「テクノロジー」「ピープル」「プロジェクト」「プロダクト」　エンジニアリングマネージャーに必要な4つのマネジメント知識体系

エンジニアリングマネージャーに必要な4つのマネジメント知識体系

藤井創氏（以下、藤井）：今まではCTOについてうかがってきましたが、ここからは別のレイヤーで話をします。エンジニア組織のマネージャーについてです。まず根本に、エンジニアのマネージャーとはどのようなもので、どのような役割なのかについて、簡単に教えてください。

広木大地氏（以下、広木）：これは「Qiita」にもエンジニアリングマネージャーのための読書ガイドということで話をしています。エンジニアリングマネージャーには、4つのマネジメントの知識体系が必要だと思っています。

1つ目はテクノロジーマネジメント。その組織における技術の選定や、どのように意思決定してそのソフトウェアを育てていくかという部分です。2つ目はピープルマネジメント。1 on 1をしたり評価をしたり、成長キャリアを育成していくためにどのようにしたらいいかという観点です。3つ目はプロジェクトマネジメント。そのソフトウェアを使った何らかのプロジェクトを実現するためのマネジメントをしなければなりません。

4つ目はプロダクトマネジメント。それが事業として外に出していく時に、どのような機能をどのような順番で開発してリリースしていくことがプロダクトの価値向上につながるのかという観点です。この4つのマネジメントスキルがエンジニアリングマネージャーに課せられることが多いです。

そして、この4つのマネジメント機能の中には2つのタイプがあります。4つとも広く浅く求められている環境と、テクノロジーマネジメントとピープルマネジメントの2つを求められている環境です。

あるいは、プロダクトマネジメントだけを除いて、プロジェクトマネジメントの両方を追っているかたち。それぞれ弱い定義と強い定義、狭い定義と広い定義という言い方をしています。なので、実際に「エンジニアリングマネージャー」と言っている人にアンケートを取ると、少なくともピープルマネジメントはしていることになります。

テクノロジーマネジメントとピープルマネジメント

広木：テクノロジーマネジメントをしている割合はやはり高いです。プロジェクトマネジメントやプロダクトマネジメントをしている人もそこそこいる状況になっていると思います。場所や立場によって求められる部分が違うのです。例えば、狭いほうをやっている、つまりテクノロジーマネジメントとピープルマネジメントが主になっている環境は、そのエンジニアの職能がレアということになります。

例えば一時期、アプリ開発技術はそれぞれのアプリエンジニアだけになっていました。フロントエンドのSPAの難しい部分も、一部の人だけという組織の中で偏った職能でした。それはレアだからストリームライン、つまり機能を開発する横断のチームではなく、特殊機能を持った人たちのチームということになります。最近ではデータサイエンティストなどです。

データエンジニアなどのチームの長は、やはりテクノロジーマネジメントとピープルマネジメントを起点に見られます。それに対してストリームライン側、つまり機能と価値に近い側だと、プロジェクトマネジメントやプロダクトマネジメントの領域の両方を求められることになります。

それには両方の知識がないと難しいです。フロントエンドの技能を持った人とバックエンドの技能を持った人が集まって機能を開発していこうと思ったら、その両方に対してアドバイスしたりキャリアマネジメントしたりしなければなりません。そういったチームの場合は、プロジェクトマネジメントとプロダクトマネジメントの両方が求められます。

なので、実はけっこうまちまちなのです。いろいろな知識体系があって、その中から必要に応じて取捨選択する感じになっています。だからこそ、「これをやるんですよ」という教科書的なものがそれほど多くないのです。最近は、エンジニアリングマネジメントに関する本も比較的ピープルマネジメント寄りの内容が多いです。それは共通項としてあると思います。だけど、実際に求められているのは、先ほどの4つの部分です。

プロダクトマネジメントとプロジェクトマネジメント

藤井：テクノロジーマネジメント・ピープルマネジメント・・プロダクトマネジメント・プロジェクトマネジメントの話でした。その中で、プロダクトマネジメントとプロジェクトマネジメントが意外とごちゃごちゃになりやすいと思っています。広木さんの本の中にもありましたが、その違いを知りたいと思います。

