futabooo blog

色々手をつけすぎてすぐに忘れるので備忘録

RSGT2019でスクラムチームをやめて20人でカンバン運用してきた半年間の軌跡というタイトルで発表してきた

RSGT2019で発表してきました。

2019.scrumgatheringtokyo.org

発表資料がこちらです。

20分枠だったのですがおよそ150ページの資料を作ってしまい、前半部分を高速でポチポチしてサマリーを喋るだけにとどまってしまいました。 Twitterで資料公開のつぶやきをしたところ自分史上では中々の数のFavをいただいているので、需要があると感じたのでカンバンをつくる際にInputになった資料をまとめてみようかと思います。

カンバン仕事術

カンバン仕事術

カンバン仕事術

カンバンの原理原則、WIPの制限について学ぶことができます。また本書の後半にはカンバンの理解を深めるためのワーク例も記載されているので、チームに広めたい場合に引用するのにも大変役立ってくれました。

カンバン始めたいと思ったらまずこの本を読んでおけば問題ないと思います。私自身初めて読んだ時は当時同僚として働いていたkajinariさんにお借りして読みました。そのあと手元に置いておきたくて自分でも買いました！

リーン開発の現場

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

スウェーデン警察におけるとても大きなプロジェクトの事例をもとに、どのようにカンバンとリーンの原則を適用したかかを紹介しています。今回の私の発表とはまた違いますがそこには確かに現場があって戦ってきた人たちがいます。

アジャイルコーチの道具箱 – 見える化実例集


アジャイルコーチの道具箱 – 見える化実例集 すごいチームはどう見える化している？
作者：Jimmy Janlén and 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也


96個の見える化の実例が載っています。発表の中で話したパーキングロットはここからのアイデアでもあります。カンバン上でやっていたことに名前がついていたのか！と確認できたりもしました。

かんばんとスクラム 両者のよさを最大限ひきだす

www.infoq.com

発表の通り、Pairs事業部ではスクラムをやめてカンバンへの移行となりました。スクラムとカンバンの比較を通して活かせる部分異なるので気をつける部分などを把握するのに役立ちました。

タウンワークをドライブさせるためになんちゃってアジャイルをやめた話

リードタイムの計測に関してものすごく参考にさせてもらいました！カンバンの手戻りをどうやって計測するか？見えるようにするか？ということが解決できました。

おわりに

自分がアジャイルとかスクラムとかカンバンとかに興味を持って、よちよちあるきでもやってこれたのは@kajinariさん@yohhatuさんのおかげです。この記事や発表のスライドがどこかの誰かにとってやってみよ！となるなにかになれれば良いなーと思います。

質問とかあれば @futaboooまで！

2018年の振り返り

新年明けましておめでとうございます。

振り返り記事を年明けになって書き始めました。

一年間を思い出すのに今回は流行り（？）のTwitterで振り返るっていうのをやってみました。 次のような感じでTwitter検索すると1ヶ月ごとの自分のツイートを振り返ることができます。

from:[your account name] since:2018-01-01 until:2018-01-31

2018年1月

冬休み全然冬休みしてなかったようです。なにやってたのか全然思い出せません。他の1月のツイートを見てもまったく思い出せません。2019年の冬休みも今の所冬休み感がまったくありません。年明け1週目に登壇が控えているのでその発表資料づくりに追われています。

2018年2月

2月はいくつかトピックがありました。

DroidKaigiで話せなかった話を勉強会で話しました。Androidアプリが無いWebサービスを使っていたので、自分でスクレイピングしてAndroidアプリを作った話です。その2ヶ月後ぐらいに公式Androidアプリがリリースされたのでモチベーションが一気になくなりました。

作ってたアプリ play.google.com

DroidKaigi2018では企画スタッフとしてコードラボやアフターパーティーでの登壇者への風船の準備などしていました。コードラボではピアノを作るツワモノがいて驚きましたｗ

