ならず者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版)

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の事例はそうではないし、正直あまり自信はないです。

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

学習の流れ

 確か第二種電工の合格通知を受け取って、登録申請した後辺りから始めたので、1月下旬~2月ごろからだったように思います。

 よって学習期間は2か月程度、どちらかというと時間短めでした。

教科書、基準、参考書の読解

 いつも通り通勤電車の中では知識の蓄積フェーズ。試験直前まで、熟読系はほとんどここでやってました。

演習

 基本的に知識蓄積は後半に効いてくるので、まずは知識だけでは解けない午後系を中心に実施して、午前試験は終盤軽めに回す方針で進めました。

午後Ⅰで感じる違和感

 まずは午後Ⅰの過去問に挑戦したんですが…ここで結構違和感があって。

 高度の午後Ⅰ試験のポイントは、出題者側(IPA)と思考回路というか、考え方を合わせることだ、とよく言われます。午後Ⅰ試験は午前試験と違って記述式の自由回答なので、一字一句確定した答えはなく、出題者の意図に沿った回答を記述することが求められます。

 高度を数回受験した経験から、そこまではわきまえていたんですが、システム監査技術者試験の午後Ⅰは、かなりつかみどころがなくて。

 システム監査技術者試験の午後Ⅰ試験の出題形式は、他形式と違ってほぼ決まっていて、字数制限にばらつきはありますが(10字から60字ぐらい)、文章記述第5問から構成されます。

 字数に合わせて答えるには答えるものの、書かれた解答例と自分の回答がだいぶ違っている、という経験を何度もしました。学習時期の後半まで回したんですが、終盤になってもあまりシンクロしなかったですね。

 実は本試験の午後Ⅰの成績、個人的には合点がいってなくて。結構埋めてるはずなんだけどギリギリ、って所が。

 ただ、試験勉強時のこの違和感からして、結局本試験まで出題者側の題意に沿えなかったのではないか、と解釈すると、自身の感覚とスコアの平仄は合います。

午後Ⅰにおける回答のポリシー

 そんな感じで午後Ⅰが弱かった受験者なので、この辺へのアドバイスは弱めなのですが、一つ意識しておくべきことがあるとすると、

  • 状況に対するリスク要因を探し、リスクに備えるためのコントロールをチェックすること

 これが午後Ⅰ、及び午後Ⅱを通して大きな方針になることは確かです。

 もう少し突っ込むと、午後Ⅰ試験では、大抵こんなことを聞かれます。私は演習を繰り返した結果、終盤では以下を念頭に置いて回答していました。

  1. 監査人がある行動をとる(べき)とされる理由
    • 潜在しているリスクか、監査人の行為規範のいずれかを聞かれている。前者は問題文から、後者はシステム監査基準をベースに答える。
  2. 事例に潜むリスクそのもの。
    • 題意に沿いながら、問題文の状況で『ここヤバくね? こういう理由で』と言える場所を探して答える。
  3. リスクに対するコントロールの方法
    • システム管理基準をベースに答えるのが有効だが、適切なものが見つからなければ、なるべく確実に問題を潰せる対策を答えるのが良い。技術的な対策とは限らない点に注意。
  4. 監査手続の方法
    • 代表的な監査手法(インタビュー、文書収集等)を念頭に、自分が監査人としてコントロールが機能しているかを客観的に確かめられる手法を回答する。

システム監査技術者試験はマネジメント系試験の一つである、という点は重要な点で、リスクに対するコントロールの方法は技術的手段とは限らないことを念頭に置いておく必要があります。

技術者、チーム個人ではなく、事業部、会社全体といったマクロな組織単位でリスクがコントロールされているか、という組織的なコントロールが主要な関心事となるので、適切なコントロールにはマネジメントとしての打ち手が多く含まれます。

もう一つ、適切なコントロールが分かっても、そのコントロールを実施するのは監査人たる自分ではなく、被監査部門であるべき、という点は常に念頭に置いておきましょう。我々は『確認する側』 なのです。独立した立場の人間として問題文を読み、答案を書く必要があります。

あと、システム監査人というロールの難しさは、技術的なバックボーンなしでは最適なコントロールや監査手法を提案できない、ということと、試験で要求されるかもしれない技術領域は非常に広いという点です。

この辺は、システム監査技術者の過去数年分の午後試験をやってみるとすぐに分かります。今年の試験は比較的マネジメントに寄ってはいたものの、対象領域、業界には以下のように非常にばらつきがあります。

