BA BLOG

要件定義力を徹底的に再構築する:⑤要件定義を簡単にしていく。すなわち、「要件」自体を再「定義」し細分化する(2/2)

要件定義を簡単にしていく。すなわち、「要件」自体を再「定義」し細分化する(2/2)

要件定義は3つのフェーズに分けてもらった方がいい。

まずは、構想。予備検討と言ったり、基礎検討と言ったり、要件定義に入るまでに事前にプロジェクトの概要や目的、大まかな予算感を定めることを取り入れている企業は多いと思う。それはそれで大切なのであるが、ここで構想と言っているのは、その予備検討よりかは少し業務要件よりである。要は、業務要件部分を分けて前倒しでやって欲しいのだ。業務フローを調べ、どのような業務フローになるのか、予め定めて欲しいのである。要は、きちんとした効果が出るのだ。
この効果というのがミソで、システム化というのは詰まるところ費用対効果があるものをやっていくべきなのであるが、費用の上限を決める行為なのだ。目的は効果の明確化なので、完全な網羅性はいらない。むしろ、どれくらいインパクトのある改革をするか、そこを決めてもらうことの方が重要である。要は、システム単位の費用対効果を定める一番の行為だ。言い方を変えると、費用対効果は最後に考えるのではなく、先に考えてもらい上限を定めてもらえばいいと思う。
コンサルタントが中長期の改革構想を立てたり、将来のITビジョンなどを立てるとことがあるが、その時にやってもらった方がいいのが、この構想だ。コンサルタントはそれなりに上手く長期構想を立案しやろうということになるのだが、実際にそこからやろうとすると、システム一つ一つを考える必要がある。こういう際は特に、業務一つ一つに落とし込み、費用対効果を本格的に検討してもらいたい。

次が要件定義。ここは、言うまでもないであろう。業務を網羅的にきちんと設計し、システム機能を定義し、データを見極める。そして、業務量、サイクルを踏まえてインフラを整理する。通常の要件定義だ。しかし、構想段階ですでに核となる業務についてはある程度見極めている。大切になるのは、網羅性と具体性だ。
網羅性は簡単である。スコープをしっかりと定め、抜けもれなく業務をリストアップし、定義しきることだ。開発段階で、あれもこれもというのは良くある話で、それを極力抑えることになる。また、業務のリストを作ることも重要だ。業務要件定義が上手くいかない企業は兎角業務のリストが出来上がっていない。「どれだけやればいいんですか?」という一番初めに答えたい問いに答えられないのだ。
余談であるが、業務要件定義の最も重要な成果物は一般的に業務フローであるが、筆者は業務フローを端折ることを時と場合によっては推奨する。理由は、工数の節約のためである。業務フローを書くという能力は、昔はコンサルタントがコンサルタントたるゆえんの能力であったが、今は随分一般化し、多くの人が記述できるようになった。しかし、フローは図で表現するためわかりやすいのであるが、作成工数が膨大となりやすく、要件が変わったときのメンテナビリティが悪い。だから、筆者はしばしば「ファンクションチャート」で代用することを推奨している。業務フローの代わりに、業務を樹形図で整理しきってしまうのだ。これは、業務のリストアップと業務要件定義、システム機能やデータの定義が一覧で可能となるので、抜け・漏れが潰しやすい。また、作るべき成果物を減らすことが出来る。節約が可能となるのだ。節約できれば、網羅性も考えやすい。是非、参考にしていただきたい。
では、具体性について考えていこう。筆者は、ユーザーにとって理解できる要件とは、どこまで言っても「画面」と「帳票」だと思っている。また、アプリケーションはどこまでいっても、データをCRUDである。システム化の画面がHTML形式になり一つの画面の中に数多くの機能を加えることができるようになるなど、機能の単位が変わりつつある。また、そうした機能の変化に応じて、見積もりの手法が変わることもおきている。だから、機能をコミットするのをやめてユーザーになるべく画面で議論をさせないというベンダーが相当いるのも事実だ。しかし、ユーザーはやっぱりシステムを画面と帳票で考える。そこで初めて自分がやりたいことを本当に要望として挙げることができる。
要件定義とは、コストを正確に把握するためにやる。そういう意味で、要件が抜けたり、間違っていることは極力避けなければならない。だから、なるべくユーザーの要望に沿わなければならない。そのための一番のイメージは、画面と帳票で議論することだ。決してその通り作れというものではないが、基本設計以降で爆発するプロジェクトは概ね、この画面での確認ができておらず、イメージがわいたときにあれもこれもと出てくる場合だ。多くの場合、このデータを表示して欲しい、というケースと、このパターンはどう処理するのか?という取引や処理パターンで膨らんでいくのだが、そうしたことを整理しようと言っても、このパターンが分かり切っている人は極めて優秀な人で、そもそもそれが分かり切っている人がいないから困っていることが多い。要件定義段階で、こうした埋もれやすい要求を洗い出しておきたい。そのためには、しんどいが要件定義で画面を議論しておきたい。

