新規事業開発の実務

どうせすぐ忘れるんでしょ\(^o^)/

超短期でのオペレーション業務立て直しメモ

f:id:naoto111:20180803091757p:plain

お世話になっております。
NORELの直人です。

先日、「事業責任者から、CS担当になりました」というエントリに記載したとおり、もっぱら先週まではがっつりオペレーションとCSの部分を見ていました。

NORELのオペレーション・CSは正社員の他にアルバイトや時短社員を含む小規模な組織で、スタートアップということもあって暗黙知も多く、経験豊かなメンバーが回しているものの整理・効率化されているとは言い難い状況にありました。

今回は約2週間程度と期間を区切って、できるだけの改善しました。小規模なチームの運用改善はGREE時代にメディア事業の立て直しを経験していたこともあり、混乱はあったものの比較的手戻りなく進められたと思います。

誰かの役に経つかもしれないので、書ける範囲内で流れをメモしておきます。

前提

以下のような組織の業務効率化 (ひいてはコスト削減) を、2週間という短期間で行う。

  • 10名未満の小規模なチーム
  • 運用は回っているが、業務は忙しく稼働率は常に100%近い
  • 担当しているサービスは立ち上げ期で変更が多く、業務フローの変更が頻繁
  • 暗黙知が多く、誰かが抜けると混乱が生まれる

流れ

  1. 状況把握
  2. 改善
  3. ずっと改善

 

1. 状況把握

何はともあれ、まずは現状を把握します。以下のようなことをします。

  • 担当者ヒアリング (1on1)
  • 業務内容の網羅的で定量的な把握
  • 業務フローの把握

1-1. 担当者ヒアリング

担当者ヒアリングは重要です。業務改善が目的ですが、精神状態やストレスの確認、人間関係などを見ます。もちろん、何をやっているのかといった具体的な業務内容をヒアリングします。

また、実務上のキーマン・意思決定上のキーマン・精神的支柱となる人物を探します。これは「だれの話を聞くべきか」を決定する上で重要です。基本的に、忙しい組織に属するメンバーは「他人のことはよく見えているが、自分のことは正しく判断できない」ような状況にあります。

今回のケースでは、ヒアリングの中で「あいまいな意思決定 (判断すべき人間が即断即決しないために問題解決までの時間が伸びる)」「暗黙知の弊害 (担当性をしいていたために、担当者欠勤時の引き継ぎなどがうまくいかない)」「アラートの欠如 (作業の抜け漏れを検知できない)」などの問題が浮かび上がりました。

また、チームメンバーは疲れており、担当者の増員を祈る状況になっていました。通常、利益に直結しない間接部門の増員は改善をやり尽くしてからになるため、建設的な改善策が進んでいない状況では増員要望は「祈り」に近いものになります (要するに、人を増やしてもらえません)。

1-2. 業務内容の網羅的で定量的な把握

続いて、業務内容を定量的に見ていきます。

忙しい組織の改善なので仕事を増やさないことが大前提となります。「業務量を定量的に把握するから、毎日仕事内容を細かく報告してください」のようなやり方では現場は反発し、時間がかかり、忙しい状況がより悪化します。

今回は、①キーワードや期間毎にメールのやり取りを分析する (Gmailの検索演算子が便利)、②担当者が業務で入力しているスプレッドシートを集計する、③電話の通話履歴からインシデントあたりの通話時間を見る、といった方法を採りました。

もう一つのポイントは、最初から深掘りしないことです。まずは全体像を広く浅く調査し、深掘りするポイントを決めます。問題がありそうなところを手当たり次第に見て、順次解決していくと、重要な改善点が後回しになり、時間のロスが生まれることになります。

結果的に、通常の業務フローに含まれない外部からの質問や問い合わせが非常に多く業務を圧迫している実態や、個人間の業務量のバラ付き、ミスによる手戻りが処理時間を増加させ、スタックすることで時間を追って雪だるま式にタスクが増えている様子などが把握できました。

1-3. 業務フローの把握

業務フローを把握します。

ここでのポイントは、マニュアルや管理画面など実際のツールを使って、実務の流れを順に追っていくことです。担当者にとっては当たり前の仕事でも、「なぜこんな非効率なことを!?」「これはあとで忘れそうだ・・・」など外部の人間ならではの気づきがあります。非効率な仕事には、そうならざるを得ない歴史的な背景があることが多いのですが、「今となっては必要のない、慣習的な流れ」を排除していくことは簡単かつインパクトの大きい業務改善になります。

