開発生産性の本質は「顧客との信頼関係」にあり

畠中：株式会社メディカルフォース 代表取締役CEOの畠中です。本日はよろしくお願いいたします。私は慶應義塾大学の理工学部に所属し、大学院まで進みました。学部4年時にメディカルフォースを創業し、設立当初からCTOを務めていましたが、2024年11月からはCEOとして会社全体を統括しています。余談ですが、大学では生成AIの研究に取り組んでいました。本日は、CEOとCTOという2つの視点から、お話しできればと思っています。

それでは本題に入ります。「開発生産性」と聞くと、まず頭に浮かぶのは「たくさん開発する」「コードをたくさん書く」「たくさんの機能を作る」といったことではないでしょうか。私個人としては、その前に「何のために開発をしているのか」という問いを深く考える必要があると思っています。

私たちが開発をしているのは、間違いなく「顧客のため」です。顧客のためとは、具体的にはどういうことなのか。確かに、コード量や機能量、リリース数が増えていけば、顧客に喜んでもらえることもあるかもしれません。

しかし、やり方によっては、必要のない機能をたくさんつくってしまうこともあるでしょう。とりあえずコードをたくさん書くだけでは、顧客は決して満足しません。「コードや機能数を増やすこと」と「顧客価値を生み出す開発生産性」の間には、きっと何か別の概念が挟まっているはずだと私は考えています。

もちろん、私たちもコード量や機能数を増やす努力は続けていきます。ただ、本日の講演で最も伝えたいのは「『コード量や機能数を増やすこと』と『顧客価値を生み出す開発生産性』の間にあるギャップを埋めていきましょう」ということです。

私なりの答えを先に述べると、開発生産性とは「プロダクトというインターフェースを通して、顧客と信頼関係を築き上げていくこと」だと考えています。これが実現して初めて、開発が真に生産性へと結びつくのだと信じています。

では、プロダクトを通じて顧客との信頼関係を築くにはどうしたら良いのか。これも私の結論を先に申し上げると、それは「安定性」です。「安定してプロダクトが良くなっていく」「アウトプットが顧客価値につながる」という2つを常に追いかけなければ、いくらコードを増やしても、顧客は決して満足しないのではないかと思っています。



「開発生産性は、安定性と顧客価値から生まれる」という視点から、「安定性」と「顧客価値」という2つの要素を深く掘り下げてお話しします。

まずは「安定性」についてです。正直なところ、安定性を実現するための「How（具体的な方法）」は、それほど難しいものではないと思っています。きちんと安定性に根ざしたKPIを設計することで達成できるでしょう。しかし、何よりも重要なのは、まずマインドセットを安定性に寄せなければならないということです。

目標を設定する際やエンジニアとの会話では「もっと機能を開発しなければいけない」「もっとベロシティを上げなければいけない」といったことを言いがちです。しかし私たちは、ベロシティを追求するのではなく、アウトプットを安定して出し続けることを目指すべきだと考えています。「なぜ安定性が必要なのか」というマインドセットを変えることの方が、重要なのではないでしょうか。

安定性の重要性について、大きく5つのポイントを挙げます。

1つ目は「安定したチームは未来を語れる」ということ。チームが安定していれば、将来のリリース計画を明確に立てられます。これは社内外にとって非常に重要です。例えば、CS部門やセールス部門からの様々な要望が寄せられたとします。エンジニアチームは「いつ、何を、どれだけ依頼できるのか」という点について、他部署や顧客に対して安心感のある提案ができなければなりません。予測可能性が確保されて初めて、他の部署も予測可能性に基づいた目標やゴール設計が可能になるわけです。この予測可能性は、大前提として不可欠なものだと思います。

2つ目は「持続可能な開発ペースが生産性を守る」です。開発者が一時的にベロシティを上げることはできると思います。メディカルフォースも最初の1年半ほどは、ものすごいスピードでコードを書き、機能をつくり続けていました。しかし、それを長期間持続させることは非常に困難です。会社にとって本当に重要なのは、開発者の健康と士気を維持して、そこから安定した生産性を生み出す基盤を築いていくことです。そうして生まれた「余白」が、長期的な成長につながっていくのではないでしょうか。

