はてなで働き始めてからほぼ5年になるので振り返ってみる

はてな

そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。

NTT CS研 => 株式会社はてな

基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。

割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単独出せる価値よりもデータのライフサイクルを含めて考えるほうがより価値が出せると思っての転職だった。転職することを決めたときに何だかんだ言われることも多少あったような気もするが*1、転職してはてなでしばらく働いてもこの思いは強くなる一方なので、いい転職だったんだろうなと思ってる。文系から理転したときも、筑波を退学してNAISTに入学したときもそうだけど、他人が何言おうが自分が心の底から納得できることが大事なんだろうなって思う。他人は自分の人生に責任を取ってくれるわけじゃない。

もちろん、職種が変わったこともあって、以下にも書くように最初はキャッチアップがめちゃくちゃ大変だった...。

チーム開発への適応

入社前も研究職としてコードは書いていたし、gitでリポジトリ管理していたが、基本的にコードは一人で書いていた。チームメンバーと共同でタスクをやることも当然あったが、共通インターフェイスはテキストファイル(tsvやjson)をNFSファイル上に置いてやり取りする、というような世界観。論文は先輩からたくさん添削していただいたが、コード自体を見てもらうことは特になかった(いい悪いとかじゃなくてそういう職業)。

はてなに入社してからは日常がチーム開発になったが、入って一年くらいはめちゃくちゃ四苦八苦していた。一人で開発していたときよりリポジトリはでかいから全体像がそもそも見えてないし、コードリーディングする力も弱いし、今だったら絶対レビューしたくないような行数のPull Requestは送り付けてたし、全体の手順をうまく考えられていなかったので、時間かけて書いたコードもバンバン手戻り発生していた。ダメなエンジニアの典型例。

どうやって解決していったかを思い出すと、チームメンバーや技術グループのメンターの人にレビューで指摘してもらったり、こうしてみるといいではないかというアドバイスをもらいながら、少しずつマシになっていったかな...という感じ。環境に恵まれていたとしか言いようがなく、エンジニアとしての基礎体力をかなり上げてもらったなと思う。

インフラ苦手意識の克服

入社してからとにかくインフラ方面への苦手意識があった。障害が起きても何が起きているのか最初は全然分からなかったし(戦力以前の問題)、何か実現したいと思ったことがあってもインフラ方面だとそもそもどう動くといいのかも全然分からなかった。Webアプリケーションエンジニアとして働いていく上で、これはどう考えてもヤバイ。しかし、会社の本番環境はまあまあでかいし、試行錯誤するのも大変。

そこで、自分で全てを把握できる小さい砂場環境を作ることにした。これは(元も含む)同僚のid:a-knowさんやid:aerealさんが同じようなことを先にやられていたのに刺激されたり、当時メンターだったid:shiba_yu36さんにアドバイスもらったことがきっかけ。

この活動は完全にやって正解だった。サーバーが5xxを返そうがDBが吹き飛ぼうが、痛いのは自分だけなのでいくらでも失敗できる。構成も一発で正解に行き着く必要がなく、あえて遠回りして馴染がなかったコンポーネントで遊んでも誰にも迷惑をかけない。仕事と違って全てを一人でやる必要があるので*2、必然的に全体のアーキテクチャを考える経験もできる。締切があるわけでもないので、自分の好きなペースでできたのもよかった。

後述する異常検知の機能を作るときに、この経験は血肉となってとても役に立った。過去の自分と比べてインフラ方面への全体の理解度が上がったし、以前と比べるとSREやインフラ方面の人と話すときにビクビクすることがなくなった*3。

教師なし機械学習の本番環境での運用

Mackerelに「ロール内異常検知」という機能をPoCから実際の開発、運用、機能改善とほぼ全てのフェイズにメイン開発者として関われる機会に恵まれた。

これは今考えてもめちゃくちゃチャレンジングな内容で、アラートというセンシティブな形でユーザーが目にするものを機械学習でリアルタイムに、しかもそれを教師なし学習*4でやるというハードな内容。ユーザーはたくさんいるので誰にでも使えるモデルを事前に作り込むのは困難であり、ある種のAutoML的な側面もありさらに難易度も高かった。

PoCの段階では色んなモデルや競合ツールをたくさん試した。時系列ベースの異常検知は結構パラメータ設定が難しく、ある程度頑張ったくらいだと誤検知があまりも多く、これだと使われないだろうなという感触があった。機械学習に詳しくない人をペルソナにしているので、そもそもハイパラ設定をユーザーにさせたら負けくらいに思っておかないといけない(当時のプロダクトオーナーであるid:sugiyama88さんやid:Songmuさんからも要望があった)。

異常検知自体を扱うのがそもそも自分は初めてで、自分のアプローチは筋がいいのか全く自信がなかった。異常検知ナイトという東京のイベントに登壇してアドバイスをもらったり、そのイベントの帰りで偶然一緒になったPFNの人(工場のデータで異常検知をやっている人だったのでラッキーだった)とラーメン食べつつあれこれ教えてもらったりしたのもいい思い出。

異常検知自体はSaaSなどでも当たり前に提供される時代になってきていて、機械学習にかけれる開発人員工数を考えると「Mackerelで」異常検知ができることの価値って何だろうか...というのを大分悩んだ。異常検知の開発より少し前に機械学習サブ会という社内の技術的なグループを立ち上げていたが、機械学習というある程度専門性が必要な内容(今でいうMLOpsとか)を相談できる場所があることに大分救われていた。

悩みに悩んだ末、Mackerelの基本的な概念である「サービス」「ロール」に戻ってきた。同一のロール内であれば、サーバーの挙動はある程度統一的になるし、理想的なMackerelの利用をしてもらえればもらうほど予測もしやすくなる。Mackerelをいい感じに使ってもらえば、異常検知も勝手にいい具合になることが期待できる。すごく単純な仕組みではあるが「Mackerelで」異常検知ができることの価値が自分の中でも腑に落ちた。実装面でも混合ガウスモデルという非常に枯れた*5モデルで実装することができた。

ベイズ的な確率的生成モデルであるということも地味に効いた。異常検知でサーバーのアラートを出す際に「どのメトリックが特におかしいかも知りたい」という要望に対して、周辺確率を使って一つのモデルでアラートの要因になったメトリックも提示できる。「このくらいのメトリックの揺れはアラートして欲しくない」という要望に対して、インフラ監視の職人的な知恵を生成モデルの事前分布として与えることができる。前職は機械学習の研究者だったが、その知識や知見を実サービスに生かす仕事がようやくできたかなと思う。

ロール内異常検知を開発する頃にはようやく人並みに開発やインフラのことを見れるようになっていたのも大きかった。はてなに転職してきていきなりこれを任されていたら、絶対爆死していたに違いない...。

データ基盤とCustomer Reliability Engineerへの挑戦

ロール内異常検知が一段落した頃、次はどうするかなと悩んでいた。ちょうどその頃、同僚であるCREのid:missasanさんが「カスタマーサクセスを今後より進めるために、データ分析が必要になってくる」という話を社内勉強会でしているのを聞いた。自分はアプリケーションエンジニアをやっていたからドメイン知識は頭の中にあるし、データ分析は多少経験あるから多少の力になれるかも、ということで一緒にカスタマーサクセスのためのデータ分析をやっている。

