技術的遺産相続人
システム開発において技術的負債は有名な概念です。
技術的負債とは目先の利便を優先することと引き換えに発生するシステム全般に対する複雑性のことです。
すぐには価値を生まなくても将来的に活きるであろう労力を今現在の問題に対して前借りして消費することから、お金の借金になぞらえて生まれた言葉です。
雑に早く終わらせるか、丁寧に時間をかけるか、を天秤にかけて前者を選択することです。
当ブログでも不正確さは他人の仕事を増やすで、雑な仕事で生まれたコミュニケーションエラーが負債として溜まり、それが複利によって膨らんでいき、後々の仕事量が増加していくさまを図解を用いて解説しました。
私個人的にはそこから派生して生まれた言葉である「技術的連帯保証人」が、業界で働く人の目に見えない苦悩を端的に表していて気に入っています。
技術的負債そのものは別に悪いものではありません。
借金をしてでも今その瞬間に手に入れなければならないタイミングは長い人生の中で何回か発生することもあるでしょう。
クレカの利用やローンを組むことも負債ですが、それ自体はとても便利で人々の生活を支えています。
借金をした人が借金を返済をするのであればなんの問題もないと思います。
ただ日本には連帯保証人という悪魔の制度があります。
連帯保証人になってしまえば借金をした本人ではないにもかかわらず、債務返済の義務が発生してしまいます。
ただし、連帯保証人は契約書に判を押さないかぎり債務を引き受けることはありません。
ひるがえって、技術的連帯保証人は負債を作った本人やその債務を引き受けた本人の自覚なく、その責を負うことになるのです。
技術的連帯保証人の一番恐ろしいところは往々にして、負債により金を引き出した人は評価を受け、負債の返済に当てられた人は評価を受けづらいところです。
借金を作った人は引き出したお金の価値をまるまるせしめることができ、連帯保証人になった人はただただ身に覚えのない借金を返済させられ続けて疲弊していくのです。
開発初期の負債を積み上げる人は0→1の仕事なので成果物が目に見えやすく、負債を積み上げていても、それを気にする人はほとんどいません。
急成長しているベンチャー企業の売上が爆増していれば会社の抱える負債にあまり目を向けなくなるのと同じです。
ところが、負債を返済するステージになると何故か負債を積み上げた人はいなくなり、新しく加入した人が1→1の仕事に対処することになるので成果が見えづらくなります。
会社の売上が鈍化してキャッシュフローの対策を打たなければならない段で、生産性よりも負債の対策をやらざるをえなくなり、いくら頑張っても株主の機嫌を損ねてしまうのに似ています。
評価される仕事よりも評価されない仕事の方を頑張るような奇特な人は世の中にはほとんどいません。
そういった人間の性(さが)からシステムの技術的負債はこの世から永遠に解消されることはないのです。
技術的負債の問題が見える化され、それに対応するために様々な取り組みが生まれましたが、技術的負債は依然、世界に蔓延っているように思えます。
むしろ、新しいプロジェクトに移るたびに、なにかしらの技術的負債を目の当たりにします。
実は技術的負債の真の問題は、人の入れ替わりによる連帯保証人の召喚システムにあります。
技術的負債が悪なのではなく技術的連帯保証人が悪なのです。
IT業界は人員の入れ替えが激しい業界です。
業務系や基幹系の大きいシステムは、開発や運用する人を外部の請負や派遣の人でやりくりしている影響で人員の入れ替えが日常茶飯事です。
Web系やベンチャー系もビジネス環境が日進月歩で目まぐるしく変わる影響でやはり人の入れ替えが激しいです。
よって、システム開発は基本的に目先の対応を優先するほど技術的負債が積み上がり、技術的連帯保証人の数珠つなぎが発生し、破産(致命的なインシデント)が詰まった実弾の入ったロシアンルーレットとなるのです。
作業者は長期的な視点を持つことよりも目先のタスクを片付けるほうが評価されますし、人が入れ替わるごとにコミュニケーションの断絶が発生するのでシステムの複雑性は上がる一方です。
ゆりかごから墓場まで同じ人が一貫して作業を行うなら、長期的な視点も持てるしコミュニケーションの断絶も発生せず連帯保証人も不要なので、そもそも技術的負債が問題になることもありません。
もしダメだったとしても、その人が自己破産するだけで他人に害が及ぶこともありません。
よって「技術的負債をどうすれば減らせるか？」問題の最大の答えは「人を入れ替えない」となります。
人の入れ替わりが発生する時点で、どうあがいても技術的負債は発生するし、それを引き継ぐ連帯保証人も発生します。
逆に、技術的連帯保証人がいなければ技術的負債がいくら発生しようと苦しむのは本人だけなので技術的負債が大々的に問題になることはありません。
よって、技術的負債の真の問題は技術的連帯保証人を生むことにあります。
技術的負債の対策は技術的連帯保証人を無くすことです。
とはいえ、現実問題として、流動的なこの業界で人の入れ替えを無くすことは不可能に近いでしょう。
ですので、技術的負債の概念を逆手に取って、「技術的遺産」という概念を提唱したいです。
負債ではなく財産を残すことができれば、技術的連帯保証人ではなく技術的遺産相続人としてバトンを渡すことができます。
雑にやることが負債を発生させるのであれば、逆の見方をすれば、丁寧にやれば貯金を積み立てられることになるのです。
サーバントリーダーシップに則り仕事を遂行すれば負債ではなくむしろ財産が増えるはずです。
豊富なドキュメント、網羅的なテスト、リファクタリングされたリーダブルコード、それらは将来的に入れ替わった人を助ける財産になります。
さらに、このような遺産は人の入れ替わりが激しいほど、システムが歴史を重ねるごとに利子が積み重なって、より人々を助けるようになります。
技術的負債は人を苦しめますが技術的遺産は人を助けます。
前述のとおり、人の入れ替わりは前提条件のようなものですから、可能なかぎり負債ではなく財産を残すような仕事を行うべきです。
短期的には良くても長期的になってくると、借金にしろ貯金にしろ利子が発生し、複利が絡んで雪だるま式に増えていきます。
負債を背負って利子の支払いに追われるか、貯金をしておいて利息の恩恵を受け取るかで、将来的なシステム運用の難易度が全然違ってきます。
そう考えるのであれば、システムを長く運用していきたいのであれば技術的財産を蓄えておくべきです。
しかし、最初の方で説明したとおり、現在のキャッシュフローだけを見て作業者を評価をしてしまうので、負債を発生させたとしてもキャッシュ(目に見える成果)を作った人がやはり評価されます。
システムにおいても損益計算(P/L)だけでなくバランスシート(BS)を用いて、資本と負債の状況も加味した上で人を評価できれば、キャッシュは生み出していなくとも資本を積み立てている人として再評価することが可能になります。
技術的負債に立ち向かうには、方法論よりも人の評価基準を変える必要があったのです。
上記のように多元的な指標で人を評価し、負債の増加を抑え、資産を増やしていくことが技術的負債に対する最大の対策であるといえます。
入れ替わった人が技術的連帯保証人ではなく、技術的遺産相続人になるような仕事ができる環境を整備するのが長期的なシステム運用において一番大事なこととなるでしょう。
現場をただ俯瞰しただけでは、キャッシングやリボ払いで上げた成果は目立ちますが、借金の利子で苦しむ人の苦しみは目に見えません。
目立つ成果だけを評価し続ければ、キャッシングは永遠と繰り返され、借金の返済は滞り、破産への道を突き進むことになるでしょう。
インフラおじさんやサーバントリーダシップのような地味で目立たないいぶし銀のような仕事を評価することが技術的負債に対抗できる最大の兵器となるのです。
技術的負債ではなく技術的遺産が残るようになれば、入れ替わった人が利子で苦しむのではなく利息で楽ができるようになるのです。