リモートでのモブプログラミングの紹介
リモートチームでモブプログラミングを導入してみてうまく動き出したので、ご紹介したいと思います。モブプログラミングの記事は多いけどリモートでの記事はまだ少ないので何かしら、感じ取ってもらえると嬉しいです。最初に言っておきますが、チームの数だけモブプログラミングの形はあると思うので、参考程度に見てください。
(読書メモ) モブプログラミング・ベストプラクティス まとめ・感想 - だいごろうのブログ
モブプログラミングとは
モブプログラミングとは、１箇所にチームで集まり、１台のPCを用いて、複数に同じ課題に取り組む手法。少しだけルールがあります。
- 基本は役割が２つあり
- ナビゲーター：問題に対し、考え、意見し、タスクの解決のために全力を注ぐ人たち
- ドライバー：別名タイピストであり、キーボードを触る唯一の人。ナビゲーターの意見に対し、手を動かす人。
- ドライバーの人は短いサイクル（１５分とか）でローテーションする。
基本的には、これだけです。このブログが非常によくまとまってると思います。 medium.com
リモートのモブプログラミングでは、このブログが非常に良い。 www.remotemobprogramming.org
リモートにモブプログラミングは向いているのか?
この議論は非常に重要な部分だと思います。
どのモブプログラミングの本などを見ても、前提条件にチームが１箇所または１部屋に集まれることということが必ず書いてあります。これはメンバー全員が１つのタスクに集中するため、邪魔を極力減らすためなど、重要な要素です。では、リモートで、ビデオ会議で同じような環境を再現できるのか。ここができなければ、モブプログラミングの恩恵を受けることが難しくなるでしょう。
僕が導入しようと決意した経緯
リモートチームで仕事をしていると、チーム全体で知識共有やコミュニケーションがすくなることが課題となってくる。モブプログラミングの良いところは、全員でタスクに集中し、知識や手法などをオンタイムで共有しながら、お互いをより深く知ることができる点であるので、リモートチームこそ、モブプログラミングなどを用いて、より密にチーム作りをする必要があると思っている。もちろん、チャットなどでもそういったことは可能だが、やはりまとまった密な時間はその恩恵を何倍にも増やせると思っている。また、リモートだとチームメンバー同士のコミュニケーションが疎かになることがあるので、全員がお互いを”知っている”と実感するのに１役買うと思う。
僕たちのリモートモブプログラミング
リモート
リモートチームでは、チームコミュニケーションをいかに補うかが非常に重要となってくる。そのため、こういったことを意識しなければいけない。
- コミュニケーションの量を増やせるようにすること
- お互いに干渉するのを苦に思わないように状況を整理すること。
- 情報伝達を行い認識合わせを行うこと。
- ありがとうとごめんなさいを伝えること
ちなみにリモートは場所にいるメンバー限定ではなく、仕事を一緒にしたいメンバーでチーム構成できるのですごく良いです。
リモートで１箇所に集まる
ビデオ会議をするアプリというのは最近多くなっています。それらを利用して、できたらカメラでお互いの顔を見ながら会話できる状況を作ります。顔を見ながら話すことはコミュニケーションにおいて非常に重要です。顔が見えたら、モブプログラミングに集中してるか一目瞭然ですし。
ドライバーとナビゲーターをローテーションすること
これがモブプログラミングの基礎だが、意外とこれが難しい。作業に集中してると時間が経つのは早すぎる。 まず、リモートだとローテーションの時間が来たことを全員が周知することを時計などで知らせるのが意外と難しい。時間を管理する人を作ってもいいが、それ自体がその人のモブプログラミングへの集中力を下げてしまう。また、口頭で「時間だよ」っと言っても、「すぐ終わるから、ここまでやらせてくれ」っと言うメンバーがいる、それに「すぐ」には終わらない。 解決策としては、ツールを導入すると良い。チームではmobsterを使ってる。時間を測り、全画面を強制的に mobsterの画面にしてくれるし、ローテーションも管理してくれる。「だれかが、時間だよ！」っていう心理的に大変な作業を代わりにやってくれるし。画面が強制遷移すると、あ、交代だって全員思う。これを導入してから、みんな時間を守れるようになった。
Mobster - Pair and Mob Programming Timer for Mac, Windows, and Linux
リモートコントロールを利用したローテーション
リモートのモブプログラミングをしている人の多くがgitにpush/pullして、コードをドライバーから次のドライバーへ継承していくことが多い。しかし、このやり方は交代時のオーバヘッドがあるし、gitの問題によって時間をロスすることが多々ある。（gitになれない人が間違えて、他の修正をコミットしちゃったり）。また、作業時のコード以外のターミナルのログやブラウザの状態は、失われてしまう。 そこで僕たちはzoomのリモートコントロールを利用している。一人のPCをマスターPCとし、全員がそのPCとZooｍでVideo会議をする。で、作業はそのマスターPCで行い、ドライバーのローテーションに合わせてリモートコントロールを権限を移していく。こうすることで、作業中のすべてを次のドライバーへ引き継いでいる。
＊ちなみに、過去にslackがscreenheroという会社を買収し、screenheroのリモートコントロールの非常に優秀な機能を取り込んだが、複雑でメンテナンスが難しいという理由で機能の削除をした。なので、今はZoomを利用している。
Removal of remote screen control in Slack Calls – Slack Help Center
振り返り
この振り返りは非常に重要である。リモートチームではチームのコミュニケーションが密になる場面が足りないことが多いので、モブプログラミングをするとチームの問題点が浮上することがある。しかし、それはタックマンモデルの混乱期に差し掛かったといういい状態なので、ちゃんと振り返りをしチームでそれを乗り越える良い機会である。
タスクの選定はメンバーと共に。
リモートのモブプログラミングのタスク選定は慎重にメンバーと共にやったほうが良い。選び基準としては
- 全員の学習となるようなタスクである
- 全員に恩恵のあるようなタスクであるとなお良い。 また、この利用としては
- リモートでのモブプログラミングだと、それぞれ１台ずつPCを持っていることになるので、モブプログラミング中でも別作業ができてしまう。それは人の心理なので止めれないので、できるだけ全員がモチベーションが高いタスクでないと行けない。
- また、リモートでのモブプログラミングは非常に貴重な時間なので、お互いに学習になるようなタスクを選ぶことでコミュニケーションの量を蜜にし、無駄な時間を使わないようにする。
- 自分たちで選んだほうが楽しいし、より技術的なことをタスクにしやすい。
疲れることを認知する
ビデオチャットでの共同作業も、モブプログラミングも疲れる作業だ。なので、定期的に長めの休憩時間を儲けよう。リモートだと、メンバーがつかれたタイミングを知るのが難しい。あと、コーヒーのおかわりほしいし。 あと、なれない頃は長すぎるモブプログラミングは控えましょう。それだけで、モブプログラミングが苦痛なイメージになってしまうので。
素人やエキスパートのどちらでもが安心して意見できること
リモートかつモブプログラミングだと、意見を言うことに対しての敷居が上がってしまう。なので、モブプログラミングの目的は、作業を進めることだけでなく、メンバーの全員の成長も含まれていることを周知します。エキスパートに先生になってくれとお願いし、素人の意見にはまず意見を言ってくれたことに感謝する。つまりは、心理的安全性のコンセプトを理解することは非常に大事だ。
場所にこだわらない
モブプログラミングの難しい理由の一つは、定期的にメンバー全員が集まれるスペースを用意し、大きなディスプレイを用意することである。しかし、リモートの場合、ビデオチャットのアプリがあれば、ほかは何もいらない。特にMTGルームを確保するのが大変な会社だと、これは大きな恩恵になる。
より実験的に。
モブプログラミングの導入自体が実験的であるのに、リモートチームでモブプログラミングをすることはより実験的であることをメンバーにも上司にも通知しておくことが非常に大事である。そのため、メンバーからのフィードバックは定期的にたくさんもらって、常に自分たちに合う方法にたくさん改良したほうがいい。
お互い信頼すること
最後に、もっとも重要なことだが、リモートチームであること、モブプログラミングをすること両方とも信頼関係を気づくことが大事である。なんでも意見を言い合って、いけるように頑張ろう。
最後に
リモートチームでは、どのようにチーム作りをしメンバー同士の関係性を向上させるかが非常に重要になってくる。お互いを信頼し、顔が見えない中でも、コミュニケーションを取らなければいけない。モブプログラミングは、それらを改善するのに非常に重要なやり方だし、僕らのチームでも上手に作用しているし、メンバーの成長とチームの成熟に貢献していると思う。
最後に、Googleが提唱しているReWorkの「イノベーションが生まれる職場環境をつくる」の中で、コラボレーションについての記述について紹介したいと思う。
つながりとコラボレーション - 従業員が仲間を見つけやすく、協業しやすい環境をつくる。
Google re:Work - ガイド: イノベーションが生まれる職場環境をつくる
ベテラン、新入社員問わずいろいろな人とつながりを持ち、アイデアを出しやすい、成熟させやすい環境を作ることはイノベーションを生むことに繋がる。 モブプログラミングはリモートチームで、チーム内での関係性を向上させ、より面白いイノベーションを生むために非常に強いツールだと思っている。なので、もっとモブプログラミングを楽しく実行していければ、ビジネス価値やアイデアも生まれるのではないかと思っています。リモートでもそれは大丈夫です。
これからも、どんどんリモートでもモブプログラミングを実験していこうと思います。
ハッピーモビング！！
(読書メモ) モブプログラミング・ベストプラクティス まとめ・感想
読んだ本 books.rakuten.co.jp 英語版 learning.oreilly.com
モブプログラミング自体はこのブログがよくまとまってると思います。 medium.com
全体のまとめ
モブプログラミングへの感想
チームのコミュニケーションとスキルシェアリングを主として、モブプロを導入したいと思って、いろいろと調べてたらこの本がおすすめされたので、読んでみた。 実際にこの本を読みながら、チーム内で、モブプロを導入してみた。今、リモートチームということもあり、この本通りにいかないことも多くあったが、考え方自体を理解していれば、それに伴って、自チームのオリジナルのモブスタイルが生まれてきて、なかなかおもしろかった。リモートモブワークのことについてはまた、別の機会にブログにしたいと思う。あと、モブ自体は今の所うまくできており、ナリッジシェアリングやコミュニケーションの増加につながっている。フロー重視の開発に対し、正しい理解をして、なんのためにこれを導入するかを考えることが非常に重要だと思う。
本の感想
モブプログラミングとは、なにか、メリット・デメリットはなにか、導入と継続はどうするか、より効果的にモブするためにはどうするか、などに焦点をおいて、無駄な情報はなく、シンプルなので簡単に理解できるいい本だった。著者の経験や、解決策なども盛り込まれており、非常に参考になる。また、エンジニアチームという観点からもこの本は良い切り口を書いており、チームの育成を考えると、もう一度、必要なときに読みたい本。
どういった人におすすめ
今後、誰かに本を紹介するときのために、ちょっと、まとめてみる。
チームに所属していて、こういった悩みやモチベーションがある方
- プルリクのレビューが遅い、リリースまでのサイクルが遅い
- チームでスキルセットが偏ってる、スーパースペシャリスト様がいる
- ペアプロがうまくいかなかった、モブプロを導入したがしっくりこない
- タスクの終わり方がゆるゆるとしてる
- モブプロに興味がある
- 新しいことをしてみたい、チャレンジングなチームだ
- 知識をシェアする時間が非常に長い、同じことを毎度新規の人に説明してる
- 組織でのチームビルディングにコーディングが使える
印象に残ったこと
モブプログラミング
- いくつかベストプラクティスな話があるので、まずはそれに準拠するといいかも、で必要に応じてチームで変更していく。
モブプログラミング導入の仕方
- 最初は実験として導入
- 最初の何回かは必ずレトロスペクティブ
バットマン制度
- 名前がいいよね
- モブプログラミングを止める割り込みを止める人
- 他でも使えそうな考え方
- 割り込み自体を止めるスキルをシェア
タックマンモデルとモブプログラミング
- もし、モブプログラミングを初めて、問題が出てきたら、それは表面化しただけなので（幸いなことに）、良いことだ。タックマンモデルで言う混乱期。
フロー重視の進め方
- 自チームがリソース重視だったので、非常に参考になる考え方。全部フロー重視でタスクしなくとも、フロー＋リソース重視でより効率的に育つチームを作れる気がする。
フローを維持するために
- 場所を確保
- 邪魔を減らす
- みんなが違和感ないキーボードとエディタ
採用面接にも役に立つ
- １，２日短期採用期間を設けることが可能なら、モブプログラミングすると良いかも
- １，２時間ならペアプログラミングするのもありかも
こんな感じかな。チームで今、週１のモブプログラミングをしてみているので、また、それをベースにブログを書きたいと思います。それについて、まとめました。ぜひこちらも、読んでください。
katacodaでLearn Kubernetes ver1 Clusterの作成/コンテナの立ち上げ/pod,deploy,service
katacodaで kubernetesの勉強をしていきます。このページはメモ。 www.katacoda.com
Launch A Single Node Cluster
kubernetes上にコンテナを立ち上げる
- minikube - kubernetesのクラスターをローカルテスト用に構築する
- kubectl - kuberneteのクライアント
Commnads
- minikube version
- minikube start
- minikube addons enable dashboard : ダッシュボードの追加
- kubectl cluster-info
- kubectl get pods
- kubectl run : imageから実行
kubectl run first-deployment --image=nginx --port=80
- kubectl expose : portのフォワーディングなどできる
kubectl expose deployment first-deployment --port=80 --type=NodePort
実際のサンプルケース
- ジョブの実行
kubectl run first-deployment --image=nginx --port=80
- ポートのフォワーディング
kubectl expose deployment first-deployment --port=80 --type=NodePort
- ポートを探る
export PORT=$(kubectl get svc first-deployment -o go-template='{{range.spec.ports}}{{if .nodePort}}{{.nodePort}}{{"\n"}}{{end}}{{end}}')
Launch a multi-node cluster using Kubeadm
kubernetesのクラスターをkubeadmで立ち上げる
* kubeadm : manager cli of kubernetes
command
- kubeadm init : masterノードを立ち上げるコマンド。token初期値を渡すこともできる、ランダム生成させることもできる。productionではランダム生成させよう
- kubeadm token list : 保持しているトークンを表示できる
- kubeadm join : master ipとトークンを渡すことでkubernetesクラスターに参加できる
- kubectl get nodes 参加しているノードを調べる
- kubectl create deployment imageからpodを立ち上げる
yaml
- kind: ServiceAccount service Accountをつくる
- kind: ClusterRoleBinding ServiceAccountを紐づけできる
Start containers using Kubectl
command
- kubectl describe 対象の詳細を表示できる
- kubectl expose ポートをexternal-ipに紐付けるやり方。実際はserviceを作成する。
- kubectl scale --replica=3 deployment * のpod数を上げる
kubectl get svc svc = services
エンジニアがエンジニアであるために
はじめに
久々に思い立ってブログを書くことにしました。
僕が思う「エンジニアがエンジニアであるために」について、まとめようと思ったからです。
ここで言うエンジニアは俗に言うWeb業界がメインです。（僕がそうなので）
本とかブログとかを交え紹介をしていこうと思います。
基本的に３つの軸で書いていきます
- 考え方を身に付け
- 良いとは何かを知る
- 自分の知識を更新していくこと
この３つが必要だと、僕は思います。個人的見解なので、ほかにももっとこういう考え方あるよ、とかもあると思いますので、参考までに読んでいただけるとうれしいです。
考え方を身に付け
考え方を意識すること
まず、エンジニアであるということは、柔軟な思考と戦略的な思考が必要だと思います。そもそも今目の前にある課題をクリアするために、コードを書くだけが解決の方法ではありません。オープンソースを利用して対応する方法もあります。DBも多種多様です。柔軟に考えプロダクトを前進させていかなければいけません。
最初にお勧めしたいのが、このストラテジックマインドです。
企業経営のための本と書いてありますが、本質は戦略的な思考の本です。エンジニアは常に考えなければいけません、課題をどう解決するか、将来どのようにプロダクトを成長させるのか。その中で、いろいろな自分の固定概念やあるべき論に縛られることがあります。その時にどう考えればいいかを紐解く一冊になると思います。
books.rakuten.co.jp
次にお勧めしたいのがエッセンシャル思考です。
これは有名な本ですね。まず、エンジニアは時間がないことを知らなければいけないと思います。自分が勉強できる・成長できる時間。仕事中の時間をなにに使い、何に貢献するのか。なにも考えないとすぐに１年終わってしまいます。エンジニアには時間がないのです。そのため、「しないことはしない」、「やるべきこと」、「やりたいこと」をするためにどういう考えを持つ必要があるか。正直これができてないエンジニアは、成長が鈍化するだけでなく、ストレスをためてしまうかと思います。
簡単に読める割には、多くの発見がある本です。
books.rakuten.co.jp
エンジニアには文化があることを知ること
エンジニアリングをしていると、当然のように人とかかわることがあると思います。直接でなくてもコードの中やシステムを通して間接的にも多々かかわることもあると思います。開発をする、チームを作るということは、そのメンバーで文化を構築していくということを意識することが非常に重要だと思います。AgileやScrumなどもその文化の中のひとつだと思います。文化はリーダーだけでなく、そこにいるメンバー一人ひとりによって代わるものです。
文化については、ここら辺がお勧めです。どういう組織を作りたいかGeekな集団とは何か。
books.rakuten.co.jp
Spotifyの文化は、すごく参考になります。英語ですがスライドを見ればなんとなくわかるかと思います。
labs.spotify.com
labs.spotify.com
ちなみに、僕は文化として、重要だと思ってることは大きく３つ合ります。
- 真剣に振り返るできること
- Retrospective や Postmortem : https://landing.google.com/sre/book/chapters/postmortem-culture.html
- 安心感があること・失敗を恐れないこと
- Spotifyの文化だとFailure Celebration: 失敗をして新たな発見をできたことを祝う。
- 先を見越し動くこと(プロアクティブ)
- 言われて実装するのではなく、先見の目を持って技術投資を行い、プロダクトを改新していく感じ
- フォードもこの文化を持ってる１社ではないかと思います。
「もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。」
by ヘンリー・フォード（アメリカの自動車会社「フォード」の創業者）
http://meigensyu.seesaa.net/article/205528783.html
良いとは何かを知る
良いコードを知ること・良いアーキテクトを知ること
コードを書くときに、動けばいいや？って書いてるとそれは大間違いです。コードを書いた瞬間からそのコードの運用が始まります。コードを運用するためにはコードを読まなければいけません。そのためには、どのようなコードが読みやすいのか知る必要があります。僕はこう考えています。「企業の成長速度は、コードの良し悪しで決まる」と。改修しやすい、変更しやすいコードは企業のビジネスの変更に強く、その仮説検証を促進してくれます。逆にテストがなかったり、汚いコードはすぐにリリースはできますが、変更に弱く、いざビジネスを進化させようとする際に足を引っ張ります。
ゆっくり読んでも１週間くらいで読める本だと思いますので、とりあえず読むといいと思います。
books.rakuten.co.jp
次にお勧めしたいのが、レガシーソフトウェア改善ガイド
これを読めば、そもそもどんなソフトウェアが危険なのかの勘所とそれに対してどうすればよいかがわかります。なので、自分がレガシーソフトウェアに携わってないと思っていても、１度読むことをお勧めします。そもそもソフトウェアの構造がここ数年でどのように変わってきたかもわかるので、ある意味歴史の教科書です。個人的に、心に残ってるフェーズは「チームが既存のコードを改修しなくなったらそれはレガシーの始まりである。」という、組織文化についても少し触れていた点です。
books.rakuten.co.jp
使っているモノをちゃんと知ること
自分の扱ってるプロダクトに合わせて言語習得をしたりすると思います。既存のコードや書きたいコードを検索して調べて、それで実装して、リリースしたりしてると思います。でも、本当にその言語の強み、フレームワークの利用方法を学習してますか？なんとなく使えるからと、怠らずちゃんとそれがなんなのか知りましょう。先人たちが知るべきことを示してくれてます。
ベストプラクティスを読む
あと、ツールやDBだとベストプラクティスは結構公式に乗ってます。きちんと理解しましょう。
Googleで「Ansible BestPractice」とか打つと大抵出てきます。独自の発想で使うのではなく、ベストプラクティスに合わせて使いましょう。
そもそも、ベストプラクティスはツールの意義に沿って案じてあります。それに沿わないと、ツールがバージョンアップするときに取り残されて将来古いバージョンを利用し続けなくならなければいけない危険性があります。そんな、運用したくないですよね。
- Ansibleだと
自分の知識を更新していくこと
幅広くアンテナを持ち続ける。
ご存知のとおり、Web含めIT業界の技術というものは日進月歩です。
日々とまでは言いませんが、常に少しだけでも読むようにしておきましょう。課題を解決するときに新しいOSSのことを知っていたり、既存のOSSをバージョンアップすることでより、より便利にしたりと、プロダクトとあなたをアップデートしてくれます。
ここでは僕が日々キャッチアップしている軸とサイトを少しだけ紹介します。自分に合ったものをちゃんと見つけましょう。
幅広くキャッチアップする
いろいろなものはどこかでつながってるもので、浅くてもいいので幅広く知っておきたいものです。
hacker news
ここでは非常に幅広いジャンルの記事を読むことができます。
OSSだけでなく、世の中の情勢記事（技術によってる）などを読むことができます。TOP３０くらいが常にトップページに出てるので、朝から面白そうな記事だけ２，３個だけピックアップして読みます。
使い方的には技術新聞をぺらぺら読んで、情勢を知ったり、キャッチアップのために使います。
Hacker News
技術方法論を日々更新する
自分が良いと思っているやり方だけにこだわらず、いろいろな手法を勉強し続けることが大事だと思います。
dev to
表示速度が異常に早いことで有名になったページです。基本的にはWeb技術や手法についての記事が多いです。
自分のプログラミングや技術手法を改善するために、暇なときに読みます。
The DEV Community
利用してるものの知識を更新する
自分が使う技術回りは常にアップデートしておきましょう。それがそのまま自分の更なる強みになります。
ScalaTimes
名前から予測できるとおり、Scala周りの技術周り、ブログ周りを集めてるサイトです。
http://scalatimes.com/
ほかの言語でもいろいろとあると思います。メールを購読するようなサービスも意外と便利です。
同ジャンルの競合を知る。
自分が利用している技術の同ジャンル等はできるだけキャッチアップできることが大事です。
DB-Engines
DBのランキング紹介サイト。各ジャンルごとにDBのRankingを紹介しています。
僕は、上位のものを使うというより、そのジャンルで今どういうDBが出てるのかを知るために利用しています。それで、自分の利用用途に一番合うのはどれかを考えます。やはり、何かを採用する際は、ちゃんと競合には何が存在するのかを知っておく必要があると思います。
DB-Engines Ranking - popularity ranking of database management systems
最後に
最近、どのようにすれば自分がエンジニアとして価値を出せるのかを考えることが良くあります。この記事は、それに紐付いて思ったことを書きました。こういった人材を育て、同じチームでプロダクトに向かっていけるといいなと思います。もちろん自分もこういったエンジニアで在り続けないといけないなと思います。
最近、リモートワークで使ってるツール紹介
リモートワークで利用しているオンラインツールを簡単に説明したいと思います。
個人的には必須のサービスになりつつあります。
ぜひぜひ、利用してみてください。
appear.in
appear.in – one click video conversations
簡単にテレビ会議をするためのサービスです。真ん中のリンクに適当な文字列を入力すると、会議が始まります。そして、そのリンクを会議したい人に渡すだけで、テレビ会議が始まるというすぐれもの。必要な環境はブラウザだけなので、なにか特殊なアプリをインストール必要が無いのがすごい楽。
画面はこんな感じ。
web white board
A web whiteboard
これは、ウェブ上にみんなで落書き可能なホワイトボードを作成するサービスです。
リモートで説明するときに、落書きしながら話したいときに、効果を発揮します。でも、マウスでのお絵かきはやっぱり難しいです。
ちなみに、この左下の人を＋するみたいなアイコンをクリックしたあと、"Invite to board"すると、シェア用のリンクが出てきます。
- オンラインで参加者全員でお絵かきするホワイトボード
- 文字も打てる、ペンのサイズ、色も変更可能
- 図も挿入できる
- 何気にチャットも可能
- 書いたホワイトボードを、imageにして保存可能
- 有料会員になると、ボイスチャット、ボードの保存が可能
- やっぱり、書きながら説明するのは良い。
idea board
www.ideaboardz.com
オンラインで付箋を貼り付けるスペースを提供してくれるサービス。
ブレインストーミングや、レトロスペクティブに使える。
こんなかんじで、スペースが提供される
各チケットにイイねできる
パリで働いて感じたこと 第５話 レトロスペクティブ楽しい
どーも、だいごろうです。
今回、パリで感じたことというより、
会社でやってるスクラムのレトロスペクティブが面白いなと思ったので、
ブログに書いておきます。
（スクラム？それってラグビーのことだろ？？ってひとは、ごめんなさい。）
チームで振り返りをしてみたいって人にはおすすめ。ただし、コンテンツは英語。
日本語で雰囲気を知りたい人はご連絡下しあ。
さきに、このレトロスペクティブの流れのイメージを話すと
レトロスペクティブが始まると、
最初に、スプリントの全体を全員が１枚ずつ絵を書いて発表します。
次に、スプリントのイベントをTwitterのつぶやきの書き方で時系列に並べます。
それから、何をすれば次のスプリントが完璧になるかをボード上に貼っていきます。
そのボード上のモノを、実行しやすいかどうか、効果が高いかどうかの軸で並べ、
実行しやすく、効果が高いものを次のスプリントの目標に設定する！
という感じで、わいわい楽しみながら、みんなでスプリントを思い出し、
なにすれば良くなるかなーってのを話し合うイメージです。
しかも、毎回レトロスペクティブの中身が変わります！
じゃあ、具体的に説明していきます。
使ってるもの
Retromatというレトロスペクティブ用に作られたページ
Retromat - Inspiration & plans for (agile) retrospectives
このブログの著者が運営してるみたいです。
Finding-Marbles | Making sense of systems – Lean, Agile, Change & Communication
このページどうみるのか
このレトロスペクティブでは５つのステップに分かれています。
- SET THE STAGE ( 振り返る準備に入る
- GATHER DATA ( スプリントの出来事を集める
- GENERATE INSIGHTS ( 改善点、良かった点をあぶり出す
- DECIDE WHAT TO DO (何するか決める
- CLOSE THE RETROSPECTIVE ( 振り返りの締め
ページを見ていただくと、色によって、５ステップに分かれてるのがわかるかと思います。
そして、それぞれのステップに複数のコンテンツがあるので、
毎回それを変えながら、いつも違った形でレトロスペクティブを楽しむことができます。
しかも、それぞれのステップで10-20くらいのアクティビティがあり、
全部で105のアクティビティが有るみたいです (2015/07/24現在
3321204 combinations (20x23x19x19x20+4)って公式に書いてあるっすね。
最後の+4がよくわからんっすけどｗ
ちなみに、ページアクセスすると、自動でアクティビティを選んでくれます。
しかも、それぞれの組み合わせはURLとして、表現されているので、
URLのコピペでレトロスペクティブの項目を保存しておけます。（便利）
では、それぞれのステップがどんなことをするか例を上げて説明します
例
SET THE STAGE ( 振り返る準備に入る
Check In - Amazon Review (#18)
スプリントをアマゾンのレビューと同じように評価する
- Title
- Content
- Star rating (5 stars is the best)
そして、前で発表する
http://plans-for-retrospectives.com/?id=18
GATHER DATA ( スプリントの出来事を集める
#tweetmysprint (#97)
ホワイトボードにスプリントの始まりから、終わりまで時間軸を書き、
その上に付箋で、twitterでつぶやくように出来事を書いていく。
もちろん、@や#タグなども使って良い。
@daigoro
ここでだいごろうのバグ発見があった。
おかげで、リリース前にフィックスできた。
#bugfix #goodjob
GENERATE INSIGHTS ( 改善点、良かった点をあぶり出す
Perfection Game (#20)
全員が２枚の付箋を持つ、
１枚には前回のスプリントを１０点満点で評価する。
もう１枚には、どうすれば次のスプリントが１０点満点になるか書く。
最後に、一人一人、前で発表しながらホワイトボードに貼る。
http://plans-for-retrospectives.com/?id=20
DECIDE WHAT TO DO (何するか決める
Divide the Dollar (#72)
前のステップで出た改善点をすべて、並べて
もし、自分が１００ドル持ってたら、どれにどれだけ投資するかを書く。
全員が投資を書いた時点で、点数が高い順から次のアクションになる。
http://plans-for-retrospectives.com/?id=72
CLOSE THE RETROSPECTIVE ( 振り返りの締め
Motivational Poster (#92)
前のステップで決めたアクションをポスターにして自席の近くに貼っておく。
ポイントは、
- イメージ画像が有ること、
- チーム同意のアクションが書いてあること
- 自分の行動イメージが書いてあること
ちなみに
僕らが会社でやってるのは、ここにあるアクティビティを噛み砕いて、やりやすいようにやってます。
どうでしょうイメージ湧きましたでしょうか？
複雑そうに見えますが、非常に簡単なので、
レトロスペクティブがマンネリ化してると思うならば、
一度やってみることをおすすめします。
ちなみに、こちら、プリントエディションもありますので、
もし、興味がある方がいらっしゃいましたら、購入してみるのもありです。
この地球上なら送料無料です。（僕も買って、日本に送ってもらってますｗ
ただ、今年の販売が7/26までなので、もし買いたい方がいたら、早めに。
Retromat - The Print Edition
本日は、いままでにないくらいちゃんとブログを書いた気がします。
フランスに来て、スクラム・アジャイルを自由にやってる方々を見ると、
日本では形式から入る人が多いのでは？と感じます。
とりあえず、こういう面白そうなことだけから始めるのもいいかなーって感じました。
では！
パリで働いて感じたこと 第４話 今しかできないというセリフを言うこと
パリでフランス人と話して考えたこと。
「なんでそんなに仕事してるの？」
「今、幸せなの？」
「なんで家族とか友達とかにもっと時間割かないの？」
っとか、けっこう聞かれます。
"once life. you should do you want to do" : 「人生一回だから、自分のやりたいことやれよ」
っとか、言われます。
それに対して、
「だって、プログラマとして頑張れるのは今しかできない。だから今、イロイロと挑戦してます」
って答えてたんだけど、なんかしっくりこない気がしたから、ちょっとだけ考えてみた。
なんで、今しかできないの？？ってことを突き詰めて考えると
- 体力がなくなる
- 頭が回らなくなる
- 技術を追いかけられなくなる
- 他にエンジニアリング以外のことが見えてきて、そっちが楽しくなる。（かも）
- 日本ではそういう働き方では稼げなくなる
っとかを、頭のなかにでてきて、
でも、結局はどれも本質ではないなと思った。
エンジニア３５歳定年説とかも、ここらへんを見据えてのことじゃないかな。
まだ、３５歳じゃないから、本当のことはわからないけど。
結局は自分が好きなうちはプログラマで楽しく出来るんじゃないかなって思った。
今も、好きだからこの仕事でプログラミングしてるんだろうな。
きっと、今しかできないってことはないんだと思う。
ただ、「今しかできない」って言う、緊迫感を持ってチャレンジしていったほうが、
自分のキャリアとか人生とか面白い方に転びそうだなって思ったから
これからも、俺は今しかできないってこれからも言い続けると思います。
今しかできない（気がする）からチャレンジしたいんです、もっと。
そんで、振り返った時に、けっこうむちゃしてきたなーｗ
って言いたい。
