システムアーキテクト試験 午後Ⅱ試験(論文)について考えたり準備したりした事柄(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分残しだったので、本番依存の遅延をフォローできた感じですね。

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

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

 をしましょう。

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

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

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

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

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

ここまでのまとめ

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

さいごに

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

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

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

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

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

3.謀多きは勝ち…

 PCで論文を何本か書いた私は、ぼちぼち手書きで論文を書いてみることにしました。

論文を手書きで書く

 言うまでもなく最も本番に近い環境での訓練になりますが、手書きはPCでの論文書きと比較して以下の点が異なります。

# 相違点 概要
1 記述が大変(手が疲れる) 初回でも触れましたが3000字近く書くことになるので結構疲れます。
2 全体が見えづらい PCと違って記述内容が1画面に収まることはなく、原稿用紙複数枚にまたがるので見通しが悪いです。
3 構成の修正が困難 カット・アンド・ペーストすることもできないので、一度記述した構成を大きく変更するのは不可能に近いです。
4 字の上手い下手 下手な字で書くと読みづらくなります。
5 漢字 IMEの力を借りることは出来ません。自力で正しく漢字が書けるかが問われます。

 端的に言うと、コンテンツの作成にあたってPCよりもずっと自由度が低く、制約された環境になるわけです。

 この環境制約は結構重要な事で、この制約によって逆に論文作成時に工夫を強いられることになります。リソースが限られているので、限られたリソースの中で最大限の効果を得ようとして工夫するわけです。

 以下、私が手書きをしていく中で自然と行っていた工夫と効果を挙げていきたいと思います。

  1. 章立てを含む論文設計は必ず本文記述前に行う
  2. 走りながら考える
  3. 記述後に確認する

章立てを含む論文設計は必ず本文記述前に行う

 前回、設問で要求された項目はまず章立てで保証するという話をしたと思いますが、逆に言うと、設問の要求事項が分かっていれば、章立ては本文執筆前に行えるということでもあります。

 これ自体はそんなに難しいことではなく、機械的に行うことができます。

 ここでポイントとなるのは、設問で要求された項目の章立てだけではなく、各章、節において記述すべき論述ネタと事例の配置も、ここで行っておくべきということです。

例えば

 実際に私が手書きで論文演習したときのメモでも。

 題材は平成21年度システムアーキテクト試験午後Ⅱ問3。

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

 以下が演習時に記述したメモ。ちなみに、この時の演習ではこのメモ書きも含め、1時間40分ぐらいで論文記述を完了しています。

f:id:dimeiza:20161225122943j:plain

 …いやぁ…あまりの悪筆で、書いた本人にもよく読めませんね。お恥ずかしい。

 ということで何が書いてあるか、解読しつつ整理してみます。

  • 第1章 私が携わった組込み製品の概要
    • 1.製品の概要
    • 2.外部調達の課題
      • 暗号ライブラリの調達
        • 高セキュリティ
        • 高速演算
        • 開発スケジュール対要員
  • 第2章 外部調達の課題について
    • スケジュール
      • 外部調達で要員、工数は節約可
    • セキュリティ強度
      • 強度の確保が難しい
    • 保守性
    • 移植性
    • (検討内容)
      • 納期優先、要員数から自社開難
      • 将来の自社実装置換を念頭に HAL I/Fがあればいい
      • 継続的なメンテナンス契約でリスクヘッジ
      • 信頼性高チップベンダ+彼ら自身に作らせる
  • 第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本ぐらい論文を書いて、本試験に挑みました。

 次回(多分これが最後?)、本試験時の論文展開を振り返ってみようかと思います。

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

2.汝平和を欲さば、戦への備えをせよ

 彼我の状況がわかったところで、次は準備の話に入ります。

何を欲するのか?

 前回書いたように、準備は状況と自身とのギャップを埋めるためにするものなので、何を目的として準備するかは結構重要です。

 例えば私にはこういうギャップがありました。

# ギャップ 概要
1 場数 IPA論文試験はおろか、試験で小論文を書いたことがほとんどない。論文書きそのものの場数を増やしたい。
2 ネタの蓄積 論文ネタが重要と言われるが全くストックがない。書けるネタを増やしたい。
3 型を身につける IPA論文はどういうスタイルで書けば良いのか、スタイルを身に着けておきたい。
4 ジャンル内テーマ対応力 エンベデッド問で種々のテーマが問われても、無難に回答できるようになりたい。
5 ジャンル間テーマ対応力 エンベデッドで全く回答できないテーマが提示された場合、エンプラ系で回答できるようになりたい。

 1~3は基本的には論文記述数によって影響を受ける箇所で、ここは論文の数をこなしていけば自然に対応できるようになります。

 一方、4と5については論文のテーマ依存の問題(『出題テーマリスク』)に対応するための準備で、こっちは論文のテーマを様々変えていくことが必要になってきます。

 特にエンベデッド系は1問しか出題されないので、エンプラ系に比べてジャンル間テーマ対応力の需要は大きいです。

 私自身も今ほど明確に認識していたわけでもないのですが、この辺は何とかしておきたいなーとおぼろげに考えていました。

最初の論文を書く

 こういう問題意識を抱えた状態で午後2試験に関するTACの講義を受けました。

http://www.tac-school.co.jp/kouza_joho/joho_crs_sa_hon.html

 TACはTACで論文記述のノウハウを持っていて、『ステップ法』という考え方で論文を書くように提案しています。

 あんまり書くとTACの商売敵になってしまうので、細かいところは書きませんが、

  1. 最初に章立てを考え
  2. 次に問題文から思いつく論述ネタを考え
  3. 論述ネタに対応する事例を取り出し
  4. 論述ネタと事例の整合性を確認した上で
  5. 展開、論述する

 というやり方ですね。

 ここから何本か論文を書くことになるのですが、上記の流れを意識して論文を書いていくと、全く何もない状態で書き始めるよりも随分と楽にはなります。

 とはいえ、この知識があっても実際に論文がスラスラ書けるようになるわけでもなくて、やはり自分の力で論文を導出して、初めて有効な訓練になります。

 一方で、論文を書きなれない状態で最初の論文を書くのはなかなかのハードルなので、まずは 過去問で最も解きやすいと思った問に対して、PCで論文を記述するのをいくつか繰り返すのが良いと思います。

 google先生の力を借りてもいいし、後から構成を変更するのもありです。とにかくまず最低1本、PCで自分の論文を書き上げましょう。

 最初は2時間以上かかるかもしれませんが、全く問題ありません。

 最初は手書きに拘るのではなく、

  • 一定の構成を有する論文を完成させること
  • 規定以上の字数を実際に書いて、コンテンツのボリュームをつかむこと
  • 論文の記述を通して、論文書き(論述ネタの展開)の実感をつかむこと

 形式に関係なく、上記を達成出来るようになるのが大事です。

複数の論文を書く

 1本書けたら、エンプラ得意ならエンプラ系で、エンベデッド得意ならエンベデッド系で、別のテーマの過去問を選んで、同じようにPCで論文を書きます。

 ジャンル内で複数書けるようになったらジャンルをまたぎます。エンプラ得意ならエンベデッド系を。エンベデッド得意ならエンプラ系を。

 TACでは、『文章得意な人は3本、苦手な人は5本ぐらい書いておきましょう』と言われたのですが、天邪鬼な私は『じゃあ私は10本ぐらい書けばいいかな』と思いまして。

 結局その半分、5本ぐらいはPCで書いています。

最低限の評価基準と具体的なコンテンツの対応関係

 じゃあそろそろ、具体的な論文例の話をしましょう。

 前回、論文の評価基準として

  1. 設問で要求した項目の充足度
  2. 論述の具体性
  3. 内容の妥当性

 というピックアップをしたと思います。

 内容の妥当性は、誰が見ても嘘だと思うような内容を書くな 、ってことで、これは言わずもがな。

 まだ書き始め、しかも経験のないエンプラ系ですが、当時書いた叩き台ということで、私の習作を例示してみようかなと思います。

 テーマは平成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段階、読みやすい(読ませる)論文について考えることになります。

 以下、次号。

平成27年度 システムアーキテクト試験 午後Ⅱ論文答案習作

第1章 業務機能追加、変更の対象とした情報システム

1.対象となった情報システム及び業務の概要

 私が業務機能追加、変更の対象として携わった情報システムは、ECサイトプラットフォームのシステムであ る。

 今日、インターネット上販売を手掛けるサイトは多く存在するが、ECサイトプラットフォームは、ECサイトとしてインターネット上販売を行うための共通機能を、小売側が手軽に利用するためのプラットフォームである。

 すなわち、販売する商品の登録と、配送、決済に関する小売体制をプラットフォームに登録するだけで、ECサイトをプラットフォーム上で半自動的に構築し、EC事業を行うことを可能としている。

 私は、このECサイトプラットフォームの業務課題対応について、システムアーキテクトとして関わった。

2.機能変更または追加を必要とした業務課題

 最初のバージョンのプラットフォームを運用してしばらくした後、以下の要望を顧客から受けた。

①販売者ごとにカスタマイズ処理を追加したい。

 共通機能を提供しているプラットフォーム上では、機能が共通でユーザビリティが高い一方、販売者ごとに個性を出すことが困難である。

 例えば、販売後にSNSへの投稿を行ったり、販売結果を保存しておいて、後日メールでレコメンドする機能等、販売者ごとにそれぞれ異なるサービスを行いたい、という要望を複数の販売者から個別に聴取した。

②販売結果をレポーティングしてほしい。

 販売者側としては、販売実績を管理し、実績を元に品揃えを最適化したいとの要求があるが、販売実績については、最初のバージョンでは単なるCSVファイルのオフライン出力しかできず、ビジュアライゼーションによる視覚的な分析には難があった。

 このため、グラフや多変量解析など、より高度な解析、出力を可能として欲しい旨の要望を受けていた。

第2章 業務機能の変更と追加

1.具体的な変更、追加機能

 私は、上記の業務課題について、以下のように変更、追加を行った。

 ①販売者ごとのカスタマイズ処理については、プラットフォーム上の購入処理末尾に、販売者独自の処理を挿入することで対応した。

 具体的には、販売者は予め実施したいサービス内容を『販売者独自処理』として(プログラムやAPI呼び出しとして)記述しておく。

 購入者が購入を確定するボタンをクリックした際、ECサイトプラットフォーム側は、決済処理とともに、当該販売者独自処理を呼び出す。

 これにより、購入確定後に、販売者独自処理が実行され、販売者ごとに独自のサービスを実行できる仕組みとしている。

 例えば、販売終了後、販売商品の情報をTwitterに自動投稿する処理や、リコメンド用データベースに販売商品のIDを保存しておく、などといった独自処理を定義、実行することができるようになっている。

 ②販売結果のレポーティングについては、購入確定後に、データ解析を行う他事業者のクラウドサービスに対して、自動的にWeb APIを呼び出し、当該API経由で販売データを転送し、データ解析クラウドサービス内に販売データを蓄積させ、当該サービスにおいてレポーティング機能を提供するように、販売データの出力を行うようにした。

 販売者は、ECサイトプラットフォーム側ではなく、データ解析用他クラウドサービスにアクセスすることで、自身の販売履歴を解析したレポーティングサービスを受ける、という形態になる。

 加えて、販売者が独自にレポーティング機能を準備した場合に備え、販売結果を取得可能なWeb APIを自社サイトに準備し、当該APIを販売者側のレポーティング機能から呼び出すことにより、販売者自身でレポーティングできるようにした。

2.課題への対応性について

 以下、各課題ごとに対応性について言及する。

 ①販売者ごとのカスタマイズ処理については、購入完了後のフォローによる差別化が販売者側の主たる要望であり、購入中のカスタマイズは不要という要求であった。

 このため、購入終了後のみ、販売者の独自性が発揮できればよく、購入終了後のカスタマイズ機能提供で十分であった。したがって、当該機能変更は、販売者にとって十分な課題対応性を有していたといえる。

 ②販売結果のレポーティング機能については、後述の通り、自社がレポーティング機能を独自開発しないことを意図したものでもあったが、販売者としては、『レポーティング機能は、ECサイトプラットフォーム機能とは独立して利用したい』『プラットフォーム上ではなく、自らデータを取得して自由に解析したい』という潜在的な要望があり、この潜在ニーズと照らしあわせても、販売者が有する課題への対応性は十二分であったと結論される。

第3章 機能変更、追加時の工夫

 以下、当該機能変更、追加に関する工夫について述べる。

1.既存情報システムへの影響最小化

 販売者ごとのカスタマイズ処理については、ECサイトプラットフォーム側で、購入完了後にある特定の名前のメソッドを呼び出す処理を追加している。この呼出処理においては、販売者が独自処理を定義していなければ何もせず、独自処理を定義していればその処理を呼び出すことになっている。

 これにより、販売者ごとのカスタマイズ処理実装にあたっては、既存のECサイトプラットフォーム側への設計、実装変更をほとんど実施する必要が無い。したがって、カスタマイズ機能実装にあたっての、既存情報システムへの影響は、当該カスタマイズ機能の処理結果を除いては全く存在しない、という設計とした。

 さらに、呼びだされた独自処理は、ECサイトプラットフォームのプロセスとは別のプロセスとして実行される。したがって、仮に販売者独自処理に不具合があり、プロセスが不正終了した場合であっても、すでに動いているECサイトプラットフォームの機能実行には何ら影響しないという実装にもなっている。

2.既存機能の活用

 販売結果のレポーティングについては、ECサイトプラットフォーム自身で解析を行った場合、既存の設計や実装に対して中規模な変更が発生する見通しであった。このため、あえて自社のサービスとしてレポーティング機能を独自開発するのではなく、既存の他事業者のサービスや、販売者自身のレポーティング機能と連携することで、すでに存在するレポーティング基盤を活用し、機能実現を図ることにした。

 これにより、自社はECサイトプラットフォームに特化した機能実現、追加、保守に注力できるばかりではなく、完成度の高い既存のレポーティング基盤を販売者に提供する形となり、既存機能の活用によって、より販売者のニーズに合致したサービス連携、機能実現を図ることができている。

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

はじめに

 関係各位の種々のご支援もあり、この度IPAシステムアーキテクト試験(2016)にパスすることができたので、システムアーキテクト受験者にとって難関とされている、論文試験対策について、私がやってきたこととか考えてきたこととかを残しておこうかなと。

 特に私の出自はエンベデッド系で、エンベデッド系の情報って、エンベデッドシステムスペシャリスト試験周りも含めて数えるほどしかないので、同じようなキャリアパスを進もうとされている方の一助になれば、と思います。

 あ、多分エンプラ系の人が読んでも参考になるとは思います。

 なんか書いていたら長くなってきたので、3部か4部構成ぐらいにしようかと思っています(内容、構成とも書きながら直すかもしれません)。

 お暇な時のお茶請けにでもどうぞ。

1.敵を知り己を知らば…

 何事もそうなんですが、戦いを始める前に、敵と自分の状況を確認しておくことって大事です。

敵(勝利条件と試験)

論文試験という定性的な日本語の試験であっても、国家試験である以上、どういう試験であって、何を達成すればいいか、というのは、一応明文化されてはいます。 まずはそれを見てみましょう。

試験環境

 敵について主要な特徴を列挙するとこんな感じ。

# 環境 内容
1 試験時間 120分(14:30~16:30)
2 論述内容 設問ア:800字以内、設問イ:800字以上1600字以内、設問ウ:600字以上1200字以内。手書き。
3 評価基準 1.設問項目の充足度2. 論述の具体性 、3.内容の妥当性…などを評価の視点とする。
4 設問 3題中1題選択。うち1問は組込みシステムに関する問。 出題テーマを事前に把握することができない。

試験時間

 120分しかありません。『もある』ではないのです。『しかありません』。

 これについては何をか言わんや、規定字数を満たす論文を1回でも良いので『手書き』で書くと、感覚が分かります。 慣れてくると演習では30分残しぐらいでさくっと終われるようになりますが、慣れない人は普通に2時間を超えるはずです。

 論文試験開始時間は14:30から。午前Ⅰから数えると6時間後という長丁場の最後に巡ってきます。

 この試験が始まるタイミングでなるべく体力を温存し、頭が回せるコンディションにしておきたいものです。そうなると、午前Ⅰ免除を受けずに挑むと不利に働くであろうことは容易に推察できるのではないかと思います。

論述内容

 各設問には規定字数があります。

  • 設問ア:800字以内
  • 設問イ:800字以上1600字以内
  • 設問ウ:600字以上1200字以内

 ここで、800+800+600=2400字ぐらい書けばいい、と思ったら大間違いです。

 論文試験で覚えておくべき鉄則ですが、 規定字数に満たない論文は、採点されません。 どれだけ秀逸な内容であっても目を通してもらえません。

 論文はIPAが用意した原稿用紙に従って記述します。このとき、原稿用紙の文字数が、一定の文字数ごとに振られているのですが、これは原稿用紙ぎっちり文字で埋めた場合の文字数なので、あくまでも目安でしかありません。

 このため、設問で示された最低字数よりも余裕を持って書く事が必要になってきます。空白の量次第ですが、私は上記の目安の文字数+400字ぐらいを下限として記述しました。

 となると、800+1200+1000=3000字ぐらい。400字詰め原稿8枚ぐらい。多いでしょ?

 そして、これを『手書き』で書かなければなりません。手書きの慣れとか手の疲労とか、もう技術とは全く関係ないことを考慮に入れる必要が出てくるって話です。

 ITエンジニアの多くは文章を手書きではなくエディタやワープロで書いていて、手書きで大量の文章を書いている人は少ないでしょう。私みたいに悪筆なのは練習するしかないとしても、手の疲労だけはなんとかしておきたい。

 ということで、私は筆記用具にも気を使いました。

ぺんてる シャープペン スマッシュ 0.5mm Q1005-1 ブラック

https://www.amazon.co.jp/gp/product/B0013NHU6K

ぺんてる シャープペン グラフ1000 フォープロ PG1005 0.5mm

https://www.amazon.co.jp/gp/product/B0013NFZU8

 この2本を使って疲労に備えることに。結局Q1005-1をメインに、PG1005は予備という使い方になってました。

 百均のものでもダメとは言いませんが、書きやすさ、疲れにくさを実感できるほどの差があります。

評価基準

 この辺りは受験者でも言われないと見ないくせに、合否を左右する重要な箇所。

試験要綱Ver3.0

https://www.jitec.ipa.go.jp/1_13download/youkou_ver3_0.pdf

注 1) 午後Ⅱ(論述式)試験の評価方法について

