dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(4)(完)

4.兵の形は水に象る

 そんなわけで、システムアーキテクト試験の会場にやってきたのだ。

本試験の様子

 午後Ⅰまでの試験についてはざっくり受験記に書いておいたので、そちらをどうぞ。

http://jukenki.com/report/josho/SA/index.cgi?mode=view&no=15

 3行で説明すると、

  • 午前Ⅰは免除。
  • 午前Ⅱは半分以上過去問使いまわし。まぁ大丈夫。
  • 午後Ⅰは悪問引いてしまった…大丈夫だと信じたいが少しだけ心配。

 まぁ、どの道ここまで来たら走りきって終わるしかないよね、という心境で午後Ⅱに臨みました。

午後Ⅱ本試験問題

 当初の作戦通り、問3を選択しようと思っていたのですが。

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_2/2016h28a_sa_pm2_qs.pdf

問3 組込みシステムにおけるオープンソースソフトウェアの導入について

 タイトルを見た瞬間ギクリとしました。

 『OSS…だと…?』

OSSに関する経験

 受験記にも書いたのですが、携わってきたエンベデッド開発の特性上、OSSを触ってきたことはあまりなかったのです。持ってきた事例もOSS利用は特に想定していませんでした。

 ここ半年ぐらいの間に、開発の内容が変わってきて、ちょうど自組織の開発内容にOSSの成果を取り込み始めようと、調査を行い始めていたところでした。

 ここでちょっと葛藤があったんですね。

  • まとまった事例経験は持参しているが、OSSは全く絡んでない。
  • OSSが絡む作業は仕掛中で、導入判断の上で開発完了しているような纏まった事例ではない。
  • エンプラ系の問題(問1 or 問2)は答えられなくもないが、論文としては1レベル下がる。

 どうしたもんかなぁ、と思ったのですが、ここで初回の伏線『妄想力』が展開され始めました。

 『待てよ…あの開発事例で、“もしも”OSSの導入を検討、考慮に入れていたとしたら…“どうなったんだろう?”

 ここが本試験午後Ⅱにおける最大の転換点でした。

仮想シナリオの検討

 問題文を見ながら、私は上記の仮想シナリオを考え始めました。すると、取っ掛かりになる論述ネタが問題文に散らされているんですね。

一般的には保証やサポートがない

 自部門で開発課題を抱えた場合や、対顧客保証をどうするんだ…?

使用許諾条件

 ライセンス。商用屋にとっては頭の痛いGPLLGPL。もう少し使いやすいBSD、MIT、Apacheもあったっけ…。

性能要件達成、独自ハードウェア制御

 ターゲットボードのサポートは含まれるのかとか、自分で作ってないコードのパフォーマンスチューニングは骨が折れる…。

関係部署を交えた協議

 そもそもうちの開発部隊、OSSのコードメンテできる実力あるのか? 客にも説明がいるが、その前に対顧客部署を説得しないと…。

 こういうのが思いついてきたので、各設問を章立てすると同時に書けそうな論述ネタをメモ用紙に展開してみました。

 それがこちら。製品名が入っているところがあるので、そこは白塗りしています。

f:id:dimeiza:20161230123531p:plain

 これはひどい…前回のメモより読めないじゃないか…本試験だってのに…。

 まぁ多少焦ってはいたわけです。

 というわけで例によって、趣旨を補完しながら読み解いていきます。

  • 第1章 私が担当した組込みシステムの概要
  • 第2章 OSSの組み合わせに対する考慮
    • 1.関係部署との協議
      • (1) 知財部間
        • ライセンス
          • GPL系とBSD
            • BSD系はあるのでコード非開示OK
      • (2)HWプラットフォームチーム
        • パフォーマンス要件
          • 要カスタマイズ
        • セキュリティ強度
          • スケジュールはかかるがハードウェアを使ったほうがいい
      • (3) 要件定義チーム
        • ライセンス
  • 第3章 判断の妥当性と今後の対応
    • 全体的に自社開発優位、(現行開発製品)は特殊セキュリティ
      • OSSを使わず自社開
    • パフォーマンス、セキュリティは所望のものに
      • 得意先も余計な表示なく納得
    • (現行開発製品)はこのままでいい
      • 自分たちが(現行開発製品)外の開発を行う時、親和性高な製品には必要となる

 ここまでで大体15分ぐらい。

 2章の構成が多少いびつ(第2階層が『1.』しかない)ですが、そろそろ書き始める時間なので、後は書きながら補正すると決め、解答用紙の問3に○をつけて、勢い良く書き始めました。

 後は勢い。『走りながら考える』です。論文再現はしていませんが、趣旨と結論は上記のメモから全く外れずに書き上げました。

