プログラマの思索

「チケット駆動開発」の感想を見つけたのでメモ。

【1】Twitter / akipii: なるほど RT @ramusara: チケット駆動開発の本、「Redmineによるタスクマネジメント実践技法」への参照が多すぎて読まないと省かれてる部分が分からない。まぁ読みたい本としてメモってるからいつか買うんだろうけど

Twitter / akipii: ありがとうございます RT @ramusara: これまでの開発との比較や、チケット駆動に至るまでの流れを書いてあるので、そういうの知った上でごにょごにょと考える自分にとっては良い本だと思います。「とにかくこういう開発手法取り入れれば良いんや！」っていうのはダメ

【2】チケット駆動開発は「ソフトウェア開発と真剣に向き合う本」 - 勘と経験と読経

(引用開始)
先日発売された書籍「チケット駆動開発」をやっとのことで読み終えた。大変興味深い本だったのだが、仕事の状況などにかまけて通読するのに妙に時間がかかってしまった。ソフトウェア開発のコミュニケーションに関するプラクティスに関する本と捉えていて、いろいろな問題提起が含まれているのがとても面白い本だと思った（逆に、実践的ハウツー本を求めている人には向かないかもしれない）。以下、感想をいくつか。

＜方法論ではなくて一つのプラクティス＞
「チケット駆動開発」はひとつのプラクティスであって方法論ではないと思っている。必要に応じてプロジェクトに取り込めば良い、プラガブルなテクニックのようなものだ。

ウォーターフォール型でもアジャイル型でもハイブリッド型でも良いが、まず前提として「きちんとソフトウェアを開発できる計画・作戦が立てられる」人でないと本書は面白くないと思う。
逆に本書はソフトウェア開発の現場を加速したり向上させたりするものという理解。
一種の「コミュニケーションパターン」×「リーダーシップパターン」なんだろうと思っている(詳細後述)。ただ面白いのはイシュー管理システムを活用して、これらのパターンを現場に半強制してしまうところ。
ただし、ツールの導入は現場を取り巻く環境などにも依存してしまうので普遍的ではない(ツールは時により進化してく)。本書がツール「ありき」で書かれている印象なのはちょっと残念なところもある。
本書を読んでRedmineやTracのようなITS・BTSを導入しちゃうのは多分乱暴だろう。すこし引いて手元の現場の状況をよく観察してみることから始めないとうまくないと思っている。

＜コミュニケーションパターンとしてのチケット駆動開発＞
もともとソフトウェア開発は大量のコミュニケーションで成り立っているようなものだけれども、チケット駆動開発ではこのコミュニケーションを汎用的な「チケット」でマーク付け（タグ付け？）して管理するというのが一つのキモだと思う。ソフトウェア開発以外の世界だと、基本的にコミュニケーションは「流れ去っていく」ものである。議事録であったりメールの履歴としての記録はされるが、これらはあくまで記録であって随時閲覧されるものではない。チケットになって初めて管理できるようになる、というのがポイントなのだと理解している。

元ネタを失念してしまったのだけれども、どこかの企業の社長は部下に指示をする際に二枚複写のメモ帳に書き込みをして、一枚を渡しているそうだ。これも一種のチケット管理のやり方で、局面がフィットしていればうまく回るような気がしている。

＜リーダーシップパターンとしてのチケット駆動開発＞
チケット駆動開発を実際にやると「計画」から距離を置けるようになるというのも良い点だ（別にアジャイルを擁護するつもりはないのだけれども）。チケット駆動を回すと「権威付けされたトップダウンのリーダーシップ」は自動的に抑止されるような気がする。

・指示出し・タスク出しの間にチケット管理システムが入るので、トップダウンの性格が緩和される
・作業完了報告もリーダー宛というよりは、チケット管理システムが相手先になる
・指示出し・タスク出しそのものがトップダウンからボトムアップに切り替わる
・リーダーシップは「皆に指示出しをする」というより「全体が回るように支援する」傾向が強くなる

うまく整理がついていないけれども、このあたりの変化がチケット駆動開発の面白みなのかもしれないと思っている。
(引用終了)

【3】チケット駆動開発の本を読み返した。

(引用開始)
2月くらいからredmineを使い始めて、中規模なサイトを2,3個作って、チケットの粒度とか運用サイクルとかリズム（トヨタ生産方式でいうタクトに近いかな）なんかについて色々とわかってきたので改めて読んでみた。

最初は複数人で使うつもりで啓蒙してみたりしたんだけど、予想通り難しかったので、他人にふった仕事もIssueとして全て自分で管理したら、うまくまわった。4.２節の権限ポリシーをワークフロー型に振って、他人に仕事をアサインするっていうタスクをチケットとして切ったことになるのかな。

