分野を横断するテーマ

同じ問いが別の分野でも繰り返し現れます。これらのタグは八つの分野を横に貫きます。

計画と意思決定

課題を定義し、優先順位をつけ、やらないことを選ぶ

16 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · セキュリティ · 実践としての AI · 技術・品質・チーム

001アイデアを、解ける課題に変える技術を選ぶ前に、誰が困っているのか、その人が今どうしているのか、そして解決したとどう判断するのかを書き出す。002何かを証明する、最小のプロトタイププロトタイプは危険な問いを一つ確かめるためにあり、製品を見せるためではない。だから、不格好で、手作業で、不完全でかまわない。003開発者が実際に読む仕様書の書き方よい仕様書は画面案ではなく、振る舞いと受け入れ条件を書く。分量はページ単位であって、数十ページ単位ではない。004作らないものを選ぶ「ノー」と言える力こそが、出荷されたプロダクトと永遠に開発中のプロダクトを分ける。005どれくらいかかるか：幻想のない見積もり良い見積もりは、知識が増えるにつれて更新される、仮定が見える幅のある数値だ。一度だけ言われる単一の数値ではない。006作る、買う、接続する自分たちを差別化するものだけを作れ。それ以外のすべては、買うか、接続するか、諦める。007三日間のユーザーリサーチその仕事をしている人との三十分の会話が五本あれば、千件のアンケート回答より多くを明かす。009技術的負債：いつ負い、いつ返すか技術的負債は正当な資金調達ツールだ——意図的に負い、記録し、返済について話す日付がある限り。010最初のバージョン：何が入るべきか最初のバージョンは一つのことを端から端まで行い、信頼できる方法でそれを行う必要がある。011皆が叫んでいるときの優先順位付け優先順位付けは順序付きリストではなく、全員が事前に知る意思決定ルールだ——そうでなければ、最も大声で話す人が決める。012仕様から始められるタスクへ良いタスクは実行してチェックできる結果で終わり、一〜二日かかる——一週間でも一時間でもなく。021ネイティブ、クロスプラットフォーム、モバイルウェブサイト選択はデバイス自体から何が必要かとチームサイズで決まる——今年トレンドの技術ではない。061一時間での脅威モデル何を持っているか、誰がそれを欲しがるか、どこで境界を越えるかをスケッチする——そうすれば、直感の代わりに本物の優先リストが得られる。075モデルの選び方——そしてなぜ最初の決定ではないかタスクが解けるかどうかをテストするために最も強力なモデルから始め、品質が壊れるまで安いものに降りる。097二年後に後悔しない技術を選ぶチーム、成熟度、コミュニティで選ぶ——退屈で慣れ親しんだものはほぼ常に新しくてエキサイティングなものに勝る。100プロジェクトを成功させるものを本当に決めるもの技術でもチームサイズでもない——目標の明確さ、短いフィードバックサイクル、決定する責任を持つ一人。

計測

本当に良くなったのかを知る

12 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · インフラ・クラウド・DevOps · 実践としての AI · 技術・品質・チーム

001アイデアを、解ける課題に変える技術を選ぶ前に、誰が困っているのか、その人が今どうしているのか、そして解決したとどう判断するのかを書き出す。002何かを証明する、最小のプロトタイププロトタイプは危険な問いを一つ確かめるためにあり、製品を見せるためではない。だから、不格好で、手作業で、不完全でかまわない。008嘘をつかない成功指標ユーザーが受け取った価値に結びついた一つの指標を選び、その隣に何か別のものを壊していないことを保証する一つを置く。025モバイルのパフォーマンス：メモリ、バッテリー、速さの感覚アプリでは感覚は起動時間とスクロールのスムーズさで決まり、どちらも画像とメインスレッドで動く作業によって壊れる。029アプリのクラッシュとエラー監視自動クラッシュレポートがなければ、ストアのレビューから問題を知る——つまり遅すぎる。052監視と観測可能性：顧客より前に何かが壊れたことを知る三種類のシグナル——指標、ログ、トレース——と一つの答えるべき質問：今何が起きていて、なぜか。054クラウドコスト：お金が消える場所請求書のほとんどは三箇所から来る：誰も必要としないのに実行しているリソース、ポリシーなしに成長するストレージ、リージョン間のトラフィック。079評価：システムが改善したことをどう知るか固定の評価セットなしに、すべての変更は信念だ——そして一つのエリアでの改善は別のところでのリグレッションを隠す。081分類と抽出：最も多くを返すタスクチャットを構築する前に、問題が実際にチケットの分類や文書からのフィールドの抽出かどうかを確認する——即時の価値を返す二つのシンプルなタスク。082幻覚：なぜ起きるか、実際に何が助けるか答えのない質問をされたモデルはもっともらしい答えを生成する——修正は間違えないよう求めることではなく、ソースとノーと言う方法を与えることだ。088実験：変更が何かを改善したことをどう知るか同じトラフィックで同時に二つのバージョンを比較する——すべての「前後比較」は世界も測定し、あなただけではない。100プロジェクトを成功させるものを本当に決めるもの技術でもチームサイズでもない——目標の明確さ、短いフィードバックサイクル、決定する責任を持つ一人。

