モニターの向こうがわ

Webサービスやアプリを作っている人が見たり考えていることを綴っています

when you gaze into your monitor, the monitor also gaze back into you.

読書メモ:チームが機能するとはどういうことか

まだ最初の10%くらいしか読んでないけどメモ。

 

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

 

「行動するための組織」と「学習するための組織」

本書では組織が何を主眼においているか?について「行動」と「組織」で二項分類している。

行動するための組織

アメリカのフォードとその片腕テイラーが開発した、プロセスを重視する組織を指す。管理と計画に重きをおき、遂行における効率性を高めることが目的。そのため、作業の単純化および作業員の作業内容の透明性を高めた。プロセスに従っているかどうか、その効率が良いかどうかによって作業員の評価を行う。作るものがはっきりしている環境においてはこのプロセスおよび組織が功を奏し、フォード社は1900年代において栄華を極めた(2000年代にトヨタにその座を奪われるまで)

学習するための組織

現代のダイナミックで不確実性の高い環境ー顧客期待の変化、グローバル化する競争、テクノロジーの発達や法的環境の変化による参入障壁の低下によるものーにおいては、複雑適応性の高い組織でないと生き残っていけない。そのため、プロセスに従う組織よりもプロセスを発展させ、イノベーションを起こす組織に変える必要がある。

これまでの効率の良い実行を可能にするマネジメントは、組織学習や革新を阻害していまう可能性がある。学習するための組織は、学習してから行動するのではなく、試みを行うリスクを許容して行動して学習する。プロセスを職能や専門知識によって分割するのではなく、これらを統合する。台本のない世界に道を作っていけるのは、学習する組織である。

ウォーターフォール開発とアジャイル開発

ここからは現時点での所感なのだが、上記の組織対比はまさしくソフトウェア開発におけるウォーターフォールアジャイルなのではないだろうか。

計画されたマイルストン上において中間成果物を次段階に渡すことで、プロジェクトを進めていくウォーターフォール(管理計画を重視する・作業内容を透明化する)。一方、動くソフトウェアをマーケットに出すことを再優先して「顧客に問い学習すること」を旨とするアジャイル開発。

そもそもアジャイル開発が、変化の激しい環境に適応するために作られたものであるので、この対比はしごく当然なのだが。

で、最近私の身の回りでは、あらゆる案件において開発プロセスアジャイルにするという流れがある。新規開発であっても、既存事業の漸進的改善(エンハンス)においてもだ。この流れに対して直感的に疑問を抱いていたが、この本がヒントをくれたような気がする(といってもまだ冒頭10%しか読んでないけど)。

既存事業のエンハンスにおいてはアジャイル開発はフィットしない

そもそもエンハンスとアジャイル開発の目的が一致しない。エンハンスは既存事業が抱える課題を改善するためのアクティビティだ。その問題というのはおおよそ事業の財務的KPIに変換できるものであり、エンハンスプロジェクトにおいて成果基準はそのKPIを改善できたか(目標数値にまで到達できたか)である。

このような案件にアジャイル開発部隊をあてがうと、以下のような弊害が起きると思われる。

  • 「学習」を試みた結果、事業数値に悪影響を及ぼす
  • 「学習」する機会を増やすために、リリースの質より量を優先してしまう
  • 「学習」を基準にしたリリースサイクルに合わせるため、課題設定・解決策にかける時間も短くなってしまう

箇条書きにしてしまったけど、要するにQCDのうちDを優先するあまりQが疎かになる、ということ。

エンハンス案件においてはウォーターフォールがベストプラクティスか?

まだ自分の中に答えはないが、おそらくYES。専門家による現状分析、課題設定、解決策検討、およびそれらプロセスを何度か繰り返すことによる発散と収斂。これによって確度の高い施策を生み出す。開発工程へ入るのはその後。これを実現するのは、管理計画を徹底して行うこれまでのプロセスが良いのではないか。

どのようなサービスが向いているか?

サービスのライフサイクルを誕生・成長・成熟・衰退と分けて考えた時、成長・成熟ステージにあるサービスはウォーターフォールで開発を行うのが良い。これら段階にあるサービスは事業方向性がすでに定まっており、スケールしていくことが優先課題である。作るものが決まっており、それをどう磨いていくか?を考える段階。

一方、誕生ステージにあるサービスは(何をもって誕生とするか定義が必要だが、ここではあくまでイメージ)Product/Market Fitにまで達しておらず、顧客開発やPivotを繰り返して、サービスの方向性を探る必要がある。このような状況では事前計画を立てることができないので、アジャイル開発でとにかく顧客に問うタイミングを増やし、フィードバックによって学習して次の打ち手を繰り出すことが重要(Lean的な)

また衰退ステージにあるサービスは、このまま手なりで死んでいくことを避けるために、新しいサービスの方向性を探る必要がある。そのためには誕生ステージにあるサービスと同様、様々な釣り針をマーケットに垂らしてどれが食いつくかを試したい。よって誕生ステージにあるサービスと同じスタンスで挑む。

 

まとまらないが、とりあえず。まとまったら別タイトルのエントリを書く。