2026-05-20

クラウドネイティブ会議ご参加ありがとうございました

クラウドネイティブ会議にご参加いただいた皆さま本当にありがとうございました！
今回私は実行委員として、プロモーション活動とセッションを担当しました。

イベントを走り切った今、記憶が新しいうちにと、運営の裏側や当日の様子などの雑記です。

プロポーザル約180件と、現地1,000人の期待に応えるぞ！

今回、2月の1ヶ月間を通して行われたプロポーザル募集では、約180件の応募が集まりました。
地方開催のカンファレンスとしては多い方だとおもいますし、参加申し込みに関しても、2月末までの先行申込み時点で300人を突破し、早い段階でこのイベントに対する界隈の熱量の高さを感じていました。

今回、実行委員では「行こうぜ1000！」というスローガンを掲げていたのですが、4月下旬にはオンラインを含めた参加者数が1,000人を達成し、開催数日前には「現地参加申込1,000人」というスローガンの真の目標に到達しました。
参加申込者数の増加は純粋に嬉しかった反面、これだけ期待されているカンファレンスなんだと実感し、その期待にしっかり応えたいという気持ちが強くなりました。

準備期間のリアル：じんわりと続く大変さと本業との両立

私自身、運営の裏側で劇的なトラブルがあったとかはないのですが、会社員生活のサイクルとうまく合わないことが多く「じんわりとした大変さ」が続く期間でした。

特に以下の時期は稼働的に申し訳なさが強いです。

2月のプロポーザル募集＆先行申込期
所属企業の人事評価期間と重なってしまった時期です。
プロポーザル募集に加えて先行申込も走る重要なプロモーション期間だったのですが、ラインマネジメント業務に時間とエネルギーを注ぐ必要があったため、コミュニティ活動へ十分に貢献できず、もどかしい思いをしました。
とはいえ、CloudNative Daysでも毎回絶妙な時期に被るのでそろそろ学習したいところです。
4月の集客の正念場
4月は先行申込みやセッション公開によるピークが落ち着き申し込みの伸びが鈍化してしまう、いわゆる「凪期間」でした。
数字が伸び悩む時期だからこそ、ここから1,000人に向けて再び集客をプッシュしていく一番大事なタイミングだったのですが、ちょっと大きめのミッションがありかなり慌ただしい日々でした。

ひとつは、クラウドネイティブ会議のco-chairの一人でもある @jacopen さんも登壇した「Agentic AI × Platform Engineering で変わる開発現場」での登壇ですが、所属企業の広報チェックなどの兼ね合いで思ったより時間がなかったという、完全に締切駆動すぎたのが敗因です。

それ以上に大変だったのは、安易に「運営ですか？興味あります。」「リーダーですか？誰もやらなさそうですね、いいですよやりますよ。」なんてことを口走って運営の中心になっちゃった社内イベントです。
株式会社タミヤ様や所属企業の社長が関わっていたりと、それなりに大きいイベントだったので結構時間が取られました。
童心にかえりすぎて楽しかったけどね！

今回の運営で印象に残っている点

そんなバタバタな裏側とは別に、今回の運営で特に印象に残っているのが以下の2点です。

1つ目は、自動化ツールの変遷とOpenClawの活躍です。
オートメーション担当の方が効率化UPにn8nの本格活用を進めていたのですが、後から導入したOpenClawが非常に細かく痒い所に手が届く働きをしてくれました。
結果的にOpenClawへ任せる領域が増え、とくにプロモーションチームの作業効率が爆上がりしたのは本当に助かりましたが、こうも簡単に技術の変化が起きるのか！って超関心です。
通勤の電車内でOpenClawと戯れるのが当たり前な日々w

ちなみに、クラウドネイティブ会議でのOpenClaw活用については、@jacopen さんが発表しています。

2つ目は、「アーカイブ配信へのQ&A機能対応」です。今回、CloudNative Daysが利用している配信システムに更新がありQ&A機能がついたのですが、そこへの「この機能をアーカイブ視聴時にも対応させたい」という提案を採用、実装していただきました。
登壇者と参加者へのより良い体験のための仕組みづくりに関われたのは嬉しかったポイントです。
ちなみに、この案もOpenClawと様々な議論を経て生み出された提案なんですよね。

当日の様子：満席となるセッションと白熱するAsk the Speaker

そして当日。
セッション部屋の着席誘導をしていると、満席となるセッションがいくつもあり、現地参加1,000人という数字の大きさを肌で実感しました。

