仕事を選ぶ前に制約を見えるようにする

例として、連携の要望リストに12個のフィールドがあるとします。最初の承認済み同期を動かせるかどうかを決めるのは、そのうち3つです。顧客の識別子、送信先の対象集団、マーケティングの許可です。残る9つも後で重要になるかもしれません。しかし今すべてを平等に扱うと、最初の安全な書き込みさえできないうちに、チームは補足情報の改善に1週間を使いかねません。

制約を設けると会話が変わります。初回リリースの審査枠を5つとし、各フィールドを枠に置きます。6つ目を加えるなら、外すフィールドを名指ししなければなりません。

5つが正しい数だという主張ではありません。要望を一つ追加する費用を見えるようにする方法です。

ボトルネックが人でない場合も同じです。提供元は一定期間の要求数を制限するかもしれません。移行できる時間枠では監査前に一つしか変更できないかもしれません。サポートチームが確認できる顧客別の対応付けは少数かもしれません。役立つ制約は、ほかの資源が豊富でも結果を止めるものです。

要望リストは自分の費用を隠す

制約と創作作業に関する議論では、制作チームが1週間の作業量を物理的な印で可視化しました。小さな背景の細部を磨き続けるには、別の作業から印を移す必要があります。その仕組みは美しさを決めませんが、交換条件を無視しにくくします。

ソフトウェアのチームでは、印はたいてい見えません。要望が管理表に入り、優先度のラベルを付けられ、ほかの20件の「重要な」要望と並びます。そのラベルは、実現のためにどの審査、移行、顧客との会話を遅らせるかを示しません。

連携で不足する資源は、提供元の要求数制限かもしれません。実際のテストアカウントへのアクセス、あるいは同意の意味を調べる時間かもしれません。見える制約は、結果を左右する資源を名指しし、提案された仕事がそれをどう使うかを示します。

Tajo の業務ツール連携ガイドは、まずワークフローと正本を特定するよう勧めます。これは、考え得るすべてのフィールドで要望リストが膨らむのを防ぐ一つの方法です。最初の同期に必要なのは、実際の結果に必要なデータです。

要となる項目を選び、残りを後に回す

例の12フィールドの対応表には、少数の要があります。識別子はどの送信先レコードを変えるかを決めます。許可はそのレコードをマーケティングに使えるかを決めます。対象集団への所属は、どのワークフローに入るかを決めます。この3つが間違えば、ほかの9つでは結果を救えません。

計画表には、その要と消費する能力を並べます。各項目にフィールド定義、テスト用のデータ、送信先の確認が必要だとしましょう。まずその確認枠を確保します。好みに関する追加フィールドには、「最初に動く同期を変えるか、それとも待てるか」という具体的な問いに答えてもらいます。

待つことは、そのフィールドが重要でないという判決ではありません。部分的な順序を付けることです。次の依存項目を決め、残りは証拠や顧客の需要で必要になったときに使えるようにします。

延期は明示します。残る9つを後の待ち行列に置き、それぞれを昇格させる条件を記します。具体的な用途、そのデータを必要とする顧客レコード、必須とする提供元の契約などです。要望を管理表の中で失うのとは違います。条件付きの待ち行列は選択肢を保ち、最初の成果を推測に基づく範囲拡大から守ります。

「人為的な制限はチームを窮屈にし、価値ある発想を隠す」という反論はもっともです。悪い優先順位を守る制約は問題になります。対策は、制約の横に守るべき成果を記し、両方を見直すことです。新たに見つかったフィールドが同意に必須なら、補足情報のフィールドをすぐに押しのけます。制約は変更を妨げるのでなく、見えるようにします。

作業量を表す印は、優先度ラベルが隠す意見の違いも示します。あるチームは開発時間が不足していると思い、別のチームは実際の待ち先が送信先アカウントの管理者だと知っているかもしれません。後者なら開発枠を増やしても意味がありません。最初の書き込みが承認されるまで仕事をたどり、本当に経路を止める段階に制約を置きます。

最初の同期の枠に入るものは？

1. 識別子、許可、対象集団に必要

   今確認する

   なければ最初の承認済み書き込みを定義できません。

2. 具体的な将来の用途に必要

   昇格条件を設ける

   最初の成果を遅らせず、要望を残せます。

3. 結果への影響が定義されていない

   要望を延期する

   推測上の範囲に希少な審査枠を使いません。

制約がもたらした結果を測る

描く価値のあるグラフは「今月閉じた要望の数」ではありません。要望から最初の正しい結果までの経路と、どこがそれを止めたかです。任意のフィールドに審査時間を使い切ったでしょうか。提供元の定義がなく、すべてのテストが遅れたでしょうか。有効化に不要なダッシュボードを延期し、時間を節約できたでしょうか。

処理量の改善を作り話にしてはいけません。実際の一組の作業について、承認済み対応付けまでの日数、送信先で確認したフィールド数、有効化後に見つかった問題数を前後で記録します。見える制約がこれらの結果を変えてこそ役立ちます。

リバース ETL のガイドは、予定されたデータ移動と、対応付けを定義する仕事を区別します。初期の作業範囲が最も効くのは後者です。データは後から追加できますが、最初の契約は今正しくなければなりません。

リストは誰かが求めたものを示します。見える制約は、その要望にかかる費用を示します。