2012年05月20日

KiDS (Keio innovative Design School)の公開ワークショップに参加しました - ブレストファシリテーターとして

5/20(日)に慶応大学日吉キャンパスで行われたKiDS (Keio innovative Design School)の公開ワークショップに参加しました。

KiDSの公開ワークショップのページ
 http://www.sdm.keio.ac.jp/news/2012/05/10-081407.html

■KiDSって?

オープンKiDSとは慶応大学システムデザイン・マネジメント研究科(SDM)が主催されているワークショップで、今回が第1回目です。SDMは複雑な状況に対してシステムズ・エンジニアリング / デザイン思考のアプローチで取り組んでいくための方法を教える、ちょっと変わった大学院です。スタンフォードd.schoolや東大i.schoolとも協業しているとのこと。
ちょっとしたご縁でKiDSの先生方とお知り合いになり、今回はスタッフとして参加させていただきました。参加者の方は学生・企業勤務・NPO勤務・自治体勤務・大学の先生等さまざま。様々なバックグラウンドの方が集まって、みんなでブレストの練習を行いました。

■本日のおしながき

ざっくりとした内容は
1. 自分たちのチームの名前をブレストしてみよう
2. 何をリ・デザインしたいかブレストしてみよう
3. どのようにリ・デザインするかブレストし、まとめよう
4. スキット(寸劇)を行って、自分たちの考えをみんなに伝えよう
と盛り沢山でした。これを初対面の人集めて3時間でやるとか、すごい。。結構無茶なスケジュールな気もしたのですが、参加者の方が非常にポジティブ・クリエイティブで思いもよらない意見がたくさん出てきました。

■雑感

僕はいくつかのテーブルをうろうろしながらアイデアを伺ったりしてたのですが、メーカーやSW設計者の中からでは出ないようなアイデアがたくさん出てとても感動しました。いやぁ。みんなすごいなぁ。と。
最後のスキットも準備時間10分程度の厳しいスケジュールの中、どのチームもとても楽しく伝わりやすい演技を披露されていました。

今回説明されたスティッキーノートをつかったブレスト・プロトタイプ(スキット)や、次回以降の講義で行われるシナリオグラフ・レバレッジポイントの見つけ方などは、アジャイルな開発・ゲームストリーミングともつながるものだと思っています。今回の参加者の積極性の高さ、クリエイティビティの高さに、僕も頑張らなければならないなあと思いました。

また、無料勉強会に最近よく参加していますが、裏方として参加したのは初めてでした。このような勉強会はスタッフの皆さんの活動によって成り立ってるのだなあと実感しました。会場設営・受付・機材準備・突発的な問題への対応・片付け・ふりかえりなど。感謝。

前野先生によるKeio SDMの紹介及び本日のワークショップの資料は以下です。
http://lab.sdm.keio.ac.jp/idc/kids/maeno_kids_20120520.pptx


posted by コパン at 22:33| Comment(0) | agile | このブログの読者になる | 更新情報をチェックする

2012年05月13日

スクラム道フルブーストに参加しました - 価値に優先順位をつけることの難しさ

5/11にバンダイナムコで開催された「スクラム道フルブースト」に参加してきました。@nawotoさんが中心になって定期的に開催されているスクラム道の大規模版です。僕はスクラム道には初参加でした。

スクラム道では、有識者の方が特定のテーマについてプレゼンを行ったあと、プレゼンの中身について聞き手の一部の人(選手とよばれます)が議論を繰り広げます。今回のテーマは「プロダクトバックログ」。発表者は@imagireさん。僕も選手のひとりとして、質問をさせていただきました。

僕の聞きたかったことは「プロダクトオーナーが価値判断・優先度判断をできない場合、どうすればいいのか」(*1)。ただ、僕が質問をまとめきれていなかったこともあり、「プロダクトオーナーの優先度をチームが理解・信用できない場合、チームはどうすればいいのか」(*2)という質問の仕方をしてしまいました。それに対して他の選手の方から、様々なフィードバックを頂きました。

*2に対するフィードバックとしては、
・チームとPOがもっと理解しあうために話し合うべき。
・まず、チームとPOが信頼関係を築くべき。
・共通の大目標・ゴールを設定した上で、それに向かっているかをチームとPOで共有すべき。
など。

*1に対するフィードバックとしては、
・POがひとりである必要はない。POチームとしてふるまっても良い。
・チームが疑問を投げかけるのはあるべき姿。ただし、優先度の決定権と責任はあくまでPO。
など。

非常に参考になりました。

POチームというのは前から出来ればいいなーと思っていたことです。POといえど神ではありません。業界情勢も、技術動向も、マーケティングも、営業も、ユーザビリティもすべて分かる人はいません。それなら、開発チームと対になる存在としてPOチームがあってもいいのではないかと思っています。 うまく整理して、提案してみたいと思います。

また、他の方もTwitterやBlogで書かれていらっしゃいますが、POやバックログの定義が現場ごとに違うので、なかなか議論がかみ合わない部分がありました。SIerなんかだと顧客と相談しながら開発ができるのでPOは価値判断を行いやすいです。オンラインゲーム業界、Webサービス業界なんかだと、予めユーザの声を聞くのが難しいので、クローズドベータやABテストなどを行って早いフィードバックを得るのでしょう。一方で僕がいる組み込み業界なんかだと、一度製品を出すとユーザログも取れず、すぐに機能差し替えもできず、ベータ版を出してあとからアップデート、というのも難しいケースがほとんどです。このようなケースで、どのように「正しい優先度」を付ければいいんでしょうか。みなさまのご助言を参考にしながら、しっかり考えていかないといけないと思います。

