AIエージェント MCPメモ

How to configure MCP servers using "npx" on Windows and Mac

Windowsでnpxを使ったMCPの設定にはまったのでメモ

Mac

"slack": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-slack"
  ],
  "env": {
    "SLACK_BOT_TOKEN": "{token}",
    "SLACK_TEAM_ID": "{team id}",
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

Windows

"slack": {
  "command": "cmd",
  "args": [
    "/c",
    "npx",
    "-y",
    "@modelcontextprotocol/server-slack"
  ],
  "env": {
    "SLACK_BOT_TOKEN": "{token}",
    "SLACK_TEAM_ID": "{team id}",
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

書評） アジャイルチームによる目標づくりガイドブック

アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ [ 小田中 育生 ]

アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ【電子書籍】[ 小田中 育生 ]

うちの会社でもいわゆる「MBO」式の目標設定と評価制度を運用しているが、まぁこれが義務的で面白くないわけで、でもなかなか時間使う業務なので、せっかくならもっと前向きに有用に取り組むヒントはないかと思い読んでみました。

対話、リズム、集中、アウトカム、などアジャイルのエッセンスが目標づくりとその運用に応用されるイメージが沸いたので、義務的じゃなく成長と成果に結びつく目標づくりのヒントになりました。

内容粒度については、目標づくりに役立つ幅広いプラクティスが簡潔に紹介されていて、例えば「インセプションデッキ」と言うプラクティスがてでくるが具体的な実践の仕方については触れられない。

なので、

• これまでいろんなアジャイル関連の本を読んできた人にとっては「あーあれをここで使うのか」と知識の応用のきっかけになる
• まだそんなに事前知識がない人にとっては「これ気になるから深掘りしてみよう」と、いろんなプラクティスへの入り口になる

という感じかなと受け取りました。

また、読み進めていくと人としてうまく行くための心や姿勢のあり方の話も多くて、目標設定の枠を超えて、人やチームや組織の中でうまく仕事をするヒントも得られました。

刺さったポイントサマリ

お互いをしろう

インセプションデッキ

• インセプションデッキはそれを作り上げていく過程にも大きな意味がある
• まずはチームの前提を揃えることにフォーカス
• 誰かが残念な思いをしてしまうかもしれない、ということに気を配り対話を避けてしまうと、チームの焦点がぼやけることに

ドラッカー風エクササイズ

• 互いの強みを知る

Disagree and Commit 

• チームとして最終的に決定した方針には全員でコミットする

ワーキングアグリーメント

• チームが仕事を進める上で守るべきルールや基準
• チームにとっての当たり前が新しいメンバーにとって当たり前じゃない可能性がある
• 定期的に見直す

わくわくする目標をつくろう

SMART

OKR

• 昨対比はなぜその目標を目指すのかを明確に
• 要求の不確実性、そのKRを達成したらOを達成するのか
• 技術の不確実性、そのKRを達成する方法は道筋が立っているか
• CFR、対話、フィードバック、承認
• OKRをツリーにすることに無理があるならツリーにこだわらない
• Google Re:WorkのOKRスコアカードがおすすめ
• 目標は絞る、どれも大事、はどれも大事じゃないように扱うのと同じ

チームのリズムをつくろう

• チャレンジングな目標を立て、達成しやすい小さな中間目標を設定する

開発サイクル中の成果

• 開発サイクルのゴールとしてクイックウィン、目標とのギャップを埋める小さな成果を明らかにする

• レビューは褒める会じゃなくて生み出した成果から学びを得る場

ふりかえり

• 新しいアクションを生むKPT
• Small starfish ある程度チームが成熟してきたら、新しいアクションよりも既存のアクションの更新を

マインド面での変化をもたらす

• Fun Done LearnのLearnが少ないのはチャレンジか足りてないのかもしれない

チームで余白を持つ

• 木こりのジレンマ
• 業務時間内の自己研鑽をしつこいくらいに奨励する、ためらいを持つ人は多い

チームのマインドを育てよう

• 責務とは行為にある。その結果にあらず。行動には全力を尽くすが、その行為の結果には執着しない
• とはいえ失敗は怖いので、小さく失敗する
• 失敗は、この方法はうまく行かないということの発見
• 経験→省察→概念化→実践 ＝ 結果→分析→仮説→アクション
• 成功体験と同じように失敗体験とその学びを共有する
• 意見が対立した時は認知の4点セットで掘り下げる
• 一見ネガティヴな行動の、その人の肯定的意図を捉えてその目線で話す、リフレーミングでポジティブに見方を変える、ただしわかった風に考えない
• 善意からの行動で情報対称性や主体性を毀損することがある（忙しいだろうからやっとこうとか）
• 心理的安全性が低い状況ではまず匿名でフィードバックを集める

目標の共同所有

• 全員で達成すれば良いいうマインドの醸成
• 個人の評価はピアフィードバックやこまめな擦り合わせなど対策

ウィンセッション

• どうしてうまくいかなかったのか、ではなくどうやったらもっと上手く行くか

戦略とは今やるべき3つの優先度リスト

• 迷った時に立ち返れる優先度リスト、なぜその順位なのか徹底的に考え抜く
• 曖昧な部分があれば、より良い目標を作る良い機会となる

助け合えるチームになろう

• 関係の質が低いまま成果にこだわるサイクルにはいると、成果の圧により対立や無関心といった歪みを産む
• 好き嫌い表でチームメンバーの得意不得意、興味関心、成長機会を知る
• 費用対効果の大きなアクションをほぼほぼやってしまった時にチームは停滞感を感じる。勇気を持って労力の大きなタスクに向き合うときかもしれない

チームの開発生産性を測ろう

• Four Keys とDevOps Capability とSPACE
• VSMは暗黙知や特定の人しか知らない情報を引き出すことも目的
• 測定、数値達成を目的化すると本来の目的が歪む
• OKRでOを達成した時に、結果としてどのような変化が生まれているか、という問いへの答えとしてKRを設定する
• 開発生産性の向上を独立した目標とするか、既存の目標に関連する成果指標とするか

チームの外と向き合おう

• 解空間内の探索、あらゆる可能性を検証する
• 解空間を狭める、Oに対する相対的な立ち位置を明らかにするメトリクスを定め、計測結果から注力ポイントを探る
• 最初は注力ポイントを探ることがKRとなり得る
• ビルドトラップ、顧客のニーズではなく、自分たちの都合を優先し不要な機能をリリースする行為
• スコープの調整では「why now」で今やることで得られるもの、今やらないとどういう問題があるのかを明らかにする

ゴールにたどり着いたその先に

• 自分たちが大切にしている要素をインセプションデッキやOKRから洗い出し評価し、次のアクションについて話す
• 結果から行動を変化させていくシングルループ学習、行動の背景にある前提やメンタルモデルまで変えていくダブルループ学習、インセプションデッキの更新はダブルループ学習を活用する良い機会

書評）リモートワーク・マネジメント

リモートワーク・マネジメント 距離と孤独を乗り越える強いチームづくり【電子書籍】[ セダール・ニーリー ]

リモートワーク・マネジメント [ セダール・ニーリー ]

感想

リモートワーク関係なく普通にいいマネジメントの本だった。

ポイントサマリ

ローンチ（リローンチ）・ミーティング

• チームの成果の60％はプリワーク（事前準備・チームの設計）、30％はローンチ・ミーティング、10%は日々の実際のチームワークによって決まる
• プリワーク
  • どういう形のチームにするか、果たすべき機能やメンバー構成や設計などを決めるチームの誕生前に行うもの
• ローンチ・ミーティング
  • チームとしてどのように業務を進めていけば最大限の成果を上げられるかを全員が理解し合意する
• リローンチ・ミーティング
  • 過去現在未来を点検し、状況変化に応じて方向付けや方向修正
• 見解の不一致は必要
  • どういう方法で目的地に到達するかの対立は構わないが、目的地の認識は合わせる必要がある
  • 目標・役割・リソース・規範の認識を一致させる
• チームメンバーは自分や他人がチーム内でどのようなポジションにあるかを正確に把握していない
  • どの業務やチームにどのくらいの時間を割くべきかの認識に違いがある
• コミュニケーション規範を設定する
  • リモートコミュニケーションのルール、チャットツールの使い方などについて全員がストレスを感じず孤独にならないように基本原則を定める
  • ざっくばらんな交流チャンスがない分、それを埋める規範が必要
  • 会議のアイディアはデジタルに書き出しておく、業務連絡のタイミングを決めておく、仕事と家庭の境界線の守り方、など

信頼関係

• 信頼とは相手の発言や行動や判断に従っても大丈夫そうだと安心でき進んで従おうと思えること
• リモートでは信頼関係構築の基盤となる毎日の自然発生的なインフォーマルな交流がない
• 認知的信頼と感情的信頼
  • 認知的信頼の基盤となるのは「この人ならあてにできる、頼れる」という確信、頭で判断する
  • 感情的信頼の基盤となるのはお互いに対する思いやりや気遣い、友情と似ている
  • リモート環境下では認知的信頼は早々にピークに、感情的信頼がピークに達するには時間がかかる
• 信頼関係を後押しする直接情報・反映情報
  • 直接情報、リモートにいる同寮の個性や生活ぶり、仕事の状況を知ることで相手の仕事を信頼しやすくなる
    • MTG冒頭や1on1での雑談などで情報を知る
  • 反映情報は相手の目に映る自分の姿への認識、同僚が自分を理解してくれていると思えれば相手を信頼しやすくなる
    • リモート環境でも相手を注意深く観察することで収集できる
    • メールやチャットのレスをいつくれるか、同意してくれることが多いか不満そうなことが多いかなど、規範が人によって違うことに気づければ、気づきを元に自分の行動を修正できる
• 感情的信頼
  • 確実な方法の一つが自己開示、コミュニケーションの中で自分の情報を小出しにする、プライベートな話を織り交ぜる（節度は守る）
• リモートワークにおける信頼構築
  • 完璧な信頼ではなく、まずは情報収集や業務遂行にとって必要十分な「適度な信頼」を確保する
  • まずは「必要十分なだけ」メンバーを信頼する。メンバーの能力の判断材料をチェックし限定付きで相手を信頼する。その一方で今後も信頼し続けられるか否かの判断材料を積み重ねていけばいい

生産性

• 監視ツールの導入は「お前を信用していない」というメッセージとなり、チームワーク成功の土台が崩れる
• チームパフォーマンスの3つの評価基準（ハックマン）
  • 結果
  • 個の成長
    • 自分はこのチームに所属することで充実しているか、成長を実現できているか、チームはそこを気にかけてくれていると実感できるか
    • 成果にダイレクトに影響しなくても、仕事満足度の上昇につながり、ひいてはチーム全体の生産性強化につながることが多い
  • チームの結束
    • チームワークのスキルを身に着ける必要がある
    • 人間的なつながりがその学習プロセスに欠かせない
• 自律性
  • 自分で自分をコントロールできる環境にあることが自律性であり、自分が信頼されている証拠であり、それが主体性を生み、個人の都合に合わせたスケジュール設定が可能になることで効率改善を促す
  • リーダーは監視をやめ、必要なツールやリソースを提供するにとどめ、各人の業務目標を達成する方法は本人が一番理解していると考える
• 仕事がしやすい環境
  • リモートで自律性が増し仕事と家庭のバランスがとりやすくなり幸福感が増す一方で、自宅環境次第では持続的作業に必要な集中力が欠け葛藤や不安を感じることがある
  • リーダーは仕事環境の最適化を目指してサポートする
• チームの結束
  • 結束は物理的距離は関係なく、他のメンバーとのやり取りの頻度と、メンバー間のやりとりから形成される人間関係の質の2つの要因できまる
  • オフィスビルに掲げてある社名やブランド名に変わるアイデンティティ、チーム目標を思い出させるシンボルを示すのはリーダーの役割

デジタルツールの活用、解決すべき課題

• テクノロジー疲れ
  • 連続したビデオ会議は疲れを引き起こす
    • 移行時間、後処理の時間を確保できない
  • ビデオ会議だけでなく多様なツールをTPOに合わせて選択する
  • リーダーはこのチームにどういうコミュニケーションカルチャーを形成したいかを決める
• 相互知識
  • 有効なコミュニケーションが成り立つ条件の一つが「共通の前提や理解の存在」
    • それが無いとリモートワークを阻害する
  • 例
    •  自分の背景情報を相手に伝えないことで理解されない
      • 別のPrjで忙しい状況、など
    • メールチェックの頻度の習慣を伝えないことで共有速度に差が出る
      • なかなか返信をくれない人だと思われたり
  • トラブル時に情報が少ないと、原因を人間関係や個人的問題に帰する傾向がある
  • 相互知識の上でデジタルツールを利用する
• 社会的存在感
  • リモートワークの課題の一つに対面の機会が無いこと
  • この問題を考えるときの一つの視点が「社会的視点」
  • 親密性：対人距離感
    • リアルタイムで相手の顔が見えるデジタルメディアのほうが親密性は高くなる
  • 即時性：心理的距離
    • メッセージの送り手が受け手との間に感じている心理的、感情的つながり
    • 言葉を通しても伝わるし、服装や表情などでも伝わる
    • これらをどの程度見たり感じたりできる課は利用するテクノロジーに左右される
  • 効率性
    • メッセージを伝えるうえでどのメディアが最も有効か
  • 非言語コミュニケーション
    • デジタルメディアがどの程度対面と同じようなディティールが伝えられるか
  • どういうデジタルツールを使うかは「何を伝えたいか」に加え「どの程度の社会的存在感を達成したいか」も含まれる
• リッチメディアとリーンメディア
  • リッチ＝伝達情報量が社会的存在感も含め多い、シンクロ
    • 対面＞ビデオ＞ソーシャルツール
    • 曖昧で多義的で不明瞭な状況ではこちらが効果的
  • リーン＝伝達情報量が少ない、非シンクロ
    • 文書＜メール＜チャット
    • 単純明快な状況ではこちらが効果的
  • 人間関係な良好なチームではリッチメディアからさほど恩恵をうけないこともあり、逆に多用することでテクノロジー疲れが起きる恐れも
  • 逆にまだ人間関係が構築できていないチームではリッチメディアでコミュニケーションするほうが明らかにチームワークが良くなる
  • 人間関係が悪化したチームでリッチメディアを使うとチーム環境がこれまで以上に悪化する
• 繰り返しコミュニケーション
  • チームメンバーを動かすために複数の種類で繰り返しコミュニケーションする
  • ラインの権限を持つマネージャの例
    • まずは非シンクロなコミュニケーションで「このままではまずい」と伝える（メールなど）
    • それでも部下の行動がすぐに変わらないとシンクロなコミュニケーションを通じて本当にまずい事態であることを伝える（チャット、ビデオ会議など）
    • ここで始めて温度感が伝わることも
  • ラインの権限を持たないプロジェクトマネージャーの例
    • 最初にシンクロなコミュニケーションで伝える
    • 後で非シンクロなコミュニケーションで補強する
    • 非シンクロメディアなら受け手が時間をかけてメッセージを処理・消化できる
• 文化の違い
  • 多様な文化を受け入れ、自分の信念や認識を押し付けない
    • 対面を重んじる文化ではリッチメディアが好まれる
    • まずは雑談から入る文化の人にはチャットのほうが適している
    • 欧米文化では悪い知らせはリアルタイムで伝えるものとされるが、グローバルチームではまずメールで知らせて受け手が非シンクロに情報を処理してからのほうが良いことが分かった
  • 業務にどういうメディアを使いたいかに関しては、必ずコミュニケーションの相手に意見を聞く
• ソーシャルツールの活用
  • 地理的距離がある中、相手が何をしているのかが見えることでつながっている実感が生まれる
    • 業務外コンテンツや雑談も適度に存在したほうがよい
  • ツールを導入するだけでは不足、ツールを利用することで社員に、組織全体にどういうメリットがあるのか、リーダーが方向性を示す必要がある
    • リーダーもツールに参加し規範を見せる
    • 公式発表限定の利用だと社員はしょせん管理職の情報周知手段でしかないと受け止める

書評） ソフトウェアアーキテクチャの基礎

ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ [ Mark Richards ] 価格：4,180円（税込、送料無料) (2024/2/12時点) 楽天で購入

アーキテクチャのパターンがカタログになってるので気になるとこだけ読めるような構成。

今回はサービスベースアーキテクチャのことを知りたかったのでそこだけ読んだ。概要レベルの解説なので詳細はまた別途調べる必要があるけど、大体どんなもんか知ることができた。

そのほかに、アーキテクトとしての働き方、心がけ、キャリア開発などにも触れられているのでアーキテクトを目指してる人の参考になりそう。

サービスベースアーキテクチャ

マイクロサービスアーキテクチャのハイブリッドで最も実用的なアーキテクチャと考えられている。

マイクロサービスよりも粒度の大きいドメインでシステムを分割、データベースは単一でもよい。なのでデータベースのトランザクションを利用できる。

ユーザーインターフェースやデータベースはドメインごとに分けてもいい。

データベースアクセスを共通化すると変更の影響が大きいのでデータベースを論理的に分けて、アクセスライブラリも分割することも考える。共通テーブルアクセスはバージョン管理システムでロック。

ユーザーインターフェースやデータベースは、顧客向けと社内向けなどで分けることでセキュリティの強化も。

データベース共有やコード共有のためにサービス間通信をしないことで耐障害性とアプリケーション全体の可用性が高まる。サービス間のネットワークトラフィックも減り、分散トランザクションが減り、使用する帯域幅が減り、コスト効率と信頼性が高まる。

書評）スクラムの拡張による組織づくり

スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する [ 粕谷 大輔 ] 価格：2,860円（税込、送料無料) (2024/2/4時点) 楽天で購入

複数のスクラムチームがいるような規模の組織がうまく仕事をしていくためのフレームワークであるScrum@Scaleについてとてもわかりやすく簡潔に説明してくれた本。

今の組織に近い感じなのでこれを参考にいろいろ整理できそう。

サマリー

一つのサービスや事業の中でスクラムチームが複数、プロダクトオーナーもプロダクトバックログも複数あるような規模組織だとフィットしていて実践しやすそうなフレームワーク。LeSSのように1人のプロダクトオーナーによる一つのプロダクトバックログを複数のスクラムチームが、ではなく「分割統治」の考えを持っている。

各チームは普通にスクラムを実践、ただチームが複数にスケールして複雑化する相互のコミュニケーションにルールを設けるなど、チーム間連携の仕組みをもうけたもの。

開発者たちの活動をスクラムマスターサイクル、プロダクトオーナーたちの活動をプロダクトオーナーサイクルとして2軸で整理し、プロダクトインクリメントを作っていくための12のコンポーネントを定義。

複数のスクラムチームをまとめたSoS、複数のSoSをまとめたSoSoS、とフラクタルにスケール。（フラクタル構造といいつつ、単に階層ツリー構造でも理解できる）

SoSは共通の関心事同士でつくるので例えば新規フィーチャー、エピック、プロジェクト、サービスドメイン、モジュールなどで柔軟に括れそう。これによって密なコミュニケーションが必要な単位で括られる。逆に不要なコミュニケーション（あのチームのやってることうち関係ないな、、、と思いながら参加する会議など）を減らすのと、一度に同期を取るチームの数を小さく保つ。

状況によって人の異動ではなく、このSoSのチームの組み合わせを変えることで対応する。

スクラムマスターサイクル

EAT(Executive Action Team)を中心とした開発者のサイクル。

スクラムチームは、

• DS (Daily Scrum)
• SDS (Scaled Daily Scrum)
• EAT (Executive Action Team)

で45分で毎日課題を解決。

スプリント

各チームのサイクルを合わせる。SoSを形成するチームのタイムボックスがバラバラだとコラボレーションが難しくなる。

EAT

チームでは解決できない問題を最終的に解決する。人やチームの配置、予算、外部要因など。その権限を持つ人が参加する。

EATもこの役割を果たすためのクロスファンクショナルなスクラムチームで人の配置などの裁量を持つ人で構成。

プロダクトオーナーサイクル

EMS (Executive MetaScrum) を中心としたプロダクトオーナーたちのサイクル。

プロダクトオーナーは、

• メタスクラムで次に取り組むPBIを決め、EMSで最終意思決定、決まったPBIを各チームのPBIにブレイクダウン
• 複数のチームを跨いだPBIはその単位のSoSでスケールしたスプリントレビューで統合したインクリメントをレビュー

メタスクラム

プロダクトオーナーたちのチーム。

配下のプロダクトを横断するプロダクトバックログを持ち、このPBをチーフプロダクトオーナーを中心に管理する。

EMS

自律した複数のスクラムチームが同じ方向を向いて仕事ができるように組織全体の戦略的ビジョンを策定し浸透させる。どのような価値を実現するかにおいての最終的な意思決定をする。

EMSもこの役割を果たすためのクロスファンクショナルなスクラムチーム。

スケールされたイベント

Scaled レトロスペクティブ

SoS各チームのスクラムマスターが参加しチームプロセスの障害を取り扱う。

Scaled スプリントプランニング

SoSのインクリメントの統合が必要な場合はプランニングも合同で。

Scaled スプリントレビュー

SoSのインクリメントの統合が必要な場合のレビュー。

12のコンポーネント

EATとEMSは上述。基本的には通常のスクラムと同じ。

共通

チームプロセス

最初に取り組むコンポーネント。スクラムガイドが規定しているスクラムを行う。スクラムチームが未熟なままでスケールしてしまうと組織全体が未成熟なまま大きくなってしまう。

守破離の破として、十分に成熟したチームどうしの組み合わせであれば、必ずしもスクラムに縛られる必要はない。

プロダクトリリースとフィードバック

リリースで得られたユーザー、市場、ステークホルダーからのフィードバックはプロダクトオーナーサイクルが解釈。ソフトウェアの稼働状況、負荷状況、リリース作業などへのフィードバックはスクラムマスターサイクルで解釈。

メトリクスと透明性

特別なことは無し。Four Keys、SLI/SLO、ビジネスKPIなど。

スクラムマスターサイクル

継続的改善と障害の除去

スクラムの基本と同じ。SoSやEATがImpediment Listを作ることもある。

チーム横断の調整

SoSを形成するチームのタイムボックスを合わせ、DS、SDSのタイミングを合わせてコラボレーションしやすくする。

関心事が近い・同じチームをSoSで組み合わせ、チーム間の依存関係を緩和しSoSをまたいだコミュニケーションやボトルネックを排除する。

デリバリ

チームが単独でリリースできることもあれば、複数のチームのインクリメントを統合してリリースすることもある。組織全体で一貫したデリバリのプロセスを保つために、デリバリの責任はSoSが持つ。

プロダクトオーナーサイクル

戦略的ビジョン

複数の自律したチームが、組織が何を目指し、どういう価値を提供するのか。各チームはこのビジョンを共有する独自のプロダクトゴールを定めてプロダクトバックログを管理する。

バックログの優先順位付け

メタスクラムなどで調整を密に行い、組織全体で一貫した順番に。

バックログの分割とリファインメント

メタスクラムが作るプロダクトバックログを、各チーム単位にブレークダウンする。

リリースプランニング

複数チームで依存する場合はリリースまでの長期的な計画が必要になることも。その場合はメタスクラムとしてリリースプランニング。

導入ステップ

機能しているスクラムチームを作る

機能しているとは？ 

www.ryuzee.com

SoSを立ち上げる

まずは１つのSoSから。

機能しているスクラムチームを分割することも。

参考）

www.heidihelfand.com

人がチームを横断しないように。コードベースの依存関係をなくすことも考える。

立ち上げたらSDS、Scaled retrospectiveなどのイベントを開始。

EATを立ち上げExecutiveメンバーを巻き込む。

メタスクラムを立ち上げる

チーフプロダクトオーナーを選出し、メタスクラムとしてのイベントを開始する。

EMSを立ち上げExecutiveメンバーを巻き込む。

改善サイクルを回す

各スクラムチームが独自に改善していくサイクルと、Scrum＠Scaleとして組織全体としての改善との２重構造。

12のコンポーネントそれぞれに対して自己採点し、優先順位をつけ、点数が低く優先順位の高い問題から取り組んでいく。これを変革バックログとしEATが取り組む。

既に組織が大きい場合

EATを一番最初に導入するパターン。パイロットチームと従来の組織を並行で運用する。

書評）大規模スクラム

大規模スクラム 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章　謙虚に問いかける態度を育てる

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