DroidKaigiといえばカンファレンスアプリがOSSとして公開されるています。私が実装したセッションアンケートでのバグが当日発見されるなどしていて本当に申し訳ない気持ちでいっぱいでした。見つかってから修正されるまでのスピード感にも驚きました。

2018年3月

ペイモガールが会社に来てくれていました。僕は会えなかった。残念。（ツイートではPaymoになってますがpaymoが正しい表記です）

技術書典4へ参加が決まって、初の同人誌執筆をしていました。

Androidエンジニア デザイン部#1に参加して懇談会で話していた内容をツイートしたら100Fav超えしてビビってました。

nohana.connpass.com

2018年4月

DroidKaigi2018でAndroidThingsのチューターやっていたつながりで、別のイベントでもチューターとして参加してました。

技術書典4を無事に終えることができました。初めての同人誌、でもたくさんの人が巻き込まれてくれて最高につら楽しいイベントでした。

会社ではスクラムチームからチームの形を大きく変え、カンバンの運用を始めた頃でした。振り返るとこのあたりからチームや組織、プロセスへの興味がましてきてように感じます。

2018年5月

引っ越しました。

Kotlin！！！

2018年6月

月1でやってたもくもく会の日がサッカー代表戦だったので、途中で切り上げて参加者のみなさんと寿司食いながら見てた。

チームの開発スタイルについて話しました。今では全社的にペアプロ・モブプロという選択肢が普通になっています。

2018年7月

チームワーク賞をもらいました。クラッシュフリー率の改善に注力していた時期です。

会社のイベントで話しました。このときはデザイナーとエンジニアで一緒に話した。参加者も両職種で、普段参加するエンジニア向けイベントとは違った側面での開発プロセスの話などができて大変良かったです。

月イチぐらいでやってるゲーム会。このときはまだWiiのスマブラだったような気がします。

2018年8月

疲れてきた。

3月には単に参加者だったAndroidエンジニア デザイン部の第2回で登壇してきました。

この記事を読んでから、ほんとうの意味で全体最適に達することは難しいので個別最適を積んで改善していくしかないという思考になるようになった。

サマソニにPairsがスポンサーしてました。

いざ読んでみると恥ずかしいですね。

また行きたい。

2018年9月

こんなこともありましたね。

4系の呪縛から解き放たれた瞬間。

実は3月ごろに一度落として修理してたのをまた落とした。

2018年10月

春に参加した技術書典4に続き、秋は技術書典5にも参加してました。この時は合同誌をやめて、1人1冊だす方式だったので１人のボリュームが多くて割と苦労しました。

多分スクラムにおけるベロシティの話してる。同じ時間でより遠くに行けるのは短距離走の選手よりマラソン選手だよねって話だと思います。

2018年11月

実はアワードにPairsで登録したけど選ばれませんでした。最後にいくつかデザイン調整したけど、長期でしっかり腰据えてやりたい。

matching-dev-group.connpass.com マッチングに特化したAndroid・iOSの勉強会で当日飛び込みLTしてきた。

認定スクラムマスター（CSM）になりました。

2018年12月

大変です。

今年はアドベントカレンダー2つ書きました。

2018年最後のツイートはごはんに迷ってました。結局何を食べたのかは思い出せません。

総括

2018年は会社としては組織体制が大きく変わり、個人としてもその変化に対応して振る舞いを変えた1年となりました。エンジニアとしてコードを書く時間よりもチームや組織やプロセスに対して思考する時間やアウトプットする時間の割合が大きくなっていきました。コードによるアウトプットと違い、自分のアクションからのフィードバックが来ないことや遅いことも多く、今自分がやっていることはなぜやっているのか？本当に意味があるのか？自分のためになっているのか？今後のキャリアは大丈夫なのか？と様々なことに不安になることも多くありました。それでも会社の締め会では2018年のMVPをいただくことができ、やってきたことを認められたことで悪くない１年だったなと感じています。 f:id:futabooo:20181220161033j:plain

