日本のアジャイル: アジャイル導入に向けた 8 つの課題に取り組む

Agileの起源がLeanにあり、Leanの原則がトヨタで部分的に開発されたことをご存じかもしれません。「看板」(Kanban: ボード)、「改善」(Kaizen: 改善)、「自動化」(Jidoka: 自動化)といった用語はもちろん、日本語から来たものです。さらに、日本から発祥した多くのLeanの概念があり、有名な「3M」– Muda (無駄: 不要な作業)、Muri (無理: 無理な作業)、Mura (斑: 不均一な作業分配)や、武道の熟練段階を示すShuHaRi (守破離: 守る・破る・離れる) もその一部です。このリストはまだまだ続きます！

日本で働いたことがない人は、「日本の企業こそが最もAgileだろう」と思うかもしれません。この話題は何度も議論されてきましたが、私は大きなため息をつく代わりに、ささやかな涙を流しながら説明を続けます。

残念ながら、日本企業と欧米企業の間にはAgileに関して大きな隔たりがあります。Agileトランスフォーメーションに向けた最初の一歩がいくつか踏み出されていますが、私が知る限り、多くの企業は非常にウォーターフォール的な方法論をいまだに採用しています。大半の場合、それは教科書的なウォーターフォールです。たとえば、プロジェクト計画とガントチャート、機能別チーム、階層的な意思決定、サイロ化、顧客との断絶、その他の非Agileな世界との対比でよく批判される特徴が挙げられます。

確かに、日本企業は品質においては卓越しています（LeanとKaizenのおかげです！）。しかし、イノベーションと顧客中心性においては遅れを取っています。私は日本で12年以上生活し働いてきましたが、日本企業がAgileになるのを妨げる要因を日々目の当たりにしています。これらの中には克服が容易なものもあれば、難しいものもあります。それでも成功したAgileトランスフォーメーションの事例に関与してきたので、不可能ではありません。しかし、これらの要因が非常に重要であることは間違いありません。

障壁その1：アウトカムとアウトプットの混同

日本企業はしばしばアウトプットを成果と見なします。過労死や職場での仮眠が一般的であるという話を聞いたことがあるかもしれません。これは、働いた時間が長く、疲れ切った様子を見せるほど、昇進やボーナスを得やすくなるからです。たとえば、手書きのリストからExcelにデータを手動入力し、それをスクリーンショットに撮ってWordに挿入し、印刷して同僚にファックスで送る、といった仕事をしても、数時間余分に働き、疲れた様子を見せていれば評価されます（冗談ではなく、実際に見たことがあります）。または、Excelの小さなセルを使ってピクセルアートを作成する、といったこともあります。

これが問題になるのは、革新的な解決策を考え出し（たとえば、グラフィックエディタを使用してExcelを代替する）、プロセスを簡略化し（Excelファイルをメールで送信し、Wordやファックスを省く）て仕事を早く終えると、以下の3つの選択肢に直面するからです。

1. 定時に帰る（怠け者のレッテルを貼られ、昇進や昇給のチャンスを失うリスクを伴う）。

2. 忙しいふりをして上司が帰るまでオフィスに残る（Excelピクセルアートを作成するなど）。

3. PowerPointプレゼンテーションを作成するなど、新しいタスクを見つけて自分を忙しくする。

アウトカム（顧客の問題解決、ビジネス収益の増加、NPSスコアの向上など）ではなく、アウトプット（作業時間、コード行数、生成されたドキュメント、または開始されたキャンペーン数）を評価する文化は、日本では非常に根深く、これを変えることはAgileトランスフォーメーションの成功にとって大きな障害となります。ただし、難しいながらも不可能ではありません。

障壁その2：従順の文化

武士道文化は現在も日本社会に深く根付いています。多くの日本人社員にとって、上司の命令に疑問を呈したり、挑戦するという考えは信じられないことです。この考え方は若い世代のおかげで徐々に変わりつつありますが、依然として多くの社会が厳格な階層的な世界で運営されています。この世界では、上司の命令がすべてです。

日本語そのものも、この階層を強調するよう構造化されています。たとえば、「与える」という動詞（および他者に向けられる多くの動詞）は、目上の人（親、教師、上司など）に対して使うと「持ち上げる」という意味に変わり、部下や年下の兄弟に対しては「下ろす」という意味になります。また、人々は互いの年齢やコホート（学校の同級生や会社に入社した年）を非常に重視し、自分より「上」の人には従い、「下」の人には従わせることを期待します。

残念ながら、女性は男性よりも階層的に低く見られることが多いですが、これも徐々に変化しています。女性が意見を述べることをためらう場面をしばしば目にします。

この文化的背景を考慮すると、階層が日本社会において重要な役割を果たしていることがよくわかります。これを踏まえて、さまざまな階層レベルの人々を含むチームでワークショップを実施したり、全員の意見を必要とし、互いに挑戦することを期待されるバックロググルーミングセッションを想像してみてください。

