なんだか難しいけどよく使われるエンジニアの用語を営業とかディレクターの仕事に当てはめてみた


なんだか難しいエンジニアが話している言葉ってよく分からない!

そんな話はよく聞きます。でも用語が特殊なだけで意外と普段みなさんが何気なくしている作業と同じような内容かもしれませんよ。ということで適当に抜粋したエンジニア用語を他の職種に置き換えたときにどうなのかをまとめてみました。

コードレビュー

自分が書いたソースコードをほかの人に見てもらって、指摘をしてもらうこと。主にコードの質の向上が目的ですが、僕は自分がやっている作業を他の人にみてもらうことで、作業内容の共有も兼ねていると思っています。

「コードの質」という表現がエンジニア以外にわかりづらいところだと思います。営業に例えると、営業トークもいろいろあって、そのトークの持って行き方によって、その後の結果が変わってきたりするのでそれに近いものかと思います。

なのでコードレビューは実際の現場に行く前に先輩と一緒にやるシミュレーションみたいなやつです。

 

ペアプログラミング(ペアプロ)

2人で同時に同じ機能をプログラミングしたり、同じ機能をさらに詳細に分解して、交互にプログラミングしてお互いの書き方を見たりすることです。同じ機能を自分以外の人がどうやってプログラミングをしているのかを見ることで、新しい発見ができたりします。

営業で言えば同行して同じ現場にいって、他の人の営業トークを聞くことに当たると思います。

 

リファクタリング

ここも「コードの質」に大きく関わってくる要素になります。同じシステム開発をしばれく続けていれば、最初は必要だった機能が必要なくなったり、同じような機能が追加されて本来は共通化されるべき箇所が共通化されなかったり、時代とともに過去の書き方では動かなくなったりするので、機能自体は変えずに中身のコードの書き方を変更することです。

営業のトークスクリプトとか利用規約とか営業用の資料は最初に決めると思いますが、時代背景や事業の形態とともに、気づいたら資料と営業トークに矛盾が出てきたりすることもあろうかと思いますので、大きく内容は変えず、言い回しを変更していくことにあたると思います。

ここは普段は問題が表面化しませんが、たまに見返さないとあとで痛い目をみるところですね。

 

テストコード

実際のコードへのインプットに対して正しいアウトプットが返ってくるかどうかのテストができるコード。テスト用のコードなので、本番の動きには影響は一切ありません。

ある一つの会員限定のファイルダウンロード機能があるとした場合に

  1. ログインチェック

  2. 検索パラメータチェック

  3. 検索

  4. ファイル生成

と、詳細機能に分解できます。(実装方法によってはもっとわけられるかもしれません)この1つ1つの機能をブラウザを利用してチェックするのは難しいし、面倒なので、1つ1つの詳細な機能のテストコードを書き、そのテストコードを実行することで動作が正しいかをチェックします。

ここはちょっと強引ですが、、、Wordなどでの文章校正やスペルチェック機能が近いでしょうか。入力した文章を自動である程度チェックしてくれることになるので質の担保ができます。

 

API

そろそろ例えるのが難しくなってきた・・・

他のアプリケーションのデータの取得・更新をするための規約。

ものすごいかいつまんで言えば、外部サイトのデータ簡単に取り扱えるようになる仕組み。

Amazonとか楽天とかで同じみのAPI。もちろんAmazon、楽天に限らないのですが。自分が作成したサイトにAmazon、楽天の商品データを表示させたいなーっていうときにAmazon API、楽天APIを使用します。

Amazon APIや楽天APIを使用するときは、実際Amazonや楽天のサーバ内でどのような処理を行っているかを意識する必要がありません。Amazonや楽天のデータを取得する部分の役割はAPI側におまかせして、後は公開されている手順に従ってプログラムを実装することで、自分が期待する値が返ってきます。

 

例えるなら・・・

何かしらの資料を作るときに、いろんなユーザーが利用しているブラウザのデータが欲しいなーとしましょう。(利用ブラウザは調べれば簡単にわかりまずが、ここでは、利用ユーザー自身以外はわからないものとします)

そんなとき、とあるリサーチ会社に「こういう情報が欲しいです」とお願いをします。すると内部でどんな仕事をしているかはあまり意識することなく必要なデータを取得することができます。

ここでいうとリサーチ会社にお願いをするところがAPIを実行するとこで、リサーチ結果のデータがAPIの返却値ということになります。

 

フレームワーク

プログラムをする上での決まりごと。この決まりごとにそってプログラムを書くことで誰が書いても比較的同じようなプログラムを書く事ができるようになります。

とあるテーマについて記事の依頼をライターにするにも、ある程度の見出しを決めて依頼するのと、まっさらな状態で依頼するのとでは作成されるものは大分違ってくると思います。

このある程度の見出しを決めた状態が、フレームワークにあたります。

