真のボトルネックは“顧客”なのか？：開発現場の天国と地獄（2）（2/2 ページ）

[佐藤大輔（オープントーン），＠IT]

MVCによる分業と相互不干渉の効率性

　システム開発者にとって、「システム」という言葉が表す領域はどんどん広くなっています。OSやネットワークに始まり、サーバ、ミドルウェア、データベースなどカバーしなければならない領域は非常に広大です。どの部分が欠けてもシステムは動きません。

　通常、それぞれの分野（サーバ、ミドルウェア、データベース……）には「コアテク（コア・テクノロジ）」の領域があり、その分野の達人とも呼ばれるエンジニアが存在します。しかし、複数の領域の「コアテク」を極める「スーパーSE」はめったにいません。スーパーSEを養成するよりも、各分野のスペシャリストを育てる方が現実的です。それぞれの分野でそれぞれのスタッフが得意なタスクを担当することで、複雑かつ広範囲に渡るソフトウェア開発の作業を効率的に進めることができるのです。

　MVCは、このような「適材適所」の考え方と非常に相性が良く、併用することによって効率を飛躍的に伸ばす効果を持っています。WebシステムのMVCは、View層のHTMLやJavaScriptにたけた「ビュー作業者」とロジックの作成やフレームワークそのものの構築にたけた「コントロール作業者」、データベースや論理モデルの作成にたけた「モデル作業者」……といったように分かれています。これらの分類を分かりやすくいうと、「画面を作る人（ビュー作業者）」「動きを作りロジックを実装する人（コントロール作業者）」「論理を考える人（モデル作業者）」というような区分けになります。では、得意分野に特化し、互いの作業の影響を抑えることで、どんなメリットが生じるのでしょうか

　Viewの部分は顧客のこだわりが強く、最後の最後まで訂正が入りやすい部分です。ゆえに、Viewをほかの作業と切り離すことにより、頻繁（ひんぱん）に起こる「画面の調整」レベルの修正がView担当者の領域に限定され、チーム全体が「仕様変更」の影響を受けにくくなります。MCのレベルのテストはViewを考慮せず、（画面上必要な内容が）何もレイアウトされずに表示される状態で行います。顧客には、一見何もできていないようにみえるのですが、この画面は開発者にいわせるとほぼ完成しているのです。このような状態でView担当者に作業を割り振ります。結果的にMC担当者は、自分の得意な「ロジック作り」に能力や資源を投入できます。モデル部はモックでカバーし、動きだけをどんどん作っていきます。コントロール部の作業者はロジックの「仕様確定」を待つ必要がなく作業を進めていきます。

　なお、MVCの作業にとてもよくマッチするツールにCVS（Concurrent Versions System）とコミットメールがあります。通常、作業者がお互いにお互いの都合を気にしなくなると、作業進捗の同期が取りにくくなります。その問題を防いでくれるのがコミットメールです。たとえパートナーが休みでも、後でメールをみるとパートナーがどんな修正を加え、何をUPしたかが一目瞭然で分かります。自宅からでも修正にクレームをつけたり、場合によっては修正をロールバックすることもできます。CVSはモジュールの変更管理を行うのに有効なツールとしてとても人気があります。

高効率化の新たなボトルネック

　開発が効率よく進むに従って、思わぬところで問題が起きました。「顧客が忙し過ぎる」ということです。画面は画面で、動きは動きで、ロジックはロジックで、作業はどんどん進んでいきます。この並行作業は顧客に大量の仕様の確認や策定を求める結果となりました。つまり、効率の良い開発は急速・大量の作業を顧客に求めるのです。実装作業が効率化されるにつれ、「顧客の効率」という新たな要素が開発作業のボトルネックとなっているようです。最もつらいのは顧客なのかもしれません。実装作業者の労働時間もかなりの超過でしたが、顧客の労働時間はさらにハードでした。

（3） カットオーバー直前からカットオーバーへ

プレス発表の都合上基本的な機能を優先的に提供

　この案件は開発側が明示的にカットオーバーをコミットする前に「プレス発表」によってリリース日がすでに定められていました。そのため、開発の遅延は許されませんでした。しかし、ごく一般的なプロジェクトと同様、このプロジェクトも度重なる仕様変更によって徐々にスケジュールは厳しくなっていきました。当初は作業者のモチベーションと作業効率の高さでスケジュールの負荷を吸収していましたが、結局リリース日に間に合う可能性が低くなったため、管理系の機能を切り離してリリースすることにしました（当分の間、管理系の機能は運用でカバーすることにしました）。

　スケジュールが厳しくなるにつれ、当然のように作業時間は「地獄の局面」へと突入していきます。それでも依然としてモチベーションは高いため、スケジュールの「地獄ぶり」に苦情を訴える作業者はほとんどいませんでした。決して「天国」プロジェクトとはいい難いのですが、チーム全体のモチベーションの高さゆえに、作業者自身に「地獄」といわせるようなプロジェクトではなかったのです。

真の「成功」プロジェクトとは

　このようなプロジェクトと出会うたびに、「本当に失敗したプロジェクト」とはどんなプロジェクトなのかを考えさせられます。余談ですが、プロジェクトルームは非常ににぎやかでした。おそらく多くの会社では「うるさい」と怒られるたぐいであったといえます。しかし、このにぎやかさ（活気というべきでしょうか）は、モチベーションを保つ1つの大きな要因であったのは確かです。たとえ顧客相手でも思ったことを自由にいえる環境でした。時には怒鳴り合うこともありましたが、基本的には多くの冗談に囲まれて着々と作業を進めていきました。

　モチベーションの維持は今回のプロジェクトを成功に導いた“勝因”ですが、まさにこのような環境があってこそ、チームのモチベーションが最後まで保たれたのだと思います。いいものを作りたいという開発側の気持ちといいサービスを提供したいと思う顧客の気持ちがしっかりとリンクしたプロジェクトでした。

　度重なる仕様変更を工数の増大やスケジュールの遅延というマイナス面で捉えるのではなく、「その仕様変更で誰が幸せになれるか」というプラス思考で乗り切っていきました。確かにスケジュールを守ることはできなかったのですが、結果として非常に高い顧客満足度を得たことは事実でした。

このプロジェクトの教訓！！

• 顧客がプロジェクトにどれだけ深く関与するかが成功のカギを握る（プロジェクト期間が短いほど顧客への負担は増大する）
• 仕様を実装する方法を顧客に説明できるプロジェクトは安心である（あるいは実装できない理由を率直に説明できるプロジェクトは安心である）
• MVCモデルにおいて、V（View）とMC（ModelとControl）は離してチームを構成するとよい
• 小さいプロジェクトのPMはスーパーマンでなければならない
• モチベーションの維持は、そのプロジェクトが「本物の地獄プロジェクト」かどうかを判断する基準となる
• 必ずしも「仕様変更＝モチベーション低下」とはならない
• MVCのチーム構成にCVSとコミットメールはとても役に立つ