システム開発には、技術的負債、文書的負債、情報的負債の3つの負債がある


技術的負債はアジャイル開発の本を読んで知ったので、多分、ウォーターフォール開発関連の書籍ではなかったのだろうと思うのだけれど、誰が詳しい人いたら教えてください。


その技術的負債に関するブログとかを読むと人それぞれに負債として取り上げて書いているようなので、これといった決まりはないように見受けられるのだけれど。だから技術的負債ががが、なんて言うつもりはないのです。


技術的負債という言葉が出て来る前まで、いや確かな時期はわからないけれど、それより以前にこんなことを経験から感じていたものです。


ウォーターフォールでの開発プロジェクトは一般的に設計<開発>テストの比率で人員が増減するのはご存知のとおりです。もう少し正確に言えば、設計工程でも後半に向かって増加します。開発からテスト工程に移り、テスト工程も進捗するに従って人員はキーパーソンや維持管理を継続するなら、維持管理にアサイン予定のメンバを中心に人員をシュリンクしていきます。


この、人員が減っていくときに引き継ぎがイベントとして発生します。ここで、様々な負債が露呈することになるのです。ひとつは残るメンバが持っているスキルより広いプロジェクトとして必要なスキルをどのように巻き取るかというものがあります。例えば、インフラとアプリがあるときのインフラのメンバはひとりいればいい方で、そのひとりがOSからミドルウエェアまで面倒をみることになります。実際は、複数のエリアをカバーできる人が残されますが、それでも専門的に深く知っているところ以外も受け持つことになります。アプリだと、業務はわかるけどアプリ開発基盤はどうするの、みたいなことも出てきます。


どちらにしても、プロエジェクトの編成時のロール設計を縦割りすぎてロールとしての冗長化を考慮していないことから起きる技術的負債です。


アプリだと担当業務の機能はわかるけど、隣までわからん、ということもあります。でも、工程が進捗すればそうはいかなくなるわけで特にリーダクラスはあれもこれもになる。これを心理的に軽減したいから引き継ぎの際に文書を棚卸しさせたりする人が出てくる。いやいや、それだけ作ることにしたじゃんっていいたくなるわけです。


引き継ぎして抜ける方は。これは維持管理を意識した文書体系としての妥当性を見ていなかったから起きる文書的負債ということができるでしょう。


プロジェクトを推進している際によく見かける光景は、工程が終盤になればなるほど「どうしてこの仕様になっているのか」という経緯をだれも確信を持って言えないという現象に遭遇することがあります。このテストの結果が正しいか何を見ればわかる、みたいな。往々にしてメールを探したりするわけです。仕様検討会やレビューの間のメールのやり取りで決まっていることが割とありますから。こうした意思決定や仕様として決定するまでの検討資料などは成果物ではないためにプロジェクトとしてセンター管理されていることはまだまだ十分考え方が行き渡っているとは言い切れない状況かと思います。まあ、センター管理されていてもディレクトリ構成なんて個人が勝手に作ることが多いですから探すことが困難ですし。


こうした意思決定などのログを探すなど情報が散逸しているのは情報的負債の問題がプロジェクト開始から課されていたと言ってもいいでしょう。


技術的負債、文書的負債、そして情報的負債。これ、ほんとプロジェクト計画を立てるときから考えておかないといかんです。