「自分が決められる」ことでジブンゴト化が進むとしたら、データはどう役に立てられるのか

「データのチカラ」は、データのその先をテーマにしたノートです。

ジブンゴト化について、データの側面からひとつの考え方を紹介したいと思います。

ここでは、ジブンゴト化の一側面を取り上げます。
「ジブンゴト化とは」には触れませんが、これが全てではないこと、再現性について触れているわけではないこと、あらかじめご了承ください。

話を分かりやすくするために「ジブンゴト化は、自分が決められると進展する」という仮説を前提におきます。

理由は、
- 自分が決めたことだから結果責任を自覚しやすい
- 自分から決めにいけるので、決めるプロセスを前向きに実行する
- 自分の決めたことで好結果がでると、よいフィードバックループが働く

これらは権限委譲することと等しい関係にあります。

しきい値による権限委譲

さて、多くの場合、権限移譲は「しきい値」設定により実現されています。

例えば、
- 物品の購入金額
- 営業の契約金額
- 人材の採用権限（報酬レンジ、ポジション）
- 面接可否（１次・2次・・・）
といった規定・ルールです。

役割に応じた規定の範囲内であれば、自由に決められることにして、多くの人に決めてもらえるようにしています。組織の意思決定者からすると、自分だけで決めるよりも速く・簡潔に決められて、事が進むようになります。

権限規定はリスク管理でもある

権限規定は、決められる範囲を定めていますが、同時に決めてはいけない（他の人の判断を必要とする）範囲も定めています。組織としてリスクとなる範囲を定めている、と言い換えることができます。

リスク管理は、組織の規模や目的によって変わります。
例えばアルバイト採用といっても、10名の会社では社長が決めるかもしれませんが、100店舗1000人のチェーン店では店長が決めるだろう、などです。
店長に権限移譲をする理由は様々挙げられるでしょうが、まず第一に、100店舗分のアルバイトを1000人規模の社長が採用することは物理的に不可能です。

ところが、店長には経営者目線でアルバイト採用を決めてほしいと、社長が考える場合があります。店長にとっては難問ですが、店舗が経営的に重要な場合、求められる事がありえます。
このとき、社長が店長に期待する役割は経営者目線なのに、実際の店長の役割は経営者ではないという差が生まれます。

期待役割が実際の役割（多くの場合、経験や能力に連動）と乖離してくると、「ジブンゴト化」「ふたつ上の目線」など言われるようになります。
（逆に、現場がダラけて目線を下げたときに言われるパターンもあります）

とはいえ、本当に経営者を店長に据えたいのか？というと、そうでもありません。あくまでも全組織を見ている視点で重要な意思決定をし、自ら進めてほしいという事です。

モデリングによる権限委譲の事例

製造業での、モデリングによる権限委譲の事例をご紹介します。経営者目線で意思決定をして欲しいが、工場長候補者に権限移譲します。複雑な事情を加味しながら、かつ現場もまわしながら価格を決めていけるようにした例です。

背景には、
- 早期に2本目の柱になるような新規クライアントが必要
- 試作・見積もり提出のサイクルが何度も必要
- すぐに価格を出すことが受注には効果的
という状況がありました。そのため、客先で技術営業しつつ、見積もり価格を本人に素早く簡便に計算してもらい、クライアントの信頼を勝ち取る事が避けられませんでした。
また、受注ロット数により単価変動しやすい業界だったので、例えば500本、1000本、3000本といった見積もりをセットで出すことも重要でした。そうすることで、クライアントは在庫リスクをどこまで取れるのかが判断できるようになります。

一律規定の限界

ところが、30万円の案件の場合、50万円の案件の場合、100万円の案件の場合と区切って権限委譲すると、本数増加に起因した見積もり権限を渡せなくなってしまいます。これでは「現場に意思決定をしてもらう」ための柔軟性に欠けてしまいます。

また、「１０万円案件は提案していいが、１００万円単位は要相談」という状態にしたくありませんでした。なぜなら、１０万円のビジネスより１００万円になるビジネスをその場で受注して欲しいからです。それだけで年間では桁が２つ変わるかもしれません。

一方で、むやみに権限委譲すると、大量受注時のリスクがどこまで反映されているか分からず、経営的なリスクを管理不能な状態にしてしまいます。

そこで、リスク・リターンのなかで意思決定をすることができるように、モデリングを取り入れました。計算可能なロジックを現場に取り入れることができれば、リスクを軽減して権限委譲しやすくなります。
この時、データの統合・変換・結合がとても重要になりました。

見積もりモデルの構築

見積もり時のもっとも大きな課題は、提示金額に関わるリスクです。
収支のバランスはもちろんのこと、固定費や受注リスクの扱い方により将来の財務諸表を決めてしまうからです。

