新機能の開発前に行っている3つのプラクティスを紹介します

こんにちは、サービス開発課の丸山です。
本日はタイトルの通り、サービス開発課で開発している Cloud Automator の新機能の開発前の段階で行っている取り組みについてご紹介したいと思います。

とは言っても、うまくいっているベストプラクティスというほどのものではなく「今のところ実験も兼ねてこんな感じで回しています」という温度感のものです。
そのため、うまくいった取り組みや利点はもちろんのこと、課題に感じている部分も紹介していければなと思っております。

開発前に行っている取り組み

今回は次の3つの取り組みを紹介したいと思います。

Working Backwards
ユーザーストーリーマッピング
Example Mapping

これらの取り組みは実装に着手する前に1~3の順番で行っています。

Working Backwards

背景

Working BackwardsとはAmazon社内で行われている「顧客視点」で考えるためのフレームワークです。
以前にAngel Dojo というAWSの若手エンジニア向けの育成プログラムに私が参加した時にWorking Backwardsのワークショップがあり、メリットがあると感じてサービス開発課内での開発プロセスでも使っています。
blog.serverworks.co.jp

ただし、元々Angel Dojoでのワークショップが簡易版だったことに加え、サーバーワークス社内でのプロセスに合わせて変更しながら使っているため、ここで紹介するものがAmazonの本家 Working Backwardsであるわけではないことはご注意ください。
本家 Working Backwardsとその思想的な背景については2022年1月にまさにWorking Backwardsというタイトルの書籍(の翻訳)が出版されるようなのでこちらの内容に期待しています。
honto.jp

目的

Working Backwardsの目的は一言で言えば「機能が顧客視点で考えられているかどうか確認する」ことです。

Working Backwardsでおこなうこと

Working Backwardsのプロセスでは、新しい企画や機能を考える際に、お客様に関する5つの質問について考えます。

対象となるお客様は誰ですか？
お客様が抱える課題や改善点が明確ですか？
お客様が受けるメリットは明確ですか？
お客様のニーズやウォンツをどのように知りましたか？
お客様の体験が描けていますか？

この5つの質問についての回答を文面で作成し、メンバー間でレビューして確認します。

もちろん単にYES/NOで回答するわけではなく、そう言える根拠や具体例を添えて回答するようにします。
これは単に回答すること自体よりも、回答するプロセスを通して顧客視点でない部分を発見して再検討することが目的だと考えています。
そのため、既にお客様や関係者にヒアリングなどをして顧客視点から検討できている場合はスラスラと回答できますし、それで問題ないと思います。
一方で、ノリノリで新機能を企画したが、Working Backwardsをやってみたら全然回答できない(根拠がない)という状況の場合はお客様が本当に課題を抱えているのか、実現方法は適切かなどを改めて考えるチャンスです。

さらに、5つの質問に答えたあとは「プレスリリース」を実際に作成して、こちらもメンバー間でレビューをしてもらいます。

メリット

ここまですることでリリースする機能を客観的に見ることができるようになり、本当にこの体験をお客様が求めているのかについて理解が深まる効果がありました。

新機能の開発ではお客様が求めていない機能を作ってしまうことが一番最悪の結末だと思うので、このプロセスを挟むことで回避できると考えています。

ユーザーストーリーマッピング

背景

こちらは Working Backwardsよりも一般的な手法で、書籍も出版されています。

www.oreilly.co.jp

とはいえ私は書籍を読んだわけではなく、同じチームの先輩に紹介していただいて知りました。
さらに何度か実施する上で方法なども少しづつ変えているので、こちらで紹介する内容も本家ユーザーストーリーマッピングと完全に同じというわけではないと思います。

目的

ユーザーストーリーマッピングの目的はいろいろありますが一言でいうと「機能とストーリーの対応づけ」と「開発の優先順位」を整理するためです。

ユーザーストーリーマッピングでおこなうこと

