ドコモPMの実践録：Streamlitアプリ『導入期』から『成熟期』へ導くチームマネジメント

1. 概要

NTTドコモデータプラットフォーム部（DP部）の外山です。

社内データ活用プラットフォームPochi*1では、2023年4月に一つ目のアプリ開発から始まり、最初のユーザー獲得に奔走した「導入期」、多くの要望に応え開発をスケールさせた「成長期」を経て、2025年12月現在、私たちのプロダクトは成長期から成熟期の転換期にあり、アーリーマジョリティ層への拡大、いわゆる「キャズム超え」の真っ只中にいます。キャズムを超えるために、MAU（月間アクティブユーザー数）の継続的な増加と、利用部署数の拡大を主要指標とし、導入事例の社内展開や簡易アプリ開発ワークショップの実施といった施策を検討・実行しています。

本記事では、この目まぐるしい変化の中で、私がプロジェクトマネージャー（PM）としてどのようにチームを支えてきたのか、プロダクトの「導入期」「成長期」、そして「成熟期」へと向かう今、それぞれのフェーズで直面した課題と、それを乗り越えるために実践してきたチームマネジメントのリアルをご紹介します。なお、本記事に掲載の取組については、株式会社NTTデータの支援メンバーである長谷川さんに進めてもらっており、以下は、長谷川さんに執筆いただいています。

サマリ

プロダクトの成長を「導入期」「成長期」「成熟期」の3つのフェーズに分け、各段階でPMがどのように課題と向き合ったかを3章～5章で解説します。

フェーズ	課題	PMの役割
導入期	技術だけでは越えられない最初のユーザー獲得という壁	最初の味方を見つけ、共創関係を築く
成長期	急増する開発リクエストが招く、スピード低下と品質のばらつき	再現性のある開発の型を導入し、チームを自律的な開発組織へと導く
成熟期	規模拡大による開発効率の低下と、プロダクト成長の鈍化	仕組みの進化と価値検証の高速化で、持続的な価値創造を牽引する

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

私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
ASCII.jp：NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進 (1/3)

2. はじめに

各フェーズでの実践録をお話しする前に、本記事の舞台となる私たちのチームとPMという役割の前提を共有します。

チーム体制

私たちのチームでは全130アプリのうち約40個のアプリを開発・運用しています。各メンバーがアジャイルかつ自律的に考え行動し、ビジネス部門と密に連携しながら、日々スピーディーな価値提供を実施しています。

PMの役割

本プロジェクトにおけるPMはプロジェクトマネジメントだけでなく、「エンジニアリングの成果を最大化するために、技術・人・組織・プロセスなどをマネジメントするリーダー」のようなエンジニアリングマネージャーの役割も担います。具体的には、ビジネス部門との対話を通した要件定義や仕様策定をリード、プロジェクト全体のスケジュールや課題の管理、上位層や関連部署などのステークホルダーとのコミュニケーションなど、多岐にわたる業務を遂行しています。

このような状況でアプリ開発を進めるにあたり、私はPMとしての活動の基軸に「DevやTLが常に開発に専念できる環境を整備する」という方針を置きました。事業貢献において、かつてないスピードが求められる中、目の前の開発に集中できるようにすることが、チーム全体での成果を最大化する効果的な方法と信じています。ただし、この開発への集中を阻む課題は、プロダクトの成長フェーズに応じて絶えず変化します。以降の章では、プロダクトの成長フェーズに応じて変化する課題に対して、PMという役割の中でアプローチをどう変化させ、チームを導いてきたのか、その具体的な実践録をお話しします。

3. 【導入期】最初の価値を生み出す〜味方作りと関係構築〜

導入期におけるPMの役割

導入期におけるPMの最も重要な役割は、プロダクトの価値を共に証明してくれる最初の味方、いわゆるファーストペンギンを見つけ出すことでした。

プロダクトの価値がまだ誰にも信じられていないこの段階では、完璧な機能を追求するよりも、まず一人でも使ってくれるユーザーを獲得し、そこから得られるフィードバックこそがチームを前進させる唯一の燃料となります。そのためPMには、技術的な課題解決以上に、組織の壁を越えて外部と関係を構築していく突破力が求められました。

