はじめに
IT業界未経験の同期三人で、社内でチーム制作し、完遂できなかったプロジェクトの失敗談です。
この記事を通して、読者には作業の引き継ぎの大切さや、コメントアウト・命名規則・ディレクトリ構成といった情報共有の工夫、さらには機能単位でのコンポーネント分割による視認性・保守性向上といった、チーム開発における重要な視点を、「課題」「原因」「対策」に分けてお伝えできればと思います。
想定する読者
- これからチーム制作を始める人
- 始めて開発する人
開発プロジェクトの全体像
- 今回のプロジェクトで作成したツールの概要
- チーム構成：未経験メンバー3名(フロントエンド１名/バックエンド２名)
- 使用技術：HTML / CSS / JavaScript / Python（Flask） / GitHub
- 目的物：簡易的なタスク管理ツール（ToDoリスト＋プロンプトによる自動タスク提案機能付き）
- 開発フロー：要件定義 → 設計 → 実装 → テスト → プレゼン
失敗事例1：クライアントとのすり合わせ不足
-
課題
チームが最初に直面した問題は、クライアントとの要件のすり合わせ不足でした。
クライアントの意図と実装された機能の間にズレが生じ、何度も修正が必要となったことで納期が遅延し、チーム全体に焦りが広がる結果となりました。 -
原因
- プロジェクトの初期段階で、クライアントから大まかな要望を受け取ったものの、詳細な仕様や優先順位について深く話し合わなかった。
- チーム内で「こうすればいいだろう」と自己判断で実装を進めてしまった。
- クライアントの意図や目的を十分に確認せず、「わかっているつもり」で進めた。
- やり取りの多くが口頭で行われており記録（ドキュメント）が残っていなかった。
- そのため、認識の食い違いが発生した。
- 対策
-
ユーザーストーリーを明確化
以下の形式で、要件の背景と目的を文書化することで、意図の共有を図ります。
As a クライアント
I want タスク登録時にカテゴリ分類を明確に表示したい
So that 登録ミスを防ぎ、チーム内での作業確認がしやすくなる
- ユーザーストーリーマッピングで機能全体を俯瞰
- クライアントの業務フローを時系列で洗い出し
- 各行動に紐づく機能やUI要件をカード化
- 優先順位やMVP（最小実装）をマッピング、これにより、チーム全体が「どの機能が何のために必要か」を共通認識として持てるようになる。
- 3Cフレームワークの導入
- Card：ヒアリングした要件はすべてNotionやスプレッドシートなどに「要件カード」として記録
- Conversation：カード化した後、チームとクライアントで会話・意図の共有を行う場を設ける
- Confirmation：最後に確認ポイントや完成イメージをクライアントとすり合わせ、ドキュメントに残す
- 定期的な認識の確認
- 設計レビューや開発進捗の節目で、「この実装は目的に合っているか？」という観点でクライアントに確認
- 認識ズレの芽を早期に摘む体制を整備
失敗事例2：チームメンバーの離脱と引継ぎの欠如
- 課題
- バックエンド担当の2人が相次いで離脱し、作業状況やコード内容の共有が不十分なまま、私1人でバックエンド全体を引き継ぐことに。
- 残されたコードにはバグが存在し、特にプロンプト処理のAPI出力が期待通りにならない問題が発生していた。
- コードは1ファイルに密集し、コメントもなく構造が不明瞭なため、修正や理解に多大な時間と労力が必要だった。
- 原因
- 属人化：バックエンドの実装が担当者任せになっており、知識が共有されていなかった。
- 情報共有の欠如：日々の進捗会話はあったが、コードの中身や設計意図までは共有されていなかった。
- ドキュメント不足：引継ぎ用の設計書・コメント・資料などが存在しなかった。
- 密結合な構造：処理が1ファイルに凝縮されており、保守性が極めて低い設計だった。
- 対策
「バスファクター」を高める意識が不可欠
「バスファクター（Bus Factor）」とは、「あるプロジェクトにおいて、何人のメンバーが抜けると開発が止まってしまうか」という指標。スコアが低いほど、属人化のリスクが高い状態を示します。
以下のような対策により、「誰が抜けてもプロジェクトが止まらない仕組み」を日常的に構築することが重要です。
✅情報の見える化と共有
- 担当領域に限らず、全員が機能の流れを理解できる設計・ドキュメントを用意する。
- バックエンドの処理や設計思想は図・簡易設計書・Wikiなどで可視化して残す。
- Pull Request単位でのコードレビューや、他メンバーが理解できるような粒度の解説コメントを追加。
✅バスファクターを上げる習慣
- ローテーションでタスクを持ち回るなど、担当の偏りを避ける。
- 1人だけが理解している状態を減らすため、「最低2人が理解している状態」を保つ運用にする。
- 「これは誰が抜けたら困るか？」を定期的に話し合い、属人性が高い箇所を特定・是正する。
補足参考
失敗事例3：バックエンドコードの構造的な問題
バックエンド担当の2人が抜けた後、私が一人でコードを引き継ぐことになりましたが、そこで直面したのがコードの構造そのものの問題でした。
バックエンドの処理はすべて1つのファイルに集約されており、どの機能がどこに書かれているのかを見つけるだけでも非常に時間がかかりました。さらに、コード内にコメントがほとんどなく、説明や補足も残されていなかったため、意図を読み解くのにも苦労しました。
このような状態では、たとえバグを見つけても、どこをどう修正すれば他の処理に影響しないかを判断するのが難しく、不用意に手を加えることができませんでした。結果的に、修正や新しい機能の追加が後回しになり、開発の大幅な遅延につながりました。
また、このような密結合のコード構造は、今後の保守や拡張性にも大きな課題を残します。実際、部分的に仕様変更があった際にも、影響範囲が読めずに慎重な検証が必要となり、作業効率が著しく低下しました。
この経験から痛感したのは、設計の重要性と、基本的な開発ルールの徹底です。ファイルの分割、命名規則、最低限のコメント、機能単位の構造――こうした一つひとつの積み重ねが、可読性・保守性の高いコードを生み出します。
特にチーム開発においては、自分だけが理解できるコードではなく、誰が見ても迷わず読み取れる設計が不可欠です。今後は、開発の初期段階からガイドラインを定め、誰が担当してもスムーズに引き継げる環境づくりを意識していきたいと思います。
まとめ：初心者こそ「共有と見える化」を
今回のチーム制作は、IT未経験の私たちにとってとても貴重な学びの場になりました。と同時に、「初心者だからこそミスを防ぐ仕組みが必要だ」ということを痛感しました。
-
クライアントとの丁寧なすり合わせ
-
引き継ぎを見越した情報の共有
-
コメント・命名・構造に配慮した設計
これらは決して特別なことではありません。基本的なルールや習慣を最初から意識することが、チーム全体を支える大きな力になるのだと、今回の経験を通じて学ぶことができました。
同じようにこれからチーム開発に挑戦する方の参考になれば幸いです。
Discussion