業務を改善する情報共有の仕掛け~DevOpsの実現,RPAの導入に向けて~

第4回 ツール活用で文化(カルチャー)・習慣を変えてみよう(後編)

この記事を読むのに必要な時間:およそ 1.5 分

小さなタスクで管理する(続き)

前編の最後では,製品やサービスを改善するために,作り替える回数を増やす,つまりソースコードのコミット回数を増やすことを考えました。まずは,そのために管理するタスクを小さくし,数を増やす方法について,Jira Softwareを使った例で示します。

ユーザストーリーで起票する

Jira Softwareのバックログ機能で,ユーザストーリーを課題(チケットやIssueとも呼びます)に起票してみます図1)⁠ユーザストーリーとは,要求を次のような言葉で記述したものです。

  • ユーザとして
  • *****をしたい
  • なぜなら……だからだ

図1 Jira Softwareの「バックログ」機能

図1 Jira Softwareの「バックログ」機能

「ユーザとして,*****をしたい」はそのストーリーのゴールとなり,⁠なぜなら……だからだ」はゴールのために満たすべき条件を決める指針となります。

相対的なポイントで見積る

ユーザストーリーの見積りは,ストーリーを完了するために必要な相対的なポイントで算出します。ポイントの付け方は,最も難易度が低いストーリーを1として相対的に見積ります。見積りは過去の経験則などが参考となりますが,個人の意見に偏るのではなくチーム全員が合意して決定します。

ストーリーでは「重要度」を見積れます。早めのリリースが求められている機能など,優先的に取り掛かりたいストーリーはバックログの上に配置します。

スプリント計画

チームの作業を一定期間に区切ったものをスプリントと呼び,通常は1週間や2週間くらいとします。

バックログのストーリーから次のスプリントで実施する課題を選びます。⁠優先度」が考慮されていれば,上から順にピックアップします。スプリントで対応可能なストーリーの数は,これまでのスプリント実績(ベロシティ)を参考にします。

ストーリーをタスクに分割する

ストーリーが決まったら,作業タスクに分解します。ユーザストーリーの実現に必要な作業を箇条書きにし,1日以内で完了するタスクを作成していきます。

タスクと開発ツールのリンク

Bambooやバージョン管理としてBitbucketを利用していると,Jira Softwareの課題でビルドやコードのマージ状況が表示され,タスクやストーリーが製品やサービスに反映されているか確認できます。

テストを管理する

製品やサービスを繰り返し作り替えていくために,テストの自動化は不可欠です。しかし,すべてのテストを自動化することは難しく,ユーザの視点,テスターや有識者の経験を基に手動テストを実施することも必要です。テストの観点を判断し,効率よくテストを管理することが重要です。

振る舞いからテストコードを作る

テストの自動化にはテストコードが必要ですが,これはJira Softwareのユーザストーリーやタスクの完了条件を⁠振る舞い⁠として捉えることで作ることができます。

Jira Softwareのユーザストーリーやタスクから作るテストコードは,JUnit,Selenium,Cucumberなどのテスティングフレームワークが利用できます。

このように作成したテストコードは自動化に利用する以外に,タスクを着手するまでに用意して「正しく動くコードを作る支援」にも利用できます。つまり先にテストを作り,テストが成功するようにプロダクションコードを作ることができます。

手動で行うべきテスト

自動化できないテストとは,⁠振る舞い⁠⁠完了条件⁠が明確ではないケースやビルドだけでは検査できないケースが挙げられます。

具体的には,探索的テストのようなテスターの経験やユーザの視点を基に手順を臨機応変に変えながらバグを発見するテストや,パフォーマンステストやセキュリティテストなど,動作環境へデプロイしてから実施するテストです。

このようなテストでも初めて実施したときの操作記録などを活用して,一部をスクリプト化し,次回以降は自動化できるように支援するツールもあります。

コーディングの文化を変える

最後に,コーディングとコードレビューの効率化について考えたいと思います。結論から述べると,チーム全員でソースコードの共同所有の意識を持つことこそが重要と考えます。

コードレビューの目的は「コードの書き方の安心感を得る」ため

「コードの正しさ」のチェックは,前述したとおり,静的解析や自動テストで実施することで不要となるので,コードレビューの目的は「きれいなコードが書けているか」というリファクタリングの正しさを確認することにあると思います。

レビューではなくみんなでコードを作る

「きれいなコードが書けているか」を目的とするのであれば,レビューは行わずにコードをチームで書くことでも解決すると考えます。みんなで議論しながらコードを書くことで,チームとしてきれいだと判断できるコードにすることができるのと同時に,メンバー全員がコードに対して同じレベルで認識を共有できるようになると思います。

繰り返し作り替えることに強くなるために

今回の例によって,開発工程は次のように変わりました。

  • 【ユーザストーリーとタスク】【みんなでコーディング】【ビルド(自動テスト)⁠ 【手動テスト】

このような大きな変革には長い期間を要しますので,重要だと思うことから始めていけばよいと思います。

リックソフトでは今回ご紹介したツールの販売および導入支援などのサポートを行っています。みなさまのサービスや製品の価値を向上するためのお手伝いが必要でしたら,ぜひともご相談ください。

次回は,リリースや運用面における継続的な改善によって価値を見つけるための実践例を紹介します。

Software Design

本誌最新号をチェック!
Software Design 2018年10月号

2018年9月18日発売
B5判/184ページ
定価(本体1,220円+税)

  • 第1特集
    GitHub徹底活用術
    Pull Requestの出し方からOSSへの参加まで
  • 第2特集
    Unixをもっとうまく操作したい!
    ターミナルマルチプレクサを活用していますか?
  • 一般記事
    [特別企画]量子コンピュータ〈超〉入門
    【前編】量子力学と量子計算について知る
  • 一般記事
    [特別企画]Jenkins X+クラウドで快適CI/CD
    【3】AKSをオートスケールさせよう

著者プロフィール

奥村和彦(おくむらかずひこ)

プリセールスエンジニア

前職でシステム開発の難しさを知って,開発プロセスをカイゼンするための技術を求めてリックソフトへ。

開発を楽しく面白くするための情報を発信していきます!

コメント

コメントの記入