書評）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が「部下のための時間」というコンセプトを受け入れられない人もいる。まずマインドセットの教育が必要。

 

 

書評）みんなでアジャイル

みんなでアジャイル 変化に対応できる顧客中心組織のつくりかた [ Matt LeMay ] 価格：2640円（税込、送料無料) (2020/7/19時点) 楽天で購入

 

感想

手法としてのアジャイル、マインドセットとしてのアジャイルの双方が密に繋がっているものとしてのムーブメントとしてのアジャイルが、開発チームだけでなく経営、マーケティング、セールスみんなでアジャイルを実践し価値を生む為に欠かせない、みたいなテーマ（だと思う）。

 

全体を通して僕の印象に残ったのが「なぜ」を考える、目的を考える、という事についてしつこいくらいに言及している事。アジャイルのプラクティスを取り入れるにしても「なぜ」それをするといいのか、何を目的としているのか。そしてその先、何を顧客に届けるのか。アジャイルの根底にある価値と原則を理解する事が職種問わず文化を作り組織を変えていくんだ、みたいなメッセージを受け取りました。

 

あとダイバーシティと並んで使われるインクルージョンという言葉について「誰もが参加して貢献する機会があって、その人が持つ経験やスキルを活用している状態を指す」という話については今の自分の組織マネジメントのヒントを貰えました。

 

ボリュームがそれほどないので内容としてはそれほど詳細じゃないけど、組織の変革に関する「考え方」に色々ヒントを貰えたのと、たまに基本に立ち返るのも大事だな、と思えた本でした。

 

 

ポイントサマリ

アジャイルとは何か？なぜ重要なのか？

• アジャイルムーブメントは、企業の厳しい条件に反発したソフトウェア開発者の間で同時に起こったもので加速度的な技術の変化に対する反動だった
• アジャイルは私たちをより良い方向に向かって協働させる
• 私たちのチームや組織は、採用したプロセスが生み出すのではなく、一緒に働く人たちが生み出すもの
• 私たちは習慣の奴隷で、多くの組織は従来の仕事の仕方が築き上げてきた総和。アジャイルの原則がそれを避けるのに役立つ
• アジャイル、リーン、デザイン思考はムーブメントであり、急激に変化する世界において組織はどのようにして顧客のニーズを満たすことができるのかという、類似した根本課題に取り組んでいる
• アジャイルはベロシティ、プロダクトを市場にリリースするスピード
• リーンは効率性、製造プロセスからどれだけ無駄を排除したか
• デザイン思考はユーザビリティ、プロダクトが顧客に提供した価値

 

自分たちの北極星を見つける

• 解決しようとしている課題や、解決のために従う原則を理解する
• 正しいプラクティスに従う前に、これまでの何が正しくなかったを確かめる
• プラクティスを意義のあるものにする為に、ゴールと課題を設定する
• チームや組織が将来なりたい状態は？
• 現状は？
• なりたい状態になれないと思う理由は何か？
• プラクティスを自分のものにする為に、アジャイルの価値と原則を使って変化を促す
• 価値と原則をどのように捉えたら、組織のゴールを達成する為に役立つか
• プラクティスを組織に合わせて特殊化はしても、骨抜きにしてはいけない

 

顧客から始めるのがアジャイル

• アウトプットより顧客に届ける成果
• 組織重力の第一法則
• 組織に属する個人は、日々の責任やインセンティブと整合性がなければ顧客と向き合う仕事を避ける
• UXや顧客サポート担当が重要な決定の場にいることはない
• アジャイルは今までと同じものを速くやる方法とみなすと、顧客が違うものを欲しがるかもしれないという本当のリスクから逃れられないかもしれない
• 包括的なドキュメントよりも動くソフトウェアを
• 顧客に価値をもたらさない中間状態に費やす時間を減らす
• MVP
• 手遅れになる前に顧客の体験を理解して改善できる
• 顧客を起点にしてそこから戻るように作業する
• 顧客が利用するときの準備、環境、状況は？
• 原則
• 顧客にフィードバックをすべてのサイクルで必須にする
• 難しければドッグフーディング
• 自分たちの「動くソフトウェア」の定義を見つける
• 各スプリントの終わりに届けてテストするものは何か
• 今やった仕事を捨てる覚悟をしておく
• 作る速度よりも顧客の学習を重視する
• 細部に囚われすぎないようにしておく
• 正解は多くの試行錯誤から生まれるし状況は変わる
• 会議のアジェンダ、ドキュメントに顧客のフィードバック、インサイトを登場させる

 

早期から頻繁にコラボレーションするのがアジャイル

