TL;DR
- クラウドサイン開発チームにて「正しいものを正しくつくる」の著者であるギルドワークスの市谷聡啓さんによる仮説検証ワークショップを開催していただいたので共有します
- ソフトウェア開発において、何をどのように作るのかの「何」の部分をどうやって決めていくかについて、ディレクター・デザイナー・エンジニアが集まりその方法を学びました
簡単に自己紹介
私は弁護士ドットコム株式会社にてクラウドサインという契約締結ウェブサービスのエンジニアチームマネージャをしています。クラウドサインではスクラム開発を取り入れており、私はスクラム開発チームのスクラム・マスターもしています。
背景
クラウドサインの開発組織ですが、現在はディレクター、エンジニア、デザイナー含め20名を超える規模になっています。
組織が大きくなるにつれ、メンバー間での情報非対称性が現れはじめている状況でした。
また、ちょうど一年ほど前に開発メンバーでValue Stream Mappingを実施したところ、実装に至る前の仕様検討段階におけるリードタイムが長いということもわかっており、ディレクターと開発メンバー間の意思伝達にも改善の余地がありそうでした。
目的
ワークショップの目的は”問題から、仮説を立てて、検証方法を練る”を通しで行なう。 でした。
さらにこれらを通しで行うことによって、上記のメンバー間での意思伝達や目線合わせにも一定の効果があるのではないかと考えました。
参加者
参加メンバーはディレクター、エンジニア、デザイナーあわせて16名ほどでした。その中で４名ずつ、４つのグループに別れてのワークショップを行いました。
当日のアジェンダ
ワークショップは大きく４段階で構成されていました。
1.仮説検証とは
2.仮説を立てる
3.ユーザー行動フローを描く
4.検証方法を練る
1.仮説検証とは
最初に市谷さんの自己紹介から始まり、仮説と検証の定義を整理するところから始まりました。仮説と検証というものをなんとなくではなく、どのような要素で定義されているのかを理解した上でワークショップに挑めるようにしてもらいました。
そもそも仮説とは？
最初に仮説 とは何かという根本的な部分から整理していただきました。
ユーザーが過去にとった行動の理由を調査するのではなく、将来に我々がどのような価値提供すべきかを考えることが 仮説となります。
仮説を整理する
さらに仮説も要素分解することができるということで、状況、要望、提案価値、ソリューション、目的の５つに要素分解して仮説を整理することができることを学びました。仮説と検証はセットで考える必要があるため、これらの要素に分解することでその後の検証がしやすくなるというメリットがあります。
仮説キャンバスで整える
そして、個々の要素の関係性やより具体的な数値情報を仮説キャンバスというLean Canvasに似たフォーマットを使って、提案価値と課題の関係や代替手段などを整理する方法を学びます。
Lean Canvasもそうですが、仮説キャンバスを使うことで全体像を短時間でつかめるという利点があります。
検証方法を学ぶ
仮説が整理できたら、次はその仮説が正しいかを検証する必要があります。検証といってもその方法は色々あるため、精度と頻度の２つの観点で選択するのが良いと教えていただきました。
たとえば、ユーザーインタビューは精度よりも頻度が高い方法ですが、プロトタイプでの検証は具体性が増し、頻度よりも精度が高くなります。このあたりは担当しているプロジェクトの状況や目的に応じて使い分けていくのが良さそうです。
2.仮説を立てる
仮説と検証の方法を学んだところで実際に仮説キャンバスをグループにわかれて作成しました。
キャンバスを作る際のポイントとしては、付箋紙に色をつけて事実と仮説が判別できるようにすることでした。これをすることによって、最終的に検証すべき仮説が何かを見分けやすくなります。
仮説キャンバスに整理することで何が事実で何が仮説なのか、課題に対する解決方法は何なのかが網羅できるようになり、またメンバー内での認識が揃っていきました。キャンバスのない状態では会話が発散したり論点を見失ったりしがちですが、そのようなこともなく短時間で話がまとまっていきました。
3.ユーザー行動フローを描く
次にユーザー行動フローを整理します。カスタマージャーニーマップのように左から右へと時間が流れていく過程でユーザー行動を１ステップずつ整理していきます。登場人物が複数いる場合はそれぞれにどのようなステップが必要になるのかを考える必要があります。クラウドサインの契約締結フローでは送信者と受信者が存在するため、それぞれの視点でどんなステップがあり、どのような課題があるのかを洗い出しました。こちらも仮説キャンバス同様に付箋紙を色分けするのがおすすめです。黄色がステップ、赤色が課題、緑色が解決方法といった具合です。
先程のキャンバスと違い、行動フローを整理することでサービス内におけるどの段階に課題が集中しているのかなどがわかりやすくなりました。クラウドサインで言えば契約締結は契約書の送信者と受信者がいますが、そのどちらに課題があるのかが可視化されていきました。そしてこれが一番重要だと感じたのですが、可視化されることにより参加者全員が同じ認識を持つことができました。
4.検証方法を練る
最後に、これまで整理した仮説をどのような方法で検証するのかを整理します。どんな仮説なのか、どのような指標で計測できるのか、検証に必要なものは何か、どのような検証方法があるのかを洗い出します。
ワークショップを終えて
駆け足で説明しましたが、ワークショップを終えた最初の感想としては、参加者の課題意識がかなり整理されたということでした。（具体的な内容は書けませんが）
エンジニアはとかく何を作るかよりもどのように作るかに思考が向きがちですが、今回のワークショップを通じて、課題を見える化することと、仮説と検証を考えることで間違った解決方法を早い段階で修正できることを学びました。
アンケート
ワークショップ後に参加メンバーにアンケートを取らせてもらいました。このような取り組みは今回初めてだったので改善すべき点もありますが、学びも多い時間となりました。
今後の課題
ワークショップで学んだ方法論や考え方を実務に活かさなければ意味がありません。今回は色々学ぶことができたので、これを今後の実務にどうやって活かしていくかを現在検討しているところです。