異常検知に引き続き、初めはデータ基盤も何も分からない状態だった(この状態でよく突っ込んでいったな自分...とは思う)。何から始めるといいか分からないことは詳しい人に聞きに行こうということであれこれ動いた。同僚(だけど東京)のid:polamjagくんに根掘り葉掘り聞いて回ったり、東京のイベントの翌日に(当時Rettyで)データ基盤をバシバシやっていたid:tkngueさんにランチでお話を聞いたり、関西の機械学習のイベント関連で仲良くなったリブセンスのid:yubessyさんにオフィスランチでお話を聞いたりして、とにかくどうやるとデータ基盤がうまく回りそうか自分の頭の中で多少なりとも描ける状態を作るようにした。データ基盤は技術の問題だけではなく文化やコミュニケーションの問題も考える必要があり、オンラインではなかなか聞けない部分も大きく、対面であれこれ知見を聞けたのは本当にありがたかった。

最初は「SaaSのKPIってそもそもどう定義すればいいんだっけ...」というところからスタートした。何とか定義をしたのはいいものの「今だとそれを出せるデータがないから業務フローという名のスプレッドシートパイプラインを整備しましょうか...」というデータ整備も一緒に進めた。あちこち未整備かつ全容を把握している人が誰もいないということもあり、大分大変だった...。

CREのサポートをしていたら、いつの間にか自分もCREになっていて、人生面白いなって思った。「歩く信頼性」ことid:a-knowさんにCREに誘ってもらったのは嬉しかったし、プロダクトサクセスの仕事を一緒にやらせてもらって「カスタマーサクセスとは何なのか」を日々背中で教えてもらっている。

id:missasanさんは自分の割と苦手な業務フローの整備や他職種とのコミュニケーションがすごく上手で、一方自分はMackerelのドメイン知識(DBのスキーマとかデータどこ見ればいいとか)やSQLはある程度できた。お互いの得意と不得意をうまく補完しながら、二人三脚で走れたかなと思う。一緒に走ったことでid:missasanさんは今ではSQLバリバリ書けるし、自分も業務フローの整備や他職種とのコミュニケーションが多少うまくなった(ような気がする)ので、一緒に仕事できてとてもよかった。

事業のKPI以外の普段のCREの活動でもデータを見たい場面が多々あるということで、BigQueryを中心としたデータ基盤の構築も行なった。データ転送するだけではデータ分析者にとって使いやすいものではないので、メタデータを中心としたデータウェアハウスの整備を行なった。id:missasanさんと一緒にデータ分析をしたおかげで、どういったところが分析のときに困りやすいか勘所ができていたし、フィードバックをもらいながら仕事をできたので大分仕事がしやすかった。

また、データ基盤の開発者も主に自分一人だったので、壊れにくいデータ基盤になるような仕組みを整備していった。ある程度データ基盤も整備できてきた後は、よりチーム内外でデータ活用をより進めるための活動を始めた。

特によかったなと思う活動は「突撃! 隣のダッシュボード」とSQLレクチャー会。需要サイドの企画系や営業系の人と供給サイドのエンジニアが同じ場に集まって、データ活用を進めていくためにどうあるといいか(To-Be)を考える機会を持つことができた。機械学習サブ会はある程度うまくいったがどうしてもエンジニア内で閉じてしまいがちなところがあったが、「突撃! 隣のダッシュボード」ではむしろエンジニアのほうがマイナー職種と思えるくらい色んな人を巻き込んで活動できたのは自分の中でとても大きな経験になった。ちょっと矛盾しているかもしれないけど、自分はコミュニケーション能力は低いが、人を巻き込んで仕事をする活動が割と好きなのかもしれない*6。

今後はデータエンジニアリング

冒頭にも書いたけど、NTT CS研から転職したときに思っていた「(アルゴリズム以外を含めて)データを丸っと見れるようになりたい」というのは今も変わっていない。データは生成 / 蓄積 / 活用というライフサイクルがぐるぐる回ることで価値が出るものと思っている。その中でデータの蓄積や活用へのサポートを特にやりたいと思っているので、今後はしばらくデータエンジニアリングを頑張っていきたい。

*1:大抵の人は応援してくれました。ありがとう

*2:仕事だと「ここは得意な人にお任せしよう」ができてしまう

*3:最初は「何やってんだこいつ...」とあきれられるんじゃないかと思ってビクビクしていた気がする。はてなは心理的安全性はめっちゃ高い職場で、一度もそんなことを言われたことはないが...

*4:障害は頻発するものではなく、障害の定義もユーザーによって異なるため教師あり学習でやるのは問題設定として難しい

*5:機械学習に詳しいメンバーが多くはないため、枯れていることや仕組みが直感的に分かりやすいことは重要であった

*6:このままだと巻き込まれる側が迷惑なので、もうちょっとコミュニケーション能力は上げていきたいとは思ってる...

esa.ioに分報っぽく投稿するアプリをReactとFirebaseで作った

Firebase React

こういう風に投稿すると(左)、esa.ioにこういう感じ(右)で投稿される分報風のアプリを自分用に年末年始に作りました。

f:id:syou6162:20210102210650p:plainf:id:syou6162:20210102210641p:plain

作った動機

きっと皆さんそうしているように、私も日々ログを残しながら作業をしている。仕事ではscrapboxを使っているが、プライベートではesa.ioを愛用している。プレビューを見つつmarkdownで書けたり、タグとカテゴリがいい感じに使えたりするところが気に入っている。あと、アイコンがかわいい。

ちゃんと作業をするときにはesa.ioにページを作るが、そうでない雑なものも記録したいときが度々ある。例えばこういうの。

  • 今度コンビニ行ったとき、忘れずにXXXを買う
  • 統計の本を読んでて、急に理解が追い付いてきたので忘れない内にメモしたい
  • Splatoonで負け越しが続いたけど、YYYを変えればよくなるんじゃないか

ジャンルも粒度もバラバラで、esa.ioに専用のページを作るのもちょっと違う。こういう時はSlackの分報チャンネル(times_syou6162みたいなやつ)が便利。粒度も内容も気にせず、とにかくここに書き殴っておけばいいという場所になっている。思考停止でここに書き込めばいいという場所はとにかく重要で、ログを残すためのハードルを下げてくれる。ChangeLogメモとかもそういう側面があると思う。しかし、Slackは検索がイマイチだったり、日付毎にログが見づらいといった問題がある。

分報風に書きつつ、esa.ioにちゃんと日付毎に(日報風の)記録が残れば便利なのに...ということで自分が欲しいWebアプリをReactとFirebaseで年末年始に作った。

esa.ioでその日の日報のページを開いて...という動作が必要なく、Webアプリなので出先でiPhoneから気軽に書くことができて便利。見るときにはhtmlで表示しつつ、コピペしたいときにはmarkdownに切り替えるのもボタン一発、というあたりも便利で気にいってる。

びっくりするようなものは特に使っていないが、使った要素技術をメモがてら残しておく。

使った要素技術

Firebase Authentication

誰でも日報を書けたり読めたりしては困るので、ユーザー認証を行なう。自前でユーザー管理を行なうのはダルいので、今回はFirebase Authenticationを使うことにした。

Googleログインを使い、ホワイトリストにマッチする自分のメールアドレスの場合だけ読み書きできるようにする。といっても、認証部分はかなりお手軽にできてしまった。

Firebase Hosting + React

アプリを設置する場所としては、Firebase Hostingを選んだ。デプロイも簡単だし(後述)、その他のおもてなしもよくできていて体験として結構よかった。

フロントはReactを選んだ。自分としてはVueのほうが慣れているが、せっかくだし違うものも使ってみよう(あと世の中的にはReactのほうが使われている...?)ということで今回はReactを選んだ。

