対談:リアルウェア

2010年4月のよく晴れた日、新宿の伝統的なホテルのゆったりとした喫茶ラウンジにて、静かな対談がはじまりました。この日は、濱氏が知働化研究誌のために書き下ろした論文『リアルウェア』を主題として、意見交換をする運びとなった模様です。時々、こういった浮き世の対談をしているようです。

なお、濱氏の『リアルウェア』は、知働化研究誌創刊第1号に掲載されていますが、許諾をいただき、本サイトでもお読みいただけます。

濱勝巳『リアルウェア』LinkIcon

Hama_Photo.jpg

濱勝巳(はまかつみ)
株式会社アッズーリ代表取締役社長
株式会社富士通プログラム技研、フリーランスを経て、1999年アッズーリ社を設立。2000年よりアジャイルプロセスに特化したソフトウェア導入サービスを開始。アジャイルとソフトウェアセル生産を融合したITビジネスの投資実装プロセスを開発する。近年、禅等の東洋思想に関心があり、ソフトウェアや経営への適用を探求している。共著に「ソフトウェア現場力ハンドブック」。
アジャイルプロセス協議会会長
同見積契約WG,知働化研究会メンバ。

大槻繁(おおつきしげる)
株式会社一(いち)副社長 一(いち)は、IT/ソフトウェアエンジニアリングをコアとす るコンサルティングファーム。IT システム関連の調達・開発 プロジェクトの第三者見積り評価、診断・改善のコンサルティ ングをコアビジネスとしている。 IPA/SEC 非ウォーターフォール研究会 委員、JEITA/ソフトウ ェアエンジニアリング技術分科会 委員
アジャイルプロセス協議会 フェロー
知働化研究会 運営リータ

OtsukiShigeru.jpg

〔大槻〕送っていただいた『知働化研究誌』の原稿、面白かったです。対話形式というのが新鮮です。
〔濱〕 話の境界を作らずにだらだらと書いて行くスタイルが気に入っています。
    ファイヤアーベント(Paul Karl Feyerabend)の本『知とは何か : 三つの対話』の影響です。
〔大槻〕なるほど、科学哲学を語る新しい方法を発見したようで何よりです。

引き算のソフトウェアエンジニアリング

〔大槻〕さて、ソフトウェアエンジニアリングについて、その後の探求はいかがでしょう? 
    「否定」や「引き算」という見方は面白いと思っています。
〔濱〕 「作らない」ことだと思うんですよ。
〔大槻〕宮本武蔵みたいですね。戦わずして勝つ。作らずして価値を生む。
    「非ソフトウェアエンジニアリング」とでも呼びましょうかね。
〔濱〕 今までのソフトウェアエンジニアリングというのは、生産性を上げるとか、大きなもの、
    複雑なものをどうやって開発するかという問題設定だったのですが、
    「小さくする」エンジニアリングというアプローチがなされていないということに気がついたのです。
〔大槻〕今どきの「エコ」ってやつですね。「Ecoソフト」。なんか有り難みがわきますね。
    ユーザとベンダとの取引きでは、作ってなんぼということだったので、作ることに焦点が当たり過ぎていたんですね。
    「リファクタリング」は、機能を保持したまま良構造化することですが、こういったものにも価値があるという見方になると思います。
    もっと突き進めれば、使われていない機能を落としてしまって本当に使うものだけにする
    「広義のリファクタリング」という引き算の考え方も良さそうです。
〔濱〕 社会的にもお掃除とか、ゴミを無くすことって価値のある活動ですから、ソフトウェアだって同じでしょう。
    機能を食べるソフトなんていうのがあってもよいかもしれません。

ソフトウェアは無料

〔濱〕 ソフトウェアそのものには価値はないのであって、それが置かれているコンテクストや様相に価値があるのです。
    企業活動でも、それだけでは価値を生まないのです。
