← BLOG

BizOpsの成果は数字では伝わらない ── 評価を動かす「証言」の設計

BizOps 評価 組織 マネジメント キャリア
BizOpsの成果は数字では伝わらない ── 評価を動かす「証言」の設計

BizOpsの成果は数字では伝わらない ── 評価を動かす「証言」の設計

株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。

御社にこんな心当たりはありませんか?

  • 半期の評価面談で成果を数字で説明しても、「ふーん」で終わってしまう
  • 自分の成果は自分で語るしかないと思っているが、語れば語るほど自画自賛に見える気がする
  • 他部門から日常的に感謝されている実感はあるのに、それが人事評価の資料には一切反映されない
  • 「作る人」として頼りにされてはいるが、経営会議や事業戦略の議論には呼ばれない

一つでも当てはまるなら、原因は成果の大きさではなく、成果の伝え方にあります。

BizOpsの成果を数字で並べる努力は、間違ってはいません。ただし、数字だけでは評価を動かせません。理由は単純で、自分で自分の成果を語る限り、聞く側は無意識に「割引」をかけるからです。本人が言うほどの成果なのか、ほかの要因もあったのではないか。この疑いを崩せるのは、本人以外の言葉だけです。

評価を動かすのは「証拠」ではなく「証言」です。数字は証拠として使えますが、証拠だけでは信頼は生まれません。受益者が「BizOpsのおかげで助かった」と語ることで、初めて評価は動きます。そして証言は放っておいても生まれません。関係性を意図的に設計し、証言が自然に出てくる仕組みを作る必要があります。

この記事では、数字が評価に反映されない構造から、証言を引き出す具体的な方法、会社側と個人側それぞれが取るべき戦略までを順に整理します。


この記事の要点(3行サマリ)

  • **BizOpsの成果を数字で並べても評価は動かない。**当事者感の薄さ、自画自賛への疑い、「あって当たり前」と見なされる構造が原因
  • **評価を動かすのは「証拠」ではなく「証言」。**利害関係のない第三者が語ることで、初めて信頼される
  • **証言は自然発生しない。**関係性の深さが口コミの発生確率を決めるため、受益者にメリットを設計して意図的に引き出す仕組みが要る

数字を並べても「ふーん」で終わる、三つの構造

「営業プロセスの見直しでリードタイムを短縮した」「請求業務を自動化して工数を削減した」。BizOps担当者が評価面談で並べる報告は、たいてい立派です。それでも経営層や人事の反応は薄い。理由は三つあります。

第一に、数字の当事者感が薄いことです。「工数を削減した」と言われても、経営層の頭に浮かぶのは「それが売上にどうつながるのか」という問いです。営業が受注を取れば受注額はそのまま営業の成果になります。しかしBizOpsが営業プロセスを改善して受注率が上がっても、その数字は「営業の成果」として計上されます。BizOpsの貢献は構造的に見えにくい位置にあります。

**第二に、自分で自分の成果を語ると、聞く側が無意識に割り引くことです。**人は自分の貢献を過大評価しやすい傾向を持ちます。心理学で「自己奉仕バイアス」と呼ばれる現象です。厄介なのは、聞く側もこのバイアスの存在を知っていることです。自己申告の成果報告を聞くとき、経営層は「本人が言うほどではないのでは」と無意識に差し引いて受け取ります。自画自賛は、伝わらないどころか信頼を損なうリスクさえあります。

**第三に、BizOpsの成果は「あって当たり前」と認識されやすいことです。**業務がスムーズに回っている状態は「普通」として扱われます。整備したプロセスがうまく機能しているときほど、その存在は意識されません。壊れたときに初めて「あの人がいないと困る」と気づかれる。BizOpsの成果は「減らした」「防いだ」「整えた」という性質のものが多く、「生み出した」「獲得した」という能動的な成果に比べて、そもそも評価されにくい構造を持っています。

この構造は、私自身も痛感してきました。前職で、事業部ごとにバラバラだった請求書のテンプレートと承認フローを統一するプロジェクトを担当したことがあります。月末の経理部門の残業は大きく減り、請求漏れも目に見えて減りました。しかし半期の評価シートに記載された成果は「請求業務の工数を月20時間削減」の一行だけでした。同じ評価期間、営業部のエース社員は「新規大型案件を3件受注」で全社表彰を受けています。どちらが会社への貢献度として大きいかは一概に比較できません。それでも「見えやすさ」は圧倒的に受注案件のほうが上でした。

