2017.12.22

要件定義力を徹底的に再構築する：⑦要件定義力向上の本質と要件定義のマネジメント

要件定義力向上の本質と要件定義のマネジメント

ここまでは、要件定義は難しい仕事だから、極力簡単にしていこうと説いている。簡単にしていくには、フェーズを分けて考えていくこと、パッケージを使って開発、すなわち要件定義の量自体も減らしていくこと、システム自体を10億未満になるように細分化していくこと、といった案件の進め方が有効であることを説明してきた。ただし、これらはあくまで、要件定義の対象、すなわち案件自体をコントロールすることで、要件定義の成功確率を高めようというもので、実は要件定義力そのものを上げるというものではない。成功の条件を整えているようなものだ。

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

ビジョンとは、あえて「観」という言葉を使いたい。自社の会社の「成長観」、自社の「業務観」、あるべき「システム観」。成長のために、どうした業務を作るべきで、そのためのシステムはこうあるべきである。。。こうした姿をどれだけ持っているかどうかで、良いシステムとなるかどうかは、最終的には決まる。
急成長を遂げようとしている事業なのか、それとも安定的な成長を遂げようとしているのか、急激な変化に見舞われ事業構造を変えていかないといけない局面にあるのか、こうした成長の姿は、どのような業務・システムを作っていくべきなのかを大きく左右する。急成長といっても、単一の商品・サービスが世に伝播していくタイミングと、商品や事業を多角化することでポートフォリオを多彩にするやり方で成長する場合でも業務・システムの在り方は変わってくる。安定的な成長も拡大志向の時と、効率志向のときとでは業務・システムの組立方は当然変わる。急激な変化に見舞われ、事業構造を変えるときは、もっと複雑かつ難解で、求められる変化の速度や変化の大きさは本当にわかりにくい。
上述は概念的な説明とはなっているが、企業の中でも同様で、どれくらい成長をしていくのか、どういう事業構造変換をしていくのか、というのは得てして明快には説明されていないことが多い。せいぜい、「10%成長」といった数字が踊っているくらいではないだろうか。10%成長の方法を具体的・論理的・包括的・明示的に説明されていることは稀である。おそらくは、こうしたことを明快に説明できる経営者が名経営者として名を馳せるのであろうが、名経営者と言われる人はやはり少ないということだろう。言いたいことは、要件定義を担う人は、自分自身で「成長観」と「業務観」と「システム観」をもって取組に挑むべきなのである。
こうした「観」が必要となるのは、詰まるところ、ユーザー、経営、関係部署に納得をしてもらわなければならないからである。納得してもらうには、根回しを含め、様々な説得策をとらねばならない。多かれ少なかれ、政治的な動きを取らざるを得ず、作ろうとしているシステムを認めてもらわなければならない。要は、コミュニケーションをとらねばならない。
コミュニケーションというと、ドキュメンテーション力、プレゼンテーション力、会議の運営力など伝達系の能力である「How」が多く問われることとなるが、もっとも大切なのは「What」にある。要件定義の場合、変える業務、新たに作るシステムがその「What」にあたるのであるが、その内容そのものが、「会社にとって圧倒的な善」であり、経営、ユーザー、システム部門が納得せざるを得ないものであることが望ましい。
戦略を実現する方法が明示されていない具体的な方法がどこにもない場合が多いからこそ、会社にとって一番いいことを一番考えること、それがもっとも重要な「コミュニケーション・コンテンツ」となる。

こうしたコミュニケーション・コンテンツは一朝一夕で作れるものでは当然ない。そう、準備が必要なのだ。準備とは、人を準備しておくことである。すなわち、案件のためのプロジェクトマネジャーを準備するのだ。お前、あの案件のプロジェクトマネジャーをするんだぞと、できれば伝え、そのために必要なことをあらかじめ考えておいてもらいたい。数年後にどういう案件見直しがあるかは、予めわかっているだろう。そこに向けて、候補となる人材を見つけ、会社の成長はどうあるべきか、業務はどうあるべきか、システムはどうあるべきか、準備をさせておこう。
別に、そのために100%従事をしろと言っているわけではない。宿題、自由研究として検討させ、たまに発表などを行ってもらうことでも十分だろう。あらかじめ深く考え、具体的なイメージが詰まっているようならば、要件定義を成功させる確率はぐっと上がってくる。要件定義をはじめシステム開発を成功させるプロジェクトマネジャーは、やはりそのプロジェクトのあり方についてはっきりとしたものの考え方をもっている。繰り返しになるが、そうしたマネジャーは一朝一夕にはできない。育てよう。

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

