TL;DRGitHub repo: https://github.com/yoheikikuta/text2img_webapp論文で示されてるフルのモデルと比べると結果がイマイチ過ぎてテンションが上がらない…最近 text2img の発展が著しいので、自分でもモデルを触って遊んでみようとかやっていた。https://github.com/yoheikikuta/text2img_webapp ので、そのあたりの話を書いておくエントリ。text2img とは入力した文章に基づく画像を生成する過程を指す言葉であり、最近 diffusion model を使いつつ巨大なモデルを構築することによって飛躍的にその性能が向上している。この手の話は昔からやられているが、なかなか難易度が高いので人間が描いたものと遜色がないというレベルに結構難しいなと思っていた。それが 2021 年 初頭に DALL·E https://arxiv.org/abs/2102.12092 によって驚くような性能を発揮したことで、ワクワクして論文を読んだり podcast で取り上げたりした。podcast は以下の3回のシリーズものとして出している。Vision Transformer の回 https://anchor.fm/yoheikikuta/episodes/9-DALLE–part-1-Vision-Transformer-eop4lsCLIP の回 https://anchor.fm/yoheikikuta/episodes/11-DALLE–part-2-CLIP-eq2as8DALL·E の回 https://anchor.fm/yoheikikuta/episodes/13-DALLE–part-3-DALLE-errr51この後に画像生成で diffusion model が流行りを見せ、それを text2img に取り入れて更に性能を引き上げた unCLIP (DALL·E2) https://arxiv.org/abs/2204.06125 や Imagen https://arxiv.org/abs/2205.11487 などが出てきて、これはもう人間が描いたものと遜色がないというレベルまで来ている。自分で遊べる pretrained model が欲しいなと思っていたら、GLIDE https://arxiv.org/abs/2112.10741 という手法の GitHub repository https://github.com/openai/glide-text2im で簡易版ではあるが pretrained model が MIT ライセンスで公開されていたので、それを使って遊んでみようとなった。web アプリを作るアプリとしてはまったく簡素なもので、以下のように 日本語文章 → (Cloud Translation で英訳) → 対応する英語文章を作成 → (text2img モデルで画像生成) → 生成画像を表示 するだけのものであり、https://github.com/yoheikikuta/text2img_webapp にコードを残していてこれがほぼ全ての情報である。構成は frontend を streamlit で実装して Cloud Run で動かし、backend を FastAPI で実装して GPU enabled な GCE で動かしている、という特に何も面白いこともないものである。結果的には特に面白いことはないが、ここに至るまでいくつか試したものがあったりするので備忘録がてらそれをメモしておく。GPU を使うGPU を使わないと（diffusion step の数をかなり減らしても）画像生成が数分掛かるので GPU を使いたいが、GPU はそこそこお金が掛かるので使う時だけ動かすようにしたい。Cloud Run が GPU をサポートしてくれるようになると嬉しいけど、今のところはサポートされてない（将来的に使えるようになるかもという話は聞いたり聞かなかったりする）。Cloud Run for Anthos では GPU を使える https://cloud.google.com/anthos/run/docs/configuring/compute-power-gpu という話を聞いてちょっと試してみたりした。これは GPU enabled な node pool を有する (Cloud Run for Anthos を有効化した) GKE cluster 準備して、その node に NVIDIA driver 準備して、とかでとりあえずまともに起動するだけでもちょっと手間取った。そして node 数が最低 3 個じゃないとそもそも cluster 作れなかったりして、あれこれ試してるうちにちょっとした金額になってしまったという…個人で GPU を使ったちょっとしたサービスを作りたい、という場合には殆ど選択肢に入らなそう。ということで大人しく Computer Engine を使うことにしたのだが、Terraform 使って resource 作成時に docker container が起動していてあとは text2img の endpoint を叩くだけにしたい、というところでもちょっと大変だった。Compute Engine では Container-Optimized OS https://cloud.google.com/container-optimized-os/docs という Docker container に最適化された VM image が提供されているが、これで GPU 使おうとすると cloud-init 使って NVIDIA driver と CUDA インストールをしないといけない。いまだにそんなことしないといけないのは面倒だなと思って、deeplearning-platform-release プロジェクトの PyTorch が使える image を以下から探して使うことにした。gcloud compute images list --project deeplearning-platform-release --no-standard-imagesそしたら今度は起動時に docker container を走らせておくのがどうすべきかというところで困って、軽く調べてもよさそうな解決策が見つからなかったので、結局 systemd の service として docker container を起動するものを登録して、それを起動時に metadata_startup_script で実行するという形になった。これなら COS image で cloud-init 書いてるのと一緒やん…ということになってしまった。これくらいの用途ならごちゃごちゃやらずにスッと使えるものがあって欲しい気がするが、自分には見つけられなかったので知ってる人がいたら教えてください。ちなみに現状では T4 使うようにしてるけど、A100 使うように変えると動かなかったりして、まだまだイマイチである。適当なところとりあえず自分が遊ぶように作ったので、適当なところが多い。ライブラリのバージョンを fix してないとか、backend の API が公開されてるとか、local の google cloud の credential で resource 作ってて適切な権限持たせた service account 作ったりしてないとか、Container Registry 使ってて Artifact Registry 使ってないのと雑に latest タグ使ってるとか、その他もろもろ。もう少し真面目に作っていくか〜という気持ちになりたかったが、後述のように pretrained model が非力で十分なやる気が喚起されなかった（という言い訳）。今後もっと良いモデルが使えるようになれば改めて頑張るかもしれない。pretarined model の非力さ今回遊んでみて少しは楽しかったのだが、pretrained model を使った生成画像が論文で報告されている画像と比べてイマイチだったというのが残念なところであった。公開されている pretrained model は小さいモデルになっており、学習では（悪用を防ぐためと思われるが）人物のデータとか暴力的な object とかが除かれたデータが使われているとか、upscale のモデルは二段階ではなくて一段階目のみ提供されている。最近の text2img ではインターネット上になさそうな画像（例えば テディベアがバタフライで泳いでる とか）を生成できるところに凄さがあるのだが、それが殆ど再現できてないと感じられた。これだと最近の本質的な発展が取り込まれていないので、遊びがいがないな〜という結果になってしまった。dalle-mini https://huggingface.co/spaces/dalle-mini/dalle-mini の結果の方がかなりよさそうに感じるので、お手軽に遊ぶならこちらの方がいいかなと思う。もっとよいモデルが使えるようになったらまた改めて着手してみるとするかな、ということで今回は終了。まとめtext2img の web アプリを作ったというエントリ。