私の評価シート営業エースの評価シート
請求業務の工数を月20時間削減新規大型案件を3件受注
一行で記載、表彰なし全社表彰を受賞

BizOpsの成果は、数字にしても地味に映ります。この現実を受け入れたうえで、別の戦い方を考える必要があります。


評価を動かすのは「証拠」ではなく「証言」

数値化そのものが悪いわけではありません。数値化だけでは足りないのです。数字は「証拠」としては機能します。しかし評価を実際に動かすのは「証言」です。

自分で「これだけ成果を出しました」と言うより、受益者が「BizOpsのおかげで助かりました」と言ってくれるほうが、はるかに説得力があります。評価を「自分ごと」として伝えるのではなく、「他人ごと」として語ってもらう。この転換が、BizOpsの評価問題を突破する鍵になります。

採用の場面に置き換えるとわかりやすくなります。候補者が履歴書に「売上目標を達成しました」と書いているのと、元上司が「あの人がいなければチームの数字は成り立たなかった」と証言するのとでは、聞く側の受け止め方がまったく違います。前者は自己申告、後者は第三者のリファレンスです。社内でのBizOpsの評価も、同じ構造で考えられます。


第三者のリファレンスが効く理由と、証言が自然発生しない理由

営業部長が経営会議で「BizOpsがプロセスを再設計してくれたおかげで、商談の進め方が明確になった」と話す。経理部長が「請求業務の仕組みを整えてもらい、月末の残業が減った」と報告する。これらはすべて「第三者のリファレンス」です。BizOps自身が言うのではなく、恩恵を受けた人が語る。この構造が経営層に対して強い説得力を持つ理由は三つあります。

**第一に、利害関係のない証言は信頼性が高いこと。**営業部長がBizOpsを褒めても、営業部長自身に直接の見返りはありません。むしろ「自部門だけで成果を出した」と言ったほうが自部門の評価は上がります。それでも名前を出すのは、実際に効果があったからです。利害を超えた証言だからこそ信頼されます。

第二に、具体的なエピソードとして語られること。「商談のステージ管理を明確にしてもらい、週次の営業会議が短時間で終わるようになった」という一文には、行動の変化と感情がともに含まれています。抽象的な「工数削減」よりも、生々しい体験談のほうが記憶に残ります。

**第三に、複数の部門から同じ証言が集まると横断的な価値が可視化されること。**営業、経理、人事、カスタマーサクセス。異なる部門から「助けてもらった」という声が上がったとき、経営層は「特定部門の改善屋ではなく、全社に横断的な価値を提供している」と認識します。

ここで一つ、落とし穴を指摘しておきます。他部門の責任者が自発的にBizOpsを褒めてくれることは、率直に言ってほとんど起きません。人は、うまくいっている状態を「当たり前」として受け入れる生き物です。プロセスが快適に動いていても、わざわざ「BizOpsのおかげです」とは言ってくれません。

自発的にBizOpsの貢献を語ってくれるのは、プロジェクト期間中に日常的に顔を合わせ、一緒に問題を解決した相手だけです。関係性の深さが、口コミの発生確率を決めます。浅い関係からは口コミは生まれません。依頼を受けて納品しただけの関係は、外注先と同じ扱いになります。だからこそ、第三者のリファレンスは待つものではなく、意図的に引き出すものです。


証言を引き出す五つの方法 ── 受益者側にメリットを設計する

口コミは自然発生しません。仕組みとして設計し、地道に引き出す必要があります。共通する原則は一つ。受益者側にメリットを設計すること。「忙しいのに証言を書いてください」とお願いしても動いてくれません。相手が動きたくなる形を先に用意します。

方法受益者側に設計するメリット
受益部門の責任者に成果レポートの一部を書いてもらう自部門の改善実績として経営会議に報告できる
経営会議で受益者から一言を話してもらう段取りを組む資料作成の手間はBizOps側が引き受ける
社内チャットで受益者のコメントを引き出す名前を挙げられたお礼として自然に感謝を返せる
「助けてもらった貯金」を日常的に積む小さな困りごとにすぐ応えてもらえる安心感を得られる
定期的に「改善事例集」を発行する自部門の取り組みとして全社に周知される