また、セッション後に行われるAsk the Speakerのコーナーでは、登壇者と参加者のコミュニケーションが予想以上に活発で、次のセッションのAsk枠まで会話が続くほど白熱する場面も見られました。

総評：疲れたけど、もう一度やりたい

準備期間はじんわりと大変でしたが、「もう一回やりましょう」と言われたら、即座に手を挙げると思います。

また、今回はPlatform Engineering KaigiやSRE Kaigiの方々と連携して活動したことで、それぞれのカルチャーや思考を知ることができ、今後の実行委員としての活動にもいい影響があるなと感じています。

そして、あらためてPlatform EngineeringやSREについての学びも広がったので、様々な面で大きな収穫があったと思います。

最後

1. アーカイブ視聴とQ&A機能の活用
当日見られなかったセッションや、別の予定で参加できなかった方は、ぜひアーカイブをご視聴ください。
そして、今回導入したQ&A機能を使って、アーカイブを見ながら生じた疑問をぜひ登壇者に投げてみてください。
通常イベント当日以外では登壇者とコミュニケーションを取ることが難しくなっていきますが、この仕組みで少しでも軽減できればと考えています。
（※回答はあくまで登壇者の方のご厚意によるものですので、都合により回答いただけない場合もありますがご了承ください）

2. 次回CloudNative Daysへの期待
クロージングでも発表されましたが、Platform Engineering KaigiやSRE Kaigi、そしてCloudNative Daysも次の日程が決まっています！
是非、11月の有明で一緒に楽しみ、そして新たな学びを得ましょう！

次回のカンファレンス情報をお知らせします！

📅 2026/9/26: Platform Engineering Kaigi 2026
📅 2026/11/18-19: CloudNative Days Winter 2026
📅 2027/2/20: SRE Kaigi 2027

今から予定を押さえておいてください！
詳細は各カンファレンスの公式SNSで随時お知らせします。#cloudnativekaigi
— CloudNative Days (@cloudnativedays) 2026年5月16日

3. スタッフに興味がでたよ！
もしこの記事を読んで、実行委員に少しでも興味を持った方がいれば、ぜひお気軽にCloudNative Days公式Xアカウントまでご連絡ください！
っていうか全然私宛でも大丈夫です。

改めまして、ご参加いただいた皆様、登壇者の皆様、そして一緒に走り抜けた実行委員の皆様、本当にありがとうございました！

2025-07-06

人事考課での成長の意識により納得感を〜私が考える持続的成長と個人の価値を測る財務諸表アナロジー〜

最近、いろいろな方とお話させていただく機会が増えたこともあり自分がずっと持っていた考えの解像度があがったのでこのあたりで一度整理などを兼ねて超久々にブログ化します。

キャリアを考えていくなかで、現在地がどういう状態なのかを考えて成長計画を立てていくと思います。
さらに企業に属すると、人事考課制度に巻き込まれるため一定期間での評価を意識する必要が出てきます。
自身の成果や頑張りがどういう評価になるのか、正しく評価されているのかの自己評価と他者評価の乖離や納得感は度々起こる問題で、この成長と評価の納得感をより向上させるための私なりの考えがあります。
といっても結構前職の評価の考え方が影響しているのでベースは受け売りかもしれません。

会社は日々、売上や利益、コストといった「数字」で経営状態を把握しています。決算期になると「貸借対照表」や「損益計算書」といった財務諸表（ほかにもあるだろっていうツッコミはここでは除外です）が次の戦略、計画のインプットの一部となったり、投資家含むステークホルダーの方々から評価をうける成績表となります。

私はこの「財務諸表」を人事考課で例える、当てはめることで、「自身の成長と評価」をもっとクリアに、そして納得感を持って見ていけると考えており、ついでに「会社全体の成長」とリンクさせることができるかなと考えています。

今日は、その基本的な考え方をお伝えしたいと思います。

人事考課を「財務諸表」に例えてみる

まず、今回の考え方に登場させる財務諸表は以下の２つです。

「貸借対照表（たいしゃくたいしょうひょう）」
これは、ある一定時点で「会社がどんな資産を持っていて、どれくらい負債があり、純資産（資本）はいくらか」を示してくれます。
「損益計算書（そんえきけいさんしょ）」
これは、ある一定期間（例えば1年間）で「どれだけ売上があり、どれだけ費用が発生し、結果としてどれだけの損益となったのか」を示す、いわば会社の「活動報告書」です。

