凄いエンジニアの困ったリファクタリング

プロジェクトでは納期があり、ウォーターフォールなら開発線表でリリース日を設定したり、見積もり可能な仕様かどうかで工程を分けて契約をしたりする。アジャイル開発であればイテレーションごとにリリースする。

何れにしてもプログラムはどこかのマイルストーンでリリースされる。

あるプロジェクトでとても優秀なエンジニアがjoinしていた。joinしていたと言うよりは、プロジェクトの目標を達成するためのプロジェクトチームとしてのスキルセットの重要なポジションを担うために引っ張ってきた。

このエンジニアが作ったプロダクトがあり、多分、50代のとあるクラスタなら誰もが知っているのではないかと思う。

ついつい、このエンジニアに難易度の高い開発テーマがを寄せてしまい、進捗がやばくなってTOCとアサイメントの見直しで乗り切ったプロジェクトがあったことは以前のエントリで書いた。

このエンジニアの凄さはなんとなく伝わったと思うのだが、いくら凄いエンジニアでも、いや、凄いエンジニアだからこそ常にコードを考えているのでコードをリファクタリングをする。

ここで問題が生じるのだ。

冒頭でプロジェクトはウォーターフォールでもアジャイル開発でも締め切りがあると述べた。それは必ずリリースするためだからだ。

一方、凄腕のエンジニアは常時コードか仕様を考えているので仕様を含め、閃いたらコードを手直ししてしまう。

金融のように構成管理や手続き、顧客とのレビュープロセスが厳密なプロジェクトでそれをやられると非常に拙い。なぜなら、コードを書き換えられてしまうと影響する範囲は全てプロセスをやり直しになってしまうからだ。

エンジニアの後ろ向きの考え方で、動いているものは変更するなと言う考え方があるが、リリースの手続きしたコードも触るな、なのだ。

もし、リファクタリングしたコードを差し替えたければ、別のテーマに抱き合わせでやる他ない。

こうした凄いエンジニアをコントロールするのは非常に骨が折れる。つまり、凄いエンジニアがプロジェクトに100％貢献しているかといえば、そうとは言い切れないのである。

まあ、進捗が前倒しだとか、もともとプロトタイプで作っていたのでプロダクションのコードとして置き換える約束だったとか、何かしらの理由がないと変えられないことが多いので理由を上手に作ってあげることも時々は必要だが。