価値提供プロセスを試行錯誤し続けてきた話

2023/01/19 19:30- 『エンジニアの失敗の哲学2022 - 2023 〜失敗を生かして最高の1年のスタートをきろう〜』にて

#Forkwell_失敗の哲学

Transcript

1. 価値提供プロセスを 試行錯誤し続けてきた話
2. 自己紹介 株式会社トドケール 執行役員CTO Twitter: @hayata_yamamoto GitHub: hayata-yamamoto 山本隼汰（やまもとはやた） 2
3. アジェンダ 1. 弊社がたどってきた価値提供プロセスの遷移とそれぞれのPros/Consを共有 2. 価値提供プロセスの遷移は本当に必要だったのか？について私なりの考察を共有 3. 小さいスタートアップ企業に関心を持たれる方に向けて（おまけ） 3
4. 価値提供プロセスの遷移は本当に必要だったのか？ 結論、どんな人たちでチームが構成されていて、どのようにその人たちが考えているかによって全て決まる 4 • 弊社の場合は、多かれ少なかれ価値提供プロセスの試行錯誤をせざるを得なかった ◦ どんなに一般的には、アイデアを検証したり、事前に要件を決めたりするのが大切だとわかっていても、 事業を伸ばしていく責任と、目の前に困っている顧客がいる状況、かつプロダクトを改善すれば解決できると思える場合、 それでも顧客を待たせて、自分たちのやるべき開発にフォーカスできるようになるには各人の中に信じれる絶対的な経験が必要 • もし最終的に到達する価値提供プロセスが既知であるならば、もちろん最初から適切なものを選べばよい ◦ が、現実的には一般的にうまくいくメソッドやプラクティスを真似することはできても、それが実際にチームに馴染むとは限らず、 結果として試行錯誤を行うことになってしまうことが多いのでは？ • そもそもプロダクトを取り巻く外部環境や事業進捗に応じて、価値提供プロセス自体も見直されてよい ◦ QCDの観点から見ても、経営戦略・技術戦略の解像度から見ても、長期的なビジョンがどれくらい明確に見えていて、 そこに向かっていく道筋がどれくらい実現可能である、と社内で働くメンバーが信じきれるかに応じて、 その時最適な価値提供プロセスがデザインされることが望ましい
5. 現在運用している価値提供プロセス ディスカバリー、デリバリーの２つのフェーズで構成される価値提供プロセスを運用しています 5 ディスカバリー デリバリー
6. 価値提供プロセス ディスカバリー、デリバリー 6 • ユーザー体験を記述したバックログを運用 • 開発プロジェクトであれば、実際にプロダクトの機能を開発するフェーズ • ディスカバリーで決まった課題やユーザーに提供する体験を元に、見積もりを実施する • 見積もりをベースに、リリース見込みを特定したのち、提供までの不確実性の度合いに応じてスプリントを計画 し、スプリントごとに進行度合いを確認しながら提供完了を予測しながら開発を進めます Delivery / デリバリー • プロダクトに対する要望やプロダクトが抱える課題を整理したバックログを元にアイデア検証を行う • デザインスプリントのフレームワークをベースにしている • ユーザー理解・問題定義・スケッチ・決定・プロトタイプ・テスト、などのプロセスを経ながら、 どんな体験をユーザーに提供するかや、体験を提供するにあたり何が必要なのかを特定する • このフェーズで明らかにした課題や提供する体験は、最終的にレビューされ次のフェーズに進むか意思決定 する Discovery / ディスカバリー この２つのフェーズを１つにまとめたものを プロジェクトとしている。 プロジェクトにはロール問わず、価値提供サ イクルに関わる全てのメンバーが参加し、プ ロジェクトの最初から最後まで一貫して関 わってもらう
7. チーム内での会話 「顧客の課題をもっと効率的に抽出したい」 「機能提供のサイクルをもっと効率的に、予測可能 に行うにはどうしたらいいか」 価値提供プロセスの遷移 チーム内での会話 「とにかく早く機能を顧客に見せたい」 「まずは作って出すんだ、細かいことはそのあと考 えればいいだろう」 人数の少ないスタートアップなのに ?だから? 価値提供プロセスは短い間に遷移して行った とにかくデリバリー優先で、 顧客にプロダクトを届けていた時期 チーム内での会話 「顧客の課題ってなんだっけ？」 「本当にこの機能、この方法で提供して効果あるん だっけ？」 ディスカバリーを頑張ろうとしすぎて、デリ バリーに影響が出た時期 ディスカバリー、デリバリーのバランスを整 えてきた時期（現在進行中） 7
8. とにかくデリバリー優先で、顧客にプロダクトを届けていた時期 もがきながら、積み上がった開発バックログをとにかくスピード重視で解き切る 8 • バックログは開発用のバックログだけを運用 ◦ どんな機能が必要か、それはどんな機能か、 UIか、などが簡素に書かれたものが中心 ◦ 顧客要望のたびにバックログが増えていくため、リファイメントが大変 • 開発チームのキャパシティに対してベストエフォートで対応 ◦ タスクに対して見積もりをとったのち、（できる限り）バックログを上から順番に対応 ◦ 一応スプリントらしきものも運用していたが、締め切り効果を持たせる目的が主 • PM の役割は、CEOやCTOが担っていた ◦ 忙しくなるとボトルネックになりがち • コミュニケーションは、 Slack, Jira を中心にエンジニアが馴染み深いものを選んで使用 ◦ 逆に、非エンジニアからすると、使い方からわからず情報ギャップを生み出した側面もある
9. 結果はどうだった？ 短期は◦、長期は？ 9 • 重複した実装、十分に検討されていないアーキテクチャの採用など、スピード意識に加えてプロダクトを作る当 事者たちの思惑が交錯し、提供している機能に対して複雑度が指数関数的に増加した • 複雑度の増加に比例して、機能の安定性を向上させるために暗黙的に決まってしまう仕様が増え、テストケー スも増大したため、エンドユーザーやそれに近い領域を社内で担当するメンバーがプロダクトを理解しにくい状 況が発生した • 機能を作ることが目的化してしまうことにより、本当に解決したかった課題に向き合う時間が十分に確保できて おらず、PDCAをしっかり回せないことによって組織学習を促すことが十分にできていなかった Cons • マーケットインにスピード重視で開発したおかげでプロダクトの立ち上げにあたり課題となる 「顧客はプロダクトのどのような点に価値を見出して使ってくれるのか」を解き明かすことができた • 数少ない顧客に対して、ビジネスサイドが前向きなスタンスを取ることができ、エンドユーザーからみるとプロダク トフィードバックが反映されやすく、どんどん改善が進むプロダクトとして認知された • 使われるのかまだ十分に明らかではなく、顧客の声も十分に獲得できない中で作りすぎない程度に機能を提 供し、顧客の声を集めることにフォーカスできた Pros 短期的には、実際にも効果があり、チーム 内の議論も活性化した。プロダクトが顧客に 使われることによって自信にもなり、勢いが ついていく。 一方で、先延ばしにしている問題も都度都 度増えていく状況ではあり、いつかは対処 しないといけない問題が積み上がっていく のも事実
10. ディスカバリーを頑張ろうとしすぎて、デリバリーしにくくなった時期 顧客の課題発見に時間を使うことはできたが、デリバリーの生産性は下がった 10 • 一定程度、プロダクトを顧客が使ってくれるようになってきて、顧客のニーズに素直に答えると別の顧客の不満を生み出すトレードオフが生まれた ◦ 顧客が抱えている本当の課題はなんだったのか？を解き明かすことが重要となった ◦ 顧客ペルソナの定義、リーンキャンバス・カスタマージャーニーマップの整理を実施 • ディスカバリー用のバックログとデリバリー用のバックログを明確に分け、それぞれのフェーズにフォーカスできるように運用体制を変更した ◦ 顧客要望がデリバリー用のバックログに入ることはなくなり、デリバリーのみに関しては見通しが良くなった ◦ が、実態としてはデリバリーの際に合わせて行っていたユーザーの課題特定や仕様の定義が、ディスカバリーに前倒しされただけはあった • ディスカバリーとデリバリーを独立なものとして考え、それぞれを最適化しようとした ◦ ディスカバリーはビジネスサイド含む多くの人が関わることができた ◦ 一方で、デリバリーは専門性の問題もあり、チームにいるエンジニアやデザイナーの数に依存して決まった • 全員でPMを担う方式への転換 ◦ ロールに問わず、手を上げさえすれば誰でもプロジェクトの PMを行える体制に移行した。 CEO/CTOボトルネック問題の解消 • コミュニケーションは、 Slackを中心にディスカバリーは NotionとFigma、デリバリーは NotionとGitHubで実施した ◦ 課題がどのように対応されているか、どのような体験が提供されるかを非エンジニアでも理解できる状態となった
11. 結果はどうだった？ 短期ばかりに目を向けず、長期的な視点で プロダクトを考えられるようになった。 が、一方で短期的な価値提供のサイクルを 遅延させることになり、エンドユーザーに近 ければ近いほどもどかしさを感じる結果に。 短期？、長期◦ 11 • ディスカバリー、デリバリーを独立なものとして考えてしまったがゆえに、スループットの違う二つのフェーズのバ ランスがうまく取れず、結果としてディスカバリーされたアイテムがデリバリーのバックログにたまる状況が続いた • 顧客の声がなかなか反映されていかないことに対して、エンドユーザーに近い立場のメンバーは少しもどかしさ を感じる瞬間が増えた • ディスカバリーを頑張りすぎるあまり、時間のかかる探索作業に限られたリソースの多くが配分され、 デリバリーにかけられる時間が大幅に減少してしまった Cons • 我々は誰のどんな問題を解決するためにプロダクトを開発しているのかが共通認知となり、 マーケットインだけではなく、プロダクトアウトの側面をチームで持つことに成功した • ある機能を開発する際に、「その機能をどれくらい今後成長させるのか」という視点が追加され、 開発した機能を資産として成長させる共通認識を持つことができた。またそれが、各種設計にもその哲学や思 想が反映されるようになった • 価値提供サイクルが低速になることにより、今まで開発してきた機能の棚卸しを行うことができるようになり、客観 的にみて「本当にこの機能必要なんだっけ」と議論し、プロダクトを洗練化できた Pros
12. ディスカバリー、デリバリーのバランスを整えてきた時期（現在進行中） 価値提供プロセスを要素還元主義的に考えることをやめ、統合的に扱うように 12 • ディスカバリー、デリバリーを個別最適化したところで、価値提供プロセス全体の生産性は向上しないことがわかった ◦ デリバリーの生産性を安定させ、かつどの課題からディスカバリーしていくかを評価し、現実的にスムーズな価値提供ができる形で運用 • 限られたキャパシティを効率的に管理しながら開発を進めるため、ディスカバリー・デリバリーそれぞれをロードマップ上で進行管理 ◦ 同時に走っているプロジェクトがどれくらい存在するのかを可視化し、過剰にプロジェクトが進行しないように制御 • コミュニケーションは Slack をメインに、ディスカバリーは変わらず NotionとFigma を中心に。デリバリーはほぼ GitHub を中心に移行 ◦ 非エンジニア向けの情報共有は継続して安定し、エンジニア向けの情報共有は馴染み深い GitHub上で完結するようになった ◦ 開発する際は基本的に GitHubだけを見ていれば必要な情報にアクセスできるように再設計された
13. 現時点での結果はどう？ 短期と長期のバランスを取る目的は、まだま だ改善の余地はあるが、以前よりはマシに なった。 短期△、長期◦ 13 • デリバリーの生産性向上には、価値提供プロセスに依存しない独立したイネーブルメント組織やシステム仕様 の洗練化、開発プロセス自体の改善など、ソフトウェア開発に依存する問題解決が必要となった ◦ そこそこの人員がいないとそもそも仕組みとして機能しない • デリバリーの生産性は一朝一夕では向上しないため、ディスカバリーしたいのに待たなくてはいけないもどかし さを抱えている Cons • 価値提供プロセスを統合的に捉えることによって、プロセス全体の生産性向上を考えることができるようになった ことに加えて、ディスカバリー用のバックログに課題がキューイングされるようになった • デリバリーに合わせてディスカバリーを行うようになり、実施されるディスカバリーの総数が減少し、客観的に見 て「どうやったらディスカバリーを効率的かつ効果的に行えるか」「ディスカバリーはデリバリーの生産性向上に どう貢献できるか」を考えることができるようになった • 価値提供プロセスが全体通してスムーズに進行できるようになり、仕掛かり中のまま止まる課題が減少した Pros
14. 価値提供プロセスの遷移は本当に必要だったのか？ 結論、どんな人たちでチームが構成されていて、どのようにその人たちが考えているかによって全て決まる 14 • 弊社の場合は、多かれ少なかれ価値提供プロセスの試行錯誤をせざるを得なかった ◦ どんなに一般的には、アイデアを検証したり、事前に要件を決めたりするのが大切だとわかっていても、 事業を伸ばしていく責任と、目の前に困っている顧客がいる状況、かつプロダクトを改善すれば解決できると思える場合、 それでも顧客を待たせて、自分たちのやるべき開発にフォーカスできるようになるには各人の中に信じれる絶対的な経験が必要 • もし最終的に到達する価値提供プロセスが既知であるならば、もちろん最初から適切なものを選べばよい ◦ が、現実的には一般的にうまくいくメソッドやプラクティスを真似することはできても、それが実際にチームに馴染むとは限らず、 結果として試行錯誤を行うことになってしまうことが多いのでは？ • そもそもプロダクトを取り巻く外部環境や事業進捗に応じて、価値提供プロセス自体も見直されてよい ◦ QCDの観点から見ても、経営戦略・技術戦略の解像度から見ても、長期的なビジョンがどれくらい明確に見えていて、 そこに向かっていく道筋がどれくらい実現可能である、と社内で働くメンバーが信じきれるかに応じて、 その時最適な価値提供プロセスがデザインされることが望ましい
15. 小さいスタートアップ企業に関心を持たれる方に向けて（おまけ） プロダクト黎明期、初期における開発を取り巻くカオスさを理解しておこう 15 • 「スタートアップはカオスだよ」と時々聞くが、「カオスって結局なんやねん」と思った人へ ◦ プロダクトを取り巻く不確実性が変化しやすいことによって、組織のあり方や開発プロセス、重視しないといけない事項が連動して変化し、 結果として、自分たちの予測できない形で、自分たちが依拠してきた前提が全て変わってしまう状況が起こり得る ◦ もちろん、作業や手続きを定式化・標準化することはできるが、意思決定の前提がどの程度持続するかは不明。 仮に前提が崩されてしまうと混乱が生じ、それが混沌さのように見えてしまう。 • では、混沌さは悪か？ ◦ そんなことはない。混沌さがある企業で働く方がきっと楽しい（と私は思う） ◦ 組織とプロダクトが周辺環境から学習し、それに応じた対応を講じた結果として、混沌のようなものが生まれている。 とすると、混沌があるということはスタートアップが何がしか成長・変化しているということのある種、証明であると考えてよい ◦ 実は、スタートアップにいるメンバーも全員が混沌を楽しんでいるわけではない。むしろ、混沌さを受け入れつつ、混沌が辛いのも否定せずに、組織内 に秩序を再構築すべく議論をしていく過程がスタートアップの面白さなのではないか？ ◦ そしてこの脱構築 →再構築の回数は、小さなスタートアップであればあるほど多い