お腹.ヘッタ。

関数型とかセキュリティとか勉強したい。進捗つらぽよ

SecHack365を修了しました。

SecHack365を修了しました。

今年度はSecHack365という通年hackathonに参加してきました。 去年の5月初旬ごろに参加決定の連絡が入り、先日3/24に成果発表会&修了式だったので、1年を通してどんな活動をしてきたかを振り返りたいと思います。
きっと来年度以降参加する人になればいいなぁというのと自分に対しての戒めてきなのもある。ちょっと後半辛めです。すいません。

SecHackとは

SecHack365 は高度な技術力を持つセキュリティ研究者や開発者を育成することで、我が国のセキュリティ技術力、産業競争力を高めることを目的としています。

年間プログラムの中ではhackathon、遠隔研究・開発実習、コンテスト演習、座学講座、全国の一流研究者・技術者等との交流、先端企業の見学等のイベントを通じて、各参加者の志望に沿った能力開発を行います。

訂正4/9 すいません.自分が委員の方から聞いた言葉の解釈間違いのようでした。完全に確認不足です.:bow: あくまでセキュリティに関連していることを目指さなくてはいけないようです ですがセキュリティというのは多岐にわたるので基本的にはやりたいことがやれるはずです!

もう少し具体的に話させていただくと.... セキュリティキャンプのような座学・実習形式ではなく、あくまで開発がメインになります。

参加者の多くは最終的にバイナリ解析や悪性web対策と言ったセキュリティ関連の物を開発していましたが、全員が思いっきりセキュリティというとそうでもなく、割と自由に作りたいものを作れるのびのびした環境です。

よくあるハッカソンと何が違うのかというと、

  1. 1年間を通して開発できる
  2. 実装や発表に関して困ったことがあればプロに相談できる。
  3. NICT保有するデータを活用できる
  4. ほんのり成果が求められる

と言った感じだと思います。 3に関しては別に使わなくても良いですし、4はメンター制度があるので相談すればそれなりに身の丈になったものを一緒に考えてくれるはずです。

今年度の参加者と応募について

全国から358件の応募があり、NICTの審査によって47名(うち未成年者17名)の若手が選抜された。
https://media.dglab.com/2018/01/05-sechack365-01/ より

結構な倍率ですねぇ。小学生から社会人まで参加していて、20〜22歳あたりの参加者が一番多かったと存じます。

実はなのですが唯一僕は参加者の中で学部一年相当で同じ学年の人が居なかったのでそれが残念でした。正直お陰で自分の実力値が他の人と図る機会がなかったり交流で同輩がいなかったりが寂しかったなぁと思いました。残念すぎるし、そのくせ私のことをみんな修士一年の間違えとか呼び始めるのまちがってるのでは?

ちなみに女性比率は今回は割りと一般的な情報系イベント並かなぁと感じました。

たぶんなんですが、割と技術ではあまり人を見てない気がします。自分はあまりできる側ではなかったでまぁラッキーぐらいのお気持ちでした。

ちなみにですが学生は参加費無料です。オフラインハッカソンでの宿泊費、交通費全て支給していただけます。やったぜ!

応募前の自分ときっかけ

応募前はまぁ色々多趣味でコードを書いていてセキュリティはそんな強くないけど適当に用語ぐらいはわかるけど、エクスプロイトかけるかと言われると困りますねぇみたいな感じ。むしろこの時のマイブームはコンパイラでした。

実は締め切りギリギリの12時間前とかに見つけて適当に出したって感じです。申し訳ないのですがホントそんな感じ。

選考課題については口外してはいけないことになっているので詳しくは言えませんが、深夜テンションだろうが強い気持ちを書いていけば自ずと受かるような気がします。

何をやっていたのか

私はチームでIoTデバイス管理システムの開発をしていて、それのプロダクトオーナー的なこと。つまりリーダーぽいことをしていました。 技術的な文脈で言うと最終的にはアーキテクチャの提案と設計、パケットキャプチャと配信、FWなど基盤部分の担当をメインでしていました。 https://github.com/Team-IoTSystem/Vortoj

1年間のイベントについて

ホント一年何も書かないでいたので書いていこうと思います。 これはもしかしたら呼んでるあなたを不快にする可能性があるので、もしものときはブラウザバックしてどうぞ。てかブラウザバックって今の人知ってるのかなぁ。

5月<東京・NICT見学会、説明会>

受かってしまったあとはマジか~って全国から来る人達にビビりまくりながら小金井にGo.

印象にあるのがHarekazeにいる@ak1t0くんにあれ?@takemioIOさんですか?って聞かれてコレオフ会になってるやんけってなったのは良い記憶。あとは@felme_neinさんとひたすら自然言語処理関連の技術の話をしていた記憶がある。

というかまわりが割りと知り合い同士らしいなか地方民はマジで浮くのであれちょっとつらかったですが強い気持ちで行きましょう。

6月<東京・蒲田>

富士通のなんかあれなところでスタート。

二回目になると流石に慣れてきて、@りねあくんとラーメンを食べてふつーに仲良く遅刻してきた記憶がある。すいません手遅れてます。いや手遅れたラーメンはうまい。 f:id:taketarou2:20180408064046j:plain

ここまでは強い気持ちでリージョン推論を用いた僕が考えた最強のコンパイラ書いてやるぞとか思っていたんですが色んな人の話を聞く中であーって思うようになって、その中の一つの選択肢として組み込みもいいかなぁということでIoTやネットワークも選択肢になった。

そんなこんなで一人ブレインストーミングをしながらマッピングをしていてぼっち検討をココでもしていたような気がします。(てか班の人がみんな居なくなるんだもん)

というわけでなんだかんだでチームの外形が決まってきました。

8月<福岡回>

前半はLINE FUKUOKAにお邪魔させていただいて、愛甲さんに講演していただいたり、各自考えて来たアイディアを発表したり、「縁日」と称したトレーナーの方によるハンズオンが開催されたりと盛りだくさんでした。後半は海が綺麗なホテルでハッカソンを行いました。これが最高のハッカソンですよ f:id:taketarou2:20180408064120j:plain が、弊チームは人はいるけど進み具合も担当もバラバラで結局可視化の自分が福岡に入る前にフィジビリ実装したものしか発表ができなかったという話があります。マジでつらい。 しかしこれがケツに火がついたのかチームや開発テーマも固まって来て、ここからが本番といった感じです。

10月<北海道回>

チーム開発は遠隔で行いながらなのですがやはり突然の音信不通の多発などがいっぱいでしんどかったです。そんな中メンターさんと5時間ミーティング&討論するとか相当な追い込まれがありました。(コレ2,3回ぐらいあった)突然の進捗どうですかがあってツラい。

f:id:taketarou2:20180408064211j:plain これは周りが迷走してる図です

大体の感想としては飯がうまい。って回でした.

内情をちょっとくわしく話すと

チーム開発は炎上してるし、みんなやはり突然の音信不通の多発などがいっぱいで、工数見積をしてくれといったのにみんなしないしてかガチガチに開発手法入れなくても良いんじゃないとかメンターが言ったせいで崩れた要因の一つだと思ってるのでそこはモニョッてる、僕の手には負えないので辛すぎるんでメンターさんにPMしてほしい言ったけど「そこは自分たちでやるべきだよ(意訳)」って言われるしほんとにつれぇってお気持ちです。 (申し訳ないのですが承知しましたが影響力がある方が開発内容に良かれと思ってだろうと口出すならば一緒に手も動かしてほしいみたいなことを議論していたりしました。)

この頃はパケット配信のAPIを作ってRest部分を用意して発表に組み込みました。

ちなみにその他として石狩サーバーも見てきました! f:id:taketarou2:20180408064247j:plain

12月<大阪回>

やはりチーム開発は炎上してる(進捗的に) この頃私はRest以外にもストリーミングAPIを用意して置くということ、@abas_onの位置推定を組み込むということをしてました。

ここでは最終発表に向けて私は音頭を取りながら2月までのワークフローを立てていった。全体のチームの人達が動くことを書き出せたのでまぁ良かった。

北海道以降では@ancoさんがinstallerを作りながらブリッジ設定など諸々を頑張っていた。ありがてぇ。。。

2月<沖縄回>

f:id:taketarou2:20180408064400j:plain やはりチーム開発は炎上してる(進捗的にも、人的にも)

自分はFWのフィジビリ実装を行い、ancoさんが実機検証をやってみたいなことを基盤サイドでやっていたことまで落とし込んだ。他の人はちょっと覚えてないが

内輪の成果発表会だったのですが発表前夜、とても背の高いトレーナーの方に手厳しいアドバイスを頂き、夜遅くまで(AM1:00すぎ)発表練習とスライドの修正を繰り返していました。うまく伝わったか不安でしたが、あとからトレーナーからの評価を聞き、言いたい事は伝わっていたのでまぁよかったなぁーってなりました。

アメリカにいった

takeio.hatenablog.com

こちらを参照してください。

3月<最終発表>

やはりチーム開発は炎上してる(進捗的にも、人的にも) 多くは語りませんが、せめて早めにできないときは連絡をしましょう。とても他の人が無駄な消耗をします。結局できないとか普通に信じらんないし(10月頃にデータ形式の相談をしたのに結局ほしいパターンではないとか言うのは流石に駄目ですよ!)優しいから怒らないだけです。

で、中身としては対外向けの成果発表会でした。デモをするにあたり、チームメンバーがそれぞれ作成したものを結合させる作業が必要でしたが、発表直前になってAPIを叩いてアプリが組み込むことが結局できなかったり、ラズパイが処理落ち頻発したりして大変でした。当日もネットワーク関係でトラブルがあり、あまりうまくいかずに厳しいなぁとなりました。

本番不具合が起こった際でもイメージを見せられるようにように準備はしていたというかそれを覚悟していていたので対応はできたのが救いでした。 f:id:taketarou2:20180408064441j:plain

まとめとお気持ち

結構楽しませてもらったなぁと思います。なんだかんだ言いましたがココまでこれたのはチームとメンターと委員の方々のおかげだと思っております。本当に感謝です。いろんなことを学ばせていただいたなぁと思います。

ですが、僕は後悔があってチームの人の持っている知識バックエンドを活かせませんでした。バックエンドに合わせた構成に無理矢理でも落とすべきなのかとかは未だに苦悩です。今回は本人のやりたい希望に合わせて議論上でこうしましょうとなった(なお僕は希望通りではない)のですが、しかし結局それが幸せなのかというとわからないし、そもそもチームの人のレベル差、得意不得意、予定の把握にもっと良いソリューションがあったのでは?とか思う。そもそも無駄な忖度をしたせいでやりたいことが出来ないとかがあったしチームでやるなら誰かが情に流されずに僕も含めて使えないor動けないコマはアサインさせたところからガンガン変えていったり、なんならMVPを活かすためならばそのやろうとしてることごと切り捨てる必要があるなぁと思いました。