・設問で要求した項目の充足度,論述の具体性,内容の妥当性,論理の一貫性,見識に基づ く主張,洞察力・行動力,独創性・先見性,表現力・文章作成能力などを評価の視点とし て,論述の内容を評価する。また,問題冊子で示す “解答に当たっての指示”に従わない場 合は,論述の内容にかかわらず,その程度によって評価を下げることがある。

 これが評価基準ですが、この評価基準は重要度別に並べられている、と言われています。上から3つ挙げていくと、

  1. 設問で要求した項目の充足度
  2. 論述の具体性
  3. 内容の妥当性

 こんな感じ。

 もう一つ、論文の評価基準を推し量るための資料があります。

平成27年度秋期(1)試験 システムアーキテクト 採点講評 午後Ⅱ試験

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2015h27_2/2015h27a_sa_pm2_cmnt.pdf

問題文の引用で文字数を費やし、内容が薄くなってしまっている論述も少なかった。

問題文に記載している観点などを抜き出し、一般論と組み合わせただけの論述は引き続き散見された。

問題文に記載した観点や事例は、例示である。自らが実際にシステムアーキテクトとして、検討し取り組んだことを具体的に論述してほしい。

 ここで主として提起されているのは、問題文と論文のコンテンツとの関連についてです。何を要求されているか一言で言うと『具体性』です。問題文に書いていない、自分が持っている具体的な経験や見識を展開せよ、ってことです。

 ただし、問題文の観点や事例を使うな、と言っているのではなく、観点や事例を一般論ではなく、自身の知見に関連づけるということが、実は許されています。これは後ほど実例で示したほうが良いかもしれません。

