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

Tech

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

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

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

 

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

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

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

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

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

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

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

 

 

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

Management Agile

 

複数のスクラムチームがいるような規模の組織がうまく仕事をしていくためのフレームワークである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を一番最初に導入するパターン。パイロットチームと従来の組織を並行で運用する。

 

書評）大規模スクラム

Agile

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

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

感想

スクラムの本にマネージャーが役割として登場することはないけど、LeSSにおけるマネージャーの役割は組織がプロダクトを開発するにあたっての価値提供能力を向上させるための改善だと明確に言及があるのが良かったです。
マネージャーは組織が改善していることを保証することに注力する、チームが改善するにあたってチームだけではできないことを支援する、例えば規制やポリシーの変更など。Doneの定義をどうやったら拡張できて、チームが自己管理の元にデリバリー能力を向上させることができるかを考える役割だ、などなど。
また人気のマネジメントの本を読むだけで満足せず、現地現物に触れ続け、学習を継続し、今の現実の問題を見つけてそれを組織力の向上に活かすこと、という示唆はちょっとドキッとしました。
 
全体としてはLeSS(Huge)におけるスクラムマスター、プロダクトオーナー、プロダクトバックログなど項目ごとに解説されていて、わからないところを読み返すことができるような感じで実際導入する場合の手引きになるような内容でした。
 

ポイントサマリ

 
顧客価値による組織化
  • コンポーネントチームからフィーチャーチームへの移行を目指すf:id:takacyk:20210815151821j:plain
  • 機能別組織はない

    • f:id:takacyk:20210816161958p:plain

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

    • f:id:takacyk:20210816162016p:plain

    • 各要求エリアの優先順位に基づきチームの移動が発生する
    • 優先順位が下がって小さくなった要求エリアは統合する
      • 小さな要求エリアが増えることで優先順位付けが複雑化したり、サイロ化したりする
 
 
LeSSでなマネジメント
  • マネージャーの役割は日々の作業の管理からプロダクト開発の仕組みの改善促進に変わる
  • 組織の問題はフィーチャーチームを当事者として向き合わせる
  • 組織が改善していることを保証することに注力する
  • チームが改善しようとしていることに対し、チームだけでは手の届かない規制や組織のポリシーの変更などを支援する
  • 現地現物
    • チームとユーザーの現場に習慣的に訪問し、実際の問題を理解して、それを組織力の向上に活かす
    • 現地で介入するとマイクロマネジメントになってしまう
    • チームが解決できない場合には方法を教えて促進しチームの問題解決能力を向上する
    • 現場から得たフィードバックをもとに優れた組織の意思決定をする
    • マネージャーは人気のマネジメントの本を読むだけではなく、最新のドメインと技術に触れ続け、今日の現実に触れ続ける
 
LeSSのスクラムマスター
  • LeSSがうまく機能していることに責任を持つ
  • システム思考とプロダクト全体思考を組織が持てるように支援する
  • 対象領域はチーム、PO、組織、開発のプラクティスでスクラムマスター専任
 
LeSSのプロダクト
  • チームが扱うプロダクトの定義を狭く細かく区切ると、サイロ化し、機能の重複が起き、互いに依存関係が生まれ、顧客の課題を解決する提案が狭い範囲でしか考えられなくなる
  • プロダクトの定義はプロダクトのビジョン、対象とする顧客や市場、ドメインの共通性によって広げるか狭めるかを考える
  • 理想はE2Eで顧客に価値を届ける範囲でプロダクトを定義することだが、現実的には組織の制約などで制限される。まずはそこから始めて将来底には理想を目指す

書評）問いかける技術

Management

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

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

 

感想

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

 
複雑化する社会で1人のリーダーが成し遂げられることは限られるので、人が相互に依存することを認めて相手を尊重し良好な関係性を構築しましょう、そのためには立場を示すために自分が話し手にならねばという古い習慣を捨てて、自分の知りたい情報を相手が持っているかもしれないと示唆する「謙虚に問いかける」という技術が重要である、みたいな内容でした。
ここでの「1人のリーダーが〜」という話はサーバントリーダーシップとも共通でした。
 
