食べチョク開発者ブログ

食べチョクエンジニアによるプロダクト開発ブログ

デザイナー間での桃色の共有化と改善による成果

こんにちは、松久です。

今年も「桃」の季節になりました。
食べチョクでは、昨年に引き続き「夏の桃ラボ」と題して、色々な桃を味わえる特集をしています。デザインチームは、桃の特集を今年も実施するだろうと予想し、2 月頃から準備をしてきました。

品目毎の色パレットを作る

準備したのは、品目毎の色パレットを作ることです。
きっかけは、「桃やぶどうのような同じ品目でバナーを作る前に事前準備したこと」で紹介した品目毎の特集の色の管理で良かったことを徹底し、できなかったことを減らしたい気持ちからでした。

数人のグラフィックデザイナーでバナーなどを作るときに、それぞれが色を検討すると時間もかかりますし、色もなんだかバラバラになっていきます。また「食べチョク」らしさというのも揃えにくいことを感じていました。

Starbucks Creative Expression」を参考にして、品目毎のカラーパレットを作ることにしました。「Starbucks Creative Expression」は、スターバックスを利用するお客様の体験のため作られたクリエイティブに関する事例の集まりになっています。

GGitHub issue に要件をまとめつつ検討を開始し、グラフィックデザイナーが中心となって、Figma 上で形にしていきました。 昨年の制作物を活かしつつ、他の色ともバランスをとって作っていくことができました。

GitHub issue を用意して、目的や取組方法の案を書き始めました

Figma で制作を始めて色の配分なども含めて検討

実際に作ってから

2 月末ぐらいから始めて、4 月末ぐらいには夏頃の品目について準備ができたので制作を担当したグラフィックデザイナーから、デザインチームの他メンバーへ共有しました。 社内で運用している esa に色のページを設けてメルマガなどでも使えるように周知を始めました。ここは、去年は取り組めなかったことなので、適用できる範囲を広げることができました。

バナーと特集ページを作ってから、esa で色の共有を始めました

運用を始めると、足りないこともわかってきました。
例えば、グラデーションはどうするか?ありなのか?なしなのか?色だけじゃない表現サンプルは必要なのか?などが話題にでました。もっと良くするための話ができたのは、次回に向けての大きな収穫でした。

おわりに

「桃色」のパレットを作ったのでデザイナー間で「桃色」が共有化できていることを感じています。共有化したことで、足りないところも見つけることができました。 気づいた足りないことも、今後埋めていくことで「食べチョク」の改善を進めていきます。

Figmaプラグイン「Google Sheets Sync」を活用したSNS投稿用画像生成

こんにちは松久です。

生産者さんだから知っている そのままおいしい野菜の食べ方」が先日発売されました。本には生産者さんからの知恵が色々掲載されています。そこで、生産者さんが本の紹介をX(旧Twitter)やInstagram で投稿しやすいように、生産者さんごとの投稿用画像を用意することになりました。

この本には生産者200名ほどの方が掲載されています。そのため、生産者さんごとに掲載されているページや、品種・品目の情報がある画像を用意する必要があります。そこで、Figma の「Google Sheets Sync」を使って投稿用画像を生成することにしました。

導入までの流れ

作成までの全体の流れは以下のとおりです。

  1. Figma でテンプレートを作る
  2. 表示するデータを用意する
  3. Figma に「Google Sheets Sync」を入れる
  4. 実行

Figma でテンプレートを作る

Figma で画像を生成するためのテンプレートとしてコンポーネントを用意します。 コンポーネントを作るときに、レイヤー(Groupなど)の名前に #producer_name というふうに # を頭につけ、Google スプレッドシートの項目と一致させる必要があります。 データを入れたあとのことを想定し、文字数などでレイアウトが変わることもあるので、AutoLayout を使う必要があります。

コンポーネントを作ったら、生成が必要な分のインスタンスを作ります。

表示するデータを用意する

生産者さんのデータを用意するために、Redash を利用しました。デザインチームも SQL を書いたら利用できるようになっています。 本の掲載ページ数や、品目・品種については Google スプレッドシートに入れてもらうことにしました。

画像もいれることが出来ます。画像は、公開されているURLで Google スプレッドシートに記載します。今回は、Redash で 画像の URL も生成して用意しました。

