ugo's 読書感想文

読んだ本のまとめや学んだことを書いていきます。

Lean UX

Lean UXとは

「リーン、スタートアップ」以外にも「デザイン思考」と「アジャイル開発」の概念を基盤としている。

かつては、物理的なものを作るため、細部のデザインを決め切ってからでないと、瑕疵があった場合の損失が莫大になってしまっていた。

しかし、昨今ソフトウェアに、継続的デリバリーという概念が導入され、製造上の制約を受けなくなってきた。

例えば、Amazonの運営するEコマースサイトでは、毎秒何らかのコードが追加されデプロイされているという。

マーケットからのフィードバックを得て、学習したことに基づき、イテレーションを繰り返す。ユーザーとの継続的な対話となる。

これにより、ユーザーのニーズを満たしているか、期待値を上げていけてるかという結果を生み出していくことをLean UXで行う。

しかし、デザイナーがアクセシビリティから、ページロードの時間、美しいインターフェース、ワークフローを作って渡していくのでは、コミュニケーションのコストが増えてしまい、より目を向けなくてはならないようなプロダクトの戦略的決定に影響を与える情報収集に時間が割けなくなる。そこで、チームメイト同士の共通理解が重要になる。

Lean UXを取り入れることで得られる3つの効果

  1. UXデザインのプロセスから無駄を取り除くのに役に立つ
    1. デザイン、開発、プロダクト/サービス間の対話を進めるために必要な作業(デザイン、リサーチ、ライティング)のみを行う
    2. 対話を最小限にすることで、長時間の交渉から解放される
    3. それらのための、チームの学習を促進する
  2. 部門横断のコラボレーションを促す
    1. プロダクトマネージャー、QAエンジニア、マーケティング担当者などを部門横断で透明性のあるコラボレーションを促す
    2. デザイナー以外の人も、デザインプロセスに関与する。
    3. デザイナーが何をすべきかを明確にして、チーム全員の参加を促す透明性の高いプロセス。
  3. 実験と検証に基づく学習をすることでマインドセットを変える
    1. 特定の人物に頼って1つの視点から最適なソリューションを導き出そうとするのではない。
    2. 迅速な実験と測定によって、自分たちの作る体験に客観的な視点でとらえられるようになること。
    3. そんとあめ、デザイナーの役割は、単に中間生成物を作るだけではなく、デザインのファシリテーターへと進化し、他のメンバーも新たな責任を担うことになる。

受け入れるのが難しいもの

「未完成」や「醜い」状態の中間生成物を人に見せなければならないこと。

最初の設計に時間や労力を多く費やすほど、その後の柔軟な修正は難しくなる。

大切なのは、コードのデプロイではなく、顧客に与えるポジティブなインパクトである。

そのためには、学習とイテレーションの継続が大事になる。

Lean UXの基盤

元々

などの多くのデザインを包含している。

しかし、その中心には、人間のニーズがあり、人間のニーズを特定するところから始まる。

人間を直接的に観察することを原動力とするイノベーション手法であり、人々が生活の中で何を必要として、特定のプロダクトやパッケージ、サポートなどの方法を好んでいるのかを観察すること。

その考え方には、ビジネスのあらゆる側面は、デザイン手法でアプローチできるというデザイン思考により、明確な立場をとっている。

そして、アジャイル開発のコアバリューと以下の面で完全に調和している。

  1. プロセスやツールよりも個人との対話を
  2. 包括的なドキュメントよりも動くソフトウェアを
  3. 契約交渉よりも顧客との協調を
  4. 計画に従うことよりも、変化への対応を

Lean UXの原則

自身とチームを正しい方向に導くための原則

  • チームビルディング
  • チームや組織文化の指針
  • プロセスの指針

チームビルディング

  • 部門横断的
    • ソフトウェア・エンジニアリング・コンテンツデザイン・マーケティング・QAから構成される
    • 各部門は、プロジェクトの初日からエンゲージメントの終了まで、継続的に関与しなければならない
    • これにより、多様な視点で問題解決をしやすくなる。
    • そして、(ウォーターフォール式の)情報伝達プロセスが不要になる
  • 小規模、専念、同一環境で作業する
    • 10人以下のチーム
    • チームは一つのプロジェクトに専念し、同じ場所で作業をする
    • リモートワークだと何かを逃してしまうという考えによる
  • 自己充足的で、権限を持つ
    • チームが外部依存なしでプロジェクトを進められるようにする
    • チームに対して以下のような権限を与える
      • 直面する問題の解決方法を決定する
      • ユーザーや顧客と直接関われる
    • これによりチームが直接、マーケットから学ぶことができる
  • 課題焦点型
    • 機能の実装ではなく、ユーザー課題の解決を目標にする
  • 共通理解
    • チームが一緒に働きながら時間をかけて築いていく集団的な知識

プロセスの指針

  • これまでと同じことを速くやるのではなく、仕事の進め方を見直す
    • アジャイルの目的は、速くすることではない
    • スプリントで仕事をすることでも、すべてのルールに従うことでもない。
    • アジャイルの目的は、ソフトウェアというメディアに適した方法で作業することであり、それにより、より多くの価値を提供する、より良いプロダクトやサービスをつくることである。
      • 適用できない場合も出てくるが、強引にアジャイル手法を実践するのではなく、仕事おの進め方を見直すべき。
  • プロダクト開発のフェーズに注意する
    • 調査フェーズ、デザインフェーズ、開発フェーズ、テストフェーズなど
    • そのような「フェーズ」と名がつくときは、何かが間違っているという警告サイン
    • アジャイルの中で、これらのフェーズをすべて断続的に行うべきなため
    • フェーズでは、プロセスステップが完了するだけで、生成物を完成させるには、フェーズで区切るのではなく、断続的に仕事を進める方法に移行する必要がある。
  • 外に出る
    • かなり早い段階で見込みユーザーからのフィードバックをもらう
    • ユーザーの行動と要望、その理由を理解する
    • プロダクトの成否を最終的に決めるのは、チームではない。
    • あなたがデザインした「購入」ボタンをクリックするのはユーザー

過去と現在のプロダクト開発フローの違い

昨今では、完成品が見えた上でプロダクトを作ることはない。

つまり、何を構築しなけっればならないかが正確に分かっていることが前提となる開発はほとんどありえない。

マーケットの変化に対する機敏な対応が求められるためだ。

しかし、現在でも要件を固めた厳密さというのは、「以前はうまくいったから」という根拠のない自信によって横行されてしまい、

要件の完全性に疑問を持つ個人やチームはトラブルメーカーとみなされてしまい、プログジェクトの納期が遅れたりスコープを超える作業が発生した時の責任が押し付けられてしまう。

ユーザーは裏切る

現在、我々は

  • 一貫性
  • 予測可能性
  • 安定性
  • 確実性

が低い現実にいる。

そのため、消費者行動の変化に対応した新たなメンタルモデルを構築していく必要がある。

例えば、Amazonでは、毎秒1回リリースが行われるというようなユーザー体験をより良いものにする機会を得ている。

その中でも消費者は、自分たちが直感的で使いやすいと思って作ったUXの期待した行動とは異なる行動で我々を裏切ってくる。

そういった結果が出た時こそ、自分たちの要件が間違っていたと証明するものになる。

どうすれば良いか?

まず我々は、要件を「権威をもって表現された単なる思い込み」であると認識すべき。

そのため、「人間の行動は予測できるものではない、そのため我々が取り組んでいるものは高リスクなことである」ということを理解する必要が出てくる。

そこで、これまではLean UX キャンバス といったものを取り入れることで、自分たちのアイディアを「検証可能な思い込み」として新たな方法で表現していた。

キャンバスの使い方

どんな時に使う?

キックオフミーティングに最適な枠組みを提供してくれる。

キャンバスには以下のメリットがある。

  • 一連のストーリーを推進するようにデザインされた連続的なプロセスに統合
  • 複雑な要素を一つの視覚的モデルにできる
  • ファシリテーションツールとして簡単に利用できる
  • ブレーンストーミングではアイディアを出すことに躊躇しがちなメンバーに、意見を提出しやすい公平な場を提供する
  • 共通言語の構築
  • チームの仕事の枠組み
  • チームの枠を超えて広く伝えられる

これらは、それなりの大規模なプロジェクトの計画を立てる際に、使用することでプロジェクトの大きさへの感覚が研ぎ澄まされていく。

主に次のようなものに直面している時に効果を発揮する。

  • 未知のもの
  • 不確実なもの
  • 複雑なもの

流れ

  • 基本的にキャンバスの作成には、2日間や1週間かかることもある
  • 参加者はチーム全員
  • 全員の参加を促すための仕組み
    • まず、参加者が一人、短めの時間(5分程度)を決めて直感的に浮かんだアイディアを記載したり図式化する
    • 一人での作業が終わったら、テーブルや小グループでアイディアを共有
    • 2人1組とかになり、アイディアを練る
      • ペアワークは時間がかかるので1人の時より少し時間を多めに取る
    • その後、発表をしてもらい、その時にディスカッションをしても良い
    • 次に、各テーブルや、サブグループのアイディアを1つのプレゼンテーションにまとめる
    • 最後に、最終的にアイディアを1つにするなら、グループ全体でアイディアを絞り、練り上げる

ボックス1: ビジネスプロブレム

ビジネスの抱える問題は何か?

ソリューションではなく、課題を認識した上で表現することが大事になる。

それがビジネスプロブレム・ステートメントになる。

具体的には以下の条件が満たされるべき

  • 機能ではなく、解決すべき具体的な課題の提示
  • 顧客中心の視点で、顧客のシエ高が最終目標となる
  • スコープの対象となるもの、対象外のものを明確にするガイドラインと制約の明記
  • KPI、ターゲットオーディエンスに求める具体的な成果として表現される明確な成功の基準の明記
  • ソリューションを定義しない

そして、ステートメントは以下の3つの内容により構成される

  • プロダクトの現在の目標
    • なぜこのプロダクトが作られたのか
    • どんな課題を解決することが目的だったのか
    • どんな価値提供が意図されていたのか
  • プロダクトによって何が変化したか?
    • 達成された目標と、未達の目標
  • プロダクトの改善要求
    • 改善を成果として定量化するもの

エクササイズのプロセス

プロダクトマネージャーによる、チームにコンテキストや背景情報の提供がある。

具体的には以下のようなことの質問に答える。

  • 問題があると至った観察・測定結果は?
  • 誰をターゲットにした機能か?
  • この機能の前者的な事業の中での位置付けは?
  • この問題の解決で、全社の経営にどのような影響があるか?

これらに基づいて、ペアやトリオに分かれてステートメントのドラフトを作成する。

気を付けるべきこと

ソリューションを含めないこと

「〜を解決するためのモバイルアプリはどのように実装すれば良いだろうか?」

といったソリューションにしてはいけない

具体的であるべき

例えば、以下のような文が含まれているステートメントがあった

「ショッピング体験の向上を目指し、平均注文額を上げるために直感的なUIを実装した」

しかし、これでは何が実装されたのか漠然としているので、チームはUIのどの部分を改善対象にすればいいか分からなかった。

そもそも、直感的なUIは、あえて言うものでもなく、誰もが目指すものであるので、記述に対する意味はない。

ボックス2 ビジネスの成果

ユーザーの行動に焦点を充てる。

カスタマージャーニー

チームが注目すべき、価値ある顧客行動を見つけることが目的である。

現在の顧客がどういった行動をしているかを見るところから始める。

「海賊指標(AARRR)」「メトリクスマウンテン」のようなテンプレートも使える。

ボックス3: ユーザー

デザインにおけるペルソナは重要。

しかし、かけた労力に伴い、絶対的なものとして捉えてしまう傾向がある。

また、外部のリサーチチームやベンダーがペルソナを作成することがあるが、利用側と知識のギャップが生じやすい。

開発チームのジレンマ

開発者は、ユーザーと定義されたペルソナのことを、自分達と同じ人間と思いがちになる。

しかし、実際はテクノロジーの知識や許容度は異なってくる。

そのため、自分たち好みに作ってしまうという傾向がある。

エクササイズ

ペルソナの制定のための話し合いが必要となることもある。

以下のような流れで行う。

  1. どんな人がターゲットになるのか、プロダクトの利用によってどう影響するのかの意見を述べるところから始まる。
  2. ペルソナタイプのリストを作成する
    1. 「大学生」「ストリーミング好き」「医療従事者」などのターゲットセグメントを決める
  3. 最もターゲットになりそうなペルソナを3〜4人に絞り込む
  4. ペルソナのテンプレートを、ニーズや役割によって区別するように作成する
  5. 小グループに分かれて、テンプレートに沿って各グループで1つ作成してもらう
  6. 結果を全体で持ち帰って検討する

ペルソナは一度決めて終わりではない

基本的にペルソナは一度定めたら終わりではない。

エクササイズを行って制定されたペルソナが正しいかどうかを確かめるフェーズが必要になる。

例えば、ペルソナとして想定した人を見つけられない場合、潜在ユーザーはいないということになる。

同じように、ペインを解決しようとしても、潜在ユーザーを集めて話を聞いてみると、課題となっていない場合もある。そうなると存在しない課題を解決しようとしていることになってしまう。