年度 午後Ⅰのテーマ
2019 RPA、開発計画、メインフレームのオープン化
2018 ステージゲート、データ分析基盤、販売管理システム
2017 在庫管理システム、品質管理基準、工場系ネットワーク
2016 VDI、情報セキュリティ管理、経営情報システム

先の通り、リスクに対するコントロールをチェックする、という点がシステム監査を貫く大テーマなので、問題の出方はリスク、コントロール、監査手続の側面に帰着はするのですが、問題の円滑な理解に当たっては ITの各領域、技術分野を広く浅く知っておく(守備範囲を広くしておく) ことが有力な武器になります。

言うは易く行うは難しなのですが、特に 特定の分野に知見が偏りがちな人は気をつけましょう(私もそうでした)。 過去問を多く見ておくことと、先般紹介した事例関連本、及びシステム管理基準を読んでおくのが備えになります。

午後Ⅱに対する備え

 論文学習の手順自体はシステムアーキテクトと大差ありません。その辺を知りたい方は過去記事をどうぞ。

 今回も午後ⅡはPC5問、机上7問ぐらい解いて試験に臨みました。システム監査技術者の論文テーマは少ないので、学習終盤にはテーマが尽きてましたね。

 午後Ⅱも監査だけ答えればいいって問題ではないのが非常に厄介です。

 いやまぁ、午後Ⅱも午後Ⅰと同じく型は決まりきっているんですよ。

  • 問1で受験者が関連した/する予定のシステムの概要を説明させ、
  • 問2でリスクをリストアップし、当該リスクに対するあるべきコントロールを述べさせ、
  • 問3で各コントロールを監査人が確認するための監査手続を問う

 という流れなのです。ほとんどが。

 問題はテーマや対象技術領域の候補が広いくせに、設定されたテーマから回答可能な範囲は結構狭い 、ってことなんです。

年度 午後Ⅰのテーマ
2019 IoTシステム企画、情報セキュリティ関連規定見直し
2018 アジャイル開発、リスク評価結果を利用したシステム監査計画
2017 内部不正対策、運用段階でのセキュリティ監査
2016 システム投資に対する監査、設計、開発段階における品質管理

 テクニカルスペシャリストシステムアーキテクトと違って、これらのテーマには技術的に何の共通点もなく 1 、あるとすれば、 それぞれに対して監査をするということだけ なんです。

 このため、幅広く経験を積んできたエンジニアでなければ、過去問、そして挑戦するであろう本試験のテーマ全てに対して実例を用意することは相当難しいはずです。 場合によっては監査部門でなければ経験しないテーマもあるので、監査未経験の一エンジニアには至難といってもいいかもしれません。

 私自身も長らくエンベデッドの一部門で経験を積んでいて、横断的に多種多様な部門の監査を経験しているわけではありませんでした。なので、今回の午後Ⅱに対しては、システムアーキテクト試験の本番で発揮された『妄想力』を演習段階から全力開放しました。

論述対象システムを"見出す"

 私自身が担当したシステムの種類は少ないものの、私の会社が保有したり、開発しているシステムは結構多かったので、

  1. 論述対象になりそうな業界のシステムをいくつか念頭に入れておいて、
  2. 論文テーマに対して、あるあるなリスクとコントロールの組み合わせをいくつか列挙し、
  3. 2で列挙したリスク、コントロールを当てはめると、現実の事例としてしっくりくるシステムを1から選んで、想定し得る状況と、その状況に対する監査手続を書く

 こんなやり方で演習をしていました。

 例えば、

  • 設計、開発段階における品質管理→自部署が設計、開発やってるので自部署の話を書く
  • 運用段階でのセキュリティ監査→人の立ち入りチェックやデータ暗号化を自社のデータセンターでやってたので、データセンター運用事例について書く
  • ソフトウェア脆弱性監査→サイバー攻撃対策がいいか。自社で作ってた電子書籍販売システムへの攻撃対策を書いてみよう

 みたいな感じで、用意したシステムのストックに対して、リスクとコントロールを組み合わせて事例を作ってました。

 一つのシステムが複数のテーマに対応できたりもするので、全てのテーマに別々のシステムを当てはめる必要はありません。

  • 本試験の時点で、出題されたテーマからリスクとコントロールを導出でき、それがしっくりハマるシステムを持ちネタとして持っていること

 が、おそらく本試験午後Ⅱの勝利条件の一つなので、これをできるようになっておくとよいです。

