TL;DR組織開発の中でも特に組織構造を最適にするという点に注目する変化が早いスタートアップ企業では、問題に対する解像度が高く課題感を感じている人が組織構造を変更できる仕組みがあると不確実性の変化への対応力が高まるUbie Discovery での組織開発は、組織をコードベースに見立てて PR を送りそれを反映することで改善していくものと考えると理解しやすいUbie Discovery ではみんな（これは正確には全員ではないので後で説明する）プロダクト開発もやるし組織開発もやると聞くけど、組織開発というのは何をどうやっているか具体的にイメージが湧かない、という話をカジュアル面談などでよくされる。仮に自分が社外の人だったとしたらという観点で Web 上で情報を調べてみると、概念と大枠を理解できる記事として Holacracy の記事 https://note.com/ubie/n/nd86e2a5655c0 が出てくる。社内で実際に運用してみて、Ubie Discovery における組織開発はソフトウェア開発と類似性が高いと考えるようになった。主にソフトウェアエンジニアを読者として対象としているが、ソフトウェア開発に少しでも携わっている人であれば誰でも理解の一助になるかもしれない。組織開発に関する整理そもそも論として、組織開発とはどういうもので、なぜ必要で、誰がやるのか、などを整理しておく。組織開発とは何か？ここでは「組織の目的（ミッション）を達成するために、必要な機能を定義してそれを最適な構造に配置する」と定義しておく。組織開発には様々な側面があるのでこの定義が完璧なものとは思わないが、今回のエントリではこの定義を採用して話を進める。組織開発の具体例としては以下のようなものが挙げられる。チームでスクラムを実施するためにプロダクトオーナーやスクラムマスターなどを役割を誰がやるか決定するある API の運用をする責務は機械学習エンジニアにあるよねという全員の認識を揃えるエンジニア全体を横串で見ることのできる CTO や VPoE などのポジションを作って人をアサインする一緒に動いた方が効率がよいであろうチーム A とチーム B を合体してチーム C とする採用計画を立てて採用施策を推進したり、評価精度を整備して適用したりする新規事業を始めるためにチームを新たに作りそこに適切な人々をアサインするこのように小さなものから大きなものまで様々なレベルで組織開発は実施されている。なぜ組織開発が必要か？ある程度の人数が集まったら、みんな好き勝手に動いても一つの目的を達成するために効率的ではないので、一度組織を構築する必要があることはほぼ自明と言っていいだろう。なので、もう少し正確にこの問を書き直すなら「なぜ一度構築した組織を継続的に開発する必要があるのか？」というものになる。答えとしては「状況の変化に適切に対応するため」というものであり、これもあまり異論があるものではないだろう。状況の変化に対応して組織構造を変える、というのをどの程度の頻度で実施するかは向き合っている不確実性や組織規模に依存する。誰が組織開発をするのか？組織が数人〜十人という規模であれば全員が全体のことを把握してるので、殊更に意識せずとも自然と全員でやるというものになるだろう。こうした事情から、一定規模以上の組織で働いたことしかない人にとっては、組織開発というのは経験がなくそもそも何をどうやるのかよく分からないものになっていることが多いと思われる。組織開発に対する課題感組織開発に対する課題は組織の規模や状況に応じて色々あるとは思うが、典型的なスタートアップ企業においては「不確実性の変化への対応が遅くなってしまう」という課題が最も深刻なものとなる。典型的なスタートアップ企業は大きな不確実性と向き合っており、しかもその変化は激しい。限られたリソース、特に人的リソース、を組織開発を通して最大限に有効活用して不確実性の変化に対応していきたいが、一部の人が低頻度で実施するスタイルでは十分な速度で対応できない危険性が高い。組織構造を変えるべきだと感じている張本人とは限らない一部の人々が情報を集めて整理し、他の人から見るとどう決まってるかよく分からないプロセスで組織構造を変更し、新たに変更が必要になったらまたそれを繰り返す、このやり方で十分な速度を出すのが難しいというのは考えてみれば当然のことに思える。要は、成し遂げたい目的に対して、世の中でよく使われている手法はあまりマッチしていないのである。理解度が高くて課題感を持っている当事者が変更することができ、変更のプロセスをその理由を含めて誰でも即時に確認でき、素早くインクリメンタルにも変更することができる、そんな手法が必要である。Ubie Discovery の組織開発をソフトウェア開発的に理解する組織開発は「不確実性の変化への対応」を目的としているという話をしたが、これはソフトウェア開発（ここでは自社プロダクト開発を想定）においても主たるテーマである。抽象的な意味では目的が同じなので、実現のための方法が類似するというのは自然なことであり、先ほど挙げた必要とする手法はソフトウェア開発で日々実践していることに近い。Ubie Discovery で採用している  Holacracy という仕組みはまさに必要としている組織開発の手法となっている。以降では Holacracy による組織開発をソフトウェア開発と対応づけて、具体的にどうやって組織開発をしていくのかを説明する。対応関係を考えるHolacracy による組織開発とソフトウェア開発の対応関係を考えてみる。組織構造 = コードベース組織開発は「組織の目的（ミッション）を達成するために、必要な機能を定義してそれを最適な構造に配置する」ことだと定義したが、これは「ある課題を解くためのプロダクトのコードベースを、必要な機能を定義して最適な構造に設計して作り上げる」ということに対応している。Holacracy では構造化された自然言語で組織構造が記述されている。組織構造を変えるためのプロトコル = Pull Request ベースの開発組織構造を書き換えるプロトコルは Pull Request ベースの開発に対応している。ソフトウェア開発では、コードベースをよりよくするために Pull Request を送り、それを他のメンバーがレビューし、承認されるとコードベースに反映される。Holacracy による組織開発も同様の流れで実施される。このように組織構造を変えるべきだという Proposal を送り、それが他のメンバーがレビューし、承認されると組織構造に反映される。この一連のプロセスは誰でも確認することができ、あらゆる変更に対してその目的などが画一的なフォーマットで与えられる。プロトコルに即していればいつでも誰でも Proposal を送ることができるため素早い変更が可能であり、Proposal はある役割に一つの責務を追加するといった小さなものも含むのでインクリメンタルな改善も可能となっている。実際の Proposal の例は以下のようなものである。組織開発者 = ソフトウェア開発者課題感を持っているメンバーであれば誰でも開発に貢献することができる。ソフトウェア開発の方はコードベースがプログラミング言語で記述されているので、プログラミング言語に造詣が深くないメンバー（例えばプログラミング経験に乏しいプロダクトオーナー）は貢献が難しい面があるが、これは難しいだけで貢献ができないということではない。組織構造は自然言語で記述されているので比較的容易に貢献が可能だが、前述のプロトコルについては十分に理解している必要がある。具体例上記の対応により、ソフトウェア開発に携わる人であればどのように組織開発をしていくのかがある程度イメージできるようになったのではないかと思う。ここでは具体的な例を持ち出してそのイメージをもう少し膨らませたい。機械学習エンジニアの責務として本番で稼働する XYZ API の運用を追加したい本番で稼働している XYZ API の運用をする人が明確に定まっておらず、エラーが起きたりするとそれに気づいた人が対応しているという状況を考える。このように暗黙の期待となっている責務は属人化しやすく、なんかあったらあの人が対応してくれるよね、となって頑張った分だけ負担が増すという辛い状況になったりする。これは組織にとって必要な機能が明確化されてない状況であり、組織構造の中に追加されるべきものである。エラーの度に善意で対応していた人がこれでは組織として適切ではないと考え「機械学習エンジニアという役割に XYZ API の運用という責務を追加。なぜならばこれは重要な責務だが暗黙の期待となっているため。」という Proposal を送り、他の人が承認して明確化された責務として記載されるようになった。Holacracy はこのように役割が果たすべき責務を明確化し、その役割に人をアサインするという仕組みになっている。人をアサインする権限を持つ役割も存在し、Ubie Discovery ではやる気と能力がある人がアサインされることが多い（組織に必要なのに適任がいなければ採用を頑張らねばならない！）。同じようなことをやっているチーム A とチーム B を合体してチーム C としたいチーム A で働いている人が OKR すり合わせのためにチーム B と議論した結果、共通で開発した方がいい機能を別々にしかもちょっと違った形で開発していそうということが判明した。この可能性に気づいた人は、共同で開発しないと後々有害になりうるしリソースも最適に活用できていないと考え、変更をしようと考えた。影響が大きそうなので、チーム A,B の人から改めて情報を収集し議論を深めて、確かに弊害になりそうと確信したので「チーム C を作り、チーム A とチーム B は削除する。なぜならば元の二つのチームは似たことをやっていて、似てるけど異なる機能を作って弊害となりうるのとリソースの無駄遣いであるため。」という Proposal を送り、関係者が承認したのでチーム編成が書き換えられることとなった。Ubie Discovery では実際にこのような流れで数日程度で大きな組織構造の変化が発生したりする。ちなみに正確には Holacracy ではチームという概念はなく、サークルというある共通の目的をベースとして様々な役割を構造化する概念がある（ここでは簡単のためチームと同義語と思っておいてよい）。この例は、ソフトウェア開発において複数箇所で同じようなコードが繰り返されていて共通化した方がよい、という状況に似ているかもしれない。（補足）Ubie Discovery では組織開発をするのは Holon という人材冒頭で Ubie Discovery ではみんな組織開発をするけど正確にはみんなではない、ということを書いたのでそれの補足をしておく。Ubie Discovery における組織開発はソフトウェア開発と似ているという話をしてきたが、どちらもやるということは事業と組織に必要なあらゆる側面にコミットするということであり、それがマッチする人材もいればそうでない人材もいる。マッチする人材を Holon 人材と名付け、少なくとも Holon 人材は全員組織開発にコミットする、ということになっている（Holon というのは Holacracy の語源となった単語で、部分であり全体であるというような意味）。一方で、自身の特定領域にコミットし、事業のリターンを最大化するのがマッチする人材もいるし組織としても必要だという議論を経て、そのような人材を Focus 人材として定義している。Focus 人材についてはスライドを公開しているので、詳しくはこちら: Focus 人材紹介の Google Slides へのリンク余談だが、この Holon 人材や Focus 人材などの概念を作っていくところも、ソフトウェア開発において概念を作っていくところとの類似性があるなと感じる。Ubie Discovery の組織開発という特定のドメインについて深掘りをしていくと、世の中でよく使われている概念とは異なるものであることに気づき、新たな名前を与えてそれを育てていく必要がある（Focus 人材は最初の頃は Specialist 人材と呼んでいたが、世の中でよく使われる意味とは異なることに気づき、混乱を避けるため敢えて独自の名前を与えたという経緯がある）。ソフトウェア開発とあまり似てないところソフトウェア開発とあまり似ていない部分としては、Proposal はそれによって困りごとが発生することが明確に示されない限りは基本的に承認されるという点である。ソフトウェア開発では論理的に良し悪しを判定できるケースが多いので、その変更はふさわしくないのでこういう変更に書き直してください、などと言いやすいが、組織開発においてはそこまで明確に言い切れるケースは少ないためである。チームトポロジーのような組織のデザインパターン的なものがもっと成熟していけば、もしかすると変わっていくのかもしれない。まとめUbie Discovery における組織開発をソフトウェア開発と対応づけて説明してみた。どちらも不確実性の変化に対応するという目的があり、Holacracy による組織開発はソフトウェア開発の方法と類似性が高い。興味が出てもっと詳しく聞いてみたいという人がいたらお気軽にご連絡ください！