ある投資家達の、プレゼン資料やタームシートや、資本政策などをまとめるためのアプリを考えていたが、実際に話してみると年に1、2度しか投資を行わなかった。

それくらいであれば、メールやExcelで十分管理できてしまうということになり、無駄に労力をかけることを避けることができた。

ボックス4: ユーザーの成果とメリット

ユーザーの成果は役割によって異なる。

「ビジネスの成果」「顧客の成果」「ユーザーの成果」の違いについて考えてみる。

たとえば、ある会計ソフトを取り上げてみる。

顧客: 経理部門の効率を上げて、建て替えできない費用への支払いを減らし、全体的な運用コストを下げること

ユーザー: 早く経費を精算し、短時間で正しく経理データを入力すること

どちらも、行動ベースの成果だが、視点が異なる。

異なるグループの人が、異なる目標を指している。

購入者: 経理部の効率化の実現によって、上司に評価されたいという目標ができ、それを達成できるソフトを探す。

ユーザー: 面倒な手続きなしに精算できるようになることを望んでいる。

感情的な目標を達成できたかどうかになる。

しかし、感情的な目標を定量的に計ることは難しいが、かなり重要。

難しいからといって、注目しなくてもいいわけではない。

もし、適切に定量化ができれば、その定量的な測定基準において良い成果をあげることにつながるため。

エクササイズ

そのため、Lean UXキャンバスの、このセクションでは感情面に注目した議論を行う。

ペルソナが何を求め、プロダクトを探し、見つけた時に何をするのかを理解することを議論の目標にする。

注意すべきこと

機能に意識が向きすぎてしまうことがある。

それが顧客のモチベーションになると思い込んでいるから。

Apple は、競合他社が「12メガピクセルのカメラ」と機能をアピールする一方で、「外国にいる祖母に、赤ちゃんの姿を見せよう」と宣伝する。

ボックス4: ユーザーの成果とメリット

ユーザーの成果は役割によって異なる。

「ビジネスの成果」「顧客の成果」「ユーザーの成果」の違いについて考えてみる。

たとえば、ある会計ソフトを取り上げてみる。

顧客: 経理部門の効率を上げて、建て替えできない費用への支払いを減らし、全体的な運用コストを下げること

ユーザー: 早く経費を精算し、短時間で正しく経理データを入力すること

どちらも、行動ベースの成果だが、視点が異なる。

異なるグループの人が、異なる目標を指している。

購入者: 経理部の効率化の実現によって、上司に評価されたいという目標ができ、それを達成できるソフトを探す。

ユーザー: 面倒な手続きなしに精算できるようになることを望んでいる。

感情的な目標を達成できたかどうかになる。

しかし、感情的な目標を定量的に計ることは難しいが、かなり重要。

難しいからといって、注目しなくてもいいわけではない。

もし、適切に定量化ができれば、その定量的な測定基準において良い成果をあげることにつながるため。

エクササイズ

そのため、Lean UXキャンバスの、このセクションでは感情面に注目した議論を行う。

ペルソナが何を求め、プロダクトを探し、見つけた時に何をするのかを理解することを議論の目標にする。

注意すべきこと

機能に意識が向きすぎてしまうことがある。

それが顧客のモチベーションになると思い込んでいるから。

Apple は、競合他社が「12メガピクセルのカメラ」と機能をアピールする一方で、「外国にいる祖母に、赤ちゃんの姿を見せよう」と宣伝する。

ボックス5: ソリューション

ソフトウェア開発では、全てを俯瞰し、いくつかの制約を設けておく方が良い結果が得られる。

ここまで、ビジネスプロブレム・ステートメント、ビジネスの成果、ペルソナ、ユーザーの成果やメリットについて議論してきたので、制約を設けてきた。

これらの制約は、ソリューションを作り出すための空間をつくるものになる。

この段階では細かなデザイン作業は、まだ行わない。キャンバスが完成してからになる。

様々なブレーンストーミング

アフィニティマッピング

最もシンプルかつ、チームを協力させることができる方法。

一つの質問をチームにし、5分かけて各自が書き出したアイディアにつちえ議論をし、最適なのを導き出す。

質問: ペルソナが望む成果を実現するために、どのようなソリューションをデザイン・構築すれば良いか?

デザインスタジオ

5~8人のチーム

オンラインの場合、Miroなどのボードツールを使用

手順

  • 課題の定義と制約やリスクの明確化
  • 各メンバーによるアイディエーション(多様性)
  • プレゼンテーションとフィードバック
  • 2人人組でのイテレーションとアップデート(形成)
  • チーム全体でのアイディエーション(集約)

課題の定義と制約条件

チーム全員で、解決しようとしているビジネスプロブレム、取り組みの成功を定義する成果、ペルソナ、ユーザーの達成しようとしているメリットを共有する。

これまでやってきているので、全員が認識を持っている状態であるが、一緒に作業していなかった人がいる場合は、説明し質疑応答をする。

各メンバーによるアイディエーション

5分ほどで行う。

6分割に罫線が引かれたテンプレートを利用する。

それぞれのボックスに、ペルソナとペインを上部に書き、それぞれの解決策のラフなスケッチを書いていく。

様々な図形などを使って表現しても良い。

プレゼンテーションとフィードバック

1人3分でプレゼンテーションをチーム全体に対して行う。

良いフィードバックには、自分の意見を述べるより、相手に質問をする方が効果的である。

質問をする方が、チームが議論しようとしていることについて議論がしやすくなる。

逆に質問ではなく、意見を述べると、議論が活性化せず、コラボレーションも起こりにくくなる。

その結果、メンバーは自己弁護的になる。

2人1組でのイテレーションとアップデート

10分ほどで行う。

ここで、できれば同じアイディアを持つメンバーを2人1組にする。

書くペアで、それぞれデザイン案の改良に取り組む。

目標は、各ペアが最もメリットのあるアイディアを選び、それを進化させ、統合することである。

何を残し、何を変え、何を捨てるかの決断は難しい。

そのため、一般的、抽象的なアイディアにしがちになるが、そうならないように注意する必要がある。

チーム全体でのアイディエーション

45分ほどで行う。

チーム全体で、有望なアイディアを絞り込む。

ここで選択されたアイディアは、次のプロセスである仮説の構築と、その後のデザインと実験の基礎になる。

選択されなかったアイディアも、一時的にためておくためのバックログを作るようにしておくと先に進みやすくなる。

注意すべきこと

参加者が平等に参加できるようにすること。

ただし、リモートセッションでは、難しいツールではなく付箋を使えば楽なところが、とても難しくなる。

チームが下流で行う機能やデザインの選択に対して、抵抗を示す可能性が出てきてしまう。

このような時、チームのデザイナーにとってデザインファシリテーションが極めて重要なスキルになる。

ボックス6: 仮説

ここでは、ペルソナであるユーザーがプロダクトを使うことでどのような利益を得られるのかということを宣言する。

ビジネスの成果を達成するのに、ユーザーの成果を達成する必要があり、どんな機能がそれを可能にする ということを信じるフェーズになる。

この場合、複数のペルソナや機能を対象にしていることに気づくことも多々ある。

そうした時、複数の機能を同時に行うのは難しいので、一つの機能のみを目指すということを目指していくようにする必要がある。

ボックス7: 最初に学習すべき最重要事項は何か?

仮説の中で、どれを最初にテストすべきかを決める必要がある。

人々はソリューションを必要としているのか?

彼らはそれを探すだろうか?

試してみるだろうか?

使うだろうか?

価値を見出すだろうか?

などに考えていく必要がある。

初期段階において、とても重要になる。

これらの質問が全て、いいえと答えられるのであれば

どのようにデザインするか、構築するかについて考える必要はなくなる。

そのため、最初に学習すべき最重要事項は何か?にフォーカスを当てる必要がある。

そこで、チームの合意が必要となるが、合意に達しないのであれば、さらなる情報が必要となる。

そのためには、どれを対象にするかについてひとまずの決定を下し、実験を行う。

この決定は、プロダクトマネージャーが下すことになるが、選ばなかった仮説や前提、リスクを完全に捨てるわけではないということに注意。

とりあえず、特定の仮説を対象にして進めるだけで、誤りと証明されれば、仮説のバックログに戻り、このプロセスを行なっていく。

ボックス8: MVPと実験

最後のステップである、ボックス8 では実験に焦点を当てる。

Lean UXキャンバスの2つの重要な質問の一つは、「次の最重要事項を学ぶために必要な最小限の作業は何か?」に対する、仮説検証のための実験である。

つまり、MVPの作成になる。

優れたMVPは、価値と学習の両方を創造する。

しかし、Lean UXではMVPは学ぶことに重点を置く。

MVPを構築するには

まず最初に必ず、「次に学ぶ必要がある、もっとも重要なことは何か?」を考える。

核心を突く

ナビゲーション、ログイン、パスワード取得フローなどは、アイディアそのものがターゲットオーディエンスにとって無価値である場合、考えても意味がないので後回しにする。

明確なCTA(コール・トゥー・アクション)を使う

サービスの選択やサインアップの機会を提供することで、ユーザーの興味の度合いや、実際に金を払ってくれるかどうかを判断しやすくなる。

行動を測定する

実際の行動を測定できるMVPを構築する。

人々の言葉で説明する自らの意図に惑わされずに、実際の行動に焦点を当てることができる。

ユーザーと話す

MVPを通して、何をしたかは分かったが、「なぜ」の部分が分からないと意味がない。

そのため、意図通りに使った人と、そうでなかった人の両方から話を聞く。

優先順位付けを重視する

優先順位が大事なので、有効であることが検証されていないアイディアを気に入ってるからという理由で固執しないように注意。

しかし、デザイナーは楽観的に物事を考える傾向があり、考案するのに5分のものも5ヶ月のものも、自分たちのソリューションはよく寝られたものだと思いがち。

実験の結果が期待に反したものであれば、その期待は間違いということを忘れないこと。

アジリティを維持する

アップデートが容易な方法やツールを用いて実験やプロジェクトを進める。

0から作ろうとしない

アイディアをテストするためのツールやシステム、仕組みはすでに多く存在している。

既存のツールを使って学習をする方法を検討する。

電子メール、携帯メール、チャットアプリ、Facebookグループ、Shopifyストアフロント、ノーコードなど

プロトタイプの種類

  • ペーパープロトタイプ
  • 低忠実度のオンスクリーンモックアップ
  • 中〜高忠実度のオンスクリーンプロトタイプ
  • ノーコードMVP
  • コーデッドプロトタイプ、ライブデータ・プロトタイプ

コラボレーティブデザイン

コラボレーティブデザインを主導するのは、従来と同じく、デザイナーになる。

コラボレーティブデザインのためのミーティングを主足し、メンバー間のコミュニケーションを促す。

カジュアルな形式の会話や、

スケッチのセッション、

ホワイトボードの前でのエンジニアとの本格的な1on1のセッション

など

一般的な流れ

  1. チーム全体でスケッチをする
  2. デザインのアイディアについて議論し、チーム全体で意見をまとめる
  3. 成功の見込みが高いと思われるソリューションを1つに絞り込む

デザイナーは従来通りデザインを行いながら、チーム活動のファシリテーターを行う。

Lean UXとデザインスプリント

デザインスプリントとは

  1. チームを集め
  2. 質問を定義
  3. アイディアを出す
  4. 試作品を作る
  5. テストする

というのを5日間で行う。

ただ、デザインスプリントでは仮説やMVPといったLean UXで登場する言葉は出てこない。

そのかわり、スプリントの最終日にプロトタイピングとテストを行う。

この点は、対立しているように感じられることがある。

ジェイク・ナップのインタビュー

Lean UXは、プロダクトサイクル全体、組織全体で使える料理本のようなもの。

対して、デザインスプリントは、チームの特定のメンバーが特定の瞬間に特定のものを作るための、1つのレシピ。

実験の中の実験という形で、デザインスプリントの中でオリジナルを試しながらチームを観察し、少しずつアレンジしていく必要があると言う。

ただ、プロダクトの細部を決めるものではないので、全体の開発スケジュールを計画したりするためのものではない。

MVPの代わりにもならなければ、ゼロから立ち上げまでの道筋を提供するものにもならない。

特定の期間に最大限の効果を発揮する。

Lean UXのプロセスでのデザインスプリントの使用

Lean UXでは、作業を「構築すべきもの」ではなく、解決すべき課題として再構成することが奨励される。

Lean UXでは、課題、オーディエンス、潜在的ソリューション、成功について前提を明確にすることを推奨する。これにより、良い仮説が立てられ、デザインスプリントの構成にも役立つ。

仮説が、デザインスプリントの開始地点となる。

スプリントで行った作業を使用して、これらの前提を細かく検証し、仮説を洗練させて次のステップを明確にする。

デザインシステム

デザインシステムを利用することで、画面構造、プロセスフロー、情報設計などの決定(ホワイトボードで作成できるもの)を適切なチームメイトが担当し、色、フォントタイプ、スペーシングなどを別のチームメイトが担当することができる。

これにより以下の2点が促進される。

  • デザインの高速化
  • プロトタイプの高速化

組織に対しても大きな利点がある。

  • 一貫性の向上
  • 品質の向上
  • コストの削減

リモートのコラボレーション

分散型のチームとのコラボレーション