3つ目は「安定性は負債の制御を可能にする」です。長年システム開発を続けていると、初期のスピードを優先したことによる歪みが必ず生まれてきます。その際に生じてしまった不具合やコードの負債などが、後々の開発スピードを著しく低下させてしまう問題はよく起こります。これまでは開発者個人の安定性についてお話ししましたが、開発組織全体の安定性を築いていくことも重要だと考えています。ここで言う「安定」とは、3年後も5年後も同じスピードで開発できるという状態を維持するという意味合いが含まれています。

4つ目は「安定性が組織連携を産む」です。先ほどもお話しした通り、エンジニアチームの安定稼働は、他部署からエンジニアチームへの信頼関係を生み出すことにもつながると考えています。この後の話にも関連しますが、顧客に価値を生み出すことは、会社全体で協力しないと難しいのが現実です。開発にフォーカスする以前に、顧客に価値を届けることが最重要なのであれば、全社一丸となってそれを推進するための協力関係を築く必要があります。そして、その基盤を作るのは開発組織の仕事です。そういった点も踏まえ、安定した開発組織は組織間の連携を円滑にするのだと言えるでしょう。

最後は「顧客が信頼するのは、継続して進化するプロダクト」です。顧客は、機能が次々とリリースされることや、コードが大量に作られることを求めているわけではありません。顧客が求めているのは「このプロダクトは常に進化している」「3年後も5年後も、このプロダクトは間違いなく良くなっているだろう」という安心感です。商談の場では「現状は優れているが将来性は低いシステム」よりも「3年後も5年後も進化しているシステム」が選ばれます。顧客が本当に求めているのは、安定した改善が継続されることなのです。

繰り返しになりますが、重要なのは、コードをたくさん書いたり、機能をたくさん増やしたりすることだけではありません。顧客が安心して使えるプロダクトを提供する、顧客のために全社一丸となって動く、そのためのマインドセットを身につけなければいけないのだと思います。

メディカルフォースが「全社スクラム」に取り組む理由

畠中：次に「コード量や機能数を増やすこと」と「顧客価値を生み出す開発生産性」の間に何があるのか、という話をしたいと思います。

私がCTOからCEOになって改めて思うのは、SaaSやプロダクト開発の業界において、会社全体を開発組織として動かしていくことが重要なのではないか、ということです。

会社全体が実際にコードを書くわけではありません。しかし「何を開発すべきか」「開発したものをどうデリバリーすべきか」というプロセスを、会社全体でしっかり追っていくことが必要だと考えています。

ここからは、かなり具体的な「How（具体的な方法）」の話をします。結論から申し上げますと、当社はこれを実現するために、全社で「大規模スクラム」を組んでいます。経営陣もスクラムを実践していますし、セールス部門やCS部門もスクラムのフレームワークに乗って動いています。これはかなり特殊な組織運営かもしれません。

スクラムは、簡単に言うと「フレームワーク」であり、チーム運営をどのように進めれば良いかという指針を示したものです。どのような役割の人がどのような仕事をするのか、そのチームの人たちがどのような会議体（イベント）を行うのか、といったことが定義されており、それらを実践することでチームが円滑に回るようになっています。

スクラムの大事なところは「スプリント」と呼ばれる短い期間での計画→実行を繰り返していくこと。そして、前回よりも今のスプリントを良くしていくことを常に追い求めるのが、スクラムの本質的な部分だと私は考えています。

では、なぜこのスクラムを「全社で大規模スクラム」として行っているのか。それは、開発に限らず、セールスやCS担当者たちが行う仕事と、最終的な顧客価値を直結させるための手段となっているからです。

スクラムはリーン思考に基づいており「いま集中しなければならないことは何か」という問いが、スプリントごとに繰り返されます。これにより、無駄な仕事を生み出さないという効果があるだけでなく「顧客価値に直結するコードを書く」という意識が生まれます。CSであれば「顧客のためになるコミュニケーションを取る」という意識が醸成されます。

このスクラムの仕組みによって、そうした顧客価値に直結する部分を担保できるからこそ、当社ではスクラムを全社で採用しているのです。

このスクラムを実践していく上で何が重要なのか。読まれた方も多いかと思いますが、『スクラムガイド』では「透明性、検査、適応」という3本の柱が示されています。この3本柱を土台に、きちんとアウトプットを出していくのがスクラムの基本です。

