クラウドではソフトウェアの品質が課金の差として出てくる

はてなブックマーク - atsushifxのブックマーク - 2009年11月26日の文言「クラウドではソフトウェアの質は課金の差としてでてくる」が秀逸なのでメモ。

【元ネタ】
InfoQ: パフォーマンスを硬貨で測る

はてなブックマーク - atsushifxのブックマーク - 2009年11月26日

(前略)
クラウドプラットフォームでは、CPU使用量を10%削減すれば、そのままクラウドプロバイダからの1ヶ月の請求が10%削減されることになる。
例えば、 Windows Azureは1計算機による1時間の計算に12セントかかる。
このことを知った上でよいプロファイラを使えば、文字通り特定のコードブロックが会社に1ヶ月どれくらいコストを発生させているかを言うことができるだろう。
(後略)

クラウドでは下記の公式が成り立つ。

ソフトウェアの品質の差＝パフォーマンスの差＝課金の差＝コストの差＝利益率の差

データストアがRDBからkey-value storeへシフトする流れがある理由は、クラウドによって、ソフトウェアの品質、特にパフォーマンスの差が利益率に直結する事実が大衆の目の前に出てしまったからだろう。

クラウド上のSW開発は、関数型言語によってデータ処理をMapReduceアルゴリズムでいかに高速化するか、が鍵を握るのかもしれない。
「クラウドコンピューティングは開発者にとってゲームのやり方を変えてしまうものである。」という指摘はとてつもなく鋭い。

クラウド時代のSW開発スタイル

「Twitterの衝撃 140文字がビジネスからメディアまで変える」を立ち読みした。
TwitterがRuby on Railsをフロントエンドで使っているのは知っていたが、メッセージの非同期処理(MQ)でScalaを使って性能改善したという説明があった。
気になったのでメモ。

【参考】
まだブロ: [Scala] Twitterの移行について

twitterがrubyからscalaへスイッチ - huixingの日記

第7回 関数脳のつくり方　First Season - 刺激を求める技術者に捧げるScala講座：ITpro

ScalaはJavaVM上で動く関数型言語。
TwitterがScalaをどこでどのように使っているのか、正直理解できていない。

しかし、大量のデータをさばく処理に対し、関数型言語を使ってMapReduceアルゴリズムで高速化を図っているのではないか、と推測している。
そのためにScalaを使ったのではないか、と。
上記の記事や本によれば、Scalaによるチューニングは大成功だったらしいから、そのノウハウが知りたい所。

Twitterは当初はRuby on Railsでアジャイルに実装しているという印象があった。
しかも、サーバーはクラウドのサービスを利用している。
#Twitter のホスティングは NTT Americaとのこと(コメントを受けて修正)

つまり、サーバー運用をアウトソーシングしているので、スケールアップしやすく、初期投資のリスクも低い。
クラウドというサービスは、ベンチャー企業にとってとても扱いやすいビジネス環境なのかもしれない。

今後のWebシステムの開発スタイルはこんな感じ。
フロントエンドはRailsやSeasarでサクサク作り、バックエンドやバッチ処理は関数型言語でMapReduceアルゴリズムをフルに使って高速化する。
そして、サーバー運用はクラウドのサービスを使ってアウトソーシングし、初期投資のリスクを抑えて、負荷が高まればスケールアップすればいい。

スクリプト言語、関数型言語、そしてクラウドが、今後のWebシステム開発のキーワードになるかもしれない。

ビジネスもSW開発プロセスも鈍重になっていく

最近のビジネス、SW開発プロセスで思うこと。
以前に比べて、どんどん鈍重になっている。

10年位前のSW開発の場合、「納期までに要求を満たすシステムを納品する」のが条件だった。
しかし、最近は更に、「納期までに要求を満たすシステムを納品し、開発プロセスが正しくマネジメントされている」ことを求められるようになった。
だから無駄なドキュメントが増えて、無駄なドキュメントを作る工数も増えてしまい、アジャイル開発しているのにその正当性を説明するのに手間がかかるようになった。

それはビジネスでも同じ。
最近よく言われるのは、コンプライアンス(法令順守)やJ-SOX対応。
確かにコンプライアンスは大事だけれども、本来の業務以外の間接業務の負荷が大きくなり、無駄なコストが増えている。
会社にシステムを導入する場合も、本来の業務を支援するシステムだけでなく、社員の労働状況やコンプライアンス状況を管理するためのシステム導入が増えている。