NORELのオペレーション業務では、在庫車両の保有者・納車店舗・整備工場・行政書士・コーポレート部門などのステークホルダーが多いため、連絡と進捗確認が多く発生し、複数顧客のフローがパラレルで進行する非常に複雑な流れになっていることがわかりました。

 

2. 改善

課題をおおよそ把握したら、改善に取り掛かります。重要なのは、運用フローを止めないことです。

クラウドのシステムをいじる時は二重化して裏側で作業し、改善作業が完了したら一瞬で切り替え、その場でチームに告知する。表現は現場の用語を使って話し、正確さにはこだわらない。例えば、NORELのオペチームは「印鑑証明と車検証登録の委任状」のことをセットで「謄本」と表現する。一般的に謄本というと登記簿謄本を表すが、そんなことにこだわるよりも郷に入っては郷に従うのがスムーズだ。

改善点は、重要度とコスト (改善にかかる時間やお金) の二軸で評価し、重要かつコストの安いものから着手していく。

2-1. 意思決定

即効性があり、成果の上がる改善は「意思決定」で済むものだ。特に「やらないことを決める」のは時間的なコストがゼロで、効果もあがります。

「それはやらなくてよい」

「必要だけど、今じゃない」

「それは外部化しよう」

ヒアリングや文書でのやり取りから、オペレーションチームの意思決定は慎重で正確さを求めるリーダーのもと十分な材料と時間をかけて吟味されてきました。意思決定がされないまま、保留にされている改善点や、「必要ないとは言い切れない」というような曖昧な判断から、結果的に現場担当者に丸投げされているものもありました。

そういったものを即断即決に変えるだけで現場はずっとスムーズに回り始めます。「みんなで話し合ったけど答えのでないもの」などもリーダーが決断すべき事項。ただし、「現場で判断すべきこと」までリーダーが判断してはいけません。そういった場合「どっちがいい?」「◯◯さんの判断で決めていいよ」と決断を促すようにして、「その重要度までは、あなたが決めるべきものだよ」という基準を伝えていきましょう。

 

2-2. 定量化の自動化

分析のフローで作業の定量化を行いましたが、改善のプロセスではそれを自動化します。改善作業を仕組みとして永続化するためです。

自動化といっても難しいものではなく、業務でExcelを使っていればそれを集計するシートや関数を作ればよいですし、メールならフィルタなどの設定で時間をかけずに行えます。

ただ、NORELの場合は業務フローが複雑だったため業務で使っているシステムの改善は非常に苦労しました。あるデータを、暗黙的に別の事業部で参照しており、依存関係が壊れると業務に支障をきたしたり、裏側でプログラミング言語が絶対参照しているせいでフロー改善にテストやデバッグが必要だったり、といっった地雷が至る所にありました。

今回は、私が元々プログラミング経験があったことから自分で全て修正しましたが、業務とシステムを両方わかる人間がいない場合はエンジニアが業務を理解しながらやるのがよいでしょう。エンジニアは物事を抽象化したり、共通化したり、整理したりということを日常的に行っているので、こういった業務を行うにはうってつけの思考回路をしている人物も多いはずです。また、無駄なことがキライな気質もプラスに作用するでしょう。

一方で、オペレーターのような「物事を、正しく、正確にこなす」ような考え方は業務改善には不向きです。そういった人は、複雑なものを複雑なまま、正確に仕組み化したりしてしまうでしょう。

 

2-3. 「チェック」の自動化

日々の仕事が自動的に生成されるようになったら、抜け漏れやすい業務にアラートを入れていきます。

「◯◯の作業をしてから、◯◯日間ほったらかされていたらアラート」

「名義が◯◯名義の時は、◯◯のフローにいくため関係ない業務をブラックアウト」

こういった、条件分岐やルーチンはシステムが得意な部分だ。現場に、普段どんなことを気にしているか、これまでどんなミスがあったのかをヒアリングして、できる部分からどんどん自動化しましょう。

こうすることで管理者の仕事も楽になります。

「◯◯さん、◯◯の業務が◯日遅れているね。どうしようか。」

「◯◯さんに業務が集中しているから、だれか手伝ってもらえないかな。」

といった判断が容易になります。

