ぽりぽり記

趣味とか自己啓発とかhowtoとかを書きます

カイゼン・ジャーニー を読んで

1月から社内の人と、タイトルに記載した通り「カイゼン・ジャーニー」を輪読することになったので、その事前のまとめのために記載をいたします。

 

 

第01話 会社を出ていく前にやっておくべきこと

・会社のレベルが低いとは、自分にとって学ぶべきことがなくなること

エンジニアにとってそれはとても酷な状況。

自分が良いと信じる開発のやり方やあり方について他人と分かち合う事が

楽しくて仕方ないという状況になる必要がある。

・何かを変えたい、新たな取り組みを始めたい場合

自分がいつもいる場所から外に出てみる事で、異なった考えを持った人に出会え

問題解決の可能性が広がる。

・他社の実験の背景にどんな状況、制約があったのかを理解し

自分たちの状況、制約の下ではどのように実践すべきか捉えて直す必要がある。

 

第02話 自分から始める

仕事のカイゼンは、見える化から。

  1. タスクマネジメント
  2. タスクボード
  3. 朝会
  4. 振り返り

依存関係

タスクマネジメント ← タスクボード (計画の可視化)

タスクボード ← 朝会(状況の反映と問題の検知)

タスクマネジメント ← 振り返り (やり方の改善)

タスクボード ← 振り返り(やり方の改善)

朝会 ← 振り返り (やり方の改善)

振り返りは全てに良い影響を与えるため、まず最初に取り入れるべき事。

 

何か仕事をする時いきなり作業はしない。

その仕事の背景や目的を理解することが重要。目的を捉え違えると、無駄になる

 

許可を求めるな謝罪せよ

小さく試みて、小さく失敗する。まずやってみる事が重要。

→ 会社の方針にもある事。誰よりも早く挑戦して、誰よりも早く失敗する事が重要

 

タスクをマネジメントする際、コミュニケーションが不十分な場合アナログが良い

人の行なっているベストプラクティス手順をそのまま自分たちに当てはめても

うまくいかない。

→ アナログは、みんなで行なっている一体感みたいなものも生まれやすい気がする。

 

第03話 一人で始める振り返り

ふりかえり とは、立ち止まって考えるための機会

ふりかえり には、大きく目的が2つ。

  1. プロセスのカイゼン → 仕事をうまくやれるようになるために実施
  2. 不確実性の高い状況でも前進していくため

 

ふりかえりの手法

KPT(keep problem try)、YWT(やったこと、わかったこと、次にやる事)などがある。

ふりかえりの頻度

チームが熟れていないようなら1週間。チームのリズムが取れてきたら2週間。

スクラムを採用しているなら1ヶ月かそれより短い期間。

(改善計画を立てる機会をスプリントレトロスペクティブ)

 

2回目の振り返りでは、前回のtryを見るところからスタート

Tryをやってみてどうだったのか?効果があって続けた方が良さそうなら
Keepに移動させる。

効果があるというのは、problemに変化が起きる。

ふりかえりをつづけていくくと keepが増えていくはず。

 

事実、意見、対策 の3つ分けて議論を整理、問題をナビゲート。

①問題発見フェーズ

 問題点を自由気ままに出し、全部意見へ仮置きする

②事実発見フェーズ

 意見をもとに具体的な不利益を記載する

 これらの深堀りのものと事実を記載

③対策フェーズ

 事実の問題が再発しないか対策案を考え、ベスト案をマークする

 これらの対策を誰が・いつ行うのかを記載する

 

自分で気づけないことは、他の人に気づかせてもらうように仕組みかする必要がある

 

 第04話 一人で始めるタスクの見える化

タスクマネジメントで気にしないといけないポイント

  • タスクがどれくらいあるか
  • そのタスクのゴールはそれぞれ何か
  • タスクのゴールにたどり着くために気をつけることは何か
  • 今の状況はどうなっているのか

 

どうなったらこのタスクは終わるのかを、言えるように

  • 誰から依頼されたか
  • 次は誰に渡すか
  • 期日はいつか
  • どれくらい作業時間がかかりそうか
  • どうなったらこのタスクは完了するのか

 

大きなタスクを大きなまま扱うと認識の違いが生まれやすい

小さな問題に分割し、その全てを解決することで元の大きな問題を解決することを

分割統治法という。

 

 

第05話 明日を味方につける

1日の最初に1日の計画を立てる事が重要。

一人でも、チームでもやることは、「昨日やったことの言語化」。