やりたかったことを勘と雰囲気のノーガード戦法で作るのはチュートリアルも読まずにさくっとできたが、その後のほうが時間がかかった。コンポーネントに分けるとかTypeScript化するとか綺麗にするには基本に帰ろう...ということで、結局チュートリアルはざっと眺めて回った。デザインは特にこだわりもないので、Material-UIで済ませた。

Firebase Cloud Functions

Firebase Hostingだけではesa.ioのデータの読み書きができないので、バックエンド的なものを用意する。自分が使うだけだし、一番お手軽なFirebase Cloud Functionsを使う。AWS Lambdaっぽい感じで使える。言語は何でもいいが、Node.jsで書いた。

Firebase Cloud Functionsをそのまま使うと、エンドポイントが外の人に知られると誰でも叩き放題になってしまう。どうにかする。

Firebase Authenticationを使っている場合、リクエスト時にbearer tokenが自動的に付与される。tokenが付与された場合、functions側でcontext.authにemailなどのユーザーの認証情報が付与されるため、利用できるユーザーを制限できる。bearer tokenがそもそも付与されていなかったり、invalidなものだった場合はFirebase Cloud Functions側でリクエストを弾いてくれるので安心。Firebaseで統一されていることのありがたみを感じる。

esa.ioのAPIキーやteam_nameをコードに保存したくないので、どこか安全な場所に保存してから呼び出したいが、この辺もおもてなしがある。AWSのパラメータストアみたいなもの(違うかもしれない...)があって、こんな感じで情報を保存しつつ

firebase functions:config:set esa.team_name="MY_TEAM_NAME"

アプリ側ではこんな感じで読み込むことができる。

const teamName = functions.config().esa.team_name;

Firebase Cloud FunctionsはHostingと比べるとデプロイの時間が少し長い(といっても1分くらい)ため、firebase側に反映してから試すというのはやりにくい。しかし、この辺もよくできていて手元でエミュレートするモードがある。TypeScriptを使っている場合はtsc --watchをしておくことを忘れずに(修正が反映されないので)。

firebase serve --only functions

これを使うと、5000番ポートにfunctionsをエミュレートしたサーバーが立つので、フロント側も切り替えてあげれば手元で動作確認が済んでとてもやりやすかった。

// 元々はこっち
// const getDailyReport = firebase.functions().httpsCallable('dailyReport');
// ローカルで試したいときはこれを使う
const functions = firebase.functions();
functions.useFunctionsEmulator('http://localhost:5000');
const getDailyReport = functions.httpsCallable('dailyReport');

デプロイ自動化

最初は手元からHostingとFunctionsそれぞれにdeployしていたが、人手でやるのは面倒なのでmasterブランチにマージされたら勝手にデプロイされて欲しい。Firebaseはこの辺もよくできていて、CIに必要なtokenを発行してくれるコマンドがある。こいつをgithubのsecretsに登録して、github actionsに書いてやればデプロイも自動化できる。30分くらいで自動化できて、最高だった。

所感

Firebaseは便利便利と聞いていたもののどう便利か分かっていなかったが、実際使ってみるとなるほど便利というのがようやく実感できた。別の趣味サイトで似たようなことをするときに、cognito + amplify + apigateway + lambdaを使ったけど、えらく難しくて週末でがっとやる感じではあまりなかった。今回は「あの苦労は何だったんだ...」というくらい簡単にできた。

今回は裏側がesa.ioだけど、S3でもGoogle Spreadsheetでも同じようなことはできる。似たようなものを作るときは今回のを真似しつつ、必要なときは今後はバシバシ使っていこうと思った。

2020年はあまりこういう瞬発力系のものを作っていなかったので、2021年はもっと色々作っていきたいですね。

2020年の振り返り

2020年もお疲れ様でした。仕事は当然まだおさまっていない。

2020年以前

2018年は砂場活動を結構頑張っていた時期だったらしい。

2019年は振り返りエントリが存在しなかったけど、こんな感じの年だったはず。

  • 仕事で取り組んでいたロール内異常検知がリリースできた
  • メンタルの浮き沈みが激しかった
    • 機械学習関係のことをあれこれ話せる同僚の退職が立て続けにあり、結構落ち込んでた
    • 退職するか30回くらい考えたし、実際他社さんのカジュアル面談受けに行ったりしたけど、何とか踏み止まったっぽい

そんでもって2020年はこういう年でした。

CREになった & データ基盤をやるようになった

今年の一番の大きな出来事としてはCREになったこと。

カスタマーサクセスのためのデータ活用を進めるために、データ基盤の構築やデータ分析を行ないました。データ分析を実際に行なう人のフィードバックを元に、データ基盤の改善を進めました。データ基盤構築の経験がゼロからやり始めた割に、まあまあできたかなと思うのは主に他社さんでアウトプットしてくれている方のエントリのお陰だったので、自分もなるべくアウトプットするようにしました。

外部での登壇も3件やりました。これくらいのペースが丁度いいなと思う。2018年 / 2019年は大分頑張ったけど、頑張りすぎた結果疲弊していた。

また、社内のデータ活用を広めるためにSQLレクチャー会をやり始めました。SELECT ... FROMから始めて、現在ではウィンドウ関数まで使い込なせるようになってもらって、セールス活動をサポートするための仕事に生かし始めてもらおうという段階まできました。SQLをレクチャーするだけでなくデータ分析のことを営業事務の方に知ってもらったことで、データ整備の改善も具体的に進み始めたことがこの活動の真の意味だったなと思っている今日この頃。

最近では「突撃! 隣のダッシュボード」という社内企画もやり始めていて、自チームのダッシュボードにまつわる見所ポイント、苦労話、活用のされ方などを他チームにも共有して、データ活用を促進できればなと思ってやっています。会社のほたてで(同率)1位を獲得するなど、まあまあいい感じになってきている気がする。

こういった現場視点のボトムアップな活動は割と色々できたかなと思う一方、トップダウンな動きを引き出すところはあまりうまくやれなかったなぁという気持ちが強い。ここに関しては今のところいい解の候補を自分でも持てていないので、2021年はもっといい方向に進むといいなぁ(他力本願...)。

コロナとWFH

3~4月あたりは世の中これからどうなるか見えない状況で結構ストレスがあった。5月以降くらいからようやくペースが掴めてきたかなと思ったが、ずっと在宅だと全然エンジンかからないな...と8月くらいに気付いて、週1~2日のペースで出社するくらいで最近はやってる。オフィスランチが恋しい。

都立大の講義をやる機会があったけど、こちらもコロナの影響でオンラインでやりました。講義はまだしもプログラミング演習は準備も当日も大変だった。

数理統計学の復習を始めた

ここ数年、仕事で数学をまともに使っていないこともあり、数学力が落ちまくっている。このままではヤバイという危機感は持ちつつも、特に何かができたわけでもないというのが今年の前半までのステータス。マジでケツを叩かないとどうしようもないな...と思って、統計検定講座を受講し始めた。

割とネガティブな要因で受講し始めたわけだけど、講座は予想よりかなり楽しく、毎週土曜を楽しみに待っている状態。不偏推定量や検定論への理解がぐっと深まったし、何より統計学はやっぱり楽しいなと再認識できたのが一番の収穫かな。

練習問題がバシバシ解けるという状態にはまだ遠いので、しばらく訓練をしてから来年の統計検定に備えようかなという気持ちになってきています。せっかく勉強したので、業務でも早速使っています。

すうがくぶんか 統計検定1級対策講座 第八回

数理統計学

前回はこちら。

