この記事はBASE Advent Calendar 2022の9日目の記事です
同日公開の（この活動にも参加してくださっている） @yuripiiiii さんの「オンラインでのチームビルディングで意識をしていること」もぜひご覧ください！
ごあいさつ
はじめましての人ははじめまして、こんにちは！フロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です
今回の記事では1年近く継続して実施してきた、 プロダクトの細かな不具合や使いづらい部分を有志チームで改善していく「#iikanji-pkb-kaizen」という活動 についてご紹介します！
なかなか利益に繋がっているかが計測しづらく、組織の間にボールが落ちてしまいがちな細かい不具合対応や改善をチームとして対応するために「どのようなことを考えて」「どのように進めて来たのか」を共有することで、読んでいただいた皆さまの組織でも実践するヒントになれば嬉しいなと思っています！
周辺の環境
まず初めに、この活動を行っていたチームとそれを取り巻く組織について組織について紹介します。
#iikanji-pkb-kaizen の「pkb」とは
BASEというプロダクトに対して、様々な経路で受け取った改善要望をまとめている場所の「Product Kaizen Backlog（プロダクト改善バックログ）」の略称です。
現在はAsanaを使っていて、そこに予め用意したテンプレートの内容を埋めて、改善要望を登録してもらう形を取っています。
PKBがなかった頃は、CSへのお問い合わせで届いたフィードバック、BASEとしてショップ運営を有人サポートしているショップからのフィードバック、社内で気づいたちょっと気になる点などの様々な改善アイデア・改善要望が様々なツール上に散らばってしまっていました。
それらをまとめて確認出来るようにする場所を作ることと、正式なお問い合わせとは別に、ショップオーナー向けの管理画面下部から直接要望やフィードバックを送れる以下のようなフォームを作成するプロジェクトを遂行して現在の形になっています。
まだまだ運用方法を模索中ではありますが、一旦ここに蓄える。という場所ができたのは検索性・一覧性の観点からとても運用しやすくなりました。
組織構造の変化
この活動はもともと、 Owners Experience（以降、OXチーム）という「ショップオーナーさんのショップ運営の体験向上」にフォーカスした組織のメンバーが有志で集まって、 月曜朝と金曜夕方という、集中力が高まりにくい業務時間のウォーミングアップ&クールダウンとしてやりだした のが始まりです。 「プロジェクトのように数ヶ月単位でやるレベルじゃないけど、BASEへのお問い合わせなどでちょいちょい届く、BASEの使いにくい部分をガンガン改善していこう！」というモチベーションで始め、いずれ他の組織の人も集まっていければ良いね〜と実施していました。
そこから数ヶ月が経ち、ビジネス優先度と組織の全体最適化のために「目的別組織」への移行が進んで「OXチーム」という組織はなくなり、より具体的な「CRM」「Back Office」などの領域に紐づく目的別組織になりました。
結果として、現在では #iikanji-pkb-kaizen の参加メンバーは様々な部署から有志でPdM、デザイナー、バックエンドエンジニア、フロントエンドエンジニアが集まる形で合計6名で実施しています。
活動名の「iikanji」とは
BASEのSlackコミュニケーションにおける文化として、Slackチャンネルをサクッと作って特定のトピックをそこでガッとコミュニケーションを取ろうという文化がありました。
「iikanji」というのは、そのSlackチャンネルを作る時に「プロジェクトでもないし、かといって何かが決まってるわけでもない、モヤッとした課題感を "イイ感じ" に解決していきたい」という感覚値を表したワードで、いつからかこれをSlackチャンネル名にプレフィックスとしてつけることが社内で慣習になっています。（プレフィックスをつけることで、こういった社内の有志活動を見つけやすくするという意図もあります）
"#iikanji-pkb-kaizen" というチャンネルは上述の通り「OXチーム」がなくなったタイミングで、今までやってきた細かい改善の有志活動を引き続きやっていきたいという思いで作った形になります。
ちなみに、過去のテックブログには他にも #iikanji-agile や #iikanji-conference-toudan という活動について紹介された記事があるので、もしご興味があればぜひ読んでみてください！👀
運営してみてわかったこと、やったこと
ここまでで「#iikanji-pkb-kaizen」という取り組みがどういうものなのかを紹介できたので、ここからは実際にこの活動を運営していて考えたこと、チームで実施したことを紹介していきます！
9月のタイミングで行った振り返り
OXチーム時代から続けてきた活動が #iikanji-pkb-kaizen という名前に変わり、約半年がたった今年9月末にこの活動の振り返りを実施しました。 まずはその振り返りをしている中で改めて見えた、言語化が出来ていなかったけどぼんやりと感じていた課題感について共有します。
1. 活動時間だけで進捗を出せている感じがしない
これは週に2日1時間ずつ、それも週の頭と終わりの日に行っているので、ウォーミングアップとクールダウンという目的にはあっていたものの、活動の時間でタスクを進めるという目線だと、 思い出す時間の方が多くて作業が進まない… という声でした。
また、この会にはPdM、デザイナーの方も同じように参加してもらっていて、エンジニアに限らず彼らからも同様の声が上がっていました。
ですが、こういった声を振り返り会の中で深ぼってみると、それぞれ少し異なる原因があることがわかったので、2つの対応方針（後述）を決め運用してみることにしました。
2. 我々がやってることは新入社員向けオンボーディングタスクとなにが違う？ / カニバってない？
少し話は変わりますが、BASEではありがたいことに2021年から2022年にかけて、月数名のエンジニアが新入社員として入社してくださる時期が続いていました。 そんな中で1つ問題になるのが、 「オンボーディング時にプロダクションコードを触るきっかけになるちょうど良い粒度のタスクが見つからない問題」 です。
「オンボーディングタスクを探すこと自体も大変だけど、そもそもこの活動でそういったちょうどいいタスクを消化してしまっていたらどうしよう…」という思いも頭のどこかにあり、この振り返りで議題に上がりました。
これに関しては、話している中で上記 1. の課題と同時に解決する方法（後述）が見つかったので、それを試してみることにしました。
3. タスクの管理方法がやりにくい
これは、歴史的経緯と具体的なツールの話しになるので、あまり読者の皆さんの参考にならないかもしれません。
もともと #iikanji-pkb-kaizen では FigJam というホワイトボードツールに現在対応中のタスクを付箋にして貼る、作業が進んだら移動させる。という形を取っていました。 これは、チームやプロジェクトによってはAsanaを活用しているチームもあったものの、社内的にはまだ普及しきっていない + タスク管理をボードでカジュアルに行いたかった（+ 個人的な好み）ことから、 FigJam を使った運用を選択した形です。
しかし半年も経って、社内の覇権を握っているタスク管理ツールもツールに対しての参加メンバーの認識も変わってきたことから FigJam を使った運用はやりにくい！となったのです。 そのため、その場で FigJam のタスクボードはアーカイブとしてファイルだけ残した上で、Asana上で管理するように切り替えました。
振り返ってわかった課題とその解決策
- 活動時間だけで進捗を出せている感じがしない
この課題感に関する根本原因を深ぼってみたところわかったのは、 「なんらかの機能全体の体験の改善を行うには、活動時間がそもそも足りない（思ったよりも規模が大きくなりがち）」 ということでした。
具体的には、以下のように2つのパターンで問題が起きていました。 ① エンジニア主導で進める場合、 業務フローの理解や調査、他チームへの確認が多くなってしまう ため、結果的に実装だけでないところに手がかかること（回答待ちが発生してなかなか実装に進めないことも） ② PdM・デザイナーが対応していた作業は 「そこやるならついでにここも直したい→規模が大きくなってしまう」パターンと、「近いうちにプロジェクト側で代替の対応が入るから触らなくてOKとなる」パターンが発生する ことでした。
これらの問題は、有志メンバー以外のプロジェクトやチームとのすり合わせが必要なために発生していたので、 #iikanji-pkb-kaizen で取り扱うもののスコープをもう少し絞り、運営体制としてはもくもく会のような形に移行することにしました。
エンジニア側は 「ゴールが明確で、実装対応と進捗把握がしやすい不具合の解消を進める」。 PdM / デザイナー側は 「ショップオーナーから受け取ったフィードバックを整理し、対応方針・担当領域も含めてPKBのアイテムとして起票をする」 。 という部分にそれぞれフォーカスし、週2回もくもく会に集まったメンバーでそれぞれ上記のような対応をしつつ、別の職能の知識が必要な場合はもくもく会で適宜質問をし合えるという形に切り替えました。
運用方式を変えて得た効用
エンジニア側
エンジニア側で対応する「不具合」には以下のようなものが含まれるのですが、これらの対応は短い時間でも対応しやすく、サクサクとリリースすることが出来ました。
- 納品書ダウンロード App でダウンロードできるPDFファイルの決済方法の表示部分だけ外国語対応されない
- 商品詳細登録画面のスマホビューのときにだけ表示されるボタン文言が旧式の呼び方のままだった
- レビュー App の設定項目が新しいデザインテーマだと不要なのに表示されてしまっていた
などなど…
これまでに対応したものの中の一部ですが、上記であげたような細かな不具合は短い時間で解消〜リリースまで完了することが出来ました。
PdM・デザイナー側
こちらの運用方式の変更を図解すると、以下の図の紫色の枠で囲った部分をガンガン進めていくぞ！という形です。
この活動を行うことで、今までよりも対応要望の詳細度が上がったバックログアイテムがPKBに積まれることになります。 これによって #iikanji-pkb-kaizen に参加しているエンジニアが対応しやすいバックログアイテムが増えるというメリットはもちろん享受できたのですが、副次的に
- 我々がやってることは新入社員向けオンボーディングタスクとなにが違う？ / カニバってない？
という課題に対しての解決策にもなりました。
図では以下の紫色の枠で囲った部分が増え、オンボーディングタスクが必要な時はPKBから探す。という運用がしやすくなりました。
まとめ
以上、プロダクトの小さな負の部分を解消する「#iikanji-pkb-kaizen」という活動についての紹介でした！ こういった有志活動は「こうすれば活動がうまくいく！」「これが絶対的な正解だ！」というものを見つけるのはなかなか難しいと思っていて、会社全体の組織状態に合わせて臨機応変に対応していきながら、 なによりも継続し続けること が一番大事だと思っています。
なので、BASEでも1年近く有志活動をしているとこんな状況になって、こういうことを考えて解決していったよ！というケーススタディの材料として皆さんに知ってもらえればよいなと思ってこの記事を書かせていただきました。 今回紹介できた内容は、会社組織の状況に対するかなり対処療法的なものばかりでしたが、少しでも皆さんの参考になれば幸いです。
明日は同じチームの shiiyan さんの記事です！お楽しみに！
