Managerでありながら尖ったEngineerであるために自己組織化チームに挑む

この記事は、 Engineering Manager Advent Calendar 2018 の3日目のエントリーです。

また、同名のタイトルで、 Scrum Fest Osaka 2019 の プロポーザルを提出させていただいております。
https://confengine.com/scrum-fest-osaka-2019/proposal/8574/managerengineer

当日の発表は、この記事をベースとさせていただきますが、また発表のタイミングで色々とアップデートもあると思いますし、全然ちゃう内容になることもあるかも…?

以下のアジェンダで書いてみようと思います。

• 前提
• 仮説
• 検証
  • Management 3.0
  • 見える化
  • タスクはPull
  • モブプログラミング
  • 任せる領域
  • 自身も含めてエンゲージメントを高める
• まとめ

前提

私がどういった組織とチームに所属しており、役割を担い、組織の運営、チームの運営にどう関わってきたか、あまり詳細に書くことはできないので、ざっくり概要だけ書きます。

• 組織の責任者
• プロジェクトと組織の枠組みは別
• 組織のメンバーは、別々のプロジェクトチームに所属している
• 私が所属しているプロジェクトは、社員のみで構成されているわけではない
• 開発拠点は一箇所で全員その場にいる(リモートはいない)
• 組織のマネジメントと、プロジェクトのマネジメントが求められていた
• プロジェクトはスクラムチーム
• わたしは、スクラムマスターではなく、Developer
• 組織の責任者であり、プロジェクトの進捗について部分的に責任を担っていた
  • 部分的というのは、プロジェクトは巨大で、全体的な進捗を私の関わる部分だけでコントロールできる範囲になかったことからそういう表現にしている

まとめると…

私の役割としては、プロジェクトを進捗させ、プロダクトを世に出すため、開発を進めることだった。

いかに、自身の責任範囲において、進捗を出し、速く確実に成果を出し、プロダクトをローンチするのかといったことに取り組んでいた。

ある程度の権限をいただいていたので、私が開発してもしなくても、進捗さえ出れば良いという状況であり、手段については、問われない状況だった。
そのうえで、私はエンジニアでありたいがゆえに、組織とプロジェクトを推進しながら、自身もエンジニアとして手を動かし続けるには、どうすれば良いのか、といったあたりで、もがきトライした経験からの抜粋を書きます。

仮説

「自己組織化チームであれば、人や進捗を管理することなく、自身もエンジニアリングをしながら、結果も出せるのではないか。」
という仮説を立てた。

自己組織化チーム

改めて、自己組織化チームという言葉について、 InfoQでは、次のように紹介されている。

自己組織化チームとは何か？

真のチームは価値のあるミッション，明確な境界，自己管理と安定のための権限を備えていることを見てきました。チームの自己組織化はチームメンバの類似性と相違性の微妙なバランスの上に作られるということ，自己組織化には明確な境界とサポートするコンテキストが必要であること，自己組織化は分散管理，継続的な対応，創発的構造，フィードバック，復元力といったもので特徴付けられている，ということも分かりました。そして最後に，自己組織化には長い時間が必要なことも理解しました。

この結論だけを読んでもちんぷんかんぷんですが…きちんと最初から読めばなんとなく分かった気がします。

とはいえ、私が今回書きたいポイントとしては、ここで述べられている全てではなく、次のポイントにしぼって実施してきたことを挙げたいと思います。

自己組織化には明確な境界とサポートするコンテキストが必要であること

検証

以下の要素を検証した。

Management3.0

Management3.0を説明するときは、いつも必ず、1.0,2.0と追って説明することで、どういったものかピンと来やすいなーと思いますので、書きます。

Management 1.0

トップダウン式で、少数の人が権限を持っているタイプの組織の運営方法です。
つまりマイクロマネジメントです。ヒエラルキーの下にいる人たちは責任がほとんどなく、いい仕事をしようというモチベーションがありません。
このとき、「マネジメントとしては間違ったことをしている」状態になってしまいます。
しかし、残念ながら世界でもっとも広く普及しているマネジメント方法です。

Management 2.0

Management 1.0という古いシステムに、作業効率と従業員のモチベーションを上げるための、大量の活動を追加した状態のことです。
こちらもトップダウン・アプローチに変わりはありません。
そして残念ながら度々間違ったアプローチを適用している「正しいことを間違った方法でやっている」状態とされます。

