開発生産性を最大化するために考えていること ~あるいは技術的負債について

はじめに

要約

• 開発生産性を事業価値へと繋げるまでにいくつもロスが発生する。ロスを分類してどのようなアクションを行うべきかを整理する。
• 技術的負債はメタファーとして誕生したが、現代ではコードや設計、開発プロセスの不備を指す言葉としても使われている。技術的負債の教訓は負債は避けられず、放置していると指数関数的に増える場合があることと、メタファーが生まれて定着するくらいには技術的なロスの説明が難しいこと。
• 開発生産性を高めるためには仕事量の生産性を増やすこととロスを減らすことの両面から取り組む。実験的な改善と投資の優先度付けおよびリソース配分の最適化が重要である。

著者紹介

ブルーモ証券株式会社 VPoE の下村です。

普段は Go で証券サービスのバックエンド開発をしたり、開発チームのマネジメントをしたりしながら、開発全体の生産性向上に取り組んでいます。

本ブログの背景

我々にとってサービスを早く顧客へ届けることは常に優先される価値基準であり、これはブルーモの場合 Values の一つ「光の速さ」で表されています。このデリバリー能力は開発生産性として表されます。

開発生産性は顧客価値につながる開発に集中すれば向上するという単純なものではありません。むしろ開発生産性自体の改善を定常的に実施していないと段階的に開発生産性は低下していきます。この低下を防ぐために必要な取り組みを決定および実行していくことはエンジニアリング組織の重要な責務です。

本ブログは開発生産性を高めるために考えている構造と変数を整理するために執筆しています。

本ブログの地図

本ブログエントリーは非常に長いです。読んでいるうちに迷子にならないように、章ごとに何を話しているかざっくりとまとめておきます。

• 「開発生産性のレベルとロス」では、まず開発生産性をどの段階の成果物や指標に着目するかでレベル分けの概念を紹介した後に、開発生産性のロスの概念を導入します。開発生産性のロスもいくつかに分類して、ロスごとに取るべきアクションを整理します。
• 「技術的負債というメタファーから得られる洞察」では、レベルやロスの話から一度離れて、技術的負債という言葉を深掘りします。技術的負債という言葉が生まれた経緯から現代の用法までおさらいした上で、開発生産性のロスとどのように戦っていけば良いのかのヒントを抽出します。
• 「開発生産性の高め方」は最後の章です。レベルとロスを用いて開発生産性を分解してから、要素に対しての取り組み方を技術的負債から得られた洞察を用いて検討しています。これまでの章は理論的な整理がメインでしたが、最後の章は抽象度は高いものの実践的な内容にまとめています。

それでは長いブログにはなりますがお付き合いいただけますと幸いです。

開発生産性のレベルとロス

開発生産性のレベル

事業の目標達成に向けて、価値を世に送り出す能力を生産性とした場合に、この生産性を測ることは至難の業です。Martin Fowler は計測不能であると 生産性は計測不能 にて主張しています。そのため、我々は生産する対象を最終的な事業目標の前段階の成果物に対しても適用することで、計測可能なレベルを扱うことが多いです。この考え方はエンジニアリング組織論への招待執筆者である広木さんのブログエントリー 開発生産性について議論する前に知っておきたいこと で広く知れ渡ったと思います。

他にも以下のブログなどは類似性のある視点で開発生産性を分解しています。

本ブログでは広木さんの定義に従った以下のレベルを用います。

1. 仕事量の生産性
2. 期待付加価値の生産性
3. 実現付加価値の生産性

開発生産性のロス

我々はすべての低レベルの生産性を高レベルの生産性へ繋げることはできません。例えば、仕事量の生産性はリファクタリングや内部向けの仕様書の作成にも使われており、必ずしも期待付加価値の生産性へと繋がるわけではないです。 このレベルアップ時に失われる生産性を 開発生産性のロス と本ブログでは定義します。

例えば、ロスには以下のようなものがあります。網羅的でも適切な粒度でもないのですが、イメージは伝わるかと思います。

