システム開発に関わるお客様のタイプ(システムオーナー編) システム開発は接客業⑩のサムネイル
デジタルテクノロジー

システム開発に関わるお客様のタイプ(システムオーナー編) システム開発は接客業⑩

このコラムは、株式会社エル・ティー・エスのLTSコラムとして2015年2月から連載を開始した記事を移設したものです。

ライター

山本 政樹(LTS 執行役員)

アクセンチュア、フリーコンサルタントを経てLTSに入社。ビジネスプロセス変革案件を手掛け、ビジネスプロセスマネジメント及びビジネスアナリシスの手法や人材育成に関する啓蒙活動に注力している。近年、組織能力「ビジネスアジリティ」の研究家としても活動している。(2021年6月時点)  ⇒プロフィールの詳細はこちら

システム開発プロジェクトに関わるお客様は大枠の分類として「システムオーナー」「プロジェクト推進者」「仕様要求者」「システム利用者」の4つが存在しますが、前回のコラムでご紹介した事前期待の軸を使ってさらにタイプを分類してみるともう少し具体的なお客様像が見えてきます。簡単に言うと、自分でプロジェクトを進めたいタイプなのか、ベンダーに任せたいタイプなのか、という分類です。書籍ではそれぞれのタイプの特徴と攻略法が書かれています。ここではその一部をご紹介します。

システムオーナーの事前期待は、意思決定の傾向と熱意で決まる

システムオーナーのセグメントするために意思決定の傾向積極性意思決定の合理性の3つの軸を使いました。軸を掛け合わせると下図 のように8つのセグメントに広がります。

実際に研究対象となったのは8つのセグメントのうち6つです。この中から3つのタイプをご紹介します。

「先頭切って走る」型

積極性があり自分で決めたい「先頭切って走る」型の場合、プロジェクトは良くも悪くもシステムオーナーの強い影響下で進みます。オーナーは取り組みの全体像やROI(投資対効果)を見て判断を下していますから、コストやスケジュールだけでなくシステム品質や業務の将来像にも思いを持っています。プロジェクト運営ではオーナーの意向が極めて重要になり、ベンダーはオーナーを無視して作業を進めることはできません。明確な理想像を持っている方ですから「自分が思っていることを速やかに実現して欲しい」というのがオーナーの期待になります。

オーナーに接する際に求められる姿勢は何より迅速性です。「今日できることは今日やれ」というセグメントですから、スピード感をもってプロジェクトを進めていく必要があります。もちろん、迅速性だけあればよいというものではなく、資料や報告にミスがないとか、指示を間違いなく実行できるといった正確性を実現したうえで、かつスピードも大切ということです。また、ベンダーの杓子定規で非効率な振る舞いは迅速性の妨げにもなるので、柔軟性も大切になります。オーナーの意図を確認するためにいちいちおうかがいを立てるのではなく、柔軟な判断で先回りした対応を心がけましょう。

逆に、どうしても自分たちで判断できないことは、時間を浪費せずすぐにオーナーにおうかがいを立てるべきです。一緒に仕事をするのは大変なセグメントではありますが、社内で発言力があることも多く、「お気に入りベンダー」に仲間入りできれば今後も指名をいただけるでしょう。また、厳しい要求とスピード感についていく能力が必要とされるため、自然とベンダー側も育てられます。ついていくのは難しいですが、オーナーの信頼を得られるようになった際には自社の成長を実感できるでしょう。

「管理統制」型

積極的な改革を行うことより、コストやスケジュールが超過しない守りの運営に主眼を置くのが「管理統制」型です。積極性を欠くため、評論家的な姿勢になることがあります。いつもは「先頭切って走る」型のオーナーも、積極性を欠く案件だとこのセグメントとなるかもしれません。たとえば、法制度対応のような施策は行わざるを得ませんが、オーナーからすれば積極的にやりたいことではありません。誰しも要件を満たす範囲でできるだけ出費を抑えたいと思うものです。また本来はやりたいことではあっても、予算の制約などで守りの運営をせざるを得ないようなケースもあります。

このセグメントのオーナーの考え方は「必要なことを最低限のコストで」というものです。大切なのは正確性で、当初約束したコスト、スケジュール、スコープを順守し、やるべきことをしっかりやることが基本です。また、根拠のある報告を定期的に行うといった安心感の提供も大切です。仮に、計画変更が必要な場合は、速やかに変更内容を報告しなければなりません。一方で、サービス精神を発揮してコストを使う提案をどんどんするような行為は、余計なお世話と思われるでしょう。

上記2つのタイプはオーナーの個性に起因する意思決定の傾向と合理性は同じでも、プロジェクトに対する積極性の違いによって分かれるわかりやすい例です。また、意思決定は周りに任せて積極性がないタイプもいます。

「部下丸投げ」型

自分自身に強い意志はなく、周りの意見ばかりを気にする「部下丸投げ」型は、あまり頼りにならないオーナーです。プロジェクトを主体的に進めることはしないため、現場はプロジェクト推進者まかせになります。ベンダーはオーナーの意向を気にしても、あまり有益な情報を得ることができません。また、プロジェクトの意思決定者が不明確になり迷走することがあります。このようなオーナーは打ち合わせに登場することは少なく、ベンダーとのやりとりも部下にまかせます。コストやスケジュールの超過を不安視したり、プロジェクトリスクに強い懸念を示したりと、後ろ向きともとれる発言が目立つこともあります。

その一方で、プロジェクトの本質的な内容に触れることはあまりありません。オーナーの本音は「放っておいてもプロジェクトが無事進捗していればよい」といったところです。したがって、大切なのは安心感になります。定期的な報告に異常がなく、トラブルがあっても、関係部署を巻き込んだ形で解決されているとの説明があれば安心できます。また、オーナーの意思決定が必要な際は必要な情報と根拠を揃え、オーナーは承認だけ行えばよいようになっていることが大切です。

オーナーに接する場合に気をつけるべきこととして、ついつい巻き込むべき場から外してしまったり、適切な報告を怠ってしまうことです。あまり興味がなさそうだからと言って、オーナーの知らないところで物事を進めすぎると、オーナーも不安になります。自分が軽んじられていると思うオーナーもいるかもしれません。定期的な情報共有と適切な意思決定への巻き込みは忘れないようにしましょう。

ベンダーは「私たちにおまかせください」という姿勢をしっかり打ち出すことが大切です。プロジェクト推進者と連携してプロジェクトをしっかり推進しつつ、定期的な報告は欠かさないようにします。このベンダーに頼めば安心できると思えば、次の開発案件のベンダーとしてオーナーから推薦してもらえるかもしれません。

いかがでしたでしょうか。これまで出会ったシステムオーナーはいずれかのタイプに当てはまりましたか?このようなかたちで、書籍にはそれぞれのタイプ別に特徴と攻略法が書かれています。次回は「プロジェクト推進者」と「仕様要求者」編です!