2017年のふりかえり
これまでやったことありませんでしたが、いろんな人がふりかえりをされているのを見て気が向いたので気が向いている内に1年を簡単にふりかえってみます。
2017年ふりかえり
今年はなんといってもモブプログラミングな年でした。
おかげさまでたくさんアウトプットする機会をいただいたり、イベントやモブプログラミング現場体験会などを通していろんな人と出会うきっかけができました。
こういった活動が継続できているのも、お仕事がうまくいっている＝価値につながっているからこそです。モブプログラミングを通して、ずっとやりたかった大きな会社でのリーンスタートアップがようやく形になり、役割やしがらみを越えて少しずつ事業を成長させることができてきました。
飽きるまではもう少しこの活動は続けていこうと思いますので、何かあればお気軽にご用命ください。
インプット
来年はさくっと出せるように読んだ本とかまとめておこうと思った。
アウトプット
- 社外発表 15回
- ブログ記事 5本
- ブログ 2本
- Qiita 3本
- 執筆 1回
2017/1/12 Regional Scrum Gathering Tokyo2017【発表】
非常に珍しく体調を崩して高熱が出ていたのであまり覚えていない。
2017/1/28 DevLOVE 199 越境CON 【発表】
その場でLTをつくるいつもの芸。
2017/4/5 モブプログラミングを実際にやってみた【Qiita】
モブプログラミングをはじめるきっかけとなった記事。
2017/4/25 DevOpsDays Tokyo 2017【発表】
ある意味、黒歴史となったワークショップ。
- モブプログラミングワークショップ
- 朝まで生DevOps（パネルディスカッション）
2017/4/26 Azure FunctionsでサーバレスにさくっとHipchat通知してみる【Qiita】
サーバレスうはうは。でも今ならFunctionすら書かずにLogic Appでどうにかしそう。
2017/5/25 アジャイルチーム未来会議【運営】
2017/6/18 DevLOVE 200 Bridge【発表】
おかげさまで8万PV（2017/12/29現在）です。
2017/7/11 モブプロディスカッション【運営・発表】
楽しかったなー！
2017/7/21 DevLOVE関西「心理的安全性」のことに思いを馳せる【発表】
関西すごい！また行きたい。
2017/8/25 Geeks Who Drink in Tokyo-Agile Team Edition-【発表】
2017/8/25 追われる開発と追う開発【ブログ】
2017/9/10 モブの宮【発表】
2017/9/16 XP祭り2017【発表】
2017/10/28 Rakuten Technology Conference2017【運営】
2017/11/2 Microsoft Serverless Hackfestにモブで参加してきた！【ブログ】
2017/11/8 エンタープライズアジャイル勉強会【発表】
2017/11/12 DevLOVE リンスタ関ヶ原 〜敗軍の将、兵を語る編〜【発表】
2017/11/16 ヴァル研究所ライトニング大会【発表】
2017/11/18 JJUG CCC 2017 FALL【ワークショップ】
2017/12/11 アジャイルひよこクラブ 結局スクラムってなんなの？日本のパイオニアから学ぶアジャイルの歴史【発表】
2017/12/22 WEB+DB PRESS Vol.102【執筆】
2017/12/25 Azure Bot Service ✕ Cognitive Servicesで英語に翻訳するChat Botを作ってみる【Qiita】
2018年の抱負
来年はさっそくRegional Scrum Gathering TOKYO 2018とDeveloper Summit2018で登壇させていただきます。
あとはこっそり海外イベントでの登壇もやってみようかなーと思っています。
来年はもう少しエンジニアとしてのアウトプットを増やしたいなーと思っているのと、ブログや執筆にもチャレンジしてみようと思います。
ちなみに来年は社会人10年目の年になります。 同じ会社でずっといるのですが、サービスや部署が変われば転職したのと同じくらい変化がある会社なので2〜3年に一度は変化を体験しているのと、常にやりたい挑戦に挑んでいるんで飽きずにここまできました。
ただ、それはそれでリスクかなーと思っているので去年くらいから 転職 は真剣に考えています。 ところが最近重要な問題に気付いたんですが、常に今がピークな自分なのでネガティブな理由でやめることがないことができません。今も今までで一番いいチームで今まで一番いい仕事をしています。
ということで、引き続きおいしいお肉とおいしいお寿司を募集しております！！
レガシーコードについて考えてみた #wewlc_jp
レガシーコード改善勉強会 in東京 - パスマーケット に参加しています、なう。
勉強会出ててくる内容（キーワード）や雰囲気はハッシュタグから追えると思いますのでぜひ！
参加レポートではなく、せっかくなので勉強会のテーマの “レガシーコード” について個人的な想いをつらつら書いてみます。
レガシーコードってなあに？
- レガシーコードとはテストのないコードである
というわかりやすい定義もありますが、
- 仕様がわからないコード
- 意図がわからないコード
- 読めないコード
といった主観的なイメージもよく聞きます。
定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。
【余談】このあたり読むと面白い！
レガシーコードとの遭遇
今までの自分の経験では、コードが存在するところには（程度の違いはあるけど）必ずレガシーコードが存在していました。
仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。
ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、レガシーコードとどう向き合っていくかはエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。
よくあるレガシーコード
今までレガシーだなーと思ったコードを思い出してみました。
- メソッドでやりたいことがわからない
- インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい
- メソッドが大きすぎてテストコード書こうにも複雑すぎる
- AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない
- 変更部分にしか注意がまわっていない書き方をしている
- 歴史を感じるくらい人によって書き方がバラバラ
- そもそもシステムやテストの設計方針がない
- とにかくわけがわからない
思い返してみるとこれらの共通点は、
- テストコードが存在しない
でした。
もちろんテストコードがあればいいってわけじゃないけれど統計的に！
レガシーコードができそうなにおい
今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。
これらを見つけた時に聞いてること。
- メソッドが長い
→「このメソッドの目的ってなに？」
→「このメソッドテスト書いててつらくなかった？」 - インデントが深い
→「ここ通るときの条件を教えて！」 - 条件文が複雑
→「この条件文を文章で説明してほしいなー」 - メソッドからreturnするパターンが多い
→「このメソッドのreturnのパターンを教えて！」
コードを書かない時にもレガシーなにおいを感じるタイミングはあります。
- 説明が不安そう
- 仕様理解があいまい
- タスク自体のDoneの定義があいまい
- （項目・コード問わず）テストが書けてない
- 本人がぱつってる
こんなときはあやしいですよね。
レガシーコードとどう向き合ってきたか
もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。
でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。
でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。
だから、
状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう
ってことを考えるようになりました。
今後レガシーコードとどう向き合っていくか
今後以下の2つのアプローチを考えてます。
- やってきたことをアウトプットする
- 知識をインプットする
1. やってきたことをアウトプットする
レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。
自分は本能で動くタイプなので、やってみたあとから、
「あのときやったことに名前・方法論があったんだ」
と知識がついてくることが多いです。
それはそれでいいと思うんですが、やってきたことを形式知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。
2. 知識をインプットする
アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。
考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。
おわり！！
アジャイル開発をはじめたって価値はうまれない #agilejapan
2013年5月24日に開催されたAgile Japan 2013で登壇させていただきました。
「アジャイルサムライ壱の太刀～実践者たちが語るアジャイル導入の型～」
竹林 崇 氏
株式会社エムティーアイ Healthcare事業本部 テクニカル・リーダー
上田 佳典 氏
NECビッグローブ株式会社 サービス開発本部
及部 敬雄 氏
楽天株式会社 新サービス部 新サービス1課
対象者
アジャイルを導入するきっかけ（判断材料・説得材料）が欲しい人
ベンダー、マネージャー層⇒判断材料 現場の人⇒説得材料
セッション概要
最近、アジャイル開発に取り組む現場や組織が増え、アジャイルへの期待がますます大きくなってきていると感じます。
このセッションでは、アジャイル開発に関心をお持ちの皆様に向けて、三人の実践者が現場での実践をもとにアジャイルの導入についてお話します。教科書だけではわからない「はじめた理由、課題の解決方法、周囲の巻き込み方、成果」について共有させていただきます。
皆様の現場にアジャイルを導入するきっかけになれば幸いです。
「アジャイルサムライ壱の太刀～実践者たちが語るアジャイル導入の型～」というタイトルで、3人のパターンのプレゼン、パネルディスカッション、テーブルディスカッションという盛りだくさんのセッションとなりました。
その中で、私は説得しない・はじめないアジャイル開発のはじめ形について話させていただきました。
今回はその内容をご紹介させていただきます。
アジャイル開発関連の勉強会や書籍を見ていると、守破離でいう守、はじめ方にフォーカスした内容がとても多いです。私がアジャイルを知ってから2年半ほどですが、あまり大きく変化はしていないと感じます。
すると、一つの疑問を感じます。
「アジャイル開発をはじめるのは難しいのだろうか？」
なぜ難しいと感じるのかをちょっと掘り下げてみます。
- 上司を説得できないかもしれない
- はじめたいけど一緒にやってくれる仲間がいないかもしれない
他人を変えることは難しい、相手がいるから難しいと感じるのでしょう。
難しいのであればいっそのこと説得もはじめることもやめてしまえばいい！
とかの諸葛亮孔明は言いました（嘘）。
冗談はさておき、そもそもアジャイル開発をはじめようとはじめまいと、もともと目指していた目指すゴールが変わるわけではありません。
もちろん上司を説得したり、「はじめます！」と宣言してはじめた方がいいケースもあります。
しかし、そこにこだわるばかりに立ち止まってしまうくらいなら、説得しない・はじめないはじめ形があってもいいのではないでしょうか？
最初は説得しないはじめ形について。
最近、私は新しいチームに異動しました。
異動することを知った後、新しいチームでどんな価値を生み出すのか、そのために私が何をすべきなのか考えました。
そして最初に私がやったことはとにかく“話す”ことでした。各メンバーに1対1でヒアリング、ランチや雑談でコミュニケーションをとりました。
これは、リーダー・Product Owner・ベテランエンジニア・新人エンジニアいろんな人と話をし、それぞれが課題におもっていることをリストアップしたものです。
まとめてみて気付いたことは、みんな共通して今よりよくしたいと思っているということです。
同じ想いを持っているのであれば、説得は必要ありません。
説得や交渉のように相対するコミュニケーションではなく、同じ方向をみて意見を出し合えるコミュニケーションの場をつくるだけでチームは進んでいくと私は確信しました。
よくバスに乗せるという例えを聞きます。しかし今よりよくしたいという想いを共感できない（バスに乗らない）人はいるのでしょうか？
「サービスをもっとよくして利益を上げたい」
「仕事を終えて早く帰りたい」
「最新の技術を使いたい」
言い方は様々ですが、これらは本当に違う方向を向いているのでしょうか？
屁理屈かもしれませんが、本当にバスに乗らない人がいるのだとすると、どんな方法をとろうとも一緒に働きたくないでしょう。
次にはじめないはじめ形について。
私は、「はじめます」と宣言して失敗した経験があります。
それからは宣言するのはやめました。
これは実際にいままでのふりかえりででたTryの一部です。
こうやって眺めてみると難しいことはありません。
多くの現場で、意外と当たり前に思えることができていなかったりします。まずそれを当たり前にすることからはじめるのであれば、わざわざ「はじめます！」なんて仰々しいはじめ方をしなくてよいでしょう。
そして、当たり前にするだけなので私でもはじめることができました。
はじめるハードルは調整可能です。高いハードルを感じているのであれば低くしてしまえばよいだけです。
最後に新しいチームに参加して4ヶ月で見えてきた成果についてご紹介します。
振り返りを数値でまとめてみました。
継続は力なり。小さなTryでも積み重ねれば大きな変化となります。
プロジェクトの進み方についても振り返ってみます。赤線は理想線（こう進んだら順調だなー線）、青線は実際の進捗を表してます。
計測しはじめた最初の頃はなかなか順調に進めることができず最後に「えいやっ！」でがんばる学生症候群でしたが、最近では毎週進捗を気にしながら順調に進めることができています。
少しは大人に近づいてきたかもしれません。
まだ大きな成果が出せたわけではないかもしれませんが、新しいチームでも“はじめる”ことはできました。
なによりも、同じチームメンバーの若手の子が「私もやってみたい」と言ってくれ、実際にふりかえりのファシリテートなどに挑戦してくれています。
このスライドはデブサミ2012で@daipresentsさんが話されていたものですが、もしかしたら少しだけ気持ちがわかったかもしれません。
アジャイル開発をはじめる・はじめないに関わらず、向かう先があってそこに向かう道があることは変わりません。
その道のりは険しいかもしれませんが、それはおそらくもともと私たちの仕事が難しいからであって何かをはじめたから険しくなったわけではありません。
どんなに道のりが険しかろうと、歩き出すことにハードルはありません。ハードルを感じているとしたらそれは自分自身が作り出しているのかもしれません。
したがって、説得しない・はじめないではじめるアジャイル開発があってもよいと私は思います。
最後に、なぜはじめ形という漢字を使っていたのかご説明します。
型・・・パターン
形・・・型に自らの血を注いだもの
本や勉強会を通して、多くの型を知ることができます。
しかし、型のままで役に立ちません。型を知り、自らの血を注いで形にしてはじめて価値が生まれます。
Agile Japanでも多くの型を見つけることができたと思います。ぜひ皆さんの熱い血を注いで形にして現場に活かして下さい。
デブサミ2013で「アジャイルサムライって当たり前になるのかな？」を発表します #devsumi @TAKAKING22
2013年2月14日〜15日の二日間にわたって開催中のDevelopers Summit2013。
デブサミは去年（Developers Summit2012）が初参加だったのですが、今年はなんと登壇させていただきます。
アジャイルサムライって当たり前になるのかな？
最近、アジャイル開発に取り組む現場や組織も増え、私と角谷で監訳した書籍「アジャイルサムライ」も多くの人に読んでいただきました。国内での取り組みはさらに活発になっていて、アジャイルへの期待も大きくなってきていると感じます。
では、『アジャイルサムライ』のような開発は、みなさんの現場で当たり前になるのでしょうか? また、そうした開発を続けていきたいと思ったら、何をするべきでしょうか? それを私と自分の現場で取り組んでいる若いサムライたちの話を交えて、みなさんと一緒に考えていきます。
アジャイルサムライや様々なコミュニティ活動を中心に、アジャイルが日本でも広く認知されるようになりました。
しかし、実際に現場でアジャイル開発を取り組みはじめる時には、
- なにからはじめたらいいのか？
- はじめたらどうなるのか？
という疑問が浮かびます。
これらの疑問に真剣に向き合ってみようということで、「アジャイルサムライって当たり前になるのか？」をテーマに、今回のセッションが企画されました。監訳者である西村さんを中心に、実際に現場でアジャイル開発に取り組んでいる竹林さん上田さんそして私が登壇させていただきます。
デブサミ2013のテーマは、Action!
参加していただける皆さんと私たちで明日のAction! を一緒に考えましょう。
会場で皆さんにお会いできることを楽しみにしております。
余談
実は去年のデブサミ2012後に、同じ会社から参加したメンバーとフィードバックLT大会を行いました。その時発表させてもらった資料が以下です。
この時はデブサミはもちろん他の勉強会にも参加し始めたくらいだったため、会場の熱気にとても刺激されたことを覚えています。
なかでも登壇者の皆さんがかっこよく見え、このLTの際には「来年は登壇したい！」なんて言っていたことを覚えていますが、現実として登壇させてもらう機会をいただくことができました。
- 機会をいただけたデブサミ運営の皆様
- 一緒に登壇させていたくお三方
- 普段支えてくださっている現場の皆様
- コミュニティ活動などで出会った刺激的な皆様
- 葉っぱをかけてくださった@daipresentsさん
に対する御礼は今日のセッションを思い切り楽しむ事で還元させていただきたいと思います。
アジャイルサムライ |
はじめてのふりかえりをまとめてみた
今のチームではじめてのふりかえりをしました。
前のチームでは、週に1度（最初は2週に1度）の振り返りを2年間続けることができました。もちろん振り返りを行えばすべてがうまくいくわけではありませんが、実際に続けてみて、
- チームの改善スピードがあがった
- 個人もチームも成長した
- 楽しかった
などを感じる事ができました。
うるさく楽しそうにやっていたおかげか、他のチームへの横展開ふりかえりやグループ単位での大振り返りをファシリテートさせてもらったり、多くのふりかえりを経験する事ができました。
今回、今のチームではじめてのふりかえりをやらせてもらえることになり、チームメンバーへのふりかえりの導入としてプレゼン資料にまとめてました。せっかくなので公開させていただきました。なぜふりかえりをするのか、ふりかえりでどういうことを目指すのかにフォーカスしています。
もし誰かの参考にしていただけたら嬉しい限りです。
ご意見やご感想があればお気軽にご連絡ください。
アジャイルレトロスペクティブズ |
Scrum Alliance Regional Gathering Tokyo 2013で暴れてきます #sgt2013
いよいよ今日から二日間にわたって開催されるScrum Alliance Regional Gathering Tokyo 2013。初日の今日は、How to change the worldのJurgen Appelo氏、組織パターンのJames O. Coplien氏の講演を中心に大いに盛り上がっていたようです。
# 私は残念ながら参加する事ができませんでした
思い起こせば、私のマスターセンセイに勧められてScrum Alliance Regional Gathering Tokyo 2013の前身であるScrum Gathering Tokyo 2011に参加させていただいたことをきっかけにアジャイルやスクラムに積極的に取り組むようになりました。Henrik Kniberg氏の基調講演の中の「人は変化を好まない。他人を変えるのではなく自分を変えることからはじめよう」という言葉は今でも私の大切にしている言葉の1つです。
そして、今年はScrum Alliance Regional Gathering Tokyo 2013 2日目の明日、登壇させていただきます。
Product Ownershipをテーマにした2社の事例発表の中で、私はチームとカンバンの歴史から見えてきたProduct Ownershipについて話させていただきます。1年半前にHenrikの講演を聴いてから明日登壇させていただくまでの想いのこもった魂の講演となる予定です。
明日も参加される皆様はお会いできる事を楽しみにしています。
※発表資料は後日Slideshareにて公開予定です。
"スクラムを活用したアジャイルなプロダクト管理" を読んできた #postudy @TAKAKING22
第1回 読書会in東京 - スクラムを活用したアジャイルなプロダクト管理に参加してきました。
″スクラムを活用したアジャイルなプロダクト管理″エクストリームリーディングSTART twitpic.com/bnviic #postudy
— takao.oyobe (@TAKAKING22) December 21, 2012
なぜ参加したか
本書内の推薦文の中で、Agile2012で出会ったEllen Gottesdiener（DISCOVER TO DELIVERの著者）が「全ての成功するアジャイルなチームは、全員がプロダクトマネージャーと同じような考え方をする」という一文を寄せているのを見かけて私はこの本を読むことを決意しました。
私は職種的にはエンジニア職ですが、最近はプロダクトオーナーのことをちゃんと知る必要を強く感じています。かのJeff Patton曰く「プロダクトオーナーシップはプロダクトに関わるすべての人が持つべき」で、この言葉は私に深くささっています。
意外とプロダクトオーナーについて深く記述されている本（特に和訳されているもの）は見当たらず、この本がプロダクトオーナーについて理解する一つのきっかけになればと思い今回読書会に参加させていただきました。
スクラムを活用したアジャイルなプロダクト管理 |
えくすとりーむりーでぃんぐ
今回の読書会はエクストリームリーディングという手法をとりました。
エクストリームリーディングについては、やってみた感想やこうしたらいいのではという想いも持っているので、別途まとめようと思います。
以下の記事の一節でも触れられているので参考に貼っておきます。
ってことで簡単な流れだけ以下にまとめます。
- プロダクトオーナーに対する理解度でチーム分け
※なるべく同じレベルの人達でチームをつくる（効果的な議論のため） - 1テーブル5人でエクストリームリーディング
※今回の進捗： 推薦文～「1.2.2 リーダーとチームプレイヤー」まで - それぞれのテーブルごとにまとめた内容を全体に共有
- 読書会の振り返り（KPT＆気づき）
テーブルごとの共有の雰囲気を写真で共有。
発表する側も真剣。
みんな本を片手に聞いてます。
関さんナイスカメラ目線！
同じ読書範囲でもテーブルごとに出るアウトプットは違いました。
最後に自分の参加したテーブルのまとめだけ共有させていただきます。
1章の冒頭はプロダクトオーナーについて端的に書かれている部分でした。
プロダクトオーナーの役割はスクラムガイドにあるように、以下のとおり。
“プロダクトバックログを管理し、チームが実施する作業の価値を保証する「唯一の責任者」”
このプロダクトオーナーとして望ましい特性に挙げられているものを抜き出してみると、
- ビジョンを描き続ける
- それを伝え続ける
- チームと協働する
- イノベーションを奨励・変化・曖昧性・議論・衝突・遊び心・実験を理解
- リスクを恐れない
- リーダーとメンバーを両立
- ファシリテーション能力
- 忍耐力
ここだけみると、プロダクトオーナーはスーパーマンであるかのように思えます。
しかし、この一連の説明の最後に「起業家チーム」というタイトルでBill GatesやSteve Jobsなどの有名なリーダーの例について触れているコーナーがあり、その中で、
“優れたチームなら、与えられたアイデアが平凡でも、それを素晴らしいものに変えてしまうでしょう”
というフレーズが出てきます。このフレーズにこそ作者の意図があると私たちは読みました。
プロダクトオーナーの役割は、とても重要なものであると同時にとても大変です。しかし、それを一人ですべて実現する必要はありません。ビジョンを見据えて実行し続けながらも、時には足りないものをさらけだしてチームに埋めてもらう勇気も必要なのかもしれません。
まとめ
冒頭に書いた通り、エクストリームリーディングについては別途まとめます。
よく考えてみたら、「読書会」にまともに参加するのは私にとって初めての経験でした。私は一通りさっと本を読んで参加しましたが、さっと読んだ時と読書会を通して得られた感想はまったく違うものになりました。アウトプットを意識してインプットすることで理解度は深いものになります。
エクストリームリーディングは、事前に読んでこなくても参加できるため、現場のチームや社内読書会のようなものをやるときにも使えるかもしれません。
本の内容については、このエントリーではまだ冒頭にしか触れていませんが、プロダクトオーナーについて理解したいという私と同じ想いを持った方にはおすすめできる一冊です。
もし興味を持たれた方はぜひ次回ご参加下さい！
エキストリームリーディングのおかげ？でページ数としてはあまり進んでいないので、全然追いつけます。
おまけ
二次会の飲み会の席でも本を取り出して語りあう図。
|
スクラムを活用したアジャイルなプロダクト管理 |
