こんにちは、患者向けサービス開発チームでエンジニアをしている種岡です。
カケハシでは社内で生成AIを活用した取り組みが活発に行われています。
生成AIは、もはや単なる効率化ツールではありません。ユーザーへ最速で価値を届けるための「強力な相棒」です。
本記事では生成AIを活用し、仕様検討からプロトタイプ作成までを高速で実現した事例を、具体的な手順を交えてご紹介します。
新規事業開発における３つの課題
所属しているチームは新規事業開発ということもあり、以下の課題に直面することが多いです。
- 変わりやすい要件 : 日々の情報収集で仕様が固まらず、開発着手のタイミングを見極めるのが難しい
- 技術課題へのリスク : 実際に開発してみないと、どこに技術的な難所があるか分からない
- 不正確な見積もり : 前例がないため、工数の見積もりが大きくブレやすい
高い不確実性への対策としてのプロトタイプ開発
チームでは、プロトタイプ開発を初期の開発プロセスに取り込んでいます。
これによって以下のメリットがあります。
- 手戻りのリスク軽減 : 実際に動くものを作ることで、仕様の妥当性や技術課題を早期に洗い出す
- プロジェクト解像度の向上 :「作っては試し、疑問を解消する」サイクルを回すことで、MVP（Minimum Viable Product）の適切なラインを見極める
プロトタイプ開発は複数回行うこともあり、チームではこれを「1周目」「2周目」と呼んでいます。
※以前取材してもらったチームのインタビューも一緒に読んで頂けると幸いです。
特に新規プロダクトや新しい機能の開発は、エンジニアでも全体像が分からないです。だから「軽く動くものを作ってみましょう」という形で始めるのですが、それを1周目と呼んでいます。1周目をやるとだいたい8割くらい理解できて、「どのくらい工数がかかりそうか？」といった解像度がぐっと上がるんです。
出典: 高速な仮説検証ループによる新規プロダクトの成果を、既存プロダクトにも反映する開発手法 ─ カケハシ「yabusame」チームにインタビュー
DevinとCursorで高速なプロトタイピング
プロトタイプ開発のマインドセット
高速なプロトタイピングを実現するために、自分が思っている2つの心構えを共有します。
- 捨てる勇気を持つ
- プロトタイプはあくまで検証のための試作品
- 機能追加や仕様変更のたびにゼロから作り直すことや、大胆な方針転換（ピボット）を恐れない
- 完成度より学習速度を優先
- 「動く」と「正しい」を混同しない
- 「動いているからこの設計で良いだろう」という思い込みは危険
- あくまで仮の姿であることを常に意識し、目指すべきアーキテクチャを冷静に模索
知識ゼロからのプロトタイピング
所属しているチームでは、他チームが管轄する土地勘のないコードベースへの貢献が求められ、次のような地道なプロセスが一般的でした。
従来の手探りワークフロー
- 膨大なドキュメントを読み込み、なんとかローカル環境を立ち上げる
- 目的の機能に関連する箇所を、手探りでコードの海から探し出す
- 既存コードの"お作法"を推測しながら、コードを修正・検証する
- 不明点が出るたびに、担当エンジニアとのヒアリングを調整し、質問を繰り返す
このプロセスは、全体像を掴むまでに多くの時間を要し、開発の初速を大きく鈍らせる原因でした。
しかし、DevinとCursorの登場が、このワークフローを根底から覆しました。
AIとの協業ワークフロー
- Devinに開発を指示 : 実現したい機能のイメージを伝え、大枠のコードを生成させる
- ローカルで即時検証 : 生成されたコードをローカル環境で動かしてみる
- Cursorとペアプロ : 動かない箇所や改善したい点を、対話形式でCursorに修正・リファクタリングさせる。既存コードの意図や構造についても、Cursorに質問すれば即座に解説してくれる
- 質の高いヒアリング : AIと壁打ちしても解決しない高度な問題のみ、担当エンジニアに相談する
この新しいフローにより、他チームに対する負荷は減りました。また、相談する際にはすでにコードレベルでの深いインサイトを得ているため、質問の質が向上し、より本質的な議論ができるようになりました。
| 従来 | 現在 |
|---|---|
 |
 |