2019年も引き続き不安を抱えたままだと思いますが、自分のペースでやっていきたいと思います。

ペアプロ・モブプロを広めるのに役立ったControl Chartの使い方

この記事はAttlassianAdventCalendar2018の8日目の記事です。

こんにちは！ この記事では以前発表した資料（モブプログラミングという開発スタイル、あるいは生産性について）を参照しながら、ペアプロ・モブプロとはどんなものか、なぜ有効な開発スタイルなのかを説明するとともに、株式会社エウレカ内でペアプロ・モブプロを広める際に役立ったJiraのReportの1つであるControl Chartについて紹介します！Control Chartの説明だけ見たいんじゃい！という方は目次から飛んで飛ばして読んでいただくこともできます。

目次

  • ペアプロとは
  • モブプロとは
  • ペアプロ・モブプロの経験がない人からよくある質問
    • 複数人で同じことをしていては生産性が下がるのでは？
    • 参加者にスキル差があるとうまくいかないのでは？
  • JiraのControl Chartとは
  • 新しいことを始めて運用に乗せる時の勘所
    • 定量と定性で示す
    • 繰り返し示す
  • おわりに

ペアプロとは

ペアプログラミング（英: pair programming）は、2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法である。

wikipediaによると上記のように定義されています。 ペアプログラミング - Wikipedia

もう少し具体的に噛み砕くと同じ仕事を同じ場所で同じ時間に同じコンピュータを使って作業するのがペアプログラミングです。この条件はモブプログラミングでも同じです。

モブプロとは

ペアプロを2人から人数を増やして3人以上で作業することをモブプログラミングといいます。手を動かしてコードを書いている人以外の人数が増えることになります。 下記はモブプログラミングを複数のチームで行っている様子を動画に収めたものです。

ペアプロ・モブプロの経験がない人からよくある質問

複数人で同じことをしていては生産性が下がるのでは？

生産性とはなにか？というところでも議論が分かれそうですが、ここではある開発タスクに着手しfeatureブランチを切ったところからmasterブランチにマージされるまでの時間とします。 2つの開発タスクがある場合に、ペアプロやモブプロで複数人で1つずつ片付ける場合と2つの開発タスクを同時に別々の人が進める場合にどちらのほうが時間が短くなるでしょうか。 それぞれの開発を1人でやった場合とペアプロで片付けた場合、かなり単純化していますが下記のようにペアプロでやったほうが時間が短くなります。 f:id:futabooo:20181207115747p:plain

参加者にスキル差があるとうまくいかないのでは？

経験豊富でスキルを持ってる人からするとペアとなった相手に知識を伝えることが多くなり、退屈だなーと感じる人も中にはいるかも知れません。 しかしペアの相手が知識をつけて成長していくことで中長期的に見ればチームの総合力が上がっていくことになります。 そうすれば将来の自分が助けてもらえるようになることもあるかもしれません。 以前ペアプロ・モブプロについて発表した時の感想でも良かったという声が届いていました。

やったことがないことに対してやらない理由を探すよりも、まずはやってみてアリかナシか判断してみても良いのではないでしょうか。 （AttlassianAdventCalendarなのにここまでペアプロ・モブプロの話しかしてない）

JiraのControl Chartとは

ここからが今回の本題です！ Control Chartとは特定の期間において、あるProjectのチケットがそれぞれどのぐらいの時間で完了したのかとその平均を見ることができる図です。

これまで説明してきたようにペアプロ・モブプロはチームに取って良いことがたくさんあります。 チームがやる気になってもステークホルダーや関係者からは疑問の声が上がるかもしれません。

