プログラミングとは経営そのもの?技術者が正しく評価されない理由

あまり知られてはいませんが、プログラミングという行為には組織経営のエッセンスすべてが詰まっています。

それは、コーディングやソースコードといったソフトウェアを記述する行為や対象についてのことではありません。

プログラミングとはすなわちソフトウェアを設計することに他ならず、その行為が組織経営と共通点が非常に多いということです。

しかしながら、多くの企業では経営者とエンジニアがわかり合えず不幸な結末を向かえることが少なくありません。

本記事では、組織経営とエンジニアリングの共通点を明らかにすると共に、現場で起きている「正しくエンジニアリング(技術者)が評価されない」という課題をどのように解決すべきかを解説します。

プログラミングと経営の共通点とは?

ソフトウェアの設計には、限られた人、金、時間の中で、どの部分を汎用的に作り、どの部分をあり合わせで作るかという判断が求められますし、時にはパフォーマンスを優先させ、時には全体への影響度を最小にしよう、というように柔軟な考え方が求められます。

モジュール(設計の単位)を後で取り替えられるようにしたり、人や時間が足りずに間に合わせの処理を作ったとしても何ヶ月間それで耐えるのか、などをじっくり考えてから実装する必要もあります。

このようにソフトウェアを設計するということは、非常に複雑な行為なのですが、実はこれ「会社が今後どのような組織として成長するかを考えてくこと」、すなわち組織経営と数多くの共通点があります。

いきなりでいったい何を言っているのか理解できないかもしれません。

例えば、エンジニアは絶え間なく成長を続けるソフトウェアに対し、今後どの部分の変化が大きいか、核になる部分はどこか、といったような設計判断を常に迫られています。

それと同じように、経営者は組織をどのように成長させるべきか、どのように維持すべきか、どのように動かしていくべきかという判断を常に迫られています。

しかも、組織というのはソフトウェア開発と同じようにリソース(人、金、時間)に限界があるため、何でもかんでもやれば良いというものではありません。

また、1つの人材(プログラミングでいうモジュールに相当)に対して、様々な役割や責務を与えすぎるとそれだけで全体の設計が壊れ組織自体が破綻しかねません。

こうした「組織経営」と「ソフトウェア開発」の共通点をもう少し詳しく見ていきましょう。

組織経営がソフトウェア設計と同等以上に難しい理由

あなたは組織経営の経験があるでしょうか?

おそらく多くの人が組織経営の経験をお持ちではないことでしょう。

私は幸運なことに、何度か経営層への参加をしており組織運営というものを間近で見てきました。

その中で気がついたことは、繰り返しになりますがエンジニアが普段から行っているソフトウェアの設計というものは、企業を成長させるための組織設計と非常に共通点が多いということです。

例えば、エンジニアはプログラミングをする際にすべてのモジュールを同じ粒度で組むことはありません。

のちのち資産になるようなモジュールは再利用可能なように設計しますし、変化が大きいところは後から要件が変更されても耐えられるような作りにします。

このようなエンジニアリングで資産となる部分というのは、会社においても経営的、財務的においても資産と見なされるものと共通項があります。

例えば、エンジニアが「このモジュールは、時間をかけてでもきちんと設計しなければならず、将来的にAという拡張が予測されるから、その口は用意しておこう」と設計するように、経営者もまた「人事制度は、時間をかけてでもきちんと設計しなければならず、今は中途採用のみだが、将来的に新卒採用ということが予測されるから、それに対応できるようにしておこう」などのように考えているわけです。

エンジニアがあるモジュールに対して拡張性を検討したとき、今後もそのモジュールが使われ続けると考えており、何かの核になるべきであるとイメージしています。

そのモジュールの設計とは、会社に例えるなら今後どのような人員を雇い、どのように組織化するべきか、どのような顧客がターゲットなのか、そのターゲットにどのようなサービス、もしくは商品を展開するのか、といったような判断を下しているのと等しいわけです。

しかし、最初からうまくいくエンジニアリングもないように、最初からうまくいく組織もありません。

