デッドライン(締切)を味方につけて、積読を消化する読書会:デッドライン読書会第14回の感想文投稿です。第14回の課題図書は前回に引き続き「チーム・ジャーニー」で、後半戦になります。

 デッドライン読書会ってなんだ?は下記の投稿をご参照ください。

課題図書

 第14回の課題図書は、市谷 聡啓さんのチーム・ジャーニーです。

[amazon asin=”4798163635″ price=1 kw=”チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで”]

 本書は2部構成になっており、第14回は後半戦の第2部が対象となります。

  • 第1部 僕らが開発チームになるまで
  • 第2部 僕らがプロダクトチームになるまで

前半戦の感想文はこちらのポストになります。

感想文

全体

 第1部では主人公の太秦(うずまさ)さんがチームリーダーとなり、タスク管理ツールの開発を行っていました。第2部では周辺のチーム(チャット機能、ドキュメント作成機能)も合流し、プロジェクト管理ツールを作成するストーリーへと進んでいきます。太秦さんはこのプロダクトチームのチームリーダーとなり、ステアリングコミッティの一角としてプロダクトを作り上げます。単独のチームリーダーから、複数のチームを束ねるリーダーへ、最後はさらにその先へ進んでいくのが本章です。

 先に概要を書いたとおり、太秦さんは複数プロダクトのチームリーダーを担っています。私も過去、複数チームが連携して一つの製品・システムを作り上げていくプロジェクトを経験したことがあります。少し大きめの開発ではよくあるシチュエーションかと思います。サブシステムチームにいたり、横断チーム(共通機能チームや、認証チーム、アーキテクトチーム)にいたり、ステコミチームでチーム間のカタライザ(情報の流通)を担当したこともあります。それらのプロジェクトを思い出しながら本書を読んでいました。特に第2部の前半のテーマである、

  • チーム同士が向き合うこと
  • チーム間の境界を調整すること
  • 横断チームの結成
  • チームとチームをつなげること、全体として一つの方向を見ること

には常にがむしゃら(文字通り「勢い」)で向き合っていたことを思い出しました。第1部に引き続き感じたことですが、チーム(第2部ではチーム間)のカイゼン活動を、目標を持ち、計画的に、段階的に進めることが、いかに大事かです。開発プロジェクトで炎上してから対応を行うことが多かったため、その結果、稚拙だったり、近視眼的だったり、その場しのぎ的な施策に陥ってしまったことが多かったです。

 繰り返しになりますが、チームのカイゼン活動は、

  • 目標を持ち
  • 計画的に(見通しを立てて)
  • 段階的に
  • 根気よく
  • チームのメンバーも巻き込み

進めていくことがミソなんだと思います。こうやって箇条書きにすると、どれも当たり前のことだと気づきますが、それを確実に実践するのがまだまだ私にはスキル不足と感じるところです。

 第2部後半では、会社組織やユーザーを踏まえた視座・視野のお話、誰も正解が分からないゴールへ向けて仮説検証をしていくお話が続きました。

個別

 個別に気になったフレーズを引用します。

リーダー会をすべてについての意思決定機関にしてしまわないことです

P.189 第10話 チーム同士で向きあう

 リーダー会(その他の横断組織)は放っておくと、内外の期待(?)から意思決定機関になりがちだと思います。例えば、早く決めたい、チーム間で意識を合わせたい、といった期待です。リーダー会で決めるレベルを全体で共有しておく。詳細を決めすぎたり、かつ、チームへの情報の還元が一方通行にならないようにすることが大事。

②番頭の輪番化

P.209 第11話 チーム間の境界を正す

 他チームからの依頼や質問などに対応するために、専任の「番頭」を立てるプラクティスを紹介しています。番頭は、モチベーション向上や、スキルアップを目的として「輪番」で運営するのが良いとのこと。これは機会あれば選択肢としてもっておきたい。

 なお、マイクロソフトの牛尾さんもブログで「オンコール(顧客からの不具合対応依頼)がローテーションで回ってくる」といったことを書いていらっしゃいました。

プロダクトのエンジニアはオンコールと呼ばれる、お客さんから上がってきた障害報告のみに対応する週間があります。ローテーションで回ってきます。

(中略)

自分が担当していない部分のアーキテクチャを学べたり、知らないことの調査の過程で教えてもらえるので、かなり理解も深まって一石二鳥で楽しいです!

https://simplearchitect.hatenablog.com/entry/2020/05/25/081302

 つづいて、こちら。

共同化とはあくまで同一の状況を作り出し、結合点を作り出すイメージだ。その先にあるのは、協働化だ。

P.268 第14話 クモからヒトデに移行するチーム

 標準化だけを目指すのではなく、共同化→協働化と進めていくと。共同とは、時間・場所・仕事をともにすること。協働とは、上記引用の引き続き説明がありますが、下記の通り。

協働とは、ミッションを共有し、お互いに協力しながらその達成へと向かう相互作用のことだ。

P.268 第14話 クモからヒトデに移行するチーム

 共同から協働へ、一歩前に進むにはどういったことができるだろうか。そのヒントが本書でも紹介がある「他者と働く」から学べるかもしれませんね。

[amazon asin=”B07Y5FF3M4″ price=1 kw=”他者と働く──「わかりあえなさ」から始める組織論”]

 なお、仮説検証について本書でも触れられていましたが、詳しくは「正しいものを正しくつくる」が良いとのことでした。今読んでいるところなので読み終わったら感想書いてみたいと思います。

[amazon asin=”4802511191″ price=1 kw=”正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について”]

次回

  • #15
    • 他者と働く──「わかりあえなさ」から始める組織論
  • デッドライン
    • #14の感想交換1Week(6/1〜7)
    • インターバル(6/8〜14)
    • #15の読書する時間2Week(6/15~27)
    • #15のブログポスト期限(6/28)