Meety
Special Contents

モチベーションクラウド偏差値83.8を生むマネジメント手法。エンジニアの組織づくりをCADDi CTOに学ぶ

CADDi

Interviewee

小橋 昭文

1992年生まれ。スタンフォード大学・大学院で電子工学を専攻。在学中から航空機や軍事機器の開発製造会社ロッキード・マーティン・米国本社で勤務。ソフトウェアエンジニアとして大量の衛星データの解析に従事。米クアルコムにて半導体セキュリティ強化に従事した後、Apple米国本社で電池の持続性改善や、『AirPods』のセンサー部分の開発をリード。2017年11月にキャディの創業に参画し、現職に至る

「モチベーションの高いエンジニア組織をどうつくり上げるか?」は、テック企業において多くのマネージャーが抱える課題だ。良いチームは一朝一夕には生まれない。各メンバーのマインドを理解し、日々の改善を積み重ねることで、ようやく組織は一丸となって前へ進んでいく。 製造業の受発注プラットフォーム「CADDi」を提供するキャディ株式会社は、エンジニアの組織づくりを成功させている企業である。組織の状態を定量化・可視化するモチベーションクラウドの結果によれば、同社のエンジニア組織の偏差値は83.8に達している。偏差値が70を超えれば優秀な企業といわれるなか、この数字は圧倒的である。 キャディのCTOを担うのが、ロッキード・マーティンやクアルコム、Appleなど名だたる企業を渡り歩いてきた小橋昭文氏だ。組織づくりにおいて、小橋氏は何を大切にしているのだろうか?

高いモチベーションが、エンジニアの良質なアウトプットを支える

今回は、エンジニアの組織づくりについての施策を伺わせてください。前提として、なぜエンジニアに高いモチベーションを持って働いてもらうことが重要なのでしょうか?

エンジニアは頭脳の仕事であり、本人のモチベーションが開発の生産性やプロダクトの品質に直結します。モチベーションが低い状態で働くと、アウトプットの量や質が100分の1とか1,000分の1になってしまうことさえあります。 かつ、私たちがいるテクノロジーの世界は、アップデートの激しい領域です。「スキルアップしたい」「新しい技術について知りたい」という気持ちで日々の仕事に取り組まなければ、働くのはどんどん辛くなっていきます。健全に働き続けるうえでも、エンジニアが高いモチベーションを持つことは重要です。 また、モチベーションの種類を大きく2つに分けると「社会的に認められるから行動する」という外発的な動機と「自分がやりたいから行動する」という内発的な動機がありますが、キャディのエンジニア組織においては後者を重視しています。

それは、なぜですか?

エンジニアは「どうして自分はこの仕事をすべきなのか」について深く考える人が多く、内発的な動機が伴わなければ、なかなかモチベーションが上がらないからです。 例えば、「○○の数値目標を達成しよう」という外発的な目標を掲げられても、エンジニアはあまり興味を持てないケースが多い。むしろ、「その数字は何の根拠に基づいているんですか?」と反発する人すら出てくるかもしれません。 だからこそ、「いかにして内発的な動機を持って仕事に取り組んでもらうか」は、エンジニアをマネジメントするうえでとても重要になります。

1on1ミーティングで、メンバーの本音を引き出すために

内発的な動機の源泉がどこにあるかは、メンバーによっても異なります。小橋さんはどのようにして、メンバーの特性を捉えていますか?

自分が実践していることとして、2つの方法があります。1つは普段の業務において「この人は何をしているときに楽しそうか」「どんな仕事を任せるとうまくワークするか」などをよく見て、できる限り各メンバーの特性を把握するように努めています。 もう1つは、1on1ミーティングなどの場で「今後、どんな技術領域に挑戦したいか」「どのようなキャリアを歩みたいか」などを確認しています。それ以外にも、採用面接のときに社員から話してもらった内容も、私はほとんど覚えていますね。「各メンバーが何を目指しているのか」を意識して、業務をアサインしています。 もちろん、全員の意向を100%反映できるケースばかりではないですが、「社員のキャリアについてマネージャーが真剣に考えている」ということが伝わるだけでも、メンバーの仕事への向き合い方は変わってくるはずです。

