読者です 読者をやめる 読者になる 読者になる

sandbox

Scala, Android, Architecture, Management, Service Design あたりを主戦場としております

技術的負債を抱えた状態で技術者がすべきこと

この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。
技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。

技術者がすべきこと

大前提

開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。

  1. 短期的な価値実現を最優先とし、初速を重視ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする
  2. 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする

1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。

…とはいえ、人生は 0 か 1 で語れる様な綺麗な世界ではない。
仮に 2 の認識の元、動きだしたプロジェクトであっても、予測できない現象が発生したり、不完全な人によってコードが書かれる限り、負債というものはどうしても発生する。

負債が目の前にある。
ただステークホルダーはその事実を認識していないか、または理解してもらえない様な場合にどうすればいいのか。

負債を明らかにする為に負債の総量を見積る

元記事でも言及されている様に負債には様々な種類があり、モノにより定量化が困難な負債も存在する。

不確実性の高い新規開発において時間ベースの見積りが意味を無さないのと同様に、大量の不可解なコード、存在しないドキュメント等の負債を抱えたプロダクトがチームに与える影響を絶対的な単位で定量化しようともまず無理だろう。

必要なのは、まさに作業をしている感覚を信頼できるチームによる相対的な見積りを行い、感覚ベースでスクラム等で採用されている 1,3,5,8… 等のポイントで負債の大きさを見積る。 そして、今目の前で曖昧になっている「技術的負債」というものを数値で明確化する。

まずは自分達が負債をどの程度抱えているのか、その負債が与えるインパクトがどれ程か、という感覚を定量化し、チームとして負債を認識する事が重要だと思う。

数値の規模感を共有する為にストーリーにする

負債を相対的に数値化したところで、既に共通認識が形成されているか、余程理解あるステークホルダーでない限り、「ひー、80ポイントもあるんだ。今すぐ返済しよう」とは言ってくれないだろう。

最初に必要なのは、やはり技術的負債がどの様なものであり、それがステークホルダーにどの様な影響を与えるか、これを理解してもらいやすい単位でストーリーとして話せる様に整理する必要がある
※ ストーリーの粒度に関しては、開発内部の負債の整理は細かくやってもいいと思うが、対ステークホルダーの説明としてはかなりざっくり、スクラムでいうエピックレベルでいいのかなとは思う

サービス開発におけるストーリーとは違い、すべてのストーリーに対して詳細に説明する必要はおそらくなく(おそらく負債について全部理解したいという動機がそもそもない)、幾つか内容として理解してもらいやすく、影響が大きいものをピックアップし、それらのストーリーに与えられたポイントの規模感さえ掴んでもらえれば、あとは負債のポイントの総量が明確であれば、「同様の問題がこれだけあるのか…」という風に想像がつきやすい。

もしかすると、理解あるステークホルダーであれば、ここで語られたストーリーの時点で、技術的負債の返済について具体的な計画を話し合える状態になる事もあるかもしれない。

それでもダメならコスト換算する

結局、総量を見積り、ストーリーによって負債が抱える現状と、それが与える影響を共有できたところで、会社として負債を返済することの Go がでないと意味がない。

ありそうなパターンとしてはプロジェクトチーム内ではその問題を共有できても、チーム内だけでは負債を返却するだけの期間をリソースを確保する権限がなく、上層部を説得する様な必要がある場合も容易に考えられる。

その場合は、特定のインパクトある負債を抱えた状態のストーリーをプレゼンテーションするのは同様だが、自分達が見積ったポイントあたりのコストというのも算出し、提示することで、負債がどの様にコスト等のビジネスインパクトを与えるのかを、上層部も納得しやすい理由を作ることができればよいと思う。

コストの算出に関しては、例えば現状のチームのおよそ人件費をベースに、いくつかの負債のストーリーを負債を抱えた状態と、返済した場合の人件費を比較してみて、ポイントあたりのコストを算出し、あとは負債の総量とかけあわせて、負債を抱えた状態で開発を続ける事がいかに経済的な合理性がない事を共有(多少でっちあげる事が)できればいい

共通認識にする

上記に書いた様な事が共通認識として形成されれば、健全な体制を作るのは比較的容易で、負債のポイントあたりのイメージが形成できている為、開発過程で負債が発生しようが、定期的に技術的負債を見積る、共有するというマイルストーンを設けておけば、あとはサービスに要求されるスピードに応じた返済プランをプロジェクトチーム内で検討できればよいし、「負債のポイントが50ポイントに達したら新しい要求は受けつけられない。返却フェーズとする」という様な決まりでもいいだろう。

もし、それでもまた負債が無視され、スピードだけが求められる様なことがあったら、負債が及ぼす影響のストーリーと、数値化されたその時点での負債の総量を示し、再び負債を返却すう必要がある時期だという事を主張するプレゼンテーションの場が必要かもしれない。

人と人が関わる開発においては、そもそも技術的負債という概念や、負債のポイントあたりの規模感などの共通認識の形成こそが重要で、一旦共通認識が形成されれば、コミュニケーションコストが減り、開発効率は上がり、健全なソフトウェア開発ができるのではないかなと思う。

まとめ

以上、技術者がすべきこと、として考えていることをまとめると、

  • プロジェクトを開始する前に、何を優先し、何を犠牲にするか、ステークホルダーに十分に認識を共有する
  • 負債を定期的に観測し、ステークホルダーと共有できる単位で数値化し、ストーリーで語り、理解を得る
  • 技術的負債における影響と、ポイントあたりの規模感を共通認識とし、閾値などを設けて仕組み化する

というあたりかなと考えている。

捕捉

こんな面倒なことせずとも、話して終わればそれでよい。
ただし、チームで相対的なポイントにより負債の総量を常に把握するのはよいプラクティスだと思う。