エンジニアリング組織論への招待 Chapter4 - 読書メモ

エンジニアリング組織論への招待

目次

• Chapter1：思考のリファクタリング
• Chapter2：メンタリングの技術
• Chapter3：アジャイルなチームの原則
• Chapter4：学習する組織と不確実性マネジメント
• Chapter5：技術組織の力学とアーキテクチャ

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Chapter4：学習する組織と不確実性マネジメント

いかにして不確実性を管理するか

• 不確実性をマネジメントするには、不確実な要素をリストアップして、それらを比較する
  • インパクトの大きい順に対処していく

スケジュール予測と不確実性

スケジュールマネジメントの基礎

• スケジュールマネジメントとは次の3つに注目して改善を行うマネジメント
  • 制約スラックを削減する
  • 見積もりの予測可能性を上げる
  • プロジェクトバッファの消費を可視化し改善する
• 出来る限り早く「いつリリースされるのか」という時間の精度を上げる
• 

制約スラックとクリティカルパス

• 制約スラック
  • 依存関係を考慮した上で、発生してしまう無駄
• クリティカルパス
  • 依存関係から導かれるスケジュール遅延の原因となる作業の流れ
• 
• 成約スラックを削減するには？
  • 「リソース制約」を取り外す
    • 「この作業はXさんにしかできない」といった属人化した作業
  • 「依存制約」を取り外す
    • 「2つの作業を同時に行えない」といった作業の依存関係

悲観的見積りと楽観的見積り

• プリンシパル・エージェント理論
  • 経済における人間関係を「依頼者」と「代理人」との契約の束として捉える考え方
  • 「依頼者」と「代理人」における情報の非対称性により、「悲観的見積り」や「楽観的見積り」が生じてしまう

スケジュール不安の見える化

• 「間に合うか、間に合わないか」ではなく「スケジュール予測が収束していくかどうか」を管理する
• CCPM
  • スケジュール不確実性の削減をプロジェクトバッファの消費という形で「見える化」する
  • 
• 多点見積り
  • 個別のタスクに対して複数パターンの見積りを行い、タスクごとの不安を洗い出す
  • 
• 個別の不安量がわかったら
  • 「不安なタスクの順に問題解決をする」ことで、スケジュールマネジメントを有利に進める
  • 「不安の大きいタスク」と「不安の小さいタスク」にタスク自体を分割する
    • 「不安部分のみを切り出して」実施することが出来る
• 不安の原因を取り除く相対見積り
  • 

計画でなく実績から予測する

• 小さくスプリントを繰り返す
  • 同じ様なタイムボックスを繰り返すことで、実績から将来の予測を行いやすくする
• ヴェロシティと生産性
  • ヴェロシティが多い ≠ 生産性が高い
• ヴェロシティを用いたスケジュールマネジメント
  • ヴェロシティの平均値・偏差 → 最悪値・最高値 → 完了予定を推定

要求粒度と不確実性

• 作る工程よりも「何を作るか」が決まっていく過程の方が不確実性をもっていてブレ幅が大きい
  • スケジュールマネジメントには要求が詳細化されていく過程もマネジメントする必要がある
• ボトルネックを探してスループットを上げる
  • 「プロダクト」には完了がない
  • 機能が要求されてから価値が生まれるまでの「川の流れ」を見る必要がある
  • バリューストリーム

スケジュール不安はコントロールできる

• 不確実性をリリース予測の幅として表現する
  • スケジュール不安が可視化できる
    • 可視化できればコントロールできる

要求の作り方とマーケット不安

スケジュール不安とマーケット不安の対称性

• 
• スコープバッファの成立条件
  • 優先順位の高い機能ごとに完了する
• プロダクトに最初に触る顧客
  • プロダクトオーナー
  • プロダクトに触れることで「目的不確実性」を減少させる
• ユーザーストーリー
  • 各機能を顧客にとっての物語となるよう分解したもの
  • 「XXXは、XXXすることができる、これによってXXXできるからだ。」

マーケット不安はいつ削減できるか

• 安いコストで仮説を検証していき、不確実性が十分に下がったら大きな予算をかける
  • 「仮説」
    • 直感的に少ない断片情報だけから「このようにしたらビジネスが成立する」というビジネスモデル全体
  • 「検証」
    • 「仮説として成立しているか」を精査し、その後に行うアクションの全て
• 価値と不確実性
  • 機能の優先順位を考えるときは、価値とリスクのマトリクスに分類する
  • 
• リーンキャンバス
  • 仮説が仮説として成立するためには、ビジネスが成立してできた後のイメージが重要
  • 仮説を明らかにするためのフォーマット
    • 1：顧客の課題「どんな痛み・ニーズを感じているか」
    • 2：顧客セグメント「誰がどの位それを感じているか」
    • 3：独自の価値「他にはない独自の価値はなにか」
    • 4：解決策「どのようにその痛みを解決するか」
    • 5：チャネル「どこから顧客をどのくらいの値段でつれてくるか」
    • 6：収益の流れ「お金はいつどのようにいくら支払ってもらうか」
    • 7：コスト構造「売上に対してどんなコストがどれだけかかるか」
    • 8：測定項目「何がどれくらいなら上手くいっているか」
    • 9：競合優位性「なぜ自分たちがそれをやると上手くいくのか」

スクラムと不安に向き合う振り返り

• スクラム
  • 「役割の整理」と「いつどんな会議を開くか」をまとめたもの
  • いつどのようにチームが課題と不安に向き合うのかを測定し、改善を行うためのタイミングを矯正するためのフレームワーク
  • 「不安への向き合い方」をチームが学習するための方法論
• スクラムにおける役割
  • プロダクトオーナー
    • チームのROIを最大化させるため、ビジネス上の要件からプロダクトバックログを作成する
    • プロダクトバックログ
      • ストーリーを優先順位に並べたもの
  • 開発チーム
    • プロダクトバックログに従ってどのように作るべきかの意思決定を行う
  • スクラムマスター
    • プロダクトオーナーと開発チームの間に存在する「ボトルネック」を解消する
