※この記事は、2024 Speee Advent Calendar12日目の記事です。 昨日の記事はこちら
こんにちは、DX事業部のエンジニアの中嶋です。
プロダクト開発ではユーザーの課題を解決するため、要件、設計、アーキテクチャといった多くの「手段」を日々検討しています。
手段を検討するなかで意識的か否かに関わらず行われているのが「意思決定」です。感覚的な意思決定をしてあとで後悔をしたり、意思決定に時間をかけすぎることはしばしばあります。こうした問題は、意思決定プロセスの質を高めることで改善できます。よい意思決定プロセスは、より筋のいい手段を導きます。
本記事では、私の開発チームで実践している意思決定プロセスを紹介します。
意思決定はプロセスが大事
プロダクト開発ではユーザーの課題を解決するため、要件、設計、アーキテクチャといった多くの「手段」を日々検討しています。手段には、筋のいいものと悪いものがあります。ユーザーの課題を効果的に解決するためには、できる限り筋のいい手段を選びたいものです。
筋のいい手段を選ぶために重要なのが、意思決定プロセスです。意思決定プロセスの質を上げていけば、筋のいい意思決定が100%できるわけではありません。ただ、筋の悪い手段を選んでしまった要因を辿っていくと、しばしば、意思決定プロセスに何らかの問題を抱えていることがあります。意思決定プロセスの質は、確実に課題解決のスピードとクオリティを左右します。
規範的な意思決定プロセス
意思決定プロセスは、次のステップを踏みます*1*2。このプロセスを実際に進める際には、ステップが前後しても大丈夫です。一通りのプロセスを踏んだ上で、最初のステップに戻っても構いません。
- 意思決定課題を特定する
- 評価基準を発見する
- 選択肢を生成する
- 評価基準をもとに各選択肢を評価する
- 評価結果から選択肢を選択する
では、例を交えながらそれぞれのステップについて紹介していきます。
1. 意思決定課題を特定する
まず、決めることが何であるかを特定します。課題を解決するうえで、手段に関する仮説があります。ただ、選択肢となる手段はさまざまで、それぞれに筋の良し悪しがあります。この状況においてどの選択肢を選ぶべきか。これが意思決定課題の特定です。
住所データの更新を例に考えると、次のようになります。あくまで住所データは例なので、住所以外に馴染みのあるマスターデータがあればそれに読み替えてもらって大丈夫です。
- 手段の仮説
- 全プロダクトで共通利用できる住所マスターサービスなどがあれば、住所データの更新の手間を減らせるのではないか
- 解決したい課題や提供価値
- 住所データの更新の手間
- ユーザにとっては、最新の住所データで申し込みができたり、コンテンツが閲覧できる
- 意思決定の対象
- 複数プロダクトで共通利用できる住所マスターデータの方式
解決したい課題の記述としては、ややゆるいですが、ゆるいものであってもまずアウトプットすることが大事です。
2. 評価基準を発見する
先ほど述べた通り、プロダクト開発の目的は、ユーザーの課題を解決することです。ユーザーの課題を解決するために、筋のいい手段を選びたいわけです。
筋のいい選択肢とはどのようなものか、これが評価基準です。評価基準は、課題を解決するためにその手段が満たすべき制約条件ともいえます。ユーザーへの提供価値、事業戦略、プロジェクトの状況などさまざまな観点で、評価基準を出します。
最初は「こういう評価基準が必要じゃないか」という仮説で構いません。プロセスを進めるなかで、新たな評価基準が見つかればそれも加えます。
住所データの更新を例にするなら、次のような評価基準が考えられます。評価基準は、その基準が必要な理由も併せて考えます。
- 評価基準: 住所データの検索・取得のパフォーマンスが良好であること
- 理由: 住所データは各プロダクトのなかで広く使われており、住所データのパフォーマンスがプロダクトの各機能のパフォーマンスに直結するため
- 評価基準: 複数プロダクトでも住所データの更新が容易な住所データの持ち方になっていること。頻度は年一回程度
- 理由: できるだけ最新の住所データを入力して申し込みができたり、コンテンツの表示ができる
- 評価基準: 開発工数、運用工数を大きく割かずに済む方式であること
- 理由: 住所データは、プロダクトにおいて必要なコンポーネントだが、プロダクトのコア機能ではないため
3. 選択肢を生成する
筋のいい手段を選ぶには、そもそも選択肢を増やす必要があります。手段の選択肢が1つしかないと、最初に思いついた手段の良し悪しによって、結果が左右されてしまいます。そのため、少なくとも3つの選択肢を出したいです。
住所データの更新を例にするなら、次のような選択肢が考えられます。
- 選択肢1. 住所マイクロサービスを作り、アプリケーションからサービスAPIを呼び出し、住所データを取得する
- 選択肢2. 住所データを格納したRubyGemsを作り、アプリケーションからRubyGemsを利用し、住所データを取得する
- 選択肢3. 各アプリケーションのテーブルに住所データを格納する
4. 評価基準をもとに各選択肢を評価する
それぞれの選択肢について、評価基準もとにメリットとデメリットを評価します。
住所データの更新を例にするなら、次の評価が考えられます（記事が長くなるので、選択肢2は省略しています）。
- 選択肢1. 住所マイクロサービスを作り、アプリケーションからサービスのAPIを呼び出し住所データを配布する
- メリット
- 評価基準: 複数プロダクトでも住所データの更新が容易な住所データの持ち方になっていること。頻度は年一回程度
- アプリケーションと住所データが疎結合になっており、住所データの更新がしやすい
- デメリット
- 評価基準: 住所データの検索・取得のパフォーマンスが良好であること
- APIリクエストによるレイテンシーがあり、パフォーマンス特性が悪い。キャッシュによって改善できるが、データ更新時にキャッシュをクリアするなど運用工数が増加する
- 評価基準: 開発工数、運用工数を大きく割かずに済む方式であること
- 新しいサービスを開発する必要があり開発工数が大きい
- アプリケーションに加え、マイクロサービスの運用が必要になるため、運用工数が大きい
- 住所マスターはプロダクトにおいて重要だがコアドメインではない。住所マスターに大きな時間を割くべきではない
- 選択肢3. 各アプリケーションのテーブルに住所データを格納する
- メリット
- 評価基準: 住所データの検索・取得のパフォーマンスが良好であること
- マイクロサービス方式のようなAPIリクエストのレイテンシーがないため、パフォーマンスが良好
- パフォーマンスは、SQLクエリ次第だが、大半はシンプルなwhere句やjoin句であるため問題にならない
- 評価基準: 開発工数、運用工数を大きく割かずに済む方式であること
- 新しいサービスを開発する必要がなく、開発工数を小さくできる
- ORMを使って住所データの検索、取得ができるため、普段のアプリケーションと同じ方法で開発ができ、運用工数が小さい
- デメリット
- 評価基準: 複数プロダクトでも住所データの更新が容易な住所データの持ち方になっていること。頻度は年一回程度
- アプリケーションと住所データが疎結合になっておらず、住所データの更新はしづらい
- ただし、市区町村ごとのコンテンツの表示設定といった、住所データを参照するデータも同時に更新する必要があるため、仮に住所データとアプリのデータが疎結合で住所データが更新しやすくなっていたとしても、結局住所データとアプリのデータの両方を更新しなくてはならず、効果が薄い
- また、統廃合のある市区町村は年に数件しかないため、住所データの更新のしやすい設計の重要度は相対的に低い
5. 評価結果から選択肢を選択する
ステップ4の評価から採用する選択肢を決めます。選択肢を決める際には、その選択肢を選んだ意図を明確にします。どのようなベネフィットをとって選択肢を選んだか、どのようなトレードオフを受け入れて選択肢を選ぶかが、選択肢の意図です。
ここまでのプロセスを経て、ネガティブだと思っていたが、実はネガティブ要素ではないと気づいたことや、ネガティブではあるが工夫で乗り切れることも、あわせて言語化します。
住所データの更新を例にするなら、次のようになります。
- 採用する選択肢
- 選択肢1. 「各アプリケーションのテーブルに住所データを格納する」を採用する。
- 選択によるポジティブな影響
- 住所データの検索・取得のパフォーマンスが良好であり、開発コスト、運用コストともに小さいため
- 選択によるネガティブな影響
- アプリケーションごとに住所データを持つ方式のため、プロダクトの数だけ住所データの更新を行う手間が必要になる
- ただ、統廃合のある市区町村は年に数件しかないため、更新の手間は小さく、十分受け入れられるトレードオフである
- また、いずれの選択肢においても、住所データとアプリ固有のデータを同時に更新する必要があり、選択肢2を選ぶ強い動機が存在しない
いい意思決定プロセスを踏むことで得られる成果
こうした意思決定プロセスを丁寧に踏んでいくことで、次の成果が得られます。
- 課題解決のための現実的で最良の手段を選べること
- 過去の意思決定の振り返りができること
- 組織の意思決定の精度を高められること
課題解決のための現実的で最良の手段を選べること
このような意思決定プロセスがなくても、「1. 課題の特定」にあたるプロセスは、普段から行っているかもしません。
「1. 課題を特定する」の例を以下に再掲します。これはいわば最初に閃いたアイデアです。「こんなことができれば、こういう問題が解決できるんじゃないか」といったものです。どんなアイデアもまずここから始まります。
- 手段の仮説
- 全プロダクトで共通利用できる住所マスターサービスなどがあれば、住所データの更新の手間を減らせるのではないか
- 解決したい課題や提供価値
- 住所データの更新の手間
- ユーザにとっては、最新の住所データで申し込みができたり、コンテンツが閲覧できる
- 意思決定の対象
- 複数プロダクトで共通利用できる住所マスターデータの方式
閃いたアイデアはキラキラして見えます。マスターデータを配布するマイクロサービスなど、いろんなアイデアが浮かんできます。しかし、本当にいいアイデアでしょうか。
意思決定プロセスにおける評価基準の選定、選択肢の生成、評価のプロセスは、こうしたキラキラしてみえるが大きなトレードオフを持つアイデアを慎重に取り除き、ユーザーへの課題解決において現実的で最良の手段を選ぶのに役立ちます。
過去の意思決定の振り返りができること
構造化された意思決定プロセスがあれば、プロセスに沿ってドキュメントが残せます。ドキュメントに残しておくことで、時間が経ってからでも、意思決定の背景や結果を振り返ることができます。
例えば、何らかの理由で過去の意思決定を見直したいとき、ドキュメントが残っていれば、そこに書かれた当時の意思決定の背景を踏まえて、より精度の高い意思決定ができます。もし、ドキュメントが残っていなければ、当時の関係者にヒアリングをしながら、意思決定の背景を掘り起こしていく必要がありますし、関係者がすでに退職している場合もあり、背景を完全に掘り起こせるとは限りません。
中長期に渡り、持続可能な方法でユーザーに価値を届けていくためにも、意思決定の記録を蓄積していくことが大事です。
組織の意思決定の精度を高められること
冒頭で述べた通り、プロダクト開発では日々要件、設計、アーキテクチャといった多くの「手段」を検討しています。こうした検討には、そのプロダクトで固有なものもあれば、プロダクト間で共有できるありふれたものもあります。例えば、ReactやVue.jsといったUIライブラリの検討などです。
こうしたありふれた検討は、他のチームですでに行なった意思決定プロセスを参考にすることで、検討する時間を大幅にショートカットできます。DX事業部においても、先行プロダクトで書かれた意思決定ドキュメントを、後発プロダクトの開発チームが参考にして意思決定することが増えています。
いい意思決定プロセスを踏むために大事なこと
意思決定プロセスをドキュメントに残すこと
意思決定プロセスをドキュメントに残すことで、評価基準や選択肢の妥当性をチームでレビューできます。また、先ほども述べましたが、後から意思決定のプロセスを振り返るためにも、ドキュメントに残す必要があります。
中長期に渡り、持続可能な方法でユーザーに価値を届けていくために、意思決定のプロセスをドキュメントの形で蓄積していくことが重要です。
仮説を立てて決めること
筋のいい意思決定をしたいと常に思う一方、意思決定のプロセスは簡単ではありません。どんな評価基準が必要か、どんな選択肢を並べていくかなど、意思決定のプロセスのなかにおいても、数多くの意思決定が必要だからです。常に評価基準や選択肢が精度高く洗い出せるわけではないですし、それを行うための時間も限られています。
大事なことは、仮説を立てて決めることです。評価基準は、ユーザーにとって、プロダクトにとって、こうあるべきじゃないかという仮説です。選択肢も、こういう手段ならやりたいことが実現できるんじゃないかという仮説です。一定の不確かさがある仮説であっても、仮説があるからこそ、確からしいロジックをもとに意思決定ができ前へ進めるのです。
意思決定を正解にすること
意思決定プロセスを経て決めたことを正解にしていくことが大事です。
どんな選択肢を選んだとしても、多かれ少なかれ問題は起きます。問題が起きるたびに、選ばなかった選択肢を羨ましく思っても、問題は解決しません。選んだ選択のなかで問題を解決していき、その選択を正解にしていくことが大事です。選んだ選択のなかで起きた問題を解決することが学びになり、次の意思決定プロセスに活かせるはずです。
まとめ
意思決定のプロセスの質は、プロダクト開発における課題解決のスピードとクオリティを大きく左右します。この記事では、規範的な意思決定プロセスを5つのステップに分け、具体的な例を交えながら解説しました。
- 意思決定課題を特定する
- 評価基準を発見する
- 選択肢を生成する
- 評価基準をもとに各選択肢を評価する
- 評価結果から選択肢を選択する
最後に、いい意思決定プロセスによって得られる成果と、いい意思決定プロセスのための重要なポイントを紹介しました。
この記事がプロダクト開発における課題解決のスピードとクオリティを高めるための一助となれば幸いです。
Speeeではサービス開発をともに推進していく仲間を募集しています。
Speeeではさまざまなポジションを募集中しています。募集中のポジションは、こちらから確認できます。もちろん、募集中のポジションに限らず、気になる方はカジュアル面談を気軽にお申し込みください。
