特集

ITよもやま話

「チケット駆動開発」の適用について考える

技術本部 JSOLデヴェロップメントセンター 開発第一課 課長 三隅 幸和

 IT業界に身を置きシステム開発に携わっている方であれば、効率的で品質の高いシステム開発を行うための開発手法や取り組みについて何かしらの興味をお持ちだと思う。私もシステム開発に従事する立場なので効率的で品質の高いシステム開発手法やその効果的な適用を模索している。本日は、ここ数年で話題になっている開発手法である「チケット駆動開発」について、現在もなおシステム開発手法の主流であるウォーターフォール開発への部分的な適用例を簡単にご紹介したいと思う。

 「チケット駆動開発」とはソフトウェア開発時の各作業を"チケット"と呼ばれる比較的小さな単位のタスクに分割し管理する開発手法である。文字通り"チケットの発行"が起点となり"チケット"の情報を中心にソフトウェア開発が行われる。

 チケットの管理にはTracやRedmineに代表されるBTS(バグ管理システム)が利用される。これらのツールを保守工程での障害管理やリリース管理に利用された方も多いのではないだろうか。チケット駆動開発ではこの障害管理の手法を、システム開発時にも適用し、チケットを用いたタスク管理などを行う開発手法である。チケットの内容は、顧客要望の詳細仕様であったり、対応が必要な課題であったりレビュー指摘やバグ指摘であったりする。近年ではBTSと連携するSubversionなどの構成管理ツールやJenkinsなどのCI(継続的インテグレーション)ツールと統合して利用することにより、チケット発行から、プログラム修正、コミット、定期的なビルドや自動テストまでの一連のサイクルを効率よく管理するための手法として注目され、また利用されている。

 チケット発行から自動テストまでの一連のサイクルを効率よく管理できる点は、反復開発によりソフトウェア開発をすすめるアジャイル開発手法と相性がよく、逆に計画重視型で反復開発を行わないウォーターフォール開発とは相性が悪いように想像され、「チケット駆動開発はアジャイル開発でしか適用できない」のではないかと思われる場合もあるようだ。しかし実際には従来のウォーターフォール開発でも適用することができる。テスト工程以降でチケット駆動開発を利用する事例も多いようだ。

 私がウォーターフォール開発での適用として取り組んだものには大きく2つある。(1)ウォーターフォール開発でも内部にある小さな開発サイクルでの適用と、(2)プログラム改訂に関係するタスク以外のタスクや情報のチケット管理である。

 まず前者についてだが、ウォーターフォール開発はアジャイル開発と違って繰り返し開発がないため開発サイクルという概念がない(全工程を通した大きな1つのサイクルしかない)と思われがちだが、実際はそうではないケースも多いように感じている。複数拠点で開発が行われる場合や、複数のオフショア・ニアショアを利用した場合、開発規模が大きくサブシステムが多い場合などは、段階的にサイクリックな受入テストや結合テストを実施することも多い。誰もが「全機能の一括(一斉)結合テスト開始」のような高リスクな作業計画を望まないからだ。また、システムテストやユーザテスト期間においても、そこで発見された課題は計画的に対応・リリースされ、再テストされる。

 ウォーターフォール開発の課題として問題の顕在化が遅れるという課題がある。プログラム製造および単体テストが終了した機能から順番に、(1)(ビルド番号などで管理される)正式ビルド、(2)検証環境へのアップ、(3)自動テスト及び手動テスト、(4)検証結果のフィードバック(チケット発行)、(5)バグ修正 という開発サイクルを準備し、少しでも早くチケット駆動開発の手法を適用することで、問題の顕在化を早める対策を行うべきだと私は考えている。(担当したプロジェクトでも取り組んでいる。)

 次に後者についてだが、実際に担当したプロジェクトでは内部設計(厳密には外部設計受入時)以降の仕様等の問合せ内容やレビュー指摘内容もチケット管理するようしている。チケットにはこれらの回答内容やそのときに聞いた簡単な仕様検討の経緯もできるだけ記載するようにしている。内部設計以降の担当者は外部設計書に基づき開発を行う。保守担当者は外部設計書や内部設計書に基づき改訂箇所や改訂内容を検討する。しかし、外部設計書や内部設計書には決定後の仕様や設計しか書かれていないことが多い。システムの仕様や各機能の目的を理解するために大切な情報は、実はこのような仕様や設計の検討の経緯に含まれている場合も多い。また、顧客側の担当者が替わった場合などに、現在の仕様になった経緯を正確に伝えることを求められる場合もある。このときにも実は設計書には記載されないこれらの情報が貴重な情報源になるのだ。もちろん議事録などに詳細に記録するのも良いが、チケットに追記する方が手軽なのである。また情報がBTSに一元化されるため、あとから情報を検索する際にも(誰かのメールを確認したり議事録や課題管理表を確認したりせずに)容易に検索できるのである。大規模なシステム開発では、必ずしも全ての関係者が同じ時期に同じ拠点で仕事をできるとは限らない。設計書に残らないこれらの貴重な情報をいかに手軽に、いかに効率的に残すかが重要であり、チケットはこのような用途に適しているのだ。しかも、問合せ結果やレビュー指摘が正しく設計書に反映出来ているか?という追跡も容易にできるので、設計書品質の向上も図れると私は感じている。(もちろんレビュー指摘内容の反映結果確認を怠らなければの話だが・・・。)

 これらの例は、ウォーターフォール開発にチケット駆動開発の手法を部分的に取り込んだわずかな事例にすぎない。ほかにも良い利用事例や取り組み事例があれば是非共有させて欲しい。また、もしまだ取り組んでいない場合は、チケット駆動開発の部分的な取込を検討してみて欲しい。

 システム開発の手法としては、現在もなおウォーターフォール開発が主流である。2010年11月にIPA(独立行政法人 情報処理推進機構)から刊行された「ソフトウェア開発データ白書2010-2011」によると、日本の大手ベンダーから集められたデータを集計したところ、システム開発の進め方として利用されている開発モデルはウォーターフォール開発が全体の9割強をしめ、反復型開発およびその他の開発モデルは全体の3.9%程度にとどまっていることが報告されている。完全にアジャイル開発手法やその他の新しい開発手法のみでプロジェクトを行うことも重要だが、チケット駆動開発をはじめ、アジャイル開発手法で推奨されているプラクティスなどを、部分的でも良いので、いかにウォーターフォール開発に効果的に組み込むかといことも重要だと私は考えている。ソフトウェア開発において"銀の弾丸はない"といわれている。たしかにすべてのシステム開発プロジェクトにも適用可能な万能な弾丸はないと思うが、プロジェクトの特性にあわせて何種類かの弾丸を組み合わせることで銀の弾丸に近い効果を得たいものだ。

(2011年11月10日)

本ページ上に記載または参照される製品、サービスの名称等は、それぞれ所有者の商標または登録商標です。
当コラムは掲載した時点の情報であり、閲覧される時点では変更されている可能性があります。また、当社は明示的または暗示的を問わず、本コンテンツにいかなる保証も与えるものではありません。

ページトップへ戻る

JSOLへのお問い合わせ

最新のインタビュー

クラウド時代のシステム運用の管理・監視ビジネスを構築する

"JSOLとしてのシステム運用の管理・監視で新たなビジネスの構築に取り組んでいるITアーキテクトをご紹介します。

特集

特集SAP

SAP ERPの豊富な導入実績があり、企業の業務改革を総合的にご支援します。

特集Biz∫

人とシステムの融合による業務効率化を目指し、あらゆる企業の変革を迅速かつ確実に実現します。

特集オムニチャネル

コンサルティングからソリューションまでオムニチャネル化に向けた最適なご支援を提供します。

特集JSOLアグリ

農業生産に係る数理計画を中核に、農業生産者の経営指標の見える化と収益拡大を実現します。