情報処理技術者試験☆合格への道

ライフワークとしての資格取得ブログ presented by Pman






Since 2005/01/10

ブログ内検索↓

カテゴリー


ブログランキング

にほんブログ村 資格ブログ 国家試験へ にほんブログ村 資格ブログ IT系資格へ
 にほんブログ村 資格ブログへ
 ブログの殿堂
資格・スキルアップ Ranking  ナレコム おけいこブログランキング

アンケート


広告エリア1




参加トラコミュ


SEO/サイト価格

SEO対策・SEOとは
IT  資格  ブログ
受験  日記  合格  論文


最近の記事


リンク集




自己紹介など

    くつろぐ

  • ニックネーム:Pman
  • プロフィール:
     情報処理サービス会社に勤務。主に金融業のソフトウェア開発、システム運用・保守を担当。メインフレームからオープン系まで広く浅く経験。資格取得はライフワークとなりつつある。
    保有資格
    システム監査技術者
    プロジェクトマネージャ
    アプリケーションエンジニア
    テクニカルエンジニア(システム管理)
    ネットワークスペシャリスト
    情報処理技術者(一種、二種)
    電気通信主任技術者(第一種伝送交換)
    工事担任者(デジタル第1種)


  •  質問、要望、感想、応援などは
     下のメールフォームから、直接
     私あてに送ることができます。


     当ブログはリンクフリーですが、
     リンクした場合は、メール又は
     コメントで知らせていただくと
     ありがたいです。

メールフォーム

名前:
メール:
件名:
本文:

広告エリア2












スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

6.プロジェクト完了評価

 6-1 プロジェクト完了後の評価
  611 評価指標の概要作成
  612 評価指標の必要に応じた追加更新
  613 プロジェクト計画に関する評価
  614 実行過程・管理方式に関する評価
  615 開発されたシステムに対する評価
  616 要員・チームが得た成果の評価
  617 以後の参考となる事項の文書化

 6-2 実績情報の収集、整理、分析、データベース化
  621 数値データのアクセス容易な保存
  622 数値データの目的別の分類整理
  623 データによる計画実績の差異分析
  624 分析結果としての教訓のDB化
  625 分析情報が参考値として利用可能
  626 評価基準の妥当性の評価

コメント:
 無事に納品、検収も終わり、メンバーたちに開放感が広がる。あとはサービス開始を待つだけと思いきや、プロマネにはまだやるべきことが残っている。プロジェクトの評価である。これまでまともな評価をしたことがあったかどうか。この機会に考えてみたい。

Pman注目:
 625 分析情報が参考値として利用可能
 スキル基準には「数値データの分析により得られた情報は、以後のプロジェクトでの、参考値などとして容易に利用可能であること」と書かれている。評価や分析した結果は、今後のプロジェクトで有効に活用することを前提に、よく整理しておく必要がある。さらに、プロジェクト管理業務に携わるすべての人が参照しやすいデータベース等の整備と、データ登録を推進するための業務プロセスが望まれる。

あとがき:
 一ヶ月近くにわたり「情報システム開発プロジェクトマネジメントプロセス」の中のスキル基準を取り上げてみた。振り返ってみると、辛かったが、体系的な知識の整理ができ、これからの土台作りとしては有効な勉強だったと思う。個々のタスクについては、15文字以内という条件で、私の独断でまとめている。15文字を超えると、キーワードとしては長くなってしまうので、こういうスタイルになった。ただし、箇条書きではスキル標準の趣旨が十分に見えてこないので、詳しく勉強したい方は、試験センターHPからスキル標準をダウンロードして読んでほしい。

 秋の受験受付は明日8/23まで。お忘れなく!
スポンサーサイト

