プロジェクトマネージャ試験の勉強法まとめ午後2対策

プロジェクトマネージャ試験の勉強法まとめ 午後2対策
勉強テクニック 午後2
解答知識エリアの絞り込み
 仕事の合間に学習することを考えると、すべての知識エリアで論文を用意するのは時間的にかなり難しいと思う。なので過去問の出題傾向と自分の好みに合わせてエリアを決めて学習するのが望ましい(出題傾向はみよちゃん本に記載がある)。学習する分野を絞り込むと学習時間を大幅に短縮できるので積極的に検討してほしい。
 お勧めの知識エリアは、タイム、コスト、品質、人的資源の4つ。ここから非常に多く出題されている。次に重要なのはリスクと統合マネジメントだ。しかし、リスクマネジメントは、どんなリスクか明示されていなければタイムでもコストでもいいので前者の4つの知識エリアを流用できるので、わざわざ学習する必要はない。統合マネジメント(主に変更管理)は、それぞれの知識エリアで論文を記述する際にも関わってくる内容なのでこれも自然に学習ができる項目だと思う。
 というわけで、特に自分の好みがないのであれば、この6つ(正確にはタイム、コスト、品質、人的資源の4つに注力しつつリスクと統合マネジメントを意識しながら学習する)に的を絞って勉強しよう。
事前にプロジェクトを3つ用意しよう
 いきなり論文を記述するのは無理なので、事前にひな形となるプロジェクトを用意しておくと論文が書きやすくなる。ひな形となるプロジェクトは、問題に対して矛盾なく適用できるようにするために、少なくとも3つの異なるプロジェクトを用意しておくのが望ましい。
 例えば、「1次開発と2次開発をわけて開発するプロジェクト」とか「納期が間に合わなそうだから部分稼働を選択するプロジェクト」というような内容の問題だと、組み込み系の製品開発プロジェクトのストーリーは適用するのが難しい。「24時間の可用性が求められるシステム開発のプロジェクト」という論文を記述したい場合は24時間ユーザが利用しているWeb系などがわかりやすいし、「夜間のバッチジョブを必要とするシステムのプロジェクト」という論文なら、クラサバ型の業務システムのひな形を利用したほうが話が通りやすい。
 ちなみに、自分が用意したプロジェクトはこんな感じだ。
  • Webアプリを利用した業務システムの構築
  • Webアプリを利用した会員向け購買サイトの構築
  • クライアント-サーバ型のWindowsアプリケーションを利用した業務システムの構築
 プロジェクトの規模は固定させたほうが矛盾ない論文が書きやすいようだ。例えば開発期間:○○ヶ月、開発工数:○○人月、ピーク時の要員:○○人、チーム数:○○チーム体制、予算:○○万円という具合に固定し、チーム編成は自分がプロジェクトマネージャでチーム数は2ぐらいがわかりやすいと思う。予算、期間、工数、要員数が想像できないようであれば、そこを知ることから学習しよう。この学習方法はプログラマの単価をネットで調べたり、どの規模のプロジェクトなら工数はどれぐらいか?ということをネットで検索してみるのがいいだろう。
エディタの利用
 論文問題に必要な技術は、問題の解答力(構成力)と、手書き能力だ。しかし解答力と手書き能力は一致しない。最初から手書きで練習し疲れてしまうと飽きて面倒になってしまう。だから、ある程度できるようになるまで、エディタを使って構成力を養うほうがいい。それで慣れたら手書きで記述して長文を時間内で書く練習をするのが効率がいいだろう。
 使用するのはワープロでもエディタでもいいが、論文では文字数を気にする必要があるので、等倍フォントが利用でき行数が表示されるエディタがいいと思う。
 例えば秀丸エディタのようなものがお勧め。1行を25文字で記述すれば、4行で100文字。8行で200文字というように計算がしやすい。
