ソフトウェアエンジニアが労働について情報発信するブログ

ブラック労働からホワイト労働まで経験したソフトウェアエンジニアが世の中にとって役立つことを情報発信していく。

製品の「量産開発」におけるエンジニアの労働環境を左右する要因の一つは「先行開発」・「要素技術開発」だ!

製品の「量産開発」におけるエンジニア、なかでもソフトウェアエンジニアは長時間労働や過重労働になりやすいと言われている。私も実際そのような経験をした。具体的に月当たり何時間以上を長時間労働というのか、どの程度から過重労働というのかは人によってまちまちだが、本来は少なくとも残業が常態化している時点で労務上の問題があると言うべきだ。

開発である以上、未知のことを行うわけだから、トラブルは付きものである。私が見てきた開発現場では、

「トラブルを想定していない組織ほどトラブルが多い」

傾向にある。

「トラブルを解決して、納期に間に合わせるのがプロの技術者だ!」

というのはごもっともなのだが、このような根性論だけが飛び交う環境は、今の時代世間からは「ブラックだ!」というイメージを持たれることになる。

一方、技術的なトラブルの発生をゼロにはできないもののできるだけ抑える、もしくはトラブルが発生してもその箇所を出来るだけ早く特定できるようにするといったことも有効だ。

そのためには、個人個人のスキルアップの他、製品やシステムのコア技術を、「量産開発」のスケジュールとは別に早い段階で確立しなければならない。この記事では、そのための手段である「先行開発」・「要素技術開発」について、私が経験してきた現実とともに語りたいと思う。

目次


1.新規技術をいきなり「量産開発」に適用すれば開発現場が混乱するのは当たり前!

日本では、長時間労働問題が従来から社会的な問題になっている。その業界はさまざまであり、製品の「量産開発」を担うソフトウェアエンジニアもその対象だ。

ソフトウェア開発における長時間労働の原因の一つは、品質トラブルや技術的な課題に対応する原因究明、解決にかかる工数だ。中でも、新規技術、新規部品、新規デバイスの採用でトラブルが多い。

新規技術を使った設計に想定以上の工数を要し、試験結果的がNGとなり、またやり直しが発生する。

リソースに余裕のない企業や、ソフトウェア開発を簡単と考えている企業は、酷い場合、新規要素をいきなり「量産開発」に投入する。技術的な課題解決の目途がたたないまま、「量産開発」に対する納期のみが決まっている。

リリース時期や納期を市場に公表したり、取引先に約束しているので、延期はできないと考えられている場合が多い。(そもそもエンジニアなど自社の社員を犠牲にしてまで、外部の要求に応えるかという問題はある。)

目処が立つか否か不明なものに対して、納期だけが決まっている。リスクそのものだ。それどころか高い可能性で炎上する。

そのような状況でも、優秀なエンジニアならやり遂げてくれるだろうと考えられなくはないが、それは優秀かどうかではなく、単に企業への忠誠心がある従順で都合の良いエンジニアだというべきだろう。本当に優秀なエンジニアはもっと良い環境を求め、転職や独立といったキャリアも視野に入れているし、わざわざ劣悪な労働環境の企業にしがみついたりはしない。人材の流動化はどんどん進んでおり、個人の力業や根性に頼るやり方は、リスクどころか今後は成り立たない。それ以前の仕組みから考え直す必要がある。

2.新たな技術の確立には「先行開発」・「要素技術開発」が効果的!

「先行開発」は「量産開発」と異なり、文字通り製品やシステムに搭載する技術を先行して開発するステージのことである。新たな技術の導入、新たなハードウェア・デバイスの採用、新たなシステム構成とする際には、まずは試作品を作成する。そして、技術的に実現可能か、量産製品に搭載しても問題ないかという点を踏まえて、技術的課題を解決しておく必要がある。

この「先行開発」で実施する内容を、最初から「量産製品」に搭載すると決めず、確実に技術を確立することを目標にすべきである。技術的な課題が確実に解決し、「量産製品」に搭載できるめどが立ってから、「量産開発」の計画に組み込めばよいわけである。この方が見積りの精度が高く、品質も担保しやすい。

このように製品やシステムに対して、いくつかの「先行技術」を確立しておき、効果やニーズが高い内容から「量産開発」にて組み込むような、無理のないスケジュールとする。アジャイル開発に類似した考え方で、柔軟に進めれば良い。

「要素技術」とは、製品を構成する要素に関する技術、製品の開発に必要な基本技術、製品の根幹をなす技術を指す。「要素技術開発」は、製品やシステムに対する「コアとなる技術の研究や開発」のことだ。これも「先行開発」とスタイルがよく似ており、製品い新しく採用しようとしている技術を「要素」と捉え、「量産開発」とは別ステージとして行う。

技術的な課題解決の目途がたたないまま、「量産開発」に対する納期のみが決まっているなどというふざけたことはやめて、「量産開発」とは関係なく「先行開発」や「要素技術開発」で技術確立を行い、目処が立った技術に対して「量産開発」に移行すればよいのである。言われれば当たり前だし、「そんなの、当社では当たり前のようにやってるよ!」という企業も多くあるはずだが、実際に「量産開発」が炎上することが多い。「先行開発」・「要素技術開発」が適切にできていないことが、「量産開発」が炎上する要因の一つである。

3.「先行開発」・「要素技術開発」におけるスコープの適切性が「量産開発」を左右する!

