本章では、ソフトウェアエンジニアリングの第３の波に対する本格的な取組みの一つとして『知働化』について解説します。知働化研究会は、アジャイルプロセス協議会のWGとして、2009年6月に設立された先端的な活動です。コンセプトリーダとして山田正樹氏（メタボリクス社）、運営リーダとして筆者、現在メンバ数23名です。

【知働化のコンセプト】

　『知働化』の源流は、山田正樹氏が2003年頃から提唱してきたもので、以下のように集約されます。

• ソフトウェアに対する新しい見方

• 実行可能知識と様相／テクスチャ

【人働説から知働説へ】

 

　『知働化』のコンセプトは、かなり本格的なパラダイムシフトです。いわば、コペルニクス的転回と言えます。今までのソフトウェア開発に対して、『人月からの脱却』を標榜しつつなかなか糸口が見つけられませんでしたが、知働化はその可能性を秘めています。考え方、手法、コンセプト、アプローチ、哲学とありとあらゆる事項が再定義（脱構築）される新しい体系です。

【ITシステム（抽象機械）の世界観】

　『知働化』へのアプローチは、各研究者によってまちまちですが、筆者はジャクソンの『問題フレーム』をベースに展開を考えています。これについて、以降、簡単に解説をします。

　まず、「ソフトウェアを使って、実世界にある問題を解く」という立場については、誰しも賛同していただけると思います。

 

　実世界が在り、実世界と接続されたソフトウェアが稼働するコンピュータが在り、それ等に対する要求が在ります。図はこの関係を示しています。注意してほしい事項は、「要求」は実世界の現象を対象としているということです。「ソフトウェアの要求」というと、コンピュータシステムを対象にした要求と誤解されがちですが、本来は、コンピュータが接続された世界に対する要求でなくては意味がありません。

【E(Embedded)タイプソフトウェア】

　マニー・レーアン（M.M.Lehmann：英国インペリアルカレッジ）がEタイプ（Embedded-type）と呼ばれる考え方を提唱しています。英語の”embedded”は「実世界に埋込まれる」という意味です。これに対し、仕様を明確にして固めてしまい実世界の変化を受け入れない、あるいは、実世界の変化とはあまり関わりのないソフトウェアをSタイプ（Specifiable-type）と呼びます。さらに、問題解決型のソフトウェアをPタイプ（Problem solving-type）と呼びます。

　Eタイプは、プログラムと実世界対象は仕様のモデルになっています。もう少々正確にいうと、実世界対象を抽象化して得られた仕様、その仕様を具現化して得られたプログラムという２段階のプロセスを通じて、実世界対象とプログラムとは関係し合っていて、それ等が正しい関係を維持できるようにすることがEタイプソフトウェアに要求されることです。

 

　仕様が、実世界とプログラムの抽象であると同時に、モデルでもあるというところが重要です。「モデル化」というのは、あらかじめ決められた言語によって記述するということです。つまり、言語という色眼鏡をかけて見えたものを記述するということです。色眼鏡ですから、見えないところ、つまり、捨象されてしまう事柄もあります。ですから、モデル化には必ず抽象化が伴います。

　仕様が実世界の正しいモデルになっていることを、「確認(validation)」する必要があります。これと同時に、プログラムが仕様を満たすことを「検証（verification）」しなくてはなりません。確認とは、記述の正しさを、実世界の状況に照らし合わせて人間が判断することです。実世界そのものは全て記述することができませんから、人間が記述やプログラム動作を見て判断するしか方法がありません。これに対し、検証とは、二つの記述の間の無矛盾生や完全生、充足可能性といったさまざまな性質を、数学的な証明、テスト等によって判断することです。仕様が形式的な仕様記述言語で記載された場合には、ある限られた条件下では、プログラムが仕様を満たすことを全て証明によって判断することも可能です。

　得られたプログラムと実世界との関係は、実世界でプログラムが正しく動作することを「確認」することと同時に、これが「適合」していくように、実世界とプログラムとが両立可能な変化をしていく必要があります。実世界はプログラムの実行によって何らかの影響を受けますから、実世界も変化します。無論、実世界の変化によって、プログラムが何らかの不都合を生じる場合には、それを修正していく必要がでてきます。この関係を常に保ち続けることが進化型のプログラムに要求されています。

【人工物（含ソフトウェア）のデザイン】

　さて、ここでソフトウェアを含む「人工物（アーティファクト）」について考えてみることにしましょう。人工物は何らかの意図をもって「デザイン」されるものです。最初に紹介した「スズメを撃つのに鉄砲を持ち出す」、私の自信作？「スズメを撃つのにはぱちんこがよい」もデザインされた人工物です。人工物は実世界に在って、人々に影響を与え、認識も変えていきます。おそらく、読者の皆さんも、本資料を読んだ後に、「ぱちんこ」を見た時に、今までとは違う解釈や意味を感じるはずです。

 

　ソフトウェアが実世界に置かれる人工物であるということは、前述の「ITシステムの世界観」の図にも表わされています。ソフトウェアがもたらす実世界の振舞いは、自然現象や装置の制御といった物理法則だけではなく、人間の社会的な規範、文化、意味にも作用を及ぼします。

　クラリス・クリッペンドルフは、『意味論的転回：デザインの新しい基礎理論』の書籍の中で、「人間中心のデザイン」を説いています。「科学」というのは、過去に起こったことを分析して何か法則を見いだしたり証明したりするのに対して、「デザイン」というのは将来について意思決定していくので、ぜんぜん違う、「人間中心」の「意味」を扱う体系でなくてはならないということを主張しています。

　そして人工物も社会・経済的な変化に対応して、考え方も変わってきています。この変遷をまとめたものが、以下の図です。

 