設問(出題テーマリスク)

 組込みシステムに関する問。エンプラ屋の立場だと3問エンプラにしてほしいと思う一方、エンベデッド屋からすると、選択肢がほとんどなく不利、という印象で、ここについては受験者の立場によって変わってきます。

 出題テーマを事前に把握することができない、という点、一見当然ですが意識する必要があります。自分が用意したネタが適合しないテーマしか出題されない、というリスクに備える必要があるためです。

 この2つは出題内容によって回答の出来、ひいては試験の成否が分かれてしまう 『出題テーマリスク』とでも呼べるリスクです。

 このリスクについては、数撃ちゃ当たる作戦で、適合するテーマが出題されるまで待つ、という気長な戦略もあるのですが、私はこの試験、なるべく1発で受かりたかったので、備えることにしました。

自分(準備開始時の状況)

 翻って自分はどうだったのか。ここは受験者によって個別に異なる箇所かと思います。

 私の状況だけピックアップしておくと、こんな感じでした。

  • IPA試験
    • 論文試験は初めて。
    • スペシャリスト試験は2種制覇(ES,SC)
  • 文書作成能力
    • (論文書いていて気づきましたが)多分得意な方。
    • そもそもこんな文章書いている時点で長文厨。
    • 『得意先への謝罪文、よろしく書いといてー』って言われてよろしく書いて説明するような業務経験もアリ。
  • 構想力
    • 多分そこそこある。
  • 妄想力(シミュレーション力)
    • かなりある。
  • 開発経験
    • 10年近くずーっとエンベデッド系。
    • エンプラ系? 天ぷらの仲間?
      • 机上知識はあるが開発経験は数えるほどしかない。

 というわけで、スタート地点は文章得意なところから始まっています。システムアーキテクト試験の午後Ⅱにおいて重要なのは文章力なので、後から気付きましたが結構有利な地点に立っていました。

 これから私が取り組んできた準備について話をしようと思いますが、『文章苦手だよどうしたら良いんだよ』って方にとっては、あるいはそのまま通用しないのかもしれません。

 ただ、文章苦手、という方に対して、『こうすれば文章苦手でも受かるよ』という話をするつもりはまったくなくて。文章苦手な方は、むしろ システムアーキテクト試験を通して文章力を鍛えましょう。

 ぺーぺーのエンジニアと、リーダレベルを張るアーキテクトを分ける大きな要素は、『他者への説明能力』。下っ端はリーダにだけ説明できればいいですが、リーダはプロジェクトのコンテキストを熟知していない顧客や、上司や、協力会社など、様々なステークホルダに対してコンテキストの共有を含めた説明をしなければなりません。

 論文試験で論文を提出した向こうにいる試験官は、まさにそのステークホルダにかなり近い存在と言えます(しかも技術的知見があるだけ、全くの素人よりよほどマシ)。

 この論文対策を通して、『知らない相手に対して、自分のコンテキストを文章で的確に伝えるスキル』を身につけられるとしたら、それは真の意味の自己啓発につながっています。単に資格を取っておしまい、というよりも、遥かにIPA試験を使いこなした姿ではないかな、と私は思います。

 あと、構想力と妄想力。後者は冗談に聞こえますが、両方とも試験に効いてきます。

 特に後者については、能力としては唯一『出題テーマリスク』に備えることができる能力です。これは本試験で実際に発揮されました。後ほどご説明します。

 手持ちの経験としてはエンベデッド系をひた走ってきたのでそればかり。エンプラ系の経験は極めて乏しいです。ここも『出題テーマリスク』ですね。

 多くの方はエンプラから入るんじゃないかな、と思うので、この点については私より有利な方が大半ではないかと思います。

