ソフトウエア開発の体制　- -　マネジメントの道具箱

はじめに

　プロジェクトマネジメントとは、プロジェクトの目標を達成するために「人」「品質」「予算」「時間」などを適切に管理しながら、チームを率いる仕事です。
　ソフトウェア開発の場合は、単にプログラムを作るだけではなく、適切な体制のもとでのマネジメントが求められます。
　プロジェクトマネージャー（PM）としては、開発の全体像を把握し、効率的にチームを編成し、プロジェクトを円滑に進めることが求められるのです。

　ここでは、ソフトウェア開発における開発体制に焦点を置いてその考慮すべき点を書いてみたいと思います。

1. ソフトウエア開発の体制とは

1.1 概要

　ソフトウエア開発は、要件定義、設計、開発／実装、テスト といった工程・流れで進められます。
　これを支えるのが、プロジェクトマネージャー、リーダー、システムエンジニア（SE）、プログラマー（PG）、テスターなどの役割を持つメンバーたちです。

　プロジェクトの規模に応じて、組織の構造や役割は変わります。
　大規模開発では複数のチームを編成し、役割を細分化する場合がありますが、小規模開発では少人数で多くの工程をこなすこともあります。

1.2 建設業との共通点

　ソフトウェア開発は、しばしば建設業と比較されます。
　たとえば建物を建てるときには、設計、資材調達、施工、検査といった工程があります。同様に、ソフトウェア開発も「要件定義」「設計」「開発・実装」「テスト」といったプロセスを経て完成します。

　また大規模開発の場合、建設業では大手ゼネコンが元請けとなり、下請け・孫請けが実際の作業を担うことが一般的ですが、ソフトウェア開発でも同じような構造が見られます。

1.3 下請け企業の存在

　ソフトウェア開発の現場では、1社だけで開発を完結させることは少なく、多くの場合、下請け企業が関わります。
　特に大規模開発では、元請け企業がプロジェクトを受注し、下請け企業やフリーランスの技術者に作業を委託 することが一般的です。

　元請け企業からの発注を受けた企業が、さらに別の企業に業務を委託することもあります。これを「多重下請け構造」と呼びます。
　この構造は、コスト削減や専門性の活用といったメリットがある一方で、伝言ゲームのように情報伝達が遅れたり、責任の所在が曖昧になったりするリスクもあります。
　そのため、プロジェクトマネージャー（PM）は、関係者とのコミュニケーションを適切に管理する必要があります。

　※下請け企業：「協力会社」と呼ぶこともあります

2. ソフトウエア開発のチーム構成

2.1 大規模開発と小規模開発との違い

　ソフトウェア開発は、プロジェクトの規模によって体制が異なります。

(1)大規模開発（例：銀行の基幹システム開発）
　・数十～数百人規模のチーム
　・プロジェクトマネージャー（PM）、プロジェクトリーダー（チームリーダー）、SE、PG、テスターなどの階層的なチーム構成
　・分業制で、要件定義・設計・開発／実装・テストを各担当が進める
　・役割が細分化され、階層的な組織になる
　・複数の下請け企業が関与することが多い
　・チーム間の調整が重要になる

(2)小規模開発（例：スタートアップのアプリ開発）
　・1人～数人程度
　・一人のエンジニアが複数の工程を担当（設計から開発／実装、テストまで）
　・役割が曖昧で、1人が複数の仕事をこなす
　・コミュニケーションが取りやすい
　・素早い開発が可能だが、属人的な開発になりやすい

2.2 チームメンバーの役割

　プロジェクトチームは、経験やスキルに応じて異なる役割を持つメンバーで構成されます。それぞれの役割を明確にし、適切な業務分担を行うことが、プロジェクト成功の鍵となります。

(1)プロジェクトマネージャー（PM）
　プロジェクト全体の進行管理、リスク管理、意思決定を担当

(2)プロジェクトリーダー（チームリーダー）（PL/TL）
　開発チームの統括・指揮、技術的な指導、進捗管理を担当

