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

第3章で見直した研究課題、目的、RQ、意義をもとに、研究計画書の導入を書く。何を調べるのかに加え、先行研究を踏まえてなぜその研究が必要なのかを、読者が理解できる文章にする。

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章で扱う。