開発の現場で、「手法」を議論する機会が減ってきているように思う。もちろん、自分の身の回りのことが全てではないので、偶然かもしれないが、ブログ等での話題でも、あまり見られなくなっている気がする。以前だと、例えばMVCがどうとか言った話題が華やかだった記憶がある。そして、古くからのさまざまな手法のどれがいいのかと言った話題や、特定の手法をどのように理解すればいいのかといったことが議論された。サイエンス的に考えれば、原理原則があり、それに則った手法は、成功する確率が高くなるということから、以前は手法やアーキテクチャ中心的な考え方もあっただろうし、もちろん、今もそれはなくなってはいない。
現実はどうだろうか？ 色々な手法や原理原則は、１人１人がしっかり学習して現場適用するということも必要なことかもしれないが、「良い手法」はそのものが、すっかりパッケージ化されている。ソフトウェア開発で言えば、フレームワークやライブラリ、あるいは開発ツールで、そうした過去の蓄積が完全にパッケージされており、手法を深く理解しなくても開発を進める上ではあまり問題はない。ともかく、ある「やり方」を採用すれば、難しい原理原則はもちろん、手法の適用までができてしまうのである。Webのサーバーサイドフレームワークは典型的な例だろう。ほとんどのフレームワークはMVC（正確にはJavaEEでのMVC2パターン）であり、よほど変なことしない限りはMVCに基づく役割分担が自然に作り込まれるし、レイヤー化についても気がついたらそうなっているのが一般的だ。もちろん、実装の良し悪しはあるとしても、現場で働く側としては「○○フレームワークでよろしく」の一言で済んでしまう。
そうなると、現場でもっとも注目されるのは何だろうか？ システム開発の現場と、サービスアプリケーションでは色々違うとしても、結果的に、「問題点は何か」ということに注目することが常に行われているのではないだろうか。開発の枠組みは使用フレームワークをはじめとして、結果的に決まってしまうことが多い。要求工学では手段は後から決めるというのが基本ではあるが、現実にはそうでもない。そして、そこではどんな手法を採用するかも概ね決まっている。スタッフが持つ経験をベースに、進行の可能性を検討し、誰かが問題なく進められる部分は、特にフォーカスされない結果となる。一方、誰も作ったことがない仕組み、誰も経験したことがフレームワーク、ある領域で実現できそうにない非機能要求など、「できるかどうか分からない」所に開発タスクとしては目を向けることになる。
では、できないことを、原理原則からボトムアップして、手法を求めるかと言うと、そう言う側面が問題解決に集中しているときはあるかもしれないが、その結果、あるライブラリを使うことで十分に解決されるなら、「ライブラリを使います」と言うことで集約され、問題がさらに絞られる。「チーム全員で手法をまずは勉強します」という結果はかなりハードルが高い。結果的に、問題から始めて、パッケージ化された解決手段で概ね解決し、さらに違う問題にたどり着き、それを繰り返す。問題がほぼなくなれば、一定時間後に完成に進めるということだ。
問題点の解決が現場での主要な話題になり、系統的な手法が議論される素地はほぼない。もちろん、結局のところアジャイルということなのかもしれないが、小さなプロセスでも、大きなプロセスでも同様に言えることではないだろうか。良い悪いはあるとしても、そのように進んでいる。その中で、基本や原理を叫んでも、誰も耳を傾けない。問題を解決する糸口は、まさに原理原則に立ち返ることで手にできるとも言えるのだが、「良い素材はないだろうか」が糸口になってしまうのである。
普段は小規模な開発に関わる機会が多いので、仕様書が渡されないような発注は普通にある。もちろん、大きな会社の発注では仕様書があるものの、非常に高い割合で「仕様書書いている」と言う証拠のためだけの紙の塊でしかないようなことも感じる。設計に役に立たないわけではないが、中身が実装作業に遠いのである。わかり切ったことは簡単に書き、問題点を記述して共有すれば、仕様書はより役に立つのではないだろうか？ サイエンスなので、原理原則があって、それを踏まえた手法があるのは間違い無いのだが、いっそうのこと現実に合わせて「問題解決」にフォーカスした手法に目を向けるべきだと考える。とはいえ、そう言う「手法」を作っても意味はない。手法を否定する手法というのは存在に無理がある。その意味では、アジャイル宣言のように、どんなマインドで対峙すべきなのかをうまく表現しないといけないだろう。ということで、表題のように「手法よりも問題解決」と言ってみた次第だ。今やそういうやり方が一般的というスタンスで、メリットと注意点を検討すべきではないだろうか。