「このシステムを作ったのは誰だ！ 出て来い！」
そんな切ない怒りの声がIT職場に響き渡る。
前任者、あるいは委託先が作った画面やシステムを変更・移行することになった。ところがあまりにも個性あふれる作りで、しかもドキュメントが残されておらず、どこからどう手をつけていいのか分からない。運用保守担当者は途方に暮れる。
ITシステムの「作り逃げ」は闇の深い問題である。過去に「作り逃げ」されたシステムは、現在の担当者の時間とモチベーションを奪う。いわば「未来の時間泥棒」だ。今回は罪深き「作り逃げ」の問題にメスを入れる。
後のことを考えず構築されたシステムで運用保守担当者が苦労する
筆者にも経験がある。以下のようなシステムを目にしてぼうぜんとしたことが……。
- 設計書が残されていない（あるいは更新されていない）
- コーディングが雑（あるいは個性的過ぎる）
- 他システムとの依存関係が不明
- データを変更／抽出できない（本番環境のデータベースを直接触らなければならない）
- バッチなどの処理が煩雑
- ログを取得できない
挙げれば切りがない。このように、後のことを考えずに構築されたシステムは本当に厄介だ。運用保守フェーズで担当者が大変に苦労する。
例えるなら「洗い物を考慮せずに作られた自己流の料理」のようである。
「どや！ 腕によりをかけてごちそうを作ったぞ！」
「とてもおいしい！ 見た目も美しいし、素晴らしいね」
「……この大量の洗い物と生ごみはどうするのよ！」
あくまで筆者の経験を基にした主観的な見解だが、「作り逃げ」は「なんちゃってアジャイル」（雑に手早く構築することがアジャイル開発だと勘違いしている）なベンダーやエンジニアに目立つ。
彼ら／彼女たちには運⽤保守の観点がない。データベースやサーバー、ミドルウエア、ネットワークなどバックエンドやインフラの作りや動きを考慮しない。
こうして、今日もはた迷惑な「作り逃げ」が悪気なく繰り返される。「バックエンドの経験がないから」「インフラはよく分からないから」では許されない。未来のエンジニアの時間とやる気を返せ！
個性的なコーディングがIT職場の属人化とマウンティングを生む
問題はそれだけではない。「作り逃げ」されたシステムは、往々にして作りが個性的である。
開発者が独自の「オレオレコード」でコーディングする。厄介にもその手の「オレオレエンジニア」は自分の仕事に過剰に誇りを持っている。
「オレが書いたコード、すごいだろ！」
こうして後任のエンジニア、あるいはコードやアーキテクチャーをシンプルにしたい善意あるエンジニアの前に壁のように立ちはだかる。
