「アジャイル インスペクション ワークショップ in 関西」に参加。

12月3日、XPJUG関西主催のイベント「アジャイル　インスペクション　ワークショップin関西」に参加した。

司会はソニー株式会社の永田敦さん。

正直、インスペクションという言葉は知っていたが、正確な意味は理解できていなかった。「インスペクション」がどういうものであるか、アジャイルインスペクションがどの様な方法なのかを知るために、イベントへの参加を決意した。

ちなみに、インスペクションについては以下wikiの引用を参照頂きたい。

■インスペクション

インスペクションとは、ソフトウェア開発プロジェクトで作成された成果物（仕様書やプログラムなど）を、実際に動作させることなく人間の目で見て検証する作業を言う。

様々な会社や団体で言葉は違うものであるが、僕の場合、上記の行為を「レビュー」と呼んでいた。

「人間の目で検証する作業」を有意に実行するためには、時間がかかる。時間を掛けずに実行したととしても、無意味にしかならない。

「アジャイルインスペクション」とは、時間の掛かるインスペクションを、短時間で効率的かつ効果的に実践するための手法である。簡単にまとめると、下記内容となる。

---

１．レビュー対象物作成期間中、一定期間でレビューする。

２．レビューは、下記レビュープロセスを繰り返し実行する。

　２．１．サンプリング

　２．２．インスペクション

　　　　ａ）１枚１５分ペースで実施

　　　　ｂ）5つの観点　「曖昧」「不明確」「矛盾」「設計要素」「重要な欠陥」

　２．３．評価　→　欠陥の種類と数を集計し、合否判定する

　２．４．ロギング

　２．５．修正

---

注目すべきは、「すべての成果物をレビューしない」と宣言している点。成果物の中のいくつかをサンプリングし、濃密にインスペクションを実施する。最初は問題だらけでも、指摘結果を開発チームへフィードバックすることで、段々指摘件数が減るという。

これは、「小さく繰り返して開発」を基本とするアジャイル開発プロセスにとても類似している。

僕は今まで、ここまでシンプルで効果的な「レビューの観点」にお目にかかった事がない。素晴らしいレビュープロセスとレビューの観点を知ることができ、非常に有意義な内容であった。

ニュースサイトを立ち上げた。

最近、「アジャイル」関連の情報が活発に発信されるようになり、とても嬉しい状況になりつつある。

そんな中、アジャイル系の情報をまとめたサイトが無いなぁと思い、一念発起して作ってみました。

■アジャイル ニュース フラッシュ

このサイトの製作に、「ZuQ9->Nn To 辛周(ズキューンとからまわり)」の中の人の絶大な強力を頂きました。この場をお借りしてお礼を申し上げます。ありがとうございます。

気がついた情報をどんどんアップしていきたいと思います。

アジャイル検定

先日参加したAgileTourOsaka2010にて配布されていたチラシに、「アジャイル検定」という言葉が書かれていたので、挑戦してみた。

アジャイル検定試験

設問は、XPに寄った問題が多く出題されていた。その他、「アジャイル開発宣言」に関する問題も含まれていた。アジャイル開発を熟知していれば、合格はそんなに難しく無いように感じた。

得点は83点。１００点取る自信はあったのだが、少々残念。どの問題を間違えたのだろうか。

合格すると、認定証が送られてくるので、腕試しに挑戦してみてはいかがだろうか。

AgileTourOsaka2010無事終了

2010/10/30、「AgileTourOsaka2010」が開催された。

本イベントにご参加頂いた、登壇者、参加者、スタッフの皆様、お疲れ様でした。そして、ありがとうございました。

「AgileTour」とは、世界規模で開催されるアジャイル系イベントで、今年で３周年を迎える。

日本は、今年初開催となる。

今回、ありがたい事に、この記念すべき一大イベントにスタッフとして参加することができた。

開催当日、台風が大阪に再接近することが判明し、中止か開催かでスタッフ間で意見が分かれたが、フタを開けてみると、台風どころか雨すら降っておらず、スタッフ全員で安堵の溜息をついた。

当日の模様は、こちらに詳細が記載されている。



■満員御礼！
開催日の約１ヶ月前から定員枠100名で参加募集を開始した所、わずか３週間で満員御礼となった。しかも、キャンセル待ちの問い合わせも多数頂き、開催前日までキャンセル待ちの対応に追われる程人気の高いイベントとなった。



■スタッフ視点から観た「AgileTourOsaka2010」

「AgileTour」名に恥じず、「アジャイル」に対する一家言を持つ方々をスピーカー陣を向かえ、素晴らしいイベントになったと自負している。また、参加率も80％を超えており、大盛況となった。

そして、最も特筆すべき点は、「イベントといえば東京」というIT系の常識を覆し、関西で初めて「AgileTour」に参加したという点。

それを強く感じたのは、「特定の発表のみ聞いて帰る参加者が居た」事。
地方から東京へ参加する事は、交通費や移動時間に拘束され、とても敷居が高いものになってしまう。しかし、電車で３０分～１時間圏内であれば、敷居がグッと下がり、一部だけでも参加が可能になる。地元民にとっては、非常にありがたいことである。

「これから仕事なんです。」

そういって帰って行かれた方にとって大阪での開催は、有意義であったに違いない、と確信している。