論文設計から見えること

 自分なりに振り返ってみます。

シミュレーションに基づく自身と社内の動き

 論文設計に書かれていることの多くは、『もし私があの製品で、システムアーキテクトとしてOSS導入を検討していたら…?』を出発点としたシミュレーションです。

 この出発点から、問題文に展開されている論述ネタそれぞれについて、自分と周囲のステークホルダに反映させた場合の動きを展開しています。

  • ライセンス
    • ってことは多分知財部門と相談することになる
    • ってことは顧客の製品宣伝に影響するはず
      • 昔要件定義チームにいたが今は別の部隊だから、きっと要件定義チームに相談に行くだろう
      • 彼らにとっては、『客への説明のしやすさ=仕事のしやすさ』。あまり説得はしたがらないだろう
      • 昔、自分が客と話したときも、先方のマーケティングチームに説明文書を追加させるのは面倒そうだった
      • となると、面倒な著作権表示や宣伝表示には難色を示してくるはずだ
  • ハードウェアとセキュリティ
    • ってことは(私が自分で作らない限り)多分HWプラットフォームチームと相談することになる
      • 顧客からの直接要求に晒されていないOSS製品が、パフォーマンスチューニングが不要なほど作り込まれているとも思えない
        • となると自前でチューニングせざるを得ないだろう
        • カスタマイズが必要、と彼らは言うに違いない
      • (セキュリティアタックに晒される製品なだけに)セキュアコーディングがされているかどうかも気にしてくるはず
        • ターゲットデバイスにはそもそも暗号コプロが搭載されている、というのはよくある話
        • 暗号コプロを採用したほうが早いし安全、と彼らは言うだろうなぁ

 一緒に仕事をしたことがある人々の反応を思い浮かべながら、こういうシナリオを表出させた、というわけです。

あなたの"経験"に基づいて論述せよ

 ただ、言うは易しとはまさにこのことで、見ての通りこのシナリオは筆者の実際の経験に基づいているんですね。

  • 知財部門が契約書主義、法文主義なのを知っているのは、特許出願やらなにやらで一緒に仕事をしたことがあるからであり、
  • 要件定義チームの気心が分かるのは、自分が要件定義をしたことがあるからであり、
  • 客の心境がわかるのは自分が客と交渉したことがあるからであり、
  • HWプラットフォームチームの反応は自分がメンテナンスするときの心境そのままだから

 なわけです。

 このことは重要な示唆を含んでいて、

  • 実務経験の蓄積と展開は応用力を高めてくれる
  • 実務経験と妄想力を組み合わせると、あたかも実際の出来事であるかのように一連の事例を演出できる
  • 実務経験の幅が広いほど、登場ステークホルダを増やし、シナリオに深みを出せる

 ってことなんです。これは私自身にとっても意外な驚きでした。

 なので、実務経験を積んできた方は、きちんと自分の経験を棚卸して、頭を柔らかくしておくことをオススメします。多少持参事例から外れたテーマが出てきても、実務経験に基づいて想像を働かせれば、問題文の論述ネタを足がかりに、具体的なイメージを伴った経験を作り上げることができるはずです。

あなたの"考え"に基づいて論述せよ

 上述のシナリオを展開してしまうと、自分を含めたステークホルダの動きから、もう本開発におけるOSS検討の結論は出てしまうんですね。

 これだけ反証が揃っていたら、どれだけ自分がやりたくてもOSSを導入するわけには行かなくて、自社開発すべき、って結論になってしまう、と。

 一瞬だけ『この結論で大丈夫か?』と思ったわけです。前回説明したとおり,キレイに締めないといけないので。

 ただ、

是非に関する判断の妥当性

 ってことは、問題は導入事例を求めているのではなく、検討事例を求めているんだな、とすぐに題意に気づいたので、設問ウの流れを書くことにしたわけです。

 世の流れ的には、エンベデッドの世界でもOSSの導入は積極的にやろうぜ、という感じですし、車輪の再発明はアーキテクトとしてもアンチパターンなのは承知の上で、“あえて”

  • 『この用途と状況なら自社開発すべきであり、判断は妥当と考える』
  • OSSと親和性の高い製品については今後導入していくべき』