大前研一や木村剛は、このような最近のビジネス状況を官製不況と呼んでいたように思う。
こういう状況で最も得をする人たちは、取り締まる役割のお役所、総務人事部、あるいはSEPGやPMOなのかもしれない。

最近の企業を取り巻く情勢は、ビジネスのスピードを落とす方向に力を入れている。
SW開発も同様に、開発プロセスの正当性を説明するために、スピードを落とす方向に力を入れている。
正直、アジャイル開発への逆風が強まっている時期なのかもしれない。

要求開発はBABOKに対抗できるか？

先月、要求開発のセミナーを聞いて思った事をメモ。

【元ネタ】
Requirement Development Alliance : 要求開発アライアンス

ＮＤＳ要求開発|社長対談|「学ぶべき道・進むべき道」

ＮＤＳ要求開発|公開ワークショップ

The future is better than the past: 次はBABOK（ビジネス分析知識体系）？

PMBOKの次は「BABOK」が来る？ - 記者の眼：ITpro

要求開発はBABOKも、プロジェクトの立上げ、要件定義以前のRFP作成のプロセスを対象にしているようだ。
つまり、ステークホルダーのビジネス要件、又はシステム開発の要件へ落とす作業をターゲットにしている。

これら2つに必要なスキルはビジネス分析、いわゆるビジネスモデリングだと思う。

BABOKは、ビジネス分析の知識体系を目指す。
要求開発は日本独自の分析技法を提示しているみたい。

要求開発の話を聞いた限りでは、面白そうだけれども、何から手を付けて、どんな技法を使えばいいのか、分からなかった。
要求開発を受け入れている会社の人が一言、BSC(バランス・スコア・カード)を使うといいですよ、と言っていたのを聞いて、そういうレベルでやっているのか、これは難しいな、と思った。

正直、技法も知識も曖昧なので、実践するのは難しそう。
「ＮＤＳ要求開発|公開ワークショップ」のように、もっと実例が欲しいと思う。

でも、「ＮＤＳ要求開発|社長対談|「学ぶべき道・進むべき道」」を読むと、受託システム開発専門のSIerが現状に危機感を持っている理由がよく分かる。
単なる技術屋だけではなく、ITコンサルも兼ねたSIを目指したい、そうしなければ今後のITビジネスに未来がない、という思いは非常に分かる。
特に、クラウドの概念が現実になっている昨今、もはやシステムはスクラッチで開発するのではなく、システムのレンタル販売に移る傾向が大きくなるだろう。

色々探ってみたい。

Webシステム開発のトレンド

2002年頃、Strutsが出た時は興奮した。
それまでフリーでオープンソースのWebフレームワークは無かったから。

同じ頃、Eclipseが出てきた。
Javaの統合開発環境がフリーで、しかもプラグインを追加すれば、UMLやメトリクス出力、JUnitなど色んな機能を追加できる。
Eclipseでサーバー上のモジュールをリモートデバッグできた時は感動した。

Strutsが出る以前は、ベンダ製のWebフレームワークを覚えさせられて、正直嫌だった。
フレームワークのAPIを覚えても、他社プロジェクトで使えない。
フレームワークにバグがあっても、ソースが公開されてないので直せない。
結局、バッドノウハウが増えて、変なパッチが当てられて、どんどんソースが汚くなる。
そして、運用保守になると、誰もソースを触れなくなる。

日本のパッケージベンダーが駄目な理由: プログラマの思索
SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

Eclipseが出る前は、ベンダ製の統合開発環境を高値で購入せざるを得ず、誰もが気軽にプログラミングできる環境がなかった。
特にVisualStudioに慣れていると、ベンダ製のJavaの統合開発環境はUIも機能も洗練されておらず、開発効率も悪かった。

Tomcat＋Struts＋Eclipseがあれば、Webアプリをフリーな環境でフリーなフレームワークを使って開発できた。
デザインパターン、オブジェクト指向プログラミング、リファクタリング、JUnitによるテスト駆動開発を実際に試す事ができて、結構面白い時期だった。