〔大槻〕ΛVモデルの「Λ」が中心ということですね。Λの部分は、意味(価値)・行為(要求)・感覚(テスト)で、
    「意味」の部分は主観世界の奥深いところにあるので難しい問題です。
    少なくとも、ユーザ/ベンダという取引き関係という見方をすると、たくさん要求をもらって、
    実現に勤しむことによって利益を得るという図式があるので、本来の目的である「意味(価値)」に焦点があたらなかったと言えます。
    昨今の内製化のトレンドというのは、要求を大きくする志向性を排除できるので、本来のあるべき姿なのかもしれません。
〔濱〕 従来の意味でのソフトウェア開発ベンダの時代というのは終わっていると思います。
    最近のベストセラー『Free』風に言えば、無料ソフトウェアの時代かもしれません。
    無料でパッケージ提供してしまうことや、Webサイトでクライアントが直接、プログラミングをしてしまうような
    シームレスな流れが重要になってくるでしょう。
    最終的には従来の意味でのベンダは無くなり、ユーザ価値をもたらすコンサルティングや
    ビジネススキームをデザインすることが主要な仕事になるのだと思います。
    また、金銭的価値とそれ以外の価値も多様化していくので、単純な価格設定はできなくなるし、
    一見「無料」の世界ももっと広がっていくような気がします。
    コンサルティング料は「お布施」のような位置づけになっていくかもしれません。

ソフトウェアは保守が中心

〔大槻〕かつて札幌の見積り・契約WG合宿の折にまとめたSPC(特定目的会社:Special Purpose Company)が
    理想的なソフトウェアに関するビジネススキームだと思っています。
    ユーザ企業と開発企業、さらには、保守企業などが出資して一つの企業体を作り、そこで継続的に開発や保守、
    広義のリファクタリングなどを行い、そこから得られた利益を出資企業に還元するというものです。
    これは広い意味での内製化とも言えますし、先ほど述べた要求や開発対象が大きくなってしまうリスクを避けることもできます。
〔濱〕 元来、アジャイルプロセスというのは保守に近いですし、ソフトウェアのライフサイクルを見守ることが本質に思えています。
    「アジャイルSPC」がよいのかもしれませんね。
    ビジネス領域でよく言われるスマイルカーブで言えば「保守ビジネス」がこれから主題になっていくと思っています。
    アジャイルプロセスについても、今までの世の中の議論では、作り手側の話ばかりでしたが、
    ユーザ側のアジャイルプロセスというのがあまり議論されてきていません。
〔大槻〕確かに、その通りですね。Λで言えば、意味の獲得や修正方法、要求の発し方、
    実装されたソフトウェアの動作からの感覚を得た時の対処の方法、
    要求とテスト、あるいは、テストから次の要求へのプロセスなどは、ほとんど解明されていませんし、規範もないというのが実状です。

テストの本質

〔濱〕 「テスト」という言葉は、あまり好きではないんですよ。五蘊(ごうん)で「見る」とか、
    「心眼」のような感じ。
〔大槻〕ΛVモデルで要求R、テストTととりあえずV字モデル側の制約で「テスト」としてのですが、
    私もこの言葉は適切ではないと思っています。
    言い訳っぽくTはTracingやTrackingとも言うとしています。
〔濱〕 僕がテストを好きでないもう一つの理由は、開発においてもテストって本当はいらないんじゃないかと思っているからなんです。
〔大槻〕テストがいらないというより、いくらやってもきりがないということですよね。
    原理的にプログラムが仕様を満たしていることをテストによって証明することはできません。
    所詮テストは自己満足の域を出ません。一部の性質、例えば、関数等価性なら数学的証明によって論証することはできます。
    「ソフトウェアクリーンルーム手法」の原理です。
    関数等価性以外の性質についてもなるべく数学的証明でやるというのが正しいアプローチです。
    それがだめなところはモデル検証とか実行確認に頼らざるをえないかもしれません。
    さらに、仕様そのものが、そのソフトウェアが置かれているコンテクストで、要求に適合しているかどうかということは、
    要求を欲した本人しか確認することができません。
