IT部門における全体最適と部分最適のジレンマを解決する顧問エンジニアの可能性
一般企業のIT部門やテック企業のインフラ部門で良くある課題、それは全体最適を目指すIT部門と部分最適を志向する事業部門とのギャップ、軋轢ではないでしょうか。独自の要求をする事業部門に対して、特例があることによる管理コストの増加を避けたいIT部門が、要求を断ったり現状の基盤との親和性検討のため時間がかかったりすると、IT部門は遅い、使えない、事業部門は会社のことを考えていないとなり、事業部門が独自にアウトソーシング等でシステムを構築、結果的にいわゆる田舎の温泉宿的な鈍重なシステムになってしまったなんていう話は決して珍しくないと思います。このあたりは木村さんの連載記事に詳しいです。
記事にあるようにCIOやCTO、部長ら幹部たちが、事業部門を含む経営陣としっかり握った明確な方向性を示すことが一番ですが、多くの組織でははっきりとしないまま、現場まかせになっていたり、バラバラの方向を向いてしまっていたりするのが実情ではないでしょうか。最適解である全体最適と部分最適のその絶妙なバランスは組織ごとにも異なりますし、定型の解法というのも今はないでしょう。この命題が誰にとっても難しいのも事実のようです。ではどうしたらその解を見出せるでしょうか？
抽象レイヤーとしての顧問エンジニア
今仮説として検討しているのが、クラウドサービス大手のAmazon Web Services等が展開するサポートサービスであるTAM（テクニカルアカウントマネージャー）のような顧問エンジニアの存在を軸とする方法です。
事業部門またはさらに細かい単位を顧客としてそれぞれ固定のエンジニアを配置、新規システムの構築や改修等のコンサルティング、日々の運用やトラブル時の対応、健全性を保つ提言、そして、電話やチャットといったストレスの少ない連絡方法を用意します。顧問エンジニアが各事業部門の様々な要望や課題を献身的に汲み取り、統一のITインフラストラクチャ基盤に落とし込むことで、顧問エンジニアが抽象レイヤーとしての役割を担います。非常に大変な業務だとは思いますが、日々エキサイティングですし、課題解決というもっとも知的創造活動だとも言えるでしょう。これを実現する上で注視した方がいいことが3つあるように思います。顧問エンジニアが潰れてしまっては元も子もないので、「緊急連絡はトラブル時のみ」などSLA（サービスレベルアグリーメント）を定義し、その持続可能性を留意する必要があるでしょう。顧問エンジニアの評価を、「担当数と満足度」の掛け合わせによって判断し、企業の評価基準とのマッチングを明確にすれば、モチベーション向上にも寄与するはずです。さらに顧問エンジニアのチームとインフラ基盤のチームで有機的な連携を計り、常に満足度を向上させるような改善を行うことも忘れてはいけません。このあたりをしっかり押さえていけばある程度形になるのではないでしょうか。
事例募集中！
現状はまだ全て仮説なので、小さいところから始めていきたいと思います。何か気づきがあればアップデートします。こういう制度や方式を取っている方がもしいらっしゃったら是非教えてくださいませ。
