情報処理技術者試験(PM/SM)に連続で一発合格したおじさんによる プロジェクトマネージャ試験 午後Ⅱのモジュール一覧

　プロジェクトの特徴は、それまで当社で実施した類似プロジェクトよりも、３カ月程度短納期だったことである。
プロジェクトを受注した翌年の４月には、改正された法律が施行されるため、A社の社員教育の期間を考慮すると、１月末までにはシステムテストを完了させる必要があった。

　プロジェクトの特徴は、A社の経営上の最重要課題が海外への製品輸出であったことである。
製品を海外に輸出するためには、製造管理、品質管理の基準であるＧＭＰ（Good Manufacturing Practice）に準拠する必要がある。
　A社がＧＭＰ認証を受けるためには、A社の生産管理プロセスがＧＭＰの要求を満たしている必要があるが、今回導入する生産管理システムもＧＭＰの要求事項を満たす必要があった。

　プロジェクトの特徴は、使用するサービスの種類やリソースの量に応じて課金されるクラウドサービスを利用する必要があったことである。
　顧客のニーズや他社動向の急激な変化に対応するため、システムの機能やリソースを適宜最適化させる必要がある。また、新規事業の運営は不確実なことが多いため、初期投資を抑える必要があった。

　開発するシステムは、使用するサービスの種類やリソースの量に応じて課金されるクラウドサービスを利用することにした。
　顧客のニーズや他社動向の急激な変化に対応するため、システムの機能やリソースを迅速に最適化させる必要がある。
また、新規事業の運営は不確実なことが多いため、初期投資を抑える狙いがあった。

　開発するシステムのベースとなるクラウドサービスは、A社のクラウドサービスを利用することにした。
　最新のデジタル技術を活用するにあたって、多くの仮説と検証を繰り返す必要がある。しかし、仮説検証のために多くのコストを割くことはできず、かつ短期間で終える必要があった。
　A社のサービスは、見込み顧客にフルスペックで検証できる環境を無償提供しており、仮説検証を効率よく進めることができると判断した。

　プロジェクトの計画は、WBSを作成して段階的に詳細化することにした。
　プロジェクトのスコープは、新規事業で販売する商品のラインナップやその販売状況に左右される。
先行販売する商品は決まっていたが、その販売状況によって次の商品ラインアップを決定する必要があった。
　WBSは事業の進捗状況にあわせて、計画の内容を段階的に詳細化することができる。

　特に重要視したプロジェクトメンバーの採用基準は、「多様な価値観を受け入れ、それぞれの知見を活かして議論できる人材であること」であった。
新事業は不確実な要素が多いため、事業の状況に柔軟に対応するためには、多種多様な知見を活用させる必要があると考えた。

　定性的リスク分析の結果からリスク対策の優先度を設定し、各優先度に応じた対策を立案した。
具体的には、リスクの発生確率（大・中・小）と影響度（大・中・小）を組み合わせによって優先度を設定した。
例えば、発生確率・影響度ともに大と分類した「プロジェクトメンバーの所属部門の本業によって、プロジェクトメンバーの工数が十分に取れなくなる」リスクは、すぐに対策を実施すべきリスクと判断した。
発生確率・影響度ともに小と分類したリスクは、リスク顕在化のモニタリング指標を設定するのみとし、対策はリスクが顕在化してから立案することにした。

　リスク対策は、スケジュールの観点と品質の観点で立案した。
例えば、「並行運用期間中に、コンタクトセンターのサービスレベルである応答率が満たせないことが発覚する」リスクに対しては、下記の２点の対策を立案した。
１．本番運用の開始時期を延期する
　サービスレベルが満たせない原因解決のための時間確保のため、本番運用の開始時期を延期する。例えば、ハードウエアの性能問題が原因である場合は、ハードウエア増強の時間を確保する必要がある。
２．サービスレベルの目標値を見直す
　システム切り替え時期を変更できない場合には、一時的であってもサービスレベルの目標値を下げる必要がある。

　システム移行にあたっては、リハーサルを２回実施することにした。
具体的には、１回目のリハーサルでは、移行作業手順や移行に伴うシステム停止時間の妥当性確認を行い、見つかった不備の修正結果の妥当性確認を、２回目のリハーサルで行った。
新規システムは、これまで導入実績のない技術を採用しているため、移行作業項目の漏れが発覚することによって、移行作業時間がシステム停止時間を超過する可能性があった。

　コンタクトセンターのオペレータが、新規システムのトレーニングに使用する環境は、マニュアルに記載されている全ての操作ができるようにした。
オペレータが操作できない箇所があると、移行当日に現場の混乱による、コンタクトセンターのサービスレベルである応答率低下の可能性が高くなる。

　トレーニング環境を準備するうえで工夫した点は、現行システムのトレーニング環境と分けた点である。
コンタクトセンターには、新人オペレータが随時作用されており、その都度現行システムのトレーニング環境を利用したトレーニングを行っている。
新システムと現行システムのトレーニング環境が共存すると、新人オペレータのトレーニングに支障がでる可能性があった。

