最近、ソフトウェア開発で、いろいろ考えているキーワードが、ソフトウェアを「育成」すること。
受託開発ビジネスだと、リリースが大きなゴール。昔は、リリースしたら、ソフトウェアはできればいじらないのが一番。
を勘案すると、リリースしたソフトウェアは、できるだけいじらないのが基本。
でも、最近は、このロジック、通用しなくなってきているみたい。
顧客も、競合も、インターネットやモバイルなどの IT も、変化しつづけている。
この環境だと、リリース時の状態でストップしたソフトェアは、あっというまに価値が下がっていく。
あるソフトウェアをリリースして、それまでは、できなかったことができるようになる。ユーザは喜んでくれる。
でも、そのソフトウェアが当たり前になると、今度は、もっと、こうならないの?という不満のネタになる。
まあ、浜の真砂はつきるとも、世に要求のタネはつきまじ。
そういう、変化への対応の要求が強いと、造る側でも、いろいろな技術の改良が進む。
技術的なキーワードは、
問題領域の知識を、いかに深めて、いかに、ソフトウェアに実装する。その哲学と実践ノウハウ。
知識は、その領域で、いろいろな経験を積めば積むほど、広く、深くなっていく。
環境が変われば、知識がさらに増えたり、変化していく。
こういう知識の変化・増殖を、絶え間なく、ソフトウェアに反映しつづければ、そのソフトウェアの価値は高まり続ける。
形式的なやり方ではなく、必要なことを、必要なだけ、必要な時にやる。その哲学と実践ノウハウ。
いまは、要件定義は、RDRA、開発は、 ICONIX 、ラストワンマイル(配置)は、CI (継続的インテグレーション) と、して取り組んでいる。
これは、開発のスピードをあげ、コストを下げるの方法として、手ごたえ十分。実践できていることは、Best Practice から、ほど遠くても、それでも、かなり効果が実感できている。
特に、ソフトウェア変更のスピードやコストの改善は、すごい。
J2EE が、いちじ、ヘビー級指向だったけど、Spring フレームワークとかが、軽量であることの価値にこだわって活動をしてくれたおかげで、アーキテクチャも軽やかなものを選択できるようになった。
オープンソースの、サーバー、フレームワーク、ライブラリも、軽量指向のものが増えて、また、成熟してきている。
安心して使える、までは言いすぎだと思うけど、十分に実用的になっている。
ハードウェアやOSも、Amazon EC2 とかで、好きに時に、好きなだけ使える良い時代になった。
プロジェクトの初日に、フルセットの開発環境、リポジトリ、ビルド環境を、インターネット上からリソースかき集めて、インターネット上に構築する、なんていうことを、実際にやってみると、ほんと、時代が変わったと思う。
ハードの調達、ベンダーからソフトウェアの購入、...などにどのくらい貴重な時間をロスしていたことだろう?
要求側の変化への強い圧力、造る側の技術革新、これが、重なって、ソフトウェアを育成することが、良いソフトウェア、役に立つソフトウェアを提供する、有力な手段になってきた。
今は、まだまだ、変更のコストは高いし、リスクも大きい、期待効果は小さい、のが現実。
でも、あきらかに、経験を積むたびに、コストが下がり、リスクが小さくなり、変更の効果が大きくなっている。
この「ソフトウェア育成」の哲学と実践ノウハウの獲得にしばらくこだわってみようと思う。
受託開発ビジネスだと、リリースが大きなゴール。昔は、リリースしたら、ソフトウェアはできればいじらないのが一番。
- 変更のコスト
- 期待できる効果
- 変更のリスク
を勘案すると、リリースしたソフトウェアは、できるだけいじらないのが基本。
でも、最近は、このロジック、通用しなくなってきているみたい。
要求の変化
顧客も、競合も、インターネットやモバイルなどの IT も、変化しつづけている。
この環境だと、リリース時の状態でストップしたソフトェアは、あっというまに価値が下がっていく。
あるソフトウェアをリリースして、それまでは、できなかったことができるようになる。ユーザは喜んでくれる。
でも、そのソフトウェアが当たり前になると、今度は、もっと、こうならないの?という不満のネタになる。
まあ、浜の真砂はつきるとも、世に要求のタネはつきまじ。
技術・ノウハウの進歩
そういう、変化への対応の要求が強いと、造る側でも、いろいろな技術の改良が進む。
- 変更のコストを下げる技術
- 期待できる効果を大きくする技術
- 変更のリスクを小さくする技術
技術的なキーワードは、
- ドメイン駆動
- アジャイル開発
- 軽量なアーキテクチャ
ドメイン駆動
問題領域の知識を、いかに深めて、いかに、ソフトウェアに実装する。その哲学と実践ノウハウ。
知識は、その領域で、いろいろな経験を積めば積むほど、広く、深くなっていく。
環境が変われば、知識がさらに増えたり、変化していく。
こういう知識の変化・増殖を、絶え間なく、ソフトウェアに反映しつづければ、そのソフトウェアの価値は高まり続ける。
アジャイル開発
形式的なやり方ではなく、必要なことを、必要なだけ、必要な時にやる。その哲学と実践ノウハウ。
いまは、要件定義は、RDRA、開発は、 ICONIX 、ラストワンマイル(配置)は、CI (継続的インテグレーション) と、して取り組んでいる。
これは、開発のスピードをあげ、コストを下げるの方法として、手ごたえ十分。実践できていることは、Best Practice から、ほど遠くても、それでも、かなり効果が実感できている。
特に、ソフトウェア変更のスピードやコストの改善は、すごい。
軽量なアーキテクチャ
J2EE が、いちじ、ヘビー級指向だったけど、Spring フレームワークとかが、軽量であることの価値にこだわって活動をしてくれたおかげで、アーキテクチャも軽やかなものを選択できるようになった。
オープンソースの、サーバー、フレームワーク、ライブラリも、軽量指向のものが増えて、また、成熟してきている。
安心して使える、までは言いすぎだと思うけど、十分に実用的になっている。
ハードウェアやOSも、Amazon EC2 とかで、好きに時に、好きなだけ使える良い時代になった。
プロジェクトの初日に、フルセットの開発環境、リポジトリ、ビルド環境を、インターネット上からリソースかき集めて、インターネット上に構築する、なんていうことを、実際にやってみると、ほんと、時代が変わったと思う。
ハードの調達、ベンダーからソフトウェアの購入、...などにどのくらい貴重な時間をロスしていたことだろう?
ソフトウェアを育成する
要求側の変化への強い圧力、造る側の技術革新、これが、重なって、ソフトウェアを育成することが、良いソフトウェア、役に立つソフトウェアを提供する、有力な手段になってきた。
今は、まだまだ、変更のコストは高いし、リスクも大きい、期待効果は小さい、のが現実。
でも、あきらかに、経験を積むたびに、コストが下がり、リスクが小さくなり、変更の効果が大きくなっている。
この「ソフトウェア育成」の哲学と実践ノウハウの獲得にしばらくこだわってみようと思う。