勉強の流れ
 いきなり骨子やストーリーを作るのは苦労すると思うので、まずは過去問に対して「章立て」と「設問からの抽出」を作成してみよう。問題文に沿った章立てと問題文からの抽出を作るのが最初は少し難しいが慣れると簡単にできるようになる。これらができるようになったら骨子を作成し、次に実際に論文を記述するという流れになる。
  • 論文の勉強の流れ
    • SETP1 章立て
      • 設問から抜き出して章立てを作る演習
    • SETP2 問題文からの抽出
      • 作成した章に対して、それぞれ記述するべきことを問題文から抽出する
    • SETP3 骨子作成とプロジェクトの事前準備
      • 記述する論文の骨子を入れていく
    • SETP4 エディタでの論文の記述
      • エディタで実際に論文を記述する
    • SETP5 手書きでの論文の記述
      • 手書きで実際に論文を記述する
STEP1 章立て
 設問の文章から章立てをする練習を行うのがSTEP1。これは簡単なので何回かやれば簡単に章を作ることができるだろう。このあたりはエディタで短時間で済ませてしまおう。
 できるようになったらSTEP2へ進もう。
 このあたりの詳細な章立ての方法は後の解答テクニックに記述されているので参考にして欲しい。
STEP2 問題文からの抽出
 作成した章に対し、どのような記述をすればいいか、問題文から抜き出して記述していくのがSTEP2の問題文からの抽出だ。このあたりもエディタで簡単にできるようになる。
 このときに自分だったらどのような話にするか考えながら行うと、骨子が作りやすくなる。
 問題文からの抽出ができるようになったらSTEP3に進む。
 このあたりの詳細な設問からの抽出方法は後の解答テクニックに記述されているので参考にして欲しい。
STEP3 骨子作成とプロジェクトの事前準備
 ここでは作成した章立てと設問からの抽出に対して、記述する論文の骨子を作成していくのと、それと平行してプロジェクトの事前準備やストーリーを作成していくのがSTEP3だ。
 ここでは作成した章に対して、自分が記述する論文の骨子を入れていく。そのためにはプロジェクトをあらかじめ準備しておかないといけないし、おおまかな開発ストーリーも用意しておかなければ、実際に骨子を作ることができないので、骨子を作るのと平行してプロジェクトの事前準備の作業を行う。
 ここもエディタで骨子を作るようにすることで数をこなすことを優先しよう。
 過去の問題に対して簡単に骨子が作れるようになったらSTEP4に進もう。
 このあたりの詳細な骨子作成の方法は後の解答テクニックに記述されているので参考にして欲しい。
STEP4 エディタでの論文の記述
 いよいよ実際に論文を記述するのがSTEP4だ。
 こちらもエディタで、STEP3で作成した骨子を実際の文章に置き換えていくように記述していく。エディタを利用して記述する本数を優先していこう。
 試験の1週間前まではエディタでの演習で十分だ。最低でも5年分ぐらいの論文は記述しておきたい。
STEP5 手書きでの論文の記述
 いよいよ手書きで記述する練習をするのがSTEP5だ。最初は疲れるが、次第に慣れてくるので、試験前の1週間前ぐらいから、1日1本、実際に記述していこう。試験前日は手を休めるようにすること。
想定するプロジェクトの用意
 前述した事前に準備するプロジェクト、ストーリーは骨子の作成段階で用意していくのがいいだろう。
 実際には章立てと設問からの抽出をしながら、自分だったらこういう物語にするなと考えながら演習していくと、自分なりのストーリーが思いつきやすくなる。最終的にSTEP3の実際に論文を記述する前に、少しずつストーリーをブラッシュアップしていき完成させよう。
