はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

チームで社外勉強会に参加するメリット

先日、以下の勉強会に参加しました。

uxdt.connpass.com

勉強会は座学とワークショップと認定試験がありました。実践的だったので社内で試しやすい内容でした。

今回は勉強会の内容ではなく、社外勉強会に参加するとき一人で参加することが多い僕が会社のメンバーと一緒に参加して感じたメリットについてまとめます。ほんと、皆で参加できて良かった。

勉強会 みんなで行けば 怖くない

やはりみんなで行くことは参加の後押しになりますね。社内で勉強会を紹介したときに、「以前も参加したいと思ってたけど一歩が踏み出せなくて、、、でも、皆で行けるなら行きましょう」っと声があがりました。
難しそうとか、レベルが高そうとか、そんな悩みはみんなで行くで解決できます。そして、実際に行ってみるとそんな想いは杞憂に終わって学びがあった、楽しかったっとポジティブな感情に変わります。

行く前から気持ちが盛り上がる

同じイベントを予定している人が社内にいると、「もうすぐですね」っと話すことが出来ます。そのたびに「楽しみですねー」って話ができて待ち遠しくなります。

普段から勉強会の予定があると楽しみですが、より楽しみになれます。

お互いの隙間を埋められる

勉強会で分からなかったことは調べることが出来ますが、さらっと流してしまったことは分からないことに気づけません。

勉強会が終わってから、みんなで話し合うと気づいてなかった大切なことを知る事ができますし、勘違いも気づけます。

学んだことを実践しやすい

勉強会で学んだことを実践すると深く考えるきっかけになるし、上手くいかないことから学びはあるし、上手くいけば自信になります。アウトプットは大切だと思います。

しかし、アウトプットの大切さは分かっていながら、勇気が出なかったり、実践方法が分からなかったり、悩んだり、行動に移せないことがあります。
そんなときに同じ場を過ごした仲間がいることで助け合い励まし合いながら行動することができます。何より一人じゃないので勇気がでます。

さいごに

勉強会に関わらずみんなで学ぶ事の良さを体験出来たので、これからも企画していきたいと思います。

さらに、さいごに

認定試験は無事に合格しました。

スクラムで目指すべき自己組織化チームになるために / エラスティックリーダーシップを読んだ

スクラムガイド(2017年度版)を確認するとスクラムマスターは自己組織化・機能横断的になるように開発チームを支援する責任があると書かれています。しかし、どうすれば開発チームを自己組織化できるのかについては書かれておらず、スクラムフレームワークに沿いながら必要な支援を考える必要があります。今回は自己組織化の知識を得るためにエラスティックリーダーシップを読みました。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

自己組織化とは?

自己組織化とは何か。スクラムガイドには以下のように書かれています。

自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。

本書には以下のように書かれています。

自己組織化されたチームとは、意思決定の機会や生産的に前進する際に、リーダーであるあなたから独立して機能するチーム

いずれも、リーダーからの指示ではなく自分たちで何をするかを決定して、行動していくチームだと定義されていますね。個人的にはサッカーチームが自己組織化の例えとして分かりやすいと思っています。監督の分析した対戦相手のデータとそれに対応する戦術の説明を試合前に行いますが、試合が始まった後は選手1人1人がチームとして勝つために何をすれば良いか選択し続けます。1秒1秒で状況が変わるので監督が細かに指示を出していては勝てないのです。指示を待つ選手がいると勝てないのです。自己組織化しないと勝てないのです。
このように、複雑で変化の激しい状況に挑むためには自己組織化が必要になります。

開発チームのモードによって支援方法が異なる

では、どうやって自己組織化したチームになるのか。本書では「自己組織化モード」「サバイバルモード」「学習モード」の3つのチーム状態があると書かれており、それぞれ異なったアプローチ方法で自己組織化モードを目指していくと書かれています。

