書評）大規模スクラム

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 [ Craig Larman ]

感想

スクラムの本にマネージャーが役割として登場することはないけど、LeSSにおけるマネージャーの役割は組織がプロダクトを開発するにあたっての価値提供能力を向上させるための改善だと明確に言及があるのが良かったです。

マネージャーは組織が改善していることを保証することに注力する、チームが改善するにあたってチームだけではできないことを支援する、例えば規制やポリシーの変更など。Doneの定義をどうやったら拡張できて、チームが自己管理の元にデリバリー能力を向上させることができるかを考える役割だ、などなど。

また人気のマネジメントの本を読むだけで満足せず、現地現物に触れ続け、学習を継続し、今の現実の問題を見つけてそれを組織力の向上に活かすこと、という示唆はちょっとドキッとしました。

 

全体としてはLeSS(Huge)におけるスクラムマスター、プロダクトオーナー、プロダクトバックログなど項目ごとに解説されていて、わからないところを読み返すことができるような感じで実際導入する場合の手引きになるような内容でした。

 

ポイントサマリ

 

顧客価値による組織化

• コンポーネントチームからフィーチャーチームへの移行を目指す
• コンポーネントチーム
• 各コンポーネントに専門家
• フィーチャーの開発が非同期となり各チームの優先順位の違いがボトルネックに
• フィーチャーチーム
• E2Eで顧客に提供するフィーチャーを受け持つ
• 一つのチームが複数コンポーネントを変更する
• いくつかのコンポーネントに詳しく、多くのコンポーネントを浅く知る
• 機能別組織はない

• 

• チームとPOは対等
• Undone部門
• 出荷可能とDoneの定義の差分を埋めるちーむ。無い方が好ましい
• LeSS Huge
• フィーチャーチームを要求エリアでグルーピング

• 

• 各要求エリアの優先順位に基づきチームの移動が発生する
• 優先順位が下がって小さくなった要求エリアは統合する
• 小さな要求エリアが増えることで優先順位付けが複雑化したり、サイロ化したりする

 

 

LeSSでなマネジメント

• マネージャーの役割は日々の作業の管理からプロダクト開発の仕組みの改善促進に変わる
• 組織の問題はフィーチャーチームを当事者として向き合わせる
• 組織が改善していることを保証することに注力する
• チームが改善しようとしていることに対し、チームだけでは手の届かない規制や組織のポリシーの変更などを支援する
• 現地現物
• チームとユーザーの現場に習慣的に訪問し、実際の問題を理解して、それを組織力の向上に活かす
• 現地で介入するとマイクロマネジメントになってしまう
• チームが解決できない場合には方法を教えて促進しチームの問題解決能力を向上する
• 現場から得たフィードバックをもとに優れた組織の意思決定をする
• マネージャーは人気のマネジメントの本を読むだけではなく、最新のドメインと技術に触れ続け、今日の現実に触れ続ける

 

LeSSのスクラムマスター

• LeSSがうまく機能していることに責任を持つ
• システム思考とプロダクト全体思考を組織が持てるように支援する
• 対象領域はチーム、PO、組織、開発のプラクティスでスクラムマスター専任

 

LeSSのプロダクト

• チームが扱うプロダクトの定義を狭く細かく区切ると、サイロ化し、機能の重複が起き、互いに依存関係が生まれ、顧客の課題を解決する提案が狭い範囲でしか考えられなくなる
• プロダクトの定義はプロダクトのビジョン、対象とする顧客や市場、ドメインの共通性によって広げるか狭めるかを考える
• 理想はE2Eで顧客に価値を届ける範囲でプロダクトを定義することだが、現実的には組織の制約などで制限される。まずはそこから始めて将来底には理想を目指す

書評）問いかける技術

問いかける技術 確かな人間関係と優れた組織をつくる [ エドガー・H．シャイン ]

感想

サーバントリーダーシップのセッションでお薦めいただいたので読んでみました。

 

複雑化する社会で1人のリーダーが成し遂げられることは限られるので、人が相互に依存することを認めて相手を尊重し良好な関係性を構築しましょう、そのためには立場を示すために自分が話し手にならねばという古い習慣を捨てて、自分の知りたい情報を相手が持っているかもしれないと示唆する「謙虚に問いかける」という技術が重要である、みたいな内容でした。

ここでの「1人のリーダーが〜」という話はサーバントリーダーシップとも共通でした。

 

相互の依存は横だけでなく上司と部下にもあって、でも部下から進言することにおいて壁がありがちなので、それを壊すのは上司の役割という話は納得感があります。

 

