類似見直しに要するコストはいくら？

「何かをするときは必ず仮説や試算をすべし」

というのは、いくつになっても、どんな業界でも、どんなシチュエーションでも大抵必要です。必要ないのは、反射神経が求められるようなシーンだけ。

じゃあ、実際普段何気なく行っている作業１つ取って試算してみるとどうでしょう。たとえば、

要員構成：５名(リーダ１名)
開発期間：１年(総期間)
開発規模：機能 = 70画面/30帳票
　　　　　規模 = 250kstep
作業対象：基本設計～システムテスト完了まで
発生工程：結合テスト
不良内容：エラーメッセージの内容がチェックリスト(≒設計書)と異なった

こんなシーンがあったとしましょう。

この時、１つ問題が発生する度に「他にも問題が無いか」と言う類似チェックをおこなわなければならないとする場合、必要とするコストはいくらでしょうか？

金額的なコストでも、時間的なコストでもかまいません。

前提条件

人によって、あるいは企業によって異なるため一概に「何が正しい」という答えはありませんが、ここでは次のように仮定します。まぁ、２～３次請けの中堅SIerならこういう企業が多いのではないでしょうか。

　エンジニア１名あたりの単価 ： 60万円
　（リーダのみ、×1.5倍）

もうちょっと多いかな？
まぁ計算が楽なので、ここではこのように設定しておきます。

もちろん、上記の説明には検討に不要な情報も載っています。ここから必要な情報を抜き出して試算してみましょう。１機能あたりの平均規模と、１機能見直すために要するコストに気を付けてください。

1.「作業配分」を仮定する

リーダーとなる1名は監督／管理の作業やお客さまへの報告などの雑務もあるので他担当の50%とした場合、単純に分割して

　リーダー：10画面
　Aくん：20画面 5帳票
　Bくん：20画面 5帳票
　Cくん：10画面 10帳票
　Dくん：10画面 10帳票

程度にわけたと仮定します。
実際には能力や得意/不得意に応じて微調整しますが、とりあえずここでは適当に平均化します。画面にしても帳票にしても、１つで１機能とします（機能あたりの規模ボリュームは平均化して2.5kstep(=ksloc)程度としておく。kstep、あるいはkslocと言うのはプログラム1000行の単位です。なので2.5kstep というのは 2500行 ということ）。

2.「見積り金額」を仮定する

さて、こんな平均的なプロジェクトがあったとして、5人が１年間携わるとすると、単純に考えればプロジェクト予算の計算式はおそらく

　（プロジェクト予算）＝（１人当たりの単価）×（12か月）×（５人）

がベースになっている企業が多いのではないでしょうか。
仮にリーダーを単価90万、他の４人を単価60万と仮定すると、

　（900k × 12）＋（600k × 12 × 4） = 3960万円(旅費/経費別)

ということになります。
ＳＥ作業(開発以外の色々な支援作業)を含むともう少し請求できるかもしれません。一般的に１つのシステムというのはこうして計算されていくのではないかと思います。

3.「問題発生事象」を仮定する

ではこのまま６ヶ月強が過ぎ、ここまで順調だったとしましょう。

いよいよテスト工程にはいりましたが、ここで１つのバグが発見されたとします。

工程：結合テスト
操作：入力画面でありえない値を入力して「登録」ボタンを押した
内容：エラーメッセージの内容がチェックリスト（≒設計書）と異なった

というバグが検出されたと仮定します。仮定の話なので設計上の問題でも、プログラミング上の問題でも何でも構いません。

多くの企業では"類似見直し"と言って、「１件見つけたら他にも存在しているはず」と言う性悪説に基づいて、その場で関係する全機能をチェックしなおそうとしていることだと思います（「１匹見つけたら10匹いると思え」的なゴキブリ理論と同じです）。

上記仮定に当てはめ、仮に全機能のチェックを行ったとし、その結果、潜在していた同類の不良が５件発見できたと仮定しましょう。