Ubie Discovery における組織開発をソフトウェア開発的に理解する

TL;DR2021 年に読んだ本を感想と共に振り返ってみる記録を残していたのは 12 冊だったもう少しちゃんとした技術書をたくさん読まないとなぁ（毎年思っている…）2021 年に読んだ本を記録を残しているものに限って感想と共に振り返ってみる（記録を残してない書籍もあるが、それらは無視）。雑に技術書と読み物に分けて、雑多に書いていく。技術書効果検証入門 amazon へのリンク機械学習を解釈する技術 amazon へのリンク施策デザインのための機械学習入門 amazon へのリンク実践的データ基盤への処方箋 amazon へのリンクGoogle のソフトウェエンジアリング amazon へのリンク読み物新装版達人プログラマー 職人から名匠への道 amazon へのリンクエンジニアリング組織論への招待 amazon へのリンク正しいものを正しく作る amazon へのリンク医療現場の行動経済学 amazon へのリンク探求する精神 amazon へのリンクスティーブ・ジョブズ I, II amazon へのリンク I, amazon へのリンク IIBAD BLOOD シリコンバレー最大の捏造スキャンダル 全真相 amazon へのリンクまとめ一番良かった本は「施策デザインのための機械学習入門」だった。久々に著者の哲学をしっかりと反映して、かつ一貫した記述でしっかりと書いてある本を読んだ気がする。ちゃんとした技術書をもっと読まないとなぁ（毎年思っている…）。

2021年に読んだ本を感想と共に振り返る

TL;DR2021 年も頑張った（5 年連続 5 回目）。会社の仕事を中心に頑張ったが、会社の仕事に満足していてその他の活動はだいぶ少なくなりがち2022 年も頑張っていきますか〜！！！2021年が終わった。 全体的によく頑張った。毎年頑張っていて偉い。本当に偉い。凄い（去年のをコピペ）（去年のをコピペ）（去年のをコピペ）（去年のをコピペ）。ここまで連続で頑張るとそろそろギネス記録して申請すべきかもしれない。ということで例によって一年を簡単に振り返ってみる。仕事会社の仕事を頑張った一年だった。いくつかの微妙な事情があって仕事の内容を大っぴらに書くことができない、というところは今の会社の数少ない不満なところではあるのだが、仕事の内容自体は気に入ってるし毎日楽しく働いている。派手なことはあまりやっていないが、ちゃんとした改善につながることを地道に続けた結果として積分すると大きな成果になっており、やるべきことをちゃんとやれているなという実感がある。データそのものに高い価値があるというのはやはり素晴らしいことだなと日々痛感している。ただ、もう少し大きな施策にチャレンジする機会を増やしたかったなという反省もある。自分のチームは採用が比較的うまくいっていたこともあり、全社最適を考えてチームメンバー（自分も含む）が一定期間他のチームに行くことが多く、十分な出力が担保できなかったというのが原因となる。これはこれで色々なチームの色々な施策に携われたのでよかったのだが、来年は人を呼び戻しつつデータやアルゴリズム観点での新しい価値創出にも力を注いでいきたい。採用も会社の最優先事項の一つだが、これは呼吸をするように日々進めている。自分はとにかくマッチする可能性がある人にアプローチし続けることこそが根幹だと思っているので、全社的な施策をどうこうするとかはあまり関わってないけど日々声がけをしている。興味がある人はいつでもお声がけください。組織開発とかはこれをやろうと思ったらそれを役割として定義してスッと着手できるのが今の会社のよいところなので、これは自分が推進したいなと感じたところを手を挙げて進めている。雑談促進とか社内表彰制度をいい感じにするとかをやっていた。仕事に満足しているので副業をしようという気が起きずに全くやらずに一年が過ぎてしまった。税金の観点から少しはやりたいなという気持ちはあるのだが、一方でそういう気持ちで働こうと思ってやる気が出ないなこともあり、これは来年もあまり頑張れない気がしている。アウトプット会社の仕事が中心だったので目立ったアウトプットはないが、会社の仕事とあまり関係ないものも少しはやった。一番良かったのは podcast の配信を途中までは頑張ったというところか。特に、単発で終わると理解が深まらないなと思って DALL·E の理解に向けて という part1,2,3 のシリーズものをやったのと、専門家をゲストに迎えて AlphaFold について話したのは、自分にとってとてもよい勉強になったのでよかった。後者は 2 hours 超えで誰もこんなの聞かないかなと思ったけど、ゲストの方の知名度もあってか結構な人数に聞いてもらえたようだ。以下が今年配信した回と再生回数のまとめ。結構専門的な内容でしかも長いので、そもそも聞きたいという人がそんなにいないだろうなと思ってるけど、その割には再生されてるかなという印象。トピックを準備して話すのをサボってしまって夏以降全然配信できていないのは反省点…Web 上で話題にされることは少ないけど、カジュアル面談とかで人と話してみると聞いてますと言ってくれる人が結構いるので、来年も回数はそんなに多くはならないだろうけど続けてはいきたい。ブログはこの振り返りエントリを含めて 9 本書いた。大した内容でなくても月 1 本くらいは書きたいところ。paper-reading は 6 個: https://github.com/yoheikikuta/paper-reading/issues?q=is%3Aissue+is%3Aopen+created%3A2021-01-01..2021-12-31対外発表は驚きの 1 件。オンラインになってから勉強会の類に参加するモチベーションがだいぶ下がってしまった。参加しても発表してちょっとした質疑応答だけして終わりというのが殆どなので、締切駆動でインプットするという以外の利点がほぼないというのが一番の理由と思う。オミクロン株が心配ではあるけど、来年はできたらオフライン勉強会とか再開したいなぁ。外から見えるアウトプットという観点ではだいぶ寂しい感じはするのだが、今後もこういう感じで細々と続けていくということになりそう。健康Ubie に入社したこととの因果関係は明らかにされていないが、自身の健康についても考えさせられることが多い一年だった。これは 5 月に尿路結石になって本当にやばかったときのツイート。幸い痛みは長引かなかったが、体質的に尿酸値が高かったり結石ができやすい可能性が高かったりで、かなりの恐ろしさを感じた一件である。食事を気をつけたり水分を多く摂ることを心がけるようになったが、同僚の医師からはめっちゃ再発しやすいから震えて待っといてくださいと言われており震えている。いきなり腰がめちゃくちゃ痛くなって、尿意と残尿感があるので AI受診相談ユビー を使ったら尿路結石と出た。震えながら病院に行ったらマジで尿路結石の可能性大だった（レントゲンで微妙に見えるか？というくらいの小ささではあったけど）。あがが… pic.twitter.com/3wGfXc9et3— Yohei KIKUTA (@yohei_kikuta) May 19, 2021 これは 12 月にアレルギーかなにかでじんましんが出てビビったときのツイート。多分何かの食べ物でアレルギー反応が出たのだと思うけど、これまで食べ物でアレルギーがあるのは自覚してなかったので結構驚いた。大事には至らず数日でじんましんは引いたが、認識していないものがいきなり発症するのは怖いなぁと思った。昨日いきなり皮膚が赤くなってビビった。同僚医師にそれは蕁麻疹で危険信号はこれこれだからそうなったら病院行こうなどと教えてもらい、改めて素晴らしい環境だ。ユビーAI受診相談でもじんましんと出て有用だなと思いつつ、皮膚疾患ならやはり画像情報欲しいなとか改善したい点もたくさん！ pic.twitter.com/04A6y1Mk5b— Yohei KIKUTA (@yohei_kikuta) December 11, 2021 その他にも運動不足が祟って脂質代謝の数値があまりよいものじゃなくなったりして、最近はジムを契約してちゃんと運動をするようになったりした。運動がどれくらい効果を発揮するかは現状ではまだ測定できてないので、来年の早いタイミングでもう一度検査をして確かめたい。健康に不安を抱えた時、同僚に医師がいると色々なアドバイスがもらえて本当に助かっている。医学の専門性と発症が確率的であるということから、適切な医療にかかるというのはほとんどの人間にとって非常に難しい。データによるパターンマッチングなどをもっと推し進めて医療体験を向上させていけるように頑張りたいね。健康より大事なものは存在しないので、何かしらのシグナルを検出したら今後も早めにアクションをしていきたい。その他年始に立てた目標を見返してみると、仕事もプライベートもそれなりに達成した。仕事では新しい取り組みにもっとチャレンジしていきたいので、来年はそこを頑張ろう。プライベートの目標は結婚式を成功裡に終えるというものを含めて、ほぼパーフェクトに達成したので偉い。アウトプットはイマイチな感じだが、これは大きく改善するモチベーションはそんなにはないので、来年はもう少しだけマシにしたいというところで目標設定をしていこう。運動は始動こそ遅かったが、最近はよく運動しているので、もう少し経ったら健康面にポジティブな影響があるかを検査して調べたい。ゲームは結構やった。薦められた Bloodborne は本当に最高だった。その他にも APEX や バイオハザードヴィレッジ や メトロイドドレッド などをやった。来年は ELDEN RING がめちゃくちゃ楽しみ。漫画は引き続きたくさん読んでるが、新作に手を出す数は減っているのでもう少し頑張りたいところ。Trickle の year stats は 279 activities, 100 days だったので例年よりもだいぶ下がってしまった。PC 買い替えたらインストールせずに放置してしまったのが大きな要因… 最近インストールしたので来年はまた気を取り直して頑張っていきたい。ということで色々ありましたが、来年も頑張っていきましょう！まとめ2021 年も終わりです。みなさま良いお年を。

2021年のまとめ