どう乗り越えたか？

私たちが初めて開発したアプリケーション群は、ビジネス部門の日常業務効率化を目的としたものでした。具体的には、顧客ID変換アプリ、サービスの契約者抽出アプリ、業務マスタ登録アプリなどです。

PMとして、日常業務効率化を果たすため、兎にも角にもアプリを使ってもらうために奔走していましたが、属人的な作業をWebアプリを通じた業務プロセスにシフトすることが浸透していない状況において、最初のユーザーを捕まえることも困難が伴いました。

最初は、チーム内に閉じて必要な機能の検討・改善を行っていましたが、「せっかく作っても誰も使ってくれないのではないか？」という懸念が払拭できず、ビジネス部門とやり取りの多い他のチームにヒアリングしたところ、「単に便利な機能を追加するだけでは、既存の業務フローは変わらない」という、技術だけでは解決できない組織的な課題の存在に気づかされました。

そして、このヒアリングがきっかけとなり、アプリ化したい業務を日頃実施しているビジネス部門を紹介してもらえることになりました。これが、直接ユーザーからフィードバックをもらえる関係性に向けた、大きな一歩となりました。

最初のユーザーとなってもらったビジネス部門へは、単に機能説明を行うのではなく、このアプリによって、彼らの業務にどんな価値が生まれるのかを体感してもらうことを重視し、開発中アプリを実際に触ってもらいながら対話を重ねることで、使いたいアプリに昇華させていきました。この「価値の体感」を起点としたユーザーとの共創プロセスは、以降の成長期・成熟期においても私たちがプロダクト開発で最も大切にしている思想となっています。初期段階からユーザーと密に連携することで、データの正確性や業務要件への適合性といった、データプロダクトに不可欠な品質要素も早期に検証・改善できる基盤を築きました。

4. 【成長期】価値をスケールさせる〜再現性ある「開発の型」作り〜

成長期におけるPMの役割

導入期を乗り越え、プロダクトの価値が認められ始めると、チームは次なるフェーズ「成長期」へと突入しました。この時期のPMの役割は、チームが自律的に価値を生み出し続けるための仕組み作りを推進することでした。

ビジネス部門からの多様なニーズが殺到する中で、場当たり的な開発を続ければ、チームはすぐに疲弊し、開発スピードも品質も低下してしまいます。そこでPMには、誰がやっても一定のスピードと品質で開発を進められる再現性のある型を設計し、チームがスケールするための土台を築くことが求められました。

どう乗り越えたか？

最初のアプリの認知・利用が増えてくると、他のビジネス部門からも開発リクエストが殺到し始めました。嬉しい悲鳴である一方、チームの前にはスケールに伴う2つの課題が立ちはだかりました。

第一の課題：開発スピードの低下

第一の課題は、要件定義の迷走が招いた「開発スピードの低下」です。ビジネス部門は本務で忙しく、伝えられる要望の解像度にはバラつきがありました。そのため、MVPとして何から作るかの判断は開発チームが主導する必要がありましたが、そこには落とし穴がありました。私たちはビジネス部門の期待に応えたい一心で、追加で発生した要望やMVPとして必須ではない機能まで開発してしまい、スコープの肥大化を招いてしまったのです。結果としてチームは疲弊し、開発スピードの低下を招いてしまいました。

第二の課題：品質のばらつき

第二の課題は、開発の属人化が招いた「品質のばらつき」です。私たちのチームでは、アプリを素早く量産することを目的に、1つのアプリをTL1名、Dev1名で開発していましたが、導入期を超えた時点では開発プロセスが標準化されておらず、進め方はメンバーのスキルや経験に依存していました。その結果、機能設計やテスト設計の整理内容にばらつきがあり、TLのレビュー負荷は増大していました。仕様の抜け漏れによる手戻りやテスト時のバグも頻発し、品質を安定させることが困難な状況でした。

このようにスピードと品質の双方に課題を抱えたまま、1ヶ月という短期リリース目標に追われ、「とにかく作らなければ」という焦りだけが空回りし、チームは混乱状態に陥っていました。この状況を打開するため、PMとして私は、これら2つの課題を同時に解決する「開発の型」を確立することに注力しました。具体的には、TLやDevと壁打ちを重ね、以下の4つのテンプレートを起点とするプロセスを設計しました。

