開発を行うチームをどう構築していくか?|『エンジニアリング組織論への招待』第3章【読書感想】

第1章、第2章は個人としての「思考のリファクタリング」「メンタリングの技術」がテーマでした。

第3章は「思考のリファクタリング」「メンタリングの技術」をベースに、「開発を行うチームをどのように構築していくか」という考え方や方法を説明しています。
本を読んで理解できたところを備忘録としてまとめます。

アジャイル開発とは

「ソフトウェア開発を行うチームをどのように構築していくか?」がアジャイルの目的です。
「アジャイル開発」はチーム全体に対してメンタリングを行い、開発出力を向上させる方法論です。
アジャイル開発は、プロダクトマネージメントで行います。

最初期には大雑把に見積もり、実際の開発工程にどの程度進んだかという実験的な知見とともに、どの程度の期間がかかるかを推計します。そして、それを繰り返していくことで徐々に方法不確実性(どのように作っていくか分からない不確実性)を減少させ、スケジュールの精度を上げるように振舞います。

リリースできない可能性が出てきたら、ビジネス価値が大きく損なわれない最低限の機能を最初期に作り、いつでもリリースできる状態にしてから、追加の機能を開発するといったアプローチを試みます。

このように、マーケット不安(マーケットで受け入れられるかどうかわからない)やスケジュール不安の両方を構成する大きな不確実性から優先的に対応できるようにするというのが、アジャイル開発の基本的な思想となります。

従来の開発と比べて3倍の成功率と1/3の失敗率

ITプロジェクトのリサーチを行なっているSTANDISH Group の2015年の調査によると、アジャイル開発は従来型の開発(ウォーターフォール)に比べて、平均して3倍の成功率と1/3の失敗率という統計が出ています。(CHAOS Report 2015 by STANDISH Group)

この結果から、大規模なソフトウェア構築にこそ、アジャイル開発はより効果的であることがわかります。

チームに対する考え方

アジャイル開発とは、「チーム全体をメンタリング」するための方法論であって、開発方式ではありません。
チームが総体として、チーム自体のゴールに対して高い「ゴール認識」をもち、チーム自体がチームをメンタリングしている状態を目指すことです。

このような状態は「チームマスタリー」があるといえます。この「チームマスタリー」がある状態のことをアジャイル開発の用語としては「自己組織化されたチーム」と呼びます。
個人がチームを、チームが個人を互いにメンタリングしている状態になり、結果的にチーム総体としては「チームマスタリー」を得ているように振る舞えることが重要です。

アジャイルな状態とは具体的には下記のような状態のことを意味しています

  • 情報の非対称性が小さい
  • 認知の歪みが少ない
  • チームより小さい限定合理性が働かない
  • 対人リスクを取れていて心理的安全勢が高い
  • 課題・不安に向き合い不確実性の削減が効率よくできている
  • チーム全体のゴール認識レベルが高い

それらを行いやすくするための方法論や枠組みが「アジャイル開発」と呼ばれるものの正体です。

アジャイルは理想状態

アジャイルという言葉は、「ある理想的な状態」を指しています。
理想的な状態というのは「チームが環境に適応して、不確実性を最も効率よく削減できる状態」のことです。これは、自己組織化とも呼ばれます。

これは理想的な状態なので、決して到達することのできないような高いゴールを指しています。

わたしたちはどうしたらもっと不確実性を減らすことができるだろうか?

理想の状態に向かうために常にこの問いが投げられます。

アジャイルな方法論

アジャイルな方法論は、「わたしたちはどうしたらもっと不確実性を減らすことができるだろうか?」に対する答えの1つです。
そのためには、不確実性を増大させる連鎖となる「システム」にアプローチする必要がああります。

不安に向き合うこと

わたしたちはわからないものに対して不安を抱えます。
不安に向き合い、解決しようと考えることで「認知フレーム(思い込みや感情によって受け止めかたが変わる)」を取り外し、前提条件や思い込みを乗り越えた解決策を模索することができます。これによって不安が通信不確実性(情報が正しく伝わることは限らない不確実性)へと転嫁されることを防ぎます。

少人数の対話を重視する

通信不確実性を極力削減するためには、大人数では難しくなります。
できる限り少人数で、最も情報の多い対面でのコミュニケーションによって情報共有を行います。これによって、「情報の非対称性(チーム内で情報が偏っている状態)」を減らすよう努めます。

役割を分けない

アジャイルな方法論で重要なことは、役割で関係性を縛らないことにあります。
自分が「役割を遂行するにはどうしたら良いか」ではなく、チーム全体の目的において「いま自分は何をすべきか」という問いをメンバーが常に保つようになるからです。

また、役割を分けない、決めないということは、ある専門性を持ったメンバーがいたとしても、必要に応じて、別の専門領域の事柄も手伝っていくように変化させていきます。そのときには、別の専門領域を持ったメンバーの補助を受けながら、新しいスキルを獲得するようになってきます。

経験のみを知識に変える

そもそもわからないものが不確実です。
実験を行う前にいくら実験結果について議論しても答えは出ません。まずは、実験をしてみることが重要です。そして得られた結果だけがチームにとって重要な知識になります。

脱構築

「アジャイルへ至るために、わたしたちは何をすべきか」「どうしたら、もっとチームの抱える不確実性を減らしていけるのか」という問いを持ち続けることが、アジャイルの起点です。

それに対する答えとして、今までとらわれていた常識の認知フレームの外にある認知をリフレーミングしていくことが、アジャイルな方法論を「チームメンタリング」であるとする理由です。

自分たちの状態や周囲に存在する不確実性をしっかりと観察し、チーム状態をよりアジャイルに導いていくための暫定状態で用いる手法のことを「アジャイル開発」と呼んでいます。

チームが同一でありながら、チームの内部に二項対立が生まれる場合、そこには「不確実性」が隠れていることを示唆しています。それを対話と熟慮を通じて、対立をそもそもなかった状態に解消するような視点を得て、自分たち自陣を再構築していくことを、「脱構築」と呼びます。

必要なことは、しっかりと自分たちを取り巻く状況を観察することです。そして今何をすべきかをしっかりと周囲と対話していくことです。それがチームをアジャイルにする最も効率的な道です。

まとめ

以前、会社で理事たちが話していた「自己組織化されたチーム」ってこれのことだったのか!
理事たちが目指すチームの理想をお話しされていた時、言葉としては伝わっているけどいまいちピンとこない状況でした。

今回、本書を読んだことで、あのとき理事たちが言いたかったことはこのことだったと気付きました。
これからは具体的な行動を起こせそうです。

わたしたちはどうしたらもっと不確実性を減らすことができるだろうか?」と問い続けていきます。

Be Agile! (アジャイルになれ!)

フォローお願いします