みなさんは「Interoperability(インターオペラビリティ)」という言葉をご存知でしょうか。
私は、最近この言葉を知りました。 しかし、今後は言い訳にしか使う事は無いでしょう。
Interoperability(インターオペラビリティ)とは
「相互運用性」という日本語の意味をもち、異なる装置や製品などを組み合わせた時に、全体として正常に動作することを示します。 ソフトウェアもハードウェアでもこれを目指している製品は多数に存在すると思います。
ソフトウェアでいうと例えばデータベース。 MySQLとかPostgreSQLとかいろいろありますが、これらを組み合わせた時に正常に動作するシステムがあれば、「Interoperabilityが保証されている。」という風に使います。
ハードウェアでいうと例えばネットワーク通信チップ。 異なるメーカーのチップ同士で正常に通信ができる場合、「Interoperabilityが保証されている。」という風に使います。
ただし、上記の様な使い方は、実際あまりしないと思います。 だれもInteroperabilityについて「保証」しないのではないかと思います。
せいぜい、「Interoperabilityに問題なさそうかな?」位の使い方です。 ※あくまで、私の経験の話です。 なぜでしょう。。
Interoperabilityは不可能
要するにこう思います。私は。 まず、Interoperabilityという言葉を使う為には比較対象が、異なる製品やプロジェクトであったりする訳です。 お互いがお互いのペースで進化したり、変化していきます。
その中で、同期しあうなんてほぼ不可能です。 だれか一人が作っている、複数のプロジェクトならば同期可能かもしれませんが、異なる場合はほぼ不可能ではないでしょうか。 その為、要件として「Interoperabilityの保証」などという文言があった場合は、すぐさま逃げた方が良いです。 結局、設計者が「やっぱりできません。。」と、謝ることになります。要件定義の段階で止められるはずなのに。。。
Interoperabilityが無理な例 その1
失敗例のその1を示します。 ある二つの異なる装置があるとします。例なので、なんでも良いですがここでは、ネットワーク装置としましょう。 この二つは、両方ともホットなプロジェクトで開発されている装置で、日々進化しているとします。
両方とも、RFCやIEEE、ITU-Tなどの勧告で定められたプロトコルを実装しているとします。 しかし、特にハードウェアと密接に関係しているプロトコルであれば、あるほどInteroperabilityが難しくなります。
FPGAやマイクロコードなど、ハードウェアもプログラミング可能なデバイスが存在しますが、やはりコストがかかるのか、一度ずれた方向性を修正することは困難な場合が多いです。 その場合、当初Interoperabilityを目指していても、やはりそれは無理だということになり、結局は誤動作させない為に、別な装置から出力されたデータを異常データとして破棄する処理をソフトで実装することになったりします。
Interoperabilityを目指して、散々時間をかけて設計しても、結局は困難なのです。 ただし、これは結果論なので、プロジェクトの成熟度が低い場合はやむを得ないこともあるかと思います。
Interoperabilityが無理な例 その2
失敗例のその2は非常に残念なケースです。 ある二つの異なる装置があるとします。 ある一方は既に開発は完了していて、製品としてはFIXしているとします。
もう一方の製品はその製品の次世代版とします。 レガシー装置の機能に加え、独自機能を追加したり、標準化された勧告にプラスアルファの解釈を含めて開発が進んでいるとします。
しかし、巨大で、多機能な装置ほど、変化や進化を嫌われます。 単純にメモリやCPU処理速度の進化などは歓迎されますが、新機能として画面が追加されたりボタンが追加されたり、文言がちょっと変わったりとかはNGになる場合があります。
レガシー装置と新装置でのInteroperabilityが保証されていても、その「Interoperability」は不要である場合があります。 要するに異なる装置の「相互運用性」は期待されておらず、まったく同じ使用感で処理速度だけ上がったものを期待されるのです。
新装置には当然、ハードウェアが違う場合がほとんどですので、ソフトウェアも作り直しの場合があります。 しかし、結局求められるのはレガシー装置と同じロジックを持つ新製品なのです。
何と残念なことでしょう。。 こんなにクリエイティブではないことはつらいだけです。。。
場合によっては、レガシー装置の「悪いクセ」もそのままとする為に、最適化できるロジックをあえて見過ごす場合もあるのです。。
まとめ
もっと、開発はシンプルに「ミニマムスタート」で行きましょう。 あれもこれもなんて無理です。 夢や希望は良いですが、コストがかかる以上、単純でなければ火を吹くだけです。