アジャイルにおける事前合意について
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。
ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。
アジャイルは最初に全てのCDSを決めない
まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。
ウォーターフォール型開発というのは、
- 「スコープは最初に確定」し、
- 「コストや期日はスコープを達成するために必要な分を最初に設定」し、
- 必要なリソース（人員など）を調達する
というシンプルな考え方です。そして、スコープを決めるために要件定義工程を実施します。この手法の問題点は、規模が大きくなるほどコストや期日の予測が難しくなる、開発期間中にスコープを変更したくなる、リリース間近にならないと品質の確認ができない、といった点です。
- とりあえず要員を固定化し、
- 「スコープは定期的に見直す」ことで、
- 「期日はリリースできるようになったらリリースする」ことになり、
- 「コストは人員を維持した期間分だけかかる」（ゼロにしたければ開発を止めればよい）
となります。つまり、アジャイルは「要員の固定化による調達オーバーヘッドの排除」「スコープの定期的な見直し」という仕組みによって、CDSを開発期間中に調整可能にしてしました。
整理すると「スコープを決めたら最適なコストと期間で作る（終わるまでスコープは変更はしないでくれ）」なのか「コストが固定的にかかるが、定期的にならスコープを変えていいし、リリースはなる早でやる」なのか、です。
（だから内製化してコストを人件費で処理できるとアジャイルのメリットが際立つことになります。SIerによる準委任的なアジャイルが顧客から見て投資対効果が見えにくくなる原因でもありますね）
チームはどこを他者と合意し、どこを自分たちで決定するのか
アジャイル開発プロセスは「最初に全部を決めなくてよい」のですが、仕事としては「最初に何も決めなくてよい」とはなりません。
特にステークホルダー（利害関係者）とは、ある程度の合意を事前にした上で開発を進める、というのが一般的です。
例えば顧客やオーナーとであれば、大まかな目標と期日、そしてコストの合意をするでしょう。これら全てを「やってみないと分かりません」というのは普通は許されないのです。
あるいは関連部署との業務手続きや関連システムとの連携、運用部門への引き継ぎなどもリリース間近になって「こうしてください」とはいきません。ある程度は事前的に合意をし、検討するべきは検討し、用意すべきものは用意するというタスクを起こしていきます。
他にもマーケ部門や広報部門とデザインルールやブランドイメージへの準拠、マーケ部門とはネタとしての機能合意などもあるかもしれません。これも勝手に決めることはできません。
ウォーターフォールは「最初に（決められないことでも）合意するしかない（から無理が来る）」ことで嫌われていたのですが、アジャイルは逆に「手法としては最初に全部決めなくていいが、仕事としては最初にそれなりに合意しないと後で面倒」という状況になります。これはシステム開発の規模や企業の規模に関わりません。
（というか、そもそも仕事とはそういうものですけども）
つまり、チームにとって「合意相手と合意すべきところ」と「チームが自ら決定するところ」があり、それらをきちんと整理して分別し、適切に管理することが必要になります。
事前合意は厄介なもの
そもそもアジャイルに限らず、チームにとって「利害関係者と合意する」というのは厄介な作業です。利害関係者というのはそれぞれの分野の専門家であり、その分野における常識や規則に縛られています。つまり、話が合わないのが普通です。とはいえ、多様な専門家の集まりが組織的な強さを発揮すれば高い成果に結びつくわけで互いに意見をぶつけあって、よりよい合意を目指すことが重要です。
もちろん、チームの状況によっても難易度は異なります。極端な例とすれば経営者がチーム内にいて、しかも自己資金でやっているITベンチャーなら一切の事前合意は不要かもしれません。逆にエンタープライズになれば事前合意を強く求められ、結局はウォーターフォール的に進めるしかないこともあります。
さて、特にエンタープライズのアジャイル開発においては1.ビジネスのコンセプトと、2.他システム連携の事前合意に問題が生じることが多いです。
どの機能が儲けにつながるのか？
ビジネスのコンセプト、というのはシステムのコンセプトとは違います。ビジネスのコンセプトとは端的に言うと「いかにして儲けるか」、そして「どの機能があると儲かるのか」ということです。
アジャイル型開発では「優先度の高い機能から作る（そして定期的に優先度を見直す）」のですが、優先度を判断する上で重要なのが「その機能があれば儲かるのか？」ということです。
ウォーターフォールの場合は最初に全てを決める必要があるので「全ての機能を抜け漏れなく洗い出す」ことが優先されます。アジャイルであれば「必要になったら、なる早で作る」という安心感があるのですが、ウォーターフォールでは「最初に言わないと、いつ出来るかわからない（少なくとも最初のリリース後）」という不安もあり、網羅性が重視されます。
結果として「その機能が儲けにつながるのか？」というような判断よりは「使う可能性があるなら作ることにしておこう」となりがちです。
例えば運営者が使う管理画面のようなものは、最初はなるてもなんとかなることもあります（ここは儲かる儲からないではなく、業務部門とのせめぎ合いもあるでしょうが）。
ウォーターフォールは「最初に作るべき機能を定める」こともあり「システム開発をする」という感覚に陥りがちです。一方のアジャイルは常に「ビジネス的に優先度の高いものから作る」ことを考えるので「ビジネス開発をする」という感覚が必要になります。
この違いを共有するためにも「ビジネスのコンセプトを事前合意する」は重要です。表現としてはビジネスモデルキャンバス、ユーザーエクペリエンスマップ、より詳細にはユーザーストーリーのようなものがあげられます。
大事なのはビジネスのコンセプトからシステムの機能まで線を引き、その機能の必要性をビジネスの観点から考えることです。
いかに基幹と繋ぐか
次がシステム間連携です。特にエンタープライズなアジャイル開発では、SoRな基幹系システムと連携することが重要になります。
企業がアジャイルでシステム開発を判断する場合、多くは新たなサービスを作り、既存顧客からの新たな売上獲得を目指します。既存の営業チャネルや取引チャネルを活用しつつ、試行錯誤の部分を「じゃ、アジャイルで」となります。
このような案件では既存顧客のデータ（アカウント、取引履歴、支払い、請求など）との連携が重要です。この連携があることで顧客にとって支払い先を集約するメリットが生まれます。
システム連携の難しさは技術論ではなく、ドメイン間にはインピーダンスミスマッチに起因します。既存サービスを成立させるとために作られてきたモデルは、必ずしも新しいサービスとは整合しません。この場合、どのようにミスマッチを解決するかは事前に考える必要があります。
ミスマッチを解決する1つの方法は「既存システムが新しいサービスのために新たな連携を開発する」ということですが、大抵の場合は時間もコストも合いません。よって、ミスマッチがある既存の連携を流用し、新しいサービス側がなんとかすることになります。
もちろん、最初からきちんとしたシステム連携をする必要はなく、手動でも問題はありません。でも、概念がズレていることは事前に理解しておく必要があります。この事前合意を怠るとシステムが破綻するか、それを手動でリカバリする業務が破綻します。
事前合意するためには、やはり、ある程度は踏み込んで既存システムの概念やコンセプトを理解した上で、連携項目1つ1つを丁寧に検証する必要があります。
アジャイルでやっていると、どうしても表側の機能開発に気を取られ後回しにしがちですが、システム連携の合意が遅くなるほど必ず手戻りが増えてしまいます。この点にも注意が必要です。
