 |
|
|
| 1 2 3 次のページ
|
|
| IT業界で調達管理が重要な理由
|
本連載も今回で最終回となりました。これまでPYMBOKにおける9つの管理エリアに沿ったポイントと、「PYRAMID」の管理ツールを紹介してきましたが、最後はProcurement（調達管理）です。
システム開発の仕事は、建設業界と同じように人的リソースが変動します。あるプロジェクトが発足すると、それを遂行するためのプロジェクトメンバーが集められ、それが完了すると、保守要員だけを残して解散します。ピーク時に必要となる開発者を常時抱えているのはコスト高となります。また、プロジェクトによって必要となるスキルも異なるので、頭数だけそろえれば良いというものでもありません。
大きなプロジェクトでは、人数的にも技術的にもメンバーが不足しやすいので、不足分の要員を外部から調達することになります。外部企業も、自社に十分なリソースがなければ、さらに別の企業からリソースを調達します。かくして、建設業界と同じように「元請け - 下請け - 孫請け」というような請負形態となり、図1のようなピラミッド構造となるのです。
|
図1：システム開発における請負形態
|
ここで誤解してはいけないのは、この階層構造自体を否定することは意味がないということです。「この業界は2次請け、3次請けで…」などと自虐的に言う人もいますが、システム開発がプロジェクトによって人的リソースが変動する以上、必要に応じて要員を外部調達するということは当たり前です。現代企業はコストに強くなければならないので、大きな要員を常時抱えている方がよほど不健全と言えるのです。
そこで重要となるのが、外部からの人的リソースの調達です。プロジェクトに必要なスキルを持った技術者を、ベストのタイミングで調達できるのかが、プロジェクト成功の鍵となります。企業と企業の取引になりますので、契約面で齟齬のないようにするのはもちろんですが、その前提となる相互信頼や情報共有といった無形部分も重要です。プロジェクト管理面から、どのような点に気をつければ良いのか、どういう手順で何をしなければならないのかを考えてみましょう。
|
| 調達管理
|
表1はPMBOKにおける調達管理のプロセス一覧です。PMBOKの調達管理は、「調達計画」「引合計画」という2つの計画プロセス、「引合」「発注先選定」「契約管理」という3つの実行プロセス、「契約完了」という終結プロセスから構成されています。
|
| 管理エリア |
プロセス |
入力 |
ツールと実践技法 |
出力 |
Procurement
（調達管理） |
調達計画
（計画） |
スコープ記述書
プロジェクト成果物記述書
調達関連リソース
市場状況
他プロセスからの計画資料
制約条件
仮定条件 |
内製対外部調達の得失
分析
識者の判断
契約形態の選択 |
調達マネジメント計画書
役務記述書 |
引合計画
（計画） |
調達マネジメント計画書
役務記述書
他プロセスからの計画資料 |
標準様式
識者の判断 |
調達書類
プロポーザル評価基準
役務記述書更新版 |
引合
（実行） |
調達書類
予定入札者一覧表 |
入札説明会
入札広告 |
プロポーザル |
発注先選定
（実行） |
プロポーザル
プロポーザル評価基準
発注方針 |
発注折衝
評価の定量化
ふるい落とし基準
査定見積 |
発注（請負）契約 |
契約管理
（実行） |
契約
作業結果
変更要求書
納入者の請求書 |
契約変更管理システム
進捗報告
支払いシステム |
コレスポンデス
契約変更
納入者の支払い請求 |
契約完了
（終結） |
契約文書 |
調達管理 |
契約ファイル
検収と契約完了 |
|
表1：PMBOKのProcurement Managementの6つのプロセス
|
1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
