アンドリュー・タン
この優秀なエンジニアチームについて、何らかの形で聞いたことがあるかもしれません。彼らは、あなたが聞いたことのある企業での豊富な経験を持っています。彼らは、サブ100msのレイテンシーで毎秒数百万のイベントを処理するストリーミングプラットフォームを構築しました。この技術的成果は本当に印象的です。
しかし、彼らが最後に機能を出荷したのは8か月前です。
それは、彼らが構築できなかったからではありません。彼らがそれに取り掛かることができなかったからです。スプリントのバックログは、「調整タスク」でいっぱいになりました。アーキテクチャレビュー会議、セキュリティ承認、ステークホルダー合意セッション、コンプライアンスチェックリスト。それぞれが単独では合理的です。しかし、それらが一緒になると、処理すべきデータよりも遅く動く官僚主義を形成しました。
これが組織のボトルネックです。そして、それはどこにでもあります。
パイプラインの問題
データエンジニアが単純なタスクを抱えていると想像してください。顧客イベントストリームに新しいフィールドを追加することです。1日、せいぜい2日で終わるはずです。実際に起こることは次の通りです：
1-2日目: コードを書く。変換を構築する。ローカルでテストする。すべてが機能する。
3日目: データガバナンスレビューに提出する。新しいフィールドには、隔週で開催される顧客データ委員会の承認が必要であることを知る。
4-10日目: 待つ。並行して他のことを構築する。コンテキストスイッチのオーバーヘッドが蓄積する。
11日目: 委員会がフィールドを承認するが、特定の値を匿名化する必要があるという要件が付く。変換ロジックを更新する。
12日目: セキュリティレビューが匿名化アプローチを指摘する。代替案を提案する。代替案を実装する。
13-14日目: 再テスト。QAに提出する。
15-18日目: QAがエッジケースを発見する。修正する。再提出する。
19日目: ステージングにデプロイする。予定されたステージングウィンドウを待つ。
20日目: プロダクトオーナーがフィールド名が新しい命名規則に一致しないことに気づく（先月の会議でこのエンジニアが招待されなかった）。フィールド名を変更する。すべての下流参照を更新する。
21-23日目: フルテストスイートを再実行する。承認を再取得する。デプロイする。
3週間。1つのフィールドのために。
エンジニアが仕事が下手になったわけではありません。組織が彼らを遅くするのが上手くなったのです。
3つの摩擦の力
このパターンが数十の企業で繰り返されるのを見た後、私は3つの根本原因を特定しました：
1. 承認の迷路
すべての組織にはゲートキーパーが蓄積されます。セキュリティはレビューを求めます。法務はレビューを求めます。データガバナンス委員会はレビューを求めます。アーキテクチャボードはレビューを求めます。各ゲートキーパーはリスクを減らそうとしています。しかし、累積的な効果は組織の麻痺です。
問題はこれらのレビューが存在することではありません。それが順次行われることです。それぞれのレビュアーが自分の領域（セキュリティ、コンプライアンス、一貫性）に焦点を当て、遅延のシステムコストへの可視性がないことです。誰もエンドツーエンドのタイムラインを所有していません。
私はフィンテック企業で、スキーマ変更をデプロイするのに11の署名が必要だったところで働いていました。ここでの話は赤いテープについてです。
2. ツールチェーンの断片化
現代のデータスタックはフランケンシュタインの怪物です。ストレージに5つの異なるシステム。オーケストレーションに3つ。監視に2つ。それぞれが異なるチームによって異なる年に異なる理由で購入されました。
その結果、データエンジニアは1つのWorkflowを完了するために7つの異なるツールに触れる必要があります。各ツールには独自の認証、UI、ドキュメント、癖があります。それらの間でのコンテキストスイッチは、実際のエンジニアリング作業よりも多くの認知負荷を消費します。統一されたデータオーケストレーションプラットフォームは、この断片化の多くを排除できます。
チームはシステム間を移動するだけで40％の時間を費やしています。さらに30％はそれらのシステム間の統合問題をデバッグするのに費やしています。残りの30％が実際のデータ作業に使われます。
彼らを支援するはずのツールが彼らの仕事になってしまいました。
3. 所有権の曖昧さ
顧客データパイプラインの所有者は誰ですか？データエンジニアリングがそれを構築しました。データサイエンスがそれを使用します。分析チームがそれに依存しています。それが午前2時に壊れたとき、誰もが他の人を指差します。
これは怠惰ではありません。それは構造的な問題です。現代のデータアーキテクチャは従来の組織の境界を超えています。しかし、報告ライン、予算、責任は追いついていません。そのため、「共有所有権」が生まれますが、実際には所有権がないということです。
最悪の部分は、最も気にかけている人々が苦しむことです。パイプラインが遅くなっていることに気づいているが、それを改善する予算がないエンジニア。技術的負債が蓄積していることを見ているが、「ビジネス機能」に対する優先順位を得ることができないチームリーダー。
なぜ優れたエンジニアがそれを解決できないのか
ここに不快な真実があります：組織の摩擦をコードで解決することはできません。
私はこれらの問題に最高のエンジニアを投入するチームを見てきました。彼らは内部プラットフォームを構築します。抽象化レイヤーを作成します。ドキュメントを書きます。これらの努力は周辺で役立ちます。しかし、根本原因には対処しません：組織のプロセス、構造、インセンティブが必要な作業と一致していません。
それは、フォーミュラ1のエンジンを調整してから、ラッシュアワーの交通を通り抜けるようなものです。パフォーマンスはあります。ただ、それが発揮できないのです。
実際に役立つこと
フレームワークを提供するつもりはありません。フレームワークは問題の一部です—別のテンプレート、別のプロセス、別の調整オーバーヘッドの層。
代わりに、実際に機能する3つの原則を紹介します：
- ゲートではなくフローに焦点を当てる。 各承認ステップはその存在を正当化するべきです。レビューが少なくとも20％の確率で実際の問題を発見しない場合、それを排除します。順次承認から並行協議に移行します。会議での「たぶん」ではなく、監視での「はい」をデフォルトにします。
- クリティカルパスを統合する。 すべてのツールが必要なわけではありません。しかし、データエンジニアがコンテキストを切り替えずに設計、デプロイ、監視できる1つの場所が必要です。断片化の認知コストは、「ベストオブブリード」のポイントソリューションの利点よりも速く複利で増加します。
- 単一スレッドの所有権を割り当てる。 すべての重要なパイプラインについて、1人（または小さなチーム）がエンドツーエンドの結果を所有します。彼らは予算、権限、責任を持っています。責任の拡散はもうありません。
layline.ioの視点（簡単に）
これが私たちがlayline.ioをこのように構築した理由です。スタックに別のツールを追加したかったわけではなく、3つまたは4つのツールを統一されたものに置き換えたかったからです。
Visual Workflow Designer。ワンクリックデプロイメント。組み込みのモニタリング。バッチとストリーミングの両方を同じインターフェースでサポートします。目標は機能密度ではなく、フローステートです。エンジニアを彼らが本当にやりたい仕事に戻すことです。
しかし正直に言うと、ツールは簡単な部分です。難しいのは、組織の現在の摩擦がバグであり、機能ではないと決定することです。出荷がプロセスの遵守よりも重要であると決定することです。速度が競争上の優位性であり、保護する価値があると決定することです。
結論
あなたのデータチームが遅いのは、才能がないからではありません。彼らが何年にもわたる善意のリスク管理によって有機的に成長した障害物コースを通り抜けているからです。
解決策は、別の再編成ではありません。調整オーバーヘッドを削減し、クリティカルパスのツールを統合し、明確な所有権を割り当てるという意識的な決定です。そして、「もう1つだけ」承認ステップを追加するという避けられない圧力が来たときに、その決定を保護することです。
速度は無謀ではありません。データインフラストラクチャにおいて、それは生存です。
アンドリュー・タンは連続起業家であり、layline.ioの創設者であり、バッチとリアルタイムの両方のワークロードを大規模に処理するエンタープライズデータ処理インフラストラクチャを構築しています。