■時代がやっと追いついた
近年、「アジャイル２．０」というキーワードをwebや書籍で目にするようになった。

日本で第１次アジャイルブームが巻き起こったのは、２０００年頃。今から１０年ほど前になる。
当時は、アジャイルの勘違い（ドキュメントは書かない、ペアプロは工数が２倍かかる、等々）により、多くのプロジェクトが失敗したらしく、一向に流行しなかったと伝え聞く。それが今ではＩＢＭ、マイクロソフト、東芝などの大手企業がこぞって「アジャイル」というキーワードを持ち出し始めた。これは、「時代が追いついてきた」と言えるのではないだろうか。

僕は、日本における「アジャイル２．０」のきっかけは、上記の大企業の宣伝効果よりも、コミュニティやアジャイル先駆者達が、書籍、セミナー、ワークショップ、ブログ、メーリングリスト、果ては飲み会の席上で、根気強く草の根活動を継続実施し続けてきた結果であると確信している。

僕自身、アジャイルには、開発者を魅了して止まない魅力があることを知っていて、それがようやく世間に広まってきたのではないか、と想像している。



■真の「アジャイル２．０」とは？
イベントを通じて痛感した事は、「まだまだ新しい人が少ない」という事。

あきぴーさんを除く登壇者の方すべて、２０００年頃に日本でアジャイルがブームとなった時期に活躍されていた方々である。

僕は、次世代の方々が、もっと表舞台に出て活躍されてこそ、真の「アジャイル２．０の到来」といえると考えている。

今、日本では「アジャイル２．０」というキーワードが流行している様であるが、一時的なブームで終わってしまう気がしてならない。

「単体テストはＴＤＤ、ピアレビューはペアプログラミング、開発スタイルは繰り返し型　であれば、アジャイルだ」と勘違いされてしまわないかと懸念している。

「アジャイル開発宣言」の意味が腑に落ち、その根底を理解し、世に発信する人々が続々と出現してきた時が、真の「アジャイル２．０」になるような気がしてならない。

■次の１０年へ向けて

真の「アジャイル開発手法」が定着し、一般的な開発手法の一つとなった時、どんな未来が待っているのだろうか。その時、「ポスト・アジャイル」となるような、画期的プロセスが生まれているのだろうか。

次の１０年は、アジャイル開発手法を超える新しい開発プロセスが必要となるはずである。それの手法を日本が発信できれば、こんなに素晴らしいことはない。

来るべき次の１０年に向けて、「アジャイル」を超えた開発手法を空想するのも、楽しいのではないだろうか。

PFP関西ワークショップ#24に参加。

昨日、PFP関西ワークショップ#24　「Scrumからみたプロジェクトファシリテーション　～どうつながって、どう活用するの？」に参加した。


「すくすくスクラム」で有名な　江端さん（ebackyさん）がスペシャルゲストでいらっしゃるとの事。無料でスクラムの体験ができるとあって、これを外す訳にはいかない。しかし、諸事情で大遅刻をしてしまい、グループワーク途中から参加する形となってしまった。




■グループワーク
前半は、アジャタボールの説明　兼　体験。
後半は、ebackyさん主導の元、スクラムの触り部分を体験。


グループワークは、人数の関係上、僕と後輩の二人で実施することとなった。二人だけということで、後輩にスクラムをじっくり伝える良い機会になった。


２分というタイムボックスで与えられた課題をこなし、自然にスクラムのプラクティスを参加者に実践させる様は、まさにプロの領域である。


ebackyさんの講義内容は、いつも参加者に疑問を投げかける。
今回も、たくさんの疑問を参加者に投げかけられた。
この問いをどう判断し、どう行動するか。それはすべて参加者にゆだねられている。


■ワークショップ終了
グループワークは非常に活発で、終始笑い声に溢れていた。
参加者の皆さんが、有意義な時間を過ごせた証拠である。
途中参加ではあったが、楽しくかつ有意義な時間を過ごすことができた。




■最後に

次回ワークショップは、２５回と切り番となる。
きっと、なにか大きなイベントを企画するはずである。
いまから楽しみで仕方がない。

PFP関西ワークショップ#23に参加。

昨日、PFP関西ワークショップ#23「円滑なコミュニケーションの為にできること、みんなで考えよう！」に参加した。


■事例発表
会社の後輩に事例発表をして頂くのが最大の狙い。
実は、今年の2月、今の会社で部署移動があり、そこで出会った二人の悩める後輩にKPTを実践した経緯があり、その集大成として発表してもらおうと考えていた。
社内で1度リハーサルを行っただけなのに、スラスラと発表する後輩を、とても頼もしく感じた。


発表時間が1人5分しかなく、肝心のKTPで実施した内容を発表することができず、参加者からKPTについて質問攻めに遭っていた。しかし、参加者から質問を頂くということは、参加者の興味を惹きつけたからだと言える。そういう意味では大成功であった。


■グループワーク
今回、初めて「アジャタ」を体験した。
印象は、ワールドカフェ＋KJ法＋マイドマップ　という表現が近い。
１つの大きな模造紙に、絵と文章を各自が書き込み（アジャタボール）、最後に結論を中央に書き込む（アンカーボール）。


