私自身、社内のシステム開発用フレームワークを一人で設計・開発していて、ちょっと前までは、自分の参画するプロジェクトでのみ採用していた。

最近、私が参画しないプロジェクトでも採用するようになり、いろいろとサポートをする必要が出てきたのだが、その過程でフレームワークを理解するために最も重要な事というのが何なのかが分かったような気がする。

それは、

「フレームワークの機能に何があるかを知る」

事ではない。

勿論、フレームワークの機能を知る事で、ある程度フレームワークの能力を発揮する事が出来るかもしれない。

しかし、フレームワークの設計者が知っているであろう最適な使い方にはならないだろう。

だから、「まず最初にフレームワークの詳細な機能について知ろう」と思う必要は無い。

もっと大切な事を理解してからでも遅くない。

むしろ、その方が個々の機能について最適な使い方とセットで理解できるので有益だ。

では、何が最も重要なのかというと、

「フレームワーク自身が持っている思想を知る」

という事である。

どんな意図でフレームワークが存在しているのか。

どんな意図でフレームワークの設計がこのようになっているのか。

どんな開発手法を想定して作られたフレームワークなのか。

それを理解する事が最も重要な事であるように思う。

これが理解できれば、各機能の最適な使い方は自ずと知る事ができるはずである。

だから、フレームワークのセットだけポンと渡されても困るし、リファレンスだけ渡されてもなかなか最適解にたどり着けない。

むしろ、フレームワークとしては中途半端である。

ちゃんと、フレームワークを作った理由や設計思想、最適な開発手法まで一緒に渡してあげる必要がある。そこまで渡して初めてフレームワークとして機能するのではないだろうか。

なんて事を昔から思っていたのだが、より一層強く思うようになった。

下手なメタファは有害だが、それを覚悟で喩えるなら、

「言語が分かっても、その背景にある文化が分からないと、なかなかうまくコミュニケーションが取れない」

という事。