4. 研究計画書の導入を組み立てる

第3章で見直した研究課題、目的、RQ、意義をもとに、「なぜこの研究が必要か」を説明する導入の下書きを作る。提出する研究計画書の一部として、先行研究を踏まえた必要性と研究目的を読者に説明する。第5章では、この目的に合う調査と分析の方法を検討する。

4.1 背景から研究目的までをつなぐ

導入では、背景と先行研究を説明したうえで、未解決の問題、研究の意義、研究目的の順に書く。次のテンプレートを使って、文献メモと更新した仮案を導入の文章にまとめられる（Creswell & Creswell, 2018, 第5章; Booth et al., 2016, 第4章; Turabian, 2018, 第2章）。

［現象］は［対象／社会／理論］にとって重要である。
先行研究は主に［知見A］と［知見B］を示してきた。
しかし、［不足、矛盾、前提］があり、［未解決の問題］はまだ十分に明らかになっていない。
この問題が未解決のままだと、［理論、実践にどのような影響があるか］。
そこで、本研究の目的は、［対象と文脈］における［現象］の
［明らかにしたい側面］を明らかにすることである。

先行研究から分かったことには出典を付け、その知見をもとに自分が考えたことと書き分ける。

4.2 意思決定の例で導入を書く

第3章で見直した仮案を、導入の文章にすると次のようになる。研究目的は、文献の比較をもとに本ガイドで考えたものである。

ソフトウェア開発では、仕様変更の採否を決めるために、技術上の見通しや業務上の要望を持ち寄る必要がある。相談が特定の人に集まる場合、その人の知識を必要としているのか、権限に基づく判断を必要としているのかによって、停滞への対応は異なる。

HerbslebとMockus（2003）は、複数拠点での変更作業に関わる人数と、完了までの時間との関連を示した。Moeら（2012）は、アジャイル開発で共同の意思決定を行う際に、戦略、戦術、日々の業務の各水準の決定を整合させる課題を論じている。前者は作業を担う人の間の調整、後者は異なる水準の決定の関係に着目する手がかりとなる。

これらの視点から仕様変更の意思決定を考えると、記録上は同じ「回答待ち」でも、情報が足りない場合と承認が必要な場合を区別する必要がある。その違いが分からなければ、知識の共有と承認の手順のどちらを見直すべきか判断しにくい。個々のやり取りを追い、何が待たれているのかを確かめることが、停滞への対応を考える材料になる。

そこで、本研究の目的は、リモート環境のソフトウェア開発チームにおける仕様変更の意思決定が進み、または滞るプロセスを、情報の共有と判断権限に着目して明らかにすることである。

この例では、背景、先行研究の知見、問題を調べる意義、研究目的を、それぞれ一つの段落にまとめた。実際の計画では、関連する文献をさらに調べ、ここで扱う問題に既存の研究がどこまで答えているかも示す。

導入の下書きができたら、第5章で、RQに答えるための調査と分析を具体化する。方法を検討して対象や目的が変わった場合は、導入も見直す。計画書全体へのまとめ方は、第7章で扱う。