[TiDD] チケットの粒度に気をつける

チケット駆動開発の特徴は、管理的でなく自律的にプロジェクトを管理できることです。チケット駆動開発を実践すると、作業の抜けをなくそうと開発メンバー自身が進んでチケットを登録し、日々残チケットを確認しながら作業します。細かな作業ももれることがなく、きちんと行えます。

チケットに登録することは、作業工数が小さければ小さいほど有効です。大きな作業を忘れることはあまりありませんが、小さな作業は「うっかり」が発生しやすいからです。

管理者は全体の進捗と残業時間を管理するだけで日々の作業が進んでいきます。しかし、順調に進んでいるからとチケットを見ていないと危険な場合があります。

それはチケットの粒度がそろっていないとき、つまり作業時間のかかるチケットが混在するときに生じます。小さなチケットがたくさんあるとき、開発者は日々チケットをチェックして、作業対象と順序を決定して作業を進めます。しかし、作業時間のかかるチケットがあると、日々の作業のリズムが崩れます。作業工数の大きいチケットだけを気にするようになり、細かな作業のチケットがなおざりになりがちです。

チケット駆動開発は作業の抜けをなくします。しかし、チケットの粒度に気をつけなければうまくいきません。もし、細かなチケットに分けることが難しいなら、細かな作業のチケットを忘れていないか管理者が気をつけなければならないでしょう。

