SUZURI Advent Calendar 2023 - Adventar の4日目です。
この記事について話しながらゆるゆるとゲームをしました。
2018年9月にGMOペパボに入社し、SUZURIで働いて丸5年が経ちました。 これまでやったことを1年ごとに記録します。
- 2018-09-01..2019-08-31（155件）
- 2019-09-01..2020-08-31（151件）
- 2020-09-01..2021-08-31（158件）
- 2021-09-01..2022-08-31（246件）
- 2022-09-01..2023-08-31（223件）
本題と逸れますが、目次の括弧書きについて。この数字は「自分がつくったプルリクエストのうち該当期間にマージされた件数」です。 この数字を記載しようか迷いましたが、事実として受け止めるために記載することにしました。 同僚の中でも特に尊敬しているエンジニアたち（いまは在籍していない方も含めて）は、年間300〜500件のプルリクエストをつくってマージしています。 もちろん、この件数だけで一概には語れませんが、マージ回数は価値の提供回数だし、価値提供の結果からフィードバックを得て改善サイクルを回すという観点では、多いほうがいいですよね。 自分も年間300件くらいはプルリクエストを出せるようにしたいところです。
2018-09-01..2019-08-31（155件）
発注先工場の追加
入社した2018年9月時点では提携先の工場は1社のみでした。
システムのロジックやデータ構造もそれを前提とした構造になっていました。
サービスの今後の展開として、提携先の工場を複数社に増やしてたくさんのグッズを作れるようにしたかったので、ロジックとデータ構造を見直して、複数の工場に発注できるようにしました。
入社直後でサービスに対する理解もRailsアプリケーションに関する知識も乏しい状態だったのでなかなか大変でしたが、当時の同僚にたくさん頼りながら実装したのを覚えています。 たしか、テストコードの修正箇所がたくさんありました。
スタンダードTシャツのウラ面プリント機能
こういう機能です
もともとオモテ面にしかプリントできなかったTシャツをウラ面にもプリントできるようにした。
こんな感じ。
スリ戸惑い中 / 忍者スリスリくん ( surisurikun )のスタンダードTシャツ通販 ∞ SUZURI（スズリ）
オモテ ウラ 
from: SUZURI New Items 2019 - tanaken’s blog
詳しくは↑の記事をご参照ください。
新アイテム「クージー」
現在は提供していないアイテムです。 SUZURI X - 2019 春夏ラインナップ ∞ SUZURI（スズリ） という企画で追加したアイテムでした。
クージーって何？という感じだった。
缶やペットボトル飲料を入れて保温保冷するアイテムで、こんな感じ。
https://suzuri.jp/surisurikun/1700791/koozie/m/white
正面 持ってる様子 
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)と呼ぶことがある。証券取引法などを抜本的に改正した「金融商品取引法」では、財務報告の信頼性を確保するために、企業と経営者の義務や責任についても厳しい規制が盛り込まれている。具体的には、経営者は有価証券報告書と併せて「内部統制報告書」を内閣総理大臣に提出しなければならず、その報告書には公認会計士又は監査法人の監査証明をつけなければならないと定められている。
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との間に別の決済代行会社のシステムが挟まっていて融通が利かない状況となっていました。
モバイルアプリのメンバーにも相談して、結論としてはモバイルアプリから外部ブラウザ（SafariやChrome等、端末側で指定されているデフォルトのブラウザ）を起動して決済代行システムの特定の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年間をざっとふりかえりました。いろんなことをやってきましたねぇ〜。以上。
