概要
企業が利用できる標準や手続き、プロセスと言われるものは数多く存在します。高いレベルにおいては、標準は主に、手続き的なもの (実行方法) と技術的なもの (従うべきこと) の 2 種類に分類することができます。企業は、社内に手続き的な標準を導入することで、効率的な運営を可能にしています。また、社外向けの手続きや技術標準を取り入れている場合もあります。技術標準は、コンソーシアムや標準化団体によって古くから開発されてきました。そうした技術標準には、公開された標準に基づくものと、プロプライエタリなデファクト標準があります。この文書は、企業外部のオープンな技術標準に従うことの重要性を議論し、強調することを目的としています。それでは議論を進めましょう。しかしその前に、社内の手続きやプロセス、標準を見直すところから始めてみましょう。
企業があらゆるレベルで標準的な手続きを導入すべき理由は何でしょうか。標準に従うことは決して新しい組織現象ではありません。企業は常に、自社の従業員を共通の規則や標準に従わせなくてはなりません。メモやタイムカード、会計手続きはすべて、社内で標準化されているものです。
開発の世界では、アプリケーションを複数の開発グループで設計するため、標準に対するニーズがあります。多くの企業は、社内で開発標準や慣例を文書化しています。例えば、ある企業が C++、Java、JavaScript を主要なコーディング言語にすることを決めたとします。その企業は、プロジェクトごとに、マーケティング仕様要求書、製品仕様要求書、機能仕様要求書、品質保証テスト計画、検定書を用意しなければならないでしょう。
企業は、成長に伴って、管理を強化するためにより多くのプロセスを必要とすることに気付きます。それにより、より容易に計画や予測を立てることが可能になります。企業はこうしたプロセスを利用して、リリーススケジュールの作成、マーケティングプランの実施、資源配分の分析を行い、必要に応じて調整を行うことができます。標準やプロセスを遵守することで、開発が予測可能になるため、実際に相当の弾力性が得られます。標準的なプロセスは、予測可能性をもたらすだけでなく、理解や効率化のコストを抑えることも可能にします。
一般的な開発プロセス
企業が成長するにつれて、マネージャやエンジニアは、こうしたプロセスを遵守することの重要性について基本的理解を深めていきます。提案されたプロジェクトは、企業全体の事業戦略に合致するかどうか評価されます。続いて、製品マーケティング担当者が、アプリケーションや製品の市場性を分析し、徹底的な技術評価と市場調査を実施しなくてはなりません。プロジェクトが承認されると、そうした情報、分析、調査は提案依頼書 (RFP) としてまとめられます。
こうしたプロセスは珍しいことではありません。多くの企業が、製品やサービスのための基本的なプロジェクト管理プロセスを持っています。社内でも、こうしたプロセスは既存の企業文化のもとでうまく機能するよう微調整されます。これが行われると、開発標準が作成され、それに従うことが期待されるようになります。
しかしプロセスにとらわれると、なぜ企業でそうしたプロセスが定められているのかということは忘れられてしまいます。結論から言えば、企業は、コスト、時間、資源を節約するためにプロセスを定めています。もちろん他にも、責任やチェックポイント、スケジュール調整といった理由がありますが、プロセスを定めることは、最終的には、企業の投資効果を最大化するということなのです。
他の標準
社外で定められている他の標準に従うことも重要です。私たちが取っている行動の方法や理由に影響を及ぼしている標準化団体は数多くあります。例えば会計の分野には、米国財務会計基準審議会 (FASB) や国際会計基準審議会 (IASB) という団体が存在します。すべての米国企業は、FASB によって定められたガイドラインに従うことが期待され、また同時に求められます。監査役が企業の経営状態を評価する場合も FASB の基準に従って行います。
企業のソフトウェア開発の分野に焦点を当てても、様々な標準化団体が開発の意識決定に関わっていることに気付くでしょう。例えば、ある企業が Web ベースのクライアントを開発する場合、以下の団体によって課せられた標準を遵守する必要があります。
- ANSI (米国規格協会)
- ATSC (Advanced Television Systems Committee)
- ECMA (ヨーロッパ電子計算機工業会: 情報とコミュニケーションシステムの標準化)
- IEEE (Institute of Electrical and Electronics Engineers)
- IETF (Internet Engineering Task Force)
- IRTF (Internet Research Task Force)
- ISO (国際標準化機構)
- ITU (国際電気通信連合)
- OASIS (構造化情報標準促進協会)
- OMA (Open Mobile Alliance (旧 WAP))
- UNI (Unicode Consortium)
- W3C (World Wide Web Consortium)
会計士やプロジェクトマネージャが従うべきプロセスや標準と同じように、このような標準化団体が開発者コミュニティに焦点を当て、その方向性を定めています。それらの整備されたガイドラインに従うことで、例えば AOL のような企業も、コストを削減しながら、ユーザ体験、相互運用性、コードの再利用、共有資源、そして営業上の信用を強化することができるのです。これらの各項目については後の段落で議論します。
相互運用性
相互運用性の鍵は、長期の利用に耐えうる標準に従うことです。企業は、自社の開発プロセスに組み込むことを選択した標準が、将来にわたって適切であるかどうか、確信を持つ必要があります。言い換えれば、長期的な将来性が必要ということです。多くの企業が犯す基本的な間違いは、プロプライエタリな方式、ソフトウェア、コード、標準の採用です。プロプライエタリな方針に従った結果、多くの企業が悲惨な道を歩んできました。
ここで代表的な例を紹介します。Xerox Corporation は、1980 年代前半に Star Office System を設計開発し、確実に時代の最先端を行っていました。Star Office System は、パロアルト研究センター (PARC) のエンジニアによって開発された、アイコンを用いたデスクトップを持つ、洗練されたワークステーションでした。Star は、Microsoft や Apple でさえ今日実現できていない機能を提供していたのです。
Xerox のエンジニアは Pilot というプロプライエタリな開発 OS をもとに Star を開発していました。Pilot には Co-pilot と呼ばれる高度に統合されたデバッグツールが付属しており、エンジニアは問題をすばやく簡単に修正できました。しかし Xerox は、Pilot や Co-pilot がどれほどパワフルであっても、Star ワークステーションはプロプライエタリであるが故に、時代とともに進化できないということを軽視していました。Xerox は、独自のハードウェアプラットフォームとクローズドな開発 OS に拘束されていました。そして、コードを他のプラットフォームに移植し、オープンソースとして公開する機会が何度かあったにも関わらず、それを選択しませんでした。その結果、製造開発コストの上昇と売り上げの減少を招き、Xerox は最終的に Star の生産を終了したのです。
Xerox を成功に導いた最大の資産が、後に自らに対する破壊兵器となってしまったわけです。彼らは、プロプライエタリな環境に依存したまま、その環境を他と比較したり、標準を定める機会を逃しました。
オープンな標準に従うことは副次的なメリットをもたらします。企業が、業務提携や合併、買収によって、他のアプリケーションと情報交換を行う必要性が生じたとき、関係者全員が最初から標準に従っていれば、統合と相互運用性にかかるコストはずっと少なくて済みます。一貫した標準は、開発のやり直しを大幅に削減し、アプリケーション間の動作に一貫性と予測可能性を与えます。
ユーザ体験と営業上の信用
企業にとって、顧客の維持と市場の拡大は重要課題です。ユーザは、特定の製品を採用する際、その製品の一貫性、信頼性、予測可能性について好意的な体験をした上で決定を下すはずです。ユーザの知識が向上し、各種デバイスが手頃な価格になるにつれて、彼らは様々なデバイスから同じ情報にアクセスするようになります。そして、デスクトップ、携帯電話、あるいは携帯端末から Web サイトにアクセスしても、それらの情報が同じように表示され、動作することを期待するでしょう。従って、企業が製品群を提供するとき、そのユーザ体験は製品間で一貫性と予測可能性を持つようにしなければなりません。
一貫性
企業が成功を収めるためには、こうしたユーザの期待を理解し、製品間で一貫したユーザ体験を提供する必要があります。ユーザビリティが製品間で大幅に異なっていたら、ユーザは不満を訴えるでしょう。
Apple や Microsoft はこうした教訓を十分に学んできました。Macintosh は、Mac OS 8.x から 9.x にバージョンアップしたとき、インターフェースやデスクトップのメタファーはほとんど変わりませんでした。ユーザはあるバージョンから次のバージョンへすばやく簡単に移行できたのです。しかし、Mac OS X のリリースに際して、Apple はそのインターフェースやデスクトップのメタファーを完全に見直しました。その変更は Apple のユーザコミュニティに大論争を巻き起こしました。それによって Mac OS は多少不便になったかもしれませんが、ユーザが順応できないほどの変更ではありませんでした。賛否両論の記事が書かれ、Apple は一部のユーザを失う一方で、新たなユーザを獲得しました。
一貫したユーザ体験によってどれほどユーザの忠誠を得られるかという事例は、Microsoft がアプリケーション間の動作を共通化していることにも見て取れます。例えば、Word や Excel、その他の Windows アプリケーションでは、どの製品でも Ctrl キーと C キーを同時に押せばコピーという操作を実行できるということを私たちは知っています。この動作は一貫していて予測可能なものであり、後にデファクト標準となりました。そうした動作に一貫性と予測可能性がある理由は、Microsoft がユーザビリティに関する一連の社内標準を定め、関連する国際標準をサポートしたことによります。
アクセシビリティ
アクセシビリティ標準を見過ごしたり無視できる企業はありません。Web 環境において、アクセシビリティ標準は、HTML、XML、XHTML などの W3C 標準と密接に関係しています。アクセシビリティガイドラインを統合し、サポートすることで、企業は、より多くの幅広いユーザ層に向けて、自社の製品群やサービスを提供できます。
互換性
ユーザは、複数の製品で一貫した動作を体験すると、特定の操作や機能がどのように動作し、反応するかを予測できるようになります。製品の提供者は、できる限り予期せぬ動作をしないという基本を守るべきです。一連の全体的な目標と標準を社内に浸透させることで、企業は、エンドユーザがあるデバイスから別のデバイスに移ったとしても、一貫した情報の交換、機能、表示、処理を可能にすることができます。
アプリケーション間で相違を認めることの重大な欠点は、異なるアプリケーション間で情報を処理する際に、複製や改変が行われてしまうということです。これは、そうした様々なアプリケーションのためのオーサリングツールに関する問題も生み出します。例えば、Web ブラウズに利用できるアプリケーションが複数あったとします。各アプリケーションは独自の開発方針に従い、標準をサポートしています。それらは国際標準を一部サポートしていますが、完全にはサポートしていません。それでは、どのオーサリングツールを使うべきでしょうか。各アプリケーションのためにプロプライエタリなオーサリングツールを開発することは、コスト的に見合うでしょうか。この場合、各製品の市場における普及率はどのくらいでしょうか。それらの製品群が統合されていない場合、企業はどのようにして一貫した市場シェアを獲得できるでしょうか。そして何よりも、それらの製品に互換性がなかったら、ユーザ体験はどうなってしまうでしょうか。
共有資源
企業は、共有すべき標準の方針を社内に浸透させれば、複数のプロジェクトでエンジニアリングリソースを活用できます。開発エンジニアは、中断期間を最小限に抑えて、プロジェクト間をより容易に移動できます。コーディング手法は一貫しています。予測も理解しています。企業が提供する複数のアプリケーションは同じ機能を備えています。そして、エンジニアは幅広い体験をすることで、社内でより一層有用な存在となります。
例えば、Web ベースのアプリケーションが W3C 標準に準拠することが期待される場合、各エンジニアは W3C 標準を知って理解することが期待されます。その結果、開発作業を通じて同レベルの標準がサポートされ、アプリケーションを越えたコーディングやコードの再利用も可能になるでしょう。
また、ある開発エンジニアが C と C++ の ANSI 標準に従ってアプリケーションを開発する際、特定のプラットフォーム上でコーディングを行っても、そのコードは ANSI 標準をサポートしている他のどのプラットフォームや OS でもコンパイルできます。Microsoft 製品の移植が難しいのは、同社が、この ANSI 標準に従っていない、Windows のみの標準である Microsoft Foundation Classes (MFC) を導入していることが原因です。
品質保証
厳密なテストを行わなければ、製品を市場に向けて発表しても無残な失敗に終わるということを、私たちは経験から知っています。サポートスタッフの教育に限らず、顧客の不満に関しても、技術サポートにはコストがかかります。
企業が品質テストに標準を適用すべき理由はそこにあります。一連の標準を採用することで、品質保証部門は、複数のプロジェクトで利用可能なテスト工程を開発できます。標準化された一連のテスト工程があれば、品質保証部門は、それらのテストを容易に保守、検証、認証できます。また、余計なテストデータベースを削除して、一貫性と信頼性を確保できます。標準化は、開発エンジニアと同様に、品質保証エンジニアの技能を向上させ、プロジェクト間の移行を可能にします。
まとめ
企業が製品開発を複数のデバイスや製品群へ拡張するにつれて、統合や互換性が重要な要件となるでしょう。一連の未来志向の国際標準を遵守することで、機能間の統合が可能になります。標準の採用は、企業のエンドユーザがアプリケーション間で一貫したユーザ体験を享受できるようにするだけではありません。開発エンジニアや品質保証エンジニアに、より高度な機能を備え柔軟性を高めるツールを提供することで、企業自体も恩恵を受けられます。最後に、一連の標準に従うことで、企業は、社内全体の進捗状況、業績、成果をより容易に評価できるようになります。
最も切実なジレンマは、オープンな外部の標準あるいはプロプライエタリなデファクト標準に従うことを、企業がどのようにして選択するかということです。プロプライエタリなデファクト標準に従うと、その標準の所有者が関心や方向性を変えたり、標準を完全に放棄したり、その発展を停滞させた場合に、企業は脆弱になり、陳腐化を免れなくなります。一方、オープンな技術標準を採用し、その標準の開発と方向性に関与すれば、企業は将来の開発、成長、利益に向けた道を切り開くことができるでしょう。
原文書の情報
- 著者: Beth Epperson
- 最終変更日: 20 Feb 2003