骨子作成中に手が止まったら
 骨子を作ろうとすると、プロジェクトマネジメントにおける知識において「こういう場合はどうなるんだっけ?」とか「もっと具体的な知識がないと解答できない」という部分が結構でてくるので、そうなったらネット等で知識を調べ、実例を参考にしながら骨子を積み上げていくといいと思う。
 例えば、よくあるパターンが品質に関する問題。ソフトウェアの品質を問う問題で「ソフトウェアの品質を保つには品質を作り込むためのプロセスと品質を確認するためのプロセスが重要である。品質を保つために、あなたはどのようなプロセスを組み込みましたか?」みたいなことが、さらっと書いてある。ここで重要となるのが「品質を作り込むためのプロセス」「品質を確認するプロセス」って何?ってこと。これは参考書等には記述されていないので、自分で学習するしかない。疑問に思った点がでてきたら、その都度調べて学習していこう。
 ちなみに「品質を確認するプロセス」は、機能性や使用性についてならレビュー、信頼性や効率性ならテストの実施などが該当する。
 それが理解できると、次に「じゃあレビューはどうやる?」「テストはどうやるの?」というように具体的なレビュー法、テスト法が知りたくなると思う。それらは応用情報等でも勉強するように、ウォークスルーとか、ラウンドロビンとか、インスペクションとか、ブレーンストーミングとか、ブラックボックステストとか、そんな知識と結びついていく。
  • 論文問題の学習の流れ
    • 「ソフトウェアの品質を保つには品質を作り込むためのプロセスと品質を確認するためのプロセスが重要である。あなたが関わったプロジェクトにおいて品質を保つためにどのような試作を取り入れましたか?」みたいな設問がある
    • 私は品質を保つために品質を作り込むプロセスを、こうこうこういうように工夫したみたいな話にしたい
    • 私は品質を保つために品質を確認するプロセスを、こうこうこういうように工夫したみたいな話にしたい
    • じゃあ、品質を作り込むプロセスと確認するプロセスの具体例を知らないと解答できないな・・・
    • 品質を保つソフトウェアの開発手法や確認する手法について学習しよう・・・
 このように論文の骨子を作ろうとするごとに「あ、この知識がないと書けないな」ということがわかってくるので、その部分をネットや参考書を利用して探す。これが重要。これが結構大変なのだが、過去問で一通り勉強すると新傾向の設問でない限り、ほとんど応用できるので合格率を確かなものにするためにはいいと思う。
骨子を用意して自分の黄金パターンを見つけるのが重要
 論文の骨子を考えていくと、自分の用意したプロジェクトパターンに合う骨子が貯まっていくと思う。
 骨子を作成していると自分の得意な黄金パターンがあることがわかってくると思う。そのパターンが理解できるようになると、論文の解答が楽になる。
 骨子を作るのは難しく、「明らかに自分たちに落ち度がある失敗で問題が発生した」という内容は自分たちのミスで発生したことなので骨子として採用しにくい。逆に、相手の都合により問題が発生したことにしたとしても、そのリスクをあらかじめ考慮してなかったの?という話になってしまい、これも骨子として採用するのはためらわれる。
 そうなると「予見することが不可能だが、しかし問題が発生してしまった」「事前にリスクを想定し事前対策を検討したけど実際に顕在化してしまった」という話にならざるを得ないと思う。骨子を作っていくと、たまたま失敗してしまったパターンみたいなものが見えてくるので、そういうパターンを見つけていくのが重要だ。
 例えばよくあるパターンだと思われるのがこのようなリスクだ。
  • ユーザ企業のキーマンが多忙、理解力不足で要件定義が進まない
    • 対処法:専任の担当者を任命することを要求したり、設計レビューにユーザ企業の人間を参加させたりとか
    • 用意するべきプロジェクト:理解力不足とかの設定ならWebアプリ形式に決定したがWebアプリについて詳しくないとかの設定に
  • ユーザ企業の経営方針変更で仕様変更が発生した
    • 対処法:上位管理者に相談したりとか、部分稼働するとか、別途予算を要求するとか
    • 用意するべきプロジェクト:部分稼働とかだとオープンを告知してしまったWebサイトの設定とか
  • 協力企業の要員の能力不足
    • 対処法:要員交代等
    • 用意するべきプロジェクト:基本的には何でもよさげだけど、クラサバ型のシステムが無難?
 このようなストーリーであれば骨子として比較的採用しやすいだろう。
原稿用紙を用意する
 手書きで練習する際には実際に原稿用紙を用意して記述するようにしよう。レポート用紙などに手書きで記述していると、どうしても文字サイズが異なるので本番時に違和感を感じてしまうからだ。
 本番の解答用紙は手に入れることができないが、サイズはA4でそこに400字を記述するような解答用紙なので、市販のA4サイズの400字詰め原稿用紙を購入して実際にそれで手書き練習をするのがおすすめ。実際にマス目の大きさにも違和感なかったし、本番に近い環境で練習できるのはきっとメリットがあると思う。
