企業特殊投資に向きあうエンジニアリング

「この会社で学べることは無くなった」？

採用面談を受けもつなかで求職者に転職理由を伺うと、よく聞く回答がある。それは「現職の企業で学べることがもう無くなってしまったから、新しい職場で新しい学びを得たい」というものだ。このような気持ちは理解できるし、その向上心は尊いと思う。筆者自身、自分のおかれた環境を大きく変えることで、なにか新しい「学び」を得たいと思う日が無くもない。とはいえ、開発組織を育てようという立場になってみると、いくつかの疑問が出てくる。ふつうソフトウェアエンジニアであれば、どのような会社であっても学べることは無数にある。新しい技術は次々と出てくるし、事業ごとにもドメイン知識が必要だろう。実際、職業人生のすべてを使い果たしても学び尽くせないくらいなのだ。では、なぜひとつの会社にいると「学び」が無くなってしまうのか？また、人はどのような「学び」を求めているのか？そして、「学び」が多い会社と少ない会社の違いは何なのか？

ここで論点のひとつとして提示したいのが、「企業特殊投資」である。企業特殊投資ないし企業特殊的人的資本投資とは、簡単にいうと「その会社のなかでしか通用しない能力の獲得に対する従業員の時間ないし労力の投資」を表す経営学用語だ。これはソフトウェアエンジニアにとっても馴染み深いものだろう。たとえば自社プロダクトの機能や設計、発生しやすい障害とその対処方法、同僚の誰がどの機能に詳しいのか、社内フレームワークの知識といったものは、基本的には自社内でしか通用しない企業特殊投資と考えてよい。そして、このような一社でしか通用しない能力の獲得に自分の限られた時間を費やすことを、ソフトウェアエンジニアはたいてい嫌っている。新しい学びを得たいと考えても、企業特殊な技能を学びたくはないのだ。だからこそ、企業特殊投資が大きい会社に身を置くと、「この会社で学べることは無くなった」とすぐに考えるようになってしまう。

このような企業特殊な知識を持った従業員は、企業が価値ある戦略を策定し実行するうえで必要な経営資源である。しかし、従業員が特定の企業で行う企業特殊投資は、他の企業ではほとんど何の価値も持たない。もしもその企業が倒産して事業をたたんでしまったら、その従業員は自分がその企業で綿々と行なってきた企業特殊投資の価値のほとんどを一瞬にして失う。^[1]

経営学において企業特殊投資は、職を転々とする従業員にとっては好ましくないものだが、企業活動に必要なだけでなく、企業の競争力を生み出す源泉のひとつだと考えられている。そしてそれは開発組織においても変わらない。それどころか筆者の考えでは、企業特殊投資は開発組織においてきわめて重要な指標なのである。

どういうことか。たとえばソフトウェアエンジニアリングには「技術的負債」という考え方がある。周知のように、これは卓越したプログラマーのウォード・カニンガムが提唱したもので、一般的には、スピード重視の開発により保守性を後回しにしていたり、経年によって使用している技術が古びてしまったり、事業の発展にともないプロダクトの機能が実情がそぐわなくなったりすることで生まれる、いつか返済しなくてはならない技術的な負債だと解釈されている。そして技術的負債は、プロダクトを開発し、運用していくうえで主要な課題でもある。実際、多くのソフトウェアエンジニアは日々の仕事のなかで技術的負債に悩まされ続けているのではないだろうか。そしてもうひとつ、「属人化」の問題がある。これはあらためて述べるまでもないことだが、多くの組織で属人化は必ず発生するし、プロダクトの開発や運用において大きな課題となっている。属人化が強くなるとボトルネックが増えるだけでなく、従業員の離職に伴うリスクが高まるのだ。しかしながら、これまで「技術的負債」や「属人化」は、チームや個々人が解決すべき問題であり、事業部全体や経営的観点からは軽んじられることが多かったのではないかと思う。しかしここで筆者が主張したいのは、技術的負債や属人化は、負の企業特殊投資を生み出す大きな要因であり、企業として対応すべき経営課題そのものであるということだ。

