ソフトウエアクライシス3 ネット WEB2.0

ネットを前提としたシステムは、不特定多数の利用者を持つ。ネットを前提としていなければ、有る意味閉じたシステムともいえる。有る程度、ユーザが決まっていた。しかし、ネットにUIを持つ・開放するということは、データ更新を伴うオペレーション・操作を不特定多数の人間が行うことを意味している。ネットの前の時代なら、そんなこと怖くてやらなかった。

ネットやWeb2.0になって、ハードやソフトやAPまでも、IPリーチャブルなどこかに置かれている。そういうシステム連携をキチンとデザインできなきゃいけない。少なくとも、それを理解しイメージできてないと、コードもちゃんと書けない。

さあ、ラッピングだ。APIだけ覚えりゃいいにしちゃいましょう。
例えば、オープン系からキャリアスタートの俺が何だかんだ言おうと、ホスト、基幹、汎用には、既存のソフトウエア資産が大量に積まれているのは事実だ。その資産を利用することも必要とされる。だから外側に皮を被せる。ゲートウエイと言ってもいいかもしれない。外からみれば、オブジェクト志向で作られたAPIだけだ。中（裏）では昔のままのレガシーアプリが動いている。中は皮とメッセージ連携、イベントドリブで連動させる。

amazon でも、googleMaps でも、中で、何が動いているかなんて、どーでもよい。
APIで何が提供されているかだけが問題になる。

ブラックボックス化、API化によって、ネットが社会のインフラとして重要度はさらに増してきている。ちょっと前まで、ブラウジング、情報得る、見るだけのお手軽システムだった。せいぜい、ちょいとCGI。

ecサイト。B2B B2C。取引、決済が、ネットをインフラとして電子化されている。それは閉じた世界じゃない。ネットというオープンな世界のテクノロジを使う。xmlを使って、取引の区別をなくそうともしている。（標準化委員会の結論はどうなったかな）
従来のクローズされた世界のシステム以上に、堅牢であり、信頼できることを要求されている。そいつを２ヶ月でやれと求められる。泣いても許してもらえない。

さあ、どうしましょう。

だからこそ、十分テストされた信頼性の高いコンポーネントを使う。それは自分のシステム外でもいい。信頼できれば。
I/F重視、徹底したコンポーネント・モジュール化。

そのシステムデザインをステークホルダが共有する。共有するというのは、単にファイルを共有するということではなく、仕様や設計レベルも含めて共有する。それがないと、前節のインクリメンタル開発は実施が困難になる。そのシカケ、方法のひとつとしてUMLがある。それをチーム開発のリファレンスとする。しかし、UMLで表現すれば、問題が解決するわけじゃない。モデリングが大事であることは論を待たない。モデリングのコアは、アーキテクチャ確立で、これがブレることはプロジェクトのゴールが変わったことを意味する。

ソフトウエアクライシス2 さっさとやらんと他社に負ける

計算機は神様で、電算室、EDP室という神殿があり、技術者は神官であり神主だった。帳票１種類追加してよとお願いすると、完成は１年後ですというご託宣が下ったりした。企画し要求をまとめ仕様を決め、設計、製造、テストまで、２年とか３年でよかった。今でも、インターネットバンキングだと、ページの文言を変更するのに１ヶ月は必要だ。

大半のネットの世界には、そんな幸せはない。
ECサイトを作りたい、というクライアントがいる。
３年前だとカットオーバに３ヶ月もらえた。今じゃあ２ヶ月だ。

さあ、その２ヶ月で、クライアントのビジネスモデルを理解し、時には一緒にモデルを作りつつ、デザインして、コード書いてテストして。
その間に、そのクライアントのライバル・競合会社が、新しい機能をつけたりすると、すぐにつけろ、となる。
携帯のコンテンツをサーブするシステムだと、企画責任者が「ピンクのハートと黄色いハートじゃあ、集客力が違うのよ！」と、直前に言われたりする。PGの「どっちでもいいじゃん」みたいな話は通用しない。それはユーザの嗜好性に基づいたプロジェクトの成否をわける話だから。
画像の差し替えじゃなく、機種依存の絵文字の話だから、かなりややこしい。

開発サイドは、かなり苦しく負荷が高くなる。近々そうなるという話じゃない。もう、そうなっている。

さて、じゃあ、どうするか、だ。

ひとつは、０から作るのはやめましょう、と。
業務・業種で、こういうワークフロがありますね、と。それに対応するフレームワークを作りましょう。コンポーネントの組み合わせを想定しておいて、クライアントの要望をコンポーネントにしてプラグインしていく。
昔からあるパッケージソフトとか、ライブラリー群との違いわかるかな？
コンポーネントとしてプラグインするってところが、オブジェクト指向風。
そして、コードの再利用だけじゃなく、分析・設計の再利用も。
いい悪いというより、そういうスタイルにしなきゃしょうがない。

もうひとつは、仕様変更・追加は必ずあるとリスク管理しちゃう。
リスクといっても、昔のレガシーのころからの工数を大目にするって話ではない。
クライアントとシステムアナリストが、仕様まで落とし込み、コード化がはじまった。しかし、最終は、マーケット、ビジネスを、クライアントとアナリストが読みきったかどうかが大事で、読みが甘いとそこで仕様は変更される。
費用は別として、仮に対応しきれないと、クライアントは満足しないし、クライアントのビジネスは成功しないし、次の仕事はこないし、会社は生き残れない。
最初にいったけど、技術サイドの話じゃない。世の中にニーズの話だ。
アプリの仕様の変更、追加は、クライアントのビジネスの成功のためには、当然のことだ。それが世の中のニーズで、ソフトウエア開発者にとっては、生きていくのがイヤになる時代になった。
だから、インクリメンタル開発。プロトを提示し、早期に確認し、繰り替えし、積み上げの開発が、世の現実のニーズに近い動き方といえる。

以上、webのビジネスサイトを中心に書いたが、組み込みの世界でも、期間圧縮のプレッシャーはかなり強いとのこと。
携帯電話のバグで回収騒ぎがあるが、中身の８０％以上がソフトウエアで、２,３ヶ月のスケジュールで、テストも全てこなせず、品質としては問題があるのはわかっていても、生き残るためには、ヤムナシと市場に投下せざる得ない・・ということも、聞いたことがある。