アジャイルと現在の自分と品質について考えた@xp祭り2010

2010/09/04(土)にxp祭りに参加してきました。
前年に比べて多くの人達が参加しており、その大半が初参加者のようでした。
そんな事実が、再び注目されつつあるxpおよびアジャイルへの関心の高さをうかがわせました。

講演もテストの話あり、UXの話あり、開発の話あり、と多彩。
形式も講演形式あり、ワークショップ形式あり、読書会もあり、と多彩。
まさに、「学園祭」をテーマとした今回のxp祭りにふさわしい多彩ぶりでとても楽しかったです。

平鍋健児さんの講演は、そうした初参加者の多さを意識したかのように、xpやScrumを中心としたアジャイルの過去から現在までを総括した内容でした。
http://www.slideshare.net/hiranabe/now-past-and-future-of-agile-development-and-xp

特に私が共感をしたのは、
Agile – Scrum = Craftsmanship
Agile – Scrum = Engineering Practices
のお話でした。

私が話を聞いた範囲では、いままでアジャイルは「人」の文脈で語られることが非常に多いと感じていました。
たとえば、プロジェクトファシリテーションやかんばんなどのマネジメントを中心とした話題が活発に議論されているように思えます。
それは今まで人を軽視していた業界の反発によるのかもしれません。
また、技術を知らない人でも語りやすい部分であるからなのかもしれません。
この観点が重要ではない、とはいいませんが、私が今まで講演などで聞いていた話は、技術的要素が抜け落ちていたように思えるのです。

私の情報網が狭すぎるだけかもしれませんが、アジャイルおいては、技術的卓越、という価値がありながらも、

技術力の優れたエンジニアが不可欠である

という事実をおおっぴらに言う人に出会ったことがありません。

平鍋さんがしめした上述の式は、まさにそれに言及しているものであると私は感じました。
すなわち、システム開発の現場がアジャイルであるためには、高い技術力が不可欠である、という事実に言及したものではないか、と思うのです。

このように感じるのは、最近、私自身が、アジャイルを標榜する現場に入ったことも無関係ではないと思います。
汎用機の世界から入った私は、自身のwebアプリケーションの構築の経験や知識、常識のなさに苦労しています。
そして、そんな私の穴埋めをして、今の現場を支えている人は間違いなく優れた技術力をもち、多くの現場経験をもつ人たちです。
現在のこのような経験が、むしろ、アジャイルはこうした人達が、のびのびと働き、しっかりと評価されるための思想であり、プロセスなのだ、ということ再認識しています。
こうしたことによって、自分に都合よく上述の式を解釈しているのだろうと思います。

個人的には、

口だけのアジャイルではなく、行動と発言の背骨となる技術力を養ように!

と言われたと思っています。
今の自分をばっさり切られたようで、気持ちが良かったです。

また、招待講演の細谷泰夫さんのアジャイルにおけるテストについてのお話は、まさに今の関心ごとと重なる内容で、たくさんの示唆を得ることができました。
細谷さんがお話で印象に残っている点は、

・コンテキストを共有する重要さ
・テスト自体を開発するというテスト開発の有用性
・品質を確定することの難しさ

です。

コンテキスト、とは、テストに限らず、そのものが行われる背景や状況のようなものです。
たとえば、新規開発の案件なのか、それとも保守開発の案件なのか、によって、設計や開発、テストの考え方も取るべき方法も異なります。
新規開発では、要件も仕様も「未知」の部分が多く、その点を検証したり、作り上げること時間がさかれます。
保守開発では、既知の部分が多く、その点を意識して、新たな要素が既存の機能が阻害しないか、などの点に時間をさくことが多くなります。

このように、コンテキストは、「システム開発」とひとくくりにできない要素を開発現場に与えるものなのです。
ですので、プロジェクトのメンバーが、プロジェクト自体のコンテキストをしっかりと共有していないといけません。
もしも、コンテキストが共有されていなければ、とるべき手段も目指すべき価値も異なってしまうからです。
逆にプロジェクトのメンバーが、コンテキストを共有していれば、どのように振舞うべきかを悩んだりすることも少なくなるでしょうし、メンバーの振る舞いがプロジェクトの目的にかなっているので行動もたらす効果も高まることになるのです。

またテスト開発とは、テストそのものもイテレーションごとに成長させ、拡張しようという考え方です。
この方法では、「品質を確定する」テストをプロジェクトに設けます。
「品質を確定する」というテストの実施のタイミングは、複数回あるリリースの前や1度きりの最終納品の前かもしれません。

一方、イテレーション内で行うテストは、「品質を確定する」テストの情報収集のような意味合いも含むようになります。
もちろん、イテレーション内のテストも目的を持って行います。
たとえば、プログラムの構造を網羅的にチェックするためにTDDに加えて単体テストを行ったり、ユースケース単位や業務シナリオ単位に想定した流れで処理が行えるかを確認するために結合テストを行ったりすることが考えられます。
イテレーション内のテストが目的を持ってしっかり行われるという点は、「テスト開発」というアプローチでも一緒です。

異なる点は、こうしたテストをシステムにたいする情報集取の機会であり、「品質を確定する」テストを開発するための学習の機会と捉えることです。
イテレーション内でおこなうテストは、実施する観点からのシステムの品質を確かめる、という目的がある一方で、

・ここのモジュールや機能にバグが多く発生した
・この観点からのテストが不足していた

などの実践を通じた学びをもたらします。
こうした学びを活かし、「品質を確定するテスト」を拡張、洗練させようとすること、これがテスト開発の考え方なのです。

アジャイルに開発を進めていると、ふとシステム全体での品質について「これ大丈夫だろうか」と不安を覚えることがあります。
テスト開発、というアプローチは、このような不安を解消し、システム全体の品質を確認するために、効果的に働くことが期待できるのです。

最後に、「品質を確定することは難しい」という点です。
じつは、品質を確定することは難しい、というのは、細谷さんがおっしゃった言葉ではなく、私が講演を聴いていて感じたことです。

細谷さんのお話のなかで示されていたのは、「目標とすべき品質が定まっている」こと、「システムの全体像が定まっている」こと、そして、それらが「プロジェクト全体で共有されている」ことの重要さです。
しかし、私自身、現在、これらのことが重要であり、同時に難しいと感じていることでもあるのです。

アジャイルでは、短いイテレーションのなかで目の前の物事に集中します。
このため、プロジェクトの大局やシステムの全体像を見失いがちでもあります。
また、全体像が決まっていないものが作れる、という誤解をお客様がもつかもしれません。
プロジェクトが大きくなり、関係者も増えてくるとコンテクストを共用するだけも相当な労力が必要になります。

この点をどのように解決するべきなのでしょうか。

XP祭りの講演を聴いていて、答えとなりそうなものをいくつか思いついたのですが、まだ確信はありません。
これ以上は長くなりそうなので、また今度の機会にまとめてみようと思います。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

広告

タグ:

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。