『大 規 模 開 発 管 理 』につい て
SI 事業部 技術２部

細1. は じ め に

2. 役

システム開発において小規模から大規模まで開川

浩

治

割

プロジェクトを形成するメンバーは，以下のような発総工数により分類されるが，大きくなればプロ体系となる。

ジェクトの体制も大きくなり，リスクも比例して①基本的には，すべての役割をアサインこと。

大きくなる。１００人月オーバーのプロジェクトで②開発規模とプロジェクト要員は，揃えること。

リスクの読みを間違えると大きなダメージを受け③適材適所の要員をアサインすること。

ることになる。システム開発のプロジェクト管理④指揮命令系統を体系の通り定めること。とはまさに問題と解決をいかにコントロールする⑤メンバーに対する責任者（指示・管理）は，サブかであり，規模が大きくなればなるほど問題点もリーダである。

多くなり，その対応如何によりリスクも上下する。

⑥サブリーダに対する責任者（指示・管理）は，ププロジェクト管理手法により，このリスクを分散ロジェクトリーダである。

し軽減することが可能である。以下にその手法を⑦マネージャは，プロジェクト全体の責任者であ要点のみ述べることとする。ただし，特別な管理手る。

法を用いた訳でもなく，ごくあたり前の管理手法でプロジェクトを形成する場合，役割分担を明確にあり，小規模からのシステム開発でも問題なく適することが必要である。誰がリーダで誰がサブリー用できる。

ダで…，作業範囲と権限・責任を明確にすることである。
プロジェクト・総括責任者

プロジェクト・マネージャ

営業責任者

プロジェクト・リーダ

営業担当

プロジェクト・サブリーダ

プロジェクト・サブリーダ

プロジェクト・サブリーダ

プロジェクト・サブリーダ

メンバー

メンバー

メンバー

メンバー

1/5

アシスタント全体サブリーダ** 機能サブリーダ** 機能サブリーダ** 機能サブリーダ

メンバー

メンバー

メンバー

設計チーム／製作チーム／試験チーム
工期が比較的長いもの，大規模なものは，設／を産むことになる。

製造／試験の大きく３つのチームに分類し，それシステムを同じ視点で見ることも必要だが，設ぞれにサブリーダを配置させるとよい。また，それ計の立場から，製作の立場から，試験の立場から，ぞれのフェーズの中は，機能単位に細分化し各人それぞれの立場から見ることも重要であると思の役割を明確化させる。

う。

プロジェクトは，やはりリーダ・サブリーダがいろんな意味で大きな影響を与える。一般的に，リーダ

4. コミュニケーションがしっかりしていればなんとかなるものだが，大規プロジェクトとして一番大事なものがコミュニ模になればなるほど要員数も増しサブリーダの資ケーション である。コミュニケーション がない質も問われる。ただし，理想のアサインはできない

プロジェクトはその時点で大きな障害を抱えてのが実情であるため，チームとして役割が重要となおり，コミュニケーションに問題があると必ずトる。

ラブルが発生する。プロジェクト の中でいろいろな役割（立場）のメンバーが存在することになる

3. 各フェーズでのチーム編成についてが，必ず毎日ミーティングを行うことが必要であ大規模システムでは，是非とも死守してほしいのる。これは，全員で集まると非常に人数が多いこが，設計・製作・試験のメンバーにある程度は，とになるのと，ミーティングのテーマが設定し難重複しないメンバー（専任）をアサインすることでい面があるので，あるグループ単位に実施すればある。設計したものがそのまま製造するのが効率よい。

的でいいのではないかとの意見もあるが，設計また，あるサイクルでできる限り多くのメンバーとチームは製造チームへ設計書を介して作業を引きコミュニケーションを図れるようにミーティングを計継ぎ，ここで設計品質が確保できる。いい加減な画することが必要である。

設計だと製造チームからクレームが挙がることになる。さらにもう一つの効果としてチーム間に5. 情報交換と整理おのずとコミュニケーションが発生し相乗効果

ユーザとの情報のやり取りおよび プロジェクト

2/5

内での情報交換の情報量はプロジェクトがユーザ

応用技術大きくなればなるほど，情報量も比例して大担当きくなる。この情報整理がプロジェクトの進担当･･info‑C@･･･.co.jp

担当
担当

捗および品質に大きな影響を与えることにな担当担当

る。基本的に，すべての情報を電子データと担当担当して管理することを前提とする。

※特にユーザとやり取りする情報に関しては，透《ユーザとの情報交換》

明性を重視するとともに，特定個人の情報となり◆ユーザとの情報交換の媒体としては，共通得ないように関係担当者に送信するようにする。

フォーマットの用紙を使用する。
Ex)･連絡《プロジェクト内の情報交換》

票；仕様等の連絡／確認／質

基本的には，コミュニケーションを重視するため，問等…
票；障害連絡打合せ形式による情報交換を前提とするが，些細・リリースノー ト；リリース時のリリース情報な確認事項および事前周知事項／連絡等，すべ・etc…てＭＬにてやり取りを行なう。プロジェクトに係わる・障害

