CREとはなんなのかを考えている

以前から Customer Reliability Engineering (CRE : 顧客信頼性エンジニアリング)に興味があったのだけれどあまり掴めていなくて、最近改めて色々な文章を読んでみた。

自分なりに CRE の輪郭がわかってきたような気がするので記録しておく。

結論

CREとは

顧客の不安をゼロに限りなく近づけるために、課題を把握・計測し、技術的なアプローチでその課題の解決に役立つものを実現していくこと

である。

と、自分は解釈した。

読んだもの

考えたこと、思ったこと

今、この時代において、真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。

Google Cloud Platform Japan 公式ブログ: Google の新しい専門職 : CRE が必要な理由

なるほどこれだな、と思った。

自分は前職でも現職でも、CSチームの方達と協力して業務効率を上げたりお問い合わせに対する技術的な対応をやったり、そういうタスクに普段から取り組んでいて、別に得意というわけではないけど、相対的に他のエンジニアメンバーよりもそういうタスクを率先してやる傾向があるよなぁ、という自覚があった。

でもなぜそういう傾向があるのか、うまく言語化できていなかった。

なんとなく、大事なことだから?とか、困ってそうじゃん?とか、そんな感じだった。

これを読んで、明確に『自分が携わっているサービスにおいて、ユーザが抱えている不安をなくしたい』という思いがあるんだなと認識した。

そして、それをミッションとする職種が存在している、それが CRE である、ということを理解した。

不安は 1 を信頼性で割った数値に等しい

Google Cloud Platform Japan 公式ブログ: Google の新しい専門職 : CRE が必要な理由

これはつまり、「信頼性を高めることで、不安をゼロに限りなく近づけることができる」ということ。信頼性を高めるためにはどうした良いか?という視点で考えると物事の見え方が変わってきそう。

お客様に寄り添い、お客様が今置かれている状況を少しでも良いものにしていくために私たちにできることをおこなっていく、ということが、我々MackerelチームのCREのミッションになります。

セールスエンジニア 改め Customer Reliability Engineer (CRE) になりました - Hatena Developer Blog

CREはその名の通りお客様の信頼、つまり、不安を抱えるお客様に寄り添うことに主眼を置いています。

CREチームを設立しました! | レポート | XFLAG(エックスフラッグ) キャリア採用サイト ケタハズレな冒険を。

CREのミッションは一言で表せば「お客様の抱える不安を払拭すること」です。

CREという組織を作りました|Repro CS Blog|note

「お客様 対 CRE」ではなく、「お客様が抱える不安 対 わたしたち(お客様 and CRE)」という構図なのだなと思った。寄り添うというのはそういうことだな。

その他、総じて書かれていることは、ミッションを達成するために「技術的なアプローチをすること」「データ・ドリブンで行なうこと」。 課題の把握、定量化、施策の実施、効果測定、などが共通するキーワードだなと感じた。

おわりに

これまで CRE に対して曖昧な理解のままその単語の表面だけを眺めていたけれど、自分なりの解釈と定義をしてみることで腹落ちした。

「自分のやりたかったこと、これなのでは?」感がすごくある。

まだまだ脳内が整理できていないけど、自分の中にひとつの筋道というか、軸のようなものが生まれた手応えがあるので、常にこれを意識しながら過ごしていきたい。

2020年は CRE をやっていく。

API Client の rubygem を作ってみた

これを作った。

GitHub - tanaken0515/cotoha-ruby: COTOHA API client for Ruby

中身について詳しくはここに書いた。

[自然言語処理 初心者向け] COTOHA API を Ruby で使いたくて gem を作りました - Qiita

この記事では作るに至ったきっかけや作りながらのお気持ちなどを記録しておく。

作るまでの話

去年、自分 gem についてよくわかっていないな〜と思って勉強し始めた。

勉強といっても、公式ドキュメントに書いてある通りに実際に作ってみる、というだけの話だけど。

一人でやっても鳥が少ないので、みんなで学びたいな〜と思って2019年9月から社内勉強会(全8回)を開催した。

