俺のコードレビュー勉強会を開いてみた【勉強会ふりかえり編】 #devraku
2014年11月5日に俺のコードレビュー勉強会を開催しました。
オープニング資料はこちら。
ライトニングトーク資料はこちら。
当日の様子もまとめました。
Why
とあるサミットで感銘を受けたプレゼンを社内で勝手に再演した際に、
「こんな活動をやってる人が社内にいるなんて知りませんでした。」
と言われたことが今思い返すときっかけでした。
その再演の際、まったく意図はしていなかったのですが、再演後にチームに共有するついでに声をかけた他部署のメンバーを巻き込んでアツいディスカッションが生まれました。
再演をやってよかったなーと思うと同時に、せっかく同じ社内にいるのにすぐ手をのばせば届く人やノウハウにたどり着いていないことが本当にもったいないと感じました。
そこで起きたアツいディスカッションをもう一度意図的に起こしたい、という想いをこじらせて今回開催に至りました。
What
聴衆型の勉強会は社内外に多いので、今回は対話型の勉強会にしました。
Where
テーマ的にセンシティブな内容を含む可能性が強く、そこを気にしてディスカッションをシュリンクさせたくないので今回は社内勉強会として開催しました。
Who
今回の勉強会でメインターゲットにしたのは、勉強会や本などからインプットしたことを現場で実践する・実践しようとする人たちです。
How
コードレビューをテーマにしたライトニングトークを募集。
当日なぐりこみOKで特にとりまとめもせず、当日集まったものを順番でLT。
ライトニングトークを媒介に場を盛り上げた後は、Scrum Master's Night形式のディスカッションを採用（この形式の勉強会をやってみたかった）。
テーマであるコードレビューについて話したいトピック・聞いてみたいトピックを付箋に書いてもらい、内容を説明しながらホワイトボードに貼っていってもらう。
出尽くしたところで、「これいいな！」と思ったトピックにドット投票をしてもらい、票の多いトピックから時間の許す限りディスカッションする形式で進行しました。
ふりかえりKPT
Keep
- 「極力楽に運営する」という姿勢をスコープとして固定した
- 各地方拠点（北海道・仙台・大阪）とスムーズにやりとりができてよかった
- 想定よりもディスカッションがかなり白熱した
- 勉強会に出て「持ち帰りがあった」割合が多かった
- Tryにできるコードレビューパターンが多く見つかった
- 運営者が一番楽しんだ
- Tech Talkとのコラボレーションができた
Problem
- ライトニングトークに時間制限がなかった
- ちょっと終了時間が押してしまった（盛り上がったからだけど）
- ふりかえりのアウトプットを形として残せなかった
Try
- さんま力（トークファシリテーション）に磨きをつける
- ワールドカフェ形式でふりかえりをアウトプットする
やってみてどうだったか
Learn（学んだこと）をGenba（現場）に活かすことができることが理想です。
基本一方通行なインプットをする機会は多く存在するため、今回はそこで学んだことを実際に現場で実践する部分をターゲットに勉強会を開催しました。
いきなりそんなにうまくはいかないだろうと期待はしていなかったのですが、予想以上に議論は白熱してとてもいい勉強会になったと自負しています（内容自体については別記事で紹介予定）。
ライトニングトーク中は聞いてるだけで大人しかった参加者のみんなも、自分たちの現場のストーリーを話しだすと饒舌になっていました。よくよく考えてみると、そもそもみんな想いを持っているから集まっているのであって、それを出し合う場・仕組みをつくってあげるだけで盛り上がるのは当然でした。たったの2時間あまりの時間で、本当にたくさんの学びがうまれました。
こんなに楽なことはない！
久しぶりに運営して心からよかったと思える勉強会になりました。
社内外に関わらず得た学びを現場で活かす。
それを現場同士で結びつけて、次の学びにつなげる。
具体的に言うと、Tech Talkや社外の勉強会でみんなが得た学びを現場で実践した頃合いを見計らって、お互いの事例を今回のような場を設けて共有し合う。もっといい現場改善につながり、それを成果としてTech Talkや社外の勉強会で発表してもらう。
この学びのフィードバックループがぐるぐるまわりはじめると、面白いことになるんじゃないかとワクワクしています。
でも期待しません、勝つまでは。
ということでやってよかったので、今回MVPでTryしてみた勉強会をDev楽と銘打って不定期でまわしてみようと思います。
無理をしない・楽をする、そして最高に楽しいがモットーなので、Continuousなペースでの開催になりますが、盛り上げてくれればすぐに調子に乗るタイプなので、取り上げて欲しいテーマがある方はのせてください。
また、無理に社内に閉じようとは考えていません。ぜひ機会があれば一緒に胸ぐらつかみ合って学びましょう。
楽にいこうぜ！
楽天テクノロジーカンファレンスの1ストーリー #rakutentech
いよいよ今週末、2014年10月25日(土)に楽天テクノロジーカンファレンス2014が開催されます。まだ参加登録可能ですので、ぜひふらっと電車で行ける海外カンファレンスにお立ち寄りください。
Rakuten Technology Conference 2014｜EventRegist
カンファレンス内容の見どころは以下をどうぞ！
簡単に注目ポイントを書いておくとこんな感じ。
- もちろん英語（電車で行ける海外カンファレンス）
- 楽天ランチ
- ライトニングトーーーク！
- Copeもくるよ
- Chef, Docker, Openstackなどのホットなトピック
- サテライト開催（仙台、大阪、福岡、シンガポール）
- ヨガセッション ★NEW★
今日はちょっと裏方の話をしてみます。
私が楽天テクノロジーカンファレンスの運営にはじめて携わったのは2012年、社会人3年目でした。
Rakuten Technology Conference 2012 - 楽天テクノロジーカンファレンス2012
きっかけは森さんから声をかけていただいて・・ですが、ちょうどアジャイルやエンジニアリングのコミュニティや勉強会に参加・発表しはじめていた頃で、その経験を活かしつつ自分でテクノロジーイベントをつくるのもいいかなと軽い気持ち（ごめんなさいごめんなさい）で参画を決めました。
この2012年はカンファレンスの英語化をおこなった年であり、実は裏側でも運営スタッフも入れ替わりの年で、とにかくはじめてのことばかりでした。
カンファレンスの英語化は人生においてもなかなか経験できないものですが、個人的には不安はなく、どうせはじめてなのでやることやるだけだろうと思ってました。まがりなりにも英語化の会社名のでオペレーションを英語にするのは容易いし、セッションに関してもむしろ遠慮なく海外の著名人や世界最先端技術のホットな人をお呼びできるので好都合でした。
ただ唯一の心配が集客。英語化したカンファレンスを日本語で開催して本当に人が来てくれるのか。はじめて関わってメインで運営したカンファレンスに人が来てくれなかったらどうしようと。
ところがふたをあけてみると過去最高の参加者となりました。これは本当にうれしかった！
個人的にも、コミュニティ活動で知り合わせていただいた方が多くご参加して下さり、当日カンファレンスで声をかけてくれました。後の戦友となるThe Hiroこと @hageyahhoo さんもこの年のライトニングトークでぶちかましてくれました。自分自身の人のつながりがこういう場所につながるのは本当にうれしい。皆さん、ありがとう！
@kawaguti さんがこの年に連れてきてくれたJeff Pattonも印象深い。
このプレゼンで話したけど、カンファレンスや研修での出会いが仕事にもつながった。
明日のUlitimate Agilist TokyoのOpenjamで暴れてきます #uatagile - 邪道
それから3年連続でカンファレンス運営に携わらせてもらっている。
入館・退館の社内オペレーション、いろいろな申請、日程の社内調整、JIRAで進捗管理、ブートキャンプで集中準備、スタッフポロシャツのデザイン、Webサイト構築自動化、KPI計測の自動化…
カンファレンス自体だけではなく、運営・裏方もこの3年で多く仕組み化や改善がされて、毎年進化していて本当にスゴイ！（たまーに冗談で話が出るけど、「テクノロジーカンファレンスを支える技術」なんて話がどこかで話されてもいいと思うw）
同じ年から運営に参加している頼れるセンターバックな先輩をはじめ、経験豊富で安定感抜群な皆さん、なんだかんだイベントが大好きなスタッフ、毎年手伝ってくれる新卒のみんな…多くの力や想いが集まってカンファレンスが支えられている。
本業務じゃないカンファレンスになぜそんなに熱を入れているのか不思議に思う人もいるだろうけど、本業務じゃないのにこんなに本気の人たちが集まっているからだ、と答えたい。自分をはじめとして運営の皆さんは、本業でもそれぞれ大活躍している人ばかりで忙しい。イベントを主務として働いてる人なんてたったの1人もいない。
こんなカンファレンスが開催できる会社は世界を見てもそんなに無いと思う。
つまり世界中を探してもここでしか経験できないことがきっとあるのだよ。
（なにより終わった後のお酒はおいしいしね）
（今年の打ち上げのLTもやばいだろうなー）
個人的には3年目の節目となる、今年のカンファレンスの準備も順調に進んでる。
毎年恒例（？）になった世界中の社員が同時に参加する朝会でのプレゼンもぶちかました。想定通りなどたばた（これがないとお祭り感がない！）もあったし、カンファレンスが終わるその瞬間までどたばたするだろうけど、やることはやった。
毎年多くのストーリーが生まれる楽天テクノロジーカンファレンス。
英語だけど怖くないので電車で行ける海外カンファレンスにぜひお立ち寄りください！
皆さんにお会いできることを楽しみにしています。
Rakuten Technology Conference 2014｜EventRegist
*1:今年のスタッフポロシャツ designed by @takaking22
レガシーコードについて考えてみた #wewlc_jp
レガシーコード改善勉強会 in東京 - パスマーケット に参加しています、なう。
勉強会出ててくる内容（キーワード）や雰囲気はハッシュタグから追えると思いますのでぜひ！
参加レポートではなく、せっかくなので勉強会のテーマの “レガシーコード” について個人的な想いをつらつら書いてみます。
レガシーコードってなあに？
- レガシーコードとはテストのないコードである
というわかりやすい定義もありますが、
- 仕様がわからないコード
- 意図がわからないコード
- 読めないコード
といった主観的なイメージもよく聞きます。
定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。
【余談】このあたり読むと面白い！
レガシーコードとの遭遇
今までの自分の経験では、コードが存在するところには（程度の違いはあるけど）必ずレガシーコードが存在していました。
仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。
ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、レガシーコードとどう向き合っていくかはエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。
よくあるレガシーコード
今までレガシーだなーと思ったコードを思い出してみました。
- メソッドでやりたいことがわからない
- インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい
- メソッドが大きすぎてテストコード書こうにも複雑すぎる
- AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない
- 変更部分にしか注意がまわっていない書き方をしている
- 歴史を感じるくらい人によって書き方がバラバラ
- そもそもシステムやテストの設計方針がない
- とにかくわけがわからない
思い返してみるとこれらの共通点は、
- テストコードが存在しない
でした。
もちろんテストコードがあればいいってわけじゃないけれど統計的に！
レガシーコードができそうなにおい
今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。
これらを見つけた時に聞いてること。
- メソッドが長い
→「このメソッドの目的ってなに？」
→「このメソッドテスト書いててつらくなかった？」 - インデントが深い
→「ここ通るときの条件を教えて！」 - 条件文が複雑
→「この条件文を文章で説明してほしいなー」 - メソッドからreturnするパターンが多い
→「このメソッドのreturnのパターンを教えて！」
コードを書かない時にもレガシーなにおいを感じるタイミングはあります。
- 説明が不安そう
- 仕様理解があいまい
- タスク自体のDoneの定義があいまい
- （項目・コード問わず）テストが書けてない
- 本人がぱつってる
こんなときはあやしいですよね。
レガシーコードとどう向き合ってきたか
もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。
でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。
でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。
だから、
状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう
ってことを考えるようになりました。
今後レガシーコードとどう向き合っていくか
今後以下の2つのアプローチを考えてます。
- やってきたことをアウトプットする
- 知識をインプットする
1. やってきたことをアウトプットする
レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。
自分は本能で動くタイプなので、やってみたあとから、
「あのときやったことに名前・方法論があったんだ」
と知識がついてくることが多いです。
それはそれでいいと思うんですが、やってきたことを形式知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。
2. 知識をインプットする
アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。
考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。
おわり！！
リリース手順書について本気出して考えてみた #CleanReleaseManual
社内でエンジニア向けのプレゼンをする機会があったので、リリース手順書について本気出して考えてみました。
手順書書くくらいなら自動化すればいいじゃん
もちろんそうです。
でも、まともなリリース手順書をつくれなければ、自動化されたリリース作業を行うことはできても自ら自動化することはできません。
自動化やContinuous Deliveryはもちろん大事ですが、自分と一緒にはたらくエンジニアには自動の前に考えてほしいことがあったのでプレゼンにまとめてみました。
新人の頃の教訓
この内容は、すべて自分が新人の頃にリーダーから伝えてもらったことです。
- 「変化前の確認⇒変化⇒変化後の確認」さぼらない
- 上から下までコピペでリリースできることが最低限
- リリース手順書には相手がいる
- 相手の事を思いやって書く
- 意図を持って書く
最初はなかなかうまく書くことができませんでしたが、新人の頃に癖づけることができて本当によかったです。
いろんな人のリリース手順書を見てきましたが、震えるような手順書には出会っていません。
たかがリリース手順書、されどリリース手順書！
リリース手順書に限らないコツ
このプレゼンのメインはリリース手順書ですが、そのコツは手順書に限るものではありません。仕事と作業を分けることを意識して大事な事に集中したいものです。
いろいろと賛否両論はあるかもしれませんが、すべて受け止めます。
ご意見ご感想はご自由にどうぞ。
ホウレンソウ、○○管理って本当に必要!?
とある先輩がメルマガと称して率直な意見をぶつけ合うメールを配信しているのを見ていいなーと思い、チームメンバーに同じことをしはじめました。
せっかくなので当たり障りない範囲でブログにも残してみます。
ホウレンソウ…
タスク管理…
スケジュール管理…
いろんな本・記事・プレゼンで語られているし、誰もが新人の頃に上司や先輩からうるさく言われた経験があります。
ひょっとしたら無条件で『必要だ！』と教えこまれてきたかもしれません。
でも、本当に必要なんでしょうか？
私はなくてもうまくいくならばいらないんじゃないかと思います。
コミュニケーションコストだってかかるし、
管理コストだってかかるし、
時間だってかかるし、
かったるいし、
もし無くせるなら無くしたい！
その時間使って新しい機能つくってお金もうけたい！
その時間の分早く帰って合コンに行きたい！
って心から思います。
とはいえ現実的に考えると、やっぱりホウレンソウやなんとか管理は必要になってしまうことが多いです。それはなぜかというと他人とコミュニケーション無しで同じ方向へ進むのは難しいから。
「あそこに向かうぞー」（ホウレンソウ）って認識合わせたり、
「ちょちょ、そっちじゃない！こっちだよー」（なんとか管理）ってチェックしたり、
やっぱり必要になってしまう。
しかし、
（今必要である）＝（だから必ずやった方がいい）
（今必要である）＝（どこの誰にとっても必要である・なくすことはできない）
と考えてしまうのは思考停止です。
無条件で「必要だ！」「当たり前だ！」と思っていたホウレンソウやなんとか管理は、なくすことはなかなかできないかもしれないけど少なくとも減らすことはできます。
もし減らすことができたらもっと大事なことに時間が使えることでしょう。
普段やってる仕事の進め方を思い返してみて、
今やってる朝礼がなくなった時、
今やってるかんばんがなくなった時、
今やってるスクラムの儀式がなくなった時、
どうすればいいのか想像できないのだとしたら、それは何かに頼って思考停止してしまっているのかもしれません。
うまくいっている時ほど“当たり前”や“成功”の中身を疑ってみると見えてくるものがあるものです。
「がんばった！」の向こうへ
「がんばった！」は麻薬だ。
僕らの仕事であるサービス開発・ソフトウェア開発を例に挙げると、プロジェクトが炎上したり大トラブルに巻き込まれてどれだけ大変な想いをしても、どうにかリリースまでたどりついて乾杯のビールを飲んでしまえば「よかった！」「がんばった！」となってしまう。
もちろんみんながんばったし、がんばっていると思う。
でも「がんばった！」だけでお給料がもらえるほど世の中は甘くない。
極端な話、がんばらなくても成果を出せば給料がもらえるだろう。
そして、チームメンバーはもとより、競合サービスのメンバーだってみんながんばってる。おそらくがんばってない人はそんなにいない。
であれば、「がんばった！」はあくまでお酒の肴に止めたい。
自分は大丈夫だと思っていても、何かを達成したあとはやはり気が緩んでしまうもの。
勝って兜の緒を引き締めるとはよく言ったものでリリース後のふりかえりにこそ本気でバチバチするように意識しようという自戒を込めて。
「がんばった！」の先に行きたい。
2013年をふりかえってみました
（DevLOVE現場甲子園打ち上げより）
2013年も残すところわずかとなりました。
毎年恒例の個人年間ふりかえりを行ったところ、2013年も多くの出会い・学びがありました。簡単ではありますが今年にふりかえりのほんの一部を公開させていただきます。
数値でふりかえり
- カンファレンス・勉強会参加 : 47
- 発表（社外） : 10
- スライド公開数 : 5
- ブログ投稿数 : 10
- KPT総ファシリテート数 : 73
- 読んだ本 : 30
- クリアしたゲーム : 12 ※神々のトライフォース2含む
- 回収したアニメ : 20
- 握手会参加数 : 1
KPTT
Keep
- 新しいチームも自他共認めるいいチームに変われた
- サービス（楽天レシピ）が大好きになった
- 年初に立てたチーム年間計画をクリアすることができた
- 2012年から2013年の1年にかけて個人的4大ドームツアー講演達成した
（Scrum Gathering、XP祭り、デブサミ、アジャイルジャパン）
Problem
- 業務内でエンジニアリングに携わる時間が減ってきた
- いろいろ計測してみたけど仮説の設定があまくあんまりいい指標ではなかった
- 大きなイベントが重なって継続的でなかった
- Agile2013のセッション通らなかった
- 出世払いが増えてきた
Try
- 業務外でエンジニアリングする（内容は決めてあるけど濁します）
- 1年を通してのKPIを設定する
- ブログを月1以上書く
- 発表を依頼されるようになる
Thanks
To チーム・部署
新しい環境でも遠慮なくやらせていただきました。一緒にやってる仲間から「仕事が楽しくなった」「自慢できるチーム」といってもらえたのがなによりでした。もしかしたら賛否両論ある方もいらっしゃると思いますが、変化が起こっているということなのでそれもまた嬉しいフィードバックです。
サービスとしてもチームとしても今年は準備の期間と計画していたので計画以上に進めることができたので2013年としては優かもしれませんが、サービスとしての価値がうまれないとなんの意味もなさないと思います。遠慮したり安定させるのは大人に任せて、来年以降もこれまで以上に空気を読んで空気を壊して行こうと思いますので引き続きよろしくお願いいたします。
To 会社
ありがとうございました。
会社を変えてやりましょう！
To 勉強会・コミュニティ
たくさんの出会いと学びをありがとうございました。
現場を変えてやりましょう！
