デザインを変更しました

前のデザインは モバイル フレンドリー テスト でモバイルフレンドリーではないと言われ続けていたので、Githubの Primer を使ってちょっとだけデザインを変更しました。

モバイルフレンドリー認定されたので満足です。ただ、Adsenseの広告が大変残念な感じになっているのでまた後日なんとかします…

ヒューマンエラーを仕組みで防ぐこと

仕事でそういう話をしていて、もやもやしたので考えを整理しておく。

リスクとコストを正しく評価する

ヒューマンエラーをシステムや仕組みによって防ぐといっても、全てのエラーが起きないようにするのは、網羅性とコストの面から不可能ではないかと思う。

つまり、ヒューマンエラーのリスク(原因となる作業の頻度と発生した場合の影響)と、それを仕組み化するコスト(構築と維持)を正しく評価した上で、費用対効果のよいものから対応していくことになる。

このあたりは 自動化するときに考えること - HsbtDiary(2015-05-03) で述べられている考え方にも繋がる。

ただ、これとは少し違うポイントとして「普通はそういうことはやらない」とか「注意すればいい」という思考があると考えている。

仕組みでヒューマンを守る

そういった考え方は、そっくりそのままそれを仕組み化すべき理由になる。

これらの思考はリスクとコストを正しく評価することを放棄しているのと、それが起きてしまったときにその言葉がそっくりそのまま「発生させた人」に返ってしまうのが問題である。

つまり、その人は「普通はやらないことをやってしまう」「注意力がない」というラベルづけされるかもしれないし、そうでなくても本人は罪悪感に苛まれてしまう。(もちろんチームメンバーはフォローするだろうが、仕組み化されてないのが悪くて私はまったく悪くないと言いきれる人はそうはいないのではないと思う)

つまり、仕組み化はデータやシステムを守るだけではなくて、ヒューマンを守るという目的もあるように感じる。

ヒューマンエラーを仕組み化で防ぐことを考えるときは、リスクとコストを客観的でかつ定量的に評価するのが重要で、そこに「普通は」とか「注意すれば」といった主観的で定性的な評価を含めるべきではないのではないだろうか。

在宅勤務訓練デー

災害発生時など在宅勤務せざるおえない状況でもスムーズに業務ができるように訓練する日でした。

いつもの通勤時間の間に洗濯したり布団干したりできるのは便利なので、通勤時間短くしたい欲が高まることに。

プロダクトオーナーシップに関する社内勉強会をはじめました

社内のとあるPOの人から「PO力高めたいんです!手伝ってください!」と言われたので、世間一般で言われているようなPOの経験なんて微塵もない私がなぜか勉強会をセッティングすることになりました。

POStudy 〜プロダクトオーナーシップ勉強会〜 のサイトや参加者の方々のブログとかを見て、まずは Inspired日本語版 | How To Create Products Customers Love を読みましょうということで、初回の今日は「はじめに」と1章の途中までを読みました。

本書では沢山のマネージャや責任者のようなロールが紹介されるのですが、自分達の組織だとその役割は誰がやっているんだろうという疑問や、必要だと思っているけど足りてない面などが明らかになってきて、開発チームの人と話しているだけでは見えないことが見えてくるのは面白いですね。

ただ、だいぶふんわりした感じになってしまったので、次回からは章毎に担当を決めて、まとめ資料をみながらディスカッションしていくというかんじで進めていこうと思っています。

電車に忘れた携帯電話が戻ってきたので知見を共有します

2週間前に割れたNexus5を総武線に置き忘れたところ、本日無事回収できましたので知見を共有いたします。

紛失する前にしておくべきこと

ロックは当然のことながら、必要であれば端末の暗号化やリモートでデータを消去できる仕組みを入れておきましょう。

ロックについては、古い記事ではありますが Androidのロックパターンの解読にFBIが投了!Googleに素直にアカウントとパスワードを聞く | あんどろいどスマート という話もあるので、利便性と強度を考えるとパターンロックが無難じゃないかなと思います。