読んだドキュメントはこの辺。

いくつかの gem のコードリーディングもした。

この勉強会を経て、同僚の harashoo さんが https://github.com/harashoo/fujitatsu (詳しくは はじめての自作Gem - シンプルなGemを作成して公開する - Qiita 参照) を作ったり、

自分自身も https://github.com/tanaken0515/suri_lang (詳しくは 忍者スリスリくんの影武者を作っている - tanaken’s blog 参照) を作るなど、アウトプットにつながったので良い感じだった。

gem 作るの簡単だし楽しいな〜、という気持ちになっていて、なんとなく「次は API Client の gem を作りたいな〜」と思っていた。

作るきっかけの話

直近半年くらいは自然言語処理に興味があって scrapbox に調べたことをまとめたり、方言をテーマにして鹿児島Ruby会議01で発表したりした(発表の中身はほぼディープラーニングの基礎、みたいな内容になってしまったのだけど)。

そんな中 Qiita で↓の記事を読んでCOTOHA APIの存在を知り、この API の Client gem を作ることにした。

「メントスと囲碁の思い出」をCOTOHAさんに要約してもらった結果。COTOHA最速チュートリアル付き - Qiita

脱線するけれど、この記事を書いた youwht さんは自然言語処理関連の楽しい記事をたくさん書いてくださっている。

個人的に特に好きなのは

で、記事の構成がうまくて文書が面白いのに加えて、試行錯誤して物事を進めていく様子がすごく勉強になった。

記事を読んだ時の感想を残していたので貼っておく。

作ってるときの話

そんなこんなで COTOHA API の Client gem を作ることにしたのだけど、API Client を作ったことがなかったのでまずは参考になりそうなものを探した。

真っ先に思い浮かんだのは RubyKaigi 2019 で発表されていた @sue445 さんのこの資料。

この資料と、この資料で紹介されていた https://github.com/asonas/chatwork-ruby , https://github.com/sue445/pixela のコードを読み、「キーワード引数を使う」「独自のエラークラスでwrapする」などを取り入れた。この発表に関しては同僚の @tsummichan さんが RubyKaigi2019 Vol.2 - ペパボテックブログ に分かりやすくまとめてくれている。

実装の全体的な方針は同僚の @shimoju_ さんが作った https://github.com/shimoju/metabase-ruby を参考にした。読みやすくてありがたかった。

作ったあとの話

実装したあと Qiitaの記事 を書いたら、↑で紹介した youwht さんからコメントを頂いて嬉しかった(自分の記事内に youwht さんの記事のリンクを貼ったから通知がいったのかも?)。

COTOHA API の Slack コミュニティでこの gem を紹介したら「この界隈Pythonが多くてRubyの記事は個人的にとても嬉しい」「これからRubyで使ってみようかと思っていたので助かります」といったコメントをもらえて嬉しかった。

作ってよかった。

この gem の todo は直近2つある。

1つ目は未対応のエンドポイントに対応すること。「固有名詞(企業名)補正」「音声認識」「音声合成」のエンドポイントがあるんだけど、有料の for Enterprise プランに申し込まないと利用できないので、現時点(cotoha v0.2.0)では対象外としている。動作確認できないけど実装だけしようかなぁ、というところ。for Enterprise プラン、月額13万なんだよなぁ、、、。最初の3ヶ月無料とのことだけど、契約期間の縛りは無いのかな?などの調査を含めて todo だな。

2つ目はコードコメントの整備。なんも書いていないので質素な感じになってる。 https://www.rubydoc.info/gems/cotoha

適宜やっていきたい。


せっかくだからこの gem を使ってなんかやりたいな。アイデア待ち〜。

おしまい。

「50日間連続AC」の実績を解除した

f:id:tanaken0515:20200225201415p:plain

2020-01-07 から「1日1AC」と決めて毎日続け、今日 2020-02-25 で「50日間連続AC」を達成した。

f:id:tanaken0515:20200225201444p:plain

