変わる現場をつくる #devlove
このエントリーは『DevLOVE Advent Calendar 2013 「現場」』の2日目の記事です。
自己紹介
2番バッターを務めさせていただきます@TAKAKING22です。2番というと、送りバント・進塁打・ヒッティングなど状況にあわせたバッティングを求められます。
私は、楽天株式会社という会社でエンジニアをしています。
楽天には野球団と楽天市場と英語以外にもたくさんのサービスが存在し、私は後者の小さなサービス達を開発・運用する部署に所属しています。肩書きはエンジニアですが、チームビルディング・プロジェクトマネジメント・プロダクトマネジメントなど必要であらば現場を変えるために役割の壁をぶっ壊して日々奮闘しています。
そんな現場での実体験を勉強会やカンファレンスなどで発表させていただいているのですが、はじめての発表は2011年の12月のDevLOVE HangarFlight - Snow Barrageでした。私のエンジニア人生にとって大きなきっかけになり、そこからの約2年間でたくさん成長ができたと思います。
現場と変化
私たちの業界では、ビジネスも技術もプロセスも凄まじいスピードで変化していきます。それに合わせて現場も変化していかないと取り残されてしまいます。
なんていうマクロな視点だけでなく、ミクロな視点(自分たちの現場)でも変化はつきものです。言語のバージョンは数年でサポートが終了するし、メンバーが1人変わればチームの雰囲気はがらっと変わるし、そうした変化に対応する形で現場もまた変化を求められます。
ところが、現場で活動をしていると変化を拒む見えない壁にぶちあたることがあります。そんな時に私たちには3つの選択肢があるそうです。
私の現場の変化のストーリー
「●●だからできるんでしょ?」
という声をよく聞きますが、どの現場もはじめからそうであったわけでなく必ず誰かが変化をおこしたストーリーがあります。
私は2012年末に今のチームに異動することが決まった際に、まずメンバーへの個別のヒアリングをしました。その結果をチェンジインセプションデッキにまとめ、面談の際に上司との合意をとりました。
- 何やってるかが見えない
- テストがない
- トラブルが多い
- リリースに時間がかかる
という状態だったチーム。
それから約10ヶ月。
今では、カンバンの前で毎朝朝礼をし、毎週ふりかえりをし、テストコードを書き、トラブルも起きず、リリースは毎回成功しています。
言葉で書くと簡単ですが、一朝一夕に変化したのではなく、小さな成功や失敗を積み重ねた変化の結果が今のチームです。
私がチームに入るという大きな変化にも対応してくれたメンバーに感謝しています。
私にとっての現場
先ほどうまくいかないときに3つの選択肢があるといいました。私は常に3つ目の「変える」を選ぶようにしています。
自分の現場が必ずしもいい現場だとは限りません。仮に今いい現場だとしても明日にはどうなるかわかりません。
そんなときに我慢するのもいいでしょう。辞めるのもいいでしょう。しかし、変えることから逃げてそれらを選択をすることは絶対にしたくないです。
いい現場は自分たちでつくらなければいけません。
私がやっていることは、自分では名前を使わずとも、アジャイル・リーンなどさまざまな呼び方で呼ばれます。
しかし現場の最前線で戦う私たちからすると、
『なんだっていい!やってやる!!』
という思いでしかありません。
明日起こせる変化は小さいかもしれませんが、その1歩を積み重ねない限り行きたい目的地にはたどりつくことができません。
私は、その思いのもと、明日からも現場のために現場にあわせた変化(1歩)を起こし続けていこうと思っています。
そして変化を起こせなくなったとき、第一線から退こうと決めています。
ネクストバッター
次のバッターはOppyさんです。
DevLOVEの裏方をされていて、DevLOVE現場甲子園2013でもたくさん助けていただきました。
ランナー1・2塁。
3番、Oppyさんのバッターボックスにご期待ください!!
Change Hackersで「つくる現場 - 変化を支える3つの現場アーキテクト -」について発表します #changehackers
11月6日(水)に開催される変化の担い手チェンジエージェントの実践を追え! - Change Hackersというイベントで「つくる現場 - 変化を支える3つの現場アーキテクト -」という発表をさせていただきます。私自身の現場で起こした “変化” の事例発表です。
セッション概要は以下の通りです。
教科書を読んだり成功した現場の事例を聞いていると、「いい環境だ」「うちではできない」と壁を感じることがあるかもしれません。しかし、どの現場も最初からうまくいっていたわけではなく、壁を壊した誰かのストーリーが存在します。今回は私の現場のストーリーを通じて、現場で感じたチェンジに必要な3つの現場アーキテクトについてお話しさせていただきます。どこにでもいる1エンジニアの私でも壁は壊せました。 “ヒーローでなくても壁は壊せる”
このイベントはChange Hackerというコミュニティが主催しています。
私は自分自身のことをチェンジハッカー/チェンジエージェントだと意識したことはないですが、常に現場をチェンジさせることを考えて活動をしてきました。
チェンジはただ起こせばいいものではありません。
私はたくさんの経験(失敗)の中から、現場に合わせたチェンジを計画的に起こすことを意識するようになりました。
私自身がおこしてきたチェンジとそれによって現場/チームがどう変わったのかというチェンジの事例と、その中で見つけたチェンジに必要な土台、3つの現場アーキテクトについてお話しさせていただきます。
当日はもう1人のチェンジハッカー、私の先輩でありヒーローでもある伊藤さんのご講演もあります。まだ空席があるようなので、ぜひお時間がある方はこちらからご登録ください!空席残りわずかなのでおはやめに!!
みなさんにお会いできることを楽しみにしております。
#rakutentech 楽天テクノロジーカンファレンス2013は予定通り開催します【明日10/26】
天候が心配でしたが、楽天テクノロジーカンファレンス2013は通常通り開催されます。
[ Rakuten Technology Conference 2013 ]
みなさん!
台風は大きくそれ、明日、暴風域に入る予報はなくなりました。
予定通り明日のイベントは開催します!
ただ、風雨が強い可能性はありますので、ご来場の際はお気をつけてお越しください。
一部のセッションはYouTubeLiveとUstreamでの配信を予定しております。
お越しいただけない方は、是非ストリーミングでお楽しみください。
‘まだまだ直前まで参加登録をお受けしておりますので、
台風だから行けない?とお考えだった方も、ぜひご登録ください!
http://tech.rakuten.co.jp/
台風それた!!なるほど、きっとこういうことだろう。 #rakutentech pic.twitter.com/ucpla1j3ZP
— takao.oyobe (@TAKAKING22) 2013, 10月 25
とはいえ何があるかわかりません!
公式サイトはもちろん、下記SNSからも情報を発信させていただきますのであわせてご確認ください。
参加していただける場合も、お気をつけて会場までお越し下さい!
明日皆さんにお会いできることを楽しみにしています。
全ては10月26日(土)に襲来ス!! #楽天テクノロジーカンファレンス #rakutentech
いよいよ今週末、2013年10月26日(土)に楽天テクノロジーカンファレンス2013が開催されます。
そして、さらには我らが楽天イーグルスも見事日本シリーズに進出することができ、同日、2013年10月26日(土)に巨人との第一戦が行われます。(18:30 Kスタ宮城)
しかーし!!
なんと台風までもが日本列島に接近しております。
しかも2つも!
このニュースを聞いて下記を思い出しましたw
ということで、当日は悪天候に見舞われる可能性があります。
台風の影響により首都圏(またはサテライト開場の地域)が暴風域
となる場合には、下記の通り短縮または中止となる場合がございま す。
朝9時の時点で暴風域に入っており、終日暴風域となる予報の場合は中止
朝11時の時点までに暴風域を抜ける場合は、午後1時からイベントを開催
最終判断は、気象庁による10月25日午前11時の予報を以って判断し、改めてアナウンスいたします。
上記の通りアナウンスさせていただきます。
公式サイトはもちろん、下記SNSからも情報を発信させていただきますのであわせてご確認ください。
仮に実施となって参加していただける場合も、お気をつけて会場までお越し下さい!
すでに多くの方に参加登録いただいておりますが、まだまだ絶賛受付中です。
まだお済みでない方は、こちらからどうぞ!
*1:http://bousai.tenki.jp/bousai/typhoon/
電車に乗って海外カンファレンスへ!10/26は楽天テクノロジーカンファレンス!! #rakutentech
来る2013年10月26日(土)、楽天テクノロジーカンファレンス2013が開催されます。
テクノロジーカンファレンスの中身について知りたい方は、すでにタイムテーブルにすべての講演情報が掲載されているのでぜひご確認ください。
また、おすすめセッションの紹介などすばらしいエントリーが既に立っているので、こちらをぜひ!
- 楽天テクノロジーカンファレンスに行っておくべき10の理由(Satoryu's Diary)
- 今年の「Rakuten Technology Conference 楽天テクノロジーカンファレンス」について その1(kawaguti の日記)
- 今年の「Rakuten Technology Conference 楽天テクノロジーカンファレンス」について その2(kawaguti の日記)
- 今年の「Rakuten Technology Conference 楽天テクノロジーカンファレンス」について その3(kawaguti の日記)
- 今年の「Rakuten Technology Conference 楽天テクノロジーカンファレンス」について その4(kawaguti の日記)
- 今年の「Rakuten Technology Conference 楽天テクノロジーカンファレンス」について その5(kawaguti の日記)
私は去年に引き続き今年も中の人として活動させていただいています。
せっかくなので今日はブログで紹介させていただこうと思うのですが、既にすばらしい諸先輩方がいいブログを書いて下さっているので、あくまで個人ブログなので個人ブログ(非公式)らしく好き勝手にメッセージを投げかけてみます。
英語だから「うっ・・」とためらってしまう方へ
楽天社員なんだから得意でしょ?と思うかもしれませんが、楽天=みんな英語が得意っていうのは、メガネ=マジメってのと同じくらい決めつけです。
今でこそ楽天はEnglishなカンパニーですが、私が入社した2009年は今ほどグローバル化に打ち出しておらず、英語化などの話は全く出ていませんでした。私は英語だけは本当に苦手でひたすら逃げて社会に出てきた身だったので、英語化の話を聞いた際は、ここにきてつかまったか・・・と内心思いました。
しかし、エンジニアという職で情報を効率的に情報を得るためには英語は欠かせません。特に新しい情報は日本語の資料が出るまでタイムラグがあることが多く、またフレームワークやOSSなどの公式なドキュメントはほとんどの場合英語です。
リーンスタートアップやアジャイルなどスピードがますます重視されるこの業界で、英語を避けてエンジニアをすることは、麻雀で例えるならはじめから絶二門+字牌落とし、将棋で言うなら飛角桂香落ち、進撃の巨人で言うなら立体起動装置無しで巨人と戦うくらいのハンデマッチです。
なんてことはわかっていても、なかなか身が入らないのが英語。しかしそんな私が本気で英語をやろうと思った転機がありました。
それは海外カンファレンスに参加したときのことです。
勉強する英語は大嫌いだけど、コミュニケーションなら身振り手振りでどうにかなるだろうという安易な思いで海外カンファレンスに参加しました。
いざ言ってみるとやはり日常会話やセッションをヒアリングするくらいはどうにかなったものの、ワークショップなどでネイティブ同士のディスカッションにまざることができなかった時にとても悔しい想いをしました。
そのときの模様は下記エントリーや記事でも書いてます。
「こいつらと激論を交わしたい」「いつかここで発表したい」と思った時、人生ではじめて英語が必要だと心から思うことができました。
同じ想いを日本で体験できる“電車に乗っていける海外カンファレンス”は、楽天テクノロジーカンファレンス2013だけでしょう。少しでも興味を持っていただけたそこのあなたもチャレンジしてみてはいかがでしょうか?
参加登録(無料)は絶賛受付中です。まだお済みでない方は、こちらからどうぞ!
スタッフ一同お待ちしています!!
*1:[写真] 昨年のテクノロジーカンファレンスの様子
ダラスで感じた甲子園を日本で #devlove
2013年11月9日(土)に、DevLOVE現場甲子園2013を楽天タワー2号館で開催します。
会場提供・イベント運営のお手伝い・(たぶん)発表をさせていただくのですが、せっかくなのでイベントへの想いをブログに綴ります。
ダラスで感じた甲子園
2012年8月、海外で開催されたとあるカンファレンスに参加しました。
世界中から1000人以上の参加者が集まっているカンファレンスで、「動いているところはじめてみた!」という誰もが知っている本の著者なども多く参加していました。
このカンファレンスで感じた違和感をまとめると以下の通りです。
- トラック数が多いので参加者の3~4割が発表者
- ワークショップで全員が本気で激論を交わす
- 休憩時間に隣の人に「お前は何がすごいんだ?」を聞かれる
- 発表したくてたまらなくなって会場の外のスペースでオープンジャムをはじめる
多くの参加者が、参加する・教えてもらう・聞きにいくという姿勢ではなく、自分たちがつくる・(情報を)つかみにいく・生み出すという前のめりな姿勢でのぞんでいると感じました。
私やDevLOVE Founderである @papanda さんは、ダラス(カンファレンスの開催地)の地で甲子園を感じました。
プロでも通用するスーパーエースもいるけれど、毎日学校(現場)で一生懸命バッドを振っている選手も同じ舞台にいる。彼らは全員が参加者であり、全員が選手です。
この雰囲気を日本でもつくりたい、そんな思いえ企画されたのがDevLOVE現場甲子園2013です。
現場選手が集うDevLOVE現場甲子園2013
DevLOVE甲子園は、
- 創 : 開発技術、プログラミング、UIデザイン
- 考 : サービス企画、スタートアップ関連、UXデザイン
- 守 : インフラ、運用保守
- 団 : 開発プロセス、チーム運営、組織改革
の4トラック構成です。
既に発表者枠の応募は閉じていますが、参加者枠は残り僅かですがまだ募集しているのでぜひご参加ください。
参加者枠で参加される方も、強制はしませんが、選手のつもりで前のめりにご参加いただくことをお勧めします。特にイベントページのこのあたりをよくお読みくださいw
最後の20分はアンカファレンス枠。自由にその場で話したい人が使えます。(休憩でも可)
DevLOVE現場甲子園の球児(主役)は、あなたであり隣の参加者です。
毎日汗水たらしてバットを振っている実践者たちがそれぞれの現場について語る圧巻の60ストーリー!
夏は過ぎてしまいましたが、アツい熱闘を一緒につくりませんか?
最後に大好きな熱闘甲子園 ED(名勝負の多かった2006年)をどうぞ。
DevLOVE現場甲子園でもこういうアツい想いが!!
アジャイル開発をはじめたって価値はうまれない #agilejapan
2013年5月24日に開催されたAgile Japan 2013で登壇させていただきました。
「アジャイルサムライ壱の太刀~実践者たちが語るアジャイル導入の型~」
竹林 崇 氏
株式会社エムティーアイ Healthcare事業本部 テクニカル・リーダー
上田 佳典 氏
NECビッグローブ株式会社 サービス開発本部
及部 敬雄 氏
楽天株式会社 新サービス部 新サービス1課
対象者
アジャイルを導入するきっかけ(判断材料・説得材料)が欲しい人
ベンダー、マネージャー層⇒判断材料 現場の人⇒説得材料
セッション概要
最近、アジャイル開発に取り組む現場や組織が増え、アジャイルへの期待がますます大きくなってきていると感じます。
このセッションでは、アジャイル開発に関心をお持ちの皆様に向けて、三人の実践者が現場での実践をもとにアジャイルの導入についてお話します。教科書だけではわからない「はじめた理由、課題の解決方法、周囲の巻き込み方、成果」について共有させていただきます。
皆様の現場にアジャイルを導入するきっかけになれば幸いです。
「アジャイルサムライ壱の太刀~実践者たちが語るアジャイル導入の型~」というタイトルで、3人のパターンのプレゼン、パネルディスカッション、テーブルディスカッションという盛りだくさんのセッションとなりました。
その中で、私は説得しない・はじめないアジャイル開発のはじめ形について話させていただきました。
今回はその内容をご紹介させていただきます。
アジャイル開発関連の勉強会や書籍を見ていると、守破離でいう守、はじめ方にフォーカスした内容がとても多いです。私がアジャイルを知ってから2年半ほどですが、あまり大きく変化はしていないと感じます。
すると、一つの疑問を感じます。
「アジャイル開発をはじめるのは難しいのだろうか?」
なぜ難しいと感じるのかをちょっと掘り下げてみます。
- 上司を説得できないかもしれない
- はじめたいけど一緒にやってくれる仲間がいないかもしれない
他人を変えることは難しい、相手がいるから難しいと感じるのでしょう。
難しいのであればいっそのこと説得もはじめることもやめてしまえばいい!
とかの諸葛亮孔明は言いました(嘘)。
冗談はさておき、そもそもアジャイル開発をはじめようとはじめまいと、もともと目指していた目指すゴールが変わるわけではありません。
もちろん上司を説得したり、「はじめます!」と宣言してはじめた方がいいケースもあります。
しかし、そこにこだわるばかりに立ち止まってしまうくらいなら、説得しない・はじめないはじめ形があってもいいのではないでしょうか?
最初は説得しないはじめ形について。
最近、私は新しいチームに異動しました。
異動することを知った後、新しいチームでどんな価値を生み出すのか、そのために私が何をすべきなのか考えました。
そして最初に私がやったことはとにかく“話す”ことでした。各メンバーに1対1でヒアリング、ランチや雑談でコミュニケーションをとりました。
これは、リーダー・Product Owner・ベテランエンジニア・新人エンジニアいろんな人と話をし、それぞれが課題におもっていることをリストアップしたものです。
まとめてみて気付いたことは、みんな共通して今よりよくしたいと思っているということです。
同じ想いを持っているのであれば、説得は必要ありません。
説得や交渉のように相対するコミュニケーションではなく、同じ方向をみて意見を出し合えるコミュニケーションの場をつくるだけでチームは進んでいくと私は確信しました。
よくバスに乗せるという例えを聞きます。しかし今よりよくしたいという想いを共感できない(バスに乗らない)人はいるのでしょうか?
「サービスをもっとよくして利益を上げたい」
「仕事を終えて早く帰りたい」
「最新の技術を使いたい」
言い方は様々ですが、これらは本当に違う方向を向いているのでしょうか?
屁理屈かもしれませんが、本当にバスに乗らない人がいるのだとすると、どんな方法をとろうとも一緒に働きたくないでしょう。
次にはじめないはじめ形について。
私は、「はじめます」と宣言して失敗した経験があります。
それからは宣言するのはやめました。
これは実際にいままでのふりかえりででたTryの一部です。
こうやって眺めてみると難しいことはありません。
多くの現場で、意外と当たり前に思えることができていなかったりします。まずそれを当たり前にすることからはじめるのであれば、わざわざ「はじめます!」なんて仰々しいはじめ方をしなくてよいでしょう。
そして、当たり前にするだけなので私でもはじめることができました。
はじめるハードルは調整可能です。高いハードルを感じているのであれば低くしてしまえばよいだけです。
最後に新しいチームに参加して4ヶ月で見えてきた成果についてご紹介します。
振り返りを数値でまとめてみました。
継続は力なり。小さなTryでも積み重ねれば大きな変化となります。
プロジェクトの進み方についても振り返ってみます。赤線は理想線(こう進んだら順調だなー線)、青線は実際の進捗を表してます。
計測しはじめた最初の頃はなかなか順調に進めることができず最後に「えいやっ!」でがんばる学生症候群でしたが、最近では毎週進捗を気にしながら順調に進めることができています。
少しは大人に近づいてきたかもしれません。
まだ大きな成果が出せたわけではないかもしれませんが、新しいチームでも“はじめる”ことはできました。
なによりも、同じチームメンバーの若手の子が「私もやってみたい」と言ってくれ、実際にふりかえりのファシリテートなどに挑戦してくれています。
このスライドはデブサミ2012で@daipresentsさんが話されていたものですが、もしかしたら少しだけ気持ちがわかったかもしれません。
アジャイル開発をはじめる・はじめないに関わらず、向かう先があってそこに向かう道があることは変わりません。
その道のりは険しいかもしれませんが、それはおそらくもともと私たちの仕事が難しいからであって何かをはじめたから険しくなったわけではありません。
どんなに道のりが険しかろうと、歩き出すことにハードルはありません。ハードルを感じているとしたらそれは自分自身が作り出しているのかもしれません。
したがって、説得しない・はじめないではじめるアジャイル開発があってもよいと私は思います。
最後に、なぜはじめ形という漢字を使っていたのかご説明します。
型・・・パターン
形・・・型に自らの血を注いだもの
本や勉強会を通して、多くの型を知ることができます。
しかし、型のままで役に立ちません。型を知り、自らの血を注いで形にしてはじめて価値が生まれます。
Agile Japanでも多くの型を見つけることができたと思います。ぜひ皆さんの熱い血を注いで形にして現場に活かして下さい。