一つ目は、プロジェクト完了時に受益部門の責任者へ成果レポートの一部を書いてもらう方法です。営業部長なら「営業プロセス改善の成果報告」、経理部長なら「バックオフィス効率化の成果報告」。部門の責任者が自部門の実績としてアピールできる形にすれば、レポート作成は「BizOpsのための仕事」ではなく「自分のための仕事」になります。そのレポートに「BizOpsとの協働で実現した」という一文が入っていれば十分です。

二つ目は、経営会議での報告をBizOpsではなく受益部門の責任者に任せる段取りです。報告資料のドラフトはBizOps側で用意し、相手の手間を最小化します。BizOpsが裏方に徹し、報告するのは受益者。この構図を意識的に作ります。

三つ目は、社内チャットでの投稿です。改善事例を共有する際、投稿の最後に協力してくれた相手の名前を挙げると、相手は「こちらこそ助かりました」と自然にコメントを返してくれます。このやり取りが社内のタイムラインに残り、日常的にBizOpsの名前が流通する状態を作ります。

四つ目は、大きなプロジェクトだけでなく、日常の小さな困りごとへの対応を惜しまないことです。この積み重ねが「助けてもらった貯金」として相手の中に蓄積され、証言を頼んだときに快く引き受けてもらえる土台になります。

五つ目は、四半期に一度、各部門の改善事例集を発行することです。体裁は「BizOpsの自己アピール」ではなく「各部門の業務改善記録」にします。事例ごとに受益部門の担当者コメントを掲載し、BizOpsの名前は協力チームとして控えめに記載する程度にとどめます。

五つの方法に共通するのは、BizOps自身が自分の成果を語らないという原則です。語るのは常に受益者。BizOpsは裏方に徹し、受益者が語りやすい環境と機会を設計する側に回ります。


会社の視点:BizOpsは「協力者ネットワークのハブ」である

ここまでは個人がどう証言を集めるかの話をしてきました。視点を変え、会社側から見たBizOpsの価値を考えます。

BizOpsは仕事の性質上、ほぼすべての部門と接点を持ちます。営業プロセスの改善で営業部と関わり、請求フローの整備で経理部と関わり、採用オペレーションの整備で人事部と関わる。全社横断の改善プロジェクトに関わるたびに、「BizOpsに協力してもらった」という記憶が各部門に刻まれていきます。この蓄積が組織にもたらす価値は、個別のプロジェクト成果を数字で報告するよりもはるかに強固です。

過去に助けてもらった記憶がある部門は、次のプロジェクトへの協力を得やすくなります。互恵性の原理で、一度貸しがある相手からの依頼は断りにくいものです。加えて、複数の部門と深い関係を持つBizOpsには、部門間の情報が自然と集まるようになります。「営業部でこんな課題が出ているらしい」「経理部がこういう仕組みを検討している」。この情報のハブ機能は、組織全体の意思決定スピードを押し上げます。

こうした関わりを積み重ねると、BizOpsの名前が社内のあらゆる場所で言及されるようになります。「あのプロジェクト、BizOpsと一緒にやったよね」「困ったらBizOpsに相談すればいい」。この言及の頻度が、BizOpsの社内での立ち位置そのものになります。組織再編の議論で「BizOpsの枠は減らせない」という判断が自然に下されるのは、どの部門に聞いても「いなくなると困る」と返ってくるからです。

BizOpsを売上への直接貢献だけで評価しようとすると、この価値を見誤ります。評価指標を設計するなら、次の三つを推奨します。

指標何を測るか
プロジェクト関与率全社の改善プロジェクトのうち、BizOpsが関与しているものの割合
部門満足度受益部門からのフィードバックスコア(四半期ごとの簡易サーベイ)
リピート依頼率一度BizOpsと協働した部門が、再度依頼してくる割合

売上への直接貢献ではなく、組織の中でどれだけ必要とされているかを測る指標です。BizOpsの本質が全体最適の設計と実行にある以上、評価指標も全体最適の視点で設計すべきです。


個人の視点:「作る人」で終わるか、「相談される人」になるか

BizOpsのキャリアには分岐点があります。指示されたものを正確に速く作る「作る人」で終わるか、経営の構想段階から声がかかる「相談される人」になるか。この分岐は、評価の構造そのものに直結します。

評価の基準作る人相談される人
評価される対象タスクの完了意思決定への貢献
評価の天井ある(実行部隊の枠を出ない)ない(事業の成長とともに上がる)
声がかかるタイミング依頼を受けてから構想段階から