なるべくABCのC問題を解くようにした。

疲れている日はB問題を解いた。

Ruby の様々なメソッドを知ることができた。

なんとなく頭がやわらくなったような気もする。


キリが良いので、ここらで「1日1AC」を引退しよう。

2月から新たにお仕事(いわゆる副業?複業?)を始めて、脳みそと体力をそちらに注ぎたい気持ちが強くなった。

技術を学習する時間や自身のふりかえりの時間を確保するのも大事。2月はそれができてなかった。

「やること」「やらないこと」を決めて時間をうまく使っていこう。


「1日1AC」は引退しても、AtCoderは続けていく。

引き続き会社の「競プロランチ会」には参加していくし、週末のコンテストも暇さえあれば参加するつもり。

別にまったく競プロ強くないけど、楽しいんだよなぁ。

「AtCoder Beginner Contest - C問題」を使って学びのある記事を書けそう

chokudai さんがこう言っていて、確かにそうかもなぁと思った。

C問題を瞬時にキレイなコードで解けるようになると、業務コードも良い感じになるのかもしれない?(そうとは限らないけど)

で、自分はどうなのか?というと、なんとも判断ができない。

読みにくいコードは書かないように気をつけているつもり。回答速度が重要な競技プログラミングだけれど、

  • 意味のある変数名を考えてつける
  • 分離可能な処理はメソッドに切り出す

この2点は意識してやっている。 自分は短期記憶能力が極めて低いと思っているので、これやらないと自分が何やっているのかすぐに分からなくなってしまう。

自分なりには「そこそこ読みやすいな〜」と思いながらやっているけど、自分以外の人の視点で「キレイなコード」なのかは分からない。(「キレイなコード」の定義も人それぞれっぽいけど)

この疑問を解決するには自分のコードを自分以外の人に読んでもらう必要がある。

すでに GitHub には push してあるから誰でも読めるようにはなっているけど、もっと読みやすいコンテンツとして用意した方が良さそうだなぁ。この問題をどう解釈したか、とか、コードを書きながらどんなことを考えていたか、とか、もっとこう書けばよかった、とか。そういうのを書いた方が読み応えがありそうだし自分にとっても学びがありそう。

あと chokudai さんがこういうことも言っていて

ああ、他の人のコードをあまり読んでないなぁと思ったし、自分と同じように他の人のコードをあまり読んでない人はそれなりにたくさんいるだろうなと思ったので、「自分以外の人はこんなふうに解いていたよ」という感じでコードを貼り付けて解説してみるとコンテンツとしての価値が上がりそう。

「コード長」「実行時間」「メモリ」で sort できるから、それぞれのトップの提出コードを読んで解説してみると良さそう(読みやすいコードではないかもしれない。特にコード長が最小のやつ)

記事を書く場所はどこがいいだろ。内容的に Qiita が良いかなぁ。ここよりも幅広い人に学びを共有できそうな場所に投稿したいな。

ruby-jp slack で ActionText の質問に答えた

ruby-jp.slack.com | ruby-jp#support チャンネルで ActionText に関する質問があったので調べて答えた。 ActionText はまだちゃんと触っていなかったので、調べるきっかけになってよかった。

質問内容

rails6の ActionTextrich_text_area について質問したいです!!! has_rich_text を使ったフォームで Create するとエラーが出てしまいます( Update では正常に更新できます)。

エラー文
SQLite3::ConstraintException: NOT NULL constraint failed: articles.body

models/article.rb

class Article < ApplicationRecord
  has_rich_text :body
  validates :title, presence: true
  validates :body, presence: true
end

そのほか views と controllers のコードも貼り付けてくれていた。

調べたこと考えたこと

ActionText か〜。まだ触ってないな〜。と思ってまずRailsガイドをみた。

railsguides.jp

読んでみると

リッチテキストコンテンツは独自のRichTextモデルに保存され、このモデルはアプリケーションの既存のあらゆるActive Recordモデルと関連付けられます。