メーカー企業には、「要素技術開発」を行う部門が存在することがよくある。しかし、企業にもよるが、「要素技術開発」の対象は、製品やシステムを構成する新規部品といった、ハードウェアやモノの開発に終始することがある。

例えば、新規に採用するハードウェアの耐久性といった評価項目は、多くの人が意識するのだが、要素開発したモノを使って、ソフトウェアでどのように制御を実現し、ハードウェアとソフトウェアのトータルでどのような効果や優位性を得るのかといったところまで評価していない組織もある。

モノ単品や部品単品で「要素技術開発」をしていても、これを組み込んだシステムとしての検証が行われていないことがよくある。その結果、システムレベルでの技術的課題が浮上し、「量産開発」でトラブルになる。その結果、納期に追われ、時間的余裕がないから残業以外のソリューションがないという状態になる。

「先行開発」・「要素技術開発」の部門は、各々の業務をこなしたにも関わらず、「量産開発」ではシステムレベルでの技術的トラブルか発生し、「量産開発」のエンジニアが疲弊する。日本は製造業に強みを持つという歴史的背景から、モノやハードウェア中心の開発であるところが多く、「先行開発」・「要素技術開発」も、モノ・ハードウェアレベルでの完了をもって「先行開発」・「要素技術開発」完了としているのではないかと思われる。

本来、モノ・ハードウェアに加え、それらへの制御仕様、ソフトウェアを含めたシステムレベルで構築すべきではないだろうか。「先行開発」・「要素技術開発」のスコープをどのように設定するかが課題だ。

私自身が実践した有効な方法の1つは、既存のシステムを使って新技術を検証できる領域は、極力既存システムを活用することだ。例えば、通信速度を上げ、大量のデータを短時間で送受信する新規通信技術を構築するならば、この技術を採用して、まずは既存システムと同じ動作を実現できることという明確な目標ができる。製品の制御基板(コントローラ)に新規マイコンを採用するならは、まずは既存の製品の制御基板(コントローラ)に新規マイコンを採用した試作品を作成することで、この試作品コントローラを既存システムに採用しても、既存システムが問題なく動作するという目標ができる。

既存のシステムを使い、新規技術を採用した、試作システムを構築すれば、新規技術を採用した部分、「要素技術開発」を行った部分を含めて、システム全体での品質確認ができる。もし、品質問題が起きても問題となる部分の発見や特定がしやすい。ありきたりな方法であり、開発組織によっては「そんなことは当たり前のようにやっている!」と思うだろう。しかし、実際「量産開発」で技術的なトラブルが起きて、開発スケジュールや労働環境に影響しているわけである。「既存システム+新技術」でシステムとしての検証と、システムレベルでの技術確立の対象領域を増やしていくための工夫が必要であると考えている。

既存システム以外にも、シミュレーションやテスト対象モジュールを代替するスタブなどを使用する方法もある。こちらについてはこの記事では省略する。

多くの開発組織は、新機能と新技術を「量産開発」で同時に進めるから、新機能の理解と実現、新技術の理解と構築という両方のことを一度に行わなければならないため、リソース不足となり、エンジニアが疲弊する。開発当初は同時に進めた方が効率が良いと判断しがちであるが、予期せぬトラブルが発生し、その対処に工数が取られてしまうものだ。

「量産開発」をスムーズに進めるには、新規技術に関する技術的課題のほとんどが解決できており、量産品質を担保することに注力できる程度の状態にしておくことだ。そうでなければ、スケジュール見積は極めてやりにくく、納期を優先するなど謎の圧力から過小に見積りを行い、スケジュールを守るために過重労働となる。更に、「量産開発」では顧客・取引先を含めた多くの組織とのコミュニケーションが多くなり、エンジニアの負担は更に増える。

4.余裕のない新規技術の確立は技術的負債を抱える等デメリットだらけだ!

開発である以上未知のことを行なう業務であるし、トラブルは起きる。しかし、これをエンジニアの過重労働で賄うのは賢いとは思わないし、世間から見てもブラックのイメージが強うだろう。そうなれば、技術力の高いエンジニアから更に良い労働環境の組織(もしくはフリーランス)へ流出し、残ったエンジニアにしわ寄せが来るだけだ。そこを更に

などと、このようなどこにでもある掛け声だけが活発になり、場合によっては「時短ハラスメント」にもなりうる。
o08usyu7231.hatenablog.com

労働環境の話だけではない。余裕のない新規技術の確立は、仕様書・設計書が整備されていない、ソースコードが雑、何か変更を加えたときにすぐに破綻する品質、後世に引き継がれていない隠れ仕様等、技術的負債が大きすぎるのである。技術的負債が大きいということは後世に負担をかけることとなり、無理な働かせ方をして労働環境悪化に繋がるか、収益低下に繋がる。

エンジニアに限らず、社員に無理な働かせ方をしなくても、利益が出るビジネスを構築するのが経営者に仕事である。

新規技術をいきなり「量産開発」に投入し、少ないリソースで、短納期で、エンジニアの力技に頼ると、当然のことながら、エンジニアは過重労働になり、開発プロジェクトの破綻、納期遅れ、品質問題等、どこかに歪が出る結果となる。このような体質を放置しているのは、経営者や管理職の問題だ。

納期までに絶対に技術的課題を解決し、何としてでも納期に間に合わせるよう、エンジニアに対して圧力をかけたやり方ではなく、あらかじめ余裕を持ってシステム・ソフトウェアを含めた技術確立をしておき、いつでも「量産開発」に組み込むことができるようにするのが理想的である。アジャイル開発の手法が参考になるかもしれない。