トラブルが多発する理由の1つには、ソフトウェア自身が抱える「技術的負債」があります。ソフトウェアが設計上の理想から外れている状態を、債務（借金）との類推から「技術的負債がある」と言います。技術的負債を返済しないとプロダクトの品質が上がらず、本来のソフトウェアの開発に注力できなくなり、なかなかビジネス価値を創出できません。
今回は、この技術的負債を返済し、ソフトウェアの構造をより良い状態にしていく実際の方法として、D Software社のZephyr Enterprise Edition（以下ZephyrEE）および、アトラシアン社の製品群によるツールチェーンを用いた、リファクタリングを継続的に実施していくためのしくみについて説明します（図1）。
図1 ZephyrEEとアトラシアン社の製品群によるツールチェーン
設計の見なおしと議論
技術的負債を返済するためにリファクタリングを行っていくわけですが、まずはチーム全員で同一の設計上の理想を描けている必要があります。そうでないと、数あるクラスのうち、処理をどの部分に担わせるかなど、担当者によって差異が生じ、後工程での認識合わせに時間をとられたり、あとからソースコードを俯瞰した場合に一貫性のない状態になったりします。このため、チーム内でその内容を共有しましょう。
チャットツールであるHipChat Serverを用いると、設計についてチーム内で議論できます。HipChat Serverでは「ルーム」を作成し、そこで行います。もちろん、ルームへの入室権限をユーザごとに設定可能なので、必要十分なメンバーだけが読み書きできるように限定できます。インターネットからアクセスできるようにしておけば、複数拠点にチームが分散した場合でもスムーズに議論が行えますし、さらにスマートフォンを含む多くのデバイスにも対応しているので、出張時の移動時間も議論に参加できます。
このようにして議論で得られた結果を、チームコラボレーションツールConfluenceのプロダクトに関連するスペースに記載しましょう。ConfluenceのようなCMS（Contents Management System）上に決定事項をまとめたほうが、あとから見なおす場合や、新規メンバーを教育するときに見やすい形で置いておくことができます。筆者らのチームでは、プロダクトのシステム構成、ソフトウェアのコンポーネント分割やレイヤー分けなどの基本設計、用語集、Q&A、コーディング規約などを、実際にConfluenceに記載して運用しています。
設計の理想を検討する方針としては、おおむねソフトウェアをシンプルにし、コードクローンを適切な方法で減らすのがよいと思います。そのための設計手法・原則としては、SOLID原則やデザインパターン、リファクタリング、DRY原則、YAGNIなどが存在します。
できることから改善
設計としてのあるべき姿は検討しました。しかし、抜本的な対策には時間がかかるため、すぐに実行に移すのは難しいと思います。たとえば、請負額や作業期間が厳しい場合、長期間続いているプロジェクトで抜本的に改革を行った際の影響範囲が大きい場合などです。それでも、改善のための何らかのアクションを起こしていかないと、いつまでたっても状況は良くなりません。あるべき姿に近づくように、できることから実践していくのが良策です。
統合開発環境にソースコードのフォーマッターを導入してコーディングルール統一の助けにし、さらにソースコードを静的解析ツールにかけることで、バグが潜んでいないか、コーディングルールに準拠しているかといった確認ができます。なお、静的解析ツールの実行は、Bambooを使用することで自動化が可能です。
プログラム自身の改善にはリファクタリングを行いましょう。リファクタリングは「外部から見た動作を変えずにソースコードの内部構造を整理する」ことで、読者のみなさまにはお馴染みではないかと思います。これにより、ソフトウェアをより良い状態に近づけます。その際は、設計改善の作業だけを行い、新機能の作り込みなどのほかの対応を同時に行わないことが重要です。
また、チーム内のメンバー複数人で開発していて、各人のソースコードの変更を統合（マージ）する際にコンフリクトが多く発生し、その対応に追われていることはないでしょうか？ そのような場合、機能が1つのファイルに集約され過ぎているという理由で、改善の余地があるかもしれません。
作成したソースコードは人手によるレビューを実施しましょう。これにより静的解析ツールではカバーできない面での品質を確保できます。「動けばよい」という考え方で漫然とコードを書いていては、プログラミングの技術・品質はいつまでたっても向上しません。レビュアーが理解しやすいコードを書く必要が生じることで、チームメンバーの意識の向上に役立つと思います。
筆者らのチームでは、詳細設計（全体の対応方針や利用するアルゴリズムなど）についてはあらかじめチームメンバー間で認識を合わせておき、レビューではソースコードの読みやすさ、クラス・メソッド名の名前付けの良し悪し、処理の責務が妥当かといった項目を主眼としてレビューを行っています。
Bitbucket Serverでは、前回の記事で紹介したように、シンプルなレビュープロセスであるプルリクエストをサポートしています。Bitbucket Serverの画面上でソースコードの差分を見ながらレビューができるので、ソースコードを紙に印刷して蛍光ペンでマーキングする必要はありませんし、複数人でレビューする際も指摘事項を共有して議論できます（図2）。また、課題管理ツールであるJIRAと連携し、プルリクエストによる承認をJIRAの課題のワークフローに組み入れることで、プルリクエストが未実施の場合はJIRAの課題をクローズできないように設定できます。
図2 プルリクエストによるソースコードの確認と議論
リファクタリングを行ったらテストの実施です。後編では、テストマネジメントツールZephyrEEを使ったテスト工程の管理と、CI（Continuous Integration）ツールによる自動化との連携について解説します。
Atlassian Expertsの盾には
アジアパシフィック市場において
トップセラーを証す刻印が…
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトの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の実行環境（基礎編）
