「それは手段でしょ。目的は？」

バグの構造解析

2026.10.18 2026.09.29

「それは手段でしょ。目的は？」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。

よく見かける光景

ビジネスの世界で、必ずと言っていいほど直面する問題があります。「手段の目的化」です。

本来、設定された目的を達成するために手段を選んだはずなのに、いつの間にか「その手段を完璧に実行すること」自体が主目的になり、本来の納期や成果を見失ってしまう現象。

例えば

目的：「テストで点を取る」

手段：「参考書を読む」

だったはずが、いつの間にか「参考書を完璧に理解すること」が目的になってしまい、アウトプットの練習がおろそかになって点が取れない、といった事象です。

マネージャーやPMは、これを実行者（部下や外注）の「視野の狭さ」や「能力不足（バグ）」だと責めがちです。しかし、システムアーキテクチャの観点から見ると、これは実行者のバグではなく、設計者（指示出し側）の「要件定義の甘さ」が引き起こした必然的なエラーです。

なぜ、手段の目的化は起きるのか？

それは、「そもそも、手段とは目的化する性質を持つもの」だからです。

目的と手段は、絶対的なものではなく「入れ子（フラクタル）構造」になっています。上位概念の手段は、下位概念から見ると「目的」になります。

↓（階層を下る）

↓（階層を下る）

このように、システム上の変数を明確に定義しないまま、抽象的な手段（業務を効率化しろ）だけを部下に渡すとどうなるか。

優秀で真面目な実行者であればあるほど、その抽象的な手段を「自分にとっての絶対的な目的」として再定義し、さらに下の階層（ランニングシューズの選定など）へと無限にブレイクダウン（暴走）を始めてしまいます。

つまり、「手段は目的化してはいけない」という定義自体が間違っています。目的と手段が明確に定義され、それ以上の分解を許さない「底（底辺）」が設定されていない限り、手段は無限に目的化していくのがシステムの正常な仕様なのです。

では、この「入れ子構造の無限ループ」を断ち切り、実行者に意図通りのアウトプットを出させるためには、PMとしてどのような指示を出せばいいのでしょうか？

その鍵を握るのが「ロジックツリーです」

ここからは、コンサルティングの世界で使われる「ロジックツリー」の真の活用法と、「絶対に手段が目的化しない、実行者へのタスクの渡し方（テンプレート）」を具体的に解説します。

ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。

『イシューからはじめよ』（安宅和人）
「そもそも何に答えるべきか」を見極める、目的思考の原点となる一冊。

※本記事は、noteで公開した「「それは手段でしょ。目的は？」」の無料部分をブログ向けに再構成したものです。