編集部からのお知らせ
解説集:台頭するロボット市場のいま
解説集:データ活用で考えるデータの選び方
コンサルティング現場のカラクリ

要件定義力の再構築(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 記事を毎朝メールでまとめ読み(登録無料)

Special PR

特集

CIO

セキュリティ

スペシャル

ホワイトペーパー

新着

ランキング

  1. クラウドコンピューティング

    AI導入に立ちはだかる「データ」「複雑さ」「コスト」「人材」の壁をどう乗り切ればいいのか?

  2. クラウドコンピューティング

    【IDC調査】2026年には75%のアプリがAIを実装!導入で遅れた企業はどう“逆転”すべきか?

  3. 運用管理

    経産省調査で明らかに:未だにレガシーシステムを抱える企業が8割!オープン化でよくある課題とは?

  4. 運用管理

    AWS東京リージョンの大規模障害に学ぶ、パブリッククラウド上のシステムの迅速な復旧方法

  5. windows-server

    【ユースケース】ソフトウェア開発にDell EMCインフラ+コンテナを使うメリット

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]