Kyoji Osada

IT Engineering Semantic & Episodic Memory by Kyoji Osada at AiR&D Inc. from Tokyo, Japan.

一流エンジニアになるための Off-JT #6. エンジニアの生産性

エンジニアの生産性:はじめに

今までのポストでも、“生産性”という言葉を要所で使用してきましたが、このあたりでそろそろ、“エンジニアの生産性”をテーマにしようと思います。

さて、みなさんの中で、“生産性”を理解されてるという方は、いらっしゃいますでしょうか。
そして、“生産性”を根拠に活動されている方は、いらっしゃいますでしょうか。

一流エンジニア”と呼ばれるエンジニアさんは、この“生産性”を理解して活動されてる方は多いと思います。
なぜなら、“生産性”を理解し、“生産性”を根拠に活動できている事こそが、“一流エンジニア”と呼ばれる所以の一つだからでしょう。

では、“生産性”とはいったい何でしょうか?
そして、“生産性”を高められるエンジニアになるためにはどうすれば良いでしょうか?
このポストでは、“一流エンジニア”になるための“エンジニアの生産性”について解説します。

エンジニアの生産性:生産性とは?

そもそも、“生産性”(Productivity)とは何でしょうか?
売上や利益上げる事や、ものを作る事でしょうか?
便利な言葉のようですが、分かるようで分かりづらい言葉でもあります。

生産性”とは、経済学上では、かけた資本、資源、労働などに対して、どれだけの付加価値をなど生み、あるいは寄与ができるかの“効率”とされています。
分かりやすく言えば、同じ時間、同じ労力などに対し、どれだけの成果や価値などが生み出せるかという事です。
生産性”は、“アウトプット/インプット”(O/I = 生産性)の関係で表す事ができるとされています。
インプット”が時間や労力などであり、“アウトプット”が成果や価値などということになります。
この、“インプット”の対象と、“アウトプット”の対象となるものが重要になってきます。
これは言及の範囲や、組織、あるいは状況によって変わってくるでしょう。
もし、その組織の価値となるものが、売上高や利益なら前述の通りとなります。
また、売上や利益の手前、あるいは先にあるものを組織の価値とするならば、そのための“インプット”に対する“アウトプット”の“効率”という事になります。
そして、この数値が高いほど、“生産性”が高いという事になります。
(“効率”とは、単に“アウトプット/インプット”で表わせる度合いをいい、“生産性”の上位概念となります。)

エンジニアの生産性:なぜ生産性が必要なのか?

では、なぜ“生産性”が必要とされるのでしょうか?
まずは、企業側のロジックから解説します。

エンジニアの生産性:企業側の視点

利潤追求が使命である企業においては、原資をかける事で利益が生まれ、その結果、給与、報酬、福利厚生、環境改善、人員増員や増強、設備投資、企業買収、社会貢献などに更なる原資をかける事が可能となり、それによって更なる利益を生む事が可能となり得ます。
このような循環が、“事業成長サイクル”となり、企業の成長と継続に繋がっていきます。
初めはどんな企業も、その時点においてかけられるだけのミニマムな原資から始まります。

この“事業成長サイクル”の中で、どの時点の何を価値と表現するかは、企業によって様々でしょう。
しかし、ほとんどの企業の価値の本質を意訳するならば、おそらくその骨子はほぼ似たものになるのではないでしょうか。
それは
「より利益を生むことで、関係する顧客、商品、従業員やその家族、会社、株主、社会などのより豊かな発展を目指す」
といったところでしょう。
まずはこのあたりを理解していると、会社の目的、チームの目的、個人の目的がリンクしやすく、双方にとってより良い成果が生まれやすくなるかもしれません。
(ここでいうリンクとは、同じという意味ではなく、相互に繋がるという意味です。)

