1. 技術と体験は、同じ座標系に存在しない
技術と利用体験は、同じ座標系には存在しません。これは比喩ではなく、構造の話です。
システム技術を主語にして世界を見る場合と、利用体験を主語にして世界を見る場合とでは、登場人物の並び順も、意味づけも、判断基準も変わります。両者は連続した一つの軸上にあるのではなく、主語の異なる別の座標系に属しています。
この区別が曖昧なまま議論が行われると、「技術を扱っている」「技術に関わっている」といった言葉だけが先行し、実際には異なる文脈の話が同一視されます。その結果、同じ言葉を使っていながら、前提の異なる議論が並行して進むことになります。
技術を主語にした世界では、関心の中心は、成立条件、制約、設計、制御可能性にあります。一方、利用体験を主語にした世界では、関心の中心は、使いやすさ、分かりやすさ、安心感、業務への馴染み方といった体験の質にあります。どちらも現実のシステムにとって重要ですが、同じ論理で語ることはできません。
問題は、これら二つの座標系が無自覚に混在することです。体験の文脈で語られた要求が、あたかも技術を直接制御できるかのように扱われたり、逆に、技術の制約が体験の議論を封じる理由として使われたりします。ここに、情シスとエンジニアの会話が噛み合わなくなる根本原因があります。
2. システム技術が主語になる世界
システム技術を主語にした場合、世界の並び順は明確になります。関心の中心は、技術がどのように成立し、どこまで制御できるかに置かれます。
この座標系では、登場人物の位置関係は次のようになります。
- システム技術
- エンジニア
- 情シス
- ユーザー（技術の末端に位置する）
この並びは、権限や立場の序列を示すものではありません。技術を理解し、制御できる範囲の違いを示しています。
エンジニアは、技術の成立条件や制約を理解し、その前提の中で設計や実装を行います。ここでは、技術は論理的に説明され、制御される対象です。技術の振る舞いは、原理や設計によって決まります。
一方、ユーザーが接しているのは技術そのものではなく、技術の結果として現れた体験です。操作や利用は体験の消費であり、技術を直接制御する行為ではありません。ユーザーの不満や要望は存在しますが、それらは技術に対する制約条件として影響を与えるにとどまります。
情シスは、この技術座標系において、エンジニアとユーザーの間に位置します。ただし、情シスが扱っているのは技術の内部ではなく、既に成立している技術を前提とした適用や運用の判断です。
この世界では、技術が先にあり、体験はその結果として後から現れます。体験から技術を逆に動かすことはできず、できるのは制約として影響を与えることだけです。
3. 利用体験が主語になる世界
利用体験を主語にすると、世界の並び順は反転します。関心の中心は、技術の成立や制御ではなく、使われ方や受け取られ方、業務への馴染み方に置かれます。
この座標系では、登場人物の位置関係は次のようになります。
- ユーザー
- 情シス
- エンジニア
- システム技術（体験や業務の背後に位置する）
ここでは、技術は前面に現れません。利用体験の背後にある制約条件として存在し、必要に応じてのみ意識されます。
ユーザーは、自身の体験を起点として世界を見ます。不便さや不満、改善要望は体験の言語で表現され、技術そのものを直接指示したり制御したりするものではありません。
情シスは、この体験座標系においてユーザーに最も近い位置に立ちます。求められるのは、技術原理の理解よりも、ユーザーの感覚を汲み取り、それを組織として処理可能な形に整える能力です。共感、調整、説明が主な役割になります。
この役割においては、技術の内部構造に立ち入らなくても業務は成立します。実際、多くの情シス業務は、この体験座標系の中で完結しています。
エンジニアやシステム技術は、この世界では直接触れられる対象ではなく、体験の背後にある制約として位置づけられます。
4. なぜ情シスは技術構造を把握しづらいのか
情シスが技術構造を把握しづらいのは、能力や姿勢の問題ではありません。それは、利用体験が主語となる座標系に置かれている役割だからです。
前節で述べたとおり、情シスの業務は、利用体験を起点として成立します。ユーザーの不満や要望を受け取り、それを組織として処理可能な形に整え、必要に応じてエンジニアや外部ベンダーに伝える。この流れの中では、技術の成立条件や内部構造に立ち入らなくても、業務は完結します。
この構造には、次のような特徴があります。
- 技術を理解しなくても業務が成立する
- 技術的な判断を外部に委ねられる
- 体験の言語だけで意思決定が進む場面が多い
その結果、情シスの役割は、技術座標系へ移行する経験を必ずしも要求されません。一般的な求人要件を見ても、高度な設計能力や原理理解が必須とされることは多くなく、これは個人の資質ではなく、役割設計の結果だと分かります。
また、体験座標系では、技術は前面に現れません。技術は制約条件として背後に存在し、体験を通じて間接的にのみ認識されます。このため、技術全体を俯瞰する視点を獲得する機会は限られます。
こうした環境に長く身を置くと、技術は「使われるもの」「外部に委ねるもの」「調整対象」として認識されやすくなります。技術がどのような前提や設計の上に成り立っているかを想像する必要がないため、その構造を把握しづらくなるのは、自然な帰結です。
5. 技術を「支配している」という錯覚
情シスの立場にいると、技術を「支配している」と錯覚しやすい条件が揃います。これは傲慢さの問題ではなく、役割構造がそう見せるためです。
体験座標系において、情シスはユーザーに最も近い位置に立ち、システム利用の可否、変更のタイミング、ベンダーとの調整など、業務上の判断に関与します。このため、「技術に関する決定をしている」という感覚を持ちやすくなります。
しかし、ここで行われているのは技術の制御ではありません。行われているのは、あくまで体験や業務の観点からの選択と調整です。技術がどのように成立し、どこまで可能で、何が不可能かという判断は、依然として技術座標系の側にあります。
この違いが曖昧になると、次のような混同が起きます。
- 社内での決定権を、技術の支配権と誤認する
- 技術的制約を「説明不足」や「融通が利かない」と解釈する
- 体験の要求が、技術を直接動かせると思い込む
体験座標系では、技術は背後に隠れているため、その制約は見えにくくなります。その結果、技術がどのような前提の上に成り立っているかを想像しないまま、判断だけが先行します。
この状態では、エンジニアが提示する説明や制約が、「技術の話」ではなく、「抵抗」や「言い訳」のように受け取られやすくなります。問題は判断そのものではなく、技術構造への想像を欠いたまま判断が行われることです。
6. エンジニアと情シスの話が噛み合わない理由
エンジニアと情シスの会話が噛み合わないのは、知識量や説明能力の問題ではありません。原因は、立っている座標系と、理解が向かう方向が異なることにあります。
エンジニアは、システム技術が主語となる世界に立っています。技術の成立条件や制約を前提に、何が可能で、何が不可能かを考えます。そのため、利用体験や業務上の要望についても、それを制約条件として解釈することができます。体験の要求が技術にどのような影響を及ぼすかを、構造として捉えることが可能です。
一方、情シスは、利用体験が主語となる世界に立っています。日常的に接しているのは、ユーザーの感覚や業務上の困りごとであり、技術はそれを解決するための手段として背後にあります。この立場では、技術の前提や設計思想を起点に物事を考える機会は多くありません。
この結果、理解の方向性には非対称性が生まれます。
- エンジニアは、体験座標系を制約として理解できる
- 情シスは、技術座標系を想像しづらい
これは努力や誠意の差ではなく、日常的にどの世界を起点に思考しているかの違いです。
この前提を共有しないまま会話をすると、次のようなすれ違いが起きます。
- エンジニアは前提や制約を説明しているつもりでも、情シスには「技術の細部」に見える
- 情シスは体験の要望を伝えているつもりでも、エンジニアには「前提を無視した要求」に見える
互いに誠実であっても、主語と座標系が異なるため、論理は交差しません。
重要なのは、この噛み合わなさを人格や態度の問題に回収しないことです。ここで起きているのは、構造的に異なる世界同士の会話です。
7. 「エンジニアはユーザー視点がない」という誤解
エンジニアと情シスの関係を論じる際、「エンジニアはユーザー視点を欠いているのではないか」という反論がしばしば提示されます。しかし、この見方は実態を正確に反映していません。
実際には、エンジニアを雇用する企業や、システムを提供する側の組織（いわゆる SIer やサービス事業者）では、ユーザー目線に立つことが強く求められています。ユーザー体験を無視した設計や実装が許容される文化は、現実にはほとんど存在しません。
一方で、技術説明の粒度をどこに合わせるかは常に難しく、説明を省略すれば誤解を招き、踏み込みすぎれば不要な混乱を生むこともあります。そのため、エンジニアは体験座標系との接点において、調整の難しいコミュニケーションを担わされる場面が少なくありません。
このため、エンジニアがユーザー視点を全く考慮しないという状況は、現実にはほぼ起こり得ません。ただし重要なのは、エンジニアに求められているのが、ユーザー視点を主語として行動することではないという点です。
エンジニアにとってユーザー視点は、設計や実装に影響を与える制約条件であり、目的そのものではありません。体験の翻訳や組織内調整を主業務とするわけでもなく、その役割を恒常的に担うことは想定されていません。
つまり、「エンジニアはユーザー視点を強く求められている」が、「ユーザー視点を主語に行動しているわけではない」という位置づけになります。
この点を無視して、「エンジニアにもユーザー視点を持て」とだけ要求すると、役割の混同が起きます。エンジニアが情シスの代替になることはありませんし、その逆はより成立しません。
両者は対立関係ではなく、異なる座標系に立ち、それぞれの責務を担っている存在です。
8. おわりに
エンジニアと情シスの関係が噛み合わない理由は、能力や姿勢の差ではありません。本稿で見てきたとおり、両者は最初から異なる座標系に立っています。
システム技術を主語にした世界と、利用体験を主語にした世界では、関心の置きどころも、判断基準も、言葉の意味も変わります。どちらが正しいかという問題ではなく、同じ論理で語れる前提が存在しないことが本質です。
情シスは体験座標系に立ち、ユーザーや業務の現実を起点として判断します。エンジニアは技術座標系に立ち、成立条件や制約を前提として設計や実装を行います。この違いを意識しないまま議論を行えば、会話が噛み合わないのは当然です。
問題になるのは、この違いが見えなくなり、「技術を理解しているか」「ユーザー視点を持っているか」といった形で、個人の資質に回収されてしまうことです。その瞬間に、構造の問題は見失われ、議論は感情論や評価論にすり替わります。
本稿の目的は、情シスを擁護することでも、エンジニアを正当化することでもありません。技術と体験が最初から別の世界に属しているという前提を明示し、その上で役割の位置関係を整理することにあります。
座標系を揃えないままでは、どれほど丁寧に説明しても、どれほど誠実に対話しても、議論は交差しません。まず必要なのは、相手がどの世界に立って話しているのかを見極めることです。
その認識が共有されたとき、はじめて、エンジニアと情シスの対話は、人格や立場ではなく、構造に基づいたものになります。
