PR

 前回に引き続き,筆者がSEとして携わった様々な開発プロジェクトから,いくつかのエピソードを紹介する。「ビジネス上の要求をシステム開発の要求に結びつける際に,どのような問題が生じ得るのか」「要求開発によってそれをどのように解決できるのか」---。こうした点を,今後要求開発に携わる可能性のある方々,特に若いSEの方々に向けて述べてみたい。

利害関係者の間で早めに合意を図る

 製造業では適正な在庫を維持することは最重要課題である。ある家電メーカーのシステムを構築するに当たっての先方の要請は,「電池から大型テレビまで,全国レベルで在庫を圧縮すること」であった。筆者らは,製品の出荷時期までのタイムラグを正確にとらえ,仕掛品(しかかりひん:企業会計などで製造途中にある製品を指す)であっても「仮想の在庫」と見なすことで,問題を解決できるのではないかと考えた。しかし,話を聞いていくうちに,どうも引っかかる点が出てきた。それは,老舗販売店に対するサービス・レベルの維持という問題だった。

 経営陣や物流センターの方々ははっきり話してくれなかったのだが,営業部門や倉庫部門の方々は,老舗販売店にはそれぞれの製品を定められた個数の範囲内で,直ちに取り寄せられる「権利」があると言うのである。現状は工場から主要営業店に入荷後,その権利数を割り振り,場合によっては権利数の貸し借りまでして運用しているとのことであった。しかし,その権利数は,まさに圧縮しようとしている在庫数から割り当てている。そのため,新システムが仕掛品を「仮想の在庫」と見立てて在庫を圧縮してしまうと,老舗販売店からの要望には応えられないことになってしまう。在庫圧縮と老舗販売店へのサービスの維持のどちらを採るのか,二者択一の選択を迫られたのである。

 結局このプロジェクトでは,既に一部実装が始まった時期に,物流部門と販売部門の方々にお集まりいただいて解決策を協議した。結果的には仕掛品による仮想在庫にまで権利数を設定していくという大変更を加えることとなった。

 「そもそものビジネスの課題はどこにあるのか」「現状の問題がどこにあるのか」---。こうした点をシステム開発の前に利害関係者の間で早く明確な形で合意するための手順や手法があれば,このような問題はもっと早く「発見」されていたのではないだろうか。Openthologyのビジョン分析ツリーや問題分析ツリーでは,トップダウンとボトムアップの双方向から要求を整理していく。これを利用することで,利害関係者同士の要求が衝突することが早めに明らかになり,ある程度調和のとれた仕様に基づいて開発を進めることができるのである。

やるべきことをやるべき順番で進める

 開発に着手した時点では,混沌としてどこから手をつけるべきかすら明確でないこともある。数年前,とある銀行の基幹業務再構築プロジェクトが種々の事情で中止になったときのこと。途中までの仕様を利用して,ほかの金融機関への転用を図ることになった。売り込み先との営業的な折衝が続く中,開発メンバーが行ったのは機能の対比であった。つまり,これまで検討してきた仕様と新しい顧客の仕様を突き合わせ,相違点がどれくらいかを把握しようとしたのである。

 しかし,この「転用」には当初から無理があった。例えば,カードローンを併用している普通預金口座などで貸越(残高を超えた出金)が発生した後の入金の取り扱いを,普通預金への入金とみなすのか,貸越分の返済とみなすのか,という扱いが,金融機関によって全く逆だったりしたのだ。

 実は,この違いは単なる仕様の相違というレベルの話ではなかった。ベースとなった元の顧客は有名都銀であり,大企業を相手とした取引が中心であった。対して,新しい顧客は一般の企業や個人を対象とする取引が中心だったのだ。上記の例をはじめ,各種の仕様の違いは,そのことに起因していたのである。

 このようなケースでは,システムの仕様について個々の違いを調査する前に,まず顧客である金融機関が,預金者や融資先に対してどのようなサービスを提供しようとしているのか,という基本的な方針(「戦略」とも言えるだろう)を理解することが大切だ。そのうえで,捨てるべき機能や改修点を明確にし,スコープを限定すれば,作業の無駄は大きく省けるはずである。

 ときおり発注側である顧客は,今後の設計や開発の中心となる人材をつなぎ止めておこうとして,開発担当側に現行調査,現行解析を依頼することがある。開発側も受注した以上は何か成果物がないと請求しにくいため,とにかく手を動かしてしまう傾向がある。しかしシステム開発の前に,ビジネスの目指すところによって,どういう順番でどういう作業を行うべきか,つまり要求定義のプロセスが明確になっていれば,無駄なコストや労力を費やすことなく作業を進めることができる。Openthologyのプロセス・セルやプロセス・キャビネットは,混沌とした状況であっても意味のある作業を,どういう順番で行うべきかを提示してくれるだろう。


(佐々木 啓一=要求開発アライアンス)