新卒の方でも中途の方でも、優れたビジネスマンは、会社に所属しはじめの頃から相互理解に努めようとします。
逆にそうではない場合、“個人のより良い環境”を望む割合が強くなってしまう傾向にあると、私は今までの経営やマネージメントの経験から思います。
言い換えれば、それがマジョリティーだと言ってしまえるのかもしれません。
しかし、全従業員がそれでは、企業はたちまち立ちいかなくなるのも事実です。
そしてこの課題は、本来はマネージャーのミッションとなるわけですが。

エンジニアの生産性:福利厚生

例えば、福利厚生などを例にあげると分かりやすいでしょう。
企業が福利厚生を充実させる目的は、どこの企業の幹部に聞いても、そのほとんどは“生産性の向上”という答えが返ってくるはずです。
それは、ファシリティ部門のトップでも、人事部門のトップでも変わりはないでしょう。
しかし世の中には、テイクありきのスタンスが存在するのも事実です。

デスクの椅子を例にとってみましょう。
例えば、エンジニアのために高価な椅子を会社が用意したとします。
しかしなぜ、わざわざ高価な椅子を用意するのでしょうか?
それは、従業員の個人的な自己満足の充足だけで終わってしまうような、一方通行の関係が目的ではないはずです。
確かに安価な椅子では、我々のように座って業務をする事が多いエンジニアにとっては、致命的な腰痛を発症しまねません。
その結果、午前中に通院を余儀なくされ、作業がはかとらず、終いには心身ともに疲弊してしまうかもしれません。
ひいては、会社の利益を下げる事にも繋がりかねません。
これでは、誰も得をしない負のスパイラルの関係に陥ります。
しかし、従業員の心身を配慮して高価な椅子を用意する事は、より“生産性”の高いアウトプットを期待するという、双方向な関係を求めるからこそでしょう。

これは、椅子に限った話ではありません。
なぜ、大型ディスプレイを用意するのか?
なぜ、社食を割引や無料にするのか?
なぜ、社内保育所や社内クリーニング店、社内ヘアサロンまで完備するのか?
なぜ、綺麗で創造性の豊かなオフィスを構えるのか?
なぜ経営者は、コミュニケーションが密になるようなオフィスの導線に拘るのか?

エンジニアの生産性:会社の永続

企業は、当然ボランティア団体ではありませんので、かけるコストによって、リターンがなければ、事業継続は不可能です。
もし、事業継続不可能となれば、顧客、従業員の生活、取引先、株主など、そのネガティブな社会的影響は、規模の大きい企業であるほど大きいでしょう。
したがって、これらの目的は、まずは利益の向上による“会社の永続”のために他なりません。
まずはこれが、利潤追求が使命である企業の原理原則であるのは周知の事実といえます。
しかし、この解説の視点は、あくまで企業側から見たロジックです。
ここで終わると、企業側の都合の押し付けに聞こえかねませんが、そうではありません。

エンジニアの生産性:顧客、従業員、株主からの視点

実は、個人の生活においても、似た側面はあるのではないでしょうか。
個人においても、コストをかける事でより良いサービスを受けたい、あるいは体験をしたいなど。
経済学上では、“生産”に対してこれらの活動を“消費”と言うようですが、これはあくまで一方向性の視点といえます。
ここでは、個人の“生産活動”という視点で解説を進めると、これも顧客側の“生産性”といえるでしょう。
これは株主にとっても同様であり、投資によってより良いリターンを望むものです。
そうです、“インプット”に対して、より価値の高い“アウトプット”を求める“生産性”なのです。
そしてこれは、従業員も同じではないでしょうか。
かける労力、時間、熱意などによって、より良い対価などを望む方は多いのではないでしょうか?
その対価とは、評価、環境、処遇、報酬、給与、地位、やりがい、など、いろいろあるかもしれません。
(“内発的動機”の重要性については、“エンジニアマネージメント”のポストで言及する予定です。) このように、顧客、従業員、会社、株主などどの立場であっても、お互いがコストに対する対価を得ている相互関係にあるということなのです。

エンジニアの生産性:生産性の本質