• 仕事量の生産性 -> 期待付加価値の生産性へのロス
  • キャッチアップ: 仕様の理解、影響把握、技術のアップデート
  • トイル: 環境構築、ビルド時間、デプロイ時間
  • 手戻り
  • バグフィックス
  • リファクタリング / リアーキテクティング
• 期待付加価値の生産性 -> 実現付加価値の生産性へのロス
  • 仮説の棄却
  • 想定外の技術的制約

「厳密には生産を行っていない時間」も仕事量の生産性に含んでしまっているため、若干違和感はあります。能力x業務時間のようなレベルを仕事量の生産性の前においた方が言葉の上では正確かもしれません。ただ、能力x業務時間のレベルをおいて考えても、あまり整理が捗るわけでもなかったので少し違和感は残りますが、大抵の業務は仕事量の生産性に含めることとしています。

仕事量の生産性の内訳

ロスは必ずしも悪いものではありません。

リファクタリングなどの開発生産性を改善するための取り組みはロスに計上されるものの、リファクタリングをやめると改修箇所の特定や影響範囲の把握、その他トイルのロスが増大して破綻します。

では、バグフィックスはどうでしょうか？これはやらないに越したことはありません。

よって、仕事量の生産性の消費先はざっくり3つに分類すると良さそうなことがわかります。

本ブログでは仕事量の生産性のロスを2つに分類した上で、次のレベルに繋がる期待付加価値の生産を加えて仕事量の生産性を3つに分類します。

• 期待付加価値の生産: 期待付加価値を直接生産する仕事
• 投資: 将来的に開発生産性を高めるために必要なロス
• 無駄: 可能な限り削減すべきロス

投資はバランスよく扱って、無駄は極限まで減らすことが望ましいです。

期待付加価値の生産性の準備と検証

期待付加価値から実現付加価値へのロスは、仕事量の生産性のロスで分類した無駄 vs 投資とは異なり、準備不足と検証不足が存在するようなイメージです。正直この辺りはまだちゃんと整理をつけきれていません。

期待した成果がすべて実現するようなことは発生しません。そのため、期待はあくまで仮説であり、我々は仮説を持ってプロダクトを世に送り出して結果の検証を行って学びを得ます。このサイクルを続けることで徐々に仮説の精度を高めて行って、最終的には社会に受け入れられるプロダクトに磨き込まれていきます。よって、継続的な学習サイクルが機能している限りは無駄と呼べるロスはないと考えています。

一方で、仮説が十分に練られていなかったり、結果の検証が不十分である場合は、仮説検証サイクルが適切に回っていないため、ロスが次に繋がりません。このような開発プロセスは改善が必要です。準備不足、検証不足どちらに対してもエンジニアとしてできることはたくさんあるので、それらについてはこの後整理していきます。

ちなみに、期待付加価値から実現付加価値が得られないパターンとしてプロダクト品質が当たり前品質を下回った場合もあり得ます。例えば検索機能が受け入れられたかどうか検証したいけど、どうやら顧客的には検索速度が気に食わなかったらしく検索機能自体のニーズの確認ができなかった場合などを考えています。このような場合も検索速度についての学びは得られるものの、本質的な付加価値に対する学習サイクルは1巡遅れることになるため、好ましい状況とは言えません。

まとめ

• 開発生産性を仕事量の生産性、期待付加価値の生産性、実現付加価値の生産性の3つのレベルに分解する
• 上位のレベルに繋がらなかった生産性を開発生産性のロスと定義する
• 仕事量の生産性のロスは投資と無駄に分類できる
• 期待付加価値の生産性から実現付加価値の生産性へのロスは学習サイクルに取り込まないといけない

技術的負債というメタファーから得られる洞察

ここまでの話でいわゆる「技術的負債」を連想された読者の方は少なくないと思います。ロスとか当たり前品質とかまどろっこしい表現しているなと思われたかもしれません。実際にここまでの説明では技術的負債という言葉は誤解を招くと考えて避けて説明を行っています。