• スクラムにおけるイベント
  • スプリント計画
    • プロダクトバックログを実現可能なスプリントバックログに変換する
  • デイリースクラム
    • 前日まで課題やその日やることを簡潔に共有する
  • スプリントレビュー
    • プロダクトオーナーがインクリメントをレビューする
  • レトロスペクティブ
    • 次に向けての改善アクションを決める
  • 

	Whatの検査	Howの検査	日々の検査
Plan	スプリント計画	スプリント計画	デイリースクラム
Do	スプリント	スプリント	その日の作業
See	スプリントレビュー	レトロスペクティブ	デイリースクラム
対象	インクリメント	プロセス	前日までの作業

どこに向かって、どのように振り返るか

• プロダクトチームにとって振り返るべきゴールとは
  • プロダクトの仮説が検証され、ビジネスが発展していくこと
  • ゴールの設定と認識のためのフレームワーク
    • 「インセプションデッキ」
• 振り返りの流れ
  • 0：ゴール再認識
  • 1：テーマ設定
  • 2：現状整理
  • 3：よかった探し
  • 4：問題の洗い出し
  • 5：問題の深堀り
  • 6：対策の決定

不安を知りチームマスタリーを得る

• チームマスタリーを得ている状態
  • チームが自分たち自身の手によって広い視野での問題解決を進めることができる状態
  • 自己組織化された状態

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 Chapter3 - 読書メモ

エンジニアリング組織論への招待

目次

• Chapter1：思考のリファクタリング
• Chapter2：メンタリングの技術
• Chapter3：アジャイルなチームの原則
• Chapter4：学習する組織と不確実性マネジメント
• Chapter5：技術組織の力学とアーキテクチャ

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Chapter3：アジャイルなチームの原則

アジャイルなチームをメンタリングする技術

アジャイル開発

• チーム全体に対してメンタリングを行い開発出力を向上させる手法
• 開発手順・開発フロー

アジャイル開発が必要とされた2つの理由

• ソフトウェアの大規模化・複雑化
• マーケットの不確実性に対応

アジャイル開発は3倍の成功率、1/3の失敗率

• 大規模開発こそ、アジャイル開発はより効果的であるという結果が出ている

プロジェクトマネジメントとプロダクトマネジメント

• ソフトウェア開発の前提が変化した
  • プロジェクト型開発 → プロダクト型開発

プロジェクト型開発（計画駆動）	プロダクト型開発（マーケット駆動）
予算が開始時点に決まっている	予算は各ステージごとに徐々に調達される
成功はコスト・スケジュール・スコープが満たされるかどうかで計測される	成功はその製品が最終的に得たマーケットや収益に基づき計測される
プロジェクトマネージャーによって指揮される	プロダクトマネージャーとテクニカルリードのペアで指揮される

• 2つの不確実性に対するアプローチ
  • 

	計画駆動	アジャイル型開発
前提とする不安	スケジュール不安	スケジュール不安とマーケット不安
戦略	初期計画の精度を高める	実験的に徐々に精度を高める
変化	変化に弱い	変化に強い
アプローチ	理性主義	経験主義的

ウォータフォールかアジャイルか

• スコープとする範囲
  • 

アジャイルの歴史

アジャイル開発は経営学

• アジャイルというコンセプには、ソフトウェア開発というよりむしろ、経営学あるいは、組織学習という文脈の中で生まれてきたもの

デミング博士とPDCA

• デミングの4つの「深遠なる知識」が日本の製造業に浸透し、ソフトウェア開発にも取り入れられた
  • システムの理解
    • システムの個別要素ではなく、関係性に着目し生産性を向上させる
  • ばらつきに関する知識
    • 測定によって知識を得るという態度
  • 知識の理論
    • 知識がどのようにして得られ、展開していけば良いのかという知識
  • 心理学に関する知識
    • 人間性に関する知識

トヨタ生産方式とリーン生産方式

• トヨタ生産方式
  • 「在庫は悪」として捉え、実現手段として「従業員」のマインドに徹底的にこだわった
• リーン生産方式
  • トヨタ生産方式の徹底した無駄の排除と現場主義による改善を高く評価
  • それらを整理し、マニュアル化、パッケージ化したもの

生産方式から知識経営へ

• 新しい新製品開発ゲーム
  • NASAと日本企業における新製品の開発フローを比較した論文が発表された

NASA	各プロセスがばらばらの専門家によって分割されている
日本企業	異なる分野の専門家が一丸となって開発を進める

• SECIモデル
  • 4つの段階を繰り返すうちに、組織内に知識が獲得されていく
  • 
• シングル・ループ学習
  • 過去の学習を通じて獲得した「ものの見方・考え方」に基づいて、改善を繰り返す学習
• ダブル・ループ学習
  • シングル・ループ学習のサイクルに、環境の不確実性を取り込んで、今まで前提としていた前提自体を変えていくような学習
  • 

軽量ソフトウェア開発プロセス

• スクラム
  • ダブル・ループ学習を短い期間で繰り返していく
• エクストリーム・プログラミング
  • うまくいくソフトウェア開発における、現場の暗黙知を形式知とし、カタログ化したもの
• 適応型ソフトウェア開発
  • 不確実なビジネス環境では、官僚機構的なワークフローではなく、創発的な仕組みが必要という考え
• リーンソフトウェア開発
  • ムダ・ムラ・ムリという3つの贅肉を減らし、引き締まったソフトウェア開発を実現する
  • 贅肉を減らすための7つの原則
    • 1：全体を最適化する
    • 2：ムダをなくす
    • 3：チームに権限移譲する
    • 4：学習を強化する
    • 5：早く提供する
    • 6：品質を作り込む
    • 7：決定を遅らせる

アジャイルソフトウェア開発宣言

