技術的負債の中身

これはエンジニアにとっては比較的当たり前の内容について書いている。そのためどちらかというと非エンジニア向けの内容として書こうと思う。

エンジニアが開発しづらいと感じたり開発速度を妨げる要因としてあげられるのが技術的負債だ。この単語自体はエンジニア意外にも知られる言葉となりつつあるため、わりと幅広い層の人たちが認識している単語だとは思う。実施に私自身が外部から関わっている会社でもよく聞かれる言葉ではあるが、単純に負債としてまとめていること自体が問題なケースも多く見かることが多い。その分類自体が問題の本質になっていることもあるため、自分の観測可能な範囲の情報をもとに書いてみようと思う。

技術的負債とは何か？

wikipediaには以下のように書かれている。

技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。

技術的負債 - Wikipedia

具体例として「ドキュメントの不備」や「テストコードが無い」などがあげられているが、たしかにこのあたりはわかりやすい技術的負債と呼ぶことができると思われる。しかしながら、今課題として技術的負債と呼ばれているもののは何を指していることなのか？そしてその問題は何が原因で発生をしていることなのか？を本質的に解決をしていかないと、この課題解決をしたときによる本来のメリットを享受することができない。技術的負債に向き合うことの本来の目的は、負債を返すことではなくその先にある品質の向上や開発速度の向上などであるべきだからだ。

コミュニケーション上の問題

技術的負債という単語を最初に発するのは現場の開発をしているエンジニアからだろう。想定した工数やスケジュール通りに開発が進まない場合の理由として「技術的負債のため開発が思うように進まない」といったコミュニケーションだ。たしかに広義でいえばそうなのかもしれないが、この技術的負債といったものがどういったものなのかをここでちゃんと具体的に解決していく必要がある。

コードが必要以上に複雑になっているのか、1つのメソッドに多くの役割をもたせすぎているのか、不要なメソッドが多数残っているのか、エラーが考慮されていない実装になっているか、テストコードが存在していないのか、などだ。ここにあげた事例はあくまでごく一部であり、他にも沢山の課題としての事例があげられると思う。しかしながら、こういった点の課題をまとめて「負債」として表現してしまっている限りはその課題と本質的に向き合うことがなかなか難しく、1つ1つにちゃんと向き合っていく必要がある。そういった課題と向き合う時間としてレトロスペクティブといった仕組みがあり、そのなかで具体的に話されなければいけない。

定期的なレトロスペクティブ

レトロスペクティブでおそらくもっとも使われている手法がKPTと思われる。たしかにシンプルで実施のしやすい方法のため、学習コストはひくく誰でも参加のしやすいものではある。しかしながら、KPTであげられた問題に対してちゃんと向き合いそれ以降のプロジェクト運営に反映させていくことが非常に難しい。また、Problemとしてあげる課題の粒度にも問題があることがあり、曖昧な表現が多用されているのであればファシリテートを行う人間が、それを深掘って具体化していく必要がある。振り返りはただあげた単語を追うだけのものではなく、本質的な課題に向き合うためのコーチング的な問いかけも必要となってくる。

負債を生み出す本質を考える

課題があるとどうしても人は点の解決策を考える。たとえば、テストコードがなければテストコードを書こう！といった具合だ。たしかにこの解決策は間違っていないし、その見えている問題に関しては解決をすることができる。しかし、この対策のみで取り組んで行ってもまた同じようなことが繰り返され、「テストコードを書かずに実装をするプロセス」と「あとからテストを追加するプロセス」がそれぞれ別になってしまうということが容易に予測できる。

ドキュメントに関しても同様だ。ドキュメントを書こう！となっていったん書いたはよいものの、そのドキュメントが形骸化していくことはよくある。またドキュメントの置き場も散ってしまい、Github上のissueやwikiに書いたり、ConfluenceやJIRAのチケット内に書くケース、SpreadSheetやSlack上のどこかにあるなんてケースもあるだろう。そのためこういったものを本来はどうすべきであるか？といった点もつねに考えていく必要がある。

