ある程度事業規模が大きくなると、新規サービスを立ち上げたりマイクロサービスによるプロダクトの分割を行い、各サービスで共通に利用する機能を切り出したサービス、基盤サービスを立ち上げるタイミングがいつか来ることがあるかと思います。基盤サービスはCynefin Framework（クネビンフレームワーク）における複雑系と呼ばれるタイプの課題を取り扱う場合が多いですが、今回の記事はそういったエンドユーザーからは少し遠い基盤サービスを立ち上げ、どのように課題を設定し、MVPを定めていくかというポイントについて書いていきたいと思います。
こんにちは。ichyことTakeru Ichiiです。以前「私のスクラム開発。もしくはペペロンチーノの作り方。」という記事を書かせて頂き、おかげさまでペペロンチーノのつくれぽをTwitterで拝見したりしてニヤニヤしておりました。ペペロンチーノはシンプルですが奥が深く、インターネット上では様々な流派があるので、ぜひ皆様にはいろんなペペロンチーノを試して、自分の思い描く素晴らしいペペロンチーノを編み出していただき、つくれぽお待ちしております。さて、前回ペペロンチーノだったので今回はボロネーゼの作り方を、と思ったのですが、Blogの担当者から「料理のレシピはいらない」との言伝を頂いておりますので、私のもう一つの趣味である鉄道から大崎駅りんかい線の配置に関する歴史を紐解こうと思います。と思ったのですが、これも担当者からだめとのことなので不承不承ではありますが、お仕事に関連するお話をしようかと思います。
基盤サービスの課題の特徴
皆さん、アジャイル楽しんでいますか？かくいう私はなかなか苦しんでいます。実は私はfreeeでは珍しく専任スクラムマスターという立場で、いくつかのチームのスクラム開発をサポートさせていただいているのですが、その一つにある基盤を支えるためのチームがあります。このチームはごく最近作られ、チーム人数はまだ少ない状態でfreeeのサービスを支えるべく新たな基盤サービスを立ち上げているところです。基盤とは、分かり易い例でいえば認証認可などの「様々なサービス固有で持つものではなく共通で使われるサービスとして運用されるもの」を指しており、このような責務を持つサービスをfreeeでは基盤サービスと呼称しています。
さて、新しくチームを立ち上げるときに必要なのはもちろんそのチームが行う仕事です。大体の新しいチームというのは何か課題感を持って立ち上がることが多いと思いますが（なんとなくチーム作って何作ろうかというのも稀にありますね）、課題感からすぐに何をすればいいかと言うのをすぐに決められる課題と、決められない課題というのがあります。例えば、ユーザーが直面している問題とその解消方法がわかっていて、解消方法を実現するために何かをつくるというわかりやすい状態が前者ですが、ユーザが直面している問題はわかるものの解消方法がわかっておらず、解消方法を定めるために様々な調査から始める状態が後者です。この後者の問題はMore Effective Agileでも紹介されているCynefin Framework（クネビンフレームワーク）でいえば「複雑系」と言われる問題です。この問題は
- 問題は把握されているが、理解されていない
- 解決に至るための質問すべき内容が全てわかっているわけではない。解決策を得るためには実験が必要。失敗は織り込み済み。不完全なデータに基づいて決定をくださなければならない場合が多い。
が特徴の問題です。More Effective Agileではこの複雑系の問題解決にはOODA（ウーダ）ループを使うと良いというアドバイスがあります。このループは
- Observe(観察)
- 現在の状況を観察し、関連する外部情報も観察する。
- その上で明らかになる状況の側面を観察し、環境とどのように関わり合うのか観察する。
- Orient(方向づけ)
- 観察の結果を自分が置かれている状況と関連付ける
- 観察した情報が自分たちにとって何を意味するかを判断し、利用可能な選択肢を特定する。
- 様々な先入観を取り除く機会を提供する。
- 理解を深めて優先順位の変更も実施する。
- Decide(意思決定)
- 方向づけによって特定された選択肢にもとづいて決定をする。
- Act(行動)
- 意思決定にもとづいて行動する。
- 行動した結果や影響をもって再び観察から始める
を実施するループで、PDCAのような性質も持っています。特徴は戻ったり省略も可能で、
- 方向づけから観察にもどれる。
- 意思決定から行動を伴わない場合は、観察にスキップする。
- 観察や方向づけにおいてが既知のパターンが発生した場合は直接行動することができる。
といったことも可能です。このOODAループはまさにアジャイル開発の方法のベースに近い性質を持っており、スクラムもこのループに当てはめることがだいたいできると思います。
さて、前提が長くなってきましたが、私が先程書いた新しい基盤サービスをたち上げるチームはまさにこの複雑系の特徴を持った課題に立ち向かうことになります。つまり、問題は把握しているが、解決方法がわからないのです。そこでこの基盤チームにもアジャイル開発を導入することにしました。まず我々は新しい基盤を作る上で、新しい基盤を使うサービスの調査を行いました。これはOODAループのObserve（観察）に当たる状態ですね。我々が担当する基盤サービスというのはエンドユーザーが直接触るUIはほぼなく、多くはエンドユーザーに対して間接的に影響があるものになります。このようなサービスの場合、エンドユーザーがどのように使うかというのはそれほど重要でない場合が多いのですが、今回の場合はエンドユーザーのUXに影響を与えることが考えられたため、まずはエンドユーザーを起点としたユーザーストーリーを集めることにしました。
ユーザーストーリーを作る
さて、ユーザーストーリーに関しては知っている方もいるかと思いますが、改めて説明していこうと思います。ユーザーストーリーとはシステムを使用する人の視点に立って説明される機能または能力の説明のことを言います。代表的なフォーマットとしては
- ユーザーの種類
誰々として
- 利益
何々をできるために何々するために
- 目標・要求
何々したい何々を望んでいる
のように書かれます。例えば
「freeeを利用したことのないユーザー として freeeを利用 するために サインアップ したい」
という感じです。
そこで、我々はまずある一つのサービスに絞ってそのサービスのPjMやPdM、エンジニアにインタビューやヒアリングを行い、我々が作ろうとしている基盤サービスとその周辺のユーザーストーリーを集めました（記事の最後に付録でユーザーストーリーの要点をまとめてあります）。多くのストーリーを集め、我々が解決したい課題が徐々に浮き上がって来たので、早速それを解決するための実装に取り掛かりたいところですが、焦ってはいけません。その解決しようとしている課題は本当に解決しなければいけない課題なのでしょうか。そしてその課題を解決するための実装する内容は本当に正しい解決案なのでしょうか。
顧客が本当に必要だったもの、MVPの考え方
「顧客が本当に必要だったもの」という言葉をご存知でしょうか。ニコニコ大百科にも記事があるぐらいには有名で、SNSとかでもへんなブランコの画像はちょいちょい見かけます。端的に言えば、「顧客は自分が欲しい物を満足に説明することはできないし、それを提供する側もわからない」というものです。受託開発をベースにしたかのような画像ですが、我々事業会社も例外ではありません。エンドユーザーがこれに困っている、だからこうしてほしいといったものは本当にエンドユーザーのほしいものを表しているとは限らないです。そこで我々はOODAループを回す必要があります。エンドユーザーが本当に欲しい物を提供するために、一度サービスを提供して使って頂き、再び観察する必要があります。しかし、一度に大きな単位でその機能を提供するのはとても危険です。大きな単位での開発を行ってしまうともし我々が間違った方向に進んでいる場合にその修正も大きくなり、場合によっては修正が不可能な状況にも陥ることになります。このリスクをなるべく小さくするために、小さい単位の開発を実施するアプローチを取ることになります。
MVP(Minimum Viable Product)と呼ばれるリーン開発ではおなじみの手法があります。「最小限の利用可能な商品」と直訳できるこの手法は、いかに失敗のダメージをへらすかという観点のマネジメント手法です。The Minimum Viable Product and Incremental Software Development | Effective Software Designという記事の絵はとてもわかりやすいMVPの例です。この記事ではピラミッドを作る方法には2つあり、それぞれ段階的なプロセスですが、以下の特徴があります。
- 土台からピラミッド組み上げていく方法
- 土台から徐々に組み上げていき、最後のステップでピラミッドが完成する。
- 小さなピラミッドを組み上げそれを徐々に大きくしていく方法
- 一番最初に小さなピラミッドが完成し、各ステップでは徐々に大きいピラミッドが完成する。
先程の話をこのピラミッドで例えてみましょう。顧客（王？）がどのようなピラミッドを要求し、満足するかは顧客本人がフィードバックを行う必要があります。事前に数値的に満たさなければいけない仕様があるのであればそれを満たすピラミッドを作る必要がありますが、それ以外の要件は実際に体験してみないとわからないものです。土台からピラミッドを作り、完成したところで、それが大きく顧客の期待からずれているものを作るより小さな必要最低限の仕様を満たしたピラミッドをつくり、そこから付け足すほうが遥かに失敗のダメージが減ることは直感的にも納得が行くところかと思います。これがMVPの目指すところです。
基盤の視点でユーザーストーリーを作り直し、MVPを定める
さて、話はもどり、我々は基盤に関連するエンドユーザーのユーザーストーリーを集めることができたので、このユーザーストーリーからMVPで実装するコアの価値を抜き出し、基盤サービスが最初に取り掛かるファーストリリースの範囲を決定することになります。ユーザーストーリーを分析し、コアの価値を定め、作らなければいけないものを決め、ついに我々エンジニアが自らの技術力を持ってやっと作る作業に入れる！と思われるでしょうが、ちょっと落ち着きましょう。基盤サービスで作らなければいけないものを決めました。でもその作らなければいけないものは、本当に全部作らなければいけないのでしょうか。そもそもその作らなければいけないものは本当にすべてが作らなければいけないものなのでしょうか。
混乱するような表現になってしまいましたが、今回のように先にエンドユーザーのユーザーストーリーを作り、MVPを抜き出してしまうとこれを実現するための機能を網羅した基盤サービスを作らなければならなくなってしまうという気持ちになってしまいます。先程MVPの話をしましたが、これはエンドユーザーだけに当てはまる話ではなく、基盤サービスにも当てはまる話です。これは、基盤サービスを利用する各種プロダクトが基盤サービスにもとめているものが実はまだわかっていないという前提で考える必要があるからです。基盤とはいえ、基盤に要求する要件はfreeeサービスを開発している開発者自身も正しくは把握できていない場合が多いです。
なので、基盤サービスでやらならければならないのは本当にこの時点ですべて作る必要があるのか、この機能は本当に必要なのかというのを再度確認する必要があります。つまり、先程のユーザーストーリーはエンドユーザーを起点としてfreeeのサービスが実現するストーリーを考えましたが、今度は、エンドユーザーが使うfreeeサービスを起点として基盤サービスが実現するストーリーを同じように考える必要があります。例えば以下のようなユーザーストーリーです。
「個別のfreeeサービス として ユーザーが存在するかどうか検査 するために ユーザーのメールアドレスからユーザー情報を取得 したい」
そして個別のfreeeサービスを起点として基盤に対するユーザーストーリーを考えたらそのMVPを更に掘り下げる必要があります。今回の我々の例の一部と取ると、その基盤サービスを使うためには各freeeのサービスそれぞれが何かしらのマスタデータを必要としているという仕様があり、次のようなユーザーストーリーが導かれたとしましょう。
「個別のfreeeサービスの開発者 として 基盤サービスの利用を するために 事前に個別のfreeeサービスの初期情報を登録 したい」
このユーザーストーリーを実現するために我々基盤サービスはそのマスタデータを入力するためのAPIが必要であると考えます。今回の基盤サービスはfreeeのほぼすべてのサービスに導入されていくことになるので、この初期情報を入れるAPIを作っておけば運用チームの手を借りることなく利用を開始できるようになるとても便利なAPIになります。しかし考えてみましょう。その機能はコアの価値でしょうか。基盤サービスを利用する前提の作業は厳密に言えばコアの価値とは違います。しかも、この機能は最初の一回だけやればいいのであれば、一旦は運用チームで引き取って行うという方法も取れます。このユーザーストーリーは一旦MVPから外し、次回以降の開発で実施したほうが良いでしょう。これよりも、我々が提供する基盤サービスがコアの価値を発揮できるか検証できる開発に注力したほうが効果的です。
まとめ
さて、今回はエンドユーザーのユーザーストーリーから基盤サービスにおけるユーザーストーリー作成のポイント、そしてMVPに焦点をあてていきました。エンドユーザーを起点としたユーザーストーリーから基盤サービスの要件を作る際は、エンドユーザーのMVPと同様に、基盤を使うサービスを起点として基盤サービスのユーザーストーリーを作り、MVPを探っていくというところが今回のポイントでした。ユーザーストーリーやMVPといった概念はリーン開発やアジャイル開発では割と知られていることではありますが、実践すると意外に難しかったりすることでもあります。特にMVPや小さくリリースするといった考え方は（自分を含めた）エンジニアは誤解をしている部分が多かったりします。もし過去上手くいかなかったなーと思ったら、ぜひこの記事を読んでもう一度Tryしてみてはいかがでしょうか！自らOODAループを回して成長していきましょう！
付録: ユーザーストーリーの要点
付録で私がユーザーストーリーのチケットを作るときの要点をまとめたリストを皆様に共有しようかと思います。ぜひご活用ください。また、うちはこういうところに気をつけてるよ！みたいなTipsがありましたらぜひTwitterでこの記事のURLとともに教えて下さい！
- タイトル（ユーザーストーリー）は以下の要素
- (必要がアレば)前提
- 前提として＜誰々＞は＜何々＞をしており…、
- ユーザーの種類
- ＜誰々＞として
- 利益
- ＜何々＞をできるために
- ＜何々＞するために
- 目標・要求
- ＜何々＞したい
- ＜何々＞を望んでいる
- (必要がアレば)前提
- 当該ストーリーがさらに分解できないか検討する
- 1スプリントで終わるかどうかを基準にしてみてもいいかも
- ストーリーの詳細を明確にする
- 要求が正確に記載できてるか、タイトルの用語にブレがないかをチェックする
- INVESTガイドラインにそってるか？
- independent（独立している）※ゆるい条件
- 特定の順番で実装する必要がない。
- Negotiable（交渉可能）
- 全ての詳細を記述しないで、開発者とビジネス側で交渉可能な状態
- 詳細化は後の受け入れ基準でおこなう
- Valuable（価値がある）
- ビジネス的に定量化できる価値
- Estimable（見積もり可能）
- 開発者が見積もりできる程度の具体性
- Small（小さい）
- 1,2人の開発者が一回のイテレーション（スプリント）で実装できる大きさ
- Testable（テスト可能）
- ビシネス側がストーリ完成のテスト可能か
- independent（独立している）※ゆるい条件
- ストーリーの受け入れ基準を定義する
- ここでタスクとして何が必要かを明らかにする
- ストーリーを見積もる
- 見積もりできないときはDoR（準備完了の定義：後述）でスパイクを検討する
- スパイクとはストーリーを見積もるために必要なメタストーリー
- ライブラリの仕組みがわからないなどの場合の調査などが当たる
- 書き方的には「＜何々＞のストーリーを見積もる」というタイトルで表される。
- 見積もりできないときはDoR（準備完了の定義：後述）でスパイクを検討する
- 準備完了の定義（DoR）を明確にする
- 準備が整う前にチームが要求の開発作業に進めないようにする
