読みました。いつだったかお買い得になっていたときがあって、そのときに買うだけ買ってずっと積ん読（電子積ん読）していたもの。
このタイミングで読んだのは、さいきん自分と同じ職種のメンバーが最近新たにjoinするというイベントがあり、それをきっかけにチームビルディングを強く意識しはじめたから。そして、やっぱり読んで良かったな、という感想を持った。加えて、「チーム開発はやっぱりいいものだよね」ということも改めて思った。
とはいえ、自分のチームはシステム開発・プログラミングを主におこなうようなチームではないのだけど、この本を読むことで、「物事を改善していくにあたって有用な武器・道具・プラクティス」を多くインプットすることができたと思っている。今後は、こうした道具を折に触れておもむろに取り出し、いいかんじに問題解決に当たっていけたらいいな、と思った（さっそく先日も 「Working Agreement」をチームごとに決めてみるのはおもしろいかもしれないと思った という社内エントリを書いてみたりした）。
以下、読書メモ。
読書メモ
理論とか
素朴理論
- 人は自分が経験したことをベースに物事を考え、親や他人から日常の中で教わった知恵を取り込みながら経験則を強化させていく。この経験則を経た知識の集合を「素朴理論」と呼ぶ。
- 二人目の存在は、励まし合うだけではなく疑問や背景への質問によって、お互いの知識に影響を与え合うことができ、より深い知識へと繋げられる。
- 説明のために、調べ直したり、つくり直したりして、原理原則と自分の経験の間を、泡のようにアイデアが現れたり膨らんだりしながら、知識の質を強化させていく。
成功の循環モデル
関係の質→思考の質→行動の質→結果の質→関係の質。
狩野モデル
- 魅力的品質
- 充足されれば満足を与えるが、不充足であっても仕方がない
- 一元的品質
- 充足されれば満足、不充足であれば不満を引き起こす
- 当たり前品質
- 充足されて当たり前、不充足であれば不満を引き起こす
あらゆる品質が同程度に重要なのではなく、また、それらを一緒に高めることも重要ではない。
モダンアジャイルの基本原則
- 人々を最高に輝かせる
- 安全を必須条件にする
- 高速に実験＆学習する
- 継続的に価値を届ける
パーキンソンの法則
「仕事の量は完成のために与えられた時間を満たすまで膨張する」
コンウェイの法則
「アーキテクチャは組織に従う。組織はアーキテクチャに従う」
ギャレットの5段階
Webをデザインする際にUXを考え、構築していく上での重要な考え方・概念のこと。
- 表面（Surface）視覚的デザイン
- 骨格（Skelton）インフォメーション・デザイン / ナビゲーション・デザイン / インターフェース・デザイン
- 構造（Structure）インフォメーション・アーキテクチャ / インタラクション・デザイン
- 要件（Scope）コンテンツ要求 / 機能要件
- 戦略（Strategy）ユーザーニーズ / サイトの目的
ジョブ理論
顧客の潜在課題に気づくためには、そもそも「お金を払ってでも片付けたい用事」とは何なのかを考えると効果的。ジョブ理論とは、そのような考え方のこと。
- 顧客はやり遂げたい何かがあり、そのためにプロダクトやサービスを「雇用」している。同じ用事でも、顧客の置かれた状況によって雇用するものが異なる。
- 機能面にだけ焦点を当てて差別化を図るだけでは、顧客満足を見つけられない。
顧客の目的や課題解決を達成できる手段やソリューションは様々ある。その多様な案の中から、自社の優位性を用いて独自価値を提案することが、プロダクトづくりを通じてやりたいことである。
カイゼンに立ち向かうための武器
問題解決のための議論
- 問題解決の際、事実、意見、対策の3つに分けて議論を整理し、問題解決をナビゲートする。
- 問題点を自由に出し、全部意見として仮置きする
- 意見をもとに具体的な不利益を記載する
- これらの深掘りのもと、事実を記載する
- 事実の問題が再発しない対策案を考え、ベスト案をマークする
- これらの対策を誰が・いつ行うのかを記載する
プロジェクトを推進させるために考えたい、4つのこと
特に、完全なインセプションデッキを作るのが難しいとき。
- ミッションや目的の共有のために「われわれはなぜここにいるのか」
- リスクや不安のリストアップのために「夜も眠れない問題」
- スコープの内と外の協会を明らかにするために「やらないことリスト」
- 「このチームではやらないやり方」「取り組みたいやり方」を挙げるのもよい。
- 判断基準を可視化し、その優先度の明確化のために「トレードオフスライダー」
Working Agreement
- チーム内の価値観や行動規範を揃えるためにチームで決める、チームのルール。
- ルールは具体的で、誰でもが同じ見解で判断できるようなもの、もしくは状態や数値が記載されている内容が望ましい。
- ルールづくりの際に衝突を恐れてはいけない。また、ファシリテーターを入れることが望ましい。
- 1回作って終わりにしてはいけない。定期的にふりかえり、アップデートしていくことを忘れてはいけない。
- KPTなどで「良い習慣」として認められたものも Agreement に追加するようにする。
- 作ったAgreementは、チームの視界に入るような場所に張り出しておく。
ドラッカー風エクササイズ
- 自分は何が得意なのか？
- 自分はどうやって貢献するつもりか？
- 自分が大切に思う価値はなにか？
- チームメンバーは自分にどんな成果を期待していると思うか？
- その期待は合っているか？
チーム結成時のチームビルディングのときだけでなく、新しいメンバーが加入したときやプロジェクトの状況が一変したときにも期待マネジメントのアップデートのため実施する。
ファイブフィンガー
個人個人が「本当はどう思っているか」を5本の指で表明するプラクティス。
むきなおり
「ふりかえり」は、過去を顧みて現在を正すためのもの。「むきなおり」は、進むべき先を捉えて現在を正すためのもの。
- ミッション、ビジョンを点検する
- 評価軸を洗い出し、現状を客観的に見定める
- 評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す
- 「課題解決」のために必要なステップを「バックログ」にする
- 「バックログ」の重要度と、一番効果の高いものを決める
- 時間軸を明らかにし、期限も明確に決める
YWT（やったこと/わかったこと/次にやること）フレームワークを使うのも便利。
Job Instruction / 仕事の教え方
- 習う準備をさせる
- 作業を説明する
- やらせてみる
- 教えたあとを見る
ECRS
無駄なプロセスをカイゼンしていく際の業務改善の方法論。
- Eliminate（排除）
- 本当に必要な業務、プロセスなのかを見極める。形骸化していないか？
- Combine（結合）
- 待ち時間の無駄や過剰な作業分担が無駄を発生させていないか？
- Rearrange（交換）
- 順番を変更することで中間生成物ややりとりを削減できないか？
- Simplify（簡素化）
- 複雑なタスクは本当に価値を生成しているのか？
リーダーズインテグレーション
リーダーとメンバーの間の信頼感を情勢するためのワークショップ。
- リーダーについて「知っていること」
- リーダーについて「知りたいこと」
- リーダーに「知っておいて欲しいこと」
- リーダーのために「みんなができること」
CCPM（Critical Chain Project Management）
各タスクには個別のバッファを持たずに抑えた見積もりをして、全体としてのバッファを持ってプロジェクトを管理する方法。「五分五分の確率で達成できる」という観点で見積もりをおこなった個々の見積もりの合計値を算出し、その合計値の半分の値をプロジェクトバッファとして使う。 ここのタスクにバッファを積むことは、巧妙に見えない形でバッファを積む形となる。それは「悪い習慣」であるという文化を形成していくこと。
INVEST
ユーザーストーリーを評価するための考え方。
- Independent : 独立して優先順位がつけられる
- Negotiable : 何をつくるかの案が調整狩野である
- Valuable : 価値のある
- Estimable : 見積もり可能である
- Small : チームで扱いやすい手頃なサイズである
- Testable : テストできる
ユーザーストーリーは、その記述だけでは詳しい中身はわからず、会話が必要になる。ユーザーストーリーは「会話することを約束する」ものでもある。
ユーザーストーリーマッピング
時間の流れに沿ってユーザーの行動を洗い出し、左から右に「場面ごとの行動」の変遷を可視化、その後、各行動に対するユーザーストーリーを作り上げるワーク。作ったユーザーストーリーには優先順位をつける。特定の目標のために、最も優先順位の高い最小限のストーリー群をスライスして切り出したものがMVPとなる。
MVPとその種類
MVPとは、「ユーザーにとって価値があり、かつ最小限の機能性をもった製品」のこと。MVPの種類は、以下のようなタイプに分けられる。
- プロトタイプ型
- ハリボテ型
- 動画型
- コンシェルジュ型
心に留めておきたいあれこれ
考え方
- 外から得られた学びを、そのまま自分たちの現場や仕事で適用しようとしても、たいていうまくいかない。自分たちの「状況」に照らし合わせてみることが必要。それぞれの取り組みの背景には、それぞれの状況や制約がある。
- ふりかえり時に問題を見逃してしまうと、後で捉え直す機会がない。
- 「どうなったらこのタスクは終わるのか」を言えるようになる
- 大きなタスクを大きなまま扱わない。
- 今日のタスクのマネジメントは、明日のタスクのマネジメントでもある。
- 上司がやることは、メンバーが出した答えを後押ししてあげること。
- 互いの期待が合っているのが「チーム」
- モブプログラミング・モブワークは、人の稼働率ではなく問題に焦点を当て、いかに早く問題を片付けられるかに注力するための手法。
- 見積もり時のユーザーストーリーについて、ユーザーストーリーとしてまとめられた欲求は、スコープが固まれば、必要な作業は誰にとってもほぼ同じになる。一方、期間はチームスキル、過去の経験、人数などの背景により変わっていく。
- 当初の計画を変更せず済むプロジェクトは皆無。変更があるのは何かを学んだ証。当初の計画に固執せず、学んだ証を計画に反映させること。
事の運び方
- 仕事のカイゼンは、まず状態の見える化から始める。
- タスクに手をつける際、「自分は何をどれからやるつもりです、もし期待と違っていたら言及してね」と示す。
- 見積もりをおこなうにあたり、その目的は「完璧で厳密な見積もりを出すこと」ではなく、「現場として価値のある見積もり」を低コストですばやく出すことが重要。また、「期間」ではなく「規模」を見積もっていることも忘れない。
テクニック
- 条件（決まった時間、場所、リズム など）を揃えると、なにか異変が起きたときに察知しやすい。
