はじめに
会議室で誰かが「戦略」と言った瞬間、空気が変わる。
みんなの背筋が伸びる。うなずきが深くなる。誰かがおもむろにホワイトボードの前に立ち、矢印を描き始める。私も「なるほど」という顔をしてみる。眉間にしわを寄せ、顎に手を当て、いかにも深く考えているふうを装う。会議室にいる全員が、突然「戦略を理解している側の人間」になる。
ただ、私は知っている。この部屋にいる何人かは、私と同じことを思っているはずだ。
「で、結局、何をするの？」
言えない。絶対に言えない。「戦略」という言葉が持つ重厚感に押しつぶされて、そんな素朴な疑問は喉の奥に引っ込んでしまう。分かっていないことがバレたら終わりだ。「あいつ、戦略を理解していない」というレッテルを貼られたら、もうこの会議室での発言権はない。だから黙る。黙って、賢そうな顔を続ける。
不思議なのは、誰もが同じ演技をしているように見えることだ。部長も、課長も、隣に座っている同僚も。みんな「戦略」という言葉に真剣な顔で向き合っている。でも、その「真剣な顔」は、本当に理解しているから出てくる表情なのだろうか。それとも、理解していないことを悟られないための防衛反応なのだろうか。私には、区別がつかない。
会議が終わると、みんな自分のデスクに戻っていく。誰も「さっきの戦略、よく分からなかったね」とは言わない。私も言わない。言ったら負けだ。何に負けるのかは分からないけど、とにかく負ける気がする。だから、分かったふりを続ける。
これは、そういう自分への苛立ちから始まった文章だ。
「戦略的に考えろ」と言われるたびに、心の中で「戦略的って何だよ」と毒づいてきた。でも調べなかった。調べるのが怖かった。調べて、やっぱり分からなかったらどうしよう。そんな不安があった。聞くこともできなかった。「戦略って何ですか」なんて質問は、新卒1年目ならまだ許される。でも、何年も働いてきた人間が今さら聞けるわけがない。だから分かったふりを続けてきた。その居心地の悪さを、いい加減どうにかしたかった。
だからこの文章を書いている。誰かのためではない。自分のためだ。「おい、戦略を語れ」という言葉は、会議室の誰かに向けているようで、実は鏡の中の自分に向けている。お前は本当に分かっているのか。分かったふりをしているだけじゃないのか。その問いに、いい加減決着をつけたかった。
戦略という言葉の氾濫
私たちの周りには、「戦略」という言葉が溢れている。経営戦略。マーケティング戦略。販売戦略。顧客戦略。人材戦略。DX戦略。グローバル戦略。デジタル田園都市国家構想総合戦略。こんなに幅広く使われている「戦略」だが、その核心が何なのかと聞かれると、答えられない。いや、答えられないだけならまだいい。答えが人によって違いすぎる。ある人は言う。「戦略とは、目標を達成するための手段だ」。別の人は言う。「戦略とは、ビジョンを実現するための計画だ」。また別の人は言う。「戦略とは、競合に勝つための差別化だ」。どれも間違ってはいない。しかし、どれも正しくはない。なぜなら、これは戦略の「結果」であって、戦略の「核心」ではないからだ。
戦略会議で何が起きているか、もう一度見てみよう。「今期の戦略は、売上を前年比130%にすることです」。これは戦略ではない。目標だ。どうやって達成するのかは、何も語られていない。「我々の戦略は、顧客第一、品質重視、イノベーション推進です」。これも戦略ではない。スローガンだ。具体的に何をするのかは、何も示されていない。「我々のマーケティング戦略は、デジタルチャネルの強化、SNS活用の拡大です」。これも戦略ではない。施策の羅列だ。なぜその打ち手なのか、どうつながっているのか、何が問題でそれがどう解決するのかは説明されていない。
そして、最悪なのは、これらを「悪い戦略」と呼ぶことさえ正しくないということだ。悪い戦略とは、内部の対立を曖昧にするための妥協の産物である、という指摘がある。経営会議で、営業部と開発部が対立する。営業は「もっと新機能を」と言う。開発は「品質を優先すべき」と言う。すると、誰かが言う。「では、両方やりましょう。それが我々の戦略です」。これは妥協だ。誰も傷つけないための八方美人だ。でも、これを「戦略」と呼んではいけない。
なぜなら、戦略とは、選択だからだ。何をやるかを決めることではない。何をやらないかを決めることだ。しかし、私たちは選択できない。なぜか。
もちろん、個人の心理もある。選択することは、責任を負うことだ。「これをやる」と決めた人間は、それが間違っていた時、責任を取らなければならない。だから、選択を避ける。全部やると言えば、誰も傷つかない。
ただ、問題は個人の心理だけではない。組織の構造が、選択を妨げている。
まず、インセンティブの問題がある。営業部長は営業の数字で評価される。開発部長は開発の成果で評価される。全社最適より部門最適が優先される構造になっている。「うちの部門の予算を削るな」という力学が働く。
次に、権限の曖昧さがある。誰が「やらない」と決める権限を持っているのか。多くの組織で、これが不明確だ。だから、誰も決めない。決めなければ、責任を問われない。
また、評価制度との不整合がある。「やらないと決めた」ことは、評価されにくい。成果として見えないからだ。「100のことをやって80点」より「30に絞って95点」の方が戦略的には正しい。しかし、評価制度が前者を高く評価することがある。
だからといって、個人の責任がないわけではない。選択する勇気は必要だ。ただ、勇気だけで組織を変えることはできない。構造を変えなければ、選択は起きない。「全部やる」は、個人の弱さであると同時に、構造の帰結でもある。
選択を避け、妥協を繰り返す。その結果、戦略という言葉は、中身のない器になった。何を入れても受け入れる、便利な箱になった。目標を入れる。スローガンを入れる。希望を入れる。妥協を入れる。蓋を閉じて、「戦略」というラベルを貼る。これが、私たちが「戦略」と呼んでいるものの正体なのだろう。
この空洞さは、どの立場にいても感じることがあるだろう。ただ、私のように技術寄りの立場にいると、余計に気になることがある。技術顧問として呼ばれているのに、いつの間にか「経営戦略」のスライドを見せられている。自分はシステムのアーキテクチャについて聞かれると思っていたのに、気づくと「売上130%」のスライドの前に立たされている。その「戦略」がどのレイヤーの話なのか、技術側から見るとよくわからない。事業の話なのか、組織の話なのか、プロダクトの話なのか。全部が「戦略」という言葉で括られている。
しかし、だからといってエンジニアが戦略と無縁でいられるわけではない。プロダクトのどこにリソースを割くか。どの技術的負債を今返し、どれを後回しにするか。このアーキテクチャで将来の拡張性を取るか、今のシンプルさを取るか。これはすべて戦略的な判断だ。経営会議に出なくても、コードを書いていても、私たちは日々、戦略的な選択をしている。だからこそ、「戦略とは何か」を理解することは、エンジニアにとっても他人事ではない。
私自身、最近作った資料を振り返ることがある。「戦略」と書いたスライド。本当に「解決すべき最重要課題と、その解き方」になっていたか。目標やスローガン、施策の羅列に留まっていなかったか。正直、自信がない。
核心を見極める
戦略を一言で表すなら、こうなる。「戦略とは、解決可能な最重要課題を見極め、それを解決する方法を見つけることだ」。シンプルだ。しかし、深い。
まず、「解決可能な最重要課題」とは何か。組織が直面している問題は無数にある。しかし、すべてが同じ重さではない。ある問題を解決すると、他の問題も連鎖的に解決に向かう。そういう問題がある。それが「核心的な課題」だ。
技術選定を考えてみよう。新しいプロジェクトを始める時、検討すべきことは無数にある。言語は何にするか。フレームワークは何を使うか。データベースは何が適切か。インフラはどう構成するか。すべて重要だ。ただ、すべてを同時には最適化できない。ここで、核心を見極める必要がある。たとえば、「チームの習熟度」が核心だとする。どんなに優れた技術でも、チームが使いこなせなければ意味がない。だから、チームが慣れている言語を選ぶ。すると、立ち上がりが早くなり、バグも減り、メンテナンスも楽になる。1つの核心を押さえたら、他の問題も動き始めた。戦略も同じだ。核心的な課題を見つけ、そこにリソースを集中させる。戦略とは、この課題を見つけることから始まる。
会社が直面している問題は無数にある。売上が伸びない。競合が強い。人材が足りない。技術が古い。すべて問題だ。すべて解決したい。だが、すべてを同時に解決できない。だから、見極める。どれが核心的な課題なのか。どれを解決すれば、他の問題も動き始めるのか。私が関わったある組織で、プラットフォームエンジニアリングチームを立ち上げようとした時、無数の技術的課題があった。どれも難しい。どれも重要だ。Kubernetesの運用。CI/CDパイプラインの整備。監視基盤の構築。セキュリティポリシーの策定。ただ、本当の核心的な課題は、別のところにあった。「開発者がインフラを触るまでのリードタイムが長すぎる」。これが核心だった。どんなに優れた基盤があっても、開発者が使い始めるまでに2週間かかるなら、誰も使わない。だから、セルフサービス化を最優先にした。申請から環境構築までを30分に短縮した。すると、利用率が上がり、開発速度も上がり、プラットフォームチームへの信頼も高まった。1つの核心を解いたら、他の問題も動き始めた。これが、戦略だ。核心的な課題を見つける。解決策を見つける。実行する。
もう1つ、私自身のプラットフォームエンジニアリングの経験を話そう。以前いたチームでは、コードの品質、テストのカバレッジ、ドキュメントの不足、レガシーシステムとの連携と、無数の課題があった。ただ、本当の核心的な課題は別のところにあった。「開発者がステージング環境を立てるのに2日かかる」。これが核心だった。インフラチームへの申請、承認待ち、手動でのセットアップ。ステージング環境が作れなければ、検証できない。検証できなければ、リリースできない。Terraformでインフラをコード化し、GitHubのPRをマージするだけで環境が立ち上がるようにした。30分で完了する。すると、リリース頻度が上がり、バグも減り、開発者体験も改善された。1つの核心を解いたら、他の問題も動き始めた。
シンプルだが、簡単ではない。課題を見極めることは、選択だからだ。「これが最も重要だ」と決めることは、「他は優先しない」と決めることでもある。戦略会議を思い出そう。「売上を前年比130%にする」は核心的な課題ではない。売上を伸ばすことは結果であって、問題ではない。問題は、なぜ売上が伸びないのか、だ。競合が強いのか。商品が古いのか。チャネルが弱いのか。ブランドが知られていないのか。価格が高いのか。営業力が足りないのか。どれが核心なのか。どれを解決すれば、売上が伸びるのか。それを見極めることが、戦略の第一歩だ。しかし、私たちはそれをしない。見極めることは、責任を負うことだからだ。「これが核心だ」と言った人間は、それが間違っていた時、責任を取らなければならない。だから、誰も言わない。全部重要だと言う。全部やると言う。そして、何も解決しない。
選択から逃げる方法は、もう1つある。パーパスやミッションに逃げ込むことだ。パーパスやミッションは、戦略ではない。パーパスとは、企業の存在意義だ。ミッションは、企業が果たすべき使命だ。どちらも重要だ。だが、戦略ではない。「世界中の人々に幸せを届ける」。美しいパーパスだ。では、どうやって届けるのか。それが戦略だ。パーパスは方向を示す。道を示すのは戦略だ。多くの企業が、パーパスを掲げて満足してしまう。具体的に何をするのかは、曖昧なままだ。これは、戦略の放棄だ。難しい選択から逃げているだけだ。
これは事業側の話だけではない。技術側にも同じ罠がある。「技術負債をなくす」「きれいなアーキテクチャにする」「開発者体験を向上させる」。美しい技術パーパスだ。しかし、具体的にどの負債を、いつまでに、どうやって返すのか。何を「きれい」と定義し、どの部分から手をつけるのか。開発者体験のどの側面を、どの程度まで改善するのか。それが示されていなければ、技術パーパスもまた、戦略ではない。事業側であれ技術側であれ、パーパスごっこに陥りやすい。美しい言葉を掲げて、具体的な選択から逃げる。
私自身、「解決可能な最重要課題」を1つだけ挙げろと言われると、考え込んでしまうことがある。なぜそれが「最重要」だと言えるのか。即答できない時、見極めができていないと気づく。
戦略はストーリーである
ここまで、戦略の「内容」について語ってきた。何を解決するか。どこに集中するか。これが内容だ。次は、戦略の「形」について考えよう。同じ内容でも、伝え方によって実行力が変わる。バラバラの施策として並べるか、一貫したストーリーとして語るか。この違いが、戦略の成否を分ける。良い戦略は、施策ではなくストーリーだ。ストーリーとは何か。物語だ。因果の連鎖だ。「AだからB、BだからC、CだからD」という流れだ。良い戦略は、この流れがある。個々の施策が、バラバラに存在するのではない。互いに補強し合っている。前の手が、次の手を可能にする。次の手が、前の手の効果を高める。
プロダクト開発で考えてみよう。「このアーキテクチャにしたからこそ、新機能の実験が低コストで回せる」。「このモジュール分割をしておくから、将来の料金プランのバリエーションを増やせる」。「このAPIの設計にしたから、パートナー連携がスムーズにできる」。コードの書き方と、事業側の選択肢が、一本の物語になっているかどうか。技術的な決定が、事業の可能性を広げている。事業の方向性が、技術的な決定を正当化している。この双方向のつながりがあるかどうか。それが、技術戦略がストーリーになっているかどうかの分かれ目だ。
逆に、悪い戦略には、ストーリーがない。「我々は、高品質な商品を、低価格で、迅速に提供します」。一見、良さそうだ。でも、これはストーリーではない。施策の羅列だ。高品質と低価格は矛盾する。高品質にはコストがかかり、低価格にするにはコストを削る。迅速さも、品質と矛盾することが多い。これらの施策は、互いに補強し合っていない。むしろ、打ち消し合っている。因果の連鎖がないから、実行できない。
なぜ、こうなるのか。多くの場合、「あれもこれも」と欲張るからだ。高品質が欲しい。低価格だって欲しい。迅速さまで欲しい。全部欲しい。でも、全部は取れない。ストーリーを一貫させるには、「これ一本」が必要になる。何かを選び、何かを捨てる。
この「これ一本」の考え方は、企業の戦略だけでなく、チームや個人にも当てはまる。私が特に強く感じるのは、専業性の強さだ。
誤解のないように言えば、多角化がつねに悪いわけではない。あるプラットフォームチームは、CI/CDパイプラインの整備から始まり、監視基盤、セキュリティスキャン、開発者ポータルへと領域を広げた。別のチームは、Kubernetesクラスタの運用から、GitOpsの導入、Terraformによるインフラ管理、コスト最適化へと拡張した。これは成功した多角化だ。しかし、共通するのは、核となる強みから派生して広がったことだ。前者は「開発者体験の向上」を軸に広がった。後者は「セルフサービス化による開発者の自律性」を軸に広がった。つまり、多角化と専業性は二項対立ではない。「何を軸にするか」が明確かどうかが分かれ目だ。
問題なのは、軸のない多角化だ。「他のチームがやっているから自分たちも」「とりあえずKubernetesを入れよう」。このタイプの多角化は、リソースを分散させ、どの領域も「そこそこ」にしてしまう。専業的なチームが強いのは、専業だからではない。1つのことを徹底的に掘り下げているからだ。多角化していても、軸が明確で、そこを徹底的に掘り下げているチームは強い。
チームの話をしてきたが、これは個人のキャリアにも当てはまる。私は、エンジニアとして働いている。プログラミングができる。インフラも分かる。データベースも触れる。フロントエンドもできる。「フルスタックエンジニア」という肩書きを持っている。しかし、あるとき気づいた。私は、多くのことを「そこそこ」できる。ただ、何1つ「徹底的に」できない。専門性がない。深さがない。だから、代替可能だ。誰かが、私より少し上手にできる。常に、そういう誰かがいる。専業性。1つのことを、徹底的に掘る。それが、競争優位の源泉だ。
もしあなたが「何でもそこそこできる人」なのであれば、それをどうポジショニングするのかも戦略だ。「何でも屋」として埋もれるのか、「事業と技術をつなぐ翻訳者」として立つのか。どちらを選ぶかは、「何をやらないか」の選択だ。翻訳者として立つなら、深い専門性を追求することは諦める。代わりに、異なる専門性を持つ人々の間を橋渡しする能力を磨く。これも戦略的な選択だ。
私自身、この問いを自分に向けることがある。戦略を説明する時、ストーリーになっているか。キーワードの寄せ集めか。専業性があるのか、何でもそこそこなのか。流されてそうなっているだけではないか。答えは、いつも曖昧だ。明確に「できている」とは言えない。ただ、問い続けること自体に意味があると思っている。
まだ顧客ではない人を見つける
あるとき、プラットフォームチームのダッシュボードを眺めていて、違和感を覚えた。利用者数が伸びていない。一方で、既存ユーザーからの機能要望は山のように来ている。私たちは、その要望に応え続けていた。新機能を追加した。ドキュメントを充実させた。既存ユーザーは喜んだ。しかし、利用者数は変わらなかった。何かがおかしい。ふと疑問が浮かんだ。「使っていない人は、なぜ使っていないのか」。私たちは、その問いを持っていなかった。
ここまで、戦略の「何を」「どう」の話をしてきた。次は、「誰に」の話だ。戦略を考える時、私たちは既存の顧客ばかり見てしまう。「この機能がほしい」「ここが使いにくい」。フィードバックは大事だ。ただ、本当の成長機会は、別のところにあることが多い。本当の顧客は、まだ顧客ではない。
「まだ顧客ではない人」とは、ただ「使っていない人」ではない。彼らは、その機能を必要としていないのではない。「高すぎる」「難しすぎる」「面倒くさすぎる」など、どこかでバリアに引っかかっている。価格のバリア。複雑さのバリア。心理的なバリア。面倒くささのバリア。どのバリアが最も高いのかを見極め、それを下げる。これが、潜在顧客へのアプローチだ。
私が関わったあるプラットフォームエンジニアリングのプロジェクトでは、社内の開発者向けに整備したCI/CDパイプラインやKubernetesクラスタが、なかなか使われない問題があった。機能を追加しても、ドキュメントを増やしても、利用率は上がらなかった。調べてみると、問題は別のところにあった。「初期設定が面倒」。パイプラインの機能は十分だった。ただ、自分のプロジェクトに適用するには、YAMLを何十行も書き、権限設定を複数箇所で行う必要があった。これがバリアだった。テンプレートを用意し、3つの質問に答えるだけで初期設定が完了するCLIツールを作った。利用率は上がった。機能の問題でも、ドキュメントの問題でもなかった。面倒くささのバリアだった。
別の例を挙げよう。ある組織で、SREチームの構築した本格的な開発者プラットフォームがあったとする。Kubernetesクラスタ、Terraformによるインフラ管理、Prometheusによる監視、ArgoCD によるGitOps。高機能で、クラウドネイティブな開発には必須の基盤だ。ただ、使いこなすにはKubernetesの知識が必要で、YAMLの書き方を理解し、GitOpsのワークフローに慣れなければならない。
このプラットフォームの「まだ顧客ではない人」は誰か。入社したばかりの新人エンジニアだ。別チームから異動してきたバックエンドエンジニアだ。彼らも同じ課題を抱えている。「自分のアプリケーションを安定して動かしたい」という同じ「進歩」を求めている。ただ、学習コストが高すぎる。複雑すぎる。だから、ローカル環境や古いVMで我慢している。
ここで、セルフサービスポータルが登場したとする。Webの画面でアプリ名と言語を選ぶだけ。裏側ではKubernetesが動いているが、ユーザーはそれを意識しなくていい。すると、今までプラットフォームを使っていなかった新人や他チームのエンジニアが、ユーザーになる。使っているうちに理解が深まり、もっと高度なカスタマイズがしたくなる。直接YAMLを書くようになる。「まだユーザーではない人」が、ユーザーになる。そして、成長とともにプラットフォームのパワーユーザーになる。
重要なのは、「機能を削った劣化版」を作ることではない。「まだ顧客ではない人」が抱えているバリアを特定し、そのバリアを下げることだ。価格がバリアなら、価格を下げる。複雑さがバリアなら、シンプルにする。心理的なハードルがバリアなら、入口を低くする。どのバリアが最も高いかを見誤ると、的外れな施策になる。
「まだ顧客ではない人」を見つけて、バリアを下げる。この視点は、開発のやり方そのものを変える。
開発には2つのアプローチがある。1つは「押しつけ」型だ。上から降りてきた仕様をそのまま実装する。なぜこの機能が必要なのか。誰のどんな課題を解決するのか。それが見えないまま、言われた通りに作る。すると、何が起きるか。作ったものが使われない。ユーザーが喜ばない。現場のモチベーションが下がる。
もう1つは「引き寄せ」型だ。ユーザーの「本当に欲しい進歩」を理解する。そこから逆算して、仕様を決める。機能がユーザーのニーズに「引き寄せられている」状態だ。「まだ顧客ではない人」を見つけ、彼らのバリアを理解し、そこから仕様を導く。これこそが、戦略と開発が噛み合っている状態だ。
私自身、「まだ顧客ではない人」を見落としていることに気づくことがある。既存ユーザーの声ばかり聞いて、「まだ使っていない人」のことを考えていない。彼らは何を求めているのか。何がバリアになっているのか。この視点を持つだけで、見える景色が変わる。
ここで、1つ問いを立てたい。「まだ顧客ではない人」を見つけるのは、誰の仕事だろうか。マーケティング部門の仕事だと思われがちだ。しかし、現場こそ、潜在顧客のバリアを理解できる独自の視点を持っている。
セールスは「買わない理由」を知っている。CSは「使い続けない理由」を知っている。そしてエンジニアは、バリアの多くが技術的な問題であることを知っている。「設定が複雑すぎる」。これは技術で解決できる。「動作が遅すぎる」。これも技術で解決できる。「他のツールと連携できない」。これも技術で解決できる。マーケティング部門は「バリアがある」と気づくことはできる。だが、「そのバリアをどう下げるか」を具体的に設計できるのは、現場だ。
ここまで読むと、「現場が重要だ」という話に聞こえる。確かにそうだ。ただ、もう1つ、見落としがちな点がある。現場が価値を発揮できるのは、ある条件が揃っている時だけだ。
その条件とは、制約だ。制約がなければ、現場は潜在顧客について何も語れない。逆説的に聞こえるだろう。説明しよう。
どういうことか。もしリソースに何の制約もなければ、「全部やればいい」で終わる。高速にする。簡単にする。安くする。連携できるようにする。全部やる。それで解決だ。でも、現実にはリソースは有限だ。時間も、人も、予算も。だから、「どのバリアを下げるか」を選ばなければならない。
この「選ぶ」という行為において、現場の知見が活きる。エンジニアなら「このバリアを下げるには3ヶ月かかる。でも、こっちのバリアなら1週間で下げられる」と判断できる。セールスなら「このバリアを下げれば、商談の成約率が上がる」と判断できる。制約があるからこそ、優先順位が生まれる。優先順位があるからこそ、戦略が必要になる。制約こそが、現場の貢献を可能にしている。
つまり、「まだ顧客ではない人」を見つけて、そのバリアを下げる方法を提案すること。これは、現場ができる最大の「事業への貢献」の1つだ。指示を待つだけの現場には、この貢献はできない。「誰が使っていないのか」「なぜ使っていないのか」「どうすれば使えるようになるのか」。そして、「限られたリソースで、どのバリアから下げるべきか」。この問いを持つ現場だけが、事業の成長に直接貢献できる。
理論と実践の間で
ここまで、戦略について語ってきた。核心的な課題を見極めること。ストーリーとしての一貫性。専業性の強さ。「まだ顧客ではない人」という視点。これらの考え方は、理解できる。頭では分かる。しかし、1つ重要な疑問が残る。これらの考え方を、どう使えばいいのか。正直に言えば、私はエンジニアだ。設計パターンやアーキテクチャの本を何冊も読んできた。ドメイン駆動設計。クリーンアーキテクチャ。マイクロサービス。モジュラーモノリス。どれも「ソフトウェアをどう構造化するか」についての理論だ。複雑さをどう分割するか。変更をどう局所化するか。チーム間の依存をどう減らすか。これらの理論や仕組みについて、語ることはできる。だが、それを自分のプロジェクトに適用できるかは、別の話だ。どの理論が自分たちの状況に適用可能なのか。どのパターンが今の組織規模とスキルセットに合っているのか。それを判断するには、理論を超えた洞察が必要だ。理論を語れることと、戦略を立てられることは、別だ。
ただ、「戦略を語れない」ことと「戦略を実行できない」ことは、同じだろうか。私は「戦略を語れ」と言っている。しかし、語れることと実行できることは別だ。美しい戦略を語れても、実行できなければ意味がない。逆に、言葉にできなくても、体で分かっている人もいる。私は、どちらだろうか。語れるけど実行できないのか。実行できるけど語れないのか。それとも、どちらもできていないのか。正直に言えば、分からない。
理論は、現実を説明する。「なぜこうなったのか」を教えてくれる。しかし、「どうすればいいのか」は教えてくれない。マイクロサービスアーキテクチャは、システムを小さな独立したサービスに分割する手法だ。各チームが自分のサービスを独立してデプロイできる。大規模組織では強力だ。ただ、5人のチームで導入すべきか。サービス間の通信、障害の伝播、デバッグの難しさ。小さなチームには重荷になる。モノリスのままでいいのか。将来の拡張性は諦めるのか。ドメイン駆動設計は、複雑なビジネスロジックを「境界づけられたコンテキスト」で整理する手法だ。だが、今のプロジェクトは、本当にそこまで複雑か。学習コストに見合う複雑さがあるのか。それを判断するには、理論を超えた洞察が必要だ。理論は、説明する。しかし、処方箋は出さない。
これは、理論の限界だ。いや、限界というより、理論というものの性質だ。理論は、世界を理解するためのツールだ。世界を変えるためのツールではない。理論には、必ず適用範囲がある。マイクロサービスは、組織がスケールしている時に有効だ。ただ、チームが小さい時は、むしろ足かせになる。クリーンアーキテクチャは、ビジネスロジックを外部依存から切り離す設計思想だ。データベースやフレームワークを後から差し替えられる。長期保守が前提のプロダクトでは有効だ。一方、3ヶ月で検証して捨てるプロトタイプでは、過剰投資になる。テスト駆動開発は、テストを先に書き、そのテストを通すコードを後から書く手法だ。仕様が明確な時に有効だ。けれど、何を作るか探索している段階では、テストが足かせになることもある。つまり、理論を使うには、まず「どの理論が適用可能か」を判断しなければならない。だが、それを判断するには、理論を超えた洞察が必要だ。これは、逆説だ。理論を使うために、理論を超えた何かが必要だ。その「何か」とは何か。経験だ。直感だ。センスだ。
結局、理論は、センスの補助線に過ぎない。センスのある人が理論を使えば、より深く考えられる。一方、センスのない人は理論だけに頼っても、何もできない。
では、センスはどう磨くのか。「経験を積め」では答えになっていない。私なりに考えた方法を3つ挙げる。
第一に、「判断の言語化」を習慣にする。何かを決めた時、なぜその判断をしたのかを書き残す。1ヶ月後、3ヶ月後に振り返る。当時の判断は正しかったか。何を見落としていたか。この繰り返しが、判断の精度を上げる。
第二に、「他者の判断を追体験する」。本を読む時、著者がなぜその結論に至ったかを考える。「自分ならどう判断したか」を先に考えてから、著者の結論を読む。このギャップが学びになる。成功事例だけでなく、失敗事例を読むことも重要だ。
第三に、「小さな賭けを繰り返す」。大きな戦略を立てる機会は少ない。ただ、小さな判断は毎日ある。「このタスクを先にやるか、後にやるか」「この機能を入れるか、外すか」。この小さな判断を意識的に行い、結果を観察する。センスは、大きな決断ではなく、小さな判断の積み重ねで磨かれる。
センスは才能ではない、と私は思う。観察と振り返りの習慣なのではないか。
私自身、この「センス」の不足を痛感したことがある。プラットフォームエンジニアとして「開発者体験を向上させるべきだ」と理論を実践しようとした。ツールのドキュメントを整備し、社内ドキュメントにまとめて共有した。ところが、利用率は変わらなかった。理論を機械的に適用したからだ。開発者体験は、ドキュメントだけでは向上しない。開発者が実際につまずく瞬間を観察する必要がある。「困ったらあの人に聞こう」と思われるプラットフォームチームが必要だ。これは信頼関係であり、組織文化だ。理論の外にある領域だが、理論を機能させるには不可欠だ。理論と実践の間には、常にギャップがある。理論は一般化された知識だ。実践は個別の状況だ。一般を個別に適用する翻訳こそが、実践者のスキルだ。
だから、私は「この技術を使うべきか」と聞かれた時、即答しない。「チームの規模は」「プロダクトのフェーズは」「今の技術的負債はどこにある」と聞き返す。理論を適用する前に、文脈を理解しなければならない。文脈なき理論の適用は、害にすらなる。
私はエンジニアだ。だから、目の前の現実と向き合うしかなかった。うまくいかないことを何度も経験した。その度に、なぜうまくいかなかったのかを考えた。理論を読み、現実と照らし合わせ、自分なりの理解を深めていった。この捻り出した思考は、今、個人やチームの戦略を立てる時に役立っている。理論を知っている。ただ、理論に頼りすぎない。現場を見る。人を見る。文脈を理解する。その状況に合った答えを探す。これが、実践者の仕事だ。小さな適応範囲なら、語れる。自分のチームで、どういう問題があって、どう解決しようとしたか。何がうまくいって、何がうまくいかなかったか。次はどうするか。この小さな範囲での試行錯誤が、戦略を立てる力を育てる。
しかし、この「小さな適応範囲」の中には、純粋な技術領域だけでなく、事業寄りの判断もじわじわと入り込んでくる。「プロダクトのどこにリソースを割くか」「どの顧客セグメントに寄せるか」「この機能を今作るか、後で作るか」。これは、技術的な判断に見えて、実は事業の方向性に関わる判断だ。技術の現場にいながら、事業の戦略にも口を出すことになる。
企業全体の戦略を立てることは、私にはできない。立場も違う。経験も足りない。だが、自分の責任範囲では、できる。自分のチームでは、できる。個人の仕事では、できる。この小さな範囲での実践こそが、本当の学びになる。理論を読むことは、重要だ。ただ、理論を読んだだけでは、何も変わらない。理論を使って、現場で試す。失敗する。振り返る。この繰り返しの中でしか、戦略を立てる力は身につかない。
私自身、「戦略と言いながら、実は何も捨てていない」ものに関わってきた。理論やフレームワークを「そのまま」適用して、うまくいかなかったことも多い。足りなかったのは、現場の事情への理解だった。人の感情への配慮だった。
技術戦略と事業戦略の距離を縮める
ここまで、戦略を立てる「個人」の話をしてきた。だが、戦略は組織の中で機能する。特にエンジニアとして気になるのは、技術戦略と事業戦略の関係だ。
長いあいだ、自分の中に「事業戦略→技術戦略」という一方向の矢印があった。事業側が「何を作るか」を決め、技術側は「どう作るか」を決める。経営が方向を決めて、エンジニアはそれを実装する。この一方向依存のメンタルモデルは、長らく私の中に染みついていた。
しかし、現実には、「どう作るか」が「何ができるか」を大きく変える。変更コストの低いアーキテクチャだから、競合が半年かかる機能を1ヶ月で検証できる。このモジュールの切り方にしておくから、「この部分だけを切り出して別料金プランにする」という事業のオプションが生まれる。このAPIの設計にしておくから、将来のパートナー連携がスムーズにいく。技術戦略は、事業の選択肢を増やす。事業戦略から技術戦略への一方向ではなく、双方向の依存関係がある。技術が事業を制約することもあれば、技術が事業の可能性を広げることもある。
この双方向性を理解すると、開発現場で起きる摩擦の見え方が変わる。技術的チャレンジは、想定外の遅延や不具合を生む。これを「技術の問題」として閉じてしまうと、現場は追い詰められる。「なんとかしろ」という圧力だけがかかる。しかし、技術的な課題を「事業戦略を動かす材料」として扱うと、話が変わる。「この技術的な制約があるなら、ローンチ時期をずらすか」。「このリスクがあるなら、この機能は一旦やめて、こっちの顧客セグメントを先に取るか」。技術の現場からの情報が、事業側の判断材料になる。不確実性を飼いならすための対話が生まれる。
エンジニアだけでなく、デザイナー、PdM、ドメインエキスパートも同じだ。現場でプロダクトの手触りを一番知っている人たちが、事業戦略の「定数」ではなく「変数」をいじれる立場になっていい。「この仕様だとユーザーは混乱する」というデザイナーの声。「この機能は、実はこの顧客セグメントには刺さらない」というPdMの洞察。「この業界の慣習を考えると、この方向は難しい」というドメインエキスパートの知見。これは、事業戦略を修正するクリティカルなインプットだ。越権行為ではない。むしろ、健康な組織の姿だ。
ここまで、技術と事業の対話について語ってきた。対話の相手は人間を想定してきた。しかし最近、対話の相手が変わりつつある。AIを戦略の壁打ち相手にする場面が増えた。試しにAIへ聞いてみたことがある。「戦略を考えてください」。出てきた答えは、驚くほど整っていた。SWOT分析。ファイブフォース分析。「デジタルチャネルの強化」「顧客体験の向上」といった施策。ロジックも通っている。
これは、先ほど述べた「理論の限界」と同じ構造だ。AIは理論を適用できる。分析もできる。ただ、「どの理論が今の状況に適用可能か」を判断するのは、AIではなく人間だ。そして、最後に「これでいく」と賭けるのも人間だ。
技術戦略と事業戦略の対話において、AIは優秀な壁打ち相手になる。「この技術的制約がある時、事業戦略はどう変わりうるか」と問えば、選択肢を整理してくれる。ただ、その選択肢の中からどれを選ぶかは、現場を知り、責任を負う人間が決める。これは、技術と事業の対話が人間同士であるべき理由と、根は同じだ。
私自身、「本当はもっとこうすれば速く進めるのに」と感じることがある。技術の現場から見えている事業の可能性。それを戦略の議論にインプットしようとしたことはある。うまくいった時もあれば、スルーされた時もある。それでも、言い続けることに意味があると思っている。
現場こそが仮説を持つべきだ
ここまで、戦略について語ってきた。しかし、1つ疑問が残るだろう。現場の人間は、そもそも戦略なんて考える必要があるのか。与えられた目標を追いかけ、仕様通りに実装するのが仕事ではないのか。
私の答えは明確だ。現場こそ、仮説を持つべきだ。エンジニアも、デザイナーも、セールスも、CSもだ。現場は、ビジネスの「手触り」を最も知っている立場だからだ。
エンジニアは、プロダクトの構造的な手触りを知っている。「この機能は技術的に難しい」「ここがボトルネックになる」。これはコードを書く人間にしか分からない。同様に、セールスは顧客の「断る理由」の手触りを知っている。CSはユーザーが「つまづく瞬間」の手触りを知っている。本部で数字をこねくり回している時には見えない「事実の断片」を、現場は握っている。
この手触りを「仮説」に昇華できた時、現場は戦略を変える力を持つ。
たとえば、カスタマーサクセス（CS）。彼らは日々、「解約」という事実に直面する。戦略のないCSは、解約阻止のマニュアル通りに動き、ダメなら「顧客の事情」として処理する。しかし、仮説を持つCSは問う。「なぜ、このタイミングで解約するのか」。彼らは気づく。「機能不足ではなく、オンボーディングの3日目に発生する『設定の面倒さ』に心が折れているのではないか」。この仮説があれば、開発チームに「新機能より設定ウィザードの改善を」と要求できる。それは単なるクレーム処理ではない。立派な「チャーン（解約）阻止戦略」だ。
たとえば、セールス。「価格が高いと言われました」と報告するだけなら、誰でもできる。AIでも集計できる。しかし、仮説を持つセールスは考える。「高いと言われるのは、価値が伝わっていないからか、それとも比較対象が間違っているからか」。もし顧客が、競合他社のツールではなく、Excelと比較して「高い」と言っているなら、戦い方は変わる。機能の多さをアピールするのではなく、「手入力のコスト」を訴求すべきだ。その気づきは、マーケティング戦略やプライシング戦略を根底から覆す可能性がある。
仮説を持たない現場は、ただの「手足」になる。言われた通りに作り、言われた通りに売る。なぜやるのかは考えない。楽だが、キャリアとしては危うい。「言われたことを正確にやる」だけなら、代替可能だからだ。
一方、仮説を持つ現場は、戦略の「センサー」になる。「本社が考えている戦略は、現場感覚とズレているぞ」と気づける。そのズレを言語化し、フィードバックする。時にそれは、経営陣にとって不都合な真実だろう。「今の売り方では絶対に売れない」「この機能は誰も使わない」。しかし、その不都合な真実こそが、組織を救う。
仮説を持つことの有用性は、職種を問わず共通している。
第一に、学習速度が上がる。仮説を持っていると、結果との差分が学びになる。「このトークなら刺さるはずだ」と思っていたことが、刺さらなかった。このギャップが、次の商談の精度を上げる。仮説がなければ、何が起きても「そんなものか」で終わる。
第二に、議論に参加できる。仮説を持っていれば、それをぶつけることができる。「開発側はこう見ていますが、セールス側はどうですか」と問える。これは、単なる状況確認ではない。お互いの「手触り」を照らし合わせる行為だ。この対話の中で、事業の解像度が上がる。
第三に、主体性が生まれる。仮説を持つと、「自分ごと」になる。この仮説が正しいかどうか、確かめたくなる。うまくいけば嬉しいし、間違っていれば悔しい。この感情が、仕事へのコミットメントを高める。
私はエンジニアだ。だからコードを通じて事業を見る。セールスは対話を通じて、デザイナーは体験を通じて事業を見る。それぞれの「現場」からしか見えない景色がある。その景色を「仮説」という形にしてテーブルに乗せること。それが、私たちが戦略に参加する唯一の方法だ。
現場は、戦略の「消費者」ではない。戦略の「参加者」になれる。そのためには、仮説を持つこと。問いを持つこと。それを声に出すこと。これが、現場と経営の距離、技術と事業の距離を縮める第一歩だ。
戦略を語れ、責任を持って
ここまで、戦略について長々と語ってきた。最後に、個人的な話をしたい。
あの会議から、数年が経った。今も、お手伝いしてきた会社で、技術顧問として経営者たちと話をすることがある。会議で、誰かが「戦略」という言葉を使う。相変わらず、中身のない戦略が語られる。正直に言えば、私はそこで「それは戦略ですか」とは言えない。言えなかった。なぜなら、それは私の仕事の範疇を超えているからだ。技術顧問として呼ばれている。システムのアーキテクチャについて助言する立場だ。経営戦略に口を出すのは、越権行為だ。それでも、心のどこかで引っかかっている。本当に必要な場面であれば、立場を超えてでも言うべきではないのか。会社が明らかに間違った方向に進もうとしている時。誰も指摘しない時。そういう時こそ、言うべきではないのか。だが、言わない。言えない。その境界線がどこにあるのか、自分でもわからない。
だから、内心では思っている。「その戦略で、どんな問題を解決するのか」。「その問題は、本当に最も重要な問題なのか」。「なぜ、その解決策なのか」。「他の選択肢は、検討したのか」。「何を捨てたのか」。これらの疑問が、頭の中を巡る。だが、口には出さない。出せない。立場が違う。責任の範囲が違う。その代わり、私は慎重に言葉を選ぶ。技術的な観点から、問いを投げかける。「その施策を実現するには、どんな技術的な課題がありますか」。「優先順位をつけるとしたら、どの順番で進めますか」。「リソースの制約を考えると、何かを諦める必要がありませんか」。気を使いながら、遠回しに。それでも、核心を突く問いを。これらの質問は、時に受け入れられる。時に、無視される。経営陣は、自分たちの「戦略」を語り続ける。
ただ、不思議なことに、この経験が無駄になることはなかった。経営会議で言えなかったこと。内心で感じていたこと。絞り出した思考。気を使って口に出した言葉。すべて蓄積されていった。自分のチームを持った時、個人として仕事をする時、この経験が役に立った。エンジニアリングチームの方向性を決める時。技術的な選択をする時。プロジェクトの優先順位を決める時。そこでは、私は問うことができた。「この取り組みで、何を解決するのか」。「本当に、それが最も重要な課題なのか」。「なぜ、この方法なのか」。「他にやり方はないのか」。「何を捨てるのか」。チームメンバーと話す。一対一で。ホワイトボードの前で。Slackで。経営会議とは違う。ここでは、私が責任を持てる。私の範疇だ。だから、問える。
そして、気づいた。戦略は、スケールの問題ではない。企業全体の戦略でも、チームの戦略でも、個人の戦略でも、根っこは同じだ。核心的な課題を見極める。解決策を見つける。何かを捨てる。実行する。経営会議で見てきた「戦略ごっこ」。あれを、自分のチームでは繰り返さない。そう決めた。チームの目標を立てる時。「全部やる」とは言わない。「これをやる。これはやらない」と明確にする。新しい技術を導入する時。「なんとなく良さそう」では進めない。「どの問題を解決するのか」を明確にする。プロジェクトの優先順位を決める時。「全部重要」とは言わない。「これが最重要。他は後回し」と決める。これは、不快だ。チームメンバーから反発されることもある。「なぜ、私のタスクは優先されないのか」。「なぜ、この技術は使わないのか」。それでも、説明する。なぜその判断をしたのか。何を最優先にしたのか。何を捨てたのか。時に、判断が間違っていることもある。やってみて、うまくいかない。その時は、認める。修正する。
ただ、少なくとも、判断はしている。選択はしている。「全部やる」という逃げ方はしていない。これが、私なりの戦略だ。企業全体ではない。自分の責任範囲での戦略だ。それで十分だ。いや、それこそが核心だ。
ただ、「小さな戦略で十分だ」と言っているが、それは「逃げ」ではないか。本当は、もっと大きな影響力を持ちたいのに、怖くて小さな範囲に留まっているだけだろう。「小さな戦略」という言葉で、自分の臆病さを正当化しているだけだろう。
逆も考えられる。大きな戦略を語りたがる人の中には、目の前の小さな選択から逃げている人もいる。抽象的な「ビジョン」を語ることで、具体的な「何を捨てるか」から逃げている人。私は、少なくともそうはなりたくない。だから、小さな範囲でもいいから、選択し続ける。それが「逃げ」かどうかは、結果が教えてくれるだろう。
戦略を立てるスキルは、3つの要素で形成される。第一に、本当に重要なものとそうでないものを見極める能力。第二に、その重要な問題が手持ちのリソースで解決可能かを判断する能力。第三に、リソースを集中投入する決断を下す能力。見極める。判断する。決断する。フレームワークでは学べない。理論でも教えられない。AIにも任せられない。では、どうやって身につけるのか。経験だ。失敗だ。振り返りだ。そして、自分の責任範囲で実践することだ。経営会議では言えなくても、自分のチームでは実践できる。そこで、何度も試す。何度も失敗する。何度も学ぶ。
数年間、何度も失敗した。ある時、プラットフォームエンジニアとして、CI/CDパイプラインの刷新を提案した。分析は完璧だった。ビルド時間の短縮率も、デプロイ頻度の改善予測も計算した。しかし、導入されなかった。なぜなら、開発チームの理解が得られなかったからだ。彼らは、新しいパイプラインを信じていなかった。今のJenkinsで十分だと思っていた。彼らの視点を理解していなかった。だから、提案は受け入れられなかった。別の時、Kubernetesへの移行について相談された。コスト分析も、リスク分析も、移行計画も、調べて用意した。しかし、実行されなかった。なぜなら、組織がリスクを取れなかったからだ。今の運用で手一杯だった。新しい基盤に投資する余裕がなかった。組織の状況を理解していなかった。だから、提案は棚上げされた。自分のチームでも失敗した。開発者プラットフォームの改善プログラムを進めようとした。どこを改善すれば、どれだけ効果が出るか、細かく計算した。しかし、実行は中途半端に終わった。なぜなら、改善すべきものを明確にしなかったからだ。「全体的に改善しましょう」と言った。結果、誰もが「自分のところは変えなくていい」と思った。中途半端に変えて、効果も中途半端だった。選択する勇気がなかった。だから、失敗した。
これらの失敗から、私は学んだ。戦略は、論理だけでは動かない。人を動かさなければならない。人を動かすには、彼らの視点を理解しなければならない。彼らの懸念を理解しなければならない。彼らの制約を理解しなければならない。戦略は、分析だけでは生まれない。判断が必要だ。「これが最重要だ」という判断。「これは捨てる」という判断。判断には、勇気が必要だ。間違うだろう恐怖と向き合う勇気が。戦略は、計画だけでは実現しない。実行が必要だ。実行には、コミットメントが必要だ。「これをやり遂げる」というコミットメント。困難に直面しても、諦めないコミットメント。論理。判断。コミットメント。この三つが揃って、初めて戦略は機能する。そして、これは、本を読むだけでは身につかない。理論を学ぶだけでは得られない。AIに聞いても教えてくれない。現場で、実際に戦略を作る。実行する。失敗する。振り返る。この繰り返しの中でしか、身につかない。
経営は、科学ではない。人に依る。
どれだけ理論を学んでも、どれだけデータを分析しても、最後は人の判断だ。その人が、どう見るか。どう感じるか。どう決めるか。そして、その判断は、再現性が低い。同じ状況でも、違う人なら、違う判断をする。同じ人でも、違うタイミングなら、違う判断をする。だから、経営には「正解」がない。あるのは、「その時、その人が、最善だと信じた選択」だけだ。これは、不安だ。頼りない。でも、これが現実だ。
戦略を語る人は、多い。でも、戦略を作る人は、少ない。戦略を作ることは、快適ではないからだ。答えのない問いと向き合う。対立を引き受ける。リスクを負う。責任を取る。だからこそ、「語れ」と言いたい。しかし、責任を持って。美しい言葉を並べるだけではなく。フレームワークを使って終わりではなく。スライドを作って満足するのではなく。本当の戦略は、もっと地味だ。もっと泥臭い。現場を見る。数字を見る。人と話す。何度も考える。何度も見直す。何度も修正する。そして、決める。やると決める。やらないと決める。これが、戦略だ。企業全体の戦略を作ることは、私にはできない。立場が違う。責任の範囲が違う。でも、自分の責任範囲では、できる。そして、それで十分だ。小さな範囲でも、根っこは同じだからだ。問題を見極める。解決策を見つける。選択する。実行する。これができれば、それは戦略だ。
私自身、最近やったことがある。自分の「責任範囲」で、今週中にやめると決められることを1つだけ、紙に書き出した。それをやめることで、どんなリソースが解放されるか考えた。そして、「戦略」という言葉を使わずに、これから1年の方針を「問題→選択→行動」の3行で書いてみた。書けた時、少しだけ、戦略を作る側に立てた気がした。
そして、もう1つ。声に出すことの価値について。
私は長いあいだ、「立場を超えて意見するのは越権行為だ」と思っていた。技術顧問は技術のことだけ言えばいい。経営戦略に口を出すのは筋違いだ。そう思っていた。でも、最近は少し考えが変わった。
黙っていても、組織が良くなることはない。「これ、おかしいのではないか」と感じた時、黙っていれば波風が立たない。ただ、波風を立てないことと、組織を良くすることは別だ。誰かが声を上げなければ、おかしいことはおかしいままだ。
もちろん、声の上げ方は重要だ。対立を煽る言い方ではなく、建設的な問いかけとして。「これは戦略ですか」と詰問するのではなく、「この戦略で解決したい最重要課題は何ですか」と問う。相手を追い詰めるのではなく、一緒に考える姿勢で。
「おい、戦略を語れ」。
このタイトルには、怒りがある。「おい」という呼びかけには、苛立ちがある。会議で空虚な戦略を語る人たちへの怒り。それもある。しかし、正直に言えば、怒りの多くは自分に向いている。かつての自分も、同じことをしていたから。今でも、完璧にはできていないから。「戦略を語れ」と他人に言いながら、自分は語れているのか。
この怒りの裏には、期待がある。もっとうまくやれるはずだ、という期待。自分に対しても、組織に対しても。その期待が裏切られるたびに、怒りが生まれる。そして、その怒りを誰かにぶつけたくなる。「おい、戦略を語れ」と。しかし、怒りだけでは何も変わらない。怒りを、行動に変えなければならない。自分の責任範囲で、選択し続けること。声を上げ続けること。それが、怒りを建設的なものに変える唯一の方法だ。
だから、この言葉は、他人に向けているようで、実は自分に向けている。お前は本当に戦略を語れているのか。中身のない言葉を並べていないか。選択から逃げていないか。そう自分に問いかけている。
でも同時に、この言葉は、外に向けても発したい。会議で空虚な「戦略」が語られている時。誰もがうなずいているけれど、誰も本当には信じていない時。そういう時に、「それは本当に戦略ですか」と問いかける勇気を持ちたい。
声を上げることは、リスクだ。嫌われるだろう。場の空気を壊すだろう。「余計なことを言う奴」と思われるだろう。それでも、本当に重要なことは、声に出さなければ伝わらない。心の中で思っているだけでは、何も変わらない。
自分の責任範囲で戦略を実践すること。そして、必要な時には、声を上げること。この2つが揃って、初めて「戦略を語れ」というタイトルに応えられる気がする。
「それだけ」の難しさ
結局、戦略とは何なのか。長々と書いてきたが、煎じ詰めれば、やるべきことはシンプルだ。
核心的な課題を見極めているか、確認する。その課題を本当に解決できているか、問い続ける。妥協なく、選択と集中ができているか、点検する。うまくいっていないなら、うまくいきそうな方に舵を切る。それだけだ。
こう書くと、「そんなの当然だ」と感じるだろう。しかし、自分の仕事を振り返ってみてほしい。本当にこれができているだろうか。
「課題を見極めているか」を確認するとは、自分たちの判断を直視することだ。これは、自分たちの見立て違いや判断ミスと向き合うことでもある。誰だって、自分が間違っていたとは認めたくない。だから、別の指標を見てしまう。納期に間に合ったか、予算内に収まったか、上司に怒られなかったか。「核心を突けているか」ではなく、「うまくやり過ごせているか」を見てしまう。
仕事をしていると、いつの間にか「課題を解決する」という目的が薄れていく。たとえば、内部開発者プラットフォームの構築プロジェクト。最初は「開発者の生産性を上げる」という明確な目的があったはずだ。しかし、プロジェクトが進むにつれて、目的は変質していく。「Kubernetesクラスタを予定通りに構築する」「監視ツールを導入する」「経営層への報告をうまくまとめる」。気づけば、開発者が本当に使いやすいかどうかより、プロジェクトとして「成功」と言えるかどうかが関心事になっている。「課題を解決しているか」という問いは、常に意識しないと蒸発してしまう。なぜなら、その問いに向き合うのは苦しいからだ。解決できていないという不安と向き合わなければならない。
「妥協なく」という言葉も、簡単ではない。妥協は悪意からではなく、善意や現実主義から生まれる。「この機能、完璧ではないけど、ないよりましだろう」「全員が満足するものを作れないから、ある程度のところで折り合いをつけよう」「理想を追求していたら、いつまでも終わらない」。一見、成熟した判断に見える。しかし、この「妥協」が積み重なると、最後に出来上がるものが「そこそこ」になる。誰も強く不満を言わないが、強く満足する人もいない。一応使えるが、積極的に使いたいとは思わない。
「そこそこ」は、失敗より危険だ。失敗は直せる。「そこそこ」は直せない。明らかな失敗なら、原因を追求して改善できる。しかし「そこそこ」は改善の動機を奪う。「一応は使われている」「致命的な問題はない」という状態は、変化への意欲を殺す。その状態が何年も続いた先に、誰も欲しがらないが捨てることもできない、ゾンビのようなプロダクトやサービスが生まれる。
「うまくいっていないなら、舵を切る」。この言葉の中で、最も実行が難しいのはこの部分だろう。まず、「うまくいっていない」と認めることが難しい。これまでの努力を否定することになるからだ。「方向性は間違っていないが、やり方に問題があった」「もう少し続ければ成果が出る」と思いたい。次に、「うまくいきそうな方向」を見つけることが難しい。うまくいっていないことは分かっても、代わりにどうすればいいかは分からない。だから、現状維持を選んでしまう。少なくとも、今のやり方なら「最悪ではない」ことは分かっている。未知の方向に舵を切るのは、博打に見える。
では、この「それだけ」を実践するには何が必要なのか。
目的を見失わない仕組み。日常の作業に埋没すると、なぜこれをやっているのかを忘れる。定期的に、しかも形式的にではなく真剣に、「何のためにやっているのか」を問い直す機会が必要だ。週に一度でも、チームで「これは本当に問題を解決しているか」と話し合う。その習慣があるかないかで、結果は大きく変わる。
小さく試す文化。大きな賭けは、舵を切りにくくする。三年かけて作ったものを「やっぱりダメでした」とは言いにくい。しかし、二週間で作ったものなら、「これは違った、次を試そう」と言える。小さく作り、早く確認し、素早く方向修正する。このサイクルを速く回せる環境があれば、舵取りは格段に楽になる。
失敗を許容する空気。「うまくいっていない」と言えるかどうかは、それを言った時に何が起こるかで決まる。責められるなら、誰も言わない。隠す。ごまかす。「うまくいっていない」という報告が、責任追及ではなく改善の起点として扱われる組織でなければ、正直な確認はできない。
判断の軸を持つこと。舵を切る方向を決めるには、判断の軸が必要だ。「顧客の困りごとを減らす」「使う人の時間を節約する」「この体験を心地よくする」。何でもいい、しかし具体的で、検証可能な軸。それがあれば、「こっちの方がうまくいくだろう」という仮説を立てられる。軸がなければ、どこに舵を切っていいか分からない。
「それだけ」という言葉は、謙遜ではない。本当に、やるべきことはそれだけなのだ。作れているかを見る。問題を解決しているかを問う。妥協しない。確認し続ける。必要なら方向を変える。
しかし、この「それだけ」を本当に実践している組織やチームや個人は驚くほど少ない。私たちは目的を忘れ、妥協に流され、現実から目を逸らし、変化を恐れる。「それだけ」の中に、ものづくりの、いや、あらゆる仕事の核心がある。そして、その核心を貫くことの難しさと向き合い続けることが、良い仕事をするということなのだろう。
おわりに
ここまで読んでしまった人がいるとしたら、申し訳ない気持ちが少しある。
この文章を読んでも、明日から「戦略が立てられる人」にはならない。私自身がそうだったから分かる。本を読んだ直後は「分かった」と思う。会議で使えそうなフレーズをいくつかメモする。「核心的な課題を見極める」「何をやらないかを決める」。いい言葉だ。これを使えば、自分も戦略を語れる側の人間になれる気がする。
でも翌週、いざ自分の仕事で使おうとすると手が止まる。「で、何から始めるんだっけ」。頭の中でフレーズは踊っているのに、目の前の仕事にどう適用すればいいか分からない。結局、また賢そうな顔をして会議に座っている。何も変わっていない。
たぶん、戦略を立てる力は、戦略を立てることでしか身につかない。走り方の本を読んでも走れるようにならないのと同じだ。転んで、膝を擦りむいて、また走る。そうやってしか身につかない。身も蓋もないけど、そうとしか言いようがない。
だから、この文章には限界がある。読んだだけでは何も変わらない。でも、もしかしたら、何かが引っかかるかもしれない。次の会議で「戦略」という言葉を聞いた時、「それ、本当に戦略？」と心の中でツッコめるようになったら、それだけで意味がある。自分のチームの方向性を考える時に「で、何を捨てるの？」という問いが頭をよぎるようになったら、それで十分だ。その小さな引っかかりが、いつか行動に変わるかもしれない。変わらないかもしれない。でも、引っかかりがなければ、変わる可能性すらない。
正直に言えば、この文章は誰かのためというより、自分のために書いた。書きながら「お前、分かってないじゃん」と何度も思った。調べれば調べるほど、自分の理解の浅さが見えてくる。偉そうに「戦略とは何か」を語っているけど、じゃあお前は実践できているのか。そう問われたら、黙るしかない。
「おい、戦略を語れ」という怒りは、他人への苛立ちではなかった。鏡に映った自分への問いかけだった。語れているのか。実行できているのか。逃げていないか。分かったふりを続けていないか。その問いに、まだ答えられていない。
明日も会議がある。誰かが「戦略」と言うだろう。私はまた、眉間にしわを寄せて「なるほど」という顔をするだろう。それは変わらない。でも、今度は少しだけ、違う気持ちで聞けるかもしれない。「それ、本当に戦略？」と心の中で問いかけながら。その問いかけは、きっと会議室の誰かにではなく、自分自身に向けられている。
そう思えるだけで、この長い文章を書いた甲斐はあった。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
参考書籍
