第1回でセーブポイント、第2回でAIとの合わせ技をお話ししました。最終回は、ひとりで書かないとき の話です。
現場の職員さんと一緒にまとめる実践報告。複数の事業所にまたがる共同研究。指導教員とのやりとり。――共同執筆でいちばん消耗するのは、たぶん文章を書くことそのものではありませんよね。
添付ファイルを送り合っているうちに、どれが最新か分からなくなって……。あとから「この表現、誰の判断でこうなったんだっけ」と思っても、もう追えないんです。
原稿と議論が、別々の場所に住んでいるからですね。議論のほうを、原稿の隣に引っ越させて しまいましょう。
回覧板 ― 提案と、その理由を、同じ場所に置く
GitHubには プルリクエスト という機能があります。名前は物々しいですが、中身は 回覧板 です。
「ここをこう直したいのですが、いかがでしょう」と提案を回す。相手は原稿を開いて探すのではなく、直した箇所だけが色付きで並んだ画面 を見て、気になる行のすぐ横にコメントを書き込む。納得したら本編に取り込む。それだけです。
メールと何が違うのか。決定的なのは、議論が原稿の「その行」にくっついている ことです。
メールだと「3ページ目の下から2行目の、“影響”という語ですが」と書き、相手は原稿を開いて場所を探すところから始めます。そして半年後、査読者に「ここの用語選択の根拠は」と聞かれて理由を思い出そうとしても、その理由はメールソフトの奥に沈んでいて、原稿からはたどり着けません。
回覧板なら、その行のすぐ横に理由が残ります。原稿と議論が、最初から同じ場所にある。 共著で「この表現、誰の判断だったっけ」が起きなくなるのは、この構造のおかげです。
付箋 ―「あとで確認」を、頭の外に出す
もうひとつ、イシュー という機能があります。こちらは 付箋 だと思ってください。
- 「この引用、出典を要確認」
- 「倫理審査の承認番号を、方法の節に入れる」
- 「B事業所の同意書の回収待ち」
- 「先行研究をあと2本」
こういう「あとでやる」を、原稿と同じ場所に貼っておけます。頭の中とメモ帳とふせんに散らばっていたものが、一か所にまとまる。片付いたら消す。共同研究者にも見えるので、「あれ、どうなりました？」の確認メールが要らなくなります。
そして、この付箋がとくに輝く場面があります。査読対応 です。
査読コメントが10項目返ってきたら、1項目につき1枚の付箋を貼る。対応した回覧板を、その付箋に紐づける。すると――修正対応表が、作業しているうちに勝手にできあがっています。 「査読者2の指摘3に対し、○○のように修正した（本文◯頁）」を最後にゼロから書き起こす、あの徒労がなくなります。
ここでもAIが使えます。
論文だけの話ではありません
同じ仕組みが、そのまま効く書類があります。
- 規程・マニュアル・様式：運営規程、就業規則、業務マニュアル。「どの条文が、いつ、なぜ変わったか」が全部追えます。実地指導で「この時点の運用は」と聞かれたとき、その時点の版をそのまま出せる強さは、なかなかのものです
- 助成金・科研費の報告書：去年のものを下敷きに今年のものを作る書類の代表格
- 調査票：質問文をどう練り直したかが残るので、方法の節を書くときに困りません
- 翻訳・現代語訳：「この語をこう訳した理由」がセーブのメモとして積み上がっていきます
研究者でなくても、長い文章を、少しずつ、何度も直す 仕事をしている方には全部あてはまります。
いちばん大事なお願い ― 逐語録は、上げない
ここは強めにお伝えします。逐語録、支援記録、お名前や生年月日の入った資料、写真は、インターネット上の書庫に置かないでください。
「非公開設定にすれば大丈夫では」と思われるかもしれません。設定としては非公開にできます。それでも、外部の事業者のサーバーに預けている という事実は変わりません。研究倫理の審査で「データの保管場所」を書いた、あの欄を思い出してください。
現実的な線引きは、こうです。
| 置いてよいもの | 置かないもの |
|---|---|
| 原稿本文（仮名化・匿名化済み） | 逐語録・音声・動画の元データ |
| 引用文献リスト・調査票の様式 | 氏名や個人が特定できる記述を含む資料 |
| 規程・マニュアル・様式のひな形 | 同意書、支援記録、写真 |
そして知っておいていただきたいのは、Gitは書庫を使わずに、自分のパソコンの中だけでも動く ということです。セーブポイントも、差分も、枝分かれも、手元だけで全部できます。インターネットに預けるかどうかは、後から選べる別の話。まずは手元だけで始めて、まったく問題ありません。
考え方の土台は「ここから先は見せない」の回と同じです。あわせてお読みください。
使い分け ― Googleドキュメントで足りる場面も多い
正直なところをお伝えします。全部Gitにする必要はありません。
| 場面 | 向いているもの |
|---|---|
| 会議中に、みんなで同時に議事録を打つ | Googleドキュメント |
| 短い文書に、ぱっとコメントをもらう | Googleドキュメント（提案モード） |
| 数か月かけて書く原稿を、何度も練り直す | Git |
| 大胆な書き換えを、本編を壊さず試す | Git |
| 直した理由を、何年も残したい | Git |
| 規程の改定履歴を、証拠として残したい | Git |
Googleドキュメントは「同時に触る」のが得意、Gitは「各自が持ち帰って書き、あとで突き合わせる」のが得意。どちらが上ということはなく、原稿の寿命の長さで選ぶ のがいちばんしっくりきます。
最初の一歩は、3つだけ
- GitHubのアカウントを作る（無料）
- GitHub Desktop を入れる。セーブも保存もボタン一つです
- 練習用に、いま書いている原稿を1本だけ 入れて、1週間、区切りごとにセーブを押してみる
いきなり全部の原稿を移す必要はありません。次に書く1本 から試してみてください。分からないところは、AIに聞けば手順を噛み砕いて教えてくれます。「Windowsを使っていて、パソコンは苦手です。GitHub Desktopで原稿を1本だけ管理したい。最初にやることを順番に、専門用語なしで教えてください」――このくらいの頼み方で十分です（頼み方の4点セットの回もどうぞ）。
導入でつまずいたら ― AIへの聞き方を、その場で組み立てる
正直に言うと、Gitの導入は、お使いのパソコンの種類や職場の設定によって、手順が少しずつ違います。記事の形でどれだけ丁寧に書いても、「書いてあるとおりに進まない」はどこかで必ず起きます。そこで発想を変えます。手順書を探し回るより、詰まった場所を、そのままAIに持っていく のがいちばん速いのです。
ただし、聞き方で返ってくるものが変わります。まず、そっけない聞き方。
これだと、AIはあなたの画面も状況も見えないので、世間一般の説明を最初から並べるしかありません。返ってくるのは、どこかで読んだような一般論です。そこで、頼み方のコツの回でお話しした 4点セット（背景・お願い・条件・形式）の出番です。
お願い：インストールは終わりましたが、次に何をすればよいか分からず止まっています。ここからの進め方を教えてください。
条件：専門用語を使わないでください。いま私の画面に見えているものを確かめながら進めてください。
形式：1回にひとつずつ、番号つきで。私が「できました」と返してから次へ。
同じ「困っています」でも、いま自分がどこにいて、どこで止まったのかまで伝われば、AIは一般論ではなく あなたの場面に合わせた道案内 に変わります。聞き方は試験ではないので、4つ全部そろわなくても構いません。足りないところは、AIのほうから聞き返してくれます。
途中でエラーの文章が出たときは（英語のことも多いです）、意味を推測しようとしなくて大丈夫。そのまま貼り付けて、「これは何が起きていますか。素人向けに説明してください」と聞いてください。読めない文章こそ、AIにとってはいちばん正確な引き継ぎメモになります。
ひとこと： 3回を通してお話ししてきたのは、結局のところ 「考えた過程を、捨てないでおく」 という一点でした。どの版を採ったか、なぜその語にしたか、AIの提案のどれを断ったか。それは論文の本文には書けない、けれど確かにあなたの研究の一部です。ファイル名や記憶に頼ってこぼしてきたものを、そのまま拾い上げてくれる。Gitという道具の値打ちは、やり直せること より、むしろ 迷った跡が残ること のほうにあるのかもしれません。
3か月後、「あのとき何を考えて書き直したんだったか」を自分で読み返せたとき、たぶん手放せなくなります。そして何より――フォルダの中から
最終版_これでいく_本当に最終が消えます。それだけでも、けっこう清々しいものです。
あわせて読みたい：フォルダの中に「最終版」が6つある ― 原稿にセーブポイントを置く話／AIが直した原稿、どこを変えられたか分かりますか ― 赤ペンを自動で引かせる／AIに話していいこと、いけないこと ― “個人情報”の線引きは、これだけ覚えて
「こんなこと、パソコンやAIでできる？」というギモンがあれば、お問い合わせフォームからぜひ教えてください。次の「教えてAIさん」で取り上げるかもしれません。