人は観察、反応、判断、介入というサイクルで動くが、それぞれにバイアスや感情による短絡的な判断がつきもの。そこで立ち止まって「謙虚に問いかける」ことで自分の対応の妥当性を自問することで間違った方向へ進むリスクを最小化できるそうです。

 

傾聴が大事、というトピックをより深く掘り下げてくれた本でした。

 

 

ポイントサマリ

第1章　謙虚に問いかける

• 一方的に話すことは相手が知らない前提に立ち上から見下ろすことになる
• 質問するということは自分を弱い立場に置き、自分が知りたい情報を相手が持っているかもしれないということが示唆される。相手への関心を持っていることを示し、相手に会話の方向づけをする主導権を渡すことになり、それが関係性を作ることにつながる
• 今ここで必要な謙虚さ
• 仕事においては地位に関わらず依存しあっている
• 下から上への進言はタブーな空気が付き物、支援を求めやすい風土を作るのは上の責任になる
• 上から謙虚に質問することで知っているけど言えない情報を得ることができ成功につながる

 

第2章　実例に学ぶ「謙虚に問いかける」の実践

• あれこれ指示をするのではなく、向き合うべき課題を伝え協力を仰ぐ
• 単に質問するだけでなく、情報を開示し、尋ねて、考える時間を与えて、判断してもらう余地を与える
• 何かを聞かれた時、相手が本当に必要としていることがわかるまで慌てて返事をせず尋ねる
• 抽象的でピンと来ない時は具体例を尋ねる
• 純粋に疑問を持ったことを問いかけることで、時として適切な質問を導き出す

 

第3章　ほかの問いかけと「謙虚に問いかける」はどう違うのか

• 質問を分類して標準化することはできない
• 先入観を排除して会話を進め、自分はなるべく聞くことに専念する
• 診断的な問いかけ
• 謙虚に問いかけるつもりが実は会話をコントロールしてしまい無理矢理考えさせてしまう
• 「何故それが起こったと思いますか」など無理やり引き出すパターン
• 謙虚に問いかけるになるかは状況次第
• 対決的な問いかけ
• 自分が言いたいことを言うために質問という形をとったパターン
• 謙虚に問いかけるになることは稀
• プロセス指向の問いかけ
• 会話の中身でなく会話そのものにシフトさせる聞き方
• 「少々深入りしすぎましたか？」など
• 会話が難航してしまった場合などにこのように問いかけることで一旦リセットし、そもそもなんのために話し合っているのか、何を得ようとしているのかを再確認する場合に有効

 

第4章　自分が動き、自分が話す文化

• その国の文化的背景により、相手よりも自分、関係性よりも課題の遂行に重きを置くことがある
• 質問することでものを知らないと思われるのを避けようともする　
• しかし課題が複雑になればなるほど、互いに対する依存度は高くなるので、上司は「今ここで必要な謙虚さ」の必要性を認め「謙虚に問いかける」を進んで実践しなければならない
• 上司は部下を仕事の対象としてではなく1人の人間として扱われていると実感させてあげる

 

第6章　「謙虚に問いかける」を邪魔する力

• 相手に勝ちたい、自分が得をしたい
• 文化による「それを聞いてはいけない」というルール
• 観察、反応、判断、介入
• 観察においては自分のほしいことにフィルターをかけてしまう。謙虚に問いかけることにより見えていなかったことを知ることができる
• 反応においては感情によって短絡的な行動を取ることにより良い結果を見逃してしまう。謙虚に問いかけることにより行動の前に確かめられる
• 判断する際に元となるデータが誤っていたり足りなければ間違ってしまう。謙虚に問いかけることにより判断の助けとなる情報が得られる
• 介入を間違った判断でしてしまう。謙虚に問いかけることにより、相手に対する偽りのない好奇心や関心を持つことができればミスを最小限に止めることができる
• 「謙虚に問いかける」がもっとも必要とされるのは、怒りや不安を感じさせるものを目にした時
• 自分の対応がどの程度妥当なのかを自問する

 

第7章　謙虚に問いかける態度を育てる

• 自分が話し手になるという古い習慣を捨てる
• 「謙虚に問いかける」を自分にやってみる
• 周囲で起きていることにもっと気づく（マインドフルになる）ために、「他には何が起きていたのか」と自問する。結論を急ぐが故に見逃していることに目を向ける
• 多様な文化では「あなたの文化的環境では、上司を信頼できるかどうか、同僚と信頼関係を、築けるかどうかは、どうしたらわかるのですか」と尋ねてみる

書評）More Effective Agile

More Effective Agile ～ “ソフトウェアリーダー”になるための28の道標 [ Steve McConnell ]

感想

「ソフトウェアリーダーになるための28の道標」という副題の通り、アジャイル開発プロセスを実践する上での各所勘所が28のトピックにまとめられています。

 