事例、リスク、コントロールは平たく、監査手続は深く。

 おそらくもう一つの、そしてあまり自明でない勝利条件はこれではないかと思っています。

 端的に言うと、『問1、問2の(監査手続以外の)記述は書きすぎず、問3はしっかり書き込む』ことになります。

 これ、システム監査技術者試験経験者が良く話す内容なんですが、受験当時はピンとこなかったんですよ。

 ただ、今ならその理由が分かります。それは時間配分という物理的な理由だけではなく、

  • システム監査技術者試験の目的は、リスクに対して適切な監査を設定できる能力を測ることだから。

 だろうなぁ、と。

 もちろん、リスクとコントロールを抽出し、評価することもシステム監査技術者の重要な仕事なんですが、監査技術者の仕事は第一義的には監査なので、リスクとコントロールを抽出して終わりじゃダメなわけです。

 コントロールが機能しており、リスクが組織として抑止されていることを検証できないといけない。なぜならそれがシステム監査技術者の第一義的な仕事だから ってことなんだろうなぁ、と。

 監査手続を問われることは、システム監査技術者の実務能力を問われるのと同義 なので、どのように監査を設定するか、何をエビデンスとしてどう確認するかは、リスク、コントロールと結び付けてガッツリ書きましょう。


  1. セキュリティはちょっとだけ出やすいです。論文ネタにもなりやすい。

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

はじめに

 というわけで合格してしまいました。

f:id:dimeiza:20190621204856p:plain

 SS、ES、SAに続き、4つ目の高度情報処理技術者タイトル取得で、今回のシステム監査技術者は高度試験の中でも難関3本柱の一つなので、なかなかのタイトルを得たことになります。

 スコア的には首の皮1枚…というか、午後Ⅰは文字通り当落線上なので、あまり威張れる成績ではないのですが、最大の難関である午後Ⅱもパスしたわけですから、背伸びして胸を張ろうかと思います。

 ただ、今回の試験は従来までの試験とだいぶ勝手が違いました。

 その辺りについて話をしつつ、今後システム監査技術者を目指す人のための参考情報を残しておく、というのが、ギリギリで勝ち残ってしまった合格者としての責務かな、と思ったので、ここに残しておこうかと思います。

 今回は4部作ぐらい。サブタイトルは特にひねらずに行きます。

事前状態

  • 高度情報処理技術者は3つ(SS,ES,SA)取得済み。
    • 論文試験も経験済み。
  • システム監査技術者試験の受験経験はない1

  • 監査人の実務経験はない。

  • 被監査側としての実務経験も乏しい。

    • 1,2回社内のISO9001内部監査を受けた程度。

 監査技術者の試験を受けるくせに、監査、被監査の経験が乏しい、ってのは、システム監査技術者試験受験者のあるあるだったりします。

 監査人の実務を経験するには、

  • システム監査を行う監査法人等で働いているか
  • 大企業の監査部門に勤めているか
  • あるいは実働部隊のシニアエンジニア/マネージャが監査人研修を受けて行うか

 ぐらいのケースしかありません。

 ましてや、監査という行為自体は比較的大きめの、コンプライアンスを重要視するような大企業で行うことが多く、中小企業勤務のエンジニアが監査人を行うケースは少ないといえます。

 私もその例に漏れず、キャリアの中で監査人としての経験を積む機会はありませんでした。

 なので、ここで伝えたいことはただ一つです。

  • システム監査人の実務経験がなくても、システム監査技術者試験に合格することは可能。

 そこかしこで言われていることなんですが、私自身が一つ実証事例を積んだので、お伝えしておこうかと思います。

教材について

 今回はシステムアーキテクトの時と違って、参考書、問題集を買って独学で臨みました。

購入した書籍類

 買ったのはですね…。

  • 情報処理教科書 システム監査技術者
  • 2019 徹底解説 システム監査技術者 本試験問題 (本試験問題シリーズ)
  • システム監査技術者合格論文の書き方事例集 第5版 (合格論文シリーズ)
  • よくわかるシステム監査の実務解説(第3版)

 大体この辺。だいぶ買ってますね。

 実は情報処理教科書は2018年度のものを読んでました。昨年受けようかどうか迷いながら読んでたんですよ。TOEICが早めに800に達したら受けようかと思ってもいたんですが、結果が出たのが5月になってからだったので。

 なので、メインで使ったのはもっぱらiTECの3冊です。

 合格論文の書き方事例集は、システム監査技術者の論文は言うに及ばず、『そもそも文章なんて書くの辛いよぉ』って人が読み始めても良いレベルの導入になっています。論文苦手勢には一読の価値ありです。

 あと、監査人としての経験が乏しいことを考えると、机上知識でもよいので、

  • どんなシステムが監査対象となり、
  • どんな監査テーマが設定され、
  • どのような手順で監査が進み、どのように監査証拠を集め、
  • 監査結果と監査意見をどのようにまとめて表明し
  • その中で監査人はどう振舞えばよいか