TL;DRpart3 は STRUCT/ARRAY 型の理解、便利機能、preview 機能について書くBigQuery は分析に便利な機能がたくさんあって楽しいBigQuery で分析する際の tips シリーズは一旦これで終了part3 では part2 よりももっと具体的なクエリを対象として tips をまとめる。具体的なクエリになるほど公式リファレンスを見れば分かるというものになりがちだが、その中でも個人的にこの辺を押さえておくとよさそうというものについて書くことにする。tips7: STRUCT 型と ARRAY 型を使いこなすpart2 のスカラー関数・集計関数・分析関数のところでも触れたが、BigQuery で分析する際に STRUCT 型や ARRAY 型はよく使うので、これらに関してはスムースに読み書きできるようにしておくと役に立つ。と言っても STRUCT 型の場合にはそれほど気を付けることはないが、NULL の判定は注意が必要。STRUCT 自体が NULL なのかその中の field が NULL なのかは明確に区別する必要があり、前者は単に struct_column IS NULL のように比較すればよいが、後者は以下の例で分かるように STRUCT リテラルでは比較できないので field アクセスして NULL 比較せねばならない。SELECT IF((1,"a") = (1,"a"),1,0) AS resultUNION ALL SELECT IF((1,NULL) = (1,NULL),1,0)UNION ALL SELECT IF((NULL,NULL) = (NULL,NULL),1,0)UNION ALL SELECT IF(STRUCT(NULL AS c1,NULL AS c2).c1 IS NULL,1,0)行result11203041ARRAY 型の場合も ARRAY 自体が NULL なのか中身が空の配列なのかを区別する必要があり、前者は単に array_column IS NULL のように比較すればよいが、後者は ARRAY_LENGTH(array_column) = 0 のように指定する必要がある。これらの違いは BigQuery console 上で見ても違いが分からないので、ちゃんと認識しておかないと想定外のミスをしてしまう可能性がある。ちなみに ARRAY 型は配列の要素に NULL を持つことは禁止されている。また、イコールで比較する機能は提供されていない。WITH  test AS (  SELECT [1,2,3] AS array_column  UNION ALL SELECT []  UNION ALL SELECT NULL)SELECT  array_column,  array_column IS NULL AS is_null_array_column,  ARRAY_LENGTH(array_column) = 0 AS is_zero_length_array_columnFROM  test行array_columnis_null_array_columnis_zero_length_array_column11falsefalse232falsetrue3truenull次に ARRAY 型を扱う上で最も重要になる UNNEST について。UNNEST を最もよく使うのは ARRAY を解いて元のソーステーブルに JOIN して使うケースだろう。UNNEST を使う場合 correlated join について一度は公式リファレンス https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#correlated_join に目を通しておくのがよいと思う。その上で以下のように具体的な例で振る舞いを把握しておくのがよい。WITH  sequences AS (  SELECT    1 AS id,    [1,2,3] AS some_numbers  UNION ALL SELECT    2 AS id,    [2,4] AS some_numbers  UNION ALL SELECT    3 AS id,    [3] AS some_numbers  UNION ALL SELECT    4 AS id,    [] AS some_numbers)SELECT  id,  flattened_numbersFROM  sequences,UNNEST(sequences.some_numbers) AS flattened_numbers----- 以下全部同じ振る舞い--   sequences CROSS JOIN UNNEST(sequences.some_numbers) AS flattened_numbers--   sequences, sequences.some_numbers AS flattened_numbers--   sequences INNER JOIN UNNEST(sequences.some_numbers) AS flattened_numbers----- UNNEST する ARRAY において NULL ARRAY や要素が空のものも残す場合は LEFT JOIN--   sequences LEFT JOIN UNNEST(sequences.some_numbers) AS flattened_numbers行idflattened_numbers111212313422524633UNNEST は IN UNNEST(foo) などでも使えてこれは単に配列をバラしてスキャンするだけだが、この correlated join の場合は単に配列をバラしてるだけではなくて特別な振る舞いをするものなので慣れが必要である。これはもうあれこれ考えるのではなくこういうもんだとして慣れて、それを前提知識とするのが一番いいかなと思っている（脳筋だが、それくらいよく使うものなので）。ちょっと脱線だが、取り出したい要素が一行に対して一つの時はスカラーサブクエリの中で UNNEST を使うこともできる。例えば先ほどの例で ARRAY の中身の MAX だけを取り出したければ以下のように書けるけど、UNNEST とスカラーサブクエリが重なって複雑になって読みにくいので個人的にはあまり好きではない。素直に correlated join して GROUP BY とかする方が好み。WITH  sequences AS (  SELECT    1 AS id,    [1,2,3] AS some_numbers  UNION ALL SELECT    2 AS id,    [2,4] AS some_numbers  UNION ALL SELECT    3 AS id,    [3] AS some_numbers  UNION ALL SELECT    4 AS id,    null AS some_numbers)SELECT  id,  (SELECT MAX(flattened_numbers) FROM UNNEST(sequences.some_numbers) AS flattened_numbers) AS max_some_numbersFROM  sequences行idmax_some_numbers11322433344nullARRAY は順序付きリストでかつ OFFSET を使って要素にアクセスしてスカラー関数のように使うこともできるので、特定の位置の要素のみに興味がある場合は UNNEST を使わずに望むクエリを書くこともできる。例えば ARRAY に入っている最初の要素だけ取り出せればいいというのであれば、以下のように書けばよい。ただしこれは対象としている ARRAY が何かしらのルールでちゃんと sort されていることに依存しているので、それが保証されてない限りはちゃんと UNNEST して ORDER BY するなりしてクエリを書くべき。ここでの話とは直接関係しないが、UNNEST すると順序が保証されなくなる https://cloud.google.com/bigquery/docs/reference/standard-sql/arrays#flattening_arrays ので注意。WITH  sequences AS (  SELECT    1 AS id,    [1,2,3] AS some_numbers  UNION ALL SELECT    2 AS id,    [2,4] AS some_numbers  UNION ALL SELECT    3 AS id,    [3] AS some_numbers  UNION ALL SELECT    4 AS id,    null AS some_numbers)SELECT  id,  some_numbers[OFFSET(0)] AS first_elem_some_numbersFROM  sequences行idfirst_elem_some_numbers11122233344null最後に GENERATE_ARRAY 系に触れておく。BigQuery には連続した要素を持つ ARRAY を生成する便利な関数が存在する。公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#generate_array この辺り。例えば、ログを集計して日毎のエラー数を出す時に、エラーがない日があると日付が歯抜けになってしまうのでダッシュボードなどで使う時にちょっと不便だったりすることがあり得る。そういう場合には例えば以下のように GENERATE_DATE_ARRAY 関数を使ってテーブルを生成し、これに対して LEFT JOIN するなどすればよい。WITH  base_date AS (  SELECT    generated_date  FROM    UNNEST(GENERATE_DATE_ARRAY(DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY), CURRENT_DATE())) AS generated_date )...ARRAY を使いこなすと分析でだいぶ自由が効くようになるので、バンバン使っていきましょう。tips8: いくつかの便利機能紹介雑多な感じにはなるが、クエリを書くときの便利機能をいくつか紹介する。UDF公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/user-defined-functionsUDF は JavaScript が使えるので、分析を BigQuery だけで完結させたいという場合に有効である。そんなに面白い例ではないが、例えば以下のようにフィボナッチ数を計算することができたりする。CREATE TEMPORARY FUNCTION  fibonacchi( num INT64 )  RETURNS INT64  LANGUAGE js AS "function fibo(n) {return n < 2 ? n : fibo(n - 2) + fibo(n - 1);} return fibo(num);";WITH num_table AS (  SELECT num FROM UNNEST(GENERATE_ARRAY(1,10,1)) AS num)SELECT  num,  fibonacchi(num) AS resultFROM  num_table 行numresult111221332443555668771388219934101055SQL だけだと表現しにくい数理的な演算やちょっとした自然言語処理をしたい場合に JavaScript UDF は便利。JavaScript のコードが長くなるという場合には GCS にファイルを置いて読み込む https://cloud.google.com/bigquery/docs/reference/standard-sql/user-defined-functions#including-javascript-libraries こともできる。（今回のシリーズでは気にしないと言ったが）パフォーマンスは犠牲になる https://cloud.google.com/bigquery/docs/best-practices-performance-compute#avoid_javascript_user-defined_functions ので注意。現在は JavaScript のみ対応してるが、最近の Google Cloud Next で他の言語への拡張が話題に挙がっていたので期待大。https://www.youtube.com/watch?v=MY2vBrjA_xg&t=367sチームで同じような処理を使い回す場合にも UDF は便利だが、その場合は適当に作りまくると管理が大変になりがちなので注意。会社だと Terraform で管理してるが、今回の主題からは離れているので割愛。JSON functionsBigQuery は JSON データを扱うための便利な関数も提供してくれている。公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/json_functionsここで一番言いたいのは、JSON_EXTRACT を使っている人は JSON_QUERY や JSON_VALUE を使うようにしようということだ（公式が推奨してるので）。実際のところこれらの違いは大きくはないが、JSON_EXTRACT では JSONPath で invalid な文字が出てきた時に single quote と [] を使ってエスケープする必要がある。JSON_QUERY などの場合は [] を使わずに double quote を使うことができる。SELECT JSON_QUERY('{"a.b": {"c": "hello world"}}', '$."a.b"') AS testUNION ALL SELECT JSON_VALUE('{"a.b": {"c": "hello world"}}', '$."a.b"')UNION ALL SELECT JSON_QUERY('{"a.b": {"c": "hello world"}}', '$."a.b".c')UNION ALL SELECT JSON_VALUE('{"a.b": {"c": "hello world"}}', '$."a.b".c')-- UNION ALL SELECT JSON_EXTRACT('{"a.b": {"c": "hello world"}}', '$."a.b".c') AS test  -- これはエラー-- UNION ALL SELECT JSON_EXTRACT_SCALAR('{"a.b": {"c": "hello world"}}', '$."a.b".c') AS test  -- これはエラーUNION ALL SELECT JSON_EXTRACT('{"a.b": {"c": "hello world"}}', "$['a.b']")UNION ALL SELECT JSON_EXTRACT_SCALAR('{"a.b": {"c": "hello world"}}', "$['a.b']")UNION ALL SELECT JSON_EXTRACT('{"a.b": {"c": "hello world"}}', "$['a.b'].c")UNION ALL SELECT JSON_EXTRACT_SCALAR('{"a.b": {"c": "hello world"}}', "$['a.b'].c")行test1{"c":"hello world"}2null3"hello world"4hello world5{"c":"hello world"}6null7"hello world"8hello world他にも JSON-formatted string から ARRAY を抜き出す JSON_QUERY_ARRAY や JSON_VALUE_ARRAY が存在する。例えば、{"a": [1,2,3,"abc"]} という STRING から ARRAY を抜き出し（各要素は STRING となる）、その各要素を使って concat して一つの STRING にするみたいなのは以下のようにスッと書ける。SELECT  ARRAY_TO_STRING(arr, "-") AS testFROM (SELECT JSON_VALUE_ARRAY('{"a": [1,2,3,"abc"]}','$.a') AS arr)行test11-2-3-abcJSON データを分析する場合は JSON functions の公式リファレンスを一通り眺めてからやるとだいぶ見通しがよくなるだろう。Scripting statementsScripting は一度のリクエストで複数個のステートメントを実行できる機能である。公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/scriptingその機能からして分析で使いたいものはあまりないのだけど、自分は対象を変えながら使い回しをするクエリ DECLARE を使ったりする。例えば、以下のようなクエリを手元に持っておいて、必要に応じて target_corpus の要素だけを書き換えて実行する。DECLARE target_corpus ARRAY<STRING> DEFAULT ["sonnets","various","1kinghenryvi","2kinghenryvi","3kinghenryvi"];SELECT  word,  COUNT(1) as cntFROM  `bigquery-public-data.samples.shakespeare`WHERE   corpus IN UNNEST(target_corpus)GROUP BY   wordORDER BY  cnt desc, word行wordcnt1'52'tis53A54Ah55Alas5.........これは TEMPORARY FUNCTION を使っても同じようなことができるけど、文法的に変数であることが明確なので自分はこっちの方が好み。ただし、複数個のステートメントの実行は BigQuery コンソールじゃないと対応できないことが多い（20211127 時点で DataGrip ではまだサポートされてない）ので、泣く泣く WITH 句を使って書いたりすることもあり、他の環境でもサポートされるといいなぁと常々思っている。Scripting は自分は使ってるものがあまりないけど、公式リファレンスを眺めると色々できることがあるというので面白い。tips9: preview 機能を楽しむ最後は 20211127 時点で preview である機能の中で面白そうなものを眺めてみることにする。まずは QUALIFY 句。公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#qualify_clauseこれは分析関数のフィルタリングができるというとても便利な機能で、例えば以下のように使用できる。SELECT  word,  word_count,  LENGTH(word) / MAX(LENGTH(word)) OVER () AS ratio_word_lengthFROM  `bigquery-public-data.samples.shakespeare`WHERE   TRUE QUALIFY   ratio_word_length > 0.6ORDER BY  ratio_word_length DESC, word行wordword_countratio_word_length1honorificabilitudinitatibus11.02Anthropophaginian10.62962962962962973indistinguishable10.62962962962962974undistinguishable20.6296296296296297これまでは WITH 句を使って多段で処理したりする必要があったが、それがすっきりと書けるのでこれはぜひ GA になって欲しい。と言いたいところだが、上のクエリには無意味な WHERE TRUE が入ってることにお気づきだろうか。QUALIFY を使うには WHERE もしくは GROUP BY もしくは HAVING の少なくとも一つが含まれている必要があり、望むクエリを書く際にこれらを使う必要がない場合は、上記のように WHERE TRUE のような虚無を挿入しなければならない、という制約があるためである。そしてこれは an implementation limitation ですと説明されている…悲しい…それでも GA にはなって欲しいが。次は table sampling で、これは大きい（1 GB 以上）テーブルのランダムなサブセットを取得することができる機能である。公式リファレンスは https://cloud.google.com/bigquery/docs/table-samplingBigQuery は LIMIT で件数を区切ってもデータスキャン量は変わらないが、以下のように書くことでデータスキャン量が変わっていることが確認できる。デカいテーブルに対して色々クエリを投げながら分析する時に、クエリが固まるまではサンプリングして試せば無駄な課金を減らしたり実行時間を早くしたりできる。SELECT  *FROM  `bigquery-public-data.samples.wikipedia` TABLESAMPLE SYSTEM (1 PERCENT)LIMIT 10（結果は deterministic ではなくキャッシュもされないので実行ごとに変わり得る）新しい機能好きな人はちょくちょく Release notes https://cloud.google.com/bigquery/docs/release-notes などをチェックしておくと楽しいかもしれない。まとめBigQuery を使って分析する際の tips part1~3 を書いた。part3 は公式リファレンスが一番、みたいな話になってしまった…part1: 開発環境やデータ連携 https://yoheikikuta.github.io/BigQuery_tips_part1part2: クエリを書く際に押さえておくとよいこと https://yoheikikuta.github.io/BigQuery_tips_part2part3: 具体的なクエリの tips （このエントリ）https://yoheikikuta.github.io/BigQuery_tips_part3

