小さなタスクで管理する（続き）
前編の最後では、製品やサービスを改善するために、作り替える回数を増やす、つまりソースコードのコミット回数を増やすことを考えました。まずは、そのために管理するタスクを小さくし、数を増やす方法について、Jira Softwareを使った例で示します。
ユーザストーリーで起票する
Jira Softwareのバックログ機能で、ユーザストーリーを課題（チケットやIssueとも呼びます）に起票してみます（図1）。ユーザストーリーとは、要求を次のような言葉で記述したものです。
- ユーザとして
- *****をしたい
- なぜなら……だからだ
図1 Jira Softwareの「バックログ」機能
「ユーザとして、*****をしたい」はそのストーリーのゴールとなり、「なぜなら……だからだ」はゴールのために満たすべき条件を決める指針となります。
相対的なポイントで見積る
ユーザストーリーの見積りは、ストーリーを完了するために必要な相対的なポイントで算出します。ポイントの付け方は、最も難易度が低いストーリーを1として相対的に見積ります。見積りは過去の経験則などが参考となりますが、個人の意見に偏るのではなくチーム全員が合意して決定します。
ストーリーでは「重要度」を見積れます。早めのリリースが求められている機能など、優先的に取り掛かりたいストーリーはバックログの上に配置します。
スプリント計画
チームの作業を一定期間に区切ったものをスプリントと呼び、通常は1週間や2週間くらいとします。
バックログのストーリーから次のスプリントで実施する課題を選びます。「優先度」が考慮されていれば、上から順にピックアップします。スプリントで対応可能なストーリーの数は、これまでのスプリント実績（ベロシティ）を参考にします。
ストーリーをタスクに分割する
ストーリーが決まったら、作業タスクに分解します。ユーザストーリーの実現に必要な作業を箇条書きにし、1日以内で完了するタスクを作成していきます。
タスクと開発ツールのリンク
Bambooやバージョン管理としてBitbucketを利用していると、Jira Softwareの課題でビルドやコードのマージ状況が表示され、タスクやストーリーが製品やサービスに反映されているか確認できます。
テストを管理する
製品やサービスを繰り返し作り替えていくために、テストの自動化は不可欠です。しかし、すべてのテストを自動化することは難しく、ユーザの視点、テスターや有識者の経験を基に手動テストを実施することも必要です。テストの観点を判断し、効率よくテストを管理することが重要です。
振る舞いからテストコードを作る
テストの自動化にはテストコードが必要ですが、これはJira Softwareのユーザストーリーやタスクの完了条件を“振る舞い”として捉えることで作ることができます。
Jira Softwareのユーザストーリーやタスクから作るテストコードは、JUnit、Selenium、Cucumberなどのテスティングフレームワークが利用できます。
このように作成したテストコードは自動化に利用する以外に、タスクを着手するまでに用意して「正しく動くコードを作る支援」にも利用できます。つまり先にテストを作り、テストが成功するようにプロダクションコードを作ることができます。
手動で行うべきテスト
自動化できないテストとは、“振る舞い”や“完了条件”が明確ではないケースやビルドだけでは検査できないケースが挙げられます。
具体的には、探索的テストのようなテスターの経験やユーザの視点を基に手順を臨機応変に変えながらバグを発見するテストや、パフォーマンステストやセキュリティテストなど、動作環境へデプロイしてから実施するテストです。
このようなテストでも初めて実施したときの操作記録などを活用して、一部をスクリプト化し、次回以降は自動化できるように支援するツールもあります。
コーディングの文化を変える
最後に、コーディングとコードレビューの効率化について考えたいと思います。結論から述べると、チーム全員でソースコードの共同所有の意識を持つことこそが重要と考えます。
コードレビューの目的は「コードの書き方の安心感を得る」ため
「コードの正しさ」のチェックは、前述したとおり、静的解析や自動テストで実施することで不要となるので、コードレビューの目的は「きれいなコードが書けているか」というリファクタリングの正しさを確認することにあると思います。
レビューではなくみんなでコードを作る
「きれいなコードが書けているか」を目的とするのであれば、レビューは行わずにコードをチームで書くことでも解決すると考えます。みんなで議論しながらコードを書くことで、チームとしてきれいだと判断できるコードにすることができるのと同時に、メンバー全員がコードに対して同じレベルで認識を共有できるようになると思います。
繰り返し作り替えることに強くなるために
今回の例によって、開発工程は次のように変わりました。
- 【ユーザストーリーとタスク】＞【みんなでコーディング】＞【ビルド（自動テスト）】 ＞【手動テスト】
このような大きな変革には長い期間を要しますので、重要だと思うことから始めていけばよいと思います。
リックソフトでは今回ご紹介したツールの販売および導入支援などのサポートを行っています。みなさまのサービスや製品の価値を向上するためのお手伝いが必要でしたら、ぜひともご相談ください。
次回は、リリースや運用面における継続的な改善によって価値を見つけるための実践例を紹介します。
米国Atlassianから、2年連続で
「Top new business APAC」を受賞。
Atlassianセールスパートナーとして
アジアパシフィックで1位の証
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、各アトラシアン製品の体験版を提供しているほか、アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては！
- リックソフトJIRAデモ環境
- https://www.ricksoft.jp/demo/
- 第1特集
MySQL アプリ開発者の必修5科目
不意なトラブルに困らないためのRDB基礎知識
- 第2特集
「知りたい」「使いたい」「発信したい」をかなえる
OSSソースコードリーディングのススメ
- 特別企画
企業のシステムを支えるOSとエコシステムの全貌
［特別企画］Red Hat Enterprise Linux 9最新ガイド
- 短期連載
今さら聞けないSSH
［前編］リモートログインとコマンドの実行
- 短期連載
MySQLで学ぶ文字コード
［最終回］文字コードのハマりどころTips集
- 短期連載
新生「Ansible」徹底解説
［4］Playbookの実行環境（基礎編）