企業は従業員が増えたりプロダクトが増えていけば、それにあわせた組織改編を余儀なくされます。

それと同じように、エンジニアリングによって開発されたシステムもアップデートだけではなく、作り直しが発生します。

データベースを利用したアプリであれば、顧客が増えていけばデータベースの構成を直さなければならないのと同じことです。

実際、多くの成功したIT企業では当初から最後まで耐えられる設計がなされていることはほぼなく、例外なく成功してから人月をかけて作り直されています。

Facebookも例に漏れず、最初は大学でのみ使われるシステムを想定していたので成功する過程の中でシステムとしては大幅な作り直しが発生しました。

このように最初にエンジニアが「これくらいでいいだろう」というように決めたモジュールについての意思決定が、会社の将来的なビジネス的意思決定を左右してしまうくらいに影響することがあるということです。

ですが、同じように最初に経営者が「これくらいでいいだろう」というように決めた組織についての意思決定が、エンジニアリングに対する意思決定を左右してしまうくらいの影響を与えることは当たり前にありえるわけです。

これだけ聞くと、お互い様のように感じるかもしれません。

エンジニアリングを外注することの意味

ここまでの話を見ると、そもそもソフトウェア開発を外注に出すという話が無謀であることがわかります。

ソフトウェア開発が経営判断や組織設計に寄り添うようにして発展するものであるとするならば、外部の会社に開発を委託(丸投げ)するということは、経営を外部の会社に丸投げしているのと変わらないということだからです。

外注を受けた会社は、自社の利益を最大化しようと考えますから、当たり前の話ですがそのソフトウェアが未来に実現するであろうことなど考えず、できるだけ利益を出せるよう最小のコストで開発しようとするでしょう。

そもそも、顧客のビジネスが成功しようと失敗しようとどうでも良いのが受託会社ですから、顧客がイメージするビジネス戦略とはかけ離れたような開発をすることが少なくありません。

にも関わらず外注を出している側は「お金を出しているのだから理想的なソフトウェアを作り込んでくれるはず」というような間違いだらけの淡い期待をし、期待通りのソフトウェアがでてくることはなく、無事に死亡します。

このようにビジネス的な視点だけでソフトウェア開発を何も考えずに外に出すということは無謀であることがほとんどです。

ソフトウェア開発には、高度な専門的知識が不可欠であること以上に「作って欲しいものを実現する」という力が求められます。

しかしながら、このようなことを経営者が理解しておらず開発は失敗に終わり、ビジネスも失敗に終わります。

ここでエンジニアが感じることとして「そうそう、経営者がエンジニアを理解してないからダメなんだよ」ということがあります。

では、逆に「エンジニアは経営者を理解しているのでしょうか?」

経営者がエンジニアを理解しないようにエンジニアもまた経営者を理解しない

「経営者がエンジニアを理解していないから会社がうまくいかない」といった愚痴は非常に多いです。

確かに、ソフトウェア開発というのは、非常に高度な頭脳労働であり、常に知的で論理的な判断が必要であるため、理解が難しいことがあります。

現実的に多くの経営層にはエンジニアリングは漠然としか理解できていないですし、エンジニアを甘く見ているのも確かです。

だから、エンジニアがビジネス的に大切な要件に対して「論理的にそれはできない」という判断を下すと、経営層は「エンジニアはすぐできないという。できるかできないかじゃない、やるんだよ」という言葉を発し、エンジニアと完全に意見が割れることになります。

エンジニアとしては「できないものはできないんだよ。できないのにできると言うなんてロジカルじゃない」と不満を抱きますし、経営層は「これがビジネス的にどれだけ重要な判断なのかエンジニアはわかっていない。やれないとなったらビジネスが立ちゆかないじゃないか。やれない理由じゃなくて、やれる方法を探してくれ」とすれ違うことになるわけです。

エンジニアの言っていることがいくらロジカルであっても、経営者には通用しないことがあるので「経営者はエンジニアを理解していない」という不満を抱くのでしょう。

では、立場を変えて考えてみましょう。