Management 3.0

ヒエラルキーではなくネットワークが権限を持っていることを要件としたリーダーシップとマネジメントの概念です。
参加者全員が協調することによって、効率が良くなり、ビジネス・ゴールを達成することだけでなく、自己組織化を通して、高い内発的動機付けができ、皆さんが笑顔になります。
組織システムとして「正しいことをしている」状態とされます。

ぱっと、1.0->2.0->3.0と順に読むと、3.0は直感的に良い状態と定義されており、ここでも自己組織化というキーワードが出てきております。

さらに、InfoQで、 スクラムとManagement 3.0 という記事が掲載されており、この中で、次のような特徴に重きを置いていると紹介されています。

1. 能力を開発する: マネージャはチームメンバが目標を達成するための能力開発を支援しなければならない。困難な課題に取り組む機会を提供することが，社員の能力レベルの向上に役立つ。
2. 構造を拡大する: チームメンバ内のコミュニケーションやコラボレーションを向上するための構造を作り上げる。
3. すべてを向上する: メンバ，チーム，組織は継続的に改善し，失敗の回避に注力する必要がある。継続的な改善。
4. 精力的にする: マネージャはメンバのモチベーション向上を支援して，彼らが創造的かつ活動的であることを評価するべきだ。
5. チームに権限を与える: マネジメントはチームの自己組織化をサポートし，意思決定を行う権限を与える。
6. 制約を整える: 自己組織化のためには，システム内部が境界によって囲まれている必要がある。境界を置くことが，自己組織化を価値へと向かわせる。

以上の中から私が取り上げたいのは、 チームへの権限の提供 と、 境界の確保 です。

チームへの権限の提供

チームを自己組織化するため、権限の提供は欠かせないと考えており、そのために境界を確保して、その範囲において、自身の判断、管理のもと、遂行して良いよという確約を提供することを意識して取り組んでおりました。

そのことを念頭に置いたうえでの具体的な行動として、以下が挙げられます。

• 見える化
• タスクはPull
• モブプログラミング
• 任せる領域

見える化

チームの状況をチームのメンバーも含めて、見える状態になっていることは、自分たちが、全体の進捗においてとか、プロジェクトの方針においてとか、世の中、プロダクトの市場価値など、あらゆる視座において、とても重要だと考えます。

スクラムのスプリントという約束された範囲において、自分たちの制御可能な領域があり、そのステータスがどのようになっているか、自分たちも見えており、いつでも説明できる状態にしておくことは、とても重要です。

そのためのプラクティスとして、スプリントプランニング、カンバン、バーンダウンチャート、ニコニコカレンダー、デイリースタンドアップといったスクラムやアジャイルのプラクティスがとても相性が良く、うまく運用することが自分たちのステータスを理解するのに役立ちます。

そして、毎日、ステータスを確認しておりますから、いつでも聞かれたら報告できます。

デイリースタンドアップは、いわゆる朝会ですが、毎日、司会を当番で回します。
チームリーダーのような立場の方が朝会を司会すると、その人に向かって報告をするようになりがちです。
朝会を当番にすると、質問が一方向に集中せず、空中に浮く形になります。
それを一回放置してみると、だれかれと分かっている人が話し出します。
強制的に誰かに発言を促すのではなく、黙る勇気を持つことも時に必要です。
肩に力の入った責任感の強いチームリーダーは、チームが困っていると自分がなんとかしないとと積極的な行動を取りますが、時にはその行動を取らない勇気を持ち、問題をそのまま空中に浮かべてみると、意外な活躍をする人が出てくるかもしれません。
デイリースタンドアップで、毎日、そういった工夫を投入していくと、それぞれがチームへのコンピテンシーを産み、チームのステータスを把握し、自分ごととして、周りに説明できるぐらい見えるような状況を作れると考えます。

タスクはPull

タスクをPushすると、状況を把握しないと、投げっぱなしになってしまいます。投げっぱなしはよくありません。

タスクを投げたら、どうなっているか聞くといった常にこちらからの働きかけが必要となりますから、基本は、Pullをしてもらいます。
どんどん、空中に浮いているタスクを取っていってもらいます。

