システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(3)
3.謀多きは勝ち…
PCで論文を何本か書いた私は、ぼちぼち手書きで論文を書いてみることにしました。
論文を手書きで書く
言うまでもなく最も本番に近い環境での訓練になりますが、手書きはPCでの論文書きと比較して以下の点が異なります。
| # | 相違点 | 概要 |
|---|---|---|
| 1 | 記述が大変(手が疲れる) | 初回でも触れましたが3000字近く書くことになるので結構疲れます。 |
| 2 | 全体が見えづらい | PCと違って記述内容が1画面に収まることはなく、原稿用紙複数枚にまたがるので見通しが悪いです。 |
| 3 | 構成の修正が困難 | カット・アンド・ペーストすることもできないので、一度記述した構成を大きく変更するのは不可能に近いです。 |
| 4 | 字の上手い下手 | 下手な字で書くと読みづらくなります。 |
| 5 | 漢字 | IMEの力を借りることは出来ません。自力で正しく漢字が書けるかが問われます。 |
端的に言うと、コンテンツの作成にあたってPCよりもずっと自由度が低く、制約された環境になるわけです。
この環境制約は結構重要な事で、この制約によって逆に論文作成時に工夫を強いられることになります。リソースが限られているので、限られたリソースの中で最大限の効果を得ようとして工夫するわけです。
以下、私が手書きをしていく中で自然と行っていた工夫と効果を挙げていきたいと思います。
- 章立てを含む論文設計は必ず本文記述前に行う
- 走りながら考える
- 記述後に確認する
章立てを含む論文設計は必ず本文記述前に行う
前回、設問で要求された項目はまず章立てで保証するという話をしたと思いますが、逆に言うと、設問の要求事項が分かっていれば、章立ては本文執筆前に行えるということでもあります。
これ自体はそんなに難しいことではなく、機械的に行うことができます。
ここでポイントとなるのは、設問で要求された項目の章立てだけではなく、各章、節において記述すべき論述ネタと事例の配置も、ここで行っておくべきということです。
例えば
実際に私が手書きで論文演習したときのメモでも。
題材は平成21年度システムアーキテクト試験午後Ⅱ問3。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2009h21_2/2009h21a_sa_pm2_qs.pdf
以下が演習時に記述したメモ。ちなみに、この時の演習ではこのメモ書きも含め、1時間40分ぐらいで論文記述を完了しています。
…いやぁ…あまりの悪筆で、書いた本人にもよく読めませんね。お恥ずかしい。
ということで何が書いてあるか、解読しつつ整理してみます。
- 第1章 私が携わった組込み製品の概要
- 1.製品の概要
- 2.外部調達の課題
- 暗号ライブラリの調達
- 高セキュリティ
- 高速演算
- 開発スケジュール対要員
- 第2章 外部調達の課題について
- 第3章 外部調達への評価
- 1.評価した点について
- スケジュール的:OK 結合もうまく行った
- コストは大きい(調達+サポート)
- 移植性はHALでOK 保守性は低い
- 製品としては成功 将来に課題
- 2.残した経験
- 自らメンテナンスできないリスク
- スケジュール的にも待ち
- 妥当な実装かどうか
- 転用移植しづらい
- 暗号はコア(技術)なので
- 今後はなるべく自社開に
言葉足らずだったところを補うと、だいたいこんなことが書いてあります。
この目次を見て、筆者がこの事例でどういう検討をして、どういう外部調達を行い、どういう経験と結論を得たのか、本文を読まなくてもだいたい分かるかと思います。
こういうふうに、目次でストーリーを作っちゃうわけです。これが論文設計って奴です。システムアーキテクトの午後Ⅱでは、ソフトウェアではなく論文のアーキテクチャ設計が必要となるわけです。
そして、これを最初に書くことが極めて重要です。なぜなら、冒頭に示した制約の通り、手書き環境下での論文は本文全体の見通しが悪い上、一度記述した論文構成を時間内に大きく変更することはほぼ不可能だからです。
論文設計は、その論文における『設問で要求した項目の充足度』と『論述の具体性』のベースを作り込む行為なので、ぶっちゃけた話、この論文設計の段階で勝敗はほぼ決まってしまうんじゃないかと思います。
論述ネタの配置
とは言うものの、問題文から目次を作るのはいいとして、論述ネタをどう配置するのか、ってところはなかなか悩ましいところです。
要はストーリーと合致した論述ネタをどう配置するか、ってことなんですが、ここには3つぐらいポイントが有るのかなと。
論述ネタを揃える
まず、そもそも論述ネタが出てこないと配置も何もないわけです。
あるお題が出た時に幾つかの論述ネタ(キーワード)が浮かぶ状態にしておきたいところですが、これについては、
- 普段からしている当たり前の課題と解決策を意識的に覚えておく
- 論文のPC記述を通しながら、自分の暗黙経験を文章化しておく
手書きするまでにこの2点を励行しておけば、おそらく1年間に出題される3問中のどれかの問題には、特に意識せずとも論述ネタを過不足なく展開できるようになっているはずです。
それでもキツイ、という方は、問題文から論述ネタを取り出して自分の事例に結びつける作戦を意識しましょう。
上記事例だと、問題文自身にネタそのものが親切に列挙されています。
- コスト
- 開発スケジュール
- 性能、信頼性、保守性
- 将来の再利用性
例えばこの観点から自分の事例を個別具体化できるのであれば、そこが取っ掛かりになります。
きれいなエンディングに持っていく(大団円 or 将来への展望)
TACでは『事例はなるべく成功例に。失敗例にすると原因やら対策やらを記述しなければならず長くなる』と言われました。
最後がバッドエンドだったり締まらなかったりすると、悪い読後感を試験官に残すことになりますし、論理に基づく一貫した主張もしづらくなります。
このため、論文の最後をキレイに締めるようにする(すべての課題、問題を解決する or 設問で要求されている場合は将来展望を述べる)ようにするとよいです。
論述ネタの伏線化と回収
最後が締まっている、ということは、論文で展開した論述ネタや課題は最後には解決されている、ということです。であれば、
- 序盤(設問ア)で解決の目処が立っている課題を配置し
- 中盤(設問イ)で課題に対する論述ネタを配置、検討し(または解決し)、
- 終盤(設問ウ)で(課題を解決し、)課題解決について評価する
こういうきれいな流れが作れますよね。
論述ネタって、基本的には技術、設計上のあるある問題で、あるある問題については一般的な解決策があったりするわけです。
上述の事例だと、例えば問題文中の論述ネタ(移植性)を使って、
- 課題：暗号ライブラリの外部調達
- 論述ネタ:移植性(他チップへの移植困難)
- 解決策:HALでチップ間差異を吸収する
- 評価:自社開発時にもI/F流用が可能
という、あるあるな課題と解決策について、各設問に分割配置しています。設問ア、また設問イで敷いた論述ネタの伏線を、設問ウで回収可能なように設計しているわけです。
まぁ何というか『推理小説を書くかのように目次を構成する』とでもいったイメージでしょうか。楽しそうだと思いませんか？
走りながら考える
手書き記述時の工夫に戻ると、上記のように論文設計をしたら、後はその内容をふくらませていきます。
目次では書ききれなかった状況だの詳細だのを書いていきます。このあたりは記述力が一定以上あると有利です。
例えば移植性の話で、『将来の自社実装置換を念頭に HAL I/Fがあればいい』を、私は設問イの一節として、こう展開しています。
③移植性について
チップベンダに暗号ライブラリ開発を依頼したことで、ライブラリ自身の移植性は小さくなる。これについては以下2点を調達時に依頼することで、影響の最小限化を図った。
(1)自社指定のHAL I/Fに準拠すること。
(2)当該チップベンダの後継製品における互換性動作を保証するか、後継ライブラリを無償提供すること。
将来、自社開発ライブラリへの置き換え可能性と、同一チップベンダの継続採用を念頭に置いた施策である。
大体200字ぐらいですかね。どう展開するかは書きながら考えていて、テンプレがあったりするわけではありません。
論文記述を繰り返していると、似たような文章を何度か書くことになるので、『あぁ、この問題はこんな感じに書けばいいんだっけ』と自然にできるようになります。
それと、論文設計時に思いつかなかった目次を、記述中に思いつくこともあります。
時間に余裕があって、追加対象の設問を未記述な場合は、書きながら浮かんでくるアイデアについて、目次への追加を検討しても良いと思います。文字数リスクを軽減しつつ、論文に深みを出せるかもしれません。
ただし、時間がないと思ったら論文完成を優先するのは鉄則です。書き上げることが何よりも大事。
記述後に確認する
論文が書き上がったら以下を確認しましょう。
作成時間
手書き条件下なので、作成時間を評価しないのは勿体無い。
| 作成時間 | (個人的)評価 |
|---|---|
| 2:00以上 | 早めましょう。検討、記述のいずれかに時間を割きすぎていないか見直しを。 |
| 1:50ぐらい | ギリギリ。もう少し余裕がほしいですね。 |
| 1:30～1:40程度 | 理想的。論文の内容が薄くなってないか、字数制限を満たしているかは確認を。 |
本番では論文記述の他に、論文の題材とした事例説明用の用紙を埋めなければならないので、演習で10分残しぐらいだと、本番で慌てるリスクが出てきます。
評価基準との照合
『設問で要求した項目の充足度』と『論述の具体性』をチェックしましょう。
…目次でフォローしたんだから確認不要？ そんなことはありません。試験官は目次だけ読んでいるわけではないのですから。
というわけで、
- 設問で要求した項目が、目次と本文に書かれていること
- 本文の記述が、第三者に技術的な内容や行為を連想させるに十分な具体性を有していること
を、本文の具体的な箇所を示しながらチェックすることをオススメします。
この辺を励行していると、
- この点についてはちゃんと答えているな。
- ここはちょっと具体性が薄いかもしれない。加筆したい。
- ここ、目次で触れているくせに本文で何も書いてないぞ。
- 未回収の論述ネタがあるじゃん。
という気付きがあるはずです。
これはPC記述のように全文を一目瞭然な環境下では起きにくい現象で、手書きでやると如実に課題が浮き彫りになってくる点なので、疲れているかもしれませんがやっておくと学びになります。
音読する
最後。完成した論文を頭から音読してみましょう。
音読です。黙読ではなく。
これ、何が良いかというと、
- 複雑な言い回しや読みづらい字など、読解の障害を明示的に認識させる
という効果があるんです。
表現が複雑だったり、主語が長かったり、句読点がいつまでも来ないと読んでいて辛いですし、汚い字だとそもそも読めないじゃないですか。
そういう意味で、自分が書いた文章を読みやすくするためのセルフチェックとして機能するので、やっておくといいんじゃないかと思います。
2時間座りっぱなしだと腰にも悪いので、私は立ち上がって部屋の中を歩き回りながら読んでいました。
(できれば)第三者にチェックしてもらう
もし論文を検証できるほどの知見がある方が周囲にいるのであれば、一度、自信作を読んでもらってコメントを貰ってもいいかもしれません。自分の視点だと独りよがりになりがちですからね。その折はIPAの論文評価基準を示した上で、この評価基準に則って客観的に評価してもらうと良いでしょう。
TACやITECでも論文添削をしていたりするので、これらを利用するのも手かもしれません。
ここまでのまとめ
- 手書き時の制約を活かして工夫しよう。
- 論文のストーリーを含め、論文設計は本文記述前にかならず行う。
- 揃えた論述ネタは、伏線と回収を意識して配置する。
- 記述後に、作成時間、評価基準の充足度を確認し、音読しておくとよい。
この条件下で多分5,6本ぐらい論文を書いて、本試験に挑みました。
次回(多分これが最後?)、本試験時の論文展開を振り返ってみようかと思います。