と書いてあるから、今回のケースで言うと Article モデルの body フィールドの実体は RichText モデルに保存されるってことだな。

つまり articles テーブルには body カラムは必要ない、ということだ。

で、質問のエラー文をみてみると NOT NULL constraint failed: articles.body とある。

ん、これは articles モデルに body カラムがあるってことだなぁ。

てことは body カラムを作る migration をしたのだろう。

そして質問者さんは「この body カラムをリッチテキストにしたい!」と考えて has_rich_text :body をつけたのだろう、と想像した。

さらに質問を読み返してみると

フォームで Create するとエラーが出てしまいます( Update では正常に更新できます)。

とある。

Create ができないのに Update ができる、とはどういうことか。

というか Create ができないのに、その Update の対象になっているレコードはどうやって作ったのか。

おそらくそのレコードは has_rich_text :body をつける前に作成したのだろうなと思った。 has_rich_text :body をつける前に作成したレコード( body カラムが not null なもの)であれば、has_rich_text :body をつけた後に Update しても not null 制約に掛からないのでエラーにならない。

回答

以上を踏まえて次の3点を回答した。

  1. 「もともと Article モデルにあった body カラムを rich_text にしようとしているのかな?」と推測したよ
  2. body カラムの実体は RichText モデルに保存されるから articles テーブルには body カラムは不要だよ
    • articles テーブルの body カラムを消す migration をすれば Create のときもエラーじゃなくなると思うよ
  3. Update がうまくいくのは has_rich_text :body をつける前に作ったレコードだからだと思うよ

質問者さんの反応は

推測通りです!笑 DBをRollbackし、Articleモデルからbodyを削除してMIgrationしたらエラーが消えました!

あってた。わーい。

めでたし。

ではない。

重ねて質問させていただきたいのですが、 bodyをnull: falseにしたい場合は、どうすればよろしいのでしょうか?

ですよね。

has_rich_textに指定したフィールドのnullを禁止するには

ActionText::Attribute をみると has_rich_text の引数は name だけでオプションは指定できない。

null を禁止したければカスタムバリデーションを書くかなぁ、と思った。

質問者さんの Article モデルを書き換える形で書くと、こんな感じかな。

class Article < ApplicationRecord
  has_rich_text :body
  validates :title, presence: true
  validate :body_required

  private
  def body_required
    errors.add(:body, "is required") unless body.body.present?
  end
end

body.body.present? となるのがなんとなく見栄えが悪いけど仕方ない。 なぜなら Ariticle モデルのフィールドとしての body は RichText モデルへの relation であり、 RichText モデルは body フィールドを持つので body.body になってしまう。

Article モデルのフィールド名を変えて body 以外(例えば content など)にするとこの見栄えの悪さを解消できる。

class Article < ApplicationRecord
  has_rich_text :content
  validates :title, presence: true
  validate :content_required

  private
  def content_required
    errors.add(:content, "is required") unless content.body.present?
  end
end

Action Text の概要 - Railsガイド の例でも content というフィールド名を使っているのでなんとなく良さそう。

思ったこと

ruby-jp 基本的には眺めているだけだったけど質問したり答えたりできる場があるのは便利だなぁと思った。

あと ActionText について調べるきっかけになってよかった。

おしまい。

更新情報

2021-02-19

最後のコード例でのtypoを修正しました

class Article < ApplicationRecord
-  has_rich_text :body
+  has_rich_text :content
  validates :title, presence: true

なぜ競技プログラミングを楽しいと感じるのか

最近競技プログラミングを始めた。

まだ始めたばかりだが、なんだか楽しいなぁ〜、と感じている。

なぜそう感じるのか。

この問いに対して「競プロは『正解』があるから楽しいのでは?」説がある。

お仕事の話