書けなかった漢字はメモる
 PCに慣れていると、手書きで漢字がなかなか書けなくなってしまっていることに気がつくと思う。
 論文の演習中にPCを使って文字を調べるのは良いとしても、それだけだとまた忘れて書けなくなる事が多い。なので、書けなかった漢字は、どこかにまとめてメモしておいたほうがいいと思う。で、あとから見直して漢字を勉強する。まったく書けなくなっているのなら、本格的に勉強する必要があるけれども、ちょっとど忘れしている程度ならば、あとから見直せば思い出せるはずなので、メモしておいて、本格的な学習に利用したり、試験前日に見直して記憶を呼び覚ましておくようにしたほうがいいと思う。
解答テクニック 午後2
論文の書き方
章立て
 論文は最初に問題を読んで、それから設問を理解して解答しようとすると、解答する内容がブレてしまうことが多い。そこで、最初は問題を読まず、どんな解答を求められているか設問から章立てをすることがぶれない解答をする近道だ。
 例えば、平成19年の問1だとこんなかんじ。問題文を読まずに設問だけで章立てするとこんな感じになる。過去問はIPAのサイトからダウンロードできる。
1 私が携わったプロジェクトについて
1.1 私が携わったプロジェクトの概要
1.2 関係者との交渉が必要になった問題と背景
2 問題解決の手順と合意に至った解決策について
2.1 問題を解決するための手順
2.2 交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
3 施策の評価と今後の改善について
3.1 手順と解決策についての評価
3.2 今後どのように改善したいと考えているか
 これが求められている内容をすべて網羅した章立て=論文の流れとなる。場合によっては問題文を読むことで多少は変化してくることもあるが、90%ぐらいはこのままの構成が利用できる。こうすることで問われている内容から大きく乖離することなく解答できるし論文を構成することができる。
問題文からの抽出
 章立てをすることでどのような論文の流れになるか道筋が見えたと思う。次は具体的に何を記述すればいいかをまとめる必要がある。
 みよちゃん本にも書かれているように、このような午後2では「あなたはプロジェクトマネージャですよね?なら、実際にこういう経験していますよね?そういうときこんなことをしていますよね?そのときどう考えてどう行動したんですか?」のように聞かれている。これらの具体例は、実は問題文の中に記述されている。なので、それを問題文からピックアップして構成した章立ての中に記述していく。
 具体的にはこのような感じだ。同じく平成19年の問1。
1 私が携わったプロジェクトについて
1.1 私が携わったプロジェクトの概要
1.2 関係者との交渉が必要になった問題と背景
 ※利用部門や協力会社に関わるような関係者との問題が発生
 ※開発範囲の認識が異なる、リスク顕在化で納期遅延が発生
2 問題解決の手順と合意に至った解決策について
2.1 問題を解決するための手順
 ※関係者と状況の認識を合わせる
 ※問題の本質を理解して、選択肢を複数立案して、優先順位を付け、最善方法をみつける
2.2 交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
 ※相手との要望が異なり、互いに妥協する過程
3 施策の評価と今後の改善について
3.1 手順と解決策についての評価
 ※もちろん顧客が満足で終了
3.2 今後どのように改善したいと考えているか
 ※さらにこうすればよかったという記述
 このように問題文から抜粋して各章に割り振ることで、具体的にどんなことを記述すればいいのかが見えてくるので、あとはこの具体例に合わせて骨子を作るだけだ。
骨子の作成
 次に作成した章立てに従ってストーリーを考える。最初からいきなりかくと後から整合性がとれなくなることがあるので、骨子を考えてから書き始めるのがお勧めだ。具体的には、問題選択に5分、章立てや骨子の作成に15分、残りの90分で書き上げて、残りの10分をチェックに使用する感じがベストだと思う。90分で書き上げるのは手書き能力で、15分で骨子を作るのは構成力だ。。
 では、実際にどんな感じでストーリーを作るのか。具体的にはこのような感じで作成していく。同じく平成19年の問1。ここまでくると問題文をみなくても章立てを見るだけで論文が作れる。実際の試験では、これを記述すると時間がかかるので、問題文にアンダーラインを引いたり、章番号を書いたりすることで対応しよう。
