支持率から許容誤差を考える

1月 18th, 2017 | Posted by admin in 長橋のつぶやき - (支持率から許容誤差を考える はコメントを受け付けていません)

以前、ビックデータ時代だからこそスモールデータの手法の理解も大事というエントリを投稿しました。

で、自分はあまりテレビを見ないのですが、たまたまCNNによる世論調査で1000名を対象に米国時期大統領トランプ氏を支持するかしないかについて、世論調査したところ以前オバマ氏が81%のところ40%で支持率が低いという報道でした。

あらかじめ言うと、自分はこの結果に、とく賛成・反対はありません。むしろ、純粋にデータサイエンス的にこれが有意かどうか純粋に興味があります。

一番、確実なアプローチは、米国民3.189億人に賛成か反対かを問うこと。いわゆる、ビックデータのアプローチ。ただ、これが本当にできるかといえば意外と難しい気がする。11月の大統領選挙でも、多くのメディアがヒラリー氏優先と伝えたものの、蓋を開けたら違う結果になったように、”ビックデータ”で解決できる話でないと思う。

となると、やっぱり、母集団からサンプリングして、そのサンプルから母集団を推定するというアプローチが妥当で、統計の世界では、サンプルの許容誤差という考え方があります。一般的には誤差5%つまり100のうち95が正しくて5が誤ると想定すると、許容誤差のサンプル数は(正規分布の5%信頼水準 1.96)^2 x (支持率 0.5x非支持率 0.5)/(標本誤差 0.05)^2 = 384、つまり、384人にアンケートを取れば、理論上、許容誤差に収まる、なので、1000人は許容誤差の範囲といえるかもしれない。

ただ、この5%の許容誤差を1%にすると、(正規分布の5%信頼水準 2.58)^2 x (支持率 0.5x非支持率 0.5)/(標本誤差 0.01)^2 = 16,641人、384人くらべて43倍のサンプル数が必要になる。

というわけで、ここから何がいえるか?この許容誤差の5%というのは、完全無作為に抽出する前提であれば成立するかもしれない。ただ、ただでさえ、CNNはトランプ氏から”うそのメディア”というレッテルを貼れて、質疑を拒否されたほど対立関係にあるので、もしかしたら、何かしらのバイアスがかかって”完全無作為”とはなっていないかもしれない。

というわけで、この精度をあげるには、1.CNNとは独立な機関によってサンプル抽出する、もしくは、2.許容誤差を5%から下げる、ともう少し尤もらしくなると思うのでした。

理学と工学

5月 15th, 2013 | Posted by admin in テクノロジー | 経営 - (理学と工学 はコメントを受け付けていません)

最近思うこと、同じ”理系”であっても、理学と工学は結構違う。

理学の代表は物理、数学で、世の中の真理・法則を探求することだと思う。たとえば、宇宙はいつできたか、とてつもなく難しい問題だけど、ある仮説を提示して、その仮説を裏付ける様々な状況証拠を一つ一つ積み上げながら、ロジックをくみたてて、証明する。コンサルタントに理学部出身が比較的多いのも、フィールドが違えど、ロジックを組み立てて、仮説を検証するという点では、やってることは結局同じなのかもしれない。

一方、工学の場合は、どちらかというと、”こんなん、作りました”というアプローチ。たとえば、ロボット作るという場合、もちろん、仮説を立てて、それを証明するのも大事だけど、それ以上に、失敗を恐れず、ひたすら、改良に改良を重ねて、誰も作っていないものを作る。何もないところから、新しいものを生みだす、そういう点だと、ベンチャー企業経営に近いかもしれない。

最近思うことは、理学的な分析思考がパーフェクトながらも、工学的なフロンティアマインドを持ち合わせている人は、ほとんどいないということ。そう、一人ではできない、だから、チームを作って、それぞれの特性を引き出す。当たり前なんだけど、その当たり前の大事さを気づきました。

スペックを書くコツ

3月 20th, 2013 | Posted by admin in テクノロジー | 経営 - (スペックを書くコツ はコメントを受け付けていません)

これまで、ビジネスとしてシステムのスペック(仕様)を書く仕事をしてきて、スペックの書き方にはコツがあるなあと思うようになってきた。

ちなみに、ここでいう、スペックは、システムをつくる上流工程での要件定義・基本設計で、それをもとにシステムを作ったり、あるいは、ベンダーにRFP(Request For Proposal)として提示して、見積もりをお願いしたりする。そして、要件定義・基本設計を大きく外さなければ、それに続く設計・実装もそれほど大きく外れることはない。言ってみれば、建物の設計図に相当するもので、作ってみたら、”柱が足りなかった”、”家が傾いていた”、ということがあってはならない。

それで、どうやってスペックを書くか、一言でいえば、”漏れをなくし、重複をなくす”だと思う。

 これはコンサル用語でいうところ”MECE(Mutually Exclusive and Collectively Exhaustive)”であり、漏れなく、重複なく、は当たり前のことなんだけど、これが以外と難しい。結局のところ、何が漏れているのか、全体像が見えていないとわからないし、経験を積まないと、失敗するポイントも見えてこない。

 どうやって漏れと重複をなくすか?その一つのアプローチとして、自分がいつも心がけているのが、証券アナリストをしているときに教わった”分解して考えるべし”という考え方だ。たとえば、ある会社の売上高が100億円だったとして、その100億円が、業種別(金融30億円、製造業70億円など)、セグメント別(コンサル10億円、システム開発60億円、物品販売30億円など、そして、この組み合わせによって粗利が決定される)に分解することができる。そして、その分解の粒度(金融であれば、そのうち、銀行、証券、保険など、さらに銀行であれば都市銀行、地方銀行、最終的には個社(MUFJなど)に帰着する)を上げれば上げるほど、その会社の特性、何が伸びて、何が落ち込むのか、おぼろげながらわかってくる。

 これはスペックを書くときも同じで、結局、経営もしくは発注側は、”ECのシステム作りたい”など漠然としたリクエストが多い。その漠然としたコンセプトを漠然としたままでいくと、結局できるものも漠然としてしまう。だからこそ、分解して、分解して、分解する、その過程で、不必要なところを削り、必要なところをさらに深堀りする。これを繰り返すことで、漏れなく、重複なく(MECE)を実現できるケースが多い。もちろん、分解しすぎて、全く当てが外れることもあり、どこを捨てて、どこを深堀りするかの勘所を押さえるのは経験によるものだと思う。

 いってみれば、このMECEは分解した後の結果であり、それ自体は目的じゃないと思う。そして、分解して、分解して、分解する、これが重要なんだと思う。