2022年10月31日

2010年度(平成22年度) プロジェクトマネージャ(PM)の論述問題(午後II問題)の合格解答の補足

前回の記事では2010年度(平成22年度) プロジェクトマネージャ(PM)の論述問題(午後II問題)の合格解答を晒してみました。
この内容について、AEのやつと同様、少し補足してみたいと思います。

■ テーマの選択について
「リスク対応計画」というテーマの問題を選択し、「携帯電話機向けのWeb閲覧アプリケーションの開発」というプロジェクトをについて記述しました。
これ、どこかで見たことありますよね、覚えてますか?
そうです、2008年度(平成20年度) アプリケーションエンジニア(AE)の論述問題(午後II問題)の合格解答で書いたのと同じプロジェクトです。
同じプロジェクトの内容を、AEとPMの2つの論述試験のネタに使い回したわけです。

こういう使い回しできるネタをストックしておくと、楽できると思います。
(というか自分はこの1つのネタしか用意していませんでしたがw)


■ 自分の役割について
「私はZ社のプロジェクトマネージャとして、開発に携わった。」と書いてますが、当然実際は違いますw。
普通に開発メンバでした。

それでも、あえて「プロジェクトマネージャとして開発に携わった。」と主張するのが論述試験のポイントですね。
プロマネ経験なくても、創作で書いていくわけですね。

「プロジェクトマネージャ」の論述試験なわけなので、「開発メンバーとして開発に携わった」とか書いてしまうと「題意を満たしていない」ということになってしまい、合格からはだいぶ遠ざかると思います。


■ 「プロジェクトの特徴」の内容
前述の通り、以前に受けたAEの論述試験で書いたプロジェクトのネタをそのまま使い回しました。
AEのときは「X社」にしてましたが、今回は「通信事業者A」も登場するので、A, B, Z として「B社」として登場させました。
「通信事業者A」は、スケジュールについての納得感のある説明をするためだけに持ち出しました。
(あと文字数稼ぎのためでもありますw)

■ 「リスク要因」の内容
これも、以前に受けたAEの論述試験で使った「Web閲覧アプリケーションのフレームワーク」を持ち込みました。
「リスク1.」として書いたのが丸々AEのときの内容ですね。
他に「エンジンの品質低下」も持ち出しましたが、これは問題文にある「〜リスクとしては、例えば、以下のようなものがある」に記載されてやつそのままですね。

このように、題意を満たすネタをちゃんと論述内容に含めておくのが重要になります。


■ 字数の制限について
以前書いた通り、「〜字以上〜字以内」とかは、「行数」でのカウントと考えて問題ないはずです。
そして、今回は時間ギリギリで、設問ウを書いているときに「残り1分」とかで極限状態で超焦りながら書いてました。
その結果、「アプリケーション」を「アプリ」と省略して書いたりしてたのですが、その結果「600字」に足りなくなりそうになり、苦肉の策で「 以上。」とかいう謎の1行を仕込んでギリギリ字数制限をクリアしました。

これで合格しているので、アリということですね。

仮に、最後まで書き終わらず時間が来て試験終了になっていたりすると、危うかったと思います。
無理やりにでも「仕上げる」というのは合格に向けては結構大事です、最後まで諦めない。

----

以上、補足でした。参考になれば。

応援よろしくお願いします!
posted by でっき at 00:43 | Comment(0) | TrackBack(0) | プロジェクトマネージャ

2022年10月30日

過去の論述問題(午後II問題)の合格解答を晒してみる - 2010年度(平成22年度) プロジェクマネージャ(PM)

2008年度(平成20年度) アプリケーションエンジニア(AE)の論述問題の合格解答に引き続き、今回は2010年度(平成22年度) プロジェクマネージャ(PM)の論述試験の合格解答を晒してみようと思います。
前回と同様、完全に書いた内容を暗記しているわけではないので、当時のメモ書きをベースに書き出してみたというものになります。



【問題】
IPAのサイトの過去問題のページから、問題冊子のPDFをDLできます。

3問あるうち、私は 問1 を選択しました。
最初に問1の内容をざっと見て「これいける!」と思ったので、問2と問3はサラッとだけ見てすぐ問1に決めた記憶があります。

過去問題のページから削除されてしまう可能性があるので、念のため抜粋して以下に書いておきます。

問1 システム開発プロジェクトのリスク対応計画について

