Archive for 2010年9月

一体感のある場づくりの難しさを感じた@愛知トリエンナーレ

9月 23, 2010

一体感のある場を作るのは難しいものです。
大人になればなるほど、それは難しくなるように感じます。

たとえば、小学校の頃の運動会。
おそらく大半の人は文句を言いながらも、ダンスや行進の練習を素直にしていました。

ですが、高校生の文化祭となると、もうダメです。
なんとなく反抗心を抱く人や自分でやりたいことが出てきた人たち、彼や彼女たちには参加を強要できません。

社会人となり、仕事の場となるとさらに複雑です。
家庭を持つ人、仕事以外にやりがいを求めて活動している人、こうした人たちに業務を命令することはできます。
しかし、納得して活動してもらうことはできません。

愛知トリエンナーレの会場、名古屋の街中で感じたのはそんな雰囲気でした。
1つ1つの会場は確かに盛り上がっているのですが、「名古屋」という街全体ではそれほど盛り上がっていないような雰囲気だったのです。

会の運営方法が悪い、と言いたいのではありません。
会場の運営に携わっているボランティアの方々が街中におり、質問をすれば丁寧な対応をしてくれます。
名古屋の街に点在している会場にも人と活気が溢れていました。


しかし、会場から一歩、足を踏み出して街中へでてしまうと、活気も消えてしまうのです。
せっかく会場で味わった雰囲気の余韻も、次の会場へ向かうまでに完全に消えてしまうのです。

1つ1つの場はしっかりとしているのに、それぞれがつながりがない。
これは、1つ1つの場が盛り上がっているからこそ、とてももったいないことだと思います。

一体感のある場にいることは、とても楽しいことです。
ただ、すべての人達がその場に参加し、一体感を得ることはできません。
というのは、そもそも活動自体があることを知らないという人もいますし、知っていても興味がわかない、という人もいるからです。

どのような場にも、その場に参加できず、一体感をもてない人達がいます。
問題は、その人達をなくすことではなく、参加意識の高い人達の一体感が、その人たちを上回れるか、ということです。
愛知トリエンナーレの会場である名古屋市内では、いまはまだそのような状態になかったのだ、と思います。

街中の至る所にアートを配置し、それによって場の一体感が醸成されると考えられたかもしれません。

しかし、それ以上に街中で目についたのは、アートに興味がない人たちです。
興味がない人たちが邪魔だ、と言いたいのではありません。
むしろ興味のない人達にとっては、アートのイベントこそが邪魔で迷惑だったのではないか、と思うのです。

そして、そんな空気を感じてアートを見ている人たちも、ちょっと冷めてしまう、という感じ。
お互いに不幸な関係があったように思います。

境界を取り払ってものごとを行ない、周囲を巻き込み、共感を得ることで場の一体感は生まれることもあるでしょう。
でも、それはとても難しいことです。

愛知トリエンナーレというイベントは、その難しい場づくりに挑戦したイベントだと思います。
ただ、まだ時期尚早、アートと生活の場に境界を設けて、イベント開催したほうが良かったのではないかと思います。
そのほうが少なからず、アート目的に集まった人たちは、場の一体感を感じて盛り上がることができたのではないでしょうか。

いろいろ文句を書きつらねてきましたが、愛知トリエンナーレというイベントに行けたことにはとても満足しています。
とくに、オペラの『ホフマン物語』の豪華な舞台装置とオーケストラの演奏は、素晴らしい、の一言でした。
オペラは初めて鑑賞しましたが、とても楽しかったです。

なにより、暑いなか沢山のボランティアの人々と各会場の来場者の熱気は、日常的に開催される現代アートの展覧会と比較にならないものでした。
このような熱がトリエンナーレが終了しても続けば、次回はもっと街中にアートな雰囲気があふれた良いイベントになるかもしれません。

広告

勉強会よりもブログと実業務

9月 21, 2010

私の周辺では、勉強会が盛んに行われています。
私も参加しますし、一部ではスタッフとして活動してもいます。
しかし、最近は仕事の場が変わった都合もあるのですが、参加の頻度は少なくなっています。
おそらく、勉強会に参加することだけに、それほどの価値を感じることがなくなったからだと思います。

