東工大授業成果展覧会のお知らせ

東工大のPBL演習授業は今年で6年目になります。今年も産デ振(産業デザイン振興会)のご協力を得て、12月の19日 – 20日の2日間、六本木ミッドタウンにあるDesignHUBにて展覧会を行います。

では、下記ご案内をどうぞ。お待ちしております。

———————————————————————————————–
東京工業大学 情報技術人材育成のための実践教育ネットワーク形成事業成果展覧会
2012年度展覧会テーマ:「闘うチーム開発」

東京工業大学では,2012年度より,文部科学省の支援を受けて「情報技術人材育成のための実践教育ネットワーク形成事業」を実施しております.
この展覧会は,東京工業大学における本教育プログラムのひとつであるシステム開発プロジェクト総合実験の成果を学生自身により発表するものです.
今年度のシステム開発プロジェクト総合実験は,6~8名からなるチームを組み,Android端末とサーバー側アプリケーションとの連携システムを開発するという,PBL(Project Based Learning)型の実践的ソフトウェア開発演習授業となっています.
皆様のご来場を学生・教員一同,心よりお待ち申し上げております.
【展示内容】
ソフトウェア開発という行為は,プロセスの中に存在するものです.ひとつのソフトウェアができあがるまでには,様々な抽象化レベルにおいて適切なモデルが選択され,それを用いてた検討がチームの中で行われ,その結果多くの生成物が作られます.そのプロセスの中で,学生達が迷った分だけ,議論した数だけ,完成したソフトウェアは,その存在の証として痕跡を残します.
東工大の学生たちは チームに分かれて議論しながら,アイデアを発想し,それを仕様記述にまとめ,そしてその実現のためにアーキテクチャデザインを行い,ソフトウェアを開発しました.本展覧会ではその成果をその開発プロセスとして現れる痕跡を中心に展示致します.ソフトウェアが完成するまでのプロセスの重要さを,この展覧会で感じとって頂ければ幸いです.
【日時】
2012年12月19日(水)
展示:17:00 – 19:00
プレゼンテーション:17:30 – 18:00
2012年12月20日(木)
展示:11:00 – 15:30
プレゼンテーション:11:30 – 12:00, 14:00 – 14:30
【場所】
東京ミッドタウン・デザインハブ
インターナショナル・デザイン・リエゾンセンター
アクセス

【観覧料】
無料
【申込み】
不要
【主催】
東京工業大学 大学院情報理工学研究科

———————————————————————————————–

 

 

Agileのベースライン