ユーザー

システムを使う人の側で何が起きているか

11 本

次の分野にも登場: プロダクトの基礎 · ウェブとフロントエンド · モバイルアプリ · セキュリティ · 実践としての AI

007三日間のユーザーリサーチその仕事をしている人との三十分の会話が五本あれば、千件のアンケート回答より多くを明かす。014ブラウザのパフォーマンス：実際にサイトを遅くするものほとんどの遅いサイトで犯人はコードではなく重さだ——大きな画像、フォント、サードパーティスクリプト。015アクセシビリティ：飛ばせない最小限アクセシビリティのほとんどは正しいHTMLを書くことから来て、失敗のほとんどは標準要素をそれらしく見えるものに置き換えることから来る。016苦痛のないレスポンシブデザイン小さな画面から始め、コンテンツにどこで壊れるかを決めさせ、デバイスリストのためにデザインするな。017モダンサイトのテクニカルSEOキーワードの前に、検索エンジンがページに到達し、読み、何であるかを理解できることを確認する。019フォーム：最もユーザーが崩れる部分良いフォームは少なく聞き、適切なタイミングで確認し、エラーが起きた場所でそれを説明し、入力したものを消去しない。020ヘブライ語とRTL：壊れるものと修正方法ほとんどのRTLバグは、beginとendの代わりにleftとrightを使うことと、一行に混在するテキストの衝突から来る。023ユーザーを失わないプッシュ通知正当な通知とは、ユーザーが見逃したことを後悔するものだ——それ以外はすべて許可をオフにすることにつながり、それはほぼ不可逆だ。028モバイルのUX：大きな画面と何が違うかモバイルではユーザーは立っていて、急いでいて、片手で持っていて、時に日光の下にいる——そしてそれがすべての決定を変える。063パスワード、二要素認証、セッション専用の遅いアルゴリズムでパスワードを保存し、二要素認証を有効にし、すべてのデバイスからのログアウトを可能にする。084常に正しいとは限らないシステムのインターフェースを設計する良いインターフェースは変化する確実性を示し、簡単な修正を可能にし、推測を事実として提示しない。

アーキテクチャ

構成要素をどう分け、どう対話させるか

16 本

次の分野にも登場: ウェブとフロントエンド · モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · 実践としての AI · 技術・品質・チーム

013静的サイト、サーバーレンダリング、ブラウザアプリの選択コンテンツが固定であるほど、アーキテクチャはシンプルであるべきだ——追加した動的さの各レイヤーは、その後毎日支払いが発生する。018ウェブアプリでの状態管理状態と呼ばれるもののほとんどは、間違った場所に格納されたサーバーデータだ——それらを分離すれば、複雑さの半分が消える。021ネイティブ、クロスプラットフォーム、モバイルウェブサイト選択はデバイス自体から何が必要かとチームサイズで決まる——今年トレンドの技術ではない。022オフライン作業：エレベーターで壊れないアプリネットワークがないという仮定でアプリを設計すると、あるときも速く感じるアプリを無料で手に入れる。034データベース：選んで後悔しないほとんどの場合、リレーショナルデータベースが正しい答えであり、他の選択はすべて一文で述べられる理由が必要だ。036キューとバックグラウンドジョブ一秒以上かかりユーザーへの応答に必要でないものはすべて、リクエストではなくキューに属する。037キャッシュ：古いデータを提供せずに高速化するキャッシュを追加する前に、古いデータがどれくらいの時間許容されるかを決める——それが本当に重要な唯一の質問だ。039一つのサービスか多数か：いつ分割するかよく整理された一つのシステムから始める。本当の痛みがあるときだけ分割する——チームが互いをブロックしているか、異なるスケールが必要なコンポーネント。040年数耐えるデータモデルを設計する良いモデルはビジネスの現実を表し、最初に構築するよう求められた画面ではない。042ファイルとオブジェクトストレージファイルはデータベースにもサーバーのディスクにも属さない——署名済みアドレスを持つオブジェクトストレージに属する。055スケーリング：水平、垂直、本当に必要なものスケーリングする前に、ボトルネックがどこにあるかを測定する——ほとんどのシステムでは、サーバーの数ではなくデータベースか一つのクエリにある。076あなたの知識をモデルに接続する：大げさな言葉なしの検索モデルはあなたの文書を知らない——各質問に関連するパッセージを見つけてプロンプトに添付する必要がある。077エージェント：システムに単独で行動させるときエージェントは自分でどのアクションを実行するかを決める——すべての報酬とリスクは与えた権限にある。087プロセス自動化：モデルが追加する場所と余分な場所プロセスが固定で明確なら、コードを書け；モデルは非構造化テキストに対する判断が必要な場所でちょうど価値がある。089モデルベースシステムのアーキテクチャモデルは普通のシステムの中の一つのコンポーネントだ——そしてその周りのシステムが仕事とリスクのほとんどだ。096戻れるコード：名前、構造コードは書かれるよりずっと多く読まれる——だから正確な名前と予測可能な構造はどんな巧みさよりも価値がある。

