日本のIT に物申す：ソフトウェア・エンジニアの上司はどうあるべきか？　イベントレポート　[Part 1]

この記事では2024年12月11日に六本木のコードクリサリスキャンパスとオンラインの同時開催で行われた対談イベント「日本のITに物申す：ソフトウェア・エンジニアの上司はどうあるべきか？」をレポートします。

今回のテーマは「ソフトウェア・エンジニアの上司はどうあるべきか」でした。一流のエンジニアには、一流の上司が必要です。それでは、ソフトウェアエンジニアにとって、どのような上司が理想的なのでしょうか？彼らのやる気を引き出し、成長、貢献、そして達成を可能にする環境を作る上司は、どのような行動を取るべきなのでしょうか？

対談を行ったスピーカーは以下の2名です：

ロッシェル・カップ（聞き手）
ジャパン・インターカルチュラル・コンサルティングの創立者兼社長。リーダーシップ、異文化理解と人事管理を専門とする経営コンサルタントとして、グローバル企業の人材育成とチームビルディングを支援。イェール大学歴史学部卒業、シガゴ大学経営学院卒業。日系大手金融機関の東京本社における職務経験があり、現在日本企業２社の社外取締役を努めている。『ＤＸ時代の部下マネジメント―「管理」からサーバントリーダーシップへの転換』（経団連出版）をはじめ、著書は多数。

牛尾剛
米マイクロソフトAzure Functionsプロダクトチーム シニアソフトウェアエンジニア。シアトル在住。関西大学卒業後、大手SIerでITエンジニアをはじめ、2009年に独立。アジャイル、DevOpsのコンサルタントとして数多くのコンサルティングや講演を手掛けてきた。2015年、米国マイクロソフトに入社。エバンジェリストしての活躍を経て、2019年より米国本社でAzure Functionsの開発に従事する。著作に『世界一流エンジニアの思考法』などがある。ソフトウェア開発の最前線での学びを伝えるnoteが人気を博す。

それでは、対談の内容のPart 1を以下にご紹介します。

********************

ロッシェル：牛尾さんがなぜマイクロソフトのシアトル本社で働くようになったのか、これまでの道のりについて教えていただけますか？

牛尾：最初はSIerとしてスタートしましたが、そうするとプログラムとか組めない。マネジメントだけで発注とかが仕事でした。そのあと豆蔵っていうところのITコンサルタントを経て、自分で会社を立ち上げました。ちょうどその頃、英語を勉強したくなって、勉強したら今度はそれを使いたくなって、日本のマイクロソフトに入りました。その後シアトルにリロケーションが決まって、アジュールを開発するプロダクトチームに社内転職して、今はエンジニアとしてプログラムを書いて、幸せに感じています。もともとプログラマーになりたかったので。

ロッシェル：夢を実現できた、ということですね。素晴らしいです。2016年にご一緒したプロジェクトは牛尾さんの提案でしたよね。その内容についてご紹介していただけますか？

牛尾：マイクロソフトは自分にとって生まれて初めての外資系企業でした。初めてのインターナショナルな環境で、上司はフランス人、同僚にも日本人は一人もいないという状態でした。そんな中で、いろいろ衝撃的に違うことを経験しましたが、それが生産性に大きく影響しているのではないかと考えるようになりました。大体の著名な技術本はアメリカから来ますが、時々その内容を見て日本でワークするとは思えないと思うことがありましたが、このような「違い」を理解したらそれは当然出来るという発想になりました。それらの経験をもとに、ロッシェルさんにプロジェクトに参加してもらう形になりました。

ロッシェル：なぜ私だったのでしょうか？

牛尾：それはやはり、異文化交流といえばロッシェルさん、と思いましたので。一緒に仕事をすることで、より大きなインパクトを提供することが出来ればと考えてのことです。

ロッシェル：ありがとうございます。私にしてみると、牛尾さんと仕事をご一緒したことで、ソフトウェア開発の環境やアジャイルソフトウェアについてもっと深く知ることが出来るようになりました。アメリカ企業では当たり前のことでも、日本企業ではそうではない、ということもいろいろあります。その中の一つに管理方法、リーダーシップがありますが、今日はそれについて話し合っていきたいと思います。では、牛尾さんに質問させてください。

ロッシェル：これまでの上司の中であなたに良い影響を与えた人を思い浮かべて、その人がどのような行動や態度をとっていたかを、具体的に教えてください。

牛尾：マイクロソフトに入ってからいろいろ衝撃的に違うことがありました。１番の違いはリーダーシップのスタイルがコマンドアンドコントロールではなくサーバントリーダーシップであるということ。

ロッシェル：聞いたことがない人がいるかも知れないので、コマンドアンドコントロールとサーバントリーダーシップの違いについて話していただけますか？

牛尾：上司が「これをやってくれ」と頼む形がコマンドアンドコントロールです。日本人だと多分普通に考えていると思います。マイクロソフトではそれが全然なくて、上司は何も指示を出しません。自分で何をやるかを決めて、上司はそれをサポートしてくれる、という形です。これがサーバントリーダーシップです。本で読んだことはありましたが、実際に体験したのは初めてでした。新人であってもベテランであっても、最初から最後まで全部自分で責任を持ってプロジェクトを進めます。まず何をするのかを明確にしなければなりません。それに基づいて自分でプログラムを設計して、実装して、テストして、リリースして、インシデントがあればそれに対応する。これを新人であっても全部自分で対応するわけです。生産性が一番落ちるのはプログラミングの速度ではないと思います。倍の時間がかかる人がいてもそれは構わないと思います。何が一番問題かというと、それはブロッカーです。例えばいくら速くプログラミングを終了しても、それを承認してくれる人が1週間何もしないと、それがブロッカーとなるわけです。このブロックをいち早く取り除く、アンブロックするのがマネジャーの役割です。