ということを必ず知見として獲得しておかないといけません。その意味で後の2冊(書き方事例集と実務解説)は、特に未経験者にとって有用な2冊です。

基準類

 あ、そうそう。大事なのを忘れてました。タダで手に入る奴なんですけど。

 この2冊には必ず目を通し、可能な限り頭に叩き込んでおきましょう。

 システム監査技術者試験は、この両者を基準や行動規範として念頭に置いて作問されているのです。いうなれば公式の教科書も同様です。

 特に今年はこの傾向が顕著で。なぜかって?

ちょうど去年の試験が終わった直後に改訂されたからです。つまり今年(2019年)の試験が新基準での試験1発目だったんですよ。そりゃぁ試験側も聞きたくなるってもんです。

いずれにせよ、今後も両基準はシステム監査技術者試験の問題作成、採点基準になるので、受験者は必ず理解したうえで、単発知識を聞かれても可能な限り答えられるようにしておきましょう。

次は試験勉強の話をします。以下次号。


  1. つまり今回の試験も一発合格。

In Win Chopinをケース改造せずにLow Profile GPUを搭載する

これの日本語版です。

dimeiza.github.io

ぱっと見、あまり共有されていない方法だったので共有しておきます。

はじめに

Mini-ITX好きの自作erならまず知っているであろうこのケース。Chopinです。

お気に入りのケースの一つなんですが、今使っているメインPC(Ryzen 1800X)にはさらに強力なケース(DAN cases A4-SFX) 1を使っていて、このケースはセカンドマシンで使用されています。

ところで、最近良いニュースを聞いたのです。Zen2という話を。

https://www.amd.com/en/press-releases/2019-05-26-amd-announces-next-generation-leadership-products-computex-2019-keynote

で、これを聞いたときRyzen9 3900Xが欲しいと思ったんですが、そうなると今使っている1800Xをどうしようか、と。

理想的には1800XをChopinに入れてセカンドマシンにしたかったんですが、1800XはGPUを持っておらず、ChopinにはGPUを搭載できない、と。加えて、この上新しいケースを買いたくないなぁ、と。

ケース本体を加工して1050Tiを入れた猛者もいたんですが、

https://forums.bit-tech.net/index.php?threads/inwin-chopin-gpu-1050-ti-mod-pluto.347849/

ケースの鉄板を切断するスキルは私になかったので、何とか改造せずに1800Xを搭載できないかなぁ、と考えていました。

どうしたか

考えたのはこういうことで。

  • 2.5インチストレージを入れる背面の空間に、ロープロGPUをぶち込めないか
  • ライザーケーブルをマザーボードスペースからストレージスペースに通せないか

で、やってみたらできた、というわけです。

ストレージスペース:

(後述の通り絶縁シートを付けていますが、分かりやすいように外しています)

f:id:dimeiza:20190607165402j:plain

マザーボードスペース:

f:id:dimeiza:20190607165448j:plain

昨日の段階で、この環境でブートし、一定時間正常動作していることを確認しています(熱暴走等は起こっていない)

材料

GPU

  • Sapphire R5 230 1G DDR3 PCI-E H/D/V
  • 何枚か候補はあったのですが、これが一番小さくて薄かったので。

ライザーケーブル

  • とにかくフレキシビリティの高い製品を選びましょう。もうちょい長くても(40cmぐらい?)良いかも。

細いHDMIケーブル 2本

  • とにかく細いケーブルを。太いケーブルは曲がりにくいばかりか、内部スペースを消費するので、手持ちがあっても妥協してはいけません。

DVI-HDMI変換コネクタ

  • GPUのDVIポートをHDMIに変換するのに使います。例えばこういうの(私は手持ちのを使ったのでこれは使ってません)。なるべく小さいやつを探しましょう。

HDMI延長コネクタ

  • ケースの壁を変換コネクタと一緒に挟みます。

絶縁シート

GPU基盤とサイドパネルの接触を防ぐために使います。

