不特定多数に向けたWebアプリを作ってて、力を注ぐところがプログラミング技術（設計なども含む）から別の領域へ移っていくんだなぁ、と感じる。
「どうやって作るか」から「何を作るか」へ
私の場合、Rails使ってみたいな〜という技術的興味を満たすところからスタートしたような気がする。会社の仕事じゃJava一辺倒だったし、RubyやRailsに触れようと思ったら、プライベートな時間に何かを作ってみるしかなかった。最初は、自分ひとりが使えればよかったし、日常的に使うレベルにまで作りこもうとは思ってなかったので、RubyやRailsを使うことに意義があった。
でも、どっかで、ふと、みんなに使ってもらえるものを作ってみたいな〜と思った。
そこから、目的が別のところへシフトしていった。作る以上、なるべく多くの人に使ってもらいたいというのは、当然の欲求だと思う。そうすると、「どうやって作るか」よりも、はるかに「何を作るか」の方が重要になっていった。どんなものであれば、自分を含め、皆便利に使ってもらえるのかがテーマになっていった。受託開発であれば、要件定義にこそ最大の労力をつぎ込む的な状態。
そこに至り、改めてソフトウェアを作り込んでいく過程で必要となる技術は、あくまでも手段なんだなぁ、と再確認した。
こういったものだけに興味を示していたのでは、みんなに使ってもらえるソフトウェアを作るのは無理なんだよね、と。
プログラマーから何か別のもの（？）へ
プログラマーとしていいものが作りたいという動機でスタートしたとしても、それが本当に良いものであるためにはプログラミングとは違う領域のスキル・作業が要求されるわけで。
そうすると、プログラミングスキルってなんだろうね、と。きっと、どの程度のプログラミングスキルがあるかは、制約であり、かつ武器なのだろうと思う。
- やろうとしていることは、自分のスキルで可能なことなのか
- 作り上げるのに、どの程度の時間がかかるのか
- どのくらいの頻度とスピードで、改修していけるのか
- 効率を上げるために、どういった仕組みが作れるのか
これらはプログラミングスキルがもたらす制約だ。しかし、一方で、ある一定レベルを超えたところから、逆に武器になっていくのだと思う。他の人に出来ないことが実現したり、他の人より短いサイクルで開発できたりしたら、それは優位性を築くための武器になる。
で、それを踏まえた上で、ビジネスモデルの設計や、ソフトウェアのコンセプト設計、マーケティング、さらにはマネジメントが出てくるのだよなぁ。ユーザーの規模が大きくなれば、システム運用の負荷も凄いものになるだろうなぁ。
1人、または少人数でWebアプリを開発するってのは、大変なことだと思った。