タイムラインを使って、振り返りの材料をうまく集めよう

こんにちは、moaiです。 この記事はfreee Developers Advent Calendar 2018 12/18の記事になります。

今日はタイムラインという振り返りの材料をうまく集める方法を紹介したいと思います。

振り返りするときにこんな悩みはありませんか?

振り返りというのは古今東西どのような組織でも行われていると思います。 そのため、振り返りをやっているうちに、 自分たちの振り返りは本当に振り返りはうまくいっているのだろうかと思うこともあると思います。

例えば、振り返り自体の悩みとしてはこんなものがあるかなと思います。

  • 話題がいつも発散してしまう。
  • うまくメンバーから意見が出てこない。
  • 何か問題がありそうな気もするが対策が良く分からない。
  • 問題は分かるが対策が出てこない。
  • 次にやることがなかなか決まらない。

今回は、『うまくメンバーから意見が出てこない。』、 『何か問題がありそうな気もするが対策が良く分からない。』という悩みに効くタイムラインの紹介です。

そもそもタイムラインって?

ざっくり

タイムラインは振り返りの手法です。 具体的にはホワイトボードに振り返りたいテーマに対して、 あったことや感情を付箋で時系列に沿って貼りだすことを行います。

こんな感じで話し合いを行います。

ホワイトボードに時系列で起こったことを付箋で張り付けながら、それについて話し合う人たちの図
ホワイトボードを使って話し合う人たちの図

大事なポイントはホワイトボードを使うことと、付箋を使うことです。

この手法を用いた振り返りの結果として、こんな成果物が出来上がります。

時系列で起こったことを付箋で張り付けて、ホワイトボード上でGood, Badで分類している様子を図示しているものと、ホワイトボード上で全体的にGood、Badなことを付箋で貼り付け、分類している様子を図示したもの。
タイムラインの成果物

詳しく

事前準備として、付箋を貼れる壁と付箋、付箋に文字を書くためのペンを人数分用意しておきます。

手順は以下のように行われ、特に太字にしたところがタイムラインの特徴的なところです。

  • ファシリテーターが振り返りたいテーマを決めます。
  • 時系列を表す線と、Good、Badの区分けをしておきます。
  • 最初に時系列でもマイルストーンとなるような出来事をいくつかピックアップして書き出しておきます。
  • 参加者にテーマに沿った出来事と思ったことを各自書いてもらい、時系列に沿って貼ってもらいます。
  • 壁に貼りだしたものを使って、良かったこと、悪かったことを分析します。
  • 次にやることを決めます。

この手順にかかる時間は2週間から4週間くらいのプロジェクトでは経験的に30分から1時間くらいでした。

タイムラインの役に立つところは?

振り返りの材料が集まります。

タイムラインを行うことで、振り返りをする際の材料がとてもうまく集まるようになります。

なぜかというと、(振り返り材料を出す)書き出しという行為の心理的な障壁を下げることができるからです。

まず、書き出すという行為と分類する(GoodとBadに貼る)という行為を分けることで、 分類のことはいったん忘れて、書き出す行為に集中できるようになります。 人間はきちんと分類しながら、書き出していくという作業が意外と苦手なのです。

書いている人と分類している人の画像の間に同時にやらないという文字が書かれている図
書くと分けるを同時にやらない

また、付箋を使うことによって、分類や起こった出来事の順番が誤っていたとしても、 すぐに修正できるということが、書き出しや分類する(GoodとBadに貼る)ということに対する 心理的な障壁を下げます。

タイムラインにおいて、付箋を使うことは、書き出す、分類するという行為を分けることでき、 また、すぐに位置を修正できるという非常に重要な意味を持ちます。

こういう小さな工夫が意外と振り返りの材料を出すのを妨げます。

分析のインプットになります

タイムラインを行うことによって、振り返りの良いインプットになります。

なぜかというと、すべての出来事、感情が同じホワイトボードにあることが一覧性が高まり、 それらの関連性が判断しやすくなることが、分析を助けるからです。

タイムラインでは、起こった出来事に対して、どう思ったのかをホワイトボードに貼っているため、 どのように関連しているのかを線でつなげることも、 似ているとおもったら、付箋を近くに持ってくることもできます。

ホワイトボード上でGood, Badで分類している様子を図示しているものに対して、分析した結果、書き込んだ注意書きと注意書きと起こった事象の関連性を線で書き足した箇所を黄色く囲って強調している図
関連性を線で書き足した

人間は二次元的に並べられたものに対して、関連性を見つけたり、違いを見つけることが得意なのです。 箇条書きのように等しく並べられたものに対して、行うよりもずっとうまく行うことができます。

また、この手法は出来事と感情を同じく付箋に書いてもらいます。 そのため、出来事に対して、参加者がどう思ったのかのかも等しく扱うことができます。 これによって、起こったことに対する感情がなぜ起こったのか分析したり、 追加で書き込んだりすることができるため、とてもうまく行えます。

タイムラインにおいて、付箋とホワイトボードを使うことは、すべてのものを二次元的に並べることができるという意味で、 とても重要な意味を持ちます。

タイムラインの役に立たないところは?

タイムラインはあくまで、振り返りの材料をうまく出すということにフォーカスした手法です。

そのため、基本的にはそれ以外のことには効きません。 振り返りの材料は、分析のインプットになるため、分析のために良いインプットを出すという意味はあります。

一方で、『話題がいつも発散してしまう。』や、『次にやることがなかなか決まらない。』といった悩みには効きません。

ホワイトボード上でGood, Badで分類している様子を図示しているものに対して、タイムラインが有効に働かない箇所として、次にやることの箇所を黄色で囲っている図
あまりタイムラインが有効に働かない箇所

これらの悩みはつまり、話し合いのスコープを絞り切れていなかったり、 やることを決める方法が決まっていなかったりすることが原因なので、 タイムラインは、これらの問題の対策としてはうまく作用しないのです。

終わりに

今回は振り返りの手法としてタイムラインを紹介しました。 しかし、振り返りの困りごとは今回のような『うまく意見が出ないなー』ということだけではないと思います。

そんな時でも先人たちは振り返りに対する困りごと毎に、いろいろな対策を考えてきました。 その悩みと対策を紹介した本として、アジャイルレトロスペクティブという本があります。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

