FAKELOG

思うがままに書き殴るブログ

イイカンジの Issue 運用を求めて

先日、スシローパビリオンのふりかえりを実施しました!プロジェクトのふりかえり自体、久し振りだなっ!という感じでしたが、今回は、ファシリテーターとして @lycoris102(ととちゃん) を迎え入れたことにより、とても濃ゆいふりかえりをすることが出来ました〜!ととちゃん、どうもありがとう!

ととちゃんによるふりかえりに関するまとめ記事、オススメなので貼っておきますね。

lycoris102.hatenablog.com

さて、このふりかえりの中で良かったことも悪かったこともたくさん出てきたんですが、その中でも Keep として挙がり、みんなの共感を得た Issue の運用周りのことについて書いてみたいな〜と思います。

ところで、スシローパビリオン is なんなの?

私が所属しているキッズスターで開発している社会体験アプリ「ごっこランド」では、実在する企業様に協賛して頂いて、その企業様独自の子ども向けコンテンツを企画・開発して無料で配信しています。その子ども向けコンテンツの一つとして、先月、「スシローのおすしやさんごっこ」をリリースしました!

www.youtube.com

2018年4月現在、全国各地のスシローさんの実店舗にて告知もしていますので、お近くにスシローの店舗があるみなさまは、ぜひ、美味しいお寿司を食べに行って満腹になったあと、子どもと一緒にプレイしてもらえたら嬉しいですっ!

で、このスシローパビリオンの開発を私が担当していて、無事にリリースしたあと、ふりかえりを実施したよ!というお話しですね。はい、前提、終わりっ!

それでは、Issue 運用に関するアレコレについて書いていきます。

カンバンスタイル

キッズスターでは、Waffle を導入しています。そのため、全社員、パートナーさんが、この Waffle を通して Issue にアクセス出来るようになっています。

f:id:fakestarbaby:20180410214304p:plain

Waffle を導入してから一年くらいが経ち、少しずつやりやすい型みたいなものが見えてきた感じです。

まずは、それぞれのリストの役割について確認してみましょう!

リスト名称 説明
Backlog 直近ではやらないよ
ToDo 直近でやるよ
ディレクター作業中 ディレクターが作業しているよ
デザイナー作業中 デザイナーが作業しているよ
監修中 協賛企業様が監修しているよ
エンジニア作業中 エンジニアが作業しているよ
ビルド待ち 対応完了してビルド待ちだよ
社内検証中 ビルド完了して社内検証しているよ
社外検証中 社内検証完了して社外検証しているよ
Done 検証完了したよ

基本的には、手戻りが無ければ、左から右に Issue が流れて行き、対応されて、ビルドされて、検証されて、クローズするという弊社の開発のワークフローに沿った流れになっています。

アサインと指示を明確にする

スシローパビリオンの開発では、アサインと指示を明確にすることを心掛けていました。

ここでは、運用の一部を例に挙げて説明します。

例えば、ビルド待ちリストには、対応済みだけどまだビルドされていない Issue たちが並んでいます。エンジニアがビルドする必要があるため、このときのアサインはエンジニアになっています。

f:id:fakestarbaby:20180412095254p:plain

エンジニアがビルドすると、DeployGate に IPA / APK がアップロードされます。この時点で、ビルド待ちリストに待機していた Issue たちを、社内検証待ちリストへ移動します。社内検証は、ディレクターのタスクとなります。そのため、このタイミングで、アサインをエンジニアからディレクターに漏れなく変更します。

f:id:fakestarbaby:20180410215419p:plain

このとき、アサインされただけでは、当人は何をすればいいのか不明瞭なので、きちんと、そのひとにして欲しい指示を書きます。ここでは、検証をして欲しいのですが、DeployGate にアップロードされているどのビルドで検証すればいいのか、指示を出してあげる必要があります。指示を出さなかった場合は、ディレクターからどのビルドで検証すればいいのか?という質問が飛んで来ることになるし、そのころにはもう、どのビルドに対応が入っていたか思い出せなくなっているかもしれないので、すぐ指示を出した方がいいですね。

アップロードされたビルドには、バージョン番号が付与されているため、そのバージョン番号を添えて Issue に追記します。更に、メンションも添えています。

f:id:fakestarbaby:20180412003635p:plain

手動で全部やるの大変なんですけど、こうして一つ一つ Issue を開いてコメントして行くことにより、検証するポイントや、やり方などの細かい指示出しをする必要があることに気付けたりもするので、自動化することだけが解決策じゃないかもな、という印象もあったりします。(これは今後の課題)

とにかく、自分の手を離れて、誰かに何かをして欲しいときは、アサインを変える、指示を出すということを徹底していました。

気付ける仕組みを整えておく

キッズスターでは、自分が Issue にアサインされたり、メンションされたりすると、Slack に通知が飛んでくる仕組みを導入しています。これにより、アサインを適切に切り替えていくことで、自分に何かのタスクが割り当てられたことに気付けるようになっています。