私は、この2つの視点を人事考課に当てはめて、それぞれを「能力」と「成績」として捉えることができると考えています。

「能力」は会社の「貸借対照表」に似ている

個人の能力は「今、どんな力を持っているか」で整理し説明できることが評価での納得感と今後成長する上でのベースとなりますが、会社の貸借対照表が同様に「今、何を持っているか」を示しています。
簿記などで説明される順序と違いますが個人の能力における「貸借対照表」を説明します。

純資産の部
会社における純資産とは、会社の財産の源泉がどこにあるかを示し、返済などを要しない自己資本が資本金や資本/利益剰余金などであらわされています。
では、個人における純資産とは。それはやはり本人の価値や保有能力だと思います。個性や強みなども含まれると思ってます。
プログラミング能力やクラウド技術の知識、顧客との会議でとても鼻が利くとかそもそものコミュ力とか。
負債の部
会社における負債とは、将来、未払金や買掛金、借入金といった他人や他社に対して支払わなければならない義務、つまり借金や未払いの代金などがあります。「負債」と表現されていますが必ずしも悪いものではありません。事業成長のなど投資的側面を持つ銀行からの融資による負債といったポジティブな負債もあります。
ということは、たとえば慢性的な勤怠不良やレビューで指摘を常に受けているその理由といった一見ネガティブだけど今後の伸びしろともいえる行動特性や、周囲の協力を得る力なども負債の一部といえると思います。
3.資産の部
会社が持っている財産を一覧にしたもので、現預金、建物や土地の固定資産、売掛金など将来会社にお金をもたらすものや、会社の活動に役立つものが含まれます。
では、個人における資産とはなにか。純資産にあるような個人の価値や保有能力と負債にある他者協力を得て生み出せるアウトプットに直結する力や保有している資格などが資産に当たると思っています。

能力評価に値するものはこの貸借対照表に例えることができ、どういうアウトカムが生み出せる可能性があるのかを示すことができると考えています。

「成績」は会社の「損益計算書」に似ている

会社の損益計算書が「一定期間にどんな活動をして、どれだけ儲かったか」を示すように、個人の成績も「この期間、どんな仕事をして、どれだけ成果を出したか」を示せると思います。

1.売上
損益計算書における売上（収益だっけ？）は、顧客に提供したことで得られる収益です。
これを個人に置き換えるとどうなるのか、やはりこの項目はアウトカム、成果や結果、影響だと考えます。
顧客満足度やプロジェクト目標の達成などがあります。ただし、チームやプロジェクトといった集団での結果もあり、きちんとそのなかでの個人の貢献状況も加味する必要があります。
2.費用
損益計算書における費用は、売上を上げるためにかかった、あるいは事業活動を行う上で発生したコスト全般です。
これを個人に置き換えるとどうなるのか、一番わかりやすいのは自身やチームが起因しての残業時間や作成したドキュメントやコードがレビューで多く指摘を受け、その修正に費やした時間といった非効率性なものや遅刻や欠勤といった事象と周囲の負担、研修に行った時間や費用といった将来投資の事象も含まれると思います。
3.利益
損益計算書における利益は、売上から様々な費用を差し引いた結果として残るお金です。
これを個人に置き換えるとどうなるのか、素直に期間内の純粋な価値？というか成績そのものだと思います。実績評価を用いている場合はもろここが大きく影響してくると思います。

なぜこのアナロジーが生まれたの？

私は評価期間の間で、自身がどんな活動をしどれだけ効率的にそして最終的にどのようなアウトカムを生み出したかを考えています。
目標設定する際は、その評価期間における結果、着地点だけでなく中長期的にどういった成長をしていこうか、そのため当該評価期間でなにをすべきかも考えています。
ある評価期間においてラッキーヒットでいい成果がでたけど次の評価期間イマイチだったなってことは全然ありますし思うような活動できなかったななんてよくあります。
簿記、会計を掠る程度には通っている関係かただのこじらせか、自分の言動などをふりかえるときに勘定科目に置き換えて考えたりしてしまいます。
そして、所属組織の計画や評価と自身の評価を結び付けていくのに何がしっくりくるだろうかと考えた時に財務諸表じゃん？って行きつきました。
大事なこととして、財務諸表に例えているので、それぞれ勘定科目的な考えも持ち当然自己評価期間には決算仕訳みたいなことを考えているのですが、だからと言って例えば売上を出すために資産科目を相手勘定に配置したときに資産が目減りするとは考えてないですが、とはいえ時と場合によって資産、負債、純資産が売上と費用が影響して増減することはあると思ってる程度には雑な部分がまだあります。

