IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

それで、労働集約型産業って何で悪いの?(散文)

散文(散らかってる文)

 

労働集約型産業って何で悪いんでしたっけ?

ここ数年ずっとこれ考えています。
たぶん答えが出ないんですが、定期的にまとめていきたいです。
何で気になるのかというと、社会の設計がプログラムの設計に似てるからでしょうかね?

※たぶんちゃんと調べればもっといい記事が出てくると思います

 

労働集約的産業の現状と課題
http://www.mhlw.go.jp/file/05-Shingikai-11601000-Shokugyouanteikyoku-Soumuka/62-75.pdf

 

 

労働集約型産業とは

労働集約型産業 - Wikipedia

労働集約型産業(ろうどうしゅうやくがたさんぎょう Labor-intensive industry)とは経済学用語の一つ。存在している産業の中でも人間による労働力による業務の割合が大きい産業のことを労働集約型産業と言う[1]

現代日本では接客を行う商業サービス業などと言った第三次産業が労働集約型産業とされている。かつての日本では製造建築も労働集約型産業とされていたが、科学技術の発達により、そこから従来ならば人間が行ってきた業務を機械で行えるようになっていることから、人間による労働力の占める割合が減少してきており、労働集約型産業ではなくなってきている[1]。現在のサービス業でもコンピュータの発達などから頭脳労働ではあっても機械が代行できるような業務から人手の需要が減少してきており労働集約型産業ではなくなりつつある[1]

 

第一次産業や、第三次産業がこれにあたります。
つまり普通にイメージできる仕事はだいたいこれと言っても乱暴ではない気がします。

 

これ以外には 

とかあるみたいです。
もちろんそんな単純な話でもないんですが。

 

労働集約型産業の特徴を探る

労働集約度というちゃんとした言葉があるようです。

付注2-1-14 産業別の労働集約度


単純に考えれば、どれだけ手間が掛かっているかという尺度。あとは売上に占める人件費なんかで出せそうですね。
ただそれ自体は特に問題がないように見えると思います。
例えばIT受託なんて人件費がほとんどを占めますが、それ自体に問題があるわけではありません。

ただ、状況的にこういう特徴を持つことがほとんどだと思います。

  • 1人あたりの生産高に限界がある
  • 人が居るほど総生産高が上がる

これは小作人が分かりやすいです。
やればやった分儲かる、という状況です。

純化すれば、10やったら10儲かり、100やったら100儲かります。
100やった時、0になるリスクはあまりありません。
その代わりに100やった時、200になることもあまりありません。

 

労働集約型産業はなぜ人気か

100やったら100儲かる、というのは非常に魅力的です。
人はリスクを嫌う性質があるので

  1. 100やったら50%の確率で0儲かる、50%の確率で200儲かる
  2. 100やったら100%の確率で100儲かる

があったら、2を選択してしまうそうです。
期待値は一緒なのに、リスクはとれません(そりゃそうです。例えば連続で0が出ると死んでしまいます)

 

だから、より安定して稼げる労働集約型産業は大人気です。

 

人気になる→レッドオーシャンになる

当然の帰結です。
例外としては、専門的すぎて誰でもできるものではないケースや、資本が必要になるケースです。
これらを突き詰めると知識集約産業とか資本集約産業になるのではないでしょうか?

すると、あるラインを境に供給過多になります。
100やったら100稼げていたのが、90になります。
しかしそれはゆっくり起こるでしょう。90になり、80になり、70になり・・・。
新規参入と脱出の平衡状態になるまで下がり続けるでしょう。

でも、安定はしているので人気度はなかなか落ちません。

 

やがて労働集約型産業は死ぬ

単価が上向くことは滅多にありません。
せいぜい他の産業が盛り上がった煽りで人手不足になる程度でしょうか?
あるいは特需レベルに需要が高まったり。
しかし長期的に見れば徐々に下がっていくのだと思います。

そしてある日突然労働集約型産業を脱出します。
それは破壊的イノベーションによってもたらされます。

今まで人手でやっていたのが、機械や仕組みに置き換わるわけです。
皆が大好きな自動化です。

労働者自体は他の作業をするので生き残るように見えるかもしれませんが、その仕事は死にますし、それに特化しすぎた人は路頭に迷うはずです。

 

労働集約型産業とは、安定度のライフサイクルなのではないか?

つまり、こういうイメージです。

 

f:id:otihateten3510:20180218012615j:plain

 

労働集約型産業とは、言い換えれば産業(稼げる方法)の末期に近いのではないかと思います。
なぜ労働集約型産業が悪いかと言えば、死にかけ・死に体だからでしょう。
(悪いというか、黄色信号というか)

 

なぜ地獄か:ブローカー

人が居るほど売上が立つ。

こうなると、労働力を扱うブローカーが必ず現れます。こいつらが話をややこしくするわけです。
その中の業界の人達は、どうにか儲けようと大量の人材を扱うようになります。
その状態でレッドオーシャンに突入すると、それはもう地獄にしかなりません。
海外から人を連れてきたり、多重派遣になったり。
みんなで一緒に苦しくなっていきます。

 

