人材育成コラム

　顧客がITベンダーやITエンジニアに期待すること、それは
「顧客の要求を引き出し、分析できる力を持った『ソリューションベンダー』」
だと思います。
　「ソリューションベンダーとは、業務の最適化、ボトルネックの解消、コストの削減などの経営上の課題の克服を支援する事業者である。主に情報システムの構築を通じて実現を支援する事業者を指す」（IT用語辞典バイナリより）

　「顧客業務の最適化、ボトルネックの解消、コスト削減などの経営課題の克服を支援する」この領域は、これまでコンサルの領域であり、ITエンジニアが介入する領域ではないという人もいました。しかし、現実にシステムが複雑化するなかで上流工程での整理がきちんとできないまま、システム開発に突入している例も決して珍しくありません。上流での検討が不十分なまま開発工程に突入したものは、しばしば原点に立ち返らなければならない大きな課題に遭遇したり、顧客との調整や計画の修正に多くの時間を費やしたりすることになります。
　仕様変更や仕様追加といったことは昔からあり、今後もなくなるとは思えませんが、ソリューションベンダーが上流工程からきちんと関わることで、多くのリスクの洗い出しとその対策を事前に検討することが可能になります。

　どちらかといえば、これまでは「仕様は顧客が定めるもの」、ITエンジニアは、「仕様に従ったものを開発し、実現すること」がその役割でした。
　システム開発の現場では、顧客とITエンジニアの次のようなやり取りが頻繁に発生しています。
　「お客様の要望通りに仕様を固め、ここまで進めてきたのに、今回のご要望はこれまでの仕様をかなり変更することになりますよ。仕様変更分の追加の見積もりも必要になります」。
　仕様は顧客が決めるものと考えていますから、上記のITエンジニアの主張は当然と考えてきました。私たちは、「言われたことをきっちり実現するＩＴエンジニア」を育ててきたともいえそうです。

　ところが、顧客は仕様変更とか、追加という思いではなく、ＩＴベンダーに対する期待や思いを話します。
　「それは私たちの認識と違いますね。御社のITエンジニアの方たちは、うちの業界に精通したITのプロと伺っています。確かに仕様には明示されていませんでしたが、今回の依頼内容は業界に精通している人なら、いわば常識の部分です。プロの目から仕様の抜け漏れがないかあらかじめチェックしていただいていれば、早い段階で明らかになっていたはずですよね」。
　システムが複雑化すると同時に顧客社内の関係部門が増え、顧客内部での取りまとめや合意形成がきちんと済んでいないケースも増えています。
　そこで業界に精通したプロのITエンジニア、つまり「仕様を確認して、抜け漏れがないか、最適な構成となっているか」など適切なアドバイスをしながら、最適なシステムを構築するITエンジニア、言い換えると
　「顧客の要求を引き出し、アドバイスができるITエンジニア」
が求められるようになってきたといえます。

　求めるスキルが変化してきた背景には、IT技術の進展により、ITで実現できる領域が急速に広がっていること、その結果一つのシステムに関わる社内の関係部署が増え、あるいは関係するパートナー会社の数も増え、利用する部門ごとにシステムへの思い、利害が異なり、人間関係的にも複雑化してきたことがあります。
　顧客内部だけで仕様を取りまとめることが困難になってきたといえるでしょう。
　システムも人間関係的にも複雑化しているなかでITベンダーがどのように立ち振る舞い、どのようなスキルを身に付けていけばよいのかを考える必要があります。
　「ソリューションベンダー」に求められるスキルは、従来のITエンジニアのスキルに加え、ビジネスアナリシスのスキルといえるでしょう。例えば、ビジネスアナリシス知識体系（BABOK）を学習することも一つです。
　究極は、コンサルタントに求められるスキルの習得ということになりますが、その入り口として、初級段階で身に付けたいスキルは「ステークホルダー分析」と「ビジネス要求の理解と分析」の2つのスキルです。

「キーマンは誰か？　ステークホルダー分析から導き出す」

　顧客の組織図を入手して、関係する部門の責任者や担当者を理解することは、ステークホルダー分析の入り口として重要です。ステークホルダー分析では、組織図をもとに作成したステークホルダー登録簿から、実際にキーマンと思われる方にヒアリングをします。ご自身の担当範囲、関心事項、業務課題、解決の方策、そして解決策を進めるうえでのステークホルダーとその関係（人間関係を含む）などをヒアリングします。
　キーマン候補数人に確認したうえで、「人間関係図」を作成します。組織図とは異なる各部門のキーマンの人間関係が明らかになる点が人間関係図の利点です。
　これができれば、今後のヒアリングの相手やヒアリング時のポイント等が徐々に明確になってきます。

　「組織図の入手」→「ステークホルダー登録簿の作成」→「人間関係図の作成」そしてこれらの情報からいくつかの分析ツールを使って、顧客と話しを進めるためのキーマンや次のステップで分析する「ビジネス要求」の重要度を見極めます。
　分析ツールとしては、「セイリエンスモデル」や「Ｂ－Ｓ分析（ビジネスシステムマトリクス分析）」などが有効でしょう。
　「ステークホルダマネジメント」は、PMBOK第5版から10番目の知識エリアとして取り挙げられるほど重要な項目であり、BABOKではさらに重要な知識として扱っています。
　「ソリューションベンダー」に従事するITエンジニアには早い段階から身に付けたいスキルです。

「ソリューション要求の前にビジネス要求を明らかにする」

　ステークホルダーの洗い出しと人間関係が明らかになったところで、それぞれのキーマンが望んでいるビジネス要求を確認します。
　「何がしたいか？」の「ソリューション要求」は、ビジネス要求が整理され、その重要度と緊急度を加味したうえで決定します。
　BABOKでは、要求の種類を「ビジネス要求」、「ステークホルダー要求」、「ソリューション要求」、そして「移行要求」の４種類あると定義しています。このうち「移行要求」は、システムを移行する際に必要な諸条件（導入教育、移行スケジュール、システム入れ替え時の条件など）ですから、ほかの３つの要求とは少し性格が異なります。

　各部門のステークホルダーがそれぞれに要求することは、いったん「ステークホルダー要求」として扱います。ステークホルダーが多数存在するなかで、ある要求はひとくくりにして扱い、整理するなかで顧客全体の「ビジネス要求」としてまとめます。
　おのおののステークホルダーは、自分の要求が「ビジネス要求」であると主張するでしょうが、企業全体のなかで扱うべき課題をその重要度や緊急度から優先付けを行って「ビジネス要求」が整理され、その課題の実現策として「ソリューション要求」が決定されます。

　「ステークホルダー要求」と「ビジネス要求」。この扱いが曖昧なまま「ソリューション要求」としてシステム開発に突入すると、開発段階で仕様追加・仕様変更が頻発し、時には仕切り直しにつながります。
　これらは、主体的には顧客内部で意思決定していただく必要がありますが、上流段階からソリューションベンダーが関わることで、顧客満足度の高いシステム開発が可能になってくるのだと思います。
　現在、ある教育ベンダーと一緒に「ステークホルダー分析」と「ビジネス要求の理解と分析」を強化するための研修の開発に取り組んでいます。興味のある方は、ぜひお問い合わせください。