従来重視されてきたもの	これから重視していくべきもの
プロセスやツール	個人と対談
包括的なドキュメント	動くソフトウェア
契約交渉	顧客との協調
計画に従うこと	変化への適応

アジャイルの歴史に見る3つのポイント

• アジャイルは失われた日本的思考を取り戻し、新たな合理性を取り入れることでもある
• ソフトウェア開発プロセスに組織学習を組み込み進化していった
• アジャイル開発とは複数の軽量プロセスの総称である

アジャイルをめぐる誤解

アジャイルに関する5つの誤解

• 誤解１：アジャイル開発は決まったプロセスである
  • アジャイル開発は、アジャイルなチームを作るための方法論
• 誤解２：アジャイル開発では設計しない
  • 必要であればドキュメント作成も行う
  • 情報伝達はドキュメントよりもコミュニケーションの方が伝達効率が良いという考え
• 誤解３：アジャイル開発は優秀なメンバーでないとできない
  • 自立性が求められ、課題に直面し成長した結果、優秀なメンバーがいるように見える
• 誤解４：アジャイル開発では中長期計画がない
  • 不確実性が大きい場合は中長期計画の意味があまりないと判断することもある
• 誤解５：アジャイル開発は開発者に決定権がある方法だ
  • アジャイルなチームは仮説検証を繰り返し、顧客ニーズやビジネス価値を深く理解する
  • より抽象的な要求を定義できるようになり、意思決定の権限が徐々に移譲されていく

アジャイルはなぜ誤解されたのか

• 経験主義の意味が理解されないまま、プロセスだけ導入してしまう場合があるため
• システム思考、自己組織化、禅といった要素を知らない人には伝わりづらい
• ウォータフォールvsアジャイルとして対立した形で広まってしまった
• 開発・ビジネスそれぞれの立場における限定合理性としてアジャイル開発を理解してしまった
• 従来手法を重視する人たちにとって、生業となっていた知識が否定されるような体験になってしまった
• 誰かの思想信条を無条件に受け入れてしまう場合があった

アジャイルの格率

「アジャイル」は理想状態

• 「チームが環境に適応して不確実性を最も効率よく削減できている状態」
  • この状態に向かうため「どうしたら、さらに不確実性を減らせるのか？」という問に答えていく

アジャイルな方法論

• 不安に向き合うこと
  • 不安の正体は不確実性である
  • 1人で不安に向き合うのは難しいので、チームの力を借りる
• 少人数の対話を重視する
  • 少人数かつ対面でのコミュニケーションで情報共有を行う
  • 「情報の非対称性」を減らし、「通信不確実性」を削減する
• 役割を分けない
  • 役割を分けると「役割を遂行するにはどうすればいいか」という「限定合理性」が発生してしまう
  • チームの目的について「今、自分は何をすべきか」という問いをメンバーが常に持つようにする
• 経験のみを知識に変える
  • 「うまくいく」ことだけを目的にしてしまうと、「うまくいかない」ときに不安が増大してしまう
  • 実験によって得られた結果だけがチームにとって重要な知識となる
• 意思決定を遅延する
  • 「仮説思考」と「リアルオプション戦略」により、経営上の意思決定を遅延させる
• 価値の流れを最適化する
  • プロジェクト型チームは、ある要求に対してどれだけ早く応えられるかを最適化する
  • プロダクト型チームは、ある時間にどれだけの要求に応えられるかを最適化する

アジャイル開発は「脱構築」される

• アジャイル開発においては、チームが自分たち自身のやり方や役割を変えていくような「脱構築」帰納を内蔵させるように振る舞うことを要求する
• 別のチームが実行している「ある瞬間の特定の開発手法」を真似たからといって、チームがアジャイルになるとは限らないことに注意する

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 Chapter2 - 読書メモ

エンジニアリング組織論への招待

目次

• Chapter1：思考のリファクタリング
• Chapter2：メンタリングの技術
• Chapter3：アジャイルなチームの原則
• Chapter4：学習する組織と不確実性マネジメント
• Chapter5：技術組織の力学とアーキテクチャ

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Chapter2：メンタリングの技術

メンタリングで相手の思考をリファクタリング

メンタリング

• 相手の歪んだ知識を補正し、次の行動を促し成長させていく手法
  • 「思考のリファクタリング」の考え方を使う

メンタリングとエンジニアリングの関係

• エンジニアリング
  • 不確実性を削減する工程
    • 組織として力を発揮するには？
      • 「人間の不完全さ」の影響を削減することが重要
• コードレビュー
  • 問題に対するより良い考え方に気づいて成長を促す
    • コードを書いた人自身が、指摘のポイントに気づくよう促せるとベスト
• ペアプログラミング
  • 相互に対話的に問題解決を行うピアメンタリング技法
    • ナビゲーター・ドライバーを経験することで問題解決に対する考え方のレベルが向上し、成長を促す
• 障害時ハンドリング
  • 障害のときは目の前の課題に目が向いてしまいがち
  • 障害時のハンドリングを行うには司令塔が必要
    • 情報を整理し、不確実な状況から順番に原因を特定し、障害を収束させるためにチームを支援していく
• チームマネジメント
  • アジャイルなチームマネジメント技法
    • メンタリングやファシリテーション能力を要求される

「自ら考える人材を作る」ためのテクニック

• メンタリング
  • 「自ら考える人材を作る」テクニック
    • 「自立した人材」
• 人材タイプ
  • 依存型人材
    • 問題を与えられてから考える
    • 問題と解決策を渡されてから考える
  • 自律型人材
    • 自ら問題を発見し解決することができる
    • 問題について、自分事として捉えている
• 依存型人材と自律型人材を分ける要素は？
  • 上司と部下という関係における期待値の問題
    • 期待値が調整されていない
      • 提案しても却下され続けてしまう
      • 負のフィードバックサイクル
      • 「学習性無気力」が生まれてしまう
    • 期待値が調整されている
      • 提案して動いた結果評価される
      • 正のフィードバックサイクル
      • 「自己効力感」が生まれる

