mono(0w0)ログ

読んで、体験して、自分でやってみた記録

スクラム道関西 第117回オープン・ジャム に参加しました

初参加でした。 昨年Scrum Boot Camp OSAKA in June 2018に参加してから結構経っていますね。

参加者とか雰囲気とか

  • 参加者は20名強(正確に覚えてない…)
  • 参加者の半数くらいが初参加
  • 参加者の1/3から1/4くらいがこれからスクラム始めたい
    • わりと堅めのことをやっている方々(僕もどちらかというとそっち系)
  • 今回の会場は株式会社ラクスさまのご提供
    • 綺麗で広くてとても快適でした

やったこと

Lean Coffeeによる対話形式でした。

最初に対話したいテーマを個人で付箋に書いて提示します。テーマを出したらドット投票により話してみたい・聞いてみたいテーマの優先順位をつけていきます。優先順位の高いテーマから順に各テーブル(今回は3つ)で対話開始します。

対話のタイムボックスは7分。7分経過したらハンドサインで継続するかやめて次のテーマにうつるかを決定します。継続したときは+2分の時間が設けられました。

僕が参加したのは以下のテーマです。

  • 品質管理はどうしてる?どんなメトリクスを取る?
  • スプリントプランニングどうやる?
  • 認定スクラムマスターについて
  • 社内勉強会や読書会どうしてる?どう続ける?
  • デイリースクラム時間オーバー問題
  • どんなドキュメントを残す?
  • 予算の見積もりどうしてる?

やってみた感想・学び

とりとめなく列挙します。

  • 7分って結構短い
  • タイムボックスが切られているので集中する
  • 自分が抱えている課題に向き合う感覚
  • 実は問題は別のところにあったとか
  • 問題箇所を探索している感覚
  • 本質を考えさせられる
  • コンテクスト大事
  • スクラムガイド読み直そ
  • 湧いてくる新たな疑問
  • 要約して話すとかうまく問いかけるの難しい

おわりに

誰かのお話を聞くのではなく、積極的に対話に参加して自ら学ぶのは大変だけど面白いです。

あー、そういえばできてなかったなーとかマンネリ化あるあるーとか、他の人のお話を聞くことで自分のチームの良くないサインに気づく。自分のチームを外から検査してる感覚。中にいるとなかなか気づけないのだなぁ。あるいは目を逸らして気づかないふりしてるだけなのか。

継続して参加していきたいなと思いました。

起きている問題をきちんと把握する 職場の問題地図読んでみた

子供と図書館に行ったら見つけたので読みました。 基礎的なことですけどわかりやすくまとまっていて、良いふりかえりになりました。

仕事を5つの要素で捉えるのはメンバーに説明しやすくて重宝しています。

5つの要素で仕事をとらえる
  1. 目的
  2. インプット(情報・材料・ツール・スキル)
  3. 成果物(完成物・完了状態・期限・提出先)
  4. 関係者(巻き込むべき関係者・協力者、インプットは誰(どこ)から入手するか、成果物は誰のためか)
  5. 効率(スピード・生産量・コスト・人員・不良率)

また、サービスレベルについても思い当たるところが多くて、思い込みではなく擦り合わせが重要だよなーと過去の辛い時期を思い返していました。ついついあれもこれも自らやっておいて、相手のせいにしてしまっていました。

8.「何を」「どこまでやればいいのか」が曖昧

サービスレベルを設定する
  • その仕事をどんな条件で、どんなレベル(品質・スピードなど)で提供すべきかを設計する
  • 設計したサービスレベルを告知・浸透させる
  • 浸透させるには、「目に見えること」「定期的なリマインド」が不可欠

自分はマネジャーやリーダーの役割ですがメンバーとの調整の場づくりやプロセスの設計・改善をしていかなければと思いました。

はじめに

本当のワークライフバランスとはどうあるものか? 殆どの企業は、プロセスと場へのアプローチが足りない。

今のアプローチとしては、とにかく対話する時間を増やすこと。デイリーミーティング、ふりかえりを習慣にし、1日数分でもいいので話しかけるようにしています。3〜4年前は雑談も無かったプロジェクトですが、今ではチーム内の対話や雑談もかなり増えています。

10.誰が何をやっているのかわからない

こんな状態になっていないか?
  1. 会話がない
  2. 話しかけづらい雰囲気
  3. 常に時間がない
  4. 他人のやり方を知る場がない

