前提としてクリエイティブな仕事は再現性が低い。しかし逆に言えば再現性があってはいけないものがクリエイティブであり、再現性がないからこそクリエイティブであると言える。アートのように非再現的なものはクリエイティブであり、再現性が低く刹那的な成果物であることに意味がある。
ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。
ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術力を求めなければ採れうる人材の幅は圧倒的に広くなる。
これは「クリエイティブではないソフトウェア・エンジニアを雇おう」という主張ではなく、クリエイティビティの尺度で境界を区別して適材適所的に組織を構成したほうが結果的にスケールに繋がるという話であり、身近な例で表現するならばファストフード・チェーンの店舗とバックオフィスのような関係で開発組織を構成していくようなイメージ。チームトポロジーで言うならば、店舗はストリームアラインドであり、バックオフィスがプラットフォームになる。バックオフィスのメンバーは店舗でオペレーションを直接やらず、代わりに新商品やオペレーション、教育プログラムをインターフェイスとして提供*1する。バックオフィスの仕事は非定型的で再現性が低いクリエイティビティが必要な業務である。
チームトポロジーの本質は組織の設計によって認知負荷の境界分割を行うことである。もしもファストフード・チェーンの店舗レベルの人間に普段の業務と並行して現場で商品や教育プログラムの開発を片手間のタスクで行わせるとしたら、それは店舗というチームにバックオフィスが持つクリエイティビティの要求が持ち込まれることに他ならない。これはまさに認知負荷の上昇であり、結果的に本来の責務として与えられていたオペレーションへ影響を及ぼす。やるべき仕事が多様になり、個々人に求められる認知負荷の振れ幅が大きくなると業務は属人化しはじめ、再現性の高い生産が行えなくなっていく。
エンジニアリングに話を戻して具体的にするならば、あるチームの仕事の中に社内で使っているサードパーティ・ライブラリの基盤に新機能追加のPRを出すタスクと、単にアプリケーション側でフレームワークの新しい機能を使うように書きかえるだけのタスクが同列に存在しているような状態を想像するといい。全員が同じレベルで全てのタスクに着手できない状態である。開発者ごとに相対的な認知負荷に対する許容範囲の差分があり、メンバー間の認知負荷の差分が結果的に技術的負債を生み出す原因になる。また、この手の負債は属人性がボトルネックになることで回収されないままになる。*2
そのような環境で認知負荷の容量が大きい人が生み出したコードは容量の小さい人からすれば、過度に難易度が高いが故の相対的な技術的負債だと言える。別の見方をすれば技術的負債とは属人性がもたらした「状態」であり、開発組織における人員の能力、特性、流動性を考慮して適切なレンジの認知負荷になるようコードベースの複雑性をコントロール*3できれなければ、どんなに綺麗に設計されたコードであっても組織の状態により技術的負債になったりならなかったりする。
これらは、いずれにしても同一のチームで求められるクリエイティビティのレンジと、個々人が対応できる認知負荷の容量のバラつきが大きすぎることが原因である。認知負荷は他者の発揮するクリエイティビティの発露によって生まれる結果であり、この差分が大きくなっている箇所をチームとして分割せねばならない。
その際には、育成や指導でメンバーのクリエイティビティの下限をどうにかして上げようとするのではなく、構成されるメンバーに応じて上限にリミットをかけるためにチームを分割・構成するべきだ。
*1:一方で、自分の大学時代の先輩に日本マクドナルドへ入職した方がいるのだが、バックオフィスの場合には実際のオペレーションなどを理解できるよう一定期間店舗で働く必要があるとのこと。オペレーションの効率性が重要な店舗側ではバックオフィスのことを知る必要がないが、逆にバックオフィスは店舗レベルのオペレーションを俯瞰して理解しなければいけない。
*2:よくある「このコードは〇〇さんしか触れないやつだから...」「〇〇さんいないと分からないコードだこれ」みたいなやつ
*3:技術選定やアーキテクチャ選定とはまさにこの認知負荷レンジのコントロールそのものであり、Goでクリーンアーキテクチャ的な設計方針を取ろうがRailsを使おうがHanamiを使おうが、その意思決定が結果的にはどう評価されるかはすべて開発組織が将来的にどういった人材で構成されるかに依存している。