• 例えばコンプライアンスチームと早期に
• 会議は報告と批評の場ではなく共有と決定のための協調の場
• 形式的な会議の枠を超えて非公式なコミュニケーションの場を広げる
• 「温室」のアプローチ
• 例えばビジネスオーナー、デザイナー、エンジニアを同じ部屋に集める
• 何を決めるかを決める
• 会議・意思決定におけるタイムボックスの練習をする
• 参加者への期待を明確にする
• 会議と呼ばず、時間の無駄という思い込みから脱出する
• 同期して行うことと、メールなど非同期チャネルを使い分ける
• インクルージョン
• 誰もが参加して貢献する機会があって、その人が持つ経験やスキルを活用している状態を指す
• 既に取り組んでいる人、動いているものを見つけてつなげる
• うまくいったやり方を他に適用してみる
• なぜデイリースタンドアップをやっているかを明確にする
• チームのゴールに合わせて質問を変えてもいい
• 下流だけでなく、上流の戦略でもコラボレーションを起こす
• アイディアや試作を完成し洗練する前に共有する
• 壊すことに抵抗がない段階で共有する
• 非同期フィードバックを依頼する際は誰になぜを明確にする
• RACIフレームワークなど

 

不確実性を計画するのがアジャイル

• 年間計画がある場合でも、4半期ごとなどに学習の機会を取り入れ、年間計画を達成する為に短期サイクルを見直すことはできる
• 振り返りは最良の学習の機会
• 定期的に顧客や市場に関する新しい情報を組織全体の人たちと共有する場を設ける
• 決定を下す際に100％の確実性を要求しない
• 変化する可能性をプロジェクト計画の一部に含める
• 意思決定を低〜高インパクト、不確実〜確実でマッピングし、確実なことと重要なことを区別してリスクについて話ができるようにする

 

3つの原則に従い、早くて柔軟で顧客第一なのがアジャイル

• リーダーがアジャイルを受け入れる為に、アジャイルによって個人が何を得られるかを明確にする
• 情報の上下の移動で1日を過ごすハブアンドスポークモデルのミドルマネジメント層になるのではなく、機能横断の世界で専門職と肩を並べて働き、彼らがどのように働くかを理解できる学習環境にいることに価値がある
• エンタープライズデザイン思考の例
• 内部ベロシティではなく市場でのベロシティをゴールと理解する
• 企業に共鳴する言葉を利用する
• 顧客体験を中心として異なる職能の人たちと協業する
• 組織にプラクティスが適合し、リーダーシップのサポートを得られればプラクティスは自然とチームにスケールする（プル型）
• なぜ（目的）とどうやって（方法）は分けて考える
• 考えるボリュームが絞られる
• 「なぜ」があることで「どうやって」に合意でき実行のガイドになる
• 「なぜ」はイテレーションの中で再考し、それが変われば「どうやって」も再構成する
• プロトタイプ・デモへの3つのフィードバック
• 「なぜ」に合致していて保護されるべきもの
• 「なぜ」に貢献していないので削除されるべきもの
• 「なぜ」に対応する為にもっと洗練されるべきもの
• 組織のリーダーの評価と昇進基準にアジャイルの価値と原則を組み込む
• リーダーが学習し発揮した経験を語ってもらう機会を設ける

 

あなたのアジャイルプレイブック

• https://bit.ly/AgileforEverybodyPlaybookJapanese

 

 

書評）Elastic Leadership 自己組織化チームの育て方

エラスティックリーダーシップ 自己組織化チームの育て方 [ Roy Osherove ] 価格：3080円（税込、送料無料) (2020/3/1時点) 楽天で購入

 

感想

「自己組織化」が最近の個人的ホットトピックなのですが、それで検索するとそのままズバリの本が見つかったので読んで見ました。

 

「チームリーダーである私たちの目標は、チームの各メンバーとチーム全体の自己組織化と自己管理のスキルを全体的に成長させて行くことだ」というようなテーマで書かれたこの本は、チームのフェーズを3つに分け、それぞれに必要なリーダーシップのスタイルを解説していました。

 

サバイバルフェーズ：指揮統制型リーダーシップ

• このモードを解除することがミッション
• チームに学習する時間がない
• ゆとり時間を作り脱出する

 

学習フェーズ：コーチ型リーダーシップ

• 自分や他のバス因子を重要な枠割りから取り除くのがミッション
• 建設的なことにゆとり時間を使う
• 経験のないメンバーに一緒に経験させる
• 適宜、指揮統制型として介入する

 

自己組織化フェーズ：ファシリテート型リーダーシップ

