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

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

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

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

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

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

それでは、対談の内容をPart 1 に引き続き、Part 2として以下にご紹介します。

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

ロッシェル：日本の上司とアメリカの上司の違いというのは何でしょうか？

牛尾：以前一度、とっても忙しくて首が回らなくなった時、上司にそのことを伝えたら、今やっている中で一番大切なのは何だと聞かれて、その時はDevOpsハッカソンっていうのが一番大切だったのでそう言うと、ではそれ以外は一切やらなくていいと言われました。それは日本ではあり得ない展開です。それを聞いたときは非常に衝撃的でした。おかげでそのプロジェクトに集中することができて、そのチームのワールドで１位が取れて、顧客満足度でも非常に高い点数がついて、昇進もしました。それで上司にお礼を言ったら、「それは君が頑張ったから出来たことだ」と返されました。日本だったら上司が手柄を持っていってしまうところでしょう。当時は感動して泣いてしまいました。

ロッシェル：心が暖まる話ですね。

牛尾：それから、上司から「早くやれ」って言われたことが一回もないです。日本で働いていた時は、すべてに関して納期がありました。でもアメリカでは、ETAを使います。意味はだいたいこれくらいに出来たら嬉しいですね、みたいな感じです。過去に一度、進捗度が遅くてすみませんと上司に謝ったことがあるのですが、逆に「そんなことは気にせずに、自分のペースで自分が納得するものを作ってくれればいい」と言われました。急いでよくないものを作るより、時間をかけていいものを作った方がいいと。

ロッシェル：そうですね、マイクロソフトのアップデートが来たら、それがちゃんと作動しないとユーザがイライラしますよね。問題がないものを出してもらわないと、意味がないと感じます。

牛尾：自分の優先順位の考え方が相当変わりました。昔は生産性イコールたくさんやることだと考えていましたが、今は全然違います。余裕を持った対応ができないと、途中で優先順位が変わった時にうまく対応できなくなります。

ロッシェル：それを理解してくれる上司が必要だということになりますね。それでは最後の質問になりますが、日本のマネジャーに対して何か特に伝えたいことはありますか？

牛尾：最初に計画したことがそのままスムーズに進むと期待するのはお勧めしません。例えばプロジェクトの途中で同じフィーチャーを競合が既に開発してしまったので、それをやっても意味がないとか、ソフトウェアの場合は特に優先順位が非常に動的に入れ替わるのが普通です。日本では計画を遂行するために皆な徹夜したりしますが、重要なのは価値の高いことをすること、計画について柔軟性を持つことだと思います。計画通りに物事を進めることは必ずしもいいことではありません。優先順位が一番高いP0が必ずしもP0のままであるわけではありません。P1やP2がP0に取って代わることもありうるわけです。スタートした時点で予測しなかったことが必ず出てきますので。

ロッシェル：日本ではスタートする前にすべてを予測できると考えがちですよね。でもそれは特にソフトウェア開発には不向きな考え方だと思います。

牛尾：昔アジャイルのコーチをしていた時に面白い体験をしました。ある建設業のIT関係の方が、「1980年代にWBSを設計してそれを何十年も使っていて、もう一切変える必要がない」と言っていました。その人が「でもそれは建築の話であって、ソフトウェアはそういうわけにはいきません。」と言っていました。

ロッシェル：ありがとうございます。それでは、次に会場の皆さんからの質問を受け付けたいと思います。その後引き続き、オンラインでの質問も受け付けます。

参加者A：興味深いお話をありがとうございます。日本とアメリカで上司の違いもありますが、働いている人たち自身の違いというのも結構大きくあるのではと思います。日本の企業で働いている多くの人たちは専門性の高さを持てないでいると感じています。自分だけで頑張っていけるという意識が薄いと思います。そういう人たちには、どうしても計画を立てていつまでにこういう仕事をしてください、というようなマネジメントのスタイルになってしまうのではと思うのですが。そういったメンバーの意識をどうやったら変えることができるかについて、何かアドバイスはありますか？