Devinへの「指示の勘所」
Devinと協業する上で以下の観点を意識しています。
指示は「小さなコミット単位」を意識する
- レビュー負荷軽減を意識し、細かい、かつ、具体的な指示を出す
- 指示の粒度が細かいほど、生成されるコードの精度が上がり、意図しない生成物を確認するコストを削減できる
まずは「動作確認」から始める
- 生成されたPull Requestのコードを一行ずつ読む前に、まずは動かす
動作確認 → 意図通りならOK → 既存ロジックへの影響を中心にPRを軽くチェック- このサイクルを回すことで、レビュー時間を大幅に短縮
- プロトタイピング段階では、コードの綺麗さよりもスピードを重視
Devinによる設計ドキュメント作成の自動化
プロトタイプの完成は、開発の終わりではなく、チームでの合意形成の始まりです。
そして、そのプロセスに不可欠な設計ドキュメント作成に、Devinは非常に効果的です。
プロトタイピングで変更されたコードの差分は、実装された仕様そのものです。
この差分をインプットとして与えるだけで、技術仕様の草案を自動生成してくれます。
特筆すべきは、Devinがリポジトリを横断して解析できる点です。
従来であれば、フロントエンド、バックエンド、インフラなど、それぞれ個別に変更点をまとめる必要がありました。
しかしDevinは、これらのリポジトリを横断的に解析し、変更点を一気通貫で整理し出力してくれます。
プロジェクトの「知」の集約方法
プロトタイピングのワークフローを支えるのが、その前段に存在するドキュメントです。
この「情報」をいかに整理し、活用するかが、プロジェクトの成否を分ける鍵だと考えています。
なぜ私たちのチームは「ドキュメント」を重視するのか
弊社のテックブログ記事「チームに『確信』と『スピード』を与える、ディシジョンレコード駆動開発のすすめ」でも触れているように、プロダクト開発とは「意思決定」の連続です。
そして、その決定の背景や議論の経緯が記録されていない場合、プロジェクトはさまざまなリスクを抱えることになります。
- 手戻りの発生 : 意図が不明なまま仕様が改修され、バグや仕様不整合を引き起こす
- コミュニケーションコストの増大 :「これはなぜこうなっていますか？」という確認が頻発し、チーム全体の生産性を低下させる
- 技術的負債の温床 : 変更理由が不明なため、誰も触れられないブラックボックス化したコードが生まれる
とくに、私たちのチームのように他チームのサービスへ横断的に貢献する体制では、関わる人数も多く、こうしたリスクはより顕著になります。
これらの理由から、明確なドキュメントによる情報共有は、単なる推奨事項ではなく、プロジェクトを成功に導くための必須要件であると私たちは考えています。
そのため、プロジェクトの初期段階からドキュメント作成に着手し、常に最新の状態に保つことを心がけていくことが、チーム文化として定着しています。
「設計タイムライン」という名の”とりあえず全部突っ込む場所”
とは言え、日々多種多様なツール（Slack, JIRA, etc.）で行き交う情報を、リアルタイムで完璧に整理・精査するのは現実的ではありません。
その運用コスト自体が、チームの負担になってしまいます。
そこで私たちのチームでは、「設計タイムライン」 と呼ぶ1つのドキュメント集約点作り、運用しています。
この設計タイムラインは、プロジェクトの日報のようなもので、「重要度の高低にかかわらず、プロジェクトに関する情報を時系列でひたすら記録していく」 という非常にシンプルなルールで運用しています。
この「誰でも気軽に追記できる」という低コストな運用が、結果的に情報の網羅性を高めると考えています。
「設計タイムライン」がAIで真価を発揮する
生の情報をそのまま記録し、整理・要約というもっともコストのかかる作業をAIに任せる。
これが、私たちのチームのドキュメント戦略です。
設計タイムラインという時系列ログ形式は、生成AIと相性が良いことがわかってきました。
チャットボット化
設計タイムラインの情報をAIに参照させることで、単なる連続した情報の記録は「対話可能なナレッジベース」へと進化します。
「〇〇機能の背景にあった議論を教えて」と質問するだけで、AIが文脈を読み解き答えを返してくれます。
NotebookLMの活用
プロジェクトのふりかえりには、NotebookLMのタイムライン機能との組み合わせが便利でした。
設計タイムラインを参照させ、より抽象度を高くし簡潔にまとまったタイムラインを出力させます。
この抽象度の高いタイムラインを読むだけでも効果はあるのですが、Geminiでmermaid形式へ変換し可視化したことで、ふりかえりの事前準備がより捗りました。
音声概要機能を使い、簡潔なプロジェクトのまとめを作成させ、社内発表に利用もしました。
個人的には、発表者側の理解度に左右されず、均一な情報提供ができること。
また、スライド作成に集中することができるので、便利だなと感じました。
一方で、社内の発表に生成AIの音声を使うと人間味が薄まるので聞き手の好き嫌いはありそうだとも感じました。
おわりに
本記事では、不確実性の高い新規事業開発において、生成AIを「強力な相棒」として活用する具体的なワークフローを紹介しました。
- AIによる高速プロトタイピング : DevinとCursorを駆使し、土地勘のないコードベースでも迅速に「動くモノ」を作り、仕様の妥当性や技術課題を早期に洗い出す
- 「設計タイムライン」による情報集約 : 完璧な整理を目指さず、日々の情報を時系列で記録することで、形骸化しないナレッジベースを構築する
- AIによる情報活用 : 蓄積した情報をAIでチャットボット化・可視化することで、必要な知見を瞬時に引き出せるようにする
AIは、大量の情報整理を整理し、判断材料を分かりやすく提示してくれます。
しかし、その材料を元に「なぜ今これを作るのか？」「このプロトタイプで何を検証したいのか？」といった本質的な問いに答え、最短で市場に投入する最終的な判断を下すのはチームです。
これら一連の取り組みを経て、意思決定の質を最大化することや価値を素早く市場に提供してフィードバックを得ることが重要だと考えています。
