Tyzoh.jp

二つの論点を整理してみます。

ひとつは、『ソフトウェア開発は製造業でいう「開発」なのか「製造」なのか？』「製造」というより「生産」と言い換えたほうが正しいかもしれません。
もうひとつは、『「要求定義時の手戻り」がなぜ起きるのか？』という問題です。



まず、『ソフトウェア開発は製造業でいう「開発」なのか「製造」なのか？』という問題に関して、私もいろいろと考えました。結論から言うと、ほぼ「開発」だと考えることができると思います。ソフトウェア開発といっても、システムプロダクトとアプリケーションプロダクトでは確かに開発の特性が異なっています。ここでは主にアプリケーション開発に焦点を当てて考えます。アプリケーション開発と言っても、部品の開発とその部品の利用では専門性が異なります。部品を開発するときは、システムプロダクトを開発することに近い専門性が必要です。しかし、その部品を組み立ててアプリケーションシステムを構築する人はまた違った専門性が必要です。どちらの開発者も専門性が高く、誰にでもできるような技術ではありません。しかし、アプリケーション開発に関して言えば、部品化が進んでいないこともあり、構築する開発者は主に設計のみを行い、その設計書に基づいて多くプログラマがプログラミングを行う形態をとっていることが多いと思います。このプログラミングの部分が製造業の「生産」工程に近いのではないかと思います。この部分に関して単純化して生産性を上げられないだろうかとよく言われていると認識しています。製造業ではこの生産工程をパートやアルバイトまで使ってコストダウンさせているわけですが、SIではそこまで単純化できないことが問題です。プログラミング工程の生産性を改善していくことは短期的にはある程度の生産性を向上させるために効果があると思います。しかしながら、中長期的にはこの作業をITを使って「自働化」することで劇的に生産性と品質を向上させることが可能だと思います。製造業で言えば、完全自動化のロボット工場を建設するような話ですが、アプリケーションシステムを設計書から自動生成する技術は製造業の場合より実現性が高いと思います。したがって、第一にはプログラミング工程における改善を行い、次にIT自身による「自働化」を実現することが肝心だと思います。

第二に、『ソフトウェア開発は製造業でいう「開発」なのか「製造」なのか？』という問題に関してです。katoさんからは、手戻りは必ずしも悪いことではないというコメントも頂いています。これも真ですね。しかし、手戻りには、良い手戻りと悪い手戻りの2種類あるわけです。RADを使ったり、スパイラルアプローチを行っても、システム開発では開発段階を正しく踏んでいかなくてはなりません。RFPに従い要件を定義して設計して見積もりを行って契約しないと、SIはビジネスとしては成り立たないわけです。いくらお客様が満足してくれてもそのためにコストオーバーランしていたのではいつまでたっても私たちのボーナスは増えません！ukonさんが言っているのはこの契約後の仕様変更のことで、katoさんが言っているのはスパイラルアプローチで要件や設計を詰めるときの修正のことだと理解しています。建設業界でもそうですが、実際に家を建てて見せてから違っていることを指摘されて、再度建てなおしていたのではいくらコストがあっても足りません。お客様に頼んでも、そこまでコストは負担できないと言われるでしょう。システム開発でも設計図やプロトタイプを見せることで要件を詰めますが、実システムを構築してから仕様を変更するのは多大なコストの負担があります。スパイラルアプローチで要件定義段階でほぼ稼動するシステムを見せることができれば、お客様も要件を正しく理解することができるため、お互いの合意の上に話を進めることができます。ukonさんはコミュニケーションの問題と書いていますが、私は単純にコミュニケーションだけの問題ではないと思っています。お互いに要件定義や概要設計の段階で気がついていない不足機能があるものです。よく建築物に比べると、ソフトウェアは見せることが難しいので仕様変更が起きるという人もいますが、これも正しいとは思えません。建築物も大型になれば、設計図だけでは確認できないところは多くあり、トラブルになりやすいと思います。今、問題になっているマンションやホテルの耐震構造に対する構造計算書の問題も同様で実際に基準を満たしているかどうかは見てもわからないわけです。むしろ、ソフトウェアの方がテストが可能な部分が多いのではと思います。

これらの二つの問題に対するひとつの理想的な答えは、「自働化」を実現する開発環境システムです。専門化が定義した仕様をプログラミング工程を経ることなくダイレクトに実システムに変換するシステムが必要です。このシステムは洗練され集約された業務部品を保持しています。プログラミング工程を完全自動化するためにジャストインタイムでアプリケーションシステムを構築することが可能です。また、実際に稼動できるプロトタイプを見て要件を確認できるため手戻りを最小化することが可能です。もちろん、開発コストは低く、高品質が達成できると思います。