〔濱〕 ソフトウェアのテストや実行に、きりが無いというのは、結構本質的な問題です。
    コンテクスト含めて変化し続けるものです。要求というか、解くべき問題というのが次から次へと出現し、
    それをソフトウェアで解き続けるというライフサイクル的観点が必要だと考えています。

人月からの脱却

〔大槻〕その意味で言うと「狭い意味でのソフトウェアづくりは創造的活動ではない」ということですよね?
〔濱〕 ソフトウェアがソフトウェアだけで価値を生まないのと同じように、それを作るだけでは価値のある知的活動だとは言えないでしょう。
    いくらプラクティスをいっぱい取入れてアジャイルプロセスをやったとしても、それだけでは価値は生まれない。
〔大槻〕価値というのは経済学的に見てもダイヤモンドのような希少性と、水や空気のような必要性の両面があります。
    ソフトウェアが、実世界にある問題を解くものであるという観点からすると、同じ問題を解き続けても、価値は生まれません。
    新しい問題を設定し、新しい解を得ることに挑戦し続けなくてはならないでしょう。これが経済学的な原理から言えることです。
    無論、労働価値説は通用しないので、価値とコストとは本来関係がありません。
    現実には、いまだに人月ベースの取引きが多いので、ソフトウェア業界は未だに労働価値説にあると言っても過言ではありません。
〔濱〕 とりあえずセル・月まで行きましたけどね。問題は、その先です。よいものをつくれば価値が高くなるというわけでもなさそうです。
〔大槻〕「よいとは何か?」という問題ですね。よく言われるのが、技術的に優れていても、
    マーケットシェアが確保できるとは限らないということです。
〔濱〕 よいプログラミング言語は流行らないとか。
〔大槻〕まぁこれは戦略とかビジネスモデルの問題とも言えます。
    よいソフトウェアを、価値が高くなるようにしていくことが、価値指向の戦略として重要だということになります。

求められる人材

〔濱〕 そのような観点から言うと、そもそも世に言う技術指向の「理系」の人がこの業界に向いているというのも幻想だと思っているのです。
〔大槻〕なかなか過激な見解ですね。「理系」の定義にもよると思いますが、数学的素養は必要でしょう。
    欧州では文学部哲学科の中に数学があるようですし、数学は「文系」かもしれませんよ。
〔濱〕ソフトウェアエンジニアリングが「記述」に関する活動ですから、文学や社会常識、文化的素養が求められると思います。
    プログラミング言語の記述は手順を表現したもので済みますが、仕様や制約記述をしていくことも大切なことです。
〔大槻〕そしてたぶん、実世界を観察し、問題を発見し、表現する「抽象化能力」が、ソフトウェアエンジニアリングで最も必要な能力です。
    もう少々範囲を限定して述べるならば、アジャイル・ソフトウェアセル生産のシェフには抽象化能力が必要ということです。
    コックの世界はソフトウェアづくりが創造的活動ではないという見解に賛同します。
    あえて補足しておきますが、創造的でない仕事だから地位が低いとかそういった話ではありません。
〔濱〕 よく「定形業務」と「非定形業務」といった分類がありましたが、「手順的」と「創造的」というのが対応しているのかもしれません。
    でも「創造的」な活動というのは、何をやっているのでしょうね?
〔大槻〕難しい質問です。
    強いていえば、問題を作るということかな。
    問題の前提となっている世界や空間を作ることも創造的な活動だと思います。
〔濱〕 そうなってくると先ほどの「抽象化能力」がますます重要ですね。

数学、哲学、そして仏教

〔大槻〕実を言うと、最近、「記述」という活動そのものが何かというのも気になっていて、
    数学的思考や抽象、定式化といったことの本質が何かがよくわからないのですよ。
〔濱〕 あるものを、あるがままに述べたり、書いたりすること。だと思います。
〔大槻〕おぉ、まさに仏教的ですね。石飛道子先生の『ブッダと龍樹の論理学』をここのところ読んでいるのですが、
    まさに「ぶっ飛び」です。西洋論理学とはあまりに違う。