f:id:fakestarbaby:20180412095455p:plain

この仕組みは、技術顧問の @ppworks(こっしー) 作のこちらのツールを利用しています。

github.com

ノーアサイン is 放置されがち

たまに、誰もアサインされていない Issue を見かけることがありますが、放置される原因になり得るので、その時点でボールを持っているべきひとをアサインしておくといいですね。

今、誰が、何をしているかを可視化する

自分が作業するときに、Issue をちゃんとリストへ移動する、という基本的なところも大事ですね。今、誰が、何の Issue を抱えているのか可視化出来て便利です。たまに、リストへ移動しないまま Issue に取り掛かるひとが居ますが、自分の Issue を管理するという意味合いでも、きちんとリストへ移動してから着手する、ということを意識した方がヨサソウです。

あと、誰しも人間なので、たまに、Issue を移動することを忘れてしまうこともあります。そういうときは、それに気付いたひとが「あれ、これもう作業中でしたっけ?」と声掛けして「ああ、忘れてたよ、ゴメンゴメン〜!」みたいなフォローが出来ると、なお、ヨイですね!

気付いたらすぐ Issue を立てる

検証に回す前に気付いたことがあれば、躊躇なく、Issue を立てるようにしていました。

例えば、この画面のこの部分はまだ未実装である、ということが分かっているなら、それを Issue として立てておくようにしていました。

こうすることで、ここはまだちゃんと動いてないですよ!という事前共有になります。ここが事前共有されていない状態で検証を始めてしまうと、ちゃんと動いてないけど、バグかな?という Issue が立てられて心配されてしまいます。事前共有さえ出来ていれば、検証する際に、その部分はまだ未実装であるという体で検証を進められます。

また、事前共有することで、今は未実装だけど、これから、実装する意思があるよ!という表明にもなります。遅かれ早かれ Issue として立てられるのなら、気付いたひとがすぐ立てようという話しです。

あと、すぐ書いておかないと、すぐひとは忘れる。

もやもやした気持ちを表明する

なんかちょっと気になったんですよね!っていう、ちょっとしたもやもやの気持ちを表明するため、勝手に、もやもや Issue を立てていました。

f:id:fakestarbaby:20180410221020p:plain

あ〜、もやもやするー!

自分の中に明確な答えや対応方法が思い付いてるわけじゃない、でも、なんかこう、ここがもやもやするんすよ!っていうとき、あるじゃないですか。そういうときに、ゆるく立ててみて、まずは、みんなの意見を伺ってみるという感じで利用されていました。

f:id:fakestarbaby:20180410221621p:plain

するね、するね、もやもやするねー!

私以外のひとも、結構、もやもやしてましたね。

f:id:fakestarbaby:20180410221154p:plain

分かるー!見えるー!左寄りに見えるよー!もやもやするー!

f:id:fakestarbaby:20180410221334p:plain

いいねー!いいもやもやだね〜!

という感じです。

このもやもや Issue から、ブラッシュアップに繋がっていった事例もたくさんあるので、もやもやの表明は大事です。ポイントは、何でも言っていいんだぞ!という心理的安全性が築けているかどうかですかね。

社外検証も同じ Waffle 上で進める

世間には、社内で検証するには足りないくらいの端末がリリースされていることもあり、他端末検証は、外部の会社に委託して検証して頂いています。

そこで上がってくるバグ報告なども、我々が利用している Waffle をそのまま公開していて、そこに直接書き込んでもらうという運用にしています。

最初は書き方などが分からず、Issue のタイトルで事象を全て言い切ってしまうということも見受けられましたが、Issue はこう書いて欲しいですという要望や、運用方法について記事にして共有することで、次第に精度は高くなり、社内と同じレベルで Issue のやり取りが出来るようになって来ました。

以前は、バグ報告専用のツールを導入していたため、運用につらみを感じていましたが、今はツールが統一されてムダの無い社外検証が出来るようになったと思います。

タイトルには、画面名とシンプルな事象だけを書く

スシローパビリオンの Issue の一部は、こんな感じになっていました。

f:id:fakestarbaby:20180410221855p:plain

先頭に該当する画面名を、そのあとに続いて事象を書き出すスタイルに統一されていて、どこの話しをしているのかが一目瞭然で分かりやすかったですね。プロジェクトメンバーの中に一人でもこれを意識しないで Issue を書くひとが居たりすると、統一感が無くなってしまうため、そういうときは、定例などで周知するといいかもしれません。

まだまだ、改善の余地はある!

Keep で出て来た良い側面だけを取り上げてみましたが、当然、もっとここをこうしたいな!という課題も色々とあります。

例えば、ビルド待ちリストから内部検証中リストへ手動で移動させる手間だったり、DeployGate のバージョン番号を調べて記載する手間だったり、Issue のフォーマットが不明瞭だったり、まぁ、色々とあります。

ここはもう日々、改善だと思うので、無理なく自然に仕事が進められるよう、今後も定点観測して行きたいな!と思います。