あなたの大切な人が末期ガンにかかり病院にかかっているとします。

あなたはその人をなんとしても助けて欲しい、そう願います。

そんなとき医者が「論理的に考えて末期ガンなので助かりません。諦めてください」と言い放ったら「いや、そうじゃなくて何とか助ける方法を考えてくれよ。医者なんだろ!?」と感じるのではないでしょうか。

そうです、経営者が求めていることはそういうことなのです。

ビジネスというものが生きるか死ぬかという瀬戸際であなたに求められていることはロジカルな答えではありません。

経営とエンジニアリングを両立できる人間はほぼ存在しない

このようにソフトウェア開発と経営には共通点が多いのにも関わらず、わかり合えないことが多発します。

ほぼすべてのソフトウェア開発において、エンジニアにはビジネス的な観点が、経営層にはエンジニアリングの観点が足りていないからです。

これだけソフトウェア開発が多様化してくると、本来であれば、ビジネス的に重要なソフトウェア開発の中で、どの部分がビジネス的、マーケティング的にクリティカルな影響があるのかを判断できるだけの経営センスがエンジニアにも求められてきます。

しかし、ビジネスの要件を設計と実装を担当しているエンジニアがビジネスの核を理解しておらず、エンジニアリング的な失敗がビジネスの成功や成長を阻害してしまうことがよく起こるわけです。

経営層の人間が、ソフトウェア開発について無理解であり、理不尽な無理難題を言ってくるのとまるで逆の現象がビジネスの現場では事実として起きているのです。

共通点を見てきたようにエンジニアがあまり理解していないことではありますが、経営も実はソフトウェア開発と同等、もしくはそれ以上に高度で専門的なスキルを要求されるものです。

しかしながら、経営が高度な頭脳労働であることを実感としても経験としても理解できているエンジニアはほとんどいません。

だから、多くのエンジニアは自分で経営のスキルを磨いたり理解することをまったくしていないのにも関わらず、どのような設計にするべきかを勝手に技術的な観点からのみ判断しており、結果としてビジネスが失敗することになるのです。

であれば、これほどの共通点を持つのであるからビジネス的な視点とエンジニアリング的な視点の両方を持ち合わせた人材を採用するなり育成するなりすれば良いのではと感じるかもしれませんが、残念ながらそれは無理というものです。

それは、プログラミングは高度な知的作業であり、常人の場合、トップクラスにたどり着くためには10年以上もの鍛錬を必要とします。

同様に、経営も同じように高度な知的作業であり、たった1度起業して何年か経営したくらいでは完璧とは言いがたいものだからです。

ということは、エンジニアリングと経営といった両方のスキルを一人の人間が1流と呼ばれるレベルで兼ね備えようとすれば、その人が何十年も学び続ける必要があり、それぞれのスキルを学んでいる最中にもそれぞれの要求レベルが上がっていくため習得が不可能なのです。

「正しく技術者が理解されない問題」を解決するためにはどうすれば良いか?

簡単に言うならば、1流の「経営」と「エンジニアリング」が両立するハイブリッド人材などいないのだからお互いが歩み寄るしかないということになります。

そして、エンジニアができることとして「経営層はエンジニアリングを理解していない」という愚痴を言う暇があれば、少しは経営について勉強をしてみることです。

今担当しているサービスの設計や実装をする際に「ビジネス的にどこがクリティカルだろう?」という考えを持つようにしてみましょう。

人間というのは相互理解の生き物です。

あなたが経営者を理解していなければ経営者もまたあなたを理解することはありません。

であれば、経営者に理解されるのを口を開けて待っているのではなく、あなたが経営者を理解する方が早いはずです。

実は経営層に近いエンジニアというのはこれができています。

現場のエンジニアに対して経営層の考えを通訳したり、その逆を行っています。

優れたCTOやVP of Engineeringというのは、エンジニアから見ればエンジニアに寄り添っているように見えますし、経営層から見れば経営層に寄り添っているように見えます。

しかし、そういった立ち位置こそがこれからのソフトウェア開発には不可欠ということなのです。