text2img の簡単なウェブアプリを作った

TL;DR最近幼児教育に関する本を読んでいるので、良かったものをまとめておく一番良かったのは「米国最強経済学者にして２児の母が読み解く 子どもの育て方ベスト」子が産まれたので子育てをしてるが、この機会にと思って幼児教育に関する本をガッと読んでいる。他人にお薦めされたり軽く調べてよさそうなものを読んだりしているが、結構似てる話をしているものも多く、なんとなく全体的な雰囲気は掴めてきた。これ以上あれこれと読まなくてもいいかなと思えてきたので、読んできた本の中で良かったものを 3 つ挙げておく。自分と似たような思考の人であればとりあえずこの 3 つをお薦めしておけばいいかなという気がしている。米国最強経済学者にして２児の母が読み解く 子どもの育て方ベストAmazon link: https://www.amazon.co.jp/dp/B08WYPWYKB/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1同僚に勧められて読んだ本。エビデンスに基づく子育て本を色々読んでみたが、最もよく書けているのがこの本だった。経済学者である著者が実験のバイアスをケアしながら、実体験にも基づいて解説をしている本である。夫も経済学者であり（本の中で夫の論文が引用されていたりしている）、論文をかなりちゃんと調べていそうで、論文があったとしてもそれが信頼に足るものかを判断していそうなところが凄い。子育てに関する論文をチェックするという観点で、ここまでの熱量は自分にはないな〜と感じる。可能な限り定量的でありながら、子どもにとっての効果だけでなく家族全体の効用についても言及したりしていて、納得感がありつつ実践的でもある。例えば、母乳育児による健康への影響（乳幼児期の下痢や湿疹や発疹や腸炎リスクには好影響がある）や IQ への影響（有意な影響を与えない）などが解説されつつ、金銭や手間の観点も盛り込んでいる。内容は米国の話ではあるが、国の依存性がそこまで大きくない話が多いので、日本を含む他の国の人が読んでも大いに参考になる。唯一の欠点はタイトルの煽り方。なんでこんな酷いタイトルしかつけられないのか…自分は同僚に勧められなければ読まなかったであろうタイトルだが、こういうタイトルをつけた方が売れるのだろうというのは虚しさがある。ちなみに原著は CRIBSHEET (虎の巻、カンニングペーパー): A Data-Driven Guide to Better, More Relaxed Parenting, from Birth to Preschool というもので、洒落てるし本の内容をよく表現していると思う。幼児教育の経済学Amazon link: https://www.amazon.co.jp/dp/B00ZQFPQLW/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1自分であれこれ調べてるうちに見つけて読んだ本。幼児教育（就学前教育）への介入が重要であることを過去の社会実験に基づいた分析から著者の Heckman（2000年に個人や家計の行動の統計的分析に関する貢献でノーベル賞受賞）が主張し、それに対して色々な立場の人からの意見をもらっているという本。内容は、認知能力と同様に非認知能力を育むことが重要であること、幼児教育への介入が費用対効果が高い（投入するコストに対して将来的に得られる利得が大きい。過去の社会実験では 15% くらいになるみたいで、これは公的教育の ROI とくらべるとめちゃくちゃ高いらしい）ことを論じている。主張の根拠になっている社会実験（ペリー就学前プロジェクト）が 50 年以上前だったりして以降の別の社会実験ではその再現性に疑問符があったりして、この手の社会実験は本当に効果があるのかを見極めるのが難しいところはあるが、幼児教育への介入の ROI という観点で面白い本だった。完全にアメリカの話なので参考程度という内容も多い感じだけど。この本を読んでおけば、幼児教育への介入が重要なので、個人の子育てとしては勉強できるようになってから頑張るのではなくその前から教育を進めた方がよい、公共政策的には限られた予算を幼児教育中心に投入した方がよい、みたいな主張の意図するところを理解できるようになる。Heckman の議論の後に各分野の専門家によるコメントが寄せられていて、古くてサンプル数が少ない研究をベースにしてる点への批判とかがちゃんと書いてあったりするので、内容を鵜呑みにしないような構成になっているのもよかった。赤ちゃんはことばをどう学ぶのかAmazon link: https://www.amazon.co.jp/dp/B07XLC1MKM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1同僚からゆる言語学ラジオの赤ちゃんの言語習得シリーズ https://www.youtube.com/watch?v=AMIaheSRVew&list=PL911pe0HjN9gufWEDWCoQIsTGkyNSSkor が面白いと勧められて見ていたら、そこで紹介されていたので読んだ本。赤ちゃんの言語を学ぶプロセスを解明するためにどういう研究をしてどういう結果が得られて、それをどう解釈できるかという解説をしてくれる本。興味深い結果としては、音声で聞かせるだけでは赤ちゃんの学びにはならずインタラクション（赤ちゃんの反応を見つつ語りかける）が必要であること、バイリンガルといってもほとんどのケースでどちらか一方の能力の方が高い、など。単に動画を見せるだけでは学べないけど、最近の機械学習で赤ちゃんの反応を検出した上で会話をするみたいなのは一定できそうなので、それで学ばさせるとどうなるかとか気になるね〜など想像力も刺激される。本以外にどういう情報源にあたるか？ちょくちょく参考にするのは以下の学会のウェブサイトである。子が新生児なので幼児教育というより医学的情報を必要とすることの方が多いのであまり調べてないのだけど、幼児教育関連であればとりあえずここを見とくと良い、みたいな情報源が存在するのかは分かっていない。日本小児科学会: https://www.jpeds.or.jp/American Academy of Pediatrics: https://www.aap.org/Society for Research in Child Development (の Briefs and Fact Sheets): https://www.srcd.org/論文が公開されてるんだから気になったものは全部自分で論文を調べればいいのではないか？という考えもあるが、あらゆるものを自分で調べるというのはそもそもの分野への興味とか手間とかの観点から難しい。具体的には、歩きながら抱っこすると明確に泣き止むよなと思って理由を調べてたら輸送反応が関係している研究 https://www.riken.jp/press/2013/20130419_2/ を見つけてそれを読んだり、子を毎日沐浴させる必要性ってあるんかと思って聞いたら同僚に関連している研究 https://repository.dl.itc.u-tokyo.ac.jp/record/48701/files/A32822.pdf (PDF 注意) を教えてもらってそれを読んだり、みたいなことがあった。まあでも門外漢にとってはちゃんとした本にまとまってくれてるのが嬉しいですね。まとめ幼児教育に関する本を色々読んで雰囲気を掴んできたので、特に良かった本を 3 つ挙げてみたというエントリ。

