えもいブログ

AIトラベルのCTOをしています。n=1 の事実をもとに思うがままに書きます。emotionalだったり、そうじゃなかったり。

チケットを書く技術

まだまだAIトラベルは小さな組織なので、要求分析・要件検討・システム/データ設計・チケット作成のようなコード書く前工程を多くの場合、僕が受け持っています。 最近、ディレクタの方にジョインしてもらい、チケットを作成する仕事は少しずつ僕から剥がれはじめてきました。

本格的に僕がその作業から離れる前に、僕が今まで蓄積してきたチケットを書く技術をテーマに本記事を書いてみようと思います。

注1) ここでは、技術調査やリファクタリングのような、技術寄りの問題を解決するチケットの話ではなく、ビジネスサイドと新規機能開発を進めている文脈でのチケット作成の話を書きます。技術寄りのチケットを作成をするときは全く別のテクニックが要求されますが、今回はスコープから外します。

注2) タスク管理、プロジェクト管理のためのチケットを書く技術もあるのですが、こちらもスコープから外します。

注3) B to B のサービスを提供している文脈で記載しています。B to Cのサービスでは必ずしも当てはまらないことを書いているかもしれません。

この記事の内容を一言で言うと

チケットはエンジニアとのコミュニケーションを取る1手段でしかなく、チケットを書くモチベーションとなった背景と、何を達成したらそのチケットを解決したと言えるかをきちんと言語化しましょう。

というお話です。かなりあたり前の話を書いている気もしているので、そうだよね〜と思われた方にはあまり価値を提供できないかと思います。

チケットを書く目的

チケットを書いて達成したいことって、少なくともビジネスサイドから見ると、エンジニアに作ってもらいたいものを伝えるためにあるんじゃないかなと思います。

作ってもらいたいものを伝えるためには、

「結局何が作られていたら、完成と言えるか。」

を定義することに尽きます。

世の中的な言葉で言うと、受け入れ条件の定義というものかと思います。

受け入れ条件を書く前に・・・チケットを書こうと思う背景となった情報の共有を頑張る

チケットの受け入れ条件を本当に細かく書くと、ほとんどプログラミングをしているんじゃないかと錯覚するぐらい、内容を詳細に書くことができます。 その代償としてチケットを作成するための工数が沼のように消費されます。

一方で、ざっくり書きすぎると、欲しいものとズレたものが出来上がってしまったり、そもそもエンジニアが手を動かす前に終わらない質疑応答の打ち返しが発生して、お互いのストレスがすごいことになりますw

この悲しい状況を減らすために効果が大きいのは、受け入れ条件を定義して伝える前に、下記の2つを明確にして共有することです。

  1. 機能開発が必要になった背景
  2. 機能により達成されるユーザの業務/シナリオ

例(あくまで一例です。)

機能開発が必要になった背景

○○会社の〇〇さんが、○○の状況で、○○を行うという業務が存在する。
現状は、○○という作業を行っているが、明らかに非効率である。
我々のサービスはそれを解消できる余地があるため、これに取り組みたい。

機能により達成されるユーザの業務/シナリオ

1. ○○さんが○○という業務をする。
2. 今回作成する○○という機能を利用して、情報を登録する。
3. ○○という機能で作成された情報が○○というサービスに自動で連携される。

これにより、ユーザの○○の業務における非効率な作業を取り払うことができる。

できるだけ具体的に書き、誰が見ても、あーこの問題は解決してあげたほうが良いなと思える文章が書けると上出来です。

ここがきっちり書けていると、経験豊富なエンジニアがよりイケている解決案を出してくれることもあり、とても生産的な時間を過ごせることもあります。 また、多少受け入れ条件がざっくりしていても、エンジニアが察してくれます。(あまりやっちゃダメですよ。)

受け入れ条件の定義

「どうであれば、リリースしても問題ないか?」を具体的に書いていきます。

作りたい機能によってケースバイケースな部分はありますが、下記の3つが揃っていれば、ほぼ大丈夫だと思います。

  1. 画面のモック
  2. どういうときに、システムがどう振る舞うか
  3. どのようなデータが蓄積され、どのように利用されるか

もちろん、チケットを書く目的にあるように、エンジニアの人にきちんと作りたいものが伝わればそれでよいので、適切に手を抜くのも重要かとは思います。

ただし、ここを手を抜きすぎると、受け入れテストを行うときに、あれ?何を確認したら良いんだっけ。。?ってなるし、コミュニケーションの齟齬が高確率で発生するので、慎重にサボる必要があるとは思いますw

最後に

いいチケットは、チーム内のストレスの総量を減らし、機能開発のスピードをいい感じにしてくれると思います。 さらに、ビジネスサイドとエンジニアサイドの建設的な議論の土台になります。

実際のところ、チケットはあくまでもコミュニケーションの手段なので、いくらでも簡素にはできると思います。

でも、チームでプロダクトを開発する上で、とても大切な要素だと思いますので、もし何か開発がうまく回ってないなぁと思うことがあれば、見直してみると良いことがあると思います。

AIトラベルでは、ソフトウェアエンジニアだけでなく、素敵なチケットを書いてプロダクトの開発を加速させることができるプロダクトオーナも募集していますので、ぜひご連絡ください。