プロジェクトをひと通り終えて

昨日、お客さまに納品した。ある意味、一区切りついた。
これから、お客さまが受け入れ試験を行うので正直油断はできないが、振り返りする上ではいいタイミングではないかと思った。

以下、気持ちを徒然と書いています。テクニカルな情報などは記載していませんので悪しからず。




今回のプロジェクトで自分の心に残った悔しい言葉がある。「生産性が悪い」という言葉だ。
プロダクトコードの規模の割には人手が掛かりすぎているという。
確かに数値だけ見れば、指摘の通り。
今回は、フレームワークや共通化を図って規模を少なくしてくださいというお客さまの要望があった。
共通化や抽象化をすることで、プログラムの難易度が上がる。
しかも、フレームワークを使用する、ソースコードを自動化するなどして規模を抑えた。
しかし、上司は自動化した部分も含めて規模として認めてくれなかった。
規模を減らすために努力した結果が「生産性が悪い」という言葉につながった。
非常に残念で悔しい。

規模を減らした結果、試験の工数が減るかどうかといったら何も工夫しなければ試験の工数は減らない。むしろ、単位規模あたりの試験工数は増える。
比較対象が、過去の非効率なたくさんのコードであるならなおさらだ。
徒競走する際に100メートル走と300メートル走でかかる時間が同じかどうか比較しているようなものだ。

規模が減ることに比例して工数を削減できるとは限らない。
開発現場を直視している人であれば理解してもらえるのだが、単純に集計した数字でしか物事を判断できないようでは、同じように社内で開発している人にとっては、先が思いやられる。
ただ、上から規模ではなく、工数を減らすための工夫を求められているのも確かだ。
工数を減らすために何をすべきか、これは自分にとっての新たな課題だ。

ただし、自分にとってたくさんの成果があったことも確かである。

・ リスクの高い新技術、アーキテクチャを採用したこと
その際にさまざまな数値を記録することができた。
新技術を導入する場合、何をどこまでする必要があるか分かった。

一番の成果は、自分にとってこのしんどいプロジェクトをやり遂げたこと。
そして、これからこの成果を元にさまざまなエンジニアの方と情報交換ができるのではないかと考えている。

これから、自分の策定したアーキテクチャを使用したプロジェクトの第二弾が始まる。
それは、今回リリースしたシステムとは別のプロジェクトだ。
ゴールデンウィークまでまた、家に帰らない日々が続く...