アジャイル開発の本質とは何なのか

はじめに

アジャイルサムライをはじめ、アジャイルやスクラムなどに関する記事や文献を読み、アジャイル開発について理解を深めたので、これまでの経験等を含めて備忘もこめて理解したことと考えた内容を書き起こしておく。

アジャイルサムライ――達人開発者への道

アジャイル開発の本質とは何か？

アジャイル開発はウォーターフォール開発とは異なり、仕様の検討から設計、開発、リリースまでを行うサイクルを短く何回も繰り返すものである。この理解は間違いではないが、このことだけがフィーチャーされることも少なくない。じゃあなぜアジャイル開発すべきかという本質まで理解した上で利用されるべきだと思う。例えば、アジャイル開発をすると早くリリースできるんでしょ？という認識は一側面では正しいが、ウォーターフォールモデルで開発されるようなクオリティのものが早くリリースされるとは限らない。正しくアジャイル開発を理解して運用しないと十分な効果を発揮しないため、本質を理解した上で効率的な開発を進めていくことが必要になる。

アジャイル開発の本質的なポイントは、開発しながらリリースするプロダクトを正しい形に導いていくことにある（開発スピードは本質ではない！）。ソフトウェア開発は開発時点では最も不確実性が高く、開発しているプロダクトが求められている納期で求められている品質のものが納入されるかどうか不確実である。この不確実性を高くしている主となる要因は２つで、(1)ユーザーのニーズと、(2)チームの開発力である。これらの不確実性について理解することがアジャイル開発の本質とは何かを理解することに繋がる。

不確実性と向き合う

(1) 不確実性１　ユーザーのニーズ

プロダクト開発におけるゴールは、単にプロダクトをリリースすることではない。ユーザーが求めているプロダクトをリリースすることである。ここで重要なのは、ユーザーが何を求めているか作り始める開発者には分からないことにある。この不確実性を高くしている要因として、ユーザー自身が本当は何を求めているのか理解していなかったり、ニーズが仕様として正しく落とし込まれてない可能性が非常に高いことにある。このアジャイル開発において不確実性を下げるために一番必要なことは、簡単に言えば「作りながらユーザーに何が欲しいか尋ねること」にある。つまりユーザーを開発サイクルに巻き込むことがアジャイル開発の必須要件になる。

チームに立てるプロダクトオーナーは、一番目のユーザーにあたる。開発サイクルの中で、仕様の検討のフェーズと設計、開発を終えた品質確認のフェーズで、プロダクトオーナーに開発サイクルに入り込んでもらってフィードバックを受けることで、正しいプロダクトの形へと導いていくことができる。一つの開発イテレーションを終えるたびに、プロダクトオーナーに動いているプロダクトを見てもらうことで、ユーザーが求めているものなのかどうかが判断され、足りない部分を次の開発イテレーションで仕様に落とし込み開発を進めていく。このようなサイクルを繰り返すことで、ユーザーのニーズという不確実性が下がっていく。

スタートアップのような小規模なWebサービスであれば、短いサイクルで開発したプロダクトを早い段階でパブリックにリリースすることもいいかもしれない。そうすることによって早い段階で、実際にユーザーの評価を得られニーズの理解が可能になる。SNSやユーザーヒアリングによる定性的な情報と、CTRやCVRといった定量的な情報を使ってユーザーの声に耳を傾けながら不確実性の高かった部分を紐どいて小さくしていく。

このユーザーのニーズをチーム内で理解を深め浸透させるようなものとして、インセプションデッキなどのやり方があげられる。

(2) 不確実性２　チームの開発力

プロジェクトの発足と同時に新たに開発メンバーが組まれることがある。チームメンバーごとの開発力が分からないということはチーム全体の開発力が不明ということであり、プロダクトリリースの計画を正しく見積もることができない。一方で基本的にプロダクト開発ではリリースタイミングを見計らう必要があり、開発初期の段階でいつリリースする予定か決める必要がある場合が多い。そのために、開発前の仕様からざっくりとした機能ごとの見積もりを出すことで、最終的なリリースタイミングと機能の絞り込みが行われる。しかしながらだいたいの察しの通り、このざっくり見積もりは到底正しくいかない。

