『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』という映画をTSUTAYAでレンタルして見た。あまりに内容がドラマティックだったので、これはどこまで脚色されているのだろうかと思って、もとのスレッドがまとめられているwikiサイトで記述をざっと読んでみた。驚いた。ほとんどスレッドに書かれていることが忠実に再現されているように見える。

考えさせられたのが、ここに描かれているのは組込みとITの違いがあるにせよ、同じソフトウェアを作るエンジニアの日々の風景だということだ。

この話しは本やコミック、映画になっているが、知らない人もタイトルを見れば、だいたい中身の予想は付くだろう。映画の中では R25 にブラック会社の条件が6つ書いてあり、主人公のマ男君が入社初日で全部当てはまることに絶句する。

【ブラック会社の条件】

1. 就業規則があるにも関わらず残業が当たり前
2. 何日も徹夜が続くことがある
3. 社内に情緒不安定な社員がいる
4. 必要経費が一切認められない
5. 同僚のスキルが異常に低い
6. 従業員の出入りが激しい

そして、確かにそういう会社がスクリーンに登場する。ちなみに、それはそれとして自分は主人公のマ男君や他のプロジェクトメンバーがやっている仕事の内容、流れについて見ていた。

【仕事の流れ】

1. 営業がクライアントから仕事を取ってくる。
2. 同行した技術担当は要求された仕事に対して開発期間が足らないと感じる。
3. 技術担当がクライアントにその日程ではムリと言おうとするとクライアントからダメなら他に回すよといわれ営業が受けてしまう。
4. 開発委託を受けた時点からすでにデスマーチが始まる
5. 納期に対してプロジェクト全体が責務を負い、遅れは分散するか特定のエンジニアへ集中させることでカバーする
6. 要求定義→設計→実装→テスト という工程はキチンと踏んでおり、プロジェクトの終了はシステムテストの成績書がすべてパスしたときになっている。
7. 死ぬほど残業してなんとか納期に間に合わせる。

そこでふと思ったのは、仕事の厳しさの違いはあるにせよ、この流れはどんなソフトウェアエンジニアも多かれ少なかれ経験しているようなことにように見えるということだ。

ブラック企業になるかならないか、もしくは、エンジニアが潰されてしまうかいなかの違いは、3のムリな日程を受けてしまうという部分と、5 の遅れの分散と特定のエンジニアへの仕事の集中のところだと思う。

【ムリな日程を受けてしまう営業】

クライアントとサプライヤという関係の場合、一般的にお金を払うクライアントの方が立場が強い。「イヤなら他に回すよ」と言われたら条件を飲まざる終えない。その条件を跳ね返すためには、ムリな日程を飲む以外の付加価値が必要になる。その付加価値が他の会社にはない価値でなければ競争に負けてしまう。

メーカーの場合、お金を払ってくれるのはエンドユーザーであり、リリースして商品が売れるか売れないかが分かるにはそれなりのディレイがあるから、請負開発の場合はよりプレッシャーが大きいと思う。

この問題は会社の経営者の考え方と経営方針で決まるのだろう。エンジニアを薄給でこき使って使い捨て目の前の売り上げを確保するという考えを持っているか、顧客満足を実現するのはエンジニアであり、顧客満足とエンジニアの満足・成長の両立を考えるのかで 180度環境は変わる。

後者よりも前者の会社に仕事を出すクライアントが多いとエンジニアにとって状況は改善しない。二次、三次といった下請け構造があると、下の階層になるほど環境は悪くなる。

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』の主人公は、実力はあり、唯一近くにいたよき先輩に鍛えられてブラック会社の中で成長するのだが、ブラック会社にしか入れなかったのは学歴で能力を判断されてしまったからだった。

もしこの話しが本当であったのならば、マ男君は死ぬほど苦労したが、3年間でプロジェクトリーダーを一回経験しプロジェクトも成功させたのだから、その実績を使ってもう少し環境のよい会社や、クライアント企業への転職などもできるのではないかと思った。ようするに、学歴以外の実績は実際の仕事を成功させることで積み重ねることができると思うのだ。

