ビジネスは、その経済活動が何らかの社会的付加価値につながっていなければ、投資したお金は無駄になってしまいます。例えば企業であれば、将来像(=事業の目標)を明確にし、その目標に向かって最短で突き進むことです。
P.F.ドラッカーは著書「マネジメント」の中で、事業の目標について、次の目標を具体的に定義し・行動をすることが必要であると述べています。
高所大所なことのように感じられるかもしれませんので、ITの現場寄りの内容で記載いたします。
そもそも将来像(To Be)を描く意味について、多くの方は次のように思われるかもしれません。
「ビジネスには、それを達成すべき目標がある。よってその目標が将来像である。よってその将来像を描くことは、関係者がそのことを共有するためには当たり前の取り組みである。(できているか否かは別として・・・)」
しかし将来像(To Be)とは、誰にとっての、しかもいつ時点のことを言っているのでしょうか?
つまり社内外のステークホルダーによってもその将来像は異なり、また来月なのか1年後なのか、はたまた10年後なのかによっても、その内容は異なるかもしれません。さらにそれらは、企業の戦略にひも付いていなければ、組織や個人の嗜好に左右された内容になってしまい、収拾が付かない将来像が、ただ乱立しているだけの状態になってしまいます。従って何らかの将来像を描く場合には、これらの問題を踏まえた上で、プロジェクトを立ち上げる前の構想・企画段階で、ステークホルダーと合意しておくことがとても重要になります。
例えばこのようなことがありました。
システム基盤が老朽化したため、基盤刷新のためのプロジェクトを実施することになりました。その時のプロジェクトの目的は「システム基盤の刷新」でした。ただその企業において、システム部門はコスト部門です。そのためプロジェクトの予算は、システムを利用しているユーザ部門の折半でまかなわざるを得ませんでした。しかしユーザ部門にとって、この目的では何らメリットは享受できないため出資は否定的でした。でもシステム基盤の老朽化により企業の継続的事業遂行に支障を来たすリスクは会社として認められないと社長は判断、プロジェクトは実施されることになりました。ところがプロジェクトは立ち上がったものの、社長決裁であるが故にユーザ部門は出資することにはしぶしぶ同意はしたものの、プロジェクトへの協力は極めて消極的でした。
このプロジェクトは、システム利用者であり出資者でもあるユーザ部門という重要なステークホルダーが、プロジェクトの目的に合意しないまま強行されたのです。
このようなケースにおいてもシステム部門は、プロジェクトの構想・企画段階において、ユーザ部門の合意を取り付けておく必要がありました。
ではユーザ部門には、どのような要求があったと想定されるでしょうか?
参考になるのは、BABOKⓇの重要なコンセプトである「要求」を分類するという部分です。その分類には次のようなものがあります。
この中で、今回のテーマである「将来像(To Be)を描くことの意味」に関連する最も重要な要求は「ビジネス要求」と「ステークホルダー要求」です。「ビジネス要求」とは、企業の目的および目標またはニーズを概要レベルで表現した要求です。一方「ステークホルダー要求」は、特定のステークホルダーや特定のステークホルダーのクラスのニーズについて表現した要求です。さらにステークホルダーは、次のように分類できると示しています。
さてシステム基盤を刷新するというプロジェクトのケースにおける「ビジネス要求」は何なのでしょうか?
企業が必要としていることは、システムの基盤ではなく安定的な事業継続です。よって
「安定的に事業を継続するための仕組みを維持すること」となります。
一方で今回のケースにおける「ステークホルダー要求」は何なのでしょうか?
BABOKⓇのステークホルダー分類を使ってみると、例えば次のようになります。
お気づきのとおり「ビジネス要求」、「ステークホルダー要求」共に、「システム基盤の刷新」というキーワードは出てきていません。しかしながら「システム基盤の刷新」を、あたかも「ビジネス要求」/「ステークホルダー要求」であるかのごとくプロジェクトの目的を定め、進めようとしたために、ユーザ部門の反発を食らったのです。
ではどのようにしたら良かったのでしょうか?
次回はこの方法について解説し、またそのことを通じ、「将来像(To Be)を描くことの意味」についてお伝えします。