食べチョク開発者ブログ

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

FigmaとSCSSで色の定義を合わせるための運用方法

こんにちは、松久です。

食べチョクでは、デザインツールとして Figma を使っています。色の定義を Figma の Color Styles で管理しています。 管理はしているものの SCSS には反映できていない状態でした。このままだと何が管理されている色なのかエンジニアとデザイナーの認識が揃わなくなります。そこで、Figma の Color Styles と、SCSS で用意した色の変数を合わせられる状態を作っていくことにしました。

色を定義するまで

1 年前ぐらいに UI の色の定義の再確認をして、一部曖昧なところは残りつつも SCSS の変数の定義をしました。 決まっていない部分があったままだったのですが、最近、未確定部分も定義して運用されはじめました。

SCSS の色の変数をまとめる

当初、variable.scss ファイルに色の定義だけではなく、いろいろな変数がまとまっていました。 今後、@use を使うことを想定して、役割ごとのファイルに分割しておくことにしました。また、Stylelint などで指摘するときも、どのファイルを確認すると良いか伝えやすくなることを配慮しました。

Stylelint で色の指摘をする

定義済みの色を直接指定しようとした場合は、Stylelint のプラグインを作って指摘することにしました。 定義済みの SCSS を json にすることも検討しましたが、追加や変更することは多くないので、そのまま書きました。

