マネジメントスタイルの違いがもたらす「圧倒的スピード感」の違いと「楽しさ」
最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか？ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。
海外企業のリーダーシップスタイルの変化
ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。 従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。
この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。
マイクロソフトに入社して感じた事
私はアジャイル/DevOpsのコーチをしていたので、サーバントリーダーシップに関してはおなじみの概念だったのだが、マイクロソフトに入って気づいたことがある。マイクロソフトはソフトウェアのチームだけではなく、会社全体が「サーバントリーダーシップ」スタイルだ。ビジョンや、戦略、KPIは明確だが、誰も指示をすることは無い。現場のメンバーが日本企業とくらべると、かなりの権限を与えられて、どう実行するかを考えている。これはインターナショナルチーム、日本チームどちらもそうだ。
日本はマネジメントの世界でも遅れている
私もマイクロソフトのことしか知らないので、詳細は分からないが、他の外資系に努めている友人に聞いても、こういうスタイルという事らしい。「コマンドアンドコントロール」型の管理は今ではオールドファッションと呼ばれているようだ。個人的意見だが、日本もそろそろサーバントリーダーシップ型に移行してもよい気がしている。ロッシェル・カップさんの下記の本は非常に興味深いのだが、そこでも、日本のマネジメント技術が低いこと、マイクロマネジメントが横行していること、権限付与のレベルが低いことが指摘されている。
また、書籍で、「社員」と「ステークホルダ」という表が乗っていて、とても興味深い。コマンドアンドコントロールは、メンバを「社員」として扱い、サーバントリーダーシップのチームメンバは、「ステークホルダ」として扱われる。
自己組織チーム / フィーチャーチーム
スクラムやDevOps の世界では、チームに強い権限を与えて、ソフトウェアに関する決定は、そのチームが行う。「コマンドアンドコントロール」スタイルだと、上司の承認とか説得とかあったかもしれないが、チームを「信頼」して「任せる」スタイルになっている。このようなスタイルのメリットとしては次のような要素がある
- 生産性が高い
- チームのエンゲージメントが高い
- よりよいソリューションが選択されやすい
生産性の高さ
最初の生産性が高いということは、「コマンドアンドコントロール」時代だと、リーダーの承認や、説得、日本だと合議・根回しもあるかもしれないが、とかく何かを決定するのに時間がかかる。これは、現在のソフトウェアのデリバリのスピードを考えると致命的だ。 だから、チームを信頼して、チームでビジネスの仮説や、仕様、そして、そのアーキテクチャ、使用する技術を決定していく。タスクの割り振りもチームが自らやっていく。基本的にチームメンバーがやりたい仕事を「自分がやるよ」と選択していく。
エンゲージメントの高さ
インターナショナルチームの基本は、メンバーが「楽しんでいる」か？はすごく重要視されているので、メンバーは楽しめる仕事をプロとして実施して、主体的に考えて仕事をする。だから「やらされる」仕事より圧倒的に「楽しい」し、「自分がやっている感」がある。正直な話やらされている仕事なんて何にも面白くない。
だから、こういった「自己組織チーム」は、エンゲージメントが高い傾向にある。ロッシェルカップさんの先の書籍を読んでもやはり、日本のマネジメントはまだコマンドコントロールが主体だが、海外だと、サーバントリーダーシップ型になっていて、そういう点もチームメンバのエンゲージメント（満足度）に大きく影響していると思われる。単純な話、自分が面白いと思うことのほうが生産性は何倍も高くなるだろう。
良質なソリューション
最後に、よりよいソリューションが選択されやすい点だが、これは単純で、現在の技術は日進月歩で、それを一番把握しているのは、そのツールや言語で毎日コーディングをしたり運用しているメンバである。つまりチームメンバが一番知っている。何年も前にプログラマを引退した人では鼻が利かない。だから、現場で様々の選択をしてもらうのが一番質がいいことになる。稀にリーダーが一人で判断したほうがいいと感じることもあるかもしれないが、それだと、チームが指示待ちになって、何も考えなくなってしまう。いつまでたってもリーダーの指示が必要だ。
ただし、リーダーでも、例外的に技術に対して超人的に鼻が利く人もいる。グルーブノーツの最首さんはその例だ。しかし、彼も社長をやっているが、自分で様々な技術をハックしたうえで、チームに技術を推薦している。それも特に押し付けではない。
エンゲージメントの重要性
日本では、我慢が大人、西洋では、自分で自分の考えで人生に責任を持つのが大人であり、雇用制度も異なっている。日本に閉じている場合は、ロッシェルさんの本でも示されているが、日本のエンゲージメントの低さはそんなにダメージがないと考えるかもしれない。
しかし、海外に進出したときはどうだろう？近年海外にオフショアしている企業も多いが、現地のエンジニアは、日本ほどエンゲージメントが低くない環境にいるので、自分が面白くないと、当然他のもっと楽しい企業に流れてしまうだろう。プログラマの生産性は10 - 25倍の差があるといわれている。「低いスキルの人」に全体を合わせる時代は終わって、より全体の生産性を高めていく、そのためにも、メンバーがエンジョイできる環境を作り出すということが重要になってくる。実際私も上司からは指示は一切なく「エンジョイしてるか？」ということは頻繁にきかれる。人をコントロールしようとする時代は終わったのだと思う。
simplearchitect.hatenablog.com
おかげで私は自分の考えで、自分で判断して仕事ができている。とても楽しい。はっきり言ってDream Jobだ。
Damienとのレビューでの出来事
先日年次レビューがあって、小さなことかもしれないけど、自分的には感動的な体験をした。Damienは、日本での私の成果をとても喜んでくれいる様だった。彼がとてもほめてくれるので、私は彼に「私の力じゃないよ。Damienが凄く助けてくれたからだよ。」という話をしたらDamienはこう言った
誰が、Hackathonをやったんだ？de:codeで他のイベントで凄いインパクトを出したのは？みんな君がやったことじゃないか。僕じゃない
私はADHDで普通の人が出来ることができない。だから、Damienは凄く私のカバーをしてくれているのを知っている。そんなことを一言も言わす、「みんな君がやったことだ」と彼は言い切った。当時Skypeミーティングだったが、不覚にもいろんなことを思い出して泣いてしまった。彼は初対面の私を信じて一切を任せてくれた。過去も素晴らしい人に囲まれていたがこれほどのことは初めてだ。あれはダメ、これはダメと子ども扱いされる職場と比べると凄い差じゃないだろうか。
こんな気持ちになれる会社と「言われたことをただ単にやればいい」という会社では、採用できるメンバーに大きく差が出てくるのは当然ではないだろうか？今は国内だけだから、成り立つかもしれないが、こういった事情に気づいた人が、どんどん海外の「楽しい」職場環境を求めて日本を去る人が増えてくるのではないだろうか？
ソフトウェアチームレベルに留まるスクラム
先日英語の記事だが、「スクラムがアジアでは機能しない」というポストを見かけて大変興味深く読んだ。私が特に印象に残ったパートは、「欧米では、組織にスクラムを導入しているが、アジアでは、ソフトウェアチームでの導入に留まっている」という箇所だ。 これは、一見「スクラムの原理主義」みたいに聞こえるが、そうではない気がしてきた。私も昔は、スクラムを会社全体に入れるという話を聞いたときは、「スクラムは、ソフトウェアの方法なのだから、何にでも適用するのは違う」と思っていた。今はもしかすると、そういうニュアンスではないのではないかと思い始めた。
組織でスクラムをしていない意味
「自己組織チーム」を作るためには、ソフトウェアチームだけを変えても機能しないことに気づく。例えば、折角チームが自己組織チームであっても、その上のマネジメントが「コマンドアンドコントロール型」の管理を続けていれば、そのチームを「コマンドアンドコントロール」しようとしてしまうだろう。上位マネジメントはそうでもなくても、中間のマネジメントの方が、コマンドアンドコントロールしてしまうかもしれない。人事制度も、「自己組織チーム」で仕事をすること前提のものに変えていかないと、不公平感が出てしまうかもしれない。
また、アジャイル以降のパラダイムでは、「計画」や「納期」に関する考え方も大きく異なる。この辺りは次回のポストで解説したい。
つまり、「自己組織チーム」は単にソフトウェアチームをそのような形態にしたらいいだけではなくて、効果を出すためには、その周囲も変えていかないといけない。これが、「ソフトウェアだけにスクラムの導入がとどまっている」ということの意味だろう。
日本で自己組織チームを実践する方法
では、日本で自己組織チームを導入し、実践していくにはどういうTipsがあるだろうか？私の個人的な経験に基づく意見だが、記述しておきたい。
トップ層
まず、日本の場合は、上下関係があるので、出来るだけ上の方のOKを取り付けるのが良い。そして、アジャイル / DevOps などを推進するコミットを得て、それをしっかり資料化するのをお勧めする。どういった理由で、それを導入するのか、何を目指しているのか？また、定期的にステータスを報告することを約束しておくとより安心していただけるだろう。他には、可能であれば、バリューストリームマッピングなどの手法を使うと、例えばリードタイムの短縮など目に見える効果を提示することも可能だ。
ミドル層
サーバントリーダーシップ型への転換で一番抵抗が激しいのがこの層だ。しかし、それにはれっきとした理由がある。トップ層は、自分のKPI的には新技術を導入するとか、様々な変革をするミッションがあるのでサポーティブになりやすい。しかし現場のマネジメントからすると、プロジェクトやサービスごとに数字を持っているので、当然自分の慣れていない方法で新しいことを始めるのは相当勇気がいるはずだ。だから、トップ層でも書いたが「トップ層」が明確に「自己組織チーム」で「サーバントリーダーシップ型を推進する」とコミットしていたら、ミドル層も、そちらに進みやすい。
また、ミドル層の方が反対する理由は、大抵は「石頭」とかではなく「不安」があるからだ。そらそうだろう。今まで慣れ親しんだ方法じゃない方法で、リーダーシップを発揮しなければならない。だから、「それはアジャイルだから」とか「それはスクラムで決まっているから」とかではなく、彼らの不安に耳を傾けて、それに答えていく必要がある。そして、しっかりとトレーニングをすると、過去のマネジメント経験も生きて、新しいサーバントリーダーが誕生しやすくなる。そうやって、いったんサーバントリーダー型になると、細かいことを計画・管理しなくてよくなるので、ビジョンや戦略や改善などより本質的な部分に注力することができるようになる。
できれば、KPIもサーバントリーダーや、自己組織チーム前提にするのが望ましい。
また、進捗報告など、アジャイルやDevOpsサービスではどうすればいいかを具体的にお話ししておくと、安心してもらえやすい。大体私がやりがちなパターンは、「スピードチャート、開発進捗サマリ、課題」程度の報告にとどめている。しかし、それらがあれば、終了の見込み、全体像、課題がわかるので、シンプルながら十分だ。下記の資料のP42, P43あたりのイメージだ。
チーム
最後にチームだが、「自己組織チーム」になっても、大抵の場合は、今まで「指示」を受けて動いていた人が多いので、自ら考えて、行動する習慣を持った人が少ないことが多い。だから、最初は自己組織チームになっても、みんな「どうしたらいいんだろう」という雰囲気になることが多い。そういう場合は、誰かが「ファシリテーター」役になって、行動を促進する質問をするといい。最初は「どう考えたらいいかわからない」と言わることもある。彼らに「アドバイス」をするのはよいがそれはあくまで「彼らが求めたとき」にする。 その前に「質問しやすくする空気」を作っておくのは効果的だ。私はよく「Ask For Help」の話をする。次のブログ参照してほしい。すると、メンバーが「あ！気軽に質問していいんだ！」と思えるようになってくるので、どんどん質問がやってくるようになる。
simplearchitect.hatenablog.com
指示待ち系の人も多いが、そのような場合も「じゃあ、○○さん、どのタスクやっときます？」とか、こちらが指示するのではなく、あくまで彼らを「促進」するようにだけする。決定はあくまで本人だ。アーキテクチャの議論をしていても、年上の人に遠慮して、本当に思っていることを言えなさそうにしている人がいることを発見するかもしれない。そしたら例えば「○○さん、このアーキテクチャの議論で、気になっていることはありますか？もし、ほんの小さなことでも結構なのですが、ちょっとでも気になっていることがあったら共有してくれませんか？」ぐらいのニュアンスで「促進」すると、少しづつ話をしてくれるようになったりする。
また、本当は「自己組織チーム」で自分たちに決定権限があるのに、「会社のルールで決まっているから無理」と自主規制してしまうケースもある。その場合は、上の人を連れてきて、その人から、「変えちゃっていいよ！」ということを言ってもらうようにする。そうすれば、徐々に「あ、会社のルールも変えようと思ったら変えられるんだ、自分で考えて自分で仕事をやったらいいんだ」ということに全員が徐々に気づいてくる。これにはプロセスは変えていいんだと気づくことができる副作用のあるバリューストリームマッピングのセッションも有効だ。
こんなことをしていくと、明日からスグという感じではないが、１週間もたつと「自己組織チーム」にチーム自体が慣れてくる。
他にも、自己組織チームのはずなのに、何となく上下関係を感じる場合がある。そうすると、チーム内部で指示待ちが発生してしまうことがある。ポイントは、チーム内ではスキルや経験に関係なく、全員が同じ責任を持っているフラットな「仲間」としてふるまうことだ。最初の「社員 vs ステークホルダ」を思い出そう。 もちろんスキル差があるのは事実だが、聞いてはいけないということではない。「指示」をうけるのではなく「主体的に聞く」ことが必要なのだ。そして、目上の人も「教えたくなるのを我慢」することだ。「考える」のはそれぞれの仕事で、「考えてあげる」のは相手を子供としてみなしていることになる。新人であっても「（西洋の）大人」として扱おう。
チームにパワーを持たせる価値
海外の同僚の活動を見ていると気づくことに、日本以外の国は「開発者」「運用者」つまり現場の人が技術や方法論選定のパワーを持っている。日本は「マネージャ」が決めるので、「開発者」「運用者」の決定権がない。しかし、新技術導入のペースを勧めるために必要なのは、そこに対して鼻の利かない人の承認ではなく、彼らを「信頼」して「任す」ことによって「現場」がパワーをもって、チームが自ら考え意思決定していく組織にある。 チームが自ら判断していけば、新しい技術の導入も、新しいチャレンジも活発化されてくる。
「自分で指示するほうがチームメンバーを考えるとよいと思う」とか「チームメンバーは指示待ちだから厳しいと思う」とか「自分勝手な行動をチームが取り始めたらどうするのだ」という意見もあると思う。
それでも私は「自己組織チーム」をお勧めしたい。１人が、他人に対してすべての要素で優れているということはほぼ無いだろう。だから、みんなのCPUを結集して問題解決に当たるほうが効果が出やすい。
「指示待ち」ということに関してはその通りの場合もあるかもしれないが、「人間は成長する」ため、「できない人を何とか管理」という方向性ではなく、「できる人」にする方向性のほうが、人による生産性の違いが10-25倍と言われるソフトウェア開発の場合は、効率的な気がする。「できない人」に焦点を合わせるといつまでたっても生産性は上がらない。
最後に何より、チームメンバーが「仕事を楽しめる」ことだ。これが最も自分的に大きい。私だったら指示されて仕事するなんて面白くもなんともないのでまっぴらごめんだ。自分の意志で自分で選択した仕事をプロフェッショナルにこなしていきたい。あくまで個人的な意見ではあるのだが、私はそう考えている。
日本に合わせるのではなくルールを変える
こういった「サーバントリーダーシップ」の考え方なども、現在の日本の組織や、ルールになじまないように感じる。ここで「できない」というのは簡単だが、そうやっている間に、海外とどんどん差をあけられていくのも確かだ。しかし、会社のルールなんて所詮どっかのおっさんが過去に決めたものだ。過去にはそのルールは有効だったが、現時点でそのルールが有効かは分からない。ルールは目的があったはずで、それに人間が縛られるのはナンセンスだ。東洋の端っこの小さな「日本のやりかた」にこだわるよりも、私は自分がより良い仕事をして楽に成果を出せるようにしたい。世界の基準でよい仕事ができるようになって、もっと世界に貢献したいなと思う。
次回は、自己組織チームに関係する、計画や、納期の考えの違いに関して整理しておきたい。
