エンジニアは日々現場で学ぶ
開発現場で学べること
最終回（第10回）　プロジェクトが失敗する不吉な匂いとは

クロノス 山野寛
2004/11/2

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

■プロジェクトが終了へ

　1年以上続いたこのプロジェクト（「第1回　忙しいのはユーザーだ」を参照）も、ようやくカットオーバーを迎えることができた。今回の開発では、何度となく苦難やトラブルがあったが、いま考えるとすべてがよい経験になったように思う。そしてこの連載も今回が最終回である。いままでこの連載を読んでいただいた読者の中には、われわれのプロジェクトが最終的にどのような終わりを迎えるのかと興味をお持ちの方もいらっしゃるのではないだろうか。であれば安心していただきたい。「プロジェクトは成功した」のだ。

　ここ数年でシステム開発に関する技術は急速に進化し、開発を成功させるための多種多様な方法論も唱えられてきた。しかし、それでもプロジェクトが失敗に終わったと耳にすることは案外多いように思う。そんな中で、われわれのプロジェクトが無事に成功を収めたことはとても誇らしいことであると筆者も胸を張っている。そして、われわれはこれに満足せずに、今後も今回のプロジェクトから学んだ教訓を生かし、さらに品質の高い、クライアントに満足してもらえるようなシステム作りを心掛けていくつもりだ。

■プロジェクトの成功に必要なもの

　プロジェクトが成功するために一番必要なものはいったい何なのだろうか。この問いに対しては、読者の皆さんもさまざまな意見をお持ちだと思う。当然プロジェクトを成功に導くために必要なものはたくさんあるだろう。しかし、もしここで筆者がたった1つだけ挙げるとすれば、それは

「一番重要なのは『危険察知』である」

ということである。

　システム開発ではよく「コミュニケーション」や「要求管理」が重要だといわれる。しかしそれらも結局は「危機察知」につながると筆者は考えている。プロジェクトを失敗へと導いてしまう多くの原因は、「そんなの知らなかった」とか「やってくれていると思っていた」といった思い込みから発生するトラブルが原因となることが多い。そういった思い込みから発生するトラブルを事前に察知することが重要だ。これはつまり、危険察知をするために、われわれには多くのコミュニケーションや、確実な要求管理が必要とされているのだ。

　かのマーチン・ファウラー氏は著書『リファクタリング』（ピアソン・エデュケーション刊）の中で、失敗を招く恐れのあるプログラムコードを「不吉な匂い」（Bad Smells in Code）と表現している。ファウラー氏はプログラムコード中にこの不吉な匂いを感じた場合、その対処法としてリファクタリングを実施するように勧めている。私はこの不吉な匂いという表現はシステム開発全体にも適用できるのではないかと考えている。つまり、開発中にプロジェクトを失敗に導く不吉な匂いを感じた場合は、その改善策を早い段階で検討し、実施することが必要なのではないかということである。

　そこで最終回となる今回は、われわれが経験したプロジェクトを失敗へと導くかもしれない不吉な匂いについて、いままでの連載の内容も踏まえたうえで読者の皆さんへお伝えしたいと思う。

■プロジェクトの不吉な匂い

　筆者の考えるプロジェクトの不吉な匂いは次の10パターンである。

（1）優し過ぎるクライアント
（2）不明りょうな非機能要件
（3）神の不在
（4）暗黙知の群れ
（5）収束しない会議
（6）最新技術への猛進
（7）パターンの乱発
（8）怠け者エンジニア
（9）無駄の山
（10）笑わないプロジェクトマネージャ

　次に、それぞれ詳しく解説しよう。

（1）優し過ぎるクライアント

　今回のプロジェクトのクライアントは「第1回　忙しいのはユーザーだ」でもお話ししたように、非常に厳しい人が多かった。われわれも開発中に幾度となくお叱りをうけたものだ。しかし、むしろそうやって厳しいからこそ、われわれ開発者側も妥協することなく、その期待に応えられるように頑張ることができたのも間違いのない事実である。また、長期にわたるプロジェクトともなれば、開発メンバーのモチベーションは徐々に下がってしまい、ちょっとしたことに手を抜いたり、簡単に妥協してしまうことで、失敗やトラブルを招いてしまうことも少なくない。今回のようにわれわれの開発への姿勢に対して注意を促してくれるクライアントであれば、後々になって「こうしてほしかったのに」といったような仕様変更も防いでくれるのだ。

