25.functionality+is+free

変幻する実行可能知識 25

機能はタダである

1. 機能はタダである

1970年代末, Philip B. Crosbyは「品質はタダである」と言いました ("Quality is Free: The Art of Making Quality Certain", Philip B. Crosby, McGraw-Hill, 1979). これは「品質を上げるのによけいなコストはかからない. むしろ品質を上げることによってコストを下げることが出来る」という彼の主張を挑発的に述べたものです (Crosbyのいう品質はいわゆる内部品質 = 仕様への適合なので, それでいいのかどうか, それが今も通用するかどうかはまた別の話ですが).

ここでは, Crosbyに倣って, より挑発的に「機能はタダである」(Functionality is Free) と言い切りたいと思います:-)

今までソフトウェアを作るもっとも主要な動機, 目的は「機能を実現すること」でした. 顧客は最終的にはソフトウェアの機能に対して対価を支払います (いやいや, そんなことはないという声はとりあえずここでは無視することにします). しかし, 今や機能を実現することはソフトウェアにとってさほど重要ではない, むしろソフトウェアにとって本当に重要なことを実現すれば機能は自然と (タダで!) 手に入るはずだというのが本論の主張です.

では, 何が「ソフトウェアにとって本当に重要なこと」なのでしょうか. その前にモデリングとは何かについて, 振り返ってみたいと思います.

2. モデリング

日本のソフトウェア開発の現状で「モデル」と言えば, ほとんどはUMLを思い浮かべるでしょう. この数年間でUMLはある程度は日本のソフトウェア開発の現場に定着しつつあるかのような雰囲気もあります. 特にオブジェクトで育ってきた若手にとって, またオフショア開発において, UMLは当たり前のコミュニケーション手段として用いられる場合が多いように思われます. それはそれで良しとしましょう.

では彼らは「何を」モデリングしているのでしょうか.

ソフトウェア開発において, モデリングの対象となっているものは大きく分けて次の三つだと思います.

  • a. ソフトウェア (作るもの, 作ったもの, 動くもの)
  • b. 要求 (ソフトウェアが実際に動く/使われる場所)
  • c. プロセス (作る過程)

(a) は, どのように実現するか (how to do) をモデリングするものです. これがもっとも一般的な (安易な) モデリングのユースケースだと思われます. ただし, 実はここには奇妙な二重構造があります. そもそも「プログラミング」というものが「どのように実現するか」を記述する (計算機械をモデル化する) ものであるのに, (a) の意味のモデリングは更にそれをどのように実現するかを記述しようというものなのです. 屋上屋を架しているのですね. 実はここではモデリング ≒ プログラミングです (抽象度や多面性などは異なる). ここからはモデル駆動開発やUML仮想マシンなどの方向への発展があります.

(b) は, 何をしたいか (what to do) をモデリングするものです. 最近ではビジネス・モデリング, 要求モデリングなどの形で重要なユースケースになりつつあると思います. 何をしたいかをモデリングしようとすれば, 当然その背景には何があるか (形式的な知識, 暗黙的な知識, 文化, ビジョン, 気持ち, 関係, ...) をモデリングせざるを得なくなってきます. 問題は (b) の意味のモデルは, 実現の過程でどこかに消えてしまうことが多いことです (少なくとも要求モデルが動く形でそのまま実現システムの中に存在することを目指すことはあまりない).

(c) は, 実現 (開発) の過程をモデリングするものです. プロセス・モデリングですね. プロセス・モデリングと実際のプロセスが相互作用し合って進んでいくようなソフトウェア開発はこれから重要になると思いますが, 今回は触れません.

3. 様相

今回問題にしたいのは, 前節 (b) の問題として述べた部分です. つまりビジネス・モデリング, もっというと背景のモデリングが実際に動くシステムの中に (明示的に) 組み込まれて動いていること, つまり背景をモデリングし続けるシステムです. もちろんそれが自動的に出来るわけではありません. 人がソフトウェアを使ってモデリングし続けるわけです. ここで人というのはエンジニアの場合もありますし (古典的に言えばいわゆる保守運用, 改修ですね. モデル・ベース・メンテナンスとでも言いましょうか), 問題ドメインの中にいる人 (ユーザ) の場合もあります.

このようにシステムの中に組み込まれて, 現実と相互作用し合っている背景知識のモデルをかっこうつけて「様相」と呼ぶことにしましょう.

