CCoEの立ち上げにあたり "MVV" にとことん向き合った話

## はじめに

筆者は現在、所属企業であるWorks Human Intelligence(以下WHI)においてCCoEに所属しております。弊社は今年7月に新たにCCoEを発足し、私は組織の立ち上げから関わってきて、今に至っております。
半年間、CCoE本格始動のため奔走してきたわけですが、その中の取り組みの一つとして、組織のMVVの策定をしよう、というものがありました。

私がまずMVVの叩き台を1週間くらいかけて作り、チーム内に共有したところ、いくつかのフィードバックをもらいました。そこから議論が始まり、どんどん議論が深まっていき……気づいたら半年です。半年を掛け、ようやくMVVを定め切ることができました。
MVVは後述の通り、組織が、組織に所属する一人一人が、目標に向かってブレずに活動していく上で非常に有用なものであるわけです。が、一方でMVVは、合計で多くとも10行程度のセンテンスであることも事実です。10行に半年を費やし、ブラッシュアップを重ねてきたわけです。

本記事では、そんなたった10行のセンテンスに半年を掛け議論を重ねてきた中でのいくつかの気づきと、我々が我々のミッション・ビジョン・バリューにどのような意思を込めたのかを紹介いたします。

## MVVとは
https://biz.moneyforward.com/payroll/basic/65388/

https://prtimes.jp/magazine/mvv/

MVVとはミッション・ビジョン・バリューの頭文字を取った言葉であり、企業や組織の存在意義や使命、そのための価値観を明確にする(外部に示し、内部で共通認識を醸成する)ために定めるものです。
上記記事では、それぞれ以下の定義が紹介されています。

```
マネーフォワード
ミッション：企業が社会で実現したいことを言語化したもの。
ビジョン  ：企業のミッションが実現したときの状態。企業の将来像や理想像を表したもの。
バリュー  ：ミッションやビジョンの実現のために大切にする価値観や行動指針を言語化したもの。

PR TIMES
ミッション：企業が社会に対して「なすべきこと」
ビジョン  ：企業・組織が目指す「あるべき姿」
バリュー  ：企業・組織の構成員が具体的に「やるべきこと」
```

MVVは前述の通り、組織内外の双方に対してその組織を表現します。
組織外の人たちには、その組織がつまり何のための組織で、どんなことをやるのか、やらないのかをざっくりと理解してもらえます。
組織のメンバーは、自分たちが仕事に取り組む上で、その中での行動を決めていく上での指針を得ることになります。

ミッションの達成という目標があるからこそ、その目標に向かってギャップを埋めるための逆算、という形で活動方針が決まっていく。
その活動方針を決める上で、自組織がどうなっている必要があるかというビジョンがベースになる。
活動方針を具体的なToDoに落とし込む中で具体的に何をどうやるかを決める上で、ToDoを実際の業務としてこなしていく中で人とコミュニケーションを取る上で、価値観たるバリューを念頭に置いて一挙手一投足を決めていく。

その組織に関わる全てのステークホルダにおいて共通認識を醸成するという観点で、MVVの策定は非常に重要なことであると言えます。

## なぜMVVに時間をかけて向き合ったのか

我々がMVVを考えるのに時間を費やした理由は、**CCoEという組織はともすれば雑用係のようになってしまう可能性がある**、というものでした。

CCoEにおけるアンチパターンにはまった例の一つとして、「あるCCoEが、取り組む領域としてルールガイドライン整備や人材育成などの長期的な取り組みを含めた複数の活動領域を掲げ設立されたものの、実際に活動を始めると個別案件支援に多くの工数を取られることとなり、いわば人員派遣のような状態に陥ってしまった」というものがありました。
特に我々WHIのCCoEにおいては、立ち上げの経緯もあり、その懸念がより強い状況でした。

その立ち上げの経緯というのは、
- クラウド利用について議論する社内分科会において、議論は活発に行われ、方針やタスクは決まっていく状況であった。
- 一方やることは決まるものの、いざ実行の段になると、分科会がバーチャル組織であるために主務と比べた際に優先度が下がりがちになる。結果なかなかタスクが進まない、という課題があった。
- その解決のため、物理組織として、タスクに工数を掛け進めることに責任を持つ部署をCCoEとして立ち上げた。

というものです。

この立ち上げの経緯から分かるように、弊社のCCoE組織は、自分たちのミッション・ビジョンの下、自分たちのバリューに沿って発生したものではなく、存在しているタスクが当面のメインの仕事であるということです。
ただ、だからこそ、です。タスクのレベルまで落とし込まれたToDoがあるということは、ただその意味を考えずにこなすだけ、ということもできるわけですが、それこそ雑用をこなすだけの雑用係になってしまっていると言えます。
**既に存在するタスクをこなすことがメインの仕事になるからこそ**、ただ漫然とこなす状態に陥らないために、**今取り組んでいるタスクが何のための取り組みなのか、最終的に実現したいことにつながるのか、を常に意識できる必要があり、そのためにはMVVが通常の組織よりもより重要である、と考えました。**

