最近、Kent Beck氏の「Tidy First? ―個人で実践する経験主義的ソフトウェア設計」を読みました。本書はソフトウェア設計における実践的なアプローチを提唱する素晴らしい本なのですが、エンジニアリングマネージャーとして読んでいくと、組織開発にも応用できると感じました。今回は、本書から得られた組織開発への気づきを共有したいと思います。
1. 構造の変更と振る舞いの変更
本書で最も印象的だったのは、「構造の変更」と「振る舞いの変更」を明確に区別する考え方です。ソフトウェアにおけるこの区別は、組織開発においても重要な示唆を与えてくれます。
ソフトウェアにおいて、新機能の追加は「振る舞いの変更」、コードの整理は「構造の変更」です。同様に、組織においても以下のような区別ができます。
- 振る舞いの変更：新機能の開発、顧客要望への対応、売上に直結する施策
- 構造の変更：チーム構造の最適化、開発プロセスの改善、組織的負債の返済
これらは両方とも価値を生みますが、本質的に異なるものとして扱う必要があります。
2. チームのオプショナリティと生産性のバランス
本書では「オプショナリティ」という概念を重視しています。これは「将来の選択肢を確保すること」を意味します。チームマネジメントにおいて、この考え方は非常に重要な示唆を与えてくれます。
短期的な生産性を追求するなら、各メンバーが得意な領域に特化して黙々と開発を進めるのが最も効率的に見えます。しかし、それは同時にチームの将来の選択肢を狭めることにもなりかねません。
例えば、以下のような点が挙げられます。
- 特定のメンバーにしか触れないコードが増える
- チーム全体の技術的な視野が狭まる
- 急な人員変更に対応できない
- 新しい技術への適応が遅れる
これらのリスクに対して、チームのオプショナリティを高めることは一種の「保険」として機能します。一見すると非効率に見える活動（ペアプロ、モブプロ、勉強会など）も、チームの長期的な適応力を高めるための重要な投資として捉えることができます。
3. 価値創出のタイミング - 組織開発はいつ行うべきか
新機能開発とチーム改善は、常にトレードオフの関係にあります。
- 今すぐ新機能を出して売上を立てるか
- 開発速度を一時的に落としてでも振り返りや対話に時間を使うか
本書では「不確実性が高い環境ではオプショナリティの価値が高まる」という重要な指摘があります。これは組織開発のタイミングを考える上で重要な指針となります。
4. 漸進的な改善アプローチ
本書では「整頓にかけるのは数分からせいぜい1時間まで」という具体的な指針が示されています。この「小さく始める」というアプローチは、組織開発においても非常に有効です。
実際に私が経験した例として、当初は各々の専門性を活かせる良いチームだったのですが、徐々に技術選定や設計について意見の相違が目立つようになり、コミュニケーションコストが増大していきました。その結果、開発に集中できない状況が生まれ、チームに溝ができてしまいました。その状態からプロセスを改善しようとしましたが、すでに手遅れでした。この経験から、チームの状態を定期的にメンテナンスすることの重要性を学びました。
また、チーム間でも同様のことが起きますので、組織の中長期的な視点を持つミドルマネージャーはチーム内とチーム間の関係性について、小さな改善を回す必要があると思います。
5. オプショナリティの広がり
ここまでチームを主語で考えて来ましたが、本書で語られている「オプショナリティ」の考え方は、技術的な文脈を超えて幅広く応用できます。
- 異なる開発アプローチを選択できる柔軟性
- 市場の変化に応じたチーム再編成の容易さ
- 多様な働き方やキャリアパスの提供
これらのオプショナリティを意識的に高めることは、製品と組織の持続可能な成長につながります。
おわりに
「Tidy First?」は、一見するとソフトウェア設計の本ですが、その本質は「不確実性の高い環境下での意思決定の指針」を提供することにあります。特に重要な教訓を以下にまとめます。
- 構造の変更と振る舞いの変更を意識的に区別する
- チームのオプショナリティを継続的に高める
- 小さな改善を頻繁に行う習慣を作る
- 一見非効率に見える活動の長期的価値を理解する
これらの原則を日々の組織運営に活かしながら、持続可能な組織づくりを目指していきたいと思います。
参考
- Kent Beck "Tidy First?: A Personal Exercise in Empirical Software Design"