2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したが、気がつけばバックエンドエンジニア兼スクラムマスターをやっていた。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行った。 スクラムマスターとしては、アジャイル開発(スクラム、XPを組み合わせたもの)、リーン・スタートアップ開発の導入等を行った。 ここでは、スクラムマスターとして取り組んできた、開発プロセスの改善周りについて資料にまとめようと思う。 なお、この開発プロセスは0-1 フェーズではなく、1-10 フェーズでの利用を想定して作成している。
この開発プロセスは市谷先生の「正しいものを正しくつくる」という書籍をベースに、僕たちのチームに合わせて手を加えたものであることを最初に宣言しておく。
TL;DR
- サービス開発は、リーン・スタートアップ、デザイン思考、アジャイル開発 ( スクラム、eXtream Programing 以降 XP )を組み合わせて行う
- リーン・スタートアップを用いて、追うべきKPIの設定や検証すべき仮設を設計し
- デザイン思考を用いて、仮説を検証するため何を作るべきか考え
- アジャイル開発を用いて、デザイン思考で得られた施策を形にしていく
背景
アジャイル開発 ( スクラム + XP )
ベンチャー界隈において、アジャイル開発という手法は有名だ。 そのなかでもスクラムは、軽量であり導入しやすいため最もよく利用されている1。
スクラムを導入すれば、開発物の内容や優先度、届けたい価値について、PBI(Product Backlog Item)という形で可視化される。 また、このスプリントで何をしなければならないか、誰が何に取り組んでいるかもSBI(Sprint Backlog Item)やカンバンによって可視化される。 誰が何をやっているのか、どの程度進捗しており、どこで詰まっているのか可視化するこの手法によって、 チームは優先度が高い課題に協力して取り組みやすくなり、機能的に活動できるようになる 。
スクラムは様々な職種にまたがって開発していくための軽量な開発手法であり、ソフトウェアエンジニアとしての技術的な制約をその中に含めない。 そのため、開発チームはXPのエッセンスを取り入れ、それらを共通認識として開発することがある2。 一般的によく取り入れられるXPのエッセンスの中には、TDDやペアプログラミング、リファクタリング、自動テスト、インクリメンタルなリリースなどが挙げられる。 これらの取り組みについてはすでに一般的になっており、特別に意図せずともXPの取り組みを行っていたという開発チームは珍しくはないだろう。 XPとスクラムに細かい違いはある。それらの差分に関して、どちらのフレームワークの概念を優先するかはチーム毎に意思決定することになる。
リーン・スタートアップ
スクラムにおいて、ビジネスと開発チームをつなげる役割はプロダクトオーナーが担っている。 「アジャイルエンタープライズ」3では、プロダクトオーナーには下記の役割があると記載されている。
プロダクトオーナー(PO)は、顧客価値を考慮しながら、作業の特定と優先順位付けに責任を持ちます。 また、プロダクトの進化に合わせて顧客からのインプットとフィードバックを取り込み、顧客価値を向上させていくことに責任を持ちます。 (中略)... POは顧客の代弁者であり、顧客が本当に必要としている方向にプロダクトを進めるために、顧客フィードバックを取得します。
また、プロダクトオーナーは顧客価値だけでなく、事業に利益をもたらすことの責任も持つ。 つまり ビジネスとプロダクトをつなぎ、顧客価値を最大化させつつも、事業に貢献する責任を持つのがプロダクトオーナーである。 顧客価値に責任を持つプロダクトオーナーと、ビジネスに責任を持つビジネスオーナーと役割を２つに分けることもある。 スクラム開発におけるプロダクトオーナーの責任をどのように分担するにせよ、プロダクトオーナーの持つ役割を遂行するための具体的な方法についてはスクラムにもXPにも触れられてはいない。
プロダクトオーナーはプロダクトバックログの内容や優先度という形で、開発したいサービスの機能や、それぞれの機能の重要度についてメンバーに伝える。 とはいえ、プロダクトオーナーも何が正解なのか、把握している訳ではない。「正しいものを正しくつくる」4 において、この問題は下記のように説明されている。
現在の私たちが手がけるプロダクトづくりは、誰かの頭の中に正解イメージがあってそれをうまく取り出してコードにしていくという開発ではない、ということだ。 (中略...) つまり、いま私たちが作ろうとしているプロダクトとは、「どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく」、そういう開発になる。
プロダクトオーナー１人にそういった「不確実性」に向き合う役割をもたせるチームは少なくない。 事業がうまく行っているときは、プロダクトオーナー１人が仮説立案、及び意思決定をしても、問題が起きることはそうそうないだろう。 けれども、事業が上手くいかなくなったとき、１人だけで適切な意思決定をし続けることができる人間は多くない。 リスクが少ないが、小さくともリターンを得られる可能性の高い選択肢を選びがちだ。 そして事業はじわじわと後退し、メンバーはプロダクトオーナーの実力に疑いを持ちはじめ、チームは徐々にまとまりを失っていく。
私たちのチームは、チーム全体でそれらの不確実性に取り組んでいくことを選んだ。 もちろん、最後の意思決定はプロダクトオーナーが行う。 しかし、検証すべき仮説の立案、及び何を作るかについてはチーム全体で考える。 リーン・スタートアップ開発は、チーム全体で、検証すべき仮説を作成し、検証、学習の一連のプロセス実施していくための方法を提供してくれる。 そのため、私達はリーン・スタートアップ開発を取り入れて開発をすることにした。
私達は、リーン・スタートアップの開発プロセス全体については「図解リーン・スタートアップ成長戦略」5を、 施策の評価方法については「Lean Analytics」6を参考にして、開発プロセスを設計した。
デザイン思考
私は、人は基本的に「アイデア」と「アイデアを発案した人間」を分けて評価することができないと考えている。 権威ある人間による的を外したアイデアと、権威のない人間による素晴らしいアイデアであれば、選ばれやすいのは前者だ。 恐ろしく口がうまい人間は、アイデアの魅力を何倍にも膨らませ、現実歪曲空間を作ることもできる。
わたしたちは、良いアイデアを提案者によらずに正しく評価し事業に役立てなければならない。 そうしなければ事業を成長させることはできないし、さまざまな観点で物事を捉えることのできない、視野狭窄で不健全なチームになってしまう。 良いアイデアを考案し、発案者のバイアスを取り除いて選出し、事業に役立てるためには、適切なプロセスが必要となる。 私達のチームは、そのプロセスを「SPRINT」7というデザインスプリントについて書かれている書籍を元に設計した。
我々の開発フロー
開発プロセスの全体像を上の図に示す。「正しいものを正しくつくる」のP.8に書かれている図を元に私たちのチームに合わせて修正した。違いは、事業計画の一部も開発プロセスの中に取り込んでいる点である。 その理由は、１プロダクト１ベンチャーの小さいチームにおいては、開発チームも事業計画に関わり、その方向性に影響を与え、そこで決まった内容は開発チームの中に過不足なく共通認識を作られなければならないからだ。
次の記事において、開発プロセスの詳細について記載していく。