負の企業特殊投資を解体する

企業特殊投資は重要な経営資源であるが、これが膨らんでくると、入社後の受け入れに時間がかかったり、離職への誘引が大きくなったりして、組織を不安定にしてしまう。だからこそ、企業特殊投資は経営課題として向きあうべきなのだ。そして企業特殊投資のなかでも特に問題なのが、企業の競争力に結びつかないものだろう。ここではそれを便宜上「負の企業特殊投資」と呼ぶ。たとえば、プロダクトのどこにどんな技術的負債が残っているのかの理解や、それぞれの技術的負債について同僚の誰がくわしいのかといった知識のことである。このような負の企業特殊投資は、先に述べた企業特殊投資そのものの問題があるだけでなく、従業員の認知負荷を増大させ、日々の仕事をただただ煩雑で不愉快なものにしてしまう。先に述べたように、企業特殊投資は企業の競争力の源泉ともなる。しかし負の企業特殊投資ばかりが増え続けると、その競争力すらも奪ってしまうのだ。著名な技術コンサルタントのトム・デマルコとティモシー・リスターも次のように述べている。

退職率が高いと、学習は定着しないし、そもそも学習ということが起こり得ない。そんな組織では、技術力を向上させたり生産方式を再編成することは、実りのない試みだ。^[2]

そのようなことだから、開発組織において負の企業特殊投資を生み出す主要な原因である技術的負債は、なるべく速やかに返済しなくてはならない。だが大抵は、増え続けるビジネス上の機能要望に押し流され、一度できた技術的負債は返済することがたいへん難しいという現場がほとんどではないだろうか。そして、技術的負債が増え続けてどうにもならなくなってくると、それに蓋をして、コードベースやアーキテクチャをまとめて新しいシステムに「リプレイス」することで一挙に解決しようと考えがちである。しかし、これは大抵うまくいかない。

数ヵ月後あるいは数年後、第二のシステムが言われるほど優れたシステムではないことに気付き始める人々が出てくる。なにしろ、システムリソースを消費する割には、ゆっくりとしか動いてくれないのだ。^[3]

私見ではあるが、リプレイスが失敗しがちな原因の一つは、技術的負債の本来的な難しさが、現実のドメインと実装の乖離にあるからだろう。つまり、ドメインモデリングとデータ構造の問題なのである。これらはコードベースやアーキテクチャの劣化とは分けて捉える必要があるのだが、それら全てを一度に解決しようとすると、タスクは際限なく膨れ上がってしまう。慣れ親しんだ技術スタックで解決できないドメインやデータ構造の問題を、どうして慣れない技術で解決できるだろうか？

なんにせよ、技術的負債の返済は地道に行うほかないのだが、その具体的な方策については多くの先行する優れた書籍があるから、ここで深くは立ち入らない。本論において重要なのは、技術的負債が積み重なると、負の企業特殊投資を生み出し、プロダクトだけでなく組織そのものを蝕んでいくということだ。

一般性に従う

企業特殊投資はさまざまなかたちで現れる。たとえば企業特有の慣習はどの会社にでもあるものだが、それが一般的な慣習よりも優れたものであれば競争力を生み出すし、それがふつうよりも劣っていたり、良くも悪くもなければ組織を不安定にする要因となる。したがって、その慣習の良し悪しを慎重に見極めなければならない。

たとえば、開発組織ごとに異なる慣習の例としては「ユビキタス言語」が挙げられる。ユビキタス言語とは、高名なソフトウェアアーキテクトであるエリック・エヴァンスが提案した、ソフトウェア開発者とドメインエキスパートが用いる言葉の定義を統一しようという考え方だ。ふつう、開発者は開発者の言葉を、ドメインエキスパートはドメインエキスパートの言葉を使う。それを統一することで、両者の摩擦を軽減したり、よりドメインの実情にあった実装を行うことができるのだ。このような効果を期待して、ユビキタス言語は近年のソフトウェア開発業界では基本的な考え方のひとつとして普及してきた。しかしながら、ユビキタス言語を浸透させようとするなかで、用語集をつくって社内独自の定義を書き連ね、それを押し付けようとするのは考えものである。なぜなら、ユビキタス言語はあくまで現実のドメインから生まれるものだからだ。そして、現実のドメインは経年とともに変化していくのが普通である。エヴァンス自身も、ユビキタス言語は実運用のなかでしばしば変わりゆくものであることを強調している。

