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年に一度は変化を体験しているのと、常にやりたい挑戦に挑んでいるんで飽きずにここまできました。
ただ、それはそれでリスクかなーと思っているので去年くらいから 転職 は真剣に考えています。 ところが最近重要な問題に気付いたんですが、常に今がピークな自分なのでネガティブな理由でやめることがないことができません。今も今までで一番いいチームで今まで一番いい仕事をしています。
ということで、引き続きおいしいお肉とおいしいお寿司を募集しております!!
Microsoft Serverless Hackfestにモブで参加してきた!
2017年10月30日から2017年11月1日の3日間で、Microsoft Serverless Hackfestにモブで参加してきました。
Microsoft Serverless Hackfestとは
簡単にまとめると、
本気で解決しにかかるというエンジニアにとっては垂涎なお祭りです。
今回は Serveless がお題です。 Azureのサービスでいうと、
あたりですね。
ただし、Serverlessは手段(How)の1つに過ぎなく、その場にいる全員で実業務の問題解決に挑むことができるのがMicrosoft Hackfest最大の魅力だと感じました。
今回取り組んだ課題
私達のシステムは、
WebApp⇒CosmosDB
という非常にシンプルな構成です。
スタートアップフェーズでは、変化に対応しやすくコストも安い現在のアーキテクチャはとても都合がよかったのですが、フェーズが変わりデータの集計などが必要になってきたためパフォーマンスを改善しようと思って今回のHackfestに参加しました。
CosmosDBはMongo DB APIなど複数のインタフェースを持っているものの、全ての機能が使えるわけではないのと、機能によっては想定するパフォーマンスが出なかったりします。
基本はKey-Value Storeとして使い、集計などは非同期で予めデータを作っておくか、RDBなど集計が得意なデータストアを使ったほうがよさそうです。
Hackfestの流れ
まず最初に、業務・アーキテクチャ・現状の課題などのコンテキストを共有し、技術的アプローチについてアツい議論をしました。
チームにはりついてくれるエヴァンジェリストの方だけでなく海外から来てくれているスーパーエンジニア達も参加して、我々のシステムについて真剣に考えてくれるというとても貴重な場でした。
ヘタなりに英語でディスカッションしていますが、通訳さんが入ってくれるので英語が苦手な方も安心です。
Hackfest期間中チームごとにMTGルームを貸し切りで使わせてもらえるので、エンジニアリングに集中できました。
私達の普段の仕事のスタイル同様にモブプログラミングを行い、全員で一つの画面を見ながら全員で問題解決に取り組みました。
その時に必要な技術要素に詳しい人を呼んでくださったり、とにかく全員で寄ってたかって問題をフルボッコにしました。
ホントにこんな感じw
3日間の最後に成果発表&ふりかえりをしました。
ちなみに3日間の成果はこんな感じです。
Azure Functionsを使ってデータ分析を非同期に逃してみたんですが、色々ハマりながらも2日間でおおよそできてしまいました。
そこで3日目は別のパターンとして、Data Factoryを使って、CosmosDBからSQL Databaseにデータを同期し、PowerBIでレポートを可視化しました。
同じ問題を解決するアプローチでも前者はコードで解決した一方で、後者はほとんとコードを書かずに実現することができました。
参加してみて
★エンジニアにとって至福の時
3日間缶詰になって、スペシャリストに囲まれてエンジニアリングに集中できる環境は控えめに言って最高でした。
なにより自分がいちばん下手くそでいられる環境というのは、最高にわくわくするし、改めて「エンジニアってたーのしー!」って思いました。
★仕事だから本気
Microsoft Hackfestでは実際の仕事の問題を解決することをターゲットにしてくれます。ワークショップの仮のお題ではなく、普段働いているチームで実際の仕事をターゲットにするからこそ本気になれます。
★クラウド時代の問題解決
今回取り組んだ問題について、自分たちのチームだけで取り組んだとしてもそんなに時間はかからずに解決することはできたと思います。
ただし、今回のHackfestでいろんなスペシャリストの知見をもらいながら、たくさんの選択肢の中からBetterなものを選んで解決することができました。
結果だけ見ると同じように見えますが、そこに至る過程で得られた経験値が格段に違い、チームとして成長することができました。
とくにクラウド時代はたくさんの選択肢があり、知っているか知っていないかでかかる手間も結果も大きく変わります。自分たちの手で地道に解決していくことももちろん大切ですが、時間は有限なのでいかに情報を得ていかに効率的に問題を解決するかという視点もこれからのエンジニアリングには必要な要素だと改めて強く感じました。
コードを書いているだけがエンジニアリングではないですね。
★モブプログラミングの真価
Hackfest✕モブプログラミングは最強の組み合わせだと思いました。
前述した通り問題解決は結果だけでなくその過程で何を得るかが非常に重要で、全員で問題を一つずつフルボッコにしていくモブプログラミングで貯まる経験値はメタルキングレベルです。
モブプログラミングについては以下の資料をどうぞ。
最後に
最後になりますが、張り付いてサポートしてくださったKanio・寺田さん・本間さん・畠山さん。声をかけてくださった牛尾さん。様子を見に来てくださった佐藤(神)さん。レポートしてくれたちょまどさん。そしてそれ以外の皆さんも本当にありがとうございました。
追われる開発と追う開発
2つの開発現場を見てみましょう。
※この物語はフィクションです
開発現場A
ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する。依頼を受けた開発チームは、要件を確認しながら開発計画を立て、数ヶ月にリリースをするスケジュールを組んで、開発を開始した。
ビジネスチームは、開発期間の間にいろんなことを想像し始める。
競合サービスを研究していると不安になり、「あれがないとダメ!」「これもないとダメ!」という気になって、最初の想定よりもプロダクトはどんどん太っていく。
こういう状況で追加されていく要望は当然ながら検証されていない想像=妄想なので、実際にリリースしててもユーザーに使われるかどうかはわからない。 * なぜあなたのチームの プロダクトは太ってしまうのか #postudy // Speaker Deckより
当然ながら開発チームは当初想定していたよりもやることがどんどん増えていく。
- やることが増えても適切に納期が延ばされない
- 既に実装してテストされた後に手を加えることになる
- 影響範囲が正しく理解されないまま変更が加えられる
などの状況が重なると加速度的に開発チームの負荷は上がる。
負荷が上がると仕事の精度はがくっと下がるので、順調にプログラムにバグが仕込まれていく。
度重なる仕様追加を乗り越えて、開発チームはようやくリリースにこぎつけた!
しかし、無理して開発した結果、トラブルが発生する。
苦労して追加した機能は大して使われず、おまけに汚く組まれたプログラムによって変更コストは膨大になり、リリース後の改修スピードもどんどん遅くなる。
そんなことしている間に競合サービスがどんどん出てきて、気付いたらユーザーは誰もいなくなっていた。
Bad End ..
開発現場B
ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する(ここまでは同じ)。
依頼を受けた開発チームは、最初のシンプルなアイデア(その一部)をさくっと作って1週間後に彼らに見せることにした。「きっと後で変わるだろう」と余計なこだわりは捨てて、デザインもコードも最初から完璧を目指さずに、1週間でできる分をシンプルに作っていった。
1週間後に予定通りデモを見せると、「え、もうできたの!?」と依頼をした人達は腰を浮かして喜んだ。実際に動いているプロダクトを見て具体的なイメージができたのか、あーでもないこーでもない議論が盛り上がった。そこで開発チームは、「次はどこを作りましょうか?来週までにできるところまで作ってくるので、またフィードバックを下さいね。」と笑顔で伝えてそのデモMTGは終了した。
それから何週間か同じことを繰り返した。
ビジネスチームは少しずつできていくプロダクトに対するフィードバックをして、次に作ってもらうものを考えて、そのための準備をすることで毎週必死になっている。
一方で開発チームは、開発のリズムができてきたことで、その週に予定している対応分は数日で完了するようになっていた。そこで余った時間で何をするのかをチームで考えることにした。
- 次の機会に使うかもしれない新しい技術検証を行う
- リファクタリングする
- 近くにいる想定ユーザーにプロダクトをさわってフィードバックをもらう
- 環境を整備したり、自動化を行う
毎週何をするかをチームで決めて、プロダクト開発をしながらも改善活動を進めていった。
そしてまた数週間が経った頃、ビジネスチームのリーダーが「もうそこそこ使えるしリリースしてみてもいいんじゃない?」と話したことで、リリースが決まった。
常にリリースを繰り返してきた彼らにとって、リリース作業は自動化されていて、さくっと世の中にサービスが出た。
ビジネスチームや想定ユーザーに何度も触り続けてもらったプロダクトは、致命的なバグなど出るはずもなかった。
また、プロダクト開発を続けながら改善を続けてきたおかげでプログラムもキレイに組まれていて、リリース後もユーザーのフィードバックをすぐに反映してサービスはどんどん成長していった。
Good End ..
考察
いかがでしたでしょうか?
この2つの現場について考えてみました。
一見すると開発現場Aはとても悪い現場に見えます。
でもよく考えてみると、みんなそれぞれの状況の中で精一杯仕事をしているだけであって、誰かが悪意を持ってさぼっていたわけではありません。
それと比べて開発現場Bはとても良い現場に見えます。
しかし彼らは急にチームが成長したわけでも特別なやり方をしたわけでもありません。
優先順位を決めて、自分達ができる仕事量だけ毎週アウトプットして、余った時間を有効に使っていっただけなのです。
ではこの2つの現場の違いはなんなのでしょうか?
本気を出すタイミング
人は動いているプロダクトを目の前にしない限り、本気になれません。
特にプロダクトをつくれない人たちは想像ができないため、ドキュメントや進捗表でいくら説明をしたところで、マジメに聞いてくれるものの本気にはなれません。
一方で開発チームは作っている間、常に本気です。
* JikkanKudo2016_BPStudy // Speaker Deckより
この違いを理解することはとても重要です。
開発チームが本気に仕事を終わらせにかかっている時に、思いつきのアイデアを出していらっとされるなんて話はよく聞きます。
お互いの本気のタイミングを合わせるためには、開発現場Bのように常に動いているプロダクトを中心に仕事を進める方がよいでしょう。
追われる開発か追う開発か
プロダクトづくりというのはクリエイティブな特性を持っているため、開発チームが追われている状況ではあまりよい結果になりません。
開発現場Bのように開発チームに余裕がある状態であれば、先回りをしたり、改善活動をしたり、様々なアプローチをとることができます。
一方でビジネスチームに余裕がある状態だと、想像ができないことが多いので効果的な先回りがしづらかったり、余裕が有ることによる不安や焦燥感によって暴走しがちです。
しかし開発現場Bのようにビジネスチームが追われている状態であれば、優先順位を決めてそれに基づいて開発してもらうための準備に勤しみます。優先順位を決められるのはビジネスチームであり、そのための準備をするという一番重要な仕事にのみ集中する状況を作ることができます。
追われる開発ではなく追う開発を目指したいものです。
「進め方がちょっと違うだけでこんなに大きな差が出るんだなー」って最近モブプロをしながら実感してるよ
なんて話をとある日のランチで社内の若者に話していたので、せっかくなのでブログに書いてみました。
speakerdeck.com 手前味噌ですがこのスライドいいこと言ってるな、って改めて思いました。
タスクボードの改善事例がたくさん詰まった「アジャイルコーチの道具箱 – 見える化実例集」を読んだ #見える化実例集
「アジャイルコーチの道具箱 – 見える化実例集」を読んでみました。 leanpub.com
この本はタスクボードを中心とした見える化のTipsがひたすら紹介されている本です。 Tips集なので前から読んでいく必要もなく、気になったTipsを辞書感覚で見たり、気軽にパラパラめくって読むことができました。
読みながらツイートしていたので、臨場感あふれる感想を貼っておきます。
ボードのリファクタリングってけっこう重要。ずっと同じだと飽きちゃうし、情報量多いと見ないし。ホワイトボード使うと面積という制限があるからいいよね。 "情報がどんどん追加されて、どんどん複雑になっていってしまう" #見える化実例集 #アジャイルコーチの道具箱
— OYB48 (@TAKAKING22) 2016年4月16日
カンバンにないタスクが増えるときはすぐに全員で足すかどうかを決めて、足すときは違う色の付箋orシンボルつけてたなー。計測しておくと振り返りに使える。 #見える化実例集 #アジャイルコーチの道具箱
— OYB48 (@TAKAKING22) 2016年4月16日
これいいね!チームでSprint毎に完了させていく意識につながりそう。モチベーションは計画しちゃダメだけど、バカにしちゃいけないと思うw "デモまで何日は、次のデモの日までのカウントダウンだ。" #見える化実例集 #アジャイルコーチの道具箱
— OYB48 (@TAKAKING22) 2016年4月16日
カイゼンボードいいね!ふりかえりで出たTryをカンバンに張り出してるけど、改善活動もステータスを見える化しちゃえばいいよね。 #見える化実例集 #アジャイルコーチの道具箱
— OYB48 (@TAKAKING22) 2016年4月16日
カンバンやタスクボードを使っているチームは、自分の現場でまわりを見渡してもかなり増えてきた印象があります。
僕はデジタルなツールよりもアナログなカンバンが大好きなので、チームのみんなにもチームで使うカンバンを好きになってもらいたくていろんな改造をしてきました。だから、読んでいて「これやってるよ!」というTipsも「これやってみよ!」っていうTipsもたくさんあって楽しく読むことができました。
ほんとこれ。やっててもやってなくても変わらないならやらない方がいい。 "見える化ボードは生き物だ。それぞれの要素とデザインの価値を定期的に評価して、改善、調整しよう。必要ないなら使うのをやめよう。" #見える化実例集 #アジャイルコーチの道具箱
— OYB48 (@TAKAKING22) 2016年4月16日
とりあえずタスクボードを導入してみるだけでもいいと思いますが、チームの状況や抱えている問題に合わせてちょっとした工夫をするだけでよりチームにとって効果的な見える化ができます。
カンバンは本当に生き物でありナマモノで、正解はないし、銀の弾丸もないので、チームの数だけカンバンがあっていいと思います。最初からあれこれなんでも導入すると失敗するので、シンプルにはじめてチームの成長にあわせてカンバンを育てていくような意識だといいのかなと思ってます。
この本にはカンバンの育て方のヒントがたくさんつまっているので、自分のチームの課題にあったTipsがきっと見つかると思います。
※かつてこんな発表をしたこともありました。
www.slideshare.net電子書籍のみですが、お手軽な値段で手に入るので、暇つぶし感覚で読んでみるといいと思います。 leanpub.com
本の最後に自分の例を書くスペースがあるんだけど、この本を読んだ人が自分達のオリジナルTipsを共有する勉強会とかあったら面白そうだねー!!
【速報】AgileガチンコFight第0試合、西村直人×-○オヨベタカオ(15分23秒 垂直落下式バーンダウン) #rsgt2015 #agilegachi
2015年2月28日〜3月2日に Regional Scrum Gathering Tokyo 2015 が開催されました。
その中で@nawotoさん&@hageyahooさんと【AgileガチンコFight第0試合】というセッションを行いました。
今回のセッションは、プレゼン形式ではなく対話形式で進めるセッションにしました。
なぜそうしたのか。
とある社内勉強会で、現場のリアルな生の話を持ち寄ってお互いに磨き合って次の日からの行動に直結するようなゴールにしたくて、
- プレゼン形式のライトニングトーク
- プレゼンの内容を肴にして参加者全員でフリートーク
という形式でやってみました。
その結果、
現場のリアルな悩みを相談し合ったり、
「うちだとこうやってるんだけどお前のところはどうだ?」とか、
「今度うちのコードレビューしてよ・見に来てよ」とか、
想像以上の場になりました。
これを社外でもやってみたい、というのがきっかけです。
決してプロレスがやりたかっただけではありません!!
大事なことなのでもう一度。
プロレスと同じでエンターテイメント性を大事にしているので、誇張表現があることはご容赦くださいw
AgileガチFight第0試合オープニングムービー
AgileガチFight第0試合 挑戦者オヨベ煽りVTR
AgileガチFight第0試合 チャンピオン西村煽りVTR
第0試合でかつ30分という短い時間だったので、雰囲気を知ってもらうことを優先しましたが、いいフィードバックをいただくこともできました。
Agileガチファイトは熱かったし、実際にその議論の内容も良かった。兼任専任どちらの立場でも、チームの成長に目を向けてる両者の話だった。 #rsgt2015 #rsgt2015a
— さとりゅう (Tatsuya Sato) (@sato_ryu) 2015, 2月 28
ガチファイトとても参考になりました #rsgt2015
— 本間崇(T.Homma) (@takas_ho) 2015, 2月 28
おまけに見事に勝利をおさめることができました!
大事なことなのでもう一度。
おまけに見事に勝利をおさめることができました!!!
そして。
今回の第0試合の経験を活かしてAgileガチFight PRJを始動させます。
AgileガチFight PRJスタート
リアルにリングがある場所を借りて、参加者の皆さんと一緒に全員でより密度の濃い追体験ができるイベントを開催したいと考えています。
ぜひリアクションを下さるとやる気が出るのでよろしくお願いします。
最後になりましたが、イベント関係者・参加者の皆さん本当にありがとうございました。
我々は本当に越境したいのか? #devlove
この記事はDevLOVE AdventCalendar 2014 「越境」の42日目の記事です。
テーマである「越境」について、考えてみた時に浮かんだ疑問について考えてみたいと思います。
コンテキスト
本題に入る前に私のコンテキストを簡単にご紹介すると、
こんなところです。
そんな私のまわりにある境になりそうなものは、
あたりでしょうか。
越境っていいことなの?
ここから本題です。
越境はすごくいいことであると述べられることが多いが、私はそうとは限らないと思っています。なぜなら蛮族(ヒャッハー)でも越境はできます。
越境はWhy(目的)ではありません。
越境はWhy(目的)を達成するためのHow(手段)の1つに過ぎません。
新しい技術を導入することがWhy(目的)になってしまい、本来あるべきWhy(適切な導入理由)や一緒に考えるべきHow(運用計画)が存在せず、おまけに導入した張本人がそのチームを去って残ったのは荒れ果てたシステムだけだった・・・などどいう世にも恐ろしい越境の悪例を私は何度も見たことがあります。
未来がない越境などしない方がまだマシです。
自分勝手とはいえ明確な目的がある分、蛮族(ヒャッハー)の方がまだマシだとさえ感じます。
“なにを為したいのか”と “どうやって為すのか” はセットで考えないと、不幸な未来が待っているのかもしれません。
越境する人たちはすごい人?
とあるプレゼンをした後の質疑応答で、
「チームに変えられる人はスーパースターだと思うのですが、どうやったら私たちもそうなれますか?」
と質問いただき、
「もし自分がスーパースターならアジャイルやチームビルドに興味を持たなかったでしょう。だってなんでも自分でできちゃうじゃないですか。スーパースターじゃないからチームが必要で、サービスにとってチームがアジャイルになることが必要だと思ったからやってるだけです。」
と応えました。
私が知っている越境し続ける人たち(ここではチェンジエージェントと呼びます)だと思う皆さんは、越境しようと思って越境しているわけではない気がします。そもそも境だと認識すらしていないからこそチェンジエージェントで居続けられるのでしょう。
とある施策をチームに取り入れようと考えたときに、反対する上司がいるだろうと思って慎重に変化を進めたらむしろその上司が積極的にサポートしてくれた・・・などという経験が私にもあります。境をつくるのも感じるのもたいていは自分自身の中だけで、本当の境は自分が思っているよりも少ないのだとそのとき気づきました。
もし、なにかやりたいことができない理由を「すごい人」「スーパースター」という言葉に変換しているのであれば、本当にできない理由は自分自身の中にあるのかもしれません。
本当に越境したい?
越境がHow(手段)の1つであるということは、越境しなくてもWhy(目的)を達成する手段はあるハズです。
それでも本当に越境したいのでしょうか?
私はどうでもいいと思っています。
「なにを為したいのか」
「どうやって為すのか」
を考えたときに必要だと思ったことをやってきただけで、今後もそれを続けます。やってきたことが越境だったとしてもそうでなかったとしても、走り続けなければいけません。
そんな想いをこめたのがこのプレゼンテーションでした。
境だと思わなければ、越えることすら越えられる。
越境に夢を見るのはもうやめました。
越境したとしても、境の向こうには世界の続きがあるだけです。
私には行きたいところ(成し遂げたいこと)があるだけです。
自己紹介
最後に自己紹介させてください。
もしこの記事を読んで興味をもっていただけたなら、フォローやメッセージなどをいただけると幸いです。
次回
バトンは志田さんにおつなぎします。
お楽しみに!