手順

1.Chopinのアルミニウム外装を外します。

f:id:dimeiza:20190607165526j:plain

この外装は特殊なネジで止められています(T15)。私はたまたま手持ちのドライバーで外せたのですが、お持ちでない方は入手する必要があります。

例えばこういうのですが、あまり使う機会がないのであれば、先端を付け替えられる万能タイプの方がいいかもしれません。

2.サイドパネルとプラスチックのフロントパネルを外す。

f:id:dimeiza:20190607165552j:plain

 アルミニウムの外装の中にはプラスチック製のフロントパネルがあります。

 プラスチック製のフロントパネルを外すと、この写真のように、フロントプレートには大きな5つの穴が開いています。

3.フロントパネルの裏に付いているUSBとオーディオコネクタ用基板を外す。

 これがあるとライザーケーブルが通らないので、前面のインタフェースは諦めます。

4.ライザーケーブルをPCIEのスロットに挿す。

5.ケーブルのGPU接続側コネクタをフロントパネルの穴に通し、背面のストレージスペースに通す。

 通し方は写真を参照。

6.ライザーケーブルにGPUコネクタを挿し、ストレージスペースへの格納を確認する。

 このケーブル長だと斜めに入ります。もうちょい長いと垂直/水平に入るかも。

7.DVI-HDMI変換コネクタを、GPUのDVIポートに挿す。

 これでGPUからはHDMI出力が2つ出るようになる。

f:id:dimeiza:20190607165616j:plain

8.Chopinのストレージスペースには3つの出力ポート用の隠し穴がある(デフォルトでは埋まっている)。このうちの大きい穴の金属の覆いを外して(手で外せる)、HDMIケーブルのコネクタ部のみを出す。ケースの外からHDMI延長コネクタを挿し、ケーブルとコネクタでケースの壁を挟むようにする。

f:id:dimeiza:20190607165637j:plain

9.もう一本のHDMIケーブルを、フロントパネルの穴を通してマザーボードスペースに通す。

10.Chopinのマザーボードスペースからは1つの出力ポート用の隠し穴がある(デフォルトでは埋まっている)。この穴の金属の覆いを外して(手で外せる)、HDMIケーブルを出す。

f:id:dimeiza:20190607165658j:plain

 今回使用したケーブルだと、直接ケーブルを出すことができますが、先ほどのように延長コネクタを使って壁を挟んでも良いです。

11.絶縁シートをGPU基板の大きさに切り、基盤の上から張り付ける。

f:id:dimeiza:20190610090504j:plain

12.サイドパネルを閉じ、アルミニウムの外装を付ける。

13.あとは動かすだけ。

さいごに

これでChopinをカスタマイズせずにGPUを装着し、Ryzen7 1800Xをも動かすことができるようになりました。

今は古いCPUが動いていますが、Zen2を買った暁には、Ryzen7 1800Xに入れ替えて動かすつもりです。


  1. これも世界的に超有名なMini-ITX専用ケース。Mini-ITXでありながらフルハイト2スロットのGPUを挿せる、サイズとスペックを両立させうる最強のケースです。

Developer's Summit 2019 【15-B-5】Site Reliability Engineering at Google 聴講メモ

講演資料

  • 資料公開なし。

概要

  • GoogleにおけるSRE(Site Reliability Engineering)の実践について。

スピーカー

  • Google Cloud Japanの中井さん。

SRE(Site Reliability Engineering)とは

  • 元々はGoogleの中のシステム運用。
    • 10年ぐらい前にGoogleの中の人が出版。
  • Google外でも考え方を取り入れていこうという流れ。
  • Googleの中で生まれた考え方なので、社内文化に依存した面はたくさんある。
    • そのまま外で実践しようとすると、合う合わないは出てくると思う。
    • どう実践していくかはこれから知見が増えていくところだろう。
    • 今日はその出発点として、どうやっているのか、どういう背景に支えられているのか知って欲しい。

Googleについて

  • Google社内では技術者同士の情報共有がかなり緩やか。

  • 建前上、今日の話は公開情報に基づいて行われる。

    • 口を滑らせたものについてはツイートしないようにお願いしたい1