これらが具体的に何を意味するのかというと、私は「適応、検査、透明性」という順番で考えた方が理解しやすいと考えています。



まず行うべきは「適応」です。現在起こっていること・進行中のものに対して「本当にこれで良いのか」「問題が起こったのなら対処しなければいけない」といったことを、組織として判断する。これがスクラムの目的であり、適応の役割です。

そして、この「適応」をきちんと行うためには「検査」をしなければいけません。現在起こっている問題の内容が理解できていない、もしくは問題が発生していることを把握できていないケースも多々ありますよね。現在の状況を把握するために、検査する必要があるわけです。

さらに、その「検査」をするためには「透明性」が確保されていなければいけません。

この一連の流れが「透明性、検査、適応」の3本柱であり、それぞれを高いレベルで実践し、最終的に適応のレベルを高めることが、スクラムの目的なのだと考えています。



スクラムの基本的な流れは、ここに書かれている通りです。先ほども申し上げた通り、とにかく「やることを決める」のが最初の重要なステップです。この最初のプロセスこそが「コード量や機能数を増やすこと」と「顧客価値を生み出す開発生産性」との間を取り持つ、非常に重要な仕事だと私は考えています。

スクラムには主に5つのイベントがあり、今の話で特に重要になるのは「Refinement」と呼ばれるものです。これは、次のスプリントで何を行うかを具体化したり、顧客が求めていることを議論したり、それを次のスプリントでどう実現していくのかを検討するイベントです。このイベントを繰り返し行っていくわけです。

そして、スクラムの全てのイベントは、先に述べた「透明性、検査、適応」を担保するように設計されています。



例えば、Refinementは、次のスプリントの「What（何をするか）」についての透明性、検査、適応を担保するイベントです。Planningは、次のスプリントの「How」の透明性、検査、適応を担保します。Daily Scrumは、昨日今日の「What」と「How」の透明性、検査、適応を担保していく、というイベント構成になっていると考えています。

スクラムを実践されている方の中で、イベントを飛ばしている方もいらっしゃるかもしれません。これは私の考えですが、イベントは飛ばさずにきちんとやっていただいた方が良い結果につながるのではないかと思います。イベントを飛ばしたいと感じる時は、何かしらの透明性や検査、適応が足りていない場合が多いです。なぜ、飛ばしたいと感じるのかについて考えてみると良いかもしれません。

Scrum@Scaleで実現する高速な意思決定と実行

畠中：続けて「Scrum@Scale」という、大規模スクラムの話をしたいと思います。Scrum@Scaleは、まだメジャーではないかもしれません。

スクラムは非常に優れた仕組みだと私も思いますが、これを拡張していくのは、実はとても難しいことなんです。特に大規模スクラムを導入しようとすると、誰かが犠牲になってしまう、あるいは誰かがとんでもなく大変な負担を背負う、といったことが頻繁に起こりがちです。

そこで、スクラムを無限に拡張できるように設計されたフレームワークScrum@Scaleです。

Scrum@Scaleの根本的な考え方は、2つの軸のサイクルを回すところから始まっています。具体的には「スクラムマスターサイクル（以下、SMサイクル）」と「POサイクル」という2つの軸を回していくことで、Scrum@Scaleは機能するようになっています。



まずは「SMサイクル」から説明します。SMサイクルは「How」の検査を重点的に行うサイクルです。具体的にどういうイベントが当てはまるかというと、例えばDaily Scrumで、昨日を振り返りながら今日行うべきことを決めていきますよね。多くの場合、そこで出てきた問題や適応策は、自分たちのチームだけで解決できることばかりではありません。

そこで、Scrum@Scaleでは「Scaled Daily Scrum（以下、SDS）」という仕組みが提供されています。例えば、開発チームAとBという部署があったとして、開発チームAとBの各Daily Scrumが終わった後、AとBの代表者と開発組織の責任者が集まり、3人で再度Daily Scrumを行うという仕組みです。

私たちはこれを経営層まで連鎖的に行っており、毎日5～6個ほどのDaily Scrumが行われています。始業から1時間半もすれば、どの部署のどのチームで、どういった問題が起きているのかという情報が経営層まで上がってくるようになっています。