多くの企業、多くのエンジニア、多くのＱＡはこの結果を聞いて

　「やってよかった」

と思うことでしょう。

4. 仮定を前提に推論する

しかし、待ってください。

類似見直しには全機能のチェックが必要と言うことで、全員の手をいったん止めることが多いと思います。チェックする時間は１機能あたり平均20分と仮定すると

①（類似見直しをした場合の所要時間）
　　＝ （調査時間）＋（（機能あたりの対策時間）×（発見機能数））

ということになります。
発見できるできないに関わらず、全機能を調査しなければなりませんので、調査時間は

　（20分）×（70機能）＝ 1400分 ≒ ３人日

は必ず消費します。そこに不良が発見された機能の対策を加えるため

　（機能あたりの対策時間）×（６画面）

分の対策時間が必要になってきます。
この1400分を原価に換算すると

リーダー：10画面 × 20分 × （90万 ÷ 20日 ÷ 8時間 ÷ 60分）
Aくん：20画面 × 20分 × （60万 ÷ 20日 ÷ 8時間 ÷ 60分）
Bくん：20画面 × 20分 × （60万 ÷ 20日 ÷ 8時間 ÷ 60分）
Cくん：10画面 × 20分 × （60万 ÷ 20日 ÷ 8時間 ÷ 60分）
Dくん：10画面 × 20分 × （60万 ÷ 20日 ÷ 8時間 ÷ 60分）

合計 ＝ 93,750円

と言ったところでしょうか。スケジュール的には３人日。利益的には１件不良を見つけるごとに10万円弱のコストをかけているということになるわけです。

5.だがしかし

ちょっと待ってください。

確かに、潜在的な不良も発見できて

　「よかった」
　「問題を取り除けた」
　「やった甲斐があった...」

と、ほっと安心したのもつかの間、このために失われた1,400分はもう返ってきません。しかし、スケジュール期限は延びてはくれません。期限内に終わらせるべきものを終わらせないと、次の作業に取り掛かる様々な人たちに迷惑をかけることになります。

不良が出ることは想定していたでしょう。
バグ０件なんてそうそうできることではありません。

想定していた不良件数分の対策工数は積んでいたかもしれません。
ですが、類似見直しにかかるコストって想定していましたか？

もし想定していなかったら、類似見直しを実施するたびにスケジュールはひっ迫し、現場は大混乱となっているのではないでしょうか。

そこで少し考えてみてください。

そもそも、今回のケースでは類似見直しとやらは必要だったのでしょうか？

条件をもう一度見直してみてください。

要員構成：５名(リーダ１名)
開発期間：１年(総期間)
開発規模：機能 = 70画面/30帳票
　　　　　規模 = 250kstep
作業対象：基本設計～システムテスト完了まで
発生工程：結合テスト
不良内容：エラーメッセージの内容がチェックリスト(≒設計書)と異なった

特に太字部分。
みなさんは、この「エラーメッセージ」の表示確認は、本来どのテスト工程で確認されるべき観点だと思いますか？

そう、『結合テスト』です。

まさに現在実施中の工程です。
よほど、レガシーな作り方をしていない限りは、プログラムやモジュール単体で

　・ある目的に従った処理を行う
　・処理にてエラーが発生する
　・そのエラー内容を汲み取って、メッセージを表示する

ところまでを実施することはありません。十中八九、エラー表示は別のプログラムやモジュールで行われているはずです。そう考えれば、この観点は単体テストでは実施が不可能…あるいは実施できたとしても観点に含める段階にないことがわかります。

そう、この観点はあくまで『結合テスト』の観点なのです。

つまり、発生すべき工程で発生するべくして発生したということです。

問題は、

　「発見すべき時に発見した」

か

　「発見すべき時に発見できず、その先で発見してしまった」

かで対応が大きく異なります。

よく見ると、この不良...本来はこの『結合テスト』と言う工程で、きちんとチェックしてれば確実に見つけられるバグの類です。一般的に言えば、結合テストで発見すべき観点に相当するからです（どの工程でどのような観点のチェックをするかは、プロジェクトごとに異なりますけど）。