(3)システムエンジニア（SE）
　要件定義、設計、テスト計画の作成を担当

(4)プログラマー（PG）
　実際のコーディング、単体テストを担当

(5)テスター
　ソフトウェアのテストによる品質保証

(6)新人など（経験の浅いメンバー）
　プログラムのテストや簡単なコーディングなど、基本的な開発作業を学びながら実践し経験を積んでいく

(7)ライブラリアン
　大規模プロジェクトなどで、ソースコードの管理、構成管理、ビルド／リリースのサポート、ドキュメントとプロセス管理、アクセス権限・承認フローの管理などを担当
　開発形態や開発ツールの変化に伴い、DevOpsエンジニアや構成管理担当者（SCM担当）、あるいはCI/CDエンジニアに引き継がれているケースが多い。また、GitHubやGitLab、Jenkinsなどのツールの導入により一部の作業は自動化されている。

2.3 工数と費用の見積もり

　ソフトウェア開発のために必要な人件費、ツール費、インフラ費、テスト費などの総コストを事前に見積もります。

　見積もりに関する主な方法としては次の様なものがあります。

　・類似案件ベース
　　過去に似たようなプロジェクトがある場合、それを参考に費用と工数を推測します。短時間で出せますが、精度は低めとなります。

　・ボトムアップ見積り
　　各作業単位（タスク）に分解し、それぞれの工数・費用を積み上げる方法です。手間はかかりますが、精度は高くなります。

　・ファンクションポイント法
　　システムの機能数（入力、出力、画面、ファイルなど）に点数をつけ、工数に換算する方法です。比較的大規模案件向けです。

　・COCOMOモデル
　　ソフトウェアの開発規模をもとに開発工数を数式で算出する古典的モデルです。現在は改良版の「COCOMO II」もあります。

　これらの詳細な解説は別の機会として、ここでは主に人件費について書きます。

(1)工数の見積もり

　ソフトウエア開発では、「人月（にんげつ）」 という単位で工数（作業量）を見積もることが多くあります。
　例えば、「この開発には10人月が必要」と言った場合、1人で作業すれば10カ月、5人なら2カ月かかる計算になります。

　しかし単純に「10 人月＝5人で2か月」とはならないのです。

　古くからフレデリック・ブルックスの著書『人月の神話』で指摘されているように、人を増やしても作業効率は単純には向上しないという問題があります。

　「遅れたプロジェクトに人を追加すると、さらに遅れる」と指摘されています。
　新しいメンバーが増えると教育や調整に時間がかかるため、単純に人を増やしても効率が上がるとは限らないのです。
　特に開発工程の後半ではそれが顕著となります。
　開発当初からの適切な人員配置が重要となるのです。

(2)開発費用の見積もり

　工数の見積もりをもとにして、各作業工程ごとに必要となる人件費を見積もります。

　開発要員については、それぞれの「スキル」「経験」などをもとにしたランクづけ（S、A、B、C、D　など）がされている場合があり、そのランクに応じて時間単価が一律に割り当てられています。
　例えばランクは次の様になっています。
　マネージャ=S、リーダー=A、SE=B、PG=C、新人=D

　各ランクの要員の人月をもとにして、開発全体の費用（人件費）を見積もります。

　このランク付は、基本的には実力（知識、スキルなど）と経験年数を加味して決められています。
　しかし時に実力と一致していない場合も存在します。中には「使えない」人がいる場合もありうるのです。
　これらを加味して、マネージャーは開発要員の適材適所への配置を考えなければなりません。

3. プロジェクトマネージャーの役割

　プロジェクト・メンバの能力を引き出し、個人かつチームとしてのパフォーマンスを最大化します。

3.1 チーム編成

　プロジェクトマネージャーは、適切なメンバーを適切なポジションに配置します。

(1)要員の調達
　・要員計画の策定
　　・コスト見積もり
　　・原価管理
　　・体制設計
　　・リスクの考慮
　・調達戦略の立案
　・下請け業者の評価・選定
　・外部の専門家の活用
　・契約後のパフォーマンス管理