最後。ベンダー選定である。構想を分けている企業は、多かれ少なかれあることは上述した。企画とでも言おうか。しかしながら、ベンダー選定を要件定義から分離している企業は実は少ない。グローバルスタンダード的には、情報システム部門の業務には、「Sourcing」という調達業務を分離するようになっている。当然と言えば当然なのだが、委託金額が非常に大きく、ベンダー選定が成功を大きく左右することになるため、調達を専門業務として運営し、ノウハウを確立していくことは望ましい。日本の製造業には必ず調達部門があるが、ベンダーとパートナーシップを作りながら効率化を図ることは片手間でできるものではない。
ベンダー選定は、RFPを書いて、提案受理のための質疑応答に答えながら、提案を受理し、価格交渉と契約交渉を行い、次の体制を整え意思決定を行う。当たり前に考えて、これだけで数か月かかる業務であり、ユーザー企業にとってはある意味ハイライトであるし、ベンダーが最も生き生きと働く。また、様々なものがうごめき、刻々と状況が変わる、極めてエキサイティングなフェーズである。こういう言い方をするのもなんだが、経営やユーザーが本当に何を考えているか、本性が現れるフェーズである。また、進めるプロジェクトマネジャーにとっても、情熱、本気度、政治力といったウェットな部分が問われる。
ベンダー選定というものは、特別なスキルはほとんどいらない。必要なものは、RFPの書き方を後々の分析や価格交渉、契約交渉に都合がいいように提案をもらえるように指定することである。それ以外は、熱意をもって良い選定をしようと取り組めば、選定の基礎資料は確実にできるし、基本的に良い選定にたどり着く。
あるといいのは、ビジネスセンスだ。ベンダーはこの仕事を取りたがっているのか?そもそも、相場はどれくらいと考えらえるか?価格はどれくらいで折り合いをつけるか?自社とベンダー、交渉上の上手にいるのはどちらか?外部のベンダーのやる気を引き出すことはできるか?社内の誰が、どのベンダーを支持しているか?どういう条件があれば折れることができるか?筆者は、政治にかかわったことがないので、何とも言い難いのであるが、昔ながらの政治家はこうした業者や役所、政治家内の利害関係を調整したのであろう。まさにこうした利害関係の調整力がものを言う。そういう類の仕事である。
スキルはいらないといったものの、ベンダー選定は非常に難易度が高い仕事である。政治家という職業があらゆる職業の上位に君臨するように、ベンダー選定をやる人は本来的にもっとも上位の政治的能力をもった人があたるべき仕事である。大切なことは、そういう能力を「専門」能力としていくこだ。ベンダーのやりたいことは、ベンダー内の政策や業績状況で刻々と変わる。社内の力学も同様に、刻々と変わる。こうしたことを、久しぶりにとか、初めてやるような人にはなかなかできるものではない。ベンダー選定をサポートする能力は、特別専門職としてとらえ、あらゆる案件に携わるような専門職を内部に持っておくことが好ましい。

まとめると、要件定義を簡単にする方法の一つは、要件定義を3つに分けて、一つ一つのフェーズの難易度を簡単にしていくことである。小さな仕事であれば成果を出しやすくなる。だから、そうする。人材育成の基本中の基本に、達成感を味合わせる、できる範囲で仕事を渡すという方法があるが、同様のアプローチである。本当に要件定義とは難しいのだ。だから、分けられるポイントで分け、一つ一つをきちんと進めるようにする。一丁目一番地の「一号室」の取組だ。


プロフィール

宮本 認 Mitomu Miyamoto
BA参画前は、某外資系ファームで統括を務める。17業種のNo1/No2企業を経験した異色のIT戦略コンサルタント。

年別アーカイブ