1986年秋に，ロッキー山中のスキーリゾートで，ICSEのプログラム委員会と併設のかたちで開催された第３回国際プロセス・ワークショップ（ISPW-3）は印象深い会合だった．わたしは，鳥居宏次・斉藤信夫の両先生と一緒に参加したのだが，なにしろ海抜３千数百メートルの高地だったので，とにかく呼吸が苦しかったのを覚えている．
このワークショップでは，20世紀末におけるソフトウェア技術の流れに大きな影響をおよぼした２つのプレゼンテーションが行われた．ひとつは，ワッツ・ハンフリーによるプロセス成熟度モデルの提案（後のCMMの原アイデア），そしてもうひとつはリー・オスターワイルによるプロセス・プログラミングの提案だった
翌年のICSE-9 in Montereyのプログラム委員長を務めることになっていたボブ・バルザーとわたしは，両者を見くらべた上で，オスターワイルのほうを基調講演者に選んだ．この選択が，1990年代ソフトウェア工学研究の中心に「プロセス・プログラミング」の話題が位置づけられる結果をもたらした．他方、ハンフリーのアイデアはその後 CMU/SEI で採択され，アメリカ国防省の強力な後押しもあって，世界のソフトウェア産業界にプロセス改善ブームを引き起こすことになった．
「ソフトウェア・プロセスもまたソフトウェアである」というオスターワイルの主張は，たしかに的を射ている．ソフトウェアの本質は何らかのデータ処理プロセスを表現したものなのだから，それを開発・運用するプロセスを一種のソフトウェアとして扱うことはできる．しかし，それがコンピュータ・ソフトウェアと同じようにプログラミング可能かどうかについては，ICSEでの基調講演に続いて，M.M.レーマン先生がカウンタートークで指摘したように，大きな問題を含んでいる．
ソフトウェア開発の仕事は，ただ手足を動かすという単純な肉体労働ではなく，ものを考えるという頭脳労働を含んでいる．開発プロセスの後半のいわゆる下流工程では比較的単純な手作業の比率が多くなるが，前半（上流工程）のシステム分析やソフトウェア設計の作業は，頭脳労働としての思考プロセスがほとんどの部分を構成する．
人間の頭の中で行われるそうした思考プロセスを「プログラミング」しようというアイデアは，レーマンが指摘したように，魅力的ではあるがしかしきわめて危険な試みなのであった．こうして，多くの人びとを巻き込んで行われたプロセス・プログラミングの研究は，いくつかのプロセス志向開発支援環境のプロトタイプ構築という中途半端な成果をもたらしただけに終った．オスターワイル自身も，その後，上流工程のプログラミングは意図半ばで放棄し，ソフトウェア開発以外の分野（たとえば医療における看護プロセス）への応用に転進して，ある程度の成功をおさめている．
一方で，ハンフリーの CMM は，大規模開発プロジェクトのマネジメント・プロセスの標準化にターゲットを絞り，スポンサーである政府機関や大企業に SPI（プロセス改善）の活動を売り込むことには成功した．しかし，それは，マクロな視点からのマネジメント・プロセスのプログラミングであって，コンサルタントたちの飯の種にはなったが，それ以上の域を出ていない．
問題は，ソフトウェア開発の核心である思考プロセスをどう考えるかということにつきる．思考はあきらかにひとつのプロセスなのであるが，われわれは通常それをプロセスとしてではなく，思考の結果として作り出される成果（すなわちさまざまなドキュメント）の集まりとして，間接的にしかとらえていないように思われる．
一般に，人間が考えるさいの道具はコトバだといわれているが，実はそうではない．コトバは考えた結果を表記するための道具でしかない．われわれが何かを考えるプロセスの中では，コトバ以外の何か，すなわちコトバになる以前の「記号のようなもの」が主要な道具として使われているのである．われわれの思考プロセスは，仏教の唯識宗がいうアラヤ識（蔵識）の中で行われている．それは，コトバになる以前のものを道具として行われているプロセスなので，もともとプログラミングすることは不可能なのである．
「人間の思考は頭の中での自分自身との対話プロセスなのだ」というソクラテスの指摘は正しい．その対話はコトバ以外のものを用いて行われる．他人との議論において、相手のコトバに対して，「それはわたしの考えと違う」「では，あなたの考えは？」「それがうまくいえないのだが，…」といったやりとりがなされる理由はそのあたりにある．禅の老師たちが唱える「不立文字」というスローガンが，そこで思い出されたりする．