【遅れの分散と特定のエンジニアへの仕事の集中】

これは「あたたかい人間関係の中のやさしい一員」という日本人の特性のよい面と悪い面が両方でていると思う。プロジェクトの中で職制がはっきりしておらず、遅れを全体でバックアップするというやり方は連帯感を生むメリット、達成感を共有できるメリットがある一方で、個の確立を疎外する側面もあると思う。

技術者個人の成果や負荷が見えにくくなると思うのだ。責任と権限が明確な世界では他人の領域には指示がなければ踏み込まないから最終的な責務と成果が個人別にはっきりする。

それが曖昧だとブラック会社では優秀なエンジニアに負荷が集中し、その成果はプロジェクト全体に分散されてしまう。ブラック会社でなくても日本の企業ではそういう傾向があるように思う。

そうすると優秀な技術者が潰される可能性が高くなり、かつ、その様子を見ている他の技術者は積極的に仕事の効率化を目指さなくなる。

【『ブラック会社に勤めてるんだが、もう俺は限界もしれない』スレッドより引用】

スレタイの意味・・・
それは、木村くんの下克上でも、父ちゃんの病気でもない。
藤田さんが、会社を去る・・・。まさにこれこそが限界だったのだ。

何のためにスレッドを立てたのか。
確かに俺は限界だった。
このスレッドを立て、全てを書き終えた時、俺は退職しようと心に決めていた。
伸びても、伸びなくても、それは変わらない。
結果的にスレは物凄い勢いで伸び、パー速に移住するほどになってしまった。

そして、その中で俺への励まし、心配、叱咤。
色々なレスが俺に向けられて書き込まれた。
ブログのコメントは、続きを書いてくれ、という内容ばかりだった。
俺は今まで、誰からも必要とされない、居なくなっても誰も悲しまない
くだらない人間だと思ってたんだ。

だけど、このスレを立てた事で
俺はみんなから励まされて、心配されて、叱咤されて・・・
たった一人の力は確かに小さいかもしれない。
だけど、それが何十、何百となったら？
その小さな力が集まって、大きな一つの力となったら？

俺は奇跡を信じる気になったよ。
だって、スレッドタイトルが変わるんだもの。
『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』が
『ブラック会社に勤めてるんだが、まだ俺は頑張れるかもしれない』に。

【引用終わり】

スレッドの最終章を見ると、マ男君を支えたのは先輩の藤田さんと、ブログで応援してくれた人たちというだということが分かる。

ソフトウェアエンジニアは知識労働者だ。人間が人間の頭で勝負している世界だ。そう考えるとやっぱり人間を人間として扱ってもらえる環境と人間の頭を成長させてくれる環境と、自分自身の知識労働者としての意欲が大事であるということが『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て再認識した。

ポイントは実績がないときには、今の仕事を成功させてその中で達成した他から認められうる点を積み重ねてそれを武器にすることだと思う。そのためには今の仕事をやっつけでいい加減にこなしてはいけない。この一つ一つの仕事をまわりに自慢できるくらいきっちりこなして積み重ねることができれば、よりよい環境に進むことができるとはずだ。

組込みソフト開発悪循環の構図

組込みソフトウェア開発の悪循環のシナリオを考えてみた。想定する具体的なシチュエーションを示してから、その問題の解決方法について考えていきたい。

【組込みソフト開発悪循環のシナリオ】

1970年代、組込み機器開発の世界で、ソフトウェアはハードウェアとハードウェアをつなぐつなぎ役だった。組込み機器にはセンサーやアクチュエータが使われ、これらをいかにうまく制御して、顧客満足の高い製品を作ることができるかどうかが組込みソフトエンジニアの腕の見せ所だった。組込みソフトエンジニアという職種は確立しておらず、エレクトロニクスの勉強をしてきた技術者がマイコンのアセンブラを覚えて制御ソフトを書いていた。ソフトウェアの規模はせいぜい1000行くらい。ソフトウェア技術者はプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。

