GW読んだ本
すでに年明けの目標は達成できないでいる。
本を読むときについつい先頭から丁寧に読んでしまう。とてつもなく効率が悪い。
本を読むのが下手なのでコツが知りたい。
チームトポロジー
GW前からのんびり読んでいたチームトポロジー。
pub.jmam.co.jp
「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則を踏まえて適切なソフトウェア開発組織を設計するという内容の本。
単純にチームを疎結合にしようとかではなく、以下の4つのチームと3つのインタラクションモードを定義して、それぞれの依存関係を減らして目標に向かって進む組織を作る。
チームの種類
- ストリームアラインドチーム
価値のある単一の仕事のストリームに沿って働くチーム。ベースとなるチーム。
- プラットフォームチーム
一部内部サービスをPFとして提供することでストリームアラインドチームを助ける。
- イネイブリングチーム
特定の領域のスペシャリストから構成され、ストリームアラインドチームの能力ギャップを埋めるのを助ける。
- コンプリケイテッド・サブシステムチーム
専門知識が必要となるパーツの開発・保守の責任をもつ。
インタラクションモード
- コラボレーション
チーム間で密接に協力して作業する。
- X-as-a-Service
最小限のコラボレーションで提供・利用する。
障害を取り除くために支援をしたり受けたりすること。
個人的にはこの組織構成の考え方よりは、チームの認知負荷を制限して、チーム間のコミュニケーションを明確にするという解きたい目的の部分の納得感とともに実態として難しさを感じるなという印象があった。
この形のほうが成果が出るという期待はあるし、おそらく当事者もこちらのほうが成果が出るという理解はできると思うが、認知負荷の制限の進め方を間違えると認知機会を奪われているというふうに考えてしまうことが結構ありそうな気がする。
特に専門家チームがストリームアラインドチームをサポートする体制になったときに、それぞれの役割と考え方を明確に理解させておかないと、「このチームはいい所取りをしている」、「このチームだけ新しいことをやっている」といった軋轢を産むことになりかねないなぁと思った。
また、いろんなことを知っていたい、広く裁量を与えられたいという考えは持ちがちだし、そういった人が評価されやすくなってしまいがちなので、配置の意義から成果報酬の考え方までが一貫していないと機能しないんだろうなと思う。
この辺の話はこの書籍の考え方云々というより組織マネージメントの課題という感じだけど、機能する組織と個人のやりがいみたいなところを完全につなげるのは難しいなというところを改めて感じた。
ジョブ理論
会社の上司から薦められた一冊。
イノベーションにおいて大切なのは、どうやってプロダクトの質を高めるのかを考えるのではなくて、ユーザーがどんなジョブ（用事、仕事）を片付けたくてそのプロダクトを雇用するのかであるという主張がされている。
相関関係から何かを見出そうとするのではなくて、因果関係のメカニズムを踏まえてイノベーションを成功させるという考えのもと、少量のインタビューデータなどを深く掘り下げて、ユーザーがどんなジョブを解決するためにそのプロダクトを活用したのをかを様々な事例とともにまとめている。
最初に出てくるミルクシェイクをなぜ購入するのかを掘り下げた内容などは非常に面白い。
プロダクト開発においてそれが十分に優れているかを追い求めすぎると永遠に完成が見えなくなるが、こういうジョブを解決したいユーザーにとって十分に役に立つか、という問いであれば答えが得られやすいというところも納得感があった。
日頃からデータを扱う立場からすると大規模なデータからはイノベーションを生まれなさそうな旨の指摘が結構されており、ビッグデータがイノベーションをなかなか産めていないのはそのとおりだよなと同調する部分もあった。
あと人が作ったデータは、人がデータから出した結論には大いにバイアスがあるとかそのへんは難しい課題だなと思わされた。
そう思うと会社の分析部隊を事業から独立させた立場においたり外部から雇うのは割と理にかなっているのかもしれない（それでも会社のデータを扱う以上はバイアスを取り除くのは不可能だけど）と思ったりもした。
余談だけど文中でamazonを優れている例としてあげていたが昨今のamazonはそうだっけ...と思ったところもあったりした。
