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 人あたり週に数時間の作業時間でした。 そのため、少しずつの活動にはなりましたが多岐に渡って遂行できたと感じています。

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

成果

• RSpec カバレッジ率
  • カバレッジ率の集計が手動から自動に改善 RSpec 実行時のレポート情報をクエリで可視化する
  • Controller のカバレッジ率が 67% から 81% に改善 テストのカバレッジをコツコツ上げた話
  • 全体のカバレッジ率が 74% から 80% に改善
• テスト実行時間
  • テスト実行時間の集計が手動から自動に改善
  • テスト実行時間が平均 13 分 17 秒から平均 4 分 45 秒に改善 食べチョクの自動テスト実行速度を 2 倍以上速くした
• 未使用コード
  • 現在使われていないコード精査、一部削除が行われた
• ブログ
  • 記事をチームで 5 本執筆（本記事を含む）

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

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

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

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

• ミーティングが意味あるものだったこと

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

• 目標の設定ができていたこと

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

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

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

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

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

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

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

最後に

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

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

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

テストのカバレッジをコツコツ上げた話

こんにちは、endo と kawabata です。 今回はプロダクトチーム内の自動テスト改善チームでコツコツカバレッジを上げた取り組みと振り返りのお話をしたいと思います。 ここでテストのカバレッジを上げているのは、RSpec でのお話になります。 テストのカバレッジを上げていこうというお話は、こちらの食べチョクの自動テスト改善活動 〜これまでとこれから〜のお話からきています。

ゴールを設定せずに活動するのは良くないので、10 月末までにカバレッジを 80%まで上げるということを目標に設定しました。 80%まで上がれば広範囲をカバーできているだろうというざっくりとした見立てです。 今回の取り組みでは、大きく分けて以下の 3 点を実施しました。

• どのテストを追加するか決める
• コツコツテストを追加する
• 不要なコードを削除する

どのテストを追加するか決める

テストのカバレッジを上げていこう！というのはいいのですが、闇雲にやっても改善幅が見えません。 そこで、改善幅を見つけるためにRSpec 実行時のレポート情報をクエリで可視化するで現状の状態を可視化しました。

その結果、どこから着手するかが見えてきました。

RSpecのグループ毎のカバレッジ

• Controller / Mailer / Jobs のカバレッジが全体よりも低い
• 3 つのグループの中で Controller は実際のエンドユーザー側へのコンテンツの表示に関わる割合が多い

ということで、Controller のカバレッジを改善しようという話になりました。

では、どのファイルからやるのか？というところも闇雲にやっても改善が見えづらいです。 カバレッジが低いものから着手しようということで、カバレッジが低いものを抽出しました。 これでテストを追加する対象が明確になりました。

Controllerのカバレッジが50%以下のファイル

コツコツテストを追加する

目標達成までに対応が必要なファイル数を算出し、目標達成までの日にちから逆算して毎週各メンバーに割り当てました。 平均すると 1 人毎週 1 ファイル追加するペースで進めば目標達成となる計算です。 テストを追加する対象が決まりマイルストーンも設定できたので、あとはコツコツと追加していくのみです。

しかし、ここからが大変でした。 最初のうちは順調に進んでいたのですが、途中からペースが鈍化し思うように進まない期間もありました。 各メンバーの業務状況により、テストを追加するための時間が確保できないというのが大きな要因でした。 これに関しては優先順位の兼ね合いで仕方ない部分があり、解決策がないので「先週出来なかったので今週は 2 つ追加しよう」みたいな感じで進めました。

不要なコードを削除する

テストの追加と並行して不要な機能やデッドコードを削除する活動も進めました。 使われていない処理のテストを追加しても無駄になりますし、テストがない不要はコードを削除すればカバレッジも上がるだろうという想定でした。 その結果、想定通りカバレッジ向上に効果的でした！

不要コード削除後の50%未満Controller数

不要コード削除後のカバレッジ

最終結果

コツコツテストを追加したり不要なコードを削除した結果、全体カバレッジが 80%を超えました！

最終全体カバレッジ

Controller 単体でも 80%を超えました！

最終Controllerカバレッジ

目標も達成したので、自動テスト改善チームは解散となります。

振り返り

今回の活動を振り返ってみて良かった点と課題が見えてきました。

良かったこと

グラフによるカバレッジの可視化

日々テストを追加してもカバレッジの増加はごくわずかです。 成果が見えづらいとモチベーション維持も難しくなります。 カバレッジをグラフ化していたことで日々右肩上がりに増えていくのを確認でき、 活動のモチベーション維持にも役立っていたと思います。

設定した目標を達成できた

