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

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で高得点を取っている本には見向きもしない。なんでなんだろ？」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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