無料ブログはココログ

« 2009年6月 | トップページ | 2009年8月 »

[TiDD] チケット駆動開発によるフロントローディング

カイゼンといえば「フロントローディング」という言葉もありますね。後工程で見つかる問題をなるべく早い工程で摘出することで、手戻りを減らすことです。リアクティブな活動からプロアクティブな活動への移行と言っても良いかもしれません。

TiDDではBTSを使いますので、障害情報と同じように「どの工程で問題が組み込まれたか」、あるいは、「本来はどの工程で摘出すべきか」、といった情報をチケットに登録しておけば、どの工程をカイゼンすればよいかが明らかになります。レビューの強化、ツールの導入、教育、などによって、あらかじめ不具合を作り込まないようにします。

西先生いわく、「武士道の究極は刀を抜かずに人を切る、テスト道の究極はテストをせずにバグをなくす」、まさに名言だと思います。

また、TiDD良いところは、作業漏れが生じた際にチケットを発行してから作業をするところです。どのような作業が考慮されていなかったか、一目瞭然です。類似の開発を行う際に、抜けていた作業をあらかじめ考慮すれば、問題の発生を減少させることや、見積もり精度を高めることができます。

このようにTiDDを用いることで、プロセス改善を行うことが可能です。それも、チケットによって、隠れていた情報が見える化されるからです。でも、TiDDを実践したけれども、難しい点もあるといわれる方もおられます。次回はその点に触れてみたいと思います。

[TiDD]チケット駆動開発と見える化

トヨタ式のプロセス改善でいう「見える化」というと

「見える化は一言で言えば,問題点が常に「見える」ようにしておく工夫のことである。正常と異常の違いがすぐに分かる仕事場とか,仕事するうえであれこれ迷わずに済む現場のことを指すと言ってもいいかもしれない。 」(ITpro)

というように、問題を発見する環境作りをさすことが多いと思います。

トヨタ式の工場では整理整頓が徹底されていて、ごみ一つ落ちていません。そうすれば、本来留めなければいけないネジが落ちていたらすぐにわかりますし、作業の流れが滞ったり、無駄な移動があればすぐにわかるからです。

チケット駆動開発(TiDD)も見える化を促進しますが、以下の3種類があります。

  ・情報共有
  ・問題の発見
  ・作業状況

TiDDでは、BTSを使って作業を管理します。それは全ての開発者が使うものですので、プロジェクトの作業の進み具合をみんなで共有することができます。開発中はついつい自分の担当している作業だけに注目しがちで、他の人と助け合わなくなりがちです。開発者全員でプロジェクトの状況を共有しますので、自然と協力し合う雰囲気ができるでしょう。

チケットは作業の一覧として見るだけでなく、BTSによってはガントチャートなどのグラフ化も可能です。遅れている作業や、作業負荷の偏りも容易に発見できるでしょう。

作業がBTSのチケットになっているのですから、未完了作業の状況を一目瞭然で管理できます。全ての作業がチケットとして登録されていますから、それぞれの作業のステータスを管理することができます。また、様々な条件で抽出できますから、担当者毎の作業状況も容易に管理できます。

このように、TiDDでは従来の見える化を超えた見える化が可能です。これらはアジャイル開発だけでなく、ウォータフォール開発でも、効果が期待できるものです。

[TiDD] チケット駆動開発とXPの共通点

あきぴーさんがチケット駆動開発(TiDD)をXP(eXtreme Programming)に適用された結果を元に、共著で論文を書いて外部発表をしています(SPESSQiP)。これらは、アジャイル開発を改善するためにTiDDを適用した論文ですが、なぜそのようなことが可能なのかを考えてみました。

実はチケット駆動開発とXPには共通点があります。それはXPの4つの価値です。それは、

- コミュニケーション
- シンプルさ
- フィードバック
- 勇気

です。この4つの価値がXPのプラクティスに影響を与えています。

TiDDの効果を考えると、このうち2つの価値を支援することがわかります。そもそもの提案者である、まちゅさんによるとTiDDの効果の一つは「開発メンバの仕事が把握しやすくなる」というものです。

全てのソース更新作業がチケットと関連付けられることで、どのような作業が残っているか、プロジェクト内で明確になります。これは、TiDDがプロジェクト内のコミュニケーションを改善するということです。

さらに、まちゅさんはもう一つの効果として「ソースコードのコミット単位が明確になる」とされています。これは、チケットなしのコミットを許さないことから来るもので、開発作業をシンプルにしたことによる効果です。

この二つの価値に対してXPでは、作業をタスクカードに割り当てるというシンプルなルールをつくり、そのタスクカードをタスクボードという掲示板に貼ることでプロジェクト内で情報を共有してコミュニケーションの向上を図っています(もちろん共同のプラクティスもコミュニケーションに重要です)。

ちなみに、フィードバックというのは、繰り返し(イテレーティブ)開発などによって、補正(フィードバック)をしつつ開発することができます。また、勇気というのは積極的な開発プラクティスの実施や担当作業のコミットメントなどによって実現されます。

