他人にモノ教える難しさ

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寺子屋を続けて行きたい。