CNDO 2021、技術的負債を現場のエンジニアが対処する方法を解説

コンピュータシステムを開発運用していく際に、設計・開発の時点では最適だったテクノロジーやツール、インフラストラクチャーが、時間の経過や環境の変化の中で「お荷物」と化してしまうことは往々にして起こり得る。その状況に対して現場のエンジニアはどう対応していくのか、ビジネスに責任を持つオーナーに対してどのように説得を行うべきかなどについて、AWSのシニアデベロッパーアドボケイトが解説を行ったセッションを紹介する。

「技術的負債とステークホルダと説明責任と」がタイトル

個人ではなく組織において開発が行われる場合、技術的負債が発生したとしてもそれを即解消するわけにはいかない。意志決定者と現場のエンジニアにおいて、負債の返済のための工数確保に合意する必要があり、その難易度は階層的に積み上がっている意志決定者の数に比例すると解説した。例えばECサイトを例にとれば、意志決定者とはそのビジネスに対して売上責任を持つオーナーであり、現場の人とはそのECサイトを開発運用するエンジニアということになる。

組織における技術的負債には工数確保の合意が必要

ここで技術的負債については「当時は最適だった選択が時間の経過とともに最適ではなくなってしまったもの」と定義して説明を行った。実際には時間だけではなく、そのビジネスを取り巻く環境の変化や利用したツールの開発がストップしてしまったなどの外的要因によっても起こり得るだろう。

技術的負債の定義

また「なぜ技術的負債が良くないのか？」については「最適」を再評価しないシステムは、継続的開発の生産性を落とすからだと解説した。

継続的開発の生産性を落とすのが技術的負債

ただウォーターフォール型のレガシーなシステムにおいては、開発が終わって本番運用が始まってしまえば、継続的開発自体が行われないので、技術的負債自体が発見されないという事態もあるだろう。ちなみにこのスライドに書かれているURLは技術的負債という概念を生み出したWard Cunningham氏による解説を日本語に翻訳したブログへのリンクである。

参考：【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明

技術的負債の返済について解説

では継続的開発の過程の中で開発に携わるエンジニア自身が技術的負債を発見したとして、それをどのように返済していくのか？ を現場視点で解説した。そして、すべてをゼロから書き直す手法では、それが合理的な方法論であることを意志決定者に納得させることは難しいと説明した。

ボトムアップではビジネスオーナーの理解を得るのは難しい

そしてエンジニア視点での解決策ではなく、ビジネスオーナーが理解できる共通認識を持つことで最終的にビジネスサイドが要求する問題解決にたどり着けると説明した。

神々の関心とエンジニアの関心を掘り下げる

その負債返済の方法については、優先順位や影響範囲の確認、返済するための手段／方法のコスト、それが解消したことの確認方法などが必要になると説明。ここでは負債の大きさと難易度は比例するとして、「なるべく小さく始める」「効果が出ない場合は中止する」「どうして効果が出なかったのかを評価する」というポイントを解説した。

負債返済のポイントは小さく始めることと効果測定

最後に一度、技術的負債の返済のアクティビティが始まったら、それに必要な人的リソースの追加投入、もしくは新規開発を止めてリソースを振り分けることを意志決定者全員が合意することが重要だと強調した。これはわかりやすい言葉で言えば現場のエンジニアを「邪魔しない」ことだと説明した。

技術的負債返済にはビジネスオーナーの合意と邪魔しないことが必要

最後にまとめとして、現場の技術者視点では、ビジネスオーナーにちゃんと説明できること、小さく始めて効果が出なかったらすぐに止めてその原因を解明することが重要だと説明した。

現場エンジニアに必要なポイント

またビジネスオーナー、意志決定者においては、負債返済のためのリソースを用意すること、他部門への説明責任を持つこと、効果測定を行うこと、返済タスクの実行を邪魔しないことが必要だとしてプレゼンテーションを終えた。

多分に現代的な継続的開発プロジェクトをベースにしたプレゼンテーションで、これからレガシーなシステムを刷新して継続的開発プロジェクトに移行しようとする場合には、要点が伝わらない可能性もあるかもしれない。システムは一度完成したらそのまま塩漬けにするのではなく、常に改善を行うことで時代や環境の変化に対応できるようになる。変化への対応を行う場合に陰に隠れがちな技術的負債にフォーカスして、失敗例を挙げながらの解説は高く評価されるべきだろう。