Google スプレッドシートのデータを作るときに1行目は、Figma のレイヤー名と合わせる必要があります。ただし、# は抜きます。 準備ができたら、Google スプレッドシートの共有のURLを取得してください。URLは「リンクを知っている人」全員に「閲覧権限」を付与します。

Google スプレッドシートにデーターを入れている様子

Figma に「Google Sheets Sync」を入れる

Google Sheets Sync」を開き、Plugin をインストールします。

プラグインを実行して生成する

これで準備は整いました。あとは実行のみです。

  1. Google Sheets Sync(プラグイン)を起動
  2. Google スプレッドシートの共有リンクを入力して、 Fetch & Sync を押します

少し時間がかかりますが、200枚ほどの画像は生成されました。

おわりに

ダミーデータをいれる時に便利なプラグインなのですが、テンプレートを用意して大量の画像生成もできます。 Figma のプラグインは大変便利なので、普段から使ってみることで急な依頼でも対応できる方法を思いつくことがわかりました。ツールを使いながら「食べチョク」の改善を進めていきます。

宣伝

Amazon などで販売中です。

食べチョクでは Ruby3.3.1 + YJIT の運用を開始し、サイトが10%高速化しました

皆さんこんにちは、ビビッドガーデンCTOの西尾です。

食べチョクでは2024年5月23日より、Ruby3.3.1とYJITの運用を開始しました。 その結果、サイト全体のレスポンスが10%ほど高速化されましたので、詳細をご報告いたします。

サイト全体のパフォーマンスが10%高速化

以下は食べチョクの商品詳細ページのパフォーマンスです。

商品詳細ページのパフォーマンスが10%高速化

食べチョクはECサイトであり、商品詳細ページが最もよく見られるページとなっています。 このページのレスポンスが150〜160msだったところが、140ms程度まで改善しました。

最もよく見られるページが10%高速化したことは、すなわちサイト全体のパフォーマンスが10%高速化したということです!

商品一覧ページのレスポンスも改善

商品一覧ページのレスポンスも改善しました。 もともと300ms近くだったレスポンスタイムが、Ruby3.3.1 + YJITの導入により250〜270msまで改善しました。

商品一覧のパフォーマンス

ただし、食べチョク社内ではGETレスポンスタイムを200ms以下にしようという取り組みを続けており、このページのレスポンスタイムはまだ満足のいくものではありません。 引き続きパフォーマンス改善に努めてまいります。

導入にあたり発生したあれこれ

YJITの導入は以前から社内インフラチームで検討しており、Ruby3.3系になったら導入しようと計画していました。 しかし、Ruby3.3.0では動作が不安定になるという問題が発覚したため、導入を見送っていたのがあります。

この問題の関連Issueは https://bugs.ruby-lang.org/issues/20085https://github.com/ruby/ruby/pull/9371 です。

2024年4月23日にリリースされたRuby3.3.1でこの問題は修正されましたが、今度はbootsnapに関する不具合が発覚し、Railsが立ち上がらないという問題に直面しました。 関連Issueは https://bugs.ruby-lang.org/issues/20450 です。

このコメントにあるようにパッチを適用することでRuby3.3.1でも動作するようになりました。 具体的には以下コマンドでRubyのインストールをしなおしました。