逆の例をあげましょう。
もしあなたが従業員として、どんなに労力と時間と熱意をもって良い成果を出しても、会社が正当な評価をしてくれなかったとすれば、あなたは会社に対する信頼が薄れていく事でしょう。
それは、企業も従業員に対して同じであり、株主も、顧客も同じなのです。
もし、あなたが顧客だとして、高額なお金を払っているにも関わらず、とても粗悪なサービスを受けたとすれば、あなたはその会社を信頼しなくなるでしょう。
この状態は、顧客の“生産性”を低めてるという、顧客にとっても会社にとってもおそらくは望ましくない状態といえます。
要するに、お互いの‘生産性”を高めあう事で、お互いのより良い相互関係を築く、これこそが“生産性”の本質ではないでしょうか。
こうして信頼関係を築き、その相互関係を発展させていくことで、社会における大きな循環関係にも、より良いサイクルが生まれていくものではないでしょうか。

ここから三つの例え話は Cig Break です。

Cig Break:贈り物の心

一つ目は、“贈り物の心”(Gift Haerts)です。
これまでの相互関係の話は、“贈り物の心”と似ています。
例えば、あなたがパートナーへ誕生日プレゼントを贈るとします。
パートナーが何を欲しがってるか、中には普段の生活から一生懸命読み取ろうとしてる方も大勢いらっしゃるかもしれません。
プレゼントを買いに行く前から買いに行った時も、いろいろ時間かけて悩んで、やっとの思いでプレゼントを購入しました。
みなさんもそんな体験をした事あるのではないでしょうか?
そして、パートナーへプレゼントを渡す。
「ありがとう!何で欲しいものが分かったの?」
と、パートナーが喜んでくれる事で、あなたは安心と嬉しさがこみ上げてくる。
そして、あなたの誕生日には、パートナーからプレゼントが贈られる。
そういうやり取りが信頼関係を強くしていく。

Cig Break:愛情貯金

もう一つは、“愛情貯金”(Love Savings)のお話です。
例えば、あなたは初めから“愛情貯金”が 10 あるとします。
そして、相手へ愛情をかけると、“愛情貯金”は等価で減っていくものとします。
ここでは、愛情 2 をかけたとすると、あなたの“愛情貯金”は 8 になります。
しかし、愛情のお返しは 1.2 倍え返さなければならないものとします。
それを近しい人間関係でやっていくと、お互いの“愛情貯金”は増えていくという単純は例え話です。
(友人の誕生日プレゼントで年々これに似た事をやって、お互いのプレゼントの額が不毛な事になったという話を聞いた事がありますが、それを推奨してるわけではありません。)

Cig Break:ギブアンドテイク

贈り物の心”と“愛情貯金”の二つの話は、私が 20 代の頃に起業した頃から使ってきた例え話ですが、要するにこれらは、“ギブアンドテイク”による信頼関係の話です。
しかし、テイクばかりを望んでいると、本当の信頼関係は生まれないと言う事です。
ここでは、個人的な自己満足の充足だけで終わってしまうような、一方行的な利益を求めるスタンスという事になります。
ギブをして初めて双方向的な相互関係が成り立つという例え話です。
例えば、生まれてから社会人になるまで、大人の愛情を受けて育ってきた方は多いと思いますが、社会人になれば受け取ってばかりでは成り立ちません。
ネットスラングでは、これに似た事をクレクレと表現される事がありますが、若いうちは許される事も、大人になるほど通用しなくなっていくものでしょう。

エンジニアの生産性:エンジニアの視点

では、話をもう一度エンジニアの視点に戻してみましょう。
我々がやるべき事は何でしょうか?
ソースコードの可読性”や、“開発速度の向上”、“改善速度の向上”は何のためでしょうか?
オブジェクト志向”、“コードの再利用性”、“MVC” は何のためでしょうか?
コーディング規約”という概念は、個人の主観、自己満足、エゴイズムが目的であるべきでしょうか?
ナチュラルキー”が目的となってしまった“データベース設計”の議論に果たしてどれだけの価値があるというのでしょうか?
これらは、本来は“生産性の向上”が目的であるべきでしょう。
コーディング規約”とは、個人のコーディングスタイルを貫くための、争いの場ではありません。
このようなスタンスは、福利厚生の例と同様に、個人的な自己満足の充足だけで終わってしまうような一方通行的な目的によるスタンスといえます。