コラボレーションを容易にできる、重要なポイントが2つある。

  • 全員が同じ条件で参加できるようにすること
  • 自由なコミュニケーションを促す仕組みをつくること

全員が同じ条件で参加できるようにすること

自分以外が会議室にいて、自分だけ電話でミーティングという状況とかが分かりやすい。

ホワイトボードに付箋を貼ったりとかになると、電話で参加している人は難しくなる。

そのために、使うツールを適切に選ぶこと。

例えば、MuralやMiro、共有ドキュメントなど、オンラインホワイトボードを使用するなど。

自由なコミュニケーションを促す仕組みをつくること

オンラインミーティングでは、唐突に始まり、唐突に終わる。

それもメンバーを集め、アジェンダを細かく定め、時間通りに終了するという杓子定規な方法で行われるが、実際のオフラインでは会議の前に廊下で軽く雑談をしたり、ミーティングが始まるまでの間、あれこれと話をする。

ミーティングが終わったあとも、一緒に会議室を出て、コーヒーを飲みながら感想を述べあったりする。

こういったコミュニケーションが仕事の本質とは無関係ではなく、重要な意味を持つ。

こうしたコミュニケーションを通して絆が生まれ、一緒に仕事ができている。

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

各スプリント後に行われるレトロスペクティブをサポートするドキュメント。

コラボレーションを進めていく上でのどんな合意がチームにあったかを記録する。

合意した内容に従って作業が進められているかどうか、新たな合意内容を追加するために更新すべきかどうか、不要な古い合意を削除するかどうかを確認する。

以下のようなことを書く。

プロセスの概要

どのようなプロセスか?アジャイルイテレーションの期間は?

定期的なコミュニケーション

どんなコミュニケーションスタイルか?デイリーはいつするのか?企画会議やでもを開催するのはいつか?

コミュニケーション/ツール

ドキュメント化するためにどのようなシステムを使うか?

プロジェクト管理ツールは?アセットはどこに保管しているか?

チーム文化/安全性/対立関係の解決

どのようなチーム文化が望ましいか?

安心してチームメイトと働くために、個人として何が必要か?

対立が起こったらどうするか?

意見の相違の解決方法は?

労働環境と時間

誰がどこで働く?

メンバーがオフィスにいる時間は?時差は?

要件とデザイン

要件定義、ユーザーストーリーの作成、優先順位付けをどう扱うか?

ユーザーストーリーを作成するのはいつか?

開発方法

どのようなプラクティスを採用するか?

ペアプロするか?テスティングのスタイルは?

ソース管理方法は?

開発中の制限や制約

バックログとアイスボックスのサイズは?

プロセスの各段階にどのようなWIP制限が存在するか?

デプロイ

リリースの流れは?どのようにユーザーストーリーを受け入れるするか?

その他いろいろ…。

心理的安全性

A Culture of Safety(著者アラ・ウェインバーグ) 引用

「チーム内に、ミスを認める、質問をする、新しいアイディアを提案する、などの行為が恥ずかしいことと見なされず、抜歯もしないという共通の信念があること」と定義。

フィードバックとユーザーリサーチ

Lean UX におけるユーザーリサーチは断続的である。

進行中の採掘にフィットする一口サイズのユーザーリサーチを行う。

ユーザーリサーチは、専門のリサーチャーに外注せず、チーム全体で行い、責任を分担する。

これにより、詳細な文書がなくても、意思疎通を図ることができ、学習の質も高まる。

重要なのは、チーム全体で共通理解を深めること。

ユーザーリサーチ

ユーザーリサーチによって得られた未加工のデータから、意味のある情報を取り出すのは、時間のかかるフラストレーションのたまりやすい作業。

そのため、リサーチ結果を外部に委託してしまうことがあるが、これはできれば避けるべきこと。

ユーザーリサーチが終わったら、できれば同日、少なくとも翌日に、チーム全体でレビューを行う。

ユーサーリサーチの結果

結果をまとめようとすると、データが矛盾を示すケースが出てくる。

このような時の対処法は以下。

  1. パターンを見つける パターンとは、特定の要素に対してユーザーの意図が繰り返し向けられていることを意味する。パターンに当てはまらない場合は、異常値であるとみなす。
  2. 異常値は、駐車場に置く(いったん脇に置く) 異常値を見つけた時は、無視する(またはソリューションで対処する)。 しかし、暫定的なものとしてバックログに記録しておく。 継続していくにつれ、他の異常値が見つかることで、パターンが示される場合がある。
  3. 他のソースを使って検証する あるチャネルから得られたフィードバックの妥当性に確信が持てない時は、他のチャネルを使ってそれを確認する。 カスタマーサポートのE mailを対象にしたユーザーリサーチの結果は、ユーザビリティのリサーチ結果と同じ懸念を示しているか? オフィス内外のユーザーは、プロトタイプの価値について同じ意見を持っているか? そうでなかったら、サンプルに偏りがあったと考えられる

カスタマーサービス

カスタマーサポートに連絡し、取り組んでいるプロダクトやサービスの部分について、ユーザーからどのような話を聞いているかを尋ねる。

今月、ユーザーが好んだものは何か、好まなかったものは何かを議題にする。

月末にカスタマーサービスとコミュニケーションをすることで、チームは自らの取り組みが成果を上げているかどうかを知るための明快な指標を得ることができる。

課題が上位10件のランキングにとどまっていれば、ソリューションが効果をあげていないと判断される。

オンサイトでのフィードバック

以下オプションで、フィードバックの仕組みを設ける。

  • シンプルなEメールフォーム
  • カスタマーサポートフォーラム
  • サードパーティのコミュニティサイト

これにより以下のような目的のリサーチで使える。

  • サイトの特定セクションから受信したEメールの数をカウントする。
  • オンラインディスカッションに参加して仮説をテストする。
  • 被験者が見つけにくい場合には、コミュニティサイトを活用して募集する。

検索ログや、サイト利用状況の分析、ABテストによって、機能の使われ方や使いやすさを調査する。

サイト利用状況には、KissmetricsやMixPanelといったサードパーティのメトリクスプロダクトを用いることができる。

ABテストには、Optimizelyなどのサードパーティツールを使うことができる。

アジャイル

Lean UX をアジャイルの仕組みにどう適合させるかについて。

アジャイルの仕組みの重要なポイント

  • 短いサイクルで作業を進める。
  • 各サイクルの終わりに価値を提供する。
  • 毎日、簡易的なプランニングミーティング(デイリースクラム)を開く。
  • 各サイクルの後にレトロスペクティブ(振り返り)を行う。

重要なことはレトロスペクティブ

スクラムをやるとした場合、最初にやらないといけないことは、最初1、2回のスプリントの後にレトロスペクティブを取り入れること。

そこでは、チームの課題について気軽に本音で議論できるレトロスペクティブにしなくてはならない。

「何がうまくいっているのか?」「何がうまくいってないのか?」「今後、何を変えて行きば良いのか?」などを検討する。

スタッガードスプリント

デザイン工程をスプリントを一つズラして行うこと。

しかし、これは小さいウォーターフォールを行っているようなもので、ウォーターフォールからアジャイルに移行する時には有効だが、最終的な目標ではない。

なぜなら、同じことに対してチーム全体で取り組んでいる訳ではないから。

部門横断的なコラボレーションのメリットが得られない。

マルチスプリントテーマ

プロダクトゴールは、一連のスプリントをつなぐために用いるマルチスプリントテーマとみなせる。

それぞれのスプリントのテーマに対して、デザインスプリントを用いる。

つまり、仮説、検証、改善を顧客の価値基準で試していく。

デザインの細部について話すわけではなく、あくまで顧客が使うか、それによって得られるメリットを念頭に置いて、スプリントを繋ぎ合わせていく。

エクスペリメントストーリー

デザインスプリントなどでカバーしきれなかったディスカバリ作業を、そのイテレーションで追加的に実施する必要がある。

それにより以下の利点がある。

  • ディスカバリ作業を可視化する
    • デリバリーと違い具体性がない。
    • そのため、エクスペリメントストーリでは、競争の場を均等にする必要がある。
    • その結果、全て(ディスカバリ、またはデリバリー)はユーザーストーリとしてバックログに収められる。
  • デリバリー作業への優先順位付けが必須になる
    • ユーザーストーリにーに対しての優先順位を、いつするか、どれを作業しないについて議論する

プランニングには全員が参加する

全ての活動(スタンドアップミーティング、レトロスペクティブ、プランニングミーティング、ブレーンストーミング)にチーム全体が参加すべき。

それにより、共通理解が学習され、たとえ9割が自分に関係のないことだとしても、関わる1割の情報によってその後の作業の何時間かを節約できるケースがある。

ステークホルダーとリスクダッシュボード

プロダクトオーナーやステークホルダー、CEO、クライアントは状況を詳しく知りたがる。

プロジェクト計画を自らの判断で承認したがるから。

しかし、成果重視型のチームにとって、プロジェクト計画は学習した内容に応じて変化していくもの。

そのため、1回の計画で予定する作業量は多くない。せいぜい1つまたは2つ先の凍レーションを計画している程度。

しかし、マネジメントはこのような計画を「近視眼的な」ものと捉え不満を抱きがち。

そう言う中で、マネジメントに上の介入をされないようにするための方法。

事前対応的なコミュニケーション

追加した機能をリリースすることを事前に告知しておくというもの。

そのために、強力なツールとしてリスクダッシュボードを作成しておく。

これによって、ステークホルダーに次のような情報を提供できる。

  • 作業の進行状況
  • 次に注力すべきリスク
  • 機能セットではなく、成果(目標に向かってどのように前進しているか)を重視していること
  • 依存関係のある部門(カスタマーサービスマーケティング、オペレーションなど)と、これらの部門が、今後自らに影響を及ぼし得る変化を認識しておくことの必要性

ロードマップ

これまでは、ロードマップがソフトウェア業界では使われていたが、デジタルプロダクトの開発は、直線的ではなく、イテレーション的なものなので、顧客行動を見て、どう影響を与えるかを観察し、再びイテレーションを回す。

そのため、出発点と明確かつ機能固有の終点(つまり締切)がある従来の直線的なロードマップモデルは、結果重視のデジタルビジネスの手法を反映するものであり時代遅れである。

プロダクト主導型では、成果主義を取り入れる。

そこで、成果ベースのロードマップを採用する。

エージェンシーにおけるLean UX

ここでいうエージェンシーとは、クライアントにサービスを提供する組織全般を指す。

エージェンシーにとって、クライアントとの業務では、クライアントの意向によるので、期待されることもあれば、やり方を拒絶されることもある。

そう言った場合でもLean UXは活用される重要なポイントが5つある。

どのような方式のビジネスか?

エージェンシーは、成果物ベースのビジネスをやることが多い。

これはLean UXとは合判するもの。

そのため、成果物を作るために稼働率を上げることを目的にしがちになってしまう。

そうすると、部門横断型のコラボレーションもできなくなってくる。

これらの解決しなければならない2つの課題に対するアプローチ。

従来型の成果物ビジネスから脱却すべき

タイムアンドマテリアル(工数単価)色のモデルに変えること アプリやデザインを売るのではなく、クライアントが抱える問題のソリューションを見つけるためにクライアントと共同作業をすることの対価として、報酬を得る形。 ソリューションは、プロジェクト開始段階では分からないが、それを一緒にクライアントと探す。

稼働率を高く維持するためには、少人数のチームを明確な更新基準の契約に基づき、期限付きで売り込むこと。

通常3ヶ月更新の契約で仕事をする。

そのため、短期間サイクルでの仕事の進め方を行いやすくなる。

これにより、仕事の進め方が合わないクライアントのために延々と働き続けなければならないというリスクも減らすことができる。

実験に誰もお金を払わない

クライアントは実験が嫌いで、実験にお金は絶対出したくないという考えが多い。

10万ドルの予算のうち、1万ドルを実験費として残りの9万ドルの最適な使い方を探る費用にしようと提案すると渋るだろう。

しかし、実験とはLean UXの一部ではありますが、単なる戦術である。

学習、適切な意思決定、ポジティブな成果を生み出すプロセスの一部である。

世界一流エンジニアの思考法

概要

マイクロソフト勤務の著者が、働く中での気づきや、 周りのエンジニアから学んだことを、自身の考えを絡めてまとめている。

自身の経験として、エンジニアに向いていなかった過去から、それ以前の経験を活かし、どのように適用していき 一流との差や、一流と一緒に働くことに対して、どういうアプローチを取ったのかというのを紹介している。

特別なことは確かにやっていないのだが、自身の行いを確実なものとして認識して 間違ったやり方ではなかったと認識するには体系的に理解するのにいいかもしれない。

最近の日本の企業としても働き方はかなり変わっていて、本書に出てくるような働き方ができるような企業も増えてきているので これから、自身の働き方をどう自分で調整していくか、自分の動き方をどうしていくかということに悩んでいる方には指標になるのではないだろうか。

各章の大枠

各章に書かれている大事だと思った箇所や、参考になりそうだと思った箇所を記述していく。

生産性

仮説を証明する

どんな一流のエンジニアでも、やり方さえ間違えなければ自分でも同じことが可能である。

