ソフトウェア界隈では、よく「巨人の肩に乗る」という比喩表現が使われます。

「巨人の肩に乗る」というメタファーはフリーソフトウェア運動を推進しその正当性を示すためにも用いられる。 レッドハットのボブ・ヤングは2002年の著書『リチャード・ストールマンと自由ソフトウェア革命（英語版）』で、人々が巨人の肩に乗ることを可能にするものだとしてフリーソフトウェア運動を支持し、巨人の肩に乗ることは車輪の再発明の対極にあるとも述べた^[48]。 巨人の肩の上 – Wikipedia

ソフトウェアにおいて「巨人の肩に乗る」が「車輪の再発明」と比較されることからもこの表現が使われる時は、先人が残した便利なツールやライブラリを使うことで、早く多くのことを実現できる。というような趣旨であることが多いと思います。便利なツールやライブラリを使う決定をする場面です。

しかし、それ以外の状況でも巨人の肩を意識するタイミングがあるかもしれないという話です。

新技術を使う検討

例えば、10年前くらいに良くあったかもしれない状況を考えてみます。

LAMP環境(Linux・Apache・MySQL・PHP)でWebアプリケーションの開発をバリバリ行なっているチームがありました。チームが利用している技術には慣れていて、多少の残業をしながらも日頃の開発は比較的スムーズに行なっていました。

新しく始まるプロジェクトでは、巷で流行っているNoSQLに分類されるHogeDBという処理速度の速いと言われているデータストレージを採用するかどうかの検討が始まりました。

新しい巨人

いうなればHogeDBは、新しい巨人と言えます。当然「新しい巨人の肩の乗り心地はどんなもんだろう」という観点で調査や学習をすることになります。どちらかというと、HogeDBの利点ばかりに注目しがちです。

この時、必然的に今まで乗っていた巨人の肩から降りてから、新しい巨人の肩に乗ることになります。今までの巨人(MySQL)がどれだけ大きかったのか、どんな特徴がチームを助けてくれていたのかというのを把握していることが検討の必要条件となります。もし、今までの巨人を過小評価してしまった場合、乗り換えてから後悔することになってしまいます。例えば、プログラマーになってからMySQLしか使ったことがない人にとっては、あたりまえに存在しているものすぎて、どれだけ便利なのか、何を助けてくれているのかを正確に把握できていないといったこともあると思います。

まとめ

これは、データストレージの変更に限った話ではありません。フレームワークの変更、クラウドサービスの乗り換え、プログラミング言語の変更、マイクロサービス・クリーンアーキテクチャ等の採用など、アーキテクチャに関する技術的な意思決定のほとんどに当てはまります。巨人の肩に乗る時よりも巨人の肩から降りる時の方が、慎重に正確な状況把握が必要なのではないでしょうか？