5.プロジェクト終結

 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 計画書に記述された成果物の存在
 スキル基準には「プロジェクト計画書に記述されたすべての成果物が存在すること」と書かれている。ただし、計画書に記述するのは、例えば、詳細設計書、ソースプログラム、テスト項目表など成果物の種類だけであり、それぞれの種類について、機能単位あるいはモジュール単位の成果物がなくてはならない。私は以前、あるプロジェクトの結合テスト工程が終わりに近づき、成果物の確認をしたところ、1機能におけるテスト成果物が見つからず、青ざめたことがあった。信じられないことだが、進捗表から漏れていたため、テストされていなかったのである。幸いにして、空き要員を割り当てて集中的にテストできたため事なきを得たが、思わぬところに落とし穴があるものだ。
 スキル基準の解説も、次回でいよいよ最終回となる。長かった・・。

 次回予定→ 6.プロジェクト完了評価

4.変更管理

 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 要求の採択・棄却・保留の決定
 スキル基準には「変更要求は、評価関係者により基準に照らして評価され、採択・棄却・保留が決定されていること」と書かれている。ここで私が気になったのは「保留」である。特別な理由もなく、白黒どちらとも決められないから取りあえず保留にしておくというのが気になるのだ。保留にすると、当面はその変更について考えなくてよいのでラクに思えるが、その間もプロジェクトは進んでいるので、保留時間が長くなるほどあとの変更実施による作業負荷が増えることになる。あるいは、保留にしていたが結果的には棄却したとしても、それでユーザが困らないことを確認または立証しておく必要があろう。

 次回予定→ 5.プロジェクト終結

3.プロジェクト追跡と実行管理(4)

 3-B 品質管理
  3B1 適切な品質管理手順の実施
  3B2 品質目標を達成している成果物
  3B3 品質確認へのユーザの参加
  3B4 品質未達時の対応策
  3B5 品質保証計画の変更・承認
  3B6 計画変更に伴う改善状況の確認
  3B7 システム構成品目の管理

 3-C リスク管理
  3C1 リスク管理要素への監視・追跡
  3C2 予定された全リスク予防策の実施
  3C3 リスク発生に伴う不測事態対応
  3C4 復旧状態の確認とその過程の評価
  3C5 リスク発生に伴う全事項の文書化
  3C6 新たなリスクへの予防策の追加
  3C7 評価関係者に対する報告

コメント:
 プロジェクトも佳境にはいり、このペースでいけば何とか納期は守れそう、費用も計画内に収まりそうという状況であっても、品質に関してはまだ改善の余地が残っていることが案外多い。いくら明確な品質基準があり、一定の水準をクリアしたシステムであっても、ある日突然、様相が変わってしまう場合がある。例えば、バグ修正が不十分のためデグレードを起こしたり、ユーザによる確認テストで操作性が悪いと指摘があったり、パッケージソフトのバージョンアップによる影響が出てくるなど、いろいろなことが考えられる。こうしたことに対し、場当たり的に対策を講じるのではなく、あらかじめリスクとして識別しその予防策を施すことが品質保証につながると考えられる。

Pman注目:
 3B3 品質確認へのユーザの参加
 スキル基準には「必要に応じてユーザが品質の確認に参加していること」と書かれている。たとえ新技術を駆使して構築した立派なシステムであっても、ユーザにとって利用価値のあるシステムでなければ意味がない。開発者と利用者の両方の観点から、品質を評価しなければならない。ユーザが真に求める品質とは何かを、的確に把握する必要があるだろう。スキル基準では「必要に応じて・・」としているが、私としては「可能な限り・・」と言いたい。

 次回予定→ 4.変更管理

3.プロジェクト追跡と実行管理(3)

 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 費用変更の計画・承認・実施

コメント:
 近年、プロジェクトマネージャ試験の午後1あるいは午後2で、海外への委託に関する出題があった。人件費などのコスト面で有利な場合が多く、私自身はオフショア開発の経験がないものの、社内では既に幾つかの実例があるのを知っている。スキル標準をよく読むと、海外調達に関する知識という項目があり、取引に関する法律とともに基本的な知識は習得しておきたいところだ。また、調達といえば、契約に関する知識が不可欠であり「知らなかった」では済まないケースも出てくるだろう。国内・国外を問わず、幾つかの会社や組織によって開発を行うことが前提となる以上、考え方の相違や担当者間の摩擦が生じることもある。そこをうまく調整し、プロジェクト全体を統括、指揮していくことがプロマネの責務であろう。