広木：本の中では「プロジェクトマネジメントは終わらせることが仕事」「プロダクトマネジメントは終わらせずにサービスを継続させて発展させることが仕事」と端的に表現しました。つまり、ゴールに向かって走っていくのがプロジェクトマネージャーであるのに対して、プロダクトマネージャーは終わらせないために、グロースさせ続けるための仕組みなどを考えて提供する役割です。

この2つは本質的に違います。しかし、アジャイルは両方に対して「何かを実現するための部分の監督」と「何を実現させるのかという部分の監督」の両方を順番に仮説検証しながら進めていくプロセスです、という説明をしています。

藤井：ということは、1人の人がプロダクトマネージャーとプロジェクトマネージャーの両方をやることはあるのですか？　それとも、別々の人がやるほうがいいのですか？

広木：「プロダクトマネージャーをPMと呼びましょう」といいます。「プロジェクトマネージャーをPjMと呼ばないで」「プロダクトマネージャーをPdMと呼ばないで」といいます。アメリカではそのように呼んでいないからという話があると思います。

では、日本ではなぜ「PM」がプロジェクトマネージャーを指していることが多く、アメリカではプロダクトマネージャーを指していることが多いのでしょうか。それは、日本国内においてはまだまだ受託なり委任されて、業務委託としてソフトウェアを納品するまでを目的として商売している割合が多いからです。

藤井：なるほど。

広木：なので、そういった場合は終わらせるための人がプロジェクトマネージャーになります。納品するところまでを契約としてちゃんとやります。そのためのプロセスに関わっていた人が「PM」と呼ばれているため、PM＝プロジェクトマネージャーと思われています。

PjMとPdMという表現がなぜ生まれたか

広木：一方、アメリカの場合は日本とはSIerやインテグレーターの比率が逆転していて、ユーザー企業側に所属しているエンジニアが多いです。その自社企業側に所属している場合、プロジェクトや内製での開発は、組成して解散するものではなくてずっと育てていくものに変わります。そうなると、終わらせないためのマネジメントのほうに比重が置かれることになります。

終わらせないために、何を作るかをメンバーとともに練っていく。人を外から大量に連れてきて、完結したら解散するのではありません。そして、その中にいる人たちも急には増えません。ノウハウがたまっていく中で、次はこの機能を作ろう、とベルトコンベア式にモノを運ぶ考え方をしています。

なので、日本ではあらゆるコンテクストで「PMはプロジェクトマネージャーを指す」というのは、アメリカでも通じます。通じるのですが、ソフトウェアの分野において、内部のエンジニアがほとんど継続開発してベルトコンベア式にソフトウェアの機能を追加しているから、プロダクトマネージャーが主になるのです。

それに対して、日本国内ではトラックに積み込んで渡すように、全部できたら「完了しました」と納品するモデルで仕事をしています。ベルトコンベアを管理する人がいないのです。ですから、スクラムやアジャイルの方式は、実は「ベルトコンベアをケアしていきましょう」「ベルトコンベアのパイプを太くしていきましょう」「テンポ良くソフトウェアを提供できるようにしていきましょう」という、ストリームライン的な仕組みなのです。

あるいは工場的なメタファーを持っています。トヨタ生産方式などの日本の1980年代の製造業を模倣したような話をするのは、継続的に生産するテンポの良さやジャストインタイム制が問われているからです。1980年代の工場であれば、アメリカにおいてのソフトウェア事業はテンポ良くソフトウェアを出していく工場的な見られ方をしていました。工場生産能力は必要に応じて簡単に調達できるものではないと見られていたのです。

そういった違いから、日本ではプロジェクトマネージャーをPMと言うし、プロダクトマネージャーもPMと言います。このような区別の付きにくい状況が発生してしまった結果、PjMとPdMという表現が生まれました。僕も最初に見た時は「え!?」と思いましたが、わかりにくい表現・状況が生まれたのは、そのような背景があるからだと思います。

2000年以降のソフトウェアは頭の中にあるウェットウェアを固くしたもの

藤井：では、昔の日本は「作って終わり」「出したら終わり」のプロダクトが多かったのでしょうか？

