読書感想文「僕たちはいつまでこんな働き方を続けるのか?」

帯に書いていた「４０年間ラットレース」というのに惹かれて書店で手にとったのが、「僕たちはいつまでこんな働き方を続けるのか？」という新書。

ざっくり読んでみての所感

ここ数年、「働く」ことについて考えることがよくあり、漠然とその理由の輪郭は見えていたのですが、本書を読んで輪郭がより明確になりました。


恥ずかしながらマルクスの資本論っちゅう奴の内容をさっぱり知らなかったので、資本主義における「給料の基準」や物の「価値」に関するくだりは読んでて非常に面白かったです。


他にもいろいろ納得の内容が記載されており、なるほどなぁと思うことがたくさん。

転職したってそう簡単に生活は楽にならないぞ！っていうのは大変納得。
ここから先は読んでのお楽しみ、ということで。

以下、読書感想文です。

某会社の某製品のライセンス価格に納得が行かない理由も理解できてスッキリ。
逆に、システムを作る大変さをお客さんがいまいちぴんとこない理由、システム屋さんがIT土方と呼ばれる理由もよくわかりました。

システムは見えない=価値が分かりづらい

実態のないもの、実感できないもの、想像できないものっていうのは人間にとって価値がピンとこないのだと思います。
コンピュータのシステムというのは正に上記３つが当てはまっていて、モノが出来上がって使ってみないと価値が実感しづらいものです。


システムインテグレーション（SI）と呼ばれる分野では、まずお客さんが作りたいシステムの要求を聞いて、その内容を元にどのような機能が必要か、それを作るのにどの程度の人間がどのくらいの期間作業を行う必要があるかを見積もり手法や過去の実績を元に算出し（これを人日とか人月とか呼びます）、その数値✕作業者の人件費✕利益率でシステムのお値段が決まります。(ホントはハードとかソフトの値段もありますけど、ここでは省略)


まず、人日や人月の妥当性というのがシステムに携わっている人からすると分かりづらいのが、値段に納得いかない第一ポイントだと思います。本書の中で言及されている「価値」＝製品を作るために必要となる材料費(人件費含む)の妥当性が分かんないんだから、高いと思うのも当然です。


まー、なんかコンピュータ上でぽちぽち作って出来上がりなんでしょ！というイメージの方からするとそうなるのはよく分かります。


ただ、実際には机上でそのプログラムがどのような機能があってどういう動作をするのかという設計書を起こして、それを元にプログラムを作成し、プログラムが設計書通り動いているかテストを行い、他の機能と一緒にしてちゃんと動くかをさらにテストし、システム全体を通してテストして問題ないか、お客様が動かしてみて想定と違うところはないかという長い道のりを経て完成するものなので、結構手間はかかるのです。


ちなみに、その手間の中にはドキュメントの体裁チェックというのがあって、全部紙で印刷した時に文字がはみ出てないか、誤字脱字がないか、罫線が切れてないかというチェックを何回もやり直すなんていう２１世紀とは思えない、これがなければお値段も安く、作成者側も助かるwin-winの関係が築けるというチョー無駄な作業もあったりしますが。紙も無駄になるのに、意外にこだわる人が多いの…。


…脱線しましたが、お客さん目線で納得いかない理由はお客様の想像する「価値」とシステム屋が出してくる「価値」のギャップなんでしょうね。
昨今流行ってるアジャイル開発というのは、ちょっとずつ作ったモノをお客さんに見せながら開発を進めていくらしいので、このギャップが少なくなるのがいいところなのかなー。(残念ながらアジャイル開発したことないから勘違いしてるかもね)

システムのお値段の算出

結局、お客さんから高いよ！と言われた場合、利益を下げるか、人月を削るかして値段を落とすことが多いのです。


IT土方と呼ばれる理由についてですが、先程登場した「人月✕作業者の人件費✕利益率＝システムの値段」を見れば分かるとおり、人件費が少なければ少ないほど、システムを安く作れるわけです。なので、お客さまから仕事を請けた会社(一次発注者。プライムベンダーとも)は自社の人間で足りない部分の作業者を、なるべく安い値段で人を探します。

多重請負がもたらすデスマ

はい、一次発注者ということは二次(セカンダリ)、三次の発注者がいるわけですねｗ


子請け、孫請けなんて言葉がありますが、紹介料だけとって他の会社に丸投げして中間マージンを取る会社なんかもあり、その場合はどんどん金額が下がっていきます。


本書では、「給料」＝「明日も今日と同じ働きをするための必要経費」＋「スキル習得費」＋「世の中からの需要」となっており、実際、スキルが低い人は単価が低くなるわけです。(実際には、単価がべらぼうに高くても役に立たない人(逆もしかり)もいますが…)


一次発注者はこのスキルの人というのを想定して金額を決めているのに、実際は想定よりスキルが低い人がくると、予定の作業時間を超えてしまい、スケジュールが遅れてしまいます。


さらに、ほんとに必要な人月を減らして値段を下げていた場合、さらにスケジュールが厳しくなります。


結果、人手と時間が足りなくなり、土日出勤、平均睡眠時間２時間とかのデスマーチが完成する訳ですね。

請負の場合、コストと納期は(基本的には)変更不可。落としどころを見つけるコミュ力大事！

「スケジュール遅らせれば良いじゃん」、「人増やせば良いじゃん」というのが普通に思い浮かぶ解決策なのですが、請負契約だと、納期遅れは契約違反、基本的には最初に契約した金額以内で完成させる必要があるので、お金が足りなければ自腹を切り、スケジュールを守るために死ぬ気で働くことになるのです。


まぁ、こんな感じでIT土方とよばれるような労働環境ができあがってしまうのです。

システム開発では(客側の)人間は死なない

この構造って、先のバス事故の発生原因とほんと良く似てるんですよねー。ただ、客側の人間が死なない限り問題にならないんですよね。


長くなりましたが、本書の内容に頷きながら、ヨーロッパの経済危機からIT業界の構造、自分のフトコロ事情まで考えを巡らせ、働き方を見なおしてみる良いきっかけになりました。


ここではないどこかに思いを馳せている社会人にお勧めです。