勉強会自体は価値のあるものですし、楽しいものです。
日々の問題意識や悩みが相談でき、問題が解決できたり、悩みが解消できたりします。
会社や業種の枠を超えて、問題意識や興味に共通点がある人々が集まれる場は素晴らしいものです。

しかし、単に勉強会に参加すること、情報をインプットすることには意味がほとんどありません。
情報をインプットすることの価値は、良質なアウトプットにより支えられているからです。
極論をいってしまえば、良質なアウトプットが可能であればインプットする必要がないのです。
良質なアウトプットがないのであればインプットには価値はありません。

ですので、最近は「興味がある」というだけで勉強会に行くことを改めるようにしました。
そのかわりに、ブログを書いたり仕事で使えそうな情報をまとめたりしています。

勉強会に初めて参加するときの緊張感は今でも忘れることはできません。
いつも参加している人たちが仲良さげに話している「身内感」のある空間にいる気まずさなどは忘れがたいものがあります。
ですので、勉強会へ参加すること自体に抵抗感をなくすために「興味があるものに手当たりしだい参加する」という行動は必要だと思います。

しかし、勉強会へ参加することに慣れたと思ったら参加回数を減らして、インプットした情報をどのようにアウトプットするか、を考える必要があると思います。
たぶん、今の私はその段階なのだと思います。

そのため、最近は、
・実業務に直結する
・勉強会のスタッフとして活動できる
・ブログを書くネタになる
などを軸に勉強会へ参加し、アウトプットにつながるインプットを心がけています。

勉強そのものは決してわるいものではありません。
しかし、それそのものだけでは決して良いものでもないのです。
ですから、勉強会に参加することの価値をよく考える必要があります。
自分がその情報をインプットすることで、どのようなアウトプットが可能か、を問う必要があります。

また、「実業務での学びはないのか」を問う必要があります。
もしも、実業務での学びがなく、仕事を早く切り上げて勉強会に参加することがつづくのであれば事態は深刻かもしれません。
もっと学びを増やせ、という合図であり、必ずしも、もっと勉強会へでろ、という合図でなく、職場を変えろ、という合図かもしれないからです。

アウトプットの質を上げるには、インプットが不可欠であり、その場として勉強会は価値があります。
しかし、実業務などのアウトプットを行うことに勝る勉強の場はなく、その穴埋めをできるほど勉強会は優れた場ではない、のです。

そして、私にとってのアウトプットの場は、このブログと実際の仕事だと思っています。
ですので、勉強会よりもブログと実業務、と最近は強く思うのです。

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

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

9月 5, 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祭りの講演を聴いていて、答えとなりそうなものをいくつか思いついたのですが、まだ確信はありません。
これ以上は長くなりそうなので、また今度の機会にまとめてみようと思います。

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

顧客価値にたいする見積りの意義

9月 3, 2010

顧客価値とはなんでしょうか。
また、顧客価値をどのように知ることができるでしょうか。
本当にお客様の役に立っている、という状態はどのような状態でしょうか。
これらを突き詰めて考えると、意外と答えることが難しいことに気づきます。
たとえば、「満足した!」とお客様に言ってもらえれば嬉しいですが、それが事実であるかはやはりわからないでしょう。
顧客価値のあるプロダクトを創り上げる、というのは、ある種の観念論であり、

これだけのことをやったから価値のあるものを届けたはずだ

という信念に基づくものではないかと、私は思っています。
では、自信をもって「顧客価値の高い仕事ができた」というには、どのようにすればよいでしょう。
そのためにはむしろ、顧客価値の高い仕事を定義するのではなく、反対の状態について考えてみるのも、良い方法かもしれません。
すなわち、どのようなことを行うと顧客価値を損ない、お客様から信頼を失うことになるのか、ということです。
アンチパターンと言って良いかわかりませんが、それらの行為を避けることで、「顧客価値を高める」ことはできなくても、下がることを防ぐことができるはずです。

お客様の信頼を失い、顧客価値を下げるような行為や状態は以下のようなものが考えられます。