昨日の問題、今日気をつける事、他人に知らせる事。

今日やるべき事が理解できれば、何を明日に回していいかという判断ができる

言語化する事は短い振り返りである。

1on1は、対話から得られる気づきによって成長する機会になる。

 

第06話 境目を行き来する

タスクボードでは、TODO(未着手)、DOING(着手済み)、DONE(完了済み)

を区別して管理する。DOINGには原則1つしか置かない。

WIP制限とは、仕掛かり作業。1つや2つに制限にするなどが良い。

タスクボードに、緊急割り込みレーンを追加して、常に空けておきメンバー全員が

今行なっている作業を中断してでもトラブル解決のために全員で片付ける。

 

 第07話 二人ならもっと変えられる

 行動を始めるべきと気づいた時がその人にとって最速のタイミング

二人目の存在は励まし合うだけでなく、お互いの知識に影響を与えあい良い深い知識へと繋げられる

建設的相互作用は、認識していなかったことや視点の異なる問いかけ、

お互いに相互に依存しながら理解が建設的に進む事。

 

第08話 二人で越境する

当たり前のように習慣化されたタスクは、問題発見カイゼンに手こずる

何か問題が発生した時には氷山の一角の出来事にとらわれて、対処療法をしてはいけない。

どんなメンタルモデルから発生した事象であるか考える。

一人では変えられないメンタルモデルも対話する事で様々な気づきと学びを得て

カイゼンが可能になる

 

 第09話 一人からチームへ

スクラムとは、透明性、検査、適応が重要な理論として位置づけられている

カイゼンが組み込まれた経験主義が根本思想のフレームワーク

過去からの失敗から学びを得る事を大切にしている

Fall Fast(早く失敗する)の精神が、漸進的(ぜんしんてき)に、開発をしていく事を後押しする

第10話 完成の基準をチームで合わせる

スプリングプランニングは第1フェーズに何を作るか決め、

第2フェーズはそれをどうやって顧客に提供するかを決める。

リファインメントは、バックログをメンテナンスする活動。

バックログは誰か一人が管理するものではなくチームで所有し見える化する

スプリントで達成すべき目標はスプリントゴールと呼ぶ。

メンバー全員がプロダクトの完成に対して共通の理解を持つ必要がある

第11話 チームの向かうべき先を見据える

インセプションデッキは10個の問いに応える事で、プロジェクトのWhyやHowを明確にできる

ツールであり、チームで作ることに意味がある。チーム全員の頭で考えなければならない。

10個の中の、「われわれはなぜここにいるのか」、「夜も眠れない問題」、「やらないことリスト」、「トレードオフスライダー」の4つを行うだけでプロジェクトの推進が加速する。

特に、「われわれはなぜここにいるのか」はチーム活動の要。

インセプションデッキ作成に今更はない。必要なタイミングで行えば良い。

一度作ったら終わりにせず、定期的に振り返ってアップデートする。

 

Start with whyを表現したゴールデンサークルでは、

中心にwhy、次にhow、一番外側にwhatがあり、why→whatで説明する事が理解を得やすいから。whyから考える事で、選択肢が大きく異なる。

 

第12話 僕たちの仕事の流儀

チームで決めたルールの事を「Working Agreement」

このルールは、チームで考えるべきもの。具体的に書く。

スローガンになっても、個別具体的でないものにする必要がある。

全体を俯瞰したものになっていない場合は、インセプションデッキで行なった

「われわれはなぜここにいるか」を確認して目的に立ち返る。

定期的に振り返って、アップデートしていく必要がある。

 

グッドサイクル

関係の質:お互いに尊重し一緒に考える

思考の質:気づきがあり面白い

行動の質:自分で気づき、自発的に行動する

結果の質:成果が得れる

 

 第13話 お互いの期待を明らかにする

期待値には2種類ある

内側の期待:チームにおける期待

外側の期待:プロジェクト関係者における期待

インセプションデッキによって2種類両方の期待に合わせた効果がある

 

チームビルディング手法 4つの質問

①自分は何が得意なのか

②自分はどうやって貢献するつもりか?

③自分が大切に思う価値は何か?

④チームメンバーは自分にどんな成果を期待していると思うか?

心理的な安全な場になっている状態でチームで共有しお互いの相互理解を進める

 

4つの質問に答えた後、

⑤自分んの認識で本当に、期待があっているか

をメンバーに確認することがより良いフィードバックにつながる

一方的な押し付けから共通理解へとする

 

第14話 問題はありませんという問題

