【初心者向け】機械学習をビジネスにつなげる「評価指標」の解説と活用事例
本記事は、機械学習が初めての方でも「『評価指標』が何となくわかった気になること」をゴールとします。
機械学習における評価指標とは、「どんなモデルを良しとするかのモノサシ」です。
評価指標は、ビジネスと機械学習の成果を結び付けるとても大切な概念です。
しかし、横文字や数式が出てきて、理解を諦めてしまう方も多い気がします。
しかし、「評価指標」をちゃんと理解しておかないと「精度9割なのに全く使えない」なんてモデルができてしまうこともあります。
長いので先に要約すると、こんな感じです。
（関連エントリ）
これだけ理解すれば大丈夫
今回は、機械学習の中でも「分類」と呼ばれる、「売れる/売れない」のような結果のカテゴリを予測するようなケースについて説明します。
先に結論を言うと、以下３(+1)つを理解すれば、なんとなく会話はできるようになります。
- 正答率 Accuracy
- 適合率 Precision
- 再現率 Recall
- (応用編として、F値 F-measure)
前提知識
機械学習（というか数学・統計）の世界では、
「予測が当たった/外れた」の組み合わせを、下図のように分割して名前をつけています。
・・・が、この絵の時点で混乱する方もいると思います。
シンプルなケース：コピー機の飛び込み営業
そこで、シンプルな例として、ある製品が「売れる/売れない」を予測するモデルを想定します。
実際の結果は２パターンで「売れる」「売れない」。
予測も当然に２パターンで「売れる」「売れない」。
で、予測結果と実際（答え）の組み合わせを表にすると、こう分類できます。
「◯」が正解「×」が不正解ですね。
もしわかりにくい方は、インフルエンザの検査も基本的に同じなので
「売れる」→ インフル
「売れない」→インフルじゃない
で置き換えてください。ちなみにこうなります。
なんとなく理解すればOKです。
前提知識は以上です。
具体的な評価指標と使用場面
冒頭述べたとおり、「評価指標」とは、どんなモデルがいいのか、を測るものさしです。
私のような文系ビジネスサイドがなんとなく思い浮かべる「精度」みたいなものだと思ってください。
ところが、文系が思い浮かべる「精度」には実は何パターンかある、というのがミソです。
要約
重複しますが、とりあえず理解するのは以下だけで大丈夫です。
- 正答率 Accuracy
- 適合率 Precision
- 再現率 Recall
- (応用編として、F値 F-measure)
それぞれについて
---------
-定義
-例えばどういうこと？
-どんな時に使うの？
-弱点は？
---------
あたりを説明していきます。
正答率 Accuracy
正答率とは
正答率(Accuaracy)とは、「全部のうち、正解したものの率」です。
絵に表すとこんな感じ
例えば
- 全部で100件
- 売れると30件予測 → そのうち4件で実際売れた
- 逆に売れないと予測したのは70件 → そのうち69 件は実際売れなかった（1件は予測に反して売れた）
ならば、正答率は73%(=(4+69)÷100)です。
すなわち全体に占める
・予測も実際も『買う』 もしくは
・予測も実際も『買わない』
の割合です。
どんな時に使うの？
買う/買わない に偏りがない場合などに使う基本形だそうです。
実際、一見これで問題なさそうですよね。
・・・でも、今回のケースでは、使えません。
弱点は？
正答率は、今回のケースでは、そのまま使えません。
だって、とびこみ営業でコピー機買う会社なんて、5％もないから。
そうすると、「全員買わない」と予測すれば「正答率」は95％以上になってしまいます。
そこで登場するのが「適合率」です。
適合率 Precision
適合率とは
適合率(Precision)とは、今回のケースだと「『売れる』と予測したうち、実際『売れる』人の割合」です。
すなわち、絵で表すとこんな感じ。
例えばこういうこと
- 売れると30件予測 → そのうち4件で実際売れた
- 逆に売れないと予測したのは70件 → そのうち69 件は実際売れなかった（1 件は予測に反して売れた）
というケースであれば、適合率は13%(=4÷30）です。
「売れる」と予測した先が30件で変わらないなら、
実際売れるのが15件なら、適合率は50%(=15÷30)、
実際売れるのが24件なら、適合率は80%(=24÷30)と高まっていきます。
どんな時に使うの？
基本的には「打率を高めたい」時に使います。
裏を返すと、「売れると思ったのに、行ってみたら売れなかったリスト」を極小化するということです。
例えば、セールスパーソンの急な退職が続いて、訪問できる件数が限られているなら、
なるべく無駄打ちは少なくしたいはずです。
「ムダ打/ハズレを減らしたい」「打率を高めたい」「リソースが限られている」ケースなどでは、「適合率」は使えそうです。
今回のコピー機飛び込み販売のケースでも、「適合率」は結構良さそうです。
弱点は？
ところが、まだ問題があります。
なぜなら超厳選リストを作ってしまう恐れがあるからです。
例えば、
- 顧客リストが1,000件
- そこからの契約獲得件数目標が100件
というケースを想定します。そこで
- 売れると予測した先：10件
- そのうち実際売れる先：9件
ならば、適合率は90%になります。
確かに適合率は高い。
でも、 契約獲得目標が100件なので、あと91契約取らなくちゃいけない。
「残ったリストは990件は売れないと思います！」とか機械学習様に言われても、セールスとしてはアタックするっきゃない。
これじゃ、「機械学習を使ってセールスのアタックリスト作ってます」って世界はとっても遠い。
そこで登場するのが「再現率」です。
再現率 Recall
再現率とは
再現率(Recall)とは、今回のケースでいうと「実際売れる人全体のうち、事前に売れると予測できた人」です。
すなわち、絵で表すとこんな感じ。
例えば
- 売れると30件予測 → そのうち4件で実際売れた
- 逆に売れないと予測したのは70件 → そのうち69 件は実際売れなかった（1件は予測に反して売れた）
だったら、再現率は、80%(=4÷5)です。
ちなみに、実際数字いじってみるとわかりますが、
適合率と再現率はトレードオフの関係（どちらかを上げれば、どちらかが下がる関係）にあります。
どんな時に使うの？
「取りこぼしを最小化したい」時に使えそうです。
再現率を高めるということは、
「売れないと思ってアタックしなかったけど、もし行ってたら売れた先」を極小化する指標だからです。
「絶対的に獲得件数を増やしたい」「取りこぼしを最小化したい」「リソースや顧客へのアプローチ方法はたくさんある」
みたいなケースで使えそうです。
弱点は？
ただ、再現率だけを見るのも問題があります。
全員「売れる」と予測すれば、当然再現率は100%になるからです。
空振りの回数が増えるってことですね。 これまた機械学習の意味なし。
応用編：F値・重み付けF値 F-measure
F値とは
数式的には、こんな感じです。
・・って言われて分かる方は、この記事読んでいないと思います。笑
なので、思い切って「どんな時に使うのか」と「弱点」だけ理解すればいいと思います。
どんな時に使うの？
「バランスとってよ」です。
ただ、再現率と適合率をどのバランスで取って欲しいかは、ビジネスによって異なるので、この比重を変えた「重み付けF値」なるものもあります。
ただ、私はこの辺は理解する必要ないと思います。
「『バランスとってよ』って考え方あるんだな」くらいで十分だと思います。
弱点は
「バランスとってよ」なので、基本的に良さそうです。
「重み付けF値」なるものなら、さらに良さそうです。
ただ、ビジネス実務においては「バランスどこで取るか」って、状況によって結構変わります。
実際使える一覧表
以上、４つの「評価指標」について解説してきました。まとめるとこんな感じになります。
ただ、それぞれの評価指標には弱点があります。
なので、状況に応じた使い分けが必要です。
また、実際の評価指標はこれ以外にも色々あります。
逆に、これさえ理解できていれば「適合率は0.4くらいを死守してほしい。その中で、再現率を限界まで高めてほしい。そんな感じでいける？」みたいな会話ができるようになります。
私と同じく機械学習に苦しむ文系ビジネスサイドの方のお役にたてば幸いです。
『AIって何？ 』『機械学習って？』をもう少し勉強したい方は、こちらの本が大変オススメです。
マニュアル作成のシンプルな３つのコツ ：「わかる」「探せる」「更新しやすい」
この記事の内容
良いマニュアルを決めるたった３つの要素
仕事をしていると、引き継ぎなど様々な場面で「マニュアル」と呼ばれるものに、ちょくちょく出くわすと思います。
オペレーションを含むコンサルをしていると色々な会社の「マニュアル」を見る機会があるのですが、良いマニュアルと悪いマニュアルが如実にある。
これを分ける要素は、たった３つだと思っています。
すなわち、
- わかる
- 探せる
- 更新しやすい
たったこれだけ。
要素その１：わかる
業務マニュアルは、理解できるものでなくてはなりません。
目的に照らして、当然です。
しかし、実務上はこれを満たしていないマニュアルが山ほどあるのです。
例えば、
とりあえず業務フローで図示していて「なんかいい感じ」だけど、業務フローの記述ルールがめちゃくちゃなケース。
結局手順が全然わからない。
そもそも業務フローって、見慣れない人には難解極まりない。わけわからんフローで描かれるなら、文字いっぱいで箇条書きにでもしてくれた方がよっぽどマシです。
要素その２：探せる
そもそも、業務マニュアルは（多くの作り手の意図に反して）、最初から最後まで通読されることはほとんどありません。
あったとしても、せいぜい引き継ぎのタイミングで一回ザクっと読まれるだけです。
あとは実務の局面局面で
「あれ、これってどうやるんだっけ？」と、該当箇所だけを読む使い方の方が圧倒的に多い。
マニュアルは、字引きとして使われることの方が多い。
なので、良いマニュアルは必要な箇所を「探せる」ことが必須です。
そのため、目次や見出しに工夫はもちろん、
業務を発生サイクル（毎日やること/月サイクルで月初にやること とか）ごとにまとめるなどの工夫が、必要になります。
要素その３：更新しやすい
「業務は、時間の経過を経て変化する」
これは、マニュアル作成者が忘れがちな現実です。
業務は変化するので、マニュアルは常に更新され続ける必要があります。
更新しにくいマニュアルは
更新しにくい→更新されない→内容が古くなる→使われない というループに陥ります。
結果、最初はどんなに良い内容でも「役に立たない」マニュアルになります。
具体的に「更新しやすい」には２つ種類があります。
①更新必要箇所が、すぐ探せる
これは要素その２「探せる」と基本的に同義です。
一つのことに関する記載が、一箇所にまとめてあると、よりベターです。
②誰でも更新できるツール・やり方で作られている
これは実務で見落とされがちな要素です。
あるいは、凝った「お絵かき」をしても、後続の人はいじりにくい。
結果として、後続の人が更新してくれない、なんて残念なマニュアルをよく見ます。
３つをいいバランスで、実現させる
ここで難しいのが
要素その１：わかる
要素その３：更新しやすい
が、ある局面では、トレードオフになりがちだということです。
そして、実務上は「わかる」が重要視されすぎるので、
「わかる」を追求しすぎて、細かい記述や図解に寄りすぎて、「更新しにくい」マニュアルがよく見られます。
これを正しくやり切るノウハウは、色々あるのですが
まぁ、実際は「いいバランスで」くらいに考えておく、というのが現実解だと思います。
何れにせよ、マニュアルは「わかる」だけでは使われません。
「探せる」「更新しやすい」を意識して作成されるべき、というのが持論です。
- 作者: 日本能率協会コンサルティング
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2010/02/17
- メディア: 単行本
- 購入: 4人 クリック: 16回
- この商品を含むブログ (1件) を見る
インタビューが盛り上がる、たった３つの言葉
インタビューは有効。だから良いモノにしたい。
企画系の仕事していると、何か課題が発生したり、プロジェクトが始まりそうなタイミングで
「とりあえずヒアリングさせてもらっていいですか？」
みたいな局面、出くわしますよね。
私は、元コンサルで、今も経営企画のような仕事をしているので
「聞く側」として参加することが、圧倒的に多いのですが
たまに、インタビューが全然盛り上がらないタイプの方いますよね。
インタビューは、仮説構築・検証のために、とても有益な手法です。
どうせやるなら、いい情報を引き出したい。
「例えば」「つまり」「他に」の三言でいい：シンプルなコツ
コンサル時代に教わった偉大な教えなのですが、
インタビューのとき、困ったら
「例えば」「つまり」「他に」のどれかだけ言ってればいい。
例えば、こんな感じです。
「今の営業組織の課題はなんですか？」「マネジメントが機能していないことですね」「なるほど。例えば？」「いや、マネジャーがKPIをちゃんと見てないんですよ。メンバーの商談数を把握していないマネージャーだっているし、結局成果を見て『頑張れ』とか言っているだけになってる」「つまり、マネジメント、特にKPI管理ができていないってことですね。」「そうそう。だって、まともな帳票もないじゃないですか。」「確かに、見たことないかもしれませんね。ちなみに、他に課題に感じることはありますか？」「最近、引き合いの質が下がっている気がしますね。マーケチームが頑張って色々な引き合いを取ってきてくれているけど、全然熱くない引き合いが多い。結果として、対応するメンバーのモチベーションが落ちてきている気がします。」
つまり、
- 抽象を具体に落とす「例えば」
- 具体から抽象へ昇華させる「つまり」
- ヌケモレや議論の局地化を防ぐ「他に」
という、たった３つの言葉で、インタビューをコントロールできると。
「なぜ」は落選
この教えの一つのミソは、「なぜ」を敢えて(?)落選させているところだと思います。
私の解釈では、理由は２つあって
- 「なぜ」は、放っておいても大体聞くという経験則
- むしろ、「なぜ」を聞きすぎる結果、詰問ぽくなって目的を達しないインタビューが存在するという経験則
だと思っています。
「なぜ」が重要なのは超前提。
むしろ控えめでいいくらいだよね、ということ。
シンプルだから使いやすい
世の中に、インタビュー手法に関するノウハウは溢れています。
・まず、対象者の選定方法はカクカクシカジカで。
・準備にあたっては、アジェンダと目的を共有し、対面法の場合は・・・
・冒頭は、アイスブレイクとして・・・
・グループインタビューとデプスインタビューは、気をつけるポイントが違って・・
・・・覚えてられない。
そんな時に３つだけ
「例えば」
「つまり」
「他に」
手元のノートに書いてインタビューに臨むと、意外とうまく行ったりします。
高い目標を絶対達成する人は「1件1件をみる」
商品企画やマーケティング、ちょっとしたプロダクトオーナーの仕事も結構やってきました。
前年比１.５倍！2倍！いや３倍だー！みたいな目標も、多少はやってきました。
1.5倍とか3倍いう目標だと、今の延長線上には答えがないことが多いので、戦略から大きく見直したりして、どうにか達成しようと頑張ります。
いろいろやる中で気づいた共通原則の一つは、（戦略を見直したりもするんだけど）
「絶対達成する人は『1件1件自分で見る』というオプションを持っている」
です。
戦略の正しさは前提
そもそも、これだけ情報が氾濫する時代で、マーケティング戦略とか方向性のゆるい意味での正しさというのは、前提に近いです。
超イケてる戦略というのはそんなに出くわさないけど、「大きく間違ってなさそうな戦略」なら大体誰でもたどり着く。
じゃ、何で差がつくのか。シンプルに実行能力です。
仕組みは大切。でも仕組みだけじゃ勝てない。
仕組みは大切
実行能力の構成要素は、シンプルにいうと「オペレーション」と「人材」です。
戦略だけでは差別化が難しいので、オペレーションや人材（狭い意味での人材に加えて組織や日々のマネジメント）設計までできるマーケターはやっぱり強い。
そして、オペレーションや人材の問題は
「仕組みで解決する」
というのが定石。ここくらいまでは共通認識だと思います。
でも、仕組みだけではダメ
ただ、「仕組みを構築してもうまくいかないケース」を実務上はたくさん見てきました。
仕組みが良いのに売れないケース
例えば、セールス戦略を大きく変えて、ターゲットを変えて前年比２倍の成果を狙うマーケティング戦略を立てる。
でも、売れない。
そういうプロダクトオーナーは、大体、商談を「1件1件」ちゃんと見ていない。
「いやいや、俺は見ている」という人も多いと思います。
でも、セールスからの二次情報に頼ってませんか？20件くらいしか見てないんじゃないですか？
突き抜ける人は一つ一つみる
本当に突き抜けた成果を出す人は、100件くらいだったら全部自分でディレクションすることができる。
一つ一つちゃんと見に行くから、仕組みに設計者の魂が篭る。
なので、仕組みの設計が多少甘くても、趣旨通りに運用される。
そもそも、完璧な仕組みの構築なんて無理なんだから、魂を吹き込むことの方が、ずっと大事。
一つ一つ見ると戦略も磨かれる
そして、少し逆説的ですが一つ一つ細かく見た方が、大きな戦略も良くなることが多いです。
これは2つパターンがあります。
１つ目は、自分自身が一次情報に触れる中で「あれ、これは想定していなかったな」みたいな気づきが生まれ、そこから拡大して戦略が修正されるケースです。
最初は「あれ」という小さな違和感から、もう一度データを見直してみて「やっぱり」という確信に変わり、戦略修正してやってみたら成果が出て「よっしゃ」となる過程は、ミクロからマクロが繋がる瞬間で、めちゃくちゃ楽しい瞬間でもあります。
２つ目は、現場からのフィードバックの精度が上がるケースです。
一つ一つ見るということは、現場との対話に他なりません。
「これはどうなってるの？」の問いから
「なるほど、今回の施策はこういう目的だから、こういう時はこうしていいよ」
「確かに、こういうケースは想定できていなかったね。ちょっとルール修正するね。」
といった風な会話が積み重ねられていくことになります。
これをやっていくうち、戦略の背景にある意図や論理構造が、なんとなく現場にも憑依していきます。
また、「この人は、是々非々で成果を求めている」ということが現場に伝わるようになります。
背景や意図が伝わると、現場と「戦略にとって重要なインプット」の判断軸が揃います。
「是々非々で成果を求めている」ことが伝わると、必要な情報を物怖じせずにあげてくれるようになります。
こうなってくると、戦略のPDCAの速度・精度が上がり、成果は雪だるま式に増えていきます。
マクロとミクロを行った来たりする
もちろん、シニアマネージャーになって、自分で全部マイクロマネジメントするのは問題です。というか無理です。
ただ、最後の最後、現実を動かすのは1件1件の商談の積み重ねでしかない。
とはいえ、1件1件の徹底は、仕組みだけでは実際は限界があるので、ミドルマネージャーを活用して魂を吹き込まなくてはならない。
また、1件1件の商談を指導する営業マネージャーに「そうじゃなくて、仕組みとしてさ・・」みたいな愚痴を言う管理サイドの人がたまにいます。
でも、管理・事業両方やってきている身としては「確かに仕組みは大切。でも、1件1件徹底されていく泥臭い工程も同じくらい大切。」だと思うのです。さらに言うと、100商談くらいまでは「1件1件徹底」だけでどうにかなると思っています。
マクロに分析して、最後はミクロで1件1件見る。
そのあとは、マクロとミクロを自在に行ったり来たりする。
最後は、1件1件見られる人が、本当は強いと思うのです。
絶対達成マインドのつくり方――科学的に自信をつける4つのステップ
- 作者: 横山信弘
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2012/11/02
- メディア: 単行本（ソフトカバー）
- 購入: 6人 クリック: 41回
- この商品を含むブログ (1件) を見る
「ECRSの原則」とは ：業務改善は、最初に「やめる」を検討する
ECRSの原則とは、業務に対する改善を
- Eliminate（やめる）
- Combine（他と一緒にやる/分けてやる）
- Rearrange（順番や担当者を入れ替える）
- Simplify（簡素化 / システム化）
の4つに分けて、1から順番に検討していきなさい。
というものです。
最大のポイントは「順番」
ここで最大のポイントは、「順番」です。
特に、
最初に「やめる」がきて、
最後に「システム化」来る
ということです。
必ず、最初にやめるを検討する
「やめる」が最初に来るべき理由は２つあります。
①一番カイゼン効果が大きいから
②目的が明確化されるから
①一番カイゼン効果が大きいから
業務削減効果が一番大きいのは、その業務自体を「やめる」ことです。
改善幅が必ず100%になるから。
さらに、カイゼン実行に必要な色々を考えなくて済むので、
カイゼン活動自体も効率化されます。
②目的が明確化されるから
ただ、実際の業務はそう簡単にやめられるものは少ないです。
それでも、絶対に最初に「やめる」を本気で検討すべきです。
なぜなら、その業務本来の目的が浮かび上がってくるからです。
そして、実はここがECRSの本当のミソ。
目的がないところで業務改善はあり得ない
実際、コンサル時代、お客さんに
「この業務、やめたら困ります？」
と聞いてました。
そうするとお客さんは
「そりゃ困るよ。だって・・・。」
と、答えます。
実はこの回答を待ってたりします。
この「だって・・・」こそが、その業務が存在する本来の目的だからです。
そうすると
- その目的は、本当に必要なのか？
- その目的に対して、今のやり方は正しいのか？
- その目的だったら、他の業務で代替できるのではないか？
と、具体的な改善策に切り込んでいけることが多い。
そもそも、目的ないところで改善策なんて、本来考えられっこないのです。
あらゆる業務は、何かの目的のために、人が作り出したものなのだから。
業務の目的の確認抜きで業務改善の議論をすると、ほぼ例外なく過剰/過少品質になります。
そして経験上、
「この業務の目的は？」と聞くより
「この業務やめたら困ります？」と聞くほうが
本質的な目的が見えることが多い。
だから、最初に「やめられないか」と問う。
実際「やめる」という最短ゴールを模索しつつ、
業務を残す場合の改善議論のキモとなる「業務の目的」を確認することが、大切なのです。
あとはご自由に。ただ、システム化の原則は最後。
業務の目的が明確になったら、もう８割は成功です。
なので、正直
2.Combine（他と一緒にやる/分けてやる）
3.Rearrange（順番や担当者を入れ替える）
4.Simplify（簡素化 / システム化）
の内容とか順番まで、多くの人は覚える必要はない。
ただ、一つだけ留意するなら、
「自動化・システム化は最後に検討」です。
これには２つ理由があります。
①自動化・システム化には時間・コストがかかる
②自動化・システム化すると、「悪いやり方が固定化」する
昨今、理由の①は成り立たなくなりつつありますが、
②とか、傾聴に値するなぁ、と私なんかは思います。
「自動化しちゃえばいいじゃん」ではなく「やめればいいじゃん」
ITベンチャーに勤めてると、条件反射的によく
「そんなん自動化すればいいじゃん」
という話になります。
でもその前に、ちょっとだけ
「てか、そもそもやめちゃわない？」
と問いたい。とってもいいことがあると思います。
なぜ、あの部門は「残業なし」で「好成績」なのか? 6時に帰る チーム術
- 作者: 小室淑恵
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2008/12/30
- メディア: 単行本
- 購入: 8人 クリック: 175回
- この商品を含むブログ (75件) を見る
- 作者: 日本能率協会コンサルティング
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2010/02/17
- メディア: 単行本
- 購入: 4人 クリック: 16回
- この商品を含むブログ (1件) を見る
総務部の本当の役割考察 〜理想の総務部は「自らシゴトを作り、自らを切り出す」
意外と共通認識がない「総務の理想形」
総務とか管理部と呼ばれる組織は、世の中にたくさんあるのですが、その「理想形」については、あまり語られることがないと思います。
セールスやマーケ、商品開発などの組織に比べて、「理想形」の共通認識がない気がします。
そんな背景もあり、昔、コンサルの大先輩にふと「理想の総務部って？」という問いを投げたことがあります。
その答えが
「シゴトを作るところ」
というものでした。
聞いた瞬間、「シゴトを作る」という表現に強烈な違和感を覚えました。
が、詳しく聞いていくと、「これはアリかも」と思えるコンセプトだったのです。
自分なりの解釈も追加して、紹介したいと思います。
「理想形」を語るにも共通の議論の拠り所も少ない総務部論（？）において、
議論の一つの出発点としては割と結構いい線行くんじゃないか、と思っています。
結論として、歴史に学ぶと、
理想の総務部は「自らシゴトを作り、自らを切り出す」という話です。
一般的に、総務部は何をしているのか
そもそも、総務部に含まれる機能は、例えば以下のようなものです。
※下の方は、専門の部署がある会社も多いと思います。
- 固定資産・オフィス管理
- 消耗品管理、備品管理
- 文書管理
- 社内システム運用
- 受付・来客対応
- 慶弔対応
- 福利厚生
- 会社行事運営
- 社内広報
- 社外広報
- リスクマネジメント
- 株主総会・IR
ポーターのバリューチェーンの支援活動の「色々」のうち、
① 少量で部門として切り出すほどじゃないもの
② 業務として定義しにくいもの
を総務部がやっている、と捉えるのがわかりやすいと思います。
その具体例が、上で挙げたような業務なのだと思います。
自らシゴトを作り、自らを切り出す：歴史に学ぶ強い総務部
上述の通り、総務部と呼ばれる組織の仕事は、ポーターのバリューチェーンの間接部門の「色々」のうち、
① 少量で部門として切り出すほどじゃないもの
② 業務として定義しにくいもの
と考えられます。
しかし、
① 少量で部門として切り出すほどじゃないもの
→組織の成長・変化や世の中の変化で重要課題となって業務量が増えてくると、この定義に当てはまらなくなってきます。
② 業務として定義しにくいもの
→世の中の変化で専門分野として確立してくることで、業務の定義できるようになってくるとこの定義に当てはまらなくなってきます。
という感じで、時代や組織の変化に伴い、状況は変わります。
これは、世の中の組織図の歴史（あるいは会社の成長）と重ねて考えると理解しやすいです。
総務がシゴトを作るとき
例えば、40年前の会社組織図を想像すると、「情報システム室」なんてない会社がほとんどだったはずです。
ところが、コンピューターの普及によって、コンピューター・情報システムの調達・運用機能が会社に必要になってきた。
初期においては、総務部が、世の中の変化や社長・事業部の「コンピューター使いたい」みたいな話を受けて、実際に導入しながら、会社として必要な調達・運用のルールや資産管理方法などを作っていったのではないかと思います。
もし当時、受け身で「コンピューター」というポテンヒットを拾うにとどまらず
時代の動きや自社の事業への鋭い洞察をもとに、むしろ積極的に、役員や事業サイドに先回ってコンピューター導入を議論して、役員や事業サイドを説得し切って、事業成果まで繋げた総務部があったとしたら、
それは、理想に近い総務部だと思うのです。
つまり、外部・内部の変化を見逃さず、必要な課題とこれまでにない業務を定義して、経営成果を最大化するという意味で「シゴトを作れる」総務部は強い。
（追記）
2020年のコロナウイルスの対応でも、総務部の対応分かれた気がします。リモートワークや職域摂取を積極的に仕掛けられたかとか。受け身にならず、いい意味で自分から「シゴトを作る」ことで従業員やビジネスを守った総務部があるんじゃないかと思っています。
総務が自らを切り出すとき
「情報システム室」の例を続けます。
さらにコンピューター普及が進む中で、業務の規模と重要性が増えてきたはずです。
例えば、一人一台パソコンを持つようになり、インターネットが普及しセキュリティなどの課題も増えてきたかもしれません。
これくらいのタイミングで、総務部から切り出す形で「情報システム室」みたいなのが生まれた、そんな歴史をたどった会社は多かったはずです。
（同じようなことが、中小企業が大きくなる過程でも発生すると思います。例えば、中小企業で「法務」「IR」などの領域が、総務部（管理部）から独立する過程は、想像がしやすいかと思います。）
自ら作り出したシゴトに対して、専門化を進めれば、業務はより明確に定義できるようになります。
また、そのシゴトが時代を先取りしたものなら、必然的に少しずつ重要性と業務量は増えていくはずです。
そうなると、だんだん冒頭の「総務部」の定義にある「少量」「定義しにくい」という枠に収まらなくなってきます。結果として、自らを切り出して別部署とする瞬間が来るのです。
つまり、会社や世の中の流れを汲んで専門化を進め、最後は別組織化するという意味で「自らを切り出せる」総務部は強い。
自らシゴトを作り、自らを切り出す
このように
- 外部・内部の変化を見逃さず、必要な課題とこれまでにない業務を定義して、経営成果を最大化するという意味で「シゴトを作れる」
- そして、会社や世の中の流れを汲んで専門化を進め、最後は別組織化するという意味で「自らを切り出せる」
という2点が、理想の総務部の重要ポイントという見方が成立すると思うのです。
理想の総務論の一つの出発点
この話は、ベンチャーだと「管理部」と呼ばれる組織の一部にも適用できると思っています。
私は総務の仕事をする人をとても強く尊敬しています。
隣人愛に溢れているから。そして、会社を支えてくれているから。
しかし、世の中一般的にキャリアや働きがいの文脈で「総務」という仕事がポジティブなイメージが持たれているかというと、残念ながらそうでもないと思います。
確かに、古い会社だと「総務は出世ルート」なんて話もあると思います。
でも、なんか多くの人にとって、「総務部の3ヶ年ビジョン」とか、ワクワク感を持って描きにくくないですか？
そんな中、
「自らシゴトを作り、自らを切り出す」
は、総務部の理想形の一つだと、私は思うのです。
当然いろいろな組織があっていいと思うので、絶対的な正解ではないかもしれないけど、議論の一つの出発点としては割と結構いい線行くんじゃないか、と思います。
このコンセプトをスタートとして、具体に落とす中で、総務部がワクワクするビジョンも描けるような気がしています。
おまけ）経営企画の役割も参考になるはず
総務部や管理部と近い組織として「経営企画」なんてのもあります。その役割について考えることも、総務部や管理部の役割を考える上で参考になるはずだと思っています。
ということで、その役割についてもまとめました↓
参考になりそうな本↓
機械学習プロジェクトで、予め精度の保証を求めてはいけない：ビジネスサイドから見たAIプロジェクトのコツ
機械学習のプロマネは、普通のプロマネとちょっと違う
最近、機械学習とかAIを使ったプロジェクトに関わる機会が増えてきました。
世の中的にも、機械学習を使ったプロジェクトは増えているように思います。
自分は機械学習の専門家ではありませんが、
そして、そのような役割の人間からすると
予め精度の保証を求めてはいけない
その一つが、機械学習を使って予測・判断のモデルを構築するプロジェクトにおいて、「予め予測精度の保証を求めてはいけない」ということです。
機械学習を使って、予測モデルを作るプロジェクトで
みたいなやり取りが発生し、ビジネスサイド「それって、どれくらい精度出るの？」データサイエンティスト「やってみないとわからないです」
結果、お互いモヤモヤが残る。
こんな場面に遭遇したことある方、少なくないはずです。
これには、構造的な背景があると思っています。
機械学習プロジェクトの大まかな流れ
そもそも、機械学習のプロジェクトは、大まかに以下のような流れを取るようです。
①ビジネス上の課題定義 ＞ ②データ収集 ＞ ③分析・モデル構築 ＞ ④システム開発 ＞ ⑤運用
今回は、上記の①とか②の段階で「精度を求めてはいけない」という話です。
例えば、「会計ソフトのデータから、倒産リスクを予測する」というモデルを構築するとします。その場合、
「①ビジネス上の課題定義」では、
- そもそもなぜ倒産リスクを予測したいのか
- 「倒産リスク」とは何年後の倒産リスクなのか
- 具体的に、そのアウトプットを使ってどんなことがしたいのか
- なぜ、今の手法のままではいけないのか
などを定義します。
「②データ収集の工程」では
- 考えられる変数（特徴量）は何か
- どういったデータが取得可能か（社内/外）
- それは、過去および未来に渡って、どれくらいの期間取得が可能か
- データ量は、機械学習に十分か
などの検討に加え、実際の学習用のデータを作る泥臭い作業が待っています。
これらを経て、
「③分析・モデル構築」の工程で初めて、様々な試行錯誤を経て、精度XX％の倒産予測モデルが構築されます。
なぜ、事前に精度を求めてはいけないのか
冒頭の
というやりとりは、このプロセスに沿って理解するとわかりやすいです。ビジネスサイド「それって、どれくらい精度出るの？」データサイエンティスト「やってみないとわからないです」
データサイエンティストの言い分
まず、データサイエンティストからすると、
実際、「③分析・モデル構築」の工程に入らないと、精度はわからないことが多いでようです。
これは、単に予防線を張っているわけではなく、実際わからないことが多いようです。
その理由を聞くと
あたりが主要な理由なようです。
ビジネスサイドの言い分
他方で、ビジネスサイドからすると
- そもそも、何らかの施策を打つんだから、投資対効果を知りたい。せめて精度の目処は欲しい。
- ちゃんとスケジュール引きたい。
- 「①ビジネス上の課題定義」「②データ収集」と、「③分析・モデル構築」の初期だけでも、相当時間を投資することになりそう。だから尚更早めに目処が欲しい。
なので「それって、どれくらい精度出るの？」と聞きたくなってしまう。
この２つによって、不幸な行き違いが生まれるのだと思います。
解決の方向
基本的な方向は「３パターンくらい、ゆるく、見立てを共通認識とする」
では、どうするのか。
結論としてお勧めしたいのは、
「楽観 / 悲観 / 中間シナリオ くらいのゆるさで、精度の見立てを分析サイドとビジネスサイドで共通認識として形成すること」
です。
実際、データサイエンティストに聞いてみると、実際は、楽観 / 悲観 / 中間シナリオ くらいなら、経験に照らして見立てを出せるケースが多そうです。
ただし、この見立ては外すことも多そうなので、約束・目標とするのは抵抗があるとのこと。
なので、事前の精度の見立ての必要性に関する共通理解の下、あくまで「見立て」であって「コミットメント」ではないことを強調しつつ共通認識を形成する
そうすれば、（変数の振れ幅大きくて難しいのですが）プロジェクトを設計・遂行できると思うのです。
データサイエンティストに求められること
そのために、データサイエンティストには
- なぜ、精度を予め保証できないのか（上述のような理由）
- 世の中的にもそんなもんだということ（できれば、具体的な事例ベースで）
を、ビジネスサイドに対して（どうか「こいつアホだ」と諦めずに）分かりやすく説明いただけると嬉しいです。
そして、
- ビジネスサイドは、ビジネス上の課題解決にすごいプレッシャーを負っていることへの理解
- ビジネス（特にオペレーションレイヤー）って内部/外部環境のちょっとした変化で打ち手変わるから、リクエスト（課題定義）が曖昧なのは仕方ないこともあることへの理解
- プロジェクト設計上必要なら、「参考程度ゆるい見積」として楽観 / 悲観/ 中間の３パターンくらいで、精度の見立てを提供できること
を示してくれると、もっと嬉しいです。
ビジネスサイドに求められること
逆に、ビジネスサイドの人間としては
- 上述のような理由から、事前に精度を保証させるのは無理っぽいということ
- それは世の中的にもそんなもんで、今自分の前にいるデータサイエンティストの腕が悪いのでは決してないこと
をしっかり理解する必要があると感じています。
その上で、
- とはいえ、ビジネスとしては課題を解決したいこと（その向こうにお客さんや世の中がいること）
- プロジェクト設計はしたいから（「見立てが外れても俺のプロマネ力でどうにかしてみせる！」という気概を持って）「参考程度ゆるい見積」として楽観 / 悲観/ 中間の３パターンくらいでいいから、見立てがほしいこと
を、データサイエンティストに誠実に伝えなくては、と思っています。
そして可能な限り、統計や機械学習の勉強をして、見立ての背景にある変数や、各シナリオの成立条件について理解できるようになりたいと思っています。
（「最初の一冊」には「文系ＡＩ人材になる―統計・プログラム知識は不要」がオススメ）
そうはいうものの、、
ただ、そうはいうものの、こういうコミュニケーションは、現状としてどうしても限界があります。
なぜなら、ビジネスサイドは「数式アレルギー」ある人多すぎるし、
他方でデータサイエンティストは、「正確だが難しい数式」か「過度に簡略化した比喩」や「こういうもんです！」で説明しがちで、「ちょうどいい塩梅」の説明ができる人が少ない（気がする）からです。
なので、その間に立てる人材になれれば、あと５年くらいはバリューの出しどころがあるんじゃないかなぁ、と個人的には思っています。
<<関連記事>>
そもそも「精度」って書いちゃいましたが、ビジネスサイドがなんとなく使う「精度」には色々な意味合いがあります。その辺も解説しました。
ビジネスサイドの人に 「文系AI人材になる」はホントおすすめ