この本を読むと、自分の悩みが振り返りにおいては、どんな意味を持つのか、 また、その悩みにはどんな対策があるのかを知ることができます。 是非参考にしてみてください。

この記事を読んだ、みなさんの振り返りがより実りあるものになると願っています。

明日はShuhei Kotegawaさんによる『APIの話 or プロマネデビューして学んだこと』です。 お楽しみに。

突撃!隣の自作キーボード

こんにちは、SREの id:foostan です。 この記事はfreee Developers Advent Calendar 2018の17日目です。

昨年に引き続きキーボードネタでお送りします。 なお昨年の記事はこちらになります。

developers.freee.co.jp

今年は自作キーボード特集!

皆さんは自作キーボードをご存知でしょうか。 今年は巷では自作キーボード元年と比喩されるほど、国内で「キーボードを自分で作る」ことが流行った年になりました。

キーボードを作る?と思った方に簡単に説明すると、キーボードというものは

  • キースイッチ
  • キーキャップ
  • ケース
  • 基板(PCB)
  • その他電子部品

で構成されていて、自作キーボードとはその名の通り、これらのパーツを買い揃えて組み立てたものです。一見難しそうに思えますが、これらのパーツは「自作キーボードキット」という形ですべて(もしくは主要なパーツ)が揃った状態で販売されています。

2018年は国内でこのようなキットの販売を開始した方々が大勢現れた年であり、キーボード好きがこぞってそれらキットを買い漁った年とも言えます。

社内でもそのブームが起こっていて、2017年には自作キーボードユーザは2人しかいませんでしたが、今年は23人も自作キーボードキットを買うという異常事態でした*1

社内にあふれる自作キーボードキットの数々

こちらは皆が購入したキットについて集計した結果です*2

自作キーボードキットをいくつ持っていますか?のアンケート結果。1位は1個の56.5%、2〜3個が21.7%、10個以上という人もいる
キットの内訳結果。Irisが一番多く、HelixやCorneが続く

キットの所持数は1つだけという人がさすがに多いですが、「ひとつ作ったらまた作りたくなった」と言い、複数個買うケースが多く見られました。 買ったキットをすべて作ったというわけではないですが、2個3個は普通で、中には10個近く買う人もいます。

その内訳を見るとIris*3、Helix*4、Corne*5の順で購入数が多いです。 自作キーボードに興味を持った人は分割キーボードを求めているケースが多く、ErgoDoxじゃ大きすぎるという理由でIrisを購入する人が多くいました。 Helixは人気のキーボードなので弊社でも持っている人が多いです。 CorneについてはIrisを使ってみた結果数字列がいらないな、という理由で購入された人が多い印象です。

次はキースイッチについてです。

スイッチのタイプはタクタイルが1位の56.1%、リニアが26.8%、クリッキーが17.1% その内訳。Gateron Silent Brown、Gateron Red、Gateron Brownが人気。

自作キーボードで使われるスイッチは基本的にはメカニカルスイッチと呼ばれるものですが、そのスイッチには主に3つのタイプがあります。

  • タクタイル: スイッチ感があるもの
  • クリッキー: スイッチ感がありかつカチカチと音を鳴らすもの
  • リニア: スイッチ感がなくスコスコと押せるもの

社内での利用状況を見るとタクタイルが一番多く、その次はリニアでした。さすがに社内でクリッキーを使う人は少ないようです。 またその内訳を見ると、Gateron Silent Brown が一番多く5人でした。ちなみにGateronとはキースイッチを製造している中国の会社で、Silent Brownとはそこで出している静音タイプの茶軸のことです。 よく市販されている茶軸と似たような感触でかつ静音タイプなのでオフィスでも使いやすく、人気が高いようでした。

ちなみに社内でキットの購入を考えている方には以下のようなキースイッチのテスターで実際にいろいろ触ってもらっています。 Gateron Silent Brown、Zealios、Zilentが人気ですが、ZealiosやZilentは値段を聞いて諦めることが多いです。

f:id:foostan:20181214120134j:plain
キースイッチのテスター

社内での活動

コミュニティ

社内SNSのコミュニティ 昨年のアドベントカレンダーの記事を書くにあたり社内にはキーボード好きが多くいることがわかったので、Workplace(社内Facebook)にてキーボードグループを作成し、ライトな話題からディープなやりとりまでざっくばらんに情報交換をしています。

こちらのコミュニティで自作キーボードキットやキースイッチの共同購入の話などもしています。 キースイッチの共同購入の呼び掛け いろいろな部品の共同購入の呼び掛け

自作キーボードキットの共同購入

2018年のはじめ頃はまだ国内で手に入る自作キーボードキットはあまりなかったので、海外で販売されているキットの共同購入の計画を立てたりもしました。 またHelixの販売開始直後は在庫が復活しても1時間足らずで売り切れるほど人気でまとまった数がなかなか手に入らなかったため、公開されているデータ*6から基板の発注やその他パーツを共同購入したりもしました。

共同購入した大量のHelix 共同購入した大量のIris

定期開催されるもくもく会

自作キーボードに興味を持った人が社内に大勢いたので社内の部活動として認定*7してもらい、定期的にもくもく会を開催しています。

細かいはんだ付け
キースイッチをつけて完成間近
ダイオードを刺した状態、これからはんだ付けを行うところ

個人のキーボード紹介

今回キーボードを作成した10人にインタビューをしたのでそれぞれ紹介していきます。

taiyo

社内でユーザが多いIris。白い無刻印にfreeeキーキャップと紫の2Uキーキャップが映える

Q: 自作キーボードキットを購入したきっかけを教えてください

元々HHKBを使っていて、キーボード自体への興味がありました。 セパレートを選んだのは肩を広げて肩こりを減らせると思ったからで、自作しようと思ったのはそういう工作の経験がほとんどなかったのでやってみようと思ったからです。 また個人の特性として周りが持っていないようなオリジナルものを作る、持つ、使うということに悦びを感じるのも理由の一つです。

Q: 製作してみていかがでしたか?