それから、Railsが出てきた時も衝撃的だった。
わずか10分でインストール＋ログイン画面が作れるムービーが流れていて、Javaでガリガリ書いていた環境から見れば革新的だった。
同じ頃にSeasarも出てきて、JavaのWebアプリ開発の敷居も相当下がった。

そして、クラウドが出てきた。
ASPの看板を入れ替えただけと思っていたが、AmazonEC2やGoogleAppEngineに触れて、その思想は理解できてないけれど、革命的である事は直感した。

クラウドでも特にSaaSを実現できれば、もはやWebシステムは自作して運用せずにレンタルすればいい。

サーバーと言うハードウェアの納品とその運用で収益を上げて、Webシステムはその付属品という従来のWebシステムの受託開発ビジネスは、昨今の不況もあいまって、クラウドの出現によって収益率が急激に落ちている。

クラウドは非RDBを必要とする: プログラマの思索
クラウド時代のビジネスモデル: プログラマの思索

Webシステム開発ビジネスは今後どこに行くべきか？
フレームワーク、クラウド等で発展したWeb技術は、どこにイノベーションがあるのか？

今時の小学生はインターネットは当たり前らしい

下記の記事をメモ。

【元ネタ】
小学生のインターネット利用、6年生で約9割--gooリサーチ調査:ニュース - CNET Japan

Rubyを最大63％高速化した中学生は超多忙！ － ＠IT自分戦略研究所

Rubyを高速化した中学生は、小学1年生からコンピュータに触れていると言う。
コンピュータは大学に入ってから、というIT技術者の発想では、ありえないだろう。

今の労働者世代の経験と、今のキッズはおそらく全く違う。

我々の感性ではもはや、Webの新しい発想は出ないのではないか？
彼らの感性が今後のWebビジネスのあり方を変えるのではないか？

マネジメントのスピードが開発のスピードに直結する

倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

(中略)
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
(後略)

上記の指摘は、昨今のシステム開発の現状において非常に的を得ていると考える。

僕は、Redmineによるチケット駆動開発を運用して初めて、アジャイル開発はこういう開発スタイルなんだ！と実感した。
即ち、チケット駆動開発では、ロードマップ画面でバージョンをイテレーションに見立てて、小刻みに機能拡張しながらリリースしていく開発スタイルになる。
つまり、XPの小規模リリースを自然に具体化した開発プロセスになる。

すると、チケット駆動開発を運用する開発チームの内部作業はスムーズに進むようになり、顧客と仕様やスケジュールを調整するプロセスがボトルネックになってしまう現象が頻繁に起こるようになった。
例えば、開発チームではこういう仕様で進めるし、無理ならば代替の仕様が選択肢としてありますよ、と顧客に提示するが、そこで決定に時間がかかってしまう。
実際に作ってリリースして、顧客に見せたら、ちょっと違うよと言われる機能があったり、本来の要件が間違っていた事実も判明するが、どんなスケジュールで直していくか、優先順位を顧客が付けれない。
リリーススケジュールを開発側が提示して、返事待ちという状況が多くなる場合がある。

この状況の原因は、開発の速度よりも仕様やリリーススケジュールを決める速度が遅い点にある。

従来ならば、システム開発そのものに工数もコストもかかっていたが、Railsなどの優れたフレームワーク等のおかげでプログラミングの速度が上がってきた。
そして、RedmineやTestLink、チケット駆動開発で開発チーム内部の作業も効率化し、品質も安定するようになってきた。
すると、開発チームで制御できないプロセスがボトルネックになって、開発の速度に制約がかかる。
特に、レビューと言うプロセスでこの症状が顕著に現れる。

XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに加わり、ストーリーカードの優先順位付け、受入テストなどを行う。
実際の開発では、顧客が開発チームに入るのは難しいので、要件定義を行うSEがその役割を担っている。
倉貫さんはこの手法を「顧客プロキシ」(オンサイト顧客の代理人)と呼んでいた。

ここで、オンサイト顧客(要件定義を行うSE)の重要な役割の一つに、開発チームが作ったシステム仕様をレビューして、品質チェック後、承認するという作業がある。
このレビュープロセス(デザインレビュー)はすぐに完了できるわけではないし、レビュー後にその仕様で実装していくから、レビュープロセスのキューにどんどんタスクが溜まって、開発速度が落ちる現象が頻繁に起きるようになった。
かと言って、レビュープロセスを簡略化したり、無視していいわけではない。
そして、SEの代わりに顧客を連れてきても、状況はおそらく変わらない。