また、業務量や期間が可視化されると、現場もスピードに意識が向くようになります。漠然と「最近仕事が多くて忙しい、なんとかしなきゃ!」と思っている状態から、「◯◯の仕事が◯◯件もある!早くしなきゃ!」「さすがにこれは無理だ、上司に報告しなきゃ!」という判断ができるようになります。上司も、部下が漠然と忙しがっているより、数字で見えた方が経営にリソースをリクエストしやすいでしょう。

 

2-4. 優先順位を決める

スタートアップに限らず、どんな事業でも常に人や予算といったリソースが潤沢にあるわけではありません。限られた予算の中で、顧客満足や事業の収益性を最大化するために、どこに注力すべきか。何に注力しないのか、を決める必要があります。

これもマネージャやリーダーの仕事です。

NORELのオペレーションチームは、顧客満足の最大化を重視するあまり、サービスにほとんど関係のないような質問にまで徹底的に回答するような文化をもっていました。これ事態はすばらしいことですが、結果として、お金を払ってくださるお客さまへの対応がなおざりになるようではいただけません。

作業の優先順位を明示し、サービスを必要としない方へのサポートは大胆にカットしました。

 

3. ずっと改善

ちょっとは落ち着きましたが、まだ終わらない。

日々改善、改善、改善。です。

 

やってはいけないこと

安易にやってはいけないことを、思いつくだけ挙げてみます。

  • コストの単純な外部転嫁
    • 間接部門の業務改善でありがちです。つまり、中の人の作業を減らすために、外の人の作業を増やす、ということ。以前勤めていた会社では「社用携帯電話の紛失管理が煩雑だから、携帯をなくしていないか、毎月持ってきてもらおう」という施策をやりました。管理部門は楽になりましたが、大勢の社員が毎月報告書を書いたり、管理部門に赴いたり、トータルコストはむしろ増えました。C向けビジネスでは中の人の手間を増やすためにユーザーの仕事を増やすなどで、これは論外です。
  • 根本解決
    • 「これは根本的に業務フローを作り直す必要がある」「システムを作り直す必要がある」など。完璧主義なマネージャや、コンサルタント、エンジニアなどは不完全な業務フローを許せないためこのような提案になりがちです。業務改善は「素早く、確実に」やる必要があるため、このような長期施策を行うとしても平行して場当たり的でも短期改善を行うべきです。
  • 馴れ合いと予定調和
    • これは私もすごく苦手なのですが、無駄を省く過程ではメンバーや業務委託、外注業者などをばっさり変えないといけないことがあります。こういう意思決定だけは、外部のコンサルタントになったつもりでドライに動く必要があります (精神的には人事が一番疲れます) 。

最後に

およそ2週間とちょっとの間、プロモーションやマーケティングをほとんどほったらかして、オペレーションやカスタマーサポートに注力してきました。

これまでは現場に任せていた、興味を持ってくださったからの質問にメールや電話で直接答えたり、クレームに発展させてしまったお客さまに謝罪したり、クルマの専門的な質問へチームのみんなの力を借りながら回答したりしました (とにかく手が足りなかったので)。

短い期間でしたが、ある程度の合理化と、注力すべき部分の選択と集中、組織の最適化はできてきました。ただ、これはあくまでも大きな問題がいくつか片付いただけで、引き続き運用改善の努力を続けていかないといけないのは言うまでもありません。

 

この仕事を通じて、オペ・CSの人たちがNORELというサービスにとってどれほどかけがえのないのかがわかりましたし、お客さまがどんな気持ちでサービスを見ているのか、リアルな肌感も得られました。

 

サービス改善という意味では、まだマイナスをゼロに近づけている段階で、ゼロからプラスの領域に早く持っていかないといかんな、と改めて強く感じました。

納車日を、最短24日からもっとずっと短くする。必要な書類をもっともっと減らす。入力の手間を短くする。審査を簡単にする。検査を徹底する。不要なコストを下げることで必要なメンテナンスをもっと充実させる。やるべきことはまだまだあります。Car as a Service として、クルマ本体よりもむしろこういった付加価値がサービスの価値になっていく。

 

これらを実現するには、今回紹介したような実務的なプロセスも大事なんですが、それ以前に「意識」。そういう意識をチーム内に育んでいかないといけない。自分は、実はそういう「人」や「気持ち」に関することがとても苦手で、これまで割りと避けてきた部分がある。これからはちゃんとそういう意識についても表現していきたいと、考えています。

 

最後にですが、そういう部分を引き受けてくれる、顧客満足責任者的な、サービス向上責任者的な人を探しています。想定年収600万くらいかな。われこそはと思う方、いらっしゃいましたらぜひご連絡ください。