Open YuheiNakasaka opened 2 years ago
たまに転職する際の企業の選び方について聞かれることがある。自分は転職を大して経験してるわけではないから具体的なアドバイスはできないだけどとりあえず自分なりの企業の見方について少し話すことにしてる。
それはあらゆるものを資本と資産と収益の関係でみるということだ。
といっても別に財務諸表を読むスキルをつけろと言っているわけではなく(あれば良いに越したことはない)、企業というシステムがどういうロジックで動いていて、組織やそこで働く人々が何をやっているかの大雑把な流れを把握するという話である。
まず企業の生産活動というのが何をやっているか？という大雑把な流れを整理すると下記に集約できる。
基本的にはこの３つを回しているだけだ。
例えば銀行からお金を借りて(資本を得る)、商品を作り(資産を作る)、販売して対価をもらう(収益を得る)といった具合。
資本を得るについては借入やVCや市場からの調達や得た収益が資本になったりする。 資産を作るについては製品を作ったりサービスを作ったりすることがそれにあたる。 収益を得るについては資産を活用してそれを金に変える部分のことだ。
資本を得る→資産を作る→収益を得るという各フェーズの中で営業やマーケティングや開発/生産や経理やらなんやらといった職務の人がおり、彼らがそれぞれの役割で働くことで会社が回っていく。結果的に業績が上がったり下がったりという具合になるわけだ。
で、この企業の見方を前提にして転職に際しては自分がどの役割を担うことになるのか？ということを考える。
例えば自分の場合ならソフトウェアエンジニアなのでほぼ「資産を作る」というフェーズに従事することになるとわかる。だから企業を選ぶ際は、どういう資産(サービスや製品)を作っているか、資産(サービスや製品)の成熟度はどの程度か、どういう体制で資産(サービスや製品)を作っているのか、将来の(資産的な)展望を最初に見る。
まぁこれは誰でもやると思うが、しかしこれだけでは不十分で、一番大事なのはその資産がどうやって収益を産んでいるのかまで見ることだ。なぜなら資産が収益を産む構造が乏しい場合は資本が減り資産を作ることに投資する原資が減るから結果として、開発全体への体験が悪くなるし給与も上がらなくなるから。
なので一般的にエンジニアとして良いDXと良い給与を得たいなら資産が収益を生み出す構造が強固な会社を選ぶ方が良い転職になりやすいと思う。
といった感じで資本と資産と収益の観点で企業活動を見ると、自分が企業活動のどこを担い、それがその活動にどれほど寄与できるか理解しやすいし、その寄与が回り回ってDXや給与へどれほどつながりそうかというところまで意識できるようになる。
資本を得る→資産を作る→収益を得るという考え方は普段の業務にも当てはめられる。例えばエンジニアの生産活動は企業全体で見ると資産を作る部分にあたるが、この資産を作る部分のエンジニアチームとしての生産活動をさらに分解して、資本を得る→資産を作る→収益を得るという構造にマッピングしてみる。
少々強引だけど無理矢理マッピングしてみるとこんな感じになるはず。
で仮に自分の役職がインフラエンジニアであれば収益を得るの部分が責任範囲になるし、フロントエンド/サーバーサイドエンジニアであれば資産を作る部分が責任範囲になる、といった具合に考えることができる。
各人はその責任範囲における生産活動を行い、またその責任範囲の中で生産性を向上させられることであれば基本なんでもやっていく道理はあるはずだ。もし新しい言語やフレームワークの導入や技術的負債の返済をしたいとなった時に、この観点で自分の立ち位置を理解できていれば、自分の責任範囲の生産性をどれほど向上させそれが組織にどういう寄与をするかを説明しやすくなる。結果として上司への提言にも説得力が出るので受け入れやすくなると思う。
ここでも大事なのは資産を作る→収益を得るの部分。どんなに開発を頑張ってもリリースされて安定運用に乗らなければ意味がない。金をドブに捨てているのと同じことになる。という意味ではデプロイ頻度が向上する仕組みづくりが重要で近年CI/CDの仕組みの重要性やSREが取り沙汰されるのはこの資産を作る→収益を得るの間の生産性を向上させる役割を担うためだと思う。
こうした資本を得る→資産を作る→収益を得るという構造は、エンジニアの生産活動に対してもマッピングできたように他の役職でも多分できるはずで、各種部門内における資本を得る→資産を作る→収益を得るという構造のリソースを調整していく仕事がいわゆるCXOという役職だ。もちろんだけどCTOは会社全体の資本を得る→資産を作る→収益を得るという構造を調整している。
資本を得る→資産を作る→収益を得るという構造は日々の生活にも見出すことができる。無理矢理マッピングするとこんな感じか。
労働者であれば、働いて金を得て、その金を使って何かを買ったり遊んだり勉強したりして自分という資産を豊かにして、それを労働力として使い金を稼いで...という感じ。もし株式や不動産を買ってそこから収益を得られるなら、収益を得る手段が資産それ自体になったりする。いわゆる不労所得。
ちなみにピエール・ブルデューの文化資本は資産を作る部分の資産の初期値パラメータになりそう。
まぁ人生は大体こんな感じだと思う。
ここでも重要なのは資産を作る→収益を得るの部分でどんなに勉強しても収益に繋げる仕組みがないなら金は得られない。自分という資産が収益を産み出すためのの生産性というものを考えるなら、資産を作る部分に力を入れるのと同じだけそこから収益を得る部分にも力を入れないといけない。
とはいえ人生が他の生産活動と違うのは別にそんな生産性なんて考えなくても良いことだ。企業活動では無理だけど人生なら自分が満足すれば何も産まなくても別にいいし生産性なんて考えなくても良い。
資本を得る→資産を作る→収益を得るという構造は人生にも見出すことはできるけど、それに意味があるのかどうかは疑問ではある。
資本・資産・収益の構造で身の回りの生産活動を見渡してみると、割と何にでも当てはめることができるとわかる。が、そのマッピングに意味があるかは別問題だ。
せいぜい暇人の思考実験にはなるのでこの3連休が暇でどうしようもない人にはちょうど良いかもしれない。
たまに転職する際の企業の選び方について聞かれることがある。自分は転職を大して経験してるわけではないから具体的なアドバイスはできないだけどとりあえず自分なりの企業の見方について少し話すことにしてる。
それはあらゆるものを資本と資産と収益の関係でみるということだ。
といっても別に財務諸表を読むスキルをつけろと言っているわけではなく(あれば良いに越したことはない)、企業というシステムがどういうロジックで動いていて、組織やそこで働く人々が何をやっているかの大雑把な流れを把握するという話である。
資本を得る・資産を作る・収益を得る
まず企業の生産活動というのが何をやっているか？という大雑把な流れを整理すると下記に集約できる。
基本的にはこの３つを回しているだけだ。
例えば銀行からお金を借りて(資本を得る)、商品を作り(資産を作る)、販売して対価をもらう(収益を得る)といった具合。
資本を得るについては借入やVCや市場からの調達や得た収益が資本になったりする。 資産を作るについては製品を作ったりサービスを作ったりすることがそれにあたる。 収益を得るについては資産を活用してそれを金に変える部分のことだ。
資本を得る→資産を作る→収益を得るという各フェーズの中で営業やマーケティングや開発/生産や経理やらなんやらといった職務の人がおり、彼らがそれぞれの役割で働くことで会社が回っていく。結果的に業績が上がったり下がったりという具合になるわけだ。
転職に生かす
で、この企業の見方を前提にして転職に際しては自分がどの役割を担うことになるのか？ということを考える。
例えば自分の場合ならソフトウェアエンジニアなのでほぼ「資産を作る」というフェーズに従事することになるとわかる。だから企業を選ぶ際は、どういう資産(サービスや製品)を作っているか、資産(サービスや製品)の成熟度はどの程度か、どういう体制で資産(サービスや製品)を作っているのか、将来の(資産的な)展望を最初に見る。
まぁこれは誰でもやると思うが、しかしこれだけでは不十分で、一番大事なのはその資産がどうやって収益を産んでいるのかまで見ることだ。なぜなら資産が収益を産む構造が乏しい場合は資本が減り資産を作ることに投資する原資が減るから結果として、開発全体への体験が悪くなるし給与も上がらなくなるから。
なので一般的にエンジニアとして良いDXと良い給与を得たいなら資産が収益を生み出す構造が強固な会社を選ぶ方が良い転職になりやすいと思う。
といった感じで資本と資産と収益の観点で企業活動を見ると、自分が企業活動のどこを担い、それがその活動にどれほど寄与できるか理解しやすいし、その寄与が回り回ってDXや給与へどれほどつながりそうかというところまで意識できるようになる。
業務に生かす
資本を得る→資産を作る→収益を得るという考え方は普段の業務にも当てはめられる。例えばエンジニアの生産活動は企業全体で見ると資産を作る部分にあたるが、この資産を作る部分のエンジニアチームとしての生産活動をさらに分解して、資本を得る→資産を作る→収益を得るという構造にマッピングしてみる。
少々強引だけど無理矢理マッピングしてみるとこんな感じになるはず。
で仮に自分の役職がインフラエンジニアであれば収益を得るの部分が責任範囲になるし、フロントエンド/サーバーサイドエンジニアであれば資産を作る部分が責任範囲になる、といった具合に考えることができる。
各人はその責任範囲における生産活動を行い、またその責任範囲の中で生産性を向上させられることであれば基本なんでもやっていく道理はあるはずだ。もし新しい言語やフレームワークの導入や技術的負債の返済をしたいとなった時に、この観点で自分の立ち位置を理解できていれば、自分の責任範囲の生産性をどれほど向上させそれが組織にどういう寄与をするかを説明しやすくなる。結果として上司への提言にも説得力が出るので受け入れやすくなると思う。
ここでも大事なのは資産を作る→収益を得るの部分。どんなに開発を頑張ってもリリースされて安定運用に乗らなければ意味がない。金をドブに捨てているのと同じことになる。という意味ではデプロイ頻度が向上する仕組みづくりが重要で近年CI/CDの仕組みの重要性やSREが取り沙汰されるのはこの資産を作る→収益を得るの間の生産性を向上させる役割を担うためだと思う。
こうした資本を得る→資産を作る→収益を得るという構造は、エンジニアの生産活動に対してもマッピングできたように他の役職でも多分できるはずで、各種部門内における資本を得る→資産を作る→収益を得るという構造のリソースを調整していく仕事がいわゆるCXOという役職だ。もちろんだけどCTOは会社全体の資本を得る→資産を作る→収益を得るという構造を調整している。
人生の場合
資本を得る→資産を作る→収益を得るという構造は日々の生活にも見出すことができる。無理矢理マッピングするとこんな感じか。
労働者であれば、働いて金を得て、その金を使って何かを買ったり遊んだり勉強したりして自分という資産を豊かにして、それを労働力として使い金を稼いで...という感じ。もし株式や不動産を買ってそこから収益を得られるなら、収益を得る手段が資産それ自体になったりする。いわゆる不労所得。
ちなみにピエール・ブルデューの文化資本は資産を作る部分の資産の初期値パラメータになりそう。
まぁ人生は大体こんな感じだと思う。
ここでも重要なのは資産を作る→収益を得るの部分でどんなに勉強しても収益に繋げる仕組みがないなら金は得られない。自分という資産が収益を産み出すためのの生産性というものを考えるなら、資産を作る部分に力を入れるのと同じだけそこから収益を得る部分にも力を入れないといけない。
とはいえ人生が他の生産活動と違うのは別にそんな生産性なんて考えなくても良いことだ。企業活動では無理だけど人生なら自分が満足すれば何も産まなくても別にいいし生産性なんて考えなくても良い。
資本を得る→資産を作る→収益を得るという構造は人生にも見出すことはできるけど、それに意味があるのかどうかは疑問ではある。
最後に
資本・資産・収益の構造で身の回りの生産活動を見渡してみると、割と何にでも当てはめることができるとわかる。が、そのマッピングに意味があるかは別問題だ。
せいぜい暇人の思考実験にはなるのでこの3連休が暇でどうしようもない人にはちょうど良いかもしれない。