みなさん、こんにちは。
手戻りばっかりで困るんだよね～。納期は遅れるし赤字は膨らむしメンバーのモチベーションも下がるし…― こんなボヤキがあちこちから聞こえてきます。 私たちは様々なお客様とお付き合いさせていただく中で「開発プロジェクトの手戻りをなくすにはどうしたらよいのか？うまくやっている会社はどういうやりかたをしているのか教えてほしい。」といったご要望をいただくことが日増しに増えています。 そこで今回は、そのようなご要望にお応えすべく、私たちが取り組んでいる方法について【特別に】お話ししたいと思います。
手戻りが起こした悲劇
上場企業であるSierのＡ社は、某大手企業から基幹システムのリニューアル開発を受託しました。同社は旧システムの開発経験があったため設計書を焼き直ししただけで単純に機能単位に分け、複数の開発ベンダーに発注しました。 ところが、納入された単体テスト済のモジュールを受入検査したところ、品質が軒並み劣悪であることが発覚。その後、テスト要員を大量投入して単体テストをやり直すことにより品質確保を試みましたが、一向に品質が向上しないまま時間切れとなり結合テストに突入することになりました。 当然、単体レベルの不具合が多発してテストが阻害され、結合テストがストップしてしまったのは言うまでもありません。結局、それ以降何度も同じことを繰り返した挙句、最終的には多額の赤字を計上してプロジェクトは頓挫してしまったのです。
手戻りは宿命なのか
上記の例は「単体テストのやり直し」が発生したものですが、このような作業の手戻りはIT開発の世界において『宿命』ともいうべきものであり、どうしようもないものなのでしょうか？誰がどう頑張ってもなくせないものなのでしょうか？ この苦い経験を通して私たちも非常に考えさせられました。完全になくすというのは無理かもしれませんが、極力少なくすることはできるはずです。宿命と諦めてしまう前に、敵をよく分析してみることからはじめましょう。
手戻り発生２つのパターン
まず真っ先に思い浮かぶのが「顧客のニーズが変わった」ことによって、せっかく決まっていたことが覆され、それまでやってきたことが無に帰するというパターンです。もちろん顧客側の思い付きや気まぐれというケースもありますが、多くの場合、世の中が変わる・法律が変わることに伴う要求の変化です。―ゆく河の流れは絶えずして、しかももとの水にあらず―とは方丈記の冒頭の一節ですが、まさに言い得て妙です。 もうひとつは「顧客のニーズは変わっていない」にもかかわらず、開発プロジェクト側の見積もりの甘さや考慮不足によって内部的に矛盾が起こり、仕様変更を余儀なくされるパターンです。これはもう自爆というか自滅というか…因果応報というより他ありません。
考えろ！考えるな！
ここまで考えれば、２つのパターンのどちらを防ぐ努力をすべきか自然とわかりますよね？ そうです。言うまでもなく後者です！自分で自分の首を絞めないようにすることです。 世の中の移り変わりや顧客要望の変化をコントロールすることはできませんし、それに対して不平不満をぶつけても何の解決にもなりません。自分たちの努力で制御し改善できることに頭を使い力を注ぐべきです。 かの松岡修造氏もこう言っています。「考えろ！考えるな！」と。つまり自分の力でどうにもできないことはくよくよ考えても仕方ない。自分の力でできることだけを必死に考えろ、ということです。
手戻りを回避する秘策はこれだ！
結論から申しますと、開発のプロセス全体を大きく見直す必要があるのです。基本設計・詳細設計といった工程ごとに品質を確保する努力はもちろんのこと、常に将来のことを考えて動くということがポイントです。某女子高の校訓でありませんが「先を見て齊（ととの）える」の精神です。 このコラムのテーマである「テスト／検証」とどういう関わりがあるのかと疑問に思われる向きもあるかもしれませんので、一言だけ申し上げておきます。『テスト目前になってテストのことを考えていたのでは遅い』ということです。
そこで、私たちは手戻りを少なくするための開発プロセスについてご説明するための簡単な資料を作成しました。 ご興味がおありの方は＜こちら＞からダウンロードしてください。少しでもお役に立つことができれば幸いです。
ご愛読、ありがとうございました。