(2)要員の配置
　•適材適所の人員配置
　•経験豊富なメンバーと新人とのバランス
　•各メンバーの得意分野やスキルの考慮

(3)要員の変更管理
　・スコープ変更時の影響分析
　・要員計画との整合性確認

3.2 人間関係の調整と管理

　技術力だけでなく人間関係のマネジメントも重要です。
　特に大規模プロジェクトでは、チーム内外の対立やコミュニケーション不足が原因でトラブルが発生することも少なくありません。
　日本の企業文化では、上下関係や年功序列の影響が考えられ、若手の意見が埋もれないよう配慮することも求められます。
　PMには技術的な判断だけでなく、人と人をつなぐ調整役 としてのスキルが求められるのです。

(1)ステークホルダーとのコミュニケーション
　・ステークホルダーの分析
　・ステークホルダーの期待値の調整
　・適切なタイミングでのコミュニケーション実施

(2)チーム内でのコミュニケーション
　・コミュニケーション計画の策定
　・円滑なミュニケーションが進むチーム構成
　・チーム内の状況把握
　・定期的なミーティングの実施
　・情報共有の円滑化

(3)人間関係の調整
　・メンバー間の対立防止
　　・メンバー同士の意見が食い違ったときの調整
　・メンバーの役割の明確化
　・心理的安全性の確保
　　・意見を言いやすい雰囲気づくり
　・モチベーション管理
　　・評価制度や成果の可視化
　　・適切なフィードバック

3.3 人材の育成

　メンバーの成長を促す環境を作ることも重要です。
　新人には学ぶ機会を、経験者にはリーダーシップを発揮する機会を提供することで、チーム全体のスキルアップにつながります。

4.考慮すべきこと

　PMBOKの10の知識エリア（第6版ベース）に基づいて、ソフトウェア開発体制の構築における考慮事項・注意点を整理します。

(1)統合マネジメント（Integration Management）
　・要件が大きく変化する可能性がある場合、アジャイルなど柔軟な手法の採用も検討します。
　・人員数や役割分担、工程設計を、期間と規模に応じて調整します。
　・プロジェクト全体の整合性をとるようにします。
　　→開発体制、技術、要件、スケジュールなどが整合していること常にチェックします。
　・複数のベンダーや関係部署が関与する場合、方針のブレや責任の曖昧さが生じないようにします。

(2)スコープ・マネジメント（Scope Management）
　・体制はスコープの規模・複雑さに応じて調整するようにします。
　・無駄が発生しないように、スコープを明確にして開発体制を組みます。
　・作業工程ごとの目的・目標を明確にして、体制がブレないようにします。
　　（開発体制は、工程（何をどこまで作るか）によって大きく変わります。）

(3)スケジュール・マネジメント（Schedule Management）
　・工程ごとに必要な人員・スキルを見極め、計画的にアサインします。
　・混乱を避けるため、スケジュールがタイトな場合は特に、開発体制を急増させないようにします。

(4)コスト・マネジメント（Cost Management）
　・総合的なコストを考慮して、内製か外注か、固定価格か工数ベースかなどを判断します。
　・人員過剰によるコストオーバーがないように配慮します。
　・短期的な納期優先で、後工程（メンテナンスなど）のコスト増大がないように配慮します。

(5)品質マネジメント（Quality Management）
　・品質を担保するためのレビュー、テスト体制、標準プロセスの整備などを考慮します。
　・「動けばよい」になりがちな文化や、属人性の高いコードの放置などがないように配慮します。

(6)資源マネジメント（Resource Management）
　・必要なスキル、経験を持つ人材を確保します。
　　→使用する言語やフレームワークに適した人材を確保します。
　・重要なポジションには特に、相応のスキルを持った人材を配置します。
　・モチベーション維持策も考慮すると良いでしょう。