本章では「技術的負債」という言葉の歴史を振り返りつつ、言葉を発端とした議論や研究などから得られた洞察を整理していきます。技術的負債への探究結果を踏まえて、開発生産性の高め方へと議論を進めていきます。

技術的負債の経緯

まずは歴史の振り返りです。

Ward Cunningham による提唱

1992年に Ward Cunningham が OOPSLA で発表した The WyCash Portfolio Management System において、技術的負債という言葉が初めて提唱されました。(正確には「技術的負債」ではなく「負債」ですが)。

2009年に改めて Ward Cunningham が YouTube にて技術的負債の説明を行っています。これを t_wada 氏が邦訳したブログエントリー 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 が最もとっつきやすいオリジナルの意図に言及した資料かと思います。

t_wada 氏のブログに記載されているように、オリジナルの意図はアジャイルや DDD にて語られる継続的なリファクタリングの説明をビジネスサイドへ行う際に、コミュニケーションがスムーズになったメタファーの事例として提唱されたものだと捉えることができそうです。

Martin Fowler による拡張と分類

2009年に Martin Fowler は 技術的負債の四象限 というブログを執筆しており、この中で技術的負債の対象はメタファーが通用するなら使用すれば良いというように述べています。メタファーが通用するとは、メタファーを使用することで課題を捉えやすくなったり、他者との連携がしやすくなる状況のことです。また、技術的負債のメタファーを利用する際には以下の2軸で4象限に分類することを推奨しています。

• Reckless(無鉄砲な) / Prudent(慎重な)
• Deliberate(意図的な) / Inadvertent(不注意な)

また、 Martin Fowler は 技術的負債 のブログエントリーにて、技術的負債のメタファーで上手く表現できないケースについても述べています。Martin Fowler は解消しなければならない不備について「技術的負債」ではなく「クラフト」と言う言葉を使っています。

現在の使われ方と研究

上述の通り、オリジナルや Martin Fowler の説明では技術的負債のメタファーはコミュニケーションを円滑にするための手段として提唱されています。一方で Technical Debt Guide - What is technical debt? では、現代ではあらゆる不完全なコードが技術的負債として扱われていると述べています。このブログ内ではドキュメント不足なども技術的負債に数えられているため、コードという対象範囲すら超えることがあることもわかります。

つまり、現在では技術的負債はそれ自体が何かしらの定義を持った名称として使われているように思います。Wikipedia のニュアンスも同様に刹那的なコミュニケーションの潤滑剤ではなく、言葉が何かを指すものとして扱われています。使われ方が変わっていったことについて皮肉ってもらうように ChatGPT に依頼したら、足し算を教えるのにりんごの数を数えさせたら、りんごで数を扱うことについての議論が激化して「りんご資産管理学入門」が始まったようなものですね、という回答が返ってきました。上手いか...？

とはいえ、メタファーを先に進めてさらに開発を深掘りすることは有用だと感じています。例えば「バランスシート 技術的負債」などと調べるとファイナンスの知識を使うとソフトウェア開発がどのように例えられるかについて議論している記事がいくつも見つかります。これらの知見は開発プロセスを多角的に見つめ直す上で有用です。

また、ビジネスサイドとエンジニアリングサイド全体が技術的制約によって生じた顧客体験の損失などにも目を向ける機会を与えました。(こちらは BS 上はどちらかというと資産として数えられるため負債ではなく不良資産ではないかという議論もありますが、正直元々メタファーなのでそこまで厳密に誰も使っていない気もします)。

得られる洞察

この項では技術的負債のメタファーで先人たちが伝えたかったことを抽出していきます。

偶発的複雑性は避けられない

Martin Fowler による「慎重かつ不注意」な技術的負債の説明にもあるように、どれほど優れたエンジニアがしっかりと時間を作って開発を行っても偶発的複雑性は避けられないものです。ここでいう偶発的複雑性とは、ドメインそのものに内在する本質的な難しさではなく、設計や実装、開発プロセスの選択などによって後から生まれる余計な複雑さを指しています。エンジニアは開発と同時に学習しているため、学習途中のコードは不完全であることが常です。

