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が何を担うのかといった「つなぎ」「因果関係」の部分がすっぽり抜け落ちている場合が多い。結果として満足度の低いシステムが生み出されているのではないか、という問題意識が生まれた」（若杉氏）。（次ページへ続く）
部門間の合意形成を体系的に進める道具
ただし、ビジネスのゴールとシステムの要件を繋ぐことは容易ではない。ビジネス上のゴールは経営層が決断すれば良いし、システムの構築はIT部門がイニシアチブを握ることができる。しかし、業務ルールの策定は、営業、経理・財務、生産など複数の部門同士でコンセンサスを取らなければならない。しかも、それらは責任の所在や仕様が不明確になりやすい。しかし、不明瞭なままプロジェクトが進んでしまうと、いざシステム構築の段階に入って手戻りが頻発したり、できあがったシステムに誰も見向きもしない完全な失敗プロジェクトになり果てたり、という事態になりかねない。
スムーズにプロジェクトを遂行するには、上流工程の意思決定を体系化し、失敗の芽を早期に摘み取っておかなくてはならない。体系化された手法で進めていれば、万が一、構築の途中で手戻りが発生しても、部門間の調整において何をすればいいのかが明確なので、短時間でリカバリできる。
SI ベンダ側がユーザー企業の経営層、業務部門、IT部門で協議する要件定義をサポートする意義もここにある。上流工程で参画していれば客観的にプロジェクト全体を見ながらサポートすることも可能となるからだ。
ユーザーの人材支援にも役立つ「Tri-shaping」研修サービス
ユーザーのビジネス価値向上に対してITが関わるという意味では、フレームワークBABOKと類似していると感じた方も多いかもしれない。「BABOKは網羅性に優れた知識のフレームワーク。Trishapingはその骨格を踏襲しつつ、実際のプロジェクト遂行に利用できるよう実践性を加味したツールと捉えるとわかりやすい」（若杉氏）。
例えば、「要求を明確にすべき」と示唆するのがBABOKだとすれば、プロジェクトの各チェックポイントで利用すべき「要件の成熟度の評価ポイント」を具体的にまとめたのがTri-shapingだ。要求形成手法、業務形成手法、業務仕様形成手法と進む過程で、その時々でどの項目で満足しておくべきか、どのような条件を満たせば、次のプロセスに進んでも問題ないか、といった点が明確化されている。具体性を備えたツールのガイドによって、経験の少ないプロジェクトマネジャーでも混乱することなく、要件定義を進めていくことができる仕組みだ。
当初は、富士通の要件定義手法として設定したTri-shaping だが、ユーザー企業側から自社のITスタッフのレベルアップに役立てたいという問い合わせが多かったため、研修サービスも新たに設定した。経営視点で業務プロセスを変える、あるいは、業務視点でITを変える人材が求められて久しい。富士通の新しい要件定義手法は、ビジネスを支える基盤としてのITシステムを実現するものになるかもしれない。
