【後編】 BizOps組織の作られ方（全2本）
株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。
前回の記事（本シリーズ前編）で、私が以前いた組織で業務改善の部署がどう生まれたかを書きました。
要点は、次の3行です。
- BizOps組織は、担当者の意思ではなく会社の力学で生まれる。振り子が全体最適に振れた瞬間にしか生まれない
- できたばかりの組織に回ってくるのは、構造的に誰もやりたがらない仕事。ただし、それを持てること自体が存在理由になる
- 誰の担当にもなっていない業務を、数字つきで一つ名指しできるようにしておく。担当者に今日からできるのは、それだけ
……で、組織はできました。仕事もあります。
ただ、ここから先に、もっと厄介な問題が待っていました。
人が、圧倒的に足りなかったんです。
今回は、そこから何をしたのかを書きます。
なお、今回はこういう方を想定して書いています。
- 業務改善やシステムを見ているのが、実質的に社内で自分一人しかいない
- 求人を出しても応募が来ない。社内で声をかけても、誰も手を挙げない
- 増員の必要は説明できるのに、なぜか人が集まらない
この記事の要点（3行サマリ）
- 人が来ないのは募集の出し方が下手だからではありません。募集する側が、その仕事に就いた人が何になるのかを説明できていないからです
- 応募しなかった人に理由を聞いても、本音は出てきません。普段から話している近しい人に「どういうイメージを持ってる？」と聞くほうが早いです
- 人は、組織ができてから探しても間に合いません。**先に人を口説いてから、制度の話をする。**この順番が逆だと通りません
目次
- 社内公募をかけたら、手を挙げた人はゼロでした
- 「プラットフォームに怯えなくていい」と言いました
- 宿題を出して、チェックはしませんでした
- おわりに――まず、一人に声をかける
1. 社内公募をかけたら、手を挙げた人はゼロでした
営業は増え続けている。戦略も変わる。組織も変わる。その全部が、業務の設計変更として降ってきます。
一人では、限界でした。
外から採ろうとして、うまくいきませんでした
まず、外部採用を打ちました。もちろん、採用枠の許可も取っています。
来ませんでした。
正確に言うと、応募自体がほとんど来ず、来ても要件と合わない。
当時の私は、求人票さえ出せば母集団は形成されるものだと思っていました。求人は出すだけでは取れない、といういまなら当たり前のことが、まるでわかっていなかったわけです。
そこで考えました。会社はこれだけ人を採用しているのだから、社内から異動してもらえばいいのではないか、と。
当時の私は、営業企画に所属しながら、プロダクト側のリードエンジニアという肩書きを兼任していました。実態としては名前だけです。ゴリゴリのコードを書いていたわけではありません。
その肩書きを一応の理由にして、CTOに相談し、プロダクト部門に向けた社内公募を出してもらいました。
結果は、ゼロです。
一人もいませんでした。
……正直、しばらく固まりました。
「そんなのいいから、作ってよ」と言われたわけですらありません。そもそも、会話が始まらなかった。
応募しなかった人ではなく、近くにいる人に聞きに行きました
ここで私がやったのは、一つだけです。
応募しなかった人に「なぜ応募しなかったのか」とは聞きませんでした。聞かれた側が答えにくいですし、たいてい本音は出てきません。
代わりに、普段から話している近しい人に、こう聞きました。
「この仕事、どういうイメージを持ってる？」
返ってきたのは、三つでした。
① Salesforceが、そもそもよくわからない
エンジニアであっても、業務システムの中身は見えていません。何をする道具なのかがわからなければ、そこに異動する判断はできません。
② 制約が多くて、作りたいものが作れない
これは、正しい認識です。SaaSの上で作る以上、プラットフォームの制約からは逃げられません。
自分でアーキテクチャを選べる環境から見れば、窮屈に見えます。つまらなく見えるだろうな、と私も思いました。
③ キャリアが、そこに依存してしまう
いちばん重かったのが、これです。
一つのプラットフォームに深く入ると、その製品を使っている会社でしか生きていけなくなるのではないか。その怖さがある、と。
この三つを、私は一度も想定していませんでした
ここが、私の失敗です。
私は「人が足りない」という自分側の事情から出発して、募集をかけました。
一方で相手は、「この仕事に就いた後、自分が何になるのか」を見ています。
つまり私は、業務の説明はしたけれど、キャリアの説明を一度もしていなかった。手を挙げなかったのは、その人たちの意識の問題ではありません。判断材料を渡していなかったのは、私です。
そして、この三つは今も、SFA/CRM（営業支援・顧客管理システム）の担当者を社内で探すときに、必ず出てくる論点だと思います。
人が来ないのは、募集の出し方の問題ではなく、その仕事に就いた人が何になるのかを説明できていないからです。
御社の求人票は、業務の説明で終わっていないでしょうか。
経営者の方へ： 業務改善やシステムの担当者を募集して応募が集まらないとき、原因は待遇や知名度ではなく、キャリアの説明が抜けていることが多いです。「この役割を3年やった人が、次にどこへ行けるのか」を経営として言語化できているか、一度確認してみてください。ここが言えないと、採用も社内異動も、構造的に埋まりません。
2. 「プラットフォームに怯えなくていい」と言いました
三つのうち、いちばん重い③から書きます。
キャリア依存の不安には、答えを用意しました。二段階で話しています。
一段目は、需給の話です
「Salesforceは世界で10万社以上、日本でも数千社が使っている。導入している以上、必ず管理者がいる。求人も、常に出ている」
そのうえで、人事が使う人材データベースを開いて、一緒に検索してもらいました。
Salesforceの独自言語であるApexを、得意な言語として登録している求職者が何人いるか。求職者はアピールのために得意な言語を書きますから、母数としては妥当なはずです。
当時、100件ほどでした。
需要はあるのに、供給が圧倒的に少ない。この数字を目の前で見せると、話が早いです。
※これは当時の数字です。市況は変わっているはずなので、同じ話をされるなら、ご自身の会社のデータベースで検索し直してください。
二段目は、スキルの話です
こう伝えました。
「特定のツールの設定やコーディングができるだけの『作る人』で終わるなら、君の言う通り、その製品が廃れたら終わりだ。市場価値もすぐ頭打ちになる。
でも、本当に価値があるのはそこじゃない。ビジネスのプロセスとデータの流れを解像度高く理解して、それをシステムのモデル（データ構造やER図）に落とし込んで、最後は現場に泥臭く定着させるまでやり切る。この力のほうだ。
プラットフォームは、事業を伸ばすための、たまたま今強力な一手段でしかない。ここで身につく『ビジネスプロセスを設計し直して、システムと現場を繋いで実装する力』は、ツールがSalesforceだろうが自社開発だろうが、どの会社に行っても、独立しても通用する。
だから、プラットフォームに怯えなくていい」
いま社内で同じことを聞かれている方がいたら、この二段はそのまま使えると思います。
②には、いまも答えを持っていません
ただし、正直に書いておきます。
②の「制約が多くて、作りたいものが作れない」については、当時も今も、私はうまい答えを持っていません。
制約があるのは事実です。「制約の中で最適解を出すのも技術のうちだ」と言うことはできますが、自分でアーキテクチャを選びたい人にとって、それは慰めにしかなりません。
ここは、ごまかさずに置いておきます。
3. 宿題を出して、チェックはしませんでした
残った①の「よくわからない」には、すぐ手を打てます。
知ってもらえばいいからです。
そこで、プロダクト部門に向けた勉強会を始めました。
教材が、とにかく退屈でした
当時はまだ、Trailhead（Salesforceが提供する無料のオンライン学習サービス）が今のように整備される前です。
使えたのは、ワークブックやクックブックと呼ばれるPDFの教材でした。業務課題があって、それをこう改善します、操作はここです――という演習形式です。
正直に言うと、私はこの教材が大嫌いでした。
手順の通りに操作すると、たしかに動くものはできる。でも、なぜそう作るのかが頭に残らない。
そして、この手の教材には別の危うさもあります。
以前の記事で「感謝ループ」という話を書きました。学習コンテンツは細かくステップが分かれていて、一つクリアするたびに達成感がある。その報酬設計に乗ると、「機能を覚えること」自体が目的にすり替わっていきます。
ツールに詳しい人は育つ。でも、事業を見る人は育たない。
この構造は、当時は言語化できていませんでした。ただ、教材どおりに進めることへの座りの悪さだけは、最初からありました。
「部活動」として設計しました
設計は、こうです。
- 1回1時間。講義が2割、演習が8割
- 終業後の18時半から19時半
- 週に1回、全12回。期間は約3ヶ月
業務時間外の、有志の自主参加。この形にしたので、宿題を忘れても絶対に怒らない、部活動のようなノリで運営していました。
対象は、興味があると言ってくれた8人から10人ほどです。
そして、設計として決めたことが一つあります。
宿題は必ず出す。ただし義務にはしない。提出のチェックもしない。
そのかわり、次回はやってきた前提で進みます。
なぜそうしたか。理由は二つあります。
一つは、これが業務ではないからです。全員それぞれの本業を持っています。義務にした瞬間、上長との調整が必要になり、参加のハードルが跳ね上がります。
もう一つは、チェックする側の私に、そのリソースがなかったからです。
……正直に書くと、二つ目の理由のほうが大きかったです。
許可は、ほとんど取っていません
ここは、真似できるかどうかの分かれ目になるので、正直に書きます。
私が事前に通したのは、当時のエンジニアのトップに対して一言だけです。
「業務時間外に、エンジニア個人の市場価値を高めるための有志の技術勉強会を、個人的にやります」
それだけです。稟議も、正式な承認プロセスも通していません。
メンバーには「市場価値を高めるApex開発やビジネスモデリングに興味ない？」と声をかけて、完全に非公式のサークルとして始めました。
これは、お勧めできるやり方ではありません。会社の文化によっては、勝手なことをするなと止められます。
ただ、正式なプロジェクトとして起案していたら、目的の説明、予算、工数の按分……と、始まるまでに数ヶ月かかっていたはずです。そして、たぶん始まらなかったと思います。
人事の担当者に、実際に話を聞きに行きました
内容は、途中から演習を離れました。
後半の題材に選んだのは、当時いちばんカオスだった人事採用部門で利用していたSalesforce環境でした。なので実際に人事部にヒアリングをして、要件定義をして、デモ、設計、実装、リリースまでの一連のサイクルを、身をもって体験してもらいました。
これは、意図してそうしました。
システムの作り方だけを教えても、業務改善はできません。必要なのは、相手の立場に立って話を聞き、その業務がどう回っているかを想像し、現状を理解したうえで、どこが原因かを特定して、それから作るものを決める――この一連の流れです。
「要件定義ができる」と一言で書くと、能力の話に見えます。実際には、聞く・想像する・理解する・特定する・提案する、という別々の動作の積み重ねです。
だから、教室の中で完結させませんでした。
完走したのは、半分でした
結果を書きます。
一通り終えたのは、参加者の半分ほどでした。
義務にしなかったので、当然と言えば当然です。途中で本業が忙しくなった人もいれば、やってみて違うと思った人もいたはずです。
3ヶ月後に、両側から交渉しました
勉強会を終えて、私がやったのは交渉です。
私からエンジニアのトップに、「参加していたメンバーを、正式にこちらのチームに異動させてほしい」と申し入れる。同時に、参加していた本人からも「異動したい」と言ってもらう。
両側から同時に出したことで、話は通りました。
順番が逆だったら、通っていないと思います。先に人を口説いてから、制度の話をする。この順番は、いま振り返ってもそうだったと思っています。
そして、この勉強会に出ていたメンバーの中から、後にこの部署の二代目マネージャーが出ています。
もう一人、印象に残っている方がいます。
プロダクト側のエンジニアで、Salesforceと自社プロダクトのあいだをつなぐバッチ処理を作ってくれた方です。二つの世界の橋渡しを、実際に手を動かして作ってくれた。本人も、この領域をやりたいと言ってくれていました。
最終的にこの部署に集まったのは、プロダクト部門の中でも、UXや機能といった表向きの仕事ではなく、地味な裏方をやっていた人たちでした。
同じ部署の中にも、実は業務改善が好きな人はいます。ただ、その人たちが自分でそう名乗る場所が、どこにもなかっただけでした。
御社の中に、名乗る場所がないまま業務改善をしている人は、いませんか？
経営者の方へ： 業務改善の人材は、外から採るより社内にいる可能性のほうが高いです。ただし、その人たちは今の評価軸では測られていないため、組織図からも人事データからも見つかりません。「表向きの成果ではないところを整えている人が誰か」を、現場のマネージャーに聞いてみてください。
4. おわりに――まず、一人に声をかける
前後編にわたって、一つの部署がどう生まれ、どう人を集めたかを書いてきました。
改めて振り返ると、私が意思決定したことは、ほとんどありません。
組織を作ると決めたのは経営です。集まるメンバーを決めたのも、当時の人事と組織改編です。私がやったのは、空いていた場所に線を引いたことと、人が来なかった理由を聞きに行ったこと。それくらいです。
そのうえで、後編でお伝えしたいのは一つだけです。
人は、組織ができてから探しても間に合いません。
制度より先に、人です。
だから、まず一人に声をかけてください。求人票を書くより先に、社内で「この人、裏側の仕組みを整えるのが好きそうだな」と思う人に、話しかける。
「どういうイメージを持ってる？」と聞くだけでも構いません。
その一人が、振り子が振れた日にあなたのチームになります。
私には、まだ説明できていないことがあります
最後に、この記事の限界を書いておきます。
集まったのは、社内の評価軸から少し外れたところにいた人たちでした。プロダクト部門では、顧客に見える機能をつくる人が評価されます。その軸で測ると、裏側の仕組みを整えていた人たちは、正当に測られる場所を持っていなかった。
実際、私たちのチームは「変な人集団ですね」とよく言われました。
ところが当時の上司からは、「強力なところを持っているチームですね」と言われています。
評価軸の外にいた人が集まったら、強いチームになった。
なぜそうなったのか、私はいまだに説明できません。
裏方の仕事に必要な資質が、たまたま揃っていたのか。評価されてこなかった人ほど、新しい場所で力を出すのか。あるいは私が見ていないところで、誰かが調整していたのか。どれも仮説の域を出ません。
再現できないものを「こうすれば強いチームが作れます」と書くのは、嘘になります。
だから、ここは空けたまま置いておきます。
そして、その現場に必要な人は、たいてい、もう社内にいます。
よくある質問（FAQ）
Q1. 業務改善の担当者を募集しても応募が来ません。何を変えればいいですか？
A. 募集要項の書き方ではなく、その仕事に就いた後のキャリアを説明できているかを見直してください。実際に社内で聞き取ったところ、応募が来ない理由は「そのシステムがよくわからない」「制約が多く、作りたいものが作れない」「キャリアがその製品に依存しそうで怖い」の三つでした。いずれも業務内容の説明では解消しません。
Q2. 「特定のSaaSに詳しくなると、キャリアがそこに縛られる」と言われました。どう答えますか？
A. 二段階で答えるのが有効でした。一段目は需給の話です。自社の人材データベースで、その製品の開発言語を得意分野として登録している求職者を一緒に検索し、件数を見せる。導入企業数に対して供給が少ないことが、その場でわかります。二段目はスキルの話です。ツールの設定ができるだけの「作る人」で終わればその通りですが、業務プロセスを理解してシステムのモデルに落とし込み、現場に定着させるまでやり切る力は、ツールが何であっても通用します。
Q3. 社内勉強会で人を育てる場合、参加を義務にするべきですか？
A. 義務にしないほうが始めやすいです。参加者は全員それぞれの本業を持っているため、義務化した瞬間に上長との調整が必要になり、参加のハードルが上がります。宿題は出すが提出はチェックしない、ただし次回はやってきた前提で進める、という設計であれば運営側の負荷も抑えられます。ただし、この方式では完走率は下がります（実際に一通り終えたのは、参加者の半分ほどでした）。
Q4. 非公式で勉強会を始めるのは、リスクではありませんか？
A. リスクはあります。会社の文化によっては止められますし、お勧めできるやり方ではありません。ただし正式なプロジェクトとして起案すると、目的の説明・予算・工数の按分で数ヶ月かかり、そのまま始まらないことも多い。私は「業務時間外に有志で個人的にやります」と一言だけ通し、3ヶ月後に成果が出た段階で、自分からと参加者本人からの両側で異動を申し入れました。先に人を口説いてから制度の話をする、という順番です。
Q5. 社内に業務改善をやりたい人がいるかどうか、どう見つければいいですか？
A. 組織図や人事データからは見つかりません。今の評価軸で測られていない人たちだからです。実際に集まったのは、プロダクト部門の中でも、顧客に見える機能ではなく裏側の仕組みを整えていた人たちでした。現場のマネージャーに「表向きの成果ではないところを整えている人は誰か」と聞くのが、いちばん早いと思います。
次回予告
前後編を通して、「私が意思決定したことはほとんどない」と何度か書きました。
ただ、それでは「では、いつ組織にすべきなのか」という問いに答えたことになりません。
次回は、そこを書きます。組織にすべきタイミングの見極め方、人の集め方、育て方、そして評価。メリットだけでなく、組織にしたことで失うものも含めて書くつもりです。
今回「説明できない」と書いた部分に、少しでも近づければと思っています。
無料相談のご案内
「業務改善を任せられる人が社内に見つからない」「求人を出しているが、応募が集まらない」。
そんな経営者・責任者の方、そしてご担当者の方は、お気軽にご相談ください。
社外の知見と御社の情報を掛け合わせて、まず現場が喜ぶ改善から、その先の改革へ。採用と育成の設計まで含めてご一緒します。
実際、最初のご相談は現場のご担当者お一人から、というケースがほとんどです。上申の材料づくりからご一緒します。初回のご相談は無料です。
参考文献・出典
- 本記事に登場する数値（Salesforceを得意言語として登録していた求職者数「当時100件ほど」、勉強会の完走率「参加者の半分ほど」など）は、いずれも筆者（祖川慎治）自身の実務経験に基づく記述です。第三者調査による統計値ではありません。「Salesforceは世界で10万社以上、日本でも数千社が使っている」という言及も、当時筆者が社内説得の場で用いた発言としての記述であり、現在の正確な導入社数を示すものではありません
- 前回の記事：BizOpsの組織が生まれる日――担当者の意思ではなく、会社の力学が決める
- 関連記事：SaaS投資が”作業コスト”に消えていませんか？
この記事を書いた人
祖川 慎治（そがわ・しんじ）
株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする？BizOps」配信中。