はじめに
はじめまして。
ネイバーズ株式会社 6月入社の河口と申します。
研修中、チーム開発のプロジェクトに携わる機会があり、リーダーを務めました。
結果として、そのプロジェクトは失敗、チームは解散となりました。
本記事では、プロジェクトが失敗に至った原因と、そこから得られた学びについてまとめました。
同じような状況に直面する可能性のある方の一助になれば幸いです。
想定する読者
- 未経験でエンジニア業界に参画した人
- 特に、チームによる開発を考えている人
- PjM（プロジェクトマネージャー）に興味がある人
プロジェクト概要
テーマ
生成AIおよびRAGを用いたチャットボットアプリの開発
開発環境
- フロントエンド：React
- バックエンド：Python
- メンバー：2名（いずれも未経験）
- 期間：2週間
私は主にバックエンド、もう一人のメンバーがフロントエンドを担当しました。
アプリ概要
- アプリ名（仮）：社内ルール確認用チャットアプリ
- 想定ユーザー：研修生
- 想定課題：
「社内ルールやマニュアル等、分かりにくい・確認し辛いルールを一括で確認したい」 - 提供機能：
- QA応答機能
- フロントエンドからの質問に対し、RAGで該当箇所を検索し、OpenAI APIで回答を整形・出力
プロジェクトの失敗と原因分析
① 期間内にデプロイできなかった
技術的な障害
RenderのFreeプラン（512MB制限）でデプロイ予定でしたが、アプリが容量制限に抵触。
そのため、設計からの見直しを余儀なくされました。
タイムマネジメントの甘さ
デプロイに向けて余裕のあるスケジュールを組んだつもりでしたが、予期せぬ問題が相次ぎ、進捗が大幅に遅延しました。
報・連・相の不足
最大の問題は、
「間に合わない可能性が生じた」段階での報告を怠ったことです。
Renderの知見がない中で、「解決策はある」という希望的観測でスケジュールを強行。
結果として、Webサービスとしてのアプリを完成させることができませんでした。
② 実用に耐え得るものではなかった
パフォーマンス
質問から回答まで最大20秒の待機時間が発生。レスポンスが劣悪でした。
バグの多発
- 同じ質問をしても回答が返ってこない
- データの読み込み失敗
- 機能が安定して動作しない
ローカル環境でのテストを通じて調整を行いましたが、原因が複雑に絡み合っており、
どこをどう直せば、どう改善されるかが分からないという状態に陥りました。
③ アプリ自体のニーズがなかった
これが最大の問題でした。
ニーズとアプリのズレ
想定課題は
社内ルールやマニュアルを一括で確認したいでした。
ですが、これは一括で確認できるドキュメントを用意するだけで済む話でした。
RAGを用いたチャットボットは過剰な解決手段だったのです。
また、ニーズを確認するために研修生に実施した「チャットボットでどんな質問をしたいか」というアンケートでも有効な回答が得られず、
「チャットボットで質問したい」という需要がそもそも希薄だったことがわかります。
それにもかかわらず、「せっかく作ったから」と開発を続行。
結果として、誰も使わないのに維持コストだけかかるプロダクトになってしまいました（完成もしていませんが）。
メンバーとの認識のズレ
実は、メンバーもニーズの薄さに気づいていたようです。
しかし、リーダーである私がコミュニケーションを怠ったため、それを汲み取ることができませんでした。
総括
- スケジュールの見通しが甘く、報告も怠った
- コード・パフォーマンス管理が不十分
- そもそもニーズのないものを作ろうとした
PJの失敗は、リーダーである私の判断ミスの積み重ねが原因だったと痛感しています。
対策
アジャイル思考を持つ
アジャイル（agile）とは「素早い」「機敏な」という意味。
開発においては、短いサイクルで計画〜テストを繰り返す手法です。
メリット
- フィードバックを早期に得られ、改善がしやすい
- 進捗やリスクの管理がしやすい
- 問題を小さく分割して対応できる
関連して、MVP（最小実行可能プロダクト）の考え方も重要です。
必要最低限の機能で動くものをまず作り、ユーザーの声をもとに改善していくという考え方です。
“Done is better than perfect.（完璧を目指すよりまず終わらせろ）”
ー マーク・ザッカーバーグ（Meta CEO）
コミュニケーションを図る
ユーザーとのコミュニケーション
- ユーザー目線で考える
- ニーズに合った機能を提供する
- 誰の・どんな課題を・どう解決するのかを常に意識する
メンバーとのコミュニケーション
- 単なる「指示」はコミュニケーションではない
- 少人数でも対話を重ね、違和感をすくい上げる仕組みが必要
- 気まずくても意見を言える関係性を作るのがリーダーの仕事
ステークホルダーとのコミュニケーション
- 報・連・相は基本中の基本
- 些細な変化でも共有することでリスクの早期発見につながる
- 一人で抱え込まず、周囲の知見を頼る勇気を持つ
おわりに
今回のPJは失敗に終わってしまいましたが、同時に多くのことを学ぶことができました。
特に、コミュニケーションの質という点において、
この失敗がなければ、気づくまでにもっと時間がかかったと思います。
今後は、自分のタスクだけでなく、
- プロジェクト全体の進捗
- メンバー・ステークホルダーとの連携
- ユーザー目線に立った開発
これらを意識し、取り組んでいきたいと思います。
これから未経験でチーム開発に携わる方は、どうかこの記事を反面教師として活用いただければ幸いです。
最後になりますが、このプロジェクトに関わってくださったすべての方々に感謝を込めて、この記事の結びとさせていただきます。
ありがとうございました。
Discussion