イベントウォッチ:要求開発サミット 「使えないシステム」がなくならない理由

「使えないシステム」になるのを避けようとユーザーへのヒアリングに重きを置いていると、かえって泥沼にはまる恐れがある。要求開発アライアンスが考える要求開発のあるべき姿とは

» 2005年04月27日 12時00分 公開
[西尾泰三,@IT]

本稿はITmedia エンタープライズに掲載された記事を転載したものです。


 「業務の効率化をどのように進めればよいか」──この問題はどの企業にとっても悩ましい問題の1つだ。「使えないシステム」を生み出すまいと必死にユーザーから要求を聞き出していると、かえって泥沼にはまる恐れがある。

講演に集中した結果コップの水をこぼす一幕もあった萩本氏 講演に集中した結果コップの水をこぼす一幕もあった萩本氏

 こうした問題を解決するために設立された要求開発アライアンス(ReDA:Requirement Development Alliance)が3月に開催した「要求開発サミット」では、同アライアンスが掲げる要求開発手法「Openthology(オープントロジー)」のコンセプトと特徴について、豆蔵の取締役で同アライアンス設立準備委員でもある萩本順三氏が解説した。



要求はどこにある?

 「Openthology」というのは、ReDAが掲げる標準的な要求開発方法論「Open Enterprise Methodology」を組み合わせた造語である。Openthologyは、「いつ何をなすべきか」(プロセス)、「誰が何をすべきか」(役割)、「何を作成すべきか」(成果物)を明確に定義することで、業務の可視化と業務改革を成し遂げるための「地図」として機能するものだといえる。 「地図がなくても目的地に着けるかもしれないが、あれば効果的に歩を進めることができる」(萩本氏)。

 近年、どの企業も業務の効率化は大事であると考えている。しかし、どんなシステムを作れば業務が効率化するのかが把握できていないことが多い。結果、思いつきとしか思えないような機能が実装されたり、ビジネス全体を理解せず、全体最適ではなくサブシステムだけの範囲で部分最適化を図った、「使わない機能を備えた使わないシステム」が誕生する。これでは業務の効率化はおろか、満足のゆく投資効果など得られるはずがない。

 システム要求を決めるプロセスというのは本来なら、業務管理者、業務担当者、システム開発者といった利害関係者間で対象としている業務を正確に把握し、その中で可視化された問題をしっかりととらえ、それを改善していくというプロセスで進むのが理想的である。しかし、現実的には、3者間で問題が共通に認識されることは珍しい。そのため、意見はまとまらず、多くの例外的な要求を含んだままシステム要求として挙げられることになる。もしくは、業務担当者とシステム開発者だけで話を進めてしまい、レアケースのシステムを生んでしまうこともある。要求開発時に合意がしっかりと行われていないことが原因であるが、詰められていない要求は結局使われないし、そのような要求に対してユースケースを作っていても意味がない。

 満足のいく投資効果を得るには、属人的、場当たり的な要求を作ってしまうのではなく、ビジネス上の要求(ビジネス要求)を基に、業務の設計、あるいは再設計を行う中で、情報システムが担うべき要求(システム要求)を導き、定義していく必要がある。つまり、要求は最初から存在していて、それを分析すればユーザー要求が見えてくるというものではなく、業務からロジカルに導いてはじめて、それが開発者に受け渡され、システム化されたときに業務が全体で最適化される、というのがReDAの根幹となる考えである。そのためのプロセスと管理方法がOpenthologyとして提供されている。

技術・技法とは何が異なる?

 では、OpenthologyはEA(Enterprise Architecture)や復型開発方法論である「Rational Unified Process(RUP)」などの技術・技法とは何が違うのか。萩本氏はこの点についても触れている。

 EAで最も有名なものとして、1999年に米国で策定された連邦政府のEAである「FEAF」(Federal Enterprise Architecture Framework)があるが、この中でEAは次の4つの要素に分割され、定義されている。

【関連記事】
▼【2004年 押さえておくべきキーワード:「EA」〜企業システム構築におけるEAの効用】トレンド解説(@IT情報マネジメント > 企業システム構築)

  • 政策・業務体系(Business Architecture)
  • データ体系(Data Architecture)
  • 適用処理体系(Application Architecture)
  • 技術体系(Technology Architecture)

 萩本氏はEAとの関連について、「Openthologyは、EAにおけるビジネスアーキテクチャとアプリケーションアーキテクチャをつなげる手法と考えるとよい」と話している。加えて、ビジネスアーキテクチャ以外の部分を構築するための実践的な手法としても機能するものになるという。

 RUPとの違いについては、企業レベルでビジネスのプロセスとモデルを形成するという点で、1プロジェクトの中でビジネスモデリングを行うRUPと異なるという。つまり、既にデザインされたものの中でビジネスモデリングをするものではないという点が違うといえる。このことは、RUPがOpenthologyの後方行程に適合可能なプロセスであるともいえるので、Openthologyがこれまでの技術・技法とまったく異なるものであるというわけではない。

 Openthologyでは要求開発が成功するための秘策として次の5つを掲げ、要求開発の重要性を参加者に説いた。

  • プロセスをカスタマイズせよ
  • チーム作りを重視せよ
  • モデルの価値を証明せよ
  • 仮説検証型により要求開発計画を立てよ
  • ゴールに最短距離で導くためのストーリーをイメージせよ

 「業務モデルを書いても、その価値を証明できない、つまり理解していなければそれは魂が入っていないものになってしまう」(萩本氏)。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