冒頭で「筆者は『うまくいくもの』の提唱者であり」と述べている通り、本の内容は経験に培われた実務目線のプラクティスでした。

例えばスケジュール予測をビジネス側が理由あって必要としている場合にプロジェクト初期ではシーケンシャル開発のプラクティスを適用する話や、エピックに割り当てたストーリーポイントをそのエピックの予算として扱う考え方など。

一つ一つのトピックはそれほど長くない為、今課題に感じてるところを読み返して参考文献で深ぼったりという使い方で今後役に立ちそうです。

内容的にリーダー職の参考になる話も多く、個人的にはPDL(Professional Development Ladder)をつかってキャリアパス制度を導入する話は深ぼって業務に役立てたいトピックでした。

ポイントサマリ 

より効率的なアジャイル

• Cynefin（クネビン）フレームワークによる考察
• 分析を持って対処が特定できる領域はシーケンシャル開発の領域
• 多くのソフトウェア開発は実験が伴う複雑系、そこでシーケンシャル開発がうまくいかないことがアジャイル開発を生み出すきっかけ
• OODAループ
• 観察を起点にジャストインタイムでプランニングから実装まで反応的に作業
• 短期的な作業にコンテキストを与えるために長期的な計画から目を離さないようにする
• あらゆる要因に検査と適応が必要

より効率的なチーム

• 職能横断
• チームが決定を下す能力と権限を持つ
• 組織との間にその為の信頼とチームの成熟度に応じたサポートがある
• テスト技術者のチームへの統合
• 開発者は自分の作業を自分でテストする
• テスト技術者はより高度なテストプラクティスにより付加価値を与える
• プロダクションサポート（オペレーション）の組織化
• サポート時間をスプリントに盛り込む
• 割り込みを許容するポリシーを定める
• レトロスペクティブで見直す
• ブラックボックスとしてのアジャイルチーム
• マネージャーは細部に首を突っ込まず、チームの方向性が明確であることを確認し、チームが責任を持ってその方向へ向かうように働きかける
• 妨害やスプリントの中断からチームを保護する
• 育成や採用などでチームを支援する

チーム文化

• 内発的モチベーションによるチームの動機付け
• 自律
• 仕事をチームがマネジメントする
• マネージャーは方向性を以ってチームをリードし、その方向性にコミットする
• 熟達
• 成長の機会を与える
• 学習と挑戦を支援する
• 目的
• なぜ重要なのかと全体像を伝える
• 情報の透明性を高める
• 顧客、ビジネスと交流させる
• 成長マインドセットを培う
• タスクをただこなしソフトウェアを作ることだけを目的としない
• そのソフトウェアを作るチームの成長もプロジェクトの目的の１つとする
• ビジネスフォーカスを培う
• 開発者が実際の利用ユーザーと直接交流することで人生が変わるような体験をすることはよくある
• ユーザーの問題をバランスの取れた視点で捉えるには、ユーザーとの継続的な触れ合いが必要

分散チーム

• 地理的に分散しているチームはフィードバックループがルーズになる
• ベストプラクティスは出来るだけ自律的に活動できるチーム（職能横断）をそれぞれの場所に配置すること
• 対面でのコミュニケーションを定期的に
• 設備、ツールを充実させる
• リモートにPOやEMの代理人を立てる
• 地理的にチームを再編する場合、コンウェイの法則に従い、アーキテクチャと組織のGap無くすようにする

個人及び対話

• 3種類の専門的な能力を開発する
• テクノロジに関する知識
• ソフトウェア開発プラクティス
• 専門分野、ビジネスに関する知識
• PDL(Professional Development Ladder)をつかってキャリアパス制度を導入する
• 文献: Career Pathing for Software Professionals
• チームでの効果的な対話
• EQ: Emotional Intelligence を向上させる
• 性格タイプの違いを理解してコミュニケーションする
• 
• タックマンモデルに現れるチームの4つの成長段階
• 
• 今チームがどの段階にいるかを理解することでその状況が普通であると安心し、次の段階への速やかな移行を促す
• 他者の成功をどのように手助けすればよいかについて考える発想の転換はチームに道徳的な力を育むのに役立つ
• Rotary International の4つのテスト(The Four-Way Test)にパスする決定や対話はチーム全体の強化につながる
• それは事実か
• それはみんなにとって公平か
• それは好意と友情を深めるか
• それはみんなのためになるか

プロジェクト

