2021 年振り返り

今年も一年の振り返りを簡単にまとめました。

私生活

  • 体調管理
    • 1 日も風邪をひくことなく元気に過ごせました
    • 仮にコロナにかかると、子どもが濃厚接触者になります。その間仕事は休まないといけなくなるので、市中感染が多いときは積極的に在宅するようにしてました。
  • お手伝い
    • 12/31 にコミックマーケット９９（通称、冬コミ）の手伝いに行きました。二年ぶりでオペレーションを忘れているかと緊張しながらスペース設営に望みましたが、だんだんと勘を取り戻せて無事一年を締めくくれました。入場者数に制限がかかっていたため、常に怒号が鳴り響くこともなく、また、間違って人流に逆らった瞬間命の危険を感じることもなく、例年に比べると随分と落ち着いたイベントでした。

f:id:yoheimuta:20211231072515j:plain
サークル入場開始直後の東ホール

  • NFTs and a Thousand True Fans[1] で引用されている a Thousand True Fans はすでに自分にとっては身近な世界の話でもあるので、それを加速させる可能性を持つとアンドリーセン・ホロウィッツ（著名VC）が主張する NFT にも興味を持ちはじめました。OpenSea や Rarible、HABET で NFT を出品したり購入すると、通貨としてのイーサリアムだけでなく、ブロックチェーン技術の活用法にも気付かされます。

[1] を意訳する。2008 年に Kevin は 1000 True Fans というエッセーを発表した。この中で、Kevin はインターネットの登場によってクリエイターが成功するには数百万人のファンがいる必要はなくなったと主張した。1000 人の熱狂的なファン、そのクリエイターが作るものは何でも買うという本物のファンが 1000 人いればビジネスが成立するようになると予見した。インターネットはこれを後押しする方向に進化してきたが、中央集権的な巨大プラットフォームがクリエイターとファンをつなぐ主要な手段になってしまった現状は、再びインターネット以前の中間者が活躍する舞台になり始めている。その中にあって、NFT はブロックチェーンを基礎にクリエイターがファンに直接販売できる機会を与える。これは今後も盛り上がりをみせるクリエイターエコノミーの主流になりうる。理由は３つあって（以下、略）

理由の詳細は長いので原文にあたってもらうとして、それでも最初少し捉えどころがない印象を受けると思うので補足しておく。この記事はビットコインやイーサリアムという、人類がはじめて獲得した高信頼の分散型プラットフォーム上でスタートアップがビジネスをはじめる経済合理性が生まれ始めているということを3つの角度から論じてる。1つ目はこのプラットフォームは誰でも参加できる分散型という特徴を持っていることから中間者の介入は限定的で、end-to-end での取引にかかるマージンは確実に下がるはずである。したがって、売り手と買い手 {1000 True Fans} が集まりやすい。2つ目はビットコインがすでに証明しつつある、金銭的な価値が担保されるほどに社会から信頼された分散プラットフォームという舞台で、通貨{Fungible}に続いて商品 {Non-Fungible/NFT}が売り買いできるようになったイーサリアムの登場。3つ目はユーザー獲得に多額のコストをかけている中央集権的なプラットフォームと比べたとき、イーサリアムなどの分散型プラットフォームは0コストで Facebook {Meta}に迫る時価総額に短期間で成長。これは中間者マージンがさらに低下する力学の存在を裏付けてくれる上に、多くのエコシステム需要を予想させる。

  • 行った場所
    • 緊急事態宣言も明けてコロナがかなり落ち着いた頃を見計らって、強羅花壇に宿泊しました。はじめて Googleマイマップで作った旅程表を用意しました。Googleマイマップ自体は、アプリによくあるチェックイン機能を Postgis で実装した時に、任意の場所の KML{Keyhole Markup Language} ファイルをエクスポートする用途で使って以来でした。普段電車を使って移動していると地図上の位置関係をあまり意識しません。もう少し続けてみようと思ってます。
  • 会った人
    • Stay home 期間が長かったので、それ以外の期間は人と会って話す機会を作るようにしてました。以前一緒に働いていた同僚と久しぶりにランチをするのは楽しいです。考えていることの壁打ち相手になってもらうこともあり、偏った見方を矯正する良い機会にもなりました。
  • 子育て
    • 今年は、「たくさん笑う」、「たくさん寝る」、「たくさん外で遊ぶ」、「たくさんおしゃべりする」、「たくさん食べる」、を意識してました。やはり偏食は簡単には矯正できない中で、色々な食べ物を与えるようにしているので「たくさん食べる」は少し難しかったです。それ以外はよくできました。特に、お互い気まずい瞬間など目があったときにとにかく笑うようにしていたら、困ったらとりあえず大笑いする癖がついてきました。保育園で先生に怒られたときも、先生が笑い返すまでずっと嫌味な感じではなく笑ってます。
    • ピアノ教室に通い始めました。リトミッククラスです。
    • 子どもの成長はあっという間なので、後から振り返るとあのときもっと一緒に遊んであげればよかったと後悔するという話はよく聞きますね。自分の場合は、一般的な労働者の可処分時間マックスまで一緒に時間を過ごしているのでその心配はありません。いつもと同じ時間、同じ道、同じ公園、同じベローチェ、同じアイスラテ、同じお菓子。連日同じルーティンが続いた 12月30日16時頃、子供と手をつないで歩きながら、同じ日をループしてる感覚を覚えたときにそう思いました。これを限界と呼びます。
    • 英語の時間を週末取るようにしてから、二年が経ちました。最近、横で信号待ちしてるサラリーマンが電話しているのを聞いて、「No Japanese!」 と注意してました。
  • ベスト of 2021
    • ブック（一般）
      • Death's End (The Three-Body Problem Series, 3) -- 邦題は「三体III 死神永生」。話のスケールがでかくて、日常生活の些細なことがちっぽけに感じさせてくれます。壮大なフィクションを読んだ、という読後感です。3 日くらいで効果が切れるので Audible でお気に入りのパートを週明けとか聴いてます。
    • ブック（専門書）
    • ソング
    • ドラマ
      • Maid -- 邦題はメイドの手帖。2歳の娘と家出したシングルマザーがダイソンの掃除機片手にお金持ちの家を回って日銭を稼ぐ話です。終始一人称視点で物語が進行していくので没入感が高いです。話を重ねるごとにじわじわと追い込まれていく若い母親の不安と苦労を追体験できます。行政への問題提起を含む社会派ドラマです。
    • パラレル・オブ・ザ・イヤー
      • パラレルのユーザーとして今年一番良かった更新内容をここに称えます。
      • 通話内チャット -- 非公式な通称、聞き専チャット。グループ通話中に何らかの事情で話せなくなっても、これがあれば会話が続けられます。通話が終了した後に読み返したりできないので、話している感覚で気楽に書けます。

