第1回真・開発プロセス

2007.08.03

　「月刊Windows Developerマガジン」（翔泳社発行）の人気連載「降ればどしゃぶり」の筆者 だいだひろ氏がITpro Developmentに登場。システム開発の現場で起こっている暗黒面に容赦なく光りをあて，教訓と改善のきっかけをもたらす！（と思う）。

　はじめまして。だいだひろです。突然ですが，私は性格が悪い。どのくらい悪いか？アメリカで「コンピュータのような先端技術は，優秀な白人じゃなきゃできない」と言っていた白人女性に対して，「われわれ日本人は天皇を神と信じていたが，進化論裁判はやらなかった。あんたたちは？」と質問するくらい，悪い。要するに「相手が触れてもらいたくない事実をあぶりだして恥をかかせる性格」と考えてもらえれば，私の性格の理解として間違いはない。

　今回のコラムではこの性格の悪さを思う存分発揮したい。なぜか？皆さんがシステム開発の現場で直面しているIT業界の負の連鎖は，誰かがそれを見つけて声に出して言わないといつまでも変わらないからだ。

　私の業務は，コアダンプの解析など主にトラブル・シューティングなのだ。その経験からトラブルの現場での悲喜劇を良く見てきた。一番印象的なのは，時代を経てもそのトラブルは見え方が違うだけで原因はほとんど変わっていないことだ。これは現場が何も進化していないことを意味している。進化しない原因は，トラブルの責任者探しを恐れるプロジェクト・メンバーがトラブルが解決すると忘れ去る方向に雰囲気を持って行き，再発防止策を真剣に検討しないからだ。

　ここで取り上げる出来事は，多少デフォルメしているがすべて真実である。それらに対して「クスッ」と笑えるネタとわずかばかりの教訓を示したい。本コラムが現場の皆様のガス抜きに役立つと同時に，多少なりとも改善のきっかけにつながれば望外の幸せである。

　初回である今回は，プロジェクトでの作業量を左右する開発プロセスを取り上げたい。開発現場には，理念だけはすばらしいが運用がへんてこな開発プロセスがまん延しており，多くの開発者が被害を被っている。ここを改善するだけで結構な効率アップにつながると思うので，開発プロセスは現場でどのように腐っていくのかを説明したい。

エッシャーのだまし絵プロセス

　まずは大規模プロジェクトの話。そのプロジェクトは，私が会社に入って参加した中でも一，二を争う巨大さだった。このプロジェクトの主管となったベンダーは，独自に定義したタスクフローを持ち，プロジェクトではその流れに沿って開発することになっていた。そのプロセスは典型的なウォーターフォール型で，「さすが大規模システム」と感心した…のも束の間，すぐに綻びが見え始めた。

　ウォーターフォールを理解している人はわかっていると思うが，このプロセスでは決められたマイルストンに従って成果物をFix（フィックス）する。そして，成果物が発注先の意向にあっていることを確認してから，次の工程へと進む。

　ところが，このプロジェクトでは締め切りが優先され，たとえ終わっていなくてもなぜか次の工程へとサクサク進んでいった。「そんなのお客様が許さない」と思ったあなた，あまいあまい。システム開発が何たるかを知らないお客様（ベンダー社員も知っているとは言い難いが）に「スケジュールより遅い！」と脅されれば，事の重大さを理解してないベンダー社員は，何もFixしないで先に進めているのが現実なのだ。

　ベンダー社員も，システムで実行すべき業務の洗い出しを優先して要件を洗い出し，詳細な詰めは後回し，と頭を使って対応してもらいたいものだ。要件を把握すればある程度正確な見積りもできるのに，それをやらずに適当に見積もった上に，お客様の要望をすべて受けてしまうから誤差はストレートに赤字になる。

　その結果，システム要件の肥大化と同時に，後になるほど多くの業務漏れが見つかるのでプロジェクトが進めば進むほど当初の見積もりと離れていく。もちろん，赤字になるほうに。これでうまくいけば不思議だが，そんなわけないのがこの業界。

　私が担当したところで言うと，営業支援部分の開発で，営業結果のデータベースへの登録と管理者によるレポーティングくらいだったのが，やれ“指定期間のランキングをつけたい”とか“指定地域別の成績を見たい”とか，どんどん仕様が増加していった。プログラム・ロジックで対処できる部分はまだ我慢もするが，データベースのカラム変更が必要な仕様追加は，個人の力では解決できないので始末が悪い。