NTTドコモR&Dの技術ブログです。

生成AI×vibecodingで業務改善アプリを“最速”開発 ── ヒアリングからMVPリリースまでの実践例

はじめに

こんにちは。データプラットフォーム部(DP部)の石井です。
社内データ活用プラットフォーム「Pochi」のアプリ開発に携わっています。
現場の業務改善の鍵は、利用者のリアルな声を丁寧に拾い上げ、速やかに形にしていくことです。

ただ、リモートワークが当たり前となったいま、複数拠点・オンライン環境で“現場感”を保つのはこれまで以上に難しくなっています。
そんな状況下でも、「業務改善に本当に役立つアプリ」をいかに最短で届けるか?──今回は、チームの多拠点化・リモート時代に合わせたヒアリングからプロトタイピングまでの実践例をご紹介します。

社内データ活用プラットフォームPochi※1とは

私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームPochi※1を開発・推進しています。 このプラットフォームは24年度に30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。

ASCII.jp:NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進 (1/3)

※1: Pochiは社内の開発コードネームです

こんな方におすすめ

  • はじめて業務アプリの開発や改善提案を担うことになった現場担当者・DX推進担当者
  • コーディングに自信はないけれどAI(vibecoding/LLM等)活用でプロトタイプを自分で作ってみたい方
  • リモートや多拠点のメンバーと効率よく合意形成・業務フローの整理を進めたい方

遅延プロジェクトの挑戦

今回私が担当した業務は、3つ同時に開始するはずだったプロジェクトの一つでした。 しかし、担当したプロジェクトは、諸事情により、他のプロジェクトより2か月遅れて開始となりました。 そのため、エンジニアではなかった私ですが、急ピッチで進める必要がある状況となりました。 上司や同僚、AIのサポートを受けて、工夫した点について書いていますので、ご参考になれば幸いです。

現場ヒアリングからリリースまで──業務改善アプリ開発の工程

今回のプロジェクトでは、以下の流れで業務改善アプリを開発しました。

  1. ヒアリング(現場課題・要望の吸い上げ)
  2. 業務フローの可視化(Miro等活用:誰がどのタイミングで何をしているか整理)
  3. 課題の選定(本質的な困りごとの明確化)
  4. 対策検討(複数アイデアを整理・洗い出し)
  5. 要件確定(実際に実装すべき内容を利用者とすり合わせ)
  6. 機能確定(どの機能から手を付けるか合意)
  7. おおまかな開発工数の算出
  8. 優先度付け(どの課題・機能から着手するかを決定)
  9. 最小機能(MVP)の選定(まず必要十分な機能でリリース)
  10. 開発着手
  11. リリース

他のプロジェクトではしっかり時間をとっていましたが、 上記の工程をリモート環境下でも凝縮して進めました。

プロジェクト進行管理の工夫

一連の工程を効率的に回すために、以下のような進行管理の工夫にも取り組みました。

  • 認識のズレを発生させないため、週に1回の定例会は最低限必要で開催し、必要に応じて追加で1時間ずつ別で会議体を設定としました。今回のケースでは、現場側の負荷が高い時期だったため、ミーティング時間は必要最小限に調整しました。

  • 情報インプットのフェーズでは、ヒアリング等で得られた知見を随時開発者へ連携。データ周りの確認や課題整理をパラレルで進めることで、後工程での手戻りを最小限に抑えます。

  • 業務フロー可視化の段階で、リポジトリ(開発管理の作業場)も早いタイミングで準備。これにより、課題発見からアウトプットまでの動線が一気通貫になりました。

  • 対策検討と合わせてプロトタイプ作成も早期に着手。アイデアが固まりはじめた初期段階からvibecoding(生成AIと対話しながらコードを共創するAIペアプログラミング手法)を活用したプロトタイピングを開始し、実際に“触ってもらいながら”現場の温度感や具体的な要望をキャッチアップします。

  • プロトタイプのブラッシュアップには約2週間を要しました。その間に本番開発の工数も見積もりを進め、現場からの要望のどこまでをいつ実装できるかを開発者と常にすり合わせました。

  • あらかじめ立てていた課題・機能の優先順位に合わせて、最小機能(MVP)を確定し、最短リリース日の目標も早めに共有・合意します。

  • リリースに至るまでのあいだは、開発者の不明点・課題を解消することに注力することで、想定外の停滞やコミュニケーションロスがないよう心がけました。

様々な拠点・リモート環境での現場ヒアリング

現場ヒアリングは、複数の拠点にまたがって、主にオンライン会議を活用して行いました。画面共有や実務デモンストレーションで業務の“こだわり”や“困りごと”を具体的に可視化。それらは録画で記録し、開発チームがいつでも参照できる情報資産とすることで、離れた場所にいてもチーム全体の問題認識がずれないように取り組みました。

オンラインホワイトボードで業務フローの可視化と合意形成