年末に同僚とこんな話をした。

  • 普段お仕事をする中では、明確な『正解』を定義できないことの方が多いと思う。
  • その中で僕らは「正解とは言い切れないけど『だいたいよさそう』と思える範囲」に物事を持っていくためにお仕事をしている。
    • 『正解』というPoint(点)ではなくてArea(範囲)だよね
  • そしてその「『だいたいよさそう』と思える範囲」を決めることもお仕事。
  • つまり普段のお仕事で僕らはすごく高度なことをしているのでは。

なんとなくこの話がしっくりきた。

普段のお仕事って、結構疲れる。

「もっとこうした方がいいかな?」「あれをするともっと良いかも?」「そもそもやりたいことってなんだっけ?」

考えることがたくさんある(量)し、ずっと考え続けてる(時間)。

で、考えた末にやったとしても、「『だいたいよさそう』と思える範囲」に入るかどうかは分からないし、その範囲に入ったとしても、本当に良いことだったのかは分からない。

「不確実性」というやつかな?

お仕事が疲れるのは、そういう中でお仕事をしている(= すごく高度なことをしている)からなのかも、と思った。

その意味では、お仕事が疲れるのは健全なことかも。「仕事疲れた〜!」「いいじゃん!!お疲れ!ビール!!!」で良いなぁと。

競技プログラミングの話

一方で、競技プログラミングは明確な『正解』がある。

その正解に向かって、問題を解くためのコードを書けば良い。

あと、問題の状況が明確に定義されていることも、お仕事の現場とは大きく違うなぁと思った。(お仕事は状況の把握だけでかなり大変)

そう考えると競技プログラミングはずいぶんと「簡単なこと」に思える。

問題や正解を定義することなく「解くこと」だけに集中できる場は意外と少なくて、

『俺はいま解くことに集中しているぞ〜〜!うぉおおー!!』

というだけですでに楽しいし

『よっしゃ提出だ!WJ... どきどき... !』『うわっ、WAだ!』『なにっ!?TLEだと!?』『ヨシっ!AC!』

と、機械的に正解不正解を判断してくれるのも楽しいんだと思う。

お仕事へのヒント

競技プログラミングのエッセンスをお仕事に活かすことを考えてみる。

まずは「解くこと」だけに集中できる場を作ってみることかなぁ。

普段は「解くこと」と並行して「問題の定義」や「正解(よさそうなArea)の定義」を考えている気がするので、そこをしっかり分けること、かなぁ。

他にはなんだろ。よさそうかどうかの判断を機械的に(≒定量的に)できるようにすること、とかかなぁ。

競プロ、楽しいので継続的にやってみる

もともとプログラミングテスト・コーディングテストの類がすごく苦手で、前職で社内スキル調査の一環としてテストを受けた時1つもできなくて情けない気持ちになったことがある。確か計2時間くらいのテストだったんだけど、他のみんなは1時間くらいで数問を解いて業務に戻るなか、自分は2時間きっかり頑張って1問も解けなかったので「なんかもう無理...」となった。これが3年くらい前の話。

それ以降、この類のことは避けてきたんだけど、さすがにエンジニアとして人並みにはこういうこともできるようになりたいなぁという思いはずっとあった。

そんな自分が競プロを始めたきっかけは、社で開催されたバーチャルコンテストだった。

AtCoderの使い方やコンテストの説明(未経験者向け)・雑談 のあと、バーチャルコンテストを開催するよ〜、という感じでハードルを下げてくれていたので参加しやすかった。

とはいえ苦手意識があったので、雑談までやってAtCoderのアカウントを作ったら、コンテストは参加せずに様子を少しだけ見て帰ろう、と思っていた。

けどコンテストの1問目をみると「与えられた3つの数字のうち小さい2つを足した結果を出す」くらいの問題があって、あ、こんな簡単なやつもあるんだ、と解き始めていた。

一度やり始めてしまうと面白くて、いまは社で毎週開催されている競プロもくもくランチにも参加している(主催の @purple_jwl さんに感謝)。

引き続きやっていこうと思う。

SUZURI New Items 2019

この記事は SUZURI Advent Calendar 2019 - Adventar の22日目の記事です。