BigQuery を使って分析する際の tips (part3)

TL;DRpart2 はスカラー関数・集計関数・分析関数、サブクエリ、型変換について書くBigQuery は便利な機能が色々備わってるので、それらの基本的な振る舞いを頭に入れておくと便利本文と全然関係ないけど自分のブログはコードブロックの表示とかイマイチなので改善せねばか…part1 に続いて part2 として、分析する際によく使うことになる道具について理解しておくとよいことをいくつかピックアップしてまとめる。ちなみに今回の tips シリーズではクエリのパフォーマンスは気にしない。自分が現状仕事で書いてるものはほぼクエリのパフォーマンスを気にしなくてよいのと、そもそも BigQuery が強力なので細かいことを気にせずに書いてしまって殆どの場合問題ない、というのが理由。実行前のデータスキャン量だけ見ておいて、数百 [GB] 以上のクエリをガンガン実行しそうとなったらコストを気にし始める、というくらいしておけば自分の環境では十分という状況である。tips4: スカラー関数・集計関数・分析関数分析でよく使う関数といえば集計関数や分析関数だが、これらの振る舞いを理解しておくために合わせてスカラー関数も見ておく。これらの関数の振る舞いとして、入力行と出力行の対応が以下のようになっているというイメージを念頭に入れておくとよい。スカラー関数 (入力行):(出力行) = 1:1集計関数 (入力行):(出力行) = N:1分析関数 (入力行):(出力行) = N:Nスカラー関数スカラー関数は入力行と出力行が 1:1 になるもので、例えば以下のクエリは word column の各行に対して最初の文字から 2 文字目までを取得するクエリになっている。SELECT  word,  SUBSTR(word, 0, 2) AS substr_wordFROM  `bigquery-public-data.samples.shakespeare`ORDER BY  word DESC行wordsubstr_word1zwaggeredzw2zoundszo3zonezo.........これは特別何かを意識する必要はないものではあるが、リファレンスなどを呼んでてスカラー関数と出てきたときはこのような振る舞いをするものだと認識しておけばよい。スカラー関数を殊更に意識するところはそんなにないが、スカラー関数にはたいてい SAFE. 接頭辞が利用可能で、これをつけるとエラーを発生させずに NULL を返すものに変えることができる。上の例でいうと、SUBSTR(word, 0, -2) とすると Third argument in SUBSTR() cannot be negative というエラーが発生するが、SAFE.SUBSTR(word, 0, -2) とすれば各行で NULL が返る（この例ではあまり意味が感じられないが、引数が何かの計算よって得られるもので、それが負になりうるケースがあるという場合には使えるかもしれない）。脱線になるが、この SAFE. という接頭辞は演算子には使えない。分析上よく遭遇するエラーとして division by zero があるが、これを防ごうとして 1 SAFE./ 0 などとすることはできない。そのため、演算子と等価でありエラーが出るときには NULL を返す SAFE_xxx スカラー関数が準備されており、除算の場合は SAFE_DIVIDE を使うことになる（なお、整数除算の場合は演算子がなくスカラー関数 DIV があるのみなので、こちらの場合は SAFE.DIV とすればよい）。さらに脱線になるが、この SAFE. というのは関数の返り値を評価するときに使われるもので、引数の式を評価するときには使われないものであると頭に入れておくと、SAFE. が使えないスカラー関数がいるということも理解しやすい。例えば LOWER スカラー関数は STRING を引数にして、STRING であればエラーは出ないので SAFE.LOWER はサポートされていない。Lower(1) のようなものは引数の式を評価して型がマッチしないということで実行前にエラーが分かるためで、型の静的解析でエラーか分かるものは SAFE. とかいらなくて実行時に初めてエラーか分かるものには SAFE. が使えるみたいなイメージ。ついつい SAFE. の話をしてしまったが、ともかくスカラー関数は (入力行):(出力行) = 1:1 という関係で素直に使えばよい。集計関数集計関数に関する公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/aggregate_functions である。集計関数は入力行と出力行が N:1 になるもので、例えば以下のクエリは word_count の DISTINCT COUNT を計算するクエリである。SELECT  COUNT(DISTINCT word_count)FROM  `bigquery-public-data.samples.shakespeare`行distinct_count_word_count1483複数行（ここでは全ての行）に対して集計した結果を1行で返しているというもので、特に難しいところはない。GROUP BY で集計するグループを設定するというのも普段から自然にやっている人が多いだろう、例えば以下のような感じ（集計関数の引数に入れてる LIMIT は単に結果が長くなりすぎるので切っているだけ）。SELECT  word_count,  COUNT(DISTINCT word) AS distinct_word_count,  COUNT(DISTINCT corpus) AS distinct_corpus_count,  STRING_AGG(word, "&" LIMIT 3) AS string_agg_word,  ARRAY_AGG(word LIMIT 2) AS array_agg_wordFROM  `bigquery-public-data.samples.shakespeare`GROUP BY  word_countORDER BY   word_count行word_countdistinct_count_worddistinct_count_corpusstring_agg_wordarray_agg_word113019842LVII&augurs&dimm'dLVIIaugurs22894642cheque'd&affords&meetcheque'daffords..................集計関数単体だと tips というほどの情報もないのだが、この (入力行):(出力行) = N:1 という関係を意識しつつ分析関数と併せて理解しておくと見通しがよくなることが多い。分析関数分析関数に関する公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/analytic-function-concepts である。分析関数は入力行と出力行が N:N になるもので、例えば以下のクエリは word_count が同じものを一つのグループにして、その中で word の長さが長い順に rank をつけるというクエリである。SELECT  word,  word_count,  RANK() OVER (PARTITION BY word_count ORDER BY LENGTH(word) DESC) AS rank_word_count_lengthFROM  `bigquery-public-data.samples.shakespeare`ORDER BY  word DESC行wordword_countrank_word_count_length1zwaggered184482zounds1466673zone180132............最も重要なのは OVER 句で、ここで行のグループがどの単位なるのかを指定している。今回は PARTITION BY word_count で word_count が同じもの毎にグループを作っている。いわゆる WINDOW というやつですね。この WINDOW はこのように指定することもできるが、以下のように named window を使って書くこともできるが、あまり使ってるのを見たことがないし自分も使わない（可読性がそんなによくないので）。コードブロックのコードシンタックスも効いてない。SELECT  word,  word_count,  RANK() OVER (word_count_window) AS rank_word_count_lengthFROM  `bigquery-public-data.samples.shakespeare`WINDOW  word_count_window AS (PARTITION BY word_count ORDER BY LENGTH(word) DESC)ORDER BY  word DESCもう一つポイントになるのは結果を返すのはグループにした各行それぞれということ。今回の例でいうと、例えば word_count が同じものが 100 行あったとしたら、各 100 行に対して結果を返している。ランクをつけるってそういうことなんだから当たり前だろ、というのはごもっともだが、これが分析関数と呼ばれるものだとちゃんと意識しておくのは役に立つ。例えば、各 word 毎に、その word の長さを全ての単語の中で最も長い単語で割った時の割合も一緒に結果に出すようなクエリを書きたいとしよう。これを集計関数・分析関数の区別なくとりあえずこんな感じか！？と書いてエラーに遭遇するという経験をした人がいるかもしれない。-- これはエラーになる: SELECT list expression references column word which is neither grouped nor aggregated at xxxSELECT  word,  word_count,  LENGTH(word) / MAX(LENGTH(word)) AS ratio_word_lengthFROM  `bigquery-public-data.samples.shakespeare`ORDER BY  ratio_word_length DESC, wordこの MAX は集計関数で、入力行と出力行が N:1 になるものなので、各行に結果を返すわけではないので word や word_cout が返す行数がマッチしてないのでエラーになる。SELECT list expression references column word which is neither grouped nor aggregated at xxx というエラーで、集計されてないので集計して行数がマッチするようにしなさいというものである。このエラーだけ見て集計するようなクエリを書かないといけないか〜と考えるのではなく、これは集計関数の N : 1 の関係なので問題が起こるのであって、N : N の分析関数に変換できればいいんだなと考えれば、余分なクエリを書かずに対処ができる。多くの集計関数は OVER 句を付与することで分析関数になるということを押さえておくと、以下のように書くことで目的が達成できる。SELECT  word,  word_count,  LENGTH(word) / MAX(LENGTH(word)) OVER () AS ratio_word_lengthFROM  `bigquery-public-data.samples.shakespeare`ORDER BY  ratio_word_length DESC, word行wordword_countratio_word_length1honorificabilitudinitatibus11.02Anthropophaginian10.62962962962962973indistinguishable10.6296296296296297............分析関数は分析クエリを書くときに多用するので、この辺りの振る舞いを押さえておくと、冗長で読みにくいクエリでなくてすっきりしたクエリを書けることが多い。ちなみに WINDOW の柔軟な指定方法に関してはここでは触れなかったが、自分はあの文法は全然覚えられないので、必要が生じたらリファレンスを読みながら書くようにしている。tips5: サブクエリ一口にサブクエリと言っても色々あるが、ここではテーブルサブクエリと式サブクエリについて書く。テーブルサブクエリはテーブルを指定する位置で () で括ったクエリを書くことで利用できる。これを使って先ほどと同じケースを書いてみると以下のようになる（分析関数を知っているとこれは全然よい書き方ではないと分かる）。SELECT  word,  word_count,  LENGTH(word) / max_length_word AS ratio_word_lengthFROM  `bigquery-public-data.samples.shakespeare`,  (SELECT MAX(LENGTH(word)) AS max_length_word FROM `bigquery-public-data.samples.shakespeare`)ORDER BY  ratio_word_length DESC, wordテーブルサブクエリは基本的には WITH 句で書く方が可読性が高いので WITH 句を使うのがいいが、例えば今回の例を WITH 句を使うと以下のように冗長な感じにもなるので、ちょっとしたクエリを書いて JOIN したりするときはテーブルサブクエリを使ったりすることがある（繰り返しだが、今回の例だと分析関数を使っておくのが最も良い選択肢とは思うということは前提として）。WITH  table_max_length_word AS (  SELECT    MAX(LENGTH(word)) AS max_length_word  FROM    `bigquery-public-data.samples.shakespeare`)SELECT  word,  word_count,  LENGTH(word) / max_length_word AS ratio_word_lengthFROM  `bigquery-public-data.samples.shakespeare`,  table_max_length_wordORDER BY  ratio_word_length DESC, word式サブクエリは式が使えるところで利用できるクエリで、こちらはいくつかの典型的なものがある。例えばスカラーサブクエリは式を指定する位置で () で括ったクエリを書くことで利用でき、例によってこれまでと同じものを表現すると以下のようになる。SELECT  word,  word_count,  LENGTH(word) / (SELECT MAX(LENGTH(word)) FROM `bigquery-public-data.samples.shakespeare`) AS ratio_word_lengthFROM  `bigquery-public-data.samples.shakespeare`ORDER BY  ratio_word_length DESC, wordスカラーサブクエリは単一行の結果を返さないとエラーになることは注意が必要で、特に相関スカラーサブクエリを書く時に条件を適切に設定しないといけない。例えば以下のようにクエリ（こんな書き方をする意味などないクエリだが、例として）を書くとエラーになり、これは word がユニークではないので WHERE 句の条件で単一行に絞れてないのでエラーとなる。これを適切に動かすようにするには、WHERE 句の条件で単一行になるように、例えば元のテーブルを DISTINCT word などして word がユニークになるようにする、などとする必要がある。-- これはエラーになる: Scalar subquery produced more than one elementSELECT  word,  word_count,  (SELECT LENGTH(word) FROM `bigquery-public-data.samples.shakespeare` WHERE t.word = word)FROM  `bigquery-public-data.samples.shakespeare` AS tスカラーサブクエリは他のテーブルの集計結果を持ってきて使用するとかには便利なのでちょっとした分析では使ったりするが、やりすぎると読みづらいので用法用量をお守りくださいという感じ。自分用の分析ではちょくちょく使うが、他人に共有するクエリの場合はあまり使わないように心がけている、くらいの温度感で使っている。式サブクエリの他のパターンとしては Array サブクエリがあり、名前の通り以下のような感じで Array を作るサブクエリを指す。SELECT  ARRAY(SELECT word FROM `bigquery-public-data.samples.shakespeare` LIMIT 5) AS array_test行array_test1LVIIaugursdimm'dplaguestreasonこれは返しているのは 1 行で、その 1 行が ARRAY 型で 5 個の要素を持っていることに注意。ARRAY は STRUCT と一緒に使われることも多いし、リテラルで書くときは SELECT [1,2,3] とか SELECT (1,2,3) のように同じような形で書いたりするので混同しがちだが、STRUCT() の方は以下のようにスカラー関数として機能しており、返してるのは 5 行である。SELECT  STRUCT(word, word_count) AS struct_testFROM  `bigquery-public-data.samples.shakespeare`LIMIT  5行struct_test.wordstruct_test.word_count1LVII12augurs13dimm'd14plagues15treason1つまり以下のように ARRAY<STRUCT> 型を作ると、ARRAY 型として 1 行を返していて、その中の要素として 5 個の STRUCT が入ってるんだなと分かる。SELECT  ARRAY(SELECT STRUCT(word, word_count) FROM `bigquery-public-data.samples.shakespeare` LIMIT 5) AS array_struct_test行array_struct_test.wordarray_struct_test.word_count1LVII1augurs1dimm'd1plagues1treason1かなり基本的な話だが、こういう簡単なところで違いをちゃんと認識しておくと ARRAY と STRUCT を区別できて変なクエリを書いてエラーになることが少なくなる。続いて IN サブクエリで、以下のように WHERE 句で条件指定するときにサブクエリを使うところで出番が多い。SELECT  *FROM  `bigquery-public-data.samples.shakespeare`WHERE  word IN (SELECT DISTINCT title FROM `bigquery-public-data.samples.wikipedia`)ORDER BY  LENGTH(word) DESC行wordword_countcorpuscorpus_date1Northamptonshire1kingjohn15962Gloucestershire3kingrichardii15953Gloucestershire21kinghenryiv1597................これもちょっとした条件をささっと書くのに便利だったりする。IN の指定は IN (1,2,3) のように直接要素を入れることができたり、IN UNNEST([1,2,3]) のように ARRAY を UNNEST したもので書くことができたり、色んなバリエーションがある。あまり考えずに使っている分にはまあ便利な書き方かなという感じだが、真面目にここでの () はどういう意味なのか理解しようとしたり文法的に意味のあるものとして解釈しようとしてもうまくいかないので、こういうパターンもあるのね、というくらいに思っておくのが精神衛生上いいとは思う。tips6: 型変換型変換について簡単に書く。公式リファレンスは https://cloud.google.com/bigquery/docs/reference/standard-sql/conversion_rules である。明示的な変換である cast と暗黙的な変換である coerce (強制型変換) がある。前者は特に意識することもなく型変換を明示的にしたい場合に使えばいいが、後者はお手軽にクエリを書くときに（場合によっては知らず知らずのうちに）よくお世話になるもので、特に WHERE date_column = "2021-01-01" みたいな形で使うことが多い。以下のように、STRING を特別な形式で書くと様々な時間に関する型へと強制型変換してくれる。SELECT  TIME(00, 00, 00) = "00:00:00" AS test_time,  TIMESTAMP("2021-01-01 00:00:00") = "2021-01-01" AS test_timestamp,  DATE("2021-01-01") = "2021-01-01" AS test_date,  DATETIME("2021-01-01T00:00:0") = "2021-01-01" AS test_datetime行test_timetest_timestamptest_datetest_datetime1truetruetruetrueこれはめちゃくちゃよく使うのでちゃんと意識しておくのがよい。型変換に関しては supertype も頭に入れておくのがよい。UNION ALL するときとか CASE 式を使うときに型が異なっていても supertype が同じなら処理できる。例えば以下は INT64 の supertype として FLOAT64 があるため、INT64 のデータが FLOAT64 に強制型変換されて FLOAT64 として扱われるようになる。SELECT 1 AS test_supertype UNION ALL SELECT 2.0行test_supertype11.022.020211121 現在、TIME、TIMESTAMP、DATE、DATETIME はそれ自身のみが supertype だと公式リファレンスには書いてあるが、実は DATE の supertype として DATETIME があることが以下のクエリが実行可能で結果が DATETIME になることから分かる。SELECT DATE("2021-01-01") AS test_supertype UNION ALL SELECT DATETIME("2021-01-01T00:00:0")行test_supertype12021-01-01T00:00:0022021-01-01T00:00:00BigQuery は型をよしなに型変換して扱ってくれるので便利な一方、型変換の基本的な振る舞いとか supertype がある程度頭に入ってないと気付かぬ間に期待と異なる型を取り扱っていたり、以前似たようなクエリ書いたときはエラーにならなかったのに今回はエラーになって困ったり、などが発生し得る。今回取り上げたことだけでも頭に入っていれば分析用のクエリを書く時ににそこそこ役に立つのではないかなと思う。まとめBigQuery で分析する際の part2 としてスカラー関数・集計関数・分析関数、サブクエリ、型変換について書いた。自分のブログはコードブロックの表示が綺麗ではないのでそろそろ改善したい気持ちになってきた…