データ

情報の構造・保存・整合性

13 本

次の分野にも登場: ウェブとフロントエンド · モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · セキュリティ · 実践としての AI

018ウェブアプリでの状態管理状態と呼ばれるもののほとんどは、間違った場所に格納されたサーバーデータだ——それらを分離すれば、複雑さの半分が消える。022オフライン作業：エレベーターで壊れないアプリネットワークがないという仮定でアプリを設計すると、あるときも速く感じるアプリを無料で手に入れる。026デバイス上のローカルストレージと機密データデバイスが失われるか侵害されると仮定する：ローカルに保存されるものは最小限で、暗号化され、リモートで取り消せる必要がある。034データベース：選んで後悔しないほとんどの場合、リレーショナルデータベースが正しい答えであり、他の選択はすべて一文で述べられる理由が必要だ。035ダウンタイムなしのスキーマ移行後方互換性のあるステップでスキーマを変更する：追加し、埋め、切り替え、最後にのみ——削除する。040年数耐えるデータモデルを設計する良いモデルはビジネスの現実を表し、最初に構築するよう求められた画面ではない。043検索：データベースでは不十分なときランキング、タイポ、複数フィルターを持つ全文検索は独自の世界であり、すべてのシステムがそれを必要とするわけではない。046お金を扱う：支払いと課金カードの詳細は絶対に保存するな、クライアントから来た金額は絶対に信頼するな、常に不変のイベントログを保持する。053バックアップと復旧：テストされていないものは存在しないバックアップはポリシーではない；ポリシーはどれだけのデータを失えるか、どれくらいダウンできるか——そしてそれを満たしたことの証明だ。069設計によるプライバシー：より少なく収集する情報を守る最も安い方法はそれを収集しないことだ——そして収集されるすべてのフィールドには目的、オーナー、削除日が必要だ。076あなたの知識をモデルに接続する：大げさな言葉なしの検索モデルはあなたの文書を知らない——各質問に関連するパッセージを見つけてプロンプトに添付する必要がある。081分類と抽出：最も多くを返すタスクチャットを構築する前に、問題が実際にチケットの分類や文書からのフィールドの抽出かどうかを確認する——即時の価値を返す二つのシンプルなタスク。083データ：どこから来てないときはどうするかほとんどのプロジェクトでデータは存在するが、散乱していてラベルなし、クリーンでない——そしてそれが時間のほとんどを食う段階だ。

パフォーマンス

速度、負荷、そしてユーザーの体感

11 本

次の分野にも登場: ウェブとフロントエンド · モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · 実践としての AI

