「複雑さにあらがう“設計者たち”」――マネーフォワードに学ぶBizOpsの実践構造：ビジネスとITを“動かす”仕組み──BizOpsという選択肢（1/2 ページ）
金融SaaSを多角的に展開するマネーフォワード。複雑な構造を内包する組織のなかで、BizOpsがいかに課題に向き合い、信頼を築きながら、変化を生み出しているのかを追う。
BizOpsは、これまで「なんでも屋」や「つなぎ役」とされてきた業務に、戦略的な意味と構造を与える職能です。
戦略と現場、構想と実行、ツールと業務。組織の 間をつなぎ、仕組みを設計し、現場を動かしていく――そんな職能が、企業の中で静かに存在感を高めています。
前回取り上げたLayerXでは、BizOpsが“戦略を動かす仕組み”として機能している様子を描きました。
今回は、より組織の深部に入り込み、”仕組みで組織を動かす”ことのリアルに迫ります。
金融SaaSを多角的に展開するマネーフォワード。複雑な構造を内包する組織のなかで、BizOpsがいかに課題に向き合い、信頼を築きながら、変化を生み出しているのかを追います。
第1章：マネーフォワードは「複雑さの縮図」
マネーフォワードがBtoB事業としてサービス展開する「マネーフォワード クラウド」は、会計、給与計算、請求書発行/受取など、複数のSaaSとして提供しています。
それぞれのプロダクトが独自の市場で成長しており、スタートアップ的なスピードと柔軟性を持つ一方、全体としての複雑性も抱えています。
例えば、顧客管理やKPI計測、受注から入金までの業務プロセス。各事業部が独自に運用を進めることで、重複や非効率が生まれやすくなります。組織が拡大し、2028年度に売上1000億円を目指す中で、個別最適のままでは限界がある――そうした課題意識が高まっていきました。
そこで必要とされたのが、全社横断で“仕組みの統一”と“構造の改善”を推進する機能です。
BizOpsは、複数の事業フェーズやオペレーションをつなぎ直し、「スケールする仕組み」へと再構築していく役割を担うようになりました。
第2章：“非連続な改善”のための専任部隊――横断BizOps本部の立ち上げ
マネーフォワードのBizOpsは、初めから現在のような形だったわけではありません。
2019年以前は1事業部の中で、Salesforce管理や受注処理などを担う「BPR推進部」としてスタートしました。
しかし、事業拡大とともに、各事業部の取り組みだけでは解決できない課題が顕在化し、2021年、マネーフォワードのBtoB事業を担当するマネーフォワードビジネスカンパニー（MFBC）内の「横断BizOps本部」として独立した組織が立ち上がります。
特徴的なのは、彼らが担っているのが「非連続な改善」であることです。日常的な業務改善が、既存プロセスを少しずつ良くする「連続的な改善」だとすれば、BizOpsが目指すのはゼロベースで理想の業務像を描き、それに向かって業務全体を再設計していくことです。
例えば請求業務であれば、「どこが面倒か」ではなく、「請求とは本来どうあるべきか」から議論が始まります。そこから、現実に即したステップを組み立て、段階的に理想に近づけていく――構想力と実行力の両立が、横断BizOpsの特徴だと言えるでしょう。
第3章：“人が頑張る”から“仕組みで回る”へ
成長期の企業では、「人が頑張る」ことで業務がなんとか回る場面が少なくありません。Slackでの手動リマインドやExcelでの手修正など、属人的な運用は初期の立ち上げには有効でも、スケールするにつれて再現性の壁に直面します。
マネーフォワードも例外ではなく、かつては業務が属人化し、「あの人がいないと止まってしまう」状態が各所に存在していたといいます。横断BizOpsの役割は、こうした人に依存した業務を、“仕組み”で自然に回る構造へと転換することです。
課題の発見は、現場ヒアリングや業務棚卸し、Slack上のやりとりの観察など、複数の方法で進められます。
「同じ質問が何度も繰り返されている」「誰かの名前を毎回呼び出して確認している」――そんな些細な兆候も、構造上の課題を見つけるヒントになります。
BizOpsでは、Slack上のやり取りをはじめとする日々のコミュニケーションの中で共有される、現場からの小さな“困りごと”や“引っかかり”の中から共通項を見つけ出し、より構造的な課題へとつなげていくアプローチを取っています。
そうして見えてきた課題は、単なる「ミスの原因」や「マニュアル不足」ではなく、構造そのものに起因することが多いのです。
例えば、リードの重複やツール連携ミス。これらを「ルールで防ごう」とすると、現場には「気をつけてください」という指示が増え、やがて形骸化してしまいます。
BizOpsが目指すのは、そうした運用依存からの脱却です。
「〇〇が起きたらをするように気をつけてください」ではなく、「〇〇が起きたらしてください」でも なく、そもそもそういった事象自体が起きないような構造に業務を見直す。そうした仕組み設計こそが、BizOpsの役割です。
例えば、入力項目にチェックロジックを設けてミスを防いだり、Slackでの通知を自動化してリマインドを仕組みに組み込んだり――そうした“人が判断しなくても正しく進む”状態をつくることが、BizOpsの基本的な設計思想です。
「できる人が支える」のではなく、「仕組みで回る」業務へ、それが、マネーフォワードにおけるBizOpsの存在意義なのです。
第4章 当事者として現場に入り込む――BizOpsのスタンスと哲学
マネーフォワードのBizOpsは、特定の事業部に属さない「横断」機能として動いています。
しかしその姿勢は、外部コンサルタントのような距離感ではなく、あくまで社内の一員として現場に入り込み、肩を並べて課題に向き合うことにあります。
BizOpsは、誰もが気づいていても着手されない課題や、部門をまたぐ連携上の曖昧な責任範囲を、自ら拾いにいきます。営業とマーケティング、カスタマーサクセスとバックオフィスなど、「どちらの課題でもあるけれど、誰も主語になりにくい」領域にこそ、彼らの価値が発揮されます。
ときには、プロジェクトの初期段階で誰よりも先に現場に入り込み、Slackの空気感を観察し、非公式なやりとりから真のボトルネックを掘り起こします。形式上は課題が明文化されていても、それが本当に現場で語られている言葉と一致しているか――そうした“ズレ”を吸収し、調整する役割も担っています。
また、仕組みは設計するだけでは定着しません。
現場が「納得できるものになっているか」を重視し、業務の背景や文化まで踏まえて丁寧に組み立てる姿勢こそが、彼らの信頼の土台となっています。BizOpsのメンバーは、導入した仕組みが現場でどう使われているか、リリース後も観察し続け、必要があれば微調整もいとわないのです。
「実装して終わり」ではなく、「使われて初めて意味がある」。
だからこそ、彼らは当事者として現場に入り込んでいくのです。
Copyright © ITmedia, Inc. All Rights Reserved.