読者です 読者をやめる 読者になる 読者になる

邪道

歌って踊れるエンジニア、邪道アジャイラー、邪道スクラムマスターを自称する1エンジニアの叫び

【速報】AgileガチンコFight第0試合、西村直人×-○オヨベタカオ(15分23秒 垂直落下式バーンダウン) #rsgt2015 #agilegachi

2015年2月28日〜3月2日に Regional Scrum Gathering Tokyo 2015 が開催されました。

その中で@nawotoさん&@hageyahooさんと【AgileガチンコFight第0試合】というセッションを行いました。

今回のセッションは、プレゼン形式ではなく対話形式で進めるセッションにしました。

なぜそうしたのか。
とある社内勉強会で、現場のリアルな生の話を持ち寄ってお互いに磨き合って次の日からの行動に直結するようなゴールにしたくて、

  • プレゼン形式のライトニングトーク
  • プレゼンの内容を肴にして参加者全員でフリートーク

という形式でやってみました。

その結果、
現場のリアルな悩みを相談し合ったり、
「うちだとこうやってるんだけどお前のところはどうだ?」とか、
「今度うちのコードレビューしてよ・見に来てよ」とか、
想像以上の場になりました。

これを社外でもやってみたい、というのがきっかけです。

決してプロレスがやりたかっただけではありません!!

大事なことなのでもう一度。

決してプロレスがやりたかっただけではありません!!

f:id:TAKAKING22:20150228162419j:plain

今回は光栄にも機会をいただけることになったので、第0試合と称して@nawotoさん対戦させていただきました。
ということで煽りVTRだけ紹介させていただきます。
プロレスと同じでエンターテイメント性を大事にしているので、誇張表現があることはご容赦くださいw

AgileガチFight第0試合オープニングムービー

AgileガチFight第0試合 挑戦者オヨベ煽りVTR

AgileガチFight第0試合 チャンピオン西村煽りVTR

第0試合でかつ30分という短い時間だったので、雰囲気を知ってもらうことを優先しましたが、いいフィードバックをいただくこともできました。

おまけに見事に勝利をおさめることができました!

大事なことなのでもう一度。

おまけに見事に勝利をおさめることができました!!!

 

そして。

今回の第0試合の経験を活かしてAgileガチFight PRJを始動させます。

AgileガチFight PRJスタート

リアルにリングがある場所を借りて、参加者の皆さんと一緒に全員でより密度の濃い追体験ができるイベントを開催したいと考えています。

ぜひリアクションを下さるとやる気が出るのでよろしくお願いします。

 

最後になりましたが、イベント関係者・参加者の皆さん本当にありがとうございました。

我々は本当に越境したいのか? #devlove

この記事はDevLOVE AdventCalendar 2014 「越境」の42日目の記事です。
テーマである「越境」について、考えてみた時に浮かんだ疑問について考えてみたいと思います。

コンテキスト

本題に入る前に私のコンテキストを簡単にご紹介すると、

こんなところです。

そんな私のまわりにある境になりそうなものは、

  • 開発とビジネス
  • 日本語(母国語)と英語
  • 個人と会社
  • コミュニティと会社
  • スペシャリストとゼネラリスト

あたりでしょうか。 

越境っていいことなの?

ここから本題です。

越境はすごくいいことであると述べられることが多いが、私はそうとは限らないと思っています。なぜなら蛮族(ヒャッハー)でも越境はできます。

f:id:TAKAKING22:20141219173934j:plain

越境はWhy(目的)ではありません。
越境はWhy(目的)を達成するためのHow(手段)の1つに過ぎません。

新しい技術を導入することがWhy(目的)になってしまい、本来あるべきWhy(適切な導入理由)や一緒に考えるべきHow(運用計画)が存在せず、おまけに導入した張本人がそのチームを去って残ったのは荒れ果てたシステムだけだった・・・などどいう世にも恐ろしい越境の悪例を私は何度も見たことがあります。

未来がない越境などしない方がまだマシです。
自分勝手とはいえ明確な目的がある分、蛮族(ヒャッハー)の方がまだマシだとさえ感じます。

“なにを為したいのか”と “どうやって為すのか” はセットで考えないと、不幸な未来が待っているのかもしれません。

越境する人たちはすごい人?

