Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

POStudy Day 2012 in Okinawa - 振り返り結果

363 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

POStudy Day 2012 in Okinawa - 振り返り結果

  1. 1. POStudy Day 2013 Spring in Tokyo振り返り結果2012年12月01日(土)POStudy@fullvirtueCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.POStudy Dayin Okinawa
  2. 2. 振り返り結果ご紹介気づき– 最初はコンテンツで引き寄せて、最後に自己紹介する– 否定から入らないことの大切さ– いろんな分野の勉強がしたいと感じた– 仕様を受けるのと伝えるのは全然違う– 社外の人と話すのは楽しい– 発散と収束は別々の日に– 自分の態度や言葉づかいが強引でないか、客観的に見る必要性– 会社とは違う形で話すことで、違う発想が出来た– 「わからない」とちゃんと伝えることから生まれる展開がある– 仕様を伝えるのは難しい– 見積の難しさ– マシュマロでの無理なトライが仇となる– 運が与える影響の大きさ– マシュマロ重い– マシュマロチャレンジを通して、1つのことに力を注ぐことの楽しさを感じた– 意志の共有どんな時でも大切– 全員の意志を共有することは難しい– ワークショップの大切感を再認識– 伝えることの難しさ– 大きな紙のテープでの止め方– 課題や方向性を指摘するのがとても大切– 可視化大切– 少ない時間では作戦よりも実際にやってみることの大切さ– みんながApple– 初対面の方々との会話は楽しい– 付箋紙の大切さ– ユーザーストーリーマッピングでのユーザーが求める価値Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 2
  3. 3. 振り返り結果ご紹介気づき– マシュマロチャレンジ 一人一人の役割を明確にする– 共有することの大切さを改めて知った– ビジネスモデル構築はエキサイティングで面白い遊びだ– マシュマロチャレンジ 仮説を立てることが大事– The Specification Exercise 前提を確認することが大事– チームビルディング大切– マシュマロチャレンジ 成功体験を手に入れる→そこから発展– フィードバック、確認が大事– マシュマロチャレンジ 土台が大切だった– ユーザーストーリーマッピングにおいて、Doneの定義は超重要– 細かい機能の完了条件を決めるのはいいと思った– チームでの決まり事の重要性– フィードバックの重要性と忘却性– チームでの作業はコミュニケーションが難しいでも重要– Doneの定義– 相対的な作業量見積はチーム内の作業認識合わせにも超有効– 仕様書の認識を作業者同士でも合わせる努力が必要– 同じ言葉を使っても認識は人それぞれ– 認識の違い– 大きな仕事に向け、小さなTryを積み重ねることも重要Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 3
  4. 4. 振り返り結果ご紹介感想– 実際の開発に取り入れてみたいと思った– ユーザーストーリーは難しい– ワークショップは楽しい– マシュマロ楽しい– 所長がこない– 良い経験をしたけど、無料でいいのかな?笑– もっとITについて知りたくなった– 長い時間でもリラックスして楽しく参加できた– あっという間に終わった– 各チームの個性が良く出ていて面白かった– Japan guide.com 凄かった ユーザー増える例– いろんな情報を得ることが出来たStartup Weekendなど– 社会人・学生の交流はWelcomeCopyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved. 4
  5. 5. 振り返り結果ご紹介Keep– 指摘されたことは感情的にならずに受け止める– 意見の共有をすること– 頭にある情報の共有化、可視化、大切さ– 相対的に見積もる– まず手を動かす– プロタイプをたくさん作ろう– 良いイメージが見えた案は試してみる– いきなり完成品を作るのではなく試作品を作ってみる– 普段から無駄を考える– ポストイットは横にはがす– 誰の為、何の為に作るのかを共有することの大切さ– Doneの定義を意識する– メンバーの構成によって自分の役割を積極的に担う– Doneの定義をすることで相手との食い違いがないようにする– 自分の限界を知っておく– 全体から物を見る大切さ– 面白かった– 討論するのが楽しい– プレゼンのシナリオをイメージ出来た– ゲーム感覚で勉強できてすばらしい– いろんな人と話ができた– 発散の日と収束の日を分ける– 見積の探り方– フィードバックは大切– リーダーってやっぱり大切– ピザが美味しかった– どうやったら、どう伝えたら伝わりやすいかを意識する– 仕様のフォーマットを決める– スクラムの基本説明があってわかりやすかった– 振り返りが細かくあってよかった5
  6. 6. 振り返り結果ご紹介Keep– 最後の振り返りで関さんの種明かしがあってよかった– プロトタイプ とりあえず動く物を作る!を再認識できた– 自己紹介は自分が出来ることをアピールする場それによって次に繋がる– ごちゃごちゃ言わず、まずはやる– まず最低限の物を作る それからアップデート– ロジック的な組み立て– 共通認識を確認する– Doneの定義– ピザ美味しかった– 仕様の前にGoalを決める for who / for why– 作りながら考える– 反省をメンバーで共有し、生かす– 役割分担– チームの情報共有化– 案件の大きなイメージからチーム内で共有していく– ストーリーの発散と収束– ポストイットのはがし方– プレゼンするときのテクニック– 方向性の確認6
  7. 7. 振り返り結果ご紹介Problem– 発表するのがニガテ– 絵が1つだけと思い込んでいた– 問題があると感じていたことを勢いで流して結果ゼロになった– 論理的に話せてない– 相手が分かるように話せない– 会場が初めてで迷った– POとしての視点の理解不足– 名刺持ってくればよかった– プロダクトオーナーとは何かがまだいまいち理解できていない– 名刺もっとけばよかった– まだちゃんとスクラムの手順や理論が落とし込めていない– プログラミングの知識がなくて認識がずれてしまった– 自分の知っていることを知らない人に伝えるのが上手くいかない– ITの知識がなさすぎる– コミュニケーションフィードバックが少なかった– ワークショップの時間が短い7
  8. 8. 振り返り結果ご紹介Try– 問題を感じた場合は、あいまいに流さず納得出来るように共有する– もっとスクラムを知りたい– 思い込みは捨てる– Keepに載っているものは定着するように努力する– 理解の順番を考えて物事を伝える– 人前で増やす機会を増やす– 目的を決め、ゴールまで進む– 案件に対してルールを決める– 相手に伝えることの難しさと技を認識して製作にアプローチする– チームでゴールを設定して定着化させること– 沖縄でスクラムを行っている企業はどのぐらいあるのか?– 自分の頭にある物をどう共有するのか– 自分の武器は何なのか?– 人見知りだったけど案外話が出来たと思うもっとたくさんの人と話す– POの立場を理解する– 相対見積– 会社もしくはビジネスモデル作成– 帰ってアジャイル関連の本を読んでみる– 日常生活にスクラムを取り入れる– リーン、英雄的構造など、気になった言葉を調べて見る– 自己紹介出来る力をもっとつけたい– 相手のモチベーションの事を考えて接する– 無理はしない(マシュマロチャレンジ)– 会場の事前確認が必要– 皆が付箋マスターにw– 付箋の使い方– 自己紹介をもっとやりたかった8
  9. 9. 振り返り結果ご紹介Try– 自分と相手の認識がちゃんと同じかチェックする– 伝わるように相手にあわせる– 書籍を読んでみようと思う– マシュマロチャレンジ とりあえず作って見る完璧を目指さない– ワークショップで見たスクラムの説明を資料で欲しい– 無駄をなくす– 英雄的構造がたくさん作れる人になりたい– アジャイル・スクラムの流れを押させる– 開発者と仕様を伝える人を1回交代してやりたかった– 簡単な言葉でしゃべる– 自己紹介では強みをアピール– プロダクトバックログを組んでみる– チームの連携– プランニングポーカーの基準値を見直す– 小さいことからはじめてみる 挑戦する– スキルレベルを統一する– 目的の確認– 伝えるときは全体像と案件毎にわける– フィードバック(コミュニケーション)をもらって、より良い物を作る– 成功体験の後、急激な拡大は危険– 常にチーム全体の動きを確認– 前提条件を見直す– 時間配分を見直す9

×