例えば、慣れていない場合、クエリに間違いが発生してる時など、いろいろと手を動かして試してみようとするが 一流エンジニアとなると最初のログをじっくり読んだ後に仮説を立ててから行動をする。

つまり、最初に推測したものを実証するようにクエリを投げるようにするようにするのである。

そうすれば、複数回クエリを投げずとも、結果にたどり着くことが早いのである。

十分な理解を持って手を動かす

一流のエンジニアは、特別頭がいいと言うわけではなく、ちゃんと理解してから手を動かすということをする。

学習用のビデオを見る時も、10回見て、分からないところはポーズをしてメモをするなどを取る。

どんな人でも理解に時間がかかることはあるので、それ相応の努力をしていることになる。

そして、手を動かすのは最後になる。

無駄に手を動かして、試行錯誤するのではなく、仕組みを理解してからの方が時短に繋がる。

理解とはどうなることか

  • 構造を掴んで人に説明できること
  • いつでもどこでも即座に取り出して使えること
  • 知見を踏まえて応用がきくこと

コードの話でいえば、コードの意図とその背後のアーキテクチャを理解することを優先する。

言えば当たり前のことだが、これが基礎となる。 基礎は誰にでも分かるが、習得には時間がかかる。

この基礎を学ぶには、著者がやったことは

  • 定時後や週末にプログラミングの基礎を学ぶ
  • 言語の仕様を理解する
  • LeetCodeなどの問題を毎日解く

などである。

大事なのは、基礎を簡単だと馬鹿にせず、1からやり直しをするということだ。

ドキュメントを残す

ドキュメントを書くには以下のメリットがある。

  • ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点に気づくことができる
  • 考えてる時のことをドキュメントにすることで、それをシェアするだけで済むようになる。あとでドキュメントとしてまとめるというのは退屈な仕事になる。

自分が良いソフトウェアを書く上で、理解して効率よく開発するために書くということを理解しておこう。

メンタルモデル

多くのことを同時に把握するには、メンタルモデルを作れるようになることが重要である。

メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論。

ここではシステム思考というフレームワークを頭にインプットする。

ソフトウェアのアーキテクチャ、クラスの構造、ソフトウェアのどういったパーツがどこにあるか、システム全体を先に把握する。

それから、全体の関係図、フローをビジュアル図としてイメージし、各パートの関係性をあてはめていく思考法。

そういった図を頭の中に持つことで、障害が出た時や、話の焦点となるものがクリアになり、どこに何の話があったか紐付けがしやすくなるというもの。

構築の手順としては、エキスパートに頼るというもの。2時間以上詰まったら即座に聞くなどをする。

大事な感覚

自分が仕事をコントロールしているという感覚。

どんなことも、基礎を固め、分からないことなどをしっかり助言を頂くことで仕事をコントロールすることができる。

それを自分で感じ取ることができるようになることが重要。

Be Lazyというマインドセット

より少ない時間で価値を最大化するという考え方。

  • 結果達成のために、最小限の努力をする
  • 不必要なことをやらない
  • 簡潔さを目指す
  • 優先順位をつける
  • 時間や努力ではなく、アウトプットと生産性に重点を置く
  • 長時間労働しない
  • 会議を時間内で完結し、価値を提供する

これらは当たり前に見えるが、落とし穴がある。

このために大事なことは

「最初の1個をピックアップしてやったら他はやらない」

ということ

その一つにフォーカスをあてる。

一つのことを確実にやるということが大事。

なぜなら、ソフトウェアのうちで本当に大事で使われる機能は40%くらいという統計がある。

それに対して100%を注ぐことは無駄とは言わないまでも価値が最大化できていないと言うことに繋がる。

この、Be Lazyというのはやらなくていいことはやらないというマインドのこと。 そうすることでやることを減らすというマインドのことである。

また、会議の中で結論を作るということも大事。 持ち帰って検討することは極力せず、会議の時間内で完結することは生産的である。

失敗のリスクを取る

失敗や間違いを受け入れることを行う。

具体的には

  • 間違いを厳しく批判したりしない
  • 失敗から学ぶ
  • 早く失敗する
  • 実験が推奨
  • 現状維持や標準を要求せず、臨機応変が推奨される
  • 避難や恐怖感のない環境

人間である以上、失敗はつきものなので、早く失敗をして早くフィードバックを得て、早く間違いを修正していくの精神が大事になる。

検討ばかりをして、さっさとやらないことの方がリスクになってしまうということを肝に銘じておく必要がある。

例えば、さっと作れるならプロトタイプを作ってしまってから話し合いをし、フィードバックをもらう方が断然早いし、話がスムーズに進むというようなものだ。

アーキテクチャやツールが数種類あって悩む場合もあるだろうが、結論的にはなんでも良いとなる。 圧倒的な差があれば悩む必要がないし、決めあぐねるくらいであれば大差がないのである。

さっさと間違えて、修正したものを出せば良いだけなのだ。

不確実性を受け入れる

変化に柔軟な対応が必要なソフトウェアにおいて、とくに必要とされるマインドになる。

具体的には

  • マネジメントは詳細までものを期待しない
  • 予算と報告のプロセスは精密な結果の予測を要求しない
  • 内部プロセスは計画や優先順位の変更に柔軟である。
  • 事前に全ての問題分析が完了せずとも、新しいことに挑戦する姿勢を持つ
  • システムとプロセスは柔軟で、複数の頻繁な変更を受け入れられる
  • 学びに基づいて、変化を精力的に行う

ここで気になるのは、納期になるだろう。

しかし、日米で納期に関しては意味が異なる。

日本では、納期までに予定された機能が全て搭載された製品を予定された品質で納品が必要となる。

アメリカでは、納期に厳しくなく、実際納期になった時にリリースされるものは予定より少ない量であることも多い。

納期に間に合わせるために徹夜する人なども少ない。

ソフトウェア開発において、納期通りというのはほとんどない。 多くの不確実性をはらんでいるからだ。

ではどうすればいいのか

進捗の実績だけで状況判断し、納期を固定したままスコープを出し入れするのが現実的である。

納期は守りつつ、間に合わないものはリリースに入れずに次に回すか、もしくはやめるのである。

中長期で見たときに、無理をして徹夜などで間に合わせても、エンジニアの体調が崩れてしまった方が生産性が下がるので、マネジメント的には効率が悪いからだ。

そして、無理して出来上がった実績は、後世に引き継がれてしまう可能性があるのだ。 つまり、前回これだけできたのだから、今回もこれくらいいけるよねというような形で無理が続いてしまう可能性があるのである。

守らなければいけない納期

しかし、そうは言っても、絶対に遅れてはならない納期というのもある。 法律的に関わるものであったり、オリンピックのようにその時に出ていないと意味が全くなくなるような納期である。

そう言うものに対しては、シンプルに早く進めるしかない。

すでに動いているものをリリースすると約束できれば良い。 例えば、フィーチャーフラグを使ってフラグの切り替えでリリースできるようにすることで公開とすることも可能であるのだ。

余裕のある計画を立てる

不確実性の高いソフトウェアにおいて、その人のできる日数を納期にするのではなく、プラス何日か余裕のあるスケジュールを設定する。

アメリカでは、「なるはやである」とか、「明日までに」というオーダーはマネジメント能力の欠如とみなされる。

生み出すものの量ではなく、価値にフォーカスをあてるマインドが大事になってくる。

コードリーディングにおける脳の負荷

以前書いた

ugo-ev.hatenablog.com

プログラマー脳と内容が重複する箇所が多かったので端折る。

ざっくりと以下のようなことである。

極力読まないようにする。

他の開発者を信じて、読まなくても挙動が分かる部分は動作だけ理解してコードは読まないなど

クラスの役割だけ把握し、インターフェースを理解することで、読む量を減らす。

重要なことは、「自分にとって難しすぎると感じる時は、大抵脳の使い方が間違っているサインである」

人に説明できるようにする

人は記憶力がいいものではない。

では、どうすれば記憶の中に留めておけるだろうか。

人に説明できるように理解すればいいだけの話である。

人に説明できるということは構造を整理して把握して、脳のメモリに乗せる必要があるということである。

また、先述したメンタルモデルをつくることも状況の細かいことを把握するコツになる。

そのため、単に「できた」で終わるのではなく、「説明が可能か」というところまでセルフチェックをした方が良い。

復習するタイミング

記憶しやすくなる復習のタイミングの習慣化というのを意識をする。

以下のタイミングが良い - 覚えた翌日 - そのさらに1週間後

意識の中に残せるようにするには、次の三つのファクターが重要になる。

  • 理解
  • 記憶
  • 反復

頭の中のみで整理する

ディスカッションをするにしても、頭の中にフレームワークがあるから理解できる。

頭の中でのみ物事を整理する訓練をしていけば、それができるようになる。

具体的には

  • ミーティングの議事をその場で書かない
  • 人の話を聞く時は、その後に誰かに説明することを想定して頭の中で整理しながら聞く
  • 頭の中で整理してから文章に書く

コミュニケーションにおける原則

エンジニアの人には、情報が少ない方が好まれる。 たくさん情報があっても消化できないという感覚による。

PRなどに大量に説明があっても、誰も読まないし、逆にスルーされることもよくある話。 もっと単純化する必要がある。

最初から全部説明せず、情報量を減らすコミュニケーションの仕方がすごく重要。

相手が求めているものへの感度

相手が何を欲しているかを理解して、自分用のメモを作る際にも共有できるような形で書いておく。

そうすることで、いつでもそのリンクを送るだけで良くなる。

見る人が欲しい情報はこれだろうという形で整理しておくべきである。

日頃から伝えることを前提としてメモなどの準備をしておくと、何か聞かれた際の工数削減にもなるのである。

他の人にシェアできる形式を意識して、文書を書くということに時間を惜しまずにすることで、将来の自分の工数削減になるのである。

環境

また、当書ではコミュニケーションの取りやすさという視点で

クイックコールと呼ばれる、簡易的な通話を行い、気軽にペアプロをしたり、一緒に考えたりしてもらうようなこともある。

もちろん、声のかけやすい環境というのを心がけることでクイックコールをしやすいという面もあれば、クイックコールされやすいということもある。

クイックコールをされる側としては、ちょっと手助けするだけでプロジェクトがスムーズに進むのでいいこともある。

なので、どんどんクイックコールをするようにしたり、そういうのが良い環境を作ることが重要になる。

チームビルディング

サーバントリーダーシップ

サーバントリーダーシップとは、リーダーはビジョンとKPIを示すが、実際にどう動くかはチームが主体的に考えて意思決定していく。

対して、コマンドアンドコントロールという管理体制では、マネージャーが部下に指示をする形になる。

サーバントリーダーシップのスタイルでは、現場のメンバーがかなりの権限を与えられて、どう実行するかを各自で考えているのである。

自己組織

自己組織チームとは、チームが自ら考えて自分で意思決定をするスタイルになる。

3つの特徴がある。

  1. 生産性が高い
  2. チームのエンゲージメント(満足度)が高い
  3. よりよいソリューションが選択されやすい

タスクの割り振りもチームが自らやっていく。

基本的にメンバー各自がやりたい仕事を「自分がやる」と選択している。

何が重要かというと、メンバーが楽しんでいるかが重要視される。

楽しい仕事でなければ、生産性は上がらないし、楽しい仕事であれば生産性は何倍も高くなるのである。

マネージャーの存在は仕事を楽しめているかを確認すること

マネージャーといっても、日本とアメリカでも全然違う。

日本では、進捗管理や課題管理を行なったりする。いわば、指揮をする人である。

アメリカでは、サーバントリーダーシップ制のもとでマネージャーが重視するのは、各メンバーのメンタル面になる。

マネージャーの一番の関心事は、メンバーがいかに幸せに働けているかになっている。

なので、随時「楽しめているか」を確認し、心地の良いムードを作ろうとしている。

そのため、マネージャーはメンバーに対して、困っている部分に対するアドバイスはするが、具体的にあれしろ、これしろなどと細かく指示することはない。

例として、1on1の時間では、共有したいことややってみたいことの相談のほか、悩みなどにアドバイスをくれるというものになる。 誰かを見習えなどの話はなく、メンバーの個性を手助けする姿勢がある。

納期に対する意識

日本だと、納期は絶対というイメージがある。

しかし、不測の事態は見通せないため、達成されないということも頻繁に生じる。

そのため、マネージャーは基本的に、一度仕事をプログラマに割り振ったら、あとはもう信頼するしかないのである。

逆に、そのプログラマが精一杯やっても遅れてしまったのなら、それがその時できるベストだったということである。

日本ではよく、技術者はどんな批判も受け入れ、まさかりを投げ合って成長するものというような雰囲気があるが、そんな辛い思いをしなくてもプロフェッショナルにはなれるのである。

基本的に、みんな自分が一番大切で、自分の幸せを第一に考えることを前提としているのである。

ミドル層

サーバントリーダーシップ方への転換で、一番抵抗が激しいのがこの層になる。

トップ層とは違い、新技術の導入や変革に対して、前向きになりにくい。 プロジェクトやサービスごとに数字を持っているので、自分の慣れていない方法で新しいことを始めるのに相当勇気がいるからだ。 彼らは慣れていないリーダーシップのやり方で発揮しなければならない。

しかし、しっかりトレーニングをすれば、過去のマネジメント経験も生きて、新しいサーバントリーダーが誕生しやすくなる。

