『DevLOVE2012 - 周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』ノート

2012/12/15に開催された『Devlove2012 - 周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』のノートです



◆講演者（中村洋氏）について

◇自己紹介
・大阪在住のエンジニア
・認定スクラムマスター
・5社くらいを2,3年くらいで渡り歩いてきた

◇コミュニティ活動
・devlove関西
　→セッション10個
　→100人を超える申込者があった
・スクラム道関西
　→アジャイル実践者が集まる
　→ワークショップでアジャイルの普及
・デブサミ関西
　→来年は実行委員長　

◇今日一番伝えたいこと
・「ええと思ったらやっていこう」
・人間、やらない理由はいくらでも出せる
　→それだといつまでたってもできない
・そういう思考にそもそも入らないことにした
・フィードバックをもらうようにした
　→厳しいフィードバックもある
　→→でもそれがあれば方向転換、突き進むなど考えることができる
・フィードバックを得る環境を作ることが重要（仲間など）

◇自分戦略の源泉
・基本路線
　→「ええと思ったらやっていこう」
・三つの柱
　→チームの成長
　→エンジニアをつなぐ
　→スパイラルな成長

◇自分の源泉にあるもの - チームの成長
・仕事の仲間が成長していくのを見るのが好き
　→時間、品質などが良くなっていく
　→振り返りで成長している様を見られるのはうれしい
・成長させるのではない
　→成長するのは彼自身
　→成長できる環境を精一杯整える
　→自分の経験を話すことはある
　→→でも押し付けはしない
　→しょうがない環境があれば整える
　→→たやすく成長できるように
・「自分達でできるからお前はもういらない」
　→こう言われるのが夢

◇自分の源泉にあるもの - エンジニアをつなぐ 
・自分には世界を変えるようなコードは書けない
　→でも、そういう人をつなぐのはちょっと上手かもしれない

◇自分の源泉にあるもの - スパイラルな成長
・主に自分自身へのモチベーション
　→同じところをぐるぐる回るのはいや
・次に会ったときお土産を渡したい
　→数ヵ月後も同じレベルのアウトプットをしているのはいや
・「この人と接点があれば自分にとってプラスなんだ」
　→そう思われる存在でいたい
　→でも他人にお土産を求めているわけではない

◇誰かの役に立ちたい
・これはみんな持っていると思う

◇そのためにどうするか
・自分でハンドルを握る
　→周りに影響されずに自分の判断で
・そのために4つのことをやる

◇自分でハンドルを握るための4つのこと

・やりたいことを表明する
　→半年に一度の評価面談ではみんな話す
　→→でも日常からやっている？
　→言っているつもりでも全然伝わっていなかったりする
　→→表明してやっていくこと = 自分のやりたいことをやる第一歩
・爪を砥いで準備
　→表明するだけでは駄目
　→→準備してるかどうかは表明の真剣さにつながる
　→→→やっていた方が回りは認めてくれる
・雪かきをやる
　→他の人がやりたがらないこと
　→チームでやっているとそういうタスクが発生する
　→→そのときに積極的に手を上げて拾っていくことを心がける
　→→→信頼貯金が出来る
　→そうすると、いいボールが回ってきたときにそれをまわしてくれる
　→ムダだと思われているタスクは、自分が好きに出来る
　→→効率化したり作業自体を廃止したりできる
　→→→チームのためになる
・仲間を見つけて巻きこむ
　→人間1人だとダークサイドに落ちやすい
　→言い訳もしやすい
→「それは違う」と言ってくれる仲間は重要



■エピソード