「問題がない」が問題となることがある。

→ 問題に気づけていない、捉えられていないことが多い

精神的に健康であることが身体的な健康に結びつく

→ 問題があるという問いに対して問題があると答えることはない。

何が欲しいか?という問いで速い馬が欲しいというフォード社の例もあるし、人は自分の問題を本質的に理解していない

 

ファイブフィンガー

個人個人が本当はどう思っているか表明する

5本:とっても上手くやれている

4本:上手くやれている感触あり

3本:可もなく不可もなく

2本:不安は少しある

1本:全然ダメで絶望的

メンバーで出し合い一番少ない本数を出した人に意見を聞く。意見の否定をしてはいけない。

全員が気づいていない懸念点を把握しているかもしれない。

 

第15話 チームとプロダクトオーナーの境界

スプリントレビュー

スプリントの終わりに開発しているプロダクトの確認を行い、スプリントの成果をレビュー。

価値あるものを届けられているか、価値を最大化するために次に何をしなければならないか。

スプリントプランニング計画で何ができていて、

何ができないか確認する

0-100ルールで、判定する

ユーザに価値を届けるということを忘れてはいけない。

 

クネビンフレームワーク

 

シンプル:問題は誰が見ても理解できるもので既存のベストプラクティスを適用すれば良い

煩雑:専門知識が必要で、問題の分析によって計画的なプロジェクト化が可能

複雑:問題分析だけでは理解は無理。反復を繰り返し得られるフィーボバックを元に技法や手法が出現

カオス:対象を理解することすら難しい。

新しいプラクティスを作っていく

 

スプリントレビューのゴールは

次のスプリントで作っていくプロダクトバックログの改訂版が出来上がっていること

 

レビュー手順

①シナリオにもどついたでも

②受け入れ条件を満たしているか

③完成の定義どおりか 

④新しいアイディアを検討、価値最大化を議論

⑤プロダクトバックログ改訂版の完成

 

リファインメント

プロダクトバックログをメンテナンス

チーム全員で考える方がいい

 

狩野モデル

魅力的品質:充足されれば満足を与える、不充足であっても仕方ない

一元的品質:充足されれば満足、不充足であれば不満を引き起こす

当たり前品質:充足されて当たり前、不充足であれば不満を引きも起こす

 

魅力的品質を高めてユーザのアテンションを集めるべきか、当たり前品質を確保して、ユーザ不満を減らすか、戦略をバックログに反映する

プロジェクトの状態によってどうするべきか考える

 

第16話 チームとリーダーの境界

むきなおり

現状から方向性を定め直し、認識を共通にする

機会を作ること

 

ふりかえり:過去を顧みて現在を正す

むきなおり:進むべき先を捉えて現在を正す

 

むきなおりステップ

①ミッション、ビジョンを点検

②評価軸を洗い出し、現状を客観的に見定める

③評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す

④「課題解決」のために必要なステップを「バックログ」にする

⑤「バックログ」の重要度と一番効果の高いものを決める

⑥時間軸を明らかにし、期限を明確に決める

 

合宿のメリット

①集中

②リードタイム短縮

③高揚感

 

第17話 チームと新しいメンバーの境界

新メンバーを迎える時の方法

 

・星取表(スキルマップ) 

 誰:どんなスキルを持っている

 何:何を誰にどれくらい任せられるか

 支援:どの作業に誰の支援が必要か

 リスク:チームとして足りない要素は

 成長:チームとして手薄で強化したいスキルは何か

 育成:個人として長期的に成長したいスキルは何か

 星取表は、チームビルディングの初期段階で実施すると効果的で、定期的に見直す。

 

・モブプログラミング

 ・プロセスフロー効率化

 ・コミュニケーションカイゼン

 ・学習効果

 ・達成感

 

JI(job instruction)

①習う準備をさせる

②作業を説明する

③やらせてみる

④教えた後をみる

  

第18話 チームのやり方を考える

 スクラムマスターは役割

・チームにスクラムの理論、プラクティス、ルールをまもってもらうようにする

スクラムチームの外部の人たちにプロダクトやチームについて理解してもらう

・プロダクトオーナーや開発チームの活動を支援、コーチングする

・プロダクトバックログの価値を最大化させるためのコミュニケーションの方法や効果的なプロダクトバックログ管理法を伝える

スクラムイベントをファシリテートする

・チームを観察し、チームの自己組織化を後押しする

・進捗を妨げるものを排除しながら、スクラムチームが作り出す価値を最大化する

・チームを元気付ける