ここまでのまとめ

 私は概ねこういう環境で試験に臨んだのですが、その情報自体は参考情報でしかなくて、重要なのは

  • 本番で何が求められているか、どう振る舞えれば勝ちなのかを正確に把握しておく
  • 自分が持っている経験、能力と、持っていないものについて自覚的になる

 ということです。これを知っていないとギャップを埋めるための準備をすることが出来ないので。

 ちょっと長くなってきたので、次回、このあたりの状況を踏まえてどんな対策をしてきたか、って話をしようかと思います。

暗黙的コンテキストが生み出す、技術用語の異なる解釈

発端

 

最初の感想

 これを聞いた時、ちょっと意外だったのです。

 …あ、いや、意外というのは、『そういう解説や誤解があるんだー』という意外さです。*1

コンテキストの変化

 マネージドサービスって言ったらAWS誕生時点でサーバーレスアーキテクチャじゃん、と後続のツイートを見ずに思ったりしたのですが、サーバーレスアーキテクチャの解説をgoogle先生に聞いてみたところ、こんな記事を見つけまして。

www.infoq.com

当初、サーバーレスという言葉は、バックエンドアプリケーションを動かすためのサーバーのセットアップと管理を、開発者が気にする必要がないことを意味していた。

ところが、Amazonがサーバーレスのパラダイムを別のレベルに引き上げた。彼らは2014年にAWS Lambdaを発表し、クラウドで動かすアプリケーションに新しいシステムアーキテクチャを取り入れたのだ。そこには、サーバー上で動作して、HTTPリクエストやAPI呼び出しを待つ永続的なプロセスはない。代わりに、AWSのサーバーのひとつで、コードの断片、通常は単なる関数の実行をトリガーするためのイベントメカニズムがある。

 AWSがLambdaを世に送り出すまでは、サーバーレスという言葉はマネージドサービスインフラストラクチャのことを指していた、という説明でして。

 これを見て、『サーバーレス』という言葉が、発せられる時代などのコンテキストによって多義性を生むことに気づいたわけです。

