■はじめに

1月に全社で参加する「ママチャリグランプリ」に向けて猛特訓中のCFO佐々木です。カップルで溢れる、恵比寿ガーデンプレイス周辺の坂を必死の形相で自転車で登っている人がいたら、おそらくぼくです。
※クラウドワークスでは全社イベントとして、毎年有志が集まってママチャリグランプリに参加しているのです。

さて、クラウドワークスコーポレートDiv.のアドベントカレンダーもいよいよ最終日、ということで、コーポレートDiv.（管理部門）に起こりがちな「城問題」を、エンジニアリングの手法をとりいれてみたら、解決できたよという話をしたいと思います。
管理系の仕事をされている方であれば一度は感じたことのあるであろう「あるある」を少しでも解決するヒントになれば是幸いです。

■「城問題」とは？

私自身、10年以上、様々なベンチャー企業の管理部門を見てきましたが、だいたい起こるのが「城問題」。具体的には以下の3つがあるように思います。

① 属人化という名の「城」
管理部門の業務はその専門性の高さや、様々な職務に分かれることから、一人ひとりに業務が属人化しがちです。管理部門を最少人数で切り盛りしなければいけないベンチャーにおいては特に起こりやすく、経理と財務、採用と労務など、複数の職務を一人でこなすこともざらにあると思います。

本人にその意図はなかったとしても、その業務を把握しているのは担当している本人しかおらず、やり方やノウハウは誰にも共有されることなく、個人にどんどん蓄積され、気付けば立派な「城」ができあがっているものです。
城の入り口や、内部の構造はその本人しか把握することができず、人も増えてきて、いざ業務分担だ、仕組化だ！となったときには、すでに難攻不落な城になっており、城を攻略するには相当なコストがかかるものです。

② 「城」同士の争い
上記のようにそれぞれの職務ごとに「城」が築かれていても、城同士がうまく連携できていればさほど大きな問題にはなりません。ところが、城の中身がブラックボックス化されているが故に、城同士の対立が起こりがちです。

たとえば、ある人事情報が共有されていなかったことにより、労務手続きや経理処理が遅れてしまったり、などといった連携ミスは誰もが経験したことがあると思います。その時に、相手側の業務フローや状況をきちんと理解していれば、まあ仕方ないな、とか、次同様のことが起こらないようにするためにこうしよう、といった提案もできるものですが、城の中身が見えないために、「なんであいつらはこんな簡単なこともできないんだ！」、「こっちの気持ちも知らないで！」といった感情が生まれ、対立構造が生まれていきます。

③ 「城」の外との争い
対立構造は管理部門の中だけではありません。管理部門の中でさえこんなに業務が見えず、対立が生まれがちなのに、各事業部との関係については推して知るべし、です。

事業部からすれば、管理部門は「管理」と名のつくものは全てやってもらえると思っていたり、管理部門からすれば、「なんでここまでやらなきゃいけないんだ」と思うこともよくあります。

「城」に例えて説明をしましたが、このように管理部門を運営するうえで、「業務属人化」「管理部門内の連携」「事業部との連携」は切っても切り離せない、大きな問題だと考えています。

■エンジニアリングの手法を取り入れた理由

クラウドワークスは、創業から3年でマザーズに上場し、また業績としても人員数としても急激な拡大を続けてきました。その中で、管理部門の構築は後手後手にまわり、上記に挙げたような「城問題」は日に日に大きくなっていました。

そういった状況をどう改善していくか。考えた結果、エンジニアリングの手法を取り入れてみようという決断にいたります。なぜエンジニアリングの手法を取り入れたのかというと、当時クラウドワークス社内で、エンジニアチームがもっとも「チームづくり」に力をいれていて、かつそれが上手くいっていた、ということが前提にはありますが、管理部門とエンジニアチームには以下のような共通点があるということが大きいと思っています。

＜エンジニアチームと管理部門の共通点＞　
　① 業務の専門性とその複雑性が高い　
　② 他部門との調整が必須　
　③ 状況に応じて変化が大きい　
　④ 業務が集中する時期とそうでない時期の差が大きい

上記を考えると、マネジメントとしては「すべてを把握する」ことはほぼ不可能で、トップダウンでは機能しなくなります。いかに各メンバーが主体性をもって自律的に動けるような環境をつくれるかどうか、課題がいかに現場から上がり、解決することのできる組織になっているかということが重要になってきます。

■なにをやってどう変わったのか

