私たちのソフトウェアシステム事業を取り巻く事業環境が、社会のパラダイムシフトとあいまつて、激変の状況にあるといわれて久しい。
たしかに顧客企業の生き残りをかけてのリストラ、リエンジニアリンング、ビジネス再デザインは切実であり、それにともなう情報化投資も従来の目的が明快で単純な効率性追求型から総コスト抑制、より最適化に向けてのライトサイジング、さらにバスに乗り遅れるな式のネットビジネス化が一般となっている。いずれも企業の根幹に抵触する目的が設定されるも成果が不透明で予測できないシステムが主流になりつつある。
このことは、私たちのシステムづくりのイメージを大きく変化させている。ソフトウェアシステムに携わる事業者自身が流れの変化を的確に認識しし自分自身が変化せねばならない。私はこの流れをおおまかに次の３点に集約して捉えている。
このことを顕著に物語る事例を紹介したい。
最近、ソフト開発を専業とするソストハウス A 社は、大手化学プラント製造メーカ Y 社の情報ネットワークシステム構築に参加した。
Y 社はすでに全国に分散する工場、営業所の基幹業務 ( 受発注、在庫、経理、物流など ) のためのネットワークシステムを運用しており、今回はこの基幹システム保有情報の効率的な活用と社員個々の持つ知識、ノウハウ、個別文書を知識データベース化し会社総合力の強化を図るのが新システムの主たる目的となっている。
新システムは、基幹システムと双へきをなして社を支えることから TWINS と呼ばれている。
A 社にとって TWINS でのシステム構築の方式はまったく衝撃的なものであった。結果として期待していた開発すべきアプリケーションがほとんど存在しないのである。
A 社は当初、 TWINS 構想を開くに及んで久しぶりの大型物件であり大量のアプリケーションプログラムの開発に期待が膨らんだ。それゆえシステム構想段階から社でも自慢の SE である S 君、 W 君をほとんど無償で参加させ、その後の請負開発の優先的な発注を持ったのである。
特に S 君は Linux 、Appschで有名になったオープンソース技術にも大きく興味を覚え個人的ながらコミュニティなどにも積極的に参加し情報を収集している勉強熱心な技術者である。
しかし A 社にとり TWINS の結果は悲惨なものであった。 TWINS は社員個々のモチベーション関わるシステムであり先が見えにくいとのことで、スタートは現場へのインフラ提供を優先したコスト抑制型の構築が指示されており、その後の運用状況の把握と利用者の意見を収集しながらシステムを成長させることが内々に打ち出されていたのである。
従ってネットインフラが DFS ( デファクトスタンダード ) ベースの商用アプリであり、さらに S 君の尽力によりオープンソースでのパッケージ、ミドルウェア、 DB を駆使することによりほとんどの初期機能が実現できることが判明したのである。
もちろんこれらの高度なインテグレーション、ネットワーク構築さらに現行業務や社内文化にフィットしない部分や商用パッケージでは実現できない機能の新規開発もあるがもあるが、 SE の S 君や W 君の報告ではもう 1 〜 2 名の技術者の追加で事足りるとの話である。
しかしエンドユーザ Y 社からの S 君、 W 君の現状分析能力やパッケージ評価及び選定能力、システム化構想能力に対する技術力の評価は絶大であり、彼ら抜きではシステム構築はおぼつかないとの言葉も頂いている。 A 社は Y 社より評価され選ばれている。しかし TWINS に対する売りものの商品を間違えたのである。
従来であれば TWINS クラスのシステムは、
ノウハウベースの活動が商品
では、 SE 各人の持つ技術的な面からの ” ノウハウ ” や ” センス ” は商品として売りものになるだろうか。アプリケーション開発が商品として存在していれば、ノウハウやセンスはプログラム開発工程の中で生産性や品質という形で反映し、結果として大きく貢献することになる。このプログラムを介さない形での無形物が商品として独立して成立するであろうか。 A 社の社長は、この無形物の商品を考えるとき、ソフトウェアに対する社会的認知や有償化に費やした長い歴史を思わずにはいられなかった。
コンピュータシステムが社会的に脚光を浴び各種業界へデビューしはじめた 1970 年代前半は情報処理産業として自立する黎明期でもあった。ハードウェアが余りにも高価すぎてソフトウェアはその付属品としてとらえられていた。しかもソフトウェアはモノとして目に見えない。見えないものはサービスであり、サービスは無償であるとの考えが大勢であった。当然、見積書にもソフトウェアの開発費用を記載しないのが一般でもあった。ところが時代とともにハードとソフトの比重が逆転するに従い、外資系ベンダーを中心にアンバンドリング ( ソフトとハードの価格分離 ) が浸透し、約 10 年の歳月でようやくソフトウェアが独立した価値として社会的に認知されるに至った。
この歴史的事実を振り返るとき、はたして SE あるいは組織のもつ ” ノウハウ ” が、そのバックボーンとしてプログラムも存在しない、無形物商品として認知成立するであろうか、疑問を禁じえない。当然、 SE の拘束時間に対する有償対価、 1 人月 50 万、 100 万、 200 万は可能であろうが、それでは余りにも十把一からげで、提供するノウハウの内容、難易度、結果の評価、付加価値が生かされず商品としての事業化が成立しない。しかし世の中は確実に、プロダクト中心から、情報技術の高度活用を目指したソフトサービスへの新しい対応が求められている。ソフトハウスが生き残るにはこの市場価値観の変化を敏感にキャッチし、
A 社はさっそく、部長、次長、上級 SE による 「無形物商品化委員会」を発足させ、 Y 社への支援業務をサンプルとして SE 個々や組織として提供できる無形物の有償価値化 ( 商品化 ) のためのメニューづくりに着手した。このメニューは、 「SE の活動が商品」との基本コンセプトから 「アクションプロダクトメニュー」とネーミングされた。 A 社の好意により、この一部を誌上にて公開しよう。未だ完成したものではないが無形物の商品を考えるうえで大いに参考になると思う。
アクションプロダクトメニュー体系
アクションプロダクトは次のようなツリー式の商品メニュー構成とする。
アクションステージ
商品としてのノウハウを提供するシステム完成まで場面、プロセスの区分。
| ステージ | 商品の内容 |
|---|---|
| 企画ステージ | システム化計画における基本コンセプトを明確にし、現状調査を踏まえて、システムニーズ / 予算からのシステム化構想を確立する。実現のための具体的リソース ( サーバー、クライアント、 LAN 、 WAN 、 DB 、ミドルウェア、パッケージ、アプリソフト ) の選定をマルチプラットフォーム行う。 |
| 構築ステージ | 企画プロセスでのシステムリソースより、実際に運用するためのシステムを構築する。構築にあたっては実現業務に優先度を設定し、段階的な評価フィードバック構築を行う ( プロトタイプモデル、スパイラルモデル ) |
| 教育ステージ | システムを効果的に運用するための操作教育、業務教育を行う。特にシステム導入で仕事のしくみの変化するセクション、運用上キーとなるセクションやメンバーには業務改善の視点からの指導も行う。 |
| 運用ステージ | 実際に現場での運用及び移行を支援する。運用の利用状況、問題点を把握し、運用を浸透させるためにタイムリーにケアする。活性化のための現場状況をプロモーションステージへリポートする。 |
| システムケアステージ | システムの直接的なトラブル保守、予防保守、改善保守を行う。さらに、環境変化 ( 法的、組織変更、ニーズ変化など ) に伴う保守や、さらなる発展に向けての企画等を進言する。 |
| プロモーションステージ | システムの現状と将来的な観点より利用者活性化のためのシステムの高度化、内部 / 外部システムとの連携アライアンス、物理的スケールの対処としてネットワーク / セキュリティの評価・再構築などの進化成長を支える。 |
ライフソリューションとして当社はアクションステージのすべてのステージにメニュー商品をラインナップしている。
今現在 20 数社の企業と親密な IT パートナー契約のもと、約 30 システムのライフソリューションを実施している。
システム化や IT でお困りの皆様、是非当社を IT パートナーとして選択していただき 「システムライフソリューション」をご検討ください。