今では複数のチームでペアプロ・モブプロが当たり前になってきたエウレカ社ではありますが、導入に際して役に立ったのがJiraのControl Chartです。実際に触って見てもらうことが一番の理解の近道だと思いますが、ここでそれぞれの表示の説明をしたいと思います。 全体としての図の見方は右上を読むとわかります。 緑の円や点はJiraのチケットを表しています。点になっている場合は同じぐらいのサイクルタイム1のチケットがまとまりとして表示されている状態です。 赤い線はこの緑の円や点が表しているサイクルタイムの平均、青い線が直近数チケット分の移動平均となります。 f:id:futabooo:20181207121625p:plain

サイクルタイムを測りたい期間を設定するのは画面中央下にあるRefineReportの部分を調整します。画像ではTodoに入ってからInprogressを出ていくまでの期間を指定している状態です。 f:id:futabooo:20181207140925p:plain

以前モブプロについて発表した時点での私達のチームでは下記のような状況でした。 少し見づらいのですが4月からモブプロを導入し、青い戦の移動平均が小さくなっていることが見て取れます。モブプロによってチケットの完了までのサイクルタイムが短くなったということです。

このあとのスライドにもありますがGithubのCode Frequencyはモブプロ開始後のほうがむしろ上がっており、作業量自体も向上しています。

このように定量的にモブプロの有用性を示すのにJiraのControl Chartが大変役立ってくれました。

新しいことを始めて運用に乗せる時の勘所

モブプロに関わらずチームになにか新しい仕組みややり方を導入する場合に以下の2点を意識するようにしています。

  • 定量と定性で示す
  • 繰り返し示す

定量と定性で示す

今回のモブプロ導入にあたってはControl Chartを使った定量的な説明と、実際にモブプロしているチームに体感でどう思ったか？というのを聞いたりした上で社内でもモブプロのススメとして話をしたりしていました。 今ではたくさんのチームがコーディングをペアプロやモブプロでやっています。最近ではバックオフィスチームやプロダクトマネージャチームでナレッジを持った意図と一緒にペア作業している姿も見かけます。

繰り返し示す

モブプロ導入においては私達のチームよりも前に実践していたチームがいました。彼らも社内へ発信してくれていました。 個人の習慣を作るのと似たように、チームに新しいことを初めて定着させるためにはめんどくさいやつだと思われても繰り返しなぜやるのか・なにが良いのかを示し続ける必要があります。

おわりに

社内にペアプロ・モブプロを広めるのに役立ったControl Chartの話をしました。 ControlChat以外にもJiraのReportsにはチームがうまくやれているか？を定量的に見せてくれるものがたくさんあります。 メトリクスを取る目的をはっきりさせた上で、今後もいい感じに使っていきたいと思います。

  1. サイクルタイム：Control Chart上ではJiraの特定のカラム間に入ってから出ていくまでの期間↩

ConfEngineでプロポーザル出す時にSpeackerDeckの埋め込みでハマった

雑記

RSGT2019にプロポーザルを出しました。 confengine.com

RSGTではConfEngineを使ってプロポーザルを提出することができます。 confengine.com

このConfEngine、Slideや動画を乗せることができてなかなかに便利なのですがSpeakerDeckの埋め込みをしようと思った時にやり方わからなかったのでメモです。 埋め込みがうまくいくと下記のような感じでSpeakerDeckのSlideが表示されます。 f:id:futabooo:20180919132427p:plain

プロポーザル編集画面でSlideのところにリンクを入れるわけですがこのリンクをひと手間かけてつくります。 SpeckerDeckの載せたいSlide画面を開き、右下のシェアっぽいアイコンを押すと何やらダイアログが開くのでEmbedを選択し、Copy embed codeします。 f:id:futabooo:20180919140824p:plain

このようなscriptがコピーされるので、このなかのdata-idのみをコピーしなおします。 下記の場合c2036ff0d97140eebd736a8e017ff00eの部分です。

<script async class="speakerdeck-embed" data-id="c2036ff0d97140eebd736a8e017ff00e" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

