つらつらと振り返ります。
習慣化済みのタスクについては特に代わり映えがないので省略することに。
続きを読む
昨日もモブプロやった。
別途振り返りのブログは書く予定だが、チーム外からの参加者からフィードバックをもらえて有意義だった。
継続こそ力。
今プランクの記録に使っているのがこちらのアプリ。
で、実際のプランク中の画面がこちら。
どうしてこうなった……。
AppStoreのスクリーンショットとは似ても似つかぬ姿。
いやまあ、普通にフィードバックして直してもらえばいいんだろうけど、もう半年以上この状況。誰もフィードバックしないのかしら。
プログレスバーとタイマーが重なって表示される以外にも、スタート時の「Ready set go」の音声をオフにする設定がないので音楽とかポッドキャスト聴きながらはやりづらいとか、社内SNSへの結果の共有手順がめんどくさいとか、色々問題はある。
あとは、個人開発のネタ不足もあるので、プランク用アプリを作ることに。
タイマーなんて、適当に、
setTimeout(() => { // do something }, 1000);
とかやっとけばカウントできるのでは?
と思ったが一応「react-native timer」でググる。
なるほど、モバイルアプリだとバックグラウンドに回した時の動作とかも考えなきゃいけないぽい。確かに。
と言うわけでタイマーを使いつつ適当な画面を作ってみた。
1秒ずつ画面の数字をカウントアップしていくだけ。
あとはこれを分・秒単位で表示できるようにしていけば良さそう。
gifアニメ作成には、最初はQuickTimePlayer->Giftedを試したが、
などの理由により、GIPHY Captureを採用。
そもそもこの手のコンポーネントならどこかにありそうな気もするからそれは今度探す。
いや、先延ばしは良くない。今探す。
timerを検索ワードにすると、自作してみた系のブログ記事がヒットしてあまりいい結果が得られなかったが、stopwatchで検索したところこれが良さそうだった。
今週中に乗せ替えよう。
開発中のソースはこちら。
開発を一通り完了してからブログ記事書くスタイルだといつ公開できるか分からないので、できたところからちょっとずつ公開していく。
ちなみに、今日のブログ執筆BGM。
www.youtube.comEricの声が若い。
Mr. Bigはオフィシャルサイトに行くとpowered by Makitaとあって流石。
ドリルいいよドリル。
[2018/02/20追記]
続きを書いた。
モブプロ始めました(真冬)。
2017年の6月頭くらいに、社内SNSでモブプロに関する投稿を見た。
多分シェアされていたのがこの記事だったと思う。
自販機を作る中で、対応して欲しいと言われる要望がどんどん増えていく様は、実際の開発現場での事例をイメージしやすいので、実プロダクト以外でモブプロのテーマにするのに良さそう。
ともかく、上の記事を見て、モブプロをやりたいと思ったので、とりあえず社内SNSに書き込んでは見た。
すると同じように思っていた同僚(全然違う部署、当時は面識なし)から返信がもらえた。ので、いいじゃんこのままやっちゃえ、と思っていた。一応、自販機を作る課題でやるとして、追加仕様をどうする?とチャットで5分くらいやり取りはしたものの、面識がないのが災いしたのか、お互い仕事が忙しいのを言い訳にしていたのか、夏の暑さにやられたのか、6月以降目立った進展はなかった。
とはいえ、モブプロのことは頭の片隅にあって、なんとなくやりたいな、と思っていたある冬の日、何気なく手に取った雑誌の特集記事がモブプロだった。
しかも「はじめての」とある。
これは買うしかない。
読むしかない。
そういうわけで、買って、読んだ。
そうこうしているうちに、Podcastでもモブプロの話題が目につくようになった。
同じくらいに、Speaker Deckで特集記事の著者である及部さんの記事を見つけて、それらも読んだ。
あ、これはやるしかないな、と言う気分が高まってきたのと、なんとか今のチームでモブプロをできそうな雰囲気もあったので、とりあえず初めてみることにした。
初めてみるとは言っても、こっそり初めてこっそり終わっても面白くないので、色々と予防線を貼ったというか、準備をした。
内容としてはこんな感じ。
そもそもチームメンバーには1月頭くらい前からモブプロやるぞ、と伝えていた。
中にはペアプロの存在を知っていて、ある程度は何をやるのかイメージできていそうなメンバーもいた。
一方で、ペアプロも全く知らないメンバーもいた。なので、雑誌記事、ポッドキャスト、スライドシェアなどを参考にしながら、モブプロはこんないいことがある、それを自分は達成したいんだということを伝え、「失敗から学んで強いチームになる」という方向性を揃えるために、資料を作ってLTして、実戦に至った。
やるぞ、と伝えてからそこそこ時間がかかったのは、その間に大きな締め切りがあって、LT資料を作る余裕もモブプロをやる気力もなかったという事もあるし、チームメンバーに自発的にモブプロについて調べて興味を持って欲しいとも思ったからだ(結局興味を持って調べたかどうかは確認していない)。
今になって振り返って見ると、このあたりの行動は『Fearless Change』のパターンに当てはまってるものが多くある。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
実戦投入できたかな、と思えるのがざっとこの辺り。
LTを済ませて、チームメンバーの動機付けも十分にできた(と判断した)ので、場所を抑えて実際にモブプロをやってみることにした。
テーマとして選んだのは、先月のリリース内容について見つかった軽微なバグから始めることにした。該当のバグについての記憶も新しいし、多分1時間くらいで実装からテストまでを完了できるだろうと見積もったからだ。
用意したノートパソコンのネットワークが繋がらないなどのトラブルに見舞われたが、おやつを用意した事もあってか、全体としては和やかに終えることができた。
流れとしては以下の通り。
モブプロ開始が若干遅い時間だったことや、スペースの予約の都合もあったので、あまり長くはできなかったのが残念。初回なので、あまり負担にならないように、という意図もあったので、今回はよしとする。
この部分のFearlessポイントは
あたり。
「失敗から学んで強いチームになる」を目標にしているので、失敗から学ぶべくモブプロの最後に振り返りを実施した。
<Keep>
前提として、新しい製品機能を、新しいチーム(自分以外新人ばかり)で作っているというのがある。そのため、ある程度開発経験のある開発者ならなんでもないと思えるようなポイントでも、彼らにとっては学びとなったようだ。
次は、実際に保守対応をしたり、より意図が伝わりやすい命名のコードを書いたり、学んだことをガンガン実戦投入して行って欲しいと思う。
<PROBLEM>
ドライバの環境については慣れている環境でモブプロできるように、色々と越えるべき壁がある。
つまらなかったという感想は、時間の制約もあったとはいえ謝らざるをえない。次回のモブプロで優先的にドライバをやってもらうこととする。
楽天の事例で紹介されている、小さな成功を祝う「やったー」をできなかったのが痛かった。微妙に実装が終わりきらなかったこと、気恥ずかしさに負けてしまったことが要因と考えられる。次回はこれを確実にやりたい。
Teletypeは、WEB+DB PRESSでも紹介されていたので知っていたのだが、AtomはJavaの開発向きではないのでは?と思ったので今回は外した。そのうち試してみて、Javaでも使えそうだったら、あるいはJavaScriptで開発する案件でちょうどいいのがあれば、使ってみたい。
Teletypeが使えるなら、他のチームの有識者が参加したいと言ってくれているのでできれば積極的に取り入れていきたいところ。
と言うわけで、ここでのFearlessポイントは、
のあたりだろうか。
『Fearless Change』で紹介されている、組織変革の序盤の活動に関わるパターンをある程度実戦投入できた。
↓の記事で掲げた「リーダーとしての実戦投入力を高める」の一環として、まずはこの一ヶ月は順調な滑り出しと言えるだろう。
とはいえまだまだ始まったばかりだし、たった1回のモブプロでめちゃくちゃ強いチームになるなんてことはあるわけがない。
来週以降も継続していく。 すでに社内のミーティングスペースは確保した。