個人でも少しずつ始められる考えや行動なので、自分の職場の問題に向き合っていくに良い本だと思います。手戻りが多いメンバーには報連相のタイミングを細かく行うようフォローしたり、会議やミーティングでの決定事項が忘れられたりしていたので、markdownのフォーマット作ってメンバーに使ってねーと配布しました。

会議のやり方を設計する
  1. 目的とアウトプットを確認する
  2. 出席者を選定する
  3. 議事録を取りやすい発言を意識する(報連相の4つのポイント)
  4. 会議の三本締め「決定事項」「宿題事項」「次回予告」

タイトルの通り「問題地図」であるため、自分の職場の問題を探したり、向かい合った上で歩き方は自ら決めて実行しなければならないよねとも感じました。 次はマネージャーの問題地図を読んでみようかな。

2018年 ふりかえり

やってみたこと

個人やお仕事

2018年は何をやるのか(やらないのか)・チームを活かすにはどうするのかを考えた。

  • 4月から色つき星取表・一行日記・ニコニコカレンダーつけるようにした
  • ブログ8回更新
  • 社内にJJUG CCCのレポートを発表
  • Redmineでチケット駆動+カンバン
  • 1on1を始めた(部下2名)
  • AWSやAIについての社内ワーキンググループに参加

コミュニティ・カンファレンス

前半は結構参加してる。後半は控えめ。学びをお仕事に活かすことができている。

読書

17冊購入、3冊図書館、計20冊。読了したのは12冊。

2018年のベスト3冊はこれ。

www.shoeisha.co.jp

gihyo.jp

www.oreilly.co.jp

家族で

長男が小学校に入学し、長女もそれなりに大きくなったので行動範囲が増えた。

わかったこと

  • ふりかえりのふりかえりは重要
    • ふりかえるためには、記録・測定・データはすごく大事。
    • やったこと・発生したことだけでなく、やってみてどうなったとか感情とかあると良い。
    • ふりかえりのふりかえりができていない。
  • 慢性的にニコニコカレンダーが低い。
    • 睡眠不足。
    • 体調が悪いと怒りっぽく、イライラしている。
  • マネジメントのあり方・考え方が変わった。
    • マネジメントを技術・スキルとして認識し、チームやプロセスを設計する感覚を得た。
    • 視野・視点・視座が初めて広がった感覚を得た。
    • マネージャーという役割を意識するようになった。

次にすること

  • 心身ともに健康
    • 7時間睡眠確保
  • データ収集と見える化
    • 自分、家族、メンバー個人、チーム全体、プロダクト
    • できるだけ楽に収集して楽に見えるような仕組みを作る
  • チームが学びを最大にする活動
    • ふりかえりのふりかえり
    • 1on1
    • 自分がやってきたことのまとめ
  • 好奇心を持つ
    • やってみる
    • 首を突っ込んでみる

Developers Summit 2018 KANSAI に参加しました

今回は会社お休みして参加してきました。
同僚二人に遭遇するハプニングありましたが(ΦωΦ)
とても充実した1日になりました。

TD;DR

  • 今年のデブサミ2018関西では「未来をはじめる」というテーマ
  • 自分が取り組む/プロセス改善/アジャイルクラウド機械学習/に関連するセッションを聴講
  • 届けたい価値、解決したい問題に向かい合うことの重要さを再確認
  • それを実現するための方法や手段をエンジニア個人としても習得したいし、組織にも浸透させたい
  • (ブログにまとめるのにいつも1週間以上かかってるのなんとかせな。。。)

Mackerelの200週連続リリースの舞台裏とこれから

  • ユーザーにとって価値のある"機能"を毎週リリース
  • ミニマムな状態からスタートし、機能開発スピード自体が価値となる
  • OSS部分もあって、ユーザー(外部エンジニア)によるコントリビュートリリースもあった
    • 【感想】オープンでありとても素晴らしいと感じました。
  • 少人数なアジャイルチームでCI/CDをさらっと実現している(風に聞こえた)
  • 長期タスク/短期タスク/作りおきをうまくコントロールして連続リリースを実現
  • No マイクロマネジメント。自律したチームには余力が必要
    • 【感想】そんなチームを作り・維持できるマネジメントに興味があります。
  • チーム全員が同じミッション・価値を共有してコミットメントする
  • 結果として機能開発スピードの価値が相対的に低下したので連続リリース止めた

