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

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

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

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

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

現在、多くのソフトウェア開発の組織では、効率や品質向上のため、そして納期を守るために、“プロセス”の改善に着目した取り組みが行われています。
すでにプロセス改善に取り組んでいる組織にとっては、効率、品質、納期、すなわち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でも要件開発がエンジニアリング領域に組み込まれたように、超上流はエンジニアの仕事となりつつあります。
例えば、社会の営みを理解し、シャーロック・ホームズのようにリバースエンジニアリングし、設計可能な対象としてモデル化すること。人の理解の仕方に沿って問題を整理し、利害関係者と共に問いを立てるセッションを取り仕切ること。これまでのエンジニアの仕事とは少々異なる構えが求められます。
しかし、巷にあふれる学習メソッドのように、様々なソフトウェア開発の方法論がありますが、超上流工程を工学的に体系立てているものはなかなか無いようです。本講演では、顧客価値(ユーザーエクスペリエンスとも呼ばれます)向上の観点から、超上流工程のプロセスと、そこで用いられる手法や観点についてミニ演習などを交えながらお話しできればと考えています。

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