[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] BTSによるコミュニケーションの効率化

BTS(Bug Tracking Tool)は、その名のとおり障害を管理するツールですが、その効果を考えるとコミュニケーションツールと言えるほど、プロジェクトのコミュニケーションを効率化します。

BTSを用いると、どのような状況にあるかを一覧で確認できるのは紙やエクセルで管理しているのと同じです。大きく異なるのは、メールやRSSで最新情報が通知できる点です。

まず、エクセルで管理している場合を考えましょう。大体こんな感じでしょうか？

1) 障害を発見する
2) 障害票を作成する
3) 上司に報告する
4) 担当者に連絡される
5) 欠陥が除去される
6) 障害票に追記される
7) 再確認
8) 完了

一連の流れにどのくらいかかっているでしょうか。仮に３の上司への報告が朝会などだと1日や2日はかかりそうですね。特に別グループの不具合だと調整に時間がかかり、その不具合に関係するテストは中断して、別の作業をしないといけないでしょうね。

実は現在私が管理しているプロジェクトでは、同じことが置きかねない状況でした。少人数の2つのグループに分かれて作業をしていたのですが、席の配置の関係でどうもコミュニケーションが悪い。見ているとメンバー間のコミュニケーションがIP Messenger中心で、グループでもプロジェクトでもなく、個人間で情報共有が行われていました。仲が悪くはないのですが、全員の一体感がない状況でした。

そこで、開発者全員のメーリングリスト(ML)を作成して、共有すべき情報はMLに流すようにしました。少しはコミュニケーションが改善したようですが、グループ間の調整になると、グループ長であるサブリーダを介して行われていました。

そして、いよいよシステムテストが迫ってきました。これまでの類似プロジェクトでは、エクセルで障害管理され、ファイル共有されていました。でも、上記のような流れで作業すると他グループの不具合の解決に、1日以上かかる危険性がある。これは危険です。

もう悩むことはありません。社内でtrac環境を支援してくれていましたので、それを使いました。ある程度はメール文化がありましたので、どんな障害でも強制的に全員に配布するようにしました。

効果は突然現れました。それは、ある障害が別グループの問題で発生したときのことです。私が障害通知のメールを見たときは、上記の1から4までに相当する作業が完了し、グループ内で打ち合わせがすでに行われていました。そして、障害通知から20分もしない間に問題は解決され、障害対応は完了しました。

簡単な設定の問題でしたが、この問題が解決しないとシステムテストが継続できなくなり、グループミーティングを経て、作業の入れ替えをする必要がありました。たとえ10分の打ち合わせであっても人数分の工数がかかります。2つのグループの打ち合わせ、サブリーダ2人の打ち合わせ、それが早くて半日、下手をすると2日欠けて行われるのです。考えるだけで恐ろしくなります。エクセルにしなくて本当に良かったと思いました。

<')))><

[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)

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

必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-

XP祭り関西2009でもっとも興味深かったのはチケット駆動開発(TiDD)です。関連する発表としては中西さんの「ゼロ機能リリースのもうひとつの側面」とあきぴーさんの「チケットファーストでアジャイル開発！」がありました。

中西さんの発表はサブタイトルが「ワーキングスタイルを変える開発基盤をまず構築しよう」ということで、開発を始める際に機能のない(ゼロ機能)ものをリリースできるようにビルド環境を整えるという「ゼロ機能リリース」で、どのような環境を整えれば良いかというお話でした。

具体的には

1. Tracなどのチケットを用いて、要求から発生するタスクや、バグの管理をする
2. 構成管理ツールでバージョン管理する
3. ビルドを自動化する

の3点でした。

まず、1.はチケット駆動開発をしようという意味で、チケットファーストにすることで

• 無駄が排除できる
• コミュニケーションプロセスが改善できる
• 成果物による進捗管理できる
• 問題が早期発見できる(問題の大きさではなく滞留時間で管理できる)

という効果を述べられました。

次に、2.の構成管理については、メインラインの開発からリリース(メンテナンス)ラインのブランチをリリースごとに起こしていくことや、機能追加、バグ修正、コードのクリーンアップなどタスクレベルでコミットすること、を話されました。

最後の3.ビルドの自動化では、システムの要のテストであるスモークテストは日中のビルドで行い、細かな回帰テストはナイトリ・ビルドで行う、また、必要にプライベートシステムビルドを行うとのこと。

Q&Aでは、チケットに関する質問がありました。マイルストーンは3カ月程度、チケットはなるべく小さく2時間単位でも良いが、分類する必要がある。管理者が閉じることができるマスターチケットと、各開発者が閉じられるタスクチケットに分類すれば、分類してレポートできるようになるとのこと。

これらの一連の自動化を見ていると、新しいことなのに当たり前のような、凄く良いアイデアのようなのに「そうしなければならない」という印象を受けました。

それは、あきぴーさんの発表で意味がわかったような気がします。あきぴーさんのサブタイトルは「チケットに分割して統治せよ」で、TiDDの歴史、背景と効果、経験を語られました。この中で、「TiDDはWeb2.0のようなもの」と言われました。古い技術を使って新しいことをするという意味で言われていたのですが、これが実はTiDDをよく表していると思います。

上に書いたように、TiDDはある意味「当たり前のことをしていったら、こうなった」という印象があります。でも、何か新しく、開発の苦しみを和らげてくれそうな魅力を感じます。

その意味を考えているうちに、かつて川端さんにお願いしたソフトウェアシンポジウムのチュートリアルを思い出しました。このセミナーはXP入門ということでお願いしたのですが、実際はEclipseの実習が中心でした。これは、少人数でソフトウェア開発に向き合うと、ツールを中心に効率化を図るしかないということを意味しているのだと思います。

TiDD(チケット駆動開発)は、その背景の思想から生まれたものではなく、ツールを用いながらプロセスを改善していったら、必然的にそうなったものだと思います。かつての方法論が、背景の思想を元にツールを開発したために実践する際にやりにくい点が生じたのに対し、実践している中で生まれた方法論は、その体系をきれいにまとめられれば従来にない力を発揮できると思います。

今後、そのあたりをまとめたいと思いました。

プロジェクト型でない開発 - XP祭り関西2009 その２-

XP祭り関西2009の2番手は土屋さんの「マネジメントから自律へ」でした。

日ごろの開発はプロジェクトとしてやっているが、実はプロジェクトの前提にあっていない、とのこと。確かに、ゴールも明確にではないし、人もゴールに合わせて集めるのではなく、そこにいる人でやっています。そのために、毎回ドメイン知識の学習や、最適解の模索に多くの時間を使っています。

プロジェクトは形式知を元にゴールを目指しますが、プロジェクト型でないので、共通の目標を持つチームが暗黙知で迅速な対応をする方が良い。技術を磨くと言いますが、磨くとは削ることで、それは無駄をなくすこと。アジャイルのライトウェイトとも一致するとのこと。それは、仕事に合わせて人を集めるのでなく、人がいるところに仕事が運ばれてくるようにすることで実現できるようです。

プロセス改善の目的は良い物を早く作ることで、アジャイル開発ではない。PDCAサイクルにアジャイルのプラクティスを取り入れて、短周期で、回せばよいとのこと。アジャイルかウォータフォールかの議論ではなく、実際の問題に合わせて良い物を取り入れることが現実的な改善であると思いました。

ところで、同じ人の所に仕事が来るというモデルですが、これはかなり効果が上がると思います。昔ながらのプロジェクトでは、途中で人をどんどん追加して、製造が終わるとどんどん減らします。これは、大きな負担だと思います。人が入るたびに説明をするのも大変ですし、担当に合わせて最低限の説明をしているつもりが不十分だったり、議論の度に背景の説明が必要になります。せめて、工程単位、できれば早い時期から同じ人間で開発できれば、非常に効率よく開発できると思います。

アジャイル開発は予算とスコープのトレードオフ - XP祭り関西2009 その１-

ことしのXP祭り関西は、塚口で行われました。キーノートは平鍋さんでAgile2008の報告でした。

まずはAgile UXの話題から。UXはuser experienceの意味で、UIよりも上の概念らしい。ユーザからフィードバックをもらわないと良いユーザインタフェースはできない、とのこと。当たり前といえば当たり前なんですが、アジャイラーからではなくUIの分野で開発法を探したらアジャイルにぶつかったとのこと。会場でUXが実践されている様子が色々と紹介されていました(その一部が平鍋さんの記事に紹介されています)。