絵と文字を使う事で脳を刺激して活性化させ、他のメンバーからのアイディアで更に脳を活性化する。脳の活性化と、発散＆収束がセットになった秀逸な手法であると言える。


メイン司会を勤めて頂いた北野さん。初めてとは思えないくらい堂々とされていたのが印象的だった。


アイスブレイク無しでワークショップを実施したのだが、参加者同士が仲良くワークしていたのが良かった。でもやっぱり、アイスブレイクが有った方がＰＦらしいとも感じた。


■ワークショップ終了
いつも常連5割／初参加5割　くらいの割合なのだが、今回初参加の方が７割くらい居た。更に、参加者総数が20名を超え、大人数であった。これは、場所／時間／主題の３つが多くのニーズにマッチしたからなのではないかと推測している。


最後の集合写真で、参加者の緊張を解すため、即興で考えたアイスブレイクを行使してみた。上手くできただろうか。


■懇親会
ふと思い立って、懇親会参加者にマインドマップで一言づつ感想を書いて頂いた。
たくさんのコメントを頂いたが、寄せ書きの方が良かったかもしれないと、少し反省。次回は色紙を持参しようかと思った。


■最後に
参加された皆様、お疲れ様でした＆ありがとうございました。

Android開発環境を構築してみた。

先日、諸般の事情で、 SoftBank から au へキャリア変更を実施した。

本当は、iPhoneが欲しかったのだが、au へキャリア変更するため、iPhoneは諦めることにした。
代わりに、au のスマートフォン「IS01」をゲット。色々と遊んでみた。

そして、なんとなく「IS01で動くソフトが作りたい！」と思う様になり、一念発起して、開発環境を構築することにした。

とりあえず、幾つかのサイトを巡り、Android用SDKとEclipseが必要なことが判明。早速ダウンロードしてインストールするも、日本語化できなかったり、必要なソフトがダウンロードできなかったりと、トラブル続き。仕方が無いので、Eclipseのオールインパッケージをダウンロードし、Android SDK（=ADK）との連携を実施。とりあえず、エミュレータの画面を表示することができた。

次は、「Hello.world.」を表示させるのが目標。

「テンプレートデザイナー」がCool!

Google御謹製のブログ、「Blogger」を使っているが、デザイン面が貧弱で、見栄えも悪く、ブログを書くモチベーションがどうにも上がらなくて困っていた。

久々にブログを書こうかと思い、Bloggerにログインした所、新機能「テンプレートデザイナー」が追加されていた！

早速使用してみた所、機能的にはGoogle御謹製のwiki「Googleサイト」とかなり似たインターフェースで、様々なデザインの変更が可能になっている。

早速本ブログも色々イジって見栄え向上を図ってみたが、如何だろうか。

非ウォーターフォール型開発に関する調査結果公開

IPA（独立行政法人　情報処理推進機構）が、2010年3月に「非ウォーターフォール型開発に関する調査結果」を公開している。
http://sec.ipa.go.jp/reports/20100330a.html


下記の３つの資料が公開されている。

・非ウォーターフォール型開発に関する調査（調査報告書）
・非ウォーターフォール型開発に関する調査（研究会報告書）
・非ウォーターフォール型開発に関する調査（成果概要資料）

XP、スクラム、FDD、RUP、クリスタルなど、アジャイル開発プロセスを整理／分析し、研究資料といて体系立てて記載されている。

IPAの本気度を感じました。

この資料をじっくり読んで、現場で活用できるヒントを見つけたい。

手witter

ET-West2010 コミュニティビレッジを担当しました。
ET-Westに初参加から、今年で３年。

毎年、セミナーまたはワークショップを担当していたのですが、思うところがあり、今年は「コミュニティビレッジ」オンリーで担当することにしました。

コミュニティ展示＆コミュニティビレッジは今年で２回目。昨年の課題を色々フィードバックし、様々な試みを導入。その一つが「リアルtwitter」なるもの。
正式名称は「手witter」（てうぃったー）。「てふかん」の新美さんが命名されました。

A1用紙に付箋でコメントを書き、貼り付ける。時間と呟きを書いて貼り付ける。ツイートも簡単。なによりも、電子機器を起動する必要が無いのが素晴らしい。
文字だけではなくイラストも簡単にかける所がポイント。

最初は、コミュニティブースの方々のツイートしかなかったのですが、周りの企業ブースの方や、視察にいらっしゃった方からのツイートも増えました。

※　下記写真は、撮影／掲載許可を頂いたものです。

今後、様々なイベントで流行るかもしれません。

他人にモノ教える難しさ

2010年5月28日「すくすくスクラムin大阪」第2弾に参加した。


参加者は、（個人的な独断と偏見で）２０代～４０代までの幅広い年齢層であった。

先月開催された第1弾では、スクラムの実習に重点が置かれ、スクラムの基本的理念や概念に関する説明は殆ど無かった。

更に、今回の第2弾では、第1弾より更にスクラム実習により多くの時間が割かれていた。

講師の方にその点について伺った所、「一日でスクラムのすべてを伝える事は難しい。スクラムの実習を通じて、スクラムに興味を持って頂き、参加者自らスクラムの習得を目指すきっかけにしたい」との意図であると明かしてくれた。

この意図には非常に共感する。

* * * * *

