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

要件定義力の再構築(6):要件定義力の本質と要件定義のマネジメント

宮本認(ビズオース )

2019-03-16 07:00

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

 ここまで、要件定義は難しい仕事だから、極力簡単にしていこうと説いてきた。そのためには、「段階を分けて考えていくこと」「パッケージを使って開発して要件定義の量を減らしていくこと」「システム規模を10億円未満になるように細分化していくこと」――などの案件の進め方が有効だと説明してきた。

 ただし、これらはあくまで要件定義の対象、つまり案件自体をコントロールすることで要件定義の成功確率を高めようというもので、要件定義の力を底上げするというものではない。成功の条件を整えているようなものだ。

 要件定義力の本質は、ビジョンとコミュニケーションにある。

 ビジョンとは、あえて「観」という言葉を使いたい。自社の「成長観」、自社の「業務観」、あるべき「システム観」――など、成長のためにはどういった業務を作るべきで、そのためのシステムはこうあるべきだといったものだ。こうした姿をどれだけ持っているかどうかで、良いシステムとなるかどうかは最終的に決まる。

 急成長を目指しているのか、それとも安定的な成長を期待しているのか、急激な変化に見舞われて事業構造を変えていかないといけない局面にあるのか。こうした成長の姿は、作っていくべき業務やシステムを大きく左右する。急成長といっても、単一の商品やサービスを広めていく方法と、商品や事業を多角化することでポートフォリオを多彩にする方法がある。安定的な成長においても、拡大志向と効率志向とがある。急激な変化に見舞われ、事業構造を変えるときはもっと複雑かつ難解だ。

 これらは概念的な説明だが、企業の中でも同様で、「どれくらい成長をしていくのか」「どういう事業構造に変換していくのか」というのは、得てして明快には説明されていないことが多い。せいぜい「10%成長」といった数字が踊っているくらいではないだろうか。その方法を具体的、論理的、包括的、明示的に説明されていることはまれである。

 恐らくは、こうしたことを明快に説明できる経営者が名経営者として名を馳せるのだろうが、そういった人材はやはり少ないのだろう。ここで言いたいのは、要件定義を担う人は、自分自身で「成長観」「業務観」「システム観」を持って取り組むべきなのである。

 こうした「観」が必要となるのは、詰まるところ、ユーザー、経営者、関係部署に納得をしてもらわなければならないからである。納得してもらうには、根回しを含め、さまざまな説得策を採らねばならない。多かれ少なかれ、政治的な動きを取らざるを得ず、作ろうとしているシステムを認めてもらわなければならない。要は、コミュニケーションを取らねばならない。

 コミュニケーションというと、「ドキュメンテーション力」「プレゼンテーション力」「会議の運営力」など、伝達系の能力である「How」が多く問われることとなるが、最も大切なのは「What」にある。要件定義の場合、変える業務や新たに作るシステムがその「What」に当たる。その内容は「会社にとって圧倒的な善」であり、経営者、ユーザー、システム部門が納得せざるを得ないものであることが望ましい。

 戦略を実現する方法が明示されていない、具体的な方法がどこにもないからこそ、会社にとっての最善を考えることが最も重要な「コミュニケーションコンテンツ」となる。

 当然、一朝一夕で作れるものではなく、準備が必要になる。特に人材面が重要になる。つまり、案件のためのプロジェクトマネージャーを用意するのだ。できれば事前に計画を伝え、そのために必要なことを考えておいてもらいたい。数年後にどういう案件の見直しがあるかはあらかじめ分かっているだろう。そこに向けて、候補となる人材を見つけ、会社の成長はどうあるべきか、業務はどうあるべきか、システムはどうあるべきか、その準備をさせておこう。

 別に、その専任になれと言っているわけではない。宿題や自由研究として検討させ、たまに発表などを行ってもらうことでも十分だろう。あらかじめ深く考え、具体的なイメージが詰まっているようなら、要件定義を成功させる確率はぐっと上がってくる。要件定義をはじめシステム開発を成功させるプロジェクトマネージャーは、やはりそのプロジェクトのあり方についてはっきりとしたものの考え方を持っている。そういうマネージャーは急に現れるものではない。育てよう。

 要件定義力≒人材育成≒準備力なのだが、それだけでは足りない。要件定義を進めるためのマネジメントも必要である。

 要件定義とは、3つの段階であると解説したが、この3つは必ず順番であるべきである。すなわち、それぞれが終わっていないものを後工程につなげるべきものでは決してない。

 要件定義の成否とは、システム開発の成否を定めるという会社の業績の成否に結び付く話だけではなく、個人の業績と評価に関わる話でもある。プロジェクトがうまくいかなければ、当然、人事評価が下がることとなる。評価が下がってしまうのならば、プロジェクトの問題については隠ぺいし、前に進めてしまった方がいいと判断をしてしまうのだ。

 こうした問題は自明の理なのであるが、会社の政策と人事の政策を一致させている企業は思いのほか少ない。筆者の経験では、ごく一部のエクセレントカンパニーのみが、これをやっている状態である。例えば、企画や要件定義をやった人が運用まで担当しなければならないというルールがある。要は、適当な言い逃れで、回りもしない業務をやることを許さないのだ。こういう企業は既に「マネジメント」ができている状態であり、以降の話は必要ない。むしろ望ましい状態である。

 しかし、多くの会社はこういうエクセレントカンパニーではない。一般の企業は、企画者が責任を持って運用することはない。企画できる人も少ないし、そんなに長く一つの部署にとどめることもない。そうすると何が起こるのか。情報が上がらないのだ。

 ある会社で実際に採った改革策なのだが、役員に「怒るのを止めてください」という施策をお願いしたことがあった。理由は「正しい情報が上がらない」からだ。上司に怒鳴られれば気持ちが滅入る。それと同時に、自分の評価と出世が気になる。異動の可能性もある。社内政治を使って引っ張ってもらう部署も調整済だ。多少の問題があっても、今は前に進めて、ここまでは良かったことにしておこう。そういう気持ちが働く。

 筆者もかつては、サラリーマンコンサルタントだったが、こういう具合に自分さえ良ければいいという考え方で動くのはコンサルタントだってそうだ。そういうコンサルタントを腐るほど見てきた。大型案件で顧客にとって都合の良いことだけ言って開発の佳境になる前に逃げていったり、今年の受注をするだけしておいて来年の受注を前借して今年の業績をお化粧して他部門に移っていったりなど、挙げれば切りがない。

 要は、自分は良い評価をされたいというのは、企業ならば当たり前なのだ。本来ならば、人事施策を「運用定着まで担当する」という整合が取れるものに変えるべきなのだが、情報システムの施策で人事まで徹底するというのは多くの企業にとって非現実的である。そうすると、前述のような「情報が上がってくる仕組み」を情報システム部門の中に作り上げるしかない。

 最近、日本企業の不祥事が増えてきている。そのたびに、第三者委員会が作られ、報告を上げる。内部の人だと、それこそ忖度(そんたく)が働いて、きちんとした情報収集、分析、報告ができないと思われている。つまり、マネジメントの中にしっかりとしたけん制を入れようという考えだ。これも本来ならば、不祥事が起こる前にやっておくべきである。起きてからでは影響が大き過ぎる。第三者委員会というけん制の仕組みは防止のためにこそ使われるべきだ。

 この事前防止の仕組みを情報システムに入れたい。本来的には日常的に機能させたいところであるが、流石に日常的では要員などのコストもかかる。要所要所で行う形態が現実的だろう。

 そう考えると、3つの段階のExitとEntryがその「要所」となる。そこできっちりと「終わって大丈夫なのか」と第三者が確認し、最終責任者に報告する。この方法だと、工数も限定的だし、ある程度の客観性が保たれる。そのための人材が必要になるが、ある程度のIT知識があり、周囲に流されない人材であればよい。コミュニケーションに難があるがたまに良いことを言うベテランや、経験は不十分だが正義感が強くてストレートにものを言う若手など、そういった人材はいないだろうか。いずれにしても、今の部門の中で「第三者」のように振る舞えて、活躍できそうな人材であればよい。

 後は、それぞれの段階におけるExitとEntryの基準である。ExitとEntryというからには、終わったか、始められるかという話に尽きる。ここでは詳説しないもののエッセンスだけを説明しておきたい。

 「始められるか」というのは、言うなれば計画があり、体制があり、予算があるという状態だ。マスタープランや移行のプランがある、推進のみならず品質や予算管理の態勢が整っている、そして経営の参画を含め、プロジェクトリーダーやコアメンバーが整っているかどうかをチェックする。ある意味で分かりやすい。

 難しいのはExitの方だろう。要件定義を「構想」「要件定義」「ベンダー選定」の3つの段階で考えようと述べてきたが、Exitは当然それぞれにある。

 構想とは、システムの目的を定め、システムによってもたらされる改革を定めるものだ。だから、「効果」がきちんと定義されているかどうかがExitの基本となる。すなわち、目的、スコープ、定量効果、効果の実現方法(業務改革方法)が定められているかどうかである。

 要件定義は、新業務を設計し、システムの機能とデータの定義や、運用を定義することだ。だから、「仕様」がきちんと定義されていることが重要であり、そのためには要件定義項目一つひとつの終了をチェックすることとなる。終了というのは、仕様としてきちんと定義されているのみならず、成果物もちゃんと作られているかどうかも問われることとなる。可能であれば、RFP(提案依頼書)にそのまま使えるレベルを考えておきたい。

 最後の「ベンダー選定」は、やりたいことがきちんとできるかどうかが問われることとなる。すなわち、ベンダーはきっちりと開発の能力があり、予算は効果以内にきっちりと収まり、将来の保守性も高い仕組みとなっているかどうかをチェックする。可能であれば、その代替案も評価しておきたい。

 このExitとEntryの第三者チェックは、要件定義力で言えばいわば「型」に当たる。型なので、実際の内容を保証するものではないし、プロジェクトごとに事情が異なる中で、適度な柔軟性が求められることは言うまでもない。しかしながら、あらゆるものに「型」があるようにシステム開発、すなわち要件定義にも「型」がある。その「型」を組織的に行うための虎の巻作りだと思ってもらった方がいいと思う。

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

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

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

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

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

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