013静的サイト、サーバーレンダリング、ブラウザアプリの選択コンテンツが固定であるほど、アーキテクチャはシンプルであるべきだ——追加した動的さの各レイヤーは、その後毎日支払いが発生する。014ブラウザのパフォーマンス：実際にサイトを遅くするものほとんどの遅いサイトで犯人はコードではなく重さだ——大きな画像、フォント、サードパーティスクリプト。017モダンサイトのテクニカルSEOキーワードの前に、検索エンジンがページに到達し、読み、何であるかを理解できることを確認する。025モバイルのパフォーマンス：メモリ、バッテリー、速さの感覚アプリでは感覚は起動時間とスクロールのスムーズさで決まり、どちらも画像とメインスレッドで動く作業によって壊れる。031デバイスからのファイル、メディア、アップロードカメラからの写真は必要以上に何十倍も重い——ネットワークに触れる前にデバイスで処理する。037キャッシュ：古いデータを提供せずに高速化するキャッシュを追加する前に、古いデータがどれくらいの時間許容されるかを決める——それが本当に重要な唯一の質問だ。043検索：データベースでは不十分なときランキング、タイポ、複数フィルターを持つ全文検索は独自の世界であり、すべてのシステムがそれを必要とするわけではない。045負荷：レート制限と自己保護健全なシステムは早く明確に拒否し、支えられない負荷の下でゆっくり崩壊するのではない。055スケーリング：水平、垂直、本当に必要なものスケーリングする前に、ボトルネックがどこにあるかを測定する——ほとんどのシステムでは、サーバーの数ではなくデータベースか一つのクエリにある。080モデルベースシステムのコストとレイテンシコストのほとんどは入ってくるテキストから来て、レイテンシのほとんどは出ていくテキストから来る——だから二つの修正は異なる。086小さい、ローカル、エッジモデルボリュームが大きく、レイテンシが重要で、データが出られないとき——あなたの側の小さなモデルはクラウドの大きなモデルに勝る。

信頼性

何かが壊れたときに何が起きるか

13 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · 実践としての AI

010最初のバージョン：何が入るべきか最初のバージョンは一つのことを端から端まで行い、信頼できる方法でそれを行う必要がある。022オフライン作業：エレベーターで壊れないアプリネットワークがないという仮定でアプリを設計すると、あるときも速く感じるアプリを無料で手に入れる。036キューとバックグラウンドジョブ一秒以上かかりユーザーへの応答に必要でないものはすべて、リクエストではなくキューに属する。041外部サービスへの呼び出しの信頼性すべての発信呼び出しはいずれか失敗する——唯一の質問は、そのとき何が起きるかを計画していたかどうかだ。044送信メール、メッセージ、Webhook送信メッセージは公開インターフェースだ：キュー、リトライ、誰に何を送ったかの記録が必要だ。045負荷：レート制限と自己保護健全なシステムは早く明確に拒否し、支えられない負荷の下でゆっくり崩壊するのではない。051デプロイ戦略：ブルーグリーン、カナリア、段階的良いデプロイは出ていく速さではなく、素早くロールバックする能力で測られる。053バックアップと復旧：テストされていないものは存在しないバックアップはポリシーではない；ポリシーはどれだけのデータを失えるか、どれくらいダウンできるか——そしてそれを満たしたことの証明だ。056ネットワークと証明書：ドメイン、DNS、HTTPSほとんどの「サイトが読み込めない」インシデントはドメイン、期限切れの証明書、またはルーティングであり、コードではない。058犯人なしのインシデントレビューすべてのインシデントの後に、システムに焦点を当て人に焦点を当てない書かれたレビューの一時間は価値がある——さもなければ同じインシデントが戻ってくる。059高可用性と災害復旧一時間のダウンタイムがいくらかかるかを決め、それからどれだけの冗長性を買うかを決める。082幻覚：なぜ起きるか、実際に何が助けるか答えのない質問をされたモデルはもっともらしい答えを生成する——修正は間違えないよう求めることではなく、ソースとノーと言う方法を与えることだ。089モデルベースシステムのアーキテクチャモデルは普通のシステムの中の一つのコンポーネントだ——そしてその周りのシステムが仕事とリスクのほとんどだ。

セキュリティ

攻撃者より先に、攻撃者のように考える

19 本

次の分野にも登場: モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · セキュリティ · 実践としての AI

