2003年12月02日
川俣晶の縁側ソフトウェア技術雑記total 3328 count

「オブジェクト指向に向ける懐疑の視線」と「情報化投資が初期計画より増える理由」に関係はあるか?

Written By: 川俣 晶連絡先

 この一文は、ある記事を読んだことに対する1つの感想です。単なる感想で、何かを正しいと主張しているわけではありませんし、書かれた内容の正しさを保証できるわけでもありません。むしろ、きちんと検証していないからこそ書いた本人が懐疑的であると言うことができます。

なぜ情報化投資は初期計画より増えるのか? §

 こういう記事を見ました。

なぜ情報化投資は 初期計画より増えるのか? ――システム部門Q&A 第2回

 この記事は、「222の法則」(情報システムの開発では、計画の2倍の費用と2倍の期間がかかり、計画した2分の1の機能しか実現できない)や、「2423の法則」(ベンダ側の話で、「契約したときの規模・金額は2であった。ところが要求分析の段階で4の規模になってしまった。それで追加費用を要求するのだが2しか払わないという。結果として3の費用で4の規模のシステムを開発したが、ユーザーは費用が2→3になったことに不満を持ち、ベンダは3の費用で4の規模をやらされたことに不満を持つ)といった法則を紹介した後、なぜそのような事態が起こるかを説明しています。

 その理由は、「情報システム部門やベンダのSEの能力が低いから」ではなく、「近年の情報化投資では、情報化そのものの投資であるよりも、経営戦略実現のプロジェクト投資の一部分であることが多く、しかもその成否は非情報化活動に懸かっていることが多い」であるとしています。

なぜこの記事が重要であると思ったのか §

 このような視点は、大変に重要だと思います。

 実際、多くのソフトウェアは、純粋に技術的に構築できるものではなく、大きな世界、環境の一部を構成するものです。ソフトウェアは、現実から切り離された抽象的な理想世界にあるのではなく、泥臭い現実と緊密に連携して使われることが要求されます。

 まあ、世の中には定型化されて滅多に変化することのない業務というものがあって、それを行うソフトウェアを現実から切り離された環境で作り出すことも不可能ではないでしょう。しかし、それはソフトウェアを現実から切り離すことができるということではなく、要求が変化しないために、要求を明確化した後で現実とのインタラクションを省略できると言うだけの話です。

 最近多い、インターネットなどの技術を前提としたソフトウェアであれば、おそらく、変化が早いため、開発は現実とのインタラクションを行いながら遂行する作業とするしかないでしょう。

 そういう状況から考えたとき、要求の変化は常に発生するものであるという視点が重要であって、それを最初から取り込んだエクストリーム プログラミングのような開発手法は必須であると思います。しかし、ただ単に変化を受け入れるだけでは不十分で、それに加えて経済的な要因に対する認識も必須だと思います。変化に対応してソフトウェアがひたすらコストアップしていくような状況は、けして受け入れられるものではありません。そういう視点まで含んでいる点で、エクストリーム プログラミングを評価している……という話は余談として。

オブジェクト指向は現実をシミュレーションする……らしい §

 オブジェクト指向というのは、一種の現実のシミュレーションを行うことからスタートしているようです。オブジェクト指向プログラミング言語の元祖はシミュレーション用のプログラミング言語だったりするそうですが、そのあたりは突っ込みません。

 そこで、私が前から思っている疑念は、プログラムは現実の一部を構成する実在物であって、現実をシミュレーションする仮想の存在ではないのではないか、と言うことです。もちろん、現実をシミュレーションするプログラムを作成する場合には、オブジェクト指向の持つシミュレーション的性格は有益でしょう。しかし、何かをシミュレーションしていないプログラムもけして少なくありません。

 たとえば、電子メールを配送するシステムを、現実の郵便のシミュレーションとして構築するシステムであれば、電子メールの集配を行うオブジェクトを「郵便局」と名付け、郵便局が持っている機能性を模倣するように設計することができます。こうすれば、郵便局の機能性を知っている人であれば、郵便局オブジェクトの実装の詳細を知らなくても、郵便局オブジェクトが何をする機能性を持っているか容易に推測できてハッピーとなります。

 しかし、このような方法論で、実際に役に立つ電子メールシステムが構築できるかというと、それは難しいだろうと思います。なぜなら、電子メールというのはシミュレーションされた郵便物ではなく、現実世界に実在する1つのコミュニケーション手段であるからです。電子メールに要求される機能性と、郵便物に要求される機能性は同一ではなく、あくまで電子メールは電子メールなのです。

 そこから考えると、オブジェクト指向におけるシミュレーション的な性格は、本当に有益なものなのだろうか、という疑問が湧いてきます。

 なお、ここで書いていることは疑念であって、間違っているという論証ではありません。念のため。