〔濱〕 僕にはすんなり腑に落ちます。
〔大槻〕流石ですね。
    私はどうしても西洋論理とブッダ論理を翻訳しようとしてしまうので、なかなか難解なところがあります。
    語の順番に意味があるとか、接続詞の用法も異なります。AかつBが、BかつAとは違うと言われてもねぇ。
〔濱〕 そりゃ違うでしょう。頭に思い浮かぶ順序が違うんだから。
〔大槻〕そうそう、そこなのですよ。言語ゲーム的に考えれば、結構すんなりと対応することが最近わかってきました。
    つまり、西洋論理というのは、表層表現と深層の論理関係とを区別していて、
    これに対してブッダ論理は言語化(あるいは認識)と論理関係をいっしょにしている体系なのです。
    そうならそうと言ってくれよと思いますが、そこはなかなか奥ゆかしい。
〔濱〕 ということは、ブッダ機械(マシン)をつくれるということですか?
〔大槻〕オートマトン理論で言う「計算」まで行けるかどうかはわかりませんが、原理的にはつくれると思います。
    面白いところは、「認識と記述の同時進行」の体系になるということになることです。
    これについては、しばし探求の時間をください。数年は楽しめそうです。

実行と暗黙知

〔濱〕 「実行」とは「記述」することだったりして。
〔大槻〕深いですね。「実行可能知識」の定義にもこの実行と記述との関係について入れていきたいところです。
〔濱〕 人工物(アーティファクト)の中でソフトウェアがソフトウェアであるゆえんは、
    この「実行」概念が握っていると思っても過言ではありません。
    花屋を経営するのと、ソフトウェア企業を経営することの違いは、ここにあるのかもしれません。
    次世代の花屋はもっとソフトウェア的かもしれませんけどね。
〔大槻〕認識の問題とかもいっしょに考えていくと、「暗黙知」と「形式知」との関係も関わってきそうです。
〔濱〕 「暗黙知」にこそ価値があると思っているのです。「形式知」を「暗黙知」にしていくところに、
    価値が生まれるといってもよいかもしれません。
〔大槻〕共同化(暗黙知→暗黙知)、表出化(暗黙知→形式知)、連結化(形式知→形式知)、内面化(形式知→暗黙知)
    というサイクルを繰り返しながら発展していくというSECIモデルで、重要なところは「内面化」であるというのに私も賛成です。
〔濱〕 そうですよね。暗黙知を形式知化することに価値があるという人もいるのですが、僕は逆の発想なんですよ。
〔大槻〕シュレーディンガーが「学習とは無意識化することである」という定義を述べているのですが、このことだと思うのですよ。
    形式知、手順、規範といったものを一生懸命学習し身につけることによって、それが次第に無意識にできるようになって、
    その状態で、本当の暗黙的が熟成されていくのですよ。
〔濱〕 ということは、ソフトウェアエンジニアリング、否、非ソフトウェアエンジニアリングでは、「暗黙知の手法」が望まれていますね。
    ひたすら座していよとか。スリッパを揃えるのも修行とか。
    あるいは、「道」のような形式をマスターすることによって、その奥にあるものをつかむといったアプローチになるでしょうね。

〔大槻〕おっと、そろそろ時間ですね。本日は、とても有意義な対談でした。どうもありがとうございます。
    通奏低音として、仏教の思想、否定や引き算の観点、形式知と暗黙知との関係、言語ゲームの考え方があり、
    リアルウェアやΛVモデルといった枠組みも定まってきましたね。
〔濱〕 旧来のパラダイムの呪縛から解き放たれ、神話をまとめ、次世代の未解決問題を設定するという
    「ソフトウェアエンジニアリングの呪縛WG」も本日のような対談の延長線上に位置づけられるでしょう。
〔大槻〕そうですね。「未解決問題」は新たに設定されるとして、旧来と新世代とにまたがる普遍的な上位レベルの問題設定として
    「本質的困難」があると思っています。
〔濱〕 では、お互い現世に戻ることにしましょう。どうもありがとうございました。