正解へたどり着くただ一つの方法
私はそれなりに長い年月を、システム開発にかけてきたのですが、昔も今も変わらずに仕事というのは炎上することが多々あります。成長していない、と言われればそれまでなのかもしれませんが、プロジェクトをうまく進めるためのノウハウも、ある程度は蓄積できているにも関わらず、炎上を完全に避けることはできていません。
開発手法において、確かに昔と比較するとはるかに方法論としても成長しています。昔ほど力技で開発を行う場面はなくなり、いかに問題を早く解決できるようにするか、いかに素早く開発できるようにするか、そのような課題に対して試行錯誤を繰り返した結果が今に繋がっていると思います。
ですが、問題となるのはその開発に至るところまでにあるのは、今になっても解決できていません。要件定義をはじめとした、上流にこそ原因が残り続けているのだと思います。
上流工程は形のないものから形を見出す、非常に難しい工程ではあります。相手によって望む形が異なるという、普通にやるだけでも難易度が激しく高いものです。相手の望むことをそのまま叶えるか、違う形で実現させるのがよいのか、時と場合によってどちらが適しているかは一概に言い切れないものです。
すべてをフルスクラッチするのも一つの方法ですし、既存のサービスを利用させるのも一つです。利用する相手がどういった構成なのか、どういった企業で利用するのか、ほかにも様々な要素がある中で、最適解に近いものを目指していくので、プログラムを書く、アーキテクチャを決める、そういった領域と比較するとやはり別格の難しさが潜んでいます。
個人的には、今のご時世を踏まえてもできるだけ早くに利用できることがまず優先するのがよいと考えています。よほどクリティカルな領域のシステムでない限りは、まず利用できる形にする、それを最優先とすべきだと思うのです。最優先とすることで、今採用している方法が適しているのかいないのかを、はっきりさせることが可能です。使う側も、作る側も触ってみて初めてそこを実感できるものです。実物を見ないでそこに気づける人は、極々どころかほぼまったくといっていいほど存在しません。
考えてみるとこのような試行錯誤ありき、というのは方法論としてそれほど多くはない気がします。試行回数を少なくする方法を、どちらかというと取り扱っているものが多いのではないでしょうか。ですがそれは、上手くいくこともそれほど多くあるとは思えません。どちらかというと、どれだけ試行錯誤するかだけが、最も適した選択肢を選ぶことができるようになる、ただ一つの方法なのだとも感じます。
プログラムを学習する時も、思い出してみれば色々と手を変え品を変え、何度も試行錯誤したことが一番実力につながったと思います。同じ問題に対して、繰り返し繰り返し取り組むことが最も近道だった、今考えてもその感覚は間違っていないと思います。これは何事にも通じているのではないでしょうか。
難しい領域である要件定義においても、この試行錯誤を繰り返すのが一番の近道なのだと思います。何かしら方法を思いついたら、できるだけ早くに関係者間で確認してもらう、そしてその結果をもとにまた方法を修正していく、この流れを何度も何度も繰り返すことで、より利用者に適したものをはじめて作ることが可能になるのだと思います。
今であれば、アジャイル的な方法やその前の時代で言えばスパイラル方式といった、繰り返すことを組み込んだ方法論が色々出揃っています。これは考えてみると、単純明快に行える方法というのは存在しなく、愚直にただ繰り返すことだけが正解というのを表しているのかもしれません。数十年という歴史が開発の世界にはありますが、その年月をかけて今たどり着いているのが、このように初心に戻り何度も繰り返すことこそが正解、というところです。
銀の弾丸を待望するのはいつの時代になってもありますが、それと同じようにいつの時代においても正解へたどり着けるのは愚直にただ繰り返すだけ、となるのではないか、ずっとそのように考えています。