ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。
ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術力を求めなければ採れうる人材の幅は圧倒的に広くなる。
エンジニアリングに話を戻して具体的にするならば、あるチームの仕事の中に社内で使っているサードパーティ・ライブラリの基盤に新機能追加のPRを出すタスクと、単にアプリケーション側でフレームワークの新しい機能を使うように書きかえるだけのタスクが同列に存在しているような状態を想像するといい。全員が同じレベルで全てのタスクに着手できない状態である。開発者ごとに相対的な認知負荷に対する許容範囲の差分があり、メンバー間の認知負荷の差分が結果的に技術的負債を生み出す原因になる。また、この手の負債は属人性がボトルネックになることで回収されないままになる。*2
これらは、いずれにしても同一のチームで求められるクリエイティビティのレンジと、個々人が対応できる認知負荷の容量のバラつきが大きすぎることが原因である。認知負荷は他者の発揮するクリエイティビティの発露によって生まれる結果であり、この差分が大きくなっている箇所をチームとして分割せねばならない。
その際には、育成や指導でメンバーのクリエイティビティの下限をどうにかして上げようとするのではなく、構成されるメンバーに応じて上限にリミットをかけるためにチームを分割・構成するべきだ。