という、世間一般の正解とは異なる結論を、明確な根拠込みで展開していきました。

 こうすることで、通り一遍の教科書回答よりも遥かに論文に意思を込められるし、『アーキテクトとして、実際にトレードオフをしたんだよ』という印象を与えられるんじゃないか、と。

 メモを書いたタイミングでこういう心証を得たので、『こいつは面白い!』と高揚したのを覚えています。

 事例を丸写しして堅実に勝つ、というのも当然一つの勝ち方ですが、本試験で求められた挑戦にガッツリ応えた上で、手応えのある論文設計ができた、という感覚を持って論文を書き始めることができたなと。

 その後の本文記述は、過去のどの練習よりも勢いがありました。

論述を背後で支えていたもの

 一見、事例と経験ベースだけで書かれたように見える論文ですが、本人が自覚しないところで練習が生きていました。

 これはこの文章を書く直前に気づいたことだったんですが、実は趣旨近めの問題は過去問で出ていて、実際にそれを解いたことがあったのでした。

平成23年度秋期 システムアーキテクト試験 午後Ⅱ問題

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2011h23_2/2011h23a_sa_pm2_qs.pdf

問3 組込みシステムの開発におけるプラットフォームの導入について

平成21度秋期 システムアーキテクト試験 午後Ⅱ問題

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2009h21_2/2009h21a_sa_pm2_qs.pdf

問3 組込みシステムにおける適切な外部調達について

 調達先がオープンソースコミュニティであり、調達ソフトウェアがプラットフォームでない、ってだけで、上記の両問題は今年の問3と共通した、『ソフトウェアの社外調達に関する問題』なんですね。

 実際、平成21年度試験問題についても、私は暗号ライブラリの調達を事例として演習論文を書いています。

 あるレベルで抽象化して俯瞰してみると、実は問題そのものがあるあるネタ、ということなんですが、これは論文演習が嘘をつかない、ということの一つの根拠でもあります。過去問のどれかを解くことで、あなたは自らの本試験問題の予行演習をしているかもしれない、ということですからね。

 そういうわけなので、自信がないと思ったらなるべく演習で補強しておきましょう。適切にやれば演習は嘘をつきません。

画竜点睛

 論文本文は大体15分ぐらい時間を残して書き終えました。演習だと30分残しだったので、本番依存の遅延をフォローできた感じですね。

 後は受験記にも書きましたが、業務経歴記述を埋めた後で、

  • 『出題要件の確認』
  • 『読み辛い字の書き直し』
  • 『回答用紙の体裁見直し』

 をしましょう。

 業務経歴記述はメモが固まった段階で実施しても構いません。たしか私も本文記述前にやったような気がします。

 出題要件の確認は正直今更で、ここで抜けがあったりするとかなりキツイです。実際私も抜けはありませんでした。

 が、もしこの時点で気づいたなら加筆して記述しましょう。採点までこぎつけられるかはさておき、フォローできる最後の機会です。

 字の書き直しは文章ではなく字単位で。隣の字が綺麗なら消してしまわないようにしたい所。時間とのトレードオフなので、あまりこだわりすぎないほうが良いです。

 いちばん大事なのは解答用紙の体裁見直し。特に受験番号、氏名と問題選択の丸つけは絶対に確認しましょう。これだけやって体裁不備による未採点とか最悪ですからね。

ここまでのまとめ

  • 棚卸しした実務経験と妄想力を組み合わせると、試験官を納得させるほどの仮想シナリオを作ることができる。
  • 問題文が許容する限り、経験に基づく限り、世間の潮流と合致しなくても、自身の考えを表出させることには意味がある。
  • 事例丸写しで勝てるならそれでも良い。納得感のある論文設計をしよう。後の勢いが違う。
  • 演習は嘘をつかない。今解いている過去問が、本試験に近いテーマかもしれないのだから。
  • 本文を書き終えたら、出題要件確認と体裁見直しが完了するまで決して気を抜かないこと。

さいごに

 論文対策には色々な考え方があり、無対策でも合格した、って人もいて。

 私はたまたまこれでうまく行ったよ、って話なので、これを読んだ方が同じことをやったからといって試験に受かるか、というと、それは保証の限りではありません。

 まぁ、こういう勝ち方もあるよ、ということで。

 今後システムアーキテクト試験に挑まれる方が論文試験を突破する際に、この記事が少しでも武器になることができたら、筆者としては何よりの幸いでございます。