・奉仕や支援を通じて、メンバーが主体的に行動するように促すサーアントリーダーシップを発揮する

 

バリューストリームマッピング

プロダクトの価値がお客様の手に渡るまでの仕事の流れを見える化カイゼンするためのプラクティス。

コミュニケーションツールでもある

全体を俯瞰して観察し、リードタイムとプロセスタイムの最適化を図る必要がある。

 

バリューストリームマッピング作成手順

①プロセスのラフ図作成、ディスカッション

アーキテクチャのラフ図作成、ディスカッション

③バリューストリームマップを記述

④手戻りプロセスと手戻り割合の記載

⑤全体リードタイムとプロセスタイムの計算

⑥抜け漏れプロセスタイムの計算

⑦ムダやボトルネックに印をつける

⑧実施するカイゼン案の検討

カイゼン案の優位順位づけ

カイゼン案のアクションプラン策定

(11)カイゼン案の実施

(12)カイゼン案の検証、削減リードタイムの計測

 

カイゼンポイント

①待ち時間が長く、ボトルネックとなっているプロセス付近

②手戻りが発生していて、その割合が高いプロセス付近

③不安な作業やいつも心配しながら作業しているプロセス付近

手順書とは大きく異なるもの。

 

ECRS

①Eliminate (排除)必要か見極める

②Combine(結合)ムダが発生してないか

③Rearrange(交換)順番を変更する事で改善されるか

④Simplify(簡素化)複雑なタスクは単純化できないか

 

カンバンは、今やっている事を可視化するところから始まる

。仕事の流れに注目するのがカンバン。

カンバンでは以下の二つを計測する

①Ready状態となったバックログアイテムが完了するまでの期間

②定期的に完成したバックログアイテムの数

 

第19話 チームの解散

 ポストモーテム

プロジェクトの振り返り、事後検証のこと。

他のプロジェクトに活用できるようにすることが目的

タイムラインでふりかえり、出来事とともに、自分の感情の起伏やモチベーションの起伏をグラフとして書き出す。

 

感謝のアクティビティ

メンバー同士で感謝を送り合うイベント

 

タックマンモデル

組織づくりにおける発展段階のモデル

①形成期(forming) 組織としてメンバーが集められ目標を模索しながら関係性を築いていく時期

②混乱期(storming)組織の目標やあり方で、メンバーの考え方の枠組みや感情がぶつかりあう時期

③統一期(norming)目的や期待が合い、共通の規範や役割分担が出来上がり協調が生まれる時期

④機能期(perfoming)チームとして成熟して一体感が生まれ、機能し、成果をだしていく時期

 

第20話 新しいリーダーと、期待マネジメント

 ドラッカー風エクササイズのアップデート

①自分は何が得意なのか?

②自分はどうやって貢献するつもりか?

③自分が大切に思っている価値は何か?

④チームメンバーは自分にどんな成果を期待していると思うか?

⑤その期待はあっているか?

④⑤が特に重要

 

インセプションデッキのアップデート

われわれはなぜここにいるか

何も変わっていないか?と問い直す

 

やらないことリスト

スコープの増減を確認

 

ご近所さんを探せ

新たなステークホルダーの出現

 

夜も眠れない問題

不確定要素が減り、ボトルネックは映ってないか

 

リーダーズインテグレーション

信任リーダーの着任時や、チーム敏江一体感が欠落している場合などに実施が良い

リーダー抜きで、リーダーに関する事を意見出し合う。

リーダーとメンバーの心理的距離を縮めることができる

 

モダンアジャイル

基本原則

①人々を最高に輝かせる

②安全を必須条件にする

③高速に実験&学習する

④継続的に価値を届ける

チームの状態が安全であることも価値最大化のファクター担っている

 

 第21話 外からきたメンバーと、計画づくり

見積もりから計画づくりの基本的な流れ

①規模の見積もり

②見積もったストーリーポイントの合計

③期間への変換

④スケジューリング

 

プランニングポーカー

参加者がそれぞれの知見を持ち寄って、活発な議論を行うことで

見積もりの精度が上がり、チームに楽しい雰囲気が醸し出される

 

計画はたいてい上振れするもの

パーキンソンの法則、仕事の量は完成のために与えられた時間まで膨張する

CCPMは、各タスクにバッファを持たず、全体としてバッファを持つ方法

 

第22話 外部チームと、やり方をむきなおる

一つの視座にお互いが立てたとき、それまで衝突してた事は小さくなる

YWTでむきなおり

