PR

 Openthologyは要求開発のガイドラインであり,企画段階であいまいな要求をシステム化に必要な具体的なレベルまで最短距離で導くための,ノウハウを提示している。

 ユーザーとの共同作業で要件定義を進める際,いかにしてユーザーの「業務の本質」を見抜くかは重要な課題である。今回は,「業務の本質」を理解するためのOpenthologyのノウハウの利用について考えてみたい。

 筆者はユーザー企業に常駐するSEである。システム開発に携わる中でシステムの利用者や利用部門の代表者と直接話をする機会が多く,要件定義を中心とした上流工程の作業が業務の大半を占める。

 打ち合わせの中でユーザーの話す内容を理解し,開発サイドにブレなく要求を伝えるためにはそれなりの業務知識が必要となる。もちろん,業務の専門家であるユーザーの担当者と私では,業務知識のレベルに大きなひらきがある。

 しかし,少なくとも,ユーザーと業務を検討するうえで意思疎通ができる程度の前提知識がなければ,ユーザーが望むシステムを構築するパートナーとはなり得ない。では,開発サイドが業務知識をもってさえいれば,プロジェクトはうまくいくのだろうか。

 ユーザーが開発サイドに求めるのは,自分たちにない技術(スキル)である。ここでの技術とは,システムそのものを構築するための実装技術はもちろん,インフラの設計やモデリングのノウハウ,開発プロジェクトの進ちょく管理や品質の確保など,システムをコーディネイトするのに必要な様々な技術のことである。

 我々開発サイドとしても,ユーザーが期待する技術を提供し,頼りがいのあるパートナーでありたいものである。

開発サイドの得意分野

 要求定義は,ユーザーと開発サイドが協力して行う作業である。作業を始める前に,次のような整理をしてみよう。お互いの知識について,図1のように分類し,開発サイドがとるべき手段を記述してみる。

図1●共有すべき知識の分類
図1●共有すべき知識の分類

 図に示した四つの領域について,(1)の領域については,双方の認識にずれがないかの確認を行う。(2)の領域は,業務に深くかかわる知識なので,必要に応じて教えを請う。(3)の領域は,前述のユーザーが開発サイドに求める知識やスキルなので役立てる。(4)の領域は,一緒に取り組む。

 というのが基本であるが,すべての知識を補完することが目的ではない。知識を共有するといっても,ビジネスやシステムのあるべき姿を検討するうえで必要なすり合わせにポイントを絞ることが重要となる。

 ここで,(3)の領域の知識やノウハウが役に立つと筆者は考える。例えば,課題の本質を見抜くための抽象化や,知識の体系化などは,開発サイドの得意分野である。

 ユーザーは日々の業務については大変詳しいが,その知識は自分が担当する業務領域に偏っている場合もよくある。業務に関して,その背景や全体像など広い領域について知識を持ち,様々な角度から体系的に自分の知識を語れる人はそうはいない。

 そこで,開発サイドが客観的な立場からユーザーの知恵と知識と経験をうまく引き出し,それらを体系化しながら,課題に取り組めば価値ある要求が開発できる。

知らないほうが有利な場合も

 そもそも業務について深く「知らない」ことが,ハンデではなくアドバンテージとなることもある。外から客観的に業務を見ることで,ユーザーからは見えにくい課題が顕在化したり,暗黙の了解といったタブーについて問題提起ができることもある。

 例えば,ユーザーは業務を変えることを好まない傾向があり,たとえそこに無駄があると気づいていてもあえて踏み込まない場合がある。「知らない」がゆえに,課題の本質をズバリ指摘できるということもあるだろう。

抽象化のスキルを役立てる

 次に,要求定義を効率的に進めるうえで,開発サイドの得意分野について知識やスキルを活かすことを考える。業務の本質を見抜き問題点を明らかにするために,ポイントとなるスキルは抽象化であると筆者は考える。

 開発サイドがユーザーと同じ視点で,業務の詳細に目を向け,局所的に問題を掘り下げると,課題の本質はなかなか見えてこない。では,どうすればよいのか。

 例えば,ユーザーへのヒアリング等で得られる情報を体系化し,客観的な視点で業務の全体像を把握する。そして,モデリングのノウハウを利用し,適度に抽象度を上げて,ビジネスを本質レベルで可視化する。

 課題の本質にポイントを絞って議論を行い,業務のあるべき姿を大枠で検討する。次に,システム化範囲やシステムのあるべき姿を大枠で検討し,段階的な詳細化により,システムの具体的な要件を検討していく。

 Openthologyでは,このようなアプローチで,要求開発を進めていく(図2)。そのための手順や具体的なモデリング手法も解説されている。また,このような視点の切り替えだけでなく,Openthologyには,「問題分析ツリー」など,現場の業務の問題を明らかにし,その解決策を導き出すためノウハウも紹介されている。

図2●抽象化による分析の流れ
図2●抽象化による分析の流れ

 次回は,Openthologyのノウハウを利用した具体的な課題分析の進め方と,そのポイントについて説明する。

(大浦 史仁=要求開発アライアンス 執行委員)