あとは//speakerdeck.com/player/[your data-id]?feature=oembedの[your data-id]の部分を先程コピーしたdata-idに書き換えたリンクをプロポーザル投稿画面で入れてやることで、最初のような形で埋め込むことができます。

最近の自分が興味あることとかそのへんの話

雑記

2018年6月現在、僕は株式会社エウレカで働いています。 最近自分がやってることや興味があることを書き出してみたいと思います。

UI/UXおよびデザイン

自分はAndroid開発が得意です。 一時期サーバーサイド開発をやったりもしましたが、あくまで当時のドメイン知識の範囲であれば新規開発や保守運用もできたなーと感じています。

medium.com

WantedlyやLinkedinなどでサーバーサイドのお声がけをいただくこともあるのですが、期待されているアウトプットは現時点では出せないと感じています。 とはいえ状況によってはそんなこと言ってないで必要なことはなんでもやるぜ！というスタンスですが。

そんな自分が最近思っているのはAndroidエンジニアとしてクライアントサイドをやっている以上、UIをメインの戦場として戦っていきたいということです。 大規模開発での設計の重要性を認識した上で、自分としてはよりUI実装を得意とした方向に進みたいなーと感じています。 その上でアルゴリズムなどを必要があれば学ぶというスタンスです。

そういえば、もうすぐマテリアルデザインアワードのノミネートが締め切られますね。Pairsでノミネートしたいと思っています。

まとめると、UX向上においてユーザーのUX向上をUIを通じて改善することにより価値をおいている状況です。

チーム開発

今年はRSGT2018にも参加しました。 2018.scrumgatheringtokyo.org

エウレカでは全社的なスクラム開発を経て、事業部全体のカンバン運用に入っています。

medium.com

自分としてはその中でカイゼン委員会に入っていますが、そこの経験からチーム開発やプロセス改善に興味をもっています。

チーム開発って奥が深いです。 暴論ですが、タスクを1人1つこなしている状況はチーム開発とはいい難いと感じています。 このあたりの考えについては別の機会でアウトプットしてみたいと思います。

DApps

ブロックチェーン技術は注目しています。 既存の中央集権的なサービスを置き換えるまでに行く状況というのはまだ先の話かなーと思いつつも、未来はわからないのであっという間に変化の波が来るかもしれません。 この辺の動きは注視しつつ自分の行動はすばやくしていきたいと思っています。

この記事はめっちゃ良かったです。 記載されている本は買って読んだし、Blogは購読するようにしました。 blockchain.gunosy.io

コミュニティとしてはこの辺はwatchしています。 blockchain-tokyo.connpass.com

neutrino.connpass.com

まとめ

情報は発信すると集まるの法則を信じています。 自分が興味あることをこのように書いてみることで、同じように興味ある方からの反応をいただけると最高だと思います。 そして反応してくれた方との議論や対話を通じて自分をアップデートしていきたいなーと思っています。

個人開発のアプリをなんとかリリースまで持っていけた理由

雑記

はじめに

今年の個人目標として技術書以外の本を40冊読む！というのを立てたことをきっかけに本を読むようになってきたのですが、 本を読み続けるモチベーションとして、何か記録をつけるサービスを使って行きたいなーと思っていた時にいくつか選択肢がありました。

その中でも僕が選んだのが今回非公式クライアントAndroidアプリを作った読書メーターです。 良かったのは本ごとに一緒にメモが残せる点と、グラフや数字でどれぐらい読んでるのか見ることができる点です。 bookmeter.com

でも残念なことに既存のAndroidアプリは非公式で、更新も滞っていました。 そこで、無いなら自分で作ってしまおう！と思って開発をはじめました。 実際に開発しているのがこちらです。 play.google.com

リリースまで開発を続けられた理由

①自分が使いたいこと

