⚠️ 文章の半分以上を酔っ払った状態で作成しています。その点はご容赦下さい。 そのため良い文章ではある気がするのですが散文になってしまってます。
はじめに
「うちのエンジニアチーム、生産性どうなの？」
この質問を受けたとき、あなたはどう答えますか？Four Keysの数値を見せますか？プルリクエストの量を報告しますか？それとも、売上への貢献度を説明しますか？
昨晩、オタク達との飲み会で、この話題が出ました。先週、Findyさん主催の開発生産性カンファレンス2025があったからだと思います。
dev-productivity-con.findy-code.io
正直に言うと、私自身も長年この問題に悩んでいました。数値で示せと言われるけれど、何を測れば本当に意味があるのか。測定すれば改善するのか。そもそも測定する価値があるのか。経営層からのプレッシャーと現場の実情の間で、いつも板挟みになっている感覚でした。
開発生産性を測定しようとすると、すぐに気づくことがあります。これは単純な数値化の問題じゃない。人間の心理、組織の政治、そして技術の複雑さが絡み合った、実に厄介な問題なのです。
過去10年間で、開発生産性を測定するための様々なフレームワークが提案されてきました。DORAのFour Keys、SPACE framework、そして最新のDevEx（Developer Experience）。これらは確かに有用なツールですが、同時に新たな問題も生み出しています。測定することで行動が歪められ、本来の目的を見失ってしまうことも珍しくありません。
私が初めてFour Keysを導入しようとした時、チームメンバーから出た質問が忘れられません。「この数値が良くなったら、僕たちは本当に幸せになれるんですか？」その時、測定の本質的な問題に気づいたのです。正直、答えに詰まりました。
測定することで何が変わるのか？何が改善されるのか？そして、何が失われるのか？
この記事では、開発生産性の測定に潜む「落とし穴」について深く掘り下げ、どうすればそれらを避けながら本当に価値のある改善を実現できるかを探求します。単なる理論的な議論ではなく、実際の現場で起こる問題と、それに対する実践的な解決策を提示することを目指します。
なぜなら、開発生産性の向上は、単に数値を改善することではなく、開発者がより良いソフトウェアを、より効率的に、より楽しく作れるようにすることだからです。そして、それこそが私たちが本当に目指すべき「生産性」なのです。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。
測定されることで変わってしまう人間
工場で製品を数えるのとは違って、エンジニアは自分が測定されていることを知っています。そして、測定されているとわかると、行動が変わってしまう。
これは別に悪いことではありません。むしろ自然な反応です。問題は、測定された数値を上げることが目的になってしまうことなんです。
DORAの研究によると、デプロイ頻度、リードタイム、変更失敗率、復旧時間の4つの指標が重要とされていますが、これらの指標を単純に追いかけるだけでは本質的な改善にはつながりません。
考えてみてください。デプロイ頻度を上げろと言われたら、どうしますか？
実際に私のチームであった話ですが、デプロイ頻度をKPIにしたところ、メンバーがREADMEの誤字修正やコメントの微調整でデプロイ回数を稼ぎ始めました。確かに数値は改善しましたが、本質的な価値は何も生まれていない。このような本末転倒な状況を見て、測定の危険性を痛感しました。
変更失敗率を下げろと言われれば、リスクを取らなくなり、イノベーションが止まる。リードタイムを短縮しろと言われれば、十分な時間をかけた設計やテストを怠る。
私が見てきた中で最も印象的だったのは、プルリクエストの数を増やすために、本来一つでよい変更を無理やり細分化していたチームです。数値は改善したけれど、レビューの負担は増え、全体の開発効率は下がっていました。
測定の副作用とリスク
測定には、必ず副作用があります。薬と同じです。効果があるものには、必ず副作用がある。
「どのような定量的な社会指標も、社会的意思決定に用いられると、その分だけ劣化圧力を受けやすくなり、追跡対象としていた社会的プロセスがゆがめられ劣化する傾向が強まる」というキャンベルの法則は、開発現場でも頻繁に観察される現象です。
特に有害な測定指標として、コード行数（Lines of Code, LOC）があります。1982年のApple Lisaでの有名な事例では、Bill Atkinsonが2,000行のコードを削除してQuickDrawのパフォーマンスを6倍速くしたとき、彼の「生産性」は-2,000行と記録されました。この出来事により、経営陣はコード行数による測定を即座に廃止しました。
私も似たような経験があります。レガシーコードの大規模リファクタリングで、1万行を3,000行に削減したプロジェクト。技術的には大成功でしたが、評価面談では「今期はアウトプットが少ない」と指摘されました。数値で見れば確かにマイナスですが、保守性は格段に向上したのに。
「測定できないものは管理できない、と考えるのは誤りだ。これは代償の大きい誤解だ。」という言葉は有名です。実は、この言葉は測定の重要性を説いたとされるピーター・ドラッカーの言葉を、後の人が誤解して広めたものなんです。
開発生産性の測定に集中すると、測定されない重要な活動が犠牲になります。メンタリング、技術調査、リファクタリング、コードレビューでの丁寧な指導。これらの活動は短期的には数値に現れませんが、長期的なチームの健全性には不可欠です。
ある優秀な新人エンジニアの話をしましょう。彼女はいつも他のメンバーの質問に丁寧に答えていました。しかし、コミット数で評価されるようになってから、「申し訳ないけど、自分のタスクに集中させてください」と言うようになりました。チーム全体の知識共有が減り、結果的に生産性は低下しました。
測定を報酬や評価に直結させると、さらに大きなリスクが生まれます。内発的動機が外発的動機に置き換わり、創造性と自律性が損なわれるのです。
測定の隠れた代償：バーンアウトという現実
2021年の研究では、83%の開発者がバーンアウトを経験していることが明らかになりました。このうち81%が、パンデミック期間中に燃え尽き症候群が悪化したと報告しています。
バーンアウトは単なる疲労ではありません。WHO（世界保健機関）の定義によると、バーンアウトは「職場の慢性的なストレスが適切に管理されていない結果として生じる症候群」です。
私自身、2019年のあるプロジェクトでバーンアウトを経験しました。「生産性向上」のプレッシャーの中、毎日ベロシティチャートを見せられ、「もっと速く」と言われ続けた結果、3ヶ月で燃え尽きました。朝起きられなくなり、コードを見るのも嫌になりました。回復するのに半年かかりました。
最新の研究では、誤った生産性測定がバーンアウトの主要な原因の一つとなっていることが指摘されています。開発者が非現実的な納期を与えられ、コミット数やコード行数などの表面的な生産性指標によって評価されることで、慢性的なストレスが蓄穏されるのです。
Computer Weeklyの調査によると、「開発者生産性ソリューションは、開発者が軽減されていないリスクに遭遇したときに、より速く出荷することで対処しようとしており、これは必然的にソフトウェアエンジニアのバーンアウトを増大させる」とされています。
バーンアウトの症状は多面的で、精神的・感情的な面では集中力の欠如、記憶力の問題、創造性の低下として現れます。身体的には頭痛、疲労、不眠、消化器系の問題が生じ、行動面では社会的活動からの引きこもり、生産性の低下、欠勤の増加が見られます。
生産性の基盤：心理的安全性
GoogleのProject Aristotleは、チームの成功において最も重要な要素を特定するために、2年間にわたって180以上のチームを研究しました。その結果、驚くべき発見がありました。
研究者たちは当初、成果の高いチームは最も優秀な個人の集まりだと考えていました。しかし、実際にはチームの成功は「誰がチームにいるか」よりも「チームがどのように協力するか」によって決まることが判明しました。
私も前職で同じ勘違いをしていました。各分野のエキスパートを集めたチームを作ったのですが、結果は期待を大きく下回りました。お互いに批判し合い、建設的な議論ができず、プロジェクトは失敗に終わりました。
最も重要な要素は心理的安全性でした。心理的安全性の高いチームは、対話の機会が平等で、全メンバーが発言の機会を持っていました。また、高い社会的感受性を持ち、チームメンバーの感情やニーズを理解する能力に長けていました。そして何より、失敗を恐れずに新しいアイデアを提案できる環境がありました。
心理的安全性の高いセールスチームは、目標を17%上回る成果を上げた一方、心理的安全性の低いチームは最大19%目標を下回りました。
これは開発チームにも当てはまります。2019年のDORA State of DevOpsレポートでは、心理的安全性がソフトウェア配信パフォーマンス、組織パフォーマンス、生産性を予測する重要な要因であることが示されました。
開発生産性の7つの項目：DORAモデルが示す本質
開発生産性について議論していると、いつも同じようなことが起こります。プロダクトマネージャーは「機能の価値」を重視し、エンジニアは「コードの品質」を強調し、経営層は「売上への貢献」を求める。みんなが違うレイヤーの生産性について話しているから、永遠に議論が平行線をたどるんです。
DORAの最新Core Modelを見ると、開発生産性は「Capabilities（能力）→ Performance（パフォーマンス）→ Outcomes（結果）」という流れで構成されています。これを踏まえて、私が長年の経験から見てきた3つの階層で7つの項目を整理してみます。
Capabilities（能力）
Climate for learning（学習環境）
最初に紹介するのは、おそらく最も見過ごされがちな要素です。
DORAの研究者たちは、Climate for learning（学習環境）を測定可能な4つの要素に分解しました。コードの保守性、ドキュメントの品質、生成的文化、そしてチームのツール選択権限。一見バラバラに見えるこれらの要素が、実は「チームが継続的に学び、成長できる環境」という一つの概念を形作っているんです。
「最近、チームメンバーが新しい技術について積極的に議論するようになったね」—もしこんな変化に気づいたら、それは学習環境が改善している確かな兆候です。
Generative cultureとは、Ron Westrum博士が提唱した組織文化の3つのタイプの中で最も高次元の文化です。病的文化（Pathological culture）では情報が隠蔽され、責任が個人に押し付けられます。官僚的文化（Bureaucratic culture）では規則に従うことが重視され、責任が部門に分散されます。そして生成的文化（Generative culture）では、情報が自由に共有され、共通の目標に向かって協力します。
多くのチームで見られる現象ですが、「優秀なエンジニアを集めれば、自然と良いチームになる」という思い込みは危険です。実際には、メンバーが意見を言わなくなり、問題の報告が遅れ、新しいアイデアも出なくなってしまうことがあります。私の経験でも、優秀な人材が集まったチームほど、お互いに遠慮して本音を言わない傾向がありました。
この問題の本質は、無意識に作り出される「完璧主義の圧力」にあります。チームメンバーが「間違いを犯すことを恐れて、本当に必要な議論ができない」状態に陥ってしまうのです。
学習環境の特徴は、情報の透明性を重視し、問題や課題が隠蔽されることなく、オープンに議論される環境を作ることです。学習志向も特徴的で、失敗を責めるのではなく、学習機会として捉えます。共同責任の考え方も大切で、チーム全体で成果と責任を共有します。そして、プロセスと結果の両方を継続的に改善していく姿勢が根付いています。
Empowering teams to choose toolsも学習環境の重要な要素です。チームが自分たちの課題に最適なツールを選択できることで、自律性が向上し、内発的動機が高まります。選択の権限を持つことで、結果に対する責任感が自然に生まれ、新しいツールを試行錯誤することで、継続的な学習が促進されます。
Fast flow（高速な流れ）
デプロイ時間が10分から3分に短縮されたとき、エンジニアたちは歓声を上げました。でも、本当の価値はその7分間の短縮にあるのでしょうか？
実は違います。Fast flowの本質は、価値を継続的に流す「仕組み」を構築することにあります。DORAが定義するFast flowは、継続的デリバリー、データベース変更管理、デプロイメント自動化、柔軟なインフラストラクチャ、疎結合チーム、変更承認の簡素化、バージョン管理、小バッチでの作業という8つの要素から成り立っています。
デプロイ自動化に多大な時間を費やしても、実際のビジネス価値の向上は微々たるものになることがあります。技術的に高度な自動化システムを構築しても、何をデプロイするかの意思決定プロセスが改善されていなければ、本質的な生産性向上にはつながりません。実際、私も過去に3ヶ月かけて構築した自動化システムが、結局「速く価値の低いコードをデプロイできるようになっただけ」という苦い経験があります。
Fast flowの重要性は、その再現性と拡張性にあります。一度構築すれば、チーム全体、そして組織全体の生産性を底上げできます。
興味深いのは、これらの要素が相互に作用し合うことです。小バッチでの作業が継続的デリバリーを容易にし、疎結合なアーキテクチャがデプロイメント自動化を促進します。逆に、一つの要素が欠けると、他の要素の効果も著しく減少してしまいます。
疎結合チームの概念は特に重要です。チーム間の依存関係を最小化することで、独立した開発とデプロイが可能になります。これにより、一つのチームの問題が他のチームに波及することを防ぎ、全体のスループットが向上します。
Fast feedback（高速なフィードバック）
新人エンジニアからよく聞かれる質問があります。「なぜテストを書くのに時間をかけるのですか？」
この質問に対する答えは、体験してもらうのが一番です。テストなしで開発したコードと、包括的なテストを書いたコードで、1ヶ月後にそれぞれ機能追加を試みると、その差は歴然とします。テストがあるコードは安心して変更でき、リファクタリングも容易です。一方、テストがないコードは、変更するたびに他の部分への影響を恐れ、開発速度が数分の一に低下します。
私が身をもって学んだのは、金曜日の夕方の「ちょっとした修正」でした。テストなしでデプロイした結果、土曜日の朝に本番環境が停止。原因調査と修正に週末を丸々費やしました。それ以来、テストの重要性を信じて疑いません。
これがFast feedbackの真価です。DORAモデルでは、継続的インテグレーション、監視と可観測性、レジリエンス・エンジニアリング、浸透的セキュリティ、テスト自動化、テストデータ管理という6つの要素でFast feedbackを構成しています。これらは全て、学習サイクルを短縮し、問題の早期発見と迅速な修正を可能にするための仕組みです。
この劇的な変化がもたらす効果は印象的です。開発者の自信が向上し、変更の影響を即座に確認できるため、大胆な改善を試みることができるようになります。技術的負債の予防も可能になり、問題が蓄積する前に対処できます。品質の向上も実現し、バグの早期発見により、高品質なソフトウェアを維持できるようになります。そして最も重要なのは、学習の促進です。失敗から素早く学び、改善を続けることができるようになります。
重要なのは、Fast feedbackとFast flowが相互に作用し合うことです。迅速なフィードバックがあってこそ、安全に高頻度でデプロイできるようになります。
Performance（パフォーマンス）
ここまでは組織の「能力」について見てきました。でも、能力があっても成果が出なければ意味がないですよね。DORAモデルでは、CapabilitiesがどのようにPerformanceに変換されるかを明確に示しています。
Software delivery（ソフトウェアデリバリー）
「今回のリリース、バグ報告がほとんどないね」
この言葉を聞いたとき、複雑な気持ちになることがあります。確かにバグは少ないけれど、そのコードは将来変更しやすいのか？新しい機能を追加するときに足枷になったりしないのか？
Software deliveryは、Four Key Metricsで測定されます。変更リードタイム、デプロイメント頻度、変更失敗率、失敗したデプロイメントの復旧時間。これらの数値は確かに重要です。でも、数値の改善が必ずしも価値の向上につながらないことも、私たちは経験的に知っています。
デプロイ頻度を上げることに集中したチームの話をしましょう。毎日デプロイできるようになった。素晴らしい！でも実際には小さなバグ修正ばかりで、ユーザーにとって意味のある機能追加はほとんどなかった。数値は改善したけれど、本質的な価値の提供は向上していなかったんです。
レガシーシステムのメンテナンスプロジェクトでよくある話ですが、開発当初はFour Key Metricsの数値が良好でも、5年後には「誰も触りたがらないシステム」になってしまう。当時は「動く」ことが最優先で、「読みやすい」「変更しやすい」という品質が軽視されていたからです。
Reliability（信頼性）
「システムが安定しているから、新しい機能開発に集中できる」
これ、当たり前のように聞こえますが、実はものすごく贅沢なことなんです。多くのチームは、日々の火消しに追われて、本来やりたい開発に時間を割けないでいます。
DORAモデルでは、ReliabilityをSLO（Service Level Objectives）で測定します。測定範囲、測定焦点、目標最適化、目標遵守という4つの観点から評価するんですが、正直、最初は「なんでこんなに細かく分けるの？」と思いました。
でも実際にSLOを導入してみると、その価値がわかります。以前は「なんとなく調子が悪い」という感覚的な判断でシステムを運用していたのが、「ユーザーのログイン成功率が95%を下回った」という具体的な基準で問題を判断できるようになる。これは大きな違いです。
ただし、SLOの罠もあります。99.99%の可用性を目標にすると、開発チームが過度に保守的になってしまう。新機能のリリースを恐れるようになり、イノベーションが阻害される。一方、SLOが緩すぎると、ユーザー体験の悪化に気づくのが遅れてしまう。このバランスを見つけるのが本当に難しい。
Outcomes（結果）
ここまで能力（Capabilities）とパフォーマンス（Performance）について見てきましたが、結局のところ、経営層が知りたいのは「で、売上は上がるの？」「チームは幸せに働けているの？」という2つの質問への答えなんですよね。
Organizational performance（組織パフォーマンス）
「新機能のおかげで、売上が20%向上しました！」
経営層の目がキラッと光る瞬間です。でも、ちょっと待って。その売上向上、本当に開発チームの成果だけでしょうか？
DORAモデルが面白いのは、Organizational performanceを商業的な成果（売上、利益、市場シェアなど）と非商業的な成果（社会的価値、顧客満足度、ブランド価値など）の両方で評価することです。これ、すごく現実的だと思いません？
B2Bプロダクトの開発でよくある話なんですが、開発チームが6ヶ月かけて技術的に優れた機能を実装した。Four Key Metricsの数値も改善した。でも、リリース後の売上への影響は...微々たるもの。なぜか？営業チームがその機能の価値を理解していなかったり、競合他社が同時期に似たような機能をリリースしていたりするからです。私も経験があります。渾身の機能が営業に理解されず、埋もれていく悲しさ。
逆のパターンもあります。技術的には単純な機能が、営業チームの強力なプッシュと市場のタイミングが合致して、予想外の売上向上をもたらす。開発チームとしては「え、あれが？」という感じですが、これも現実です。CSVエクスポートボタンを追加しただけで大絶賛されたときは、正直複雑な気持ちでした。
個人的に好きな事例は、カスタマーサポートツールの改善です。技術的には地味な作業でしたが、サポートチームの応答時間が半分になり、顧客満足度が15ポイント上昇。これが口コミで広がり、新規顧客の獲得につながった。地味だけど、確実に価値を生み出す仕事ってありますよね。
Well-being（幸福度）
最後に、おそらく最も重要な指標について話しましょう。
「最近、チームメンバーの表情が明るくなったね」—これ、数値化できますか？できないですよね。でも、これこそが最も重要な成果の指標かもしれません。
DORAモデルがWell-beingを重要なOutcomeとして位置づけているのは、本当に画期的だと思います。仕事の満足度、生産性の実感、バーンアウトの減少、リワークの減少。これらを真面目に測定し、他の成果と同等に扱う。
技術的負債の解消プロジェクトの話をしましょう。短期的には売上に全く貢献しない。でも、開発チームの満足度が上昇した結果、新機能の開発速度が2倍に改善され、チームメンバーの離職率が下がり、新しい人材の獲得も容易になった。これ、立派な「成果」じゃないですか？
「前は毎日、レガシーコードと格闘するのが苦痛でした。でも今は、新しい機能を作るのが楽しくて仕方がありません」
こんな声が聞こえてくるようになったら、それは真の生産性向上の証拠です。数値では測れない、でも確実に存在する価値。それがWell-beingなんです。
項目間の相互作用：システム思考の重要性
ここまで7つの項目を個別に見てきましたが、実はこれらを別々に考えること自体が罠なんです。
DORAモデルの本当の価値は、Capabilities → Performance → Outcomesという流れを示したことにあります。これ、当たり前のように見えて、実はすごく重要な洞察なんですよ。
考えてみてください。Climate for learningが向上すると何が起きるか？チームメンバーが新しいことに挑戦しやすくなり、Fast flowとFast feedbackの改善アイデアがどんどん出てくる。その結果、Software deliveryとReliabilityが向上し、最終的にOrganizational performanceとWell-beingの改善につながる。全部つながっているんです。
最新のDORA研究で「Reduced rework（リワークの減少）」が重要なOutcomeとして追加されたのも興味深いですね。要するに、「二度手間を減らす」ということ。品質向上が長期的にはすべての項目の生産性を向上させる、という当たり前だけど見落としがちな事実を改めて示しています。
多くの組織で起きる失敗は、この相互作用を理解せずに、単一の項目だけを最適化しようとすることです。「とりあえずデプロイ頻度を上げよう！」とか言って、他の項目への影響を考えない。結果として、局所最適化の罠にはまってしまうんです。
本当の生産性向上は、これら7つの項目を統合的に理解し、バランスよく改善していくことでしか達成できません。簡単じゃないですよ。でも、だからこそやりがいがあるんじゃないでしょうか。
SPACE framework：包括的な測定手法
DORAのFour Keysだけじゃ物足りないと思った人たちがいました。Microsoftの研究者Nicole Forsgren（DORAの研究者でもある）、GitHub、そしてVictoria大学の研究者たちです。彼らが開発したSPACE frameworkは、開発生産性を5つの次元で測定しようという野心的な試みです。
名前の由来は各次元の頭文字なんですが、これがなかなか覚えやすい。
Satisfaction and Well-being（満足度と幸福度）って、要するに開発者が仕事を楽しんでいるかどうか。チーム、ツール、文化にどれだけ満足しているか。満足度が高いチームは生産性も高い傾向があるって、まあ当たり前といえば当たり前ですが、それを真面目に測定しようというのが新しい。
Performance（パフォーマンス）は、チームがどれだけ成果を出せているか。品質、顧客満足度、ビジネス価値の創出など。DORAのPerformanceより広い概念ですね。
Activity（活動）は、開発者が日々何をしているか。コーディング、テスト、デバッグ、会議、コードレビュー...でも重要なのは量じゃなくて質と価値。忙しそうに見えても価値を生んでいなければ意味がない。実際、「8時間コーディングしました」と報告してきたメンバーの成果物を見たら、ほとんど進捗がなかったことがあります。聞いてみたら、Stack Overflowを彷徨っていたとか。
Communication and Collaboration（コミュニケーションとコラボレーション）。これ、測定が難しいんですよね。でも、コードレビューの質とか、知識共有の頻度とか、新人のオンボーディング時間とか、工夫すれば測れるものはある。
Efficiency and Flow（効率性とフロー）は、どれだけスムーズに仕事が進んでいるか。個人レベルでは集中時間の確保、チームレベルでは無駄な待ち時間の削減。これ、DevExのFlowとも関連していて面白い。
で、SPACE frameworkの最も重要な教訓は何か？これらの次元を単独で使うな、ということです。「Activity（活動量）だけ見て評価するなんて最悪だぞ」と研究者たちは警告しています。複数の次元を組み合わせることで、初めて生産性の全体像が見えてくるんです。
DevEx：最新の開発者体験フレームワーク
2023年、また新しいフレームワークが登場しました。今度は誰が作ったかって？なんと、DORA、SPACE、その他の研究フレームワークの創設者たちが集まって作ったんです。オールスターチームみたいなものですね。
DevEx（Developer Experience）は、名前の通り「開発者の体験」に焦点を当てています。でも、これまでのフレームワークと何が違うのか？それは「日常業務で遭遇する摩擦ポイント」に注目したことです。
3つの核心次元がシンプルで分かりやすい：
Flow（フロー）—これ、心理学者のチクセントミハイが提唱した「フロー状態」から来ています。没頭して時間を忘れるあの感覚。でも現実は？会議、Slack通知、「ちょっといい？」の声かけ。集中なんてできやしない。DevExは、この中断の頻度や種類、深い集中状態に入れる能力を測定します。
実際に測定してみたら、1日で本当に集中できた時間は平均2時間しかありませんでした。残りは会議、Slack対応、「緊急」の割り込み...これじゃ生産性上がるわけない。
Feedback（フィードバック）—コードを書いて、結果がわかるまでどれくらいかかるか。ビルドに20分、テストに30分、レビューに3日...これじゃ学習サイクルが回らない。DevExは、この待ち時間をどれだけ短縮できるかに注目します。
Cognitive Load（認知負荷）—これが個人的には一番重要だと思います。複雑なシステム、分散したドキュメント、謎の暗黙知...頭がパンクしそうになりますよね。DevExは、開発者が作業を完了するために必要な精神的努力を測定します。
あるレガシープロジェクトでは、新機能追加の見積もりが2週間だったのに、実際は2ヶ月かかりました。原因？ドキュメントがない、コメントもない、設計思想は「歴史的経緯」。認知負荷が高すぎたんです。
面白いのは、Gartnerの調査で78%の組織が正式なDevExイニシアチブを確立または計画しているということ。みんな開発者体験の重要性に気づき始めているんです。
そして驚くべきは、2020年のMcKinseyの研究結果。より良い開発者環境を持つ企業は、競合他社の4〜5倍の収益成長を達成したそうです。4〜5倍ですよ？これ、もはや「あったらいいな」じゃなくて、競争力の源泉なんです。
測定の隠れたコスト
「測定は無料だから、とりあえずやってみよう」
これ、大きな間違いです。測定には必ずコストがかかります。そして、そのコストは思っているより高い。
データを集めるための時間、分析するための時間、会議で議論する時間、ツールの導入と維持にかかるコスト、そして何より、本来の開発作業から奪われる時間。
開発生産性を測定するために、エンジニアが1日30分をデータ入力に費やすケースを考えてみましょう。5人のチームなら、週に12.5時間。月に50時間。年間で600時間も本来の開発から奪われることになります。
600時間あったら、中規模の機能を2つは作れますよね？
その測定から得られた洞察は、正直に言って、その600時間に見合うものであることは稀です。「デプロイ頻度が先月より10%上がりました」という報告のために600時間を使う価値があるでしょうか？
なぜ経営層は測定を求めるのか
経営層が開発生産性の測定を求めるのには、理由があります。
「エンジニアチームに多額の投資をしているのに、その効果が見えない」 「開発が遅いと感じるけれど、それが妥当なのかわからない」 「他社と比較して、うちのチームはどうなのか知りたい」
こうした不安、すごくよくわかります。経営層も人間ですから、見えないものは不安なんです。特に、エンジニアリングという「よくわからない」領域に大金を投じているわけですから。
ある経営者との対話で印象的だったのは、「年間1億円投資してるけど、何が生まれてるのかわからない」という率直な告白でした。確かに、エンジニアリングって外から見たらブラックボックスですよね。
でも、その解決策として測定を求めるのは、多くの場合、適切ではありません。
本当に必要なのは、開発プロセスの可視化と、エンジニアチームとのコミュニケーション改善です。測定は、その手段の一つでしかありません。そして、多くの場合、測定よりも対話の方が効果的だったりするんです。
私が実践して効果があったのは、月1回の「技術説明会」でした。経営層向けに、今月の成果を「普通の言葉で」説明する。「データベースを最適化しました」じゃなくて「お客様の画面表示が3秒から1秒になりました」というように。すると理解が深まり、不安も解消されていきました。
Four Keysの光と影
Four Keysは確かに優れた指標です。DORAの長年の研究に基づいており、多くの組織で実際に改善の指針として機能しています。
でも、Four Keysには限界があるんですよ。
例えば、Sansan社のモバイルアプリ開発チームの事例。彼らはFour Keysからベロシティを含む別の指標に変更しました。なぜか？モバイルアプリでは過度にリリース頻度を増やすとユーザ体験を損ねる場合があり、Four Keysの前提と合わなかったからです。
これ、すごく重要な気づきですよね。Four Keysって、Webサービスの継続的デプロイを前提にしている部分があるんです。でも、すべてのソフトウェアがそうじゃない。
他にも限界はあります。デリバリーの効率は測れても、何をデリバリーするかの適切さは測れません。チームの健全性は示唆できても、個人の成長やモチベーションは見えません。開発プロセスの改善は追跡できても、顧客価値の創出は直接的には測れません。
Four Keysを「結果指標」として理解することが重要です。数値を上げることが目的ではなく、数値の背後にある組織の能力（Capability）を改善することが目的なのです。
2018年に発売された『LeanとDevOpsの科学』には、実はこのことがちゃんと書いてあるんです。もっとみんな、内容を読めばいいのにって思っています。
こちらの資料もめちゃくちゃに良いので読んでみてほしいです。『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。Forsgrenらが発見した、DevOps組織のパフォーマンスを上げるために必要な24（現在は27）のケイパビリティには、継続的デリバリは当然のこと、組織文化やリーダーシップ、リーンといったものも含まれています。
変革型リーダーシップの重要性
開発生産性の向上って、結局のところ技術的な問題じゃないんです。人の問題なんです。
英国工学技術学会の調査結果を見て驚きました。リーダーシップスキルを持つエンジニアは、チームの生産性を30%向上させることができるそうです。30%ですよ？どんなツールを導入するよりも効果的じゃないですか。
特に効果的なのが変革型リーダーシップ（Transformational Leadership）です。難しそうな名前ですが、要はチームメンバーの内発的動機を高め、組織のビジョンに向けて一緒に頑張ろうと導くリーダーシップスタイルのことです。
でも、多くの技術者にとって、リーダーシップは自然に身につくものではありません。コードは書けても、人を導くのは苦手。そんな人が多いんじゃないでしょうか。私もそうでした。
そこで注目されているのがスタッフエンジニアという役割です。組織横断的な技術的課題に取り組み、他のエンジニアの技術的判断をガイドする。直接的な部下を持たずとも、影響力とリーダーシップが求められる役割です。
スタッフエンジニアのリーダーシップは、従来のマネジメント型とは違います。権限じゃなくて専門性に基づく影響力。階層的な指示じゃなくて技術的な説得力。個人のパフォーマンス管理じゃなくてチーム全体の技術的能力向上。
これって、変革型リーダーシップの理論とぴったり合うんです。理想化された影響、鼓舞的動機、知的刺激、個別的配慮という4つの要素。これらを理解し実践することが、開発生産性の向上には不可欠なんです。
変革型リーダーシップの4つの要素
変革型リーダーシップは4つの要素から構成されているんですが、これが結構難しい。理論は美しいけど、実践となると...
理想化された影響（Idealized Influence）
リーダーがロールモデルとして機能し、チームメンバーから尊敬と称賛を得る。言うは易く行うは難し。技術的な専門性を維持しながら、チームの成功を優先する。言うのは簡単ですが、実際にやってみると矛盾だらけです。
完璧である必要はないということが重要です。むしろ、自分の失敗を率直に認め、そこから学ぶ姿勢を見せることの方が大切です。設計したアーキテクチャに重大な欠陥があることが発覚した時、言い訳をするのではなく、チーム全体の前で設計判断の誤りを認め、なぜそう判断したのか、どうすれば防げたのかを一緒に考えることで、チーム全体の雰囲気が変わります。メンバーも自分の失敗を隠さなくなり、互いに助け合うようになるのです。
私が設計したマイクロサービスアーキテクチャが複雑すぎて誰もメンテできなくなった時、素直に「ごめん、設計ミスだった」と認めました。すると、他のメンバーも「実は自分も...」と失敗を共有し始め、チーム全体がオープンになりました。
技術的な信頼性を保つことも重要ですが、それ以上に倫理的な行動を示すことが大切です。困難な状況でも一貫した価値観を示し、透明性のある意思決定を行う。コードレビューでは建設的なフィードバックを提供し、自らも率先してレビューを受ける。これらの小さな行動の積み重ねが、信頼関係を築いていくのです。
鼓舞的動機（Inspirational Motivation）
魅力的なビジョンを設定し、目的意識を創造する能力は相反する能力ではありません。エンジニアは概して現実的で、抽象的なビジョンには懐疑的です。だから工夫が必要なんです。
効果的なのは、技術的なビジョンを具体的なユーザー体験と結びつけることです。スプリント開始時に、実装する機能がユーザーにどのような価値を提供するかを具体的に説明する。技術的負債の解消を「将来の自分たちへの投資」として位置づける。新しい技術の導入を「チームの競争力向上」として意味づける。
レガシーコードのリファクタリングを進める際、チームメンバーから「この作業に意味があるのか？」という質問を受けることがあります。そんな時は、6ヶ月後にその部分に新機能を追加することになった時のことを具体的に想像してもらいます。現在のコードのままだと、開発に2週間かかり、バグの発生率も高くなる。しかし、今リファクタリングすれば、その作業が3日で完了し、品質も向上する。
このように、抽象的なビジョンを具体的な体験に変換することで、チームの目的意識を創造することができるのです。
知的刺激（Intellectual Stimulation）
「従来の方法に挑戦し、新しい視点とアプローチを奨励する」
これは技術者にとって最も自然な要素かもしれません。でも、実際には思っているより難しい。なぜなら、自分の知識や経験が邪魔をするからです。
重要なのは、答えを教えるのではなく、考えを促す質問を投げかけることです。アーキテクチャ設計時に「他にどのような方法があるか？」と問いかけたり、チームメンバーが新しいフレームワークを提案した際は批判ではなく検証を支援したり、定期的に「なぜこの方法を選択したのか？」を振り返る時間を設けることが効果的です。
新人エンジニアが既存のアプローチとは全く異なる解決策を提案した時、「それは複雑すぎる」と却下するのではなく、「面白いアイデアですね。どのようなメリットがあると思いますか？」と質問することで、見落としていた重要な利点が発見されることがあります。
失敗を学習機会として扱うことも重要です。エラーが発生した時、誰が悪いかを追求するのではなく、なぜそのエラーが発生したのか、どうすれば再発を防げるのかを一緒に考える。これにより、チーム全体の学習能力が向上します。
個別的配慮（Individualized Consideration）
「各チームメンバーの個人的なニーズと能力に注意を払う」
これが最も時間がかかり、最も重要な要素です。なぜなら、人は一人一人違うから。
定期的な1on1を実施し、各メンバーの目標に応じた学習機会を提供することが基本となります。各メンバーの強みを理解して各人の能力に最も合致した役割を割り当て、メンバーの性格や学習スタイルに合わせてフィードバックを調整することが重要です。
例えば、内向的で技術的には優秀だが会議では発言しないエンジニアがいる場合、「もっと積極的に発言してください」と言うだけでは効果がありません。1on1で話してみると、口頭でのコミュニケーションが苦手だが、文書でのコミュニケーションは得意だということがわかることがあります。そのような場合は、事前に意見を文書で整理してもらい、会議ではその内容を代弁する形にする。また、複雑な技術的な判断が必要な場合は、文書で分析してもらうなど、個々の特性に合わせたアプローチが効果的です。
変革型リーダーシップの落とし穴
ただし、変革型リーダーシップにも限界があります。最新の研究では、変革型リーダーシップには「収穫逓減の法則」が適用され、過度なリーダーシップは逆効果になる可能性があることが示されています。
組織がリーダー個人に過度に依存してしまうと、組織の脆弱性が高まります。カリスマ的なリーダーが常に高いエネルギーを維持し続けることは持続可能ではなく、強力なビジョンが異なる意見や多様な視点を排除してしまうリスクもあります。
特に注意が必要なのは、短期的な成果の軽視です。長期的なビジョンに集中しすぎると、短期的な成果や日々の小さな勝利を見落としがちになります。チームメンバーは理想的な未来への道筋だけでなく、現在の進歩を実感できる具体的な成果も必要としています。
測定の難しさと現実的なアプローチ
変革型リーダーシップの効果を測定するのは困難です。チームの離職率、技術的負債の減少速度、新機能の開発速度など、定量的な指標はある程度の示唆を与えますが、それだけでは全体像は見えません。
360度フィードバックでのリーダーシップ評価もよく使われますが、これには重大な問題があります。匿名性があるとはいえ、多くの場合、評価者は無意識に「政治的に正しい」回答をしてしまいます。特に日本の組織文化では、率直なフィードバックを避ける傾向が強く、結果として「みんな平均的に良い」という無意味なデータが集まることが多いのです。また、360度評価は実施に多大な時間とコストがかかる割に、具体的な改善アクションにつながりにくいという本質的な欠陥もあります。
チームメンバーの満足度調査、技術的な意思決定への参加度なども重要な指標ですが、これらの定性的な指標は解釈が複雑で、文脈に大きく依存します。
効果的な測定指標として注目されているのは、チームメンバーが自発的に新しいアイデアを提案する頻度です。これは心理的安全性が確保され、知的刺激が機能していることを示す重要なサインと考えられています。また、クロスファンクショナルなコラボレーションの増加や、チーム内での知識共有の活発化も、変革型リーダーシップの効果を示す指標となります。
DevOps文化との融合
変革型リーダーシップとDevOps文化って、実は相性抜群なんです。
どちらも継続的な学習と改善を重視し、実験と失敗からの学習を奨励し、協調とコラボレーションを促進し、顧客価値の最大化を目指す。価値観がぴったり一致しているんです。
具体的にどう実践するか？レトロスペクティブで建設的な振り返りをする。技術的な実験を恐れない文化を作る。部門の壁を越えたコラボレーションを推進する。顧客フィードバックを開発プロセスに組み込む。
これらは全部、変革型リーダーシップの4つの要素を日常的に発揮するための基盤になります。リーダーシップとDevOps、別々に考える必要はないんです。一体として実践すればいい。
変革型リーダーシップは単なる管理手法じゃありません。技術組織の文化と価値観を形成する重要な要素です。適切に実装できれば、開発生産性の向上だけじゃなく、チームメンバーの満足度と継続的な成長にも大きく貢献します。
ただし、これは一朝一夕で身につくものじゃありません。組織全体での継続的な学習と実践が必要です。でも、その価値は十分にあると思いませんか？
現場の声を聞く重要性
現場にとって最も効果的な測定システムは、現場の人間が適切に設計したものです。
机上で考えた理想的な指標よりも、実際に開発をしているエンジニアの経験と判断の方が、多くの場合、より正確な情報を提供します。
「あのエンジニアは本当に頼りになる」 「この機能は使いやすくて、お客さんからの評判がいい」 「最近、デプロイが安定していて、安心して作業できる」
こんな声が聞こえてきたら、それは本当の生産性向上の証拠です。数値では捉えられない、でも確実に存在する価値。それを見逃してはいけません。
代替的なアプローチ
標準化された測定だけが、情報収集の方法ではありません。
DORAの最新研究や『LeanとDevOpsの科学』でも強調されているのは、定量的な指標と定性的な情報の組み合わせの重要性です。
顧客からの直接的なフィードバック、チーム内での振り返り、個人との1on1での会話、実際のプロダクト使用体験...これらは数値化しにくいけれど、めちゃくちゃ価値が高い。
特に重要なのは、実際にプロダクトを使っているユーザーの生の声です。
「この機能があって助かった」 「バグが少なくて使いやすい」 「新しい機能がすぐに追加されて嬉しい」
こんなフィードバックは、どんな精密な測定指標よりも、本当の生産性と価値創出を示しています。
私が経験した最も効果的な方法は、エンジニア全員でカスタマーサポートの電話を聞くことでした。「この機能、使いにくい」「ここがわからない」という生の声を聞くと、自然と「もっといいものを作ろう」という気持ちになります。
DORAの最新モデルでは、こうした多角的なアプローチが体系化されています。定量的なFour Key Metrics、定性的な組織文化評価、そして顧客価値に関する直接的なフィードバック。これらを組み合わせることで、より包括的な生産性評価が可能になるんです。
スクラム研究でも同じような結論に達しています。チームの効果性を評価するには、定量的な指標だけじゃなく、7年間の研究で明らかになった5つのKey Factorを元にした包括的な評価が重要だということです。
測定の限界を受け入れる
最終的に、測定には限界があることを受け入れる必要があります。
すべての問題が解決可能なわけではなく、測定で改善できる問題はさらに限定的です。「測定できないものは管理できない」という考え方は間違いです。むしろ、測定できない要素こそが、組織の成功にとって決定的に重要な場合が多いのです。
透明性の向上は問題を可視化しますが、それ自体は解決策ではありません。複雑な問題は単純な数値では表現できず、熟練した専門家の判断力と解釈力が不可欠です。
そして何より、測定に振り回されて、本来の目的を見失ってはいけません。私たちの目的は、数値を改善することではなく、より良いソフトウェアを作り、ユーザーに価値を届けることなのですから。
測定の落とし穴を避けるための現実的なアプローチ
ここまで問題点ばかり指摘してきましたが、じゃあどうすればいいのか？実践的な提言をまとめてみました。
1. 心理的安全性の確立を最優先に
Google Project Aristotleの研究結果は衝撃的でした。チーム成功の最重要要素は、優秀な人材でも、厳密に設計されたプロセスでもなく、「心理的安全性」だったんです。
でも、どうやって心理的安全性を作るのか？Amy Edmondsonの診断アンケートを使って現状把握から始めるのがおすすめです。特に「失敗について話し合うことができる」という項目のスコアが低い場合は要注意。
リーダーが率先して自分の失敗を開示することも効果的です。設計判断の誤り、顧客要件の理解不足、見積もりの甘さ...これらを隠さず共有し、そこから何を学んだかを明確に示す。すると不思議なことに、チーム全体が失敗を隠さなくなるんです。
1on1も重要です。表面上は問題なく見えても、内心では不安を抱えているメンバーは多い。定期的に個別で話を聞き、本音を引き出す。これには時間がかかりますが、投資する価値は十分にあります。
そして、失敗を非難しない文化を明文化すること。「学習のための失敗」は奨励し、「不注意による失敗」は改善のためのサポートを提供する。この区別を明確にすることで、チームメンバーは安心して挑戦できるようになります。
2. 多次元的な測定アプローチの段階的導入
SPACE frameworkやDevExを見て「これ全部測定するの？」と思った方、正解です。いきなり全部やろうとすると測定疲れで倒れます。
だから段階的にやりましょう。まずは月1回の簡単な満足度調査（5分程度）から。「今月の仕事、楽しかったですか？」くらいのシンプルな質問で十分です。慣れてきたら四半期ごとにSPACE評価を実施し、半年ごとにDevExの深掘りインタビューを行う。
面白い発見もあります。満足度と認知負荷には強い負の相関があるんです。つまり、頭がパンクしそうな状態では、仕事を楽しめない。当たり前といえば当たり前ですが、データで示されると説得力が違います。
測定の品質を確保するためには、匿名性の保証が不可欠です。「正直に答えてもらえなければ、測定する意味がない」ということを、経営層にも理解してもらう必要があります。
そして最重要ポイント：測定結果を必ず改善アクションに繋げること。データを集めるだけで終わったら、次回から誰も協力してくれなくなります。
3. 開発者の主観的体験の重視
DevEx研究の最大の貢献は、「開発者の主観的体験が生産性に大きく影響する」ことを明確にしたことです。
フロー状態の測定では、中断頻度の記録が鍵になります。技術的な中断（ビルドエラー、テスト失敗）より、人的な中断（会議、Slack、「ちょっといい？」）の方が影響が大きいんです。これ、実感としてもわかりますよね。
認知負荷の評価も重要です。新しいコードベースの理解困難度、ツールの複雑さ、意思決定に必要な情報の入手困難度...これらを定期的に評価することで、本当のボトルネックが見えてきます。
実践的な収集方法として効果的なのは、デイリースタンドアップで「昨日一番ストレスを感じたのは何？」を共有すること。最初は戸惑うかもしれませんが、慣れると貴重な情報源になります。
4. バーンアウト予防の測定戦略への組み込み
83%の開発者がバーンアウトを経験している現状を踏まえ、測定によるストレス増大を避ける必要があります。
早期発見システムの構築では、Maslach Burnout Inventory（MBI）の定期実施、勤務時間外の連絡頻度監視、休暇取得パターンの分析、パフォーマンスの突然の変化検出などが重要です。特に、普段高いパフォーマンスを示していたメンバーの生産性が突然低下した場合は、バーンアウトの兆候である可能性が高いため、早期の介入が必要です。
予防的介入としては、持続可能な開発ペースの維持が最も重要です。十分な休息とリフレッシュの機会を提供し、技術的な成長機会を定期的に提供することで、内発的動機を維持できます。短期的な成果を追求するあまり、長期的な持続可能性を損なわないよう注意が必要です。
5. 変革型リーダーシップの体系的育成
技術的な改善だけでなく、リーダーシップスキルを持つエンジニアの育成が重要です。
リーダーシップの育成は、メンバーの成長段階に応じて異なるアプローチが必要です。初級レベルでは、まず1on1スキルと効果的なフィードバック方法の習得から始めます。これらは日々のコミュニケーションの基礎となる重要なスキルです。中級レベルに進むと、組織間協調と戦略的思考の能力開発に焦点を移します。単一チームの枠を超えて、より広い視野で物事を考える力を養うのです。そして上級レベルでは、ビジョンの策定と組織文化の変革という、より高次元のリーダーシップスキルの習得を目指します。
実践的な育成方法として、まずメンターシップ制度の導入が効果的です。経験豊富なリーダーから直接学ぶ機会を提供することで、理論だけでなく実践的な知恵も伝承できます。リーダーシップ研修の実施も重要ですが、座学だけでなく実際の場面を想定したロールプレイングなどを組み込むことで、より実践的な学習が可能になります。360度フィードバックも活用できますが、先述したようにその限界を理解した上で、あくまで補助的なツールとして使うべきです。最も重要なのは、理論と実践を組み合わせた学習アプローチです。学んだことをすぐに現場で試し、その結果を振り返ることで、真のリーダーシップスキルが身についていくのです。
6. 組織文化への戦略的投資
測定は手段であり、目的ではありません。持続的な生産性向上には組織文化の醸成が不可欠です。
文化醸成は段階的に進める必要があります。まず現状把握として、組織文化診断を実施し、Westrum文化モデルで現状を評価して文化的な問題点を特定します。次に意識変革の段階では、文化変革の必要性を共有し、変革ビジョンを策定します。最も困難な行動変容の段階では、新しい行動パターンを実践し、成功事例を共有していきます。
具体的な施策として、失敗を学習に変えるプロセスの構築、実験を奨励する制度の導入、部門横断的なコラボレーションの推進、顧客価値創出への集中などが重要です。これらの施策を通じて、組織文化を徐々に変革していくことができます。
7. 測定疲れを防ぐ持続可能な仕組み
測定自体が負担になってしまっては本末転倒です。
最小限の負担で最大の効果を得るためには、自動化可能な指標を優先し、既存ツールからのデータ収集を活用し、短時間で完了する調査を設計し、重複する測定を排除することが重要です。
明確な価値の提示も欠かせません。測定結果の活用方法を明示し、改善につながる実例を共有し、測定コストと得られる価値を比較し、無駄な測定を定期的に見直すことで、チームメンバーの理解と協力を得ることができます。
参加型の設計により、開発者自身が測定項目を提案し、測定結果の解釈に参加し、改善アクションを共同で立案し、測定システムを継続的に改善していくことで、測定への抵抗感を3分の1程度に減らすことができます。
これらの提言を実装することで、測定の落とし穴を避けながら、真の開発生産性向上を実現できます。重要なのは、一度にすべてを実装しようとするのではなく、組織の成熟度に合わせて段階的に取り組むことです。そして、常に人間を中心に据え、測定が目的ではなく手段であることを忘れないことです。
ちゃんとした生産性向上への道
では、どうすればいいのでしょうか？
測定を諦める必要はありません。でも、測定を万能薬だと考えるのは危険です。
重要なのは、測定を改善の手段として位置づけることです。数値の背後にある人間の活動と組織の能力に焦点を当て、測定されない価値を見過ごさないことです。
Four Keysのような指標は、組織の健全性を示すバイタルサインのようなものです。熱があるのは病気のサインかもしれませんが、熱を下げることが治療ではありません。根本的な原因を理解し、原因に基づいた対処をすることが重要なのです。
実際、DORAの最新の研究プログラムでは、Four Keysだけでなく、より包括的な行動科学的手法を用いて、働き方、ソフトウェア配信パフォーマンス、組織目標、個人の幸福度を結ぶ予測経路を解明しています。この統合的なアプローチが、実質的な生産性向上への道なんです。
さいごに
飲み会帰りの散文、失礼しました。開発生産性は、簡単には測れません。測れたとしても、その数値が全てを語ってくれるわけではありません。
でも、だからこそ面白いんです。
人間の創造性、チームの協力、技術の進歩、顧客の満足。これらすべてが絡み合って、本当の生産性が生まれます。単純な数式では表せない、複雑で美しいシステムです。
測定は重要ですが、測定されない価値を忘れてはいけません。数値の向上は手段であって、目的ではありません。真の目的は、より良いソフトウェアを、より効率的に、より楽しく作ることです。
エンジニアリングって、本来楽しいものですよね？新しいものを作り出す喜び、難しい問題を解決する達成感、チームで何かを成し遂げる充実感。これらを犠牲にしてまで、数値を追いかける価値があるでしょうか？
開発生産性の測定に万能な答えはありません。でも、その限界を理解し、謙虚に取り組むことで、より良いチーム、より良いプロダクト、より良い組織を作ることができるはずです。
この記事が、開発生産性の測定に取り組む皆さんの一助となれば幸いです。測定の落とし穴を避け、本当に価値のある改善に向けて、一緒に歩みを進めていきましょう。
そして最後に一つ。もし「この数値が良くなったら、僕たちは本当に幸せになれるんですか？」と聞かれたら、あなたはどう答えますか？
私なら、こう答えます。「数値は幸せを保証しない。でも、みんなで一緒に改善していく過程は、きっと価値があるはずだよ」って。