• ファシリテーターとしてこの状態を維持するのがミッション
• 現状を処理するチームの能力に注意を払い次に取るべきリーダーシップスタイルを判断する
• リーダーは実験したり重要なことに時間を使える

 

それぞれのフェーズでリーダーに求められる振る舞いがわかりやすく解説されていました。その内容も良かったのですが、後半が著名なリーダーたちのエッセイ集となっており、そこがまた刺さります。

かつ日本語版特典として日本のリーダーたちのエッセイも収録されているのですが、なんか聞いたことがある人がいっぱい…。

 

「近い・遠い、具体的・抽象的の組み合わせで考えるリーダーとしての方向性の導き方」や、「チームをマネジメントすることを言い訳に、事業やプロダクトや技術から目を背けていい兄貴になりがち」といったエッセイがグサグサ刺さり、気が引き締まるのを感じながら読み終えました。

 

 

ポイントサマリ

 

エラスティックリーダーシップを理解する

 

チームリーダーマニュフェストに向かって努力する

• チームが求めるリーダーシップは彼らのスキルに応じて変化する
• リーダーシップスタイルを継続的に変化させるアプローチを採用する
• チームのニーズに合ったスタイルを認識する
• 自分自身とチームが改善することに挑戦する
• ゆとり時間を作る
• 安全よりもリスクを取る
• 現状維持よりも実験する
• 適切な道具、プロセス、実際の仕事環境で実験する
• メンバーを導くことが中核的なプラクティス
• 人やコミュニケーションの問題を解決するテクニックを学ぶ
• リーダーが問題を解決すると学習するのはリーダーになってしまう
• ボトルネックにもなり休めなくなる

 

リーダーシップスタイルをチームのフェーズに合わせる

• サバイバルフェーズ：指揮統制型リーダーシップ
• このモードを解除することがミッション
• チームに学習する時間がない
• ゆとり時間を作り脱出する
• 学習フェーズ：コーチ型リーダーシップ
• 自分や他のバス因子を重要な枠割りから取り除くのがミッション
• 建設的なことにゆとり時間を使う
• 経験のないメンバーに一緒に経験させる
• 適宜指揮統制型として介入する
• 自己組織化フェーズ：ファシリテート型リーダーシップ
• ファシリテーターとしてこの状態を維持するのがミッション
• 現状を処理するチームの能力に注意を払い次に取るべきリーダーシップスタイルを判断する
• リーダーは実験したり重要なことに時間を使える
   

バス因子（トラックナンバー）に対処する

• 単一障害展、ボトルネック、士気の低下、成長の阻害
• バス因子を見つけ、防ぎ減らすことがリーダーの役割の大部分を占める

 

 

 

サバイバルモード

 

サバイバルモードに対処する

• 中毒性があり留まろうとする傾向がある
• いくつかのコミットメントを取り消す必要がありそれがリーダーの仕事
• リーダーの仕事の対価
• 厳しい要求に応え、判断を下すこと
• チームをプロフェッショナルにすること
• 全力をかけてチームがソフトウェアを届ける際に最善を尽くせる状態にすること
• 自分の習慣を破る
• 新しい挑戦の前には確かな足がかりを捨てる時期がある
• 指揮統制型リーダーシップ
• 会議を開かず決定を下す
• 悪い決定を正す（Gitを使おうなど）
• 課題解決は得意な人をアサインする
• 反対意見には1on1で今のモードを説明する
• 別のProjectで働いてもらうことも
• 時間を浪費しない
• 移行期間に行うこと
• 不要な会議を捨てチームと過ごす時間を増やし支援する
• 複数のステークホルダからチームに指示させない
• 割れ窓理論を理解する
• レビュー品質の妥協は割れ窓
   

学習モード

 

学習することを学ぶ

• 学習モード
• チームを安全地帯の外へ押し出す
• 抵抗を感じるならチームをうまく操縦できている
• ゆとり時間を集中訓練に使っている状態
• 基本はコーチスタイル
• 間違った決定には時に指揮統制が必要
• SCMを使わない、というのはありえない
• 学習には谷（リスクや生産性の低下）があり飛び込むことを恐れてはいけない
• 全く異なる技術スタックの組織で見習になる、など
• メンバーを谷に飛び込ませるための「宿題」という方法
• 全ての会話で一番最後に話す人になる、など
• 1on1で説明するのが良い

 

コミットメント言語