BigQuery を使って分析する際の tips (part2)

TL;DRBigQuery で分析する際の tips をまとめてみる。長くなりそうなのでいくつかに分割して書くpart1 はエディタとして何を使うかとか実行結果の連携などについて書くBigQuery console/DataGrip を使いつつ、結果を GitHub issues/Google Sheets/Bdash Server で共有するという感じで使っている仕事で BigQuery を使って分析することが多いので、いくつかの回に分けて BigQuery を使って分析する際の tips をまとめていくことにする。今回は part1 としてエディタとして何を使うかとか実行結果の連携などについて書く。個人的な探索的・アドホック分析用途の話に限定して、組織的にどういうデータ分析基盤を使うかとかそういう話はしない（会社だと ETL の L として dbt https://www.getdbt.com/ を使っていて、これについても色々と書きたいことはあるけどそれはまた別の機会に）。tips1: クエリを書くためのエディタ基本的には BigQuery console https://console.cloud.google.com/bigquery を使ってきたし、今でも使っている。しかしながら、これは BigQuery console を使っている人全員が感じていることだと思うが、イマイチと言わざるを得ない。ブラウザで提供してるので補完が遅いのはやむなしと思う（この遅さによって書いてる時にちょくちょくスムースにいかなくてストレスが溜まることもあるが）けど、フォーマッターはとりあえずこれで納得するかというレベルにならない（CASE 式を見るたびに足が震えてしまう）し、ちょっと前に新 UI が出た時も「これは本当に開発者が触って使い心地チェックしてるのだろうか？」という感じだった（同僚の中には使いづらいのでエディタタブを無効にしているという人もいる）。BigQuery は間違いなく素晴らしいプロダクトではあるが、その「プロダクト」には UI の観点があまり含まれていないようで、こういうところは残念である。もちろんいいところもたくさんあって、ブラウザがあれば使えるというお手軽さは最高だし、実行前の検査でクエリスキャン量を表示したりや文法エラーに留まらずより広範囲のエラーを教えてくれたり（例えば異なる region にある dataset のテーブルを join は不可能だが、それをクエリ実行前に教えてくれる）、Google Sheets や GCS への export などがシームレスに実行できる点、など重宝している。個人的にはフォーマッターがマシになってくれてかつそのフォーマッターが公開されてくれれば、BigQuery console 一本でやっていくという選択肢を取ってもいいかなと思っているが、待ち続けてもそういう日がやって来る気配はない。そんなこんなで JetBrains 社の DataGrip https://www.jetbrains.com/datagrip/ も併用している。これはデータベース IDE で JetBrains 社の製品！という感じの rich な機能を提供してくれる。書き味はざっくりこんな感じ。FROM 句書く時に謎の空白行を入れてるけど、これはテーブル名の変換候補の表示で会社で使っている project/dataset/table が見えないようにするためです。JetBranins 社製品だけあって、補完の滑らかさはかなり心地良い。その他にも文を複数書いてもよしなに各文を解釈してくれるので CMD + Enter とカーソル選択のみで特定の文を選択的に実行できるとか、F1 で Quick Documentation してテーブルの概要を把握できるとか、Export Data でクエリ結果を markdown table にして Copy to Clickboard して GitHub issues に貼れるとか、便利な機能が多い。フォーマッター Editor > Code Style > SQL > General で実際にどのようにフォーマットされるのかの例が以下のように視覚的に分かりやすい形で柔軟に色々と設定することができる（フォーマッターとかあれこれ細かく設定したくないのでこれ使っとけばだいたいオッケーというものをチームで使うようにしたいのだが…）。DataGrip は色々なデータソースに対応していて、BigQuery 対応は比較的最近（2020.2）始まったので、まだまだ不完全な部分もある。やはり Array型 とか STRUCT型 周りが弱い感じがする。補完が弱いのはまあそんなに気にならないが、手元で色々分析する時に例えば id だけ入れ替えれば使いまわせるような scripting statements https://cloud.google.com/bigquery/docs/reference/standard-sql/scripting を使ったりするので、これがサポートされてないのはちょっと不便だ。それと JetBrains 社製品ということでそこそこの金額がするのも気になるところ。会社で働いていてがっつり使うという場合は問題ないが、そんなに頻度高くなく必要になったらちょっと使いたいくらいの場合はなかなか購入まで踏み切りづらいかもしれない。local でのクエリの保存とちょっとしたグラフを見るという用途で Bdash https://github.com/bdash-app/bdash も使っている。local での保存という意味では別に Bdash を使わなくてもいいのだが、後述するように Bdash Server https://github.com/bdash-app/bdash-server で他の人にクエリを共有するというのにも便利なので Bdash を使っている。作者が社内にいるのでなんかサポートされてない機能があったら feature request を出せるのも便利（contribute しろよという意見は一旦無視する）。tips2: Colaboratory での利用クエリだけでなく、Python で例えば pandas.DataFrame に結果を読み込んで interactive に色々分析したいということもある。ちょっとした分析が目的のときには local に環境準備をするのは面倒だし、他の人に再現可能な形で共有するのにも適してない。そういうときにはやはり Colaboratory https://colab.research.google.com/notebooks/welcome.ipynb を使うのは便利である。BigQuery にクエリを投げて結果を利用する方法はいくつかあるが、一番お手軽なのは magic commands を使うことだろう。自分は以下のコードを snippets に登録して使えるようにしている。from google.colab import authauth.authenticate_user()%%bigquery --project [適当な GCP project] dfselect * from ``これで interactive に authentification をして、クエリ実行結果を df という pandas.DataFrame に格納することができる。Colaboratory は URL を共有してコピーして使ってもらえば他の人も（自分と同じような環境構築をしてもらうとかの手間がなく）簡単に利用できる。ちなみに自分がいま分析してる範囲だとそんなに Python を使ってあれこれ分析せずに SQL だけで十分なことも多いので、そんなに使ってはいない。ちょっと話は逸れるが、分析やモデリング周りを一手に担う統合プラットフォームとして Vertex AI https://cloud.google.com/vertex-ai が実際どんな感じかはやや気になっている。ここまで色々揃っていると、このプラットフォームに沿うように自分たちがうまく振る舞わないといけないと思うが、そうしたときにどれくらいのメリットを享受できるのかというのはガッツリ運用している人がいればぜひ聞いてみたいところだ。tips3: 実行結果の連携方法分析結果をどう連携するかについても日々実践していることを書いてみる。一番頻度高く使うのは、クエリの実行結果を作業ログとしての GitHub issues に markdown table として貼るというもの。これは連携というよりは自分の日々の作業ログであったり他の人が作業ログを見た時に自分の思考の流れが追えるようにしてるという側面が強い（ちなみに以前データ分析系タスクの作業ログ共有に Jasper を使っているという話 https://yoheikikuta.github.io/working_log_using_jasper/ も書いたりしている）。markdown table としてコピーする方法は BigQuery なら以下のように tweet した方法を使っていて、DataGrip の場合は Export Data で Copy to Clickboard を使っている（当然後者の方が使いやすい）。BQ console のクエリ結果をコピーして GitHub issues とかにマークダウンとしてペーストできるのは便利だけど、左だとヘッダーがちゃんととれなくて右だと大丈夫（これは Safari で Chrome だと見た目の違いは分からない）tips は左上からではなく右下の値のところから範囲選択することです（真顔） pic.twitter.com/Th3h99C5Qt— Yohei KIKUTA (@yohei_kikuta) November 7, 2021 次によく使うのは Google Sheets に結果を export して連携するというもの。Google Sheets はソフトウェアエンジニア以外でも使える人が多いので、結果を共有したり interactive にちょっと触ってもらうのには適している。BigQuery console だと 結果の保存 > Google スプレッドシート でスッと export できるし、DataGrip ならば Export Data で TSV にして Copy to Clickboard でコピーしてから Google Sheets にペーストしている。ちょっとダルいのは、特に前者の方法だと個人の Google Drive に保存されてそのままでは他の人が使えないので、共有できるよう保存場所を移動するなりしないといけないという点。Google Sheets という意味では Connected Sheets https://cloud.google.com/bigquery/docs/connected-sheets を使うのも便利。単純にクエリの結果を貼って共有するのとは違い、こちらはちょっとしたクエリを書いてその実行結果を Google Sheets 上で扱えるというのが利点で、さらに定期実行を設定できるので新しいデータを参照してもらうことができる。自分はちょっとした分析結果を使ってビジネス的な意思決定のインプットにしてもらう、とかいうときに日時で新しい結果を参照できるような Connected Sheets を共有したりする。もちろんこの Connected Sheets 上で複雑なクエリを書いたり、あれもこれもとやりすぎると管理や運用が大変になってくるので、よく使うし重要というものはちゃんとデータマートを準備したり BI ツールで閲覧できるようにしたりなどと交通整理する必要はある。Data Portal とか BI tool での連携というのはアドホックというよりもう少しかっちり運用という感じになるので、今回は対象外としておく。連携というほどにはまだ会社全体で使い倒してるレベルにはないが、Bdash Server が導入されてるのでクエリと結果を共有（というか他の人も見れたら便利かもなというものを見れるとこに置いておくだけという感じ）するときに使っている。Bdash からワンクリックで以下のように共有できるので、local での自分用のクエリ保存と簡単なグラフ確認を Bdash でして、それを他の人も共有できるように Bdash Server にも送っておくという使い方をしている。まとめBigQuery で分析する際の part1 としてエディタとして何を使うかとか実行結果の連携などについて書いた。