この障壁を突破することは可能ですが、時間と努力を要します。私は最終的に真にAgileなチームを形成できた事例をいくつか経験しました。これらのチームは、ステータスやランクを外に置き、オープンな会話に従事し、互いに挑戦し、新しいアイデアを提案できるようになりました。しかし、初めの頃は、他人の考えに反することへの謝罪やためらいが多く見られました。

障壁その3：「神様」のような顧客

日本には「お客様は神様です」という有名な言葉があります。神道では、森、川、山、岩といった自然物に神が宿っており、祈りを捧げることで豊作や自然災害からの保護といった恩恵を受けるとされています。同様に、顧客も神のように扱われ、ビジネスに成功をもたらす存在として崇められます。

確かに、日本では顧客が非常によく扱われ、素晴らしいサービスや行き届いたケアが提供されます。しかし、この考え方には欠点があります。それは、顧客に直接何を求めているのかを尋ねることを企業がためらう点です。顧客の時間を「煩わせたくない」という意識があるためです。

これにより、日本の企業は非常に顧客志向でありながら、顧客中心的ではないというパラドックスが生まれます。企業は顧客の望むものを予測しようとしますが、成功することもあれば、失敗することもあります。プロトタイプ、MVP、直接的なフィードバックを活用することは日本では一般的ではなく、顧客にリサーチに参加させたり、フォームやアンケートを通じてフィードバックを求めることもあまりありません。

さらに、顧客は「神様」のように扱われることに慣れているため、リサーチやユーザビリティテストへの参加を依頼するのが難しい場合もあります。しかし、不可能ではありません。

この障壁を克服するには、企業が「崇拝者」の心構えから「研究者」の心構えに切り替え、顧客と直接対話し、そのフィードバックを取り入れる必要があります。

障壁その4：規則、プロセス、プロトコル

日本では、規則が生活のあらゆる面を支配しており、それが非常に重視されています。新しい会社に入ると、社員は守らなければならない規則や業務プロトコルに圧倒されることが多いです。大企業では、毎年4月に新卒を大量採用し、数か月から数年にわたる徹底的な研修を行います。

この厳格な規則遵守は、高品質な製品の製造に役立ちます。たとえば、人気のあるSUVや高度なカメラを製造する際には、このようなプロトコルや品質管理手法が競争優位性をもたらします。しかし、イノベーションや実験に関しては、これらの規則が柔軟な発想を妨げることがあります。小さな変更でさえ、長い議論や多くの承認、膨大な書類作業が必要です。

たとえば、私が日本に来たばかりの頃、あるeコマースサイトのチームで働いていました。そのチームは、送料を100円（約1ドル）引き下げるだけで3か月近くを費やしました。その間に行われた無数の議論やPowerPointプレゼンテーションの労働コストは、送料削減による収益減少をはるかに上回るものでした。

Agileコーチとして日本のチームと協力する際には、規則や規制の前提を精査することが重要です。維持すべき規則もあれば、廃止すべき規則もあります。また、財務や法務などの関係部門に支援を求める必要がある場合もあります。Agileを促進するには、パイロットAgileチームの周りに自由のバブルを作り、規則や規制に対する組織全体のアプローチを再考する必要があります。

障壁その5：現状維持

日本は保守性と現代性が混在した興味深い国です。古代文化や伝統を深く尊重する一方で、職場にこの保守性が及ぶと苛立たしさを感じることがあります。例えば、時代遅れの技術（ファックスなど）や90年代のようなウェブサイトが依然として存在しています。「問題がないなら変える必要はない」という考え方が支配的で、変化を導入することは大きなリスクと見なされています。企業は、変化によって既存顧客を遠ざけたり、新技術に適応できない人々からの苦情を招くことを恐れています。

個人的な経験を話すと、数年前に会社を設立した際、申請書類をCD-Rで提出する必要がありました。外付けドライブを購入する羽目になりましたが、数年前までは3.5インチフロッピーディスクで提出していたそうです。現在ではそのドライブを購入することすらほぼ不可能です。若い世代にとって、3.5インチフロッピーディスクは「保存」ボタンのアイコンでしかありません。

現状維持は日本企業において強力な力を持ち、既存顧客にサービスを提供し、現状を維持することに重点を置き、新市場への進出や新しいアプローチの探求はあまり行われません。Agileトランスフォーメーションを成功させるには、顧客ペルソナやカスタマージャーニーの演習に時間を投資することが重要です。これにより、チームは「変化から顧客を守る」姿勢から「顧客のニーズや苦痛点を共感する」姿勢に転換することができます。前述の通り、日本のビジネスは非常に顧客志向であり、少しの指導があれば顧客中心になる可能性を秘めています。

