【新規部署立ち上げ期最大の壁！】業務プロセス整備を半年間で完遂した方法
こんにちは。
株式会社スタメンのえりーです。
今回は第2回スタメンnoteリレー12日目の記事です🎶
第2回スタメンのnoteリレーについてはこちらをご覧ください👇
今月から、カスタマーサクセス部の部長を担当しておりますが、私の野望の一つにこんなものがあります。
「日本でSaaS事業のカスタマーサクセスをやるなら一度はスタメンに行っておけ！」と言われるチームに全員でなれるよう、プロセス・仕組みを整え、個々人の力を最大化したいです。
現在のチームのメンバーに向けては全員がプロセス整備について同じように考えられるように、まだ見ぬ仲間に向けては、（同じ組織でもそうでなくても）今悩んでいる誰かのヒントになれば、と思い、私自身がこの半年取り組んできたプロセス整備の具体的な進め方を改めてまとめることにしました！
この記事がおすすめな人
それなりに皆さんのお時間をいただくので、この記事がおすすめな人を書いておきますね。
・似たような困りごとに、自分もチームのメンバーも遭遇しているはずなのに、どこから手を付けていいかわからない人
・プロセス整備や改善は頑張っているつもりだが、思ったように成果が出ていない人
では、さっそく本題に入っていきたいと思います！
【Before】このお話の舞台になる部署の状態
今回私がプロセス整備を実施した部署は、新事業を立ち上げて約１年の部署。初年度があまりにもうまくいったため、一定のプロセスはあるものの、なかなか大きく見直しを図れるほどの時間も余裕もなく、全員が比較的勢いだけで突き進んでいた部分もあった。
しかし、市場の変化も見え始め、昨年と同じように業務に取り組んでも成果が出にくく、苦しい局面に突入し始めた。
誰もが「このままではまずい…」と感じていたところだった。
プロセス整備の考え方
上記のような状態になったときに、とにかく何とかしたくて「あれやってみよう、これやってみよう」とすぐにHow toを考えて走りたくなってしまう人も多いだろう。
１秒でも速く成果を出したい、その気持ちは「最高！」だけど、せっかく「（プロセスのツギハギではなく）整備」をするなら、走り出す前に一度じっくり立ち返ることで成果を最大化することができる。
プロセス整備も正しく行う「プロセス」がまたある。
他にもやり方は色々あるかもしれないが、一例として、私がいつも取り組んでいる考え方のプロセスを以下に記載していく。
プロセス整備、と書いているがいわゆる「改善」も同じステップで取り組むことができる（プロセス整備とは改善に他ならない）。
STEP1 全体像を書き出す
どのような範囲でもいいが、整備していく業務範囲の大まかなプロセスを洗い出す。その中で問題だと思っていること（整備されていなくて毎回苦労すること）をまずは雑にでもいいから洗い出す。
すでになんらかの取り組みがかなり進んでいたら別だが、そうでない限り、この時点では解決策（こうしよう、こうしたい）を書き出すのではなく、困っていることや現状などの「事実」を書き出す。
解決策を書き出せば、すぐに動き出せるじゃないか！と言われそうだが、ここはグッと我慢することをおススメする。
なぜ、事実を書き出すかというと、目的と手段をなるべく混同しないようにするためだ。
例えば、解決策の一つである「～のフォーマットを作る」などは、よくある整備の手法だが、困っている事実や全体のプロセスから考えなければ、以下のようながっかり整備にもなりかねない。
フォーマットはあくまで手段。困りごとが問題点が解決できれば手段はなんでもよいはず。
（どんなプロセス整備も、目的と導線を考えて設計することはかなり重要！基本的に、普段通らない道を通ったり、面倒なことをしたがる人はいない）
フォーマットを埋める作業が増えた
↓
前後のプロセスで使っているものとも違うツールを使っている
↓
情報もバラバラになり誰も見に行かない
↓
整備担当は「情報入れてくれ」とフォローする
（以下略）
STEP2 優先順位をつける
洗い出した項目の中のどこが優先順位が高いか（＝今の組織に必要か）を考えてみる。
ここも面倒なプロセスだが、残念整備のバッドエンドを迎えないためにグッと我慢することが必要だ。
優先順位をつけるときには以下の２つのバランスを考慮して検討するとよい。
１）効果の高さ
［例：検討するための項目］
・すぐに変化が起こる（目下既に困っていることへの対応）
・その業務・プロセスを実行する頻度が組織全体や個人で高い
・会社の利益（＝主に直接的な収益）に貢献しやすい
２）投入が見込まれる時間
［例：検討するための項目］
・個人で完結できそうか、できるとするとどのくらいの作業量になるか
・人を巻き込む場合どのくらいの規模（組織数）になりそうか
※多くなればなるほど説明などの付帯工数が増加し、撤退もしづらい
・整備するまでに使うツールは身の回りにある使い慣れたもので完結できそうか
例えば、手作業で売り上げ集計をしていてミスが多く困っている場合。確かにミスはよくない。一方で、そのミスはその部署の中で修正すればいいだけで、かつ、その部署が売り上げがなければ解散だった場合に、
「新しい売り上げシステムを入れよう！」
と１年間かかる全社を巻き込んだプロセス整備にとりくんでも、そもそもその手前で解散する可能性が高い。
このバランスのとり方は組織の安定度などにもよるので一概にいえないが、たとえば、今回私が取り組んだ際には新規立ち上げ部署だったのでとにかく時間をかけず効果がでるもの優先とした。
また、プロセス整備にあまり慣れていないような組織では、極力いろいろな人が整備による恩恵を感じ、協力を得やすくするため、最初はハードルが低くて「とりあえずやってみた」がわかりやすいものに取り組んでみるのもおすすめ。
STEP3 優先順位順にとにかく実行
説明が不要なレベルで「あとはとにかく実行！」
JUST DO IT.
STEP 3.5 とにかく実行が難しい人へのヒント
しかし、とにかく実行というけれど、こんな問題にぶち当たる人はいないだろうか？という２つのパターンへのヒントも書いておく。
■パターン１「時間捻出が難しい」。
わかる、めちゃくちゃわかる。
特に、仕組みを構築したりすることをしたことがない人にとっては、ハードルが高く感じると思う。
「時間がなかったから進みませんでした」の言い訳は特に使いやすいし、自分自身も使ってしまうこともある…。
そんなときに実行できる仕組みを自分のなかに整備するのもまさに「仕組みの力」！
忙しい中でもペースメイクするために、私がプロセス整備などぼんやりした仕事を実施する際にはかならず以下のようにしている。
［自分がサボらないための仕組み化］
・優先順位を付けたリストに必ず完了時期を記載する
・その完了時期はかならずほかの人にシェアする（宣言する）
・シェアした他の人に（必ずしも上司でなくてもOK。フォローが厳しい人がおすすめ（笑））レポートする場を、先に完了時期まで定期で作ってしまう
とにかく、コミットして、それが出来たかどうかを誰かに一緒に追いかけてもらう。
これだけでも随分成功確率は上がる。
■パターン２「何からしたらいいかわからない」
これもわかる。わかりみが深すぎる。
そんな時には、これまでSTEP1・2で実施したプロセスをもう一度やってみるとよい。
これまで書き出した項目をその中で起きているさらに小さな問題に細かく分割してみると、対策の糸口が見つかるかもしれない。
分割するときは更に細かいプロセスに分けるやり方もあるが、ある切り口から見つめなおしてみるのも効果的だ。
分割のイメージを架空のレストランのプロセスで書いてみた。
あえての手書き…（笑）だが、実際に私はこんな感じで付箋やノートに書いているのでそういう意味でのリアリティは多少あるかも？
大きな問題は「料理の作り方のばらつき」、ということだが、そのプロセスを整備するのはとても時間がかかりそうだ。しかもこれだけぼんやりしていると対応策を見誤る可能性も高い。
その問題をさらに細かく見てみると以下のような問題が見つかるかもしれない。
［例：問題を分割する際の視点］
・どういうケースでよく発生するか？
＜時期・時間＞
・季節のメニューなど特定のメニューで発生している
・ランチは発生しないけど、ディナーで発生している
＜人＞
・ベテランと新人では作り方に差がある
・男性と女性では作り方に差がある
（↑は作り方は同じように知ってでいても身長や力の問題がある可能性もある）
＜周囲の環境＞
・道具・材料の置き場所によって差が発生している 等々
作り方は全員同じように知っているけれど、実はそれ以外の事柄が作り方のばらつきを発生させている可能性もある。
それなのに、苦労して数か月かけて「レシピのマニュアルを整備しました！」では（意味がないわけではないが）時間のかけ方も効果面ももったいない。
こんな感じで、自分が「これなら解決できそう」というサイズに問題を小さくしていけば、解決の糸口やアクションの一歩目を踏み出しやすいし、効果も正しく出しやすい。
実際の取り組み
私が今回取り組みを実施した部署は、いわゆる「THE MODEL」型のファンクションを上流から下流まで持っている部署だった。
私はカスタマーサクセスの担当として入ったので最初は全てのプロセスがわからなかった。
従って、以下のように優先順位を付けた。
まずはカスタマーサクセスで明らかに躓きが発生しているプロセスに集中してプロセス整備を実施
・このプロセス整備を進めた時点では、チームがたくさんの時間直面するわけではないフェーズの問題については思い切って何もしなかった
・最初は１～２枚の資料の変化で変えられる、自己完結で実施できることに取り組み、段々と時間がかかる、チームの一週間のサイクルの構築や全体のマニュアル作成など明らかに時間がかかることに手を付けていった
次に、自分自身プロセスを学ぶ必要があるマーケティング・営業寄りの改善を進めた
・上の改善を実施すると、自分自身の日ごろのオペレーションにも時間の余裕ができ、チームも安定しだす。だからこそ、自身の担当業務でないチームのプロセス整備も実施ができるようになる（やはり優先順位づけは大事）
・ここでは主に営業資料の改定などを実施したが、この時は
①投資時間に対して使う頻度・効果が大きい「初回使用資料」
②お客様によって分岐が発生し、効果が分散する（かつ自身も学習コストが必要な）「２回目以降の資料」
の作成と優先順位を明確につけていくことで一つ一つの整備アイテムに集中して取り組み整備をすることができた
【After】起こった変化
ここで業務工数〇％減！と言えたらカッコいいのだが、一個一個の取り組みに関してはBeforeの状態を計測せずに実行したので（これは反省点）定量的な結果としては測れていない。
しかし、最初に書いた通り苦しい局面だったチームも、何とか変化後の環境でも戦っていける素地が作れてきた（もちろんそうなってきたのは今回のプロセス整備だけが理由ではないのだが）。
今回の整備における定性的な効果だと私自身が感じているのは以下の通りだ。
・自身がほぼ関与しなくてもチームが自走できる状態になっている
チームが何を追いかけていくのか、マニュアルと仕組み両面を整備することでメンバーが意識をできるようになったので、安心してメンバーに任せることができる
・プロセスや仕組みを整備することで、成果が出しやすい状態になるということを体感できた
意外にこれを感じる機会がない人もいるのではないだろうか？
個人的には、頻度の低いわかりにくいプロセスもマニュアル整備して無駄なことを覚えておくリソーセスが不要になったのがうれしい（笑）
今後の取り組み
「自分だけでこの取り組みをすべて実施した！」というつもりは全くないが、時間も限られていたのでかなりの部分を個人の力技で進めてしまったことは事実。
ありがたいことに、今回取り上げた部署よりさらに人数の多いカスタマーサクセスのチームを任せていただくことになった。
ここでも、正しい仕組み化に全員で向き合い、仕組みで生まれたリソーセス（余裕）で個々の力を最大限発揮しながら強くなっていけるチームをみんなで作り上げたい。…いや、必ず作る！
そんなチームの仲間になりたいなと感じてくださった方や、ここには書ききれなかった内容について聞いてみたい、という方、ぜひ一度カジュアルにお話ししましょう！