　逆に優し過ぎるクライアントの場合、後々になっての仕様変更も多く、開発者側も甘い考えで開発を進めてしまいがちであろう。こういったクライアントが優し過ぎると感じた場合は、ぜひ気を付けてほしい。気付かないところで、気付かない形で、気付かないうちにトラブルになっている可能性があるからだ。

（2）不明りょうな非機能要件

　パフォーマンス制約などの非機能要件は開発途中で意外と軽視されがちだが、機能要件と同等であるという意識は非常に重要である。「第6回　開発存続の危機で分かったSEに必要なスキル」にあったように、後々になって非機能要件を満たしていないことが発見されるとシステムそのものが使い物にならず、結果として失敗に終わってしまうこともある。

　不明りょうな非機能要件というのは、要求分析、もしくは基本設計の段階でクライアントと開発者側で具体的なアグリーメントを行っておく必要があるという意味も含んでいるが、むしろ開発途上で非機能要件を強く意識しておくことの方が大事である。具体的には設計時点でパフォーマンスを意識しておくこと、単体・結合テストにパフォーマンスを確認するテストケースを盛り込むこと、パフォーマンスが出ないことが判明した場合は早い段階でプロファイリングを実施して原因を追究し、改善しておく、といったことが主な対応策である。

（3）神の不在

われわれのプロジェクトには「第2回　スーパーコンサルタントはここが違う！」で紹介したコンサルタントのA氏がいた。A氏は幅広く高度な知識を持ち、かつ温和で実直な対応をしてくれることから、われわれは「A氏の声は天の声だ」という気持ちを持っていたのだ。A氏が「できると思いますよ」と一声いうだけで、本当にできる気になったものである。このように、何かに卓越したメンバーが開発に1人でもいると、ほかのメンバーのモチベーションが向上し、プロジェクトの成功の確率が高くなる。

　逆に卓越した存在がいないプロジェクトでは、判断が優柔不断になりがちで、開発の方向性を見失うこともあるかもしれない。プロジェクトチーム内に、神のような存在、成功しそうだと思わせてくれるような人材が1人はほしいものである。

（4）暗黙知の群れ

　プロジェクトには誰かが知っているけど、明文化されていない重要な情報が至るところに転がっている。読者の中に、次のようなエピソードに共感できる人はする方はいらっしゃらないだろうか。

　ある日、突然アプリケーションがうまく起動しなくなった。各種調査をしたが、なかなか原因を特定できず、無駄に時間が過ぎていく。仕方なくほかのエンジニアに発生した不具合を話したところ、彼は先日全エンジニアが共通で使用しているサーバ環境を変更したことが原因だろう、というのだ。彼いわく、ちょっとした変更だったために、ほかには影響がなく、たとえ不具合があったとしてもすぐに原因に気付くだろうと勝手に思い込んでいたらしい。

　こうした1人の勝手な思い込みによる行動によって、ほかのエンジニアの貴重な時間を奪うこともある。このトラブルは、サーバの環境を変更したことを明文化して報告していなかったことが最大の原因である。たとえちょっとした変更であっても、電子メールで全員に知らせたり、シートに変更履歴を記録したりして、形式知にしておくべきである。もしもこうしたことが1回でも発生した現場では、それ以外の暗黙知が群れているかもしれない。決してそのままにしておかず、確実に明文化する仕組みを導入してほしい。

（5）収束しない会議

　われわれは要求定義の段階で、コンサルタントのA氏から次のようなことをいわれた。

　「問題解決を行う打ち合わせでは『発散・収束・決定』でスケジュールを立てましょう」

　つまり、1つの問題に対する打ち合わせに対して、1日目はみんなでいいたいことをすべて出し尽くす「発散の日」、2日目は発散した内容をある程度まとめて結論を導く準備をする「収束の日」、そして3日目は収束した内容から最も適した結論を導き出し、それを答えとする「決定の日」にする、といったように、この3段階をどの時点で行うかを明確にしてスケジューリングしましょうということである。

　このようなルール化により、今日は何をする日であるのかを明確にでき、まとまりのよい進行を行えるのが一番のメリットである。その段階を踏まえずにただ発散だけを延々と続けていくのは時間の無駄であるし、よい結果は生まれにくい。さらには、結論だと思っていたものが、発散をし尽くせなかったことによって、あとで大きな失敗を招く可能性だってあるだろう。そのような打ち合わせがプロジェクト内で行われているのであれば、この3段階を意識しながら進めてみてほしい。

（6）最新技術への猛進