Googleのグローバルインフラストラクチャー

  • ミッションステートメント『世界中の情報を整理し、世界中の人々がアクセスできて使えるようになる』

    • 『世界中の人々』がキーワード。
    • Googleのエンジニアが開発するアプリのターゲットユーザは『世界中の人々』。
    • 特定の人向けのアプリはなるべく作らない。
  • Google社内のプライベート回線で繋がってるのでGCPは速い。

  • コンテナのシステムで全部統一化されている。ダサい言い方だが標準化。

    • 徹底してて世界中のデータセンターが全て全く同じ仕組みで作られている。
      • アプリは確実にどのデータセンターでも動くことが保証される。
    • 世界中のデータセンタにKubernetesっぽいものが展開されている。
      • Borgのこと。
      • Borgのマスターにコードを投げつければ勝手にデプロイしてくれる。
    • ミドルウェアが全て標準で用意されていて、アプリのエンジニアはこれを使わなければならない。
      • オレオレルールを禁止している。
    • 最近はパブリッククラウドが浸透してきて、ミドルウェアレベルの標準化は浸透してきているのでは。
      • そもそもGCPはもともとGoogle社内で使っていたインフラを公開したもの。

GoogleのSREチーム

  • いわゆるシステム運用のチーム。

    • 最初はフルスタック的な運用をしていた。
    • 規模が大きくなって人が増えてくると、開発と運用のチームを分けた。
  • そのチームの最初のマネージャーがGoogleらしい人だった。

    • 運用者を雇うことをしなかった。
    • 『運用も開発者目線でやりたい。開発者に理想の運用を考えさせたらどうだろう』と考えた。
  • ゴールを明確にすることが重要。

    • システム運用、サービス運用のゴールは? →安定的にサービスを提供すること。
    • 安定運用のための開発を考えるチーム。
  • ソフトウェア開発以外の作業もたくさん存在する。

    • 50%ルール
      • 業務時間の50%以上を、ソフトウェア開発を含むシステム安定化に関わるプロジェクト活動に当てる。
      • 半分はデベロッパーとしてワクワクする業務に当てて欲しい。
      • 残り半分は一般的な運用作業。
      • 実際問題守れるのか?→一応守れている。
  • バーンアウト(Burnout)の防止。

    • SREチームは運用を開発に突き返す権利を持っている。
    • 50%ルールを守れない場合は、開発チームに突き返す権利がある。
      • 実際には簡単に突き返さない。
      • 突き返されると困るので開発側も協力して安定化に協力する。
      • あるいはマニュアル運用を減らせるように、デベロッパーとSEがいっしょに動く。
  • 全てのシステムをSREが面倒を見ているわけではない。

    • 共通のミドルウェアと重要度の高いアプリは面倒を見ている。
    • 小規模で重要度が低いアプリは開発チームが面倒を見る。
    • SREチームが関わる必要がないほど安定しているアプリは面倒を見ない。
      • SREの究極のゴールは、自分たちが運用するシステムをなくすこと。
      • が、現実はそうはならない。機能追加が多いので、新しい機能をリリースすると大抵トラブルが起きる。
      • 『世の中から病気がなくなれば医者は職業を失う』のと似ている。

SREの活動原則

  • SLO(Service Level Objective)

    • チームを超えた『安定』の共通認識。何を持ってシステムが安定してるかの共通認識を作る。
    • 数値レベルで安定度を客観判断する。
      • 例えば、
        • 『99%のリクエストに対して、サクセスステータスを返す』とか。
        • 『サクセスステータスの99%は、1000ms以内に応答を返す』とか。
    • こういうのを淡々とモニタリングしていく
  • エラーバジェット(Error Budget)

    • 1ーSLOで算出。
    • SLOの計算期間内でエラーバジェットを決めておく。
    • エラーバジェットの消費状況をモニタリングして、なくなる可能性がある場合は抜本的対策を講じる。

      • この場合は開発チームを巻き込む。
        • 開発とSLEがいっしょになって頑張ることが重要。
      • やってみないとわからないこと、本番デプロイしてみないとわからないことが山ほどある。
        • どうなるかはSREの方が知っていることが多い。
      • デベロッパーはその間、新機能リリースはフリーズする。
        • SLOを守るために注力する。
        • 困る人が出てくる場合もある。この場合、SLOの設定が悪い。
    • いろんな人が納得するSLOを議論して決定していくことが重要になってくる。

      • 実際には一発で決まらない。
      • 新規運用の場合は大雑把に決めておいて、後から調整するプロセスが走る。
  • デザインレビューの提供

    • アプリの設計段階から、安定化をゴールとしたレビューを実施。
    • SREチームが知っている安定化の知識を渡す。
      • デベロッパーのオレオレルールで作ったものを持ってこられても困る。
      • 自分たちがよく知っている標準的な設計にできる。
    • 設計の標準化、共通化が実現できるため、SREへの引き継ぎ後も人手をかけない運用ができる。
  • その他

    • Toil(労力のかかる作業)の削減。
      • Toilは悪である、というのが共通認識。
      • 削減する努力が美しいとされる。
      • 自動化で面倒な作業をなくす。
  • SRE本の英語版を読むと印象的な単語(Burnout)が出てくる。

    • システム運用の世界では嫌になる作業が山のようにある。
    • デベロッパーにつまんない仕事をさせたらみんな会社を辞めちゃうので、Burnoutを防ぐことは非常に重要。
    • 普通の発想だと、システム運用はつまらないのが当たり前になっちゃう。
    • 優秀なエンジニアにやらせると、転職先を見つけてどっかに行ってしまう。
    • ワクワクしながらやってもらうルールを考える必要がある。

