  |
はてなキーワード: システム監査技術者とは
https://anond.hatelabo.jp/20221225142418
の続きです。これまでは幸運も手伝ってか合格を続けることができましたが、ついに落ちてしまいました。午前I免除、午前II88、午後I84、午後IIDでした。最初にお断りすると、事務屋が高度試験の論文分野を受験するに当たっての参考としては、topisyuさんのプロマネ合格体験記の方が本駄文よりよほどお役立ちかと思いますので、ぜひぜひお読みください。こちらは、こうすれば失敗するぞ、という反面教師にしていただければ。
１ 準備
いわゆる経営学系の問題が多いのがITストラテジスト試験なので、高度試験の中ではもっともわたくしの本職が活かせる試験であるわけです。実際、午前II、午後Iは去年の過去問を眺めただけで楽勝だろうと察しがつき、午前IIはこれまででもっとも少ない４年分の過去問をプリントアウトして解き、間違えた問題のみ何度か解き直しておしまい。午後Iに至っては、過去問を解くこともしなければ、参考書を読むこともしませんでした。
準備のほとんどすべては、午後II対策に費やしました。用意したのは、翔泳社の『情報処理教科書』のITストラテジスト2022～23年版と、アイテックの『ITストラテジスト 合格論文の書き方・事例集（第５版）』の２つ。最近はDX関連が必ず出ていて、自分の本業でもそれっぽい経験（ただし、非システム側からのもの）があったことから、その経験をシステム側に寄せて論文を書きました。本番までの間、それを実際に手書きもしましたし、何度も読み返して（たまには音読もして）、準備万端だ、と思っていたわけです。
あと、この手の体験記で明示的に触れられることが少ないのですが、論文で取り上げるシステムについてのアンケートがあります。規模等についてのものですが、このぐらいのシステムならこの程度、という感覚がわたくしには一切ないので、これについてもきちんと調べて書くべき内容を整えておいたわけです。
２ 本番
午前II、午後Iは順調に終わり、いよいよ午後IIとなったわけですが、開始とともに冊子をめくって愕然としました。DX関連の問題がない！ 問題の選択からして、どれを選んでも書ける気がしませんでしたが、相対的に絶望度がもっとも小さそうな大問１、システム改修を選びました。昔いっちょ噛みした複数部門で使っている業務システムの改修事例（ただし、自分の所属部門ではそれを使っていなかった）を必死で思い出しながら、設問で問われている事項は形式的にはすべて対応する記述を盛り込み、字数制限も満たして何とか書き上げることができました。
しかし、書いた内容というのが、結局は（１）ユーザ部門と緊密にコミュニケートしました、（２）使用頻度の低い機能を廃止してコストを削減しました、の２つしかなかったのがD判定につながったのだろうな、と自己分析しています。こんなことを話し合いましたとか、こんな機能を廃止しました、といった具体例などをあれこれ書いて字数を稼ぎましたが、水増し以外の何物でもなかったわけですし。事前に作った論文が改修ものだったらある程度転用もできたのですが、まったくの新規プロジェクトだったのでそれも叶わず。適当な旧システムをでっちあげて改修ネタにすればよかったかな、と後からは思うものの、その場では頭が真っ白になり、そんなことを考える余裕はなかったですね。アンケートも適当に書きましたが、規模の見当もなく、論文の内容ともさぞかし齟齬があったことでしょう。
３ 今後
とりあえず秋は監査を受けようと考えています。来年の春には再チャレンジを考えていますが、シラバスが変わっちゃうんですよねえ。論文の大問のひとつが組込みで固定されることになるので、それ以外の出題内容は振れ幅が大きくなってヤマをかけるリスクは大きくなってしまいますし。いっそのこと技術的な話を詰め込んで組込みで勝負する？ それなら秋にエンベデッドシステムスペシャリストを受ける？ もう少しゆっくり考えてみます。。。今回受かるつもりでシラバス変更をちゃんと読んでませんでした。組込みがエンベデッドスペシャリストに集約されて、ITストラテジストでは出なくなるんですね。やっぱり秋はシステム監査技術者受験で。
覚えている内にメモ
■午後１
＜大問２＞
設問１：本番運用サーバに負荷を与え、予定や会議室登録などの従業員の通常業務に影響するリスク
設問２：申請者に、個人情報の利用目的・保管場所・削除予定日を確認し、実際に削除されたことも確認すること
設問３：必要以上のサービスレベルを提供する体制を用意することにより、コスト配分を最適化できないリスク
設問４：活用検討会の議事録を通期確認し、新規データおよび追加収集したデータの利用状況を確認する
設問５：会議開催実績表を通期確認し、情報共有を目的とする各部門の会議が減少していることを確認する。
＜大問３＞
c=受注伝票
設問３：e=１注文が10万円以下となるように分割発注されてしまう、
f=受注責任者が、承認なしで処理したデータ一覧を日次で確認する
設問４：g=出荷完了リスト出力時に、当日出荷日のデータが出荷入力されていない場合に通知する機能があるか確認する
■午後２
＜大問１＞
H25午後１--問１がアジャイルに関するもので、イテレーション毎の反省会や
要件スコープの逸脱に注意する点などが述べられていて、覚えていたためにこちらを選択した。
# TAC合格トレーニング本の解説もためになった。選んでよかった。
設問ア：
システムの概要を述べる。インターネットシステムのほうがよさそう。
要件が不明瞭な点が多いこと、社会情勢によって本PJへのコスト配分を検討したいため、
アジャイルの内容としては、イテレーション４週間で設計・開発・テスト・UATおよび内部分析をしたこと、
開発環境に関しては、自動ビルド・デプロイツールを利用したことを記述。
設問イ：
②アジャイル経験者がないために、Pスコープ外の顧客要件も対応してしまうリスク
③アジャイルにおける開発環境構築の経験者がいないために、テストが遅れ納期間に合わないリスク
これらのリスクに対するコントロールとして、PMがPJ立上げ時に各経験者を参画させる必要がある。
また、開発が進んだ時には、１イテレーションの終わりに、当サイクルのプロセス分析し次サイクルに
上述の③のようにスキルのある人材が必要だが、実際の構築にあたり、
実はスキルが無く、進められないあるいは構築した環境の品質がひくくなりテスト進捗が遅れるリスク、
期待したメンバが、他タスクに埋もれ本来の環境構築作業に着手が遅れテスト進捗が遅れるリスク、がある。
このコントロールとして、PMが構築時の進捗および品質を把握し管理する必要がある。
設問ウ：
監査ポイント：アジャイル・アジャイル用の開発環境構築のスキルを有していることをPMが確認しているか。
監査ポイント：終わったイテレーションプロセスの反省・次への改善点に言及されているか。
監査手続き ：査閲する。設計工程や構築工程のフェーズアップ資料か。
監査ポイント：環境構築の進捗が把握されていること。環境の構築品質について評価していること。
監査手続き ：開発メンバあるいはテストメンバにヒアリングする。
監査ポイント：開発したモジュールが自動デプロイされ当日あるいは翌日に当該機能のテストができる状態か。
以上