「第3回　システム開発の真の目的を見失わない」でも触れたとおり、開発者が自己満足のために最新技術を導入して失敗するシステム開発は非常に多い。特に「オブジェクト指向は再利用性が高い」という文言だけを信じ、柔軟な分析・設計手法や再利用するための技を知らずに、オブジェクト指向開発を導入している現場は後を絶たないようだ。その結果、無駄に複雑で保守が困難なシステムになってしまうことがある。こうならないように気を付けなければならない。

　「最新技術を使用する＝成功プロジェクト」という図式が成り立たないことを念頭に置くべきである。もし現場で無駄に最新技術に突っ走ろうとするエンジニアを見掛けたら、その本質と目的を見極めて、不必要だと感じればぜひ異論を唱えてほしい。

（7）パターンの乱発

　現在のシステム開発では、開発のパターン集は必需品である。例えば分析に用いるアナリシスパターン、アーキテクチャ設計に用いるJ2EEパターン、プログラム設計に用いるデザインパターンなどがそうである。これらは再利用性の向上などによって開発効率を上げる一方で、不適切な個所でむやみに使用すれば、逆にデバッグが困難になったり、メンテナンス性を損ねたりする可能性も秘めている。設計者の自己満足でパターンを使用していないか、注意を払っておいてほしい。

（8）怠け者エンジニア

　リファクタリングの不吉な匂いに「怠け者クラス」というものがあるが、それとは意味合いは異なる。怠け者エンジニアという言葉には、目の前にやらなければならないことがあるにもかかわらず、明日やればよいという思想を表している。

　システム開発において面倒なことを後回しにしておくと、後々になって取り返しがつかなくなることは往々にしてある。「少し不安だけど、面倒くさいから後でもいいや」という気持ちは、おのずとプロジェクトを失敗に陥れると考えた方がよい。早い段階で不安なことはできるだけつぶしておくのがプロジェクトを成功させる秘けつの1つである。怠け者エンジニアを見掛けたら、ぜひその危険性を説き、背中を押してあげてほしい。

（9）無駄の山

「第5回　開発のトラブルは必然」では、われわれがテストの自動化を図ることによって、工数の削減に成功したことを紹介した。テストにかかわらず、システム開発には自動化可能な「無駄」な作業が山ほどある。これらは「第9回　仕事ができ、周囲から評価されるエンジニア」でも紹介したように、想像力と応用力を用いて自動化することで、かなりの工数を削減できることが多い。雑用作業が多く発生して工数が圧迫されてしまっている場合は、多少の見直し工数を設けてでも、自動化や作業効率向上を図ることをお勧めする。

（10）笑わないプロジェクトマネージャ

　プロジェクトマネージャ（PM）はプロジェクトのムードメーカーでもあると筆者は考えている。メンバーと一緒に考え、笑い、そして叱咤激励する、そんな人間味豊かで楽しいPMが率いる開発現場は成功に導かれることが多いだろう。時には笑いを提供し、活発にコミュニケーションを取るようなPMがいれば、メンバーのモチベーションが上がり、いざというときに踏ん張る力を発揮できるものだ。今回の開発のPMはわれわれ開発メンバー全員に気を配り、常に明るく振る舞う一方で、叱るときは叱るといった、非常に人間味豊かな人であった。今回のプロジェクトが成功した理由も、そんなPMの存在が非常に大きいと感じている。もし現場のPMがそうした部分に無頓着な人（つまり笑わないプロジェクトマネージャ）であれば、あなたがその役割を買ってでてほしい。チームに明るさをもたらす存在というのは何にも替え難い重要なファクターなのだ。

　上記以外にも失敗を予感させる不吉な匂いを感じておられる読者の方は多いだろう。ぜひそれに対して適切な行動で対処し、成功プロジェクトをつくり上げてほしい。

■プロジェクトスクーリング終了

　このプロジェクトにかかわって約1年、投げ出したくなるような苦しい時期を何度も経験した。しかし、それらすべてが今後の糧となり、次のプロジェクトを再び成功させるための布石となると期待している。多くの素晴らしいクライアントとエンジニアに囲まれて、筆者の経験の中の大きな一歩として今後の人生においても非常に有用な開発であったように思う。

　最後に、本連載が少しでも読者の皆さんの力となり、知恵となってくれることを期待して、この「プロジェクトスクーリング」を終了したいと思う。長い間お付き合いいただき、誠にありがとうございました。

筆者プロフィール

山野寛（やまのひろし）●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント／サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。