不器用なので最初ははんだ付け自体に困難を感じましたが、はんだ付けし終わって、全部通電した時は気持ちよかったです。 キーキャップやキースイッチ、キーマップまで自分の好きなようにカスタマイズできるので、自分に最適化させたモノを作れるということ自体が楽しいです。

Q: 次にやりたいことはありますか?

キーキャップはデザインにもこだわったものを買って使いたいです。 あとキット購入済みのCorneとHelixを光らせたい!

Q: キーボードについてこだわりポイントがあれば教えてください

キースイッチは納得いったものを使うようにしています。 どちらかというと重めで打鍵感があるものを好んで使用しています。

これぐらい肩を広げられるのはセパレートタイプの醍醐味

budougumi0617

最初はIrisを使っていたが、数字列が不要と感じCorneを使い始めた

Q: 自作キーボードキットを購入したきっかけを教えてください

リーダー(narinari)が沼の人だったためです。

Q: 製作してみていかがでしたか?

はんだ付けしていると時間も溶ける。

Q: 次にやりたいことはありますか?

キー配置を探求したいです。

Q: キーボードについてこだわりポイントがあれば教えてください

なるべくホームポジションを崩さない(崩れない)ようにしたいと思っています。

MacBookのトラックパッドが中央に来るようにキーボードを配置している

narinari

自ら設計した 'Xenon'。すべて1UのColumn Staggered。ロープロファイルを組み合わせているのが特徴的。

Q: 自作キーボードキットを購入したきっかけを教えてください

腱鞘炎になったので手に優しいキーボードを探していました。

Q: 製作してみていかがでしたか?

たくさん作ったので、だんだん組み立てる速度が早くなってきてよりハードルが下がってます。キーマップはホント沼で終りが見えず、仮住まいで満足した気になっています。

Q: 次にやりたいことはありますか?

自分用に設計したPCBを公開できていないので公開したいです。別のキーボードの設計も始めてます。

Q: キーボードについてこだわりポイントがあれば教えてください

作りすぎてあまりこだわりが無くなっている気がします。あえて言うなら、選ぶキーボードは必ず割れていることですかね。

f:id:foostan:20181211201907j:plain
こちらは同僚に貸しているHelix。こちらもロープロファイルを組み合わせている。

noblejasper

Irisは家用とオフィス用で2台制作。撮影用に持ってきてもらったのでデスクに2台置いてあるが、さすがに普段は1台だけとのこと。

Q: 自作キーボードキットを購入したきっかけを教えてください

以前はErgoDoxを使っていましたが、キーが多く不満を感じていたからです。

Q: 製作してみていかがでしたか?

人生初のはんだでしたが、没頭できて楽しかったです。難しかった点は ProMicro を浮いた状態ではんだ付けしてしまって、破壊しながら外した所ですかね。絶望感がすごい。

Q: 次にやりたいことはありますか?

キーキャップを作りたい&PCBを設計してみたいです。

Q: キーボードについてこだわりポイントがあれば教えてください

肩がこらないようにすることです。 来年はPCB販売できる所までやれたら理想的ですね。

freeeではオリジナルのキーキャップをノベルティとしてイベントなどで配っているので見かけた際は是非。

ikesho

Zealiosスイッチをプレートにはめたところ。クリアなハウジングに紫の軸がよく映える

Q: 自作キーボードキットを購入したきっかけを教えてください

2つにわかれたキーボードが欲しく、また面白そうだったためです。

Q: 製作してみていかがでしたか?

電子工作を久しぶりにしたので楽しいです。また自分で作ったぶん、愛着がわきます。

Q: キーボードについてこだわりポイントがあれば教えてください

押しごこちこそが重要だと思っているので、スイッチは遠慮しませんでした。

完成まであと一歩

かず

シンプルな黒の無刻印キーキャップ

Q: 自作キーボードキットを購入したきっかけを教えてください

面白そうだったからです。

Q: 製作してみていかがでしたか?

LEDを付けるのが難しかったです。あとキーマップを考えるのが楽しいです。

Q: 次にやりたいことはありますか?

新しいものを何台か作ってみて、後々はPCBを設計したいです。

Q: キーボードについてこだわりポイントがあれば教えてください

打った感じが、メカニカルの方が好きです(だいたい値段が高めなので最近は買えてない)。

スイッチはGateron Red。LEDをつけるためSMD対応のハウジング。

toofu__

動作確認をしている様子。挙動が不安定なためまだ修正が必要。

Q: 自作キーボードキットを購入したきっかけを教えてください

しばらくHHKBを使っていて、何か新しいのを触りたいなと思ったときに、かわいい見た目の自作キーボードが目に入ってきたためです。

Q: 製作してみていかがでしたか?

2台製作したんですが(IrisとMint60*8)、どちらも完成まで組み立てたところで「一部のキーがうまく動かない」「左右の通信がうまくいかない」といった不具合が発覚し、直すためにはスイッチのはんだをシュッ*9しなければならないというツラい状況になりました。 まだ1台も完成していないので、現状「ただ自作キーボードに数万円費やして何も成していない人」になっています。 もはや他の人に製作外注したほうがいいのかもしれないです。

Q: キーボードについてこだわりポイントがあれば教えてください

かわいいやつ。

修復をしている様子。 キットによっては修復の際にキースイッチやProMicroのはんだ付けをやり直す必要があり、このような専用の工具(はんだシュッ太郎)を使うと効率的。

ララ・チャン

丁寧に仕上げたLily58*10。白い基版に白いキーキャップがよく似合う。
※ 片側のProMicroは修復をした関係で裏表逆についています(本来のキットは同じ向きなので注意)。

Q: 自作キーボードキットを購入したきっかけを教えてください

分割キーボードに憧れたためです。アニメとかで見る多面コンソールっぽいですね。

Q: 製作してみていかがでしたか?

以前、ゼロから作る方法も教えてもらったのですが、難易度が高すぎて「既製品でいいかな〜」と断念しかかってました*11。 今回はワンセットになっているキットが好きなデザインで、一緒に教えてくれる環境があったので、めでたくデビューできました。 安心感半端なく、人に紹介できるくらい楽しかったです。

難しかったところといえば、基礎知識大事だなーと。 はんだ付けの上手い下手がどういうものなのか、ProMicroの設置場所は基板をよく見ないとずれちゃうとかはいい経験値になりました(^^)ゞ

