食べチョク開発者ブログ

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

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

こんにちは、松久です。

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

トイルとは何か

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 にして、実行していくことにしました。 「ふりかえり」から「食べチョク」の改善を引き続き実行していきます。

デザインチームの2023年のブログを振り返り!変化と継続、そして2024年への動き出し #デザイン #ブログ

こんにちは、松久です。

デザインチームの 2023 年のブログ記事をふりかえり執筆後から変わったことや、変わらなかったことを書き出すことで、2024 年に向けて動き出せるようにします。

Figma のファイル管理ルール( 2022 年 12 月 )

ファイル名については、デザインチームでは浸透が進み当たり前の状態になっています。変える話もいまのところなく、やってよかったです。 マスターデータの運用は、GitHub Projects で「🏁 マスターデータに反映待ち」を用意し、ここを通らないと作業完了とはしないことにしました。ただ、マスターデータへの反映が滞りがちなところがあるので、課題は残っています。

Figma の操作方法を学ぶ( 2023 年 2 月 )

公式の YouTube から学んだことは生かされているし、YouTube で学ぶのは良い、と実感しています。 出来ていないことは、Figma のイベント Config 2023 で新機能がたくさん出ましたが、キャッチアップできている、とは言い難いことです。普段の業務でも嬉しい新機能はあるのですが、手慣れているところで終わらせることも多く、より効率的な使いこなしのために、チームで Figma のことを話すことを話す時間をもちたいです。

バナー制作をデザイナー以外でも作成する運用始めました( 2023 年 3 月 )

運用自体は、軌道に乗っています。でも、増やせてはいません。作れるスキルがある程度必要なことと、都度作るバナーが多くあるので、今以上に拡大することは難しそうです。

Figma と SCSS で色の管理をあわせる( 2024 年 4 月 )

Stylelint は役割をきちんと果たしてくれています。 ただ、色々な方法で色々な指定が生まれています。例えば下記のように使われることがあります。Figma では表記が異なるので、SCSS を書くときに少し面倒です。

@use "../Foundation/variable";

.foo {
  color: variable.$color-gray0;
}

フォントについて、SCSS と Figma を近づけて、下記のように SCSS を書けるようにしています。

@use "../Foundation/mixin/typography";

.foo {
  @include typography.body;
}

Figma の DevMode が出来て、CSS のカスタムプロパティが表示されるようになりました。Figma の表示を合わせて、実装を調整することも検討しています。

ふりかえりからデザイナー同士のミーティングを改善しました( 2023 年 5 月 )

GitHub Projects に「🧵 Talking」を設けて、issue を検討する時間をとるようにしました。 現在、あまり上手くできていないです。話すためにも、準備することが多く、そのためには時間を確保する必要があります。話をする時間だけでは足りないことがわかりました。あと、夏ぐらいから業務量が増え続けて、この時間も作業の交通整理のミーティングに使われることが増えました。

急ぎではないが重要なことを進める仕組みを試し続けないと、改善活動はされないままです。取り組める量は同じでもより効率的に進められるようにする取り組みをして、「急ぎではないが重要なことを進める仕組み」を手に入れようと検討しています。

「似ているけれど少し違う色」を減らす取り組み( 2023 年 6 月 )

増えることはなくなりましたが、既存の実装からは減らせていないです。 UI を変更するときに対応しているので、徐々に減っているハズです。

桃やぶどうのような同じ品目でバナーを作る前に事前準備したこと(2023 年 7 月)

品目・品種でバナーを作る時から始めた色のトーンを事前に話すことは、続けています。 ここから発展して、年末年始の色など、季節やイベントでの色や表現はどうあったらいいのか、を話し始めています。

おいしそうが伝わる写真を選ぶ原則をチームで共有した( 2023 年 8 月 )

原則ができたことで、写真選びはしやすくなりました。思ったよりも、画像制作のスピードアップに効果がありました。

GitHub Projects でデザインチームのタスク管理をするノウハウ( 2023 年 9 月 )

ここからは、あまり変化はありません。ただ、他のチームにも紹介して、使ってもらえるよう話しています。ノウハウのベースは「カンバン仕事術」です。私が休みでも、チームでプロダクトバックログの管理がされていたので、デザインチームには定着してきたようです。

デザインと上手くお付き合いする方法を社内で発表した( 2023 年 10 月 )