障害対応のプロセス

  • 障害対応システムがGoogle社内にある。

    • 細かい障害は山のように起きている。
    • 障害対応に電話番が付いている。問題が起きたらその人に電話して障害対応が始まる。
    • 障害報告を受けた人がインシデントコマンダーになってチームに役割を割り当てる。
    • 割と自分たちでコードを見て根本原因の解決に当たろうとする。
    • SREの中だけで解決するルールは全くないので、デベロッパーに相談することも行われている。
  • 問題解決を最優先して、他人に頼ることを本人のスキル不足とは認識しないことを徹底。

  • Postmortem(事後検討)

    • 重大障害対応後、google docsで文書を開いて、記憶をダンプする。
    • 『何が問題で何が起きたのか』をダンプアウトする。
    • 言い訳をするものではなく、障害対応で得られた知見を未来に繋げる。
    • 書いていく中で改善案は出てくるので、改善のためのアクションアイテムが最後に書かれている。
    • 個人を非難する内容は絶対に書かない。
      • 個人のミスを誘発するシステムを設計したSREの責任。
      • コマンドの打ち間違いで障害が発生したのなら、コマンドの打ち間違いで問題を起こす設計が悪いと考える。
    • Google社内の全てのエンジニアに共有されている。見放題。
      • 社内の問題データベースを見ると大きな問題に対するPostmortemが出ていて、リアルタイムに皆が一斉に書き込んでいる様を眺めることもある。
      • 読んでいると勉強になる。エンジニアの教育材料としてすごく役立つ。
    • うわさによるとPostmortemを読む同好会が社内にあるらしい。
    • SREチームの中で障害対応の再現、実地訓練を行うためのシナリオとして使ったりもするらしい。

最後に

  • 同じことを外部の企業でやるのは難しいと思うが、合理性は徹底しているので、つまみ食いしてもらえればいいんじゃないか。
  • レーニングコースがあるらしい(coursera)。

    • 日本語版は出てないので、日本語化早くしろとリクエストしてほしい。
  • GCPをせっかく使うのであれば、開発した後の運用についても、SREのエッセンスを取り込んで使ってほしい。

    • それぞれの企業文化に合わせて、どのように実践していくかのディスカッションが広がっていくといいんじゃないかと思っている。

  1. もし口を滑らせた内容を気づかず私が記述していたら、こっそり教えてください。しかるべく処置します。

プログラマが第二種電気工事士を取ってみた(3.教室の受験者全部抜く)

技能試験当日

場所

千葉県の某大学でした。ちゃんとした作業台があるところでできるのかと思ったら、普通の講義室なのでちょっと面喰いましたね。

ただまぁ、受験者の前後左右の席は開けてあったので、左右のスペース的にはそれほど問題はありませんでした。

机の幅が若干狭かったんですが、まぁ困るほどではないです。

着席から試験までの間

これがまた異様に長いんですよ。10:55に着席させるくせに、試験開始は11:30~。30分以上溜めがあるんです。

本人確認とか問題配布とか、作業はいろいろあるんですが、最大の理由は技能試験用材料配布と確認のためです。

材料が配布された後、決められた時間内だけ、配布された材料を受験者が直接確認することができます。

材料に抜けがある場合は、この時間に限って交換を求めることができます。この時間を逃すと、たとえ欠品していても一切交換してもらえず、不合格確定なので、念入りに確認しなければなりません。というか、しっかり確認しておくとちょっとしたボーナスがもらえます。