なぜ地獄か:学校ができる

これもブローカーと同じです
人が必要となれば学校ができやすいです。すると人の供給はどんどん増えていきます。
また、行き過ぎると学校の方が儲かるという意味のわからない状態になります。

 

なぜ地獄か:ブラック企業が蔓延る

労働集約型産業で経営者が儲けようとしたら、大規模化し、1人あたりの人件費を削るのが一番です。
つまり許される限界ギリギリまでブラック化するし、そういう企業が勝ってしまいます。

 

なぜ地獄か:破壊的イノベーション

脱出する方法がぶっ壊すしか無い状態です。
救いがありません。
業界ごと壊れるので、キャリアがぶっ壊れます。
入って5年で潰れたらラッキーです。20年目とかだとそれはもう地獄でしょう。

 

様々な回避策

救いのある回避策

昭和までは上記の方法が一般的だった気がします。より自由化が進んでなんかぶっ壊れましたが。

参考

otihateten.hatenablog.com

 

救いがあまりない回避策

  • 新規参入の阻止

破壊的イノベーションからの独占状態です。
最近だとこういうの多いですね。他が真似できないように工夫します。(もちろん私もサービスをそういう風に考えています)

 

労働集約型産業の難しい点

労働集約型産業の良いところは、リスクが少ない点です。

例えば、100やって0 or 200みたいな仕事があったとして、200を勝ち取るのは優秀な人です優秀ではないけど賢い人はそれがわかっているので、リスクを取ろうとしません

そう言った人たちが行き着くのが労働集約型産業です。
その選択は正しいように見えますが、実はリスクを長期に引き伸ばしただけなのです。

これがまだ、20年前の世の中なら良かったと思います。
あるいは高度経済成長時代みたいに、仕事がだめになっても別の仕事がジャンジャン生まれる状態なら良かったかもしれません。
しかし今の時代は、破壊的イノベーションは起こる割に新しい仕事がなかなか生まれない辛い時代だと思います。

この時代において、リスクを取っても勝てないと判断した人たちに救いが無いわけです。
これじゃどう足掻いても二極化ですよね。真面目にやっただけじゃ勝てないのが地獄度高いです。
一部だけが儲かっても業界全体の地獄度は変わりません。

 

※統計があるわけじゃないので想像ですが。ただ二極化は世界的に進んでいるそうですね。日本も同様。

 

真の回避策はあるのか

どう足掻いても勝者と敗者が出て、それがどんどん鮮明になるこの状況。

完全にぶっ壊すには、経済学的な力学を無視した対応を生むしか無いように思えます(語弊がありそうですが)

 

もう一つの解法

これをずっと考えているのですが。

破壊的イノベーションが外部から行われるのが一番不味いんだと思います。

業界内で、例えカニバリになろうがイノベーションを起こし、その上で参入障壁をきちんと作れれば、今より安定するのではないでしょうか。

 

まあ、もちろんそれを全産業で起こすには中々大変です。
だとしたら、業界内から破壊的イノベーションを発生させることを目的とした企業が世に必要なんじゃないかなぁと感じています。どうしても最近のイノベーションは業界を食ってる感が否めないと思うのです(まだふわっとした印象ですけど)

 

好景気の受託開発で起こりがちな失敗

好景気ですね(たぶん)
 

実際に好景気かどうかは置いておいて、仕事が溢れた時受託開発で気をつけたいことを考えてみます。会社単位で見ればよくあることですし、その時には気づかなかったことが色々ありました。

せっかく仕事が多いというチャンスなのに、対応次第でリスクになってしまうケースがあると思います。

 

図解!!

色々文章で説明しようと思ったのですが無理でした。
うっかりするとこうなります。

 

f:id:otihateten3510:20180214211630j:plain

 

これが数年スパンで起きるケースがあります。

 

少し解説

この図のフローが起きて怖いのは、

  • 仕事を大量にこなすのに、上がらない利益率
  • 優秀な人が出ていって地獄
  • とにかく仕事が多い
  • 例え切り抜けても、大きな図体と一段レベルが落ちた従業員が残る

ここらへんだと思います。

 

やらかす最大の要因としては「リーダー格の割合が減る」です。仕事があふれるせいで採用を厳選しづらくなります。(回避しようとして外注を増やしても結果は好転しません)

 

回避するには?

  • 従業員の数に見合った仕事量
  • 従業員のレベルアップ
  • 社員全体のレベルバランスを壊さない(兵隊ばかり雇わず、ちゃんと収束できる人を増やす)

を心がけるしか無いと思います。

 

でも、回避が難しい理由

このくらいのこと、PMや経営陣はわかってると思います。

しかしクライアントも好景気には必死なので「何とかお願いします」と言ってくるわけです。そうなると引き受けざるを得なくなってしまいます。

中々仕事量のコントロールは難しいはずです。

これらを解決できるすごい会社だけまともに成長していくのでしょうね。私には自信ありません。

 

エンジニアとしてどう対処するか

自分が壊れる前に逃げるです。

フローを見れば大体わかりますが、そこから好転する目が見つかりません。ジリ貧です。もはやこれまでとなると、本当に優秀な人から抜けていきます。地獄度は刻一刻と上がっていくだけです。

 

