組織と個人それぞれの技術的負債の解消方法
原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。
はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。
今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこうと思います。技術的負債は、主に継続的な開発を前提としたソフトウェアに関連して、話題にあがることが多いと思います。
個人で開発しているときはどうでしょうか。何かを開発していて「あ、この負債ちょっとヤバいな」となったら、サクッとお手入れしますよね。将来もっと面倒なことになる前に、今のうちにやっつけてしまおうと。これは自然なモチベーションですし、個人での開発では、こんな感じのことをみなさん日々やっているだろうなと思います。少なくとも僕はそうです。
仕事では、組織で開発することが多いでしょう。組織での開発では、どうなるでしょうか。「この負債ヤバいんちゃうか？」となってから、実際にお手入れする前に、もう1つステップを踏むことが多いです。
そうです。工数の確保を合意するはずです。組織で開発をしているということは、そのソフトウェアには、複数のステークホルダーがいるはずです。そのため、技術的負債の返済をしていく前に、その返済に工数を使うことを、なんらかのかたちで合意することになるのが、非常によくあるシチュエーションです。
“工数の確保を合意”と一言で書いてしまうと、なんだか簡単に見えますが、所属している組織の形態や、扱っているソフトウェアの性質、あるいは返済しようとしている負債の内容など、いろいろな要因で難易度が変化します。
その難易度を決める要素によくなるのが、意思決定層の多重度合いです。組織が大きくなればなるほど、1つのシステムに関わるステークホルダーは増加していきます。それに伴って、意思決定層も多くの場合、多重化されていきます。
多重化していなければ工数確保の合意が簡単かというと、必ずしもそんなことはありません。このへんを言葉ではなく、もうちょっとわかりやすい、別の簡単な図で見ていきましょう。
組織の技術負債解消における相関図
たとえ組織で開発していたとしても、最初のステークホルダーはすごく少ない人数です。多くの意思決定が現場レベルでポーンと済ませられ、作りたてのサービスは、それはそれは開発が楽しくて仕方ないわけです。
ただし、サービスが成長してお金を稼ぐようになってくる頃には、こうはいかなくなることがほとんどです。1つのサービスに関わるステークホルダーは、多くの場合、目先のKPIが現場のエンジニアとは違うところにあります。
（スライドを見て）例えば、ここに登場した意思決定者は、とにかく利用者を増やすことがトッププライオリティです。そのために新しい機能を作り、バグ直しにプライオリティを置く。そういう人だとしましょう。
図の真ん中にあるとおり、長く開発をしていると、どんなシステムかに関係なく、システムのいろいろなところに、当然歪みのようなものが出てきます。この歪みに最も近いところで働いている現場のエンジニアとしては、将来のリスクをそこに感じるわけです。そのため、当然ですがこの歪みを直すことを提案します。
そうすると、ここで意見や考え方の衝突が起こり得ます。僕も現場のエンジニアとして提案したことが通らなかったケースに身に覚えがあれば、この図でいう、意思決定者側にいて意見が合わなかったことも身に覚えがあります。
さらに組織とかシステムによっては、その奥に経営層や意思決定層がいて、当然その人たちの思惑もシステムには絡んでくるわけです。
僕は仕事柄、AWSのいろいろなお客さんと会話をする機会があります。あるときはCTOだったり、あるときは現場のエンジニアの方だったりします。まさにこの図に出てくる、いろいろな人々と直接会話をする機会をもつことが多いわけです。
彼らは同じシステムに関わるステークホルダーですが、異なる立場にあり、それに伴って異なる視点でものを考えます。そして僕は、そんな彼らを第三者の視点で見れる立ち位置にいるわけです。
というわけで、今日のお話は、僕がとあるAWSユーザーのお客さんとの打ち合わせの場で話したことを、再構成してまとめたものになります。第三者の立場にある僕だからこそ見えやすい、システム開発の現場における話と言えます。あらかじめ伝えておきますが、AWSの話は一切出てきません。
（スライドを見ながら）本日のお題を一言でまとめるとこちらです。今日は、組織において技術的負債を返済していくうえでの難しさについて、みなさんと一緒に考察していこうと思っています。
“技術的負債”の認識合わせ
本編に入る前に、まずは簡単に認識を合わせておきたいと思います。“技術的負債”という言葉、よく聞くし、おそらくみなさんも、ふだんの仕事の中でよく使っていると思います。この技術的負債という言葉には、もちろんいろいろな解釈があると思いますが、本セッションにおける定義を最初に認識合わせしていきます。
「技術的負債って何でしたっけ？」と聞くと、こんな言葉が返ってきます。「前任者の手抜き実装がヤバくて、不具合だらけでやってられないですよ～。ははは（笑）」みたいな。こういうのが返ってきたりします。本日扱う技術的負債は、こんな程度の低い話ではありません。
本セッションの技術的負債とは、実装当時には考えられた方法の中でベストだと言えたものが、時間の経過とともにベストとは言えなくなったもの。これを本セッションでは技術的負債と定義します。
時間の経過によって起こること
そしてここに時間の経過とありますが、時間の経過によってどんなことが起こるのか、その例を少し見ていきます。まずはビジネスを取り巻く状況が、時間の経過とともに変わったりします。わかりやすいのは、世の中のニーズの変化です。
ほかにも、規制業界でシステムを作っているのであれば、新たに作られる法律に準拠していく必要性がある。こういったものも、まさにビジネスを取り巻く状況の変化と言えます。ただ、これらは機能要件として降ってくることが多いので、直接的に技術的負債と関わってくる可能性はないかもしれませんが、時間の経過がもたらす変化の1つです。
ビジネスやシステムに対して、自身の持つ知識、理解、洞察力が成長することも、時間の経過とともに起こり得ます。「当時は理解できていなかったけれど、継続的に開発を続けていく中で、深まったドメイン知識をもとに判断するならこう実装する」と思うことはよくありますよね。
それから、システムに関わる人間の数や、その役割も変化します。例えば、開発を始めたときは1人で開発していたので、1人で全部やれることを前提にアーキテクチャを設計していたとしたら、その後人数が増えたときに、スムーズにチーム開発を進めることは難しいです。
技術そのものも進化します。当時ベストだった技術選定は、現時点のビジネスとかシステムの状況から考えれば、適切ではなくなっているかもしれません。
つまり、時間の経過とともに、その時点で考えられる“最適”は変化するわけです。ふだんシステムに関わっている方であれば、身をもって体感していることだと思います。
なぜ技術的負債はよくないとされるか？返済に努めるのか？
ではなぜ、この技術的負債と言われるものが、一般に良くないものと捉えられるのか。これはもう自明です。今挙げてきたような、変化していく“最適”を再評価して、差を埋めることをやっていないシステムは、継続的な開発の現場において生産性を低下させるからです。
ではなぜ我々は技術的負債の返済に努めるのかというと、時間の経過とともに変化していく“最適”を、最初の段階ですべて予測しきることは、そもそも不可能です。だからこそ、変化する“最適”に対して、システムのキャリブレーションを継続的に行い、可能な限り高い生産性を維持し続ける。そのために我々は、技術的負債の返済に取り組むわけです。
（次回につづく）
