引き継ぎファーストという考え

このアイディアに至った背景

銀行やお役所では、主に不正回避のための人事異動があり、担当していた業務は数年で別の人に引き継ぐ必要がある。しかしシステム開発の現場では、なかなか引き継がれることがない。それはなぜなのだろうかと考察しみる。

定常業務とプロジェクト

システム開発は定常業務であることはまずなく、ほぼ全てがプロジェクトである。定常業務であれば、その引き継ぎは手順と現在仕掛かりの状況などを引き継げば済む話であるが、プロジェクトの成果物となると一筋縄ではいかない。プロジェクトとは前例のない繰り返さない有限な活動である。そのためその活動の中で発見、発明されたことや妥協などに至った背景など設計書やソースコード、運用時の設定だけではわからないような情報がたくさん発生する。つまりプロジェクトの成果物が大きければ多いほど伝えるべきものは多くなり、途方もない労力を割かないととてもスムーズに引き継ぐことはままならない。

引き継ぎ元と引き継ぎ先の能力バランスミスマッチ

引き継ぎ元と引き継ぎ先の能力値にミスマッチがあると最悪だ。設計書が読めないということはないだろうが往々にして必要十分な設計書が書かれることはこのご時世ではないだろう。そのためにもアジャイルソフトウェア宣言ではクリーンな実行可能なプログラムを作ることに専念するよう書かれている。
ビジネスロジックを中心にコーディングすることは、他のよくある処理はライブラリに任せることになる。フレームワークやこうしたユーティリティとなるライブラリに慣れ親しんでいなければ、いくら可読性の高いコードでも何が書いてあるか理解できない。