　初期の人工物のデザインというのは、生産者の論理で機能を提供する「製品」を開発することで済みました。それが経済の発達により市場の論理が支配するようになって「商品、サービス、アイデンティティ」をデザインしなくてはならなくなりました。意向、より人間中心、意味中心にシフトしていって究極は、人工物のもたらす意味や意義を言説や行動規範を考慮して「ディスコース」としてデザインする時代になったというのが、クリッペンドルフの主張です。これは、ソフトウェアについて当てはめてみると、第１の波が「製品」の時代、第２の波が「商品等」〜「プロジェクト」の時代、そして、第３の波が「ディスコース」の時代と、ゆるく対応づけることができると思います。

【問題フレーム】

　人間中心のデザインによる人工物としてのソフトウェアを、知働化のパラダイムのもとで具体的に開発していく方法論を確立したいと考えています。その一つのアプローチが、筆者が考えているジャクソンの『問題フレーム』をベースとしたものです。

　『問題フレーム』を一言で説明するのは難しいのですが、誤解を恐れずに言うと、「ITシステムの世界観」で述べた、コンピュータ世界、実世界、要求との関係を明確にすることによって、問題に集中し、これを分析・定式化していく観点を、５つの基本的なフレーム（パターン）で提示しています。

 

　最終的には、（抽象）機械をプログラムによって実現することになりますが、その前に、実世界（問題領域）を中心にして分析を進めていきます。実世界の現象をどのように制御したいかということが「要求」ということになります。実世界の問題の所在を「ドメイン」で表わします。ドメインというのは、ジャクソンの『問題フレーム』では、物理現象によって支配されるもの、装置、そして、オペレータやユーザといった振舞いが予測できない人です。

　このように込み入った実世界にある問題をソフトウェアによって解くためのフレームが５つ提示されています。

 

　以上が、ジャクソンの提案している『問題フレーム』の骨子ですが、筆者は、これを『知働化』の世界で適用できる方法論としていくために、３つの拡張を検討しています。

【拡張１：社会ドメイン】

 

　ジャクソンは、ドメインの種類を、「原因ドメイン」という主として物理法則による因果関係に支配される世界、「従順ドメイン」という振舞いが予測できない法則なき人間の世界、「語彙ドメイン」というデザインされるデータの世界の３つに分類しています。筆者は、これに「社会ドメイン」という社会的コード（規範）によって行動の因果関係が生ずる現象領域を付加するとよいと考えています。これは、人工物としてのソフトウェアが、人の価値や意味解釈に影響を及ぼすことを意図したデザインの対象となる領域です。

【拡張２：主観世界（言語ゲーム）】

　クリッペンドルフの『意味論的展開』での基底にある哲学は、ヴィトゲンシュタインの『言語ゲーム』です。ヴィトゲンシュタインは、20世紀初頭に活躍した哲学者です。最終的に到達したものが『言語ゲーム』です。これは、従来の客観的、絶対的な世界観を否定し、「物の世界」でも「事の世界」でもない、全ては「言語的事象の世界」であるという世界観です。言葉の意味も、何か絶対的なものを指示するというのではなく、用法によって定義されるとしています。

　この考え方は、知働化のパラダイムに旨く適合しています。人、それぞれがものの見方が異なり、その解釈や意味も異なります、この主観的なものを、社会の中で相互にやりとりしていくためには、『言語ゲーム』をベースにしたとらえ方をしなくてはなりません。

 

　一つの言語や概念が通じる範囲を、ここでは「ディスコース」としてひとまとまりに考えるようにするとよいと考えています。すなわち、ディスコースとは、以下のように定義されます。

　例えば、信号機をコンピュータによって制御して、交通を制御する場合、信号機の装置へのパルスについては、装置のドメインの物理法則を考慮することで済みますが、赤は止まれで、青は進め、青の点滅は注意して進めといった事項は、社会的な規約の問題で、これを規定する範囲をディスコースとして示しておくとデザインや分析が旨くできると考えています。

【拡張3：進化・適応】

 

　ソフトウェアやシステムが実世界に置かれ、環境に適応していくものと見なすのが「進化型ソフトウェア」です。ソフトウェアやシステムの場合には、突然変異というより意図されたコードによるものですが、実世界とのやりとり、環境に適応していくところをデザインする必要があります。

　得られたプログラムと実世界との関係は、実世界でプログラムが正しく動作することを「確認」することと同時に、これが「適合」していくように、実世界とプログラムとが両立可能な変化をしていく必要があります。実世界はプログラムの実行によって何らかの影響を受けますから、実世界も変化します。無論、実世界の変化によって、プログラムが何らかの不都合を生じる場合には、それを修正していく必要がでてきます。この関係を常に保ち続けることが進化型のプログラムに要求されていることです。

　一方、人工物としてのソフトウェアは、ユーザの理解の仕方によって、ユーザの行為や人工物から受ける感覚に影響を及ぼします。この理解の構造は、時間がたったり、ユーザの置かれている環境によって変化していきます。その変化によって、新たな、人工物と人とのインタフェースの不適合を起こしていきます。これを、プログラムとドメインとの間の適合に反映させていく方法を確立することが要請されています。

【ゆるさ】

　プログラムとドメインとの適合問題というのは、「広義のアジャイルプロセス」で述べた、開発プロセスとビジネスプロセスとの関係に対応しています。開発プロセスとビジネスプロセスを、固く、厳密に噛み合わせてしまうと、融通のきかない固いシステムになってしまいます。そこには、ある程度の「ゆるさ」が要求されると考えています。

 

　最近のクラウドコンピューティング等でも採上げられている領域では、ゆるさが役に立つ場面が多く考えられます。