上述したようにそもそも仕様に不確実性があるのだから見積もりも正しいものになるわけがないが、仮に仕様が確実なものだとしてもチームの開発力を正しく見積もることができない以上、ざっくり見積もりは期間や機能数が多ければ多いほど、実際にかかる工数との差分が生まれていく。そのために、期間と機能数を絞ってチームで開発を行い、チームの開発力を実績値として測るのである。一つの大きなサイクルでは測れなかった実績値を、細かなサイクルに分けることで小さな単位で実績値を積み上げていくことができる。サイクルを繰り返すことでだんだんと実績値にブレがなくなっていき、本来のチームの開発力が正しく測れるようになる。そうして実績値ベースで工数の再見積もりを行うと、最初に積んだ全体の見積もりから最終リリースに対してどの程度ずれが発生しそうなのか、開発途中で気づくことができる。上述のユーザーのニーズとの兼ね合いを見ながら実装する機能を削ったり変更したりして、あるべきプロダクトの形をリリースに向けて模索していくことができる。

チームの開発力をより正しく測るために、プランニングポーカーなどのやり方があったり、バーンダウンチャートなどのグラフで示す方法があげられる。

アジャイルな開発手法

アジャイル開発手法としては、スクラムやエクストリームプログラミングなど、フレームワークがすでに存在している。これらは必ずしも乗っからなければならないものではないが、やり方としてアジャイル開発をしたことがない場合に取り入れやすく、これまでの先人の知恵が取り入れられているため正しい形で進めやすい。しかしながらチームの形やプロダクトの種類、環境によってフィットしたやり方を見つけるのがベストである。

スクラム開発

スクラム開発は、アジャイル開発を行うための１つのフレームワークに過ぎない。スプリントという概念でイテレーションが回され、スプリントごとに行うべきイベントがもう定義されている。

• 計画を立てる（プランニング）
• 開発を実施し、毎日進捗を確認する（デイリースクラム）
• 開発した機能をユーザー（プロダクトオーナー）に見せてフィードバックをもらう（レビュー）
• 開発サイクルに対して振り返りを行う（レトロスペクティブ）

要は上記を行うことなので、本質的には、よく読んでもらえればやって開発でごく当たり前のことを並べているのに過ぎない。しかしながらこういった「ちゃんとやるべきこと」が実際に開発を進めるとおざなりになってしまってきちんと運用されないことが多いのが現実である。そのために、スクラム開発はスクラムマスターを別でロールとして用意することで、これらの「ちゃんとやるべきこと」をきちんとイベントとして実施することが重要である。

エクストリームプログラミング

エクストリームプログラミングの本質はプロダクトを長期に渡って運用することを見越したチームの熟成が必要な場合に使われるべきフレームワークである。簡単に言ってしまえば、その本質は「教育」にある。スクラム開発はスプリントに参加する開発者はある一定の能力を持った開発者が揃っていることが前提にあり、教育的概念を含んでいない。一方で、現実ではチームメンバーの力量はメンバーごとに様々であり、インフラ、バックエンド、フロントエンド全てに精通している優秀なメンバーもいれば、一部のスキルしか持ち合わせていないメンバーもいるようなことがある。これによって、上述した不確実性の１つとして挙げたチームの開発力が、メンバーの流動によって見積もりに大きなブレができてしまう。これを避けるために、ペアプログラミングを基本としたチームの開発力の底上げと均一化を行い、どのメンバーでもどの機能開発もできるようにすることが狙いである。

さいごに

アジャイル開発について学んだことや考えたことをまとめた。アジャイルの本質は不確実性を低下させながら正しいプロダクトを開発することにある。開発手法や個々の場面で使われるべきツール、フレームワークはアジャイルサムライをはじめとした様々な文献を読んでより深い理解を深めてほしい。ただ、本質的にはチームやプロダクト、それらの置かれた状況や環境などに応じた、最適な開発手法を探すのが一番だと思う。もしかしたらアジャイル開発に変わる新たな考え方が出てくるかもしれないし、時代に応じた適切な開発手法があるかもしれないので、今後もどういう開発スタイルが良いのか考えながら開発をマネジメントしていきたい。