## CoEだからこそのMVVの特徴

CoEでない組織ではシンプルに、ミッションは「自組織が周囲(会社・顧客・社会)に対して実現したいこと」、ビジョンは「自組織が目指す、自組織があるべき姿」と置き換えればよいですが、CCoEをはじめCoE組織においては、ビジョンの考え方が少し異なります。
**CoEである組織において、ビジョンの「自組織が目指す、自組織があるべき姿」において、「自組織」とは何でしょうか。CoEでしょうか。それとも自社全体でしょうか。**

このことについて、**我々は議論の末、自社全体である、と結論付けました。なぜならばCoEである以上、ミッションが、「全社横断」の組織として「自社の状態を変えること」であるためです。**
ビジョンは「自組織が目指す、自組織があるべき姿」であり、かつ「自組織のミッションが実現したときの状態」です。CoEが「自社の状態を変える」というミッションを実現することにより、「自組織のミッションが実現したときの状態」=「自組織があるべき姿」に到達する、という構図となります。

すなわち、CoEとしてのミッションとビジョンにおいては、
- **CoEという組織がどのような使命を果たすことで、自社全体をどのような理想的な状態に到達させることができるのか**
言い換えれば
- **自社の理想的な状態を実現するためには、CoEという組織がどのような使命を果たさねばならないのか**

ということを念頭に考える必要がある、ということです。

## MVVを考える上で重視したポイント

我々がMVVを考える上で重視したポイントが2つあります。

一つ目は、**フレーズがすっと耳に入ってきて、簡単に理解できるものであること**です。
エンジニアだと結構その特徴を持っている方は多いんじゃないか、と思うのですが、私も、情報をできる限り間違いなく、不足なく伝えられるような文章を書く傾向があります。それも今回は、自分の組織のMVVという、自分たちが何をしたいのかということを伝えるセンテンスを作る、というシチュエーションであるので、ともすればその傾向が出がちになるところです。
ただ、このように意識して書いた文章は総じて冗長な印象になりがちで、いわばとっつきにくい文章になります。
我々は議論の上、**MVVは、まず周りに興味を持ってもらうきっかけになればよい**、と割り切ることにしました。興味を持ってもらえれば、相手からもう少し詳しく活動とかを知ってみよう、と思ってもらい、聞く耳を持ってもらったり、相手からのアクションを促したりできる、ということです。

二つ目は、**社内の既存組織との差別化が、MVVの中で明確になること**です。
一つ目のポイントで、まず周りに興味を持ってもらうことが大切、と言及しましたが、**興味を期待感として持ってもらう**ために必要な要素の一つとして、その組織は今までにないどのような価値を発揮するのか、があろう、となりました。
CCoEを新たに組成する場合で、既に社内でクラウドプラットフォームやSaaSサービスの活用が進んでいる場合、共通機能提供についてはIT部門であったり、ルール・ガイドライン策定では品質管理部門であったり、と、既存組織と活動領域が被る部分が出てまいります。特に弊社はSaaSベンダーであるため、よりその傾向が顕著になります。
そのうえで、**組織というハコモノとしてCCoEを新たに作る上では、差別化が重要なポイント**だろう、と判断しました。

## WHIにおけるCCoEのMVV
半年間を掛け、その過程でこれまで記載してきた学びを得ながら我々が定めた、弊社WHIのCCoEのMVVは以下の通りです。

### ミッション
**現場と経営・社会の架け橋となり、クラウドの適切な活用を促進することで、WHIのアジリティを高める**

### ビジョン
- **クラウド活用に必要な要素について、現場と経営が背景や目的を相互理解できている状態**
- **クラウドの簡単で安全な運用により、クラウド機能の利用に注力できる状態**
- **クラウド利用のコストの最適化とリターンの最大化を実現できる状態**
- **現場がクラウドの知識を持ち、クラウド活用を含めた最適な選択をできる状態**
- **上記を継続することで、全社員がそれぞれの本質的な価値創出に注力できる状態**

### バリュー
- **透明性を尊重する**
- **相手の「なぜ」を理解する**
- **プラクティスを皆でシェアする**
- **OODAループを実践する**
- **「事業部門によるCoE」として、現場へ寄り添い、負担を減らすことを第一とする**
- **自動化を含め、可能な限り長期的な低工数とエラーの低減を両立する**

