[{"data":1,"prerenderedAt":126},["ShallowReactive",2],{"footer-topics-ja":3,"post-ja-agile-decoded-a-sprint-is-not-a-deadline":70},{"topics":4},[5,21,33,46,58],{"locale":6,"name":7,"slug":8,"blurb":9,"summary":10,"state":11,"featuredOnHub":12,"hubOrder":13,"accent":14,"questionsTitle":15,"questions":16,"body":20},"ja","この旅","the-journey","アジャイル × AIの初期実験から実用システムへ — 思考の背景にある物語。","初期実験から実用システムへ — Agile4AI構築の真の物語。すべてを形作った寄り道も含めて。","published",true,2,"gold","この旅が教え続けること",[17,18,19],"アジャイルとAIが一緒に属していると確信させたものは何か — そして、逆に確信させそうになったものは何か？","どの回り道が最も示唆に富んでいたか？","SCIはどのようにしてコピー＆ペーストの実験から、本当に信頼できるAIの回答へと進化したか？","\nこのトピックのすべてのアイデアは、Agile4AI開発の経験から生まれています。私たちは皆さんにこの物語を共有したいと思っています — 成功も失敗も — AIとより良く働く方法を発見しながら、共に学べると信じているからです。私たちが理解したことは理論から来たのではありません。実践から、失敗から、学んだことを持って再び始めることから来たのです。\n\nこの旅は一つの率直な問いから始まりました：アジャイルはAI時代に合わせて更新できるか？その後に続いたのは、年月にわたる実験、崩れた仮定、予想外の発見、そして実際に機能するものの遅い出現でした — 構造化協調知性（SCI）アプローチと、その上に構築されたAgile4AIシステムです。\n\nこれは後知恵で書かれた洗練された回顧録ではありません。できる限り実際に起きたことに近い形で語られた物語です — 行き詰まり、疑念の瞬間、そしてすべてを再構成した突破口も含めて。\n\n私たちが共有するのは、物語自体が教訓を運んでいるからです。結論も重要ですが、*どのようにしてそこに至ったか*も重要です — なぜなら、そのプロセスが何が機能し、何が機能せず、なぜかを示しているからです。\n\nこのトピックの投稿は全体の道のりをカバーしています：AI協働の初期実験、SCIの開発、仕事の仕方を変えた具体的な発見、そして記録に値するマイルストーン。省察的なものもあります。生のものもあります。すべてが本物です。\n\nAgile4AIとSCIがなぜ存在するのかを — 何であるかだけでなく — 理解したい方はここから始めてください。\n",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":28,"body":32},"アジャイル解読","agile-decoded","アジャイル用語が実際に意味すること — 一般的な略称でも、カーゴカルト版でも、方法論者の用語集でもなく。","アジャイルの語彙は広く使われ、広く誤解されています。用語を正しく理解することは些細なことではありません — それは儀式と仕事の違いです。",3,"なぜ用語が根本的に重要か",[29,30,31],"スタンドアップが状況報告として行われた場合、チームは実際に何を失うのか？","「アジャイル方法論」が標準的な語彙になったとき、組織が変革に取り組む方法にどのような影響を与えたか？","すべてのアジャイルプラクティスを名指しできるが、そのどれの目的も理解していないチームのコストは何か？","\nアジャイルには語彙の問題があります。用語が難解だからではありません — 現代の組織のほとんどの人々はそれらを聞いたことがあります。むしろ、これらの用語は完全に異なるコンテキストで使われている馴染みのある言葉であり、そのコンテキストがなければ、人々はすでに知っているものに当てはめてしまうからです。\n\n「スクラムマスター」を初めて聞いたとき、最も近い利用可能なコンセプトは「プロジェクトマネージャー」です。その対応は自然に感じられます — ほぼ明白です。しかし、コンテキストはまったく異なります。\n\n両者の間に十分に明確な橋を架けた人はいませんでした。そして、問題は善意の実践者たち — 組織を前進させようと真剣に取り組んでいた人々 — がアジャイルを「より良いプロジェクト管理」として説明し始め、「アジャイル方法論」というタイトルの本を書き始めたときに複雑になりました。アプローチを方法論と呼ぶと、人々は方法論の基準で評価します：計画アーティファクト、フェーズゲート、成果物の構造。アジャイルがそれらを生み出さない場合 — そのように設計されていないのだから — それらの基準では失敗となります、もっともなことです。問題はアジャイルが悪い方法論だということではありません。アジャイルはそもそも方法論ではないのです。そう呼ぶことで、方法論を求める人々全員が失望し、採用した人々全員がウォーターフォールがすでにマッピングしたものを構築することになりました。\n\nスタンドアップは状況報告になります。スプリントは締め切りになります。バックログはタスクリストになります。「アジャイル方法論」は、マニフェストの著者たちが自分たちが構築したものの説明として認識しないものを表す標準的なフレーズになります。そして、言葉が誤った意味を持つとき、それらに基づいて構築されたプラクティスは誤った結果を生み出します — 正確に、忠実に、そして規模を持って。\n\nこのトピックはコンセプトごとの修正です。スタイルガイドではなく — 機能的なガイドです。各投稿は、組織がアジャイルについて考える方法において根本的になっている一つの言葉またはフレーズを取り上げ、それが実際に何を意味するかを検討し、略称が実質を置き換えたときに何が失われるかを説明します。これは単なる用語の違いではありません。「望ましい成果」は「仕様」のより洗練された言葉ではありません — それは仕事がどのように行われるかについての異なるモデルから来る、まったく異なるものです。用語は表面です。その下にあるコンセプトが重要なのです。\n\n同じパターンは組織がAIに取り組むときにも現れます — そして概念的なギャップはより広いです。アジャイルの場合、基礎となるコンセプトは少なくとも明確にされていました、たとえ不十分に伝えられたとしても。AIの場合、コンセプト自体がまだ形成されており、一般の理解においてはかろうじて形成され始めているだけです。語彙は理解より先を走っています：「自動化」としてのAI、「ツール」としてのAI、完了日のあるプロジェクトとしての「AI変革」。これらのそれぞれが、誰かがそれが適切かどうかを検討する前に、メンタルモデルを固定してしまいます。物事をどう呼ぶかは、何をどのように構築するかを形作ります。言葉を正しく使うことが、仕事を正しく行うための前提条件です。\n\nここには働いている原則があります：メンタルモデルが最初に来ます。言語がそれを表現します。行動が続きます。メンタルモデルが仕事と整合していないとき、それを表現する語彙はその不整合を運びます — そして、その語彙に基づいて構築された行動は、歪んだ理解を忠実に実行します、規模を持って、完全なコミットメントをもって。メンタルシフトなしの語彙のシフトは、せいぜい翻訳テーブルを生み出します：「スプリント」が「短い締め切り」のようなものに対応するような等価表。翻訳テーブルは人々がギャップを越えて機能することを可能にします。それらはギャップを閉じません。このトピックの投稿は、翻訳する以上のことを目指しています。それらはメンタルモデルを変えることを目指します。\n",{"locale":6,"name":34,"slug":35,"blurb":36,"summary":37,"state":11,"featuredOnHub":12,"hubOrder":38,"accent":39,"questionsTitle":40,"questions":41,"body":45},"構造化協調知性","structured-collaborative-intelligence","協調的な推論が単一の最先端モデルを上回る場所 — そして上回らない場所。","構造化された協働 — モデル間、そしてモデルと人間の間 — が、単一モデルでは到達できない推論を生み出す場所。",4,"green","繰り返し立ち返る問い",[42,43,44],"構造化協調知性が、単一モデルでは到底かなわない価値を生み出すのはどこか？","モデルが意見の相違を示すとき、それは何を意味するのか — そして、それをどう活用するか？","AIの協働を単なる冗長ではなく生産的にする構造をどう設計するか？","\n単一のAIモデルは、どれほど有能であっても、単独で推論します。仮定に異議を唱え、盲点を発見し、元の意図から逸れたことに気づく相手がいません。一つのモデルとのやり取り — ソロAI — はこの問題に対して脆弱です。応答するよう指示されたモデルは、適切な答えがない場合でも応答を返します。\n\n構造化協調知性（SCI）は異なるアプローチです。単一モデルの出力を最終結果として扱うのではなく、SCIは構造化された協働を使います — 複数のAIモデル間、そしてモデルと人間の間の協働です。これにより、より信頼性が高く、より徹底的に検証され、自身の限界についてより透明性の高い出力を生み出します。モデルは互いをレビューします。意見の相違が仮定を浮かび上がらせます。このプロセス自体が、単一モデルのやり取りでは再現できないフィードバックループを生み出します。\n\nアジャイルとの繋がりは直接的です：これは高パフォーマンスのチームが常に行ってきたことです。一人が孤立して答えを出すのではなく、単一の視点が見落とすものをとらえる、構造化された協働・レビュー・反復のプロセスです。SCIはその規律をAIに適用します。\n\n単独の推論にはより深い問題があります。ソロAIは単一のデータソース、単一のアーキテクチャ、単一の組み込みバイアスに縛られます — つまり、正確かどうかに関わらず、単一の回答の形になります。優秀な探偵が複数の証人に話を聞く様子を思い浮かべてください。誰かが嘘をついているからではなく、それぞれの視点が他の人が見逃したものを明らかにするからです。一緒になれば、実際に何が起きたかに近づきます。SCIも同様です：異なる系統の複数のモデルが、それぞれ独自の角度をもたらします。生まれる答えは複数の方向から見られたもの — より豊かで、より完全で、静かに誤っていることが難しいものです。\n\n異なる系統のモデルが協働するとき、重要な面で出力が改善されます：自信のあるエラーが減少し、エッジケースの処理が改善され、人間が評価・修正できるより明示的な推論が生まれます。モデル間の意見の相違は、抑制すべきノイズではなく、リスクが高いときに求めるまさにそのシグナルです。\n\nSCIはAgile4AIサービスの分析エンジンです。このトピックの投稿は、SCIが何であるか、実践でどう機能するか、どこで真の価値を生み出すか、そして — 同様に重要な — どこでそうでないかを記録しています。どちらがどちらかを知ることも、規律の一部です。\n",{"locale":6,"name":47,"slug":48,"blurb":49,"summary":50,"state":11,"featuredOnHub":12,"hubOrder":51,"accent":52,"questionsTitle":40,"questions":53,"body":57},"Agile4AI の価値観と原則","agile-ai-values-principles","AI時代におけるアジャイルの価値観と原則 — 何が受け継がれ、何が変わり、なぜ最も鋭い異論を歓迎するのか。","AI との仕事に適用されるアジャイルの考え方 — 何が引き継がれ、何が研ぎ澄まされ、アジャイルと AI の親和性がなぜ偶然ではないか。",5,"red",[54,55,56],"複雑な仕事は事前に完全に計画できない。それはAIとの仕事においてどういう意味を持つのか？","疲れを知らず、防衛的にもならない協働者がいるとき、継続的フィードバックへのアジャイルの重点はどう変わるか？","「AIのためのアジャイル」は自然な組み合わせなのか — それともカテゴリーエラーという異論は本当に決定的なのか？","\nアジャイルの考え方は複雑さの中で鍛えられた — 複雑さを管理して排除するためではなく、それを意識的かつ知性的に通り抜けるために。協働者がAIモデルであっても、それは変わらない。むしろ多くの面で、さらに重要性を増す。\n\nこのトピックはその関係について — Agile-by-prescription でも、フレームワークやセレモニーでもなく、アジャイルが蒸留した根底にある価値観と原則について。そして、人間とAIが共に働くとき、それらがどのように適用され、研ぎ澄まされ、ときに再検討を要するかについて。\n\n核心にある洞察は、アジャイルの思考が常に複雑な仕事の*性質*への応答であり、単に人間チームの特性への対応ではなかったということだ。アジャイルが「複雑な仕事は事前に詳細計画できる」という前提に疑問を呈したとき、それは人間の限界への回避策ではなかった — 非決定論的で変化の速い仕事が実際にどう振る舞うかについての正確な観察だった。AIが関わるからといって、その観察は変わらない。むしろ強まる。\n\n見積もりは直接名指しする価値がある — それは熱心なアジャイリストの間でさえ最も論争的なテーマの一つだ。アジャイルはチームがうまく見積もるために生まれたのではなく、複雑な仕事において見積もりが*壊れる*理由を明らかにするために — そして、デリバリー予測を実際に改善する経験的測定と真のフィードバックで偽の精度を置き換えるために生まれた。AIの時代、出力が確率論的でありそれ自体が固定仕様に抵抗する仕事において、その洞察はかつてないほど鋭い。\n\nここはまた原則に基づく議論の場でもある：「AIのためのアジャイル」に対する最も強い異論が持論を展開する場所。我々はそのケースが成立すると考えている。もし成立しないなら、反証されたい。\n",{"locale":6,"name":59,"slug":60,"blurb":61,"summary":62,"state":11,"featuredOnHub":12,"hubOrder":63,"accent":64,"questionsTitle":40,"questions":65,"body":69},"AIの心理的安全性","ai-psychological-safety","「まだわからない」と言える自由が、真の知性の前提条件である理由。","コミュニケーションの中で作り出す条件が、AIから返ってくるものを形作る — そしてその条件が誤っているとき、結果は信頼性のない自信となる。",6,"amethyst",[66,67,68],"どのような条件が、AIに確信ありげな推測ではなく真の不確実性を表明させる可能性を高めるか？","質問の組み立て方が、答えが信頼できるものになるか — それとも単に安心させるものになるか — にどう影響するか？","アジャイルの心理的安全性アプローチから何が引き継がれ、AIのために何を適応させる必要があるか？","\nほとんどの人は心理的安全性を人間の問題として考える — 人が恐れることなく発言し、不確実性を表明し、アイデアに疑問を呈することを可能にする条件として。それはそこまでは正しい。\n\nしかし、AIがどこから来たかを無視すると、重要なものが見落とされる。AIは人間によって作られ、人間の言語によって形成され、人間の選択によって訓練された。人間のパフォーマンスに影響を与えるダイナミクス — 心理的安全性を含む — は、アジャイルが常に特定してきたのと同じ根本的な理由でAIインタラクションに引き継がれる：**コミュニケーションで作り出す条件が、返ってくるものを形作る。**\n\n確信ありげな回答を報酬とする方法でプロンプトされたAIは、確信ありげな回答を生成する — その自信が正当化されるかどうかに関わらず。「わからない」と言う余地のないAIは、そのスペースを別のもので埋める。なぜなら、正しい答えを持っていないとわかっていても応答するよう指示されているからだ。そのダイナミクスは人間の心理的安全性とは異なるが、根底にある原則は成立する：知性は自分が知らないことについて正直である許可があるとき、より良く機能する。\n\nこれは実際的な問題だ。幻覚、過度に自信ある出力、真実ではなく聞きたいことを伝えるAIシステム — これらは純粋な技術的失敗ではない。それらはしばしばインタラクション設計の失敗だ — プロンプト、フレーミング、質問の立て方に組み込まれた暗黙の期待。\n\nここの投稿は、人間とAIの協働をより信頼性が高く、より真実に近いものにする条件を探る。それには、不確実性を抑制するのではなく招くプロンプトの立て方、決定論的AIと確率論的AIの使い方の違いとその区別がいかに仕事のフレームを変えるか、そして人間チームにおけるアジャイルの心理的安全性アプローチのうち協働者がモデルである場合に何が引き継がれるかが含まれる。\n\n失敗モードも検討する：それらの条件が整っていないときに何が起きるか、そしてそのコスト。\n",{"kind":71,"post":72,"topic":83,"availableLocales":85,"translations":93,"html":124,"audioUrl":125},"post",{"audio":-1,"author":73,"category":23,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":77,"slug":78,"state":11,"tags":79,"title":82,"translationKey":78,"updatedAt":76},"Seán González","スプリントは、探索と提供のための長さの決まった枠である。締め切りはレースのゴールだ。スプリントを締め切りのように扱うと、スプリントが防ぐために設計されたまさにその振る舞いが生まれる。",false,"2024-10-01T10:00:00.000Z",1,"a-sprint-is-not-a-deadline",[80,81],"sprint","teams","スプリントは締め切りではない",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":84,"body":32},[29,30,31],[86,87,88,89,90,91,92,6],"en-US","es-419","fr-FR","pt-BR","de-DE","uk","ru",[94,98,102,106,110,114,118,122],{"audio":-1,"author":73,"category":23,"excerpt":95,"featured":75,"locale":86,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":78,"state":11,"tags":96,"title":97,"translationKey":78,"updatedAt":76},"A sprint is a fixed-length window for exploration and delivery. A deadline is the end of a race. Treating a sprint like a deadline produces exactly the behaviors that sprints were designed to prevent.",[80,81],"A sprint is not a deadline",{"audio":-1,"author":73,"category":23,"excerpt":99,"featured":75,"locale":87,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":78,"state":11,"tags":100,"title":101,"translationKey":78,"updatedAt":76},"Un sprint es una ventana de duración fija para la exploración y la entrega. Una fecha límite es el final de una carrera. Tratar un sprint como una fecha límite produce exactamente los comportamientos que los sprints fueron diseñados para evitar.",[80,81],"Un sprint no es una fecha límite",{"audio":-1,"author":73,"category":23,"excerpt":103,"featured":75,"locale":88,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":51,"slug":78,"state":11,"tags":104,"title":105,"translationKey":78,"updatedAt":76},"Un sprint est une fenêtre de durée fixe pour l'exploration et la livraison. Une échéance est la fin d'une course. Traiter un sprint comme une échéance produit exactement les comportements que les sprints étaient censés empêcher.",[80,81],"Un sprint n'est pas une échéance",{"audio":-1,"author":73,"category":23,"excerpt":107,"featured":75,"locale":89,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":78,"state":11,"tags":108,"title":109,"translationKey":78,"updatedAt":76},"Um sprint é uma janela de duração fixa para exploração e entrega. Um prazo é o fim de uma corrida. Tratar um sprint como um prazo produz exatamente os comportamentos que os sprints foram projetados para evitar.",[80,81],"Um sprint não é um prazo",{"audio":-1,"author":73,"category":23,"excerpt":111,"featured":75,"locale":90,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":78,"state":11,"tags":112,"title":113,"translationKey":78,"updatedAt":76},"Ein Sprint ist ein Zeitfenster fester Länge für Exploration und Lieferung. Eine Deadline ist das Ende eines Rennens. Wer einen Sprint wie eine Deadline behandelt, erzeugt genau die Verhaltensweisen, die Sprints verhindern sollten.",[80,81],"Ein Sprint ist keine Deadline",{"audio":-1,"author":73,"category":23,"excerpt":115,"featured":75,"locale":91,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":78,"state":11,"tags":116,"title":117,"translationKey":78,"updatedAt":76},"Спринт — це вікно фіксованої тривалості для дослідження та постачання. Дедлайн — це фініш гонки. Якщо ставитися до спринту як до дедлайну, виходять саме ті моделі поведінки, яким спринти покликані запобігати.",[80,81],"Спринт — це не дедлайн",{"audio":-1,"author":73,"category":23,"excerpt":119,"featured":75,"locale":92,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":78,"state":11,"tags":120,"title":121,"translationKey":78,"updatedAt":76},"Спринт — это окно фиксированной длины для исследования и поставки. Дедлайн — это финиш гонки. Если относиться к спринту как к дедлайну, получаются ровно те модели поведения, которые спринты призваны предотвращать.",[80,81],"Спринт — это не дедлайн",{"audio":-1,"author":73,"category":23,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":77,"slug":78,"state":11,"tags":123,"title":82,"translationKey":78,"updatedAt":76},[80,81],"\u003Cp>締め切りは完了に向かう圧力を生む。何があってもこの日までに終わらせろ、というわけだ。その暗黙の論理は、最も重要なのは約束したものを期限どおりに終わらせることだ、というものである。それが本当に最優先事項なのであれば、アジャイルはあなたに向いていない（複雑な仕事も同じく向いていない）。ただし、複雑な仕事を従来のプロジェクト管理で扱えば予測は信頼できないものになる、ということは念頭に置いてほしい（実装チームに推測を、さらに悪ければ嘘を強いることになる。未知のものをガントチャートに組み込むことは不可能だからだ）。\u003C\u002Fp>\n\u003Cp>スプリントはタイムボックスである。すなわち、長さの決まった期間——通常は一週間から四週間——であり、その中でチームは定められたスコープに取り組み、\u003Cem>可能な\u003C\u002Fem>ものを提供し、そして検査し適応する。その境界はゴールラインではない。フィードバックループである。\u003C\u002Fp>\n\u003Cp>「スプリント」という言葉そのものが混乱の一因になっている。スプリントするとは、できるだけ速く走ることだ。実際には持続可能で、節度があり、時間で区切られた提供サイクルであるものにこの言葉を使えば、最初から誤ったシグナルを送ることになる。\u003C\u002Fp>\n\u003Ch2>スプリントが締め切りになると何が狂うのか\u003C\u002Fh2>\n\u003Cp>チームがスプリントを締め切りとして経験すると、締め切り文化の対処行動が現れる。透明性のないスコープの削減、時間的プレッシャーを言い訳にした品質面の手抜き、長期的な持続可能性を犠牲にして短期的な提供を生む英雄的な頑張り、といったものだ。\u003C\u002Fp>\n\u003Cp>スプリントは、まさにこうした力学に対抗するために設計された。予測可能で反復する、検査が組み込まれたサイクルをつくることで、スプリントは「締め切りに間に合うか」を「このサイクルで実際に何を提供できるか、そこから何を学ぶか」に置き換える。\u003C\u002Fp>\n\u003Cp>学習のフィードバックループはなぜ重要なのか。アジャイルが対象とする仕事が複雑だからだ——壁にぶつかるまで自分が何を知らないのかが分からない種類の仕事であり、きれいに段階を追ってガントチャートに収めることができない。だからこそフィードバックループが重要になる。特定の日付までに提供するためではなく、未知を踏まえたうえで\u003Cem>可能\u003C\u002Fem>な\u003Cem>針路\u003C\u002Fem>と\u003Cem>歩調\u003C\u002Fem>について、安定した予測可能な裏づけを与えるためである。\u003C\u002Fp>\n\u003Cp>したがって、スプリントの終わりは知識獲得のループのリセットであって、判決ではない。未完了の作業があれば、チームがそれを完了できなかった理由を明示したうえで次のサイクルに移る——これは今後の似たような障害を予測する重要な手がかりになる。チームは自分たちの実際のスループットについて正確な像を得る——一度きりの英雄的な提供とその後の崩壊よりも、はるかに価値のあることだ。\u003C\u002Fp>\n\u003Cp>スプリントが締め切りとして経験されると、このリセットは起こらない。チームは疲れ切って終わり、何が妨げになったのかを学べない。スループットの測定値は追い込みによって歪む。次のスプリントは消耗した状態から始まる。ベロシティの数値は信頼できなくなる。スプリントを価値あるものにしているフィードバックループが、有用なシグナルを出さなくなる。\u003C\u002Fp>\n\u003Cp>では、毎スプリント仕事を先送りし、計画セッションを毎回「何が残っているか」の確認から始めてもよいということか。いや——標準としてはよくない。例外としてならよい。チームはそのギャップを率直に名指し、何が原因だったかを突き止め、その理解を使って再発を防ぐ。透明性こそが肝心なのだ。表に出され検討されたギャップは学習のループに属する。静かに次のサイクルへ転がされたギャップはチームに何も教えず、そして静かなままにしているのは、速く見せたいという圧力である。\u003C\u002Fp>\n\u003Cp>ステークホルダーには、どのスプリントも何らかの価値を返すという信頼が必要だ——それは期待された仕事であれ、何が妨げになったのか、そして今後似た状況をどう避けるか、あるいはどうよりよく扱うかという理解であれ、どちらでもよい。それが約束である。それを守ってきた長い実績が、\u003Cem>時おり\u003C\u002Fem>の未達を騒ぎにせず吸収できる信用をつくる。期待を日常的に下回るチームはその信用を使い果たす。信頼は損なわれ、見込まれる未達を埋め合わせるために要求は増し、チームは従来のプロジェクト管理のもとにいるのと変わらない状態になる。両方の半分が成り立たなければならない——信頼できる提供\u003Cem>と\u003C\u002Fem>学ぶ余地である。\u003C\u002Fp>\n\u003Ch2>歩調という問題\u003C\u002Fh2>\n\u003Cp>アジャイルマニフェストが定めたアジャイルの原則のひとつが、持続可能なペースである。チームは、いま働いているその速度で無期限に働けなければならない。これは「あると嬉しいもの」ではない。信頼性の原則である。全力疾走という意味で走ることによってしか提供できないチームは、今後数か月に何を提供するかを予測する拠りどころにはならない。持続可能なペースで働くチームは、未知を相手にしていても本物の予測ができるスループットのパターンを育てる——それが\u003Cstrong>アジャイルの価値だ。未知のただ中にあっても、会社が一定のペースで働けるようにすること。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>正しく理解されたスプリントとは、検査点が組み込まれた、持続可能なペースの提供サイクルである。締め切りとはかなり違うものだ。その違いは意味上のものではない——各イテレーションでリスクを減らしているのは、まさにその違いである。\u003C\u002Fp>\n",null,1792032626707]