プロジェクトマネージメントとして定めておくことは、プロジェクトとして
の実行組織・実行管理の元になる各組織としての役割分担・責任が定まって
いることです。
その理由は、プロジェクトは履行目的の完了（検収完了）で終了します。
アフターフォローは各組織の業務責任の範囲で履行していかなくては、
「納入しっぱなしの事業」になってしまうためです。
上記の例外
スポット開発（基礎技術のためにプロトタイピング開発）や、祭事運用
目的のシステム運用（要件/システム設計/施行/運用（役務））などは、
完了後、実務履歴（設計ドキュメントや計画書など）による技術移転
や会期終了で終息する案件のため、プロジェクト主体のみで運営される
場合がある。
プロジェクトマネージメントの一言説明：
各組織を縦横する進捗で発生する課題を逸早く解決し目的とするゴール
地点に導く役割をさす。
プロジェクトマネージメントが扱う管理は、企画プロセスや、商品化
プロセス等とは異なる観点で管理していくことで、目標を達成する。
従来業務のプロセスや工程とプロジェクトマネージメントで制御して
いく項目は異なり、相互関係でリスクを最小限に減らす活動にする
役割。
プロジェクト遂行ための管理項目（範囲）とプロセスの体系で成り
立っている。
手足になるのは、プロジェクトメンバーとして参画した各部門の担当
者が従来業務としてのプロセスに則り、下記のプロジェクトの管理
項目で進めていく。
１）１０の管理項目
管理項目は、通常組織業務の差長手順で示されるプロセス管理とは
異なり、プロジェクト（案件）を遂行するために特化した管理項目
により実施されます。案件を遂行するには、従来業務のノウハウが
必須ともいえます。
①総合管理
プロジェクトの立上げから終結までを管理する。
実行組織がもつ作業標準（業務規程/WBSなど）から、プロジェクト
・スコープを策定し、WBSの最下層となるワークパッケージやその
下に位置する（子）アクティビティに対して、所要時間や依存関係、
必要リソースやコストを調整していくことで作成する。
これが、プロジェクトの実行計画書の元になる。
②スコープ管理
2つの視点の管理が含まれる。
１つは、何を行っていくか（行動/アクション）
基本業務として実施されている場合、同じことを行っても、
意味がない。スコープ管理では、基本行動以外、顧客の案件に
特化した行動として定義し、プロジェクトの中で基本行動に加え
ていき、メンバーで共有して進める。
２つは、何を作るか（受注提供物）
納品時の成果物として提供すべきものをメンバーで共有し、
それぞれの実行計画により具現化していく。
③スケジュール管理
スケジュールは、総合管理やスコープ管理で明確になった作業工程
を列挙し、時間軸ごとの計画として作成していく。
実作業組織の工程は実作業組織内の管理として進捗管理する。
ここでは、スコープ管理として上げられている管理項目の
スケジュール管理として進捗を可視化していく。
ガントチャートなど、一般的な管理方法。
④コスト管理
コスト管理には、フェーズにより５つ（各工程の単位を営業、
システム技術、王子（エンジニアリング）と定めた場合）の基本要素
がある。
1つは、見積段階のコスト
2つは、受注確定段階のコスト
3つは、各工程の計上（予算）時、作業工程毎の原価（労務費）コスト
4つは、各工程の実績時、実績原価コスト
5つは、各工程で計上した実績原価コストの集計
これらのコストは、リアルタイムで原価管理のポリシーに従った執行
を行い、予算の執行を管理していく。
⑤品質管理
広義な意味で品質は全役割に掛か管理項目となる。
単純に成果物品質を管理するだけではなく、スケジュールに関わる
タイムスケールの加味した品質管理を実施（スケジュールに照らし
合わせた品質管理）する。
また、成果物の試験までも含めて行う。
⑥組織管理
組織管理は、要員管理とも言う。
メンバーごとの付加状況を把握し、タスクの振り分けは分割で回避
などが含まれる。適材適所にするために再配置もあり得る。
⑦コミュニケーション管理
プロジェクトの失敗の多くはコミュニケーション管理の失敗が原因。
そして、自己満足的な仕事が一番危険。これを回避するために、常に
ミーティングやレビュー、ウォークスルーを実施し、議題や結果
（方向つけしたこと）をミーティング記録としてメンバーが参照で
きるようにする。統制を取ることもコミュニケーション管理の一つ。
必ず後工程にも綱割るようにすることも忘れずに！
⑧リスク管理
プロジェクトは、初期の計画通りに進捗することは稀です。
リスク管理は発生しえる問題を予測しその対策を事前に用意して
おくことや、事前にリスクが発生しない対処を行うことで、突発
リスクに割かれ工数を最小限に抑えることに尽きます。
そして、次組織（プロジェクト内）で制御可能なリスクなのか、
制御不可能なリスクなのか見極めておくことも重要です。
⑨調達管理
納入設計により確定された機材や部材を外部より調達する場合、
もしくは、特型品（ハードウェアやソフトウェア）を外注委託
すると場合には、委託先の管理が必要となります。
下請法を理解した上で委託物の設計レビューや、最終レビュー
（検収前の設計審査会）などを通して、確実な成果物の納入に
つなげます。
市販品購入では、コスト管理や納期管理及び初期不良等を
スクリーニングする受け入れ管理など多岐にわたります。
⑩ステークホルダ管理
顧客や仕入先などの外部で関わるメンバーなど、常に、
適用範囲内のスケジュールにより真摯な情報を的確に流し、
良好な関係を構築していきます。
特に、対顧客には、成果物の納品とその納品物（成果物）の運用
までを最適な手段で教育していく考慮なども、事前説明なども念頭
した管理を行う。
２）５つのプロセス項目
受注時の作業プロセスには、受注前活動として商談や提案、要件
抽出や要件定義（具現化素案）に始まり案件としての見積仕様や
原価積算、見積書（見積金額の確定）などのプロセスがある。
また、受注確定後のプロセスでは、見積として確定した見積仕様を
起点としたシステム設計作業とその成果物のシステム設計書、
納入仕様書などと繋がって前工程の作業を最大限活用したプロセス
で運用していく。
このプロセス（工程作業）とはことなり、プロジェクト管理項目
ごとのプロセス管理として独立管理をしていくことになる。
そのプロジェクトのプロセスが5項目ある。
a．立ち上がりフーズ
統合管理、ステークホルダ管理としての定めを明確にしていく。
b．計画フェーズ
10の管理項目全てが対象になる。
c．実行フェーズ
統合管理、品質管理、組織（要員）管理、コミュニケーション管理、
調達管理、ステークホルダ管理実務フェーズで各組織が持つ業務
規程を活用した活動とプロジェクト固有で定めた活動で実施して
いく。
d．監視・管理フェーズ
10の管理項目全てが対象になる。
e．終結フェーズ
受注案嫌悪契約履行として契約完了（検収後の教育訓練等が
発生する場合がある）
３）3つのパート
パートは、それぞれの仕事の作業単位の出入り口と処理に値する
管理を指します。
イ 入力
入力は、各工程の情報源となる、この情報源の確からしさを高める
ために、類似経験者や専門性の技能がある有識者、プロジェクト
メンバーによるレビュー等を行い重力品質を高める。
顧客の情報を自社内に伝達する場合には、自己解釈を極力排除した
成果物として、客先の精査を受けることも重要な品質確保に繋がる。
ロ ツールと実践技法（力量）
実行するに当たり、利用可能なツールや必須ツールをメンバーで
共有して進める。特に情報を共有化するツールでは、成果物
（ドキュメントなど）の新旧の待ちが絵を排除できるツールを用いる
など、様々なプロジェクト内の課題を明確に報知していく手段とし
てツールはひつ予不可欠になる。
また、実践で効力を発揮する技法（仕事をこなしていくノウハウを
含む）は、人に依存する場合が多いが、ペアーになった活動により
OJTを心がけながら実践していく。
ハ 出力（中間成果物/最終成果物）
出力は、各工程の結果となり、重力同様に成果物の品質を高めた
状態で出力しなければ、後項手の工数がリスクとして浮き彫りに
なってしまう。このようなことが発生しないようにすることも
プロジェクト管理は以下で統制ある行動を実行していくことになる。
プロセスごとの成果物は、出力順番（時系列）にあわせて共有資産
として参照できるようにする。また、客先出図時の管理なども発生
する。
プロマネは、1案件1人・・・・
そんな会社はどこにも無い。
固定費が膨れ上がり、益が生まれない体質になる。
よって、管理ポイント熟知し、実作業者を的確に把握し、判断し、制御する
ことが、主要な業務になる。
謝辞：
PMBOKの説明など、多くの企業やサイトがあります。言葉や文章で、
類似もしくは同等になってしまいますが、営利目的ではありません
のでご了承ください。
プロジェクトマネージメント（プロジェクトマネージャー）を導入し実行し
たが、効果が出なかった、または、仕事が煩雑化した。
何故こうなるか、。
一つに、役割や責任の範囲が各自の思惑により異なるからです。
PMBOK（Project Management Body of Knowledge）とは
プロジェクトマネジメントに関するノウハウや手法を体系立てて
まとめたものです。
非営利団体PMIが「A Guide to the Project Management Body of
Knowledge」というガイドブックで発表（1987年）。
プロジェクトマネジメントの世界標準（事実上の標準）として
世界各国に浸透しています。内容は４年に１度（程度）のペース
で改訂され、最新版は2017年に発行された第6版となっています。
作成の団体
PMI（Project Management Institute）は、アメリカに本部が
あります。日本では1998年にPMI日本支部（PMIJ）が設置され、
PMBOKの普及促進やPMPという資格の認定、交流などを行ってい
ます。
PMP
PMP（Project Management Professional）とは、PMI本部が認定
しているプロジェクトマネジメントに関する国際資格です。
PMP資格の特徴は、単なるプロジェクトマネジメントの知識だけ
でなく、取り組み方や経験など実務的な内容を重視しているとこ
ろです。また、1回取って終わりと言うものではなく、一定期間
ごとにCCR（Continuing Certification Requirements：継続認定
要件）と呼ばれるプログラムの履行が義務付けられます。
それは3年ごとにPDU（Professional Development Units）という
単位を60ポイント以上取得するというもので、これをパスしない
と認定を抹消されます。
PMBOKの意義
1つは「プロジェクトマネジメントを初めて体系化したこと」です。
これまではプロジェクト管理と言っても、その言葉の示す範囲や
内容はバラバラでした。ある人はスケジュール管理をイメージし、
ある人は原価管理を重点的に考えるというように、プロジェクト
管理とはという命題に対しての明確な答えがない状況でした。
PMBOKは、このように各人各様のものだったプロジェクト管理を
10の管理エリアと5つのプロセスに整理し、体系立ててくれました。
そのおかげで、その後のプロジェクトマネジメントの発展に大きく
役立つ基礎ができていると思います。
もう1つは、「プロセスをマネジメントする」という考え方の重要
性を押し出したことです。
従来のプロジェクトマネジメントは、製造業で昔から謳われている
QCD管理が中心でした。QCDはプロジェクト管理の3要素とも呼ばれ
ており、Quality（品質）、Cost（原価）、Delivery（納期）という
3つのゴールを定め、その目標に向かってプロジェクトをコント
ロールするというものです。しかし、ゴールだけを目指してもなか
なかうまく行きません。
目標を達成するためには、そこに至るプロセスも対象としてコント
ロールする必要があります。そのような考えに基づいて、PMBOKでは
スコープ管理、リスク管理、要員管理、コミュニケーション管理、
調達管理なども明確なコントロール対象としているのです。
これらはプロジェクトの最終目標ではないのですが、最終目標であ
るQCDを実現するためにはきちんと管理する必要があるのです。
PMBOKの限界
PMBOKはあくまでもプロジェクトマネジメントのBody of Knowledge
（知識集）です。プロジェクトマネジメントを学び、理解するため
のバイブルではありますが、過大評価してはなりません。PMBOKの
限界をきちんと理解した上で、あくまでもプロジェクトマネジメント
の基礎知識を整理するという目的で活用しましょう。
PMBOKの限界は、主に２つあります。
1つは、
あくまでも知識集なのでそのまま現場では使えないという
ことです。
現場で使うにはツールが必要です。
PMBOKを理解した上で効率的なプロジェクトマネジメントツール
を活用するというアプローチが求められるのです。
勘違いし易いのですが、ここで言うツールとは書かれていること
を忠実に実行するツールではありません。
知識集をそのままExcelなどで実施できるようにしても、現場で
使うツールとしては非効率過ぎてそっぽを向かれます。
PMBOKを把握した上で、もっと実践的・効率的なツールが必要と
されるのです。
2つ目は、
PMBOKはあくまでも1つのプロジェクトをマネジメントすること
に焦点を絞っていることです。
企業では通常複数のプロジェクトが平行して走っており、それら
を串刺しにチェックしたり、束ねて集計してみたりすることが
必要になります。企業におけるプロジェクト管理力向上という
点に関しては、PMBOKでは触れていないのです。
実務ノウハウや実務手順は、既存組織のノウハウを活用し、また、
既存実務のプロセスを用いることで、実務に直結するプロジェクト
マネージメントを実現していきます。これら既存の組織の専門性の
ノウハウや行動判断基準、プロセスが最適なツールといえます。
PMBOKをどのように活用するか
PMBOKは実践的な手段ではありませんし、具体的な方法を示して
くれるわけでもありません。組織のプロジェクトマネジメントを
強化してゆくためには、PMBOKとは別に実践的かつ具体的な手法や
ツールを独自で用意する必要があるのです。では、PMBOKはどの
ように活用すればいいのでしょうか。それとも役に立たないもの
なのでしょうか。
PMBOKの整理されたノウハウ、知識は、世界レベルの生きた
ノウハウです。プロジェクトマネジメントの学び、理解する上で、
それを使わない手はありません。プロジェクトマネジメントの
教育カリキュラムを制定する際、またはプロジェクトマネジメント
を強化するための具体的手段を考える際には、PMBOKの体系を意識
してみてください。
自分たちの組織に活かそうという目的であれば、基本を理解して
実行できれば、十分に活用できますので、市販の本で読みやすそう
な解説書を買って読んだ方が分かりやすいと思います。
謝辞：
PMBOKの説明など、多くの企業やサイトがあります。言葉や文章で、
類似もしくは同等になってしまいますが、営利目的ではありません
のでご了承ください。
受注残 客先との契約が完了し納品物および納品日、金額が確定している状態。
受注残では、納品物の着手計画段階として受託金額（売り上げ金額）
とリソース稼動バランス管理が主体となる。
受注残の案件を進めていく中で、手配品等の発注処理が含まれる。
この発注処理が、受注残の中で発注済み（執行金額）と発注残
（未執行金額）として分類される。
発注残により、受注残の予実管理が、リアルタイムで可視化出来る
ことが、受注事業の受託金管理に繋がる。
受注残の管理は、受注前段階の情報整理から始まる。
営業情報のインプットにより、確度が数十パーセントの案件で
あっても、アプローチや商談のフォロー、もしくは、要件の見極
めなどの深堀を進めるためシステムに熟知した技術者同行で対応
する行動計画が「可視化できるメリット」もある。
それぞれの商談から案件に繋げていく段階が注残のインプット
となる。
客先商談（訪問活動）→商談（仮説課題/解決等の提案）→客先の真の課題
の探求
→商談（案件としても見極め）→営業情報（組織化活動へシフト）
→案件の深堀→精度向上・・・・・・
↓
見積など具体的な要求に基づくアクション
↓
受注活動による成果
↓
受注/内示等に繋げる
↓
営業情報が注残基礎データにアップデートされる。
実活動者が、営業情報から日記感覚でアップデートしていくことが第一目標
になる。
日々の積み重ねの証として、また、商談の情報を係わる連携組織に伝える
手段として、受注事業の基礎情報になる重要な基点です。
一般的な工程（詳細ではない）で対比させると、その差が歴然として見えてくる。この違をシステム受注としての原価に取り込むことが事業を円滑にする否決でもある。
あるお客さんより、
こんなことも、あんなことも、したい。
と商談で話してくれた。
自社が持ち合わせている商材（機材や技術）では、機能の追加が必要。扱えるノード数（スピーカ数）も増やさなければならない。
新規開発で商品を作る要望を、量産設計部門に受注検討会議などを経由して答申した。
この内容は、システム事業としては、当たり前の思考か、異常な思考か？
答えは、「異常な思考」です。
これを繰り返していたらシステム事業はキャッシュフローが回らなくなる。
市場調査より、量産商品として多売できる製品開発であればまだしも、特定顧客の要望で、量産組織を動かくことは、開発費（設計工数がほとんど）の回収は、この1案件では回収しきれなくなる。
となると、複数案件が入る想定で原価見積りをする。
これも受注業界では、「取らぬ狸の皮算用」になり、遣ってはいけない事です。
類似的な開発要素の注残が多数あれば、確実な納入として開発費の按分も可能となりますが、注残がなければ、回収見込みのない開発費の先送りになるだけです。
顧客が開発費として出す契約であれば、問題ないですが・・・・・・
そこまで太っ腹の顧客も少ないのが現実。
量産製品事業の常識が、システム受注事業の常識にはならないという事です。
上記の回避策は、
実現できる構成要素を考える。
構成要素を考えるうえで、他社の機材やアプリケーションなどを調べることです。
そして、
調べる時には、一つ見つかったから「これでいいや」とせず、
２，３の手段を見つけておくことです。
（詳細設計時に適合できない場合の代替策のためです）
世の中に存在するもので顧客の課題を解決できるシステム事業が、レスポンスを高め、顧客の必要要件に叶った、顧客予算に入る納品システムになる。と思います。
他社の機材を使ったシステムであっても、
自社が納入した物件であれば、弊社が責任を持って対応できる様にする事、そして、
問い合わせで即答できる様にします。
→資産（納品仕様書/完成図書等）を宝物として再利用していくことです。