• プロジェクトを小さく保つ
• 成功率と一人当たりの生産性が上がり、エラー率が下がる
• スプリントを短く保つ
• 新しい要求、フィードバック、改善、実験への反応性が高まる
• リスクの顕在化が早まる
• チームと個人の説明責任がより明確になる
• バーティカルスライスによるデリバリー
• 頻繁に動く機能をデリバリーするための設計アプローチ
• 非技術系のステークホルダーにとって理解しやすく、フィードバックループをタイトにする
• バーティカルスライスに転換するには設計スキルが必要
• 技術的負債を管理する
• 返済のための計画を立て、ビジネスと話し合う
• 持続可能なペース
• 常に同じスプリントを継続することはハムスターの回し車のよう感覚を覚えることがある
• 例えば一週間スプリントを挟み普段できない改善や学習をする

大規模なプロジェクト

• 大規模なシステムにとっての理想は、そのプロジェクトに取り組むチームの作業を完全に分割できるようなもの
• コンウェイの法則からアーキテクチャと人間組織両方に目を向ける

品質

• 欠陥の挿入と検出の時間的GAPを最小限にし、潜在的（見つかってない）な欠陥を最小限にすることでリスクを最小限にする
• 明確な完成の定義を作り使用する
• 定義を満たしたものからQAが可能となる
• リリース可能な品質水準を維持する
• スプリントごとにリリース水準を維持していれば欠陥の挿入と検出のギャップが最小限になり負債の蓄積を回避する
• またそれ以上の作業は不要であることを意味し、計画のトラッキングをサポートする

テスト

• ユニットテストとユーザーレベルのテストの自動化
• テストカバレッジ70%が現実ライン、ただそれが目的ではない
• テストカバレッジはコードの質を担保しないのでコードメトリクスを監視する

要求の作成

• アジャイルでは要求の推敲をジャストインタイムで行う
• クネビン複雑系の問題に対して、フィードバックループをタイトにすることで不確実性による要求の仕損を最小限にする考え方
• プロダクトバックログ（PB）
• 複数スプリントにまたがるフィーチャーやエピック、1スプリントで完結するストーリー
• それ以外にテーマやアイディア、技術的負債への対応など
• PBへのアイテム追加
• トップダウン式の課題は詳細の掘り下げが不十分になること
• ボトムアップ式の課題は「木を見て森を見ず」になること
• PBのリファインメント
• 継続的に実施し予想外の展開に何度も出くわさないように
• 十分にリファインメントされたPBLがスプリント2つ分あるようにする
• 準備完了の定義を作成し、使用する

要求の優先順位付け

• PO重要
• 専門分野の専門知識
• ソフトウェア要求のスキル
• ファシリテーションスキル
• 決定者が決める時とグループが決める時の心得
• エネルギッシュに一貫してやり遂げる特性
• ビジネス価値と開発コストをTシャツサイズに分類し、非技術系のステークホルダーが判断を下せるようにする
• ビジネス価値と開発コストのマトリックスで正味のビジネス価値を数字で割り当て判断する
• 上位のストーリーは即座に承認
• 下位のストーリーは却下
• 中間のものはその後の見直しで動く可能性がある
• ストーリーマッピングにより機能を首尾一貫したパッケージにまとめる
• MVPが難しい場合
• Earliest Testable Product
• 顧客が何かを試せる最初のリリース
• Earliest Usable Product
• 新しいもの好きの顧客が実際に使ってみようと考える最初のリリース
• Earliest Lovable Product
• 顧客に気に入ってもらえそうな最初のリリース

デリバリー

• ソフトウェア作業はデプロイに近いほど自動化に適している
• 自動化が不可能な要求、設計、構築を自動化が可能なデリバリーとデプロイから切り離すことが鍵
• 頻繁な統合により欠陥の挿入と検出のギャップを最小限にする

リーダーシップ

• リーダーはチームとスプリントをブラックボックスとして扱い、スプリントのインプットとアウトプットだけを管理する
• リーダーはチームの決定を導くための「司令官の意図」を伝える
• プロジェクトの理由と動機、背景の明文化
• 求められている最終状態を可視化
• リーダーは優先順位を決めて伝える
• チームは自分たちの責任と裁量でスループット、作業が完了するペースにフォーカスする

組織文化

• 必要な間違いを素早く犯し学習することを良しとする
• チームに心理的安全性があるか、阻害する要因がないかに注意し、有れば取り除く
• 圧力ではなくキャパシティの計測に基づいてプランニングする
• チームの学習と成長を後押しする
• 持続可能なペース
• プラクティスコミュニティなどの機会
• 発展途上なら組織の他のリーダーを参加させる

計測

• ベロシティと共に手戻り率にも注意し改善する
• 計測の目的について透明性を保つ
• チームの自己改善を支援することも１つ

プロセス改善

