2.2ソフトウェア開発管理技術

同じシステム開発でも、「最初にすべて計画してから作る」進め方と「小さく作って確かめながら進める」進め方があります。この開発の進め方（モデル）の違いと、規模・工数をどう見積もるかを理解することが、この節のテーマです。

2.2.1開発モデル

• ウォーターフォールモデル＝要件定義から受入れまでの各工程を順番に、後戻りしない前提で進める開発モデル。計画が立てやすい一方、後の工程で問題が見つかると手戻りが大きくなりやすい特徴があります。
• アジャイル＝小さな単位（短い期間）で計画・開発・確認を繰り返し、変化する要求に柔軟に対応する開発の考え方の総称。スクラム＝アジャイルの代表的なフレームワークで、短い期間（スプリント）を繰り返しながら優先度の高い機能から順に作っていきます。
• XP（エクストリームプログラミング）＝アジャイルの一手法で、ペアプログラミング（2人1組で1台の画面を使い、1人がコードを書きもう1人が確認する）や、こまめなテスト・継続的な統合など、プラクティスを重視するのが特徴です。

2.2.2共通フレームと見積り

• 共通フレーム＝ソフトウェア取引・開発の各工程で「何を実施すべきか」を共通の用語と作業項目で定めた、発注者・受注者間の認識のずれを防ぐための指針です。
• ファンクションポイント法＝画面数・帳票数・ファイル数など、利用者から見える機能の数と複雑さをもとに開発規模を数値化する見積り手法。プログラムの内部構造に詳しくなくても比較的早い段階で見積もれる利点があります。
• 工数＝作業量を「人数×期間」で表した単位（例：人月＝1人が1か月かけて行う作業量）。見積もった規模から必要な工数を割り出し、費用や納期の計画に使います。

業務システムの刷新プロジェクトを例に考えます。要件がほぼ固まっていて、途中で大きく変わる見込みが低い場合は、ウォーターフォールモデルで要件定義から受入れまでを順番に計画的に進めるのが向いています。一方、新規のスマートフォンアプリのように「実際に使ってみないと本当に必要な機能が分からない」場合は、短いスプリントを繰り返すスクラムのようなアジャイルの進め方が向いており、優先度の高い機能から少しずつリリースして利用者の反応を見ながら計画を調整します。開発チームの中でさらに品質を重視したいなら、XPのペアプログラミングを取り入れ、1人がコードを書きもう1人がその場で確認することで、レビューの効果を開発中に前倒しで得ることもできます。プロジェクトの初期段階、まだ詳細設計が固まっていない段階でおおよその開発規模とコストを見積もる必要が出てきたら、画面数や入出力ファイル数など利用者から見える要素を数えて規模を算出するファンクションポイント法が使われます。算出した規模から必要な工数（例えば「20人月」）を見積もり、そこから要員計画や納期、費用の妥当性を検討していく、という流れになります。また、発注者と受注者の間で「設計」や「テスト」という言葉の指す範囲の認識がずれると、後になってトラブルになりやすいため、共通フレームに沿って工程や作業項目の定義をすり合わせておくことが、契約や進行管理の土台になります。

2.2.3この節のまとめ

• ウォーターフォール＝順番に後戻りしない前提・アジャイル＝小さな単位を繰り返し変化に強い（スクラム＝フレームワーク／XP＝ペアプログラミング等のプラクティス）
• 共通フレームは発注者・受注者間の用語・作業項目のずれを防ぐ指針
• ファンクションポイント法＝利用者から見える機能の数と複雑さで規模を見積もる。工数は「人数×期間」（例：人月）