更には、“コーディング規約”のための“コーディング規約”にもなるべきではないでしょう。
要するに、職務として中間目的があったとしても、それは最終目的ではないという事です。
したがって、中間目的だけでなく、最終目的も明確に理解しておくべきでしょう。
なぜなら、中間目的しか見えなければ、いずれ本来の目的からズレが生じ、やがて“生産性”の低下を招く恐れがあるからです。
例えば、エンジニアが“オーバーエンジニアリング”に目が向かいやすいように、事業の本来の方向性からズレていく可能性を高めてしまうという事です。
中間目的と最終目的の親和性が低いと感じたなら、勇気を持って中間目的を軌道修正すべきでしょう。
何のための中間目的なのか、中間目的は最終目的を達成するための手段であり、あくまでテクニックに過ぎないという事です。

エンジニアの生産性:最終目的の距離感

しかし、多くの方の職務は、会社にとってはあくまで中間目的である場合がほとんどでしょう。
そして、その目の前の目的に集中するあまり、本来の目的を見失うか、あるいは本来の目的の存在すら考えないエンジニアさんのケースをよく見聞きします。
なぜ、このような錯覚に近い状態に陥ってしまうのでしょうか?
もし、あなたが社長から、会社の目的は“会社の永続”だと聞かされて、普段の職務のタスクがピンとくるでしょうか?
そこから逆算して、目の前のミッションがはっきりイメージできるでしょうか?
もしできなければ、この“会社の永続”という大義名分は、あまりに距離感が遠すぎて現実味がないという事でしょう。
このあまりに遠すぎる最終目的と、従業員の意識の距離感を埋めるために、最終目的から中間目的をフォークしていくのが一般的なセオリーでしょう。
しかし、この親和性を管理維持していくのは本来マネージャーの任務でしょう。
もし従業員一人一人にそれを求めても、それはマネージメント意識の強い従業員でない限りなかなか困難でしょう。
しかし逆に言えば、もしこれが理解できてしまえば、会社にとっての“生産性”の高いエンジニアになり得るという事です。

エンジニアの生産性:利益という仮想通貨

エンジニアさんの中で、会社の主要な資金を直接扱ってる方はどれくらいいるでしょうか?
そう、会社の中では、会社の主要な資金を取り扱う立場の人の方が少ないはずです。
利益と言っても、多くの方にとって予算表や実績表、あるいは損益計算書貸借対照表など、紙面の数値上の話になります。
会社の収支といっても、その全てに関わっている方は少ないでしょう。

では、個人の話に立ち返ってみましょう。
もし仮に、あなたが結婚して子供が一人いたとするならば、あなたは家族という組織に属している事になります。
あなたの職業が会社員ならお給料、経営者なら報酬、フリーランスなら受託料などをいただいている事でしょう。
それが、あなたの家族という組織の収入ということになります。
ほとんどの方は、その収入は毎月の生活のためになくてはならないものでしょう。
あなたは、その中から生活に必要な費用を払い、その余剰の中から余暇を楽しむかもしれません。
では、その家族の収支が赤字になればどうなるでしょうか?
企業の場合には、いろいろな資金調達の方法があるかもしれませんが、個人の場合ではおそらく限られてくる方も多いでしょう。
しかし、会社も家族という組織も本質的に大きな違いがないとすれば、それはどちらも組織の継続のために“生産活動”を続けているという事でしょう。
したがって、家族という組織と同じように、会社であっても利益がでなければ組織継続は困難という事です。
しかし、会社の資金を直接取り扱っていない以上、その数値に現実味がないのも事実でしょう。
よって、会社の利益は一見実体のない“仮想通貨”のようにも思えてしまいますが、しかし個人に立ち返って考える事ができれば、組織も個人も本質的にはそう大差ないという事はご理解頂けるかと思います。

