最速!「見える化への挑戦2」 - 行動と変化へ繋ぐ「見える化」セミナーレポート

というわけで行ってきました。とても参考になったのですが、6時間はちょっとキツかったなぁ。風邪気味なのもあって、鼻をズビズバ&パパパヤーと言わせておりました。
資料が配布されなかった為、内容は全て私のメモによります*1。間違いがありましたらご指摘願います。

見える化 はじめの一歩、そして二歩三歩」橋本 正徳(id:m-hashimoto)氏

「現場力を高める見える化手法プロジェクトファシリテーション」平鍋 健児氏(An Agile Way:オルタナティブ・ブログ)

資料(PDF)

  • 計画→実行のプロセスはシステム開発に向かない
  • 見える化」とは?
    • 正の状態が一箇所に大きく見え、全員が情報を共有できること
      • 野球のスコアボードが例にでてた
  • 見える化」ツール
    • バーンダウンチャート
    • かんばん
      • ToDo/Doing/Doneで管理
      • 作業を指示するのではなく、自らサインアップさせる
        • はてなの「あしか」みたいなもの
    • 朝会
      • 必ず15分で終わる
      • 長引きそうなのは2次会をやる
        • これも「はてな」でやってたなぁ
    • 色つきUML
    • ペアボード
      • 2人、もしくは1人に1枚ホワイトボード持ち問題を共有。「問題vsわたしたち」構図を作る
    • ふりかえり
    • 繰り返すことによりプロセスを改善させる
      • プロジェクトやリリースの回顧
      • タイムライン
        • プロジェクトを時間軸で振り返る
        • 個々人の物語をチームの物語として表現
        • にこにこカレンダー
      • リリース毎におおきな「ふりかえり」を。この後には打ち上げを(必ず!)
  • マインドマップ
    • ドラゴン桜」でいうところのメモリーツリー
    • 頭の中の見える化
      • 中心に話題をおいて
      • 放射状にキーワードを書く
    • すばやいノート術として
    • 自己紹介として
    • どちらかというと
      • ブレインストーム
      • アイディア書き出し
      • アウトラインなどの発散系ツール
  • PFの5つの価値
    • コミュニケーション
      • 必要な人と、必要を感じたときすぐ、対面で話をしていますか?
    • チームとして個人の総和以上の成果を上げるために、「コミュニケーション」を価値とします
    • 行動
      • あなたの言葉に、行動はともなっていますか?
      • 価値を現実のものとするために、そして気づきを得るために、「行動」を価値とします
    • 気づき
      • 今日、何かに気づきましたか?気づきを、毎日誰かに話していますか?
      • 個人そしてチームが成長するために、「気づき」を価値とします
    • 信頼関係
      • あなたはチームのメンバーを信頼していますか?チームのメンバーはあなたを信頼していますか?
      • 行動を起こす勇気の源として、「信頼関係」を価値とします
    • 笑顔
      • 人からの非難をおそれてびくびくしていませんか?冗談を言える雰囲気はありますか?今日、みんなの笑顔は見えますか?
      • 人生の貴重な時間を楽しくすごすために、「笑顔」を価値とします

「よくわかる要求開発入門と事例」萩本 順三氏(株式会社豆蔵)

私自身、要求開発の経験が無い為、理解が不十分。要件定義の経験も殆どないため難しかったです。
なので、印象にのこったキーワードのみ列挙します。

「ユーザ中心の設計」比嘉 康雄氏(id:higayasuo)

比嘉氏の説明は非常に分かりやすく、実践的なもので非常に有用でした。ただ私の場合は上流にかかわる立場にないのが問題なんですよね…。

  • ユーザーにとっての「見える化
  • ユーザ中心の設計へ
    • UIスケッチ
      • 紙で入出力項目・ラベル・リンク・ボタンを書く
      • それをホワイトボード等に貼り画面遷移の状態を表す
      • 紙で書くというのは面倒なことなので自然と画面がシンプルになる
    • UIスケッチ検証・確認・修正
      • ラベルに同じ項目なのに違う名前はないか?またその逆は?
      • ラベルがテーブル設計の入り口の役目も果たす
      • 早い段階でウォークスルーができるためリスクを軽減。ユーザの頭の中になる要求を可視化
      • ウォークスルーで「見える化」→「ためす化」
    • UIスケッチでHTMLを使うと
      • レイアウトに凝ってしまいがち
      • 本質的なことを見失ってしまう
    • 画面のない場合は?
      • 帳票でもバッチでも入出力はあるわけなのでスケッチしたらいいじゃないの?
    • 外部設計の「見える化
      • 要件をシステムに落とし込む(画面・帳票・業務ロジック)
      • ポイントはユーザがレビュー可能なものであること!
      • 成果物
        • UIスケッチ→UIモック(紙からHTMLへ)
          • ここでも検証・確認・修正を
          • なぜ必要→プロジェクトが進行するにつれてユーザの「見える化」が進むから
          • 入出力漏れ・例外処理とか
        • 操作シナリオ
          • マニュアルというほど、精密なものを作らない
          • 正常・異常ケース
          • メッセージ
            • 状況メッセージ(xxxを受け付けました)
            • 例外メッセージ(xxxの在庫はなくなってしまいました)
            • オペレーション誘導メッセージ(xxxの在庫はなくなってしまいました。カートから削除しますか?)
          • 教育資料も兼ねよう
        • 操作レシピ
          • アクションの際のシステムの振る舞い
          • ユーザがレビュー可能であること!
          • ユーザへのインタビューを綿密に行う

「ドロドロ仕事をサラサラ仕事に!マジカ!を使って仕事の迷路を抜け出そう」羽生 章洋氏(id:habuakihiro)

一番面白かったです。よってメモが少なめ…。まさに本末転倒。

  • 成長のステージ
    • 知る
    • やる
    • できる
    • 理解する
    • 見つける
  • AsIs(現状)→Tobe(あるべき姿)へ
    • 現状を分析(業務分析)して問題の核を発見、そして解決へ
    • でも業務フローって難しいよね…
    • そこで「マジカ!」
    • 途中からシャツを脱ぐ
      • 私は何をメモしてるんだ…
    • まず断片からでもいいのでマジカに書き出す
    • ポイントは後肯定から前工程へ
    • 業務フローの緻密さは程々に。
    • 現状をよりよくするために業務分析を行う。あくまで手段、目的ではない

まとめ(私の気づき)

見える化」を突き詰めると最終的にはアナログ(紙・ホワイトボード)に行き着く。人と人との情報共有はデジタルよりアナログが有効である。

番外編

  • 橋本氏のTシャツ(Planet Of The Apes)
  • 比嘉さんはオシャレ(あとヒゲが濃かったので親近感が沸いた)
  • 羽生さんのシャツ(原色)。pptの表紙に「I Love Fukuoka」(でも関西弁。福岡のどこらへんが好きなんだろう?)

*1:平鍋氏の資料はオブジェクト倶楽部にあります。平鍋氏の章に資料へのリンクをしています

*2:Keep Problem Try