テーマ： process
-
技術的な意思決定のためのDACIとRACI: 承認者は1人、貢献者は名指しで
DACIは、意思決定を進行させるドライバー、決定を下すただ1人の承認者、発言権はあるが投票権のない貢献者、結果を知らされる関係者を指名する。RACIは、実行責任者・説明責任者・相談先・報告先という役割をタスクごとに割り当てる。どちらの方式も、議論を始める前に役割を書き出しておけば技術的な意思決定に使える。
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
Einen brauchbaren Fehlerbericht schreiben
Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.
-
事後検証の対応項目を完了まで追跡する：追跡チケット、単独の担当者、経過時間による見直し
Site Reliability Workbook は、正式な追跡手順がないと事後検証の対応項目が忘れられがちだと警告しています。各項目に追跡チケット、担当者一人、種類、優先度を与え、未完了項目を経過時間順に定期確認し、期限を過ぎた項目を飛ばす行ではなく判断すべき事項として扱います。
-
Agile principles as concrete working agreements
The twelve principles behind the Agile Manifesto become useful when translated into checkable team agreements: delivery cadence, direct communication, sustainable pace, technical excellence and regular reflection.
-
Meeting notes with a separate decisions section reduce re-opened decisions
Hypothesis: teams whose meeting notes list each decision separately (statement, rejected options, owner, date) and copy it into a durable decision log re-open settled questions less often than teams with narrative notes, because a decision that can be found and quoted is less likely to be argued again from scratch.
-
Handling a data subject request as an engineering process: export and delete
Treat a person's request for a copy or deletion of their data as a job: verified intake, one exporter per store in the data map producing a manifest, delivery through an expiring authenticated download, deletion through the pipeline, exemptions listed with reason codes, and a synthetic-subject test on a fixed cadence; which requests must be honoured and when is not addressed.
-
オンボーディング文書：新しいマシンから変更のマージまでの道筋
オンボーディング文書は、人でもエージェントでも、新しく参加した者を、何もインストールされていない状態から変更のマージまで、書かれた内容だけで導く1本の番号付き手順です。各参加者がつまずいた箇所を直し、手順には担当者と鮮度を示す日付を付けます。
-
小規模な運用チームの変更カレンダーとメンテナンス時間帯
ユーザーに影響し得るすべての計画変更を、担当者、時間帯、ロールバックの記載、変更禁止ルールとともに1つの共有カレンダーへ載せます。GoogleのSRE書籍によると、SREは障害のおよそ70%が稼働中のシステムへの変更によるものだとしています。そのためインシデントの最初の問いは「何が変わったか」であり、答えを探す場所がカレンダーです。
-
Ein Design-Dokument (RFC) schreiben, über das Reviewer entscheiden können
Ein Design-Dokument holt die Entscheidung ein, bevor Code entsteht: zuerst das Problem, dann Ziele und Nicht-Ziele, eine Erklärung auf Anwender- und eine auf Referenzebene, verworfene Alternativen mit Begründung, Nachteile und eine ausdrückliche Liste offener Fragen. Die Struktur folgt dem, was PEP 1, die Rust-RFC-Vorlage und die Design-Doc-Praxis bei Google verlangen.
-
小規模プロジェクトの Issue トリアージ：固定ラベルと定期的な確認
トリアージとは、新しい各 Issue が何か、対応可能か、次に誰が動くかを決めることである。種類、状態、領域の3系統の小さなラベル集合と、固定の間隔での短い確認により、トラッカーを実態に合わせる。GitHub の既定ラベル（bug、enhancement、documentation、duplicate、question、wontfix、good first issue、help wanted など）は出発点として使える。
-
Retrospektiven, die Änderungen bewirken statt Listen
Eine Retrospektive rechtfertigt ihre Zeit, wenn sie mit ein oder zwei Änderungen endet, die eine Eigentümerin, einen Termin und ein erkennbares Erfülltsein haben; der Scrum Guide verlangt, dass die wirksamsten Verbesserungen so bald wie möglich angegangen werden, und die Prime Directive setzt den Ton, in dem Leute echte Probleme benennen.
-
Postmortems ohne Schuldzuweisung: Ablauf, Ursachen und Massnahmen festhalten
Ein Postmortem beschreibt, was während eines Vorfalls geschah, wen es wie lange traf, welche Umstände es ermöglichten und welche Massnahmen eine Wiederholung unwahrscheinlicher machen. Schuldfreiheit ist kein Höflichkeitsgebot, sondern die Bedingung dafür, dass Beteiligte Fakten berichten statt sich zu verteidigen.
-
Designing an on-call rotation and its handover
An on-call rotation needs a primary and a backup, a bounded share of each engineer's time, shift lengths and swap rules that people can plan around, a pager budget that triggers corrective work when exceeded, and a written handover at every shift change; the Google SRE book and PagerDuty's public response documentation describe the constraints.
-
RICEとICEのスコア：数字の意味と適用範囲の限界
RICEは到達範囲、影響、確信度を掛け合わせ、労力で割ります。ICEは到達範囲を除き、影響、確信度、実施の容易さを使います。どちらも優先順位の根拠を明示し比較するのに役立ちますが、入力が数字を装った推測である場合や、依存関係と戦略を無視した場合には機能しなくなります。
-
Aufwand als Spanne mit angegebenem Vertrauen schätzen
Eine Schätzung als Spanne abgeben (bester Fall, erwarteter Wert, schlechtester Fall) plus die Zuversicht, dass der wahre Wert darin liegt; die Breite an den Ergebnissen vergleichbarer früherer Arbeit ausrichten statt am Plan, und an festen Punkten nachführen. Eine einzelne Zahl verbirgt genau die Unsicherheit, von der Entscheidungen abhängen.
-
小規模プロジェクトのリリース周期：定期リリース列車と準備が整ってからのリリース
バージョン番号はリリースが何を約束するかを示し、周期の方針はいつリリースするかを示す。Rust は nightly、beta、stable の列車で六週間ごとに安定版を出し、Python は PEP 602 で年一回の機能リリースへ移行した。Django は機能リリースを定期的に、パッチを必要に応じて出す。小規模プロジェクトも、機能は日程または目立った変更の蓄積に合わせ、パッチは修正が取り込まれるたびに出すという形を取り入れられる。
-
設計レビューの進め方：コメント期間、決定者の指名、処置の記録
提案のレビューには、期限のあるコメント期間、決定する個人またはグループの指名、理由付きの処置（受諾、却下、延期）の記録、再開のルールが必要です。RustのRFCプロセスとPythonのPEPプロセスがその形を示し、この手順は1つのチーム向けに調整します。
-
貢献者を失わずに機能要求を断る
文書化したスコープを示し、速やかに届き、代替案を挙げてスレッドを閉じる断り方は、沈黙より親切で、要求者を貢献者としてつなぎ止める。Open Source Guides は、書いておくと断りやすくなり、返答はたいてい一、二文で足りると述べている。
-
作業項目ごとにテストへ変換できる受け入れ基準を書く
各作業項目の受け入れ基準を、開始状態、操作、観測可能な結果を含む具体例として書きます。Gherkin の Given/When/Then または同等の構造を使い、境界条件を明記します。作成者以外が実行も確認もできないものは、基準とはいえません。
機械可読： JSON