• 人ではなく仕組みを改善する
• 改善を取り入れた前後数回のスプリントのペロシティの平均を取れば生産性の向上がわかる
• チーム間のベロシティの比較は意味がないが、向上率は比較できる
• スループットを低下するWIPのネックを改善するにはカンバンとリーンが役に立つかもしれない
• アジャイルの焦点はチームにあり、個人のベロシティは外部変数が多すぎて意味のある計測はできない

予測可能性

• シーケンシャル開発は固定したフィーチャーに対してスケジュールを予測することに焦点
• アジャイル開発は固定したスケジュールの中で最も価値の高いフィーチャーをデリバリーすることに焦点
• ただ、バックログを定義した後は見積もりを予測することが可能
• 予測可能性のサポート
• ストーリーポイントの割り当て
• ベロシティの計算
• 小さなストーリー
• バックログリファインメント
• 短いイテレーション
• リリースバーンダウン
• ベロシティのばらつきから信頼区間を予測する
• 実際には予測の対象が絶えず変化するため、予測とコントロールの組み合わせである
• エピックのストーリーポイントをそのエピックの予算と考える方法もある
• エピックが55ptであればその中で価値を最大にするストーリーを選ぶ
• 予測を重視するのであれば初期作業をシーケンシャルに取り組む
• ただし複雑系の要素が多いのであれば確実に予測するのは不可能になる
• 複雑系に分類された作業は予測から調査に切り替える
• 見積もりを必要としているビジネス側を否定することは、顧客とのコラボレーション原則に反する

規制産業

• ドキュメントの作成、リリースサイクルの変更などが必要になるがアジャイル開発は不可能ではない、という話
• 完成の定義や自動化などのプラクティスは規制の目的、品質を後押しする
• 規制上の要件が、法律ではなく古い企業文化に基づく場合は改善の可能性がある

ポートフォリオマネジメント

• WSJF: Weighted Shortest Job First
• CoD: Cost of Delay を突き止め CoD / 開発期間 = WSJFの高いものから開発することで機会損失を最小限にする考え方
• 全てを平行し最後に一度にリリースするのは機会損失ワースト
• コストが明確でない場合もストーリーポイントやTシャツサイズの考え方を流用できる

導入

• ドミノ変革モデル: 次の順で１つでも欠けるとうまくいかない
1. ビジョン: なぜやるのか、どうよくなるのか
2. コンセンサス
3. スキル
4. リソース: 時間、専任者、ツール etc.
5. インセンティブ: 自律、熟達、目的
6. アクションプラン
• 導入にもキャズム理論が当てはまる
• 最初の導入はイノベーター、アーリーアダプターのような人が良い
• 組織の人々の大多数は後期のアダプターでありより多くの支援を必要とする

書評）マンガでやさしくわかる学習する組織

マンガでやさしくわかる学習する組織 [ 小田 理一郎 ]

 

感想

冬の課題図書として。

自分の組織マネジメントで、今日より明日の方が仕事が上手くなるチーム、失敗から学んで上手くなるチーム、未来のために自己学習を続けるチーム、辺りがなんとなく大事なんだろーなー、と思い、なんとなくそこにつながってそうな「学習する組織」に前から興味があったんですが、分厚い本が苦手なのでマンガでわかるシリーズを読んでみました。

 

学習する組織とは「誰かに言われて動くのでは無く、自分で考えて動く社員のいる組織」ということでした。

 

学習するために問題やテーマを大局、全体像から根本にアプローチして本質について考え観察する手法としてのシステム思考については、

対象を、

• 目に見えるできごと
• そこに繰り返し現れるパターン
• それを引き起こす構造
• 根っこにあるメンタルモデル

のそれぞれのレベルで観察する話が具体例で解説されてて勉強になったり、

 

解釈、認知のフィルターとなるメンタルモデル、その認知の働きを「推論のはしご」として人それぞれなぜ違う捉え方をするのかの解説も勉強になったし、

 

個人のビジョンと共有ビジョンを作る話も参考になったり、

 

と、色々学びの多い本でした。

マンガはシンプルでそんな上手くいかないでしょ的なものですが、それによって理論がイメージに落ちやすくて全般わかりやすいものになってました。

 

と、やはりこの手の話はサーバントリーダーシップや7つの習慣辺りと通じるんだなぁと感じます。

チームや組織を持つリーダーにお勧めできる本でした。

 

 

ポイントサマリ

 

なぜ、人と組織は変われないのか

• 人は変えられることに抵抗する
• 自ら状況を理解し、その選択肢を明確にした上で、どのような行動を選択するかを決めるプロセスに関わった人たちは、変化に抵抗するのでは無く、建設的に進めようとする傾向がある

 

学習する組織とは

• 誰かに言われて動くのでは無く、自分で考えて動く社員のいる組織
• やる気の温度差、上から目線は組織の学習を阻害する

 