正直言ってイマ何言っても仕方ないのでアレですが、メンターの方とうまくマッチングしてないと感じたら新しいメンターの方新たに相談するべきだし、人数が多すぎるときは誰かがリーダーとしてPO or PMになりきる必要があるけどそれはちゃんと責任分界を決めてやらないとリーダーがコードを書いたりすることは出来ないし、権限の移譲を心がけてうまくやらないと行けない。ある種の気づきが多くあったと思います。 そういう意味では後半は最適化されてきたせいでオンサイト開催をうまくスプリントとして自然に使うことが出来たなぁと思います。

割と悔いが残る形で終わりましたが、逆に悔いなく出来た部分もあります。それもまぁ充実なのかなと思うことしました。初年度なので手探りなので結構辛かったですね。 ですが来年度はこの辛さがフィードバックされまくるはずなので、コース制になったのでそんなことなく楽しめるはずです。

ぜひ皆さんも最高の体験をしに応募しましょう!

SXSWに行ってきた話

SecHack海外について

事の発端は1月末。沖縄回に向けて準備したりとか忙しい時期の話です。SecHack365で海外派遣参加者募集の案内がアナウンスされました。 海外派遣先はテキサス・オースティン。そこでは世界最大級の技術と音楽と芸術のイベントSXSWに参加できるとの事で思い切って応募、2月にはSlack上で派遣メンバーになったことが伝えられました。今回はその参加したSXSWのレポートです。

僕にとってはどれも初めてで濃い期間だったので無駄なことも盛り込んでる気がしますがタイムラインで書いていきます。

これは一生忘れないだろうなっていう日々をありがとうございました。~帰りの飛行機にて~

ざっくりとアジェンダ

  • sechack海外視察について
  • timeline

sechack海外視察について

sechackトレーニーの中から希望者を募って応募するという方式でした。大体2.x倍とかなんとだったらしい。 これについては口外して良い悪いを言われてないので私が応募用紙に書いた動機の原文ママを載せます

私は3つの理由からサウス・バイ・サウスウエストに行くことを希望します。
1つ目の理由はカンファレンスで自分の知見を広げることです。
コーディングはもちろんですがサウス・バイ・サウスウエストではプログラミング技術の側面だけではなく使うというところについて主観が置かれているように感じました。”技術と人の未来を俯瞰して理解する”そんなことばがぴったりだと感じました。
特に私が注目してるはDesignのトラックで、「Scaling Design Systems: Pixels to People」などが気になっています。Designのトラックのすごいところは、Designの持つ意味が、日本では一般的に描くことやUI的な部分が多いように感じます。ですがここでは意味どおりの設計という意味として表現していて様々な意味で表現してくれると期待ができます。そしてこれは自分の今回携わっているIoTの管理システムにもつながってくるのではと強く確信しております。システム設計(Design)、UI/UXとしてのDesignなど自分の大きな学びとなり、挑戦しているoutputに大きな影響を与えれると考えています。

2つ目の理由はhackathonです。
このhackathonは
“Questions our hackers can/will address within or across each category”
つまりhackathonでは行いたいことを持ち込んで挑戦することができる。私はぜひこの機会をうまく使い議論をしたいのです。IoTセキュリティにおいてどんな技術が必要なのかという点は見えつつあるが、IoTセキュリティの見せ方という点はこれから発展していくのではないかと思う。どうやって従来のネットワークの可視化を住み分けるのか。どんなニーズが有るのか。そういうoutputができるんじゃないかと思っています。
 
3つ目は世界一のBBQを食べたい!!ってことです。
何を言ってるんだお前はと思うかもしれませんが、いやいや。これはアメリカに渡航する重要なバイタリティになるはずです!
オースティンにはどうやらFranklin BarbecueというめっちゃうまそうなBBQがあるみたいで、日本人レポートをみたところ3時間でも並んでも食べたいとかなんとか。ぜひ食べに行きましょう!

以上より英語力無いのを棚に上げて、私はサウス・バイ・サウスウエストに行くことを強く希望します。

ちなみにですが今回、希望理由のこれのとおりに出来たのかというとそんなことはなくて。 しかし、この応募用紙に書いたコアの理由である「知見を広げる」「世界の人と議論をする」「世界一のBBQ」これらは結果として全く違う形で達成されました。 以下に書くタイムラインから感じ取ってもらえたら幸いです。

timeline

3/8

インターンで東京に下宿してるので夜に実家のある仙台へと一度発行したクレジットカードや服などを取りに戻った。とても忙しい。。。

3/9

仙台から戻ってきて成田EXで成田に前乗りした。いわゆるsechack的に言えばここまでがday0ってやつだとおもう。 ちょっと疲れていて脳死していたので即決で成田エクスプレスに乗りました(自腹) f:id:taketarou2:20180408015114j:plain かなり見晴らし位がいいホテルであったが、大変残念だったがあいにくの天気。晴れていれば飛行機が見えてワクワクが止まらないっていうのだったんじゃないかなぁ少し残念に思う。 f:id:taketarou2:20180408015156j:plain その日は期待と不安とちょっとの嬉しさを感じながら就寝した。

3/10・11

成田空港に8:50に集合だった。心配の一つだった集合時間チャレンジを成功させて無事手遅れなかった。なお@りねあが遅刻して案内人の佐藤さんに笑われていた。

チェックインを行っているときにもう一人の案内人とcodeblueの佳奈さんと顔合わせ。以前みんなSecHackを通してお会いしたことがあるはずだが改めてみんなでご挨拶をした。

飛行機出発までの間各自見て回ることにした。僕は初めての海外ということでなんとなく佳奈さんについていって必要なものなどを見聞きしながらブラブラしていたり、カフェで自分の技術バックエンドの話や佳奈さんが技術バックエンドの話をしていた。ちなみにその時、佳奈さんから呼び名が決定して「たけちゃん」になってしまった()

飛行機ではコードを書いて眺めながら、slackで委員の人たちが時々流す有益情報を確認して、映画を見て、sxswのサイトを見て、美味しい機内食を食べて、更には隣の日本人とアメリカ人と話すといった具合でなかなかに初めての国際線を楽しめたと思う。 f:id:taketarou2:20180408015341j:plain

しかしながら機内の回線が良いと思っていたらかなり激遅いので、最終成果発表会に向けてのコードの修正のタスクが降ってきたけど全くやることができなかった。機内の回線の投げてうまく通ったかを見極めるライフハックとしてwiresharkを立ち上げて、tcpがうまくいったときに緑色が流れてくるの見て作業をすると言った感じだった。完全に何もできん。

隣のアメリカ人のおばあちゃんは長野で合掌造り集落を見てきたと言っていた。この旅初めての英会話だったがほんと文面とは違うことを早速痛感したて何もわからんって気持ちになりました。

それにしても事務局の浅生さんがすごく行きたそうにしていて来年は行けたら良いですねと思った。

さて。アメリカ・シカゴに着いた。入国審査の行列がすごくてトランジットに遅れそうになったのがとても印象的だった。並んでいたところ前には高校生たちがホームステイをしに行くらしく、どうやら前述した隣の日本人が引率の先生らしく第一声「また会いましたね!」。

どうやら海外だと日本人同士だと仲間意識が少し生まれるような気がした。入国審査自体はタジタジだったがなんとかクリア。何を持ち込んだ?っていわれて米っていったら俺は酢飯を食いたいと言われて少し面白かった。

そんなこんなでトランジットは無事成功。シカゴからAuteinへの飛行機に飛び乗り、テキサスぽい何かを見て、タクシーのおばちゃんが話してるのを聞きながらホテルへのチェックインをした。なかなかホテルは広くてこんなのところに止まってええんか???ってなるところでした。

f:id:taketarou2:20180408015428j:plain

そこからすぐに折り返してチケットを発行するためにSXSWの会場へ移動。そこでは今回のアテンドしてくれるWIREDの中村さんたちと顔合わせをして、チケットを発行しました。なおすっごく訛がひどくてageが聞こえなくて佳奈さんに答えてもらうみたいな恥ずかしいことがあった()

そこからは屋台でご飯を食べた。そこではハンバーグを食べたのだが初めてのロブスターでしたがなかなかに最高だった。ほんと最の高です。

f:id:taketarou2:20180408022020j:plain

つぎにsonyブースで色んな体験をした。例えばインタラクティブなホッケーとかVRでサッカーとか。参加者がみんな楽しそうで素敵だなぁ感じ、これがSXSWかと思った....(語彙力)

さて。そんなこんなで夜ご飯に行くことになった。

交流を深めるということでeyes japanの人たちとBBQを食べに行った。ここでの食事はまさにアメリカン。日本の三倍の大きさぐらいですべてがいきなりデカい。僕らが普段日本で食べてた「いきなりステーキ」は実は「計画的ステーキ」なのではと言うように思うぐらいだった。

f:id:taketarou2:20180408022133j:plainf:id:taketarou2:20180408022142j:plain

eyes japanの人たちにhackathonについて優勝だよな?ってめっちゃ煽られたので僕らも危機感が徐々に出始めて下調べなどをした。(が、即寝たので議論などはまだ出来てなかった。。。悲しい)

こうしてとても異常に濃い一日が終わった。

ちなみにですが後日私と@さわだはお腹を下して辛かった(食べ過ぎ?)

3/12

この日はSXSWを見て回ることをした。どうやら早朝からイーロン・マスクの公園を見れるチケットが配られるということで@さわだと並んでいた。どうやら公演は12:00かららしくその間はまたウロウロタイムになってしまった。

私は待ち時間の間programmingのphysical fights backというのを聞いてきた。IoTデバイスがどういう風に振る舞っていくべきかなどの議論が複数の講演者たちがしていたもので、面白かったのがどういうアーキテクチャであるべきかを考えたほうが良いということに対して技術側の話を持ち出すタイプとユーザーストーリーを持ち出すタイプと社会的インパクトを持ち出すタイプ。みんなバックエンドが違う人がいるんだなぁと感じた瞬間だった。

f:id:taketarou2:20180408022257j:plain

ちなみにだが結構日本人が多くて、隣りにいた博報堂のお兄さんと仲良くなってFB交換をした。

イーロン・マスクの公演についてはイーロンが来た質問に対して返答をしていくというもの。これはなかなか破天荒ぶりがよくわかった回だったと思う。たとえば「Q.やることの優先度付は何か」「A.うーんとりあえず全部」みたいな。うーん。なんか強いなぁ....

その後は仲良くなった博報堂の人たちとエキシビションの展示を見に行った。

エキシビションでは多くの企業が参加していて例えばwolfuramやfacebookといった世界の名だたる企業が展示を行っていた。企業だけではなくペンシルバニア大学のラボや日本からは東大生たちのチームなど学生もちらほら。

結構日本企業がゴロゴロいてYAMAHAとかPARCOとか。個人的にはYAMAHAの出していてものとかは特に興味深くて「協調演奏」というAIが人間と連弾しているという技術について展示していた。自動演奏などはよく聞くがAIが人間と連弾するなんてすごい技術だと感じた。ただ使ってる技術としてはNNにカルマンフィルタとからしいので枯れた技術といえば枯れた技術らしいがそれでもすごい。