ここで「様相」という用語は, 建築家 原広司の著作「機能から様相へ」(「空間 <機能から様相へ>」所収, 原広司, 岩波現代文庫, 岩波書店, 2007, 原著は1987) から採りました. ただし原の様相は, 英語ではmodalityと言うことになっていますし, 分野が建築ですから物理的/感覚的なものを対象としています. ここではこれをソフトウェア的に再解釈して, 英語ではtextureと考えることにしましょう (別にmodalityでもいいのですが:-). textは織ると言うことです (いわゆるテキストは模様と言うことらしいです). context (文脈) はtextを共にする (つまり共通のtextを持つ) ということ, textureは織ったものということになります.

つまりこの考え方では, 我々ソフトウェア開発者のもっとも重要な仕事はお客様の組織がもつ様相をソフトウェアとして, 目に見えるもの, 手を動かして操作できるものとして提供することです. 様相が実現されていれば, それを元にして何か機能を実現するのは難しいことではありません. 様相の実現に較べて, 機能の実現はほとんどタダで出来るはずです. 場合によっては専門家や技術者の手を借りなくても, ユーザが機能を実現することも出来るかもしれません.

我々は機能を実現することではなく, 様相を提供することによってお客様からお金をもらうべきなのです (見積もりの標準的な手法のひとつがファンクション・ポイント = 機能点というのは, ある意味で現状のソフトウェア開発の本質を示しているのでしょう).

4. 例

様相というややこしい言葉を使うからわけが分からなくなるのですが, もう少し具体的には様相とは何なのでしょうか.

例えば最近のいわゆる「(Web2.0的) コンテンツ」は規模の大きな, 公開された様相のひとつと考えられます. そこでもっとも重要なのは「機能」ではありません. ある範囲, 分野を覆う必ずしもよく形式化されていない知識, 情報, 気分の複雑に絡み合った織物です. その織物は静的ではなく, 多数の人が関わりながらどんどん変化していきます (eg. wikipedia). ソフトウェアがやることは, その最初のアーキテクチャを決めること, 織物の初期状態を用意すること, 織物が変化できるような仕組みを作ること, 多くの人が織物を眺めたり操作できるようにすることなどです. それさえ出来ていれば, その上の「機能」は後から誰でも必要な人が作っていくでしょう.

いわゆるビジネス・システムも, その範囲や分野は異なりますが基本的には同じことです.

例えば要求を定義する過程で, 概念辞書 (オントロジ) を作ることはよく行われます. しかしほとんどの場合, この辞書は最終的なシステムに直接組み込まれることはありません. 辞書はユーザ, 顧客, 開発者などの共通認識を獲得するため, あるいは開発者が問題領域をよりよく理解するために使われ, いわば開発者の頭の中で「コンパイル」されて, 「バイナリ」としてシステムのどこかに (目に見えない形であちこちに散らばって) 組み込まれています. いったんコンパイルされてしまった様相は, 基本的に変化に対応することが出来ません. そのために膨大なコストを「保守」に掛けざるを得ず, 保守改修による品質低下によってソフトウェアの寿命は限られてしまいます.

その代わりに, 辞書をユーザが編集出来るようにし, その辞書の定義に基づいてシステム全体が動くような仕組みを提供することにしましょう. これが様相を提供する (見えるようにする, 動くようにする) ということです. これは現実とソフトウェアの間の動的なリンク, 相互作用を実現すると言うことにほかなりません.

もちろん, ビジネスにある様相は概念辞書 (オントロジ) だけではありません. 組織構造, プロセス, ルール, 認証, 権限制御, 変更管理, 暗黙的な知識などさまざまな様相が織り込まれています. 理想的にはそれらがすべて有機的に統合されていればいいのでしょうが, 不完全であっても, 部分的であってもプロフィットがあると思います.

別の方向の例として, 例えばBSC (バランス・スコア・カード) 自体が組み込まれた業務システムなどを考えることも出来るでしょう.

5. 問題点

最後にこの考え方のいくつかの問題点, 疑問点を挙げて, 尻切れトンボ的に終わりにしたいと思います.

  • 最近業務的な分野, 消費者向け分野, 組込み的な分野の境界が曖昧になりつつあるとはいえ, 組込み的な分野でこの考え方は通用するのか?
  • 「機能で金を稼ぐ」稼業はなくなるのか, 併存するのか?
  • 技術的には現在, あるいは近い将来にどこまでが可能で, どこからが難しいのか?
  • モデリングだけではなく, アーキテクチャが重要なのではないか?
  • 結局「様相」には「機能」が含まれているのではないか?
  • 「様相」に対してどうやって, 何を基準にお金を払ってもらえばいいのか?
  • どんな「様相」が提供されるのかをどうやってお客様に伝えることが出来るのか?
  • ......

2008.05.17
山田正樹 (メタボリックス)

Comments