システム思考

• 問題が単純明確な場合はそこへ対処する
• 論理的思考
• 問題が複雑な場合は対象の大局、全体像、根本にアプローチして本質について考える
• システム思考
• システムとは相互に作用し合う要素の集合体
• 人間関係、家族、社会、市場、業界など
• 氷山モデル
• 繰り返し起こるパターンや大きな流れが観察される時、なんらかの構造がそれを作り出している
• 表面: できごとのレベル
• 1層: パターンのレベル
• 2層: 構造のレベル
• 3層: メンタルモデルのレベル
• 課題への対応策を浅く安直に感じるのはできごとへの対応になっている可能性がある
• パターンを把握するための3つの相互作用基本構成単位
• 自己強化型ループ
• バランス型ループ
• 遅れ
• これらの組み合わせとしてよくある型がシステム原型
• 成長の限界
• うまくいかない解決策
• 問題のすり替わり
• 課題に向き合う際にこれらの型に当てはまってないか分析し、課題を見える化、構造化して本質的な解決策を見出す
• システム原型の目的は視点のレベルをできごとからパターン、構造、メンタルモデルへ引き下げること

 

共創的コミュニケーション

• 解釈、認知のフィルターとなるメンタルモデル、その認知の働きをわかりやすく解釈するための「推論のはしご」
• メンタルモデルやがて世界観やステレオタイプを形成し偏見となるリスク
• メンタルモデルへの対処
• オープンマインドで真摯に相手に問いかけ、探究の質を高める
• 自分の主張や結論を仮説として呈示して、主張の質を高める
• 仮説に至った背景も伝え仮説の検証も厭わない発言をする
• 自分の思うメンタルモデルと行動に現れるメンタルモデルは違い、自分では気づきにくいため他人の意見を聞くことも必要（1on1など）
• 個人個人がメンタルモデルを理解することが共創的コミュニケーションのベースになる
• チーム学習のレベルアップ
• メンタルモデルを一旦脇に置いて現実を観察、傾聴する。自分の意見は仮説として呈示し、推論のはしごに沿ってその根拠を伝える
• 相手の立場に視座を転換する。相手の立場を知り共感するからと言って同調する必要はない
• 自分の中で大切にしてきたビジョン、目標、信念、規範のいずれかを手放し、全体の視座に転換することでより大事なものを手に入れる、または保全する

 

自己マスタリー

• 自己マスタリーとは、自分の仕事を自分ごとと捉えて、目指す姿を明確にして自己を磨き続けること
• 自分自身のビジョン（何を成し遂げたいか）は自分事になってないとと覚悟を疑われる内容になる
• ビジョンと現実のGAPを埋めるために創造的緊張が生まれる
• 逆は感情的緊張、外部からのプレッシャーにより創造性を損ない不正に走るなど手段と目的を取り違えたりする
• 人は自らが学びたいことこそ、自発的に、かつ効率的に学ぶ

 

共有ビジョン

• ミッション、組織がなぜ存在するのか
• ビジョン、組織が何を作り出すのか
• バリュー、組織がどのような基本理念や規範を大切にするのか
• 私のビジョンが私たちのビジョンとなるよう、個人のものが反映され、共有するもの同士が互いに誓約する
• 共有ビジョンの普及では、プレゼンだけで無く組織の日々の意思決定や行動に織り込んでいく。また社員に選択の自由を与える

 

学習する組織の実践プロセスと戦略の構造

• テーマとチームメンバーの設定
• テーマは組織や企業課題から、または話し合って
• チームの「学習する組織」に関する教育と関係性構築
• システムの観察と多様な関係者による対話
• システム思考、氷山モデルからの観察と対話
• 共有ビジョンと個人ビジョンの融合
• 何を創り出したいのか
• ビジョンステートメント
• 実験と学習
• 素早いフィードバックループを回す
• システム的な変化の展開
• ハードとソフト両面での横展開
• 普及のためのコミュニケーションと学習プランも

 

変革を導くリーダーシップ

• 現場リーダー、実践と検証
• ネットワークリーダー、部署間など支援協業関係性構築の媒介役
• 役員リーダー、組織環境を整え反対勢力に対する守護神
• 現場リーダー、ネットワークリーダーのコーチング

 

深い学習サイクルと戦略の構造

• 学習を後押しする経営理念の設定
• 役員リーダーの役割
• 学習のための理論、ツール、手法の習得
• 現場リーダーが身につけメンバーへ
• 学習インフラにおけるイノベーション
• 研修、指導、ITシステム、評価の仕組みなど
• 役員リーダーの庇護のもとでのネットワークリーダーの役割