他人への仕事のアサインを不確実性のあるタスクとして登録して、タイムアウトしたら自分に再アサインするというやり方にしたわけだけど、これで淡々とこなせるようになったし、さらにイライラしなくなって精神的にも都合が良かった。

ついでにチケットも会議と紐付けるようにしたので、会議を定期的にやれば、プロダクトの開発サイクルもそれにつられてタイミングが揃うようになったし、会議の議題とかチケットの粒度も次の会議までの期間でできそうな(3週間くらい)に揃えやすくなった。

変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅です
これはそうだよなとしみじみと思った。というわけで、これ(チケット駆動開発)も読む予定
(引用終了)

【4】「curiosity driven works」「好奇心駆動仕事」でいこう：坂本史郎の【朝メール】より：ITmedia オルタナティブ・ブログ

(引用開始)
技術者Ａ) 単体テストを作成してから本体の開発に取り掛かる、
テスト駆動開発は大変よいものだと思います。
継続して布教していこうと思います。

私) ⇒「テスト駆動開発」という言葉があるのですか。Wikiでみたら
『近年はビヘイビア駆動開発へと発展を遂げている。』だそうです。
なぜ「駆動」という言葉を使っているのだろうか。
drivenの直訳としてはちょっといただけない。

技術者Ａ) Hoge driven development はすべからくHoge駆動開発と訳されています。
何か違和感がありますか？

私) ⇒違和感ありますね。drivenというのは、「意識して」とか「中核の」
というような意味合いで使われていると思うのです。定着してしまって
いるのであれば、最初に訳したケースが残念だったということか。

技術者Ｂ） →ちょうどＴさんから貸して頂いた『チケット駆動開発』という本の中で、
　「なぜ「チケット駆動開発」と呼ぶか?」という節があります。
　そこで示された理由は
　　　「チケットがプロジェクトをテンポよく推進してくれる」
　ということでした。
　この話のスタートである「テスト駆動開発」も、
　　　「テストがプログラミングをテンポよく推進してくれる」
　ような仕掛けになっています。
　この「テンポよく推進」を言い表す日本語として「駆動」を充てるのは、
　あながち外れてはいないと私は思います。
(引用終了)

【6】ソフトウェア開発プロセスを環境にする - 勘と経験と読経

(引用開始)
＜ルールとしてのソフトウェア開発プロセスの必要性＞
ソフトウェア開発プロセスは皆が守るべきルールのようなもので、ルールである以上みんながそれに従わなければいけない。CMMIなどでは遵守状況のモニタリングと継続的な改善を行う必要がある。この考え方の前提は「ルールを守らなくてもソフトウェアを作ることができる」ということなのだと思う。

ソフトウェアには物理的制約がほとんど無いので、絶対に守らなければならないルールというものは無い。例えばビルなどの建築物であれば当然のことながら土台の基礎工事をした後に、下部構造から構築しなければいけない。しかし、ソフトウェアにはこのような制約は無い(どんな方法でも構築できる)。

しかし、自由なやり方では大失敗してしまうことがある。そして、成功した場合より失敗した場合のダメージが大きいのがソフトウェア開発である。ソフトウェアでは無制限に失敗することが出来るからである(その反面、一般的には成功は有限)。

だからベストプラクティスを探してルールを作るのだけれども、それを守るというのがまた難しい。

＜ルールを環境にする＞
いまチケット駆動開発を読んでいる(未了)。
(中略)
チケット駆動開発のルールはシンプルで、『チケット無しのコミットは禁止(No Ticket, No Commit!)』というものである。この手法が良いのは、これ以外のルールをRedmineなどのイシュー管理システム(ITS/BTS)とバージョン管理システム(VCS)にまかせて環境化し、隠してしまっていることだと思う。

実際には、No Ticket, No Commit!以外のルールも存在するのだけれども、そのコントロールはITS側にまかされている(記録やワークフローなど)。
実際に存在する多数のルールをメンバーが意識する必要は無い。一つのルールを守るためにITSを使っていれば自然に所定のプロセスで作業をするようになる。
もちろんツールに頼ってしまうことによって、「開発者が考えなくなる」という問題はある。
(中略)
もちろん技術者教育は重要なのだけれども、なんでも教育の問題にするのは違っているのではないだろうか。

別にチケット駆動開発だけを持ち上げるつもりはないけれども、「考えなくても自然とルールが守れる環境をつくる」ということもセットで考えるべきではないかと思う。
(引用終了)

皆さんの感想を読みながら、更に「チケット駆動開発」について色々考えている。