私は、PFP関西／XPJUG関西という２つのコミュニティのスタッフとして、ワークショップを主催する側に立つことがしばしばある。その際、参加者に我々のメッセージが伝える様々な方法を考える。参加者の年齢層、興味を引く内容か、参加者に意図が伝わる内容か、斬新なアイディアはないか、……などなど。悩みは尽きない。

この問題の根本原因の一因は、参加者側の意識にもある。
参加者が、「学び」の意識が無い限り、主催者側の意図は伝わらない。キャッチボールに例えると、相手が投げたボールを無視した場合と同じである。

基本的に無料のセミナーやワークショップは、いわゆる「ボランティア活動」であり、スタッフは無償で活動する。このため、仕事の合間を縫って時間をやりくりし、限られた時間で最大限の成果を発揮しなければならない。そのため、どうしても想定漏れや、考慮漏れが発生してしまう。加えて、参加者の背景、スキル、知識もバラバラなため、すべての参加者が満足する内容に仕上げることは、到底不可能である。

そこで、我々運営側は、「参加してみて、得られた気付きを持ち帰って、自分の仕事にフィードバックして欲しい」との願いを込めて、実施内容を策定することになる。その結果、参加者に理論・理屈を説明する時間が確保できないし、確保しても、参加者全員が「腑に落ちる」かどうかは保障できない。限られた時間の中で教えられることは本当に少ないのである。

主催者側の発表内容は、主催者が自発的に行動して体得した知識や技術の発表の場であり、一丁一石に説明できる簡単なものではない。主催者側は、「参加者に興味を持ってもらい、自発的に探求するきっかけになって欲しい」という事を期待している。１～１０まで教えてあげたくても、体験を通じて会得したものを、簡単に人に伝えることはできない。だから、自発的に探求して欲しいという思いがある。

* * * * *

今回参加された方から、「よくわからなかった」という意見をいくつか聞いた。
私は、「よくわからなかったから、自分で調べてみよう」という発想を抱き、自発的行動に移すことができれば、今回のワークショップに参加した意義があるのではないかと考えている。

「すくすくスクラムin大阪」第一弾参加。

2010/4/25（日曜日）に開催された「すくすくスクラムin大阪」に参加した。

「スクラム」とは、アジャイル開発の１つに分類されるソフトウェア開発手法である。名前の由来は、ラグビーの「スクラム」が元になっており、「開発チーム全員でスクラム組んで一丸となり、てソフトウェアを開発しよう！」というもの。

チームが開発に注力するため、様々な手法が提案されている。

　・バックログ

　・スプリント

　・スクラムミーテイング

　etc, etc……

今回は、この「スクラム」という開発手法を体感する事がゴール。

主催は、「すくすくスクラム」。司会は　ebackyさん。

下記にワークショップの内容を簡単に紹介する。


--------------------------------------------------------------------------
シナリオは「新しい家を作る」ことが目的。

いくつかのチームに別れ、各チームをそれぞれ「家族」に見立て、役割（ロール）を明確にし、ロール毎に新しい家に対する要求を出す。

出された要求に対し見積もりを行い、タスク分けを行い、タスク単位にブロックの組み立てを行う。見積もりは、ブロックの個数単位。タスクをスプリント単位に実施し、１スプリント終了毎にふりかえりを行う。

家を建築中、隣の家のお父さん　（顧客）　に優先順位付けと、出来栄えの評価を実施してもらい、開発チームが見落としている観点や、開発者の都合で決めた仕様の問題点を指摘してもらい、軌道修正する。

--------------------------------------------------------------------------

上記ワークは、スクラムのプロセスのすべてが含まれている。

　・プロダクトバックログの作成

　・各プロダクトバックログの見積もり方法

　・プロダクトバックログからタスクへの分割

　・開発チームの開発スピード（ベロシティ）の測定

　・改善活動（ふりかえり）

　・顧客を開発に巻き込む

特に参考になったのは、「プロダクトバックログ」（ストーリーカード）の書きかた。

　（１）記入者の役割

　（２）欲しい機能／性能

　（３）欲しい理由／得られる価値

そして、もう１つ大きな参考になったのが、規模の分からない機能に対する見積もり方法。
（１）「プロダクトバックログ」をすべて出す
（２）その中から最も規模の小さいものを１つ選び、ポイントを「２」にする。
（３）（２）の４倍のものを１つ選び、ポイントを「８」にする。
（４）（２）（３）を元に、他のカードをすべて見積もる

これらの基準は、実践的で効果的な内容でした。

--------------------------------------------------------------------------

その他、気付き事項を列挙。

・スプリント

　「イテレーション」とは違う。「全力を尽くす」という意味合いが込められている。

・done（完了）

　誰もがわ納得できる、分かり易い判断基準が望ましい。

・コミュニケーションコストを払った方が、ステークスホルダーからの協力が得られやすい。

・時間がなくなると、コミュニケーションを止める。

・日本人の特徴「言わなくてもわかるだろ？」

・朝会、ふりかえりはコミュニケーションコストが掛かるが、本当に高いのか？

・良いコミュニケーションとは、相手の考えを理解すること。

--------------------------------------------------------------------------

たった１日でしたが、書籍で読んで理解していた内容に、実体験が加わって、更に理解を深めることができた。