書評）英語の品格 実践編

[音声DL付]英語の品格　実践編【電子書籍】[ ロッシェル・カップ ]

英語の語彙が少ないと、短く一言二言で返信しがちですが、品格ある英語で返すとどうなるか、というのを60のシチュエーション別に初級、中級、上級と3つのレベルで教えてくれます。

一例）

Situation

何回かあったことのある取引先の人と再会したときにする挨拶

ダメな言い方

Hello.

品格のある言い方

初級： Nice to see you again.

中級： It's good to see you again. How are you?

上級： Long time no see! How have you been?

それぞれなぜ品格があるのかの解説と共に何を気にするべきなのかを説明してくれます。

単にhelloやyesやnoだけじゃなく、最初に感謝を伝えたり、説明をつけ加えたり、共感を示したり、要求を伝えたり、次にやることを伝えたり、といろんなTipsとともに自然な英語を学ぶことができました。

こんな時どう答える？という問いから始まるので、いったん自分で英作文してみて、回答をみる、と使うと瞬間英作文のようなトレーニングになって良さそうです。

一読するだけだと身につかないので何度も読み返そうと思います。

書評）WEB+DB PRESSまとめ

参考になった記事をメモ。

 

Vol.117

WEB+DB PRESS Vol.117【電子書籍】[ WEB+DB PRESS編集部【編】 ]

通常のJavaScript で実装してからTypeScriptに置き換えていく記事がすごくわかりやすかったし、たしかうちにもサーバーサイドでJS使ってるチームあったから役立ちそうだな、とか、
AWS/GCPコスト削減の記事は、どういう削減アプローチがあるかの説明がわかりやすくてマネージャでも理解できたし、
Windows の開発環境の記事を参考に、実際に会社のPCに環境構築してみたら（ちょいはまったけど）、こんなこともできるようになったんだと感動。
きちんとPHPの記事ではPSRについて復習できたし、
とてもよい号でした。

Vol.116

WEB+DB PRESS Vol.116【電子書籍】[ WEB+DB PRESS編集部【編】 ]

新連載の「マネジメントの現場」がEngineering manager に関するトピックで面白かったのと、「わかりやすいFAQの書き方」があまりこういう観点の話ってこれまで整理されたものを読んだことがなかったので参考になりました。

Vol.115

WEB+DB PRESS Vol.115【電子書籍】[ WEB+DB PRESS編集部【編】 ]

CORSについての詳しい記事とPHPでの型システムについての解説が分かりやすい。

Vol.114

WEB+DB PRESS Vol.114【電子書籍】[ WEB+DB PRESS編集部【編】 ]

2段階認証と2要素認証の違い、知識情報（パスワードなど）、所持情報（スマホやICカードなど）、生体情報（顔や指紋など）のいずれかを組み合わせたものが多要素認証で、特に2つの異なる要素を満たしたものが2FAであること、Eメールにワンタイムパスワードを送信する認証はデバイスの所有に該当しないので1要素の2段階認証であること、などの解説が分かりやすかったです。

またFIDOの歴史と取り組み、FIDO2のWebAuthnがW3Cに標準化されたことで今後広がりを見せることなどについて知れました。

 

Vol.113

WEB+DB PRESS Vol.113【電子書籍】[ WEB+DB PRESS編集部【編】 ]

ドメイン駆動設計の解説が素晴らしい。

Vol.109

WEB+DB PRESS Vol.109【電子書籍】[ WEB+DB PRESS編集部【編】 ]

Fastlyを例にしたCDNの仕組み、キャッシュ設計、その他便利機能について。

 

 

書評）ヤフーの1on1

ヤフーの1on1 部下を成長させるコミュニケーションの技法 [ 本間 浩輔 ] 価格：1980円（税込、送料無料) (2020/7/25時点) 楽天で購入

感想

だいぶに前に購入したけど、今更1on1の本か…と思って積読してたのですが連休を使ってやっと読み終わりました。

 

人の成長のうち7割は仕事の経験から、この7割に焦点を当てて経験学習を浸透させる手段としての1on1というテーマで、それをやる意味から手法まで基礎的ですが大事なことを教えてくれます。

1on1は部下のため、という聞いてはいるけど忘れがちなコンセプトとその理由、陥りがちな失敗、具体的な手法は、初めてリーダー職になって1on1を始めた人だけでなく、既にやれてると思ってる人（＝自分）が再考する気づきも与えてくれます。

 

コルブの経験学習モデル、

• 具体的経験→内省（振り返る）→教訓を引き出す（持論化、概念化）→新しい状況への適用（持論・教訓を活かす）