026デバイス上のローカルストレージと機密データデバイスが失われるか侵害されると仮定する：ローカルに保存されるものは最小限で、暗号化され、リモートで取り消せる必要がある。038認証と認可：あなたが誰で何が許可されているかアイデンティティと認可は二つの別々の質問であり、ほとんどの違反はインターフェースでチェックされ、サーバーでチェックされないことから来る。046お金を扱う：支払いと課金カードの詳細は絶対に保存するな、クライアントから来た金額は絶対に信頼するな、常に不変のイベントログを保持する。056ネットワークと証明書：ドメイン、DNS、HTTPSほとんどの「サイトが読み込めない」インシデントはドメイン、期限切れの証明書、またはルーティングであり、コードではない。057シークレットとキーを管理するコードリポジトリ内のシークレットは漏洩したシークレットだ——リポジトリがプライベートでも、後で削除しても。061一時間での脅威モデル何を持っているか、誰がそれを欲しがるか、どこで境界を越えるかをスケッチする——そうすれば、直感の代わりに本物の優先リストが得られる。062すべての監査で繰り返す十の失敗ほとんんどの発見は洗練されていない：サーバーでチェックされない権限、クエリに入る入力、古いライブラリ。063パスワード、二要素認証、セッション専用の遅いアルゴリズムでパスワードを保存し、二要素認証を有効にし、すべてのデバイスからのログアウトを可能にする。064インジェクション：指示をデータから分離するユーザーからの文字列がコマンドに組み立てられるすべての場所が穴だ——解決策はフィルタリングではなくパラメータだ。065公開インターフェースのセキュリティ確保インターネットに開いたインターフェースは最初の日から自動的にスキャンされる——すべてのルートが、どんな順序でも、どんな入力でも呼ばれると仮定する。066コードのサプライチェーンあなたのコードは本番で実行されるものの少数派だ——リスクのほとんどは持ち込んだパッケージとそれらを構築したツールにある。067暗号化：いつ、どこで、どう間違えないか既知のライブラリを最新のデフォルトで使い、何も発明するな——ほぼすべての暗号化の失敗は使用の失敗だ。068クラウドの権限：最も重要なルールは最小限ほとんどの深刻なクラウドインシデントは、必要以上の権限を持ち有効期限のないアイデンティティから始まる。070ブラウザのセキュリティ：ヘッダーで設定される保護クライアントサイド攻撃の大部分は、いくつかのレスポンスヘッダーといくつかの正しいcookie設定でブロックされる。071チームのセキュリティ：ほとんどの侵害が始まる場所安全なシステムでさえ、従業員のデバイス、フィッシングメール、二要素認証のないアカウントを通じて侵害される。072セキュリティテスト：何を注文し、いつ自動スキャンは継続的な衛生管理；侵入テストは焦点を絞ったイベント——両方に書かれた目標が必要だ。073モデルベースシステムのセキュリティモデルは二つの新しいリスクを追加する：指示として解釈される外部コンテンツ、チェックなしに機密な場所に届く出力。074インシデントが起きる前に準備するインシデント中は誰が決定するかを決める時間がない——穏やかな朝に書かれた紙が一時間と一週間の差だ。077エージェント：システムに単独で行動させるときエージェントは自分でどのアクションを実行するかを決める——すべての報酬とリスクは与えた権限にある。

プライバシー

収集を減らし、集めたものを守る

5 本

次の分野にも登場: モバイルアプリ · インフラ・クラウド・DevOps · セキュリティ · 実践としての AI

026デバイス上のローカルストレージと機密データデバイスが失われるか侵害されると仮定する：ローカルに保存されるものは最小限で、暗号化され、リモートで取り消せる必要がある。060ログ：正しく保存して素早く見つける良いログは構造化されていて、リクエストIDで識別され、定義された期間保持され、そこにある理由がない個人情報がない。067暗号化：いつ、どこで、どう間違えないか既知のライブラリを最新のデフォルトで使い、何も発明するな——ほぼすべての暗号化の失敗は使用の失敗だ。069設計によるプライバシー：より少なく収集する情報を守る最も安い方法はそれを収集しないことだ——そして収集されるすべてのフィールドには目的、オーナー、削除日が必要だ。085モデル使用のバイアス、公平性、説明責任モデルは見たものを反映する——だから人々に影響する決定にはセグメントの確認、ループ内の人間、文書化が必要だ。

コスト

いくらかかり、なぜ増えるのか

7 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · 実践としての AI

006作る、買う、接続する自分たちを差別化するものだけを作れ。それ以外のすべては、買うか、接続するか、諦める。031デバイスからのファイル、メディア、アップロードカメラからの写真は必要以上に何十倍も重い——ネットワークに触れる前にデバイスで処理する。042ファイルとオブジェクトストレージファイルはデータベースにもサーバーのディスクにも属さない——署名済みアドレスを持つオブジェクトストレージに属する。054クラウドコスト：お金が消える場所請求書のほとんどは三箇所から来る：誰も必要としないのに実行しているリソース、ポリシーなしに成長するストレージ、リージョン間のトラフィック。075モデルの選び方——そしてなぜ最初の決定ではないかタスクが解けるかどうかをテストするために最も強力なモデルから始め、品質が壊れるまで安いものに降りる。080モデルベースシステムのコストとレイテンシコストのほとんどは入ってくるテキストから来て、レイテンシのほとんどは出ていくテキストから来る——だから二つの修正は異なる。086小さい、ローカル、エッジモデルボリュームが大きく、レイテンシが重要で、データが出られないとき——あなたの側の小さなモデルはクラウドの大きなモデルに勝る。

