This Week in Railsを読むポッドキャストを始めて3ヶ月経った

This Week in Railsとわたし

This Week in Railsという、Railsのコミットやプルリクエストを毎週お知らせしてくれるWebページがあります。メールとRSS feedで購読できます。

以前(2023年以前)からRSS feedを個人のSlackワークスペースのチャンネルに登録していました。

ですが、なんとなく通知を流し見する程度で、ほとんどまともに内容を読んでいませんでした。

2024年になってから、「Railsはお仕事で使っているわけだし、最新の情報を追いかけるようにしよう」と気持ちを改めて、行動を変えることにしました。

単に読むだけだと自分の中に閉じてしまうので勿体ないなと思ったので、ついでにポッドキャスト番組をつくって配信を始めました。

podcasters.spotify.com

2024年1月の第1週から始めて3月末の現在まで、毎週欠かさず配信できています。

なにをやっているか

次の4つのことをやっています:

  1. This Week in Railsの最新記事を読む
  2. 記事の中で気になったプルリクエストを2~3件ピックアップしてScrapboxにまとめる
  3. まとめた内容を読み上げる(声を録音しておく)
  4. 音声ファイルをSpotifyにアップロードして配信する

この作業を毎週土曜(あるいは日曜)にやっています。

This Week in Railsは日本時間の金曜の深夜〜日曜の早朝あたりに更新されています。 多くは土曜の午前中までには更新されているので、昼前頃から記事を読んでScapboxにまとめ、昼明け〜夕方ごろに収録して配信する、というルーティンになっています。

まとめたページの一覧です:

scrapbox.io

収録は一発撮りで、編集をまったくせずにそのまま出しています。編集に労力をかけずに、継続することに主眼を置いているためです。 第7回まではSpotifyの機能をつかってBGMをつけていましたが、第8回以降はそれも面倒になってやめました。

一発撮りである分、事前に文章をまとめる際には「そのまま読み上げることができるか?」の視点を大事にしています。 (第1回は事前に文章を用意せず、かつ、直前にビールを(昼から)飲んでいた日だったので、だらだらとまとまりがないエピソードになっています)

やってみて感じていること

たのしいです。やってよかったなって思っています。

学びが多いです。issueとプルリクエストを読むと、「現状どうなっているのか」「なにに困っているのか」「どうなったらハッピーなのか」「どうやって解決するのか(方針/コード)」が書いてあります。

「現状どうなっているのか」を読んだ時点で、あ、そもそもそんな機能があるのね?知らなかったわ〜、となることも多いですね。

「なにに困っているのか」「どうなったらハッピーなのか」を読むと、そういうシーンや用途があるのか〜と知れる(共感できるものもあれば、自分にはまったく馴染みのないシーンだったりもする)し、その状況だったらたしかにもっとこうしたほうがよさそうだね、と視野が広がっていきます。

「どうやって解決するのか(方針/コード)」を読むと、自分の解決策の選択肢も広がります(ような気がして来ます)。複雑なコードの変更を経て解決している場合もあれば、自分にもできそうなシンプルな変更で解決している場合も多々あります。

いろんな観点で学びが得られてお得ですね。

知識がつながっていくのもたのしいです。「あ〜、3週間前に出てたあのプルリクエストに関連する対応か〜」など。個別のプルリクエストだけではなく、複数のプルリクエストでつながりをもってRailsが開発されていることを感じることができます。

ポッドキャストとして配信するという選択をしたのもGoodだったなと思っています。

「このあと声に出して読み上げるんだぞ〜」という前提で調べると、自信を持って説明できる範囲がどこまでなのか(ここから先は説明できない、という線がどこにあるのか)を意識するようになるので、自分の知識や理解に対する認識が以前よりも明確になったと感じています。 また、その前提で調べていても、実際に声に出して読み上げてみると「あれ、この部分けっこう曖昧じゃん」という箇所が出てきたりして、それもおもしろいです。

これから

3ヶ月やってみて、無理なく続けられることがわかってきたし、得られるものも多いと感じているので、これからも継続していこうと思います。今年中は継続できるといいな。

退職とこれから

GMOペパボを退職します

2024年2月29日付けで、2018年9月から5年5ヶ月間を過ごしたGMOペパボ株式会社(以下ペパボ)を退職します。

1月末に最終出社を終えて、

2月は勉強をしたり毎日声日記を記録したりして過ごしていました。

listen.style

ペパボではSUZURIというサービスの開発に携わっていました。 やってきたことは前回のブログ SUZURIでの5年間でやったこと - tanaken’s blog にまとめてあります。

感謝

本当にたくさんのことを学びました。

尊敬できる同僚がたくさんいてありがたい環境でした。

約5年半に渡って成長していくSUZURIと共に歩めたことも幸運でした。

SUZURIは今年(2024年)の4月で10周年を迎えます。おそらくさまざまな取り組みを準備していることと思いますし、これからも進化をしていくサービスだと思っているので、とても楽しみです。

退職する理由

勤務スタイル

ひとつは、「自身の理想とする勤務スタイル」と「会社の勤務体制に関する方針」との乖離が広がっていると感じたことです。