プロジェクマネージャ(PM)には、システム開発プロジェクトのリスクを早期に把握し、適切に対応することによってプロジェクト目標を達成することが求められる。
プロジェクトの立ち上げ時にリスク要因が存在し、プロジェクト目標の達成を阻害するようなリスクが想定される場合、リスクを分析し、対策を検討することが必要となる。

プロジェクトの立ち上げ時に存在するリスク要因と想定されるリスクとしては、例えば、次のようなものがある。

・採用した新技術が十分に成熟していないことによる品質の低下
・未経験の開発方法論を採用したことによるコストの増加
・利用部門の参加が決まっていないことによるスケジュールの遅延

PMは想定されるリスクについては定性的リスク分析や定量的リスク分析などを実施し、リスクを現実化させないための予防処置や、万一現実化してもその影響を最小限にとどめるための対策などのリスク対応計画を策定し、リスクを管理することが重要である。

あなたの経験と考えに基づいて、設問ア〜ウに従って論述せよ。

設問ア あなたが開発に携わった開発プロジェクトの特徴とプロジェクト目標について、800字以内で述べよ。

設問イ 設問アで述べたプロジェクトの立ち上げ時に存在したリスク要因とプロジェクト目標の達成を阻害するようなリスクは何か。また、リスク分析をどのように行ったか。800字以上1,600字以内で具体的に述べよ。

設問ウ 設問イで述べたリスク分析に基づいて策定した予防処置や現実化したときの対策などのリスク対応計画と、その実施状況および評価について、600字以上1,200字以内で具体的に述べよ。



【解答】
設問ア あなたが開発に携わった開発プロジェクトの特徴とプロジェクト目標について、800字以内で述べよ。
※ 文字数が計算しやすいよう、実際の解答用紙と同じ「1行=25文字」で書いています。

           1111111111222222
  1234567890123456789012345
01 1.プロジェクトの特徴
02  Z社は組み込み機器向けのWeb閲覧システムの開発
03 を行っており、主に携帯電話向けの事業をメインとして
04 いる。B社は製造メーカーであり、通信事業者A向けの
05 携帯電話を開発している。以前から、B社の携帯電話機
06 はZ社のWeb閲覧システムを搭載しているが、Z社か
07 らはWeb閲覧システムエンジンのみを提供し、アプリ
08 ケーションはB社が独自で開発していた。今回、B社が
09 コスト削減のため、Z社にアプリケーショも込みでWe
10 b閲覧システムを提供するよう要求し、Z社はエンジン
11 のみでなくアプリケーションも一緒に提供することとな
12 った。私はZ社のプロジェクトマネージャとして開発に
13 携わった。
14 2.プロジェクト目標
15  通信事業者Aは毎年決まった時期に携帯電話機を販売
16 しており、本プロジェクトの携帯電話機についても、販
17 売時期が確定している。そのため、B社の携帯電話機の
18 納期厳守は必達であり、Z社としてもWeb閲覧システ
19 ムの提供について納期を厳守しなければいけない。
20  また、Z社としては今までのエンジン提供のみとは違
21 い、アプリケーション込での提供することになるため開
22 発規模が多くなる。開発人員も多くなるが、コストを確
23 実に予算内に抑えるよう、事業部長より指示があった。
25文字×23行=575文字ですね。指定の800文字以内です。
ちょっと少なめな気もしますが、まあこれで合格したわけなので、題意に沿った「プロジェクトの特徴」「プロジェクト目標」がきちんと記述されていれば問題ないと思います。


設問イ 設問アで述べたプロジェクトの立ち上げ時に存在したリスク要因とプロジェクト目標の達成を阻害するようなリスクは何か。また、リスク分析をどのように行ったか。800字以上1,600字以内で具体的に述べよ。
※ 文字数が計算しやすいよう、実際の解答用紙と同じ「1行=25文字」で書いています。

           1111111111222222
  1234567890123456789012345
