コンサルティング現場のカラクリ

要件定義力の再構築(4):「要件」自体を再「定義」して細分化する(後編)

宮本認(ビズオース ) 2019年03月02日 07時00分

  • このエントリーをはてなブックマークに追加
  • 印刷

(本記事はBizauthが提供する「BA BLOG」から転載、編集しています)

・前回の記事はこちら

要件定義は3つのに分けて考える

 まずは「構想」の段階。予備検討や基礎検討と呼ぶこともある。要件定義に入る前にプロジェクトの概要や目的、大まかな予算感を定めるために取り入れている企業は多いだろう。それはそれで大切なのだが、ここで構想と言っているのは、その予備検討よりも少し業務要件寄りである。

 要は、業務要件の部分を分けて前倒しでやってほしいのだ。業務の流れを調べ、どのように変わるのかをあらかじめ定めてほしいのである。そうすれば、きちんとした効果が見込める。

 この効果というのがミソで、システム化というのは詰まるところ、費用対効果があるものをやるべきである。これは、その費用の上限を決める行為なのだ。目的は効果の明確化なので、完全な網羅性はいらない。むしろ、どれくらいインパクトのある改革をするか、そこを決めてもらうことの方が重要である。

 システム単位の費用対効果を定める最初の行為であり、言い方を変えると、費用対効果を最後に考えるのではなく、先に考えて上限を定めればいいというわけだ。

 コンサルタントが中長期の改革構想を立案したり、IT活用の将来像などを打ち立てたりすることがある。そのときにもこの段階を踏んでもらった方がいい。コンサルタントはそれなりにうまく長期構想をまとめようとするが、実際にそこからやろうとすると、システム一つひとつを考える必要がある。こういう際は、特に業務の一つひとつに落とし込み、費用対効果を本格的に検討してもらいたい。

 次が「要件定義」の段階だ。ここは言うまでもないだろう。業務を網羅的にきちんと設計し、システム機能を定義し、データを見極める。そして、業務量、サイクルを踏まえてインフラを整理する。通常の要件定義だ。しかし、構想段階で既に核となる業務についてはある程度見極めている。大切になるのは「網羅性」と「具体性」だ。

 網羅性は簡単だ。スコープをしっかりと定め、抜け漏れなく業務をリストアップし、定義し切ることだ。開発段階で、あれもこれもというのは良くある話で、それを極力抑えることになる。また、業務のリストを作ることも重要だ。業務要件の定義がうまくいかない企業は、とにかく業務のリストが出来上がっていない。「どれだけやればいいんですか?」という初歩的な問いにすら答えられないのだ。

 余談だが、業務要件定義の最も重要な成果物は、業務フローが一般的であるが、時と場合によっては、業務フローを端折ることを推奨する。理由は、工数を節約するためである。

 業務フローを書く能力は、昔はコンサルタントがコンサルタントたるべき資質の一つだったが、今はずいぶんと一般化し、多くの人が記述できるようになった。フロー図は分かりやすい反面、作成工数が膨らみやすく、変更になったときの保守性もあるい。

 そのため、筆者はしばしば「ファンクションチャート」で代用することを勧めている。フローの代わりに樹形図を使って業務を整理するのである。業務のリストアップと業務要件定義、システム機能とデータの定義を一覧可能になるため、抜け漏れをつぶしやすい。また、作るべき成果物を減らすことができる。つまり、節約が可能となるのだ。節約できれば、網羅性も考えやすい。ぜひ参考にしていただきたい。

 では、具体性について考えていこう。ユーザーにとって理解できる要件とは、どこまでいっても「画面」と「帳票」だと考えている。また、アプリケーションはどこまでいっても、CRUD(Create、Read、Update、Delete)が重要にある。システムの画面がHTML形式になり、単一の画面に数多くの機能を加えられるようになるなど、機能の単位が変わりつつある。また、そうした機能の変化に応じて、見積もりの手法も変化している。

 そのため、機能にコミットするのを止めて、ユーザーになるべく画面で議論をさせないというベンダーが相当数いるのも事実だ。しかし、ユーザーはやはりシステムを画面と帳票で考える。そこで初めて自分がやりたいことを本当に要望として上げることができる。

 要件定義とは、コストを正確に把握するためにやる。そういう意味で、要件が抜けたり、間違っていることは極力避けなければならない。だから、なるべくユーザーの要望に沿わなければならない。そのための一番のイメージは、画面と帳票で議論することだ。決してその通り作れというものではないが、基本設計以降で膨張するプロジェクトはおおむね、この画面での確認ができておらず、イメージが湧いたときにあれもこれもと出てくる場合だ。

 多くの場合、このデータを表示してほしいというケースと、このパターンはどう処理するのかという取引や処理パターンで膨らんでいくのだが、そうしたことを整理しようと言っても、このパターンが分かり切っている人は極めて優秀な人で、そもそもそれが分かり切っている人がいないから困っていることが多い。要件定義段階で、こうした埋もれやすい要求を洗い出しておきたい。そのためには、しんどいが要件定義で画面を議論しておきたい。

 最後はベンダーの選定である。多かれ少なかれ、構想を分けている企業があることは上述した。企画とでも言うべきだろうか。しかしながら、ベンダー選定を要件定義から分離している企業は実は少ない。

 グローバルスタンダード的には、情報システム部門の業務には、「Sourcing」という調達業務を分離するようになっている。当然と言えば当然なのだが、委託金額が非常に大きく、ベンダー選定が成功を大きく左右することになるため、調達を専門業務として運営し、ノウハウを確立していくことは望ましい。日本の製造業には必ず調達部門があるが、ベンダーとパートナーシップを作りながら効率化を図ることは片手間でできるものではない。

 ベンダー選定は、RFP(提案依頼書)を書いて、提案受理のための質疑応答に答えながら提案を受理し、価格交渉と契約交渉を行い、次の体制を整え意思決定を行う。当たり前に考えて、これだけで数カ月かかる業務であり、ユーザー企業にとってはある意味ハイライトであるし、ベンダーが最も生き生きと働く。

 また、さまざまなものがうごめき、刻々と状況が変わる、極めてエキサイティングな段階である。こういう言い方をするのもなんだが、経営やユーザーが本当に何を考えているか、本性が現れる部分である。また、進めるプロジェクトマネージャーにとっても、情熱、本気度、政治力といったウェットな部分が問われる。

 ベンダー選定というものは、特別なスキルはほとんどいらない。必要なものは、RFPの書き方を後々の分析や価格交渉、契約交渉に都合が良いように提案をもらえるように指定することである。それ以外は、熱意をもって良い選定をしようと取り組めば、選定の基礎資料は確実にできるし、基本的に良い選定にたどり着く。

 あるといいのは、ビジネスセンスだ。「ベンダーはこの仕事を取りたがっているのか」「そもそも、相場はどれくらいと考えらえるか」「価格はどれくらいで折り合いをつけるか」「自社とベンダー、交渉上の上手にいるのはどちらか」「外部のベンダーのやる気を引き出すことはできるか」「社内の誰が、どのベンダーを支持しているか?」「どういう条件があれば折れることができるか」――といった具合だ。

 筆者は、政治に関わったことがないので、何とも言い難いのであるが、昔ながらの政治家はこうした業者や役所、政治家内の利害関係を調整したのであろう。まさにこうした利害関係の調整力がものを言う。そういう類の仕事である。

 スキルはいらないといったものの、ベンダー選定は非常に難易度が高い仕事である。政治家という職業があらゆる職業の上位に君臨するように、ベンダー選定をやる人は本来的に最も上位の政治的能力を持った人が当たるべき仕事である。大切なことは、そういう能力を「専門」能力としていくことだ。

 ベンダーのやりたいことは、ベンダー内の政策や業績状況で刻々と変わる。社内の力学も同様に刻々と変わる。こうしたことを「久しぶりに」とか「初めて」やるような人にはなかなかできるものではない。ベンダー選定をサポートする能力を特別専門職として捉え、あらゆる案件に携わるような専門職を内部に持っておくことが好ましい。

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

宮本認(みやもと・みとむ)
ビズオース マネージング ディレクター
大手外資系コンサルティングファーム、大手SIer、大手外資系リサーチファームを経て現職。17業種のNo.1/No.2企業に対するコンサルティング実績を持つ。金融業、流通業、サービス業を中心に、IT戦略の立案、デジタル戦略の立案、情報システム部門改革、デジタル事業の立ち上げ支援を行う。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

関連ホワイトペーパー

SpecialPR

連載

CIO
月刊 Windows 10移行の心・技・体
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
セキュリティインシデント対応の現場
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]