内製開発組織の注意点
プロダクトを作るためには「プロダクトを開発する組織」が必要になってくることが多い。
世の中に価値を提供したいから、プロダクトを作りたい。
プロダクトを作るために、開発組織が必要だ。
多くのプロダクト組織の中で「強い開発組織」を作り、プロダクトを成長させていきたいと思うプロダクトマネージャーはたくさんいると思います。
今回はそんな「強い開発組織」に関して、例としてよく挙げられる「内製開発組織」に焦点を当て、私が感じている注意点をお伝えしようと思います。
「内製開発」が理想だよね！という声は多い一方で、手放しで「内製開発」が良いと言えるかというと、そうとは言い切れない部分があると私は考えているため、現在内製開発組織と向き合っている方、今後内製開発組織を構築していこうと考えている方に少しでも参考にしていただければと思います。
そもそものメリット
「内製開発」のお話しをする前に、そもそも「強い開発組織」とはどういうものをイメージするでしょうか。
技術的に秀でた人を多く抱える組織
マネジメント/プレイヤーのバランスが良く、生産性が高い組織
大量の人数で馬力を出して戦う組織
色々な軸で評価することができます。
「内製開発」はこれらの軸に対して、外注開発よりも相対的にパフォーマンスを出しやすいという特徴は確かにあります。
また「内製開発」には
社員が稼動するが故の、業務体制の柔軟性
責任範囲の広さや責任感の高さ
技術方針の策定や技術課題への対応
など多くのメリットがあるのも確かです(細かくはまた別の機会に)
このように、メリットを上げ出すとキリがなく「内製開発」には多くの魅力があるため、私自身も、開発は内製が良い！という意見には賛成です。
一方、より良くするために気をつけなくてはいけない部分もあると思いますので、今回は３つの注意点を紹介します。
注意点１：「事業状況に合わせた開発体制の縮小が難しい」
まず一つ目として挙げられることは、「事業状況に合わせた開発体制の縮小が難しい」という点になります。
「内製開発組織」を持つということは、その分の社員人件費を抱えるということになります。
事業が順調で「内省開発部隊を作っていこう！」「プロダクトで開発したいことがたくさんある！」というときは、新しくエンジニアを採用するなどし、組織を強化していくことができるでしょう。
もっと人数を増やそう！もっと強化しよう！という流れになるのは自然なことです。
ただ、プロダクトライフサイクルにもあるように、常にプロダクトが上り調子でいられるとは限りません。
「市場が変化した」「競合が伸びてきている」「自社で課題が発生した」等、プロダクトを運営していれば、様々な要因で事業の調子が悪くなることはあります。
その際、打ち手として、「事業運営のコスト削減」という話が上がることがあります。
もちろん、開発部隊の人件費も事業のコストと捉えることができるわけですが、外部のパートナーに発注している場合であれば、発注を止めることで、その状況に対応することが割と容易にできます。
しかし、内製開発部隊で社員を雇用している場合は、簡単にその人件費を削減することはできません。
別の業務を担当をしてもらう。
技術研鑽に励んでもらう。
プロダクトの磨き込みをしてもらう。
リファクタリングをしてもらう。
何かしらの仕事を準備することはできるかも知れませんが、難易度が高い問題にぶつかることになります。
プロダクトマネージャーとしては、本来「プロダクトを磨き込むこと」にリソースを割きたいと思うものですが、事業がうまくいっておらず、内製エンジニアを持て余す場合は、「その方達に何の仕事をしてもらうか」といった、本質とは違う悩みにぶつかることがあるでしょう。
事業の成長に合わせて内製開発組織を構築していくことには、上記の様な注意点があると思います。
注意点２：「スペシャリストキャリアの構築」
次に考えられる注意点は、「スペシャリストキャリアの構築」です。
以前に比べ、世の中一般的に「スペシャリストキャリア」の認知が広がってきているとは思います。
しかし、感覚としては、まだ「特定のスペシャリスト」よりも「マネジメント層」の方が評価をされやすいという風潮がある様に感じます。
「エンジニア」という職種において、高いパフォーマンスを発揮し「優れている」と評価されるエンジニアは、他の職種よりも「スペシャリスト傾向」が高い様に感じます。
内製エンジニアの場合、社員として雇用することになるため、当然人事考課が必要になります。
良いパフォーマンスを発揮したメンバーは評価し、より次の成果を出してもらうように促すことになるでしょう。
しかし、優秀なエンジニアを評価し続けた結果、この後のキャリアはどうすれば良いのか？という悩みにぶつかることになることが多いと感じます。
優秀なエンジニアが必ずしも「マネジメント」に長けているとは限らない。
そのため、
「評価したいけど、自社の評価システムではこれ以上評価することができない」
という壁にぶつかることがあるのではないかと考えます。
内製開発部隊の評価制度をどう設定するべきかという点は、大きな注意点かと思います。
注意点３：「マネジメントコストの肥大化」
3点目は、「マネジメントコストの肥大化」に焦点を当てます。
内製開発組織を作るということは、内製エンジニアに積極的に意見を言ってもらい、皆で同じ方向を向いてプロダクトをよくしていこう！という意図があると思います。
企画側の人間だけではなく、エンジニアからも自由な改善提案が行われ、実際に形になっていくことは、組織として物凄い良い状態だと感じます。
ただ、必ずしも全ての意見が同じ方向に向かっているとは限りません。
事業としては、緊急度高く推進してほしい案件があるが、エンジニア組織としては、技術的負債を抱えたくない等の理由で、他に優先したいことがある。
要件の内容や構造/設計において、意見が食い違うことは多々あります。
もちろん、優先順位を決めるのはプロダクトマネージャーであり、そこがしっかりと手綱を握るべき。
外注のエンジニア組織としても、同様のことは発生し得るという意見は尤もです。
ただ、内製開発組織であれば、各所の意見のギャップがより大きくなり、一緒に前に進めていくためのマネジメントコストが大きくなることが考えられます。
エンジニアによっては「好き嫌い等の嗜好」や「勝手に要件を変えてしまう」と言ったことが発生する可能性もあります。
その部分のマネジメントを誰がどうやるかといった組織作りともしっかり連動して検討していくことが非常に大切だと思います。
終わりに
このように、ひとえに「内製開発」と言っても注意点は存在します。あくまで「内製開発」というのは手段の一つであるため、どういう目的で、何を目指して、どういう組織を作っていきたいのかを、しっかりと考えた上で、組織を構築していくことが大切かと思います。
また、今現在は発生していないとしても、将来発生しそうな課題を想定し、予め準備をしておくと、悩み事も小さく済む可能性もあります。
上記の注意点に対して、どうすれば良いのか？という話は、機会があればまた別途記載したいと思います。
プロダクトマネージャーの皆さんやプロダクトマネージャーと関わる皆さんに、少しでも参考になっていただければと思います。
皆さんの経験談やご意見もよければお聞かせください。
それでは、また！