※好循環の道を歩むソフトウェア技術者はフローチャートやブロック図を描いてソフトウェアの構造を分析していた。その程度でなんとかなるくらいの規模だった。構造化プログラミングを意識している者もいた。

1980年代、8ビット、16ビットのCPUが次々と登場し、さまざまなペリフェラルデバイスが組み込まれたワンチップマイコンを組込み機器に使うことが多くなってきた。ソフトウェアを記述する言語はC言語が主流となり、リアルタイムOSも徐々に普及しはじめ、ハードウェアエンジニアとソフトウェアエンジニアは職種を分けるようになってきた。リアルタイムOSが普及することにより、ソフトウェアエンジニアがソフトウェアをモジュールに分割することを考えなければいけなくなる。悪循環の道を歩むソフトウェア技術者は相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストを行い実機で検証をしていた。LCDなどの表示用のユーザーインタフェースデバイスも普及し、プログラムサイズは数千行くらいに増加していた。

※好循環の道を歩むソフトウェア技術者はソフトウェアの振る舞いについて分析する際に状態遷移図や状態遷移表、データの流れを考えるために構造化分析手法が使っていた。

1990年代、組込み機器におけるユーザーインタフェースは飛躍的に向上し、スタンドアロンで動くだけでなく他の機器と通信をしたり、ネットワークにつながったりするようになった。CPUも16ビット32ビット64ビットと次々に高性能なものが登場し、ソフトウェアの規模が数万行になっても処理はオーバーフローしなくなっていた。悪循環の道を歩むソフトウェア技術者はソフトウェアの規模が数万行になっても相変わらずプログラムを試行錯誤で作り、実機レベルでランダムテストをしていた。コードレビューも言葉は知っていたがプロジェクト内で習慣化するところまでには至っていなかった。ソフトウェアシステムの増大の対応策としては、過去に使ったソフトウェアの一部を流用したり、前回担当した機能を作った技術者を今回もアサインするなど、特定の技術者に役割を分担させ、その技術者を何世代もの製品開発に使い続けるというアプローチを取った。そのため、社員や協力会社の社員が担当から外れるととたんに開発の効率や品質が下がったりした。担当者を外したプロジェクトマネージャ本人もその原因がよく分かっていなかった。

ソフトウェアの規模が数十万行にもなり、複雑度が高くなって、分かりにくいバグが増えてきた。ソフトウェア開発の工程が進めば進むほど、ソフトウェア技術者の残業が増えるようになり、新しい技術を学ぶ余裕がなくなってきた。

※好循環の道を歩むソフトウェア技術者は、ソフトウェアの大規模・複雑化に対して何か手を打たなければいけないと気づきはじめ、ソフトウェアシステムをサブシステムに分割する方法や、サブシステム同士のインターフェースをきちんと決めて役割を分担するなどくふうをするようになる。

2000年代、組込み機器にも多様な要求が降りかかってきて、組込みソフトの規模も数万行から数百万行まで幅広くなってきた。規模が大きいソフトウェアシステムほどプロジェクトが遅れたり破綻したりするようになる。ソフトウェアエンジニアの残業時間はピークに達しており、月あたりの残業時間が100時間、200時間という者も増えてきた。しわ寄せは、特に下請け、孫請けの協力会社の技術者がかぶることが多く、ソフトウェア技術者になりたくないと考える若者も増えるようになる。失敗プロジェクト、開発日程の大幅遅延プロジェクトの開発スタイルと見ると、1970年代と同じプログラムを試行錯誤で作り、実機レベルでランダムテストを行い検証をしていた。設計工程の後半で発生する月に100件以上のバグのうちのいくつかは非常に分かりにくい複数のモジュールが関係する不具合であり、数日もしくは一週間以上かけないと原因がわからないようなバグであった。

2000年代になると組込み機器のユーザーインタフェースも多種多様な表現方法ができるようになり、試作品ができた後に、試作器を手にしたステークホルダーが「もっと、こういうインタフェースにしよう」などと言って大幅な仕様変更を指示することも多くなるようになった。ソフトウェアプロジェクトにおいてプロセスを切って、確認してから前に進むことの必要性を認識していない上司（1970年代の試行錯誤でソフトウェアを作っていて特に問題が起こっていなかった世代）が上にいると、ソフトウェアの変更容易性から最後の最後で右に向いていたものを左にしろなどということがあった。

