おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(3)
前回まででモチベーションについて書いたので、今回は具体的な学習サイクル、教材とか、戦術の話をします。
学習サイクル
実は今回の英語学習のサイクル、一昨年までにやってきた高度情報処理技術者試験勉強のサイクルとほぼ同じなんです。
学習時間的な話
学習時間で書くのが簡単かと思うのでリストアップしますが、実は以下2種類の時間しか使っていません。
- 通勤電車の中(往復合計で約30～50分)
- 週末午前中(土日、約120分づつ)
これを大体1年間やりました。ってことは単純計算で1…
| 学習タイミング | 学習時間[分] | 回数[回] | 合計[分] | 合計[時間] |
|---|---|---|---|---|
| 通勤時間帯 | 40 | 260 | 10,400 | 173 |
| 週末(土日) | 240 | 52 | 12,480 | 208 |
| 合計 | 280 | 312 | 22,880 | 381 |
400時間に満たないですね。
ただまぁ、仕事の中で英語の文書を読んだりはしているので、その辺を加味するとずいぶん違ってくるとは思います。私は比較的読まされる量が多い方かもしれませんが、エンジニアであれば、最近のオフィシャルドキュメントはたいてい英語だったりしますから、そんなに大きな差はないかとは思います。
学習時間、今計算してみて意外に短いなぁ、と自分でも思いましたが、この学習タイミング自体は意図的に計画したものです。
前回も書いた通り、仕事をしたり家事をしたり、睡眠もしなきゃいけませんから、生活サイクルとコンフリクトする計画は立てられないですし、学習時間を延ばして苦痛になって辞めてしまったら意味がありません。
学習時間の『品質』
そうは言っても限られた時間なので一つ工夫したのが、
* 『高品質な学習時間』と『低品質な学習時間』を分け、それぞれに最適な勉強をしよう
ということでした。
例えば通勤時間は電車の座席に座って(あるいは立って)、学習コンテンツを視聴するわけですが、電車の中って語学学習の邪魔が結構入るじゃないですか。
ましてや紙と鉛筆を広げて問題を解く、なんてことはとてもできないわけです。
一方で、週末自宅の机に向かっているときは、
- 様々な娯楽コンテンツの誘惑はある
のですが、
- 電車に比べれば比較的静か
- 机も広いので紙と鉛筆を使おうがパソコンを使おうが自由自在
という環境の静謐と空間的余裕があります。
なので私は、
* 自宅週末の『高品質な学習時間』では、新しい概念(新単語、文法、発音)の習得に注力する
* 電車の中の『低品質な学習時間』では、既存概念の復習、適用に注力する
という立て分けをしました。
両時間ごとに、使用したコンテンツを紹介していくのが、この際ちょうどよさそうですね。
『高品質な時間』に取り組んだ事柄
大きく3つの取り組みをしています。
1. iKnowで『新規単語』のインプット
まずはiKnowで単語学習。
iKnowは『新規単語を学習』→『忘却タイミングに合わせて単語の問題を繰り返し出題して復習』→『一定数正解するとマスター』という流れで単語学習を進めるようにデザインされています。
iKnowを開くとこんな画面が出てくるんですが、下の『アイテム』に『新規のみ』と書いてある場合、既出単語の復習を全く行わずに、新規単語だけが出てくるようになります。
これを1回につき20から40単語回してました。
iKnowでは問題に回答した際、単語を使った例文が出てくるので、その例文を有声でリピーティングしてます。
最初に単語学習を持ってきているのは、簡単でとっつきやすく、気乗りがしないときでも、学習に手を付け、継続するための呼び水になるからです。
2. DSの英語アプリを動かす
最初は1回目で説明したえいご漬けをやっていたのですが、文字の認識率が低くてイライラしてきたので、このイライラは危険だなと。
今回は従来と違ってTOEIC照準で勉強しているので、途中から、比較的新しいこれに切り替えて勉強を進めていました。
各パートごとに勉強できて、それほどストレスなく操作できているので、割と長く続いていますね。
あえて自宅でDSによる学習方法を選択しているのは、
- 回答を紙に書いた後で、自分で自己採点するのが面倒
という心理があったからです。
そもそもTOEICの本試験だってOMR(マークシート)で採点しているのに、人間様がわざわざ手書きで採点する技術的必要性なんぞなかろう、と。
『公式問題集で勉強するといいよ』と周囲にも言われていて、やった方がいいんだろうなぁ、と思ってはいるのですが、結局手を付けずにここまで来ています。
このソフト位の手間で自動的に採点、評価してくれて、かつ新形式に対応した電子上の高品質な学習コンテンツがあれば、是非それをやってみたいと思ってはいます2。
大体このDSによる学習を30分から40分ぐらいやって、次に入ります。
発音または文法の学習
あとは発音の練習『か』文法の練習をやって、その日の学習を終えていました。
両方同時にはやらないようにしていました。疲れるので。
発音についてはこれで。
後半のParrot's Lawとか英文読書はとりあえず置いといて、発音バイエルを最初から最後まで、付属のCDをシャドーイングする形で練習していました。
TOEICに関しては、『正しい発音を知らないと、脳内でカタカナ変換を伴ってしまうので、英語をパッと理解できない』という点がListeningに効いてくるので、一見関係ない発音の練習は(今後会話に進むための下準備としても)しっかりやっておいた方がいいかと思います。
あと、この本の『はじめに』に書いてある
結局、語学の学習の秘訣は『壮大な慣れ』です。
という言葉はすごく私に刺さりました。
これを読んだとき『特別なことをする必要はなく、慣れないことと分かったうえで何度も繰り返して、長い時間をかけて慣れていけばいいんだな』という理解と安心を得たのを覚えています。
一方、文法についてはこれで。
この本、『構造、フレームワークで英語の文章構造を論理的に分解する』という点において、非常によくできた本です。
われわれ日本人は日本語の文章を理解するときに、わざわざ『単語を分解して、各単語の品詞を解釈して、構造を把握した後で意味を理解する』とか七面倒なことをやってないかに見えるんですが、それはやらないのではなくて、脳内で超高速に無意識的にやっているだけだったりします。
実はこれは英語についても同じことが言えるのですが、我々は英語の文章を超高速かつ無意識的に品詞分解、構造把握できるわけではないので、まずは意識的にそれをやりましょうよ、という本ですね。
個人的には、この本は論理的思考を求められるエンジニアに対しては結構親和性が高い本なのではないかと思いました。理詰めで、『なぜこの単語はそのように解釈しなければならないのか』といった問いに答えてくれる本です。
この本は文法の基本要素から少しづつ読み進めつつ、読み進めるたびに練習用テキストが提示されます。そのテキストに対して、文法上のQuestionが提示されるので、Answerをよどみなく言えるようになることを求められます。
このQuestionに対するAnswerを口頭で回答する練習をひたすらやっていました。
実はAnswerは暗記しても良い、とこの本自身に書かれているのですが、実際に暗記していくだけでも、練習用テキストだけでなく初見の英文に対して、構造を自動的に解析する癖がついてくるんですよ。
この効果はPart5以降のReadingにおいて絶大なものがあります。気づかない間に、
- あぁ、この"arrived"は『準動詞』で、『分詞構文』ではなく『過去分詞形容詞用法』で使われているから、『大黒柱』になる動詞は別の動詞"went"の方だな
- あれ？ ここには現在形の『述語動詞』が2つある。両方とも『準動詞』にはならないから、後ろの方は『従属節』か
みたいな構造把握のための脳内回路ができて、問題を解くときに自動的に作動するようになってきます。
一方で、実はこの本についてはいろいろ批判があります。著者の薬袋先生もそのことを認識していて、『あとがきに代えて』で批判に対する回答をしていたりするんですが、その中にこんなことが書いてあります。
これは私の持論なんですが、英語の勉強法には、万人に妥当する唯一絶対の方法などというものはない。
大事なことは無作為に抽出した10人の中にいつも2人は私のやり方で劇的にできるようになる人がいるということなのです。また、この2人に入らなくても、私のやり方に触れて魅力を感じる人であれば、勉強を続けると必ず実力は向上します。
私はこの本で文法に関する理解が一気に進んだので、『劇的にできるようになる人』に近い感覚を抱きました。ただ、人によるのではないかとも思っているので、一度見てみて、合うと思ったらやってみるといいんじゃないかと思います。
TEDを聞く
これは余裕があれば。
ノルマをこなし終えて時間と精神に余裕があれば、TEDで興味のあるネタを見つけて聞いていました。
TEDについては最近取り扱い方を変えているので、最後にちょっと話をします。
『低品質な時間』に取り組んだ事柄
通勤電車内で何をやったか、って話ですね。
1. iKnowで既出単語の『復習』
週末に勉強した既出単語の『復習』に絞って取り組みます。
iKnowの学習サイクルの中で新規単語を学習しようとすると、そのサイクルはボリュームが増えてしまう、という特徴があるのと、落ち着かない電車内でやるなら、新規学習という高コストの学習作業ではなく、もう少しハードルの低い復習をやろう、という発想です。
この時もリピーティングしていますが、流石に声を出すわけにはいかないので無声で。
2. 英語リーディング教本の読解
文法書を読むだけならパッシブな作業なので、それほど苦も無くできます。ここで文法の内容を先に読んでおいて、週末に暗唱する、という流れです。
3. 英語ニュースを読んでみる
これは比較的最近の取り組み。POLYGLOTSを使っています。
テクノロジーのジャンルからニュースを取ってくると、TechCrunchのニュースとかを表示してくれるので、エンジニアも興味を持って読み進めることができます。
WPM(Words Per Minute)とか、読解速度を表示してくれたりするんですが、読むのが遅い私は大抵比較されると凹むので、あまり気にせずに読んでいます。
ここまでのまとめ
- 学習は通勤電車の中と週末に集中的に。苦痛にならないような時間配分を意識した。
- 週末の高品質学習時間では単語学習から入り、手や口を動かす高コストな学習を実施。
- 通勤電車の低品質学習時間では既出単語の復習や文法読解など低コストな学習に絞って実施。
こんな感じですね。
ただ、これで十分だとは思っていなくて、より良い勉強法を今もなお模索中です。
最後は試験によって得られた成果と、最近の取り組みについて話をしようかと思います。
おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(2)
前回までで英語学習のための背景を話しましたが、次は学習の骨格となる、モチベーションの話を。
モチベーション
『英語を勉強する』って言うと、この現代社会、右にも左にも勉強法が溢れていて、頼まなくてもノウハウを教えてくれるような世界だったりするじゃないですか。
ところが、あちこちで聞きまわったノウハウを手にして実際に英語学習に取り組もうとしても、長続きしなかったり効果が出なかったりするというケース、割と多かったりしません？
少なくとも私はそうでした。
- えいご漬けでゲーム感覚で勉強しているはずなのに、いつしか苦痛まみれになり、勉強を止めてしまう
- iKnowをLifetimeプランで買って自腹を切っているのに、やっぱり苦痛で単語が身につかない
- そもそも12年間も学校英語やってきて、しかも好成績で卒業しているのに、一向に英語が楽しくない
最後の奴、実はそうなんですよ。学校英語の成績は決して悪くなかったのに、社会人になってから英語に苦しんでたりするんです。
『自分にだけ意味のある、英語に取り組むメリット』に腹落ちする
この理由はいたって簡単で、
* 英語を習得する/使いこなすことに対するメリットを腹落ちしていない
ことに尽きます。
口でも頭でも『英語を理解できたらいいなー』と漠然と思っている状態だと、英語学習を作業以上の何者かにすることができないんです。
前の記事で長々と、個人的な背景を語ってきたのには明確な理由があって。あそこで書いたことが、『私にだけ意味のある、英語に取り組むメリット』なんです。
客観的に見れば、英語を習得した程度で、一個人が世界に何等か影響を与えることなんてできないのかもしれません。
しかしそれは他人にとっての意味付けであって、私にとっては関係のない話です1。
自分の中に、自分のためだけの、英語を取得するメリットが内発的に存在し、燃え続けている限り、英語学習の歩みを止めない原動力になりますし、空回りを防ぐこともできます。
まずはこれを灯し、薪をくべ続け、消さないことを意識しましょう。
長期戦であることを覚悟する
よく、『2か月で』『3か月で』800点取るぞ的なキャッチーな広告なり、成果報告なりを目にすることがあります。
短期間でがむしゃらに、というのは確かに一見効率よく見えますし、実際に成果を得られるのであれば、それはそれでよいことだと思います。
一方で、学業にすべての時間を使える学生と違って、現実世界で日々の仕事や生活に追われながら生きる我々としては、1日10時間の勉強なんて空想の中だけの話ですし、5時間確保するのだって極めて難しいわけです。
また、後述しますが、TOEIC800点取ったからと言って、一部で喧伝されるような英語全能者になれるわけではないですし、これから先も絶え間なく学習の道は続くわけです。
この辺の状況を考えると、
* 会話も含めた実践的な英語習得はロングスパンで計画し、行動する
ということは大事です。
私の弟は大学時代から英語に秀でていて、今は世界を飛び回りながら英語で研究者と議論するような堪能な奴なんですが、その弟にして、
『英語の勉強ってコスパ悪いからね』
って言ってましてね。短兵急に結果を求めて落胆しないようにするためにも、長期戦であることは覚悟しておきましょう。
苦痛にするほど追い込まない
長期戦である、ということは、『一瞬だけ苦しい思いをして突き抜ければあとは楽』みたいな戦術が使えないってことです。
もし日々の戦いが苦痛で、その戦いが長期戦なら、ずーっと苦痛が続くことになりますが、それは誰だって嫌ですし、脱落者を生む道ですよね。
であるならば、
* 日々の取り組みを苦痛にしない。苦痛だと思ったらいったん止めるなり、やり方を変えて苦痛でないようにする
という意識もまた必要になってきます。
ずいぶん昔にこういうツイートが流れてきたんですが、
これ格ゲーにも同じ事言えるなと思います pic.twitter.com/A2vZgyNlGN
— ばばさん (@a_ri_ba_ba) 2017年3月19日
私はこれとは逆の立場を取っていて。
たぶん今の教育制度で教育された人の大半はこう考えるのでしょうけど。
— dimeiza (@dimeiza) 2017年3月19日
>RT
この発想、つまり『苦学』に対し、
苦しまずに、
必要なことだけを、
継続的に学ぶ
が、ここ10年来志向されてきた学習スタンスで、これに沿っている学習プロセスはことごとく勝利を収めているのですよ。
例えば今は昔と違って、新技術を広く展開しようと思ったら、ペインレスなチュートリアルって必須じゃないですか。
最近だとAVS Device SDK/Google Assistant SDK、Amazon FreeRTOSのチュートリアルなどは、指定された機材(Raspberry Pi等)をそろえて指定された手順通りにやれば、サクッと動く成果物を作ることができます。
学習曲線を急峻にせず、一段階づつ着実に、転ばないよう無理なく知識を与え、最終的に何等か動く成果物をインセンティブとして与えるように設計されているわけです。
適切に設計された学習計画を公式が与えることで、新来者を増やしてユーザの水かさを増し、市場を取っていくのが今どきのイケてる技術普及戦略ではないかな、と。
我々が英語のチュートリアルを自分たちのために作るとしたら、同じように学習曲線を急峻にせず、転ばないように整備し、(自分という)ドロップアウトを出さないデザインにしたいと思いませんか？
私はそう思いました。
となると、
- 1回の学習時間を長時間にしない。
- 生活や仕事とコンフリクトするサイクルで学習しない。
- 学習時間の中に、学習の本質と関係ない不要な手間を含めない。
- 学習にリズム、サイクル、イテレーションを与え、成果にインセンティブを与える。
といった円滑化を考えていくことも、一つ無視できない要素になってきます。
自分にとって最適な勉強法は自分でしか発見できない
最後はこれです。
Qiitaですげー数のいいねがついているこの勉強法、私も見たのですけど。
2つ目は私が英語学習に取り組む前に見ていました。両方とも、私もいいねしましたし、成果を出していて立派だと思いましたし、一部は参考にしています。
ただ、『これが私にとって最適な勉強法か？』と言われると、答えは明確にNoなんです。
例えば前者で言うと、
1000時間やることにします。1日3時間くらいやればよさそうです。
この時点でエー、と思うほど、私は根性なしですし、
まず最初に発音、基礎文法、瞬間英作文をやりました。
発音と文法は私も取り組んだんですが、瞬間英作文は800取るまでに全く手を付けていません(今ちょうどやり始めています)。
後者については、
2010年10月(大学2年生/学習開始時)
先方は学生、一方でこっちは社会人(しかもいい歳の)で、置かれている環境、コンテキストからして全く違うわけです。
自分にとっての勉強法を考えるときに、(このBlogも含めて、)他者の成功体験を参考にすることはできます。
が、自分という人間のコンテキスト(境遇、仕事、性格、傾向)を知っているのは自分だけなので、そのコンテキストに最適な学習法を編み出せるのは自分だけだ、ということは認識しておくといいと思います。
誰かが成果を出した勉強法であっても、自分がやりたくなかったり、成果が出なかったりするのであれば、自分にとっては無価値。逆に誰かにとって意味がなかったとしても、自分が成果を出せるなら、そのやり方には自分にとっての価値がある、ということです。
平たく言うと、『英語の勉強法は(自分も含めて)学習者の数だけ存在する』のです。
自分の学習法は他人からコピーするのではなく、これまで述べた3点を意識しつつ、いいと思ったものをまずは取り込んでみて、実際に回しながら評価し、組み立てていくと、しっくりくるものができるんじゃないかと思います。
ここまでのまとめ
- 誰よりも自分にとって、英語を学ぶメリットを意識し消さないようにしよう。学習という作業をする価値はそこからしか生まれない。
- 長期戦であることを覚悟する。たとえ800取っても英語への学びはずっと続くのだから。
- 学習を苦痛にしないようにしよう。自分にとっての英語チュートリアルをペインレスに、ドロップアウトを出さないように設計する。
- 自分に最適な学習法は自分で組み立てる。他人の成功例をうのみにする代わりに使える所を盗み、回しながら評価しよう。
一見ポエム的に見えるんですが、自分の感触としては学習計画や方法よりも、この辺りのモチベーションが学習の骨格であり、成否を分けると思ったので力いっぱい書きました。
では、そろそろ戦術的な話に入っていくことにしましょう。以下次号。
-
最後に成果をちらっと話しますが、英語でアウトプットをし始めたりしているので、ほんのわずかではありますが影響を与え始めたりしています。↩
おっさんエンジニアがまったり1年かけてTOEICを265点上げて800点を達成した話(1)
はじめに
先日、表題の事項が発生しまして。
今回に関しては、まぁなんというか、率直に言ってまぐれだとは思ったのですが、
- もう若くもなく、学力も全盛期(20台)には到底及ばない、いいお年頃のエンジニアが、
- 英語好きではなく、むしろ英語アレルギーを抱えた状態から、
- バリバリがむしゃらにではなく、仕事と両立しつつ、無理せず、ゆっくり着実に
- 予定より半年前倒しで、多くの人の目標点に到達した
という状況になってしまったので、これは自分のやってきたことをシェアしておかないと罰が当たるんじゃないかと思い、筆を執ることにしました。
背景
TOEICへの挑戦を始めたのはちょうど1年前ぐらいの頃でした。
仕事からの要求
これまでも仕事の中で参照技術仕様やら何やらで、英語の読解を求められることは多かったのですが、そのたびに『なんとなく理解』『勘』『他力本願』で何とかやり過ごしてきました(と言うと関係者にすっごく怒られそうですが)。
ただ、ここ最近は以前にもまして、対峙する技術仕様に英語の割合が増えてきたのです。
しかもソロで動くことが増えてきていて、他人の力を借りることも難しくなってきました。
情報獲得の速度
一方で、Twitterとかで諸外国やら、識者から流れてくる情報を眺めていると、大抵英語が最初の情報源じゃないですか。
そして、英語で発信されたものが日本語に変換されて国内で周知されるまでに、どうしてもタイムラグが発生してしまう、と。
技術の情報源が母国語頼みだと、タイムラグの長さによって、われわれ日本人は2種類の不利益をこうむってしまう、と思ったのです。
1.情報の鮮度が失われ、価値を失い陳腐化する。
せっかく収集の努力をしても費用対効果が悪くなってしまいます。
2.母国語では決して発信されない情報が存在する。
海外の技術書だと、ずーっと翻訳されない名著があったりしますよね。
どの本だか忘れましたが、2000年代に英語で著された本が、10年以上後になって邦訳された、なんて話を聞いた辺りで、
- 英語の情報源の取り扱いを他人には任せておけないな
と思いました。
自分は世界を変えられるかもしれない
もう一つ、あまり社外にアウトプットしてないので張り子の虎なんですが、IT関連のセンスは(周りの人と比べると)自分では結構あるなと思っているのです。
小手先の技術だけではなく、取り扱う技術の広さや、設計やマネジメントの考え方、知的財産等異分野の知識など、若手にはない地力もついてきています。
そういった(ある程度肥えた目で)、英語圏から発信されてくる情報とか、海外を渡り歩くような一流の有識者の言動行動を見ながら、不遜にも
- こんなの、単に英語だってだけで、言っていることや考え方は(我々と)それほど大きな差はないんだな
と思い始めてしまったのです。それどころか、
- ひょっとして、自分は英語ができるようになったら無敵なんじゃないか？
傍から見ると噴飯物な、根拠のない自信を持つようになってしまったのです。
まぁ実際そんなことはないでしょうし、大抵の人は鼻で笑うと思うのですが、この、
- 英語を学ぶことで、自分は世界を変えることができるかもしれない
という、アウトプット、アクティブ志向のモチベーションは、実は情報を取りに行くというパッシブ志向のモチベーションよりも、自分にとってずいぶん魅力的で、大きな原動力になっていました(今でもなっています)。
そういうわけで
2016年までに高度情報処理技術者試験に3連勝して勢いをつけ、継続的な自己学習も習慣化できたことだし、
- ここらで一度本気になって、英語、ぶっ潰しますか
と、昨年の初頭から取り組みを始めた、という次第でした。
スタート地点
そもそも最初はどうだったのか、という話です。
最初のスコア
表題の通り、265点上げて800点なわけですから、最初の結果は当然こうだったわけです。
600点行かないにしても、そこそこできてた方じゃん、という方もいらっしゃるかもしれません。Qiitaに掲載されていた記事の300点台よりはよほど恵まれていますね。
この辺は、
仕事の中で参照技術仕様やら何やらで、英語の読解を求められることは多かった
という点が多少効いてはいます。ただ、いきなり無勉強でTOEICを受けるわけはなく、年明けから多少勉強してこの数字だったりします。
これまでやってきた取り組み
割と前からこれをやってきてはいました。
一応最後まで走ったんですが、後半の方は惰性というか、あまりやる気がない状態で進めていて結構苦痛でした。
あと、実はずーっと昔からこれをやってまして。
5,6年ぐらい前に友人が続けて取り組んでいるという話を聞いていて、Lifetimeプランを契約して、出勤前の時間帯とかにちまちまやっていたのですが…。
しばらく続けていると面白い技術や技術書が出てきて、そっちに飛びついて英語の方は忘れてしまう、なんてことを何度も繰り返していました。この辺はエンジニア特有の落とし穴かではないかと思います。
そういうわけで、世間標準からすれば英語に触れる機会は多めだったのですが、英語自体には強烈な苦手意識が伴っていました。通りの良い言葉で言うと『英語アレルギー』という奴です。
- ググる→英語のページしか出ない→必死で日本語のページを探す→そこから読み始める
とか、
- 英語のページしかない→読み始める前にエキサイト先生にご登場願う 1
みたいな行動パターンを紹介すると共感していただけるでしょうか(今までよくやってこれたな…)。
推移
こんな感じでした。
| 受験日 | Listening | Reading | Total |
|---|---|---|---|
| 2017/3/12 | 265 | 270 | 535 |
| 2017/5/21 | 350 | 295 | 645 |
| 2017/6/25 | 380 | 285 | 665 |
| 2017/7/23 | 415 | 290 | 705 |
| 2017/10/22 | 370 | 340 | 710 |
| 2017/11/19 | 390 | 340 | 730 |
| 2017/12/10 | 355 | 315 | 670 |
| 2018/3/11 | 445 | 355 | 800 |
まぐれ、って言った理由が分かったでしょ？ 前回の試験が予想外に悪く、今回が予想外に良かった、というのが正直なところです。
Listeningのスコアがガッと上がっているので、最後こんな値になっているんですが、紆余曲折ありながらもじわじわ上がっている格好になっています。
『TOEICは受け続けているとスコアは上がっていくよね』と、英語堪能な知り合いには言われたのですが、このグラフやら上述の事項やらを見て言えることは、
勉強し続けても、必ずしも順調に上がっていくわけではない。 スコアは試験の内容やらコンディションに依存して上下にブレる。
ということです。
TOEICのスコアに一喜一憂してはならない、とよく言われますが、一歩推し進めて私は、
* 上がったら『ハードルを越えられた』と全力で喜び、落ちたらなかったことにしてスルー
という風に、非対象に取り扱うように心がけていました。
ちょっと先走ってしまいましたが、ここから先、(ある意味で勉強法より大事なメンタル面について)話をした後で、実際の戦術を書いていこうかと思っています。
以下、次号。
Developers Summit 2018【16-C-6】The Amazon Way～Amazonのソフトウェア開発～ 聴講メモ
講演資料
資料公開予定なし。
概要
外部から伺い知ることが少ない、Amazonのソフトウェア開発の姿について、特にAmazonのバックボーンであるカルチャーを中心に紹介する。
スピーカー
Amazonの西谷さん。
詳細
The culture of Innovation
ミッション
- 地球上で最もお客様を大切にすること
- ここでお客様とは、ものを買う消費者だけではなく、販売者、企業、コンテンツクリエイターも含む。
- 安心感をもたらす
- お客様の生活を楽にする、というコミットメントに根ざしている。
- 常にお客様を起点に行動する
- ミッション、コミットメントのスタート地点として。
- 地球上で最もお客様を大切にすること
Customer Obsessionという考え方。
- Obsessionという言葉の訳は難しいが、お客様への執心、執着というニュアンス。
顧客重視と長期的視点
- 創業時から一貫して変わっていない。
- 1997年の株主向けレターにおいて既に明言されている。
- お客様への徹底的なフォーカス。
- 長期的視点での投資を継続。
- 売上は成長し続けているが、純利益自体はフラットに推移している。
- 得た利益を次の投資として回し続けているということ。
イノベーションの例
こうした投資の結果、いろんな領域でイノベーションを起こし続けている。
創業時のコンセプト
紙ナプキンのスケッチ。以下の要素が配置された図。
以下の循環の中で成長する。
また、以下の構造も含まれている。
- Lower Cost Structure(低コストのオペレーションの実現)がLower Price(低価格化)をもたらし、
- Lower PriceがCustomer Experienceにつながる
イノベーションのための組織づくり
以下を大事にしている
メカニズム
- アーキテクチャ
- 組織
- カルチャー
メカニズム
PRFAQ(PR+FAQ)
プレゼン文化はない。
- アマゾンにはプレゼンを使った会議はほとんどない。
- プレゼン形式だとプレゼンターの喋りが上手ければ、内容も良く聞こえてしまう。
- Amazonで複数名で検討を行う際には、6pagerと呼ばれるレポートを使う。
- ファクトベースの数ページのレポートを先に配布し、
- 数分間読んでもらい、
- その後ディスカッションする。
- アマゾンにはプレゼンを使った会議はほとんどない。
アーキテクチャ
組織
2 Pizza Team
Amazonのチームは2 Pizza team。
- ピザ2枚でまかなえる人数がちょうどいい、という発想。
- アイディアを早く形にしてフィードバックにすばやく対応するには、大規模な組織ではなく少数精鋭でやったほうが効率的。
- AWS含め様々なプロジェクトで適用されている。
こうして作られた2 Pizza teamは、作るものに対するすべてのオーナーシップを負う。
- プロダクトの計画策定 ロードマップ
- 開発
- 運用、カスタマーサポート
"You build it, You run it."
という観点で見ていくと、こんな問答になる。
チームの動き方
全ての機能はサービスチームに存在するが、自身の役割に集中している。
- 開発、ディレクション、支援など、個々がそれぞれの担当業務を専任している。
- (自分たちでお守りをすることになるので)夜遅く起きないようにするために必死に作る。
開発方法についてもチームに権限が与えられている。
こうした動きを実現するためには、チームとして高い水準を維持する必要がある。
- オンボーディングと呼んでいるトレーニング。
- 定義されたパターン、プラクティス。
- レビュー。
- 内部的な技術共有。
- Our Leadership Priniciple
- これについては後程述べる。
- といった原則を徹底的にやっている。
パイプラインについては、上述のカルチャー(独立かつ自由選択的な多数のチーム)から、
- セルフサービス。
- テクノロジ非依存。
- ベストプラクティス。
- 単一目的のサービス群。
- を提供するためのツール群を社内で共有している。
- 利用するかも裁量だが、90％以上のチームが使っている。
こんな感じで、各チームが開発からデリバリまで並列に動くことになる。
- 年間5000万回ぐらいのデプロイが行われている。
AWSは昨年1年間だけで1400ぐらいの機能、サービスをリリースしている。
- ただ、これは対外的にアナウンスしたものだけ。細かいリリースはもっと多い。
カルチャー
文化の根底にはOur Leadership Principleがある
- 14個の行動規範。
- Amazonでは、マネージャであるかどうかに関係なく、全員がリーダとして動くことを求められる。
Web上で公開されている。
- ちなみに中身は何年かに一回変わったりする。
- ただし、一番最初の原則と最後の原則は不変。
- ちなみに中身は何年かに一回変わったりする。
人事評価にも組み込まれている。
以前からもこのOur Leadership Principleは知っていたが、入社して驚いたのは、普段の会話でこのキーワードが出てくること。
- コミュニケーションにおける共通言語として使われている。
- 社外の人が言われても、何のことか分からないが、社内だとニュアンスが伝わる。
Amazonの社員を捕まえて『どのOLPが好きか？』と聞くと、それぞれ異なる答えを返してくれるだろう。
Our Leadership Principle
Customer Obsession
- 全てはお客様から、という発想。
- Empty chairという慣習がある。
- 会議を行うとき、あえて椅子の一つを空けておき、そこにお客様が座っているかのように意識して会議を行う。
OwnerShip
- 長期的な視野に経って役割分担をすること。
- テストで重要なこととして、すべてを自動化しようとしている。
- 運用も全て自動化しようとしている
- 自動化が非常に重要、という考え方が根付いていて、実現している。
- テストをしやすいようにアーキテクト、デザインし、
- テストや運用を自動化するためのアプリのアーキテクチャを考えている。
Dive Deep
Learn and be curious
- 深堀していく。
- Rootcause analysys
- 5Whys
- いわゆる『なぜなぜ』と同じようなことをやっている。
- Brownbag sessions
- 社内勉強会。ランチボックスを持って集まって取り組みをシェアしたりしている。
Frugality
- お客様にとって重要でないことにお金を使わない
- Door Desk
- 社員の机はドア用の板に木の足をつけた簡素なものを使っている。
- 創業時の気持ちを忘れないようにするため。
- この影響で、目黒のオフィスではドアが天井に並んでいたりする。
Think big
- お客様に貢献するために大きな視点を持つ。
- 常識にとらわれない。
Bias for action
- スピード重視。
- 取り組みにはやり直しがきくことも多い
- プロトタイピングとフィードバック。
Hire and develop the best
- 採用時に高いバーを維持する
- 各チームが採用活動をしていると話したが、人が足りないから採用する関係上、本来求めるべきレベルを下回っていても採りたくなる心理がある。
- そこで、そのチームに直接関係ない人が採用に入ってバーを上げるという取り組みをしている。
- カルチャーにフィットするかを非常に重視する。
- カルチャーに合わない人だと、会社の成長を妨げてしまうので。
- 採用時に高いバーを維持する
Have backbone;Disagree and commit
- 敬意をもって異議を唱える。
- 偉い人に対する反論があっても空気を読んで言わない、とかいうのはやめよう、という話。
- ただし、決定には全面的にコミットする。
- 敬意をもって異議を唱える。
Invent and simplify
- イノベーションとインベンションを求めてシンプルに。
- コード、プロセス等全てにおいて。
- イノベーションとインベンションを求めてシンプルに。
Are right, A lot
Earn Trust.
- 話をよく聞く。
Insist on the Hightest Standard
- 常に高い水準。
- 同じ失敗、問題を繰り返さない。
- コードレビューを非常に重視している。
Deliver Results
- 決して諦めない。
重視している点
こういうことを求めていくと『寝ずに働く』しかない。
- のではなく、重要なことにフォーカスするようにしている。
イテレーションを重視している。
- 必ずしも開発に限らない。
- 溜め込みすぎずに、小さくしてなるだけ繰り返す。
- 貯め込むと頻度も下がってしまうのでよろしくない。
MVP(Minimum Viable Product)
- としてモノを作っている。
- 最小限の仕様でモノを作って、お客様のフィードバックをもとにプロダクトを成長させていく。
- マーケットに届ける時間と機能セットのどちらを優先するかは悩ましいが、トレードオフして必要最小限の仕様で届けていく。
- いろいろ考えて、でかいモノを作っても、お客様にマッチしなかったら嬉しいものにはならない。
さいごに
- Every day is still Day Oneという言葉がある。
- 常に毎日が最初の一日である。
- 現状に満足せずに新しい挑戦をし続けよう。
GB-BKi7HT2-7500を買ってみた
きっかけ
最近、Intelが出しているNUCという製品を知って、小型ベアボーンに物欲を刺激されまして。
よさそうなのを見つけたのですが、日本のAmazonはじめ、Webで売っているところを見かけなかったので、amazon.comで購入してみることにしました。
現時点で情報があまりないように思ったので、軽くレビューでもしてみようかなと。
ターゲット
これです。
https://www.gigabyte.com/Mini-PcBarebone/GB-BKi7HT2-7500-rev-10#ov
選定で意識したのはこの辺。
- 接続ポート、コネクタ種別
- USB-TypeC,USB 3.0がそれぞれ2つ
- HDMI,mini DisplayPortの複数画面出力
- ThunderBolt 3
- 2.5インチSATA HDD接続可否
- 大きさも程よい
- IntelのNUCは結構大きく見えた
ほんの少しだけゲームもやっているので、グラフィックをどうフォローしようかとも思ったのですが、最近はSteamホームストリーミングとか、ESXiによる仮想マシンサーバからのパススルーとか、いろいろ手があります。
ここは仮想化やリモート化の勉強も兼ねて、遠隔でやってみようかと思っていました。
注文
amazon.comで注文しました。
https://www.amazon.com/gp/product/B071KJF4BX/
本体＋AmazonGlobal Priority Shipping＋Import Fees Depositで、大体￥65Kぐらいでした。
9/9にオーダー、9/11に出荷、9/15に受領、という流れでした。
はじめてAmazon.comを使ったのですが、Amazon Global様々ですね。これで日本市場未流通の製品も比較的楽に手に入れられそうです。
開封の儀
こんな感じの箱に入ってきました。
上面
底面
前面
後面
本体
上面
電源スイッチは上面についています。
前面
左側面
背面
という構成です。
右側面
MicroSDリーダがあります。これまで外付けのを使っていましたが、もういらないかな…。
底面
各脚にねじがついていて、このねじを外して内部にアクセスします。
付属品
1点、アダプタの電源プラグの形状が三叉プラグになっています。この点だけ注意ですね。
私の環境では二つ又プラグだったので、たまたま持っていた旅行用の変換コネクタをかませて動かしました。
内部
ねじを開けるとこんな感じです。
ふた部分にSATA SSDをマウントしてケーブル接続し、SO-DIMMのDDR4 RAMをセットすれば使えるようになります。
M.2スロットは2つあって、一つはSSD接続用、もう一つはWifi/BlueToothボードで占有されています(これ、外して別のボード刺したりできるのかしら…)。
動作
BIOSは従来型でした。
この構成でFF14ベンチを動かしてみましたが、720Pでこの程度の能力です。
HD Graphics 620ですから、まぁそんな大したことはありません。
で、このベンチを取った時の音を記録してみました。
なんか動画で見るとあまり騒々しくないように聞こえますね。実際は机の上に置いておくと、もう少し騒がしい印象でした。
どうやらTurbo modeをEnableにしているとファンが回りやすいようなので、私はBIOSからTurbo modeをoffにして動かしています。
Voice wakeup
という機能がついている、と製品ホームページにこっそり書いてあって。
説明書いわく、
Voice Wake Up Feature: Allows the Device to Wake Up from Sleep/Shutdown Mode,
とあって、スリープやシャットダウンモードから発声で起動させられる、と。
ドライバインストール後、タスクトレイからRealtec HDオーディオマネージャを開くと、Voice wakeupの設定を行うことができます。
"Hello Gigabyte"でも動かせるみたいですが(未確認)、"私のキーワードを聞く"で学習をさせようとすると、"お気に入りのキーワード"を6回録音して覚えてくれるらしいので、有名なあのフレーズを使って動かしてみました 1 。
GB-BKI7HT2-7500 Voice Wake up Feature
まだ数回しか使っていませんが、現状認識率がちょっと微妙。録音の仕方に依存するのかもしれません。いろいろ試してみたいところです。
ちなみにマイクは本体に内蔵されているので、マイクを追加することなくこの機能を使うことができます 2 。ボイスアシスタントとの親和性が高い作りです。
感想
まだ使い始めたばかりなので、評価は固まってはいませんが、
良かった点
- ライトユーザの作業(Webブラウジング、音楽、動画視聴)程度は余裕でこなす
- Turboを切ってこの範囲で動かしている限り、音も静か。
- 2.5インチベイ搭載モデルなのに小さくていいね。
- フロントUSBポートでスマホ系の充電回りも賄えるので、充電コンセントであふれなくていい。
苦手な点
- 3Dゲームはそんなに得意ではなく、ノーパソ程度。単体でゲームさせるなら他所をあたったほうがいいかも。
- Core i7とはいえ2コアなので、開発用途にも力不足かも。
って感じですかね。
ほかに気づいた点があれば加筆するかもしれません。
Developers Summit 2017 Summer【A-7】こっそり教える有名コミュニティの裏話 ～Tensorflow、Java、PyData～ 聴講メモ
講演資料
資料公開予定なし。
概要
エンジニアコミュニティの現状、課題、裏話等について、老舗や新鋭コミュニティの中の人(運営側の人)がパネルディスカッションする。
スピーカー
- ウルシステムズの漆原さん(司会)
- ブレインパッドの下田さん(パネリスト)
- TFUG運営。Google Developer Expert。
- Microsoftの寺田さん(パネリスト)
- Slideshipの池内さん(パネリスト)
- PyData.Tokyo運営。
詳細
各コミュニティについて
TFUG(Tensor Flow User Group)
- 2016/11立ち上げ。
- 約2800名のユーザ。
JJUG(Japan Java User Group)
- 2007/4設立。
- 一時期(2012年頃)は登録者数が少なかったが、現在は6000名ぐらい。
- ちょうどOracleがSunを買収完了した時期。政治的な理由に加えて、他の言語の盛り上がりもあった。
PyData.Tokyo
設立、参加のきっかけ
下田氏
寺田氏
- JJUGは丸山氏によって立ち上げられた。
- 日本にコミュニティがないということから。
- ６年前に幹事に。
- 所属していた企業で、コミュニティの幹事になってはならないというルールがあって、事務局長になっていた。
- なぜJava Championになったのか?
- 海外の友人が多い。
- JavaOneに行ったら日本人と交わらないようにしている。時間があったら外部の人と会っている。
- 自分の活動を知ってくれている海外の人が多かったことが要因では。
池内氏
- 前の会社にいたときにPyData面白いよ、と登壇時に話をし、PyDataの人集めたら面白いと思うよ、と言ったのが発端。
- ニーズとして多そうだ、多かった、という実情もあった。
- 情報格差(海外と比して2年ぐらい遅れている)をなんとか縮めたいと考えた。
漆原氏
- 皆、情報を発信している中で見出されたという印象がある。
コミュニティ活動の醍醐味
寺田氏
- 多くの人と出会える。
- 地方のイベントに行くほうが交流が深くなる。
- 良い人に会える。
- パッションを持っている人はすぐに分かる。
池内氏
- いろんな価値観に触れられた。
- 運営を通してグローバルな発想に触れられる。
下田氏
- 自分が行きたいコミュニティを作りたいと思っていた(そして作れた)。
- データサイエンティストのコミュニティは技術者が少なかった。
- アカデミック寄り過ぎても、ビジネス寄り過ぎてもダメ。
- 価値を届けられるようなコミュニティにしたい。
- 参加者は、企画、エンジニア、アカデミックとさまざま。
- エンジニアもモバイル系、組み込み系など多種多様。
苦労していること
池内氏
- 識者に話をしてもらうのだが、誰に話をしてもらうか。
- 内容的にもディープな話をしてもらいたいが、難しすぎると誰もついてこれない。
- 講演者はイベント来場者の伝手や、スライド・ブログ等から。会社経由ということもある。
下田氏
- 内輪になりすぎず、それでいて行きたいと思う環境の塩梅が難しい。
- 最初は入門者しかいないのだが、時間が経ってくると入門者と専門家等、層が広がってくる。
- すべての参加者の需要を満たせないので、分科会を作る等の工夫をしている。
- 提供しつつ自分も楽しむ、ということの両立に苦しむ。
寺田氏
- 300人ぐらいだった頃はもっと大きくしたいと思っていた。
- 大規模化した後は、それまでやってきたやり方では回らなくなる。
参加できない人やクレームへの対応
池内氏
- connpassの抽選機能で行っている。
- ヘイトコントロールが難しい。
- 当日キャンセルとの戦い。
- ドタキャンは仕方ない。皆忙しいし都合がある。
- が、サイレント不参加は問題。本当に行きたい人が来れなくなる。
下田氏
- スルー力が大事。運営は透明にやっているので。
- (登壇枠は別なので)どうしても参加したければ登壇してください、と言っている。
寺田氏
- 事務方は10名ぐらいいて、毎月幹事会を開いている。クレームに対してもKPTをやって対応。
イベント費用の工面
池内氏
- 会場を借りつつスポンサーセッションを作っている。
下田氏
- GoogleのDevelopers Committeeから支援を受けている。
寺田氏
- 大規模化すると会場のキャパが問題になってくる。お金がかかる。
- ボランティアでやっているのでお金を儲けることはできない。
- JJUGのTシャツを作ったら、売ってくれと言われたが、売ったら商売になっちゃうので難しい。
コミュニティ活動で失ったもの
寺田氏
- イベントは週末になりがちなので、家族との時間。
池内氏
- コミュニティの色がつきすぎた。
- 他にも言語を使っているが、PyDataの人という見方をされてしまう。
下田氏
コミュニティへの参加と会社の理解
寺田氏
- コミュニティに参加すること自体は上司とか関係ない。
- 自分自身を高めるために、アンテナを広げるために行くものではないか。
- また、昨今はSNS等、外のつながりが転職にすごく有利になっているという側面がある。
- よって、旧来の会社は、エンジニアをコミュニティに出したくないと考えるかもしれない。
池内氏
- 自分は(トップなので)自由に動ける。
- その上で(勤め人に対して言うならば)自由に動けばいい。
- コミュニティ参加の効果を説明する際、前の会社ではコミュニティ経由で仕事に繋がった経緯があったので、数値ベースで話をしたことがあった。
- このコミュニティとつながることで○○万円の仕事が得られたんだよ、的な。
下田氏
- コンサルに近いような会社なので、間接的な効果を理解してもらうのが難しい。
- 半分は仕事とは関係ないが、半分は無理やり仕事とつなげるようにしている。
- 戦略的に動かないといけない。
健全なコミュニティ運営
池内氏
下田氏
- 幹事を一人でやっているので、意見が割れることはない。
寺田氏
- 幹事は20名ぐらい。毎回出てくるのは10名。
- 幹事自体の入れ替えをやっている。長らくアクティブでない人は卒業してもらったりとか。
- 女性を幹事に入れることで、託児所やコーヒースペースを設けるなど、視点の多様化が図られている。
- 参加者自身も変化している。
- これは幹事自身が若返りをしているからと考えている。
- 新たに幹事を任命する際は、幹事メンバーの過半数承認が必要。
- パッションを持っている人に(幹事にならないかと)声をかける。何よりも重要なのはパッション。
- JJUGでは会長1名、副会長2,3名を置いて、その下に幹事。
コミュニティへの貢献方法
池内氏
- 質問をする。
- 興味深く聞いてくれたことを登壇者に伝えられるし、盛り上がった、という印象を与えられる。
下田氏
- 会場で得られたことをブログやSNSで配信して欲しい。
- 主催者側に大きなカンファレンスを主催するための後押しをしてほしい。
寺田氏
- 会場のボランティア。
- いいドキュメントを見つけたら、翻訳、共有する。
- 今後、英語のドキュメントの邦訳はますます減っていくだろうから。
- JavaのEarly Versionを試してバグを見つけたら報告とか、できることはたくさんある。
運営に向いている人
池内氏
- ホスピタリティがある人が向いている。
- 登壇者や参加者への配慮という観点で。
下田氏
- 前には出ないが、作戦を立てて盛り上げていく軍師タイプの人。
- 仕掛け人をやるのが面白いのでは。
運営側に回ることによるメリット
池内氏
- (普段の仕事ではなかなか得られない)マネジメント視点、組織運営視点を得られる。
下田氏
- 自分が行きたいコミュニティを作ることができる。
最後に一言
池内氏
- サイレント不参加の風潮をなくしていきたい。
- 抑止策を考えざるを得なくなってしまうので。
下田氏
- 気軽に来てほしい。
- (人数的に参加できない人がいるというツッコミに対して)パッションを持って運営側に来て欲しい。
寺田氏
- ソフトウェア開発で世界との対等性を得ていくためには、コミュニティの力が不可欠と考えている。
- 世界と日本の標準がかけ離れているという実情がある。
- 海外では『Strutsなんて使うかよ』だが、国内だと『そうは言っても…』。
- どのコミュニティでもいいので参加してアンテナを張り、情報を入手し、広めていってほしい。
- 会社の先輩、後輩に声がけしていって欲しい。
- 世界と日本の標準がかけ離れているという実情がある。
Developers Summit 2017 Summer【C-6】CIにおけるセキュリティテストの組み込み方について 聴講メモ
講演資料
資料公開予定なし。
概要
激化するWebアプリへの攻撃を紹介しつつ、高速化する開発とセキュリティ対策の両立を図るための手段として、"DevSecOps"の考え方に基づいて、CIの中にセキュリティテストを導入する手法について紹介する。
スピーカー
ユービーセキュアの最首さん。製品事業を統括している。
詳細
増加するDDoS攻撃
昨年秋、史上最大のDDoS(Distributed Denial of Service)攻撃が発生した。
商用DDoS攻撃をスクープしたBrian Krebsのサイトに対して、665[Gbps]の攻撃。
- フランスISP(OVH)が複数経路からDDoS攻撃を受けた。攻撃の一つは799[Gbps]、総計1.1[Tbps]の攻撃。
- 攻撃元は15万台のボットネット。
- 昨年10月にDyn社が運営していたDNSがダウン。
Mirai
教訓
- IoT機器は初期設定情報を変更してから使用する。
- 昨今の攻撃では、攻撃者の修正や、攻撃のスピードが早いという特徴がある。
Miraiのデモ
- ここで、登壇者のPC内仮想環境上でMiraiの攻撃デモが行われた。
開発スピートとセキュリティ対策の両立
アプリケーション開発のライフサイクルとセキュリティ診断のスピード感が合わない。
- 外部診断は費用、時間がかかるので、ライフサイクルに組み込みにくい。
- 数回分のリリースをまとめて外部診断しているケースもある。
“DevOps"にセキュリティを組み入れて"DevSecOps"に。
- DevOpsのスピード感を活かしたままセキュリティプロセスを取り込む。各工程にセキュリティ対策を入れていこう、という考え方。
- 数年前からガードナーがコンセプトを出しており、RSA Conference 2016などで言及されている。
- 実装、テスト、リリース時にセキュリティ診断を行う。
- 単に診断を組み込むだけでは速度が落ちるので、実装、テスト、リリースについて自動化を行う。
“ツールで診断を自動化する"、"脆弱性検出を前倒す"が目指す姿。
- 開発者自身が診断実施者になる。
- これまでは外部の実施者がブラックボックステストとして実施していた。
- 開発者が診断することでホワイトボックス、グレーボックステストになる。
- 開発者自身が診断実施者になる。
開発者が診断実施者になるメリット。
- 開発者が希望するタイミングで診断が行えるようになる。
- 実施範囲を自分で決められる。
- 検出結果の判定が容易。
- セキュリティ対策知識が開発側に蓄積されていく。
診断自動化に用いるツールの特徴
- SAST(Static Application Security Testing)とDAST(Dynamic Application Security Testing)。
- SASTはソースに対する静的解析。
- DASTは動作するアプリに対して動的に解析。
SAST
- パターンマッチングやライブラリチェックなどを行う。
以下のようなデータフロー解析がよく採用される。
- 外部入力を受け取る変数(ソース)を探す。
- エスケープ処理を探す箇所(フィルタ)を探す。
- 変数が制御に影響する処理(シンク)を探す。
- ソースからシンクに行く間にフィルタが働いているかを確認する。
脆弱性の検出率はツール依存。
- 実施準備が容易。
- 比較的診断時間が短い(数分から数時間)。
- ちなみにMiraiをSAFESQL(SQLインジェクション静的解析)で検査したら数秒で終了した。
- SQLインジェクションの脆弱性はなかった。Miraiはよくできている。
- ちなみにMiraiをSAFESQL(SQLインジェクション静的解析)で検査したら数秒で終了した。
- 過検知が多い傾向がある。
- 比較的診断時間が短い(数分から数時間)。
- SCA(Software Composition Analysys)という系統のツールもある。
- OSS含め種々のツールが有る。
DAST
- 擬似攻撃リクエストを送り、レスポンスで脆弱性を判断する。
- 攻撃パターンを切り替えつつリクエストを行う。
- 環境構築とツール設定が必要。
- SASTと比して診断時間が長い(数時間から数十時間)。
- SASTと比して過検知が少ない。
- OWASP ZAPが優秀なツールとして有名。
- OWASP(Open Web Application Security Project)。Webセキュリティを中心テーマとした非営利組織。
誤検知
- セキュリティテストには誤検知の問題があるので注意。
DevSecOpsの実施
4つの自動化された作業からなる。
- 開発者の手元で簡易なSASTを行う。
- (プルリク等により)マージするタイミングでSCA(ライブラリチェック)。
- SASTサーバでSAST診断。
- デプロイする段階でテスト環境に対してDASTを実行。
簡易SAST->SCA->SAST->DAST->マニュアル診断、という手順で脆弱性をふるい落とす。
認証不備や機能レベルのアクセス制御をマニュアルでチェックする。
- あまり修正するところではないはずなので、毎回実施する必要はなく、初回リリースやメジャーリリースで行えば良い。
複数のSASTを導入すると良い。
- 早く開発者にフィードバックすることが重要。
- 可能であれば簡易SASTはIDEに組み込む。
- データフローのような解析系は時間がかかるので、プルリク時に専用環境で実施するのがおすすめ。
- 過検知が発生した場合、次の解析時から除外して検査できるツールを使うとよい。
DASTも専用の環境で実施する。
- 診断用テストデータを準備し、シナリオとセットで管理する。
- 変更や削除処理用のテストデータは事前投入する。
- 同じリクエスト処理を何度も行うので、エラー検知機能や通知機能はOFFにしておく。
- 高い性能の環境で実施するとよい。
DASTの診断時間が短いアプリの特徴。
ツール導入時の考え方
- どういうツールを使うか？
- 複数のツールを導入して、なるべく早い工程で脆弱性を見つける。
- マニュアル診断はどこで？
- ツールはどのように使い分ければ？
- SASTは複数ツールの導入を推奨。
- DASTはツール設定でユーザ操作の再現性、網羅性を上げるとよい。
余談
- ユービーセキュア製のVEXというツールはBlack Hat USA 2017で出展しているらしい。