rbenv install -v --patch 3.3.1 < <(curl -s https://raw.githubusercontent.com/havenwood/rvm-1/696d4f652864109a0cffff62e30a9e405fb0636a/patches/ruby/3.3.1/fix_bootsnap.patch)

パッチを当てることでRuby3.3.1でも動くようになったのですが、このままパッチをあててまで本番リリースするのか、急いでリリースしなくても次のリリースまで待てばいいんじゃないの? といった声はメンバーからあがりました

ただ、今回はYJITを有効化するとサイトのパフォーマンスが10%向上する! みたいな記事をちらほらみかけ、Rubyを変えるだけでパフォーマンスがあがるんだから導入しない理由はない! という話をしたところ社内エンジニアの納得も得られたので、Ruby3.3.1 + YJIT導入に踏み切りました。

パフォーマンスがあがるといったわかりやすい理由があると、バージョンアップのモチベーションにつながるのだなと感じました。

まとめ

Ruby3.3.1 + YJITを有効化することで、食べチョクのパフォーマンスは10%高速化しました。 Railsを使っている皆さまも、ぜひYJITの導入を検討してみてください。

これからも食べチョクのさらなるパフォーマンス改善に取り組んでまいります。

デザインチームの成長を加速する!内省(リフレクション)の技術

こんにちは、松久です。

各自で「ふりかえり」をして、人事評価がされます。 私も「ふりかえり」をするのですが難しいです。適切な「ふりかえり」だったのかわからず、手探りで行うことが難しく感じます。 そこで「ふりかえり」をどうやっているのか、まとめてみました。

ふりかえりとはなにか

経験したことを身につける(自分の知恵)にすることです。 反省する(過ちを認める)ことが「ふりかえり」ではないです。

経験したことを身につけるというのは、以下の3つのステップに分解できそうです。

  • 認知:知った・(他者から聞いて)知っている
  • 行動:使った
  • 結果:成功・失敗

経験とは、知ったことをもとに行動し結果を知った状態になることとします。 自分の知恵にするには、これらを「抽象化」して「次の行動を決めること」が必要になります。

経験したことを身につけるための「ふりかえり」は3ステップになります。

  1. 経験の確認
  2. 経験を抽象化をする
  3. 抽象化したことから、次の行動を決める

目標とふりかえりの関係

目標は「成果(結果)」のための「行動」を設定しています。 目標で設定した行動をして成果(結果)がどうだったか確認し抽象化して次の行動を決めるまでが「ふりかえり」となります。

抽象化するということは、認知にも繋がります。認知になると、次の経験のためのスタートになります。 そのため、目標をたてたら、ふりかえりをすることで循環させていく取り組みになっています。

ふりかえりをする

ふりかえりをする前に

ふりかえりは、具体から抽象を引き出して、具体にしていきます。また、過去に何をしたのか確認する工程があるので、思い出す時間も必要となります。 そのため、おさえておくと良さそうなポイントは以下のとおりです。

  • 落ち着いた時間を確保すること
    • なにかをやりながらは、ダメ
    • 細切れな時間ではなく、ある程度続けた時間であることが理想です
  • 疲れているときにはしない
    • ネガティブなことばかりになりがち
    • 反省になってしまう

実際にふりかえりをする

何をして、どんな事が起きて結果どうだったかを確認します。 サンプルを用意してみました。

何をしたか?から始めて、次の行動まで書き出してみる

  • どんな行動をしたか?
    • LPを作った
  • どんな事が起きたか?
    • 期日に間に合った
    • CSS を書く時にクラス名の命名で困ったが解決方法がわからなかったままになった
    • CSS 変数の便利さがわからなかったが、便利な場面に出会った

行動して起きたことを書き出したら、抽象化をしてみます。 抽象化の前に、出来事の原因を探します。そこから抽象化をしてみます。

  • 起きたことを抽象化する
    • 期日に間に合ったのはなぜ?
      • デザイナーさんとレイアウトが見えてきた時点でマークアップを始めたから
        • 抽象化 => 手戻りの可能性がない部分を明確にすることで、開発着手を早めてスケジュールの短縮に繋がる
      • デザイナーさんと進捗の共有をしたから
        • 抽象化 => 初期段階で関連ステークホルダーとコミュニケーションを取り、進捗を共有することで、手戻りの可能性を減らしたから
    • 解決方法がわからなかったままになった
      • なんとなくで命名して解決してしまった <= 見返しポイント
    • 便利な場面に出会った
      • 何度か使ってみていたから出会えた <= 見返しポイント

抽象化から、行動を書き出してみます。 「行動」はカタチに見える行いを「行動」とします。 例えば「考える」だと何か具体的なカタチに見えるものがないので「行動」とは呼びません。

  • 次の行動を決める
    • 期日に間に合ったのはなぜ?
      • 自分ができるところから着手を始めて、後で変わるのか、変わらないのかを把握する
      • 把握するためにも、ステークホルダーと進捗の共有を毎日する
    • 解決方法がわからなかったままになった
      • 次の行動なし <= 見返しポイント
    • 便利な場面に出会った
      • 次の行動なし <= 見返しポイント

書き出したものを見返す

ここで、もう一度見返します。行動のところから見返していきます。

見返すポイント
  • 上手くいったのはなぜ?系
    • 「リリースできた」「100%以上の達成をした」時は、なぜ出来たか?要因を探ります
      • 要因を定着させることを次の行動にします( Keep となる行動をみつける )
    • 200% の成功になるには何が足りなかったかを探るのも出来そうです
  • わからなかった系
    • わからないときに、なにもしないのはなぜか?を探ります
      • わからないんだったらどうする?はエマージェンシーリーダーシップがあるか?のポイントになります
      • どこまでわかって、何がわからないのか探ります
  • わかった系
    • 本当にわかった?わかったことを広げられない?を探ります
    • わかったあとに、定着を目指す行動がないかを探ります
  • 行動しなかった時
    • なぜ行動しなかったんでしょうか?を探ります
      • 「体調を悪くしていた」などやむを得ない事情もあります
      • 他の急ぎがあった時は、別なことの行動のふりかえりをします
        • ただ、OKR 以外のことが発生した理由を探るのもアリです
    • サボった、という話であれば、とにかくやる、時間の使い方の配分を検討します
  • 実は問題ではなかった
    • 問題だと思っていたけれど、誰も困っていない時は、問題ではないことに気づいた、とします

上記のようなふりかえりの見直しをして、抽象化と次の行動を書き出して「ふりかえり」とします。 抽象化は、「他でも起こせること」「ベストプラクティスをつくる」「教訓」などと言い換えられそうです。 起きたことから気づいたことを抽出するようなイメージです(インサイトを見つけるとも言えそうです)

ふりかえり方法のまとめ

ふりかえりは3ステップです。

  1. 具体:経験の確認
  2. 抽象:経験を抽象化をする
  3. 具体:抽象化したことから、次の行動を決める

上記の流れで、具体と抽象を行き来するので、時間も必要となります。 落ち着いたまとまった時間を確保して行うことをおすすめします。

おわりに

「ふりかえり」について具体的にどうすればいいのかデザイナーに説明することがあり、実例で書き出してみました。 書き出してみてから「ふりかえり」をしてみると、抽象化が大切になっていると実感しました。

個人の「ふりかえり」をすることで、個々人の学習を組織に広めて「食べチョク」の改善を進めていきます。

参考書籍

トイルを減らすデザインチームの行動

こんにちは、松久です。

日々の"業務"の中には、手作業が定期的に必要で、必要だけれどデザインチームでなくてもいいし、サービスの変化とともに増えていることに気づく業務があります。こうした業務を「トイル」と呼んで減らすようにしています。

トイルとは何か

Google がサイト信頼性エンジニア(SRE)の指標の1つとして「トイル」を挙げています。詳しくは「SRE の原則に沿ったトイルの洗い出しとトラッキング」で紹介されています。

トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。

デザインチームでのトイルの例としては次のようなのがあります。

  • キャンペーンにまつわる色々な表示作業
  • 定期的なバナーの変更
  • 動線の変更

こうした業務をデザイナー以外のチームが取り組みたいタイミングで実行できるようにしたり、できるだけ自動化や管理画面からの操作が可能なるようにしました。 このような取り組みをするのは、「トイル」を減らすことで制作時間を確保するためや、担当している部署でコントロールすることを増やすために行います。

トイルに変化する仕事

最初にトイルの影響をきちんと計測したいと思ったのですが、計測する作業時間をどれぐらい使うのか悩み、結果取り組んでいません。

検討にしたなかで、最初から「トイル」だとわかっている仕事よりも、突然だけれど定期的に発生することもあるトイルな仕事に変化していくことに気づきました。 デザインチームではキャンペーンの取り組みがあり、その時は、急ぎで、1回限りの取り組みになることが多いようです。キャンペーンが好評だと、キャンペーンの一部が継続する仕事になり「トイル」となっていくのが多いようです。

また、トイルな仕事を減らすためには、システム化することが求められ、エンジニアとの協力も必要でトイルが溜まっていくこともわかってきました。

トイルを減らす

バナー作成をデザイナー以外でも作成する運用をはじめました」は事例の1つです。 自動化ではありませんが、文字変更や写真差し替えであれば、デザインチーム以外でも出来る状況を作り、分担しました。

システム化が必要なトイルは、私自身が開発をして減らすことにしました。 自動化ではないですが、管理画面から表示変更できることを増やしました。ルールが多いものも、ルールを簡易化する話をして開発を進めています。社内から問い合わせがある記事などに使う画像のリサイズも、管理画面でフォーマットを用意することでリサイズ作業を減らすことをしました。

上手くいかなかったこととしては、名刺作成の自動化です。 自動化を試みて上手くいかなかった理由には「表示要素で変わるレイアウトがあり、パターンが多い」「依頼量が多い月と0件の月がある」などがありました。それらを踏まえると、外部にお願いしたほうが最終的には割安そうという結論になりました。まだ外部にはお願いしていませんが、どこかで外部にお願いする想定です。自分たちで自動化するのではなく、外部にお願いする解決手段もありそうです。

おわりに

手作業の多いデザインチームで、気づくとトイルな仕事が増えていることがあります。トイルを減らしキャンペーン自体がやりやすくなるようにすることはもちろん、新しい取り組みの時間を確保することにつながります。「食べチョク」の改善が進みやすくなる状態を引き続き目指していきます。

デザインチームに新メンバーを迎えるオンボーディングのくふう

こんにちは、松久です。

昨年(2023 年)、デザインチームに新しいデザイナーが加わりました。新しいデザイナーがすぐ活躍しやすいようにオンボーディングを実施しました。

デザインチームでのオンボーディングとは

デザインチームでのオンボーディングが久しぶりなので、改めてオンボーディングの目的を定めました。

  • 入社してきた人が、早く実力を発揮しやすくすること(自分がチームでやっていけそうという感覚を手に入れる)
  • 入社している人が当たり前と思っていたことを改めて確認する機会になること

目的を「入ってくる側」「受け入れ側」の 2 つに分けて、オンボーディングの実施計画を用意しました。

受け入れ側のオンボーディングの目的は、ドキュメントにもなんもなっていないことを言語化してみることで、説明できる状態を目指しました。また、そもそも「当たり前」と思っていることについて、指摘をもらわないと気付けないことが増えているという認識で「指摘をもらおう」と心がけました。

入ってくる側のオンボーディングは、受け入れ側が「お手並み拝見」にならず、チームでやっていける手応えを 3ヶ月で持ってもらい、チームメンバーとして活躍できている状態を目指すことにしました。

オンボーディングでの「お手並み拝見」については下記を読み参考にしました。

fujii-yuji.net

チームで成果を出すためには、環境や仕組みは大切な基盤です。理想には至らないですが、この機会にできる限りのことをしました。

事前準備できたこと

オンボーディングに合わせて、いくつかの事前準備をしました。準備は大きく分けて、下記の 3 つです。

  • 情報の整理
  • ツールの準備
  • 活動のガイドライン

具体的には下記のような取り組みをしました。

ドキュメント(esa)を整備しました。

過去に書いて古くなったものを更新したり、削除したりしました。散乱しているのもあったので、ディレクトリーも整備しました。ただ、今も見つけては整備していますが、一度整備したので、だいぶ楽です。 あと、ブログも役立ちました。過去にチームで何をしたのか、ブログに書いておいて良かったです。

アカウントに関する情報確認をしました。

エンジニア向けのアカウント準備手順はあったのですが、デザイナー向けはない事に気づいてドキュメントにしました。Adobe のことや素材集など、デザイナーしか使わない情報は足りていないことに気づき、書き起こしたり更新したりしました。

Figma のデータを少し整理した。

ファイル名とか、過去の制作物とかを整理しました。 整理していて、Figma の group や section の良い名前の付け方の方針などがあると良いかもと気づきました。今回はそこまではできていません。

習慣になっていることについて言語化した。

他の会社でもやっていそうだけれど、ちょっと違うかも、ということについてドキュメントを更新し、改めてチームに説明をしました。改めて説明をすると「そうだった、そうだった」と形骸化していないか確認する機会になりました。

事前準備できなかったこと

事前準備したかったのですが、できていない点も有ります。 「食べチョク」らしさについてまとめることができませんでした。最も根幹なところですが、言葉にしきれないところがあり、まとめられずでした。

オンボーディングの成功のための 3 ヶ月目標

事前準備の 1 つが、新しいチームメンバーの 3 ヶ月目標です。 新しいチームメンバーが、なるべく早く活躍してほしいとは思いつつ、ある程度の時間は必要です。そこで、オンボーディングの期間を 3 ヶ月(100 日後)として、段階的に活躍の場を広げるような目標設定をしました。

  • 1 ヶ月目:会社やチームメンバーの理解
  • 2 ヶ月目:経験のある業務で何かしらの成果を出す
  • 3 ヶ月目:チームへの提案

目標設定をする方法については下記を読み参考にしました。

achamixx.com

周りのことを知ってもらい、活動をした結果の影響範囲が時間を経て広くなるように目標を設定し、達成した状態を共有しました。

3 ヶ月目標達成のために支援する活動

目標を設定して終わりにせず、目標達成のために、いくつか準備をしました。

1on1 の実施

最初の月は、私と毎週 30 分実施して話し相手となるようにしました。 また、デザインチームのメンバーともお話をする機会を作り、人となりを知ってもらう時間を作るようにしました。その後、チーム外の人とも 1on1 をすることで、「会社やチームメンバーの理解」を促進できるようにしました。

デザインチームのモットーの定義

デザインチームは、フルリモートの人も多くいるチームなので、個別で動いてしまうことが多く、チーム感に欠けやすところがあります。そこで、活動のモットーを決めて、2 日に 1 回はチームに言うことで、どんなことを大切にしているのか全員で合わせるようにしました。

Slack で広い領域に伝えられるような施策をお願いする

知ってもらうためにも、色々なチームメンバーに知ってもらえるような施策をお願いしました。入社された人のことを知ってもらう機会となりました。

他にも、デザインレビューを一緒にすることで、「らしさ」を共有したり、普段使っているツールや命名のクセなども知ってもらいました。

おわりに

チームに入ってくれた人が早く活躍してくれるためにも、オンボーディングをキッカケにして足りていないことや、日頃の業務をやっている理由を改めて確認できました。 まだまだ至らないことも多いですが、オンボーディングをキッカケにチームが大きくなることで、「食べチョク」の改善が進みやすくなるようにしていきます。

「ふりかえり」から始まる2024年デザインチームのカイゼンプロジェクト

こんにちは、松久です。

先月、デザインチームで 2023 年の「ふりかえり」をはじめました。はじめて、1 ヶ月経ちますが、まだ終わっていません。終わっていませんが、なかなか良さそうだと感じています。

「ふりかえり」をすることにした理由

2023 年は、チームでの「ふりかえり」をしてきていませんでした。してこなかった理由はいくつかあります。

  • 「ふりかえり」からのカイゼン行動ができていないことがあるため
  • デザイナーが複数のチームで活動しており、そのチームでの「ふりかえり」を重視した

目の前の期日がある仕事を優先してしまうので「ふりかえりをした」で終わっていました。カイゼンの実施まで辿り着くことが出来ないので、デザインチームの「ふりかえり」は、しばらくしていませんでした。

再び「ふりかえり」をした

今回、再び「ふりかえり」をしています。 理由は、いくつかありますが、人が少し増え、目の前のこと以外も取り組めそうだったからです。本当に取り組めるかは、「ふりかえり」をしないと始まらないからです。「ふりかえり」で決めた改善策を実行できるなら「ふりかえり」の意味が出てきますし、改善できていないモヤモヤした気持ちを抱えなくてすみます。

行った「ふりかえり」の方式は KPT に似ていますが、出来たところ、自慢したいところを出すことと、上手くいかなかったところを書き出し、次のアクションを 1〜2 つ決めて半年の間で取り組むことにしました。

KPT について詳しくは「これだけ! KPT」を参考にしています。

「ふりかえり」は、何度かに分けて実施しました。社員の人もいれば、業務委託契約の人もいて、稼働している時間が異なるための対策です。契約は異なりますが、デザインチームであり、同じコトに向かっている一員なので、できるだけ参加してもらうようにしました。

Miro に書き出した「ふりかえり」の項目

長い期間を対象としたふりかえりなので、多くの項目があがりました。 いきなりまとめるのではなく、出てきた項目 1 つ 1 つについて、じっくり話すことにしました。問題を色々な人が見て、把握して、根本解決を目指すのか、早く気付けるようにするなど予防策があるのかを検討できるのはチームらしい取り組みです。

問題と解決・改善策を並べて、なにを GitHub issue にするのか決めたときの Miro の様子

おわりに

今回は「ふりかえり」をしたところで終わっています。まだ改善策を実施するところまでは出来ていません。時間がかからなさそうなのは、GitHub の issue にして、実行していくことにしました。 「ふりかえり」から「食べチョク」の改善を引き続き実行していきます。