とあるプレゼンをした後の質疑応答で、

「チームに変えられる人はスーパースターだと思うのですが、どうやったら私たちもそうなれますか?」

と質問いただき、

「もし自分がスーパースターならアジャイルやチームビルドに興味を持たなかったでしょう。だってなんでも自分でできちゃうじゃないですか。スーパースターじゃないからチームが必要で、サービスにとってチームがアジャイルになることが必要だと思ったからやってるだけです。」

と応えました。

f:id:TAKAKING22:20141219182823p:plain

私が知っている越境し続ける人たち(ここではチェンジエージェントと呼びます)だと思う皆さんは、越境しようと思って越境しているわけではない気がします。そもそも境だと認識すらしていないからこそチェンジエージェントで居続けられるのでしょう。

とある施策をチームに取り入れようと考えたときに、反対する上司がいるだろうと思って慎重に変化を進めたらむしろその上司が積極的にサポートしてくれた・・・などという経験が私にもあります。境をつくるのも感じるのもたいていは自分自身の中だけで、本当の境は自分が思っているよりも少ないのだとそのとき気づきました。

もし、なにかやりたいことができない理由を「すごい人」「スーパースター」という言葉に変換しているのであれば、本当にできない理由は自分自身の中にあるのかもしれません。

本当に越境したい?

越境がHow(手段)の1つであるということは、越境しなくてもWhy(目的)を達成する手段はあるハズです。

それでも本当に越境したいのでしょうか?

私はどうでもいいと思っています。
「なにを為したいのか」
「どうやって為すのか」
を考えたときに必要だと思ったことをやってきただけで、今後もそれを続けます。やってきたことが越境だったとしてもそうでなかったとしても、走り続けなければいけません。

そんな想いをこめたのがこのプレゼンテーションでした。

境だと思わなければ、越えることすら越えられる。

越境に夢を見るのはもうやめました。
越境したとしても、境の向こうには世界の続きがあるだけです。
私には行きたいところ(成し遂げたいこと)があるだけです。

自己紹介

最後に自己紹介させてください。
もしこの記事を読んで興味をもっていただけたなら、フォローやメッセージなどをいただけると幸いです。

f:id:TAKAKING22:20141220101655p:plain

次回

バトンは志田さんにおつなぎします。
お楽しみに!

俺のコードレビュー勉強会を開いてみた【勉強会ふりかえり編】 #devraku

f:id:TAKAKING22:20141106005204p:plain

2014年11月5日に俺のコードレビュー勉強会を開催しました。

オープニング資料はこちら。

ライトニングトーク資料はこちら。

当日の様子もまとめました。


2014年11月9日 俺のコードレビュー #devraku - Togetterまとめ

Why

とあるサミットで感銘を受けたプレゼンを社内で勝手に再演した際に、
「こんな活動をやってる人が社内にいるなんて知りませんでした。」
と言われたことが今思い返すときっかけでした。

その再演の際、まったく意図はしていなかったのですが、再演後にチームに共有するついでに声をかけた他部署のメンバーを巻き込んでアツいディスカッションが生まれました。

再演をやってよかったなーと思うと同時に、せっかく同じ社内にいるのにすぐ手をのばせば届く人やノウハウにたどり着いていないことが本当にもったいないと感じました。

そこで起きたアツいディスカッションをもう一度意図的に起こしたい、という想いをこじらせて今回開催に至りました。

What

f:id:TAKAKING22:20141106011455p:plain

聴衆型の勉強会は社内外に多いので、今回は対話型の勉強会にしました。

Where

テーマ的にセンシティブな内容を含む可能性が強く、そこを気にしてディスカッションをシュリンクさせたくないので今回は社内勉強会として開催しました。

Who

f:id:TAKAKING22:20141106010121p:plain

今回の勉強会でメインターゲットにしたのは、勉強会や本などからインプットしたことを現場で実践する・実践しようとする人たちです。

How

f:id:TAKAKING22:20141106010029p:plain

コードレビューをテーマにしたライトニングトークを募集。
当日なぐりこみOKで特にとりまとめもせず、当日集まったものを順番でLT。

ライトニングトークを媒介に場を盛り上げた後は、Scrum Master's Night形式のディスカッションを採用(この形式の勉強会をやってみたかった)。