今回で最終回。尤度比検定の練習問題や線形回帰のパラメータの推定量について。尤度比検定から派生して興味が湧いたNPSの信頼区間推定についてがっつり書いてしまった。

多項分布のパラメータの尤度比検定

前回めちゃくちゃやった尤度比検定の練習問題として、多項分布のパラメータについての尤度比検定の問題を解いた。3つパラメータp_1, p_2, p_3を持つケースについて考える。帰無仮説がp_1 = p_2、対立仮説がp_1 \neq p_2とした場合に、尤度比検定量と有意水準5%の棄却域を求めよ、という問題。

割と素直な問題で、帰無仮説が正しい場合(p = p_1 = p_2)の最大対数尤度をラグランジュの未定乗数法で求めてあげればよい。

NPSと尤度比検定

ここからは実務に関係する話。先ほどの問題は仕事にも使える問題になっていて、多項分布はNPS(Net Promoter Score)で使える問題設定になっている。

そもそもNPSは「XXを友人や同僚にお薦めしますか? 0~10の11段階でお答えください」というアンケートをお客さまに送るというもので、9~10点を付けた顧客を「推奨者」、7~8点を「中立者」、0~6点を「批判者」と分類する。NPSのスコアは、回答者全体に占める「推奨者」の割合から「批判者」の割合を引いた値で定義される。サブスクリプション時代において、リテンションの高さなどはますます重要になってきているが、NPSのスコアと売上成長率への相関があることや「推奨者」は「批判者」に比べてLTVが高いことなどから、NPSは最近カスタマーサクセスの分野を中心に注目を上げているKPIの一つになっている。

仕事でNPSの定期調査をやっていると、「推奨者の割合は批判者の割合よりも高いのか?」といったことが気になってくるが、それは今回の統計検定講座の練習問題と似ている(片側と両側の違いがある)。

NPSの信頼区間推定

NPSは「推奨者」の割合から「批判者」の割合を引いた値で定義されるが、回答時期によって回答数が多い場合や少ない場合がある。NPSのスコアは例えば-10.0のように出てくるわけだが、実現値はある程度揺らぎがある(例: 0 ~ -20の範囲に大体いるはずだ)。C向けのサービスはある程度サンプル数を集めやすいと思うが、B向けのサービスだとそうもいかない場合も多い。ある時期と今を比較してNPSが改善 / 悪化したかを判断したい場合、NPSの信頼区間を求める必要がある。今回興味のある統計量は「割合の差」。これがどういう分布に従うか、段階を追って見ていこう。

標本比率の分布

母分布が二項分布\text{Bin}(1, p)である母集団を二項母集団、pを母比率と呼ぶ。二項母集団からn個の無作為標本を取っていた場合、標本比率\bar{p}の平均はp、分散は\frac{p (1-p)}{n}となる(スッキリわかる確率統計より)。

ここで、中心極限定理(あるいはその特殊ケースであるド・モアブル–ラプラスの定理)より、nが十分大きい場合、標本比率\bar{p}はN(p, \frac{p (1-p)}{n})の正規分布に(近似的に)従う。

割合の差

標本比率の分布が正規分布で近似できることが分かった。よって、標本比率の差は正規分布に従う変数の差を考えればよい。正規分布の再生性より、標本比率の差もまた正規分布と考えることができる。

...が、このまま進めるとよくない。「京都でセブンイレブンが好きな人の割合」と「東京でセブンイレブンが好きな人の割合」の差を考えたい場合はこれでよいが、今回は考えたいのはNPSの「推奨者の割合」と「批判者の割合」の差。NPSでのそれぞれの割合は足して1になる制約上、どちらかを増やせばどちらかが減る(中立者の割合が変わらないならば)。独立ではなく負の相関があるため、それを考慮に入れる必要がある。

ここで、「推奨者の割合」をp_1、「批判者の割合」をp_2とする。今回考えたい標本比率の差の分散は

V(\bar{p_1} - \bar{p_2}) = V(\frac{1}{n} (X_1 - X_2)) = \frac{1}{n^2} V(X_1 - X_2) = \frac{1}{n^2} (V(X_1) + V(X_2) - 2 \text{Cov}(X_1, X_2))

となるが、二項分布の分散を思い出せばV(X_1) = n p_1 (1 - p_1)、V(X_2) = n p_2 (1 - p_2)と分かる。\text{Cov}(X_1, X_2))は一瞬悩むが、冷静に考えると多項分布の共分散であるから、\text{Cov}(X_1, X_2)) = - n p_1 p_2。符号が負であることから、「推奨者の割合」と「批判者の割合」は負の相関があることが確認できた。

よって、元々考えたかった「割合の差」に対する分散は

V(\bar{p_1} - \bar{p_2}) = \frac{1}{n^2} (n p_1 (1 - p_1) + n p_2 (1 - p_2) + 2 n p_1 p_2) = \frac{1}{n} (p_1 (1 - p_1) + p_2 (1 - p_2) + 2 p_1 p_2)

と分かる。NPSを前提(\text{NPS} = p_1 - p_2)に分子をもう少し整理してみると

p_1 (1 - p_1) + p_2 (1 - p_2) + 2 p_1 p_2 = - p_1^2 + 2 p_1 p_2 + - p_2^2 + p_1 + p_2 = - (p_1 - p_2)^2 + p_1 + p_2

とできるが、NPSの定義は「推奨者の割合p_1 - 批判者の割合p_2」だったので、V(\bar{p_1} - \bar{p_2}) = \frac{- \text{NPS}^2 + p_1 + p_2}{n}となる。

NPSの信頼区間

以上の議論から、NPSは平均がNPSの値、分散が\frac{- \text{NPS}^2 + p_1 + p_2}{n}の正規分布に従うことが分かったので、例えばNPSの95%信頼区間は\text{NPS} \pm 1.96 \times 100 \sqrt{\frac{- \text{NPS}^2 + p_1 + p_2}{n}}と計算できることが分かる。100は%をパーセントに変換するための登場。Zendeskでも同様の計算式が使われており、「NPSの調査の誤差をXX以内に抑えたければ、標本サイズはYY以上取るようにしましょう」といったアドバイスもされている。

統計検定1級の練習問題から大分派生してしまったが

  • 標本比率のモーメント
  • 中心極限定理の標本比率への応用
  • 差の分散といった統計量の計算
  • 自分の問題に適した信頼区間の算出

といった具合に、統計検定1級の対策講座でやってきた内容をフル活用したので、まあよしとしよう。

参考:

線形回帰

統計検定1級に頻出の話題として、線形回帰がある。定式化や最小二乗法が自力で出せるのは前提として、回帰係数が不偏推定量であること、回帰係数の分散を練習問題として解いた。

面白かったのは、回帰係数\beta_iがx_iとyの偏相関係数の符号と一致する、というのを示す問題。偏相関係数って何だっけ...となってしまったが

  • x_1とyの相関関係を知りたい
  • しかし、x_2という変数がx_1にもyにも影響を与えている
  • x_2の影響を取り除いた状態でのx_1とyの相関係数を知りたい

というものだった。名前に「偏」と付いた統計量は偏自己相関係数くらいだったので、なるほどーという感じだった。偏自己相関係数はARモデルなど時系列モデルを考える際に必須なやつ。

すうがくぶんか 統計検定1級対策講座 第七回

数学 数理統計学

前回はこちら。

今回は検定論の話。話題がそもそも難しい & 自分の理解も不十分なところが結構あるので、間違っていることが結構あるかもしれない。色んな本を見ながら書いているので、表記も結構バラバラです。

全体像

