DevLOVE HangarFlight - Spring Bomb -( #devlove0521 )参加メモ

DevLOVE HangarFlight - Spring Bomb -へ参加した際のメモです．
聞きながらのメモですので，誤りが含まれているかと思います．その点ご了承ください．

■日時：2011/05/21(土) 13:00-21:00
■場所：日本オラクル青山
■参考：http://kokucheese.com/event/index/10866/
■他の方によるまとめ，感想：参考になります．

■参加プログラム
□オープニング「Spring Bomb」　@papandaさん
□「より高く飛ぶためのはったり活用法（仮）」　乗り手：@yotii23さん
□「今だからこその実践的プロジェクトファシリテーション」
　乗り手：チームPFP
　整備士：@DiscoveryCoachさん
　プロジェクトファシリテーションの案内人@j_matsumotoさんの解説とファシリテーションで皆さんと50分間という時間を共有
□システム企画を加速セヨ
　〜イノベーションを引き起こすアジャイルなシステム企画手法〜　乗り手：@sandayuuさん
　Business RIAカンファレンスでの発表再演。
□俺たちのハンガーフライト　整備士：@papandaさん
　「物語を、自分事にするために。」
　参加者それぞれのコンテキストに基づいて、課題解決を指向したふりかえり
□「次の時代を作るのは、老人ではない。」　ボースンの白昼夢　乗り手：@jojoAtHanawaさん
　整備士：@ujtommyさん
　概要：SpringBomb、クロージング。
□Hangar Flight 渾身会　乗り手：全員
　「ビアバッシュダイアログ」

■感想
　懇親会において，松本屋さん(@j_matsumoto)とプロジェクトファシリテーション(以下，PF)について，詳しくお話しさせていただくことができました．今まで，PFは言葉としては聞いていましたが，どういったことをどういった考えでおこなっているかよくわかっていなかったので，とても良い機会でした．あらためて，松本屋さん，ありがとうございました．
個人的に感じたPFとは下記の通り

自分がより心地良いように少し動いてみる．
動いた結果を自分が感じて(=not 理解)，再び心地良いように少し動いてみる．
これを繰り返すことで，良い状態にする．
動かなければ、変わることは難しい。
ただし，物事は常に変わり続ける．そのことを感じなければならない．

■詳細メモ
□オープニング「Spring Bomb」　@papandaさん

DevLOVEとは
- 開発を楽しく
HangerFlightとは
- 体験を語り合い，空を知る．
- →体験を語り合い，ソフトウェア開発/システム開発を知ろう．
- 具体的行動，経験→プラクティス→(別の人に伝える：HangerFlight)→プラクティス→行動
  - 経験から振り返りプラクティスを作成する
  - 問題意識があるからできるのでは．
  - プラクティスから制約ごとに行動を決める
- 上記の例として，朝会を知り，夕会をおこなう．

第1は，Javaとはったりと人の心
第2は，別のコミュニティから．
- PFP, Shibuya.Trac, HCDValueで世界を変える
補給：3.11とコミュニティ
第3は，福井さん：居酒屋，大谷さん：変えていこう，牛尾さん
第4は，話し合い
第5は，基調講演．

ひとりで出来ることは限られている
- 300人月
- 時間がない．

この現場の課題は向こうの現場では乗り越えているかもしれない
- ソフトウェア開発の難しさ/複雑さにWeで戦う

□「はったり活用法」より高く飛び，そして帰還するために

スピーカー：@yotii23さん
ruby,railsで開発
技術がそれほどないにもかかわらず，技術があるものと判断される．
- そのため，はったりかまさないといけない．
  - 軽く話をするつもりがいきなり要件定義に．
  - 言葉が社内用語
  - 不勉強の部分を突っ込まれる
はったりを使うと
- 客と良い関係
- 連帯感向上
- スキルアップ
良いものではないとわかっているが，客の信頼を得，良いものをつくる．
- 良いものを作るためには信頼が不可欠
はったりの三段階
- かます
- 巻き返す
- 本当にするor翻す
ハードルをあげる．

はったりの使いどころ
- 私が何を知っているべきことか．
- チームが知っていることか．
  - 誰が知っているべきことかを考えて，「私」が知っているべきこと．
- 危険回避
  - L1.私が知らなくて，客が知っているべきこと
  - L2.私が知らなくて，私が知っているべきこと
  - L3.私が知らなくて，私が知っているべきことで，チームが知っていること．←ここがはったり使いどころ

単語反応メソッド
- 知っている単語を拾う
- 確実に知っている内容だけで回答する
  - 嘘言うとあとが大変
昔取った杵柄メソッド
- 経験を匂わせる
- 最新情報を調べる時間を稼ぐ
共感メソッド
- 心情的に肯定する
- 分かりませんを前向きに言う．お調べしますなど．
- お客さんを味方にする

はったり心得三か条
- 常に自信を持って答えるべし
- 断言せずに，満足させよ
- 常に折れる覚悟をもて
  - 意地になったら負け

はったりの巻き返し方
- 前提を確認する
- 問いかけて，引き出す
  - 自分の理解を口にだして，問いかける
    - お客さんが答えやすい．
    - 誤解が早めに解けやすい
    - 共通認識の地合いが広がる
      - 敵はわからないこと．客と一緒に共闘している気持ちで
    - 図を書く
      - Cacooとか(システム構成図やチャットがある)
    - 用語集を作る
      - チームメンバーで共有を意識する
- チームに聞く
  - ネットワークを作っておく(Leafy,yammerなど)
  - 得意分野を知っておく
  - チーム内では正直に
    - 見栄を張ると致命的
  - 相談はできるだけリアルタイムに
    - レスポンスはリアルタイムでなくてもよい
    - わからない過程を実況

はったりの翻し方
- はったりを言う際に，早めのリミットを決めておく．
- しっかり謝る

はったり使用の注意点
- 使いどころを間違えない
- 帳尻をあわせる
- すぐ謝る

皆がわからないときは，時間を稼ぐ．
- 時間を稼ぐ際に，難しいなどの匂いをいれておく
わからないときは客に聞くのはどう考えるか？
- 業務知識を客に聞くことは悪いことではない

自分がnoといったことが実はyesだった場合はどうする？
- 私がわかったからこそ，yesなんだと言うのはどうでしょう．
ネットワークがない場合はどうする？
- あとでやる．メモ書く．
はったりを身につけるトレーニングは？
- 自分の実力よりも少し高いレベルのところで，金銭的問題が発生しないところ．
- ふられたことには，期待されているものと思いYESと答える．

□「今だからこその実践的プロジェクトファシリテーション」

スピーカー：松本屋さん(@j_matsumoto)
- プロジェクトファシリテーション4,5年
PFとは常に変化していることを自覚すること
プロジェクト結　#yuijapan
- 放課後支援，子供の支援．
聞きたいところを聞いて，それに対して語る場としたい．
話に関しては全部正しい．ただし，すべてを行なうのではなくその場でチョイスする

PFと言う言葉を聞くが内容がよくわからない
- PFは平鍋さんが作成した造語，こうだという明確な定義はないがやっていることはある．

PMとPFの違い
- PM的視点：現在と計画的なゴールを見て，差分を見て，やるべき事を管理する．
  - 目標ありきなので，道が少ない．
- PF的視点：現在を見て，その積み重ねから可能性を考え，ゴールが入っているか考える．
  - 選択肢を持ったままブレながらも良いゴールへ向かっていく．モアベター
- ゴールが可能性から外れていたら，ゴールへ行くための必要なものやゴールの変更などを考える・アクションを取ることができる．

変容のアプローチ
- 変えていくためにどうしたらいいか．
変容と変化の違い
- 変容は受容して変化する意味．
内発的動機(やりたいなど)→行く，やる
- 心から行動に結びつけて，変化させるアプローチ
外発的動機→やってみる，やらせてみる→お，いいじゃん→やりたい，となる
内発的と外発的は表裏一体
- スパイラル

変化の受容
- 周りが変化していることを感じる．
- ものごとを感じていないわけではない．
- プロジェクト内で様々なことがおきている．
  - それらを放ったらかしにしない．感じる．
  - 取られたなら，それを良し悪しとするのではなく，それからどうこうする．
- 感覚的に感じることを重視する．
- 上記はプロジェクトファシリテーターのこと
- その後は，感じたあとにこうだなーと思った行動をとる．

環境とは
- 自分のまわりにあるものはすべて自分になんらかの影響を与えている．
- 自分自身も含め，すべて環境．
- 誰からなにかやってもらいたい場合は，その人がそのことをやる環境を用意する．
  - 仮に見てもらいたいなら，見てもらう・気になるようにする
    - バーンダウンチャートや朝会やら．
  - 間接的に働きかけることが多い．直接的には，やるときにはやるが強制はしない．

PFは専任なのか．
- 専任でなくともよいが，しっかりロールを分けてやるほうがいい．
- PM的立場とPF的立場がコンフリクトする部分があるので，分けたほうがよい．
- 時期的にPFが居なくなっても良いのかもしれない．
なぜ”今だから”
- 考え方が変わってきている．

デジタルとアナログ
- 時計の例が良い例．
  - アナログは直感的．
  - デジタルは読んで理解しないといけない．
- アナログはプロジェクトの様子がわかりやすい
- デジタルはプロジェクトマネジメントしやすい．扱いやすい．
- どっちが良い悪いということはない

具体的にはどんなことをしたのか
- 2企業がいるプロジェクトがひどい状態．企業同士がいがみ合っている．
  - ただし，現場の担当者間は悪くない．社としては悪い．
- 皆の前で，会社間が仲悪いことを言った．でも担当者間は悪くない．など全部を言った．
- 評価をしない．
  - 「悪い状態になってますよね」
- 席を交互にした．
  - 2週間くらいで改善していった．

□システム企画を加速セヨ

スピーカー：@sandayuuさん
発想の準備
- 発想するときは，別の時が多い
- アイディアスパークは何かと何かが繋がるとき．
  - そうするように情報をあつめることは大事
  - スパークしやすい状態にしておく．
発想の抽出と整理
- 思考フレームワーク
  - MECEとか
- ファシリテーション

アイディアスパークとカオス
- 整理しておくとスパークしない
- カオスにしておくほうがスパークしやすい
- 嶋浩一郎のアイデアのつくり方
  - 真面目なこともどうでもいいことも書いておく．
- オブ脳は英会話や受験時代の話などがスパークして書いた．
- 普段からしておくと良い

ソフトウェアにおける企画の方法論
- 要求開発
  - 具体的なものがある，枯れている
  - 思ったより単純
- CSPO
  - アジャイル方面．
- UX
  - デザイナー方面
- どれでも良い
  - 何のためにおこなっているかを考えて取捨選択すると良い．

CSPO
- プラグマティックペルソナ
- 全部はカバーしていない感じ
  - 利害関係者との関係などは漏れている

サンプルお題
- iphone向けアプリビジネス
- 英語のステップ2をうまくやれないか(英語は絶対勉強するな)
- 企画からアプリ作り，ビジネスまで実施する．
  - 英語：ディクテーションで単語ごとではなく，一文ごとに聞き直す．
やったこと
- 企画の進め方を設計する
  - コンセプト，企画立案，評価/検証
- プロジェクトマトリクス
  - プロジェクトを中心にランダムに頭の中を書き出す
  - 整理しないのがポイント
- ビジネスモデルと原価計算
  - 設ける方法と，原価計算と収益の予測
  - 設ける方法
  - プロフィットパターン
  - ビジネスの継続性
  - 細かいところはExcelで計算
- 一枚提案書
  - プロジェクトのはじめの一歩は何をするか．
  - はじめの一歩は分かりにくい．漏れていることが明確になる
- ビジネスコンテキスト図(要求開発の方法)
  - 業務の全体像と利害関係者をとらえる
  - 図化することで全体像やまきこむべきひとがわかる
- 利用者ロール
  - どんな利用者がいるか抽出し，分類することで利用者のロールを抽出する
  - 上級/中級/初級など
- プラグマティックペルソナ
  - 利用者ロールの結果を活かして作成する
  - 重要な利用者ロール2つの利用者のモデルを，想定して作成する．
  - 具体的にモデル化する
    - この人ならどんな機能がほしいか
- 要求分析ツリー図(要求開発の手法)
  - 企業の戦略，要求の構造を可視化する
  - プロジェクトの上位目的を共有する
  - 何のためにプロジェクトをやるのか．
- ゴール記述書
  - プロジェクトの業務上のゴール・目標を定義する
  - プロジェクトが何を達成するのか．
- ユーザーストーリーマッピング
  - アジャイルのストーリ(要求)を抽出する
    - ストーリーを作成する，時系列のグループに分類する，グループごとに優先順位をつける，相対見積もりをおこなう，すべてのストーリお優先順位に並べる
    - ペルソナやゴールが明確になっていると決めやすい
    - 今回のものはここまでで5時間くらいでできた．
- 概念モデル
  - 概念の構造を可視化
- ペーパープロトタイピング
  - ローファイな紙ベースで臨場感あるユーザテストをおこなう
  - 実際にユーザーに触ってもらって，インタラクティブにおこなう
  - ユーザを観察しやすく，ユーザもイメージしやすい
  - 手書きのほうがよい．綺麗だとそっちに眼が向く．
  - 機能の必要性などもわかる
- アジャイル開発
  - 早期に実際のアプリを作って検証
  - 今の動向としては，イノベーティブな方向に進んできている．
    - ユーザー企業としては，手配師は不要になってきている．
      - 大手以外が見えるようになってきている．
  - これからはお客さんと直に話して作れる人が必要になるのではないか．
  - コンサルとしてプログラムできることが良いとされている

イノベーションを起こすためには
- 常に面白いものを探す
- カオスの状態にし，スパークさせる
- お金計算を鍛える
速さを高めるために
- アナログツールを使う
- モデリングツールを使う
実現力を高める
- 思いつきを実現するプラン/実行の方法があること
- 動くアプリで検証する
- 技術力

本番でも思いつきでもツール自体は変わらない
やってみることがよい
アジャイル時代のシステム企画方法論はそのまま使わずにカスタマイズせよ

□俺たちのハンガーフライト

会場アンケート
- 今日はどうでしたか
  - 結構よかった多数
- ふだんのお仕事は。
  - プログラマが半分くらい
- 自分にとって最も印象が残っているのは，どちらのHangarTalksだったでしょうか．
  - 分散した結果となった
- 今回のHangarFlightは自分のどんな問題と結びつくか
  - キャリアの課題が4割強
  - 例：それぞれのアプローチはバラバラだが，悩みはキャリアだった．
  - 例：各自課題意識があったことがわかった．同じ考えでも別の課題としてとらえていることがあった．

今日のHangerFlightは自分の課題にどのように生かせるか，
- 1つのきっかけにすることとして生かす
- 当たり前のことを実行出来ていないが，当たり前のことが正しいとわかるので，勇気として生かせる．自分も頑張ろう的．
- 本棚広げる/本棚に本が入る感じ
- 言葉にすることにより，勇気などが得られる．
- 提案活動にもペルソナが使えるかも．

□「次の時代を作るのは、老人ではない。」　ボースンの白昼夢

スピーカー：@jojoAtHanawaさん

普通のベテランプログラマとしてきた
ソフトウェア開発は誰でも工夫することができる

エンドユーザに喜んでもらうために，色々した
よくも悪くも業界の一部を作った

自分の役目は新しい技術を社内に広めること

企業向けシステムは皆に任せる
狙っているのは，街の荒物屋，学校のIT用務員などなど

RubyのWinOLE32は必携

やれることを実践しましょう
- 助けてくれることはない．
- 価値を認めてもらうしかない．
- 現場での実践をあきらめない，効果を測定する．