BigQuery を使って分析する際の tips (part1)

TL;DR興味があったので Launchable の @yoshiori さん @draftcode さんとカジュアル面談をしたテストをはじめとしてソフトウェアエンジニアリングの生産性をデータドリブンで改善していくというのはめちゃ面白そう自分は現段階では転職意思がないけど、機械学習エンジニアで興味ある人は言ってくれればおつなぎします！Ubie Discovery に転職して一年半が過ぎた。そんな折に Launchable https://www.launchableinc.com/ で Machine Learning Engineer の position を募集しているというを見て、yoshiroi さんが転職した会社だし面白そうなので話を聞いてみたいなと思って連絡したら、転職の意思があまりないと事前に伝えていたにも関わらず快諾してもらった。現時点では自分が転職するということはないが、興味ある人もいるだろうということでブログに残しておく。（話の内容をブログにしてもよいというのはすでに先方に確認を取っています）経緯書いた通りだが、思い立って連絡したら一時間ほど話をしてもらえることになった。最近入社した @draftcode さんも呼んでもらって三人で話をすることになった。自分としても面白そうだと思っていた分野なので、話の前に HP を見て紹介されていた https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45861.pdf や https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/ やちょっとググって関連知識を調べるくらいはしておいた。Launchable の会社全般的な話会社の目指すところはデータドリブンでソフトウェアエンジニアリングの生産性を上げるというもので、その最初の取り組みとして特にテストに注力しているとのことらしい。ソフトウェアエンジニアリングはどのように不確実性と向き合うかというのを積み上げてきてはいるが、その中には確率的に判断せざるを得ないものもあるし、そうなると適切にデータを集めて統計的に考え行動する必要があると思う。そういったところに真正面から取り組んでいる Launchable の目的には共感する。ビジネスモデルは toB 向けのフリーミアムモデルで、HP の pricing を見るとなかなか面白くて、$7 / hours saved ということで開発が効率的になった分だけお金を支払うというものになっているらしい。マーケットはソフトウェア開発をしている企業全般ということになるのでポテンシャルはとても大きい。とはいえ会社ごとに違いはありますよね？という疑問が思い浮かぶので聞いてみたが、会社ごとにセットアップしてサービスを展開してきて、色々な勘所が分かってきたという段階らしい。カスタマイズを要求されまくって破綻するみたいなことはなさそうな一方で、もっとスケールさせるためにはまだまだアイデアやチャレンジが必要そう、みたいな印象。最近優秀なソフトウェアエンジニアの人が続々入社してる会社なので、一緒に働く同僚から得られる刺激が多そうなのもよさそう。Launchable の機械学習周りの話機械学習周りの話も色々と聞いてみた。ファイルの変更行数などを入力特徴量として、各テストの fail する確率を予測する GBDT を使うというのが基本になっているらしい。テスト実行を積み重ねることによってそこから単なる 成功/失敗 以上の情報を抽出するという試みは興味深い方向性だ。同じ会社でもレポジトリによって触る人が全然違うし、テストは複数レポジトリにまたがることもあるので、モデルを学習する単位としては一連のテストを実行するプロジェクト単位で作っているとのこと。ソフトウェアエンジニアリングに造詣がありつつも軸足は機械学習にある、というタイプの人がマッチしそう。ということで、Launchable は機械学習エンジニア絶賛募集中とのことです！ソフトウェアエンジニアは採用が順調だけど、機械学習エンジニアはなかなか path がないとのことだったので、私からも宣伝しておきます。もちろん一番は Ubie Discovery に興味を持って話を聞かせてくださいというのを期待しますが、Ubie Discovery よりも Launchable の方が興味があるんや！という場合も遠慮なく言ってください。ちなみに拠点は JP と US だけど、開発拠点は日本が中心とのことです。菊田さんぜひ！というありがたいお言葉もいただきましたが、自分の興味関心から考えるとやはり Ubie だなという気持なので、何か状況が変わるタイミングがあったりしたらまた話をさせていただきたい、という感じでカジュアル面談は着地しました。まとめ興味があったので Launchable の話を聞いてみたら面白そうだったのでブログに書いてみた。ちなみにあわよくば話をした二人とも Ubie Discovery に引っ張ってこようとして話の最中にどんどんこちらの話もねじ込んだのですが、さすがに転職するという雰囲気はありませんでした。ベンチャー企業同士仲良くやっていきましょう！

Launchable の人とカジュアル面談した