この視点はとても大切だと思いました。指揮統制型リーダーシップ、サーバントリーダーシップをチームの状況に応じて常に重心を移動しながら行動しましょうっと言うことです。本書を読むまではリーダーとなる人の個性で指揮統制型リーダーシップ、サーバントリーダーシップの違いが生まれると思っていました。しかし、自己組織化したチームを育てるためには状況にあったリーダーシップを取る必要があり、苦手なリーダーシップタイプも出せるように練習しておく必要があります。

ふりかえりで成長を促す

チームの状況が把握できた後は成長するための行動が必要です。本書ではクリアリングミーティングが紹介されています。スクラムのレトロスペクティブ(ふりかえり)と同じだと思いました。
アジャイルなチームになるためにはまず"ふりかえり"って話も聞くので、自己組織化を目指すうえで重要な活動ですね。自分たちで課題を見つけて、自分たちで改善案を出して、自分たちで良くしていくサイクルは色々な課題を自分事として考えるきっかけにもなるため、僕も採用することが多いです。

コミットメント言語

仕事をしているとき、僕たちは多くの事を約束します。「〇〇を作ります」「○○を提出します」「○○までに調べておきます」約束の連続です。約束するときに不安があったり、分からないことが含まれていた場合、あいまいな回答をするときがあります。「今週中には不具合が修正できると思います。」「今週、やろうと思ってます」このような曖昧だったり、希望が混ざった約束とは違い、明確で制御できる約束をすることをコミットメント言語と呼ばれています。
このコミットメント言語を使うには心理的安全性が必要だと感じました。約束しても色んな予定外が発生して守れないこともあります。そんな時はいち早くチームに報告し対策を考えるべきです。しかし、心理的安全性が低いとネガティブな報告が遅れ、その影響でサバイバルモードに突入する可能性があると思います。

さいごに

リーダーになる方やチームビルディングに興味のある方におすすめできる本です。どうリードすれば良いか分からないとき、チームのモードを把握するところから始めることで迷いが減ると思います。

ドラッカー風エクササイズ でチームメンバーを知ろう

先日、ドラッカー風エクササイズをチームで行いました。
どんな風に進めたのか、どんな結果を得られたのか、今後どうしていきたいかをまとめていきます。

ドラッカー風エクササイズとは

チームメンバーそれぞれが以下の4つの質問に回答し、回答者以外のメンバーからフィードバックを行うことでお互いを良く知り開発のパフォーマンスを高めるための手法です。
(質問)

  • 自分は何が得意なのか?
  • 自分はどうやって貢献するつもりか?
  • 自分が大切に思う価値は何か?
  • チームメンバーは自分にどんな成果を期待していると思うか?

(フィードバック)

  • チームメンバーが対象者に期待している事

進めるにあたり以下のサイトを参考にさせて頂きました。
チームメンバーの期待をあわせる「ドラッカー風エクササイズ」 | DevTab - 成長しつづけるデベロッパーのための情報タブロイド
「ドラッカー風エクササイズ」で期待をすりあわせて安全なチームに - ペパボテックブログ
チームの期待値を合わせる!ドラッカー風エクササイズとタックマンモデルを組み合わせた結果 | Backlogブログ

どんな風に進めたのか

いきなり集まって実施するのではなく、目的を伝えて、4つの質問を事前に書いてもらうことにしました。今回はエクセルに4つの質問とチームメンバーの表を作り各自でエクササイズの日までに記入をお願いしました。

エクササイズ当日はメンバー毎に記入済みの回答を紹介した後、チームから期待していることを伝えました。

どんな結果を得られたのか

大切に思う価値について共通点が見つかったり、チームからメンバーに期待を伝えつつ、メンバーそれぞれの長所を伝え合う場になりました。日常の開発の中で「こんなこと期待してるんだよ」とか「こんなところが凄いと思っているんだよ」、「ここをもっと伸ばせばもっと良くなるよ」などを伝える機会は少ない(ほぼない)と思います。そういった事が伝えられるのも良いなと感じました。
普段話さない事を話すので僕は少し嬉し恥かしの気持ちでした。

今後どうしていきたい

定期的に見返していきたいです。期待されていることで良くなった事があればお祝いしたいですし、時間が進むにつれ考えも変わるでしょうし、たまには更新したいと思います。

