ITエンジニアに読んでほしい！技術書大賞 2019「エンジニアリング組織論への招待」

1. はじめに

ITエンジニアに読んでほしい！技術書大賞 2019に輝きましたエンジニアリング組織論への招待を読んで、自分にとって重要と感じた部分、参考になった部分をまとめてみました。(遅いですね^^;) 内容を網羅しているわけではありませんのであしからず。是非書籍の方も手に取ってご覧ください。

2. 不確実性を削減する

2-1. 不確実性とは

• 不確実性とは、ある物事の事象が確実でないことを示す概念。不確実性は「分からないこと」から生まれる。人間にとっての分からないことは以下の2つに分類できる。
  • 未来・・・それがやってくるまでどうなるか分からない。環境不確実という。
  • 他人・・・人と人は別の自意識を持っていて、すべての情報を一致させることは不可能である。通信不確実性という。

2-2. 環境不確実性を削減する

• 情報を入手するために行動し、結果を観察し、そこから問題解決を行う。経験主義という。
• 答えを出す情報が揃っていないのなら、どのような次の一手が必要かを考える。つまり何が分かれば分かるのか。知識の源泉は経験である。
• コントロールできるもの(他人の行動等)をコントロールすべき。コントロールできないもの(他人の内心や能力等)をコントロールしようとするとストレスとなる。
• 不確実性の高いものこそ優先的に取り組む。そうすれば全体の時間が読めるようになる。プロジェクトマネジメントにおいて重要なこと。

2-3. 通信不確実性を削減する

• 仕事は複数人によって行われるため、コミュニケーションの失敗が生まれる。
• 「私はあなたでない」という単純なことが忘れられてしまい、自分の事情は全て相手に伝わっているのだという勘違いが発生する。このことから、事実を正しく認知するのが難しくなる。その結果、仕事の問題解決を行う上で必要な論理的思考は、コミュニケーションの失敗によって制限されてしまう。
• 人間が正しく論理的に思考するためには、以下の2つが重要となる。
  • 事実を正しく認知する・・・人間は事実を正しく認知することは難しく、認知は事実から変化してしまう。「事実」と「意見」は別物であることを意識すべきである。
  • 感情にとらわれず判断する・・・人間はすばやく結論へと思考を進めてしまう傾向にある。このときに発生しているのは論理的思考ではなく感情による短縮である。感情的になる瞬間を知り、その影響を少なくすることを意識すべきである。
• 同じ目的を持った人は本来対立しない。対立するのは、部分しか認識していないためである。何かの対立が発生したときは、当事者全員が少しずつ正しく、少しずつ間違っている。

3. メンタリング能力を向上する

3-1. メンタリングとは

• メンタリングとは、対話や助言によって本人の自発的な成長を支援すること。
• 指導する側をメンター、指導される側をメンティと呼ぶ。
• 「どうしたらできるのか」を共に考えていく。自ら考えられる人材を作ることを目的とする。

3-2. メンタリングのポイント

• メンターはメンティの話を「聞く」のではなく「傾聴」する。話を聞くのが上手い人は相手の話を聞いているという信号を常に送り続けている。話を聞くときは姿勢、相槌、共感、表情をコントロールする必要がある。
• 問題は解決してあげるのではなく、モヤモヤしない問題に変換してあげる。つまり、答えはまだ分からないが次にすべき行動が分かる状態にする。
• メンターとメンティの関係性を向上ためには、以下のことを意識する。
  • 謙虚・・・お互いの弱さを見せられる。
  • 敬意・・・お互いに敬意を持っている。(感謝を伝える)
  • 信頼・・・お互いの成長期待を持っている。 (意見を求める、頼る。→頼られるという体験は強烈な自己承認を生み出す)
• 関係性の向上によって、心理的安全性を高めることができる。心理的安全性は「課題や疑問を率直に話せるようになる」「心理的不安が減る」等の効果が得られる。

4. アジャイルなチームを作る

4-1. アジャイルとは

• アジャイルとは、チームをメンタリングし、成長させていく技術。
• 「ソフトウェアをどのように開発するか」はアジャイルの主眼ではない。
• アジャイルに関する言葉の意味は以下。
  • アジャイル・・・目的地。環境に適応して、最も効率よく不確実性を減少させられている状態。
  • アジャイルなチーム・・・目的地に向かうチーム。
  • アジャイルな方法論・・・目的地に向かうための考え方。どうやったら不確実性を減らせるか。
  • アジャイル型開発・・・目的地に向かうための移動手段。「アジャイルな方法論を取り組んだチーム」で実行されている開発プロセス。

4-2. アジャイルになるには

4-2-1. 不安と向き合う

• 「不安」を「何が不確実なのか」という問題に変換する。
• 1人で不安に向き合うのは難しいので、「チーム」で向き合う。そのために振り返りや学習という仕組みを取る。

4-2-2. 少人数の対話を重視する