で、今どんな気持ち？

この考えによって私は納得感が増しています。

評価がより明確に、納得しやすくなる
定量データを示したり、定性的な自身の成長を説明するにあたり個人の純粋な力と周囲の恩恵を整理しているため説明しやすい
成長と貢献が多角的に見える
完全な期間内業績評価だけしか見ない場合は違う可能性がありますが、能力という財産と短期的な成果それぞれを考えることができるので自分自身の全体像がわかった気がしています。
成長意識が強くなる
負債を成長機会ととらえることもできるので、どういった投資をすることでさらなるアウトカムが得られるのかを具体的な成長目標、計画で考えられますし持続的な成長を意識できてるなって感じてます。

なお、ここまで書いておいて言うのもあれですが、期間内成果におけるインセンティブが主となる制度の場合は全くかみ合わないかもしれませんが、経験したことがないのでわかりませんごめんなさい。

今の所属企業は「実力評価」という評価期間内の単純実績じゃない評価指針があるので、わりとこの考えの中で生きていけるなって思いつつ評価者側なので会社方針に逸脱しない程度に説明、利用してます。

「貸借対照表」と「損益計算書」の具体的なたとえは別途記す予定です。

2018-07-04

QA2AQ AgileなQualityの実践-その４-「俺たちがAQだ！」

QA2AQについての記事4日目。
QA2AQについてはこの記事をご参照ください。

今回は、俺たちがAQだ！といった感じのパレットを抜粋しました。
というより、[Becoming Agile at Quality]のパレットから抜粋しただけになってます。
ホワイトペーパーの訳ではなくを雑訳して引用していますが、私なりの解釈や整理した内容をかいたポエムのようなものととらえてください。

Whole Team

従来、QAチームは開発チームとは別組織として存在していることが多い。
また、開発後半に投入される存在のため、市場投入までの圧力により品質を妥協する場合がある。
従って、QAをアジャイルチームの一員に含めよう。
別組織からチームメンバーとなることで、チーム全体の品質意識が高まる。

QA Product Champion

チームやPOは機能提供を重視しがちになるが、品質が充足されるまでは「リリースできる状態」とは言えない。
チームがシステム品質に集中できるよう支援する役割。
プロジェクトの開始から顧客要件の理解に関与し、チームを支援する。
ビジネスアナリスト、アーキテクト、プロダクトマネージャはQA Product Championともいえる。
専門知識を普及させることで、品質の検討やテスト実施能力の向上を図る。

Agile Quality Specialist

特定のシステム品質に対する技術スキルが高い方を指す。
セキュリティの場合で言えば、セキュリティアーキテクトやセキュリティスペシャリスト。
スペシャリストは、単なる助言だけではなく実践的な直接支援を行うことでチームと協力します。

Spread the Quality Workload

QA以外も品質に関するタスクをこなすことで、作業負荷を分散させる。
プロジェクト全体に品質に関するタスクを含めることで、高品質に向かうための作業負荷を分散させる。

Shadow the Quality Expert

Expertのシャドーイングをすることで、メンター指導効果やチームの成長につながる。
QAの専門知識は高度に専門的である。

Pair with a Quality Advocate

ペア作業はペアプロだけじゃないよ。
QAの仕事はテストだけじゃないよ。
QAとペア作業することで、優れたテストの設計だけじゃなくアーキテクトが品質目標に影響を与えるかどうか検討することもできる。
ただ、ペア作業は片方向の学習だと失敗するかもしれず、双方向の敬意、理解と信頼が大事。

Specialistのシャドーイングができれば、立派なSpecialistになれると思いますが、道は険しそう。
ペア作業を通じて学習していきたいところ。
いや、そもそも自分の身近なSpecialistって誰だろう？

2018-07-03

QA2AQ AgileなQualityの実践-その３-「品質の視える化」

QA2AQについての記事3日目。
QA2AQについてはこの記事をご参照ください。

今回は、品質の視える化に着目したパレットを抜粋しました。
ホワイトペーパーを雑訳して引用していますが、私なりに整理した解釈と考え方の解釈や整理した内容をかいたポエムのようなものととらえてください。

Measureable System Qualities

測定方法と値を決めること、当然測定可能な値であること。
測定が困難、またはコストがかかるものがあるので、必要な正確さと精度を計測するための方法を定義すること。
程度を考えた測定が行えるように上記のことを考えろということでしょうか。

