「アジャイルが向くための4条件」

興味深い記事を読みました。感想を書きます。

日経SYSTEMS 2019.11月号 DXプロジェクト成功の勘所(下田 幸祐氏:JQ代表取締役)第2回 開発プロセス より

アジャイル開発がDXシステム開発に向く場合の条件

  • システムの開発規模が大きくない
  • 高品質が求められるシステムでない
  • プロダクトオーナーがいて意思決定できる
  • スキルの高いエンジニアを確保できている

上記について、詳しい説明が続きます。

システムの開発規模が大きくない

開発規模が大きいと、関わるメンバーの人数が多くなります。その分、コミュニケーションコストが増えます。メンバーそれぞれのスキル・知識レベルの違い、理解力の違いなどから、以下のようなコミュニケーションが発生するためです。

  • 教える、理解させるためのコミュニケーション
  • 仕様の整合性を保つためのコミュニケーション
  • 品質レベルを一定にするためのレビュー
  • モチベーションを保つためのコミュニケーション(感情的ないさかいを起こさせないなど)

アジャイル開発ではある時期に開発する量は一定量以下です。なぜなら、その時点で優先順位の高い要件だけを開発しているからです。他は後回しにしているので、各時点で開発は小さな(10人未満程度の)チームで行います。コミュニケーションコストは問題にならないでしょう。

逆に、ウォーターフォール開発ではシステムの開発規模が大きくなってもコミュニケーションコストは大きくならないのでしょうか?アジャイル開発のようなフェイスツーフェイスのコミュニケーションこそそれほど必要とはしませんが、それ以上に仕様の整合性を保ったり品質を一定に保つためのコミュニケーションコスト(文書化とかレビューとか)がかかります。

高品質を求められるシステムでない

ハードウエア製品など利用者が手に取るものや、B2B2C(企業向けにサービスを提供し、顧客企業がそれを一般消費者に提供する形態)のように様々な関係者が登場するサービスシステム、既存システムと連携するシステムの場合、高いレベルの品質を求められます。そのため、プロトタイプ開発はアジャイル型でよいとしても、本サービスの開発時には必ず厳密な品質保証テストが必要になります。つまり、途中からウォーターフォール開発になります。

例えばホテル予約サービスの場合、サービス提供者、宿泊施設の担当者、予約者という3者分の機能があるはずです。各機能における仕様の整合性確保や、全体の業務の流れを確認する総合テストが必要になります。既存システムと連携するサービスシステムであれば、仕様調整のタイミングを合わせる必要がありますし、品質担保のために連携テストをしなければなりません。既存システムとの連携テストは、事前にスケジュール、テストケースやテストデータ、テスト手順などを調整した上で実施します。

一般的に連携テストは、結合テストと総合テストで少なくとも2回実施します。必然的にウォーターフォール型にならざるを得ません。

QAチームに対して内部リリースを常時行ってQAテストを常時行なってもらう、あるいは、リリースが近いイテレーションでは機能追加はせず統合的なテストを重点的に行う運用をしているアジャイル開発プロジェクトの事例は多数報告されています。 厳密な品質保証テストはウォーターフォールでしかできない、結合テストと総合テストはウォーターフォールでなければできないというのは、思い込みかミスリードではありませんか?

プロダクトオーナーがいて意思決定できる

規模や内容がアジャイルに適したプロジェクトだとしても、チーム体制がアジャイルに向いているかどうかを確認する必要があります。

アジャイル開発の要諦は「素早くモノを作って、要件を満たすこと」と言えます。では、「要件を満たしているか」は誰が判断するのでしょうか。それはプロダクトオーナー(プロダクトマネジャー)です。プロダクトオーナーがアサインされているものの名ばかりで、実は最終承認者がチーム外の役員や部長であったりすると、アジャイル型はうまくいきません。意思決定に時間がかかる可能性があるからです。

役職上位者が多忙で承認に手間取る、事前のレクチャーに時間がかかるなど、多くの作業コストも発生します。現場の実態や要件を細かく把握していない役員や部長クラスの鶴の一声で、ちゃぶ台返しのリスクもあります。

そのため、DXプロジェクトの企画内容に関わる現場をよく押さえていて、あるべき姿が描けるプロダクトオーナーに意思決定権限が与えられていることが必要です。また、プロダクトオーナーがエンジニアと物理的に近い場所にいて、すぐに判断できる環境も重要です。

要件や大きな仕様について責任を持って判断できる人が参加していないなら、確かにアジャイル開発はできません。これはその通りですね。

ウォーターフォールならば、いなくても開発完遂できるのでしょうか?

スキルの高いエンジニアを確保できている

アジャイル開発では、エンジニアのスキルの高さも重要です。エンジニアのスキル不足で、開発に時間がかかってしまう、または品質に問題が発生しがちだったとします。これでは、素早くモノを見ながら要件を考えること自体ができなくなり、開発の終わりが見えなくなります。すると一気にアジャイル開発に対する不信感が生まれ、プロジェクト自体が中止になりかねません。ここで言うスキルはプログラミングスキルだけではありません。プロダクトオーナーの要望を理解・解釈するスキルも重要です。

アジャイル開発であれば、スキルセットに不足があれば早期に問題が発覚します。助っ人を入れるなりプロジェクトを中止するなり、いつでもしたらいいです。

ウォーターフォールではそのような問題は開発の終盤に噴出するので、これについてもこの条件を気にすべきなのはウォータフォール開発なのではないでしょうか。