効果的なメンター／メンティの関係性

• メンターとメンティの関係性を効率的なものにするための条件
  • 謙虚（Humility）
    • お互いに弱さを見せられている
  • 敬意（Respect）
    • お互いに敬意をもっている
  • 信頼（Trust）
    • お互いにメンティ（自身）の成長期待をもっている
• メンターとピアメンター
  • メンター
    • メンティにとってのロールモデルとなるような、能力と経験をもった人物
  • ピアメンター
    • ロールモデルとなるほど尊敬される訳ではないという状況から始まるメンター関係
• 階段を上る手助けをする
  • メンティを階段を上らせるために必要なこと
    • 階段を認識させる
      • 見えていない課題に自分で気づかせる
    • 壁に梯子をかける
      • 成長を実感させ、正のフィードバックを促す
    • 階段を上りたくさせる
      • 自ら考え行動するよう促す

「他者説得」から「自己説得」に

• 応用力
  • 自ら獲得した知識だと感じることによって生まれる
    • 自己説得
• 他者説得
  • 自分以外の他者から、たとえや理屈、学習などを通じて、その事を説得すること
  • 特徴
    • 他人が答えを伝える
    • 体感を伴わない
    • 理解を確認できない
  • 納得が伴わないためメンティの行動を変容させることができない
• 自己説得
  • 周りの状況などから、自ら今までわからなかったことを理解した状況
  • 特徴
    • 他人が質問で促す
    • 体感を伴う
    • 行動の変化が発生しやすい
  • 質問を通じてメンティにとっての盲点となっている部分を外していき、自ら解決策に導く

「悩む」と「考える」の違い

• 悩む
  • 「次に取るべき行動」がわからずにいる状態
• 考える
  • 「次に取るべき行動」を行うこと
• メンターは「悩み」を聞き出し、気づきを促して、「考える」に変えていく

傾聴・可視化・リフレーミング

メンタリング

• その問題が解けない理由を1つずつなくしていき、「ひとりでも」解けるパズルに変換すること
  • 感情に固執していて解けないので「傾聴」をする
  • 客観視できずに解けないので「可視化」をする
  • そもそも解けない問題なので前提を変える「リフレーミング」をする

空っぽのコップにしか水は入らない

• 

「傾聴」と「ただ話を聞くこと」の違い

ただ話を聞くこと	傾聴
「自分の」意見を言う	「相手の」感情への共感を言動で表す
「自分の」興味のあることを質問する	「相手の」話の内容を「可視化」する
「自分に」興味のないことには興味がなさそうな素振りをする	「相手の」思考の「盲点」を探索しながら質問をする

共感をして話を聞き出す「信号」

• しぐさ・うなずき・座り方
  • スマホを見たり、手で机をタップするといったしぐさはNG
  • ポジティブな話→早く細かくうなずく、ネガティブな話→ゆっくり深くうなずく
  • 横に座り、自分の全身が見えるようにして話をする
• 表情
  • 「相手の目を見て話す」のは威圧的に感じつ場合もあるので注意する
  • 相手と同じ様な感情を表現する→「ミラーリング」
• あいづち
  • 「Aさんが、〜したんですね」「〜が許せないんですね」といった、要約や共感という形であいづちを打つ
• 気がつかない信号を指摘してもらう
  • メンティに気になる所があったら、教えてほしいと伝える
• 共感と同感
  • 共感
    • 相手がそのような気持ちになった理由を理解する
    • e.g. 「そういう理由であの人が許せないんですね」
  • 同感
    • 自分が相手と同じ気持ちになる
    • e.g. 「確かにあの人は許せない！」

問題の「可視化」と「明晰化」

• 「可視化」と「明晰化」
  • 
• 事実と意見を分ける
  • 「可視化」するのは事実関係
    • 感情と癒着した問題には事実がはっきりしない表現が出てきやすい
      • 質問を通じて事実関係を切り出していく
• フォーカスポイントを作る
  • 色々な悩みをまとめて全部解消することはできない
    • 問題を分解し、1つ1つにフォーカスして解いていく
• 衝突から比較可能への変換
  • 「悩んでいる」状態
    • 「選択肢」が不明確
    • 「比較軸」が不明確
    • 「評価方法」が不明確
  • これらを明らかにして解けるパズルに変換する

認知フレームとリフレーミング

• 人はありのままに物事を見られない
  • 物事を認知できる枠組みが存在する
    • 「認知フレーム」
  • 認知フレームは「焦り」「優先順位」やちょっとした発言で変えることができる
    • 「リフレーミング」
    • 「解けない問題」から「解ける問題に」変換する
• 認知フレームを発見する「キーワード」
  • 
• 前提の「確認」と「取り外し」
  • 前提
    • 「常識」や「普通はこうする」といった認知フレーム
  • 質問を通して前提を「確認」し、不要な前提は「取り外す」
    • 「そもそも、何で〜なんですか？」
    • 「これは必ず必要なんですか？」
• 情報の非対称性の解消
  • 情報の非対称性
    • 自分は「わかっている」けど、相手はわかっていない
    • 相手は「わかっている」けど、自分はわかっていない
  • 解消するには
    • 自分の情報を相手に伝える
    • 相手の情報を自分が聞く
  • 「相手は〜と思っているに違いない」「自分の考えは相手に伝わっている」といった認知フレームがあると、当たり前のことができなくなってしまう
    • 相手に情報が伝わっているか確認する
• 課題の分離
  • 不安や悩みを抱えると問題が大きくなってしまう
    • 課題を分離する
  • 思考の範囲をクリアに限定する
    • 「あなたにとって具体的に何が問題か」
    • 「あなたがコントロールできるものは何か」
    • 「どうなればその具体的な問題は解消されたと言えるのか」

心理的安全性の作り方

心理的安全性

• 対人リスクを取っても問題ないという信念がチームで共有されている状態

