6-1 プロジェクト完了後の評価
611 評価指標の概要作成
612 評価指標の必要に応じた追加更新
613 プロジェクト計画に関する評価
614 実行過程・管理方式に関する評価
615 開発されたシステムに対する評価
616 要員・チームが得た成果の評価
617 以後の参考となる事項の文書化
6-2 実績情報の収集、整理、分析、データベース化
621 数値データのアクセス容易な保存
622 数値データの目的別の分類整理
623 データによる計画実績の差異分析
624 分析結果としての教訓のＤＢ化
625 分析情報が参考値として利用可能
626 評価基準の妥当性の評価
コメント：
無事に納品、検収も終わり、メンバーたちに開放感が広がる。あとはサービス開始を待つだけと思いきや、プロマネにはまだやるべきことが残っている。プロジェクトの評価である。これまでまともな評価をしたことがあったかどうか。この機会に考えてみたい。
Pman注目： 625 分析情報が参考値として利用可能 スキル基準には「数値データの分析により得られた情報は、以後のプロジェクトでの、参考値などとして容易に利用可能であること」と書かれている。評価や分析した結果は、今後のプロジェクトで有効に活用することを前提に、よく整理しておく必要がある。さらに、プロジェクト管理業務に携わるすべての人が参照しやすいデータベース等の整備と、データ登録を推進するための業務プロセスが望まれる。
あとがき：
一ヶ月近くにわたり「情報システム開発プロジェクトマネジメントプロセス」の中のスキル基準を取り上げてみた。振り返ってみると、辛かったが、体系的な知識の整理ができ、これからの土台作りとしては有効な勉強だったと思う。個々のタスクについては、15文字以内という条件で、私の独断でまとめている。15文字を超えると、キーワードとしては長くなってしまうので、こういうスタイルになった。ただし、箇条書きではスキル標準の趣旨が十分に見えてこないので、詳しく勉強したい方は、試験センターＨＰからスキル標準をダウンロードして読んでほしい。
秋の受験受付は明日8/23まで。お忘れなく！
5-1 プロジェクト終了状況の確認
511 プロジェクトの目的・目標の達成
512 計画書に記述された成果物の存在
513 成果物が要求仕様を満足する
514 プロジェクト完了基準を満たす
515 推進組織の全チームの作業完了
516 残項目を除く全問題点の解決
517 承認された変更要求の実施
5-2 プロジェクト完了報告書の作成
521 実行要約の明確かつ完全な文書化
522 計画と完了時の差異原因の文書化
523 実施された変更の効果の文書化
524 残項目が明確である
525 残項目が引き継げる状態にある
5-3 ユーザによる成果物検収に対する対応
531 ユーザ検収条件を満たす
532 全成果物の検収・承認
533 利用者・製品管理者への引き渡し
5-4 プロジェクト完了報告と終結
541 評価関係者への完了状況の報告
542 評価関係者による完了の承認
543 評価関係者への終結の通知
544 有効な情報が共有情報として追加
コメント：
ソフトウェアというのは、一般的な工業製品などと異なり、エンドユーザーの目に見えないものである。見えるのは画面や帳票といった入出力部分だけであり、処理機能そのものは通常ブラックボックスになっている。しかし、利用者の目に見えないから設計書は多少の不備があってもいい、ということにはならない。むしろ見えないからこそ可視化、すなわち見えるようにすべきだろう。どのような設計内容に対しどのようなレビューを行い、どのような手法でどのようなテストを行い、どのように品質を保証したのか。それらがわかる成果物を納品することが、プロジェクト終結の必須条件と言える。
Pman注目： 512 計画書に記述された成果物の存在 スキル基準には「プロジェクト計画書に記述されたすべての成果物が存在すること」と書かれている。ただし、計画書に記述するのは、例えば、詳細設計書、ソースプログラム、テスト項目表など成果物の種類だけであり、それぞれの種類について、機能単位あるいはモジュール単位の成果物がなくてはならない。私は以前、あるプロジェクトの結合テスト工程が終わりに近づき、成果物の確認をしたところ、１機能におけるテスト成果物が見つからず、青ざめたことがあった。信じられないことだが、進捗表から漏れていたため、テストされていなかったのである。幸いにして、空き要員を割り当てて集中的にテストできたため事なきを得たが、思わぬところに落とし穴があるものだ。
スキル基準の解説も、次回でいよいよ最終回となる。長かった・・。
次回予定→ ６．プロジェクト完了評価
4-1 変更要求の把握
411 全要求の保存・データベース化
412 標準形態に準じた変更要求仕様書
413 要求に関連する付帯的情報の収集
4-2 変更内容の分析と評価
421 全要求の分析と対応方針の決定
422 分析評価への適切な技術者の参加
423 変更による影響の推定
424 判断不可能な要求への判断の委譲
4-3 変更の承認
431 変更必要性の上位管理者への報告
432 要求の採択・棄却・保留の決定
433 重要な変更へのより綿密な分析
434 採択された変更要求の適切な実施
4-4 変更の実施
441 変更実施の関係者への周知
442 変更実施過程の注意深い観測
443 変更内容の適切かつ完全な文書化
444 変更過程・変更後の変化の報告
コメント：
業務仕様が固まったら完全に仕様を凍結し、そのあと変更はゼロというのが理想であるが、実際には、多かれ少なかれ何らかの変更がのちに発生すると思ったほうがいい。ただし、何でもかんでもユーザからの要求を受け入れるのではなく、仕様変更の必要性、つまり変更によってどのような効果があるのか、あるいは変更しなければどのような不都合があるのかを、よく吟味する必要がある。そして、仕様変更によるリスクを洗い出し、慎重に対応しなければならない。開発の後半、特にテスト工程において仕様変更せざるを得ないというケースもある。テストをやってみて初めてわかった仕様上の不備というものだ。この場合、変更は必要な部分だけについて、最小限の対処に抑えるべきだろう。よく知っている技術者ほど、ついでと言ってはあちらこちらのプログラムに手を入れようとするが、これは非常に危険だ。プロマネは、こうした危険な匂いを嗅ぎ分け、変更によってかえって品質を落とすことのないよう、しっかりと管理する必要がある。
Pman注目： 432 要求の採択・棄却・保留の決定 スキル基準には「変更要求は、評価関係者により基準に照らして評価され、採択・棄却・保留が決定されていること」と書かれている。ここで私が気になったのは「保留」である。特別な理由もなく、白黒どちらとも決められないから取りあえず保留にしておくというのが気になるのだ。保留にすると、当面はその変更について考えなくてよいのでラクに思えるが、その間もプロジェクトは進んでいるので、保留時間が長くなるほどあとの変更実施による作業負荷が増えることになる。あるいは、保留にしていたが結果的には棄却したとしても、それでユーザが困らないことを確認または立証しておく必要があろう。
次回予定→ ５．プロジェクト終結
3-B 品質管理
3B1 適切な品質管理手順の実施
3B2 品質目標を達成している成果物
3B3 品質確認へのユーザの参加
3B4 品質未達時の対応策
3B5 品質保証計画の変更・承認
3B6 計画変更に伴う改善状況の確認
3B7 システム構成品目の管理
3-C リスク管理
3C1 リスク管理要素への監視・追跡
3C2 予定された全リスク予防策の実施
3C3 リスク発生に伴う不測事態対応
3C4 復旧状態の確認とその過程の評価
3C5 リスク発生に伴う全事項の文書化
3C6 新たなリスクへの予防策の追加
3C7 評価関係者に対する報告
コメント：
プロジェクトも佳境にはいり、このペースでいけば何とか納期は守れそう、費用も計画内に収まりそうという状況であっても、品質に関してはまだ改善の余地が残っていることが案外多い。いくら明確な品質基準があり、一定の水準をクリアしたシステムであっても、ある日突然、様相が変わってしまう場合がある。例えば、バグ修正が不十分のためデグレードを起こしたり、ユーザによる確認テストで操作性が悪いと指摘があったり、パッケージソフトのバージョンアップによる影響が出てくるなど、いろいろなことが考えられる。こうしたことに対し、場当たり的に対策を講じるのではなく、あらかじめリスクとして識別しその予防策を施すことが品質保証につながると考えられる。
Pman注目： 3B3 品質確認へのユーザの参加 スキル基準には「必要に応じてユーザが品質の確認に参加していること」と書かれている。たとえ新技術を駆使して構築した立派なシステムであっても、ユーザにとって利用価値のあるシステムでなければ意味がない。開発者と利用者の両方の観点から、品質を評価しなければならない。ユーザが真に求める品質とは何かを、的確に把握する必要があるだろう。スキル基準では「必要に応じて・・」としているが、私としては「可能な限り・・」と言いたい。
次回予定→ ４．変更管理
3-7 資源管理
371 資源が計画通りの投入配置・活用
372 資源が必要時期の必要量利用可能
373 資源の無駄ない最適利用
374 資源の過不足への対応策の実施
375 資源変更の計画と承認後の実施
3-8 組織要員管理
381 条件を満たす要員の要所への配置
382 推進組織による役割・責任の遂行
383 方針にそった運営・活動の維持
384 組織パフォーマンスの改善・向上
385 積極的かつ連帯感をもつ任務遂行
386 力量不足の技術に対する追加訓練
387 意思決定への適切な要員の参加
3-9 調達管理
391 最適な外部委託先の選定
392 交渉段階で計画に適合する協議
393 受託企業に管理能力のある責任者
394 受託企業メンバは他チームと融和
395 調達要求仕様が計画通りの実行
396 十分な情報交換
397 受託企業からの解決策提案の実施
398 契約外作業の契約変更の計画実施
399 情報の漏洩がない
3-A 費用管理
3A1 全体計画通りの支払いの実施
3A2 費用超過への対応策
3A3 費用変更の計画・承認・実施
コメント：
近年、プロジェクトマネージャ試験の午後１あるいは午後２で、海外への委託に関する出題があった。人件費などのコスト面で有利な場合が多く、私自身はオフショア開発の経験がないものの、社内では既に幾つかの実例があるのを知っている。スキル標準をよく読むと、海外調達に関する知識という項目があり、取引に関する法律とともに基本的な知識は習得しておきたいところだ。また、調達といえば、契約に関する知識が不可欠であり「知らなかった」では済まないケースも出てくるだろう。国内・国外を問わず、幾つかの会社や組織によって開発を行うことが前提となる以上、考え方の相違や担当者間の摩擦が生じることもある。そこをうまく調整し、プロジェクト全体を統括、指揮していくことがプロマネの責務であろう。
Pman注目： 385 積極的かつ連帯感をもつ任務遂行 スキル基準には「プロジェクト要員は積極的かつ連帯感をもって任務を遂行していること」と書かれている。一人でやる仕事はプロジェクトとは呼ばず、複数の人間が共同して行うのがプロジェクトである、と何かの本で読んだ記憶がある。共同作業である以上、人と人との間に生まれるものがコミュニケーションである。インターネットも電子メールも無い時代には、皆がお互いに声を掛け合いながら仕事した。あるいは客先へ訪問し、顔を合わせて話をしたものだ。これに対して最近は、メールでのやりとりが一般化し、相手と活字の交換をするだけでコミュニケーションが成立する、という風潮さえあるように感じる。しかし、活字では伝わらない情報が沢山あるはずで、例えばチーム内でミーティングをする、関係メンバーだけで集まり検討する、インフォーマルな場で相手の本音を聞くなど、いろいろなことを意外にやっているものだ。連帯感があってこそ、プロジェクトは機能する。
次回予定→ ３．プロジェクト追跡と実行管理 つづき
3-4 工程完了評価
341 完了条件項目によるレビュー実施
342 適切な代表者のレビュー参加
343 レビュー・評価のための情報収集
344 効率性・技術水準・体制等の評価
345 改善事項が以降の工程で有効活用
346 レビュー・評価結果の文書化
3-5 プロジェクト状況報告
351 企業の標準形態に準じた状況報告
352 計画に対する進行状況の評価
353 成果物・推進過程・活動等の報告
354 改善策が次工程以降の計画に反映
355 重要な問題点への対応結果の報告
356 変更管理の実施状況・効果の報告
3-6 進捗管理
361 全体が計画通りの推移・成果
362 各タスクが計画通りの実行・成果
363 進捗遅延に対する対策の実施
364 遅延時の変更計画と承認後の実施
コメント：
開発プロジェクトは工程（フェーズ）単位で段階的に進行していくのが普通で、それを前提として上記のような達成指標が設定される。ある工程が完了したらすぐ次へ移るのではなく、振り返り、きちんと評価してから先に進むべきだろう。いわゆるウォーターフォール型の開発手法に限らず、スパイラル型のように何度か繰り返して開発を行うような場合でも、作業の節目における評価は欠かせない。プロマネは工程完了報告書の作成において、ややもすると、問題ないことの理由付けに苦慮するが、問題があるのならしっかりとその本質を見据えたうえで改善策を明示する必要がある。
Pman注目： 345 改善事項が以降の工程で有効活用 スキル基準には「工程内で認識された改善事項が、以降の工程で有効活用されていること」と書かれている。つまり、改善したこと（今後も改善すべきこと）は、次の工程に引き継がれなければならない。よくあるのは、改善効果がやがて薄れていくという現象だ。せっかく素晴らしいマニュアルを作ったのに使う人がいない、作業フローを作ったのに新たなチームに馴染まないなど、改善策が有効に働かない場合がある。こうしたことは、工程の境目に限らず、もっと詳細なタスクレベルで監視し、有効性を見極めていくことが大切だと思う。
次回予定→ ３．プロジェクト追跡と実行管理 つづき
3-1 プロジェクト実行管理
311 計画通りの推移・コントロール
312 予実差異に対する是正策の実施
313 発生問題の吟味と対応策の実施
314 リスク予防策の実施効果の確認
315 目標達成状況の確認
316 新たな識別リスクへの対応計画
317 計画変更の実施による効果の追跡
318 過剰管理要素の除去
319 実行管理状況の正確な報告
3-2 プロジェクト監視と追跡
321 管理要素の監視・追跡方法が明確
322 監視・追跡の頻度の明示
323 必要時期に手順通りの監視・追跡
324 異常な進行・予兆の発見と分析
325 リスク予防策の実施状況の監視
3-3 問題管理
331 全問題点の識別・分析・文書化
332 標準形態に準じた問題点の起案
333 問題に関連する適切な情報の収集
334 問題の重要性の識別・影響の推定
335 大きな問題は変更管理の対象
336 必要対策の計画・実施による解決
337 類似する問題の潜在性の検証
338 全問題点の解決の過程が文書化
339 チーム内と評価関係者への報告
コメント：
きょうからプロジェクトの運営・実施にはいる。基本的には出来上がったプロジェクト計画書に沿って進めていくべきであるが、いくら立派で完璧な計画書を作ったとしても、実行しなければ意味がない。ここで大切なことは、初めに（重要なところを中心に）プロジェクト計画書の内容をプロジェクトメンバー全員に周知し、一人一人に理解してもらうことだろう。なぜなら、プロジェクトは、プロマネだけでなくメンバー全員が意識を共有し、目標に向かい一致団結して実行すべきものだからである。個々のメンバーがばらばらに動いたり、全体がおかしな方向に向かっていくことのないよう、プロマネは常に監視（モニタリング）を怠らず、一つ一つの問題点を確実に解決していく努力と工夫が必要である。
Pman注目： 313 発生問題の吟味と対応策の実施 スキル基準には「発生したすべての問題は吟味され、必要に応じて対応策が実施されていること」と書かれている。3-3問題管理というタスクが存在しているにもかかわらず、ここで問題についての指標があるのは、少し不思議な気がした。けれどもよく考えてみると、問題として挙げたことは、本当に問題なのかどうかさえはっきりしない場合もあり、初めによく吟味する必要があると思う。すぐに対応することがいつも正しいとは限らない。もっと優先して対応すべき問題が残っていれば先送りにしたり、他の問題と同時に解決したほうが効率的であったり、また、ケースによっては「何も対応しない」ことが最善の道だったりすることもある。いろいろな道から近づいてくる問題点の交通整理をするのが、プロジェクトマネージャの任務ではなかろうか。
次回予定→ ３．プロジェクト追跡と実行管理 つづき
2-9 品質保証計画
291 企業の品質方針の確立
292 品質特性・品質項目の明示
293 採用した品質標準が機能している
294 文書作成基準の確立
295 品質保証手順が適切かつ完全
296 システム構成管理手順が適切
297 品質レビューの進め方が規定
298 品質リスクの文書化
299 品質保証計画の文書化・レビュー
29A 評価関係者からの承認
2-A リスク管理計画
2A1 全リスクの識別・影響の評価
2A2 詳細タスクへの予防策の組み込み
2A3 不測事態対応計画の計画
2A4 リスク監視追跡のための管理表
2A5 管理計画の文書化・レビュー
2A6 評価関係者からの承認
2-B プロジェクト計画書作成
2B1 目標・成果物・推進体制が明確
2B2 成果が及ぼす影響が明確
2B3 実行に際しての前提・制約が明確
2B4 管理目標としての基準値が適切
2B5 状況報告の方法・承認ルール
2B6 問題発生時の対応策の承認ルール
2B7 スコープ決定時の課題への解決策
2B8 監視・追跡・管理方針の明示
2B9 各工程完了を確認する条件の確定
2BA パフォーマンス計測の項目・方法
2BB ユーザによる成果物の検収条件
2BC 完了後評価指標の概要
2BD 計画の文書化・レビュー
2BE 評価関係者からの承認
コメント：
ＱＣＤ−すなわち品質・費用・納期の３つが、プロジェクトにおいて柱となる管理項目となる。特に品質は、システム利用者が業務を円滑に効率良く行うためにもっとも重視すべき要素であろう。ところで、スキル基準によれば、2-4〜2-10までのタスクは並行的に進めるもので、各計画は相互に整合性を保つものとしている。つまり、2-3までのタスクで開発方針やスコープの設定をしたあとは、スケジュール、資源、組織要員、調達、費用、品質保証、リスク管理の７つの計画を策定し、最後にこれらの計画を盛り込んだプロジェクト計画書を正式にまとめる作業となる。リスク管理は６タスクで少ない感じがするけれども、各計画のタスクの中に必ず「リスク」という言葉が出てくることから、じつは非常に重要な位置付けにあるものと読み取れる。
Pman注目： 2B4 管理目標としての基準値が適切 スキル基準には「各種管理目標としての基準値が適切かつ完全に定義されていること」と書かれている。例えば、品質目標の場合、レビュー指摘件数やバグ発見数などの目標値がプロジェクト計画書に記載されている必要がある。ところが、あればいいと言うものではなく、プロジェクトにとってその目標値が妥当なものでなければならない。品質基準では、一般的にソフトウェアの規模（プログラムステップ数）をもとに算出したりするが、過去の類似プロジェクトにおける実績を参考にしたほうが適切な基準値になることもある。さらに、リスク要因などを加味したうえで、品質だけでなくコストなどに関する基準もしっかりと定義しておくことが肝要だろう。
次回予定→ ３．プロジェクト追跡と実行管理
2-6 組織要員計画
261 組織の役割・責任が明確に定義
262 組織の運営・維持の方針が明確
263 適正な規模のチーム分割
264 適材適所の要員配置
265 タスク毎のクリティカルなスキル
266 代替案の検討
267 組織編成リスク等の文書化
268 組織要員計画の文書化・レビュー
269 評価関係者からの承認
2-7 調達計画
271 外部調達の必要性が明確
272 ベンダ企業の現状が調査
273 調達先に要求すべき特質等が明確
274 調達仕様の正確かつ完全な定義
275 プロジェクトに適合した調達形態
276 調達リスクの文書化
277 調達計画の文書化・レビュー
278 評価関係者からの承認
2-8 費用計画
281 費用の必要性が明確
282 金額・出費の時期の明示
283 プロジェクトの初期費用の明示
284 費用リスクの文書化
285 費用計画の文書化・レビュー
286 評価関係者からの承認
コメント：
このあたりは資源計画などと並んで、プロジェクトマネージャならではの項目という印象を受ける。チームリーダー以上の経験をもつ人であれば、プロジェクトメンバーすなわち要員との関わり合いは不可避であるし、要員計画の大切さがよくわかるはずだ。そしてプロマネになると、さらに社外からのメンバー調達や原価算出なども含めた費用管理を行う点で、リーダーとはまた違った視点が必要になる。費用計画は、じつは組織要員計画や調達計画と密接な結びつきがあるように思う。なぜなら、システム開発にとって「ヒト」はもっとも重要でかつ、人件費という莫大な費用がかかる資源だからである。企業の利益をいかにして生み出すかという経営的な観点から、私は、プロマネの役割と責任は重大なものであることを改めて認識した。
Pman注目： 264 適材適所の要員配置 スキル基準には「知識・スキル・経験・生産性・志向・性格などを考慮し、プロジェクトの特徴に適合する適材適所の要員配置がなされていること」と書かれている。メンバーのうち誰をどこの業務に割り当てるか考える作業は、おもしろいと言ったら語弊があるけれども、まさにリーダー冥利に尽きると言える。うまく配置できたときは、まだ開発が始まらないうちから成功したような気分になるし、逆に不安を残す配置となった場合は、その不安をリスク要因の一つとして対策を考えることになる。メンバー全員が各々持っている能力を十分に発揮できるような、パフォーマンスに優れたプロジェクト体制を築き上げることが大切だろう。
次回予定→ ２．プロジェクト計画策定 つづき
2-4 スケジュール計画
241 適切な規模の詳細レベルタスク
242 成果物の完了・評価会議の時期
243 タスク間の依存関係・実施順序
244 企業の見積り基準に照らして妥当
245 リードタイム・ラグタイムの見積
246 プロジェクト管理対応等の見積
247 クリティカルパスが作業期間内
248 可能な範囲のスケジュール短縮
249 代替案の検討
24A スケジュールリスクの文書化
24B スケジュールの文書化・レビュー
24C 評価関係者からの承認
2-5 資源計画
251 主要な資源の利用根拠が明確
252 資源の投入・調達量・時期が正確
253 調達先に対する調査・分析・評価
254 代替案の検討
255 資源投資リスクの文書化
256 資源計画の文書化・レビュー
257 評価関係者からの承認
コメント：
スコープを定義したら、次はいよいよスケジュール作成にはいる。プロマネと言えば作業線表と常ににらめっこしては頭を抱えて悩んでいる姿を想像するかもしれない。何度もスケジュールを引き直し、しまいには、どうやっても終わらん、と嘆く。挙句の果てに、上流工程でがんばって設計すれば下流工程は何とかなるだろうからテストを少し削ろうとか、線を三本も四本も並べて一緒にできるだろうなどと安易な計画をする。これではプロマネの任務を十分果たしていると言い難い。ヒト、カネ、モノなどの資源をきちんと押さえつつ、効率的かつ実現可能なスケジュールを立案することが重要だろう。
Pman注目： 248 可能な範囲のスケジュール短縮 スキル基準には「論理的および物理的に可能な範囲で、スケジュール短縮が図られていること」と書かれている。つまり、無駄に時間を使わないで、終われる作業から早く終わらせる工夫が肝要だと言える。ここがプロマネの腕の見せどころ。特にWebシステムのような開発では短納期が原則になってきているので、実務上は非常に役に立つ（場合によっては必須の）スキルだと私は思う。
次回予定→ ２．プロジェクト計画策定 つづき
2-1 スコープ計画
211 企業目的への貢献内容が明確
212 顧客／ユーザの満足度基準が明確
213 推進組織の役割・任務が明確
214 プロジェクト情報の範囲が明確
215 前提事項・制約事項が明確
216 解決すべき課題が明確
217 代替案の検討
218 スコープ管理方針の明示
219 スコープ計画の文書化・レビュー
21A 評価関係者からの承認
2-2 システム開発方針の設定
221 ライフサイクルモデルの選定
222 モデル選定時の専門技術者の参加
223 特性に適合した開発技法の選定
224 代替案の検討
225 特性に適合した開発標準の選定
226 評価関係者からの承認
2-3 スコープ定義
231 概要レベルタスクへの分解
232 各概要レベルタスクの明確な定義
233 スコープ定義の文書化・レビュー
234 評価関係者からの承認
コメント：
プロジェクト計画のはじめに、開発の対象範囲を明らかにしたり、開発手法や方針の大枠を決めたりする。この段階では、概要レベルとはいうものの、プロジェクトにかかわる関係者の間で、ここまでが任務の範囲だという線引きをはっきりしておかないと、あとで大変な問題に発展する可能性がある。スコープが曖昧なままスタートしたプロジェクトは、その時点でもう高いリスクを背負ったと思ったほうがいいだろう。
Pman注目： 214 プロジェクト情報の範囲が明確 スキル基準には「プロジェクト情報（成果物、費用、期間、品質、利用者、規模、機能、技術リスクなど）が正確かつ完全に定義され、範囲が明確であること」と書かれている。ただし、これだけの情報を限られた期間で定義するのは難しいので、プロジェクトの特徴に応じて、特に重要なものを中心に定義づけを行うのが現実的かもしれない。何を優先するかが検討のポイントになる。
次回予定→ ２．プロジェクト計画策定 つづき
1-1 情報システム開発プロジェクト企画書の作成
111 企業の標準形式に準じた企画書
112 目的・目標・費用等の明確な記述
113 企画の要点を審査しやすい記述
114 責任者の上位管理者からの承認
115 関係者レビューによる内容の合意
1-2 情報システム開発プロジェクト企画の申請と説明
121 公正な立場での審査担当者の参加
122 重点事項中心の効果的な説明会
123 審査担当者の質問への的確な回答
124 設定された制約に大きな支障なし
1-3 情報システム開発プロジェクト企画書の完成
131 再提出を求められた事項の記述
132 企業における実行可能性の検討
133 プロジェクト推進上の障害なし
134 ＰＭの役割・任務・権限が明確
135 企画の初期要求のＰＭへの伝達
コメント：
プロジェクト立ち上げ時には、まず、プロジェクト企画書が作成される。企画内容が審査をパスすると、正式なプロジェクトとして承認され、立ち上がったことになる。さて気づいた方もいると思うが、プロジェクト立ち上げの上記３タスクは、じつはプロマネのスキル基準として定義されていない。もっと上位の、企画担当者あるいは責任者が行うものと想定している。ただし、プロマネ（またはプロマネ候補）が企画書のレビューに参加し、助言を行う機会を得ることが望ましい。というふうな注釈が、スキル基準に書かれている。
Pman注目： 135 企画の初期要求のＰＭへの伝達 スキル基準には「プロジェクトマネージャに企画内容がプロジェクトへの初期要求として伝えられていること」と書かれている。プロマネは、以降のプロジェクト計画をどのように具体化し実現していくのかということに注力する。しかし、時間の経過とともに、そのプロジェクトの本来の目的はいったい何だったのか、忘れがちになるような気がする。忘れるだけならまだしも、目的から外れたプロジェクトになってしまうと、例えば開発したシステムが顧客に使われないなどといった問題が生じることもあるだろう。初期要求を念頭においたマネジメントが必要である。
次回予定→ ２．プロジェクト計画策定
春の試験では、テクニカルエンジニア（システム管理）対策の一つとして試験センターから公表されているスキル標準を読み、キーワードを中心にまとめた。詳しくは、ブログのカテゴリ「
スキル基準(SM)」に整理している。こういう地味な勉強というのは非常に苦痛であり、多くの人はあまりやらないと思われる。しかし、私としては、こういう地道な作業をスキル作りの基盤と考えて、秋の試験対策にも取り入れるつもりである。
3月27日付の記事：【スキル標準】の整理で書いたように、システム管理のアクティビティは10種類であった。これに対し、プロマネは下記の６種類である。
【情報システム開発プロジェクトマネジメントプロセス】
１．プロジェクト立ち上げ
２．プロジェクト計画策定
３．プロジェクト追跡と実行管理
４．変更管理
５．プロジェクト終結
６．プロジェクト完了評価
なんだ少ないじゃないか、と思われるかもしれないが、内容的にはけっこうなボリュームがあるのだ。ところで、春はシステム管理のスキル基準をまとめた内容をブログ上にただ垂れ流し的に掲載しただけであった。また同じやり方では面白くないので、今度は私なりのコメントを入れた形でアップしてみようと思う。さっそく次回から始めよう。私といっしょに勉強したい方はどうぞ（コメントも歓迎）
次回予定→ １．プロジェクト立ち上げ
| ホーム |