コンテキストによって変わる解釈

 『サーバーレス』という言葉、

  • プロセスレス、イベント駆動、使い捨てのコンテナ
  • マネージドサービスインフラストラクチャ

 という2通りの解釈が、コンテキストによって、それぞれ異なる正当性を帯びているわけですが、私がもう一つ思いついたのはPeer to Peer。

 あれも『クライアントサーバモデルとの対比』というコンテキストを加えると、『サーバーレス』って言えちゃうんですよね。

 そもそも、『Server』も『less』も、古くから使われる一般的な単語なわけで。そこに一意性を求めるのは結構難しいですよね。

まとめ?

 あ、いや、いつもどおりそんな大したものは用意していません。

 強いて言えば、

『一般的な単語で一意的な何かを表現するときには、きちんとコンテキストを相手と合意しないと雲をつかむ』

 ってところですかね。

おまけ(という名の免責事項)

 個人的にはこうおもうんすよねー、あとからちがってたらごめんね。*2

 

*1:言葉を知る前にLambdaから入っていたもので。私自身はAWS歴2ヶ月程度なのですが、『このPoC、ステートフルで実装したほうが楽だから、LambdaじゃなくてEC2で実装しよう』などという意思決定をしたばっかりでした。

*2:私自身は世間様の見方にせよ、自身の正当性にせよ、正しさを確信して断言できる人ではないので、よほどのことがない限り基本このスタンスなんですけどね。信頼を求められる紙媒体と、このチラシの裏みたいなBlogでは重みが違うか…

