システム開発のお客様とは誰なのか システム開発は接客業⑧のサムネイル
デジタルテクノロジー

システム開発のお客様とは誰なのか システム開発は接客業⑧

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

ライター

山本 政樹(LTS 執行役員)

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

前回までのコラムでシステム開発におけるプロセス品質がどのようなものか理解いただけたと思います。しかし、これまで示したのはあくまでも全体像であって、お客様すべてに同じようなサービスを提供すればよいわけではありません。たとえば、こまめな進捗報告を高く評価するお客様もいれば、あまり評価してくれないお客様もいます。したがって、プロセス品質は漠然と実現させればよいのではなく、お客様の特性に合わせて実現する必要があるのです。

ここでサービスの定義を思い出してください。サービスとは「人や構造物が発揮する機能でユーザーの事前期待に適合するもの」でした。お客様が誰で、どのような期待を持っているかを考えることは、サービスを提供するうえでとても大切なのですが、多くの人が集まるシステム開発の現場で「誰がお客様なのか」という問いに答えるのは簡単ではありません。今回のコラムからは効果的なプロセス品質の実現のために、システム開発のお客様とは誰なのか、お客様の特性ごとにどのようなプロセス品質を実現すべきなのかを考えていきます。

システム開発のお客様は主に4種類の役割に分類できる

システム開発にはどのようなお客様がいるのでしょうか。プロジェクトに集まるお客様企業の関係者を思いつくまま挙げてみると、その多様さに驚かされます。決裁権を持っている役員、ユーザー部門長である管理職、システムの細かい仕様を要求するユーザー代表など様々です。このようにお客様側の体制に集う人々をその肩書きや所属部署や会社で分類しようとすると千差万別でうまく整理することができません。しかし、お客様を担っている役割で分類するとシンプルになります。ここでは、お客様の役割を以下のように分類してみました。

  • システムオーナー:プロジェクトの重大事項を判断する決定者
  • プロジェクト推進者:プロジェクトを円滑に進める調整者であり現場管理者
  • 仕様要求者:システムで実現する細かい仕様の要求者
  • システム利用者:稼働したシステムを使う利用者

プロジェクトはシステムオーナーの指示を受けたプロジェクト推進者が計画を作成し、システムオーナーが承認してスタートします。そして仕様要求者が要求を出し、ベンダーがシステムを構築します。その過程ではプロジェクト推進者が各種手続きや調整事項を担います。最後に、システム利用者に完成したシステムを活用してもらうという流れになります。この分類方法を使えば社内外を問わず、たいていの関係者をどこかに分類することができます。

たとえば、お客様側のプロジェクトマネジメントを支援しているコンサルタントは、多くの場合はプロジェクト推進者の立場ですし、運用保守を担うアウトソーシングベンダーがシステムへの非機能要求を提出する場合は仕様要求者の立場であると分類できます。プロジェクトの体制はさまざまなので、仕様要求者がプロジェクトに参画しているケースもあれば、プロジェクトは調整機能だけを受け持ち、ユーザー部門の仕様要求者に毎回ヒアリングに行くようなケースもあります。

しかし、プロジェクト体制がどうであっても、お客様の役割の全体像は変わりません。お客様の肩書や所属に惑わされるのではなく、その人がどういった役割でシステム開発に参加しているのかを見極めることが大切です。

事前期待はお客様の役割で変わる

それぞれの役割のお客様に満足してもらいたい場合は、どうすればいいのでしょうか。実は、お客様の役割によって、求められるプロセス品質は変わります。

システムオーナーの事前期待

システムオーナーの立場で見ればシステムは動けばよいというものではなく、ROI(投資対効果)をしっかり出すことが大切です。システムオーナーは決裁権を持っているので、納得のいく説明ができるとプロジェクト方針の変更や追加投資を決心してもらえることもあります。システムオーナーと接するうえで大切なのは、まず共感性です。システムオーナー個人の思いも重要ですが、主管している組織の状況や社内での役割など、全体の事情を考慮した会話ができないと信頼を得ることはできません。ここで得た信頼を壊さないよう柔軟性を発揮してプロジェクトを推進していくことが大切です。