1 私が携わったプロジェクトについて
1.1 私が携わったプロジェクトの概要
 ▼基幹業務システムの開発 保守契約切れに併せて再構築のため遅延許されない
1.2 関係者との交渉が必要になった問題と背景
 ※利用部門や協力会社に関わるような関係者との問題が発生
 ※開発範囲の認識が異なる、リスク顕在化で納期遅延が発生
 ▼ユーザ企業から口頭で伝えたという仕様変更の要求がありリスク顕在化
2 問題解決の手順と合意に至った解決策について
2.1 問題を解決するための手順
 ※関係者と状況の認識を合わせる
 ▼伝えていたつもりが、自社では把握せず、どちらの責任にもならないという結論に
 ▼変更しないと業務に使えないが、それを変更すると時間がないという認識は一致
 ※問題の本質を理解して、選択肢を複数立案して、優先順位を付け、最善方法をみつける
 ▼複数立案したが、弊社としては納期を遅延してもらうしかないという結論
2.2 交渉時の双方の主張、説得した内容、譲歩した内容、合意した解決策
 ※相手との要望が異なり、互いに妥協する過程
 ▼顧客はとりあえず納期だけはなんとかして欲しいという要求
 ▼幸い、仕様変更部分は月集計に関する部分なので、最初の1ヶ月では必要の無い機能。部分稼働はどうか?
 ▼顧客も同意し、まずは日次機能を稼働させ1ヶ月以内に月集計機能を実装で合意
3 施策の評価と今後の改善について
3.1 手順と解決策についての評価
 ※もちろん顧客が満足で終了
 ▼無事うまくいきますた
3.2 今後どのように改善したいと考えているか
 ※さらにこうすればよかったという記述
 ▼そもそも口頭うんぬんが問題なのでそれを解決できればよかった
論文の流れの必勝パターン
 プロジェクトマネージャ試験の論文を読んでいくと「だいたいこんな流れの解答を期待しているんだろうな?」というのがわかってくる。そのあたりが理解できるとしめたもので、難なく解答ができるようになると思う。
 それが、この論文のおおまかな流れの必勝パターンだ。具体的には、こんな感じの流れになっている。
  • あるプロジェクトがある
  • そのプロジェクトのはある特徴がある
  • その特徴のためプロジェクトにはリスクが内包している
  • リスクが顕在化しないように事前対策を複数検討し選択する
  • でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった
  • さらに対策を検討する
  • でもリスクが顕在化してしまった
  • そのために事後対策を複数考えて選択する
  • リスク回避できたが予定と違うことをしたので、別リスク発生の可能性
  • その予防策も考える
  • うまく収まってめでたしめでたし。でもこうすればもっとよかったかも
 骨子を作ったら、そこから話を膨らませていくわけだが、基本的にはその骨子の結論やストーリーの道筋をたどるために、字数や設問に合わせて、上記の黄金パターンからいくつかを選択して解答するようにする。こうすると、簡単に肉付けができるし、PMとして考えた理由も記述することができる。
 しかし、論文中では、これらすべての解答が求められているとは限らない。例えば、「絶対に納期が許されない状況。なぜか納期遅延の可能性がでてきた。どうしましたか?」みたいな論文を求められているとする。この場合では事前対策や兆候の発見までは問われていない。いきなり納期遅延リスクの顕在化であり、その顕在化したリスクに対する対応策だけを回答として求められている。すると、こういうパターンを選択することになる。
  • ○あるプロジェクトがある ←これは設問アとして絶対に存在する
  • ○そのプロジェクトのはある特徴がある ←これは設問アとして絶対に存在する
  • ×その特徴のためプロジェクトにはリスクが内包している ←いきなりリスク顕在化なので問われず
  • ×リスクが顕在化しないように事前対策を複数検討し選択する ←いきなりリスク顕在化なので問われず
  • ×でも、その特徴が原因で、どうしても回避できないリスクの兆候を発見してしまった ←いきなりリスク顕在化なので問われず
  • ×さらに事前対策を検討する ←いきなりリスク顕在化なので問われず
  • ○でもリスクが顕在化してしまった  ←問われている内容
  • ○そのために事後対策を複数考えて検討する  ←問われている内容
  • ▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性 ←あるとなお良い
  • ▲その予防策も考える ←あるとなお良い
  • ○うまく収まってめでたしめでたし。でもこうすればもっとよかったかも ←これは設問ウとして問われる可能性アリ
 ○は必須に解答すべきこと。最初の二つの○は問アに該当する部分。
 ▲は記述するとなお良いけど、場合によっては字数がたりなくなるので必要に応じて追加する部分。
 ×は合否に関係しないからスルーする部分。
 このようにパターンを選択したら、選択したパターンに対して論文に記述する骨子を埋め込んでいく。すると、このような感じになる。
  • ○そのプロジェクトのはある特徴がある
    • Webアプリを利用した基幹システム。かつ納期遅延が許されない
  • ○リスクが顕在化してしまった
    • Webアプリに詳しくなく操作性に関する要件定義が進まなくなって遅延しそう
  • ○そのために事後対策を複数考える
    • 案1 要件定義を円滑に進ませるために要件定義の責任者の設置を顧客に求める
    • 案2 プロトタイプ手法を採用
  • ○プロジェクトの特徴を考慮して、その複数の案から最善案を選択する
    • ユーザにとってもっともわかりやすいと思われるからプロトタイプを選択
  • ▲リスク回避できたが予定と違うことをしたので、別リスク発生の可能性
    • プロトタイプ手法の採用でかえって作り込みが増え遅れないか?
  • ▲その予防策も考える
    • あくまで操作性に限定したプロトタイプにするよう両社で合意
  • ○うまく収まってめでたしめでたし
 このような必勝パターンの考え方に従って、問題発生の理由、プロジェクトの特徴、その解決法をうまく組み合わせると、旨い具合に論文が肉付けできると思う。