・ストーリーが終わらない事態が頻発
・顧客が価値の高いと思っているストーリーが終わらない
・ストーリーが完了して出荷可能なはずものが出荷できない

こうしたことが起こる原因は様々考えられるのですが、防ぐ手段というのはあるのでしょうか。

防ぐ手段の1つとしては、しっかりと見積りを行う、ことが挙げられます。

ストーリーにたいする見積りが甘いと、チームはお客様、Scrumでいうプロダクトオーナーとの約束を果たすことできなくなります。
特に「今回のイテレーションでは~までやります!」と宣言していたにもかかわらず、終わらなかった、という状態はお客様に不信感を抱かせます。
まだそれが、時々であればまだましなのですが、頻発するとお客様からの信頼は地に堕ちるでしょう。
なにより、恐ろしいのは、開発チーム自身がその状態に危機感をいだきながらも慣れてしまうことです。
コミットが守れないことが常態化すると、その状態をマズイなと思いながらも、抜け出すための行動をとらないことになってしまうのです。

では、しっかりと見積りを行う、というのはどのようなことを指すのでしょうか。
この観点の一つとして、精度の高い見積りを行なうこと、が挙げられます。

通常、見積りは人工(にんく)でもなければ、時間でもない単位であるポイントで行われます。
そのため、「正確に」という意識が働きづらいかもしれません。
なんとなくの感覚でポイントを出したり、特に知識のない領域にたいしては詳しい人の意見にあわせてしまったり、という根拠なく見積りをおこなってしまいがちです。

しかしながら、見積り時に「正確さ」を意識することは重要です。
知識がない、という点については、メンバー全員がもっていないのであれば仕方ないですが、詳しいメンバーがチームにいるのであれば理解、納得できずに簡単に同意するのは危険です。
というのは、正確な見積りの恩恵は作業量が正確に予測することに加え、仕様の詳細を洗い出すことだからです。

見積りという作業が予測である以上、当たるほうが良いことは言うまでもありません。
が、正確に見積もろうすれば、「このストーリーではいったい何をしなければならないのだろう」という問が無意識のうちに頭のなかで起こります。
この疑問に大きな価値があるのです。

「何をしなければわからない」、「どれだけの作業量があるか」「どのような専門知識が必要か」ということがわからなければ、そのストーリーの大きさはわかりません。
そして、もしもこの点を放置してしまうとその見積りは著しく精度を欠きます。
また、やるべきことが明確でないので、「なにが起こるかわからない」という意識から、お客様へのコミットに自信を持つことができないのです。

こうした理由から疑問は生じるのですが、生じた疑問はお客様の要望を洗い出し、開発チームと意識をあわせることにも役立つのです。
というのは、この疑問から「どのストーリーを達成するべきか」「どのようにストーリーを達成するのか」という具体的な方法へ思考が向かいます。
この過程に、お客様が「本当に何を望んでいるのか」が具体的になる機会があるのです。
抽象的な思いが現実に向かって具体化されるとき、必ず「制約」が現れます。
この「制約」こそが、お客様の思いと思考を「なにをすべきか」から「なにができるか」へ向かわせます。
そして、「なにができるか」という問いが、お客様と開発チームの双方で起こることこそが、思いを具体化するきっかけとなるのです。

見積りを通じてストーリーをタスクに落としこむときに、お客様も開発チームも、新たに「実現可能な価値」を問うことができるようになるのです。
そして、そのストーリーの価値について真剣に悩むことができるのです。
このため、どのストーリーの優先順位が高く、そのイテレーションではどのストーリーを行なうか、を決めるときにはもちろん、そのストーリーの見積りを行う際には、なるべくお客様の近くにいて話が聞ける状態でないといけません。

しっかりと見積りを行なう、という行為には、予測、という目的があります。
そして、その予測という行為のなかには、来るべき未来の行動の洗い出しがあります。
この点において、「どのようにストーリーを実現化するのか」という問いが発生します。
この問いこそが、じつはお客様との会話を発生させ、雲と掴むがごとき存在の「顧客価値」について考える機会であり、お客様と認識を合わせる機会でもあるのです。

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