プロジェクトマネージャ試験の午後Ⅱ、合格論文のサンプル骨子を掲載します。
こんな低レベルの論文でも合格できますので、コツを掴んでください！
試験中もこんな低レベルで大丈夫か？と一瞬不安になりましたが、不合格になる理由もないだろう、と思っていました。
実際合格しましたので、参考にしてもらえればと思います。
まずは合否結果について
結果は以下でした。
午後Ⅰはギリギリでしたが、合格です。
2013年の試験ですので、問題は古いですが合格のためのエッセンスは変わっていません。
是非コツを掴んで合格を勝ち取ってください！
午後Ⅱ 選択問題
2013年（平成25年）の午後Ⅱは問１を選択しました。
ここにはほぼ骨子が載っているので、うまく対応関係を見極めて、自分の経験したプロジェクトに当てはめていけばいいんです。
それではやり方を説明していきます！
設問ア 骨子のサンプル
設問アは以下です。
よって、お題は３点に絞られます。
それをアー１～アー３までに分け、それぞれに骨子となる文言や文章を入れていきます。
設問アを分解すると以下の３つですね！
アー１ システム開発プロジェクトの特徴
アー２ 情報セキュリティ上のリスクが特定された開発業務
アー３ 特定されたリスク
それぞれ具体的に自分の経験を載せていきましょう。
自分の経験でなくても、大体こんなもんだろう、でもOKです！
骨子なので、以下のように文章にせずに自分が見て論文を書けるレベル（箇条書き）でまとめておけば大丈夫です。
アー１ システム開発プロジェクトの特徴
冒頭では、自分の会社の業態、自分のポジションについて明記してください。
プロマネをやったことがなくてもプロマネとして書かないと速攻で不合格です。
ですので、プロジェクトマネージャの試験なら立場はプロマネ以外にはありえませんので、ご注意ください！
私は銀行系SIerのプロジェクトマネージャである。
系列のローン保証会社の基幹システム更新プロジェクトであり、一般顧客の氏名、住所などの一般的な個人情報以外にも、銀行ローン残高、返済予定、金利など、センシティブ情報あり。
開発関係者以外に情報が漏れることは厳禁。
アー２ 情報セキュリティ上のリスクが特定された開発業務
開発は保証会社（顧客）ではなく、自社（システム会社）で実施。
そのため、テスト工程、特に結合テスト以降のテスト工程で実データを利用したテストの際、顧客→自社へのデータ持ち出しにリスクあり。
データ移行での移行データ不備、改ざん。
※この時、開発時のリスクだけでなく運用面でも言及が必要です。
問題文に指定されていますから。
それも踏まえて、リスクを記載していきましょう。
アー２では開発業務に絞って書きましたので、アー３にそれを踏まえて、運用段階で想定されるリスクも書いてみましょう。
アー３ 特定されたリスク
開発時：データ持ち出し、漏洩による会社外へのデータ流出
データの盗み見による会社内の関係者以外への情報漏洩（印刷物放置など）
移行時：データ改ざん、データ破壊による金額不整合による銀行の信用喪失
運用時：テスト用や調査用データとして実データを利用したい場合も同様のリスクがあるため、運用も考慮が必要
特に担当者の入れ替わりによる引継ぎモレなど
設問アは大体こんなもんで十分でしょう。
設問イ 骨子のサンプル
設問イは以下です。
アで述べたリスクについて、それぞれ運用面での予防策を骨子に箇条書きしていきましょう。
まず、設問イを分解して骨子として必要なものを抽出します。
イー１ リスクに対する運用面の予防策
イー２ 各予防策の周知方法
イー３ 各予防策で重要と考えた点
こんな感じですかね。
では、作っていきましょう。
この時、各リスクに番号を振っておくと採点者もわかりやすく、論文を書く時も漏れがなくなりますから、オススメです。
開発時のリスクを１，移行時を２、運用時を３、などどして、採点者にも漏れがなく網羅できていることをアピールすると良いかと思います。
私は毎回やっています。
イー１ リスクに対する運用面の予防策
１：開発時の予防策（運用フェーズに入った後）
故意や偶然に関わらず、データの盗み見を防ぐ仕組みが必要
個人情報はシステムでもキー情報以外はマスクするような機能を付加し、必要な時以外は参照できないようにした
２：移行時の予防策
データ移行に失敗していたことに気づかず運用された場合、時間が経つほどに影響が大きくなる。
それを防ぐため、データ移行では全テーブル、全カラムのデータが全て一致していることを機械的に確認し、責任者レベルでのダブルチェックを実施。
また、２～３か月は新旧のシステムを両方稼働させ、常に両方の数字が同じになることを確認することで、運用フェーズに入った後でも問題ないことを担保する。
３：運用時の予防策
サーバはシステム会社のオンプレミス環境とすることで、保証会社から開発会社へ実データの持ち運びをなくす。
また、管理者権限によるデータの更新やサーバログイン履歴は毎日保証会社の担当者がチェックし、不正なアクセスがないことを確認する。
保証会社と開発会社でのデータのやり取りは原則行わず、連絡は基本電話による口頭とすることでデータ流出そのんものを防ぐ。ただし、口頭による連絡ミスを防ぐために、対象の顧客のキー情報のみはメールベースでのやりとりを可能とする。
イー２ 各予防策の周知方法
開発時、移行時、運用時のそれぞれのフェーズにおいて、毎回担当者へ上記の内容の周知。
また、メンバーが入れ替わることも想定し、全て文書化してまとめておき、教育履歴を毎月の進捗会議で確認。
イー３ 各予防策で重要と考えた点
開発・運用メンバーに顧客からアクセス履歴が見られている、という意識を植え付けることが抑止力の観点から重要と考えた。
また、担当変更による引継ぎもれに起因するミスも想定されるため、協力会社を含め、メンバー変更時の周知は徹底することが大事。
さらに、稼働後は新旧システムを両方稼働させる想定であるため、顧客企業へも事前に内容を理解してもらい、運用リソースを通常の２倍確保してもらう旨、説明・了承が必要。
まぁ、こんだけ書けば十分でしょう
設問ウ 骨子のサンプル
設問ウは以下です。
これも開発、移行、運用の各段階で書いていけばいいでしょう。
ウー１ モニタリングの仕組み
ウー２ 発見された問題と対処
全部に問題が発生していないくても、一部の内容について詳しく書いていけば良いかと思います。
ウー１ モニタリングの仕組み
開発時のモニタリング：
個人情報のマスク機能がすべての画面に付与されているか？をテスト仕様書のひな形として作成しておき、全ての機能でテストに盛り込めるようにした。
移行時のモニタリング：
全テーブル、全カラムデータの件数、値が同じかどうかをスプレッドシートで検証した。
スプレッドシートの設定そのものに誤りがないことを複数人で検証し、抜けモレがないことを確認した。
運用時のモニタリング：
管理者権限でのサーバアクセス時は、事前に管理表へ記載したうえで実施する手順とした。
また、要員交代時の引継ぎ資料についても事前に作成し、資料をベースに引継ぎを行っていることを月次の進捗会議で確認した。
ウー２ 発見された問題と対処
顧客企業が連絡を受けていない管理者権限でのアクセス履歴が散見される、と報告を受けた。
実際、問題が発生すると、原因究明とトラブル解決を優先するため、まず第一にサーバへアクセスし状況を確認していた。
トラブル対応としては事象の収束と解決を優先する方針で問題ないが、管理方法を改善した。
まず、サーバへアクセスした際は、事後報告でも構わないため顧客へ当日中へ連絡する手順とした。
また、サーバアクセスのログも１週間に１度、運用管理者が確認し、顧客へ申請しているアクセス履歴と合致していることを確認するフローと修正した。
以上
って感じです。
論述の対象とするプロジェクトの概要
論文試験では、論文以外にもアンケートのようなものを記入する必要があります。
このアンケートは非常に大事ですので、ざっと目を通しておいて、試験当日に記入する内容をイメージしておいた方がよいです。
詳しくは関連記事を参照してください。
この内容と論文の内容の整合性が取れていないと不合格になりますので、気を付けてください。
まとめ
どうでしょうか。
大した内容ではないと思います。
でも、題意に沿って、何を書かなければいけないのか、アー１～ウー２のように分解してもれなく抽出し、自分の経験＋αで載せていけば、確実に合格ラインに達すると思います。
練習は骨子だけで十分ですので、何度か練習してコツを掴んでください。
自分の経験したプロジェクトから２～３書きやすそうなものを選んで練習しておけば、本番で多少骨子の変更が必要になっても対応できると思います！
これができればプロマネ合格にはぐっと近づきます。
頑張ってください！
※ITストラテジストの論文のサンプルはこちらの記事で紹介していますので、よかったら見てみて下さい。
コメント