
既存の凝り固まったマネジメントスタイルの方にデータサイエンスの不確実性を理解(わか)ってもらうためには
先日大学でデータサイエンス関連の講義をした際に、タイトルのような質問を頂きました。
既存の凝り固まったマネジメントスタイルの方にデータサイエンスの不確実性を理解してもらうためにはどうしたらよいでしょうか(一部意訳)
その時は咄嗟に答えが出てこなかったのですが、その後思考を巡らせてみて「こういうことかな」と思ったので、ちょっとそれを書いてみようと思います。
「既存の凝り固まったマネジメントスタイル」とは
まずは共通認識を持つために「既存の凝り固まったマネジメントスタイル」について考えてみましょう。
私が考える「既存の凝り固まったマネジメントスタイル」は、
計画ドリブン
予実管理と評価
コマンド&コントロール
といった印象です。
計画ドリブン
何よりも、計画を立てるところから始める、という考え方です。
それ自体は何ら悪いことはなくて、むしろ大切なことではあります。ですが、データサイエンスの業務が始まる際は、
顧客の真の要望
データの中身
どのようなアウトプットを求めているか
メンバーのスキル
といったことがほぼ分からない状況です。つまり不確実性がめちゃくちゃ高い状況です。私はこんな時、不確実性コーンを思い出します。「初期コンセプト」の段階では、見積もりは0.25倍~4倍もずれると言われているのです。

『プロジェクトの本質とはなにか | 日経クロステック(xTECH)』より引用
https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/
また、「計画を立てる」ということ自体がタスク化してしまい、それが一大イベントのようにスケジュールに組み込まれ、計画を立てたことで満足するような雰囲気もあります。
予実管理と評価
上記のように一大イベントとして計画を立てたものですから、マネージャーとしてはその計画通りいかないと困るわけです。ですので、計画(予定)と実績が乖離していないかどうかのいわゆる「予実管理」が始まるわけです。そして、「進捗率は90%です」「進捗率は95%です」「進捗率は98%です」…といった謎のチキンレース報告会が始まります。
これに紐づいて、その人やタスクの評価も決まったりします。
即ち、計画通りいけばOK、計画通りいかなければNG、というものです。計画通りいかないと、それはその人が悪かった(さぼった、頑張らなかった、スキルが足りなかった、など)と評価されてしまいます。
コマンド&コントロール
上記の計画ドリブンに繋がるのですが、旧来型のマネジメントスタイルではおそらく「計画を立ててそれを指示(コマンド)し、制御(コントロール)する」という考え方が根強いように感じます。
ものすごく端的に言えば「オレの言う通りやれ」というところでしょうか。
なぜ凝り固まってしまうのか
さて、上記のようなマネジメントスタイルは、従来は「それが当たり前」でした。そういったことがいかにうまく出来るようになるかがマネージャーのキモである、という考え方さえあったのです。
そのため、多くの方はこの考え方を「神様」のように扱っています。疑うということがないんですね。
正しい例えかどうか分かりませんが、これは鳥が生まれて初めて見たものを親だと思ってついていくというインプリンティング(刷り込み)のようなものだと思っていて、ある意味しょうがないことだと思われます。
理解してもらうには?
では、このような方にデータサイエンスの不確実性を理解してもらうにはどうしたらよいのでしょうか。
私は所感としては「かなり難しそうだなー」という印象を抱いています。
というのも、おそらく理屈だけでは理解してもらえなさそうで、感情や現状に訴えかけないといけないからです。
もしかしたら、「それよりも全く何も知らない人に育ってもらった方が早いんじゃない?」って思うぐらいです(築50年のボロアパートを改修して若い人が住めるようなアパートにするのは難しいけど、一度全部取り壊して更地にしてから新しくマンションを建てる方が早いし安い、みたいなのと同じ)。
ですが、そうはいっても人材不足の世の中ですし、いまいる人で何とかしないといけない、という状況はありそうですよね。
そんなわけで、「理解(わか)ってもらうには?」を考えてみました。
アンラーン
知っておくとよさそうなのが、unlearn(アンラーン)という考え方です。
「思考のクセ」を自ら認識することが、まずは第一歩ではないかと思います。
つまり、先述のような「計画ドリブン」「予実管理と評価」「コマンド&コントロール」をいったんわきに置いておく、というのが良いかと思います。
これは私が研修(講座)でやった事例ですが、冒頭に「皆さんがこれまでにやってきたことはリスペクトしますが、そのうえでいったんこれまでの経験をわきに置いておきましょう。忘れなくていいですよ、いったん置いておくんです」みたいな声掛けをしました。
敢えてPMBOK(第7版)の話をする
あるいは、敢えてPMBOKの話をしてみても良いかもしれません。
PMBOKはそれこそ第3版・第4版の頃は旧来型の凝り固まったマネジメントスタイルの権化みたいなものでしたが、最新版の第7版ではアジャイルの考え方がかなり取り入れられています。
そもそもプロジェクトには「計画型」と「適応型」があるとされています。そのような国際的な権威あるものでさえ「適応」を訴えているのですから、そういった話をすれば「もしかして自分の考え方が古いのかも?」と思うようになるかもしれません。
現場の仕事をやってみる
または、現場で自ら仕事をしてもらってもいいかなと思います。
私は、野球をやったことがない人は野球の監督をすることが出来ないと思っています。当たり前じゃん、って思うかもですが、現実の会社では実はそうではないケースが多く「やったことがない業務のマネージャーに就く」ということが多いです。
マネージャーの方は「自分は手を動かさない」ことが正義だと思っている可能性があります。そこで、敢えて現場の仕事をしてもらうのです。なんでも良いのですが、できれば自分が計画を組んだ仕事が良いかもしれないですね。まずはそれを手を動かしてやってみることで、いかにそこに不確実性が高いのか、計画通りうまくいかないのか、を体感してもらうと良さそうです。