紛失したらすること

Android デバイス マネージャー にアクセスして、端末の状態を確認しましょう。ネットワークに繋っていれば現在地がわかります。

Android Devise Manager

ロックと消去は実際に行うかどうかは迷うところです。とくにロックは

  • パスワードでのロックに変更される
  • メッセージや連絡先を表示できる

という一長一短の機能ですので、実際に使うかどうかは迷うところではないでしょうか。

当然ですが、ロックや消去はネットワークに繋っていないと効果がありません。デバイスマネージャに甘えずに、十分な強度のロックと暗号化はしておいたほうがいいでしょう。

また、利用しているWebサービスの2FAをかたっぱしからOFFにして、重要なアプリケーションはパスワードの変更やセッションの切断などをやっておくとよいでしょう。

もちろん、会社にも忘れずに連絡しておきましょう。

警察に届けられた携帯はどうなるのか

グーグル先生や教えてgoo、知恵袋などによると、犯罪や悪用の恐れから、紛失した携帯電話を直接受けとるのは多少難易度が高いようです。

私の場合は忘れたのが電車の中とわかっていたので、JRの方に何度か連絡してみましたが当日中には見付からず、翌日以降は何回か電話してみましたが落とし物センターが混んでいてまったく繋がらなくて諦めムードでした。

そんななか、事件が起こりました。

これはどういうことかというと

  • JRから警察に届けられる
  • 警察からキャリアに問い合わせがいく
  • キャリアから契約者に連絡がくる

というルートで、SIMがささっている携帯電話が届けられた場合はほぼ確実に契約者に連絡がくるという仕組みらしいです。(電話だったりメールだったり書面だったりするようです)

ちなみに、Nexus 5には IIJmio のSIMを差していたのですが、IIJからメールが来たので3キャリアじゃなくても大丈夫なようです。

あとは、その連絡の中に保管されている場所と受取番号が記載されているので、そこに行けばOKです。電車に忘れた場合は飯田橋にある遺失物センターに集められるようですが、13時過ぎに行ったところ5人待ちで15分くらいで終わりました。

オチ

私の場合、最初にJRに電話して見付かってないことがわかった時点で、デバイスマネージャの位置情報がとれなくなっていたのでリモートで消去を実行していました。しかし、実は電源が切れていただけで、受け取ってから電源を入れてネットワークに繋がったタイミングで、持ち主の目の前で消去が始まるという衝撃的な結末が待っていました。

2015/04に読み終えた本

今月は諸事情により通勤中の意識が極めて低い状態にあったのでvimの本を再読したり、去年セールでの価格設定ミス(?)で運よく購入できたスレイヤーズ全巻を読んだりしていた。

shucreamの本棚 - 2015年04月 (2作品)
実践Vim 思考のスピードで編集しよう!
Drew Neil
読了日:04月30日

【全巻セット】スレイヤーズ 全15巻セット〈豪華特典版〉
神坂一
読了日:04月30日

powered by booklog

散髪ログ

前回は2/14だったので3ヶ月くらい。ちょうど1年前も行っていたらしい。

LINE DEVELOPER CONFERENCE 2015に参加してきました

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

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

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

LINE Platform Development Chronicle

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

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

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

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

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

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

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

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

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

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

座談会 & 懇親会

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

おわりに

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

第1回ペパボテックカンファレンスで見積りと計画づくりについて発表しました

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

という二枚舌作戦です。

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

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

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

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

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

2種類のバッファ

バッファには

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

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

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

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

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

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

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

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

おわりに

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

Comeback Japan 2015というイベントで発表してきました

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

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

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

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

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

CoreOS Meetup Tokyo

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

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

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

新入社員

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

エレクトーンの発表会と幼稚園開始

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

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

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

2015/03に読み終えた本

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

