研究計画の立て方

文献調査がある程度進んで、自分の問いの輪郭が見えてきたら、次にやってくるのが研究計画の段階です。多くの学生が、ここで一度足を止めます。「ちゃんとした計画を書かないといけない気がする」「網羅的に書かないといけない気がする」と、無意識のうちに身構えてしまうのです。

僕は、その身構え方を少しほぐすところから話を始めたいと思っています。研究計画の本質は、ぶ厚い書類を仕上げることではありません。 あなたの問いを解決するために必要なステップを明確にし、限られた時間の中で確実に前に進む道筋をつくること です。研究計画は、あなたが書き上げて出すための書類ではなく、これから一年半なり三年なりを一緒に歩く、あなた自身のための地図なのです。

完璧な計画は、研究にとって邪魔になる場合が多い 。最初から完璧を目指して計画を組み立てると、想定外の事態が起きたときに、計画そのものを守ろうとして本来の問いを見失います。方向性だけ明確にしておいて、小さな改善を積み重ねながら、走りながら学ぶ。そのくらいの構えでちょうどいい、というのが僕の長年の実感です。

理解→設計→実装→評価の循環

情報系、特に人間を対象とするシステム開発の研究では、技術開発と人間理解の両輪を回していく必要があります。これは口で言うより、実際にやってみるとずっと難しい。技術ばかり進めて人間理解がついてこない、あるいはその逆、というのが、ありふれた失敗です。

頭の中で描いてみてほしいのが、四つの段階を巡る循環の絵です。最初は 理解段階 。あなたの問いに関わる人間の行動や思考プロセスを調べて、支援すべきポイントを特定する。何を支援したいのか、誰のどんな困りごとに介入したいのかを、ここで言葉にします。次に 設計段階 。理解した内容を、技術的に実現可能な形に翻訳していく。同時に、別ドメインへの応用可能性も視野に入れておくと、研究の射程が広がります。三つめは 実装段階 。核心機能から始めて、段階的にプロトタイプを発展させ、設計の実現可能性を確かめる。最後が 評価段階 。システムの効果やユーザビリティを測り、改善点を洗い出して、次の循環につなげる。

ここで強調したいのは、 この四つは一直線に進むものではない という点です。実装してみると設計の前提が崩れて、理解段階に戻る必要が出てくる。評価してみると、当初の問いそのものを再定義したくなる。何度も行き来しながら育てていくものだと思ってください。最初の計画段階で「何ヶ月までにこのフェーズ」と固定的に決めすぎると、戻ること自体が「失敗」に見えてしまいます。実際は、戻ること込みのプロセスです。

リスクと付き合う

システム開発研究には、どうしても技術的な不確実性がつきまといます。想定した技術が使えないかもしれない。実装が予想以上に難しいかもしれない。被験者が集まらないかもしれない。期待した効果が出ないかもしれない。こういうリスクを、計画の段階で完全になくすことはできません。

でも、減らすことはできます。やっておきたいのは、 代替案を先に考えておく ことです。「この技術が使えなかったら、何で代用するか」「被験者が集まらなかったら、対象を広げるか」「効果が出なかったら、何を再分析として用意できるか」。これを最初に紙の片隅にメモしておくと、いざというときの被害が桁違いに小さくなります。代替案は、悲観論ではなく、保険です。研究計画書のなかで明示する必要はないのですが、自分のノートのなかには必ず書いておいてほしい類のものです。

研究計画書で表現する

研究計画書は、書類としては概ね次の四つの構成で作ります。研究概要（タイトル・目的・期待成果）、背景・関連研究、研究アプローチ（手法・設計・評価）、スケジュール・リソースの順です。

このなかで、ほとんどの学生がいちばん軽く書いてしまうのがタイトル ** です。ところが、タイトルは計画書のなかで一番ものを言う部分でもあります。「AIを活用した教育システムの研究」のような抽象的な書き方は、誰でも書ける代わりに、誰の心にも残りません。「プログラミング初心者の思考プロセス可視化による適応的学習支援システム」のように、何を対象に、何をどう扱うのか** が一目で伝わる形まで詰めてください。タイトルがちゃんと書けていれば、研究の半分は決まったようなものです。

研究目的の節では、いきなり学術的な目的から書き始めず、まずはあなたの素朴な問い――たとえば「なぜ初心者は同じところで詰まるのか？」――を率直に書いてみてください。そこから、その問いを学術の言葉に翻訳した目的、そして理論・技術・実践のそれぞれにどんな期待価値があるのかを順番に整理していく。素朴な問いを最初に置いておくと、計画書全体に「なぜそれをやるのか」という芯が通ります。

スケジュールとマイルストーン

スケジュールを引くときに効くのが、年間を3〜4ヶ月のクォーターに分けるやり方です。第1クォーターで問題定義の完了、第2クォーターでプロトタイプ、第3クォーターでシステム完成、第4クォーターで評価と論文化、といった具合に、各クォーターの成果目標を具体的に決めます。月単位だと細かすぎて崩れやすく、半年単位だと粗すぎて軌道修正が間に合わない。クォーターはちょうどいい解像度です。

ガントチャートで全体を可視化しておくのも、地味だけど効きます。文献調査、要求分析、設計、実装、評価、論文執筆。それぞれの期間と依存関係を一枚にしておくと、遅れが出たときに「どこを調整すれば全体が崩れずに済むか」を判断しやすくなる。これは指導側にとっても助かるので、定期面談のときに毎回そのチャートを一緒に見られると、議論がぐっと早くなります。

研究の核を保ちながらも、実現可能性を重視して調整していきましょう。 完成度の高い小さな成果のほうが、未完成の大きな構想よりずっと価値がある というのが、長く研究をやってきての僕の本音です。だから、計画は守るためにあるのではなく、調整するためにある。週次・月次のレビューと、指導教員との定期面談で、方向性のズレを早めに修正してください。

実行のコツ

最後に、計画を動かしていくうえでの心構えを少しだけ書いておきます。

ひとつは、 毎週、小さくても確実な進歩を積み上げる ということ。今週新しく分かったこと、動くプロトタイプの改善、問いの精緻化。ぱっと見は地味でも、こういう「手ざわりのある前進」が、長い研究を支えてくれます。逆に言うと、「今週は調査だけだったので進捗ありません」が三週続くと、危険信号です。調査自体に進捗を定義し直してください。

もうひとつは、 完璧な理解を待たずに行動する ということ。文献で学んだ理論を、まだ消化しきれていなくてもプロトタイプで試してみる。実装を通じて理論の理解を深めていく。情報系の研究では、頭で考える時間と手を動かす時間が半々くらいでちょうどよいと思っています。手を動かすと、頭で見えなかったものが見えてきます。

そして、困ったときは一人で抱え込まないでください。これは計画管理の技術というより、研究を続けるための生存戦略だと思ってもらっていいです。詰まっているときに一人で粘っても、ほとんどの場合、問題は解けません。誰かに話しかける、ノートに書き出す、ゼミで発表する。外に出す行為そのものが、計画を立て直す機会になります。