const stylelint = require("stylelint");
const ruleName = "tabechoku/use-ui-color";
const messages = stylelint.utils.ruleMessages(ruleName, {
  reject: (color, definedColor) =>
    `${color}${definedColor} が定義済みです。定義されているSCSS変数を利用してください。`,
});
const meta = {};
const colors = {
  "#ffffff": "$color-gray0",
  "#fff": "$color-gray0",
};
const ruleFunction = (primary) => {
  return (root, result) => {
    const validOptions = stylelint.utils.validateOptions(result, ruleName, {
      actual: primary,
    });
    if (!validOptions) {
      return;
    }
    root.walkDecls((decl) => {
      const matched = decl.value.match(/#.*/);
      if (!matched) {
        return;
      }
      const definedColor = colors[decl.value.toLowerCase()];
      if (definedColor) {
        stylelint.utils.report({
          ruleName,
          result,
          message: messages.reject(decl.value, definedColor),
          node: decl,
        });
      }
    });
  };
};
ruleFunction.ruleName = ruleName;
ruleFunction.messages = messages;
ruleFunction.meta = meta;
module.exports = stylelint.createPlugin(ruleName, ruleFunction);

指摘されるのがうっとうしい

Figma の Inspect に表示されるのをコピペすることが多く、Stylelint に指摘されるのはうっとうしく感じそうです。

「/ Primary/$primary2 /」から$primary2が使われていることがわかる

Figma の Inspect では Color Style が使われているところには定義名が表示されるので、SCSS の定義名と合わせて気付けるようにしています。 理想は、Zeplin のように Inspect に変数名で表示されることですが、できないのが残念です。あとは、Prettier にフォーマットしてもらう方法もあるのですが未着手です。

おわりに

Figma の Color Style で定義した色を運用するために、Stylelint で指摘することにした話でした。まだ問題はありますが、いろいろな色が実装されることは減らすことができました。

個々のデザイナーの力をより発揮しやすくする取り組みをすることで「食べチョク」の改善に向き合っていきます。

今年もやります!! RubyKaigi 2023の"Local Food Sponsor"。長野の絶品食材をご堪能あれ

こんにちは。プロダクト開発チームの Engineering Manager 兼 人事の @hirashun です。

今年もビビッドガーデンはRubyKaigiに"Local Food Sponsor"として協賛します。Rubyコミュニティと長野の地に感謝を込めて、地元長野の絶品食材をお届けします!

産直通販サイト「食べチョク」が「RubyKaigi 2023」にLocal Food Sponserとして協賛。当日収穫した新鮮なりんごなど長野県のこだわり食材を会場で配布。|(株)ビビッドガーデン/食べチョクのプレスリリース

昨年に続き、やっていきます!

利用率No.1の産直通販サイト「食べチョク」を開発/運用するビビッドガーデンではリリース当初からバックエンドをすべてRubyで開発しており、ユーザーに迅速なサービス提供ができる恩恵を最大限にあずかっています。

昨年スポンサーとしてRubyKaigiに初参加しコミュニティの熱の高さととそこに薪をくべ続ける価値を再認識しました。ビビッドガーデンとしても引き続きRubyとそれを支えるコミュニティに貢献し続けたいと考えています。

そしてRubyKaigiは開催される都市自体を楽しむお祭りでもあります。その土地の魅力を伝えることも大事なポイントです。

昨年は想像以上に反響があり、多くのRubyistに三重の魅力とおいしさをお届け出来たという実感がありました。 感想を教えてくれた皆さん、お話させていただいた皆さん、本当にありがとうございました!

ビビッドガーデンとしては活動の継続に踏み切りました。やっていく!

より多くの人に楽しんでもらいたい

オフライン参加の方だけでなく、オンライン参加の方にも楽しんでいただけるように、以下の2つのスポンサー内容を準備しました。

  • 日替わりで長野の食材を会場にて配布
  • 長野の特産品を抽選で毎日5名の方にプレゼント

それぞれ説明していきます!

日替わりで長野の食材を配布します

昨年は大変多くの方に楽しんでいただきました!

が、反省として「初回の休憩ですべて配りきってしまう」「秒で売り切れる」というのがありました。 なので今年は1.5倍です。より多くの皆さんに届けたいと思います!

Day1「幻の林檎」ピンクレディ®︎とフリーズドライセット

シャンパンのような食味、重厚感のある食感。
懐かしさと新しさのハイブリッド。
ぜひお召し上がりください。

安曇野ファミリー農産へのレビュー・商品:長野県|食べチョク|産地直送(産直)お取り寄せ通販 - 農家・漁師から旬の食材を直送

Day2「食べる宝石」有機ドライほおずき

見た目もかわいく、ビタミンA、ビタミンCやビタミンB群のイノシトール、カロテン、鉄分などが含まれ、
いわゆる「スーパーフード」と呼ばれて注目されています。
見ても良し、食べても美味しいほおずきはきっと皆さまをとりこにするでしょう。

百笑農房へのレビュー・商品:長野県|食べチョク|産地直送(産直)お取り寄せ通販 - 農家・漁師から旬の食材を直送

Day3「最終日にうれしい」たっぷり野菜が溶け込んだ玄米入り無添加スープ

種をまいて畑で実った野菜を丸ごといただく感覚を味わってほしいと思います。
食欲がないときや風邪気味のときにもおすすめです!

のらくら農場へのレビュー・商品:長野県|食べチョク|産地直送(産直)お取り寄せ通販 - 農家・漁師から旬の食材を直送

是非毎日お越しください!ブースで待ってます。

長野の特産品を抽選で毎日5名の方にプレゼント

その場ではお渡しが難しいけどこれだけは味わってほしいという長野の逸品をいずれか1品プレゼントします。 オンラインの方にもお届けできればと思い、Twitterで応募、その後当選された方に食べチョクを通じて生産者さんより直接発送します!

一例を載せますが・・・

トロリとろける信州サーモン
ナガノパープル&シャインマスカットの宝石箱
信州白馬豚燻製詰め合わせ

欲しい。

こちらは3日間、毎日当たります!ぜひご応募いただければと思います。

応募方法は「食べチョク開発部アカウントのフォロー」と「会期中に #rubykaigi と #食べチョク を付けてツイート」です。

twitter.com

RubyKaigiの感想、欲しい食材等、思い思いのつぶやきをお待ちしております。
※当選された方には食べチョク開発部アカウントよりDMをお送りさせていただきます
※対象者はRubyKaigiに参加している方とさせていただきます
※本当に当たります!届きます!

おわりに

RubyKaigiが終わった後も、長野の生産者の方々が作ったこだわり食材に思いを馳せていただけると幸甚です。
気になった方がいましたら是非こちらを覗いていってください。
https://www.tabechoku.com/areas/nagano

ビビッドガーデンは「生産者のこだわりが正当に評価される世界へ」というビジョンのもと、一次産業の課題解決を推し進める会社です。
引き続きRubyをはじめとした技術を活用しながら、日本中の生産者の方々のこだわりがより多くの人に伝わるように、プロダクトを改善し続けようと思います。

ビビッドガーデンのことが気になりましたらこちらも是非ご覧くださいませ!
https://note.com/vividgarden_corp/

それでは皆様、当日スポンサーブースもしくはTwitterにてお会いしましょう!

バナー作成をデザイナー以外でも作成する運用をはじめました

こんにちは。松久です。

キャンペーン、ニュースリリース、LINE など様々な場面で使われる画像は、デザイナーのみが制作していました。デザイナーだけで制作するには限界があり、作成の一部をデザイナー以外でできるようにする取り組みを行っているお話です。

画像を作成することが増えてきた

いろいろな施策が実施される体制になり画像の作成数が増えてきました。 急ぎの画像作成も増加し、一ヶ月間で UI 以外のデザイナーの取り組みの半分が画像作成になっていることもあります。 種類、目的が複数種あり、以下のような画像を作成しています。

  • サイトトップのバナー
  • ニュースリリースの画像
  • LINE のリッチメッセージ
  • LINE のリッチメニュー
  • 各種広告
  • メルマガ

キャンペーンとなれば、これらの画像の作成が必要となります。 キャンペーンではなくても、普段の運用でも必要となる時があり、デザイナーでは作成しきれない量が発生している状態です。

発生した問題

デザイナーだけでは作成しきれないため、いくつかの問題が発生しました。

  • 開始したいタイミングに間に合わない
  • 制作期限がはっきりしているので他の施策よりも優先順位が上がり、プロダクトについての施策の優先順位が下がる

そこで、マーケティング担当の方や、いくつかの部署の方に画像を作ってもらうことにしました。問題の一部は解決しましたが、新しい問題が出てきました。

  • 様々な人が様々なツールで作成しているため共通した色などの管理が困難
  • いろいろな「食べチョクらしさ」が発生する
  • デザイナーに画像制作に関する質問や、確認依頼がくるが、急ぎの話になる(確認しきれない・作ったほうが早い)

これらの問題解決のため、デザイナーチームであらかじめ Figma でテンプレートを作り、テキストや画像の差し替えを各担当者にしてもらう体制に移行をはじめました。

Figma でテンプレートを用意した

最初から、全種類の画像のテンプレートを作ることは難しいので、定型があるところから作り始めました。

ツールは Figma にしました。

  • 担当者に edit 権限があったこと
  • デザイナー側で共有している色のライブラリーなどがそのまま使えること

今回は、Figma の edit 権限を持っている人がマーケティングチームにいたので、そこから今回は始めることにしました。 Figma から始めることで、デザイナーがすでに共有している色のライブラリーなども使うことができ、試すための敷居は低めでした。

テンプレートを用意して、担当者に説明をして調整をして運用に進んでいます。

Figmaで用意したテンプレート

おわりに

問題が 0 になったわけではなく、Figma について知ってもらう必要や、edit 権限を持つ人を増やす取り組みも必要そうです。運用していくなかで見つかる問題にも対応を続けていく予定です。

今後もいろいろな取り組みで、個々のデザイナーの力をより発揮できる組織になり「食べチョク」の改善に向き合っていきます。

Figma の操作を方法学んでデザインデーターができるまでの過程を知る

こんにちは、松久です。

食べチョクでは Figma をデザインツールとして使っています。デザイナーが作った Figma のデザインデータを見てエンジニアはHTML/CSS を書いています。このとき、わかりにくいデザインデータを見かけるときがあります。解決の糸口をみつけるために、Figma の使い方を知ろうと取り組んでみた話です。

何から始めるかを決める

新しい技術を学ぶ時は、チュートリアルがあればチュートリアルから始めるのを基本にしています。 Figma のチュートリアルとして、公式のYouTube動画を今回は使いました。このYouTube動画だけでチュートリアルとしては十分な量があります。全部はできませんでしたが、必要に応じて学ぶことができそうです。

Tutorials: Explore design features in Figma - YouTube

私はここから始めて一通りの操作を学ぶことができました。

www.youtube.com

Figma のようなソフトウェアは、動画で操作しているところを見ることができるため理解がしやすいです。公式の動画なので、Figma が想定している使い方の基本を知ることができるのも安心です。 動画は、英語なのですが、YouTube には自動翻訳機能があるので英語が苦手でも、日本語訳を表示させながら学ぶことができました。

残念なのは、全体像の説明がないので全体のどれぐらいを学んでいるのかはわかりません。学びたいことは、なんとなく思い浮かんでいたのですが、全体像の説明があると、後どれぐらい時間が必要なのか想定ができるのでありがたいです。

UI のトレースをしてどうやってデザインデータを作るか試してみる

操作方法について学んだあとに、いくつかのサイトの UI をトレースしてみました。 トレースの目的は、どんなことに気をつけて UI を作っているのか観察し、トレースすることで、デザインデータをどんなふうにすると良いのか感じ取ることを目的として行いました。

行ってみて、Figma の AutoLayout、コンポーネント、Variants が、マークアップではどんなふうに置き換えられるのか想像しながらデータを作ってみることができたのは大きな体験でした。

YouTube にあるチュートリアルでは、レイヤー名を常につけています。見ているときは「こまめに名前つけてるなあ」と見ていました。トレースをしてみると、名付けがあとになっている自分がいました。そして、あとからつけようとすると面倒くさい…。時々ある「Group 831」という数字のレイヤー名にとても納得しました。

実務のデザインデータを作る

トレースをしたあとに、実務でも UI のデザインデータを作ることになりました。自分が作ったデザインデータでエンジニアがマークアップをするのを見るのは新しい体験でした。

実際のUIデザインデータの一部

作ってみると、話し合いからデザインデータを作る流れで実装まで一通りのデザイナーの体験をしてみて、見えていなかった作業もわかりました。 例えば、モブデザインの後は、データの整理をしないと使いにくいデータ(例えば、レイヤー名から表示個所がわかりにくい、テキストのサイズが複数混ざっているなど)ができること。margin/padding についてデザイナーが理解していないとデザインデータとして表現できないこと(例えば、レイヤー同士の距離で margin を表現することと AutoLayout で padding を表現すること)を感じました。

おわりに

デザインデータはどうやってできるのか、実務で使ってみることで頭の中で知っていたこと以上のことを感じることができました。情報として知るのではなく、上手くいえないですが、実感のある情報となりました。

今後もいろいろな取り組みで、個々のデザイナーの力をより発揮できる組織になり「食べチョク」の改善に向き合っていきます。

ペアデザインとモブデザインを行いデザインデータを作る

こんにちは。松久です。

デザインデータを作るとき、デザイナーが一人で作業をすることもありますが、複数のデザイナーや、デザイナー以外の職能の人と一緒に取り組む事も少しづつ増えています。 現在、どのようにデザインデータを作っているのかを紹介します。

デザインデータができるまで

食べチョクで、デザインデータができるまでの大まかな行程は下記の通りです。

  1. 施策の目的を整理する。資料を集める。
  2. 施策の目的にそったデザインの初稿を作る
  3. 関係者で見ながら作って確認する( モブデザイン・ペアデザイン )
  4. デザイナー同士で確認・検討をする(デザインレビュー)
  5. 関係者で合意する( デザインが確定 )

今回は 3〜4 の工程で取り組んでいることを紹介していきます。

UI のためのデザインデータは認識合わせのためのドキュメント

デザイナーが作っている「デザインデータ」の役割は、バナーなどのグラフィックとUIでは異なります。 バナーなどではデザインデータは完成品となりますが、UI を作るときのデザインデータは、プロダクトを作るための中間成果物で、意図を伝えるドキュメントです。 デザインデータを使い、プロダクトマネージャーと成果物(= プロダクト)について共通の認識を持つために使います。エンジニアとは、HTML や CSS などを作るための設計図のような役割( 1px を正確に表した図面ではなく意図を伝えるための図)で、認識を合わせるために用意しています。

職能を制限せず複数人でデザインをするモブデザイン

デザインデータを作るとき、エンジニア、プロダクトマネージャなど複数人で Figma を見ながらデザインすることを少しづつ増やしています。

GitHub の issue でデザインデータを依頼者に連絡しても意見交換で数日経ってしまうことがあります。複数人集まって見ながらデザインする方法であれば、何ができるのか伝わり、納得感を関係者で持つことができ、複数視点で確認できるようになります。 デメリットは、複数人の時間をいっぺんに使うのでコスト面とスケジュール調整が必要なことです。

進めるコツは、デザイナーは話しながらデザインをして黙って作業をしないことです。話を聞いて受け身で作業だけをするのが目的ではないからです。 もう1つのコツは、1時間を目安に終わらせること。話を聞きつつ、Figma を操作して画面を作るのは頭と手を同時に動かすので疲労が大きいです。話している方も目の前でできていくので白熱しやすく疲れてきます。ファシリテーションと Figma の操作は別な人がする方のが良い可能性もありますが、デザイナーの理解としては話しながら Figma で作るのが良いと感じています。

デザイナー同士複数人でデザインする

デザイナーは毎日「Designer Team Discussion」というミーティングをしています。ここで取り組んでいるデザインについて相談したり、一緒に作ることがあります。 目的を達成するためのデザインになっているか、他の人へ説明する機会になっていることが、一番大きいメリットです。あと、他の人の Figma の操作方法を見ることができるのもいい点です。

デザインレビューをする

UI については、「Designer Team Discussion」で確認して終わりになることも多いのですが、バナーなどはデザインレビューを必須にしています。 Slack に専用のチャンネルがあり、Workflow から依頼できます。デザイナー全員にメンションされますが、レビューはレビューワーを指定してレビューすることが多いです。

Slackのワークフローを利用したデザインレビュー依頼

デザインレビューの本もありノウハウが増えてきていますが、デザイナー以外がするのはまだ未挑戦です。今はデザイナー2人、もしくは、3人以上ですることが多いです。

おわりに

デザイナーだけでデザインを行うのは難しいと感じています。 取り組む業務の知識、どんな表現が技術的に可能なのか、ビジネスとして取り組む事のバランスの落とし所を探すために、デザイナー以外を巻き込んでデザインに取り組むことが大切になってきていると感じています。

今は、Figma などのツールを土台にデザインについてのコミュニケーションを促進させていくことで、プロダクトをより良い状態にリードすることを、デザイナーに求めている状況になってきました。 今後もこのような取り組みで、組織でデザインを行えるようになり「食べチョク」の改善に向き合っていきます。

Figma のファイル管理ルールを決めて業務を円滑にする取り組み

こんにちは。食べチョクの松久です。

今回は、複数人で Figma のファイルを管理するために工夫していること、悩んでいることも含めてどのようにしているかを紹介します。

ファイル管理をする目的

ファイルを管理する目的は、なんでしょうか。 複数人でデザインを行う体制のために、下記のことを実現するためだと捉えました。

  • 過去の積み重ねによる一貫性(UIや、らしさ・ブランディング)を保つため
    • デザイナーが過去のファイルを見つけやすくする
  • デザイナー以外もデザインに関われる状態を作り、全員でプロダクトを作るため
    • デザイナー以外もファイルを見られる状態を作る

上記の目的のために、今までの管理方法を踏まえながら、ルールとして明確にしていきました。

プロジェクトを端末ごとに分ける

食べチョクのデザイナーは、Web / iOS / Android といった端末でのサービスや、広告、キャンペーンなどのデザイン作成を担当しています。そのため、端末、媒体に合わせてプロジェクトを分けて管理することにしました。

  • Library
  • Web
  • LP
  • Mobile(iOS・Android)

上記の様なプロジェクトを作っています(上記が全てではありません)。 プロジェクトには、About を書くことができるので、プロジェクトの役割とファイルの命名ルールを書いています。

プロジェクトではなく、チームを複数に分けて管理する方法もありますが、今は1つのチームで管理しています。 理由は、例えば Web、Mobile でチームを分けると、「食べチョク」でウェブでもMobileでもキャンペーンを行う時にどこで管理するのがいいのか悩むからです。 もう1つの理由は、利用している Professional プランでは、作れるチームに限りがあり、細かく分けることができないためです。

ファイルの管理

ファイルの管理として、ファイル名に規則をもうけています。また、カバー画像についてもルールを設定しています。ルールを設けているのは、ファイルを一覧した時に見つけやすく、状態の把握がしやすくなる様にしたいためです。

プロダクトに関するファイル名のルール

ファイル名のルールは下記の通りです。

状態の絵文字 + GitHub のリポジトリ名 + issue番号 + issue のタイトル

取り組むことは、GitHub の issue を使って管理しているので、issue の情報をファイル名に含めました。そのため、issue 番号で検索してファイルを見つけることができます(被る時もあるので、リポジトリ名も入れています)。

状態の絵文字は以下としています。

  • ✍️ デザイン中
  • 🔧 実装中
    • 開発でエンジニアにファイルを渡して実装中の時
  • ✅ 完了
    • デザイン、実装も完了している状態。これ以上の変化が起きない時
  • ⏸ ペンディング
    • 施策を進めることが止まっている時
  • 🚩 ピン留め
    • テンプレート用ファイル

ファイルをリスト表示すると作業中のファイルが固まって表示されるようになります。issue 番号がすぐに出てこない時も、絵文字で目視による絞り込みができる様になります(付けていないファイルがまだあったりしますが、少しづつルールを適用している途中です)。

LP などのファイル名管理

プロダクトに関するファイルは、命名管理を徹底していますが違う管理もあります。 キャンペーンや、サービス紹介のためのLPについては、サービス名やキャンペーン名をファイル名にしています。 理由はいくつかあります。

  • サービス紹介のための LP は、Facebook 広告、LINE のリッチメッセージ、メルマガでの紹介画像などの複数のクリエイティブを作って成立する。
  • 複数のキャンペーンがあって1つのキャンペーンとなることもあり、前回のキャンペーンと比較することがある。
    • この時、issue は分けたいが、Figma のファイル内では比較をしたい。

以上の理由から別ルールとなっています。

カバー画像の設定

カバー画像はグリッドで見た時に、見つけやすくするために設定してます。 特に、キャンペーンや、サービス紹介の LP は、カバー画像をキービジュアルを設定しています。ファイル名でも見つかるのですが、見た目で覚えていることも多く、カバー画像を設定しています。

Figma のカバー画像の例

ファイルの中の管理

Pages を以下のとおりに分けるのを基本にしています。

  • 💻 実装用デザインマスター
    • デザインが確定した時に渡すデーターです
  • 🎨 Flow
    • 制作中。さらに分割されることもあります
  • 📝 メモ
    • 資料などを集める時に使います
  • 🗂 Cover
    • カバー画像の設定をしています

上記を基本としますが、追加される Page もあります。多い Page の追加事例は、広告や、og:imageサイズの画像用の Page です。キャンペーンの告知のためのクリエイティブをまとめる Pages を作ることがあります。

継続的なキャンペーンなのかは、最初わからないのもありますし、お歳暮・お中元のように毎年実施しているキャンペーンもあります。毎年実施であっても、違いがあります。前回との違いと共通点を気をつけることが多いので、今は1つのファイルに、クリエイティブごとの Page を作ることが多いです。

まだ悩んでいること

管理方法を決めたことで、ファイルを探しやすくなり、過去の施策も見つけやすくなってきました。以前より、状況はよくなりましたが、管理方法だけでは足りないことにも気づきました。

マスターデーターを運用すべきか

多くの施策が実施されると、マスターデーターへの反映が追いつかなくなってきました。また、知らず知らず変更されていることもあります。 マスターデーターはあった方がいいのですが、運用コストと対価が見合う方法を見つけられていない状況です。 施策でエンジニアが機能追加・変更をすることもあるので、デザイナーだけで解決できないのではないか、と感じています。

印刷データーの管理はどうするか

印刷データーは、Illustrator で作るので、Figma 上では管理していません。専用のルールが存在しています。 GitHub の issue で、印刷に関しても管理しているので、Figma で issue 番号を検索して「あ、違った」となることがあります。

おわりに

書き出してみると、まだまだ問題があることに気づいてしまいました。 特にマスターデーターの運用問題は、頑張るしかなさそうな気持ちと頑張り切らないと意味がなさそうと想像しているところです。

今後もいろいろな取り組みで、個々のデザイナーの力をより発揮できる組織になることで、「食べチョク」の改善に向き合っていきます。

テスト改善チーム活動の軌跡(総集編)とチームの進め方

みなさま、お久しぶりです。QA エンジニアのujeです。 今回、テスト改善チームの活動が一段落したので総集編としてこれまでの取り組みを振り返ります。 改善チームの始まりはこちらの食べチョクの自動テスト改善活動 〜これまでとこれから〜をお読みください。

現在、チームは目標達成を契機に 10 月末で解散となり、メンバーは食べチョク開発業務に集中しています。

私を含めて 8 名で食べチョクの開発業務も並行だったので、1 人あたり週に数時間の作業時間でした。 そのため、少しずつの活動にはなりましたが多岐に渡って遂行できたと感じています。

ここではその成果一覧とその時のブログ記事をまとめました。

成果

4 月〜10 月の半年間でしたが、形骸化せず目標を達成できたので上手くいったチームになったかなと感じています。 自分なりにですが次の項目では上手くいった要因について振り返って見たいと思います。

チームが上手くいったと考えている要因

  • メンバーが改善活動に対して意欲的だったこと

    • 改善した方が良い箇所という意見出しを実施してから、テスト改善について重要だと感じているメンバーに集まってもらったので意欲が高かった
  • ミーティングが意味あるものだったこと

    • ミーティングは「レビュー」→「レトロスペクティブ」→「プランニング」を短時間で進めて意思決定を重視した設計していた
    • メンバーからもらった意見は抽象化して議題にしてやった方が良いものはプランニングで取り入れていった
  • 目標の設定ができていたこと

    • フワッとしたまま進めないことを前提に、まずは目標を数値を出す部分を対応した
    • 数値の取得が可能になったら最終目標を設定した
    • 目標に対して毎週どれくらいで達成できるか週次目標を算出していた

筆者個人が特に重要視していた点

「チームを動かすこと」「チームが意思決定しやすいように自身が動くこと」の 2 点です。

冒頭でもお話ししたとおり改善チームは食べチョク開発と並行した改善チームだったのでみんな本来の開発業務があります。

そのため、そちらが優先となりどんどん作業が後ろ倒しになって形骸化してしまう といった結果にならないよう注意していたことを箇条書きにしてみました

  • 重要視していたこと
    • ミーティングの準備、ファシリテーションなどを担当
    • 必ずネクストアクションを作る
    • 数値目標を作る
    • 締め切りを決める
    • 次ミーティングまでに出してほしいアウトプットや資料を提示して記載してほしい場所に誘導する
    • 1 施策にたいしてなるべく担当を 2 名アサインする
    • 問題が提起された場合や上手くいってないと感じたら早めの変更をする(ミーティングや進まない要因の解決を図る)

振り返ってみると筆者自身は毎週何かしら運営関連するアクションを取っていたように思います。 一番良くないのは、動かないことで忘れられてしまうことだと思っていたので、Slack で細かく発信していたように思います。

最後に

正直、かなりメンバーの意欲的な部分に助けられたと実感しています。一番早く業務が進むときって心のどこかに安心感や連帯感があることだと思ってます。 また私自身も次も同じようにいくとは限らないです。新しい改善チームを運営する場合は、手を変え品を変え試していく意識を大事にしていきます。

改善が新しい改善を呼び、結果として開発やお客様にとって安定したサービスになるよう尽力していきます。

最後になりますが食べチョクでは仲間を募集しています。 ご興味がある方は是非、RECRUITからご応募ください。