2015年10月、コーポレートDiv.の2016年9月期コンセプトとして「城から街へ」を掲げ、属人化した「城」を壊し、チームとして機能する「街」をつくっていくことを打ち出しました。

そして、エンジニアチームで取り入れていた手法をいろいろとコーポレートDiv.に取り入れ、実行に移しました。具体的にやったことと、それによってどう変わったのかは以下のとおりです。

① チームをつくる
■やったこと：
まず最初にやったことは、「チーム」をつくること。
「チーム」をつくる？そんなこともできてなかったの？と思うかもしれませんが、チームをつくるというのはそう簡単ではありません。
チームには、「共通となる目的」があり、「全員がそこに向かっていること」が必要で、ただ集まっただけではチームとは言えません。

当時、クラウドワークスのコーポレートDiv.は、優秀な「個」の集まり、という感じでしたが、いくつかのグループに再編を行い、「チーム」づくりを開始しました。

■どう変わったのか：
「チーム」ができると、すべてが変わっていきます。
それまで一人に閉じていた業務も、チームになることでメンバー同士で気軽に相談したり、そこから連携が生まれたりしていきます。ただ、本当の意味で「チーム」になるためには、以下にあげるような取り組みが必須になると考えています。

② OKRの導入と定期的な見直し
■やったこと：
OKRは目標設定の手法の一つですが、「チームとしての共通の目的（どこにむかっているか）」を明確にするために、他のチームメンバーが「あのチームはどこに向かっているのか」を理解するために導入をおこないました。

OKRを導入するうえで大事なことは、　
・会社全体・部門全体のOKRをもとに、チームが主体的にOKRを設定すること　
・OKRはその進捗も含めて見える化して全員に共有する　
・変化に合わせてOKRを適宜見直すということだと思います。

特にやってみて思うのは、OKRの見直しの重要さ。変化の大きい部門だからこそ、定期的な見直しは必須だと考えています。

■どう変わったのか：
まずチームとしてどこに向かうべきか、を議論して決めることで、「共通の目的」ができ、一人ひとりがその目標を「自分ごと」化するようになったと思います。
そして、OKRを共有することで、となりのチームの業務についても理解が進んだことで、連携がスムーズにできるようになったと思います。

③ スクラムの導入
■やったこと：
おとといのCIO大場さんの記事に詳しいのでこちらも併せて読んでいただければと思いますが、スクラムとよばれる手法を導入しました。
まずは、OKRに沿って毎週のタスクを見える化して共有、計画を立ててチームですすめていくのですが、重要なのは、毎朝の朝会の実施と振り返り。

朝会でその日のやることや課題を共有し、週次でKPTをつかって振り返り、Keep（よかったこと）、Problem（課題）、Try（次に試したいこと）を一人ずつ付箋に書き、発表、チームで議論していきます。

ポイントは、チームメンバー一人ひとりが思ったことを率直に伝える、言える場をつくること。

■どう変わったのか：
チームが機能するようになったという点で、朝会の実施やKPTをつかった振り返りが最も効果があったように思います。最初はぎこちなく、あまり意見を出さなかったメンバーも、回を重ねるごとに意見を出すようになり、活発な議論が起こるようになってきました。

また、チームごとに適したやり方というのも異なりますし、朝会や振り返りのやり方自体も変化し続けることが重要。バーンダウンチャートを導入したりなど、やり方は適宜見直しながら、各チームで最適なやり方を模索し続けています。

■まとめ

まとめると、この1年以下のようなことを試行錯誤しながらやってきました。　
　① まずは「チーム」をつくる　
　② 共通の目的となる「OKR」を設定、共有　
　③ 「スクラム」を導入し、OKR達成に向けてチームで取り組む

結果としては、
・属人化されている業務はまだまだあるが、お互いの状況や課題が可視化されるようになった　
・課題が適宜上がってくるようになり、チームで解決にあたることができるように　
・チーム内で、「率直に言える」環境ができた　
・つねに変化に挑戦し、変化し続けるチームになった
という感じで、「城から街へ」という点では、一定の成果はあったかなと思っています。

とはいえ課題はまだまだ残っています。
特に事業部との連携、という点ではやるべきことは盛りだくさん。コーポレートDiv.の2017年9月期コンセプトとしては、「事業に貢献する、かつてない視点を」を掲げ、より事業成長に貢献できる管理部門を目指して日々チャレンジをしています。

まだまだやりたいことだらけ！クラウドワークスでは、一緒にいいチームをつくっていきたい！という方からのエントリーをお待ちしておりますー！