少しでも早めに声をかけてもらえるチームになりたいです、という宣言でした。 まだ、実現できていないことのほうが多いですが、少しづつ声をかけてもらえるチームになるための行動をします。

画像制作依頼チェックリストから普段のヒアリング内容を確認した話( 2023 年 11 月 )

画像の制作依頼は、日々あるのですが「画像をつくる」ということだけが決まっていることが多い状況です。なんのために作るか、を確認してもらえるように作ったチェックリストですが、なかなか使用されないことがわかりました。GitHub issue のテンプレートにチェックリストを入れたこともありますが、チェックリストは消されることがわかったので、デザインチームでチェックしていく方法に切り替えることを検討しています。

おわりに

2023 年の棚卸しとして、一年のブログを見返しました。 ブログ記事から時間が経って、そのまま続いている事や、変化しつつ継続している事、継続できていない事があります。デザインチームが変化している証拠なので、変化を確認するためにも、ブログは継続して「食べチョク」の改善に活かしていきます。

画像制作依頼チェックリストから普段のヒアリング内容を確認した話

こんにちは、松久です。

食べチョクでは様々なところで画像が作られています。 これらの画像は、様々な部署からの依頼をうけてデザインチームで作ることが多いです。一部、テンプレートから画像を作っているのもありますが、まだ、デザインチームで作ることは多いです( テンプレートを使った画像作成は「バナー作成をデザイナー以外でも作成する運用をはじめました」参照)。

大雑把な画像の作成依頼の時があります。このときは、具体的な形にするまでにヒアリングをして制作を進めていきます。 制作前のヒアリングに時間がどうしても必要になっています。この時間を短縮したり、事前に検討してもらえるようにするため、社内のドキュメントツール( esa を使用しています )にチェックリストを作り確認してもらうことをお願いし始めました。

具体的には、下記のようなチェックリストを esa に作って運用しています。

運用しているチェックリスト

  • [ ] GitHub issue を作る。下記の項目は後で埋めても大丈夫
  • [ ] どこにいつ出すか
  • [ ] 何を伝えて、どうなってほしいか
  • [ ] 伝えたいテキストの優先順は決めたか
  • [ ] 必ず入れなくてはいけない要素があるか
  • [ ] 写真が必要であればどんな写真なのか、だれが写真を探すのか
  • [ ] サンプル例はあるか

チェックリストの回答具体例

どこにいつ出すか

  • サイトトップや、メルマガなど

何を伝えて、どうなってほしいか

  • コンシェルジュ野菜の日キャンペーンを伝えたい

伝えたいテキストの優先順は決めたか

  1. 今だけ 初回 980円(税込)
  2. 野菜のある生活を始めよう!

必ず入れなくてはいけない要素があるか

  • キャンペーン期間を載せておきたい
    • 8月1日から8月31日 15時まで

写真が必要であればどんな写真なのか、だれが写真を探すのか

  • デザインチームに選んでほしい
    • 🙆🏻‍♀️ 夏から秋にかけての野菜が届くこと
    • 🙅🏻‍♀️ サラダなど調理後ではない

サンプル例はあるか

  • 特になし

チェックリストのポイント

チェックリストは、2つのことを伝えたくて作りました。

  • 完成イメージ(だれに、いつ、どこで、なにを伝えているか)を持ちましょう
  • 画像が必要になったらすぐ GitHub issue を作ること

画像がどんなふうに使われるのか完成イメージを持つことは大切です。 メルマガからサイトへ誘導する時と、商品をテーマに沿って紹介する時で大切にすることはことなります。画像に求める役割は異なるからです。チェックリストは、画像の役割を明文化するきっかけになるように心がけました。

おわりに

画像を作る目的のヒアリングは大切ですが、確認したいことが、事前にわかると話もスムーズです。チェックリストは、普段のヒアリングはなんのために、なにを聞いていたのか確認するいい機会でした。

普段の業務を棚卸しをして、なぜやるのかを確認することは定期的に行い「食べチョク」の改善に活かしていきます。

デザインと上手くお付き合いする方法を社内で発表した

こんにちは、松久です。

株式会社ビビッドガーデンでは、「週次 Sync & Share の会 」が開催されています。 (だいたい)毎週、各チームから全社に向けて、学んだことを伝えたり、聞いたりしています。

