第1回、第2回で、システム構築リーダーに大切なジレンマの許容度を解説しました。今回からいよいよプロジェクトを成功に導く、リーダーとして具体的な調整力の発揮法やアプローチを紹介します。そのスタートは何をもってプロジェクト成功とするのか、その基準についての考え方です。
プロジェクト成功の基準は何か、価値の方程式で考える
多くの企業のシステム部では、システムの運用管理やシステム構築の一部を担当するレベルから、システム構築を統括するリーダー、そして、予算管理や経営レベルの意思決定にも参画するマネジャーへといった具合にキャリアが進みます。リーダーから、マネジャーへのステップアップには視点の大きな変換を迫られます。ここでは、リーダーやエンジニアが、このキャリアの移行を乗り越えるために必要な考え方と視点について解説します。
現在、リーダーとして目前のプロジェクトの成功を使命としている方も多いと思います。さて、ここでいうプロジェクトの成功とは何でしょうか?
私がコンサルティング先でこのように問いかけると、多くの人は「QCD(品質、費用、納期)を満たすこと」と答えます。実際、この3つを満たせるかどうかで、プロジェクトの成否が判断される場合が多いのは事実です。さらにいえば、プロジェクトの現場では「プロジェクトを終わらせる」ことにばかり注力してしまう現実があります。
しかし、この当たり前だと思っている「プロジェクトの成功の基準」を今一度、考えてみてほしいのです。そして、この成功の基準こそが、エンジニアやリーダーとしてプロジェクトに携わるみなさんのキャリア構築に必要な視点となります。
顧客は何を買っているのか?
プロジェクトには必ず“顧客”が存在します。社内のプロジェクトであれば、それに予算を投じることを決めた経営層、及びそのシステムを使う営業部門、経理部門といった社内顧客です。プロジェクトは、そうした“顧客”が必要性を感じてお金を払ってくれる(予算を投じてくれる)から存在するわけです。社内であっても、プロジェクトにお金を払ってくれる人は“顧客”であるという意識が必要です。
では、プロジェクトの“顧客”は何に対してお金を払っているのでしょうか。言い換えれば、“顧客”は何を買っているのでしょうか。
例えば、システム開発のプロジェクトを考えてみましょう。プロジェクト開始時には、プロジェクトのスコープ(範囲)を決定します。「どんなものを作るのか」「どんな作業を行うのか」を決めるわけです。要件定義書や設計書、プログラムソースコード、そしてソフトウエアなどの成果物。プロジェクト期間中の定例ミーティングや、ユーザー向けに行う研修などの役務。これらがプロジェクトのスコープになります。これらの成果物が納品され、すべての役務が提供されてプロジェクトは完了します。…
ということは、“顧客”つまりユーザーは成果物と役務に対してお金を払っているのでしょうか? システム構築を担当するプロジェクトリーダーやチームメンバーはそう考えるかもしれません。しかし、お金を払っている“顧客”は、実はそう思っていないのです。
例えば、業務の効率化を図るためにシステム導入を決めたとします。幸い、当初の計画通りにプロジェクトは完了しました。成果物もすべて作成が終わり、ユーザーへの研修もすべて完了しました。
しかし、ユーザーはどうも不満そうです。それは、当初期待していたような「業務の効率化」が実現できそうもないからです。「こんな使いにくいシステムだと、かえって効率が落ちてしまう」とのクレームが相次いでいます。
プロジェクトチームとしては「当初予定していたコストで納まり、システムの稼働は期日に間に合ったし、不具合だって少なかった。自分たちとしてはよくやった」と思っているかもしれません。確かに、成果物と役務に関しては何の問題もないこのプロジェクトですが、果たして成功といえるのでしょうか。そうとは言えないことは誰にでも分かります。ということは、“顧客”であるユーザーが買っているのは成果物でも役務でもなく、別の何かだということなのです。
価値について考える
バリューエンジニアリング(価値工学、以下VE)では、「顧客はモノでなく、機能(ファンクション)を買っている」といいます。ここでいう機能(ファンクション)とは、コストを支払ったものから得られる「働き」であり、「何のために」買ったのかという目的です。“顧客”は成果物や役務が欲しかったのではなく、そこから得られる機能(ファンクション)が欲しいのです。
例えば、100円のボールペンに私たちは何を期待するでしょうか。それは「文字や絵を書く」、もっと言えば、「記録を残す」という働きではないでしょうか。このような、モノやサービスに期待する働きのことを機能(ファンクション)といいます。商品やサービスに、“顧客”がどれくらいの価値を感じるかは、得られたファンクションに対してどれくらいの犠牲(コスト)を支払ったかで決まります。
システム開発の例でいえば、要件定義書や設計書、ソフトウエアではなく、「効率化された業務」が欲しかったわけです。もっと言えば、「ラクになった自分たちの姿」が欲しかったのです。いくら成果物や役務が提供されても、ラクになった自分たちの姿が手に入っていなければ、“顧客”が不満に思うのは当たり前なのです。
VEは価値を「ファンクション(F)」と「コスト(C)」の比で考えます。得られるファンクション(機能・便益)がコストを超えたとき、価値が生まれるというわけです。すなわち“顧客”が感じる価値は絶対的なものではなく、それを得るために支払う犠牲(コスト)とファンクションとのバランスで変化する相対的なものなのです。
“顧客”が買っているのがモノでなく、機能(ファンクション)であり、そこに価値を感じるかどうかは、それを得るために支払った犠牲(コスト)よりも、得られた機能(ファンクション)が大きいときです。だとすれば、プロジェクトが成功したかどうかは、“顧客”が「価値を感じたかどうか」で決まるべきなのです。
「むしろ安いぐらいだ」と思われるプロジェクトに
この方程式から、「Value(価値)」を高めるには4つの方向性があることがわかります。
(1)ファンクションを維持して、コストを低減する。(V↑=F→/C↓)
(2)ファンクションを高めつつ、より安いコストで達成させる。(V↑=F↑/C↓)
(3)コストを維持して、ファンクションを向上させる。(V↑=F↑/C→)
(4)コストは上がっても、それ以上にファンクションを向上させる。(V↑=F↑↑/C↑)
この4つの方向性の中で、目指すべきは2つめのアプローチです。よりよいシステムを、より安いコストで実現することこそ、情報システム部門が目指すべき姿といえます。
「コスト(C)を下げる」ためには、プロジェクト活動の中でもっとも大きなコスト要素である「時間(工数)」を下げる必要があります。仕事の仕方(プロセス)を改善し、より少ない時間でより大きなアウトプットを生み出す工夫をし続ける必要があります。時間をリソース(資源)として捉え、意味のある活動に投資するという視点がリーダーには求められます。
そして、コスト以上に「ファンクション(F)を高める」ためには、顧客であるユーザー(会社)が何を求めているのかを理解する能力が必要となります。そのためには、自社の戦略を理解し、その実現をどのようにシステムでサポートするかを考える必要があります。また、システムを利用する直接のユーザーの要望をそしゃくし、要件として定義する能力も必要となるでしょう。
情報システム部門のリーダーは、「高い、高い」といわれがちなIT投資を「高いとは思わない」「むしろ安いぐらいだ」「高くてもほしい」といわれるようなものにするための戦略を持つ必要があるのです。
日経SYSTEMS/芝本秀徳(プロセスデザインエージェント)