古参プログラマーがいる。
彼は可読性を一切無視したアセンブラ育ち、力技で叩き上げたプログラマー。
腕は確かなのかもしれないが、一緒に仕事をしたくない。
彼が担当したプログラムのバグ修正レビューに参加することがあるが、
3000行にも及ぶ関数、経路複雑度が大きい関数を得意気に説明しだして、
参加者が全く理解出来ない状況になること日常茶飯事。
説明を聞いても、果たして本当にバグが直っているのか、
不安で不安で仕方ない。
事実、バグ修正が不適切で、さらに重大な不具合を出したことは数知れずだ。
会社では、プログラミング作法が基準化されており、
プログラムソースをツールでチェックすると
作法に準拠していないプログラムは警告される。
開発初期の時点で、それらの警告を修正し、見やすい礼儀の良いプログラムに
することで、保守や引き継ぎ者への負担を減らし、
またプログラムを部品として別プロジェクトにも使えるように資産化していく。
彼の場合、そんなことお構いなく、ひたすらわが道を行く。非常に迷惑だ。
さらに、設計書も記載が無い、もしくは、記載があっても分かりにくい。
図や表、フローチャートなどを使って、言葉は箇条書きで簡潔に書くのが、
通常の設計書なのだが、彼のものは、言葉が長文で記載されているだけで
何を伝えたいのか分からない。主語目的語の関係が滅茶苦茶なのだ。
恐らく、本人の頭の中には、ちゃんと設計書があるのだろうが、
それらをドキュメント化する際の、表現力、論理的文章力が著しく
欠如しているに違いない。
いまさら、指導をしようとしても、頑固一徹で受け入れてもらえない。
彼の作業成果物を理解するのにどれだけの人間が苦労しているのか？
このような人には早めに退職してもらうか、
配置換えしてプログラムを書かない別部署に異動して欲しい。
そうすれば、我々のストレスも減るし、残業も減る。
社員と会社にとって一石二鳥だろう。