目次
Open 目次
はじめに
こんにちは。
現代のソフトウェア開発について考えるとき、ソフトウェアエンジニアとして、どのような開発のあり方が望ましいのかに対しての説明として以下のような観点があると思っています。
- モジュール性が高く、変更容易性の高いソフトウェアを作ること
- テストピラミッドに基づいて自動テストを書き、CI/CDによって継続的に品質を担保すること
- クラウドネイティブなアーキテクチャを採用し、利用量に応じてスケールできるような可用性を確保すること
- ビジネスサイドと開発のコミュニケーションコストをできるだけ減らし、素早く変更しながら仮説検証を繰り返せる体制を作ること
- etc.
上記のような観点を、私は現代のソフトウェア開発においてかなり重要だと思っています。
内部品質の高いソフトウェアを作り、継続的に改善できる開発プロセスを持つことで、将来の事業成長の可能性を高められる。ユーザーに価値をより素早く届けられるようになる。障害そのものを起こしにくくし、仮に障害が起きたとしても素早く復旧できるようになる、こういった状態を作ることが非常に重要だと考えています。
ただ、実際にこれを組織の中で実現しようとすると、技術的に正しいことを知っているだけでは全く足りなくて、そこを踏まえた上でいかに経営に対して売るか、という話になってきます。
金額に変換するのが難しい
この話が難しい理由はかなり明確で、先ほど挙げたような開発の価値は将来に対する事業成長の可能性を語る話だからです。
変更容易性が高くなることで、将来的な開発速度が上がる。自動テストが増えることで、変更時のリスクが下がる。ビジネスと開発が密に連携することで、仮説検証の回数を増やせる。 こういった話は、まさに開発生産性をメインとしたカンファレンスだったり、アジャイルやスクラムのような話の中でもよく語られる話です。 まさに、現代のマーケット環境が変化の激しい時代だからこそ、ソフトウェア開発においても、素早く変更を繰り返せるようなあり方にしていかなければならない、という話です。
ただ、これを「では、いくら儲かるんですか」と聞かれると、一気に説明が難しくなってしまうんですよね。 特に、すでにある程度開発が進んでいて、ユーザーも獲得できているようなサービスや、長期間稼働しているシステムでこの傾向がかなり強くなるように感じています。
そういったシステムに対して新しい開発体制を提案すると、どうしても 「今の開発費はいくらなのか」 「新しい体制にするといくらになるのか」 「結局どちらが安いのか」 という話になりやすいように思います。
もちろん、コストを見ること自体は経営の観点で重要です。 ただ、本来議論したいのは、単純な開発費削減だけではなくて、将来的に事業を成長させるための投資として、どのような開発能力を組織の中に持つべきなのか、という本質的な部分を議論して意思決定したいわけです。
外注と内製を、単純な金額だけで比較するのは難しい
私自身、事業会社が自社のプロダクトを内製で開発していく体制が望ましいと、以前から考えています。
日本の事業会社では、ソフトウェア開発を外注する文化がまだかなり根強いと思っています。
もちろん外注そのものが悪いという話ではなくて、事業のコアではない部分の開発に関しては、外注を活用することが合理的な選択となる部分が大いにあると思います。
ただ、請負契約を中心とした構造では、どうしても「決められたものを、決められた期間と金額で作る」というインセンティブが強くがちです。
その結果として、本来は継続的に投資していくべき内部品質が後回しになりやすいと感じています。
また、社内にエンジニアがいない状態で外注に依存していると、本来は事業側がしっかりと考えるべき非機能要件や、ベンダーが提示してきた設計の妥当性を判断することができず、結果として内部品質が低い状態で開発が進んでしまうこともあります。
実際に僕自身も、そういったコードを何度も見てきました。
可読性がほとんど考慮されていないコードや、もう使われていないのにコードベースに残り続けているコード、依存関係が複雑になりすぎていて、変更しようとすると影響範囲の特定だけで大きなコストがかかるコード、自動テストが存在しないため、変更するたびに人力でテストしなければならないシステム、さらに利益を伸ばすための改修を行いたいのに、内部品質が悪いせいで開発のアジリティそのものを失っている状態です。
こういった状態のコードに対して向き合ってきた経験から、事業会社が自社のプロダクトを内製で開発していく体制を作ることは、将来的な事業成長の可能性を高めるために非常に重要だと考えています。現代的なソフトウェア開発のプラクティスを取り入れて、開発をコントロールできる形を作るのが重要だと思います。
ただここで難しい問題があって、外注で今まで作ってもらっていたものと、内製化後に作ろうとしているものは、そもそも費用の中身が違います。
外注費用の中には、極端に言えば、目に見える機能要件を最短で実現するための工数しか含まれていないことがあります。
一方で、内製体制を本気で構築しようとすると、自動テスト、CI/CD、内部品質向上、開発環境整備、人材育成、ドメイン知識のインストール、開発文化の醸成といった様々な活動が必要になります。
つまり、一口に開発費と言っても、比較しているものの中身が全く違うわけです。
ここを説明せずに単純な金額比較だけをすると、 「内製にしたのに、そこまで安くならないですね」 という話になってしまいます。
ただ、作っているものや目指す目標が違うので、単純な金額比較だけでは判断できなくて、ある意味それは当然だと思っています。
片方は機能を作るための費用で、もう片方は将来的に継続して価値を生み出すための開発能力そのものへの投資まで含んでいるのですから。
なので、費用対効果をきちんと意思決定に盛り込むためにも、ここをきちんとエンジニア以外の人たちが理解できる形に翻訳しないといけません。
エンジニアが伝えたい価値と、経営が見ているものは違う
この手の話は、エンジニアやエンジニア経験のあるPMや部長レイヤー、CTOなどには比較的伝わりやすい話かと思います。
変更容易性が重要だとか、自動テストが重要だとか、ビジネスと開発が一体になった方が良いという話は、ソフトウェアエンジニアであればある程度共通認識があるので、具体の金額の話をしなくても理解が進みやすい。
一方で、エンジニア経験のない事業責任者やマーケティング、技術的なバックグラウンドを持たない経営陣や取締役に持っていくと、一気に難しくなる感覚があります。
もちろん、彼らも頭が切れる方々ばかりなので、イメージとしては理解してもらえることは多いと思います。 ただ、最終的に経営として意思決定しようとすると、 「具体的にいくらかかるのか」 「どれくらい削減できるのか」 「投資した結果として何が変わるのか」 という話になります。
経営判断という観点では、これはある意味当然ですよね。 なぜなら、経営は限られた経営資源をどこに配分するかを決める立場なので、最終的に金額の話を避けることはできないからです。
だからこそ、エンジニア側には適切な意思決定のための適切な翻訳が必要になります。 技術的に正しいことをそのまま説明するのではなく、それが事業に対してどのような影響を与えるのかを説明しなければいけません。
あるべき姿に変革していくためには、ここがかなり重要だと思っています。
経営に刺さりやすい話と、刺さりにくい話がある
実際に経営とのコミュニケーションをしていて、一番分かりやすいと感じるのはセキュリティですね。
サイバー攻撃によって個人情報が流出するとか、サービスが停止する、障害対応のために多くの人員が拘束される、信用が毀損し、その影響で将来の売上まで落ちる。 こういった話は、経営にとってもかなりイメージしやすいです。 セキュリティ事故による損失は、経営リスクとして理解しやすいからです。
同じように、開発生産性やインフラ費用の最適化も比較的伝わりやすいと思っています。 たとえばFindy Team+のようなツールを利用して、開発生産性を継続的に計測する、開発のリードタイムやアウトプットを可視化し、それがどの程度改善しているのかを見る、あるいは、インフラ構成を最適化して、月々のランニングコストをどの程度削減できるのかを見る。 こういった話は、数字との距離が近いので説明しやすいです。
一方で、「ビジネスと開発が二人三脚になることでコミュニケーションコストを減らします」とか「Product-led Growthを目指します」とか「仮説検証を高速化して事業成長を加速させます」 といった話は、途端に伝えるのが難しくなる感覚があります。
本当はむしろ、こちらの方が重要ですよね。開発体制を変えることの本質的な価値は、将来的な事業成長の可能性を高めることにあるからです。
ただ、将来の事業成長に対する投資なので、具体的な金額に落とし込みづらい。 重要度と説明しやすさが一致していないんですよね。
経営に対する「営業戦略」が必要になる
最終的に実現したいことを一言で表すなら「ビジネスサイドと開発をより密に連携させて、仮説検証プロセスを高速化させ、事業成長を加速させること」だと私は考えています。
ただ、これをいきなり経営に持っていっても、なかなか意思決定にはつながらないんですよね。
なので私が今関わっているプロジェクトでは、かなり地道にボトムアップで進めています。 まずはPMやEMを巻き込んで、どういう伝え方をすればよいのか、新しい体制では何人必要なのか、どのくらいの工数が必要なのか、具体的な費用はいくらなのか、既存の体制と比べて何が変わるのか、そういったところを徹底的に議論して、詰めていきます。
その後、事業責任者と議論する、事業側の視点から見て、どの説明なら納得感があるのかを確認する、その上で、ようやく経営に持っていく。
こう考えると、これはかなり営業に近い活動だなと思います。 自分たちが主導する開発体制がいかに事業運営の観点で価値があり、かつROIを最大化できるのかという経営に対する営業です。
一回のプレゼンで説得するというよりも、関係者を一人ずつ巻き込みながら、相手に合わせて説明のレイヤーを変え、理解者を増やしていくという営みです。
ボトムアップで組織を変えようとすると、かなり広範囲な人たちに対して、粘り強くコミュニケーションを続ける必要があります。
多くの資料作成や見積もり、数字の根拠、技術的な説明の体系的な用意が必要になってきます。
そして、説明する相手によって言葉を変える必要があります。 エンジニア同士であれば、「変更容易性を高めたい」で通じるかもしれませんが、経営に対しては例えば「変更容易性が上がることで、新しい施策を市場に出すまでの期間を短縮できる」といったような方向性で説明を行う必要があります。
「自動テストを増やしたい」ではなく「変更時の確認工数を減らし、リリース頻度を上げながら障害リスクを下げる」
「内部品質を上げたい」ではなく「将来的な機能追加のコスト増加を抑え、事業成長に合わせて開発を継続できる状態を作る」
と翻訳しないといけません。
エンジニアリングマネジメントには、翻訳能力が必要になる
エンジニアは技術者なので、気を抜くとどうしても技術者が分かる言葉で話してしまいます。
ただ、組織の中で本当に望ましい開発を実現したいのであれば、それだけでは足りなくて、相手が何を見ているのかを理解し、その言葉に翻訳する必要があります。
経営が金額を見るのであれば、金額にどう影響するのかを説明する。 事業責任者が売上を見るのであれば、開発体制が事業成長にどうつながるのかを説明する。 PMであれば、仮説検証の速度や施策実行の柔軟性で説明する。 エンジニアであれば、内部品質や開発体験の話まで踏み込んで説明する。
同じことを説明するにしても、伝えるレイヤーによって言葉を変える必要があります。
私自身、あるべき姿に組織の意思決定を持っていこうとしているタイミングで、まさにこの難しさに直面しています。
ただ、逆に言えば、ここまでやらないと本当に望ましい開発体制は作れないのだということを痛感しています。
良いソフトウェアを作るためには、良いコードを書くことだけでは足りないし、良い開発プロセスを知っていることだけでも足りません。
事業としてソフトウェア開発を行う以上、それを実現するために必要な予算、人員、体制を獲得しなければいけません。 そのためには、経営に対して価値を説明し、納得してもらい、意思決定してもらう必要があります。
そう考えると、エンジニアリングマネジメントには自分の目指したい開発のあり方に対して何らかの経営に対する営業戦略が必要になりそうです。
技術的な正論を、相手が意思決定できる言葉にまで翻訳する。 そのために関係者を巻き込み、根拠を積み上げ、何度も説明する。
望ましい開発を実現するためには、そこまで含めてのエンジニアリングになるのだと思います