システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(2)
2.汝平和を欲さば、戦への備えをせよ
彼我の状況がわかったところで、次は準備の話に入ります。
何を欲するのか？
前回書いたように、準備は状況と自身とのギャップを埋めるためにするものなので、何を目的として準備するかは結構重要です。
例えば私にはこういうギャップがありました。
| # | ギャップ | 概要 |
|---|---|---|
| 1 | 場数 | IPA論文試験はおろか、試験で小論文を書いたことがほとんどない。論文書きそのものの場数を増やしたい。 |
| 2 | ネタの蓄積 | 論文ネタが重要と言われるが全くストックがない。書けるネタを増やしたい。 |
| 3 | 型を身につける | IPA論文はどういうスタイルで書けば良いのか、スタイルを身に着けておきたい。 |
| 4 | ジャンル内テーマ対応力 | エンベデッド問で種々のテーマが問われても、無難に回答できるようになりたい。 |
| 5 | ジャンル間テーマ対応力 | エンベデッドで全く回答できないテーマが提示された場合、エンプラ系で回答できるようになりたい。 |
1～3は基本的には論文記述数によって影響を受ける箇所で、ここは論文の数をこなしていけば自然に対応できるようになります。
一方、4と５については論文のテーマ依存の問題(『出題テーマリスク』)に対応するための準備で、こっちは論文のテーマを様々変えていくことが必要になってきます。
特にエンベデッド系は1問しか出題されないので、エンプラ系に比べてジャンル間テーマ対応力の需要は大きいです。
私自身も今ほど明確に認識していたわけでもないのですが、この辺は何とかしておきたいなーとおぼろげに考えていました。
最初の論文を書く
こういう問題意識を抱えた状態で午後2試験に関するTACの講義を受けました。
http://www.tac-school.co.jp/kouza_joho/joho_crs_sa_hon.html
TACはTACで論文記述のノウハウを持っていて、『ステップ法』という考え方で論文を書くように提案しています。
あんまり書くとTACの商売敵になってしまうので、細かいところは書きませんが、
- 最初に章立てを考え
- 次に問題文から思いつく論述ネタを考え
- 論述ネタに対応する事例を取り出し
- 論述ネタと事例の整合性を確認した上で
- 展開、論述する
というやり方ですね。
ここから何本か論文を書くことになるのですが、上記の流れを意識して論文を書いていくと、全く何もない状態で書き始めるよりも随分と楽にはなります。
とはいえ、この知識があっても実際に論文がスラスラ書けるようになるわけでもなくて、やはり自分の力で論文を導出して、初めて有効な訓練になります。
一方で、論文を書きなれない状態で最初の論文を書くのはなかなかのハードルなので、まずは 過去問で最も解きやすいと思った問に対して、PCで論文を記述するのをいくつか繰り返すのが良いと思います。
google先生の力を借りてもいいし、後から構成を変更するのもありです。とにかくまず最低1本、PCで自分の論文を書き上げましょう。
最初は2時間以上かかるかもしれませんが、全く問題ありません。
最初は手書きに拘るのではなく、
- 一定の構成を有する論文を完成させること
- 規定以上の字数を実際に書いて、コンテンツのボリュームをつかむこと
- 論文の記述を通して、論文書き(論述ネタの展開)の実感をつかむこと
形式に関係なく、上記を達成出来るようになるのが大事です。
複数の論文を書く
1本書けたら、エンプラ得意ならエンプラ系で、エンベデッド得意ならエンベデッド系で、別のテーマの過去問を選んで、同じようにPCで論文を書きます。
ジャンル内で複数書けるようになったらジャンルをまたぎます。エンプラ得意ならエンベデッド系を。エンベデッド得意ならエンプラ系を。
TACでは、『文章得意な人は3本、苦手な人は5本ぐらい書いておきましょう』と言われたのですが、天邪鬼な私は『じゃあ私は10本ぐらい書けばいいかな』と思いまして。
結局その半分、5本ぐらいはPCで書いています。
最低限の評価基準と具体的なコンテンツの対応関係
じゃあそろそろ、具体的な論文例の話をしましょう。
前回、論文の評価基準として
- 設問で要求した項目の充足度
- 論述の具体性
- 内容の妥当性
というピックアップをしたと思います。
内容の妥当性は、誰が見ても嘘だと思うような内容を書くな 、ってことで、これは言わずもがな。
まだ書き始め、しかも経験のないエンプラ系ですが、当時書いた叩き台ということで、私の習作を例示してみようかなと思います。
テーマは平成27年度午後2問2。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2015h27_2/2015h27a_sa_pm2_qs.pdf
私の論文答案(習作)はこちら。
http://dimeiza.hatenablog.com/entry/2016/12/24/210952
設問で要求した項目の充足度
結論から言ってしまうと、 設問で要求された項目はまず章立てで保証する のが一番、というかほぼ唯一の解だと思います。
設問の記載をピックアップしてみましょう。
設問ア あなたが携わった情報システムにおいて、 業務機能の変化または追加を必要とするような業務の課題 はどのようなものであったか。対象となった情報システムの概要 、及び 業務の概要 とともに、800字以内で述べよ。
設問イ 設問アで述べた 業務の課題に対応するために、どのような業務機能の変更または追加 が必要となったか。 業務の課題に対応できると考えた理由 とともに、800字以上1600字以内で具体的に述べよ。
設問ウ 設問イで述べた業務機能の変更または追加の際、既存機能の活用や既存の情報システムへの影響の最小限化のために、どのような工夫をしたか、600字以上1200字以内で具体的に述べよ。
太字で書かれているのが、『設問で要求した項目』です。この項目全てに対して答えた論文のみが、合否判定の俎上に乗る、と言って良いと思います。
私の習作では、この要求項目に対して章立てで備えています。
- 第1章 業務機能追加、変更の対象とした情報システム : 設問ア
- 1.対象となった情報システム及び業務の概要： 対象となった情報システムの概要、業務の概要
- 2.機能変更または追加を必要とした業務課題： 業務機能の変化または追加を必要とするような業務の課題
- 第2章 業務機能の変更と追加：設問イ
- 1.具体的な変更、追加機能： 業務の課題に対応するために、どのような業務機能の変更または追加が必要となったか。
- 2.課題への対応性について： 業務の課題に対応できると考えた理由
- 第3章 機能変更、追加時の工夫：設問ウ
- 1.既存情報システムへの影響最小化： 既存の情報システムへの影響の最小限化のために、どのような工夫をしたか
- 2.既存機能の活用： 既存機能の活用のために、どのような工夫をしたか
こういう章立てをしておいて、『じゃあ第1章の1でカレーライスの作り方を書こう』とはあまり思わないわけです。章立てで何を書くべきか定義しておいて、それが設問の要求事項と完全に合致していれば、設問で要求された項目に気づいていながら書き落とす、ということはあまりなくなります。
もちろん、『設問の要求事項を読み落とす』ということがあってはならないので、本試験では線を引くなどして、読み落としがないようにはしておきましょう。
論述の具体性
この問題における関心事は、既存システムへの機能変更、追加とそれに対する工夫なわけですが、私の習作では、機能変更、追加のネタとして具体的な事案を2つ持ってきています。
- 機能変更ネタ:販売者ごとのカスタマイズ機能。
- 購入後にツイートしたり、独自の広告を表示する。
- 機能変更ネタ:販売結果のレポーティング機能。
- 販売実績を解析し、品揃えを最適化したい。
『柔軟な機能追加にあたってはDecoratorパターンを使うと有効であり…』みたいな一般論を展開せず、個別具体的な事例にしている点がポイントです。
ここで、設問の要求事項から具体的な事例に結びつけることが鍵なんですが、このためのキーワードこそが、『論述ネタ』って奴です。
『既存システムへの機能変更、追加』と聞くと、経験豊富なSE各位は、例えばこんな事を思いついたりしませんか？
- 入力、処理可能なデータ項目を増やしてほしい
- 出力結果に特定の情報を加えてほしい
- 他のシステムと連携できるようにしてほしい
あるあるだと思いますが、この言葉を並べるだけだと一般論でしかありません。ところが、
- ECサイトで新たに他事業者のポイントを取り扱うことになり、ポイント種別の入力機能追加を要望された。
- 購入処理後には購入金額だけを表記していたが、新たに配送日を出力するように要望された。
- 自サイトで販売している商品だけでなく、他のマーケットプレイスサイトの出品物も商品リストに加えられるように要望された。
と言ってしまうと、これはもう一般論ではありません。『ECサイトの機能追加』として、もう個別具体的な事例なんですね。
ここで、前回話をした、観点や事例を一般論ではなく、自身の知見に関連づけよに関する説明もしてしまうと、論述ネタとしては、実は問題文に書かれていることを使ってしまっても良いわけです。
- 受注内容の変更と、各業務機能の起動タイミングの変更
- 出荷指示機能から呼び出されるサブ機能の追加
これだけだと一般論なんですが、
- ECサイトでの購入後、ユーザからの変更と取り消し指示を出荷1時間前まで可能にするべく、出荷処理起動タイミングを後ろにずらす
- ECサイト購入後の出荷指示処理において、運送業者の繁忙に応じて採用業者を変更する業者選定サブ機能を作る
と言ってしまうともう一般論ではない、と。
特に問題文の論述ネタは論文内容の発散を防ぐためのものとも言われているので、自分が持っている具体的な事例に展開できるのであれば、1つぐらい使ったほうが良いとはTACでも言っていたりします。
習作で使っている事例
ここまで説明した辺りで、『あれ？ この筆者ってエンベデッド系メインで、エンプラ系の経験ないって言ってなかったっけ？』と思いだした方もいらっしゃるかと思います。
そう。これ、私が経験した事例ではありません。というか、これはあるイベントでの講演をもとにした私の創作です。
元ネタはこちら。ここで話された内容を大分脚色して、習作を作っています(ちなみにCommerbleさんと私には何の関係もなく、ネタ元と習作の技術的な整合性も一切ありません。念のため)
Developer’s summit 2016 Summer Webサービスベンダーのビジネスを支える足回り
https://www.commerble.com/contents/devsumi2016
エンプラ系メインの方はエンベデッド系の、エンベデッド系メインの方はエンプラ系の論文を書こう、という話をしましたが、経験がないものをどうやって書くかは課題でして。
私はこの手のイベントに参加することが多く、このセッションも直接聞いていて、実際その場でツイート機能の追加とかをしていたので、問題文をしばらく見て使えそうだなぁ、と思って題材にしてみました。
こんな感じで、1.設問の要求事項、2.論述ネタ、3.論述ネタに適合する事例、の順で手繰っていくと、論文にしっくりあった題材を当てはめた上で、具体性を伴って要求事項に章立てで答えた文章を誂えることができるんじゃないか、と思います。
ここまでのまとめ
- まずはPCで書いてもいいので、自分の論文を作って完成させる。
- 1本書いたら複数のテーマ、ついで他方のジャンルへ。
- 設問の要求事項には章立てで備える。
- 一般論(論述ネタ)を揃えつつも、一般論のままでは書かない。個別具体的な事例で説明する。
- 論述ネタに合致した経験や伝聞を取り出し、論文に対応した事例とする。
こんな感じですかね。ここまでで最小限の(採点してもらえる)論文の書き方に対する取り組みとアプローチについては書けたかなと。
ここから私は手書きに入るのですが、手書きには手書きの気づきがあり、そこでもう1段階、読みやすい(読ませる)論文について考えることになります。
以下、次号。
