企業は「Y理論」で人が動く仕組みづくりに注力せよ

及川　それを一言で言語化するのは非常に難しい（笑）。なので、僕が過去に勤めてきたDECやMicrosoft、Googleの事例を話しますね。

これらの会社には、「Individual Contributor（特定の専門性で業務を遂行する人）」とマネジメントそれぞれのキャリアパスがあって、それとは別に、職位としての階級も決められています。

例えばマネジャーAさんの職位が「5」で、Individual ContributorであるBさんの職位が「6」だとすると、Bさんの方が上下関係としては上ということになるんですね。

でも、AさんとBさんは職種としてのやるべき業務が違うだけので、職位が上であろうと、AさんがBさんをマネジメントすることになる。こういう仕組みの方が健全な評価を生みますし、職種のミスマッチも起きにくいはずです。

そして、こういう仕組みにすると何が起きるかと言うと、多くのプログラマーはマネジメントをやりたがらない（笑）。だから、田中さんがおっしゃっていた「日本企業は管理職が多過ぎる」という問題も起きません。

及川　いえ、そんな中でもマネジメントをやりたいというエンジニアは一定数いますから。プログラミングよりチームビルディングの方が向いているとか、ライフスタイルの変化でキャリアパスを変更したいという人が、プログラマーのやりたがらない仕事をやるんです。これは自らの意思ですから、機会が平等だという点では良い仕組みだと思います。

田中　マネジャーの評価はどうやっているんですか？

及川　日本のように「管理の仕事」では評価されませんね。チームメンバーへのアドバイスであったり、全体のディレクション、チーム全体のパフォーマンスを高めるための環境づくりなどが、職種として負うべきミッションになります。ミニマムな業務管理は悪なんですよ。

及川　そうです。

田中　その仕組みなら、肩書きだけの管理職に多くの給料を払う必要もなくなりますし、その分優秀なプログラマーに対する報酬を厚くすることができますね。

及川　僕は、そういう名ばかり管理職のことを「壊れたルータ」と呼んでいます（笑）。

田中　（笑）。日本企業だと、壊れていないルータの方が怖いかもしれません。たくさんの階層があって中間管理職が機能し過ぎると、現場は指示待ちになってしまいますから。コーダーばかりが増える悪循環に陥りかねない。

及川　マネジャーが少ないと、皆が自発的に動く組織になるものですよ。マネジャーが多い会社ほど、上意下達の組織になってしまうような気がします。

田中　D.マクレガーが提唱した「X理論とY理論」があるじゃないですか。X理論だと、人間は元来仕事が嫌いで、誰かに管理・強制されないと動かず、嫌なことをやる対価として報酬が与えられることになるけれど、Y理論だと人間は条件次第で喜んで自ら目標を設定して働くようになる。

私が思うに、人月や工数が重視される環境ほど、X理論が重視されている気がします。かつてのSI産業がそうだったように。今のIT・Web業界は、全体的にまだこの文化を引きずっていて、人事・評価制度もその名残りが色濃く残っているのでしょう。

当社でも、創業時はY理論寄りのマネジメントでやっていたのに、上場する前後で社員数が増えてきたらX理論寄りのマネジメントが横行するようになった時期がありました。で、僕がそれに反発して、一度社長を辞めちゃったんですよ。

及川　（笑）。

田中　2007年に社長業に戻ってからは、改めて皆がY理論で動く組織づくりを目指してやってきました。組織構成も、これまではピラミッド型でエンジニアの上にマネジャーがいる形だったのを、マネジャーもシニアエンジニアやチーフアーキテクトといった技術専門職と横一線の立場にしていきたいと考えています。

及川　いいですね。

田中　ただ、社内でこの組織構成にしていく話をしたら、モチベーションの上がるエンジニアだけでなく、下がるエンジニアも出てきたんです。

田中　「頑張れば出世できて、マネジャーになると給料も上がる」という古い価値観で働いてきた人もいますからね。そういう人は、「エンジニアはシンプルに技術力で評価されるんだよ」という仕組みになると、生きづらくなる。

コーダーとプログラマーの違いで言うならば、コーダーは俗に言う35歳限界説くらいでキャリアの岐路を迎えることになり、プログラマーだけが評価され続ける仕組みなんです。

