ヒエラルキー組織とスクラム
世界ではヒエラルキーからフラット、ネットワーク、ホラクラシー、ティールなど様々な組織体がありますが、日本はまだまだヒエラルキー組織が多数を占めていると思います。
そんな私が属する組織もスクラムを導入して3年が経ちました。
結果、ヒエラルキー組織でもスクラムを実施することはでき、たくさんのいい効果を生み出しました。
一方で、今までの組織の考え方とスクラムの考え方とで課題も多々発生もしました。
この記事ではそんな課題にになった3つのことをまとめます。
- 組織体との関係
- 評価制度と組織のベクトル
- プロジェクトとプロダクトとの関わり
スクラムのはじまり
私の務める会社も典型的なヒエラルキー組織で、各開発1チームに1人のマネージャーいて、更に上に部長、更に上へと組織体が続いています。
導入初期は、開発部の数チーム（1チーム5名ほど）をそれぞれをスクラムチームとしました。イメージとしては以下のとおりです。
開発部（部長：プロダクトオーナー） |- Aチーム（マネージャー：スクラムマスター） |- Bチーム（マネージャー：スクラムマスター） |- Cチーム（マネージャー：スクラムマスター） |- Dチーム（マネージャー：スクラムマスター）
プロダクトは一つ、プロダクトバックログも一つ、プロダクトオーナーも一人です。
まずはLeSSに近いこの形でトライしてみることになりました。
1. 組織体との関係
スクラムマスターとマネージャー
組織体で大きな問題になったはマネージャーという存在でした。
我々の組織のマネージャーはチームと個人を成長させるとともに、プロダクトにコミットをしています。
一方、スクラムマスターは「プロダクトオーナーとチームが、スクラムを最大限に活かせるようにスクラムの理解と成立に責任を持つ。」というのが役割です。そのためには、チームや個人を成長させたり、課題を解決したり、導いたりと多岐に渡ります。
そうなんです。役割が若干被っています。
スクラムを導入する上でどうすればいいのかという議論がありました。
スクラムマスターとマネージャーを分ける
スクラムマスターはチームから1名選出し、マネージャーはそのままチームをマネジメントする形です。
この形は大失敗でした。
スクラムマスターとマネージャーでどちらがどこまでを担当するのかという境界が引ききれず、スクラムマスターは自由に活動ができなくなってしまいうまくいきませんでした。
境界を明確に引くのも難しいですが、そこに境界を引く時点でスクラムマスターの活動を制限することになってしまうので、この形はナンセンスだと感じます。
スクラムマスター = マネージャーとする
スクラムマスターは評価者ではあってはならないという原則に反するが、チームを束ねる立場でもあったので進行はやりやすいと考えました。
確かに当初はやりやすかったのは事実ですが、スクラムマスターの中立的にプロダクトオーナー、開発チーム、組織を支援するというよりも開発チームを支援するということに注力してしまう傾向が強くなってしまいました。
ベストな形というのはまだ見つかっていませんが、スクラムマスター=マネージャーのほうが組織的にはまだやりやすいです。
スクラムマスターとしてはこの組織の形も変えていくというもミッションです。このアクションはまだまだ時間がかかりそうですね。
スクラムマスター1人で複数チーム
認定スクラムマスターでも話がありました。
1つのチームを回せないのは、三流のスクラムマスター
複数のチームを回すのは、二流のスクラムマスター
1つのチームを回せるのは、一流のスクラムマスター
スクラムマスダーさんが記事まとめているとおり、1チーム1スクラムマスターとなるのが理想的です。
そのため、まだこの選択肢は選んでいません。
スクラムが越境するには
スクラムと他部署へと広げていく。というのは、本のようにうまくはいかずなかなかスクラムは理解されませんでした。
業務が近い部署にさえ受け入れてもらうのは時間がかかりました。
従来のやり方に慣れ親しんでいる人たちにとって、スクラムというのは一種のアレルギーのような拒否反応を生むこともあります。何か問題が起きるとそれがスクラムのせいにされてしまうのが非常に悔しかったです。
後述するクロスファンクショナルチームに対して、他部署が関わると誰にお願いをしていいのかわからないという問題が起きたのも事実あります。
結局の所、1年半かけて少しづつ周りの部に受け入れてもらえたので、3年目のこれからさらに遠くの部署へ広げていこうと考えています。
ヒエラルキー構造体を跨いでスクラムを広げていくとうのは、普通にやると相当時間がかかってしまいます。早く広めていくにはで何かしら工夫が必要だと思います。
2. 評価制度と組織のベクトル
評価は課題があるのか
私の会社はMBOで四半期に一回マネージャーが評価しています。
スクラムでは360°評価などが適していると言われているようですが、評価でそこまで大きな問題は発生していません。
スクラムマスターが評価者の場合、スクラムマスターとしてのサポートが指示と捉えられたり、評価を得るためにチームが動いてしまうということが起きると言われていますが、我々の組織ではそのようなことは起きなかったです。
問題は目標
目標はヒエラルキー上層の目標を個人までブレイクダウンして落としていますが、チーム目標を明確に作成する仕組みを設けていませんでした。
そのため、自己組織化したチームが裁量を持っても、組織とチームでベクトルがずれることが発生してしまいました。
解決法としては、個人目標の見える化やOKRなどを利用して、上位目標からのブレイクダウンをチーム目標に掲げるということをトライしてみようと考えています。
3. プロジェクトとプロダクトとの関わり
タスクフォースによる混乱
私の会社ではプロダクト開発としてのチームの他に、プロジェクト単位でタスクフォースを編成することがあります。
開発1チームではどうしてもリソースやスキルセットなどが合致しないので、複数チームから招集してタスクフォースという背景です。メンバーはスクラムチームにも所属し、プロジェクトチームにも所属している状態になります。
これは、私の会社のスクラムを壊しかけました。
原因は、タスクフォースメンバーのタスクが、自スクラムチームでは見えづらいタスクと化してしまったのです。（闇タスクと呼ばれていました）
タスクフォースはタスクフォースで、ウォーターフォールをしたりベンダーコントロールなどで無数のタスクを管理しています。
それがスクラムチームに詳細に共有することがうまくできなく、同じスクラムチームなのにメンバー同士よくわからないことをやっているという状況に陥ってしまいました。
「我々をスクラムをやることが目的になってしまっていないか？」
とよく議論されていました。
兼務状態になっているのがアンチパターンではあるのですが、スクラムマスターは闇になってしまっているタスクをクリアにすることに手腕を問われます。
大規模なタスクフォースはベンダーコントロールも入ってきていたので、これを自チームに反映するというのは、タスクの二重管理も起きて時間と労力がかかります。
スプリント毎に自チームでの可動可能時間を減らす、タスクフォースの稼働分をざっくり自チームのストーリーにも足すなどトライしました。
これもベストプラクティスが見つかっていませんが、可動可能時間を減らす方がシンプルでまだいいかなと思っています。
クロスファンクショナルチームと責任
LeSSを意識していたのもあったので、クロスファンクショナルチームの編成にして、1チームでどんな案件も対応できるという形を目指しました。
中規模案件などを1チーム行うとものすごいうまく周り、チームの結束も高まりとても評価できるものでした。私はいまでもこの形は素晴らしいと思っています。
一方で発生したことがあります。
各コンポーネントごとの責任をどこのチームが持つのかが不明瞭になることです。
プロダクトの責任は全員で持つというのはわかるのですが、その末端にあるコンポーネントでも同様に誰かが責任を持って促進していく必要があります。
クロスファンクショナルチームなために、どこのチームでもできる＝自分のチームじゃなくてもできるという力が働いてしまい、重めのコンポーネントのタスクが敬遠される、障害が発生しても誰も手を付けないということが発生しました。
また、他部署からはどのチームに何をお願いして良いのかがわかならないということも起き、最終的にクロスファンクショナルチームからコンポーネントチームに戻すことになりました。
ベンダーとスクラム
大規模案件などベンダーと一緒に開発することが多々あります。
ロケーションが異なる、人員の入れ替えがあるなどの理由で、どうしてもスクラムを一緒にやりずらいことになります。
今の取り組みとしては、ベンダーのリーダーは一緒のスクラムチームでプロジェクトを進行する形でトライしようと考えています。
ベンダーも巻き込んでのスクラムの勉強も必要なので、大変な労力にもなりますがこの一歩が次のプロジェクトに繋がると信じています。
そして現在
私の会社でのスクラム歴史を整理すると下記のような感じになります。
- スクラム導入
- クロスファンクショナルチーム編成
タスクフォースの問題が発生 - 近くの部署にも受け入れてもらえる
コンポーネント責任の問題が発生 - コンポーネントチーム編成
- 目標に課題を感じる
- 他部署に少しずつ広がる
スクラムチームの形としては、コンポーネントチーム単位でスクラムチーム作り、各チームにプロダクトオーナーを配置するという形で落ち着いています。
開発部（部長） |- Aチーム（マネージャー：スクラムマスター、別部署：プロダクトオーナー） |- Bチーム（マネージャー、カンバン） |- Cチーム（マネージャー：スクラムマスター、別部署：プロダクトオーナー） |- Dチーム（マネージャー、カンバン）
コンポーネントチーム編成のタイミングで、スクラムを実施するか否かもチームに任せています。
これはチーム自身でスクラムを選択して実施したほうが、課題が発生した際にスクラムのせいにはせずに、工夫して乗り越えることができると期待しているからです。 いざ自由にするとカンバンだけが残ったり、スクラムをやり続けるチームもあったりと様々です。
必要と感じているチームだけだがスクラムをやっているので、「我々をスクラムをやることが目的になってしまっていないか？」 という声はもう聞こえなくなりました。
各チームにスクラムのエキスは残っており、どこかのタイミングでまた全チームがスクラムができたら良いなと思っています。
さいごに
冒頭にも書いたとおりですが、ヒエラルキー組織でもスクラムはできます。
スクラムのフレームワークをどう自分たちの組織に適応するかというのが大事になるので、みなさまの会社でも柔軟にいろいろトライをしてみてください。
スクラムを導入して3年経って思うのが、やはり強力で魅力的なフレームワークだなと思います。
一例を上げると下記のようなものですが、本当にそれを感じることができます。
- 自己組織化したチームができる
- 早いサイクル価値ある開発ができる
- 変化に柔軟に対応できる
- 誰が何をやっているのか全て把握できる
- チームの課題を発見できる
- チームがチームを改善していく
- カオスなプロジェクトに絶大な威力を発揮する
ヒエラルキー組織でスクラムの壁にぶち当たった方の参考嬉しい限りです。