相互の依存は横だけでなく上司と部下にもあって、でも部下から進言することにおいて壁がありがちなので、それを壊すのは上司の役割という話は納得感があります。
 
人は観察、反応、判断、介入というサイクルで動くが、それぞれにバイアスや感情による短絡的な判断がつきもの。そこで立ち止まって「謙虚に問いかける」ことで自分の対応の妥当性を自問することで間違った方向へ進むリスクを最小化できるそうです。
 
傾聴が大事、というトピックをより深く掘り下げてくれた本でした。
 
 

ポイントサマリ

第1章　謙虚に問いかける

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

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

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

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

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

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

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

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

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

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

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

書評）More Effective Agile

Management

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

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. アクションプラン
  • 導入にもキャズム理論が当てはまる
    • 最初の導入はイノベーター、アーリーアダプターのような人が良い
    • 組織の人々の大多数は後期のアダプターでありより多くの支援を必要とする

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

Management
 
感想
冬の課題図書として。
自分の組織マネジメントで、今日より明日の方が仕事が上手くなるチーム、失敗から学んで上手くなるチーム、未来のために自己学習を続けるチーム、辺りがなんとなく大事なんだろーなー、と思い、なんとなくそこにつながってそうな「学習する組織」に前から興味があったんですが、分厚い本が苦手なのでマンガでわかるシリーズを読んでみました。
 
学習する組織とは「誰かに言われて動くのでは無く、自分で考えて動く社員のいる組織」ということでした。
 
学習するために問題やテーマを大局、全体像から根本にアプローチして本質について考え観察する手法としてのシステム思考については、
対象を、
  • 目に見えるできごと
  • そこに繰り返し現れるパターン
  • それを引き起こす構造
  • 根っこにあるメンタルモデル
のそれぞれのレベルで観察する話が具体例で解説されてて勉強になったり、
 
解釈、認知のフィルターとなるメンタルモデル、その認知の働きを「推論のはしご」として人それぞれなぜ違う捉え方をするのかの解説も勉強になったし、
 
個人のビジョンと共有ビジョンを作る話も参考になったり、
 
と、色々学びの多い本でした。
マンガはシンプルでそんな上手くいかないでしょ的なものですが、それによって理論がイメージに落ちやすくて全般わかりやすいものになってました。
 
と、やはりこの手の話はサーバントリーダーシップや7つの習慣辺りと通じるんだなぁと感じます。
チームや組織を持つリーダーにお勧めできる本でした。
 
 
ポイントサマリ
 
なぜ、人と組織は変われないのか
  • 人は変えられることに抵抗する
  • 自ら状況を理解し、その選択肢を明確にした上で、どのような行動を選択するかを決めるプロセスに関わった人たちは、変化に抵抗するのでは無く、建設的に進めようとする傾向がある
 
学習する組織とは
  • 誰かに言われて動くのでは無く、自分で考えて動く社員のいる組織
  • やる気の温度差、上から目線は組織の学習を阻害する
 
システム思考
  • 問題が単純明確な場合はそこへ対処する
    • 論理的思考
  • 問題が複雑な場合は対象の大局、全体像、根本にアプローチして本質について考える
    • システム思考
  • システムとは相互に作用し合う要素の集合体
    • 人間関係、家族、社会、市場、業界など
  • 氷山モデル
    • 繰り返し起こるパターンや大きな流れが観察される時、なんらかの構造がそれを作り出している
    • 表面: できごとのレベル
    • 1層: パターンのレベル
    • 2層: 構造のレベル
    • 3層: メンタルモデルのレベル
    • 課題への対応策を浅く安直に感じるのはできごとへの対応になっている可能性がある
  • パターンを把握するための3つの相互作用基本構成単位
    • 自己強化型ループ
    • バランス型ループ
    • 遅れ
    • これらの組み合わせとしてよくある型がシステム原型
    • 課題に向き合う際にこれらの型に当てはまってないか分析し、課題を見える化、構造化して本質的な解決策を見出す
    • システム原型の目的は視点のレベルをできごとからパターン、構造、メンタルモデルへ引き下げること
 
