ソフトウェア開発が逼迫している状況を依頼元に丁寧に説明すれば理解していただけた！ - ソフトウェアエンジニアが労働について情報発信するブログ

日本の製造業はソフトウェアを軽視し、ITエンジニアのブラック労働で成り立っている。

全てとは言わないし、また開発現場によって程度は異なるが、この傾向は概ね当てはまっている。

私自身の過去の経験、他社の状況、専門家の見解にて合致する点は多い。

しかし、これによる問題点を理解していない人が多い。

ソフトウェアによる価値を創出できない
労働環境を理由にエンジニアの退職を招く
残りのエンジニアに負荷がかかる
ソフトウェア開発は「キツイ仕事」というイメージを与える
エンジニアを目指す人が少なくなる
IT技術者不足

等々、負のスパイラルだらけだ。

このようなときこそ声を挙げるべきであり、まともな組織なら是正へ向けたスタートとなる。粗悪な企業であれば、声を挙げた人を叩き、誰も声を挙げなくなり、いつまでも是正されず、衰退していく。

この記事では、まずは逼迫した状況について「声を挙げよう」という内容、および幸いにも依頼元に理解していただけたという事例についてお伝えする。全ての依頼元がこのような結果になるとは限らないので、慎重な見極めを要するところである。

1.システム開発の前行程のしわ寄せをソフトウェアエンジニアの犠牲で賄う現状
2.この状況を変えるべく、まずは開発プロジェクト全体を振り返る
3.発注元を巻き込んで本音ベースで語ろう！何かが見えてくるよ！
4.言ってみる価値はある。発信することは大切だ！

1.システム開発の前行程のしわ寄せをソフトウェアエンジニアの犠牲で賄う現状

本来、システム開発の前行程に遅れが生じたり、システム開発中における機能追加が発生することは、スケジュールを変更しなければ後行程にしわ寄せが行くのである。ソフトウェア開発などまさに該当する。

普通はスケジュール延期、人員の増員で賄える場合は人員の増員、優先度が低い機能の搭載見送り等何かしらの調整が行われる。しかし、現実には、ソフトウェアエンジニアの犠牲で賄うことが少なくない。ソフトウェア開発組織内の調整や工夫で凌げるならまだ良いのだが、これが間に合うレベルではないから問題になるのである。

そして、ソフトウェアエンジニアの長時間労働という、犠牲の上で開発が成り立ってしまい、以降もそれが当たり前になってしまい、またその状況を

「ビジネスとはこのようなものだ！」
「業界の常識！」
「甘い考えはを排除し、己に厳しく・・・」

等と称して、間違った考え方で洗脳しようとする者まで出てくる。

実際に過去に対応した開発業務で、前行程のしわ寄せを受けたにも関わらず、前行程の進捗促進・サポート、開発製品群での機能仕様共通化、ソフトウェア開発組織への人員追加投入、長時間労働で賄い、納期を変更せず対応した案件がある。
o08usyu7231.hatenablog.com

2.この状況を変えるべく、まずは開発プロジェクト全体を振り返る

開発プロジェクトの「振り返り」を行う組織は少なからずあるだろう。良かった点、悪かった点を洗いだし、次の開発に活かしていくというスタイルである。「振り返り」の対象とする要素内容では、技術面、開発プロセス面、プロジェクト運営面が多く、品質（quality）、コスト（cost）、納期（delivery）の観点から行われる。

先程のリンクの記事にあるプロジェクトは、品質、コスト、納期、いずれも問題なく達成しており、一見なんの問題もなさそうに見えてしまうが、色々と紆余曲折があったプロジェクトである。ソフトウェア開発部門で実施した「振り返り」の結果、良かった点が多くあるものの、一部改善点があるというものだった。

しかし、本当の問題はそこではない。当該プロジェクトは、開発序盤からソフトウェア開発部門から要求元部門へ積極的にアプローチし、フロントローディングを行ったにも関わらず、

要求仕様決定の遅れ
開発中の追加仕様
納期の延期なし
対応機能の削減を申し入れたが、受け入れてもらえない
ソフトウェア開発部門内での調整以外になす術なし

といった、前工程のしわ寄せを全てソフトウェア開発部門が受けてしまい、開発終盤にソフトウェア開発部門の業務が逼迫し、最終的には、

ソフトウェア開発部門内での人員増強（により、他のプロジェクトへの進捗に影響が出た）
一部メンバの長時間労働（により、心身の負荷がかかるという犠牲の上に成り立たせる）

ことで、プロジェクトを完了させたことである。

このようなことがまかり通り、

「業界の常識」
「いままでもやっていた」

と称して当たり前の状況になるから、ソフトウェア開発部門内外関わらず、「労務」や「コンプライアンス」に対して感覚が鈍り、麻痺してしまい、気付いたら

「品質に影響が出ていた」
「労務問題に発展していた」
「人材が流出していた」

となるのである。幸いにも、このプロジェクトは

「品質不良が市場に流出する」
「メンバが体調を崩す」
「メンバが流出する」

といったことは発生していないが、リスクや予兆こそ早目に捉えて手を打つべきであり、問題が顕在化する前に改善していく必要がある。

