組込みソフトウェア開発のプロセス改善の違和感

先日、組込みソフトウェア開発現場のプロセス改善の講演を聞いてきて、何となく違和感を感じた。
以下は感想とラフなメモ書き。
箇条書きなのでラフなメモ。

【1】こんな講演ストーリー。

【1-1】組込みソフトウェア開発組織での課題。
経営層がソフトウェア開発を分かっていない。
工場のモノづくりと同じような感覚でマネジメントしようとして、思い通りにならないことに苛立っている。

なぜ、そんなにコストがかかるのか？　コストやロスを見える化できないのか？
これだけの開発規模で、もっと安く作れないのか？　開発効率を向上できないのか？
人材を計画的に育成して、もっと良い人材を揃えたい。IOTやビッグデータ、AIなどが分かる技術者を揃えたい。

(感想)
メーカーの経営者から見れば、ソフトウェア開発はブラックボックスなのだろう。
モノづくりのように、なぜもっと作業を標準化して、資本(資金)と労働者を大量導入して、大量生産できないのか？と思っているのだろう。
ソフトウェア開発は労働集約的な産業であり、規模の生産性が効かないのを知らないだけ。

【1-2】では、開発者にとってのプロセス改善はどうか？

プロジェクトリーダーにとって、憂鬱な仕事。
現場は、プロジェクトを回すのに手一杯で、これ以上、管理作業を増やしたくない。
SQA審査は無駄、時間の浪費としか思えない。

ソフトウェア開発を失敗しないやり方、うまいやり方はないのか？
しかし、銀の弾丸はないのだから、最終的には、自分達にあったやり方を見出すしか無い。

【1-3】開発標準の目的は、ソフトウェア開発を手順化して、管理できるようにして、効率的なやり方を定着させたい。
製造業の生産工程の標準化、３Sと同じ発想。

SQA審査では、開発標準に定めたルール、それに沿ったチェックリスト、テンプレート資料で、ドキュメントを精査する。
しかし、この開発標準は実質的に機能していない。形骸化している。

現場にとって負担が大きいだけで、効果が薄い。
CMMIのようなプロセスモデルの要求事項を満たすだけのために導入された資料作り、という感触が強い。
では、手間がかかるデータの収集にツールを導入して解決できないか？

(感想)
本当にその通り。
CMMIやISO9001のようなプロセス改善のための資料作りは、審査を通すだけのための作業と化しており、本来の品質維持にあまり役立っていない。
実際、リリース後に、設計書を整備したり、テスト結果を整理する作業をまとめて行う場合が多い。

【1-4】開発の計測として、工数、開発規模、欠陥抽出数というメトリクスがある。
たとえば、下記がある。

欠陥検出密度＝欠陥検出数(件)/開発量(kStep)
開発効率＝開発量(kStep)/工数(人時)

【1-5】「欠陥検出密度＝欠陥検出数(件)/開発量(kStep)」は、どの工程で測定するか、で意味合いが異なる。
たとえば、「設計レビュー」「結合テストのテストNG数」「総合テストの障害数」なら、バグ率。
バグ率を使って、品質を良くするためのプロセスを取り入れることで、開発期間中のプロセス制御に使える。

しかし、レビュー指摘数が多いほど欠陥検出密度は大きくなり、品質が悪く見えるので、レビュー指摘を躊躇する人が出てしまい、悪循環になる場合がある。

一方、製品出荷後なら「流出不具合率」になる。
ハードの製品なら、出荷後の不具合は、PL法(製造物責任法)の制約でメーカーの無過失責任になる可能性があるから、一方的にコスト負担になりがち。
だから、流出不具合率はできるだけ低く、ゼロにしたい。

しかし、流出不具合率は、開発完了後、一定期間を経過しなければ測定できないデメリットがある。
また、開発期間内に欠陥があると分かっていて、その欠陥は品質に問題なしという評価で、出荷する場合もあるが、それは流出不具合率に含めるのか？

(感想)
欠陥検出密度は、テスト前に、他の類似案件を元に計画値を定めて、実績はそれとほぼ同じか、少し低いぐらいの数値になるように収める、みたいなやり方が多い。
でも、欠陥検出密度の測定方法はいくらでも改ざんできるので、あまり意味が無いと思う。
「これは障害ではなく、顧客要望の仕様変更です」と言って省くこともできるから。