業務フロー整理シート： Why／Whatを明確化するために、As-Is／To-Beの業務フローを可視化する
画面イメージ設計シート： Whatを具体化するために、主要画面のレイアウトや遷移を設計
機能設計シート： What／Howを具体化するために、必要な機能や入出力・処理を定義する
テスト設計シート： Howの妥当性を担保するために、テスト観点やテスト項目を定義する

この「開発の型」は、チームに大きな変化をもたらしました。
まず、業務フロー整理シート、画面イメージ設計シートは、開発者とビジネス部門の間に共通言語を生み出しました。これにより要件定義のコミュニケーションが円滑化され、「本当に作るべき機能は何か」という共通認識を早期に形成でき、迷いなくMVP開発を遂行できるようになりました。特にデータプロダクトにおいては、データ定義の曖昧さやデータの活用目的のずれが大きな手戻りにつながるため、この共通言語がデータ品質とユーザー価値の向上に大きく貢献しました。

さらに、機能設計シート、テスト設計シートは開発の道標となり、メンバーのスキルに依存しない安定した品質を生み出しました。これにより、TLのレビュー負荷は軽減され、手戻りやバグの減少につながりました。データプロダクトに求められる高い信頼性と再現性を確保するための基盤となりました。

当初、新しいプロセスに戸惑うメンバーもいましたが、「進め方に指針が欲しい」という声はチーム全体から上がっており、各プロセスの必要性を説明することで、チーム全体の共通認識となっていきました。結果として、チームは開発のスピードと品質を取り戻すための一歩を踏み出し、エンジニアが自律的に開発を進めるための土台を築くことができました。

一方で、この「型」はあくまで開発プロセスの骨格を整えるものであり、画面イメージ設計シートは、ビジネス部門との共通認識の形成やスコープの肥大化を防止する効果はありましたが、作成自体に負荷が発生してしまう側面もありました。また、テスト設計シートは大枠の指針にはなったものの、テスト項目を網羅的に洗い出す作業は依然としてメンバーのスキルに依存し、属人性の完全な解消には至っていませんでした。「コミュニケーション円滑化のために増えた負荷」と「詳細レベルに残り続ける属人性」。これらが、成熟期における「価値検証の高速化」という次なる挑戦のテーマとなっていきます。

5.【成熟期】持続的な価値創造への挑戦〜仕組みの進化と価値検証の高速化〜

成熟期におけるPMの役割

導入期・成長期を経て、私たちのチームが開発・運用するアプリは40にまで増加しました。この時期のPMに求められる役割は、チームが自律的に価値を生み出し続ける仕組みを、より持続可能なものへと進化させることでした。

アプリやチーム規模の拡大は、同時にプロジェクトの複雑化を招きます。これまでのやり方が通用しなくなり、生産性や成長の勢いにブレーキがかかり始めます。そこでPMには、チームの現状を正確に観察し、ボトルネックとなっている部分を解消し、チームが再び前進するための新たな仕組みを設計・導入することが求められました。

それはまさに、2章で掲げた「開発者が開発に専念できる環境を整備する」という原点に立ち返り、成熟期という新たなフェーズに合わせて、その環境をより高いレベルへと進化させるミッションでした。

どう乗り越えたか？

成熟期を迎えた私たちの前には、これまでにない性質の2つの課題が立ちはだかりました。

第一の課題：開発効率の低下

第一の課題は、規模の拡大が招いた「開発効率の低下」です。この課題の背景には、主に二つの要因がありました。

一つ目の要因は、運用業務の急増による開発リソースの圧迫です。開発・運用するアプリが増加したことで、ユーザーからの問い合わせや障害対応といった差し込み業務が急増し、開発者の時間を著しく奪っていました。日頃、各チームのスプリントバックログやベロシティの確認をしたり、スプリントイベントでコミュニケーションを取る中で開発者の負荷を肌で感じていた私は、開発者の盾となることに徹しました。開発チームの負荷状況に応じて、私自身も問い合わせや障害の一次対応を担い、他チームへの調整を行うことで、開発者が目の前の開発作業に集中できる時間を確保したのです。