ソフトウェア開発部門内で、個々のプロジェクトでの反省点を洗い出し、次に繋げることは有効である。その一方、多くの開発プロジェクトに共通してみられる、業務過多による労務問題といった根本的な問題と向き合い、本気で是正しなければ未来はないと言っても過言ではない。特に、経営層や管理職にそのような姿勢が求められる。企業によっては、これすらも現場に丸投げしているのが実態だ。

それでもまず、ソフトウェアエンジニアができることとして、このプロジェクトでは「振り返り」を、従来から行ってきたソフトウェア開発部門内で行うものに加え、要求元部門を交えて合同で「振り返り」を行うことを、ソフトウェア部門のメンバから要求元部門へ提案した。

3.発注元を巻き込んで本音ベースで語ろう！何かが見えてくるよ！

要求元部門と合同で「振り返り」を行うにあたって重要なことは、本音で語ることだ。うわべだけ、形式だけの実施では、根本的な問題は解決しない。

ここで気を付けなければいけないのは、ソフトウェア部門は正直に、

「前工程のしわ寄せを受け、ソフトウェア開発が逼迫して困る」
「このような状態が改善されないと、品質（quality）、コスト（cost）、納期（delivery）に対するリスクのみならず、長時間労働をはじめとする労務トラブルに繋がるリスクがある」
「一部の人や組織の犠牲の上に全体を成り立たせることが問題であることは、コンプライアンス教育の場面でも語られている」

という感じで、自分たちが困っていることを明確に伝えたうえで、

「要求元部門としても、短納期での依頼に至るには、更に前段階からのしわ寄せを受けている可能性がある」
「我々ソフトウェア開発部門も、要求元部門のすべてが見えていない」
「要求元部門にも何か困りごとがあるはずだ」

という感じで、要求元部門に対して気遣いを見せることだ。

そして、ソフトウェア開発部門、要求元部門が、

「開発中のあのときの〇〇の場面で、□□となったが、もう少し妥当な進め方はなかっただろうか。」

という問いに対して、Win-Winとなるよう落としどころを決めることである。Win-Win以外はビジネスは成り立たないと思ってほしい。

一例を挙げると、システムのある機能仕様が２パターンあり、この２パターンのうちどちらにするかなかなか確定しない場面においては、

【方法Ａ】仕様確定まで、ソフトウェアの設計・作成に着手せず、確定へ導く
【方法Ｂ】２パターンの仕様の両方のソフトウェアを設計・作成し、最終的に要求元に選んでもらうだけにする

という方法が考えられる。ソフトウェア開発の総工数（＝コスト）を最小にすることや、作業の手戻りを発生させないことを重視する人は【方法Ａ】を選ぶ（要求元やマネージャがこの考え方ならメンバに【方法Ａ】を指示する）だろう。一方、ソフトウェア開発の総工数（＝コスト）は増えるが、開発期間の早い時期に【方法Ｂ】を実践し、開発終盤にソフトウェア開発部門の業務が逼迫することを回避するという選択肢もある。ソフトウェア開発業務を逼迫させると、品質に影響が出てかえってトータルのコストが膨れ上がるリスクさえある。アーキテクトの一般論としては、仕様が未決の部分の設計を局所化する（＝未決部分がどちらに決定しようとも、作成済みの部分のソフトウェアに影響を与えないような設計とする）ことが語られている。システム開発のプロジェクトで何を重視するのかは各案件によって異なるが、【方法Ａ】【方法Ｂ】の一方に固定するのではなく、適宜協議するということを、ソフトウェア開発部門と要求元が合意するに至っている。

結果、このような本音で語る合同の「振り返り」によって、要求元も学ぶことが多かったようである。

「ソフトウェア開発部門が、しわ寄せを受け、逼迫している状況を理解できた」
「ソフトウェア開発部門の思いを聞くことができて良かった」
「コミュニケーションを大切にし、良いシステム開発に繋げたい」

要求元部門からは、このような前向きなコメントが出ている。本音で語る合同の「振り返り」は、良い取り組みであったと考えている。

リンク

4.言ってみる価値はある。発信することは大切だ！

この開発プロジェクトを見てもわかることだが、やはり「現状」「困りごと」を発信することは大切だ。このプロジェクトの要求元部門は、ソフトウェア開発の大変さをわかる、理解のある人たちである。丁寧に発信すれば、理解してもらえる。

一方、この開発プロジェクトとは異なり、要求元にはソフトウェア開発を下請けに丸投げし、ソフトウェア開発部門が抱える困りごとを発信したにもかかわらず

「ソフトウェア開発部門内で解決すべきだ」
「ソフトウェア開発部門の労働環境など、我々要求元が知ったことではない」
「ソフトウェア開発部門の技術の問題だ」

などと、高圧的な対応を取る要求元もいる。これではWin-Winにはなりえないし、健全なビジネスではない。要求元もソフトウェア開発を含めたシステム開発や製品開発の責任を背負っていることを自覚し、ソフトウェア開発部門や、ソフトウェアエンジニアを犠牲にすることなくビジネスを成り立たせるべきである。コンプライアンスが厳しくなる中、これができない要求元は、まともなソフトウェア開発組織から相手にされず、衰退していくことになるだろう。

なので、やはり発信することだ。発信しなければ何も始まらない。発信したことに寄り添えなければ、相手は所詮そのレベルだ。

世間一般に目を向けると、