「チケット駆動開発」の感想を集めてみたpart3

@SugiTKさんが「チケット駆動開発」の感想をTwitterで流していて、とても参考になったのでメモ。
ありがとうございます。
感想をラフなメモ書き。

【元ネタ】
Twitter / SugiTK: 「チケット駆動開発」を読んでます。ようやく6章まで。少なくとも15年以上前には、FreeBSD Project で CVS + GNATS + make での「三種の神器」が揃っていました。ツールは変わりましたが考え方はほとんどそのままと言えると思います。

Twitter / SugiTK: そういう昔からのOSSでの開発手法が一般の企業活動にもようやく採用されるようになってきたというのはここ5年ほどのことだと思います。ツールはそれぞれ改良されて git + Redmine + Jenkins が最強だと思いますが、根本はさほど変わってないように感じます。

Twitter / SugiTK: 13年前に某社に新卒で入社したときにCVSはこんなに便利で日付とか担当者別に毎回全部をコピーしなくてもいいんですよ、とプレゼンしたことがあったんですが、「複数の担当者で一つのコードをいじるほうがおかしい」と一笑に付されたのをよく覚えてます。

Twitter / SugiTK: 他のことでもよくあることなのですが、一部の人にはよく知られていてそれまでの常識ではないことというのは、なかなか理解されません。いいか悪いか考えてもくれず即却下ということも普通にあります。

Twitter / SugiTK: 中身は同じでも、何かわかりやすい単語や概念を作って広めるのが好きな人に広めてもらうというのはかなり有効なんですよね。多くの人に手に取ってもらって、ようやく検討してもらえるという。いい考え方だったりモノだったりすると、やっとそこから進化していくんですよね。

Twitter / SugiTK: まだ半分も読んでないところでの感想なのですがこの「チケット駆動開発」は少々読みにくいです。学術的すぎるという印象があります。よくまとまっていて人に紹介しやすいというところもあれば、それはあまりにも古いですよ、などというところも。後半ものんびり読み進めます。

Twitter / akipii: 玄人の人達が解説してくれればと笑 RT @SugiTK: まだ半分も読んでないところでの感想なのですがこの「チケット駆動開発」は少々読みにくいです。学術的すぎるという印象があります。よくまとまっていて人に紹介しやすいというところもあれば、それはあまりにも古いですよ、など

Twitter / akipii: アジャイルの概念追加が新しい観点と思います RT @SugiTK: 「チケット駆動開発」を読んでます。少なくとも15年以上前には、FreeBSDでCVS+GNATS+makeでの三種の神器が揃っていました。ツールは変わりましたが考え方はほとんどそのままと言えると思います

Twitter / SugiTK:なるほどです。ただ、FreeBSDも十分アジャイルな開発をしていたと思います。短期間でのリリース目標設定、日々の回帰テスト、継続的デリバリなどです。ずっと変わらないので効率の面から置いて行かれた感はあります… RT @akipii アジャイルの概念追加が新しい観点と思います

Twitter / akipii: 仕様書も同じ文脈ありました @SugiTK 13年前に某社に新卒で入社したときにCVSはこんなに便利で日付とか担当者別に毎回全部をコピーしなくてもいいんですよとプレゼンしたことがあったんですが「複数の担当者で一つのコードをいじるほうがおかしい」と一笑に付されたのをよく覚えてます

Twitter / akipii: ソフトウェアが時代にようやく追い付いたのだと思う @SugiTK 昔からのOSSの開発手法が一般の企業活動にもようやく採用されるようになってきたのはここ5年ほどのことだと思います。git+Redmine+Jenkinsが最強だと思いますが根本はさほど変わってないように感じます

Twitter / akipii: 素晴らしいですね @SugiTK FreeBSDも十分アジャイルな開発をしていたと思います。短期間でのリリース目標設定、日々の回帰テスト、継続的デリバリなどです。 @akipii アジャイルの概念追加が新しい観点と思います

Twitter / akipii: チケット駆動開発が古いツールでアジャイルの価値観と方向性を示したことが新しいと思います。同じか。@sakaba37 いや、アジャイルっぽい事も昔からあって、整理された事が新しいかと。 RT @akipii: アジャイルの概念追加が新しい観点と思います

多分、BTSというWebシステムが出現する以前から、障害管理と変更管理、ビルド管理を組み合わせた手法を実施していた現場は存在していただろう。
そのようなツールの組み合わせが生まれた理由は、現場でそんな開発環境が必要だったからという欲求があったからだと思う。
@SugiTKさんのように、随分以前からCVS + GNATS + makeのようなツールを組み合わせて、「短期間でのリリース目標設定、日々の回帰テスト、継続的デリバリ」を運用してアジャイルに開発していた現場はかなり慧眼の目があったに違いない。

その頃とチケット駆動開発が生まれた現在を比較してみると、CVS + GNATS + makeからgit + Redmine + Jenkinsというツールへ成長して変わっただけとも見えるが、僕はそう思っていない。
チケット駆動開発がアジャイルという概念と密接に連携しただけでなく、ソフトウェア開発に新しい観点を提示した点が大きいのではないかと思っている。
そして、そのようなツールが必要となるマーケット(開発現場)とチケット駆動開発というアイデアが結びついたからこそ、静かに普及していったのだと思う。
従来型開発へのテーラリングは、その一連の流れのバリエーション(派生・先祖返り)に過ぎないかなと思ってる。

最近思うのは、ソフトウェアがようやく時代に追いついたという感覚。
TwitterやFacebookが普及した頃から、各地の開発現場のノウハウを勉強会やコミュニティで共有しやすくなり、色んな人達が切磋琢磨するような環境が生まれたように思う。

チケット駆動開発は、ITSやバージョン管理などのツールの使い方という観点と、アジャイル開発への適用という観点がある。
その観点が意味するのは、ソフトウェアでソフトウェア開発のプロジェクト管理の諸問題を解決できるという事例が増えてきていることを意味していると思う。
プログラミング技術が優れていれば、それをベースにより少人数でアジャイルに開発できる環境が整いつつあるからだ。
そうでなければ、短期間で頻繁にリリースしていくアジャイル開発を安定して運用することはできないだろう。

そして、安定してアジャイル開発できるようになれば、そこから開発のリズムが生まれ、自分たちの運用を改善していけるようになり、マネジメント技術も身に付けていくことができると思っている。
プログラマがいきなりチーム運営できる立場に立つことはあまりないだろうが、アジャイル開発を経験することで、マネジメント能力を向上できるきっかけが生まれると思う。
より良い環境を自ら作り出せば、能力を向上できるチャンスがどんどん生まれる時代なのだと思う。

他にも探してみる。