こんにちは。CADDi でエンジニアリングマネジメントをしている村上です。 この記事は CADDi Advent Calendar 2日目の記事です。昨日は、いなむさんによる C++20 Approach to Units of Measurement でした！
キャディでは、メンバーが持ち回りで発表する勉強会「STUDDi」と、特定領域について講師役を設定してシリーズ物でレクチャーを行う「STUDDi ゼミ」の2種類の勉強会をそれぞれ週1回のペースで行っています。
これまで「インフラ知識」や「ドメイン駆動設計」について扱ってきた「STUDDi ゼミ」ですが、私が9月に4回に渡って紹介したのが「良いチーム開発を実現するためのアジャイル」というテーマでした。その内容の一部として、より良い "チーム開発" を実現するために必要な「組織的な学習」と「自己組織化」について話したことをダイジェストでまとめようかと思います。
採用サイトや Wantedly の求人としては出していませんが、アジャイルコーチ的な立場で開発チームを改善するロールの方のジョインも心待ちにしています！
チームで学習すること、学習フレーム、心理的安全性
アジャイルソフトウェア開発宣言 の冒頭には 私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。 という言葉があります。「ソフトウェアのよりよい開発方法」を導くために、自らの実践や他者の実践の手助けの経験を重視するこの態度は、「経験主義」と呼ばれます。
「アジャイルなソフトウェア開発プロセスのひとつ」と説明されることの多い スクラム では、「透明性」「検査」「適応」という「3つの柱」を重視していますが、これも「チームの経験から知識を得て、起きたことや経験したことの観察に基づいて意思決定を下す」という経験主義を支えるためのものです。
『チームが機能するとはどういうことか』という書籍では、簡単には因果関係を突き止めることの出来ない複雑な問題解決に臨むチームを成功に導く鍵は「仕事を学習の機会と捉えるか」だと紹介されています。(このような態度は「学習フレーム」と紹介されており、真反対の態度が「実行フレーム」と呼ばれています。) これも一種の「経験主義」と言えましょう。
このような組織ぐるみでの「経験に基づいた学習」を促進するために重要となるのが「心理的安全性」です。
「心理的安全性」とは「厳しいフィードバックを与えたり、真実を避けずに難しい話し合いをしたりできる」状況や、「何かミスをしても、そのために他の人から罰せられたり評価を下げられたりすることはないと思える」状況を指します。 成長の材料となるはずの「失敗」から目を背けたくなるのは人間の直感的な心理でしょう。その失敗を直視するために必要なのが「心理的安全性」です。
今や広く知られる言葉となったこの言葉ですが、一方で曲解されるケースも目立つと感じています。「心理的安全性」を、単純な「居心地の良さ」や、「何を言っても許される雰囲気」を指すと言われる状況はしばしば見かけます。チームリーダーは、心理的安全性の担保を目的とするのではなく、それによってチームに学習フレームを植え付け、チームがイテレーションごとに強くなってゆくことを目指すという「本来の目的」を見失わないようにしたいものです。
自己組織化に至るまでの「3つのモード」
チームの文化を実行フレームから学習フレームに移行させる ("リフレーミング" と言います) ことや、それ以外にもチームが「何とか上手く回っている」状況を実現し、維持することがチームリーダーの大きな仕事です。スクラムというフレームワークで言えば、スクラムマスターという役割が主に気を配ることになるでしょう。それでは、チームはいつまでも チームリーダーやスクラムマスターによるケアやフォローを必要とし続けるのか？ そこで重要になるのが、チームの「自己組織化」です。
チームリーダーは、いつまでも自分に依存するチームではなく、自分の元からいつでも巣立ってゆける「自己組織化されたチーム」を作るべきでしょう。『The Great ScrumMaster』(邦訳: 『SCRUMMASTER THE BOOK』)にも、「自己組織化されたチームの構築に努め、自己組織化を、組織のあらゆる階層において重要な原則にする」ことがスクラムマスターの目標であり責任である、と書かれています。
自己組織化されたチームを目指す上でひとつの指針になるのが『Elastic Leadership』という書籍にて紹介されいる、「チームの3つのモード」という考え方です。
※ 書籍『エラスティックリーダーシップ』を参考に筆者が作成
自己組織化されたチームの実現への道は「サバイバルモード」から一足とびには叶わず、まず "火の着いた締切による炎上や難局" を切り抜け、チームを「学習モード」へと遷移させる必要がある、というのが「3つのモード」の特徴です。ここらへんの話は『チームが機能するとはどういうことか』の内容とも通づるところもあり、納得感があります。
GROW モデルと5つのツール
スクラムマスターとしてチームの自己組織化を促したり、もしくはメンターとしてジュニアメンバーの成長に貢献したりする際にヒントになるのが 「GROWモデル」です。これは筆者自身が過去に Ebacky による 認定スクラムマスター研修 を受講した際に習った話です。
「誰か」(個人だったりチームだったり) がどこかに向かうとき、まず「Reality: 現実」を確認した上で「目標: Goal」を定め、そこに至る「選択肢: Option」を洗い出してから、どの選択肢を「意思: Will」をもって決める、という枠組みが GROW モデルが示すものです。そんな「誰か」を手助けするときに有効なアプローチが5つ存在し、状況に応じて適切なアプローチを選択する必要があります。
- Situationing: 本人の現状を整理し、以下に述べる他の4つのアプローチのどれを適用するべきかを判断する
- Teaching: 本人に分野や概念の存在をインプットする。知識を一から十まで教えるというより、「より深く調べたい、勉強したい」と思わせるためにインパクトを残すイメージ。
- Coaching: 本人の中に潜在しているが自覚していない目標や答えを、問いを通して本人から引き出すことで明らかにする。
- Mentoring: 本人にとって明確なゴールへの進み方に迷っている状況で、選択肢を提示して本人に選ばせる。
- Facilitating: 「促進する」。脇道に逸れないようにする。現状から目的までの道のりから「脇道」に出た行動を軌道修正させる。
キャディではこの1年間どうだったの？
私自身のキャディでの仕事のひとつは、"klein" と呼ばれるサプライチェーン管理システムの開発・保守・運用を行うチームのコーチングを行うことでした。私たちのチームは「理想的なチーム」と呼ぶには道半ばだと思っていますが、この記事で言及した概念を STUDDi ゼミにて紹介した9月から現在までの短い期間でも、チームの良い変化をいくつか感じることがあります。
チームとしての学習
スクラムの定義するイベントの中で、レトロスペクティブ (振り返り) はチームの成長のための戦略を考える重要な場です。 私が klein チームに加入してから、様々な振り返りのフレームワークを紹介したり実践したりしてきましたが、「振り返りを何故やるか」の理解がチームで共有できたタイミングでクオリティーがぐっと上がった実感があります。 最近はホワイトボードアプリの miro 上に「klein チームの振り返りボード」を用意して、毎週の振り返りディスカッションログを残していますが、振り返りが「前回の振り返りからチームはどう変わったか」を積み重ねるような進み方をするように、自ずと変化していきました。
スプリント計画における自己組織化
私が加入した頃の klein は、 "誰が" "どの" プロダクトバックログアイテム (PBI) に取り組むかのレベルまで、プロダクトマネージャー (PdM) がケアしている光景がありました。一方で現在では、チームの開発者たちがスプリントゴールの妥当さや、その達成に向けた作戦を主体的に決めるようになりました。まさしく「自分たちのするべきことを自分たちで決める」という ”自己組織化された” 姿です。 特に顕著だったのがサブチームの流動化です。klein チームは、ある時期より 3~5人程度の固定化された2つの小規模サブチームで構成されていましたが、振り返りミーティングでの議論を通じ、スプリントごとにスプリントゴールやその達成方法に応じてサブチームをスプリントごとに形成する、という運用になりました。
メンター制度で他者の成長に貢献する風土
キャディのソフトウェアエンジニア職の採用では、経験のない技術要素でもなるべく早く実戦で成果を出すことができるような学習力や自走力を重視しています。しかし、メンバー間でのスキル差は存在するし、他のメンバーと比べて何らかの側面で能力がビハインドしているメンバーには、より一層の成長の機会を提供することが必要です。
このような状況で、キャディのテクノロジーチームでは, 必要な部分から少しずつメンター・メンティーの関係を構築し始めており、またメンター同士の情報交換として隔週30分のフリーディスカッションをする時間を設けています。メンター側も迷いを持つこともある中で、メンタリング/ティーチング/コーチング/ファシリテーション というアプローチのバリエーションを知っていることで、メンターとしての働きについて客観的な視点を持って振り返ったり議論ができているのではないかと思います。
理解は容易、習得は困難
さて、こういった概念や態度をキャディのエンジニア全員が完全に身につけたのか、と問われれば、答えは「No」だと思います。スクラムについてスクラムガイドが言っていたように、このような姿勢や考え方は「理解は容易」だったとしても「習得は困難」なものでしょう (2020年のスクラムガイド改定にて、この文言は削除されたようですが)。私自身だって、知識は頭の中にインデクスとしてはあるけど、それを日々の仕事で体現できているかというと、自信が持てないことも多々あります。そもそも、「自己組織化」という概念に「完成」は存在しないとも思います。
では、そんな「困難な習得」に攻略法はあるのでしょうか？成功が約束された方程式は無くとも、近道は存在するのではないかと思います。それは「同じ意識を持ったチームで仕事をする」ことです。漫然とタスクをこなすチームになるのではなく、常に「自分たちは正しく問題にアプローチしているか」「チームでの学習を促すために自分はどう振る舞うべきか」という視点をチームで共有し、メンバー間の相互作用でチームを強くすることが一番の近道なのだと、この2ヶ月のチームの成長を目の当たりにして改めて思う次第です。
ぜひ、そんなチームにジョインしませんか？こんな風にチームの成長をサポートするアジャイルコーチを付けたいけど付けられてないチーム、まだまだあります。 ご連絡はこちらからどうぞ
明日の CADDi Advent Calendar は、飯迫さんによる Argo Rollouts の話です。