海外ので面白かったものとしては技術の面ではあまり印象はないのだがベンチャーがロケットを作るって話があってそれの展示、3Dプリンターでチョコレートを印刷などちょっと日本では見ない粒度のものが多くて感動した。

f:id:taketarou2:20180408022426j:plainf:id:taketarou2:20180408022430j:plain

この日も夕飯はBBQ。WIRED REAL WORLD TOURのメンバーの方とご一緒させて頂いた。 f:id:taketarou2:20180408022534j:plain まぁここでも「hackathonは優勝するしかないですよねぇ。」とみんなに煽りを受けながら交流をしていました。なかでも印象的なのが電通の廣田さんにどうやったらプレゼンで勝てるのかというアツい話をしていただいたことです。分量が多いので詳しくは書きませんが。

廣田さんの斜め向かいで話を聞いていたのですが眼の前の@さわだはプレッシャーで胃が痛いとか言ってるし、他に座った@りねあと@たきはhackathonなんて半分忘却して楽しんでるし、僕は話せば話すほど煽られ続けるしとてもつらいって感じでした。(ほんと廣田さん煽っていただいてありがとうございます)

というわけでホテルに急いで帰ってhackathonの戦略をこねこねするはずだったが!寝ました(みんな)

3/13

この日はSXSWからはすこしはなれて、朝からSparkCognition™というベンチャー企業見学に行きました。 f:id:taketarou2:20180408033240j:plain 社名どおり人工知能システムを活用した「認知」に力を入れている会社でAIの産業応用をしている会社です。 セキュリティも含めて様々なプロダクトの紹介があったのですが中でもシグネチャフリーの機械学習によるマルウェア検索エンジンDEEPARMORというモノが面白いなぁと思いました。 訓練データの更新もかなり頻繁にしているようで、アルゴリズムも興味深いなぁとは思っていたのですが残念ながら社外秘。ひとつ気になったこととしては他社製品と比較しててこっちが優れてると言っていたがそれに関する検証環境を示していないのが残念に思えました。。。

僕ら学生には,AIを学ぼうと考えているなら熱意をもって取り組む事.他者との違いを大切にして何かしらの専門分野を確保しておく事とのお言葉を頂いた。どれにも共通するような気もしながらも往々にしてAIは応用分野になりがちなので主戦場がどこにしなくてはいけないのかと言うのが難しいのかもしれません。

その後,再び会場へ戻りご飯を食べました(めっちゃチーズがすごい) f:id:taketarou2:20180408033422j:plain

またその後はhackthonのmeetupということをしてきました。 ここではhackathonでのアイディア交換やチーム募集をする場でした。全く英語話せないので「ぐぬぬ。。。」ってなっていたら周りに煽られて、しょうがなく話しかけに行きました。 格好としては右手にはグーグル翻訳、左手には図で伝えるための紙とペン。とてもひどい格好ですね。。。。。で気合で自分のアイディアを伝えて追加でアイディアをもらうみたいなことを繰り返してました。ほんと抽象な言葉は咄嗟になかなか出てこないですね。 (それにしても結構アメリカ人グーグル翻訳で話しながらでも待っててくれる。。。優しい。。。)

アイディアは恥ずかしいので言いませんが、面白いこととしてあっちの方でビールの種類として「sapporo」というのがあるらしい。いや残念ながら未成年なので酒詳しくないんですけどね。(俺コレが好きなんだよ的なことを相手の人はめっちゃ言ってた)

大体アイディア交換も終わり、この大会のスポンサーたちがどういう意図を狙ってるのかなぁとかがわかってきた頃終わり。とても疲れた。

その後は自由時間でエキシビションで回れなかったところを見に行きました。ちなみにですが何か発表を見てきたはずなのですが完全に疲れてメモって聞きながら寝てました(マジで何も覚えてない) f:id:taketarou2:20180408033626j:plain f:id:taketarou2:20180408033637j:plain さて、ホテルに戻ったあとは作戦会議。とりあえず各自の課題として案を一個考えるを宿題にして再び寝てしまった。(気力体力0)

3/14・15

楽しいhackathonの始まり

さて今日がhackathonの当日。チームはsechackの参加者四人で結局行うことになった。スタートは午後からなので午前中は作戦会議。

僭越ながら僕がファシリテーターをしながら自分たちの宿題にしていた案をもとにブラッシュアップ。ユーザーストーリーマッピングをして案におけるユーザーペルソナを彫り込みながら、「案の批判」と「案のサポート」、「案の提案者」という役を作ってアイディアの煮詰めていくという作業をした。役という概念については電通の廣田さんの話をヒントに行ったものでした。割りとこの流れでやったところ短時間で引っかかりがなくブレストの良さみたいなものが出てきたので出だし的には良かった。

アイディアの雛形としては「言葉にできない瞬間を音楽で表現」というテーマをつけて「動画に音楽をつけてシェア&リコメンド」というSNSチックなものを打ち出した。

ココまでで午前はタイムアップで午後は僕らはhackathonに向かった。 f:id:taketarou2:20180408033732j:plain f:id:taketarou2:20180408033912j:plain hackathonのスタートもなかなかすごくてBeatboxをオープニングにAmazonのCTOが壇上で話したり,CloudnayというCDNの会社のエバンジェリストが登壇したり。FacebookからはFacebookAPIの開発者やVRReactの開発者が登壇したり。すごい人々が壇上で話していて国際hackathonというだけはあるなぁと思いました。

僕としてはfacebookの人に御社のflowtypedを使ってるんですっていったら同僚が作ってるのに携わってるんだよ!って話が帰ってきて嬉しかったです。

会場の様子はアメリカ人らしく歯ブラシや歯磨き粉がただで配っていたり。飲み物(全部ジュース)だったりとか結構充実した感じでした。 f:id:taketarou2:20180408033840j:plain

そんなこんなでhackathonはスタートしました。僕ら四人のお仕事の割り振りとしては

  • @私:フロントエンド
  • @たき:サブでフロントエンド、同時並行でAPIの下調べ
  • @りねあ: サーバーバックエンド
  • @さわだ:発表資料作成・発表

といった感じでした。(ドコが担当できるか的な消去法で決まった)

使うライブラリやAPIAWS, React, Cloudnaryの3つでした。

初手としては

  • 僕がwebpackの設定やeslint,flowtypedなどを詰め込みながら@りねあとAPIエンドポイントの設計相談
  • @たきがAPIの下調べ
  • @さわだが資料作成と発表シナリオの作成

というのが15:00ぐらいから始まって行きました。

大体18:30ぐらいまで会場で行っていて(晩飯が出て来る時間まで待ってた)

この辺ですでに消耗しはじめたオタクが悪態をついてるのがわかりますね。僕言ってないですよ...?(悪い顔)

残りはホテルで作業。 コレは知見なのですが久しぶりにReactを触ったらwebpackのバージョンは上がってるわ,使うライブラリはバージョンミスって死んでるとかで少しリハビリしてからhackathonに行けばよかったなぁと思いました。まる。

消耗するオタクたち

死屍累々という感じになりながら翌日の5時を迎えたのですが以下に示すのは消耗するオタクたちです。

画像で見てみるとこんな感じです。 f:id:taketarou2:20180408041353j:plain f:id:taketarou2:20180408041404j:plain ちなみにですがこの状態ではまだAPIの結合をしていません。さぁどうなってしまうんでしょう.....

弊チームバグを踏み抜きまくる

朝8:00ごろ,会場へ向かいました。 そこでついにAPIの結合作業をしてたのですがここで問題が発覚します。

API叩けねぇ!!!」

なんでかというとlambdaで自前のAPIを用意していたときCROSがEnableにならないという話で、色々やっていたのですが自分たちでは手に負えずその場に来ていたAWSの開発者に投げます。で、なんと僕らは「AWSのバグ」を踏み抜いたのです。...とてもツラい。結局解決としてはヘッターにallowを手書きという人力感ある方法でした()

しかし同時並行で「Cloudinaryの方もバグ」を踏み抜いていてどうやら想定ではサーバーからAPIを投げる想定だったようだが僕らは面倒なのでフロントエンドから投げたところ動かないということになりました。。。いやあくまで想定なので動かないはずはないのですが。。。。 困り果てたのでCloudinary社のエバンジェリストに相談したのですがずーっとトラブルシューティングしていたけども何もわからんと言ったの流石に草も生えない。

発表フェイズ

と、そんなこんなでモノは完全に作りきれぬまま時間切れでした。事前に運営に状態を見せに行くのですが「出さないほうが良いのでは?(意訳)」と言われて完全にチームの雰囲気はお通夜でした。

@さわだにいたっては質問のときにじゃあ竹くん答えようかとか丸投げしたので完全にクソ最悪でした。全くコード書いてないんだからやってくれよ!!!頼む!!!

そんなこんなで@さわだが発表をして質問に関しては結局英語が一番できる@りねあがcodeblueの佳奈さんの助けを借りながらAmazonのCTOからの質問に答えていました。ありがとうりねあ....ありがとう手遅れ(様々な理由からこの旅ではりねあのあだ名が手遅れになった)

結果

で、思いの外ですが、結果としては「最もクリエイティブであった」という言葉とともにCloudinary Prizeという企業賞を頂きました!これはどうやら日本人初出場で初受賞らしい。

自分たちが世界でも十分に通用したということがとてもモチベになりました。本当チームと支えてくれた方々に感謝ですね。ありがとう。

このあとは自分はテキサス大学を少し見学してきました。大学生協とかで本とか売ってないかなぁとか思っていったけど全く理工書とかありませんでした。。。 ちょっと面白いのがあっちにも学生に向けてPCを売りつけるアレがあって笑いましたw

f:id:taketarou2:20180408040239j:plain

その後はこのままヘトヘトになりながらもお祝いディナーをしてきました。一応オースティンで10番以内に入るお店らしい。ランクとしてはカップルが記念日に来るような感じのところ。

もうこの日はぐっすり寝ました。

4/16

今日は最終日。VR関連の展示やセッションを見て,この日から始まったGame Expoをぐるぐる見てきました。 ゲームなどが盛んでeSportsなどゲーマーが山ほどいて子供の数が多いなぁと感じました。治安がいいですね

その後は地元のインキュベーションセンターへ行きました。良い印象だなぁと思ったのが人のためになるものを選んでいると明言しているところがとても好感度upって感じでした。 f:id:taketarou2:20180408040126j:plain しかしながらまぁ何を基準で選んでいるのか全くわからず。りねあが聞いときは「勘」みたいなことを言われてるし謎。ですが日本からでもオースティンでやるなら受け入れると言うのは胸熱ですねそれってなりました。

というわけであんなことやこんなことをしてこの日はまたBBQで締めました。ちなみにココが一番うまかった(BBQ3回目) f:id:taketarou2:20180408040631j:plain f:id:taketarou2:20180408040643j:plain

4/17