このサイクルを回しメンバーの成長とキャリア開発を支援して、結果として組織の安定と成長、事業の成果に結びつける1on1という手法についていい感じに振り返りをさせてくれる本でした。

 

 

ポイントサマリ

マンガで学ぶ1on1ミーティングの基本

• 経験学習
• 自分の経験を詳細に思い出して、言葉にして、深く内省することが必要
• 助言ではなく、遮らず、本人に話させて考えさせる
• 言い換え
• 部下の発言から状況を想像して適切な言葉を選び投げかける
• 別の表現、視点から部下が考えを深め掘り下げるよう促す
• ニュートラル
• 肯定、否定、評価をせず部下が考えを深めるよう反応する
• 否定は常にNGではないが慎重に
• 行動で終わる
• 指示するのではなく、行動のイメージを浮かべてもらうよう問いかける
• 本人から行動宣言をさせ、コミットメントを引き出す

 

1on1とは何か

• 7：2：1の理論
• 7割は仕事経験から学ぶ
• 2割は他者から学ぶ
• 1割は研修や書籍から学ぶ
• 経験を学習に変換するアクション、振り返りが1on1
• コルブの経験学習モデル
• 具体的経験→内省（振り返る）→教訓を引き出す（持論化、概念化）→新しい状況への適用（持論・教訓を活かす）
• 部下が情熱を持てる仕事、職業感について話し合う
• 自分で見えない客観的評価について伝え話し合う
• 部下の目標に対するラップライムを測り伝える
• 「今日は何を話そうか」
• 部下がテーマを決め、上司が聞きたいことを聞く場ではない
• 習慣化すると部下は準備するようになり前もって内政が始まる
• 「もう少し詳しく聞かせて」
• 部下の頭の中の動いてなかった部分を動かし内省を深める
• アドバイスをしがちだがそれでは依存が強まるだけ
• 「○○って事？」
• 曖昧なことを明確化する為に質問する
• 極端に言ってみるのがコツ
• 「なるほど」
• 否定せず評価せずニュートラルに受け止める
• 部下に「こんなことも話していいんだ」と思ってもらう
• 「○○さんは○○したいんだ」
• あえて主語を明確にすることで本人の本音であることを確認する
• 「うん（沈黙）」
• アドバイスをグッと堪えて部下が考え言葉を発するのを待つ
• 自分に対するネガティブな発言に「自分ではそう思ってるんだ」
• 「そんなことないよ」と言われることを期待されていてもニュートラルに返し思考を深める
• 期待していることを言ってもらうと思考が止まる
• 「次はどうする？」「今決めなくてもいいけど」
• 教訓化ができたところで次の行動を宣言させる
• 「いつまでに？手伝えることは？」
• コミットメントを宣言させる
• 上司が手伝うと部下もやらないわけには行かなくなりコミットメントを誘発する
• 上司としてもコミットメントに協力できることは理想
• 1on1サーベイは1on1を上司・部下のブラックボックス化を防ぐ仕組み
• 制度化
• 「やったほうが良いこと」は「やることになっている」方が楽
• コミュニケーションの定義
• 仕事では「自分の意図を相手が理解し、実際に行動する」こと

 

1on1に置ける働きかけ

• 第1段階：信頼関係の構築
• アクティブリスニング
• レコグニッション：無条件の肯定的な配慮
• 自分の期待値と部下の感じていることにGAPがあっても、部下が感じていることは事実として認める
• もっとやれるはずと思っている部下が「忙しすぎる」と言っても、まずはその事実を認め共感する。同意しているわけではない
• 信頼関係を構築するための手段として意識する
• 第2段階：学びの深化
• コーチング
• 質問を重ねて部下の新たな発想や気づき、思考の言語化を促す
• 問題点が明らかになったら次の行動を促す
• 内発アクションの方がやる気が出る
• ティーチング
• 社内ルールのように知ってれば済むことはティーチング
• フィードバック
• 上司が期待する水準と、部下の成果との差を伝える
• なぜその差が生じているのかを明らかにする
• 相手が気付かないことを伝える
• 非言語なこと「Aさんのことを話すときに手を組むけど、苦手意識があるの？」について気付かないことを伝え、気づきを得るきっかけを作る
• 「学んだことは？」
• 失敗から、1on1から学びを深める為に問いかける
• 学びは言語化されるプロセスを経て認識される
• 第3段階：次の行動の決定
• 「この学びを次にどこへ活かす？」
• 守られなければ「なぜできなかったのか」についてまた話す
• コラムから
• 内容のメモを共有してくれることはありがたいと感じる
• 成功はなぜ成功したかを振り返って言語化しないと再現性が生まれない
• 1on1が「部下のための時間」というコンセプトを受け入れられない人もいる。まずマインドセットの教育が必要。