2019年の1年間で SUZURI には10種類の新アイテムが追加され、7種類の既存アイテムがリニューアルされた。

  • ✨Tシャツ: 両面プリントに対応 (01/17)
  • ✨パーカー: 両面プリントに対応 (01/21)
  • ✨ロングスリーブTシャツ: 両面・両袖プリントに対応 (04/02)
  • 🆕アノラックパーカー (04/02)
  • 🆕ウォッシュTシャツ (04/02)
  • 🆕クージー (04/02)
  • ✨リンガーTシャツ: ボディリニューアル (07/01)
  • 🆕ウエストポーチ (07/08)
  • 🆕ジップパーカー (09/25)
  • ✨パーカー: サムネイル画像リニューアル (10/28)
  • ✨スウェット: サムネイル画像リニューアル (10/30)
  • 🆕きんちゃく (11/07)
  • 🆕ビッグショルダーバッグ (11/07)
  • 🆕ビッグシルエットパーカー (11/27)
  • 🆕ビッグシルエットスウェット (11/27)
  • 🆕グラス (12/05)
  • スマホケース: 仕上がりリニューアル (12/18)

抜け漏れないかな?たぶん大丈夫。

この記事では自分が開発に携わったアイテムについて、作りながら考えていたことやいま改めて思うことを書いていこうと思う。

✨Tシャツ: 両面プリントに対応

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

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

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

両面プリントに関しては、すでに対応済みのコーチジャケットの実装があってそれを参考にしながら実装したので、大きな技術的課題はなかった。

ただ、新アイテムを追加するのは初めての経験だったので仕様の理解(そのためのコードリーディング)にかなり時間をかけたなぁ、という記憶がある。

あとTシャツは他のアイテムと比べてサイズの種類が多い(Mens S~XXXL, Ladies S~L, Kids 90~160)ため、単純にその分手間が掛かった。 実はこの時、単にウラ面に対応しただけではなくオモテ面画像のリニューアルも行なっていて、それも合わせると結構大変だった(特にデザイナさんは作業が多くて大変だったと思う)。

実装しながら思っていたことは、なんかこれミスったら影響でかいよなぁ〜、ということ。TシャツはSUZURIで一番売れるアイテムだから。リリース後に変な問題が起きないように、っていうのを一番考えていたかもしれない。問題なくリリースできて良かった。

案の定めちゃくちゃ売れて8月4日には2019年の累計受注枚数が10万枚を突破した。 pepabo.com

よくわからないけど10万枚はすごそう。
10万といえば10まんボルトだから、きっとすごいと思う。

🆕クージー

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

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

NINJA BEER / 忍者スリスリくん ( surisurikun )のクージー通販 ∞ SUZURI(スズリ)

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

円柱形のアイテムなのでクリエータさんがアップロードした画像を円柱形に合成する必要があった。

円柱形の合成処理は既存アイテムのマグカップにもあったが

  • 再利用できる形に切り出されていない
  • 変数名が length1 , height1 等になっていて可読性が低い

という問題があって、まずはこれを解決するためのリファクタリングをした。

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

クージーの実装でもこの Cylinder クラスを使い、良い感じに実装することができた。

正直クージーの実装を担当することに決まった時はめちゃくちゃ不安だった。
「円柱形の合成処理なんて分からんわ〜」という感じだったし、参考としてマグカップの合成処理を読んでも「なるほど(全くわからん)」という状態だったのでヤバかった。

心折れそうだったけど「読んでるうちに理解できるはず」と信じて読み続けていたらだんだんと分かるようになってきたし、「途中までだけどここまで分かったかも」というのを誰かに聞いて欲しくてそれを聞いてくれる(&適宜良い感じの質問をくれる)仲間がいたのでなんとか乗り越えることができた。

(様子) koozie-yousu

この Cylinder クラスは最近リリースされたグラスにも活用されていて、あ〜実装しておいてよかった〜と思った。

ある冬の日 / 忍者スリスリくん ( surisurikun )のグラス通販 ∞ SUZURI(スズリ)