幼児教育の本をいくつか読んで良かったものを挙げる

TL;DR子が産まれたので 4/15 ~ 6/30 まで育休を取ります東京じゃないところで子育てしたいな〜と考えたので福岡に移住します4/15 に子が生まれました。子ができたらまずは集中して子育てするか〜ということで 6 月末まで育休を取ることにした。子が生まれた4/15 お昼ごろ爆誕した。新型コロナウィルス感染症対策のため、自分は健診の時から母子が退院するまでクリニックに入ることはできない。これはやむなしとは言え、やはり寂しい。あと数日待たないとまだ実物の子に会うこともできないわけが、ともかく母子ともに無事で何よりだった。自分もできる限りのことはしたつもりだが、どう足掻いても圧倒的に妻の負担の方が大きいわけで、そういう状況でも一緒に楽しく過ごしてくれてお産も頑張ってくれた妻には感謝しかない。同僚に産婦人科医がいるので、プロに色々聞くことができたというのは非常にありがたかった。クリニック・病院選びや出生前検査など、自分が調べるだけでは判断できないことを色々教えてもらえた。ちなみに子に欲しいものなんかある？と聞こうと思ったがどうやらまだ会話することができないみたいなので、子が見て楽しんでくれそうなアイテムを選んで欲しいものリストを作った: https://www.amazon.jp/hz/wishlist/ls/24YEC5IJRKEVP?ref_=wl_share育休を 2 ヶ月半ほど取得する子が産まれた最初のうちは育児に専念したいと思い、育休を取ることにした。もともと出産予定日が 4/12 で退院まで 5 日ほど掛かるので 4/15 くらいから取っておくか〜と考えて申請していたが、実際に出産日も 4/15 になってなかなかの偶然の一致であった（ちなみに育休は出産予定日から取得することができるので、予定日がずれれば産まれる前から休みに入ることもある）。チームには最近立て続けに優秀なメンバーが加入してるので一緒に色々やっていきたいところではあったが、しばらくはお休みすることにした。育休の間に何かやろうかな〜と思ったりもするけど、育休っていっても休みじゃなくてめちゃ大変だから！という話も聞くので、我が家の場合どうなるか様子を見つつやっていこうと考えている。福岡に移住することにした子が産まれそう、となってから引っ越しをすることを考えていた。家は 75m2 以上で 3LDK 以上とかがいいなとか、徒歩圏内にいい感じの公園が欲しいなとか、家賃はできるだけ抑えたいとか、とはいえそこそこ都会で生活の利便性も欲しいなとか、我々が求める条件を満足しようとすると都内では（そして東京郊外でも）厳しかった。これはもう地方移住でもいいなと思って色々探していたが、Ubie には福岡で働いてる同僚が 5 人以上いて、福岡はいいぞと推されることが多かった。自分でも色々調べてるうちに、福岡はかなりよさそうという思いが強くなっていった。そこからは大濠公園近辺で好条件の物件を探して不動産会社に連絡をして、幸運にもかなりよさそうな条件の物件の契約にこぎつけることができた。別に福岡には縁もゆかりもないのだが、同僚もそこそこいて色々情報を教えてもらったりコミュニケーションも取れそうなので、そこまで不安なく移住を決断することができた。ということでみなさん、福岡にお越しの際はぜひご連絡ください。まとめ子が産まれた。育休を取る。ついでに福岡に移住する。