及川　でも、それはとても正しい取り組みだと思いますよ。エンジニアも自己成長に対する危機意識を持つようになりますし。

日本のIT・Web企業は、もっとさくらさんのような制度を導入して、エンジニアにきちんと説明しなければならないんですよ。「あなた方が目指すべきはプログラマーで、コーダーではありませんよ」と。

それと同時に、マネジャーになる人にも、ほんの少しでいいから技術的なアドバイスをできるようにしておくのが大切だと伝えなければならないと思います。日本だと、プログラマーとして食っていくのが難しいからマネジャーになろうとする人もいるかもしれないので。

及川　それだと、プログラマーが「この人にはマネジメントされたくない」と思ってしまいます。

田中　尊敬がない中では信頼関係を築けませんよね。

及川　だから最初に話したように、開発業務とマネジメント業務が二律背反になってはダメなんです。実際に、Googleではコードの読めないマネジャーは1人もいませんでした。

今の業務でコードを書いていなくても、過去のプログラミング経験やコンピュータサイエンスへの理解から、必ず技術的なアドバイスもできる人たちがマネジメントをしています。

田中　実はちょうど先日、当社でもマネジャーを含めた全社員に向けて「もっとコンピュータとソフトウエアトレンドへの感度を高めてほしい」というメッセージを伝えたばかりなんです。クラウドやソフトウエアの最新動向に疎くなってしまっている人が増えてきたと感じることが多々あったもので。

仕事の定義を「プログラミング」から「開発」に広げよう

及川　今回の対談を仰せつかってからずっと考えていたのですが、田中さんのお話を聞いても、やはり労働集約的なコーディングだけでキャリアを築いていくのは難しいんだと感じました。

でも、「開発職」という括りの中でなら、いくらでもやりようがあると思うんですね。技術が好き、コンピュータが好きという前提条件さえあれば、開発に携わりながらキャリアを作り続けるのは可能なはずです。

田中　エンジニアとしてやる仕事の定義は、「プログラミング」ではなく「開発」なんだと。そう考えれば、及川さんの言うようにキャリアパスは広がっていくでしょうね。

及川　会社側も、開発に関わり続けることのできる選択肢をたくさん用意してあげる必要があります。それがないと、エンジニアとして生きていくのがとても難しくなりますから。

実装能力では優れたプログラマーに勝てないという人もいるでしょうし、年齢を重ねるとスキルレベルの上昇カーブはなだらかになり、どこかで頭打ちになってしまうものです。こういった壁に突き当たり、ドロップアウトしてしまう人を救えるような他の専門職を、業界や会社が用意してあげなければならないと思います。

実は僕自身がプロダクトマネジャーをやるようになったきっかけも、ある時期にこの壁を感じたからなんですよ。

及川　ええ。Microsoftに転職する時、自分がプログラミングだけではトップになれないと感じまして。でもこの時、コーディング以外の技術的な貢献で高いパフォーマンスを発揮できそうだと感じました。

例えば他のプログラマーがドキュメント化するのを嫌がる中で、きっちりドキュメントを残したり、お客さまにヒアリングしてきたことを技術の言葉に変換して伝えたり、技術の方向性を見極めて製品の方針を決め、分かりやすい言葉でさまざまな人たちに必要なことを伝えたり。

「これなら自分の得意なことを活かしながら開発に貢献できる」と考え、徐々にプログラミング業務から軸足を移していったんです。

そういった仕事を高いレベルでこなす人のことを、Microsoftでは「プログラムマネジャー」と呼び、Googleでは「プロダクトマネジャー」と呼んでいました。一つのIndividual Contributorとして、キャリアパスが用意されていたんです。

こういう職種は、他にもたくさんあっていい。近年脚光を浴びているデータサイエンティストだって、プロダクションコード（本番稼働中のプログラム）を書くことはないけれど、ログを解析して見つけた発見を、製品・サービスづくりのプログラマーに提言するじゃないですか。そういう意味では「開発」をやっていることになります。

次のページ：なぜ、エンジニアは「経験」に頼ってはいけないのか？

1. 1
2. 2
3. 3