dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

ならず者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~2020年版

情報処理教科書 システム監査技術者 2019~2020年版

  • 作者:落合 和雄
  • 出版社/メーカー: 翔泳社
  • 発売日: 2018/09/10
  • メディア: 単行本(ソフトカバー)

2019 徹底解説 システム監査技術者 本試験問題 (本試験問題シリーズ)

2019 徹底解説 システム監査技術者 本試験問題 (本試験問題シリーズ)

システム監査技術者合格論文の書き方事例集 第5版 (合格論文シリーズ)

システム監査技術者合格論文の書き方事例集 第5版 (合格論文シリーズ)

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

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

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

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

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

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

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

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

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

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

基準類

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

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

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

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

www.meti.go.jp

ちょうど去年の試験が終わった直後に改訂されたからです。つまり今年(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. もし口を滑らせた内容を気づかず私が記述していたら、こっそり教えてください。しかるべく処置します。

情報処理安全確保支援士の経過措置対象者に関する問い合わせと、回答を受けた私の決断

はじめに

 ここしばらく表題の件でIPAと話をしていたんですけど、彼らと経産省から回答が来たので、経過措置対象者たる私1 の肚も決まったという話でもしようかなと。

情報処理安全確保支援士(登録セキスぺ)と経過措置対象者について

 情報処理安全確保支援士という『国家資格』があります。この資格は登録することで名乗ることを許される名称独占資格です。

 この資格はIPA(情報処理推進機構)が情報処理技術者試験と同時に実施する試験に合格すると、登録する権利を得ることができるのですが、IPAが過去に実施していたセキュリティ関連試験である『情報セキュリティスペシャリスト』と『テクニカルエンジニア(情報セキュリティ)』の合格者も、2018年8月19日までに申請を行うことによって、登録を行うことができます。

 これは経済産業省令に基づく経過措置によるもので、この経過措置を受ける2資格を有する者のことを『経過措置対象者』と呼びます。

経過措置の法的根拠

   経過措置対象者が登録資格を有する法的根拠は、情報処理の促進に関する法律施行規則(平成28年経済産業省令第百二号)の附則第4条によります。

この省令による改正前の情報処理技術者試験規則(以下「旧規則」という。 ) の規定による情報セキュリティスペシャリスト試験又は情報処理技術者試験規則等の一部を改正する省令(平成十九年経済産業省令第七十九号)による改正前の情報処理技術者試験規則の規定によるテクニカルエンジニア(情報セキュリティ)試験に合格した者は、支援士試験に合格した者(ただし、この省令の施行の日から起算して二年を経過するまでの間に、法第十五条の登録を受ける場合に限る。 ) とみなす。

 つまり、省令施行の日から2年以内に登録を受けた場合、経過措置対象者は支援士試験に合格した者と見なされるというのが、経過措置対象者が登録を受ける法的根拠になります。

 省令の施行日は平成28年(2016年)10月21日です。

 一方で、情報処理安全確保支援士試験の事務を代行するIPAは半期に1回しか登録事務を行っていないので、10月21日以前の直近の登録締め切りである、2018年8月19日が、経過措置対象者が措置を受けることができる最後の締め切り、というわけなのです。

 なので、IPAは経過措置対象者にこんなハガキまで送って知らせてきたわけです。

f:id:dimeiza:20180721200327j:plain

経過措置対象者の地位

 ところが、実は経過措置対象者の登録資格は、情報処理安全確保支援士試験合格者と比して、非常に不安定なものなのです。

 ここで問題になるのは以下の文章です。

支援士試験に合格した者(ただし、この省令の施行の日から起算して二年を経過するまでの間に、法第十五条の登録を受ける場合に限る。 ) とみなす。

 実はこの文章には、法的に2つの意味があります。

  1. 2年以内に登録を受ければ支援士試験に合格したものとみなす。

2. 当該登録を受けた事実が消滅した場合、経過措置対象者は支援士試験に合格した者『ではなくなる。』

 法的には2が厄介でして。

 普通に考えると、過去に行われた事実が消滅することってないじゃないですか。ところが、法的にはあり得るんですよ。

 民法第121条にこうあります。

第百二十一条 取り消された行為は、初めから無効であったものとみなす。

 つまり取消という行為が行われた場合、法的には、当該取り消された行為が、(取り消された時点ではなく)、そもそもの初めからなかったこととなるわけです。

 これが、IPAがWebページに載せているFAQのQ2-18(登録が取り消された後の再登録)の法的根拠になります。

お問合せ・FAQ:IPA 独立行政法人 情報処理推進機構

Q2-18.経過措置対象者の場合、登録が取り消されたあとに再登録は可能でしょうか?

A.経過措置対象者の場合、登録申請できるのは2年間です(平成30年8月19日申請締切)。登録が取り消された場合は、その後2年間登録ができませんので、再登録するためには、新たに情報処理安全確保支援士試験に合格することが必要となります。

 これにより、支援士試験合格者と経過措置対象者の間に、取消について異なる法律効果が発生するわけです。

支援士試験合格者:取消を受けても支援士試験合格の地位は変わらないので、2年待てば再登録可能。

経過措置対象者:取消を受けると経過措置期間内の登録の事実が消滅する→支援士試験合格者と見なされない→そのままでは再登録できず、支援士試験合格が必要。

消除について

 この辺のことを考えながら、IPAのページで申請書類一式を見ていた私は、こんなものを見つけて考え込んだんですよ。

情報処理安全確保支援士登録消除届出書

https://www.ipa.go.jp/files/000058522.pdf

 支援士は支援士の仕事を辞めるときに、登録消除を自ら行うことができます。これは情報処理の促進に関する法律施行規則24条に基づくものです。

 ところで、この消除の届出が行われたときの事務処理については、情報処理の促進に関する法律施行規則27条に規定があります。

第27条 経済産業大臣は、第二十条の届出があったとき、第二十三条の届出があったとき、第二十四条の届出があったとき、又は法第十九条の規定により情報処理安全確保支援士の登録を取消し、若しくは期間を定めて情報処理安全確保支援士の名称の使用の停止を命じたときは、登録簿の当該情報処理安全確保支援士に関する登録を訂正し、若しくは消除し、又は当該情報処理安全確保支援士の名称の使用の停止をした旨を登録簿に記載するとともに、それぞれ登録の訂正若しくは消除又は名称の使用の停止の年月日を記載するものとする。

 この辺りを見たときに、こう思ったんですよ。

  • あれ? 登録の自己消除を行うと消除の記録が残るのだけど、それでも最初からなかったことになるの?

IPAに聞いてみた

 そこでIPAに聞いてみたわけです。

  • 消除を行った場合、記録が残るのだから取消とは異なる効果を有するのではないの?

 と。

 IPAが最初に返してきた回答は、単なるFAQの焼き直しだったんですが、上記の論点をもっとはっきりさせて問い詰めたところ、経産省と協議したらしく、先日IPAがその経産省の応答を送ってきたんですよ。

情報処理の促進に関する法律施行規則(平成28年経済産業省令第百二号)附則第4条において、改正前の情報セキュリティスペシャリスト試験又はテクニカルエンジニア(情報セキュリティ)試験に合格した者は、「支援士試験に合格した者(ただし、この省令の施行の日から起算して二年を経過するまでの間に、法第十五条の登録を受ける場合に限る。)とみなす。」となっています。

 この「場合に限る」とは、「施行後2年以内に登録されている状態にある場合」に限ると解釈します。

 このため、登録が取消しになった方、又は、登録を消除した方は、登録されている状態ではありませんので、施行後2年を経過した後に、改めて支援士の登録を受ける場合には、支援士試験に合格していただく必要があります。

 ということだそうです。

 結局、消除も取消と同じ法律効果を有するというのが、お役所側の認識という事でした。

IPAに同時に伝えていたこと

 法的には無理筋なのかもしれませんが、一応IPAにはこう伝えていたんですよ。

  • 現状、支援士登録、講習費用に見合ったメリットが登録者に与えられているとは毛頭思えない。
  • 経過措置対象者に消除と将来の再登録の自由を与えることで、現状メリットがない登録講習費用負担を強いることを回避すれば、登録者をもっと増やせるのでは?

 また、IPAは登録消除時の取り扱いについてFAQでも何ら言及しておらず、各種法令にも登録消除時の明示記載がなかったので、適切な法運用をしているのか疑念がある(審査請求の対象となりえるのでは?)、というところまで話をしていました。

 が、審査請求を受ける上級官庁の経済産業省がこう答えを返してきたとなると、仮に請求を起こしたところで徒労に終わるのは間違いないので、この辺が私の引き際かな、と思いました。

費用対効果、価値の検討

 彼らがそういう態度で経過措置対象者に臨む、ということであれば、私としては登録以外の他の選択肢を机上に並べながら、自己の原点に返ってデジタルに考えざるを得ないわけです。

 すなわち、

  • 3年間で15万(5万/年)の費用、約3人日の講習時間は、自己のキャリアプランに対して明確なリターンをもたらす、有益な投資たり得るのか?

 と。

 しかし、10回考えても得られる結論は微塵も揺るぎませんでした。

  • こんな不安定な地位を維持するのに使うぐらいなら、その登録講習費用と講習時間、他の資格や技術習得に使った方が圧倒的に有益。

自己研鑽の観点から見た適切な投資先

 例えば他のIPA資格という狭い範囲で捉えなおしても、年2回の高度試験合格に投資する金額としては、年5万でも場合によってはお釣りがくるでしょう。1個に絞るというならトレーニングコースの学費すら捻出できます。

 ベンダー資格なら2,3万ぐらいは普通にかかりますよね。(こいつも有効期限付きですけど)最近儲かる資格と言われているAWS認定を代わりに受けたっていいでしょう。選択肢は無数にあります。

 言わんやセキュリティ資格なら、世界に通用するCISSP、GIACを受けるために投資した方がさらなる挑戦ができますよね。

 …実は私自身も、(そんなに難しくはないんですが)準備にお金がかかる資格 2 を、(スキルの幅を広げるために)受ける算段をしているところです。

 そもそも、投資先を資格に絞る必要すらないわけです。資格に関係なくセキュリティを学習する場に投資することは可能なのですから。サイバー攻撃対応訓練、CSIRTの訓練をしているところも今はたくさんあります。

ペーパー試験資格の登録に拘る意味

 先日このセミナーに出てきたんですけど、

www.ipa.go.jp

 パネルディスカッションの場で、パネリストの一人が『資格試験はペーパー試験でしかない』 3 と言ってたんですよ。じゃあこだわる必要なくね? って話ですよね。

 もっと言ってしまうと、後日どうしても支援士資格が欲しい、という状況になったなら、その時5700円払って、改めて受けて取ればいいじゃないですか、と。取れる実力があるという推定故の経過措置なわけですから。

 そうなると、酷い言い方ですが、経過措置対象者が登録に拘るのは、単に『試験を受けるのが面倒』という事でしかないな、と。私自身もそういう認識があったなぁと自省しました。

 しかも登録講習の内容については、IPAの主張とは裏腹に懐疑的な見解が散見されていてですね…。

ameblo.jp

登録セキスぺを『オワコン』にする自己研鑽

 こうやって棚卸してくると、経過措置対象者として登録を受けることで、費用負担的にも姿勢的にも、かえって自己の成長に縛りをかけてしまうなぁと思いました。

 本当にスキルアップを考えていくのなら、たかだか日本国内の1資格を登録維持するための費用にではなく、外の世界に打って出るための投資のために財布の中身をぶちまけたほうが、エンジニアとしてはプラスになるよね、と。

 『登録セキスぺは自分にとっては通り過ぎた道、すなわちオワコン』という姿勢で、新たな技術領域、もっと広いセキュリティの世界を学んでいきたいという思いを強くしました。

さいごに

 そういうわけで、私は登録のことは忘却して、今後も『情報セキュリティスペシャリスト4と名乗りつつ他の研鑽に精を出しますが、これをお読みになった、去就に迷われている経過措置対象者の方は、改めて登録講習の投資が、真に自分にとってプラスになるかをご一考なさることをお勧めします。

 あ、ちなみに、支援士試験を受けようか迷っている人は、特に迷わなくていいのでそのまま受けましょう。

 受験の過程における知識の獲得と、支援士登録資格の取得自体には意味があります。

 そのうえで合格の暁には当面登録せず、IPAにも国庫にも金を入れずに静観することをお勧めします。


  1. 2015年秋合格。ぶっちゃけ支援士と区切られるほど、試験で要求された知識に差はないと思っています。

  2. 実はIT資格ですらありません。

  3. 多分口が滑ったのでしょう。『確かにそうかもだけど、それこの場で言っちゃっていいのかよ』とは思いましたが。

  4. といっても、IPA資格ベースで自己紹介するときは、(IPAの職員が件のセミナーで、ITアーキテクト』って間違えて読んでいた)『システムアーキテクト』で大抵通してます。

HD ピコ レーザー プロジェクター 自作キット for Pi [HD301D1]を組み立てて使ってみた

はじめに

 Twitterを見ていたら、たまたまこんなのを見つけてですね。

 実は我が家ではずいぶん昔に"羊の皮をかぶったオオカミ"と呼ばれたこれを使っていたんですが(1万円ぐらいで買いました)、

https://www.amazon.co.jp/Wis-KVD-Z240K-%E7%A5%9E%E7%94%B0%E7%84%A1%E7%B7%9A%E9%9B%BB%E6%A9%9F-%E9%AB%98%E8%A7%A3%E5%83%8F%E5%BA%A6%E5%B0%8F%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%82%BF%E3%83%BC/dp/B00ABYEUBKwww.amazon.co.jp

 そろそろ年季も入ってきたのと、(ファンを交換したにも関わらず)そこそこファン音がするので、次世代品をそれとなく探していたところだったので、何も考えずにポチって見ることにしました。

 組み立てて使ってみたところ、簡単に組み立てできて、なかなかの使い勝手が期待できそうなので、写真を付けて組み立て手順を共有してみます。

部品

 こんな感じです(ヒートシンクの袋だけ撮り忘れてたので別撮り)。

f:id:dimeiza:20180714124411j:plain

f:id:dimeiza:20180714124432j:plain

組み立て方

1. ①のねじで入出力用基板を金属板に固定

 f:id:dimeiza:20180714124554j:plain

2. フィルムケーブルをヒートシンク付き基板(レンズ付き基板)と入出力用基板に差し、レンズ付き基板を1のねじで金属板に固定

f:id:dimeiza:20180714124629j:plain

 フィルムケーブルは"TOP"って書いてある方を上にします。

3. ②のねじで③のスペーサーを金属板に固定

上面

f:id:dimeiza:20180714124653j:plain

底面

f:id:dimeiza:20180714124658j:plain

 この底面中央の大きなねじ穴は三脚固定用です。

5. アクリル板のシールをはがし、④のねじでスペーサに固定

f:id:dimeiza:20180714124924j:plain

 これで出来上がりです。簡単でしょ?

使用例

 自宅は天井がほぼ白なので、天井投影で試してみました。

 昼間(午前11時頃)ですが、1級遮光カーテンを2重にしてがっつり遮光しています。

f:id:dimeiza:20180714125051j:plain

f:id:dimeiza:20180714125109j:plain

f:id:dimeiza:20180714125122j:plain

f:id:dimeiza:20180714125134j:plain

 これ1はPCのDVI-HDMIケーブルから入力しているんですが、PCからの入力解像度は1280x720で認識されていました。

 取り急ぎ天井に映しただけなので、角度とかは適当ですが、まぁ特に問題なく見れる感じです。

 何となくKVD-Z240Kの方が画像がくっきりしているような第一印象でしたが、もう少し使い込んでみたいところです。

設定

 側面についている音量調節の歯車はボタンになっていて、押し込むと設定画面を出すことができます。

f:id:dimeiza:20180715163634j:plain

 最初は中国語表示なんですが、Language設定を選択すると日本語表示にすることができます。

f:id:dimeiza:20180715163716j:plain

f:id:dimeiza:20180715163946j:plain

 明るさは最初から最大設定になっていました。

 精細度はピント調節みたいな調整でしたね。多少ぼやけているようであれば設定しておくといいかもしれません。

所感

 光量はお世辞にも強くないので、昼間ならがっつり遮光するか、夜間に使用することをお勧めします。

 ファンがないので無音なのはかなりありがたいです。

 音声出力はHDMI経由で入力できていて、ステレオピンプラグから取ることができます。

 RasPi向けってことになってますが、別にRaspberry Piが必要なわけではないので、軽く手を動かしながら小型、静音、高コスパのプロジェクタが欲しい人は、試してみてもいいんじゃないでしょうか。

 しばらく使い込んでみて、新たに感想が出てきたらまたシェアしようかと思います。


  1. やっぱりTwitterを見ていたら、これの聖地に撮影に行った人が怒られた、って話が流れてきたので興味を持って見てみました。インドア派なので多分キャンプには行かないと思いますが、現在3周目です。

おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(4)

 最後は試験によって得られた成果と、最近の取り組みについての話でも。

TOEICに取り組んだ結果

 よく、『TOEICに意味はない』『TOEICなんてやっても無駄』とか言われたりもしますが、私にとっては結構意味がありました。

1. 一定のレベルに達すると、『英語に関わる』ことに対する抵抗感がなくなる

 一言で言うと、『英語アレルギーを克服できる』ってことです。

 私の場合大体700点台に到達したあたりから、

  • あれ? 何か英語勉強していてもあまり苦しくなくなったな

 という感覚が出てきたんですね。それどころか、

  • この英語圏の情報、取りに行ってみるか

 と、自分から英語の情報に手を伸ばせるようになります。

 昨年9月にこんな記事を書いたと思うのですが、

dimeiza.hatenablog.com

 このNUC、amazon.comで、つまり英語圏で買い物をしているんですが、実は昨年の7月に700点を達成していた後のことだったりします。

 その後、昨年11月のサイバーマンデーRyzenamazon.comで注文してみたり、先日はEssential Phoneを注文したりと、英語圏で買い物をすることができるようになったばかりか、先日はサポートを受けるために英語でチャットしたりと、自分の目的を達成するためのツールとして使い始めるようになりました。

2. 英語アレルギーを克服するまでの間は、スコアが補助輪的なインセンティブになる

 英語アレルギーを克服して、英語に自然に触れるようになると、学習と実力の間に障害なく正のフィードバックが回り始めますが、それまでの間はどうしても『分からない』『理解できない』苦痛が出てきてしまうんですね。

 自然な成長実感が得られないこうした時期においては、数値として見えるスコアが上がっていく、という『分かりやすいフィードバック』が、学習者を補助的に支えるという効果を持ちます。

 TOEICのスコアは優劣を競うものではなく、実力を序列化するものでもなく、単に『一私的団体が作成した問題をどれだけ解けたか』の指標でしかありません。どう使うかはすべて受験者に委ねられている、と言ってもいいでしょう。

 なので、受験者としては、『自分にとって最も価値のある解釈の仕方をする』のが合理的です1

 その一つとして、『成長を可視化して実感を作り出す』という使い方をしてもいいんじゃないかと思います。

3.英語で世界に働きかけられるようになる

 ご存知の方もいらっしゃるかと思いますが、昨年末からこんな取り組みをしていてですね。

qiita.com

qiita.com

qiita.com

qiita.com

qiita.com

 AlexaとGoogle Assistantを1台のRaspberry Piで同時に動かす、って話なんですが、両者の公式情報に当たるとすぐに分かる通り、いずれも英語の情報なんですね。

 読めるようになったので英語の情報を拾ってくる、ってだけじゃなくて、この成果をyoutube英語で公開したら、外国の人から質問が来たので、諸々やり取りしたりしています。

 さらに調子に乗って、githubに成果物を公開して、英語でREADMEを書くところまでやってしまいました。

github.com

 この辺、(特にRaspberry Pi zeroでのWakeword付き並行動作は)あまり先例のない試みなので、ほんのわずかですが世界にcontributeできたんじゃないかな、と。

 アウトプットはまだ始めたばかりで、google先生の力も借りていて、見る人が見ると下手なんじゃないかと自覚はしているのですが。

* 下手だろうが知ったことか! 全力で伝え、伝わればいいんだ!

 という開き直り感が最近出てきましてね。

 日本のAmazonで、片言の日本語で一生懸命商品を紹介しながら、それでも売り上げを稼いでいく中国の人たちの商魂を見ていると、

* 上手下手に拘らず、とにかくコミュニケーションに挑む

 ということが、今後英語を一層求められるようになるであろう、われわれ日本人が認識しておくべきスタンスなんじゃないかなぁ、と最近思い始めています。

ここから先、歩むべき道

 ぶっちゃけですね。

* 730取ろうが800取ろうが、読めない単語も多いし意味の取れない文章も多い

 のですよ。世間で憧れられているような、ペラペラスラスラの領域はまだまだ程遠いのです。

 ただ、800は一つの節目であり、私自身の今年の目標と合わせて、今後はReading, Listeningの取り組みと並行して、Speaking, Writingの2つの側面を新たに加え、4つの領域から英語を深耕していこうと思っています。

 今取り組んでいることを書いておくと、こんな感じです。

Reading

 通勤電車の中で、過去に読んだ邦訳文書の原典に当たっています。

 一つはこれ。

www.joelonsoftware.com

 私は若いころからJoel On Softwareの大ファンで、20代のころはmoreも含めて暗記する位読んだんですよ。

 これを英語で読んだらどんな感じだろうなぁと思って、邦訳があるエントリを中心に読み始めています。

 もう一つはこれ。

 これも邦訳を読んで瞠目させられた口なので読み始めていますが、まだちょっと難易度が高いかな、という印象。

Listening

 『1日1TED』と勝手に名付けたキャンペーンを絶賛実施中です。

www.ted.com

 実は枕元にiPadを据え付けていて、寝ながら動画を見れる環境があるんですが、平日は必ず寝る前に1つTEDを聞くことにしているんです。

 聞き方は、あえて日本語字幕を表示しつつ、英語を聞き取って、日本語字幕と対比する、という感じです。

 ヒアリングした単語から日本語の文章を組み立てられるか、という視点で聞くと、聞き取りの精度に自覚的になりつつ、聞き取れなくても興味深い内容を取りこぼさなくて済むので、楽しみながらヒアリングを鍛えられるかな、と思っています。

 寝る前の学習は記憶にもいいらしいですし、寝ながらで気楽に聞けるので、いい感じで続いています。

Speaking

 ここはまだ始めたばかりで、今のところは瞬間英作文に手を付け始めました。

 もう少し力を付けたら、TerraTalkとかにも手を付けつつ、慣れてきたら英会話教室かなと思っています。

https://www.terratalk.rocks/ja/www.terratalk.rocks

Writing

 この辺は先日のGitHub以来、まだあまり手がついてません。

 技術情報を英語で書ければなーと思っていますが、もう少し学習寄りの活動を視野に入れた方がいいのかも、と考え中です。

さいごに

 1年間にわたって挑んできたTOEICですが、スコアを徐々に上げながら、英語学習のループを作ることができ、いい感じで成果を収穫できたように思います。

 まだまだ会話も含めた実用には程遠いので、学習はずーっと続くのですが、とりあえず苦手を克服し、次の領域へのステップを踏むことができたかなと。

 『万人にとって有効な唯一の英語学習法はない』ので、ここに書いてあることがどれぐらいの人に役立つのか分かりませんが、私と同じように英語アレルギーに苦しみ、苦手を克服して世界を広げようとする人々(特にエンジニア)の役に、少しでも立つことができたら、筆者としては何よりの幸いでございます。


  1. そういう意識もあって、最初の回で述べたように、私はあえて非対称な解釈の仕方をしていた、というわけです。