• 効能
• メンバーが阻害要因だと感じていてもリーダーに話しにくいと思っていることを探しだすのに役立つ
• メンバーが言ったことに対して責任を感じる
• 制御下にないコミットメントを可能なものに変える
• バグを今週中に修正します、は制御下にないコミットメント
• ではなく、毎日5時間をバグ修正に当てます、ならコミットできる
• 外部要因に関わるものも注意
• 約束できないことを伝えることは誠実である
• リーダーもチームもこれを理解し実践する
• あらかじめこの言語を使うことを説明する
• 間違いはお互いに直すルールを敷く
• 最初は不快（谷）になることを知っておく
• コミットメントを果たせないことがわかった時はすぐに警告をあげる
• 早ければ早いほど手を貸すことができる
• Active Listening でコミットメントしたことしてないことを確認する
• 最後は感謝で締める

 

メンバーを成長させる

• 挑戦的課題「あなたはそれに関して何をするつもりですか？」
• コミットメント言語での回答を求める
• リーダーが解決してはいけない
• 最初は不信感、反発がありえる
• リーダーは背後からサポートする
• 人脈や時間など
• 解決できなくても罰しない
• 問題が起きたときに自問することを教えている
• 宿題
• 恐怖や不快感を伴う谷に飛び込ませる
• 日常の作業ではなくスキルを学ぶこと
• 例
• タイピング速度の向上
• 否定的表現を1日3回までに
• 定期的にフォローアップする
• あなたとチームのペース
• ペースを考慮し挑戦が多くなりすぎないように
• 短期的な付き合いであっても同様に接することで将来帰ってくるかもしれない

 

自己組織化モード

 

自己組織化を促進させるためにクリアリングミーティングを行う

• 目的はうまく行っていないことやしまい込んでいる悪い感情、共有すべき情報など、チームが知っていることを全てクリアにすること
• コミットメント言語、誠実さ、ゆとり時間を組み合わせてチームが自分たちの問題を解決するための学習に向かわせる
• 進め方
• 今週うまく行かなかったことは？
• あなたはそれに関して何をするつもりですか？（コミットメント）
• 今週良かったことはなんですか？
• 最後に自分も話す
• 問題に対してすでに対処しているメンバーの数が自己組織化の度合いになる

 

影響パターン

• 6つの影響力のコンテキストを考える
• 個人レベルの能力、モチベーション
• メンバー自身の問題か
• 社会レベルの能力、モチベーション
• 周囲の人々、支援、情報、リソースの問題か
• 環境レベルの能力、モチベーション
• 設備や予算、報酬の問題か
• これらの観点で問題の要素を洗い出して全て解決する

管理職のためのマニュフェスト

• チームリーダーと役割を分け合う
• リーダーは技術、チーム、プロジェクトに関連することにおいてチームを成長させることができる
• 管理職はそれ以外のあらゆることにおいて部下を成長させることができる
• 全体的なスキル向上や個人を多様なプロジェクトで作業させる、など

 

 

チームリーダシップについて知るべきこと