Ward Cunningham が技術的負債のメタファーを最初に利用して伝えたかったのもこの点であると考えています。

偶発的複雑性は指数関数的に増える

偶発的複雑性は放置すれば指数関数的に増えると捉えられます。これは偶発的複雑性の上にも容赦無く追加改修は発生していき、さらなる複雑性が追加されていくためです。一方で、本当に追加改修が入ってくるのか？と言うのは一考の余地があります。

この場合、逆に何かしらの設計を行った際などに技術的負債であることが連想されたとすると、その設計における偶発的複雑性は許容できないと直感していると考えることもできます。改修頻度が少なく、正直この後の複雑性の上乗せがほとんどない箇所における偶発的複雑性は、そこまで技術的負債と思わないのではないでしょうか？

追加改修の頻度などを踏まえて複雑性をどう扱っていくかなどは ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 という書籍で美しく論理的にまとめられているのでおすすめです。

ロスの説明は難しい

コミュニケーションにおいてメタファーが有用であるという知見が共有されるくらいには、そもそも技術的な開発生産性のロスについて他職種へ伝えることは難しいということでしょう。

松岡さんのブログエントリー 「リファクタリングの時間」を確保する技術 などを参照していただくと技術者視点で何が起こっているかを伝えることの難易度がわかると思います。

はじめにお伝えした通りこの種のロスについて100%理解しているのは現場のエンジニアだけです。Why developers don't get given time to fix technical debt にわかりやすい図が用意されています。

このことからある種ぼんやりとしたイメージのまま、詳細の説明なしに効果とコストのみを説明して進めることが適切な場合もあると考えています。

個人の見解

個人的には「AI」などと同様で「技術的負債」はかなり意味がぼやけてしまったバズワードであると考えています。

現代のソフトウェア開発においてこの言葉は絶大な認知度を誇っているため、使わずにコミュニケーションを取ることは難しいです。そのため、会話の中で現れる「技術的負債」は実際に何を指しているのかを常に意識した方が良さそうです。

自分から不備の説明を行うときには、ビジネスサイドに対して明らかに説明難易度が高すぎる事象を除いて、不備自体の説明を行った上で、「いわゆる "技術的負債" ですね。」と締めくくるくらいが理想的だなと思っています。

...はい、理想的なだけで実際はめちゃくちゃ公然と使ってます。現実論としてこの類の偶発的複雑性やトイル全体を指す用語で広く認知されたちょうど良いものが見つからず、正直ミスコミュニケーションもそこまで発生していないのでまぁいっかと使わせていただいています。

まとめ

• 「技術的負債」はメタファーとして誕生したものの、現代ではコードや設計、開発プロセスの不備を指す言葉としても使われている
• 偶発的複雑性は避けられず、放置していると指数関数的に増える
• メタファーが生まれて定着するくらいには技術的なロスの説明は難しい

開発生産性の高め方

開発生産性の対象期間

我々が開発する多くのプロダクトの希望的な寿命は無限大です。それでは我々の開発生産性の計測期間も無限とするべきでしょうか？正直な話、エンジニアとしての私は気を抜くと無限に近い期間で認知負荷の影響度やトイルの影響度を考えてしまいます。しかしながら、実務上はある程度の長さで考察対象の期間を区切って考えるのが適切でしょう。

対象期間は四半期や年度の固定された期間だったり、あるプロジェクトの期間のように可変なものであっても良いでしょう。重要なのはあるロスの影響度合いを判断する際にどの期間の開発生産性を前提に考えているかを認識することです。

特に偶発的複雑性の影響度合いは対象期間によって大きく変わります。先に述べたように偶発的複雑性は指数関数的に増加するためです。

認知負荷によるインシデントの発生リスクなどは確率的です。対象期間が大きくなるごとにサイコロを降る回数が増えるので、発生回数の期待値も増えます。

弊社の場合は基本的に1年間を対象期間として考えているので、この後の検討も基本的に対象期間は1年間として考えています。

