こんにちは。てぃろです。
今回はコラムです。フレームワークを使うことについて書いてみたいと思います。
仕事をしているとどんな分野であれ”フレームワーク”というものを耳にします。フレームワークはある問題を解くための公式のようなもので、特定の問題にあてはめて使用すると正しく容易に解決策やそのめのヒントが得られる、というものです。
ビジネスの分野では、4C分析とか5P分析、AIDMA、AISASなんかがよく聞かれるものではないでしょうか。
エンジニアリングの世界もフレームワークであふれていて、ソフトウェアの世界に特化していくとそれはデザインパターンと呼ばれるものがあります。それはよくあるコーディング上の課題を解決するために使用されるもので、最もよく聞くのはシングルトンとかリポジトリパターンといったものではないでしょうか。
ただ、ソフトウェアの世界は変化が激しく、デザインパターンのように体系立てて名前を付けられているようなフレームワークばかりが存在しているわけではありません。
どこかの誰かが提案したディレクトリ構成だったり、メモの書き方だったり、自動化の方法だったり、それらもすべてフレームワークと言えるものなのだと思います。（私も過去記事で書いたりしてるのも一種のフレームワークだと思ってます）
それぞれのフレームワークは、過去の論文をメタ分析するなどで得られた普遍的なものではないにしても、その人たちの経験から生まれたある意味生きたフレームワークであることは間違いなく、それこそ彼らが直面していたその特定の問題に対して非常に大きな効果を発揮するものなのでしょう。
しかし、こと自分たちの問題に対して言えば、そのフレームワークをそのまま適用することによって効果を発揮するかははなはだ疑問です。
ここで一度思い返していきたいのが、フレームワークの使い方です。
フレームワークはある特定の問題に対して解決策やそのヒントを与えるものです。
つまり、そもそも適用する対象の問題を間違えてはいけません。フレームワークを適用するべきではない問題に対して無理やり適用したところでヒントを得るどころか、間違った解が得られることで害悪とさえなります。
だからこそ、フレームワークがどのような問題に対して適用されるべきなのかをしっかりと考える必要があります。加えて言えば、フレームワークがそのまま適用できる場面というのは極稀であり、フレームワークは多少カスタマイズしたり、有用なエッセンスだけ使ってしまうというのも使い方の一つだと思います。
特にソフトウェア開発の現場では、ある意味フレームワークはディレクトリ構成など、ノウハウとして一部を切り出すことが可能なものが多かったりします。そのため、自分たちの現場固有のフレームワークを作るくらいの気持ちで、どんどんフレームワークの一部を切り出して適用させていくのがいいんだろうと思います。
しかし、どんどん開発技術などやビジネス環境が変化していく現場において、一度決めたフレームワークを単純に守るということほど無意味なものはありません。
今開発現場で起きている問題を解決するためにフレームワークは使われるべきであり、すでに問題ではないところ、もしくは違う問題に変化してしまったところに既存のフレームワークを当てはめてもやはり無意味か害悪でしかないのです。
つまることろ、現場においては現実的に効果が高いところに正しくフレームワークを適用するように運用を定着させることこそが開発現場でのフレームワークの正しい使い方だと思うのです。
このように正しくフレームワークを使うためには、現場で起きている問題が何か？ということを発見し定義することが、まず一番最初に必要なことです。さらにそこからどのように運用していくかをその組織それぞれの事情に合わせて考えていく。これこそが真にフレームワークを機能させ、本当に望ましい課題解決をしてくこと繋がると思います。