また、トヨタ式のカンバンについてもWIP(Work in Process)の観点で説明されていました。WIPにある(つまり開発中の)カンバンの数を制限することで、工程中の物を少なくできるとのこと。これは、いわゆる後工程の引き取り、すなわち使われるものだけを作るということで、アジャイルでいうところのYAGNI(You Aren't Going to Need It )と共通する。さらに鎖のメタファで、後ろから押すと途中で溜まってしまうが、前から引っ張るとスムーズにいくと言われていました。なるほど。

あとは、Dear XPを外人さんと共に英語で歌ったことの報告と、木下さんの飛び入り発表がありました。木下さんは発表だけのつもりだったのに論文を書くことになって急遽書かれたらしい。やりますね。木下さんの発表はいつもながら面白かったです(関西人への期待値が上がりすぎるのではないかとの若干の心配も感じました:-)。木下さんのスライドはslideshareで見ることができます。

色々と興味深い発表でしたが、最も印象深かったのはQ&Aでした。一つ目は日本と海外との違いです。欧米では本などで知っている人が多く、採用は25％ぐらい。ビジネスと作る人との距離が近く、同じリスクをとる、また、コンサルタントも多い。一方、日本は40-50%ぐらいはアジャイルを知っているが、5-10%しか採用しない。これは、ビジネスと作る人の距離が離れているので、ウォーターフォールの方が発注しやすいからだそうです。

二つ目の質問は発表内容と関係なく、たぶん平鍋さんだからこそ出た質問だと思うのですが、アジャイルがうまくいくイメージがわかないので教えてほしい、とのこと。アジャイルは顧客とゴールを一緒に持ち、それぞれの利益の綱引きでなく、運命共同体になっている。作っても使われないものや、うまくいかないものより、コスト削減や新ビジネスなど、うまくいくものを作る。まず、予算と期限を決めて、予算とスコープとのトレードオフで決定していく、との回答でした。

なるほど、と思いました。従来の方法では、スコープが先にあり、無理な予算でも一度決めたら変更せず、ずるずるとリリースが遅れるのでしょうね。

技術者に必要な「なぜ」

SEA-SPIN 滋賀Workshopのポジションペーパーです。
(締め切りが9/5まで延長されましたので、まだ申し込めます)

技術者に必要な「なぜ」

１．概要

ソフトウェア開発には様々なルールがある。多くの組織ではルールを決めることで、ソフトウェアの品質を保とうとするのである。確かにルールを守っていればそれなりの品質になるのであるが、そこに落とし穴がある。ルールを守ることだけに注力し、それ以外のことがおろそかになるからである。

本当に必要なものはルールではなく、ルールが守ろうとしているもの、「なぜ」ルールが必要であるかという理由ではないだろうか？ルールに従うことを目指した開発は開発者の基礎力を高めないので応用が利かないが、「なぜ」を理解した開発は応用が利くからである。

２．ルール文化

ルールが守られなければ、ルールを定めた意味がない。そこで、レビューなどにチェック機構が取り入れられることになる。人は自然と良いものを作るのではなく、ルールを守ることに注力してしまう。しかし、もしルールに漏れがあれば、ルールしか見ていない開発者は、大きな問題を起こすことになる。そこで、ルールはさらに肥大化し続け、人はよりルールを守ることに多くの力を注いでしまう。

そんな文化に育った技術者は応用が利かない。ルールを守ることが仕事だったので、ルールを守らなくて良いと言われた瞬間に、何をして良いかわからなくなる。たとえば、より軽量なプロセスを必要とされたとき、それまでの経験は無駄になってしまう。

３．技術者に必要な基礎力

一方、「なぜ」を知っている技術者は応用が利く、言語やプロセスが変わっても、ふさわしい開発ができる。過去の経験を生かして、必要なことを考えて開発が実践できるのである。新たに経験した問題に対してもその原因を追及することができる。技術者に必要な基礎力とは、「なぜ」を理解していることではないだろうか？

４．ワークショップに期待すること

ワークショップでは、ソフトウェア開発で必要とされる「なぜ」にはどのようなものがあるか、「なぜ」を習得するにはどうすればよいか、ということを議論したい。

以上

安全側に倒す - エスカレーター事故に思う -

システムを設計する際の重要な概念に「安全側に倒す」というのがあります。システムに予想外の事象が発生しても、システムダウンなど重大な問題につながらないようにすることです。

簡単に言ってしまうとエラー系の処理をきちんと設計することですが、そもそも実現しなければいけないことは何かをしっかり考えて抜けがないように、と言うところがポイントではないかと思います。卑近な例で言うと、ループ処理ならきちんとループが終了するように、演算誤差を考慮してループカウンタの判定を＝でなく≦で判定するなどもそれに当たるでしょう。

東京ビッグサイトのエスカレーター事故(リンク先はスラッシュドット・ジャパン)の報道を見ていると、何か釈然としません。基準を満たした設計がされていて、基準以上の人が乗ったので使い方が悪いとのこと。システム設計としては、(1)(逆走など)人命にかかわるような問題が生じないようにブレーキがあった、(2)重量オーバーを検知してブレーキをかける仕組みがあった、という二つの仕組みがあったようです。そして、重量オーバーを検知してブレーキをかけたが、耐えきれずに逆走した。

変ですよね。なんか、メモリ不足を事前に検知する仕組みがあってワーニング(警告)をデータベースに出力できるようになっていたが、ワーニングの出力によってメモリが致命的に不足してシステムがダウンしたような感じです。こんなシステムを作ったらお客さんから怒られますよね「そんな負荷の高い出力は要らないからメモリーを食わないワーニング出力にしろ！」と。笑うに笑えません。そもそもメモリー不足とはどのような状況で、必要なのはどのようなことかを考えて、さらにメモリーを消費しないように設計しないといけません。

このように考えると、エスカレータの設計は間違いなくおかしいですよね。少なくとも上向きに動いていたのだから、きちんと止められないなら警告音を出しでそのまま動けと思ってしまいます。もちろん、ブレーキが耐えられる重量で、停止すればよいのですけどね)。

こんな間の抜けた設計なのに社会的責任を問われないなんて、ある意味うらやましくもあります。ソフトウェアの仕様を決める際に何でも入れすぎなのがいけないのかもしれません。でも、「XXレコードを超える検索はシステムがダウンします」なんて仕様は書けません。ソフトウェアの柔軟性が自らの首を絞めているのでしょうね。

結局、システムを設計するなら、機能を実現するだけでなく、予想外の事象が発生してもシステムが危機的な状況にならないように、安全側に倒す設計をして、身を守るしかないのでしょう。

棚卸をしていびつな人になる - まつもとさん@SS2008 -

6月に行われたソフトウェアシンポジウムのキーノートスピーチの一人目は、Rubyのまつもとゆきひろさんによる「技術者の幸せとは何か？－エンジニアサバイバルガイドー」という講演でした。

Rybyのテクニカルな話がない、なんとも贅沢なこの講演は、３K(きつい、帰れない、給料が安い)とか７K(さらに、規則がきびしい、休暇がとれない、化粧がのらない、結婚できない)などと幸せそうに見えない日本のエンジニアのために、日本で一番幸せそうに見えるまつもとさんの経験をもとに話していただこう！という企画のだそうです。

ものづくり軽視や理系軽視、そしてプログラミング軽視によってこんなことになってしまいましたが、嘆いていてもはじまりません。社会は変えられないが、自分の境遇は変えられます。すでに右肩上がりの時代は終焉し、みんなが幸せになれないほどのパイはありません。激化する生存競争の中、受け身ではなく戦略を持って行動しなければ幸福になれません。

そんなお話の後、マクドナルドでアルバイトをされていたころに経験された「インベントリー」（倉庫の棚卸）を紹介されました。大雑把にあやしくまとめてしまうと「敵を知り、己を知れば百戦危うからず」のような内容です。自分の利点・欠点、変えられるもの・変えられないものをはっきりさせること。自分の幸せはなにかを考え、理不尽なことはの拒否する。自分のことは自分で決める。幸せと無関係なものは重要視しない。ということでした。

棚卸ができたなら、幸せをどう手に入れるかが課題となります。現実を考えると、そうはいってもと考えがちですが、できないと思うからできないのです。たしかに精神論ですが、挑戦なしに結果はありません。目標を決め、戦略を考え、行動しよう！(私の文章だとあやしくなってますね。すみません)

目標というのは、己を知ること、何を目指し、何を目指さないかですが、流動的で構いません。己を知ればぶれないですむし、確信や自信につながります。また、現実との妥協点も見出せ、Win-Winの関係が築けます。

戦略といっても、みんなが成功するわけではないし、運も必要です。しかし、確率を高めることはできます。代替可能でない自分、世界に一人しかいない自分をめざし、差別化をします（ただし、マネジメントの観点ではシングルポイントフェイリュアなので切り捨てられる危険もあります)。

結局、差別化戦略とは「いびつ」になることです。良い点は伸ばし、悪い点を無視する。そんな孫子の兵法(リンク先はWikipedia)のような戦略です。もちろん、能力も必要で、継続する努力も必要です。情報収集や情報整理の能力、コミュニケーション力、機嫌が悪くならないことや、英語力もある程度は必要です。しかし、完全である必要はありません。

当然の権利を要求する自己主張とともに、信頼関係の形成も大切です。ある分野でその組織の最後の頼れる一人として認めてもらうために、問題の解決や調査、たよれる人脈を持つということも大切です。