検定論全般について復習したことをまとめているため、統計検定1級対策講座で話題にされていないトピックも含んでいる。個別の検定の話がばらばらに出てくると繋がりが分からなくて迷子になってしまうけど、全体像を描けると安心しながら前に進めるようになってきた。

  • 検定論にはそもそもαエラー(第一種の過誤)とβエラー(第二種の過誤)が付き物
  • ネイマンピアソン流では、αエラーは確実に一定以下に抑えたい
    • 一方、βエラーもなるべく最小にしたい
  • 一様最強力検定: αエラーが一定以下の検定手法の中で、他のどの検定手法よりもβエラーが小さい検定手法のこと
    • 単純仮説の場合、尤度比検定が一様最強力検定となる(ネイマンピアソンの補題)
  • 複合仮説の場合、一様最強力検定が存在するとは限らないが、尤度比に単調性があり、片側検定ならば一様最強力検定が存在する
    • 不偏検定もそういった類のもの
  • 一様最強力などいい性質を持つ尤度比検定だが、帰無分布に正規性を仮定できる場合などは尤度比検定とt検定は同一のものと考えられる
    • 尤度比検定のよさから、t検定のよさも言えるということ

定義

帰無仮説と対立仮説

  • 帰無仮説H_0: \theta \in \Omega_0
    • \{\theta_0\} = \Omega_0のような要素が一個しか入っていない場合を単純仮説と言う
  • 対立仮説H_1: \theta \in \Omega_1
  • \Omega = \Omega_0 \cup \Omega_1, \Omega_0 \cap \Omega_1 = \phiを満たすものを考える

検出力

  • 決定関数(または検定関数): \delta
    • 英語だとtest function
    • X= xを観測したとき帰無仮説を棄却するならば1、受理するならば0を取る関数
  • 検出力: \pi(\theta | \delta)
    • \deltaの有意水準(critical region)をS_1とすると、\pi(\theta | \delta) = \text{Pr}(X \in S_1 | \theta), \theta \in \Omega
  • αエラー: 帰無仮説が正しいときに、帰無仮説を棄却してしまうこと
    • \pi(\theta | \delta), \theta \in \Omega_0
    • \alpha(\delta) = \text{Pr}(\text{Rejecting} H_0 | \theta = \theta_0)
  • βエラー: 帰無仮説が正しくないときに、帰無仮説を採択してしまうこと
    • 1 - \pi(\theta | \delta), \theta \in \Omega_1
    • \pi(\theta | \delta), \theta \in \Omega_1のことを普通は検出力と呼ぶと思う
    • \beta(\delta) = \text{Pr}(\text{Not Rejecting} H_0 | \theta = \theta_1)

よく行なわれるのは任意の\theta \in \Omega_0に対して\pi(\theta | \delta) \leq \alpha_0を満たしつつ、\pi(\theta | \delta), \theta \in \Omega_1が最大になるような方法を探す、というやつ。ネイマンピアソン流とも言われる。

一様最強力検定

検定手法が複数考えられる中で、検定手法の評価を行ないたい。まず、言葉を定義する。

検定手法がより強力であるとは

2つの検定手法T_1とT_2があって、それぞれの検出力関数を\beta_1(\theta)、\beta_2(\theta)とする。このとき、次を満たす場合、T_1はT_2より強力(more powerful)であるという。

  • 全ての\theta \in \theta_0に対して、\beta_1(\theta) \leq \alpha, \beta_2(\theta) \leq \alpha
    • \theta_0に対して言っていて、これは第一種の誤りが\alpha以下であることを要請している
  • 全ての\theta \in \theta_1に対して、\beta_1(\theta) \geq \beta_2(\theta)であり、少なくとも一点で不等式が成り立つ
    • 対立仮説が正しいもとで、検出力がT_2より高い

一様最強力検定とは

レベル\alphaの検定の全体をC_\alphaで表わす。このとき、検定Tが一様最強力検定であるとは、Tがレベル\alphaの検定であり、C_\alphaの中のどんな検定よりも強力であることをいう。すなわち

  • \beta_T(\theta)をTの検出力関数とすると、すべての\theta \in \Theta_0に対して\beta_T(\theta) \leq \alphaである
    • 第一種の誤りが\alpha以下だよ
  • 任意の検定S \in C_\alphaに対して、その検出力を\beta_S(\theta)とすると、すべての\theta \in \Theta_1に対して\beta_T(\theta) \geq \beta_S(\theta)が成り立つ
    • \thetaがどんな値だろうと、他の検定よりも第二種の誤りを抑えられる

ということ。一様最強力検定は必ずしも存在するとは限らないが、単純仮説の場合など限定された状況においては一様最強力検定が作れる場合がある。一様最強力検定が構成できるいくつかのケースを見ていく。

ちなみに、βエラーを一定、αエラー最小にしたいという逆の場合も考えられるが、帰無仮説と対立仮説を入れ替えれば同じ議論ができる。

尤度比検定

  • 帰無仮説H_0: \theta \in \Omega_0
  • 対立仮説H_1: \theta \in \Omega_1
  • 尤度比統計量\Lambda(\mathbf{x}) = \frac{\sup_{\theta \in \Omega_0} f_n(\mathbf{x} | \theta)}{\sup_{\theta \in \Omega} f_n(\mathbf{x} | \theta)}を使って検定する
    • 分母は\Omega_1じゃなくていいのか?
    • 久保川本もこうなってるから間違いではない。パラメータ空間を限定しないでいい
      • 単純仮説の場合、それしかないから値をつっこめばいい
      • 複合仮説の場合、丁寧に場合分けしつつ尤度比を計算するしかない
  • 尤度比検定量をいじった-2 \log \Lambda(\mathbf{x})がX^2分布に分布収束するのが知られている
    • https://en.wikipedia.org/wiki/Wilks%27_theorem
    • これはテイラー展開やスラツキーの定理を使って割とゴリ押す必要があるため、初手で証明追う必要はない
    • しかし、統計検定1級では頻出なので、使い方は理解する必要があり
    • 分布収束することを言うためには、ある程度のサンプル数を仮定する必要があることには注意
      • テイラー展開した後に二次近似するため
    • X^2分布の自由度については少し注意が必要
      • 帰無仮説を定める\Theta_0の空間としての次元をd_0、対立仮説を定める\Theta_1の空間としての次元をd_1としたとき、-2 \log \Lambda(\mathbf{x})は自由度d_1 - d_0のX^2分布に従う
      • 「空間としての次元」というのがミソで、これはパラメータ数のことではない。仮説が一点からなる集合であれば次元は0、直線からなる集合であれば次元は1といった具合になる
  • 尤度比検定が広く使われているのには、理論的な根拠がいくつかある
    • 代表的な根拠はネイマンピアソンの補題。一様最強力検定であることが言える
    • 使える条件は限定されるが、単調尤度比や不偏検定も尤度比検定のよさをサポートしている

ネイマンピアソンの補題: 単純仮説における尤度比検定

単純仮説からなる検定問題H_0: \theta = \theta_0 vs H_1: \theta = \theta_1 (\theta_0 \neq \theta_1)を考える。ランダムサンプル\mathbf{X} = (X_1, \cdots, X_n)の同時確率密度をf_n(\mathbf{x} | \theta)で表わすと、尤度比検定統計量は\frac{f_n(\mathbf{x} | \theta_0)}{f_n(\mathbf{x} | \theta_1)}となる。これがC(C>0)より小さくなるとき、帰無仮説を棄却するのが尤度比検定である。すなわち、k = \frac{1}{C}とするとH_0の棄却域は