見方によっては制限されているけど、しっかりしたフレームワークであればその分、質が担保されるし、あまり余計なことを考えなくて良いのでフレームワークになれればスピードの向上も見込めます。

 

フロントエンド

サーバから受け取ったデータを表示させるところ。HTML、CSS、Javascriptが担当。

営業でいうと、お客様先に出向いて実際に交渉をすること

 

バックエンド

フロントに渡すデータをDBから取得して、データを表示用に加工してフロントに渡すところ。PHP、Rubyなど。

営業でいうと、お客様先に出向く前の電話のアポ取りとか資料作りとか。

 

ライブラリ

いろいろなシステムを作成していると似たような処理をやっている箇所があるので、その部分だけを切り出して、その機能を呼び出すことでシステム間で使い回しができるようなもの。

世の中には既にいろいろなライブラリがあり、すごい人たちが公開してます。Rubyだとそれがgemと呼ばれているものです。エンジニア以外の人も名前ぐらいは聞いたことがあるかもしれない、jQueryもJavascirptのライブラリです。ただjQueryはライブラリとしてはかなり巨大なので、jQueryを使ったライブラリもあるのでJavascriptとごっちゃになってしまっている人もいる印象です。

営業だとなんでしょう。

どんな業界でも使える便利トークスクリプトといったところでしょうか。もしくは誰にでも通用する話のつかみのネタとか。。。

 

DB設計

データの構造を設計すること。そのままですね、、、

例えばECサイトであれば、

会員テーブル

  • 名前

  • 住所

  • メールアドレス

商品テーブル

  • 商品ID

  • 商品名

購入履歴テーブル

  • 商品ID

  • メールアドレス

  • 個数

みたいな感じでデータの構造を決定します。

意味合いはちょっと違ってしまうかもですが、事業の戦略を決めるところに近い作業だと思います。ここでの決定事項が後の作業に大きく影響を与えるので、先々のことも考えて慎重に作業をしなければなりません。

売上○○億円達成するためには、広告費を○○円かけて、流入が○○で、会員数を○人にする必要がある、みたいな感じ

 

詳細設計

DB設計をもとに、どうやってプログラムを組んでいくかの大枠を決めます。この辺は経験が長い人であれば、プログラムを実際に書きながらやってしまうかもしれません。

事業の戦略を実現するための戦術(施策)といったところでしょうか。

流入が○○必要であれば、Aに広告費○円かけ、Bに広告費○円かけ、LPとして会員登録用のページを用意する、みたいな感じ。

 

アジャイル

あるシステムを作るときに、いきなり1~10までの機能を盛り込まずに、最小単位で作成してリリースを進めていく方式。小さい単位とはいえ、リリースを前提で作っていくことが肝。

お試し掲載 → シルバープラン → ゴールドプランみたいな感じで徐々に機能が追加されていくイメージ。

 

Git

言わずと知れたバージョン管理ツール。バージョン管理についてはGoogleドキュメントなどでも仕組みがついているので、大分浸透はしていると思うのですが、後述するGithubとGitがごっちゃになっている人がいたりします。

手動でやる、ファイル名.20150921.txtみたいなバージョン管理をもっと手軽にできるようにしたもの。

 

Github

Gitの仕組みを活用して、プログラムを共有できるようにしたWebサービス。要はバージョン管理ができるファイルの共有サービスです。そのバージョン管理の方法としてGitの仕組みを使っています。

営業資料などは自分のところだけで更新してもしょうがないので、共有サーバに置くことかと思います。共有場所でのファイルを配置すると勝手にバージョン管理をしてくれるものになります。

 

プルリクエスト(プルリク)

開発環境で自分が書いたコードを、本体側に取り込み(プル)を要求(リクエスト)すること。先ほど出てきたGithubを使った場合には変更する場合に、いきなり変更せずにプルリクエストを出してコードレビューをしてもらい、OKがでてから取り込みをすることになります。(絶対ではないけど、そういう流れが一般的)

要はレビューお願いします、ってお願いすること。

 

Qiita

一般に公開されているプログラマーのノウハウ共有サイト。Q&Aのサイトではないので質問をするところではないです。「パフォーマンスを向上させるにはこういう書き方をした方がいい」とかそんな投稿があります。

Web業界のノウハウ共有サイトがもしあったら、

  • こういうメルマガ出したら、反応良かった

  • ボタンの文言を変更したらCVRが向上した

とかそんなのがあるイメージです。まあこの辺のはあんまり公開すると真似されてしまうし、基本的には隠したい情報になるので難しそうですが・・・

 

hogehoge

サンプルプログラムなどを組むとき、名前を決めるのが面倒なときに使われるやつ。意味は全くありません。不思議な言葉ですね。海外だとfooとかbarになるんだって。

あれですね、太郎くん、花子さん的なノリです。