ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

「アジャイルコーチング」を読んだ

はじめに

現在4人チームのチーム運営に取り組んでいまして、いろいろあってアジャイルプラクティスの1つ、カンバンボードを各自のタスク割りに使うようにしました。

take-she12.hatenablog.com

導入前の課題

  • あらゆる情報をGitlabに一元化しており、個人の作業状況も個人のWORK/name/README.mdに集約していた
    • 結果、報告の粒度や問題点の提起が個人任せになっており、周囲が気づきづらい
    • 頼んだ仕事が本当にそのひとに認識されているかがわかりづらい

まずはチケット化しよう。ということでgitlabのissueを導入しました。

issueを導入した結果

  • どのタスクが誰が担当しているかわかるようになった
  • タスクの状況も1日1回更新してもらうことで1日1回のペースでupdateされるようになった

課題と改善

  • タスク粒度が不適当
    • ラインをbacklog,todo,doing,review,doneとし、reviewを追加することで、「これ以上自分のやることは終わった(誰かの待ち状態)になったものをreviewにすることにした
    • 結果、タスクはreviewが入るまでが1タスクになることになった

というわけでこれからはタスクがどれだけ追加されるか、消化されるかの数値をはかって生産性を可視化しよう、ということですが、なぜこのアジャイルコーチングを手にとったかというと

  • カンバンボードを導入した結果、メンバーが指示待ち(タスクを振られるのを待つ)になってしまった
    • これは僕が最初振っていたので当たり前です。自己組織化にはほど遠い。
  • タスクの期待値がうまく伝わらない
    • 説明不足もあるんですが、タスクの完了条件、背景(なぜやる必要があるのか)を記載することでだいぶ良くなりました

というわけで、カンバンボード自体は何なくみんなに使ってもらえたんですが、チーム全体でアジャイル式にタスクをまわしていくというときに、どうやったらみんなが自分ごととして、取り組んでくれるようになるのか?そのマインド変化をもたらすために何が大事か?を考えたときにこの本に出会いました。

アジャイルコーチング

アジャイルコーチング

アジャイルコーチン

自分がスクラムマスター、アジャイルチームをリードする立場になったときの心構えの本。中でもよかったところを紹介します。

1章 コーチングの基本

コーチの役目

気づく、フィードバックする、教育する、ファシリテートする、支援する、がアジャイルコーチの役目。

今は自分がプレイヤーかつマネジメントもやっている状況だったのでとっても良くない状況。そもそも自律的にチームが動いているところにアジャイルコーチが手助けする前提ですよね。

コーチングの態度

「模範を示す」というのがありました。僕自身の経験から、ひとにやってもらうためにはまず自分がやる、ということを心がけてまして、これは間違ってなかったなと実感しました。

もうひとつ、大切だなと思ったのは「言葉に気をつける」「私が」「あなたが」「彼らが」ではなく「私たちが」「私たちの」「私たちに」と置き換える。これは全然意識がたりていませんでした。「うちのチームが」とは言っていたかもしれませんが。(笑)

とはいえ「属人化を殺す」というポリシーで仕事をしているので、特定のひとに仕事を頼むことはあれど、誰のせいとか誰がやらないといけないということはない、はず。

PrOpERサイクル

Problem,Options,Experiment,Review。

PrOpERサイクルという言葉は本書でもたくさん出てくるんですが、でてくるたびに「何の略だったっけ?」と戻ることになってました。(笑)わかりづらい。

意識こそしてなかったですが、ほぼほぼこの通りに仕事を捉えていました。

「何が問題なの?(problem)」「解決するにはどうしたらいい?複数案あるならメリットデメリットを教えて。(Options)」「じゃあやってみて。(Experimtn)」「やってみてどうだった?(Review)」の方式で問題解決に取り組んでいますし、メンバー内でも上記の対話で話を進めています。

問題はExperimentの途中であらたなproblemが発生したり、時間がたてばproblemはproblemじゃなくなったりして、それがめまぐるしいことですね。あとは時間をかけてほしいところとかけてほしくないところの認識にメンバーとギャップがあったりしました。単にこれは対話がたりてないか事前の背景共有が不足してるんでしょうが。

14章 あなたの成長

飛んで一番よかったのはこの章ですね。

情報をキャッチアップしたり、ブログでアウトプット(まさにこのことですね)したりと、自分が成長し続けるための方法がのっています。ただ、中でも一番心にきたのは「優しく」という項目。

チームで仕事をしていれば、イラっとすることもあるし、「なんであんなに時間かかるんだ?」と不信に思ったり、意思疎通がうまくとれなくて「何を言っているかわからない。。。(きっとお互いに)」となったりすることがあるでしょう。(この本でもある通り、あなたを待ち構えてる苦難、ですね)

僕自身、怒りを表面に出したり、直接誰かを批判することはしません。それでも心に刻んでおきたいのがこの"優しく"かなと思います。

自分に優しくするように、他人にも優しくしましょう。厳しく責めたりしてはいけません。誰もが最善を尽くしており、すべてのことには何らかの理由があることを常に意識しましょう。その「最善」は素晴らしいものではないかもしれません。そして、そのように振る舞う理由をあなたが理解していないのかもしれません。だから見つけるのです。推測だけで終わらせて、判断したり陰口を叩いたりしてはいけません。話し合いましょう。情報を直接もらいましょう。驚くことがあるかもしれません。

「同じ立場になるまでは、他人を批判してはいけない」という言葉もあります。人が仕事をうまくできない理由はさまざまです。私生活に困難を抱えているのかもしれませんし、仕事を失い不安を感じているのかもしれません。自分の価値観を曲げなければいけないと感じていたり、コンフォートゾーンから追い出されていると感じていたりするのかもしれません。これまでに仕事で失敗したことがなければ、それは単に運がよかっただけです。適度にストレスのかかる状況にいたことがなかったのでしょう。

これは常に、心に持っておきたいです。

幸い今の僕の職場には失敗を責めたり声を荒げるひとはいません。

おわりに

今回、アジャイルチームを見る立場にとっての心構えを学びました。自分自身についてもPrOpERサイクルをまわして、改善をはかっていきます。