無料ブログはココログ

« 2011年2月 | トップページ | 2011年4月 »

[#TiDD] チケット駆動開発の事例を集めたい

ソフトウェアプロセスは選択的なタスクの集合です。「ソフトウェア開発に銀の弾丸はない」と言いますが、実は銀の弾丸があっても狼男だけではないので必ずしも死なないのだと思います。狼男には銀の弾丸、ドラキュラには太陽の光、フランケンには怪物くん、怪物くんには怪子ちゃんが必要なのです。

CMM/Iで有名なハンフリーさんの「ソフトウェアプロセス成熟度の改善」という本の序文に「『ソフトウェア』危機は死んだ!」とあります。確かにある種の危機は死んだかもしれませんが、それ以外の危機はCMM/Iでは、リーズナブルに殺すことが困難です。

規律正しい方法論や技術がすべての問題を解決することはありません。それは、わかり易く、体系的にまとめた反面、苦手なものもできてしまうのです。

より広範囲の問題を扱うには、抽象度を上げるという方法もあるでしょう。かつてプロセスモデリングがブームだったとき、プロセスの動的な変更を記述する技術が注目されました。抽象化するとたくさんの問題をまとめて議論することが可能になりますので、記述することで議論が容易になったのでしょう。しかし、その反面、具体性がなくなり、現場の問題と結びつけることは難しものになりました。

私がチケット駆動開発に期待しているのは逆のアプローチです。受け皿だけを用意して、具体的な事例を集めることです。

かつて、プラクティスにあだたぬチケット駆動開発という記事で「チケット駆動開発はソフトウェア開発の基盤プロセスであり、多くの目的を達成できる方法論」と書いたのはそんな気持ちからです。

たとえば、Redmineによるタスクマネジメント実践技法には、タスクすべてをチケットにする完全型と、WBSなど既存の仕組みを補うものをチケットにする補完型を定義しています。それ以外にも、ストーリカードを親チケットとする方法、ストーリカードを別の種別のチケットとする方法、Wikiに書いておくという方法もあるかもしれません。

そんな色々なチケット駆動開発の事例を集め、「こんなチケット駆動開発もある。こんな点が良かった」という議論をしてみたいと思っています。現場発の技術であるチケット駆動開発が、現場の問題を解決する方法の基盤となり、現場の問題を解決する選択的なタスクを増やしたいのです。

このような思いから、チケット駆動開発には「No ticket, No commit!」という基本的な規律以外にあまり規律を増やさない方が、たくさんの事例を収集することができ、より現場の問題に対応しやすくなると思っています。

追記:規律のセットの事例を集めるのは「あり」かもしれません。


向上しようと思ったら、愚かな自分を受け入れろ #dvsumi

問題を見極めること同じように限界を見極めることも大切です。映画「セレンディピティ」に哲学者エピクトテスの「向上しようと思ったら、愚かな自分を受け入れろ」という言葉が出てきます。

技術者は技術があるから技術者です。常に新しい技術を身に着ける必要があります。特にソフトウェアの世界は生産性のジレンマで言われるようにプロダクト・イノベーション(画期的な新製品を開発する技術革新)からプロセス・イノベーション(生産の効率化を図るべく、既存生産工程や生産技術を開発する技術開発)に単純に移行するだけではなく、突然、生産性が高すぎて案件が大きくならないなどということが起きる業界ですから、常に最新技術をウォッチすることは重要です。とはいえ、やみくもに技術を身につければ良いとは限りません。

情報化が進む中で、すべてのIT技術を獲得することは困難です。一つの言語のクラスライブラリを熟知することすら難しくなっています。認知科学のロンバック先生は、学校のカリキュラムのように限定されたことを全て学ぶことは、実社会では困難であるとして、Learning on Demandという言葉を使われ、コンピュータによる支援の研究をされています(Learning on Demand and High-Functionality Applications)。

コンピュータサイエンスで習う「計算量」というものがあります(「NP困難」とか「オーダー」とい言った方が通じるかもしれません)。かつて(その後学長になられた)大学の恩師に「計算量なんて役に立たないでしょう」などと生意気なことを言った時、「計算できないことがわかって、人工知能の研究が進んだ」という旨の指摘を受けました。限界を知ることで完璧な答えをあきらめることができ、別の道を歩むことができたのです。

あきらめるというと敗者のイメージがありますが、実は勝つための第一歩だと思います。前の記事で書いた、203高地を避けて問題点を的確に攻めるという兵法も、正攻法をあきらめて勝つということだと思います。

デブサミ2011で和田さんの講演の「脱完璧主義」に感銘をうけたのは、そのような思いがあったのかもしれません。

[#TiDD] アジャイルは戦略 - 「竜馬がゆく」にみる坂本竜馬のアジリティ -

学生のころに司馬遼太郎さんの「竜馬がゆく」を読んで坂本龍馬を知りました。そこに描かれていた坂本龍馬はドラマの「龍馬伝」とは若干異なり、

- 商家の血を引く
- 合理主義
- 策士
- 民主主義を理解していた(ただし英語はできない)

という人物像が描かれています。このうち、司馬遼太郎さんらしいのは「策士」です(「坂の上の雲">坂の上の雲」には203高地の失敗との対比で、秋山兄弟の兵法が描かれています)。ぜひ、読んでいただきたいところです。おなじく長編ですが武田鉄也さん・小山ゆうざんのコミック「おーい! 竜馬 」にも同じような竜馬像が描かれています。

竜馬の行動とアジリティ

そんな竜馬の行動は、こんな特徴があります。

- 既成概念にとらわれない
          ⇒民主開国をめざす
- 正直に話す
          ⇒勝海舟と面談
- 人の話を素直に聞く
          ⇒開国派に寝返る
- 危機感を共有する
          ⇒山内容堂を味方に
- 敵を作らない
          ⇒薩長同盟
- 問題点を的確に攻める
          ⇒船中八策
- 能力を発揮させる
          ⇒海援隊

これらの特徴は、アジャイル開発とも重なるものです。上記の特徴をアジャイルに当てはめてみると、以下のようになります。

- 既成概念にとらわれない
          ⇒複数リリース
- 正直に話す
          ⇒見える化
- 人の話を素直に聞く
          ⇒コミュニケーション
- 危機感を共有する
          ⇒チケット駆動開発
- 敵を作らない
          ⇒ファシリテーション
- 問題点を的確に攻める
          ⇒リーン
- 能力を発揮させる
          ⇒集中(スクラムの価値)
   
このように、アジャイルは従来のソフトウェア開発にとって維新をもたらすものかもしれません。アジャイルの解説を聞いていると、最後に「とにかくやってみる」とか「勇気をもって」と言われることもあります。しかし、ソフトウェア開発はもっと緻密なものです。アジャイルを戦略ととらえることで、より効果的な開発ができるのではないかと思うのです。

問題点を的確に攻める

このうち、「問題点を的確に攻める」ことが最も重要だと思います。一般に要所と言われているところをすべて抑えようとしても、203高地のようになることがあり、必ずしも成功しません。状況をきちんと見極めて、もっとも危険なところを適格に攻めることが大切です。

「パレートの法則」あるいは「2割8割の法則をご存知の方も多いでしょう。2割の問題が8割の影響を与えるというものです。パレート図は、この2割の問題を見つけるためのもので、頻度順に問題を並べてグラフ化をします。

プロジェクトを計画する際には、問題の頻度を予想してその対策を練っておきます。予想される問題によって、上に挙げたものだけでなく様々な対策を検討し、計画します。

アジャイルは戦略です。チケット駆動開発も戦略的な技法の一つです。かつて「『確信をもてたとき』が導入するタイミング」と書いたのは、このような問題の見極めができたときなのです。

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


[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi

ベストスピーカー賞(3位)をいただきました

デベロッパーズサミット2011で、小川さんと共にベストスピーカー賞(3位)をいただきました。ご参加いただいたみなさま、スタッフのみなさま、ありがとうございました。

色々なところで発表していますが、実はこれが初めての受賞です。ノミネートされたり、次点だったこともあるようです。常連のシンポジウムでは、プログラム委員の方から「受賞したことがあると思って推薦しなかった。ごめんね」と言われたことさえあります。なので、章とは縁が無いと思っていました。

今回は、本に興味を持っていただいたみなさんや小川さんの人気に救われたほか、ベストと言いながら3位まで賞をいただけたのが、次点までしか経験のなかった私にはとてもラッキーだったのかもしれません。

ソフトウェア工学の不幸な歴史

今回発表したチケット駆動開発には、特別な思いがあります。それは「現場のソフトウェア工学」であることです。

ソフトウェア工学という言葉は、私が社会人になった時に初めて聞きました。しかし、英語のエンジニアリングという言葉から期待するものと、現場で感じるものはかけ離れているように思いました。現場で苦労しながら開発している現状を、当時のソフトウェア工学は解決してくれないと思っていました。

時は過ぎ、私はソフトウェア工学を学ぶ機会を得ました。そしてわかったのは、ソフトウェア工学は役に立つということです。ただし、正しく実施する、すなわち、ふさわしい問題にふさわしい解決法を実施した場合だけです。

でも、実際には、ふさわしいかどうかと関係なく、ルールだから、とか、良いと言われている、話題になっている、などという理由で、トップダウンに強制されることが多いと思います。

そのような形での技術導入では、現場はやらされ感がいっぱいで、面倒なことにならないように指標に合うように開発するだけです。たしかに、指標が正しいかどうかに関係なく、一定の値になるように開発していればそれなりには安定するという一面もあるのですが、現場から見るとなにも良くなっていない。ソフトウェア工学や改善は管理職のためのもので、自分たちには関係ないことだと思ってしまいます。

そのような状況では精神的な負担を増やすだけで、現場を改善しようと言う雰囲気になるわけがありません。

現場のソフトウェア工学

チケット駆動開発を知ったのは、共著者で一緒に発表させていただいた小川さんからです。現場で苦労されているうちにチケット駆動開発を始められ、「アジャイルがわかった!」と言われるようになりました。チケットでタスクマネージメントするだけだと思っていたのになぜなのだろうと、そのころから私もチケット駆動開発に興味を持ちました。

そして色々と調べたり、考えたりするうちに気が付いたのです。これは「現場のソフトウェア工学」だと。tracとかRedmineは障害管理ツールですから、もちろん障害管理ができます。そしてチケットでタスクを管理するのは、チケットが構造を持つのでWBSと同じ。また、基本ルールの「No ticket! No commit!」は構成管理ツールと連携するのですから、もちろん構成管理もしている。さらには、アジャイルの要素である、タイムボックス管理、スコープの変更、見える化、コミュニケーションの向上。そして、小川さんはEVMとの関係まで語っている。

このように、現場から始まった技術であるにもかかわらず、チケット駆動開発にはいろいろなソフトウエア工学の要素が入っています。現場の問題を解決するために始まったチケット駆動開発によって、ソフトウェア工学の技術をを正しく導入したのです。もちろん、「はやっているから」とか、「おもしろそうだから」と始めてはこれまでと同じです。現場にある問題を確認し、チケット駆動開発で解決で きるなら、その時に導入するべきです。私が発表で、どうしても伝えたかったのはそのことです。それは私が最後に付け加えた一言、

「もし問題がないならばそのままで良いと思います。(説明した)これらの問題が当てはまるならチケット駆動開発を検討してください」

ということです。現場の問題を見極めることから始めることは、現場で改善を進めていくにはとても大切なことだと思っています。

意外にいける赤ワイン BANROCK STATION CABERNET SAUVIGNON / SHIRAZ(更新)

Banrockstation_2

紙パックのワインというと、安いだけで、量が多くてすぐに味が変わるというイメージがありました。紙パックに比べると格段においしいと思っていたカルロ・ロッシの大瓶が姿を消して、最近はみんな紙パックになってしまったな~と思っていました。知らない間に、紙パックは進化していたのですね。

今回、試したのはBANROCK STATIONの赤ワイン。CABERNET SAUVIGNON と SHIRAZ です。いつのころからか、防止剤が気になって無添加ワインしか飲まなかったのですが、ここのところ飽きてきていました。そんなところに「おいしい」と教えてもらったので、試してみました。

買った時には紙の四角い箱ですが、中にアルミコーティングのビニール袋にワインが入っていて注ぎ口がついています。それを引っ張り出すと、写真のようなサーバー状態になります。ご存知の方がおられるかはわかりませんが、日田天領水の箱と同じような方式です。空気が入らないので、味があまり変わりません。

注ぎ口にはレバーがあり、何かに抑えられて出ないように上に持ち上げるとワインが出てきます(上げると出る方式になったのは阪神大震災の教訓からというのは都市伝説ですが、これとは関係ないでしょう)。レバーの倒し方によってワインの出方が強弱2段階になっていて、なかなかよくできています。

さて、味の方ですが、オーストラリアワインらしくすっきりしていて

  • CABERNET SAUVIGNON: 深みがありながらもあっさり
  • SHIRAZ: ほどよい渋み

と感じました。どちらもチーズがあればいくらでも行けそうです。イタリア料理や肉料理にもピッタリで、お金を気にせず気兼ねなく飲めるでしょう(健康には気を付けます)。

イオン系のスーパー(ジャスコ、サティ)やダイエーで売っていました(1,280~1,480円程度)。ご自宅用に一度試されては、いかがでしょうか。きっと、

「そんな、うまい、うまいとか言うて、紙パックでうまいわけないやろ~、、、、ほんまや!」

と思われるでしょう。

#ちなみに関係者ではありません。

[#TiDD] チケットのエクセル連携は工事進行基準と相性が悪い(更新)

工事進行基準

工事進行基準というのは、最終納品時に売り上げを計上するのではなく、開発の進捗に合わせて売り上げを計上できる会計の方法です。毎月売り上げが上がるので、納品が1日遅れるだけで売り上げが次の期なるということがありません。

工事進行基準を採用するには、一定の規模以上で、きちんと計画が立てられていて(ある程度詳細なWBSがあり)、その実施が可能と考えられる場合です(売り上げを単純に期間で立てられる会社もあるようですので、もう少しゆるい場合もあるかもしれません。

私の勤める会社の場合、顧客と合意した工数でWBSを作成し、そのWBS上の

 (完了工数/総工数)×受注金額

で売り上げを決めます(完了工数にもステータスで進捗率を決めるなどのルールがありますがここでは省略します)。チケット駆動開発のプロジェクトではWBS 相当の情報をチケットにしますので、当然のようにチケットの内容をTSVで出力して、エクセルで整形しようと考えました。

そこには壁が

担当プロジェクトは客先常駐作業でした。お客様は情報漏えいを気にされていましたので、条件がつきました。「技術要件が外に出ないように」とのこと。そこで、文字列の入れ替えもしくは番号での表記、あまりにも細かいタスクは連携せずに上位タスクを連携する、といったことをEXCELシートでやりました。

その結果、それなりのWBSができました。しかし、1ヶ月以上の結合テストのタスクができて「詳細化が不足している」との指摘を受けたほか、自分でもどれがどのタスクであるかわかりにくいものになってしまいました。

タスクが増やせない

それだけであれば適当に調整すれば何とかなるのですが、開発を進めるうちに別の問題が発生しました。工事進行基準は総工数に対する完了済み工数の比率で生産額を決めます。しかし、なにかタスクを追加するだけで総工数が変わってしまい、売上げの予定が変わってしまいました。たった1時間か2時間のタスクを追加するだけで、売上げに影響しました。こんな恐ろしいことはありません。

そんな風に勝手に総工数が変わらないように、リーダーなりマネージャが新規タスクを管理すればよいのですが、細々としたチケットまで管理できません。また、細かなタスクも管理できる、個人の作業を自己管理できる、というチケット駆動開発の良さが失われてしまいます。

実は工事進行基準の場合、生産計画の工数と実際の配員工数は一致しなくてもかまいません。お客様と合意した機能に、合意した工数を割り当てたものが生産計画で、余裕を残して少なく配員しても良いし、予想外の問題などで過配員になってもかまいません(利益が減るので問題ですが、、、)。ポイントは計画した時期に、計画した機能が実現されていれば良いのです。もちろん、実現できない時は生産計画を見直します。

問題なのは、生産計画のWBSと配員は異なっても良いのに、両方に共通のチケットにしてしまったことです。チケット駆動開発では作業をチケットにしますので、チケットは配員を表しています。 2日で計画したことを2.5日かかりそうであれば、そのように計画を変更し、他のタスクと調整します。残業を増やして解決できるならそれでも良いですし、余裕のある仲間にチケットを担当してもらってもかまいません。いずれにしろ、計画した機能が経過した時期にできればよいのです。工事進行基準は1か月単位で売り上げを得委譲しますので、極言するならその月の間に計画通りの機能ができればよいのです(もちろん、間に合わなければ再計画が必要です)。

結局、チケットは生産計画ではないということで、チケットからエクセルに進捗を連携することをやめて、生産計画とその進捗はエクセルで管理しました。

じゃあ、エクセルの職場は?

考えてみると、そもそも別物を一つのデータで扱うことが無謀だったのです。生産計画と配員は違うのですから、当初の生産計画に対する進捗と、さらに細かな作業が明確になった現状での進捗は異なって当然だったのです。

では、チケット駆動開発ではない場合はどうしているのか、私は経験が無いので理論だけで考えてみました。生産計画と配員の二つがあるのですから、

  1. 2重帳簿方式で管理している
  2. 「生産計画=配員」として一元管理している

このどちらかだと思います。一般には、「生産計画=配員」のことが多いので、2が多いと思うのですが、どうでしょうか?

もし、そうだとすると、エクセルで管理されているなら、細かなタスクが新たに見つかった場合、こんなことが行われるのでしょうね。

  • 見える化されない:タスクが追加されず、他の人にも知られず、協力もされない
  • 多大な管理工数をかける:WBSを修正、生産計画を修正、売上げ予定を調整する

いずれかの対応が、組織の文化によってなされるのでしょうね。

このように考えると、エクセルだけで管理するよりも、やはりチケット駆動開発で、新しいタスクを追加し、見える化し、協力し合うプロジェクトが良いと思いました。

[#TiDD] チケット駆動開発のはじまり #devsumi

チケット駆動開発は、

  • タスクをチケットで管理する
  • 構成管理上の更新をする際はチケットと連動する(構成管理と障害管理の連携)

というものです。

チケットは障害管理票に当たるものですが、これはかなり昔から障害以外の記述が行われていました。私の知る限り1992年に生まれたオープンソースBTSであるGNATSはバグの管理だけでなく、ユーザとのコミュニケーションが目的であり、2003年に使った時にはすでにBugとFeatureが標準の分類にありました。

2番目の構成管理と障害管理は、たぶん1980年代から行われていました。構成管理では、ベースラインを決めて、そこからの変更の管理をしていたからです。障害は障害票で管理されて連番が降られますから、ベースラインからの変更理由として障害票の番号を書くことは自然だからです。

このように、チケット駆動開発の基本的なルールはすでに20世紀から実施されてきたと思われることです。しかし、それは一般の開発現場のためでなく、オープンソースの開発であり、管理のためでした。これらはツールで自動化されることなく、別々に行われました。これがチケット駆動開発と大きく違うところです。

チケット駆動開発はtracから始まりました。tracは障害管理ツールの一つですが、以下のような特徴がありました。

  • チケットの種類に「タスク」が始めからあった
  • 構成管理ツールと簡単に連携できた
  • Wikiが組み込まれており、その記法としてチケット番号やチェンジセットへのリンクがあった

このように、オープンソースでなく一般の開発が考慮され、管理者でなく開発者を意識したつくりになっていたのです。tracを知った開発者たちは現場で活用し、Shibuya.tracなどで、多くの情報交換が行われました。

その当時に有名だったのは、masuidriveさんで、チケットでプロジェクト管理することを提唱されていました。そのような中で、まちゅさんがチケット駆動開発を提唱されました(このころのことはtogetterチケット駆動開発のはじまりをご覧ください)。

まちゅさんは上述の基本ルールを、現場の実体験を通じて提案されました。これが、XPJUG関西の人たちの目に留まり、略称がTiDDとなり、アジャイルに関する議論が行われ、あきぴーさんを通じて私も参加するようになりました(アジャイルに関してはまちゅさんもコメントされています)。

そうこうする間に、tracを参考に開発されたRedmineが注目を集めるようになり、あきぴーさんと史上初のチケット駆動開発の本を書くことになったのです。

謝辞:

上に挙げさせていただいたmasuidriveさん、まちゅさん、XPJUG関西のみなさん、あきぴーさん、に感謝します。また、この記事を書くに当たってTwitterでかぬさんに色々と教えていただきました。感謝いたします。そして、かぬさんへの質問のきっかけになったのは、デブサミ2011の講演中のつぶやきでした。これは会場のアンテナ設置がなければ、そのきっかけを失っていたでしょう。スタッフのみなさん、ソフトバンクのみなさんに感謝いたします。

« 2011年2月 | トップページ | 2011年4月 »