生活術

ワークライフバランスについて

基本的に、働く人の裁量に任せられる。

日中はミーティングなどが多い時は、夜に集中してコーディングの時間を取るとかをする人もいる。

生産性を上げるには、定時上がりの方が効率が良かったりもする。

ただし、定時で上がったあとは自分の好きなトピックについて学習したりを行う。 そのように、学習をしなければ生産性は上がらないのである。

タイムボックス制を取り入れる

定時が来たら仕事が終わっていなくても強制的に切り上げるというような感じでタイムボックスを取り入れると良い。

そうすると頭がスッキリし、リフレッシュしたりする。

夜の時間は自分の趣味に回すことができるので、気持ち的にも余裕が持てるようになる。

そうしていくと生産性が上がるのである。

違うことをする

気分のリフレッシュに以下のようなことを頭に留めておくと良い。

  • 水泳をする時に息継ぎをせずに泳ぐことはできない。
  • 発送のブレークスルーは、その仕事をしていない時に発生する。
  • 1日に一つのことに集中できるのは4時間。
  • 何もしない休息ではなく、いつもと違うことをする。

幸せ

この本で一番好きな言葉がある。

「幸せを感じるから成功するのであって、成功したら幸せになるわけではない」

という言葉だ。

物事を整理するということを意識する。

例えば、ランニングに行ったら走ることだけで完了とするのではなく、帰って水分補給をしてシャワーを浴びて万端の状態になるまでを一連の所作として行う。

それが達成されては初めてランニングが完了するとした時の達成感によって、幸せを感じることができるのである。

まとめ

上記のほかにもいろいろと書かれていることはあったが、自分にとって重要だと思われるところだけを抜粋した。

AIに対しての考えであったり、ワークライフバランスや体の衰えに対する考えや実際の行動など

非常に参考になることが多く、プログラマーとしてやっていこうと思ってる人には一読の価値があるだろうと思った。

Microsoftで働かれてることもあり、Microsoft製品名を全面に出しているのは気になったが、内容には大きく影響の与えるものではないので、随時自分の使ってるツールなどに置き換えてもいいとは思う。

この本を読む直前に意外と自分の中での発見したことがあり、それが答え合わせのように書かれていたので、自分の感じたものは間違いではなかったのだと改めて確認できたのも良かったと思う。

SCRUM MASTER THE BOOK

自己組織化

スクラムにおける自己組織化は、スプリントゴール、バックログ、動作するプロダクトを期間内にデリバリーすることに限られる。 あるメンバーにとって気二位いらないことがある時は、チーム全員で話し合ってお互いを理解し、協力や助け合いの方法を変えていかなければならない。 重要な特徴として、一人ひとりのマインドセットがある。 良いチームは、「私」ではなく、「私たち」の姿勢を持っている。 「問題を解決するために、チームを手助けできることはありますか?みなさんのお役に立てることはなんでしょう?」 というふうに考えられるようにすること。

自己組織化したチームは一つの生命体となる。 チームメンバーが、自分自身ではなく、自己組織化したチーム全体のあり方に責任を持ち、説明責任を果たし始めたら、偉大なチームの一員へと一歩近づく。 スクラムマスターは、チームを「個人の集まり」ではなく、「一つの存在」として認識していけるように重要性に気づいてもらわなければならない。

スクラムマスターの責務

  • チームが責任を持つように促し、共通のアイデンティティと目標に沿って行動することを支援する
  • 透明性とコラボレーションを推進する
  • チームの自発的な行動を促すことを通じて、障害物を取り除く
  • アジャイルスクラムの考え方を理解し、自分自身も学び続ける
  • アジャイルスクラムの価値を維持し、他の人がスクラムを視界し、実施するのを助ける
  • 守るべきときは、開発チームを守る
  • スクラムのミーティングをファシリテートする
  • チームがより効率的になるよう、手助けする

チームメンバーと兼務

デメリット

システム全体を俯瞰する視点とシステム思考の能力を欠いてしまう。 リーダーシップやチェンジマネジメントのスキルを欠くこともある。 チームの能力を向上させることに気が回らない。

メリット

メンバーの一員なのd、チームメンバーの間には相互に信頼がある。 スクラムの基本とチームの弱点を理解しているので、レトロスペクティブで指摘を入れることができる。

結果

重要性が低いものとみなされ、完全に消滅してしまうこともある。

プロダクトオーナーと兼務

デメリット

相反する関係になる。 スクラムマスターは、デリバリーの責務を担うべきではない。 デリバリーの責務はプロダクトオーナーの責務。

メリット

チームメンバーの一員として扱ってもらいやすくなる。

結果

スクラムマスターの役割は淘汰され、POがすべてをコントロールするようになる。

マネージャーと兼務

デメリット

命令的になる。 コーチングせずにメンタリングに頼る。 メンバーとの関係性を欠いたものになりがち。

メリット

優秀なマネージャーはリーダーであり、チェンジマネジメントの経験があるため、移行期間中の対応がより素早くなる。

結果

ほとんどのマネージャは組織を率いることを夢見るので、スクラムマスターをやったとしても一時的なものになる。 自己組織化、自己肯定感、当事者意識が弱くなりがち。

複数のチームを兼務

デメリット

時間が足りない。 早めに議論をファシリテートし、対立が大きくなるのを防げないと、かなり難しい仕事になります。

メリット

このスクラムマスターは素早く学び、困難な問題を解決する経験を豊富に持つ。 理想は、2チームまで、最大でも3つまで。 3つでも手が余る場合が多く、必要な情報が不足し、衝突を防いだり、チームを次のレベルに高めたりすることができなくなるため。

結果

システム思考に秀でることが多い。 チームは一つ一つ異なることを理解しているから。 多様な文化に合わせてスクラムをうまく実装できる。

スクラムマスターはリーダー

スクラムマスターはリーダーシップを取る職務になる。 創造性、ビジョン、直感が必要。 共感力があり、聞き上手で、いつでも関係性を修復する準備ができている。 組織をまたいだコミュニティを構築できる。

スクラムマスターの役割

ティーチングとメンタリング

スクラムアジャイルの基本的な進め方を伝えるもの。 自らの経験に基づき、効果的なプラクティスや手法を提案する。 アジャイルへの移行の序盤では、何度も繰り返し説明しなければならない。 それぞれのプラクティスがなぜ組み込まれ、どうすればうまくいくのか、チームが理解しきれないから。

障害物の除去

仕事の前にこの質問から始める。 「チームがもっと仕事をしやすくするために、私はなにができるだろうか?」 チームを手助けする一つの方法は、障害物を取り除き、効率よく仕事ができるようにする。

ファシリテーション

会議や、会話には、ゴール、成果物、期待する結果が明確に定義されているべき。 ファシリテーションを行う際は、議論の内容や解決策について絶対に干渉しないのがルール。

コーチン

偉大なスクラムマスターが持つべき最も重要なスキルの一つ。 一度習得してしまえば、信じられないほど強力。 スクラムにおけるコーチングは、個人の成長だけでなく、チームの自己組織化、責任、オーナーシップにも焦点を当てる。

スクラムを始めるにあたって知っておくべきこと

スクラムの背景にあるダイナミクス(動力学)や原則を理解する必要がある。 以下はフェーズに合わせた事象と、スクラムマスターが行うこと。

障害物

スクラムマスターは、チームの障害をチームに気づかせて、自分たちで解決するように進める方法がある。 それを怠ることで、チームの秘書になってしまい、チームは誰かが問題を解決してくれるのを待つような自信のないグループになってしまう。

立ち往生

ある程度長い間スクラムをやっていて、良いスクラムチームではないが、問題に感じてる程でもないチームにある話で スクラムマスターはチームに何をすべきかをいうものではない。 場合によっては、そのようなスクラムマスターはチームから受け入れを拒否され、チームを去るしかなくなる。

責任

自己組織化もできているチームでは、ファシリテーションが役割を果たしてきたと言える。 次のアプローチに進むため、ミーティングの進行を任せるべき。 軽いタッチのファシリテーションの準備をし、チームに空間を与え、信頼する。 もし、間違った方向に議論が行った場合はコーチングをする。 ここではスクラムマスターは、注意深く耳を傾け、何が起こっているのかを把握し、必要なら手助けをできるように準備を整えておく。

偉大なスクラムマスターに必要なこと

それは「観察」になる。 チームの議論を促したり、チーム自身で決めるよう問いかけたり、問題解決を試みたりといったことをチームに代わってもらい、観察する。 全部なる早で問題解決してチームを作業に戻したい衝動に抵抗できれば、「自己組織化したチームを作る」という目標に大きく近づく。 観察する役割まで一歩下がり、どのアプローチをなぜとるかをチームが判断することを強く促すから。 傾聴することは、コミュニケーションや意思決定をする上で最も重要な要素の一つ。

偉大なスクラムマスターを目指すためのヒント

  • スクラムマスターの心理状態モデルのうち、どのアプローチを取るかを決める前に、観察する。
  • チーム自身で障害物を取り除くよう手助けすることを通じて、障害物を取り除く。
  • ファシリテーションとは、会議を開催したり、本を読んだり、研修に出ることだけではない。
  • コーチングで重要なのは、あなたの経験ではなく、良い質問をする能力。
  • スクラムマスター道の3つのレベルすべてに取り組む。開発チームのレベルのみにとどまってはいけない。
  • アジャイルスクラムは、偉大なスクラムマスターの働き方と生き方そのもの。

メタスキル

ある状況において意図的に取る態度、考え方、スタンスのこと。 具体的なスキルを引き出す、より抽象的なスキルのことを言う。

スクラムマスターのメタスキルは

  • ティーチング
  • 傾聴
  • 好奇心
  • 尊敬
  • 遊び心
  • 忍耐

状況に応じて適切なものを選び、意図的に使用することがとても大事。

クネビンフレームワーク

hirolaboratory.com

コンピタンス

理論だけではなく、スクラムマスターは気づきを得るために、幅広く物事を調べる必要がある。 カンファレンスに参加して、他の参加者や講演者とリアルな状況について話し合うのも1つの手。

  • 説明と経験の共有 アジャイルに関する概念をさまざまな相手に売り込んで、強く関心を引き、夢中にさせることができないといけない。 実際の経験がないと、特定のプラクティスや成果物を採用するのは難しい。

  • ファシリテーションコーチング 自分の経験は置いておいて、傾聴と好奇心のメタスキルを適用し、チームに決定してもらう。 チームを信じ、自分より良い解決策を思いつくように自分なりの解決策を考えつく手助けをする。

コアコンピタンス

3つの知識 - ビジネス知識 - チェンジマネジメント - 技術知識

どのコンピテンスを持っているか

について、どれが足りないかを考えていく。

チームビルディング

タックマンの集団発達モデルというのがある。

  • フォーミング(形成期)
  • ストーミング(混乱期)
  • ノーミング(統一期)
  • パフォーミング(機能期)
  • 変動

チームの機能不全

信頼の欠如

それぞれの人は、他人にはない専門性、特別な技術知識、業務領域のノウハウを持っていると信じている。

そのため、サイロ(外との断絶した世界や領域、中に閉じこもった状態)を守りたい。

衝突への恐怖

ニセモノの調和を取り繕う傾向がある。

領域ごとに分けているのに、議論に時間を使うのを避ける。

1つのユーザーストーリーに協力して取り組むなんて意味がない。コミュニケーションに不必要な混乱を生むと思っている。

コミットメントの不足

次のような言葉は低レベルの信頼の欠如によるもの。

スプリントの終わりまでに、何を終わらせられるかは言えない。何が起こるか分からないのだから。

自分の担当部分はすぐ終わるけど、他人の分はなんとも言えない。

説明責任の回避

スプリントの終わりには、できなかった理由をつけて例外扱いし、次のスプリントにも同じ量の仕事ができると計画する。

時々起こりうることではあるが、定期的に起こるなら、機能不全である。

結果への無関心

顧客に価値を届けるという目標に対して、担当範囲のコーディングやテストだけを終わらせるという関心しかない状態をなくす。

スクラムマスターのやること

達成したいことを明確にし、なぜ達成したいのかどのように達成するのか、計画の実現を目指すようにする。

チームの協定や、ワーキングアグリーメントを作成するように支援しないといけない。

守りの姿勢

チームが提案した時に守りに入ってしまうことがある。

例えば、2週間スプリントを1週間スプリントに変える時などは、変化を恐れて守りに入ったりするなど。

それを変えるための提案も、今の結果に満足することで守りに入る。

壁を作る

自分のアイデアを何度も繰り返して、他の人のいうことに耳を傾けない。

自分がやってるので、自分のやり方でやる。他の人がやる時はその人のやり方でいいよ、というようなことを言うこと。

直接的ではないが、最後は同じ結果になる。

これは、仕事のやり方がバラバラな個人の集まりとして働くことになる。

侮辱する

君何も分かってないね

とうようなことを言う。

これは非常に険悪なものに発展する。

責任

問題が起こると、頭の中の思考では解決策を考え始める。

順番に以下が頭の中で行われる。

  • 否認
  • 責任転嫁
  • 正当化
  • 回避
  • 義務
  • 放棄
  • 責任

