技術的負債をうまくマネジメントすることは重要です。なぜなら、持続可能な長期的な利益の確保こそが競争戦略における目標であり、技術的負債への対応力はその目標に近づくための重要な組織能力だからです。EMとして組織の成果の最大化を目指す上で避けては通れない課題です。また技術的負債への対応は、単に技術的な課題ではなくそれらを包含するプロダクトの課題です。どうやって解決するかだけでなく、なぜ、いつ、どのくらいやるべきかを、事業責任者などのステークホルダーと合意して初めて対応を進めることができます。こうした課題に対しては、多職種をつなぐメンタルモデルの構築、方向付け、ファシリテーションといったソフトスキルが必要になってきます。EMはエンジニアリングの視点とそうしたスキルを併せ持つことが期待される存在で、技術的負債への対応においても重要な役割を担うと考えています。本記事では、技術的負債をマネジメントする方法についてEMの視点で考えをまとめます。
技術的負債の定義
まずはこの記事において「技術的負債」が何を指すかを定義しておきましょう。原典を辿るなりして世間的な定義を見つけることはできますが、この記事では競争力や成果を主眼に置いて議論をすることから、次のように独自に解釈をして話を進めます。
技術的負債とは事業に好ましくない影響を与えるソフトウェアの性質全般を指すものである。
技術的負債に対応する重要性と難しさ
ソフトウェア開発において、新しい価値を次々と提供し、かつ既存の価値の満足度を必要水準に保つことは競争力になりますが、この競争力は基本的には何も手当てをしなければ低下します。なぜならソフトウェア自体、何も手当てをしないまま開発運用を続ければ技術的負債が蓄積する性質があるからです。一方で何か手当てをしながらでは価値提供のスピードが足りない局面というのが往々にしてあって、一時的に競争力を高めるために技術的負債を狙って積むこともあります。こうした事情を鑑みると「技術的負債への対応」はソフトウェアでビジネスをやるプレイヤー全員に平等な制約と言えるでしょう。技術的負債のことを考えずに儲けられるソフトウェアサービスがあったらぜひ参加したいものです。技術的負債によりうまく対処し、開発能力の面で競争力を維持向上することは、ソフトウェアビジネスにおいて重要だというのは明らかでしょう。
しかし、技術的負債に対応する重要性にはもう一段深みがあると考えています。全員に平等な制約であれば、全員が対応してしまえば差別化要因ではなくなるわけです。しかし世の中はそうはなっていません。なぜか。それはひとえに技術的負債への対応が難しいからであると考えます。全員に平等な課題でありながら対応が非常に難しく、ゆえにソフトウェア事業の主要な差別化要因として競争優位性を生み出せるポイントになるのだと思います。
その具体的な難しさは多岐に渡ります。まず素朴に技術面での難しさはあるでしょう。技術的負債を特定し改善のために過不足なく設計と実装を選択するには相当量の知識と経験が必要です。EMとしてこの技術面の課題をうまく解ける人材を育て能力を引き出すことは重要です。
しかし技術的負債の難しさはそれだけではありません。仮に解くべき課題と解き方を特定したとしても、それをやる工数があるとは限りません。売上目標や顧客要望に基づいて計画された機能の追加や改修と、技術的負債への対応のどれを優先すべきかを考えなくてはなりません。影響を与える対象も時間軸も異なる仕事の価値を比べるのは難しいことです。また技術的負債への対応はタイミングも難しい傾向があります。早すぎても過剰な改善になってしまうし、遅すぎても問題が複雑になりすぎて手がつけられないという具合です。テクノロジーマネジメントというよりは、プロダクトマネジメント的な難しさが付きまといます。多くの事業がこうした難しさの前に建設的な議論を尽くせず、機を逸して競争力を損なっているように思います。ここをうまくやるのがEMの腕の見せどころと言えるでしょう。
基本方針
EMとしてのゴールは、チームが技術的負債について建設的に議論し、実際に技術的な手当てを通じて事業の競争力を維持向上できるようにすることです。特に自分は間接的に各事業に関わっているので、自分が課題を整理したり、特定の仕事をステークホルダーにかけあうようなことは効果的とは言えません。望ましいのは抽象度の高い方向付けによるレバレッジの効いた働きかけです。
この記事では以下の2つの方向付けを提案します。共通するのはステークホルダーの関心に沿って進めることで、可視化、計画と実行のそれぞれについて考えます。
技術的負債をステークホルダーの関心に沿って可視化する
前の節で、技術的負債のプロダクトマネジメント的な難しさ、つまり価値判断の共有とタイミングの難しさについて述べました。この節ではその課題への対処を考えてみます。
技術的負債への対応を行う上での重要なステークホルダーは、事業責任者やPOといった、開発チームが何に時間を使うかに説明責任を負っている人たちになるでしょう。その人たちに対して「システムがXXだから手当てをしたい」と伝えるのが素朴な始め方ですが、おそらくこれでは事態は前進しません。事業の予算や目標を立ててその達成に邁進する立場からは、それが売上やコスト、事業目標にどう関係あるのかが最も重要なのです。それがわからない限りはリソースを投じる判断はできません。技術的負債は、事業の障害になっているという証拠によって初めてステークホルダーに発見されるのです。とすれば、彼ら彼女らの関心に沿って技術的負債を可視化するのが最初にやるべきことになります。
例えばベロシティは可視化の道具として有用です。ソフトウェアをいつ頃にどんな状態にできそうか、大掴みな開発計画を立てるための重要なガイドラインになる指標です。これが乱高下したり下降傾向になることは事業責任者にとって重要な関心ごとになるはずです。そしてそのような指標の変化の裏にはしばしば技術的負債が存在します。「変更しようとした箇所が複雑すぎて整理に時間がかかった」「テストケースが不十分でデグレを起こしたので対応に時間がかかった」といった具合です。なぜベロシティが望ましくない状態なのかという共通の文脈の中で技術的負債を提示できれば、ステークホルダーも実害とともに技術的負債を認識することができるでしょう。これが関心に沿って技術的負債を可視化するということです。
ステークホルダーと共有しやすい関心は大きくふたつあると考えています。ひとつは「想定通りのスピードで開発できているか」です。たいていは予算や目標から逆算した開発計画を引いているわけで、その開発のスピードが出ていないとなれば一大事です。そして技術的負債の結果指標としての側面もあります。上述のベロシティはそれを検査する典型的な指標です。他にも、見積もりとの予実やFour Keysは関連性の高い指標として活用できるでしょう。
もうひとつの共有しやすい関心は「システムの障害が増えていないか」です。システムを利用できない、動作が壊れている、重いといった事象は事業への信頼を損ねるものです。完璧はありえないにしても、その頻度や程度が一定の閾値を超えてしまうとユーザーが離れる原因になってしまいます。より外のステークホルダーへの説明といった胃の痛い業務も増えるので事業責任者やPOにとってもしっかり嫌なイベントです。そしてスピードに関する関心と同様に、こちらも技術的負債の結果指標としての側面もあります。典型的な指標としては、可用性やレイテンシー、Four Keysから変更失敗率や平均障害復旧時間が挙げられるでしょう。
こうした共通の関心を計測し、そこに沿って技術的負債を可視化することで、まずは優先度判断の議論ができる土台を作れると考えます。また、ここまで述べたような指標は、技術的負債に対応するタイミングをはかる上でもよく機能するはずです。これらの指標を定期的に検査しておくことで、開発生産性とシステムの安定性における実害が出て、課題が顕在化しはじめたことをキャッチできる期待があります。エンジニアが最初にキャッチする漠然とした嫌な感じは超えていて、かつ手がつけられない状態になるまでには時間があるという、絶妙なタイミングで問題を俎上に上げられる頻度が高まるはずです。
ステークホルダーの関心に沿った目標を置いて戦略的に取り組む
前の節で説明したのは、技術的負債をうまく共有するための方向付けでした。実際に技術的負債に対応するためには計画と実行も必要です。この節ではそのための方向付けを考えてみます。
まず、前の節でステークホルダーの関心に沿って技術的負債を可視化する方向付けを提案しましたが、実は計画と実行においてもこの考え方は適用できます。例えば、平均障害復旧時間に関する課題感が高まっていてステークホルダーと共有できていたとします。それに対して「ログを出して監視をします」とか「障害対応演習を行います」と提案を始めてしまうと、やはりステークホルダーは判断が難しくなってしまいます。ステークホルダーの関心はあくまで「平均障害復旧時間をどうするか」であって、それをどう解くかはエンジニア特有の関心だからです。「このくらいのリソースを割けば平均障害復旧時間がこのくらい改善する」と大掴みに理解できると、ステークホルダーはリソースを投じる判断をしやすいのです。
もちろん、いつもすんなり目標が置けるとは限りません。数値目標をどのくらいに置くかで悩むこともあるでしょう。それでも「ベロシティの低下を最も招いたであろうXXな性質を取り除く」であるとか、抽象的なゴールを定義する言語化を行うことは、技術的負債への対応にリソースを割く障壁を下げるために重要です。EMとしても、単にこうした方向性を示すだけでなく、目標の設定を手伝うなど委譲のスライダーを動かして助けていくことができるでしょう。
また目標の効用はそれだけではありません。システムの結果指標に着目し、目標から逆算して少ない労力で実行する力が加わるため、戦略的な思考が促されます。変更頻度の高い部分の品質を重点的に高めたり、事業上重要なフローに絞って可観測性を高めたり、そういった鋭いアプローチが自然と生まれることが期待できます。これはリソースが限られている以上とても望ましい振る舞いです。アウトカムに着目して本質的な仕事に取り組むという意味では普遍的なプラクティスと言えるかもしれません。
まとめ
本記事では技術的負債のマネジメントについて考えました。技術的負債には、単に技術面の難しさだけでなくプロダクトマネジメント面の難しさがあり、それを乗り越えるためにはステークホルダーの関心に沿って技術的負債を可視化することが重要です。また、その計画と実行においてもステークホルダーの関心に沿って目標を設定することで、リソースを投じる判断をやりやすくし、また戦略的に取り組むためのガイドラインとすることができます。こうした抽象度の高い方向付けを通じて、EMとして効果的に技術的負債をマネジメントできるのではないかと考えています。
参考文献