このように考えるとTiDDはXPと矛盾しないだけでなく方向性が共通しています。繰り返し開発や開発プラクティスを導入すれば立派なアジャイル開発になりそうです。実際にXPJUG関西のTiDDの議論の中では「TiDDによってリズム感が生まれてアジャイルがわかった」という感想さえ出ていました。現実の現場では実現しにくかったXPが、より効果的に実現できるようになる、そんなパワーがTiDDにはあるようです。

ひかりTV: PC-STB4の熱暴走=>PM700に交換

今月になってから、ひかりTVのセットトップボックスPC-STB4(バッファロー)が熱暴走するようになりました。

予約録画の途中で画面が真っ黒になって固まります。STB4がかなり熱いので、設置場所をDVDレコーダの上から移動させましたが改善しませんでした。

真っ黒画面の状態で再起動すると10~15分ぐらいでまた固まります。ためしに扇風機から直接風をあてると、何とか動くようになりました。

こんなことをいつもやってられないので、ひかりTVのホームページからサポートに連絡しました。結局、PM700という機種に交換になりました。操作性が向上してS端子とNHKオンデマンドが増えました。

「STB4、熱暴走」で検索すると、同じ症例で交換してもらっている人は結構居るようですね。今月分の料金はサービスしてもらいましたが、ギャラクチカシーズン3の終盤が見れなかった方が悔しいですorz

TiDD:チケット駆動開発

「チケット駆動開発」という言葉を聞かれたことがあるでしょうか?
テスト駆動開発と似ているこの言葉は、最近、アジャイルに興味を持つ人たちの間で注目されています。今回は、この「チケット駆動開発」について書いてみたいと思います。

1.チケット駆動開発の始まり

「チケット駆動開発」は、TracやRedmineなどのBTS(Bug Tracking System:障害管理ツールなどとも呼ばれる)の利用から始まりました。まちゅさんが、たくさんの小さな修正を加えるシステムを開発されている中で、BTSのチケット(障害票)を用いて開発プロセスを改善されたことに始まります。

まちゅさんは「チケット無しでのコミット禁止」とすることで、全てのコード修正をチケットで管理できるようにされました(参考文献1:チケット駆動開発 … ITpro Challenge のライトニングトーク (4))。

まちゅさんによると必ずチケットを発行するというルールによって、2つのメリットが生まれるそうです(参考文献2:チケット駆動開発 (TiDD) とアジャイル開発)。

(1)開発メンバの仕事が把握しやすくなる

(2)ソースコードのコミット単位が明確になる (目的が異なる修正を同時に加えない)

2.アジャイル開発への適用

まちゅさんの講演を受けて、XPJUG関西の人たちが、TiDDがアジャイル開発に向いていることに気付きました。まちゅさんは「もう一つのTDD」と呼ばれていましたが、テスト駆動開発と区別するためにえと~さんが「TiDD」と名づけられました。

そして、あきぴーさんを始めとして、実際の開発現場でTiDDが実践されました。XP(Extreme Programming)のタスクカードをBTSのチケットに置き換えることで、XPを以下のように改善できました。

(1)タスクボードが必要ないので、職場の環境に関係なく多くの作業を管理できた

TiDDによるアジャイル開発では、XPのタスクカードをチケットに置き換えます。このことで、タスクボードと呼ばれる掲示板が不要になり、XPの実施が容易になりました。また、タスクボードを用いると、その大きさによって貼ることが可能なタスクカードの数が制限されますが、そのような制限がなくなりました。

(2)個人毎の作業管理が容易になった

タスクカードはToDo、Doing、Doneという3つの状態で管理されますが、それぞれのタスクの担当を容易に識別できません。タスクカードをオンライン化することで、個人ごとの担当作業を容易に抜き出すことが可能になりました。

(3)複雑な構成管理作業が抜けなく行えるようになった

XPでは繰り返し開発を行いながら複数回リリースするので、リリース後のソースコードと開発中のソースコードを同時に構成管理する必要があります。BTSのワークフロー機能を使うことで、作業の抜けをなくすことができました。

3.TiDDの二つの側面

このようなチケット駆動開発には、ツールの新しい利用方法という側面と、プロセスの改善という二つの側面があります。

3.1 ajaxのようなもの?

「TiDDはajaxのようなもの」と言われることがあります。昔からある機能ですが、考え方と使い方を少し変えるだけで世界が大きく変わる、という意味だと思います。TiDDではBTSのチケットを用いますが、それは障害を記録するものと言うよりは作業の管理単位になっています。

大昔に読んだマイヤースの本に機能とは何かについて書かれていました。時計の機能は現在の時刻を示すものですが、ユーザによっては1と3の間の数字を知るということもひとつの機能になると書かれていました。もちろんこれは本来の機能ではありませんが、TiDDとBTSの関係に似ています。