Q: 次にやりたいことはありますか?

キーマップ作成やキーマップに合わせた印字のキーキャップ作成。 あと新しいものも作りたいかも。

Q: キーボードについてこだわりポイントがあれば教えてください

色と配列です。また操作性とデザイン突き詰めたいです。

はんだ付けは中学の授業以来とのことだが、はんだ付けの仕方を動画で学んで制作に挑んだとのこと。久々のハンダ付けとは思えないほど綺麗な仕上がり。

foostan

MacのトラックパッドとCorneの組み合わせ。

Q: 自作キーボードキットを購入したきっかけを教えてください

Let's Splitを見て小さくてかわいいなーと思っていたところに、先に沼に浸かっていた方(narinariさん)が入社してきたのでそこからパーツを集め始めました。

Q: 製作してみていかがでしたか?

始めた当初は久々のはんだ付けだったのでうまくいかないことが多かったです。 それなりに良いはんだごてを買ってからはきれいにできるようになりましたが、HelixのLEDで挫折しかけました。

Q: 次にやりたいことはありますか?

Corneの改良とModulo対応*12は直近でやろうかなと思っています。 あとdactyle-manuform*13のような立体型のキーボードを作ってみたいです。

Q: キーボードについてこだわりポイントがあれば教えてください

キー配置とキースイッチの推し心地にはこだわっていますが、まだ納得していません。

たくさんの数字を打つことがあるので、テンキーは別で用意している(Attack25*14 )。

ymrl

f:id:foostan:20181212155746j:plain
スタンディングデスクにたくさんのキーボードが並んでいる。ちなみにHHKBはPCにつながっていない。

メインで使っているのはErgo42*15。これに特徴的なキーキャップが並んでいる。

Q: 自作キーボードキットを購入したきっかけを教えてください

最初は同僚に誘われたためです。そのあと数字列要らないとか考えるようになって色々と。

Q: 次にやりたいことはありますか?

自分のほしいものものはいろいろ作れたので、ちょっと興味あるくらいの人に勧められる何かとかを考えたいですね。

Q: キーボードについてこだわりポイントがあれば教えてください

スイッチの感触や英字配列、外付けキーボードもノートPC本体のキーボードもMacもWindowsも違和感なく乗り換えられるように、ソフトウェアによるキーリマップを併用したりすることですね。 あとはセミコロンとエンターを入れ替えています。

こちらは馬の毛を使ったキーボード専用のブラシ。以前HHKBミートアップで登壇した際にもらったもの。

f:id:foostan:20181214124008j:plain
キーボードはファッション(KeyPierce*16 )

最後に

いかがでしたでしょうか。

同じ自作キーボードキットでもひとつひとつ個性があり、またキーマップをこだわるなど自分に最適なキーボードを追い求めている人がたくさんいました。皆さんのこだわりの話が聞けてインタビューしていてとても楽しかったです。

freeeでは一緒に仕事をする仲間を募集しているのはもちろんですが、一緒に沼(≒温泉)に入ってくれる仲間を募集しています。

自作キーボードの集合写真

明日は最近DDDにハマっている id:ryamazaki です。お楽しみに!

*1:だたしそのうちメインで使っているのは10人程度です

*2:筆者はCorneの製作者なのでCorneのカウントは省きました

*3: Keeb.ioにて販売されている分離型キーボード。ErgoDoxよりも小型だが数字列があるので初めてでもとっつきやすいです。

*4:遊舎工房にて販売されている左右分離型キーボード。国内初の自作キーボードキットとして登場しブームの火付け役となりました。

*5:筆者が設計/公開している小型の左右分離型キーボード。Irisに似ていますが数字列がありません。

*6:MIT Licenseで公開されています。

*7:公式認定されると部費で工具等を買ってもらえます。

*8:ゆかりキーボードファクトリーで販売されている左右分離型キーボード。自作キーボード初心者にとって組みやすくまた扱いやすくなっています。

*9:はんだシュッ太郎 によってはんだを吸い取る行為

*10:ゆーち氏が設計/販売している左右分離型キーボード(現在は販売終了しているが冬コミで新しい版が販売される予定)。Irisに似ているがキー数が少し多くまた薄型になっています。

*11:部活動の一環としてPCBを一から設計する会を行いました。

*12: Ergo42 Modulo のペンダント対応

*13:3Dデータが公開されているため好みに修正して3Dプリントすることが可能です。

*14:monksoffunk氏が設計/販売している25キーのキーボード。テンキーとして最適です。

*15:Biacco42氏が設計/販売している左右分離型キーボード。レツプリよりも内側に1行多く、カッコを配置するなどプログラマ向けのキーマップがしやすい設計になっています。

*16:tomykaira氏が設計/販売されていた1キーだけのキーボード。PCに接続して使うことができます。

freeeの品質トゥギャザー:リスク洗い出し編

ども。皆のQAアニキ、freeeをテストするおっさん*1ことコヤマンです。

この記事はfreee Developers Advent Calendarの16日目です。※22日公開予定だったのですが、諸事情により記事公開を早めさせていただきました。

12/8(土)に弊社にて開催したシステムテスト自動化カンファレンス2018において「freeeの品質トゥギャザー」と題して弊社の品質への取り組みの発表があったのですが、そこで伝えきれなかった素敵な取り組みの1つである「リスク洗い出し」についてエントリーさせていただきました。

テストの目的

さて。リスク洗い出しのご紹介の前に改めて「テストの目的」とはなんぞや、というのをご紹介したいと思います。

JSTQBというソフトウエアテストの資格*2があり、ソフトウエアテストの広義の目的が4つ定義されています。

  1. 欠陥を摘出する
  2. 対象ソフトウェアの品質レベルが十分であることを確認する
  3. 意思決定のための情報を示す
  4. 欠陥の作りこみを防ぐ

この目的は、開発におけるシーンによって何が主目的なのか、という点が変わってきます。

DevOpsでのテストとシフトレフト

f:id:koyatest:20181211164636p:plain
DevOpsサイクル
※上図はeBayのHead of TestであるDan Ashby氏の記事の画像を元に加工のため書き起こしています

