組み込みエンジニアが目指すIoTストラテジストへの道(5)(完)

午後Ⅱ

最後の事前準備

 午後Ⅰ終了後、私は手持ちのタブレットを取り出して、こんな絵を眺めていました。

f:id:dimeiza:20191228131756p:plain

 以下に書かれた数値をまとめなおしています。

f:id:dimeiza:20191228131727p:plain

 これの出典はここ。

www.soumu.go.jp

 午後Ⅱにおいて組み込み系問題(問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の問題文で示唆されている各種の論文ネタを十分に回答することはできないので、問題文のセンテンスを洗い出しながら、書くべき事柄に対応する事例記述を構築していきます。注意したのはこの辺の文言。

必要な技術を洗い出す必要がある。

中長期的な展望を視野

外部調達との棲み分け

コスト削減

外部の専門家を要請するケース

自社との関係・実績、強みとなる技術評価、長期的な供給の安定性、見積もり提示価格、品質管理体制

外部へ情報を開示するリスク

 前々回で伝え損ねたところですが、こういう 問題文の中で"誘いをかけてきている箇所"に対して、きちんと誘いに乗る(実例を対応させて明示的に記述する) というのも論文テクニックの一つです。

 これら全てに対応する必要はないですが、私が念頭に置いていた実例では、外部の専門家を要請するケースが欠落していたので、ここを補完しています。

 で、本試験中にメモ用紙に書いた論文設計はこんな感じ。製品名は白埋めしています。

f:id:dimeiza:20191228131827j:plain

 何度か本試験のメモ用紙を公開してるんですが、受験記を書く段になってみると、本文は丁寧に書いたとはいえ、よくこの記述を読んで本文を書けたなぁ、と思うんですよね。まぁメモに過ぎないとはいえ、この辺火事場感があります。

  • 第1章 私が企画した〜
    • 1.1 概要
      • セキュアセンサ遠隔確認システム
        • (セキュリティモジュールを)組み込んだ環境センサボードのセンサ情報ネットワーク表示
    • 1.2 背景
      • D社はセキュリティモジュール製造者→IoT方面のセキュア化に進出
      • 半導体大手A社と製造業B社より、工場内センサのセキュア化と監視システムの要望
    • 1.3 調達戦略の概要
      • D社は(セキュリティモジュールの)セキュリティノウハウ
      • A社はSoCノウハウを持つ
      • NWノウハウが両社にない
      • センサ、ボードは汎用品
      • D社はノウハウを出したくないが、NWノウハウは取り入れて拡販したい
      • A社のOSはフリー、OSを変えても(セキュリティモジュール)の拡販をする
  • 第2章 調達戦略の検討
    • 2.1 自社技術
      • 自社:(セキュリティモジュール)開発とデバイスドライバ、セキュリティモジュールのチップ
    • 2.2 調達先の選定方針
      • (セキュリティモジュール)の他案件拡販に使用する
        • A社に頼むとA社OSにロックインされる
        • SoCとOSはA社を使う、(セキュリティモジュール)とドライバはD社、NWシステムは外部委託
      • 調達速度は早めに
    • 2.3 専門家
      • サイバーセキュリティは自社の知識少→ペンテスターを使う
    • 2.4 外部リスク
      • 成果物の権利→契約
      • ノウハウの形式知化→仕様書と自社レビュー
  • 第3章 調達戦略の評価
    • 3.1 妥当性
      • 導入後、調達したNWシステムを他案件に流用中
      • 納期も達成、セキュリティも事故なし
      • →妥当
    • 3.2 リスク配慮
      • 施策は奏功
      • 品質が低かった → コーディングガイドラインやA社側担当の強化要
    • 3.3 将来展望
      • D社セキュリティモジュール拡販のために、分野と資産を洗い出しロードマップ化
        • 優先度を付けて能動整備

 うん、長い。こういうのを数分で書きなぐるのも高度区分論文試験の固有技 ですよね。

 論文設計を読んでもちょっと伝わりづらいので補足すると。

論文設計の補足(論文の趣旨)

 セキュリティモジュール開発に定評のある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字目ぐらいまで、すでに記述がびっしり書き込まれてるんですよ。

 誰が書いたって、私が書いたに決まってますよね。

 そう、設問イの解答用紙の上半分を埋めていたのは、設問アの本文 だったのです。つまり設問アを書きすぎていた んですね。

 『策士策に溺れる』って有名な言葉があるじゃないですか。今回のをそれっぽく言うと 『文章上手、文章に溺れる』 って感じでしょうか。

論文熟達者へのアドバイス

 試験終了後に知ったのですが、趣旨は違うものの実は事前に回避する方策を教えられてはいたのです。

情報処理教科書 ITストラテジスト 2019~2020年版

情報処理教科書 ITストラテジスト 2019~2020年版

  • 作者:広田 航二
  • 出版社/メーカー: 翔泳社
  • 発売日: 2019/03/18
  • メディア: 単行本(ソフトカバー)

(6)設計書作成時の注意点

設問イ、ウを作成したあと、設問アを作成せよ!

 この注意点の示唆自体は、設問イ、ウの前提を設問アで後付で強調する効果を狙ってのものでしたが、同時に 無意識下の書き過ぎ の対策にもなっています。

 ということで、ITストラテジストを狙うレベルの論文熟達者に対して、私が実経験から学んだ最も重要なアドバイス はこれです。

  • (無意識下、緊張状態下での)書き過ぎに必ず備えよ!

 文章書けなくて困っている人からすると信じられない話かもしれませんが、実際にこういうことがあったので、時間配分上も、各設問に対して書きすぎないようにブレーキをかけることは大事です。情報処理教科書に記載のある通り、解答用紙の余白にマーキングするなどして備えておいたほうがいいでしょう。

 緊張下で自制力が損なわれるという点もありますが、特にITストラテジスト試験では、

  • 論文のステークホルダが多く、複雑な状況を説明するために多くの文章を費やしがち

 という 試験区分特有の理由があるので、文章力に自信がある人ほど、書き過ぎの落とし穴に注意しておいたほうが良い です。

文章記述戦略の転換

 …と、終わった今だからこそサラッと言ってられるんですが、この時の私は顔面蒼白で、気が気ではありませんでした。

 この状況が発生した時点で、書きすぎた文章を全部消した上で、設問アの本文再構築を行って800字で体裁を整え直さなければなりません。設問アの文章も削除、加筆が必要になるので、これだけで20分以上のロスです。

 そしてこのペースで設問イ、ウを書き続ければ時間切れは必至。敗北の二字が脳裏をよぎりました。実際ここで慌てていたら敗北していたでしょう。

 そこで(心理的に)ぐっと踏みとどまった上で、以降の文章構築について戦略を練り直しました。

 いつもは網羅的に理由をガッツリ書きなぐった上で、最大字数ー400字ぐらいをベースに隙のない論文を書くようにしていましたが、真逆にしよう、と。すなわち、まず最小字数を達成することを念頭に置いて骨子だけを記述し、論文完成後に記載不備を補足していく 方向で記述しよう、と。

 いかなる環境下においても 『試験時間内に論文を完成させる』 は鉄則で、回答者にとっては、これが論文作成戦略の根本になります。この点に基づいて論文作成ルーチンの切り替えを行ったのが、今にしてみれば起死回生の打ち手でした。

 この基本戦略さえ確定してしまえば、後はその戦略に従って、持ち前の文章記述力でひたすら記載を続けていくだけです。文章力で落ちた落とし穴を、戦略の切り替えと文章力でなんとか字数を埋めて這い上がった、というのが、私の本試験午後Ⅱのストーリーでした。

字数の補足に対する考え方

 そういう意味では、提出された論文自体は私の本来出力の7割も出ていません。 字数的にもギリギリ+α、って感じでした。

 ただまぁ、怪我の功名もあったかなぁと思うのは、各設問の末尾を補足するときに、少し話に深みと言うか、きちんと付加情報を追記できたかなぁ、と思っています。

 例えば、さっき触れた費用負担の話と、論文設計で書いたノウハウの形式知に関する話を本文に書いた後で、末尾の補足で少し掘り下げたりしています。

 ベンダーがシステムを納品した後、納品された方が文書だけ見て即日そのまま使えるわけないだろうと思ったので、引き継ぎ期間中のサポート契約は必要だよね、と。一方でサポート契約の費用ってのは実務でもよく交渉事になっていたので、交渉しに行きましたって書く、なんてことをしていました。

 字数不足については、補足のための時間さえあればあまり心配することはなくて、本文内に記述した事実をフックとして、色々膨らました内容を追記すればフォロー可能 なんですよね。やはり書きすぎの方を警戒すべきだなぁ、と思います。

試験時間終了後に訪れた、私の試験終了

 どうにかギリギリで文章を書き終え、製品、システム概要説明用紙を埋めた後2、誤字脱字のチェックと、最小限の流れの確認をしたところで試験終了の合図。いつも演習で実施していた設問の充足度や論旨の妥当性を確認することなく、私の論文は手元から回収されていきました。

 周りの受験者が開放感あふれる顔で帰り支度をしていく中、ただひとり私だけが浮かぬ顔をしていて。ずーっと頭の中で、

  • 問で聞かれたことを、きちんと論文で回答できていたのだろうか?

 と検証していました。私の中で試験はまだ終わっていなかったのです。

 ほとんどの人が退出した後で、おもむろに立ち上がり、帰路につこうとするも何となく帰れず。そのままキャンパス内のベンチに座って、ずーっと問題用紙の問3を眺めていました。

 もちろん、論文設計上は各設問に対して章構成で備えているので漏れはないはずなんですが、記述内容が読み手に響くだろうか という点を、まだ脳内に残っている論文の残滓と問題文を照らし合わせながら、じーっと考えていました。

 そのまま15分ぐらい経ってから『まぁ何とかなるだろ』と、私の口からふいに言葉が出た瞬間に、私のITストラテジスト試験は終わりました。

 私はよく旅行をする際に、観光地を堪能する暇のない忙しない旅行をした後で、旅行記を書きながら回顧して追体験することが多いんですが、まさかそれを情報処理技術者試験でやるとは思いませんでしたね。

 で、それから2ヶ月後に、頭書の報に接した、という次第です。

さいごに

 大分長くなってしまったので、この内容がどれだけ役に立つか、どこまで受験者の血肉になるかはわからないのですが、

  • 企画部門、事業戦略部門、コンサルタント以外のエンジニアでも、
  • エンプラではなく組み込みのエンジニアでも

 (一応最難関ということになっている)ITストラテジスト試験を突破できる、ということを伝えられれば、と思っています。

 ITストラテジストの前身であるシステムアナリストは、私がIT業界に入った頃は雲上の資格で、どういう立場でどういう知識が必要なのか想像することさえできませんでしたが、気づけば私もスタートラインに立つ資格を得たのかなと。

 机上とはいえ、技術を商売の観点で捉えなおして理解する発想と立ち位置の転換を体験しつつ、エンジニアの思考、フレームワークとは異なる考え方を体感できたという点、今後の職場で求められる立ち位置的にも有意義な活動だったように思っています。

 ひとまずこれで私のキャリアパス上必要となる高度区分はすべて取得したので、私は一足先にIPA試験から卒業します3が、以上、IPA資格を通して知識と視野を広げようとする方々の参考になれば、私としても何よりの幸いでございます。


  1. D社としては『だって御社で稼働させるんでしょ?』って言いながら費用負担を折半させつつ、自社資産のセキュリティを担保するという、だいぶ虫のいい話なんですけどね。

  2. 『あなたの役割』の所で、ITストラテジストにぴったりハマる役割がなかったので、"システムアーキテクト"に丸を付けて答えてましたね。設問アでも定番の『私は、ITストラテジストとして〜』って書く余裕がなかったので、"システムアーキテクトとしてストラテジスト的な仕事をした"みたいな伝え方になっているはずです。

  3. 残り4つは私にとっては『ラスボスを倒した後のエンドコンテンツ(やりこみ要素)』。挑戦も可能ですが、もっと他にやりたいことがあるので、さしあたりそちらを優先します。コンプしたくなったら戻ってくるかもしれません。

組み込みエンジニアが目指すIoTストラテジストへの道(4)

本試験

 というわけで本試験の会場にやってきたのだ。

会場

 半年前にシステム監査技術者試験を受けた会場と同じ大学で、勝手知ったる会場。

 午前Ⅰの終了時間を過ぎてもしばらく教室に入れなくて、午前Ⅰ免除者が数分待たされてましたね。

午前Ⅱ

 いつもどおり過去問でたいてい押さえられますが、ちょくちょく新問が入っていて、そこから聞いてくるのかー、ってのはいくつかありましたね。

問2 官民データ活用推進基本法などに基づいて進められているオープンデータバイデザインに関して、行政機関における取り組みの記述として、適切なものはどれか。

問11 企業や組織の目標管理の仕組みとしてOKR(Objectives and Key Results)を活用する時、OKRの目標(Objectives)及び主な結果(Key Results)に関する記述として、適切なものはどれか。

 この辺りはボーナス問題と言うか、知っていたほうがベターという位置づけなんでしょうけど、受験者の予備知識次第で難易度が変わってきそうな印象でした。

 いずれにせよ、ここは私も含めて空気のように乗り越える、って感じでした。過去問をちゃんとやってきていれば6割は普通に超えるはず1

午後Ⅰ

問題選択

 ITストラテジストの午後Ⅰは4問出題、かつ1問が組み込み系問題(問4)なので、問4の選択は確定として、あと1問をどうするか、と。

 問1は最近自社でもよく耳にするようになったDX(デジタルトランスフォーメーション)の話だったのですが、いかんせん問題文が長い。

 ITストラテジスト試験の午後Ⅰ過去問を解いて自己採点評価したとき、私自身の傾向として気づいた点があって。

  • 問題文が長い問ほど、正答率が低下する

 という傾向だったんですよ。なので、事前に設定した本試験の問題選択ポリシーの一つは、

  • 長文の問題は避けよ。

 という極めてシンプルなポリシー。

 午後Ⅰの問題選択にあたっての最適なポリシーは、区分によっても、受験者の予備知識によっても大きく変わるところなんですが、ITストラテジスト試験の午後Ⅰ攻略の一般原則としては、上記は結構有効だと思っていて。

 他の試験区分だと、表や図を探したり、複雑な計算をする代わりに長文の問題を解く、って選択の仕方をしたりするんですが、ITストラテジスト試験の答えは、基本的に日本語の問題文にしかないわけですよ。

 午後Ⅰの解答時間が90分しかなく、自身の日本語読解量が有限であることを考えると、なるべく早く問題文を読み解いてしまったほうが、解析と解答に要する時間を多く取れるな、と。

 このポリシーで2019年度問1〜問3の問題を選ぶとしたら、選択肢は一つしかありません。設問記述含めて4ページしかない問3で確定です。

 で、実際問3を解いてみると、何の予備知識も要求していない割にはかなり簡単で。おそらくここの問題選択は適切だったなぁと思っています2

組み込み系問題(問4)

 問4は、Web系やオープン系と違って、どうしてもB2B商流に束縛され、会社の殻にこもりがちな組み込み系メーカ企業にあっては非常にあるあるな環境の中、顧客からの要求に答えるだけでなく、逆にレバレッジをかけて自社の価値を高めていくという、組み込み屋として非常に理想的な戦略が書かれていて。

 問題を一通り解いた後で、理想事例ながら、そのたくましさに思わず感心してしまいました。組み込みストラテジストとしてはかくありたいものです。

 ひとつだけ残念だったのは、設問3(2)で、『空飛ぶクルマ事業』を答えそこねたこと。

災害時の救急搬送や迅速な物資輸送などを想定した"空飛ぶクルマ"の構想と、その実現に向けたロードマップを示した。

 このフレーズは見てたんですが"事業"という言葉には結びつかなかったですね。ここに書かれているのは政府の構想であって、直接事業化することはできないもの、という印象を問題文から受けたので。私の予断といえば予断なんですけど、問題文として両者をつなぐ表現があったほうが、誤解がなくて良かったですね3

 さて。今回はちょっと短いですがここで切りましょう。

 午後Ⅱはこの試験の特徴通り、これだけ練習してきた私にとって(むしろ私自身のために用意されたかのような)大きな罠が待ち構えていて、文字通り最後にして最大の敵になったので、次回に詳しく書いておきたいと思います。


  1. あらゆる試験区分の午前問おなじみのデルファイ法とかも出てましたしね。ほとんど使ったことないんですがあまりにも聞かれまくるので、もはや脊髄反射で答えてましたね。

  2. 正答率が高すぎて配点調整をするという、噂の『逆下駄』リスクはあるんですが、長文に圧倒されて回答できないよりはるかにマシです。

  3. という(採点講評に対抗した)出題者に対する解答者からの解答講評。

組み込みエンジニアが目指すIoTストラテジストへの道(3)

午後Ⅱ

 さて…ここが正念場ですよ。

 ITストラテジスト試験が情報処理技術者試験最難関と呼ばれる最大の理由…それはおそらく論文の難易度です。

 普通のエンジニアからすると、大きく2つの障害があると思っていて。

  1. 事業課題と直接対峙した経験がない
  2. 論文スキルの高いライバルと競わなければならない

 敵が持つこれらの特性を変えることはできないので、合格したければ自分を変えていくしかありません。 気を引き締めていきましょう。

 あ、論文試験初めてって人は、システムアーキテクトの論文に関する過去記事をお読みください。そこに書いてあることは知っている、という前提で書いていきます。

事業課題と対峙する

 多分ですが…実装とか設計とかプロジェクト管理といった、現場で開発力を駆使してきたエンジニアのほとんどは、こんなことしたことないと思うんですよ。特に所属する企業の規模が大きければ大きいほど。

 ところがそれを容赦なく迫ってくるのがITストラテジストの論文です。

 例えば2018年度。これなんかは大上段で来ます。

問1 事業目標の達成を目指すIT戦略の策定について

設問ア あなたが携わったIT戦略の策定について、事業概要、事業目標、実現すべきビジネスモデルまたはビジネスプロセスについて、事業特性とともに800字以内で述べよ。

設問ウ 設問イで述べたIT戦略の実現のために、あなたは経営層にどのようなことを進言し、どのような評価を受けたか。

 経験がある向き、例えば企画部員、事業戦略部門の人、コンサルタントといった人々は、自分の経験を書けばいいでしょう。

 一方で、正攻法でITストラテジストの論文に挑む我々エンジニアとしては、まず最初に、

  • 持ち込んだ開発経験を元にして、どうやって事業課題と対峙するか

 ってのがポイントなんだろうな、と。

(かつて存在したであろう)事業課題を想起した上で対峙する

 システムアーキテクト試験以来発揮され続けてきた妄想力を、今回私はこの方向で使うことにしました。

 というのも、我々が日々開発しているプロダクト、サービスにしても、源流をたどると必ず事業課題にたどり着くはずなんですよ。会社は伊達と酔狂で仕事をしているわけではないので。

 例えばですね。2017年度問2。

問2 新しい情報技術や情報機器と業務システムを連携させた新サービスの企画について

 この演習で私が持ち込んだシステムは『画像認識を用いたリテール売り場向け顧客行動分析システム』。新技術としてIoT(カメラ)とAI(動画認識)を使うことになりますね。

 仮に書き手がこのシステムを設計実装したエンジニアで、システムの全体像や概要設計を知っているのだけれど、このシステムの企画背景を知らないとしたらどうするかと言うと、社会情勢や顧客、作り手の状況を含めて推察していくわけです。

  • このシステムの顧客は誰だろう? → リテール向けってことは小売店(事業概要:顧客)
    • 売店の事業課題は? POSはあるはずだが…。
      • POSは個数だけしか把握できない。売り場における消費者の購買行動がわからない (事業特性)
      • 売り場で消費者が興味関心を示す商品や、新商品の導入効果をリアルタイムで特定してフィードバックサイクルを早く回したいのでは? (新技術の必要性)
        • 売り場にカメラを設置して、消費者の行動パターン(取り上げた商品、他商品との比較、パッケージのどこを見たか)を消費者の属性情報と合わせて吸い上げ、蓄積して分析すると、上記の情報が取れる。これを元に仕入れを改善 (検討したビジネスプロセス) すれば、効率よく小売できそう (利用者の便益)
  • このシステムを作ったのは誰だろう? → SIer? もっとマーケに関心のあるプレイヤーでは? 広告代理店とか (事業概要:自社)
    • なぜ広告代理店がこんなものを作るんだ?
      • マーケティングを効率化したいのでは?
        • 紙のチラシは最近単価が下がってきていて収益性が悪いし、捨てる人も多いので効率が悪い。と言ってメールはスパムフィルタで弾かれて届かないことも多い。(事業特性)
        • 店舗特性に適したマーケティングを行えれば、読んでもらえる広告メールを効率良く送れるし、消費者の受けもいい (利用者の便益)
        • メールトラフィックと広告チラシを減らせればコスト削減 (投資効果)
      • 導入実績が増えてくれば、自社に分析ノウハウも貯まる。他の小売店に水平展開すれば自社の市場を拡大できるのでは (事業戦略)

 太字で記述したのは設問ア、イで求められている項目です。こんな形で、お題として与えられたシステムから、逆方向にニーズを遡って想起していくと、論文設計の基本的な所はざっと埋められるようになります。

 もちろん、受験者がこれらの情報を直接知っているのであれば、そのまま記述すればいいんですが、知らなければこうやって妄想力を働かせ、自分が携わってきたシステムの 『事業上の必要性』を浮き彫りにして論文設計 することで、ITストラテジスト午後Ⅱの論題とひとまずは渡り合うことができるはずです。

 こうしたビジネス上の必要性に迫ることなく、単に『システムを導入しました、効果はこんな感じでした』程度だと、多分勝たせてくれないんじゃないかなぁ…と思います。

"分析"を示す

 事業課題の次に考えるべきなのは、ITストラテジストとして、どのように吟味、検討、分析したかということでしょう。大抵設問イのメインの質問事項です。

 特に事業環境、投資効果、実施結果等の 分析については、IPAのページにもある通り『期待する技術水準』にはっきり示されています1

https://www.jitec.ipa.go.jp/1_11seido/st.html

 (1) 事業環境分析、IT動向分析、

対象となる事業・業務環境の調査・分析を行い、

 で、求められる分析の中で意識すべき分析が2種類あってですね。

  • 効果分析
    • その戦略を実行することで見込まれる投資効果や、実施した結果得られた利益など。
  • 市場分析
    • 参入する市場や自社、他社の立ち位置を含めた環境分析。主として問3で多く求められる。

効果分析

 例えば先程の問2だと、

設問イ 設問アで述べた事業戦略を実現するために…(中略)検討したビジネスモデルまたはビジネスプロセス、利用者の便益、投資効果を明確にして、800字以上1600字以内で具体的に述べよ。

 『投資効果』を『具体的に述べよ』なので、コスト削減万歳とか、市場拡大で爆益とか、そういうフワッとした話をしているわけには行かなくなります。数字で出さないと具体的とは言えないでしょうから。

 これについても、最初から数字を持っていれば、それをそのまま書けばいいんですが、持ってない場合は、投資判断に必要なレベルである程度数値を作ってしまってもいいと思います。

 例えばさっきの『画像認識を用いたリテール売り場向け顧客行動分析システム』の例で書くと。

イニシャルコストはカメラとクラウドへの回線接続料 1店舗当たり100万程度

A社システム構築費用は店舗数で分散させて店舗単位で賦課 1000店舗導入させて店舗当たり100万程度

顧客側のランニングコストは1店舗当たり月数万程度、A社運用費を増分して月額20万程度

顧客側の改善効果は1店舗当たり月150万円程度を見込み

よって初期投資費用が店舗当たり200万程度を要するが、顧客側の改善効果が月130と非常に大きい

A社側では無駄なダイレクトメールを打たずに済むので、全体で月50万程度のコストを低減できる

A社側の収益は初期費用100+ランニング15万/店舗、かつ月50万のコスト削減だが、店舗数が少ないうちは旨味が少ない

A社側のシステム構築費用回収は店舗展開速度次第だが、A社は小売り業の顧客を多く抱えているので、水平展開すれば数年で回収可能と試算している

 この数字が事実かどうかはさておき、とりあえず収支がプラスになりそうな目論見、ってのは分かるんじゃないでしょうか。よほどおかしな算数をしていない限り、これが事実かどうか、結局の所採点者に判断する術はないのですから。

きちんと数値ベースでシステムを検討して投資判断をできるかどうか、裏付けする数値を出せるかどうか、というのは、具体的に述べよ、という題意から見ても重要なので、怠りなきようにしましょう。

市場分析

 これは組み込み系問題の問3でよく出てくる分析です。

 例えば2018年度問3。これはテーマそのものが市場分析です。

問3 組込みシステムの製品企画戦略における市場分析について

 2017年問3。

問3 組込みシステムにおける事業環境条件の多様性を考慮した製品企画戦略について

設問イ 設問アで述べた製品企画の際に分析した内部環境、外部環境の各要素を挙げ、それぞれどのように分析したか。

 前回話をした、

午後Ⅱを分析演習の場とするのです。

 の出番はここで、論文演習中に、求められている分析を実際にやってみればよいのです。

 2018年度問3の設問イを何度かやってみる、というのが面白いかもしれませんね。

設問アで述べた新製品の投入を考えた市場について、どのように調査したか。分析手法の選定理由、分析方法、分析内容及び立案した戦略について、800字以上1600字以内で具体的に述べよ。

 私はIoTセキュリティデバイスを新製品として市場分析を行う演習をしてみたのですが、ここでPEST分析と5Force分析を併用する、という論旨展開を行いました。

 そもそもA社にとって当該デバイスの投入は、過去に類を見ない新製品開発であり、市場の評価自体が存在していない。このため、投入市場そのものの周辺環境を調査したうえで、まずは開発投資に値するか否かを見極める必要がある。このためにPEST分析を用いてIoTデバイス市場自体の将来性を検討する。

 次いで、当該デバイスはセキュリティの汎用部品であるため、具体的な応用用途が存在しない限り、需要を想起しづらい。よって、売り手としては需要が発生し得る産業分野を特定し、当該産業分野に対する販促活動や技術蓄積を行うことで、速やかに、かつ確実な市場収益につなげる準備をしておく必要がある。よって、候補となる産業分野を絞り込むために5Force分析を行った。

 分析手法は他にもアンゾフのマトリクスとかSWOTとか色々あるんですが、外部分析を伴う分析手法を展開したほうが、自社の独りよがりになりづらいので良いと思います。

結果を作ってみる

 で、実際にやったかのように結果を作ってみます。

 ガチで調査会社に頼んでリサーチする必要はありません。5Forceなら、現在の自社の立ち位置を流用してもいいですし、PEST分析なら、Google先生に動向を聞いてみるのもいいでしょう。

 例えば、Google先生から得られた情報や、IoTセキュリティに関する資料を読み込むことで、こんな感じで実際にPESTを行ったかのように論旨展開することができます。

結果、以下の傾向が明らかになったことから、IoTセキュリティデバイスは、市場から需要が発生する可能性が高いと見極めた。

・P:経産省のIoTセキュリティガイドラインが示された。

・E:IoTにおける産業界の投資が活発になっている。

・S:Miraiに代表されるようなIoTセキュリティ攻撃が活発化し、社会不安が増大している。

・T:Webセキュリティ等のソフトウェアセキュリティが、ハードウェアのバックアップを必要とし始めている。

 PEST分析の結果をこうして論文に書こうとすると、PEST分析がどういうものか、よく考えて記述することになると思うんですよ。分からないと頓珍漢な論文になってしまいますから。

 こんな感じで、実際に分析結果を作るときに、分析手法が肌感で分かるってわけです。分析手法が今ひとつ頭に入らない、って人は、こういうきっかけを作ると論文事例蓄積も兼ねられてお得なので、お試しあれ。

経営陣との対話

 最後の関門はこれです。大抵設問ウで、面倒くさいオジさん連中に目論見を説明して、フィードバックを受けることになります。

設問ウ 設問イで述べた新サービスにおいて、新サービスの導入でどのようなことを検証するためにどのような対応策を立案し、経営層に提案したか。

 ただ、経験がなければここは結局ロールプレイです。

 経営層と話をしたことがある人であれば、その人の顔を思い浮かべながら、自身の職場でどういう趣旨で資料をまとめ、どういうフィードバックが得られる 『であろうか』 を想起しながら書くことになります。

 私も役員クラスと話をしたことは数回しかなかったのですが、

  • 基本的に経営層は技術そのものには全く関心を示さない

 ので、何を伝えるにせよ、予算、会社の立ち位置、体制、収益のようなレイヤで話をすることになろうかと思います。

 個人的に気をつけていたのは、

  • 自身の立てた戦略、目論見が満点である、という評価には絶対にしない

 ことですかね。他人なんですから絶対考えの相違はあって、経営視点からの何らかのダメ出しはあって然るべきもの、として評価を記述するようにはしていました。

 いわゆる 『打たせて取る』 戦法で、このダメ出しを受けてフィードバックとして自身の目論見を改善した、という流れにすると、話としては自然ですし、オレオレストラテジストではないことを暗に示すこともできます。

論文スキルの高いライバルとの戦い

 これについては正直なところ、楽に勝てる方法はありません。

 システムアーキテクト試験の論文の記事で示したような、論文設計の基本を身に着けた上で試験に臨む、ってのは当然なんですが、正直な所大半の人間がその辺を弁えた人たちなので、差別化要因にならないんですよね。

 私から何が言えるだろう、と思ったんですが、強いて言うならばこの辺でしょうか。

  • 空気のように読み、空気のように書ける ようになっておくのが最強。
    • たくさん本を読み、たくさん文章をアウトプットすること。
    • 要は国語力を鍛えよ、ということ。Blogを書き続けていたら論文パスした、って人もいましたが、おそらく両者には大きな相関があります。
    • 今回、私がどれぐらい空気のように書けたか、というのは、本試験でやらかしたヘマも含めて後でご紹介します。
  • 設問で聞かれていることを 題意を外さず、漏れなく答えること。
    • おそらく論文評価C以下の人は、設問で聞かれている事項に対して『題意を外しているか』『漏れがある』んじゃないかと推察しています。
    • 自分が言いたいことではなく、出題者の聞きたいことを答えてあげましょう。手持ちのネタを出題者の聞きたい内容に合わせて書けるようになりましょう。
  • HowよりもWhy,Whatに重点を置くこと。
    • ITストラテジストの場合は、具体的な要素技術、実装方式ではなく、企業やユーザが欲しい物 の話をしましょう。例えば収益新しい仕事新しい市場利用者の便益などです。
  • 良きストーリーテラーになる こと。
    • システム監査技術者以外の試験には、大抵流れがあるんですよね。現状→受験者が実施したこと→内外の評価とフィードバック、という。
    • この流れを自然に伝えられることで、論文がある種の物語性を帯びるようになり、読み手の頭に入りやすくなります。
    • 自然に伝えるためには、以下のことが重要になってきますが、一言で言うと 『読み手のことを考えた文章になっている』 かどうかです。
      • 事実を必要なだけの言葉で過不足なく伝え、
      • 前の文章と後の文章に連続性がありつつも、
      • 段落で話題が区切られており、
      • それぞれの行動に必然性がある

 まぁなんと言うか、『合格したければ、合格できる実力をつけることだよ』みたいな、言われる側からすると何の役にも立たないアドバイスをしているような気もしますが…論文スキルという話をするなら、結局のところ、

  • 事実でない事項も含めて、いかに自然に、論理的に相手の頭に文章を入れるか

 ってことでしかなくて、結局は論理的文章の記述力に帰着してしまいます。

 私は毎回これを培うために、試験1回あたり大抵10本ぐらい論文作成をしています。結局の所練習は嘘をつかないんですよ。

 ただ、どうしても文章が苦手でしょうがない、って人は、先述した『合格論文の書き方・事例集第5版』を最初の足がかりにすると良いです。

 Blogを書くなり、自分のペースで毎日文章をアウトプットしてもいいでしょう。

 その上で、上手な文章を書きたくなってきたら、この本をおすすめします。

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 基礎編 (ちくま学芸文庫)

  • 作者:結城 浩
  • 発売日: 2013/04/11
  • メディア: 文庫

数学文章作法 推敲編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

  • 作者:結城 浩
  • 発売日: 2014/12/12
  • メディア: 文庫

『数学』とありますが、技術文書全般に通用する名著です。最初は意識しながらだと思いますが、型が身につくと、良い文章が自然に出てくるのではないでしょうか。

 こんなことを考えながら、前述の通り10本(PC5本、手書き5本)ぐらい書いて本試験に望みました。

 これだけ書いてまだ書き足りないことがあるような気もしますが、気がついたら適宜補足します。

 いやー長かった。以下次号。


  1. この試験の前身が"システムアナリスト"であることを考えると、さもありなん、という感じ。

組み込みエンジニアが目指すIoTストラテジストへの道(2)

 というわけで続き。午前Ⅱ〜の勉強に対する、私の感覚とアドバイス的なものを書いていきます。

午前Ⅱ

 今回はシステム監査技術者合格権限を使って午前Ⅰはスキップなので午前Ⅱからなんですが…うん…まぁ…ここまで来てしまうと、あまり言うことはないですね。

 ITストラテジストに限らず、どの区分においても午前Ⅱは区分固有知識を問うだけなので、一言、『過去問やっとけ』 で終わりではあります。

 それだけですべてを察し、空気のように午前Ⅱを乗り越えてくる熟練者と戦わなければならないのが、ITストラテジスト試験の厳しさの一つでもあります1

不正解選択肢をすべて拾い上げて理解する

 が、エンジニアのスキルセットだけで過去問に挑むと、未知の知識ばかりで辛いと思うので、先ほど紹介した、『この1冊ですべてわかる 経営戦略の基本』を読むと同時に、

  • 正解選択肢だけではなく、不正解選択肢でわからない言葉をググって調べておく

 といいと思います。

 ペネトレーションプライシング(浸透価格戦略)と同時に、スキミングプライシング(上澄み吸収価格戦略)も覚えてしまう。PEST分析を聞かれたら、不正解選択肢に書かれている文章から、3C分析、SWOT分析、ファイブフォース分析までまとめて概念を勉強してしまうのが効率が良いです。

マーケ、戦略系用語を肌で理解するには

 エンジニア畑固有の課題としては、仕事で使い慣れているわけでもないマーケ系、事業戦略系の用語です。

 文言で概念を勉強しても、肌感と言うかイメージで理解できないのが、畑違いゆえのハンデになるんですが、実はこの辺を克服して、分析手法を体で覚える良い方法があるのです。

 午後Ⅱを分析演習の場とするのです。

 詳しくは後述します。

午後Ⅰ

 システム監査技術者試験を経験した後で、ITストラテジスト試験の午後Ⅰを見た私の感想は、

  • 何これ、めっちゃ分かりやすいんだが!?

 でした。2

 もう一つの感想は、

 という印象。

システムアーキテクト試験の上流進化系

 システムアーキテクト試験の場合、システムの個別の構成要素(DBのフィールドとか、NW内のサーバとか)と、そのつながりについて聞かれることが多いですが、大抵、

  • 現行システムで不足している機能とか
  • なぜその設計にしたかの理由とか
  • システム化対象業務の特性とか

 実は結構WhatやWhyを聞かれているんですよ。

 システムアーキテクト試験でチラホラ聞かれるこの手の要件絡み、理由絡みの問題について、もう1段上位の要件定義、経営課題的な背景を使って全面的に聞いてくるのが、ITストラテジスト試験の午後Ⅰなのかーというのが私のイメージでした。

 システムアーキテクトと違うのは、技術的構成要素間のつながりではなく、要求やニーズ、現行システムの特性、リスクといった抽象的な事象間の関連を元に質問してくる ところです。

 例えば2018年問1。

設問2 A社は、新サービスによって、顧客のどのようなニーズに答えようと考えているか、25字以内で述べよ。

 問1はコールセンターのチャットボット化に関する問題なんですが、現行のコールセンターの特性とユーザニーズが、問題文に暗に示されているので、つなぎ合わせて答えていけば、普通に正答にたどり着けます。

自動音声応答の案内によって、顧客が案内の途中で電話を切ってしまうことが多く、

問い合わせをしてきた顧客に簡単なアンケートを行った。その結果、問い合わせをした顧客の多くが、電話やメールで問い合わせをする前に、ヘルプの検索などのセルフサービス機能での解決を試みていることが分かった。

 1対1でわざわざ問い合わせを起こすのって面倒じゃないですか。こうした顧客のニーズはきちんと問題文に示されているので、

新サービスによって自ら問題を解決できること

 サポートの手を煩わせず自己解決したいのね、ってな解答を、ちょっと想像力を働かせて上記の文章から引っ張ってくるだけの、要は国語の問題です。

ITストラテジストらしい午後Ⅰの設問

 市場要求への推察を行わせるような問題は、ITストラテジストの固有問題と言えるかもしれません。例えば2018年問4。

設問1(2) U氏が、今後は海外市場の高層ビル向けの製品にも注力すべきと考えた需要面の理由を、30字以内で述べよ。

 まぁでも、この辺も言うほど難しくないんですよ。ちゃんと書いてあるので。

新興国の都市部に高層ビルの建設予定が多く、集中した需要が見込まれる。

 あと、複数のステークホルダの要求を同時に満たすような解決策を提案させる、なんて問題もこの区分らしい問題かも。2017年度問1。

設問2(1) 本文中の下線⑤の、A社の強みを活かしたあるサービスについて共同で実証検討を開始する提案の内容について、30字以内で述べよ。

 この辺はA社と、A社と付き合いのあるP社、2社の特性を合わせると問題解決できる系です。実はP社には困りごとがあるんですよ。

近年、P社の整備部門への新規要員の採用が難しく、

整備部門を縮小しつつも、大型車両の運用を継続できる施策の検討

 一方でA社には強みがあります。

ES部(エンジニアリングサービス部)は(中略)顧客に密着した高い品質のサービスを提供することで業界の評判も高い。最近では、他社製品への対応を有償で依頼されることも増えてきている。

 これらを個別ではなく組み合わせることで、

  • ん? A社の他社製品修理技術ってP社に高く売れるんじゃないか?

 と商売根性を働かせると、

P社の整備部門の業務をA社のES部が受託する提案

 と言うWin-Winの解決策を解答に書けるわけです。

商売根性を働かせる

 この、『商売根性を働かせる』という点、特にエンジニア畑からこの区分に挑む人にとっては、午後Ⅰ、午後Ⅱを安定して戦うために必要となる、極めて重要な発想の転換ではないだろうか、と私は思っています。

 最初にもちょっと触れましたが、ITストラテジスト試験を貫く大テーマは、『ITを利用していかに稼ぐか』 なのです。コストを減らす系にせよ、市場を選ぶ系にせよ、素早く市場展開させる系にせよ、ほとんどすべての設問が、直接間接にこれを聞いてきています。

 技術畑で長く仕事をしていると、売り先を決めるのはマーケの仕事、商談取ってくるのは営業の仕事、量産するのは工場の仕事だろ、と、自分の視野を開発とIT技術の範囲に限定してしまいがちで、それ故に、『ITを使ってどう稼ぐか』という、金と市場に関する嗅覚が欠落してしまいがちです。

一方で、こうした嗅覚があると解きやすい というのがITストラテジスト試験の特徴の一つで。

  • ん? この文言だと、ここのコストを減らして固定費を下げられるじゃん
  • もっと売れる市場があるって書いてあるよね? そこに売りに行こうぜ
  • このステークホルダ、我々が知らない技術持ってるじゃん。組めば自分で作らんで良さそう

 みたいな解き方ができるんですよ。実際そういう解答になっていることが多いです。

 ITストラテジスト試験の午後1で、つかみどころのない問題にお困りの方は、一度、『この状況を利用してどう金を稼ぐか?』 という視点で文言を捉えなおしてみると、ひょっとすると糸口がつかめるかもしれません。

定石を使う

 あと、前述した情報処理教科書には、『トップダウンアプローチ』と『対策標語』というユニークな解き方があるので、これを先に念頭に置いてから挑むのもありです。

 『対策標語』は、ITストラテジストとしての見解やノウハウを、設問の状況に応じて即適用するための指針の集合体と言っていいでしょう3。これを設問に対してズバッと当てはめて解答を導き出すのが、『トップダウンアプローチ』です。

 例えば、『コアコンピタンスで勝負せよ』とか、『AIといったら学習』とか、『遊びが発生したら連携して活性化せよ』とか。午後Ⅰであるあるな状況に対して方向性を打ち出してくれます。

 この辺を覚えるのが大変、というのが先述した話ですが、一通り押さえておくと午後Ⅰの戦いがぐっと安定するので、最後におすすめしておきます。

 とりあえずこんなところかしら。不足していたら適宜補足します。

 午後Ⅱは次回に回しましょうか。ではまた後ほど。


  1. 2019年度のITストラテジスト午前Ⅱ突破率は91.4%で、他の高度区分より10%以上高い。

  2. システム監査技術者試験の午後Ⅰの理解難度を実感してもらえれば。そういう意味ではドラゴンボールの悟空の重力修行じゃないですが、システム監査の掴みどころのない午後Ⅰを経験してからこっちに来ると、割と軽くなるんじゃないでしょうか。

  3. 情報処理安全確保支援士(情報セキュリティスペシャリスト)受験経験者なら、『ポケスタ』の『即効サプリ』に近い、と言うと通じるかもしれない。

組み込みエンジニアが目指すIoTストラテジストへの道(1)

はじめに

 はい。いつものとおりです。

f:id:dimeiza:20191222171628p:plain

 この度ITストラテジスト試験に合格しました。

ITストラテジストとは何ぞ?

 WikiPediaによるとすごいことがいっぱい書いてあるんですけど。

ja.wikipedia.org

事実上の情報処理技術者試験制度の頂点に君臨する区分

あらゆる国家資格の中でも最難関級の部類に属し、その難易度は国家公務員総合職採用試験、公認会計士試験、税理士試験などと肩を並べるレベルと言われることも多い。

高度試験の中でも最高峰の区分と呼ばれることも多い。

IT系の資格では唯一、弁護士、公認会計士、医師、技術士等と並び、厚生労働大臣によって「専門的知識等を有する労働者」に指定されており、労働基準法において特例扱いの対象となる。

本資格を取得した社員に与える褒賞金の額を最大に設定する企業が多く、中には100万円を超えるものもあるほどである。

……。

…いや、どうかなぁ…とあまりのハッタリ感に取得した人間のほうが圧倒されそうです。 (とりあえず100万円はもらえない)

実際のところ

 実情はIPAのページを見たほうがいいでしょう。

www.jitec.ipa.go.jp

ポイントはここで。

2.業務と役割

ITを活用した事業革新、業務改革、革新的製品・サービス開発を企画・推進又は支援する業務に従事

3.期待する技術水準

事業企画、業務改革推進、情報化企画、製品・サービス企画などの部門において

 この資格のポイントは、『経営』とか『企画』というキーワードです。端的に言うと、

  • 『ITによって、どのように自社の競争優位を獲得して金を稼ぐか?』を考える仕事の資格

 と雑にまとめてもいいかもしれません。

 ITエンジニアの仕事って、基本的に、

  • IT技術を使って、どうやってプロダクト・サービスを効率良く作って運用するか?

 すなわちHowの領域に属するもので、IPAの大半の資格の価値はほとんどここに帰着しますが、ITストラテジストはちょっと毛色が違っています。

 つまり、企業の経営視点上から、

  • 自社としてはどの市場に参入、投資すべきか?
  • 誰をパートナーとして何を交換すれば、競争を優位に進められるか?
  • 市場の困りごとは? リスク要因は? どこを守りどこを攻めるべきか?

 といった、ITを企業や社会に敷衍する上での全体的な戦略を考える能力を問う試験です。この領域はもはやエンジニアと言うよりも、事業企画系、経営戦略系の仕事なんですよね。

ITストラテジストが『最高峰』という誤解

 ITストラテジストが前述のとおりやたら持ち上げられるのは、この試験の前身であるシステムアナリストの圧倒的な難易度(年齢制限+合格率5%という超難関)が影響している側面もありますが、我が国の経営と技術のヒエラルキーからも悪影響を受けているんじゃないか、とも思っています。

 経営や企画が上、技術が下という考え方でIPAの資格を見てしまうと、どうやっても経営や企画の能力を問うITストラテジストを持ち上げたくなってしまうのです。

 今のITストラテジスト試験はかつてのシステムアナリストよりずっと合格しやすくなっていますし、エンジニアたる我々はこれを正視眼で見る必要があります。

 すなわち、この試験は企画者、戦略立案者のための試験区分でしかなく、技術力、運用力を問う他の高度試験区分と何ら上下の差はありません1

 これはIPAのWebページの図にもはっきり示されているところです。

www.jitec.ipa.go.jp

 ただ、ITストラテジスト試験はもう一つの例外であるシステム監査技術者試験同様、

  • 単なる技術知識だけで太刀打ちすることが難しく、別レイヤの知識が必要になるのと、
  • HowではなくWhatやWhyを考えるという、一段抽象化した思考様式が必要になる

 ので、エンジニアのスキルセットだけだと手強いっていう話です。

 この辺の誤解を説いた上で、エンジニアの私がどのようにこの試験に挑んだか、を話していこうかと思います。

事前状態

  • 高度情報処理技術者は4つ(SC,ES,SA,AU)取得済み。
    • 論文試験2本、かつ両方とも一発突破。
  • ITストラテジスト試験の受験経験はない2
  • 基本的には技術部署にいる技術仕事な人。事業企画系部隊にいたことはない。
    • 仕様書書いたりコードを書いたりはんだ付けしたり…。
  • ただ、最近上司から商品販促、戦略系の相談が増えてきた。
    • 『どの市場に売り込むべきだろう?』『だれが最後に勝つんだろう、そこと組みたい』
  • もともと戦略的に、俯瞰的に考えることが好きなタイプ3
    • ネトゲなどでは個人技を披露するより参謀っぽい役回りをすることが多かった。

 おそらく、本人の特性、環境ともに、割とこの試験に向いている状態で受験しています。

 所属部署でも戦略的俯瞰をして打ち手を考える需要が増えてきた中で、その役割を担う意味でも取る価値はあろう、という動機もありました。

教材について

 今回もシステム監査技術者試験同様、独学で参考書と問題集を買って臨んでいます。

 えーとですね…。

試験対策本

情報処理教科書 ITストラテジスト 2019~2020年版

情報処理教科書 ITストラテジスト 2019~2020年版

  • 作者:広田 航二
  • 出版社/メーカー: 翔泳社
  • 発売日: 2019/03/18
  • メディア: 単行本(ソフトカバー)

2019 ITストラテジスト「専門知識+午後問題」の重点対策 (重点対策シリーズ)

2019 ITストラテジスト「専門知識+午後問題」の重点対策 (重点対策シリーズ)

 情報処理教科書は色々買ってるんですけど、このITストラテジストの情報処理教科書はなかなか当たりです。特に午後Iの解答に迫るための方法論、午後I特有のもやもやについての記述もあり、覚えることは多いですが対策力は高めです。

参考書

 実はこっちのほうがポイントなのです。情報処理技術者試験の勉強をするなら対策本を買うのは当然なので。

 ITストラテジストの主戦場が経営、戦略、企画だと言うなら、その戦場にリーチしないと勝ち筋が見えないじゃないですか。

 とりあえず『この1冊ですべてわかる 経営戦略の基本』の内容を理解していれば問題ありません。ITストラテジスト試験で問われる経営戦略の基礎理論とフレームワークが非常によくまとまっています4

 基本的にはこの辺を揃えて、今までどおりの論文系試験と同じ対策をしてきた、ってだけなんですが、次回以降、もう少し掘り下げていきましょうか。


  1. もっと突っ込んだことを言うと『ITストラテジストだけ取得しても、企画屋としてはともかく、ITエンジニアとしてはまるで大したことはない』まで言ってもいいと思っています。実装、設計、プロジェクト管理等のIT開発の各側面を理解した上で取得して初めて、ITストラテジストが最高峰としての位置づけを有する(開発の全レイヤにおいて活躍できることを意味する)のだ、というのが私の理解です。

  2. そう、今回も一発突破。

  3. でも戦略しか考えてなくて手を動かせないやつは嫌い。

  4. 私はここで教えてもらいました(https://blog.apar.jp/other/12529/)。何事でも先達はありがたいものです。

ならず者IoTエンジニアが由緒正しきシステム監査技術者になってしまった件(4)

午後Ⅱ

 午後Ⅰが終わった後、午後2の答案が配られるまでの間、私は数か月前のことを思い出していました。

IPAへの質問

 システム監査技術者試験の対象者像には、こんな記述があります。

https://www.jitec.ipa.go.jp/1_11seido/au.html

高度IT人材として確立した専門分野をもち、監査対象から独立した立場で、情報システムや組込みシステムを総合的に点検・評価・検証して、監査報告の利用者に情報システムのガバナンス、マネジメント、コントロールの適切性などに対する保証を与える、又は改善のための助言を行う者

 ところが、午後2の論文試験の問題文記述を見ると、組込みシステムに関する配慮がされていないように見えたのです。

 例えば2018年春季の問1。

設問ア あなたが関係する情報システムの概要、アジャイル開発型開発手法を採用する理由、及びアジャイル型開発の内容について、800字以内で述べよ。

 同年度問2。

設問ア あなたが携わった組織の主な業務と保有する情報システムの概要について、800字以内で述べよ。

 組込みシステムを含むシステム監査能力を問う試験のくせに、組込みシステムの知見を基に回答できる設問が同一年度中に全く用意されていないのではないか? と思ったのです。

 これは看板に偽りありで、組込みシステムの知見を積んできた受験者には著しく不利な措置では? と思ったので、直接IPAにこう尋ねてみました。

  • 問題文中に『情報システム』と記述のある問題について、『組込みシステム』における内容について論述し、回答した場合、問題の趣旨に添わない(B以下の判定となる)と解釈されるのでしょうか。

 と。

 するとこんな回答が返ってきました。

午後2(論述式)試験につきまして、組込みシステムに関して論述された場合でも、設問の趣旨に沿っていれば問題ございません。

なお、論述式試験では、設問で要求した項目の充足度、論述の具体性、内容の妥当性、論理の一貫性、見識に基づく主張、洞察力・行動力、独創性・先見性、表現力・文章作成能力などを評価の視点として、論述の内容を評価します。

 回答表現としてはちょっと物足りないですが、質問とセットで見た場合、情報システムと記述された設問に対し、組込みシステムの事例をもとに回答しても問題ない、ということでした。

 というわけで、午後Ⅱを受験する段階では、組込みエンジニアとして解答オプションが3つあったことになります。

  • 文章上、組込みシステムを直接論述可能な問題に回答する。
  • 『情報システム』と記述のある設問に対して、組込みシステムを題材として解答する。
  • 『情報システム』と記述のある設問に対して、組込みシステム以外の仮想事例をベースに回答する。

 このことを答案用紙が配布される前まで思い起こしていました。

実際の設問

 試験開始の合図を聞き、問題用紙を開いた瞬間、私はあっと息をのみました。

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_1/2019h31h_au_pm2_qs.pdf

問1 IoTシステムの企画段階における監査について

 この時ほど自身に対する天佑神助を確信したことはかつてありませんでした。

 完全にホームグラウンド。この設問であれば、監査を行った事例こそ持ち合わせてはいないものの、自身の技術知見をダイレクトに使って回答可能です。

 私が発した質問だけではないのかもしれませんが、情報システム一辺倒での出題形式に対して少し補正がかけられたのかもしれません。

 と同時に、このテーマに対して内心予期していた部分があって、驚愕すると同時にさもありなん、という印象もありました。

実は予測されていた

 実は、このテーマを最初に見たのは本試験の場ではなかったのです。

 この本の462ページにはこんな想定問題リストがありました。

f:id:dimeiza:20190624162311p:plain

 そしてこの想定問題に対する出題例と回答論文例まで書いてあったのです。

f:id:dimeiza:20190622184441p:plain

 で、私はiTECの回し者ではないのでここで言っておくと、実は私、この回答論文の内容には大して目を通しておらず、私自身の論文作成においては全く参考にしていません。

 ここで私が言いたいことはiTECの本を読めなどという対症療法的な話ではなく、

  • 今まで出題されていない分野に対する予想リストを何らかの形で入手、確認しておく

 ことが、準備として有効に機能することがある、という話です。

 というのも、IoTに対する監査に対しては、iTECの本だけではなく、もう1冊言及している本があったのですよ。

  • よくわかるシステム監査の実務解説(第3版)

よくわかるシステム監査の実務解説(第3版)

よくわかるシステム監査の実務解説(第3版)

  • 作者:島田 裕次
  • 出版社/メーカー: 同文舘出版
  • 発売日: 2019/01/25
  • メディア: 単行本(ソフトカバー)

f:id:dimeiza:20190622184500p:plain

 『新しいITとシステム監査』という章に書いてあります。

 システム監査というと、すでに完成したフォーマルな古いシステムに対して何らかの検証行為をするもの、と思われがちですが、むしろ新しい領域に構築されたシステムの方が、ガバナンスもコンプライアンスもコントロールも効いていないばかりか、社会的な影響力が大きく危険であり、現実として種々の事故、事件が発生しているわけです。

 加えて、ともすれば年長者が座を占めがちなシステム監査技術者に対して、絶えず新しい技術領域に対するキャッチアップを怠ってはならない、というメッセージを体現した出題、ともいえるでしょう。

 この傾向性はテーマ監査として、クラウド、サイバーセキュリティ、アジャイル等、新規技術領域に対する出題が例年相次いでいることからもうかがえます。

 監査テーマで不意を突かれないようにするためには、監査というメソッドばかりを注視することなく、IT技術領域全般に対するアンテナとして、監査として新規に狙われやすい領域を意識しておくことが重要かと思います。

私の解答

 これは得たり、と、私は勢い込んで論文設計をメモ用紙に書き始めました。

 といっても、IoTで物は作っているものの、監査に立ち会ったり実施した経験があるわけではありません。

 なので、演習同様、リスクとコントロールを抽出し、題意に沿いつつ実在してもおかしくない事例の構築を行いました。

f:id:dimeiza:20190622184519j:plain

 …読めるわけがない。いやはやまったく、よく本試験で通ったな、この字…。

 ではいつもの通り、略した部分を補って解読しましょう。

  • 第一章 私が関係するIoTシステム
    • 概要 A社の鍵管理PF(プラットフォーム)
    • A社はセキュリティモジュールを売る、鍵管理PFを持つ
    • 自社工場機械向けに暗号データを送って制御する機器を導入
    • メリット
      • 遠隔制御したいのでセキュリティが心配
      • セキュリティを維持しつつ遠隔操作
      • セキュリティモジュールなのでクラッキングしづらく、現場のいたずらも防げる
  • 第二章 (想定されるリスク)
    • 外部からの不正操作リスク
      • 鍵が流出するリスク
      • 不正なデータで操作されるリスク
    • サプライチェーンリスク
      • 不正機器の埋め込みがハード作成時に行われていないか
  • 第三章 (監査手続)
    • 鍵の伝達がセキュアか
    • 不正データ受信時に停止するか
    • 導入時の機器正当性の証明
      • 入手管理、トレーサビリティ
      • 受け入れ時の機器構成確認

 …って書いてあるんですけど、この論文設計メモだけ見ても何をどう書いたのかが、あまり伝わらない気がします。実は本文執筆中に結構脚色しているんですよ。

私が記述した事例

 概略を書くと、大体こんな感じです。記憶をもとに適当に字句を並べているので字数とかは適当。

第1章 私が関係する組織で導入を検討しているIoTシステム

 私の所属するA社は国内各所に工場を有している大手製造業。昨今の働き方改革の流れや、工場の機械を人が直接操作することによる労働災害を防止するべく、自動化、省力化を推進している。

 そんな折に、工場設備管理部署が、セキュリティベンダからIoTセキュアプラットフォームの提案を受けた。

 セキュリティベンダ曰く、

  • セキュリティベンダが売っているセキュリティモジュールを機器に組み込む。
  • セキュリティモジュールには個別鍵が埋め込まれており、セキュリティベンダが持っているプラットフォームで鍵を管理できる。
  • プラットフォームを介して工場機器に制御データを送ることで、プラットフォームとセキュリティモジュールが暗号化された通信路上で制御データを授受し、遠隔からセキュアに機器を制御できる。

 提案を受けた部署は、当該PF導入によって上記メリットを享受できることを期待し、導入の企画検討に入った。

 私は監査部門の人間ではなく、別の開発部隊の人間だが、過去の被監査経験や幅広いシステム開発の知見を基に、監査を念頭に置いたアドバイスをしてほしい旨を依頼され、本件に関わった。

第2章 想定したリスク

 私は監査人の観点に立ち、以下のリスクを想定した。

  1. 外部からの不正操作リスク

    • 鍵が漏洩することで、第三者が不正な制御データを正しく暗号化して送信するリスク
    • 不正な暗号データをでたらめに生成し送信することで誤動作を引き起こすリスク
  2. サプライチェーンリスク

    • ベンダが納品したハードウェアにスパイウェアや不正なチップが搭載されているリスク

 いずれも顕在化すれば、工場の機器を不正に操作されることで事故が発生したり、内部情報の漏洩によって経済的損失をこうむったり、会社の信頼を失墜するなど、大きなダメージの原因となるリスクであり、これを放置することはできない。

 前者は鍵の管理状態(セキュリティ)と、誤動作に対する備え(セーフティ)に関連するリスクである。

 一方後者はIoTデバイスサプライチェーンの正当性確認に関するリスクであり、近年某企業が世界的な疑惑と問題を起こしたことから無視できないリスクと考えた。

第3章 適切性を確かめるための監査手続

 私は監査人ではないが、監査人となった場合は以下の手続きを設定するだろう、と話した。

 なお、監査手続の実施における、適切な監査証拠の収集に当たっては、セキュリティベンダからの全面的協力を得られる旨を確認している。

  1. 外部からの不正操作リスク

 鍵の漏洩に関しては、セキュリティモジュールの設計書、およびセキュリティテスト結果を査閲し、デバイスからの直接鍵漏洩の可能性が低いことを確認する。

 また、プラットフォームを稼働させているデータセンタの管理ポリシー、物理的設計等についてヒアリングするとともに、直接立ち入り調査を行って、不正なデータ持ち出し、鍵流出を防止可能なメカニズムが機能しているか、目視確認する。

 誤動作に対する備えに対しては、セキュリティベンダに対してファジングテストの実施可否をヒアリングするとともに、結果報告書を査閲し、十分なテストが行われていることを自ら確認する。

  1. サプライチェーンリスク

 セキュリティベンダに対して、使用しているハードウェアのリストを提出してもらうとともに、各ハードウェア製造メーカの与信を適切に行ったことを証明する書類を合わせて提出してもらう。これを査閲することで、サプライチェーンの与信管理をセキュリティベンダが行っていること、実際に各部品が信頼に値するかを確認する。

 併せて、A社側の受け入れ試験において、納入された機器が実際に当該リストに基づいていることを確認する手順、項目を用意しているかを、A社側の企画書を査閲して確認する。

以上

題材、内容の妥当性も、文書記述も文字数の妥当性も一切保証されているわけではないので、パクったところでそのままでは合格できません1。こういうものか、と雰囲気だけ持って帰ってください。

リスク、コントロールの抽出とリアリティ

 前述したように、リスクとコントロール自体を先に抽出したうえで、システムの側を当てはめているんですが、やはり背景となる技術知識を有している点はアドバンテージとして大きいものがあります。

 同じリスク抽出する場合でも、当該業界、領域に対する事前知識があると、リアリティのあるリスクを抽出できるんですよ。

 セキュリティ製品を使う場合に鍵に関するリスクがある、というのは普通のエンジニアなら想像できると思うんですが、ゴミデータを送った時に誤動作するリスクがある ってのは組込みや制御系の知見(いわゆるセーフティに関する考え方)がないとなかなか引っ張ってこれないと思うんですよね。

 もう一つ、業界に関連するニュースとか、ホットトピックを知っていると、それを引き合いに出すことでリアリティが増します

 例えば働き方改革、という言葉はもう世の中に十分定着してますよね。午後ⅠのRPAもそうですが、IoT導入の旗印としても使えるわけです。

 あと、IoTのリスクで思い出したのは、某国の通信機器メーカがスパイウェアやスパイチップを仕込んでいる疑惑の話でした。

現在進行形で炎上中のこの問題、大半の人には他人事なんですが、自分がIoTシステムの導入をしようとすると、あらゆる国の部品を使用することになるので、まったく他人事ではなくなるんですね。実際、SDカードのような汎用品はおろか、表面実装組み込み品でも偽チップ問題とかが横行しているわけですから。

こうした、自分がウォッチングしている業界の事例とかを組み込んでおくと、仮想事例でも大分現実臭くなってきます。ここから監査手続きを書くとなれば、問題に対する対策も同時に書くことになるわけですから、自分が世の中にキャッチアップし続ける、広い知見を持っているエンジニアであることも同時にアピールできるわけです。

監査手続の障害を排除する

 現実問題として監査手続を企画すると、他社の成果物をどうやって監査するのか、とか、まだ存在していない成果物をどう監査するのか、とか、いろいろと地に足をつけすぎて考えてしまいがちです。

 正直なところ、こうした現実志向は論文における監査手続記述においては、あまり価値がないだろうと。

 どうしても確認しなければならないエビデンスがあるのなら、それが他社の成果物であろうが、まだ作成されてない物であろうが、断固として手続を設定すべきで、逆に支障となる事態が存在するなら、論文中で明確に排除しておく、というのも一つのリアリティの出し方かな、と思っています。

 なので、A社におけるIoT企画案件でありながら、監査対象はA社の成果物ではなく、導入元のセキュリティベンダの成果物であり、そのための合意はすでにとっている、という立て付けを論文中に直接記述しているわけです。

 実際私が監査人の立場ならそうするでしょうから、監査実施の障害排除についてあえて書いておく、というのも有効な一手になったかな、と思います。

試験終了後

 こんな感じで論文を書いて試験会場を後にしたのですが。

 疲労困憊で家に帰って、労いの酒を飲みながら5chを見ていたら、こんな文が目に入ってしまいましてね。

394名無し検定1級さん2019/04/21(日) 16:47:30.12id:kKzh5QTb>>395>>400

午後2のIOT選んだ人

問ウは、企画段階の話だからね

テスト仕様書を確認するとか意味不明なこと言ってた人いたけど

395名無し検定1級さん2019/04/21(日) 16:50:19.09ID:2Cfdkb8I

394

うわぁ

その人今日寝れないんじゃ

 私には一緒に試験を受けた連れもおらず、内容も一切しゃべってないので、ここで言及されている人では全くないんですが、企画段階という言葉はその時の私から結構抜け落ちていて、おかげで眠れなくなりました。

 ご覧いただければわかる通り、立て付けは一応企画段階として設定しているものの、開発済みの成果物を監査証拠にしている辺り、試験官に誤解されないだろうか…と、2昼夜ぐらい頭の隅に引っかかってました。

 が、結果は御覧の通り。どうやら私の意図は試験官に伝わっていたようです。

 ただ、振り返ってみると、自分のホームグラウンドの問題が出たことに舞い上がって、問題文を正確に咀嚼して頭の中に入れていなかったが故の不安であり、油断だったと感じています。

どのような問題が出題されても、落ち着いて問題文の中身と題意をしっかりと頭に叩き込まなければならない、と痛感しました。

さいごに

 気づけば大分長くなっていましたが、こんな体験をした2か月後、合格の報に接することができました。

 監査というテーマからは結構程遠い人間だったので、今回の試験を通して、

  • 監査する側、される側の視点を得た
  • 自部署、他部署、自社、他社の対監査能力を見直すことができた
  • 監査の目的として、業務の正確性、正当性だけではなく、業務効率化を目的とした助言が存在することを知った

 と、監査に対する視点をベースとして、知見がだいぶ広がったように思っています。

 ESと並んで日本一マイナーな高度情報処理技術者タイトルですが、割と独立した立場で業務に関わることが多い自身の立場に相応したタイトルでもあり、この知見を活かして様々なステークホルダに改善の働きかけをしていければよいかな、と思っております。

 こんな感じですかね。午後Ⅰをぎりぎりでパスした合格者の補習としては。

 人によっては結構大変な試験区分ですが、この記事がエンベデッド領域を含め、再挑戦者も含め、この試験に挑む方の背中の一押しになれば、筆者としては何よりの幸いでございます。


  1. そもそも完全な再現ではありません。実際に書いたことの何割かを忘れています。

ならず者IoTエンジニアが由緒正しきシステム監査技術者になってしまった件(3)

本試験

 今回も千葉県の某大学です。

 幸いなことに駅からほど近い所に位置していたので、お昼ご飯は食べに行くことができました。

午前Ⅰ

 これに関しては…不覚というか、まぁスキルアップの道筋上仕方なかったんですが。

dimeiza.hatenablog.com

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

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

 って発言した人物は、当日の朝9時にその大学の教室に座っていました。どの口が言うか、って感じですよね。

 前回のシステムアーキテクト試験から2年以上が経過してしまったので、午前Ⅰ免除資格の有効期限は切れていました。午前Ⅰ試験に関しては直前に問題集3年分を2周回した程度でしたが、結果は御覧の通りです。正直もう終身免除でいいと思うんですが、たまに知らない言葉も出てくるので、まぁこれはこれで。

午前Ⅱ

 今回最初のトピックは午前Ⅱでした。

 初回で伏線を引いた通り、そして私自身が予期していた通り、来たわけですよ。改訂された最新の基準が。

https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_1/2019h31h_au_am2_qs.pdf

問1 システム管理基準(平成30年)において、ITガバナンスにおける説明として採用されているものはどれか。

問3 システム管理基準(平成30年)において、経営陣がITガバナンスを成功に導くために採用することが望ましい原則としているものはどれか。

問5 システム管理基準(平成30年)に規定されたアジャイル開発において留意すべき取り扱いとして、最も適切なものはどれか。

問6 システム監査基準(平成30年)において、システム監査人が実施する予備調査の作業として、適切なものはどれか。

問9 システム監査基準(平成30年)の説明はどれか。

問10 システム監査基準では、監査計画の策定にあたり、監査対象として考慮する項目を、情報システムの”ガバナンス”、”マネジメント”、”コントロール”に関するものに分けて例示している。情報システムの”マネジメント”に関するものを監査対象とする場合に、考慮する項目としているものはどれか。

 というわけで6問あります。午前Ⅱの問題数は25問なので、これらをすべて落とすと19問、最大76点しか獲得できなくなります。合格ラインは15問なので、安全バッファも4問と、がぜん厳しくなります。

何問かは監査の常識で突破できます。 例えば問6(予備調査の作業)とかは、改訂前とさほど変わり映えしないので、本監査の前にやっておくべき作業として理解していれば、最新版の管理基準を知らなくても正答可能です。

 厄介なのは単発知識系です。例えば問1や問3の選択肢は、パッと見るとそれっぽい選択肢が並んでいます。これらの選択肢の中で、 システム管理基準が採用しているもの を答えるには、 厳密に言うとシステム管理基準を読むしかないわけです。

 無論両問とも、ほかの予備知識から枝切りすることはできて、『常識的に考えるとこれじゃね?』と解答するルートもあるにはありますが、各受験者の予備知識は個々のバックグラウンドによって異なるわけで、万人が本番でその効果を狙って発揮するのは難しいものがあります。

そういうわけで、システム監査技術者試験の午前Ⅱで不本意な討死をしたくない方は、必ずシステム監査基準とシステム管理基準をしっかり読んでおきましょう。

午後Ⅰ

 システム監査技術者試験の午後Ⅰは3問。2問選択解答です。

 問1がRPA、問2が開発計画、問3が基幹システムのオープン化をテーマにしていました。

 私はRPAについては知見がなかったので、マネジメント一般知識で勝負できそうな問2と問3を選択して解答。これが正解だったかどうかは、正直今もよく分かりません。

問2

 問2は純然たる開発体制関連の問で、文章上にリスクそのものが羅列されているので、線を引きながら解答していきました。

 過去問をこなしていく中で、リスクが文中に示されておらず(暗喩すらされてない)、とても解答できそうにない問題があったりしたので心配していましたが、この辺の特定は割と無難にできるようになっていました。

 ただ、例えば設問5(利用部門からの追加、変更要求への対策)とかは非常に難しいと思いましたね。

本調査の実施(2)において、監査チームがT課長に確認した対策の具体的な内容を45字以内で述べよ。

 午後Ⅰの問題に対して解答を記述するときには、問題文中の根拠に基づいて解答する、というのが全試験区分における基本原則 なのですが、システム監査技術者試験においてはここが曖昧になることがあります。

 すなわち、

  1. 監査人の一般的な行為規範や、ソフト開発の一般的な知見を自分の言葉で解答するべきか
  2. 文中の根拠に対する自分なりのリアクションを解答するべきか
  3. 文中の根拠記述を抜き出して(あるいは要約して)解答するべきか

 この判断が非常に難しいのです。実際、情報処理教科書ではこれを3パターンの類型にしていて、選択を誤ってはならない、とはっきり書いてあります。

 厄介なのは、根拠が文中にあるにもかかわらず、解答者が問題文から見つけられないケース。これについては、ある程度探したら一般論で答案を書いた後で再度見直せ と情報処理教科書に提案されていますが、1問辺り最大45分の時間制限上、実際は結構難しいものがあります。

 もう一つ厄介なのは、 根拠は見つかったが、採用した根拠や解答に記述したリアクションが出題者の意図とずれているケース。これは合格した後の私でも適切な対策を提案することは難しいと思っています。

話を問5に戻すと

この設問に対する強力な根拠は終盤まで私も見つけられなかったのです。そこで、解答としては、

委託先の要求変化対応キャパシティを把握し、対応可能な分のみ要求を受け入れる

 という、委託先の負荷モニタリング実施をベースとした対策を記述しました。これは一般的なソフト開発の知見に加えて、問題文中の以下文章を論拠にした解答です。

委託先への発注窓口であるシステム部の体制が不十分で、開発着手後も委託先に”丸投げ”の状態となるリスクがある。

 ところが試験終了直前になって、問題文中のこの記述の意味に気づいたのです。

PMとしての責任、権限が曖昧なことから、T課長が判断に迷った場合に、プロジェクトとしての意思決定ができないリスクがある。

 ここで、出題者の意図が、要求採用可否決定の基準と仕組みづくりにありそう、ということに気づいたのですが、時すでに遅し。答案は私の手から回収されていきました。

 実際、IPA解答例としては、

開発着手後の追加・変更の要求に対応する際の採用条件を明確にし、利用部門と合意すること

 と書いてあったのですが、解答が他人行儀になっているだけで1 、別に私の解答でもおかしくはないよなぁ、と。採用条件を委託先負荷にしているだけなので。

 このように、根拠が複数考えられる場合や、根拠の一歩先の提案や見解を求められる類の設問をどう処理するか、という点、おそらくシステム監査技術者試験固有の難しさ だと思っています。

まぁ、IPA発表はあくまでも『解答例』なので、部分点か、あるいは正答扱いになっているのかもしれないのですが、こうした発散によってその辺がブラックボックスになってしまうのも、この区分固有の厳しさの一つかな、と思っています2

問3

 問3は基幹システムのオープン化に関する問ですが、この問の前半は割とプログラマあるあるというか、現場経験が多少あると問題を把握しやすい印象でした。

  • 古い設計書をうのみにしたら実装と違ってて調査に時間がかかったとか
  • 誰かが試用して、使えるって言われたツールを現場に適用したらうまく動かないとか
  • Web開発してるなら、ビジネスロジックと並行してGUIをプロトタイプできるよねとか

 ただ、ここでも設問5はあまり筋が良くなくて。

設問5 表3項番5について、監査チームが、情報システム部の対応計画に関して確認すべき事項を一つ挙げ、40字以内で具体的に述べよ。

 表3項番5には、現行システムの状況を考慮すると、次の段階の業務機能の見直しが円滑に進まない旨の記述がある ので、現行システムの状況をベースに解答することになるんですが、問題点はいくつかあるんですよ。その中でどれを選ぶか、という点にぶれがあるんじゃないかなぁ、とは思いました。

 解答例では、

要件定義書や設計書を整理し、最新の要件や仕様を反映する計画が存在すること

 とあって、確かにドキュメントと実装の相違は現行システムの問題なので、納得のいく正答にはなっています。

 一方で私は別の問題点を指摘していました。

現行システムの機能要件、作業要件に精通した要員を加えて対応する計画になっているか

 業務機能の見直しを行うためには、当然現行の業務要件を知っている人間が参画している必要があるんですが、現行システムにはそういう要員がいない、って問題文に書いてあるんですね。

情報システム部では、部員の移動に加え、各サブシステムの部分的な機能追加、機能変更を繰り返してきたことから、現行システム全体の機能要件及び業務要件について精通した部員がいない。

 これは業務機能見直しに当たっての支障になるので、私自身が構築した解答も、設問5の解答としては論理の筋が通っていたりするわけです。

 この解答もどう処理されたのかちょっとわからないですが、問2同様、こんな感じで解答の方向性が発散してしまいがちな傾向がこの試験にはあるのではないか、と思っています。

 私に見えていない何物かがあるのかもしれませんが、この試験を受験する際には、本文を根拠にする場合であっても、解答方向性の発散に注意して、備えられるならばなるべく備えましょう。3

 午後Ⅰの話が長くなってしまいました。今宵はここまでに致しとうございまする。


  1. 先述したように、監査人はコントロール実施の確認者であって実施者ではないので、ある程度他人行儀である方がベターではある。

  2. 作問と難易度の調整が難しいのを承知の上で、ここは改善してもらいたいです。国家試験として受験料を徴収している以上、解答例を見て万人が納得できるようにしてもらいたいところ。

  3. 問2設問5の回答を対比して思ったのは、もしかすると、『コントロールは外部視点である程度抽象化する』辺りがヒントなのかもしれません。端的に言うと、『監査人としての視点だけで書き、組織内部の具体的な対策実装方法は問わない』ってことなのかも。とはいえ問3の事例はそうではないし、正直あまり自信はないです。