失敗事例から考える「成功する開発チームの3つの特徴」：明日の開発カンファレンス2019

【失敗事例1】当初の合意が覆り「リリース延期」、両社想定以上のコスト増

　1つ目は「当初の合意が覆るパターン」だ。このプロジェクトは、ある企業の業務システムのリニューアル案件だった。開発プロセスには、顧客からの要望もありスクラムを採用した。

　開発チームは、日本とベトナムのメンバーによって構成された。複数拠点をまたがる大規模なチームでのスクラム実践は、モンスター・ラボにとってもチャレンジだったそうだが、チームビルディングの段階からさまざまな配慮を行い、良いチームワークの中で進めることができていたという。しかし、結果的にこのプロジェクトは、大幅なリリース延期と、両社ともに想定を超えたコスト増となってしまった。

　その最大の原因について、宇野氏は「開発側とプロジェクトの決裁権者およびステークホルダーとの間で、開発状況やゴールなどがうまく共有されていなかった」と分析する。このプロジェクトでは、「開発中に顧客から出される追加要望には、初期段階で実装を予定していた機能をドロップすることで対応していく」という合意ができているはずだった。しかし結果としては、ドロップを決定した機能が必須機能であり、ドロップできないことが後になって判明。さらに、顧客側のステークホルダーには開発の状況が共有されていなかったため、次々と追加要求が出され、大幅な納期遅延につながってしまったという。

　「仕事として開発を行う上で、QCDS（Quality、Cost、Delivery、Scope）のコントロールが重要なのは当たり前。加えて、スコープコントロールも、ローンチ後のビジネス展開を考える上で極めて重要。現実にはQCDSはトレードオフになるのが一般的だ。であれば、これらの状況を決裁権者も含めて共有し、検討できる体制が必要だった。このプロジェクトでは、開発側のチーム作りには配慮した一方で、顧客側の意思決定者、ステークホルダーまでを巻き込んだチーム編成ができていなかったことが、問題につながってしまった」

【失敗事例2】要求追加による計画変更繰り返し、開発手法の選択ミスで現場が「カオス化」

　失敗プロジェクトの2つ目として、宇野氏が挙げたのが「要求追加による計画変更繰り返しパターン」だ。これは、ある企業が立ち上げる新規サービスを対象に、スマートデバイス向けのアプリとサービスを開発するというプロジェクト。将来の拡張プランも検討されている壮大な計画だった。

　モンスター・ラボ側では、日本と海外の拠点で開発チームを編成。開発プロセスとしては、最初の段階でUXデザインとサービス設計を行い、コンセプトと仕様が固まった段階でシステム設計、開発、最終的なテストと順を追って進めていく、典型的なウオーターフォール型を採用した。

　典型的なパターンの受託案件として、滞りなくプロジェクトは進んでいくとみられていたが、途中から雲行きが一変してしまう。

　発注元のビジネスオーナーは、ビジネスに対する知見が豊富なアイデアマン。開発が始まってからも、他社の動向などを逐一チェックし、新たな要求が追加される。「より良いサービスを作るためのアイデアを多く頂けるのは良いこと」としつつも、まずは初期の計画に合わせたものをリリースし、ユーザーの反応を得ながら改善していくことを勧めるが、ビジネスオーナーは「競合を超えるためには、スタート時から圧倒的な差別化が必要」と譲らない。こうなると、発注元のニーズに応えるためには、進んでいる開発をいったんストップし、再度上流から仕様を固め直す必要が出てくる。

　こうしたやりとりが何度か繰り返されるうちに、チーム内の情報ラインは錯綜（さくそう）。さらに、拠点の開発者に指示を出すコミュニケーターに調整の負荷が集中し、完全なボトルネックとなってしまった。

　「このプロジェクトでは、初期段階で検討したサービスのコンセプトやターゲットに対する見直しが必要になったことで、開発中に根本的な部分での変更が発生してしまった。こうした状況が想定される場合には、開発側にも変化を前提とした体制が必要だった。つまり、このプロジェクトは、そもそもウオーターフォールでやってはいけなかった」

　宇野氏は、「スクラムはあくまで一つの方法論」としつつ、このケースでは、受注者、発注者を問わず「それぞれの役割がしっかりと定義されており、全員がそれを認識している」体制作りが必要だったとする。

　「エンジニアと要求元の心理的な距離をできるだけ近くすると同時に、クライアントを含めたそれぞれの役割が適切に定義された1つのチームを作っていくことで、そうしたクライアントの要求にも対応していくことができたはず」

【成功事例】「ハッピープロジェクト」となった3つの要因

　宇野氏が紹介した3つ目のプロジェクトは、改善サイクルを繰り返すことによって、チームの育成とクライアントの要求を満たすことの両方がうまくいった「成功パターン」だ。このプロジェクトは、一般ユーザーと専門家のマッチングプラットフォームの構築案件であり、モンスター・ラボ側では要件整理やデザインから、システム設計、実装までを一貫して担当した。開発は、日本とベトナム（ハノイ）のメンバーによる共同で進められ、手法としてはスクラムを採用した。

　このプロジェクトは最終的に成功を収め、クライアントの担当者からも「関われて楽しかった」「今までで一番チーム感のあるプロジェクトだった」「リリース後の成果も出ている」と感謝のメールを受け取るほどに、高く評価されたという。また、ベトナムの開発チームの間でも「ハッピープロジェクト」と呼ばれ、リリース後にも「あのプロジェクトに戻りたい」との声が上がるほど、うまく進めることができたそうだ。

　一方で、開発中の仕様変更なども多く、決して容易ではないプロジェクトでもあったというが、宇野氏は成功の要因として「スクラムでプロジェクトを進め、早期、かつ頻繁にPDCAを回すことができた」「Web開発の知見がある発注側の担当者が、プロジェクトに積極的に参加してコミュニケーションし、経営側への説明と承認を行ってくれた」「メンバーが、それぞれのスキルに合った役割を果たすことができた」の3つを挙げた。

プロジェクトを成功に導くチームが備える「3つの特徴」

　宇野氏は最後に、紹介した3つの事例を基に、成功する開発チームが備える特徴として、下記3つを挙げた。

　これを実現していくためには、マネジメント側に「組織戦略」、採用や育成といった「人材戦略」「モチベーションマネジメント」といった視点が求められる。これは、個別のプロジェクトだけではなく、企業全体の運営にも通じる課題だろう。さらに、受注側には「ビジネスやサービスを成功させたいという思いで、プロジェクトに主体的に関わること」が、発注側には「サービスを成功させるチームを作る意志を持つこと」が必要条件であるとし、「受発注の立場にかかわらず、共通のゴールを目指すチームを作ることができるか」が、プロジェクトの成否を分ける重要なポイントになるという。

　「プロジェクトの成功や失敗の原因は多様で、今回考えた『成功要因』は、残念ながら『これさえやっていれば、必ず成功する』というものではない。しかし、このようなチーム作りを土台としてこそ、その上で多様な開発方法論が生きるのではないか。私自身も、今回の振り返りをきっかけに、人を大事にしながら、彼らが働く場をどのように作っていけるかについて、考え続けていきたい」