組み込みエンジニアが目指すIoTストラテジストへの道(5)(完)
午後Ⅱ
最後の事前準備
午後Ⅰ終了後、私は手持ちのタブレットを取り出して、こんな絵を眺めていました。
以下に書かれた数値をまとめなおしています。
- IT戦略に関する基本データ集<デジタル化の現状と課題> 平成31年3月22日 内閣官房情報通信技術(IT)総合戦略室 https://www.kantei.go.jp/jp/singi/it2/senmon/dai16/sankou1.pdf
これの出典はここ。
午後Ⅱにおいて組み込み系問題(問3)を解くに当たって用意してきた懐刀です。
前述の通り、午後Ⅱ問3は過去数年間に渡って市場分析をテーマにしてきています。
これに対し受験者としては、例えば前々回で書いたように、PEST分析結果を定性的に記述することでもある程度の体裁を整えられますが、私はそこにダメ押ししておこうと思っていたのです。分析そのものに定量表現を付け加えることで、きちんと数字に当たった経験があることを確実に伝え、他の受験者よりも一歩先んじるために。
あえて衒った言い方をしていますが、実際の所ITストラテジストの仕事は分析を含むので、実務経験の一部として、自己のスキルアップとして必要なことをしているに過ぎません。
あと、最初の図を見ると分かると思いますが、私は数字に対して自己の見解を付け加えていて、(結果的に同じになっているとはいえ)内閣官房の大本営発表を鵜呑みにせずに傾向性を把握しています。自分で分析をしておくと、万が一数字を忘れてしまっても、自分の言葉で傾向性を伝えられるので。
というわけで、市場分析系問題が出てきたら百倍返しにして回答してやろうと手ぐすねを引いていたのですが、結果的にこれらの情報を使うことは全くありませんでした。
実際の問題
というのも、午後Ⅱの冊子を開いて目に飛び込んできた問題は…。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_2/2019r01a_st_pm2_qs.pdf
問3 組込みシステムの製品企画における調達戦略について
そう来たか。
先程の数値関連は無駄になってんじゃん、とお読みの方は思われたでしょうが、この時私はほくそ笑んでいました。あぁ、ちょうど進行中の案件、これで悩んでたな…と。
やはり経験があるのは午後Ⅱにおいては強いです。
今年は18歳の青年がITストラテジストに合格したと聞いていますが、経験値を論文に敷衍できる人がたくさんの経験を持ったうえで試験に臨むと、おそらく勝率は彼/彼女の数倍になるんじゃないか、と今書きながら思っています。
いかなる敵が出てきても撃ち払える、という意味で、経験値は勝敗というより勝率に響くんじゃないでしょうか。
論文設計
とはいえ、思い浮かんだ事例をそのまま答えても、問3の問題文で示唆されている各種の論文ネタを十分に回答することはできないので、問題文のセンテンスを洗い出しながら、書くべき事柄に対応する事例記述を構築していきます。注意したのはこの辺の文言。
必要な技術を洗い出す必要がある。
中長期的な展望を視野
外部調達との棲み分け
コスト削減
外部の専門家を要請するケース
自社との関係・実績、強みとなる技術評価、長期的な供給の安定性、見積もり提示価格、品質管理体制
外部へ情報を開示するリスク
前々回で伝え損ねたところですが、こういう 問題文の中で"誘いをかけてきている箇所"に対して、きちんと誘いに乗る(実例を対応させて明示的に記述する) というのも論文テクニックの一つです。
これら全てに対応する必要はないですが、私が念頭に置いていた実例では、外部の専門家を要請するケースが欠落していたので、ここを補完しています。
で、本試験中にメモ用紙に書いた論文設計はこんな感じ。製品名は白埋めしています。
何度か本試験のメモ用紙を公開してるんですが、受験記を書く段になってみると、本文は丁寧に書いたとはいえ、よくこの記述を読んで本文を書けたなぁ、と思うんですよね。まぁメモに過ぎないとはいえ、この辺火事場感があります。
- 第1章 私が企画した〜
- 1.1 概要
- セキュアセンサ遠隔確認システム
- (セキュリティモジュールを)組み込んだ環境センサボードのセンサ情報ネットワーク表示
- セキュアセンサ遠隔確認システム
- 1.2 背景
- D社はセキュリティモジュール製造者→IoT方面のセキュア化に進出
- 半導体大手A社と製造業B社より、工場内センサのセキュア化と監視システムの要望
- 1.3 調達戦略の概要
- D社は(セキュリティモジュールの)セキュリティノウハウ
- A社はSoCノウハウを持つ
- NWノウハウが両社にない
- センサ、ボードは汎用品
- D社はノウハウを出したくないが、NWノウハウは取り入れて拡販したい
- A社のOSはフリー、OSを変えても(セキュリティモジュール)の拡販をする
- 1.1 概要
- 第2章 調達戦略の検討
- 第3章 調達戦略の評価
- 3.1 妥当性
- 導入後、調達したNWシステムを他案件に流用中
- 納期も達成、セキュリティも事故なし
- →妥当
- 3.2 リスク配慮
- 施策は奏功
- 品質が低かった → コーディングガイドラインやA社側担当の強化要
- 3.3 将来展望
- D社セキュリティモジュール拡販のために、分野と資産を洗い出しロードマップ化
- 優先度を付けて能動整備
- D社セキュリティモジュール拡販のために、分野と資産を洗い出しロードマップ化
- 3.1 妥当性
うん、長い。こういうのを数分で書きなぐるのも高度区分論文試験の固有技 ですよね。
論文設計を読んでもちょっと伝わりづらいので補足すると。
論文設計の補足(論文の趣旨)
セキュリティモジュール開発に定評のあるD社(自社)が、ある日、半導体大手A社と製造業B社に、『B社の工場で使われている組み込みボードとセンサのセキュリティを、D社のセキュリティモジュールで安全にしつつ、ネットワークで遠隔監視できるようにしてくれない?』って頼まれたのが事の始まりです。
で、D社は自分の技術だけでは達成できないので、
- 組み込みボード(SoC)とセンサ、OSはA社から調達
- 工場設備はもともとB社のものなのでB社から調達
- セキュリティモジュールとドライバはD社から調達
- クラウドを使ったネットワークシステムはどの会社にもノウハウがないので外部調達
- システム構築はD社と顔なじみのC社に委託開発
- システムのセキュリティチェックは社外のペンテスターに依頼 (外部の専門家を要請するケース)
という技術の棲み分けをしよう、というシナリオになっています。
ここで特殊なのはD社の思惑で、D社は『今回構築したネットワークシステムを、セキュリティモジュール販促のために他の案件で使いたい』と思っているんですよ。これが 『中長期的な展望』で、この論文になくてはならない戦略の根拠です。
なのでD社は、欠如しているネットワークシステムを顔なじみで融通も効くC社に委託開発させようとするわけです。ちなみに論文設計には記述がありませんが、ネットワークシステムの費用負担はD社が、ペンテスターの費用負担はA社、B社、D社の折半、って本文には書いてあります1。
リスクについてはシステム監査技術者試験を経験している人にはお手の物でしょう。外部調達系のあるあるリスク(成果物の権利関係と自社ノウハウの欠如)を列挙して、第3章で回収する、という基本の流れです。
将来展望はITストラテジストらしく戦略性のある書き方にしておきました。ここで技術的な詳細を書きなぐってしまうと戦略から技術にレイヤが下がってしまいます。大所高所からの打ち手を印象づけておくことで、戦略系の論文として良い読後感にすることを狙いました。
(私のために用意されたかのような)落とし穴
経験にも即しているし、割と手応えありそう、ってことで、勢い込んで論文を書き始めます。早速設問アを埋めていきます。
えーっと、セキュリティモジュール大手のD社はA社とB社に頼まれて…って関係者が多いな…あとC社の記述も入れなきゃ…。各社の背景も書いておかないとわからないよね…。
没頭しながら筆を走らせて、よし、設問ア終わり。
じゃあ次の設問イだ。論文設計メモを見て、いざ書き始めるぞ、と思って設問イの解答用紙を見たその瞬間、私は凍りつきました。
設問イの解答用紙の上半分、300字目ぐらいまで、すでに記述がびっしり書き込まれてるんですよ。
誰が書いたって、私が書いたに決まってますよね。
そう、設問イの解答用紙の上半分を埋めていたのは、設問アの本文 だったのです。つまり設問アを書きすぎていた んですね。
『策士策に溺れる』って有名な言葉があるじゃないですか。今回のをそれっぽく言うと 『文章上手、文章に溺れる』 って感じでしょうか。
論文熟達者へのアドバイス
試験終了後に知ったのですが、趣旨は違うものの実は事前に回避する方策を教えられてはいたのです。
(6)設計書作成時の注意点
設問イ、ウを作成したあと、設問アを作成せよ!
この注意点の示唆自体は、設問イ、ウの前提を設問アで後付で強調する効果を狙ってのものでしたが、同時に 無意識下の書き過ぎ の対策にもなっています。
ということで、ITストラテジストを狙うレベルの論文熟達者に対して、私が実経験から学んだ最も重要なアドバイス はこれです。
- (無意識下、緊張状態下での)書き過ぎに必ず備えよ!
文章書けなくて困っている人からすると信じられない話かもしれませんが、実際にこういうことがあったので、時間配分上も、各設問に対して書きすぎないようにブレーキをかけることは大事です。情報処理教科書に記載のある通り、解答用紙の余白にマーキングするなどして備えておいたほうがいいでしょう。
緊張下で自制力が損なわれるという点もありますが、特にITストラテジスト試験では、
- 論文のステークホルダが多く、複雑な状況を説明するために多くの文章を費やしがち
という 試験区分特有の理由があるので、文章力に自信がある人ほど、書き過ぎの落とし穴に注意しておいたほうが良い です。
文章記述戦略の転換
…と、終わった今だからこそサラッと言ってられるんですが、この時の私は顔面蒼白で、気が気ではありませんでした。
この状況が発生した時点で、書きすぎた文章を全部消した上で、設問アの本文再構築を行って800字で体裁を整え直さなければなりません。設問アの文章も削除、加筆が必要になるので、これだけで20分以上のロスです。
そしてこのペースで設問イ、ウを書き続ければ時間切れは必至。敗北の二字が脳裏をよぎりました。実際ここで慌てていたら敗北していたでしょう。
そこで(心理的に)ぐっと踏みとどまった上で、以降の文章構築について戦略を練り直しました。
いつもは網羅的に理由をガッツリ書きなぐった上で、最大字数ー400字ぐらいをベースに隙のない論文を書くようにしていましたが、真逆にしよう、と。すなわち、まず最小字数を達成することを念頭に置いて骨子だけを記述し、論文完成後に記載不備を補足していく 方向で記述しよう、と。
いかなる環境下においても 『試験時間内に論文を完成させる』 は鉄則で、回答者にとっては、これが論文作成戦略の根本になります。この点に基づいて論文作成ルーチンの切り替えを行ったのが、今にしてみれば起死回生の打ち手でした。
この基本戦略さえ確定してしまえば、後はその戦略に従って、持ち前の文章記述力でひたすら記載を続けていくだけです。文章力で落ちた落とし穴を、戦略の切り替えと文章力でなんとか字数を埋めて這い上がった、というのが、私の本試験午後Ⅱのストーリーでした。
字数の補足に対する考え方
そういう意味では、提出された論文自体は私の本来出力の7割も出ていません。 字数的にもギリギリ+α、って感じでした。
ただまぁ、怪我の功名もあったかなぁと思うのは、各設問の末尾を補足するときに、少し話に深みと言うか、きちんと付加情報を追記できたかなぁ、と思っています。
例えば、さっき触れた費用負担の話と、論文設計で書いたノウハウの形式知に関する話を本文に書いた後で、末尾の補足で少し掘り下げたりしています。
ベンダーがシステムを納品した後、納品された方が文書だけ見て即日そのまま使えるわけないだろうと思ったので、引き継ぎ期間中のサポート契約は必要だよね、と。一方でサポート契約の費用ってのは実務でもよく交渉事になっていたので、交渉しに行きましたって書く、なんてことをしていました。
字数不足については、補足のための時間さえあればあまり心配することはなくて、本文内に記述した事実をフックとして、色々膨らました内容を追記すればフォロー可能 なんですよね。やはり書きすぎの方を警戒すべきだなぁ、と思います。
試験時間終了後に訪れた、私の試験終了
どうにかギリギリで文章を書き終え、製品、システム概要説明用紙を埋めた後2、誤字脱字のチェックと、最小限の流れの確認をしたところで試験終了の合図。いつも演習で実施していた設問の充足度や論旨の妥当性を確認することなく、私の論文は手元から回収されていきました。
周りの受験者が開放感あふれる顔で帰り支度をしていく中、ただひとり私だけが浮かぬ顔をしていて。ずーっと頭の中で、
- 問で聞かれたことを、きちんと論文で回答できていたのだろうか?
と検証していました。私の中で試験はまだ終わっていなかったのです。
ほとんどの人が退出した後で、おもむろに立ち上がり、帰路につこうとするも何となく帰れず。そのままキャンパス内のベンチに座って、ずーっと問題用紙の問3を眺めていました。
もちろん、論文設計上は各設問に対して章構成で備えているので漏れはないはずなんですが、記述内容が読み手に響くだろうか という点を、まだ脳内に残っている論文の残滓と問題文を照らし合わせながら、じーっと考えていました。
そのまま15分ぐらい経ってから『まぁ何とかなるだろ』と、私の口からふいに言葉が出た瞬間に、私のITストラテジスト試験は終わりました。
私はよく旅行をする際に、観光地を堪能する暇のない忙しない旅行をした後で、旅行記を書きながら回顧して追体験することが多いんですが、まさかそれを情報処理技術者試験でやるとは思いませんでしたね。
で、それから2ヶ月後に、頭書の報に接した、という次第です。
さいごに
大分長くなってしまったので、この内容がどれだけ役に立つか、どこまで受験者の血肉になるかはわからないのですが、
- 企画部門、事業戦略部門、コンサルタント以外のエンジニアでも、
- エンプラではなく組み込みのエンジニアでも
(一応最難関ということになっている)ITストラテジスト試験を突破できる、ということを伝えられれば、と思っています。
ITストラテジストの前身であるシステムアナリストは、私がIT業界に入った頃は雲上の資格で、どういう立場でどういう知識が必要なのか想像することさえできませんでしたが、気づけば私もスタートラインに立つ資格を得たのかなと。
机上とはいえ、技術を商売の観点で捉えなおして理解する発想と立ち位置の転換を体験しつつ、エンジニアの思考、フレームワークとは異なる考え方を体感できたという点、今後の職場で求められる立ち位置的にも有意義な活動だったように思っています。
ひとまずこれで私のキャリアパス上必要となる高度区分はすべて取得したので、私は一足先にIPA試験から卒業します3が、以上、IPA資格を通して知識と視野を広げようとする方々の参考になれば、私としても何よりの幸いでございます。
-
D社としては『だって御社で稼働させるんでしょ?』って言いながら費用負担を折半させつつ、自社資産のセキュリティを担保するという、だいぶ虫のいい話なんですけどね。↩
-
『あなたの役割』の所で、ITストラテジストにぴったりハマる役割がなかったので、"システムアーキテクト"に丸を付けて答えてましたね。設問アでも定番の『私は、ITストラテジストとして〜』って書く余裕がなかったので、"システムアーキテクトとしてストラテジスト的な仕事をした"みたいな伝え方になっているはずです。↩
-
残り4つは私にとっては『ラスボスを倒した後のエンドコンテンツ(やりこみ要素)』。挑戦も可能ですが、もっと他にやりたいことがあるので、さしあたりそちらを優先します。コンプしたくなったら戻ってくるかもしれません。↩