広木：プロダクトという言い方をすると難しいですが、コストの効率化に代表されるようにソフトウェアは攻め側ではなく守り側のITで、一時的な費用だったのです。ですから、ITが盛んになってきた1990年代後半ぐらいから、「IT投資をしなきゃ」という風潮がありましたよね。でも、この時の日本企業は不景気だったじゃないですか。

いろいろなところでリストラクチャリングやコストカットなどと言っていました。そのタイミングで、「社内でエンジニアを採用しましょう」「IT投資をしましょう」とは言いません。どんどんコストカットし、外部化もしていく。派遣に切り替えたり、子会社に切り替えたりしたかもしれません。外部委託にどんどん任せていく試みもしていました。

実は、さらに昔の1970年代ぐらいの企業やメーカーは、意外と自分たちでやろうとしていました。やはり1980年から1990年代になって、「全部自分たちでやるのはおかしい」と、ベンダーに頼む文化が主流になっていきました。その結果、外に頼むものになりました。外に頼むのが当たり前になると、必要な100人分のリソースにずっとお金を払い続けることはしたくなくなります。

つまり、終わったら最低限の人数にしたいのです。ソフトウェアはハードウェアの上に乗っている、ハードウェアをちょっと柔らかくしたものではありません。それこそ組み込みを触っていた感覚からすると、ハードウェアの上にソフトウェアを乗せて付加価値にするから、ハードをちょっと柔らかく使いたい時のものだったのです。

2000年以降のITやWebの世界は、ハードを柔らかく使うためではなく頭の中にあるウェットウェアを固く使うためのものでした。なので、より柔らかいものを固める過程がソフトウェアだったのです。業務知識などをちゃんとヒアリングしてまとめて整理して、それをソフトウェアに落とす過程にこそ、本質的なソフトウェアへのナレッジの価値があったのです。しかし、その人たちは外注だったので、終わったらそこにはいられなくなってしまいます。

自社に合ったウェットウェアのさまざまなノウハウを、システム化・IT化して効率良くしようとします。効率良くする過程の知識こそが日本企業には必要なナレッジだったのに、これを持っていた人たちが「次、行くか！」と次の案件に行ってしまいます。ゆえに、日本企業のソフトウェアのナレッジがたまらず、「技術的負債になりました」となります。そして、いちいち5年ごとに償却期間が終わったら、ベンダーに新しい技術で作り直してもらうという、無限に続く工業事業のようなことが生まれてしまったのです。

メディアでどれだけ発信できるか

藤井：それが今、日本でも広く変わり始めているところだと思います。先ほど言ったプロダクトマネジメントの部分が、今後、企業によっては増えていくと思うのですが、とは言っても海外と比べるとまだ少ない気がします。これをもう少し浸透させ、「あるべきだ」とするにはどのようにすればいいのでしょうか？

広木：どうすればいいんでしょうね。

（一同笑）

1つは新しい常識に変わってきていることをメディアも含めてどれだけ発信できるかだと思います。これから労働人口がどんどん減っていきますし、人口も減っていきます。コンピューターは安くなっていきます。今は半導体不足でちょっとブレーキがかかっていますが、長い目で見た時に半導体も安くなります。

なので、人が減る代わりに何かをやってもらおうと思ったら、コンピューターに指示することは必須のスキルとなります。読み・書き・そろばんと同じようになっていくと思います。今は文字を読み書きできたりPowerPointやExcelを使えたりすることは、最低限のスキルだという感覚があると思います。でも、昔はなかったわけです。もっと昔になると、文字を書けること自体がレアなスキルでした。

それと同じように、プログラムを書いてコンピューターに指示して何かをしてもらうことは、たぶん技術側の進歩も含めて普通の人が普通にやることになっていきます。コンピューターに指示する人を増やさないといけないし、コンピューターに指示する人たちを取りまとめて何か指示するというさらに上のスキルも必要になってきます。そういったものがないと、日本社会の生産性はそもそも上がりません。その危機感はすごくあります。

藤井：やはり、メディアとしてそこはちゃんと伝えないといけない……（笑）。確かに今は、大きく移り変わっている部分がなかなかうまく伝わっておらず、うまく届けられていない部分もあります。そこがうまく回っていけば、プロダクトマネジメントの重要性がわかるということが理解できました。

（4記事目につづく）