デザインチームから Sync & Share 会で「デザインと上手くお付き合いする話」というテーマで、デザインチームとより上手に仕事をする方法がわかることを目的とした発表をしました。

発表テーマを決めた気持ち

「デザインと上手くお付き合いする話」というテーマだと、今は「上手くできていない」と聞こえます。正直、すべてが上手くいっているとは言えません。上手くできているところもあるので、上手くできているところを増やすために伝えたい、という気持ちでした。

「デザインチームはどんな事ができるのか」を伝えて、デザインの必要性や、どんな風に関わると事業に対してよい影響を与えることができるか社内の広報活動が必要だと感じていました。同様のことが、「銀行とデザイン」という本に、インハウスデザイナーの取り組みとして書かれています。この本に後押しされて、実際にやってみました。

発表内容

「いい感じになーれ」を図解

当日は、スライドを作り、発表をしました。

一番言いたいことは、デザイナーが魔法使いで「いい感じになーれ」と唱えたら「いい感じ」にしてくれるわけではなく、一緒に「いい感じ」を探しましょう、ということです。

要件を決める前に呼んでもらえないのは、理由があると思っている。忙しそうで話すと迷惑そう。工数をかけたくない。話すと質問されて面倒。話しても上手くいかない経験がある。チームで話して決まっている。的確な質問をする力が必要という認識。そのために何ができるかは模索中。質問の作り方と数字の理解がデザイナーに必要
デザインチームが取り組むこと

一緒に取り組むためには、デザインチームも取り組むことが必要です。 認識している問題はいくつか有り、解決策が見えていることもあれば、暗中模索のこともあります。

発表した結果、どんな関わり方を持つとよいか、わかったと感想をいただいくことができました。発表することで、少しでも伝わったはずです。

おわりに

会社の取り組みの 1 つである「Sync & Share 会」を利用して、デザインとの関わり方を全社に伝える機会を得ることができました。 日々の活動で伝えることももちろん重要なのですが、業務ありきから始まってしまうので、業務で直接話したことがない人も含めて伝えられるいい機会があり助かりました。

デザインとの関わり方を全社で行えるようになることで、「食べチョク」の改善に活かしていきます。

GitHub Projects でデザインチームのタスク管理をするノウハウ

こんにちは、松久です。

デザインチームでは、GitHub Projects でタスク管理しています。 タスク管理する理由はいくつかあります。

  • 「食べチョク」の改善を少しでも進めるため
    • チームで効率的に改善を進めるため
  • 他のチームと一緒に仕事をするため

チームで成果を出せているのかを確認するため GitHub Projects を使って「カンバン」を参考にして管理をしています。

なぜ GitHub Projects を使っているのか

GitHub が、職種関係なく導入されています。GitHub issue で、タスクを書き出して GitHub Projects に集約がある程度されている状況がすでにありました。もし、GitHub Projects を使い続けて問題が発生すれば移行することを検討することにしました。

現在の GitHub Projects の状態

GitHub Projects の運用状態です。

いくつかのカラムに分けて運用しています。 カンバンと同じで、issue は、inbox から始まり、Done で完了します。 現在あるカラムと役割は下記のとおりです。

  • inbox
    • issue ができたらまずはここに置く
    • 担当が決まっていない
  • Talking
    • デザインチームで検討したいことをここに置く
    • 定期的に話す時間を設けて話して解決したり、具体的な取り組みになれば、あたらしく issue を作る
  • Backlog
    • 取り組む担当を決めた issue
    • 取り組める状態にするのもこの状態で行う
  • Expired Backlog
    • リリース日が決まって動かせない issue
    • 取り組む担当を決めた issue
    • 取り組める状態にするのもこの状態で行う
  • In Progress
    • 取組中
  • 開発中・連絡待ち
    • UI デザインが終わり、開発実装中
    • 社外からの連絡待ちで、動かせない issue
  • マスターデータに反映待ち
    • 開発も終わり、利用者に届けられた状態だが、デザインデータをマスターデータ( Figma でブランチ機能が使えないため)に反映するの待ちの状態
  • Done
    • 利用者に届けられたられた状態
  • icebox
    • いつか優先度が上がる可能性のある issue

運用を始めて、少しづつ変化して現在の形になっています。 今後も変化していきます。

GitHub Projects の運用ルール

