ワークスアプリケーションズ「COMPANY」考 －非常識への挑戦、そしてコンセプト破たんを招いたドン・キホーテ－
ワークスアプリケーションズ社（以下ワークス社）または製品名の「COMPANY（カンパニー）」と言った方が聞きなれているかもしれない。
業務系のシステムインテグレーションに携わる方であれば、誰もが一度は聞いたこと事ある名前だろう。或いはベンチャー企業にアンテナの高い方にとってもそうかもしれない。
＞＞はじめに
ワークス社について語るにあたって、IT業界が辿ってきた歴史を振り返らずにはいられないだろう。
1990年代前後、コンピューターシステムのスタンダードは、ハードウェアメーカーに依存した端末に、様々な業務システムを組み込んでいく、いわゆる「汎用機」型のシステムモデルであった。
例えばNEC、IBMと言ったメーカーのコンピューターに、ユーザーは独自のシステムを開発を行い、販売管理やら人事給与、会計、生産管理といった様々なサブシステムを集約していた。ユーザー社内には汎用機の開発要員とメーカー機に強いシステムベンダーを抱えてシステムを「個別に」作り上げていく、そんな時代だ。
つまり、汎用機時代にはシステムの仕様変更、改修にあたって専任のエンジニアに依存する部分が非常に大きいということだ。これが意味することは、システムが属人化してしまうことによる、ブラックボックス化、技術者の退職や技術継承のコスト、リスクを抱えているということだ。
この状況を大きく変えたのは、1990年代中頃すなわちWindows95の発売開始に象徴されるような、ハードウェアに影響されないOPENなプラットフォームの登場だ。ハードウェアメーカーに依存せずに、様々なシステムを汎用的に構築できるこの新たなプラットフォームは、当たり前の基本技術として今も尚生きづいている。
＞＞パッケージ・システムの隆盛と課題
OPENなプラットフォームの登場は、汎用機時代のような「個別システム開発」から、各業務の標準的に必要な機能を実装した「パッケージ・システム」のインテグレーションへシフトしていった。
パッケージ・システムは、対象の業務に対して標準的なマスタや帳票を実装し、公開されたパラメータ設定、データ処理などを可能にした汎用的で可用性のあるアプリケーションであり、時代と共に洗練されていくこととなる。そしてこのように、標準化された機能を提供することで、個別のシステム開発に比して安価で短納期でのシステム構築が可能となった。
パッケージ・システムによるSIは、クラウドなどプラットフォームの変遷はありながら、今も尚、システムの利用形態のスタンダードであると言えるだろう。
また、パッケージ・システムは機能が洗練されていく中で、汎用機時代にあった「システム仕様の属人化」からの脱却を促していった。
つまりパッケージ・システムにおいて、それが完全とは言わないが、パラメータの修正や随時のバージョンアップによって特定の「ヒト」への依存度を大幅に減らすことが可能となったのだ。
とは言え、パッケージ・システムとて万能ではなかった。実際には、パッケージに実装された標準的な業務機能とそれに対応する業務の個社独自の運用にギャップが生じることも発生した。その為、個社独自の運用や仕様に対してはカスタマイズやアドオンと呼ばれる追加のサブシステムの開発を行っていくこととなる。
ユーザーは、パッケージ選定当初に「標準機能で運用できる」と思っていたものが、標準的なものであるが故に個社独自の運用手法をキャッチアップ出来ない機能を、カスタマイズやアドオン開発などを、後追いで決定しなければならなくなる。ユーザーにとって、これらのギャプ部分を、初期費用に後追いでコスト追加することがストレスとなっていた。
＞＞非常識への挑戦と「COMPANY」の隆盛
そんな時、2000年代に入って登場したのがワークスアプリケーションズ社の「COMPANY」だ。
「COMPANY」のコンセプトは従来のパッケージ・システムのウィークポイントを克服する画期的で新鮮なものであった。それはすなわち
- カスタマイズが発生せず全ての業務を標準機能で実現
- 費用コミットをして追加開発コストが発生しない
- それでも実現できないものはバージョンアップでの機能提供をコミットする
という従来のパッケージインテグレーションの常識へのアンチテーゼとでも言うべき、意欲的で野心的な挑戦だった。
そしてそれを実現するサービス・フレームとして「COMPANY」では、「ユーザーがパラメータを理解するためのサービスを整え、ワークス社によるSI作業が一切発生しない」というものであった。これは、従来のパッケージインテグレーションの常識を打ち崩すもので、それまでのパッケージ・システムは「SIERやパッケージ・インテグレータにシステム導入作業のプロセスを委託する」スタイルが常識であったのだ。
この「非常識への挑戦」とも言うべきサービスのフレームは、「コンサルタント」と呼ばれるエンジニアによる設定方法の支援によってパッケージ導入を行うというもので、トレーニングセンターなどでティーチング、コーチングを通じて受けられるメニュー群によって実現される。パラメータ設定方法の教授を行い、標準のモジュールにない機能はパッケージのGUIを利用した事実上の「システム開発」手法の指導を受けることで、必要な機能を実装することが出来るようになるのだ。
このチャレンジは当初、爆発的と言ってよい破竹の勢いで市場を席巻した。
僕は2003年頃から、人事給与パッケージシステムのSI営業の現場にいたから、その勢いを肌で感じていた。当時、コンペチタ―としてワークス社がいると〝「COMPANY」だから”という理由で連戦連敗したのは、今でも苦い思い出だ。
ユーザーからのRFPにある何100項目もの機能要件に対し、全て無思考と言ってよい位に「全て標準機能で実現できる」という回答を、僕はいくつも見た。
当時のその勢いは、今思い返してもさながら宗教的熱狂のように、業界を席巻していたように思う。
＞＞「COMPANY」の魔法が解けるとき
そんな「COMPANYのロイヤリティ」が一変したのは2000年代後半の頃からだ。
その頃の僕は、未だ人事給与パッケージの営業を継続していて、コンペにおいて負けることが無くなっていた。むしろ、コンペチタ―として登場した時点で優位性を感じるほどに、「COMPANY」の魔法は解けた。
きっとそれは僕だけではなく、業界全体の風潮だったのだと想像する。
なぜ、このようなことになったのか？
それは、パッケージ導入がユーザー主体であることを主に以下のような理由によるからだと考える。
- ユーザーにとって不慣れなPJマネジメントが負担となる
- 仕様面で業務ノウハウが提供されず、機能設計が複雑化してまう
- 通常業務を優先し、パッケージ導入に対するプライオリティを下げてしまい作業遅延を招く
- 仕様のドキュメント化がSIERレベルで作成することの困難さ
- コミットしたはずのバージョンアップによる追加機能提供が遅い
ワークス社とてこの状況に手をこまねいていた訳ではない。
「COMPANY」の導入作業を請け負うサービスの提供を開始したのだ。
これによって、PJのスケジューリング、サーベイランスによる業務要件の抽出と機能Fit＆Gap、進捗管理による遅延防止が出来るようになった。
けれど、この言ってみればSIサービスの提供開始が、「COMPANY」のマジックを解いてしまった。
すなわち、従来型のパッケージインテグレーションへのアンチテーゼとして打ち出した「COMPANY」のビジネスモデルの限界を、自ら晒してしまう結果になってしまったのではないか。そして、SIサービスを提供することでサービスとしてのコンセプト破たんを抱えながらビジネスを進めていくことになる。
そして僕が思う最大の課題は、ユーザーによって構築されたパッケージの仕様或いはノウハウは、特定の誰かに集約されてしまう、ということだ。これは言わば、汎用機時代のユーザーにあった課題をそのまま抱え込んでしまった、のではないか？
属人化のリスク。ユーザーから、導入当初のリーダーがいなくなったとき、誰も手出しができないシステムになってしまうのだ。ドキュメント管理がされているかも分からない。
また、「COMPANY」はアプリケーションとしての可用性も飽和しているように思える。すなわち、「ロードマップ無き機能追加」を重ねていったことで、積み木をただひたすらに積み上げるようにしてグラついている。システムは不安定で処理は重くなり、稼働させるために高スペックの機器が必要となる。
「COMPANY」は当初HR（人事給与）のみのサブシステムであったが、会計、ECなどサブシステムの幅を広げている。けれどこれは、上に積み上げられなくなった積み木の横にもう一つ積み上げるだけの積み木を用意しているかのようだ。
＞＞結び
業務系パッケージメーカーの雄として、一時市場を席巻したワークスアプリケーションズ「COMPANY」。今の彼らは、理想と現実に矛盾を抱えながら、それに目をつぶりながらビジネスを進めているかのように感じる。
まるで、騎士道の妄想に陥り、巨大な風車を巨人と思い違えて物語られるドン・キホーテのようだ。
そのビジネスの変遷と現在について考えることは、変化の激しいIT業界、特にシステムインテグレータ（SI）のおけるビジネスの在り方について、何らかの示唆を与えてくれるものだと思うのだ。
＜了＞
正林俊介