開発生産性は経営視点のIssue Drivenで考えよう

「開発生産性は経営視点のIssue Drivenで考えよう」

これが今日の中核メッセージになります。



神原：なぜこう考えるのか、その理由として3つ挙げさせていただきます。まず1つ目が「開発生産性そのものは経営の関心事ではない」ということ。2つ目が「リソースは有限である」ということ。そして3つ目が「経営視点で成果が見えやすくなる」ということです。

この「Issue Driven」という言葉について、少し説明させてください。これは『イシューからはじめよ』という本から引用した言葉です。この本は2010年の発刊なので、もう15年前の本になりますね。我々のようなソフトウェアエンジニアのような知的労働者の中では、結構古典になりつつある本かなと思います。今でもめちゃくちゃいい本なので、読んだことがないという人がいたら、ぜひ手に取ってみていただきたいです。



特にソフトウェアエンジニアの場合、自分がタスクを与えられてやる人から、「何をやるんでしたっけ？」ということを考える人、「どんな施策をやるんですか？」ということを考える人になったあたりで、読むとピンとくる本だと思います。

では、そのIssue Drivenについて詳しく説明していきます。まず、私の好きな引用をご紹介させてください。かの天才アインシュタインはこんなことを言いました。

「もし仮に地球を救うために1時間の時間を与えられたとしたら、私は59分を問題の定義に使い、1分を解決のために使うであろう」

これは非常に示唆に富んだ言葉だと思います。問題の定義にほとんどの時間を使うと、天才のアインシュタインは言っているわけですね。

ここで言う「問題の定義」とは何でしょうか。私の考えでは、まず「どの問題を解決するのか」、そして「その問題とは何であるのか」、こういった定義がとても大事だということです。

我々のほとんどは会社組織で働いていますから、会社組織でどの問題を解くのかということを考える時に、一番大事になるのが「経営が何を気にしているんですか」という話です。

開発生産性そのものは経営の関心事ではない

それでは、開発生産性を経営視点のIssue Drivenで考えるべき理由ついて詳しく説明していきます。1つ目は「開発生産性そのものは経営の関心事ではない」ということです。

まず、経営が何を重視しているのかを整理してみましょう。経営の関心事の1つ目は、経営成果です。



具体的には3つの要素があります。1つ目が事業成長で、YoY成長率などの指標で測られます。2つ目が収益で、売上の向上とコストの削減が含まれます。3つ目が市場競争力で、Moatや「7 POWERS」といった概念で表現される競争優位性のことです。

経営の関心事の2つ目は、資源配分と投資判断です。経営の視点から見ると、開発は数あるファンクションの一つに過ぎません。



SaaS企業を例に取ると、限られた予算を開発に投入するのか、マーケティング・セールスに投入するのか、人材・組織力の向上に投入するのかという選択が常に求められます。また、人員をどこにどれだけ配置するかという判断も必要です。複数事業を展開している会社であれば、事業間のリソース配分バランスも重要な意思決定となります。

ここで典型的な会話例を見てみましょう。エンジニアリングマネージャーやCTO、テックリードと社長との間でよく起こる対話です。

エンジニア側が「技術的負債が溜まっています」と訴えても、社長側は「それやらないと失注するのか？」と応答します。エンジニア側が「テストを自動化する必要があります」と提案しても、社長側は「コストは増やしたくないのだが...」と懸念を示します。

このような経験をお持ちの方は多いのではないでしょうか。話がかみ合わない理由は、開発の言葉と経営の言葉が異なるため、インピーダンスミスマッチが発生しているからです。

このため、開発生産性について議論する際は、それを経営の関心事に適切に翻訳して考える必要があります。

経営の関心事を具体化すると、現在の経営状況において売上を伸ばすことが優先なのか、コストを削減することが優先なのかという問いになります。また、短期的な受注加速を重視するのか、中長期的な開発スピード向上を重視するのかという時間軸での優先順位もあります。

事業成長の観点では、機能の豊富さが必要なのか、各機能の品質の高さが必要なのかという選択もあります。これらは二者択一の問題ではありませんが、経営がどこに課題を感じ、何にフォーカスしているのかを正確に把握することが重要です。

では、どのように変換すれば良いのでしょうか。経営課題と開発生産性施策の対応関係を整理してみます。



経営の言葉と開発の言葉は明確にマッピングできます。このように変換することで、経営の言葉で開発生産性の議論ができるようになります。

リソースは有限である

続いて2つ目の理由「リソースは有限である」について説明します。