Pman注目:
 385 積極的かつ連帯感をもつ任務遂行
 スキル基準には「プロジェクト要員は積極的かつ連帯感をもって任務を遂行していること」と書かれている。一人でやる仕事はプロジェクトとは呼ばず、複数の人間が共同して行うのがプロジェクトである、と何かの本で読んだ記憶がある。共同作業である以上、人と人との間に生まれるものがコミュニケーションである。インターネットも電子メールも無い時代には、皆がお互いに声を掛け合いながら仕事した。あるいは客先へ訪問し、顔を合わせて話をしたものだ。これに対して最近は、メールでのやりとりが一般化し、相手と活字の交換をするだけでコミュニケーションが成立する、という風潮さえあるように感じる。しかし、活字では伝わらない情報が沢山あるはずで、例えばチーム内でミーティングをする、関係メンバーだけで集まり検討する、インフォーマルな場で相手の本音を聞くなど、いろいろなことを意外にやっているものだ。連帯感があってこそ、プロジェクトは機能する。

 次回予定→ 3.プロジェクト追跡と実行管理 つづき

3.プロジェクト追跡と実行管理(2)

 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.プロジェクト追跡と実行管理 つづき

3.プロジェクト追跡と実行管理(1)

 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問題管理というタスクが存在しているにもかかわらず、ここで問題についての指標があるのは、少し不思議な気がした。けれどもよく考えてみると、問題として挙げたことは、本当に問題なのかどうかさえはっきりしない場合もあり、初めによく吟味する必要があると思う。すぐに対応することがいつも正しいとは限らない。もっと優先して対応すべき問題が残っていれば先送りにしたり、他の問題と同時に解決したほうが効率的であったり、また、ケースによっては「何も対応しない」ことが最善の道だったりすることもある。いろいろな道から近づいてくる問題点の交通整理をするのが、プロジェクトマネージャの任務ではなかろうか。

 次回予定→ 3.プロジェクト追跡と実行管理 つづき

2.プロジェクト計画策定(4)

 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 評価関係者からの承認

コメント:
 QCD-すなわち品質・費用・納期の3つが、プロジェクトにおいて柱となる管理項目となる。特に品質は、システム利用者が業務を円滑に効率良く行うためにもっとも重視すべき要素であろう。ところで、スキル基準によれば、2-4~2-10までのタスクは並行的に進めるもので、各計画は相互に整合性を保つものとしている。つまり、2-3までのタスクで開発方針やスコープの設定をしたあとは、スケジュール、資源、組織要員、調達、費用、品質保証、リスク管理の7つの計画を策定し、最後にこれらの計画を盛り込んだプロジェクト計画書を正式にまとめる作業となる。リスク管理は6タスクで少ない感じがするけれども、各計画のタスクの中に必ず「リスク」という言葉が出てくることから、じつは非常に重要な位置付けにあるものと読み取れる。

Pman注目:
 2B4 管理目標としての基準値が適切
 スキル基準には「各種管理目標としての基準値が適切かつ完全に定義されていること」と書かれている。例えば、品質目標の場合、レビュー指摘件数やバグ発見数などの目標値がプロジェクト計画書に記載されている必要がある。ところが、あればいいと言うものではなく、プロジェクトにとってその目標値が妥当なものでなければならない。品質基準では、一般的にソフトウェアの規模(プログラムステップ数)をもとに算出したりするが、過去の類似プロジェクトにおける実績を参考にしたほうが適切な基準値になることもある。さらに、リスク要因などを加味したうえで、品質だけでなくコストなどに関する基準もしっかりと定義しておくことが肝要だろう。

 次回予定→ 3.プロジェクト追跡と実行管理

2.プロジェクト計画策定(3)

 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.プロジェクト計画策定 つづき

2.プロジェクト計画策定(2)

 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.プロジェクト計画策定 つづき

