2011年2月に富士通が発表した「Tri-shaping」は、SI における30年以上の要件定義経験のノウハウを再結集し、体系化した手法だ。Tri-shapingを担当するシステム生産技術本部長代理の若杉賢治氏は、類似の手法との差別化ポイントを「業務へのフォーカス」にあると説明する。
「開発プロジェクトの一部分にフォーカスした要件定義手法はこれまでも存在してきたが、『そもそもこのシステム構築によってどんなビジネス上の価値を高めるのか』という根源的な問いに踏み込んでいるものは少ない」（若杉氏）。
一口にビジネス上の価値に結びつくよう要求をまとめると言っても決して容易なことではない。なぜなら、ビジネスに近くなればなるほど、技術論だけでは片付かないステークホルダー間の意見調整のような課題が現れるからだ。それらを解決し、的確なシステム要件にたどり付くために必要な手法を、Tri-shapingは確立していると氏は言う。
まずは、その概要について見てみよう。Tri-shapingは、文字通り3つの形成手法からなる。すなわち、（1）要求形成手法「shapingBR（shaping Business Requirements）」、（2）業務形成手法「shapingBP（shaping Business Process）、（3）業務仕様形成手法「shapingBS（shaping Business Specifications）」だ（図）。
それぞれ、経営・業務に真に貢献する要求を立案・決定し（要求形成）、それを実現するためのシンプルで柔軟な業務プロセスを分析・設計し（業務形成）、ヌケモレ・曖昧さを低減した業務ルールに落とし込む（業務仕様形成）ことを目的としている。
従来、業務プロセスの改善や、システム要件のとりまとめに主眼が置かれることが多かったのに対し、Tri-shapingはそこに至るまでの、より上位のプロセスにも焦点を当てている。ビジネス上の価値向上に資する目標を設定するためのプロセスや、それを業務ルールに的確に反映させるための分析・設計プロセスを、具体的なツールでサポートしている点が特徴だ。
なぜシステムへの不満が消えないのか
なぜ、富士通がビジネス要件にまで踏み込んだ要件定義手法を策定するに至ったのか。もともと、年間2 万件以上のSI 案件を手がける富士通にとって、ユーザー企業側の要件定義のサポートは重要な業務のひとつ。特に、上流工程の失敗は全体の採算を左右するため、各プロジェクトが終了する度に、社内でフィードバック会議を開き、これらの蓄積により手法を洗練させてきた。継続的な取り組みの結果、オープン化や要件の複雑化という時代の流れとは裏腹に、下流工程での手戻りの頻発といった一般的なトラブルでプロジェクトが失敗するケースは減少している。
代わって浮上してきたのが、当初の設計通りに構築できたとしても、満足できないケースがあるという事実だ。完成したシステムを利用するユーザーを対象とした調査によれば、「計画通りに（システムを）利用しているが不満足」という回答が全体の25％を超えたという。画面もロジックもユーザーの要求通りに構築したにもかかわらず、システムへの満足度が低い場合がある。
つまり、そもそも何のためにシステム化を行うのか、そのための手段としてどのように業務の仕組みを変えれば良いのか、そのためにはどのような手段が適切なのか、開発プロジェクトに至るまでの道のりが不明確なために、その後の過程がいかに丁寧に行われていようとも、最終的なアウトプットがユーザーの満足に結びついていないということだ。
「どのようにビジネスを変えたいのか、どんなことを実現したいのかといった経営層の考えるビジネスゴールや、どのような画面が欲しいかといった現場の詳細な要望レベルは、要件定義書にだいたい書かれている。しかし、ビジネスゴールを実現するために、業務をどのように変えるのか、そしてそのためにITが何を担うのかといった「つなぎ」「因果関係」の部分がすっぽり抜け落ちている場合が多い。結果として満足度の低いシステムが生み出されているのではないか、という問題意識が生まれた」（若杉氏）。（次ページへ続く）
