最善を尽くしたにもかかわらず、やっと稼働したシステムに対し業務部門は不満を抱くばかり――。こうした状況を引き起こす原因を“あいまいな要求定義”に求めて久しい。だが、要求定義のためのテクニックを身に付けただけでは、状況は一変しない。「何のためにシステムを作るのか」といった根本的なゴールを不明確なままに要求定義を急ぐからだ。業務部門とIT部門が一体になり、ゴールを明確にし、かつ共有するための体制作りがますます重要になってきた。
本記事は日経コンピュータ1月22日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集2」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバーをご利用ください。
中堅損保会社の日新火災海上保険は2006年11月、契約内容を顧客に説明するための資料を作成する「ご契約内容確認マップ」システムを稼働させた。保険商品の内容が複雑になるなかで、契約時の顧客への説明責任をどう果たすかという経営課題を解決するための期待のシステムだ。
釜中貞彦 情報システム部長は新システムを、「稼働直後から営業部門の満足度は高い。納期も予算も予定通りで、情報システム部門としても納得のいく結果になった」と評価する。
日新火災にとって、ご契約内容確認マップの構築は、プロジェクト体制面でも同社初の取り組みだ。06年1月から、システム開発の全工程を対象にした行動規範やレビュー方法を明記した規定集の策定に着手。同8月に全社には「システム開発・改訂に関する規定集」を配布した。同プロジェクトで、この規定集を初めて適用した。
これまで日新火災は、要求定義は業務部門が担当し、情報システム部門が開発するという分業体制を採ってきた。だが、業務部門が作成する要求定義の中身はおおまかなレベルで、「あとは情報システム部門に任せておけば狙い通りのものができるだろうという風潮だった」（釜中部長）。
規定集では、要求内容については業務部門に全面的な責任があることを明記。企画段階における業務部門の責務を示した「前文第5条」では、「関係各グループ、課と打ち合わせを行わねばならない」とした。釜中部長は、「これまでは、システム化によって『何をしたいのか』に無頓着すぎた。システム構築プロジェクトにおいても、ゴール（目的）の共有は不可欠だ」と強調する。
経営だけでも現場だけでも進まない
従来、“あいまいな要求定義”から抜け出すには、「UML（統一モデリング言語）など種々のモデリング手法の活用が不可欠だ」と指摘されることが多かった。しかし、日新火災を例に取れば、手法の導入よりも、業務部門と情報システム部門の関係見直しを先行することで、“あいまいな要求定義”からの脱却に筋道を付けている。
その背景を、要求定義のコンサルティングを手掛ける豆蔵の萩本順三取締役は、「システム化の本当の目的を決め切れていないことが、より大きな課題だと気付き始めたためだ」と説明する。
現場におけるITを使った業務改革で成果を上げてきたリコーの松崎豊IT/S本部副本部長も、「『何のために』を明確にすることがますます重要になってきている」と言う。「既存業務を置き換えるような単体システムを構築する時代は終わった。今求められているのは、システムの連携や統合により経営改革を実現するための仕組み。経営ビジョンだけ、現場のニーズだけでは、その解は見つけられない」からだ。
加えて最近は、じっくりとシステムを構築している余裕はない。ローソンのCIO（最高情報責任者）である長谷川進常務執行役員によれば、「ビジネスの環境変化は激しくなる一方。システム構築は、企画からカットオーバーまで5カ月以内が前提だ」。
 |
| 図1●不十分な要求定義の改善に動き始めたユーザー企業の取り組み例 |
ユーザー企業が作成してきた要求定義が“あいまい”なことは、もはや疑念の余地はない。日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2006」では、発注者の反省点として「仕様の定義が不十分」との回答が44 ％、「要求仕様を明確に提示しない」が22％もある（図1の上）。その要求仕様書にしても、「ITベンダーが作成している」とする企業が8割に上る。
こうした状況に危機感を抱いた経済産業省は、ソフトウエアの開発プロセスの体系である「SLCP（ソフトウエア・ライフサイクル・プロセス）」を07年3月末に改訂する。その中で、要求定義につながる「企画」工程と、「業務詳細設計」の工程は、ユーザー企業の責任であることを明記する考えだ。
同時期に、ユーザー企業とITベンダーとのシステム開発契約のガイドラインである「モデル契約書」も見直す。そこでは、企画と業務詳細設計における契約は、「準委任型」（業務の代行）にすることを求める。実作業はITベンダーに頼らざる得ないとしても、システム化要求の責任はユーザーにあることを改めて意識付けるのが目的だ。
役割変わる情報システム部門
ユーザー企業も当然、手をこまぬいているわけではない。冒頭の日新火災の情報システム部門のように、要求定義におけるユーザー責任を果たすため、社内体制の見直しを図るユーザー企業が増えてきた（図1の下）。
先行企業への取材からは、これからの要求定義に求められるポイントが、大きく二つ浮かび上がってきた。(1)要求定義書を作成するためのプロセスを“見える化”したうえで、業務部門と情報システム部門のそれぞれが果たす役割を定める、(2)業務部門にはできるだけ早いタイミングでシステムの利用環境を疑似体験させる、である。
続きは日経コンピュータ2007年1月22日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。