TL;DR機械学習に基づく施策をサービス改善につなげるためのフレームワークとその実践を提供してくれる本統一的なフレームワークと一貫した記述で、よく書かれている本だなと感心した個人的には 4.2 節の Implicit Feedbak を用いたバイアスを考慮したランキングシステムの構築のところは勉強になったタイトルの通り 施策デザインのための機械学習入門 という本を読んだ。本の正式なタイトルは「施策デザインのための機械学習入門　データ分析技術のビジネス活用における正しい考え方」というもの。本のタイトルからは具体的ににどういう内容が書いてるかは想像しにくいが、内容は機械学習に基づく施策を実際に導入する際に重要となる観点を一連のフレームワークとして提供し、そのフレームワークに基づいた具体的な実践を解説するというものになっている。技術評論社出版で HP は https://gihyo.jp/book/2021/978-4-297-12224-9 にある。https://github.com/ghmagazine/ml_design_book にある。本の概要章立ては以下のようになっている。1 章 機械学習実践のためのフレームワーク    KPI 設定 → データの観測構造をモデル化する → 解くべき問題を特定する → 観測データを用いて解くべき問題を近似する → 機械学習モデルを学習する → 施策を導入する というフレームワークを導入2 章 機械学習実践のための基礎技術    広告配信を例に導入したフレームワークに則って施策導入までの一連の流れを解説3 章 Explicit Feedbackに基づく推薦システムの構築    ユーザの行動に基づくデータの観測構造に注意を払って適切な目的関数を導く一連の流れと実験結果を解説4 章 Implicit Feedbackに基づくランキングシステムの構築    ポジションバイアス、セレクションバイアス、クリックノイズ、に対して適切な目的関数を導く一連の流れと実験結果を解説5 章 因果効果を考慮したランキングシステムの構築    より発展的な内容として推薦枠非経由の conversion も考慮したケースを紹介演習問題    本の内容を自分で実践に活かすための訓練となるような問題大まかな頭出しについてはこれより詳しいものとして著者のブログ https://usaito.hatenablog.com/entry/2021/08/03/191339 があるので、もう少し詳しく知りたい人はこれを読んでから本を買うかどうか決めればよさそう。全体的によく書けていて、入門書を謳って基本的なところから始まりつつも内容が割としっかりしていて、自分にとっても勉強になるところが多い本だった。推薦システムは 5 年くらい前に仕事でやって以来そんなに追ってなくてほとんど覚えてないこともあり、特に 4.2 節の Implicit Feedbak を用いたバイアスを考慮したランキングシステムの構築のところとかは勉強になった。数学的な定式化がしっかり目になされているので読みやすい。特によく書けているなと感じたところこのエントリではそれぞれの章でどういうことを書いてあるかを紹介したりはせず、自分が特によく書けているなと感じたところを書く。全編を通して一貫したフレームワークに基づく記述1 章で導入する機械学習実践のためのフレームワークに基づいた一貫した記述がなされている点がよい。本を書こうとすると、どうしても色々な知識を紹介しようとしてあれこれと詰め込み、結果として知識の羅列を薄く繋いだものになりがちだと思う。この本はそうではなくて、様々な具体的ケースに対応できる適度なレベルに抽象化したフレームワークを構築し、それで一本筋が通っている状態で個々の具体例を解説している。具体例で経験を積み、このフレームワークに立ち戻って理解を増強することで、より困難な他の具体例に立ち向かうことができるようになるという設計になっている。こういう思想は巻末の演習問題にも顕著に現れている。この統一的な記述は著者のこだわりというか信念が感じられてとてもよい。データの観測構造のモデル化と unbiased な目的関数の導出手順フレームワークの中でも特によいと感じたのがデータの観測構造のモデル化と 解くべき問題を近似するときの unbiased な目的関数を導出するところである。データの観測構造のモデル化のところは解析可能な数学的表現で対象の状況をモデル化するという意味合いが強い。この部分がしっかり目に書かれているのがよいところで、ここがきちんとモデル化できないと解くべき問題を数学的に表現できず、バイアスなどの落とし穴に気づくこともできない。（数学的表現に慣れてない人がこの本で機械学習に入門するぞ、という場合には少し難しいかもしれない）。データの観測構造をモデル化できるからこそ、解くべき問題を近似して適切な目的関数を設定するという後のプロセスも適切に実施できる。この本ではまずは観測データのみに注目してデータの観測構造を意識していないナイーブ推定量を算出し、それだとデータの観測構造に基づくバイアスが乗っているのでそれを是正するように Inverse Propensity Score 推定量（バイアスを打ち消すような重みを逆数として掛ける）を使いましょうという流れになっている。これを何度も繰り返すので、どうやって適切に解くべき問題を近似するのかというのが意識しやすくなっている。手計算できる簡単な例で感覚を掴む問題の本質を損なわないようにしつつ手計算で確認できる例が豊富にあるのもよい。ある種のアイデアがあるときに、それを正しく把握するためには（本質を損なわない）簡単な例でチェックするというのは重要で、そこを意識して簡単化した例がいくつも載せられている。簡単な例で振る舞いを理解する、次元解析をする、極端なケースで振る舞いを確認する、まずは生データを眺める（EDA する）、などは感覚を掴むために重要なので、実データで取り組む前に簡単だが重要な例があるのはよいと思った。余談だが、こういう話を書くと「いかにして問題をとくか」が思い出されるわけだが、これの機械学習/データ分析特化版みたいなのがあっても面白いかもしれない（断片的には色々なところで語られていると思うけど）。実験用データを問題設定に合わせて適宜いじっているオープンデータを使って実験する際に、本の内容を解説するために適宜手を加えてデータセット（本では半人工データと呼んでいる）を準備しているのも工夫が感じられた。機械学習の本を読んでると、それでは具体例と言ってこのデータにこのモデルを適用したら結果はこう！みたいな感じでそこから何かを得るということがあまりないことも多いが、本の内容を適切にサポートするような実験設定にしてあるところは素敵だなと思った。その他記述が丁寧すぎる部分がある。入門書ということなので丁寧にしたのだと思うけど、unbiased な目的変数の期待値が望み通りになっているかの計算がほぼ自明なのに繰り返し記述されてるのとかは、本書を通読できる人なら必要ないと感じた。もう少し記述をスキップした上で、章末の発展的内容を一部解説してみたり 5 章の内容で著者が考えてることをもっと深く記述してもらうとかだと個人的には嬉しかった。notation がちょっと confusing な部分がある。4.2 節の Pair Result Randomization のところで確率的ランキングを導入するが、ユーザ $j$ に提示するランキング $y_j$ にさらに $k \leftrightarrow k+1$ を swap するランキングと元のランキングという新しい次元の情報が出てくる。それらを断りなく $y_1, y_2$ と書いたりするのでユーザの添字と confusing なところがある。まあこれはさらに新しい notation を導入したりすると複雑になりすぎるし分かるやろってことでそう書いてるのだと感じたけど、ちょっと読み淀んだ。あと $y^{-1}$ でアイテムを指すのはあまりしっくりこなかったけど、推薦システム関連だとよく使われる notation なのかな。この本に限らずだけど、typo とか見つけたらフィードバックしたいけど、どこで受け付けてるか書いてくれると嬉しい。正誤表 https://gihyo.jp/assets/files/book/2021/978-4-297-12224-9/download/%E6%AD%A3%E8%AA%A4%E8%A1%A82021-08-18.pdf にないところだと図 4.5 の $R(u,i_9) = 0$ でなく $R(u,i_9) = 1$ というのがあった（本文を読めば分かるので単なる typo）。GitHub repository はコードだけって感じだったので書いていいか判断つかず、技術評論社のお問い合わせページ https://gihyo.jp/site/inquiry/book?ISBN=978-4-297-12224-9 に送っておいた。ただこちらは他の人が何送ってるかが見えないので被ったりしそう。GitHub repository あるなら issues にそういうフィードバックどうぞと案内するとよさそうか。まとめ施策デザインのための機械学習入門 を読んだ。よい本だったので書評ブログを書いたが、改めてブログとして書いてみると、著者が多大な努力を払って本を完成させたことが伺え、ありがとうございますという気持ち。

施策デザインのための機械学習入門 を読んだ

TL;DRUbie 株式会社に入社して一年くらい経ったので振り返りをする改めてデータ分析/機械学習で何がしたいのかを考えているが、自分はデータから普遍的な知識を得たい人間で、その観点では（まだまだ先は長いけど）やりたいことができている人によって目的は色々だと思ういますが、みなさんはどうですか？Ubie 株式会社に入社して 1 年以上経過したので軽く振り返りをしつつ、そもそも自分はデータ分析/機械学習で何がしたいんだっけというのを改めて言語化してみるエントリ。ここしばらくは採用の文脈以外で他の会社の人と話すことが少なくて物足りないところもあるので、自分はこうだな〜という意見があればぜひ教えてください。一年間を振り返ってみるまず何よりも、勤続一年一ヶ月を達成している自分を褒めたい。凄いぞ自分。偉いぞ自分。勤続一年一ヶ月という圧倒的事実が示唆しているように、（労働の辛さはもちろんあるのだが）楽しく働けている。これは主観的にもそうだし、他の人から言われることもあるので客観的にもそうだと言えるだろう。入社を決めた時のブログエントリ https://yoheikikuta.github.io/joinning_ubie/ を今一度読んでみると、「ストーリーを語りたくなるような仕事ができそう」ということで入社を決めている。どうですか、ストーリー、語れそうですか？（自分への問いかけ）これに関しては力強く YES という回答なのだが、まだまだ「俺たちの戦いはこれからだ！」という状況なので、先を見据えつつも今やるべきことを着実に進めている。入社してしばらくは地道なバグの調査・修正とかデータの確認とかでしんどいタスクも結構あったのだが、そういうところをある程度乗り越え、今は有用なデータを蓄積することにフォーカスしつつ同時にそれを活用するというフェーズになっている。有用なデータを蓄積することは楽しい。簡単化した例として P(頭痛|髄膜炎) という条件付き確率を求めることを考えてみる。これは髄膜炎という病気に罹っているときに頭痛という症状を発症する確率を算出することを意味している。医学的な知識がない人にはこの一つの例であっても想像も難しいレベルだろう。医師であれば髄膜炎において頭痛は典型的な症状であって高い確率で発現することを知っているが、定量的に表現するということは簡単ではない（一人の医師が見聞きできる症例は限られているし、膨大にある症状と疾患の組み合わせを定量的に表現することは困難である）。十分な量のデータがあれば、髄膜炎に罹っている患者全体のデータから頭痛症状有りの患者の割合を求めることでこの条件付き確率を求めることができる。シンプルだが、シンプルであるが故に、データを集めるだけで医師の専門知識を誰にでも利用できる普遍的な知識へと昇華することができる。実際には、そもそものデータの真正性とか、年齢や性別による差異とか、既往歴や他の症状との関係性とか、気にすべき観点やより現実に即した発展は山のようにある。まだまだ先は長いが、こういったところを自分たちでデザインして進めていくのは実に楽しい。入社してから気付いた良さとして、一緒に働く機会がなかなかない業種である医師と同じチームで働けるという点が挙げられる。自分がほとんど触れてこなかった知識体系について造詣が深い専門家と一緒に働くと新鮮な驚きがあって楽しい。体調が悪い時に専門家に相談できるというのも優れた福利厚生と言える。福利厚生と言ってるが、社内医師が善意で相談に乗ってくれているという話で、これは仕事とは直接関係ないプログラミングの問題についてプログラマが答えてくれるようなもの。自分は胃痛でピロリ菌感染疑いだったとき、とりあえず自分で近場のクリニックに行ったら治療方針がよく分からずイマイチだったが、社内医師に相談しつつクリニックを変えたらあっさりと治療ができた。医師の専門性などを把握して適切な医療機関にかかるというのは簡単ではないなと実感したので、テクノロジーで人々を適切な医療に案内する、やっていきたいね。その他にも組織全体に関する業務や採用なども頑張っているが、これは同僚がたくさん情報発信してるので割愛。いいことばかりを書いたが、満足してないこともある。自分はデータ分析や機械学習の技術的に進んだ領域にも興味があるが、そういうところはこれまで殆どできていない。仕事とは別で摂取するしかないなと思って hikifune.fm を始めて補完していた。ただ、データが集まり人も集まり、この点に関しても色々なことに挑戦できそうな土台ができてきたので、今後は業務でもやっていけそう！自分はデータ分析/機械学習で何を成し遂げたいのかやってきた仕事を振り返りつつ、改めてデータ分析/機械学習を通じて何がしたいのかと考えてみると、自分はデータから普遍的な知識を抽出したいという嗜好性が高い。働き始めのころは今よりも数理的なモデリングへの興味が強く、現実のデータでモデルを作ってそこから意味のある情報を得ることに注力していた。仕事としてそれを実現するために、モデリング業務を中心に担当してサービスを改善・開発し、一部の内容は論文化したりと頑張っていた。こういう仕事はやっているとき楽しいと思っていたし、仕事始めのほぼ何も知らなかったところから考えると、相当に色々なことを学ぶこともできた。しかしながら、この手の仕事を続けていくうちに、自分は本当に何か普遍的な知識を得たのだろうか？という疑問を抱くようになってきた。発展的なモデルを駆使することでインパクトの大きな成果を出したり新しいサービスが作れたりする可能性は広がるけど、自分の人生の第一義的な目的はそういうものではないと知った。やはり入力となるデータに普遍的な知識を抽出できるポテンシャルがある領域が望ましい。そういった知識を積み上げることで、人類の知的財産に少しでも貢献できたな！という自己満足が得たいのである。一方で、可能なら労働なんてしたくないので金銭的にも十分なリターン（うまくいけば 5~10 年後には賃金のための労働をしなくてもいい）も欲しい。自分はビジネスで大成功するような才覚はないし、ライフプラン的にも給与所得だけでは難しさもあるので、期待値でいえば成長可能性が高い会社で Stock Option をもらうのが一番よさそう。こういった諸々の条件を満足し得る会社がどれくらいあるのか知らないが、自分が知る限り最も良い会社が Ubie 株式会社だった（偉そうに言ってるが @masa_kazama に声をかけてもらったおかげで知った。感謝）。前述の通り医療データには自分が望むポテンシャルが大いにあるし、会社として大きく成長する可能性も秘めている。当然どちらもうまくいくかの不確実性はまだまだ高いわけだけど、自分たちの力でそれを現実のものにしていこうと一丸となってやっていけるのは楽しい。もっと頑張っていきたいですね！たまにはこうやって「自分はそもそも何がやりたいんだっけ」を振り返ってみるのも一興ですね。ということで、みなさんはどうですか？ここまで自分の話をしてきたが、これは徹頭徹尾自分の好みであって、何が偉いとかどれが正しいとかこうあるべきとかいうものでは決してない。何を人生の目的関数とするかは人それぞれなので。ただし、目的関数に応じて適切な場所で働いた方がよいし、目的関数は時間と共に変わり得るものなのでその変化は認めて追従していった方がよい。例えば、機械学習を用いることで初めて実現可能となるようなサービスを作りたいと思っている人がいるとする。その人が日々の仕事ではまず機械学習を使わなくても済む方法を考えているとか、機械学習と関係のないコーディングがメインになっているとかいう状況であれば、目的とマッチしていないので環境を変えた方がいいだろう。データ分析や機械学習を活かしてサービスを改善したりビジネス的に大きな成果を出したいという人は、データの規模とかそれを効果的に使えるようなビジネスをしている会社に所属した方がいいだろう。このタイプの人は、入りはデータ分析や機械学習であってもやっていくうちに手法にはそんなに拘りがなくなって何でもやる人になるという印象がある。大学や研究所だけでなく企業でも研究職がそこそこあるので、研究を生業としてやっていきたいという人は他分野よりはやりやすそうだ。ただ、機械学習分野は参加人数が多くてカンファレンスに論文を通すために考慮しなければならない点も多いので、職業研究者がどうやって自分が本当にやりたい研究に取り組めるよう工夫をしているかは聞いてみたいところ。Kaggle のようなコンペ形式のデータ分析/機械学習が楽しいからそれに打ち込む、というのは目的が明瞭だし継続性もあってよさそう。多くの人が参加してその副次的な価値（コンペで得られた知見は直接関係のない仕事にも有用）を示してきた結果、仕事としても取り組めるような環境も出てきたのはいい話だな〜と思う。色々な目的関数があると思うので、どういう目的関数でそれを実現するためにいまどこで何をしてるか、というのはぜひ聞いてみたいですね。一年以上にも渡り他の会社の人と話す機会がなかなかなくて寂しいので、自分はこうだというのがある人は教えて欲しい〜。自分と似た考えの人で、Ubie 株式会社に興味がある人はお気軽にお声がけください。自分と似た考えじゃなくてもオッケーです。つまり興味があれば誰でも！！！まとめ仕事を振り返りつつ自分がデータ分析/機械学習で何を成し遂げたいのかを言語化してみた。自分はデータから普遍的な知識を得たいと思って今の会社で働いているけど、みなさんはどうですか？