[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する-

あきぴーさんと書いた論文が公開されました(2-1、今週公開されたようです)。

引用していただける場合は、こんな感じでどうぞ。

小川明彦, 阪井誠, チケット駆動開発 - BTSでExtreme Programmingを改善する-, SQiP2009, 第28回ソフトウェア品質シンポジウム2009発表報告集, pp.93-96, 日本科学技術連盟, 2009.

<')))><

[TiDD] チケット駆動開発は見える化でもある

チケット駆動開発にはいくつかの側面があります。

開発者にとって大きいのは、ToDoリストとしての側面でしょう。忘れてしまいそうな細かな作業を、どんどんチケットにすることで忘れずに作業をすることができます。

以前、ある人が「備忘録」言われた際には、正直なところ抵抗を感じました。しかし、開発者が積極的にチケットを起こす動機は、やはり抜けなく作業をしたいと言うことに尽きると思います。

チームとして考えると、チケット駆動は見える化でもあります。チケットの発行は、これから解決しないといけない問題点(issue)を共有し、明らかにする行為です。

チケットによってプロジェクトの現状が明らかになり、コミュニケーションが向上します。また、だれが何をしているかも管理が容易になり、必要なフィードバックが可能になります。

作業の見積もりがきちんと行われているならば、アジャイルで必要となるタイムボックス管理も可能になるでしょう。

チケット駆動開発は見える化でもあるのです。

<')))><

[TiDD] チケット駆動開発の最初の一歩

チケット駆動開発で最初にすることは、「上司への報告！」というねたは終わったので、具体的に進めましょう。

前回書いたように、どのようなものをチケットにするかプロジェクト内で決めておくことはもちろん、チケットを参照する環境を整えなければなりません。

たとえばtracなら、既存のレポートをコピーして修正するだけです。とりあえず以下のようなレポートを作成してはいかがでしょう。

　　- bugのみ
　　- taskのみ
　　- その他

当初、品質管理用にbugのみを作成しましたが、すぐに作業管理がしやすいようにtaskのみというものを作りました。そうすると、抜けができるので、残りのみを参照する「その他」を作りました。抽出条件(WHERE句のところ)や表示項目(前に"_"があると表示されない)は自由に変更できますので、プロジェクトによって用意されると良いでしょう。

また、tracの権限の設定が堅いので、チケットを修正できるようにメンバーに権限を追加すると良いかもしれません。私のプロジェクトでは、memberにTICKET_ADMINの権限を与えました。それなりのリスクもありますので、よく検討して設定してください。

[TiDD] チケット駆動開発はじめました

あきぴーさんと共著で発表活動をしていますが、これまではチケット駆動開発の経験はありませんでした。とはいえ、今世紀の初めからBTSを遣っていますし、アジャイル開発の経験もありますので、あきぴーさんの経験を聞きながら一度はチケット駆動開発をしてみたいと思っていました。

しかし、現在のプロジェクトはウォータフォールで開発していますし、メンバーは7人と試行するには中途半端な規模、個人の趣味で仕事をするわけにもいかないので、あきらめていました。しかし、その時は突然訪れました。

プロジェクトはオープン系の事務システムで、外部システムとの連携があることもあり、色々と予想外のことが起きていました。これまでもWBSを変更することが多かったのですが、それはシステムテストの時期になってもおさまりそうにありませんでした。

ハンフリーさんは「TSPガイドブック：リーダー編」で、アイアコッカの言葉を引用して「ボスのスピードがチームのスピードだ」(p.9)と書かれています。また、司馬遼太郎さんの「龍馬がゆく」には、北辰一刀流の「気は早く、心は静か、身は軽く」と言う言葉が載っています(あんまり関係ないですが、、、）。

現状を見極めると、今こそチケット駆動開発を実践を決断するときだと思いました。不具合だけでなく、*新たに*必要となった作業は、必ずチケットに登録して作業することにしました(全ての作業をチケットにしないことで、チケット数を減らしました)。

実際にやってみると、結構使えます。日々新たに発生する作業が、手に取るようにわかります。メンバーも作業を忘れないようにと、進んでチケット登録をしてくれます。予想外の変化を抱擁しながら、管理が一元化され、コミュニケーションが効率的になり、そしてメンバーに適時支援(フィードバック)が可能になりました。勇気を持って導入してよかったと思います。繰り返し開発こそしていませんが、まさにアジャイルな開発です。

ただ、一つだけ失敗したことがあります。それは上司に報告していなかったことです。上司にtracのメールを流さなければよかったのですが、何も知らされない上司に「tracのメールが急に増えたけど品質は大丈夫？」と確認されました。

これからチケット駆動開発を始めようとするあなたに言っておきます。上司には必ず報告してください。

「チケット駆動開発はじめました」

と。

＃それって冷麺じゃないの？　いや、冷やしシャンプーのパクリです(笑)

<')))><

[TiDD] 小規模開発の難しさを考える

もう20年以上前になりますが、私がソフトウェア業界に就職したとき、最大10人程度の小規模プロジェクト(当時は間違いなくそういわれていました)に配属されました。

当時はいかに大規模開発を管理するかと言うことが注目されていて、各社で開発標準が決められつつあったころです。当時、小規模プロジェクトの管理はあまり注目されていませんでした。大規模プロジェクトが不採算になると会社がつぶれますが、小規模プロジェクトの不採算なら何とか耐えられたようです。

大規模プロジェクトが難しいのはだれもが認めるところでしたが、小規模プロジェクトにもそれなりの難しさがあり、当時、それはなぜか、どうすればよいか、と考えていたことを覚えています。

時代は移り、大規模プロジェクトではプロセス改善に費用をかけることで、比較的安定した開発が行われるようになりました。特にTSP/PSPでは階層的な管理が行われ、個人からチームへと積み上げによって高い精度で定量的な見積もりと管理ができるようになりました。プロセス改善を進める企業においては、その枠組みに入りきらないようなプロジェクトが企業の利益を圧迫するとまで言われています。

一方、小規模開発に関しては、アジャイル開発があるものの、高い能力を持つ技術者が必要とされていて、全ての小規模プロジェクトを救えるかどうか、難しいところです。

さて、ここで小規模プロジェクトはなぜ難しいかを考えて見ます。規模の大小にかかわらず、外部環境の変化による業務要件の変更、外部仕様の決定遅れ、ミドルウェアなどの開発基盤により生じる問題、は同じように発生します。

リスクは一般に問題の大きさとその発生確率で表現されます。大規模プロジェクトでは、それらを乗じた予算をあらかじめ用意しておくことで、問題が発生しても解決できます。これはリスクが統計的に扱えるほどに、プロジェクトの規模に比して小さいからです。

小規模プロジェクトあるいはプロジェクトの規模に比べて大きなリスクの場合は、問題が発生することで危機的な状況に陥ります。品質低下、予算超過やスケジュール遅れ、といういわゆるQCDが守れなくなるからです。

リスクが問題化したプロジェクトを健全な状態に戻すには、
(1)発生している問題をきちんと把握する
(2)優先順位を決めて作業手順を定める
(3)全ての問題を確実に解決(あるいは対処)する
ということが実施できなければなりません。

これは、まさにチケット駆動開発(TiDD)が支援することです。ソフトウェア開発集に生じた問題や予定していない作業をすべてチケット化し、優先順位を決めて、確実に作業する、TiDDのプロセスそのものです。

このように考えると、TiDDは小規模プロジェクト、特に、仕様変更の多いプロジェクト、細かな仕様が多いプロジェクト、予想外の問題や作業がが生じやすいプロジェクト、に向いていると言えるでしょう。

[TiDD] プラクティスから方法論へ

「チケット駆動開発」というキーワードで検索すると、名古屋で勉強会が開かれていたり、実際の仕事で試されている方がおられたり、色々なところで注目されていることがわかります。

そんな中で気になったのが、「チケット駆動開発の研究と実践http://blog.livedoor.jp/techblog/archives/64874955.html」(livedoor 開発Blog)です。ここでは、チケットによる見える化http://sakaba.cocolog-nifty.com/sakaba/2009/07/tidd-1b90.htmlや達成感というメリットのほか、こんなデメリットも書かれています。

「チケットを発行するときは楽しいのですが、クローズしたりステータスを変更するときはチケットが多いほど手間がかかります。」

そして、管理者をつけたほうが良いとのこと。確かに、たくさんの作業を見える化できることがTiDDの特長ですが、管理作業そのものは従来と同じですし、全体の状況となるとチケットを容易に増やせる分だけわかりにくくなるかもしれません。

実は関連する議論をしたことがあります。題して「TiDDは方法論か、プラクティスか」。アジャイル開発やテスト工程などでTiDDをプラクティスの一つとして用いるならば、大きな効果を挙げると思います。しかし、方法論として考えると、チケット駆動開発の基本である「チケットなしではコミットを許さない」というルールだけでは規模が大きくなると開発できません。

そのような現実から考えると、厳密にはTiDDはプラクティスと言えると思います。では、みなさんはどうされているかというと、あきぴーさんなどは上流はウォータフォール、製造はアジャイルをベースにTiDDを用いられているようです。

では、あきぴーさんの開発方法はTiDD開発方法論であるかというと、そうでもあるし、そうでもない。本人がそうだといえばそうなるのかもしれません。しかし、詳細が定まっていないものを方法論というのもおこがましいので、私とあきぴーさんで外部発表した際には「TiDDをアジャイル(あるいはXP)に適用した」という表現を使っています。

方法論とするには、いくつかの定義が必要だからです。具体的には

チケットの管理の方法：ワークフローの一般化。役割と作業の詳細な定義が必要です。また、チケットの統合や分割の定義も必要です。

作業の管理：チケットと紐づいた作業を日々どのように管理するか。作業が増えた際にどう管理するか。

要件あるいはストーリカードとチケットの関係：チケットをXPのタスクカードとするならば、ストーリーカードはどうなるのか。何らかの参照が必要なことはわかりますが、具体的な方法を示さなければなりません。

ほかにも色々あると思います。実際には、現実のプロジェクトが目の前にあるのですから、色々工夫をしながら具体的な事例積み重ねることだと思います。そしてそれらを元に、まとめていければと思っています。

(事例の提供者おられませんか？もし、論文を書きたいのなら、お手伝いならしますよ～)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TiDD：チケット駆動開発

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

１．チケット駆動開発の始まり

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

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

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

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

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

２．アジャイル開発への適用

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

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

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

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

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

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

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

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

３．TiDDの二つの側面

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

３．１ ajaxのようなもの？

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

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

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

３．２ アジャイル開発のプロセス改善

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

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

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

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

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

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

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

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

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

５．まとめ：チケット駆動開発の魅力

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

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

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

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

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

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

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

不況時のプロセス改善 - 脱ノルマ -

少し前になりますが、TV東京系の経済番組(WBS)で「脱ノルマ」という特集をしていました。不況が迫る中、ノルマを課して売り上げアップを狙っても限界があるので、ノルマをやめて利用者に好まれる販売に徹する様にしてリピータを増やしたというお話でした。これまでならノルマを考えて、推奨品や高額品を進めていたが、お客様に最も喜ばれる商品を勧めることができるようになったというお話でした。

さて、これをソフトウェア開発に当てはめるとどうなるでしょうか？ノルマと言うのはやはり生産性や経済性になるでしょう。そしてその延長の品質向上だと、手戻りが少なくなるような信頼性の向上と言うことになるでしょう。

そして、脱ノルマプロセス改善に当てはめるなら、顧客重視と言うことでしょう。品質＝信頼性ではなく、品質＝顧客満足となるような品質向上が必要なのでしょうね。そこでの問題をなぜなぜ分析してフロントローディングすると、結局は要求を如何に引き出すか、如何に顧客との信頼関係を築いて協力してもらうか、と言うところが改善のポイントになるような気がします。キーワードとしては、プロトタイピング、アジャイルのほか、狩野モデルあたりでしょうか。

不具合摘出工数 - SEA関西プロセス分科会 -

ソフトウェア工学やプロセス改善に大きくかかわるのが、不具合摘出工数です。先日のSEA関西プロセス分科会の秋山先生のTSP/PSPの講演でも話題になりました。

コードレビューなら1欠陥を修正するのに2分ですむが、単体テストなら32分、システムテストなら1405分かかると言うものです。これは、バグを修正する時間だけでなく摘出する、つまりテストの時間を含めてバグ数で割ったものだそうです。

メアリー・ポッメンディーク他,リーンソフトウェア開発,p.82-84, 日経BP社, 2004.のよると、スパイラルモデルやアジャイルと規律で有名なベーム先生が言いだしっぺのようで、リリース後は開発中の100倍だとか5倍だとかの工数がかかると言われているようです。

秋山先生によれば、バグを見つける工数も含むと言われるのですから、テストが進むにつれて、すなわち品質が向上するにつれてバグが見つかる確率が下がる、見つける工数が増えるのは当たり前ですよね。しかも、一度に結合してしまう(ことが多い)ウォータフォール開発では、バグを見つけてから除去するために、問題箇所を突き止めるのも難しくなるのは当然です。

アジャイル開発は、段階的に開発・テストをしますから、バグの入っていそうなところを中心(というか古いところは自動テストされるので発見工数が不要)にテストされるので、常にほぼ同じ確率で発見できるでしょうし、バグが見つかっても追加したコードがおそらく原因でしょうから、バグの除去にかかる時間も安定しているのでしょうね(まあ、アジャイル開発でも、規模が大きくなればそれなりに工数は増えますし、品質保証部門のテストがあれば工数もかかり、デバッグも難しいでしょうけど)。

さて、この後の工程ほどバグの修正にコストがかかるというのは、プロセス改善の基礎になっています。「フロントローディング」などと言う言葉がありますが、後の工程で発覚しないように、前の工程でバグをつぶすような活動です。後工程ほど工数がかかるのだから、早めに見つけるのは当然だし、途中の作業を飛ばすなんて言語道断と言うわけです。実際にテスト工程のどれかを飛ばしてみると、その意味が良くわかります(良い子はまねをしないでね)。

リリース後の品質が悪くて工数がかかって仕方がないなら、プロセス改善のチャンスです。改善結果が利益に直結するので、きっと楽しい活動になると思います。

TiDD：チケット駆動によるアジャイル開発法

3月6-7日にあるソフトウェア信頼性研究会の第5回ワークショップ(申込み締め切りが２月２０日まで延びました)に参加します。良い機会なので、チケット駆動開発(TiDD)についてまとめてみました。

「TiDD：チケット駆動によるアジャイル開発法」(PDF)

文字ばかりのポジションペーパーですが、コメントがいただけるとうれしいです。

ET-WESTの発表内容

パネルで発表したポジションです。コメントがいただける嬉しいです。

-------------------
アジャイルと規律のバランス派

(1)アジャイル開発について

• 組み込みはもともとアジャイル的な開発が多い
• アジャイル向きの問題があるなら部分的(プラクティス*1、工程*2、モジュール*2)に導入すべき
• 環境・仕様の安定度、品質の確保、支援ツールがポイント

*1川端,阪井,小林,効果的なXPの導入を目的としたプラクティス間の相互作用の分析, SS2004.

*2バリー・ベームほか、"アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～", 日経BP, 2004.

(2)開発ポリシー

• 現物主義とすり合わせ(コード中心、プロトタイプ、実機)
• 可変要素の切り出しと繰り返し開発
• 品質の確保(第三者検証、ピアレビュー)

(3)課題

• 部分的な導入ノウハウの蓄積
• リファクタリングの勇気と環境が欲しい
• 各種メトリクスの収集など管理をしやすくする工夫(EPM?)

＊EPMツール：http://sec.ipa.go.jp/tool/epm.php

ETWEST2008に出ます

6/5-6にインテックス大阪でETWEST2008が開催されます。
6/6（金）の午後にXPJUG関西のパネルディスカッション「組み込みアジャイル開発の現場」が行われます。わたしもパネラとして出ますので、ご興味のある方は是非ご参加ください。

組み込みでアジャイル開発を導入した経験者の体験談を元に組み込み開発の現場でアジャイル開発を導入する時の課題や課題に取り組むノウハウについてディスカッションします。私は「アジャイルはバランス」の立場で発言するつもりです。

発表資料：エンピリカルソフトウェア工学の実践

ご参加いただいた皆さま、ありがとうございました。

遅くなりましたが、発表資料を公開します。

配布資料(SEA版)：http://sakaba.cocolog-nifty.com/SEA/sea080227.pdf
EPM論文：http://sakaba.cocolog-nifty.com/SEA/SS2004EPM.pdf
WebTracer論文：http://sakaba.cocolog-nifty.com/SEA/ss03WebTracer.pdf
XP論文：http://sakaba.cocolog-nifty.com/SEA/SS2004XP.pdf

なお、スライドは以下の第9回の案内の下のほうにあります。
http://www.sra-ktl.co.jp/Seminar/seminar-j.html

ある種の制約は自由を増やす

いつも読ませていただいている、まつもとゆきひろさんの日記でITproの“Rubyに学ぶ「Ruby on Railsの正体」”が紹介されていました。

いわゆるフレームワークは、良く出てくるパターンを簡単に記述できるようにしたものです。Ruby on Railsの特徴はさらにに一歩推し進めて、制約を与えることでより簡単に記述できるようにしたものです。本文中の表現でいうと「Railsを使いこなすということはRailsの支配を受け入れることである」と言うことになります。

まつもとゆきひろさんは、これを的確な指摘であるとして

ある種の制約は自由を増やす傾向がある。ある種の自由は人間の負担を増す傾向がある。

と述べられています。この文章を読んで、「まさにそのとおり」と思いました。

ソフトウェア工学の初期においては、構造化プログラミングはスパゲティプログラムによる混乱からプログラマに自由を与えました。オブジェクト指向言語も何でもできるC++に制約を与えて、Javaの安心してプログラミングできる自由な世界が作られました。VBに代表されるコンポーネントベースのプログラミングも、コンポーネントという制約を与えることで複雑な機能の組み合わせが自由になりました。

Ruby on Railsについては、まだあまりよく知らないのですが、ソフトウェア工学の流れに沿った新しい自由を構築するものなのでしょう(SEA関西SPINでもRuby on Railsの講演が計画されているようなので楽しみにしています)。

ところで、このお話をプロセスにあてはめる時、ウォーターフォールの方が制約をたくさん与えるのだからより自由だ、などと言うのは詭弁です。ウォーターフォールの制約にしろ、XPのプラクティスにしろ、毎回考えていると負担になることを制約としてまとめることで、プロジェクトの戦略的な実施や、状況の把握、バグの地獄からの解放という自由を与えるものだからです。とにかく制約すればよいのではなく、「ある種の制約」とよべるような開発者の創造性を高める制約でないといけないと思います。

コミュニケーションと田舎暮らし

XP(Extreme Programming)では、コミュニケーション、シンプル、フィードバック、勇気の4つの価値(最近は尊重を加えた5つの価値)が根幹であると言われます。今回は、このうちコミュニケーションについて考えて見ます。

コミュニケーションはウォーターフォールモデルでの開発でも、仕様書がきちんと作成されなかったり、利害関係者に渡っていないと、無駄な開発が行われたり、必要なものが開発されない、重要なデシジョンを誤るなどの問題が生じます。しかし、ここではそのようないわばマスコミ的なコミュニケーションでなく、アジャイルソフトウェア開発に特有なコミュニケーションを考えてみたいと思います。

アジャイルソフトウェア開発におけるコミュニケーションの必要性は、田舎暮らしを考えると分かりやすいと思います。田舎では、ある特性を持つ地域に、少ない人間が住んでいて、特産品や郷土料理などを作り、お互いに協力し合って生きています。そんな田舎では、情報交換をうまくやらなければ生きていけません。

1.独特の問題・情報がある
あの山に雨が降ると川が増水する。XXに熊が出た。など、マスコミに流れないその土地特有の問題や情報があります。

2.熟練・知恵が必要
他所ではできない特産品を作るには、熟練工を育てなければなりません。口では簡単に伝えられない技術を作業を通して伝える必要があります。原材料が不作になるなど、これまでになかった問題には、知恵を出し合って解決します。

3.一人の問題が全体に影響する
お互いに協力しあって生活しているので、誰かが病気になればすぐに助けます。火事が出れば協力して消火します。そのような緊急の情報は地域全体に知らせる必要があります。

なんとなく、アジャイルと似ていませんか？

1.独特の問題・情報がある
業務に固有の問題があるので、オンサイト顧客(全員同席)によって、ユーザの情報をきちんと理解する必要があります。

2.熟練・知恵が必要
よく考えられたプログラムを開発するには、熟練者を育てなければなりません。ペアプログラミングによって技術を伝える必要があります。また、困難な問題が生じた場合には、二人で協力してアイデアを出します。

3.一人の問題が全体に影響する
計画ゲームを行い、全員で手分けして開発しますので、どこかに問題が生じると全員に影響します。日々の問題をスタンドアップミーティングで把握します。

このようにアジャイルのコミュニケーションは、田舎暮らしのコミュニケーションとそっくりです。コミュニケーションの重要性が、少し分かったような気になりませんか？

これを元に、アジャイルでない開発方法をとる条件を考えこともできます。以下が満たされていないといけません。

• 業務知識を形式知にできる。あるいは、手分けするには形式化が必要である
• 力技で解決できる程度の複雑さである。あるいは、効率よく分担することのほうが主たる問題である。
• 規模が大きいので、小さな問題は全体に影響しない。あるいは開発期間が長いので、問題が発覚してからでも対策が取れる

アジャイルのコミュニケーションを田舎暮らしのメタファで考えてみました。いかがでしょうか？

Rubyの魔法と動く標的のためのアジャイル - XP祭り関西2006 -

「XP祭り関西2006 in ワッハ上方」が終わりました。スタッフだったので、あまりゆっくりとは聞けませんでしたが、とっても良かったです。じっくり聞けた中で良かったのは、Rubyのまつもとゆきひろさんの講演と平鍋健児さんの講演、そして牛尾さん・しゃけさんの寸劇でした。

お髭のまつもとゆきひろさんの講演は「The State of the Dominion(世界制覇への道)」で、日本Rubyカンファレンスと同名のタイトルでしたが、言語の中でRubyのランキングが高くなったことやRubyが利用者を洗脳するお話など、けっこう手が加わっていました(詳しくはXP祭り関西ホームページに後日公開される資料を見てください)。

個人的には、前回の資料にもあった「魔法」という言葉が印象に残りました。Rubyをはじめて見たのは、ベクターのパックシリーズというフリーウェアライブラリの本や、ニュースグループfj.lang.oopsの議論で、面白い人がいるなぁと見ていました。そうこうするうちに、仕事でawkを2000行ほど書いて苦しんでいました。その後、C言語のプログラムの簡単な構文解析をしなければいけなくなって、Rubyを検討しました。もちろんRubyしかありませんでした。

初期のawkは関数もなく、システムVでようやく関数ができた程度でしたので、Rubyは本当に便利でした。特に、イテレータ。C-shell等には、あるだけ繰り返すforeach等がありましたが、それをさらに強化している。それだけで魔法にかかりました。

最近は、さらにすごいですよね。まつもとさんの髭の効果(らしい)でRuby on Railsができましたし、ライブラリの充実もなかなかすごいですよね。最近の私の経験ではメールを簡単にPOPできるので、驚きました。この、開発者が思い通りに書ける言語と言うのは、型宣言のいらない動的言語であるだけでなく、コミュニティが活発であることも関係しているのでしょう。洗脳と言うよりは、魔法に魅せられたという感じですね。

平鍋健児さんの講演は、東京のXP祭りと異なり「現場力を高める見える化手法プロジェクトファシリテーション」でした。ここには書ききれない中身は公開される資料を見ていただくとして、心に響いたのは、「動く標的」の話でした。

「ウォーターフォール開発は動く標的を大砲で狙うようなもの」たしかにそうかもしれません。でも、まあ基本はそうですが、管理された仕様変更は可能で、工程の終わりのレビューはありますね。正確に言うなれば、多段の固定燃料ロケットのようなものでしょう。ある程度は調整できるが、限界があるんですよね。

それに対してアジャイルは、常に変更可能で、言うなれば自動追尾ミサイルのようなものですよね。まるで逃げていくような仕様に対しても俊敏に追跡する。そこには、標的を随時把握して、追跡するという明確な目標があります。

ここまで書いて、月ロケットってどうなんだろうと思いました。月ロケットは動きが予測可能で、一発勝負でロケットを飛ばすようなことも可能かと思われますが、実際は宇宙空間にある様々な問題を解決しなければなりません。

そう思うと、東京で平鍋さんが「大人の意見」と評されていた「アジャイルと規律」を思い出しました。逃げ回る戦車には、自動追尾ミサイルのアジャイルだけでよいですが、月ロケットまでいかなくても、それなりの規模・複雑さになると、うまく組み合わせる必要があります。

そう思うと、牛尾剛さんがしゃけさんとのペアプロ寸劇「NEVER NEVER NEVER SURRENDER～アジャイルやりたいんや～」での言葉が思い出されます。仕事でアジャイルさせてもらえなくても、フレームワークのプロトタイプ開発や、ちょっとしたツールなど、「様々な場面でアジャイルは使える」との言葉は、すぐにでもできるプロセス改善としてすばらしい発想だと思いました。

色々大変でしたが、関西で200人もの人が集まりました。これは、はっきり言って驚きです。また、参加された方にも喜んでいただけたようなので、良かったと思います。講演者のみなさん、キャスト(スタッフ)のみなさん、そしてゲスト(参加者)のみなさん、ありがとうございました。

ペアプログラミング

XP祭り2006(東京)ではのプログラミングコンテストでのコメントに考えさせられました。
「ペアでやると詰まってしまわないというメリットがあると思うのですが、二人で『どうしよう？』と言っていると進まない」と言うコメントは、なかなか楽しいコメントでした。

これまで、ペア・プログラミング(ペアプロ)は常にレビューすることになり、品質、特に信頼性が高くなると考えていましたが、こんな側面もあるのですね。そこで、オブジェクト倶楽部の説明を読むと、

ペアで行う方がよりよいコードを一人で行ったのと同程度の効率で生産することを示している。その通り: 二人の頭は一人の頭より良いのだ！

とされています。なるほど！

そのように考えると、対象の問題の難しさが、ペアプロの有効性に関連することになりますね。誰でもできる簡単な問題なら一人でもかえって効率が落ちますが、色々なアイデアを出し合ったほうが良いような難しい問題ならペアプロに向いていることになります。

また、保守性を高めるために多方面から検討した良い構造が必要な場合も、ペアプロが向いていることになります。また、二人でも難しい問題なら、より多くの人間が検討したほうが良くなります。

アジャイルソフトウェア開発には、有能なエンジニアが必要になると言われますが、実は簡単な問題しか解けない人の組み合わせでは、ペアプロをしても意味がないという面もあるのかもしれませんね。

IT技術者を幸せにするには

ITmedia News にショッキングな記事が出ていました。

「日本のIT技術者、幸せではない」──MSの課題
マイクロソフトのヒューストン社長は、新年度の課題として「IT技術者の地位向上」を掲げる。「あまり幸せではない」ためだ。

この記事はマイクロソフトのダレン・ヒューストン社長が、経営方針説明会で話された内容です。同社が「ITスキルの向上を支援していく」前提としてお話された内容です。

この記事は、さらにスラッシュドット・ジャパンでも取り上げられて、多くの意見が寄せられています。批判的な意見の多くは、「技術力をつけても仕事が集中して不幸になるだけ」という、悲しくて、情けなくなるようなコメントでした。

この元記事を読んだとき、最も気になったのは、なぜ幸せでないとされているかです。

「日本のITプロは『社内のPCを購入する』という決定はできても、プロジェクトなどの上位の大きな決定には参加できてないようだ」

この事実の原因が技術力にあるというのは、多くの日本企業に当てはまらないと思います。私が思うのは、日本の企業は組織構造がピラミッド型で、しかも強固であることです。このことが日本企業の強みであり、弱さであると思ってます。

主なソフトウェア危機は、巨大なソフトウェアを開発すること、品質の高いソフトウェアを開発することだと言われています。かつては、バグのないことすなわち信頼性がソフトウェアの主要な品質だと考えられてきました。

しかし、ソフトウェアの機能が高度化するにつれ、ユーザの求めるソフトウェアが開発されているか、すなわちユーザにとっての品質が重要視され、様々なアジャイルソフトウェア開発が提案されてきました。

アジャイルソフトウェア開発が注目される中、日本では導入される企業と、どうも普及しにくい企業に分かれていると思います。導入が遅れる原因は簡単です。技術者がいないこと、そして管理しにくいからです。

管理可能なことでないと実施させてもらえない。それは、当たり前の問題の発生を減らします。これ派大きなメリットである反面、独創的なアイデアや社員のやる気をなくします。

構造化プログラミングからオブジェクト指向に、ソフトウェア開発のパラダイムはシフトしてきました。これは、トップダウンでの開発には限界があり、ボトムアップな要素を入れる必要があったこと、開発を効率化する再利用には、小さなオブジェクトの組み合わせが有効であったからだと思います。

IT技術者を幸せにするには、ソフトウェア開発で生じたようなパラダイムシフトが、組織にも生じる必要があるのかもしれません。トップダウンで管理されるのでなく、自律的で協調的な高度なITエンジニアを育成できる組織が求められていると思います。

それは、上の記事にある教育的なことも含むでしょうが、重要なのはITエンジニアが自立的に行動する組織文化ではないでしょうか？

SS2006参加者募集中

今年のソフトウェア・シンポジウムは熊本で開かれます。
7月19日(水)～21日(金)(チュートリアルは18日)の間、初日は従来の発表形式、2日目はワークショップ形式で開かれます。締め切りは7月10日で、参加者募集中です。
ぜひ皆様ご参加ください。

私はグループBの「要求仕様，テスティング，メンテナンス」で申し込みました。別のグループにするつもりだったのですが、アジャイル系のお話をさせていただこうと思ったら、このグループになりました。

ポジションペーパーはこんなのを出しました。こんなに柔らかい文章が書けるようになったのはブログのおかげでしょうね(笑い)。

すべての仕様を早期に確定してはいけない
       
「一向に確定しない要求仕様」という発想が、はじめに仕様ありきというウォータフォールモデルにとらわれすぎではないだろうか。ソフトウェア開発工程の標準として、「要求が全て確定されていること」あるいは「確定してないことのリスクを考慮しているか」といったチェック項目が比較的多いと思われる。しかし、「仕様を早期に確定する無駄・リスク」に関しての考慮が不足していると思われる。

トヨタ式改善のソフトウェア版とも言うべきリーンソフトウェア開発では「決定をできるだけ遅らせる」事が重要視される。「決定をできるだけ遅らせる」とは、決定をずるずると遅らせる意味ではなく、最終決定時点を決めて、それまでは決定を選択的にするなど、最終的な決定を遅らせるということである。

ウォータフォールモデルに対するアジャイルソフトウェア開発のアンチテーゼのうち、もっとも大きなものは仕様変更を受け入れることである。要求仕様には全てを知った上でないと最適な決定が困難なものがあるという事実を受け入れ、推測によって決定を早期に行うことのリスクをもっと考慮すべきだと思う。

実際のソフトウェア開発現場では、必要に迫られてこのような開発も一部行われている。しかし、ソフトウェア開発の効率化を考えるのであれば、より積極的に方法論として取り入れるべきではないだろうか？

参考文献：
M. Poppendieck, T. Poppendieck, "リーンソフトウェア開発", 日経BP企画, 2004.

「アジャイル開発の勘違い」- JaSST'06 in Osaka -

JaSSTソフトウェアテストシンポジウム'06 in Osakaに行きました。
今回は2日間のイベントで、テストの実務的な内容を中心に、テストのノウハウや形式手法といった技術的な内容から、JSTQBテスト技術者資格制度やIT検証産業協会（IVIA)などの社会動向の情報まで豊富な内容で実施されました。

昨年のスポンサーセッションはテクノロジーセッションに変わり、スポンサーの講演だけでなく、パネルなども取り入れた無料セッションになりました。スポンサーの講演というと商品説明をイメージしますが、JaSSTの場合はきちんと技術的な内容も入っているので、それなりに楽しめます。

このテクノロジーセッションで最も興味深かったのは永和システムマネジメントの天野さんによる「アジャイル開発の勘違い」
でした。

• ドキュメントを書かないのでなく、不要なドキュメントを書かない。これは、決まりだからと思考停止をしないということ。
• 過剰な設計をしないというよりも、効果的な設計がすばやくできるように教育に力を入れる
• 短期に開発できると思われがちだが、短期すぎるものはオーバーヘッドの方が大きいのでには向いていない。早期リリースして、成長させる
• リファクタリングしても品質低下しないのは機能だけで、コードが効率的でなくなるなど品質低下する場合もある
• テスト駆動開発をすればテストは十分だと思われがちだが、テスト駆動のテストコードは設計を目的としているので、品質保証に不十分な場合もある

考えれば当たり前ですが、勘違いしやすいところですね。

このあと、アジャイル開発で失敗するパターンに触れられ、誤った知識、経験不足、無意味な指標(ソース行数)、的を射ない基準などをあげられ、経験のある弊社が支援しますとのこと。うまい！話の展開が抜群でした。

アジャイル開発の生産性の高さを考える

ソフトウェアをアジャイルで開発すると生産性が高い、と言われるのはなぜでしょう。普通に考えると、

• 手戻りの減少(継続的インテグレーション、小規模リリース、オンサイト顧客)
• 信頼性向上(ペアプログラミング・テストファースト)
• 保守性の向上(シンプルデザイン、リファクタリング、コーディング標準)
• 知識や作業の共有・時間軽減による生産性向上(オンサイト顧客、メタファ、コード共有、40時間)
• コミットメントによるやる気(計画ゲーム)

といったところなのでしょうか(カッコ内はXPのプラクティス。最近はWikipediaにあるように体系的に整理されたようですが、ObjectClubの定義に合わせました)。しかし、最近はYAGNIによる2割8割の効果が最も大きいような気がしています。

2割8割と言うのは、パレートの法則から来ているものです。パレートは多く(8割)の問題が、一部(2割)の原因によるものであるとしていますが、ソフトウェア機能のほとんど(8割)が少ない工数(2割)で開発できるが、残り(2割)に多くの工数(8割)がかかると言うものです。

アジャイルソフトウェア開発では、開発に優先順位をつけて段階的に開発していきます(
計画ゲーム、継続的インテグレーション、小規模リリース)。そこではYAGNIと言われる今必要でないものは後回しにする思想のもと、保守の容易な構造で開発されます(シンプルデザイン)。

難しい2割の機能が全て後回しになるわけではありませんが、必須であるかどうかわからない難しい機能は後回しになり、場合によっては開発されないこともあるでしょう。これが、決定を遅らせるというリーン開発の実践になり、生産性を高めているのではないでしょうか。

テストのパラダイム

SEA関西プロセス分科会の勉強会で紹介したリー・コープランド著「はじめて学ぶソフトウェアのテスト技法」のセクションⅢに「テストのパラダイム」の概要を説明します。

パラダイムは概念をモデル化したようなもので、「ルールと規範であり、境界を明確にし、成功するために、境界内でどう行動すればよいかを教えてくれるもの」です。情報の伝達や、教育、議論する際に役立ちますが、「いわば心理的フィルターなので、適合しないデータはふるい落とされる」というマイナス面もあります。

この本では、テストのパラダイムとしてスクリプトテストと探索的テストが取り上げられています。スクリプトテストは「要件を順番どおりに検証する」もので、いわゆるウォーターフォール型の開発で、通常行われている方法です。計画に従って、試験項目書などをあらかじめ作成し、それに基づいて試験を実施する方法で、IEEE829では8つのドキュメントが定義されているようです。

探索的テストは、テスト担当者が製品について学習(探索)しながら、テストの設計と実行を同時並行で行うものです。いい加減に行うものではなく、熟練したテスト担当者が「システムの適切な振る舞いについての仮説(メンタルモデル)」を作りながらテストするものです。「自由形式の探索的テスト」のほか、テスト担当者の方向付けのために「チャーター(指示書)」を用意することもあるようです。

それぞれ良いところがあって、スクリプトテストは、「再現性、客観性、監査性が重要なときに利用できる」ものなので、仕事をフェーズに分割できるほか、網羅的な試験が可能で、文書化により、理解や評価、管理などが可能になります。また、「最終段階では、テストケースが要件定義書を補える」と言う特徴もあります。その反面、システム要件の品質に依存し、柔軟性にかけ、試験の実施は「こなし仕事」になりがちなのでテストスキルを低下させるというマイナス面が指摘されています。

一方、探索的テストは、テストケースが事前に予測できず、直前のテスト結果にしたがって選択する必要があるときに有利です。たとえば、開発初期の段階でのパフォーマンスのベンチマークテストや、プロトタイプのテストなど開発の初期段階や、テストの終盤になり、試験項目がなくなったときなどに有効です。また、見つかった問題をさらに追求し、欠陥の規模、範囲、バリエーションなど十分に探索してフィードバックできることも利点です。しかし、「チャーター(指示書)」を用意すれば、テスト担当者にテスト対象や欠陥の種類などを方向付けられるものの、欠陥を予防する力は持っていませんし、わかりきった試験には向きません。また、ルールが定められているなら、それに従わねばならないので補完的な技法としてしか使えません。

この本では、テスト計画を古典的計画から適応型計画へ変更すべきだとしています。そして、計画の発見的な策定法として、以下のようにすべしと述べています。

• (利用可能な時間とリソースに基づいて)計画できるときに
• (利用可能な知識に基づいて)計画できるところまで計画するが
• 計画が可能になる前にはそれを行わない

そして、「目の前の問題に対し、意味のあることなら何でもしよう」と両者をうまく組み合わせて使うことをすすめています。

この構成と内容が何かに似ていると思ったのですが、そう、あのベーム先生の「アジャイルと規律」にそっくりです。あの本もパラダイムと読んでも良いような二つの開発方法の特徴を述べ、実際の現場にどのように適応させるかを書いています。「アジャイルと規律」はプロジェクトの分析方法まで踏み込んでいる点が優れていますが、「はじめて学ぶソフトウェアのテスト技法」は、テスト計画の説明であるべき姿を述べている点が優れています。

このテスト計画の説明ではアメリカ海兵隊の"Planning"という文書の「計画する際に注意すべき落とし穴」について触れています。

• あまり遠い将来まで事態を予想しようとすること
• あまりに詳細まで計画すること
• 計画の手法を制度化してしまい、計画のプロセスも計画書も固定して変えられないという硬直化した思考に陥ること
• 計画を、問題に対する変更不可能な唯一の解決策だと思い込んでしまうこと
• 計画の欠陥を識別して必要な調整を行うための、フィードバック機構の必要性を無視すること

この記述、メアリー・ポッペンディーク＆トム・ポッペンディーク「リーンソフトウェア開発」にそっくりです。あの本でも、海兵隊の説明から変化に強い開発方法を述べていますので、その本質は同じと言っても良いでしょう。

この本を読んで感じたことは二つあります。一つは、「アジャイルと規律」にしろ、この本にしろ言っていることは、当たり前のことです。ウォーターフォールに向かないところは切り出してプロトタイピングするなど、すでに似たようなことは皆さんも工夫して実施されているでしょう。しかし、それを極端な二つのタイプにモデル化することで、その特徴を示し、より効率的な開発の仕方を示していることです。このような本は、好き嫌いが分かれますが、プロジェクト戦略を考える際に役に立つので、わたしは結構好きです。

もう一つは、アジャイルやプロセス改善がすでにブームでなくなり、実践の時代になったと言うことです。世の中のものは、流行りはじめに似て非なるものがでてその違いを理解するのも大変です。そして、徐々に淘汰されて残ったものにも限界が現れる。そして、ようやく実務でどう使うかのバランスの議論が始まり実践の時代になると思います。この本や「アジャイルと規律」はそのような実践の時代の到来を知らせる本だと思いました。

リーンソフトウェア開発～CMM/CMMIの利用～

第8章：使用説明書と保証書では、大企業においては改善プログラムと闘う代わりにそれらを利用するようにすべきと書かれています。CMMとCMMIのところを要約すると

【CMMにあわせて仕事をすること】

• KPAで問題を発生させていた要因をアジャイル手法は解決する(レベル3以上で認識できる)
• CMMは現在の手法が既知の失敗パターンを解決するかを評価するだけ

【CMMIには用心すること】

• 不運にも、CMMIはソフトウェア開発の領域を超えた多くの領域を網羅するように設計されている
• 10年間の試みの結果世界一の兵站になったが、リーン思考を30の原則や方針として再挑戦している
• リーン原則を軍事調達システムのプラクティスに取り込むことは、気が遠くなるような作業になった
• しかし、その努力をたどることで、リーン原則を採用する確固たる理由が見つけられるだろう

と書かれています(このほかにもシックスシグマを利用すること、PMIには注意することが書かれています)。CMMには好意的ですが、CMMIにはかなり否定的な書き方です。リーン開発の1番目のツールは「ムダを認識する」で、CMMIはムダに大きくなったと言いたげです。CMMIはうまく参照するものだと思うのですが、必要なところを抜き出す努力がまず無駄ということでしょうか。

ちなみに、この少し前には、

【ムダの最小化をうまくやること】

• 不要な文書が廃止できないなら、なるべく上位レベルで作成すること
• 計画をリリースレベルで保持すること(この程度はどの道やらなければならない)
• 要約文書を作成すること(普通の人が短時間で理解できるなら、じゃまされないですむかもしれない)
• コーディング完了後に設計要約文書を保守用に作成する(2度手間になるから)

と書かれていて、リーンソフトウェア開発を組織のルールにあわせる工夫が必要なようです。

先日、日本の技術が米国で発達してCMM/CMMIになったような説明を聞きました。リーンも元はトヨタですから、日本発の技術を組み合わせるために、日本人が苦労すると言うのもおかしな話ですね。

＃思いつきで書いてますので、説明の順番がむちゃくちゃですみません。

お気に入りの一言

スタートレック・ヴォイジャーを見ました。トレス中尉からホログラムのエンジニアへの一言、

「栄光を築くのは戦士かもしれないけど、社会を築くのはエンジニアよ」

いい言葉だと思いませんか？

リーンソフトウェア開発～できるだけ速く提供する

「決定をできるだけ遅らせる」とともに、この「できるだけ速く提供する」は重要です。

変化に対応させて手戻りを生じさせないために、コンカレントに広さ優先で、効果的なオプションを残し、最終責任時点まで決定を遅らせて開発することを説明しました。並列処理の効率を上げ、オプションのコストを下げ、最終責任時点をより遅い時期にするのがこのできるだけ遅く提供するです。

できるだけ速くというのはアジャイルすなわち機敏ということで、早い時期という意味ではありません。これを実現するには、前に説明したプルシステムで効率よく開発するとともに、各作業をスムーズに流れさせ、パイプの詰まりを生じさせないようにします。「リーンソフトウェア開発」ではこれを待ち行列理論で説明しています。

待ち行列を効率よくするにはサイクルタイムを短縮する必要があります。それには到着の平準化とサービス時間の平準化が有効です。到着の平準化が有効な例としてテストがあげられています。ウォータフォールプロセスではテストが後工程に集中し、十分なテスターがいないとボトルネックになってしまいます。作業を平準化してより速く提供するには、リリースを分ける、つまりイテレーション(繰り返し)開発が必要になります。到着の平準化はテストのみでなくもっと詳細なプロセスにおいても有効だと思います。

サービス時間の平準化には作業を細かな単位に分割することが有効です。作業時間のばらつきをなくすことで待ち行列は効率よく動かすことができます。これは、対象ソフトウェアで制御できるはずです。オブジェクト指向で推奨されているように、より細かなクラス・メソッドに分割することで、実現できると思います。なお、上流でばらつくときは下流に影響が出るので、ばらつきそうな作業は、なるべく下流にもって行くほうが良いようです。

なお、この待ち行列は人間が処理しますので、ゆとりを持たせなければなりません。作業負荷が高くなると人間が疲弊・故障し、待ち行列は止まってしまいします。XPの様に適切な作業量を守らなければなりません。

(全体にカテゴリーを変えてみました。いずれカテゴリーを独自のものに変えるようにします。)

アジャイルとプルシステム

リーソフトウェア開発におけるプルシステムとは、トヨタ式カイゼンの看板方式のことです。後工程で必要なものを前工程で用意する際に用いられるのが看板で、この看板によって生産を管理します。従来のあらかじめ用意する方法は、無駄が多く、機敏に開発することができません。YAGNI(You Aren't Going to Need It：今必要のあることだけをやれ)を実践するために、タスクカードを用いて管理します。

これは、計画の線表を後ろから引くことに似ています。前から順に線を引くと完成できないことでも、後ろから線を引くと各作業間の制約が見えてきて、並列化するなど効率的な計画を立てることができます。最小限のことに限定して、後ろから計画する。それがYAGNIとプルシステムです。

シンプルルール

シンプルルールは自律的な組織運営を可能にします。「リーンソフトウェア開発」ではシロアリのシンプルルールの例と、それを応用したネットワークルーティングなどの例を示して、以下の特徴を挙げています。

• 柔軟性：集団が変化する環境にすばやく順応
• ロバスト性：個体が失敗しても集団はタスクを実行できる
• 自己組織性：集団に対する指揮やトップダウン管理が少なくてすむ

シンプルなルールを決めておくことで、狭い範囲で物事を決めてしまう深さ優先でなく、システム全体を考慮しながら広さ優先の意思決定が可能になり、コンカレント開発を支援します。また、一般により良い決定である直感的な意思決定ができるようになります。

リーンソフトウェア開発 - 決定をできるだけ遅らせる

アジャイルソフトウェア開発はどこが優れているか？なかなか理解できませんでした。これまでの理解では、無駄なドキュメントを書かない、リファクタリングで変更容易性を維持する。コードの共有とペアプログラミングでコミュニケーションを向上させる、などで、概念的にはわかるものの、経験の不足している私には、なにか欠けているような気がしていました。

リーンソフトウェア開発のなかで、まずショッキングだったのは「決定をできるだけ遅らせる」という説明でした。この基本的はコンカレント開発です。従来のようにシーケンシャルに開発すると、まだ決定すべきでない変更の可能性のあることも暫定的な決定が必要とされ、生じるべくして生じた変更の対応のために、ドキュメントの変更、関係者への周知、プログラムの変更、レビュー、テスト＆デバッグといった余計な作業が生じていました。

リーンソフトウェア開発は、変更の生じそうことはそれ以上に決定をの最終責任時点まで決定まで決定しません。また、開発上、何らかの決定が必要なときには必要なオプションを保持します。このような方法で全体をコンカレント(平行)に開発します。コンカレント開発は容易でなく、また、オプションを保持することはコストがかかります。しかし、よく考えて計画することで、変更によって生じるリスクを低減するのです。

また、コンカレントに開発する場合は、開発者に自律的な行動が必要とされます。この方法は、次回に説明します。

５つの重要要因

アジャイルと規律によると、プロジェクトがアジャイルと計画駆動のどちらのホームグランドに近いかは5つの重要要因で判断できるます。アジャイルのホームグラウンドは
以下のように要に定義されています。

人：手続き的な作業が可能な人は０％、手法を改定カスタマイズ可能な人は35%
　　=>希少な熟練者が十分な割合でプロジェクト期間を通じて必要である．
　　　　手法に慣れていない人を使うリスクは高い
変化の度合い：1ヶ月あたりの要求変更の割合が50%程度
　　=>変化の度合いが非常に高い環境では設計をシンプルにして
　　　　継続的にリファクタリングするとうまくいくが，きわめて安定した
　　　　環境では再設計のコストが高くつく可能性がある
文化：カオスで反映する割合が90%
　　=>高い自由度を持つことによって，快適で権限が与えられている
　　　　と感じる文化で反映する(カオスにおける反映)
規模：小規模（典型的な場合3人月）
　　=>小規模な製品やチーム向け．暗黙知に依存しているため
　　　　規模を拡大することは困難である
重要度：
　　=>安全性が非常に重視される製品への適用事例はない．
　　　設計がシンプルで文書が少ないことによる困難が予想される

リーンソフトウエア開発

SEA関西SPINの勉強会に行ってきました。
皆さんとお話していて思ったのは、視点と対象読者が面白いと言うことです。

これまで、いろいろなアジャイル本がありましたが、この本は

• 既存の技術からアジャイルの説明を試みている
• オブジェクト指向未経験者をターゲットとしている

と言う点です。上は、前に書いた良い点ですが、下は要注意です。計画駆動の経験がないと、問題点がピンと来ないようです。まあ、アジャイルをやっているなら、余計な説明本かもしれませんが、、、

アジャイル開発を理解するには

アジャイルはオブジェクト指向プログラマの開発スタイルから発達したものです。このため、アジャイルの良さを宣伝する人の多くはオブジェクト指向が当たり前に感じている人が多いと思います。このような人たちはオブジェクト指向の、適した対象、熟知した開発者、設計手法、コーディングスタイルなどが前提であることを述べずに、アジャイルの有意な点を述べますので、オブジェクト指向が身にしみていない人間から見ると、ベーム先生の言う純粋主義者に見えたり、宗教的にさえ感じてしまいます。オブジェクト指向の設計やプログラミングを思い浮かべながら、理解しようとすることがアジャイルの理解につながるのではないでしょうか？
(このブログでは、「リーンソフトウェア開発」の紹介でオブジェクト指向との関連付けを行う予定です）

純粋主義者の解釈

今日はベーム先生の「アジャイルと規律」のお話をします。
この本はサブタイトルに「ソフトウェア開発を成功させる2つの鍵のバランス」とあるように計画駆動型開発(とりあえず従来型のウォータフォールをイメージしてください)とアジャイル開発に対し、両者のホームグラウンドと長所短所を説明し、どのように俊敏性と規律のバランスをとるかを説明しています。
この前半部分に「純粋主義者の解釈」として以下のようなことが書かれています。

• XPの一部を少しずつ採用して始めようと考えないでください．XPの部品は精巧なスイス時計のように調和しているからです
• アジャイル手法の利点は，既存のものから選択して適用することも，自分で新しく創造して適用することも可能なことにあります。

• SW-CMMレベル3に100パーセント準拠していなければ入札できません
• CMMIをひととおり解釈していれば，自分が一番良いと考える順序で自分のプロセスを改善することができます

こんな議論を聞いたことはありませんか？
たしかに手法の普及には宗教的な盲信に聞こえる断言も有効ではあります。しかし、私のように魅力を感じるものの、どうもうまくいきそうにないような気がする場合、多分、それはうまく行かないと思います。まあ、問題がないときは大丈夫なのでしょうけど、何か問題が生じたとき、あるいは、問題の兆候に気づいたとき、対応できなくなってしまいます。
このようなことを考えていた時に川端さんと小林さんからソフトウェアシンポジウムに論文を共著共著で出すお話があり、上記の観点を入れさせていただいた論文が「効果的なXPの導入を目的としたプラクティス間の相互作用の分析(PDF )」です。

空想的アジャイル

いわゆるウォーターフォールモデル型できちんと管理していると、大規模なソフトウェアを、安定して、秩序正しく開発することができます。仕事そのものは大変であっても、開発の技術的な難しさは早い段階でその多くが解決され、定められた計画にしたがって開発を進めれば、開発後の達成感を感じることができます。しかし、そこでの目標は管理目標の達成であり、知らず知らずのうちにQA(品質保証)や管理者の顔色を見ることが仕事になっています。なにか違う。ソフトウェア開発の目標はもっと違うはずだ。管理されるために作業をするのでなく、もっと効率よく開発できるはずだ。そういった疑問が始まりでした。

確かに仕様が比較的明確で、規模や信頼性のばらつきがある場合にウォーターフォールモデル型開発は非常に有効です。しかし、開発対象の自由度が増して開発が難しくなるにつれ、小規模なプロジェクトほど管理ができなくなってきました。いつしか最適な開発方法を探すようになっていました。

やがて、XPをはじめとするアジャイルソフトウェア開発が注目されるようになり、これならばと思うインスピレーションを感じました。しかし、いろいろな本や雑誌を読んで見ましたが、メタファ(比喩)が多く、アジャイル的な開発経験のない者にとっては、わかりやすい内容ではありませんでした。また、セミナー参加するもベーム著「アジャイルと規律」でいう原理主義的な話が多く、求めている最適な開発とは少し違うようでした。

このような混乱を整理してくれた本が、「アジャイルと規律」でした。

(アジャイルと規律、リーンソフトウェア開発、テスト駆動開発などを中心に話を展開していきます。次回はアジャイルと規律からお話しする予定です)