4/15 ~ 6/30 まで育休を取ってついでに福岡に移住します

TL;DR各々が何を話したいか？ということなので特定の答えがあるトピックではない自分は (仕事に関すること):(それ以外) = 7:3 くらいの割合で話してる気がする最近忙しい気味で、雑談の内容がどうこうではなく日頃雑談をするくらいの余力があるという状況が大事だな〜と思ったりしている職場で雑談、やってますか？自分は結構雑談が好きな方ではあると思うけど、そもそもどういう内容の雑談をしたいんだっけということを振り返ってみる。雑談することで相互理解が深まるとかそういう効用の話は今回は触れずに、雑談の内容について考えるエントリ。仕事以外の内容まずは仕事内容に関係ない雑談から。自分は仕事と関係ない雑談もちょこちょこする。最近調子どうですか！？というのを会話のきっかけにしがちだけど、その後の分岐で仕事以外の話になるとそれを継続して話すことが多い。内容としては相手に合わせつつ生活一般とか漫画とかゲームとかになりがちだけど、振り返ってみるとあまり内容には気を払っていない。その場が楽しい時間になるようにとか、それをきっかけに仕事の議論につなげようとかが目的にあることが多くて、話の内容自体はどうでもいいと思っている節がある。こういうことを書くと別に話したくもない内容を無理して話してると思われかねないが、普通に楽しんではいるのでそこはちゃんと表明しておきたい。本質的には話の内容には興味がないということで、そもそも雑談というのはそういう要素を多分に含んでいるものですよねと言われたら、それはそうという感じでもある。そもそも他人に興味がないので、仕事以外の雑談が苦手とかそもそもしたくないという人がいたりするけど、気持ちは分かる。自分も他人に対してさして興味はないけど、場の話題とかをコントロールしがちなので、自分が興味ある話題に転換するのが比較的上手いということで苦手感が薄いのかなと自己分析している。仕事以外ではあるけど技術的な内容の雑談、というのはだいぶ趣が異なる。これは自分は好きで最近何か面白いトピックありますか！？的に聞いて色々話したり、同僚が定期的に開催してくれる会で技術的トピックを持ち寄ってワイワイ雑談したりする。仕事の状況によっては技術的にはそう面白くないことをやることも度々あるので、この手の雑談は良い気分転換になる。仕事に関する内容まず、今まさに取り組んでいるタスクは必要に応じて議論すればいいので雑談的に話したいということは特にない。自分が話したい内容は大雑把に分けると三つくらいある。話したい内容の一つ目は、相手がどういうことをやっているのかという情報収集である。どういうことやってるかとかどういうトピックに興味あるかとかを聞いておくと、後々議論しやすくなるので便利。最近どんな仕事してるんですか？というのはいろんなところでよくなされている雑談だろう。話したい内容の二つ目は、タスクを進めた上で出てきた（そのタスクで直接的に成し遂げたいものとは別の効果をもたらす）アイデアである。いまの実装はこうなってるけどこう変えればこういうことできそう、こういう分析をしてたらこんなことを発見したけどそれから考えるにこういう施策考えられそう、とかはタスクをやっていると色々見えてくるものがある（ここでの書き方は指示語だらけだが…）。例えばスクラムで PBI やタスクをきっちり管理してそれを消化するばかりだとこういうことを雑に話す機会がなかったりするので、雑談がその役割を果たしてくれたりする。雑談じゃなくてそういう場があればもちろんそれでもいいけど。話したい内容の三つ目は、日々色々考えてるプロダクトとかサービスとか組織課題に対するアイデアである。こういうのはプロジェクトとかで携わってないとなかなか議論する機会がないので、色々と自分の中で蓄積しておいて、雑談できるタイミングに持ち出して議論するのがちょうどよい。リモート中心の世界になったけど、gather https://app.gather.town/ とかを使うと雑談できそうな人を視覚的に認識できたりするので、自分に時間があるときは雑談をしにうろうろしたりできるのはいいね。他にもこういうことがしんどいですよね〜みたいな愚痴っぽい話もあったりするかもしれないが、そういう話はあまりしないように心がけている。雑談というと最近の辛い話、みたいに固定化されると雑談してても辛くなってきてしまうので。自分は仕事以外の雑談をするときも、それをフックにこういう仕事に関する雑談をすることが多い。ということで、雑談しましょうよ〜と言って話すと (仕事に関すること):(それ以外) = 7:3 もしくは 6:4 みたいな割合になる。日頃雑談をするくらいの余力があるという状況は大事上記のように書きはしたのだが、最近忙しい気味であまり雑談ができてない。雑談をする余裕があったり、その雑談で筋がよさそうな施策が見えてきたら新たにプロジェクト作って推進していける余裕があったり、ということは必要だよなと感じている。ということで、中身の話をすると言ったエントリではあったが、大事なのは日頃雑談をするくらいの余力があることだよな、というところに着地してしまった。ちゃんちゃん。まとめ雑談についてちょっと書いてみた。雑談はいいよね。雑談できる余白を作らねば。