01 [リスク要因と想定されるリスク]
02 1.<リスク要因>Z社にはWeb閲覧アプリケーショ
03 ン用のフレームワークがあるためそれを使おうとしたが、
04 チーム内に経験者が不足していた。
05 <想定されるリスク>開発コスト増加
06 2.<リスク要因>Web閲覧システムのエンジンの最
07 新版の品質が不十分
08 <想定されるリスク>不具合多発による開発コスト増加、
09 納期の遅延
10 3.<リスク要因>Web閲覧アプリケーション用フレ
11 ームワークに最新バージョンのエンジンを組み合わせた
12 実績がまだない
13 <想定されるリスク>品質の低下、不具合発生時のエン
14 ジン/フレームワーク/アプリケーションのどの部分が
15 原因かの切り分けのコストが増大
16 [リスク分析の内容]
17 <1.のリスクについて>
18  過去にWeb閲覧アプリケーション用フレームワーク
19 を使ったプロジェクトの関係者にヒアリングを実施した
20 結果、過去にWeb閲覧アプリケーション用フレームワ
21 ーク利用者向けの技術講義が行われており、その時の講
22 義内容がビデオに録画されていたことが分かった。また、
23 要望があればフレームワーク開発チームのメンバによる
24 技術講義を行うことも可能とのことだった。
25  これらの情報をもとに、過去の技術講義のビデオを使
26 った勉強会を行い、状況に応じて追加の技術講義の依頼
27 を出すことを検討した。
28 <2.のリスクについて>
29  Web閲覧システムのエンジン開発チームにヒアリン
30 グし、以下の情報を入手した。
31 ・エンジンの最新版より1つ前のバージョン(旧版)は
32 安定している
33 ・もう数ヶ月すれば最新版も安定する見込みである
34 ・エンジンのAPIについてはほとんど変更がないため、
35 旧版から最新版にバージョンを上げる際にはアプリケー
36 ション側はほとんど変更が不要
37  これらの情報から、ひとまずは旧版のエンジンを使っ
38 て開発を行い、最新版が安定したあとで差し替えを行う
39 のがよいと判断した。もし最新版の安定化が予定通り進
40 まない場合は、旧版のまま出荷することを検討した。
41 <3.のリスクについて>
42  Web閲覧アプリケーション用フレームワークの開発
43 チームにヒアリングを実施し、以下の情報を入手した。
44 ・エンジン側でAPIの変更がほとんどないのであれば、
45 フレームワークと組み合わせたことで発生する不具合の
46 ほとんどはエンジン側のはず
47 ・旧版のエンジンとフレームワークの組み合わせでは、
48 採用実績が多く既知の不具合はないため、品質は安定し
49 ている
50  これらの情報をもとに、2.のリスクと同様、ひとま
51 ずは旧版のエンジンを使って開発を行い、最新版が安定
52 した後に差し替え行うのが良いと判断した。
25文字×52行=1300文字です。指定の800字以上1,600字以内に収まっています。
見出しを[xx]と書いたり、項目を見やすくするため<xx>と書いたり、「・」を使って箇条書きにしたりと、記号をうまく使ってています。
実際の本番でもこのように書きました。
字数稼ぎというのも少しありますが、このような形式で書いたほうが圧倒的に見やすくなると思います。
逆にこれらの記号を一切使わないで記述するとなると、だいぶ見づらくなるのではないでしょうか。


設問ウ 設問イで述べたリスク分析に基づいて策定した予防処置や現実化したときの対策などのリスク対応計画と、その実施状況および評価について、600字以上1,200字以内で具体的に述べよ。
※ 文字数が計算しやすいよう、実際の解答用紙と同じ「1行=25文字」で書いています。

           1111111111222222
  1234567890123456789012345
01 [リスク対応計画]
02 1.<予防処置>フレームワーク利用者向けの技術講義
03 ビデオで勉強会を行うよう、技術リーダに指示
04 <リスクへの対策>技術講義ビデオだけで不足する部分
05 について、フレームワークチームに技術講義を依頼
06 2.と3.<予防処置>旧版のエンジンを使ってアプリ
07 ケーションを開発し、最新版が安定したあとに差し替え
08 るようにする
09 <リスクへの対策>最新版のエンジンの安定化が遅延し
10 た場合は、旧版エンジンのままで出荷する
11 [実施状況と評価]
12  1.については、過去のフレームワーク技術講義ビデ
13 オによる勉強会を行ったおかげで、スケジュール通りに
14 進めることができた。もしこの勉強会を行わなかった場
15 合には、相当苦労したであろうと技術リーダから話がき
16 ており、うまくリスク低下できたと思う。また、開発工
17 数も削減でき、コストを予算内に納めることができた。
18  2.と3.については、最新版のエンジンの開発が遅
19 れており、品質が安定化しなかった。旧版を使ってアプ
20 リケーション開発を行っていたため、アプリケーション
21 開発のスケジュールへの影響は出ていない。もし最新版
22 のエンジンを使っていた場合、エンジン側の不具合のせ
23 いでアプリケーションの実装ができなかったり、不具合
24 の切り分けなどで余計な工数がかかり、スケジュール遅
25 延が発生してたと思われる。
25文字×25行=625文字です。指定の600字以上1,200字以内に収まっています。ギリギリですがw
実際の本番では、時間がギリギリで本当に焦っていて、「アプリケーション」を「アプリ」と書いたりしていた記憶があります。
その結果、「600字以上」の指定の文字数が足らず、ギリギリラインの24行目に「 以上。」みたいなのを入れて無理やり誤魔化しましたw
本当に焦りましたね、「 以上。」の「。」を書いた瞬間に、試験官から「はい、やめてください。筆記用具を置いてください。」と言われた記憶があります。
ヒヤヒヤもんですね。
無理やり感がありますが、これでも合格してるので「アリ」ということだと思います。最後まで諦めないのが大事ですね。



