日本では従来から長時間労働が問題視されている。パフォーマンスの低下どころか、健康面の悪化のリスクは比較的多くの人に認識されている。更には、生活面とのバランスが崩れ、育児に時間が取れず、少子化に至る社会的な問題でもあるとの指摘もある。
その要因を多方面から探っていく。
長時間労働に巻き込まれると悩んでいる人にとって有益な情報であってほしい。
1.長時間労働問題に着目する背景
私は社会人になって長年、「IT業界やソフトウェア開発における長時間労働の原因は、自分のスキル不足である」と思い込んでいた。実際に、この内容は私が新卒で社会人になってから10年強の間、自身のキャリアにぴったり当てはまっていた。しかし、それ以降の出来事やそれに関する分析により、上述の思い込みは根本から覆ることとなった。
これまで色々な開発現場でソフトウェア開発に携わってきたが、中でも私が一番最初に配属された現場が一番長かった。
この開発現場では、新卒1,2年は終電帰りの日あり、休日出勤があるなど、ブラックな状態が続いたが、その後スキルも身に付いて段々とやりがいを感じ始めるようになった。
更にその後は自動化ツール作成などで仕事効率が良くなり、高度な資格試験の対策ができるようになるなど余力ができた。
この開発現場だけで見ると、最初に苦労して後々成長を感じる流れであった。周囲の人間から見ても、若いころに長時間労働に耐え、成長し、その結果今があるという認識であった。
しかし、開発現場が変わり、プロジェクトが変わり、慣れない環境に馴染まず、久々に長時間労働に巻き込まれる。そして体調に影響を与える。
また、別の開発現場では残業禁止で健全な生活を送りながらプロジェクトに成功するという期間もあった。
同じ能力、同じスキル、同じ性格の人間が、あるときにはブラック労働に巻き込まれプロジェクトが混乱し、またあるときには健全な生活を送りながらプロジェクトに成功する。
どうやら自分のスキル不足ではなさそうだ。もっとほかに原因がありそうだ。
世間一般、業界一般を調べてみると「自分のスキル不足」とは全く違う。「自分の仕事が遅いからだ!」と自分を責めすぎることが無いように、長時間労働問題の背景や実態を知っておく必要がある。
また、これらの知見を元に、根本的にどこに問題があるのか正しく見極める必要がある。
外的要因でありながらも、長時間労働に巻き込まれるのは、優秀な人材であってもパフォーマンスや生産性は落ちるし、勿体ない話である。
以上が、私が長時間労働問題に着目し拘る理由である。
2.これまでの経験上の具体的内容
ソフトウェア開発によくある長時間労働の具体的要因を、これまでの経験を踏まえて思いつくままに挙げていく。専門家の見解については別記事で書いているので、ここではそれ以外に感じたことを書いていく。
(1)市場でほとんど使われることのない機能の搭載
「競合他社との差別化」を謳い多くの「機能」を搭載しようとしている。企画部門、営業部門等が「機能が多いほうが優位」、「同業他社がやっているから」のような理由で、〇〇機能、△△機能、・・・・、ソフトウェアに負荷がかかるだけである。
そもそも、追加しようとしている機能は
- 「市場で必要なのか?」
- 「顧客に何らかの価値を与えられるのか?」
の観点が必要である。
(2)ビジネスとITにおけるミッションの分離
ITシステムを発注する側は「新たなニーズに対応」「コスト低減」等、何らかの「ビジネス」に活かしたい意図がある。一方、ITシステムを受注する側は、「発注側の要求通りのものを作る」ことがミッションと考えてしまう。
発注側、受注側が異なる企業であれば、企業間の契約関係が成立するためである。発注側、受注側で目指すゴールにずれが生じ、無駄な工数や手戻りが発生してしまい開発における生産性が悪くなってしまうことがある。発注側と受注側が一体となって進めていかなければならない。
(3)プロセスのミスマッチ
派生開発推進協議会代表を務められていた清水吉男氏の講演によると、派生開発に対して新規開発のプロセスをそのまま適用しているケースがある。これは「新規開発崩し」と呼ばれており、派生開発プロセスのNG手法の1つである。実際この「新規開発崩し」のプロセスで破綻しているプロジェクト現場を見たことがある。
o08usyu7231.hatenablog.com
(4)多重下請け構造と丸投げ体質
ピラミッド型構造における下位層の企業には最低限の情報しか伝えられない。コミュニケーションも多段階にわたって行われているため、大元の発注元の意図が開発現場末端にまで伝わりにくく、ロスが多い。セキュリティのためか、そもそも何の製品を開発しているのかすらわからないプロジェクトもあった。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
(5)見積もり段階での情報が不十分
スケジュールを臨機応変に調整できるならいい。一度決めたスケジュールは守るという根性論が強ければ、簡単に過重労働になる。「見積には十分時間をかけて行うべき」という情報もあり、見積り精度を上げるために、解析や設計に着手した結果、円滑に進んだ事例あり。
(6)計画時の楽観視?
「資料があるから(早くできる!)」と言って短いスケジュールを設定させようとする依頼者がいる。見た目は立派な設計書でも、読んでいてスムーズに理解できないことや、細かすぎて知りたいことをすぐに知ることができない、目的にあったとはいえない資料を丸投げされ、解析に時間がかかる。ベースソフト、移植参考ソフトの開発当時が過重労働だったなら、設計資料が最新でない可能性あり十分注意が必要。技術的負債による悪影響である。ソフトウェアを類似製品から「移植するだけ」、「持ってくるだけ」など、あたかも簡単に対応できるかのように匂わせ、短納期での約束へ誘導するような、詐欺商法と同じ手口を取る顧客もいる。
(7)依頼者がソフトウェアに対する理解がない
ソフトウェアを知らない人たちの中には、ソフトウェア開発を工場の製造ラインと同じ感覚で考えている人もいる。ソフトウェアは知らないけど立場が上で、発言力があり、難易度関係なく無理なスケジュールを要求してくるケースがある。そもそもソフトウェアは抽象的であり難度が正確に見えない。コードの行数やモジュール数といった指標もあるが、一か所変更するとその影響が大きく多岐にわたるというケースもある。それを説明するための資料作成工数が上乗せされる。
o08usyu7231.hatenablog.com
(8)IT軽視の体質
歴史的な背景によると、日本は製造業が強く、モノ(ハードウェア)中心の考え方であり、ソフトウェアはハードウェアのおまけ程度のものであった。また、ITは業務効率化のためのツール程度のものと軽視されていた。このことが、既出の項目とも重複するが、IT・ソフトウェア開発は下請けに丸投げされるようになり、理解が浅い依頼者による力関係を背景とした発注条件を基に進めるため、これによって歪が生じた。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
(8)客先との力関係
「お客様のほうが偉い」「発注元のほうが立場が上」といまだに勘違いしている人がいるようである。受注側でも考え方の古い人はこのような感覚を持っており、理不尽な要求を飲み込んでしまう。最近はよく「発注側と受注側は対等であるべき」とよく言われるが、まだまだ行き渡っていないようである。片側の犠牲によって成り立っているシステム開発など、そもそもWin-Winの関係とは言えない。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
(9)ソフトウェアが最後の砦
仕様提示遅れでも、開発期間が短くとも、ソフトウェアで不良を出せばソフトウェア部門の責任とされてしまう。これを避けるためにソフトウェア部門の技術者は、設計、実装、テストを必死で頑張る。このような状況は製品開発全体の問題と認識すべきであり、開発工程の末端をブラック労働としないような全社的な配慮が必要である。
(10)依頼内容と契約形態のミスマッチ
知見の無い分野を一括で丸投げされることがある。よって、依頼元の期待に応えようとするほど過重労働になる。良い例は、最初は派遣契約や委任契約とし、ある程度受託側の知見が身に付き、まとまった業務を任せられるようになった段階で契約形態を請負に変更するなど、柔軟に対応する方法である。
(11)仕様追加・変更を受け入れるためのソフトウェア変更が発生する。
「○○を対応するなら、あわせて□□も対応しなければならない」と開発中の仕様追加・変更が無くても、開発作業としては追加となるケースがある。開発現場内では「それは初期の設計が甘いからだ!」と言いそうであるが、そもそも開発初期には追加変更となる部分まで見えていない状態で作業を開始することが多い。根性論で片づけても何も改善されない。依頼元にしては「そんなの知ったことではない。」と言ってしまいそうであるが、ソフトウェア開発の大変さを理解してほしいところである。
(12)開発するベースとなる製品のソフトウェアに潜在不具合や改善したほうが良い点が見受けられる。
なぜ不具合が存在していたのか原因究明、本来あるべき姿について思考、類似観点での調査、分析資料作成に時間を要する。スキルアップには良いが、これも本来予定していなかった作業である。
(13)間違った考え方で頑張ってしまう。
「エンジニアとして質の高いソフトウェアを開発したい」「ステークホルダに迷惑をかけたくない」と思うことは結構なことだが、「品質問題」や「進捗遅れ」のリカバリとして間違った方法で頑張ってしまうことがある。そうなると長時間労働のみならず、デスマーチになり、プロジェクトが破綻に向かってしまう。デスマーチに至る際の開発要員の心理について別記事に記載しているので、参考にしていただきたい。
o08usyu7231.hatenablog.com
3.ソフトウェア開発における長時間労働是正に向けて
これらの要因を見てみても、自分の技術的なスキルアップで解決できる要因は、ごく一部であることがわかるだろう。プロジェクトマネージャのスキルとなれば、もう少し幅は広がるだろうが、それにしても限界はある。この状況を改善するにあたって必要な内容をざっくり書くと以下のようなものがある。
- 製品・サービスを通して「価値」を与えることのできる「機能」の見極めと提案。
- 不慣れなプロジェクトにおいてはスローペースで進めることを前提としたスケジュールの作成。
- 開発である以上トラブルを想定する。開発の要所要所でリスクの洗い出しが有効。
- 余裕のあるスケジュール。
- 依頼者や顧客がソフトウェアの難しさを知る。およびこのための情報発信。
- 無理な要求は断る。可能であれば代替案の提示。
適切な見極め、余裕の確保と関係者の理解が必要である。
4.長時間労働しかソリューションがないことが問題
最近は長時間労働対策に関する研究が進んでおり、情報を得やすくなった。よって、経営陣も管理職も一般社員も、積極的に情報を取りにいってほしい。
「気合い」「根性」「情熱」というブラック企業が好みそうな言葉やマインドだけでは、もう通用しない。「気合い」「根性」「情熱」も大切だが、業務逼迫状態を乗り切るソリューションが長時間労働しかないことが問題である。
健康面と経営面からいうと、人間は朝起きて13時間以上経過すると、酒酔い運転程度の作業効率になると、医学的に証明されているとのことである。その作業効率が落ちた社員に、割り増しで残金代を払っているのである。経営としてはダメージが大きいことに気付かなければならない。
このような時代背景にありながらも、長時間労働に巻き込まれ困っている人は、健全な会社に転職することも一つの選択肢だろう。
最後に私の経験から確実に言えることを一つ。「長時間労働の原因は自分のスキル不足ではない」。
o08usyu7231.hatenablog.com