具体的にはBTSの状態管理、ワークフロー管理、構成管理ツールとの連携、といった機能を、作業管理のために用いています。そのように書くと、「BTSでなくても良いの?」とか「BTSがなくてもよいのか?」という疑問が出ると思います。実はそうなんです。

3.2 アジャイル開発のプロセス改善

まちゅさんによると、そもそもTiDDはBTSを「みんなで使うToDoリスト」として使う開発法です。だとすると、ToDoリストがあればBTSはなくても良いはずです。いやいや、ワークフローの管理が必要だと言われるかもしれませんね。それなら、ToDoリストに判子欄を設けてはいかがでしょうか(そういえば、昔の障害票には判子欄のあるものがありました。順に押印していくことで、ワークフローを管理していたのですね)。あとは個人毎の作業管理が必要ですね。ToDoリストを色分けして、担当者がわかるようにすれば、すこしは便利かもしれません。

そんな風に考えると、チケット駆動開発はいったい何だろうと思われるでしょう。誤解を恐れずに書くと、TiDDはプロセス改善の手法です。

まちゅさんはたくさんの小さな修正を加えるシステム開発をうまく行いたかった。たまたまそこにBTSがあって、便利に使えたということでしょう。あきぴーさんは、アジャイル開発をうまく行いたかった。そこにBTSがあってTiDDを実践すると、いままでうまくいかなかったアジャイル開発がうまくいった。そういうことなのだと思います。

つまり、プロセスを改善する道具を探したら、そこにBTSがあったということなのだと思います。

4.チケット駆動開発はエンジニアリングの基本

巷では月着陸40周年と騒がれていますね。このアポロ計画が成功したのはWBS(Work Breakdown Structure)があったからだといわれています。かつてない巨大なシステムを構築するには作業を抜けなく行う必要があるので、WBSは非常に有効なツールだったと思います。

XPJUG関西の集まりで、チケット駆動開発をどこまで抽象化できるかを議論していたとき、ある方が「チケットは忘備録」と言われました。この言葉を聞いて、その程度のものかと正直思いましたが、じつはこれがチケットの本質だと思います。小さな作業がたくさんあるプロジェクトにおいて、作業を抜けなくきちんとやることは、とても大事なことなのです。

アポロ計画ほどの巨大なシステムでなくても、作業を細分化していけばその数は膨大なものになります。それをきちんと抜けなく、定められた手順でやる、それはとても大切なことです。

そのためには、(1)どのような作業があるかプロジェクト内で共有・確認し、(2)開発者が担当作業を把握し、(3)決められた手続きに沿って抜けなく作業する、ということが支援されなくてはならないのです。チケット駆動開発は、それを支援しています。まさに「エンジニアリングの基本」を支援しているのです。

5.まとめ:チケット駆動開発の魅力

「チケット駆動開発」は、アジャイル開発(を中心とした)プロセス改善手法です。もちろんBTSがあれば便利に使えますが、ツールが無くてもプロセスを改善することができるはずです。

このように書いていて、かつてオブジェクト指向分析がブームのころに話題になったOMT(リンク先はWikipedia)の本を思い出しました。この本の後半には、オブジェクト指向でない言語でのオブジェクト指向開発の方法が書かれていました。オブジェクト指向分析は、言語に関係なくのメリットがあるということなのでしょう。実際、この本に励まされて実践された方もたくさんおられるのでしょう。でも、環境の整ったオブジェクト指向言語の方がはやったように思います。

チケット駆動開発もたぶんそうです。便利なタスクカードや「チケット駆動開発環境」というものがあれば、それがブームになるかもしれません。でも、それ以前に良くできたBTSがあったのです。最近のBTSは高機能化が進んでいて、チケットの状態管理、検索、グラフ化、ワークフロー管理、などなど、様々なことができます。その機能はチケット駆動開発に十分なものでした。

そんなチケット駆動開発は現場で生まれました。研究所で生まれたなら、たいそうな概念があって、見た目重視の専用ツールがあったでしょう。でもチケット駆動開発は違います。解決したい問題が先にあり、目の前にあったBTSを使ってやってみたらうまくいった。

その概念もあまり固まっていませんでした。私がここに書いていることも人によっては「ちがう!」と言われるかもしれません。でも、実践したらうまくいった。それが「チケット駆動開発」なのです。

「チケット駆動開発」を育てたのは、技術に対して貪欲で、意欲的な人たちです。いまやアジャイル開発も普通のことになりましたが、数年前までは目新しい概念でした。どの程度役に立つのか、あまりわからない状態でしたが、現場に問題を抱えていた技術者たちはアジャイラーになりました。そして進んで実践し、問題にぶつかり、チケット駆動開発を見出したのです。

私が「チケット駆動開発」に魅力を感じるのは、そんな技術を実践する人たちが育てているからかも知れません。オブジェクト指向も、アジャイル開発も、そんな人たちが育てたから、良いものになりました。きっと「チケット駆動開発」も良いものに育っていくだろうと思っています。

このエントリーをはてなブックマークに追加


« 2009年6月 | トップページ | 2009年8月 »