要件定義とは、3つの段階であると前述しているが、この3つは必ずシーケンスであるべきである。すなわち、それぞれが終わっていないものを後工程につなげるべきものでは決してない。
要件定義の成否とは、システム開発の成否を定めるという、会社の業績の成否に結び付く話だけではなく、個人の業績・評価に関わる話でもある。プロジェクトが上手くいかないということがあれば、当然、自分の評価が下がることとなる。評価が下がってしまうのならば、プロジェクトの問題については隠蔽し、前に進めてしまったほうがいいと判断をしてしまうのだ。
こうした問題は自明の理なのであるが、会社の政策と人事の政策を一致させている企業は思の他少ない。自分の経験では極一部のエクセレントカンパニーのみが、これをやっている状態である。ごく一部のエクセレントカンパニーでは、企画や要件定義をやった人が運用まで担当しなければならないルールがある。要は、適当な言い逃れで回りもしない業務をやることを許さないのだ。こういう企業は、言うなれば「マネジメント」が出来ている状態であり、以降の話は必要ない。むしろ、望ましい状態である。
しかし、多くの会社はこういうエクセレントカンパニーではない。普通の企業だ。普通の企業は、企画者が責任をもって運用にもっていくことはない。企画できる人も少ないし、そんなに長く一つの部署にとどめることもない。では、何が起こるのか。情報が上がらないのだ。
ある会社で実際にとった改革策なのであるが、役員に「怒るのをやめてください」という施策をお願いしたことがあった。理由は、「正しい情報が上がらない」からだ。上司から怒鳴り上げられれば、気持ちはいやになる。それと同じくらい、自分の評価と出世が気になる。自分は異動する可能性もある。社内の政治も行って、引っ張ってもらう部署も調整済だ。多少の問題があっても、今は前に進めて、ここまでは良かったということにしておこう。。。という気持ちが働く。
筆者もかつては、サラリーマン・コンサルタントだったが、こういう具合に自分さえ良ければいいという考え方で動くのはコンサルタントだってそうだ。自分さえ良ければいいというコンサルタントは腐るほど見てきた。大型案件を顧客にとって都合のいいことだけをいい、開発の佳境になる前に、逃げていくコンサルタント。今年の受注をするだけしておいて、来年の受注を前借して今年の業績をお化粧して、他部門に移っていくコンサルタント。
要は、自分はいい評価をされたい…というのは、企業ならば当たり前なのだ。本来ならば、人事施策を「運用定着まで担当する」という、整合がとれるものに変えるべきなのだが、情報システムの施策で人事まで徹底するというのは多くの企業にとって非現実的である。そうすると、前述で申し上げた「情報が上がってくる仕組み」を、情報システム部門の中に作り上げるしかない。

最近、日本企業の不祥事が増えてきている。そのたびに、第三者委員会が作られ、報告を上げる。中の人間であれば、それこそ忖度が働き、きちんとした情報収集、分析、報告が信用できないと思われている。要は、マネジメントの中にしっかりとした牽制を入れようという考えだ。これも本来ならば、不祥事が起こる前にやっておくべきである。起きてからではインパクトが大きすぎる。第三者委員会という牽制の仕組みは防止のためにこそ、使われるべきだ。
この事前防止の仕組みを情報システムに入れたい。本来的には日常的に機能させたいところであるが、流石に日常的では要員等のコストもかかる。ポイントポイントで行う形態が現実的であろう。
そう考えると、3つのフェーズのExitとEntryがその「ポイント」となる。このポイントで、きっちりと「終わって大丈夫なのか？」と第三者的人材がチェックし、最終責任者に報告する。この方法だと、工数も限定的であるし、ある程度の客観性が保たれる。チェックする人材が重要となるが、ある程度のITの知識があって、周囲に流されない人材であればよい。プロジェクトマネジャーには、コミュニケーションに難があって向かないが、たまにいいことを言うようなベテランはいるのではなかろうか？また、経験は不十分だけど、正義感が強くてストレートにモノを言いすぎてしまうような若手はいないだろうか？いずれにしても、今の部門の中に、「第三者」のように振る舞えば活躍できそうな人材でやればよい。

後は、それぞれのフェーズでのExitとEntryの基準である。ExitとEntryというからには、終わったか、始められるかという話に尽きてくる。
ここでは、紙面が限られるので、詳説はしないもののエッセンスだけ説明しておきたい。
始められるか？というのは、言うなれば計画があり、体制があり、予算があるということに尽きてくる。マスタープランや移行のプランがある、推進のみならず品質や予算管理の態勢が整っている、そして経営の参画を含め、プロジェクトリーダーや業務やシステム検討のコアメンバーが整っているという準備が出来ているかどうかをチェックする。ある意味で分かりやすい。
より難しいのは、Exitの方だろう。本項において、要件定義を「構想」「要件定義」「ベンダー選定」の3つのフェーズで考えようと述べているが、Exitも当然それぞれある。構想とは、システムの目的を定め、システムによってもたらされる改革を定めるものだ。だから、「効果」がきちんと定義されているかどうかがExitの基本となる。すなわち、目的、スコープ、定量効果、効果の実現方法(業務改革方法)が定められているかどうかである。要件定義は、新業務を設計し、システムの機能とデータの定義や、運用を定義することだ。だから、「仕様」がきちんと定義し終わっていることが重要であり、そのためには要件定義項目一つ一つの終了をチェックすることとなる。終了というのは、仕様としてきちんと定義されているのみならず、成果物もちゃんと作られているかどうかも問われることとなる。可能であれば、RFPにそのまま使えるレベルを考えていきたい。最後の「ベンダー選定」は、やりたいことがきちんとできるかどうかが問われることとなる。すなわち、ベンダーはきっちりと開発の能力があり、予算は効果以内にきっちりとおさまり、将来的なメンテナビリティも高い仕組みとなっているかどうかをチェックする。可能であれば、その代替案も評価しておきたい。
このExitとEntryの第三者的なチェックは、要件定義力でいえば、いわば「型」にあたる。型なので、実際の内容を保証するものではないし、個別のプロジェクトの個別の事情が異なる中で、適度に柔軟に適用を変えることは言うまでもない。しかしながら、あらゆるものに「型」があるようにシステム開発、すなわち要件定義にも「型」がある。その「型」を組織的に行うための虎の巻づくりだと思ってもらった方がいいと思う。