お久しぶりです。
さて、私は開発関連タスクを作る際は、ストーリーとしてチケットを切ります。それで最近良くなかったなと反省した点があったので、雑記としてまとめてみます。そもそもこのブログ、雑感書くものですし、こういうのもたまには。
開発体制
既に動いているWebサイトを運営しつつ、中身はレガシーなので、その改善（撲滅？）を同時並行で行っています。
私が一応リーダーで、あとは新卒メンバーが一人、オフショアのメンバーが一人です。
やらかしたこと
オフショアにチケット渡して実施してもらったところ、思ったものと全く違うものが出来上がってきました。いや、その修正箇所は確かに例として挙げたけど、そこだけじゃないよ、と。
そのやり取り（英語）にかなりの時間を割いてしまい、結果自分の仕事が全く回らないという状況になりました。オフショアメンバーとしても、「そこもやるんかい…」みたいな気持ちになったのだろうと思います。
なんでなんだろう…と原因分析してみました。
ふりかえる
ちょうどオフショアのメンバーが交代になったところで、プロダクト知識が足りない部分はあったので、そのせいかなと思う部分がありました。
一通り実装が終わった後に、「そもそもストーリーに書いてあったこれってどうやって判別するんですか？」という質問が来ました。先に聞いてよ…と思う気持ちはありつつ答えましたが、自分にも悪い点があると思い、自分が作ったストーリーを見直しました。すると、
- 実現したいことは書いてある
- どこを直せばよいか書いてある
- どうなったら良いのか書いていない
という状況でした。いわゆる受入基準が無いな、と。
せめて一言、「これらのページで想定する挙動*1をしていること」というものがあると、「何をすればよいのか」明確になりそうだと思いました。
受入基準とは
英語では
Acceptance criteria
と言うそうです。『アジャイルサムライ』では「受入テスト」という形で出てきます。ちょうど見つけた、こんな記事も読んでみました。
この記事によると
Acceptance criteria are a formalized list of requirements that ensure that all user stories are completed and all scenarios are taken into account.
とのこと。抽出すると
すべてのシナリオが考慮されることを保証する要件の形式化されたリスト
という部分が肝です。
これをちょっと具体化すると、
- ○○のページではこのような挙動を取る
- △△のページでは（○○とは違って）このような挙動を取る
という形で記載できます。こう書くと、○○のページ、△△のページとは何ぞやという疑問が湧くはずなので、質問につながるかなと。
ストーリーの言語化や粒度は難しい
言語が共通*2なら、ある程度雑なやり取りでも、意味が通じます。
サイトの○○を変えてほしい
と言われたら、
ああ、この部分直せばいいんですね。この部分も同じですがそちらも同じようにしますか？
みたいな感じで、すぐに意思疎通できます。
これをオフショアなど外部者に依頼するために詳細に言語化しようとすると、抜け漏れが発生しやすいと思っています。抜け漏れに対する打ち手はあまり多くないです。
修正箇所まで明示したタスクまで落とし込んでから依頼するのか、受入基準を明示したストーリーをそのまま渡すのか、個人的には試行錯誤を続ける必要があるな、と思いました。
おわりに
今の体制で仕事を始めて、まだ二日です。それで課題が出るのはある意味好ましいです。自分で課題に気づいて、とりあえず打ち手を思いつけているので、健全だなと感じています。
ほんと、いくつになっても学ぶことばかりだと思う今日この頃です。
こんな記事、今後毎週書いていこうかと思っています。（ちゃんと書こうとするとまるで書けないので）