「アットホームな会社」は心理的安全性が高いか

• 影響から考える心理的安全性
  • 「心理的安全性」を高めることによるチームへの影響

影響	解説
率直に話すようになる	課題について他の人がどう思うかをそれほど気にしないでも発言できる
考えが明晰になる	不安が少ないため認知の歪みが少なく、考えを明晰に表現できる
意義ある対立が後押しされる	関係性の悪化に伴った対立ではなく、より本質的な対立を健全に議論できる
失敗が緩和される	失敗を報告しやすくなり、ミスについて話し合う機会が増え、学習を行える
イノベーションが促される	今までの前提を取り払って、思考することが出来るようになり、創造的な意見が出る
組織内の障害で履く目標に集中できるようになる	目標に対してストレートに向き合えている。組織内の理不尽を取り除くことに力をかけないでも済む状態にある
責任感が向上する	対人リスクを取っても、目標に対して自律的に行動出来るようになる

• 心理的安全性と責任
  • 
• 自己主張と同調圧力
  • 「同調圧力」
    • 周囲と出来る限り同調してコミュニケーションするような環境・集団心理
    • 対人リスクを避けている
      • 自己主張しづらい
• メンタリングにおける心理的安全性
  • メンタリングを効果的にするためには
    • 「対人リスク」が取れる状態を構築する
  • 「対人リスク」が取れる状態にするには
    • 自分の弱さ・自分の失敗を開示する
      • 「〜で失敗したけど、〜したら上手くいって成長した」といった物語で自分の弱さを開示する
        • 「ストーリーテリング」

アクノレッジメントとストーリーテリング

• アクノレッジメント
  • 「承認」
    • メンティの存在・行動を理解し、受け入れ、感謝を伝えること
  • アクノレッジメントには3つの段階がある
    • 
• YouメッセージとIメッセージ
  • Youメッセージ
    • 「あなたは〜だね」
  • Iメッセージ
    • 「わたしは〜と感じた」
  • ニュアンスを変えることで、よりアクノレッジメントを伝えやすくなる
• フィードバックを求める
  • メンターがメンティに相談して意見を求める
    • 求められているという体験は、自己承認と自己効力感を生み出す
  • 当たり前のことを意識してやる
    • アクノレッジメントは当たり前なことばかりだが、忘れてしまいがち
      • ちゃんと挨拶する
      • 無視しないで話を聞く
      • 相手に感謝を伝える
      • 気にかけて話しかける
      • 自分本位ではなく相手本位で話をする

ストーリーテリングの重要性

• 自己開示
  • 包み隠さず苦労や思いを伝えることが重要
    • 問題を乗り越えられるという感覚を得てもらう
• 感情の共有
  • 「辛い」や「憎い」など、感情を説明する
    • 自分事として理解し、話を深く聞いてもらう
• 価値観の共有
  • 「伝えたい価値観」をはっきりさせておく
    • 同じ様な価値観を持つことの重要性を理解してもらう
• 半報性の原理
  • 人から施しをもらうと、自分もお返しが必要と感じる心理
    • メンティ自身の「自己開示」を引き出す

ジョハリの窓と心理的安全性

• 

内心ではなく行動に注目する

内心は見ることができないが、行動は見ることが出来る

• メンタリングの最終工程
  • 「これからどうするか」を話し合い、合意し、次回に振り返ることを約束すること
    • 「内心」
      • コントロールできない
    • 「行動」
      • メンティ自身がコントロールできる
• SMARTな行動
  • 「SMART」
    • 「言葉は決して正しく伝わらない」という前提のもと、少しでも解釈の差を減らしていくための原則
      • Specific（具体的な）
        • 何をするのか解釈にブレの少ない言葉にする
      • Measurable（測定可能な）
        • 行動が行われたことを、どのようにして計測するのかを合意する
      • Achievable（到達可能な）
        • メンティに十分コントロール可能である行動を合意する
      • Related（関連した）
        • 課題と行動の関連性をメンティ自身が「説明できる」ような行動にする
      • Time-Based（時間制限のある）
        • いつまでに行われ測定されるのかが決まっている
• 「わかった？」は意味のない言葉
  • 「わかった？」と聞く
    • 「わかりました」「わかりませんでした」
      • わかったかどうかの情報が、メンティの頭の中にしかない
  • 「わかる」の定義を「具体的な行動を行うことができる」とすると
    • 「〜をやってみて」「〜をせつめいしてみて」
      • 観測可能な行動を通じて、理解を確認する

能力は習慣の積分、習慣は行動の積分

• 人の成長のサイクルは、行動・習慣・能力・成果の4つの事柄のループ
  • 

なぜ行動を起こせないのか？

• 「行動変化」を起こすことができないとき
  • 行動を「阻害する力」と「促進する力」が働いている
    • バランスによって行動が行われたり、行われなかったりする
• 「行動を促進する要因」
  • フィードバック機会を増やし、適切に承認していくことで強化
• 「行動を抑制する要因」
  • 環境や構造を変えるための行動に変換して、その行動を促していく

ゴールへのタイムマシンに乗る

• メンタリング
  • 自律的な人材を育むために行う
    • 自分が気づかなかった問題に気づくようになる
    • 認知の歪みによる感情と問題の癒着を切り離せる
    • 答えではなく、次の一手を生み出す行動が取れるようになる
  • 「ゴール認識」が重要
    • ゴールによって「認知フレーム」が変わる
      • 高いゴール設定と「ゴール認識」のレベルが伴う必要がある
  • ゴール認識のレベル
    • レベル4になると、習慣が変化し始める
      • 「ゴールへのタイムマシンに乗った」状態
    • 

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 Chapter1 - 読書メモ

エンジニアリング組織論への招待

目次

• Chapter1：思考のリファクタリング
• Chapter2：メンタリングの技術
• Chapter3：アジャイルなチームの原則
• Chapter4：学習する組織と不確実性マネジメント
• Chapter5：技術組織の力学とアーキテクチャ

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Chapter1：思考のリファクタリング

