前回 はGitのメリットを紹介しつつ、アトラシアン社の開発ツールであるBitbucket Server やSourceTreeの使い方を説明しました。中でも、ブランチを使った開発手法や、プルリクエストによるコードレビューやマージはチーム開発を支える強力な機能です。まだ記事をご覧になっていない読者の皆さんは、ぜひバックナンバーをご一読ください。
今回は、ソフトウェア開発で避けることのできない不具合対応やトラブル対応において、JIRA やBitbucket Serverをどのように活用していくかについて説明します。
トラブル発生！
不具合の報告は、いつも突然やってきます。メール、電話、最近ではチャットやSNSかもしれません。障害の報告というのはけっして気持ちの良いものではありませんが、ソフトウェアの品質を上げる、そして何より開発チームの手腕が問われるチャンスでもあります。筆者自身、長年にわたってソフトウェア開発に関わっていると、何度もピンチに見舞われることがありましたが、そのときの対応次第でソフトウェアの良い改善機会になったこともありますし、結果的にお客様から対応内容についてお褒めの言葉をいただき、バグを作りこんでしまったにも関わらずたいへん恐縮したこともあります。
不具合の連絡を受けたときは、できるだけ速やかにチームの課題管理システムに登録しましょう。どんな形であれ、記録を残すのは重要です。幸い、JIRAは組織やプロジェクトに合わせて柔軟にカスタマイズでき、Webブラウザから手軽に課題を入力できます。また、JIRA Service Desk というアプリケーションを導入すれば、より簡単にバグチケットを起票できるインターフェースが提供されます（図1 ） 。この連載の第1回ではメールによるチケット起票についても書いているので、興味のある方はそちらをご覧ください。JIRAは元来バグトラッキングシステム（BTS）として生まれたということもあり、ソフトウェアのバグを記録するためのシステムと思われがちですが、けっしてそんなことはありません。ちょっとした改善項目や問い合わせなど、何でも記録していくことがうまく使いこなす第一歩だと思います。
図1 JIRA Service Deskのインターフェースさて、トラブル対応時はトラブルシューティングに必要な情報を漏れなく速やかに集めることが重要です。JIRAはそのための窓口でもあり、データベースとして機能します。トラブルシューティングに必要な情報は、扱っているソフトウェアやシステム、また組織によってさまざまです。たとえば、モバイル関連のサービスであれば、端末のオペレーティングシステムの情報や解像度などの環境情報が重要になることもあるでしょう。
JIRAには標準で課題の要約、優先度、担当者、期限などのフィールドが用意されていますが、カスタムフィールドを自由に追加することもできます。このJIRAの柔軟性を活かして、トラブルシューティングに必要な情報を効果的に収集できるように、業務に応じてフィールドを自由にカスタマイズしてください。
情報を入力するときは、その内容も大切です。「 ○○が動きません」といった情報だけでは調査は困難なものになります。「 再現手順」「 期待する結果」「 実際の結果」「 再現率」といった情報のほか、スクリーンショットやログがあれば問題解決に役立つでしょう。組織で簡単なルールを作ったり、チケットの起票の負担を軽減するために必須フィールドを減らしたりといった工夫も必要かもしれません。
調査開始
調査に必要な情報がそろったら、問題解決に向かっていよいよ作業開始です。報告を受けた時点ですぐに原因がわかれば良いのですが、原因が不明な場合は、問題解決への第一歩は再現テストです。現象を再現できたら、原因を追及していきます。環境の問題かもしれませんし、単にソフトウェアの使い方の問題かもしれません。プログラムの問題が疑われるならば、ソースコードを解析していくことになります。そのとき助けになるのが、バージョン管理システムに蓄積してきたソースコードであり、コミットログの歴史です。目的のソースコードをすぐに見つけられるように、日ごろからBitbucket Serverのように信頼のおけるツールを活用し、ソースコードの管理はしっかりやっておきたいところです。
報告のあった不具合内容からソースコードの場所をピンポイントで特定できると良いのですが、原因がすぐには判明しないこともしばしばあります。たとえば、利用しているフレームワークやライブラリに原因があるときなどです。ソフトウェアの、あるバージョンを境に不具合が起きるようになった場合は、バージョン間の差分を調べる必要があります。Bitbucket Serverにはブランチ間の差分をグラフィカルに表示する機能が備わっており、Webブラウザ上でソースコードのdiffを見ることができます（図2 ） 。また、コミットログを追うことで、「 いつ」「 誰が」変更を行ったかもひと目でわかります。Bitbucket Server 4.6ではBlame表示という機能が追加され、ソースコードの1行1行について変更を行った開発者を表示できるようになりました。チーム開発では1つのファイルを複数の開発者が修正することも多いので、このような機能は非常に役立つでしょう。
図2 ブランチ間の差分の比較SourceTreeやBitbucket Serverを日常的に使っていれば、「 いつ」「 誰が」という情報は自動的に記録されていきます。しかし、ソースコードの変更履歴で最も重要な情報は「なぜ？」 、つまり変更した理由です。1人の開発者だけで開発している場合でも、これは重要です。1年前に自分自身がコードを修正した理由をすぐに言える人は少ないのではないかと思います。優れたツールを使っていても、せっかくたどりついたコミットログに「変数名を変更した」とか「APIをfoo( )からbar( )へ変更」といったコメントしか残されていなかったらどうでしょうか。変更内容はソースコードを見ればわかります。大切なのは「変更した理由」です。たとえば、「 グローバルスコープと名前が衝突する可能性があるため、変数名を変更した」となっていれば、衝突の可能性を回避するための改善なのだな、ということがわかります。同様に、「 パフォーマンス向上のため、APIをfoo( )からbar( )へ変更」とあれば、性能向上のために利用するAPIを変えたことがわかります。このように、コミットログはソースコードのコメントと同様に、開発者にとって貴重な情報源であることを覚えておきましょう。
とはいえ、コードのコメントやコミットログだけではすべてを書き残すことは難しいです。JIRAを使っているのであれば、コミットログにJIRAの課題キーを記載することを忘れずにしたいものです。こうしておけばBitbucket ServerのコミットとJIRAのチケットが紐付けられ、より詳しい変更理由を知ることができるようになります。追跡の際、開発者はソースコードのコメント→コミットログ→チケットの順に見ていくはずです。ソースコードをメンテナンスするときも、この順番で記録していくのが良いと思います。
後編では、より良いコミットログを残すためのヒントと、コード修正の流れを追いながらCIツールの連携などを紹介します。
Atlassian Expertsの盾には
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、各アトラシアン製品の体験版を提供しているほか、アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては！
リックソフトJIRAデモ環境
https://www.ricksoft.jp/demo/
