toBプロダクトのROIとソフトウェア・エンジニアとしての成長③

前回の記事では、なぜnice-to-haveなプロダクトにおける開発組織は社内受託状態になってしまうかを説明した。今回の記事では、社内受託の状態がなぜエンジニアの成長に適さないかについて触れる。

技術投資について思考する機会を失う

そもそも、バーニングニーズを捉え切れていない時点で本質的に事業が技術に投資をするフェーズではないことに起因している。それでいて営業によって利益がでているが故に、ソフトウェア・エンジニアの対する行動の評価軸は「いかに技術的な投資から未来の利益を生み出すか」ではなく「いかに低コストにプロダクト開発をするか」という視点に集約され、貴重な攻めの技術投資について考える機会を失うことになる。

ここで言うところの攻めの技術投資とは、新しい技術の導入を始めとして自動テストやリファクタリングなどの活動も含まれる。いずれにしても、その投資対効果に関する議論が不随することになるが、本質的にプロダクトに対する技術的な投資が利益と直結する状態になっていない時点で、基本的にはやらない方向に倒れる不毛な議論が多い。せいぜい「工数が少なければやってもOK」のような雑な結論にしかならない。ちょっとでもポジティブに言うとすれば、技術的なROIを説明する能力が身につくのかもしれないが、この状況で説明されるROIなど詭弁に過ぎないためやはり本質的には意味がない。

とはいえ、稀にこのような環境でも新規事業と称して流行りの技術を取り入れた新しいプロダクトが立ち上がり、少なからず技術的なチャレンジの機会が提供されることもある。しかし、それもまた組織がプロダクトドリブンでない時点で長期的には同じことの繰り返しになる。

形骸化した開発組織のロードマップ

プロダクトが事業の中心でないが故に、プロダクトとしての在り方よりも「いかに売りやすい機能を盛り込むか」が優先され、中長期的に開発サイドでロードマップを決めたとしても集中できない状態が生まれ、ロードマップは形骸化する。

具体的には、プロダクトがmust-haveでないことで競合との些細な機能比較で負けるケースが頻発する。これに対処するべく、競合比較で負けないための機能開発、本質的には不要だが営業するには必要という表面的な開発アイテムが横入りしてくる。残念ながら、営業で利益を積み上げている以上、競合プロダクトに営業で負けるのは死活問題であり、開発組織で既に立てていたロードマップの優先度を下げてでも開発アイテムとしての割り込みを許容せざるを得ない。

このような形でロードマップが形骸化することの問題点は、エンジニアに対する評価も形骸化することだ。長期の計画は立てても意味がないという学習が働くため、長くてもせいぜい1ヶ月程度の目標しか立てられない状態が生まれる。そしてそのほとんどが「機能Aを完成させる」のような雑なアウトプット目標ばかりになる。開発組織には質高くアウトカム評価をするだけの時間も権限もないのでどうしようもない。

もちろん単なる機能開発の要員という観点ではある程度のスキルは身に付く。しかし「能動的に課題を発見しそれを中長期のロードマップに落とし込んだ上で解決を図る」というような、ひとつレベルの高い一連のサイクルを回す経験を積むことができない。言われたものを納期通りに作っていることを評価するのが限界であり、それ以外は「チームの枠を超えて困っている人を助けなさい」「チーム間のこぼれ球を拾いなさい」くらいの社会人一般に通じる無難なフィードバックで終わる。

このレベルの評価で成長できるのはせいぜい新卒1-2年目くらいまでがいいところで、3年目以降のソフトウェア・エンジニアとしての成長は微妙なものになる。ここからさらに先へ行くには、会社での業務や評価に頼らず自主的に副業をしたり社外での勉強会で知識をつけるなどの取り組みをするしかない。

番外: エンジニアと事業貢献

社内受託の状態が発生している時点で、組織の中では営業組織が事業を牽引している状態にあり、組織の力学的に開発組織の業務は「ただコーディングをしているだけ」ということになる。逆に言えば、このような思想の営業組織もまた「ただ売っているだけ」であるとも言えるが、残念ながらプロダクトで事業をドライブしていない時点で、能動的な歩み寄るアクションをしなければいけないのは開発組織サイドになってしまう。これは相互理解やリスペクトの欠如から生まれる結果ではない。この歩み寄りの活動こそが事業貢献活動だ。具体的な内容は多岐に渡るためここでは触れないが、少なくともコードを書く以外の活動であることは間違いない。

ソフトウェア・エンジニアにとって事業貢献活動は技術的な成長に繋がらない業務であることが多く、良く言ってもせいぜい微妙なソフトスキルか悪く言えば根性論が身に付くと言ったところか。ただ、世の中の事業会社においてはこの事業貢献という単語を呼吸するかの如く口に出せるかどうかで大きく評価が動くこともあり、世渡り能力としての成長はあるのかもしれない。

この事業貢献という言葉、冷静に考えればエンジニアリングの業務とは別に存在していることから、定例業務としてのプロダクト開発は事業貢献に繋がっていないことを示す逆説的なメッセージである。事実、ソフトウェア・エンジニアという存在が非プロダクトドリブンな組織において余剰なリソースになりがちなのは間違いない。

補足: 事業貢献について

なんとなく誤解を招きそうなので補足しておくと、前提として「事業に貢献する」というマインドは必ず必要である。その上で、組織の中にマインドの有無／強弱があるかのように相対的に表現されることに問題がある。極端な言い方をすれば、事業貢献という概念がそこにある時点で相対的な差分を見出している主体が存在しているわけであり、真に全員が共有している概念ならば、わざわざそれを命名し認知させる必要性がない。これは組織の人間性やモラルに起因するものではなく、むしろプロダクトの抱える本質的な課題から生まれた結果であることのほうが多いと考えている。

また、主観的な体感ではあるが、名指しでこの事業貢献のマインドが相対的に少ないと捉えられがちなのは、多くの場合エンジニアリングに専門性を持つ開発組織であることが多い。エンジニアが事業貢献のマインドを持つことでプロダクトの課題が解決されるならば、これは正しい指摘だ。しかし、本質的なプロダクトの課題がそのような表面的な取り組みで改善されるとは到底思えない。