このNoteでわかること
- 生産性の考え方について
- 生産性の定義
- 生産性の上げ方
- 生産性の重要性
生産性とは
生産性は､以下のような数式で表すことがあります｡
- 生産性 = 開発の価値（成果物）÷ リソース（人､工数など）
やるべきことの方向性があっていないと､成果物の価値は0に近づくため､生産性は低下する｡また､価値はあるものの､それを開発するためのリソースが多すぎると､それはまた0に近づく｡
レイヤーごとの生産性
生産性は主に開発者､エンジニアに対して使われることが多いですが､3つのレイヤーがある｡
以下は､各レイヤーごとの生産性/成果物だ｡
- L1:開発チーム ･･･ ソースの改修量､CloseしたIssueの数など
- L2:開発組織 ･･･ 価値の提供
- L3:組織 ･･･ 売上､利益など
L1で開発されたものは､最終的にはL3へと移る｡L1の生産性が高くても価値の適用ができておらず､売上が立たない場合は､生産性は0となるだろう｡
リソースの種類
多くは､人や工数が当てはめられる｡しかし､その他にも
- 利用ツール､ライセンス利用料
- 広告費
- 教育費
など､それ人､時間以外にも､生産性に影響するリソースはある｡
プログラミング言語のバージョンなどもそうである｡古い言語やライブラリは情報量が少なかったり､便利な機能などが使えなかったりするため､それだけでも生産性は落ちるでしょう｡
流行りの言語のほうが情報量が多く､手間が少なくなるのも容易に想像がつく｡
最悪なのは､メンテナンスがされていない独自に開発された自社ライブラリだろう｡作った人がいればまだ良いが､外注されたものだったり､すでに退職していて詳しい人がいない場合などは目も当てられないだろう｡
生産性を上げるには
生産性を上げるとはつまり､以下のどちらかをすることである｡
- 成果物の価値を上げる
- リソースを少なくする
以下の2つについて､どのようなアプローチができるかを書いていく｡
方向性を確認する
開発を進める上での方向性の間違いを減らし､軌道修正しやすくする｡以下のタイミングで方向性について認識合わせする｡
- PdMなどから新規施策の仕様について相談を受けたとき
- 起票された開発Issueを最初に確認するとき
- 自分がIssueを作成するとき
5W1Hで使用用途を考えある
いわゆる､5W1Hなど｡その機能を｢いつ､誰が､どこで､なぜ､どのように｣を明確にする｡これらは要件として､PdMから提供されることが一般的だが､開発者側からも考えてから開発した方が良い｡
- ニーズはどの程度あるのか
- 代替案はないか
toBシステムでニーズが一部なのに､工数を数ヶ月使う場合などは多々ある｡個別案件として費用請求したり､代替案（エクスポート機能でデータを渡すからやってね)なども考えた方が良い｡
既存の機能で同じことはできないか｡
すでに提供している機能で要件を満たすことができないかを考える｡利便性などはあるだろうが､結果同じことができるのであれば､そもそも開発自体が不要な場合もある｡
シンプルにすること
いわゆるコピペなどで同じ機能が無駄に増やしたりすることで､その場の工数を減らすことはできるかもしれないが､煩雑なコードは後の生産性低下の原因になる｡多少工数がかかっても抽象化するなど､リファクタリングしながらシンプルな改修にする｡
ツールの選定・更新
先にも説明したが､情報が少ない言語や古いバージョンの言語､ライブラリというのは､それだけでリソースを多く使う｡
新しくするための改修が必要だったり､メジャーバージョンを更新すると､互換性がなく動かなくなる場合もあるが､特に問題なければ新しいバージョンを使ったほうが生産性は上がる｡
マイクロサービスなどで開発に関係ない時間を短縮する
JavaやC言語など､プログラムを動かすためにビルドを必要とする言語もある｡このような言語ですべての機能を同じプロジェクトに入れた場合､デプロイ・リリースするたびにすべての機能を再ビルド､テストされるため､検証・商用環境への反映で無駄に時間がかかってしまう｡
個人・組織の開発力の向上
今までのことを実施しても､結局は開発者の個々のスキルによって高くも低くもなる｡その組織内でスキルを共有し個々の開発スキルを上げていくことが重要になる｡
特に､始めたばかりの小さい組織だと､各々自由なスキルを使うことが多いため､バラバラのプログラミング言語やフレームワークを使い煩雑になりがちである｡
せめて､フロントエンド､バックエンド､DBなど､大枠では同じ技術を共有して開発できるようにするのが理想だろう｡
生産性の重要性
日々の開発で重要なのは言うまでもないが､開発者だけではなく経営層にもこれらは無視できなくなっている｡転職を考えているエンジニアをインタビューした際に､以下のような理由が挙げられている｡
- 8割弱は､生産性を重視していると答えている
- 生産性が高い組織のほうが､個人として成長できる可能性が高いと考えている
- 一人あたりの付加価値が高いため､年収にも影響している（と思う）
一言で言えば､開発体験が悪いと仕事の効率も悪いため､モチベーションが上がらず転職を考えるっと言うことである｡
売手市場のエンジニアを確保するために､生産性（開発環境）が整っていない組織は人材を確保するのが難しくなるだろう｡
まとめ
- 生産性について､個人的な見解を書いた
- 生産性はエンジニアだけの問題ではなく､組織､会社にとっても気にすべき指標となりつつある
- 生産性が低い組織と高い組織なら､高い組織が選ばれていく
コメント