【1-6】「開発効率＝開発量(kStep)/工数(人時)」は、開発する対象や領域によって傾向が大きく異る。
プロジェクトや製品ごとに違うために、比較しにくい。

また、流用開発や派生開発では、新規開発よりも開発効率の値が低くなりがち。
たとえば、流用率が高いほど、新規作成のソース行数は少ないが、工数は新規開発とそんなに変わらない。

話を聞くと、普通は、5step/時間、800step/人月くらいらしい。
1時間で5ステップ、または5行とは、かなり少なすぎるが、デバッグやテスト、障害修正を考えると、そうなるのだろう。

だから、経営者から見れば、ソフトウェア開発は効率が悪すぎる、と見てしまいがち。
つまり、開発効率は数字がひとり歩きしがちだが、比較は意味が無い。

(感想)
開発効率を使いたい場面は、子会社のオフショア開発者の生産性評価に使いたい場面が多い。
もちろん、開発効率が良い開発者が評価が高い。

しかし、実際は技術の習熟度、プロジェクトの習熟度に依存するので、ほんとうに正しいかどうか分からない。
メーカーのモノづくりならば、生産工程における単純な組立作業、ライン上の作業の開発効率として評価しやすいし、あまりブレない。
むしろ、生産工程の「標準時間」として抽出し、「生産標準」として「この生産工程ではこれくらいの作業時間が標準だ」と定めて、未熟練労働者を指導することもできる。
しかし、ソフトウェア開発でそんなやり方が通用するのか？

【1-7】そんな状況で、プロセス改善活動をやっているが、現場で蓄積するノウハウを展開していきたい。
組織のルールが自分達のプロジェクトに合わなくても、柔軟に解釈して運用する方が良い。
無理に合わせるため必要以上に時間を使わない。

(感想)
現実的にはそうなるだろう。
しかし、そうであれば、プロセス改善活動を進める立場の人の意義は、結局何だろうか？
プロセス改善部署がなくても、現場は回るのではないか？

【2】組込みソフトウェア開発のプロセス改善の話に違和感を感じたのは、製造業の品質管理の技法をそのまま当てはめようとしても、実際はうまくいかない、と思うからだ。
その違和感については、過去に書いた。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

ソフトウェア開発でバグ管理はなぜ必要なのか: プログラマの思索

上記の講演では出て来なかったが、僕が一番違和感を持つ言葉は「標準時間」「開発原単位」だ。
製造業では、開発効率の単位となる「標準時間」、開発コストの単位となる「開発原単位」をメトリクスとして抽出するのが一番重要であり、そこから計画を立てて、正確な見積を行おうとする。

なぜなら、数億～数千億円のような製造装置、製造ライン、工場を建てる場合、正確な見積がなければ、設備投資できないからだ。
しかも設備投資の意思決定は、実際のプロジェクト開始の1年前に決まっている。
だから、早めに開発効率やコストの原単位を計算する必要性がある。

しかし、ソフトウェア開発では、「標準時間」「開発原単位」は計算できるのか？
ソフトウェア技術者の能力によって、生産性や10倍以上違うのだから、標準時間も10倍以上違ってしまう。
開発原単位も、技術者の人月単価は30万円から200万円まで幅がありすぎるし、標準時間も10倍以上も差があれば、見積りのブレは大きくなりすぎ。
つまり、ソフトウェア開発では、「標準時間」「開発原単位」を計算しても、その正当性を説明しづらいのだ。

そもそも、アジャイル開発では、そんなものは計算しないし、計算しようとする動機も持っていない。

一方、日本の製造業では、実際の生産は外注に出している場合が多いので、外注によるアウトソーシングでどれだけコストメリットが出るか、品質が良いか、という評価が必要になる。
その時に、「標準時間」「開発原単位」という指標が外注ベンダー単位に必要なのだ。
そうすれば、今後の発注にも、見積りとして使えるし、納入された製品の品質評価にも使える。

そのやり方をソフトウェア開発にそのまま取り入れてもうまくいくとは到底思えない。