「作る人」の評価は、依頼されたシステムを期限どおりに構築したかというタスクベースで測られます。タスクの完了は評価されても、そのダッシュボードが経営の意思決定をどう変えたかまでは守備範囲に入りません。結果として、どれだけ速く正確に作っても「実行部隊の一員」という位置づけから抜け出しにくくなります。

一方「相談される人」は、「来期の事業戦略でオペレーション面に何が必要か意見をもらえないか」といった相談を構想段階から受けます。評価の対象は「何を作ったか」ではなく「どんな価値を生み出したか」に移り、事業の規模が大きくなるほどBizOpsが関与する意思決定の範囲も広がります。評価に天井がありません。

転換はスキルの積み上げだけでは起きません。構造的な仕掛けが必要です。第一に、経営の言語を話せるようになること。「この投資はいつ、どれだけのリターンを生むのか」という問いに答えられる形へ、業務改善の提案を翻訳できるかどうかが最初の壁になります。第二に、問われる前に提案すること。「来期の事業計画を拝見しました。オペレーション面で三つの課題が予見されます」と、依頼が来る前に自分から持っていく姿勢が「早めに相談したほうがいい人」という認識につながります。第三に、小さな成功体験を積み重ねること。今のプロジェクト報告の場で小さな提案を添え、採用されたら次は少し大きな提案をする。この繰り返しが、構想段階から声がかかるポジションへの移行を作ります。

BizOpsは横断組織であるがゆえに、直接の売上を立てません。この構造は変わりません。だからこそ、評価の軸は自分で定義し、上司や経営層と事前に合意しておく必要があります。自分の手柄を主張しない姿勢は、裏を返せば経営の懐刀として信頼される資質です。代替不可能な存在になった先には、報酬も評価もついてきます。遅れてくるだけで、必ず来ます。


BizOpsの評価問題の本質は、見えにくい価値をどう伝えるかにあります。数字で伝えるのではなく、人の口を通じて伝える。自分で語るのではなく、受益者に語ってもらう。地道な積み重ねが、社内のあちこちから「あの人がいないと困る」という声を生み出したとき、それがBizOpsにとって最も確かな評価になります。


よくある質問

Q1. 数字での成果報告は、もうやめたほうがいいのでしょうか?

A. やめる必要はありません。数字は「証拠」として必要です。ただし証拠だけでは評価は動きません。数字は用意したうえで、それを語る主体を自分から受益者に移すのが要点です。

Q2. 受益部門の責任者に報告を頼むのは、負担をかけて嫌がられませんか?

A. 「BizOpsのための報告」として頼むと嫌がられます。「自部門の改善成果の報告」として、資料のドラフトはこちらで用意する形にすれば、相手の社内評価にもプラスになるため引き受けてもらえます。相手のメリットで設計してください。

Q3. まだ大きなプロジェクトの実績がありません。何から始めればいいですか?

A. 日常の小さな依頼への対応から始めてください。レポートの見方がわからない、数字を急ぎで出したい。こうした一つひとつの対応が「助けてもらった」という記憶として蓄積し、後から証言を頼めるだけの関係になります。

Q4. 経営側として、BizOpsをどう評価すればいいですか?

A. 売上への直接貢献ではなく、組織の中でどれだけ必要とされているかを測る指標を置いてください。プロジェクト関与率、受益部門の満足度、リピート依頼率の三つが目安になります。


無料相談のご案内

BizOpsの評価がなかなか社内で伝わらない、証言を引き出す仕組みをどう作ればいいかわからない。そんな経営者・責任者の方は、お気軽にご相談ください。

現場に入って一緒に整理するところから始めます。初回のご相談は無料です。

お問い合わせはこちら

これまでの支援実績はこちら


参考文献・出典

  • 本記事の評価面談のエピソード(請求フロー統一プロジェクトと評価シートの記載内容)は、いずれも筆者(祖川慎治)自身の前職での実体験に基づきます
  • 「自己奉仕バイアス」は社会心理学で一般に知られる認知バイアスの呼称です
  • 第三者のリファレンス、証言を引き出す方法、評価指標の設計に関する考察は、筆者が執筆中の書籍『BizOps本(仮題)』の議論を再構成したものです

自社の実行力を、7問でセルフチェック

会社名は不要、約1分半で今の段階がわかります。

BizOps成熟度セルフチェックを受ける