System Quality Dashboard

継続的な測定と監視をすること。
考慮する点は、開発環境とダッシュボードがどれだけ統合されているかです。
ランディングゾーンの調整をした際は、ダッシュボードも更新も忘れずに実施しましょう。
ダッシュボードは必ずしもラジエーターではないが、ラジエーターの一部になることもある。
理由は、オブザーバーが理解できない詳細な情報を含むこともあるため。
継続的な監視をするために開発環境とダッシュボードを統合し、ダッシュボードを新鮮な状態に保てということでしょう。

System Quality Radiator

誰かに聞くことなく、現在集中している品質についてとその状況をわかるようにすること。
品質の条件と状況を一目で伝えることを目的としています。

Quality Checklists

システム全体で共通して一貫しているシステム品質の期待値を含むチェックリスト。
ホワイトペーパーを読む限り、本当に想像通りのチェックリストを作れということっぽいです。

Quality Chart

Monitor Qualities

上記２つは視える化に関係していると思いますが、説明なく消えたのでパレット名だけ抜粋です。

視える化は、結構すんなり入ってきました。
個人的にも、普段業務で使っているDashboardがホワイトペーパーで言及されている通りほんと開発者寄りのため、Radiatorを別途用意するならどういった形がいいのか検討したいところです。

2018-07-02

QA2AQ AgileなQualityの実践-その２-「品質も意識して、立ち向かう」

QA2AQについての記事2日目です。
QA2AQについてはこの記事をご参照ください。

今回は、プロジェクトを進めるにあたり、機能要件だけではなく、どのように品質に対して成果をだしていくべきかに着目したパレットを抜粋しました。
ホワイトペーパーを雑訳して引用していますが、私なりに整理した解釈と考え方の解釈や整理した内容をかいたポエムのようなものととらえてください。

Agile Quality Scenarios

ハイレベルな品質シナリオを定義せよ。
定義する目的としては、重要な考慮事項であれば、ロードマップの一環として取り入れるようなストーリーを作ることにつながり、結果スプリントへ取り込むことができるようになります。
ということは業務フローの品質版？のようなものでしょうか。

Quality Stories

PBIsのストーリーは機能に焦点が当たりがちです。
重要な品質を優先順位づけして対応するため、品質を達成させるためのストーリを作成します。

Fold-Out Qualities

ユーザーストーリーの中に品質に対する基準を設けます。
ただし、必ずしも最初のacceptance criteriaというわけではない。
議論を重ね合意に達することが重要で、Quality Storiesになるものもあります。
つまり、Refinementをしていく中で、達成させるべきacceptance criteriaと分離して別のストーリーで達成させるacceptance criteriaやQuality Storiesにするなどあり得るということだと思います。

Agile Landing Zones

着地点を設定しろってことです。
最低限、ターゲット、傑出？(適切な訳がわからない)の３点設定しましょう。
一番最良な品質(傑出？)は過剰品質とまではいかない範囲でしょうか？ちょっとそのあたりが読み取れませんでした。

Agree on Quality Targets

着地点に対して合意を得る。
重要な品質要件の場合、Quality ScenariosやAgile Landing Zonesへの合意、Recalibrate the Landing Zoneの合意を得る。
機能要件もそうですが、設定したら合意得ると思うのですが、明記したということはそれだけ機能要件以外の部分はおざなりになりがちなのでしょうか。

Qualify the Roadmap

ロードマップにはマイルストーンなどが含まれているが、システムの品質とアーキテクチャは考慮されないことがしばしばあります。
システム品質に関する内容をロードマップに組み入れろ！

Qualify the Backlog

特定のBacklog、ユーザーストーリーの受入条件に重要な品質要件が含まれていると、見落とたり過小評価することがある。
品質ストーリーをバックログへ組み込む。このとき、ユーザーストーリー固有の品質要件であればFold-Out Qualitiesが含まれたBacklogとして、そうでない場合はQuality Scenarios or Quality Storiesを意味する品質固有のBacklogとなる。