ここで改めて、『イシューからはじめよう』という本からの重要な概念をご紹介します。この本では避けるべき「犬の道」について言及されており、その中で極めて重要な指摘がされています。「一心不乱に大量の仕事をすることで、バリューを上げようとしても無駄である」ということです。



ソフトウェアエンジニアリングの現場において、改善には終わりがないという現実があります。

世の中には無数のベストプラクティスが存在し、日々大量に発生し続けています。時間が経過するとともに、実践できていない項目の数は増加の一途をたどります。生成AIが登場して以降、この傾向はさらに顕著になっています。

ファインディのプロダクトマネジメント室長が言及していた「AI疲れ」という現象が示すように、日々大量に新しい技術や手法が発生し、実装できていない要素が継続的に増加している状況です。

実践できていないことは確かに課題ですが、それが現時点で解決すべき優先課題であるとは限りません。この区別を明確にすることが重要です。

改善を検討する際、通常は費用対効果で評価されます。ROI による分析では、R（リターン）は改善のために投入したコスト、I（投資効果）は主にコスト削減効果として算出されます。

開発生産性の改善における投資対効果は、将来の開発コストの削減として現れます。例えば1ヶ月分の投資により、将来にわたって開発工数が5ヶ月分削減される場合、投資対効果は5倍となります。インフラコストの削減も同様のリターンとして計算されます。

しかし、この分析で見落とされがちな要素があります。それが機会損失と先行者利益の概念です。

開発生産性の改善施策に1ヶ月を費やすということは、その期間中に魅力的な機能の開発が停止することを意味します。競合他社が継続的に開発を進める中で、本来であれば獲得できたかもしれない先行者利益を放棄することになります。

このトレードオフを適切に評価して判断する必要があります。製造業の顧客との対話から見えてきたことですが、従来はアナログ的な文化と思われていた製造業においても、現在はスピードが重視される時代になっています。

多くの企業で「コストが多少高くても、開発期間を2年から半年に短縮したい」という要求が一般的になっています。これはソフトウェア業界に限らず、現代のビジネス環境全体がスピード重視になっていることを示しています。そのため、機会損失や先行者利益を考慮した判断が不可欠です。

以上を踏まえて提案したいのは、「改善しない勇気」を持つということです。経営にとって重要度の高い課題のみを対象とするIssue Drivenアプローチで改めて検討しましょう。その他の改善やベストプラクティスについては、戦略的に後回しにする判断も必要です。

経営視点で成果が見えやすくなる

最後の理由として、「経営視点で成果が見えやすくなる」ということについて説明します。

ファインディのアンケートによると、100人のエンジニアリングマネージャーとCTOのうち、採用強化に95%、生産性向上に85%の人が悩んでいます。この背景には、エンジニアリングマネジメントの成果が見えづらいという問題があります。



エンジニアリングマネジメントの成果が見えづらい理由は、そもそも計測できないことが多いからです。

人材育成は重要な仕事ですが、その成果を測定することはできません。「この人が成長したので事業が伸びました」という関係があっても、成長の事業への寄与度を定量化することは不可能です。意思決定についても同様で、技術選定でA案を選択し成功しても、B案を選択した場合の結果が存在しないため、A案選択の価値を測定できません。合意形成や動機づけも、効果を定量的に評価することは困難です。

一方で、開発生産性向上の成果は見える化できます。従来の表現と経営視点での表現を比較してみましょう。



従来の「技術的負債が溜まっています」「テストを自動化する必要があります」という表現に対して、経営視点では「週1回のリリース制限で年間x億円のアップセル機会を逃しています」「技術的負債により機能開発工数が昨年比40%増加、市場投入速度がx%低下し、ARR成長率をnポイント押し下げています」と表現できます。

このような表現により、経営陣から「すぐ改善してくれ」「その負債をすぐ返済してくれ」という前向きな反応を得ることができます。

机上の空論的な側面もありますが、重要なのはロジックが一貫しており計測可能であることです。Four Keysなど一般的な指標と経営成果を結びつける変換ロジックを構築できれば、具体的なビジネスインパクトを説明できます。

現在は生成AIを活用できる時代です。経営成果指標と開発生産性指標を結びつけるロジックは一般論であるため、生成AIに基本的な変換ロジックの作成を依頼できます。人間の仕事は、自社の外部環境と内部環境をもとに問いを立て、仮説を作成し、分析することです。

実践編：基本フローチャート

ここまでの話を踏まえて、どのように実践していけばよいのかという基本フローを簡潔にご紹介します。



このフローチャートは左上から始まって右に進行し、下に行って回るループ構造になっています。まず出発点は「経営課題を知る」ことです。これは今回の講演の主張と同じで、経営が何を課題として認識しているかを把握することが第一歩です。