shucreamの本棚 - 2015年03月 (4作品)
OpenStackクラウドインテグレーション オープンソースクラウドによるサービス構築入門
日本OpenStackユーザ会
読了日:03月12日
評価4

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

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

NEW GAME! (2) (まんがタイムKRコミックス)
得能正太郎
読了日:03月29日
評価5

powered by booklog

今年度もお疲れ様でしたの会(ミーティング現状確認会)でLTをしてきました

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

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

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

なんとかフラグと履歴データについての雑な考え方

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

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

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

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

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

あんちぽ派決起集会

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

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

スクラム実践入門を読みました

本日発売された「スクラム実践入門」という本をさっそく買ってざっと目を通しました。

タイトルに違わず、スクラムを実践するための入門書として、とてもよい内容だなと感じました。

ソフトウェア開発の難しさに正面から向き合う

1章では、スクラムやアジャイル開発に限らない「ソフトウェア開発そのものが難しさ」を明かにし、その難しさにどう立ち向かっていくのか、スクラムは何を手助け、解決してくれるのかを簡潔に説明してくれます。

2章から4章では、スクラムガイドで書かれている各要素を詳しく紹介してくれています。ここの説明は、スクラムでなくても実際にアジャイル開発を実践している人からすると、非常に簡潔に、必要十分な量の説明になっていると感じるのではないでしょうか。まさに実践の入門という感じがしました。

新しい発見もあって、本書を読むまではスクラムチームのそれぞれが責任について、私は以下のように考えていました。

  • 何をどういう順番で作るかに責任を持つプロダクトオーナー
  • プロセスの改善に責任をもつスクラムマスター
  • プロダクトをどう作るかに責任をもつ開発チーム

しかし、一つ視点を上げると「プロダクトをどう作るか」というのは「どういうプロセスで作るか」ということになり、そこに責任を持つのはスクラムマスターだと考えられることができるんですね。

一方で、そう考えることで開発チームにあたるスポットライトが(ただでさえチームという表現で弱くなっているところ)さらに弱くなってしまっているように感じるのはちょっと残念だなと思いました。

赤裸々な失敗談

6章から8章では、他のスクラム本では絶対に読めないであろうコンテンツですね。GMOペパボ、mixi、DeNAでのスクラム導入を初期から振り返って、実際におきた問題やそれに対する対応、結果どうなったかというのを著者の方々の視点から書かれています。