解決: バグが報告された時、修正するだけでなく、再発防止に次回はどこを変えてみるかを議論する。

部族としての組織

スクラムバット

  • ステージ1 ほとんど起こらない。 ストリートギャングなどで起こるようなこと。 人生は最低だ。の文化のこと

  • ステージ2 アジャイルの環境では、移行の初期の段階でこのステージに陥る。

「自分の」人生は最低だ。に移行する。

このこときから、スクラムバットが発生する。

スクラムバットとは、スクラムを一部を取り入れてはいるものの、やっていない部分やうまくできていないところがあることを言う。

  • ステージ3 自分はすばらしい、でもあなたは違うフェーズ。

一人一人が成功体験を持つ必要がある。

このステージでは、人々は個人的な成果や肩書きが重要だと思っている。

自分は人よりよくがんばっているという感覚を持っている。

このステージのSMはチームを過小評価している。

  • ステージ4 チームとして一つの目標を持っていて、競争に興味がなくなるフェーズ。

人々は自分達は最高だと思っている。

チームは自己中心的ではなくなり、外に目を向け始める。

そのためには、個人として活躍するための十分な場を与え、十分に評価しなければ、チームは真にアジャイルの文化になる準備ができていないのでスクラムは失敗する。

重要なことは 1. 個人の評価よりもチームの成功の方 2. 一般的に、周囲と競う気持ちは弱まる 3. 自分達はすごくて、他の人たちを手助けもできる

  • ステージ5 これまでの続き。競争力は弱まる。

アジャイルコーチの中にはこのレベルで仕事をしている人がいる。

つまり、他のアジャイルコーチを競合とみなさない。

業界全体を良くしていこうという考えでいるため、お互いが協力し合い、市場を成長させる。

変化の実装

アジャイルの車輪は、変化のタイミングや理由が正しいか、判断するのに役立つエクササイズになります。

顧客満足、生産性、市場に出すまでの時間、チームの健康、チームのコラボレーション、チーム外とのコミュニケーション、継続的改善、効率性、品質、変化への反応、顧客からフィードバックを得る、デリバリーの予測可能性から成る。

半年後にはどこにいたいかの期待値を評価として、円の中央を最小として、パラメータをふってみる。

どこが改善点か見えてくるでしょう。

行動を変える

変化をエッジとして見る。

エッジとは、既知と未知の境界線。自分自身について知っていることの限界。

新たな行動、アイデア、視点を試す時はいつでも、エッジを超えている。

チームと個人が成長し、変化する限り、常に新天地と探索すべきエッジがある。

SMとしての役割は、あらゆる変化の中で乗り越える小さなエッジを理解し、個人、チーム、組織がエッジを乗り越える手助けをすること。

そうすると、SMの心理状態モデルのうち、最も適したアプローチはコーチングになる。

人々がエッジを乗り越える準備ができたら、いつでも手を差し伸べ、力の限り助けるべき。

変化を成功させるための8つのステップ

  • 危機意識を持つ

変化を必然にする。

人は痛みを感じるまで改善の必要性を感じない。

正当な動機と理由があれば、変化は起きる。

正直で透明性のあるものを提示していく。

  • チームをガイドする

アーリーアダプターに焦点をあて、1人では難しいことをチームの一員になってもらって乗り越えるように働きかける。

広範な人々を巻き込みたいなら、組織構造にとらわれるべきではない。

  • 変化のビジョン

変化のビジョンとその戦略を練る。

何円何百というアイディアを人々が理解できるよう、その変化について明確かつシンプルに説明できるようにする。

変化を推進するチームのメンバー全員が、5分以内に説明できるようにする。

  • 理解と了承

人々はさまざまな不安を抱えている。

置かれている状況も違えば、やり方を変えることの影響もさまざま。

優れた傾聴のスキル、状況把握、人々の情熱を引き出す能力が必要となる。

新しいアイデアを受け入れるのに時間がかかる人には、忍耐も必要となる。

  • 人々の行動を促す

チェンジマネジメントのこの部分は、SMがやることに近い。

人々の行動を促すために障害物を取り除く必要がある。

人々への感謝と称賛を忘れずに、変化に向けて行動していきましょう。

  • 短期の成功

成功を頻繁にアピールする。

長期的ビジョンや野心的なゴールを持つ。

ポジティブな雰囲気になる。

失敗を隠さずに、この瞬間を大事にすることを行う。

失敗を隠すことは、良からぬうわさが立つリスクにつながり、これまでの努力を台無しにしてしまう可能性がある。

  • 気を緩めない

望ましい状態に到達していないのに、あまりに早く「完了した」と認識してしまったために、変化が失敗に終わることがある。

まだ新しい状態が定着していないので、遅かれ早かれ以前の習慣に戻ってしまう。

しかるべき階段を越えたら、変化をする必要がなくなるわけではなく、完璧などない旅なので完了するということもない。

  • 新しい文化を創る

定着させること。

新しい働き方を組織の文化にとって不可欠なものにする。

フィードバックに基づいて計画を変えていくという言葉が出て来れば良い方向。

ポジティブさを高める

レトロスペクティブでは、基本的に褒めたり、いいところについて話し合う会にする。

この先続けたいことや、もっとやりたいことについて話すことに費やすようにする。

ネガティブな要素は、1つのネガティブイベントに対して、3〜5つほどのポジティブイベントが含まれるべきである。

ポジティブな出来事を見える化し、成功を祝う。

そして、どれだけ状況が厳しくても、パニックにならず、ポジティブさと笑顔を増やす。

ファシリテーション

ファシリテーションは、すべてのスクラムマスターのコアプラクティス。

ファシリテーションとは、議論の枠組みと流れを定義すること。

優れたファシリテーターは、柔軟でアジェンダを変更する準備ができている必要がある。

馬の熱量を把握し、それに応じてフォーマットを調整する必要がある。

やるべきこと

  1. ファシリテーターは、内容ではなく議論の枠組みに責任に持つ
  2. 開始前に各会議の明確な目的と成果物を定める
  3. 会議の目的とアウトカムを参加者と一緒にレビューする
  4. 会議の開始と終了の際に、チェックインアクティビティを行う
  5. パーキングロットについて説明し、使っていく
  6. 自分の計画に必要以上に執着しない。もしその計画がうまくいかないなら、状況やチームのニー時に合わせて変える
  7. 人々の理解を深め、さまざまな意見を得るため、議論の幅を広げたり、狭めたりする。

コーチン

すべてのスクラムマスターにとって最も重要なスキルの一つ。

自己認識と自己実現を呼び起こすこと。

創造的な解決策を考え出し、自分自身を成長させる目標を決める際に役立つ。

人の潜在能力を解き放ち、パフォーマンスを最大化する。

傾聴のスキルに注目する。

アドバイスを与えるのではなく、人々が自分自身の解決策を考え出す手助けをする。

独自の解決策を生み出すべきで、あなたの唯一できることは、鏡を調整して気づきを与え、新しい視点を見つけてもらうこと。

根本原因調査

  • 予測可能性 何が、どこから、いつ、誰が、なぜという質問を行う。 フィッシュボーン呼ばれる。
  • なぜなぜ5回
  • 品質が低い

まとめ

スクラムを行う上で必要な知識や、最低限の行動などの指針となる参考になった。

スクラム初心者や、僕のようなスクラムマスター未経験からスクラムをやるってなった時でもこの本を参考にすることで、ある程度スクラムのイメージはつくと思う。

これまで少し漠然としていたスクラム像が、当本を通して少し具体化したように思われる。

そもそも「論理的に考える」って何から始めればいいの?

こちらの本を読んだので感想を書こうかと思います。

概要

論理的思考はどこの場面でも使われる。

勉強の場でも、仕事の場でも、人とのおしゃべりの場でも。

人生を左右するような大きな分岐的になることもある。

論理的思考ができるかどうかで、その人の言葉の重みも変わるし、その後の人生にも大きく影響が出て来る。

本の進行

本自体は、登場人物同時の会話で進行していくため、非常に読みやすい。

会話なので、ところどころジョークが混じったり、状況の説明などが入るのが息抜きになって緩急づいた本になっている。

内容自体も、先生と生徒 のような構図で、生徒側に読者を置き換えることで感情移入も、情景も掴みやすい。

ある程度論理的思考について考えたり読んだりしてきた人であれば、スラスラと読めて、短期間で読める良いボリューム感だった。

内容

非常に分かりやすい。

先生役の登場人物が、生徒に対して、どういった場面で論理的思考が必要か、どういう考え方をすれば良いのかを3、4つ程提示するのだが

例題を出して、それに対して回答例もつけてくれていて、しかも図が差挟まっているので分かりやすい。

一つの例題に対して、2、30ページあるが文字量的にも、前述したように会話の部分もあるのでそこまで重くなく、スムーズに読み進められる。

議題

議題はいくつか用意されている。

  • 考えるための準備(考え始めのスタートとゴールを決める)
  • 逆から考える
  • 三段論法(演繹思考法)について
  • 帰納的に考える
  • 整理の仕方(表を使う)
  • 反例を用意する
  • 背理法について
  • 相手の主張を簡単に否定するコツ
  • 優柔不断を無くすための判断基準について
  • 重み付け
  • 説得力のある決め方(消去法)
  • 常識を疑う
  • ズルいことが考えられる人(盲点を見つけることができる人)

ワークショップ

この議題に対して、生徒役の人が答えて、正解に導かれていく。

その時に、生徒役の人は必死に答えを見つけようと考えるのだが、その時に自分もまずは考えてみるというのをやってみると良さそう。

本が相手となるワークショップができるような作りになっているのもとても良かった。

まとめ

基本的には、この本に書いてあることを実践するだけでもかなり論理的思考を再現できるような気がする。

しかし、実際に仕事の場で使おうと思うとそれなりに訓練が必要になってくる。

何度かこの本を流し読みでもいいので定期的に意識をより戻して、仕事の中でも意識できるようにしておくと良いだろうと思われる。

全く自分には論理的思考がないというような人でも、この本を一通りなぞることで、枠組みは掴めると思うので、地盤を固めるはじめの一歩としてはかなり良い本のような気がした。

みんなでアジャイル

はじめに

以下の方を読みました。

アジャイルについての本は、3〜4冊目くらいになります。

ある程度、アジャイルについての考えや実践を通して内省を行なったり、記事を読んだりしていたのもあり

薄らとアジャイルについての知識や行動について身についてきていました。

しかし、いろんな職能に当てはまるプラクティスゆえに、抽象的な概念が多く、なかなか効果を最大化するというようなスキルには変えにくいのもアジャイル

そう言うわけで、アジャイルについての本をどんどん読んでいこうという一環で読むことにしました。

本記事は、内容にはほぼ触れず、読んだ感想だけを書こうと思います。

感想

上記でも書いたように、いろんな職能に対して適用できるプラクティスとして、 アジャイルが存在していることが前提となります。

どうしてもエンジニアをしていると、開発に焦点が当たりがちになりますが、 開発以外にも適用することができます。

むしろ、開発以外にこそアジャイルを組み込まないと、 サービスの最大化を図ることができないのだと思いました。

アジャイルを取り込むことで

開発以外にアジャイルを取り込むことでどうなるか

多くは、サービスを取り囲む全員の向いている方向が定まるというのがあります。

それは何に繋がるか

それぞれの職能でやるべきことが、一点に向かって絞り込まれていくというところになります。

チーム横断でのコンテキストの共有や、価値基準についての話を行うことができることで、 より早い理想の実現を可能にしていくのがアジャイルの基本となってきます。

アジャイルは必須か

どんなチームにもアジャイルが必要かという疑問については、「完璧なアジャイルは必須ではない」というのが答えになります。

アジャイルというのは取り組みのことであり、こういったことをすれば良いといったプラクティスがあるだけで、それに従うことが前に進むことに繋がるわけではないということです。

つまり、アジャイルにおける考え方、「顧客を引き込む」、「必要性について話す」、「全ての準備が整った上での開発ができている」など、必要な概念を必要な分だけ取り入れればいいのです。

アジャイルを取り入れるから、全ての考えに従う必要があるという考えはいらず、顧客と対話ができているなら、それはすでにアジャイルに取り組んでいると言えたり、マーケティングやセールスと方向性を共にできているのであれば、それはアジャイルが導入されていることにつながります。

なので、それらが必要ない仕事については導入する必要がないという認識になります。

例えば、必要なものが明確で、これが欲しいというのが決まっているものについてはアジャイルというより、どう実現するか、だけに焦点を当てればいいので、実現工程にのみ部分的なアジャイルで事足ります。

そして、アジャイルを行うことも、そのチームの構成や、人、組織体系によって行うことが異なるので、「これ」といった完璧なアジャイルが用意されているのではなく、アジャイルの考えに則ったチームごとのやることを選定していくことが必要になるかと思います。

「なぜ」、「どのように」、「どのようなもの」を洗い出し、話し合う。

それができるだけでも、十分アジャイルを取り込んでいると言えるでしょう。

方向性が全く見当違いの職能チームで構成されていたら

方向性が定まらなければ、話し合いもできないかもしれません。

そう言った時に必要なのが、方向性の統一化になります。

これも結局概念で、方法は自分で編み出す他ないです。

ただ、この本にはこうするといいよといった示唆はあるので、実践するだけでも効果を得られることでしょう。

