「情報処理試験まとめ/プロジェクトマネージャ試験の勉強法まとめ/午後2対策」の編集履歴（バックアップ）一覧に戻る

情報処理試験まとめ/プロジェクトマネージャ試験の勉強法まとめ/午後2対策 - (2016/03/09 (水) 20:31:17) のソース

&topicpath()&aname(top)
#divclass(pageTitle){プロジェクトマネージャ試験の勉強法まとめ　午後2対策}
**目次
#contents_line(level=3,sep=　/　)
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**関連ページ
#ls3(情報処理試験まとめ)
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**初めに
　モバイル版のページが表示される方は見やすいPC版からどうぞ。画面下部の「PC版はこちら」をクリック
**勉強テクニックなどについて
***午後2の勉強テクニック
#divclass(h5){解答知識エリアの絞り込み}
　仕事の合間に学習することを考えると、すべての知識エリアで論文を用意するのは難しいと思う。なので過去問の出題傾向と自分の好みに合わせてエリアを決めて学習するのが望ましい（出題傾向はみよちゃん本に記載あり）。
　お勧めの知識エリアは、タイム、コスト、品質、人的資源の4つ。ここから非常に多く出題されている。次に重要なのはリスクと統合マネジメントだけど、リスクマネジメントは、どんなリスクか明示されていなければタイムでもコストでもいいので前者の4つの知識から流用できるので学習しなくても自然と理解できるし、統合マネジメント（主に変更管理）は、それぞれの知識エリアで論文を記述する際にも関わってくる内容なのでこれも自然に学習ができる項目だと思う。
　というわけで、この6つ（正確には前者の4つに注力しつつリスクと統合マネジメントを意識しながら学習する感じ）に的を絞って勉強して、もし他の知識エリアから出題されたらそれは選択しないぐらいでいったほうが効率良く学習ができると思う。
#divclass(h5){事前にプロジェクトを3つ用意しよう}
　論文を記述するのに想定するプロジェクトは、問題に対して矛盾なく適用するために3つぐらい用意しておくのが望ましい。
　例えば、「1次開発と2次開発をわけて」とか「納期が間に合わなそうだから部分稼働を選択する」というような回答を求められる問題だと、組み込み系の製品開発のプロジェクトは適用するのが難しい。24時間の可用性が求められるという場合は24時間だれかがアクセスする可能性のあるWeb系などがわかりやすいし、夜間のバッチジョブを想定した論文なら、クラサバ型の業務システムという感じで考えたほうが話が通りやすい。理解しやすい想定を適用し採点者にわかりやすく理解してもらうっていうのも必要だと思う。
　ちなみに、自分が用意したプロジェクトはこんな感じ。
#divclass(quot){
-Webアプリを利用した業務システムの構築
-Webアプリを利用した会員向け購買サイトの構築
-クライアント－サーバ型のWindowsアプリケーションを利用した業務システムの構築
}
　プロジェクトの規模は固定させたほうが矛盾ない論文が書きやすいようだ。例えば開発期間：○○ヶ月、開発工数：○○人月、ピーク時の要員：○○人、チーム数：○○チーム体制、予算：○○万円という具合に固定し、チーム編成は自分がプロジェクトマネージャでチーム数は2ぐらいがわかりやすいと思う。予算、期間、工数、要員数が想像できないようであれば、そこを知ることから学習しよう。どのぐらいのシステムなら工数はどのぐらいなのか、1人月いくらでプログラマを雇えるのかなど、実際の現実のプロジェクトの数字を知ることも必要だ。
#divclass(h5){エディタの利用}
　論文問題に必要な技術は、問題の解答力（構成力）と、手書き能力だと思う。でも、解答力と手書き能力は一致しない。最初から手書きで練習し疲れてしまうと途中で飽きて面倒になってしまう。だから、ある程度できるようになるまで、エディタを使って構成力を養うほうがいいと思う。それで慣れたら手書きで記述して長文を時間無いで書く練習をするのが効率がいいと思う。
　自分も論文の演習はすべてエディタでやって、直前の数週間で実際に手書きして手を成らす感じで勉強をした。おかげで効率良く論文の学習ができたので、かなり効率良く勉強ができたと感じてる。
　使用するのは、より軽量なエディタのほうが便利。論文では文字数を気にする必要があるので、等倍フォントが利用でき、行数が表示されるエディタがいいと思う。
　例えば秀丸エディタのようなものがお勧め。
　1行を25文字で記述すれば、4行で100文字。8行で200文字というように計算がしやすい。
#divclass(h5){勉強の流れ}
　いきなり骨子を作るのは苦労すると思うので、まずは過去問に対して「章立て」と「設問からの抽出」を作成してみよう。問題文に沿った章立てと設問からの抽出を作るのが最初は少し難しいが慣れると簡単にできるようになる。これらができるようになったら骨子を作成し、次に実際に論文を記述するという流れになる。
#divclass(quot){
-論文の勉強の流れ
--SETP1 章立てと設問からの抽出
---問題文の読解力の向上、問題文作成者の質問意図を理解する能力の向上のため
--SETP2 骨子作成
---ストーリを短時間で作る構成力の向上のため
---プロジェクトを運営するための知識の学習
---想定するプロジェクトを用意するため
--SETP3 エディタで実際に論文を記述
---論文らしい言い回し、知識や定量的表現の入れ方などの学習
--SETP4 実際に手で論文を記述
---長文を書く筋力やテクニック等を実際に身につける
}
#divclass(h5){章立ての仕方～骨子の作り方}
　このページの下部、「解凍テクニックなどについて」の項目にて詳しく記述しています
#divclass(h5){骨子作成中に手が止まったら}
　骨子を作ろうとすると、プロジェクトマネジメントにおける知識において「こういう場合はどうなるんだっけ？」とか「もっと具体的な知識がないと解答できない」という部分が結構でてくるので、そうなったらネット等で知識を調べ、実例を参考にしながら骨子を積み上げていくといいと思う。
　例えばよくあるパターンが品質に関する問題。ソフトウェアの品質を問う問題で「ソフトウェアの品質を保つには品質を作り込むためのプロセスと品質を確認するためのプロセスが重要である。品質を保つために、あなたはどのようなプロセスを組み込みましたか？」みたいなことが、さらっと書いてある。ここで重要となるのが、「品質を作り込むためのプロセス」「品質を確認するプロセス」って何？ってこと。これは参考書等には記述されていないので、自分で学習するしかない。疑問に思った点を煮詰めていくのが学習なのだ。
　ちなみに「品質を確認するプロセス」は、機能性や使用性についてならレビュー、信頼性や効率性ならテストの実施などが該当する。
　それを理解すると「じゃあレビューはどうやる？」「テストはどうやるの？」というように具体的なレビュー法、テスト法が知りたくなると思うけど、それらは応用情報等でも勉強するように、ウォークスルーとか、ラウンドロビンとか、インスペクションとか、ブレーンストーミングとか、ブラックボックステストとか、そんな知識と結びつき、知識と実践が結実するという感じになる。
#divclass(quot){
-論文問題の学習の流れ
--「ソフトウェアの品質を保つには品質を作り込むためのプロセスと品質を確認するためのプロセスが重要である。あなたが関わったプロジェクトにおいて品質を保つためにどのような試作を取り入れましたか？」みたいな設問がある
--私は品質を保つために品質を作り込むプロセスを、こうこうこういうように工夫したみたいな話にしたい
--私は品質を保つために品質を確認するプロセスを、こうこうこういうように工夫したみたいな話にしたい
--じゃあ、品質を作り込むプロセスと確認するプロセスの具体例を知らないと解答できないな・・・
--品質を保つソフトウェアの開発手法や確認する手法について学習しよう・・・
}
　このように論文の骨子を作ろうとするごとに「あ、この知識がないと書けないな」ということがわかってくるので、その部分をネットや参考書を利用して探す。これが重要。これが結構大変なのだが、過去問で一通り勉強すると新傾向の設問でない限り、ほとんど応用できるので合格率を確かなものにするためにはいいと思う。
#divclass(h5){骨子を用意して自分の黄金パターンを見つけるのが重要}
　論文の骨子を考えていくと、自分の用意したプロジェクトパターンに合う骨子が貯まっていくと思う。
　そうすると、自分の得意な黄金パターンがあることがわかってくると思う。そのパターンが理解できるようになると、論文の解答が楽になる。
　例えば、プロジェクトの話なんで、明らかに自分たちに落ち度がある失敗で問題が発生しただと、そもそも自分たちの責任になってしまうので、なかなか自分たちが問題の発生源になることが難しい。かといって、相手の都合による仕様変更とかも、じゃあそのリスクをあらかじめ考慮してなかったの？という話になってしまう。そうなると、予見することが不可能で、でも発生してしまった。もちろん事前にリスク回避を検討したけど、実際に顕在化してしまったので、対策しなきゃみたいな話にならざるを得ないと思う。
　で、骨子を作っていくと、たまたま失敗してしまったパターンみたいなものが見えてくるので、そういうパターンを見つけていくのが重要。
　例えばよくあるパターンだと思われるのがこんな感じ。さらにそれぞれのパターンが自分の用意したプロジェクトと合致する必要があるので、それらを考慮して一つのシナリオを作り上げていくことが重要だと思う。
#divclass(quot){
-ユーザ企業のキーマンが多忙、理解力不足で要件定義が進まない
--対処法：専任の担当者を任命することを要求したり、設計レビューにユーザ企業の人間を参加させたりとか
--用意するべきプロジェクト：理解力不足とかの設定ならWebアプリ形式に決定したがWebアプリについて詳しくないとかの設定に
-ユーザ企業の経営方針変更で仕様変更が発生した
--対処法：上位管理者に相談したりとか、部分稼働するとか、別途予算を要求するとか
--用意するべきプロジェクト：部分稼働とかだとオープンを告知してしまったWebサイトの設定とか
-協力企業の要員の能力不足
--対処法：要員交代等
--用意するべきプロジェクト：基本的には何でもよさげだけど、クラサバ型のシステムが無難？
}
　こんな感じで、基本的にはどんなパターンでも、人間や品質の問題が納期に影響を与え、その納期の遅延がコストに影響を与えることになるので、ある程度の論文パターンを身につけることができれば、それをどんなものにも応用できるようになる。さらにそれぞれの兼ね合いで、いちばんしっくりするプロジェクトを適合して論述するようにすれば完璧だし矛盾が無くなる。
#divclass(h5){筆記用具を揃える}
　学生の頃はどんな筆記用具でも余裕で長文を書けたようなイメージがあるけど、書き慣れなくなると筆記用具で長文を書くのが辛くなっていたりする。
　それでも良い筆記用具を使うと疲れずに長文をかけるようになるみたい。
　いろいろな筆記用具関連のサイトを見ると、手の疲れは筆圧や書き方、筆記用具の性能に依存するようなので、自分の使いやすい筆記用具を使うとかなり改善されるようだ。
　自分も筆圧が強くすぐに手が疲れて困っていたけれど、筆記用具をいろいろ試して、長文を書くごとに疲れずに書けるような方法があることに気がつくことができた。疲れて長文が難しい人はいろいろ試してみるといいと思う。
　自分が、実際に使ったのは、三菱鉛筆のαGELグリップのクルトガ機構搭載タイプ、パイロットのドクターグリップ。替え芯はぺんてるのハイポリマー For Proの2Bの替え芯。
#divclass(h5){原稿用紙を用意する}
　手書きで練習する際には実際に原稿用紙を用意して記述するようにしよう。レポート用紙などに手書きで記述していると、どうしても文字サイズが異なるので本番時に違和感を感じてしまうからだ。
　本番の解答用紙は手に入れることができないが、サイズはA4でそこに400字を記述するような解答用紙なので、市販のA4サイズの400字詰め原稿用紙を購入して実際にそれで手書き練習をするのがおすすめ。実際にマス目の大きさにも違和感なかったし、本番に近い環境で練習できるのはきっとメリットがあると思う。
#divclass(h5){書けなかった漢字はメモる}
　PCに慣れていると、手書きで漢字がなかなか書けなくなってしまっていることに気がつくと思う。
　論文の演習中にPCを使って文字を調べるのは良いとしても、それだけだとまた忘れて書けなくなる事が多い。なので、書けなかった漢字は、どこかにまとめてメモしておいたほうがいいと思う。で、あとから見直して漢字を勉強する。まったく書けなくなっているのなら、本格的に勉強する必要があるけれども、ちょっとど忘れしている程度ならば、あとから見直せば思い出せるはずなので、メモしておいて、本格的な学習に利用したり、試験前日に見直して記憶を呼び覚ましておくようにしたほうがいいと思う。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**解答テクニックなどについて
#divclass(h5){解答用紙への工夫}
　実際の試験では、解答用紙として週刊誌や青年漫画誌のように紙が二つ折りにされ、真ん中がホチキスで留められている冊子が配られる。ちょうど、IPAの各試験の午前、午後の問題冊子のような形状である。その1ページに400字詰め原稿用紙のマス目が印字されている。つまり1ページの裏表に両方記述をすることになる。紙質は厚手の原稿用紙のような感じで、多少、つるつるした感じである。
　ここで二つの問題が発生する。
　一つは裏移りの問題である。1ページの裏表に記述するので、表を書いた後に裏を記述すると表に書いた時が裏移りしてしまうのである。下敷きが使えればいいのだけど、持ち込んでいい筆記用具に下敷きは含まれていないため利用できない。なので特に筆圧の強い人、濃い鉛筆を使うと汚くなってしまい、採点者の印象も悪くなりかねないという懸念がある。中には、最初に問題文の表ページをやぶり間に挟んだり、ティッシュを挟んで裏移りを防止している人もいるようなので、試して見るのもいいと思う。
　二つ目の問題は書き心地が変化してしまうことである。説明が難しいけど、週刊誌の表紙に文字を書こうとすると、机と表紙の間に何枚も紙があるので、当然、書き心地は柔らかい。ところが、裏表紙に文字を書こうとすると、今度は机と裏表紙の間には紙が一枚もなく、机と直接接しているので、書き心地が堅くなる。前述の通り解答用紙も週刊誌のように二つ折りにされているので、1ページずつ記述をしていくと、書いてる紙と机の間の紙の枚数が変化してしまう。この変化が以外と苦痛で、このおかげで手が痛くなったりする。そこで、完全に解答冊子を折り返してしまい、机と記述している紙の間の枚数を一定にさせるようにすると変化が無くていいと思う。よく、満員電車で新聞の読みたい面を折り返して読んでいる人が居るけど、あの要領。単語帳やスケッチブックのようにくるっと裏側に一周させるイメージ。
　ところで関係ないが、会場によっては、かなり机の状態が酷いこともあるようだ。特に古いテーブルで木目がデコボコしているようなところもあるらしい。そういうところはボール紙が配布され、それを下敷きがわりに使うように指示されるらしい。このような可能性も考えて、シャープペンの芯などは異なる硬さのものを用意するとかするといいかもしれない。
#divclass(h5){設問から題目を作成する}
　論文は最初に問題を読んで、それから設問を理解して解答しようとすると、解答する内容がブレてしまうことが多い気がする。
　だから、最初は問題を読まず、どんな解答を求められているか設問から章立てをすることがぶれない解答をする近道だと思う。
　もちろん実際の試験では3問中1問を選択するので、問題を読んで選択するわけだけど、実際に解答するときは設問から章立てして、それから問題文を熟読して解答するのが合格への近道だと思う。
　例えば、平成19年の問1だとこんなかんじ。問題文を読まずに設問だけで章立てするとこんな感じになる。過去問は[[IPAのサイト>http://www.jitec.ipa.go.jp/1_04hanni_sukiru/_index_hani_sukil.html]]からダウンロードできる。
#divclass(quot){
1　私が携わったプロジェクトについて
1.1　私が携わったプロジェクトの概要
1.2　関係者との交渉が必要になった問題と背景
2　問題解決の手順と合意に至った解決策について
2.1　問題を解決するための手順
2.2　交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
3　施策の評価と今後の改善について
3.1　手順と解決策についての評価
3.2　今後どのように改善したいと考えているか
}
　これが求められている内容をすべて網羅した章立て＝論文の流れとなる。場合によっては問題文を読むことで多少は変化してくることもあるが、90%ぐらいはこのままの構成が利用できる。こうすることで問われている内容から大きく乖離することなく解答できると思うし、論文を構成することができると思うので、試してみるといいと思う。
#divclass(h5){問題文から解答すべき項目を列挙する}
　章立てをすることでどのような論文の流れになるか道筋が見えたと思う。次は具体的に何を記述すればいいかをまとめる必要がある。
　みよちゃん本にも書かれているように、このような論述問題では「あなたはプロジェクトマネージャですよね？なら、実際にこういう経験していますよね？そういうときこんなことをしていますよね？で、そのときどう考えてどう行動したんですか？」みたいに聞かれている。これらの具体例は実は問題文の中に記述されている。なので、それをピックアップして、さっき構成した章立ての中に入れていく。
　具体的にはこんな感じ。同じく平成19年の問1。
#divclass(quot){
1　私が携わったプロジェクトについて
1.1　私が携わったプロジェクトの概要
1.2　関係者との交渉が必要になった問題と背景
　※利用部門や協力会社に関わるような関係者との問題が発生
　※開発範囲の認識が異なる、リスク顕在化で納期遅延が発生
2　問題解決の手順と合意に至った解決策について
2.1　問題を解決するための手順
　※関係者と状況の認識を合わせる
　※問題の本質を理解して、選択肢を複数立案して、優先順位を付け、最善方法をみつける
2.2　交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
　※相手との要望が異なり、互いに妥協する過程
3　施策の評価と今後の改善について
3.1　手順と解決策についての評価
　※もちろん顧客が満足で終了
3.2　今後どのように改善したいと考えているか
　※さらにこうすればよかったという記述
}
　このように問題文から抜粋して各章に割り振ることで、具体的にどんなことを記述すればいいのかが見えてくる。あとは、この具体例に合わせて骨子を作るだけ。今までエディタでシコシコと論文の骨子を作成して養った構成力が役に立つ。
#divclass(h5){ストーリ（骨子）を作る}
　あとは作成した章立てに従ってストーリーを考える。最初からいきなりかくと後から整合性がとれなくなることがあるので、最初にうちに骨子を考えてから書き始めるのがお勧め。具体的には、問題選択に5分、章立てや骨子の作成に15分、残りの90分で書き上げて、残りの10分をチェックに使用する感じがベストだと思う。90分で書き上げるのは手書き能力。15分で骨子を作るのは構成力。
　では、実際にどんな感じでストーリーを作るのか。具体的にはこんな感じ。同じく平成19年の問1。ここまでくると問題文をみなくても章立てだけで論文が作れる。これを記述すると時間がかかるから、問題文にアンダーラインを引いたり、章番号を書いたりすることで対応しよう。
#divclass(quot){
1　私が携わったプロジェクトについて
1.1　私が携わったプロジェクトの概要
　▼基幹業務システムの開発　保守契約切れに併せて再構築のため遅延許されない
1.2　関係者との交渉が必要になった問題と背景
　※利用部門や協力会社に関わるような関係者との問題が発生
　※開発範囲の認識が異なる、リスク顕在化で納期遅延が発生
　▼ユーザ企業から口頭で伝えたという仕様変更の要求がありリスク顕在化
2　問題解決の手順と合意に至った解決策について
2.1　問題を解決するための手順
　※関係者と状況の認識を合わせる
　▼伝えていたつもりが、自社では把握せず、どちらの責任にもならないという結論に
　▼変更しないと業務に使えないが、それを変更すると時間がないという認識は一致
　※問題の本質を理解して、選択肢を複数立案して、優先順位を付け、最善方法をみつける
　▼複数立案したが、弊社としては納期を遅延してもらうしかないという結論
2.2　交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
　※相手との要望が異なり、互いに妥協する過程
　▼顧客はとりあえず納期だけはなんとかして欲しいという要求
　▼幸い、仕様変更部分は月集計に関する部分なので、最初の1ヶ月では必要の無い機能。部分稼働はどうか？
　▼顧客も同意し、まずは日次機能を稼働させ1ヶ月以内に月集計機能を実装で合意
3　施策の評価と今後の改善について
3.1　手順と解決策についての評価
　※もちろん顧客が満足で終了
　▼無事うまくいきますた
3.2　今後どのように改善したいと考えているか
　※さらにこうすればよかったという記述
　▼そもそも口頭うんぬんが問題なのでそれを解決できればよかった
}
#divclass(h5){論文の流れの必勝パターン}
　プロジェクトマネージャ試験の論文を読んでいくと「だいたいこんな流れの解答を期待しているんだろうな？」というのがわかってくる。そのあたりが理解できるとしめたもので、難なく解答ができるようになると思う。
　それが、この論文のおおまかな流れの必勝パターン。具体的には、こんな感じの流れになっている。
#divclass(quot){
-あるプロジェクトがある
-そのプロジェクトのはある特徴がある
-その特徴のためプロジェクトにはリスクが内包している
-リスクが顕在化しないように事前対策を複数検討し選択する
-でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった
-さらに対策を検討する
-でもリスクが顕在化してしまった
-そのために事後対策を複数考えて選択する
-リスク回避できたが予定と違うことをしたので、別リスク発生の可能性
-その予防策も考える
-うまく収まってめでたしめでたし。でもこうすればもっとよかったかも
}
　骨子を作ったら、そこから話を膨らませていくわけだけど、基本的にはその骨子の結論やストーリーの道筋をたどるために、字数や設問に合わせて、上記の黄金パターンからいくつかを選択して解答するようにする。こうすると、簡単に肉付けができるし、PMとして考えた理由も理解できるということになる。
　しかし、論文中では、これらすべての解答が求められているとは限らない。例えば、「絶対に納期が許されない状況。なぜか納期遅延の可能性がでてきた。どうしましたか？」みたいな論文を求められていると仮定しよう。この場合では事前対策や兆候の発見までは問われていない。いきなり納期遅延リスクの顕在化であり、その顕在化したリスクに対する対応策だけを回答として求められている。すると、こういうパターンを選択することになる。
#divclass(quot){
-○あるプロジェクトがある　←これは設問アとして絶対に存在する
-○そのプロジェクトのはある特徴がある　←これは設問アとして絶対に存在する
-×その特徴のためプロジェクトにはリスクが内包している　←いきなりリスク顕在化なので問われず
-×リスクが顕在化しないように事前対策を複数検討し選択する　←いきなりリスク顕在化なので問われず
-×でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった　←いきなりリスク顕在化なので問われず
-×さらに事前対策を検討する　←いきなりリスク顕在化なので問われず
-○でもリスクが顕在化してしまった　　←問われている内容
-○そのために事後対策を複数考えて検討する　　←問われている内容
-▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性　←あるとなお良い
-▲その予防策も考える　←あるとなお良い
-○うまく収まってめでたしめでたし。でもこうすればもっとよかったかも　←これは設問ウとして問われる可能性アリ
}
　○は必須に解答すべきこと。最初の二つの○は問アに該当する部分。
　▲は記述するとなお良いけど、場合によっては字数がたりなくなるので考えて追加するべし。
　×は合否に関係しないからスルー。
　みたいな感じで肉付けができると思う。
　で、さらにその内容を突き進めて骨子を埋め込んでいくと、例えばこんな感じになる。
#divclass(quot){
-○そのプロジェクトのはある特徴がある
--Webアプリを利用した基幹システム。かつ納期遅延が許されない
-○リスクが顕在化してしまった
--Webアプリに詳しくなく操作性に関する要件定義が進まなくなって遅延しそう
-○そのために事後対策を複数考える
--案1　要件定義を円滑に進ませるために要件定義の責任者の設置を顧客に求める
--案2　プロトタイプ手法を採用
-○プロジェクトの特徴を考慮して、その複数の案から最善案を選択する
--ユーザにとってもっともわかりやすいと思われるからプロトタイプを選択
-▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性
--プロトタイプ手法の採用でかえって作り込みが増え遅れないか？
-▲その予防策も考える
--あくまで操作性に限定したプロトタイプにするよう両社で合意
-○うまく収まってめでたしめでたし
}
　このようなプロジェクトマネージャにとって王道の考え方に従って、問題発生の理由、プロジェクトの特徴、その解決法をうまく組み合わせると、旨い具合に論文が肉付けできると思う。
#divclass(h5){章中の流れの必勝パターン}
　もう一つのパターンが一つの章の中で記述すべきパターン。
　みよちゃん本でも記述されているようにシステムアーキテクトの論文でなく、プロジェクトマネージャの論文なので、マネジメントする立場になって論文を記述していかなければならない。そのためには、以下のようなパターンを多様するとマネジメントっぽい感じになる。
　具体的にはこんな感じ。
#divclass(quot){
-ある問題が発生した（発生しそう）
-原因を調査した
-その原因に対する対策として○○を実施させた
-なぜなら○○が○○だから○○だと考えたからである
}
　たったこれだけ。具体的な論文になるとこんな感じになる。
#divclass(quot){
-ある問題が発生した（発生しそう）
--納期遅延が発生しそう
-原因を調査した
--調子したところ今回の開発で使用するテクノロジでの開発経験の無い要員が多かった
-その問題に対する対策として○○を実施させた
--そこで経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
-なぜなら○○が○○だから○○だと考えたからである
--なぜなら勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
}
　こうすると、かなりプロマネっぽい論文になると思うけどどうだろうか？
　こういうパターンでなく、○○だった。だから○○した。それで○○だ。という感じだとＢランクになってしまう可能性が高いんじゃないかと思う。例えばこんな感じ。
#divclass(quot){
-納期遅延のリスクが顕在化しそうだった
-そこで経験者に新人の教育を実施させた。
-その後進捗が挽回しはじめ最終的に納期が守られた。
}
#divclass(quot){
-納期遅延が発生しそう
-調査したところ今回の開発で使用するテクノロジでの開発経験の無い要員が多かった
-そこで経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
-なぜなら勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
}
　この二つと見比べてみると、やはり後者のほうが良いような感じがする。
#divclass(h5){知識を散りばめる}
　これでなんとなく体裁は整ったが、さらに知識をちりばめてアピールすると、より合格論文に近くなると思う。
　具体的には、実施した施策の根拠となるツール、理論、必勝法などを記述する。そうすると、前章の例もグッと厚みが増してくる感じにみえる不思議。
　実際に記述するとこんな感じ。
#divclass(quot){
-納期遅延が発生しそう
-各チームリーダや現場の人間から本音を聞き出すため個別にミーティングを実施し、特性要因図を利用して原因を分析した
-その結果、今回の開発で使用するテクノロジでの開発経験の無い要員が多かったことが主な原因であることがわかった
-これらの対処には要員交代したり、開発要員を同室で作業させるなどの改善なども考えられる
-しかし、今回は経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
-なぜなら、ただちに経験豊富な要員を集められることは現実的でないからである
-そして勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
-また過去の類似プロジェクトの結果から要員教育の効果で成功した例が多くこの例が参考になると考えたからだ
}
　みたいな感じでどんどん加筆して知識をいれてしまう。すると、なんか偉そうな論文に見えてくる感じがする。
　分析手法やツールはいろんな場面でちりばめる知識として利用できる。そのため、それらを暗記しておくことが重要になる。で、ここで「必勝パターン」がでてくることになるのだが、やはり「必勝パターン」の暗記は重要だと思う。
　論文中に使える必勝パターンは例えばこんな感じ。
#divclass(quot){
-発生確率・影響度マトリクス
-インスペクション、ウォークスルー、ラウンドロビン
-デルファイ法、過去の類似案件からの類推
-特性要因図、パレート図
-ミーティング、個別面接
}
#divclass(h5){定量的な解答をする}
　知識をちりばめるのと同様に、所々に定量的な表現を入れることも大事だと思う。数字が入ると説得力が増すからだ。だけど、実際の論文との内容で矛盾が生じるかもしれないので結構難しいところだと思う。
　例えば定量的な表現をいれるとこんな感じになる。
#divclass(quot){
-納期遅延が管理上限の進捗10%以上の差違が発生しそう
-各チームリーダや現場の人間から本音を聞き出すため個別にミーティングを実施し、特性要因図を利用して原因を分析した
-その結果、今回の開発で使用するテクノロジでの開発経験の無い要員が多かったことが主な原因であることがわかった
-これらの対処には要員交代したり、開発要員を同室で作業させるなどの改善なども考えられる
-しかし、今回は経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
-なぜなら、ただちに経験豊富な要員を集められることは現実的でないからである
-そして勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
-また過去の類似プロジェクトの結果から要員教育の効果で成功した例が多くこの例が参考になると考えたからだ
-実際に過去の例では勉強会の実施で一時的に5%の進捗率低下となるが、その後持ち直し、対策をしない場合より10%の納期短縮されていた
}
　こんな感じ。この例は割合で記述しているが、具体的な工数や金額で答えられればそのほうが良いと思う。
　定量的な言葉として使いやすいものは以下のような感じ
#divclass(quot){
-進捗率、工数、ステップ数
-レビューの指摘件数、指摘密度
-テスト数、密度、網羅率
-不具合の発見件数、発見密度
-レスポンス時間、バッチの処理時間、システム停止時間、要望された機能の実装率
}
#divclass(h5){検討した結果を複数用意する}
　これはすでに今までの中の話で取り上げているので短く説明すると、だいたい一般的には対策が複数考えられる。しかし、そのうち対策として実施するのは一つか二つのことが多いと思う。それは他に考慮すべき事柄があって、それを採用できないことが多いから。
　もし字数や時間的に可能であれば、一般的な対策は、これと、あれと、それと、と複数ある。しかし、このプロジェクトでは、こうで、ああで、ほげほげだから、その中から最も可能性の高いこれを選択せざるを得なかったというような記述にすることで、より合格論文に近づくと思う。
　でも、これをやるには、最初の設問アでちゃんとそれを選択できない理由があるという説明がされてないと説得力が薄まってしまうので、そのあたりから考えて骨子を作る練習をしておく必要があると思う。設問アってただプロジェクトの特徴を説明するだけでしょ？と考えると痛い目をみると思うのは、そういう理由があるから。
　なぜリスクが顕在化して、なぜ複数ある対策の中から論述した対策を選択したのか、すべてはプロジェクトに特徴があるからそういう論述になるわけで、実は設問アというのは、論文を作成する上でかなり重要だと思う。
#divclass(h5){変更したことに対して発生するリスクを考慮する}
　これもすでに述べているのに簡単に。
　進捗遅延しました。その対策をするために作業工程を見直したり、ファストトラッキングして進捗遅延を挽回しました。めでたしめでたし・・・
　もちろんこの書き方では、どんだけ進捗遅延してるのか定量的でないし、なんでファストトラッキングを選択したのかわからないし、複数の案を検討してないからダメダメ論文になるわけど、それとは別に、そんなに簡単に作業工程を見直したりファストトラッキングして回復するなら、最初からしとけばいいじゃん。だってそのほうが早く終了するからいいでしょ？っていう話になってしまう。なんで最初にやっておかないの？ということに。
　つまり、プロジェクトは最初から正しくマネジメントされていて、でも不可抗力の問題が発生して、その対応策としてやむなく実施したみたいに成らざるを得ないと思う。その実施策は本来とは違うことを実施しているわけで、逆に言えばリスクを多少犯してでも、何かを守るべきために実施していることになる。だったら、その施策を実施することに対するリスクも考慮している姿勢を示せば完璧なものになると思う。
　でも、実際にはここまで書いている人は少なそうなので、もし字数が足りないとか、何か物足りないという場合に付け足しとして記述しておくといいと思う。例えば、要員を追加投入してクラッシングで進捗の挽回を狙うが、それは単体テストのみで実施し、実際にはテスト計画書に従って作業する要員なのでプロジェクトや要件に対する知識がなくとも実施できるから、みたいに記述すれば、ああそのリスクも理解していて、リスク低減できるから採用したんだなっていう話になる。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**文房具の評価
#divclass(h5){紙質}
　紙質は、午後1はマークシート用紙のような、わりと色が乗りやすいタイプの紙で応用情報の午後と同じような感じ。午後2はどちらかというと若干つるつるして色が乗りにくい感じだった。
　そのため、手の疲れ防止のため2Bを午後1で使うと非常に書きにくく文字が汚くなる傾向があるように感じた。しかし午後2は若干つるつるしているので、2Bでも十分に記述が可能だった。なので、手の疲れが激しい人は午後1をHB、午後2をBか2B（受験票にはHBかBを指定）などと使い分けたほうがいいと思う。
#divclass(h5){文房具}
　自分はパイロットの「ドクターグリップ　Gスペック」と三菱鉛筆の「ユニ アルファゲル　クルトガエンジン搭載タイプ」を利用してみた。
　ドクターグリップはとても重心のバランスが良く書きやすい印象があった。ユニアルファゲルのクルトガ搭載タイプも同様、書き心地は問題ないのだが、つかれにくさではドクターグリップのほうが上に感じた。
　しかし、実際に利用してみると、特に2Bの芯では、すぐに芯が減るので、どんどん文字が太くなってしまう。その場合にはクルトガ搭載タイプのユニアルファのほうが、常に芯のとがった部分を利用できるので、書き心地が維持され非常に書きやすかった。ところが、HBなどの堅い芯で午後2の論文の解答用紙のようなツルツルした紙に記述しようとすると、逆に芯のとがった部分のみ紙に接するため、芯のひっかかりを感じて書き心地がものすごく悪くなった。
　そのため、柔らかい芯→クルトガ搭載タイプ、硬い芯→ドクターグリップなどと使い分けたほうがいいと感じた。
　しかし、このあたりは書き方によっても随分違うと思うので、実際に試してリスクを軽減するか、異なる芯やシャープペンを複数持ち込むなどのリスク回避を検討したほうがいいと思う。
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**関連ページ
#ls3(情報処理試験まとめ)
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**参考書など
#divclass(h5){2016年おすすめの参考書等一覧}
#html2(){<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4798143243" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>}
#html2(){<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4797367709" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>}
#html2(){<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4534052014" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>}
#html2(){<iframe src="http://rcm-jp.amazon.co.jp/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=486280263X" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>}
#html2(){<iframe src="http://rcm-jp.amazon.co.jp/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=4873112990" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>}
#right(){&link_anchor(top){▲}&link_anchor(bottom){▼}}
**コメントを残す
- テストの投稿  -- 名前  (2011-08-15 18:20:55)
#comment
----
#right(){&lastmod()&aname(bottom)}
#right(){&trackback()}