そしてこういった課題を解決していくわかりやすい手段のひとつが「ルール化」である。たしかに一見正しそうに見えるし、最終的にはルール化でしか解決できない問題もある。しかし本来向き合うべきなのは、ルールを作ることよりも、起きた問題が抱えている本質的な課題とどう向き合うかといった点だ。 ここを解決しない限り、確実に再発することになる。しかしながらこの本質的な課題に向き合うことがリソースとの兼ね合いになり実現されないことが多い。

本質的な課題解決に向き合えない理由

テストコードがないといった種類の負債を例にとって考えてみようとおもう。これはエンジニアにとって当たり前の思想になっているが、テストコードに関しては仕組みで矯正をしていくことだ。自動的にテストが実行されるような環境の整備やそれに紐付いたデプロイ環境の構築、またそれにともなう各種の通知やレポートの受け取りなどである。このあたりは現時点でのベストな解決策はある程度決まっており、この言語（もしくはFWやインフラ選定でも変わる点はある）ならこうやったほうがいいといったものは先人たちの試行錯誤した結果がドキュメントとして溢れている。それを参考に構築していくのがよいだろう。

ここで課題となるのは、こういった開発の工数がプロジェクトの進行に直接的な影響が見えないためどうしてもないがしろにされてしまうといった点だ。たしかにPdMといった立場にたつと、目の前の機能開発を優先させたくなるため一見ユーザーに届けるには直接的に影響がない開発工数はできるかぎり後回しにしたい。とくにエンジニア出身でないPdMとなるとそのあたりの重要性が理解しづらいからだ。これはエンジニアの多くが経験したことであると思う。

しかし、PdMがエンジニア出身で無い限りこの点を理解できないのは当然である。世の中全てのPdMがエンジニア出身であれば解決できる問題なのかもしれないが、本質的にPdMが目指すべきことはプロダクトのグロースだ。そういった意味ではプロダクトのグロースにもっとも寄与できる人材をそこにアサインすべきである。だからこそ、プロダクトが成長している限りにおいてはそのPdMが技術への理解が乏しかったとしても、リソースのアサインという意味では決して間違っていない。ひとつ重視すべき点は、技術的な大局観をもっているかどうかだ。

技術的な大局観

先日も「品質 vs スピード」がテーマで話題になっていたが、この問題を引き起こす本質的な問題は技術的な大局観をもっているかどうかだ。もう少し具体的にいうと、短期的な開発速度だけでなく中期的にみた差し戻しやバグ修正も含めた開発のトータルコストの話である。こういった視点が入ってくるだけで、既存の課題の本質への向き合い方が変わってくる。 たしかに短期的にどうしても出さなければいかないものはある。これはユーザーに向けたものだけではなく、投資家とのコミュニケーションで生まれているものも含まれていたりするため、現場のメンバーが把握できないようなコンテキストが背景にあることもある。しかしながら、こういった中期的な観点を持った上でプロダクトをどうやってよりよくしていくのかといった観点を意識的に持つ必要がある。

また、この点をエンジニア側も説明をする義務がある。「テストコードがないのはダメだ！」という主張を直の上長が理解してくれない環境なのであれば、推進していく人がちゃんと説明をすべきだ。技術領域における短期的・中期的な課題やこのままいくことのリスク、その上でユーザー向けの機能開発のリソースを一定期間減らすことなどの説明だ。Web系のスタートアップだと、プロダクト開発が直接的に経営に与える影響は大きいため、経営とのコミュニケーションにもなってきたりもする。このような課題を分析し提案することが、内部だと難しいときに外部の技術顧問などを活用するケースがあったりする（ただ、技術顧問の定義は曖昧で人によって定義が変わってくる。このあたりは以下の記事にまとまっているので以下の記事を参考にすると良いと思う）

言語化することの大事さ

巷に溢れている単語だけでコミュニケーションしたり、点の課題を直していくだけでは本質的な改善は行われない。ここで大事なのは、言語化能力でありいま起きている課題の本質を正しく伝えることができる能力だ。なんとなく曖昧な課題感を適当な単語に当てはめてカテゴライズすることは容易であるが、そこに向き合うことは難しい。だからこそ、表面化している課題とちゃんと向き合い、課題をブレイクダウンしていくことで課題の本質に対してさまざまな対策を練っていく必要があると思われる。