以上、記憶を掘り起こして、書き出してみました。内容的にはほぼこんな感じで書いていたと思います。

実際には、本番ではAEの時と同様、
・字は汚く、
・おそらく誤字脱字もあり、
・さらに漢字書けなくて平仮名で書いたり
・文字数制限を満たすためだけのの苦しい「 以上。」だけの行があったり
と、とても読みづらい酷いものだったと思いますが、
採点官がちゃんと内容読んで採点してくれたことに感謝するしかないですね。

長かったですが、以上、2010年度(平成22年度) プロジェクマネージャ(PM) の午後IIの合格解答でした。

応援よろしくお願いします!
posted by でっき at 02:19 | Comment(0) | TrackBack(0) | プロジェクトマネージャ

2022年10月28日

2008年度(平成20年度) アプリケーションエンジニア(AE)の論述問題(午後II問題)の合格解答の補足

前回の記事では2008年度(平成20年度) アプリケーションエンジニア(AE)の論述問題(午後II問題)の合格解答を晒してみました。
この内容について、少し補足してみたいと思います。

■ テーマの選択について
「フレームワークの利用」というテーマの問題を選択し、「フレームワーク」として「自社開発のWeb閲覧アプリケーションのフレームワーク」というものを選択して論述しました。
2022年現在だと、スマホにChrome とか Safari とか当たり前にように入っていますが、ガラケー時代はそんなことはなかったわけですね。

この「フレームワーク」としては、通常だともっと一般的なもの、例えば
・Webフレームワーク向けの Ruby on Rails、ASP.NET、Angular、Vue.js、React など
・ネイティブアプリ開発向けのXamarin、 React Native、Flutter、 Electronなど
が思いつくと思います。
テームとしてこれらを選択するのも良いと思います。

自分は業務経験から「自社開発のフレームワーク」を選んだというだけですね。
きちんとフレームワークの説明ができていれば問題ないと思います。


■ 自分の役割について
「私はZ社のアプリケーションエンジニアとして、開発に携わった。」と書いてますが、当然実際は違いますw。
そもそも「アプリケーションエンジニア」という役職というか肩書の人自体少ないのでは?
「プロジェクトリーダー」とか「リードエンジニア」とかそういう表現のケースもあると思います。

それでもあえて「アプリケーションエンジニアとして開発に携わった。」と主張するのが論述試験のポイントですね。
「アプリケーションエンジニア」の論述試験なわけなので、「開発メンバーとして開発に携わった」とか書いてしまうと「題意を満たしていない」ということになってしまい、合格からはだいぶ遠ざかると思います。
(2022年現在の試験制度だと「システムアーキテクト」ですね、適当に読み替えてもらえれば)


■ 「課題と認識したこと」の内容
「課題」がどういうものであり、どのように対策を行ったか、またその結果の評価と改善点、というのが論述内容のメイン部分になってくるわけですが、自分が書いたのは以下の3つでした。
・[課題1] X社の要求事項を確認したところ、フレームワークの機能の一部についてX社が要望する機能が不足しており、機能変更が必要
・[課題2] プロジェクトメンバのうち、フレームワークの利用経験者が少なく、精通しているメンバがほとんどいない
・[課題3] フレームワークの特定の利用パターンにおいて、性能が著しく悪化するケースがあることが判明し、 本プロジェクトにおいてそれが該当してしまうことが判明した

