AI開発標準策定の失敗から学ぶ、不確実性があるタスクを推進する技術

この記事はTimee Product Advent Calendar 2025の22日目の記事です。

はじめに

こんにちは！kazzhiraと申します。タイミーでプロダクトエンジニアとして働いています。この記事では、AIエージェント開発をチームに定着させようと奮闘したストーリーと、そこで得た学びを語ろうと思います。よってこの記事はAIの技術解説ではありません。『AI推進』という答えのない課題に直面して空回りしたエンジニアが、どのようにして仕事を前に進めるコツを掴んだのかを記録したものです。

何かを推進する立場の方にとって学びや励みになればと思い、執筆しています。

背景

チームメンバーは全員がプロダクトエンジニアで、AI時代よりも前から開発経験があります。主にフロントエンド、バックエンド、Androidのケイパビリティがあります。

Cursor、Claude Code、Devin、GitHub Copilot、Geminiを個々人の判断で利用可能です。

プロダクト組織ではAI活用が進んでおり、私も「AI活用を進めて生産性を上げたい」という強いモチベーションがありました。

上司からもチャンスをいただけたので、即「やっていきます！」と推進をしていくことに。

推進で試行錯誤した3ヶ月間の話

これまで私は開発業務の遂行、個人で生産性を上げる取り組み、短期的な組織運営を経験してきました。今回引き受けたAI推進は、チーム全体をスコープとする中長期の組織的な取り組みです。このスコープでの取り組みで成功体験が少なく、私にとって新たな挑戦でした。

当初の状況を整理すると、組織としてはTipsは転がっているものの、AI活用の状況は個々人に閉じていました。 AIの技術進化は近年目まぐるしく、AIを中核にワークフローを組んだりサービスを作ってもすぐに陳腐化してしまうなど、不確実性が高い領域です。

この状況を認識しつつも悶々としたまま、2週間が過ぎました。そう、身動きが取れていない状態だったのです。このときの行動のループをまとめると、

推進って具体的にどうするの？自分の中で良さそうと思っていることを単に広めるってこと？
ブレストして、共通項をまとめる…
結局それで何になるの？AI活用が今より進んでいるってどういう状態？

今振り返ると、焦りから完全に空回りしていました。

AI開発標準の作成エピソード

頭を悩ませているうちに時間が経過し、自分自身のモチベーションも下がっていることに気づきました。このことを上司に相談したところ、的確なフィードバックをもらいました。

「情報収集と分析が足りていない」（意訳）

ハッとしました。チームには情報がありません。当然、情報収集が必要です。私はテックブログや時事ネタを眺め、それを手元で試したり、試さずに終わってしまったりしている状態でした。「なぜやるのか」「どうやるのか」をチームに腹落ちさせるだけの材料も、自分自身の確固たる言葉も持っていなかったのです。

その日から私は情報をかき集め、Geminiと相談しながら内容を深掘りし、知見を深めました。 80%くらいのAI開発標準v0.1を即座に作成し、メンバーからフィードバックを受けてブラッシュアップしました。

次に示すのはドキュメントで定義した開発フロー図の一部です。前後のPhaseは本質と関係ないため図から除外しています。

核心としては、CursorやClaude Codeなどで実装されているPlanモードで実装計画とレビューを挟むことで、AIの出力を高品質にし、手戻りを減らす開発スタイルを言語化したものです。コンテキスト用意の部分を解説します。

ガードレール設計
- リポジトリ毎に規約が決まっていることが多いので、その参照を持たせます
プロンプティング
- 役割や制限事項を含めた命令文を書きますが、コンテキストはガードレール、Design Doc、MCPサーバで補完できることが多いため、プロンプトの分量はそれほど多くなりません
Design Doc作成
- DB設計書、API設計書など必要に応じて設計書を作成します
MCPサーバ接続
- Figma MCPやGitHub MCPを利用して外部のコンテキストを取得します

AIエージェント、推論モデルは目まぐるしく変化するため、そこに依存せず中長期的に運用できる内容を目指して作成しました。

AI開発標準v1.0は、フィードバックと改善が活発に行われ、知見が共有されたり目線が揃ったことで、個々人の生産性には多少の変化がありました。しかしチームで提供する価値の面では大きな成果は上がりませんでした。なぜならば、資料の説明は抽象的で、かつ現在地を示したに過ぎず、チームも具体的に動きようがなかったからです。チームの課題や生産性のボトルネック、理想とする開発体験など、「なぜやるのか（Why）」「何をやるのか（What）」「どう実行するのか（How）」が、全くもって抜けていました。この成果物は開発手法の共通項を抜き出したガードレールになっただけでした。ガードレールがあるのは良いのですが、チームの状態としては相互理解や知見が少々増えて開発が楽になったに過ぎず、会社が「期待以上だった」と評価を下せるほどの成果ではありません。

スクラムに着想を得た推進の勘所

ここでふと、今まで長期に渡り実践してきたスクラム開発を思い出しました。スクラム開発ではプロダクトゴールとスプリントゴールを設定して不確実性が高い環境でも継続して価値提供を実行します。

先ほど反省した通り、中長期の組織的な取り組みにもゴールとマイルストーンを設定し、計画的に進めることが大事なのだと気づくことができました。

日々やっているはずなのに、なぜできなかったんだろう、忘れてしまったんだろう…と落ち込みましたが、今では伸びしろだと考え直しています。気づくといろいろなものが見えてきて、何をすべきかがわかります。最近、上司から的確なフィードバックをもらいました。

「今のままでも前に進むとは思いますが、ゴールと計画を具体化した方がいいですね」

まさに！です。まず、理想の開発体験をチームで話し合ってみることに決めました。議論を進めるうちにチームでは次の結論が出ました。

作業さえ切り出してしまえば、実装はボトルネックになっていない
リファインメントで議論が発散する時間が長く、収束に時間がかかる場合がある
AIにはビジネス戦略、顧客課題、ユーザーストーリーが渡っていない。ドメインの知識を詰め込んだGeminiのGem、もしくはNotion AIを用意することで、期待に近い出力を得ることができそうだ
AIの出力が微妙な時は、整理されたコンテキストが足りていないことが多い。仕様の記述もAIを中心に進め、レビューを開発者が行えば、質とスピードが担保できそうだ。これらを満たすSDD（仕様書駆動開発）に、投機的に取り組んでみる

これにより、以前よりも一歩前に進むことができ、次の具体的な計画を立てることができます。明確な成果に紐づけるところまでは達成していませんが、以前よりも議論が活発になり、開発体験をより良くしていく動きができるようになりました。