ユーザーストーリーマッピングは開発に関わるメンバー数人で集まってワークショップ形式で行っています。
ただし、サービス開発課は完全リモートのチームなので、作図ツールのCaccoを使ってオンラインで実施します。
cacoo.com

まずはユーザーの体験を「アクティビティ」・「ステップ」・「ストーリー」に整理します(この呼び方も諸説あるようです)。
アクティビティは開発者視点から見ると「ユースケース」に近い概念で、例えばシンプルなタスク管理アプリで考えると「画面からTODOを作成する」のようなものです。
ステップはアクティビティを実現するために、ユーザーが行う操作です。例えば「内容を入力する」「締め切りを入力する」「サブミットボタンを押す」などです。
ストーリーはステップをさらに具体的にしたものです。ステップとほぼ同じ内容になることもあります。
例えば「テキストエリアに内容を入力する」「セレクトボックスで締め切りの年月日・時間を選択する」などです。
ストーリーは同じことをするストーリーでも複数挙げられる場合があります。
例えば「テキストエリアの下に入力可能な文字数がリアルタイムで表示される」「年月日をデートピッカーで選択する」などは先ほどの例よりもリッチなユーザー体験が期待できるストーリーです。
このようにして洗い出したストーリーを並べ替えて整理していきます。
これは作図サービスのCacooを使うと、次のようなアウトプットになります。

メリット

ここまで整理できると、ユーザーがある機能を実現するために何の実装が必要なのか明確になり、またその機能の品質(ここでは、ユーザー体験のリッチさ)も意識してコントロールできるようになりました。
もちろん、どこまで最初のリリースで開発するかなどは機能の狙いや検証したいことによって変わってくると思いますが、サービス開発課では最初は必要最低限の実装でリリースして後から機能を追加していくことが多いです。

さらに、「新機能を追加したことによる既存機能への影響」を整理できるという副次的な(?)メリットも感じています。
例えば「TODOにメンバーをアサインする」という新機能のアクティビティを検討する場合に、「TODOの締め切りが通知されるように設定する」、「TODOを表示する」などの既に実装されている機能のアクティビティも改めてステップやストーリーを洗い出していきます。そうすると既存機能の変更が必要な箇所や、変更は必要ないけどテストは追加したい箇所などが整理できて、よりシステム全体への影響が可視化できます。
例えば、「TODOにメンバーをアサインする」というアクティビィが追加された場合、「TODOを表示する」アクティビティなら「アサインされているメンバーが確認できる」ストーリーや、「TODOの締め切りが通知されるように設定する」アクティビティなら「どのメンバーに通知するか設定できる」ストーリーの追加を検討できます。

Example Mapping

背景

こちらのブログを読んだことをきっかけに試してみたところ、実装前に異常系やテストケースの整理がうまくでき、開発作業にメリハリがつけられると感じたため継続して取り組んでいます。

nihonbuson.hatenadiary.jp

目的

Example Mappingの目的は一言でいうと「これから開発する機能について理解を深めること」です。

Example Mapping で行うこと

Example Mapping についてはこちらの資料を参考に実践しています。
事例から学ぶ実例マッピングのやり方 / Example Mapping - Speaker Deck

Example Mappingもユーザーストーリーマッピング同様、開発メンバーで集まってワークショップ形式で行っています。
そこまでチーム独自のアレンジはしていませんが、リモートチームなのでユーザーストーリーマッピングと同様、Caccoという作図ツールを使っています。
Example Mapping ではユーザーストーリーマッピングを実施した後に、作成した「アクティビティ」を「ストーリー」として利用しています(ややこしいですが...)。
それぞれのストーリーに対して「ルール」とその具体例を追加していきます。

例えば先ほどのタスク管理アプリの例で続けると「セレクトボックスで締め切りの年月日・時間を選択する」に対しては「過去の日時は選択できない」というルールが思い浮かびます。
そこで、もしそのルールを仕様とする場合はそれに対してより具体的に「現在時刻が'2022年 1月 1日 0時0分 (UTC)' の場合、 '2021年 12月 31日 12時59分(UTC)' は選択できない」というテストケースレベルまで落とし込みます。