改善を重ねるリモートスクラム開発 〜kintone開発の現場から〜

  • スプリント期間を2Wから1Wに変更
    • 【感想】僕も全く同じ理由で1Wスプリントに変更したのでめっちゃ頷いてました。
  • スプリントプランニングで大枠の設計を実施
  • タスクの実施は全員でモブプログラミング
  • バックログリファインメント毎日30分全員で
    • 【感想】僕は週の半ばくらいにまとめて時間をとっていましたが、毎日少しずつというのも試してみたいです。
  • リモート改善について
    • 【感想】「リモート」でのスクラムをどう実現しているのだろうと期待していたため、1スライドに詰め込まれていて少し残念
    • 【感想】もう少し「リモート」観点で深掘りしたお話を聞いてみたかったです(ツールの選定とかなぜリモートやるのかとか)

今日から始める機械学習はてなの事例〜

  • 吉田 康久さん [はてな]
  • 3つのタイプ
  • 世間のイメージ VS お手軽機械学習
    • 【感想】勇気をもらえます。何事もミニマムスタートですね。
  • アプリケーションエンジニアのメリット
    • データをきちんと見る
    • いい特徴量のありかを知っている
    • 問題解決の手段として使える
  • 汎用ではなく固有・制約を活かす。全部機械学習で解決しようとしない
  • 大事なのはデータ量・特徴量。解決したい問題やドメインをしっかり捉えること
  • 困ったときは
    • Kaggle
    • Machine Learning Meetup KANSAI