次回、5/29に「すくすくスクラムｉｎ大阪　第二段」が開催される。そちらも楽しみである。

コミュニケーションは大切

twitterで得た気付き

「隣の人に勧められた本は読むのに、amazonで高得点を取っている本には見向きもしない。なんでなんだろ？」

物と人の距離を縮めるためには，人が興味を持つ必要がある。興味が無い物に人は自分から寄付こうと思わない。

人は他人の行動に興味を魅かれやすい。「口コミ」や「オススメ」もその一例と言える。

単にドキュメントやソフトといった「物」と顧客やエンドユーザーを繋ぐために，間に開発者や営業といった「人」を仲介するのが良い例である。

だから，コミュニケーションは大切なのである。

サービスを売るということ。

メーカー系企業では、「技術」はできてあたりまえ。自己啓発で勉強するのも当たり前。

持っている技術を使って、いかに顧客が喜ぶサービスを考える点が重視される。

単にモノを作っても、顧客が買わなければ意味がない。

顧客が欲しがるモノで、低価格かつ高品質でなければ売れない。

ソフトハウス系企業は、「顧客要求の満足度」という指標があり、これを満たすために顧客から仕様を引っ張り出そうと努力する。

しかし、単に引っ張り出しただけでは足りない。
それでは、「伝言ゲーム」になってしまう。言った／言わないの水掛論争が始まる。

顧客の言った言葉の意味を、受注側が１２０％汲み取り、製品に反映しなければならない。

「１２０％汲み取る」とは、すなわち顧客の言っていることが正しいか間違っているかまで判断するということであり、顧客が言い間違っても、それを間違いであると訂正できなかった受注側のミスだと認めるくらいのレベルであると言える。

顧客の要求を理解するだけではまだ足りない。顧客の要求を踏まえた上で、顧客が「欲しい！」といわせるだけの提案を行って、初めて顧客に受け入れてもらえる製品となる。

僕は未だに、顧客に「欲しい！」と言わせる提案を行っているソフトウェアハウスに出会ったことは無い。

ソフト開発における成功の道筋

今の世の中，薄利多売がはびこり，それが最も簡単かつ確実な方法だと考えていた。

しかし，ソフトウェアで薄利多売を実現することは難しく，受託開発によるビジネスモデルが当たり前になっていると感じる。

薄利多売を実現するためには，売れるソフトウェアを大量生産し販売する事を意味するが，このビジネスモデルは大きなリスクを孕んでいる。もし不具合が見つかった場合，回収／修正／返送費用がかかり，売上が一瞬で消し飛んでしまう。

このビジネスモデルを実践しているのが，主にゲームメーカー，一部のビジネスソフトメーカー，特定用途向けソフトウェアメーカーぐらいである。

成功しているメーカーが少ない事から，リスクの削減が難しく，利益も不透明で不確定要素が強いと思われる。

一般的なソフトウェアハウスでは，薄利多売のビジネスモデルを成功させる道は無いのだろうか。

繋がり

私は，ソフトハウスから転職し，現在メーカー系の会社で働いている。

メーカー系とは，自社で機器を開発する企業を意味する。

ソフトハウス系企業とは比較にならない程業務範囲が広い。

一つの製品を創るのに多くの企業と提携し，それらの企業との調整も必要となる。

今関わっているプロジェクトは，初期メンバーが地道に様々な所へ提案活動をして回った結果，糸口を掴み，様々な企業とのパイプが繋がり始めた。

それは，最初の提案活動で名前を売り歩いた成果だと聞く。

様々な企業との連携は，簡単で綺麗なものではない。自分達の得意分野を活かし，お互いの利益を守り，チャンスがあれば別のビジネスを広げるべく，虎視眈々と狙っている。真に弱肉強食の世界。

いずれにしても，先は点から始めなければならない。点から始めるためには，他者が持っていない強力な武器と，地道な努力が必要であり，どちらが欠けても上手くいかないだろう。

強力な武器があれば，他者が現れても，自分達のポジションを奪われる事なく，ビジネスを進める事ができる。

ただし，そうやって勝ち取ったビジネスも，数年立てば模造品，類似品が出回り，利益回収は困難になる。
だから，安堵すること無く，新しい商品やサービスを次々開発しなければ生き残れないのである。

XP寺子屋第5回「ペアプロ体験」ふりかえり

盛況の内に終了しました。

あらかじめ参加者にパソコンとペアを各自用意して頂いた。その結果，欠席者ゼロというスゴイ記録が生まれた。通常，参加者の１〜２割が欠席するのが常識となっているのに，「欠席者ゼロ」とはスゴイ事である！

当初，参加条件が厳しかったためか参加者集まらなくて焦りを感じたので，下記２点の初の試みを実施。

■その１：資料の事前公開
いつも資料は当日まで公開されないが，参加者が内容を事前に把握した方が安心できると思い，事前公開してみた。

■その２：目立つテンプレートの使用
見た人に興味を持ってもらう様，目立つテンプレートを使用した。
いつもお世話になっているMS様のテンプレートでは物足りず，フリーのテンプレートを探し，印象に残るものをチョイス。

