今回はこちらの本をアウトプットする。

私はエンジニア・デザイナー採用担当として働いている。
エンジニアとのカジュアル面談も担当しているが、自社で採用している技術やエンジニアの業務内容について、自信を持って紹介できない場面が多々発生していた。そこでこの問題を解決すべく、本書を開いた。
内容の理解のために学んだ内容をここでアウトプットする。

エンジニアリング知識が無いとどうなるか

採用業務ではエンジニアリング知識が必要な場面が多い。
求人票をはじめとした文字ベースでのやりとりや、実際に会って会話するとき、候補者体験向上のための社内エンジニアとのコミュニケーションするときなど必要な場面は多くある。
しかし知識がないと下記の3つの行動をしてしまう。

1. 重要な事柄の表現をぼやかす

候補者から技術的な質問があった際に具体的な言及を避けるような行動だ。その結果、候補者からは「何か隠しているのではないか」「急にきつい業務が来るのではないか」などマイナスの印象を持たれてしまう。特に優秀なエンジニアは少しでもマイナスの要素を見つけると応募しないしない傾向があり、重要な事柄の表現をぼやかすことは採用活動に致命的な影響をもたらす。

2. 「アットホームな会社です」のような説明に終始してしまう

この説明の瞬間、候補者からは「技術の理解がない会社なのでは」と感じさせ、その結果「エンジニアは働きづらい」「エンジニアの立場が弱い」「ビジネス職から要望がコロコロ変わりそう」という判断をされる。
大半の候補者はエンジニアを大事にしてくれる組織で働きたいと考えており、この希望が満たされなければ他社に流れてしまう。

3. 採用市場を無視した要件を作ってしまう

知識がなければ、現場から依頼された採用要件の妥当性や難易度が判断できない。現場から言われた通りの求人を作った結果、超人のような求人になってしまい、そのようなエンジニアが転職市場にいないために応募が一向に来ない状態になってしまう。

開発工程の理解を深める

ここではエンジニアがどのような業務を行なっているかを学んだ。開発工程は次のような順序で進む。

1. 企画・課題発生

背景の課題を把握し、改善のために開発が必要なのか？を考えるパート。例えば「Webサイトの取り扱い高が少ない」という課題があれば、それを改善するためにどんな開発が必要なのかというアプローチを行う。逆に「レコメンド機能が欲しいから」という理由で開発は行われない。開発は常に課題ベースで行われる。

2. 要件定義

課題が確かに存在し、それが開発によって達成されると判断された場合に行うパート。ここでは開発しようとしているサービスの、
・ターゲット（ペルソナ）
・目的
・機能
・納期
・予算・必要な人員
などを要件定義書と呼ばれる文章にまとめる。

これに加えて、先の例にあったレコメンド機能を作るのであれば、
・どんな仕組みを用いて開発するのか
・どのくらいの精度が必要になるのか
・機能をリリースした後にそれをどのように計測するのか
もここで決定する。

要件定義書は、開発の前提を整理して社内外に共通の認識を作るという重要な役割を持っている。

3. 設計

定義された要件を満たすための方法を考えるパート。
作ろうとしているサービスに対して、似たような既存のシステムを調査し、同じように作るのか別のコードを書くのかをここで決める。
ここで設計が決まればようやく実装に移る。

4. テスト

実装したシステムが設計書や仕様書の通りに正しく動作するかを確認するパート。ここでは単体テスト、結合テスト、受け入れテストが行われる。
・単体テストは画面や機能など小さな単位で正しく動作しているのか
・結合テストは一連の機能群が正しく動作しているのか
がチェックされる。

クライアントワークの場合は受け入れテストが行われる。ここでは発注側のエンジニアによって、サービスが正しく動作するかのチェックされる。

開発手法の理解を深める

開発手法は次の2種類がある。

1. ウォーターフォール開発
   水が上から下に流れるような一直線の開発手法で、開発の前工程が完了したら次の工程に移るという開発の仕方。品質が担保しやすいという特徴がある一方、1つの工程が遅れると後の工程に多大な影響が出ることがデメリットとして挙げられる。

2. アジャイル開発
   近年のWeb系企業で一般的になっている開発手法。小さい単位で開発し、未完成でもいったん動くシステムを作る。リリースしてユーザーに使ってもらってフィードバックをもらい、その後また実装・リリースを繰り返す開発手法だ。
   
   アジャイル開発の話になると「スクラム」「スプリント」などの単語が出てくる。

アジャイル開発の例

ここでは具体例を使って、アジャイル開発のメリットを紹介する。

後者の開発手法がアジャイル開発にあたる。この手法ではフィードバックによって開発の方向性を見出すことができ、顧客が必要なものを正しく提供できる。

アジャイル開発を実現するツール

1. CI/CD
   これはサービスのテストやリリースの作業を自動化するもの。
   アジャイル開発の浸透により、小さな粒度で仕様変更をして、フィードバックを得るというループを高速に回す必要が出てきた。テストやリリースはソフトウェア変更のたびに必要になり、こうした作業を自動化するCI/CDを導入することによって、アジャイル開発を効率よく進めることができる。

2. Terraform
   これはインフラの設定をコードで管理するツール。インフラの構築は手順書と呼ばれるドキュメントにまとめられている。しかし手順書の作成者と構築の作業者の認識が違うために、コミュニケーションの齟齬が起きる可能性が出てくる。
   
   そこで、Infrastructure as Code (IaC)という考え方が登場し、それを実現するのがTerraformというツールである。
   
   インフラの設定がコードで管理されていれば、手順書のように人によって解釈が変わることが無くなる。さらに、コードを使って自動的に環境を作ったりバージョン管理ツールを用いてインフラ環境の変更履歴を記録することができる。

ここまでで開発手法について紹介を行なった。自社ではアジャイル開発を採用しているが、具体的な期間や使用中のツールは不明である。いろんなメンバーにアジャイル開発についてヒアリングするのが良いと感じた。

その他用語

本書では様々な技術用語が紹介されている。
ここでは私がよく耳にする用語についてまとめる。

1. エディタ・IDE
   エディタはコード書くツール。IDE（統合開発環境）はエディタの機能に加えてコードのエラーの検知も行う開発環境である。

2. OSS(Open Source Software)
   OSSとはソースコードの改変や再配布が可能なソフトウェアのこと。
   再開発して再公開することが可能であり、技術を無料で共有することができる。LinuxやAndroidaなどのOSやRubyなどの言語、WordpressやMySQLもOSSの1つである。
   
   これに関連してOSS活動というものがある。これはソースコードを改善して、皆で進歩しようという取り組みのこと。エンジニアにとってOSS活動は技術力の証明と認識されている。OSS活動をするエンジニアのことを「コントリビューター」と呼び、有名なOSSコントリビューターはエンジニアの尊敬の対象になる。

3. ドメイン駆動設計
   ビジネス側とシステム側で共通の認識を作って開発していこうという思想のこと。

4. テスト駆動開発
   最終的な仕様や要素を先にテストコードとして記述して、そのテストを満たすように開発する手法のこと。

終わりに

本社では上記の他にも様々な言語やフレームワーク、DB、ツールの紹介が行われている。

全ての知識を得ようとするとキリがないので、
・自社が採用している技術
・なぜ自社がその技術を採用したのか
・採用したいポジションはどの部分を担当するのか
・それらの周辺で行われる業務はどんなものか

これらを自社のエンジニアに聞いてみることで、採用業務を効率良くレベルアップできると感じた。

本書を読む前に感じていた悩み

これからのアクション