仕組みはつくるだけでは動かなかったーーCSの私が社内BPRとBizOpsを兼任する理由

この記事は、「現職経験」を通じて、CS業務と社内BPR・BizOpsを兼任することになった経緯と考え方を紐解いたストーリーです。

きっかけは「つくった仕組みが使われない」という壁

最初の基幹システム刷新が一段落し、段階的なクラウド移行が始まろうとしていた頃のことです。

周囲がまた新たな混乱に直面していた中で、私が直面した一番の課題は意外なものでした。

それは、「作った仕組みが守れない人がいる」という、ヒューマンエラーでした。

• 何度周知しても、何度指摘しても、改善されない部分がある。
• どんなに綺麗な仕組みを組み立てても、ボロが出てしまう。

とくに、多くの問題を生み出したのは、システムモジュール間の接合点。
従来のオンプレな仕組みと、クラウドのつなぎ目には多くのブラックボックスがあります。

私たちの環境では、システムにデータを入力する初動にて、誰がいつどのようにやるかのルールが曖昧なまま運用されていました。

その結果、無形商材である自社サービスのオンボーディングに必要なデータ基盤が崩れ、業務に支障をきたし、CX低下やチャーンの種となってしまったのです。

「伝えた」は「伝わった」ではない

このとき読み返したのが、以前ご指導をいただいたCTOに勧められた
『エンジニアリング組織論への招待』（広木大地）です。

エンジニア挑戦当時の私は「理想ばかり高くて生産性のない設計やプルリクしかできてない」と感じていた時期があり、その処方箋として渡された一冊でした。

書籍にはこう書かれています。

コミュニケーションというのは、「発信」と「到達」だけでは成しえません。
「受信」の確認と行動変化による「正しく受信されたか」の確認が必要不可欠です。
なぜなら、コミュニケーションとは通信不確実性を減らす試みのことだからです。 — 広木大地『エンジニアリング組織論への招待』p.233

要するに、「情報伝達の設計が成立していなければ、どんな仕組みも機能しない」ということです。

「導入したけど使われない」という状態は、ニーズのミスマッチが原因ではなく、
人への伝達設計（運用）に課題を抱えていることが多いのではないかと考えたのでした。

「全員が知っている」を前提条件にする

この気づきから、私が徹底したのがドキュメントドリブンという考え方です。

特定の誰かが理解しているだけでは仕組みは成立しない。全員が同じ情報にアクセスできて、初めて組織として動ける。

そのために徹底した教育・周知を繰り返しながら、同時に開発陣に分離構造やUIの再設計を依頼し、「必要な情報にしか触れられない」構造を作りました。

代表例としては、Reactの「コンポーネント指向」の応用です。
業務処理に必要なページやタグを小さな部品を見立てて分割配置し、組み合わせることで再利用性と独立性を高くする考え方で、使用者が共通の操作感で扱えるようにしました。

さらに、上長に提案して自分自身を「意思決定を下から支えるポジション」に置きました。

全体を俯瞰できる視座を持つ自分が、あえて権限を持たないことで、課題を見つけて全体に周知する役割を構造として作るためです。

立ち回りひとつで組織を『リファクタリング』する

書籍には、組織構造や権限の委譲について、こう書かれています。

ひとりが考えて、多数の人が実行するという組織の情報処理能力には限界がある。
だから、適切に権限を付与することが重要だ。
— 広木大地『エンジニアリング組織論への招待』p.238の要約

この考え方を実践した結果が、CS・社内BPR・BizOpsの横断という立場に繋がります。

権限と責任は表裏一体——権限を委譲された側には、それに見合う責任が生まれる。
基幹システム刷新のカオスを乗り越えるため、その構造を自分で設計し、自分を社内で最初の実験台にしました。

目的は「お客様のため」ただひとつ

CTOから学んだ、書籍で読んだというのは、簡単でしょう。
しかし、私はそれらを机上の空論で終わらせませんでした。

現職の3年間を通じて、

お客様に、当サービスを安心して使っていただき、正しく価値を提供すること。
そして、問い合わせに誠実な回答を返す説明責任を果たすことを成し遂げたかったから。

上から指示を出していたわけではありません。
自分の立ち回りを通じて、自ら課題を見つけ、自分ができる範囲内で組織そのものを少しずつ作り直してきただけです。

それらが、現職における業務領域の横断経緯であり、
「ITと人を繋ぎ合わせ、ビジネスが成立するかどうかに責任を持つ」という、
これからのキャリアと、CS・BizOpsとしての信念と決意だからです。

▼ 併せてお読みいただけると幸いです。