はじめに

要求仕様が確定していなければ基本設計はできない。基本設計が確定していなければ詳細設計はできない。詳細設計が確定していなければコーディングはできない。コーディングが確定していなければ単体テストはできない。単体テストが確定していなければ結合テストはできない。すべての物事に関する簡単な道理についてのお話です。

例外的に何とかなるだろうと思うことは、窮地に陥った者たちにおける正常化バイアスがもたらす妄想と言ってよいでしょう。

#50：目先の問題に惑わされるな

たとえば、単体テスト項目が作れないという問題を目前にした場合、何とかテスト項目を作ろうと自分なりに検討してみても徒労に終わる。この問題への適切な対処法は自分なりのテスト項目をひねり出すことではなく、何をテストすべきかの元ネタである詳細設計書をしっかりと作ること以外にない。目の前の炎を消したければ火元を消す以外に有効な方法はない。

泥と炎の戦場カメラマン

『泥と炎』と形容されたベトナムの戦場で、まず名をあげた日本人カメラマンは岡村昭彦だった。実は写真は素人で、通信社と契約して赴任したときフィルムの詰め方を支局長に聞いたという逸話を残す。だが活躍はめざましく、写真家の憧れだった米国のライフ誌を矢継ぎ早に飾った。

同誌は岡村を『ロバート・キャパを継ぐ戦争写真家』と絶賛した。本人いわく『フィルムの詰め方は知りませんでしたが、何にレンズを向けるべきかは知っていました⁠』⁠。

岡村昭彦、戦場カメラマン、朝日新聞 2012/1/23

#51：やるべきことをやるべきときに

単体テスト時に結合テストをやると言ってもやれるわけもない。単体テストに合格していないレベルのソフトウェアが結合できるわけもない。このようなことを無理に強要するベンダや請けてしまう下請けの頭の中が心配だ。開発の初期工程である見積もりや要件定義工程でやるべきことをきちんとやってさえいれば、こんなぶざまなことは起こりえない。

時間を無駄にする方法

• 混乱は時間の無駄である。混乱に飛びついてどたばたする前に冷静に事実を把握することだ
• 急がば回れ。信用は時間の代わりになる。正しく使えば、金もしかり
• 結論に飛びつくのは時間の無駄である。原因追及もしかり。大騒ぎせず見極めること
• コンピュータは時間の無駄になることがある。バックアップでその時間を節約できることもある

G.M.ワインバーグ、『⁠コンサルタントの道具箱』

#52：レビューは銀の弾丸ではない

レビューは構造物の基本的な構造や仕様の再確認を目的とする。細かなバグを見つけることが目的ではない。バグを見つけるのはデバッグであり、単体テスト、結合テスト、総合テストの役割である。なお運用テストを兼ねた総合テストは仕様の最終動作確認を主な目的とする。

銀の弾などない

病気治療の第一ステップは、悪魔信仰を細菌説によって生理学的理論に置き換えることだった。そのステップこそ希望の始まりであり、すべての魔法のような解決の夢を打ち砕いた。医療従事者は、進歩は段階を追いながら多大な労力を払って遂げるもので、健康回復には持続的で根気強い看護がなされなければならないと教え込まれた。今日のソフトウェアエンジニアリングにおいても、それは変わらない。

フレデリック・ブルックス、『⁠銀の弾などない No Silver Bullet』

#53：分別をわきまえよ

ふんべつ（分別）とはものごとの道理をわきまえることを指す。やるべきではないことをやったり、やるべきことであってもやるべきではないときにやったりする場合に分別がないと言われる。たとえば何百何千とあるテスト項目を1、2時間で全件レビューしようとすることなど、最初からできるわけもないとわかっているのに無理矢理やろうとする。レビューの本意は基本骨子の検証だけである。

自然界は人間の都合のいいようにはできていない

世の中で、役に立つ材木はみんな四角だけれど、天は四角な木を生やさない。また皮も骨もないような、かまぼこか、はんぺんのような魚があれば、人のために便利だろうけれども、天はそのような魚を生じない。自然界は人間の都合のよいようにはできていないものだ。

二宮尊徳、『⁠二宮翁夜話』

#54：顧客が望んでいるように

顧客からの要望といっても、顧客の言うことが本当にその顧客のためになるのか自分でも考えてみる必要がある。何でも言うことを聞くことが必ずしも顧客満足になるわけでもない。

顧客が何を求めているのか、どんな方法でするのを望んでいるのかを知り、そのとおりにすることだ。これが求めていること、望む方法だ。そのとおりにやってもらいたい。すべきことを、すべき方法でやってもらわなければならない。望むことを、望む方法で、必要な時に、その通りにやってもらうことだ。

ピーター・グレン、『⁠それは私の担当ではありません』

#55：少しでもましな負け方を

確かな設計書などが存在しない中での開発や評価テストは、多くの不具合を見逃したままで最後はバグ修正の大混乱状態に必ず陥る。このような結果になることが確実視されている場合に取るべき態度は、あきらめではなく被害を最小限にとどめようようとする意思と行動だ。少しでも根拠になりそうなものはすべて利用し尽くす必要がある。たとえば稼働中の旧システムのソースコード、旧システムのテスト成績書・市場障害票、旧システムの開発経験者などの人的知見など。もちろん精度の高いドキュメントの提供について、新規開発システムの仕様作成者および設計者などへ強く迫る必要がある。

懸命と賢明

懸命に働く、ではなくて、賢明に働く。

ロバート・キヨサキ

#56：共有分業と分離分業

分業とは一つの仕事を複数の人間や組織で分担分けして実行することだが、各担当間で情報共有を行いきちんと一つの仕事にまとめあげることを共有分業と言う。一方、情報共有もなく、各担当がバラバラに行動し、まとまった一つの仕事を完成できないやり方を分離分業と言う。時間がなかったからきちんとした仕事ができませんでしたという言い訳は通らない。時間が不足する前に時間を確保する方策がなぜ取れないのか。

開発フェイズのオーバーラップ

チームの自己組織的特性は一つの原動力、言い換えればリズムをつくる。チームのメンバーは異なった時間範囲に立ってプロジェクトを開始する。すなわちR＆D部門のメンバーは最も長期的な、また生産部門のメンバーはもっと短期的なリズムを考える。しかし、彼ら全員は、最終期限に間に合うよう、一人一人のペースを同期化し仕事をしなくてはならない。そのうえ、プロジェクト・チームは何の情報もないところから出発するが、各メンバーはすぐに市場や技術についての知識を共有することを始める。結果としてチームは、一つの単位として機能しだす。いくつかの点において、個人と全体が分けられなくなる。個人のリズムとグループのリズムが重なり合い、全体として新しい一つの脈動（パルス）をつくるのである。この脈動は推進力となり、そしてチームを前進させるのである。

野中郁次郎・竹内弘高、『⁠製品開発革新　ラグビー方式による新製品開発競争』

おわりに

単体テスト・結合テストにおいて提起された問題の原因は次のとおりです。

• 時間不足
• 時間・時期の同期不良、実行すべきタイミングの失敗
• 前工程の不良によるもの
• 不適切な実行内容に関するもの
• コミュニケーション不良、連携不足など

時間に関する最初の2つの合計は全体の半分以上を占めており、また要件定義工程・設計製造工程における大部分の問題も時間不足に起因しています。時間に起因する問題の総数は全体の約8割にも達しています。時間不足の三大元凶は、見積もりにおける必要時間の確保失敗、要求仕様の早期凍結失敗、および過去の失敗の繰り返しにあります。