• 思考のリファクタリング
  • 頭の中で発生してしまう無駄なプロセスを削除して、考えるときの指針を持ち、問題解決に向かって明確に行動が出来るよう促すもの
  • 「不確実性に向き合う」

不確実性とエンジニアリング

エンジニアリングとは

• 「曖昧さ」を減らし、「具体性・明確さ」を増やす
  • 曖昧さ
    • 決まっていないこと・将来どうなるかわからないこと ＝「不確実性」

不確実性

• 組織構造と不確実性
  • 
• 不確実性の発生源
  • 「わからないこと」から「不確実性」が発生する
  • 

情報を生み出す考え方

仕事の問題解決を行うために必要な3つ思考

• 論理的思考の盲点
  • どんなときに人が論理的でなくなるかを知った上で問題解決を行う
• 経験主義と仮説思考
  • 情報を得た上で問題解決を行う
  • 得た情報から全体を想定し問題解決を行う
• システム思考
  • 全体像を見極め問題解決を行う

仕事の問題を学力テストの問題に変換する

• 

論理的思考の盲点

論理的思考には2つの前提が必要

• 2つの前提
  • ルールと自称を正しく認知できること
  • 正しく演繹できること
• 「人はどのようなときに非論理的になってしまうのかを知る」ことが重要

ベーコンのイドラ

• 「身体的機能」「自身の環境」「周囲の意見」「伝統や権威」によって錯覚や認識の間違いを起こしてしまう

認知の歪み

• ゼロイチ思考
  • 白か黒か、敵か味方かのように、2分法で考えてしまう
• 一般化のしすぎ
  • 1つや2つの事例で決めつけたり、早計な判断をしてしまう
• すべき思考
  • 他人に対し「○○すべき」と期待し、強制してしまう
• 選択的注目
  • 人は見たいものだけ見てしまう
• レッテル貼り
  • ある人の特定の属性に注目して判断してしまう
• 結論の飛躍
  • 相手の感情を先回りして読み取り、短絡的な判断をしてしまう
• 感情の理由付け
  • 感情のみを根拠に自分の考えが正しいと判断してしまう

認知的不協和

• タバコが体に悪いと理解しているがタバコを吸う
  • 知識と行動の整合性が取れていない状態
  • 不整合を避けるため、正当化出来る情報を選択的に取り入れてしまう

扁桃体をコントロールする

• 「自分」や「自分が大切にしていること」に被害が及びそうだと感じる
  • 恐怖を感じる
    • 怒りに変わる
      • 自分や大切にしていることを守るため、理屈を練り上げてしまう

自分のアイデンティティの範囲を知る

• アイデンティティ＝「自分を構成すると思っていること」
  • 範囲が広い人
    • 怒りを感じる範囲が広い
  • 範囲が狭い人
    • 怒りを感じる範囲が狭い

「怒り」を「悲しみ」として伝える

• 他人の大切にしていることを知ることはできない
  • 「怒り」を感じたときは「○○は自分にとって大切で、○○な扱いをされると悲しい」など、「悲しみ」として伝え、相手に自分の大切にしていることを知ってもらう

問題解決より問題認知のほうが難しい

• 人は自分が間違っているかもしれないことを無意識に避けてしまう
  • 正しい情報を認知できない
  • 自分が間違っているかもしれないと思考のパターンを変える必要がある

経験主義と仮説思考

経験主義：わからないことは調べるしか無い

• 「理性主義」
  • ある「前提」から演繹的に判断しようという考え（ウォータフォール）
• 「経験主義」
  • 「経験」を行うことでしか「知識」を得られないという考え（スクラム）
  • 「何がわかればわかるのか」を考え、それを「確かめる」

不確実性と夏休みの宿題

• 夏休みの宿題
  • 計算ドリル
    • 不確実性が「低い」
    • いつ終わるのか大体わかる
  • 自由研究
    • 不確実性が「高い」
    • いつ終わるのかわからない
• 自由研究（不確実性の高いもの）から取り組むことで、いつぐらいに終わるのかわかる
  • 不確実性が下がる

プロフェッショナルの仕事

• プロフェッショナル
  • 短い時間で一定のクオリティまで上げて、残り時間で作り込む
    • 不確実性の高いものから取り組む
• アマチュア
  • 残り時間が短くなってから、急速に出来上がってくる
• 

コントロールできるもの／できないもの

• 経験主義で重要なこと
  • 「知識」＝「経験」を行動によって手に入れるということ
    • 「行動できることは何か？」
    • 「行動の結果起きたことを観察できるか？」
• e.g. 「上司が自分の仕事を評価してくれない」
  • コントロールできない
    • 上司の行動
    • 上司の考え
  • コントロールできる
    • 自分の行動
    • 自分の考え

観測できるもの／できないもの

• 本来コントロールできないはずのものを、自分の行動で変化させようと試みるには
  • 「観測できる」必要がある
  • 「観測できない」ものは、行動しても変化がわからない

あなたができること

• 

仮説思考：少ない情報で大胆に考える

• 演繹法
• 帰納法
• 「仮説法」
  • 経験主義を更に生産的な（不確実性を下げる）ものにするために、「大胆な跳躍」をもたらす

演繹法	帰納法	仮説法
ルール：人間は死ぬ	事象：このカラスは黒い	事象：2つの大陸は海岸線が似ている
事象：Aさんは人間である	事象：あのカラスも黒い	仮説：大陸は移動してたのではないか
結論：Aさんは死ぬ	結論：全てのカラスは黒い	結論：2つの大陸が1つである証拠を探そう

PDCAサイクル

• 

データ駆動な意思決定の誤解

• 「データ駆動な意思決定」
  • 「仮説」を推論するために、持っているデータの可視化をする
  • 「仮説」が正しかったのか、統計的に検証する
  • 「次に取るべき正しい行動」を出すためではない

リアルオプション戦略と遅延した意思決定

