コーポレート + エンジニア・デザイナー混成チームのスクラム的取組み
こんにちは。コーチェットの取締役COO吉田です。
コーチェットのnoteで勉強会のお知らせは何度か書いているのですが
今日は自分が一緒に働いているチームの取組みを紹介をしたいと思います。
これは弊社サービス CoachEd for Teams で行った自チームのアセスメント結果です。
チームの状態について所属メンバーそれぞれが回答し、項目ごと、メンバー間、時系列でのバラツキを見ていくというものですが、全体スコア83というのは比較的よい状態と言えます。
実際にはどんな様子なのか、お伝えしていこうと思います。
まず前提として、コーチェットではコーチングやコーチングのトレーニング業務に関わるメンバーが多く、エンジニアやマーケティング、労務担当等、業務としてコーチングに直接関わっていないメンバーもコーチングには慣れ親しんでいる環境にあります。
その中で自分の所属するチームはmothershipという名称で、コーポレート+エンジニア・デザイナーの混成チームです。比較的ディフェンスよりのバックオフィス業務とソフトウェア開発がチームの担当範囲です。
経理や人事・労務、総務といったコーポレートのメンバーと、エンジニア・デザイナーの混成チームというのも珍しいとは思うのですが、コアメンバー全体で20名ほどのまだ小さな組織であることと、比較的労働集約性の高いサービスから始めているため、1人目のエンジニアはコーポレートエンジニアの役割も大きかった点、私のこれまでの経歴や守備範囲等の複合要因でこのようなチームになっています。
小さな会社のコーポレート部門が一般的にもつ特性
私は前職・前々職でも社長室や経営企画室といった事業部門ではないチームに所属していたこともあるのですが、数十人〜200人程度の組織において、コーポレート・バックオフィスはいろんな業務の担当者が混在するチームになりやすいです。
例えば経理と人事・労務、広報、IRと社長秘書やアシスタント、新規事業の企画やプロジェクトマネージャーなど役割の違うメンバーが1つの組織にいる場合、「チーム」としての一体感を持つことは難しくなります。チームの共通の目的・目標も、抽象度の高いものになることが多いですし、相互理解を目的にした定例MTGを設けても、お互い自分の専門性や守備範囲以外の業務についてはあまり興味がもてなかったり、それぞれ報告して終わりといった形にもなりやすく、MTGの存在意義自体を見失いがちです。
一方で例えば上場プロジェクトや全社イベント・カンファレンスの事務局といった「イベント」があると、一体感は生まれやすくなります。学生時代の文化祭や体育祭でクラスが団結するような一時的な熱量の話であったり、通常業務とは別に共通の役割や仕事が発生することも要因にはあるでしょう。
コーチェットで仕事をするまでは自分も上記のような認識で、コーポレート部門で「チーム」感を醸成するのは難しいし、必要もないのではないかと思っていたこともありました。
ところがそうではなかったということに気付きました。
結論、コーポレートとエンジニア・デザイナーの混成チームであっても「チーム」感は醸成できるし、それによってチームの生産性を向上させることができます。
今のチームでやっていることとその様子については以下の通りです。
チームでやっていること
メンバーに恵まれている、ということは前提ではあるのですが 要素としては、３つの仕組みと相互の関わり方に特徴があると思います。
朝会
タスクボード
週次定例で行う各自の振り返り（KPT）
上記のスクラム的な手法と、主に朝会と振り返りでの相互の関わり方に要因があると思っています。
元は私とエンジニア2人ではじめて、他のメンバーも合流したという流れです。
朝会
朝会は毎朝15分oViceで音声のみ。5名。
notionに記載したタスクボードをそれぞれ見ながら、昨日やったこと、今日やること、妨げになること（困っていることや相談したいこと）などを一人数分ずつ声に出しています。
別のMTG等でメンバーが欠席することもありますが、1年以上続いておりチームの中では定着しています。
これによって、他のメンバーが毎日何をするのか耳にすることができます。具体的な内容まではわからなくても、数日同じタスクの話があると、大変そうだなとか長くかかる業務だなということはわかりますし、体調の話題などもよく出ます。
メンバーが主にファシリテートしてくれているのも、自分にはとても助かっています。
タスクボード
通常のスクラム開発ではチームで共通のボードを使うと思うのですが、担当業務やプロジェクトがバラバラなので、担当者やプロジェクト別に８つほどのボードがチームのnotionページに並んでいます。
ステータス、見積もりサイズ、締切日、完了日はおおむね共通の項目です。
進捗が悪そうなタスクについて「どうやったら分解できるか」「最初のアクションはなにができるか」「こちらでサポートできることはないか」等の問いかけがメンバー間でも行われ、結果進捗が改善するということが発生しています。
ここはそれぞれのメンバーがコーチング的な関わりに慣れ親しんでいることも助けになっています。
週次定例での各自振り返り（KPT）
メンバーそれぞれ先週1週間の振り返りをKPTの形式で書き出した状態で定例MTGを行います。
大きなアジェンダがなければ、6人のメンバーそれぞれ5分で発表と質問・提案・フィードバックを行い、チーム全体で30分程度使っています。
KPTにおいては、DPAで雰囲気について合意をつくったのも良かったと思います。
（DPAについてはこちらの記事が参考になります）
自分達で決めた「作りたい雰囲気」と「具体的にできること」は以下の通りです。
安心安全！軽い不安や不満、困っていることでも共有しやすい雰囲気！
相手を否定せず承認する
Keep をたくさん出す
大トロ、中トロ、赤身と吐露してくれたことをおもしろおかしく扱う
多様な観点で振り返る！(特に外部リソース)
思考のタガを外す問いを投げ合う
I メッセージで伝える(私はこう思う)
自分だったらどうだろうか？と考える
KPTでKeepがなかなか出てこないという悩みはよくあると思うのですが、DPAで場について合意しておくことや、他者のKeepについて積極的に承認することを意識するとよいと思います。
その他、Tryについてヘルプになりそうなことは伝える等、誰かのKPT発表に対して無反応ということはありません。
結果どうなっているか
最近特に痛感するのは、不安やわからなさが仕事のスタートを妨げたり、スピードを遅らせることが本当によくあるということです。
そういった、進みが遅いタスクがあったとして、マネージャーとしては「いつできるの？」「なんでできてないの？」という関わりになりがちだったなと思いますし、阻害要因を取り除けているわけでもなかったなと思います。
もう１つ、塊の大きなタスクというのも仕事のスピードを妨げます。分解していますぐできることから着手することが重要です。
タスクボードと朝会でお互いのタスクを可視化し、週１の振り返りで承認とフィードバックをする。これらがベースとしての心理的安全をつくり、「不安」「大きな塊」という２つの阻害要因をとりのぞくこと、外部リソースとしての手助けがあることが、仕事の進捗をスムーズにすることに役立っていると思います。1人担当者の業務は自分1人に閉じがちですが、専門外の人からもサポートがあると思うと安心して仕事ができますし、そうした精神的な余裕が他者に関わる意識を下支えするのだと思います。
成果や進捗を承認すること、不安や心配にアプローチすること、大きな塊に対して「分解しよう」と声をかけること、これらには業務の専門性は無関係です。誰でも力になることができます。
役割がバラバラだったり、具体的な達成目標に向かってそろいにくいチームであっても、上記のような仕組みと関わり方で、チームの一体感はつくれるし、それが生産性の向上に役立つんだなということをここ1年ぐらいで学び、実感しています。
開発部門以外でもスクラム的な取組みを取り入れてみてはいかがでしょうか。