牛尾：日本もアメリカも新卒は新卒です。アメリカの場合、コンピューターサイエンスの学位あるいは同等のものを取得している、というのが前提になっています。しかし日本の企業はそれを求めていません。もし自分だったら、コンピューターサイエンスの学位を求めていない企業は、つまらないのではないかと思ってしまいます。だから日本企業も堂々と、それを求めることが必要だと思います。アメリカでは新人もすぐに設計もコーディングもみんな任せられます。わからないことがあると、周りの人たちの頭を借ります。新人が会議を収集して、このアーキテクチャーを考えているのだがどうか、ということをベテランの人たちに聞くわけです。ベテランはこういう風に実装したほうがいいよ、とかアドバイスしてくれます。ここで指摘したいのは、その新人は主体性を持っている、ということです。やればできるのです。新人だから無理、と言っていると、いつまでもできません。だから、できないことは周りに聞く、ということを教えてあげるのが重要だと思います。私は2002年くらいにアジャイル開発をやっていたのですが、オブジェクト指向のカプセル化を使ってものづくりをしていました。その時に入ってきた新人は、ちゃんとユニットテストを自分で書いて、最初は時間がかかりましたが、最後には彼がいろいろ説明する立場にまでなっていました。日本人は年齢を気にし過ぎます。若いからできないとか、歳だからできないとかは無いと思います。

ロッシェル：日本人はよく、もう歳だから新しいことを覚えるのは無理、とか言いますよね。

牛尾：私もいい歳になってから英語を勉強しました。新人と同じように、50歳の人でも何かできないことがあれば、周りに聞けばよいのです。制限があるとすれば、それは本人が自分に課している制限だけです。

参加者B：私は将来サーバントリーダーになりたいと思っているのですが、今いるところは完全にコマンドアンドコントロールの会社です。現在の上司にどうやってサーバントリーダーシップを実行してもらえるか、どういう働きかけができるかを知りたいと思います。

牛尾：上司に対してサーバントリーダーシップのプレゼンを誰かにやってもらうのがよいのでは？できれば経営層に対するプレゼンがいいと思います。経営層だとサーバントリーダーシップの方が儲かると思えばその方向に進むでしょう。彼らは結構新しいことをしたいと思っています。それで上手くいかない場合は、サーバントリーダーシップを既に行なっている会社に転職する。

ロッシェル：自分の部署でサーバントリーダーシップを実行して、成功事例を作ることもお勧めしたいと思います。

オンライン参加者C：コマンドも締切も無い、失敗してもプラスに転換するという風土では、危機感も飢餓感もない文化になってしまわないか心配です。そんな中で社員が成長できる背景にはどんなものがあるのでしょうか？

牛尾：それは評価制度にあると思います。アメリカのエンジニアの場合、競争は他人相手ではありません。誰かを追い越すとか、誰かが出世しないので自分も出世できない、というのではなく自分自身との競争です。自分が出世したかったり、レイオフの対象になりたくなかったら、自分をアピールしなければなりません。

オンライン参加者C：どういう人がレイオフの対象になるのでしょうか？

牛尾：レイオフの対象は個人というより組織の場合が多いです。ですので、儲からない事業が組織ごとレイオフされてしまったりします。時には各部から何名ずつレイオフという場合もあります。そういう時はマネジャーが部下のパフォーマンスを判断して切るのだと思います。

ロッシェル：マイクロソフトは15年くらい前までそのようなレイオフをしていましたが、やる気に悪影響を与えるということでもうやめたようですね。それでは、最後にカニさんから何かご質問やご感想があればお聞かせください。

カニ：今日は本当に貴重なお話をありがとうございます。牛尾さんは日本とアメリカを行き来していらっしゃいますが、日本の企業は変わってきていると感じますか？また、その変わり方のスピードは速くなっていると感じますか？

牛尾：スピードはどうでもいいと思います。みんなスピードを気にし過ぎていると思います。遅くても少しずつでも、変えていくこと自体が重要だと思います。少しずつの変化でも1年経ったら大きな変化になると思います。アメリカは日本よりも新しいことに飛びつくのが遅い感じがします。でも違うことは、アメリカでは何かを始めると確実にやり遂げる。着実にやっていくことの積み重ねで大きな変化が生まれています。自分のペースで着実に変わることが大切だと思います。

カニ：ありがとうございました。では、みなさん交流会でまたお話ししましょう。

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

以上、対談イベント「日本のITに物申す：ソフトウェア・エンジニアの上司はどうあるべきか？」のレポートでした。ソフトウェアエンジニアを部下に持ち、良い上司になりたいと考える方にとって、非常に示唆に富む対話であったと思います。また将来マネージャーを目指している方や、自分の上司の行動について考えたいと思っている方にも、ご参考になれば幸いです。

コードクリサリス共同創立者でCEOのカニさん、また本イベントのライブストリームを担当し、更にYouTubeにアップロードしてくださったYesNoButの共同創立者でアギレルゴ・コンサルティングのシニアアジャイルコーチである川口恭伸さんに深く感謝いたします。