職場で、すごく知識はあるのになぜバグが多いのだろうというエンジニアがいて、エンジニアとしての価値の指標はなんだろと考えてみた。
そして、私の頭の中で、大まかに以下の６つにまとめてみた。
- 業務の理解
- 技術に対する知識
- 保守運用性の高い（可読性の高い）コードの実装力
- バグが少ない
- コーディング速度
- アルゴリズム力
それぞれ、活動しているフィールドによってどの軸に強いとか弱いとかあると思う。たとえば、言語を開発しているエンジニアにとってみれば、その言語が正しく動くためのアルゴリズムを実装できるかというのが大事な要素になってくるし、会計システムに関わっているエンジニアであれば、会計の知識（業務知識）は必須のものであると言える。
各軸について、簡単に説明したいと思う。
1. 業務の理解
業務の理解は、上位レイヤー（要件定義・外部設計など）に関わるエンジニアであれば、これができないと実装まで落とし込めないし、メソッドを作るにしても、メソッド名すら名付けるのが難儀になってくる。古くからのSIerでは、業務を理解していなくても与えられた仕様書に沿って実装してしまうかもしれない。しかしそれでは、その仕様書が本当に業務に沿ったものかがわからないし、それがバグの温床ともなる。SIerが炎上しがちなのは、実装がわからないSEと業務がわからないプログラマがシステムを構築することも一因であると思う。
2. 技術に対する知識
エンジニアであれば自分が使っている技術に関しての知識があるのは大前提であるが、全てを知っているというのは到底無理なので、今までの経験や自分の興味等により濃淡が生じる。例えば、Rubyエンジニアであれば、基本的なオブジェクト指向の考え方、Rubyが用意してくれている便利なメソッドたちを知っておくことは必要であるが、Cの実装までは理解しなくても仕事にはなる。とはいえ、内部実装を知っておくことは何らかの形で役にたつかもしれないから知っているにこしたことはないが、そこまでの知識は必須とはいえない。
3. 保守運用性の高い（可読性の高い）コードの実装力
究極的にいえば、逐次処理，条件分岐，繰り返しを理解していれば、望む挙動となるプログラムを書くことができるであろう。しかし、一つのメソッドがだらだらと長く、複数のことを行なっていたり、全然関係ないメソッドがあったりすると、後から読むと何をするコードなのか理解が難しくなる。
そうならないようにオブジェクト指向などの概念を理解し、プロジェクト毎のルールに沿って実装し、できる限り後から読んだ人が理解できるよに書くかが大事である。
また、あまり使われないトリッキーなコードを書かないということも重要である。少し挙動把握が難しくかつあまり頻繁に使われないメソッドをつかったりすると、その挙動の理解だけでエネルギーが消費され、それが要件にあった挙動なのかということと合致させる難易度が高くなる。できる限り、シンプルに記述するように努めるべきである。とはいえ、配列をforで回して代入して新しい配列をつくろうというのであれば、最近の言語にはmap関数があるのでそれを使わない手はないし、何が難しく何がシンプルなのかの線引きは難しい。言語の習熟度や時勢（流行り廃り）にも影響されるので、コードレビューなどを通じてチームとしての認識の一致をはかっていくべきであろう。
4. バグが少ない
バグというのは、必ず生み出されてしまう。これをゼロにするのは不可能に近い。しかし、バグをできる限り減らそうとする努力は怠るべきではない。
前述した、「シンプルに書く」 というのもバグを減らす良い方法の一つである。なぜなら、多くの場合、現実に求められる要件の方が複雑で移り気だからである。一見理不尽な要件が正しかったりする。一方でプログラムの方は完全に論理の世界であり理解すれば難しいことではない。現実の要件をコードからも読み取れるよう、できる限りシンプルに書くべきなのである。
バグを減らすというのは、言ってみれば、いかに全ケースを網羅できるかということにかかっている。数学でいえば、場合分けだ。二次関数の最小値を求める時に範囲がどこかによって最小値が変わる問題を解いたとことがあると思うが、それと同じである。一つでも抜け漏れがあれば、不正解となってしまう。このパターンが多くなればなるほどバグが生じやすくなる。このパターンをいかに網羅できるかがバグを減らす鍵となってくる。
5. コーディング速度
すなわち生産性だ。保守運用生が高く、バグが少ないコードを素早く実装できるエンジニアは強い。
6. アルゴリズム力
実は、業務システムを作るにあたって、アルゴリズム力というのはそこまで必要とされない。
昔の人は並べ替えをいかに速く行うかについて研究してきた。マージソート、クイックソートなどが考案された。
しかし、業務システムを作るにあたってはあまり重要とはならない。最悪、ループで回して一つずつ処理をおこなっていけばいいのである。それらの効率の良いアルゴリズムは、言語の中で実装され、私たちが知らないところで活躍してくれている。
また、特に近年は、ハードウェアの技術が向上して愚直に実装してもそれなりの速度で返ってくることが多い。札束で殴れば解決することも多い時代なのだ。
しかし、処理速度をあげたい！新しいロジックで機能を追加しなければいけないエンジニアはアルゴリズムをつくる力が必要になる。例えば、以前私はぷよぷよにインスパイアされたゲームを作ったことがあるのだが、４色揃えば消えるようにするのはアルゴリズムを書かなければいけない。ぷよぷよのアルゴリズムであればググれば出てくるので、コピペエンジニアである私は、コピペして使ったが（もちろん、理解をし、自分の環境に合うように修正は行った）、新しいゲームのルールであればエンジニアが自分で考える必要があるであろう。
私自身はというと、どちらかというと業務寄りのコードを、しかも短納期で仕上げることが求められることが多いので、業務の理解やコーデイング速度はそれなりに高い方だと思う。しかし、技術に対する知識はまだまだで、先輩エンジニアに教えてもらうことも多い。保守運用生に関しては、自分では評価しにくいが、同僚に聞いてみたいところ。バグもまだまだ多く、減らす努力もしているが、なるべく検知して大怪我にならないようなところで止めるようにしている。アルゴリズム力に関しては皆無といってよく、競技プログラミングは敬遠している。