今の僕の経験では、デザインレビューが開発のボトルネックになっている。
つまり、デザインレビューの速度が上がらなければ、開発の速度が現状以上に上がらない。

要求を洗い出す作業と、要件を仕様化する作業は別の能力だと思う。
要求開発やBaBOKのレベルでは、業務の全体最適化(つまりエンタープライズアーキテクチャ)の観点から、システムのあるべき姿を導き出す。
しかし、我々ITエンジニアは、要件をいかにシステムとして実装して稼動させるか、という作業に注力を注ぐ。
それらの作業は大きく異なる。

その作業をつなぐ部分にボトルネックがあるのかもしれない。

同期安定化プロセスのメモ

クスマノの本「ソフトウエア企業の競争戦略」をもう一度読み直した。
この本には、マイクロソフトの開発プロセスである同期安定化プロセスについて詳しく書かれている。
考えたことをメモ。

【元ネタ1】
Y2’s blog ? Blog Archive ? 本: マイクロソフト・シークレット(上)

次に開発プロセスです。開発プロセスについては、クスマノ氏が「同期安定化プロセス」と読んでいるマイクロソフトの手法についての説明です。
しかし、読み進めていると、実はこれがほぼScrumやXPなどのアジャイル開発プロセスが進めている方法と同一であることがわかります。
この本が出版されたのが1998年、アジャイルマニフェストが公開されたのが2001年とのことで、実はアジャイルマニフェストを作成した人々は同期安定化プロセスを参考にしたのではないかと疑います。

少し具体的にあげると、
・定期的なビルド -- アジャイルやスクラムでのDaily Buildやイテレーション
・開発工程の分割 -- スクラムのイテレーション
・プログラム管理者と開発チーム -- スクラムのスクラムマスターとチーム
・設計書より成果物を優先 -- アジャイルでも同じ
・見積もりは開発者に行わせる -- スクラムでも同じ
などです。

マイクロソフトが編み出した同期安定化プロセスとアジャイル開発の類似性は、知っている人には知られている。
曰く、夕方5時にデイリービルド。
曰く、プログラマはテスト担当者とペアになって作業する。
曰く、開発目標は定めるが、頻繁に変わる設計書よりも動く製品を優先する。

つまり、複数のサブチームの成果物をデイリービルドで「同期」を取り、その度にテストして「安定」を図るのが同期安定化プロセス。

アジャイル開発も同期安定化プロセスも、結合テストを早期に行っていると言うのが最大の特徴ではないか？

SW開発はいつも、多数のモジュールをバラバラに作った後にビッグバン統合を実施し、結合テストを行って、初めて重大な問題に気付く。
単にコンパイルエラーが見つかるだけでない。

インターフェイスが合わなかったのは、設計書に記載が無かったからだ。つまり、設計漏れ。
動かしてみて顧客に見せたら、違っていると言われた。つまり、要件漏れ。
実際にビルドしようとすると、ビルド環境の構築作業が間違っていたり、ライブラリのバージョンに相違があったり、テストデータが足りなかったりしていたからだ。つまり、ビルド作業漏れ。
そういう重大な問題は早期にキャッチしたい。

しかし、実際のSW開発では早期に結合テストを行うことができない。
特にWF型開発ではそうだ。
何故だろう？

業務システムと法律の関係性

業務システムの仕様を突き詰めると、法律にぶち当たることが多い。
特に、会計システムや勘定系システムの場合、金融に関する法律のために、込み入った仕様になっている。

J-SOXも然り。
法律のために業務システムが作られる。
コンプライアンスを実現するために、業務システムが作られる。

業務システムを作る理由は、定型化されたワークフローで人を動かすためにあるのではないか？
ルーチン化された業務は、業務システムでカバーした方が安上がり。
人数の多い会社ほど、手動によるワークフローの管理はミスが多く、手間もかかるのだろう。

特に金融系のシステムの仕様は、法律の塊だ。
複雑な業務システムの背後には法律があるのだろう。

クラウド時代のビジネスモデル