スクラム・オブ・スクラム 

複数のスクラムチームから代表を集めて実施して共有するMTG、状況報告MTGにしてはいけない。チームを超えた協調性を生む事ができる

 

コンウェイの法則

アーキテクチャは組織に従う。組織はアーキテクチャに従う

 

ディリーカクテルパーティ

一つ目 各機能開発チームで行うスタンドアップMTG

二つ目 各機能開発チームのリーダーがそれぞれ集まる専門担当者によるMTG

三つ目 各担当者、PMが横断的に集まってプロジェクトを俯瞰するMTG

 

第23話 デザイナーと、共通の目標に向かう

デザインの制作工程

①サイトの全体像 : どんなページが存在するか

②スケッチ : 要求を聴いて、ラフイメージ作成

③ペーパープロトタイピング : スケッチをプロトタイプ化し、インタラクションを検討

ワイヤーフレーム : 各ページでどんな情報を表現すべきか情報設計

⑤ビジュアルデザイン:トーン&マナーを守りつつ主要なワイヤーについて本番サイトと同様のビジュアル要素を決める

⑥コーディング : HTML&CSS実装

 

ユーザーストーリー三段構成

who:顧客として

what:xxxを達成したいか

why:なぜならyyyだからだ

 

INVEST

ユーザストーリーを評価する方法。

ユーザストリーは会話することを約束すること。

 

I:independent 独立して優先順位がつけられる

N:negotiable 何を作るのか案が調整可能である

V:vauable 価値のある

E:estimable 見積もり可能である

S:small チームで扱いやすい手頃なサイズである

T:Testable テストできる

 

ギャレット5段階

表面:資格的デザイン

骨格:インフォメーション・デザイン/ナビゲーション・デザイン/インターフェース・デザイン

構造:インフォメーション・アーキテクチャ/インタラクション・デザイン

要件:コンテンツ要求/機能要件

戦略:ユーザニーズ/サイトの目的

 

whyからはじめよ

 

第24話 視座を変えて、突破するための見方を得る

ジョブ理論

顧客はやり遂げたい何かがあり、そのためにプロダクやサービスを雇用していると考える。

 

仮説キャンバス

目的:なぜこの事業をやるのか

ソリューション:提案価値を実現する手段

優位性:自社がやるべき理由になる具体的なリソース、状況

評価指標:評価の指標と基準値

提案価値:顧客にもたらす価値

意味:顧客にとっての意味

 

ビジョン:顧客にどうなってもらいたいか

潜在課題:顧客が気づいている課題

潜在課題:顧客が気づいていない課題

代替手段:課題解決のための現状手段と不満

チャネル:顧客に出会うための手段

状況:どのような状況にある顧客が対象か

傾向:状況に基づく顧客の傾向

 

仮説キャンバス14の観点から規約やアイディアの確からしさを見定めていくと良い。

それでも不足していると感じたら、ビジネスモデルキャンバスと、リーンキャンバス 活用すると良い。

 

第25話 広さと深さで、プロダクトを見立てる

ユーザストーリーマッピング

時間の流れに沿ってユーザの行動を洗い出し、左から右にその変遷を可視化していくワーク。ユーザの体験にチームの考え方を集中させる必要がある。

 

MVP

ユーザにとって価値があり、かつ最小限の機能性を持った製品の事。計測、学びのフィードバックを回し、最小限の機能セットであるMVPの価値を検証してく。

プロトタイプ型、ハリボテ型、動画型、コンシェルジュ

などが存在する。決めていく際のポイントは広さと深さ。

 

26話 チームで共に越える

ユーザーインタビュー

インタビューで得たい情報は自分たちの仮説に誤りがないかを判断するための事実。

ページング、ミラーリングラポール空間などを活用して進めると良い。

準備フェーズ、実施フェーズ、検証フェーズがある

 

SL理論

リーダーシップのスタイルは、チームやメンバーの成長に合わせて、4つの理論を活用する

 

①S1(教示的リーダーシップ):具体的に支持し、事細かに監督する

②S2(説得的リーダーシップ):こちらの考えを説明して、疑問に答える

③S3(参加的リーダーシップ):考えを合わせて決められるように仕向ける

④S4(委任的リーダーシップ):仕事の遂行の責任を委ねる

 

第27話 越境する開発

ハンガーフライト

社内の空気を少し変えるつもりで行う勉強会の企画。

普段関わらない人々の絡み、仕事では扱われない技術などを知れ、登壇者たちのスキルや価値観を垣間見ることができる。