Developers Summit 2016 Summer B-6 Webサービスベンダーのビジネスを支える足回り - アトラシアン事例 聴講メモ

講演資料

 アトラシアンさんの資料は限定配布。

 commerbleさんの資料はこちら。

http://www.commerble.com/contents/devsumi2016

概要

 スポンサーセッション。Webサービス開発を行うある企業において、アトラシアン製品を使って少人数開発を実施した事例を紹介する。

スピーカー

 アトラシアンの新村さんと、commerbleの竹原さん。

詳細

  • 今回はcommerbleという会社での事例紹介になる。
  • がスポンサーセッションなので、ちょっとだけ自社の宣伝をさせてもらう。

アトラシアン(atlassian)

  • まず最初に、『アトラシアンという会社を聞いたことがあるか?』という質問。

    • 会場では結構手が挙がった(筆者も挙手)。
    • 製品の認知度のほうが高いらしい。
  • 2002年オーストラリアで創業された会社。

    • チームのために何ができるかを考えるのがテーマ。
      • あらゆるチームの可能性を解き放つ、というのがアトラシアンのミッション。
        • 目立つ一人の天才の裏にもチームがある。
      • チームのコミュニケーションとコラボレーションツールの提供をビジネスとしている。
      • 企業のティッカーシンボルはたいてい会社名だったりするが、アトラシアンでは"TEAM"。
  • 製品。

    • JIRA ServiceDesk(サービスデスク向け)
    • Confluence(ドキュメント管理)
    • JIRA(プロジェクト管理)
    • BitBucket(リポジトリ)とBamboo(CI)
    • HipChat(チャット)

