こんにちは！ 広報の山口真央（やまお）です。

GIGでは毎月さまざまなテーマで勉強会を開催しています。

コロナウイルス感染症の影響で、リモートワークの導入など、「働き方」は大きく変わりました。1年以上続くコロナ禍を経て慣れも出てきたと同時に、「やっぱり改善したほうがいい！」というポイントが把握できるようになってきた部分もあるでしょう。

GIGでは、よりよい「プロダクト」や「チーム」を目指し、日々改善を行っています。

今回の勉強会ではGIGを代表し、Workship事業部の部長、石倉さんが試行錯誤しながら取り組んでいるカイゼンポイントをご紹介。とくに取り入れてよかったものをシェアしてくれました！

■登壇者プロフィール

石倉 彰悟（いしくら しょうご）

Workship開発チーム・カスタマーサポートチームのマネージャー。ソーシャルゲーム開発を行うSAPでカスタマーサポートとして従事した後にエンジニアに転身し、大規模決済システムやEC系Webサービス等の構築を経験。2018年にGIGにジョイン。

Workshipチームが「カイゼン」のために取り組んだこと

コロナ禍以前は、対面で「あれをやってほしい」「こうしてほしい」といった会話がすぐにできたGIGのチーム環境。しかし、リモートワークの導入で、全体スケジュールが見えにくくなったり、チャットツール上でのコミュニケーションだけでは掴みにくい細かなニュアンスが反映できなかったりと、課題が現れました。

そこでWorkshipチームでは

1. スクラム開発とJira導入
2. プルリクエストにラベルをつける
3. お問合せ状況報告

といったカイゼンを導入。今回はその手順と、導入した意図、実際に導入してみてよかったことをご紹介いたします。

1. スクラム開発とJira導入

「スクラム」とは、「チームで仕事を進めるための枠組み（フレームワーク）」のことです。具体的には、「スプリント」と呼ばれる開発期間を区切ってチームのタスクを整理したり、チーム全員で進捗を確認する「デイリースクラム（朝会）」などを行ったりします。

Workshipチームでは

• スプリント（開発期間）を区切る
• 朝会（デイリースクラム）の実施
• 定例（スプリントレビュー）の実施
• KPT（スプリントレトロスペクティブ）

の4つの段階に分けて「スクラム開発」を導入しました。それぞれについて詳しく見ていきましょう。

スプリント（開発期間）を区切る
「この1週間は○○の開発をします」と開発期間を区切ることで、自分が今何をすべきなのかわからないという状況をなくし、目の前の集中すべきタスクを明確化。どのタスクから着手すべきかもわかりやすくなりました。

朝会（デイリースクラム）の実施
進捗をチーム全員で把握する朝会を実施。チームメンバーそれぞれのタスク進捗を確認するほか、気軽に話せる機会を毎日設けることで、チャットツールに載せるまでもないと思っていた小さな悩みも共有できるように。スピード感ある解決に繋がります。

定例（スプリントレビュー）の実施
スプリントの終了時に定例を開催し、スプリントの進捗、リリース情報の共有をすることで、自分以外が担当したリリース内容なども理解できるようになり、さらに次のスプリントでやることの共有も可能になりました。

KPT（スプリントレトロスペクティブ）
KPTとは「Keep」「Problem」「Try」からなるふりかえりのフレームワーク。今後も続けるべきこと（Keep）、今抱えている問題（Problem）、次に挑戦したいこと（Try）を明確化することで、チーム内の改善がきちんと回転するようになりました。

石倉：「とくにWorkshipチームはKPTの『T』に対して積極的に行動できており、これが次のスプリントを活性化させることに繋がっています」

また、スクラム開発と合わせて「Jira」を導入したことも注目ポイント。「Jira」とは、開発プロジェクトの計画、追跡、管理を行えるソフトウェアのことです。Workshipチームでは、全体のスケジュールをガントチャートに起こせる「ロードマップ機能」や、スプリントごとにタスク管理ボードを作成できる「ボード機能」を使って、スケジュールやタスクを「見える化」。朝会や定例の際にはこれらを見ながら進捗を共有しているんだそうです。

2. プルリクエストにラベルをつける

次に「プルリクエスト」のラベル付け。「プルリクエスト」とは、レビュー担当者に開発者がレビューを依頼し、レビュワーが改善点を見つけることで品質の高いコード作成を目指すことを指します。

コードは複雑なため細かいところまで指摘するとキリがないほど。ですがその細かすぎる指摘がコードの質を高めていくのも事実です。レビューを依頼した側からすれば「細かすぎるプルリクエストの指摘を、どこまで対応すればいいんだろう」と迷うことも多く、レビュワー側は「細かい指摘をすべきなのはわかっているけど、ちょっと心がいたむ……」といった悩みもあるようです。

そこでWorkshipチームが導入したのが「ラベル」です。たとえば以下のようにラベル付けをします。

[must]必ず対応してほしいこと
[imo]自分の意見や提案・好み
[nits]些細な指摘。できれば直してほしいこと
[ask]質問や確認。コードの意味や背景の確認

石倉：「プルリクエストに対してラベルを付けることで、レビュワーの温度感や考えも一緒に伝えられるようになりました。『ここは絶対直して』『これは提案なんだけど、どう？』といった認識を合わせられるようになり、レビュワーも『ここまで言ったら失礼かな？』と考えることなくレビューができます」

3. お問合せ状況報告

最後に「お問合せ状況」を確認すること。『Workship』にはユーザーから毎日さまざまなお問合せが寄せられるのですが、その内容をチーム全体に毎日共有しています。

実際にお問合せの対応をしているのは『Workship』のサポートチームですが、プロダクトの運営チームであるWorkshipチームと密に連携をとることで、プロダクトの把握や改善の材料になるようにと始めました。

結果、お問合せの内容を見ながら「この意見は多いから対応しよう」とプロダクトへの反映に繋がっています。

まとめ

今回は、Workshipにおけるカイゼンポイントをご紹介いたしました。

カイゼンを通して、どんなサービスが作られているのか気になった方は、ぜひ「Workship」を覗いてみてくださいね！

Workshipはこちら

GIGでは、Workshipチーム以外でも社内のワークフローやプロダクトをよりよいモノにするため、毎日試行錯誤でカイゼンを行っています。今後も、ユーザーのみなさまに価値あるサービスをお届けするために、こうした取り組みを行っていきます！

GIGではgood is goodなチームを築ける仲間を募集しています！

現在、GIGでは「一緒に学びながら成長していきたい！」と意欲のある仲間を募集しています。 詳しく話を聞いてみたい方はコチラからどうぞ！

山口 真央（やまお）

1995年生まれのフリーランス編集/ライター。GIGの広報をお手伝いしています。 お酒と野球と深夜ラジオとドライブと…と好きなことがありすぎて、結局お酒にもどってくるを繰り返し中。