ロッシェル：そのためにマネジャーはどんな行動を取るのでしょうか？

牛尾：例えば承認が遅れている場合、マネジャーがそれを喚起してくれることで、それがアンブロックされます。あるいは、何かに行き詰まっているときは、それを解決してくれそうな人を紹介してくれることで、先に進むことが出来ます。またマネジャー自身が直接手伝ってくれることもあります。あらゆる手を使ってアンブロックしてくれるのがマネジャーです。

ロッシェル：つまり、働きやすい環境を整えてくれる、ということですね。では次に、普通の上司と優れた上司の違いとは何だと思いますか？

牛尾：コマンドアンドコントロールの上司だと、自分で考えることが出来ないので、仕事がつまらなくなります。でも自分でいろいろ考えて決めることができる仕事は、とても楽しくなります。

ロッシェル：それはプログラマーにとって特に非常に重要な要素になりますね。

牛尾：それからアメリカに行ってびっくりしたことですが、上下関係というのがない。日本にいるときは如何に上司を説得するかという心理学のテクニックを学ぶことが必要でした。上司を説得しないと何も始まらない。例えば何か新しいやり方を進めたいとしても、上司に言うと「ではまず俺を説得してみろ」と返される。そこで自分はダブルバインドとかミラーリングとか心理学的な方向から上司を説得することを学びました。でもアメリカでは誰を説得する必要もない。上司は自分よりもプログラミングの技術が高い。その上の事業部長も明らかに自分よりも優れた技術を持っている。そんな人たちが自分をサポートしてくれる。だから自分がロジカルに仕事をしていれば、それをすんなり納得してくれる。

牛尾：もう一つびっくりしたことですが、ある時期非常に忙しい時があって、普段はみんな5時に退社するのですが、その時だけは5年間で初めて休日出勤を頼まれました。その直後に360度評価のサーベイがあって、上司の評価がかなり悪かったようなのです。日本では、どうせ何を書いてもどうにもならない、という風潮がありますから、誰も悪い評価をしないと思います。その後、サーベイでワークライフバランスの点数が低かったので、人員が補給されました。つまり、お金をかけて解決策をちゃんと探してくれたというわけです。日本だとそれはないと思います。

ロッシェル：確かにそれはすごいですね。日本ではサーベイを行っても、その結果を改善に繋げることは少ないのではないかと思います。

牛尾：実際にフィードバックがある、というのに感動しました。

ロッシェル：次の質問です。上司がソフトウェア・エンジニアを管理する際にしがちな間違いとは何だと思いますか？

牛尾：知らないことを知っているように振る舞うことかな。それから、自分から指示を出しておいて、結果が良くないと「自分はそんな指示を出していない」と開き直ること。日本の場合、上司が技術的専門知識を持っていない場合が頻繁にあります。そんな時、何かわからないことがあると、部下に素直に教えてくれと言えない上司が多いのではと思います。アメリカの場合、上下関係ではなく、違う役割をする人との対等な関係になるので、知らないことは学ぼうという態度で応じてくれます。

ロッシェル：優れた上司はソフトウェア・エンジニアの技術の向上をどのように支援していますか？

牛尾：半年に一度くらい、今季はこんなことをやってみたい、とかこんな挑戦をしてみたい、ということを話し合う機会があります。それを実現してくれる上司は素晴らしいと思います。例えばある時、サーベイで最近新しいことを学ぶ機会が少ない、ということが指摘されたのですが、その翌日から丸一日勉強に使える日、というのが出来ました。

ロッシェル：ソフトウェア・エンジニアの中で、心理的安全性はどのくらい重要だと思いますか？

牛尾：今のチームで心理的危険を感じたことは一回もありません。失敗した時、上司がどのように対応するかというのは、非常に重要なことだと思います。一度、自分が完成させたプログラムのお披露目をリモートで行ったのですが、前日まで完璧に作動していたプログラムが当日全く作動しなかったということがあります。実はその時使っていたPCに原因があったのですが、上司は大恥をかいたにも関わらず、「君は何も気にすることはない」と言ってくれました。また、Flex Consumption という Azure Functions の新しいサービスを手掛けていた際、相当な時間と労力を注ぎ込んでから、今のプラットフォームではそれが出来ないことがわかりました。その時自分はとてもショックだったのですが、その後、ではそれが出来る新しいプラットフォームを逆に作ろうということになり、結果的にスループットが40倍向上しました。つまり、日本だと失敗は悪いことと考えがちですが、アメリカで体験したのは、失敗はむしろいいことだ、ということです。失敗したくないと思うと、無難なことしか出来ません。何か価値のあることをやりたいのであれば、失敗して当然です。失敗は進化の過程に過ぎません。だから、失敗を責める上司は良くないということになります。

ロッシェル：日本では何かが失敗に終わると、責任を追及したり、皆の前で誰かを叱ったりという、心理的安全性とは正反対なことがよく起こりますね。

牛尾：日本で失敗の責任をとって辞職する、ということがよくありますが、そうすると失敗してせっかく得た知識を持っている人が辞めてしまうことになります。

********************

以上、対談イベント「日本のITに物申す：ソフトウェア・エンジニアの上司はどうあるべきか？」のレポートPart 1でした。続きはPart 2をご覧ください。