ペパボは2020年6月に「テレワークを基本とする勤務体制」への移行を発表し、そこから数年はフルリモートワークでした。
1年目の年間平均リモートワーク率は96.0%!すごい!!!)

自分はその発表を機に、2020年8月には東京都23区外に引っ越し、愛犬を飼いはじめるなど、生活スタイルが一変しました。 社内のさまざまな方がリモートワークに関するインフラや制度を整備してくださったおかげで、快適にリモートワークをすることができ、そのおかげで自身はオフィスワークよりもリモートワークのほうがパフォーマンスが出やすいということに気づくことができました。

そんななか、2023年2月から、ペパボが属する「GMOインターネットグループ」では出社しての勤務が原則となりました。ペパボにおいても(たしかペパボからの公式な発表はないはずですが)この原則に従う形で勤務しています。また、採用候補者との面談・面接においても「出社しての勤務が原則」であることをお伝えしたうえでコミュニケーションをしています。(職種や等級による出社頻度の目安などはあります、気になる方はカジュアル面談へ!

そのような変化がある一方で、自分の家庭事情はブログに書いた理由でなるべく自宅から離れずに勤務をしたいという想いがあり、リモートワークのほうが自身のパフォーマンスが出やすいと感じていることも含めると、理想とのギャップが広がっていく方向に変化していることを感じていました。

自身はオフィスワークでのパフォーマンスが悪いわけではないし「出社が嫌い」とかでは全然ないので、たらればの話ですが、あのとき引っ越さずに出社しやすい場所に居住しつづけて愛犬も飼わずに別の選択をしていたら、退職には至っていなかったかもしれないですね。

モチベーション

もうひとつは、複合的な理由でモチベーションを維持するのが難しくなってしまったことです。

サービスのユーザに直接的に価値を提供するような機能開発に取り組めていなかったこと、結果としてサービスを自分の手でつくりあげているようなワクワク感が薄れてしまったこと、が大きいかなと思います。

ペパボに入社して丸5年がたった#③プロダクトへの熱の高さに書いたとおり、サービスの開発よりもその運営を支える裏側の機能(決済や会計周り)に取り組むことが多く、サービス自体への熱量は落ちていた自覚があります。まあこれは自分のスキルがもっと高ければ(裏側の機能を片付けつつサービスの開発もバンバンできるくらいのスキルがあれば)良かったのかもしれませんが、実際にはなかなかそううまくはできませんでした。

自分はもっとサービスづくりがしたかったんだなぁという気づきでもありました。

そのほか、さまざまなできごとのなかで、自身のコントロールできる範囲の外側にあるものごとによってモチベーションに影響があるシーンも時にはあり、そういったできごとに折り合いをつけるのが難しかったという面もありました。

3月からLeaner Technologiesで働きます

2024年3月からは株式会社Leaner Technologies(以下、リーナー)で働きます。

リーナーに決めた理由は次の3点です。

  • 尊敬できる同僚
  • 事業領域
  • カルチャー

尊敬できる同僚

一緒に働いたことのある方々がいることは心強く感じました。

  • ペパボにいたころから公私ともに仲良くさせてもらっている @co_bachie さん
  • 副業でお手伝いしていたbosyuを一緒に開発していたことのある @corocn さん、@lulu_lul2 さん、@renyamizuno_ さん

また、技術カンファレンスで何度も発表を見聞きしていた @kokuyouwind さんがいることも意思決定を強く後押ししました。

リーナーは現在社員数が40名程度の会社です。 小規模のチームで密にやりとりをしながらプロダクトを開発していくことになるので、尊敬できる方々がぎゅっと詰まったチームに飛び込めることはとても魅力的に感じました。

そして彼らがフルリモートで働いていて、それを前提としたコミュニケーションができることも安心感がありました。

note.com

事業領域

リーナーは調達購買領域でサービスを展開しているスタートアップです。

「ニッチ過ぎて意味わからん」というのが最初の感想だったんですが、

「この領域に課題を抱えている事業者は比較的大きな規模の事業者だろうな」というのは予想がつきました。 (調達部門があるってことは多くの場合は製造部門をもっているだろうし、その調達に課題があるってことはそれなりの種類や数量の調達をするからこそ課題があるわけで、それはつまり大規模な組織ってことになるのでは、という予想)

過去に「小規模事業者向けのtoBサービス」と「toCサービス(SUZURI)」は経験してきていて、大規模事業者向けのtoBサービスに携わってみたいという思いがあったので、この事業領域にも興味を持ちました。

詳しく話を聞いてみるとおもしろくて、この領域でリーナーが頑張ることによってクライアント事業者にとって大きな価値を生むであろうということが分かったので、チャレンジしたいと感じました。

つくっている人々が、価値のあるサービスだし、もっと価値のあるサービスにしていく、と信じ切っていることにもワクワクを感じました。

カルチャー

Sponsors - RubyKaigi 2023 をみると、リーナーはトップスポンサーをしています。この規模の会社でRubyKaigiのトップスポンサーをやることってあるんですか?(いや、まあ過去にはあるのかもしれないけど)

自分が経営者だったら、いくらRubyにお世話になってるとはいえ、この意思決定できるだろうか?この意思決定をできるのってすごくない?と思いました。

その意思決定をしたCEOがどんなことを考えているのかがよく分かるnoteがあって、これを読んだら心に響いたし、↑の意思決定ができるのも腑に落ちました。

note.com

おわりに

自身の会社員としての節目のタイミングなので、記録としてブログを書くことにしました。文章にしてみたことで考えが整理できた気がします。

2月の休息期間が終わり、気持ちも高まっています。3月からやっていくぞ〜!

SUZURIでの5年間でやったこと

SUZURI Advent Calendar 2023 - Adventar の4日目です。


この記事について話しながらゆるゆるとゲームをしました。

youtu.be


2018年9月にGMOペパボに入社し、SUZURIで働いて丸5年が経ちました。 これまでやったことを1年ごとに記録します。

本題と逸れますが、目次の括弧書きについて。この数字は「自分がつくったプルリクエストのうち該当期間にマージされた件数」です。 この数字を記載しようか迷いましたが、事実として受け止めるために記載することにしました。 同僚の中でも特に尊敬しているエンジニアたち(いまは在籍していない方も含めて)は、年間300〜500件のプルリクエストをつくってマージしています。 もちろん、この件数だけで一概には語れませんが、マージ回数は価値の提供回数だし、価値提供の結果からフィードバックを得て改善サイクルを回すという観点では、多いほうがいいですよね。 自分も年間300件くらいはプルリクエストを出せるようにしたいところです。

2018-09-01..2019-08-31(155件)

発注先工場の追加

入社した2018年9月時点では提携先の工場は1社のみでした。

システムのロジックやデータ構造もそれを前提とした構造になっていました。

サービスの今後の展開として、提携先の工場を複数社に増やしてたくさんのグッズを作れるようにしたかったので、ロジックとデータ構造を見直して、複数の工場に発注できるようにしました。

入社直後でサービスに対する理解もRailsアプリケーションに関する知識も乏しい状態だったのでなかなか大変でしたが、当時の同僚にたくさん頼りながら実装したのを覚えています。 たしか、テストコードの修正箇所がたくさんありました。

スタンダードTシャツのウラ面プリント機能

こういう機能です

もともとオモテ面にしかプリントできなかったTシャツをウラ面にもプリントできるようにした。

こんな感じ。
スリ戸惑い中 / 忍者スリスリくん ( surisurikun )のスタンダードTシャツ通販 ∞ SUZURI(スズリ)

オモテ ウラ
t-shirt-front t-shirt-back

from: SUZURI New Items 2019 - tanaken’s blog

詳しくは↑の記事をご参照ください。

新アイテム「クージー

現在は提供していないアイテムです。 SUZURI X - 2019 春夏ラインナップ ∞ SUZURI(スズリ) という企画で追加したアイテムでした。

クージーって何?という感じだった。

缶やペットボトル飲料を入れて保温保冷するアイテムで、こんな感じ。

https://suzuri.jp/surisurikun/1700791/koozie/m/white

正面 持ってる様子
koozie-front koozie-hold

from: SUZURI New Items 2019 - tanaken’s blog

詳しくは↑をご参照ください。と、言いつつ、

具体的には、円柱形画像変換器として Cylinder というクラスを作り、マグカップの合成処理からこのクラスを使うようにした。クラス内ではとにかく意味のある変数名を定義した。 変数名を定義するのは意外と大変で、そもそも何やっているか分からないと名前をつけることができない。「あ、この height1 は "斜め上から見下ろした時に見えるプリント領域の高さ" のことなのか〜」「あ、この length1 は "円柱形の上面の楕円の、短い方の半径" のことね!」のように、内容を理解しながら名前をつけていった。

特にこのあたりは苦労して工夫しながら対応したので思い出深いです。

2019-09-01..2020-08-31(151件)

新アイテム「ジップパーカー」「きんちゃく」「ビッグシルエットパーカー」「バケットハット」

バケットハット以外については SUZURI New Items 2019 - tanaken’s blog に書いてあるので割愛します。

バケットハットの追加についても、特におもしろエピソードはないので割愛します。

2020年前半ごろまで新アイテムの追加を担当するチームにいましたが、そのあとはチームから離れたのでアイテムの追加にはほとんど関わっていないと思います。

J-SOX

日本版SOX法(J-SOX)」と呼ばれるものがあります。

金融商品取引法」の一部を俗称で日本版SOX法(J-SOX)と呼ぶことがある。証券取引法などを抜本的に改正した「金融商品取引法」では、財務報告の信頼性を確保するために、企業と経営者の義務や責任についても厳しい規制が盛り込まれている。具体的には、経営者は有価証券報告書と併せて「内部統制報告書」を内閣総理大臣に提出しなければならず、その報告書には公認会計士又は監査法人の監査証明をつけなければならないと定められている。

from: 会計・監査用語かんたん解説集:日本版SOX法(J-SOX) | 日本公認会計士協会

当時の社内では、たしか売上規模によって "内部統制報告書" の作成対象事業を決定していて、SUZURIの売上規模が大きくなったために対象事業となった、という話だったはず。 (いまは色々と状況が変わって全サービスでやってるはず)

販売および原価に関する業務フローを明確にして「業務記述書」という文書をつくる必要がありました。

前年までの他サービスの文書はエクセルシートでつくられており、フローチャートWindows PCでしか動作しないアプリケーション(名前は忘れた)で作成されていました。

管理コストが掛かりそうと思ったので、文書はMarkdownに書き換えて、フローチャートはPlantUMLでつくって画像を出力してMarkdownに埋め込むことにしました。これは本当にやってよかった。テキストベースでバージョン管理がしやすくなったので最高になりました。英断。

この提案をしたときに快く受け入れてくれた内部監査室のみなさまには大感謝です。

で、まあこの業務記述書をつくる作業がまあ大変でした、まあ、ええ、大変でした、ええ。

2020-09-01..2021-08-31(158件)

未払金の残高集計

SUZURIはグッズが売れるとクリエイターさんのトリブンが貯まっていき、クリエイターさんがトリブンの振込申請をすると、クリエイターさんの口座にトリブンをお支払いする、という仕組みになっています。

貯まっているトリブンは「SUZURIからクリエイターさんに支払う予定だけどまだ支払っていないお金」、すなわち「未払金」です。

この「未払金」について、経理部門が把握している金額と、SUZURIのシステムで集計した金額が一致しない、という問題が起きていました。(いくらズレていたのかは秘密です)

その不一致の原因を特定するために、また、今後の不一致が発生しないようにするために、

  • これまで毎月経理部門に提出していたあらゆる資料を見直す
  • その資料をつくる際に使われているロジック(SUZURIアプリケーション内のロジック、および、提出書類(エクセル)内で構築されているロジック)を見直す
  • 今後の未払金の残高を詳らかにするために、SUZURIアプリケーション内に新たな集計ロジックとその結果を明細単位で残すためのテーブルを追加する

などの対応を行ないました。

これがまあ、ええ、ええ、大変でした、ええ。

CREチーム本格始動

2020年9月頃からチームメンバーを集め、12月には業務委託メンバーにも参加してもらい、6名チーム(エンジニア4(うち2名業務委託), デザイナー1, PdM1)で動いていました。

from: SUZURI CRE 1年目のふりかえりとこれから - Pepabo Tech Portal

※ 現在では色々と状況が変わって自分がまたひとりでCREを名乗ってなにかをやっていたりいなかったりします。

エンジニアリングリード

2021年3月から「エンジニアリングリード」という職位につきました。 マネジメントの一部を担うエンジニアです。

CREチームを本格始動させた経験は、「ヒトを動かしてチームをつくる」という意味でエンジニアリングリードの練習みたいな感じだったなぁと、いまふりかえると思います。

正式に職位に就いてから、これまでと違う視座・視野のメンバーと関わることも増えて、学びがたくさんありました。

詳しくは エンジニアリングリード1年目を終えて - tanaken’s blog に書いています。

2021-09-01..2022-08-31(246件)

売上集計

企業会計基準第29号「収益認識に関する会計基準」 に従い、SUZURIの "履行義務" について法務部門を交えて再確認したうえで、売上報告の仕組みを再構築しました。

具体的には次の2点を行ないました。

  • 購入者からの決済確定時点で売上計上していたが、商品の出荷時点で売上計上をするように変更した
  • システムからデータをダウンロードして表計算ソフトで集計していたが、システムのロジックで自動集計して集計値およびそれを構成する明細データを記録するようにした

この対応により、企業会計基準に則った数値が出せるようになっただけでなく、毎月売上報告の業務がめちゃ楽になりました。

PayPay決済の追加

PayPayでお買い物できるようにしました。

【6/28 追記】PayPayを使ってお買い物できるようになりましたという忍者スリスリくん ( surisurikun )のジャーナル | オリジナルグッズ・アイテム通販 ∞ SUZURI(スズリ)

モバイルアプリでの挙動がなかなか大変でした。

PayPay決済の場合はモバイルアプリからの購入フローでモバイル内のPayPayアプリを起動させる必要があり、かつ、社の契約の都合上PayPayとの間に別の決済代行会社のシステムが挟まっていて融通が利かない状況となっていました。

モバイルアプリのメンバーにも相談して、結論としてはモバイルアプリから外部ブラウザ(SafariChrome等、端末側で指定されているデフォルトのブラウザ)を起動して決済代行システムの特定のURLに遷移させることで、外部ブラウザからPayPayアプリを起動させることにしました。

ブックマーク機能

ブックマークできるようにしました。

気に入ったアイテムを「ブックマーク」できるようになりましたという忍者スリスリくん ( surisurikun )のジャーナル | オリジナルグッズ・アイテム通販 ∞ SUZURI(スズリ)

SUZURIのフロントエンドはさまざまな技術がつかわれています(ref: 技術スタック)が、新しい画面はReact, TypeScriptで書くことが多いです。

それまでレビューはしてきましたが、自分の開発タスクでがっつりReact, TypeScriptを書くことはなかったので、このブックマーク機能の実装でたくさん触れて楽しかったです。

2022-09-01..2023-08-31(223件)

ITAC

「ITに係る業務処理統制(Information Technology Application Control)」というものがあります。

業務プロセスを実行する際に利用するアプリケーションに組み込まれた統制のことである。入力情報の正確性、エラーデータの修正・再処理、マスターデータの正確性等の評価する

from: ITAC(ITに係る業務処理統制)/オペレーショナルリスクに関する用語一覧|オペレーショナルリスク|デロイト トーマツ グループ|Deloitte

J-SOXの対応の際に作成した販売や原価に関する「業務記述書」について、記載内容の通りに運用ができているかを評価します。

具体的には

  • SUZURIデータベースにおいて「入金済み」となっている注文情報が、決済代行システムにおいて過不足なく「入金済み」になっているか
  • SUZURIデータベースにおいて「出荷済み」となっている注文情報が、提携先の工場から過不足なく出荷されているか
  • SUZURIデータベースにおいて「クリエイターへ支払済み」となっているトリブン情報が、経理部門の振込履歴情報と過不足なく一致しているか

などの確認を行ないます。

関係各所からさまざまな情報をかき集め、SUZURIデータベースの情報を取得し、Access に入れて突き合わせをします。 Accessを利用したのは「突き合わせの方法自体に問題がないか」も監査対象になるためです。(外部の監査法人Accessのファイルごと渡す)

最終的に突き合わせの方法や結果を「調書」として文書にまとめます。これもMarkdownでバージョン管理することにしました。

Amazon Pay決済の追加

Amazon Payでお買い物できるようにしました。

Amazon Payを使ってお買い物できるようになりました | それゆけ!SUZURI計画

モバイルアプリでの挙動がなかなか大変でした(再)。

Amazon Pay決済の場合は、モバイルアプリの WebViewでの決済がセキュリティ上の理由でサポート対象外 となっています。 そのため、Amazonのドキュメントに従い "Secure WebView" を用いた実装が必要でした。

SUZURIのモバイルアプリではWebViewでログインセッションを管理していて決済もWebViewで行なっています。 そのため、Amazon Pay決済の過程でSecure Webviewを開いてもそこにはログインセッションがないので、それを前提として購入フローを安全に完結できるように実装する必要があります。

モバイルアプリのメンバーにも相談して、最終的には zenn.dev にまとめたフローで実装しました。

売上集計の追加実装

Amazon Pay決済およびデジタルコンテンツ販売機能の追加に伴い、売上集計に関連する処理の追加や修正が必要でした。

この辺はまあ、ええ、ガッとやりました。ええ。


5年間をざっとふりかえりました。いろんなことをやってきましたねぇ〜。以上。

PostgreSQLのVALUESコマンドが便利だった

VALUES https://www.postgresql.jp/document/15/html/sql-values.html

結論ファースト

たとえばこんなことができる...!定数テーブルをつくれる、便利。

WITH
prefectures (code, name, group_name) AS (
    VALUES
        ('01', '北海道', '北海道'),
        ('02', '青森県', '東北'),
        ('03', '岩手県', '東北'),
        ('04', '宮城県', '東北'),
        ('05', '秋田県', '東北'),
        ('06', '山形県', '東北'),
        ('07', '福島県', '東北'),
        ('08', '茨城県', '関東'),
        ('09', '栃木県', '関東'),
        ('10', '群馬県', '関東'),
        ('11', '埼玉県', '関東'),
        ('12', '千葉県', '関東'),
        ('13', '東京都', '関東'),
        ('14', '神奈川県', '関東'),
        ('15', '新潟県', '北陸'),
        ('16', '富山県', '北陸'),
        ('17', '石川県', '北陸'),
        ('18', '福井県', '北陸'),
        ('19', '山梨県', '中部'),
        ('20', '長野県', '中部'),
        ('21', '岐阜県', '中部'),
        ('22', '静岡県', '中部'),
        ('23', '愛知県', '中部'),
        ('24', '三重県', '近畿'),
        ('25', '滋賀県', '近畿'),
        ('26', '京都府', '近畿'),
        ('27', '大阪府', '近畿'),
        ('28', '兵庫県', '近畿'),
        ('29', '奈良県', '近畿'),
        ('30', '和歌山県', '近畿'),
        ('31', '鳥取県', '中部'),
        ('32', '島根県', '中部'),
        ('33', '岡山県', '中部'),
        ('34', '広島県', '中部'),
        ('35', '山口県', '中部'),
        ('36', '徳島県', '四国'),
        ('37', '香川県', '四国'),
        ('38', '愛媛県', '四国'),
        ('39', '高知県', '四国'),
        ('40', '福岡県', '九州/沖縄'),
        ('41', '佐賀県', '九州/沖縄'),
        ('42', '長崎県', '九州/沖縄'),
        ('43', '熊本県', '九州/沖縄'),
        ('44', '大分県', '九州/沖縄'),
        ('45', '宮崎県', '九州/沖縄'),
        ('46', '鹿児島県', '九州/沖縄'),
        ('47', '沖縄県', '九州/沖縄'),
        ('__', 'その他', 'その他')
)

SELECT * 
FROM prefectures 
WHERE prefectures.name IN ('東京都', '大阪府')

結論に至った過程

最もよくある使い方

通常は、VALUES は大きな SQL コマンドの内部で使用します。 最もよくあるのは、INSERT での使用です。

INSERT INTO films (code, title, did, date_prod, kind)
    VALUES ('T_601', 'Yojimbo', 106, '1961-06-16', 'Drama');

ですよね。VALUESといえばこれって感じ。

必要最小限のコマンド

必要最小限の VALUES コマンドはこのようになります。

VALUES (1, 'one'), (2, 'two'), (3, 'three');

これは、列が二つで行が三つの表を返します。事実上、これは次と同じことです。

SELECT 1 AS column1, 'one' AS column2
UNION ALL
SELECT 2, 'two'
UNION ALL
SELECT 3, 'three';

へぇ〜〜、便利じゃん!!

FROMのなかでも使える

VALUES は、副SELECTが書ける場所に使用することができます。 例えば FROM 句の中などでも使えます。

SELECT f.*
  FROM films f, (VALUES('MGM', 'Horror'), ('UA', 'Sci-Fi')) AS t (studio, kind)
  WHERE f.studio = t.studio AND f.kind = t.kind;

へぇ〜〜〜〜〜〜。ん、この AS t (studio, kind) って、これ定義できるってこと?

VALUESをFROM句の中で使用する場合には、AS句が必須となることに注意しましょう。 これは SELECT の場合と同様です。 AS句ですべての列の名前を指定する必要はありませんが、指定しておくことをお勧めします。 (VALUESのデフォルトの列名は、PostgreSQLにおいてはcolumn1、column2のようになります。 しかし、他のデータベースシステムでは異なるかもしれません。)

ほ〜〜ん、なるほど!!

なんかこれ WITH句でも使えるような気がするな...

https://www.postgresql.jp/document/15/html/queries-with.html

テーブル名も定義できるし便利なはず!、やってみっか!

で、一番上のクエリ。

愛犬のがんが判明した話

2023年8月、愛犬のラテのがんが判明しました。

愛犬のラテはこちらです:

かわいい


具体的には「リンパ腫」という血液のがんであることが分かりました。

悪性リンパ腫(あくせいリンパしゅ、英語: Malignant Lymphoma、略称:ML)は、血液のがんで、リンパ系組織から発生する悪性腫瘍である。

from: 悪性リンパ腫 - Wikipedia

リンパ腫にもいくつか種類があるようで、ラテは身体の複数箇所のリンパ節が同時に腫れる「多中心型」でした。

特に多中心型では、リンパ節が腫大する以外には症状がでず、動物は元気なことも多くありますが、無治療で経過すると急速に進行し、全身の臓器に浸潤して、元気・食欲がなくなり、最終的には死に至ります。犬の多中心型リンパ腫を無治療で経過観察した場合の生存期間は約 1 ヶ月が平均的といわれています。

from: 犬と猫のリンパ腫 - 北海道大学動物医療センター外科/腫瘍診療科

記事にある通り、本人は元気でただ「身体に腫れたしこりのようなものがいくつかあるね」という感じだったので、当時はまさかリンパ腫(しかも無治療だと生存期間が1ヶ月の病気)だとは思ってませんでした。

早めに発見して病院で治療を開始できたのは不幸中の幸いでした。


現在は定期的な抗がん剤の投与で治療をしています。

使用する薬の種類や投与頻度によっていろいろなプロトコールがある中で、獣医さんと相談して「ウィスコンシン大学(UW)プロトコール」をベースとした治療をしています。

複数の抗がん剤を組み合わせ、初めの 2 ヶ月は毎週、その後の 4 ヶ月は 2 週に 1 回の治療を行います。 全部で 6 か月間の治療期間となり、その後はリンパ腫の再燃がみられるまで無治療で経過観察となります。 通常は治療終了後 3~4 ヶ月で再燃がみられ、治療が再開されます。 多中心型リンパ腫では、1 年生存率 50%、2 年生存率 20%、3 年生存率 10%弱という成績があがっています。

from: 犬と猫のリンパ腫 - 北海道大学動物医療センター外科/腫瘍診療科

抗がん剤の投与に際には動物病院に日帰り入院で預けて治療をしてもらっています。2ヶ月間の毎週の投与が終わり、現在は隔週の投与をしているところです。

最初の1ヶ月くらいで、身体にあったしこりはなくなりました(これを「寛解」と呼ぶらしいです)。

最初は抗がん剤投与の直後に発熱したり、その後も投与の1~2日後くらいは気だるそうにしていることもありましたが(抗がん剤は身体に負担がかかるようです)、今は身体も慣れてきて基本的に元気に過ごしています。

記事にある通り "1 年生存率 50%、2 年生存率 20%、3 年生存率 10%弱" という病気なので、元気なうちにやれることをやっておこう、と、キャンプに行ったりお世話になった人と会ったりしています。

フォトスタジオにも行きました。記念写真、大切にします。

from: instragram

引き続き抗がん剤治療を進めていきます。そのなかで、体調の変化とそれに伴う生活の変化が出てくるかもしれません。

具体的にどういう変化になるかは予測できないことなので、正直不安もたくさんありますが、限られた時間を精一杯たのしく過ごそうと思っています。

人が大好きでたくさんの人に撫でてもらったら大喜びするので、会っていただける方がいたらぜひお声がけください^^

ペパボに入社して丸5年がたった

気づいたら5年経ってました。早いですね。

入社3ヶ月時点で書いていた記事「"ペパボに入って良かった"と思った7つのこと - tanaken’s blog」があるので、この7つの観点で今の状況を記録します。

①コードレビューの心地良さ

『ここのコード、どういう意図があるのかを知りたいです!』という質問をくれます。質問部分にはもしかしたら「本当はこう書いた方がより良いかも?」という思いがあるのかもしれませんが、一旦それを抜きにして、自分のコードに歩み寄ってくれます。


時にはレビューによってちょっと大きめな修正が必要なケースもありましたが、そんな時は理由部分をしっかりと説明した上で『代わりにこうやってみましょうか』という具体案を提案してもらいました。

チーム全体として、引き続きそういう感じで出来てると思います。

自分はその日の調子や状況によってはちょっと棘のある言葉を使ってしまってるかもしれないなぁと心当たりがあるので、より心地良いレビュー環境をつくるために気をつけていかなきゃなぁと思っています。

あと、レビューはスピードも大事だよなと感じています(プルリク出してすぐにレビューをもらえたら、それは心地良さにもつながりそうだし、生産性の観点でも大事)。

いまは基本的に非同期でレビューしてますが、今後は同期的なレビュー(実装者に解説してもらいながらレビューする)もとりいれてみようかなと検討しています。

②技術への熱の高さ

ペパボでは様々な勉強会が様々な頻度で行なわれていますが、特に自分は、毎月開催されているPTF(Pepabo Tech Friday)というイベントがすごく良いなぁと思っています。

引き続き毎月開催されています。毎回5~8名くらいが発表していて、これが継続的に運営できているのは結構すごいことだと感じています。

PTF に関する記事一覧 - Pepabo Tech Portal

外部イベントでの発表も増やしたいですね。ここ1〜2年でのメンバーの入れ替わりもあり、外部カンファレンス(特に各技術のトップカンファレンス)での発表経験者が減っています。

技術的な発信を増やすためにも、メンバー(や自分自身)が技術に集中できる環境をつくっていきたいところです。

③プロダクトへの熱の高さ

自分はSUZURI事業部にいるので、SUZURI事業部のことしか分からないですが、最近でも「状況の変化に合わせてブランドビジョン*1を見直そう」という動きがあり、引き続き高い熱量でプロダクトに向き合えていそうです。

一方で自分自身は、最近はSUZURI自体の機能の開発よりもその運営を支える裏側の機能(決済や会計周り)に取り組むことが多くて、その意味では「SUZURI」というサービス自体への熱量は落ち着いています(対 入社3ヶ月時点 比)。

サービスの観点よりも技術的な観点で、SUZURIのコードベースへの熱量は上がっているかもしれません。

最近はあるテーブルの再構築*2をしまして、これはなかなか熱量がないとできないことだと思うし、やりきった達成感がありました。

④Slackに統一されたオープンなコミュニケーション

入社して3ヶ月経ちましたが、僕はまだ1通もメールを送っていません。 全ての社内のやりとりがSlackに集約されているので、メールを使う必要がないためです。

メールの送信履歴をみてみたら、「外部サービスの検証環境についての問い合わせ」と「研修の外部講師への依頼」の2スレッド(計11通)のみでした。 コミュニケーションが統一されてない環境では働けない身体になっていそうだなぁと感じています。

ここ数年での変化では、GMOグループ横断での共有チャンネルが生まれてグループ内の他社とのコミュニケーションがしやすくなりました(自分はあまりに活用できてないですが)。

⑤行動指針の刷新 〜私たちが大切にしている3つのこと〜

わたしたちが大切にしている3つのこと | GMOペパボ株式会社 採用サイト は引き続き頭において日々過ごしています。

この数年での変化としては、おかげさまで創業20周年を迎えました | GMOペパボ株式会社 にあるように会社のミッションが刷新されました。

「インターネットで可能性をつなげる、ひろげる」

これは2013年に定めた私たちのミッションです。

創業20周年を機に新たなフェーズを目指して、このミッションを変更することにしました。

「人類のアウトプットを増やす」

新たなミッションでは、私たちが提供するプロダクトによって表現や情報発信のハードルを下げ、文学や芸術などの表現、あらゆる情報発信、商品や作品の売買、といったアウトプットを世界中に増やすことを掲げました。

⑥社長からのメッセージ

今年9月の初め、北海道で大きな地震がありました。 そのことはあまり深く考えず、入社したての僕は出勤しました。 すると、Slackの全社チャンネルにあるメッセージが届いていました。社長からです。 そこには次のような内容が書かれていました。

  • 北海道で大規模な地震と停電が発生していること
  • パートナー(社員)自身やご家族で被害にあっていたり安否が分からない場合は上長や人事に申し出てほしいこと
  • 各サービスでお客様のことを想った対応をしてほしいこと

このメッセージに、僕はすごく心打たれました。 僕自身や僕の家族で被害に遭った人はいなかったのであまり深く考えていなかったですが、周りの社員の中には家族の安否が分からない方もいたかもしれません。サービスの利用者の中にも被害に遭われた方がおそらくいたでしょう。

そういうことをすぐに思って社長自らメッセージを発信してくれていることに、僕はすごく感動しました。(と同時にそういう想像力や思いやりを欠いている自分に不甲斐無さを感じました) ペパボの中の人にとってはこれが当たり前の感覚なのかもなぁと思った、印象的な出来事でした。

あぁ、当時はこんな感想を持っていたんだなぁ。感覚としてはもう当然のことのようになっているけれど、改めて大事なことだなぁと感じました。

⑦『のっていき!』の安心感

自分ひとりでは実現できなかったであろうこのイベントが、様々な方の"のっていき"のおかげで実現までこぎつけ、

こういうことが社内でよく発生しているのを見かけます。

自分の最近の経験では、今年の5月中旬から7月末まで新卒13期生の技術研修の運営責任者をやっていたんですが、各研修コンテンツの社内講師のみなさんの「やっていき・のっていき」に大変助けられました。 運悪く、研修が始まったその日からコロナを発症してから6月上旬ごろまで万全に動けない時期が続いたのですが、周囲のみなさんのフォローのおかげで無事に運営することができました。本当に大感謝。

tech.pepabo.com


ふりかえってみると、どれも継続できているとわかったし、新たな観点にも気づけてよかったです。3ヶ月の記録を書いておいてよかったなぁ。今回のこの記録も、数年後に見直したらなにかお得なことがあるかもしれませんね。

*1:SUZURIのブランディングについてはこの記事が詳しいです

*2:明らかに複数のエンティティを1つのテーブルに詰め込みすぎだったので3つのテーブルに分解してデータを移行してコードも全面的にリファクタリングした。これはまた別途記事を書きたいなぁ。

戦略としての...

出社

自分が勤務している「GMOペパボ株式会社」が属する「GMOインターネットグループ」では、今年2月から「原則、週3日出社・週2日在宅勤務」の推奨が廃止され、出社しての勤務が原則となりました。

GMOインターネットグループ、新型コロナ対策完全撤廃に伴い週2日在宅勤務推奨を廃止 | GMOインターネットグループ株式会社

2023年2月21日(火)より、これまで「原則、週3日出社・週2日在宅勤務」を推奨していた出社体制を廃止し、GMOインターネットグループ各社では出社しての勤務を原則としました。なお、より高い成果を出すための「武器」、オフィス賃料を削減しパートナーへ還元するための計画的な在宅勤務の活用は可能といたします。

上述のとおり "高い成果を出すための「武器」" としての在宅勤務の活用は可能となっており、自分はいまのところ週1出社・週4在宅のスタイルで勤務しています。(これは今後変わるかもとは考えていて、いろんな働き方や選択肢を検討しているところです)

出社の頻度は多くないものの(いや、多くないからこそかな)、出社の際には最大限にそれを活かした勤務ができるようにしたいと考えていて、8月は特にそういう動きができた実感がありました。

具体的には、オフィスで発生している立ち話に入り込んで「アプリケーションのちょっと先の未来」について考えを出し合う、カフェフロアで仕事や私生活のことを雑談する、などです。

この数十分〜数時間は、コードも書いてないしデプロイもしてないので、この時間によって直接的に上げた成果はありません。 けれど、中長期的な視点では、将来の成果に間接的な貢献をしてる(することになる)んじゃないかなと感じています。

また、事業部のマネージャー・シニア・リーダーを集めた合宿*1にも参加できて、考えの共有と方向性の目線合わせができたのもよかったです。

言葉

言葉が思考をつくる、という考えを持っています。

ref: A に気をつけなさい。それはいつか B になるから。 - junebox

さっきの出社の話にも関連しますが、最近は職場で「〇〇なので在宅勤務をします、ご迷惑をおかけします」という言い回しをちらほら見かけて、こんなコメントをしたのでした。

自分は、出社も在宅も “より高い成果を出すための「武器」” として活用することが前提とされている、と認識をしています! https://www.gmo.jp/news/article/8236/

なので、在宅勤務に対して「申し訳ないこと」であったり「迷惑をかけること」という感情は持つ必要はないかなと思いました!

あえてこういうコメントをしたのは、この言い回しを当たり前のものとしてスルーしてしまうと、「在宅勤務が迷惑な行為である」という思考を発話者自身とそれ受けた周囲の人々に植え付けてしまう可能性があるな、と感じたからです。

別の例でいうと「お先に失礼します」も自分は進んでは使いません。

よく使われる言葉や言い回しは、その周辺の人々(= 組織)の文化を形成すると考えています。

いまの所属している会社でいうと「ナイストライ!」は言葉がステキな文化を産んでいる一例だなと感じます。そういう言葉を増やしていきたいです。

図解

ものごとの理解度を計る手段として、図を描くことは有用だと感じています。理解していない部分はまったく図が描けないので面白いです。

お仕事のアプリケーション開発のシーンでは、シーケンス図を描くことが多いです。

最近は Mermaid を活用しています。

今年のはじめにお仕事でアプリケーションへのAmazon Pay決済の導入をしたのですが、なかなか複雑だったので、先日それを zenn.dev の記事にしました。

Amazon Pay決済をNativeアプリに導入する場合の一例

実装当時も描いていたんですが、改めて描いてみると当時の理解は違ったな、とか、いまでもここ曖昧だな、といった気づきがあって楽しかったです。


以上、8月のブログでした。

*1:終日会議室で議論しまくる会です