2.プロジェクト計画策定(1)

 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 プロジェクト情報の範囲が明確
 スキル基準には「プロジェクト情報(成果物、費用、期間、品質、利用者、規模、機能、技術リスクなど)が正確かつ完全に定義され、範囲が明確であること」と書かれている。ただし、これだけの情報を限られた期間で定義するのは難しいので、プロジェクトの特徴に応じて、特に重要なものを中心に定義づけを行うのが現実的かもしれない。何を優先するかが検討のポイントになる。

 次回予定→ 2.プロジェクト計画策定 つづき

1.プロジェクト立ち上げ

 1-1 情報システム開発プロジェクト企画書の作成
  111 企業の標準形式に準じた企画書
  112 目的・目標・費用等の明確な記述
  113 企画の要点を審査しやすい記述
  114 責任者の上位管理者からの承認
  115 関係者レビューによる内容の合意

 1-2 情報システム開発プロジェクト企画の申請と説明
  121 公正な立場での審査担当者の参加
  122 重点事項中心の効果的な説明会
  123 審査担当者の質問への的確な回答
  124 設定された制約に大きな支障なし

 1-3 情報システム開発プロジェクト企画書の完成
  131 再提出を求められた事項の記述
  132 企業における実行可能性の検討
  133 プロジェクト推進上の障害なし
  134 PMの役割・任務・権限が明確
  135 企画の初期要求のPMへの伝達

コメント:
 プロジェクト立ち上げ時には、まず、プロジェクト企画書が作成される。企画内容が審査をパスすると、正式なプロジェクトとして承認され、立ち上がったことになる。さて気づいた方もいると思うが、プロジェクト立ち上げの上記3タスクは、じつはプロマネのスキル基準として定義されていない。もっと上位の、企画担当者あるいは責任者が行うものと想定している。ただし、プロマネ(またはプロマネ候補)が企画書のレビューに参加し、助言を行う機会を得ることが望ましい。というふうな注釈が、スキル基準に書かれている。

Pman注目:
 135 企画の初期要求のPMへの伝達
 スキル基準には「プロジェクトマネージャに企画内容がプロジェクトへの初期要求として伝えられていること」と書かれている。プロマネは、以降のプロジェクト計画をどのように具体化し実現していくのかということに注力する。しかし、時間の経過とともに、そのプロジェクトの本来の目的はいったい何だったのか、忘れがちになるような気がする。忘れるだけならまだしも、目的から外れたプロジェクトになってしまうと、例えば開発したシステムが顧客に使われないなどといった問題が生じることもあるだろう。初期要求を念頭においたマネジメントが必要である。

 次回予定→ 2.プロジェクト計画策定

スキル基準の読み込み開始

 春の試験では、テクニカルエンジニア(システム管理)対策の一つとして試験センターから公表されているスキル標準を読み、キーワードを中心にまとめた。詳しくは、ブログのカテゴリ「スキル基準(SM)」に整理している。こういう地味な勉強というのは非常に苦痛であり、多くの人はあまりやらないと思われる。しかし、私としては、こういう地道な作業をスキル作りの基盤と考えて、秋の試験対策にも取り入れるつもりである。
 3月27日付の記事:【スキル標準】の整理で書いたように、システム管理のアクティビティは10種類であった。これに対し、プロマネは下記の6種類である。

【情報システム開発プロジェクトマネジメントプロセス】
 1.プロジェクト立ち上げ
 2.プロジェクト計画策定
 3.プロジェクト追跡と実行管理
 4.変更管理
 5.プロジェクト終結
 6.プロジェクト完了評価

 なんだ少ないじゃないか、と思われるかもしれないが、内容的にはけっこうなボリュームがあるのだ。ところで、春はシステム管理のスキル基準をまとめた内容をブログ上にただ垂れ流し的に掲載しただけであった。また同じやり方では面白くないので、今度は私なりのコメントを入れた形でアップしてみようと思う。さっそく次回から始めよう。私といっしょに勉強したい方はどうぞ(コメントも歓迎)

 次回予定→ 1.プロジェクト立ち上げ
 | HOME |  ▲ page top


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。