あなたが業務に入ると、多かれ少なかれ評価される場面に遭遇します。
その際、どういう基準で評価されるのかを知らなければ、あなたはその評価を上げようがありません。
単にコードを早く書けることが優れたプログラマーかと言うと、そうではありません。
いくら早く書けても、バグがたくさんあれば修正に時間がかかります。バグの修正は工程が後になればなるほどやっかいなので、システム全体の品質を下げることにもつながりません。
反対に丁寧過ぎても問題です。
変数名でずっと悩んで字願をかけても仕方がないです。同じ品質のものであれば、早く仕上がるのが良いに決まっています。
では、プログラミングを評価するにはどのような指標があるのでしょうか。ここではQCDという考え方を紹介したいと思います。
Quality（品質）
1つ目は品質です。バグがないことや修正しやすいコードになっていることを指します。
バグの数についてはテストをしながらコードの長さと比較して、○行に1つエラーがあったなどの指標で評価します。
この数字は多すぎるのはもちろん問題ですが、少なすぎても問題になりえます。しっかりとテストをしたのかを疑われるということです。システムはバグがあって当然という前提で開発していくため、バグが少なすぎるのも実は問題です。
それに対して修正しやすいコードになっているかという点については、数値化する評価は難しいです。
スキルのあるエンジニアにレビューをしてもらったり、ペアプロをしてもらったりすることでベースの力として上げていく必要があります。
初めのうちは、QCDの中でもこの品質が一番大切な指標となります。
品質が悪いものは納品できないからです。コードの長さに対するテストケースの数とバグの数をもとに品質のデータを自分で取っていきましょう。
Cost（コスト）
2つ目はコストです。対象の機能を仕上げるのにかかった総コストを指します。
コストとして一番目に見えるものは、もちろんお金です。あなたの単価が時給1,000円だとして20時間を費やしたのであれば、2万円ということになります。
また、コストはお金以外も忘れずに計算する癖をつけておきましょう。
上記の例でも時間というコストをあなたは払ったことになりますし、新規参画者へのプロジェクトの説明やペアプロやレビューをするという教育コストもあります。
細かいところで言うと、電気代やパソコンやデスクなどを買いそろえる初期費用もコストです。
人によっては面白くないプロジェクトに入ることは心理的なコストになるかもしれません。もちろん、そのコストはプログラムの評価には含まれませんが。
これらをすべて含めてコストとして評価します。自分が何時間かけてどのような機能を作れるのかを数値化しておくことは非常に重要です。品質と同じくかけた時間等のコストもデータを取っていきましょう。
Delivery（納期）
3つ目は納期です。対象の機能を期限内に納品できたかを指します。
これについては納期を調整できるプロジェクトもあれば、ギリギリの納期設定をされているプロジェクトもあり、まちまちです。
ただし、納期の遅れが続くようだと継続して案件を受注することは難しくなります。
データを取ってどうこうするというものではありませんが、QとCを踏まえて納期をいつに設定すれば良いのかという見積もりをできるようになる必要はあります。作業開始前に立てた見積もりもデータとして取っておきましょう。
この3つの指標は新人の教育でも良く使われます。こまめにデータを取り、少しでも良くするためにはどうすれば良いかを日々振り返り、その改善策を実行していきましょう。
