ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

組織やチームづくりに役立つ20冊

こんにちは。@ryuzeeです。最近、組織やチームのことを考えるヒントになる本を紹介してほしい、と言われることが多いのでダンプしておきます。あくまで自分で読んだ私見で選んだものなので、この定番がないのは何故だとかはあると思います。

定番

「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」とあるように、ソフトウェア開発における問題点を人間の観点で整理している名著。第IV部では生産性の高いチームを育てるというテーマで機能するチームの特徴やチームの壊し方(守りのマネジメント・官僚主義・作業場所の分散・時間の分断・品質の削減・はったりの納期・チーム解体の方針)についても説明している。作業場所の分断についてはリモートワークの方法が洗練されてきてる現状はありつつも思い当たることも結構ある。

分量が約450ページあるうえに理論の話が多いので最初に読むにはハードルが高いかもしれない(しいきなり読むとたぶん挫折する)。ただワークショップの例、分析方法の例、そして事例なども含まれているので参考書籍としては一読しておくとよい。現場のリーダークラスというよりはもうちょっと上の立場の人が対象。

「最強組織の法則」の増補改訂版。センゲは、メンタルモデル・自己マスタリー・システム思考・共有ビジョン・チーム学習の5つが組織に必要だという考えを広めた人。

読み物系

ディシジョンテック社という創業約2年のベンチャー企業に立て直しのため畑違いな分野からやってきたCEOがいかに経営陣のチームを変えていくか、というフィクションを元に機能しないチームの特徴や、それへの対応方針を説明している。物語が全体の8割くらいを占めるので、これを読んだあとに他の本で補うといいかも。信頼の欠如 / 衝突への恐怖 / 責任感の不足 / 説明責任の回避 / 結果への無関心という構造は分かりやすい。かなり古い本だがオススメ。

著者のジーンキムはDevOps系の著名人。こちらもある日前任者の退職で突然システムの責任者になった主人公が、いかにシステム開発における問題点をカイゼンしていくかという物語を通じてDevOpsを説明している。DevOpsはツールだけでなく主に組織的な問題への対応であり、この中でも組織をどのように変えていくかという話がふんだんに出ている。ツールの銀の弾丸が大好きな人に先に読ませておくべき一冊。

入門系

すべての組織は病んでいる / 戦略至上主義という病 / 犯人探しという病 / 会議が空回りする病 / 「最近の若者は」という病 / 「何回同じことをいわせるの?」という病 / ものさし不在という病 / 決断が先送りにされる病 という病をあげてそれに対してどう取り組むかを解説した書籍。理論ではなく実践の書籍で1時間くらいで読めると思うのでオススメ。

組織開発とは組織の主に人間的な部分に焦点をあてその変革に取り組むこと。組織開発ではさまざまな手法や理論を使うことになるが、それらの理論を初心者用に解説した書籍。「実際の生産性=潜在的生産性 - 欠損プロセスに起因するロス」というのは分かりやすい。

事例系

これは説明するまでもない一冊。グーグルにおける文化・戦略・意思決定・採用・コミュニケーション方法などを詳しく解説している。この中で採用はいちばん大事な仕事と明言している。

こちらはグーグルの人事担当上級副社長のラズロが主にチームでの働き方や、一緒に働く人の採用や評価の仕方・報酬の設定などフォーカスして解説した本。採用面接に関していえば、直感を信じてはいけないという章で詳しく説明されている。一方で多くの日本企業では面接のスキルややり方について教育が行われていないしカイゼンが行われていないことは驚くべきことでもある。

生産性・人を雇う・文化といったあたりの章は組織やチームづくりに大いに役立つ。体系的に組織についてまとめた本ではなく37シグナルズの働き方に関する本で読み物として非常によくまとまっている。

サイボウズの創業者の1人で現社長の青野氏による著作。現在こそ、社員が辞めない会社、辞めても6年の間は戻ってこられる出戻り推奨の会社としても知られているが、2000年代中盤は高い離職率に苦しみ、本業と関係の少ない事業投資によって会社が疲弊していたらしい。そこからどのように考えて現在のような姿に変えていったか分かる生々しい事例。社長自らが育児休暇とったりしてすごい。

組織内での浸透や推進

日本に頻繁にやってきてくれるCopeさんの大作。パターンとは、ある文脈で繰り返し起きる問題を解決する方法であり、本書では組織の漸進的成長のためのパターン、組織構築パターンが多数紹介されており、それらのパターンを組織にどう適用していくかも解説している。ぼくは「自分たちで選んだチーム」「チームのプライド」あたりが好き。

こちらもパターン。タイトルに「アジャイル」とあるがべつに適用範囲がアジャイル開発に限定されるわけではまったくない。ぼくが好きなのは、定番のエバンジェリストのパターンで、何か新しいものを自分が組織に導入するのであれば自分自身をまず最初に説得し、自分の理念を確信し、情熱をもって取り組むことを指す。

さきほどから何度か登場しているグーグルのエンジニア2人が書いた開発チーム向けの書籍。グーグルの一貫性のある考え方がよく現れている。約170ページで非常に読みやすい翻訳でもあるので、分厚いのはちょっと、という人はまずここから読んでみるといいと思う。

軍隊を舞台にしているのでスマートじゃないんじゃないか?と不安になるかもしれないが全く心配いらない。冒頭で「束縛をゆるめればゆるめただけ、すぐれた結果が出る」「自分のプライドよりもチームの実績を優先させなければならない」などの記述からもわかるはずだ。これもすぐ読めておすすめ。

リモートワーク

リモートワークに関するまとまった書籍としてはこれが初めてだと思う。人材は世界中にいる / リモートワーカーは人柄 / 賃金差別をしない / テストプロジェクトで試すあたりは定番でたぶんソニックガーデンさんも同じような感じではないだろうか。従来型の組織でリモートワークに移行しようとするとマネジメントスタイルを変えないといけないのは言うまでもない。

元マイクロソフトの著者がWordPress.comを運営するAutomattic社にジョインして過ごした約1年半を振り返ってたノンフィクション。「すぐれたリーダーの最後の仕事は、自分がいなくなったあとも万事うまくいくようにしておくことだ」

37シグナルズ本と重なる内容は多いが日本でもここまでできることが分かる良書。特にマネジメントがどう変わるかについて詳細に述べているのが良いところ。採用に時間をかける / 全員がセルフマネジメントする / 成果はチームのものという考えなど、リモートかオンサイトか関係なく役にたつ。

会議

日々たくさんの会議がおこなわれている割に問題の解決に至らずだらだら時間が過ぎてしまうというのをよく見かけるがそういう時に使ってみるといいかも。特に苦しい状況のときには。個人的には、言葉のフォーマットを変える「製品にバグが多い」→「どうやったら製品のバグを減らせるか」とか、言えない問題を言ってみる、あたりのプラクティスがいいと思う。

ちょっと表現が誤解を生む(意思決定者は会議にでないとか、キャッチーにするために仕方ないのか)箇所はあるものの、1日集中討議でその日のうちに結論を出すのを仕掛け化しているのはいい。そして議論を円滑に進行できるように付箋紙や必要な道具がいつも常備されているのもいい。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 【資料公開】強いチームの作り方(デブサミ2016版)
次の記事 スライド共有アプリをAzureに対応させた話

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World