freeeは所謂DevOpsをしていると言えるのですが、DevOpsでは「継続的テスト」をするのが一般的です。

上記で箇条書きしたテストの主目的をDevOpsサイクルに当てはめると、以下のようになります。

f:id:koyatest:20181211234056p:plain
継続的テストとテストの主目的
※目的3の「意思決定のための情報を示す」は主目的にはありませんが、常に実施します

テストは「知ること」なので、フィードバック(情報提供)は早い方が良いです。 フィードバックが早ければ早いほど問題の解決が安上がりになりますので*3、テストの原則*4としてテストは早ければ早いほど良い(=効果が高い)と言われています。

そのため、開発の初期であるPlan,Branch,Codeのあたりでは目的4の「欠陥の作りこみを防ぐ」が主目的になります。 このように開発の初期にテスト活動することを「シフトレフト」と呼んでさまざまな取り組みがなされています。

freeeはリスク洗い出しでシフトレフト

freeeが扱うお客様のデータはクリティカルなものが多いため、品質を疎かにできません。 しかしながら品質を上げる、保つ活動をDevOpsの中でスピード感を持ちながら実施することが要求されるためにシフトレフトな活動をしています。

その中で代表的な活動が「リスク洗い出し会」(そのまんま)です。

リスク洗い出しでトゥギャザー

リスク洗い出し会を一言で表現すると 「みんなの"ヤバい"を共有して方針を決める会」です。

開発の初期段階からプロジェクトやプロダクトの情報を皆で共有して理解し、エンジニア以外の目線でもヤバいところ、不安なところを洗い出して方針を決めます。

具体的には以下のステップで進めます。

  1. 人を集める
  2. ヤバい、不安だを共有する
  3. 方針と担当を決める
  4. プロジェクトを進めるにあたり都度確認する
  5. 新たに気づいたら追加して共有する
  6. 最後に振り返りする

QA(テストするおっさん)の役割

おっさんは以下の活動をします。

  • トゥギャザーする人を集める(セールス、サポート、マーケティング、PM、Engなどなど)
  • 開催までに仕様・データ構造・アーキテクチャや連携する対象などをできる限り理解する
  • ヤバいと思うところを予めリストアップしておく
  • テストしようと思うことを予めリストアップしておく
  • 洗い出し会を設定する
  • リスク洗い出し会をファシる(みんなのヤバいを引き出す)
  • プロジェクト中に都度リスク表を確認する

このトゥギャザーによりコードを書く前あるいは書いている最中にフィードバックすることが可能になり、以下のような効果が早い段階で得られます。

  • 優先順位やセリングポイントの共有
  • マイルストンと熱量の共有
  • みんなが困ることとその対策
  • 構造・仕様の共有
  • 頑張るところ、頑張らなくていいところ*5の明確化
  • ヤバいの未然防止・手戻りの予防
  • いつまでに何をしないといけないのか
  • 各人が何をした方がいいのか
  • 何からテストをした方がいいのか、どの程度徹底的にやればよいか

集まった人全員に対し早めにフィードバックをすることが可能になります。

さらなる取り組み

freeeでは先日発表したDevOpsサイクルのMerge時におけるE2E per PullrequestやPlan,Branch,Code時に効果のあるリスク洗い出し、タイミングによってさまざまなシーンに効果のあるUX主導のユーザーテストなどによるシフトレフトだけでなく、Monitorとしてバグ分析やOperate時に専門家によるTesting in Productionなどシフトライトなどにも取り組んでいます。 その他、私はあまりトゥギャザーできていませんがサービス品質などの知覚品質を上げるための活動も動き始めています。

このような活動をできるのも、先日素晴らしいエントリーを裏freee Developers Advent Calendarに上げてくれた同僚のスーパーマサキさんをはじめとする素敵なメンバーがいてこそ、だと思っています。 このようにfreeeのエンジニアは品質トゥギャザーしながら、お客様にマジ価値を届けるために日々活動しています!

さて明日のfreee Developers Advent Calendarは自作キーボードの変態 伝道師こと id:foostan の記事です。 自作キーボード部の私も今から楽しみです!

*1:アジャイルチームに入ってテストしたり時々自動テスト書いたり色々やってます

*2:実は筆者はトレーニングコースの講師もしております

*3:不具合修正はコードに埋め込まれてから早いほうが安い、というのはWatts S. Humphreyさんの書籍でおなじみ

*4:JSTBにも「初期テスト」という原則があります

*5:エンジニアがやるべきところ、やらなくていいところなど

標的型攻撃と多層防御にAWS Security Hub + DeepSecurity はどうして嬉しいのか。

この記事はfreee Developers Advent Calendar 2018 15日目の記事です。 adventar.org

freee CSIRT専属エンジニアのEiji Sugiuraです。 早いもので、freeeにjoinしてから1年が経過しました。

前職では、UTM*1を使ったMSSP*2を作って運用していたので、SaaS*3はどちらかというとブラックボックスとして扱っていました。 それが、何の因果かSaaSのなかにどっぷり浸かっています。人生って何が起きるかわからないもんです。

自分から「セキュリティエンジニアです。」なんて名乗るのは眉唾ものだと思っています。他人からセキュリティエンジニアと呼ばれれば本物ですね。 自分は果たしてどうなんだ? という点はさておき、この1年間、どんなことを考えてセキュリティを無理なく無駄なく担保しようしてきたかを、まとめておきます。

ざっくりいうと、立場は変わっても、考えることは普遍ですという話です。

攻撃と防御

標的型攻撃

その昔、インターネットで報告される攻撃といえば、わかりやすく同時多発的に被害が生じるもので、愉快犯が犯人であることがほとんどでした。 しかし、2010年代に入ってから、金儲けの手段として攻撃や侵入を行い、実際に利益を得る組織の存在が知られるようになりました。 そうした組織は、標的型攻撃と呼ばれる洗練された手法を用いていました。

標的型攻撃に限らず、こうした攻撃手法は常に進化していて、APT*4攻撃と呼ばれる手法に変化しています。 この攻撃は、7つの段階を経て行われると言われています。