f:id:TAKAKING22:20141105213604j:plain

テーマであるコードレビューについて話したいトピック・聞いてみたいトピックを付箋に書いてもらい、内容を説明しながらホワイトボードに貼っていってもらう。

出尽くしたところで、「これいいな!」と思ったトピックにドット投票をしてもらい、票の多いトピックから時間の許す限りディスカッションする形式で進行しました。

 

ふりかえりKPT

Keep

  • 「極力楽に運営する」という姿勢をスコープとして固定した
  • 各地方拠点(北海道・仙台・大阪)とスムーズにやりとりができてよかった
  • 想定よりもディスカッションがかなり白熱した
  • 勉強会に出て「持ち帰りがあった」割合が多かった
  • Tryにできるコードレビューパターンが多く見つかった
  • 運営者が一番楽しんだ
  • Tech Talkとのコラボレーションができた

Problem

  • ライトニングトークに時間制限がなかった
  • ちょっと終了時間が押してしまった(盛り上がったからだけど)
  • ふりかえりのアウトプットを形として残せなかった

Try

  • さんま力(トークファシリテーション)に磨きをつける
  • ワールドカフェ形式でふりかえりをアウトプットする

やってみてどうだったか

f:id:TAKAKING22:20141106013057p:plain

Learn(学んだこと)をGenba(現場)に活かすことができることが理想です。

基本一方通行なインプットをする機会は多く存在するため、今回はそこで学んだことを実際に現場で実践する部分をターゲットに勉強会を開催しました。

いきなりそんなにうまくはいかないだろうと期待はしていなかったのですが、予想以上に議論は白熱してとてもいい勉強会になったと自負しています(内容自体については別記事で紹介予定)。

ライトニングトーク中は聞いてるだけで大人しかった参加者のみんなも、自分たちの現場のストーリーを話しだすと饒舌になっていました。よくよく考えてみると、そもそもみんな想いを持っているから集まっているのであって、それを出し合う場・仕組みをつくってあげるだけで盛り上がるのは当然でした。たったの2時間あまりの時間で、本当にたくさんの学びがうまれました。

こんなに楽なことはない!
久しぶりに運営して心からよかったと思える勉強会になりました。

f:id:TAKAKING22:20141106014647p:plain

社内外に関わらず得た学びを現場で活かす。
それを現場同士で結びつけて、次の学びにつなげる。

具体的に言うと、Tech Talkや社外の勉強会でみんなが得た学びを現場で実践した頃合いを見計らって、お互いの事例を今回のような場を設けて共有し合う。もっといい現場改善につながり、それを成果としてTech Talkや社外の勉強会で発表してもらう。

この学びのフィードバックループがぐるぐるまわりはじめると、面白いことになるんじゃないかとワクワクしています。

でも期待しません、勝つまでは。

f:id:TAKAKING22:20141106015948p:plain

ということでやってよかったので、今回MVPでTryしてみた勉強会をDev楽と銘打って不定期でまわしてみようと思います。

無理をしない・楽をする、そして最高に楽しいがモットーなので、Continuousなペースでの開催になりますが、盛り上げてくれればすぐに調子に乗るタイプなので、取り上げて欲しいテーマがある方はのせてください。

また、無理に社内に閉じようとは考えていません。ぜひ機会があれば一緒に胸ぐらつかみ合って学びましょう。

楽にいこうぜ!

f:id:TAKAKING22:20141105213737j:plain

f:id:TAKAKING22:20141105213722j:plain

楽天テクノロジーカンファレンスの1ストーリー #rakutentech

いよいよ今週末、2014年10月25日(土)に楽天テクノロジーカンファレンス2014が開催されます。まだ参加登録可能ですので、ぜひふらっと電車で行ける海外カンファレンスにお立ち寄りください。


Rakuten Technology Conference 2014|EventRegist

カンファレンス内容の見どころは以下をどうぞ!