テスト

本番に届く前に不具合を捕まえる

6 本

次の分野にも登場: インフラ・クラウド・DevOps · セキュリティ · 実践としての AI · 技術・品質・チーム

050自動化されたビルドとデプロイのパイプラインすべてのマージは同じシーケンスをトリガーすべきだ：ビルド、テスト、セキュリティチェック、デプロイ——途中に一つの手動ステップもなく。062すべての監査で繰り返す十の失敗ほとんんどの発見は洗練されていない：サーバーでチェックされない権限、クエリに入る入力、古いライブラリ。072セキュリティテスト：何を注文し、いつ自動スキャンは継続的な衛生管理；侵入テストは焦点を絞ったイベント——両方に書かれた目標が必要だ。079評価：システムが改善したことをどう知るか固定の評価セットなしに、すべての変更は信念だ——そして一つのエリアでの改善は別のところでのリグレッションを隠す。091テスト：いくつ、どれ、価値がないものロジックを実行するテストの大多数、いくつかの統合テスト、ごく少数のエンドツーエンドテストに投資する。098官僚制なしの品質：機能するものを壊さない方法リグレッションは三つのことで防がれる：自動テスト、小さくて頻繁なリリース、素早くロールバックできる能力。

デプロイ

コードをどう本番に出し、どう戻すか

8 本

次の分野にも登場: モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · 技術・品質・チーム

030段階的なロールアウトと機能スイッチ小さな割合にリリースし、指標を観察し、拡大する——そしてバージョンをリリースせずに機能をオフにする能力を保持する。035ダウンタイムなしのスキーマ移行後方互換性のあるステップでスキーマを変更する：追加し、埋め、切り替え、最後にのみ——削除する。047環境：開発、テスト、本番同じ定義から構築された三つの環境、設定とデータのみが異なる——他の違いはすべて、見つかるのを待つバグだ。048コンテナ：何を与え、いつ不要かコンテナはアプリが実行に必要なすべてのものとともにパッケージし、どこでも同じように動作するようにする。049コードとしてのインフラバージョン管理のファイルから環境を再現できなければ、インフラではなくクリックの履歴を持っているだけだ。050自動化されたビルドとデプロイのパイプラインすべてのマージは同じシーケンスをトリガーすべきだ：ビルド、テスト、セキュリティチェック、デプロイ——途中に一つの手動ステップもなく。051デプロイ戦略：ブルーグリーン、カナリア、段階的良いデプロイは出ていく速さではなく、素早くロールバックする能力で測られる。098官僚制なしの品質：機能するものを壊さない方法リグレッションは三つのことで防がれる：自動テスト、小さくて頻繁なリリース、素早くロールバックできる能力。

監視

いま何が起きていて、なぜかを知る

4 本

次の分野にも登場: モバイルアプリ · インフラ・クラウド・DevOps · 実践としての AI

029アプリのクラッシュとエラー監視自動クラッシュレポートがなければ、ストアのレビューから問題を知る——つまり遅すぎる。052監視と観測可能性：顧客より前に何かが壊れたことを知る三種類のシグナル——指標、ログ、トレース——と一つの答えるべき質問：今何が起きていて、なぜか。060ログ：正しく保存して素早く見つける良いログは構造化されていて、リクエストIDで識別され、定義された期間保持され、そこにある理由がない個人情報がない。090時間をかけてAIシステムを運用するモデルは置き換えられ、文書は変わり、ユーザーは異なる質問の仕方を学ぶ——六ヶ月間触れられていないシステムはほぼ常に悪くなる。

ドキュメント

コードから推測できないこと

6 本

次の分野にも登場: プロダクトの基礎 · バックエンド・API・データ · 実践としての AI · 技術・品質・チーム

003開発者が実際に読む仕様書の書き方よい仕様書は画面案ではなく、振る舞いと受け入れ条件を書く。分量はページ単位であって、数十ページ単位ではない。032共存できるインターフェースを設計する良いインターフェースは予測可能で、一貫していて、退屈だ——その中のサプライズはすべて、使う人への繰り返しの質問とバグになる。078プロンプト：呪文ではなく仕様を書く良いプロンプトはロール、入力、決定ルール、出力構造を定義する——そしてバージョン管理とテストを持つコードとして扱われる。092遅らせるのではなく改善するコードレビュー良いレビューは小さく、速く、正確性と保守性に集中する——自動ツールが強制すべきスタイルの好みではない。094人々が実際に読むドキュメントコードから推測できないものを文書化する：決定、限界、始め方——他のすべては古くなり誤解を招く。095一ヶ月ではなく一週間で新しい開発者をオンボーディングする指標は本番での最初の変更までどれくらいかかるかだ——遅れのほとんどはコードを理解することではなく、アクセスとローカルセットアップだ。

