suusan2号の戯れ

SIerでインフラSE⇛WEB系でエンジニアのおっさん

「チームが機能するとはどういうことか」を読んだ

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

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

一ヶ月くらい前にnaoya_ito さんの記事を急に思い出して読んでみたらとても良い事が書いてあった。この本は、資料の参考文献で強くおすすめされていたので買って読んでみた。

まとめ

プロセス知識スペクトル

この本で繰り返し言われているのは、仕事の中にも「知識の成熟度」と「不確実性」に応じてルーチンの業務、複雑な業務、イノベーションの業務 があり(本の中ではプロセス知識スペクトルと言われる)、それにより適切なチーミングと学習のあり方を変える必要があるということだった。新規事業のような不確実性の高い仕事と、書類仕事のような手順の決まりきった仕事では、当然ながら仕事の進め方や許される失敗は異なる。当たり前のことではあるのだけれど、自分の業務がどういう位置づけのものなのか、このような分類を意識して考えたことがなかったので新鮮だった。

心理的安全

今でこそ「心理的安全が大切」というようなことはよく言われているのだけれど、なぜ心理的安全が大切でそれによってどんなことが実現されるのか、といったことをきちんと説明してくれている。また心理的安全な環境を生み出すには、リーダーがどのような行動を取る必要があるのかということも記載されている。紹介されているリーダー行動のなかで、個人的には以下が特に重要なんじゃないかと思う。

  • 現在持っている知識の限界を認める
  • リーダーが自分もよく間違うことを積極的に示す

エンジニアに限らないけど、リーダーになるような人はプレーヤーとしても優秀な人が多く、チームメンバーからすると「とりあえずリーダーの言うことに従っておこう」となりがちなんじゃなかろうか(※自分はあまり思ったことないけど、そんな雰囲気を感じるチームは見たことがある)。

境界を超える

組織のなかでチーミングをするときによくある3つの境界として以下が紹介されている。

  • 物理的な距離・・分離による相違
  • 地位・・・格差による相違
  • 知識・・・多様性による相違

個人的には知識による相違について説明している箇所に頷くポイントが多かった。設計・モデリングをするときに、登場人物の関連図やユースケース図を関係者でワークショップ的に作るということをやると、システムに対する理解度が圧倒的に上がって、その後の開発がとてもやりやすくなった経験があるんだけど、こういった図・試作品をバウンダリーオブジェクトというらしい。バウンダリーオブジェクトを使うことで、職業や専門知識による境界が取り払われやすくなるらしい。

フレーミング

またこれまで「目標はワクワクするものがよい」ということを何となく思っていたのだけれど、それはフレーミングというものだったんだなーということがよく分かった。

著者がMICSという新しい医療技術を導入するというプロジェクトを調査した結果、成功したプロジェクトはフレーミングが異なっていたそうだ。フレーミングとは一言でいうと「プロジェクトをどのように解釈するか」ということだと思う。成功したプロジェクトではリーダーが、新技術の導入を「患者の利益」「チームの能力を高める」といった目的で捉えていたのに対し、失敗したプロジェクトでは「世間に遅れをとらない」といった後ろ向きの目的で捉えていた。目標が前向きなチームでは「患者が少しでも早く快復する手助けするときのワクワクした気持ち」を感じたり、「自分たちの可能性を試す機会」とメンバーは考え、積極的にプロジェクトに関わり助け合っていた。

これは自分がちょうど最近まで関わっていたシステムリニューアルのプロジェクトがそうだったと思う。単純に「レガシーなアプリケーションがメンテ不能になったのでリプレースします」ではモチベーションを保つことが難しかったと思うが、「レガシーなアプリケーションをモダンな技術を使って社内外に誇れるアーキテクチャにしていく」という目標(まあ明にこんなことを言われてたわけではないのだけれど、そんな雰囲気はあった)があったからやっていけた感はあった。

感想

決して読みやすい本ではなかったのだけれど、最近よく言われていることが体系的にまとめられており、学びがあった。これを読んだ上で naoya_ito さんの資料を見てみると、あーこれはこの本からの話かーというのがいくつかある。naoya_itoさんの資料にも、文化を変えようとすることは悪手だと書かれているんだけど、この本にもまさになことが書いてある。

学習する文化は、新しい働き方―なおいっそう、相互依存し、ほかの人の仕事や必要性に気づき、向上しようとする働き方―を実践する副産物として現れるのであって、その逆ではない。

もっとこういう文化にしたい・・・といった話は大なり小なり今の組織でもこれまでいた組織でも上がってきたんだけど、結局のところ今目の前にある仕事をどのように行っていくのか、その働き方を変えていく、なぜ働き方を変える必要があるのか同意する、というプロセスを踏まないと文化は変わっていかないんだなー

特にソフトウェアエンジニア向けの本というわけではなく、本書の中の例でもソフトウェアエンジニアの例が出てくることは殆どない。スクラムアジャイルといったキーワードも登場すらしていないんだけど、これらの文脈で出てくる話と類似するものが多いのはちょっと驚いた。