• リアルオプション戦略
  • 仮説を作り、その仮説を早期に少ない予算で検証する
  • 大きな意思決定を遅らせることが出来る
  • 

問題の解決よりも問題の明晰化のほうが難しい

• 社会で取り組む問題の多くは、情報が不完全な状態から始まる
  • 問題解決よりも先に「どのような問題なのか」をはっきりさせることが重要
• 「経験主義」＋「仮説思考」→「問題は何なのか」をはっきりさせる
  • 「問題を解く」ことは難しいことではない

全体論とシステム思考

システムとは全体の関係性を捉えること

• 

部分だけしか見えないことで対立が起こる

• 3次元のU
  • 様々な対立が、物事を「側面から」見ることができずに発生する
  • 

バランスシートとP/Lの関係性

• 
• 企業内部には、まだ資産や利益に還元されていない無形の投資活動が含まれている
  • 全体のフィードバックサイクルで見ると、それらは「コスト」とは限らない
  • P/Lだけ見ると「コストに見えてしまう」

拡張のフィードバックと抑制のフィードバック

• 
• どの様なフィードバックサイクルが存在するのか見つけていくことが重要

全体の関係性が見えれば対立は解消する

• 1つ上の次元から問題を捉えて、システム全体を把握していく
  • 対立から発展的な議論へと視野が拡大する

認知範囲とシステム思考

• 視野・視座・視点
  • 問題解決のための眼
    • 視野
      • あるポイントからその問題を眺めたときに同時に把握できる領域の広さ
      • 広い／狭いで評価
    • 視座
      • どこから眺めるか
      • 高い／低いで評価
    • 視点
      • どの角度から眺めるか
      • 鋭さ／凡庸さで捉える
• 個人ではなく関係性に注目する
  • 様々な問題は、本当に個人の問題なのか？
    • 個人同士の関係性が問題なのかもしれない
      • 個人の性質
        • 変えるのは難しい
      • 個人同士の関係性
        • 変えるのは難しくない
        • ここに注目するのがシステム思考

問題解決より問題発見のほうが難しい

• 世の中は複雑な相互関係を持っている
  • 合理的に見える解決策が別の問題を引き起こしたり、想定していない悪化をもたらす可能性がある
• システム思考によって問題を変換する
  • 対立に見える問題 → 対立にならない全体像をあぶり出す
  • 個人の問題 → 関係性の問題

人間の不完全さを受け入れる

思考を前にすすめるための3つの考え方

• 論理的思考の盲点
  • 「人は正しく事実を認知できない」
  • いつ認知が歪むのかを知り、歪んだ認知を正すための行動を促す
• 経験主義・仮説思考
  • 「いくら理屈で考えても答えが出ない問題に時間を浪費してしまう」
  • 実験によって知識を獲得し、何が問題であるかを削り出すように考えるための行動を促す
• 全体論とシステム思考
  • 「人は問題を個人の責任にしたり、全体像を見失った局所的な思考をしてしまう」
  • それが全体像ではないかもしれない、問題は関係性にあるのでは、という視点と問題解決のための眼を提供し行動を促す

コミュニケーションの不確実性

• 人間のコミュニケーションの不確実性は3つの不確実性から来ている
  • 他者理解の不確実性
    • 人は他人や事象を完全には理解できない
  • 伝達の不確実性
    • コミュニケーションが到達するとは限らない
  • 成果の不確実性
    • 仮に理解されたとしても予想されたように行動するとは限らない
• 

情報の非対称性

• 同じ目的を持った集団で、何かの情報を片方の人が知っていて、もう片方の人が知らないという状態
  • 人は正確に自分の考えを他人に伝えることは不可能なので、非対称性が生まれる

限定合理性

• 人間の認知能力には限界があり、ある人にとっての正解が全体にとっての正解になるとは限らない

コミュニケーション能力と透明性

• 組織の人数が増えるにつれてスケールするはずが、徐々に悪化してしまう
  • 「情報の非対称性」と「限定合理性」が存在するから
• コミュニケーション能力
  • コミュニケーション能力とは、コミュニケーションの不確実性を減少させる能力
• 透明性
  • 透明性とは、継続したコミュニケーションや仕組みを通じてコミュニケーションの不確実性を低く維持し、情報の非対称性が削減され限定合理性の働きを弱められている状態

不確実性を削減し秩序を作る

• 「不確実性を削減し、秩序を作る」ことこそがエンジニアリングで最も重要な出発点・性質である

書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

Clean Architecture - まとめ

読書メモ

umatomakun.hatenablog.com

umatomakun.hatenablog.com

クリーンアーキテクチャ

ソフトウェアアーキテクチャの目的

• 求められるシステムを構築・保守するために必要な人材を最小限に抑えること
• 優れた構造（アーキテクチャ）にすることで、ソフトウェアをソフト（変更しやすい状態）にする

優れたアーキテクチャとは

• 「境界線」と「依存方向」が正しく設計されている
  • 独立した開発・運用・デプロイを可能とする

クリーンアーキテクチャ

• 優れたソフトウェアアーキテクチャを具体化したもの
  • 「境界線」と「依存方向」を具体化したもの

感想

• つまり、クリーンアーキテクチャとは何なのか？
  • オブジェクト指向設計に基づいたソフトウェアアーキテクチャのこと
    • 継承・ポリモーフィズム・カプセル化と言っていることは同じ
• 必ず4層に分ける必要があるのか？
  • 絶対に分ける必要は無いはず
  • 様々なトレードオフを理解した上で「境界線」と「依存方向」を正しく設計していれば、クリーンアーキテクチャなのだと思う

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture - 読書メモ 2

叫ぶアーキテクチャ

優れたアーキテクチャはユースケースを中心にしている

• フレームワーク・ツール・環境に依存しない
• 簡単にユースケースを把握できる

クリーンアーキテクチャ

クリーンアーキテクチャ