過去に実際にそういうことがあったか?というと、全く同じというものはないですね。
似たようなことはありましたが、論述試験向けに書きやすい形に簡略化したり創作したものになっています。
まあ試験なんでそんなもんですね。
過去の似たような経験をもとに、題意に当てはまるものをでっち上げる、というのが論述試験では重要になるのかと思います。

例えば「フレームワークがとても素晴らしく、チームメンバもそれに精通しており、課題と認識できるものは全く無かった」とかいう大成功プロジェクトが過去に実際にあったのだとしても、その時のことについて論述試験で書いてしまうと、これまた「題意を満たしていない」ということになりますね。


■ 字数の制限について
段落を分けたり、「[課題1の対策]」だけの行を作ったりと、字数稼ぎしてるっぽく見えますが、実際には「見やすくするため」というのが目的ですね。
採点官も人間なので、びっちり詰め詰めで書いてあるものよりも、適度にスペースを設けて書いてあるほうが読みやすいはずで、心象もよくなるはずです。

「〜字以上〜字以内」とかは、「行数」でのカウントと考えて問題ないはずです。
実際、プロジェクマネージャ(PM) の論述試験では「設問ウ」で「600字以上1,200字以内」となっており、ギリギリ600字の24行目のところまで書いて時間切れになりましたが、無事に合格していました。
実際の「字数」をカウントすると明らかに600字未満でしたが、合格していたということは「600字の行まで使われていればOK」とみなして良いと思います。

----

以上、補足でした。参考になれば。

応援よろしくお願いします!

2022年10月27日

過去の論述問題(午後II問題)の合格解答を晒してみる - 2008年度(平成20年度) アプリケーションエンジニア(AE)

では、前回の記事での予告通り、過去の論述問題の合格解答を晒してみようと思います。
といっても、完全に書いた内容を暗記しているわけではないので、当時のメモ書きをベースに書き出してみたというものになります。

まずは、2008年度(平成20年度) アプリケーションエンジニア(AE) です。


【問題】

3問あるうち、私は以下の 問2 を選択しました。
理由としては、当時は組み込み系のソフトウェア開発をやっていたので、
「DMBS」「業務システム」「Webアプリケーション」「データウェアハウス」
とかがテーマだと、全く業務経験がなくて何を書いてよいか分からず、手が出せないんですね。
この年は「フレームワークの利用」というとても抽象的なテーマがあったので、
組み込み系のソフトウェア開発の経験をもとにして書くことができました。
(確か問1と問3は手が出せない系のテーマだった記憶があります)

IPAの過去問題のページ からは消されてしまっているようなので、問題内容を以下に書いておきます。

以下のサイトを参考にさせていただきました(感謝!)
https://katzchang.hatenadiary.org/entry/20090901/p2

問2 フレームワークの利用について

最近、システム開発にフレームワークを利用するケースが増えている。フレームワークを効果的に利用することができれば、対象システムの品質を確保し、生産性向上が期待できる。

ただし、フレームワークの利用においては、例えば、利用方法の習得時間の短縮、機能や性能面での制約への対応、機能の利用方法に関する開発者間のばらつきの統制、業務機能の効率の良い設計・開発などの課題に直面することがある。

アプリケーションエンジニアは、これらの課題を解決するために、利用するフレームワークの経験者や専門家の協力を得ながら、次のような対策を実施しなければならない。

・利用方法の習得時間を短縮するために、専用の開発支援環境や利用ガイドを整備する。
・機能や性能面での制約に対応するために、フレームワークの一部をほかのフレームワークや独自に作成したソフトウェアなどで代替する。
・機能の利用方法に関する開発者間のばらつきを統制するために、利用規約を作成して周知徹底を図ったり、利用する機能に制限を加えたりする。
・業務機能を効率よく設計・開発するために、フレームワークに基づいて、業務機能用のテンプレートや業務共通の機能を設計・開発し、各業務機能の設計・開発でそれらを利用する。
・これらの対策を、システムの規模、要求される性能や信頼性の水準などのシステムの特性、開発要員のスキルなどを考慮して、効果的に実施しなければならない。

あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

設問ア あなたが開発に携わったシステム、及び利用したフレームワークの概要について、800字以内で述べよ。