クラウド時代のビジネスモデルについてメモ書き。
＃きちんと理解できてないので後でまとめる。

【元ネタ】
クラウドコンピューティング - Wikipedia

知られざる先進業界「地銀」に見るシステム共同化の真実 - ITPro

【1】クラウドコンピューティングには下記3種類がある。
1-1.SaaS(Software as a Service)
インターネット経由のソフトウェアパッケージの提供。
例えば、Salesforce CRM。

1-2.PaaS(Platform as a Service)
インターネット経由のアプリケーション実行用のプラットフォームの提供。
例えば、GoogleAppEngine。

1-3.IaaS(Infrastructure as a Service)
インターネット経由のハードウェアやインフラの提供。
例えば、AmazonEC2.

これらの特徴は、ハード不要、サーバー不要であること。
ユーザにとって、ITは利用するものである。
ITシステムはユーザ企業にとって資産ではない。
データセンターを維持する運用コストは馬鹿にならない。

技術の特徴は、ハードの仮想化だ。
特にGoogleAppEngineは、ユーザから見れば、アプリケーションをデプロイすればすぐに起動できる。
VMWareも同様の技術の流れ。
本番環境もアプリケーション実行環境も全て仮想化してしまった方が、後で安くつく。

【2】クラウド化が進むとビジネスそのもの大きく変化する。
ITはサービスであり、利用料さえ払えば誰でも使える。
ハードもソフトもシステムも自前で保有する必要はない。

そもそも受託開発は必要ないのでは？
SaaSを利用して、ERPやSNSを社内に展開すればいい。
膨大な運用コストはユーザ企業は必要ない。
この場合、ソフトウェアをクラウド上で利用する。

あるいは、ユーザ企業にSW開発の能力があるならば、ユーザ企業自身が自社開発すればいい。
自分たちが業務や問題点を一番よく分かっているのだから、自分たちの業務改善のために自社システムを作ればいい。
その場合、インフラやプラットフォームとしてクラウドを利用すればいい。

すると、ソフトウェアシステムこそが、ユーザ企業のビジネス上の競争優位の源泉という発想になるはず。

【3】IT化よりもクラウド化が最も進んだ業界がある。
それは銀行。
知られざる先進業界「地銀」に見るシステム共同化の真実 - ITProによれば、特に地方銀行がそうだ。

地方銀行の事務を支えるシステムは、複数の銀行による共同利用になっている。
システムは共通だから、銀行の独自性は、使うパラメータが微妙に違ったり、帳票出力する項目が微妙に違ったりするだけ。
地方銀行の事務はどこも殆ど共通なのだ。
つまり、銀行の看板が違うだけで、銀行の業務は全く同じ。

だから昨今、銀行の統合再編がやりやすいのだろうと思う。
米英が最近まで、金融とITで産業再生して高成長した理由は、上記にあるのかもしれない。

ところで、銀行に勤めている人に聞くと、昔と比べて仕事が面白くないと言う。
昔は、銀行独自の仕組みやシステムがあったので、この帳票のこの項目は、こういう業務から発生してきたんだな、と言うのが、経験するにつれて分かってきたけれど、今はシステムがブラックボックスのために全く分からない。
しかも、昔は預金や融資が主な業務だったのに、今は投資信託などのように高度な専門知識が要求されるため、昔のスキルが全く通用しない、と。

システム化、クラウド化が進むにつれて、ホワイトカラー、特に事務員の仕事は単純労働に近くなっている。
SEもIT土方と言われているし。

おそらく、今後、工場のようなハードに依存しないサービスを中心とした業界は、上記のようなクラウド化が進んでいくのではないか？
すると会社の看板が違うだけで、中身はどこも同じではないか。

そして、クラウド化が進むにつれて、IT業界も半導体業界のように、大量の投資資金を持つ会社しか生き残れなくなるだろう。
大規模なデータセンターを運用できる資金力と、常時稼動し続ける耐障害性や膨大のトランザクションをさばききる技術力がなければ、もはや生き残れないのでは？

今はIT業界は、技術革新が盛んで、個人でもプログラミングスキルに秀でていれば、世界を変えることもできる。
でも、じきに半導体業界のように、膨大な投資を延々と続けることができなければ、じきに淘汰されるのでは？