このコラムは、株式会社エル・ティー・エスのLTSコラムとして2015年2月から連載を開始した記事を移設したものです。
ライター
プロジェクト推進者の事前期待は、主体性とプロジェクト運営への自信で決まる洗い出す
プロジェクト推進者を分類する軸としては主体性とプロジェクト運営の自信の2つを使いました。この2つの軸は密接な関係があります。中には「自信がないから、主体性がない」という担当者もいます。このような方は本心から主体性がないのではなく「わからないからやりたくない」という姿勢ですので、ベンダー側がしっかりリードして、お客様に運営ノウハウを伝授していくと主体性のある推進者に変わってくれる人もいます。
さてこの2つの軸を掛け合わせると以下のようなセグメントが浮かび上がってきます。
この中から「推薦意識先行型」と「ベンダ利用」型を見てみましょう。
「推進意識先行」型の場合は、不慣れな推進者をしっかりガイドする
「推進意識先行」型は、運営能力は低いのですが主体性をもって作業に取り組んでくれるセグメントです。著者が過去にお付き合いしたお客様には、このセグメントが多くいます。
一般的には現場の業務知識をしっかり持っていて、求める業務の姿をしっかり語る一方で、情報システムやプロジェクト運営に関しては知識がなかったり、経験不足を感じさせたりする様子があればこのセグメントでしょう。中には自分から「システム開発経験がないからサポートをお願いしたい」と依頼される方もいます。また、プロジェクト運営に自信がないにもかかわらず担当者に任命されてしまった推進者の中には、不安からくる拒否反応で、一見するとやる気のない「すべておまかせ」型のように見える人がいます。
しかし、よく話を聞くとプロジェクトを推進しなくてはならないという責任感と、どうやって進めたらいいのかわからない不安との狭間で苦しんでいる心の内が見えてきます。「進めなくてはいけない」という潜在的な主体性があれば「推進意識先行」型と言ってもよいと思います。このようなケースは、強い不安感を何度も示すので見分けるのは容易です。
このセグメントの推進者の場合には、共感性と安心感が大切になります。やる気に対して能力が追い付いていないため、自分の考えをうまく表現することができません。その結果、意図を誤解させてしまうような説明をすることもあります。ですから、ベンダー側が相手の背景や思いを汲み取って意図を明確にする必要があります。そのうえで自分たちがついているから大丈夫という安心感を提供しましょう。
このセグメントは、ベンダーのプロフェッショナルとしての姿勢が問われます。相手はシステム開発の専門家としてベンダーを頼っていますから、ベンダーが主導してユーザーを引っ張る必要があります。ベンダーはある程度広い範囲をカバーし、主体的にプロジェクト管理を行うことを前提にした体制や見積りを組まないとうまく進められないでしょう。
コミュニケーション全般にわかりやすさが大切となり、システム開発上必要とされる要件定義書や設計書とは別に、ユーザーが理解できる粒度や難易度に調整した説明資料などが必要になるかもしれません。ただ、ユーザーの熱意や推進主体としての自覚を無駄にしないよう、親身に接しつつも育てる姿勢で推進者を巻き込んでいけば、次第により良い協力関係と高い顧客満足を引き出すことができるでしょう。
「ベンダー利用」型は、正確性と迅速性を確保したうえで、柔軟性で担当者を楽にさせる
「ベンダー利用」型は、プロジェクトを運営する能力があっても主体性はありません。プロジェクトの進め方やIT 用語をよく知っていて、豊富な経験があることを感じさせつつも、やる気が感じられないとなったらこのセグメントです。このセグメントはできるだけ仕事で楽をしたいという姿勢が見えます。そのため、作業の主体はベンダーとなります。ただし、決してプロジェクト運営に素人というわけではないので、ベンダーに対する要求や指摘は厳しく、接するのに緊張感が必要です。
著者の過去の経験では、ユーザー部門ほどシステム導入に熱意を持っていなかった情報システム部の担当者がこのセグメントでした。また、他の業務とプロジェクト運営との掛け持ちになってしまった結果、プロジェクトに意識を割く余裕がなくなってしまった管理職もこのセグメントでした。このセグメントは、「プロジェクトは仕様要求者とベンダーにまかせ、自分は最低限の管理に徹したい」と思っていますから、隙があればできるだけベンダーに作業をやらせようとします。
「言われたことしかできないのか」「気が利かない」「なんとかしておいて」といった言葉が口癖です。ただし、ベンダーとの役割分担は理解していますし、管理者や監視者としての役割はわきまえています。ですから、決して「丸投げ」ではありません。要所でしっかり状況を確認し、必要であればベンダーに指摘してくるでしょう。両社の関係は、ひとつのプロジェクトを進める仲間というより管理する側とされる側という形になりますから、うまく作業が進捗していないと容赦なく追及されます。
「プロジェクト掌握」型と同じように正確性と迅速性が大切なのは言うまでもありませんが、このセグメントはただ当たり前のことをやっているだけでは満足してくれません。それだけでは自分たちは楽にはならないからです。この場合は、正確性と迅速性に加えて柔軟性が重要となります。一定の役割分担の取り決めは必要ですが、厳格に役割分担に従うよりは多少は推進者の作業をカバーしたり、支援したりすると「楽をさせてくれるベンダー」ないしは「気の利くベンダー」となります。推進者がシステムオーナーに行う報告作業を手伝うなどはその最たる例です。
プロジェクト推進者がこのセグメントの場合は、仕様要求者との関係も合わせて重視すべきです。仕様要求者との良好な関係が構築されていれば要件定義や設計の作業は進めることができます。自分が関わらなくてもプロジェクトが進捗している状況は、このセグメントの推進者が最も望む状態です。やる気のないプロジェクト推進者を巻き込みすぎるよりは、そのほうが楽なこともあるかもしれません。あまり作業をカバーしすぎるとベンダー側の負担ばかり増えますが、そこは考えようです。ベンダーとしては楽をさせてあげる分だけ、対価を得ることができるからです。
著者にはこのセグメントのお客様は大企業の管理職に多い印象があります。管理職だと一定の決裁権があります。優秀な方が多いですが、忙しいので自分ができないこと、やりたくないことはベンダーにまかせます。「御用聞き」と言ってしまえばそれまでですが、「このベンダーを抱えておくと自分が楽できる」と思ってもらえれば積極的に使ってもらえます。
事実、著者が経験した案件の担当者はこのセグメントでした。何か必要な作業がプロジェクトに発生した際に、しっかり提案すれば次々と仕事をまかせてくれたのでその案件は当初の見込みを上回る売上となりました。それほど難易度が高くなくベンダーとして構築するシステム像が明確な場合は、むしろこういう担当者の方がいることをビジネスチャンスと捉えることもできます。
いかがでしょうか。「Aさんは○○型だな」とご自身のお客様に当てはまったり、これまでに出会ったことのないお客様のタイプの説明もあったかと思います。このコラムでご紹介したシステム開発プロジェクトに関わるお客様のタイプはあくまでも参考ですので、みなさまのお客様に全て当てはまるものではありません。
お客様の業種や業態によって期待の分かれる軸は変わるはずですので、これまでの内容を参考にしてご自身のお客様を分析してみてください。なお、ここではご紹介できなかった「仕様要求者」と「システム利用者」のタイプ＆攻略法や、システム開発サービスを提供する際にチームメンバーで作成、共有するとより効率的にプロセス品質を高めて顧客満足を得られる「サービスプロセスモデル」の作成方法についても、書籍「サービスサイエンスによる顧客共創型ITビジネス」では説明しています。
次回コラムのテーマは「プロセス品質を高めるため企業としてどうしたら良いか」です。これまではシステム開発の現場で使える手法についてのお話しでしたが、プロセス品質の向上は現場だけに任せるのではなく企業としても取り組む必要があるのです。是非次回もお読みください！
サービスサイエンスによる顧客共創型ITビジネス
本書はビジネスをサービスの論理から改善するための「サービスサイエンス」に基づくITビジネスについての書籍です。システム開発会社、企業のIT部門、サービスサイエンスを駆使してプロジェクトを成功させていく方向を明確にしていきます。
著者：諏訪 良武, 山本 政樹
出版社：翔泳社（2015年1月28日）
