TRACERYプロダクトマネージャーの haru です。
2025年2月18日(火)に開催された勉強会『BPStudy#210〜見積りと計画について学ぼう』の第3部では、開発の見積りをテーマにしたパネルディスカッションが行われました。その時の様子をお伝えします*1。
プロジェクト成功への鍵、開発見積りの重要論点
- その１: 内製開発と外部委託における見積りの相違点
- その２: 「高すぎる」と言わせない見積りの技術（説明責任、スコープ、タイミング、インプット）
- その３: 見積りのトレードオフへの向き合い方
- その４: 過去の経験を見積りに活かす方法
- その５: 新規開発と既存システム改修の見積り戦略の違い（本記事）
- その６: 『見積りソン』に参加して得たもの
- パネラー：
- 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
- (株)アクティア COO
- 濱井 和夫 (はまい かずお) 氏：以下、濱井
- 神崎 善司 (かんざき ぜんじ) 氏：以下、神崎
- (株)バリューソース代表取締役社長、要件定義手法のRDRA（ラドラ）*2の開発者
- 藤貫 美佐 (ふじぬき みさ) 氏：以下、藤貫
- （株）NTTデータフィナンシャルテクノロジー T＆S事業部 シニア・スペシャリスト、ITシステム可視化協議会 会長、『見積りソン*3』主催
- 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
- モデレータ：
- 佐藤 治夫(さとう はるお) ：以下、haru
- (株)ビープラウド代表取締役社長、この記事の筆者
- 佐藤 治夫(さとう はるお) ：以下、haru
新規開発と既存改修──見積りの前提とアプローチの違い
haru：参加者の方から「まったく新しいシステムを開発する場合と、既存システムに修正を加える場合とでは、見積りの進め方や考え方は変わってくるのでしょうか？ 特に後者、既存システムの修正について詳しく伺いたいです。たとえば、CCPM（クリティカルチェーン・プロジェクトマネジメント）におけるバッファー係数は変えるべきなのでしょうか？」という質問が届いています。
藤貫：新規システムを開発する場合は、新規開発に適した生産性モデルを適用しやすいため、比較的見積りしやすいと言えます。
一方で、既存システム、特に自動化された仕組みを含むシステムの修正となると、状況は大きく変わります。
どこに手を加えるのか、要求される品質レベルに応じて影響範囲をどこまで見積もるか、どの程度テストを実施すべきか、判断と見極めが欠かせません。
既存システムの改修見積りには、有識者による影響分析や品質リスクの見立てが不可欠となります。こうした点が、既存システムの見積りが、新規システムの見積りとは決定的に異なる部分だと考えています。
神崎：少し話がそれるかもしれませんが、As-Is（現状）とTo-Be（あるべき姿）の見積りは、あらかじめ分けておいたほうがよいと感じています。
To-Beの検討中にAs-Isの話を始めてしまうと、議論が入り混じってしまい、結果としてプロジェクト全体の混乱につながることが少なくありません。
そこでまずは、As-Isについて大まかな見積りと期間だけでも押さえておきます。
その上で、To-Beの設計や見積りに集中できる体制を作ったほうが、話の整理もしやすく、結果としてプロジェクトの進行もスムーズになるのではないかと思います。
haru：それは新規ではなくて、改修の時の話ですか？
神崎：そうです。
haru：As-Isというのは、調査などの話ですか？
神崎：はい。To-Beを検討するにしても、それが改修を前提とするものであれば、どのシステムの、どの部分を修正する必要があるのかを把握していなければ始まりません。
修正対象となるシステムの全体像が見えていなければ、To-Beの議論そのものが空回りしてしまう可能性があります。
だからこそ、まずは現状把握の一環として、As-Isレベルでざっくりとした見積りを行い、対象範囲と規模感を掴んでおくことが重要だと考えています。
haru：影響範囲の調査に多くの工数がかかるシステムも少なくありません。長年そのシステムに関わっている人であっても、そう感じることはあります。
最近では、AIにコードを解析させ、「この部分を修正すればよい」と提案してくれるサービスも登場しています。
とはいえ、すべてのソースコードをAIに読み込ませたうえで、「このような変更をしたいなら、こことここを直せばよい」といった形で、正確かつ信頼できる回答を即座に返してくれるようになるには、まだ技術的なハードルが残っていると感じます。
濱井：継ぎ接ぎだらけのコードや、安易にコピペを繰り返して作られたようなソースコードをAIに読み込ませても、現段階では、意図を正しく解釈したり、的確な判断を下したりするのは難しいと思います。
見えないシステム、見えない責任──改修を阻む構造的課題
haru：付け足し、付け足しで何とかやってきたシステムは、世の中に本当にたくさんありますね。
濱井：弊社でもそうなんですが、長く維持管理しているシステムは、だんだん全体が見えなくなってくるんですよね。「あれ、これってどうなってたっけ？」のように。
実際、以前RDRAを使ってリバースモデリングをしたとき、「ああ、そうか、このシステムは、こういう構造だったのか」と神崎さんに教えてもらいながら一つひとつ整理できたのは、本当に助かりました。
たとえば今ある仕組みを全部フルスクラッチで作っていたとしても、そこから一部をパッケージと連携したいとなったときに、全体の構造を把握していないと、どこで機能を分割すれば良いかも判断できません。そのような意味で、RDRAはすごく実践的に効いたなと実感しています。
haru：皆さんに経験からお伺いしたいのですが、システムの全体像が把握されていなかったり、把握している人すらいない状態で開発が進んでいるプロジェクトは、どれくらいあるのでしょうか？
濱井：維持管理フェーズに入ったシステムだと、そういうケース、山ほどありますよね。
「この一部だけちょっと直してくれない？」と言われて手を入れたら、実はその裏で他の機能とつながっていて、思わぬところで不具合が出てきたり。
とりあえず作ってリリースまではしたものの、その後になってバグが出てきて、対応に追われて…というのも、本当によくある話です。
haru：そうなんですよね。気がつけば、もう誰も責任を持てない状態になっている。でも、今まさに誰かが手を入れなければならない。
特に、大規模なシステムは、長く開発が続くほど「誰が何をどうしてきたのか」が見えにくくなって困った状況に陥りやすいんですよね。
神崎：そのような場合、システムが明確に独立していないことが多く、どこで機能や構成を切り分ければよいのか判断しづらいケースがよくあります。
改修における見積りの難しさ
haru：質問に戻りますが、「新規と改修でCCPMのバッファー係数*4は変わることはあるのか？」という点についてです。
弊社では、新規と既存では、バッファ係数は変えていないですね。
改修対象が、これまで継続的に開発してきた既存システムである場合、開発チームには十分な知識と経験が蓄積されています。そのため、リスクが相対的に低く、バッファを削減できるのではないかと考えられるかもしれません。
しかし、たとえ既存システムについてある程度知っていたとしても、やはり影響範囲の調査は丁寧にやらないといけないし、慎重に進めざるを得ません。
先ほど藤貫さんがおっしゃっていたように、新規開発のほうが思い切った判断がしやすいんですよね。一方、既存システムはバグを出せないプレッシャーがあるぶん、どうしても慎重に進める必要がある。
結果的に、新規と既存で大きくバッファー係数が変わることはないのではないか、というところに弊社の今のところの実感です。
高崎：では逆に、既存システムの場合は、あえてバッファー係数を大きく設定することもあるのでしょうか？
haru：増やしもしていないですね。一度「バッファ係数1.4、つまり5日に対して2日」というバッファー設定でお客様にご納得いただいているので、それを後から増やすとなると、「その増加分にはどんな根拠があるのか」といった話になりがちです。
高崎さんの話にもありましたが、やはり納得感を損なうとプロジェクト全体の信頼性に関わってきますし、説明にも手間がかかります。
場合によっては、「不要なコストを上乗せしようとしているのでは」といった誤解を招くこともあるため、そうした懸念を避ける意味でも、弊社ではバッファーを追加で増やすことは基本的にしていません。
高崎：藤貫さんが言っている通り、「改修は難しいんです」と納得してもらう、というのはどうでしょうか？
濱井：工数のかかり方って、やっぱり全然違うんですよね。
haruさんのところのように、設計ドキュメントがちゃんと残っていればまだいいんですけど、スクラッチで作られていて、記録も曖昧な場合は特に。
通常の新規開発だと、工数は製造の真ん中あたりがピークになる、いわゆる山型になります。
でも、改修や維持メンテナンスになると、バスタブ曲線のように、最初の影響範囲調査の工数が大きくて、中盤は比較的工数が少なく、最後の試験工程で一気に工数が跳ね上がります。
で、そこの試験や影響調査の大変は、結局ドキュメントがどれだけ残ってるか、どれだけ正確かにかかってくるんですよね。そこがしっかりしていないと、どこに手を入れたらどこが壊れるのか読めなくて、怖くて前に進めない。
だから結局、そういう“改修の前と後の重さ”が、工数全体に影響してくる構造になってるのだと思います。
高崎：ファンクションポイントは、たしか新規と改修で係数のかかり方が違っていましたよね。
藤貫：測り方そのものが少し違う、という扱いになるイメージですね。
高崎：測定方法の違いは、改修作業特有の難しさに起因しているのでしょうか？
藤貫：難しさというより、仕組みの問題なんです。
ファンクションポイントは、すごく単純で、手を加えた機能を「改修のファンクション」として数える、というルールなんですよね。だから影響範囲として表せる部分と表せない部分があります。
実際には、たとえばデータベースに少しでも手を加えると、それを起点に他の処理（トランザクション）にまで影響が波及することもあります。
データベースの変更に伴い、修正が必要となる処理は、改修対象としてファンクションポイントで規模を数値化できます。一方で、影響を受けている可能性はあるものの、実際には改修を行わず確認のみを行う処理については、ファンクションポイントの対象とはしません。
ただし、システムに求められる品質レベルによっては、確認作業の範囲や工数が大きくなる場合もあり、見積りに含めるかどうかは、業務やシステムへの影響度を踏まえて有識者が判断する必要があります。
次回は『見積りソン』に参加して得たもの、というテーマで話が進みます。
*1:伝わりやすくする目的で、話の流れを一部再構成しています。
*2:モデルベースのビジネスとシステムの可視化手法。To-Be用途では要件定義に使え、As-Is用途では、既存システムの可視化に使用できる。RDRA公式サイト
*3:紹介資料：見積りと提案の力を競う見積りソン
*4:CCPM（Critical Chain Project Management）では、各作業に個別で持たせていた安全余裕を、プロジェクト全体のバッファーとして集約する。バッファー係数とは、クリティカルチェーンの所要時間に対して、どれだけのバッファー時間を設定するかを示す係数である。一般的には、クリティカルチェーンの所要時間の50％（係数0.5）程度が標準的とされるが、プロジェクトの不確実性やリスクの大きさに応じて増減させることが推奨されている。
