必然的な事業成長を導く「組織のファシリテーション」

LAPRASで事業責任者をやっている染谷です。
弊社の提供するLAPRAS(https://lapras.com/)でもnoteとの連携が始まりつつありますので、僕もnoteはじめてみます。
書きたいことを気ままに書きますが、少しでも皆様のご参考になれば幸いです。

さて、この記事では、僕が組織のアウトプットを高めるために取り入れている考え方をご紹介してみます。

LAPRASでもこの考え方に基づいて、僕が事業責任者になった5月から組織をリファクタリングして、特に6月・7月は大きく事業を推進させることができました。今も継続しています。
ちなみに前職で様々な新規事業をやっていたときも、これに似た考えで事業推進スピードが上がったので、少なからず汎用的な考え方かと思います。

事業の推進スピードを上げたいときや、どうも各役割（チーム・部署）の頑張りが成果に繋がらないなと思ったときなどに取り入れて下さい。
（初めてのnoteなんで、素人感満載だと思いますが、興味ある方はお付き合いください。）

事業組織は必然的に価値を生産するべき

事業にはお客さんがいて、そのお客さんに価値を届けることで対価を得られます。
そのために、事業組織は価値を生産し続けなければなりません。
そして、価値の生産量をどんどんと肥大化させていかなければなりません。

事業組織において、この価値の生産プロセスがどのようになっているかはとても重要です。
うまく価値を生産できていない事業組織では、価値の生産プロセスが偶然性に依存していることが多いです。
価値の生産プロセスが偶然性に依存すると、価値の提供にムラが出ますので、事業がうまく行かない期間が生じます。

事業を必然的に成長させるためには、偶然性に左右されない価値の生産プロセスを組織内に持たせることが重要です。

ここで言っている価値の生産プロセスとは、顧客に提供するものがどういう順番で各組織をたどって、その際に組織間で何が渡されて、最終的に顧客に届くのかという流れです。

例えば、LAPRASのプロダクトに関しては、最終的に顧客に届く機能を開発しているのはWebAppチームですが、その手前でAlgorithmチームやCrawlerチームがその前段階となる開発をしてWebAppにイシューを渡していたり、プロダクトマネジメントやUXデザイナーが仕様の決定をしてWebAppにイシューを渡していたりします。

※弊社のプロダクトづくりは、ざっくりこんな感じでアウトプットが流れていく。

この各役割がどういう順番で仕事をしていて、次の役割に渡る際に何を渡しているか（これれをこの記事では価値の生産プロセスと呼びますが）が非常に重要です。

重要となる「組織のファシリテーション」

事業がうまく進まない場合は、この価値の生産プロセスに問題が発生していることが多いです。
しかし、ここに問題が生じていても、各役割から見える視界は限られているものなので「頑張っているのに、なんでうちの事業はうまくいかないんだろ？」というふうに見えてしまいます。

そこで、事業責任者や経営者などの事業を俯瞰して見るべき役割こそが、この問題を直しに行かねばなりません。
そのために、組織内の各役割間の仕事の順番や、各役割間で渡されているものを整備する必要があり、これこそが「組織をファシリテーションする」ということです。
（ちなみに、「組織のファシリテーション」という表現はあくまで僕が個人的に使っている表現で一般的ではありません。）

※なお、ビジネスにおける「ファシリテーション」という語が指すものは、ただ場を仕切ることではなく基本的に問題解決の土台をつくることだと僕は認識しています。まあ、それは改めて。

組織のファシリテーションの目的は、以下の２つです。
・各役割の頑張り（アウトプット）がより確実に顧客に価値として届くようにすること
・各役割の頑張り（アウトプット）がより早く顧客に価値として届くようにしていくこと

要は、”早く””確実に”各役割のアウトプットが顧客に価値として届くようにすることです。
これは、組織に所属しているメンバーの持てる力がちゃんと事業に反映されることでもあります。

そして、組織のファシリテーションを行うことの大きなメリットは金銭的なコストを一切かけずに、しかも短期で組織が生産する価値が増えることです。実際にLAPRASのアウトプットも、この取り組みを行ってわずか1ヶ月で大きく改善しました。
（一方で、1ヶ月やれば完了するものではないので、その後の伸びを作るためには継続的に取り組んでいく必要があります。）

なお、どの役割のアウトプットでも最終的に顧客に届かないものは、そのアウトプットにかけたリソース（時間・コストなど）が一切の無駄になってしまうことなので、このような悲劇は避けなければなりません。

各役割のアウトプットが高い確率で顧客に届くように役割間のインプット／アウトプットを整備していかないといけないのです。

もちろん、ある程度の失敗は許容した方が素早く学習ができ、最終的に顧客に届くものの価値が上がるので、そこはバランスが重要です。ただし、失敗を許容する目的は失敗することではありません。空振りを何度重ねても打率（まあ、打率よりOPSのほうが重要ですが）が上らなければその空振りになんの意味もありません。

組織のファシリテーションを通じてどのように事業を改善するか？

さて、役割間の流れを価値の生産プロセスだと理解すると書きました。
また、組織内の各役割間の仕事の順番や、各役割間で渡されているものを整備する必要があり、これこそが組織をファシリテーションすることだと書きました。
ではこれらを具体的にどのように組織改善につなげていくのかについて書いていきます。

改善のプロセスは①現状理解、②課題抽出、③課題解決という順番で流れていきます。まあ、オーソドックス問題解決の流れです。
ただ、組織をファシリテーションするという視点で見ていくと今まで見えなかった問題が見えるようになります。
以下では、この考えに基づいた①現状理解、②課題抽出のやり方について述べていきます。
③の課題解決については、課題さえ特定できればその内容に応じて対処すればいいのでここでは述べません。

現状理解でわかる現状の複雑さ

現状理解のためにおすすめなのは簡単な役割間の流れを図にすることです。
最終的に顧客に届くものは、どこからその種が生まれて、それが誰に渡されて、最後どう顧客に届くようになっているのか。この順番を図にします。

それを、プロダクトを改善したいのならばプロダクトについて、マーケティングを改善したいのならばマーケティングについて図にしていくのです。

役割間の順番がわかれば、粒度は先ほど見せたこのような図で構いません。この図はまず自分自身の認識が表現できていればそれで充分です。

※ざっくりだけど、まずはこんな感じで充分。

そしてその上で、ただ順番を理解するだけではなく、具体的に何が役割から役割に渡されているのかを理解していく必要があります。
例えば、PdMからWebAppに渡される機能開発の内容はどういう内容で渡されるのか？どこまで具体的なのか？Mtgで渡されるのか、非同期で渡されるのか？など具体的な内容を確認していきます。

そのためには、各役割へのヒアリングや、実際にMtgの場に同席することによって情報を得ることが最も有効です。そして、多くの場合、自分が思っていたより複雑なプロセスを経ていることに気づかされます。

例えば、WebAppの作るものはPdMから渡されているものだけではなく、WebAppからも開発イシューが上がっている、や、Crawlerからの連携案件とAlgからの連携案件とPdMからの連携案件では全くもらい方が違うなど、現実がいかに自分の理解していた図より複雑になっているかを目の当たりにするのです。

さて、ここまでは現状把握です。その上で、②課題抽出を進めていきます。

課題抽出の重要なポイント

複雑な現実を見に行くと改善しなきゃいけないポイントは無数にあるように感じます。しかし、すべての解決には多大な時間が必要なので、レバレッジの効くものから解決せねばなりません。

この考え方で組織改善するときに重要なポイントはこの2つです。この２つを頭に入れておくとレバレッジの効くものを見つけやすいです。

・顧客への提供物から一つ一つさかのぼって考える
・役割と役割の繋ぎ目は注意深く確認する

顧客への提供物を一つ一つさかのぼって考える

目的は事業進捗の改善です。そして事業進捗に改善の余地があるというのは、極論、顧客に提供しているもの（プロダクト、情報など）が悪いのです。
そして、この提供物がなぜ悪いのかを一つ一つアウトプットのプロセスをさかのぼって考えていくと、改善ポイントが浮かび上がります。

例えば、プロダクトが悪い＞バックログが悪い＞イシューの作られ方が悪い＞…とさかのぼっていて、適切な介入ポイントを決めるのです。

ちなみにこれは余談ですが、プロダクトを提供する会社ではやはりプロダクトが大事で、もし、プロダクトが良くなっていない印象があれば、まず実装される前のバックログを眺めましょう。なぜなら、プロダクトが良くなっていないのは必ず、機能化される前のバックログが悪いのです。

バックログが悪いというのは、優先順位の付け方が悪いのか、イシューの作られ方が悪いのですが、結局、バックログに並んでいるイシューを見て「濃さ」とか「今よりものすごく良くなる期待」を感じられなければ、良いプロダクトなど提供できようがありません。

※社内で全然リアクションが取れなかった例えですが、バックログには常にワールドクラスが控えてないといけません。

役割と役割の繋ぎ目は注意深く確認する

もう一つ大事なのは、役割と役割の繋ぎ目です。役割を分けるというのは生産性を上げる一方で、工夫しないとアウトプットの滞りを生みます。
特に重要なのは同じ役割を持つチーム内の課題を解決するのは比較的簡単な一方で、2つのチーム、３つのチームにまたがるような課題になった瞬間に解決可能性が恐ろしく下がります。

こここそ、事業を俯瞰して見るべき役割の人間こそが直すべき箇所です。そして、この役割の繋ぎ目で起きがちなのは、例えば以下のような問題です。

弊社では、機械学習や自然言語処理をおこなうAlgチーム（いわばR&D的な役割を担ってています）から渡された案件をWebAppチームがサービスに反映しています。

ところが、実態はAlgチームからの案件の実装確率は低く、Algチームは「なぜ、あの案件が実装されないのか？」と思い、一方でWebAppチームは「Algから来る案件、インパクトが不明瞭で優先順位が難しい」と思っていました。つまり、Algチームのアウトプットはほとんど実装のパイプラインに乗っていなかったのです。

役割が分化していくにつれて、このようなアウトプットの滞りが役割の繋ぎ目で発生します。アウトプットの変更や、役割を修正、間に役割を挟むなどによって、アウトプットの滞りを解消し、顧客に提供されるものに繋がるようにスムーズに流していかなければなりません。

このように顧客に提供しているものに近いところの悪い箇所や、役割間の停滞を直していくことで、各役割のアウトプットが漏れなく繋がれていき顧客に対する価値の生産プロセスがスムーズに回りだすのです。

まとめ：社内のアウトプットは顧客に届いているか？

ここまで、組織をファシリテーションするという考え方とその考え方を通してどのように課題が抽出できるのかを概論としてお伝えしてきました。
気が向いたら、この考え方で具体的にLAPRASの何をどうして、どう改善されたのかも書こうかなと思っています。

いずれにせよ、事業において行われることは何事も顧客に届かないと意味がありません。最終的に顧客に提供するものに寄与しない時間など無意味です。
そして、それはただ顧客に届かないだけでなく、顧客の反応を見て学習する機会すら失います。

もし、社内の特定の役割のアウトプットが最終的に顧客に届いていないのであれば、顧客に取って、自社のメンバーにとっても大問題です。
こういったときには、現場任せにせず事業責任者や経営陣が問題解決に動くべきだと思います。

以上、ここまでお読み頂きありがとうございました。少しでも皆様のご参考になれば幸いです。

ちなみにもしご興味あれば、弊社のLAPRAS( https://lapras.com/ )でご自分のページも覗いてみてください。Twitterアカウントがあれば、簡単（無料）にログインできます。
今は転職するつもりがなくても、自分に興味を持ってくれる会社を貯めていくことができるので、中長期的なキャリア形成を支援できるサービスです（し、そういうサービスを目指しています）。