1on1ミーティングの際に、どうすればメンバーの本音を引き出しやすくなるでしょうか?

話し合いの場において「メンバーの心理的安全性をどう保つか?」が非常に大切です。安全性がない状態では、どれだけヒアリングしてもメンバーから本音は出てこなくなってしまいます。 例えば、チーム内でパフォーマンスが下がっているメンバーがいると仮定します。一番良くないのは、1on1ミーティングでそのメンバーに「どうして最近、パフォーマンスが出ないんだろう?」といった質問から切り出してしまうことです。メンバーは自分が責められているような印象を受けてしまいます。

確かにプレッシャーがかかりますね。では、どのようにヒアリングすべきでしょうか?

メンバーの様子が以前と比較しておかしいのなら、生活のなかで何か変化を引き起こすようなことが起きているのかもしれません。 あくまで一例ですが「最近、帰りが夜遅くなっていますよね。お体は大丈夫ですか?」とか「ご家庭では最近どんなことがありますか?」といった質問からスタートして、そこを基点に、変化の要因を可視化していく方がいいです。そのうえで、「起きている課題を解決するために、マネージャーには何ができるか」を一緒に考えていくと良いと思います。 もしかしたら、お子さんの夜泣きがすごくて仕事に支障が出ているのかもしれません。根本原因がわかれば、勤務形態を見直すなど、何らかの解決策を打ち出せる可能性が出てきます。メンバーが心理的安全性を持てない状態ですと、こういった情報をなかなか話していただけないケースが多いです。

「アイデアへの評価と人への評価は別もの」だと理解してもらう

そういったコミュニケーションのとり方を、小橋さんはどのように身につけてこられましたか?

私は学生時代からカウンセリングに興味があり、体系立てて学んできました。その知識や経験から「安心して話せる空気をつくること」「こちらから一方的にアドバイスするのではなく、本人に自分の抱えている課題と向き合ってもらうこと」の重要性を学んできました。 それに、私はアメリカで過ごしていた期間が長くて、日本の文化や価値観についてそれほど詳しくなく、日本的な考え方を学ぼうと心理学などの本をたくさん読んできました。完全には理解できないかもしれませんが、せめて歩み寄る努力をしたい。日本に住む人や日本の組織がどのような特徴を持っているのかを、可能な限り理解したいです。

日本で育った人が持つ固有の価値観として、どのような特徴が挙げられますか?

多くの日本の方は、周りの人の目を気にする傾向、あるいは気にしなければいけないと考える傾向があると感じます。それが働き方にも影響していて、社内からの目を非常に気にする傾向があります。マネージャーは、その特徴をふまえたフィードバックを行うことが重要です。 人からの評価がストレスになっているならば「他の人の目を気にしなくてもいいよ」という発信をした方がいいかもしれない。逆に「周りからすごくよく思われているから、今のままでいいよ」という発信をすると効果的なケースもあるかもしれません。

納得です。他に、心理的安全性をつくり出すために有効なコミュニケーション手段はありますか?

「アイデアへの評価と人への評価は別もの」だと、メンバーに理解してもらうことも重要です。例えば、会議などで自分のアイデアに対してネガティブなフィードバックを受けたとき、「私は仕事ができないから、ダメなアイデアを出してしまった」と、自分が非難されたように思いこんでしまう方もいます。 心理的安全性を高めるには、そうではないのだと認識してもらう必要があって。「アイデアが否定されても、あなたが人間的に否定されたわけではないよ」という声かけを、メンバーには日常的に行っています。

「メンバーが進みたいキャリア」をふまえて、評価やフィードバックを行う

メンバーの評価において、工夫していることはありますか?

エンジニアの評価において難しい点の1つとして「自分よりも技術スキルの高い社員を、どうやって評価するか」が挙げられると思います。 例えば、キャディの社内には日本トップレベルのC++のスキルを持ったエンジニアがいて、C++という領域において彼は圧倒的に私のレベルを越えています。その方に対して「では、具体的にどれくらいすごいスキルなのか」を正確に把握するのは難しいですよね。 詳しくはEMの村上とのカジュアル面談でも具体的にお話しできると思いますのでぜひご参加ください。