自分がデータ分析/機械学習で成し遂げたいこと

TL;DR15 回ほど配信をしたのでここらで hikifune.fm の振り返りをしてみる配信ドリブンで色々勉強したのでそこそこためになったし、シリーズ物はやってみて結構よかった二人で収録するメリットはあまり感じられなかったので今後どうするかは考え中hikifune.fm https://anchor.fm/yoheikikuta という podcast を始めて半年以上経ったので備忘録のために振り返りをしておく。反省会会場、と言いながらブログなので自分一人が振り返って書くだけなのだが、これはお察しの通りこのスレタイが好きだからつけただけである。hikifune.fm とは何だったのか？何だったのか？とか言うともう終わったものという感じもするが、まだ終わってはいない。コンセプトとか運用に関しては https://yoheikikuta.github.io/podcast_hikifunefm/ で書いた。機械学習に関連する事柄を配信することで自分たちの勉強に役立てようというものである（会社の仕事は諸般の事情により対外的に話しづらいということもあるので、勝手に勉強して勝手に話す場として準備している）。配信をしているので誰でも聞けるものではあるけど、聞き手にとってためになるとかではなくあくまで自分たちの役に立つという目的がメインで、一定間隔で配信をすることで配信ドリブンでインプットの意識を高めようという感じ。15 回配信をしてみての stats20210504 の時点で、総再生回数が 3,572 回で各エピソードの再生回数一覧は以下（正確には第 0 回もあったので 16 エピソードなのだが、第 0 回は単に始めます宣言なので一覧からは除いている）。一番再生されているのは Vision Transformer の論文解説で、一番再生されてないのは Prompt Tuning の論文解説（再生回数は時間に関して単調増加なので、最近の回が一番再生回数が少ないのはそれはそう）。内容的にある程度機械学習への理解がないと聞いても全く面白くないと思う Podcast なので、始める前は平均 100 回でも再生されれば結構凄いんじゃないかと考えていたので、思ったより再生回数は多いなと感じている。正直なところこの手の技術系 Podcast でどれくらい再生されるものなのか全く知見がないし調べてもいないので相場が分かってないが、hikifune.fm の場合はこんなもんだったということで。何か感想とか物申したいときのために Twitter hashtag #hikifunefm を準備したが、これは発表側以外では @karino2012 氏が感想を書いてくれたのみで他は殆どなかった。まあ自分も人の Podcast 聞いて感想を Twitter に書いたりしないので、そんなもんなんでしょうね。有名どころの Podcast だと感想を書いてる人もそこそこいる印象だけど、こっちはなんてたって曳舟だからね。ネームバリューがないよ（自分はもちろん曳舟好きだけどね）。show notes を GitHub repository https://github.com/yoheikikuta/hikifune.fm で管理していて誰でも issue に要望とか書けるようにしたけど、これは数としてはゼロ。Twitter hashtag 使われないくらいなんだから、そりゃ issue に何か書く人はいないでしょうな。この repository は issue を使うというよりは show notes をお手軽に管理したいという理由だったので、その目的は達した。良かった取り組み概ね隔週で配信してたけど、間隔としてはこれくらいがちょうどよかった感じがする。自分は発表者と聞き手を交互にやっていく役なので発表するのは 4 週に 1 回とかになる（実際はもうちょいハイペースだったが）ので、準備が怠くなってグダグダになりすぎるということはなかった。シリーズ物として DALL•E の理解に向けて というのをやったのは結構よかった。自分はあまりこういう方向性でやっていきたいというモチベーションがないので、単発で何かを話すだけだとあれこれ話題が飛ぶのであまり蓄積がなくて表面だけなぞって終わりがちだけど、3 回関連する話をすると自分の中でも理解が結構深まる。きっちりシリーズ物にしなくても、連続した数回はこういう系統の話でまとめる、とかやるとある程度はまとまった知識が得られるのでいいかもと思うなどする。show notes を割とちゃんと残した点もよかった。収録した音声はバグってないかは調べるけど最近はちゃんと聞き直したりはほぼしないので、この回はどんな話をしたっけというのを振り返りたい時に便利だったりした。そして収録前に repository に PR として送っておいて聞き手も見れるようにしておいたので、それを眺めながら聞くのはやりやすい（音声だけだとさっき何て言ってたっけ？とか忘れがちだけどテキストで書いてあるとすぐ確認できるので。Podcast 配信してるくせに身も蓋もない話だが、ちょっと込み入った話を音声だけで理解するというのは難しい）。イマイチだった取り組み二人で収録して聞き手を準備する、というのはそんなに効果がなかったなと思う。こういうのは大体準備ができるのが前日夜か当日収録前なので、聞き手は事前準備なく聞くことがほとんどで、質問がどうしても表面的で浅いものが多かった。まったく準備せずに聞き手として参加して素朴に質問することでリスナー目線で質問ができるかなという試みをしたりもしたが、そもそも自分たちの勉強のためにやってるものなのでやっぱりもうちょっと深い話に立ち入りたいよなというのが個人的な感想（それはそもそも Podcast で配信するような類のものではないのでは？という尤もらしい疑問は置いておいて）。その他にも細々した点はあるっちゃあるが、まあでも概ね良かったのではないか。ポジティブシンキングである。今後の方向性これを決めあぐねている。自分がやりたいと言って始めたもので他メンバーにちょっと負担を強いていた面もあったので、やっぱり発表者が自分以外には集まりづらい。他の人とワイワイやっていくスタイルにしたいなと最初は思ってたけど、自分一人でやっていくスタイルにするか。この場合は「あれ？なんで Podcast で配信してるんだっけ？ブログとか paper-reading とかでいいのでは？」となりそうな気配はする。発表内容を予め通達して、その内容に関して自分と同等以上に詳しい人を聞き手として招いて、自分の話に色々突っ込んだり補足を入れてもらうというのは自分の勉強にはよさそうだ。この場合は聞き手を探すのが大変という未来が容易に想像できるが。もともと自分たちの勉強になるというモチベーションで始めてある程度は役に立ったけど、そういうのはやっぱり少人数の勉強会で議論するのが一番いいんだよな（なかなか気軽にそれができる情勢になってはくれないのだが）。目的を変えて自分が興味ある話を紹介して自己満足する場にするか、ある程度やって満足したからもういいかとスパッと止めるか。どうするかまだ決めてないけど、ちょっと考えてみて近いうちに決めることにしよう。まとめhikifune.fm の反省会をした。今後どうしていくかはまだ未定。

yoheikikuta

Ubie Discovery における組織開発をソフトウェア開発的に理解する

2021年に読んだ本を感想と共に振り返る

2021年のまとめ

BigQuery を使って分析する際の tips (part3)

BigQuery を使って分析する際の tips (part2)

BigQuery を使って分析する際の tips (part1)

Launchable の人とカジュアル面談した

施策デザインのための機械学習入門を読んだ

自分がデータ分析/機械学習で成し遂げたいこと

hikifunefm 反省会会場

Ubie Discovery における組織開発をソフトウェア開発的に理解する

2021年に読んだ本を感想と共に振り返る

2021年のまとめ

BigQuery を使って分析する際の tips (part3)

BigQuery を使って分析する際の tips (part2)

BigQuery を使って分析する際の tips (part1)

Launchable の人とカジュアル面談した

施策デザインのための機械学習入門 を読んだ

自分がデータ分析/機械学習で成し遂げたいこと

hikifunefm 反省会会場

施策デザインのための機械学習入門を読んだ