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