まとめ
日報・週報を書くこと自体の意義は「自分が目的達成に向けて進んでいるのかどうか？」「目的達成に向けて進んでいるとしたらどこにいるのか？」を確認できることだと思う。これが確認できない日報や週報は自分にとって意味が無い。
はじめに
えんじにあのたまご：研究報告についての考えで良い進捗報告のやり方を褒めていただいた。うれしい。なので研究報告について何か手助けできないか考えてみる。
自分の研究や作業を進めるために他人から良いコメントをもらうという観点は良い進捗報告のやり方で書いた。また、他人が気づきやすいように自分の努力を可視化するという観点は研究室でのアピールの仕方で書いた。なので、このエントリーでは、日報や週報を書くこと自体が自分にとって役立つという観点で何をどう書けば良いのかを考えてみる。
伝統と先輩を利用する
分野やテーマによって書くべきことは異なるので、まずは自分の分野および所属研究室・部署の研究ノート、日報、週報の書き方マニュアルを探してみる。そして、それを真似する。こうするのが一番効率が良い。
もし、ボスや先輩に質問をできる雰囲気ならば「なぜ、〜を研究ノート or 日報 or 週報に書かなければならないのか？」を尋ねて、各項目を記載する意義をはっきりさせた方が良い。特に詳細に記述することを求められている項目については、マニュアルに理由の記載があったとしても、マニュアル理解の確認という形でボスや先輩に意義を説明してもらった方が無難。
その理由は、目的によって記述方法やどのくらいの詳細度で書けば良いのかが変わるため。どの記法には理由があり、どの記法は便宜的（一時的）なものなのかを把握していないと研究ノート、日報、週報をカスタマイズするときに困る。
「何を何のためにしているのか？」「期待している結果は何か？」を明記する
定形業務において既にマニュアルが作られている場合を除き、今行っている作業は何のために行っており、その作業の結果として期待される事柄は何かを可視化しておくのはとても重要。
ある目的を達成するために、複数の作業を行わなければならないことが多い。作業が順調に進んでいるときには、今の作業を何のために行っているのか、また、その作業の結果として期待されていることは何かをはっきりさせておかなくても特に問題は無い。
ところが、作業中にトラブルが発生すると話は変わる。作業を遂行するためには、トラブルを解決しなければならない。このため、新たに「トラブル解決を目的とした作業」が発生する。そして、ほとんどの場合、トラブル解決には試行錯誤が伴うので、「トラブル解決を目的とした作業」を遂行するために、さらに「トラブル解決を目的とした作業」を行わなければならなくなる。
作業の入れ子が深くなったり、試行錯誤のために作業目的を変更しつつ作業を繰り返しているうちに、元々何のためにこの作業を行っていたのかがわからなくなり、目の前の作業の終了自体が目的となってしまう。目的達成に締切りがあるときにはこれはまずい。
そこで、日報や週報において定期的に「何を何のためにしているのか？」「期待している結果は何か？」を自問自答し、他人にわかる形で記載することにより、自分が行っている作業を客観視し、「目の前の作業遂行自体を目的としてしまう」という状態を避ける。また、「期待している結果は何か？」をよく考えることで、成果物（アウトプット）を具体的にイメージし、何となく作業を行ってしまう状態を避ける。
例えば以下の質問を使って作業の内容や目的、成果を明確化する。
行為に関して洞察したいとき（特に評価やテストなど）
- 「〜というのはいったい何をどうすることなの？」
- 「何がどうなったら、〜ができたといえるの？」
- 「何がどうなったら、〜は失敗したといえるの？」
- 「〜を終えるための手順は何？一番最初に行うことは？」
- 「その行為を行う理由は何？」
- 「その行為以外に目的を達成できることはないの？」
- 「その行為を始めるには何が必要？その行為によって何を得られる？」
- 「その行為における大前提は何？」
- 「その行為は誰がどういう状況のときに行うの？」
（質問テンプレートより抜粋）
週報や日報に載せるかは別として、作業間の依存関係をはっきりさせるためにPERT図を書いておくと、どの作業から始めなければならないのか、どの作業は並行して進めてよいのかがわかって便利。なお、見積り時間は書くのは難しいと思うので書かなくても良い（初めての作業は見積りするのが難しいので）。
「調査する」「分析する」「検討する」「実装する」などの複合作業を表す言葉は使わない
日報や週報では「何を行ったのか」を報告するのがメインになると思うのだけれども、その際に「調査する」「分析する」「検討する」「実装する」などの複合作業を表す言葉は使わないようにする。この理由は、これらの言葉を使ってしまうと、具体的にどういう作業をするのかが他人にはわからないため。「誰が、何を、どうすることで、どういう状態にする」ということがわかる言葉か、あるいは、説明をする。
たとえば、「先行研究について調査した」では実際に何をしたのかがわからない。こう書くかわりに「私は、Web of Scienceにて〜というキーワードで論文を検索し、ヒットした論文20本についてタイトル、概要、参考文献を読み、自分が取り組んでいる＊＊というテーマと関連するかどうかを調べた。その結果〜だった。」と具体的に書く。このぐらいまで具体的に書けば「調べた」は曖昧ではなくなる（「調べた」＝「Web of Scienceにて〜というキーワードで論文を検索し、ヒットした論文20編についてタイトル、概要、参考文献を読み、自分が取り組んでいる＊＊というテーマと関連するかどうかを判定した」であることが分かる）。
GTDの注意事項でも言われているけれども、自分がその行為を行っている姿をイメージできるぐらいの詳細度で作業を明記しないといけない。もし、今後の予定を立てる際にその詳細度で作業を記載できないならば、その複合作業の最初の単純作業のみを記載するか、複合作業を単純作業にわけること自体を一つの作業として記載する。
- 例：「先行研究について調査する」を以下のように単純作業として明確化する。
- 最初の単純作業だけ記載する：「先行研究を調査するために、〜という論文から、自分のテーマを表すキーワードを10個抜き出す」
- 複合作業を単純作業にわける：「『先行研究について調査する』を3つ以上の作業に分割する」
行おうとしていること、行っていること、行ったこと、行いたいことを区別する
以下を区別して記載する。
- 行おうとしていること：目的を達成するために行うべきことで、まだ実行していないこと
- 行っていること：目的を達成するために行うべきことで、現在実行していること
- 行ったこと：目的を達成するために行うべきことで、もう終わったこと
- 行いたいこと：目的を達成するためには（当面）関係ないことで、まだ実行していないこと
行おうとしていること、行っていること、行ったことは区別して書く。もっとも注意しなければいけないのは「行いたいこと」。スケジュールによっては「行いたいこと」に手をつけてはいけないときがある。前項の「何を何のためにしているのか？」をはっきりさせることで、どの作業が「行いたいこと」なのかを明確にする。
他人が読む前提で書く
他人が分かるように書くとただそれだけでいろいろと整理されてアイデアが湧くことが多い。本当に人が聞いている必要はない。ベアプログラミングのお手紙版を狙う。
自分のコードを他人に説明してみよう。自分のコードを誰かほかの人に説明して聞かせるのも効果的なテクニックだ。こうすると自分自身インバグが見えてくることが多い。場合によっては説明し始めた途端に気がついて「あ、もういいや、変なところがわかったよ。ごめん、ごめん」などと言って照れくさい思いをすることもある。このテクニックは意外なほど有効だし、聞き手は別にプログラマでなくてもかまわない。ある大学の計算機センターのヘルプデスクのそばにはテディベアのぬいぐるみが常備されており、摩訶不思議なバグに悩む学生は、人間のスタッフに相談する前にぬいぐるみに向かって説明しなければならないことになっていた。
（プログラミング作法 第5章 p. 173より)
ただし、いきなり他人が読む前提で文章を書くのは訓練されていない人にとっては厳しいので、まずは、垂れ流すように書く。読みやすいかどうかは一切考えずに書く。そして、一回保存する。その後、他人が読んでわかりやすいように推敲する。推敲の際には大学院生が卒論・修論指導をすべき理由とそのやり方のチェックリストがお役にたつと思う（3回ぐらい利用したならば、もう見なくても良いと思う）。
あくまでも程度問題なので注意すること。「他人が読んでも分かる＞自分しか分からない＞＞＞＞＞＞書かない」なので、書かないよりはとにかく書いた方がマシ。
公開範囲に気をつける
各種Webサービスを使って週報・日報をつける場合には公開範囲に気をつける。基本は研究室構成員だけが閲覧できるようにアクセス制限をかけるべき。世界トップレベルの研究室や部署ならば、週報・日報を無料Webサービスでつけてはいけない。無料Webサービスの提供者があなたの研究成果を盗むかもしれない。まずは、所属研究室・部署の責任者に「〜というサービスを使って週報・日報をつけてよいか」を尋ねるべし。
どういうツールを使うか
以下、思いつくままに。
- 日報や週報を書いた日時が自動で記録される、かつ、後で参照できる
- 自分で記載しないといけないのは面倒くさい＆日付間違えると困る
- タイトル、サブタイトルが記載できる
- 読みやすさや内容から章分けしたいときがあるため
- 検索できる
- 日付、キーワード、添付ファイルなどで検索できると見返すとき便利
- テンプレートを設定できる
- 定型的内容が多くなると思うので、必須項目はテンプレート化できたほうが記載漏れが減る
- リンクできる
- 過去の週報や日報全体および各章、URLやローカルの電子ファイルにリンクを貼れると後から見返すとき便利
- バックアップできる
- 重要な資産なので
- 電子的である
- 卒論、修論、報告書に再利用が簡単にできるので便利。
next49のところはどうしているのか？
研究室のメーリングリストに週1度任意で進捗報告を出してもらっている。フォーマットは研究室でのアピールの仕方の「日報／週報／隔週報をメールで送る」にあるとおりのフォーマット。
