「もうやめて！」僕らが疲弊する「アジャイルっぽい何か」の正体
はい、それではブログの「起」の部分、スタートです！（3000文字チャレンジ、いきますよ！）
皆さん、お疲れ様です。海外の片隅で、今日もVisual Studioと睨めっこしながらWPFの画面設計に唸っているITエンジニアです。
さて、突然ですが、皆さんの現場、「アジャイル開発」やってますか？
「もちろん！うちはスクラムでバリバリ回してるよ！」
素晴らしいですね。スプリント計画ミーティングで活発な議論が交わされ、デイリースクラムでチームの進捗がクリアになり、スプリントレビューでは顧客を感動させるデモが……。
……本当ですか？（笑）
僕がこっち（海外）の現場に来て、いくつかのチームを渡り歩いて強烈に感じたこと。それは、**「俺たちは、いつのまにか『アジャイル開発』じゃなくて、『アジャイルっぽい何か』に殺されかけてるんじゃないか？」**っていう、切実な疑問でした。
アジャイルソフトウェア開発宣言。2001年に提唱された、あの素晴らしい理念。「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」。僕も大好きです。この理念のおかげで、僕ら開発者は、あの分厚いウォーターフォール時代の仕様書地獄から解放されたはずでした。
でも、現実はどうでしょう。
僕が体験した、とある「スプリント計画ミーティング」の話をさせてください。
月曜の朝イチ。ただでさえ気が重いのに、いきなり2時間ぶっ通しのミーティングです。僕の専門はC#を使ったデスクトップアプリ（WPF）開発。エンタープライズ向けの、ちょっとレガシーな部分も含む複雑なシステムです。
会議室（今はZoom越しですが）に集められた僕ら開発チーム。そこに、プロダクトオーナー（PO）とスクラムマスター（SM）が登場します。
PO「今スプリントでやるバックログはこれだ。優先順位順に並んでいる。上から順に見積もっていこう」
SM「はい、じゃあ最初のチケット。ID-123、『顧客管理画面の検索ロジックを改善し、パフォーマンスを向上させる』。はい、エンジニアチーム、見積もりをどうぞ！」
開発者A「うーん、これ、既存のロジックがかなり複雑で……。DBのインデックスも絡むし、WPF側での非同期処理も直さないと表示が固まる可能性があるな」
開発者B「そもそも『パフォーマンス向上』って、具体的に何秒を目指すんですか？現状のボトルネックってどこか調査しました？」
PO「いや、いいからいいから。とにかく速くしてほしい、と顧客は言っている。ざっくりでいいよ。プランニングポーカー、出すよ！せーの、ドン！」
僕（内心）：「（うわ、出たよプランニングポーカー……）」
僕が出したのは「8」。開発者Aは「13」。開発者Bは「5」。
SM「お、見積もりが割れたね。なんで13だと思ったの？なんで5なの？」
ここからが地獄です。「なぜ8なのか」「いや、これは13の複雑さがある」「5でいける根拠は」という、**不毛な「ストーリーポイント当て」**が延々と続くわけです。
結局、POの「まあまあ、間とって8でいいんじゃない？次いこう、次！」という鶴の一声で、このチケットは「8ポイント」としてスプリントバックログに積まれました。
……皆さん、おかしいと思いませんか？
この2時間のミーティングで、僕らは**「具体的に何をもって『完了』とするのか（完了の定義）」も、「なぜ今これをやるのか（ビジネス的な価値）」も、「技術的に最適なアプローチは何か」**も、何一つ深く議論できていません。
僕らがやったのは、POが持ってきた「やりたいことリスト」に対して、「なんとなくの工数（という名の、誰も責任を持たない数字）」を貼り付ける作業だけ。
そして、スプリントが始まれば「なんで見積もり通りに終わらないんだ！」「ベロシティ（消化ポイント）が落ちてるぞ！」と詰められる。
デイリースクラムは、「昨日やったこと、今日やること、問題点」を報告するだけの「進捗報告会」と化し、スクラムマスターは「問題点？よし、じゃあミーティングを設定しよう！」と、僕らの貴重なコーディング時間をさらに奪っていきます。
スプリントの終わりには「レトロスペクティブ（振り返り）」という名の、「Keep（良かったこと）」「Problem（悪かったこと）」「Try（次に試すこと）」を書かされた付箋をホワイトボードに貼り付ける儀式。
「Problem」には大抵、「見積もりの精度が低い」「コミュニケーション不足」「仕様変更が多すぎる」が並びます。
「Try」には、「もっと正確に見積もろう」「もっと密にコミュニケーションしよう」という、何の具体的解決にもなっていない精神論が並ぶ。
そして次のスプリントが始まり、また同じことが繰り返される……。
これが、「アジャイル」ですか？
僕がやっていたのは、アジャイルの皮を被った、ただのマイクロマネジメントであり、ウォーターフォール（滝）ならぬ**「ウォーター・スクラム・フォール」**（2週間単位で無茶な仕様が降ってくる滝）でした。
僕らエンジニアは、動くソフトウェアを作るために雇われているはずです。C#のロジックを組み、WPFで美しいUIを構築し、ユーザーの問題を解決するためにコードを書いている。
それなのに、僕らの時間の半分以上が、この**「アジャイルごっこ」**のためのセレモニー（儀式）とミーティングに消えていく。
「こんなの、おかしい」
「もっと効率的に、ストレスなく、価値あるものを作る方法があるはずだ」
僕は海外で働くエンジニアとして、この「働き方」の非効率さに本気で悩み、 burnout（燃え尽き）寸前までいきました。
WPFのXAMLを書いていても、「ああ、明日のプランニングミーティングで、またあの不毛なポイント見積もりをやるのか…」と思うと、手が止まる。
このままじゃ、技術者として死んでしまう。
僕は、本気で「何か」を探し始めました。シリコンバレーの最新スタートアップがやっている、イケてる（っぽい）開発手法か？それとも、もっと根本的な何かなのか？
そして、僕は見つけてしまったんです。
その答えが、僕が毎日見ている「Jira」や「Trello」のUIのことではなく、なんと**1950年代の日本の「自動車工場」**にあったなんて、その時は夢にも思いませんでした。
そう、あの「トヨタ」です。
なぜ、「アジャイルっぽい何か」に疲弊しきった僕が、70年以上前の自動車工場の「ある仕組み」に救われることになったのか？
これが、今回のブログで皆さんに一番伝えたい「フック」です。
この話、単なるプロジェクト管理のテクニックじゃありません。海外でエンジニアとして生き残るための、マジの「人生術」です。
答えはシリコンバレーになかった。トヨタの工場と「スーパーマーケット」が教えてくれたこと
（承：ここから）
「アジャイルっぽい何か」に心底ウンザリした僕は、文字通り「藁にもすがる思い」で、開発プロセスのことを調べまくりました。
「スクラムがダメなら、次は〇〇だ！」みたいな、シリコンバレー発のイケてる（っぽい）新しいフレームワーク、あるいは「アジャile」の「i」が小文字になってるような（笑）、微妙な亜種を探していたんです。
でも、見つかるのは「もっとミーティングをうまくやろう」とか「POのスキルセットが足りない」とか、そういう「精神論」や「他人任せ」の解決策ばかり。
「そうじゃない、俺たち現場のエンジニアが、今すぐ、自分たちの力で、このカオスを何とかできる『仕組み』が知りたいんだ！」
半ばキレながら、夜な夜な海外のフォーラムや技術ブログを漁っていた時、僕は何度も目にする「ある単語」に気づきます。
それが**「Kanban」**でした。
「かんばん？ TrelloとかJiraのボードのことだろ？ うちはもう使ってるよ。でも、タスクが右から左に動くだけで、結局スプリントの終わりには『終わらなかったタスク』が山積みになる。あのボードに何の意味が…」
そう思いながら、僕はその「Kanban」の源流、オリジナルの意味を調べてみて、文字通り、椅子から転げ落ちるほどの衝撃を受けました。
僕が知っていた「かんばんボード」は、その哲学のほんの上澄み、というか「見た目」を真似しただけの「ガワ」に過ぎなかったんです。
そのルーツは、僕が探していたシリコンバレーとは真逆。1950年代、戦後間もない日本の、愛知県にある「トヨタ自動車」の工場でした。
当時のトヨタは、アメリカの巨大な自動車メーカー（フォードとかGM）とは比べ物にならない、リソースも資金もない、小さな町工場のような存在でした。
アメリカ式は「大量生産」。
「先にドカンと10万台分の部品を作って、倉庫に積んでおけ！ あとは流れ作業で組み立てまくるんだ！(Push！)」
という**「プッシュ型」**のシステムです。
でも、当時のトヨタにそんな「在庫（部品）を抱える」体力はありません。そんなことしたら、キャッシュが底をついて即倒産です。
「どうすれば、アメリカと同じ土俵に立たずに、ムダなく、効率よく、高品質な車を作れるんだ…？」
この難題に立ち向かったのが、ご存知の方も多いでしょう、トヨタ生産方式（TPS）の生みの親、**大野耐一（おおのたいち）**氏でした。
そして、彼がこの問題を解決するヒントを見つけた場所が、またスゴイ。
なんと、アメリカの自動車工場……ではなく、**「アメリカのスーパーマーケット」**だったんです。
彼は、スーパーの棚を見て、ある仕組みに気づきます。
- お客さん（Customer）が、棚から欲しいジュースを1本**「取る（Pull）」**。
- 棚のジュースが1本減ったのを**「見た（Visual）」店員が、バックヤードから1本「補充する（Replenish）」**。
- バックヤードのジュースが減ったのを**「見た（Signal）」仕入れ担当が、倉庫（あるいはメーカー）に1本「発注する（Pull）」**。
分かりましたか？
スーパーでは、店長が「今日はジュースを100本売るぞ！」と決めて、棚に無理やり100本**「押し込む（Push）」**ようなことはしません。
**「顧客が、本当に必要とした分だけ」が、下流（顧客）から上流（メーカー）へと、連鎖的に「引っ張られて（Pull）」**いくんです。
これだ！と。
大野氏は、この「スーパーマーケット方式」を自動車の組み立てラインに持ち込みます。
「後工程（組み立てライン）は、前工程（部品工場）にとっての『お客様』である」
という有名な言葉があります。
組み立てラインで「部品A」が1個使われたら（＝顧客が棚からジュースを取ったら）、
組み立てラインは、部品工場に「部品Aを1個使いましたよ」という**「発注書」**を送る。
この**「発注書」こそが、「かんばん（看板）」**と呼ばれる、現物（部品箱）に貼り付けられた「カード」でした。
前工程（部品工場）は、この「かんばん」カードが届かない限り、絶対に部品を作ってはいけない、というルールにしたんです。
これが、トヨタ生産方式の根幹をなす**「ジャスト・イン・タイム（Just-in-Time）」であり、「プル（Pull）システム」**の正体です。
…僕は、この話を知った時、雷に打たれたような気分でした。
「これ、俺たちの『アジャイルっぽい何か』と、構造が真逆じゃないか？」
僕が苦しんでいた現場は、まさに「プッシュ型」でした。
PO（プロダクトオーナー）が「今スプリントでやるぞ！」と決めた大量のタスク（ストーリーポイント）を、僕ら開発チーム（後工程）のキャパシティも考えずに**「押し込んで（Push）」**くる。
僕らは、それをさばくために、全員が複数のタスクを同時に抱え込み（マルチタスク）、あちこちで「待ち（レビュー待ち、仕様確認待ち）」が発生し、その結果、スプリントの終わりには大量の**「仕掛品（Work-in-Progress = WIP）」**、つまり「中途半端に終わったタスク」の山が残る。
これ、トヨタが一番嫌った「ムダ」そのものじゃないか、と。
製造業における「在庫（作りすぎた部品）」というムダは、僕らソフトウェア開発における**「仕掛品（書きかけのコード、レビュー待ちのプルリク、テストされていない機能）」**というムダと、本質的に同じだったんです。
トヨタが「かんばん」というツールを使ってやろうとしたこと。それは、
「今、本当に必要なものだけを、必要な時に、必要なだけ作る」
というシンプルな原則を守ることでしかなかった。
そのために彼らが行ったのは、たった2つの、しかし超強力な「ルール」でした。
- 仕事の流れを「見える化」する（どの部品が、今、どこにあるのか。かんばんボード）
- 同時にやる仕事を「制限」する（WIP制限）（かんばんカードの枚数を決めて、それ以上は絶対に作らせない）
僕が求めていた答えは、シリコンバレーの小難しい横文字のフレームワークじゃありませんでした。
70年も前に、日本のエンジニア（大野氏も技術者でした）が、現場の「ムダ」と「ストレス」を徹底的に排除するために生み出した、超合理的で、超シンプルな「仕組み（システム）」だったんです。
「待てよ…？」
僕は思いました。
「この『ジャスト・イン・タイム』と『WIP制限』っていう考え方、俺のWPFのコードレビューや、C#の設計作業に、そのまま応用できるんじゃないか？」
「俺のチームが疲弊している本当の原因は、『スプリント』という時間で区切ることじゃなくて、**『仕掛品（WIP）を制限していない』**ことにあるんじゃないか？」
僕の目の前が、急に開けた気がしました。
僕がやるべきことは、「アジャイルごっこ」のミーティングを改善することじゃない。
トヨタがやったように、僕の「開発現場」という名のスーパーマーケットから、**「ムダ（仕掛品）」**を徹底的に排除する仕組みを作ることだ。
そして、その最強の武器が「かんばん」だったんです。
C#エンジニアが実践。「ジャスト・イン・タイム」をコードレビューと設計にぶち込んでみた
（転：ここから）
「トヨタの『かんばん』、ヤバすぎる…」
スーパーマーケットの仕組みにまで遡ってその本質を知った僕は、興奮のあまり、その夜は一睡もできませんでした（半分ホントです）。
僕の頭の中は、C#のコードとトヨタの組み立てラインがグルグルと回っていました。
「俺たちの『仕掛品（WIP）』って何だ？」
「書きかけのC#コードだ」
「レビュー待ちのプルリクエスト（PR）だ」
「仕様が曖昧なまま『とりあえず』で作り始めたWIFの画面モックだ」
「俺たちの『後工程』って誰だ？」
「コードレビュワーだ」
「QA（テスター）チームだ」
「そして、最終的には『お客様』だ」
「じゃあ、俺がやるべきことは…？」
答えは一つでした。
「『アジャイルっぽい何か』のミーティングをボイコット（笑）するんじゃなくて、俺たちのチームに、トヨタ式の『WIP制限（仕掛品制限）』と『プルシステム』を導入することだ」
そう決意した僕は、次の日、チームリーダーと数人の同僚（僕と同じように「アジャイル疲れ」していた仲間）を捕まえて、こう宣言しました。
「なあ、もう『スプリント』っていう2週間の箱に、タスクを無理やり詰め込むの、やめてみないか？」
「PO（プロダクトオーナー）が『今週中にやれ』と押し込む（Push）んじゃなくて、**俺たちが『今、本当にできること』だけを『引っ張る（Pull）』**っていうやり方に変えたいんだ」
最初は、みんな「？？？」という顔をしていました。
「どういうこと？ スプリント計画しないと、何をやるか決まらないじゃないか」
「見積もりしないと、いつ終わるかPOに報告できないだろ」
僕は、Jira（タスク管理ツール）のボードを開いて、説明しました。
「俺たちがストレスを感じる原因は、この『In Progress（作業中）』カラムに、一人の開発者が3つも4つもタスクを突っ込んでいることにある。マルチタスクの地獄だ。これじゃ、WPFの複雑なメモリリークなんて追えるわけがない」
「だから、実験しよう。この『In Progress』カラムに入れていいタスクの数を、チーム全体で『4』とか『5』とかに、物理的に制限するんだ」
これが「WIP（Work-in-Progress）制限」です。
僕のチームは当時、開発者5人（僕含む）でした。
「じゃあ、WIP制限は『5』だね」
と、あるメンバーが言いました。
「いや、違う」と僕は反論しました。
「WIP制限を『5』にしたら、開発者5人がそれぞれ1タスクずつ抱えて、結局『俺は俺の仕事』『お前はお前の仕事』になって、誰も助け合わない。それじゃ今までと同じだ」
「トヨタがやりたいのは『個人の効率化』じゃない。『チーム（ライン）全体の効率化』だ。そのためには、あえて**『手待ち』**（やることがない状態）を作り出す必要がある」
「だから、WIP制限は**『3』**だ。開発者5人に対して、動かしていいタスクは3つまで」
「えええ！？」と、チームは騒然となりました。
「5人いるのに、タスクが3つって…残りの2人は何してろって言うんだよ！」
「それこそが『かんばん』の狙いだ」
僕は、前夜に叩き込んだ知識を総動員して説明しました。
革命1：WIP制限「3」がチームに引き起こした「奇妙な現象」
僕らは、Jiraのボード設定を即座に変更し、「Developing（開発中）」カラムのWIP上限を「3」に設定しました。Jiraは優秀で、タスクが4つ目をドラッグされると、カラムが赤く光って「警告」を出してくれます。
そして、運命の月曜日が来ました。
開発者A、B、Cが、それぞれ「Ready for Dev（開発OK）」のカラムからタスクを「Developing」に引っ張り（Pull）ました。
これで、WIPは「3」。上限いっぱいです。
僕（開発者D）と、もう一人（開発者E）は、「Developing」にタスクを入れられません。
僕らは「手待ち」です。
「おい、どうすんだよこれ。俺ら、今日何すればいいんだ？」
開発者Eが、不安そうに僕に聞いてきました。
これが、「アジャイルごっこ」に染まった脳が起こす、最大のアレルギー反応です。
「エンジニアたるもの、常に手を動かし、常に『忙しく』していなければならない」
という呪い。
僕はニヤリと笑って、ボードを指差しました。
「トヨタのルールを思い出せ」
「俺たち『後工程』は、自分たちの仕事（コーディング）だけをするんじゃない。『前工程』を助けるか、『下流工程』を助けるか、それが仕事だ」
「まず、**『下流』**を見よう」
ボードには「Developing」の次に、「Ready for Code Review（レビュー待ち）」というカラムがありました。
そこには、先週末にAさんが終わらせたタスクが、1つ、ポツンと置かれています。
「Eさん、俺たち、やることあるじゃないか」
「あ…」
そうです。僕ら「手待ち」の2人がやるべきこと。
それは、新しいコードを書き始めること（＝仕掛品を増やすこと）ではなく、
「溜まっているコードレビューを、世界最速で片付けること」
だったんです。
僕とEさんは、そのタスク（Aさんのプルリクエスト）を、2人で徹底的にレビューしました。
「ここのC#のロジック、もうちょっと簡潔に書けないか？」
「このWPFのXAML、ViewModelとのバインディングが、将来リーク（メモリ漏れ）起こさないか？」
2時間後、僕らはレビューを完了し、Aさんにフィードバックを送りました。Aさんはすぐに修正し、タスクは「Ready for Test（テスト待ち）」へと流れていきました。
さあ、その時です。
開発者Bさんが、「うーん、詰まった…」と声を上げました。
彼がやっていたタスクは、レガシーな部分の改修で、C#の複雑なビジネスロジックが絡み合う、いわゆる「地雷」でした。
彼はWIP「3」のうちの1つを占有し、「Blocked（進捗不可）」の状態になりました。
さあ、どうする？
「手待ち」の僕とEさん。
「Bさん、手伝おうか？」
これが、自然に出てきた言葉でした。
僕ら3人（B、D、E）は、Zoom（あるいはデスク）で頭を突き合わせ、その「地雷」の設計について議論を始めました。（いわゆる「モブプログラミング」や「ペアプログラミング」が自然発生した瞬間です）
もし、WIP制限がなかったら？
僕（D）もEさんも、自分の新しいタスクを「Developing」に入れていたでしょう。Bさんが「詰まった」と声を上げても、「ごめん、今こっちも手が離せないんだ…」と言って、Bさんは孤立していたはずです。
でも、WIP制限「3」が、僕らを**「助け合わわざるを得ない」**状況に追い込んだんです。
革命2：「見積もりミーティング」の廃止
この「WIP制限」が定着してくると、もう一つ、驚くべき変化が起きました。
僕が、あれほど憎んでいた**「ストーリーポイント見積もり」**が、いらなくなったんです。
考えてみてください。
トヨタのスーパーマーケットで、店員は「このジュースは棚に補充するのに『8ポイント』かかる」なんて議論をしますか？
しませんよね。
彼らが見ているのは、ただ一つ。
「ジュースが棚から取られてから（＝Ready for Dev）、バックヤードから補充されるまで（＝Done）、平均して何時間かかったか？」
という、**「リードタイム（所要時間）」**だけです。
僕らのチームも、タスクをポイントで見積もるのを一切やめました。
代わりに、ボードの「Ready for Dev」から「Done」までの「平均リードタイム」を計測し始めたんです。
POが「この機能、いつ終わる？」と聞いてきたら、
僕らは「（当てにならない）8ポイントです」と答える代わりに、
「ウチのチームは、似たようなサイズのタ…”タスク”（ストーリーではなく）を、平均3日で完了させています。だから、今『Ready for Dev』に積まれているタスクが5個あるので、あなたの機能は、だいたい15日（3日×5タスク）後くらいに着手できますよ」
と、**「実績（データ）」**に基づいて答えられるようになったんです。
この「WIP制限」と「プルシステム」は、僕のC# / WPF開発に革命を起こしました。
僕は、WPFの複雑な画面設計（Design）をやるとき、もう「早くコーディング（Development）もしなきゃ」と焦る必要がなくなりました。
「Designing」カラムにWIP制限「1」を設ければ、僕はその設計タスクに**「合法的に」集中できる。なぜなら、それがチーム（システム）全体の流れをスムーズにするために、今僕がやるべき「唯一の仕事」**だからです。
僕が書いたC#のコードが「Ready for Code Review」で滞留することもなくなりました。
なぜなら、「手待ち」になった仲間が、それを最優先で「Pull」してレビューしてくれるからです。
「アジャイルごっこ」の儀式に振り回され、マルチタスクの地獄で燃え尽きかけていた僕は、70年前の日本の知恵によって、初めて「エンジニアとして、本当に価値のある仕事に集中できている」という実感を得ることができたんです。
「かんばん」はツールじゃない、最強の「人生術」だった。
（結：ここから）
「アジャイルっぽい何か」に疲弊し、WIP（仕掛品）の地獄で燃え尽きかけていた僕が、1950年代のトヨタの工場とアメリカのスーパーマーケットにヒントを得て、現場に「WIP制限」という爆弾を投下した話（笑）。
それが「転」でした。
結果、僕のC# / WPF開発チームはどうなったか？
- レビュー待ちのプルリクエストは、「手待ち」になった仲間が光の速さで片付けるようになった。
- 「なんで俺だけ忙しいんだ！」という不満が消え、**「詰まってるタスク（ボトルネック）を全員で助ける」**という文化が生まれた。
- 「このタスクは8ポイントです」という**不毛な「工数当てゲーム」がなくなり、「うちのチームの平均リードタイムは3日です」という「実績（データ）」**で会話できるようになった。
- そして何より、僕自身、WPFの複雑な設計（僕の専門領域です）に**「合法的に」**集中できる時間が手に入った。
僕が体験したのは、まさに「革命」でした。
JiraやTrelloのボード。あれは「かんばん」そのものじゃなかった。
あれは、僕らの仕事（ワークフロー）を「見える化」するための、ただの「器」です。
本当の「かんばん」とは、その器に注ぎ込まれる、
- 仕事を「押し込む（Push）」な、「引っ張れ（Pull）」
- 同時にやる仕事を、物理的に「制限しろ（WIP Limit）」
という、たった2つの、しかし超強力な**「ルール」であり「哲学」**でした。
そして、このブログの結論です。
僕がたどり着いた答えは、**「かんばんは、最強の人生術である」**ということです。
「は？ 仕事の進め方の話が、なんで急に『人生術』になるんだよ」
そう思いますよね。
でも、海外でエンジニアとして生き抜き、ここでキャリアを築いていこうと本気で考えた時、この「かんばん」の哲学が、僕の仕事観、いや、人生観そのものを変えたんです。
1. 「忙しいフリ」という人生のムダからの解放
僕らが「アジャイルごっこ」で疲弊していた最大の原因は、**「常に忙しくしていないといけない」**という強迫観念でした。
WIP制限がない状態というのは、「やることがない（手待ち）」状態を「悪」とみなすシステムです。
だから、レビュー待ちでやることがなくなると、不安になって、まだ仕様も固まってない次のタスクに手を出し、新たな「仕掛品（WIP）」を生み出してしまう。
でも、「かんばん」は、その「手待ち」こそが「善」である、と教えてくれました。
**「手待ち」は、システム（チーム）に生まれた「余裕（スラック）」**です。
その余裕があるからこそ、仲間が詰まった時に助けに行けるし、溜まったレビューを片付けられるし、本当にヤバいバグが飛び込んできても対応できる。
WIP制限は、僕らに「忙しいフリをするな」「マルチタスクという名のムダな仕事をするな」「今、本当に価値のある『たった一つ』に集中しろ」と教えてくれる、最強の「お守り」なんです。
僕はこの考え方を、プライベートにも応用しました。
「勉強のために技術書Aも読む」
「副業のためにBの動画も見る」
「将来のためにCの勉強会も行く」
…これ、全部「仕掛品（WIP）」ですよね。
全部やめて、自分のWIPを「1」にしました。
「今月は、この技術書Aを『終わらせる（Done）』ことだけが、俺の人生のタスクだ」
そう決めて、他のノイズを全部シャットアウトする。
結果、どうなったか？
人生の「リードタイム」が爆発的に短くなりました。
中途半端な知識（仕掛品）の山が、確実なスキル（Done）に変わっていったんです。
2. 「海外で働く」とは、「ルール」と「データ」で戦うこと
そして、これが「これから海外で働くエンジニア」の皆さんに、僕が一番伝えたかったことです。
なぜ、僕が「アジャイルっぽい何か」にあれほど苦しんだのか。
それは、「スクラム」のようなフレームワークが、「解釈」の余地を大きく残しているからです。
「デイリースクラムは15分で『簡潔に』やろう」
「レトロスペクティブで『建設的』に話し合おう」
この「簡潔に」とか「建設的に」の尺度が、文化や言語、バックグラウンドが全く違う多国籍チームでは、絶望的に揃わないんです。
僕の現場もそうでした。
ある国のエンジニアは「問題点を全て洗い出すのが誠意だ」と信じてレトロスペクティブで1時間喋り続けるし、別のエンジニアは「空気を読んで（笑）」当たり障りのないことしか言わない。
「アジャイル・マニフェスト」という名の「ポエム」を、みんなが自分に都合よく解釈するカオス。それが僕の職場でした。
その点、「かんばん」は、天才です。
「WIP制限は、3だ」
このルールに、「解釈」の余地はありません。
文化も言語も関係ない。
ボードの「Developing」カラムに、4つ目のタスクを突っ込もうとしたら、カラムが赤く光る。ただそれだけ。
「平均リードタイムは、3日だ」
このデータに、「反論」の余地はありません。
POが「なんで遅いんだ！」と精神論で怒鳴ってきたら、「あなたの優先順位がブレるから、タスクの差し込み（割り込み）が頻発し、結果としてリードタイムが悪化している。このデータを見ろ」と、客観的な事実で議論ができる。
海外の（特に欧米系の）エンジニアやマネージャーは、こういう**「曖昧さのないルール」と「客観的なデータ」**が大好きです。
「頑張ります」「チーム一丸となって」なんていう日本の「精神論」は、残念ながら1ミリも通用しません。
これから海外で働くあなたが、文化も言語も違う強者たちと渡り合っていくために必要なのは、熱意や根性（それも大事ですが）よりも、**「客観的なルールとデータで、自分とチームを守る術」**です。
「かんばん」は、その最強の武器になってくれます。
3. あなたが明日からできる「小さなかんばん」
「わかった、でも、いきなりチームのルールを変えるなんて無理だ…」
そうですよね。僕も、最初はそうでした。
だから、最後に、あなたが一人で、明日からできる「ファーストステップ」を提案します。
**「マイ・かんばん」**をやってみてください。
- 紙とペンでいいです（Trelloでもいい）。
- 「ToDo（やること）」「Doing（作業中）」「Done（完了）」の3つのレーンを書きます。
- 「Doing」のレーンに、**「WIP = 1」**と、クソデカい赤字で書いてください。
- 朝、ToDoから「今日、絶対に終わらせる」と決めたタスクを、たった一つだけ「Doing」に移動させます。
- 何があっても、そのタスクが「Done」に移動するまで、絶対に、絶対に、他のタスクを「Doing」に入れてはいけません。
メールが来ようが、チャットが鳴ろうが、上司に呼ばれようが（これは無理か（笑））、あなたの「Doing」は「1」です。
「すみません、今、WIPが1なので、それが終わったら対応します」
そう言う勇気を持つことです。
これを1週間、いや、3日間でもいいから続けてみてください。
世界が変わります。
いかに自分が、日々、大量の「仕掛品（WIP）」を生み出し、その「マルチタスクの切り替えコスト」によって、人生の貴重な時間を浪費していたかに気づくはずです。
僕らエンジニアの価値は、「どれだけ忙しく働いたか（Busy）」ではなく、「どれだけ価値を顧客に届けたか（Done）」で決まります。
「かんばん」は、その「Done」にたどり着くための、最短かつ最強の「ムダとり」の道具であり、僕らエンジニアがストレスなく、本当に価値ある仕事に集中するための「人生術」です。
このトヨタが生んだ偉大な「知恵」が、海外という新しいフィールドで戦うあなたの「武器」になることを、心から願っています。
コメント