余り言うことはありませんが、朝六時の起床はまじでツラい。カバンに荷物は入らねぇしホント次行く人は前々からものの整理はちょくちょくしておいたほうが良いと思います。

と、そんなこんなで色々略しますが帰国。

まとめ

楽しかった!!!!が、英語ができないつらい。。。。

古来から「成田決議」という英語を絶対やろうなという伝統芸能が日本にはあるわけですが例外にもれず自分もやりました。はい。

なかなか日本は味わえないエキサイティングなことが出来たかなぁと思います。同時並行でインターンもしていたので帰ってきて次の日は出社したら出社時間に寝てました(怒られがあった) まぁですが、知見を広げる」「世界の人と議論をする」「世界一のBBQ」これは違った形でしたが達成できました(ほんまか?)

ぜひ皆さんも行きましょう!

2018にやりたいこと

「2017年にやりたいこと」 - お腹.ヘッタ。

恒例のアレです。

反省点

  • 勉学面はぶっちゃけダメでした。具体的は英語がなんだかんだ言い訳してやってしまったのがダメだったと思います。厳しい....
  • 生活面も自力目覚ましできませんでした....サボった1限目は数知らず....
  • 趣味、ダーツはしばらくお休みしました。ダメかどうかはさておきこの時間を情報科学に割くことが出来たのは良い話
  • 情報技術・情報科学について。去年はセキュリティをやりたいと書いてますけどぶっちゃけ全然出来ないです。お前何なら出来たんだよって話ですがブラインドSQLiとかは見ながらなら書けてるので許してください()あといまだにDPは全然書けないです...orz
  • 計算論理は全然出来てないですが、代わりに意味論と型システムが出来てて良かった。もうちょい頑張れ私。
  • イベントについては思ったようにいかなかったけどもくもく会とかひらけてある程度サーベイになったので良かったと思います。

総評としては50点。ぶっちゃけ甘めにつけたけど目標にしてたこと達成できたかというと怪し過ぎる。目標外でアジャイルとかgitとか意味論勉強してたし10点色をつけた。大学なら赤点。

来年やりたいこと

  • 英語 どうやったら英語できるようになるのか。それは英語を読むしかないんだよなぁ。。。。英語の時間毎日取るようにするぞ!!!
  • コンパイラを作る。関数型ってロマンだよね。僕はコンピュテーション式が好きです。そこにロマンはあるかしらではなくてあるんだよ
  • 関数型を用いて一個プロダクトを立てる。あくまで趣味から出れてないからね。
  • 意味論を勉強する。出来ればもう少し検証論の知識をつけたい。俺がCoqだ。
  • バイナリを読む。去年できてないheep問できるようになろうなーという感じ
  • CFPを出す。出したいところは定まってるんですけど通ったら嬉しいぐらいの話。
  • 編入する。絶対だからな。

締め

今年も至らない点あると思いますがご指導ご鞭撻を賜りますようよろしくお願い申し上げます。

Git Objectの話

これは Harekaze Advent Calendar 2017 23日目の記事です。

git objectを皆さんはご存知ですか。そもそもとしてgitをご存知であるか問題があるわけですが、まぁ親の顔よりgitのdiffをみた人もいるんと思うので知ってることにして話を進めます。

で、git objectって何よって話をすると皆さんがgit initをしてホゲホゲすると生まれる.git/objectsを指しており、gitのコアの部分のデータストアのことを指します。

さて、このオブジェクトは大きく分けて三つの構成がされています。

  • blob
    • ファイルデータを表現する
  • tree
    • フォルダ構造を表現する
  • commit
    • treeへの参照、コミットしたユーザーやタイムスタンプなどのスナップショットの表現

それをラップしているのが僕らが普段扱うコマンドたち。

そのコマンドも大きく分けると二つで、

  • 磁器コマンド(Porcelain command)
    • 僕らが普段使うようなbranchとかユーザーフレンドリーなコマンドたち
  • 配管コマンド(plumbing command)
    • 普段のgitフロー開発では普通全く使う必要がないgit objectを直接触るようなhash-objectなどのコマンド

後者の方はあまり聞きませんが、今回はこれも用いて行なっていきます。

何が何だかわからんって人もいるかもしれませんが、git使ったことあるならばなんとなく分かるんじゃないかなと思うのでつらつらと書いて行きます。

ではサックっと見ていきましょう

.git/objects