業務状況により進捗が少ない時期もありましたが、自然消滅せず目標を達成できたことも成果の 1 つだと思っています。 あまり進捗しない状況でも継続することの大切さを改めて実感しました。

課題

安定した作業時間の確保

上でも書きましたが、各メンバーの業務状況によりテストを追加する時間を確保できないという状況が発生しました。 今回の取り組みだけのことではなく、こういった改善活動では起こり得ることです。 これに関しては良い解決方法が見つかっていませんが、 定期的にミーティングを開催して進捗状況の共有を行なっていたのは、良かったと思っています。 （個人的にミーティングのたび『頑張って進めないと！』と感じ、モチベーション維持に役立っていました）

おわりに

80%を超えたカバレッジですが、日によっては 80%を下回っています。 日々システムが進化していてコードは増え続けていますが、それに対応したテストが不足している場合があるということですね。 カバレッジが高いから良いというものではありませんが、必要なテストが不足していることは問題です。 自動テスト改善チームは解散となりますが、プロダクトチーム全体としてテストを書くということを意識していきます。

目標達成後のある日の全体カバレッジ

デザイナー同士で行う3つのミーティング設計

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

今回は、デザイナーの活動を支えるミーティングをどうやっているか紹介します。デザイナーが関係するミーティングは3つあり、それぞれのミーティングの目的を説明していきます。

プランニング・交通整理

月・水・金曜日に施策の整理をしています。1回 30分程度です。

デザイナーが行うことは、ユニットに所属する施策以外にも、マーケティングや広報など他の部署・組織と一緒に行う施策があります。そこで、施策の状況の確認や、新しい施策の話について確認する必要があります。

施策は全て、GitHub issue に記載され、GitHub Projects にある ボードで管理をしています。ボードを見ながら、進捗の状況や新しい施策の対応を決めます。

デザイナーのGitHub Projectsの様子

さまざまな施策があり、人数に限りがあるのでどうしてもアサイン（割り当て）をすることになっている問題があります。理想としては issue を読み、施策に自発的に取り組める状況が理想ですが、まだたどり着いていない、というのが現実です。

Designer Team Discussion

「Designer Team Discussion」という名前でカレンダーに登録していますが、堅苦しくはなく、ざっくばらんに話すための時間を、毎日1時間とっています。 話していることは下記のようなことです。

• 取り組んでいる施策の UI について相談（雑なデザインレビュー）
• デザイン界隈の話題（ Figma のアップデートとか ）
• 最近の困ったこと、良かったこと
• 雑な話

です。

色々な施策があり、1ユニットに複数のデザイナーがいるのは少ない状況なので、一人で抱え込まないように「定期的になんでも話せる時間があること」を大切にしています。そのため、これといって議題は決めていません。決める時もあるのですが、決めたら決めたで議題について、話せない時もあります。ここは改善の余地があるところです。

コミュニケーションの場でもあるので、デザインとは全然関係ない話になることもありますし、Figma などツールの話になることもあります。例えば下記のようなことを話しています。

• 写真素材のダウンロード履歴が美味しそうな写真だらけで困る
• いわき市に良さそうなゲストハウスがあるので、ワーケーションにいいのでは？
• Figma でマスターデーターを管理し続けるのは現実的か？

などです。

このミーティングで話したことを「📝🍵🍡」という絵文字をつけて、Slack のデザイナーのパブリックなチャンネルにメモをしています。メモなのでツッコミは歓迎です。 ここで話したことから、業務の改善できそうなことを見つけて、取り組むこととして esa にまとめて、時々対応しています。具体的には、印刷物に関する資料をアップデートしたり、デザインシステムのアップデートをしたりしています。

Monthly Update

プロダクトチームと呼ばれる組織にデザイナーは所属しています。この組織では「Monthly Update」というミーティングが、月1回あります。この時に合わせて、この一ヶ月間で何を取り組んだか？確認しています。

このMonthly Update実施前にデザイナーで何を取り組んだのか成果を確認をするミーティングをしています。何を取り組んだのか確認するのと一緒に下記のようなチェックリストを実施することにしました（議事録は esa で管理しています）。

- [ ] Figma のアカウントの確認
- [ ] 📝🍵🍡 のリスト確認
- [ ] スタイルガイドの進捗確認

Figma のアカウント管理・確認は定期的に行う必要があるので月一のイベントは都合が良かったです。

デザイナーの成果を確認するのですが、書き出してみるのは時間がかかります。時間はかかるのですが、自分たちで何をしたのか？どんな成果だっけ？を確認する時間は必要だと思っています。ただ、確認しきれないこともあり、改善が必要です。

おわりに