3社の中では、DeNAの大規模スクラムの事例が一番興味深かったのですが、業務委託契約の話については前職のこともありいろいろ思うところが(ここで日記は途切れている

パターンとFAQ

5章と9章以降は、スクラムというフレームワークにどういう具をつめるか、その具をどうやってよりよいものにしていくかという、スクラムマスターの入門書というふうに読みました。

スクラムガイドを読んで「どこからどこまでがスクラムなのか」その枠がぼんやりと見えてきた人が、いざ実践するときにそのフレームワークにどういうプラクティスを詰めるのか、そのヒントがたくさんあるように思いました。

一押しは10章の「スクラムチームでよくある問題と解決策」ですね。どれも本当にあるあるですし、一度解決したつもりでも、メンバーやPOの交代など状況の変化で再発しやすい問題が盛り沢山でした。

6章から8章の事例も含めて、こういうFAQのようなものを知ってるだけでも緊急時に落ち着いて行動できるようになるはずなので、これからやってみようという人は必読ですね。

とりあえず読みましょう

タイトルの通り、これからスクラムを実践してみようという人は必読の内容です。 また、スクラムに興味ない人でも、ソフトウェア開発を今よりもう少しうまくやるためのヒントにはなるのではないかと思います。

みなさんだまって読みましょう。

電子書籍は スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス | Gihyo Digital Publishing からどうぞ。

「30分(くらい)でわかるGit」という勉強会をしました

社内のデザイナーさんから、Gitのmergeとかrebaseがよくわからないという話を聞いて、折角なので資料を作って勉強会を開催しました。

今回も 自分がGitを理解できたなーと思えたきっかけである「全てはコミットである」 という持論を押し付けていく形になっていますが、mergeやrebaseを理解して使っていくためのはやっぱりこれが必要だと思うんですよね。

資料の内容は、なるべく わかりやすさのために正確性を犠牲にしない ように心掛けたつもりですが、無理のある説明になっているところもあるかもしれません。

発表でだいたい30分、質疑や議論含めて45分程度で終われたので、参加者の方々は30分くらいでGitがわかるようになったと信じています!

SUZURIのAPI ClientをHeroicsで生成しました

Ruby Business User Conference で JSON Hyper-Schema についてLT をしたのも半月前のこと、ついにSUZURI Developer CenterでAPIとJSON Schemaが公開されました。

折角なので、interagent/heroicsを使ってクライアントライブラリを生成してみました。

kenchan/suzuri_client

いざ生成してみると、ちょっとおかしいなと思うインタフェースがいくつかあるので原因を調べときます。

あとは、HeroicsはHTTPクライアントライブラリとしてexconを使っているのですが、手元の環境だとうまくSSLの証明書が読み込めないっぽく、exconのREADMEにあるように証明書を自分で設定しないとHTTPSで接続できませんでした。(それかExcon.defaults[:ssl_verify_peer] = falseをする)

そんなこんなでちょっと変なところもあるんですが、これも一つの試みということで。

あわせて読みたい: ワンクリックでインターネットをTシャツにアーカイブれるGoogle chrome拡張作った。 - パルカワ2

通販生活

数日前、たまたまコナミスタイルのポイント失効メールがきたので見に行ったら、IIDX 22のサントラが出るということを知り、特典を確認し、ポスターは不要なのでAmazonで注文しました。もう何年もやってないんですけど、奥さんが現役なのとなんとなく流れで今でも買ってしまうのでした。

konozamaせずに無事発売日に届いたので一安心。

2015/02に読み終えた本

今月は2冊。ひどい。

Ruby Business User Conference で JSON Hyper-Schema についてLTしました

Ruby Business Users Conference 2015 で JSON Hyper-Schema についてLTしてきました。

同じ内容でCFPを出したら落ちてしまったのですが、当日の内容を見るに妥当な結果だったなという感じです。

Ruby Associationのイベントはほぼ初参加だったのですが、いわゆる界隈の人とはまた違った人達が集まっているので、これはこれで面白いなぁと思いながら参加していました。

資料については少し直したいところがあったのですが、.keyファイルが壊れてしまって画像が全て消失したので、発表前にexportしたPDFをそのまま上げました。

補足しておくと、

  • json_schema gem はちょっと微妙なので json-schema を使ってるやつを選んだほうがいいよ
    • そして interpol は json_schema なので…

というくらいです。

IDLからの自動生成は人類の夢なので、もうちょっとこの夢をおいかけようかな、と思っているのでした。

テレビ効果ってすごいなって話

先週から ハンドメイドマーケット minne(ミンネ) のテレビCMがはじまったり、有吉反省会でビリギャルのパッケージの人が本人じゃないことを知り、そのあと事務所のサイトが落ちているのを確認して、テレビ効果ってすごいなーと思った日曜の夜でした。

明日から1週間がんばるぞい。

デブサミ2015にちょっとだけ参加しました

Developers Summit 2015 の Agile TED に同僚のかしめぐさんが登壇するとのことで、応援にいってきました。

身内補正込みだと一番よかったんじゃないかと思いました!掴みも内容もすばらしかった!

後半が社内で練習したときとけっこう変わって、ぐっと良くなっていたのでびっくりしながら聞いていました。

デブサミについての思い出

2012年のWeb日記 で書きましたが、自分にとってはデブサミは思い入れのあるイベントで、参加するたびにあの頃の平鍋さんや角谷さんと今の自分を比べて、もっとがんばろうという気持ちになるのでした。

今年は勝負の年だぞー