もちろん、そうなる前に社内でよく話し合うことができればいいんですけど。中々難しいです。
個人的にも、もっと上手くやれたパターンの話を聞いてみたいです(失敗パターンばかり見てきている)

アプリ開発者は、Webサイトをどうすればいいか問題

www.publickey1.jp

 

PWAでいいのでは?

あれ、PCでPWAって表示できるんですかね?

 

でも、iOSアプリ作って、Androidアプリ作って、PWA作ってって
同じような機能を3回作るのはつかれるので、ハイブリッドがまた流行るんでしょうかねぇ
さすがに3プラットフォームとなると、1人でやるには中々しんどいものがあります
会社でやるにも2人×3で6人くらい必要になっちゃいます

 

 

PCは順次対応とのこと

www.suzukikenichi.com

(日記)最近の一日

08:30 起床、風呂

09:30 出社 最近CM始めたサービスのアプリ開発(本職)

13:00 飯を食べながら趣味のアプリの開発

19:00 退社

19:15 渋谷のコアワーキングスペースで起業用のアプリの開発

22:00 コアワーキングスペース退出

22:20 帰宅

23:00 晩飯食いながらネット徘徊

23:30 アニメ見ながら趣味のアプリの開発

02:00 寝落ちするように就寝

 

1日13時間開発してる!?

 

ここ半年、人生で最も稼働が安定していると思っていたんですが。
気づけば一人でデスマしてました。

 

なお土日祝は起業用のアプリ作ってます。
死ぬ。
こんなだからぼっちなんですよ。

なぜなぜ分析はサービス改善に使えなくない?

note.mu

 

前々からこれには違和感がありました。
ブコメにもありますが、全部仮説なんですよね。

 

Wikipediaには

”要因はひとつだけとは限らない。また、事象に対して、論理的なつながりがなければならない。" (なぜなぜ分析 - Wikipedia

とあるので、要因がいっぱい出てきて発散してしまいます。
発散した選択肢の中で「真の要因」を見つけられるメソッドになっているでしょうか?

 

なぜなぜ分析の適切な使いみち

調べた所、こちらのサイトがすごく納得できました。 

図解 なぜなぜ分析:5Whys ~現場の問題解決手法~

 

「悪い事例」が分かりやすいです。
つまり、原因と結果が仮説であってはならないわけです。

 

現場レベルで原因と結果が分かるものに対して使うものみたいです。
プログラミングで行われている普通の行為ですよね。バグから原因を特定して解決する行為こそなぜなぜ分析なのだと思います。

 

サービスに適用する問題

もちろん、顧客開発するときに似たようなフローは行われます。しかし非常に時間がかかります。
1個の原因と結果を調べるのがそもそも大変なんです
下手すると関係者でさえ誰も分かっていないことがあります
みんなして「うーん何となく」っていうんですよ。

 

リーンスタートアップなんかは、その誰も分かっていないポイントを仮説として、検証していく過程の方法論です。そこでは仮説を絞ることが推奨されています。5回なんて無茶です

(ブログにあるような小さい事象ならどうにかなるでしょうけど)

 

解決できていないからこそ真の問題

真の原因を特定して解決したらサービスになる、というのはちょっと烏滸がましいのだと思っています。
関係者は既にやれるだけやっているはずです。簡単に解決できるなら誰かがやってます

  • 解決できない
  • 解決する技術がない
  • 解決して旨味がない
  • 解決すると他が問題になる(トレードオフ
  • 解決してほしくない人が居る
  • 解決するコストが掛かりすぎる

などと言った理由で解決できていないからこそ真の問題なわけです。

 

サービスを考える時の思考法

個人的におすすめなのは論理木を作ることです。

全部仮説や推測で構いません。

 

f:id:otihateten3510:20180210143409p:plain

 

一応、仮説なのか仮説じゃないのかは分かるようにしておいたほうが良いかもしれません。「人によっては違う」みたいなのもあると思います。程度問題になるので完璧なものは作れないはずです。

 

これを1個の事実(不満など)から、要因の方、結果の方、思いつく限り広げていくとします。途中で別の事実も出てくるはずです。
すると、あれ何でこここうなってるの?こうした方がいいんじゃないの?という部分が発見できると思います。

 

そうしたら次に調べることができます。大抵は自分の勘違いですが、勘違いだとわかればまた角度の高い木が書けます。そうやってるうちに、本当に穴が見つかると思います。
しかし、それも大抵は解決方法ができないとかコストに見合わないです。

 

その中からさらに「行けそう」というものが見つかります。
それがようやくアイディアとなります。

 

アイディアまで辿り着けたら、既に論理木が書けているので、利害関係者やモチベーションが表せているはずです。

 

その次に待ち受けているのがアイディアを実現できるかで、その後に流行らせることができるか、が待ち受けています。
ですが、どこまで行っても最初に作り、アップデートしていく論理木があると迷うことが少なくなると思います。

お試しあれ。

 

 

あ、リーン顧客開発良いですよ

www.oreilly.co.jp