「プロジェクトが遅れているなら、進捗会議を増やして細かく管理しよう」 「メンバーが迷っているなら、私が正解を教えて指示を出そう」
もしあなたが、部下やチームに対してこのようなアプローチをとっているなら、残念ながらあなたはDX推進の「ボトルネック」になっている可能性があります。
既存事業のオペレーションを回す上では、正解を知っている上司が指示を出し、部下がそれに従う「コマンド＆コントロール（指令統制型）」は有効でした。しかし、正解のない新規事業やソフトウェア開発において、このスタイルは百害あって一利なしです。
今回は、スクラム開発における「スクラムマスター」という役割を題材に、不確実な時代に管理職が身につけるべき**『サーバント・リーダーシップ（奉仕型リーダーシップ）』**について解説します。
1. 「正解」を教える上司はもう要らない
従来の理想的な上司像は、「部下よりも知識があり、正しい答えを持ち、的確に指示できる人」でした。 しかし、技術の進化スピードが人間の学習能力を超え、市場の変化が予測不能になった今、一人の人間（上司）が全ての「正解」を持っていることなどあり得ません。
上司が答えを出そうとすればするほど、以下の弊害が生まれます。
- 意思決定の遅延: 全てを上司にお伺いを立てるため、スピードが落ちる。
- チームの思考停止: 「上司が言う通りに作ればいい」となり、現場の知恵が出なくなる。
- 責任の転嫁: 失敗したとき、「指示通りやりました」という言い訳が生まれる。
DX組織において、マネージャーがすべきことは「正解を教えること（ティーチング）」ではありません。**「チームが自ら答えを出せるように導くこと（コーチング）」**です。
2. 「スクラムマスター」は管理者ではない
アジャイル開発のフレームワーク「スクラム」には、リーダー役として「スクラムマスター」が存在します。しかし、彼らはプロジェクトマネージャー（PM）のように進捗を管理したり、作業を割り振ったりはしません。
彼らの仕事は、「チームが成果を出すための障害物を取り除くこと」。ただ一点です。
- メンバーのパソコンのスペックが低くて作業が遅いなら、稟議を通して買い換える。
- 他部署からの急な割り込み仕事が入らないよう、盾となって守る。
- 会議が長引いているなら、ファシリテーションをして時間を短縮する。
チームの上に立って命令するのではなく、チームの下から支え、彼らが全速力で走れる環境を整える。これが「サーバント（奉仕者）」としてのリーダーシップです。
3. 今日から実践できる「3つの行動変容」
では、従来の「管理職」から「サーバント・リーダー」に変わるためには、具体的に何を変えればいいのか。
① 「どうすればいい？」に答えない
部下から「これ、どうしましょう？」と聞かれた時、反射的に答えを言わないでください。 代わりに**「君はどうするのがベストだと思う？」**と問い返してください。 最初は時間がかかりますが、これを繰り返すことで、部下は「相談する前に自分の意見を持つ」ようになり、やがて自律的に判断できるようになります。
② 「監視」ではなく「観察」をする
「サボっていないか」を監視するのではなく、「何に困っているか」を観察してください。 表情が暗いメンバーはいないか、議論に参加できていない人はいないか、特定の作業でいつも詰まっていないか。 観察によって得た気づきをもとに、「何か手伝えることはあるか？」と声をかけるのがリーダーの仕事です。
③ 権限を「手放す」勇気を持つ
「任せる」と言いつつ、最後の承認印は自分が握っている。これは偽りの委譲です。 リスクの許容範囲（ガードレール）を決めた上で、**「その範囲内なら、君たちの決定が最終決定だ。失敗しても私が責任を取る」**と宣言すること。 権限を手放すことは、コントロールを失うことではありません。チームのポテンシャルを解放することです。
まとめ：リーダーの仕事は「不要になること」
パラドックスに聞こえるかもしれませんが、サーバント・リーダーの究極のゴールは、「自分が居なくてもチームが回る状態」を作ることです。
チームが自ら課題を見つけ、自ら解決策を考え、自ら改善していく。そうなれば、あなたは現場の管理から解放され、より本質的な「組織全体の戦略」や「外部環境の変革」に時間を使えるようになります。
まずは明日、部下に指示を出すのを一度だけ我慢し、「君たちで決めてみてくれ」と言ってみてください。そこから組織の変革は始まります。
次回は、チームのパフォーマンスを最大化するために不可欠な**『心理的安全性』**の設計技術について解説します。
コメント