昨年は参加できなかったのですが、今年は見事抽選に通ったので参加してきました。

午前中は全体のアーキテクチャやエンジニアの文化の話、午後は2トラックで各技術要素についての詳細というかんじでとてもバランスがよく、かつそれだけのトピックについて自信を持って話せる人がいるというのは素晴しいなと感じました。

途中でどうしても抜けないといけない用事があったので、聞いたセッションだけざっくりと感想を。

LINE Platform Development Chronicle

サーバサイドのアーキテクチャがどう変わってきたかという話で、LINEの成長に合わせて、適切な技術を新旧問わず選択してきているという印象を受けました。

ゲートウェイサーバの実装をnginxの拡張モジュールからErlangに変更することでダウンタイム無しでコードのアップデートを実現した話や、SPDYの採用、サービス間の連携にThriftやprotbufを利用している点など、今のLINEを支えている技術基盤がなぜそうなっているのかというところが納得できて面白かったです。

HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ

とにかくスケールがでかくてすごい。

数十ペタバイトのデータを管理するために、HBaseとRedisを組み合わせたストレージを設計し、それを抽象化するStorage APIを提供しているとのこと。

直近ではそんな規模のデータを扱う機会はないんですが、一つのオプションとして知っていると非常に役立ちそうな話で勉強になりました。

そんな規模のHBaseのバージョンアップを検討しているとのことで、応援すると共に来年、再来年にその話が聞けるのを楽しみにしています。

４年に渡る LINE Android アプリの進化とチャレンジ

星の数ほどあるAndroid端末ですが、できるだけ多くの端末で快適にLINEが使えるように、ハードウェアの情報を取得してそれにあわせてエフェクトや機能のオンオフを切り替えていたり、GCMが使えない端末のために通知プラットフォームを自作した話など、メッセージングサービスだからこそ重要なポイントをしっかり解決できているのはすごいなと思いました。

また、エラーを集約するためのプラットフォーム、めっちゃくちゃ便利そうなので参考にしたいです。

座談会 & 懇親会

ご挨拶したかった人と軽くお話できたし、懇親会は同じテーブルの人といろいろ話せましたし、ちょっとだけLINEのインフラについて聞けたのでとても有意義でした。(食事もたっぷりで満足でした!)

おわりに

来年もあったら是非いきたいな、と思う素晴しいカンファレンスでした。LINEの皆さんありがとうございました。