最も知られているのは、標的型メール攻撃なので、それを例にとると、こんな感じです。

  1. 偵察 Reconnaissance
    攻撃者は餌食となる標的を物色します。最も都合が良いのは、防御が脆くて、足がつきにくい宝物を持っている組織です。検索エンジンやSNS、メールなどから簡単に標的の情報を手に入れられるので、組織に属する人のリスト、組織構造、予定されているイベント、取引先、取引内容など、集められるものをすべて揃えておき、最も割りの良い標的を選び出します。
  2. 武器の準備 Weaponization
    標的が決まったら、malwareの作成ツールやbotnetを調達し、特定の人物に開いてもらえそうなメールのタイトルと文面を推敲し、組織が利用しているセキュリティ対策製品に検知されないことを確認したmalwareを添付ファイルやリンクとして添えたメールを用意します。
  3. 輸送 Delivery
    そして、メールを送付します。 メールは暗号化された通信路で配送されるため、配送途中にmalwareが検知されることはありません。
  4. 侵入、展開 Exploit
    組織内の誰か一人がメールを開く、もしくは開かなくてもメールを受信した時点で、パソコンのOSにmalwareが侵入します。AntiVirusには検知されません。なぜなら、検知されないことを確認済みのものを送付したからです。
  5. 潜伏 Installation
    malwareは侵入したOS上で、自らをまっとうなプロセスであるかのように偽装し、OSの管理者権限を奪取します。そして、C2C serverとの通信路を確保します。
  6. C&C->探索 Command&Control
    その後は、C&C serverからの指令に従って、周囲のパソコンやネットワーク機器への侵入を試します。
  7. 目標の奪取、掃除 ActionsOnObjectives
    探索の結果、取得したかった情報が見つかった場合、頃合いを見計らって奪取したら、自らの痕跡を消して攻撃は終了です。

APT攻撃は、標的型攻撃と比べて以下の点で進化しています。

  • 明確に目的がある
    攻撃者は、APT攻撃を仕事として取り組んでいるので、利益を得る、情報を手に入れる、もしくは、標的の評判を貶めるなど、明確な意図を持っています。
  • 見つけられない
    間欠的にしか動作しない。長期間潜伏する。ファイルを残さずにメモリ内にのみ存在する。既存のプロセス内で動作する。プロセス一覧に表示されない。などなど、様々な手法を凝らして、とにかく痕跡を残しません。
  • 技術レベルが非常に高い
    自ら攻撃ツールを作成できる専門家が組織として行動していると考えられています。標的側の兼務のセキュリティ担当なんて相手になりません。
  • 粘り強いこと
    うまくいかなければ別の方法を探り、ツールを自動でアップデートし、プラグインによる機能拡張を行う、なんてこともやってのけます。

防御する側が圧倒的に不利な状況ですね。 防御側は一つも間違いを許されないのに、攻撃側は蟻のひと噛みでどこか一つでも穴を見つければ勝ったも同然というのも困ったところです。

標的型攻撃やAPT攻撃は、日本では企業や公的機関の情報漏洩ばかりに注目が集まってしまい、あまり報道されませんでしたが、2015年12月にはウクライナにおいて戦争の手段として用いられ、基幹インフラである送電網に物理的な被害が生じました。

www.wired.com https://ics.sans.org/media/E-ISAC_SANS_Ukraine_DUC_5.pdf

この攻撃は、1年後、2年後、そして今年も継続して行われている、と考えられています。

多層防御

標的型攻撃やAPTの対処策として広く知られているのは、2009年にLockheed Martinが提唱したCyber Kill Chain = 多層防御です。

多層防御の基本的な考えは、攻撃の段階全てで、まずログを記録し、その中から異常を検知することです。 その上で、攻撃を直接的に止める、動作を妨害し時間稼ぎをする、情報を略取されたとして意味がわからないものに加工しておく、偽物を掴ませる、最終手段として攻撃元を破壊する、の全ての手段を用いて攻撃が成立しない状況を維持することを目指します。

例えば、標的型メール攻撃に対して、多層防御で対策を練った場合、以下のような対処が考えられます。 社内LAN内のサーバが、機微なデータを保持している想定です。 なお、偵察や武器を準備している段階については、一般企業では対処は難しいため省略しています。

-
攻撃段階
Discover
記録
Detect
検知
Deny
禁止
Disrupt
妨害
Degrade
矮小化
Deceive
撹乱
Destroy
破壊
3. 輸送 Internet Gateway上での対策
NetFlow IPS*5 Firewall、URL Filter、WAF*6 Rate Limit
4. 侵入 PC上でのメモリアクセスでの対策
EventLog HostIPS、LogInspection Package Update ASLR*7 Sandbox
5. 潜伏 PC上のファイルアクセスでの対策
FileIntegrity*8 AntiMalware FileAccessControl
6. 探索 社内LAN機器での対策
NetFlow IPS NetworkFirewall NetworkSegmentation RateLimit
7. 奪取 サーバ上での対策
AccessLog HostIPS、DLP HostFirewall、FileAccessControl ASLR HoneyPot

これを、AWS上に構築されたサービスシステムに適用した場合を考えてみます。 こちらは、S3 BucketやDatabaseに機微なデータを保持している想定です。

f:id:eiji-sugiura:20181215002300p:plain
AWSに構築したシステム

-
攻撃段階
Discover
記録
Detect
検知
Deny
禁止
Disrupt
妨害
Degrade
矮小化
Deceive
撹乱
Destroy
破壊
3. 輸送 ELB周りでの対策
ELB AccessLog AWS Shield、AWS WAF ELB Security Group AWS WAF Rate Limit
4. 侵入 EC2 instance上でのメモリアクセスでの対策
AuditLog、AccessLog HostIPSLogInspection Package Update ASLR Sandbox
5. 潜伏 EC2 instance上のファイルアクセスでの対策
FileIntegrity AntiMalware FileAccessControl
6. 探索 VPC内での対策
FlowLog IPS SecurityGroup NetworkSegmentation RateLimit
7. 奪取 BucketやDB周りでの対策
QueryLog、ObjectLog ObjectIPSDLP SecurityGroup、ObjectAccessControl HoneyPot

青字で示した部分は、AWSに用意されているサービスや機能によって対策が可能な部分です。