プロセスとチーム

互いを止めずに協働する方法

22 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · セキュリティ · 実践としての AI · 技術・品質・チーム

005どれくらいかかるか：幻想のない見積もり良い見積もりは、知識が増えるにつれて更新される、仮定が見える幅のある数値だ。一度だけ言われる単一の数値ではない。011皆が叫んでいるときの優先順位付け優先順位付けは順序付きリストではなく、全員が事前に知る意思決定ルールだ——そうでなければ、最も大声で話す人が決める。012仕様から始められるタスクへ良いタスクは実行してチェックできる結果で終わり、一〜二日かかる——一週間でも一時間でもなく。024ストア審査を最初のトライで通過するほとんどの拒否はコードではなくメタデータと権限から来る——そして一時間の準備で防げる。039一つのサービスか多数か：いつ分割するかよく整理された一つのシステムから始める。本当の痛みがあるときだけ分割する——チームが互いをブロックしているか、異なるスケールが必要なコンポーネント。047環境：開発、テスト、本番同じ定義から構築された三つの環境、設定とデータのみが異なる——他の違いはすべて、見つかるのを待つバグだ。049コードとしてのインフラバージョン管理のファイルから環境を再現できなければ、インフラではなくクリックの履歴を持っているだけだ。050自動化されたビルドとデプロイのパイプラインすべてのマージは同じシーケンスをトリガーすべきだ：ビルド、テスト、セキュリティチェック、デプロイ——途中に一つの手動ステップもなく。057シークレットとキーを管理するコードリポジトリ内のシークレットは漏洩したシークレットだ——リポジトリがプライベートでも、後で削除しても。058犯人なしのインシデントレビューすべてのインシデントの後に、システムに焦点を当て人に焦点を当てない書かれたレビューの一時間は価値がある——さもなければ同じインシデントが戻ってくる。071チームのセキュリティ：ほとんどの侵害が始まる場所安全なシステムでさえ、従業員のデバイス、フィッシングメール、二要素認証のないアカウントを通じて侵害される。074インシデントが起きる前に準備するインシデント中は誰が決定するかを決める時間がない——穏やかな朝に書かれた紙が一時間と一週間の差だ。078プロンプト：呪文ではなく仕様を書く良いプロンプトはロール、入力、決定ルール、出力構造を定義する——そしてバージョン管理とテストを持つコードとして扱われる。085モデル使用のバイアス、公平性、説明責任モデルは見たものを反映する——だから人々に影響する決定にはセグメントの確認、ループ内の人間、文書化が必要だ。087プロセス自動化：モデルが追加する場所と余分な場所プロセスが固定で明確なら、コードを書け；モデルは非構造化テキストに対する判断が必要な場所でちょうど価値がある。092遅らせるのではなく改善するコードレビュー良いレビューは小さく、速く、正確性と保守性に集中する——自動ツールが強制すべきスタイルの好みではない。093バージョンで作業する：ブランチ、マージ、履歴短いブランチと頻繁なマージはほとんどのバージョンの痛みを防ぐ——そして読める履歴はインシデントを調査する日に努力の価値がある。094人々が実際に読むドキュメントコードから推測できないものを文書化する：決定、限界、始め方——他のすべては古くなり誤解を招く。095一ヶ月ではなく一週間で新しい開発者をオンボーディングする指標は本番での最初の変更までどれくらいかかるかだ——遅れのほとんどはコードを理解することではなく、アクセスとローカルセットアップだ。098官僚制なしの品質：機能するものを壊さない方法リグレッションは三つのことで防がれる：自動テスト、小さくて頻繁なリリース、素早くロールバックできる能力。099ベンダーと開発請負業者と作業する成果物、所有権、アクセスを事前に書面で定義する——最後の大きな引き渡しではなく継続的な配信を要求する。100プロジェクトを成功させるものを本当に決めるもの技術でもチームサイズでもない——目標の明確さ、短いフィードバックサイクル、決定する責任を持つ一人。

ベンダーと外部依存

他者に依存するとき何が起きるか

6 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · バックエンド・API・データ · セキュリティ · 技術・品質・チーム

