グループ開発による問題解決
◆チームで挑んだ受注納品管理システム開発 ー PMとしての挑戦と学び 大学の実務型授業で、6〜7人ほどのチームで一つのプロジェクトを進める機会がありました。私たちのミッションは、「受注納品管理システム」を開発すること。この授業は、ただ単にシステムを作るだけではなく、顧客からの提案依頼書（RFP）を読み解き、ヒアリングを重ね、要件を定め、設計・実装・テストを経て納品するという、非常に実践的な内容でした。まさに「現場に近い」プロジェクト形式で、各チームに1人のPM（品質保証・支援役となる教員）、スーパーバイザ(SV)１～２人が構成要員で入っていて、 継続的にレビューや指導を受けながら進めていきました。 私たちは4チームに分かれて活動し、私はその中の1つのチームで**プロジェクトマネージャー（PM）**を務めました。 ◆プロジェクトの背景と目標 顧客からの提案依頼の内容は、受注から納品までの一連の業務を効率化する「受注納品管理システム」の開発でした。業務改善のポイントとして特に求められていたのは、 ・顧客ごとの累計売上額の可視化 ・顧客ごとの平均リードタイム（注文から納品までの時間）の算出 といった統計情報を簡単に取得できる機能でした。 ヒアリングを通して、現行業務では注文書と納品書の対応がうまく取れていなかったことや、注文キャンセルなどの例外処理が曖昧であることが明らかになりました。このような問題を解決するために、業務の流れを可視化しながら、システム化の方向性を探っていきました。 ◆V字モデルを採用した開発の流れ プロジェクトはV字モデルに沿って進行しました。 プロジェクト計画書の作成 要件定義（機能要件・非機能要件・背景と目的の明確化） 基本設計・結合テスト設計 詳細設計・単体テスト設計 実装・単体テスト 結合テスト・システムテスト 受入テスト・納品 私たちの初期の納期は2025年1月31日とされており、現状プロジェクトの完遂が難しいのではないかと示唆されていました。 ◆PMとして最初にぶつかった壁 PMとしての経験は初めてでしたが、応用情報技術者試験の勉強経験を活かせるかもしれないと思い、挑戦を決意しました。 しかし、座学と実務の差は想像以上でした。とくに要件定義の段階では、 システムの背景と目的 ステークホルダーの整理 機能・非機能要件の定義 といった項目を自分たちで一からまとめる必要があり、「何から始めればよいのか」まったく分かりませんでした。インターネットや書籍を参考にしながら、手探りでドキュメントを作っていく日々が続きました。 さらに、メンバーへのタスクの振り分けがうまくいかず、作業の偏りや進捗の停滞が発生。チームの方向性が定まらない中で、PMとして自分がどう動くべきか悩み続けました。 ◆ユースケース図とアクティビティ図による再整理 現状を打破するため、私はまず、ステークホルダーを明確に洗い出し、「ユースケース図」を作成しました。次に、業務の流れを視覚的に把握できる「アクティビティ図」を作成し、漠然とした要件を少しずつ具体化していきました。 この作業は効果的でしたが、それでも定義が曖昧だった箇所が後に品質保証（品証）で課題となり、苦しむことになります。 ◆限界を感じた私、そして役割交代へ PMとして手探りで進めてきましたが、限界を感じ始めた私は、SV（スーパーバイザ）と役割を交代することを申し出ました。PMとしての重責を担いながらも、自分ができること、貢献できることを模索し、知識の橋渡し役＝中継ぎ役としてチームを支えることを選びました。 この柔軟な対応は、チーム全体の雰囲気にも良い影響を与え、開発は次第に軌道に乗っていきました。 ◆納期延期と変更要求の対応 そんな中、2024年12月15日に顧客から変更要求が発表されました。 内容は、「情報反映のためのデータ管理担当者が離職し、運用が困難になったため、納期を2025年7月に変更したい」というものでした。納期が延期されたことで開発スケジュールにも余裕ができ、基本設計の大枠、システムテスト設計、結合テスト設計を2年生のうちに完了させることができました。 ◆再びPMへ、引き継ぎと新体制 3年生に進級して間もなく、人事異動により現PMが別のチームに移動し、私は再びPMとしてチームを率いることになりました。 引き継ぎはスムーズに行えました。日頃から報連相を重視し、ドキュメントや情報をチーム全体で共有していたおかげで、暗黙知にならずに済んだことは大きな安心材料でした。 ◆現在の進捗と直面している課題 現在はプロトタイプ発表に向けて、基本設計の内容をもとに詳細設計を進めています。 システム方式設計の選定 クラス図、画面遷移図、画面設計図、ER図、データフロー図 シーケンス図、DB設計書、パッチ処理設計書 MVCモデルを用いたクラス構成 を作成してきました。 一方で、要件定義と設計との間に認識のずれがあり、システムテスト設計で品証に時間を取られているという課題も浮き彫りになっています。PMOや品証担当との相談を重ねながら、要件の再確認とテスト観点のすり合わせを行い、乗り越えようとしています。 ◆プロトタイプ発表会に向けた体制変更とコーディングへの取り組み プロトタイプ発表会の日程が発表されたとき、私は正直「このままでは間に合わないかもしれない」と強い危機感を抱きました。設計フェーズが予想以上に時間を要しており、このままでは実装に十分な時間を確保できないと感じたためです。 そこで私は、ただ設計を進めるのではなく、MVCモデルに基づいたクラス図と並行してコーディングも進めてしまう方が効率的だと判断しました。実際にコードを書くことで、設計の妥当性を検証しながら、理解を深めていけるとも考えたからです。 その方針をチームに提案し、旧SVと新たに加入した新SVの2人を軸に、設計チームとコーディングチームに分かれて並行作業を進める体制を構築しました。 この決断が奏功し、現在ではフロントエンド部分はおおよそ完成しています。GitHub上でのコード管理もうまく機能しており、Pull Requestベースでのレビューとマージ、ブランチ運用による分業体制がしっかりと機能してきています。 また、使用している言語・フレームワークは **PHP（Laravel）**です。私はこれまで主にPMとして動いてきましたが、設計が落ち着き次第、コーディングチームに加わり、自らも手を動かして品質向上に貢献する予定です。 さらに今後は、テスト実装を担うチームと本実装を進めるチームにさらに分かれて作業を進める計画です。このようにチームが細分化していく中で、PMとしては全体の状況を把握しつつ、臨機応変にどこへでも関与できるよう準備しておくことの重要性を強く実感しています。 プロジェクト終盤に差しかかるにつれ、「マネジメント」と「現場感覚」の両方を持って立ち回れる柔軟性が、チームの成果を大きく左右することを痛感しています。 ◆最後に：この経験で得たもの このプロジェクトを通して、私はPMとしての責任感、状況判断力、柔軟性、メンバーとの信頼関係の築き方など、多くのスキルと学びを得ました。 座学だけでは得られない「リアルな現場感」や「思い通りにいかない苦しさ」、そして「それでも前を向いて取り組む姿勢」を体験できたことは、これからの自分にとって大きな財産です。 プロジェクトは2025年7月下旬の最終発表会をもって終了予定です。残りの期間もチームで協力しながら、品質の高いシステムを目指して、日々精進していきたいと思っています。 ご覧いただき、ありがとうございました。