赤字で示した部分は、AWSでは提供されない機能です。EC2 Instance自身を守るには、別途仕組みを導入する必要があることが分かるかと思います。そして、この不足した機能をそのまま提供してくれるのがDeepSecurityだと考えています。

DeepSecurityの他にも、同様の機能を提供する製品は存在しますが、IPSやFile Integrity、Log Inspectionについては、signatureを編集することが可能な点がお気に入りです。

SIEM

多層防御を張り巡らせれば、仕事は終わりというわけではありません。

実は、多層防御では、各段階で膨大なログが発生します。 例えば、WebServiceに関連するものだけに絞ったとしても、以下のように様々なログが挙げられます。

ログ種別 記載される内容
Detect Log Firewall、WAF、IPS、AntiMalwareなど、セキュリティ上の異常を検知したことを報告するログ
Web Error Log nginx/apacheでのエラーが記載される
Web Access Log Layer 7のログ、nginx/apacheが出力する、AWS WAFも全てのアクセスを記録するログを出力します
Application Log WebApplicationの動作を記録する
Flow Log Layer4までのログ、AWSのFlowLogはNetFlow v5に相当します

Detect Logや、Error Logが発生した場合に、それらの原因を調査し、対処を行うのは、誰でも行なっていると思います。 Detect LogでWAFであるIPから一定以上の頻度で繰り返される攻撃を検知したら、IP reputationを検討するでしょうし、IPSで誤検知が判明したらsignatureを修正するといった具合です。

でも、間違いが起きる前にproactiveに対処するためには、通常運用時のログである、Access Log、Application Log、Flow Logを解析して、間違いが起きる予兆を掴み、対処を自動的に実施しなくてはなりません。

しかし、通常運用時のログは膨大です。 ログを解析するためのシステムを構築して運用していくのは、かなりのコストが必要です。下手をすると、お客様向けサービスを構築する費用の半額以上をかける事態に陥りかねません。

こうした、ログを集積し、相関分析を行い、予兆を検知したら、自動的に対処を行う仕組みは、SIEM*9と呼ばれています。 オンプレミスでシステムを構築している場合、SIEMの導入は、もう一つ別の高価な箱を買ってくることを意味したのですが、AWS上では箱を持ってくるのは無理そうです。

SIEMを自前で構築するとなると、AWSが提供するGuardDutyのようなサービスや、DeepSecurityのように3rd partyが提供するサービスのログを集めるところか始めなければなりません。

AWS Security Hub + DeepSecurity

で、今回何が嬉しいかというと、まずは、AWSがログを集積する箱を用意してくれた!、という点です。 AWSが提供するサービスのうち、GuardDuty、Inspector、Macieについては、Security Hubを有効化するだけで、集積してくれます。

さらに、3rd partyのログを受け付けるAPI = Findingsも用意されました。 DeepSecurityは、Findingsにeventを投げるための実装もTrendMicroが用意してくれたみたいです。

ということで、早速使ってみました。

AWS Security Hubの有効化

詳しくは、以下のサイトに記載されていますが、 Security Hubを有効化し、CISベンチマークを有効化しておきます。

dev.classmethod.jp

DeepSecurityのsubscribe

[Settings]->[Providers]で、TrendMicro DeepSecurityを[Subscribe]しておきます。

実行ロールの作成

  1. AWS マネジメントコンソール にサインインし、IAM コンソールを開きます。
  2. [Create Role]をクリックして、ロールの作成を開始します。
  3. [Select Role Type] で、[AWS Service Roles] を選択して [AWS Lambda] を選択します。
  4. [Attach Policy] で、AWSLambdaBasicExecutionRole という名前のポリシーを選択します。
  5. Tagは今回は利用しません。
  6. [Role Name]は、今回はlambda-ds-agent-security-hubとしました。

後で用いるので、以下の形式の[Role Arn]をメモしておきます。 arn:aws:iam::XXXXXXXXXXXX:role/lambda-ds-agent-security-hub

SecurityHubBatchImportポリシーの作成

lambdaからSecurityHubへFindingsをBatchImportするためのポリシーをAWS CLIを用いて作成します。 以下の内容で、security-hub-batch-import-policy.json を作成しておきます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "securityhub:BatchImportFindings",
            "Resource": "*"
        }
    ]
}

以下を実行して、ポリシーを作成します。

aws iam create-policy --policy-name SecurityHubBatchImport \
    --policy-document file://security-hub-batch-import-policy.json

実行ロールへのSecurityHubBatchImportポリシーの追加

以下を実行して、実行ロールにポリシーを追加しておきます。

aws iam attach-role-policy --role-name lambda-ds-agent-security-hub \
    --policy-arn arn:aws:iam::XXXXXXXXXXXX:policy/SecurityHubBatchImportOnly

Lambdaの作成

修正済みのソースコードを、lambda-function.pyとして作成しておきます。

本家の実装は、以下の点の修正が必要でした。

  1. HostAssetValueが、AntiMalwareのeventの場合は存在せず、IPSのeventの場合は数字の配列でやってくる状態だったので、ひとまずコメントアウトしています。
  2. DeepSecurityからのeventを受け取るSNSを管理しているAWS accountと、SecurityHubを管理しているAWS accountが、別の場合にも対応できるように組まれているのですが、そのままだと動作しません。 コメントアウトせずに、assume role時の例外を拾って、処理をそのまま継続しています。cross accountで処理する場合にも対応しているつもりです。
  3. 他にも、例外を捕捉していない箇所がほとんどだったので、debugしやすいように例外を捕捉してerrorの内容を出力するようにしています。

github.com

ソースコードをzip fileにまとめておきます。

zip -r ds-agent-security-hub.zip lambda_function.py

以下を実行して、Lambda関数を作成します。

aws lambda create-function --function-name DeepSecurity2SecurityHub \
--zip-file fileb://ds-agent-security-hub.zip \
--role arn:aws:iam::XXXXXXXXXXXX:role/lambda-ds-agent-security-hub \
--handler lambda_function.lambda_handler --runtime python3.6

Lambda関数の一覧から、作成したDeepSecurity2SecurityHubのDesignerを参照すると、以下のような状態となっているはずです。

f:id:eiji-sugiura:20181214222642p:plain
Lambdaが作成された

Triggerの設定