もしヒントがあればTwitterなどでご助言いただけると幸いです。

posted by コパン at 23:12| Comment(0) | agile | このブログの読者になる | 更新情報をチェックする

2012年04月23日

「状況打開力を叩き上げる TOCfE ブートキャンプ」に参加してきました。

4/21に日本オラクルさんで開催された、状況打開力を叩き上げる TOCfE ブートキャンプに参加してきました。TOCとはなんなのか、TOCfEとはなんなのか、全然分かっていない状態での参加でしたが、非常に丁寧に説明していただき、楽しむことができました。

TOCとはザ・ゴールで有名なエリヤフ・ゴールドラットさんが提唱している理論のこと。らしい。ザ・ゴールを読んだのはまだ学生の時でソフトウェア屋さんでもなかったので殆ど忘れてしまいました。。読み直さねば。。TOCfEとはTOCの考え方を誰にでも使えるように翻訳・定式化したもの(なのかな??)
そのうちの「クラウド」というツールを手取り足取り教えてもらいました。

実は「for Educationだから全然畑違いのワークショップになるんじゃないだろうか」とか「ウェブ上にやり方が書かれた資料があるから、これでいいんじゃないか」とか思って参加を迷っていたのですが、行って正解でした。Web上で作業の順番はわかるのですが、ワークショップで手を動かすことで、またファシリテーターや近くの方に説明する・質問されることでより理解が深まったと感じました。ウェブだけだとすべての手順を知ることが出来ていなかったこともわかりました。自分ひとりでやると「それは本当なの?」とか「ほんとうに必要?」「しっくり来る?」などの手ごわい質問をしないまま、すすんでしまいますし。「コーチ付きの素振り」ができたのが良かったと思います。
# また、参加者もファシリテーターもいつものクラスタの方が多かったです。

印象的だったのは「自分が納得するか、自分にしっくり来るか」を重視すること。論理的なことも大事なのですが自分の問題を解消するために声に出して読んで自分の問題として理解するということが、問題の解決の一歩になるのだと感じました。

あと、このツールやっぱり使いこなすのは難しいと思いました。サラッと使える場面もあれば難しいケースもあると感じたので、練習・素振りが必要なんでしょう。

以下、メモです。

イントロダクション

・問題に対して的はずれな回答をしてしまうことがありますか?
・もやもややギスギスを表現するのって難しい
・問題/対立を表現する手法が必要


・要望と行動を分ける
・相手の要望を理解出来ればこっちのもんだ
・「対立がないようなふりをする」「臭いものに蓋をする」では対立は解消しない。
・思い込みを解消する。思い込みをやっつける


クラウドの書き方

・問題
 一文で書く:問題点を分かりやすく
 事実を書く:誤解をなくす。問題をはっきりさせる
  「閉塞感がある」:あなただけが感じていること。それは事実?
  →「閉塞感があると感じる」ならOK
 ◯◯なのでと書かない:問題を捉えきれてないから理由が入る。仮定や予測が入ってしまってる
 疑問形で書かない:説明しきれてない
  →「これって問題ですか?」と自分に問う。


・共通目的
 ・共通目的とは
  両者が望むような理想的な状況
  対立を解消して両者が達成したいと思うこと
  手段が対立しているが、そのどちらも目指していること
 ・共通目的は文章で書く
 ・共通目的はかならずある。
  目的があるからこそ対立する。


・良いクラウドかどうかチェックする
 ・声に出して読んでみることで、いいクラウドになっているかどうか確認する。
 共通目的と要望の関係
  ・A<-Bの場合:AするためにはBをする必要がある。
 要望と手段の関係
  ・BするためにはDするべきだとプレッシャーを感じる。
 要望と手段の関係
  ・D’ことはBという要望に対して妥協してしまう
 しっくりこないばあい
  要望と手段が両方とも手段になっている。
  要望と手段が逆になっている。


よくある対立の解消方法
  回避  :なにもしない。やり過ごす。対話を拒絶する。
  あきらめ:片方を選ぶ。
  強要  :力の強いほうが一方の手段を押し付ける。いつの間にか強要していることもあるので注意
  綱引き :どちらも譲らない。緊張と摩擦。
  妥協  :落とし所を見つける。全員満足できない。
       妥協しなくても、良い解決策を満たされることを放棄してしまうことも。
 クラウドが目指す解決
  互いが満足する解決方法を探る
  対立そのものを解消する
  妥協しなくてすむようにする
  問題そのものの本質の理解
  問題の対立と仮定を表面化させる


・解決編
 仮定を加える
  仮定:要望に対して、その手段を選んだ理由
     仮定は矢印に対していくつもある
 クラウドを壊す
  気になる過程を見つける
    この仮定は実在していますか?
    この仮定は有効ですか?
    それらの理由はなぜですか?
    仮定が真実とならないためには、どういう行動を取ればいいんでしょうか。
    例:挑戦するという要望に対して
      「変えない人は全員しんでしまうんですか?」
      「変えるほうが本当にリスクが低いと言えるんですか?」
      「変える時期は今じゃないといけない?」
   「それって本当ですか?」を問う。
 →もっといい方法を考える。
  問題に対する理解が深まったなら、もっといい方法が思いつくはず。
  「二つの要望を満たす方法はなんですか?」
 *目的は、二つの要望を満たす行動をつくること。



posted by コパン at 00:26| Comment(0) | agile | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。