無料ブログはココログ

« 2010年10月 | トップページ | 2010年12月 »

クリスマスにお勧めの曲

クリスマスとは何か?

去年、プロジェクトの打ち上げの2次会でのこと。その場の雰囲気で、一定時間ごとにお酒を作ってくれる人が変わるお店でのこと。口説く趣味もないので興味本位でクリスマスが何の日かを質問をしてみました。さすが日本の若人、4-5人のうち「キリストの誕生を祝う日」と言ったのはたった一人で、それ意外の方はボロボロでした。

日本は不思議な国です。そもそもクリスマスは「キリストのミサ」の意味、キリストをカトリック教会で祝うのが語源です。日本でキリスト教徒は1%、カトリックはその半分で0.5%しか居ないそうです。そのお祝いを全国でするのですから、キリストもお喜びでしょう。

そもそも、馬小屋で生まれたら死にそうな冬のクリスマスは誕生日ではありません。ローマの宗教であったミトラ教の太陽神の祭りと重ねるためには政治的に決まったそうです。そんな日でも、年に一度、楽しむことが大切なのでしょうね。

吉田拓郎「諸人こぞりて」

クリスマスになると毎年のように流れるのが吉田拓郎さんの「諸人こぞりて」です。歌詞は元のままで「神様が生まれたぞー、やれ祝え」といった歌です。この歌が入っているのは「クリスマス」というCDで、吉田拓郎, 泉谷しげる, 井上陽水, 小室等というフォーライフの時代を築いた面々です。

このCD(当時はレコード)は作りすぎて会社が傾いたそうですから、半端ではない力の入れ方、売れないCDだったのでしょう。でも、フォーク好きが集まってパーティをしているようなこのCDは結構楽しめます。特に泉谷さんの悪ふざけに拓郎さんが突っ込んでいる様子は、実際のパーティの様子を見ているような気がします。

ボブ・ディラン「Christmas In The Heart」

ボブ・ディランといえば私よりも少し前の世代の歌手で、ガロの「学生街の喫茶店」で名前を知っている程度ですが、「風に吹かれて」と言えば多くの方がご存知でしょう。

ビッグ・イシュー133号によると、ボブディランの親はユダヤ教徒でしたが、70年代遅くに洗礼を受け、以来、ゴスペルのアルバムを出されていたようです。そしてクリスマスアルバムを出したそうです。

このChristmas in the Heartの収益金は経済的に苦しんでいる人たちのクリスマス・ディナーを買うために使われるようです。

このCDを聞いて驚いたのはボブ・ディランの声。渋い!とても渋いです。ルイ・アームストロングみたいな声です。部屋を暗くして静かに聞きたくなるような、ちょっとしわがれた太い声です。若い頃はこんな声ではなかったと思うのですが、低音の良く聞こえる環境で聞くと最高です。 ぜひ、一度聞いてみてください。

