チケット駆動開発のメリット・デメリット
小規模から大規模まで幅広く使われているチケット駆動開発のメリットとデメリットを解説します。
当社の開発環境もチケット駆動開発で落ち着いてたりもしますが、最近はデメリットの方が多いような気がしてます。
そろそろ別の開発手法も試したいなぁと思っているのでこの文章もややネガティブな目線です(^_^;)
プロジェクト管理に興味がある方はこちらの記事も御覧ください。
目次
そもそもチケット駆動開発とは
チケット駆動開発は、プロジェクトの中で発生する数あるタスクをチケットという単位に分割してタスク処理する手法です。
具体的に言うと、開発の中には新機能追加、バグ修正、課題解決、テスト、サポートなどなど様々な手順がありますが、それぞれを一つの作業として切り出しチケット化します。
チケットには担当者が割り当てられるので担当の人間がソースコードを修正したりしてチケットを終了させるわけです。
テスターやマネージャーはチケットをバンバン発行してプログラマーはチケットをクローズするという作業に分割できるので、作業分割できるし組織っぽい開発環境を作れるわけです。
チケット駆動開発はプログラミングが主な開発会社だけでなくて、プロジェクトマネージメントが必要な組織であれば共通して使える概念です。
チケット駆動開発に適したプロジェクト管理ツール
チケット駆動開発は概念的には簡単なものですが、さすがにExcelで管理したりするわけにもいかないので、効率的に作業を進めるための便利なツールがいくつかあります。
Redmine
チケット駆動+プロジェクト管理の定番ツールのRedmineです。
Ruby on Railsで書かれているオープンソースで、無料ですが、自分でRuby対応のサーバーにインストールする必要があります。
Trac
プロジェクト管理とバグ追跡のためのツールです。
先述のRedmineの前進のツールのようで、同じくオープンソースです。Pythonで書かれているので、Pythonユーザーには良いかもしれませんが、そうでなければ後発のRedmineの方が良いかもしれません。
JIRA
オープンソースは無料で良いのですが、インストールが面倒だったり敷居が高かったりするので有料でも良いという方はJIRAがおすすめかもです。Bitbucketを開発しているAtlassianのが提供しているサービスですのでBitbucketとの相性も良いです。
$10/月 10ユーザーまでというリーズナブルな金額でスタートできます。
Backlog
日本産のプロジェクト管理ツールです、課題管理やWikiなどの基本的なツールは揃ってます。ベーシックプランで2000円/月〜お値段は安くないですがGUIが良さそうです。
最初の30日間無料で使えるみたいです。
有料版の注意点
いくつか代表的なツールを紹介しましたが、有料版は開発会社が価格改定をする可能性と、サービスを止める可能性があるという点でリスクがあります。サービス提供側はマネタイズができなかったらサービスを維持できないので、信頼性を考慮して使用するのが良いと思います。
チケット駆動開発のメリット
チケット駆動開発のメリットは、誰が何のためにどのコードを編集したかがわかるところでしょう。
プログラマーやデザイナーはソースコードを編集してコミットするわけですが、コミットのログにチケットIDを入れておけばソースコードの編集履歴とチケットが紐づくので、ソースコードの可視化ができます。
バグが発生したら誰がどのチケットのために編集したコードに問題があるのかもわかるし、プログラマーの作業のブラックボックス化を避けることができます。
また、チケットごとの工数を登録すると結局全部の工程でどれくらい時間がかかったのかの集計を取ることもできますので、ガントチャートを作ったりコスト計算をする材料にもなります。
チケット駆動開発のデメリット
全体の設計が見えなくなる
数あるタスクを細かいチケットに分割すると、タスクを処理する人は全体の設計を考える必要がなくなります。
チケットが全体の設計に関わらない分割可能なタスクであれば問題ないのですが、設計に関わる部分をチケット化してしまうと、後々の設計見直しを強いられて、せっかく処理したチケットをもう一度やり直す可能性が出てくるわけです。
上流工程がしっかりと整理されていたり、マネージメントがちゃんとできていたり、もしくはプロジェクトが単純なタスクに分割できるならチケット化で効率開発できると思いますが、それができない場合、デメリットが増えるような気がします。
エンジニアが創造力を失う
ひとつの機能追加、あるいはひとつのバグ修正でもアプローチは何通りもありますが、プロジェクトの全体を見る必要がなければ、バグの修正は局部的な応急処置になりがちです。
ソースコード全体を見通して今後の拡張を考える必要がある場合、局部な修正が良くない場合っていうのはよくあることです。チケット化されてなかったら全体を通して考えるところを、チケット化することによってエンジニアの想像力を制約していたりするわけです。
エンジニアに責任もってプロジェクトにコミットしてもらう場合、タスクをチケットにするよりも、ある程度、大きな範囲で任せてもらったほうがやりやすいと思います。
工期がその通りになるとは限らない
タスクを分割して個別のチケットをスケジュール化して進めれたとしても、全体のプロジェクトの進行がその通りになるとは限りません。
先述の通り、バラバラのタスクを後でまとめて組み上げる作業が発生する可能性を考えておかないと工期の遅れは避けられません。
チケット駆動開発は個々のチケットのスケジュールは立てれても、それが全体にどう影響するかを想像させるのには適してないのです。
エンジニアとのコミュニケーション不足問題
分業できるということは、エンジニアがテスターになる必要がなくなるとも言えます。
クライアントやテスターが発行したチケットをエンジニアが処理するというフローにすると、エンジニアがどういう経緯でそのチケットが発行されたのか考える必要がなくなります。
チケットを出す人と処理する人のコミュニケーションが密に取れていれば良いのですが、そうでない場合、そのタスクや機能が本当に必要か、必要な場合でもそのタイミングで必要かどうか、ちゃんと精査されていないチケットを発行したり処理することになります。
チケット発行側とチケット処理側の関係が浅かったり、コミュニケーションの距離があったりすると、チケットを簡単に却下することもできなくなります。
都度ミーティングして対立した意見を出すくらいならさっさとチケットクローズさせる、みたいな流れになると、不毛な作業をすることになったり、もしくは無駄なチケット放置してカオスな状態になったりします。。
チケット駆動開発に限らずコミュニケーションは非常に大事ということです。
まとめ
今の気分でデメリットを絞り出した感じの記事になりましたが、チケット駆動開発はチケットを発行して、うまく完了してもらえるとプロジェクトがスムーズに回ってる気分になるのですが、使い所を考えないと失敗してしまいます。
向いてる会社やプロジェクトの見極めが大事と言う話でしたー。
最新記事 by まなびん (全て見る)
- 日本最大級セミナーのポータルサイトの開発に関わらせて頂いています - 2019年10月24日
- エンジニアとして求人応募する際に意識してほしいこと - 2019年10月23日
- 受託が忙しく自社サービス開発できないので開発メンバー募集！ - 2019年1月28日