というのも、技能試験の演習を2周以上回している人が念入りに確認すると、問題用紙を見るまでもなく、この時点で出題される候補問題が分かってしまいます。あぁ、この部品と、このケーブル長を求めるのはあの候補問題だよな、と。

実際、私もこの時点で出題される問題が分かったんですよ。そこでちょっと冷や汗をかきつつ苦笑したんですけどね。

前日の出来事

前日、私は最後の詰めとして、最も苦手な候補問題である、候補問題11の作成を行っていました。

候補問題11はこういう問題なんですが、私は特に金属管の取り付け作業に手間取る傾向があったのです。

f:id:dimeiza:20190123193201p:plain

f:id:dimeiza:20190123193056p:plain

(第二種電気工事士技能試験 すぃーっと合格より引用)

もう一つ、あえて最後に候補問題11を解くことにしたのは、金属管接続時に支給される部品上の都合によります。

候補問題11で支給される金属管はねじなし電線管で、ねじなしボックスコネクタを使ってジョイントボックスに固定する必要があります。

ねじなしボックスコネクタでねじなし電線管をジョイントボックスにつなぐ際は、止めネジを切るまでねじを回す必要がある(ねじを切らないと欠陥を取られる)んですが、一度ねじを切ってしまうと再利用できなくなるので、ねじを切るのは最後にしよう、と。

本番でも忘れずにネジを切らないとな、と思いながらねじを切っていました。

再び当日に戻ると

で、当日、試験会場で部品確認をしている私の手の中には、ねじなし電線管とねじなしボックスコネクタが握られていまして。

よりによって最も苦手なこれか(冷や汗)…昨日練習してきたけどさ(苦笑い)という感じでした。

ただまぁ、この時点で候補問題が特定されたおかげで、試験開始の合図を待つまでもなく、複線図作成以降の作業シミュレーションが頭の中でできるようになります。

段取りをばっちり組み立てて、開始時間を迎えました。

あとはもう手を動かすだけです。

ただ、これだけ準備していても、やはり本番一発勝負というだけあって、開始時には手が震えてましたね。

対策サイトや教科書で『本番特有の緊張感』と言っている奴ですが、作業手順をはっきりさせて無心に手を動かしていれば、そのうちスムーズに作業できるようになります。

演習をしっかり積んだうえで、本番では自分の習熟を信じましょう。

ふと気が付くと

時計を見ると、試験終了の大体12,3分前。一通り組付け、無欠陥も確認して完成。

両手を下ろしてふと教室を見渡すと、ほかの受験者は例外なく作業を続けていました。

…どうやら教室の中で最速で完成させたらしいぞ…と。

電気工事に関する専門教育を受けたわけでもない、初受験の私が受験会場最速、というのにはちょっと驚きました。

やることもないので2度、3度と確認していると、一本だけ規定長より長いケーブルがあって。そのケーブルだけ長さを計らず、切れ端をそのまま使っていたのに気づいたので、規定長に合うように切りなおす、などという無用な調整をしていたほどでした 1

試験終了時

試験終了の合図とともに、すべての受験者が作業を止め、その後は退出票をもらって一人づつ退出していくことになります。

退出票をもらうまでの間、何とはなしに教室の左右を見ていたのですが、結構いたんですよ、作品が未完成だった人が。

まだ部品の接続どころか、ケーブルの切断の段階、という人もちらほらいました。

きっと練習してこなかったんだなぁと思いつつ、事前準備の有無で峻厳に勝敗が決まる試験会場を後にした、という次第です。

さいごに

…というのが、第二種電気工事士を門外漢のプログラマが取得する際に得た諸々の気づきでした。プログラマから電気工事士を目指す人は少なそうですが、門外漢から電気工事士を目指す人はそれなりにいると思いますので、よければ参考にしてください。

これから免状の申請に入りますが、この資格が今後私にとってどういう助けになるか、実際のところはまだ分かりません2。ソフトウェアレイヤで仕事をしている限り、独占業務範囲に入ることも少なそうですしね。

ただ、IoT系も含め、電気が関わる種々の領域におびえることなく飛び込める切符を得られたので、機会を見つけてどんどん知見と権利を活用していきたいと思っています。


  1. ケーブル長に関しては、規定長の50[%]以下のときのみ欠陥を取られるので、長い場合は問題とされず、本来は不要な作業。余裕がなければ基本的にはやらない方がいい。

  2. プログラマを引退しても別の職が得られる、という、見えざる保険的な効果もあるかもしれません。