製造業の生産管理による標準化手法はソフトウェア開発に適用できない

製造業の生産管理による標準化手法はソフトウェア開発に適用できないのではないか、という考えをメモ。
ラフなメモ書きなので、ロジカルではない。
間違っていたら後で直す。

【1】製造業の生産管理に触れて、その中身を見ていくと、ソフトウェア業界に身を置く者としては、全く異質な感触を受けている。

例えば、Industorial Engineeringという手法がある。
IEという作業研究の手法を使って、工場での旋盤の加工方法、モノの運搬、納品物の受入検査などを効率化するために、人の手や体の動作、人と機械の配置とモノの流れなどを徹底的に情報収集し、分析する。
無駄な動きを省き、効率良くモノが流れるように、工程図やレイアウト、フローなどの図を書く。

IEのような手法は、工場だけでなく、ファストフード店、スーパーのレジ作業、旅館のサービスなど、労働集約的なサービス業にも適用できるだろう。
おそらく、大量の低賃金労働者を集めて、標準的なマニュアルに従って、大量の作業を効率的にさばくのに有効なのだろう。
しかし、そのような手法は、ソフトウェア開発に適用できるのか？

プログラムを書く時に、詳細設計書に書かれた日本語の仕様をそのまま書き写して1字1句間違えないようにプログラムを書く、などの作法を標準化して、プログラミングすべきなのか？
多分、そのやり方は20年以上前のソフトウェア開発のやり方だ。

ソフトウェア開発が、低賃金の労働者による労働集約的な産業ならば、それはできるかもしれない。
でも、現代ではありえない。
ソフトウェア開発の作業の標準化、属人性の排除は、日本企業は大好きなのだが、今まで成功した事例の話をほとんど聞かない。

【2】ある人から、Redmineで作業の生産性を測定したいという要望を聞いた。
僕は、作業ごとに、設計者が自分が書いた設計書を元に見積りして予定工数をチケットに記録し、開発者が与えられた仕様書を元に実装した実績工数を付けるだけだと思っていた。
しかし、話を聞くとどうやら違うらしい。

話を聞くと、予定工数、実績工数とは別に「基準時間」という概念をチケットに入れて、生産性を測定したいらしい。
では、基準時間とは何か？

たとえば、Javaや.NET、Cobolのような言語と、画面・帳票・バッチのようなシステム機能の組合せで、熟練した開発者ならば、これくらいの標準時間で作業できる、という指標を基準時間で定める。
その基準時間を元に、開発者の作業ごとの実績工数を採取して比較し、その差分から生産性の善し悪しを評価して、開発者への発注金額の評価に使いたいらしいのだ。

この発想は、生産管理における時間研究の標準時間の測定の考え方と同じだ。

たとえば、マクドナルドのようなファストフード店で、ビッグマックを作る場合に、熟練者なら標準的なマニュアルに従って、標準時間はこれだけかかるだろう、という基準時間をあらかじめ定めておく。
その基準時間に対し、あまり熟練していない作業者には、レイティング補正を行い、基準時間よりもやや長めに幅を持たせて、作業の標準時間を定めて、その作業者の生産性の指標に使うわけだ。
この手法を使うことによって、作業者毎の生産性や熟練度を評価できる。

そもそも、そんなやり方をソフトウェア開発に適用できるのか？

20年以上前なら、Cobolなら、何LOCで生産性はこれくらい、というメトリクスを計算できていたのだろう。
しかし、現代のようなソフトウェア開発で、Javaなら何LOCの規模で標準時間はこれくらい、Rubyなら何LOCの規模で標準時間はこれくらい、と測定がそもそもできるのか？
標準時間、基準時間という概念を現代のソフトウェア開発に実現できるのか？

ソフトウェア開発が、低賃金の労働者による労働集約的な産業ならば、それはできるかもしれない。
でも、現代ではありえない。
実際、ソフトウェア開発の見積り手法は、たくさんの知見はあるが、どれも一長一短であり、まともに使えない。

【3】製造業の生産管理の経験が深い人は、ソフトウェア設計や要件定義は、CADのようなツールを使って一気通貫でプログラミングできないのか、とよく言う。

CADで実物に近い製品イメージを作り、その内容を詳細化し、CAEを使って製品動作をシミュレーションして解析したりする。
自動車のモデルをCADで作り、自動車の衝突安全分析などをCAEでシミュレーションするイメージでいい。
そして、CADやCAEで製品仕様を固めた後、CAMで製品を生産するための工程設計に落とす。

似たようなやり方をソフトウェア開発に適用したとしたら、RADのようなツールでプロトタイプを作り、そのプロトタイプに対して色んなテストデータを投入してシミュレーションないしテストを行うようなプロセスになるだろう。
20年以上前に流行したRADみたいなやり方だ。

でも、現代のソフトウェア開発でそんなやり方ができるのか？
設計書だけ作れば、プログラミングなどせずに、プログラムはモデルから自動生成させるだけであり、必ず設計書のモデルと同期させるようにすればいいのかもしれない。
しかし、頻繁な仕様変更やバグ修正を行ううちに、ソースを直接修正するようになり、モデルとソースは乖離し、設計書は古くなっていく。
たとえば、ソース1行の修正なのに、モデルの修正の方が手作業でたくさん修正しないといけない場合も多い。

個人的には、超高速開発ツールにも似たような匂いを感じる時がある。
モデルはたしかに重要だが、実装とかけ離れたモデルは無意味だ。

【4】日本の製造業が生み出したリーン生産方式、TPSのような考え方をソフトウェア開発に適用することでアジャイル開発のような考え方を生み出した、という話を聞いてきたし、そうなのだろうと思っていたが、最近は、何か違うような気がしている。

欧米の人は、製造業における生産管理、品質管理の考え方をそのまま取り入れるのではなく、何かしら一工夫を入れてからソフトウェア開発に適用したのではないか。
ソフトウェア開発と製造業という産業構造の違いがあるために、リーンやTPSの考え方は参考になるものの、そのまま適用できず、何かアレンジして、本来の製造業の生産管理や品質管理とは全く違う異質の開発スタイル、アジャイル開発を見出したのではないか。

何かモヤモヤしているけれど、製造業の生産管理や品質管理とソフトウェア開発の中身は異質だと思う。
プログラミング作業そのものの標準化、時間研究による標準時間の規定、CADやCAEによるソフトウェア設計の自動化作業などの考え方は、製造業で成功したやり方に影響を受けすぎていて、そのまま当てはめてもうまくいかない。

生産管理ではよく、５Sや５ゲン主義などの話を聞く。
その発想は確かにソフトウェア開発にも適用できるかもしれないが、ソフトウェア開発はクリエイティブな仕事である、という真理とずれている気がする。
ソフトウェアはクリエイティブな人がその能力を発揮できて初めて良い物が作れる、という真理から外れているからではないか、と直感する。