ここから、『熊とワルツを』（トム・デマルコ/ティモシー・リスター）より引用

・・・約束した納期に間に合わなくてもよい、大幅に遅れてもかわまないが、その日までの間、期日に間に合いそうにもないと言ってはならないということだ。事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される。このルールを言い換えると、遅れたことに対して後から「赦し」を請うのはかまわないが、遅れることに対して前もって「許し」を求めてはならない。

　：

このような制約があると、「選択的近視」という感染症になりやすくなることがある。この条件を突きつけられたプロジェクトでは、小さな問題しか見えない。健全なプロジェクトでは視野の真ん中に見えるようなおおきな問題がすぐそこに迫っていても、選択的近視にかかった人にはまったく見えない。

－引用終わり－

ソフトウェアプロジェクトのリーダーとメンバは、製品の開発計画を突きつけられたとき直感的に「（いままでの試行錯誤的な開発を行っていたのでは）この日程では間に合わない」と感じる。しかし、『熊とワルツを』にあるように、運がリスクを消し去ってくれるのではないかと期待している。期待するだけでリスクと正面から向かい合うことはしない。また、楽観主義（嘘をつくこと）があたりまえの環境でプロジェクトマネージャーだけが真実のリスクを話すと、「やる気がない」とか「あいつはネガティブだ」という烙印を押される。そういう環境ではその日が来るまで期日に間に合いそうにもないと言えないので、プロジェクトリーダーはダメだと分かっていても、その日まで最大限努力したというポーズを作ろうとする。メンバは組織上位層にポーズを取る必要はないが、期日に間に合わないことを知っているから、「組織は、また、無理な日程を押しつけている」と感じ、プロジェクトリーダーがかわいそうだと思いつつ残業を続ける。（あたたかい人間関係の中のやさしい一員の特徴）　そして、プロジェクトメンバは組織上位層のことを「無理な日程を押しつけるソフトウェアを理解していない人種」と考え、ソフトウェア開発の現場でどんな問題が起こっているのか説明しても無駄だと考えるようになる。

この状況においてソフトウェア開発の現場がやっていることは、1970年代と同じ「試行錯誤的開発アプローチ」だけだ。場合によっては、構造化設計をちょっとだけやっていたり、ソフトウェアの構成管理だけに力を入れている状態かもしれない。いずれにせよ、ソフトウェアの規模・複雑化の増大に対する抜本的な対応は取っていないので、日程にも間に合わないし品質も上がらない。

この状態が長く続くと、組織上位層も原因は分からないが、ソフトウェア開発に問題があることに気がついてくる。品質に関する問題でお客さんに迷惑をかけることが多くなり、開発日程についても「事前に失敗するかもしれないことを認めるという大罪を犯さなければ、失敗は容認される」とは言えなくなってくる。

そうなると問題の矛先は特定の個人や協力会社に向いてくる。「やっぱりあいつじゃダメか」とか「あそこに仕事を出したのが間違いだった」ということになり、人やソフトウェアの発注先を入れ替えたりする。しかし、試行錯誤的な開発アプローチでは、ソフトウェアシステムの機能・責務の分割と割り振りを人ベースで行っているため、人の入れ替えは開発効率や品質悪化の原因になってしまう。

かくして、組込みソフトの開発は遅れに遅れ、品質は下がり、組込みソフトエンジニアの残業は増え、職種として若者から敬遠されるようになり、優秀であればあるほど仕事が降りかかってくるようになり、中にはプレッシャーに潰れてしまう者もでてくる。労働力を補充することで状況が打開できると勘違いする組織が協力会社や派遣社員に頼るようになり、技術的にも空洞化する。

これが、組込みソフト開発悪循環のシナリオ＆構図である。

【組込みソフト開発の悪循環から抜け出す方法】