仕事

  • Ruby
    • v2.5.8 を使ったサーバーがリクエスト処理中に突然止まってしまい puma スレッドが完全に枯渇するという現象に遭遇したので upstream にバグ報告[2]をして、その調査過程を Medium に投稿しました[3]。後日 Reddit の ruby 板 や Ruby Weekly[4] で取り上げられていることを周りから教えてもらい、国外での Ruby の関心の高さを再認識しました。著名な Podcast である Ruby Rogues からゲストのお誘いも当時あったのですが、調整がつかずそのまま流れました。

[2] An exception still breaks monitor state and causes deadlock in 2.6.7: https://bugs.ruby-lang.org/issues/17669

[3] Why puma workers constantly hung, and how we fixed by discovering the bug of Ruby v2.5.8 and v2.6.6: https://itnext.io/why-puma-workers-constantly-hung-and-how-we-fixed-by-discovering-the-bug-of-ruby-v2-5-8-and-v2-6-6-7fa0fd0a1958

[4] Ruby Weekly Issue 549: April 22, 2021: https://rubyweekly.com/issues/549

  • サービス
    • ピークタイムのサーバーダウンは前回の 2020/09/05 21 時から 5 ヶ月後の 2021/02/22 21 時に一度ありました。Preemptive node が複数同時に落ちたのが直接の原因です。その後はありません。この時にまとめた再発防止策 6 つのうち、4 つが完了してます。残り 2 つは進行中です。
    • 5月頃から API の 5xx エラーが一日通して 0 件になる日が現れ始めました。多すぎて見きれなかった時代は過ぎ去りました。続いて 8/21 には終日でスロークエリが 0 件になりました。これも多すぎて見きれなかったところから大きく改善されました。0 件を維持する必要はないですが、多すぎることによって無駄に必要に迫られるモニタリング環境の構築を当面しなくて済むのが良いです。
    • ユーザーの増加に伴って、データ不整合による問い合わせが徐々に増えてきました。このままだといずれ通常業務を圧迫するおそれがあったので、適切な DB 制約をつけながら不整合データを整えていくデータクレンジングプロジェクトがはじまりました。論理削除用の deleted_at に直接ユニーク制約はつけられないので GENERATED カラムを含む複合インデックスを追加していくのがメイン作業です。10 月頃に一通り対応してもらったおかげで、問い合わせは来なくなりました。
    • その他にも色々ありますが、わかりやすいマイルストーンの列挙だけにとどめておきます。Sidekiq の Queue latency もすごい安定するようになりました、とか良くなったことはたくさんあります。機能開発は続けながらも、いつの間にか達成できていることが多いです。バランスを取れている一つの証だと思います。
  • 会社
  • チーム作り
    • 前半は、パラレル内にミニゲーム・ミニアプリを追加していく土台の設計やそのチームの立ち上げをしてました。第一弾は慣れたネイティブでサーバー含めた基盤を作ってから、第二弾で開発速度重視の Unity ゲーム、その後は数を増やしやすい Web ゲームと段階的に手を広げました。リスクとスピードをバランスさせながら経験値をたくさん積めました。おかげで安定した体制が出来上がりました。
    • 後半は、ボイスチャット基盤の安定化を行うチームの立ち上げをしてました。低レイヤーを完全なブラックボックスとして扱う限りにおいては、状態遷移図を書き出すようなデバッグ作業に大半の時間を使ったほうが直接的な効果が期待できます。一方で、基礎知識に欠けるとどこかで進捗が完全にスタックしてしまうリスクが残ります。デバッグ作業自体とても難しいですが任せられる人がいたので、その間自分は優先順位の決定やどこまで深くやるかの判断はしつつも基礎知識の理解に時間を使いました。DSP {Digital Signal Processing/デジタル信号処理, 広告ではないよ}が分野としてはそれに該当するので、教科書[5][6]を読んでました。その過程で、前提知識として求められる、電子工学・三角関数・微積分・微分方程式あたりの復習と英単語インプットは本やオンライン動画で補完しました。Dummies シリーズ[7][8][9][10]ありがとう！子どもを寝かしつけしながら読み進めました。このチームの扱うタスクは既存の 2 週間くらいで目に見える進捗を出していく開発リズムには全然合わないことが予想されたので、お互いノイズにならないように隔離して進めました。おかげでシステムへの深い理解が蓄積されてきました。