最後に、4つの言葉でにまとめられました。「差別化重要」、「機嫌重要」、「継続重要」、「行動重要」。

お話しのあとで、「もともとそのような戦略で行動されたか」という質問に対して「私自身はアドホックにやってきました。過去を振り返って戦略としてまとめました。努力といっても、時間はかけたものの、苦痛は感じていません」と正直に言われたのが印象的でした。

発表の概要はこんな感じでした。いびつに生きると言うのは、「チーズはどこへ消えた」とか聖書の「タラントンのたとえ」を彷彿させましたし、実存主義(リンク先はWikipedia)も思い浮かびました。しかし、なんといってもfj.oopsでのオブジェクトアイデンティティの議論(リンク先はまつもとさんの日記：こんな感じの議論がされていました)を思い出しました。

すでに十分いびつな私は、いびつなままにどうやって生きるかを考える必要がありそうです。そこでは、やっぱり棚卸が有効な気がします。講演の中では、自分の価値観や自分の利点を元に差別化を行うと言われていましたが、Win-Winの関係とも言われていました。自分が幸せと思える範囲内なら、周りにあわせることも大事なのでしょうね。

そして、もっとも大切なのは「機嫌重要」なのでしょう。人とのコミュニケーションが必要な仕事なので、怒ってやるよりも喜んでやる方が良いに決まっています。講演の中でも「機嫌が悪いと『情けは人のためならず』の反対になる、ネガティブ・ループバックに陥る」「周囲に不利益であり、自分に不利益になる」と言われていました。やっぱり、仕事は楽しくやりたいですね。

(「情けは人のためならず」というのは「情けは人のためならず、巡り巡って我のため」が全文です。人にやさしくすると、いつか自分に返ってくるということです。)

SEA-SPIN 滋賀ワークショップ

「ソフトウェア技術者の基礎力」というテーマでワークショップを企画しました。

一泊二日という短期間ですが、基調講演にSmalltalkで有名な青木先生、CMMI入門インストラクタでPSP/TSPインストラクタの秋山先生をお招きして、じっくりと議論したいと思います。ご興味のある方は、ぜひご参加ください。

(SPAM対策で@を＠に変換していますご注意ください)
---------------------------------------------------------------------

　　　　　　～～～　SEA-SPIN 滋賀ワークショップ案内　～～～

１．テーマ：ソフトウェア技術者の基礎力

２．企画運営：　ソフトウェア技術者協会 関西支部 プロセス分科会
　　　　　　　　http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/

３．日程：　2008年9月12日(金)～13日(土)
４．場所：　ウェルサンピア滋賀（滋賀厚生年金休暇センター）
　　　　　　住所：〒523-0806
　　　　　　滋賀県近江八幡市北之庄町615
　　　　　　電話：0748-32-3221 FAX：0748-32-5972

----------------------------------------------------------------------
５．開催の趣旨：

この度，SEA 関西プロセス分科会では，上記のテーマによる１泊２日のワーク
ショップを企画しました．日頃の活動は２時間程度の講演会や勉強会中心で，
なかなか皆さんとじっくり腰を据えた議論・討論・よもやま話ができる機会が
ありませんでした．そこで，泊りがけで一度ゆっくり話あってみたい，という
のが，開催の動機です．

さてそのテーマですが，何と言ったらいいのでしょうか，ちょっと漠然として
いて説明しにくいのですが，先日の世話人会での次のような会話がきっかけで
した．

　　先日，自宅の引越しをしたんですけど，引越し業者の中にネジのとめ方を
　　知らない人がいてちょっとびっくりしました．
　　普通，四角い蓋なんかをネジ留めするときは，まず対角線の順番で軽く全
　　部を仮止めしてからキチンと締めていくものだとおもうんですが，いきな
　　り端からきつく締めていく人がいた．これくらいは常識かと思っていたん
　　ですが，最近は知らない人が多いんでしょうか．

この「ネジ止めのコツ」って，ソフトウェア開発にも同じような話があるので
はないでしょうか？　すでにそれを身につけている人にとっては，特に意識も
しないような当たり前のことで，わざわざ「ノウハウ」とか「スキル」と呼ぶ
程でもないのですが，実は基本的に大事なことで，それがきちんとできている
かどうかが，プロとして仕事をして行く上で意外に大切だというようなこと．
書物やセミナーで勉強するのではなく，仕事の中で受け継ぎ，身につけて行く
ようなことがらです．

また，別の見方をすると，ネジ止めのような一見単純な作業の中でも，１本の
ネジに集中してしまうのではなく，一段高い視点に立って，全体の位置関係や
バランスを見ていく姿勢が大切だともいえます．

自らの仕事の遂行やプロジェクトの運営，キャリア設計などにさいしても，こ
の「一段高い視点から見る」姿勢が身についていることは大切であり，それを
無意識の習慣になるまで身に染み込ませておくべきではないでしょうか．

今回のワークショップでは，この「ソフトウェア開発に従事する者として，基
本的なこととしてに身につけておくべきこと」とは何だろうか，また，一段高
い視点に立って仕事をするとはどういうことなのか，といったことについて，
皆さんと意見交換や討論を行っていきたいと考えています．

もちろん，材料としてはこのネジ止めの例のような，具体的な手仕事に関する
ものに限らず，設計に関すること，テストに関すること，成果物管理に関する
こと，プロジェクト管理に関することなど，仕事の性格によっていろいろある
でしょうし，組織や分野によっても違うと思います．しかし，そうしたさまざ
まな立場や環境にもとづく経験を出しあうことで，お互いに新たな「気付き」
につながることを期待しています．

今回は，以上のような討論テーマに関連して，次のお２人の方に基調講演をお
願いしました．

京都産業大学の青木淳先生には，Smalltalkを駆使しての豊富なソフトウェア
開発経験と広い知見をベースに，プログラマ（あえて「プログラマ」とします
が）が身につけるべきセンス・スキル・知識等について語っていただきます．
また，事例として最近の研究成果の紹介もお願いしました．