　リスク対応計画を行うにあたって、A社の社長以下役員全員に、プロジェクト運営に関するヒアリングを行った。
プロジェクトのステークホルダには多様なメンバがおり、リスク対応計画における戦略がぶれる恐れがあった。
事前に役員全員からヒアリングしたうえで戦略を立案することで、戦略にブレがでないようにできると考えた。

複数ベンダに関わるプロジェクトにおいて、マイルストーンの設定を工夫した。
具体的には、各社の開発箇所を接続する機能の開発については、各工程の開始・終了を合わせるようにした。
例えば、Ｘ社の詳細設計の修正が必要な場合、Ｙ社がすでに製造工程を終了していた場合に、Ｙ社の開発に多くの手戻りが発生してしまう。
工程を合わせることで、手戻り発生による影響を小さくする狙いがあった。

　製造工程のコスト見積もりにあたっては、ファンクションポイント法と類似プロジェクトによる見積りを併用した。
具体的には、システム入出力データやデータベースの項目数などから、開発規模を試算した。
さらに、今回のプロジェクトのようにコスト見積りがしづらかったプロジェクトの生産性を掛け合わせ、開発工数を試算した。

　製造工程のコスト見積もりにあたっては、ファンクションポイント法と類似プロジェクトによる見積りを併用した。
具体的には、システム入出力データやデータベースの項目数などから、開発規模を試算した。
さらに、今回のプロジェクトのようにコスト見積りがしづらかったプロジェクトの生産性を掛け合わせ、開発工数を試算した。

想定外に発生するリスク対応のために、プロジェクト期間中に追加予算の承認を得ようとすると、経営陣との調整によるプロジェクトが遅延してしまう。
そこで、想定外に発生するリスクに備えてマネジメント予備を確保するよう、経営幹部の了承を得ることにした。

　直接会う機会を重視した。
具体的には、原則的に毎日午後は開発現場に出向くように自分のスケジュールを調整した。
最低でも週に一度はすべてのメンバーと直接会話する機会を持つよう、チェックリストを作
成した。
　また、会話した日時と会話内容を記録するようにした。メンバの様子で目立ったところがあった場合には、それについても記録しておくようにした。

　目的によって、コミュニケーション手段を使い分けた。
具体的には、各メンバとそれぞれの目標設定を行う場合は、個別に面談を行い、プロジェクトの目標や重要な課題の伝達には、ミーティングを開催し集団でのコミュニケーションを図る機会を利用した。

　メールや電話によるコミュニケーションだけでなく直接会って話をする機会も持つようにした。
例えば、利用部門との画面デザインレビューのように、ドキュメントの回覧レビューではお互いの意思が伝わりにくい場合には、積極的に会議形式でのレビューの場を設けるようにした。

　ひとりひとりと個別に会う機会と、ミーティングを併用するようにした。
例えば、以下のようなケースである。

• メンバー全員で共有すべき指示伝達事項は、ミーティングの場を利用する。
• 特定のメンバーに対する指導などを行う場合には、個別に会う機会で話をする。

　コミュニケーションの相手や内容によって、その媒体と頻度を使い分けるようにした。
例えば、下記のような使い分けをした。

• 開発チーム内で行っている朝礼では、前日の作業実績と当日の作業予定および問題の有無確認を行う。
• Ａ社への週次の定例報告メールでは、プロジェクトの進捗状況の報告と問題の有無報告を行う。
• 問題があった場合の報告や議論は、個別に会議を実施する。

　コミュニケーションの頻度と媒体を使い分けた。
具体的には、プロジェクト開始前の準備期間に行ったステークホルダ分析の結果に基づき、コミュニケーション計画を作成した。プロジェクトオーナ、顧客ユーザ部門、開発チームリーダ、外注先、といったステークホルダごとに、月次・週次・日次といった頻度と文書（紙）、メール・掲示板・ミーティングといったコミュニケーション手段を定義した。

　プロジェクトメンバーにヒアリングを行った。
特に留意した点は、プロジェクトマネージャである私の意見を、メンバーに悟られないようにしたことである。
他人の意見に引きずられない、各メンバーが主観的な考えを引き出すことが狙いだった。
例えば、他のプロジェクトメンバーへの不満といった否定的な意見に対しては、「我慢してもらうようになだめる」「相手に同調する」といった態度をとるのではなく、「不満を持っているという事実を受け入れる」「不満の理由を確認する」という姿勢でヒアリングを行った。

経営陣からの要求や指示が一貫していないことが、プロジェクト推進上の阻害要因だった。
Ａ社の経営陣にはＸ社派とＹ社派がおり、それぞれのベンダに配慮したような要求や指示があった。
この阻害要因を回避するために、具体的には次のようにして、プロジェクトに対する経営陣からの指示ルートを一本化するようにした。

• 経営陣からのプロジェクトに対する要求や指示は、経営会議で決定したうえで行う。
  プロジェクトへの指示はＡ社ＣＩＯが行う。
• プロジェクトから経営陣に了承を取り付ける必要がある事項は、Ａ社ＣＩＯを通じて経営会議に諮る。

