サービス型チームを作る

　マトリックス組織をつくり運用するために必要な一つ目の要素であるサービス型チームについて記載する。サービス型チームの作り方は、頭で考えるのは楽ちん。先日参加したガートナーのイベントでも、プロダクトチーム(サービスチーム)が必要だ！みたいな事をアナリストの方が言っていたが、総論同意。一方で、サービス型チームの作り方の情報提供はもちろん無く、そこが大切なのになと思った。今回はサービス型チームの意義や作り方について、記載する。

サービス型チームが必要な背景

　サービス型チームが必要な背景は、仕事が複雑になっているのにスピードアップが求められているためである。サービス型チームを作り、その連携をAPIのようにするということが必須になりつつある。何故ならば、仕事は信頼関係でなりたっており、その信頼の境界線はサービスとして定義をすることでわかりやすく表現できる。その結果、仕事の重複や隙間が明確になり、圧倒的に仕事がやりやすくなる。同時に、サービス定義をすることで社員のスキルが格段に上がり、自律的なチームとなる。ほぼティール組織。また、今までのように、Digitalがプロジェクトではなく、サブスクのようなサービスになりつつある昨今、一時的なプロジェクトマネージメントではなく、EOL(End Of Life)まで走り続けるサービスマネージメントが重要になっており、そのような視点でもサービス型チームという定義が重要になる。

サービス型チームの作り方

　まずは適切な大きさでサービスを定義する。できれば2Pizzaくらいで。サービスとはアプリケーションサービスもあるし、ヘルプデスクのようなサービスもあり、全ての仕事は全てサービス化するという視点で考えればOK。そしてそれをリスト化し、ストラテジーというグループを作る。そして、サービス間連携をするためのバリューチェーンを作る。できる限りシンプルに作る方が良い。その後、ストラテジー内で最適化を図り、隙間や重複を緩和する。最後に、ストラテジー間の調整を行う。ストラテジー内の調整はWeeklyで行っても良いが、そこはストラテジーを担当するストラテジストが行う。ストラテジー間の調整はQBR（四半期レビュー）にて、ストラテジー間の目線合わせを必ず行う。微調整は日々行ってもOK。

ピープルマネージメントとの分離

　サービス型チームのピープルマネージメントは分離してもOK。もしかしたら分離してから、一緒にできるか考えた方がよさそう。一般的に認知されているピープルマネージメントの組織を作ってから仕事を渡すと、その瞬間から仕事が既得権益化される。また、できていないことを出来ていると責任を果たさなくなる。つまり、組織に丸投げをするようなピープルマネージメントの組織型の仕事をすると、ノウハウや人材の効率化が下がってしまう。(今後記載する計画であるコミュニケーション改革をしないと、このサービス型チームは機能しないが)。まずはサービスの定義を明確にし、それから組織を作る事が重要である。いわゆるマネージメントスキルを3つにわけると、3Pで整理できてそれを分離して育成計画を立てると良い。Product Management（Service Management）、Project Management、People Management。分離して育成したり役割を持たせると、楽になりそうなのがわかるでしょう？

サービス型チームで外せないこと

　サービスにはプレスリリースが必要である。これはAmazonが行っているサービス開発をする前には必ずプレスリリースを作るというお作法から学び、それを日本企業的にアレンジして実践している。
　サービスの大きさに正解はない。例えば、小さめのサービスを作り新卒2年目に任せてもよい。
　そして、サービス型チームを作るための一丁目一番地である、DX時代の人材マネージメント、これについては次回に記載させて頂きたい。ここにDXの本質が隠されている。People Portfolio Management、ロールアサインリスト、実力型人事制度、など 私がVMwareやMicorosoft、AWSで実践してきた人材マネージメントがまさにDX向きである事は複数企業で実証できている。それではまたおあいしましょう。