実際のワークも盛り上がった。
最初の15分でインストラクション＆アイスブレイク。アイスブレイクで久々に「しりとらず」を実施したが，凍り付いた場が数分で和やかな空気に変わるのを感じた。
残りの時間をペアプロに割り当てた。あるペアはタスクかんばんを使い，あるペアはデザインパターンで熱い議論を交わし，会場は静かにヒートアップ

最後に「拍手２回でふりかえり」を行い全員の感想をシェア。「有効なやり方」「会社では教えられない細かい事を指導できた」「楽しかった」「もっとやりたい」等々，前向きな意見が多かった。

◆◆◆◆◆◆◆◆◆
自分自信のふりかえり

■KEEP
・ペアプロのワークショップを実現した
・期待していた効果が得られた
・参加者が１０名を超えた
・ソフト業界以外の方も参加

■PROBREM
・ヘルプファイルを忘れていた
・見学者への対応が不十分だった
・自分も開発していたので十分フォローできなかった

■TRY
・XP寺子屋継続
・XPの全プラクティスを使ったWSの開催
・IT業界へのペアプロの展開


これからも，XP寺子屋を続けて行きたい。

XPの真価を伝えたい

2007年，XPJUG関西のスタッフにして頂いた。

当時，「XPをもっと世間」に広めたいという思いを強く持っていた。

人に自分の知識を教えるのが好きな性格だったため，XPJUG関西を通じて誰かにXPの良さを伝えたかった。それを形にしたのが「XP寺子屋」である。

今まで通算4回開催し，本当に多くの方々に参加頂き，様々な気付きを頂いた。

今月，5回目を開催する。
内容は，念願のペアプログラミング。「やってみたいXPのプラクティス」で常に上位にランキングされるプラクティスである。

ただ，予算の都合上，様々な制約事項をつけなければならなかった。

機会があれば，制約事項を減らして再度企画してみたい。

ペアプログラミング

ＸＰのプラクティスの中で注目度の高いプラクティスの一つである「ペアプログラミング」、通称「ペアプロ」。

「ＸＰを知ってますか？」と聞くと、殆どの方が「ＴＤＤとかペアプロするんですよね」と答える、ＸＰの代名詞と言っても過言ではないプラクティスである。

ＴＤＤ、リファクタリング、コード共同所有、シンプル設計、ペアプロなど、開発に直結するプラクティスの内、ペアプロだけが一人で試すことができない。できないからこそ、注目度が高いのではないのだろうか。

或いは、「２人で１台のパソコンを使って開発すると、生産性を落とさず高品質になる」という、従来の考え方（個々人の能力の高さが生産性と品質に直結する）と相反する考え方だからだろうか。

私は、両方の理由からペアプロに挑戦しようと考え、約３年間取り組んできた。
その経験から学んだ事は、「ペアプロは、ペアを組む相手により結果が変化する」という事である。
 特に、ペアプロを有効と感じないメンバーが居るプロジェクトでは、上手く機能しない。つまり、２人１組で開発することの弱点となる。

ここを上手くクリアできなかればべ、ペアプの有効性を感じることは難しい。

XPと受託開発はマッチしない

「XP祭り関西2010」が無事終了した。
今回のテーマは「アジャイルマインドの育て方」となっており，ご登壇頂いた皆さん，アジャイルマインドについて，熱く×100語っていた。
特にpapandaさんの熱さには驚かされた。
◆　◆　◆
基調講演で「XPと受託開発はマッチしない」というお話しがあった。
曰く，「品質よりスピード」，「シンプルより多機能」，「（契約の関係で）複数回リリースより１回リリース」という，XPと異なる価値を重視しているためである，と。
「XPはお客様と協調し，良い製品を作るための手法だ」と言われて久しいが，（少なくとも）日本ではXPの価値がお客様の満足度に貢献できていない様に感じる。
お客様にとって，開発手法は重要ではない。「XPは素晴らしい」と言っても，お客様の満足が得られなければそれは技術者の自己満足でしかない。
イベント終了後，知人とそんな話をしていると，ふとアイディアが浮かんだ。
「受託開発者で，お客様が満足するプラクティスを開発する」
ケント・ベックが教えてくれた「プラクティス」を実践するという事は，「守破離」で言う『守』の段階である。だから，受託開発に最適化したプラクティスを開発（『破』）し，成功（『離』）を目指さなければ単なる開発者の自己満足で終わってしまう。

そして，一番重要なのは「XPとは変わる事」だという事。
XPの本質は「ソフトウェア開発において正しい事を最大限に実行する事」であると考えている。その考えに基き，価値と原則とプラクティスが策定されたはずであるが，「価値・原則・プラクティス」は，プロジェクトや前提条件によって変化するのではないだろうか。
ならば，「日本の受託開発」という前提条件を満たす「価値・原則・プラクティス」を考えればよいのではないか。

一つ言える事は，「現状のソフト開発スピードでは，顧客満足が得られない」という事。
ハードウェアスペックの向上によりコンパイル時間は短縮された。次の10年ではソフト開発の時間短縮が実現されるだろう。
その時，XPはどんな進化を遂げているのだろうか。

アジャイル・マインド

「アジャイルを実践している人は，自発的にアジャイルの布教活動を行なう人が多い」

-XPJUG関西代表　細谷氏　談-

経験的に，アジャイル開発実践者は自ら率先して様々な活動を展開する。