そういったこともあり、アジャイルの導入への最初の一歩を踏み出すには、この本は分量、内容共に手軽な感じがあります。

まとめ

アジャイルの導入は個人的にはすごくワクワクする話です。

これまで、沈澱していた底にある物を掘り起こし、再びそこに新しい風を吹き起こすような新鮮さを感じます。

しかし、それはコップの中のココアのようなスプーン一振りで混ざり合うようなものではなく

針金のような細いもので、プールの水を幾度となくかき回す必要があるほど大きく労力と時間がかかるものかもしれません。

そういった意味で、アジャイルというのは表面的なもので終わってしまうことが多いのかなという印象を受けました。

僕個人は今のプロダクトでアジャイルを採用していて、まだまだ未熟なアジャイルをしているという自覚はありますが

その中でも、少しずつ本にあるようなことを試してもいいし、アジャイルの概念に則っとって自分のやり方を試してみるなど、経験を積んでいければと思います。

Go言語 プログラミングエッセンス

概要

自分は実務でのGoでの開発はほぼ皆無に等しく、

サービス的にはGoを使ってるものの、レビューすることはあれど、自分が書くということはほぼしてませんでした。

そのため、自分でもGoを書く練習をしようと思い、本書を買いました。

Goの言語的な使い方について細かく書いてあることもあり、中途半端に学んでいた自分にとっては有益な本でした。

Goの言語仕様

Goの言語的な設計や考えなどが説明されており

Goによるプログラムはもちろん、コマンドや機能、テストについても書かれています。

コマンドは特に、開発で利用できるものが多くあり、自動生成コマンドであったりパフォーマンス計測であったり、インストールのコマンドについても細かく書いてあるので、一読の価値がありました。

文法

Goの文法的なところも少し説明があります。

僕は文法は他のところで学んでいたり、別言語での経験はあるので、ある程度飛ばしつつ読みましたが、初めてプログラミング言語を触るという人は参考になるかと思います。

Goだからといって特別なことはなく、純粋に文法を学んでいくにも素直な説明なので入ってきやすいかと思います。

開発

Goを利用してCLIの開発とWebアプリケーションの開発が紹介されています。

特によく使われているフレームワークやライブラリの紹介があるのは嬉しかったです。

慣れていない人からするとどんなライブラリを使えばいいとかの勘所がないので、長いことGoに触れてきた方の紹介としてライブラリが紹介されていると心強いですね。

そして、Webフレームワークなども紹介されていますが、基本的にGoは言語としての開発力が高く、フレームワークと言ってもGo言語の拡張としてのものしかないようで、得にルーティングの部分を吸収してくれる役割が大きいようです。

そう言った点もあり、どこにどんなフレームワークが良いかといった技術選定も、各フレームワークがどういった思想や機能を兼ね備えてるかを理解するのに良かったです。

並行処理

もちろん、並行処理についても1章使っており

channelを利用した並行処理、スロットルによる並列処理の制限など

少し学ぶのに難しい部分についてもサンプルコードと一緒に書かれているのは良かったです。

サンプルコードも何百行もあるものではなく、焦点を絞った形になっているのでコードも理解しやすいです。

ただ、1行1行の処理の説明はないので、ある程度独学で学んだ人が書き方を学ぶといった形に適しているかと思いました。

一部Go言語の仕様っぽい箇所があり、なぜそう書けるのか分からず悩む箇所がありました。

それも、素直にそう書くんだと受け入れる気持ちで読めば、何度か読んでいるうちに恐らく馴染んでくるでしょう。

実際のコードは、URLを元にスクレイピングして情報を取得するなどを想定して作られているのでイメージはしやすいかと思います。

テスト

Table-Driven-Tests を元にテーブルテストを書く紹介があります。

テストライブラリがGo言語の仕様で用意されていたりするので、そちらを用いてのテストをしています。

その中でいろんなテクニックも紹介されており、テストの効率的な実行の仕方や、前処理後処理の書き方なども学ぶことができました。

またこちらも並列テストの紹介があり、テストの速度などを上げるための仕方もサンプルコードがあります。

モックを使ったテストの紹介がなかったのが、少し気がかりでしたが、学ぶことが多い章でした。

計測

ベンチマークを取る機能が言語仕様として備わってるのは結構珍しいらしく、手法を紹介されていました。

僕自身は普段はあまりベンチマークを取るということを意識してはいなかったので、少しイメージがしにくいところではありましたが、そもそもベンチマークがとれるということも知らなかったので、知識としてあっても良いと思いました。

これからGoを触っていく中でベンチマークも取ることがあるかもしれないですしね。

まとめ

まとめとしては、とても学びが多い本でした。

もちろん既に知っていることや、あまり自分には必要なさそうな箇所もあったとは思いますが

いずれにしても再確認や、知識として知っておくというだけでも読んで良かったと思える本でした。

まだまだGoを始めて日が浅い自分なので、こういったベストプラクティスなどをまとめてもらえるのは、すごく有益でした。

個人開発ではGoを触っているので、もう一回読みながら書いてるコードに適用していけたらと思います。

Team Topologies

はじめに

チームトポロジーというのは、チームにおける形成図のようなものを指して、最適な組織構成とは何かを定義し、必要に応じて適用することで、チームの開発、運用、デリバリーを早く行えるようにする考え方を示している。

この本には、主に各チームや機能の定義、どういった概念かの説明を行った上で

どういったフェーズに当てはまれば良いか、どういった適用の仕方が良いかを解説する。

チームトポロジーとは

チームは常に未完成だが、最善を尽くした状態でもある。

チームは独立して存在しているわけではなく、熱意を持ったメンバーで構成し、自律的で、長続きさせるべきである。

そして、顧客に価値を届けるためにチームのことを考え、チームを進化させなければいけない。

そのための明快なパターンを提供することが、チームトポロジーである。

チーム構造を最適化する方法を見つけ出そうと奮闘している組織や、チーム設計が特にビジネスアウトカムやソフトウェアに影響を与えることにまだ気づいていない組織に役に立つ。

チームトポロジーの考え

以下の4つの基本的なチーム - ストリームアラインドチーム - プラットフォームチーム - イネイブリングチーム - コンプリケイテッド・サブシステムチーム

以下の3つのインタラクションモード - コラボレーション - X-as-a-Service - ファシリテーション

チームトポロジーでは、技術や組織の成熟に応じてどう進化するかに目を向けている。

適応型モデルを重視し、チーム間の相互関係に積極的に優先順位をつけることで

ソフトウェアの比重が高い現代の企業がビジネスや技術の観点で戦略変更が必要になったことを感知するための、特定の技術に依存しない重要なメカニズムを提供する。

つまり、人間的なアプローチも重視しているということ。

同形力

組織の本当のコミュニケーションパスと、結果として得られるソフトウェアアーキテクチャーには強い相関関係がある。

理論上、理想的なシステムアーキテクチャーでも、組織モデルに合わなければ変えなければならない。

認知負荷

人間の認知容量には限界がある。

同時に、チームにも認知容量が存在する。

しかし、担当割り当ての際に、この認知負荷について議論されることは滅多にない。

認知負荷とはどんなもので、定量化することが難しいからだ。

チームへの要求というのは日々増え続ける。

だが、新規サービスの開発は、チームの時間は全て支えて、認知負荷が何もないかのように計画されることが多い。

チームは既存のサービスの修正や拡張も求められるが、それらは無視されているからだ。

これにより、チームのモチベーションの低下などが発生しうる。

私たちは、チームを最優先して、認知負荷を制限するよう呼びかけていく必要がある。

認知負荷をしっかり考えることは、チームサイズを決めたり、責任を割り当てたり、他のチームとの境界を設定したりする上で、とても役に立つ。

チームの認知負荷を制限し、チーム間のコミュニケーションを明確に設計する必要がある。

チームトポロジーのゴールは、コラボレーションが必要な場所やタイミング、実行に集中してコミュニケーションのオーバヘッドを減らすべき場所やタイミングを、組織が適応しながら動的に見つけられるようなアプローチとメンタルツールを提供すること。

チーム内のフローをよくするソフトウェアアーキテクチャ

チームの編成前に、どんなソフトウェアアーキテクチャが必要かを理解する必要がある。

コミュニケーションパスとインセンティブがソフトウェアアーキテクチャーを決定づけてしまうからだ。

そのためにはソフトウェアアーキテクチャのグッドプラクティスに従うと良い。

  • 疎結合
  • 高凝集性
  • 明確かつ適切なバージョン互換性
  • 明確かつ適切なチーム横断でのテスト実行

ものごとを分離し、チーム内にとどめておくことが重要。

組織設計には技術的専門知識が必要

アーキテクチャとチーム編成の間にある自己相似の力が現実のものであることを受け入れるなら、エンジニアリングチームに強い影響を持つのだということを受け入れなければいけない。

チームの編成

偶発的、行き当たりばったりでチームを編成するのではなく、断続的にチームを設計する必要がある。

このような設計によるチーム構造のことをチームトポロジーと呼ぶ。

しっかりと思慮深く練られたチーム構成は成功する確率が高い。

フィーチャーチーム

職能横断型かつコンポーネント横断型のチームのこと。

一貫で、顧客に提供、使用状況、パフォーマンスを監視できるチームを指す。

しかし、自給自足、つまり他のチームを待つことなく機能を本番にリリースできる場合に限る。

エンジニアリングの成熟度が高くないと、ワークフローの自動化やボーイスカウトルールに従わなかったりなどが発生する。

プロダクトチーム

基本的にはフィーチャーチームと同じだが、1つかそれ以上のプロダクトの機能全体を担当するという点が異なる。

インフラ、プラットフォーム、テスト環境、ビルドシステム、デリバリーパイプラインなどに依存する。

ソフトウェア開発の構築と運用はとても不確実性が高いため、スケジュールに沿って、同じ仕事のストリームのなかで複数のチームが調整を行うのは難しい。

そのため、ブロッキングが発生してしまう。

ノンブロッキングにするには、セルフサービス型の能力という形を取ることが多い。

テスト環境の洗い出し、デプロイパイプラインの作成、監視など。

しかし、プロダクトチームが自律性を満たしていないシステムの一部でありながら、早くデリバリーするようにプレッシャーをかけられると摩擦が増えていく。

クラウドチーム

プロダクトチームは、必要に応じて新しいイメージやテンプレートを作り、自分達の環境やリソースをプロビジョニングできる自立性が必要になる。

そして、クラウドチームはそのプロビジョニングプロセスを引き続き担当し、

  • 必要な管理
  • ポリシーの適用
  • 監視

を確実に行えるようにする。

しかし、クラウドチームはプロダクトチームのニーズと適切なリスクおよびコンプライアンス管理のニーズに合うような、高品質のセルフサービスを提供することに注力すべきなのである。

4つの基本的なチームタイプ

ストリームアラインドチーム

価値のある単一の仕事のストリームに沿って働くチームのこと。

ストリームとは

機能一式のこともある

ユーザージャーニーや、ユーザーペルソナの一つのような場合もある

顧客やユーザーに価値を届けられるように、チームに権限が委譲されている

つまり、他のチームへの引き継ぎが発生しない

どのストリームでも、長期的に維持される仕事のポートフォリオもしくは、プログラムの一部として、予算が割り当てられる

これまでの、顧客からの大きな要望、複数の顧客からの小さな要望を、プロジェクトが承認され予算が割り当てられ、フロント、バック、データベースなどいくつかのチームに割り振られ、既存のバックログに追加されるというやり方とは全然異なる。

期待されるふるまいとしては以下のようなものがある。

  • フィーチャーデリバリーの安定したフローを作ること
  • 最新の変更へのフィードバックに基づいてすばやく軌道修正できる
  • プロダクトの進化に実験的なアプローチを用い、常に学んで適応する
  • 他のチームへの引き継ぎを最小限にする(理想はゼロ)
  • このチームが実現した変更フローの安定性と、技術面およびチームの健全性の観点での補助的なメトリクスで評価される
  • コードの品質変化(技術的負債)に対応するための時間を持たなければならない
  • 積極的かつ定期的に支援を受ける他のチームタイプと連携する
  • メンバーは「自律」「熟達」「目的」を達成しようとしているか、達成していると感じる

イネイブリングチーム

複数のストリームアラインドチームの支援を行う

適切なツール、プラクティス、フレームワークなどのアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案などを行う

協調的な性格が強く、ストリームアラインドチームの課題や不足点を理解しようとする

サーバントリーダーシップとも考えられる

期待されるふるまい

  • ストリームアラインドチームのニーズを探索し、定期的にチェックポイントを設け、より多くのコラボレーションが必要になるタイミングについて合意する
  • 専門領域での新しいアプローチ、ツール、プラクティスについて先んじる。
  • 技術的な良いニュースも悪いニュースも伝える。技術的なライフサイクルマネジメントを支援するため
  • ストリームアラインドチームが直接使うのが難しい外部(もしくは内部)サービスのプロキシーとしてふるまうこともある
  • ストリームアラインドチームを横断した学習も促進するため、組織内の適切な情報共有を促すキュレーターとして活動する

ストリームアラインドチームへのインタラクションは、短期間(数週間〜数ヶ月)にとどめる方が良い。

