こんにちは。すべてを科学したい男、神本(@naoto__911)です。
この記事はourly Advent Calendar 2025🎄 18日目の記事です。
前回は、弊社のテックリードのjakeさんがプライベートCA環境を構築してCBAの動作確認する方法について解説いただきました!
私は、直近でチームの開発プロセスを変更した経緯とその成果についてお話します。
開発プロセス変更
今クオーターに我々は、これまで以上に早い開発スピードが必要となりました。
そして、私自身も今以上の速さで開発を進めることはできないのか? と常に考えていました。
試行錯誤の結果、下記の通り開発プロセスを変更するという意思決定をしました。
以前までのプロセス
(実装方針を設計した後に)
- タスク分解をしてプロダクション実装を順次進める
新しいプロセス
(実装方針を設計した後に)
- プロトタイプ実装でハッピーパスを通す
- その後、タスク分解をしてプロダクション実装を順次進める
※ここでいう「ハッピーパス」は、学習に必要な最小限の成立性を確認するための正常系フローを指します。完成度や品質を保証することは目的としていません。
右側は一見プロセスが増えたように見えますが、その効果をこの後ご説明します
この変更に至った理由について書いていきます。
これは「スピードを上げるために雑に作ろう」という話ではありません。
不確実性を最速で潰し、開発者が安心して“良い実装”に集中できる状態を作るための取り組みです。
ourlyにおける「プロトタイプ」と「プロダクション」の定義
まず前提として、ここで言う「プロトタイプ」は、
よくある 「簡易版」「試作品」という曖昧な言葉ではありません。
チーム内で、かなり明確に定義しています。
「プロトタイプ」の定義
[目的]
-
実装者の実現不確実性を最速で潰す
- 少なくともハッピーパスを通す
-
POと要件の齟齬を最速で潰す
- 「動くもの」を前に会話できる状態を作る
[やること]
- 要件を満たした 振る舞い を最速で作る
- とにかく「一通り動く」状態を作る
[やらないこと]
- 振る舞いが動作確認で保証できていれば、ロジック自体のコードレビューは不要
- レビュー負荷を気にした タスク分割もしないでよい
- 振る舞いは満たしたが、構造的に良いコードである必要はない
- 既存テストが落ちるところを無理に通す必要はない
- 新規で追加のテスト実装を行わない
※プロトタイプは隔離したブランチで進め、メインブランチの品質は守ります。
「プロダクション」の定義
[目的]
- リリースできる状態にする
[やること]
- アプリケーションを完成させる
- 構造的な負債を解消する
- テストを実装する
- レビューしやすい単位に整理する
[やらないこと]
- 基本的に「やらないこと」はありませんが、例外はあります。
- リリース日に間に合わない場合
- ユーザー影響がない構造的変更は後回しにする
- 振る舞いは満たしたが、構造変更にやや時間がかかる場合
- リリース後対応にして、リリースを遅らせないようにする
ポイント
- 「プロトタイプ」の段階では、「コードの美しさ」や「テストの網羅性」は一切ゴールではありません。
- 「プロトタイプ」の目的にフォーカスして進めて、目的が達成された後に、「プロダクション」でこれらを拡充します。
- 「プロトタイプ」は、学習のための検証資産であり、メインブランチへマージはしません。
- 「プロダクション」の段階では、振る舞いに関する学習が手元にすでにあるため、従来のタスク分解された1タスクの完遂に比べて圧倒的速さで作業が完了します。
このプロセスで目指していること
- つまり、プロトタイプで「成立性」と「認識合わせ」を先に終わらせ、プロダクションでは品質に集中できる状態を作ります。
本来のプロトタイプには4つの目的がある
この考え方は、『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』 で語られている、本来のプロトタイプの役割に強く影響を受けています。
同書では、プロトタイプの目的として、次の4つの問いが挙げられています。
①.ユーザーはそれを買ってくれるか?
②.ユーザーはその使い方をわかるか?
③.私たちのエンジニアはそれを作れるか?
④.ステークホルダーたちの支持が得られるか?
プロトタイプは「とりあえず動くものを作る」ためのものではなく、
これらの不確実性を早い段階で検証するための手段だ、という考え方です。
すべてを同時には追わない
ただし、現状 ourly では この4つすべてをプロトタイプで同時に満たそうとはしていません。
今フォーカスしているのは、以下の2つです。
- ③私たちのエンジニアはそれを作れるか?
- ④ステークホルダーたちの支持が得られるか?
なぜ今は①を含めていないのか?
ourly は今、「まず使えるものを、早くユーザーに届ける」 フェーズにいます。
また、ToB SaaS という性質上、
- 失注理由のデータベース
- ユーザーヒアリング
- CS の定例MTGで得られた声
を通じて、「この課題は本当に存在するのか？」というインサイトの確からしさは、すでにある程度高い状態にあります。
そのため現時点では、
「買ってくれるか？」をプロトタイプで検証する優先度は、相対的に高くない
と判断しています。
なぜ今は②を含めていないのか?
これも軽視しているわけではありません。
ただ、チームとしては、
価値をユーザーに届けた“後”に、初めて本気で向き合える改善
だと捉えています。
- そもそも価値が届いていない段階で
- 使いやすさだけを磨き込んでも
学びの密度は高くなりません。
まずは、
- 価値があるか
- 業務で使われるか
を、現実のプロダクトとして成立させることを優先しています。
今は③と④にフォーカスする
以上より、現状のプロトタイプの役割は、以下の2つにフォーカスしました。
③.私たちのエンジニアはそれを作れるか?
- 「ちゃんと作れる」という確信を持つ
- ハッピーパスを通した状態で、本実装に入る
- 以上より実装者の実現不確実性を最速で潰す
④.ステークホルダーたちの支持が得られるか?
- 動くものを前提に議論できる
- 抽象的な要件定義で消耗しない
- 以上よりPOと要件の齟齬を最速で潰す
モナリザの絵の話
ここで少し別のお話をします。
この話は、『ユーザーストーリーマッピング』 の中で紹介されていた内容です。
少し意訳しながら書きます。
デッサンからはじめる
レオナルド・ダ・ヴィンチは、
モナリザを描くときに、最初から細部を描き込んだわけではないのでは?という考え方です
まずやったのは、
- 全体を とても細い線でデッサンする
- 構図・バランス・全体像を確認する
という工程でした。
この段階の絵は、
一見すると「未完成」どころか、
「ちゃんと描いていない」とすら言える状態です。
しかし、この 最初のデッサン によって、
- 思っていた完成イメージとの違和感
- 構図そのもののズレ
に、かなり早い段階で気づくことができます。
そして、
「あ、これは完成させる方向を変えた方がいいな」
という判断を、まだ修正コストが極めて低い段階で行える。
この 学習ができること が重要だ、という話です。
もし最初から「完成系」を分割して描いていたら？
対比として、こういう描き方を考えてみます。
- まず目を完璧に描く
- 次に鼻を完璧に描く
- 次に口を完璧に描く
一つ一つは、とても丁寧で完成度が高い。
しかしもし、
- 全体の構図
- 顔のバランス
- 視線の向き
に設計ミスがあった場合、途中でそれに気づいた瞬間、そこまでの作業はほぼ無駄になります。
画像にしてみると、右の描き方は無理ゲーなことがよくわかりました
開発プロセスに当てはめると
この話は、そのまま開発プロセスにも当てはまります。
デッサンを先に描く描き方
- まず全体をざっくり描く
- 完成系の違和感を早期に発見する
- 方向性を修正してから、細部を作り込む
これは、開発で言うと
「プロトタイプ → プロダクション」
のプロセスです。
最初から完成系を分割して描く描き方
- 最初からタスク分解する
- 各タスクを「完成」させながら進める
- 途中で前提が崩れると、大きな手戻りが発生する
これは、開発で言うと
「タスク分解をしてプロダクション実装」
のプロセスです。
モナリザのデッサンのアナロジーが示すのは、細部を完璧に仕上げる前に、まず全体像を描いて違和感を早く見つけ、修正コストが小さいうちに方向転換できることの価値でした。
プロトタイプはまさにその「最初のデッサン」で、早期学習のための装置です。
だからこそ、プロトタイプ段階ではコードの美しさやテストの網羅性をゴールにしないという割り切りが成立します。
なぜ「今」プロトタイプなのか
ここまで話してきたプロトタイプ実装を、なぜ今このタイミングで導入したのか。
理由は、LLM が「少し大きめな処理でも、短時間でハッピーパスまで作れる」レベルに進化したからです。
以前は、人の認知能力の限界から、ある程度以上の規模の実装では局所的な正しさを積み上げないと、全体の整合性が崩れるリスクがありました。そのため、タスク分解と単体テストを前提とした実装が一般的で、我々もそうしてきました。
しかし現在は、LLM を活用することで、まず「成立するかどうか」という実現不確実性を一気に削減できるようになっています。細かな考慮不足や構造調整は人の手で行う必要がありますが、その段階では局所最適に集中できます。
この変化によって、今のタイミングで「プロトタイプ」という選択肢を取れるようになりました。
プロセス変更によって生まれた成果
ここまでお話したプロセスへと変更して1クオーターが経過しました。
どのような成果が得られたか? を振り返ってみます。
具体的な成果 (定量)
まず定量的な変化としては、Findy Team+の「プロジェクトプロセスタイム分析」を確認したところ
以前よりも、「実装」の時間が減り、「要件定義」や「設計」の時間が増えていました。
加えて1プロジェクトに要した時間自体は早くなっています。
(プロトタイプ実装は要件定義/設計、プロダクション実装は実装として集計してます)
これは、「プロトタイプ → プロダクション」という開発プロセスに変更したことにより、前段で不確実性を潰す動きができた結果、以前よりも上流のプロセスに人がフォーカスできていると言えるのではないかと考えています。
プロジェクトA,Bが以前のプロセス、C,D,Eが新しいプロセスで開発したプロジェクト
具体的な成果 (定性)
開発プロセスを変更してからの定性的な変化をお伝えします。
プロトタイプ時点ですぐにPOと認識齟齬を埋めることができたことも大きな成果でした。
静止画のFigmaデザインでは分からないユーザーストーリーの狭間に考慮していなかったポイントが見つかりこれを早い段階で発見し対策を打てました。
これは、プロトタイプで実際に動くものを最速で作り上げたからこそ得られた効果です。
また、開発メンバーヒアリングした結果、以下のような意見が得られました。
- すでにハッピーパスが通っており「これそもそも成立するのかな？」という不安がない
- 安心して構造・設計・テストに集中できる
つまり開発者体験がめちゃくちゃ良くなったということです。
このプロセス変更にして、一番良かったと感じた点はこれです。
これらの効果からも、プロジェクトの進捗自体も今まで以上により早くプロダクトが実現されている感覚が個人的にも強く感じております。
まとめ
本記事では、新たに導入した「プロトタイプ → プロダクション」の開発プロセスについてご紹介しました。少しでもご参考になれば幸いです。
これからも、既存のプロセスにとらわれることなく目的を達成するために最適な手段を使い分けて、より大きな価値を作り上げられるチームを牽引していきたいと思います。
参考資料
Discussion