開発の管理と見積り

ねらい

開発そのものを管理する方法を学びます。このレッスンを終えると、規模の見積り方と変更の扱い方を説明でき、遅れた開発に人を足しても速くならない理由が分かるようになります。

どれくらいの大きさかを見積もる

日程と費用を決めるには、まず作るものの大きさを見積もります。

• プログラムステップ法（LOC法）… プログラムの行数で規模を測ります。分かりやすい反面、同じ機能でも書き方で行数が変わり、設計の前には数えられないという弱点があります。
• ファンクションポイント法… 利用者から見た機能の数と複雑さで規模を測ります。入力画面がいくつ、帳票がいくつ、といった数え方です。設計の前でも見積もれることが利点です。
• 類推見積り… 過去の似た案件と比べて見積もります。速い反面、比べる相手の記録が要ります。

人を足しても、速くはなりません

遅れている開発に人を追加すると、かえって遅くなることがよくあります。理由は2つです。

• 教える時間がかかる。新しく入った人は、すぐには戦力になりません。教えるのは、いま働いている人です。
• 連絡の経路が増える。3人なら経路は3本ですが、6人だと15本になります。人数の増え方より速く、経路は増えます。

だから、遅れへの対処は「人を足す」ではなく、「作る範囲を減らす」か「期限を延ばす」が基本になります。

変更を、勝手に受けない

開発の途中で「ここも直してほしい」という要望は必ず出ます。受けるかどうかを、その場で決めないしくみが要ります。

変更管理では、要望を受け付けたら、次を確かめてから可否を決めます。

• 影響… どの工程まで戻るのか。他の機能に影響しないか。
• 費用と期間… どれだけ増えるのか。
• 優先度… いま入れるべきか、次の機会でよいか。

受け付ける窓口と、決める人を決めておきます。現場で個別に受けると、誰も全体の増分を把握できなくなります。この「気づかないうちに範囲が膨らむ」ことをスコープクリープといい、遅延と赤字の主要な原因になります。

成果物を、正しく管理する

• 構成管理… プログラムや設計書の版を管理し、いまどれが正しいのかを保つことです。
• バージョン管理… 変更の履歴を残し、いつ誰が何を変えたかをたどれるようにします。必要なら前の状態に戻せます。

同じ名前のファイルが複数の場所にあって、どれが最新か分からない状態が最も危険です。古い版を元に直せば、直したはずの不具合が戻ります。

まとめ

見積りは、規模を測ることから始めます。ファンクションポイント法は利用者から見た機能で測るので、設計の前でも見積もれます。遅れている開発に人を足すと、教える時間と連絡経路の増加でかえって遅くなります。変更は窓口と決定者を決めて受け、構成管理でどれが正しい版かを保ちます。

理解の確認

納期が迫っている開発プロジェクトが遅れており、責任者が「人員を倍にして挽回する」と提案しました。この提案の問題点を2つ挙げてください。

答え: 1つ目は教える時間の発生です。新しく参加した人はプロジェクトの経緯や設計を知らないため、すぐには戦力になりません。しかも教える役目を担うのは、いま作業している人です。もっとも生産的な人の時間が教育に取られ、短期的にはむしろ進みが落ちます。2つ目は連絡経路の増加です。関係者が増えると、意思疎通に必要な経路は人数の増え方より速く増えます（3人で3本、6人で15本）。打ち合わせと確認の時間が増え、認識の食い違いも起きやすくなります。納期が迫っている段階での対処としては、作る範囲を減らすか期限を延ばすことを先に検討すべきです。