だからこそテスト中に検知されたと言っても過言ではありません。

つまり、チェックリストの精度が間違っていないことさえ保証できていれば、このままテストを続けていくと

　類似見直しをしてもしなくても
　これらの潜在不良を余すことなく見つけられ、改善できた

ものだったのです。

②（随時発見した場合の所要時間）
　　＝（１画面あたりの対処時間）　　　　　　　 … １件目を発見
　　＋（１画面あたりの対処時間）　　　　　　　 … ２件目を発見
　　＋（１画面あたりの対処時間）　　　　　　　 … ３件目を
　　＋（１画面あたりの対処時間）
　　＋（１画面あたりの対処時間）
　　＋（１画面あたりの対処時間）

類似見直しで先に見つけても、テストをそのまま進めて後に見つけても、対処する時間は同じ。

実際には類似見直しをしてもしなくても、問題は確実に検知、対策できたとして、『20分×50画面』かけた時間だけが差として生まれてきます。

しかも、６機能とも対処の内容さえ間違わなければ品質はまったく同じにしかなりません。報告上は

①（類似見直しをした場合の所要時間）＝バグ１件（類似５件）
②（随時発見した場合の所要時間）　　＝バグ６件

となるだけで品質的には差異がありません。
差異があるのは

　・３人日を費やしてスケジュールを圧迫した
　・10万円弱のコストを費やして利益を減らした

だけです。

実際には類似見直ししてもしなくても同じ結果、同じ品質だったと言うのであれば、この10万円は何のために消費されたことになるのでしょう？

10万円近くを失い、３人日分近くを無駄にし、その尻拭いは自分たちでしなければならず、間に合わせるためには残業や休日出勤でカバーするしかない...と言うケースに陥ったのでは本末転倒ではないでしょうか。

不良件数が出れば出るほど逼迫するのは、こうした何も考えずに盲目的な作業をマネジメントしているためです。

プロジェクトにおける利益率の低下や、スケジュール遅延、従業員の疲弊などは、残念なことに大半が"マネジメント不良"によって発生することを知っておきましょう。

エンジニア一人ひとりの力量不足でプロジェクト全体が破綻すると言うことは、（どこかによほどの悪意でもはたらいていない限り）まずありません。

今回の例で言えば、プロジェクトマネジメントにおける

　品質マネジメント

をしっかりと計画、実行、監視・コントロールできていれば、

　多くの冗長工数(コスト)の消費を防ぎ
　結果としてスケジュールが遵守でき
　逼迫による品質劣化の脅威を防ぐ

ことにつながっていたでしょう。品質マネジメントというと、とかく定量的な基準値を設けて、傾向を分析し、重点的に対策すべてポイントを絞り込むだけ…と思っているエンジニアやマネージャー、ＱＡも多いようですが、それではアウトプットの品質だけしか満たせません。それではプロジェクトの品質としては50点も取れません。

スケジュールをひっ迫させると

・残業が増える
　→残業コストの増加、利益の低下
・メンバーは疲弊する
　→離職リスクの増加、人的リソースの低下
・スケジュールを伸ばせば、要員の空きが作れず次の仕事が回せない
　→受注量の低下、売上の低下
・顧客の信頼を失う
　→潜在顧客の損失、機会損失の増加

が発生する可能性がグンと上がります。計画の意図を理解し、行動の内容を把握し、因果を明確にして、本当に必要なマネジメントが行えなければ見えにくいところで企業に損害を与えるだけなのです。

何も考えず、過去に妄執し、ただ愚直に従っているだけというのは、周囲を不幸にすると言うことでもあることに注意しましょう。

定性的な観点からこの施策を講ずるだけで、スケジュールの逼迫は軽減し、おそらく利益を数百万は改善できます。利益率に換算すると、いったいどれだけの改善になるのでしょうね。