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

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


概要は次のとおり。

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

（中略）

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

【建設予定地】『Rakuten Technology Conference 2012 - System Development, Culture and "Shikatanai" By Masa Nakamura』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Masa Nakamura氏の講演『System Development, Culture and "Shikatanai"』のノートです。


※開催一ヵ月後を目処に公開致します。

【建設予定地】『Rakuten Technology Conference 2012 - Exploring User Wish Through Mindmapping By Kenji Hiranabe』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、平鍋健児氏の講演『Exploring User Wish Through Mindmapping』のノートです。

※開催一ヵ月後を目処に公開致します。