R = \{\mathbf{x} \in X | f_n(\mathbf{x} | \theta_1) > k f_n(\mathbf{x} | \theta_0)\}

と書ける。棄却域がこの形で与えられる尤度比検定は最強力である(ネイマンピアソンの補題)。証明は区間を分けて、不等式で押さえる形式。

「尤度比検定にはsupが付いてるけど、ネイマンピアソンの補題にはsup付いていないのはなぜ?」と疑問に思ったが、ネイマンピアソンの場合は単純仮説しか考えていないので、\theta_0とかの取り得る値がそもそも一個しかないので、それが最尤推定。ネイマンピアソンの補題を複合仮説にも拡張(そのためにsupを取る)したのが尤度比検定、と捉えると分かりやすい。

ネイマンピアソンの補題を使って一様最強力検定であることを示す

ネイマンピアソンの補題は単純仮説でしか成り立たないから、あまり使い物にならないかと思っていたが、実はそんなことは全然ない。ある検定方法が一様最強力検定であるかを示すためによく使われる。

検定問題H_0: \theta = \theta_0 vs H_1: \theta > \theta_0を考える。これは複合仮説。ここで、\theta_1 > \theta_0について考えよう。\theta_1を対立仮説に置くと、これは帰無仮説と合わせて単純仮説となる。単純仮説であるからネイマンピアソンの補題を使って、点\theta_1において一様最強力検定であることが示せたとする。示す際に棄却域が出てくるわけだが、棄却域の式中に\theta_1が出てこなければ、点\theta_1でないところでも一様最強力検定が成立している、という理屈。

まとめると、こういう使い方。統計検定1級にもよく出るようなので、何回も練習しよう。

  • 対立仮説のある点\theta_1で、ネイマンピアソンの補題が成立することを言う
  • 棄却域が\theta_1に依存していない式ならば、ネイマンピアソンの補題がどこでも成立している
  • つまり、一様最強力検定であることが示せる

単調尤度比 (monotone likelihood ratio)

単純仮説のとき、ネイマンピアソンの補題から尤度比検定が一様最強力検定であることが示された。一般に複合仮説の場合には一様最強力検定を構成するのは困難である。しかし、尤度がある性質を持つとき、一様最強力検定を求めることができる。

T = T(\mathbf{X})を\thetaに対する十分統計量とすると、因子分解定理よりf_n(\mathbf{x} | \theta) = h(\mathbf{x}) g(T(\mathbf{X}) | \theta)と表わされる。尤度比検定はTの関数になることが分かる。\theta_1 \leq \theta_2に対して、g(t | \theta_2) / g(t | \theta_1)がtに関して非減少であるとき、g(t | \theta)は単調尤度比を持つという。

十分統計量T(\mathbf{X})に対して、g(t|\theta)が単調尤度比を持つとする。H_0: \theta = \theta_0 vs H_1: \theta > \theta_0なる片側検定について、P_{\theta_0}(T(\mathbf{X}) > t_0) = \alphaとするとき、棄却域がR = \{\mathbf{x} | T(\mathbf{x}) > t_0\}で与えられる検定は一様最強力検定となる。両側でなくて、片側のみであることに注意。

例: 片側Z検定

久保川本の7.19 163ページの例。X_1, \cdots, X_nをN(\mu, \sigma_0^2)からの独立な標本とする。\sigma_0^2は既知とする。実際に尤度比を計算してみると、\mu_1 = \mu > \mu_0なる\mu_1に対して以下のようになる。

\frac{f(\mathbf{x} | \mu_0)}{f(\mathbf{x} | \mu_0)} = \exp{\left( \frac{n(\mu_1 - \mu_0)}{\sigma_0^2} \left(\bar{x} - \frac{1}{2} (\mu_0 + \mu_1) \right) \right)}

十分統計量は\bar{x}で、単調性が成り立つことが分かる。従って、H_0: \mu = \mu_0 vs H_1: \mu > \mu_0なる片側検定に対しては、尤度比検定R = \{\mathbf{x} | \sqrt{n} (\bar{x} - \mu_0) / \sigma_0 > z_\alpha\}が一様最強力検定となる。

この辺の詳しい式展開はProbability and Statistics: Pearson New International Editionが詳しい。

不偏検定

単調尤度比と片側検定に限定すれば一様最強力検定が構成できるが、両側検定については一般には最強力検定が存在しない(棄却域の場合分けが必要になってしまう)。しかし、検定方法を不偏な検定に制限するならば、その範囲で一様最強力検定を求めることができる。

H_0: \theta \in \Theta_0 vs H_1: \theta \in \Theta_1なる検定において、ある検定の検出力関数\beta(\theta)が全ての\theta^\prime \in \Theta_1と全ての\theta_0^\prime \in \Theta_0に対して\beta(\theta^\prime) \geq \beta(\theta_0^\prime)を満たすとき、不偏検定(unbiased test)と呼ぶ。

意味合いとしては「対立仮説の下で、検出力が常に有意水準以上であるような検定」。ここでいう「不偏」は不偏推定量のようなunbiasedという意味ではなく、片側などに限らずどこででも成り立つという意味での不偏(universalっぽい感じ...?)と捉えておくとよいかな。

指数分布族であれば、一様最強力検定を構成できる、という定理が知られているようだ。統計検定での出題回数は多くないので、初手では後回しにしておいても悪くなさそう。

尤度比検定としてのXX検定

母集団が正規分布(分散既知)の状況で、平均値の間に差があるかを尤度比を使って求めることを考える(ここでは片側とする)。ゴリゴリと計算を進めていくと、尤度比はt分布に従うことが分かる。あれ、これってどこかで聞いたことがある話。統計検定2級などでもよく出てくる平均値の差の検定で見るt検定である。そう、t検定は(特定の状況下において)尤度比検定から導出できるものだったのだ。この場合、尤度比は単調性も満たし、片側検定であるため、t検定が一様最強力検定であることも分かる。

こういった性質はt検定だけでなく、F検定など他の検定にも成り立つ。つまり、こういうこと。

  • どういう性質が成立すれば尤度比検定が一様最強力検定になるか、よく研究されている
  • 特定の検定と尤度比検定のつながりと前提条件を満たしているかを調べれば、特定の検定が一様最強力検定であるかも分かる

F検定などその他の例についてもProbability and Statistics: Pearson New International Editionに詳しく書いてあって、面白かった。

その他の検定統計量を使った検定方法

尤度比でない検定統計量を使った検定方法も世の中考えられていて、代表的なものとしてはワルド検定やスコア検定がある。サンプルサイズが少ない場合は尤度比検定が適していないケースもあるらしく、偏回帰係数の検定などはワルド検定が利用される場合もあるようだ。まあ、でも初手はとにかく尤度比検定について抑えておくのがよさそう。

コーヒーブレイク: 検定論と区間推定

ここまで色々書いたが、統計的検定は結構難しい。統計のこと興味ある人でも正しく結果の解釈をするのはまあまあ難しいし、「統計のこと全く興味ないっす」という人向けに統計的検定の話をするのはさらに難しい。そして、世の中的には統計のこと興味ない人のほうが圧倒的に多いので、統計的検定の結果を説明するときには大体頭を悩ませることになる(これはid:syou6162の個人の主観です)。

「統計的検定よりも区間推定のほうが一般的な人々向けには説明しやすいかな?」と思うことがあり「統計的検定の代わりに区間推定で説明しても大丈夫ですか?」と質問してみた。一般的にはNGだが、ケースによってはOKという回答をもらった。どういうケースはNGで、どういうケースはOKなのかを理解するために、区間推定の評価指標について考えてみよう。

