PR

 前回は,要求仕様の不備がプロジェクトの後半における仕様変更の発生につながり,失敗プロジェクトにつながることを述べた。今回は,失敗プロジェクトにおける,仕様策定の進め方について問題点を分析し,解決のための方策について考えてみる。

従来の要件定義の進め方=そこに問題があった

 これまで行っていた要件定義の方法は,以下のようなものであった。

  • ユーザーに新システムの概要についてヒアリングする
  • 大まかな業務フローについて確認する
  • 機能一覧と機能仕様書を提示し,合意を得る

 実はユーザーは,この合意時点で,そのシステムを使用した業務の具体的なイメージまでは想像できていなかった。

  • この機能仕様で問題なく業務が流れるか
  • 想定される人的リソース(人数やスキル)で,想定時間内に業務が遂行できるか
  • そもそも自部門の目標達成に向けて,方向性が合っているのか

 これらは重要な観点であるが,要件定義時点では把握できておらず,問題がある場合には,動作確認や検収テストの段階で,実際に動く機能を目の前にして初めて顕在化する場合が多かった。

ユーザーサイドの事情=投資効果への責任,ラインからの突き上げ

 ユーザーのIT担当者は,業務変革という使命をおび,企画と予算獲得,ライン担当者の取りまとめといった役割を担っている。財務部門に費用対効果について説明を求められるし,新システムによる新しい業務の導入に際しては,ライン担当者からの風当たりも強いだろう。

 開発中に要求仕様(要件)の不備が発覚し,開発サイドへ要件変更を依頼することになったとすれば,財務部門に追加費用を認めてもらわなければならない。財務部門から費用の超過について糾弾され,場合によっては予算の追加が認められない場合もある。

 逆に,そのまま要件を変更しなければ,新システムによる業務が機能しないなど,ライン担当者から新システムの利用自体拒否される可能性もでてくる(それでなくても,既存の業務に習熟しているライン担当者にとっては,業務の変更そのものに抵抗を感じる場合が多いのだから)。

 このような板ばさみの状況から,なかば自衛手段のような理由で,「要件を最初から明確には決めない」という風潮が生まれていた。

開発サイドの問題意識=ユーザーが悪いのか?

 一方,開発サイドでは「業務仕様はユーザーの責任」「無理な仕様変更を要求するユーザーが良くない」「自分たちの責任範囲は,与えられた要件に基づき正しく動作するシステムを提供するまで」と考えていた。

 ユーザーの知恵と知識と経験をうまく引き出すための努力や,仕様策定の方法に問題があるとの意識はなく,その結果,状況が改善されることはなかった。最終的には,使われないシステムができあがったり,納期やコストが超過した失敗プロジェクトにつながったりと,悲しい結果につながってしまう。

 ユーザーの責任といってしまえばそれまでだが,このままではお互いに不利益な関係になってしまうことが懸念された。

解決に向けて=WIN-WINの関係構築のために

 この状況を打開するには,最初の要求仕様(要件)の精度を上げるしかないと筆者は考えた。しかし,プロジェクト初期の段階で仕様を詳細なレベルまで強引に決定し,厳格な要求管理によって仕様変更を抑えるだけでは問題の解決にはならない。

 プロジェクト収支は守れたとしても,使われないシステムが出来あがり,顧客満足度が落ちては意味がないからだ。ユーザーとWIN-WINの関係を構築するためには,業務目的に合致した,正しいシステム要件をプロジェクトの早い段階から定義し,不必要な仕様変更を元から抑える必要がある。

 システムを業務の一部として捉え,開発サイドとユーザーサイドの双方が参画して,その目的を達成する仕組みを互いに協力しながら定義しなければならないと考えた。

 最上位の方針となる経営戦略,IT戦略をベースに,BSC(balanced scorecard)やKPIの手法によって,ビジネス価値に基づいた「業務システム」を定義する。これを可視性が高く,実際の業務をリアルにイメージできるドキュメント(システムの使用イメージを含んだ業務フローや,ユーザー・インタフェースのモックアップなど)を使用して,開発サイドとユーザーが共通の認識を基に,協力して仕様を検討する。

 実際に動くシステムができあがる前に,考え方の相違や,業務の現実性を阻害する要因を顕在化させ,早期に対応する。以上のことが重要と考えたのである。

 これを確実に実行すれば,ユーザーは,以下のメリットを得ることができるはずである。

  • 経営戦略,IT戦略から導かれる“あるべき姿”を元に,「業務システム」の目的が定義され,その目的に適うシステムが開発される
  • 経営戦略とシステム要件との間のトレーサビリティが確保される
  • 業務のKPIに基づき「業務システム」が定義され,新システムの導入効果が生み出される仕組みが明確になる
  • 初期の段階から新システムを使用したリアルな業務イメージを持つことができ,問題があれば早期に発見できる
  • 業務価値の観点から要件が定義されるため,稼動後のシステム導入効果が検証できる
  • 導入効果が出ないなど,もし何かが間違っていたら,どこが間違っていたかを検証できる

 開発サイドにとっても,以下のメリットがある。

  • 経営戦略とシステム要件との間にトレーサビリティが確保されるため,仕様の優先順位が明らかになる
  • 目的が明確化するため,効果の薄い仕様変更要求が低減される

 結果としてプロジェクトの成功率も高まり,顧客とのWIN-WINの関係構築につながるはずである。

実現するためには=しっかりした根拠が必要

 ただし,これを実行するためには,システム開発を実施する前に,ユーザーと開発サイドが協力して,要求に対する十分な検討を行う必要がある。ユーザーにとっては従来よりもリードタイムが長くなり,コスト高の印象を受けることもあるだろう。

 まずは開発サイドが,ユーザーの担当者になぜそれが必要か,どのような効果が期待できるのかを説明し,理解してもらう必要がある。そのうえで,ユーザーから社内に対して効果を説明し,期間と費用の了承を得てもらわなければならない。

 ユーザーの理解を得るためには,効果についての具体的な根拠を示す必要がある。それには,しっかりとした方法論とプロセス,実績といった目に見えるものも提示したい。

 筆者が要求開発アライアンスに参加したのはそのためである。要求開発アライアンスには筆者同様,システム開発の上流段階の仕様策定について考える人々が集っている。要求開発方法論“Openthology”があり,それを実践している有識者・先駆者がいる。

 Openthologyには,正しい要求を定義するための手順,役割,成果物が定義されており,これを利用して仕事の質を高めることができる。また,自身の経験や意見をフィードバックすることによって,方法論自体も洗練されてゆく。

 方法論は実践しなければ意味がない。要求開発の現場で試行錯誤を繰り返すことによって,共に成長することができるのである。

(後藤 拓郎=要求開発アライアンス 執行委員)