(7)コミュニケーション・マネジメント（Communication Management）
　・チーム内・外の情報共有、リモートやオフショア含むコミュニケーション手段を設計します。
　・情報が一部の人にしか届かないことがないようにします。

(8)リスク・マネジメント（Risk Management）
　・技術的リスク、人材確保リスク、外部依存のリスクなどを考慮します。
　・楽観的な前提による見落としを避ける様にします。
　　（特に新人や新技術導入時は注意）

(9)調達マネジメント（Procurement Management）
　・外部ベンダーの活用範囲、契約条件、品質・納期の保証などを明確にします。
　・契約範囲の曖昧さ、責任分界点の不明確さがないようにします。

(10)ステークホルダー・マネジメント（Stakeholder Management）
　・開発体制への理解と協力を得るために、社内外の利害関係者との関係を構築します。
　・現場の声を拾わず、上層部だけの視点で体制を決めてしまうことがないようにします。

5. 関連書籍の紹介

・人月の神話[プリント・レプリカ] Kindle版
　フレデリック・P・ブルックス，Jr. (著)、滝沢徹 (著)、牧野祐子 (著)、富澤昇 (著)
　丸善出版 (2014/4/20)
　大規模開発プロジェクトにおけるソフトウェア工学の古典として読み継がれている名著。　「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ」というブルックスの法則は名高い。開発において「人員×月日」というスケジュール見積もりを適用する問題点を指摘する。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

・プロジェクトマネジメント知識体系ガイド
　（PMBOKガイド）第7版 Kindle版
　＋プロジェクトマネジメント標準: PMI日本支部監訳
　プロジェクトマネジメント協会（PMI） (著)
　一般社団法人 PMI日本支部 (2023/1/6)
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

・図解即戦力　PMBOK第7版の知識と手法がこれ1冊でしっかりわかる教科書 Kindle版
　前⽥ 和哉 (著)
　 技術評論社 (2024/9/20)
　プロジェクトマネジメントの世界標準として知られるPMBOK Guide 第7版の解説書です。「プロジェクトの基本」「価値実現システム」「12の原理・原則」などプロジェクトマネジメントの基礎となる知識のほか、PMBOK第7版のメインテーマともいえる「8つのパフォーマンス領域」について、要点をくわしく解説します。プロジェクトマネジメントの勉強のほか、PMP試験対策の第一歩としてもおすすめできる1冊です。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

・図解入門よくわかる最新PMBOK第6版の基本 Kindle版
　鈴木安而 (著)
　‎ 秀和システム (2018/3/23)
　PMBOKガイドは、米国プロジェクトマネジメント協会により、日本語を含め世界11ヶ国語に翻訳・出版されています。翻訳されても、専門用語が多い、カタカナ用語が多いなどの理由からなかなか理解が困難です。本書は、『PIMBOKガイド第6版』の翻訳・監訳チーム・リーダーでもある著者が、本来の意味をなるべくかみ砕いて解説します。イメージしやすいよう図版を豊富に使っているので、初心者からベテランまでわかりやすくなっています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

・プロジェクトマネジメントの基本がこれ1冊でしっかり身につく本 Kindle版
　前田和哉【著】
　技術評論社（2022/06）
　本書は、プロジェクトマネジメントについて基本から学ぶことのできる入門書です。プロジェクトマネジメントの基礎知識について解説した後、プロジェクトを「立ち上げ」「計画」「実行」「監視・コントロール」「完了」という5つの段階に分け、各段階において実施すべきこと、注意すべきポイントについて丁寧に解説しています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

おわりに

　ソフトウェア開発は多くの専門職が連携しながら進められます。
　そのマネジメントを実施するPMには、単なる進捗管理だけでなく、チーム編成や人間関係の調整、リスク管理など、多くのスキルが求められるのです。

　プロジェクト成功の鍵は、「適切な人員配置と、柔軟なマネジメント」です。
　今回紹介したポイントを理解し、実際のプロジェクトで活かすことで、より円滑なマネジメントに活用してください。

実践・プロジェクトマネジメント［概要編］　- -　マネジメントの道具箱