新しいスキルを身につけたら、日常的なインタラクションはやめ、別のチームにフォーカスするようにする。

CoP(コミュニティオブプラクティス)も、同じように知識を広めるためのチーム。

イネイブリングチームが短期的に目的を達成するものとしたら、CoPは長期的に広く行う部隊。

コンプリケイテッド・サブシステムチーム

複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らすことにある

習得や育成の難しいスキルや専門能力を活かして、担当するサブシステムの複雑さに取り組む

期待されるふるまい

  • 担当するサブシステムの開発状況を意識して、適切にふるまう。初期の探索や開発の段階では、ストリームアラインドチームと密接にコラボレーションする。サブシステムが安定してきたら、インタラクションを減らし、サブシステムのインターフェイス、機能の使用状況と進化に集中する
  • サブシステムのデリバリー速度と品質は、ストリームアラインドチームが開発した場合(分割の判断をする前)より明らかに向上する
  • サブシステムを利用するストリームアラインドチームのニーズを尊重し、適切に優先順位をつけて変更をデリバリーする

プラットフォームチーム

ストリームアラインドチームが自律的に仕事を届けられるようにすることで、ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。

ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる。

提供するサービスが目的に一致し、信頼性が高く、使いやすいプロダクトになるように扱う必要がある。

基本的に、少数のサービスを高い品質で提供することに集中する必要がある。

期待されるふるまい

ストリームアラインドチームが必要とする下位の内部サービスを提供することで認知負荷を減らし、ストリームアラインドチームがより上位のサービスや機能を提供できるようにする。

そのために以下のことを行う

  1. ストリームアラインドチームのニーズを理解する
  2. 高速プロトタイピングの手法を使い、ストリームアラインドチームのメンバーを巻き込んで何がうまくいって何がうまくいかないかのフィードバックを素早く得る。
  3. プラットフォームをプロダクトとして扱い、ユーザビリティと信頼性に強くフォーカスする。定期的にサービスが目的にあってるか、使いやすいかを検査する
  4. 手本を示すことでリードする。可能な限りストリームアラインドチームと一緒に使い、下位のプラットフォームを利用する
  5. 新しい内部向けサービスの採用には他の新技術と同じように時間がかかること、テクノロジー採用ライフサイクルの採用曲線に沿って進化することを理解する。

プラットフォームをプロダクトやサービスのように管理する

プラットフォームにはユーザー(開発チーム)がいて、運用対応の時間(開発チームが使う時間)も決まっている。

開発チームがなるべく効果的に働けるようにするには、次のことを行う必要がある。

  1. プラットフォームを稼働中のシステムとして扱い、ダウンタイムを計画し管理する。
  2. ソフトウェアプロダクトマネジメントサービスマネジメントのテクニックを使う。

プラットフォームチームの主要顧客はプロダクトチームになる。

運用対応の時間を決め、インシデントやサポートの対応期限を定め、プラットフォームサポートのオンコールのローテーションを設定、適切なコミュニケーションチャネルを用意、インシデントや計画買いダウンタイムを管理を行う必要がある。

開発チームと定期的に話し合いを行い、何が必要かを理解しようとする。

機能の利用度合いをメトリクスとして追跡し、対話と優先度設定に利用したりもする。

モノリス

アプリケーションモノリス

多くの依存関係や責任を持つ単一かつ巨大なアプリケーションで、多くの錆巣やさまざまなユーザージャーニーを公開しているもの。

ユーザーはデプロイの間、アプリケーションを使えない。

本番環境相当の環境でテストしていたとしても、そのあと変わってしまっているため、予期せぬ問題に悩まされる。

データベース結合モノリス

同一のデータベーススキーマと結合している複数のアプリケーションやサービスから構成される。

それぞれ別々に変更、テスト、デプロイが難しい。

データベースをコアのビジネスのエンジンと考えている場合に発生する。

人手が足りていないことが多く、デリバリーにおける大きなボトルネックになる。

モノリシックビルド

新バージョンのために、単一の巨大な継続的インテグレーションでビルドを行う。

アプリケーションモノリスが、モノリシックビルドをもたらすが、小規模なサービスでも同じ問題は起こりうる。

コンポーネント間の依存関係を管理する標準的な仕組みを使うのではなく、コードベース全体をビルドするようなビルドスクリプトになっている場合。

モノシリックリリース

全てをまとめてリリースする

小さなコンポーネントをまとめてリリースする

サービスのモックは使わずに、共有の固定環境でしかテストできない場合

コンポーネントの最新バージョンをまとめて同一の環境に導入することになる。

コンポーネント一式をひとかたまりとしてデプロイすることで、テストしたものが本番環境でも実行されるという確証を得る。

QAチームによってテストを担当される場合もあるが、キャパシティが限られていて、複数のサービスの変更をまとめて行うことが理にかなっていると考えるため。

モノシリックモデル

単一のドメイン言語と表現(フォーマット)を多くのさまざまなコンテキストに強制的に適用しようとするソフトウェアのこと。

小さな組織では、チームが明示的に同意している場合であれば、この手の一貫性を重視するのは理にかなっている。

だが、組織内のチームやドメインが片手で収まらない数になると、意図せずアーキテクチャーや実装の制約になる可能性がある。

モノリシック思考

チームの「画一的」な考え方のこと。

技術面やチーム間の実装アプローチのばらつきを最小限にするための標準化をおこなう。

しかし、優れたエンジニアは新しい技術を学ぶことができるし、学習したがる。

そういった機会を単一の技術スタックやツールを強制し、チームの選択の自由を奪う。

仕事で適切なツールを使う能力に大きな悪影響を及ぼし、モチベーションを阻害したりもする。

モノリシックワークスペース

地理的に同じ場所にいるすべてのチームや個人に適用する単一のオフィスレイアウトのパターンのこと。

オープンプランオフィスがコラボレーションを促進するという通説もある。

だが、採用した2つの組織での調査の結果、それは否定されていて、対面でのやりとりが大幅に減少し、電子的なやりとりが増えたのだ。

それは、場所を同じにするだけでなく、目的を同じにすることによるものだ。

リスク

継続的デリバリーができているかにも大きく影響を与える。

疎結合のシステムアーキテクチャのもとで継続的デリバリーが実現できているのであれば、小さな変更を頻繁にデプロイするリスクは実際に減少する。

ユーザーの数によって許容できるリスクもある。

数百万の無料ユーザーと、数百人の有償ユーザーを仮定したとき

数百万人に影響のあるリスクは潜在有償ユーザーの損失が大きいが

数百人の有償ユーザーのみに影響がある場合、個別対応なども不可能ではないと考えると、優先度としては下がったりもする。

3つのチームインタラクションモード

以下の3つのインタラクションモードの組み合わせが多くの企業に必要。

1つのチームが2つの異なるチームに対して別のインタラクションモードを利用することもある。

どのチームがどのチームに対して、どのインタラクションモードをすれば良いか、何を期待されているだろうかということを意識するようにならなければならない。

それぞれの定義から書いて、それぞれの立ち振る舞いを書いていこうと思う。

定義

  • コラボレーション 2チームが一定期間密接な作業をすることで、新しいパターンや手法や制限を発見する。 責任は曖昧になるが、問題を素早く解決し、素早く学習を促進させる。

  • X-as-a-Service 一方のチームが別のチームから「サービスとして」提供されたもの(サービスやAPIなど)を使用する。 責任は明確に定義されている。利用する側のチームはすばやいデリバリーが可能になる。 サービスの提供者はいかに利用しやすくするかを目指す。

  • ファシリテーション 一方のチームが、別のチームが新しいアプローチを学習したり習得したりするのを一定期間支援する。 ファシリテーションを行う側のチームは相手チームを早く独り立ちさせることを目標として、ファシリテーションをされる側のチームは学習に対してオープンな態度を取る。

コラボレーションモード

イノベーションとすばやい探索を行う。

しかし、境界は曖昧である。

主に、やることとしては他のチームとの協業である。

新しいものをいち早く取り込み、他のチームへ展開する役割を果たす。

異なるスキルの人たちで構築されたチームによって運用され、さまざまな経験や知識を融合して、難しい問題解決にアプローチする。

他のチームへの学習を促すのもこのチームの役割である。

そして、チーム間の協力がほぼ全面的なのを示す。

異なるスキル感のチームが二つ存在していても、一つのチームとしてみなす。

重点分野と責任範囲の重なりが少ない場合でも、多い場合でも全体的なアウトカムに対して共同責任を負うことになる。

コラボレーションという行為が、責任境界を曖昧にするためだ。

そのため、コラボレーション中においては、認知負荷はずっと高くなる。

他のチームの学習において責任を伴う形で行う必要があるからだ。

これはオーバーヘッドが高くなることを示唆する。

しかし、新しいプラクティスを学ぶ機会にもなり、2つのチームのインタラクションを起こすことで、一緒に働くことにより有効性を高めることができる。

そのため、チーム間の摩擦は全くなくすか、極力少なくする努力は必要になってくる。

X-as-a-Serviceモード

あまり、手間をかけずに「まずは動く」コードライブラリ、コンポーネントAPI、プラットフォームを必要とするチームがいるという状況に適している。

他のチームに使われるような場合である。

システム開発の後期フェーズや、新しいアプローチの探索より、こちらのアプローチが必要とされる時期に効力を発揮する。

これにより、デリバリーチームは自分達の仕事のコアでない側面について理解する必要がなくなり、よりすばやいデリバリーを可能にする。

認知負荷の観点では、より低いものになる。

これは、優れたクリーンなAPIがあるためだ。

そのかわり、デベロッパーエクスペリエンス(DevEx)は非常に魅力的なものにしなければならない。

提供されるサービスは、使用、テスト、導入、デバッグが容易である必要がある。

ファシリテーションモード

1つ以上のチームが、別チームから積極的に作業の一部をファシリテーションまたは、コーチしてもらう場合に適している。

主に、イネイブリングチームにより運用される。

他チームの支援と能力を提供し、生産性と有効性を高める助けとなる。

他チームが使用している既存のコンポーネントやサービスのギャップや不整合を発見することもある。

そのため、どちらかというと、主要なソフトウェアシステムや付随するコンポーネントやプラットフォームの構築は行わず、それぞれの構築を行うチーム間のインタラクションの品質に注目する。

チーム間のコミュニケーションを、システムが求めるアーキテクチャに基づいて定義し、明確化するのに役立つ。

必要なインタラクションモード

チームが達成すべきことによって、必要なインタラクションモードは異なる。

最終的には、特定の理由でチームインタラクションがコラボレーションとX-as-a-Serviceの間を行き来することを期待される。

そうすることで組織はアジリティを獲得できる。

多様なトポロジーと多様なチームインタラクションは、組織の各所での目的や状況に応じて、それぞれのタイミングで進化させなければいけない。

そのためには、「自分達は何かを発見しようとしているのか?」「どれくらいの速さで?」といった自問をしなければいけない。

組織のチームトポロジーは、数ヶ月にわたりゆっくり変化するのだ。

チームトポロジーの変化のきっかけ

兆候としてあるのが以下 - スタートアップ企業が成長し、15人を超える - 1チームの変更により、他のたくさんのチームが長く待たされる - システム内の特定のコンポーネントやワークフローへの変更は、多忙だろうと不在だろうと、いつも決まって同じ人に割り当てられる。 - チームメンバーはドキュメントの不足に不満を持っている。

これは「今優先すべき仕事は何か」ではなく「分かっているのは誰か」に計画が左右されることによる兆候になる。

これが常態化すると、個人のモチベーションに悪影響を与える可能性がある。

そして、結果としてシステムの大きさやコードの大きさが、大きくなりすぎていることに全体像を把握しきれなくなって初めて気が付くようになる。

また、兆候としてあがる側面に

  • デリバリーのリズムが遅くなり始めている

ということがある。

  • リリースに時間がかかるようになった
  • チームのベロシティやスループットのメトリクスが、1年前と比べて明らかに低下しているという現象
  • デリバリープロセスについて、メンバーが手数の多さに不満が出てくる

モダンでハイパフォーマンスな組織になる3つの方法

  • システム思考: 組織のごく一部だけでなく、全体の早いフローを最適化する
  • フィードバックループ: 運用部門からの情報と指導による開発
  • 継続的な実験と学習の文化: すべてのチームインタラクションに対するセンシングとフィードバック

OpsとDevの強力なコミュニケーション経路に依存する。

つまり、OpsとDevを同じチームに配置するか、少なくとも同じ変更ストリームに沿って仕事をしているストリームアラインドチームにペアを組ませて、運用上のインシデントにスウォーミングさせること。

まとめ

この本には、すごく丁寧に各チームと機能や振る舞いの説明があった。

かなり大きな組織になっていかないと適用が難しいようなところもあるかもしれない。

それこそ、何チームにも渡って一つのサービスを運用し、これからの拡大を行なっていく見通しを立てるには良いかもしれないが、まだ100人規模などの組織、かつ開発チームも1つか2つといった状況下ですぐに適用できるかと言えば、そこまでな気がする。

しかし、チームがどうあれば良いか、どういうフェーズでどういう動きが求められるかなどの考えを知っておくことは、今後組織を形成する際の参考にはなるだろうと思う。

チームビルディングの一つの基盤としての考え方には、すごく寄与するのではないかと感じた。