意外と知らない?!GitHubの新機能を紹介します

  • 鈴木 順子さん [GitHub]
  • ビジネス向けGitHub
  • 【感想】Git/GitHubの基礎知識からちゃんと学ぼう(´・ω・`)
    • 【感想】Git/GitHubの何がどのようにメリット/デメリットになってどんなチーム・組織・プロセスにフィットするのか説明できたらなぁ

クラウドネイティブなアーキテクチャを設計する次世代の現場力

  • 北山 晋吾さん [レッドハット]
  • クラウドネイティブ=クラウドリソースを意識することなく活用できること
  • KubernetesクラウドのKernel
  • クラウドを活用するために意識を変える
  • クラウドネイティブな設計
    • 柔軟かつ効率的なシステム運用
      • マネージドサービス活用によりカスタム運用を減らす
    • 迅速かつリスクの少ないアプリデプロイ
      • 必ずしもマイクロサービス化が正義ではないがモノリシックは分割する
      • 【感想】マイグレーションについての基礎知識を見ることができて嬉しい
      • サービスメッシュ活用によりアクセスに応じたデプロイ実現
    • 信頼性を維持する運用体制
      • 組織とプロセスの意識改革

Javaを活用したマイクロサービスのためのKubernetes活用

  • 寺田 佳央さん [日本マイクロソフト]

  • 会社・開発者は二極化する

  • すべての企業はソフトウェアカンパニーにならなければならない
  • 「変化することのリスク」「変化しないことのリスク」
  • 技術の見極め・最適化が大切
    • とりあえずマイクロサービスだ!コンテナだ! はダメ絶対
  • サービスごとにリポジトリは作るべき
  • 並列処理をしっかり理解する
  • 障害は起きる
    • 1個のサービスを切り離して残りの99個を活かす
  • Release It! 本番用ソフトウェア製品の設計とデプロイのために オーム社
  • HelloWorldレベルは簡単

勝てる「開発プロセス」の作り方 ―そのプロジェクト計画、本当に成功を確信して書いていますか?

  • 岡 大勝さん [ゼンアーキテクツ ]

www.slideshare.net

  • 開発プロセス=プロジェクトの見通しを立てる
  • プロジェクトの三態
    1. 価値探索
    2. 試行錯誤
    3. 製品化
  • 実現性トライアングル
    1. チーム・環境
    2. テクノロジーアーキテクチャ
    3. スコープ
    4. 中心にコスト・スケジュール
  • トライアングルを使ってリスクを見る
    • 【感想】「物差しを当てる」という表現と感覚がすごく腹落ちしました
  • ウォーターフォールのメリット
    • 未経験者が習熟しやすい
    • 【感想】ちょっと疑問が残る。プロジェクト期間とかにもよるけど、習熟度合いが早いのはアジャイルかなと思う
    • 【感想】ウォーターフォールをすべての工程通して経験できれば深く習熟できると思う
  • アジャイルとは
    • 暗黙知の再評価
    • 暗黙知を活かすために必要なたったひとつのこと=「信頼」
  • Work Together

Agile Japan 2018に参加しました #agilejapan

www.agilejapan.org

会社の支援(参加費&交通費)を得て参加してきました。 去年の大阪サテライトに参加してアジャイルに触れて、実際に少しずつ始めてみて試行錯誤している状況で実践されている人のお話を聞いてみたいと思っての参加です。

基調講演がとても素晴らしかった!

片やモブプロのお話、片や経営に関するお話にもかかわらず共通した部分があると感じました。

基調講演1(モブプログラミングと”フロー”の力):Woody Zuill 氏

  • Woodyさんが出した3つの条件
    1. 邪魔するな
    2. 見積りしない
    3. 延期する権利
  • よく問われる「生産性あがるの?」問題
    • わからない!
    • 正しくない問いに対して頑張って答えても意味がない
    • 正しい問いを見つけることが重要
    • 「モブプログラミングは効果的なのか?」としてみる
    • 少し逆から考えて「バラバラに仕事する場合に効果的に働くにはどうしたらよいか?」と問う
    • 今回の内容は氏の体験を紹介しただけであり"あなた"に合うかどうかはわからない
  • モブプログラミングは仕事のフローに対して最適化されている
    • フローについて
      • 個人のフロー
      • チームのフロー
      • リーンフロー
    • フローを阻害するもの
  • 「大事なのはアートを作ることではなく、自然にアートを作れる素晴らしい状態にいること」

氏の講演については、及部さん(@TAKAKING22)のレポートがとても参考になります。 takaking22.com

基調講演2(JapanTaxiの挑戦):川鍋 一朗 氏/漆原 茂 氏

  • スマホの普及によって起きた変革
    • 黒船襲来(Uber
  • 日本交通の社長->JapanTaxiへフルコミット
    • エンジニアと目線/ゴールをあわせる
    • エンジニアがパフォーマンスを出せる環境を作る
    • ビジネス VS エンジニアになるのではなく両方大事。リスペクト重要
    • トップは言い続けなければならない
  • 相乗り実証実験
    • やってから謝るのは日本文化では難しい
    • 政・民・官のバランスをとって新しいルール・イノベーションを起こす
  • グローバルローミング
    • 全国タクシーを海外で利用可能に
  • 電子決済
  • コラボレ-ティブモビリティ
    • タクシーのUI/UX
    • ライドシェア
    • 移動データ
      • 位置情報
      • IoT
      • 画像解析
      • センサ
      • 自動運転

氏の講演については、木下さん(@fkino)の記事にとても共感しました。
Agile Japan 2018 川鍋氏の基調講演に思ふこと

Whyで思い出せた原点

今回のテーマである「Why Agile?」に向かい合うことができ、アジャイルに取り組んだ一年間のふりかえりになりました。

Why Agile?〜Whyからはじめるアジャイル〜:森 一樹 氏

  • 100人超のワークショップをタイムボックスを守りつつ完遂されているのが凄い
  • ゴールデンサークル(えんたくん)の距離感が絶妙
  • 同じような悩みをもつ人同士で話すことで勇気をもらえる
  • 共有によってフィードバック(緑の付箋)がたくさん貰えたのがとても嬉しい!
  • 最後に挙げたWhatは、「よくあるWhatだけど実現は難しいもの」だったので、少しずつ良くしていきたい!

開発プロセスだけ「アジャイル」で良いの?~アジャイル導入で変わった人・組織・世界~:株式会社アプレッソ(土岐 拓未 氏/野村 俊介 氏/伊藤 真仁 氏)

  • be Agile
    • 「あなたは、どう組織を変えましたか?」
    • 情報の共有ではなくプロセスを共有する
  • バーチャルチーム
    • チームが機能する可能性を上げるよう働く
    • SpotifyモデルのGuild
    • 機能横断型チーム
  • WoWゾーン
    • WhatとHowの中間(造語)
    • プロダクトオーナーは、What。スクラムマスターは、How。
    • What/How判断に時間がかかるとPO依存→POがボトルネックになる

単に知識を得るだけでは足りない! 組織で取り組む体系立った理想のアジャイル人材育成とは?:渡会 健 氏

チームワークとしてのアジャイル -強いチームの作り方-:倉貫 義人 氏/仲山 進也 氏/天野 祐介

今のチームについてどのような状態にいるのか改めて考えるきっかけになりました。フォーミング体質は抜けきらないですが、少しは変われていると思います。
仲山さんのジャイキリ本買いました!

f:id:msts0w0:20180727085138j:plain

  • Q:チームとは
    • 天:共通の目的を持ったメンバーの集合
    • 倉:気軽に雑談できること
    • 仲:グループからチームに変わる。ジグソーパズル。70点→赤点→120点。
      • チーム成長ステージ
        • フォーミング
        • ストーミング
        • ノーミング
        • トランスフォーミング

f:id:msts0w0:20180727085203j:plain

  • Q:チームメンバーで意見を言わない人がいたらどうすればよいですか?
    • 倉:言いやすい場かどうか。人数を絞る(最大4人まで)
    • 仲:フォーミングを進めるだけ。
  • Q:アジャイル導入。何から始める?
    • 天:コーチから学ぶ
    • 倉:バズワードから入らない。
      • 実践させて、効果を見せてから、実はとネタばらし
      • 新卒から育成。それが当たり前にする
    • 仲:誰か一人が指揮命令するのではなくみんなでやる。
  • Q:雑談を無駄だというメンバーに対して
    • 天:雑に雑談していないか?
    • 倉:報連相よりも雑相。何を無駄と感じているか。
      • きっかけとしての雑談はチームのパフォーマンスあげる
      • 評価をやめたら「できないこと」の共有が進んだ
    • 仲:フォーミング状態へ戻りやすい(メンバー増減、やることが変わったり)
      • フォーミングを進めるためにも雑談は必要
  • Q:アジャイルに変える必要性を聞いてくる上司
    • 倉:やり方が上手くいっているのであれば帰る必要はない
      • 上手くいっていないのであればありのままを伝える
      • それでだめなら転職
    • 天:上手くいく方法を探して結果としてアジャイル

まとめ

とても充実した1日でした。モダンアジァイルの原則の中に「人々を最高に輝かせる」とありますが、まさに誰もがやりたいこと・目的に向かってキラキラしていました。
僕にとってのWhy Agile?は「人々を最高に輝かせる」ためです。

  • 楽しく働きたい
  • 成長するチームを作りたい
  • 家族の笑顔を増やしたい
  • 越境に挑戦する
  • 仲間を見つける

Scrum Boot Camp OSAKA in June 2018 に参加しました

参加のきっかけ

2017年のAgileJapan大阪サテライトでアジャイルに触れて、今の業務でスクラムを取り入れて半年くらい経ちました。 スクラムガイドや本の知識だけで突き進んで来たので経験者の知見をきちんと学びたいと思い参加しました。

タイムテーブル

  1. オープニング
  2. スクラム概要(座学)
  3. スクラムイベント体験(ワークショップ)
  4. ふりかえり・問題解決
  5. ビアバッシュ

丸一日かけてスクラムを体験できます。ワークショップによる体験が中心のため、色々とメモを取っていたのですがネタバレすると体験による学びが減ってしまうので割愛します。

気づき・学び

  • タイムボックスを意識すること
  • メンバーとの認知共有の難しさ
  • 言うは易く行うは難し
  • スプリントレビューとふりかえりを混同しないこと
  • スクラムへの適性はスキルの高さよりも意欲の高さ
  • 講師陣の問題を解決する・学びを得ることへの意識の高さ・貪欲さ
  • おやつ大事
  • とにかく楽しい!
  • ストロング0はヤバイ

フィードバック

得た学びはすぐに業務へフィードバックしました。 チームが集中できる・コントロールできる・リズムができるようにスプリント期間を短くしたり、タスクの粒度を小さくしたり。 少しずつ良くなっているかなと思います。

スクラムガイドにも

スクラムの理論 スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

とあるように、ビッグバン的な改善はできないし、やろうとすると失敗するのだと思います。

講師の方々へ質問した時も当事者(私)のコンテキストをとても気にされていました。チームの状態を観て、何が課題か・何を解決するのかを明らかにしながら、少しずつ良くしていきたいと思います。

おわりに

それでも困った時、悩んだ時は相談したいです。

エラスティックリーダーシップ を読みました

リーダーシップやマネジメントについて悩んでいたときに良さそうだったので購入。 結構前に読了してたのにアウトプットできてなかったのでメモ。

本の感想

チームの状態に応じてリーダーシップのスタイルを変化させて対応する方法が具体的に書かれていてとても参考になりました。 リーダーシップもマネジメントもスキルで解決できることに気づかせてくれた本です。

SIerとして協力会社のメンバーとチームを組むため、プロジェクト初期の立ち上げにとても苦労していました。今はこの本を参考にチームの育て方・成長の仕方・メンバーとの接し方を実践しています。 特に印象に残っているのは「コミットメント言語」ですね。すぐにチームメンバーにも伝えました。

現実は非情である

実践していますが、なかなか自己組織化チームへの道は険しい。。。 サバイバルフェーズと学習フェーズを行ったり来たりという感じ。 メンバーとの1on1を定期的に行うことが必要と思っています。

購入したのは紙の本

Amazonで探したら電子書籍版がなかったのだけど、O'Reillyのサイトなら電子書籍版も購入できることを後から知りました。Kindleアプリでも見ることができるので参考まで。

本を読みながらとったメモ

殴り書きなのでまとまっては無いです。

スタイル

  • 挑戦させる/コーチ型
    • チームの問題はチームに解決させる
    • リーダーがボトルネックにならないこと
    • チームに意思決定の仕方を教える
    • 教訓を得られる限りチームが誤った決定を下すことも許容する
  • 指揮統制型
    • リーダーが道を示す
    • リーダーは決定者であり問題を解決する
  • ファシリテート型
    • アジャイル
    • 自己組織化チーム
    • チームが問題を解決すると信頼する

フェーズ

  • サバイバルフェーズ
    • チームに学習する時間が十分にない状態
    • ゆとり時間を作って抜け出す
  • 学習フェーズ
    • ゆとり時間があり、学習や検証を行っている状態
    • 問題を自己解決できるよう教え、挑戦させることで自己組織化チームへと育てる
  • 自己組織化フェーズ
    • リーダー不在でも問題ない状態
    • リーダーが自由に使える時間を持てる状態

バス因子

  • チームメンバーの何人がバスに轢かれたらプロジェクトもしくはチームが破綻するか?
  • バス因子とはバス係数として数えられるメンバーのこと
  • バス因子がリスク
    • 単一障害点
    • 物事の進行を減速させるボトルネック
    • 士気を低下、雇用の不安を誘発
    • チームの成長を阻害する
  • バス因子の除去・発生防止
    • ペア作業とコーチン
    • 教師として扱う
    • メンバーを安全地帯の外に連れ出す

サバイバルモード

  • ゆとり時間が十分に取れない状態
  • 永続化・常態化しやすい
  • サバイバルモードから抜け出す
    • ゆとり時間を作るためにコミットメントを取り消す努力をする
    • それこそがマネジメントでありリーダーの役割である
  • 指揮統制型リーダーシップ
    • 悪い決定を正す、チームの強みを発揮する、障害を取り除く
    • チームとより多くの時間を過ごす
    • チームの主導権を握る
    • 全てのタスクに優先順位をつける
    • デイリースタンドアップを始める
    • 割れ窓理論を理解する

学習モード

  • 学習の変化
    • 学習の進みが遅く安定高原→学習の谷→学習が大きく飛躍している峰
    • 谷は安全地帯の外へ踏み出した状態
  • コミットメント言語
    • 事実を述べ、"いつ"までに"なに"を実行する
    • 制御下にあるものにコミットする
  • チームを成長させるワード
    • それに関してあなたは何を行いますか?
    • デイリーミーティング
    • 1on1
    • 笑顔と礼儀を忘れない

自己組織化モード

  • クリアリングミーティング
    • 全員が知るべき重要な課題を伝える
    • 課題提起の機会を全員に与える
    • チームの自己組織化レベルを測る
    • チーム内の信頼を作り出す
    • 目的は未熟なチームを迎え、成熟に向かうのを助けること
  • 何を問い、何を行うか?
    • うまくいかなかったことは何か?
    • あなたはそれに関して何をするつもりですか?
    • よかったことは何か?
    • 締めの言葉(あなたがすること)
  • 権限の行使について
    • 物理的な振る舞いを見つけ、その振る舞いを変えたい時はどうしたら良いだろうか?
    • 人に対するつらいことをやるのがあなたの仕事(1on1)
  • 影響パターンを考える
    • 個人レベルの能力・モチベーション
    • 社会レベルの能力・モチベーション
    • 環境レベルの能力・モチベーション

管理職のマニフェスト

  • 管理者は、部下の自己組織化と自己管理スキルを長期的・全体的に成長させること
  • 部下が求めるものは変化するという事実を受け入れる
  • 部下に対するリーダーシップスタイルを変化させる
  • 部下とともに改善に挑戦する
    • ゆとり時間を作る
    • リスクを受け入れる
    • 適切な時に援護する
    • 部下が組織を横断してスキルを習得することを支援する
  • 部下を導くことが中核
    • 自分の時間の50%をコミュニケーションに当てる
    • ソフトウェアの問題を人の問題として扱い指導する
    • 対人スキルとコミュニケーション技術を学び、部下にも確認させる