区間推定のよさをはかる

数理統計学は推定量のよさだったり、検定方法のよさだったりについて議論をすることが多い学問だが、区間推定についても当然評価指標の話が存在する。推定量のよさほどは話題になることが少ないが...(私は今日初めて知った)。

以降は久保川本の8.3をベースに書く。考えたいパラメータ\thetaが確率1-\alphaでこの区間にあるはず、というのをカバレージ確率という。ここでいくつかの評価軸が考えられる。

  • A: 同じカバレージ確率を持つ信頼区間であれば、区間の平均的な長さが小さいほうが望ましい
  • B: 同じ長さの信頼区間ならばカバレージ確率が大きいほうが望ましい

Aの基準で選んだ区間推定のことを最短信頼区間といい、Bの基準で選んだ区間推定のことを最精密信頼区間という。

検定方式との対応

詳しくは久保川本を読んで欲しいが、最精密信頼区間は統計的検定をある意味反転させて信頼区間を作る方法であり、裏側には一様最強力検定の考え方が入っている。一方で、最短信頼区間は統計的検定のことは特に考慮していない区間推定になっている。「統計的検定の代わりに区間推定で説明しても大丈夫か?」という質問に対しては、最精密信頼区間であれば統計的検定と対応しているのでOK、最短信頼区間は統計的検定の結果と(意思決定の結果が)食い違うことがあるので一般にはNGということだった。なるほど、確かに。

統計検定2級までで出るような一般的な区間推定は、最精密信頼区間がベースの考えで作られていることが多い。そういったケースでは統計的検定の代わりに、区間推定で説明しても問題ない。自分が説明に使おうとしている区間推定がどういう考えのもので作られた方法かを意識しましょう、という話。

こういう結構答えにくい質問に関しても「こういう考えが背後にはあって〜」というのを説明してもらえるので、統計検定1級対策講座はいい講座だなと思います。なんと来週が最終回〜。

現代数理統計学の基礎 (共立講座 数学の魅力)

現代数理統計学の基礎 (共立講座 数学の魅力)

すうがくぶんか 統計検定1級対策講座 第六回

数学 数理統計学

前回はこちら。

今回は完備十分統計量を使ったUMVUEの構成法や検出力について。長かった(?)推定論の話も、今回で一段落ですね。

十分統計量の定義の復習

十分統計量は定義がいくつかあるが、前回の講義では直感が効くようにフィッシャー情報量を経由した定義がなされた。

  • 元々のデータと同じく、何らかの統計量Tについてもフィッシャー情報量を定義できる
  • 「元々のデータが一番データを持っているわけだから、\thetaを少し動かした場合分布の変化は、Tを使った場合は変化が緩やかになるのではないか?」という直感をサポートする定理が存在する
    • I_T(\theta) \leq I_N(\theta)
  • 不等式の等号が成立する場合のTを十分統計量と呼ぶ
    • 元々のデータと同じだけの(最大の)フィッシャー情報量を持つ、というのが直感的な意味合い

十分統計量の別の定義とFisher-Neymanの因子分解定理

今回、我々は十分統計量を起点として、Lehmann-Scheffeの定理を使ってUMVUEを構成するのが目的。フィッシャー情報量を使った十分統計量の定義は直感的には分かりやすいのだが、Lehmann-Scheffeの定理を使う場合にはもう少しテクニカルな定義が必要となるので、別の定義を行なう。

ここでの定義は「統計量T=tであるもとでの条件付き分布が、もはや真のパラメータ\thetaに依存しないこと」というもの。wikipediaとかはこっちで書いてある。この定義とf(x_1, \cdots, x_n; \theta)がf(x_1, \cdots, x_n; \theta) = h(x_1, \cdots, x_n) g(T(x_1, \cdots, x_n); \theta)の形で書けることが同値、というのがFisher-Neymanの因子分解定理として知られている。講義では離散の確率質量関数の場合について、この定理の十分条件と必要条件を示していった。

十分統計量を用いた不偏推定量のRao-Blackwellization化

\thetaの不偏推定量\hat\thetaに対して、十分統計量 Tを条件付けて(その後で期待値を取る)やると元の推定量より分散が改善する場合がある(少なくとも悪くはならない)よ、というのが知られている(重要ポイント1)。十分統計量で条件付けて分散を改善させることを「Rao-Blackwellization化する」とよく呼ぶ。

十分統計量 Tで条件付けると、因子分解定理から\thetaを用いない式となり、\thetaの推定量として利用できることも頭の中に入れておく。Tで条件付けても、\thetaが式の中に含まれていれば推定量として使うことができないので、そういった意味でも十分統計量の定義がこうなっている、ということである(重要ポイント2)。

Rao-Blackwellization化で分散が改善する例

例がとても分かりやすかった。X_1, X_2 \sim N(\mu, 1)がそれぞれ独立。不偏推定量として\hat\mu = X_1を考えてみよう。例なので、あえてX_1だけ使ってる。正規分布の平均パラメータ\muの十分統計量はデータの和であることが分かっているので、T = X_1 + X_2。

Tを使って、\hat\muをRao-Blackwellizationしてみよう。Rao-Blackwellization化はE(X_1 | X_1 + X_2 = s)であるが、ここでE(X_1 | X_1 + X_2 = s) + E(X_2 | X_1 + X_2 = s) = E(X_1 + X_2 | X_1 + X_2 = s) = sであり、X_1とX_2は対称であるからE(X_1 | X_1 + X_2 = s) = \frac{1}{2} S = \frac{1}{2} (X_1 + X_2)となる。これは標本平均であり、この分散は\frac{1}{2}。標本平均の分散は頻出の話題。一方で、元の推定量\hat\muの分散は1であるから、十分統計量を条件付けた上で期待値を取ると、推定量の分散が改善していることが分かる。

実はこのTは後述する完備十分統計量となっており、Lehmann-Scheffeの定理からRao-Blackwellizationした推定量はUMVUEとなっている。先ほどの例で、Tで条件付けたことで標本平均が出てきたことはちょっとびっくりするが、裏側にはそういうことが隠れている。

不偏性の証明

Rao-Blackwellization化が主張していることを証明したい。まず、Tで条件付けても不偏性は壊れない、ということを示す。Rao-Blackwellization化した統計量はE(\hat\theta | T)だから、その期待値E(E(\hat\theta | T))が\thetaに一致することが言えればよい。

タワー定理よりE(E(\hat\theta | T)) = E(\hat\theta)となるが、\hat\thetaは不偏になるものからスタートしていたので、E(\hat\theta) = \thetaとなり不偏性は満たされる。E(E(\hat\theta | T))の外側の期待値はTの分布での期待値を取っていることに注意。

タワー定理については以下を見ると分かる。こういう時は期待値の定義に立ち戻って書いていくと難しくない。周辺化でYが消えるのが肝。

分散が改善することの証明

正確には悪くならない、だが。今度はV(E(\hat\theta | T)) \leq V(\hat\theta)が示せればよい。これを示すのはそんなに難しくなくて、以下を使って割と機械的に示すことができる。

  • 分散の定義
  • 分散の公式
    • 分散は二乗の期待値 - 期待値の二乗
  • 分散は0以上
  • タワー定理

以下でも詳しめで書いてあった。

Lehmann-Scheffeの定理

十分統計量(+完備性)とRao-Blackwellization化を組み合わせることで、UMVUEを構成できるというめちゃくちゃかっこいい定理があり、Lehmann-Scheffeの定理として知られている。