自分よりすごいスキルを持つ人を評価するのは、難易度の高い作業ですからね。

その場合には、1on1ミーティングで「チーム内で、どんな人に助けられましたか?」などの質問をすると、かなり見えてきます。「○○さんはチーム内で相当に尊敬されているな」とか「○○さんはチーム内で一番○○の領域が強いらしい」とか。日常的に一緒に働いているメンバーだからこそ、わかることがあるはずですから。

「どんな人に助けられましたか?」は、チーム内での関係性がわかる良い質問ですね。キャディでは、どのような評価基準を設けていますか?

キャディではエンジニアの評価において、表面的な技術スキルをそれほど強く重視していません。例えば、「Vue.jsはできるけれど、業務で使っているReactは少し弱いから、評価を下げる」ということは全くないです。 それよりも、技術の裏側にある理論や思想、技術の存在意義について、なるべく理解してもらうように努めています。Vue.jsとReactの例に沿って考えるなら「なぜ仮想DOMが必要なのか」「どのような設計で仮想DOMを扱うべきか」などを理解していることの方が重要、というイメージです。 そして、面談においてメンバーの技術的な理解度をヒアリングしたうえで「こういう領域について学ぶと、よりエンジニアとして成長できそうだね」というフィードバックを必ず返しています。 成長の指針としては、自分が得意なところだけをどんどん掘っていくというより、なるべく幅広い技術を身につけてもらうのがキャディの特徴です。そうすることで、他領域のメンバーたちとも連携しやすい状態をつくりあげています。

評価の結果、メンバーに習得してほしい技術が何種類も出てくるケースもあると思います。その場合、どのようにして優先順位をつけますか?

もしも、「習得してほしい技術=現在の業務で使う技術」ならば、迷わずその技術を習得してもらえばいいです。ですがキャリアチェンジを考えている人に対しては、もっと別のアプローチをとった方がいいだろうと思います。 極端な例として、これまでずっとインフラを担当していた人が「フロントエンドエンジニアに転向したい」というモチベーションを持っている場合、「まずはバックエンドを学んで、慣れてきたら徐々にフロントエンドを……」という順に学習したら、時間がかかりすぎてしまいますよね。本人のモチベーションも徐々に下がってしまうかもしれません。 その場合は、「まずは趣味でReactに触れてもらって、慣れてきたらプロジェクトにアサインする」とか「まずはキャディ公式サイトのフロンドエンドを修正するなど、業務にクリティカルな影響が出ない部分を担当してもらう」といった方針を考えます。本人の目指すキャリアをなるべく早めに達成できるプランを、マネージャーが一緒に考えていけばいいと思います。

人の成長と事業の成長を両立できるような組織に

最後に伺いたいのですが、今後どのようなエンジニアチームをつくり上げていきたいですか?

チームにいる全員が、技術のことを好きで、「キャディがどんな社会課題を解決しようとしているのか」を考えつつ行動できる。そして人がどんどん育っていくチームにしていきたいと思っています。事業の成長と人の成長を両立させられるような組織を目指したいです。 それから、エンジニア全員にバランス良くスキルを身につけてもらえたら嬉しいです。もちろん各エンジニアは、フロントエンドやバックエンド、要件定義や実装など、普段の業務でフォーカスしている領域の違いはありますが、なるべく全員が全ての領域を担当できるような組織でありたいですね。

その目標を達成するうえでも、成長の道筋をつくっていくことは重要です。例えば技術に特化したエンジニアには、より事業観点を強くできるようなロードマップを引くとか。事業観点が強いエンジニアには、技術を伸ばせるようなサポートをするとか。そういった道を整備していけば、組織としての成熟度も増していくはずです。 日本国内でも有数の、理想的なエンジニア組織をつくっていきたい。責任感を持って仕事に取り組みながらも、事業や技術と楽しく向き合えるようなチームを目指したいです。 このあたりはカジュアル面談でも詳しくお話しできると思いますので、ご興味ある方はぜひお気軽に"気になる"を押してみてください。

カジュアル面談はこちら

Meety

キャディで働くソフトウェアエンジニアって?

Takuya Murakami

エンジニアマネージャー