• 大人数で通信不確実性を削減するのは難しい。
• できるだけ少人数でコミュニケーションをとり、情報共有を行う。これにより、情報の非対称性を減らす。

4-2-3. 役割を分けない

• 役割を分けることにより、異なる目的意識が発生してしまう。チーム全体の目的において、「自分は何をすべきなのか」の意識をもつ。

4-2-4. 経験のみを知識に変える

• 分からないことは実験してみる。そこで得た結果がチームとしての知識になる。

4-2-5. 意思決定を遅延する

• 大惨事にならないように、初期コストを抑えておく。状況・成果次第でコストを追加していく。

4-2-6. 価値の流れを最適化する

• プロジェクトの完了を目指すよりも、プロジェクトの永続を目指す。
• 継続的に顧客へ価値を提供することを主眼とした最適化を行う。

5. スケジュールマネジメント能力を向上する

5-1. スケジュールマネジメントとは

• スケジュールマネジメント(で大事なこと)とは、効率良くスケジュール不安を解消すること。
• スケジュール不安を解消するには、制約スラックと不安量の大きいタスクに注目する。

5-2. 制約スラック

• 依存関係によって発生してしてしまう無駄のこと。リソース制約と依存制約がある。

5-2-1. リソース制約を解消する

• この作業は〇さんにしかできないとうような属人化した作業のこと。
• 〇さんが行ったほうが効率的であるが、その作業をできる人を育成していくことによって、リソース制約を解消できる。

5-2-2. 依存制約を解消する

• 作業と作業の間にある依存関係のこと。例えば「APIができていないとUI作業ができない」といった依存関係があるときに生まれる制約。
• 依存関係を解消するためのアイディアを出すことが重要。例えばダミーデータを返すAPIを作成することで、依存関係を解消できる。

5-3. 不安量の大きいタスク

• 不安量の大きいタスクは、スケジュール不安に繋がる。

5-3-1. 不安量の大きいタスク順に問題解決をする

• 順番を考えずにタスクを実施していくと、不安が大きいタスクが後ろ回しになってしまい、タスクを消化してもスケジュール不安が減っていかない。
• 不安量を基準にタスクの優先順をつけ、それに沿ってタスクを消化してくことで、早期にリスクを減らしていくことができる。不安の量を見える化することが重要である。

5-3-2. 不安量の大きいタスクを分解する

• 不安量の大きいタスクを分解することで、どこか不安でありのか、何をすれば不安でなくなるのかが見えてくることがある。
• ソフトウェア開発においてスケジュール不安の発生源になるようなものは次のようなものがある。
  • 使ったことのないライブラリの使用
  • うまくいくかわからないアルゴリズムの使用
  • 外部との連携
  • 詳細仕様が未決定
  • 影響範囲が読み切れない
• スケジュール不安の発生源がタスクの一部に隠れているために、不安量が大きく見積もられてしまう。これらは別のタスクとして切り出すことで、優先順位の自由度が増す。

6. 組織の生産性を向上する

6-1. 生産性とは

• 生産性とは、不確実性を効率よく削減できる企業の情報処理能力のこと。
• 情報処理能力の低い組織は、市場の不確実性にうまく対応できない。
• 情報処理能を向上するには、技術的負債の減少や、目標の管理といった方法がある。

6-2. 技術的負債

6-2-1. 技術的負債とは

• 早さを求めて構築されたシステムの課題が負債となっている状態。技術的負債は不可解な開発速度の低下に繋がる。
• 品質のよくないコードを使い続けることは、借金の利息として捉えることができる。
• 開発初期は、今まで積み上げてきたシステムもないので、新機能の開発も比較的簡単に行うことができる。しばらく開発を続けると、今まで開発してきたシステムが逆に制約となり、考えないといけない範囲が広がっていく(=ジェンガの後半のような状態)。

6-2-2. 技術的負債を減少する

• 「ここは変わることがあまりないだろう」という部分を固定的に作り、「ここはよく変わるかもしれない」という部分を変動的に作る。(設計をきっちりやる。)
• 綺麗なコードはシンプルな構造をしているコード。汚いコードは複雑で整理されていないコード。汚いコードは技術的負債になりやすい。
• 開発者がすべきことは、今必要な機能をシンプルに作ること。シンプルに作るのか、複雑に作ってしまうのかはトレードオフにならない。

6-3. 目標を管理する

6-3-1. 目標とノルマ

• 目標とノルマは別物である。
• 不可能ではないが挑戦的な目標を、社員が自ら設定し、社員が納得して達成に臨むこと。
• 自発的な目標設定をする場合、社員は目標に向かって熱心に取り組むようになる。

6-3-2. 目標の透明化

• 目標設定を通じて、従業員1人1人が組織全体を見渡す。自分が何のために仕事をしているのかを意識する。
• 「会社目標」「部署目標」「チーム目標」「個人目標」を設定し、社員から経営者へ、また経営者から社員へ、情報を公開する。情報の非対称性を減らす。

7. マインドマップ