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:終日会議室で議論しまくる会です

ビールがうまい2023ふりかえり夏

ビールはいつもうまいんですが、最近特にうまいのでふりかえりをします。

定期的な運動

運動をするとビールがうまいです。動かした身体に染み渡るように感じます。

毎日朝晩1時間ずつの愛犬との散歩が習慣になっていて、気持ち良いです。愛犬よ、いつまでも元気でいてくれ。

2023年からはテニススクールに通い始め、毎週1時間半のレッスンを受けています。妻も自分も、学生時代(妻は中学、自分は高校)テニス部に所属していたので経験者ではあるのですが、大学以来ずいぶんとテニスをやっていなかったので、スクールでコーチにあれこれ教えてもらいながらテニスをするのはとても新鮮で楽しいです。もっと上達したいですね。

散歩とテニスで週15時間以上運動をしている(散歩2時間 x 7日 + テニス1.5時間)ので、ビールがうまいです。

体調不良からの回復

5月15日に発熱し、その後検査を実施したらコロナ陽性と診断されました。誕生日に発症するなんて、なかなかのプレゼントですね。 発熱の様子は バースデー発熱2023 - tanaken0515 に記録しました。40度近い発熱が4日連続で出て驚いたしツラかったです。 咳と痰がひどくて、3週間くらいつづきました。

やっと治ったと思ったら、今度は細菌性の肺炎に罹りました。こちらはコロナと違って治療薬(抗菌薬)を処方いただけたので、回復への安心感がありました。とはいえ、発熱症状の改善から咳と息苦しさの解消までは2週間くらい要しました。

そんなこんなでやっと7月になって回復した身体を手に入れたのでした。

健康を噛み締めながら飲むビールはうまいです。

余談

以上、ふりかえりでした。健康な身体で運動して飲むビールはうまいですね。

ここからは完全に余談で、この記事を書くにあたって、iPhoneのアルバムアプリの検索枠に雑に「ビール」と書いてみたら、ちゃんとビールに関連する画像が一覧表示されました。便利。

さらに、今年の写真だけに絞り込みたかったので「ビール 2023」で検索してみると、それっぽい結果が出ました。

左上の写真だけビールじゃないな?と思い、見てみると

原材料名の「ビール酵母」と賞味期限の「2023」を検知してるんですね。

ビールの画像認識と画像内の文字認識の技術が使われてるんだなと知りました。今後も便利に活用できそう。

なにかを漏れなく被りなく検討するときにやっていること

なにかに取り組むときに「漏れなく被りなく思考・検討できているか?」を知りたくなる(あるいは他者から問われる)ことがあります。

そういう時に自分はこの手順で整理することが多いです。

  1. 対象を分解するための「観点」をリストアップする
  2. それぞれの「観点」に対して取り得る「選択肢」をリストアップする
  3. 「観点」と「選択肢」のすべての組み合わせをリストアップした表をつくる
  4. 表の各行に対して深掘りする

実際にやってみる

やったほうがわかりやすいと思うので、ここでは

SUZURIにおけるグッズの注文」

を対象として雑にやることにします。

1. 対象を分解するための「観点」をリストアップする

注文について検討するので「買う人」と「売る人」がいそうですね。

注文時の状況も考えてみましょう。SUZURIが「セール」を開催しているかもしれません。買う人はお得な「クーポン」を使うかもしれません。

これらを踏まえて、ここでは「観点」として次の4つを挙げることにしましょう。

  • 買う人
  • 売る人
  • セール
  • クーポン

2. それぞれの「観点」に対して取り得る「選択肢」をリストアップする

先ほどの4つの観点に対して、どういう選択肢がありそうかを考えてみましょう。

買う人

SUZURIで販売されているグッズたちは、ふらっと訪れて購入することもできるし、会員登録をしたうえで購入することもできます。つまり、次の2つ選択肢があります。

  • (買う人が)ゲストである
  • (買う人が)会員である

売る人

SUZURIでは、様々なクリエイターさんがグッズを販売しています。そういったグッズの中から好きなものを購入できますし、自分自身でデザインしたグッズを購入することもできます。つまり、これも2つ選択肢があります。

  • (売る人が)買う人と異なる
  • (売る人が)買う人と同一である

セール

SUZURIでは、運営によって時々セールが開催されています。開催中に買うとお得です。

  • (セールが)開催中である
  • (セールが)開催していない

クーポン

SUZURIから会員に向けてクーポンが配布されることがあります。クーポンを使うとお得です。

  • (クーポンを)使用する
  • (クーポンを)使用しない

3. 「観点」と「選択肢」のすべての組み合わせをリストアップした表をつくる

手順の1と2を整理すると、このようになります。

4つの観点で2通りずつの選択肢があるので全部で 2 x 2 x 2 x 2 = 16 通りですね。

これをすべて書き出すとこうなります。

4. 表の各行に対して深掘りする

最後に、各行について深掘りをします。 深掘りの内容はケースバイケースですが、ほとんどいつもやるのは次の2つです。

  • 発生し得るかどうか?をYes/Noで記載する
  • 備考にメモを残す

今回の例でやってみた様子がこちらです。

たとえば、SUZURIは会員登録をしないとグッズを販売できない仕様になっているので、「買う人 = ゲスト, 売る人 = 買う人と同一(=ゲスト)」というのはあり得ません。なので CASE 5~8 は「発生する? = No」です。

効能

この手順でやると自分がどこまで理解できていてどこでミスった(いまいちな検討内容になった)のかがわかるので便利です。

「観点」のリストアップ(手順1)で指摘された場合は、向き合う対象のことを理解できていない可能性が高いので、詳しい人に話を聞くことが有効でしょう。

「選択肢」のリストアップ(手順2)で指摘された場合は、「観点」に対する有効な切り口を発見できていないかもしれません。たとえば今回の例では「買う人」という観点に対して「ゲストである」or「会員である」という選択肢を出しましたが、ほかにも "同じメールアドレスを使って何回買っているか” という切り口で「1回だけ買った」or「2回以上買った」という選択肢にすることもできるかもしれません。

(手順3は組み合わせをリストアップするだけの機械作業なので、この手順に指摘はないはず。)

各行に対しての深掘り(手順4)で指摘された場合は、実際どうなるのかに対する認識や想像力が足りていないと考えられます。実状に詳しい人に話を聞くと良いでしょう。

手順4までいくとCASE番号を指しながら会話ができるので、認識の齟齬が発生しにくくなります。これも便利ですね。

おわりに

取り組む対象が複雑になってくると頭のメモリだけでは限界がきます。そういうときに今回の手順は有効だと思います。

加えて、お金や法律に関わる取り組みの場合は小さなミスが大きな問題に発展する可能性があるので、全体像を把握してミスの発生を最小化するためにも有効だと感じています。

このブログを書くにあたってつくったGoogle スプレッドシートを(キャプチャの通り、大したことはしてませんが)一応貼っておきます。

なにかを漏れなく被りなく検討するときにやっていること | tanaken's blog - Google スプレッドシート