[5] The Scientist and Engineer's Guide to Digital Signal Processing: http://www.dspguide.com/ch1.htm

[6] Understanding Signal Processing 3rd: https://www.pearson.com/us/higher-education/program/Lyons-Understanding-Digital-Signal-Processing-3rd-Edition/PGM202823.html

[7] Electronics For Dummies 3rd Edition: https://www.amazon.com/Electronics-Dummies-3rd-Computer-Tech-dp-1119675596/dp/1119675596/ref=dp_ob_title_bk

[8] Basic Math & Pre-Algebra For Dummies: https://www.amazon.com/Basic-Math-Pre-Algebra-Dummies-Science/dp/1119293634

[9] Pre-Calculus For Dummies 3rd Edition: https://www.amazon.com/Pre-Calculus-Dummies-Mary-Jane-Sterling-ebook/dp/B07JQDQLLD

[10] Calculus For Dummies: https://www.amazon.com/Calculus-Dummies-Math-Science/dp/1119293499

ソフトウェアエンジニアリング

雑記

  • 会社組織は職種別の縦割り構造からターゲット別のユニット構造に変わりました。入社当時から今までエンジニアが人員の一番大きな割合を占めている中で、PM との間に自分が立って、全エンジニアを一つのカンバンボードと二週間のタイムウィンドウで成果を監督する手法を入社して一ヶ月後に採用しました。その意味で、前者は自分が当初から積極的に推し進めた方針といえます。入社直後まだシステムの全体像を掴めていない中、多様な経験を積んだ唯一の正社員エンジニアとして、毎週ピークにサーバーダウンする状況をいち早く解消しつつ、大量に溜まったバックログを業務委託が大半を占める全 8 人に割り振るのにはこれは有効です。その後想定通り、正社員が増えて、システムも安定化、バックログも枯渇しはじめました。この頃になると、エンジニアの稼働効率・安定よりもプロダクトの創造性をいかに全社で上げていくかに周りの注目が集まるようになりました。最初に相談を受けた時に、組織を全く別方向に変えることによる、エンジニアリング面でのバックログの解消速度低下と開発と運用（Devops）をバランスさせる力学の低下は避けがたいが誰も想定していなそうで、だけど実際は誰もそれを望んでない副作用だろうと考えてました。まず、下がった生産性を底上げするためには、各々にシンプルな目標設定と自律性の高さが必要です。複数の Tribe（自己完結した村社会みたいなニュアンス）がそれぞれ直交した目標に向かって 1Q（3ヶ月） 突き進む形はその点から理想的です。また、Server/iOS/Android という重要プラットフォームそれぞれの SLI/SLO 回復に責任を持つ開発 = インフラユニットという存在は必要だと判断しました。その後、全員で細かいところをすり合わせながら、エンジニアリング面での副作用を回避する形でターゲット別のユニット構造に変わることができました。以前のシンプルなマネージメント体制から比べると、この組織は飛躍的にコントロールのレバーが増えます。Q 初めの目標設定も非常に大事になります。適切なメンバーのアサインは以前ほど細かい粒度では行なえません。つまり、ポジティブな変化である一方、調整が常に求められます。