• フレームワーク非依存
• テスト可能
• UI非依存
• データベース非依存
• 外部エージェント非依存

依存性のルール

• ソースコードの依存性は、内側だけに向かっていかなければならない

エンティティ

• 企業全体の最重要ビジネスルール

ユースケース

• アプリケーション固有のビジネスルール

インターフェイスアダプター

• フォーマットを変換する
  • ユースケースやエンティティ用のフォーマット
  • データベースやウェブ用のフォーマット

フレームワーク・ドライバー

• フレームワークやデータベース

クリーンアーキテクチャ

プレゼンターとHumble Object

Humble Object パターン

• 「テストしにくい振る舞い」と「テストしやすい振る舞い」に分けるパターン
  • テストしにくい振る舞い
    • View・Database
    • シンプルに保っておく
  • テストしやすい振る舞い
    • Presenter・UseCase

部分的な境界

本格的なアーキテクチャの境界はコストが高い

• 多くの作業が必要であり保守も必要
• 優れたアーキテクトは、このような境界はコストが高すぎると判断する
  • 同時に、後で必要になるから境界を残しておきたいとも思う
    • YAGNIに違反する
    • 部分的な境界を実装

部分的な境界

• 最後のステップを省略
  • 独立してコンパイル・デプロイが可能な状態にしておくが、同じコンポーネントにまとめる
• 片方だけの境界
  • Strategyパターンを使い、片方だけの境界を作る
• Facade
  • Facadeパターンを使い、シンプルな境界を作る

片方だけの境界	Facade

サービス：あらゆる存在

サービスアーキテクチャ

• 「サービス思考アーキテクチャ」・「マイクロサービスアーキテクチャ」
  • サービスが互いに分離されているように見える → 正しくない
    • サービスは共有しているデータと強く結びついていて、間接的ではあるが相互に結びついている
  • サービスが開発・デプロイを独立させていように見える → 正しくない
    • 誤った分離により独立して開発・運用・デプロイできない
    • データや振る舞いが結びついている限り、開発・運用・デプロイには調整が必要となる

横断的関心事

• アーキテクチャの境界は
  • 正：サービスを横断することでコンポーネントに分割する
  • 誤：サービスとサービスの中間に位置する
• サービスは依存性のルールに従った内部コンポーネントのアーキテクチャと一緒に設計する必要がある

テスト境界

テスト容易性のための設計

• 脆弱なテストの問題
  • 共通のシステムコンポーネントを変更すると、何千や何百というテストが壊れる可能性がある
• テスト容易性の設計
  • 変化しやすいものに依存しない
    • GUIは変化しやすい → 脆弱である

テストAPI

• 変化しやすいものに依存しないようにするために
  • テストから使用できるAPIを作り、全てのビジネスルールを剣侠できるようにする

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture - 読書メモ 1

設計とアーキテクチャ

ソフトウェアアーキテクチャ

• 目的
  • 求められるシステムを構築・保守するために必要な人材を最小限に抑えること

崩壊したコードを書く方がクリーンなコードを書くより常に遅い

• TDDありとTDDなしで比較
  • TDDを使ったほうが速い

速く進む唯一の方法はうまく進むこと

• 優れたソフトウェアアーキテクチャを設計するということ
• クリーンアーキテクチャ

２つの価値のお話

ソフトウェアシステムの価値

• 振る舞い
• 構造 >> こちらの方が重要
  • 簡単に変更できるようにする
    • ソフトであるということ
  • 「形状」ではなく「スコープ」に比例して難易度が変わるべき

アーキテクチャとは？

アーキテクチャ

• 主な目的
  • システムのライフサイクルをサポートすること
    • 開発
      • 開発しやすくなるようなシステムにする
    • デプロイ
      • 単一のアクションで簡単にデプロイ出来るようにする
      • 速い檀家来からデプロイ戦略を考える
    • 保守
      • 保守派最もコストがかかる
      • アーキテクチャを考え抜きコストを下げる

ソフトウェアの価値

• 振る舞いの価値
• 構造の価値
  • ソフトウェアをソフトにする価値
    • できるだけ長い期間・多くの選択肢を残すこと
    • 残すべき選択肢
      • 重要ではない詳細
        • DB・サーバー・フレームワーク・プロトコル...

独立性

優れたアーキテクチャがサポートすること

• システムのユースケース
• システムの運用
• システムの開発
• システムのデプロイ

レイヤーの切り離し

• UI・ビジネスルール・データベース等のレイヤーで切り離す
• 変更される理由をまとめる

ユースケースの切り離し

• ユースケースで切り離す
• 他のユースケースに影響なく、新しいユースケースを追加する

レイヤー・ユースケースを切り離すことで

• 「独立した開発」「独立デプロイ」を可能とする

切り離し方式

• ソースレベル
  • モジュールを分離する
  • モジュール間で影響しない
• デプロイレベル
  • デプロイ可能な単位を分離する
  • ソースコードの変更が他のモジュールに影響しない
• サービスレベル
  • 実行単位を完全に分離する
  • ソースやバイナリの変更が影響しない

バウンダリー：境界線を引く

ソフトウェアアーキテクチャとは、境界線を引く技芸である

• バウンダリー
  • 「重要なもの」と「重要でないもの」の間に引く
  • 重要なもの
    • ビジネスルール
  • 重要でないもの
    • DB・GUI...

方針とレベル

コンピュータプログラムは、入力を出力に変換する「方針」を記述したもの

• レベル
  • 入力と出力からの距離
• 依存方向はレベルと結びつける

ビジネスルール

エンティティ

• ビジネスデータを操作するビジネスルールを含んだオブジェクト
  • ビジネスルール
    • システムが自動化されていなくても存在するルール
  • ユースケースのことは知らない

ユースケース

• 自動化されたシステムを使用する方法を記述したもの
  • ユーザーインターフェイスについては記述しない
  • エンティティのことを知っている

書籍

Clean Architecture 達人に学ぶソフトウェアの構造と設計