新しい技術や開発プロセスをプロジェクトで採用するには、上司や経営幹部といった社内の関係者の説得が必要になることが多い。新しい技術やプロセスの採用には失敗のリスクが伴う。こうしたリスクに敏感な上司は、既に実績が豊富な手段の採用を求める姿勢になりがちだ。大規模なシステムとなればなおさらである。
では、社内の関係者をどう説得するか。野村総合研究所の小塚信昭さん(流通・情報通信ソリューション事業本部 通信システム一部 グループマネージャー)の事例を見てみよう。
新しいフレームワークを開発する
小塚さんが大手通信事業者B社のプロジェクトでマネジャーを務めたときのこと。そのプロジェクトでは、チームのITアーキテクトが、「データ量が膨大になっても分散処理しやすい新しいフレームワークを自社でこれから開発しアプリケーション基盤として採用する」という案を出してきた。既存のフレームワークでは、データ量が膨大になったときの対処が難しく、小塚さんは新しいフレームワークを開発することが最良の策だと判断した。
しかし、自社内の関係者の説得が難しかった。そのフレームワークには実績がなく、関係者にとってリスクが高いと映るのは当然だった。
そこで小塚さんは、関係者をその立場を基に大きく三つに分け、それぞれが想定しそうなリスクを推測。その上で、リスクごとの対策を示すという方法を採用した。「相手がもやっと抱いているリスクをあえて明確にしてその対策を伝えることで、不安感を払拭したかった」と小塚さんは話す。
関係者の立場に応じたリスクを推定
説得する必要のある社内の関係者はさまざまだったが、特に重要なのは三つだった。経営幹部、事業責任者(小塚さんが所属する部署のトップ)、研究開発部門の責任者である。小塚さんは、それぞれの立場から想定するであろうリスクを推測した(図6)。
経営幹部は、一つの案件にとどまらず、新しいフレームワークに投資したコストを回収できるかどうかを重視するもの。このためユーザーが見つからないというリスクを恐れる。そこで小塚さんはあらかじめ、新しいフレームワークを採用する内諾をB社のキーパーソンから得た。B社のキーパーソンは挑戦意欲が高く、内諾は容易に得られたという。その上で、経営幹部に対して、この案件での実績によって他のユーザーにも受け入れてもらえる、という見通しを示して説得した。
一方、事業責任者が抱く可能性の高いリスクはフレームワークの属人化だった。事業責任者は、プロジェクトの内情や新しいフレームワークについてある程度理解している。しかし、フレームワークを使いこなせるのが1人のITアーキテクトだけとなると、その人が仮に病欠するとプロジェクトが停滞してしまう。他のプロジェクトへの適用も難しい。