僕なりの Fun Done Learn の進め方

先日のふりかえりでFun Done Learnをやってみました。初めてFun Done Learnをやってみたときは進行方法も分からずモヤっとして終わったのですが、ワークショップに参加したりブログ見たりpodcast聞いたりと情報収集してから再度やってみて「この進め方で良さそう!」っと自分なりの進め方が見つかりました。Fun Done Learnは他のふりかえりフレームワークであまり考えない"Fun"についてふりかえります。"仕事を楽しめたかどうかふりかえりたい"とか"KPT以外のフレームワークを使いたい"とか"ふりかえりがいつも暗い"などの時に使えそうです。

私が進める際に注意したことをまとめていきます。

Fun Done Learnはファン・ダン・ラーン

Fun Done Learnはファン・ダン・ラーンと読みます。Scrum Alliance Agile Coaching Retreats のイベントで生み出されました。詳細はやっとむさんのブログで公開されています。
ファン・ダン・ラーン(FDL)ふりかえりボード - やっとむでぽん

Fun Done Learnが生まれた経緯はomoiyariFMでやっとむさんがお話されています。

#45 Fun! Fun! Fun! | #omoiyarifm 
この回の32分ぐらいからお話されていて、新しい技術(このときはスクラム)を導入する際に楽しいかどうかが大切で、それが目に見えた方が良いねと話になり生まれたそうです。ちなみに次の回もやっとむさんがゲストでふりかえりの話をされています。
#46 いろいろ!ふりかえり | #omoiyarifm

Fun Done Learnはデータを収集するアクティビティ

ふりかえりの良書 アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き にふりかえりの構成が書かれています。

1.場を設定する
2.データを収集する
3.アイデアを出す
4.何をすべきかを決定する
5.レトロスペクティブを終了する

Fun Done Learnは主にデータを収集するアクティビティとして使います。要は何があったか思い出しながら、「楽しかったなー」「学びがあったなー」「すげぇ価値を届けられたなぁー」っとふりかえるのです。前向きなアクティビティですね。

Fun Done Learnの進め方

1.ベン図の用意

f:id:iucstscui:20190529232343p:plain
こんな感じでFun、Done、Learnのベン図を用意します。図の中に付箋を貼るので大きめに書きましょう。
注意点は真ん中の三角(三つの丸の重なり部分)が大きくなるように書くことです。じゃないと、付箋が貼れなくなります。コツとしては真ん中の三角から大きめに書き始めて、二つの重なり部分を書いて、三つの丸になるように書くと付箋が貼りやすくなります。*1

2.やった事を話しながら付箋を貼っていく

皆でやった事を話しながらベン図に付箋を貼っていきます。私がやったときは各自で付箋に書いて、一枚できたら周りを待たずに発言しながら貼っていきました。他の人の意見を聞くと思い出すこともあるので、全部書いてから貼るのではなく早めに共有しました。そして、みんなで貼る場所を決めます。Funでもあり、Doneでもあれば二つの重なり部分に付箋を貼ります。


注意した点は2つです。

その1.付箋を書くときはFun、Done、Learnの枠組みで思い出さない

AさんがFunだったなぁっと出した付箋はBさんから「こんな学びもあったんじゃない?」っとフィードバックが得られます。AさんがFunでもDoneでもLearnでもないと思っていてもBさんから見ればどこかに当てはまるかも知れません。取りあえずやった事を出しましょう。どこにも当てはまらない場合は枠外に配置します。枠に縛られて発言が出にくくなるのは良くないと思うので、やった事は全部出したほうが良いです。

その2.Doneの枠は価値を届けられた事を貼る

初めにやった時、Doneは「やった事」を貼っていました。その結果、全部Doneに貼られる事になります。(やった事を話すので、そりゃそうです)何か違うなぁっと思って考えていると、Doneの前の名前がDeriverだったことを思い出しました。そこで、Doneには価値を届けられた事を貼るように変えると収まりが良くなりました。