• フィードバック
• サバイバルフェーズ
• よくない行動、やらなければいけないことを伝える
• 「XをやめてYだけに集中しなければなりません」
• 「今週終わらせて欲しいことはXです」
• 学習フェーズ
• 欠けているスキルに関すること
• 貢献してくれているメンバーが直面している難題に関すること
• 「あなたはXで素晴らしい仕事をしました、それはあなたにとってもとても難しいことだったとわかっていました」
• 自己組織化フェーズ
• チーム全体の意思決定や目標に関すること
• 「このアイディアは素晴らしい。できれば2つ以上出して初めに試したい方を選ぶようにしてください」
• 「どうすれば目標を達成できるか。そのために支援できることはありますか？」
• 衝突を学習に導く
• チームが衝突し決定できない時は、コミットメントの延期を提案する。
• それぞれを試し、そのデータから判断させる（並行学習）
• 効率と引き換えに効果を手に入れる
• サバイバルフェーズではこのアプローチは取れない
• おそらく技術的な問題ではない
• 実際は、理解しているのが当然でしていなければ失格という考え方や、それによってグループから追い出されるかもしれないという恐怖かもしれない
• これは個人ではなく社会レベルの問題
• コードをレビューしよう
• できない場合、社会レベル、環境レベルでの問題に目を向ける
• 空気、食料、水をドキュメントする
• リポジトリの場所、チームの開発フローはチームにとってそういったもの
• 「ちょっとした質問」は「ただ」ではない
• バス因子を減らすことにも役立つ
• （給与）査定とアジャイルは仲が良くない
• 査定は個人、非継続的、トップダウンである傾向
• 学習とキャリア開発を個々のユーザーストーリーに組み込む
• イテレーションごとにメンバーが学んだことについて会話する
• イテレーションごとに査定時に参照できる記録を残す
• 学習を通して導くというリーダーの責務
• メンバーに失敗する機会は提供するが、それは必ずチームのセーフティネットのコンテキスト内にある
• Coreプロトコルの紹介
• チェックインプロトコル
• 自分がどう感じているかを怒っている、うれしい、悲しい、不安だ、の4つを使って表現する
• リーダーシップと成熟したチーム
• 自己組織化フェーズにいるリーダーは、チームを観察することが主な責務となる
• 実際には重要なスキルを欠いていることがわかったら、学習歩フェーズに押し戻す必要がある
• 作業負荷を分散する
• 衝突を恐れて頼みやすい人にばかり退屈な仕事を押し付けてはいけない
• 衝突に対処するのがリーダーの責任
• メンバーが自分たちで仕事を管理できるようにする
• 今後は自分たちで仕事を分配することを期待していると表明する
• 難しければ手を貸すことも伝える
• それを実現する方法を理解しているか確認し支援する
• 見守り、尋ね、敬意を示す
• 現在妨げとなっているものの根本的な原因を明らかにするためのオープンで厳密な質問をたくさんする
• リードについて
• 「言いにくいな」とおもったときこそ発言しよう
• 実は別のメンバーも気になっている
• チームに成長してもらうためのリーダーシップ
• 自分が学び成長する
• 他人の学び方を学ぶ
• 1人で抱え込んでいる仕事を減らす
• 現在を記録し、後になって振り返る
• 成長したチームを維持するために力を発揮する
• 解散からリスクをとって守る
• コミニケーションメンテナになる
• コンセプト駆動のリーダーシップ
• 相互リスペクトの維持
• 部下やメンバーに鍛えてもらう
• 共に作業し自分の実力をさらけ出す
• 静かなリーダーシップ
• こうあるべきだ、というのを宣言して周りへ説明しながら淡々と地道に進み続けていく
• いく先を決める
• 集団で活動するときの不安要素
• 今何をすべきなんだろう
• なぜそれをすべきなんだろう
• それによってどうなるのだろう
• やるべきことは多いが一体どれからすべきなんだ
• チームの人はどんな人だろう
• 自分の考えはどう受け止められるだろう
• 方向性はこれらの道標となる
• 近い・遠い、具体的・抽象的の組み合わせで考える
• 制約はチームのモード、余裕と体力
• 求めるゴールが自分の考えを超えて欲しい時は「遠い」方向性を出す
• 遠くて抽象的はぼんやりするので具体的にする
• ゴールが明確でそれを超えたものを求めない時は「近い」方向性を出す
• 近くて具体的、は裁量がないので抽象的にする
• 具体的な方向性の例
• エディタを作る
• 近いテーマ
• 起動が早く軽快なエディタを作る
• 活動がイメージしやすく目指しやすい
• 遠いテーマ
• 使う人がコードを書くのが楽しくなるようなエディタを作る
• チームの能力が足りないと迷走する
• 方向性は現状、抱えている課題、チームの能力、環境、時間んじくなどから導くもの
• 採用プロセスについてもっと考えよう
• 採用も重要な仕事
• 業務後の疲れた頭で正しい判断はできない
• 優秀な人ほど見極める力が高いことが多い
• 採用後のギャップを減らす
• 無理して採らない
• 文化や雰囲気に合わない人も避ける
• チームの平均より上の人を採ることで総合力が上がっていく
• プロジェクトファシリテーションとしての6つ
• 見える化
• みんなわざわざファイルを開いて見ないので壁に貼る
• 名前づけ
• チームが得た気づきに名前をつけて定着させたり外の人へ伝える
• 初めよければ全てよし
• 良いこと、成功しやすいことを先に行う
• 振り返りはKeepから
• ポジティブFBから
• リズム
• チームのイベントはリズムを持って定期的に
• 問題　対　私たちの構図
• 席を同じ方向に向け視線の先に問題を置く
• カイゼン
• 改革ではなく小さくても良いので行動を起こす
• 最後に：QoEL
• 大事な問題にフォーカスする
• 事業を伸ばすには事業を伸ばすことを考える必要がある
• ロジックと願望の違い
• 本当に今最も大きい課題はチームビルディングなのか
• 「いい兄貴」になる誘惑に負けず、難易度の高い問題から目を背けてはいけない
• チームをマネジメントすることを言い訳に、事業やプロダクトや技術から目を背けてしまいがち
• 第一線でリードし続けることが、結果的に自己組織化したチームを作る見本になることもある