はじめに
プロダクトデザイン室データユニット 新卒２年目エンジニアの高草木です。
弊社ではLLM Boot CampというLLMを使った新機能を3週間でリリースする施策を2023年5~6月に行なっていました。 本記事では、短期間で不確実性の高い開発を行うにあたって、モメンタムを意識して開発プロセスを変えた話について執筆します。
他のLLM Boot Campは下記をご覧ください！
何を開発したか？
ヘルススコア改善のための意思決定支援アプリを3週間で開発しました。
ヘルススコアとは
弊社では、プロダクト利用者の状態や満足度を数値化し、解約リスクの統合指標「ヘルススコア」を運用しています。
参考: ヘルススコアはカスタマーサクセスの実現には必須！(Gainsight様ブログより)
ヘルススコアの課題
「解約リスクを検知できても、ヘルススコアを改善する打ち手を考えるのが難しい」ことが課題としてありました。
例えば、ヘルススコアの１変数として「プロダクト利用者のアクセス率」があります。解約リスクからアクセス率が低いことは認識できても、アクセス率を上げるための打ち手立案は難しいです。
ヘルススコア改善のための意思決定支援アプリの概要
解約リスクに対する打ち手を立案するアプリケーションを開発しました。
バックエンド：
・弊社のベテランのカスタマーサクセスのナレッジを収集し、データ化しました。
・ナレッジをコンテキストとしてOpenAI-APIに打ち手を立案するプロンプトを投げ、打ち手をレスポンスとして返すようにしました。
フロントエンド：
Google Workspace Addonを使用して、Google Workspace 利用時にいつでも参照できるように実装しました。
そもそもモメンタムって何？
一言で言えば、チームの勢いです。
スタートアップにおいて、よく引用される概念です。
OpenAI創業者サム・アルトマン氏のブログでも、モメンタムの重要性が強調されています。
The prime directive of great execution is “Never lose momentum”
素晴らしい目標達成において最優先すべきは、「決してモメンタムを失わない」ことである
サムアルトマンブログ: Startup Playbookより引用
モメンタムを知った背景
学生の頃、スタートアップを自称して１年間プロダクト開発をしていた時がありました。
当時PMから「モメンタムを保て」とアドバイスを受けチームの中でモメンタムを合言葉としていました。
合言葉にしていたものの僕自身「なぜモメンタムか」の問いには答えられず、結局資金とエネルギーがなくなって消滅しました。
短期間で不確実性の高い新規開発の機会が巡ってきたので、当時と状況が似ていることを思い出したのがきっかけでした。
モメンタムがある時 / ないとき
モメンタムがないと、様々なよくない事が起こります
モメンタムがある時は、良い事があります
| あるとき | ないとき |
|---|---|
| 士気が高まる | 「負けている」という感覚が広がる |
| 優秀な人が集まってくる | 人が去っていく |
| 問題があっても後回しにできる （良いことに注力できる） |
責任のなすりつけ合いや非難がはじまる |
スタートアップのフォーカスとリズム 🎯🥁 モメンタムを死守する (1) - Speaker Deckを参考に表を作成
モメンタムはどうやったら維持できるか？
モメンタムは、「小さい勝利」を積み重ねることで維持できます。
小さい勝利は「スプリントゴールの達成」におく事が多く、私のチームでも週単位でスプリントを回しました。
各スプリントでは、「小さい勝利」を祝い勝利の要因を振り返ることを習慣化しました。
Before: BootCamp始める前
現行の開発体制への不安
今回は「不確実=わからないことに取り組んでいる」かつ「短期間(3週間)で成果を求められている」ので、自チームのスタンダードとなっているプロジェクトマネジメントからやり方を変える必要性を感じました。
今までであればプロジェクトマネージャーが要件定義したものを実装すれば良かったのですが、今回は要件が降りてくるわけではなく、自分たちで顧客課題の検証から行う必要がありました。
そこで、短いスパンで価値検証し必要とあればピボット出来るアジャイル的なやり方を意識し始めました。
「スクラム導入したい」vs 「導入してたら開発期間が終わる」
"3週間でリリース"が制約だったので「今のやり方じゃ達成は無理だ」と思うものの、本格的にスクラムを導入しても結果が出る前に開発期間が終わることが懸念されました。
そんな中BootCampが始まりました。1週目は主体性が低く責任をお見合いしている節があり、モメンタムがなくなっていると危機感を募らせました。
After: BootCampでモメンタムに注力した
モメンタムを取り戻し維持するために２つの仕組みを導入しました。
- フォーカス: 「小さく戦い、小さく勝利する」ことに注力しモメンタムを取り戻す
- リズム: 戦いで得た経験を振り返り、学びとして蓄積する
こちらの資料小さく勝利し続けるため４つのポイントが大変参考になりました。
フォーカス: 小さく戦い、小さく勝利する
小さく戦うために、週次での顧客MTGで仮説検証を行うことだけに注力しました。
そして、勝利の定義を「顧客MTGまでにMVPを必ず１つ作成し仮説検証を行うこと」にしました。
勝利を祝う
勝利するだけではモメンタムは維持できません。勝利し、チームで祝うことでモメンタムは生まれます。
（意外と実践できていないチームが多いので強調したい）
リズム: 経験を学びにする
そこで、「スプリントの振り返り(レトロスペクティブ)」を習慣化することから始めました。
スプリントで起きたわからなかったこと、うまくいかなかった経験を言語化して、学びを蓄積することを続けました。
経験のみを知識に変える
そもそもわからないものが不確実性です。ですが、「うまくいくこと」だけを目的としてしまうと、「うまくいかなかった」ときに不安が増大してしまいます。 (中略) 見積もりと実績を比べて正確さを増していくという繰り返しをすれば、見積もりの精度は高くなっていきます。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 3章「アジャイルなチーム原理」より引用
学びの蓄積
各スプリントで学んだことです。学びを言語化することで、チームで共通言語を作ることに成功しました。
それにより、似た不確実性に対して対処できるようになりました。
| スプリント | 問題 | 課題 | 学び |
|---|---|---|---|
| 1 | 長時間MTGしても、開発を一向にスタートできない | ・「顧客の課題を解決する」という壮大なテーマに対して、会議参加者の視界が揃わず、話が行ったり来たりする | ・視界が揃うレベルまで問題を小さくする ・問題小さくして視界が揃ったら、「で、顧客は喜ぶんだっけ？」「課題を解決できるんだっけ？」の問いかけを行う |
| 2 | 開発体験が決まらない | 顧客課題に対する解像度が低く、意思決定ができない | わからないことは、開発ではなく仮設検証として扱う →話してもわからないことは、顧客=ドメインエキスパートに決めてもらう |
| 3-a | UIが決まらない | 想像するUIの共通言語がなく、UIの要件がスリ合わない | 空中戦になってしまった時、議論ではなく、ペアプロする →プロダクトに近いものを作成, 一緒に手を動かす ex. カスタマージャーニー, モック |
| 3-b | スプリント終了まで開発時間がない | リリースするための機能要件が多い | ・開発はミニマムに ・必要ない場合は、サンプルデータで →「リリースしたものが恥ずかしくなかったら、リリースが遅すぎるということだ」 |
「なぜモメンタムか」への答え
短期間で不確実性の高い開発を遂行するために、「モメンタムを保つ」事が重要だと今なら言えます。
なぜなら、開発=戦いの中で成長することが必要だから です。
戦いとは、短期では小さい勝利に向けてスプリントゴールに注力すること、長期ではプロジェクト(開発)の成功を指します。 特に不確実性が高い状況では、実現性が低いと感じるプロジェクトの成功に注力せず、小さく戦い小さく勝利を積み重ねモメンタムを維持することが肝要です。
そして、小さい勝利を祝うことでモメンタムを維持できることを強く実感しました。
成長とは、うまくいかなかった経験を学びに変え、チーム内で共通言語を作ることです。柔軟かつ適応する形で成長し、勝利のリズムを整えます。
やったこと
- モメンタムの維持のため、「小さく勝利する」に注力し続けた
- 小さい勝利の定義: スプリントゴールの達成
- 小さい勝利をチームで祝う時間を作った
- スプリントで得たうまくいかなかった経験を学びとして蓄積した
具体的に変わったこと
| 変わったもの | before | after |
|---|---|---|
| 第一に考えること | プロジェクトの成功 | 小さい勝利 |
| 追うべき対象 | プロジェクト進捗 | スプリントゴール |
| 関心の対象 | タスク進捗 | モメンタム |
| 時間軸 | 月単位 | 週単位 |
| 学びにするもの | 方法論 | 経験 |
おわりに
新機能開発を3週間でリリースできました。
３週間で新機能リリースという達成可能性が見えづらいを目標達成をするために、モメンタム意識して開発プロセスを変えました。
モメンタム駆動で開発
「なぜモメンタムに注力するか？」という問いに開発=戦いの中で成長することが必要だからと答えを出すことができました。
現状では達成できない目標に向けてレベルアップして挑んでいく、そのためのモメンタムなんだなと私なりに解釈しています。
成長して乗り越える感じ、ドラクエ(やそれに類するRPG)に近しいなあと思いました。
盤面ごとにボスを倒すために装備を整えたり、レベル上げをしたりして臨んでいる感じが今回の開発ではありました。そして、キャラの成長や役割に焦点を当てている感じがすごく新鮮で楽しかったです。
モメンタム駆動をドラクエとすると、プロジェクトマネジメントは信長の野望（戦略シミュレーションゲーム）と捉えました。キャラというよりかは、リソースやスケジュールに焦点を当て成功に近づく手法なんだなと比較して捉えました。
コンフォートゾーンを出る
最初は、「３週間でやるのきっついなあ」「できるか怪しいなあ」と悲観的な思いが中心でしたが、目標達成のために現状の常識を疑い変えていくきっかけになり、大変良い経験になりました。
むしろdrasticに変えるきっかけにできました。
モメンタムに注力して段階的に不安を乗り越えて、楽しく困難を乗り越える事ができました。個人としてもチームとしても成長を感じられ、フロー状態を作れました。
参考: チクセントミハイのフロー理論
開発プロセスに対する理解
本記事の中心テーマ「モメンタム」の着想自体はスタートアップ論でしたが、スクラムの有用性を深く理解でき、大きい経験となりました。
並行して不確実性に対抗する手段がプロジェクトマネジメントだけでないことを理解でき、「柔軟に適応可能な形でプロセスを変えていく」という前提を持てるようになりました。
ソフトウェア開発に対する従来のアプローチのおいて、約束と言えば合意したスコープがスケジュールや予算に収まるようにすることだった。スコープと時間と予算の組み合わせが従来の「成功」の定義だったのだ。 （中略）これは、非常にリスクの高い「オール・オア・ナッシング」手法だった。
スクラム実践者が知るべき97のこと "ビジネスに舵を取り戻すスクラム"より引用
特にスクラムがゴール達成だけでなく、人へのサポートを価値基準に置いていることがﾁｮｯﾄ分かりました。
スクラム実践者が知るべき97のこと "実は、スクラムの話ではない"より引用