アングル1 アングル2
glass-1 glass-2

✨リンガーTシャツ: ボディリニューアル

デザインを印刷するTシャツ自体のことを「ボディ」と呼んでいる。 SUZURIのディレクター陣は常に面白いアイテムや良さそうなアパレルを探していて、この時は「今のやつよりも良さそうなシルエットと質感のリンガーTシャツを見つけたからリニューアルしよう」という話になった。

Yes. I am a NINJA. / 忍者スリスリくん ( surisurikun )のリンガーTシャツ通販 ∞ SUZURI(スズリ)

旧ボディ 新ボディ
ringer-t-shirt-black ringer-t-shirt-sumi

画像を差し替えて合成処理のパラメータを調整し直すだけなので、技術的に難しい課題は特になかった。

ただ今回はボディ差し替えと同時にカラー変更(旧ボディの4カラーを全て廃止し、新カラーに変更)も行なったため、旧カラーを表示したいシーン(買ったもの一覧画面など)でエラーにならないように、旧ボディの画像が表示されるようにする対応も必要だった。カラーによって合成処理を切り替えることで旧ボディも表示されるようにした。

ちなみに新カラーはスミ、バーガンディ、ジーパンブルー、ヘザーグレーの4種類で、個人的にはこの2色が好き。

ジーパンブルー ヘザーグレー
ringer-t-shirt-jeansblue ringer-t-shirt-heathergray

🆕ジップパーカー

その名の通りジップがついているパーカーのこと。個人的には、ジップがついているものを「パーカー」と呼ぶのだと思っていた節がある。(ジップがついていないパーカーのことは「ジップがついていないパーカー」と呼んでいた)

スライス / 忍者スリスリくん ( surisurikun )のジップパーカー通販 ∞ SUZURI(スズリ)
Jingu / 忍者スリスリくん ( surisurikun )のジップパーカー通販 ∞ SUZURI(スズリ)

オモテ ウラ
zip-hoodie1-front zip-hoodie1-back
zip-hoodie2-front zip-hoodie2-back

もともとSUZURIではパーカーのことを「フーディ」と呼んでいたけど、このジップパーカーのリリースを機に見直されたりした。

what-is-hoodie

🆕きんちゃく

小物を入れるきんちゃく袋。

ズッキュンズッキュン / 忍者スリスリくん ( surisurikun )のきんちゃく通販 ∞ SUZURI(スズリ)

グレー ベージュ
kinchaku-grey kinchaku-beige

合成の調整が難しかった。単純に画像を乗せるだけでは質感や色合いがうまく表現できないので、ざらつき感を出す加工をしたり色合いを調整した。

リリース後に、蛍光色を使ったデザインを合成すると微妙な感じになることが発覚し、どうしようかな〜と悩まされた。

社内ドキュメントに「こんな感じでやるといいかも?」とメモを残して私用で休暇に入ってしまったのだが、次に出勤した時には仲間がその感じで修正してリリースしてくれていた。ありがたかった。

🆕ビッグシルエットパーカー

ビッグなシルエットのパーカーのこと。

the page you were... / 忍者スリスリくん ( surisurikun )のビッグシルエットパーカー通販 ∞ SUZURI(スズリ)

オモテ ウラ
big-hoodie-front big-hoodie-back

(たまたまこの商品はウラ面のデザインがないけど、両面にプリント可能)

ビッグシルエットパーカーを触りがなら実装していた。

すごくふわふわで気持ちよかった。

この気持ち良さを合成で伝えたかったんだけど、なかなか難しかった。たぶん買ってない人には、このふわふわさは伝わっていないんじゃないかなぁ、と思う。

リリース当時もこんなこと言ってた。

まとめ

自分が実装に携わったのは以上の6アイテムだった。

改めてふりかえってみると、チームメンバーの仲間に大いに助けられてリリースすることができたのだなと感じた。

2020年もSUZURIは新しいアイテムの追加やリニューアルをたくさんやると思う。

楽しみ。