2012年10月10日から12日までの3日間、大阪国際交流センター(大阪府大阪市 http://www.ih-osaka.or.jp/)で行われる、ソフトウェアプロセス改善カンファレンス(SPI Japan2012)の企画セッションを担当することになりました。
10月10日(水)15:00 – 17:00に行う「Agileのベースライン」という企画セッション(パネルディスカッション)です。

パネリストは、下記の4名の方々です。
(50温順 敬称略)
・阪井誠(SRA)
・西丈善(XPJUG関西)
・前川直也(パナソニック)
・和田憲明(富士通)

本企画セッションの説明文は下記になります。
「日本においては、過去を否定し新規のルールを敷設するのではなく、ターニングポイントに行きあたったときには常に「われわれとは何であるのか」を問い直すことによって、過去と変革との均衡ポイントを見つけてきた(レヴィ=ストロース)。
昨今、あれもAgile、これもAgileと耳にするようになってきました。踊り場を迎えていると思われる日本のソフトウェア技術にとって、今まさに「Agileとは何であるのか」を問い直すことは、均衡ポイントを見つけるための重要なテーマではないかと思われます。
パネリストとともに議論し、Agileのベースラインを一緒に引いてみませんか」

SPI Japan2012への申し込みは下記になります。
https://www.jaspic.org/event/2012/form/SJ/registration.html

また、本企画セッションのみ参加の場合は、SEA関西プロセス分科会のページから申し込まれますと、一般2,000円、学生500円で参加可能です。

SEA関西経由での申し込みは下記になります。
http://sea.jp/kansai/wp/?p=82

奮ってご参加ください!

 

支えあう

8月21日から3泊4日の日程で、岡山県美作市上山(みまさかしうえやま)に合宿に行きました。岡山県の美作は、かの宮本武蔵の故郷*。その美作市の南東、吉井川の上流、標高約400mに上山は位置しています。
かつては8,300枚の棚田を有し、夜になれば水面の数だけの月を映し出していた棚田でしたが、バブル期に住民の流出で多くの棚田が放棄され、20年あまりのあいだに、7割を越す棚田が姿をとどめなくなってしまいました。

上山の風景
右手の斜面は、まだ再生されていないかつての棚田です。

2009年からは、耕作放棄地となった棚田の再生がはじまり、この活動の中心である美作市地域おこし協力隊(MLAT)のメンバーの協力を得て、奈良先端大学院大学で実施しているシステム開発演習の一環としてフィールドリサーチを行いました。

棚田再生のための野焼きを見学。この距離からでもかなりの熱さです。

2012年度のシステム開発演習は、「支えあう」をテーマに、地域活性のためのITシステムの開発を、大阪芸術大学(キャラクター造形学科)との合同授業として行っています。過疎、高齢化により、社会的共同生活の維持が困難になった地域は限界集落と呼ばれているようです。日本の多くの中山間地域がそうであるように、住民が40世帯あまりの上山においても、人と人との支えあいは、地域生活の維持と発展のための重要な要素であると考えました。

座学
合宿中の座学風景。

 

「支えあう」をシステム開発演習のテーマとした理由には、実は、もうひとつの意図があります。それは、システムを開発するには“メンバー同士が支えあわなければモノは作り出せない”ということを学生に学んでもらいたいということです。

チーム#01
チーム毎のワークショップ。奥に座っているのは、怪奇マンガ第一人者の日野日出志先生。
チーム#02
つなぎに身を包んでいるのは、現地「MLAT」のメンバー。
チーム#03
立命館大学でゲーミフィケーションを研究している学生にも参加いただき、アドバイスをもらいました。

この授業は、ソフトウェア開発にかかわる工学知見を演習を通して学んでもらう授業です。一方で、ソフトウェア工学を含め、技術は、ともすると「人」を交換可能な部品として扱うものであるととらえがちです。そのため、特定のツールや手法に興味がいってしまい、「人」という要素が遺忘され、共同してモノを作り出すという根本的なところの大切さや難しさが忘れられてしまいがちです。また、学生を取り巻く昨今の教育環境は、教育が本来教えるべきである人と人とが支えあうということよりも、残念ながら、他者に対して相対的に有利なポジションを取ることを、無意識的にも刷り込んでしまっているようにも思えます。

ソフトウェア開発という、人と人とが共同する知識労働を成功させるために本質的に大切なものは何か。この授業で学ぶ、というよりも体験して欲しいと考えています。

* ということを、「バカボンド」で知ったというと日頃の知見の出所が疑われるところですが、おかげで、同行していただいた大阪芸大のキャラクター造形学科(別名、マンガ学科)の先生方とも意気投合し、教養の懐は広くしておくべきであるとあらためて実感しました(笑)

システム開発演習夏合宿in上山

今年から、奈良先端大のマルチスペシャリスト育成プログラム「IT-Triadic」がスタートしました。
本プログラムの中の先端複合演習「Design as User Experience」は超上流工程からのシステム開発をPBL形式で学ぶ演習授業です。
この授業は、大阪芸術大学のキャラクター造形学科とのコラボレーション授業となっており、大阪芸大の学生と奈良先端大の学生とがチームを作ってシステム開発を行います。
開発はPS Mobile上で行い、ソニー・コンピュータ・エンタテイメントの支援と協力を受けています。また、立命館大学映像学部の中村教授や岡山県立大学、美作市上山の上山棚田団の皆さんなど、多くのご協力の上に成り立っている授業です。

この授業では、超上流工程の要件開発プロセスの一環として、フィールドリサーチを行います。今年は、棚田で有名な岡山県美作市上山に8月21日から3泊4日のスケジュールでフィールドリサーチ合宿を行います。

岡山県美作市上山について

美作と書いて「みまさか」、上山と書いて「うえやま」と呼びます。岡山県美作市上山には、かつて800枚を超える美しい棚田があったといわれいます。戦後の減反政策、労働者の都市への流出によって、上山もまた、日本の多くの農村部が抱える人口減と高齢化問題の波に飲まれ、いわゆる「限界集落」として、かつての棚田が絶滅の危機にさらされてきました。「限界集落」とは、過疎化による人口の減少、さらに住民の高齢化によって、社会システムの維持が困難になった地域を指します。実はこのような限界集落は、これまで問題となっていた地方農村部に固有な問題では無く、たとえば、東京都新宿区の戸山団地で顕在しているように、都市部のベッドタウンにも広く見られる現象です。また、3.11後の東北地方では、人口の減少と西への流出によって一気に限界集落化が広がっています。さらに、日本は、これまで誰も経験したことが無い少子高齢化、つまり、日本の歴史がはじまって以来、“人口が減少していく”という問題に取り組まなければならず、限界集落は、まさに将来の日本が直面する問題を先取りしている「場」といえます。今回の演習は、「限界集落に代表される現在の里山環境が抱える問題をIT技術で解決しよう!」をテーマに取り組みます。

合宿先である上山では、棚田の再生プロジェクトに加え、セグウェイ、Facebookやマイクロ発電などの最新技術を駆使して、地域活性に取り組むという新たな局面がはじまる兆しが感じられます。今回の合宿では、彼らとの情報交換や、住民との交流などを通じて、開発するシステム要件、すなわち、何を解決するのか(What)、そしてそれは何故解決すべきなのか(Why)の情報を収集します。

*参加学生の皆さんへ

合宿のしおりが下記よりダウンロードできます。

合宿のしおり201208(PDF 2MB)

プロジェクト計画の妥当性

プロジェクト計画が妥当であるか、つまり、プロジェクトが計画どおり行くか否かを論じることができるのは、「すでに、その計画の可能性について、ある程度の経験がある」場合に限られます。このような、経験に基づく判断をコミットメントといいます。経験が無いのにコミットする人のことを植木等(無責任)といいます。

歩むべき先が見通すことができるとき、人は真剣になります。先があまりにも見えていないとき、夢(実現しない夢)を見ます。問題が大きくなればなるほど、ひとりでは解決できないため、誰かが解決してくれるであろうという期待に皆が夢想します。その結果、責務が曖昧になります。先が見えなければ見えないほどプロジェクトは夢の中に迷い込み、リスクが大きければ大きいほど、誰かが解決してくれるであろうと全員が思い込みます。

一方で、先が見通せたと思っていても、「判断しないといけない局面」が現れた時点で見通しは誤っていたのです。判断とは「失敗している状態に今まさにいる」ということなのです。判断が求められた時点で、それまでの過去の行いは精算され、新たなスタートの白線が目の前に引かれるのです。

プロセス改善に至る少々歴史的な話し

現在、多くのソフトウェア開発の組織では、効率や品質向上のため、そして納期を守るために、“プロセス”の改善に着目した取り組みが行われています。
すでにプロセス改善に取り組んでいる組織にとっては、効率、品質、納期、すなわちQCD(Quality、 Cost、 Delivery)の向上のために、プロセスに着目した改善に取り組むことは自然な活動なっています。しかし一方で、「なぜプロセスなのか」、「プロセスとは何か」、「設計手法やコーディングの技術を上げることを考えるほうが早いのではないか」といった疑問をもたれる方も多いと思います。また、すでにプロセス改善に取り組んでいる組織でも、「なぜプロセスなのか」について、少々の疑問を持ちながら活動を行っているところもあるのではないでしょうか?
プロセス改善の意味と、プロセス改善を実行する際に重要となるプロセスのモデル化について述べさせていただきたいと思います。

“ソフトウェア工学”の誕生

ソフトウェアに関する研究、技術の分野には、「ソフトウェア科学」と「ソフトウェア工学」の2つの分野があります。「ソフトウェア科学」は、設計手法やプログラミング技術、コンピューターの応用方法に関する分野です。実は、日本国内の大学の情報処理系研究室のおよそ98%(実際にはそれ以上かもしれません)は、ソフトウェア科学系の研究を行っています。そのため、特に日本では、ソフトウェアの技術と言った場合、ソフトウェア科学の分野の内容を想像する方が多いようです。
一方、ソフトウェア工学とは、ソフトウェアを作るための技術分野です。その定義は、1960年代にさかのぼります。
1960年代の半ば、メインフレームコンピュータの急速な普及に伴い、作られるソフトウェアも規模が大きく複雑になり、また、コンピューターの利用者とソフトウェアの開発者といった区分けもできました。さらに、保守や管理の方法も問題となりました。現在のソフトウェア開発が抱える問題と同様な問題がすでに発生していたのです。このような問題は、当時「ソフトウェア危機」と呼ばれました。ソフトウェア危機は世界的、つまり、国を問わず一般的な問題となりました。そして、1968年にNATO(北大西洋条約機構)の技術委員会の主催によりドイツで開催されたソフトウェア工学会議の準備会議において、ミュンヘン工科大学のBauerが、ソフトウェア危機を解決するための技術分野として、「ソフトウェア工学」という概念を提案したと言われています。
その後、要求分析、ソフトウェア仕様、設計法、検証・保守といった、ソフトウェアライフサイクルの各開発段階の明確化の研究が進められ、データの抽象化、構造化、モジュール化などの方法論や各種技法の研究、さらにソフトウェア生産の自動化を目指すCASE(Computer Assisted(Aided) Software Engineering)などの開発環境が提案され現在に至っています。

技術の問題から管理の問題、そしてプロセスへ

ソフトウェア工学の技術的な進展の一方で、ソフトウェアの規模がさらに増加し、複雑度も増すとともに、ソフトウェア開発プロジェクトの管理の面での失敗に起因する見積もりの不正確さ、納期の遅れ、ソフトウェア品質に基づく事故などが問題となってきました。このようなソフトウェア開発プロジェクトの管理という新たな課題に対し、「ソフトウェアプロセス」という概念が登場し、広く議論されるようになりました。「ソフトウェアプロセス」という言葉自体は、1984年にイギリスのEghamで行われたソフトウェアプロセス国際ワークショップ(ISPW: International Software Process Workshop)からのことであると言われています。そして1987年、ソフトウェア工学国際会議の第9回大会において米国のOsterweilが、「ソフトウェアプロセスもソフトウェアである(Software Process Are Software Too)」という論文を発表して大きな反響を呼び、ソフトウェアプロセスの概念が急速に広まったのです。
今日、製造、流通、販売、そしてサービスといった産業全般にわたって、ソフトウェアが果たす役割は益々広がっています。ソフトウェアを開発する企業にとっては、高いソフトウェア品質が市場競争における重要な要素となり、また、日本の製造業を代表する組み込み系ソフトウェアの開発を行っている企業にとっても、ソフトウェア開発の技術力が企業の競争力を上げるための重要な課題となっています。このような産業構造のソフトウェア比重の増大に伴い、ソフトウェア開発の技術力が産業全体に大きく影響を及ぼすようになりつつあり、この傾向は今後益々増してくると予想されます。
その一方で、ソフトウェアの大規模化に伴ったソフトウェア開発のコストやリスクも増大する傾向にあり、ソフトウェアプロジェクトの失敗が、企業のビジネス自体に大きく影響をすることは、日々、実感していることではないかと思います。1960年代半ばにメインフレームコンピュータの普及とともに起こった“ソフトウェア危機”は、ソフトウェア規模の増大、企業競争の激化に伴う品質や生産性競争として形を変えて現在に至っていると言えます。

CMMの登場、そして現在

ソフトウェアの品質や生産性の課題を解決するために、米国では、国防総省(DoD:Department of Defense)のソフトウェア調達モデルとして開発されたCMMが、ソフトウェア開発組織のプロセス改善のために利用され、主に管理面における適用の研究が急速に進みました。そして、米国でのCMMの適用が進んだ丁度その頃、急激な規模の拡大や企業間の競争力として重要となったソフトウェア開発に対して、品質・コスト・納期(QCD:Quality Cost Delivery)に関する課題を抱えていた日本の企業においても、1998年頃より、CMMによるプロジェクトの管理技術に着目したプロセス改善の議論がはじまりました。2002年4月には、プロセス改善に関する議論の場として日本SPI(Software Process Improvement)コンソーシアム(JASPIC)が設立されています。そして現在、より高い生産性の実現や市場の要求の変化に対して、より柔軟な対応能力が求められており、CMMもCMMIにバージョンアップが図られ、プロセス改善はますます重要な課題となっています。

これまで見てきたように、現在では、CMMやCMMIによるプロセス改善が主流となっています。CMM/CMMIの開発と管理を行っているSEI(Software Engineering Institute)によると、2001年4月から2005年12月の期間でのCMM正式評定を行った組織数は、日本国内で177組織、全世界では、1,264組織にのぼります。また、2000年にリリースされたCMMIにおいても、2002年4月から2005年12月の期間で正式評定を行った組織数は、日本国内で131組織、全世界では1,264組織と報告されています。このように、いまやCMMそしてCMMIによるプロセス改善はソフトウェア開発組織の能力向上のための手段として一般的になってきています。
しかし、その一方で、プロセス改善にかけたコストに見合っただけの効果が、実際には得られていない、改善活動が形骸化してしまっているといった問題も、CMMやCMMIの普及に比例して報告されはじめているのも事実です。このような状況の中、プロセス改善を効果的に進め、その結果を確実に得るための方法が求められてきています。

セミナーご案内

「顧客価値共創のための超上流工程」というタイトルでセミナーを行います。日時は、2012年07月20日(金) 18:30~21:00 (18:00 開場)。場所は、大阪市立大学文化交流センターです。
下記は、そのセミナーの内容説明です。
セミナーの詳細と申し込みは(http://kokucheese.com/event/index/42595/)まで。

「何について語っているかさえわからないようなら、そのことについて正確さを云々しても意味が無い」とは、フォン・ノイマンの言葉です(厳しいですね)。
要件開発プロセス、最近は「超上流」と呼ぶのが流行のようです。 システム開発のWhatを決めるプロセスでは、作る対象に対する「正しい問い」の立てかたが求められます。
ところが一方で、要件は「解析的方法による解の導出と検証が不可能である」と言われています。すなわち、正解というものが無いなかで正しく問いを立てるということが、要件開発の本質のようです。 これまで、システム開発の仕事は、立てられた問いをHowの視点から定義し直すところからが長年の仕事の範疇でした。ところがCMMIでも要件開発がエンジニアリング領域に組み込まれたように、超上流はエンジニアの仕事となりつつあります。
例えば、社会の営みを理解し、シャーロック・ホームズのようにリバースエンジニアリングし、設計可能な対象としてモデル化すること。人の理解の仕方に沿って問題を整理し、利害関係者と共に問いを立てるセッションを取り仕切ること。これまでのエンジニアの仕事とは少々異なる構えが求められます。
しかし、巷にあふれる学習メソッドのように、様々なソフトウェア開発の方法論がありますが、超上流工程を工学的に体系立てているものはなかなか無いようです。本講演では、顧客価値(ユーザーエクスペリエンスとも呼ばれます)向上の観点から、超上流工程のプロセスと、そこで用いられる手法や観点についてミニ演習などを交えながらお話しできればと考えています。

「『シャーロック・ホームズのようにリバースエンジニアリングする』とはどういうこと?」と突っ込まれましたが、詳しくはセミナーにて(おそらく、忘れていなかったら説明すると思います)。

 

科学と宗教とプロセス改善と

「修証一如」
修行とさとりはひとつ(一如)である。

今年のSS(ソフトウェア・シンポジウム)2012は福井で行われた。SRAの岸田さんから、SSにあわせて頭脳警察のPantaさんのライブがあると聞き、ここ数年足が遠のいていたSSに久しぶりに顔を出した。

福井市は、福井の語源と言われている井戸を敷地内に持つ福井城を中心とする城下町であり、城下町特有のレイアウトを描いていた。

福乃井
福井城内にある井戸「福乃井」

 

自前の地理の疎さを図らずも露呈してしまうが、かの禅寺、永平寺がJR福井駅前からの直行バスで20分程度の距離にあることを、シンポジウムで配布された観光案内マップ上で発見。

今回のシンポジウムでは、プログラム委員長のニルソフトの伊藤さんのご尽力によって、永平寺の西田正法氏の特別ご講演を頂けるのであったが、その理由がやっと飲み込めた(という自分の勘の悪さを自省することもなく、特別講演をせっかく聞くのだから、まずは自分の目で永平寺とやらを研究してみないと、と自主ワークショップ開始… )。

永平寺は、観光客にも非常に厳しい(例えば、スカートの女性は見学お断りとか)という話を聞いたことがあり、クローズドな雰囲気かと思いきや、とても開放的で気持ちのよい気が充満しているお寺でした。

永平寺
永平寺は、檜の香りが印象的であった

 

閑話休題。
西田氏のお話し。

「修証一如」なのだそうである。つまり、修行が手段、さとりが目的ということではない。”修行すること自体が、すなわちさとりである”ということ。

悟りと修行とが同じであるという禅の構えは科学のアプローチと通じているなぁ、というのが、西田氏のご講演を聞いて印象に残ったこと。

「科学」は、科学者が捕まえようとしている真理を指しているのではない。真理を捕まえるそのプロセス自体こそが科学である。だって、Factは目の前に立ち現れるけど、Truthなんてものには到達できないんだから(弁証法というよりも、インディアナ・ジョーンズ博士の”Archaeology is the search for fact, not truth.”という台詞の方が印象深い)。

では、何故、科学者は到達できない真理に向かってそのプロセスを粛々と、というよりも確信を持って歩んでいる(歩める)のかというと、それは、”真理はすでに解かれていて、この宇宙に確かにある”という確信があるからである。その確信があるからこそ、科学者は安心して到達できないであろう真理を解くプロセスに自らを放り込める。そして誰によって真理が既に説かれているのかというと、この宇宙を創り出した”誰か”である。その意味で、科学は宗教の構造に通じるのである。

ところで、さらにもう一歩。

「家庭厳俊不容陸老従眞門入(かていげんしゅん、りくろうのしんもんよりいるをゆるさず)」
「鎖鑰放閑遮莫善財進一歩来(さやくほうかん、さもあらばあれ、ぜんざいのいっぽをすすめくるに)」
これは、永平寺の山門の左右の聯に書かれている言葉。

名誉も財産も何でも意のまま自由にすることが出来た陸老においても、出家せずものは、門をくぐれないという意味(だそうです)。ちなみに「出家」とは、名誉や利益をあげることを手放しているということだそうです(世の中の人すべてが出家すれば、世界は平和になると思いますよね)。

永平寺の山門
永平寺の山門を内側から見たところ(ここから入ってはダメという観光客用の小さな看板が置かれてあった)

この山門を結界として寺の中入ると、そこでは、修行とさとりがひとつの場となっている。悟りはすでに開かれており(お釈迦様がすでに開いている)、修行という関わりによって生まれる変化そのものがさとりである。
つまり、”活動による差異そのものがさとりとなるには、さとりがすでに開かれている場に入ることが必要”という構造。これは、真理が既に解かれている場(宇宙)にいるからこそ、解くプロセスに自らを放り込むことができるという科学の構造と同じですね。

これを組織にあてはめてみると、改善や改革が成功するためには、すでに改善や改革が成功していなければならないということ。つまり、改善や改革が成功するための唯一の条件は、すでに改善や改革が成功しているとことというのが、隠された真理のような気がしました。

『説明しなければ分からないということは、説明しても分からないということだ。』(村上春樹, 1Q84, 第2巻, p181)

 

タスク視点と成果物視点

業務システムや開発プロセスを設計し、管理し、改善するためには、プロセスを外在化、すなわち、モデル化する必要がある。以下は、プロセスをモデル化する際の視点の話し。

プロセスをモデル化する際に、人はなぜタスクの視点で描こうとするのであろうか。それは、プロセスを認識する場合、タスクの観点が人間にとっては自然である(慣れている人が多い)からである。

例えば、工場の生産ラインを記述する際、たいていの場合に目が行くのはラインを構成する機械である。生産ラインが「Aをする機械」、「Bをする機械」、「Cをする機械」… によって構成されていると認識した場合、生産ラインを”A→B→C…”の機械の並びとして描くことが自然であると感じる。しかし、生産ラインを設計する際のプロセスの本質はそれぞれの機械ではない。

このようなタスク視点に対して、製造ライン上でどのような中間成果物を作り、管理して最終製品に仕上げるかという、成果物視点による実体の構成こそが生産ライン設計の本質的な視点なのである。

作ろうとする成果物に対して、それを一度に作れない場合、段階を経て作ることになる。その際に、どのような段階に分けるかは、本質的には製造する機械によって決まるのではなく、作ろうとする製品の制約、品質管理上の確認ポイント、そして製造リスクの管理の視点から適切なプロセスが設計される。そして、ラインを構成する機械は、設計したプロセスを実現するために、プロセスからの要件と相互作用的に適用する技術が定義、もしくは開発されるのである。

このように、プロセスを設計するためにモデル化する場合には、成果物の視点からプロセスを描く必要がある。描いた業務プロセスモデルがシステム仕様の記述となってしまうのは、タスク志向でプロセスを描くことによって、システムで行われる(行われるであろう)処理、すなわち、システムの仕様が業務プロセスの中に入りこんでしまうためであるとも思われる。

ちなみに、ワークフローという言葉で用いられるときの「ワーク」の語源は、「作業」という意味ではなく、生産ラインの途中に現れる「仕掛品」、すなわち、中間成果物を意味している。つまり、ワークフローという言葉が指し示すプロセスモデル自体、本来的に成果物視点なのである。