フローで最も重要なのは「開発生産性の課題と経営課題って結びつくのか？」という分岐です。

結びつかない場合は「犬の道」を回避し、魅力的な機能開発を優先します。状況が変化して開発生産性の改善が経営課題と重なる時が来たら、改めて生産性改善施策に取り組むという流れです。

開発生産性の課題解決が経営課題の解決につながると判断できた場合、まず「ボトルネック特定と分析」を行います。ここが人間の仕事で、自社の外部環境や内部環境は汎用の生成AIには理解できないため、自分で考える必要があります。

次に「ROI試算やKPI設定」を行います。ここは生成AIに頼れる部分です。経営視点とつなげるロジックについては、一般論的な内容のため生成AIに依頼できます。

その後「ボトルネック解消」を実行し「結果測定」を行い、効果が不十分であればまたループを回します。

キャディでの実践事例

ここからは、キャディ株式会社での実践事例をご紹介します。

キャディは製造業AIデータプラットフォーム「CADDi」を提供しています。データとAIの力で製造業企業の生産性向上、脱属人化、QCD最適化といった課題を解決するプロダクトです。



プロダクトの構造は、CADDiデータ基盤に図面、3DCAD、仕様書、不具合情報といった製造業企業の重要な情報資産を集約し、そのデータベースを活用してCADDi DrawerやCADDi Quoteなどのアプリケーションを展開する仕組みになっています。

キャディが現在置かれている状況を整理します。まず日本市場で急成長中で、言える範囲ではT2D3を大きく超える速度で成長しています。課題はARPA（平均顧客単価）のさらなる向上と価値の多層化です。

US市場の開拓中で、創業者の代表・加藤が自らアメリカに移住し、現地でローカル人材チームを組成しています。また、組織のグローバル化が進行中で、テクノロジー組織の25%が日本以外の出身者です。

事例1：コンパウンド戦略のためのPlatform Engineering

経営の関心事はARPA（平均顧客単価）の向上です。1社あたりの契約金額を上げるため、既存のCADDi Drawerの契約金額拡大や、CADDi Quoteも含めた複数サービス利用顧客の増加を目指しています。

戦略として、今後3年で数十のアプリケーションとサービスを開発することが決まっています。そのため開発関連の課題として、新規アプリ・サービスの立ち上げ期間短縮が必要になります。

対策として、Platform Engineeringにより新規アプリ・サービスの立ち上げ期間を3分の1にすることに取り組んでいます。これは経営課題と開発生産性向上施策が綺麗につながっている例です。

事例2：US市場開拓のためのセキュリティ

経営の関心事は、事業成長スピードのさらなる加速です。経営が目指しているのは、現在のT2D3超えという成長をはるかに上回る速度での成長で、そのためにはアメリカ市場でのPMF（Product Market Fit）が必要です。

意外な課題として浮上したのが、US大手企業水準のセキュリティレベルです。キャディは日本では名だたる大企業に利用いただいており、セキュリティレベルも万全ですが、アメリカではUSリージョン対応やアメリカ独自の法令対応など、追加要件への対応が必要になります。

しかし、今後3年間で数十個のアプリケーション開発が予定されているため、セキュリティ強化による開発速度の低下は許されません。

対策として、アプリ・サービス開発の足枷にならない高セキュリティを実現するPlatform Engineeringに取り組んでいます。経営課題を知り、開発でできることとの接続を考えた結果です。



これらの事例から、経営課題を起点とした開発生産性向上施策の検討により、施策の必要性と効果を経営陣に明確に説明できることがわかります。新規アプリ・サービスの立ち上げ期間が3分の1になれば、経営への貢献度も見えやすくなります。

まとめ

最後に、キャディでの取り組みと今後について簡単にお話しします。

現在、キャディは事業成長を重視し、アメリカ市場での成功を目指して積極的に取り組んでいます。急激な変化の中にあり、通常であれば5年で起きる変化が1年程度で発生しているような状況で、非常に挑戦的な環境となっています。

入社して想定を超える発見だったのは、製造業向けソフトウェア開発の複雑性と面白さです。製造業向けのソフトウェアは個社特有の事情、複雑な業務プロセス、規制や法律など、多様な要素が複雑に組み合わさっています。この複雑性が課題解決の面白さを生み出しており、技術的な挑戦として魅力的な領域だと感じています。

現在、キャディでは様々な領域で人材を募集しています。今後3年間で数十のアプリケーション開発を予定しているため、Platform Engineering、アプリケーション開発、セキュリティなど、幅広い分野で力を発揮していただける方を求めています。ぜひ一度カジュアルにお話ししましょう。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です