仕事量の生産性の増大

開発生産性を改善させるために最も直接的な方法は仕事量の生産性を高めることです。仕事量の生産性はざっくり言うと個々人のエンジニアの能力とエンジニア全体の業務時間として考えています。これらを伸ばすための施策を例示すると

• エンジニアの能力向上
  • 教育
  • 認知負荷の低減
  • AI ツール活用
• エンジニア全体の業務時間向上
  • 採用
  • 外注
  • エージェント型の AI 活用

のようなイメージです。例示は網羅的ではないですが、共通して言えそうなことはクイックウィンできる施策が少ないことです。正確にはクイックウィンできる施策は気づいた瞬間に実行されていると思います。つまり、仕事量の生産性の総量を高めるためには、投資を時間をかけて行っていく必要があります。

仕事量の生産性の効率化

仕事量の生産性を増やして、手数で押し切る改善方針には一定の仕込み時間がかかることがわかりました。一方で、生産性の課題は経営上の重要なテーマであり、迅速な改善が求められます。

開発生産性を上げる手段は、生産量の増加とロスの削減に分解できます。利益を増やすには売上を増やしてコストを下げるみたいな話です。ロスの削減はある程度クイックウィンが効きやすいので、短期的な開発生産性改善のレバーとして有用です。

まずは開発プロセスを見直して、自分たちの仕事のうち期待付加価値を生めていない時間を見つけます。システマチックな特定方法を自分は知らないので、気合いと直感でいつも探しています。

一つロスを見つけた場合は、ボトルネックまでちゃんと深掘るのが重要だと考えています。表面的に見えているロスに対処しても、根本的なボトルネックが解消されていなければ、結局また別のロスが発生すると思います。

ロスを特定した後、「よし、無駄をなくそう！」のようにシンプルな話であれば良いのですが、自分の経験としては大体以下のいずれかのロスが見つかります。

• 投資ではあるものの取り組みが過剰で無駄もありそうなロス
• 無駄ではあるものの解消に投資が必要なロス

無駄もありそうな投資については実験的改善で、無駄を削減するための投資は無駄の影響度による優先度付けとリソース配分の最適化によって解消していくのが良いと考えています。

無駄もありそうな投資に対する実験的改善

当たり前の話ですが、無駄と判断できるものは早く削りたいです。特に、意思決定さえすれば no time で効果が現れる MTG の削減などは真っ先に槍玉に上がるものでしょう。さて、そのようなロスで無駄と断定できるものはどれほどあるでしょうか？ どの業務も何かしらの目的を持って実施されているため、基本的に無駄と断定できることはないです。あった場合はおそらく別の根本的な原因がより上位の意思決定にあります。

無駄かどうかわからないけど、削ったら間違いなく期待付加価値の生産性や仕事量の生産性に充てる時間が増えるといったロスを見つけた場合は、実験的な取り組みが必要だと考えています。アジャイル開発の精神に則り、仮説を立てて小さく試し、効果があったら拡大するというサイクルを回していく方針です。

状況に応じて、過剰のラインは上下させる必要があります。カケハシさんの取り組み 20%ルールに頼らない: 技術的負債を解消する 組織的な取り組み はとても参考になりました。

無駄を削減する投資のコストとリターン

ビルドの待ち時間やバグフィックスなど無駄と断じられる業務も存在します。これらは、少ければ少ないだけ良いものの、減らすために投資が必要になることが多いです。投資についてはいつ何をやるのか決めるためにコストとリターンを見積もる必要があります。

コストはストーリーポイントなどお決まりの方法で各社の既存の方法で見積もり可能です。リターンを決めるには対象期間を定める必要があります。対象期間の開発マイルストーンを踏まえて無駄の発生頻度や発生確率をざっくりと把握すれば、およそどれくらい時間を浪費するか考えられるはずです。

