「このコード、消していいのかな」
「それ書いた人もういませんよ」
というやりとりからみる暗黙知の弊害について考えます。
この記事の内容は、お題化しています。
状況
使って無さそうなソースコードがあるが、すでに運用中で変更をミスしたときの影響範囲が大きい。
そのコードが存在する背景を知っているエンジニアはすでに退職済みで、
コードが残っている理由を把握することができない。
暗黙化の弊害
経緯がわからなかった場合の対応は例えば
- 周辺のコードや資料を洗い出し、どういった意味のコードか判別して不要そうなら各所のテストで安全を確認しつつ変更・削除する
- 色々調べるが確信を持てないので意味はわからないが運用中のシステムへの影響を避けるためにそのままにする
というような対応方法があるでしょう。
1の場合、そのコードが存在する経緯が形式化されていればより少ないコストで変更することが
できていたでしょう。
2の場合、「必要かどうか分からないコードを加味してコードを拡張していく」という長期コストの上昇があります。また、そのような状態のコードを継続してメンテしたいと考えるエンジニアは多くないため離職リスクがあがるでしょう。
どちらにせよ大きな被害を被ることになります。
体験談
担当者が情報を暗黙化したままいなくなったケースの実体験について思い出してみます。
難読化されたコード
あるシステムのリプレイスを担当したときのこと。
リプレイス元のある機能が暗号化されていました。
該当機能に関するドキュメントは存在しません。
コードが仕様なのにコードが読めない、という状況です。
担当者は退職済みで、経緯を引き継いでいる人はいません。
コードの一部のみ確認可能になっているような種の暗号化だったので、
一部のコードを手がかりに調査したところ、Webに掲載されている
とあるサンプルを流用していることがわかり、復号化に成功しました。
（成功しちゃだめな気がするけど）
この調査にはそこそこの時間を費やしました。
まとめ
忙しいから情報を残している暇があったら成果物を作って。
そういう場所に限って「忙しくない時」は訪れないものです。
暗黙知を形式化
この記事で紹介したような暗黙知の形式化をしていくために Sharain という手法を練り上げています。
Sharain (【ʃeəréɪn】)とは暗黙知を形式化するための手順です。
Share + Brain = Sharain です。
以下に関連記事をまとめています。
