EurekaMoments

新米エンジニアが一人前を目指す修行の日々を記していくブログです。

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

背景・目的

ここ最近の自分のソフトウェア開発業務は、開発の納期に追われつつも、目標とする性能をなかなか達成できなくてかなり苦労していました。自分は管理職ではなくただの一般社員ですが、それでもソフトウェア開発を行うチームとして業務改善を行える余地がたくさんあるんじゃないかと思い続けていました。
何か解決策はないかと調べていたところ、とても参考になりそうな書籍を見つけたので、今回はそれを読んで参考になったポイントを書き留めておこうと思います。

参考文献

思考のリファクタリング

  • 頭の中で発生してしまう無駄なプロセスを削除して、考える時の指針を持つことで、問題解決に向かって明確に行動ができるように促す。
  • どうしたら効率良く、不確実性を減らしていけるのか、を考える。
  • 「不確実なもの」とは「未来」と「他人」の2つ
  • 「不確実性を下げること」は「情報を生み出すこと」。いかに多くの情報を生み出せるか。
  • 複雑な問題を簡単な問題に変換していく
  • 出来る限り正しく事実を認知する。そのためには、自分の認知が、いつ、どのように歪むのか知る必要がある。
  • 感情に囚われ、つい非論理的に考えてしまう瞬間を知っておく。
  • 人は自分が間違っているかもしれない事を無意識に避けてしまい、正しい情報を認知できない。「自分は間違っているかもしれないが、それに早く気付いた方が良い」と思考のパターンを変える必要がある。
  • 仕事の最初期に、不確実なものから確実に仕上げていくと早い段階で全体像が見えてくる。それに対して確実なものから仕上げていくと、終盤を迎えるまで全体像が見えない。
  • 「何が仮説なのか」、それをどうしたら「検証できるのか」を明らかにする。
  • 数少ないデータから大胆に仮説を推論し、それが正しいのかという検証をするための行動を取ることが重要。
  • 思考で重要なのは、自分の知性に対する絶え間ない疑いと、自分自身への洞察力である。

メンタリングの技術

  • 自分の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を補正し、成長させていく。
  • コードレビューでは、「なぜ、そのようにしたのか?」ということを問いながら、その人自身が指摘のポイントに気が付いてもらうことを促せるのがベストである。
  • コードの修正案をつけて、相手に考えさせる。
  • ペアプログラミングが上手くいくと、2人バラバラの生産性と同程度のコード量を生産でき、バグ発生率などのクオリティに関するパラメータが有意に改善される。
  • 小さな成長実感だけでなく、大きな目標達成やゴールの認識を合わせていくことが重要。
  • 相手が「悩んでいる」のか「考えている」のかを判断する。
  • 「次にとるべき行動」がはっきりすれば「考える」ことはあっても「悩む」ことは無くなる。
  • 「共感」とは、「相手がそのような気持ちになった理由を理解する」ということ。傾聴において示すべきは「共感」であって「同感」ではない。
  • 最終的には、「これからどうするか」を話し合い、合意し、次回に振り返ることを約束する。

アジャイルなチームの原理

  • 実際の「アジャイル開発」は、チーム全体にメンタリングを行い開発出力を向上させる方法論である。
  • マーケット不安やスケジュール不安の両方を構成する大きな不確実性から優先的に対応できるようにする。
  • アジャイルをする」ではなく「アジャイルになる」、状態を表す言葉
  • チームが総体として、チーム自体のゴールに対して高い「ゴール認識」を持ち、チーム自体がチームをメンタリングしている状態を目指すこと。
  • チームが環境に適応して、不確実性を最も効率よく削減できているのが理想的な状態⇒自己組織化
  • 「不安に向き合う」: 問題を隠すよりもチームで共有する。
  • 「少人数の対話を重視する」: 情報がチーム内で偏ることを防ぐ。
  • 「役割を分けない」: チーム全体の目的において「今自分は何をすべきか」を考える。
  • 「経験のみを知識に変える」: 見積と実績を比較して、見積の精度を上げていくことを繰り返す。
  • 「意思決定を遅らせる」: あらかじめ大惨事にならないようにしておけば、意思決定を遅らせても大丈夫。
  • 「価値の流れを最適化する」: 継続的に顧客へ価値を提供することを主眼として最適化

学習するチームと不確実性マネージメント

  • 不確実性とは、「目的」、「方法」、「通信」の3つに大別される。
  • 不確実な要素をリストアップして、それらを比較する。
  • スケジュール不安とどのように向き合っていくのか、どのように可視化すればよいのかを中心にマネジメントする。
  • 「理想工期」: 総作業時間を人数で割ったもの
  • 「制約スラック」: 作業同士の依存関係による無駄、作業者の限定
  • 「プロジェクトバッファ」: 見積の不確実性を吸収するための期間
  • 「納期」= 「理想工期」+ 「制約スラック」+ 「プロジェクトバッファ」
  • お互いの得意分野を学び合い、どちらもできる人を育成することが大事
  • 会議を行うなど、意思決定や調整を必要とする場合も、制約スラックを膨れさせる。
  • どの程度の確率で完了できる作業期間なのかを考える。
  • 「間に合うか、間に合わないか」ではなく「スケジュール予測が収束していくかどうか」を管理する。
  • 最善ケースと最悪ケースの幅(不安量)を徐々に狭めていく。
  • 不安量が大きいタスクから順番に解決していく。
  • 不安量が大きいタスクは小さいタスクに分解する。

技術組織の力学とアーキテクチャ

  • システムを作る組織の構造は、その組織が作り上げるシステムの構造と似てくる(コンウェイの法則)。
  • コミュニケーションコストが多くかかるであろう環境ほど、バグが多くなる傾向がある。
  • システムの構造は、どこに機能を追加しやすくして、どこの機能はどこの機能は統一的に取り扱うのかというもの。

読んだ感想

バグを潰すのにてこずっていたり、プロジェクトが計画通りに進行できていなかったりすると、ついつい感情的になって非理論的な話をしてしまいがちになります。自分達が感情的になってしまう理由は、大抵は精神的な余裕がないときであり、その原因は納期に迫られている、あるいは遅れぎみになっている場合です。
不確実性とはいうものの、各TODOの計画見積の精度が上げられていないように思います。この本にあるように、最善ケースと最悪ケースを考慮した計画を立てれれば、もう少し余裕も持って作業できるのかもしれません。

また、目先の効率化を図ろうとして、自分が自信のない作業については他の得意な人にお願いしてしまうというのも、自分の開発チームでは起こっている問題の一つです。任されたタスクを完了させる自信が持てないのは、一人で完了させなければならないと思い込んでしまっている事、それを他の人がサポートしてあげれるようにマネージメントできていないことが原因かと考えられます。
例え不安で自信が持てない状態でも、それを周りがサポートして、本人が気持ちよく取り組むことができるようなチーム作りをしていくことも今後のチームとしての課題であると思います。