まずミッションについて。
CCoEは日本語で「クラウド活用推進組織」と併記されることが多く、すなわち組織のクラウド活用の推進を担うことになります。がしかし、クラウド活用を何のために推進するのか、クラウド活用推進によって何を得たいのか、は企業ごとに異なります。**我々がミッションを定める上で、まず我々の活動によって最終的にWHIをどのように変えたいのか、を考える必要がありました。**
弊社はSaaSベンダーであり、顧客へのサービス提供基盤としてのクラウドプラットフォーム活用は国内有数の規模で、また社内でのSaaS活用も、開発環境・ツール、社内コラボレーションツール共に進んでいる状況です。そのため、活用の推進そのものではなく別の観点を持つ必要があります。クラウドの利用は既になされていて、クラウド・SaaSを活用する文化もある。すなわち土台はできているということです。
ではそこからの我々のミッションは？それを、**クラウド活用にまつわるWHIのアジリティを高めることと定義しました。** これがまさしく、次のビジョンに繋がります。

次にビジョンについて。
「クラウド活用にまつわるWHIのアジリティを高める」というミッションの通り、現場に対しては、**現場が使いたいクラウド・SaaSを迅速に使える、という状態**を作りたい。とはいえ新しいサービスを導入するには、**経営や社会が求める安全やリターンの明確化について説明ができる必要もあります。**
その観点から、ビジョン1つ目～4つ目を定義しました。
現場が安全やコストの最適化を担保できる、説明できる状態を作るための共通機能をCCoEとして提供したり、ルール・ガイドラインの解釈を伴走したりする。
そういった取り組みにより、現場が使いたいより最適なクラウド機能をアジリティ高く使えるようにし、より最適なクラウド機能の活用により、弊社製品の機能向上などの、本質的な価値創出に関するアジリティを高める。
こうした展望を描くことができました。

最後にバリューについて。
このバリューのポイントとして、**「事業部門によるCoE」として、現場へ寄り添う** というものがあります。ここは [MVVを考える上で重視したポイント](#mvvを考える上で重視したポイント) で先述した差別化のポイントでもあります。
社内の他の横断組織にも、それぞれ現場の業務のブロッカーにならない、や現場の事情を熟知し協働する、というようなバリューや行動指針を掲げている組織はあります。が、横断組織としての歴史が長いこともあり、現場における実際の困難を、理解し共感・実感したいと思ってもしきれない、というジレンマを抱えてもいます。
**我々は、現場部門発祥の、現場部門によるCCoEとして、顧客や社会に直接的に価値提供を行っている現場の負担軽減に特に力を注ぐことをベースの価値観として掲げました。**

**この差別化要素はミッション、ビジョン、バリューすべてに通ずるものでもあります。**
現場がステークホルダとの相互理解ができるように架け橋となる。その上で、現場がクラウド統制の重要性を分かったうえで、それを迅速に達成できるよう共通機能を提供する、コストの最適化とリターンの可視化ができるようにサポートする、世にどういうクラウド技術・機能があるのかといった情報に現場がアクセスしやすい状態を作る。
バリューである『「事業部門によるCoE」として、現場へ寄り添い、負担を減らすことを第一とする』を基本の価値観とし、ビジョンの実現のため、ミッション達成のため、活動するということです。

## さいごに
この半年間、CCoEとしてのタスクをこなしながら、並行してMVVの策定をはじめCCoE本格始動の準備を進めてきたわけですが、改めて実感したこととして、**CCoEの仕事というのは非常に泥臭いものです。**

コミュニケーションでは、縦と横、両方の架け橋……と言えればいいですが(笑)、板挟みになりながらどう調整するのかに腐心する。
自動化するほどの頻度ではなかったり、機械的なアプローチに対応しづらい細かい手動オペレーションを日々こなし、また作業手順を文書化しておく。
一つ一つ発見的統制のアラートのルールを書いていき、運用を試しつつ発報しすぎを調整する。
ガイドラインや台帳を文書化し、陳腐化しないよう更新し続けたり、定期的な棚卸を行う。
ガイドラインの社内の遵守状況を定期的に確認し、遵守状況がよくないチームがあれば事業を聞き改善を促し、進捗管理をする。
国・自治体・標準化団体等の動きや規格等の策定の情報や、クラウド技術をはじめとした幅広い面での技術の情報にアンテナを立て、必要であればガイドラインへの反映と社内での活用の両面について検討する。

などなど、例を挙げればキリがないですが！
こうした地道な泥臭い仕事であるからこそ、今後の活動の中で様々な悩みや壁にぶつかることも出てくると思いますが、MVVをこだわって作ったことは、そうした時に大きな意味を発揮してくれることと感じています。