復職後は会社で退屈なリファクタリング作業を一人でずっとやってきた。
この一人というのは逆説的な「最小チーム」だと思っている。その一人チームのなかでかってな想像野のもと仕様を策定して実装していく作業の繰り返し。
結論から言おう。
こういうった作用形式ははオススメしない。知識が属人化するる。知識のドキュメントをつくったとて、どこまで読まれるか、理解を深めてくれるかはコントロール不可能。
でも、一方でこうも言える。
「自分が属人化している。その中で誰よりも最高のパフォーマンスを出せる」
という、この時にその状態を続けるならば、真っ先に考慮するのはいま自分がしている作業が他のメンバーができるかだ？
言ってしまえば、同じ品質で引き継げるか、である。独善的である問題に対するソリューション（≒成果物＋運用手順）を作り、運用メンバーに「引き渡すことが可能か？」ということを考えなければならない。
PMBOKではプロジェクト成果物はプロジェクトチームがつくった資産（ソースコード、ドキュメント等）は運用チームに引き渡され、それが「運用」されることによって価値が発生する、といっている。これにはレガシーシステムを扱っているオレとしては120％同意である。逆に何を心配しているの？ときになっている方もいるだろう。実は「プロジェクト」というものは関係内のなかでも優秀なエンジニアが対応する。それが終わると、ジュニアエンジニアが「運用、保守」をまかされることになる。スマートに機能をみたす実装をしたプロジェクトチームメンバーと、今後その機能が続く限りメンテしつづける保守メンバー。この間にあるモチベーション、個人的なモチベーションの熱量の差などは組織において表面化されない軋轢として記録される。つまり、若手の離職、ボイコット... などだ。
実は最近、わたしもその引き継がされる側にたったことがある。エリート、上級職員が実装し、ユニットテスト、機能テスト、統合テストが完了し、リリースされる機能が、プロダクションとして運用し始めるにあたり、いきなりわたしたちの運用、保守対象になったのだ。別に初めてのことではない。でも筋が違っている。引き渡すつもりながら、引き渡すためのドキュメントは最低限必要だ。
思った。オレがおかしい。常に引継ぎにおいて仕様書、運用手順書、運用に関するQAのミーティングがあると思うな。ソースコードだけが真、ドキュメントなど役に立つだろうか？ 仕様書は必要で、ドキュメントも必要だ、とオレは誰が否定しても言う。ソースコードに意思はない。意思の結果、出力されたのがソースコードだ。だからそれを作ったひとの言葉を聞かねば、障害の「善し悪し」すら判別がつかないのだ。これを残ながら、というコンテキストではいいたくない。実装者が運用を何も考えていないアホだったから、という正しい言い回しで説明できればと思っている。
オレはコードをコツコツなおす。あの人の、プルリクエストは間違っている。オレのプルリスクエストも間違っている。
自分が完全に正しい訳じゃないと知りつつ書いたコードは多様性に書く。
受容可能な窓は大いに越したことはない。いまその窓が役に立つか立たないかは関係ない。
窓は将来の可能性だと思う。
