オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

クラウド世代のソフトウェア開発 - どちら側になりそうですか?

»

一方は「かたいことは言わずにぎりぎりまで作れる」もう一方は「事前に合意した基準を守り、あらかじめ合格しておかなければならない」だ。サービスプロバイダにはこれまでもあった話だが、その局所的な動きが広くITシステム全般で起こるようになるかもしれない。

まず、「かたいことは言わずにぎりぎりまで作れる」ほうから。多数のユーザに同様のサービスを提供するパッケージ型サービス開発向けの話だ。これまで配布型のアプリケーションソフトウェア/組込み機器を提供していたときには、インストーラ、配布先の計算機の能力、配布後のアップデートコストを勘案する必要があり、ぎりぎりまで作ったり配布後に改変したり、ということに制約があった。

これをサービス化、一括管理することにより制約は弱まり、ぎりぎりまで開発を続けられるようになる。月末処理や年次更新等は(設計は必要だが)そのタイミングが来るまでは必ずしも実装しておく必要はなくなる。各種プロビジョニングをはじめとしてログをどこに保存しておくかということも含め、動き始めてからでも比較的自由にコントロールできる部分がある。

一方「事前に合意した基準を守り、あらかじめ合格しておかなければならない」ほうは、これまで自前で開発、運用していたシステムやアプリケーションを預ける場合だ。IT系、エンタープライズ系で、内製していたりインフラはデータセンタ業者に預けていたものを、ミドルウェア、データベース等も共通のものに移行し、アプリケーションロジックに集中していく場合はこちらにあてはまる。今まで電源は・・・とか、寸法は・・・というスペックはあったもののソフトウェアに関するものはそれほど多くなかったが、・・・のバージョンは、・・・の最大コネクション数は・・・と、求められるものがソフトウェア寄りのものが増えるだろう。

去年の6月にここ(このブログの過去エントリ)に書いたが、たとえば、salesforceではアプリケーションを預かる際に、アプリケーションのテストコードとそのテストコードのカバレッジに条件を課している。ミドルウェア、データベース、OSのアップデートの際に、事前にテスト環境でテストコードを実行し不具合が現れないかを確認するためだ。状況が許すならば、感触がわかるまでは手元で運用しておき、実績が出てから預けたいところなのだが。。

Comment(0)