障壁その6：リスク回避志向

日本ではギャンブルが法律で禁止されていますが、パチンコ（スロットマシン）、競馬、ボートレースといった抜け道が存在します。ただし、賭け金は通常少額であり、一度の賭けですべてを失うことは稀です。

日本企業はリスク回避志向が強い傾向にあります。西洋では50対50の成功率でも価値のある挑戦と見なされる場合がありますが、日本ではこの確率ではほぼ間違いなく却下されます。成功率が70%あっても、内部での長時間の議論と調整が必要であり、30%の失敗リスクを受け入れることは難しいです。

Agileでは、チームが大胆に新しいことを試し、失敗を学びの機会と見なすことを奨励します。しかし日本では、他の企業がすでに成功しているという十分な証拠がある場合にのみプロジェクトに取り組む傾向があります。このため、日本企業がAgileを採用する事例は非常に少なく、成功事例が出るのを待ってから投資を決定する傾向があります。

このリスク回避志向を克服するには、小規模で低リスクの実験から始め、それを習慣化し、徐々にスコープを拡大して賭け金を上げることが重要です。チーム内で心理的安全を確保し、新しいことを試みて学ぶ努力を報いる文化を作り出すことが必要です。

障壁その7：PowerPointの支配

この問題は日本特有ではありませんが、日本企業がAgileになるのを妨げる要因の一つとしてPowerPointの存在を挙げることができます。日本の企業で働いた経験を通じて、多くの人がスライド作成に膨大な時間を費やし、そのスライドを議論するためにミーティングに参加する姿を目にしてきました。

スライドデッキは私の天敵であり、Agileの敵でもあると考えています。ここで言っているのは会議用スライドのことです。数時間をかけて数ページのスライドを作成し、興味を持たない聴衆の前で数分間見せた後、再び新しいスライドを作成するプロセスです。もちろん、数値やグラフを準備してポイントをサポートする必要がある場合もありますが、会議が「PowerPointカラオケ」に成り下がるべきではありません。会議は、対面の会話や有意義な議論、問題解決のために集まる場であるべきです。

多くの日本企業では、10ポイントのフォントでぎっしり詰まったプレゼン資料や膨大な詳細が含まれるスライドが好まれます。その結果、議論の余地がほとんどないミーティングが行われ、情報共有や進捗報告、アナウンスに終始し、実際のコミュニケーションや意思決定、問題解決がほとんど行われません。

私がチームをコーチする際、会議中のスライド使用を禁止することがよくあります。その代わりに、ホワイトボード、Miro、Jira、その他のコラボレーションツールを活用し、参照資料を保存します。最後に行いたいことは、四角形を揃えたり、箇条書きのインデントを調整することに時間を費やすことです。このようにすることで、顧客行動や市場動向の調査、製品設計、実験、結果分析など、本当に重要な作業に集中するための時間が生まれます。

障壁その8：ベンダー依存

多くの国の企業がベンダーを活用していますが、日本ではその依存度が特に高い場合があります。日本の企業では、営業担当者やプロジェクトマネージャー（「プロデューサー」や「ディレクター」と呼ばれることが多い）が主に活躍しており、専門知識を必要とする作業（デザイン、開発、マーケティングなど）は外部のベンダーにアウトソースされることが一般的です。

この依存構造により、ウォーターフォール的な進行が避けられなくなります。すべての要件をまとめてからベンダーに送る必要があるためです。日本では、主に2種類のアウトソーシング形態があります：

1. 業務委託: 作業全体をベンダーに委託し、完成を待つ。

2. 派遣社員: 専門家を一時的にチームに迎える。

後者はうまく機能する場合が多いですが、前者はクライアント企業に多大な制約を課すことが一般的です。標準的な契約では、ベンダーのプロジェクトマネージャー以外と直接やり取りできないことが多く、またクライアント企業側も自社のプロジェクトマネージャーのみがベンダーと話すことを許されています。

技術的知識のないプロジェクトマネージャーが、エンジニアリングチームの要求をベンダーのチームに伝えるのは大変な作業です。このような状況は、クライアントとベンダーの両側でウォーターフォール的なプロセスを悪化させ、最悪の場合、伝言ゲームのように混乱を招きます。

Agileをベンダーと一緒に実現することは可能ですが、良い結果を得るには、ベンダーを自社チームの一部のように扱い、完全な透明性と毎日の対面コミュニケーションを確保する必要があります。この目標を達成するには、新しい契約の策定やアプローチの完全な見直しが求められるでしょう。

結論

日本にはAgileトランスフォーメーションの大きな可能性が広がっています。多くの障壁が存在する一方で、それらを克服することは可能です。ここで挙げた問題にもかかわらず、日本企業には計り知れない可能性があり、より多くの企業が野心を持ってグローバル市場で成功することを願っています。