ある人は本を書き，ある人はセミナーを開き，ある人はコミュニティーを立ち上げ，ある人は会社でアジャイルを広めようと活動し，ある人は独立してアジャイル開発を実践する会社を作る。

この様に，自発的行動を起こす人が，アジャイル開発実践者の中に多く見られることから，「アジャイル開発実践者によく見られる自発的行動へと駆り立てる心（スピリット）」の事を「アジャイル・マインド」と名付けた。

アジャイル・マインドを持つ開発者が増えれば業界が良くなると考えている。

今年開催される「XP祭り関西2010」では，「アジャイル・マインドの育て方」をキーワードにしたセッションが多数行われる。

このイベントの参加者の中からアジャイル・マインドに目覚める人が一人でも多く現れる事を願わずにはいられない。

「アジャイルって良いのですか？」

「マクドナルドのテキサスバーガーって美味しいのですか？」と同じレベルの質問だと思う。

マスコミやネットで騒がれているが，美味しいかどうかは本人が食べてみなければ判らない。食べてみて美味しいと感じる人も居れば美味しくないと感じる人も居る。

ソフトウェアの開発手法にしても，合う・合わないがあるのではないだろうか。問題は，情報量の少なさだと思う。

専門学校や大学で，アジャイルについて十分教育がなされていないから，認知度が低いのである。

もっと大きな問題は，ソフトウェア開発者が儲らないという点。儲らない業種に学生は集まらないから，授業で取り上げる価値が低いのは当然である。

老体に鞭打って勉強会の場だけでアジャイルを伝えるのは，間違いだと思う。

Agile2.0について思うこと。

「アジャイル」という言葉に、どの様な感想をお持ちだろうか。

10/1/14に、「AGILE2.0 〜 アジャイルなチームで何を提供する？」というタイトルのイベンが開催された。
http://kokucheese.com/event/index/1151/

ちょっと気になって「アジャル２．０」でググッてみると、実は２００６年にも「アジャイル２．０」という言葉が登場する。

■アジャイル2.0ホームコミュニティ
■アジャイルな世界
■Agile, Orthodoxy and a Message From God

だからどうという訳ではないが。

---

最近、某ＩＴ系出版業界の方とお話した際、「最近、”アジャイル”というキーワードの本は、まったく売れなくなった」と聞いた。個人的には最近、アジャイル関係の書籍が多数出版され、読み手も飽きたのではないかと推測している。

話を戻そう。

私は、「アジャイル２．０」という言葉に大きな違和感を抱いている。
アジャイルを簡潔に表現すると「ソフトウェアを素早くしっかり作りましょう」という基本的理念の呼び名であり、この基本的理念は何も変わっていない（はずである）。

「ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法郡の総称である。」

－ウィキペディアからの引用－


「アジャイル開発手法」＝「イテレーション型開発手法」と言われたり書かれたりしているが、実はそうではない。「ソフトウェアを素早くしっかり作る」ことが本質であり、「イテレーション型開発手法」はその実現手段の一つに過ぎない。アジャイル２．０で語られている多くは、実現方法やソフトウェアの品質保証、開発プロセスなど多岐に渡っているが、結局実現手段に関する話題が主体となってる。

「アジャイル開発」の本質は「ソフトウェアを素早くしっかり作りましょう」であり、「イテレーション開発」、「eXtream Programmming」、「スクラム」を実施することではない。この点を見誤ってしまうと、2000年に起こった「アジャイル開発手法の誤解によるプロジェクトの失敗」の再来が起きる。

2000年に「アジャイル開発手法」が日本に上陸した際、アジャイルの誤解による悲劇が起こったと聞く。下記の内容を本気で信じて開発しても、失敗することは明らかである。

・ドキュメントは書かなくても良い

・設計よりもプログラミングを重視する

etc,ect･･････

「アジャイル２．０」、「TiDD」、「スクラム」など、それ単体で確かに価値のある方法であると言えるが、万能な方法ではないことを理解する必要がある。「それは本当に自分にとって有効なのか？」と、常に疑ってかかった方が良い。そうしなければ、アジャイルの誤解によるプロジェクトの失敗を招く結果となる。

他人の考えを鵜呑みするのは簡単だが、それでは失敗してしまう。だから、他人の意見が自分にとって有効か無効か考えて判断することが必要であると言える。

コミュニティのスタッフから頂いた気付き

先日、XPJUG関西のスタッフミーティングが行われ、その場に居た参加して間もないスタッフの方からこんな一言を頂いた。

「会社の人達は、なぜコミュニティに参加しないのだろうか。」

理由を詳しく聞いた所、「自宅で使用しているツールを会社で使わない。もっと自分のやっている事を積極的にアピールすれば良いのに」との事であった。

彼に対するファーストインプレッションは、どちらかといえば消極的という印象であった。
その彼が、コミュニティへの参加の素晴らしさに気付き、発言内容が大きく変化した。
モチベーションの高いメンバーに囲まれると、人の考え方や行動を大きく変化させる効果があることに、改めて気付かされた。

IT系技術者の人材不足について

昨晩、コミュニティ繋がりで知り合った方との呑みに行った。

その席上で、「本当に欲しいと望むIT技術者に、なかなかめぐり合えない」という話題が挙がった。

