事業成長のために、ソフトウェアやテクノロジーがどう貢献できるのか。この問いは、現代のエンジニアにとって極めて重要なテーマです。一方で、事業成長に貢献するとはどういうことか、エンジニアの立場からは見えにくい部分もあるのかも知れません。
先日、私が取締役CTOを務める株式会社クラシコムでエンジニアの皆さんに向けて、「事業成長に寄与するソフトウェア」をテーマに話をする機会がありました。本稿では、その資料の一部と話した内容について残しておきます。
事業会社の経営者の立場から、エンジニアに対する期待を言語化してみました。「事業成長に貢献するソフトウェアを作りたい」と考えているエンジニアの方々にとって参考になれば幸いです。
事業成長に寄与するソフトウェア、その3つの貢献
ソフトウェアが事業の成長に貢献する方法は、突き詰めると大きく三つに整理できると考えています。これらは相互に関連し合いながら事業全体を押し上げていくものです。
1.顧客価値につながる機能をつくる＝売上の向上
最も直接的な貢献は、顧客が喜び、価値向上を実感できる機能を作り出すことです。それによって、より多くの顧客が商品やサービスを購入したり、ユーザ数を増やすことができれば、直接的な売上の向上となって事業成長に繋がります。
2.業務効率につながる機能をつくる＝コストの維持
事業の成長に伴い、様々な業務が増えていきます。業務の増加に伴って人も増えていけばコストもかかりますし、そう簡単に人は増やせません。そこでソフトウェアが果たす役割は、業務効率化です。
ソフトウェアによる自動化などを通じて業務効率を高めることで、一人当たりの生産性を高めることができれば、会社全体としてはコストを維持し、より利益を出すことができます。その利益を、顧客価値向上に向けることで事業成長に繋がっていきます。
3.事業拡大に対応する基盤をつくる＝成長速度を維持
もう一つは忘れられがちな点ですが、事業には成長速度があります。市場にマッチした機能ができて、うまく事業が軌道に乗ってきた時など、その成長速度を落とすことなく邁進できるように対応していかねばなりません。
かといって、最初から大袈裟なシステムを作ろうということではなく、その時点における最適な状態を維持し続けられるような体制や作り方を実現し続けていくことが、求められる貢献になります。
経営がエンジニアリングチームに求める「理想の状態」
では、これらの貢献を最大化するために、経営サイドはエンジニアリングチームにどのような状態でいることを期待しているのでしょうか。これも三つの理想の状態として整理できます。
1.経営の優先順位に従い、柔軟に変えていけること
経営者は常に市場の変化を捉え、事業の舵取りをしています。その結果、事業の優先順位は、驚くほど頻繁に、そして柔軟に変わります。「3年先まで計画して、その通りに実行する」という静的な経営は、もはや成り立ちません。
そこで経営が求めるのは、変化に迅速に対応できる柔軟さです。ちなみに、ここでいう柔軟に変化させたい対象は、ソフトウェアそのものではなく、先々に作ろうとしている機能の優先順位のことです。とある仕組みを導入しようとしていたが、AI関連の機能の方が今は重要なので、そちらを先に実装したい、という感じです。
2.価値検証の試行錯誤を、高速に回していけること
次は、現場寄りの視点です。ある機能を作ったとしても、それが本当に価値を生むかは、使ってもらわなければ分かりません。本当に使えるものになるまでチューニングが必要です。ここで重要になるのが、「価値検証の試行錯誤」をいかに高速に回せるかです。
「作って終わり」ではなく、「使ってみて改善する」というサイクルを、どれだけ速く、数多く回せるかが勝負になります。この高速なフィードバックループは、ソフトウェアの価値を高めるだけでなく、経営そのものの学習サイクルを加速させる貴重なインプットにもなります。
3.業務を妨げることなく、安定して動いていること
三つ目の理想は、逆説的ですが、ソフトウェアが空気や水のように当たり前に、その存在を意識すらしないほど、安定して動き続けている状態です。
経営者やユーザーが、本来の業務や活動に安心して集中できる。この「意識されない安定性」は、事業全体の生産性と顧客満足度を根底から支える大きな貢献です。そのためには、継続的なバージョンアップやセキュリティの対応など、目に見える機能ではない地道な活動が欠かせません。
従来型の開発スタイルでは理想の実現が難しい
こうした理想の状態は、「要件定義→開発→納品」の形で実現することは困難です。要件を固めた時点では経営の優先順位が変わらない保証はなく、納品が前提だと試行錯誤の余地も限られます。
また、大きく作ったものを数年おきにリプレースするような形でも、理想の状態は実現できません。必要なのは、事業と一体となって、継続的に保守を続けていく開発体制です。それも、経営や現場と密な連携をとりながら改修していけるような体制です。
継続的な開発を支えるのは「保守性」という核心
継続的な開発を効率的に行うためには、ソフトウェアの改修コストが低い状態を維持する必要があります。時間と共に改修コストが高まっていこうとするのに対して、一定に維持しようと取り組むのです。
つまり継続性には「保守性」が重要だと言うことです。保守性の高さは、主に二つの要素によって実現されます。
・内部品質（コードの質）を高めること
言わずもがなですが、保守性を維持し高めるためには、ソースコードが理解しやすく修正しやすい状態であることが重要です。
たとえ生成AIを活用したとしても、動いているコードが改修しやすいものでなければ、後々の技術的負債となってしまい、変更にかかるコストは高まってしまいます。
もちろん、どういったコードが「いいコード」なのかは、時代や技術によって変わってくるので、その品質基準そのものもアップデートし続ける必要があります。
・内部の連携コストを下げること
保守性を考える時、どうしても内部品質のことに目が向きますが、ソフトウェアを改修していく開発組織を健全に保つことも、改修コストに影響します。
チーム内の円滑なコミュニケーション、統一されたプロセスとツール、健全なレビュー文化など、組織やカルチャーも含めて考えなければ、真の「高い保守性」は実現できません。
「ネオ内製」という試み ー 内製化の幻想を超えて
事業に合わせて継続的にソフトウェアを改修していく、そのために重要な保守性を高めるためには、カルチャーが整った開発チームが必要で、その開発チームが、経営や現場と密に連携をとっていくこと。
こう考えると、自ずと答えは「内製化」が導かれます。確かに、私自身も事業会社のCTOとしては、社内に開発チームがいて内製だけでできることが一つの理想だと考えています。
しかし、そうした体制及び状況を作るのは容易なことではありません。コストだけならまだしも、相応の時間がかかるでしょう。経営者としては、その時間を圧縮する方法を考えたいのです。また、ただ社内にエンジニアを雇用しただけでは、前述のような理想の体制や保守性を実現することはできません。
そこで、クラシコムで取り組んでいるのが社内のエンジニアチームと外部のエンジニアチームが垣根を超えて取り組む新しい内製の形「ネオ内製」であり、それを実現しているのが、ソニックガーデンの「納品のない受託開発」です。
開発事例記事：株式会社クラシコム 育ててきた内製システムを「伴走型開発」で刷新。事業の本質にも切り込む対等な関係性で
「納品のない受託開発」は、お客様の社内エンジニアのように振る舞い、経営と直接対話し、現場と一体で価値検証を繰り返します。「納品」という区切りをなくし、継続的なパートナーとして伴走することが特徴です。
終わりなく続く開発支援を前提とするため、その長期の関係は、もはや内製と違いはないのです。本当に大事なことは、雇用かどうかではないということでしょう。
経営視点で見た「効果的なエンジニアリング投資」
最後に、経営者がエンジニアリングを「投資」として捉えた時、何を「効果的」と判断するのかを解説します。エンジニアの時間は、事業の未来を創る貴重な投資であり、その効果を最大化したいと考えるのは当然です。
経営者が最も望むのは、エンジニアという貴重なリソースが、今最も解決すべき重要度の高い課題に集中されることです。事業にとって一番インパクトの大きな課題から順番に取り組んでほしいと考えています。
その際、課題解決に最適化するためには、組織やチームの壁なんてものがなくて、重要な課題に全員全力でフォーカスできること。それも効果的な投資と言えます。
また、経営者が心から嬉しいと感じるのは、開発のサイクルが速いことです。個々のプロジェクトにかかる期間がなるべく短いことと、そのプロジェクトの優先順位をロードマップ上で柔軟に変更できること、それらによって経営は試行錯誤の回数を高めることができます。
あるプロジェクトに「1年かかる」と言われるより「1ヶ月で試せる」方が、経営者は遥かに挑戦しやすくなります。より多く試せるということは、経営側もより多くの「学び」を得られるということです。動くソフトウェアから得られる学びは、次のより良い意思決定に繋がり、事業全体の進化を加速させるのです。
経営にしてみると、何を作るのか？を決めるのは、不確実性を伴った取り組みです。投資という位なので、うまくいかずに返ってこないことを前提とするべきです。このことは経営側も開発側も理解しておく必要があります。
エンジニアが手を動かすこと全てが成果には繋がらないのです。当たるものもあれば、外れるものもあります。ならばこそ、小さく何度も試せることが大事なのです。
エンジニアが「事業成長を加速させるパートナー」になる
本稿で解説してきた視点を持つことで、エンジニアは単なる「ものを作る人」から、真に「事業成長を加速させるパートナー」へと進化することができます。
自分の書いたコードが、どのように顧客価値に繋がり、事業の未来を支えているのか。そして、経営が求めるスピードと柔軟性にどう応えていくのか。この問いを常に心に抱き続けること。それが、これからの時代に求められるエンジニアの姿であり、その仕事の価値を最大化する道なのです。