[#TiDD] 出版裏話8:「Redmineによるタスクマネジメント実践技法」はそもそもRedmineの本だったらしい

もう「Redmineによるタスクマネジメント実践技法」の裏話は無いと思っていたのですが、先日、「JUDEで学ぶシステムデザイン (oop Foundations)」の細谷さんとSPI Japan 2010でお会いしたときのことです。そもそも出版のきっかけは、細谷さんが翔泳社を紹介してくださったからでした。世間話やらレビューのお礼を言っていると、本の話になりました。

そのときにうかがった、あきぴーさんに翔泳社を紹介した理由は、

「Redmineを検討していたので、あきぴーさんのブログをまとめて欲しかった」

というものでした。最初にあきぴーさんから聞いたときは、チケット駆動開発が主で、Redmineにも触れると思っていたのですが、きっかけはRedmineだったのです。

Redmineは先進的なのでチケット駆動開発を考える方にお勧めなので、不満はありません。でも所詮、孫悟空は一生懸命に遠いところに行っても、御釈迦さんの指までしかいけないということなのですね。

まあ、そんなこんなで、アマゾンにもチケット駆動開発の本としての評価と、Redmineの本としての評価がいただけるのはうれしい限りです。

これまでの裏話

[TiDD] 出版裏話1:没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -

[#TiDD] 出版裏話2:大人の事情で「タスクマネジメント」

[#TiDD] 出版裏話3:中堅技術者向けのRedmine&TiDDの本

[#TiDD] 出版裏話4:「チケット駆動開発+テスト工程管理のAtoZ」

[#TiDD] 出版裏話5:「Redmineによるタスクマネジメント実践技法」 詳細目次

[#TiDD] 出版裏話6:「Redmineによるタスクマネジメント実践技法」 販促チラシ

[#TiDD] 出版裏話7:trac, mantis,すべてのBTSをお使いの方に

[iPhone4] 無線で印刷!AirPrint はなかなか便利です。with HP B110a

iOS が4.2.1になり、待望のAirPrint(リンク先はApple)が利用可能になりました。

早速、自宅のHP Photosmart Wireless B110aで試してみました。対応プリンタの一覧にはありませんが、ぜんぜん問題ありません。各アプリケーションのメニューから印刷を選ぶと、プリンターの選択ができるようになっていて、無線でつながるプリンターを選択できます。細かな設定はできませんが、写真も十分キレイに、Webの印刷もキレイにできました。メールも印刷できますが、添付ファイルはキレイなアイコンが印刷されるだけでした(残念!)。AppleのページにはiBooksからPDFが印刷できるとありますが、いまのところ印刷メニューはありません(今後に期待しています)。

AirPrintが便利なのは無線で印刷できることです。B110aにはePrint(メールdeプリント)といって、プリンタにメールを送ってテキストや添付ファイル(Office+PDF)を印刷する機能があります。しかし、以前書いたように、自宅のルータ+FONの環境では電源を完全に切ると、再接続に時間がかかると言う問題がありました(マニュアルには数分でつながると書いてあります)。また、接続された状態でも、メールだと開始までに30秒ぐらいはかかっていました。

これが、AirPrintならサーバーを経由しないので、すぐに印刷が始まります。今のところ、印刷可能な文書には限りがありますが、写真もふちなしで出ますし、iPhoneでは読みにくいWebも印刷して読めます。とても便利です。

こうして、パソコンが要らない環境を構築していくというのが、Appleの戦略なのでしょうね。今後の展開を楽しみにしています。

[#TiDD] チケット駆動開発で現場力を向上する

少し前に書いたプロセス改善には、以下の二つの流れがあります。

・トップダウンによる管理力の向上
・横展開による現場力の向上

それぞれに長所、短所があります。

トップダウン

  • 長所:組織全体で一貫性のあるプロセスを組織的に実現できる
  • 短所:ルールの存在が負担になり、やらされ感を感じる場合もある

横展開

  • 長所:プロジェクトにあわせたプロセス改善ができる
  • 短所:個々のプロジェクトの判断で、プロセスを端折ってしまう可能性がある

トップダウンは会社の方針ですので、予算の獲得も用意です。問題もありますが、やる気を出させるために開発者を集めてワークショップを開けば、効果的な改善が可能なようです。そのようなアプローチがふさわしい問題がある場合には、トップダウンが有効な場合もあると思います。

しかし、チケット駆動開発の本 で私が意識しているのは、現場力の向上です。自分たちのプロジェクトで実践し、成功すれば、そのメンバーが別のプロジェクトでも実践しますし、それを見た人たちのプロジェクトにも展開されるでしょう。このように個々のプロジェクトを活性化して、プロセスを改善していきます。

現場で起きている問題を解決する目的で、プロセス改善を実施すれば、プロジェクトは楽になり、多くのメリットが得られます。開発者自信で考え、行動することで、効率的な開発ができるでしょう。

横展開で問題になるのは、組織での一貫性です。新しいことを始めると、従来のルールがあてはまらなくなり、管理できなくなります。また、似た問題に対する解決法の再発明によって無駄も発生します。

チケット駆動開発ではBTSを利用しますので、BTSの共有によってある程度この問題を解決できると思います。BTSにはチケットのルールがツールかされていますので、BTSを共有する人たちで、知恵を出し合えうことで、より便利で効率的な環境が構築できると思っています。

グレー境界値!?

Twitterは情報が豊富ですね。

先日は「上流工程で効く,”「テストの考え方」第2回 境界値バグは上流で潰したい”を知りました。

なかなか面白い記事です、Myersの「ソフトウェア・テストの技法」は、社会人になった頃の上司に薦められてよく読みました。

今やテストする際に、この本に載っている境界値のテストは当たり前です。

かつて、てふかん(TEF関西勉強会。TEF(Testing Engineer's Forum):ソフトウェアテスト技術者交流会))が始まった頃の集まりで、テストの議論をしていたとき、ビットの切れ目の話が出ました。仕様上の境界値のほか、実装する環境によってビットの切れ目のテストが必要と言うものでした。

それは特殊なハードのお話しでしたが、確かにハードウェアやソフトウェアによる管理上の制約によって、仕様と異なる境界が生じる可能性があります。このような境界値の名前はあるのでしょうか?ここではグレーボックスのまねをして、グレー境界値としておきます。グレー境界値として、思いつくものには以下のようなものがあります。

  • 変数の型による上限値:コーディングミスの可能性を考えると、符号ビットの境界値を意識したテストも考えられますね。
  • ディレクトリなどOSの境界値:OSによっては1つ(あるいは特定)のディレクトリに許されるファイル数の上限があるかもしれません。
  • ミドルウェアの境界値:言語でなくミドルウェアやライブラリや設定による制約があるかもしれません(設定は運用設計によって行われるので、グレーではないかもしれません)。

かつて、ポスグレで特定のEUCとUTFの変換で問題があると言うのもありました(これは境界値と言うよりは同値クラスかもしれません)。

このように、仕様で明確に書かれていない境界値は、テストのノウハウですね。チェックリストを作っておいて、あらかじめわかる問題をさけたいところです。こういったテスト項目のフロントローディングは、高品質なソフトウェアを開発するには大切だと思います。

[#TiDD] チケット駆動開発はプロセス改善

プロセス改善とは文化を変えることです。チケット駆動開発はプロセス改善です。単にツールを導入するのではありません。

BTSを中心に環境を整備して、開発現場の複雑な作業をツールに任せることでよりクリエイティブな作業をするという文化が、チケット駆動開発の文化です。

さて、このような文化をどのように根付かせるか、それは1990年代にCMMが話題になった頃のプロセス改善の議論が役に立つと思います。当時のキーワードには以下のようなものがありました。それぞれについて考えてみます。

1.トップのコミットメント

プロセス改善には予算が必要です。たとえ必要なツールが無料であっても、組織の活動とするには、学習のための時間が必要です。また、あまり乗り気でない人たちに理解を得るには成果を報告したり、ワークショップでモチベーションを高めることも必要でしょう。

2.プロセスチャンピオン

組織を変えるのはトップの号令だけでは困難です。組織のプロセス改善を引っ張っていく「プロセスチャンピオン」の存在がプロセス改善を成功に導きます。

3.成功事例を作る

今までのやり方を変えるのは誰でも抵抗があります。その抵抗感を和らげるのは、イノベータの成功事例です。「やってみようかな」と思わせるような効果が必要です。そのためには、最初の対象となるプロジェクトやタイミングは非常に重要です。

CMMに対するこのような議論が、SEA-SPINJASPICSEA関西SPINで行われてきました。CMMのように大きなブームになれば、営業的な観点からトップのコミットメントを得ることも比較的容易かもしれません。

しかし、チケット駆動開発のような最近名前が付いた技術の場合、まずは成功事例が必要でしょう。そこで、補完型のチケット駆動開発が大きな効果をあげるのではないかと思っています。

あと、近年のアジャイル2次ブームを利用するなら、XPのタスクカード、スクラムのバックログをチケットに置き換えることから始めるのも良いかもしれません。

つづく

[#TiDD] チケット駆動開発とデジタル化

昨日書いた記事で、チケット駆動開発によってアナライザ型の人が元気になったことは、デジタル化の効果だと思います。

これまであきぴーさんとチケット駆動開発の論文を書く際に、様々な議論をしてきました。その中で、「デジタル化」あるいは「オンライン化」についても何度か議論しました。デジタル化は、たとえば「XPのタスクカード」を「チケット」にデジタル化するというと説明が容易になります。しかし、論文で発表する主たる効果としてはインパクトの弱いもので、これまでデジタル化とはあまり書いていませんでした。

今回、デジタル化をコーチングの分類と絡めることで新しい展開が見えてきました。しかし、デジタルならではのメリットもある一方で、デジタル化に伴う弱点もあります。特に簡単で全体を鳥瞰できるのはアナログ媒体ならではのよさでしょう。今回は、これらの特徴を考えて見ます。

デジタル化の長所

・膨大なデータを分類して記録することができる
・データベースを利用することで、膨大なデータの中から属性値に基づいて抽出できる
・分類することで情報が単純化され、本質的なコミュニケーションが容易になる可能性がある(きっと、これが、アナライザ型の人の能力を引き出すのでしょう)

デジタル化の短所

・データ長、属性数の制限がゆるいので、利用するうちにデータが膨大になる
・手作業では対応できなくなるので、分かりやすくまとめることが困難
・単純化されるので、ある程度データを蓄積するまでは情報量が減る

BTSの限界と対策

先日のSPI Japanで、大量のチケットが捌けないというお話を伺いました。複雑なものを管理する方法で、よくあるのは構造化です。階層的に扱うことで管理が容易になります。しかし、大量のデータを分析、判断、決定をするには、まとめるか、間引くか、して、アナログ情報の鳥瞰を実現する必要があります。

BTSには古くからまとめる機能があります。マイルストーンやバージョンなど、チケットを何らかの単位で集計することで、詳細を見なくても概略を見ることができます。しかし、これはマイルストーンやバージョンなどの一つの属性に基づくものですので、データ量が多すぎる場合には限界があります。

BTSで階層化する場合、サブタスキングや関連付けが行われますが、これは、良く考えると上位のチケット分だけデータを増やしています。このため、集計結果を上位チケットに更新する機能があっても、下位チケットを含めて管理対象にしていては大変です。

管理対象にするかどうかの属性を増やして、それを元に抽出して表示する、つまり間引くことが必要だと思います。

また、チケットが大量にある場合は、Webベースの入力は大変ですし、外部との連携も考慮すべきでしょう。

デジタル化の可能性

かつて在宅勤務が話題になったとき、現行の仕事をどのように持ち帰るかと言う観点で議論されました。しかし、仕事をデジタル化することで、ある程度分散が容易になると思います。また、最初に述べたように、これまでは能力が発揮できなかった人が能力を発揮できる可能性があります。

とはいえ、デジタル化にも長所と短所があります。何でもデジタル化すればよいわけではありません。長所を伸ばし、短所を回避するノウハウを蓄積することで、新しい未来が開けてくる。その可能性を感じています。

[K-POP] 韓流音楽は原語がおすすめ

男はどんな音に魅力を感じるか?

私は聞きなれない音ではないかと思います。初めてのメロディ、聞いたことがあるようでちょっと違う旋律と共に、甘えた声やちょっとずれたような発音は、方言と同じでとても魅力的だと思います。

実は私の妻は福岡出身です。たまに方言が聞けると、とてもうれしいものでした。武田鉄也さんはコンサートなどで、低い声でまねをして性格の悪い女性を皮肉られることがありますが、地元の言葉と言うのは、聞きなれていますし、言葉の裏側まで透けて見えたりして心地よくないものかもしれません。

実際、妻の言葉にネイティブな関西弁が混じりだした頃、うれしいような寂しいような気持ちがしていました。

私の魅力的な音との最初の出会いはアグネス・チャンさんだったと思います。香港なまりの舌ッ足らずな発音はとても魅力的で、いまもそのスタイルを守られているのは、ファン層が分かっているのでしょうね。

私がアジアの音楽を原語で聞き出したのは10年近く前になるでしょうか。スカパーで中国や韓国(MNET)の音楽を聴いていました。当時の中国は返還された香港と市場が一つになり、レベルの高さを感じました。A-meiなどがお気に入りでした。

韓国は少し前の日本のアイドル歌手のようで、しかもライブはほぼすべて口パクなので、あまり良い印象派ありませんでした。

そんな中でBOAさんは別格でした。パンチのある音楽とダンス、少しなまった日本語も魅力的に感じました。しばらくして「Girls On Top (韓国盤) 」というアルバムが韓国で出ました。儒教社会の韓国での挑戦的なタイトルと言われたこの作品も、なかなかの作品だと思っています。

さて、最近だと少女時代とKARAが話題ですね。世間ではその容姿や、足をビョンビョンさせたり、お尻を振り振りするダンスが話題ですが、私はそれよりもあの音がたまりません。日本に進出していませんが、最近はT-ara にも注目しています。

少女時代の「少女時代 2集 - Oh!(韓国盤)」はかわいい感じの音があふれたアルバムです。話題曲の「Oh!」「Gee」「Genie」等が入っています。また、1970年代のアメリカ音楽を髣髴させる優しい曲も変化があって聞き飽きません。全体に「パピプペポ」系の音や拗促音が多く、なかなか良い感じです。

KARAの「KARA BEST 2007-2010 」は話題の「Mr.」「LUPIN」が入っています。パンチのあるBOAや軽快なABBAのようなイメージの曲が多いのです。その中にあって「Umbrella」はチョット変わっています。長い間、言葉の意味が分からず、雰囲気が違う事しか分かりませんでしたが、先日、光TVでプロモーションビデオをたまたま見かけたところ、プチモニのようなコミカルな歌でした。なるほどと言う感じです。

こんな風に意味の分からない歌を聴いて、色々感じたり、新しい発見をするのが楽しいと思っています。もし、Music Japan、M-ON、MTV、など音楽チャンネルが視聴可能なら、ぜひ、一度見られることをお勧めします。

なんか、音フェチおじさんの告白になってしまいました。

[#TiDD] チケット駆動開発とコーチング - SPI Japan 2010 -

SPI Japan 2010 でチケット駆動開発の発表をしてきました。SPI Japan 2010はその名の通りプロセス改善のシンポジウムです。現場発のプロセス改善として「チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェクトを変えた 」と題して発表してきました。

発表の後、コメントや質問でに必ずつくのが「同じようなことをしているんですけど」という前置きです。そうです。BTSのチケットでタスクを管理することは珍しいことではありません。また、構成管理ツールと連携するルール「No Ticket! No Comit!」を守っているなら、それはチケット駆動開発です。チケット駆動開発という呼称をつけることで、その知見を持ち寄ることができるのです。

今日は日帰りでしたが、SEA-SPINのセッションにも参加しました。そこでは、参加者の色々な経験などをネタにお話をしました。その中で、コーチングのお話しが出ました。コーチングでは、自己主張と感情の表出によって、プロモーター、コントローラ、サポータ、アナライザの4種類のタイプに分けられます。

良くある誤解はこのタイプを変えるというものですが、コーチングはそういうものではなく、それぞれのタイプにあった対応をするそうです。たとえば、一番気の弱いアナライザなら直接お話しするよりもメールでやり取りをするようです。

そこで気付いたのが私が今回発表したプロジェクトです。この発表の中で、「目が輝いた!」というサブリーダがこのアナライザだったのです。だからこそ、年長のビジネスパートナーに丸め込まれてうまく対処できなかったのです。そこに、チケットと言う作業指示の道具、しかもおじさんリーダ(私)が常に見てくれているので、鬼に金棒だったのです。

「なるほど!」と思いました。そしてふと気付いたのです。それは、

チケット駆動開発はこれまでは難しかった体制でもうまくいく可能性がある

ということです。これは、すごい発見かもしれません。

もう一つ、気付いてしまったことがあります。リーダは与えられたリソースで何とかこなすのが仕事だと何も考えていませんでしたが、そもそも体制が難しかったのですね。コーチングでは、このようなときに人の組み合わせを考えるそうです。工数や技術的には難しかったのですが、私がもっと間に入ればよかったのかもしれません。あるいは、もっと良い体制のための配員もあったかもしれませんね。

日帰り出張は大変でしたが、大きな収穫でした。

#懇親会では、チケットが多くて大変と言うお話しがありましたが、別の機会にまとめるつもりです。

[#TiDD] 二つのチケット駆動開発と「方法論」

Redmineによるタスクマネジメント実践技法 」がアマゾンで「なか見!検索」に対応したと思ったら、今度は初めてのレビューも載りました。ありがとうございます。「うまくまとまっていて読みやすかったけど」と評価していただきながらも

「ひとつの開発方法論というには、まだ未成熟ではないでしょうか。今後に期待します。」

とのことです。なかなか厳しいコメントですが、確かにそうだと思います。

この本に書いているチケット駆動開発には2つあります。

1.プラクティス
2.開発法

1のプラクティスは、既存のプロセスにチケット駆動開発を組み込むもので、補完型と呼んでいて、第一部で説明しています。

2の開発法はチケット駆動開発を中心とした開発法で完全型と呼び、第2部以降に書いています。必ずしもアジャイルに限らないと思いますが、この本では2部以降ににチケット駆動開発を中心としたアジャイル開発法を説明しています。

ご指摘の方法論としては、これからのところが色々あると思います。著者らの経験で色々言い切ると、方法論らしくなるのかもしれませんが、それは「No Ticket! No Commit!」というシンプルなルールを中心とするチケット駆動開発の良さをなくすように思います。

ここにわかりやすいKanbanとScrumの比較表が載っています(たぶん、こちらの資料がベースだと思います)。

これを見ていて気付いたのは、チケットはどちらにも利用できると言うことです。チケットは備忘録としての側面があり、とりあえず登録するほうがチケット駆動開発的ですが、マイルストーンやバージョンで区切ることでスプリント(イテレーション)を確定して、その間の集中を維持することもできます。

また、何でも登録できるからと言っても、それは容易に区別できます。tracだとチケットの種類、Redmineならトラッカーかカスタムフィールドなどによって、区別して表示することができます。

私の思うチケット駆動開発「方法論」は、そのような複数の選択肢とその良し悪しを示さなくてはならないと思っています。しかし、まだ議論や経験が不足しているので、これからに期待していただかなくてはいけません。

そこで、「プラクティス」あるいは「アジャイル『開発法』」として、細かな決め事でなく大切なことだけを載せています。初めてのチケット駆動開発の本である「 Redmineによるタスクマネジメント実践技法 」をきっかけに、多くの議論、経験を重ねて、いつかは方法論にできればと思っています。

ぜひ、皆様のレビュー・コメントをお願いします。

アジャイルプラクティスの副効果

アジャイル開発に対して様々な良さが語られていますが、従来型をベースにした開発をする中で、アジャイルプラクティスの直接的な目的や効果だけでは分からない良さがあることに気付きました。

1.繰り返しはコミュニケーションを良くする

繰り返しの中で、具体的な成果物が明確になるほか、外部環境の変化に対応してスコープを変更することで、変化に適応できると言われます。

また繰り返し開発の単位である、イテレーション(スクラムだとスプリント)と呼ばれる「タスクの集合」ごとにプロセス改善が進むと言われています。

もちろんこれらも重要な特徴ですが、同じメンバーで繰り返すことが別の効果を生むと思います。土屋さんがどこかのシンポジウムでこんなことを言われていました(詳細は自信ありません。すみません)。

  • 従来型の開発は課題にあわせて人を集めるイメージ
  • アジャイルは開発者がそこにいて、仕事が流れてくるイメージ

従来開発は文書により分業を進めて、実装の際には人を増員して一気に作ってしまいます。この増員が、コミュニケーションの負荷やロスを発生し、うまくいかなくなる可能性があります。

作業の遅れを取り返すために増員すると言うのは、良くあるデスマーチのパターンでしょう。ドキュメントによりコミュニケーションをはかる従来型開発においても、増員は慎重に行わないといけないのは、経験者なら誰もが実感していることでしょう。

ソフトウェア工学の研究においても、阪南大学の花川先生がメンバーの習熟や、メンバー間のコミュニケーションを考慮したシミュレータの開発などをされています。このように、配員・増員は難しいことであると言えると思います。

このように「繰り返し開発」には

「規模の増大によるコミュニケーションの無駄がない」

と言う副効果があると思います。これは、アジャイルが人を重視したプロセスであると言うこととつながっているのでしょう。

2.最適なペースの仕事は納得性を高める

XPエクストリーム・プログラミング入門」の初版では人としての豊かな生活や問題の早期発見等が書かれていますが、それ以外にも大切な効果があると思います。それは

「納得して作業を担当する」

ということです。担当作業に対するコミットメントはソフトウェア開発の重要な要素の一つです。しかし、作業の効率を考えると、できる人に負荷が集中しがちです。

TSPガイドブック:リーダー編 」にも「動的な再計画」(p.118)や「作業負荷のバランス」(p.120)が書かれています。しかし、目先の作業を早めにこなそうとしていたのに、また作業が増えるという感情を持ってしまうと、うまくいきません。お互いに協力できるような雰囲気を作るためにも、「最適なペースの仕事」は効果があると思います。

3.リーダーの仕事

分かっているけどアンチパターンにはまってしまいます。そのような現実から、混乱をどのように取り除くか、その実践がリーダの腕の見せ所なのでしょうね。

「ウォータフォールモデル」を超えた「エクストリームウォータフォール」 #agileto2010

Agile Tour Osaka 2010の長瀬さんの講演で印象的だったのは「エクストリームウォータフォール」という言葉でした。たぶん、ウォーターフォールモデルをベースにして「極めたプロセス」なのだと思います。

アジャイルとかウォータフォールの議論で「言葉の定義」の問題はウォータフォールにもあります。

元々、ウォータフォール(滝)と言うのはプロセスをモデル化したものです。モデルと言うのは、細かなところはそぎ落として主張したいところだけを単純化して示したものです。

ブルックスさんの「人月の神話」を読むと良く分かります。この本の中でブルックスさんは、「一つは捨石にするつもりで」と言うのは誤りだったとしています(P.256)。そして、ウォータフォールモデルでは各工程が1回だけであることを仮定していることが誤りで、漸増的モデルの方が優れているとしています。

これは間違いなくそうです。初期開発だけで終わるソフトウェアがほとんどなく、毎年のように保守という名のバージョンアップが繰り返されている現実からも、開発は一度だけで済むわけがありません。

この漸増的モデルは「アジャイル」を含みますが、アジャイル「だけ」ではありません。「1回だけ」という形だけを示したモデルに対応するのは「繰り返し」だからです。

この議論は明確で多くの人が賛同できるでしょう。モデルとモデルを、比較しているからです。

モデルでアジャイルと比較するなら、例えばスクラム本 の2段ループのモデルでなら明確な比較ができるでしょう。このモデルでは、全体の流れの中で、スプリントや日次スクラムを繰り返すことによって、「コミットメント」と「集中」が実現できるという議論ができると思います。

さて、長瀬さんの「エクストリームウォータフォール」は、モデルではなく日本式開発法と言うべきものです。問題点を示すための表現である「ウォータフォールモデル」をベースに、管理の強化によって問題を解決する日本式の開発法を示しておられるからです。

昔は「仕様の凍結」などという言葉があり、それが「ウォータフォールモデル」をベースにした際の前提でした。しかし、凍結は現実的でないので、ベースライン+変更管理が行われたのでした。ルーツは仕様の凍結ですから、変更が容易なわけはありません。

(このようなプロセスの特性はウォーターフォールモデルではないので、ベーム先生の本 では「規律(Discipline)」と呼んで、アジャイルの特性である「アジリティ(Agility)」とバランスをとるように提案したのでしょう。)

「エクストリームウォータフォール」は、1回だけの工程を成功させるためにわざと手戻りさせます。レビューや工程会議などで検査して問題が見つかれば、もう一度やり直しになって品質は向上するものの計画が遅れる方法です。手戻り工数をあらかじめ見積もることができれば計画通りに進む可能性はあるのですが、効率は良くないでしょう。

そのようなプロセスに、日本の企業がこだわる理由の一つは「品質」それも「信頼性」です。プロセスが計画的に行われるので、定量的な管理が可能になり、ソフトウェアの信頼性を飛躍的に向上できます。

講演の中で長瀬さんは日本に比較して欧米7割品質、中国3割品質と言われていましたが、実はもっと差があります。

先日亡くなられたハンフリーさんのTSPの本「ソフトウェアでビジネスに勝つ 」pp.75-76のテラダイン社のデータでは、最終システムテストとフィールド保守では、20欠陥/KLOCでしたが、TSPによって1欠陥/KLOCに改善したとあります。以前、秋山義博先生にうかがった時には、

「システムテスト後だと0.1欠陥/KLOC以下でないとはずかしい」

と言われていましたので、欧米は1割以下の品質ということになります。

長瀬さんが言われたように、そのような高信頼性を生み出していたのですから、アジャイルの導入が難しいと言うのはその通りなのでしょうね。

信頼性の低いソフトウェアは後々多大な被害をもたらします。しかし、実際のビジネスは変わりつつあります。ブルックスさんは利用者にとっての「扱いにくさ」を挙げていますが、信頼性以外のもの、使いやすさ、短納期、魅力的な機能などが求められたときに、ビジネスにならない可能性が出てきます。

では「エクストリームウォータフォール」で信頼性をほどほどに下げて、他の競争力を上げることができるかと言うと、なかなか難しい。そこで、アジャイルに目が向いていると思います。

長瀬さんはスクラムを言われていました。管理の視点が含まれているので、実際に多くの企業が使われているようです。

しかし、そのような動きに乗れないところで身を守るには「リーン開発 」と「チケット駆動開発 」ではないかと、とんでもプロジェクトの中でもがきつつ考えている今日この頃です。

« 2010年10月 | トップページ | 2010年12月 »