二つ目の要因は、ナレッジのサイロ化による非効率な情報探索です。チームやアプリの規模が拡大するにつれて知見が属人化し、同じような調査や問題解決に別々のチームが時間を費やす場面が目立つようになっていました。この要因に対して、属人化していたナレッジを組織の資産に変えるアプローチを実施しました。具体的には、社内コミュニケーションツール上にチーム横断のナレッジベースを構築。開発知見、過去の障害事例、データ活用方法といった各チームの暗黙知を誰もがアクセスできる形で集約・体系化していきました。例えば、特定のデータソースに関するFAQや、Streamlitアプリ開発におけるナレッジをテンプレート化し、タグ付けや関連情報へのリンクを充実させることで、メンバーは必要な情報を迅速に参照できるようになりました。また、ナレッジ化に至っていない知見についても、関連する情報源やキーマンを日頃から把握しておき、メンバーからの相談に対して適切な人や情報へつなぐハブの役割を担うことで、ナレッジベースを補完するようにしていました。

私が直接コードを書かないPMだからこそ、個々の開発タスクから一歩引いた視点を持ち、開発者が本来の業務に集中できるよう、組織全体のタスクや知識の流れを整える環境整備に徹することができたのです。

第二の課題：成長の鈍化

第二の課題は、成功の先にある「成長の鈍化」でした。プロダクトは安定的に利用されるようになったものの、利用者数の伸びは停滞傾向を迎えていました。「次に何を作ればヒットするのか」という確信が持てず、チーム全体が次の一手を打ち出せずに足踏みしている状態でした。

この課題に対して、不確実性を前提とした価値検証の高速化というアプローチを取りました。「わからないなら、これまで以上の速さで仮説を検証し、市場から学ぶしかない」という発想に転換したのです。
しかし、その高速化の足かせとなっていたのが、成長期から持ち越した課題でした。アイデアを素早く形にしようにも、画面イメージ作成の負荷がボトルネックとなり、品質を担保しようにもテスト項目洗い出しの属人性が壁となって立ちはだかっていたのです。

この価値検証の高速化と、そこに付随する足かせを同時に解決する手段として、私たちは生成AIの力を借りることを決めました。具体的には、画面イメージ作成の負荷を削減しつつ開発初速を上げるためのコード生成による開発支援と、テスト項目洗い出しの属人性を解消し品質チェックを効率化するためのテスト自動生成というアプローチでした。生成AIの導入により、初期段階のプロトタイプ開発期間が約70%削減され、簡易なテスト設計・テスト実施においても効率化の効果が見え始めています。

一方で、生成されたコードの品質担保や、ビジネスロジックの複雑な部分への適用においてはまだ人間のレビューが不可欠であり、現在も検証を進めています。この取り組みを通じて、Devメンバーがより本質的な課題解決や高度な開発に集中できる環境を整備することを目指しています。

生成AIを活用した検証の詳細は別記事で紹介予定のため、ぜひそちらをご覧ください。

ユーザーストーリーで紐解くプロンプト改善術～AIで開発初速を上げる画面イメージの作り方～
「テストしたつもり」の悲劇を断ち切る。PMが仕掛ける、標準化されたテストケース生成の仕組み

これらの打ち手の結果、Devメンバーは運用業務の負荷から少しずつ解放され、再び本質的な開発に集中できる環境が整いつつあります。
ただし、この取り組みは開発チームの力だけで実現できたわけではありません。DP部には、生成AIの導入を推進する専門チームが組成されており、このチームと連携したからこそ、短期間での実現が可能となりました。このように開発チームだけで打開が難しい課題に対しては、専門組織との連携や社内の有識者を巻き込むことが、ブレークスルーの鍵となるでしょう。

そして今、私たちは生成AIという新しい武器を手に、「価値検証の高速化」という次なる挑戦のスタートラインに立っています。成熟期に立ちはだかる課題を乗り越え、持続的に価値を創造し続ける組織へと進化するために、私たちの試みはこれからも続きます。