自分が若かった頃、プログラムの知識が一切なまま仕事を任され、非常に苦労した。その結果、ある程度スキルが身についた。そんな自分が言うのもおかしいが、当時の自分の様な知識の無い人と一緒に仕事したいと思えない

大学卒業しても、プログラムの知識なんかほとんど持っていない新人が殆どなのが現状。だから、会社が費用をだして教育させる必要がある。大手のソフトウェアハウスの場合、入社から数ヶ月間言語研修が行われ、そこでスキルを身につけるのが一般的だと思う。

小さな会社では、教育費が確保できないため、自己啓発（＝自宅で勉強）に大きく依存する所もある。

中には社員の能力以上の肩書きを与えて仕事させ、現場で成長ささせる考えの企業もある。

様々な業界において、「免許」という制度が存在する。たとえば、飲食業界には「調理師免許」、医療業界には「医師免許」、タクシー業界には「車の免許証」など。しかし、ソフトウェア業界にはこの「免許」が事実上存在しない。

先に述べた通り、ソフトウェア技術者のスキルは、それぞれ歩んできた道のりにより異なるが、それを定量的に示す物差しが存在しない。スキルを知るためには、実際に一緒に働いてその働きぶりを見るしか方法は無いのが現状である。

プログラムも知らないままソフトハウスに就職し、能力以上の肩書きを与えられ社外へ出て仕事をし、定量的に測定不可能ながらも少しづつスキルを身につけ成長するのが、一般的なIT技術者の成長過程なのではないだろうか。

定量的に測定不可能なスキルと、スキル以上の肩書きとを見比べて人材を評価しようとしても、真に望む人材を見つけることは難しい。

いっそのこと、大学生よりIT系専門学校生を採用した方が期待に答える人材を見つけられるのではないかという意見で合意した。

感動するソフトウェアはどうやって作るのか？

TVで木村カエラさんが「butterfly」という曲を歌っている映像が流れているのを見聞きして、その曲の美しさに感銘を受けた。

その時、ふと思った。

「感動するソフトウェアを作ることができるのか？」

－◆－◆－◆－◆－◆－◆－◆－◆－◆－◆－◆ー

人は、「素晴らしい」と感じるものに感動する。

人は、五つの感覚器官「五感」を使って受け取った刺激の良し悪しを判断する。

例えば、車の場合、車体の形状（視覚）や、エンジン音（聴覚）、高級感（視覚、触覚）に感動する。

料理の場合、匂い（嗅覚）、見た目（視覚）、味（味覚）、舌触り（触覚）に感動する。

パソコンの場合、色や形（視覚）、キーボードの感触（聴覚、触覚）、処理速度（視覚）に感動する。

これらを刺激するソフトウェアとしてすぐに思いつくのが「ゲーム」である。
確かに、ゲームは人の五感を直接揺さぶり、感動させる力を持っている。
それでは、ゲーム以外、人を感動させる事はできないのだろうか。

－◆－◆－◆－◆－◆－◆－◆－◆－◆－◆－◆ー

ふと思いついたのが、上記の五感以外で感じる喜びに「知的欲求の満足」と「達成感」がある。
人は、知的欲求が満たされた時や、何かを達成した時、喜びを感じる。

ソフトウェアは、これらの喜びを得ることが得意なのではないか。
創造的なグラフィックや動画製作、或いは、Ｅｘｃｅｌによる表計算シートの製作にも「知的欲求の満足」や「達成感」を味わうことができる。

これらの得意分野を駆使し、更に人の五感に訴えるようなソフトウェアを使うと、人を感動させることができるのではないだろうか。

誰のために開発するのか。

アジャイルは手段であって目的ではない。

しかし，『目的の達成』というゴールへの道のりは楽しい方が良い。

だから僕はアジャイルの考え方が好きだし，実践したいと願っている。

たとえ成功できなくても，失敗という経験から何かを学び，成長すれば良いのではないか。

『成功』より『成長』するために，アジャイルを実践したい。

そして，大きな『成功』を得たい。

「アジャイルしてます」とはどういう状態か？

「アジャイルしてます」と言う時，何を持って「アジャイル」と判断するのだろうか。

アジャイルという言葉から連想するものが，アジャイルに関する経験や知識によって異なるのではないだろうか。

一方，ウォーターフォールという言葉は，広く世間に浸透しており，大筋で類似した回答が得られる。

自分自信，アジャイルとは「アジャイル開発宣言」の価値を重視する手法としか理解しておらず，実感が伴っていない。

ちなみにXPとアジャイルは類似しているが明確に異なるものである。「アジャイル開発手法」とは，アジャイル開発を抽象的に定義したものであり，「XP」とは高品質なソフトウェアを効率的に開発する具体的な手法である。つまり，下記の関係が成立つ。

アジャイル開発＞XP

「イテレーション開発してます」「ペアプロしてます」「テスト駆動開発してます」といった状況を総称して「アジャイルしてます」というのは，本来のアジャイル開発の趣旨から反するのではないだろうか。

しかし，ウォーターフォールのように，なにを持って「アジャイル開発」とするか明確な定義がないため，判断が難しいのは確かである。

アジャイル開発の知識体系をまとめると，法則や規則が見えてくるかもしれない。