(当日の様子や、なぜこのようなイベントが開催されたのかはCTOのエントリ 第1回ペパボテックカンファレンスを開催しました #pbtech - delirious thoughts をご覧ください。)

ペパボテックカンファレンスという企画が立ち上がったとき、最近ずっとスピリチュアルなことばっかりやってるし、テッキーなことはまだ発表できるほど成果だせてないし、という思いがあって登壇を保留していました。(普段外に出ない人に発表してほしいというコンセプトもあり)

ただ、社内でも「見積りと計画づくり」について何度か説明しており、参考文献にあげたような書籍を全部読まなくても概要を理解できるような資料の必要性を感じていたので、自分の考えていることを技術という切り口で言語化してみるといいかもしれないと思い、今回発表させていただきました。

現実社会の厳しさと戦っている皆さんのヒントになれば幸いです。

さて、実はスライドからは時間の都合上いくつか省いた箇所がありまして折角なので補足しておきます。

規模を見積もり期間を導出するという基本の話

相対規模見積りのポイントが時間見積りになってしまっている場合があります。

本人達がそれを把握している場合はまだよいのですが、もし無意識に見積りをするときに時間換算しているようでしたら、それは無駄なので思いきって(理想|現実)時間で見積もるのがよいのではないでしょうか。

規模見積りは「規模を見積もって期間を導出する」ことで、見積りや計画作りにかかるコストを軽減しつつ、だいたいあってる計画をたてるのに非常に役立ちます。それはスライド中にあるような、不確定要素の多い中で、必要十分な見積りと計画づくりをするためのテクニックの一つです。

もし時間見積りで妥当な時間を見積れるような成熟したチーム、プロダクトであれば、時間の見積りをするのがよいのではないでしょうか。

ベロシティの考え方と、初期の想定ベロシティの合意について

発表では、突然ベロシティという言葉を使ってしまって「しまったな」と思っていたのでここで簡単に補足します。

ベロシティとは、上で話したような「規模を見積もって期間を導出する」ために必要な、1イテレーション(スプリント)あたりに消化するポイント数です。

ベロシティは扱いが非常に難しい物と感じていて、多くの場合これがコミットメントになってしまい、開発チームが身動きがとれなくなってしまうことがあります。

そこで一つのアイデアとして考えているのは

• POやマネージャにはベロシティは安定させるのが大事という説明をする
  • ベロシティが安定しないと計画がたてられない
• 開発チームにはどうやったらベロシティが上がるのか考えてもらう
  • 課題を見つけ解決していく姿勢

という二枚舌作戦です。

AEP読書会でも、ベロシティの扱いについてディスカッションがあったのですが、その際も「ベロシティはチームのパワーの限界近くまでは上がるが、無限に上昇するものではない」という話がでていました。

このあたりを上手く説明できると、お互いやりやすいと思うので、みなさんどうやっているのか知見を共有しましょう！

また、もう一つ問題になるのが、開発に入る前、入った直後の想定ベロシティをどう置くかという問題です。

これもまたよく揉めるところだと感じていて、ハッピーケースとしては「ベロシティは2-4イテレーション程度見てから決めましょう」という感じにできるとよいのですが、1週間イテレーションだとしても半月から1ヶ月かかるので、その間リリース計画は立てられませんとなる困りますよね。

チームメンバーがお互いの能力をよく知っていれば、大体の想定ベロシティを考えることはできるのですが、そういうケースばかりでもないので難しいです。ここも知見を共有しましょう！

2種類のバッファ

バッファには

• フィーチャバッファ
• スケジュールバッファ

の2種類があります。フィーチャバッファについては、優先順位付けができればそれで終わりなので、ここでは、スケジュールバッファについて考えます。

基本的には、スケジュールバッファはPOや事業マネージャが用意するべきで、個々のストーリーに詰まなくてもいいような関係作りが大事ではないと考えています。

もちろん、技術的難易度が高いフィーチャについて、合意の上でバッファを取るのは大切ですが、そういう例外を除いて基本方針としてはフィーチャの見積りにバッファを積まないほうが、スケジュールを考える上では有用ではないでしょうか。

見積りや計画づくりがいらない組織

当然見積りや計画づくりはタダじゃないので、目的を持って行おうというのは発表でも述べましたし、資料にも含まれています。

では、見積りや計画づくりが不要なチームや組織は存在するのでしょうか？

私は見たことないですが、どこかにはあるんじゃないかなとは思います。もしそういう組織を知ってる方がいらっしゃいましたらぜひ教えてください！

おわりに

というわけで、みなさん充実した見積りと計画づくりを！

Comeback Japan 2015 ～日本のアジャイルを応援しよう～ - Comeback Japan ～日本のアジャイルを応援しよう～ | Doorkeeper というイベントが急遽行われるという話を聞き、せっかくなのでということで発表してきました。

発表内容と資料はペパボテックカンファレンスのエントリを参照ください。

参加者のみなさんからいろいろのフィードバックをいただき、そのおかげで本番(テックカンファレンス)も上手くいきました。ありがとうございました。

発表後は某社の方と某インフラについてもりあがったり、スクラムやってるんですよーという話を聞いたり、とても有意義な時間でした。

時間の都合上最後までいれなかったのですが、企画してくださった方々、会場のリクルートマーケティングパートナーズさん(めっちゃお洒落な会場でびっくりしました)ありがとうございました！

CoreOSの機運が高まってきたので CoreOS Meetup Tokyo #1 - connpass に参加して知見をいただいてきました。

プロダクション運用しているところの話は非常に面白かったのと、Checkpoint/Restore の話は「あっこれコンテナ仮想化勉強会で聞いたやつだ！」みたいな感じで、このあたりの技術が少しずつ自分の中で繋ってきた感ができた気がします。

社内では、とあるOpenStack環境でCoreOSのインスタンスをバンバン立ち上げられるようになったので、バンバン使って知見を貯めるぞ、という気持ちが高まっております。

おっさんからいろいろ言われたりするだろうけどそんなことどうでもいいので「おっさん向け最新のオススメ論文10選」みたいなエントリを社内SNSでもいいので書いてください。お願いします。

4日(土)に息子のエレクトーンの発表会があったので行ってきました。一年間飽きもせず楽しめたようなのでよかったよかった。

近くのいくつかの教室で合同の発表会で、ジュニアドラムの子とかもいてなかなかよかったのですが、席の位置取りをミスって正面から写真がとれなかったのが残念。

あとは、今日から幼稚園だったので、また一年無事に通ってくれる嬉しいなと思っております。あと1年で小学生とか、月日が流れる速度が上っているとしか思えない…

4冊。うち一冊がぞい。さみしい。

OpenStackクラウドインテグレーション オープンソースクラウドによるサービス構築入門
日本OpenStackユーザ会
読了日：03月12日

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
貝瀬岳志
読了日：03月19日

WEB+DB PRESS Vol.85
菅原元気
読了日：03月24日

NEW GAME! （2） (まんがタイムＫＲコミックス)
得能正太郎
読了日：03月29日

ミーティング現状確認会あらため 今年度もお疲れ様でしたの会 on Zusaar で議事録についてLTしてきました。

もしかしたらストロングスタイルの会かもしれないと出発直前にがっと書いたのですが、参加者の皆さんには納得していただけたようでなによりでした。

あとは、フルーティーなベルギー発泡酒がめちゃくちゃおいしかったです。ありがとうございました！

お仕事でも丁度タイムリーな話題だったので、「何とかフラグが欲しい」と言われたときに自分が考えていることをまとめておきます。

私のポジションとしては「DB設計をちゃんとやろうと思っているものの現実に流されてしまうゆるふわRailsエンジニア」あたりです。

Q. 変更される回数はどれくらいか
    - 一方通行で一回だけ
        Q. 付随する状況があるか(e.g. 退会理由)
            - ある -> イベントテーブル作成
            - ない -> 時刻カラム追加
    - 何回もトグルする
        Q. 付随する情報があるか
            - ある -> イベントテーブル作成
            - ない
                Q. 変更される時刻に意味があるか
                  - ある
                    Q. DB上である時点の状態を再現できる必要があるか
                        - ある -> イベントテーブル作成
                        - ない -> ログでがんばる
                  - ない -> booleanカラム追加

このあたりの要件をヒアリングするなり決めてしまうなりして、妥当なところに落しています。

一番しんどいのが「何回もトグルする上に特定の時点をDB上で再現させないといけないケース」なんですが、幸いにもこのケースにはあまり出会ったことがないのはゆるふわだからですかね。

CTOに就任したあんちぽさんを囲んで決起集会が開催された。

今年も1/4が終わってしまう事実を受け止めつつがんばるぞい。