現実の一部としてのソフトウェア開発 §

 最近、私が考えているソフトウェア開発の方法論というのは、実は非常に狭い領域に限定しています。つまり、直接的にどのようにプログラミングするかという問題だけに対象分野を制約していて、直接プログラミングに関わらない、たとえば業務の分析のような領域は一切対象に含めて考えていません。

 そう考えるようになったのは、直接プログラミングに関わらない領域について何かを行うことは、ソフトウェアの問題と言うよりは、業務の問題であったり組織の問題であったりするのではないか、と思うようになったからです。それらは、ソフトウェア開発という観点から関わるべきものではなく、関わっても不完全に終わるだけではないか、と思うわけです。

 とはいえ、そういう問題に関わらざるを得ないという状況は確かにあります。たとえば、ソフトウェアシステムを発注する側が、自分の要求を明確化できず、開発する側が分析しなければならない場合も多いと思います。しかし、それは、やむを得ず行われるものであって、あるべき理想の姿ではないと思います。仮に理想のソフトウェア開発手法を目指すなら、それには直接プログラミングに関わらない領域に関する手順を含めるべきではないかも知れません。(断言はしていません。念のため。書いた本人も信じていないし)

蛇足 §

 実は、こういう結論は完全ではありません。たとえば、ソフトウェア開発は、組織が行う大きなプロジェクトを構成する一部であると認識したとします。その場合、プロジェクトの実行委員会の言いなりになって、ただ言われたとおりにソフトウェアを開発すればよい、と言うことにはならないでしょう。やはり、コミュニケーションとインタラクションが必要です。たとえば、ソフトウェア開発現場からのフィードバックによって、プロジェクトの内容が修正されるような状況が、当然あり得るべきです。たとえば、重要だが必須ではない機能について、開発現場で予想以上のコスト高であることが判明した場合、それを本当に開発するかどうか検討する機会が与えられるべきです。プロジェクト遂行側の立場なら、(そして、本当に何が何でもプロジェクトを成功させたいなら)、そういう検討のチャンスは絶対に欲しいものです。

 そういうことを考えると、ソフトウェア開発の方法論の守備範囲とすべき境界線が何となく見えてくるような気がします。それが正しいかどうかは、検証を経ずには結論できませんが。

2003年12月2日13時51分頃追記・更に蛇足 §

 この著者のサイトにあるMurphyology on Information Technologyをざっと流し読みしたら(時間がないのでじっくり読めない……)面白いですね。なお、以下のような注意書きがあるので、ご注意を。

次の少なくとも一つに該当するかたはご遠慮ください(^o^)。

  • 情報システム部門の経験が10年未満の人
  • 「悪魔の辞典」を読んだことのない人
  • お仕事で忙しい人

Facebook

このコンテンツを書いた川俣 晶へメッセージを送る

[メッセージ送信フォームを利用する]

メッセージ送信フォームを利用することで、川俣 晶に対してメッセージを送ることができます。

この機能は、100%確実に川俣 晶へメッセージを伝達するものではなく、また、確実に川俣 晶よりの返事を得られるものではないことにご注意ください。

このコンテンツへトラックバックするためのURL

https://mag.autumn.org/tb.aspx/20031202124329
サイトの表紙【技術雑記】の表紙【技術雑記】のコンテンツ全リスト 【技術雑記】の入手全リスト 【技術雑記】のRSS1.0形式の情報このサイトの全キーワードリスト 印刷用ページ

管理者: 川俣 晶連絡先

Powered by MagSite2 Version 0.36 (Alpha-Test) Copyright (c) 2004-2021 Pie Dey.Co.,Ltd.