一番はこれです。個人開発は納期も無いし必要に迫られることが無いと感じていましたが、自分で使いたいから早くほしくて手が動くという感じでした。 リリースしたこれからは自分以外のユーザさんも出てくると思うので、そのあたりも今後はモチベーションになっていきそうです。

②競合がいること

最初に上げた既に存在していた非公式Androidアプリがなかなか良いダウンロード数で1万〜5万という表示がされていました。 更新が滞っていたので自分が新しいモダンなものを作ることができれば、同様のダウンロード数ぐらいまでは行けるのではと考えていました。 勝手に競合だと思って、勝ちたい！と思って開発が進んだと思います。

③MVPを意識すること

MVPとはMinimum Viable Productの略で最小の労力で最大の効果を得られる機能に集中して開発していくって感じの理解です。 開発をしているとあれもこれもやりたくなってきて、いつの間にか何作ってるのかわからなくなって来るパターンもあると思います。 そんな時はこの機能は絶対ないとだめ、これはあったら嬉しいけどなくても困らないなど自分の中で作るものと作らないものを分けて開発を進めました。

おわりに

いったん自分が欲しい機能は作れたのでこれで読書も捗りそうです。 読書メーターにはSNS的要素もあったりするので、よければ一緒に読書していきましょー！ futabooo - 読書メーター

Scrum Masters Night! に参加してきた

雑記

最近スクラムマスターとしてお仕事するようになったので、色々吸収したいと思って第16回 Scrum Masters Night!に参加してきました。 smn.connpass.com

Scrum Masters Night!とは

Scrum Masters Night!はオープンスペーステクノロジーで運営されており、参加者同士のディスカッションを通じて、スクラムを実践する上でぶつかった課題や疑問に対して解決のヒントを得ることを目的としているイベントです。 参加者の中からファシリテーターを募集するので、スクラムマスターにとって重要となる「ファシリテーション力」を鍛える事が可能です。 僕は初参加でびびってたので、ファシリは遠慮しておきました。

オープンスペーステクノロジー

スクラムアライアンスが主催する「Global Scrum Gathering」でも活用されている、会議運営の手法です。 会議の参加者が、解決したい問題・議論したい課題を持ち寄って小グループでディスカッションを行います。ファシリテーター役の参加者が、ディスカッションを促進します。 また、会議の参加者は、 The Law of Two feet（2本足の掟） に従って行動します。

The Law of Two feet（2本足の掟）

会議に出席すると決めた場合、参加者はそこで、「学習する」か「貢献する」か、どちらかをしなくてはいけません（これを徹底するには、かなりの努力が必要です）。 もし、議論の場にいても学ぶものがなく、貢献もできていないと感じたなら、参加者は席を立って、2本の足でその場を離れ、2つの行為のどちらかができそうな別の場所を探す責任があります。 同じ会場の中の、別の課題を話し合っているグループに移っても良いし、休憩所に行っても良いのです。

参加した議題

スクラム開発における品質管理に参加しました。 学習or貢献できないと思うタイミングが無かったのでそのテーブルから動かなかったので、１個しか話してません。でも濃かった。

ファシリテーター役の方が最近個人的に聞いていたポッドキャストのオーガナイザーの方だったのでテンション上がりました。 初対面だけど適度にパーソナルな突っ込んだ話とかもして場をつくるのうまかったなーという印象。

議論中はこんな感じでテーブルにシートがはられててファシリ役の人がメモっていっていた。 書き出すのは問題対私達にできるのですごくよいなっておもった。ファシリテーション・グラフィックとかで調べると出て来る。 f:id:futabooo:20170614212706p:plain

缶ビールとかが写ってますが、飲食に関しては、BYOB（Bring Your Own Beverage/Beer/Booze）形式で自分でのみものとつまみをもってくるっていうかたちでした。

品質管理は組織構造でうまくいったよー的お話聞けたのですごくよかった。 ここでも思ったのは戦術は戦略が間違ってたらダメだからもっと戦略から考えられるようにならないとなってこと。