こんにちは。クックパッド特売情報ディレクターの田中です。
前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。
チームが大きくなってきてヒズミが生じてきた
本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根性で対応していましたが、それでも本質的には問題が解決しませんでした。
施策の完成度80%でissueを書くことで周囲を巻き込む
そこで、自分自身で100%と思われるまで施策を考えるのを諦め、開発案件の骨子のみを簡潔にまとめた80%の段階でissueを早く立てるようにしました。 私の場合は下記の要件だけをまとめて立てることが多いです。 この時、よほど確定的な機能や案件以外では詳細な遷移図や画面イメージを作成することはありません。
# タイトル 施策の呼称 名前が仮の場合はその旨も記載する ## 概要 施策の背景と狙い ### ユーザーストーリー ユーザーが直面している課題と施策による問題解決の内容 特売情報では下記のフォーマットを利用することが多いです 「『具体的なユーザー』は 『〇〇したい』(疑いの無い欲望)が 『□□で出来ない』(欲望の障壁となっている問題)ので 『△△することに価値がある』(施策による問題解決の具体的内容)」 ### シナリオ ユーザーが何をみて、何を感じ(考え)、どんな行動をとることで問題が解決されそうか ## どうなったら成功か 施策の効果検証方法 ### 成功のイメージ 施策が成功した時、ユーザー・クライアント・サービス提供者がどんな状態になるか ### KPI 成功のイメージは何によって定量評価できるか ## その他 ### 未決定の問題 仕様が詰まりきっていないと自覚している点、技術観点での懸念などをまとめる ### リリースフロー リリースまでに解消する必要がある検討事項・承認事項をまとめる
一見、詳細が詰まっていないがためにエンジニアやデザイナーに負担をかけてしまう様に思いますが、早い段階でissueを立ててアウトプットした方が結果的に開発前に仕様をブラッシュアップすることができ、開発がスムーズに運ぶことが分かってきました。 その理由は下記３者のレビューを早い段階でもらうことができるからです。
エンジニア
ディレクターが詳細な仕様を詰めたものの、「これは莫大な時間がかかる！」「現実的じゃない！」「エンジニアは魔法使いじゃない！」と手戻りが発生することは少なくありません。 開発に着手するよりもかなり早くissueを立てることで、
ボトルネックの洗い出し
現時点で着手している案件とのコンフリクトの回避
を行うことが可能です。特に1.に関しては、工数を膨らませる可能性のある要因を事前に把握できることで、仕様を最適化したり、技術的なアプローチに頼らなくてもディレクターが手を動かせば解決可能な箇所に先んじて手を入れることができるはずです。
デザイナー
弊社では施策のユーザーストーリーとシナリオを定義することが多いですが、これはデザイナーとのコミュニケーションを円滑化するのにも役立ちます。私は、手書きで手早くまとめることができ、かつデザイナーに意図を伝えやすいことから、シナリオをユーザー遷移図で表現することが多いです。
これらの施策の要諦さえブレないように定義しておくことで、
UX設計の妥当性の評価
表現方法のバリエーションの提示
を事前にアドバイスしてもらうことが可能です。これらを踏まえて仕様を練りなおしたり、画面イメージを構築することで、デザイン・開発にボールが移った時の手戻りを最小限に留められます。
第三者
早くissueを立てることで実際に開発に着手するまでの時間が長くなるため、多くの人のレビューを受けることができるようになります。施策が直接影響する部署からリスクを事前に洗い出してもらうことが出来たり、直接施策に関わりのないと思われた部署のエンジニアから、より良い技術的なアプローチを提案してもらうことが出来たこともありました。
まとめと注意点
今回は、私が複数のエンジニアと開発を進める上で工夫しているissueの立て方をご紹介しました。 一つ注意していただきたいのは、早く要点をまとめたissueを立てることが重要なのであって、早く雑にissueを立てることを推奨しているのではありません。特に自分でも経験がありますが、骨子が明確になっていないと、当初自分が意図していたものから大きく議論が膨らんで収集が付かなくなってしまうことも少なくありません。 自分自身でもより良い方法を模索している最中ですが、同じような境遇にある方のお役に立てれば幸いです。