章中の流れの必勝パターン
 もう一つのパターンが一つの章の中で記述すべきパターン。
 みよちゃん本でも記述されているようにシステムアーキテクトの論文でなく、プロジェクトマネージャの論文なので、マネジメントする立場になって論文を記述していかなければならない。そのためには、以下のようなパターンを多様するとマネジメントっぽい感じになる。
 具体的にはこんな感じ。
  • ある問題が発生した(発生しそう)
  • 原因を調査した
  • その原因に対する対策として○○を実施させた
  • なぜなら○○が○○だから○○だと考えたからである
 たったこれだけだ。具体的な論文では、このような感じになる。
  • ある問題が発生した(発生しそう)
    • 納期遅延が発生しそう
  • 原因を調査した
    • 調子したところ今回の開発で使用するテクノロジでの開発経験の無い要員が多かった
  • その問題に対する対策として○○を実施させた
    • そこで経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら○○が○○だから○○だと考えたからである
    • なぜなら勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
 こうすると、かなりプロマネっぽい論文になるがどうだろうか?
 例えばこんな感じでは後者のほうがやはりよく見える。
  • 納期遅延のリスクが顕在化しそうだった
  • そこで経験者に新人の教育を実施させた
  • その後進捗が挽回しはじめ最終的に納期が守られた
  • 納期遅延が発生しそう
  • 調査したところ今回の開発で使用するテクノロジでの開発経験の無い要員が多かった
  • そこで経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
知識を散りばめる
 これで体裁は整ったが、さらに知識をちりばめてアピールすると、より合格論文に近くなる。
 具体的には、実施した施策の根拠となるツール、理論、必勝法などを記述する。そうすると、前章の例もグッと厚みが増してくる感じにみえるのが不思議だ。
 実際に記述するとこのような感じになる。
  • 納期遅延が発生しそう
  • 各チームリーダや現場の人間から本音を聞き出すため個別にミーティングを実施し、特性要因図を利用して原因を分析した
  • その結果、今回の開発で使用するテクノロジでの開発経験の無い要員が多かったことが主な原因であることがわかった
  • これらの対処には要員交代したり、開発要員を同室で作業させるなどの改善なども考えられる
  • しかし、今回は経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら、ただちに経験豊富な要員を集められることは現実的でないからである
  • そして勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
  • また過去の類似プロジェクトの結果から要員教育の効果で成功した例が多くこの例が参考になると考えたからだ
 このような感じでどんどん加筆して知識をいれていく。すると、よりしっかりした論文に見えてくる。
 特に分析手法やツールはいろんな場面でちりばめる知識として利用できる。そのため、それらを暗記しておくことが重要になる。そしてここで「必勝パターン」がでてくることになるのだが、やはり「必勝パターン」の暗記は重要だと思う。
 論文中に使える必勝パターンは例えばこのようなものだ。
  • 発生確率・影響度マトリクス
  • インスペクション、ウォークスルー、ラウンドロビン
  • デルファイ法、過去の類似案件からの類推
  • 特性要因図、パレート図
  • ミーティング、個別面接
