Introduction
こんにちは。trackチームの新田です。
エンジニア採用において、「いかに優秀なエンジニアと出会えるか」「自社で活躍するエンジニアをどう見極めるか」といった部分で頭を悩ませている人事の方もいらっしゃるのではないかと思います。
その中で、例えば
スキルチェックでとてもいい評価だったのに、あっさり現場（エンジニア）面接で落とされてしまった
一見、技術力が高い優秀なエンジニアを採用したのに、チームで全く活躍できなかった
なんていう経験はございませんか？
弊社が提供しているtrackでは、得られたスコアや提出されたコードのレビューをすることで、求職者のスキルチェックの役割を担い、スクリーニングをより効率的におこないますが、採用マッチングはスキルマッチの他にパーソナリティマッチ・ビジョンマッチなどを考えなければなりません。
現場のエンジニアに「この求職者はスキルもパーソナリティも申し分ない！」と思わせるためには、人事側ではいかに技術者のパーソナリティを見極められるか、が重要になってくるでしょう。
そこで、当記事では、人事の方がエンジニアとの面接の際に必要なパーソナリティの見極めの参考として、技術面の優秀さだけではない、これからの時代にエンジニアがチーム開発をする上で必要とされている 思想や原則 を、よく知られている用語やプラクティスを交えて、ご紹介していきます。
Contents
1 チーム開発に必要とされる優秀なエンジニアの思考、KISSとは
1.1 Keep It Short and Simple – 単純、そして簡潔に
2 なぜKISSが求められるのか
2.1 プロジェクトが複雑化すると、開発スピードが落ちる
2.2 エンジニアにとってコードはコミニュケーションそのもの
2.3 コードは書くよりも読むことのほうが多い
3 技術力の高い人ほど陥りがちなソフトウェアを複雑にしてしまうアンチパターン思考
3.1 1.「新しい技術を見せつけたい！」
3.2 2.「この機能はそのうち多分必要になる！」
3.3 3.「コードを書いてしまったほうが早い」
4 “優秀なエンジニア”を採用するために、採用担当者が見極めるべき視点
4.0.1 関連コンテンツ
チーム開発に必要とされる優秀なエンジニアの思考、KISSとは
今回ご紹介するのはこの KISS（KISSの原則） という言葉です。
KISSと聞くと、一般的には甘酸っぱくロマンチックなものを想像されると思うのですが、エンジニアの世界では違う「KISSの原理」という用語として知られています。以下、WikipediaよりKISSの原則の引用です。
Keep It Short and Simple – 単純、そして簡潔に
KISS の原則 (KISS principle) とは、”Keep it simple, stupid” （シンプルにしておけ！この間抜け）、もしくは、”Keep it short and simple” （簡潔に単純にしておけ）という経験的な原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだということである。意味はそのままに余計な文字を省略して、”KISの原則”とする人もいる。
即ち、コードを如何に「単純に」「簡潔に」保つかという視点を最優先に考えることが重要であるという、ソフトウェア開発における一つの原則として知られています。
なぜKISSが求められるのか
プロジェクトが複雑化すると、開発スピードが落ちる
シンプルに保つことを意識せずに、闇雲に修正や機能開発を続けていくと、どんどんコードは複雑になり、どこで何が動いているのかを理解できなくなります。
更に、わかりづらいコードをなんとか動かすために修正を加えれば加えるほど、更にわかりづらくなっていき、最終的には、全く触ることのできないコード、になってしまう恐れがあります。
複雑化が深刻化することによって、「開発した人以外が触れないコード」になったり、最悪の場合「開発した本人もわからなくなってしまう」なんてこともおこりえます。
エンジニアにとってコードはコミニュケーションそのもの
肥大なコードに対し、少し足りなくてもいいぐらいシンプルなコードは、構成する各要素における「役割が明確」となり、読みやすくなります。役割が明確だと正しく動いているかどうかを確かめるテストも楽になります。また、読みやすくなることで誰でも理解しやすくなります。
そうすれば、エンジニア同士が実際の開発現場で余計な会話や質問をせずに済むため、コミュニケーションコストの削減になります。それにより、開発速度を保ちながらソフトウェアを長期的に開発していく事に繋がります。 コードを単純に簡潔にすることで、「読みやすく・理解しやすく・修正が容易」なソフトウェアを構築することができます。
まさにエンジニアにとってコードはコミニュケーションそのものと言えるでしょう。
コードは書くよりも読むことのほうが多い
エンジニアの仕事って「コードを書くこと」だと、考えられている方が多いのではないかと思います。
しかし、実はエンジニアの1日の仕事内容を分解してみると、
コードを書く << コードを考える <= コードを読む
だったりします。 書くことよりも考えたりコードを読むことが多い仕事の中で、コードを単純にシンプルに保つことのほうが、よりチームでの開発効率を保つことに繋がります。
つまり、チームでの開発速度を保ちながら、適切なタイミングで必要な機能改善を繰り返していくためには、この「KISS」の思想が重要なのです。
技術力の高い人ほど陥りがちなソフトウェアを複雑にしてしまうアンチパターン思考
では逆に、一体どのような思想や考えが、ソフトウェアを小さく保つ妨げになってしまうのでしょうか。
初心者よりも実は経験を積み重ねている中級者や技術力の高い人ほど、ソフトウェアを複雑にしてしまう陥りやすいアンチパターンをご紹介します。
1.「新しい技術を見せつけたい！」
新しい技術や自分が身に着けた技術をプロジェクトで発揮したい！という想いは非常に重要なことですが、過度に技術志向が強い場合、コードに無駄が出てしまう可能性があります。
新しい技術を利用することが目的化してしまい、無駄にソフトウェアを大きくしてしまうのです。
技術そのものに囚われず、シンプルにソフトウェアを保つためには、
コードは自分の頭の良さをアピールする場所ではないと理解をすることが重要です。
2.「この機能はそのうち多分必要になる！」
今の計画上は必要ないかもしれないが、もしかしたら将来的にこの機能やコードが必要になるだろう、と考えてコードを複雑にしてしまう可能性があります。
開発経験がある場合、過去のプロジェクトでの経験から、どうしてもリスクヘッジのために予め余分な機能を作りたくなってしまいがちです。
しかし、そのような場合に限って、プロジェクトの方向性や開発優先順位の変更によって、いつまでも使うことのない機能になってしまうケースもあります。
本当に今、改善に必要なものだけに集中してどのように開発するかという視点が重要です。
3.「コードを書いてしまったほうが早い」
これもより技術力の高い・あるいは自分の技術に自信のある人にありがちなケースですが、慎重に議論や検討をする前に、「とりあえず書いてしまおう」というケースがあります。
「コードが書くほうが簡単だ」と考えてしまうと、無駄なコードを生みやすくなってしまうことにつながってしまいます。
必要な要件を決めるのはユーザ（クライアント）であり、エンジニアではない。
エンジニアの使命はソリューション（適切な解決策）を提供することであることを念頭に置く必要があります。
“優秀なエンジニア”を採用するために、採用担当者が見極めるべき視点
いかがでしたでしょうか。
今回はエンジニアとして求められる思想・原則を、その理由やアンチパターンとあわせてご紹介させていただきました。
少し専門的な要素が多かったかもしれませんが、いまエンジニアに求められるのはコーディング力や技術力の高さだけではありません。
エンジニアという仕事において、チーム開発を進めていく上で、求められる思想や原則はたくさんあります。
自社のエンジニア採用面談の際に、求職者がこの
「Keep It Short and Simple」
の思想に当てはまっているかどうか、見極めてみてはいかがでしょうか。