簡単に注目ポイントを書いておくとこんな感じ。
  • もちろん英語(電車で行ける海外カンファレンス)
  • 楽天ランチ
  • ライトニングトーーーク!
  • Copeもくるよ
  • Chef, Docker, Openstackなどのホットなトピック
  • サテライト開催(仙台、大阪、福岡、シンガポール
  • ヨガセッション ★NEW★

 

今日はちょっと裏方の話をしてみます。

私が楽天テクノロジーカンファレンスの運営にはじめて携わったのは2012年、社会人3年目でした。


Rakuten Technology Conference 2012 - 楽天テクノロジーカンファレンス2012

きっかけは森さんから声をかけていただいて・・ですが、ちょうどアジャイルやエンジニアリングのコミュニティや勉強会に参加・発表しはじめていた頃で、その経験を活かしつつ自分でテクノロジーイベントをつくるのもいいかなと軽い気持ち(ごめんなさいごめんなさい)で参画を決めました。

この2012年はカンファレンスの英語化をおこなった年であり、実は裏側でも運営スタッフも入れ替わりの年で、とにかくはじめてのことばかりでした。

カンファレンスの英語化は人生においてもなかなか経験できないものですが、個人的には不安はなく、どうせはじめてなのでやることやるだけだろうと思ってました。まがりなりにも英語化の会社名のでオペレーションを英語にするのは容易いし、セッションに関してもむしろ遠慮なく海外の著名人や世界最先端技術のホットな人をお呼びできるので好都合でした。

ただ唯一の心配が集客。英語化したカンファレンスを日本語で開催して本当に人が来てくれるのか。はじめて関わってメインで運営したカンファレンスに人が来てくれなかったらどうしようと。

http://tech.rakuten.co.jp/rtc2012/img/report/report_photo024L.jpg

ところがふたをあけてみると過去最高の参加者となりました。これは本当にうれしかった!

個人的にも、コミュニティ活動で知り合わせていただいた方が多くご参加して下さり、当日カンファレンスで声をかけてくれました。後の戦友となる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

f:id:TAKAKING22:20141010125959j:plain

*1

*1:今年のスタッフポロシャツ designed by @takaking22

レガシーコードについて考えてみた #wewlc_jp

f:id:TAKAKING22:20140927124606j:plain

レガシーコード改善勉強会 in東京 - パスマーケット に参加しています、なう。

勉強会出ててくる内容(キーワード)や雰囲気はハッシュタグから追えると思いますのでぜひ!

参加レポートではなく、せっかくなので勉強会のテーマの レガシーコード” について個人的な想いをつらつら書いてみます。

レガシーコードってなあに?

  • レガシーコードとはテストのないコードである

というわかりやすい定義もありますが、

  • 仕様がわからないコード
  • 意図がわからないコード
  • 読めないコード

といった主観的なイメージもよく聞きます。

定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。

【余談】このあたり読むと面白い!

レガシーコードとの遭遇

今までの自分の経験では、コードが存在するところには(程度の違いはあるけど)必ずレガシーコードが存在していました。

仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。

ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、レガシーコードとどう向き合っていくかはエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。

よくあるレガシーコード

今までレガシーだなーと思ったコードを思い出してみました。

  • メソッドでやりたいことがわからない
  • インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい
  • メソッドが大きすぎてテストコード書こうにも複雑すぎる
  • AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない
  • 変更部分にしか注意がまわっていない書き方をしている
  • 歴史を感じるくらい人によって書き方がバラバラ
  • そもそもシステムやテストの設計方針がない
  • とにかくわけがわからない

思い返してみるとこれらの共通点は、

  • テストコードが存在しない

でした。
もちろんテストコードがあればいいってわけじゃないけれど統計的に!

レガシーコードができそうなにおい

今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。

これらを見つけた時に聞いてること。

  • メソッドが長い
    →「このメソッドの目的ってなに?」
    →「このメソッドテスト書いててつらくなかった?」
  • インデントが深い
    →「ここ通るときの条件を教えて!
  • 条件文が複雑
    →「この条件文を文章で説明してほしいなー」
  • メソッドからreturnするパターンが多い
    →「このメソッドのreturnのパターンを教えて!」

コードを書かない時にもレガシーなにおいを感じるタイミングはあります。

  • 説明が不安そう
  • 仕様理解があいまい
  • タスク自体のDoneの定義があいまい
  • (項目・コード問わず)テストが書けてない
  • 本人がぱつってる

こんなときはあやしいですよね。

レガシーコードとどう向き合ってきたか

もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。
でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。

でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。

だから、

状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう

ってことを考えるようになりました。

今後レガシーコードとどう向き合っていくか

今後以下の2つのアプローチを考えてます。

  1. やってきたことをアウトプットする
  2. 知識をインプットする

1. やってきたことをアウトプットする

レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。

自分は本能で動くタイプなので、やってみたあとから、
「あのときやったことに名前・方法論があったんだ」
と知識がついてくることが多いです。

それはそれでいいと思うんですが、やってきたことを形式知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。

2. 知識をインプットする

アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。

 

 

考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。

おわり!!

リリース手順書について本気出して考えてみた #CleanReleaseManual

社内でエンジニア向けのプレゼンをする機会があったので、リリース手順書について本気出して考えてみました。

f:id:TAKAKING22:20140216202016p:plain

手順書書くくらいなら自動化すればいいじゃん

もちろんそうです。

でも、まともなリリース手順書をつくれなければ、自動化されたリリース作業を行うことはできても自ら自動化することはできません。

自動化やContinuous Deliveryはもちろん大事ですが、自分と一緒にはたらくエンジニアには自動の前に考えてほしいことがあったのでプレゼンにまとめてみました。

新人の頃の教訓

この内容は、すべて自分が新人の頃にリーダーから伝えてもらったことです。

  • 「変化前の確認⇒変化⇒変化後の確認」さぼらない
  • 上から下までコピペでリリースできることが最低限
  • リリース手順書には相手がいる
  • 相手の事を思いやって書く
  • 意図を持って書く

最初はなかなかうまく書くことができませんでしたが、新人の頃に癖づけることができて本当によかったです。

いろんな人のリリース手順書を見てきましたが、震えるような手順書には出会っていません。

たかがリリース手順書、されどリリース手順書!

リリース手順書に限らないコツ

このプレゼンのメインはリリース手順書ですが、そのコツは手順書に限るものではありません。仕事と作業を分けることを意識して大事な事に集中したいものです。

 

いろいろと賛否両論はあるかもしれませんが、すべて受け止めます。
ご意見ご感想はご自由にどうぞ。

ホウレンソウ、○○管理って本当に必要!?

とある先輩がメルマガと称して率直な意見をぶつけ合うメールを配信しているのを見ていいなーと思い、チームメンバーに同じことをしはじめました。

せっかくなので当たり障りない範囲でブログにも残してみます。

*1

ホウレンソウ…
タスク管理…
スケジュール管理…

いろんな本・記事・プレゼンで語られているし、誰もが新人の頃に上司や先輩からうるさく言われた経験があります。

ひょっとしたら無条件で『必要だ!』と教えこまれてきたかもしれません。

でも、本当に必要なんでしょうか?

私はなくてもうまくいくならばいらないんじゃないかと思います。

コミュニケーションコストだってかかるし、
管理コストだってかかるし、
時間だってかかるし、
かったるいし、
もし無くせるなら無くしたい!
その時間使って新しい機能つくってお金もうけたい!
その時間の分早く帰って合コンに行きたい!
って心から思います。

とはいえ現実的に考えると、やっぱりホウレンソウやなんとか管理は必要になってしまうことが多いです。それはなぜかというと他人とコミュニケーション無しで同じ方向へ進むのは難しいから。

「あそこに向かうぞー」(ホウレンソウ)って認識合わせたり、
「ちょちょ、そっちじゃない!こっちだよー」(なんとか管理)ってチェックしたり、
やっぱり必要になってしまう。

 

しかし、
(今必要である)=(だから必ずやった方がいい)
(今必要である)=(どこの誰にとっても必要である・なくすことはできない)
と考えてしまうのは思考停止です。

無条件で「必要だ!」「当たり前だ!」と思っていたホウレンソウやなんとか管理は、なくすことはなかなかできないかもしれないけど少なくとも減らすことはできます。

もし減らすことができたらもっと大事なことに時間が使えることでしょう。

普段やってる仕事の進め方を思い返してみて、
今やってる朝礼がなくなった時、
今やってるかんばんがなくなった時、
今やってるスクラムの儀式がなくなった時、
どうすればいいのか想像できないのだとしたら、それは何かに頼って思考停止してしまっているのかもしれません。

うまくいっている時ほど“当たり前”や“成功”の中身を疑ってみると見えてくるものがあるものです。