開発がわからないでは済まされない時代！ 経営層や事業責任者が知っておくべき開発手法の見極め方

1つ目の条件は、チームそのものについてです。

アジャイル開発は、

1. エンジニアやデザイナーがプロダクトオーナーの「実現したいこと」をヒアリング
2. 実際にプロトタイプを作る
3. 確認とフィードバックを繰り返す
4. プロダクトを完成させる

というプロセスを踏んで開発を進めていく手法です。

そのため、エンジニアやデザイナーがそれに対応できる技術やコミュニケーションスキルを持っている必要があります。

たとえば、アプリケーションのモックアップを作る場面。
アサインされたデザイナーは、プロダクトオーナーからの依頼を噛み砕いて実現したい内容をイメージし、いろいろな事例とともにデザイン案を提案できなくてはいけません。

しかし、アサインされたデザイナーのスキルが不十分だったらどうでしょうか。
「これはどうやって操作したらいいの？」「戻るボタンが設置されてなくない？」など、開発において議論したい内容以前のところでつまづき、話にならないなんてことが起こり得ます。

ちなみにこれは、プロダクトオーナー側のスキルに対しても同様のことが言えます。
スキルのある優秀なデザイナーから良い提案が出されたとして、ほとんど知識のないプロダクトオーナーは正しくフィードバックできるでしょうか。

こうした観点から、プロダクトオーナーがしっかりとした論拠を持って判断できるかが重要とされるのです。これは、知識だけでなくプロダクトに対する思い入れも問われていると言えます。

アジャイルは、プロダクトオーナーの確認とフィードバックを受けて作っていくというサイクルが適切に回ってはじめて成り立つ開発手法です。双方に十分なスキルがなければ、このサイクルが生まれず、アジャイルは成り立ちません。

2つ目の条件は、開発規模についてです。

実際にものを作りながら進めるアジャイル開発において、作らなくてはいけないものが多い場合には、アジャイルは成立しません。

たとえば、100画面を作らなくてはいけない開発案件があるとしましょう。
短い期間でたくさんのものを作らなくてはいけない場合、多くの人がアサインされることになります。そもそも、1人のプロダクトオーナーが100画面の要件を決めたり、レビューしたりするのは無理です。

仮に5人のプロダクトオーナーをアサインして5つのチームを作って分担したとします。すると今度は5チーム間での整合性チェックが発生し、要件定義や設計のどこかでスケジュールを合流させる必要が生じます。そうなってくると、もうウォーターフォール開発に近くなってしまいます。

1人のプロダクトオーナーがコントロールできるのは、せいぜい横で話しながら調整ができる範囲です。規模の大きさの目安として、エンジニアやデザイナーの人数は2〜3人がベスト、5人以上集まったら大きいと思っていいでしょう。

最後の条件は、開発内容についてです。

他システム、特に基幹システムと連携するような場合は、アジャイルの開発にしてはいけません。大体において、基幹システムは従来型のウォーターフォールで開発していて、保守管理においても同様です。そうなると、新たなサービス開発側のみをアジャイルで進めるのは困難です。

なぜなら、基幹システムは品質をしっかりと保つ必要があるため、仕様変更がある場合には、

1. 仕様変更によってどんな影響があるのかをきちんと調査
2. 見積りを出し、発注をもらってから開発を開始
3. 導入前にテストを実施
4. テストで問題がなければ実装

というプロセスを踏みます。そのような流れのなか、新たなサービスの開発側でインターフェースの仕様をアジャイルによってコロコロ変えられたら困るのも当然ですし、そもそもできません。これはもう、基幹システムという特性上仕方がないのです。

条件②の規模と関連することですが、連携せずとも、基幹システムと似たような業務システム系はどうしても開発規模が大きくなります。これらは、そもそもアジャイル開発が難しい開発内容であることは理解しておきましょう。
 

まとめ

以上が、アジャイル開発に必要な3つの条件です。

紹介した条件のうち、どれか1つでも満たしていない場合には、そのプロジェクトのアジャイル開発はうまくいかないので、従来のウォーターフォール開発で進めることを強くおすすめします。