共創的コミュニケーション
  • 解釈、認知のフィルターとなるメンタルモデル、その認知の働きをわかりやすく解釈するための「推論のはしご」
  • メンタルモデルへの対処
    • オープンマインドで真摯に相手に問いかけ、探究の質を高める
    • 自分の主張や結論を仮説として呈示して、主張の質を高める
      • 仮説に至った背景も伝え仮説の検証も厭わない発言をする
    • 自分の思うメンタルモデルと行動に現れるメンタルモデルは違い、自分では気づきにくいため他人の意見を聞くことも必要（1on1など）
  • 個人個人がメンタルモデルを理解することが共創的コミュニケーションのベースになる
  • チーム学習のレベルアップ
    • メンタルモデルを一旦脇に置いて現実を観察、傾聴する。自分の意見は仮説として呈示し、推論のはしごに沿ってその根拠を伝える
    • 相手の立場に視座を転換する。相手の立場を知り共感するからと言って同調する必要はない
    • 自分の中で大切にしてきたビジョン、目標、信念、規範のいずれかを手放し、全体の視座に転換することでより大事なものを手に入れる、または保全する
 
自己マスタリー
  • 自己マスタリーとは、自分の仕事を自分ごとと捉えて、目指す姿を明確にして自己を磨き続けること
  • 自分自身のビジョン（何を成し遂げたいか）は自分事になってないとと覚悟を疑われる内容になる
  • ビジョンと現実のGAPを埋めるために創造的緊張が生まれる
    • 逆は感情的緊張、外部からのプレッシャーにより創造性を損ない不正に走るなど手段と目的を取り違えたりする
  • 人は自らが学びたいことこそ、自発的に、かつ効率的に学ぶ
 
共有ビジョン
  • ミッション、組織がなぜ存在するのか
  • ビジョン、組織が何を作り出すのか
  • バリュー、組織がどのような基本理念や規範を大切にするのか
  • 私のビジョンが私たちのビジョンとなるよう、個人のものが反映され、共有するもの同士が互いに誓約する
  • 共有ビジョンの普及では、プレゼンだけで無く組織の日々の意思決定や行動に織り込んでいく。また社員に選択の自由を与える
 
学習する組織の実践プロセスと戦略の構造
  • テーマとチームメンバーの設定
    • テーマは組織や企業課題から、または話し合って
    • チームの「学習する組織」に関する教育と関係性構築
  • システムの観察と多様な関係者による対話
    • システム思考、氷山モデルからの観察と対話
  • 共有ビジョンと個人ビジョンの融合
  • 実験と学習
  • システム的な変化の展開
    • ハードとソフト両面での横展開
    • 普及のためのコミュニケーションと学習プランも
 
変革を導くリーダーシップ
  • 現場リーダー、実践と検証
  • ネットワークリーダー、部署間など支援協業関係性構築の媒介役
  • 役員リーダー、組織環境を整え反対勢力に対する守護神
    • 現場リーダー、ネットワークリーダーのコーチング
 
深い学習サイクルと戦略の構造
  • 学習を後押しする経営理念の設定
    • 役員リーダーの役割
  • 学習のための理論、ツール、手法の習得
    • 現場リーダーが身につけメンバーへ
  • 学習インフラにおけるイノベーション
    • 研修、指導、ITシステム、評価の仕組みなど
    • 役員リーダーの庇護のもとでのネットワークリーダーの役割

書評）英語の品格 実践編

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

[音声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とともに自然な英語を学ぶことができました。


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


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