粘り強くユビキタス言語を使用すれば、モデルの弱点は明らかにならざるを得ない。（中略）言語に食い違いが見つかると、新しい単語が議論で使われるようになる。言語に対するこうした変更は、ドメインモデルに対する変更として認識され、用語の意味が変わった場合には、チームがクラス図を更新して、コード中のクラスやメソッドの名前を変えたり、ふるまいを変更したりすることにまでつながる。^[4]

そのようなことだから、「本物のユビキタス言語」と「社内用語」を峻別し、後者を抑制するのが肝要である。そうすることで、ドメインへの本当の理解が深まるだけでなく、負の企業特殊投資が縮まり、競争力につながるのだ。

以上のようなことは、開発組織のさまざまな事柄においても同様だ。プログラミング言語の選定やアーキテクチャ、開発プロセス、バージョン管理のフロー、ドキュメント管理方針といった諸々の事柄には、一般的に普及していたり推奨されているものがある。いたずらに社内独自のプロセスを発達させるのではなく、なるべく人気のある普通のプロセスに従おう。巨人の肩に乗れるだけでなく、新しい従業員の受け入れを容易にし、属人化を抑制できる。そのうえで独自のプロセスが発達し、成功しているのならば、それこそがあなたの組織の強みであり、競争力を生み出す企業特殊投資だと言えるだろう。

特殊を普遍にする

最後に取り上げたいのは、企業特殊な技能を公開し、それを普遍的な技能にしてしまう方法である。言うまでもなく、これは先行する多くの偉大なプログラマーや開発コミュニティが行ってきたことだ。当たり前のことだが、ソフトウェアエンジニアが日頃から用いるプログラミング言語やフレームワーク、アーキテクチャや開発プロセスなどは、いずれも誰かが発案し、公開し、普及していったものである。もちろん企業秘密を勝手に公開することは言語道断だが、一般的なソフトウェア開発の実態のなかでは、公開してはいけないことなどほとんどない。

広く知られるように、コンピュータ科学者のアラン・ケイは「未来を予測する最善の方法は、それを発明することだ」と述べたという。だからこそ、あなたの開発組織に他社にない強みがあると感じるなら、それを積極的にアピールしよう。そうすれば企業特殊な技能が、未来の普遍的な技能になりうるかもしれない。もちろんこれにより、競争力を生み出す企業特殊投資が失われるかもしれない。しかし、差別化による競争力は長続きしないのが経営学の常識である。たとえばジョナサン・ラスマセン著『ユニコーン企業のひみつ』(2021)で紹介された開発組織の運用モデルである「Spotifyモデル」は、一時期たいへんな反響を呼んだものの、現在のSpotify社ではSpotifyモデルは採用していないという。だからといって、Spotifyモデルの声望が失われたわけではないし、Spotify社は退行したのではなく先に進んでいったのだ。すべてのものは移り変わっていく。そのようなことだから、特殊を普遍にし、あらたな特殊投資を生み出しながら、開発組織は変わり続けていく必要があるだろう。

脚注

1. ジェイ B.バーニー, ウィリアム S.ヘスタリー 著, 岡田正大 訳『[新版]企業戦略論【下】全社戦略編 戦略経営と競争優位』2021, ダイヤモンド社, pp79

2. トム・デマルコ, ティモシー・リスター 著, 松原友夫, 山浦恒央 訳『ピープルウエア 第3版』2013, 日経BP, pp245-246

3. Mike Gancarz 著, 芳尾桂 訳『UNIXという考え方: その設計思想と哲学』2001, オーム社, pp40

4. エリック・エヴァンス 著, 和智右桂, 牧野祐子 訳『エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう』2011, 翔泳社