事例紹介

  • ここでスピーカー交代。
    • commerbleの竹原さん含め3人がデモを見せながら説明していく。

commerble

  • ECのプラットフォームをマネージドで提供するサービスを実施している。
  • 使っている技術
    • AWSとAzureの組み合わせ。
    • Keycdn。
    • New Relic,logentriesなどなど。

端緒

  • 2010年に初リリースしたが、いろんな失敗をした。

    • 割と『あるある』な失敗。
      • 要件の粒度がバラバラ
      • 役割分担のあいまいさ
      • まとめて検証(ビッグバンテスト)
      • 課題共有されてない
  • リリースが終わったあとで話し合って改善しようとした。

  • 2年ぐらい前に組織変更があり、社長1人に開発者が3人という少数体制に。

    • 管理手間をかけられなくなった。

余談

開発の進め方

  • 一般的には要求分析から始まるウォータフォールの工程が知られているが、自分たちの作り方は違う。

  • どんな問題があるのか考える、感じる

    • 問題の定義を適切に行うことが大事
  • 問題を課題に分解する
    • 2,3日ぐらいの粒度で達成可能な課題に分割する。
      • 大きすぎる課題はみんなを不安にする。
      • 適切な課題粒度だと、日々の達成感を感じることができる。
  • チームで課題を共有する
    • 課題を起票する。
    • この時に担当を決めてしまう。
    • お互いの褒め合いに役立つ。
  • コード、テスト作成
    • 採用する解決策によってはコードを書かないこともある。
  • ソース管理
    • ブランチ、プッシュ、プルリク、マージ
    • 当初はMercurialだったが今はGit。
    • 人数が少ないのでルールをきっちり決めてない。
  • ビルド、デプロイ
    • プッシュしたら、必ず自動でビルド、デプロイできるようにしておく。
    • ビルド、デプロイを特別に考えると、イベント化してしまうことでかえって進捗が遅れる。
    • 単体テストは極力書いたほうがいい。