設問イ 設問アで述べたフレームワークを利用するために課題と認識したことは何か。また、それらの課題を解決するために、システムの規模、システムの特性、開発要員のスキルなどを考慮して、どのような対策をどのように効果的に実施したか。重要と考えた点を中心に、具体的に述べよ。

設問ウ 設問イで述べた対策について、あなたはどのように評価しているか。また、今後、改善したい点は何か。それぞれ簡潔に述べよ。

※設問アは800字以内、設問イおよび設問ウは1600字以上3,200字以内で記述。



【解答】
設問ア あなたが開発に携わったシステム、及び利用したフレームワークの概要について、800字以内で述べよ。
※ 文字数が計算しやすいよう、実際の解答用紙と同じ「1行=25文字」で書いています。

           1111111111222222
  1234567890123456789012345
01 1.システムの概要
02  Z社は組み込み機器向けのWeb閲覧システムの開発
03 を行っており、主に携帯電話向けの事業をメインとして
04 いる。
05  Web閲覧システムは、エンジン部分とアプリケーシ
06 ョン部分に明確に分かれている。エンジン部分は共通機
07 能開発チームが開発・保守を行い、各プロジェクトで共
08 通で使えるようになっている。アプリケーション部分は
09 各プロジェクトチームで個別に開発を行い、アプリケー
10 ション固有の機能追加などのカスタマイズなどを行って
11 いる。
12  X社は携帯電話機の製造メーカーであり、今回Z社の
13 Web閲覧アプリケーションを搭載することになった。
14 私はZ社のアプリケーションエンジニアとして、開発に
15 携わった。
16 2.フレームワークの概要
17  Z社ではWeb閲覧アプリケーションの開発に便利な
18 フレームワークが用意されており、このフレームワーク
19 には一般的なWeb閲覧アプリケーションが必要とする
20 機能を網羅している。例えばURL入力、閲覧履歴、ペ
21 ージの戻る・進むの機能、ブックマーク機能、ページの
22 保存機能、画像の保存機能、などである。これらはどの
23 プロジェクトでも通常必要とされるものであるので、フ
24 レームワークとしてまとめられており、これを利用する
25 ことで開発コストを節約することが可能である。
26  X社向けのプロジェクトにおいても、このフレーム
27 ワークを使って開発することになった。
25文字×27行=675字ですね。指定の800字以内です。
途中で段落を分けてるのは決して行数稼ぎwではなく、見やすくするためです。


設問イ 設問アで述べたフレームワークを利用するために課題と認識したことは何か。また、それらの課題を解決するために、システムの規模、システムの特性、開発要員のスキルなどを考慮して、どのような対策をどのように効果的に実施したか。重要と考えた点を中心に、具体的に述べよ。
※ 文字数が計算しやすいよう、実際の解答用紙と同じ「1行=25文字」で書いています。

           1111111111222222
  1234567890123456789012345
