最速!「見える化への挑戦2」 - 行動と変化へ繋ぐ「見える化」セミナーレポート
というわけで行ってきました。とても参考になったのですが、6時間はちょっとキツかったなぁ。風邪気味なのもあって、鼻をズビズバ&パパパヤーと言わせておりました。
資料が配布されなかった為、内容は全て私のメモによります*1。間違いがありましたらご指摘願います。
「見える化 はじめの一歩、そして二歩三歩」橋本 正徳(id:m-hashimoto)氏
- 行動から変化へ
- 「見える化」とはなにか
- アジャイルへの拒否反応
- 過去の経験と新しい知識の融合が大切。WFを否定するわけではない
- ヌーラボでの「見える化」実例紹介
- 「見える化」の実践
- 会社という超リアルな現実(うちでは「見える化」なんてできないんじゃないの?)
- 東京で流行っているだけなんじゃないの?
- 対策は?
- コミュニティを使え!
- AIP - 高度IT人材アカデミー
- 社団法人福岡県情報サービス産業協会
- XPJUG-Q
- これ最近活動してるの?
- Java@九州
- 立ち上げは9月9日。私も行きます。
- SICP読書会
- オブジェクト指向読書会
- オブジェクト指向をネタに居酒屋で飲むらしい。←混ぜて欲しいと思った
- SoftWire Fukuoka
- ググっても出てこなかった。詳細不明
- キーワードは「脱社内!」
「現場力を高める見える化手法プロジェクトファシリテーション」平鍋 健児氏(An Agile Way:オルタナティブ・ブログ)
- 計画→実行のプロセスはシステム開発に向かない
- 「見える化」とは?
- 正の状態が一箇所に大きく見え、全員が情報を共有できること
- 野球のスコアボードが例にでてた
- 正の状態が一箇所に大きく見え、全員が情報を共有できること
- 「見える化」ツール
- バーンダウンチャート
- かんばん
- ToDo/Doing/Doneで管理
- 作業を指示するのではなく、自らサインアップさせる
- はてなの「あしか」みたいなもの
- 朝会
- 必ず15分で終わる
- 長引きそうなのは2次会をやる
- これも「はてな」でやってたなぁ
- 色つきUML
- ペアボード
- 2人、もしくは1人に1枚ホワイトボード持ち問題を共有。「問題vsわたしたち」構図を作る
- ふりかえり
- 繰り返すことによりプロセスを改善させる
- プロジェクトやリリースの回顧
- タイムライン
- プロジェクトを時間軸で振り返る
- 個々人の物語をチームの物語として表現
- にこにこカレンダー
- リリース毎におおきな「ふりかえり」を。この後には打ち上げを(必ず!)
- マインドマップ
- PFの5つの価値
- コミュニケーション
- 必要な人と、必要を感じたときすぐ、対面で話をしていますか?
- チームとして個人の総和以上の成果を上げるために、「コミュニケーション」を価値とします
- 行動
- あなたの言葉に、行動はともなっていますか?
- 価値を現実のものとするために、そして気づきを得るために、「行動」を価値とします
- 気づき
- 今日、何かに気づきましたか?気づきを、毎日誰かに話していますか?
- 個人そしてチームが成長するために、「気づき」を価値とします
- 信頼関係
- あなたはチームのメンバーを信頼していますか?チームのメンバーはあなたを信頼していますか?
- 行動を起こす勇気の源として、「信頼関係」を価値とします
- 笑顔
- 人からの非難をおそれてびくびくしていませんか?冗談を言える雰囲気はありますか?今日、みんなの笑顔は見えますか?
- 人生の貴重な時間を楽しくすごすために、「笑顔」を価値とします
- コミュニケーション
「よくわかる要求開発入門と事例」萩本 順三氏(株式会社豆蔵)
私自身、要求開発の経験が無い為、理解が不十分。要件定義の経験も殆どないため難しかったです。
なので、印象にのこったキーワードのみ列挙します。
「ユーザ中心の設計」比嘉 康雄氏(id:higayasuo)
比嘉氏の説明は非常に分かりやすく、実践的なもので非常に有用でした。ただ私の場合は上流にかかわる立場にないのが問題なんですよね…。
- ユーザーにとっての「見える化」
- ユーザの真の要求
- 要求の「見える化」
- ユーザ中心の設計へ
- UIスケッチ
- 紙で入出力項目・ラベル・リンク・ボタンを書く
- それをホワイトボード等に貼り画面遷移の状態を表す
- 紙で書くというのは面倒なことなので自然と画面がシンプルになる
- UIスケッチ検証・確認・修正
- ラベルに同じ項目なのに違う名前はないか?またその逆は?
- ラベルがテーブル設計の入り口の役目も果たす
- 早い段階でウォークスルーができるためリスクを軽減。ユーザの頭の中になる要求を可視化
- ウォークスルーで「見える化」→「ためす化」
- UIスケッチでHTMLを使うと
- レイアウトに凝ってしまいがち
- 本質的なことを見失ってしまう
- 画面のない場合は?
- 帳票でもバッチでも入出力はあるわけなのでスケッチしたらいいじゃないの?
- 外部設計の「見える化」
- 要件をシステムに落とし込む(画面・帳票・業務ロジック)
- ポイントはユーザがレビュー可能なものであること!
- 成果物
- UIスケッチ
「ドロドロ仕事をサラサラ仕事に!マジカ!を使って仕事の迷路を抜け出そう」羽生 章洋氏(id:habuakihiro)
一番面白かったです。よってメモが少なめ…。まさに本末転倒。
- 成長のステージ
- 知る
- やる
- できる
- 理解する
- 見つける
- AsIs(現状)→Tobe(あるべき姿)へ
- 現状を分析(業務分析)して問題の核を発見、そして解決へ
- でも業務フローって難しいよね…
- そこで「マジカ!」
- 途中からシャツを脱ぐ
- 私は何をメモしてるんだ…
- まず断片からでもいいのでマジカに書き出す
- ポイントは後肯定から前工程へ
- 業務フローの緻密さは程々に。
- 現状をよりよくするために業務分析を行う。あくまで手段、目的ではない
まとめ(私の気づき)
「見える化」を突き詰めると最終的にはアナログ(紙・ホワイトボード)に行き着く。人と人との情報共有はデジタルよりアナログが有効である。
番外編
- 橋本氏のTシャツ(Planet Of The Apes)
- 比嘉さんはオシャレ(あとヒゲが濃かったので親近感が沸いた)
- 羽生さんのシャツ(原色)。pptの表紙に「I Love Fukuoka」(でも関西弁。福岡のどこらへんが好きなんだろう?)