pospomeがよくやる "組織の動かし方"

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`)

働いていると、複数のチームを横断したり、会社全体で「これやりたいな」と思うことがあります。 対象の組織規模が大きくなればなるほど難しくなりますが、 自分のやり方は一貫しているので、それを書いてみようと思います。

ザックリとして流れの説明

大体以下の流れで進めます。

  1. 勝ち筋を見出す。
  2. ステークホルダーを確認する。
  3. やりたいことをドキュメント化する。
  4. ステークホルダーにレビューしてもらう。
  5. 自らオーナーシップを持って進める。

上記の流れを見ると「普通のことじゃない?」と思うかもしれないですが、その通りです。 特別なことはしていません。 しかし、ちょっとした工夫が必要だったりするので、それも含めて説明しようと思います。

1. 勝ち筋を見出す

まずは自分がやろうとしていることについて整理します。 簡単に言うと "メリデメを整理して、実現可能かどうかを考える" になります。 自分はこれを "勝ち筋があるかどうか" という言い方をします。

勝ち筋は100%である必要はないですが、10%だと厳しい・・・。 どのくらいの勝ち筋で勝負しにいくかは、その人次第だと思いますが、少なくとも「やってみないと分からないけど、多分いけそうだな」くらいの勝ち筋があればいいでしょう。

ポイントとしては "実際にやってみてダメだった場合にどうなるか?" を考えることです。 リスクをゼロにできるケースは稀なので、可能な限りリスクを減らせないか? リスクを許容できるか? を考えることになります。 これを考慮しておかないとステークホルダーの承認を得られませんし、失敗したときのダメージが大きいです。

2.ステークホルダーを確認する。

やりたいことを実現するためのステークホルダーを確認します。

チームに閉じるものであればチームメンバー全員がステークホルダーになりますし、 部署に閉じるものであれば部長やEM陣がステークホルダーになりますし、 会社全体であればCTOや部長陣がステークホルダーになります。 ステークホルダーが多いと面倒なので、少ない方が良いです。

ステークホルダーが決まったら次のステップに進むのですが、 このタイミングでステークホルダーに口頭やSlackで雑に相談するといいかもしれません（必要であれば）。 ステークホルダーの中でも影響力のある人や理解度の高い人に対して「こーゆーことやろうと思うんだけど、どーですか?」みたいな感じです。 自分は勝ち筋が薄いものほど相談することが多いです。 ここでネガティブな反応が返ってきたら、Step1に戻って勝ち筋を再検討します。

3. やりたいことをドキュメント化する。

やりたいことをドキュメント化します。 ドキュメントと言っても、ペライチの軽いドキュメントです。 長々と細部まで記載すると時間がもったいないですし、誰も読んでくれないので、要点だけ抑えて可能な限り軽くします。

自分は大体以下を記載します。

1. やりたいことの概要を一言で
2. なぜやりたいのか?（課題の説明）
3. 具体的に何をするのか?（課題解決方法の説明）
4. ネクストアクション（何をどのような順番で進めるのか）

何度も言いますが、ペライチの軽いドキュメントで大丈夫です。 ボリュームのあるドキュメントは人に読んでもらえません。

そして、内容も完璧を目指す必要もありません。次のステップでステークホルダーにレビューしてもらいますが、そのときに "一度でも指摘を受けたらゲームオーバー" になることはありません。どーせ持ち帰って検討することになるので、"さっさとドキュメントにまとめて、レビューしてもらって、指摘された点を修正して、再度レビュー依頼する" という改善サイクルを回した方が良いです。

4. ステークホルダーにレビューしてもらう。

Step3 でドキュメントを書いたら、ステークホルダーにレビューしてもらいます。 レビュー依頼はSlackで「こーゆーことやりたいなーと思っていて、ドキュメント化したのでレビューしてコメントして欲しいです。」みたいな形でレビュー依頼を出します。 ただ、ポイントがいくつかあります。

ポイント1. レビュー期限を決めること

人間は期限がないとレビューしない生き物なので、具体的な期限を決めます。 祝日などを考慮する必要はありますが、期限はテキトーでいいです。 どーせ「xx月xx日までにレビューお願いします。厳しい場合はスレッドに連絡してください。」みたいに「厳しい場合は」という言い方をするからです。

ポイント2. レビューしない人は同意したとみなす

ステークホルダーが多ければ多いほど、"レビューしない人" がでてきます（特に普段から忙しい人）。 その人を待っても仕方ないので「特にコメントがなかった方は同意したとみなします」という一言を加えることがあります。

ただ、「この人には絶対にレビューして欲しい」という人がいたり、 レビューしてくれた人が少ないと実行に移した後に問題になったりするので、 そーゆー場合は頑張ってリマインドします。 というか、普段から忙しい人ほど重要なステークホルダーだったりするので、結局リマインドすることが多い気がします。

"レビューしない人が悪い" という考え方もあるかもしれないですが、 自分のやりたいことを実現するためのリスクは潰しておかなければいけません。

ポイント3. 決定事項ではないことを明示する

場合によっては「大事なことを一方的に決められた」という受け取り方をされてしまいます。 そーなると進むものも進まなくなるので「これはあくまで提案であって、決定事項ではないです」という一言を加えることがあります。 相手との関係値が薄い場合は、とりあえずやっておくと良いと思います。

ポイント4. 必要に応じて同期的に共有する

Slackで「レビューしてください」と投げるのもいいですが、その他の手段として以下のような同期的な共有手段もあります。

  1. ミーティングをセットし、口頭でドキュメントを読み上げる。
  2. ミーティングをセットし、スライドで発表する。

どちらのパターンも自分の口から伝えることができるので、 やりたいことに対する熱量を伝えることができます。

「熱量ってなんやねん」という気持ちになるかもしれないですが、 組織を動かすような意思決定は何かしらのトレードオフがあり、必ずしも勝ち筋の大きいものばかりではありません。 リスクを許容してリターンを取りに行く必要があるので、ステークホルダー全員を納得させるのは難しいことがあります。 そんなときに熱量高く説明することで、ステークホルダーも「そこまで言うならやってみましょうか」という気持ちになるかもしれません。 最終的に人を動かすのは、そういった気持の部分だったります（当然普段からの関係値も大事）。

"口頭でドキュメントを読み上げる" は、ミーティングの場でステークホルダーとディスカッションできるのがメリットです。 その場で説明して、その場でディスカッションして、問題なければ先に進めます。 レビューを待つ必要がないですし、ドキュメントのコメントによるラリーも発生しないので、リードタイムが短縮できます。

"ミーティングをセットし、スライドで発表する" は、大きな変化を多くの人に共有する場合に利用します。 会社の方針や部署の方針を大々的に打ち出す場合に、従業員の方々を集めて発表するようなイメージです。 大きなことをやろうとすると、影響する人たちも多くなるので、組織を混乱させないために、このようなパターンを採用します。 このパターンの場合は、Step3でドキュメントを書かずにスライドを作ります（もしくは両方作る）。 自分がDMMプラットフォームでプラットフォームエンジニアリングに取り組むときは、このパターンを採用しました。

5. 自らオーナーシップを持って進める

最後は "自らオーナーシップを持って進める" です。 人間は人から言われたことをやるようにはできていないので、自分のやりたいことを実現して組織を動かすには、自分がオーナーシップを持って進める必要があります。 ここが最も重要です。 これができないと組織は動きません。

よくあるアンチパターンは「みんなやってね」で終わってしまうことです。 大体みんなやりません。 頑張ってドキュメント化したり、ステークホルダーと会話したにも関わらず、自然消滅したり、形骸化します。

"オーナーシップを持つ" といっても、必ずしも "自分が手を動かして頑張る" というわけではないです。 組織に属する人たちが主体的に動かないと意味がないですし、そもそも自分が頑張ってどうにかなるものではないからです。

じゃあ何をするのかというと、"組織が意図通りに動いているかどうかをチェックする仕組み" を作り、 自分で状態を確認するだけでいいです。 必要に応じてテコ入れしましょう。

自分がよくやるのは "定例" です。 週一とか月一で定例を開催し、各チーム、各部署に人たちに状況を報告してもらいます。 上手く進んでいないチームや部署があれば、ヒアリングして、問題を解消します。 最終的には自分が定例に参加せず、自分以外の人たちで定例を運営していけるようにします（どのタイミングで自分が離れるかはケースバイケース）。

補足: "Disagree & Commit" を徹底できない組織は "詰み状態"

大きなことをやろうとすると全員が納得する方針を考えるのは不可能なので、"全員納得しないと進まない" という状況は "詰み" です。 そのような組織では、何も進まず、何も変化しないでしょう。

これを防ぐためには、組織全体として "Disagree & Commit" を徹底する必要があります。 これが徹底されないと "納得しないからやりません" とか "納得できないから取り組みを妨害する" という人がでてきます。 仮にこーゆー人がいた場合、当事者同士で直接コミュニケーションを取って説得しようとしても平行線で終わることが多いので、 その人の上司にエスカレーションするなりして対応しましょう。

補足: こーゆー動き自体を部下にやってもらう

今回紹介した方法は、結構自分で手を動かしてアレコレしているなーと思っていて、 この動き自体を部下にしてもらうと、いい成長機会になるのではないかと思っています（自分としても、その分の作業工数が浮く）。 自分の次のステップとしては、こーゆー動きを部下にしてもらう・・・になるのかなと、薄っすら思っています。

まとめ

今回は "組織の動かし方" を書いてみました。 重要なのは Step1 で勝ち筋を見出すことと Step5 でオーナーシップを持つことですかね。 ここらへんさえ抑えておけば、その他のステップはなんとかなると思います。

宣伝

株式会社カミナシでは以下のポジションをすごく募集しています。 興味のある方は応募してみてください。