このシリーズの第1部では、サプライヤーに対して不健全な依存関係に陥ってしまう仕組みについて、そして何よりも、それが自社にどのような問題を引き起こす可能性があるかについて議論しました。
今日は、そのような依存を避けるために何ができるかについて考えてみましょう。
1. プロセスおよびシステムのノウハウ、ならびにその開発計画に関する所有権を維持する
ITのことは一切気にせず、ITベンダーに大まかな指示を出すだけだと決めたなら、それは依存関係に陥る最善の道です。意外に思われるかもしれませんが、このアプローチはしばしばベンダー自身にも問題を引き起こします。というのも、時間が経つにつれて、クライアントの要件が重複し、複雑に絡み合い始め、新たな要件に対応することがベンダーにとって大きな課題となるからです。
競争力を維持したい企業にとって、ITを自社のプロセスを支援・改善・測定するためのツールとして捉えることが重要です。その方法を見出すのは難しくありません。なぜなら、今日ではプロセスの全体像を把握し、効果的な計画立案を行うことを可能にする手法や基準が十分に整っているからです：
- エンタープライズ・アーキテクチャとは、組織の目標、それらの目標をビジネスプロセスを通じて達成する方法、そしてテクノロジーがこれらのプロセスをどのように支援できるかを記述する手法です。詳細については、「不十分なエンタープライズ・アーキテクチャに足を引っ張られないように」という記事をご覧ください。エンタープライズ・アーキテクチャに関する最もよく知られた2つのアプローチは、The Open GroupおよびZachmannのウェブサイトで確認できます。
- プロセスの記述 – 最もよく知られ、広く利用されている標準規格は、Open Management Group（www.omg.org）によって策定されています。BPMN（ビジネス・プロセス・モデル・アンド・ノテーション）仕様に基づいてプロセスを記述することで、企業の経営陣は社内で実施されているプロセスを容易に把握し、記録することができます。
- ユーザーマニュアル――これは、ベンダーが作成して引き出しにしまい込み、ほこりをかぶらせるような文書である必要はありません。 効果的なアプローチとして、ユーザーが日常業務でアプリケーションをどのように使用するかを示す動画を撮影することが挙げられます。これにより、製品サポートや新規ユーザーへのトレーニングが簡素化されます。こうした動画はたいてい数分程度の長さで、システムを効果的に活用するために必要な情報をすべて網羅しています。例えば、研究プロジェクトにおけるYammerの活用ガイドや、オンラインショップでの商品注文方法ガイドをご覧ください。
すべての基準および手法には、各分野を詳細に解説した包括的なドキュメントや学習資料が付属しています。私の経験上、特定の企業に適した手法の要素を選定してくれる専門家を起用することは、非常に有益です。
ノウハウを標準化された形式で整理しておけば、会社の改善につながる話題を議論するためのツールが得られるだけでなく、現在および将来のサプライヤーの大多数と共通の基盤を見出せるという確信も得られるでしょう。
プロセスや情報の流れに何らかの変更を加えたい場合は、まず業務の仕組みを見直すことから始めましょう。モデルレベルでの変更でも、パイロット実験を通じた変更でも構いません。その変更が期待通りの成果をもたらすかどうかを検証してください。 次に、変更によるメリットと導入コストを算定します。すべてが想定通りであれば、システムの変更に着手し、そうでなければ、何の問題もなくその取り組みを中止することができます。これを外部ベンダーに完全に委ねてしまうと、すでにリソースを投入したプロジェクトを中止する勇気を持つ人はほとんどいないでしょう。
2. いかなる場合でも、そのデータはあなた自身のものに限ります
データは当社のサプライヤーに保管されていますが、最近、彼らとの関係が悪化し、データは彼らの所有物だと告げられました……。残念ながら、このような状況は、皆さんが想像するほど珍しいことではありません。一般に考えられているようなクラウドサービスやホスティングプロバイダーではあまり起こりませんが、データがサプライヤーによって完全に管理された「ブラックボックス」内に保管される、カスタム開発されたシステムでは、こうした事態が頻繁に発生しています。
これは、顧客をサプライヤーの管理下に置くための伝統的な手法です。この問題は、一般的に2つの方法で解決できます。すなわち、データを直接管理する方法と、利用可能な形式でデータを確実に入手する方法を確保する方法です。
例えば、サプライヤーのウェブサイトに登録することで取得できるメール連絡先を管理するサービスが挙げられます。第一のアプローチは、データを自社のシステムに確実に複製しておくことです。第二のアプローチは、サプライヤーのシステムに保存されている情報を定期的にダウンロードし、「万が一に備えて」自社で保管しておくことです。
自社のシステムであっても、データ保存方法が十分に文書化されている場合でも、データを標準的なテーブル、データベース、またはXML形式にエクスポートする手法を確立しておくことは、新しいシステムの統合を大幅に容易にするものです。 データ抽出の手順を確立し、エクスポート機能が正常に動作すること、およびフォーマットが適切に文書化されていることを確認することが重要です。なぜなら、データを取得する必要があるという決定的な瞬間こそ、エクスポートが機能していないことや、完璧にエクスポートされたデータが処理できない形式でエンコードされていることに気づく最悪のタイミングだからです。
サプライヤーからシステムの新たな機能や変更を受け入れる際には、上記の要件を確認する必要があります。
3. アプリケーションに関する知的財産権を保持する
アプリケーションの所有権とは、そのソースコードまたは設計の所有権を指します。もしソースコードの管理権限を保有していない場合、サプライヤーを変更しようとした際に、既存のサプライヤーがコードの重要な部分を所有しており、それを無償で提供してくれないというリスクが生じます。 これを回避するには、契約書において所有権を明確に定義し、要求された変更の結果として開発されたコードは当社の独占的な所有物であること、あるいは、これらの変更は当社が無料で使用および配布できるライセンスの下で作成されたものであることを明記すればよい。
たとえ契約上所有権を確保していたとしても、契約を解除しようとしているサプライヤーが、必ずしもコードへのアクセス権を付与してくれるとは限りません。そのため、ソース管理システムやWiki、その他の文書は第三者に保管させ、パートナーに対し、特定の場所と時期にデータを保管するよう義務付けることが強く推奨されます。そうすることで、最新のバージョンにアクセスできるようになります。
4. 機能拡張ではなく、システム統合
WebサービスAPI（アプリケーション・プログラミング・インターフェース）は、現在では多くの商用およびオープンソースのアプリケーションにおいて一般的な機能となっています。つまり、アプリケーションのユーザーが利用できるすべての機能は、異なるシステムやアプリケーション間でも利用可能であるということです。
このインターフェースを定義するためにプロトコルや標準規格を用いることで、これらのサービスは統一された通信手段およびプラットフォームとなります。これにより、ある言語やオペレーティングシステムで書かれたアプリケーションでも、全く異なる方法で書かれたシステムからアクセスできるようになります。データはXMLやJSONなどの共通フォーマットで転送され、両システムのコードベースは完全に独立したまま維持されます。
今や、システム連携がどのようなものか、どのユーザーも想像できるでしょう。 何しろ、私たちは皆、互いに連携しているWebアプリケーションサービスを利用しています。例えば、GoogleカレンダーとGoogleコンタクト、Gmailなどがそうです。もし既存のカレンダーの代わりに別のカレンダーを使い始めることにしたとしても、既存のデータと連携させるだけで済みます。しかし、自社システムの場合、当初は会計処理のためだけに導入し、その後ベンダーにCRMモジュールやサービスモジュールなどを徐々に開発してもらったようなシステムでは、このようなシステム変更は不可能です。
この論理は、クラウドサービスプロバイダーがサービスとして提供するシステム（SaaS：Software as a Service）との統合にも当てはまります。Webサービスを利用することで、個々のアプリケーションが互いに独立し、システム全体の柔軟性と透明性が高まります。逆に、異なるモジュール間の固定的な連携があると、サプライヤーが私たちへの依存度を高めやすくなり、コードの複雑さが増大します。また、システムの柔軟性は、最も柔軟性の低い部分によって制限されることになります。
5. 標準システムへの変更は最小限に抑えるようにしてください
標準実装への変更を最小限に抑え、必要なシステムを構築するように努めてください。通常、貴社はベンダーにとって最初の顧客ではありません。導入にあたっては、ベンダーが他の顧客との取引で培った経験を最大限に活用するようにしてください。一部のプロセスがどれほど効率的に実装できるか、あるいはこれまで見過ごしていた特定のデータが競争上の優位性となることに、きっと驚かれることでしょう。
アプリケーションの機能に大幅な変更を加える必要がある場合、将来の新バージョンへの移行が著しく複雑化する恐れがあり、どのような移行であっても、開発およびデプロイの面で困難を伴うことになります。
6. 複数のサプライヤーを利用する
システム設計、開発、導入、運用の一連のプロセスをすべて自社で管理し、ベンダーに任せないようにしましょう。例えば、ビジネスアナリストと開発者を分けるのが良いでしょう。また、開発チームとは別のテスターにシステムのテストを依頼するのも有効です。そうすることで作業効率が向上し、欠陥のない製品が完成する可能性も格段に高まります。 運用を別の当事者（例：クラウドサービスプロバイダー）に委託する場合は、システム運用上の問題を最小限に抑える製品を納品するよう、その当事者が開発者に働きかけることを確実にしておく必要があります。
7. 契約書に解約手続きを明記すること。これには、サプライヤーに対する違約金も含まれる。
契約書では、提携の終了についてどのように定められていますか？3ヶ月前の通知が必要で、その後、貴社が支払いを停止し、サプライヤーもサポートを停止するということですか？それは全く不十分です。
通知期間中、サプライヤーが貴社に、あるいは新しいサプライヤーに直接、どのような文書をどのような品質で提供しなければならないかを明記する必要があります。 第3項で言及した設計、ソースコード、およびその他のドキュメントに関する知的財産権を確保できていれば、なお良いでしょう。サプライヤーとの契約を締結する際には、2位および3位の企業に対し、落札者から開発および保守業務を引き継ぐ場合に何が必要となるかを確認しておくことをお勧めします。
8. サプライヤーに今後の開発計画を伝える
サプライヤーとは長期的なパートナーシップを築くよう努めてください。機能面での現在の変更点だけでなく、開発計画や戦略的な課題についても定期的に話し合うことで、サプライヤーから、現在の要件だけでなく将来の要件にも対応できる、安定的かつ効率的で費用対効果の高いシステムアーキテクチャを構築するための提案が得られる可能性があります。要件を明確にするために、例えば、要件を以下のカテゴリーに分類するMuSCoW法などを活用することができます：
- 必須アイテム – 必須アイテム
- ～すべきだった – ～すべきだった
- 「あればよかったのに」――「あればいいのに」
- 今回はそうはさせない – 現時点では必要ない
9. 他の関係者から意見やアイデアを聞く
一つの場所に固執せず、トレンドを追い、最善のアプローチや手法を探し、あらゆる動向に目を光らせておくことです。外部の企業に依頼して第三者の意見を聞くのも有効です。彼らは技術的および戦略的な両方の観点から、あなたの判断を評価してくれるでしょう。必ずしも高額な費用がかかるわけではありません。こうしたコンサルティングは、ミスを防ぐ助けとなるため、その価値は十分にあります。 私の経験から言えば、あるサプライヤーが、自らが引き起こした問題の解決のために、顧客に数百万クローネもの投資を強要したケースを知っています。しかし、コンサルタントが調査したところ、問題の根本原因は別のところにあるため、その投資では全く解決できないことが判明しました。
コンサルタントは、戦略の策定、需要の創出、選択肢の評価、そして意外な視点からの分析を支援してくれます。また、サプライヤーの監査を行い、お客様にとって最善の結果が得られるようサポートすることも可能です。コンサルタントは、お客様が特定のサプライヤーに依存しないことを望んでおり、自社のノウハウを競争上の優位性として認識していることを常に念頭に置くべきです。
適切なサプライヤーの選定は、リスク管理に他なりません
この記事をお読みになったことで、サプライヤーを単なる従属先ではなく、自社の成功に向けたパートナーへと変える方法について、より明確なイメージが湧いてきたことと思います。不愉快な事態を防ぐには、一貫したリスク管理を行い、現在の要件と将来の柔軟性のバランスが取れた解決策を選択することが重要です。上記の原則に従うことで、サプライヤーや新しいシステムの適切な選定が可能になります。