また、「ルール」にできるかどうか曖昧な「質問」も洗い出します。
例えば「99999年のような極端な未来の日付も扱えるか?」や「タイムゾーンはユーザーが選択できるか?」といった質問です。
質問に関してはその場ですぐ仕様が決められるならその場で決めてしまい「ルール」にしますが、そうでない場合は改めて別で仕様を決定します。

ちなみに、Example Mapping もユーザーストーリーマッピングと同様、ユーザーからみた仕様について検討するので実装や設計などとは直接関係ないのですが、Example Mappingを行う段階で大まかに設計や実装が方針レベルで検討されているとよりスムーズに進む感覚があります。
これは実装の方向性が意識できていると実装観点から質問を思い浮かんだり、質問から仕様を決める時も実装のやりやすさという観点から検討できたりするためです。

メリット

このようなプロセスを実装前に行うことで、機能の詳細まで理解できた状態で開発に移ることができるため、実装がスムーズに進みます。
Example Mapping をしない状態で開発に移ると高確率で「実装中に想定外の異常系の存在に気づく」ということが起きてしまいやすくなります。
その場合、次の2パターンのどちらかで対処されることことが多いと思います。

(機能全体への影響が小さい場合) 実装担当者が仕様を決めて実装する
(機能全体への影響が大きい場合) Slackなどで議論して仕様を決定(変更)する

1のパターンでは、異常系とは言え実装担当メンバーが単独で仕様を決めてしまうのはあまり良くはないですし、Pull Request のレビューで仕様レベルのコメントが必要になったり、仕様レベルで問題があった場合は実装のやり直しになり手戻りが発生したりしてしまう問題があります。
2のパターンでは、チームメンバー各自の実装の手が一旦止まってしまったり、場合によっては仕様変更によって手戻りが発生してしまうという問題があります。
あらかじめExample Mapping を行うことで、このようなリスクを潰しておくことができ実装タスクをより制御可能なものにできると考えています。
加えて、仕様を検討するフェーズと実装するフェーズが明確に分離することで、集中力を一つのことだけに向けられることも個人的に大きなメリットだと感じています。

課題

ユーザーストーリーマッピングとExample Mappingの共通の課題として多くの時間がかかってしまう点が挙げられます。
実際にどのくらいの時間をかけてどのくらいのメリットがあったかというところまで計測できているわけではないのですが、具体的には以前リリースした「スキップ日付指定」機能について実施した時には、1回2~3時間のMTGを4日に分けて行なったりしていました。 *1
1日に数時間とはいえ、終わらないと実装に着手できないので残りの時間も体感的に待ち時間のように感じてしまいます。

この課題に対するアクションとしては、作図ツールではなくテキストで箇条書きにして洗い出したり、既存機能のストーリーは一旦諦めて新規追加になるストーリーのみ洗い出すといったことを試してみています。
加えて、ワークショップ形式だと作図ツール上にカードを作ったり移動させたりする時間が待ち時間になりがちなので、先に誰か1人がざっくりと叩き台を用意しておくことも効果的ではないかと考えています。 (こちらはまだ試せていません。)

最後に

以上、サービス開発課で新機能の開発前に行っている取り組みについてご紹介しました。
実はこれらの取り組みも毎回できているわけでなく、たまにちゃんとできていないまま進んでしまう機能があったりするのですが、個人的にはその度に「やっておけばよかった」と後悔するくらいの意味のある取り組みになっていると思います。
この記事が機能開発に関わる方の参考になれば嬉しいです。

*1:この時はユーザーストーリーマッピングで 24アクティビティ・46ステップ・47ストーリー、Example Mappingで 24ストーリー・50ルール・14質問を整理しました。