PR

 前回は,「使われないシステム」が出来上がる原因が要求定義にあると考えていた折に,要求開発方法論Openthologyに出会い,筆者の悩みを解決する大きな助けとなったことを述べた。今回は,Openthologyを実際のプロジェクトに適用する際のヒントをいくつか紹介したい。

 システム開発に取り掛かる前段階としての要求定義では,様々な問題が発生する。筆者がこれまで携わったプロジェクトでも,「システム化する部分ばかりに目がいって,ビジネス上のゴールまできちんと詳細化できない」「要求仕様が膨れ上がってまとめきれず,時間切れになる」といったケースがあった。問題を簡単にまとめると,以下の2つになるだろう。

(1)要求を検討する際の目的とゴールが明確になっていない。
(2)本来議論すべき対象が可視化できておらず,議論が発散する。

 こうした問題を解決するために,筆者は身近なプロジェクトにOpenthologyの概念を適用している。中でも特に重要なのが,Openthology Ver1.0の特徴である,PDCAと段階的詳細化だ。

 OpenthologyにおけるPDCAのP(Plan)は 単なる計画ではない。達成すべきゴールの設定と,そのための計画策定である。例えば検討を始める前に,検討の目的とゴール,そのために実施する項目,成果物作成の期日とレビューの日時,評価の基準を明確にする。

 ユーザーと検討する際も,いきなり画面や帳票レベルの詳細に入ってはいけない。ビジネスの全体像を大枠で提示し,ビジネスにおけるシステムの対象領域を明確にしたうえで,徐々に詳細を検討するといった段階的詳細化を心がける。そして,その結果をPDCAのC(Check)で集中検討・チェックすることで,「使える」ことを検証し,誤りを訂正するのである。

 この際のポイントとしては,「システムが実現すること」だけをレビューするのではなく,「このシステムを導入することでビジネスがどうなるか」までレビューすることである。このような工夫で,ユーザーと要求仕様を決める作業が随分効率良く実施できるようになったと実感している。

 もちろん,プロジェクトの進め方やコストの問題,ITベンダーとユーザー企業の関係の問題(要求仕様の確定はユーザー企業のシステム部門の責務であるといった議論)があるため,一概にすべてのプロジェクトに適用できるものではない。しかし,ITベンダーの開発担当者としては,こうした開発方法論を理解し,活用することが,「使われないシステム」を作らないために大きな助けになると筆者は感じている。

全面的に適用しなくてもかまわない

 現実のプロジェクトでは,社内で定められた方法論や標準化ルール,顧客との合意事項などがあるために,簡単には進め方を変更できないことが多い。開発方法論やOpenthologyに興味があっても,プロジェクトへ全面的に適用するのは非常に難しいと言える。実のところ,筆者も自分のプロジェクトへ全面的に適用したことはない。

 しかし,Openthologyは全体でしか活用できない方法論ではなく,「つまみ食い」が可能である。しかも,おいしいノウハウが無償で提供されているのである。Openthologyを使うことを高らかに宣言せずとも,さりげなく(こっそりと)Openthologyの興味あるノウハウをプロジェクトに適用すればよい。うまくすればプロジェクトが成功し,自分の評価も上がる。筆者も最初はそんな形で利用したクチである。

 ちなみに要求開発アライアンスには,エンドユーザーからシステム開発者まで様々な立場の方々が会員として参加し,定例の勉強会やML(メーリング・リスト)で日夜熱い議論を交わしている。筆者がたまに使う手として,この勉強会やMLに(こっそりと)自分の悩んでいる問題や疑問をぶつけることによって,プロジェクトの問題を解決するというテクニックもある。コストがほとんどかからないうえ,運が良ければ「ビジネス・モデリングの分野をけん引する巨匠」にアドバイスをもらえたりする。何ともお徳な話ではないだろうか。

 というわけで,興味(またはシタゴコロ)のある方は,ぜひとも一緒に開発方法論の普及活動にご参加願います。まずはOpenthologyの公式サイトを訪れてみてください。

(石沢 健人=要求開発アライアンス執行委員)