業務全体の流れや、関係者間の業務分担、ボトルネックになっている箇所はオンラインホワイトボードツールで可視化。付箋、図、矢印を使いながら、直感的に現状・課題・改善案を共有し、多拠点・多職種でも共通認識を効率よく育てられました。

本記事では実際に作成したボードの一部を紹介しています。 実際の業務フロー分解や論点整理にどのように活用したか、イメージしやすくなると思います。

ヒアリングのポイント

  • ヒアリング会議の中で素早く要点を書き出す
  • 書き出すことで不明点や齟齬がないか、その場で確認する
  • 想定の話題から会話が脱線しても、追って重要になる可能性があるため記録を残す
  • 業務上重要視している部分の熱量は、色や形で強弱をつけて残す
  • 聞き出したい範囲の情報を埋められるか、タイムスケジュールを意識する

実際作成したボード画面の一部(画面は加工しています)

非エンジニア×vibecodingで高速プロトタイピング

エンジニアではない私ですが、vibecoding(生成AIによるコーディング支援/ペアプロンプティング)を活用することで、プロトタイピングの時間と開発者の工数を大幅に圧縮することができました。

たとえば、現場でExcel運用されているデータをそのままサンプルデータとして活用し、より現実に近い形でイメージを伝える工夫を。Streamlit+vibecoding環境で、まずは自分で“プロのWebアプリ開発者”になりきったつもりで、AIにこう頼みます。

▼プロンプト例

## 参照ディレクトリ
/●●●/●●●

## 出力ファイル
●●●.py

## 参考ファイル
●●●.py

## 指示
あなたはプロのwebアプリ開発者です。
以下の仕様を満たすアプリのコードをstreamlitを用いて出力ファイルを更新してください。

### アプリ仕様
- ●●●.csvのサンプルデータを使って、以下の機能を実装してください。

入力
- 予算の上限を入力する欄
- 目標の獲得数を入力する欄

出力
- 入力された予算を費用の上限として想定直近3か月のCPAを元にした想定獲得数、費用のシミュレーションを表示

### 禁止事項
- ●●●の機能は使わないでください

このプロンプトだけで、初期版としては「入力フォーム」「CSV読み込み」「簡易的なシミュレーションロジック」「結果テーブル表示」までが生成されました。

最初はこうしたシンプルなプロンプトで進め、その後はAIと“対話”しながら細かな改善指示を加えていきました。
「複雑な仕様が言語化できない」「要件整理に困った」ときは、ClaudeやChatGPTなどLLM/AI自身にプロンプトの書き方そのものを聞いてしまうのもコツ
たとえば「Claudeに、Claude codeのプロンプトを依頼する」ように、AIをパートナーと割り切って積極的に頼ってみると、より精度の高い指示がしやすくなります。

またある程度まとまったら、「今までどんな指示を出したか・どう伝えればAIに上手く依頼できるか」もまとめて、今後のプロンプト設計や他メンバーとのノウハウ共有にも役立てられます。

プロトタイプ作成の工夫

  • 本番開発に備え、UIコンポーネントとデータ加工ロジックを分離する構造を指示
  • 現場で利用しているエクセルのデータを活用し、文言や数値の粒度が本番と乖離しないよう調整し、本実装をイメージしやすくした。
  • CSVをpandasで読み込み、Streamlitのグラフやデータフレームで可視化。
  • 開発者へスムーズにバトンパスするために、あらかじめ用意していたリポジトリに実装し、開発者が閲覧できるようにしました。

実際作成したアプリの画面の一部(画面は加工しています)

利用者の声・現場での効果

プロトタイピングサイクルとAI活用による早いサイクルでのアプリ開発によって、
- 「KPIや各種指標算出のための作業工数が大幅に削減できた」 - 「エクセル入力・計算ミスが抑制でき、管理が楽になった」 - 「新規着任メンバーへのOJTや指導負担も減った」

といった現場のユーザーから具体的な声も届いています。

エンジニアと依頼者の橋渡しとして

過去の自分であれば、ヒアリングを実施した後、描画ツールでワイヤーフレームなどで絵に起こして、本番開発のエンジニアへバトンパスしていました。
プロトタイプは本番開発のエンジニアに作成いただき、大体のものがせっかく作っていただいた後に、大いに手直しが入ります。
モチベーションダウンにつながる工程でもあると考えているので、そのパートを自分が担えてよかったと考えています。
今後も依頼者のご要望に沿った試行錯誤ができること、また、エンジニアの方は本番プロダクトの開発に集中いただけることが、私としても嬉しいかぎりです。

そして、何より2か月の遅れを最終的にはほぼ差のない状態まで進めることができたことに、ほっとしています。

まとめ

オンライン中心・多拠点体制でも、AIや新しいツールをフル活用してプロトタイピングや改善サイクルを高速化することで、現場が本当に使いやすいアプリケーションを素早く届けられる時代になってきました。

まだまだ進化の余地も大きいですが、業務プロセスと開発そのものを一緒にアップデートしていきたいと思います。