まず、こうしたリスクを分類しました。主に限界利益率の異なる単位でグループ化し、グループ化した単位でロジックを組み、組み合わせによってモデル化しました。

モデル概要
- 原材料
　配合により変わるため、配合書（レシピ、部品表的なもの）に単価を持たせました。ロス率も配合技術の難易度により変わるため、変数として設定値にしました。
- 外注資材
　単価表を利用。経理と現場のマスタデータの不一致を改善しました。
- 稼働人員（パートタイム）
　現場の采配で、受注した結果かかる製造工数をイメージし、人数・時間をざっくり入れることにしました。
- 使用設備の減価
　製造日数により算出。本来は、使用する機械別に行いたかったのですが、簡素化しました。工法・必要工程ごとに標準値を設けました。
- ロット数（発注単位）
　受注ロットごとの１本単価に利用。500本、1000本、3000本など入れられるようにし、掛け算や割り算に用いました。
- 利益
　上記の各グループ項目ごとに、リスクに応じて利益率を設定。また、最終的に獲得したい利益率を総額に設定しました。これにより工程上の利益と受注全体の利益を分けることになりました。（一部工程だけ受注することも可能になりました）
受注リスク（製造ミス、不具合、品質保証）も、一定の利益率に含めることにしました。
- 値引き
　営業現場で値引く金額を、最後に入れられるようにしました。モデルによる算出結果と、値引きの金額をデータとして蓄積することが目的でしたが、多くのケースでモデリングによる算出価格の調整も行われることになりました。

データソースとシステム概要

固定費のデータソースは会計データです。
原価データは受発注システムにあります。
人件費および部門の人件費は、人事労務です。

システムはExcel、Kintoneを用いました。
Kintoneを利用したのは、当時すでにAPIとUIの両方を備えた安価なクラウドサービスとして唯一だったためです。
定期処理のプログラムは、弥生シリーズから書き出されたCSVを読み込み、固定費計算や単価表更新のためにKintoneへ書きこんでいました。

想定ほどうまく行かなかった要素もあります。
当初は現場にABC会計をいれようと目論見ましたが、システム化してもIRRが合わないため断念しました。
また、パートタイムで働く方々のマネジメントも細かく把握しようとしましたが、こちらも費用対効果が見合わず断念しました。
代わりに、採用時に提示する賃金とヘッドカウント以外は、全権を現場へ委ねました。その２つ以上の経営的なリスクはないためです。

成果

結果は良好でした。見積もり作業が劇的に軽減されるわけではありませんでしたが、見積もりそのものは提出しやすくなり、提案数の増加に合わせて枚数が増えていきました。最終的には大型受注にもつながり、当初の目的を果たしました。

モデリングにも修正は加えていましたが、大きな枠組みは変わりませんでした。もともと経営上のリスクに絞って原価計算に準じたモデルだったためです。

ジブンゴト化
事業的な成果もさることながら、もっとも大きな成果は、現場が自ら提案をしてまわれるようになったことでした。単純なことですが、クライアントと話すための重要な資料である「価格」を提示しながら話せるようになったためです。速度と会話量によって活気が生まれたのです。

少量生産で価格が高い場合には、本数を多めにして提出することも可能です。設備性能に左右される工程は、外注先の見積もりと比較することも可能です。上長に相談し、値引きすることも可能です。

こうして、手元に数字が持てることにより、思考がはじまり、行動が変わっていきました。

モデルそのものは完璧ではありませんでした。
たとえば相場や他社提示価格との乖離がありそうな数字が出ることもありました。そもそもモデルが「自社の現状」の上に構築されているため、致し方ありません。そもそも自社に競争力がない案件では、受注できそうな価格は出てこなかったのです。

また、値引きについては現場からの相談に積極的にのりました。現状から導いた金額で解決できない＝経営課題が潜んでいそうだからです。
そのうえで、徐々に「固定費相当分は値引き可能である可能性が高い」などの視点を提供していきました。財務的な視点では、キャパシティを超えない範囲で稼働率をあげる限り、ほぼリスクがありません。TOC制約理論からも、ボトルネック工程の稼働が埋まるまでは競争力を重視することにしていました。

データのチカラ

いかがでしたでしょうか。
ここで触れたデータは、すでに各システムに存在しているものばかりでした。また、モデリングも目新しいことはしていません。使ったシステムも、斬新なパッケージではありません。

きちんと統合し、連動し、事業・部門の目的に応じた形で「使える状態に置く」事が、データのチカラを引き出すのだと思います。
このノートが、データの活用に日々向き合っている方の、何かしらのお役にたてば幸いです。

ご相談・ご依頼はお気軽にご連絡ください！