01 1.フレームワークを利用するための課題
02 Web閲覧システムのフレームワークを利用するにあた
03 り、私は以下の3点の課題があると認識した。
04 [課題1]X社の要求事項を確認したところ、フレーム
05 ワークの機能の一部についてX社が要望する機能が不足
06 しており、機能変更が必要
07 [課題2]プロジェクトメンバのうち、フレームワーク
08 の利用経験者が少なく、精通しているメンバがほとんど
09 いない
10 [課題3]フレームワークの特定の利用パターンにおい
11 て、性能が著しく悪化するケースがあることが判明し、
12 本プロジェクトにおいてそれが該当してしまうことが判
13 明した
14 2.課題の解決のために実施した対策
15 [課題1の対策]
16 プロジェクト固有の要件による機能変更をフレームワー
17 クに適用してしまうと、それまでの動作実績が失われ、
18 品質低下のリスクが考えられ、他のプロジェクトへの影
19 響が発生してしまう。そのため、今回はX社からの要求
20 内容をよく分析し、フレームワークの既存機能をそのま
21 ま活用できる部分と、X社向けに新規に開発する部分を
22 組み合わせて要求を実現することにした。その結果、新
23 規APIの開発を追加で行う必要はでてきたが、フレー
24 ムワーク本体に変更を適用することが無くなるため、品
25 質低下のリスクを避けつつ、要求を満たすことができた。
26 [課題2の対策]
27 過去にフレームワークを使って成功したプロジェクトの
28 担当者にヒアリングを実施し、フレームワーク利用にお
29 ける開発効率をどのように向上させたのかを確認した。
30 その結果、そのプロジェクトでもフレームワーク利用経
31 験者が少なかったため、フレームワーク利用者向けの講
32 習会が行われてことが判明した。さらに、そのときの講
33 習会の内容がビデオで保存されていることが分かったた
34 め、そのビデオを活用し、本プロジェクトのメンバー向
35 けにも同様の講習会を実施した。
36 [課題3の対策]
37 フレームワークの性能が悪化するケースについては既知
38 の問題ではあったが、特定の利用パターンでのみ発生す
39 る問題であり、実際のプロジェクトでは過去に発生する
40 ケースはなかったが、本プロジェクトで初めて発生して
41 しまった。フレームワーク自体を修正する必要があるが、
42 知識不足のため利用するだけで精一杯で、プロジェクト
43 チームだけでは対応が困難であった。そこで、フレーム
44 ワーク開発チームの支援を借りられるようプロジェクト
45 マネージャに依頼し、調整をしてもらった。その結果、
46 以下について協力してもらえることになった。
47 (1)フレームワークのどの部分が性能悪化の原因にな
48 っているかの解析ポイントを提示してもらう
49 (2)プロジェクト側担当者からの質問への対応や、実
50 際にコードを見ながらの分析のサポートなどの対応
51 (3)実際に修正したコードのレビュー会への参加
25文字×51行=1275字です。
「設問イおよび設問ウは1600字以上3,200字以内」とあるので、2つ足して1600字が最低ラインですね。
設問イが「具体的に述べよ」、設問ウが「簡潔に述べよ」とあるので、
イ:ウ=3:1 ぐらいの割合とし、イ=1200字以上、ウ=400字以上ぐらいを目標で書いてました。結構ギリギリですねw。まあ本番はこんなもんだと思います。時間無くてめっちゃ焦るし。

※ 現在のシステムアーキテクト(SA)だと、設問イ、設問ウ のそれぞれで字数指定があるようですね。昔のアプリケーションエンジニア(AE) はそのあたり雑だったようですw


設問ウ 設問イで述べた対策について、あなたはどのように評価しているか。また、今後、改善したい点は何か。それぞれ簡潔に述べよ。
※ 文字数が計算しやすいよう、実際の解答用紙と同じ「1行=25文字」で書いています。

           1111111111222222
  1234567890123456789012345
01 1.評価
02 (1)課題1について
03 X社からの要求そのままの機能変更をフレームワークに
04 適用せず、既存機能の活用と新規API追加で対応する
05 ことができたので、品質を確保しつつ、開発効率を向上
06 させることができた。
07 (2)課題2について
08 フレームワークについての技術講習を効率よく行うこと
09 ができ、プロジェクトメンバの技術力を向上させること
10 ができたとともに、開発効率も向上させることができた
11 と思う。
12 (3)課題3について
13 フレームワーク開発チームの協力を得ることができ、性
14 能悪化の問題についても無事に解決することができた。
15 2.改善点
16 (2)課題2について
17 フレームワークの講習会のビデオの存在は、過去のプロ
18 ジェクトの担当者に確認するまで知らず、このようなも
19 のは会社全体でもっと共有化し、有効活用すべきと思う。
20 (3)課題3について
21 フレームワーク開発チームが既知の問題を修正せず後回
22 しにしていた結果、実際のプロジェクトで急遽修正する
23 必要が出てきてしまい、スケジュールに影響が発生する
24 リスクがあった。本来はフレームワークは常に安定化さ
25 せた状態にし、利用する上でのリスクが無い状態を維持
26 するのが望ましい。今回のプロジェクト側の成果をもと
27 に、性能向上をフレームワーク開発チームに依頼した。
25文字×27行=675字です。前述の通りの目標文字数は超えています。
設問イと設問ウで合計で 1225 + 675 = 1900 なので、まあ文字数としては問題ないですね。
(空白があるから全部詰めたら1600字いかないんじゃ?とか心配かもですが、「行数」でカウントしてるはずです)
実際は、漢字とかちゃんとかけなくて平仮名で書いたりもしてたと思います("急遽" とか絶対書けない自信がありますw)。



以上、記憶を掘り起こして、書き出してみました。内容的にはほぼこんな感じで書いていたと思います。

