説明できる判断と、その証拠を準備する
以下の15問と30の深掘りは、2026-10-05に確認した公式事実から作る独自の練習問題である。Databricksが実際に聞くと確認した質問ではない。「何を確かめる問いか」も編集上の推論であり、採点rubricではない。fact IDは先に職責・公式面接案内の記事で読む。
Tokyoの一般FDE求人は本番実装、Spark runtime、複数cloudを重視し、Tokyo AI FDEはGenAI application、評価、1cloudでの本番MLを挙げる。各問の適用職種を明記し、両方を使う場合も事実の持ち主を分ける。本番の考え方には他社と共通する部分もある。その共通性を同じ採用processの証拠にはしない。
本人の経験を使い、未経験なら未経験と言ってoffline設計演習を明示する。以下の数字は必要な場面で示す証拠の種類であり、架空実績やDatabricksの合格閾値ではない。顧客credential、課金API、live workspaceは不要である。
- 1実projectまたは明示した演習
- 2dataと責任の境界
- 3失敗仮説
- 4条件を揃えた比較
- 5releaseまたは復旧判断
- 1足りない証拠
- 2小さな合成case
- 3限界を記録
- 4次の検証計画
DB005、DB011〜DB012、DB017、DB021〜DB023の業務領域から作った独自の準備フローである。内部architectureや面接順序ではない。同じcaseを保ちつつ仮説を変え、toolを使ったことだけでなく、なぜその判断になったかを示す。
DB-TQ01: 顧客の1つのrequestを、元dataからmodel、利用者の画面までどう追いますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB002, DB005, DB012, DB017 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002、Tokyo FDE CSQ427R277 / ATS 8741922002。DBS01 公式資料, DBS02 公式資料。
何を確かめる問いか — 推論： model単体でなく、他teamが担当する境界を含めて本番経路を説明できるかを確かめる練習。
回答に含める証拠・数字・判断： 実際のprojectを選び、data到着、変換、model呼出し、response、UIを描く。境界を越えるrevision、identity、request IDを示す。自分の実装・判断とteamの成果を分ける。入力件数、freshnessの遅れ、error率、end-to-endのp95待ち時間は単位と測定期間を添える。却下した設計案と、その案が満たせなかった制約も残す。
深掘り1：modelは正しく答えたのに画面のdataが古い場合、何を調べますか。
説明すべき点：同じrequestで元dataのrevision、pipeline完了時刻、cache/indexの年齢、UI stateを比較する。入力が古いのか表示が古いのかを分け、各境界のownerと復旧方法を示す。最初からmodel再学習で解決しようとしない。
深掘り2：失敗したrequestを再試行した時、結果の不整合をどう防ぎますか。
説明すべき点：固定request ID、繰り返せる処理、重複検出、利用者に見える処理中・失敗stateを説明する。writeがある場合は権限確認とcommitを回答生成から分ける。意図したdata revisionに対応するresponseであることを確かめるtestも示す。
避ける浅い回答： 「APIとUIを接続した」だけでは、dataの版、責任、復旧方法が分からない。
DB-TQ02: 本番Spark jobが急に遅くなった時、どの仮説から確かめますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB007, DB011, DB012 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002。DBS01 公式資料。
何を確かめる問いか — 推論： 処理が終わるまでcomputeを増やすのでなく、分散runtimeの挙動を観測から説明する練習。
回答に含める証拠・数字・判断： 実際の遅延から、共有できる実行planとstage/taskの観測を持つ。同じworkloadのbaselineに対し、入力量・分布、task時間のばらつき、shuffle、spill、I/O、executor失敗を比較する。仮説の順序と、各観測で支持・棄却できる点を説明する。1つの条件を変えた前後の時間、retry、resource費用を記録する。
深掘り1：skewと広いresource不足をどう区別しますか。
説明すべき点：少数の長いtaskと多数のtask全体の遅延を比べる。該当stageのdata分布とpartitionを調べる。何が出れば仮説が外れるかも示し、worker追加で長いtailが残り得る理由を説明する。
深掘り2：tuningで速くなっても採用しないのはどんな場合ですか。
説明すべき点：出力の正しさ、peak負荷、費用、失敗率、入力分布が変わった時の感度を確かめる。使った設定とworkload、regression検査を残す。cacheが温まった1回の実行を、本番で再現する改善として扱わない。
避ける浅い回答： 「clusterを増やした」で終えず、原因、条件を揃えた比較、残るtrade-offを示す。
DB-TQ03: 遅延・重複・再処理されるdataに対して、pipelineの正しさをどう保ちますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB011, DB012, DB017 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002、Tokyo FDE CSQ427R277 / ATS 8741922002。DBS01 公式資料, DBS02 公式資料。
何を確かめる問いか — 推論： 処理時間だけでなく、dataの意味と復旧を本番設計に含める練習。
回答に含める証拠・数字・判断： 実際のdata contractとしてentity key、event/arrival時刻、想定順序、訂正方針を説明する。重複・遅延をどこで検出し、replayで下流modelの入力とUIの結果がどう変わるかを示す。実際の件数、照合差、data遅延を使う。検証したdelivery保証と、前提にしただけの保証を分ける。
深掘り1：一部の出力を書いた後でretryした時、復旧は何を証明すべきですか。
説明すべき点：commitの境界と完了済み処理を同定する証拠を示す。retryが上書き・追加・照合のどれを行い、下流が一貫した版をどう読むかを説明する。完全restartだけでなく途中まで進んだ失敗もtestする。
深掘り2：reportが使われた後に業務上の訂正が届いたら何を変えますか。
説明すべき点：訂正の承認者、修正する期間、利用者へのrevision通知を定義する。監査履歴を残すことと、過去回答を無言で置き換えることを分ける。照合手順とownerも示す。
避ける浅い回答： 「platformがretryする」だけでは、重複や訂正の業務上の意味を説明できない。
DB-TQ04: 顧客が別cloudへの展開を求めた時、何を再利用し、何を検証し直しますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB005, DB010, DB024 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002。比較対象はTokyo AI FDE FEQ227R196 / ATS 8569392002。DBS01 公式資料, DBS03 公式資料。
何を確かめる問いか — 推論： applicationのlogicと、cloud固有のidentity・network・storage・運用を分ける練習。2cloud要件からの推論である。
回答に含める証拠・数字・判断： 実際に知る2つのcloudと、そのうち専門とするcloudを示す。application contract、identity経路、data境界、接続、deployment、monitoringを別々に対応付ける。未知の境界には小さな検証計画とrollback条件を置く。実測した移行工数や既知の制約があれば使い、未実行の比較はそう記す。AI FDEは指定cloudの1つで本番ML経験を求めるため、こちらまで2cloud要件とはしない。
深掘り1：顧客のidentity/network統制が好みの設計と衝突したら何を変えますか。
説明すべき点：強制すべき境界とsecurity ownerを特定する。限定的な統合と全面移行を、data移動、運用責任、復旧で比較する。本番accessの前に必要な検証も説明する。
深掘り2：未検証のportabilityを主張しないために何を残しますか。
説明すべき点：変えない部分とcloudごとにtestした部分を、versionとworkloadとともに列挙する。設計上の同等性と実測挙動を分け、不足する証拠とcloud固有部分をreviewできる人を示す。
避ける浅い回答： 「同じcloud serviceがある」で済ませず、統制と運用の違いまで確かめる。
DB-TQ05: code・data処理・model挙動が同時に変わる変更を、どうreleaseしますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB012, DB017 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002、Tokyo FDE CSQ427R277 / ATS 8741922002。DBS01 公式資料, DBS02 公式資料。
何を確かめる問いか — 推論： CI/CD・MLOpsをtool名でなく、再現できるrelease経路とrollback責任として説明する練習。
回答に含める証拠・数字・判断： 自分が担当したreleaseを選ぶ。code、依存、data/schema、modelやpromptの版、設定、昇格した環境を同定する。test gateと各段階で残した証拠を示す。実際の展開時間、失敗判定、測った復旧時間があれば使う。承認者と、旧版を使い続けられる理由も説明する。
深掘り1：codeのrollbackはできてもdata schemaが変わっていたらどうしますか。
説明すべき点：戻せない処理と別に戻す処理を分ける。移行中のreader保護、利用できるversion組合せ、testした復旧方法を示す。binaryを戻せばdataも戻るとは考えない。
深掘り2：model変更がunit testを通っても出力品質を変えたら、何で止めますか。
説明すべき点：code testだけでなく、関連する失敗群を含むversion付き評価setを使う。合意した受入条件、canaryの対象、停止・rollback ownerを説明する。仮の閾値と実projectの閾値を分ける。
避ける浅い回答： 「CI/CDを使った」だけでなく、artifact、gate、失敗経路を示す。
DB-TQ06: 利用者ごとにaccess権が違うdata・AI applicationを、どう安全に設計しますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB005, DB017 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002、Tokyo FDE CSQ427R277 / ATS 8741922002。DBS01 公式資料, DBS02 公式資料。
何を確かめる問いか — 推論： data検索、model呼出し、UI結果にわたって利用者の権限を保つ練習。具体設計は編集上の推論で、公開された試験課題ではない。
回答に含める証拠・数字・判断： 実例、または仮想と明記したrequestに、principal、許可data、service identity、write操作を描く。どこで権限を強制し、modelが決めてはいけないことは何かを説明する。権限外利用者、権限変更、根拠なし、危険な出力のtestを示す。logの内容・閲覧者と、残さない機微情報も明らかにする。
深掘り1：summaryだけ返すapplicationでも制限dataを漏らし得ますか。
説明すべき点：検索結果とlogを含め、modelへ入る資料すべてを追う。生成前にaccessを絞る方法とresponse確認を説明する。短いsummaryにするだけでdata境界は消えない。
深掘り2：agentがservice identityでactionを要求した時、誰が許可しますか。
説明すべき点：要求した利用者と実行serviceを分ける。決定的policyで操作・resourceを検証し、影響のある変更に必要な確認を説明する。credentialを出さず、拒否と監査の証拠を示す。
避ける浅い回答： 「開示しないようpromptに書いた」だけでは権限制御を証明できない。
DB-TQ07: GenAI applicationを想定利用者へreleaseしてよいと判断する証拠は何ですか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB021, DB023 — Tokyo Senior AI Engineer–FDE FEQ227R196 / ATS 8569392002。DBS03 公式資料。
何を確かめる問いか — 推論： 平均scoreだけで済ませず、用途・重大な失敗・本番判断を評価につなぐ練習。
回答に含める証拠・数字・判断： 利用者、行う判断、失敗時の影響を定義する。期待結果と代表的な失敗分類を持つversion付き評価setを示す。caseの選定者と受入条件の承認者を明らかにする。測ったsample数、分類ごとの失敗率、待ち時間、費用を使う。限界、段階公開の対象、monitoring、停止できる人も説明する。
深掘り1：平均scoreが上がっても重大な失敗群が悪化したらreleaseしますか。
説明すべき点：平均に埋めず、その群の影響とcoverageを示す。合意した受入条件、sample数による不確実さ、scope制限を比較する。保留・限定公開・releaseのどれを選び、何が変われば判断を変えるか説明する。
深掘り2：offline結果はよいのに利用者が離れる時、何を調べますか。
説明すべき点：業務成功と評価scoreを分ける。live入力の構成、UIの摩擦、待ち時間、根拠の有用性、利用者のworkflowを比べる。人が確認した失敗を次の評価revisionへ戻し、model出力を正解にしない。
避ける浅い回答： 「accuracyが目標を超えた」で終えず、目標、失敗、sample、本番判断を定義する。
DB-TQ08: RAGの誤答が検索由来か生成由来か、どう見分けますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB022, DB023 — Tokyo Senior AI Engineer–FDE FEQ227R196 / ATS 8569392002。DBS03 公式資料。
何を確かめる問いか — 推論： AI FDE求人が経験例に挙げる領域で、失敗箇所を切り分ける練習。
回答に含める証拠・数字・判断： 実際の失敗、または合成と明記したcaseに、質問、許可された出典のrevision、検索passage、出力を揃える。必要な根拠が存在・取得・正しく利用されたかを分ける。検索coverageと根拠付き回答の品質は別に比較する。corpus規模、freshness境界、sample数、1つの変更の効果を記録する。観測なしに大きなmodelで検索問題が直ったとはしない。
深掘り1：正しいpassageが取れたのに誤答する場合、次に何を見ますか。
説明すべき点：contextの組立て、版の矛盾、質問解釈、引用との対応を調べる。1箇所を変えて同じcaseを再実行する。根拠不足で保留すべきcaseも含める。
深掘り2：検索改善が品質を上げても待ち時間と費用が増えたら、どう判断しますか。
説明すべき点：業務単位で追加資料量・時間と改善した失敗群を測る。検索範囲を絞る、reranking、scope縮小を検証案として比べる。実際の受入制約と、設計変更の前に必要な証拠を示す。
避ける浅い回答： 「embeddingとRAGを入れた」だけでなく、失敗の発生箇所と修正を選んだ比較を説明する。
DB-TQ09: 検索、fine-tuning、より単純な決定的処理を、どんな条件で選びますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB022, DB023 — Tokyo Senior AI Engineer–FDE FEQ227R196 / ATS 8569392002。DBS03 公式資料。
何を確かめる問いか — 推論： 経験例の技法を高度に見せるchecklistにせず、失敗の原因に応じて選ぶ練習。
回答に含める証拠・数字・判断： 実際のtaskとbaselineから始める。現在の事実が欠ける問題、出力挙動が安定しない問題、直接計算できるtaskを分ける。data鮮度、学習・評価dataの利用権、変更頻度、運用負担、品質を比較する。比較を実行したなら結果を示し、未実行なら検証計画と不足する証拠を明記する。
深掘り1：fine-tuningでsampleは改善しても顧客の事実が毎日変わる場合、何が未解決ですか。
説明すべき点：変えた挙動と、最新の事実を取得する経路を分ける。古い根拠・根拠なしと、好ましい出力形式を別々にtestする。version更新の責任と、改善主張が無効になる条件も示す。
深掘り2：単純なSQLやruleが十分に動く場合、LLMを残す理由は何ですか。
説明すべき点：まだ解けない利用者の要求と、測れる影響を特定する。残らなければ単純な案を選ぶ。顧客がAIを求めたことだけでなく、運用費用と復旧で比較する。
避ける浅い回答： 「fine-tuningの方が正確」「RAGは常に有利」と言い切らず、task・失敗・比較を示す。
DB-TQ10: 小さなtool群を持つ1agentよりmulti-agentを選ぶ根拠は何ですか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB021, DB022, DB023 — Tokyo Senior AI Engineer–FDE FEQ227R196 / ATS 8569392002。DBS03 公式資料。
何を確かめる問いか — 推論： 調整の追加が観測した問題を解き、本番でも評価できるかを確かめる練習。
回答に含める証拠・数字・判断： task境界、各componentに渡る根拠、許可action、最終判断のownerを説明する。1agentのbaselineと分割案を、測った成功・失敗率、tool呼出し数、待ち時間、復旧負担で比較する。message contract、停止条件、traceに必要な情報を定義する。未実装なら仮想設計と記す。
深掘り1：2agentが対立したり同じactionを繰り返したりする時、loopをどう止めますか。
説明すべき点：実行上限、重複action防止、対立を決める権限を説明する。観測stateと失敗testを示す。agentを増やしても、modelへ権限や不可逆commitを決めさせる理由にはならない。
深掘り2：単体componentはよいのに全workflowが悪化する時、どう評価しますか。
説明すべき点：componentとend-to-endのcaseを分ける。引継ぎで失う情報、根拠の矛盾、累積待ち時間、失敗の伝播を調べる。検証した価値がなければ取り除く・簡単にする境界も示す。
避ける浅い回答： 「agentごとに専門役を置いた」だけでなく、全taskがよくなる証拠を示す。
DB-TQ11: 業務用語とaccess境界の両方が曖昧なText2SQL回答を、どう検証しますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB022, DB023, DB005 — Text2SQLはTokyo AI FDE FEQ227R196 / ATS 8569392002、secure architectureはTokyo Sr. FDE CSQ327R52 / ATS 8568173002。DBS03 公式資料, DBS01 公式資料。
何を確かめる問いか — 推論： SQL実行、業務上の意味、権限を別々に確かめる練習。Text2SQLはAI FDEの経験例、secure architectureは一般FDEの事実である。
回答に含める証拠・数字・判断： 業務質問の用語、時刻境界、許可view、期待結果を定義する。固定snapshotで同名entity、null、join、禁止列、根拠不足をcaseにする。query、返った行とrevision、回答、引用を一緒に示す。実行上限と実際の失敗分類を記録し、query成功を正答と同一視しない。
深掘り1：SQLはvalidでも顧客が指標に異議を出したら、どう調べますか。
説明すべき点：指標ownerと分母、filter、timezone、業務定義を確定する。同じsnapshotで期待結果を照合する。意味・data・query生成のどの誤りかを示し、訂正した定義にversionを付ける。
深掘り2：権限外のfieldを利用者が求めた時、どう動作すべきですか。
説明すべき点：query結果がmodelへ入る前にpolicyを強制する。明示的な拒否や、許可された狭い結果を説明し、制限行から裏で推論しない。拒否caseと、安全に残せる監査fieldを示す。
避ける浅い回答： 「queryが実行できた」だけでは、意味・根拠・accessの適合を証明できない。
DB-TQ12: 品質悪化を隠さず、GenAIの待ち時間や費用をどう減らしますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB021, DB023 — Tokyo Senior AI Engineer–FDE FEQ227R196 / ATS 8569392002。DBS03 公式資料。
何を確かめる問いか — 推論： token単価や単発の最速呼出しでなく、利用者の成果と失敗群を制約にして最適化する練習。
回答に含める証拠・数字・判断： taskの境界を決め、model、検索/tool、retry、context量、利用者から見たend-to-end時間を分けて測る。実際のtask数、p50/p95、完了task当たり費用、評価結果に測定期間を添える。追加の運用負担も含め、候補変更を1つずつ比較する。測っていないsystemの削減率は作らない。
深掘り1：安価なmodelでretryと人の訂正が増えたら、本当に安いですか。
説明すべき点：会計の境界を示し、retry、失敗、reviewまで完了taskに含める。実測費用と人の時間の見積りを分ける。増えた誤りがその業務で許されるかも説明する。
深掘り2：cacheで速くなってもdataや権限が変わる場合、何を確かめますか。
説明すべき点：cache keyのdata revision・権限前提、無効化規則、scopeを説明する。古い根拠と権限変更をtestする。有効範囲外の回答を返すよりcacheを使わない条件を示す。
避ける浅い回答： 「token単価が安い」だけでなく、許容できる完了taskの費用を比べる。
DB-TQ13: cloud上のML実験を本番serviceへ変える際、何を制御しましたか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB024, DB025, DB027 — Tokyo Senior AI Engineer–FDE FEQ227R196 / ATS 8569392002。DBS03 公式資料。
何を確かめる問いか — 推論： 1cloudでの本番ML経験を運用の具体像として示す練習。preferredのDatabricks/Spark背景を必須へ変更しない。
回答に含める証拠・数字・判断： 実際に使ったcloudを選ぶ。学習/入力lineage、artifactの版、serving capacity、identity、monitoring、顧客の運用境界を説明する。実負荷、展開頻度、driftや失敗、復旧の観測を使う。自分の担当を示す。別platformの経験なら概念の対応を誠実に示し、まだ学ぶ必要があるDatabricks固有の挙動を分ける。
深掘り1：学習品質は安定していてもlive挙動が変わった場合、何を比べますか。
説明すべき点：展開artifactに対し、入力分布、feature/data revision、依存、serving設定を比べる。offlineで再現できる点と足りない本番観測を示す。dataやservingの修正と再学習を分ける。
深掘り2：動いている顧客ML serviceを新platformで作り直しますか。
説明すべき点：必要な成果、移行risk、governance、運用工数を比較する。移す根拠、限定的な移行とrollback計画を説明する。製品に慣れていることだけで置換を正当化しない。
避ける浅い回答： 「cloudにmodelをdeployした」だけでなく、制御したartifactと運用責任を示す。
DB-TQ14: incident時、顧客実装の不具合とplatform側の問題をどう分けますか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB007, DB033 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002。hands-on reviewはTokyo FDE Manager CSQ427R97 / ATS 8535419002。DBS01 公式資料, DBS04 公式資料。
何を確かめる問いか — 推論： Engineering/Supportが使える再現可能な調査にする練習。Managerのreview職責はICと分けて扱う。
回答に含める証拠・数字・判断： 共有できるincidentを選ぶ。症状、影響、timeline、request/job ID、version、許可された最小再現を示す。確かめた仮説と除外した原因を説明する。共有できる実際の時間や影響負荷、一時的緩和策を残す。escalation時点、渡した証拠、顧客への連絡ownerも示す。
深掘り1：顧客環境の外で再現できない時、何を渡せますか。
説明すべき点：安全なmetadata、dataの形・設定の差、関連error、再現可能な合成条件を揃える。その再現で証明できない点も明記する。顧客dataをreportへ複製せず、承認された診断accessを調整する。
深掘り2：workaroundで復旧しても原因不明の時、どうincidentを閉じますか。
説明すべき点：緩和と解決を分ける。残るrisk、恒久修正のowner、monitoring、再検証を残す。Managerならreviewとteam学習が次の対応をどう変えるかを示し、全ICが無期限on-callを持つとはしない。
避ける浅い回答： 「Supportへescalateした」だけでなく、理由、渡した証拠、残った責任を説明する。
DB-TQ15: 顧客固有componentを別teamが安全に再利用できる技術contractは何ですか。
位置づけ： 事実から推論した独自の想定質問。公式出題ではない。
根拠と適用範囲： DB008, DB038, DB062, DB063 — Tokyo Sr. FDE CSQ327R52 / ATS 8568173002、Tokyo DSA CSQ427R266 / ATS 8813844002。共通標準はglobal serviceの範囲。DBS01 公式資料, DBS05 公式資料, DBS11 公式資料。
何を確かめる問いか — 推論： 隠れた顧客前提ごとprojectをcopyするのでなく、境界と検証を持つ再利用assetにする練習。
回答に含める証拠・数字・判断： 実際に切り出したcomponent、または設計演習と明記した案を選ぶ。安定した入出力、設定で変える部分、依存、権限、失敗挙動を示す。test、対応version、release責任、移行noteを揃える。測った利用件数、setup時間、不具合があれば使う。再利用実装と製品roadmapへの要望を分ける。
深掘り1：使った顧客が1社だけなら、どこまで抽象化しますか。
説明すべき点：実証した共通要件と未検証の前提を列挙する。interfaceは小さく、顧客固有codeは明示する。汎用optionを足す前に、2件目で何を確かめるか説明する。
深掘り2：別teamの変更が旧deploymentを壊す時、contractは何を持つべきですか。
説明すべき点：version、互換性の期待、regression fixture、変更ownerを説明する。upgrade/rollback経路とbreaking changeの通知を示す。共通repositoryを置くだけではdelivery contractにならない。
避ける浅い回答： 「templateにした」だけでなく、入出力、限界、test、保守ownerを示す。
offlineで作る回答証拠の台帳
本番経路を扱う問と失敗分析の問を1つずつ、応募先に合うならAI FDEの問も選ぶ。匿名化した実projectか小さな合成caseを使う。これは未実行の準備演習であり、指定assessment形式ではない。
| 記録欄 | 書くもの |
|---|---|
| 根拠 | question ID、fact ID、正確な職種/requisition、出典確認日 |
| case | task、data revision、自分の責任、他のowner |
| 判断 | baseline、比較案、制約、選んだ設計 |
| 証拠 | trace、plan、test、実測結果。意味のある箇所だけ単位・期間 |
| 失敗 | 観測したこと、除外した原因、残る不確実さ |
| 深掘り | 結果を作らず2つの追加問へ答える |
| 次の作業 | 足りない証拠、offline test、証明できない限界 |
声に出してcaseを説明し、相手に深掘りをどちらか選んでもらう。境界を説明できなければ不足を記録し、caseを直す。実績、仮想設計、未実行testを区別する。合意、受入、顧客ownershipはdelivery面の準備記事で続ける。
出典
公開日は資料の日付、確認日は内容を参照した日です。コミュニティの観測は公式の確定事項と区別します。
01