アジャイル開発における「ニーズの変化」への対応方法

なぜ開発者はユーザを巻き込むことに「どんびき」なのか？

開発に携わる部門にお伺いして、いつもおもしろいと思うのは、「ユーザを巻き込む」話になると実際のシーンを想像して「どんびき」されるお客様が多いことです。これは、筆者がお邪魔している組織の多くが、ウォーターフォール文化だからでしょうか？　しかし「ニーズの変化に応えよう！」と言っているのに、いきなりどんびきされてしまっては話が先に進みません。

なぜ「どんびき」になってしまうのか、過去のトラウマをひも解いてみることも意味があると思います。どんびきしていた開発者に話を伺うと、ユーザ部門と開発部門との関係性について、程度の差こそあれ「対立の構図(図1）」ができているのがよく見られます（といいつつ、「筆者自身のトラウマ」も顔を出しているような･･･）。

図1：ありがちな対立の構図

もちろん、対立の原因がすべて開発技法に帰着するわけではありませんが、ウォーターフォール型の「早い段階で要件の詳細をすべてフィックスする」ことの無理が、負の効果をもたらしていることもまた否定できないと思います。これらの認識のギャップを埋めるために、アジャイルではプロダクトオーナーという役割を設定したり、なるべく同じ部屋でのユーザと開発者の密なコラボレーションを推奨したりしていますね。ここまでは教科書的にわかります。しかし、利害関係者が増えてくることを「想像」しただけで、次のような質問を受けます。

• こんなにいろいろ利害関係者がいたら、開発中のコラボレーションは無理でしょ
• イテレーションの最後にデモするってあるけど、そこに利害関係者をみんな呼ぶの？　取締役も？
• 優先順位を付けてというけど、あんまり差がないんだよね？　それでも付けるの？

つまり、利害関係者が多様化してきたなら、それに合わせたコミュニケーションのスキームを用意する必要があるということです。スケールド・アジャイル・フレームワーク（Scaled Agile Framework、以下SAFe)とDADは各々がコミュニケーションのスキームを形作るさまざまなテクニックを提案していますが、この両者はいい具合に補完関係を組むことができます。

• SAFeにおける要求の構造化→現場から経営層へと連なる利害関係者の関心を整理
• DADのフェーズ → プロジェクト時間軸上のタイミングとその時点で決められているべき要求の具体性

SAFeにおける要求の構造化

アジャイル開発におけるシステム要求の定義といえば、ストーリー（「ユーザ～」や「テクニカル～」などがありますね）です。システムをブラックボックスとして表現し、「（ユーザは）なにができるか」を記述することで、ユーザ視点でのアプリケーションの価値を明確に提示できるというメリットが、ストーリーにはあります。その一方、イテレーションでの（おそらく最小の）実装単位という性格上、規模に応じて単純に数が増えていきます。中にはテクニカルストーリーと呼ばれるビジネス色の薄いストーリーも含まれるので、ビジネスサイドの関係者からは、自分が関心を持っているものと、さっぱりわからないものが混在した、なんともわかりづらいバックログができあがりかねません。現場のメンバーから偉い人まで、関心のポイントやその抽象度は異なります。これを意識して適切に情報を共有しないと適切な判断を期待することはできません。

アジャイル開発における要求の表現には、ストーリー以外にもフィーチャーやエピック、テーマと以前からいろいろ提案されており、その違いについて開発者を悩ましてきました。SAFeでは、ややビジネスに寄せた視点で定義しています。紙数の関係もあるので、筆者なりに要約すると以下のようになります（図2）。

図2：アジャイルなのに（？）、要求の構造

• 投資テーマの価値を実現する大規模な取り組みを表現する「エピック」。機能と言うよりも戦略やアプローチといった言葉のイメージに近い
• エピックを実現するために、システムが満たすべき条件を記述する「フィーチャー」
• フィーチャーを実現するためのシステムの機能性である「ストーリー」

　この構造を利用することで、以下のような効果が期待できます。

• 経営者と現場のメンバーではそもそも関心が異なります。各々の関心に合った要求のレベルを適切に管理・提示することができ、各レベルで適切な情報にもとづく意志決定がよりスムーズに行われることが期待できます。
• よりビジネス寄りの要求からストーリーに繋がる関係性が定義できます。なにか変更が発生した場合、影響する範囲を調べる（たとえば、「フィーチャーが変更されたらどのストーリーが影響を受けるか」という右向きのベクトル）のと同時に、そもそもその変更がよりビジネス的な観点で合意された要求に沿うのか（たとえば、「フィーチャーに求められる変更は、エピックの意図に沿うのか」を検討する、左向きのベクトル）といった判断を助けます。

図3：HP Agile Managerのバックログ

図3はHP Agile Managerのバックログの画面例です。Agile Managerでは要求の構造としては、［テーマ］−［機能］−［ストーリー］という構造を採ります。図3にあるように、テーマや機能で必要なモノを取捨選択することで、総要求数がふくれあがっても、適切なものを照会することができます。