予め、DeepSecurityからSNSにeventを飛ばすように設定しておきます。
まだ、設定を行なっていない場合は、DeepSecurityのSNS設定マニュアルを参考にDeepSecurity用のIAMユーザを作成し、ACCESS KEY、SECRETを設定し、SNS topicを作成しておきます。

今回は、deepsecurity-eventという名前でSNS topicを作成しました。

そして、SNS topicからeventをLambda関数に通知するためのsubscriptionを作成します。 DeepSecurityからSNSへのeventの全体的な手順は、こちらが参考になると思います。

DeepSecurity2SecurityHubのDesignerに戻り、Triggerを追加します。 左側に並んでいるTrigger一覧から[SNS]を選択し、SNS topicには、deepsecurity-eventを指定します。

f:id:eiji-sugiura:20181214222652p:plain
LambdaにTriggerが追加された

この時点でTriggerを有効化すると、以下のようなエラーがCloudWatchLogsに記録されます。

securityhub: Unknown service: 'securityhub'. Valid service names are: ....<アクセス可能なサービスが羅列される...>

これは、Lambdaが利用しているboto3が古く、securityhubに対応していないために発生するエラーです。 ということで、最新のboto3を利用するためにLayerを利用します。

Lambda Layerの追加

詳しくは、こちらを参考にしていただくとして、

qiita.com

手元で以下を実行し、layerにuploadするためのboto3のzipファイルを作成します。

$ mkdir python
$ pip install -t ./python boto3
$ zip -r boto3-1.9.62.zip python

執筆時点のboto3のversionは、1.9.62でした。

Lambdaコンソールで

  1. [Layer]を選択し、[Create Layer]で新しいLayerの作成を行います。
  2. [Name] python-boto3、 [Description] 1.9.62、 [Compatible Runtime]には、python2.7 python3.6 python3.7を指定しておきます。
    f:id:eiji-sugiura:20181214222038p:plain
    Lambda Layerの作成
  3. 先ほど作成したboto3-1.9.62.zipをuploadし、[Create]を実行します。
    f:id:eiji-sugiura:20181214221623p:plain
    lambda Layerが作成された

DeepSecurity2SecurityHubのDesignerに戻り、[Layer]を選択し、[Add a layer]を実行して、python-boto3を追加します。

f:id:eiji-sugiura:20181214221235p:plain
Lambda layerが追加された!

動作確認

DeepSecurityのAntiMalware機能でReal-Time scanを有効にしていれば、EICAR文字列をテキストファイルに書き込むだけで、eventを発生させることができるので、これで動作試験を行えます。

DeepSecurityが動作しているEC2 instanceにloginし、ds-agentが動作していて、かつ、Real-Time scanが有効になっていることを確認しておきます。

$ sudo /opt/ds_agent/dsa_query -c GetComponentInfo
...
Component.AM.scan.Realtime: 1
...

以下のようにEICARを用いて、動作確認を行えます。 EICAR文字列には、"EICAR test file"で検索すると出てくる文字列をいれて下さい。

$ echo 'EICAR文字列' > test.txt

Real-Time scanが正常に動作していれば、test.txtは作成されません。 syslog出力を有効にしていれば、以下のようなログが確認できます。

Dec 14 00:16:03 ip-10-XX-YY-ZZ CEF: 0|Trend Micro|Deep Security Agent|1X.0.0.XXXX|4000000|Eicar_test_1|6|cn1=...... cn1Label=Host ID dvc=10.XX.YY.ZZ TrendMicroDsTenant=...... TrendMicroDsTenantId=..... cn2=144 cn2Label=Quarantine File Size filePath=/tmp/test.txt msg=Realtime TrendMicroDsMalwareTarget=N/A TrendMicroDsMalwareTargetType=N/A TrendMicroDsFileSHA1=CF8BD9DFDDFF007F75ADF4C2BE48005CEA317C62 act=Quarantine

もちろん、DeepSecurityのWebU/Iでもeventは確認できます。

f:id:eiji-sugiura:20181214220910p:plain
DeepSecurityでのevent表示

そして、EICARを検知したeventは、AWS Security Hubでも確認できます。

f:id:eiji-sugiura:20181214222703p:plain
Security HubにDeepSecurityのeventが表示された!

まとめ

多層防御を適用すると膨大なログが発生しますが、それを運用で回していく仕組みに使えそうなものをAWSが用意してくれたので、使ってみました。

AWS Security Hub + DeepSecurity の使い方だけであれば、以下ですでに解説されていますが、背景も含めて理解できるようにしたつもりです。

dev.classmethod.jp

Future Work

AWS Security Hub Findingsで、一覧性は確保できそうですが、まだ、統合されていないものもあります。AWS WAFのeventも集約したいなぁ。

今回は、EC2 instance構成での話でしたが、AWS + Kubernetes構成にも応用できますが、まだ足りない部分が多々あります。それについては別の機会に。

新たに開発するサービスに構想、設計段階からセキュリティを織り込んでいくのは、人であるエンジニアの仕事です。 また、すでに稼働しているサービスに合わせてWAFやIPSのsignatureやparameterを調整したり、取捨選択するのも、エンジニアの仕事です。 セキュリティエンジニアという職業がなくなって、エンジニア皆がセキュリティを身につけた世界が理想です。

freeeでは、一緒に働く仲間を募集しています。

jobs.freee.co.jp

CSIRTのエンジニアとして、隣で働いてもらえる人も募集中です。

www.wantedly.com

さて、明日12/16(日)は、freeeが誇るQAの達人コヤマンさんです。

*1:Unified Threat Management system: ルータにFirewall、IPS、AntiMalware、AntiSPAMなどのセキュリティを担保する機能を詰め込んだもの、アプライアンスとして提供されることが多い

*2:Managed Security Service Provider : network securityのdesign、deploy、management、incident responseを丸投げできる便利なサービス

*3:Software as a Service

*4:Advanced Persistent Threat:直訳すると、より進化し継続して行われる攻撃

*5:Intrusion Prevention System : trafficに対してsignature matchを行い不正な通信を検知する

*6:Web Application Firewall : www serverへのHTTP requestのfilteringを行う

*7:Address Space Layout Randomization

*8:ファイル改ざん検知

*9:Security Information and Event Management