運用しながら出来たルールがいくつかあります。

  • issue を左から右に進める
    • チームで issue をゴール(完了/Done)に進めることを大切にしています
    • issue が左から右に移動することで取り組む内容が具体的になります
  • Done に移動した(完了) issue をアーカイブするのは月曜日
    • 一定期間にどれぐらい完了したかチームで確認するため
      • 大体、1 週間で 10〜15 ぐらいの issue がクローズされているのか肌感をもつようにしています。少ない時は、進めるための障害があった時だと気付けるからです
    • Projects に置いておける issue には限りがある
  • 並べる順位は、取り組む・期限が近いもの順
    • 取り組む価値が大きいことを先にするのが基本です。ただし、取り組む内容が時間のかかるものの場合(例:冊子を作る)や、リリース日が近いのもあるので、取り組む順で並べています

GitHub Projects の運用ノウハウ

運用している中で、上手くいかなかったこともあります。

  • 毎日見る
    • チームでは月・水・金に見ています。取り組むことに困っていることはないかを確認しています
    • 私は毎日見ています。急ぎの issue が登録されていることがあるためです
      • 急ぎの issue は、Slack のデザイン組織のチャンネルなどでメンションしてもらうなどの方法もありますが徹底は出来ていないです
    • issue での連絡が途絶えたときは「いかがでしょうか」と連絡することから始めます
  • 担当者別のカラムは作らない
    • 担当者のことが知りたいわけではなく、issue がどんな状態なのかを把握したいので、担当者(アサイン)別のカラムは用意しません
      • 担当者の状態が知りたいときは、担当者別の View を作って対応しています
      • ラベル別で View も作れるので、ラベルの管理を大事にしています
  • カラムを増やしすぎない。
    • カラムを増やしたいと感じる時は、1 つのカラムに issue が溜まっていて取りこぼすことが出てくる時のようです
    • カラムを増やす前に、issue が止まっている要因を取り除くことを優先します
      • 「左から右」に issue を進める方法が他に無いか模索します。例えば、他のチームにお願いできないか、人を増やせないか、取り組み方やゴールを変えられないかを検討します

issue を作成する時のコツ

  • とりあえず issue にする
    • issue にしないのは、プライバシーに関わることなど、秘匿性が高いものだけです
    • デザイナー採用の資料作成など、プロダクトに関係ないことも issue にしています
    • Slack やミーティングで取り組むことを決めたら、issue にします。特に、Slack で話して取り組むことを決めたら忘れずに、issue にします
  • 完了を定義する
    • 「バナーを作る。中身未定」という issue はよくあります。そのときは、要望がでてくるまで待ちます。もしくは、声をかけて、取り組みを具体的にするところから始めます
    • 方法だけ決まっていて、何をすればいいのかわからないときは、わかるようにしていく取り組みをします。例えば、issue で質問したり、ミーティングしてみるなどをして結果を issue に記載します
  • issue の種類を把握する
    • 急ぎ(ASAP)、Epic(複数の issue 達成で成立する )、不具合といった issue があり、別で管理できるようにラベルを付けています

GitHub Projects を運用してみて

運用していくなかで、大切にできていることは 2 つです。

  • 見える化する
  • フローを重視する

チームがどれだけ改善を実現しているのか一週間ごとで確認できるようになりました。同時に、連絡待ちや、急ぎの発生回数があるかも把握できるようになりました。 チーム外の人が見ても、詳しくは分からなくても、どのカラムにどれだけの作業があるのかはわかるようになっているハズです。

「左から右へ進める」ということを前提にしています。進めるための障害(デザインする時の悩み)が発生し、検知するためのイベントができ、検知したことを定例で話すようになってきたので、issue を進めることを大切にできるようになってきたと感じています。

もちろん、出来ていないこともあります。
また終わっていない issue があるのに、新しい issue に着手することがあります。取り組む issue を増やすのではなく、完了する issue を増やすことを優先できていないときがあります。終わらせることを優先したいのですが、確認待ちなどもあり、In Progress が増えている状態です。

おわりに

GitHub Projects を使ったチームのタスク管理についてまとめました。 やっていて、取り組まないといけないことが漏れていることは減りましたし、困っていることを見つけて、解決に進める機会が増えたことも感じます。

チームで成果をだせる体制を作り「食べチョク」の改善に活かしていきます。