ご紹介したミーティング以外に、1on1 や、プロダクトチームの定例ミーティング、全社でのふりかえりなどがあり、ミーティングは少なくありません。 ミーティングは、効率的に目的を持って行えるのが理想です。ただ、デザイナーが複数人いる状態になってまもないので、デザイナー間でのコミュニケーションを目的としたミーティングをしています。そのため、全体として少し多めの状態が続いています。

今回、半年ぐらい運営した結果を書き出してみることで、変えたほうが良い点に気づくこともできました。

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

デザイナーへの依頼数を GitHub CLI と jq を使って集計する

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

今回は、デザイナーへの依頼数を GitHub CLI と jq を使って集計している話を紹介します。 どうして、依頼数を計測することになったのか、どうやって GitHub CLI と jq を使って集計しているのか、を順番に説明していきます。

組織の中でのデザイナーの位置付け

最初に、「食べチョク」を作る組織の中でのデザイナーと、エンジニア、プロダクトマネージャーの関係は下記の図の通りです。

2022年9月現在の組織図

「食べチョク」を作る組織は、チームトポロジーを原則としています。 2022年9月現在、「プロダクトチーム」にミッションを持った「ユニット」がいくつかあります。ユニットには、プロダクトマネージャー、エンジニア、デザイナーなどで構成されています。ただ、ユニットによっては、デザイナーがいないこともあります。詳しくは「食べチョクのプロダクトチームとチームトポロジー」を参照してください。

デザイナーは、ストリームアラインドチームに所属するのを基本にしています。デザイナー（職能）だけの組織はありません。 組織図には存在していませんが、デザイナー同士で集まって組織的に活動する場面も多くあります。理由は、「食べチョク」でのキャンペーンや、株式会社ビビッドガーデンの運営に必要なクリエイティブ作業も担当するため、組織的な対応が必要となるためです。

キャンペーン、バナー、広告の事例

具体的には以下の仕事があります。

• キャンペーンページのデザイン
• キャンペーンに関するバナー類の作成
• ディスプレイ広告などの作成
• 広報に関する画像
• コーポレートサイトの運用
• Tシャツ

などがあります。

2021年末頃、デザイナーも、マーケティング、広報担当も今より少ない人数で、なんとか対応していた状態でした。 その後、デザイナーの人数は増え、マーケティング、広報担当の人数も増えました。人数が増えた分、取り組む「食べチョク」や、株式会社ビビッドガーデンの運営に必要な「クリエイティブ作業」も増えて、対応が追いつかなくなってきました。

バナー作成など依頼数が増えてきたがどれぐらい増えたのか計測したい

本来であれば、依頼を受けて対応するよりも、一緒に目的のために活動できる状態（ = ゴール）が望ましいのですが、まだその状態には達していないです。ゴールに向けて、今の状態を把握するための取り組みから始めました。

最初の取り組みは、Slack などで行われていた依頼を全て GitHub issues で残すことにしました。 プロダクトチーム（ストリームドアラインチーム）はもちろんですが、マーケティング、広報なども issue に書き起こしてもらうことを徹底しました。issue には、部署ごとのラベルをつけて分類しています。 issue は複数のリポジトリで管理されていますが、デザイナーが関わるリポジトリは限られているので（いまは 3つぐらい）、そこはあまり負荷になっていません。

GitHub CLI と jq を使って集計する

GitHub CLI （ gh ）を使い、issue のデータを取得していきます。 issue のデータは、json 形式で取得できるので、jq コマンドで tsv 形式にしてダウンロードします。

$ gh issue list -s all -L 1000 --search "label:"design:UI","design:ASAP","design:PS","design:PR","design:service","design:marketing","design:biz"" --json "createdAt,closedAt,number,title,url,labels,state"| jq -r '.[]|[.createdAt, .closedAt, .number, .title, .url, .state, ([.labels[].name] | join("/"))]|@tsv' > issue.tsv

gh コマンドには、色々なオプションがあるのですが、ラベルを複数指定することが難しかったので、search オプションでラベルを指定して検索しています。 検索結果を jq コマンドに渡して、tsv ファイルにして保存しています。 この後は、tsv ファイルを Google Sheets にいれて、集計します。

集計結果を活用する

集計結果は、毎月、プロダクトチームで成果を共有する場で、プロダクトチーム外で起きたプロダクトのこととして数値共有を 発表して esa に残しています。 また、完了数や、時間の配分も他の集計結果と合わせてわかってきたこともあるので、業務の見直しに活用できました。

おわりに

組織が大きくなり、デザイナーが色々な場面で求められるようになってきました。 求められるのは、嬉しいですが、残念ながら人数の限界もあります。どんなことが今できているのか数値で整理することで、他のチームに理解を求めたり、活動を可視化できました。

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