「技術力」の解像度を上げる

こちらのイベントで登壇させていただくことになりまして、その前段として考えをまとめます。
https://lapras.connpass.com/event/185212/

※主にソフトウェアエンジニアの採用担当者をターゲットとした内容です。

さて、「技術力の高いエンジニア」（この記事ではアプリケーションエンジニアを想定します。インフラエンジニアやQAエンジニア、SREなどは含めません。あしからず）とは、つまりどんなエンジニアを指すでしょうか。イメージしやすいのは「特定のプログラミング言語を自由自在に操れる人」があるかもしれません。しかし、エンジニアに求められる技術力は、プログラミング言語による実装力だけではありません。人事担当者の方も、なんとなくそんな認識はされている方は多いと思いますが、じゃあどんな能力があるのか？ということを書いていきます。

開発のプロセス

通常、エンジニアは以下の流れで開発をします。

1. 要件定義
2. 設計
3. 実装
4. テスト
5. リリース
6. 保守

プロセスでみても実装は一部です。また、時間でみると実装に要する時間は通常2割程度と言われます。5割以上は要件定義と設計が占めるでしょう。ここを失敗すると、どんなに美しいプログラムを書いたところで、価値のないシステムが出来上がってしまいます。

「これってウォーターフォールでしょ？うちはアジャイルだよ！」という方もいらっしゃるかもしれません。しかし、本質は同じです。いきなり実装するということはありません。

ただ、細かい追加開発や不具合の修正などの場合は実装の比率は少し上がるでしょう。

いずれにせよ、実装は開発の一部であることがイメージできるかと思います。

では、要件定義と設計のフェーズと、実装のフェーズで担当者が分かれていたら、実装スキルだけが重要になるのか？答えはイエスです。が、前提に問題があります。フェーズで担当が分かれることで、課題が発生することが多いためです。物量は多いが仕様としてはシンプルなシステムであれば成功するかもしれませんが、たいていは実装フェーズに入って設計の課題に気づき後戻りする、ということが発生します。担当者が分かれているとコミュニケーションのコストが増大し、デスマーチが訪れます。

要件定義、設計のスキル

要件定義と設計がいかに難しいか、どんな技術があるのか、について説明するのは難しいことです。しかし、以下の例からイメージはしやすいでしょう。

・料理のレシピを作ることは、そのレシピに従って料理をすることよりも難しい。
・プラモデルの設計を考え、設計図を作ることは、その設計図に従ってプラモデルを作ることよりも難しい。
・注文住宅を、その家主の情報をヒアリングして間取りなどを設計し、適切な素材や部品を選び、図面を作成することは、その図面に従って家を建てることよりも複雑だ。

この要件定義、設計のスキルをどう見定めるか？こればっかりは熟練のエンジニアが面接で深堀りするか、インターンや体験入社などの形で実際のシステムに一定期間携わってもらうでしかないかなと思います。

実装のスキル

実装についてよくある疑問は、言語ごとの差です。ひとつの言語に精通しているエンジニアであればほかの言語にも応用できるものの、特性や作法は大きく異なります。

大分類としては、2×3で分類ができるかなと思います。

・静的型付け / 動的型付け
・オブジェクト指向型 / 関数型言語 / 手続き型

たとえばオブジェクト指向しか経験がないエンジニアがいきなり関数型に挑戦するのは結構リスクがありそうです。

なお、実装の時間は割合としては2割程度と述べましたが、実装スキルはどう効いてくるのか？それは以下の3点に集約されるかなと思います。主観です。

・実装スピード
・システムのパフォーマンス
・保守性

状況によって、どの特性を重視するかは大きく異なります。既存のシステムは安定していて追加開発がメイン、という場合は実装スピードはそこまで求めず、保守性の高いプログラムを書けるエンジニアだと嬉しい、ということになるでしょう。

このスキルをどう見定めるか。実装スピードとシステムのパフォーマンスについては、コーディングテストなどである程度は機械的に測れるでしょう。ただし保守性については点数をつけられるものではありません。これもエンジニアがインタビューする必要があるでしょう。

まとめ

・エンジニアの技術力には、実装以外にも要件定義や設計のスキルが必要。また要件定義や設計のほうが重要。
・要件定義や設計のスキルはエンジニアが見定めるべき。
・実装のスキルは、一部はコーディングテストなどで測れる。測れない要素もある。