コストとリターンを踏まえて優先度を付けて、期待付加価値の生産とのリソース配分のバランスを取りながら投資を進めていきます。これも言うは易しな方針ですね。期待付加価値の生産における優先度を握るのは多くの場合ビジネスサイドです。対して投資のリスクとリターンが解像度高く見えているのはエンジニアリングサイドのみで、前述の通り説明が基本的にとても難しいです。しかしながら、期待付加価値の生産と投資は同じ仕事を食い合うため、並べて優先度を決める必要があります。

期待付加価値の生産と投資のバランシングは後ほど詳しく見ていきます。

期待付加価値の生産性改善

期待付加価値の生産性から実現付加価値の生産性への変換に伴うロスは避けられません。先に述べた通り、できることはしっかり仮説を練ることと検証を十分に行うことと捉えています。

エンジニアとしてやるべきことは仮説に疑念を抱いたらちゃんと質問すること、仮説をしっかりと理解すること、仮説に対してより良い検証方法の提案をすることなどが挙げられます。要は仮説を作るビジネスサイドとしっかりとコミュニケーションを取りましょうとまとめられます。

特に非機能要件などについてはエンジニアの方が鼻が効くと思っています。さらに言うとセキュリティや可用性の話をこのレベルの会話に持ち上げることはエンジニアリングサイドの責務であると考えています。

期待付加価値の生産と投資のバランシング

最後に、仕事量の生産性をどの程度投資に回すかについて整理します。

「無駄を削減する投資のコストとリターン」の項では投資に優先度のヒントとなる項目のみを洗い出して、そこで議論を止めていました。期待付加価値の生産、投資、無駄はどれも仕事量の生産性を使います。よって、優先度を決めて同じリソースをうまく配分しつつ仕事を行っていく必要があります。無駄は避けられないもののみ残っているはずなのでこの場合議論から外しても良いでしょう。期待付加価値の生産と投資の2つをどのように実施していくかについて、まずはシンプル (極端) な方針を2つ見た上で組み合わせ方を考えます。

• 期待付加価値の生産と投資を同じタイムラインに並べて計画を練る方針: 投資対象に対してビジネスサイドにある程度理解してもらった上で、期待付加価値の生産と比較しなければならない。経験上うまく比較することはできないので組織内でのパワーバランスが如実に影響する。
• 投資についてはエンジニアリングサイドの裁量で実施時期などを判断する方針: 事業組織として期待付加価値の生産を優先したいはずなので、投資を増やしすぎるとビジネスサイドの納得感が得られない。またエンジニアリングサイドも基本的に期待付加価値の生産を優先したいと考えているので、投資に消極的になる可能性がある。また、開発生産性はエンジニアリングサイドのみではなく全社を挙げて取り組むべきテーマであるにも関わらず、サイロ化してしまうリスクがある。

上述の通り、極端な方針を取るとうまくいかないというのが私の考えです。現実的な投資へのアプローチとしては2つを組み合わせるのが良いと考えています。

• 定常的に仕事量の生産性の一定割合をエンジニアリングサイドが決定した対象への投資として充てることにビジネスサイドと合意する
• 投資対象についてビジネスサイドと合意した上で、他の期待付加価値の生産性を向ける対象と同格に並べて優先度を決定して対応計画を立てる

一定割合のリソースを投資に回すことを合意してスピード感を持って改善を進めつつ、一定割合を超えないことでビジネスサイドの納得感をある程度得ることができます。大規模な投資の場合は一定割合の枠に収まらなかったり、予算の問題が生じたりするため、どれだけ難しくてもビジネスサイドに内容を説明した上で、期待付加価値の生産と比較して優先度を決める必要があると思います。

ちなみにエンジニアリングサイドの裁量内で解消していく方針とビジネスサイドと合意を形成してから進める方針は CAPEX vs OPEX のようなメタファーで捉えることができると AI 先生がおっしゃっていました。自分の口でうまく説明できる自信がないのでここでは深掘りしませんが、確かにビジネスサイドに伝わりやすいようには感じたので、コーポレートファイナンスが得意な方はぜひ活用してみてください。

エンジニアリングサイドの裁量による投資

