本当のハイテク企業になるために
以前、ポールグレアムが、「Yahooに起きてしまった事」として、テクノロジー企業としてスタートしたものが徐々にメディア企業としてハッカー文化が摩耗していくといった話をしていた。
Webテクノロジが本当にハイテクだったかはさておき、コミュニケーションのためのWebサービスを開発するという事は、単純なWebサイトを構築したりどこかから拾ってきたCMSをいじったりするのとは本質的に違う。
雑誌を編纂するようにエディトリアルに価値の本質があるわけではないし、コンテンツプロバイダーのようにクリエイティブそのものに価値の本質があるわけではない。
Webサービス企業にとっての本質的価値とはサービスしているソフトウェアのドメイン／構造そのものだ。
サービスしているソフトウェアのドメイン／構造そのものに本質的価値をおく企業は、その表面的なプレゼンテーション層に価値のメインストリームをおかない。
たとえばそれは、Googleにとってはsearchであって、Facebook/Twitterにとってはsocial graph と friend feedであったりする。
このアプリケーションソフトウェアのドメイン/構造に本質的価値をおく企業をこれからのWebサービス企業の形だとすれば、プレゼンテーション層やプラットフォームというものは販促や小売、流通、営業であって、商品開発ではない。
それは決してプレゼンテーション層/プラットフォームに価値が無いことをいいたいのではない。戦略としてプレゼンテーション層に力を入れる事も消して間違いではない。
レイヤが違うという事を(エグゼクティブ、スタッフ、組織が)認識しているかどうかだ。Webサービス、WebアプリケーションとWebページの違いを本当にわかっているのかどうかだ。
それは、販売のフィードバックを商品開発部門がうけとることがあっても、販促部が直接商品開発をすることはないようなものだ。
こういった企業にとって、ソフトウェア開発計画とは事業計画/人事計画でもある。
事業計画/人事計画のようなというのは、開発行程とそのリソース配分そのものがビジネスの進捗に直結するからであるし、
インフラコストと人件費がコストの中心となる企業にとって、コスト改善の為の幾多の意思決定がソフトウェア開発には内在しているからだ。
技術的負債という言葉がある。
技術的負債（英: Technical debt）とは、 行き当たりばったりなソフトウェアアーキテクチャと、 余裕のないソフトウェア開発が引き起こす結果のことを指す 新しい比喩である。「設計上の負債(design debt)」とも言う
というものだ。ソフトウェア開発計画の方針が簡単にぶれてしまえば、事業計画の方針がぶれてしまったときにコストが発生するようにソフトウェア開発にとってもコストが発生してしまう。
製造業が、中国に工場を造るという事業計画を立てて進捗していたが、途中で国内工場の増産にシフトするといった場合、その変更コストは試算され、しかるべき意思決定者によってそのコストが受容される事になるが、ソフトウェア開発企業ではなかなかそうはいかない。
ソフトウェアの技術的負債は、定量化しづらく、コストの試算がきわめて難しい。それはソフトウェア開発工数／工期の見積もりが安定しないのと同じで、複雑系の中にあるものをブラックボックスとして評価する類いのものだからだ。
そして、ソフトウェアアーキテクチャとは、ソフトウェア開発計画に基づいて、適切な抽象化構造をソフトウェアに提供してくことなのだが、この抽象化構造を適切な意思決定者に不可視である場合、この負債の事前評価はさらに難しくなる。
ある意思決定を行った事が、つぎの意思決定への多大なコストを生みうるからだ。
ソフトウェア開発では、個人的な予知に基づいた設計はタブーとされる。不当に複雑な抽象を与えてしまう可能性があるからだ。予知ではなく、現在と計画において適切な構造を提供することが重要だ。
その構造のインクリメンタルな発展であれば、修正コストは最小限に保てる。その構造そのものを別モノに変換するのであればそれが中核的な抽象であればあるほど修正コストは肥大化する。
それは他の業界であれば、
いままで半導体工場を提供していた企業が、その工場でようかんを製造すると方針転換するといえば想像がつくコスト増なのだが、アーキテクト不在のソフトウェア企業であれば、このコストですら秘匿されたものとなってしまう。
これらの可視化と評価はきわめて難しいことだが、
ソフトウェア企業がさらに発展していく為の重要なファクターとなる。
本日発売のWEB+DB PRESSのPerl Hackers Hubにて、技術的負債の定量的評価とアーキテクチャパターンを簡単ながら扱っている。
ぐだぐだと書いたが結局のところただの宣伝なのだ。
