FC2ブログ

駆け出しエンジニアの気ままにブログ

このブログでは、駆け出しエンジニアの私が興味をもったトピックについて不定期に発信しています。

スポンサーサイト  

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

category: スポンサー広告

tb: --   cm: --

駆け出しエンジニアのプロジェクトマネージャ取得への道(5)~午後Ⅱ(論文)試験対策その2~  

プロマネ取得への道、午後Ⅱ(論文)試験対策その2

fig_paper

前回に引き続き、午後Ⅱ対策を進めていきます。

午後Ⅱ試験のポイントは「合格できる論文のイメージを固めること」「合格レベルの論文を書ける準備をしておくこと」 ということで、前回のブログでは過去問題と合格レベルの論文を紹介しました。
※合格レベルの論文については他にもいろいろとWebに紹介されていますので、読んでイメージを固めてください。

今回は具体的な文章の塊(モジュール)の作成を進めます。

以下、午後Ⅱ試験で使えそうな汎用モジュールを、「体制」、「コミュニケーション」、「リスクヘッジ」、 「品質確保」、「業務効率化」という5つの切り口でまとめます。


◆体制関連

内部設計から単体テストまでは外部設計からこの開発に参加している要員の中から各開発チームのリーダを専任し、 2つのチームに分かれて開発を行う。

結合テストでは結合テストチームが結合テストの管理と実施を担当し、各開発チームは摘出された欠陥の改修を担当する。 結合テストチームのリーダには、各開発チームのリーダではなく、テストに関する十分な経験を持つG主任を任命する。

作業項目を2チームに割り振り、開発チームが新規機能の開発を担当し、基盤チームがプラットフォーム導入を含めた 基盤整備を担当することにした。

開発チームの要員の検討に当たって、品質確保、生産性向上の観点から、新バージョンでの開発スキルを持った要員 の確保が必要であると考えた。

プロジェクト検討段階のプロジェクトオフィスに各ユーザ部門のキーパーソンを参画させ、ユーザ部門の要求とりまとめや、 プロジェクト概要の伝達などの中心的な役割をもたせた。

ユーザ部門ごとに説明会を開催し、複数の代替案も含めて、それぞれのメリット、デメリットをともに示し、 ユーザ側にもその中から選択させるかたちで同意を得た。同意が得られなかった場合は、オーナーにエスカレーションした。

各開発チームについては作業的な進捗のみならず、個々のチームメンバの出勤状況、残業時間、雰囲気などもチェックし、 なんらかの気がかりな点があればただちに対策を行った。

開発チームは、共通モジュール開発とモデル固有部分の開発チームの2チームで編成した。共通モジュール開発と 固有部分開発の連携は重要であったが、固有部分において発生した課題やその解決策を共有することにより、 開発効率の向上と品質の確保を図った。


◆コミュニケーション関連

週に一回の打ち合わせを実施し、進捗状況の報告、懸念点の確認、新規・変更依頼の確認を実施し、 業務の円滑化を行った。

ユーザインタフェース部分で細かく設定されていなかった機能について、問題がないことを確認し、 結果をプロジェクト関連部署の共有サーバにアップして共有した。

Z社とのコミュニケーションと、社内のコミュニケーションを分けて実施し、社内外でのコミュニケーション方法の 見直しを実施した。

社内のコミュニケーションは、従来は週次の打ち合わせだけであったが、今回より、これに加えて日次でSWの完成率 のメール報告を実施することでメンバーの意識を向上させた。


◆リスクヘッジ関連

各開発チームに比較的経験の浅いメンバが含まれることから、内部設計や品質や進捗に問題が生じた場合に備えて、 G主任の参加を結合テストの9週間前まで前倒しするコンティジェンシプランを計画した。

レビューの手法は、チームによるミーティング形式のレビューを基本とした。 レビューについては準備段階の活動を重視して、レビューの時間を計画書の理解に浪費させないルールと、 レビューアが誤字、脱字、表記のルール違反に注意を奪われずに欠陥の摘出に集中できるようにするためのルールを決めた。

体制面のリスクを考慮し、成果物をさらに詳細に分解した各要素成果物の完成の判定基準を設定し、 定例ミーティングで進捗状況を確認することとした。

開発作業を予定通りに進める上でのリスクを軽減するために、1月末に行うキックオフミーティングでは、 Z社システムを極力利用して業務プロセスを組み立てるようにCIOから利用部門に協力を要請してもらうことにした。

新バージョンの機能仕様が把握できず設計が進まないリスクへの予防処置としては、 機能仕様が把握できている旧バージョンのものを利用することで対応することにした。

Z社のプロジェクト管理能力が低く、スケジュールが遅れるリスクへの予防処置としては、 S社のプロジェクト管理のノウハウを提供して対応することにした。

Z社への技術移転が進まないリスクへの予防処置としては、プロジェクトの初期に 教育を徹底し、プロジェクト期間を通してフォローすることで対応することにした。

週次レビューでの指示が性格に伝わらないリスクへの予防処置としては、Z社の成果物を ネットワーク上の共有ファイルサーバに保管し、双方で確認できるようにすることにした。


◆品質確保関連

後工程に持ち越すと修正のために大きなコストが発生するような欠陥をレビューで確実に摘出し、 設計工程で品質を作りこむための品質管理計画を立案した。

要件定義作業の手戻りが発生し、進捗が遅延することを防ぐために、理解不足による指摘事項をモニタリングすることにし、 開発期間に影響する数値を早期に見積もるため、新規追加機能などの工数の発生するものをまとめた。

設定された品質目標は、開発標準に準拠するものであった。今回の開発は短期間、低コストの市場投入ではあったが、 品質について妥協することはゆるされなかった。

弊社において標準としてきた開発・テスト基準を適用した。具体的には、ハード部分のテスト基準、ソフト部分の 欠陥摘出基準などであり、すべてこれまでの開発において適用してきた基準を適用することになった。

新規開発するモジュールの開発テストは、既存モジュールの結合テストに比べ、回帰テストの期間を通常の1.5倍 確保した。


◆業務効率化関連

外部設計移行の開発作業におけるS社にとってのメリットを考え、Z社の支援を受けながら、 新システム担当にZ社特有の用語を収集して解説した用語集を作成した。

4月から9月末までの6ヶ月という短期間開発なので、D課長はZ社システムに業務を合わせることで 開発規模を絞り込むこと、及び3月末に要件定義が完了することを重視した。

テストデータを充実させることによってサービス開始後に安定したサービスを提供できると考え、 結合テストの後半から、テストデータとしてデータ移行で作成した新システムのデータを使用することにした。

各チームに自分達が開発する機種に好きな愛称を付けさせた。メンバすべてが自分達が開発中の製品を愛称で呼ぶことで、 開発製品への愛着度アップの効果があった。


・・・以上です。

なんだか、玉石混合といった状態ですね・・・(^_^;)

午後Ⅱ試験対策を進めていく上で、もう少し洗練させていければと思います。


もう、テストまで10日を切りました。ラストスパート、頑張りましょう!!

今回も最後まで付き合ってくれた方、本当にどうもありがとうございました。m(_ _)m

(参考)
高度情報処理技術者試験の論文集PM-プロジェクトマネージャ-過去問題&論文例

(2012年04月06日)




スポンサーサイト

category: 資格対策(PM)

tb: 0   cm: 0

コメント

コメントの投稿

Secret

トラックバック

トラックバックURL
→http://kazufumi1984engineer.blog.fc2.com/tb.php/41-621eaba2
この記事にトラックバックする(FC2ブログユーザー)

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