”アジャイル”をもう一度考えてみよう。(XP祭り関西2010)

XP祭り関西2010に参加してきた。


講演も面白かったし、以前からずっとお会いしたいと思っていた方々ともイベント終了後もじっくりとお話することができ、とても充実した一日でした。ありがとうございました。


しかし、イベントの内容に関してふりかえると、途中からかなり頭の中がもやもやと曇ってきた。
もやもやすることは、自分の考えの及んでいなかった領域を発見したということでもあるので、これをきっかけにいろいろと考えてみたい。

まず、私はこうしたアジャイルの実践事例を共有する場に行くと、発表者が思わず使ってしまう「勇気」とか、「信頼」「覚悟」などの、時・場面・人によってぶれのある言葉は、何か他の言葉に置き換えられないのかなあといつも考えてしまう。時には「愛」とか言ってしまう人もいるが、正直ジンマシンが出るほど苦手だ。

たとえば、「勇気」という言葉。
この言葉を使ってしまう理由もよくわかる。
「うまくいった!なんだろうこの感覚は。そうか、これが勇気か!」
この言葉は、経験した人だからしっくりくる言葉のはずだ。
残念ながら、この感覚を経験したことが無い人には理解が及ばない。
だから、「勇気を持って踏み出しましょう」って言っても、一番動いて欲しい人は動かないし、説得力も無い。
ドメインの言葉で、その意識を考えるべきではないか。
発表者には、自身の感覚の表現ではなく、聞き手の行動・思考を促すためのできるだけ具体的な話をして欲しい。


アジャイルは、ビジネス視点でシステム開発を考える性質上、避けては通れない「人」の問題にフォーカスするため、特にこうした話になりがちだ。

特に最近は、前後の話やその発言をした場の雰囲気も知らず、youtubeustreamslideshareなどでその部分だけを切り出して見てしまう事も多いので、「勇気」とか「信頼」のような、ぶれのある単語はかなり慎重に使いたい。
言葉だけを切り出して見た人が、精神論であるとか、宗教っぽさ(マイナスイメージな意味での)を感じるといわれても、反論の余地が無いだろう。


今回のXP祭りのテーマは、『アジャイルマインドを育もう』だった。

顧客のビジネス価値の最大化を目指す開発を行うには、メンバー全員が、アジャイルな考え方でプロジェクトに望まなければならない。(言い換えると、ビジネス価値を引き上げるための開発ができているプロジェクトは、往々にしてアジャイルなプロジェクトになっている。)つまり、プロジェクトメンバー全員でアジャイルを心がけることができていれば、良い開発ができるはずである。『アジャイルマインド』を育めば、プロジェクト、顧客、会社、さらには、業界が良い方向に導かれる。
では、その過程はどうするのか。私の現場ではどうやって取り組めばいいのか、何を考えれば良いのか。または、何かヒントは。これを探求し、知ったことや考えたことを共有したい。
これが、私のイベントの期待であり、可能性だった。

しかし、今回のイベントの流れでは、そのまま文字で表しただけでは、おそらく参加者によって認識がまちまちであると思われる『アジャイルマインド』とは何か、その先にあるものは何か、について一切共有することなく、一方通行で話が進んだ。
このズレは、パネルディスカッションで表面化し、私の中でもやもや感として現れた。

上記の期待・可能性を示した通り、『アジャイルマインド』は大切だ。それに、それぞれの発表がいい話だっただけに、ちょっともったいなかったのかも、と思った。


今回の件でも再認識したのだが、アジャイルの重要性や効果を端的にアウトプットするのは難しい。
だからといって、安易に何かに例えたり(メタファーとか言って誤魔化されることが多いので、安易にそっちに逃げる。)しては、場合によっては余計に不正確に伝えてしまいかねない。
時間がかかって面倒なことかもしれないが、現場(職場)、場面によって、誇張することなく、確実に言葉を探して伝えるべきだ。

考える事。
こうしたもやもやを感じたら、考えて、少しでもいいので、正確に伝えることを積み重ねていかないといけない。


アジャイルについてもう一度考えよう。

XP祭り2009

祭り2週目。
充実した内容のセッション、終わった後の焼肉と、おなかいっぱいの一日でした。

基調講演

平鍋さん、木下さんによるAgile2008レポート。
気になったポイントのメモ。

「AgileUX(User Experience)」

Agile2008の印象的キーワード。
ユーザーからのフィードバックが無ければよいものは作れない。
UXを実現する開発手法として、Agileは非常にマッチする。
UserExperienceセッションでは、アイデア,意見を貼るかんばん。色使いなど、工夫している。
イベント自体のUIにこだわっている。

  • 絵葉書によるセッション誘導
  • フィードバックかんばん
ベンチャーが積極的にAgileに取り組んでいる。
Kanbanブーム
  • Scrum板など。記事紹介なども増えている。
  • かんばんの本来の意義に回帰。
    • 後工程で必要になったら、タスクを引っ張ってくる。pullで使う。WIPを最小限に。
    • Doneがはけないと、Doingに入れてはいけない運用の紹介など。
思ったこと

CE Linux ForumでLinuxイベントのレポートを聞いていても感じることだが、
海外のイベントは参加者全体の一体感がすごいなと思う。
Linuxなら、カンファレンスなどの議論がきっかけでカーネルの技術革新が起こるし、
Agileもその場にいた人が現場を変える。
イベントに参加した人全員で、業界を動かしている。
一回行ってみたいなぁ。

最後の質疑応答

以下、個人的な感想です。

  • 「プロジェクトの成功の定義が違う」
    • 契約・期間を最初にしっかり決めて進めるような開発スタイルが一般的な日本では、顧客とゴール・価値を共有して進めていくという、Agileのスタイルとの発想の転換をすぐに伝えるのが難しいと感じた。Agileをただの開発プロセスのひとつという領域で見ているうちは、前に進まない。何故、Agileをやるのかということを、しっかりと伝えていきたい。
  • Agileのプラクティスには、エンジニアがすぐに効果を感じ取れるものが多い。とにかくやってみる。現場から伝えていくアプローチも同時に進めていくのが、我々の役割。

PF入門ワークショップ(PFP)

  • 田村さんのPF解説中に、平鍋さんが見学に。平鍋さんの前でPFについて説明するという、すごい状況に。やっぱ緊張したのかな。
  • PF体験ワーク。
    • ソフトウェア開発の変わりに、チームでトランプを並べるというゲームをする。朝会、KPTによるふりかえり、ニコカレでチームの生産性を向上させ、ゲームのスコアをあげていく。
    • 僕もいち参加者としてワークに参加しました。ゲームはシンプルなだけにすごい熱くなる。KPTでふりかえりしていても、活発な意見が出てきた。短時間だったが、ワーク終了後は、チームで一体感も感じられた。PF入門の目的だけじゃなく、このワークをやるとチームワークが強まるかもしれない。実際の開発チームでもやってみると面白そう。
    • ふりかえりでは、参加者とのディスカッションも盛り上がった。PFを導入するということではなく、私たちは現場でどういったことができるか?という前向きの意見が多かった。

PFP関西のワークショップでも、こういった意見交換をもっと積極的にやっていきたいと思いました。


終わった後

公式の懇親会の後、荷物運び用のランエボで、数人と大阪市方面へ。一人が「ラーメンを食いたい」とか言い出したので、おいしいテールラーメンが食べれる焼肉屋さんへ。ラーメンどころか、がっつり焼肉食べてました。
おなかいっぱいです。