アジャイルジャパン仙台に参加して①

◇Keynote 1：「"Demand Technical Excellence" アジャイルにおける技術と品質の重要性」

James Grenning 氏

「アジャイルと品質」は気になっている問題だったので、是非聞いてみたいと思っていた。 Jamesさんは「テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶア>ジャイルな設計」の著者。

導入

アジャイル宣言から10年後。 Snowbirdに集まって、Debriefingを行った。そこで話したことで記憶に残っているのは2つのこと。

Technical Excellence
Promote Individual [change]

まず、アジャイルな開発者に必要なのは『技術的卓越性(Technical Excellence)』ということ。アジャイル開発の本だと暗黙の前提としてあまり書かれていないが、きちんと言ってくれて嬉しかった。

焼きなまし

アジャイルで一番重要なものはShippableコードということ。近頃だとHardening Sprints(焼きなまし)と呼ばれるバグ出しのスプリントを入れることがある。しかし時間通りには終わらずに燃える。そもそもバグをなくすことが重要。バグを追っかけることは技術的卓越性ではない！

最後にバグ出しの期間を取るわけだね。個人的なイメージだと、全てのフィーチャーが出揃った後にシステムテスト、シナリオテストを実施するのがいいと思うけど、ここでデグレが出すぎると炎上するんだろうなぁと思った。

スクラムとXPの結婚

技術を高めるということは、バグを出さないこと。スクラム、アジャイルで技術的な変化をしましたか？？この問題を解決するために"スクラムとXPの結婚"を提案したいとのこと。

開発者に質問してみたところ、コーディング、デバッギング、テスティングのうち、ある人は90％をデバッグとテストに使っている。デバッギング、テスティングは顧客にとっての価値を生み出さない。価値を出すのは新しい機能を実装すること。 printf、ステップ実行は1979年の技術今日でも見かけは変わってますが、同じ技術である。

おめでとう！！

これは"Debug Later Programming"じゃないか？

90%をデバッグに使っているのは厳しいなぁと思うが、大きな製品になるとこれくらいになるかも。

バグを入れて、しばらく後で見つかる。どのくらいで見つかるか分からない。バグ修正がバグを呼び出す。

バグはどこから来るの？？自分で入れたんでしょ？（Its our fault!)

テストを最後まで待つと最後に発見される。日本は品質を作りこむということを知っている。 BigWaterFallではバグを管理し始める。

XPはエンジニアリングの技術的なプラクティスの集合信頼性の高いソフトウェアが欲しいなら、最初からバグを作りこまないようにする。 TDDはダイクストラの方法を具体化したものだ。開発の流れを変えて、テストと開発を平行に行うようにする。これによって、開発とテストは欠>陥予防の連続体となる。 3分前のバグは簡単に見つけることができる。

バグの生存期間の話をしていたが、これは明らかに短いほうが良いと思っている。仕様書の場合はレビューで出したり、コードの場合はテストコードで出すのが短くする方法のひとつだと思う。テストを先に書くという概念は今は普通だけども、改めてすごいなぁと思った。これだとコードレベルのバグの生存期間は限りなく0になるもんなぁ。。。

開発とテストの比重

UnitTestは絶対に必要である。システムテストでは全てのパターンを試すことはできない。システムは変更されることを嫌がる。 25%のバグが、変更箇所以外の別のところが壊れたものという結果もある。

テストと開発の努力の比率は1:1のように思いがちだが、実際の比率は開発が進むにつれ、テストに比重を置かざるを得ない。2回目のスプリント>のテストは回帰試験も必要になってくるからである。このギャップが、このリスクがプロジェクトが炎上する理由になっている。

確かに・・・納得。ソフトウェアは共通化できるがゆえに思ってもいないところに影響がでることがあるんだよなぁ。アジャイルな開発だと回帰試験はどうなんだろうと思っていたのでJamesさんの話を聞いてスッキリした。

テスト書かない暇は無いんじゃないの？

テストを書く暇は無いっていうけど、バグを追いかける時間はあるでしょ？テスト書かない暇は無いんじゃないの？他のプログラマーが理解できるコードを書くのがスキルになる。

スパゲッティなコードではソフトウェアの価値がなくなる。ソフトウェア大切な価値の一つは「変えられること」

自分はソフトウェアの価値は変更容易性にあると思う。ただそれゆえに壊れやすいという特性も併せ持っている。日本はH/Wの品質管理を導入して、弱点を克服しようとしたがこれだと遅くなることが多い。1行の変更に1週間とかはザラだ。そうではなく、顧客の要求にギリギリまで対応できるというほうにフォーカスを当てていくべきなんだろうと思った。

アドバイス

Jamesさんからのアドバイス。

ものずくりのプロになれ(Become and expoert in your craft)

透明性を高めて信頼を築け(Build trust make your work visible)

新しい事に挑戦せよ(learn and try new things)

組織のアドバイザーになれ(become advisor)

マネージャーがモチベーションをさげるのは簡単で、絶対できない締め切りの設定、事実のみを責めたり、品質の低い仕事をさせる。

マネージャーのモチベーションを下げる方法は本当にあるあるで、もう黙って頷くしかなかった（笑

守備範囲を増やす

人は自分が知っている範囲で最善を行うので、チームのみんなが最新のプラクティスの知識を持っているようにする必要がある。そして自分の組織がその重要さを知っているようにする必要がある。

問題解決をするのであって、スクラムをすることが重要なのではない。スクラムマスターはモチベーションを下げるものを取り除いていく必要がある。チームに学ぶ活動を入れる。悪いものは積極的に見せて、チームで解決する。

知っている範囲で最善を尽くすっていうのはそうだよね。だから常に学んでいかないといけないわけだし、引き出しは多くないといけない。また問題解決もその通りで、自分の仕事はソフトウェアを作ることではなく、問題解決することが仕事だと思うようにしている。

平鍋さん「日本だからこそ品質を作りこむっていうのが重要」

自分の感想

いままでの本などでは聞けなかったアジャイル開発と品質についての話はめっちゃ面白かった。テスト、品質について勉強しているというのもあるけど、アジャイルでずっと気になっていたことが少しクリアになった。昨年は倉貫さんの話でアジャイルとお金の話がクリアになって、今年はアジャイルと品質の話がクリアになってちょっと嬉しい。

合わせてこれも読んでみたらめちゃ面白かった。組み込みアジャイルコーチ James Grenning さん突撃インタビュー

http://www.ogis-ri.co.jp/otc/hiroba/specials/JamesGrenning/interview1/

http://www.ogis-ri.co.jp/otc/hiroba/specials/JamesGrenning/interview2/