先ほどお昼に外に出てみるとぽかぽかしてとても気持ちのいい天気でした。昨日まで霜が降りるほどの寒さだったのに。このまま暖かい春になってほしいな。
東葛人的視点はIT業界に対する鋭い批評でいつもチェックしているのですが、「完璧なソフトなど作れない」公的な場で言い放ったIT企業経営者の話は色々考えさせられるものがありました。
私も以前はプログラマーをしていたことがあってバグのないソフトウェアを作ることがいかに難しいかは骨身にしみて理解しています。
ソフトウェア開発では技術的な問題もありますが、政治的な問題のほうが大変だったりします。
顧客が仕様をまとめきれない、仕様変更をカットオーバー直前に言ってくる、ゼネコン構造の業界のため利益が取りづらいなどあります。
ここでは技術的な観点でソフトウェア開発を考えてみました。記事で書かれている「完璧なソフトウェアなど作れない」とありましたが、完璧なソフトウェアとは少しあいまいな言い方ではないかと思いました。
完璧なソフトウェアとはなんでしょうか？私なりにその条件を以下のように考えてみました。
1 顧客のやりたいことができる
顧客は問題を解決するためにソフトウェア開発を依頼します。
しかしそのためには顧客が問題を把握している必要があります。
場合によっては問題自体を開発側が発見しなければいけない場合もあります。
そしてその問題を解決する方法を提案することになります。
まずこの時点でのハードルがかなり高いですね。
2 あらゆる障害に対して考慮してある
ソフトウェアには異常事態に備えて様々な対策が組み込まれます。
しかししょせん人間の考えることですから全ての障害を予測することは不可能です。
この時点で完璧なソフトウェアを作ることは無理ということでしょう。
しかし予測しうる限りの障害を想定して妥当なところで手を打つということになります。
3 顧客にとってコストが妥当である
機能を多く持っていても顧客が払えないくらい高価だと買ってくれません。
ユーザーも投資対効果を考えるのであまり使わない機能は削ったり、めったに起こらない障害に対する対策を組み込まなかったりします。
開発は常に予算の制限を受けます。
4 ユーザビリティが顧客の満足するものである
人が扱うソフトウェアはユーザーインターフェースが品質の重要な要素です。
使いにくいソフトウェアは作業効率を下げますし、最悪な場合は使用されなくなることもあります。
私はユーザビリティは完璧なソフトウェアの条件だと思います。
完璧なソフトウェアは微分関数のようなもので、無限の資源を投入すれば可能なものなのでしょうね。
なので現場ではこれくらいが妥当であろうというところでリリースすることになります。
バグがゼロのソフトウェアを作ることも不可能でしょう。しかしバグを少なくする方法はあります。
その手段としてオブジェクト指向やデザインパターンなど様々な方法論が提案されていますが、それらがやりたいことは結局はシステムを小さいモジュールに分割しお互いが影響しあわないように作るということです。
システムを小さいモジュールに分けることによって特定の問題を集中して考えることができます。
人っていろんなことを同時に考えるのは苦手ですからね。
さらにお互いのモジュールが影響しあわないことによって、作業を分業化することができます。
MicrosoftもOSとアプリケーションを作る部署は別になっているでしょう。
そしてこのようなモジュール化の考え方はシステムアーキテクチャーだけでなく産業構造や企業組織の考え方にまで拡張されています。
「デザインルール」はそんなモジュール化に関するすばらしい分析を行っています。
エンジニアの方にはぜひ読んでほしい本ですね。
 | デザイン・ルール―モジュール化パワー キム・クラーク カーリス・ボールドウィン 安藤 晴彦 東洋経済新報社 2004-03-26 売り上げランキング : 34,898 おすすめ平均  Amazonで詳しく見る by G-Tools |