職場での雑談で何を話したい？

TL;DR令和3年分の確定申告を終えた仕訳帳を作り始めてから税額が確定してクレジットカードで支払い処理をするまで 6 時間ちょっとだった去年副業とかあまりしてなかったのと特に新しい処理がなかったので過去最短だった偉いので確定申告をした。特筆すべき点はないのだがメモがてらブログに書いておく。自分の確定申告の流れ過去に記事 https://yoheikikuta.github.io/tax_returns/ を書いていて、基本的にはこれを毎年少しずつ育てて（新しいことがあったら情報をアップデートして）いる。今年の確定申告も例年通り以下の手順で進めた。仕訳帳を作る仕訳帳を基に総勘定元帳を作る株式関連の情報を取得して整理e-Tax で確定申告書B、所得税青色申告決算書、医療費向上の明細書、外国税額控除の明細書、を作成内容を確認してクレジットカードで納税昨年から変更が入った分電子庁保存法 https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/02.htm というものが2022年1月から施行された。これは、これまで紙の保管を義務付けられていた国税関係帳簿書類などを電磁的に保存しておけば紙が不要になるもの、と理解している。まあ正直細かい条件とか読んでないけど、最初に帳簿とかを作るときは全部 Google Sheets で作ってるのでこれで満たされていて欲しい（希望的観測）。医療費控除のマイナポータル連携で自動的にデータ取得ができるようになった。これはとりあえず連携してるので試してみたが、ちゃんと全部情報が入ってんのかな？という疑問が湧いた。額を見ると足りない気がする。どちらにせよ今回は医療費控除が発生するほど医療費使ってないので、連携ができたという以上の深入りはしてない。あとは e-Tax でスマホからできるよってアピールが強くなってた気がした。M1 Mac とかで問題なくできるのかなという懸念があったのでうまくいかなかったらスマホで試してみようとも思ったが、問題なくできたので試してない。そんなもんかな。昨年は副業をあまりやってないので経費とするものもほとんど発生しないし、作業はサクッと終わった。M1 Mac から e-Taxマイナンバーカードの読み込みがうまくいかないかも、的な警告を目にした気がしたが、結果的に自分は問題なくできた。ただし Chrome は対応していないので、Safari で処理をした。Safari: Version 14.1.2IC カードリーダ: NTT ACR39-NTTCom https://www.ntt.com/business/services/application/authentication/jpki/download6.htmle-Tax ソフト: 適宜これやれあれやれと指示が出たものに従って特に問題なくできた所管トータル 6 時間くらいで終わってよかった（去年は 15 時間くらい掛かってそうだった）外国税額控除のための作業が一番面倒くさい（SBI証券で特定口座（源泉徴収なし）だと年間取引報告書が発行されずに自分で一件一件調べないといけない…過去に問い合わせたときも一覧は作成してないと言われた）色々とめんどくさいところはあるけど、色々調べて自宅で作業して申告と納税をする、という一連の流れが全部自宅で完結できるのは便利だまとめ令和3年分の確定申告も無事に終えた。偉い。

令和3年分の確定申告を終えた

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 としてスカラー関数・集計関数・分析関数、サブクエリ、型変換について書いた。自分のブログはコードブロックの表示が綺麗ではないのでそろそろ改善したい気持ちになってきた…