"Qualify the Roadmap"と"Agile Quality Scenarios"の関係性や"Quality Stories"？"Qualify the Backlog"？とそれぞれの粒度がさっぱりわからなくて、何度もホワイトペーパーを読み直したのですが、しっかり理解できてはいないと思います。
現状の理解としては、順番の前後はありますが、"Qualify the Roadmap" "Agile Quality Scenarios"の設定、"Quality Stories" "Qualify the Backlog"や"Fold-Out Qualities"といった具体的な内容に踏み込んで"Agree on Quality Targets"と合意しながら進めていきましょう。
ロードマップ～バックログ、ユーザーストーリーのレベルまで詳細化する過程の流れの中でそれぞれ品質に関する重要事項を設定することで、検討すべき品質事項を忘れずに意識させつづけられるということでしょうか。
さらに、"Agile Landing Zones"を設定し、徐々に品質を達成させていくことも忘れずに。

2018-07-01

QA2AQ AgileなQualityの実践「QA2AQに出会う」

品質保証にどう取り組んでいくか考える中で、海外のほうが情報があるのではないかと思い、USのGoogle検索を利用してプラクティスがないかを検索したところ、QA2AQに出会いました。

QA2AQとは？

Joseph W. Yoderさん、Rebecca Wirfs-Brockさん、Ademar Aguiarさんが発表された論文で全Part6まであります。Part3以降は早稲田大学の鷲崎教授の名前もはいっていました。内容は、「Quality Assurance to Agile Quality」ということで従来のQAがよりアジャイルな形になるための22パターン(Part6時点。Part1からPart6に至るまでに多少変化があります)が示されています。

どこで読めるの？

ドキュメントは、RebeccaさんのWebサイト(http://www.wirfs-brock.com/)で閲覧可能です。(Resourcesページにあります)

Index

Part6まであるので、どのPartに何が載っているのかを勝手に纏めました。

Part1「QA2AQについて」QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality, by Joseph Yoder, Rebecca Wirfs-Brock, and Ademar Aquilar

Part2「品質の測定と監視」QA to AQ Part 2: Shifting from Quality Assurance to Agile Quality "Measuring and Monitoring Quality," by Joseph Yoder and Rebecca Wirfs-Brock

Part3「障壁の破壊」QA to AQ Part 3: Shifting from Quality Assurance to Agile Quality "Tearing Down the Walls," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Part4「品質の優先順位付けと見える化」QA to AQ Part 4: Shifting from Quality Assurance to Agile Quality "Prioritizing Qualities and Making them Visible," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Part5「高まる品質意識と専門知識」QA to AQ Part 5: Being Agile At Quality "Growing Quality Awareness and Expertise," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Part6「品質の有効化と注入」QA to AQ Part 6: Being Agile At Quality "Enabling and Infusing Quality," by Joseph Yoder, Rebecca Wirfs-Brock, and Hironori Washizaki

Core Patterns(Fitting Quality Into Your Process)

Patlet Name	JA雑訳	reference	note
Break Down Barriers	障壁の破壊	Part3
Integrate Quality	品質の統合	Part1

Identifying Qualities

Patlet Name	JA雑訳	reference	note
Find Essential Qualities	本質を検索	Part2
Agile Quality Scenarios	アジャイル品質シナリオ	Part1
Quality Stories	クオリティストーリー	Part1
Measureable System Qualities	測定可能なシステム品質	Part2	Part3[Specify Measurable Values or System Qualities]
Fold-out Qualities	折り込み品質	Part1
Agile Landing Zone	アジャイルランディングゾーン	Part2
Recalibrate the Landing Zone	ランディングゾーンの再調整	Part2
Agree on Quality Targets	品質目標に同意	Part2

Making Qualities Visible

Patlet Name	JA雑訳	reference	note
System Quality Dashboard	システム品質ダッシュボード	Part2
System Quality Radiator	システム品質のラジエーター	Part4
Quality Checklists	品質チェックリスト	Part5	Part4から登場
Qualify the Roadmap	ロードマップに品質を組み込む	Part4
Qualify the Backlog	バックログに品質を組み込む	Part4
Quality Chart			Part3で消えた

Becoming Agile at Quality

Patlet Name	JA雑訳	reference	note
Whole Team	チーム全体	Part1
Quality Focused Sprints	品質重視のスプリント	Part1
QA Product Champion		Part5	Part4以降[Product Quality Champion]
Agile Quality Specialist		Part6	Part6[System Quality Specialist]
Monitor Qualities			Part6で消えた
Agile QA Tester			Part6で消えた
Automate As You Go		Part6	Part6から登場
Spread the Quality Workload	品質の作業負荷を拡散させる	Part6
Shadow the Quality Expert	品質熟練者と共に	Part5
Pair with a Quality Advocate		Part3