ども、LAPRASで働く中島（@nakashimayugo）です。

人事向けのエンジニアリング学習＃5のテーマは、採用の起点になりやすい、開発にまつわる表現です。

エンジニア採用では、「Python」のようなプログラミング言語名や「AWS」のようなサービス名など、技術的な専門用語がたくさん出てきますが、それに加え、「リファクタリングする」や「技術負債がつらくて」といった表現もよく出てきます。

これらの表現（動詞や言い回し、名詞）は「なぜその採用ポジションを採用したいのか」といった、採用ニーズの発生源である開発の課題に関するものであることも多く、採用担当者であれば知っておく必要があります。

しかし、プログラミング言語名や具体的なサービス名などの固有名詞に比べると、”なんとなく意味が分かっているようで、分からないまま聞き流していた”ということが多いのではないかなと思っています。

ということで、いくつかの表現や用語を紹介していこうと思います。もちろんこの記事で紹介するもので網羅できることはないですが、もし知らない表現があれば、ここにあるものは抑えておくようにしましょう。

●技術負債を解消する

技術的負債とは、ソフトウェアの機能開発に伴って発生するバグや設計上の問題などの総称です。開発を進めると必ず徐々に溜まっていくもので、技術負債を放置すると、開発速度が低下したり、設計が汚くなったり、場合によっては取り返しのつかないバグが起きたりしてしまうこともあります。技術的負債は誰かの”ミス”というわけではないので、新機能を開発したりしつつ、並行して過去の開発の技術負債をどんどん返済していかないといけません。比較的経験が浅いメンバーが、「とりあえず動くものを」という開発を進めていくと、ユーザーが増えたり、機能が増えたりした際に、あとでめちゃくちゃ大変な改修をする必要が出てきて、最悪ゼロベースで作り直す方が早いとなることも。。

▼テトリスに例えるこの記事は面白かったです
https://gigazine.net/news/20190322-technical-debt-tetris/

●リファクタリングする

リファクタリングとは、ソフトウェアの機能やインタフェースを保ちつつ、設計を改善したりレスポンスを速くしたり技術的負債を返すために内部構造を変更することを指します。ざっくりとは、サービスの動きを変えず（止めず）コードを綺麗にすることです。プロダクトの機能や利用ユーザーが多くなるなどして、「このまま開発を進めていくとやばい！」となったときに必要になります。

▼参考
http://objectclub.jp/technicaldoc/refactoring/refact-what

●レスポンスを上げる

レスポンスを上げるというのは、サーバからの応答の「速さ」を改善したいということです。ほとんどのサービスで、LPや検索機能などがあるかと思いますがなかなかページや画像が表示されず、ずっとローディングアニメーション（画面上でくるくると円が回ったりするもの）しか表示されなければユーザーは離脱していきます。このレスポンスを早くするためにレスポンスを速くするためには、例えば画像の読み込みの回数を減らしたり、データベースへのアクセスの回数を減らしたりといった取り組みが行われます。（一例です）レスポンスタイム（リクエストを受けて返すまでの時間）をレイテンシと呼びます。

少し話が逸れますが、広告配信のアドテク系の企業であれば、ものすごい早い（ざっくりだな）レスポンスが求めれれます。インフラからアプリケーションまで様々なレイヤでの最適化が求められ、経験や専門性、幅広い知見が必要になります。

▼合わせて読むとよいかも
https://developers.cyberagent.co.jp/blog/archives/12746/

●スループットを上げる

スループットとは一定の時間でどれだけ処理できるか（処理能力）です。例えば何かのECサイトで、「年度末の割引キャンペーン」を開催したとすると、キャンペーン期間中は普段より多くのユーザーが来ますよね。一定の時間で多くのリクエストを処理しならないときに必要な考え方で、分散・並行処理が取られたりします。処理するコンピュータの脳みそや作業台を分散して（増やして）同時並行で処理を進めるイメージです。

●拡張性を高める

拡張性とは、ソフトウェアに新たな機能を追加したり性能を向上させたりする際に、小さな変更で済むようにしたり、既存機能に悪影響を及ぼしにくかったりする性質のことです。最近のサービスでは一度作って販売（納品）して終わりではなく、常にアップデートしていくことが一般的です。またtoC向けに作成したサービスを、一部のデータを共有しつつToB向けに展開する（逆も）といったこともあります。こういった場合、データベースをはじめ、継ぎ接ぎの設計ではどうしても無理が生じてしまいます。例えば営業社員向けに作った評価制度を、広報の社員に適応しようとしても無理が生じることと同じです。その為今後機能やサービス拡張が予想される場合は、それらに対応できるように設計を行うことが重要になります。一方でどんな拡張があっても対応できるようにするということは不可能ですし、こだわりすぎれば開発スピードも落ちます。その為ある程度トレードオフで開発の方針を決める必要があります。

●保守性を高める

保守性と拡張性は同じ文脈で語られることも多いですが、保守性はエラーの発生源を突き止めたり、エラーが拡大しないようにアーキテクチャを工夫したりして高めます。プロダクトの立ち上げ期などは早く作って、受けなかったら別のモノ、別の機能を。といった開発の速度が求められますが、ある程度利用ユーザーが増えてくるとサービスを止めたり、大きなバグが発生しないよう安定性も重要になります。そういった場合保守性の高い設計や開発が求められることになります。

少し話が逸れますが、システムやサービスの運用・保守では、システムがストップしてしまうような大きなバグが発生してしまう前に異常検知を行う目的などで、様々なデータを取得し、動きをモニタリングできるようにすることで、システムが正常に動いているかをチェックしたりします。そしてそのために分析やログ基盤を整えることがあり、それを行うためのサービス名もよく採用要件で見かけます。このような用語をみたときに、そもそも今のプロダクトが何を求めているのかを意識すると、採用するエンジニアの志向性ややりたいこととのすり合わせもしやすくなるはずです。

●まとめ

さて、後半はもう疲れてリンクも貼れませんでしたが、ここで紹介した6つの表現の中で”なんとなく意味が分かっているようで、分からないまま聞き流していた”ものがあれば抑えるようにしてください。

例のごとく細かい整合性を気にして書いているわけではありませんので、間違いやもっとよい解説があれば是非教えて下さいね！

本記事の内容を含めた採用担当者向けの技術用語本を発売しました。
こちらもぜひ見てみてください。