アジャイルなマインドセットとは④

豆蔵の中の人ナカサトのヒトづくり・モノづくり・コトづくりへ一言 第１４回

中佐藤　麻記子

「アジャイルなマインドセットとは」4回目です。
今回は結論から。「要件・計画・見積・設計の無段階の階層性を認めること」です。

「アジャイル開発で要件は事前に決めるの？決めないの？」

今回は特に、なんのこっちゃ、と思われる方が多いのではないかと思います。要件で考えていきましょう。
数年前の話ですが、インセプションデッキやスプリントゼロについて、社外の方数名と会話していたことがありました。スプリントゼロという考え方は、本来のスクラムにはありませんが、チームビルディングをし、プロダクトのビジョンについてチームで合意するための準備期間として、設定することがあります。純粋なアジャイル開発ではなくなるものの、目標・目的をチーム全員で合意するという意味で、スプリントゼロってやっぱり必要ですよね、とかいう話をしていたのですが、その時にある方が言ったことが、私にはちょっと衝撃でした。

　　「でもね、スプリントゼロの話をすると、『やっぱり要件定義期間は必要なんだ』 と言う人がいるんだよ」

誤解のないように申し上げておきますと、この方ご自身はアジャイルのことをとてもよく理解されている方です。周囲にその考え方を広める際に、いろんな苦労をされている、その背景があって出てきた言葉だと思ってください。
スプリントゼロと従来の要件定義工程の区別がつかない人がいるんだ、という点にびっくりしたのですが、そう言われてみれば思い当たる節はありました。

要件をアジャイル開発でいつ決めるの？という話が出た時には、私は、アジャイルに対する理解度において、相手が今どの段階にいるかによって、かなり言葉を選んで答えます。ここを間違えると、いらぬ誤解を与えかねないのです。

・第1段階：アジャイル開発って、要件を決めずに始められるんだよね
　⇒ 要件を決めずにものづくりができるわけはない。もちろん作り始める前に少なくとも概要は決める

・第2段階：プランニングで決めればいいんだよね
　⇒ これは遅すぎる。プランニング前にある程度は決まっていなければならない

・第3段階：プランニングで決めたらスプリント途中では変更不可だよね
　⇒　程度問題。バックログ項目単位で入れ替えることは通常しないが、細かい点は相談して変えることはある

・第4段階：大きな目標・目的は初期段階で決めてプロダクトバックログを洗い出せばよい？
　⇒ バックログにもレベル感の違うものがある。大きなレベルでも変更の可能性はゼロではない

・第5段階：結局何をいつまでに決めればいいの
　⇒　状況による。標準で一概には決められない

これ、すべてが曖昧な言葉（太字部分）を含んでいることにお気づきでしょうか。アジャイルのコンサルタントやコーチは、何を訊いても ”It depends”（場合による）としか答えない、と言われることがありますが、それのいい例でしょう。そして、その理由は「要求や要件と言われるものに階層があり、かつ、それが何階層、というようにきっちり分けられない」ということではないかと思っています。

階層的な要求とそこから派生するもの

階層的な要求・要件の例として、弊社の要求開発手法の研修で使用している図を見ていただきましょう。

この図は、ビジネス戦略⇒ビジネスオペレーション⇒システム要求⇒システム設計、というつながりで、WhatとHowが連鎖していることを示しています。ある段階のWhatを実現するために次の段階のHowがあり、それがさらに次の段階から見ればWhatになる、というつながりです。ビジネス戦略というとおおげさに聞こえるかもしれませんが、プロダクトオーナーがプロダクトのビジョンを明確化する際、会社のビジネス戦略抜きにはできないはずです。ビジネスオペレーションは、業務フローをイメージしていただけると、わかりやすいでしょう。

実際には、このつながりは必ずしも4階層ではなく、さらに多くの階層を含むことがあります。一概に何階層、と決められません。この図もあくまでも便宜的なものであって、正確に書こうとすると、こうなるでしょうか。

そして、要求が無段階の階層を持っているということは、計画・見積も同じだということであり、さらにこれ以降の設計についても同様です。どこまでが、概要設計やアーキテクチャー設計で、どこからが詳細設計なのか、本当のところは切り分けられないのではないかと思います。

だからこその契約や体制の変化ではないのか

アジャイル開発を説明するキーワードとして、よく出てくるのは、「ビジネスとの協調」です。もちろん、これは否定しないのですが、これをあえて言わなければならないということは、「今は協調できていない」という現実があるということです。
DevOpsもそうですね。「現状は、DevとOpsが分断されている」からこそ、この言葉がみんなに響いたのです。

この背景にあるのは、アジャイル開発であるかどうかに関わらず、ここまでがビジネス側／ここからはシステム側と区切ることは本当はできない、からではないでしょうか。そして、だからこそ、「一括請負契約はアジャイルの考え方に矛盾する」と言われるのであるし、「内製開発が望ましい」のではないかと思います。本来、区切りづらいものを、現状の契約や体制のために、無理やり区切ってきた、というのが、これまでのシステム開発だったのではないでしょうか。