次に「POサイクル」についてご説明します。POサイクルは、SMサイクルと逆回転します。経営チームが「会社として何をすべきか」という大きな方向性を決定し、それと連動しながら各事業部で「いま何をすべきか」ということが決まっていきます。そして、各事業部で決まったことが、さらに個別の開発チームに具体的なタスクとして降りていき、最終的に「個別の開発チームが何をすべきか」が明確になります。

ここまで抽象的な話をしてきましたが、実際にどういうことが起こっているのか、具体的な例を挙げて説明したいと思います。



SMサイクルの例として「決済」という新しい機能をつくるケースがあったとします。

決済の開発チームで朝会を行い「以前のプラットフォームから新プラットフォームに移行しようとしたが、データ移行が難しそう」という課題が持ち上がったとします。そうすると、SDSで開発を担当しているチームから、開発組織の責任者の方までこの課題があげられます。そして、それが経営チームまで伝達され「データ移行はどうするべきか」「新プラットフォームと以前のプラットフォームを並行して運用した方が良いのではないか」「これから新しくお客様になる方には新しいプラットフォームを提供し、既存のお客様には以前のプラットフォームを継続した方が良いのではないか」といった判断が1日以内にできます。

このようなスピード感が、この仕組みの大きな強みです。



POサイクルの例として、例えば経営チームで「決済機能に注力していく」と決めたとします。

それを受けて各チームが決済に向けて具体的に何を行うべきか、を判断します。開発チームであれば、決済機能の開発を進めなければなりませんし、マーケティングチームであれば、プレスリリースを打つ準備を始めなければなりません。決済のデリバリーチームは、営業活動を進めるのか、どのような座組で決済機能を販売・提供していくのかを検討します。CSチームはクライアントのペルソナを事前に洗い出す、といったイメージで各部署のタスクが決まっていきます。この全てが1スプリントという短い期間で実行できます。開発自体が1スプリントで終わるかどうかは別として、開発チームが開発を完了した瞬間に、関係するすべてのデリバリー活動が完了している、といった状態を作り出すことができる。これがPOサイクルの力です。



「コード量や機能数を増やすこと」と「顧客価値を生み出す開発生産性」の間にあるギャップは、開発組織だけではなく、会社全体で埋めていかなければいけません。そのギャップを埋めることは非常に難しく、通常のやり方では莫大な時間がかかってしまうでしょう。しかし弊社では、Scrum@Scaleの仕組みを回すことで、短いスパンかつ短い労力で、このプロセスを円滑に回せるようにしています。

会社全体でプロダクトに向き合い、顧客価値に繋げていく

畠中：最後にまとめます。開発生産性とは、プロダクトを通じて顧客との信頼関係を築き続けることです。「コード量が多いこと」「何を開発するのか」「機能をたくさん作る」といったことだけが重要なのではありません。

「コード量や機能数を増やすこと」と「顧客価値を生み出す開発生産性」の間にあるギャップを埋めるのは「安定性」と「顧客価値」であると私は考えています。「安定性」という点では、とにかく関係者のマインドセットを変えてもらうところから始めなければなりません。単にベロシティを追いかけるのではなく、安定性を追いかけるという視点に立つ。これは、開発組織の責任者やマネジメントする側が変えなければならないマインドセットだと強く感じています。

また、「会社全体が開発組織」として、プロダクトの開発やデリバリーにきちんと向き合うことが不可欠です。そうすることで初めて、私たちがつくったコードや機能が、顧客への価値やアウトプットへとつながっていくのです。それによって、開発生産性が高い組織となることができるでしょう。

ご参加されている方の中にCTOの方がいらっしゃいましたら、開発組織全体だけでなく、会社全体がプロダクトを通じて顧客に向き合うという意識に変えていってほしいと強く願っています。

ただベロシティを追求するのではなく、開発組織が安定した稼働をすることで会社全体を安心させられれば、より力強く回していくことができるようになると思っています。

安定性と顧客価値、プロダクトというインターフェースを通して、顧客との信頼関係を築き続けること。これが、これからの時代に求められる開発生産性の本質であり、私たちが目指すべき姿だと思っています。

ご清聴いただき、誠にありがとうございました。

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