3.少ないところを見てみる、多いところを見てみる

出来上がった結果を見て多かったところ、少なかったところに注目してみると、次のアクションを見つけやすいです。
例えば、Funが多ければ「どうすればこの状態を続けられるか?」、Doneが少なければ「どうすれば、もっと価値を届けられるか」です。
初めてFun Done Learnをやったとき、次のアクションの決め方が分からず、モヤっと終わってしまいました。次のアクションが出なくても、振り返って意見を共有するだけで充分価値はありますが、次のアクションを決めたい場合は偏りに着目すると良いと思います。

さいごに

Fun Done LearnはKPTと同じくふりかえり手法の一つです。「Fun Done Learnが良い、KPTが悪い」っという訳でもなく、それぞれに特徴があります。多くの手法を知り、場面によって使い分けられるように経験を積みたいと思います。

Fun Done Learnのように感情面(喜怒哀楽)をふりかえる事は意見も出やすくなるので大切だなっと思います。なので、KPTするときでも意識的に感情面の意見を出すと盛り上がりやすいです。


私が参加したワークショップはこちら。その時のスライドも上がっています。
iucstscui.hatenablog.com

それでは、楽しいふりかえりを!

*1:参加したワークショップで教わりました

Gitで別ブランチのフォルダを取得する(コピーする)

Gitで別ブランチのフォルダを取得する際に迷ったのでまとめておきます。

git checkout で取得できる

git checkout で取得できるのはファイルだけだと勘違いしていて、調べるのに時間がかかってしましたが、フォルダーも同じように取得できました。

git checkout <ブランチ名> <フォルダパス>

例えば、「feature/XXX」ブランチの「YYY\ZZZ」フォルダをコピーする場合は以下のコマンドになります。

git checkout feature/XXX YYY\ZZZ

ちなみにファイルを取得したい場合は<フォルダパス>の部分をファイルパスに変えればOKです。

TortoiseGitを使っても取得できる

僕はTortoiseGitを使っていて、TortoiseGitでも同じことができます。

右クリックから「Repo-browser」を選択
f:id:iucstscui:20190527221153p:plain


ポップアップが出るので、Revisionの「HEAD」をクリック
f:id:iucstscui:20190527221343p:plain


ログ画面が表示されるので、取得したいブランチの任意のコミットログを選択してOK。
f:id:iucstscui:20190527221820p:plain


取得したいブランチのフォルダ構成が表示され、ドラッグ&ドロップで特定のフォルダを取得できます。
f:id:iucstscui:20190527221829p:plain

アイデアを出すためのフレームワークを調べた

人生初ハッカソンに参加するにあたって短い時間でアイデアを出すためにフレームワークを知っておいたほうが良いだろうと思って調べました。今からワクワクしています。

しりとり

TEDの動画を見て知りました。
www.ted.com

子どもの頃にやっていた「しりとり」を使ったアイデア出しです。しりとりで出たランダムな単語とテーマ(TEDの動画であればおもちゃ)を組み合わせてアイデアを出すフレームワークです。考えたアイデアは自分の考えられる範囲でしか出すことができませんが「しりとり」であれば思いもよらないアイデアが出そうですね。

余談ですが、僕はしりとりが弱くて、7歳の息子としりとりしても負けています。先日も「ラーメン、あ!」っと負けました。

ブレーンストーミング

とにかく数を出すことを重視してアイデアを出す方法です。僕は何かアイデア出しましょうってなった時はブレーンストーミングをすることが多いです。
ブレーンストーミングは4原則があります。
判断・結論を出さない(結論厳禁)
粗野な考えを歓迎する(自由奔放)
量を重視する(質より量)
アイディアを結合し発展させる(結合改善)

Wikipediaより ブレインストーミング - Wikipedia

特に最後が重要かなと思います。「しりとり」の項目でも書きましたが、考えたアイデアは自分の考えられる範囲でしか出せないので、他の方が出したアイデアを元に新しいアイデアをどんどん出していく必要があります。

出したアイデアKJ法などでまとめてアイデアを徐々に形にしていきます。