プロジェクトの定例会は、ベンダと個別に実施する会議と、全ベンダの責任者が参加する会議を設定した。
全ベンダの責任者が参加する会議を設定したのは、各社に関わらる課題や調整事項の対応を迅速化することが目的であることに加え、各ベンダの責任者のプロジェクトへの関与度を高める狙いがあった。

　プロジェクトの早期段階でＡ社のキーパーソンを参画させることにした。
具体的には、Ａシステムの利用者となるＡ社の第一～第三営業部からそれぞれリーダー・サブリーダーを任命し、部内の要求の取りまとめ・調整を担当させることにした。

プロジェクトの早い段階から、ユーザ部門のキーパーソンをプロジェクトメンバとして参画させた。
具体的には、プロジェクト計画検討段階のプロジェクトオフィスに各ユーザ部門のキーパーソンを参画させ、ユーザ部門の要求取りまとめやプロジェクト概要の伝達など、中心的な役割を持たせた。

　プロジェクトの目的意識をメンバー全員が納得できるように工夫した。
具体的には、キックオフミーティングを開催しプロジェクトの位置づけや目的をメンバー全員で共有できるようにした。また、定例会の場などで目的の再確認を行うなど、目的意識共有の維持・強化に心がけた。

　利害関係が対立するような場合には、複数の代替案をメリット・デメリットを踏まえて当事者間で議論した上で選択させるようにした。
例えば、ユーザインターフェースについて利用部門と開発チームでの意見が一致しない場合は、両者で代替案を提案させるようにした。
また、議論が平行線をたどるなど、結論が出ない場合はプロジェクトオーナーにエスカレーションを行い、当該機能部分のみ実装を延期するかどうかも含めて判断を仰ぐようにした。

　プロジェクトの位置づけ、目的を十分に説明し納得してもらう機会を設けた。
具体的には、ユーザ部門ごとに説明会を開催し、複数の代替案も含めて、それぞれのメリット・デメリットとともに示し、ユーザの中から選択させる形で同意を得た。
どうしても納得が得られない場合は、プロジェクトオーナにエスカレーションした。

　定期的に進捗状況・勤務状況・不具合の検出状況などのモニタリングを行い、問題の兆候が見られれば早期に対策を打つようにした。
例えば、開発チームの残業時間が基準値を超えている場合には、個別にヒアリングを行って残業超過の原因分析を行うなどした。

　定期的にさまざまな項目で進捗状況をチェック・評価した。
例えば、各開発チームメンバの出勤状況、残業時間、雰囲気（簡単な面談による本人の様子の確認と、チームリーダからのヒアリング）などもチェックし、何らかの気がかりな点があれば、直ちに対策を打った。

　コスト差異を把握するために、チケット管理システムを利用したＥＶＭを採用した。
　ＥＶＭを確実にするために工夫した点は、プロジェクトメンバーが予実をタイムリーに入力できるようにしたことである。
例えば、工数の予実が入力できていることを確認する場合、朝会にて前日タスクの進捗を確認するにあたって、工数入力実績と合わせて確認することで、前日分の入力漏れを把握できるようにした。

変更管理委員会で変更の承認を行う前に、プロジェクトに参加する各ベンダーによる共同レビューを実施するようにした。
例えば、Ｘ社の開発範囲に影響しないと考えて実施したＹ社の設計の変更が、実際にはＸ社の開発範囲に影響を及ぼしてしまう、といった問題を見落とさないようにようにする狙いがあった。

　プロジェクト憲章を作成した。
具体的には、プロジェクトの背景・目的・大まかなスケジュール・体制などをプロジェクト憲章に記載した。
　特に留意した点は、プロジェクトの遂行が最優先事項であることをプロジェクトの背景に明記すること、プロジェクト憲章の説明を経営幹部にしてもらうことである。
プロジェクトメンバーには、現在の業務と兼務しているメンバーがいるため、現在の業務よりも優先順位が高いことを明確にし、全社での協力体制を確立する狙いがあった。

　プロジェクトチーム編成において工夫した点は、プロジェクトチームを経営幹部直下に配置した点である。
経営幹部直下にプロジェクトチームを配置することで、全社からプロジェクトメンバーを参画させるための調整がしやすくなる。

　プロジェクトチーム編成において工夫した点は、パッケージ標準のプロセスと現在の業務手順の違いを机上で確認する作業（フィット＆ギャップ作業）の期間中、業務プロセスを理解しているA社の従業員を専任させたことである。
　フィット＆ギャップ作業の結果は、要件定義におけるスコープ確定の前提になるため、高い精度が求められる。
当社だけで高い精度のフィット＆ギャップ作業を行うためには、既存の業務マニュアルを細かく読み解くための多大な工数が必要になってしまう。
A社の従業員を専任させるのは、その工数を抑制する狙いがあった。

　システム構築作業やパラメータ設定作業を、外部のベンダーの支援を受けながら、本番稼働時に運用を行う予定の要員が行うようにした。
外部のベンダーに構築作業などを委託しなかった理由は、本番稼働後に発生するトラブルをなるべくベンダーに頼らないようにするためである。
外部ベンダーに頼らない運用を行うことは、トラブル対応の迅速化や外注費の圧縮も期待できる。