◆とあるお客様にて(10年くらい前）

◇コンテキスト
・100人くらいの開発会社
・ほとんどお客様先に常駐
　→自社には月に一回帰る

◇ここは面白かった
・こういうところはたいがいつまらない
　→ここは違った
・技術的にとがっている人もいた
・常駐先のお客様がいろいろやらせてくた

◇前提
・お客様と自社の両方に信頼貯金があった
・何回か社内勉強会やっていた
　→でもうまくいってなかった
　→平日帰ってきた後
　→→なかなかやらない
　→客先常駐なので、普段は顔を合わせない
　→→休日にわざわざそういう人と会おうとは思わない

◇こういう状況の中での問題
・独りでお客様先へ行くことが多い
　→目の前のタスクでいっぱいいっぱい
　→→技術を学ぶ機会がない
・結果として若手のモチベーションが低い
　→言われたことだけやればいい
・これはもったいない

◇アクション
・チームに若手をどんどん引き入れていった
　→本社に戻ったとき、姿勢のある若手とかいたらチームに引き入れる
　→姿勢を重視
・ペアプロやレビューなど一緒に考える時間を多く取った
　→タスク渡して放置という現場が多いがそうやらなかった
　→→そういう時間を徹底的にとった
・魚ではなく魚の釣り方を教えた
　→最初は釣れない
　→→何回かやると釣れるようになる
　→→→そのうち改善するようになる
・機能で分けてシステム開発
　→工程で分けない
　→「若手はとりあえずテストでも…」ではない
　→→そうではなく、縦串で一通り任せる
　→→→そうすると横のことも判る
　→小さな開発だったのが功を奏した

◇起こったこと
・人を集めすぎたので自分の仕事が回らなくなった
　→朝早く仕事を開始
　→→同じ勤務時間でも、残業するよりはるかに仕事ができる
・指示待ちではないやり方を知ってもらった
　→考えることでやりがいをもてるし、楽しくできる
　→自分でいかようにもできる
　→→ただ、全員がそうなったわけではない
・会社の数字にも貢献できた
　→若手をどんどん引き入れたので

◇ここでのまとめ
・社外常駐でもやりようがある
　→成長もできるし仲間も作れる
　→諦めたりやらない理由にはしない
・自分で仲間を見つけて巻き込もう

◇わざわざなんでそんなことをやるか
・もっと顧客に価値を届けたい
・若手にこうすればいいのではと伝えたい
・そういう情熱があった

◇何で辞めたか
・会社が派遣主体に
　→「翌月から○○に行って」みたいなのが多い
・チームから優秀な若手がはがされる
　→彼らが転職してよい会社にいく
・もういいかなとなった



◆某SIer

◇コンテキスト
・6000人規模でサラリーマンSEはそれなりに多い
・とんがった人もたくさんいた（る）
・人材輩出企業

◇自分の状況
・本部系部門で社内向けフレームワークやツールを作成
・Redmineやjenkinsなど生産性向上のセミナーや勉強会の開催

◇問題
・勉強会に参加者がなかなか集まらない
　→本社での開催ではそこそこくる
・これからとんがるかもしれない人達をつなげることができていない
　→これからとんがろうとしている人が現場にはそれなりにいたにも関わらず

◇アクション
・ローラー作戦
　→声を掛けまくった
　→メール・社内SNS・ランチ
　→→とにかく話しかけるようにした
　→社内SNSでのみ面識がある人に、出張したときに直接会った
　→→そうやって一本釣りした
　→10人に声をかけて1人釣れると成功だと思う

◇ポイント
・全員が社内勉強会に熱心なわけではない
　→大きい会社なので「粛々と定年まで給料をもらえればいい」という人もいる
・相手が何を求めているかを考える
　→相手のメリットや不安を聞く
　→→「今の業務ではすぐに役に立たない…」
　→→「業務時間内なので上司の許可が…」
　→→「勉強不足で怖くて…」
　→→→すぐに使えるコンテンツを入れたりハンズオンして手取り足取りで教える
　→→→相手が欲しいものを聞いて、内容を調整する
　→→→マシンを持ってきてもらって明日もって帰って使えるようなもの提供する
・一部や全部を業務時間外に開催する
　→「残業代はどうするのか？」という声
　→→そういう人は放っておく
　→組織がそういうことを言うなら、それはさっさと見切りをつける
・もっと上の人に働きかけてお墨付きをもらう
　→上にの人はもっと人材育成とかそういう目線がある
　→→彼らを口説く
　→現場の人は目先のプロジェクトを見てしまう
・社外勉強会をそのまま持ち込む
　→休憩の時間に見に来てもらう
　→→突然当てられることや怖いこと、そういうことはないということを知ってもらう

◇Fearless change
・人が取るアクションには理由がある
　→こういう組織はアーリーマジョリティが一番多い
　→→アーリーマジョリティを巻き込むためにアーリーアダプターをいかに巻き込むか
・流れが出来れば自然にいける
　→参加した人が、自主的にコミュニティを作ったりするように
　→各部門にバラバラにいたリーダー達に連携が
・大きな組織でもうまく巻き込めば仲間を見つけコミュニティを作れる
・社外コミュニティの情熱で社内に（小さな）変化をもたせる
　→パッション大事

◇なんで転職したか
・数千人が変わるのを待つには人生は短い
　→1割でも変わればいいかとおもった
　→→だけどそれも遠かった
・ユーザの声をもっと聞きたかった
　→大きい会社なので間に他の部門が入ってしまう
・カットオーバー後の話をする機会がない
　→そもそもチームが解散したりとか



◆今の会社

◇状況
・自社プロダクトサービスを作っている（ウェブブラウザ）
・職人肌のエンジニアが多い
　→毎朝にgithub3時間使う人とか
　→窓の社でノミネートされてるとか
・勉強会主催者もいる

◇やってること
・現在進行形で巻き込みしている
・3チームのスクラムマスタ
・部門の障害をやっつけたりもする

◇問題点
・ドライブ力が物足りない
　→職人肌の人は自分である程度の問題設定を作れる
　→→それを片付けることもできる
　→でもビジネスとかユーザが苦手
　→→そこの突破力がない
・開発プロセスが未成熟
　→個人は当たり前のようにテストなどやっている
　→→でも、組織としてみると俺々ルールが多い
　→方向を間違えなければいいところにいくのに…

◇入ってやったこと
・姿勢を見つめなおしてもらう
　→正解がない問題を自分達で考えるように
　→よいブラウザって？
　→→答えはない
　→→→使ってみて始めてわかる
　→仮説検証する姿勢重要
　→→そういう取り組みをするようにする
・フィードバックを正面から受けられるように
　→厳しいメッセージにも目を背けずに
　→→そこから一生懸命考える姿勢を
・透明性を維持する
　→朝会で自分のことを素直に話せる人ってどれだけいる？
　→→上司の進捗会になっていることが多い
　→→→それは朝会じゃない
　→自分でタスクを取り、周囲が助ける
　→→自分達で判断してやっていく

◇入ってやったこと
・ふりかえり
　→wikiにいろいろ書いてもらう
　→→書いてどうするの？
・テストコードがない
　→テストを書こう
　→→こんなの意味ない
　→→→こういうのを改善した
・タスクボード
　→redmineを使っていたけど…
　→→進捗はよくわからない
　→タスクボードを作った
　→→朝会に持って行ったりしている

◇姿勢を変えるために
・社内勉強会
　→『チーム力を上げる"朝会"のコツ』
　→プロダクトオーナー勉強会
　→ユーザストーリの作り方
・結果
　→自律的なチームになりつつある
　→チームのアジリティも上がりつつある
　→→まだまだこれからできることがあると思う



◆最後に

◇コミュニティについて
・様々な経験を持ついろいろな人達の集まり
・それをどう使うかは自分次第
　→話を聞いて終わるか
　→自分のコンテキストに合わせて使うか
　→使った結果からさらに相談したり
・仲間とめぐり合う部隊

◇何時に起きてるか
・22:00に寝る
　→3:00に起きる
　→→6:00に会社
　→→→9:30に始業

◇情熱はすごく大事
・でも1人で燃やし続けるのは難しい
　→周りを巻き込みように
　→社内にいなければコミュニティで
・巻き込まれてくれている仲間にThanks!

◇「ええと思ったらやっていこう」
・「もうこんな年だから…」「こんな状況なので…」
　→自分が勝手に作っている制約
・いいと思ったらその日から始める






中村洋様、CyberAgent様、DevLOVE様、ありがとうございました。

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 2 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートです。間が空いてしまったので、パート1と2に分けました。

パート1はこちら


◆岩崎 奈緒己氏「分散スクラム」

オフショア & スケーリング（複数チームが連携してスクラム）について


◆海の向こうのスクラム（オフショア）問題と改善
・無理だと思う人たくさんいるのでは？
　→JIRA, Redmine
　→skype

◇問題：全員が映っているわけではない
・ビデオ会議なので起こる
　→誰が誰に話しているか分からない
　→こっちは盛り上がっているが、あっちは…
・解決
　→呼びかける
　→→「○○さんに質問です」
　→実況中継
　→→「○○がいます」
　→→「相談中だから待ってください」

◇問題：途切れる声
・「……が………の……………でいいですか？」
　→大事なときにこそ起こる
・解決
　→チャット
　→→話をしながら打つ
　→ビデオ
・会議用スライドを画面で共有する
　→アジェンダを写しながら話す
　→→その場でスライドに成果を書き込む
・直接行って会う
　→ぜんぜん違う

◇海の向こうのスクラムのまとめ
・特別なツールがなくても話し方やちょっとした準備で改善することが多い
・直接会ってどんな人か知ることが一番効果的（特に初期）


◆チーム連携（一箇所で複数チーム）問題と改善
・リリースバーンダウンを並べる
・全体の課題のためのボードを作る
・同期を作るためにマイルストーンのボード
・体制図

◇問題
・スプリント計画、レビューとか人が多い
　→合戦みたいになっている
・プロダクトバックログが大きい

◇2段階の会議
・多すぎる会議
　→基本はチーム単位で行うこと
・Scrum Of Scrumで連携
　→チームをまたぐ課題は別の会議体で

◇ストーリーマップ x バックログ
・1枚のシートに大量の項目・文字があったので対策
　→プロダクト全体をストーリーマップで表現
　→各チームごとのプロダクトバックログを作成
　→細かい受け入れ条件は別シートへ

◇スケーリングする場合のまとめ
・複数チームに関係することを話し合う会議体が必要
　→そうしないと「あのチームこんなことやってるの？」「聞いてないよ」とか生まれやすい
・各チームがプロダクトの全体像をつかめるような資料が必要
　→各チームが何やっているかは全体像があればだいたい掴める


◆崩れてしまったときの心の持ちよう

◇うまくいっていない場合
・みんなが「これでいいじゃん」で進めてしまった
　→「なんかおかしい。いや、絶対おかしい」となった
・オフショア・大規模だと問題が起こりやすいし複雑化しやすい
　→起こっても見えにくい
　→→チームではうまく行っていてもプロダクト全体では問題とか

◇止める
・そういうときは止めないといけない
　→まずはプロダクトオーナーに相談
・非効率なスプリントを中止する
　→冷静になりましょう
　→大きいものは小手先でやっても上手くいかない

◇消す
・でも緊急でやるべきことはやり切る

◇組みなおす
・情報を整理していく
　→大きなものから小さなもの
　→荒いものから細かいもの
・インセプションデッキが狂っているのにプロダクトバックログを直しても意味が無い

コンセプト
□□□□□□□□
□□□□□□□□
↓
ワークフロー・ストーリー
□□　□□　□□　□□
□□　□□　□□　□□
↓
タスク
□　□　□　□　□　□　□　□　
□　□　□　□　□　□　□　□


◇要求以外でも重要な情報は整理
・検討課題
・リスク
・周知、情報共有

◇1つずつ着実に行う
・みんなが見えるように
　→でも早く
　→→改善疲れが出てくるので

◇巻き込む
・1人でやっていても、周りがしらける
　→息が続くうちに
　→みんなが見放す前に

◇まとめ
・いかに状況を早く見える化するか
・いかに改善が目に見えるようになるか
　→それぞれ掛け算になっている
・プロセスを止めるのも組みなおすのも全員が疲れる
　→巻き込む気力とスピードが肝
　→引っ張るのではない

◇最後に
・『小さな工夫、大きな成果』が大事
　→大規模・オフショアって大きく見えるが、大事なのはちょっとした小さな工夫
　→→それを着実にやれるか
・できないのはそういう工夫を飛ばしているから
・誰がやるか
　→皆で
・ピラミッドになっていて「あの人が言ったからやる」ではない



◆上田 佳典氏「はじめての自己組織化」

◇自己組織化とは何か
・自分の言葉で説明できる？
　→脱コマンドアンドコントロール
　→タスクをアサインしない
　→クロスファンクション
　→優れたチームワーク
　→→いろいろある

◇ここで動画
・self-organization in hanoi traffic



　→信号がない
　→警官がいない
　→それでも自分達で状況理解・判断・行動
　→→外から指示されないというのがポイント
・『チームとして』最適な方法を自分で判断し行動すること
　→『自分として』ではない

◇どういう観点で考えるか
・ビジョン・ゴールを共有する
 →QCD + S
・長期的・短期的で考えることができる
　→ノウハウ共有
　→チームとPOの教育
　→→といった観点を踏まえ、自己判断で行動できるように
・全部インセプションデッキで話す内容
　→インセプションデッキを作って総合判断する
・デッキを作ったら放置でよい？
　→そうではない

◇スクラムマスター・プロダクトオーナー・管理職は自己組織を加速するためにどうすればよいか？
・補助輪になる

◇自分で考えて動くってどういうこと？
・自動車教習所で教わること
　→認知
　→判断
　→操作（行動）
・人が行動して失敗するときはこのどれかの段階でつまづく
　→スクラムマスター・プロダクトオーナー・管理職はつまづく原因を取り除く
　→→特に認知・判断をしっかりサポートする
　→→→ウォーターフォールの人に対しては特に重要

◇プラクティスで気をつけること
・朝会
　→個人のタスク整理ができていない
　→→状況と自分自身がやることを認知できていないから
　→朝会前にリマインド
　→→朝会前に整理するフェーズを入れられるように

◇それでも3つの共有事項がいまいちなことが…
・正直な思いを伝える
　→チームに共有事項の感想を求める
　→→そうやって自分の立ち位置を理解してもらう
・タスクを選べない
　→背中を押す
　→→「失敗してもいい。取っていい」
　→→→今まで失敗しないように仕事していると安全側に倒したがる
　→WIP(work in progress)の制限
　→→自分自身がやることをはっきりさせる
　→WIPがよくわからないならペアワーク
・プランニング
　→ストーリーの実装方法が分からない
　→→スキル不足
　→→消極的
・メタ情報の収集不足
　→プロダクトオーナーに聞けばわかることを聞けない
　→→請負根性
　→→スキル不足
　→プランニングで意見を求める（設計・実装・ストーリーポイント）
　→→「どう思う？」積極的に聞く

◇ポイント
・情報収集する
・自分で考える
・成長する

◇ふりかえり
・課題意識の欠如
　→KPTの希薄化
　→どこか他人事
・自分自身の成長戦略を立てられない
　→TRYがプロダクトの話ばっかり
・本音KPT
→本音で喋れる場をまず作る
→→楽天の藤原さんは、まずリラックスできる場を作るという
→期待を出し合う
→→「どうなって欲しいとか」お互いに求めるものをお互いに出し合う
・根本原因分析
→開発をやっているとじっくり考える暇がない
→→時間が無いならKPTせずにいきなり根本原因分析をするのもあり
→→→ゲームストーミングのSquid（イカチャート）
・じっくり考えることが重要

◇革新会議
・じっくり考える時間がない
　→でも重要
・成長するエンジンが欲しい
　→あればほうっておいても成長してくれる
・従来型の報告会議をビジョン・ゴールのメンテナンスの場にしてみた
　→自分の成長戦略を考える場に
　→→やり方はチームに任せる

◇大事だと思ったこと
・自橙明
　→釈迦が亡くなるときの話「自分で考えて決めろ」
・自分が明かりになって道筋を明るく照らす
　→自らが常に意思決定に関わるように

◇これまでのやり方が通用しないのは何故か
・他人が過去に決めた仕組みやルールだから
　→これからは状況に応じた"意思決定"自体が重要になる
・ソフトウェア開発でも適切なカードを切るスキルが求められる時代に

◇"答え"ではなく"答えを出す方法"を学ぶ
・でもそれだけじゃ足りない気がする

◇神々の意識改革
・お偉いさんの意識を変えてもらう
　→チームや個人を信頼し許可を与える
　→→そういう上司の一言と後押しは心強い
・神々からの支援
　→チームが解決できない問題を解決してみせる
　→→会議室の予約・組織をまたいだ勉強会etc.
　→→→社長に直談判して、社長を通して解決してもらったことも
・アジャイルのゴーサイン

◇まとめ
・チームとして最適な方法を自分で判断し行動すること
・観点
　→ビジョン・ゴールを共有する
　→QCD + S
　→長期的・短期的で考えることができる
　→ノウハウ共有
　→チーム・POの教育
・補助輪
・認知、判断、行動
・神々の意識改革
・信頼、許可、支援

◇最後に
「コマンドアンドコントロールからさよなライオン」

岩崎 奈緒己様、上田 佳典様、スクラム道様、ありがとうございました。

【チラシの裏】今日の送別会の帰り道に思ったこと

2007年の4月、社会人になって初めての給料をもらった週末、電車がなくなる時間まで飲み、そして歩いて帰った。

サラリーマンとして稼いだお金でお酒を飲んだというささやかな満足感とか、これから始まる社会人としての人生に対する晴れやかな気持ちであるとか、今日飲んだ同期の仲間達とずっとやっていきたいという希望とか、自分の世代が今以上に会社を盛り上げていくのだという野望とか、一生懸命勉強して優れたシステムを作るのだという向上心とか、いろいろな気持ちを抱えてワクワクしながら歩いた。社会人として成長していく自分のことを思うと、明日のことを考えるのが楽しくて仕方がなかった。

そして、本日付で私は会社を辞めた。明日から別の会社に勤めることになる。

昔の常駐先の職場の先輩が送別してくれることとなり、普段いかない場所で飲み、自転車に載っておらず、飲んでばかりだったので締めのラーメンが必要　…など、いろいろな条件が重なり、たまたま5年半前と同じ道を歩いて帰ることになった。

キラキラした何かを抱えていたあの日の自分と、その会社を辞めたという半ば冷めた気持ちを抱えている今の自分が同じ道を歩くという偶然に驚きながら、当時のことを思い出したり、今の自分に重ねてみたりしながら帰った。

やりたいことを貫き通すために会社を飛び出したのだという覚悟や、新しく迎えてくれる仲間の期待に応えることへのプレッシャーなど、今の自分には向き合わなければいけないものがあって、だから当時のような純粋で晴れやかな気持ちで歩くことはできなかった。でも、それは、自分が当時より少しは成長していることの証なのだと思った。


今までお世話になった会社の皆様、ありがとうございました。そしてこれからお世話になる会社の皆様、宜しくお願い致します。

『第4回テックヒルズ UI,UXの衝撃 ～ユーザーを魅了するプロダクトの裏側～』ノート

2012/11/07に開催された『第4回テックヒルズ　UI,UXの衝撃　～ユーザーを魅了するプロダクトの裏側～』のノートです。



◆酒井洋平氏 「開発者のためのUXデザイン」

◇UI/UXって？
・UXって？
　→ユーザエクスペリエンスの略
・UIって？
　→ユーザインターフェースの略
・なんでUI/UXで一括りなのか？
　→この状況は不思議
・ネットでも専門家がいろいろ書いている
　→でも、皆「ん？」という状態なのではないか？と思う

◇↑のあたりを整理する
・UXはユーザからみた主観的な経験
・UIはユーザの主観的経験を支えるための接点となるいろいろな道具
　→券売機、ATM、自販機など。

◇人(UX)　←→　UI　←→　システム
・人に属するものがUX
・↑を支えてシステムとつながっているのがUI
・これが同時に語られるのはどういうことかということ。
　→大事なポイント
・旧来、デザイナーはUIを大事に考えてきた
　→いまはUXについても考えないといけない
　→→それはUIがUXを支えているから
　→→→そこまで考えざるをえない状況になっている
　→だからUI/UXという表現になってきている

◇ユーザの主観的経験なのでデザインできるのか？
・個人の内面的なものだからできないと思われるが…
・そうではなく、ある主観的経験が想起されることを企図した設計と考える
　→多くの場合はビジネスとしてやるもの
・ユーザに"価値がある主観的経験"を想起させること企図した設計
　→"個人的には"それがUXデザインだと思っている
・この辺りは議論になっている
　→ウェブ上
　→各種専門家など
　→UX白書
　→→UX白書をググってご覧ください

◇ユーザって誰？　ユーザにとっての価値は何？
・この辺りをいま課題に感じている
　→ユーザって誰？どこにいる？
・見つけてきたユーザにとっての価値を真剣に考える
　→それをやらないとUXはできない
・今までのウェブでは数打てばあたるというところがあった
　→この辺は肌感覚でやっている人も多いのでは？
・どうやって見つけるか？
　→難しい

◇価値発見プロセス
1. 計測
2. 気付き
3. ベンチマーキングと観察
4. 脳内でプロトタイピング
5. ストーリーテリングで価値を訴える
　→このような活動をとおして新しい価値をもたらそうとしている

◇UXデザインをサマライズする
・あるUXの価値（ユーザにとっての価値）がある
　→それをどう発見するか？
　→どう実現するか？
　→→これがポイント
・具体的な価値が見つかったときにどうするか
　→部門横断的に価値に向けて動かないといけない。
　→→マーケティング・プランニング・デザイン・エンジニアリングなど…
　→UXの専門家がいるだけではどうにもならない
　→→全社的に理解してやっていかないといけない

◇展望
・マーケティングやプランニングなどの領域でもUXデザインと同じ考えを別の言葉で使ったりするのではないか
　→同じような活動が行われたり
　→同じことを別の言葉で指していたり
　→→そういうことが多い
・UXデザインの周辺ではその辺が整理されて全体統合的な流れが出てくるのでは
　→それが活発な企業から成功事例が出るのかなー


◆橋本建吾氏　「UI/UXについて 〜LINEの場合〜」

◇UX design ≠ UI design
・全然違うもの

◇理解を深めるために
・Janice Fracerの写真

from The Difference Between UX and UI: Subtleties Explained in Cereal

　→食器や食材がバラバラの状態
　→→この状態だとどうすることもできない
　→→これをプロダクト、機能リストして考える
　→これをスプーンで統合する
　→→スプーンはインタフェース
　→→カップにシリアル
　→→ミルク
　→→スプーンで朝食
・これはUXとしては原始的なもの
　→でも結果として空腹が満たされる
・もう少し上層的な考え方
　→牛乳の量をコントロールしてシリアルの質感を変える
　→砂糖やジャムで味を変える
　→→こういうのもUXのアプローチだと思う
・自分でもチョイスしてみる
　→日本食
　→木の橋
　→漆の器
　→陶器
　→→ユーザの感じるものがずいぶん違う
　→→同じ結果でも与える印象はずいぶん違う
・材料や素材のチョイスで結果が変わる
　→このチョイスがUIデザイナーの役割

◇UXとは？　UIとは？
・UXはユーザの感受であり体験
・UIは感受性を生み出す入り口、窓

◇NHN UX Designプロセス
1. simple
・NHNに入ってまず上長に言われたこと
　→半年くらい言われ続けた
・なぜUIにシンプルさが必要なのか？
　→様々なものが双方向的になっているから
　→→ユーザが参加するインターネット、という構造の出現
・ブログメディアの発展
　→素人の人でも情報が流通できる
　→→不特定多数の人間が情報を流通
　→非専門家による情報の供給
　→→シンプルなインタフェースが必要になる
 →→→誰でも使えるようなもの
・この考えはビジネスのデザインにも影響する
　→そういうデザインの方が強い
　→→0.5秒で持って帰ってもらえるようなもの
　→シンプルにUIを構築すると同時に、シンプルにバナー・広告も考える
　→→そちらの方がよい

2. Quick and Fast
・まず昔の一般的なワークフローについて考える
　→plan →> design -> develop
　→→ウォーターフォール的なワークフロー
　→工期が読みやすくて進行に有利
　→→でもプロジェクトのロールバックには弱い
・今やっている方法
　→UXがリサーチ
　→UIキャッチアップしてプロトタイプ
　→1回では終わらせずループをクルクルまわす
　→あるUIが完成したら開発にまわす
　→ここでもUXの方でデザインやインタラクション、ニーズへの満足度を検知
　→足りない場合は開発に戻す
　→これを半日とか一日単位でぐるぐる回す
・比較
　→ウォーターフォールはプランが無いと動けない
　→後者は起点がどこでもよい
　→→どこからでも回せる
　→→→クイックな開発・意思決定ができる

3. 意匠
・身の回りにあるもの
　→材質とか色など、ポイントを持ってものを選んでいるはず
・スマートフォン
　→→液晶などが進化していて非常に品質の高い表現ができるようになっている
　→毎日使うスマホのアプリにそこまで気を配っている人がどれだけいるのか？
　→（作り手も）あまり心血を注いでいないような気がする
・最近はUIコンポーネントがライブラリ・共有化されている
　→パーツを組み合わせればある程度のサービスができるということ
・差別化を図るには？
　→意匠を追及し、UXを高めていかないといけない
　→→特にUIデザイナが取り組まないといけない、という課題
　→→「ノイズを取り除く」
・流れや空気感を壊さないようなデザイン
　→画面上の情報のボリュームよりも
　→→そういうところにデザイナもコミットしないといけなくなってきている
　→→→「かんなをかける」と表現している
・「かんなをかける」
　→ざらざらした四角い木
　→→かんなをかけるとなめらかで気持ち良い質感になる
　→→→それはUIデザイナがやらないといけないこと
　→→→→そのためにはプロトタイプデザインを重ねていくしかない
・かんなをかけたUIはそれがごく当たり前のように見える
　→その当たり前に気付くか否かが重要
　→→だからプロトタイプを作り日々デザインする
・見た目や使い勝手に磨きをかける
　→そうすることで気持ちいいUXデザインができる

◇まとめ
・UIデザイナの選択の連続がユーザ体験を様々に彩る
　→一つ一つの選択の与える影響が大きい
　→→選択することに、より注視する
・使う人の立場、状況を踏まえデザインをシンプルに
　→シンプルにするのは怖い
　→→そこを踏み込んでいくことほどのUXのアプローチはない
・プロトタイプデザインを繰り替えす
　→そうすることで品質のでこぼこをなくす



◆坪田朋氏　「アジャイル開発におけるUX」

◇UI/UXについて
・UIって単語はイメージしやすい
　→議論の中で出てきても腹落ちする
　→でもUXは違う
　→→議論するときだいたい着地しない
・UXの定義をUX白書から引いてみた
　→「UXという分野は、システムの利用（あるいはシステムとの出会い）を通じて人々が持つ経験について…」
　→→なんど読んでも腑に落ちない
　→うまく言語化できないと思ってしまう
・UXという言葉が1人歩きしている
　→多くの概念を包括している
　→1つの定義で言い表せなくなっている？
　→→この言葉を使って議論することは危険？
・でもUXの意味を考えた
　→システムの利用を通じて人々が持つ体験
・UXって？
　→フレームはある
　→→タイムスパン
　→表すための要素もある
　→→ハニカム構造
　→自分で学んではき出していかないと身につかない

◇UXデザイナーとは
・自分はどう思っているか
　→イケてるプロダクトを作りたいと思っている
・ユーザーの立場を中心に考える
　→ユーザ価値のためにどうプロダクトを作ればよいかを考える
　→様々な方法論を組み合わせて課題・要求を解決する

◇イライラUIが生まれる理由
・最終的なプロダクトアウトはUI
　→なんでイケてないUIが出来あがるか
・ユーザニーズの不理解や市場の勉強不足
　→UXデザインで重要になってくる
・コミュニケーション不足やチューニング不足
　→UXデザインの後に出てくる
・これらがないと、イケていないUIデザインになる

◇Denaでの開発プロセス
1. リサーチ
2. 要件定義、UI開発
3. テストリサーチ
4. リリース
・これをループ
　→UXデザイナはこの全ての責任者だと思っている
　→→何をやるかを決めてチームを回すところまで

◇リサーチでなにをやっているか
・定量調査
　→アンケートを使って、数値化・グラフなどで表現したものを分析
　→→主観が入るところを定量化して明確に
　→→→いろいろな軸で切り取る
　→キャッチコピー・サービスの機能名・コア機能のニーズ・イラスト・キャラクターなど
・定性調査
　→定量調査で終えないものを追う
　→→実際に使ったときにボトルネックになっているものとか
　→→→スマホでゲームしているときの視線の動きなど
　→競合サービスに対しても使い、ヒアリングする
・競合調査
　→何が刺さっているかなどを切り出す
　→→ターゲットユーザー
　→→プロモーションマーケティング
　→→デザイン
　→→→設計
　→→→グラフィック

◇調査した後はUI開発
・要件定義やUI開発をする
　→要件定義は、何が課題で何をするかを決める
・まずはストーリー
　→それからUI設計
　→→ペーパープロトタイピングやワイヤフレームワーク
　→→→課題をどうUIで解決できているかを見る
　→使いやすさを考えるために実機でモックを作る
　→→HTMLやcssで再現
・違和感を感じた部分は何度も作り直す
　→必要かどうか迷った機能は落とす
　→→迷うような機能をユーザは使わない
・UIが決まったらGUI
　→どういうグラフィックにするかをデザイナと決める
　→→複数パターンを作る
　→→→チームやアンケートで採用する案を決める

◇リリーステスト
・プロダクトを始めて触る人が直感的に分かるようにしたい
　→ユーザに見てもらう
　→→テキストやアイコンなどの直感的な判断に関わるところを見てもらう
　→作っている側は慣れるので冷静に判断できない

◇リリース
・本当に受け入れられてアクティビティが向上しているかを見る
　→A/Bテストなど
　→→乱数・特定地域やセグメントなどで分ける

◇まとめ
・UI設計で重要なこと
　→徹底的な分析
　→→定量/定性
　→プロトタイピング
　→→実際に作る前
　→→→巻き戻りのコストを下げるため
　→→UIを決めてからGUI
　→ユーザーテストの実施と繰り返し
　→→盲目的になってしまったところを解決する

◇スクラム開発
・数年前から欧米で流行っているアジャイル開発の手法
　→上記のやり方をどう回すか？というところでスクラムを使っている
　→欧米では採用が多い

◇現場に求められていることは
・スピード
・スピード
・スピード
　→ウェブ開発では重要

◇高いスピードと品質を求められる
・マネジメントの期待する要求でスピードを出す
　→出した後は数字を求められる
・品質をスピードを達成しないといけない
　→スクラムだと品質とスピードが出せる

◇スクラムによる開発プロセスの最適化
・優先度・目的の可視化
・役割の明確化
・コミュニケーションコスト減

◇スクラムフレームワーク
・ストーリー
　→プロダクトバックログ
　→スプリントバックログ
・ミーティング
　→スプリント計画
　→朝会
　→振り返りとレビュー
・役割
　→プロダクトオーナー
　→スクラムマスター
　→チーム
・誰が何をやっているか、意思決定者が誰か、が明確化されている

◇スクラムについて
・ストーリーの書き方
「<サービス>においては、<目的>をしたい。なぜならば<将来の対象>は<現在の対象>に比べて<統計的事実>だからだ」
・スプリントは2週間
　→最初の月曜がプランニング
　→最後の金曜日がレビュー
・スクラムチーム
　→各人が専門（意思決定権）を持っている
　→→意思決定者が明確なので、コミュニケーションコストが減る
・チーム
　→UXデザイナ・リサーチ・エンジニア・UIデザイナなどに分けている
・スクラムではスクラムチームがまとめる
　→ディレクター制だとディレクターに集中してしまう
・チーム外のステークホルダーにはレビューで見せる
　→それを次のスプリントで改善する

◇ディレクション工程のシステム化
・Excelで線表を引く時間すらもったいない
　→ガントチャートはやめて朝会
　→アナログのタスクボード
　→→みんな自分で管理
・ミーティングは全員たってやる
　→タスク管理ツールはシンプルに
　→→タスクボード
・UIデザイン
　→パワポでワイヤーフレームから、チームでホワイトボードへ
　→→決まればデベロッパとGUIの人へ
・偉い人からの差し込み
　→基本的にはブロック
　→→レビューにまわして「次にやりましょう」

◇専門性について
・浅く広くではない
　→スペシャリストが作り、決める
・コンセプト・優先順位を明文化することでチームは自走する
・スペシャリスト同士のコミュニケーションに特化する
　→コミュニケ-ションコストを減らす

◇まとめ
・企画者は1人
　→事業管理している人
・サービスデザインはエンジニアやクリエイターの領域
　→彼らが作るのが一番早い
・UI設計はリサーチとテストがとても大事
・UXを考えないUIは時代遅れなのでは
　→リリースして終わりではない
　→→リリース後の効果分析を徹底的に行う
　→→→次に何をするかを決める






CROOZ株式会社様, 酒井洋平様, 橋本建吾様, 坪田朋様, アカデミーヒルズ様、ありがとうございました。

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 1 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートのパート1です。

パート2はこちら

◆高橋 一貴氏「スクラムマスター思い出語り」

◇アジャイルコーチをやっている

・自分は推進係

　→知らないところで好きにやっていたりする

・昔は壁に張り物がなかった

　→今は場所取りが必要なくらいになっている

◇スクラムマスターって？

"スクラムマスターは、スクラムチームとのやり取りで役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらうようにする。

スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。"

 - (Ken Schwaber and Jeff Sutherland､ Scrum Guide)

　→みんなのやり取りを変えてもらうことでスクラムチームの作る価値を最大化する

◇最初はわからないことだらけ

・スクラムマスターについて

　→どこまで理解しておけば？

　→チームとの関わり方のコツは？

・どこから始めれば？

　→『塹壕より Scrum と XP』を読んだ

　→→今だと若干古いところがあるので注意

◇失敗

・Excelでスプリントバックログとプロダクトバックログを一元管理

　→プロダクトバックログのアイテムの下にインデントでタスクを並べる

・個人別にバーンダウンチャート

　→個人の遅れもばっちり把握

・フロントエンドとバックエンドでチームをわける

　→効率的な分業

・スクラムマスターがタスクをアサインした

　→抜け盛れを防ぐ

・レビュー完了はスクラムマスターが判断

　→確実な品質確保を

・詳細仕様をプロダクトオーナーに承認してもらう

　→外部仕様より先の話

・ミーティングはスクラムマスターがどんどん発言

　→進行も決定も効率的に

　→自分の意見もどんどん言う

◇こういうことをしているといろいろ変になる

・タスクの残量が把握できない

　→並べてあるから見える化

　→→全体量が分からない

　→→メンテナンスが大変

・遅れている人を問いたださないといけない

　→いつも遅れている人に余計なプレッシャー

・堂々巡り

　→「バックエンドが終わってないから画面作れない」

　→「いやいやフロントエンドが終わってないから見せられない」

・追加タスクが申告されない

　→バーンダウンチャートが増えるだけだから隠してしまう

・自分のところでレビューが溜まりすぎる

・POと話がかみ合わない

・チームから活気が消えた

◇どうなったか

・葬式のような振り返り

　→ミーティング全てお葬式に

　→→こんなはずではなかった

◇もう一度定義をよく見直した

・スクラムの理解と成立のために

　→皆のやり取りを変えてもらう

　→→スクラムチームの外側ステークホルダーに理解と行動を促す

　→→→個々の作業に関与しすぎるからうまくいかない？

◇やり方を変えた

・手法や環境へ働きかける形へ

　→作ったものや個人ではなく、全体的な視点で

・スプリントバックログは付箋とペンで

　→『塹壕より Scrum と XP』どおりにやってみた

　→→一覧性がぜんぜん違う。何が起こったかすぐわかる

・チーム全体のバーンダウンチャートのみに

　→チームを解散させたいなら個人別バーンダウンチャートがオススメ

・チームはクロスファンクションで組成し直し

・放置・滞留しているタスクに気付いてもらうように

　→「しばらく貼りっぱなしだけどどうしたの？」

　→→意外と話してくれる

　→→→フィードバックすれば自主的にやってくれる

・レビューはチームで完結

　→実施有無とレビュー観点のみ見る

　→後はチームに任せる

・詳細仕様は求められた場合のみ説明

　→プロダクトオーナーはデータベースとかに興味ない

・ミーティングへの貢献の仕方を変える

　→ゴールとアジェンダを必ず用意

　→→参加者に手伝ってもらうつもりで

　→進行のコントロールに徹する

　→→内容には干渉しない

　→→→"誰が喋るか"を決めては駄目。"誰から喋るか"を決めるのはよい

◇大事だと思うこと

・いっぱい勉強してやってみる

　→今はいろいろなところで話を聞ける

・『自分が信頼している人に見せる態度』でみんなに接する

　→ノーガードで飛び込んでしまう

　→→ガチで殴ってくる人はいない

　→チームの少々の混乱は覚悟しておく

・Be Nice

　→いい人のいいところを容赦なく真似る

◇変えられないものを受け入れる

・変えられるものは変える

　→そこはあきらめない

・判断できる力をつける

高橋 一貴様、スクラム道様、ありがとうございました。

『スクラム道 EXPO 2012 - 午前のセッション』ノート

2012/10/28に開催された『スクラム道 EXPO 2012』午前のセッションのノートです。


◆和田　卓人氏「ペアプログラミング ホントのところ」

◇質問「ペアプロすべきか？」
・答え「状況による」
　→それはずるい
　→→経験者としてそういう結論になるのはわかるが…
・ペアプロは議論を巻き起こす
・見た目も派手

◇ペアプログラミングって何？
・書籍「プログラマが知るべき97のこと」
　→「いかに周りの人とお客と仕事をするか」という中身が詰まっている
　→→プログラマは技術が優れいてるだけでは充分ではない
　→→他人との連携でより大きな成果が上げられるようでなければならない
・2人で1つのマシン、1つのキーボード
　→ドライバとナビゲータ
　→2人でコラボレーション
・いろいろなイベントではモヒカンが切りあう形になっている
　→それも面白いが…
　→チーム（ペア）でプログラミングするもの

◇ペアプロをやっている人の結論
・外国でやっている人も国内でやっている人（自分）同じような結論に至る
・やっている人とそうでない人ではイメージがだいぶ違う

◇ペアプロの利点
・規律の強化
　→1人だとサボったり、コーディング規約が億劫になったりする
　→→1人だと悪魔のささやきに負けやすい
　→→2人でコードを書いているときは天使の方が勝る
　→ペアプロ中ってtwitterやネットサーフィンをしない
　→→仕事モードになっている
　→→→仕事と休みのメリハリが付きやすい
・より良いコード
　→品質は上がっていく
　→→すぐ隣にそのコード使う人がいる
　→→フィードバックが非常に早い
　→→→それが良い効果をもたらす
　→ペアは最小のチーム
　→→シンプルさはチームが決めるもの
　→→→複雑なコードは書かなくなる
　→力技でこなす「動けばよい」みたいなコードも書かなくなる
・快活なフロー状態
　→1人と2人とでは深く集中した状態（フロー）が異なる
　→→ペアならではでのフローがある
　→→→1人のときとは異なるフローの状態に入れる
・チームの士気向上
　→ペアプロをすると部屋が無言ではなくなる
　→会話をしていくことがチームの仲の良さ
　→→情報が伝わりやすくなる
　→→→チームがよりよい方向に行く
・コードの共同所有
　→プロダクトコードに持ち主がいない状態
　→→少なくとも2人は知っている状態
　→「ある個人しか知らない」というのはない
　→→保守性が高まる
・学習効果
　→ペアプロはばらつきを一番早く吸収できる
　→→エディタ・開発環境・ネーミングなどなど
　→教える側は知識の整理などが必要
　→→教える側にも学びがある
・チームの一体化
　→チームが同じ方向に進むという方向付けがやりやすい
・割り込み削減
　→ペアプロ中の人には割り込みにくいという調査結果
・つまり…
　→教わる側は当然学べる
　→教える側は滅多なことは言えなくなる
　→→実は教える側の方が学べる

◇1人でプログラミングするのと、2人でするのとの違い
・最大の違いは"喋るか喋らないか"
　→この差は非常に大きい
　→→1人の場合、考えてコードに落として　…というのをグルグル回す
　→→2人の場合、声に出すので頭の中をもう一段整理しないといけない
　→Rubber Duckingという手法もある

◇機能しないとき
・管理者はハードウェアに投資したくない
・現場がペアプロに最適化されていない
　→机の並び方など
・現場では従来型の雇用方法を採用している
　→覚悟や適正など、ペアプロに向いたプログラマーを雇っていない
・現場では反社会的な行動を大目に見る
　→コーディング規約に従わない
　→ペアプロやらなくても「プログラマはそういうものだから」で看過されてしまう
・ペア作業の生産性が理解されていない
　→「生産性が半分になるじゃないか」という管理者の意見
　→→生産性は2割増しくらいになる
　→→仕様・スキルの伝達・Better Codeなどの生産性がある
　→ペアプロにはペアプロの生産性がある
　→→なかなか理解されない
・現場では的確でない開発者を雇っている
・現場は過労と人員不足に陥っている
　→「この期に及んで二人でコードを書くなんて」
・開発者は一緒に仕事をしている人達全員を好いているわけではない
・開発者はそのような面倒なことをしたいとは思わない
・たいていのソフトウェアの現場では、優秀さのことを本当は気にかけていない

◇ペアプログラミングをエゴの問題
・角谷さんとKent Beckさんとのやりとり
　→ペアプロするとき自分のキー配列とかの好みはどうする？
　→→「おまえの好みとチームの成功とで大事なのはどっち?」
・ワインバーグによるエゴレスプログラミングの十戒

◇ペアプロを入れるかどうか
・結局はIt depends.
　→気に入らない人という人も一度やってみると即座に気に入る（塹壕とScrum本）
　→→（結局）8割は気に入る
　→→それでも2割には通じない

◇ペアプロは楽しい
・楽しいのが一番
　→「楽しい」はものごとを前に進めるためのプリミティブな原動力



◆吉羽 龍太郎氏「Doneの定義 虎の巻（再演）」

◇出荷可能な製品とは？
・Doneの定義
　→実施しなければいけないことの一覧
　→→プロジェクトとして定めた『出荷可能な製品』を作るため

◇（個人的には）次の単位でDoneを定義したりする
・バックログ単位
・スプリント単位
・リリース単位

◇何が出来たら完了なのかを決めるもの
・どこまでやったら終わりかが分からずにやると…
　→悲惨なことになる
　→→だからゴールを決めてからやる

◇手戻り
・本人だけできていないつもりで延々と作りこむ
　→時間の無駄が発生
　→→（ex. 誰が見るのか分からないのに、一生懸命レイアウトを整える）
・本来やっていないといけないことをやり忘れる
　→セキュリティとか考えずにとりあえず作る
　→→後でセキュリティホールが見つかったりする

◇アジャイルな進捗の判断は0 or 1
・ウォーターフォールは80%などあるが、アジャイルにはない
　→アジャイルでは、できたか、できていないか
　→アジャイルは判断が必要ということ
　→→その基準がDoneの定義
・バーンダウンチャートの数字が信用できる理由は？
　→Doneの定義に従って進めているから
　→Doneの定義がないと見せかけの進捗でごまかせてしまう

◇プロダクトバックログの受け入れ基準との違い
・受け入れ基準とは
　→どこまでできたら終わりか？を書くもの
　→→機能要件適合性の判定のためのもの

◇体験談
・悪い受け入れ基準
　→『ソースコードが綺麗なこと』
　→→あやふや
・良い受け入れ基準
　→ソースコードをCheckStyleで検証し、重要度N以上の違反がないこと
　→→全員が合意できる
・変な基準を強制される
　→品質はコンテキストに寄る
　→→金融・医療・ウェブでは異なる
　→→→社内品質基準は顧客の期待と関係ない
　→そもそもゴージャスすぎる
・守っているかどうか判断できない
・そもそも定義の中身を知らない

◇Doneの定義を守れない理由
・なぜの分析が足りない
・別の圧力に負けれる（スコープの圧力など）
・チームがオーバーコミット
・そもそもDoneの定義が曖昧

◇どうやって改善するか？
・振り返りで改善
　→プロセスが改善されることでDoneの定義が変わっていく
　→1スプリント目と10スプリント目で同じなのは逆にやばい
　→→それは、従来のウォーターフォールの書き方を変えただけ
　→プロセスは自分達で変えることができないといけない

◇Doneの定義の更新
・自明のDoneは外す
　→チームが成熟するとでてくる
　→→もっと進むと『リリースのDoneの定義』をスプリント内でやれたりする
　→→→でもやりすぎには注意

◇Doneの定義の縮小
・気をつけなければいけないこと
　→明確に守れていないものを外すのはまずい
　→→本当に顧客の期待に応えられているかを考える

◇Doneの定義充足の検証
・Doneの定義を見ればチームの技術力がわかる
　→自動化できるものは自動で
　→→より本質的なものに時間が使えるようになる

◇Doneの定義をいつ決めるか？
・見積もりや契約の前に大枠が決まっているべき
　→そうでないと工数がぜんぜん異なる
・誰が決める
　→プロダクトオーナー + スクラムマスター + チーム
　→→プロダクトオーナーは外部のステークホルダーの声も聞く
・決め方
　→必要な作業を付箋に書き出す
　→実施タイミング(Release, Sprint, etc.)でグループ分け
　→リスト化して印刷して、皆が持つ

◇荒ぶる四天王
・品質は固定パラメータ
　→スコープ達成の圧力に負けない

◇大事だと思うこと
・プロジェクト開始時点で決める
・スプリントで全部やろうとしない（最初は無理）
・チームが成熟したら拡張
・品質は固定パラメータ
・途中で縮小しない
・自動で検証
・定義をみんな知っている


◆市谷 聡啓氏「Your Mind is the Scene of Development」

◇なぜインセプションデッキ？
・プロジェクトに然るべき人が集まっているかを確認
　→いないと後で話が変わる
・プロジェクトがしかるべき方向を向いているかを確認
・「チームメンバーが誰もいないところで合意したことを前提にしているからプロジェクトがダメになる(The Agile Samurai)」

◇インセプションデッキとは
・10個の問いから構成されている

◇いつデッキを作るか？
・プロジェクトキックオフ？　最初のイテレーション？
　→それでは遅すぎる
・契約前、予算取り前
　→検討する段階で作る
　→正しい制約を作るために

◇予算が確定した後にデッキを作るにしても、プロジェクトの前提は後からは動かしにくい
・だからステルスデッキ（受注前のインセプションデッキ）
　→前提を作る
　→目的に適した制約を作り、プロジェクトを開始する

◇プロジェクト開始前・開始後で進め方が違う
・開始前（ステルスデッキ）
　→ステークホルダーにはインセプションデッキとあえて言わない
　→→相手の期待値が上がる
　→あくまで制約をあぶりだすための仕掛け
・開始後（インセプションデッキ）
　→目的を明らかにして作る
　→→プロジェクトの方向を明らかにするために

◇インセプションデッキのCRUD
・Create
　→プロジェクト開始前と後
・Read
　→最初はデッキの内容のチームへの定着を図る
　→→週一回全員で点検するなど
・Update
　→デッキの更新はプロジェクトの方向が変わるということ
　→→その認識を併せる
・Delete
　→デッキが用を成さなくなったとき

◇ゴールデンサークル
・why, how, whatの順で考える
　→インセプションデッキの前半5枚がwhy
　→後半5枚がhow
　→ユーザストーリがwhat
・howが変わる
　→インセプションデッキに影響が及んでくる
・whyが変わる
　→プロジェクトの方向が変わる
　→→ステークホルダーが認識しているかを確認
　→→→プロジェクト全体で判断し合意する

◇インセプションデッキの弱点
・whoが弱い
　→エレベータピッチの「対象顧客向け」しかない
・whyを考えるためにはwhoは必要

◇エレベータピッチ
・whoの分だけエレベータピッチを考え、作る
　→ターゲットが複数
　→→ニーズが複数ということ
・複数ニーズに対してプロダクトは1個でよいのか？
　→そういう疑問をステークホルダーと話し合う

◇やることやらないことリスト
・いきなりやらないことを出すのは難しい
・目的
　→スコープを明らかにする
　→加えて、開発への期待を明らかにするためにも使える
　→→開発の苦い経験を明らかにしてもらう
　→→ここを見誤ると、この後の開発での相手の期待がわからなくなる

◇プロジェクトコミュニティ
・誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい
　→顧客には顧客組織が分かる
　→開発は開発の人しかわからない
　→→コミュニティを明らかにする必要がある
・開発のよくある役割を確認する
　→顧客に過去の開発であった役割を思い出してもらう

◇重要なこと
・練習重要
　→本番は本番の結果を出さないといけない
・質問力重要
　→良質な問いかけがプロジェクトの行く末を左右する
　→→アクションラーニングオススメ





和田 卓人様, 吉羽 龍太郎様, 市谷 聡啓様, スクラム道様、ありがとうございました。

" はてな匿名ダイアリー - 『地方の雑誌メディアの終焉が近い件について』まとめ"を作った

初まとめ。
概要やタウン誌の説明と併せて日記を時系列で並べた。

http://matome.naver.jp/odai/2135081868451032001


概要は次のとおり。

タウン誌（地域密着型の情報誌）のビジネスモデルが立ち行かなくなっていくまでの顛末を述べた『はてな匿名ダイアリー』の一連の日記をまとめました。

（中略）

強力なライバルの出現や、コアバリューを手放したことによる求心力の急速な低下など、さまざまな外的・内的要因によって、タウン誌の存在理由が脅かされていく様はとても生々しいです。