マンダラート

swingroot.com

3×3の9つのマスを用意し、中心にテーマを書き回りを埋めていく発想法です。ブレーンストーミングに制限を加えたような発想法だと思いました。出さないといけないアイデアの個数が決まっているので無理にでもアイデアを考えることで、自分の考えを超えたアイデアを出すことができます。また、別の9つのマスを作って出したアイデアを中心に書き、さらに回りを埋めていくことでアイデアを連想させていきます。

「耕す」「芽生え」「育てる」

フレームワークではありませんが、「エンジニアの知的生産術」で紹介されていたアイデアを思いつくためのフェーズです。「耕す」フェーズは色々な情報をインプットして芽が出る準備をする段階です。参加するハッカソンは当日にテーマが発表されます。そのテーマに慣れ親しんでいない可能性もあるので、まずは情報を収集して幅広く考えられるようにしたいと思います。

iucstscui.hatenablog.com

さいごに

イデアを開発した後はプレゼンすることになります。考えたアイデアをただ作るだけでなくWhy→How→Whatの順に伝えられるように、誰向けに作るのか、どういった課題を解決するのかもしっかり考えてハッカソンにチャレンジしたいと思います。

iucstscui.hatenablog.com

ビジョンを伝えないと人は動かない

子どもと「お風呂入ろう」「いや」を繰り返していて、「入る!」になるまでのやり取りの中でビジョンを伝える大切さを改めて感じました。そしてこれがゴールデンサークルの力だと思い知りました。

お風呂に入りたくない!

いつもならお布団に入っている時間なのにお風呂も終わっていない状況でした。明日も幼稚園があるので早々に寝る準備へ取り掛からないといけません。さっそく子どもに「お風呂入ろう」っと声をかけました。返ってきた返事は「いや」です。いつも、すんなり入ってくれることは少ないのですが、今回は特に「うん」と言ってくれません。
「お風呂入ろう」
「いや」
「お風呂入ろう」
「いやや」
「早く寝ないと」
「いや」



困った。

ビジョンを伝える

次は子どものやりたい事/なりたい事から早く寝ることが必要だと訴えかけてみました。
「大きくなって強くなりたいよね」
「うん」
「大きくなってヒーローになるんだよね」
「うん」
「早く寝ないと大きくなれないし、強くなれないよ」
「・・・」
「お風呂入ろう」
「うん」

入ってくれた!

ビジョンが人を動かす

お風呂に入ってくれた後に、これがゴールデンサークルの伝え方だと思いました。
www.ted.com

ゴールデンサークルは人に行動を起こしてもらえる伝え方です。多くの人や企業は「What」→「How」→「Why」の順番に伝えます。しかし、行動を起こしてもらうためには逆の「Why」から伝えたほうが良いと説明されています。

今回のお風呂の例で確認してみましょう。

「What」→「How」→「Why」だと以下の流れになります。
「お風呂に入ろう」→「今すぐ服を脱いでお風呂場に向かう」→「大きく強くなってヒーローになりたいよね」

「Why」→「How」→「What」だと以下の流れになります。
「大きく強くなってヒーローになりたいよね」→「今すぐ服を脱いでお風呂場に向かって」→「お風呂に入ろう」

「What」から始めると、まだ遊びたいからお風呂に入りたくないっとなり「Why」までたどりつきません。子どもが興味を持つ「Why」から始めると、「ヒーローになりたい。どうすればいいの?」っと共感してもらえて行動に繋がります。

色々なところで応用ができる

会議でもチーム開発でも日常生活でも応用できる考え方だと思います。Why(ビジョン)に共感できることが前提ですが、魅力的なビジョンを伝えることで全員が同じ方向に向かって自律的に動くことができます。スクラムチームが目指す自己組織化されたチームも同様ですね。全員が同じビジョンを共有していることは自己組織化チームに必要な要素の一つになります。

最後に

お風呂に入ったら入ったで、次は「出るのいや」になったりするので子育ては難しいと思うことがいっぱいです。