gitのデータは前述の通り、gitオブジェクトという形で.git/objectsの中に格納される。 実際にコピってやってみよう。(以下よ#〜は結果)

git init
echo "hello" > piyo.txt
git add piyo.txt
git commit -m "init commit"

find .git/objects -type f
#.git/objects/73/0c1bf1546ce745073e50572b64d951427b868c
#.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
#.git/objects/2e/1206f177f168e9654bd0f803c3b79100308516

中身を見てみると.git/objectsフォルダの中にファイルが3つできているのがわかると思う。 この不規則に見えるgit objectの名前は40文字のhashがつけられていて、先頭の2文字がサブフォルダ名、残りの38文字をファイル名として1つのオブジェクトにつき一つのファイルに保存される。ちなみにこのobjectの名前はsha1で生成される。

さて、これではそれぞれどんなオブジェクトなのかわからない。そこでgit cat-fileというコマンドを用いる

git cat-file -t 2e12
#tree
git cat-file -t 730c
#commit
git cat-file -t ce01
#blob

よって以上のobjectはtree,commit,blobと言うことがわかった

blob object

-pオプションでオブジェクトの中身を表示ができる。

git cat-file -p ce01
#hello
cat piyo.txt
#hello

blob objectはファイルデータのスナップショットで、ファイル名などのメタ情報は含まれてない。

tree object

git cat-file -p 2e12
#100644 blob ce013625030ba8dba906f756967f9e9ca394464a    piyo.txt
ls 
# piyo.txt

tree objectはfile構造を指していて、file属性やblob objectへの参照、filenameを記録している。 なお、サブフォルダの場合はtree objectへの参照になる。

commit object

git cat-file -p 730c
#tree 2e1206f177f168e9654bd0f803c3b79100308516
#author take <****@gmail.com> 1513838255 +0900
#committer take <****@gmail.com> 1513838255 +0900

#init commit

//流石にメールはぼかしましたw

commit objectには、トップレベルのtreeへの参照、commitしたユーザー情報、タイムスタンプ、commitメッセージが含まれる。

ちなみに最初のcommitなので親commitがないが、2回目以降のコミットでは親commitへの参照も含まれる。 ほんまか?って思うかもしれないので試しに見てみる。

ではまずは新しいファイルで新たにオブジェクトが生成されるか確認する。

echo "world" > fuga.txt
git add fuga.txt
git commit -m "second commit"
ls
#fuga.txt piyo.txt

find .git/objects -type f
#.git/objects/da/22367adec08f45e1f4c368361f7582159c9012
#.git/objects/b4/7b491cb488426c0ea4c0b04bc0ac9609fb6cc0
#.git/objects/73/0c1bf1546ce745073e50572b64d951427b868c
#.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
#.git/objects/83/c7a922210527a3543ce0cfa9f1f63d9dce921b
#.git/objects/2e/1206f177f168e9654bd0f803c3b79100308516

確かに、以下のobjectが増えていることがわかる。

.git/objects/da/22367adec08f45e1f4c368361f7582159c9012
.git/objects/b4/7b491cb488426c0ea4c0b04bc0ac9609fb6cc0
.git/objects/83/c7a922210527a3543ce0cfa9f1f63d9dce921b

ではcommit objectをgit cat-fileをする。

git cat-file -p 83c7
#tree da22367adec08f45e1f4c368361f7582159c9012
#parent 730c1bf1546ce745073e50572b64d951427b868c
#author take <hayatake396@gmail.com> 1513954425 +0900
#committer take <hayatake396@gmail.com> 1513954425 +0900

#second commit

この場合、確かにparentと言う親commitが出来ていることがわかる。

折角なので、他に増えたobjectたちも確認してみよう。

git cat-file -p da22
#100644 blob b47b491cb488426c0ea4c0b04bc0ac9609fb6cc0    fuga.txt
#100644 blob ce013625030ba8dba906f756967f9e9ca394464a    piyo.txt

treeなのでファイル自体がやはり増えている。

git cat-file -p b47b
#world

blobなのでファイルの中身が確かに出てきている。素晴らしい。とりあえずgitobjectが頑張ってることはわかった。

ここで思うだが、git objectを配管コマンドから直接いじって見たい気持ちになったりするわけである。

と言うわけでこれってもしかして全くファイル作らずにgit commitができるのではと言うことが容易に思えるので検証していく

配管コマンドを用いたファイルを一度も作らずに行うcommit

初めはまずはgit initをして確かに初めにはないもないことを確認する。

mkdir fugafuga
cd fugafuga
git init
#Initialized empty Git repository in /Users/Home/Desktop/fugafuga/.git/
find .git/objects
#.git/objects/
#.git/objects/pack
#.git/objects/info

さて、使うコマンドはgit hash-objectと言う物を使う。これはobjectIDを計算してファイルからblobを作成するコマンドである。 オプションがいくつか設定する必要があって、今回使うのは-w,--stdinと言う実際にobjectデータベースに書き込むオプションと標準入力からobjectを読み込むと言うものを指定する。 ちなみに-wをつけないとただ単にIDを吐くだけになる。blobは出来ない。

echo 'create data' | git hash-object -w --stdin
#070f3bd01632c945394b3aac7187a9d91ca4816a
ls
#(何もない)
git cat-file -p 070f
#create data

これで確かにblob objectだけができた。

次にこれを格納するtree objectを作る。

さて、下準備をする必要がある。 まず、使うコマンドはgit update-indexと言うコマンドを使う。これはworking treeのファイル内容をindexに登録するコマンドである。

これにもオプションをつける必要があり、Stageingしてるファイルに対してこれは実行されるので(と言うかファイルがないのでStageingする場所もない)--addオプションをつけて追加すること必要ある。

また、このindexに追加するものはファイルではなくてobjectデータベースにあるので--cacheinfoオプションをつけて指定された情報をindexに直接挿入してやることになります。このオプションは引数を3つ取ることになって--cacheinfo <mode> <object> <path>と記述する必要がある。

ちなみにだがこのmodeとはchmodなどと同じパーミッションの数値の値を指しています。今回の100644chmod 644と同じですので通常の一般的な権限のファイルであることを意味します。逆に実行可能ファイルとかならば100755になります。

git update-index --add --cacheinfo 100644 8b137891791fe96927ad78e64b0aad7bded08bdc test.txt

さて、これ無事indexにぶち込んだのでStageingエリアをtree objectに書き出すことができるようなった。 これをどう書き出すかと言うとgit write-treeコマンドで行う。これはまだtreeがないときに自動でindexからtree objectを作る。

git write-tree
#c47b19c8b7a3b7724138f73e4cd53efa0f1e9595
git cat-file -p c47b
#100644 blob 070f3bd01632c945394b3aac7187a9d91ca4816a    test.txt

これによって作ることができた。

さて、次はcommit objectです。ここまでやれば簡単で、

echo 'first commit' | git commit-tree c47b
#5cb61261e3c4d2d15d09583c107577564cc6335e
git cat-file -p 5cb6
#tree c47b19c8b7a3b7724138f73e4cd53efa0f1e9595
#author take <*****@gmail.com> 1514031034 +0900
#committer take <****@gmail.com> 1514031034 +0900

#first commit

確かにcommitが出来ました。やったぜ!

終わりに

私は今回NICT主催のSecHack365というのに参加しているんですが、計画性のなさが露呈して、開催期間中に記事を書く羽目になりました。ツライ....

次は@Knom10さんです。お楽しみに!

参考

AVTokyo2017に行った話

AVTokyoとは

http://ja.avtokyo.org/ ウェブサイトには 「AVTOKYOは、コンピューターセキュリティに関する発表と、気軽に情報交換をする、コンピューターセキュリティのカンファレンスイベントです。ひとときの楽しい時間をドリンクとHACKで過ごしてみませんか?」 と書いているがまんまその通りのイベントです。

元々は「ブラックハットジャパン」参加者のミニプレゼンを含むパーティーが原型だったそうです.

参加した動機

元々はずーっと行きたいなぁと高校の頃から思ってたイベントの一つでした.

今回あわよくばcodeblue学生スタッフで余裕があったら行きたいなぁとか思ってたわけですが残念なことにどうやら僕は落ちたようでした....残念!まぁ実力不足ってことでしょうね: (

というわけで勢いでAVTokyoのearlyチケットを取ってしまいました.....苦学生には....ここからが本番でした

参加するのになるべく金かけないように行きました

どういうことかというとチケット取ったはいいが、じゃあどうやっていこうかなぁという話が出てきたりお金の出所が頭を回す必要があります.

ちなみにですが10月回のsechack365では今回のスピーカーの神園さんとお話ししてる際には「いやー行きたいんですけどお金がないんです(涙目)」みたいなことを話してた記憶があります そのせいで当日お会いした時は「よくこれたね!!!」ってビックリマークが3つぐらいついてましたw

まぁ結論から言えば、安定の夜行バスを使うわけなのですがコツがあります.

やはり、いわゆる早割を使うわけなのですが、 自分の使ったのはさくら交通のバスでした. 、 これは実は眺めてるとわかるのですがサイトによって記述値段が異なることや、時間によって当然謎の安い値段帯のものが降りてくることがあります. また行く日にちをずらすなどで今回は運よくそれを拾い往復7000円ほどで行きました.

ちなみにもコツがあって、どうやって自分の体力を確保するかがあります(もしかしたら最重要) これも2つ方法があって、

  • なるべく背後を取ってリクライニングシートを使えるようにする
  • 空いてるバスを狙うということがあります.

自分は無事条件を満たすバスに乗りました.

さてかなりリサーチした結果なのであまり語ると長くなるのでここら辺でやめておきます.なお友達の家に泊まらせてもらったのでホテルなんてものはありません:(

参加当日

勢いで決めたせいで当初ぼっち参加だったわけなんですが、同じSecHack参加者の三須さんと一緒に行くことになり会場前で待ち合わせしてました. 三須さんありがとうほんと大好き(大泣)

実際参加してみると雰囲気としては結構地味に圧倒されますが....しかし入ってみると外人の方もいらしたり和気藹々と楽しそうな印象を受けました.

というかなのですが明らかにどう見ても知ってる人多くて実際セキュリティにどっぷり使ってる人はオフ会にしかならないのではwと思いました。

面白かった公演について

あんまりCall for Xの出し物にハマってたせいで聞けなかったんですが(神園さんの聞きたかった....)個人的には2つ。

  • pancake氏のradare2
  • 木村 廉氏のMore efficient remote debugging with Thin Hypervisor

がとても良かったです. 特に前者のradare2の作者は界隈では有名な方で、なかなか英語なので辛いってなりながら耳をかっぽじってました.割と既知の知識ばかりでしたが後から聞こえた話によるとandroidでも動かせたりとかなかなか強い人だなぁと思ってました. ちなみなんですが参加後リポジトリを眺めていたらhttps://github.com/radare/r2jp なんと日本コミュニティができていてびっくりしました・・・しかも公式だし. 後者のるくすさんこと木村氏のはbitvisorを用いていてかなり先進的なことをしているように感じました.これまた面白いのがGSoCにおいて木村さんはradare2についてコミットしていたので界隈が近いなぁと強く思いました.

参加したイベント

  • SMD Soldering Practice
  • Open xINT CTF

この2つに一緒に来た三須さんと参加しました.

前者のSMD Soldering Practiceはツラい半田付け体験でした.

具体的には表面実装用の細かい抵抗やコンデンサ、ICなどを取り付けていきます.自分は残念なことに手を焼肉してしまってツラいさんでした. 自分はラッキーなことに半田付け初心者ではなかったので無事完成させました: )

後者のOpen xINT CTF http://xintctf.wpblog.jp/ はOSINTと言われる要はスパイぽいCTFです(ざっくり) 結果として3問解いて12位でした. f:id:taketarou2:20171116121603p:plain 一問目はwhoisするだけだったのですが....(なぜかここで自分たちのコマンドから通らずこける) ちょっと時間をかけてしまいましたw その後出て来た管理者のメアドからSNSを漁り、見つけていくってことを行いました.ですが3つ目終わった地点で時間切れ.悲しい.さんまでGOってなんだよ... ちょっと雰囲気をつかめばワンチャンありそうだったので来年もやりたいと強く思いました.

雑多な話

  • 英語できなすぎてジェスチャーで乗り越える
  • うっかりするとジンジャエール頼んだのにジントニックが出てくる
  • カールおじさんこと、NICTのカナハマさんにお会いしたのでカールを得た f:id:taketarou2:20171116120859j:plain
  • AVTokyo参加記書くのでTシャツくださいとカナハマさんに言ったらもらった
  • CFP来年は出そうなって煽られる
  • Sechackの関係者余裕で10人ぐらいいた
  • ツイッターでAVTokyoにいく旨を話したら何人かフォロワーさんをお会いすることができた
  • hiro1357(@eserver_dip_jp)と会うために待ち合わせしてたら同じ場所に別のひろさん(@kazu1130_h)に話しかけてしまい初対面で挨拶替わりにtwitterフォローするという謎事件
  • CodebBlueの人たちがまんまマイグレーションしただけという事実が行けなかった俺に刺さった
  • @__ukun さんがCTF強くてプロだったけどメッチャうるさかった
  • NICTの石川さんが明日は合コンだ!って目が輝いてた
  • アフター行きたいのでやはりCFP出すだけ出すしかない

まとめ

これ書くの12月でもいいかなぁと思ったら f:id:taketarou2:20171116120911p:plain という指定暴力団sechack事務局お世話になった人たちに煽られたので急いで書きました.

ともあれいろんな方々がいろんなところからやって来て幅広いバックエンドをお持ちなので話してて飽きないです!

ぜひセキュリティに興味ある人はみんな楽しめると思うので行きましょう!

ThinkPad USB keyboardをMacOS Sierraで使う

ThinkPad USB keyboardをMacOS Sierraで使いたい!

macThinkPad USB keyboardを使いたいが、MacOS Sierraで使うと残念なことにKeyRemap4MacBookでバインドが使えないんですね….探すのにだるかったので載せときます。あとこのキーボード非常に優秀なのでみんな使ってください。 というわけで備忘録です。

キーバインドをする。

これは基本的にググれば出てくるので割愛。ポイントとしては今のところSierra以降はKarabiner-Elementsでのみキーボードのバインド周りを変更できる。ただし以前のようにマウスに仕事させれない。 GitHub - tekezo/Karabiner-Elements: The next generation Karabiner for macOS Sierra

マウスのミドルボタンを押しながらスクロールしたい。

ディフォルトではミドルボタンスクロールができないんですけど、USBOverdriveでマウス周りを変更できます。 http://www.usboverdrive.com/USBOverdrive/News.html

トラックポインターの速度を上げる

mousezoom Ben Net - MouseZoom OS X Official Site

これらでできるはず。

僕が運用中に困ったこと

このキーボード実は換装可能で、jis->uk->jisってことができたりするんです。 自分はこのキーボード、ボロボロの中古で買って、修理して使ってます。

そこで引っかかったことを書いておきます。決して上の使い勝手の話ではないです。

キーボードがukになってしまう。

どういうことかというとjisで使ってるのにukとして振舞ってしまう。ってことがありました。 いろいろ調べていくとまぁいろいろありますが、僕の場合前に今のキーボードをukで使っていて、そのあと換装してjisにしました。つまりキーボードの設定がukのままになってるって考えるのが妥当ですよね。 なのでライブラリの中にあるcom.apple keyboardを削除してrebootしました。

そうすると使えました。はい。特殊ケースですね。。。

終わりに

ThinkPad USB keyboardクソ最高なんだけど環境に合わせるのがめんどいっていう人がいそうなのでまとめました。 ThinkPad USB keyboardは汚れたり壊れたりしたら自分で中身だけ買って換装が可能です。フレームが割れない限り永遠に使えるので某馬の鎧で表現してるキーボードよりもよっぽど永遠にプログラマを支えうる道具だと思います。 また、PC切り替え機とかと併用すると最高に作業がはかどります。自分はこれでノーパソきりかえて使ってます。

ざっと30分クオリティですけど誰かの役に立てば幸いです。備忘録でした。

リーン開発の現場を読んだノート

リーン開発の現場

という本のノートを描いて見た。この本は実例を交えながら紹介している本である。

当ノートは自分なりに本の中身を元にまとめて見ている。 個人的に後から考えてもいいのではみたいな章は省いたり、簡約したり纏めたりしてる。他にも自分で知っていることを含めて見たりもしているので必ずしもこれが正解とかは言えない可能性もあるのを忘れずに。

さて、そもそもアジャイルとかリーンとは何じゃ、ということをざっくり説明します。

アジャイルの概要

ソフトウェアコミュニティの17人のオピニオンリーダーたちが2001年にユタ州のスキーリゾートに集まってソフトウェア開発を成功させる方法について議論しお互いの考えを擦り合わせていくうちにアジャイルソフトウェア開発という言葉が誕生しました。そしてソフトウェア開発を成功させる方法に関する共通のビジョンを見つけて文章化したもので、いわゆるアジャイルマニフェストと呼ばれる文章になったもの。 内容を以下に示す。

私達は、ソフトウェア開発の実践、あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。この活動を通して、私たちは以下の価値に至った。

  • プロセスやツールよりも個人と対話を。

  • 包括的なドキュメントよりも個人と対話を。

  • 契約交渉よりも顧客との協調を。

  • 計画に従うことよりも変化への対応を。

価値とする。すなわち、左記の事柄に価値があることを認めながらも私たちは右記のことに価値を置く。

  • 顧客満足を最優先し、価値のあるソフトウェアを速く継続的に提供する
  • 要求の変更はたとえ開発の後期であっても歓迎する。変化を味方に身に付けることでお客の競争力を引き上げる。
  • 動くソフトウェアを2〜3週から2〜3ヶ月という短い時間の間隔でリリースします。
  • ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働かなくてはいけません。
  • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事終わるまで彼らを信頼します。
  • 情報を伝える最も効率的な方法はフェイストゥフェイスで話すことです。
  • 動くソフトウェアこそが最も進捗の重要な尺度である。
  • アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなくてはなりません。
  • 技術的卓越性と優れた設計に対する普段の注意が機敏さを高めます。 シンプルさが本質です。(言い換えると無駄なく作れる量を最大限にすること。)
  • 最良のアーキテクチャ・要求・設計は、事故組織的なチームより生み出されます。
  • チームがもっと効率を高めるかどうかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイルという言葉自体は2001年に誕生したが、ほとんどのアジャイルの方法論は1980年代にはすでに作られていた。アジャイルはこれらを包括的に指す言葉で、様々な共通点があればアジャイルとも言えなくもない。 つまり全てアジャイルとも言える。 逆に言えばではあるが、これらの共通点原則を持つものをアジャイルという多面的な表現を許容することでもあると考えれる。

スクラムの概要

ソフトウェア開発のフレームワークのことである。1990年ごろにできた。 スクラムは経験則に基づいたプロセス制御や複雑適用系理論を元にしている。 以下にコアコンセプトを説明する。

  • 順番付けされたプロダクトバックログ

  • 実現すべき事柄を小さくリリース可能な作業一覧に分割することを指している。

  • プロダクトオーナー(OP)はプロダクトビジョンを定義して、ビジネス価値やリスク、依存関係などのエレメントに基づきプロダクトバックログを作る。

  • 要は全体の仕事の山を分割する。

  • 職能横断型チーム
    • 自己組織化したチームに小さく分割していく。
    • それぞれのチームにはPOとスクラムマスター(SM)が存在している。POはビジネス全体のプライオリティをチームに提供して、スクラムマスターはチームの改善や障害を取り除く作業に力を注ぐ。
  • スプリント
    • 開発期間を短く固定されたイテレーションのことを指す。例えばリリース期間とかのこと。
    • 目標まで走り抜けるのでスプリンターから来てる。
      • しかし。短距離ランナーではなくペース配分をするマラソンランナーの方が現実は正解なのであるのは忘れずに。
  • 継続的にリリース計画を調整する。
    • プロダクトオーナーはリリース計画を最適化し、各スプリント後のフィードバックを顧客と強調しながら優先順位について更新する。
  • 継続的にプロセスを調整する。
    • それぞれのフィードバック後の振り返りによって最適化していく。

大人数で長い期間大きなものを作るのではなく、少人数で短期間で小さいものを作るのがスクラムであるということである。

XPの概要

1990年中盤に生まれたエクストリームプログラミングとは

  • シンプル

  • コミュニケーション

  • フィードバック

  • 勇気

  • 敬意

というジャンプばりの五つの価値を基盤にしたものである。 スクラムと並行して進化して来たためにほとんど同じ要素を持っている。例えばXPにおけるオンサイト顧客はスクラムのプロダクトオーナーとほぼ同一。

じゃあスクラムと何が違うかというと外向的か内向的かである。

スクラムはしばしばXPを取り囲んでると言われる。何故ならば組織構造の課題や外部とのコミュニケーションに着目しているからである。

ではXPはどうかというと、エンジニアリングプラクティスが主幹的だったりする。

  • 継続的インテグレーション
  • 自動ビルド、自動的な統合。そしてチームが開発したコードを自動テストする仕組み。これによって作業の品質が関わる早期のフィードバックをチームはより早く得ることができる

  • ペアプログラミング

  • ペアでプログラミングする。学習や設計品質を最大限引き上げることができる。また欠陥の発生を最小限にできる。
  • ペアのレベル差が大きいと片方のレベルが格段に上がる。

  • テスト駆動開発

  • テストコードを書いてテストを通すためのコードを書く。
  • またリファクタリングをしてコードを洗練させていく。

  • コードの共同所有

  • チームメンバは全員ソースを修正することが許されている。また奨励されている。これにより理解が進み協同的な感覚が生まれる。

  • インクリメンタルな設計の改善

  • 初めはシンプルで実現可能な設計から始める。
  • その後改善してブラッシュアップしていくアプローチ

カンバンの概要

カンバンはアジャイルソフトウェア開発におけるリーン的なアプローチだ。これは日本語から来てて工場にあるカンバンと同じところから来ている。つまるところ物理的な伝達システムのこと。

しかし、勘違いしてはいけないのが2004年にデイビットアンダーソンがソフトウェア開発におけるカンバンとしたのだ。間違っても天井に貼り付けるあのカンバンとは微妙に違う。

カンバンのルールを以下に示す

  • ワークフローを可視化する。
  • 作業を小さく分けてそれぞれをカードに書いて壁に貼り付ける。
  • それぞれのカードがワークフローのどのstatusであるのか可視化するためにそれのラベルのついたものに貼り付ける。

  • WIPを制限する。

  • サイクルタイムを測定し管理する。

  • これを元にプロセスを最適化していく。
  • 例えば人員の転換やさらに仕事の分割など。

リーンの概要

リーンとは「TPS」というトヨタ生産方式を元にしたものである。(というかぶっちゃけ同じで西洋でTPSと呼ばれるだけの話。)このTPSという方式は様々なものに適用可能とされている。その中にはソフトウェア開発も含まれる。

よくある勘違いとしてアジャイルとリーンは共通の価値があるために親戚や同一視されるが起源は異なっている。 リーンは製造業から、アジャイルはソフトウェア開発から誕生した。お互いの原則は相性が良く、適用できる範囲も広い。 最近多いのは製品コンセプトの開発〜デリバリまでというエンドツーエンドの開発の流れ全体でアジャイルとリーンをどう組み合わせて適用していくのかということが探求されている。

このリーン(TPS)の原則を、リーンソフトウェア開発として提唱したのがメアリー・ポッペンディークとトム・ポッペンディークである。

全体を最適化する

システムの一部分の最適化に時間をかけても必ずしもシステム全体の最適化にはならない。

  • ストリーム全体を最適化する。
  • つまりコンセプトからデプロイまでの包括的な部分を指している

  • 完全な製品を提供する。

  • 顧客の一番の目的は問題解決なのでそれを解決できるソフトを作ろう。

無駄をなくす

無駄とは、顧客に価値を付加することのないあらゆるものである。ソフトウェア開発では3つの大きな無駄がある。

  • 間違ったものを作るという無駄。

  • 学び損ねるという無駄。

  • 頻繁な引き継ぎや現場からかけ離れれた意識決定などいわゆる方針のブレのことを指してる。

  • 過度な作業切り替えによる無駄。

品質を作り込む

プロダクトのテスト段階で毎回過度の欠陥が見つかるのであればプロセスに問題があると言える。

  • 最終テストで欠陥を見つけないような仕組みづくり。

  • テスト駆動開発による誤りを防ぐプロセス。信頼を担保し続ける必要がある。

  • 依存関係を断ち切る。

  • 機能追加や変更を可能な構造をすべきで疎結合なものであるシステムアーキテクチャである必要があるべき。

たゆまぬ学び

計画は立てることに意味があり、学びを得ることにその本質がある。この学びというのは実験を重ねることなどを指している。

  • 成果の予測可能性はフィードバックにより高まる。

  • 選択肢を幅広くもつ。

  • 変化への耐性を持たせる。

  • 意思決定を最終責任地点まで遅らせる。

  • 取り返しのつかない所に来る前に(決定とも表現) 可能な限り学習をしてできるだけ実験を重ねる。

速く提供する

ステークホルダー全員についての深い理解と、彼らにとっての価値を何かということを考えるところをから始めるべき。 それによって継続的にビジネス価値を生み出していく流れを作る。

  • 素早いデリバリと更新しつ。低コストでの実現。

  • 待ち行列理論は鯖だけではなく開発にも応用できる。

  • ゆえにプロセスには作業の塊を小さくして少しずつ流す。代わりにサイクルタイムを短くしていく。

  • ワークフロー管理はスケジュール管理よりも簡単にできる。

  • 任意の日にリリースする最善の方法はイテレーションやカンバンシステムを使ってしっかりとイテレート可能なワークフローを確立することにある。

全員を巻き込む

優秀なメンバーは起床資源である。チームメンバーは公平かつ公正に適切に対価を得る人々であり、自律、熟達、目的に応じて意欲を感じるのだ。

  • 自立
  • 効率よく働くチームのメンバーというのは半ば自律しているチームである。チームにはメンバーの精神面を支えるリーダーが存在し、リーダーは完了させるべき作業や意義のある作業について始めから終わりまで責任を持つ。

  • 熟達。

  • 人に敬意を払うことでチームの誰もが素晴らしい人なるための挑戦やフィードバック環境が生まれる。

  • 目的。

  • 仕事と価値を繋ぐものが目的である。仕事の意義を感じることで初めて人々は目的の達成に没頭する。

改善を続ける

結果が重要なのではなく、人と結果を出せるシステムを育てるのが重要なのである。

  • 失敗とは学ぶ機会である。
  • 小さな失敗でえ注意深く調査し、修正すれば最高に信頼できるパフォーマンスを生み出せる。

  • 標準は挑戦や改善のために存在する。

  • 現在の標準になっている物への挑戦や変更を奨励していく。その上で現状最も知られていて誰もがわかる理解を標準化していく。

  • 科学的な方法を使う。

  • 仮説の検証法、早くたくさんの実験を行うやり方、簡潔なドキュメントの作り方。これまでとは違った良いやり方をやる。

つまるところある種の信頼が担保されたものを実行することである。 何言ってるんだって感じなのでつまるところ、

  1. 顧客の目で「価値」を定義。

2.その価値の流れを可視化する。

3.それを「エンドツーエンド」で「細く、速く」流れるようにする。

4.その流れの改善活動を現場で実際に仕事をしてる人が行う。

ということである。以下から実際に当該書籍を元に紐解いていこう。

一章 プロジェクトについて

スウェーデンの国家警察で作ってるPUSTという新しい捜査報告システムを元に紹介する。これを実現するにはある要件を満たす必要があった。

  • 膨大な量のレガシーなシステムと統合

  • 相手に質問しながらリアルタイムでシステムを使うため警察官にとって簡単に使えるシステムである必要がある

  • 堅牢なセキュリティ

  • たくさんの複雑な法律や規則を遵守しなくてはいけない

  • スケジュールが厳しい

タイムライン

スタートは2009年9月から。一年後にはリリース。その後は隔月でリリース。 スケジュールの中で重要なマイルストーン

  • 1.0の最初のバージョン

  • 1.4の警察全体で使えるようなったバージョン

早めにリリースしていくスタイルである。 理由としてはバグや思い込みなど仕様をすり合わせつつ行うことのできる点にある。よって頻繁なリリースをするというのは一度のリリースに抱えるリスクを減らすと言えるだろう。 また、リーンの特徴として開発のプロセスがどんどん変わって、進化し続けることが挙げれる。

スケジュール分割について

大きなプロジェクトでリスクを最小化する鍵は大きな像を分割する方法を見つけ出すことである。こうすることで、小さい機能を徐々に増やしていくことができてシステムを何度もリリースするインクリメンタルリリースを行える。リスク分散の観点からもユーザーにそれぞれ価値を送りフィードバックをされていくというより良くしたいという流れからも良い作業と言える。 今回の場合は地理的な場所犯罪者別という点から最小化にかかった。

  • リリース1.0から1.2
  • 一つの地域のみに対応。
  • 飲酒運転など武器の所持。よくある多い犯罪種のみ対応。
  • 徐々に犯罪種のサポートを増やした

  • リリース1.3:

  • 2つ目の地域に対する拡張リリース
  • これをメインリリースとした

  • リリース1.5

  • 犯罪種別を追加押収品の管理システムなど他のシステムと統合したバージョンをリリース このような形に分割した。

顧客について

これは警察組織のプロジェクトで顧客やユーザも身内であった。がこれは当該プロジェクトではある一人が主役である「顧客」として振る舞った。 エピックにあってるかどうか、詳細なフィードバックをもらうなどを行った。 (エピックは一般的には壮大な作品という意味だが、この文脈では大まかな要求大きなストーリーという意味である。)

二章 チーム編成

ソフトウェア開発プロジェクトにおける難題の一つとしては適切な人数でチーム編成して、不空のチームが強調して動くためにはどうすれば良いのかというのが挙げれる。 メンバーの人数が増えるに従ってコミュニケーション問題やコラボレーションの難しさにぶち当たる。組織が成長する際によく発生する痛みの症状と同じ。 初めの小さい頃は疑問があれば人数が少なく近くにいることが多いのでどのように運営するかなど方針に対する容易に行えた。 これに対して、実際人数が増えたが上手くいけたのはメンバーが一つの場所で働いていたことにあるだろう。また柔軟にチーム編成を進化させた。今では5チームで行っている。

  • 要求分析

  • システムテスト

  • 機能開発が3チーム

  • チームではなく、プロジェクトマネージャや構成管理、パフォーマンステスト、コーチなどがいる。

さて。 三つの開発チームは基本的によくあるスクラムチームで構成されている。職能横断型で、自己組織化していて、昨日全体と開発とテストする能力がある。 要求分析のチームは仮想的なチームでアナリストが所属していて、基本的に他のチームに所属しながらなので仮想的。 これによってプロジェクトメンバー全員が分散して配置されている。 また、この理由としてアナリストと各プロジェクトの人たちがコミュニケーションを取りやすいようになっている。

基本的に要求分析チームは3つの役割をこなすことになる。

  • 何人かのアナリストは機能開発チームの一つに所属し、開発者からの質問に答えて要求を明確にするために、開発からチームの開発をサポートする。

  • 何人かのアナリストはどの機能開発チームにも参加せずシステムの全体像の分析に重点を置いて取り組んでいいる。彼らはシステムの概要となる昨日エリアを定義するために、将来像を見定める。

  • 残りのメンバーは上記の2つのうちどちらかに柔軟に横断して必要な作業を行う。

テストチームも同じように、

  • 何人かのテスターは機能開発チームに属して機能レベつのソフトウェアテストデバッグを手助けする。

  • 何人かのテスターはシステムの全体像に対するテスターで、リリース候補版の概要レベルのシステムテスト結合テストの実施に力を入れている。

  • 残りのメンバーは2つのうちどちらかに柔軟に横断して必要な作業をする。

初めはチームは担当する作業で分けて編成していた。要求分析チーム、テストチーム、機能開発チームをはっきり区別し、テスターやアナリストがいなかった。

しかし、これによってコミュニケーションの問題でスケールが上手くいかなかった。さらには担当するチームで分けてしまうとチーム間のコミュニケーションを文章で行ってしまうことが多くなった。そして問題責任の押し付け合いが始まってしまった。また、それぞれのチームは自分の仕事だけの完了だけをしようと考えがちであった。

例えば、アナリストであれば機能が本番環境にリリースするまでに行われる開発やテストに付き合わなくなったりする。これは要件定義を書き終え、自分の手から離れた時に機能に関する自分の仕事が完了したと考えてしまうからである。 コラボレーションの質は、スクラムのような職業横断型のチームに進化したことで劇的に改善した。

しかし、何でもかんでも一つのチームで行うのではなく、何人かのアナリストやテスターを機能開発チームから引き離してシステム全体を見るようにした。

三章 ミーティングについて。

当該書籍では朝10:15前までに3段階のミーティングを行う。

第一段階:機能開発のスタンドアップミーティング

自分たちが使っているtaskboardに立って今日やることや取り組むべき問題や課題について意見交換をしていく。 場合によっては昨日やったことや昨日やること、困っていることと言った3つのことを話すと言うことをしている。

第二段階:スペシャリティ同期(synchroの方)ミーティング

チームごとの話や各場所で行ったことを初めに決めたグループを超えて話し合う。

第3段階:プロジェクト同期ミーティング

これは組織をバラバラに考えて少数精鋭で行ったりする。これは全体的に長期的なスパンで俯瞰したり、フォーカスを広く持つことをひつようとする。

これらのミーティングの特徴として、ボトムアップからのアプローチであることが挙げられる。 細かいディティールから大きな対局へ見ていく。 その際には人を変え、場所を変え、問題を変えて課題を認識して解決していく。

これによって大きな問題を分割していくことができる。

また、これに関してはある固定した期間を持たせて無制限で行わない。また必要に応じてこれをなんどもイテレートする。 ex,9時ごろミーティングを15分、お昼に15分、帰り前に15分。 場合によっては柔軟に増やしていく。

四章 プロジェクトボード

プロジェクトボードとは、プロジェクトにおいてコミュニケーションの大元になるものとすべきものである。具体的にはプロジェクト全体の状況などを見せる。これは、カンバンシステムであったり、ストーリーマッピングであったり、様々な形が考えられる。

当該書籍におけるプロジェクトのカンバンを例に取ろう。 アイディア->機能->次の作るべき10機能->開発->システムテスト->ユーザー受け入れテスト->本番 となっている。 これらはすべてフローとなっている。

何点か細かいディティール例をあげたいと思う。

  • 機能
  • 大局として考える。
  • ユーザーストーリーと呼ばれるフォーマットで書かれている
  • XとしてYをしたい、何故ならばZだから
  • と言うフォーマット
  • ex:捜査官として住所を検索するときに地域によって絞り込みをしたい。何故ならば住所を早く見つけることができるからだ。

  • 次の10機能

  • これは先ほどのエピックといえる機能を細かく分割する。
  • 具体的に詳しい機能や必要な要求を展開する。
  • ここの中身こそミーティングでブラッシュアップを必要だったりする

  • 開発とシステムテスト

  • 継続的インテグレーションを行っていき、機能レベルのテストが出来ならばシステムテストを行っていく。
  • このときgit上には別バージョンのブランチを作って扱おう。
  • ここで素晴らしい点はここも大きい単位でテストを行うのではなく、小さい細かい単位でテストを行うこと、当該書籍の言葉を使うと継続的システムテストを行っている。

ウォーターフォールとの大きな違いとしては、初めから要求を完全に分析しているかしていないかの違いである。 カンバンシステムでは全てのフェーズを並行して進める。これよってフィードバックによるアイディアを組み込みやすく、フローとして価値を作り続けているのである。

ここでもひとつ忘れるべきではない点について、緊急の課題や、ボトルネックについての処理である。 パターン的にはマーカーをつけていろんな人からフォローをもらわなくてはいけないとわかる。

しかし、これをどのように機能させればいいのか。少人数なら気にすることはないが、大人数ならばどのようにすればいいのか。 それについて次章に入ろう。

五章 カンバンボードをスケールする

一般的にプロジェクトが進むスピード大部分は、メンバーがどれくらい状況を理解しているかによって決まる。 もしも、メンバ全員が何をしていてどこにいるのか、何が起きてるのかを理解していれば同じ方向に進むことは容易であると言えるだろう。 そう。そのためのカンバンボードである。

しかしながら、人数が増えてやることも増えたら付箋だらけだったりカードだらけでとても扱いにくいものになるだろう。 そこでカンバンを分割してあげることをする。例えば開発についてであれば複数チームがいる際に、自分のところに今やるべきメインの課題などは機能開発チームが持っていることをメインのカンバンで示してあげて、議論が深くなるであろうディテールの部分は各開発チームのボードに書き込むなどをすると言ったことができる。

ここでのポイントは階層に分けることである。しかし流れスタックは溢れてしまうものなのでWIPの制御をして行うことなどをしよう。またちゃんと同期しないとあとあと大変なことになるので注意。

六章 プロジェクトゴールの管理

プロジェクトの全体のゴールを理解していると、プロジェクトメンバーはゴールに向かって集中するようになる。 それはそうという話ではあるんですが、実際に行っていくと意見の食い違い等があることがわかる。 なのでゴールへの理解のすり合わせを行う。具体的にはミーティングのプロジェクト同期ミーティングで行ったりするべき。 彼らは初めの方はなかなか難しいという評価をするかもしれない。しかしそれに対してどのようにモチベーションをあげていくのか。また、仕様書は共通認識ではないということを理解して、ストーリーマッピングをするということを行わなくてはいけない。

これらのことは定期的に行うべきである。これによって現状とゴールのチェックを行うというのは、進捗とチームの士気と意識についてを知ることである。

技術課題を捌くとバグを捌く

以下は章に合わせず必要なことを纏めて書き留めていく。

技術課題さばき

技術課題が出てくるのは仕方ない。なのでどれくらいそれにコストがかかっているかを機能の情報と別に用意して作る。要は機能カードと技術課題カードにそれぞれどれくらい労力を必要としてるか見えるようにしよう。

やるべきものにうまく乗っていくために。

例えばリファクタリング。あまりにも技術的負債が大きいと、とてもやりたくないものである。しかし、これを嫌だからと言って看過してしまうとその後技術的負債は増大していく。

この場合は、実際にこの脅威を可視化するといい。 この場合であれば実際にそのクラスファイルを印刷をかけて、どれくらいが理想のコードサイズであるかを示すべきである。 それによって僕らが行わなくてはいけない技術的負債の線引きガン見えてくるだろう。

また、リリースの前のパイロット版にはそれに対するリハーサルをコストとして見ていこう。どこまで用心することに越したことはない。

バグさばき

カンバンを使わないで捌くとテスターがバグを見つけて、開発のサイクルの終わりにバグを見つけては要求分析にプライオリティをつけて、変更管理ミーティングをしてそれに対するコストにシンクロさせていく。

が、しかしこんなのは厳しいのでしっかりとカンバンを使いたおそう。

  • 継続的システムテスト
  • 要は大きいテストをやるのではなく、一つのスプリントごとなど小さいうちに部分のテストを行っていこうというスタイル。
  • これの良い点はバグを探すなど無駄な本質から離れたことで時間を多く取らなくても済む点である。そう考えると結果として最後にまとめてテストする場合と比べると時間に関するコストが明らかに軽減される。

  • さっさとバグをぶっ殺せ。

  • テスターがバグを見つけたらさっさと殺す。いっそその場で殺しにかかるのがベターだろう。
  • 後からバグとかで揉めるより効果的
  • 会って話すというコミュニケーションをするということはバグトラッキングのシステムに状況を記述するよりも対面でのコミュニケーションの方がドキュメントコミュニケーションより多くを知ることができからである。
    • しかし、これについてはただ会って、口頭で話すというだけではなくユーザーストーリーのフォーマットなどある種のフォーマットで簡潔に述べたものを用意してそれに対するディティールとしてテスターが受け持つのが良いと言えるだろう。
    • また、引き受けたことがあるバグに近いタイプのをなんども引き取ってしまうことがあるので、バグに関する統計を取るのおも良いと考えれるだろう。
    • 開発者とテスターがお互いの仕事に関して学び合うのでチームとしての改善点など多くが見えてくると考えれる。
    • 簡単な細かい古いバグが含まれたタスクカードの管理に無駄な時間を使わなくても良い。(難しいのは適宜対応
    • では大きい難しいのはどうするのか。そういうものを優先して積極的にバグとしてバグトラッキングシステムに登録する。細かいものは統計は取るが、追加などはしない。
    • この際、どこまでもサイズが増大する可能性がある。よってバグの登録数にはラインを引く。30個とか適当なサイズを。また、バグのレベルとしてはブロッカー(絶対リリースに支障が出るバグ)かどうかなどを問い合わせて重要度を決めて登録するか決める。

バグを可視化する

何をやるべきでどんだけ今後やるべき仕事があるのか。あまりに多いならプロセス改善が必要だし、余裕があるならば今後のイテレーションに関する学習を行うことができる。

また、くりかえし起きてしまうバグに対してどのようにアプローチしていくか。繰り返し発生するバグのステージから引きずり下ろすために分割統治的なアプローチをかけていくべき。 例えば根本原因を見つけるために因果関係図を描くなどをすべき。 これを用いて本来やるべきモジュールなど、何が問題であるのかなど本質を捉えるのに役立たせる。

例えばこれによって、

  • 不要なモジュールのリファクタリング

  • ドキュメント作成に対してコストを取る。

  • (テスターや作り手同士で)お互いの技能を幅広く活用するためにどこぐらいのレベルでコラボレーションしていくかを示していく。

バグの根本原因が必ずしも技術的課題だけではないということをまずはしっかりと念頭においてほしい。ここで述べてるのは自分の技術に依存しない整理して本質を得るために書いていることを再度認識しよう。

みんなもないだろうか。数学の計算をする際に急ぎすぎて字が汚くてケアレスミスをしてしまって間違ってしまったこと。これにプロジェクト開発は似ている。多くの人がそれによって手戻りで失敗してしまう。

プロダクト(方針や開発を進めること)の中で生まれたバグというのはプロセスのバグから生まれる症状である。じゃあプロセスってどうすればもっとより良くしていけるのかを考えていこう。

継続的プロセス改善とバージョン管理

プロセスをデザインするというのはとても難しい。何故ならばプロセスというのはスケーラビティを求められるプロジェクトに包まれるものである。つまり、プロセスもスケールして変化を求められる。

そこでプロセス改善エンジンを導入していく。要は機械学習と同じで評価関数を決めてそれに対して定常偏差を合わせていくといったイメージである。下に一般化して示す。

  • 明確さ
  • プロジェクトがどのような状況なのか誰にでも伝わるように目立つところに誰もがわかる明確なゴールを示す。
  • 一週間目標などを用意して目標を層にするの有効である

  • コミュニケーション

  • チーム内で定期的にプロセス改善ミーティングを開く

  • 統計データ

  • プロセスを改善できたかどうか。できるだけシンプルな方法で動向を追跡する。
  • 例えば、ベロシティ(開発した機能の数)、サイクルタイム(機能一つあたりのかかった週)の二軸で見るなど

この三つである。これを行なっていくことで自己組織化を目指していく。

さて、これを行うに当たってチームの振り返りなどは必須である。 良くある振り返りの方法として、他者を呼んで、外部的視点を見てもらうことをしてもらうこと。他にも色々方法はある。

さて、それを通じて良くある改善内容としては

  • もっとコードをコミットしよう

  • ミーティング方法を変えていく

  • コーディング規約を更新

  • チーム内に新しい役割を増やす。バージョン管理の主幹の人を作ったり、様々なインフラ的な問題が起きた場合主幹となって動くゴールキーパーを作ったり。

これらの振り返りのキーとして、エスカレーションポイントを用意することである。エスカレーションポイントとはチームを超えて影響を与えたる、一緒に解決したりする。たとえ他のことをしているとしても、お互いにプロセスの改善を行うことで視点が養われてシナジー効果が期待できる。

プロセス改善ワークショップ

振り返りの手引きをざっくり示したい。 これを開く意義は、仕事のベクトルを明確に、そして改善することである 当該書籍ではスクラムオブスクラムで示されているが、ここで話される取り組みというのは他にも適用可能だと考える。 以下に示す。

  • 場を設定する
  • テーマを決めてそれに集中する

  • データ収集

  • 以前に実施したワークショップから行なったことを話し合う

  • アイディアを出す

  • データをもとにそれらにどんな意味があるのかを議論する
  • そして辛いポイントを出して、それを今後どうするのかを具体的に示していく

  • 何をすべきか決定していく

  • 振り返りを終了する

    • 次のワークショップまでに誰が何をすべきかを決めてクロージングする

ワークショップではみんながさっさと話せるように心がけるべきである。今思っていることをサッサといってみようと投げるぐらいの勢いで手早くしていくのがいいだろう。 しかしながら目標を見失っていくのではダメで、期待すべき事柄をしっかりと示していくことが大切。

これは運用次第であるが、リーン主義で居続けるなら漠然としたことを許さない可能性もあるが、クリエイティブな、カンバンといったことであるならばブレインストーミングや直感で決めるというのも大切である。ただしいつかは抽象から具体に変えなくてはいけないのを念頭におくべき。

早すぎても難しい

当該書籍では興味深いことを述べている。 以前は変化が少ないことが問題であった。今回は変化が多すぎることが問題だった。 ほどほどというのが必要だと感じる話だ。

こういう時はプロセス改善提案書を書いて一手間加えるワンクッションを入れてもらうことにしている。 理由は提案者に対して簡単に出しすぎないようにする枷であり、何故こうしたいのかということの再認識をすることができるからである。

  • あなたが改善したい問題は何?

  • この変更で誰が影響を受ける?

  • この変更を実施する上でどのように進めるべきなのか?

  • どれくらいのコストがかかってくるものなのか?

  • これを実現するのにどのように分割できるのか想定させることができる(注意すべきはここまではやらせるべき範囲が違う。ここでは問題を分割するのではない。)

迷ったらシンプルな解決策を選ぼう。

因果関係図

根本原因分析を行うのに有用な方法である。 なんでこれが必要かというと、適当に解決するとまた浮き彫りになlって厳しいことになるからである。 具体例を挙げると * 寝室に煙が充満してる * 窓を開けて、また寝る(ダメな例) * 煙の発生源を見つける。おっと危うく火事になるとこだったぜ(良い例)

といった話である。

A3シンキング

リーンシンキングの中核にある教えの一つとして、継続的なプロセス改善を表す「カイゼン」という言葉がある。 トヨタ曰くこの正しい問題解決手法を厳格に運用にしたからであると表現している。これをA3の用紙に描くのでA3シンキングという。

A3シンキングのサンプルやテンプレートはネットにあるので要参照 テンプレートリンク

因果関係図の使い方

基本的な流れはこう。

  • 問題を選んで書き出す。

  • 明らかな損害やそれの弊害を上向き(トップダウン)に突き止めていく

  • つまりこの書き出した問題が理由として扱えるように描く
  • 問題:リリースした奴がバグって死んでる
  • 突き止め:リリースした奴がバグって死んでるー>客がキレる

  • 根本原因を下向き(ボトムアップ)に見つけていく。

  • テスト不足
  • 描く時間が不足してたなどが上の例には当てはめれる

  • 図に現れた循環(基本的に悪循環)を特定して目立つように描く

  • 図を洗練するために上記をイテレートする。

  • 根本をどう解決するか(ミーティングに持ち込んだりする)

これを行なっていく。 もし今回の場合はテスト自動化のトレーニングとかが足りないとかそういうとこに帰着するであろう。

因果関係図の書き方

ぼっちなら線画ツール好きなの使って頑張ってくれ。

複数人8人以下ならホワイトボードや付箋と模造紙で書いて作ろう。

30人以下とかの大規模なら人数を分けて具体的な問題の一つに着目して纏めたりしておく。最後に持ち寄って纏めたりする

定期的にこれをちゃんと認識できるシステム組み込みが必要だったりするのでそこはアナログツールに頼ったりしていくべき。

よくある失敗

  • 幅優先ではなく、深さ優先探索で見ていこう。

  • 問題領域が広すぎる場合がある。分割可能な問題になのではないのかということを見極めよう。

  • 簡略化しすぎない。専門用語ではなくできるだけ一般化した言葉で話すべきである。

  • 具体例に頼ったり、専門用語に頼るのは説明ではない。一般化してる表現で説明してこそ本当の説明なのだ。

  • いらないのが出てくるけどそこは問題ではなく、根本に辿れるかが問題。あくまでブレインストーミングのような形でも問題はない。

  • 個人攻撃をしないように気をつける。しばしば誰かが足を引っ張ってることがるだろう。しかしそれはチームで解決すべき問題だ。出来ないならばそれを解決するプロセスが工数なだけなのだ。そもそとして問題解決ができるのはそのシステムに要因があると仮定できた時のみなのだ。

なぜ因果関係図を使うのか

  • 共通理解を構築するためある。
  • 他の手法としてはストーリーマッピングが挙げれる

  • 問題がどのようにビジネスに影響を与えるか明確にする。

  • 根本原因を見つける

  • 悪循環のループを見つけ、潰す

なぜやるかを意識して問題解決に当たろう。

終章 まとめ

なんでこんなのを纏めたかというと、学生が情報技術を学ぶというの通じて楽しいというのを続けたいならば、それを業務にうまくたたみこむ必要が有るんだぜということが最近よくわかってきたからというのが大きい。

結局最近思うのは実用技術>>>大局的な開発手法ということがやればやるほど僕らは痛感するだろうと思う。現に本質的ではないgitがわからなくて右往左往してみたりまだまだ辛いものはある。精進したいものである。

間違えがあったらそっと教えてください。

参考文献