エンジニアの生産性:成長サイクル

このように、会社の永続や利益向上というミッションは、従業員からすればあまりに距離が遠く現実的に聞こえないかもしれません。
しかし、それらをより身近に感じるための手段は世の中にはたくさんあります。
例えば、より親近感を感じるための“コアバリュー”経営や、組織と個人の目的をより強力にリンクするための “OKR” などのマネージメント手法など、いろいろな手段が存在します。
(“コアバリュー”や “OKR” の詳細は、“エンジニアマネージメント”のポストで言及する予定です。)
これらは、より身近な言葉で表現されたり、従業員の行動指針や意思決定の物差しとなります。
しかし、これらも“生産性の向上”が目的である事は言うまでもないでしょう。
そして、決して一方向的にならず、顧客、従業員、会社、株主、社会の相互の“生産性”を発展させ、これらを“成長サイクル”でまわして行く事で、より良い豊かな発展が生まれるのではないでしょうか。
PDCA” や “DevOps” などのサイクル図は、プロダクト開発に限ったものではなく、個人にも、顧客にも、従業員にも、会社にも、社会にも当てはまるという事です。

このような事を、繋げて考える事だけが正しいという事ではなく、エンジニアさんのスタンスはいろいろあって良いと私は思います。
幸せの形やスタンスは、決して一つではありません。
しかし、このシリーズに冠しているような“一流エンジニア”を目指されている方には、これらが何かのきっかけになれれば幸いです。
もし、組織構築の主体者の方々がこのポストを見てくれているとするならば、是非この循環関係にこだわって欲しいと切に願います。

エンジニアの生産性:生産性と効率化の違い

最後にもう一つ、大事なポイントをお伝えしておきます。
みなさんは、“生産性”と“効率化”の違いをうまく説明できますでしょうか?
この二つの言葉の意味の違いを、うまく説明してる情報も非常に少ないようです。

ここでは、いったんこれらを“生産活動”と“効率活動”と言い換えてみます。
例えば A さんは、筋トレを始めたとします。
そのバリューは、筋力増強だとします。
しかし、その A さんが、筋トレを怠り、プロテインばかりを飲み始めたとしたら、いったいどうなるでしょうか?
もちろん、そのプロテインは筋肉ではなく、脂肪に変えてしまう可能性を高めてしまいます。
プロテインを飲む行為は、あくまで、筋トレによる筋力増強の“効果”を上げる補助的な“効率活動”としては有効ですが、バリューを生むのための直接的な“生産活動”にはなりません。
例えば、会社が“広報活動”ばかりに傾倒し“生産活動”を疎かにした場合の、価値の生まれない実態とかけはなれた“錯覚負債”を増やす活動、と酷似してるといえるかもしれません。

生産性とは?”のセクションでも解説したように、“効率”とは単に“アウトプット/インプット”で表せる指標であって、何かの価値を表した指標という意味ではありません。
よく“業務効率化”という言葉が多用される場面を見聞きしますが、この言葉が本来意味するものは、単に業務の“効率”を“アウトプット/インプット”で表わすものでしかなく、それによって価値あるものが“生産”できるかどうかの意味とは全く別物であって、この二つの意味を混同して使用されている情報が非常に多いようです。
したがって、その“業務効率化”の施策は、本当に“生産性の向上”に寄与してるかどうか、もう一度よく検討すべきでしょう。
そして、もし“生産性の向上”に寄与していないとすれば、この状態も“生産性の向上”の目的からズレている状態といえますので、その施策の改善の余地があるかもしれません。
このズレの軌道修正も非常に大切ですが、このズレに気付く事が何より大切です。
生産性”とは、“生産”(価値を生む活動)の“効率”を表したのものという事です。

エンジニアの生産性:まとめ

このポストでは、“一流エンジニアになるための Off-JT” シリーズのテーマとして、“エンジニアの生産性”について解説しました。

この考え方は、“一流エンジニア”になるためのみなさんの強力で有用な武器になりえます。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。

一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#7. エンジニアマネージメント” の予定です。