実際には、本番では
・字は汚く、
・おそらく誤字脱字もあり、
・さらに漢字書けなくて平仮名で書いたり
と、とても読みづらい酷いものだったと思いますが、
採点官がちゃんと内容読んで採点してくれたことに感謝するしかないですね。

長かったですが、以上、2008年度(平成20年度) アプリケーションエンジニア(AE) の午後IIの合格解答でした。

次の記事では 2010年度(平成22年度)春季のプロジェクトマネージャ(PM) の合格解答を晒してみたいと思います!

応援よろしくお願いします!

2022年10月25日

久々のブログ更新!

しばらくぶりのブログ更新です!
12年ぶり!?

情報処理技術者試験は、2010年春のPM合格後は、以下のような感じでした。
・2010年度(平成22年度)秋期試験で「ITストラテジスト(ST)」に 不合格w
・2011年度(平成23年度)特別試験で「情報セキュリティスペシャリスト(SC)」に 合格!
(「特別試験」というのは、この年は 3.11 の影響で「春期試験」が延期になり別名として実施されたものですね。ここ を参照。)

で、その後は試験を受けるのはやめてしまいました。
ちょうど転職した時期で、もういいかな、と。
ITストラテジストは論述問題まで準備したのに、なんと午前IIで 56点でという悲惨な結果になり、やる気失ったというのもありますねw
結構対策したのに、甘かったようです…。
論述試験とかめちゃくちゃ時間かけたのに 採点すらされない という悲しさw

----

せっかくなので、転職活動と情報処理技術者試験の関係(?)について、書いてみます。

結論から言うと、資格を沢山取得してたおいたので、転職活動は全く困りませんでした
というのも、リクナビNEXTなどの転職支援サイトでは履歴書に取得資格を記載する欄があるんですね。
ここに大量の情報処理技術者試験の資格を記載することになるので、他の転職者と差別化が図れるわけですね。

企業の人事担当者も、転職エージェントも、この資格欄をよく見ています。
おそらく「xxの資格保持者」とかでフィルタかけて候補者を探しているはずなので、資格が多いほど検索にヒットするわけですね。
もちろん資格持ってりゃいいってわけでもないですが、スキルセットや業務経験が似たような人材がいた場合、
多くの資格を持ってる方に声をかけたくなるのではないでしょうか?
資格自体が重要というよりは、「資格取得に向けて自己啓発する人」と判断されているんだと思いますね。

転職活動は新卒の就職活動とは違って、いわゆる「エージェント」経由で活動するのが基本になってきます。
良い条件の会社の案件を沢山持ってきてくれるんですね。
非公開案件というエージェント経由でないと応募できないものも多数あります。

そんで、このエージェントから声がかかると、色々やりやすくなるわけです。
自分の場合、前述の通り資格をモリモリ記載したので、10社ぐらいのエージェントからオファーがかかりました。
それと、興味あるなし関わらず、企業からも結構な数の直接オファーがきてました。
これ、結構普通じゃないぐらいの数らしいですね。よく知らんけど。
気付かなかったけど、リクナビNEXTって「今月のトップオファー取得者」みたいのがあるようで(2011当時はありました、今は知らない)、
そこの月間トップ10に入ってましたね、自分(そんなランキングあること自体知らなくて後から気付いたのですがw)。

結果、結構な高待遇の会社に転職で滑り込むことができたので、沢山資格取得しておいてよかったな、と思いました。
あとエージェントさんにも感謝。

そんなわけで、情報処理技術者試験も取得しておけば損することはないですね。
努力した分、ちゃんと報われます。

----

ということで、このブログはもう終了な予感wなのですが、
せっかくなので、今後は過去の論述問題(午後II)の解答を晒していってみようと思います。

実際に合格したときの解答になるので、参考になるのではないかと思います。

といっても、完全に書いた内容を暗記しているわけではないです(そんな頭脳はないw)。
当時のメモ書きがあるので、これをベースに書き出してみるという感じになります。

2008年度(平成20年度)秋期のアプリケーションエンジニア(AE)と、
2010年度(平成22年度)春季のプロジェクトマネージャ(PM)のものになります。
(「アプリケーションエンジニア(AE)」 は現在の制度では「システムアーキテクト(SA)」に該当します)

だいぶ古い時期の内容ですが、まあ本質的な部分は変わらないはず、と思います。

ということで乞うご期待!

応援よろしくお願いします!
posted by でっき at 21:07 | Comment(0) | TrackBack(0) | 雑記