# 第2章 アメリカで見つけたマインドセット――日本にいるときには気づかなかったこと（後半・part1から続く） ※第2章の前半は `part1-ch2-mindset-in-america.md`。このノートは part2 に収録された後半（VSMによる見える化と「思考回路」を形づくる実践）を扱う。 **中心主張**: リードタイムを可視化して無駄な待ち時間を削るのと同じように、仕事の進め方そのものを支える「思考回路」（計画への向き合い方、断り方、他文化からの学び）を変えることが、結果よりバリューを重視する働き方への転換の土台になる。海外のマインドセットは「無理をしないこと」を前提に設計されており、日本式の「気合いで結果を出す」姿勢とは根本が異なる。個人が無理を重ねてプロジェクトの帳尻を合わせる行為は、実は問題点を先送りにしてチーム全体の疲弊を生むだけで、組織の業務改善には一切つながらない。 **論の展開**: - 前半は開発プロセスの改善事例（バリューストリームマッピングによるリードタイム可視化、DevOps導入でリードタイムが8.5カ月から1週間程度に短縮された例）を示し、「見える化」がボトルネック（上司承認など実処理時間3分に対し3日かかる工程）をあぶり出すことを述べる - そこから「思考回路を形づくる実践」として3つの具体的な習慣提案に移る：①楽に達成できる計画を立てる、②無理をせず断る練習をする、③他文化の視点を学ぶ - 各提案の背景として、日本人が無意識のうちに自分にも他人にも「無理を承知で」の基準を適用してしまう傾向を、ブラジル人との混成チームでの対比を通じて指摘する - 個人が無理をして仕事を抱え込む「願いの連鎖」がチームや組織全体の疲弊につながる構造を描き、「これは無理」と言いやすい空気こそが負荷軽減の具体策になると説く - 最終的に「結果を出す」から「バリューを出す」へという価値観の転換を提示し、計画の変更を「悪」ではなく現実を見てフィードバックを受け入れる「善」と位置づける - 章の締めくくりとして、目標達成の工夫のやり方を管理職ではなく各人が決められる環境こそが、失敗を恐れずパズルを解くようにチャレンジを楽しめる土壌になると結論づける **実践指針**: - 依頼を受けるときは、火急の対応を美徳とせず「マネジメント能力の欠如」の兆候と捉え、早めに計画を立てて相手に依頼する側に回れ - 仕事を「決まっている日程」に無理やり合わせるのではなく、見通しをたてて「計画通り」に進められる量に絞れ - 「無理を承知で」の依頼は安易に引き受けず、断る練習をせよ。自分に厳しいルールを他人に押しつけていないか意識的に点検せよ - 自分自身に課しているルール（納期厳守のDNAなど）を自覚したら、他人だけでなく自分自身に対しても骨の髄まで緩やかにしてよいと許可を出せ - KPIやノルマは「定時で無理なく楽に達成できる」水準に設定し、達成後に改善点やベストプラクティスを振り返る運用にせよ - チームやプロジェクトの計画変更が発生したら、失敗ではなく現実に即したフィードバックとして歓迎し、素早く見直せ - 「これは無理」と感じたら早めに言葉にしてチームでシェアせよ。個人が黙って抱え込むと、負荷はチーム全体に波及して疲弊を生む - 目標に向けた工夫のやり方は管理職が決めるのではなく、各人が自分で決められる環境をつくれ。取り組みの中で得た学びのシェア自体を組織の財産とみなせ **根拠となる研究・事例**: - バリューストリームマッピング（図8）: 現場の人・マネージャ・上席全員で4時間かけて実施した例。「上司承認」はリードタイム3日・実処理時間3分、「スワップ処理（ステージングから本番へ）」はリードタイム15分・実処理時間15分、「デプロイ後処理（スケール設定変更）」もリードタイム15分・実処理時間15分と可視化され、承認プロセスの必要性そのものが議論の俎上に載った → 示唆: ボトルネックは「見える化」しない限り放置される。LT（リードタイム）＝PT（実処理時間）＋WT（待ち時間）という分解式が、どこに無駄な待ち時間があるかを一目瞭然にする - DevOps導入企業の事例: リードタイムが8.5カ月だったのが、バリューストリームマッピングを実施し改善策を導入して数カ月後には1週間程度に短縮。BIツール（企業内データインテリジェンスツール）を使えば数クリックでレポートが自動化できる → 示唆: プロセスの無駄な承認・手作業の洗い出しだけで大幅な短縮が可能であり、大掛かりな技術投資は必須ではない - フィーチャーフラグの活用: 機能を先に実装しておき、スイッチを後からオンにすることで「既に動いているものをリリースするだけ」の状態を作れる。「早く始める」だけで一気に話が進む場面を著者は何度も見てきた → 示唆: リリースそのものの意思決定コストを下げれば、開発全体のリードタイムが短縮できる - ブラジル人と日本人の混成チームのワークショップ（ロッシェル・カップ氏との共同実施）: 「仕事で忙しいときに上司から仕事を頼まれたらどうするか」という質問に対し、ブラジル人は「私は今忙しいので」と快く断ると回答したのに対し、日本人参加者は同じ状況でも無理をして引き受け、残業でカバーすると回答する傾向が顕著だった → 示唆: 「無理を承知で」の美徳は文化的な刷り込みであり、絶対的な生産性の基準ではない - 著者自身の英国留学（40代当時、3カ月間）の経験: 「マーケットリーダー」のようなビジネス英語表現や、はっきり「常識ってなんだっけ？」と意見表明するイギリス人・デンマーク人の率直さに触れ、日本人が気を遣って言えないことを率直に言い合える文化があることを実感した → 示唆: 文化的な視点を変えることで、負荷軽減の具体策（「これは無理」と言いやすい空気）が見えてくる - マイクロソフト社内の方針変更: エンジニアに降りてくる方針は数カ月単位で頻繁に変わる。日本人はこうした変更を「（計画の変更は）悪」と捉えがちだが、著者はこれを状況変化に対応するための「善」だと位置づけ直している → 示唆: 計画に固執せず現実を見てフィードバックを受け入れる姿勢が、チームの生産性とモチベーションを高める - 著者自身の経験: インターナショナルチームでは目標は「あくまで目標」であり、達成できなくてもいちいち理由を問われない一方、日本の職場ではKPI未達が厳しく管理される傾向があった → 示唆: 目標の位置づけ自体が「絶対達成すべきノルマ」か「方向性を示す指針」かで、働く人のプレッシャーの質が大きく変わる **キーワード**: - バリューストリームマッピング（VSM）: ソフトウェアがリリースされる時点からさかのぼり、どんなプロセスにどれだけ時間と人がかかっているかを可視化する手法。LT（リードタイム）＝PT（実処理時間）＋WT（待ち時間）で分解する - フィーチャーフラグ: 機能を先行実装しておき、後からオン・オフを切り替えることでリリースタイミングを制御する仕組み - 「楽に達成できる」計画: 火急の依頼を避け、余裕を持って自分や他人の仕事量を設計する考え方 - Be Lazy: 無理をせず、シンプルかつ最小限の労力で成果を出そうとするマインドセット（本書全体を貫く鍵概念、詳細は他分冊で展開） - 願いの連鎖: 個人が無理をしてプロジェクトの帳尻を合わせる行為が、問題の先送りとなってチームや組織全体の疲弊を生み出す構造 - 「結果を出す」から「バリューを出す」へ: プレッシャーで結果を絞り出す姿勢から、取り組みの中で得た学びのシェア自体を組織の財産とみなす姿勢への転換