またシステムオーナーと接する時間は、進捗報告や意思決定のための会議が中心となります。限られた時間で信頼を得るためには、正確な情報を正しく伝えることが大切です。正確性と迅速性のバランスの取れた報告は、安心感にもつながります。

プロジェクト推進者の事前期待

プロジェクト推進者は社内外の関係者を巻き込みつつ、プロジェクトの現場管理を担います。プロジェクト推進者とベンダーは苦楽を共にし、プロジェクトの全工程で密接に関わることになります。プロジェクト推進者の一番の期待はプロジェクトをうまく運営して、無事にシステムを稼働させることです。費用対効果を重視するシステムオーナーに対して、プロジェクト推進者はコストと納期を守ったうえで、システムを無事稼働させることを重視する傾向にあります。プロジェクト推進者がコストや納期の決定権限を持っていることは少ないため、システムオーナーと約束したコストや納期の変更には神経質になるからです。

プロジェクト推進者の立場では、トラブルなくプロジェクトが進捗しているという状況が一番ですから、安心感がとても大切です。ベンダーは、お客様に「この人たちがいてくれればプロジェクトが成功する」と思ってもらえなくてはいけません。プロジェクト推進者は、ある程度の機能の妥協やシステム要件の削減は自分の裁量で可能なため、コストや納期にリスクを感じるとシステム品質を犠牲にしようとする傾向があります。他のプロジェクト関係者の期待を損ねないためには、ベンダーはプロジェクト推進者が安易に品質や関係者の期待を犠牲にしないよううまくリードすることが大切です。

仕様要求者の事前期待

仕様要求者は、要求が受け入れられて使い勝手の良いシステムができあがることを重視します。要求仕様を実現することが最優先で、極端なケースでは自分たちの要求が受け入れられないとプロジェクトに協力してくれないこともあります。システムオーナーやプロジェクト推進者と比較すると、コストや納期への責任感が弱いため、ソフトウェア品質重視となる傾向にあります。仕様要求者と接する際も共感性が大切になります。

システムオーナーはオーナーの主管する組織全体への共感が大切なのに対して、仕様要求者は要求者個人への共感が大切になります。IT やシステム開発の進め方に不慣れな方が多いので、自らの要求する機能を正しく表現できないことがあります。相手の立場で求めている機能を理解し、「あなたが求めている機能は、こういうことですよね」というように具体的な表現で会話することが大切です。

システム利用者の事前期待

システム利用者の期待は、自分たちに使い勝手の良いシステムを構築して欲しいという点では仕様要求者と同じです。ただ、プロジェクトに直接関わっていないためシステム導入に関する情報が少なく、不安を持ちやすい傾向にあります。このため、システム導入で影響を受ける利用者には、早めに情報提供を行い、操作教育やサポートを手厚く準備するといった安心感を重視した振る舞いが大切です。ベンダーは普段あまり接点がないため、その期待をじかに感じることがありません。

しかし、プロジェクトから遠い立場にいるお客様からだからこそ、利用者を意識した設計が大切です。システム利用者の視点でプロジェクトを進めるには、仕様要求者と同じように共感性が大切になります。

システム開発のお客様を役割で分類したことで、お客様の姿が少し見えてきました。ただ、これはあくまでも大きな括りで見た場合の傾向であるため、たとえばプロジェクト推進者であれば誰でも「安心感」を与えれば必ず顧客満足を得られる、という単純な話ではありません。それぞれの役割の中にはまた色々なタイプの方がいるわけで、そのタイプ毎に期待も異なります。次回は各役割をさらに分解して、同じ役割でも人によって異なる事前期待と発揮すべきプロセス品質を考えてみましょう。