PSP (Personal Software Process) やTSP (Team Software Process）に関する
活動で著名な秋山義博先生には，組織のカルチャーチェンジにおける技術者の
悩みや役割について語っていただきます．われわれ自身の仕事のあり方を見直
す上で，大きな刺激を与えていただけるものと期待しています．

皆さんの積極的な参加をお待ちします．

----------------------------------------------------------------------
６．プログラム：

１日め
　　10:30 　受付開始
　　10:45 　開会
　　11:00 　基調講演
　　　　　　テーマ：プログラミングにおける知ることの深層
　　　　　　講師　：青木 淳 先生
　　　　　　　　　　　　京都産業大学 コンピュータ理工学部 教授
　　　　　　　　　　　　株式会社SRA先端技術研究所 非常勤顧問
　　　　　　内容　：
　　　　　　　　可視化（視えるように）する・可聴化（聴けるように）する
　　　　　　　　・可触化（触れるように）するプログラミング活動を介して
　　　　　　　　知り得たことの深層を紹介します．
　　　　　　　　視覚・聴覚・触覚は，文字・音字・点字に対応し，頭の中に
　　　　　　　　言語を作ります．プログラミング言語を用いて日々活動して
　　　　　　　　いるプログラマの頭の中に基底とすべき事柄を述べます．

　　12:30 　昼休み

　　13:30 　ワークショップ：自己紹介・ポジションペーパ発表
　　　　　　（一人5～10分程度）
　　15:30 　休憩
　　16:00 　ワークショップ：グループ討論
　　　　　　傾向別に２～３のグループに分かれて討論．
　　　　　　各グループ毎に内容を発表資料にまとめる．
　　18:00 　討論終了

　　19:00 　夕食および懇談
　　21:00 　解散

２日め
　　 9:00 　基調講演
　　　　　　テーマ：カルチャーチェンジはどのようにおこるか
　　　　　　　　　　-ソフトウエアとエンジニアリングを越えて-
　　　　　　講師　：秋山 義博 先生
　　　　　　　　　　　　九州工業大学　情報通信技術教育センター教授
　　　　　　　　　　　　理学博士
　　　　　　　　　　　　SEI認定PSP/TSPインストラクタ
　　　　　　　　　　　　SEI認定CMMI入門インストラクタ
　　　　　　　　　　　　SEI認定SCAMPI AB&C High Maturityリードアプレイザ
　　　　　　内容　：
　　　　　　　　産業革命，物理学，化学，新しい工学・製造，最近のサービス
　　　　　　　　（GMがよく知られています）などの領域のプロフェッショナル
　　　　　　　　自身が問題に苦悩し悩みどのように解決したか，その「自分の
　　　　　　　　カルチャーチェンジ」を実現したか，また，それを回りに伝え
　　　　　　　　たかについて考えます．
　　　　　　　　（ソフトウエアというもの創りのカルチャーを変える，ハンフ
　　　　　　　　リーのPSP/TSPもそのようなひとつの例）
　　10:30 　休憩
　　10:45 　ワークショップ：グループ討論
　　12:15 　昼食
　　13:15 　ワークショップ：グループ討論
　　14:45 　休憩
　　15:00 　ワークショップ：全体討論
　　　　　　各グループからの発表，全体討論
　　16:15 　閉会
　　16:30 　終了

７．定員：　19名

８．参加費：
　　ワークショップ参加者用に会場（ウェルサンピア滋賀）の部屋を定員分予約
　　しています．ただし，４人１部屋の相部屋となります．
　　参加費は，この宿泊費込みとなります．
　　宿泊先を別途，御自身での手配を希望される方はご相談ください．
　　（seakansai-office2007＠media.osaka-cu.ac.jp までメールでお問い合わせ
　　下さい．）

　　SEA正会員 　　　18,000円
　　SEA賛助会員 　　20,000円
　　一般　　　　　　23,000円

９．申込み方法 (〆切 8/29(金))：
　　下の申込み票に必要事項を記入し，「ソフトウェアの基礎力」についての
　　自分の考えを書いた簡単な Position Statement を添えて，
　　seakansai-office2007＠media.osaka-cu.ac.jp　まで  e-mail でお申込み
　　ください．折り返し受付確認の mail を返信します. 当日会場の受付で
　　お名前を申し出てください．参加費は当日現金でお支払いください．
　　領収書をさしあげます．
　　申込み受付後のキャンセルは原則として認められません．

　　------------------------------------------------------------
　　SEA-SPIN 滋賀Workshop (9/12-13 ＠ ウェルサンピア滋賀)参加申込み

　　氏名：__________________ ふりがな（______________________）
　　所属：__________________________________________________
　　住所：__________________________________________________
　　電話：________________
　　E-mail: _______________
　　領収書宛名: ____________________________________________
　　種別（いずれかにチェック・記入）：
　　　□ ＳＥＡ会員（No: 　　　　　　）
　　　□ ＳＥＡ賛助会員 (会社名: 　　　　　　　　　　　　　　　)
　　　□　一般
　　性別（部屋割りの為）（いずれかにチェック）：
　　　□ 男性　□女性
　　宿泊部屋のタイプ（いずれかにチェック）：
　　　□ 禁煙　□喫煙

　　---- mail to seakansai-office2007＠media.osaka-cu.ac.jp ----

　　*注：賛助会員企業一覧：http://www.sea.jp/sanjo.txt

----------------------------------------------------------------------

ETWEST2008に出ます

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

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

ねじ止めの基本からソフトウェア開発を考える

最近引っ越しをした関係で、家具を少し買い換えました。

通信販売でしたが、組み立てもお願いしていたので様子を見ていると、、、、
ほとんど何も考えていません。説明書を見て、電動ドリルで端から止めるだけです。
もちろん、傷がつかないように毛布をひいたり、丁寧に扱ったりはしているのですが、

1. 仮止めする
2. 対角線にとめていく

という歪みを取りながら組み立てる手順がありません。電動ドライバーが空回りするまで一気にねじ止めするだけです。元々のつくりのせいもあるのでしょう が、出来上がったものも、あっちがずれたり、こっちがずれたり、やっぱりそれなりです。通販の組み立ては運送屋さんがやっているので、まあ、仕方ないかと も思っていました。

しかし、家具やさんで買った商品の組み立ても同じでした。床に傷がつかないようにフェルトを貼ってくれただけで、基本的に端から一気にねじ止めするだけで す。それを見てて、怒りを感じるよりもなぜか悲しくなりました。世の中全体が、基本的なことを忘れてしまい、効率ばかりを考えているような気がしたからで す。

ソフトウェア開発を考えても、同じように効率重視がまかり通っていないでしょか？

私がソフトウェア業界に入ったころは、「安全側に倒す」プログラミングを教えられたものでした。たとえば、if文を書く際にも判定条件をどう描くかによっ て予想外の結果が生まれます。ループの終了条件をある値なら終了と記述していれば計算誤差によって無限ループになる可能性もあります。そこで、ある値未満 (あるいは以下)の間繰り返すように書くことで問題が起きにくくなるのです。このほかにも、コーディングスタイルを統一するとか、処理時間やデッドロック を考慮するとかなど、色々な基本技術がありました。

いろいろな会社の人の話を聞いていると、最近は開発環境が整っているので、新人でも得意なフレームワークなら何万行も書けたりするようです。しかし、本当に大丈夫なのか、プロジェクト全体で品質は保てているのか、他人事ながら心配をしてしまいます。

考えてみると、覚えないといけないことが多すぎるのかもしれません。結局、「教育の問題」などと言われて、ついつい目標に＊だけ＊向かってコードが書かれ ているのが現状でしょうね。最近は売れる本しか出版されないのもこのような状況も後押ししているかもしれません。「ここを見て勉強しろ！」と言えるWeb ページがあれば良いのかもしれませんが、もっと本質的なところで何か忘れているような気がしてなりません。

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

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

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

配布資料(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

見積り手法CoBRAの魅力

見積り手法というとCOCOMOが有名で、大量に集めたデータから統計的に見積もりをするものです。しかし、企業内で実践するにはデータ数をそろえることが大変です。また、すでに公開されているモデル式で見積もるには、パラメータをどう与えるか人間がモデル式に合わせる努力が必要です。

そこで、似たプロジェクトから類推する協調フィルタリング(リンク先はEASEプロジェクト)と言う方法が提案されています。この方式は、データに抜けがあっても見積もることができることもあり、非常に魅力的です。

しかし、そもそも見積もり精度を高めるのは、ソフトウェア開発プロセスを改善するためで、その処理系である開発者の能力を高めたいという気持ちがあります。それは、COCOMOのパラメータを上手に決定できるということや、良いアルゴリズムを入手するということも含まれるのですが、現場の人間としてはなにか寂しいものを感じていました。

先日(といってもかなり前ですが)のSEC設立三周年成果報告会で講演を聞いた見積り手法CoBRAはこの不満を解決するものでした(リンク先はすべてIPA)。

このCoBRAというのはドイツフラウンホーファ協会IESE（実験的ソフトウェア工学研究所）で開発された見積もり法です。私も名前だけは聞いたことがありましたが、人間の経験を生かすことができる見積もり法であるとは、きちんと理解していませんでした。

モデル式は以下のようにあらわされます。

　　工数＝α×規模(1＋∑COi)

この式でCOiと言うのは要因影響分のオーバヘッド分で確率分布で表現されるものです。

COはコストオーバヘッドの略で、式からも分かるように「この要因があればどの程度の比率で作業が増えるか」を表します。「XXなときはYY％ほど工数がオーバする」という経験が式であらわされているのです。講演(リンク先はIPA)によると、この要因は複数のPMによるブレインストーミングで決められるようです。

これはモデル化とプロセス改善のあるべき姿です。モデル化の目的には、予測のほか、人への伝達、議論、教育なども含まれます。CoBRAを使うことで、それぞれのPMがどのように考え、どのように対処したか、それがこのモデル式の議論の中で明確になるでしょう。また、モデルから大きく外れることがあれば、それが頻繁にある要因か、対処が適正に行われたか、ほかに対処法はなかったかなど、多くのコミュニケーションが行われると思います。そして、このようなコミュニケーションは、プロセス改善の目的である組織の能力を高めることになるでしょう。このようにCoBRAは魅力的な見積り手法だと思います。

ことしは、あまり活動できませんでしたが、来年は、こんな観点をまとめて、コミュニケーションツールとしてのメトリクスという観点で、エンピリカルソフトウェア工学の実践の講演をする予定です。

ひたむきであること

今日は同じ会社の有名人Aさんのお話を聞いてきました。内容も面白いし、トークも最高でした。

以前から楽しそうにされている様子がうらやましく、人間関係や仕事の内容に苦しみながら仕事をしている自分とどう違うのだろうと、以前から気になっていました。

今日のお話を聞いているうちに、先日、とある方からうかがった言葉を思い出しました。それは、お寺の掲示板に書かれていたもので、たしかこんな感じでした。

一生懸命なら喜ぶ。中途半端なら不満をいう。さぼっていれば言い訳をする。

いつも楽しそうなAさんはよく働きます。仕事好きというよりは、理想に向かって、ただひたむきに仕事をされます。ときどき愚痴も言われますが、笑いながら夢を語られるのです。

そういえば私も、若いころは良く働きました。昔は楽しかったなどとおじさんのような(というかおじさんそのものの？)言葉を言ったりしますが、昔は楽しいからというよりは、より良くなるように一生懸命でした。だから、身体は大変でも喜びを感じることができたのかもしれません。

色々と不満なことがあっても、なすべきことにひたむきに働くことが大事なのだと思いました。ソフトウェア開発は本来楽しいものなのですから、、、

SEA関西プロセス分科会 - Ruby on Rails について -

SEA関西プロセス分科会の参加者を現在受付中です。
今回は、「Ruby関西」のみなさんにご協力いただき、Ruby on Rails (RoR)を取り上げます。 会場は大阪駅前第2ビルの大阪市立大学の文化交流センターde
す。 土曜日の午後ですので、ぜひ、ご参加ください。

--------------------------------------------------------
～～　第31回　SEA関西プロセス分科会のご案内　～～

テーマ：Ruby on Rails について～JavaからRubyへ

講師　： okkez @ Ruby関西さん
　　　　 cuzic @ Ruby関西さん
　　　　 あきぴー @ SEA関西さん

主催　：ソフトウェア技術者協会 関西支部 プロセス分科会
　　　　　http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/

日時　：2007年08月25日(土) 13:30～16:30

会場　：大阪市立大学文化交流センター
　　　　〒530-0001　大阪市北区梅田1-2-2-600
　　　　大阪駅前第２ビル６階　大セミナー室
　　　　Tel　06-6344-5425　/　Fax　06-6344-5524
　　　　http://www.ado.osaka-cu.ac.jp/BUNKO/
　　　　周辺略地図 　　　　http://www.media.osaka-cu.ac.jp/Toshi/yoteiti.html

内容　：
　　　Javaは約10年前に出現して以来、Webシステム開発の業界標準技術として
　　使われ、進化してきました。しかし、その応用範囲が大規模な基幹システムに
　　広がるにつれ、API の巨大化や実行環境の複雑化により、Javaの開発者に
　　かかる負担も年々大きくなりつつあります。
　　　いっぽう、Javaとは対照的に草の根的なオープンソースソフトウェアの形で
　　着実にユーザー層を広げてきた Ruby の世界に、最近 Ruby on Rails という
　　Web フレームワークが出現し、大きな注目を集めています。その特徴は、現実に
　　稼動する Webアプリケーションが極めて少ない工数で開発できることにあります。
　　その異常な生産性は JavaやPerl、PHPなど他言語の開発者も注目し、これら
　　他言語のWebフレームワークやDBモデリングにも影響を与えています。
　　　このたび、関西で活発に活動しているRuby関西の方を講師にお呼びして、
　　Ruby on Railsのアーキテクチャの概要、実際のデモ、そして、Ruby on Rails
　　がIT技術に何をもたらしたのか、を解説して頂きます。

プログラム：

　　1.　13:30 - 14:00
　　　　JavaによるWebシステム開発の現状（あきぴーさん）

　　2.　14:00 - 15:20
　　　　Ruby on Rails のアーキテクチャ
　　　　Ruby on Rails のデモ
　　　　（以上、okkezさん、cuzicさん）

　　　　15:20 - 15:30 休憩

　　3.　15:30 - 16:30
　　　　RailsがＩＴ技術に影響を与えたもの
　　　　（会場の参加者を巻き込んでのディスカッション）

参加費用：
　　SEA正会員：1,000円，SEA賛助会員：1,000円，
　　Ruby関西メンバー：1,000円（※１）
　　学生：500円，一般：2,000円

　　※１　Ruby関西のメーリングリストに登録されている方。
　　　　　メーリングリストに登録されているメールアドレスで
　　　　　お申し込み下さい。
         なお、学生の方は500円になります。

　　定員　：36名

申込方法：
以下のペ‐ジからお申し込みの受付を行っております。
http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/application.html
### 08/23（木）までにお申し込みください ###

　ご注意）
　・受付は先着順で，定員になり次第〆切とさせていただきます．
　　申込受付後のキャンセルは原則としてお断りします．
　・メール，FAXなどWebページ以外からの申し込みは受け付けて
　　おりません．
　・お申し込みの受付け後，確認メールが自動的に返送されます．
　　確認メールを印刷し，当日受付時に持参ください．
　・申し込み手続きについて不明点などございましたら，下記まで
　　ご連絡ください．
　　seakansai-office2007@media.osaka-cu.ac.jp
　・参加費は当日会場受付にて現金でお支払いください
　 領収書が必要な方は，申し込み時に「領収書要」にチェック
　　してください．

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

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

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

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

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

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

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

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

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

世代の壁を超えるには - SS2007に参加して その２-

ソフトウェアシンポジウム2007のワークショップでメトリクス(定量的データ尺度)の議論をする仲で、開発者がデータ取りに協力してくれないという話題の中で、

「プロでしょ！お金をもらっているのだから、データを取って当たり前」

そんな言葉が聞かれました。なにか納得いきませんでした。私の世代までならいざ知らず、今の若い人が「当たり前」というだけでデータ収集に協力してくれるとは思えません。仮に、協力してもらえたとしても形だけのデータで、データの精度や一貫性は望めません。

故坂本氏は、プロセス改善はWIN-WINが基本で、開発、支援(SEPG)、ユーザがそれぞれにメリットのあるWIN-WIN-WINの関係が必要だと言われましたが、そのような明確な動機付けが必要な気がします。単に「データをとれ」というのではなく、仕事の定義やデータ収集の意味と効果などを、きちんと説明する必要があると思いました。

このような意見の違いはなぜ生まれたのでしょうか？単に世代の違いではないと思います。もちろん、その時に受けた教育や社会情勢といった違いはあるでしょう。でも、それだけではないと思います。

そもそも仕事の内容が変わり、やり方が変わったのだと思っています。私が社会人になったころはC言語の普及が始まったころです。その頃の言語は、容易にすべてのマニュアルを読むことができました。その後、C++、Javaと変わっていく中でライブラリは肥大し、すべてのマニュアルを熟知することは困難になりました。また、１プロセス・１CPUで処理されることも少なくなり、システムも複雑になりました。

10年ほど前に、コロラド大学で認知科学を教えられていたフィッシャー先生が「オンデマンド・ラーニング」と言われていたことが思い出されます。情報の肥大化によって、かつてのように頭の中に情報を詰め込む時代は終わり、情報を選択して記憶するようになったと言われていました。当時としては画期的なお話でしたが、インターネットが普通の時代に社会人になった、今の若い人は当たり前のようにそんなことをしているのではないでしょうか？

今の若い人のように、様々な知識を取捨選択するということは効率的である反面、断片的でもあります。多くの知識を体系づけられずに持っているので、ある特定の価値観を植え付けられると、それだけが全てになってしまいます。企業価値と言えばお金のことだけ、プロジェクトの目標と言えば、成果物ができればよい、ともすればニュースになりそうな、そんな感覚を持ちかねない知識なのです。

かつて論文の書き方を教わった時に、「言葉の定義」をするように厳しく教えられました。これは、異なる背景を持つ人との対話では、非常に有効です。暗黙の知識に頼らずに伝えることで、正確なコミュニケーションができるのです。開発に関する情報が複雑になり、各人が異なる断片的な知識を持つようになった今、異なる背景を持つ人が増えたのです。

人に何かを伝えるときは、断片的に説明してはいけません。きちんと体系的に説明しなければいけません。そんな時代が来ているのです。

改善の壁 - SS2007に参加して -

ソフトウェアシンポジウム2007に参加しました。今回はよりワークショップを重視した構成になり、多くの情報交換ができました(反面、参加したワークショップと関係のない情報を得る機会がなく、その点はちょっと残念でした)。私が参加したのは品質保証(SQA)でしたが、EPMのことを発表(リンク先はPDF)することができました。

内容は「障害管理ツールのデータをEPMで分析したところ、プロセス改善のきっかけを見つけることができた」というものでした。しかし、ワークショップの議論が「SQAを進めるために必要なメトリクスとツール」だったので、それに合わせて議論したところ

• SQAが手の回らない小さなプロジェクトでも開発者自身が分析できる
• メトリクスを収集するために作業が不要
• 開発中の情報をいつでも収集できる

といった点が好評でした。

さて、タイトルの改善の壁というのは、シンポジウムの最後の各ワークショップの報告に出てきた「準最適」という問題です。今のままではいずれ問題になるから新しいことを始めようとすると「今のままで良いじゃないか」という意見が出て、先に進めないというものです。レガシーなソフトを作り直したり、新しい技術を導入するには、コストがかかり、リスクもあることから、会社を問わず苦労するところですね。

これまでのプロセス改善(SPI)の議論では、

• 経営者層のコミットメントを得る
• 部分から全体に進める
• プロセスチャンピオンが引っ張る

という方法が言われてきました。ここでは、これ以外を二つほど考えてみます。

一つ目はプロダクトラインに学び「きっかけを生かせ」ということです。プロダクトラインでは、シリーズ開発などでソフトウェア資産の再利用を重視して、経営資本を投入します。その成功例を聞いているとあることに気付きます。これまでバラバラに開発したものをプロダクトライン化する際には、たいてい何かきっかけがあるのです。

新シリーズの開発などは非常に良いきっかけです。今までとあまり変わらない開発対象なら、今まで通りに開発することがたぶん効率的で、リスクの高い方法をとることもないでしょう。しかし、新シリーズなら従来の方法にもリスクがあり、新しく作り直したり新しい技術を導入することとのコスト差も小さく見積もることができます。

二つ目は「多次元に考える」です。「準最適」という聞きなれない言葉を使われていましたが、数学的に言うと「局所解」ですね。つまり、線形に考えると最適解が見つからないということだと思います。ついつい目先の収支にとらわれて新しいことができないなら、別の次元のパラメータを考慮することです。

このパラメータには、将来の市場予測や、開発環境の変化の予測など、プロダクトラインで検討されるべきパラメータが参考になるでしょう。

今回は日本酒 麒麟山「吟辛」(これがおいしい！)も、毎日のように飲めました。また、日本海タワー(リンク先はgoo)からも佐渡島らしき山影も見ることができました。そんなこんなで、結構楽しいシンポジウムでした。

日経ソフトウェアでSmalltalk

今、売っている日経ソフトウェア2007年1月号は、「フリー言語で真のプログラミングを学ぶ」という特集です。この本にはRubyやTurbo Delphiなどのフリーウェア言語の入ったCDがついています。
この中で注目すべきはSmalltalkが入っていることです。青木淳さんのSmalltalk道場で使われる３DライブラリJunの入ったイメージです。私はRuby使いになってしまいましたが、ついつい買ってしまいました。めったにない機会ですので、買っておかれてはいかがでしょうか？
といいつつも、Turbo Delphiもつかって見たいような気が、、、、、、

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

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

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

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

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

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

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

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

XP祭り関西2006 in ワッハ上方

今年から始まったXP祭り関西2006 in ワッハ上方(中央をクリックして、左メニューの"XP祭り参加申し込み"よりお申し込みください)の申し込み受付が開始しました。本体の講演はもちろんのこと、懇親会も楽しめます。ぜひご参加ください。

プログラムは以下のようになっています。

時間	スピーカー	タイトル
10:30 -11:15	日本XPユーザグループ 代表 倉貫義人氏	事例に学ぶXP開発のキホン
11:15 -12:00	国際ファシリテーション協会 理事 本間直人氏	笑いと喜びある未来のために ～人と組織の活性化のコミュニケーション
12:00 -12:50	昼休憩
12:50 -13:20	XPJUG関西支部 組込TDD分科会	組込みでもTDD！ ～C言語における LegoMindstorms テスト駆動開発実践～
13:20 -13:50	XPJUG関西支部 ビジネスモデリング分科会	経営戦略と情報システムをつなぐモデリング
13:50 -14:30	(株)ネットワーク応用通信研究所 まつもとゆきひろ氏	The State of the Dominion （仮）
14:30 -14:40	休憩
14:40 -15:10	牛尾剛氏・川端光義氏	XP（ペアプログラミング）開発ライブ
15:10 -16:00	株式会社チェンジビジョン代表取締役社長 株式会社永和システムマネジメント副社長 オブジェクト倶楽部 主宰 平鍋健児氏	現場力を高める見える化手法プロジェクトファシリテーション ～モチベーションアップのツールと場づくり～

詳しくは、トップページの中央をクリックしてください。

XP祭り関西申し込み受付開始せまる

いよいよ、8月28日からXP祭り関西2006 in ワッハ上方(中央をクリックしてください)の申し込み受付が開始されます。本体の講演はもちろんのこと、懇親会も楽しめます。ぜひご参加ください。

ちなみに、プログラムは以下のようになっています。

時間	スピーカー	タイトル
10:30 -11:15	日本XPユーザグループ 代表 倉貫義人氏	事例に学ぶXP開発のキホン
11:15 -12:00	国際ファシリテーション協会 理事 本間直人氏	笑いと喜びある未来のために ～人と組織の活性化のコミュニケーション
12:00 -12:50	昼休憩
12:50 -13:20	XPJUG関西支部 組込TDD分科会	組込みでもTDD！ ～C言語における LegoMindstorms テスト駆動開発実践～
13:20 -13:50	XPJUG関西支部 ビジネスモデリング分科会	経営戦略と情報システムをつなぐモデリング
13:50 -14:30	(株)ネットワーク応用通信研究所 まつもとゆきひろ氏	The State of the Dominion （仮）
14:30 -14:40	休憩
14:40 -15:10	牛尾剛氏・川端光義氏	XP（ペアプログラミング）開発ライブ
15:10 -16:00	株式会社チェンジビジョン代表取締役社長 株式会社永和システムマネジメント副社長 オブジェクト倶楽部 主宰 平鍋健児氏	現場力を高める見える化手法プロジェクトファシリテーション ～モチベーションアップのツールと場づくり～

詳しくは、トップページの中央をクリックしてください。

「ハッピ」か「Tシャツ」か - ＸＰ祭り関西2006 -

いま、関西では大論争が巻き起こっています。
といっても、9月30日に行われる「ＸＰ祭り関西２００６」のスタッフの服装です。祭りというネーミングからハッピが人気なのですが、ボランティアベースのイベントで、初回からそんなにお金をかけなくても、実績を積んだ2回目からでも良いように思います。Tシャツだったらパジャマにもなるし、、、。地球に優しいTシャツに清き一票をお願いします。投票はここのページまで、、、XP祭りはこんなノリでやってます。

ちなみに、申し込みの受付開始はもう少し先になりそうですが、8月25日にあるSEA関西プロセス分科会で、XP祭り関西のチケット先行販売が行われます。ぜひご参加ください。タイトルは「ソフトウェア・アーキテクチャの実践」で、ご講演は「実践ソフトウェア・アーキテクチャ」の翻訳チームのメンバーでもあるデンソーの佐々木明博さんと、SEA幹事でもあるSRAの小林修さんです。

「＜＜」の読み方－第11回 Ruby勉強会＠関西－

新しい文化は関西から始まるのかもしれません。
Ruby関西の勉強会では、新しい技術やディープな話のほか、Ruby 初級者向けレッスンが行われます。レッスンのお題は「イテレータ」、繰り返し処理を簡単に処理する方法の解説でした。例題でArrayの最後に追加する際にメソッド「<<」(Pushとおなじ)が出てきました。これは

Array << obj

とすると、もともとの配列の最後に"obj"が追加されるものです(マニュアル)。さて、このメソッド、なんと呼ぶでしょう？「小なり小なり」ですか？

そんな呼び方をするあなたは、たぶん職業プログラマでしょう。そんな呼び方はやめましょう。「クク」と呼んでください。呼びにくい言葉は、言い換えれば良いのです。ギャル文字風の呼び方などと言ってはいけません。

この呼び方は「みかか」以上のショックでした(「みかか」はチャット中にNTTと打とうとして、入力モードを間違えて「みかか」と打ってしまったことがきっかけで、露骨に書くのがはばかれるときなどに、いわば隠語としてはやりました)。「なんだそれ」と思わせて、あとから「ああ、そうか」と思わせる不思議な呼び方です。

それだけではありません。「クク」はパソコンの創成期を思い起こさせます。そう、プログラミングが仕事でなく、趣味だった時代です。プログラムのソースが雑誌(マイコン、アスキー、IO、のちにOh!PC)に載っていて、誰もがそれを打ち込んでいたころのお話です。

膨大なプログラムを一人で打つのは大変なので、一人がプログラムを音読し、もう一人がタイプする。そんな協調作業が普通に行われていました。

読むのも大変で、読みにくい記号は、新しい読み方を与えられました。

( ：　かっこ
) ：  こっか
! ：　バン

こんな感じで、それぞれ工夫したものです。

さていつからだったでしょうか。プログラミングが仕事になり、新人研修で「開き括弧」なんて真面目に呼ぶようになりました。また、人にプログラムのコードを伝えるときは、合理的だからとメールなどが増え、音読して伝えることも少なくなりました。

Ruby勉強会での出来事は、プログラムを音読して人に伝える過程でおきました。その意味を考えると、Rubyは私たちにプログラミングの楽しみを取り戻させてくれようとしているような気がします。これは画期的な出来事、社会の変革だと思います。

みなさんに提案します。「＜＜」は「クク」と読みましょう。

「アジャイル開発の勘違い」- 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割の機能が全て後回しになるわけではありませんが、必須であるかどうかわからない難しい機能は後回しになり、場合によっては開発されないこともあるでしょう。これが、決定を遅らせるというリーン開発の実践になり、生産性を高めているのではないでしょうか。

テスト設計のモデル化

少し前のお話になりますが、テスト技術者交流会の関西勉強会に行ってきました。

今回は電通大の西先生がJaSST'06 in 東京で講演された、の「テスト設計におけるモデリングのための記法の提案」のお話をうかがうことができました。これまでソフトウェア設計で行われていたグラフィカルなモデル化を、テスト設計に持ち込むものです。

モデルという言葉で思い出すのは、ビル・カーチスらの記事「プロセスモデリング*」です。この記事では、(乱暴にまとめると)プロセスをモデル化することで、人に伝えたり、議論したり、教育に用いることができるようになるとしています。

今回も、サンプルのテスト設計モデルを通じて、どのようなテスト設計が良いか、再利用をどこまで考慮すべきかなど、興味深い議論が行われました。

これまでテストというと、職人芸的に重要な因子が選ばれていることが多いと思いますが、モデル化によって各人の中にうずもれていたノウハウが、より洗練されたり、技術移転がなったりすると期待しています。

*B. Curtis, M. I. Kellner, J. Over, "Process Modeling", 35-9, CACM, pp.75-90, 9, 1992.

Path上のRubyの実行

Ruby関西に行ってきました。詳細はあきぴーさんの記事 を見ていただくとして、ショッキングだった出来事を書きます。

VAX世代のUNIX使いの私は、rubyのスクリプトの先頭は

#!/usr/local/bin/ruby

と書くものだと思っていました。そうでなければ、間にシェルをはさむものだと思っていました。かずひこさんのレクチャーでは、

#!/usr/bin/env ruby

のように、envを間に挟んだほうが、どこでも動くので良いとのこと。envは環境変数を見るツールだと思っていた私は、目からうろこです。4.2BSDのころのマニュアルなら一般ユーザ向けの内容は一通り読んでいましたが、やっぱりマニュアルは新しいものを読まないといけませんね。はい、はい、時代遅れのおじさんで、すみません。

SEA関西プロセス分科会(WebTech)

「もうひとつのRuby on Rails」で、ご案内した徳冨さんによる「WebTech」の講演がありました。明らかに"Ruby on Rails(RoR)"とねらいが異なっており、面白かったです。

RoRの場合は、いかに実装を早くするかを重視していると思うのですが(ちがっていたらごめんなさい)、WebTechは要求分析でのデータモデリングをいかに効率的に行うかに注目しています。

業務システムを開発する場合、データモデリングは重要です。その業務に関わるエンティティとリレーションを明らかにする必要があります。もちろん、オブジェクト指向で分析しても良いのですが、RDBの利用が前提ならE-Rモデリングも直接的なマッピングであることから、それなりに有利だと思います。

ユーザとともにモデリングをする場合、細かな見た目はともかく、テーブルと画面とすばやくデモすることは重要だと思います。ともかく動くようになれば、ユーザはコメントをしてくれるでしょう。

WebTechはそのような典型的なデモアプリの作成を支援する環境です。E-Rモデルを変更しながらユーザにデモする、そんな環境を提供します。

WebTechの基本的なアイデアはRoRと似ていると思います。DBを使うといつも同じように書かなければいけない部分を、環境側に用意しておきます。簡単なものはすぐにでき、ユーザは差分を開発すればよい。この辺は非常に似ています。

しかし、データモデリングを重視したところがWebTechの特徴でしょう。近年、システムが複雑化、短納期化することで要求分析の重要性が高まっています。今後のWebTechの発展に期待しています。

もう一つのRuby on Rails !?

SEA関西SPINのWebページにSEA関西プロセス分科会のご案内が出ています。

今回は、未踏プロジェクトの徳冨 優一さんです。テーマは「WebTech ～ Webアプリケーションの効率的な開発方法論」となっていますが、開発環境まで作成されています。IPAに載っている概要を見ると

システム開発案件で主流となっている DB 連係の Web アプリケーション開発について、要求獲得から実装までの開発効率を向上させる方法論と、それを実現するシステムを提案する。
　　基本的な考え方は、開発する Web アプリケーションを典型的な部分と個別的な部分に分割し、典型的な部分を自動生成することで、開発リソースを個別的な部分へ注力することである。
　　全体の 80% の典型的な部分を 1/4 の開発期間で実現し、残った3/4の期間を使って、個別的な部分の開発を行うことで、精度の高い要求獲得と高品質な実現を行うことを目標としている。

とされていて、なんとなく Ruby on Rails(RoR) と似ています.。以前、徳冨さんにうかがった際には、RoRがお手軽最優先に対し、開発者向きのRoRを目指されているように感じました。

そのときは、酔っ払ったので、おおまかな印象しか覚えていません。ぜひ、分科会で詳細をご確認ください。(^_^;

テストのパラダイム

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

来年はバランスの年に

今年一年を振り返ると色々ありましたが、無理やり分けると二つの考えの対立(あるいはせめぎあい)に思えます。

• トップダウン、ウォーターフォール、計画駆動、機能指向、性悪説
• ボトムアップ、ボトムアップ、アジャイル、オブジェクト指向、性善説

上の方には、SOAやアスペクトなども含めます。

この二つに分類すると、バランスが悪くて「ホツレ」が出てきているように思えます。試験があるものの裏技を駆使してごまかすような事件があったり、まとめのWebページが話題になったり、、、

今年のお気に入りの本を上げるなら、「アジャイルと規律」「リーン・ソフトウェア開発」でしょう。これらの本を読むまでは、そろそろウォーターフォールも限界でアジャイルかとも思っていましたが、「アジャイルと規律」はそれぞれの長所・短所を明らかにし、対象や組織の状況によって、段階的に開発したり、部分的に適用するなど、バランスをとるべきであることを述べている、とっても良い本です。でも、よく考えると、すでに同じようなことをしてませんか？

「リーン・ソフトウェア開発」は「アジャイルと規律」では最もアジャイルに分類されている、トヨタ式改善のソフトウェア版です。この本は、ソフトウェア開発の最適化とリスク回避の技術が詰まっている良い本です。でも、具体的にはリスク回避のためのオブション思考以外は、けっこう普通のオブジェクト指向でもあります。

結局、書籍はあるところに注目して書き上げたものなので、すでに色々工夫している人にとっては、けっこう普通のことが載っています。これは、オブジェクト指向を長くやってきた人が、デザインパターンやXPをそういう風に言われるのと同じだと思います。

で、なにが言いたいかというと、上にあげた2冊はバランスに注目している点がすばらしいと言うことです。具体的にああしろ、こうしろとはあまり書かれていませんが、現実の具体的な問題に対して、どのように判断するかが書かれているところが秀逸だと思います。

このようにバランスを考えた本は、20年前にもありました。テストの本で有名なマイヤースの「複合設計」です。機能指向とデータ指向で議論されていた当時、同じようにバランスをとった設計法でした。この本はわかりやすく、その内容を現場でよく使わせてもらいました。まあ、そのあとのオブジェクト指向ブームで、あまり読まれなくなっちょいましたが、、、

来年は、それぞれの要素技術をどう組み合わせてバランスをとるかが重要になるのではないでしょうか？もちろんある技術に特化した議論も進むでしょうけど、現場で実際に使われるようになれば、既存技術とどのようにバランスするかがポイントになると思います。

また、複合設計に対するオブジェクト指向のように、RonR(Ruby on Rails)あたりに吹き飛ばされるかもしれませんが、、、

最後になりましたが、本年もお世話になりました。来年もよろしくお願いいたします。

１２・１６ＳＥＡ関西プロセス分科会

今回のSEA関西SPINは、企業全体の視座からのプロジェクトマネジメントのお話です。

「プロジェクトガバナンスとポートフォリオマネジメント」

と言うことで、まだ申し込んでいない方は急げ！＞おれ

Ｒｕｂｙ勉強会＠関西

はじめてＲｕｂｙ勉強会＠関西に行ってきました。会場は京都女子大。
そこで、開会に先立って注意がありました。怪しい行動、ものめずらしげにきょろきょろしたり、じろじろみないように。最初から大うけでした(^_^;

今日の発表は以下の3件でした(詳細は以下に書きます)。

• YARV について by 笹田耕一さん
• RGSS 解説 by サイロス誠さん
• Ruby 初級者向けレッスン by かずひこさん

それぞれ内容も充実していて、とても楽しめました。

続きを読む "Ｒｕｂｙ勉強会＠関西"

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

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

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

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

【CMMIには用心すること】

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

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

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

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

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

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

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

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

Webアクセシビリティ

今日はKOF2005で開かれたACRI研究会に参加しました。
今回は実習形式でアクセシビリティを考慮したWebページを作成しました。
実習はメモ帳＋無料ツールで行われました。

• Another HTML-lint gateway
• Fujitsu ColorSelector(Java Runtime Environmentが必要)
• W3C CSS 検証サービス

このほか、実習はありませんでしたが、以下も紹介されていました。

• PC-Talker XP 体験版
• ProTALKER 97 開発者向け評価キット（サブセット版）

メモした内容は以下の点です。

• JavaScriptへのリンクがあると、設定によっては呼べない人がいる
• _blankで新しいページに遷移すると、戻れなくなるので、どうしても新しいページに遷移したければJavaScriptで遷移する(JavaScriptが無効になっていれば同じページに表示される)
• CSSでは総称セレクタ"* {"でブラウザごとに異なる"margin","padding","font-style","font-weight"を指定する

altの指定やセーフカラーの指定などアクセシビリティの基本のほか、Windowsのユーザ補助に合わせて"h1"に"line-height : 100%;"を指定すると良いというのは、ACRIのメーリングリストで議論のあったところで、実ユーザからの情報が得られるのは、コミュニティの強みですね。このほか、リンクで「ここ」と書いてあると、リンク先だけを読ませた際に良くわからないと言うのは忘れがちなところだと思いました。

つぎは、Webエディターの利用方法なども聞いてみたいと思いました。<=わがままです

お気に入りの一言

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

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

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

モデル検査とSPIN入門

SEA関西支部プロセス分科会(略称SEA関西SPIN)に参加しました。
トゥルーロジックの野中さんはUNIXカーネルの開発者たちが開発したSPINの解説でした。SPINは状態遷移を検証する処理系で、モデルが取りうる状態と起きてはいけない状態の論理積が空であることをすべての状態を展開して確認します。モデル検証は実装の前に設計を検証するもので、自動、反例を示す、まれにしか起きない問題を検証するといった特徴があります。

言語はPROMELAといい、do-od、if-fiとさすがにUNIXの開発者が作っただけあってshのような表記です。いつかきっとは" <>"、いつもずっとは"[]"、untilは"Ｕ"です、このうち、" <>"をひし形はいつかきっと傾くという説明がGOODでした。

モデル検証はアルゴリズムと計算機の高速化で1980年に7日かかったものが今では数秒で処理できるようです。SPINにはモデル検査のCコードを出力する機能もあるそうです。
詳細とツールは、http://www.spinroot.com/にあるようです(私は見れませんでした)。

SRA-KTLの岸田さんは「銀河ヒッチハイクガイド」をつかみに、岸田さんが70年代後半にアメリカのSRAでエドワードミラーと知り合って、カバレージを日本に伝えたお話、LehmanのS(Specificationが定義できる),P(なんとかプログラマブル),E(Embedded)のお話、社会のチリにまみっれているからと大森荘蔵に教えを受けられなかったお話、ソシュールが言語学は規範の額ではない(正しい日本語とか)と同じく、ソフトウェア工学は規範の額ではなく、モデル(文字)はソフトウェア(言語)の正体を隠すものであって、モデルを剥ぎ取ったところに本物のソフトウェアが現れる、E-typeは無限の属性を持つので、仮説は2000年問題のように成り立たなくなる、といったお話で構成されていました。

最後のディスカッションでは、SPINは特定領域に絞って使う、複数の形式手法を組み合わせないといけないのが現状といったわだいが出ていました。

アジャイルプロセス協議会「西日本セミナー」その3"モチベーションとファシリテーション"

セミナーの最後は2件で、一つ目はTDDのバグなし本で有名なアジャイルウェアの川端さんは「アジャイル開発の落とし穴」はプロジェクトのモチベーションをいかに保つかでした。お話の途中で出てきた契約のパターンのお話は聞いたことがあると思ったら「リーンソフトウェア開発」が元ネタだそうです。コミットしたときに自慢げに押すコミットボタンは東急ハンズで千円台で売っていたそうで、「御用の方は、、、」と書いてある上から「コミットしたときはベルを押してください」と書いた紙を張ったそうです。このベルは懇親会でも活躍していました。

NCSの高森さんの「eXtreme Programming とファシリテーション」はぜひ資料を見てください。共有、発散、収束をうまくコントロールすることがポイントだそうです。経験がにじみ出ていてよくわかるお話でした。

SEA関西プロセス分科会

10/21は「モデル検査とSPIN入門」です。野中さんと岸田さんが 講師で、場所は大阪駅前ビルです。まだ、若干の空きがあります。詳しくはこちらの案内を見てください。
(水曜日が締め切りになっていますが、たぶん、ぎりぎりまで大丈夫です)

アジャイルプロセス協議会「西日本セミナー」その2"Software Factories"

アジャイルプロセス協議会「西日本セミナー」の2つ目は、マイクロソフトの荒井さんの「Software Factories　― パターン、モデル、フレームワーク、ツールによるアプリケーションの組立」でした。

ここでいうSoftware Factoriesは昔はやったソフトウェア工場ではなく、ユーザのドメイン用の言語をDSL(Domain-Specific Language)　tool で作成し、ドメインに限定された言語(DEL)で要求を書くことで、コードの自動生成を行うものです。自動生成によってより機敏(アジャイル)に開発できるとのこと。従来からコードの自動生成のツールはありましたが、 より抽象度の高いレベルで環境を整えておくところが新しいと思います。

日経BPソフトプレスから「ソフトウェアファクトリ」という本も出るようです(以下の和訳)。
Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools by Jack Greenfield, Keith Short, Steve Cook, Stuart Kent, John Crupi (Wiley)

アジャイルプロセス協議会「西日本セミナー」その１

アジャイルプロセス協議会「西日本セミナー」に参加してきました。
オープニング・セッションは新保さんの「開会挨拶・アジャイルプロセスとは」でした。アジャイルの説明の中で興味深かったのは、アジャイルを「ビジネス価値に基づく開発」とし、要求開発アライアンスを引用されていたことです。はじめのビジネス価値というのは、先日のSEPG JapanのVuさんの講演の「ビジネス成果」につながるものです。後のほうの要求開発アライアンスは、SEPG Japanのチュートリアルの内容そのものです。CMM的なSEPGとアジャイルは同じ方向を向いていたのですね。

SEPG Japan 2005 の感想

SEPG Japan 2005に3日間参加してきました。
参加者は４３２名だそうで、今回も盛況でした。発表は45件（うち海外6件)で、以前はレベル達成などの発表が多かったですが、より実質的なプロセス改善のお話が増えたように思います。

最優秀発表賞はオリンパス岩見さんで
「ソフトウェア開発委託の実態　－責任回避と丸投げの病理－」
という発表でした。 社内の部門で、外注管理に失敗しているところがあったので支援した経験の報告でした。改善したのは、レビューと検収の強化で、このうち興味深かったのは、検収の強化です。検収ではテスト報告書の確認と受け入れ試験の実施をおこなったとのこと。このテスト報告書を受け取る際に、最終結果だけではなく最初のテスト結果を提出してもらったのがアイデアで、このデータから問題の生じそうなモジュールを特定されたそうです。そういうのもある、ある、と思うような現場の問題を発表されていて、耳の痛い人も多かったかもしれません。

実行委員長賞はニコンシステム今井さんで
「熱意や道徳に訴えないモチベーションのアプローチ」

プログラム委員長賞はSRA杉山さんで
「小さなプロジェクトの小さな改善」

でした。この2件は聞けなかったのですが、杉山さんの発表は、小さな改善ではあるが、現場の人自身が改善して、発表したということが評価されたようです。このお話をSEA関西SPINでしたところ、O社のTさんいわく、SEPGを別グループにすると現場の協力を得ると言うのは難しい、ということで評価が高くなったようです。

レベル取得ブームからカイゼンへ

CMMが普及するにつれ、レベル取得ブームの嵐が吹き荒れていました。PMBOKやCMMIの連続モデルなども知られ、ようやくレベル取得ブームは山を越えたようです。

SEPG Japanのキーノート＆プレゼンのVuさんいわく、レベルだけでなく、ビジネス成果が必要であるとのこと。まさにそのとおりだと思います。

質疑応答で出た例がリーンソフトウェア開発のプルシステムに似ていると思ったら、リーンソフトウェア開発を導入していたとのこと、なるほどね。

SEPG Japan 2005に参加しています

キーノートは米国ボーイング社のJohn D. Vuさんのプロセス改善の間違いと実際の話でした。プロセス改善を行う72%は失敗あるいは大きな効果がないそうです。プロセス改善には成熟度レベルの向上だけではなく、ビジネス成果と結びつかないといけないと言うお話でした。

質疑応答で改善の例として、「飛行機では7000万個の部品がいる。在庫が減るとFAXなどで注文するが、その間製造が遅くなる。そこで、在庫情報をDBに入れ、すべてのサプライやが見れるようにした。在庫の上限と加減を決めておき、納入してもらう仕組みにした。サプライヤもカイゼンできた。この結果、FAXや注文書がなくなった。サプライやが在庫管理できるので、効率が50％向上し、５億ドル儲かった」と言うお話がありました。これぞ、リーンソフトウェア開発のプル・システムですね。

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアメトリクス

ソフトウェア工学という言葉を知っていても、メトリクス(尺度)という言葉を知らない人は多いのではないでしょうか？最近、初めて学ぶソフトウエアメトリクス～プロジェクト見積もりのためのデータの導き方という本が出たようです。ソフトウェア開発を見える化するためには何らかの尺度に基づく定量的なデータが必要です。ひとまず買ってみます。

シンプルルール

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

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

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

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

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

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

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

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

ソフトウェアテストシンポジウム

論文締め切りが延びたようですね。

　　　　JaSST'06 in Tokyo

テストと聞くと狭い工程のように感じますが、品質を高める最後の砦ですし、新しい技術を取り入れて工夫する余地の多い工程ですね。最近ではTDD（テスト駆動開発）の話題もありますので、興味深いところです。

個人的には、今回はネタがないので論文はパス、会議のほうは東京か大阪のどちらかには参加したいと思っています。

５つの重要要因

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

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

リーンソフトウエア開発

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

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

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

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

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

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

純粋主義者の解釈

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

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

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

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

空想的アジャイル

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

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

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

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

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