情報は，原則，些細なことでもすべて関係者に連◆情報により ML（Mailing list）を作成し，この MLを介してやり取りする。

絡が伝わるようにする。情報の共有化とＭＬにて流●情報により，関係する担当者へ mail が送信される情報により，発信者の状況を確認することにも役立つ。

れるようにする。

注意してほしのは，ＭＬにてやり取りすることがユーザ

応用技術

基本ではなく，情報交換は打ち合わせ形式で行う

担当･･info‑A@･･･.co.jp

担当

ことが前提であり，ＭＬは極端に言えば，その打ち担当合わせ結果をメンバーに周知させるために使用す担当ることである。

担当担当･･info‑B@･･･.co.jp
担当担当

担当Ex)

担当

・各チーム内 ML

担当･･info‑C@･･･.co.jp

・基本設計 ML担当

・詳細設計 ML･･info‑D@･･･.co.jp

・障害 ML
●社内では，ユーザに送信した mail は，必ず関・全メンバーML係担当者にも送信されるようにする。

・etc…

3/5

･･PRO‑C@･･･.co.jp･･PRO‑A@･･･.co.jp

問担当

担当

担当

担当

担当

担当

担当

担当

･･PRO‑D@･･･.co.jp

題担当

担当

担当

担当

第一解決者

･･PRO‑B@･･･.co.jp

６．問題点の解決手法
プロジェクトの中では，ユーザ間を含め日々多くの問題が発生する。問題はすべて解決することが解決案前提となり，問題の置き去り・間違った解決は，プロジェクトに何らかの影響を与え，小さなことでも積み重なれば大きなダメージを受けることにもつながる。
解決手法としては，非常に単純であるが，問題複数で再確認に対する解決者（特定メンバーが選定できない場合は，複数関係者を選定する。）を選定し，解決予定期日を定め解決にあたる。解決した内容は，関係者により再度，解決内容を確認する。

７．意 思 決 定

要は，一人の判断では解決とみなさない。必ず複数のメンバーにより最終判断を下す。

いろいろな場面で判断（決断）することがあるが，判断を下すことのできるものは仮に判断が間違っ問題の解決時の対応として常に問題のもつ影た場合に，責任（対処）が取れることが条件となる。

響範囲を予測する必要がある。特に工期に影響すこの条件を守れない可能性があれば，当然ながらる問題であれば，最終的な工程までシミュレーショ上位のメンバーに判断を仰ぐことが必要である。

ンし影響を検討する必要がある。一般的に工程に基本的には，ある程度，影響度のある判断につい影響が出る問題は，最後のフェーズで調整せざるては，複数関係者による判断を原則とすればよを得ない状況になりがちであるが，いつかは調整い。

不可能な状況になり，多少なりと後工程まで尾を引きそうな問題は，要注意である。

また，判断のレスポンスは重要であり，ひとつの判断の遅れが及ぼす影響は常に把握（予測）し，できる限り早めに対処することが理想である。

4/5

８．規約（ルール）
プロジェクトが大きくなれば，要員もそれだけ多くなる。このメンバーをコントロールするにはりアナログ的な対応であり，言葉での表現は非常に難しいが，あえて言うなら 勘 ということになる。

は，リーダが声を張り上げて制御しても限度がある。
前述の情報交換で ML の活用もそうであるが，マネージャ（リーダ）は，日々この 勘 という微妙な感覚を発達させ精度を高めることにも努力してほしい。

作業手順を規約化することも重要である。組織もそ最後に非常にあいまいな表現となってしまった

うであるように，あるルールに基づいて活動していが，システム開発の中でプロジェクト管理は，管理る。プロジェクトも同じようにルールを作り，これにする内容・手法等，明確に定義することは可能で従うべきである。ただし，この規約は運用して問題あるが，いざ実行となると，なかなか思うようにいかがあれば，臨機応変に変更し，常に状況に応じたないものである。しかし，システム開発を行うというものに変更することが必要である。

ことはプロジェクトに存在していることであり，いつEx)でも管理手法について見て習得できる環境にある。

・連絡票運用規約

メンバーはサブリーダ，をサブリーダはリーダの管・障害管理規約

理手法について自分なりのシミュレーションをした

・工程会議規約

り，打ち合わせの場等で積極的に自分の意見を出・開発環境規約

すようにしてもらいたい。

・コーディング規約
・ライブラリ管理規約
・etc…

９．お わ り に
プロジェクト管理としてリスク分散・軽減が大きな課題であるが，単純なことでもなかなか実行することが難しいのが現実である。マネージャ（リーダ）としてプロジェクトを遂行する場合，やはり経験が重要である。
経験の中でもいろいろな局面においての判断能力・予測能力を身に付けることが重要である。プロジェクトの構成要員は 人 であり，プロジェクトを動かすのも 人 である。デジタル的な対応も必要となるが，経験を重ねてほしい部分は，や5/5