006作る、買う、接続する自分たちを差別化するものだけを作れ。それ以外のすべては、買うか、接続するか、諦める。024ストア審査を最初のトライで通過するほとんどの拒否はコードではなくメタデータと権限から来る——そして一時間の準備で防げる。041外部サービスへの呼び出しの信頼性すべての発信呼び出しはいずれか失敗する——唯一の質問は、そのとき何が起きるかを計画していたかどうかだ。066コードのサプライチェーンあなたのコードは本番で実行されるものの少数派だ——リスクのほとんどは持ち込んだパッケージとそれらを構築したツールにある。097二年後に後悔しない技術を選ぶチーム、成熟度、コミュニティで選ぶ——退屈で慣れ親しんだものはほぼ常に新しくてエキサイティングなものに勝る。099ベンダーと開発請負業者と作業する成果物、所有権、アクセスを事前に書面で定義する——最後の大きな引き渡しではなく継続的な配信を要求する。

互換性と変更

既存の利用者を壊さずに変える

5 本

次の分野にも登場: モバイルアプリ · バックエンド・API・データ · インフラ・クラウド・DevOps · 技術・品質・チーム

027アプリのバージョンと後方互換性ユーザーは何ヶ月も古いバージョンを持っている——サーバーはそれらをサポートし、いつ止めるかを知る必要がある。033インターフェースのバージョニング：壊さずに変更する方法インターフェースを公開した——コミットした。破壊的変更は新しいバージョン、重複期間、事前通知が必要だ。035ダウンタイムなしのスキーマ移行後方互換性のあるステップでスキーマを変更する：追加し、埋め、切り替え、最後にのみ——削除する。051デプロイ戦略：ブルーグリーン、カナリア、段階的良いデプロイは出ていく速さではなく、素早くロールバックする能力で測られる。093バージョンで作業する：ブランチ、マージ、履歴短いブランチと頻繁なマージはほとんどのバージョンの痛みを防ぐ——そして読める履歴はインシデントを調査する日に努力の価値がある。

長期の保守

プロジェクト終了後にシステムに何が起きるか

5 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · セキュリティ · 実践としての AI · 技術・品質・チーム

009技術的負債：いつ負い、いつ返すか技術的負債は正当な資金調達ツールだ——意図的に負い、記録し、返済について話す日付がある限り。027アプリのバージョンと後方互換性ユーザーは何ヶ月も古いバージョンを持っている——サーバーはそれらをサポートし、いつ止めるかを知る必要がある。066コードのサプライチェーンあなたのコードは本番で実行されるものの少数派だ——リスクのほとんどは持ち込んだパッケージとそれらを構築したツールにある。090時間をかけてAIシステムを運用するモデルは置き換えられ、文書は変わり、ユーザーは異なる質問の仕方を学ぶ——六ヶ月間触れられていないシステムはほぼ常に悪くなる。096戻れるコード：名前、構造コードは書かれるよりずっと多く読まれる——だから正確な名前と予測可能な構造はどんな巧みさよりも価値がある。

実験

段階的に出し、バージョンを比べる

3 本

次の分野にも登場: プロダクトの基礎 · モバイルアプリ · 実践としての AI

002何かを証明する、最小のプロトタイププロトタイプは危険な問いを一つ確かめるためにあり、製品を見せるためではない。だから、不格好で、手作業で、不完全でかまわない。030段階的なロールアウトと機能スイッチ小さな割合にリリースし、指標を観察し、拡大する——そしてバージョンをリリースせずに機能をオフにする能力を保持する。088実験：変更が何かを改善したことをどう知るか同じトラフィックで同時に二つのバージョンを比較する——すべての「前後比較」は世界も測定し、あなただけではない。

インターフェース

利用者に対して差し出す契約

4 本

次の分野にも登場: バックエンド・API・データ · セキュリティ

032共存できるインターフェースを設計する良いインターフェースは予測可能で、一貫していて、退屈だ——その中のサプライズはすべて、使う人への繰り返しの質問とバグになる。033インターフェースのバージョニング：壊さずに変更する方法インターフェースを公開した——コミットした。破壊的変更は新しいバージョン、重複期間、事前通知が必要だ。044送信メール、メッセージ、Webhook送信メッセージは公開インターフェースだ：キュー、リトライ、誰に何を送ったかの記録が必要だ。065公開インターフェースのセキュリティ確保インターネットに開いたインターフェースは最初の日から自動的にスキャンされる——すべてのルートが、どんな順序でも、どんな入力でも呼ばれると仮定する。