取り残される感覚

世間様はGWだったりする。
しかしながら、私のほうは、コレといった予定もなく、子供たちから「どっか連れて行けやこら！」という圧力をうけつつ、どこ行っても人がいっぱいのなか、どこに行くつもりも起こらず（ラ・マシンだけは見に行きたい）、日々を過ごしている今日このごろ。
そんな中、実はこのブログが、なんだか〜だと丸々4年たち、5年目に突入したことに、軽い驚愕とめまいを感じてしまうわけであった。

今凝っている話

だいたい、1年周期くらいで、SAPの仕掛けとは離れたところ、主にWeb系の仕掛けに興味を持ち、ちょっとやってみるというのが趣味になっている感じなのだが、昨今は、これがどうも、仕事直結のような感じになってきて、ちょっと気が重い。
だってそうでしょ？2005年くらいに「あれ〜どうなるんだろう？」って言っていたSOAってやつは、Webサービスという形で実用化にまっしぐら。ついでに、「クラウド」なんてキャッチーな言葉付きで一気にメジャーに。概念先行かと思いきや、いまやJavaScriptを使ってWebサービスを呼び出し、それなりのフロントエンドを作る、なんてのは、簡単とは言わないが、無茶苦茶難しいなんてレベルではなくできてしまう。
で、その業務パッケージ自体が「SaaS」なんてまたキャッチーな名前で、サーバなんて買わずに動かせてしまう。ASPと何が違うんだ、なんてタカをくくっていたが、WebサービスとしてAPIを公開しているってことは、それと連携した何かってやつを作るのも、そんなに手間はない。たとえば、Zoho CRMで作ったアクションを、自分のGoogleカレンダーに持ってくる、または、Googleカレンダーで変更した予定を、ZohoCRMに書き戻す、なんてことは、ちょっとがんばったらできそうな感じがしてくるから不思議。

取り残されてないかな・・・

で、何が危機感か、というと、そういうことを作る際に、今までの「要件定義書」なんてものが、何の意味もない文章になってしまうってこと。

いや、まあ、全部が全部そうだってわけじゃないですよ。
けどね、たとえば、Zoho CRMとGoogleカレンダーを組み合わせて、案件ごとの活動管理が簡単にできるようにしましょう、みたいな企画を本格的に立ち上げるとするでしょ？
そうするとね、今定義されている標準の「要件定義書」のうち、本当に作らないといけないのって、なんですか？という話なんですよ、これが。
データのCRUDなんて、特に文書にする必要がないわけですな。
逆に、営業活動のステージを決めて、そのステージに対する活動を決めて、それを自動で登録できるアプリを作る。で、それはZohoに登録されてたそれは、Googleカレンダーに自動登録。Googleカレンダーでの時間変更は、15分ごとに確認し、Zohoに書き戻す。
こんな、「やりたいこと」に対して記述するべき文書って、なんなんだろう、という話なんですよ。

少なくとも、いわゆるエンタープライズ開発という世界では、「要件定義書」の標準みたいなのが幅を利かせていて、ま〜なんていうのか、各種多様な文書を作るわけですな。
まあ、全部自前でUIの設計もやって、DB設計もやって、なんて感じでやるスクラッチ開発なら、それも絶対に必要なのは理解できる。けど、そんな世界じゃない開発ってやつは、目の前に来ているわけで、じゃあ、何を定義すれば、顧客の要求を文書化した新しい「要件定義書」みたいなものができるのか、ということを悩むわけですな。

ところが、現実にお金をもらっている仕事では、旧世代の「要件定義書」と格闘する羽目になる。ロックのスコープとか、確かに重要だけど、そんなのWebサービスの向こう側で、ちゃんと考えてくれちゃっているわけで。

違う世代と競争することになるんだな、きっと

こんなこと言う若手がいれば、ちょっと前までは、そんなWebの世界とエンタープライズ開発の世界とは違うから、こっちの仕事のやり方を覚えろやこら！と、説教していたんだけれど、「やりたいこと」を中心に考えれば、Webの世界とエンタープライズ開発の世界とでは、あまり垣根はない。というと、言い過ぎか。けど、垣根は確実に低くなっている。

そうこうしている間にも時代は移り、今やっている仕事が時代遅れになっていく。そんで、新しい仕掛けの時代になったときには、新しい仕掛けが、若いときから当たり前の世代と競争するハメになる。そりゃ、変なバイアスがないだけ、そっちのほうが強いよね、普通にやれば。

う〜ん、怖いなあ・・・

そう思いつつも、10年ぶりくらいに見るJavaScriptは、ちょっと楽しかったりするので、微妙に現実逃避な感じを続けるわけでした。はい。