PR

 前々回では,要求開発はユーザー企業のためのものであり,Opentyologyはユーザー企業の戦略やプロジェクトの目標を達成できる「本当に役に立つシステム」を構築するための,価値あるガイドラインであることを述べました。また,前回では,モデリングの目的とその価値について考えました。

 この記事を書く中で,私自身,「要求開発」という概念が必要とされる背景やその目的について考えるようになり,いろいろな「気づき」がありました。ここで,もう一度「要求開発は誰のためのもの?」というテーマについて考えてみようと思います。

 一つ,わかったことがあります。それは,要求開発はユーザー企業にとって価値のあるものであると同時に,プロジェクトに参加するSI企業にとっても価値のあるものだということです。

 「要求開発」というテーマと向き合ったことで,システム開発に取り組むSI企業にとって,お客さまであるユーザー企業の視点で考えることが非常に重要であると感じるようになりました。

 ユーザー企業から提示される要求(あるいは要望)には,多かれ少なかれあいまいな部分が存在します。ユーザー企業にとってのベストプラクティスを検討するには,システムの前提となるビジネス要求を理解し,あいまいな要求を明らかにし,お客様とともに,システムの「あるべき姿」を検討する必要があります。この際,お客さまが望んでいることの本質を理解できなければ,「本当に役に立つ」システムを構築することはできないと筆者は考えます。

 しかし,これはなかなか険しい道のりです。お客さまの要求には,見えやすいものと,掘り起こさないと見えてこないものがあるのを感じます。また,お客さまにとっては当たり前の要求が,SI企業の立場からは見えていないといった場合もよくあるからです。

 実は,筆者も経験があります。あるシステムについて機能追加を行う際,新規機能を利用するアクターを中心に業務を分析し,操作性を重視した設計を行ったところ,従来のユーザーが頻繁に利用する重要な機能の操作性が悪くなったというクレームを受けたことがあります。お客さまにとっては当たり前の要求が,開発サイドでは理解できていなかったのです。

Openthologyでは,ビジネス要求をその性質から次の3種類に分類します。

(1) 初期要求
  • 初めから企業ミッションの中に生息している,そもそも達成すべき最優先の要望や要求
  • 従来の業務課題の延長上,最初から見えている要求
  • 従来のシステムの中に存在しており,今後も重要視される要求
(2) 開発された要求
  • 業務分析,業務標準化,業務改善により始めて姿を見せる要求
  • トップダウンのビジネス戦略やボトムアップ的な業務課題に基づき,ToBeモデルを描いているうちに明確になってきた要望
(3) 暗黙知要求
  • 従来のシステムの中に存在しており,今後も必要とされるが,あまり注目されていない要求

 これらの視点から要求を整理し,あいまいな部分をモデリングにより「見える化」し,検討を進めると,ユーザー企業の要求の本質が見えてきます。例えば,前述の例は,暗黙知の要求を「見える化」し,共有しなかったことがトラブルの原因といえるでしょう。

 今回紹介したのは一例ですが,このようにOpenthologyには,システムのあるべき姿を検討するためのノウハウが詰まっています。

 SI企業が,ユーザー企業の視点からシステムの本来あるべき姿を検討するお手伝いをし,そしてユーザー企業と一緒に検討を進め,「本当に役に立つ」システムが構築できたなら,それは素晴らしいことです。

 要求開発は,広義のシステム開発にかかわるすべての人にとって価値のあるものだと言えるでしょう。

(中山 尚子=要求開発アライアンス)