個人的には可能な限りエンジニアリングサイドの裁量として与えられたリソースの枠内で対応し続けることが理想と考えています。先述の通り、技術的なロスの説明は難しく、その準備時間もロスになります。手続型のパラダイムで実装されているビジネスロジックを関数型と OOP のパラダイムを用いてリファクタリングすることが、どのような業務でどのようなメリットがあるかをビジネスサイドへ説明するとか想像するだけで辛いです。

...想像したらちょっと楽しそうではありますね笑。どちらかというと説明される側が地獄かもしれないです。

説明なしの枠の割合は実験的な改善を持って調整していく必要がありそうです。 The DevOps ハンドブック 理論・原則・実践のすべて では少なくとも20%として紹介されていました。一旦その程度に設定して状況に応じて調整していくのが良いと考えています。

一定の枠はちゃんと使い切るようにすることは結構重要な観点だと思っています。先に述べたように、特に弊社のようなスタートアップの場合はエンジニアも事業に対する関心が高く、放っておくと期待付加価値の生産を優先してしまいがちです。一方で、投資を行わないといつまで経っても開発生産性が伸びていかないので、開発工数を管理する立場の人間は常にこのバランスを意識しておく必要があります。 こう書いていると資産運用のアセットアロケーションやリバランスと近いことをやっているなと思います。

一定の割合をちゃんと制御するには、ある程度定量的にリソースの使われ方を掴む必要があるので、 Velocity の計測に内訳を盛り込むなどの工夫はしておくのが良いと考えています。

エンジニアリングサイドの裁量で枠を使うということは、エンジニアが自分たちで何の投資を行うのか決定することを意味します。ビジネスサイドへの説明をショートカットできるため説明内容は簡素化できるものの、コストやリターンの見積もりはしっかりと行う必要があります。

ビジネスサイドと合意の上で進める投資

ビジネスサイドと投資対象に合意して大規模な開発を行う場合は、どれだけ難しくても十分な説明が必要です。なるべく定量的な形で仮説や工数を説明して、その他の期待付加価値の生産と比較できるようにしたいです。これらの説明を助けるために 事前に 準備しておきたいものを以下にまとめました。

• 開発生産性の指標計測
  • DORA の Four Key Metrics が有名
  • 100%信頼できる指標ではないものの開発生産性をある程度定量化できるため投資のコストとリターンの見積もりに役立つ
• SLO (Service Level Objective)
  • ビジネスサイドと非機能要件の目線感を擦り合わせる土台
  • SLO に抵触した際のアクションまで事前に合意を取っておくとコミュニケーションコストのロスが小さくなる
• ADR (Architectural Decision Records)
  • Martin Fowler による技術的負債の分類の内、「意図的かつ慎重」なものを増やすことで、計画的な解消を可能にする
  • なぜ投資が必要な無駄や非機能要件の課題が発生したのかの背景の説明が容易になる
  • ロスの解消方法のヒントをくれる

もっとあると思いますが、自分が扱えているのはこの程度です。これらの指標は一定の割合を決定する際にも使えるものですし、ビジネスサイドへの説明に使えるというだけで本来はそれぞれもう少し抽象的な意図があるものです。説明の時に納得感のあるものが出せることは重要ですが、説明のためだけに指標を準備するのはリターンが見合わない可能性があるので注意が必要そうです。

ちなみに、自分が最も好きな技術的負債の使い方は事前にロスの発生を予想して、「借入」についてビジネスサイドと合意することです。「借入」を行なった後は ADR にこれを記録した上で、必要なタイミングが来たら返済を計画します。事前にビジネスサイドと合意している返済であるため、すれ違いは少ないはずです。

おわりに

長文へのお付き合いありがとうございました。

うまくまとめられた自信はないものの、自分が考えていることは書き出せたと思っています。皆様の日々の開発のどこか何かのヒントになってくれればとても嬉しいです。

最後に、ブルーモはエンジニアを積極採用中です。少しでも興味がある方は以下の採用ページからご連絡いただけると幸いです！

https://careers.bloomo.co.jp/