iTEC HOME

メニュー

Menu

アイテックオンライン学習へようこそ!

さあ、さっそく学習を始めましょう!

アイテックID
パスワード

BACK

お電話でのお問い合わせ

03-6824-9001

土日祝日を除く 10:00〜17:00

BACK
CLOSE

【プロジェクトを成功させるために必要な注意事項とは?】

 大手のITベンダA社は、大手製造業P社の基幹システムを、RFP(Request For Proposal)作成の段階から準委任で契約して参画し、基本設計から委託契約で見事受注しました。
基本設計・詳細設計を終え、プログラム設計・製造部分の一部を外製で行う方針を取りました。

 発注は、PMBOKを参考にして、技術力・会社規模などの基準は満たし、A社との取引も十分なS社に決定しました。

1.S社に発注する分の見積り

 Javaを使用して作成するプログラムのA社の見積りは、ファンクションポイント法(以下FP法)を使用しており、過去の実績値も把握しています。

 過去の実績値は、100FP当たり3.94人月(1人月当たり25.38FP)でかなりの精度を誇っています。S社に発注する分は、634FPであるため、25人月の仕事として発注した。それを2.5ヶ月で行うため、10名ずつの稼働でできると考えて発注しました。

2.進捗報告会の報告方法

 進捗の報告については、細かくこの作業が終わったら30%、この作業が終わったら50%といった取り決めをしていなかったのです。ですので、S社は、「プログラム設計・製造」工程を「プログラム設計」「実装」「単体テスト」の3つの工程に分解して、それぞれ、50%、30%、20%という割合にしていました。しかも、「内部レビュー」「外部レビュー」の重みをつけていないため、「プログラム設計」の作成途中でも高い進捗率になり、レビューに入った時点で進捗が滞る事態が発生しました。それでも、報告の貯金があったため、無事に「プログラム設計」工程は、終わったように見えました。

 「実装」工程を終えた時に、S社は、80%終えたつもりになっていましたが、実はちょうど50%を終えたところでした。進捗「単体試験」工程を甘く見ていたのです。(下表参照)

週(進捗報告) 把握進捗 報告進捗 実進捗
1 14% 10% 7%
2 28% 20% 14%
3 42% 30% 21%
4 52% 40% 27%
5 59% 50% 32%
6 66% 60% 38%
7 73% 70% 44%
8 80% 80% 50%
9 把握できず 80% 60%
10 把握できず 80% 70%

3.A社とS社の取引実績について

PMBOKに発注先選定基準が記述されているので、S社を◎○△×の4段階のマークで評価してみると、以下のような結果となりました。△が2つあるものの、×がなく優良な発注先と思えました。

  • ニーズの理解:○
  • 全体コストまたはライフサイクル・コスト:○
  • 技術力:◎
  • リスク:○
  • マネジメントの取組み:○
  • 技術的な取組み:○
  • 保証:△
  • 生産能力と意欲:○
  • ビジネスの規模とタイプ:△
  • 納入者の過去の実績:○
  • 知的財産権:A社(○)
  • 所有権:P社(○)1.プロジェクトの目的または正当性

 S社はA社との取引は初めてではないのですが、マネジャのK氏は初めてでした。そこで、S社と取引経験のあるM氏N氏に意見を聞いたところ、S社は、金融系が得意で、しかも、S社のY氏がプロジェクトに参画して、Y氏のリーダーシップでうまくいっていたとのことで、他のマネジャの実績はなく、未知数だということが判明しました。

4.PMBOKでの教え

 調達コントロールにおいて、調達パフォーマンス・レビュー、パフォーマンス報告の重要性を説いています。週1回の進捗報告会の開催は、当然やるべきで正解です。しかし、進捗率を把握する尺度が異なっていたため、進捗を報告する側と受ける側とでギャップが生じていました。

 PMBOKは幅広い知識体系ですので、プログラム設計・製造工程において、事細かく進捗管理について定義していないですが、WBSに分けなさいとあります。

 S社のY氏は、A社との取引実績もあり、WBSの分け方や進捗度合いの把握方法のルールを熟知していましたが、K氏は初めてで分からなかったので、勝手に進捗の基準を決めてしまって報告していたことが、認識のずれの要因でした。K氏が、S社との取引経験がないことが判明した時点で、プログラム設計・製造工程を細分化して、「××のタスクが終わったら○%終わったことにする。」と取決めをしておけば、今回のような工程の終わり間近で、進捗率が80%から動かないといったことは起こらなかったと思います。

 次の表は、プログラム設計・製造工程を細分化して、進捗の把握方法を細かく取り決めた事例ですが、このくらい細かく認識合わせをしていくことが大切です。

工程 進捗率 重み
プログラム設計 完了ページ数/予想ページ数 25
内部レビュー 未着手:0%
指摘項目10項目以上:30%
指摘項目10項目未満:60%
完:100%
5
外部レビュー 未着手:0%
指摘項目10項目以上:30%
指摘項目10項目未満:60%
完:100%
5
実装 完了ステップ数/予想ステップ数 15
単体試験仕様 試験項目数/予想試験項目数 15
試験仕様レビュー 未着手:0%
指摘項目10項目以上:30%
指摘項目10項目未満:60%
完:100%
5
コードインスペクション
(ツール使用)
未着手:0%
指摘項目10項目以上:30%
指摘項目10項目未満:60%
完:100%
5
試験環境 ドライバ・スタブ作成:30%
単体試験データ作成:70%
どちらも完了:100%
10
単体試験 実施試験項目数/試験項目数 15

 発注する側も進捗報告をそのまま信用しないで、実際に成果物を見せてもらうことも必要です。特に、初めての委託業者や初めての委託先マネジャであった場合は、なおさらで、これはリスクとして管理するべき項目でもあります。

 今回は、リスク・マネジメントについては、述べておりませんが、取引実績のない業者やマネジャは、リスクとして管理し、そのパフォーマンスを細かくチェックしてくことが必要になってきます。

【25PDU取得可能!!】プロジェクトマネージャに必要なITプロジェクトの立ち上げから終結までの一連のプロセスをどのようにマネジメントしていくか学習するのにオススメコース!!

【10PDU取得可能!!】プロジェクト推進に必要なリーダーシップを発揮するためのスキルを学ぶのにオススメコース!!

【10PDU取得可能!!】プロジェクトマネージャがプロジェクト分析及び評価結果などの情報をいかに効率的に活用し,戦略の策定・見直しを行っていくか、戦略的マネジメントスキルを高めるのにオススメコース!!

執筆者『多賀 康之(たが やすゆき)氏』プロフィール

【豊富なシステム開発の実務経験と、人材育成のノウハウで、君のやる気を引き出す!】
・独立系ソフトウェアベンダにてシステム開発、プロジェクトマネジャを経て、技術者・営業員の育成に従事。2011年に独立し、現在は、講師業、コンサルティング業に従事。
・保有資格は、特種情報処理技術者試験、ITコーディネータ、スキル標準ユーザーズ協会ITSS導入推進者認定、実践リスク・マネジメント研究会 リスク管理者認定、他多数。
多賀 康之

パスワードをお忘れの方

ご登録のアイテックIDを送信してください

アイテックIDを入力してください。

メールを送信しました。

ご登録のメールアドレスに
メールを送信しました。

2015年10月1日以前に
ECサイトに会員登録された方

ECサイトに登録していたメールアドレスを入力してください

ECサイトに登録していたメールアドレス

確認完了

登録完了しました。

メール送信完了

登録いただいたメールアドレスに招待用リンクをお送りしました