やっぱ やってみるまでわかんねぇって

「サービスウェア」の項が個人的に秀逸だと思う。
理想といえば理想だけど、決してできないわけではない点に力を感じる。

Read more!
サービスウェア
2006年10月25日、2:21:09 相馬純平

見積もりは果たして当たるのだろうか？使ったことのある技術で、経験のあるクライアントとビジネスであればかなりの高確率で見積もりを的中させることは可能だろう。

もし2年後新しい技術やフレームワークが登場し、新しいビジネスの案件が出てきたら見積もりは当たるだろうか？答えは「解らない」である。「やってみるまでわかりません」と答える他無い。そして、次が今作ってるソフトウェアは果たしてクライアントの商売の利益になるのだろうか？答えは「解らない」である。「やってみるまでわかりません」と答える他無い。

全世界で「見積もりしろ」「やってみるまでわかりません」という押し問答が繰り返されている。

エンジニアリングの世界ではソフトウェアの見積もりを行うために様々な理論や方法論が考案されてきた。しかし、未だかつて完璧だと世の中が認める何かは存在していない。

なぜ見積もりが正確に当たらないのだろうか？それはそんな方法は世の中に存在しないからである。

そんな方法が世の中に無いにも関わらず強引に見積もりをして、または、強引に見積もりをさせて、外れるとほとんどの場合は現場が残業をしたり、責任を取らされる羽目にある。果たして今から開発するシステムが爆発的な収益を上げることが可能だろうか見積もれと言われて、見積もれるとしたらそれは未来人くらいだろう。それと同じく、ソフトウェア開発の見積もりをしろと言われても、一体どんな作業が発生するのか？どのくらい調査にかかるのか？アルゴリズムの問題点に気がつくのにどのくらいかかるのかなんて、正確にわかるはずはない。

何を作ったらよいのか？
どのように作ったらよいのか？

この2点はやってみるまで解らないので見積もりはムリである。

ではそもそもなぜ不可能である見積もりをさせるのだろうか？それはソフトウェアというモノをどのような仕様かを決定し、それを作るというモノづくり的な考えでシステムが作られるからである。モノ作りにおいて見積もりは絶対である。例えば建築物とか・・・

では、システムは本当にモノなのだろうか？実はシステムという名のソフトウェアはモノではなく、サービスなのである。サービスというのは、需要があり、それを管理運用する組織が存続する限り延々と存在する。だから、サービスの完成を見積もることはできない。

サービスの完成を見積もる　という言葉はおかしい。システムをサービスと考えるならば、明らかにモノでは無いから見積もるという行為自体がミスマッチなのである。資本主義社会においては、サービスの進化が停止するときは、そのサービスに対する需要が無いことを意味する。したがってシステム開発も終了する。このようなシステムを表現するソフトウェアをサービスウェアとここに命名する。

モノという概念ではないサービスウェアに対する要求は刻一刻と変化する。しかし、何が市場から歓迎されるのか最初から知ることはできない。だからといって何もしないわけではない。まず作る。そして市場に投入したら効果測定を行い、更なる要求を得るといフェーズが絶対条件となる。

モノとしてあらわされていたソフトウェアは、最初に要求を確実にしようと考えるため、効果測定はあまり重要ではない。それどころか、効果測定をした結果、使われないと失敗プロジェクトとなり、投資してきた全てはごみとなる。一方で、サービスウェアは効果測定からの要求の精緻化が必要不可欠なのである。そして、新たな要求が実装され続ける。

システムの進化の速度(T1)にビジネスの進化の速度はあわされてしまう。そしてビジネスにおける投資対収益率(T2)は効果測定からの要求開発の精度とT1に合わされる。

ROI = ( T2/T1 - OE ) / I

ROI=投資収益率
T2=要求に対する経済的効果
T1=開発に要する期間
OE=要求の実現にかかる費用
I=何もしなくてもかかる費用

この2つのカオスが2次的に作用するサービスウェアの世界において、見積もりや計画が入り込む余地など存在しない。

今までソフトウェア開発計画を軸に置き、ソフトウェアを開発するという考え方が一般的だったため、あまり気が点かなかったかもしれないが、システムの成長速度を軸にして開発計画を従わせるならば、おそらく無駄が0になる。

それと同様に過剰に作りこむ前に市場の反応に合わせて価値を作りこむモデルでは無駄な要求を実装するムダはほぼ0になる。

日々刻々と要求が反映され続けるシステムに対し、経営的判断でリリースを決定すること事体が経営行為となる。これは開発という不確実性に抵抗するのではなく、従うべきという発想である。

開発者に対して目標は設定するが、それが守られなくてもその自然の法則に逆らってはならない。サービスウェアを健全に永続的に進化させたいなら、この進化の鼓動をコントロールしようとなんて考えてはいけない。さもなくば成長の鼓動は停止し、市場競争力を失ってしまう。計画という軸にサービスウェアの進化の速度を従わせるという考えは捨て去るべきである。サービスウェアの進化の速度に全てを従属させることが長期に渡って成長し続けるシステムを維持する、つまり経営し続けることに必要不可欠なのである。

サービスウェアを健全に長期に渡って成長させ続けるためには下記の条件が必須となる。

テストが自動化され、テスト工数が指数関数的に増大することを防ぐ仕組みが入っていること。

ソフトウェアの責任範囲がインタフェースやアスペクトによって分断されていること。
常に何かしらの価値が提供される状態が維持されていること。

これらが守られるにはコードは組織内で共有され、修正前にはリファクタリングされ(当然自動化テストが実行可能)、誤解の無いわかりやすい名前が付けられ、ユーザインタフェースの実装が限りなく減らされ、画面同士の状態依存が限りなく無い設計が検討されなければならない。

そしてこれらのモラルが疲労や眠気などから破られないよう、最適ペースで作業は進められなければならない。サービスウェアの考え方において開発速度は非常に重要な競争力を持つ。コードで表現できることと同じ事をドキュメント化することは意味が無い。

そしてこの考え方は何も何かのサービスを開発するということに限らない。今までソフトウェアで表現されていたモノのほとんどは実はサービスウェアに当てはまる。行政のシステムはその国家が繁栄し続ける間進化する。ハードに組み込まれるソフトもハードの進化に伴い進化する。たとえプラットフォームが変更されたとしても、何を表現すればよいかという概念は知識を通じて進化し続けるのである。

経営行為が続く間サービスウェアは進化し続ける。つまり開発が終了するということは経営行為が止まるということを意味する。