先週よりチームメンバーも増え、そろそろJIRAを運用してしっかりとタスク管理をしなければ思ってチケットを書き始めた時のこと。
ざっくりと書いてみるパターン
まず最初に書いたのはこんな感じ
サブスクリプション課金システムを実装する
一人でガリガリコードを書いていた時は実際にこういうタスクをメモ帳に積んでいたので取り敢えず書いてみる。
しかしなんとなく違和感…
- ツールや実装方法は具体的に書かなくて良いんだろうか？
- 渡された人の「サブスクリプション課金」の実装に必要な要素の認識は私と同じだろうか？
自分の為だけに書いてあるのであればこれでいいのだが、「ロケットで月に行く」みたいな書き方に少し違和感があったのでもう少し詳しくなるように書き直してみた。
詳細を書くパターン
というわけで、実装方法やDB設計までをそれぞれのチケットに落としてみた
1. XXX（Stripeとか課金プラットフォーム）に開発用アカウントを作成する
2. サブスクリプション課金システムをフロントエンドから叩くAPIを実装
3. サブスクリプションのフロントエンドUIを実装
4. サブスクリプション課金成功時にフロントエンドからバックエンドへ通信するPost Subscription APIを実装
5. サブスクリプション課金成功時にフロントエンドからバックエンドへ通信した際にバックエンドへサービスへ課金確認をするロジックを実装
6. サブスクリプション課金成功時にバックエンドに課金ログを残すようにDB（subcription_logs）を実装
7. ユーザーの現在のサブスクリプション状況を確認できるようにDBを改変（userテーブルにis_subscribed:boolを追加）
8. サブスクリプション課金動作のテストケースを実装する（フロントエンド）
9. サブスクリプション課金動作のテストケースを…
とこの辺まで書いて気づくのが、これ全部書いてたらきりがない。
新規サービスの開発なのでもちろんサブスクリプションだけを作るわけじゃないし、実装内容をいちいち全部書いていたらチケットを書いているだけで1週間ぐらいかかってしまうと。
そしてもうひとつ書いていて思ったのが「これが本当に正しい実装方法なのか、自分の知らないもっといい方法があるのではないのか」ということ。このチケットは当然自分の知識がベースになっているので、必ずしも最良ではない可能性があるということに気づいてしまった。
実際、昔開発していた現場でも「チケットにこう書いてあるからそのまま実装する」という状態で、あとから別のもっといい開発方法を見つけることが何度かあった。
結局どうしたか
今までのチケットの書き方の問題点は
- 開発者としっかりと意思疎通できる内容であるか
- チケット内容が開発者の自主性やポテンシャルを阻害する要因となっていないか（マネージメント層の知識が組織のスキルキャップになっていないか）
と少々悩み、自分が以前Scrum Masterとしてチケットを書いていた方法で書き直してみる。それがこちら
1. ユーザーとして、サブスクリプション制の課金システムで課金ができるにする。
2. 運営として、各サブスクリプションの履歴を参照できるようにする。
3. 開発者として、サブスクリプションシステムが正常に動作しているか定期的にチェックしたい。
やや独特の書き方であるが書いてみてこれがやっぱり一番しっくりときた。
チケットに実際の実装方法を書かず、アウトプットの価値（とそれが誰に対してか）を記しているので、開発者に対して制限を設けず、かつその人の自主性を重んじる内容となる。このあと、アサインされた開発者はPull Requestベースで作業方針を示していく流れとなる。（その他必要条件がある場合は事前に1on1でフォローする）
Manifesto for Agile Software Developmentを振り返る
もちろんこの書き方の前提条件には、開発チームの全員がある程度のスキルレベルに達している必要がある。ジュニアレベルのメンバーや外部連携ではもっと詳細を書く必要があると思う。
ただ、少数精鋭の開発チームであればこれはアジャイル開発手法として有効なチケットの書き方だと思う。
アジャイルソフトウェアの根底にある考えは以下だ（Agile開発に携わったことのある人は耳にタコができるほど聞いたことがあるだろうけど…
- プロセスやツールよりも個人と対話を、
- 包括的なドキュメントよりも動くソフトウェアを、
- 契約交渉よりも顧客との協調を、
- 計画に従うことよりも変化への対応を、
上のチケットの書き方はScrum Master認定の講習会でも説明を受けるものだが、開発においてのこの4つの考えを守るのに最適なものだと考えている。
Agile開発をすでにしている方には当たり前の話かもしれないですが、久しぶりにAgile開発に戻ってきての嬉しい気付きでした。