（1） 開発期間6カ月程度のうち、最初の3カ月
UMLは高精度
開発作業従事者は15名程度でした。この段階のフェイズはUPにおける推敲フェイズに相当します。UPに従い、設計はユースケース駆動を採用し、顧客の要求をUMLで記述していきました。この段階は、UPという開発プロセスの基本に丁寧に沿ったプロジェクト運営でした。つまり、UMLの精度は高く、実装作業者の負担はかなり少ない状況でした。
この時点での成果物は、UMLの各図（ユースケース記述、シーケンス図、クラス図、ER図、業務フローを分析したフローチャート図）とフレームワークの一部でした。特にシーケンス図はほとんど実装レベルの詳細さで素晴らしい出来でした。なお、UMLの作成にはボーランドのTogetherを利用しました。
設計者はエース級の上級エンジニアばかりでした。もう一度同じ人材を集めるのは非常に難しいと思います。EJB（Enterprise JavaBeans）を実装できるほどのスキルを持つエンジニアの数は決して多くはありません。設計もデザインパターンを利用した非常に技術レベルの高いものでした。
さて、この段階で不思議なことが起こりました。15名程度のプロジェクト参加者のうち、特にアーキテクトを中心とする5名前後の人々が連日の徹夜残業を余儀なくされ始めたのです。プロジェクトは中盤に差し掛かっていました。残りの10人は18時ごろには帰り支度を始めていました。作業進ちょく管理表も少しずつ訂正が多くなり、誰の目から見ても予定より遅れ始めていました。このような状況でも、本当に働いている人は、不思議なことに数人でした。
このプロジェクトに何が起こったのか
このプロジェクトに何が起こったのでしょうか？ そして何が原因でこうした状況が起こったのでしょうか？ 完ぺきな設計と優秀な技術者、UMLで書かれた素晴らしい仕様書、フレームワーク（Struts、EJB）をはじめとした実装を支援する最新技術がそろっていました。このチームには何が足りなかったのでしょうか？ いままでの記述だけで、多くの方は気付いたかもしれません。「設計者が不足している」というのが当時のプロジェクト従事者の意見でした。確かにそうだったかもしれません。
しかし、本当の問題はこの段階で「完ぺきな設計」をするという態度にありました。プロジェクトの初期段階で一部のすきもない「完ぺきな設計」を行ったら何が起こるでしょうか？ 「設計」と「実装」が際限なく近づくという状況になるのです。つまり設計にかかる工数が実装なみに膨らんでしまうのです。
多くの現場ではマネージャ＜設計者＜実装者という人数比率になっています。確かに推敲フェイズは設計の負荷が重いフェイズですが、設計の精度を100％に近づけようとする試みは、そもそも「イテレーション」の意図（変化の許容）に反するのです。
UMLの有効性、初期の詳細設計の重要性とプロトタイプ（機能の一部）の動作までの詳細設計は、明らかにプロジェクトの効率を上げます。しかし、同時に実装者への「権限委譲」は実は非常に重要な要素なのです。それはしばしば「いいかげんな設計」として実現されますが、本当はそれこそ「良い加減」なのかもしれません。
この時点ではプロジェクトは「地獄」というほどではなくむしろ多くの実装者にとって「天国」でした。
（2） カットオーバー1カ月前
新規エンジニアの参入
この作成フェイズで設計段階の遅れを取り戻そうと、設計者の負荷が非常に高い状態になっていました。この時点でプロジェクトの進ちょくが大きな問題となり、大幅増員が決定しました。増員においては、テストを行いふるいに掛けたことなどが幸いし、質の高い技術者が集まりました。エンジニア各人のスキルレベルの高さは、プロジェクトへの参入障壁を下げたと思われます。
また、仕様や環境設定、ツール類の情報をWeb上で管理していたのも、プロジェクトの新規参入者が（プロジェクトに）スムーズに合流できた要因だと思いました（このプロジェクトではWikiを活用し、サーバのIP／ID／パスなどの情報や開発環境構築のための手順書を管理していました）。ユースケース記述もすべてWebに格納され、実装担当者がその都度、設計者に聞き直す必要がありませんでした。ユースケース記述を基にユースケース駆動での開発がスムーズに進められたのです。
その際に非常に興味深いのが、チームへの機能の割り振りを、機能の関連性や画面やエンティティの類似性によらず、緊急度の高いユースケースから順番に手の空いたチームに割り振ったことです。私はこの方針には反対でした。というのも、仕様的に近い機能は、同じチーム（や人）がまとめてやってしまった方が明らかに効率が良いからです。
実際、効率は若干落ちていたように思われます。しかし、意外な効果が得られました。どのチームも触れたことのない機能を突然割り振られることに慣れ、開発者全体で“広く浅く”システム全体の仕様が理解されるようになっていきました。そして、障害の発生時には「ほかのチームの担当分でも直せる」という現象を生み出したのです。
4〜5人のチームを1ユニットとし、計4ユニットが稼働している体制でした。さて、ここでユースケース駆動の大きな欠点の1つが洗い出されました。ユースケース駆動による開発作業では、ユースケース記述を書き並べたインデックスを基に作業を行っていきます。その記述1行1行がいわばストーリーカードのように各チームに配布されていくのです。
システム全体の姿が分からない
ある日、開発者の1人がこういいました。「システム全体の姿が分からない」。つまり、それぞれが関連性のないユースケースを、1行ずつこなしていく実装チームには、自分たちの作成しているユースケースがシステム全体の中でどのように流れているかが見えなくなっていったのです。細かく分割された「ユースケース・オブジェクト」を開発している開発者・設計者には木はともかく、森の姿が見えなくなっていったわけです。システム全体の姿が見えない開発作業は各チーム間の連携を急速に失わせ、結果として仕様を含む情報の伝達不足、共有すべき技術の非共有化を招いていきました。各チームのリーダーは自分のチームが担当するユースケースにしか興味がなくなっていきました。例えば、後続の機能に影響があるような修正を行っておきながら、ほかのチームには知らせなかったり……。
一方、この時点でも、設計者は詳細なシーケンス図の作成に追われていました。
森全体を管理する人はなく、いつまでたってもシステム全体の姿が見えてこない状況でした。しかし、このような大規模システムでは、森全体を管理する方が設計者にとっては重要な作業なのではないでしょうか。
この段階で、何とも不思議な問題が顧客と開発チームの間で取りざたされるようになりました。「仕様書がない」という問題です。前述のようにこのプロジェクトでは、UMLで非常に詳細な設計を行っています。数百万円ものUMLモデリングツールを活用し、クラス図、シーケンス図なども顧客に提示しています。ユースケース記述はWeb上で常に見ることができます。ではなぜ、「仕様書がない」という奇妙な問題が発生したのでしょうか。
理由は2つ考えられます。
第1の理由としては「画面仕様書がない」という点です。UMLでは画面仕様書を定義していません。しかし、実際の開発では、画面仕様書は非常に重要です。これがないために、顧客は仕様の追跡性を失ってしまい、結果的にシステム全体の姿を見失ってしまったのです。
第2の理由には「UMLが顧客向けでない」ということが挙げられます。実装作業を想定して英語で記述されたクラス図やシーケンス図は、顧客にはとても難読なシロモノでした。特にユースケース記述は非常に重要な仕様書であるにもかかわらず、テキスト中心であるために、顧客に読みにくさを印象付けてしまったのです。その結果、われわれが納品した仕様書を片手に、仕様書を要求されるという奇妙な事態になってしまったのです。
プロジェクトが地獄になり始めた
開発現場では、開発プロセスとは関係のない「よくある問題」もいくつか発生しました。例えば、テスト環境へ修正版をリリースするたびに基礎的なバグが大量発生しました。このことは顧客の（われわれに対する）信頼性の低下を招き始めました。なぜ、こんなことが起きたのでしょう。開発者も設計者も仕様変更やバグのおおよその影響範囲を短時間で想像できます。このことは逆に、テスト範囲を“効率化”させてしまいます。つまり、影響のありそうな範囲に焦点を当てたテストはきちんと行われるけれど、影響の薄そうな部分のテストを行う時間は削減されていってしまったのです。
もちろん、JunitやHttpUnitは「繰り返しテスト」を簡単に行うことができます。しかし、ビューの問題（画面デザインの崩壊）や開発者・設計者の意図しない問題には、そもそもカバーするようなテストコード・シナリオが用意されていない場合が多いのです。結局、仕様書を片手に、全機能をテストするテストチームが結成されることになりました。この専任テストチーム（4?5人）がこの混乱を収束させたことはいうまでもありません。
大幅増員を決めたことで分かるように、そのあたりから一気にプロジェクトは設計者だけでなく全員にとっての地獄となっていきました。経費的にも急速にふくらみ始めましたし、作業者への負荷は「設計の遅れ」を取り戻すべく異常な速度での実装を求められました。それはとりもなおさず、「28時までには仕上がります」という形でプロジェクト内を飛び交うようになったのです。
（3） カットオーバー直前からカットオーバー以降へ
仕様変更の連続
いよいよカットオーバーが見えてきましたが、「イテレーション」を標ぼうする多くの開発プロセスで発生しているのと同じ問題も発生していました。つまり、提案段階で訴えた「可変性」に基づく直前の仕様変更の連続です。延々と続く新たな仕様への対応は開発者のモチベーションを急速に奪っていきます。今回の「イテレーション」では、ほかの機能に影響のある比較的大きな修正も相次ぎました。この場合、該当する新機能や修正した機能を各チームで調整し、タイミングを合わせてリリースする必要がありました。その結果、プログラムの異なるバージョンが大量に発生しました。
この管理／運営にはCVSのブランチ機能が大変役に立ちました。ブランチ分けして、仕様変更や新機能を取り込んでいない「確実に動く検証可能なバージョン」と「新機能を取り込んだ調整中のバージョン」の共存により、ほかのチームへの影響を最小限にとどめることができました。CVSのおかげで比較的スムーズにバージョン管理ができたわけです。
ただし、ブランチ機能を活用する際、修正をバージョン双方に反映させる必要があるため、「自分のしている修正がどちらに反映されるべきか」を慎重に管理する必要があります。設計者は常に、どのような機能がそれぞれのバージョンに取り込まれつつあるかを監視する必要があります。
さて、この段階で「リリース時によく起こる問題」が発生してきました。主なものに、環境の違いによる障害対応があります。仮環境と本番環境でシステムの挙動が明らかに違う場合があることは当然です。その「誤差」をいかに修正するかというのが終盤に至って重要視される問題です。例えば、WebSphereにEJBを利用したシステムをリリースする場合はデプロイメントマネージャを利用するのが普通ですが、顧客の本番環境ではデプロイメントマネージャが利用されておらず、回避策などをベンダへ問い合わせて検討する必要がありました。致命的な問題であるにもかかわらず、ベンダや顧客のシステム運用部隊と協議し、調整をしなければいけない問題だったので非常に時間がかかりました。
テストデータを誤ってチームメンバーが削除してしまい、復旧に多くの工数を要したということもありました。カットオーバーした後で、開発サーバを引き上げるという話も出ました。結局は引き上げたのですが、そのダメージは意外と大きかったことをのべておきます。どういうことかというと、新しい開発サーバは複数のプロジェクトで共有するルート権限がなく、その都度依頼しなければならないために効率ダウンを引き起こしたのです。また、長い開発期間のうちに少しずつ効率化を促進するためのツールの導入や設定改良を行っていたのですが、それを一遍（いっぺん）に失ってしまったわけです。
別案件の到来
そして、この段階に至って、次々と別案件（別プロジェクト）が現れ始めました。これらの案件は現在進行中の開発環境に加わり、連携機能などを要求してきました。納期まで時間は限られています。現在作成している機能が“落ち着いて”から新たなプロジェクトを開始しようなどという悠長（ゆうちょう）なことはいっていられず、ほとんど並行開発のような状態で開発をしていました。
もちろん、この状況でもバージョン管理は有効な解決策だったのですが、これ以上に有効だったのは、全体のアーキテクチャを監視し、交通整理を行い、技術リスクを排除していくチームの存在でした。このチームは非常に高度な技術者で構成されており、それぞれが実際の設計者以上に大きな視点でプロジェクト全体を見ていました。彼らの存在は、移行フェイズでのシステム連携といった多くのリスクを取り除く非常に有効な要素でした。
完全に佳境に入ったプロジェクトは2日徹夜、3日徹夜の対応を作業者に求めました。机の上で眠り、3食を机の上でとるという、まさしく“開発現場の地獄”となったのです。
（4） プロジェクトの特徴を振り返る
一般的にこのプロジェクトは、コスト超過という要因から失敗プロジェクトと認識されています。しかし、私の目から見た限り、
- 納期に間に合った
- コードの品質は高い
- 技術的な再利用価値が顧客・開発者双方に残った
- 開発プロセス運用のノウハウが蓄積された
といったメリットを考慮すると、失敗プロジェクトと簡単に割り切るわけにはいきませんでした。最後に、このプロジェクトを構成する特徴的な要素を指摘して第1回をしめくくります。
- 完璧に近いシーケンス図は設計者の意図を正しく実装者に伝えることができるが、非常に設計コストがかかる
- プログラムの書き方や実装方法までを設計情報に埋め込む必要はない
- 仕様を顧客に理解してもらうためには、UMLの記述だけでは不十分
- 予算を高めに設定してでも、優秀な人材を確保すること。納期に間に合った要因の1つは優秀な人材の存在にある
- 全体的なコードレビューを行い、技術リスクを取り除く“フレームワークチーム”の存在は有効。彼らが最終的なコードの品質確保した
- 難しい技術（今回はEJB）を利用しても、技術者のスキルレベルが十分にあれば、特に効率を落とすことはない
- チームと機能を結びつけず、ユースケース単位で開発作業を進めた。その結果、開発者全体で“広く浅く”開発中の機能情報を共有できるようになったが、システムの全体的な流れを把握できなくなった
- 新しい技術を積極的に利用するのは、技術者のスキルレベルが高ければプロジェクトの成功につながるが、一般的にはプロジェクトの成否には関係ない
- CVSは非常に有効にプログラムの管理を行った
- 高額なUML設計ツールを用いたが、十分に有効であった
著者プロフィール
佐藤大輔
有限会社オープントーン社長。会社設立前から財閥系大手システム会社などで多くのシステム開発に主にマネージャーとして携わる。あくまで「現場主義」であり、自身含め社員全員が「本物の実装能力を持つ」がモットー。「案件完遂率100％」と「必ず新しい技術を織り込む」ことを前提とした技術集団を率いる。言語・フレームワーク・プロセス・ツール、あらゆるものをシラミ潰しに実際のプロジェクトに適用し、最適な開発を日夜探しつづける。今の使命は本稿などを通して、「実験結果」を社会にフィードバックし、「新技術や新発想」と「現場」の紐付けをしたいと考えている。
Copyright © ITmedia, Inc. All Rights Reserved.