成功したコネクター: ベストプラクティスと実装戦略

コネクターに関するベストプラクティスは、常にルールベースのアプローチを強制し、例外を最初に扱うのではなく、例外やルールベースの枯渇を後から対処することです。

例外ベースのアプローチは、人間の選択と現在のプロセス構造の維持を重視するため、魅力的で魅力的です。 しかし、それは、長期的に健全なプロセスを拡大し維持するための良い代替手段を提供しない場所へのベクトルを示しています。 その点で、ルールとは対照的に例外について考えることから始めることは、私たちが絶対に避けるべき間違いです。

短期的な利益が長期的な痛みをもたらすという要約です。私たちが協力するほとんどの組織は、これを共通点として持っています: 彼らは現在のプロセスの維持を求めています。 技術が求められるとき、それはプロセスの制限と効率の間の妥協点を見つけるのではなく、現在のプロセスを受け入れることを意味します。

私たちのコネクターは、リポジトリからBWXへのコンテンツの流れを橋渡しし、再び戻す方法です。 コネクターを使用した案件で、ファイルを選んで使用する必要がある場合があることは理解していますが、コネクターのベストプラクティスは手動アプローチではなく、ルールベースのアプローチに従うことです。

手動アプローチの誘惑の説明

手動アプローチは、プロセスの変更を少しも必要としないため、魅力的です。 ユーザーは、翻訳したいファイルを正確に探索し、コネクタを使用して翻訳プロジェクトを開始できます。 手動アプローチの問題は、スケーラブルでなく、持続可能でなく、予測可能である（改善が難しい）ことです。

そのため、手動アプローチを検討するのは、コネクタの動作をルールベースの動作に適合させるすべての可能性を使い果たした後のみです。例外に対処することは必要ですが、例外によって設計することはできません。

成功する製品とそれに対応する実装は、可能な限り最大の割合のユースケースをカバーするルールに基づいています。 提案されたパラダイム内でそれらを実装するために、未解決のユースケースは慎重に評価され、回避策やソリューションズを探る必要があります。

例を挙げると、クライアントAはスケジュールに基づいて動作するコネクタを持っていますが、時々スケジュール外の実行を必要とするプロジェクトがあります。 ここでは、これにアプローチする方法について、いくつかの異なるオプションを紹介します。

1. サポートチームにスケジュール外の実行を手動でリクエストする
2. CLI を使用して、スケジュール外の実行をリクエストします
3. 通常のスケジュールよりも頻繁にポーリングされるオフサイクルのブランチ/ディレクトリを作成して、緊急の案件を取得します。

別の例を次に示します: クライアント B は、ローカリゼーション プロセスを開始するためにファイルを選択するために使用されます。 手動のアプローチを永続させるのではなく、ほとんどのチェリーピッキングプロセスは逆にエンジニアリングできる動作に従います。

このリバースエンジニアリングを限界まで押し上げることは、常に努力する価値があります。 UIを通じて最初から例外をカバーすることに集中したり、手動アプローチから始めたりすると、それはプログラムの加速装置ではなく、むしろ足かせになってしまいます。コネクタを考えるとき、私たちは常に自動化を考えます。

これこそが、コネクタによってもたらされる真のプロセス効率です。 コネクターに関しては、プロジェクトのエクスポートとインポートは小さな利点です。 真の利益は、ビジネスルールと、それが生み出す予測可能性とガバナンスを中心に展開します。

問題は、例外によって設計および実装すると、自動化が本当に選択肢にならないことです。 自動化は定義上、ある程度のプロセス変更を必要とし、このプロセスとソフトウェアの適合を推進しないと、期待を超えることができず、混沌のデジタル化を売り込むことになります。

これは私たちの目指すところではなく、これを受け入れることはありません。小規模のコネクターは、大規模のコネクターと同じ設計と原則に従わなければならず、効率的に拡大し成長できるようにする必要があります。 ほとんどのローカリゼーションプログラムは、より多くのファイル、より多くの頻度、より多くのロケール、より短い市場投入時間、より低いコスト、そしてより多くの人々が協力する将来を見据えたユースケースではなく、現在（実際には過去）のユースケースに基づいたソリューションズを要求します。

正しいフレームワークで出発しないと、後でのコース修正は高くつき、非常に困難になります。なぜなら、新しい実装によって導入された変更のタイミングを逃してしまうからです。私たちのすべてのコネクター、大きいものも小さいものも、ルールとパラメーターに基づいています。

これらは同じ設計原則によって管理されており、適切に動作するために UI は必要ありません。 UIは成熟したコネクタにとって興味深い追加要素となる可能性がありますが、主にコネクタの設定を簡単に変更するためのものであり、手動でプロジェクトを開始する方法とは対照的です。

既存のアナログプロセスの加速に加担することは、長期的な成功を促進することはできません。  

むしろ、アナログプロセスをデジタル思考に変換し、それらが真にソフトウェア互換となり、データ指向の自動化を可能にすることが目標です。私たちは、毎日数千のファイルを処理し、ほぼ100の異なるロケールに対応するコネクターを管理することに慣れています。

大規模なコネクターを成功させるための同じ要素は、小規模なコネクターにおいても、スケーラビリティと持続可能性の基本的な設計原則を遵守するために尊重されなければならないことを、私たちは長年にわたって学んできました。