属人化による『技術的負債』は誰も気にしない
まず、技術的負債とは何かを改めて確認しよう。技術的負債の検索結果の1番はQiitaである。でもwikipediaを参照する。
次に、誰の目線で技術的負債を見るか、を決めておこう。今回は、プロジェクトマネージャの視点でみる。このポジションは読み手の立場で変えて構わない。一度、自分の立場で見た後、一つ上の立場で見直すと差異を感じられるので、ぜひ試して欲しい。
技術的負債(英: Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である[1]。「設計上の負債(design debt)」とも言う。
1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。
プロジェクトマネージャの立場であるから『余裕のないソフトウェア開発が引き起こす結果』という文章に、戒めを感じなければならない。自分がキャリーするプロジェクトでは、それを引きおこなさない手段を講じているとしても。
最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる[2]。
引用 同上
よくないものを作るとそれ自身が足枷となり、開発チームの首を絞める。まあ、誰がそれをつくるか、ということである。
あと、引用での負債そのものは、コードなりの成果物として存在するが、実際には、誰が作るかという根本原因=人という事実まで踏み込む必要があるのではないか、と思うのだが。
そうした原因や諸条件に引き起こされる事象として表された結果を目の当たりにして立ち竦んでいるのではないだろうか。
その他にも、技術的負債の例として、組織で共有されない知識や、複雑すぎて変更が難しいコードなどがある。
引用 同上
技術的負債のバリエーションについて述べられているとおり、世間はそうした共有されない個人の経験知をいかに引き継げるように仕組みを考えて来た。一つの現れは、ナレッジシステム(死語)であり、組織のポータルサイト、リポジトリ、技術伝承のための仕組みである。
ではそうした取り組みでの成果はあったのだろうか。
結論から言えば、ナレッジシステムに代表される業務上の情報共有のデファクトがないことを見れば、個々に得られた知は蓄積し続けることはなく、活かされることも無い。
局所的、一時的にはあるが、組織として、継続しては活かされない。
なぜか。
知を有している個人において、各自で持っている知を他人にとって価値のあるものであると認識しないためである。それは、当人は自然に身につけたものであり、知を持っている本人にとっては付加価値を感じないためである。
さらに言えば、その知を第三者が認知することがないためである。それは当然で、知を持っている人がその知に価値を認知しないのだから形式知として現れることががない。よって、視界に入らないのだから、第三者には触れる機会がない。
よって、形式知は一向に共有されないし、強制的に知を出すことを求められなければ続くことはなく、消えていくのである。
で、『属人化による技術的負債』である。
上述を踏まえれば、プロジェクトチームの中で行なっているのは情報共有である。情報共有が行われるのは、SOWによる役割分担である。チームとしてのスキルセットを満たすために、技能を持つエンジニアを招集し、役割をアサイメントする。
そこで起きるのは小さなチームであっても役割で分断される縦割りである。その結果、情報は個人に属し、成果物もまた個人に属することになる。
プロジェクトが時系列を追うごとに増減する計画とした時点で無条件に属人化による技術的負債を生じることになる。それは前述した理由による。
では、道幅が同じであればそれを防止することができるか。
できないだろうし、ある対策を行えば防止することができる。
それは、役割において正副の担当をつけることである。なんてことはない。成果物に対する冗長化を行うことである。先に述べたとおり、原因は個人に情報を属させることなのであることから、そうしない策を最初からコストを支払い対策をしておく他ない。一つ、良い意味での副作用がある。それは開発を止めないという効能である。
この策をできないと頭から否定するのであれば、一生、属人化による技術的負債をしらってくれればいい。
なあに、あなたが支払うのだから誰も気にしない。