組込みソフト開発の悪循環から抜け出す方法が簡単に分かれば苦労はしないが、悪循環脱出のきっかけは特に組込みソフトの歴史や日本人の特性を考えると、「意識改革」と「技術導入」をセットで進めることが重要ではないかと最近考えている。テーマは多すぎると散漫になるので3つだけだ。

－組込みソフト開発の悪循環から抜け出すためにすべきこと－

1. 品質文化と設計の規範の確立
2. 価値観の一致
3. 試行錯誤的アプローチからの脱却
   

<品質文化と設計の規範の確立>

組織やプロジェクトに品質文化がないとルールは形骸化し新しい方法論は難しいからイヤだと敬遠される。また、設計の規範がないと、過去に発生した問題を教訓にすることができず、プロジェクトリーダーが技術的なリーダーシップを発揮することができない。

品質文化と設計の規範の確立という「意識改革」の具体的施策の第一歩としては、ソースコードの行数を数えグラフを描いて可視化し、不具合（バグ）を紙や電子的に管理することをおすすめする。ちなみに、この2つがキチンと行われていない状態から習慣・慣習化するのはとても大変なことである。もしも、この2つがクリアできたなら、変更管理、構成管理についてできるようにしよう。

品質文化と設計の規範の確立におけるポイントは、どんな小さなことでも習慣・慣習化するまであきらめないことだ。

<価値観の一致>

次のテーマは価値観の一致だ。悪循環のシナリオに書いたように、問題は組織上位層とプロダクトマネージャ、ソフトウェアプロジェクトリーダー、プロジェクトメンバ間の間で、言葉が通じ合っていないことに原因がある。

ソフトウェア特有の言葉や環境が通じないから説明しても無駄だと感じ、上はとんちんかんな要求をし、下は無視（最初から無理だと考え思考停止）し、中間層は板挟みになって苦しんでいる。

この状態を打開するには、この三者が共通の価値観のもとに問題に正面から向き合わなければいけない。その価値観の共有は、製品に対する市場要求・ユーザー要求を実現しているソフトウェアの機能や性能が何かを可視化することで実現できると考えている。（組込みプレス vol.8 特集1 を参照のこと）

価値観の一致に対するキーワードは徹底した顧客志向だ。お客さんのため、顧客満足を高めるために○○の技術を導入したいとか、ツールを買いたいとか、教育を受けたいという主張が悪循環からの脱出につながる。

<試行錯誤的アプローチからの脱却>

21世紀になっても試行錯誤でソフトウェアを作り、ランダムテストでバグ出ししているようでは、悪循環から抜け出すことはできない。まず、そのことを認識する、意識改革しなければソフトウェア技術者としても成長が見込めない。組込みソフトの場合は黙っていてもその仕事に関わっているだけでドメインの知識が蓄積されるため、一見成長しているように錯覚することがあるが、技術的にはほとんど1970年代と変わっていないという状況もあると推測する。

試行錯誤的アプローチから脱却するためには、まずはソフトウェア開発のプロセスアプローチがなぜ必要なのかを自分の頭で考えることが必要だろう。開発の後工程で大きな仕様変更を受容してしまえば、多大な後戻りが発生し、バグを生み、日程を遅らせることくらい少し考えれば分かる。問題は、それを防ぐために工程を切って、どの工程で何をやるのか決めてそれを守ることができるかどうかだ。

開発の後工程での仕様変更を受容したり、跳ね返すためには、変わりにくい部分と変わりやすい部分を分離するソフトウェアシステムのアーキテクチャ設計が必要になる。また、ユーザーインタフェースの変更要求に対しては、商品コンセプトを明確にし、最初の計画したユーザーインタフェースがその商品コンセプトに基づいて作られていることを説明できるようになることも必要だろう。テスト技術がソフトウェア品質の向上に付け焼き刃ではなく、本質的に効いてくるのはプロセスアプローチがキチンとできるようになってからだ。

組込みソフトウェア開発の悪循環から脱出するには、意識改革と技術導入をセットで推し進める必要がある、これは本当にそうだと思う。