定量的な解答をする
 知識をちりばめるのと同様に、所々に定量的な表現を入れることも大事だと。数字が入ると説得力が増すからだ。だけど、実際の論文との内容で矛盾が生じるかもしれないので結構難しいところだと思う。
 例えば定量的な表現をいれるとこんな感じになる。
  • 納期遅延が管理上限の進捗10%以上の差違が発生しそう
  • 各チームリーダや現場の人間から本音を聞き出すため個別にミーティングを実施し、特性要因図を利用して原因を分析した
  • その結果、今回の開発で使用するテクノロジでの開発経験の無い要員が多かったことが主な原因であることがわかった
  • これらの対処には要員交代したり、開発要員を同室で作業させるなどの改善なども考えられる
  • しかし、今回は経験者がサポートしたり、週に二回勉強会を開き技術を習得させるようにした
  • なぜなら、ただちに経験豊富な要員を集められることは現実的でないからである
  • そして勉強会に時間がとられるが、技術習得が遅れると後々に重大な遅延になりかねず、早期に実施すべきだと考えたからである
  • また過去の類似プロジェクトの結果から要員教育の効果で成功した例が多くこの例が参考になると考えたからだ
  • 実際に過去の例では勉強会の実施で一時的に5%の進捗率低下となるが、その後持ち直し、対策をしない場合より10%の納期短縮されていた
 この例は割合で記述しているが、具体的な工数や金額で答えられれば、そのほうが良い。
 以下のような言葉が、定量的な言葉として使いやすい。
  • 進捗率、工数、ステップ数
  • レビューの指摘件数、指摘密度
  • テスト数、密度、網羅率
  • 不具合の発見件数、発見密度
  • レスポンス時間、バッチの処理時間、システム停止時間、要望された機能の実装率
検討した結果を複数用意する
 これはすでに今までの中の話で取り上げているので短く説明する。
 問題発生時の対策には一般的には複数が考えられる。しかし、そのうち対策として実施するのは一つか二つのことが多いと思う。それは他に考慮すべき事柄があって、採用できない対策であることが多いからだ。
 もし字数や時間に余裕があれば、「一般的な対策は対策A、対策B、対策Cと複数の対策ある。しかし、このプロジェクトにはこのようなプロジェクト特有な特徴があるので対策Aを採用することになった」という記述にすることで、より説得力が増す論文になる。
 しかし、このような記述するためには、最初の設問アでプロジェクトの特徴としてしっかりと特有の特徴が記述されていないと説得力を失ってしまうので、そのあたりも考えて骨子を作成する練習をする必要があるだろう。
 なぜリスクが顕在化してしまい、そしてなぜ複数ある対策の中から特定の対策を選択したのか、すべてはプロジェクトに特徴があるからそういう論述になるわけで、実は設問アというのは、論文を作成する上でかなり重要だ。
変更したことに対して発生するリスクを考慮する
 これもすでに述べているのに簡単に解説する。
 顕在化しそうな問題や、発生してしまった問題に対して事後対策を行って問題を解決しようとするわけだが、そもそも「事後対策」は本来は行う予定でない対策で、本来の予定を変更して特別に実施していることになる。このように本来とは違うことを実施しているわけだ。従って、それを実施することで新たなリスクを抱えてしまう可能性が考えられる。
 そのため論文では追加して実施した施策に対し、その施策が悪影響を及ぼさないよう別の対策を考えておく必要がある。その施策を実施することで抱えるリスクに対する事前対策を論文に盛り込むことで、より説得力のある論文になるし、字数を多く記述できない人にとっては、絶好の文字数稼ぎになる。