タスクを空中に浮かすためには、スクラムのリファインメントやスプリントプランニングで、タスクのWhy、What、Howについて、議論が成されており、サイズ感についても共通認識にいたっていることが重要です。
中にはスキルや経験が足らず、認識レベルが低い方もいると思います。
そういった場合は、ペアプロ、モブプロなどを取り入れて、次のスプリントにおける共通認識のレベルを上げていくことが重要です。
自己組織化チームは一日にして成らず、継続的な改善と取り組みをトライし続けることが必要です。
積極的にPullするための共通認識の醸成のために、今はできていなくても、レベルを上げ続けるため、いまのスプリントで分かっている人、分かっていない人で協力して、タスクを進めていくことで、認識の輪が広がり、チーム全体のレベルが底上げされていくはずです。

モブプログラミング

先に触れていますが、チームの共通認識のレベルを上げていくことに、とても役立ちます。
また、自身が取っている行動について、安心感を得られます。
相互に取り組んでいることを良い意味で監視し合い、安心してスプリントを過ごすことができます。

モブプログラミングを取り入れなかった場合、各個人の進捗について、デイリースタンドアップでチームリーダー的なロールの人に向かって報告をしていただく必要があります。

取り入れた場合は、報告していただく必要はなく、チームの誰かが分かっている状態を作ることができます。
結果的に終わったかどうかだけを把握することで事足ります。

モブプログラミングから得られる効果は、数えるとまだ他にもありますが、今回の中では共通認識レベルの向上から、次回からのスプリントでタスクをPullできるようになっていくことや、良い意味での相互監視により、自己組織化が進み、チームの中でこの人なら安心して任せられるヒーロー的な存在をどんどん排出していける流れが組めたりするあたりを取り上げます。

任せる領域

タスクをPullして、モブプログラミンをしながら、スプリントを何度か繰り返していると、自然と、この件については、この人といったお任せできる領域がでてきます。
その領域を持っている人を軸に置いたタスクの進め方がパターン化されてくると、周りの人がその人に弟子入りして、免許皆伝となり、次からはその人が軸となって…といった良い流れを作ることができます。
そういった観測も、モブプログラミングなら、いつでも自身が参加することができますから、状況を見て、この人に一度任せられるかもといった観測と、チーム自身からの発言をベースにして、構成していくことができます。
状況によっては、時間を短縮してなんとか仕上げたいといった特急的なタスクのときに、だれか個人でタスクを仕上げていただき、その人しか知らないという状況ができることもあるかと思います。
その場合でも、新に弟子入り制度を設けて、ペアプロ、モブプロを活用して、次の引き継ぐ人、免許皆伝となる者を作っていくことで、その人しか知らない単一障害点を防いでいく働きかけができます。

自身も含めてエンゲージメントを高める

ここまでの取り組みを通して、自身が組込まれていてもいなくても、自走するような流れを蒸留することができれば、自身もその流れに乗り、タスクを積極的にPullしていきます。

そうすることで、自身もエンジニアリングしながら、弟子を取ったり、弟子入りしたり、モブの一員でドライバしたりと、めくるめくエンジニアリング活動を継続することができます。

ただし、全体を俯瞰する視座を忘れてはいけません。

自走しているとはいえ、仕組みが健全であるかどうか、計測し続ける取り組みは必要です。

この俯瞰の視座は、チームの中で没頭すると見逃しがちですから、スクラムのふりかえりを効果的に計測とフィードバックの場として取り組みましょう。
仕組みを見直す観点の話題も定期的に取り入れながら、仕組みとしてトライを検討していく動きも必要と考えます。

まとめ

書きはじめると、とりとめもなく、あまり整理されていない書きっぷりに、自身も驚きと反省をしております…

まとめると、自身はEngineerでありたいと言っても状況が許さないManagementを求められる場合、可能な限りチームが自走して自身のManagement対象がシステムに向くようになり、メンテナンスを定期的に施す状態を作ることで、エンジニアリングに集中できる環境を作ることは可能です。

それをどこまで続けられるかは、プロジェクトやプロダクトの状況や成長などフェーズによって受け入れられないことも、充分ありえます。
とはいえ、そこにチャレンジせず、漫然と今まで通りのマジメントを続けていてもだめで、Managemenにエンジニアリングを注入して、自身を保ち続ける取り組みにチャレンジすることは、とても大事だと思います。

以上です。