少ない労力で管理する

  • この手順を愚直にやると、どうやって管理するか困る。

    • 人数も少ない。
      • 少ない労力で管理する方法が必要だった。
      • もっと開発に注力したい。
  • 解決方法として、各作業でアトラシアンの製品を導入している。

    • JIRA、BitBucket,BAmboo,Hipchat。
    • HipChatにすべてのオペレーションのログを残すようにしている。

デモ

  • ECサイトで販促のため、注文完了したらTwitterでツイートする、という問題解決を行う、というデモ。
  • その場で課題起票からデプロイまでを行った。

  • まず、『注文完了したらツイートする機能の追加』をJIRA上で起票。

    • 起票するとバックログに入る。
    • その後、BitBuckiet上でブランチを切ってチェックアウト。
  • Microsoft Stack(Visual Studio)でコードを追加。
    • ECサイトのプラットフォームを提供しているが、顧客ごとのカスタム処理にも対応可能なアーキテクチャにしている。
    • 注文処理の最後にカスタム処理を呼び出すようなアーキテクチャ
      • カスタム処理の末尾にTwitterでツイートするコードを追加。
  • コードを追加後にcommit。
    • IssueとCommitとビルドを連携し、Issueの対応状況をトラッキングしている。
    • 基本的にルールはあまり作らず従ってもいないが、トラッキングのために『コミットメッセージにIssue番号を入れること』は絶対のルール。
  • commit完了したらプルリクし、内容を確認してマージ。
    • マージと同時にビルドを自動的に実行。
    • いつもの開発環境まではデプロイまで自動で行っているが、今回はデプロイを手動で見せる。
  • デプロイ。
    • 当該デプロイに含まれるIssueとCommitの内容が画面上に出てくるので確認する。
    • デプロイをビビっていると、デブロイ承認のような変なフローが増える。
      • お客様の承認は当然必要だが、ステージ環境へのデプロイまでは自動で行うようにしている。
    • デプロイが終わったあとに、各々のサーバが自律的にセットアップ(更新内容を自動で取り込んで環境構築)するようにしている。

最後に

  • デベロッパーがビジネスのためにできることはたくさんある。
  • このやり方が最善だとは思っていない。
  • ハイペースでビジネス改善を回すためのツールとして使っている。