魔法のチョークで描いた窓

フレームワークとは

フレームワークは「物事をとらえるための手段」です。ビジネス分析では「状況を整理するレンズ」として意図的に使い分けます。ところが、ソフトウェア開発ではフレームワーク自体を実践だと捉えてしまいがちです。手段が目的化するのです。実際に、作業の大部分がフレームワークに規定されるため、開発ではその現象がしばしば起こります。

手段の目的化という落とし穴

この手段の目的化が深刻な問題を引き起こすのは、フレームワークと本来の目的との適合性に疑義が生じたとき、あるいは環境変化によって不適合が生じたときです。普通なら「レンズを掛け替えれば」良いのですが、現実を無理にフレームワークに当てはめる結果、フレームワークの思想からも逸脱した複雑な依存関係をこしらえたり、あるいは空虚なモジュールを量産したりする――これは技術的負債が膨らむ瞬間です。

さらに手段の権威化も生じます。時間を経るごとに、本来の目的を意識し、その目的達成に資するかという観点から実装を評価する姿勢が鈍っていきがちです。開発者自身が責任を持つべき評価というプロセスをフレームワークという「権威」に委ねてしまうのです。

なぜ囚われてしまうのか

フレームワークに囚われてしまう理由は二つあります。ひとつは思考の抽象度が固定化されてしまうことです。手段あるいは権威と化したフレームワークのもとで、そもそも「顧客にどんな価値を届けるのか」という本来の目的に立ち戻る思考が難しくなるのです。

ふたつ目はサンクコストの誤謬です。フレームワークの枠内で費やした時間が権威性を補強し、逸脱をためらわせます――ただ、この点に関しては昨今のAIの発展が解決の糸口を与えつつあるでしょう。さいきん、私たちは新しく何かを始めることに物怖じしません。

囚われず、あえて利用していく

単一のフレームワークに囚われないよう留意し、本来の目的の達成に資するかという観点から継続的に評価を行い、あえて使い倒していくのが良い姿勢でしょう。加えて、組織づくり（採用や育成）の観点からは、複数のフレームワークを使いこなせるスキルと、それらのフレームワークが「実際に何を解決しているのか」を理解できているかどうか。これらはますます重要になっているように思われます。