エンジニアの「組織にまつわる用語」はアイディアの宝庫！ビジネスで活かせるエンジニア用語5選
エンジニアではないけれど、エンジニアの採用をしているみなさん。
エンジニアの用語ってすごく難しいですよね。
弊社では IT に特化した企業の支援をしており、 採用決定の半分以上が エンジニアの採用です。
その経験の中でエンジニア用語やその概念に多く触れてきたのですが、その意味や概念を知っていくうちに「この考え方ってビジネスにも活かせるのでは？」と考えることが非常に多くあります。
そのため、ポテンシャライトではいくつかの用語を業務に活用しているのですが、非常に論理的でうまくワークしていると感じています。
そこで今回はエンジニアの用語と、それをどう活用しているのかを5つご説明していきたいと思っています。
※あくまでも非エンジニアが、自分達のビジネスに活用できる方法にアレンジしていますので、本来の意味と若干異なります。ご了承ください。
1. アジャイル
アジャイルとは
直訳すると「素早い」「機敏な」という意味。
アジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進める。従来の開発手法に比べて開発期間が短縮されるため、アジャイル（素早い）と呼ばれている。
これまで、ウォーターフォール開発が主流でしたが、このアジャイル開発は近年ソフトウェア開発などで活用されてきました。
上の図でお分かりいただけた通り、アジャイル組織はフラットな組織体系です。そのため、ウォーターフォール型に比べ意思決定までの期間が短いです。
このアジャイルを用いて「アジャイル人事組織制度」を作成しています。
こちらについては、詳しいブログが他にございますのでそちらをご覧ください。
また、アジャイル開発には「スプリント」と「デプロイ」という用語も存在します。
スプリントとは
一定量の作業を完了させる際の、短く区切られた期間のこと
デプロイとは
プログラムを使える状態にすること
これらの用語も非常に勉強になります。採用のゼロイチを作り出しているのですが、アイディアが思いついたタイミングで「とりあえずやってみよう！」と動き出すケースが多いです。
ただ、エンジニアに習い、単にやるだけではなく1週間のスプリントでPDCAを回していくと決めて取り組んでいます。（スピードがものすごく早いです・・！）
2. ベロシティ
ベロシティとは
プロジェクトマネジメントにおいて、チームが作業を進める速度のこと
このベロシティを測る際に考えるべきポイントが2つあります。それは、1で紹介した「スプリント」と「ストーリーポイント」です。
ストーリーポイントとは
作業完了に必要な全体見積りを示す測定単位のこと。
これらを使えば、ベロシティを把握することが可能。
これをメンバーの「工数管理」に活用しています。
スプリントは1週間で設定し、ストーリーポイントは仕事内容を洗い出し、その工数を数値で表しました。そして各メンバーがどのくらいのベロシティを持っているのかを把握しています。
複数のプロジェクトが同時進行で動いており、誰がなにを進めているか、これまで正直明瞭ではなかったのです。またそのプロジェクトにかかる工数は、支援企業様の数やご料金によって判定ができるものではありませんでした。
そのためベロシティを用いて工数を数値化することで誰がどのくらいの業務量を抱えているのか、またどのくらい工数が空いているのかを可視化することができました。
いくつものプロジェクトが同時進行で進んでいることや、1週間のスプリントで仕事内容が変更することもある点が、エンジニアの仕事とうまく重なる点があり、このベロシティという工数管理方法がうまく当てはまったのではないかと考えます。
ベロシティの話に戻すと、新規お取引企業様のご支援を開始する際に誰をアサインするかや、どのくらいの工数が足りていないから、何人新しく社員を採用するべきなのか等を判断する際にも利用しています。
3. ペアプログラミング
ペアプログラミングとは
名前の通りプログラム2名体制で開発する手法であり、アジアャイル開発でよく用いられる。
同時にコードを書き上げるのではなく、1人が「ドライバー」として手を動かし、もう1人が「ナビゲーター」としてアドバイスをしながら進めるようです。
これを、「ブログのチェック」に用いています。
現在大体月に10本程度のブログを代表の山根や有志のメンバーが執筆をしています。
そのブログの質の担保のために、山根が全ブログを確認していますが、山根への負担が非常に大きかったのです。そこで初回確認としてこのペアプログラミングの要素を取り入れ、ブログをペアで確認していきました。
その名も、ペアブログラミングです！
ブログの確認なので、ペア”ブログ”ラミングと名づけています。
このペアブログラミングのポイントになるワードがもう1つ。それが、「コードレビュー」です。
コードレビューとは
ソフトウェア開発工程で見過ごされた誤りを記述者とは別の人が詳細に調べ、所感を開発者に伝えること。
そしてそのガイドラインをGoogleでは以下のように定めています。
これを用いて、ペアブログラミングガイドラインというものを作成しました。
それがこちら👇
このガイドラインをもとに、ペア同士でブログを確認しあっています。
4. SLIとSLO
SLIとSLOとは
- SLI ：サービス レベル指標
- SLO：サービス レベル目標
この単語はSRE（サイト信頼性エンジニアリング）の仕事においてよく見るワードです。SREのミッションはサービスを改善し、さらにユーザー エクスペリエンスを向上させることです。
この概念を取り入れ、クライアントの声を拾い、サービス改善やユーザーエクスペリエンスの向上施策に力を入れています。
また、ポテンシャライトには「Aim120」というvalueがあります。これは100の期待値に対して120の意識／姿勢を持つという意味です。このvalueがSLIとSLOの考え方に近いのかなと思います。
👇そして、このAim120を7つに分解してみました。
これを定量的に評価しているのが「NPS」（顧客推奨度）です。
導入している企業様は多いと思いますが、それを細かく分解しそれぞれの項目でクライアントに対しAim120を提供できているのか振り返りする時間を設けています。
Aim120を目指し、HR業界を凌駕できるような高いNPSを目指していきたいと本気で思っています。
おかげさまで新規の営業活動をしておりません。これまで、お問合せやお付き合いをしている企業様からのご紹介やお問合せでご支援させていただいています。
5. フィーチャーチーム
フィーチャーチームとは
特定の成果物を生み出すことを目的としたチームのこと。日本語では「機能横断チーム」。チーム内に必要な機能を揃え、複数のコンポーネントにまたがり、チームで「成果物＝動くもの」を作り上げることができるよう構成されている。
このフィーチャーチームを語る上で、覚えておくべき用語がもう1つあります。それは、コンポーネントチームです。
コンポーネントチームとは
コンポーネントチームとは、特定の専門領域での役割を果たすことを目的としたチームのこと。日本語では、「機能別チーム」。
そして、ポテンシャライトはコンポーネントチームではなく、フィーチャーチームを採用しています。
コンポーネントチームは、いわば「特定領域の専門家」であるため専門性を高めることができます。一方で、フィーチャーチームは特定領域以外の知見も身に付くというメリットに加え、何よりもそれぞれの個性を生かした組織になれるというところが大きいと思います。
もし仮に「コンポーネントチーム」を推奨する場合、「サービス」ごとにチームを分けているかと思います。
👆 サービスを大きく3つに分けています。本来であればこの3つそれぞれに法人があって良いくらいのサービスの大きさなのですが、すべてサービス提供が可能です。
また、社内を効率化させるためには、この3つのサービス領域ごとにチームを分けるほうが良いかと思います。ただ方針としてコンポーネント(上記でいうサービスごと)チームにはしていません。
皆さん、考えてみてください。
もし仮に皆さんが「 B 採用実務プロジェクト」のチームだったとします。その場合、目の前にいるお客さまが「採用ブランディングのサービスを受けたい」「人事制度を作りたい」と言うとします。その際に
「すみません、それは私の担当領域ではないので、別のチームに伝達しますね」
というのは悔しくありませんか？悔しいというより、目の前にいるお客さまはあなたがもっとも理解しているかと思いますし、あなたがBの支援も、AもCも提供できたほうが、あなたもお客さまも良いですよね。
繰り返しになりますが、AとBとCのサービス領域ごとにチームを分けて専門性を持たせたほうが、会社としては効率が良くなります。ただ、思想として、コンポーネントチームにはしないとジャッチしており(今のところ)、フューチャーチームでいこう、とジャッチしているのです（HR業界では割と変わっているかもしれません。HR tech企業はSaaSなのて、The modelを導入していると思うので、コンポーネントチーム寄りですよね）
また、ポテンシャライト組織OKRという
「採用担当チーム（社内ではhuman experience）」
「クオリティ管理チーム（impressive speed）」
などの複数チームが存在します。
もちろんオーナーはいるのですが、採用チームのみが採用することはありません。
最後に
ここまでエンジニアの概念をビジネスに活用した事例をご紹介してきました。こうしてみると、エンジニアの概念は活用すべき点が多いこと共感していただけたのではないでしょうか。
また、覚えにくい・意味を調べてもわかりにくい用語であっても、ビジネスに置き換えて考えると、理解しやすくなったのではないでしょうか。
今後も応用できるエンジニアの用語がありましたらアップデートしていきたいと考えています。
それではまた！
この記事が気に入ったらサポートをしてみませんか？