Twitterで開発マシンの「最低限の人権」とされるスペックについての話題が広がっています。
発端はこれです。
NTTでは優秀な人材はGAFA（Google, Apple, Facebook, Amazon）に引き抜かれるので処遇を改善しよう（具体的には給料をあげよう）という話です。
そこで、「いや、給料だけの問題じゃない。意思決定が遅い組織的な問題やITエンジニアの仕事そのものへの無理解に起因する開発環境のチープさに嫌気が差して止めていくエンジニアは多い」という話がぶり返されます。この問題はITエンジニア業を営む人にとっては本当によく見る問題であります。
そんな中、ネットで有名なエンジニアの一人がタイムリーにNTT（研究所）を退社しGoogleに入るというエントリを書きました。
これでこの開発環境周りの論議が白熱してみんな色々語ってるように思います。「人件費に比べても圧倒的に安い程度には安価な設備をケチって(もしくはそういった物品の購入が簡単に認められないような組織運営を続けて)GAFAに優秀な人材を引き抜かれてていいのか？」って話ですね。ただ、前述のNTTを退職した人のエントリを見ると、少なくともNTT研究所では開発環境のスペック等々に恵まれていたとの記述があるので、この人には当てはまらない話なんですが。
最低限の人権とは
そもそもスペックの人権ってなんだよ、人権の意味分かってるのか？と思う人もいるかも知れませんが、そのへんはギャグで自虐的に言ってることなので突っ込まないでくださいね。
意見を雑にまとめると、「メモリが最低8GB、普通は16GB以上のマシンにSSD」というスペックが語られている事が多いように思います。この数字は大げさではなく、普通に必要な数字と私も思います。
例えば私はいまこの文章をWindows PC上でChromeを起動して書いていますが、この状態でメモリは5GBも使ってるみたいです。裏で起動しているAdobe関連のサービスがメモリ食ってるみたいなのでこれが平均的とは思えないですが、でも多分最近のOSなら起動して会社で導入させられるアンチウィルスソフトその他監視アプリを起動させるだけで2GB弱くらいは使うんじゃないでしょうか。
その上で更に、IDEを立ち上げると2GBくらいは普通に使いますし、開発中のアプリをデバッグ用にローカルで立ち上げたりするとそこでまた数GBのメモリを消費することもあるでしょう。普通は調べ物をしながら開発をしますから、ブラウザも起動するとそれでまた1～2GBくらいは最低でも使用するわけです。ですから、8GBでギリギリ、普通に開発マシンとして使用するには16GBという数字は大げさでも何でも無く、これが現代の普通なのです。
ちなみにLinux(Ubuntu)でメモリ使用量を確認したところ、ブラウザだけ起動した状態で3.3Gくらいメモリを使ってました。するとたとえ消費メモリ量の少なそうなLinuxに切り替えたとしても、やっぱりメモリ8GBくらいは欲しくなってくる数字と思いますね。
生産性の低下
Twitterを読むと
- Eclipseが立ち上がるまで5分
- コーヒー飲んで帰ってきてもログイン画面が出てない
などという記述が出てきます。メモリが足りなくて盛大にスワップしていることは明らかです。
「5分待てば動くなら待てばいいじゃん、と言われた」という体験談も書かれていましたが、いや、そういう問題じゃないんです。5分待ったら快適になるわけではなく、なにかするたびに数分待たなければならなくなります。単純に待ち時間だけでカウントしても、Eclipse起動するまで5分とかいう極端にひどいマシンでは労働時間の1/4くらい待ち時間が発生するんではないでしょうか。
そしてそれよりも大きな問題は、そういう待ち時間が発生するたび人間の集中力は途切れてしまうんです。人間の脳はタスクを始めるハードルが高く、しかし一旦タスクに取り掛かって集中し始めると前頭前野への血流が増え、逆に作業を止めにくくなるという性質があります。「始めるのが難しいが、やり出したことはやり続けられる」という特性を持った人間という生物が、仕事の最中に頻繁に作業を中断させられていたら、そりゃ生産性が落ちるのは当然でしょう。たとえば、電話着信があって作業を中断して電話応対を始めると、元の集中力に復帰するまで平均10分かかったなどという研究結果もありましたね。
だから、開発環境のスペックを良くして人間の待ち時間を減らすことは、目に見える時間以上に生産性を向上させるんです。
自分の話
自分は前職で相当に開発環境には苦しめられてきました。
入社して初めて与えられたPCはメモリ2GB、HDDなマシンでした。その当時はSSDがちょうど普及し始めた頃だったのでSSDを望むのは贅沢であったものの、メモリはそこらへんのマシンでも4GBくらい積んでるのが普通だった時代なので当時でもスワップと戦いながら開発を進めていました。
たまに人事異動などによって使われなくなったPCが発生すると、人が群がるんです。メモリが欲しいから。
でも新人には「新人だから」という理由でメモリの配給を受けるのは後回しにされました。そうして、主にExcelとWordしか使わない係長クラスのPCスペックがまず増強され、各種IDEを起動して、開発中のアプリをデバッグして…という作業をする新入社員や協力会社メンバーが使用するマシンは一番後にされました。
入社2年目に、「お前はいつもスペックに文句を言ってるから新しいマシンを買ってやる」と言われ期待して待っていると、またメモリ2GBの新品のマシンが届きました。意味がわからない。
CPUの世代は一つ上がっているものの、同じミドルレンジゾーンのCPUだったので性能向上も殆どなかったです。そればかりか、DVD-RWドライブが通常のCD-ROMドライブに変わっているという始末。当時、USBメモリの使用は禁じられていましたが、なぜかDVD-Rでのデータの持ち運びはOKという社内規定がありました。
「メモリとドライブを古いPCから移し替えていいですか」と聞くと、「ドライブを交換するのは良いがメモリは駄目。古いマシンは協力会社メンバーに回す」とのことでした。でも結局、その古いPCもメモリが取り外されて係長クラスのPCに増設され、実際にコードを書いている協力会社メンバーのマシンは古いままでした。確か、Core iが数世代出てた時にCore Soloとかのマシンが割り当てられてた気がするな…。
メモリが4GBになったのは入社して4年後くらいだったと思います。その時も、メモリは増設できましたがOSは32bitのままで64bit Windowsは「ライセンスも余ってないし買う予定もない、つーかメモリ分けてやったのにがめついんだよ、調子のんな」的なことを言われて、結局32bit Windowsの制限で3.2GBほどしかメモリを使えませんでした。
後に私も部署異動が発生しまして、それ以降、異動先はもっとバリバリにソフトウェア開発をするような部署だったので(それまでは原子力関係の部署だった)、以前よりはPCスペックに対する管理職の理解もあり、OSも64bit Windowsにすることができました。
また、ここでは周囲の先輩方から「余ってるから使っていいよ」と先輩方が自費で購入したメモリやSSDを使わせてもらうことができ、大変ありがたかったです。まぁ自費で買ってる時点で何かおかしいんだけど、自費で買ってもいいと思えるくらい、仕事へ影響があるというのは上層部には分かってほしかったですね。
あなたもさっさと自費でメモリを買えば早かったのでは？と思われるかも知れませんが、PCの蓋に物理的なキーチェーンが装着されており、かつ、それを外すために理由を説明をしなければならないのですが、担当者がクソ面倒くさいオッサンで「自費で買った物を業務用のPCに装着するな、データ漏洩の原因になる」とか言われて諦めました。DRAMでどうやってデータ漏洩させるんだよ、って感じです。もちろんそれも主張したのですが最終的に行き着く議論は「とにかくうちではそういう決まりになってる、何かあったときにはお前の責任だけじゃなくて管理職の首が飛ぶ」になるのでバカバカしくて諦めてました。
ともかく、異動と諸先輩方のご厚情に預かり私は何とかSSDにメモリ4GBのマシンを揃えることができましたが、協力会社の方々はやっぱり「Eclipseを起動し直してブレークポイントを張ってデバッガを起動するので5分待ってください」などと言う場面もありましたね。
前の部署では主にCとかC++での開発で、かつ「OSS資産は業務で使ってはならない」という謎のローカルルールがあったのでそこまで問題にならなかったのですが、異動後はJavaでWebベースのシステムを開発することになったので、maven等々を使って依存するjarをネットから取得する、ということが日常的に発生するようになりました。
ちょうどその頃はSSL/TLSなWebサイトが増え始めた時期でした。すると、従業員がどのサイトにアクセスしているかを監視したい人たちはE2Eで暗号化されるプロトコルだと困るわけです。なので、プロキシサーバでMITMをし始めましたんです。
このプロキシサーバはブラウザやOSが信頼している認証局で発行していない、所謂オレオレ証明書というやつで通信を行う仕組みになってました。すると、たいていのシステムでは「SSL/TLS通信の通信先が信用ならない証明書を使ってる」という主旨のエラーメッセージが表示されます。説明もなしに突然こんな措置をされたのです。
このためにmavenやnpmなど、ネット経由で依存するライブラリを自動取得するようなビルドツールその他が軒並みエラーを返すようになりました。これを回避するために、オレオレ証明書を発行しているオレオレ認証局を信頼できる認証局としてJDKやOS、ブラウザ等々に登録したりという作業をしていましたが、もうこれがすごくしんどいんですよね。基本的に試行錯誤の作業なので、これだけで半日潰れたりします。プロキシだけでも設定が大変なのに…。
ちょうどそのころは世間ではAWSはすでに普及しており、続いてdockerも話題になり始めていた頃でした。会社ではどちらも利用できませんでした。アクセスすると「あなたのアクセスしたページは閲覧が禁止されています（理由：オンラインファイル共有サービスのため）」と表示されていました。AWSやdockerがファイル共有サービスとはバカバカしいことこの上ないですが、おそらく「業務情報流出のリスクがあるため、ファイルをアップロードできるオンラインサービスはアクセス不可」みたいな言い分なんでしょう。そういえば、Slideshareなんかもアクセス負荷でした。
バカバカしいですが、この件に関しては「我々は親会社のインフラを使わせてもらっているので、子会社の一部門が動いたところでどうにもならない」という感じで、会社も対応してくれませんでした。そればかりか、mavenでmaven repositoryにあるjarを自動ダウンロードしてるなんてことがインフラ部門にバレたら今度はそこをターゲットにされかねない、みたいな雰囲気だったのでどうしようもできなかったです。
それでも、世間では散々にこれからはクラウドだ！！と騒がれてから数年が経っていたので、そろそろ我々もクラウドを使えるようにならないと駄目だ、みたいな意見が部長以上の層で議論され、最終的に「AWSは使えないので社内に開発用に使用できる仮想マシンサーバを構築しよう」という事になりました(記憶があやふやなので細部が間違ってるかも)。
別にVPSやIaaSだけがクラウドってわけでも無いんだけどなぁ…と思っていましたが、使用できるマシンリソースが多いに越したことはないので、私はそれを歓迎しました。部長からも「ごついサーバを買ったからな、これからはいくらでも仮想マシンで高負荷な作業を出来るぞ」と言われていたのですが、届いたのは32GBメモリが乗ったDellのワークステーション。一人でこれを使えるならば確かにまともな環境ですが、これを部内（プロパー40人位）の組織で使え、とのことでした。
それでも最初は私しか使ってなかったので、Jenkinsを動かしたり機械学習をさせたりなどといったことに大いに利用できていたのですが、そのうちに開発中のWebシステムを常時サーバで動かして検証用として使おうみたいな話になり、それらのインスタンスで32GBのメモリを一瞬で使い果たした上、「お前メモリ使いすぎ。落すからね」と言われて私が使えるリソースは最終的にほぼゼロになりました。
その他にも、必要なソフト・周辺機器であっても導入できなかったり、毎度説明に苦労したりということが重なり、「うちはソフトウェアを開発するための会社ではなかったんだな。たまたまソフトウェアに理解の無い製造業がソフトウェア開発をやってしまったんだ」と気づいて転職しました。そのころに書いた記事が以下です。
正確に言うと、入社2年目くらいのときにはすでにそれに気づいていたのですが、結婚出産などが重なりなんだかんだで愚痴をたれつつ7年も働いてしまいました。悪い会社では無かったですが、結局組織運営や開発環境、仕事内容の諸々が気に入らなくて辞めました。
組織を良くするのが従業員の使命では
以上が私の経験ですが、まぁ大体どこも同じような環境だと思います。なぜならば、ネットに投下された数多の体験談が「わかる…わかるわ…」と頷けるものばかりだからです。
IT関連の基礎知識を上層部が持っていなくて、意思決定が遅くて、何をやるにも稟議を通せとか、会社規則で認められてないという理由で一蹴させるとかいう組織を変えることは現実的には無理だと思っています。
しかしながら、こういう話をすると決まって
- エンジニアを名乗るのであれば非技術者層にも説明できる能力(と努力)があって然るべきでないのか
- まず従業員が自分の会社を良くしようと思って上層部の説得に動くのが筋ではないか。言われたことばかりやってるのが社会人じゃない
- GAFAに転職できるくらい優秀な人であれば自分の組織（日系企業）で頑張れば上層部も理解してくれたのでは
- 根拠も示さず「ITエンジニアの給料を上げろ、労働環境を向上させろ」では誰も動かない。数字を示せ
という謎の説教おじさんが出てきてたまに引用リツイートでそういうことを言われイラッとするんです。
違う…違う…。違うんですよ！！ここからが本記事で私が最も言いたいことです。
まず、なぜ彼らは「ITエンジニアが上層部を説得せずに不平不満ばかり言ってる」と思っているのでしょうか。いや、してます。相応に努力してます。
少なくとも私はそうですし、おそらく私と同じような悩みで転職した数多の人もきっとそうだと思うのですが、みんな必ず説得にかかってるはずです。まずはソフトウェア開発に必要な最低限の設備と環境は用意してくれと。
仕事ができねーんだから、仕事ができねーよって報告するのはごくごく当たり前のことで、普通の感覚を持った人ならば誰しも当然やることです。それでも駄目だから転職するのです。
転職って、結構精神的にも事務的にもコストがかかる作業です。それよりも、「仕事が進めらんないんですけど」と上司を説得にかかるほうがよっぽどコストが低い(説得と交渉を続け実際に導入されるまでにかかるコストはまた別だけど)作業で、普通に仕事してて困ってりゃみんな相談・陳情・説得してるはずなんです。
だから上層部を説得できてないんじゃないんですよ。説得したいなら無制限に説得したり、そのためにアホでも分かるような詳細な資料を用意することは可能なのですが、普通の人は「諦めて我慢する」「転職する」の方が「無制限に説得する」「アホでも分かる資料を作る」よりもハードルが低いので止めてしまうんです。転職するよりも説得して要求を飲ませる方が難しい状態の会社が多くネット上で報告されている、という状態が問題なんじゃねーの？ってみんな騒いでるわけですよ。
それなのに、なぜ件の説教おじさんは「上層部を説得する手間を惜しんでる」と思うのでしょう。
これは想像ですが、多分「説得すれば上も理解を示してくれるはず（それが出来ないのは単にお前の説明能力がヘボだから）」「従業員が仕事ができなくて困ってるのにそれを助けない経営者が居るわけがない」という、ファンシーな考えに囚われているんではないでしょうか。いや、現実に居るからみんな問題だって言ってるんだって。
大工が家を建てろと指示されて「しかしノコギリもトンカチもノミも釘も無いでやんす」と報告されたら、おお、そうか、そうだよな。用意するから待っとってくれ、となるのは普通のことなんですが、もしかしてこのレベルの印象で語ってるんかな？
IT業は大工業と違ってやや特殊なところがあり、専門分野の分化も激しいし、そもそも人類の歴史からみれば新しい工学分野だし、その文進歩も激しいので、CPUやメモリの性能が不足したら何が起こるかを正確に理解できていなかったり、MITMってなあに？みたいな人だったりするレベルの人が従業員の開発マシンの導入と運用を管理していたりする重要な役職についていたりすることがよくあるんです。だってパソコン使った事ない人がサイバーセキュリティ担当になって叩かれたでしょ？そんな文化圏の会社なんですよ？
IT系の知識が無いながらもIT部門の設備を管理しなければならない立場の人達にとっては、自分にとっては理解できないメモリの容量とかMITMがどうとか、プロキシがどうとか、SSDがどうとか、DDR DIMMがどうとか言われたってちんぷんかんぷんなんですよ。その良く分からないMITMだかSSDだかBIG MAC BURGERだか分からない謎の物体を購入しろ、さすれば生産性は上がるであろう、とか啓示じみたことをエンジニアから言われても理解できないじゃないですか。理解できないから、「本当に必要なの？」「本当にそれだけの効果が上がるの？」「数字を挙げて見せてくれない？」とかいう話になりますよね。
しかしながらソフトウェア開発の生産性って実は正確に測定するのが本質的に難しく、人類の知識がまだ十分に蓄積されていない感じで、仕方なくコードのステップ数とかファンクションポイントとか、良く分からない指標をでっち上げ「これで正確に表現できてるかなぁ…？」と半信半疑の手探り状態でやってるような分野なんで、そもそも「生産性」を定義するだけで論文が何本もかけるような感じであって、数字を出したり説得力のある説明を作るのが難しかったりするんですよね。
そういう難しい話を、全然予備知識ありませんみたいな連中に対して、「まずノイマン型コンピュータがありましてな…」「例えるならばメモリの大きさはメモ帳の大きさ、CPUは電卓なわけでしてな…」みたいなところから説明しなければならないのか？っていうと、流石に「指示されたこと以外のことも能動的に判断して動け」とか上から目線で言われたって無理ですよ。説明すること自体、専門の人を割かないと無理なレベルですもん。
そんな中で働いている折、GAFAとか良くわからない、所属しているだけで活性酸素が除去されて健康になりそうなイケイケな会社から、「良く分からんけどお前らの好きなようにさせたるわ、うちに来たら」とか、「我々はみんなエンジニア出身だし面倒なことを言う上層部も居ないですから好きにできますよ」とかいうオファーをもらったらグラッと来るよね？という話なわけなんです。
くり返し言いますが、「まずは上司を説得しろ」は事実だしそうすべきなんだけど、それが現実的にすごく困難だからみんな転職という道を選ぶわけで、そこが（一部の会社や日本企業が負けたら困る人達にとって）問題だよね？ってみんな言ってるんですよ。
以上を全部踏まえてですよ、踏まえた上で、それで「上司を説得しろ」とか言われても、いや、議論を最初から読んでってくださいとしか言いようが無いんです。横から見れば「説明もせずにITエンジニアが調子に乗って要求をゴリ押ししてくる」ように見えるので文句の一つでも言いたくなるからそうしてると思うんですけど、そこは議論の本質じゃないんです。っていうか、よく知らねーならしゃべんなよ、言葉の一部を切り取ってそれで判断して自信満々で説教するのって前頭葉が退化して理性が効かなくなった老害そのものなんだよ。それでも喋りたいなら「よく分かんねーけどこうなんじゃないの」ってエクスキューズを入れてから語れよ。そうしてくれよ。主に俺がムカつくから。ジャスト俺のためにそうしてくれよ。ぜひともお願いしますよ。と思う。
私が思う解決策
これ（開発環境がしょぼいことや、硬直した組織運営を理由に転職することを防止すること）を解決する方法って私は一つしか無いと思っています。それは、「転職のハードルよりも組織を変えるハードルの方を低くする」です。つまり、転職に至らせる前に不満になる種を積極的に摘んでいき、会社自体が従業員の意見をよく聞いて常に変化していくということですね。
具体的に言えば、IT関係の無理解から来る生産性の低さが問題であるならば、件の上司を説得しろおじさんが言うように説明を行い、上層部がそれを聞いて、予算等々の制約からうまい落とし所を見つけてあげたり、とりあえず小規模に初めて変化を観察してみるとか、そういうことを始めていきやすい組織運営と意思決定プロセスが重要だと思います。俺にその権限は無いから無理、とか、金がないか無理、とか、すごく難しい説明を要求する、とか、そういう実質的なゼロ回答を繰り返すから転職のほうがハードルが低くなるんですよ。
たとえば、実際にそうやって効果測定したり意見を聴取したりして、会社として出来ることを検討した結果、予算的な制約で出来なかった、とかであれば仕方ない(ただしその場合もいつ実施するかという調整は必要だが)と思うのですが、でもそこまでほとんどの会社はやってないと思うんですよ。むやみに複雑かつ重厚な意思決定フローにして自らを縛ってるから出来ないだけであって、本来は内輪の同意だけで済む話なので、ビジネスで金を稼ぐよりずっと簡単なことのはずなんですよね。
そういう環境を踏まえた上でもエンジニアがちゃんと説明できないからだ、エンジニアが説明しろ、やりたいと要求する言い出しっぺが権限のある人間を説得するのは当たり前のことじゃないか、という、要求側の一方的な努力に頼る方向で理解させようというのは、ちょっと精神論が過ぎませんかね？引き抜かれるのが嫌だったら、向こうよりも魅力的な条件を提示するしかないんですよ。「開発環境？好きにしていいよ。高いキーボードでも何でも買ってアマゾンの領収書ちょうだい」というやり方に魅力を感じる社員を引き止めるなら、少なくとも同等の条件を出さなきゃいけないんですよ。それをば、なんですか？GAFAに引き抜かれる優秀なエンジニアが会社のために上層部を説得するモチベーションはどこからくるとおもってんのよ？正義感や義務感に頼るような組織運営をしてるから駄目なんだよ。
なぜこういった正義感や義務感が度々議論に登場して「俺は正義だ」という厚顔を晒して人々をうんざりさせるのかというと、我々日本人はそういう「過程の美学」や「自己犠牲の美学」に取り憑かれているからだと思うんですよね。
たとえば、保守的でIT系の業務に理解のない日系企業に務めるAさんとBさんが居たとしましょう。AさんとBさんはITエンジニアとして戦える環境を整えようと発起しましたが、Bさんは途中で理解のない経営陣に愛想をつかしてGoogleに転職して無料のランチを食い、1000万の大台を超える給与をもらい、裁量労働制で、夜は六本木のバーで飲む生活をおくるようになりました。一方でAさんはBさんが居なくなったあとも頑張って上司を説得に周り、「Aはいつも自分の要求をゴリ押ししてきてしつこい」などと疎まれながらも主張の正しさを日々伝え、少しずつAさんに同調する管理職を増やしていき、最終的にはITエンジニアが使用するPCはメモリ最低16GB、SSD搭載のものを割り当てることを確約させました。でも年収は600万から上がりませんでした。
AさんとBさんについてどう思いますか？
「Aさんは苦労をしたが、最終的に会社を良くしたのだから、その点は偉い」と思いました？
「Aさんの年収はBさんよりも低いが、しかし会社を良くしたのだから価値のある行動であった」と思いました？
それがっ！駄目なんだって！ことですよっ！！！
Aさんははっきり言ってスーパーマンです。給与も上がらない会社でときに人に疎まれることがあっても、会社を良くするために組織に働きかけ続けました。その行動自体には何の追加の報酬もなかったですが、結果的に多くの人が幸せになりました。
こういう自己犠牲的な精神を発揮できるスーパーマンはそういません。だからこの種の話はプロジェクトXみたいな雰囲気を醸し出しつつ美談として取り上げられることが多いのですが、Aさんみたいに自分を犠牲にして周囲のために尽くすっことが出来る人は多くないですし、そもそも自己犠牲の精神を賛美すべきでないと私は思います。
だって、自己犠牲の精神の延長端に位置するのは神風特別攻撃隊や回天や桜花ですよ。
全体のために個人が犠牲になることを許容すると、組織全体は犠牲の大きさ分、無償で利益を得ます。これは組織にとってはとても美味しくて魅力的で簡単に利益を得られる方法です。だから、いつか権限を持った人は権限を持たない人や立場の弱い人にそれを押し付けるようになります。「みんなのために」という錦の御旗を振りかざしてね。そういうことになるから自己犠牲はクソだと我々は言っていかなければならないのではないですか？大戦や数々の過酷労働に起因するうつ病だの自殺案件だのから、我々は何を学ばなければならないのでしょう？
だから「エンジニア（やその他特定の何か）が自分の人生を犠牲にして会社を良くしていくべき」みたいな自己犠牲を強いるのをまず止めましょうよ、あなたが自己犠牲を強いてると思って無くても実際強いてんだよ、だからそれをやめろ。というのが一つ。
つぎに、同じ問題をちょっと違う聞き方でしましょう。
保守的でIT系の業務に理解のない日系企業に務めるCさんとDさんが居たとします。CさんとDさんは、どちらもITエンジニアとして満足の行く労働環境で働きたいと思う願望がありました。Cさんは頑張って説明を何度も何度も行い、日々上層部を説得し、なんとか組織を変えて満足の行く労働環境を得ました。一方でDさんは見切りをつけてさっさと転職し、おしゃれなオフィスのベンチャー企業に入社してセクシーなWebサービスを開発することで満足の行く労働環境を得ました。CさんもDさんも幸せに過ごしました。
この二人についてどう思いますか？
「Dさんは早々に見切りをつけたけれど、Cさんは組織が変わると信じて努力したのだから偉い」と思いました？
「早々に見切りを付けたDさんはちょっと薄情。残された人の気持も考えるべきでは」と思いました？
それがっ！駄目なんだって！ことですよっ！！！ダメダメパート２ですよ！！
結果的に両方共同じ結果はえられたけれども苦労した分Aさんの方が偉く、早々に組織を見切ったBさんはちょっと薄情かも、みたいな考え方っておかしいと思うんですよ。結果同じだったら過程は関係なくないですか？もちろん、違法で不道徳をして達成したことと、真っ当なやり方で達成したこととでは、前者よりも後者のほうが良いのは当然ですが、どちらも道徳的・法律的に問題ないやり方で目的を達成したなら、どちらも同じじゃないですか？
というか、そもそも薄情とかいう考えが主観的な決めつけであって、AさんもBさんも生きていくためには金を稼ぎ、時に家族をも食わせていかなければならないわけであって、そんな折によりよい労働条件を提示する会社が出てきたらそっちに行きたいと思うのは普通じゃないですか？どこが薄情なんです？ここまではっきりと分かる例は少ないですが、言葉の節々から組織へ忠誠は当然だと思ってるのが透けて見える人って結構いますよ。
一方で、忠誠とか、薄情とかいうのは置いといて、でも苦労した結果Aさんのほうがその分得るものも多かったのは事実だよね？だからAさん偉いよね？と主張する人も居ると思います。でも過程で得るものが大きかったらそれは結果が同じじゃなくなるんで前提が崩れるんですよ。
このたとえ話で言うならば、Aさんは説得する過程で「パソコンの基礎の基礎を初心者に教えるスキル」を身に着けたけれども、しかしAさんはその後の人生でもパソコン教室の講師などにはならなかったので、その経験を活かすところはなかったという場合を想定し考えたらどうですかね。それでもAさんのほうが偉いとおもうかどうかということですよ。例えば役に立たない経験だったとしても、苦労した分人間には成長しているだろうから人間的に深みが出るとか思うかどうかってことですよ。思います？どう？苦労したほうが良かった？苦労して稼いだ金は苦労せず得た金よりも尊い？どう？
たとえそこまで厳密に得たものを一致させなかったとしても、Aさんに苦労の末得たプラスアルファの経験が存在するならば、Bさんにだってそういう組織運営のいざこざに費やされる時間分を自分の成長に当てることが出来るのでもっと成長できてると考えてなきゃフェアじゃないんですよ。
何が言いたいかというと、「つまり苦労した分何か偉くなってる」という予想は過程を必要以上に重視してしまった結果じゃないですか？そうならば、それは良くないよねってことです。
苦労自体を目的とする人は居ないのであるから、苦労した分得られるものが多かったというのは棚からぼた餅が落ちてきたという話と等しいです。棚からぼた餅が落ちるのを期待して所構わずすべての棚を漁るひとを「いやぁー、頑張ってるわぁ…頑張って流す汗は尊いわぁ…」とか思ったらアホですよね？
人生のうちでそういう遠回りしたけど結果良かったよね、みたいな経験はよくある話ですが、しかし人生の回り道も味わい深いよねーってレベルの話を仕事の生産性に適用することってなんか意味あんの？ビジネスの場面で苦労を美徳にするのに、そういうのを美徳として感じる人の心の安寧を図るという以外に意味あんの？ってことですよ。
本気で生産性を上げたかったら、むしろアウトプットになんら価値を付加しない作業はどんどん切ってくべきで、「生産性を向上するために苦労して流す汗そのものが尊い」とか本末転倒じゃね？と思うんだけどどうよ？
過程を褒める、つまり「理解のない保守的な会社を自力でなんとか改革していって良い会社にした」のと、「最初から良い会社の方に入る」のとでは、「いい会社」の条件が同じならば従業員個人が受ける利益も同じはずなのですが、なぜか前者のほうが世の中では良いとされたり、美談として語られたりします。これは、結果ではなく過程を重視していると言わざるを得ません。
過程を褒めるのは幼児教育では重要だという研究結果もあるんですが、でもここでの登場人物に幼児出てきてないんですよ。大人しか出てきてないんですよ。それなのに、頑張ったねぇ～偉いねぇ～とか言うのってはっきり言って幼稚だと思うんだけど、どうなの？そこんとこ。
まとめ
- 生産性に影響がある程度に低いスペックのマシンで開発を行っている会社はたくさんある
- スペック以外にも会社運営が根本的にソフトウェア開発に向いてないのにソフトウェア開発業務に手を出してる会社もたくさんある
- 多くの従業員はそれを指摘する
- しかし改善されない会社は多い
- それが理由で転職する人もいる
- その中には優秀な人達もいる
- その状態を鑑みた上で「転職ではなくて自分の組織を正すべき」というならば、それは自己犠牲の精神を押し付けているに等しいと思う
- 自己犠牲の精神は常にクソだと主張していくべき
- 「転職するよりも自分の組織を頑張って変えて得た環境の方が価値がある」というのは過程の美学に囚われすぎていて無駄な作業を許容してしまっているし、議論の本質をすり替えようとしていると思う
- 上記のような問題が元で転職者を増やしたくないのならば、転職するハードルよりも会社を変えるハードルを小さくするしか無いと思う
以上、事実とそれを踏まえた私の主張です。
以上を読んでくださったあとでもなお、「エンジニアは経営層を説得すべき」と思うのなら、どうぞそう思っていてください。思ったり主張したり主張に基づいて行動するのは自由です。エンジニアは経営層を説得すべきおじさんを投獄・拷問するための政治将校を派遣することは私には出来ないですし、日本社会は自由に言いたいことは言っていいよという社会になってるのです。だから私にそれを止める権利はないですし、ここで書いたことも私の一つの主張で、皆がそうしろとも言ってません。私の主張よりも良い筋の主張も当然有るでしょう。
でも、「エンジニアが頑張って説得しろ」の結果GAFAに人材を抜かれたとか、労働者が経営層を説得できないから悪いとかブー垂れるのはみっともないし見ててイラつくので止めろ、とは思います。あと、「エンジニアは経営層を説得すべき」という論が絶対正義だという自信をもち、皆もそうしろと強要するのは迷惑なので止めてください。
つーか、冷静に考えてほしいのですが「エンジニアは経営層を説得すべきでないか」と言われて「なるほど！確かにそうだ。俺は感銘を受けた。Googleに転職しようとおもってたけどそれは止めて今の組織に尽くそう」と思う人は殆ど居ないと思いますよ。そんな原理原則に囚われた正論の話なんて分かってるし、もう聞きたくないんですよ。だからこそこうして転職エントリが話題になっているという事実をもう少し冷静に考えてみたらどうかと思います。
あともう一つ、似たような話で主にアメリカのITエンジニアの給与を引き合いに出して「エンジニアの給料をもっと上げるべき」という論があるのですが、私はこれには同調していないです。何故ならば技術的に難しいことをやってるから高い給料をもらえるのではなくて、儲かっている国家・地域で、儲かっている分野で、競合に勝てるビジネスをしている会社があって、その中で相応の貢献をしている人が高い給料をもらえるのが普通だからと思っているからです。
おわり。
