KATOエンジニヤリング開発日誌

「アウトプット無きエンジニアにインプットもチャンスも無い」の精神で書いています

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

3月に転職しましたが、これまでのSESでのプロジェクト開発型組織から自社サービスのプロダクト開発型の組織になったので1つのチームで長期的に活動することについて考えてみようと思い、以前から興味のあった「エンジニアリング組織論への招待」を読んでみました。

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

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

書いてある内容は素晴らしいのですが誤字脱字が多いのがちょっと気になりました。

学んだことを羅列する

  • この本で何度も語られていることとして「不確実性に向き合う」ということがある。学校教育では「わからないもの」にどう立ち向かうかを教わることはなく、答えが導きだせる問題の解き方を教わっていた。
  • エンジニアリングとは「実現するための科学」であり、ソフトウェア開発も誰かの曖昧な要求からスタートし、要件定義->概要設計->詳細設計->実装といった具体的なものに変わっていく過程である。
  • エンジニアリングで重要なのは「どうやって効率よく不確実性を減らしていくか」という考え方。エンジニアリングでは不確実性の高い状態から不確実性の低い状態に効率よく移していく過程に行う全てのこと(プログラミングだけではない)。エンジニアリングの本質が「不確実性の削減」ということに気づかないでいると、確実なものを確実な手段で提供したいという理想を思い描いて上手くいかないという状態になってしまう。
  • 組織構造では上位の人が抽象的で曖昧な指示を出し、下位の人になっていくにつれ具体的で明確な行動になる。
  • 「具体的で細かい指示が必要な組織」と「抽象的で自由度のある指示で動ける組織」で比べると、前者は指示をする人間の能力がそのまま組織の能力となる。そのためその組織のメンバーは少しの「不確実性」の削減しかできない状態である。後者はより大きな「不確実性」の削減を行うことができる。前者は「マイクロマネジメント型の組織」と呼び、後者は「自己組織化された組織」と呼ぶ。
  • 不確実性とは「わからないこと」によって生じる。人間にとってわからないことは「未来」と「他人」である。
    • 未来 -> 環境不確実性
    • 他人 -> 通信不確実性(コミュニケーション不確実性)
  • この2つの不確実性からは逃れることができないので、向き合ってこれらを少しでも減らしていくことが物事を実現するための「手段」である。しかし人間にはわからないものに向き合うことを避ける習性があるので、わかっている「物事」から取り掛かってしまう。これがプロジェクトの最初は順調に見えて、後半になって進捗が遅れがちになる理由である。
  • プロフェッショナルの仕事とアマチュアの仕事の違いは、プロは短い期間で一定のクォリティに仕上げて残りの時間で作り込んでいく。アマチュアは残り時間が少なくなってから急速に出来上がってくる。つまりプロは不確実性の高いものから取り掛かるということである。
  • メンタリングは「自ら考える人材を作る」テクニックである。つまり「自己組織化された組織」を作るテクニックである。
  • メンターとメンティーの関係性を効率的なものにするための条件は次の3つ
    • 謙虚:お互いに弱さを見せられる
    • 敬意:お互いに敬意をもっている
    • 信頼:お互いにメンティの成長期待をもっている
  • これらはHumility,Respect,Trustの頭文字をとってHRT(ハート)と呼ばれる。
    • HRTの詳細は「Team Geek」が詳しく載っている

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

  • 「悩む」と「考える」の違い
    • メンターはメンティーが悩んでいるのか考えているのか判断することが重要。悩んでいるというのはぐるぐると思考が巡り続けていてもやもやが取れていない状態のこと。この状態のときはサポートが必要である。
    • 考えているときは答えが出ていなくても次に何をしたらよいかが明確になっており、メンティーは何らかの行動をとっている。
    • メンタリングでは「次にとるべき行動」がはっきりとするようにメンティーに促す必要がある。曖昧にしておくとメンティーの悩んでいる状態が続くことになる。
    • メンティが「行動できていないとき(悩んでいるとき)」にメンターは「悩み」を聞き出し、気づきを促して「考えている状態(行動しているとき)」に変えていく必要がある。 
  • 「傾聴」と「ただ話を聞くこと」の違い
    • 特に意識をしないで人の話を聞くときは自分の意識を出してしまいがち
      • 自分の意見を言う
      • 自分の興味のあることを質問する
      • 自分に興味のないことには興味がなさそうな素振りをする
    • 「傾聴」では相手を中心とし、思考が整理され前向きに考えられるように支援するように意識して会話をする。
      • 相手の感情への共感を言動で表す
      • 相手の話の内容を可視化する
      • 相手の思考の盲点を探索しながら質問をする
  • アジャイル開発は開発手順や開発フロー・開発手法というよりもチーム全体をメンタリングする技術。
  • マーケットがプロジェクト期間中に変動することが頻繁に発生することが多くなり、プロジェクト費用対効果が悪くなっていた。アジャイル開発はこのマーケットの不確実性に対応することができる。