UMVUEはかなり性質のよい推定量であるが、そのために必要な不偏性と十分統計量は割と容易に手に入る。

  • 不偏推定量
    • 先ほどの例でも見たが、X_1でも正規分布の平均パラメータの不偏推定量になってしまう
  • 十分統計量
    • 尤度関数を書き下してあげれば何かしら十分統計量はゲットできる

簡単に手に入るものからいい推定量が手に入るなんてうまい話はやっぱり世の中にはなくて(あったらそれは詐欺)、Lehmann-Scheffeの定理が成立するための最後の重要な条件が「十分統計量が完備性を満たしている」ということである。そして、この完備性はいつでも示せるものではなく、Lehmann-Scheffeの定理を経由してUMVUEを構成するためには結構大きな仮定が入るということでもある。

Lehmann-Scheffeの定理を使ってUMVUEを示す問題は2019年の統計検定1級でも出た話題らしいので、押さえておこう。

完備十分統計量

完備十分統計量の定義はE_\theta(g(T)) =0 \Rightarrow g(T) = 0。「何言ってるんや...」という気持ちになるが「任意のパラメータ\thetaについてgの期待値が0ならば、そういうgは定数0しか存在しないぞ」ということを言っている。

完備性の気持ちについて考えたくなるが、これはどっちかというとLehmann-Scheffeの定理のためのテクニカルに必要な要件、くらいで捉えておくとよさそう。

Rao-Blackwellization化を使って、Lehmann-Scheffeの定理を示す

さて、これで道具が出揃ったので、Lehmann-Scheffeの定理を示そう。

\thetaの不偏推定量として、例えば\hat\theta_1と\hat\theta_2を持ってこよう。こいつらは別に何でも(X_1でもUMVUEでも)いい。これらの推定量をRao-Blackwellization化したものはE(\hat\theta_1|T)とE(\hat\theta_2|T)になるが、Rao-Blackwellization化しても不偏性は維持されるのでこれらの不偏推定量。

ここで、Rao-Blackwellization化した二つの推定量の差の期待値E(E(\hat\theta_1|T) - E(\hat\theta_2|T))について考える。期待値の線形性と不偏性から

E(E(\hat\theta_1|T) - E(\hat\theta_2|T)) = E(E(\hat\theta_1|T)) -E(E(\hat\theta_2|T)) = \theta - \theta = 0

となる。さて、ここで完備性の出番(ここまでの議論で完備の前半の条件(E_\theta(g(T)) =0)が出てきたわけなので)。E(\hat\theta_1|T) - E(\hat\theta_2|T)は十分統計量Tの関数。Tが完備十分統計量の定義の後半より、g(T) =0だから期待値の中身であるE(\hat\theta_1|T) - E(\hat\theta_2|T) = 0となる。つまり、E(\hat\theta_1|T) = E(\hat\theta_2|T)。

ここで思い出したいのは、\hat\theta_1と\hat\theta_2は何でもよいと言っていたということ。仮に\hat\theta_1 = X_1、\hat\theta_2はUMVUEだったとしよう。そうすると、完備十分統計量を使ってRao-Blackwellization化された推定量は一致する、ということを言っている。\hat\theta_2はUMVUEでそもそも改善のしようがなく、\hat\theta_1は完備十分統計量によってめでたくUMVUEになれた、ということである。これがLehmann-Scheffeの定理が言っていること。

ただの十分統計量を使うだけだと、Rao-Blackwellization化で分散は小さくできるものの、最小であるUMVUEに到達できるかは保証できない。

しかし、完備十分統計量を使うと元の推定量が何であれRao-Blackwellization化でUMVUEに必ず到達できる。

昔の自分がいい絵を書いていた(別に連続な関数なわけでもないので、ただのイメージです)。

練習問題として、一様分布の最大値パラメータについて標本の最大値(に\frac{n+1}{n}のバイアスをかけたもの)がUMVUEであることを示した。

推定量の中でも不偏推定量が大きく取り扱われているのは、Lehmann-Scheffeの定理によって完備十分統計量があればUMVUEにできる、という存在も大きいようだ。UMVUEを示すための道具として、クラメルラオの下限とLehmann-Scheffeの定理の二つが手に入ったので、レベルアップした気がしますね。推定論は楽しい。

検定論: 検出力

残り25分くらいだったので、簡単なメモだけ残しておく。計算は難しくないけど、手順を覚える必要がある。

  • 検出力: 対立仮説が正しいとき、検定統計量が棄却域に収まる確率
    • 「検定統計量が棄却域に収まる」とは帰無仮説H_0を棄却すること
帰無仮説を採択 帰無仮説を棄却(対立仮説を採択)
帰無仮説が真 正しい判断 第一種の誤り(有意水準を設定するのはここ)
対立仮説が真 第二種の誤り ここの確率が検出力

参考

日本統計学会公式認定 統計検定 1級・準1級 公式問題集[2018〜2019年]

日本統計学会公式認定 統計検定 1級・準1級 公式問題集[2018〜2019年]

  • 発売日: 2020/03/11
  • メディア: 単行本（ソフトカバー）

Data Engineering StudyとCROSS Party online 2020に登壇しました

登壇 データ基盤

先週はデータ基盤やデータ整備のイベントで2件登壇してきました。どちらもオンライン登壇でした。

Data Engineering Study #4「データ分析基盤の障害対応事例LT祭り」

@yuzutas0さんにお声がけいただきまして、登壇することになりました。聴講者数多いし、他の登壇者の方もプロな方ばかりだったので、登壇前は胃が痛かった...。

私が担当しているデータ基盤、現時点ではめちゃくちゃ巨大なデータをパイプラインで扱っているわけでもなく、リアルタイム性がめちゃくちゃ重視されたりというわけでもなく、割と素朴なデータ基盤です。派手さはなくてひたすら地味ですが、世の中的にはむしろこちらのケースが多く参考になる方も多いかもと思って登壇しました。"壊れにくい"データ基盤を構築するためにMackerelチームで実践していることで書いた内容から、2つのトピックを発表しています。

質疑を含めた動画もすでに上がっているので、是非ご視聴ください。

CROSS Party online 2020 データ整備人が語る！DXにも不可欠なデータ整備の姿

データアーキテクト（データ整備人）を”前向きに”考える会を主催のしんゆうさんからお声がけいただきまして、パネリストとしてディスカッションしてきました。パネリスト慣れないな...と思ったけど、意外と今回で三回目だった。

パネルディスカッションの時間は話している側からするとあっという間に終わってしまったので、まだまだいくらでも話せそうな感じではありましたが、当日はこの辺の話題についてお話しました。

  • 周りをどのようにうまく巻き込むか
  • エンジニア以外でデータ整理をしている場合に、まず身につけるといいスキル（SQLとかPython等の言語以外も含め）
  • データ整備人としてのモチベーション
  • データ整備人の苦労
  • データ整備人の業務・貢献について、社内でどのようにアピールしているか
  • データ整備人の将来性

データ整備は接する他の職種の方が多いのでコミュニケーションをどう円滑に進めていくか、データ整備は割と地味な仕事ではあるのでアウトプットや貢献度合いをどうアピールするか、何でも屋になってしまいがちな職種ではあるけどどういうモチベーションで仕事をしているか魅力は何か、などがメインの話題だったかなと思います。割とテンパらずにいい話ができた気がします。

こちらも当日の動画がすでに上がっているので、是非ご視聴ください。

今後の予定

また別のイベントでお声がけいただきまして、来年の2月にデータ基盤・データ整備の話をさせてもらう予定です。がんばろう。