解答用紙や文房具の評価
解答用紙への工夫
 実際の試験では、解答用紙として週刊誌や青年漫画誌のように紙が二つ折りにされ、真ん中がホチキスで留められている冊子が配られる。ちょうど、IPAの各試験の午前、午後の問題冊子のような形状である。その1ページに400字詰め原稿用紙のマス目が印字されている。つまり1ページの裏表に両方記述をすることになる。紙質は厚手の原稿用紙のような感じで、多少、つるつるした感じである。
 ここで二つの問題が発生する。
 一つは裏移りの問題である。1ページの裏表に記述するので、表を書いた後に裏を記述すると表に書いた時が裏移りしてしまうのである。下敷きが使えればいいのだけど、持ち込んでいい筆記用具に下敷きは含まれていないため利用できない。なので特に筆圧の強い人、濃い鉛筆を使うと汚くなってしまい、採点者の印象も悪くなりかねないという懸念がある。
 二つ目の問題は書き心地が変化してしまうことである。説明が難しいけど、週刊誌の表紙に文字を書こうとすると、机と表紙の間に何枚も紙があるので、当然、書き心地は柔らかい。ところが、裏表紙に文字を書こうとすると、今度は机と裏表紙の間には紙が一枚もなく、机と直接接しているので、書き心地が堅くなる。前述の通り解答用紙も週刊誌のように二つ折りにされているので、1ページずつ記述をしていくと、書いてる紙と机の間の紙の枚数が変化してしまう。この変化が以外と苦痛で、このおかげで手が痛くなったりする。そこで、完全に解答冊子を折り返してしまい、机と記述している紙の間の枚数を一定にさせるようにすると変化が無くていいと思う。よく、満員電車で新聞の読みたい面を折り返して読んでいる人が居るけど、あの要領。単語帳やスケッチブックのようにくるっと裏側に一周させるイメージ。
 ところで関係ないが、会場によっては、かなり机の状態が酷いこともあるようだ。特に古いテーブルで木目がデコボコしているようなところもあるらしい。そういうところはボール紙が配布され、それを下敷きがわりに使うように指示されるらしい。このような可能性も考えて、シャープペンの芯などは異なる硬さのものを用意するとかするといいかもしれない。
紙質
 紙質は、午後1はマークシート用紙のような、わりと色が乗りやすいタイプの紙で応用情報の午後と同じような感じ。午後2はどちらかというと若干つるつるして色が乗りにくい感じだった。
 そのため、手の疲れ防止のため2Bを午後1で使うと非常に書きにくく文字が汚くなる傾向があるように感じた。しかし午後2は若干つるつるしているので、2Bでも十分に記述が可能だった。なので、手の疲れが激しい人は午後1をHB、午後2をBか2B(受験票にはHBかBを指定)などと使い分けたほうがいいと思う。
文房具
 自分はパイロットの「ドクターグリップ Gスペック」と三菱鉛筆の「ユニ アルファゲル クルトガエンジン搭載タイプ」を利用してみた。
 ドクターグリップはとても重心のバランスが良く書きやすい印象があった。ユニアルファゲルのクルトガ搭載タイプも同様、書き心地は問題ないのだが、つかれにくさではドクターグリップのほうが上に感じた。
 しかし、実際に利用してみると、特に2Bの芯では、すぐに芯が減るので、どんどん文字が太くなってしまう。その場合にはクルトガ搭載タイプのユニアルファのほうが、常に芯のとがった部分を利用できるので、書き心地が維持され非常に書きやすかった。ところが、HBなどの堅い芯で午後2の論文の解答用紙のようなツルツルした紙に記述しようとすると、逆に芯のとがった部分のみ紙に接するため、芯のひっかかりを感じて書き心地がものすごく悪くなった。
 そのため、柔らかい芯→クルトガ搭載タイプ、硬い芯→ドクターグリップなどと使い分けたほうがいいと感じた。
 しかし、このあたりは書き方によっても随分違うと思うので、実際に試してリスクを軽減するか、異なる芯やシャープペンを複数持ち込むなどのリスク回避を検討したほうがいいと思う。

  • 最終更新:2017-12-29 14:59:56

このWIKIを編集するにはパスワード入力が必要です

認証パスワード