現代IT技術者像の「フィクション性」——技術者は、何を負い、何を負わないのか

The Fiction of the Modern IT Engineer — What Engineers Owe, and What They Do Not

著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)

1. 技術企業は、技術について真剣に考える場所なのか

IT企業、あるいは「技術企業」と呼ばれる会社に入ると、どこかでこう期待してしまう。

技術的に正しい判断が重視される。良い設計が評価される。長期的な保守性が尊重される。技術者の専門判断が意思決定に反映される。技術について真剣に考えること自体が、この会社の中心にある。

しかし、企業はそもそも技術を最適化するために存在しているわけではない。

企業が同時に考えなければならないのは、売上であり、利益であり、契約であり、納期であり、顧客関係であり、人員であり、予算であり、市場であり、組織運営であり、法務であり、継続性であり、競争優位である。技術はそのなかの重要な一要素にすぎない。重要ではある。しかし、唯一ではない。

ここで最初の前提を置いておきたい。

技術企業だからといって、技術的「最適」を最優先するとは限らない。

これは皮肉ではない。むしろ逆で、企業が技術的最適だけを優先しはじめれば、企業運営そのものが成立しなくなる。予算を無視して最良の構成を選び、納期を無視して品質を追い、契約条件を無視して設計を通す会社は、技術的には正しいまま倒れていく。

2. コミュニティで流通する「理想のIT技術者」

一貫した人物像

IT技術コミュニティには、かなり一貫した「良い技術者像」が流通している。

継続的に学習する。良い技術選定をする。技術的負債を見つける。長期的な保守性を考える。品質を高める。事業を理解する。他職種を巻き込む。オーナーシップを持つ。組織に働きかける。エンジニアリング文化を改善する。必要なら越境する。

カンファレンスの登壇資料でも、技術ブログでも、採用要件でも、評価制度でも、この人物像はほとんど同じ形で現れる。

そして個別に見れば、どれも妥当である。学習しないより学習したほうがよい。負債は見えているほうがよい。事業を理解している技術者は、していない技術者より有用である。ここに反論はない。

問題にしたいのはそこではない

この文章は、技術コミュニティを批判するものではない。理想を掲げること自体は健全だ。

問題にしたいのは、そこで理想とされる人物像を、そのまま企業にとって普遍的に望ましい意思決定主体として扱ってよいのか？、という点である。

「良い技術者」の定義と、「良い企業運営」の定義は、本当に同じ方向を向いているのかを問い直したいのだ。

3. 理想のIT技術者は、企業運営には向かない可能性がある

理想的なIT技術者は、技術的整合性、再現性、保守性、品質、可観測性、長期的持続可能性、技術的負債の抑制を重視する。

しかし企業運営では、ときにそれらを意図的に「捨てる」判断が必要になる。

本来は刷新すべきだが、あと三年延命する。技術的負債になるが、今期は売上を優先する。内製したほうが美しいが、時間がないので外部サービスを使う。より堅牢な構成はあるが、予算上そこまではやらない。品質を百点まで上げず、七十点で市場に出す。長期最適より短期の生存を優先する。

こうした判断に必要なのは、「技術的に最善のものを選ぶ能力」ではない。

複数の価値を比較し、ときには技術的最適を捨てる能力である。

したがって、こう言える。

優れたIT技術者であることと、優れた企業運営者であることは同義ではない。

場合によっては、理想のIT技術者像を純化すればするほど、企業経営に必要な判断とは距離が生まれる。技術的整合性への感度が高い人ほど、「わかっていて捨てる」判断に耐えづらくなるからだ。

4. 技術的に正しいことと、企業として正しいことは違うはずだ

企業にとっての意思決定は、多目的最適化である。

技術だけを見ればAが正しい。しかし予算、納期、人員、契約、顧客、市場、他事業との優先順位まで含めればBを選ぶ。

このときBは「技術的に間違っている」のではない。

技術以外の変数を含めた企業判断としては合理的である可能性がある。

技術者側から見れば不格好な判断でも、経営側から見れば成立している。ここを混同すると、「なぜこんな技術的に悪い判断をするんだ」という不満が生まれる。

その不満は、しばしば正確である。技術的には実際に悪い。だが、企業はそもそも技術的正解だけを探しているわけではない。同じ盤面を見て、違う関数を最大化している。

不満の内容が正しいことと、不満の前提が正しいことは、別の話である。

5. GoogleやAmazon、Netflixは、本当に「技術的最適」を選んでいるのか

参照されるのはいつも「技術に限定した目線」のほうだ

IT技術コミュニティでは、Google、Amazon、Meta、Apple、Netflixなどが頻繁に参照される。

マイクロサービス。SRE。Chaos Engineering。巨大分散システム。内製プラットフォーム。高度な自動化。

こうした事例は、しばしば「技術的に優れた組織」の象徴として紹介される。

しかし、見るべきなのは技術そのものだけではない。彼らの判断もまた、成長速度、ユーザー体験、開発速度、事業規模、運用コスト、市場競争、組織規模、収益性といった企業上の条件に強く規定されている。

つまり彼らが行っているのも、技術最適化ではない。

事業最適化のなかで、技術を極めて高い水準で扱っているのである。

技術的に美しいからマイクロサービスにしたのではない。その事業規模、その組織規模、その成長速度にとって、当時それが合理的だった。

模倣すべきなのは「意思決定構造」

だとすれば、参照すべき対象も変わる。

どの事業課題があったのか。どの制約が存在したのか。誰に意思決定権があったのか。どのコストを許容したのか。どのリスクを捨てたのか。何を優先し、何を諦めたのか。

これらの企業を参照するなら、その技術ではなく、その技術を採用した意思決定構造を見るべきである。

ここを飛ばして技術だけを模倣すると、かなり奇妙なことが起きる。数千人規模の組織のための設計を、数十人の会社が模倣する。世界規模の配信サービス向けの構成を、小規模な業務システムで採用する。

結果としてできあがるのは、「先進的ではあるが事業には不釣り合いなシステム」である。そしてそれは、技術的に間違っているわけではないぶん、指摘しにくい。

6. 現代IT技術者像に隠されたもう一つの前提——権限

責任だけがある、という定番の話について

現代的な理想のIT技術者像には、ひとつ大きな前提が隠れている。

技術者には、自分の判断を実現するための権限があるという前提である。

「良い設計を選択する」。しかし、最終予算を持つのは誰か。

「技術的負債を解消する」。その工数を誰が承認するのか。

「長期的な保守性を考える」。契約期間や事業計画を決めるのは誰か。

「オーナーシップを持つ」。事業上の意思決定権も渡されているのか。

「組織を改善する」。採用権、人事権、予算権、評価権はあるのか。

ここまでは、よくある「責任だけ渡されて権限がない」という話である。この指摘自体は正しい。

しかし、この問題には逆方向がある

少し意地悪だがこう問うてみたい。

技術者の方は、本当にその権限を持つ準備ができているのか。

予算権が欲しいのであれば、その予算を技術以外にも配分しなければならない。採用権が欲しいのであれば、技術力だけでなく、人件費、配置、育成、退職リスクまで考えなければならない。納期を決める権限が欲しいのであれば、品質だけでなく、売上、契約、顧客関係、市場投入時期まで引き受けなければならない。技術選定の最終決定権を持つのであれば、その技術が失敗したときの事業上の損失まで判断対象になる。

つまり、権限とは、自分の技術的判断を自由に通せる権利ではない。

権限とは、技術以外の価値まで含めて判断し、その結果に責任を持つ役割である。

都合のよい「裁量のある技術者」

ここで本質的に問いたい。

現代のIT技術者像は、業界を見回すと権限を求めることについてはかなり積極的である。もっと技術者を意思決定に入れるべきだ。経営は技術を理解すべきだ。技術者に裁量を渡すべきだ。エンジニアがプロダクトにオーナーシップを持つべきだ。

では、その権限に対応する役割を果たせるよう、自分を訓練している技術者はどれほどいるのだろうか。

予算を読む。契約を読む。人員計画を考える。売上を考える。顧客との関係を考える。法的リスクを考える。そして、技術的には望ましくない選択肢を、企業として選ぶ。

そうした判断まで含めて「権限」である。

にもかかわらず、権限だけを、技術的理想を実現するための自由として夢見ていないか。

技術コミュニティで語られる「裁量のある技術者」は、ときに非常に都合のよい存在である。技術的判断には強い影響力を持つ。しかし予算責任は負わない。事業責任も負わない。人員責任も負わない。顧客との契約責任も負わない。

もしそうであるなら、それは経営参加ではない。

自分の専門領域だけに拒否権を持つ専門家を夢見ているにすぎない。

もちろん、すべての技術者が経営者になる必要はない。むしろ、ならなくてよい。技術専門職として、限定された責任と権限のなかで仕事をすることは完全に正当である。

問題なのは、専門職として働きたいのか、企業意思決定に参加したいのかを曖昧にしたまま、後者の権限だけを要求することである。

権限を持つとは、技術を守る力を得ることだけではない。ときには、自分が最も正しいと思う技術を、自分の判断で捨てる側に回ることでもある。

そこまで含めて引き受ける覚悟があるのか。権限についての議論は、そこまで見なければ、技術者にとって都合のよい夢物語になってしまう。

7. 技術者の能力で解決できる範囲は、実際より大きく描かれている

技術コミュニティでは、成功事例が可視化されやすい。

技術者主導で刷新した。リプレースを成功させた。技術的負債を返済した。開発文化を改善した。アーキテクチャを変えた。

一方で、こういう話は語られにくい。

普通に却下された。予算がつかなかった。営業都合で採用されなかった。契約上無理だった。人が足りなかった。問題は理解されていたが、あえて放置された。

後者は登壇資料にならない。ブログ記事にもなりにくい。書いたところで、自社への不満に見えてしまう危険もある。

その結果、技術者個人の能力によって変更可能な範囲が、実際より広く見える。

見えているのは、成功したケースと、そのとき動いた個人の力量だけだ。動かせなかった大量の事例は、記録に残らない。

8. 組織条件が、個人能力として語られる時の盲点

主体性には前提条件がある

一部の企業では、技術者に大きな裁量が与えられている。ロードマップを決められる。技術的負債返済の予算を確保できる。組織設計に関与できる。事業責任者と直接意思決定できる。

こうした環境では、技術者は大きな主体性を持てる。

しかしそれは、その技術者個人が特別に優秀だからだけではない。その主体性を可能にする組織構造が存在しているからでもあることを忘れてはいけない。

その条件を消したまま「優れた技術者ならこの程度はできる」と一般化すると、構造の問題が個人の能力問題に変換される。

そして「自己責任化」が起きる

すると、次のようなことが起きる。

技術的負債が返せない。→ 説明力が足りない。

無理な納期が設定される。→ 調整力が足りない。

技術判断が通らない。→ 影響力が足りない。

技術に使う時間がない。→ タイムマネジメントが悪い。

組織が技術を軽視する。→ エンジニアリング文化を作れていない。

人員が足りない。→ 自動化能力が足りない。

本来は企業構造や経営判断に属する問題が、個人の成長課題として回収される。

厄介なのは、この変換にはいつも一定の真実が混じっていることだ。説明力はもっとあったほうがいい。調整力も同じだ。だからこそ反論しにくく、そして無限に努力先が生成されるのである。

9. 「オーナーシップ」という言葉の危うさ

「オーナーシップを持つ」は、現代IT組織で非常に好まれる言葉である。

自分事として考える。主体的に動く。担当範囲を越えて問題を拾う。それ自体は悪くない。

しかし、意思決定権はない。予算権もない。人員配置もできない。納期も変更できない。にもかかわらず「オーナーシップを持て」と言われる場合がある。

この状態では、権限を増やさずに責任だけを増やしていることになる。

著者(霧星礼知)が仮に「権限なき経営者要求」と呼んでいる現象がある。技術者に求められているのが、専門職としての責任ではなく、権限のない経営者として振る舞うことに近づいていく状態のことだ。

事業のことを考えろ。組織のことを考えろ。全体最適で判断しろ。ただし、予算も人事も納期も契約も、決めるのはこちらである。

この要求は、言葉としては「主体性の奨励」の形をとる。だから断りにくい。

10. 現代IT技術者像の「フィクション性」とは何か

ここで改めて定義しておく。

現代ITコミュニティで流通する理想の技術者像とは、高度な技術的専門性を持ち、事業も理解し、関係者を巻き込み、組織を改善し、適切な技術判断を実現する主体である。

この人物像には、少なくとも二つのフィクションが含まれている。

第一に、技術的最適と企業としての最適が必ず一致するというフィクション。

第二に、技術者個人に、その判断を実現するだけの権限と能力があるというフィクション。

そしてさらに、その権限そのものについても、権限とは自分の専門判断を通せる自由であるという夢が混じりやすい。実際の権限は、技術以外の価値を引き受け、ときには技術的最適を自ら捨てる責任とセットである。

この三つを取り除くと、技術者という職能の輪郭はかなり変わって見える。小さくなる、というより、境界がはっきりする。

11. では、技術者は何を負い、何を負わないのか

負えるもの

IT技術者として負えるものはある。

自分の専門領域について学ぶこと。知っていることと知らないことを区別すること。技術的な成立条件を示すこと。技術的リスクを説明すること。選択肢とトレードオフを提示すること。自分の判断に根拠を持つこと。問題を隠さないこと。担当範囲について必要な品質を確保すること。

つまり、技術に関する判断材料を、専門職として適切に提供することには責任を持てる。

負わなくてよいもの

一方で、当然には負わなくてよいものもある。

技術判断を組織に採用させること。予算不足を個人努力で埋めること。人員不足を長時間労働で埋めること。無理な納期を成立させること。営業判断の結果を吸収すること。契約制約を突破すること。他部署の意思決定を肩代わりすること。権限のない組織変革を成功させること。会社全体の技術文化を一人で救うこと。

ここで重要なのは、「できないから負わない」のではなく、責任主体が別に存在するから負わないということを意識できることである。逆に、この責任分界を理解しないまま「自分の責任ではない」とだけ主張すれば、それは専門職としての責任放棄にもなり得るということに注意が必要だ。

責任分界として捉え直す

技術者が「この構成なら成立する」と説明する。「この条件ならこのリスクがある」と説明する。「Aなら高コストだが安全、Bなら安いが負債が残る」と説明する。

そこから先、どのリスクを取るか、どの予算を使うか、納期を優先するか、売上を優先するか、長期保守性を優先するかを決めるのは、企業の意思決定である。

したがって、こう整理できる。

技術者は技術的に成立する条件を示す責任を負う。その条件を満たす組織を作る責任までは負わない。

ただし、もし自ら企業意思決定の権限を持つ側へ進むのであれば、その瞬間から判断対象は技術だけではなくなる。そこでは、技術を守ることだけでなく、技術を捨てることにも責任を持たなければならない。

12. 技術企業への期待を「下げる」

これは技術軽視でも、企業への冷笑でもない。

「技術企業なのだから技術的最適を選ぶはずだ」と期待しない。むしろ、企業は技術を含む複数の価値を調整する組織であると考える。

そう捉えたほうが、技術判断が採用されなかったときに「自分の技術力が足りなかった」とすべてを自己責任化せずに済む。

また逆に、企業が技術的に不格好な判断をしたからといって、即座に「技術を分かっていない会社」と断定する必要もなくなる。その判断には、技術者から見えていない別の制約が存在するかもしれない。

期待を下げるとは、諦めることではない。期待の宛先を、正しい責任主体に置き直すことである。

13. 結論：あなたはこの構造のなかで、何を負い、何を負わないのか

現代IT技術者像の問題は、単に理想が高すぎることではない。

それは、技術者という職能に、企業運営の論理と組織的権限まで重ね合わせていることにある。

さらに、その権限を「自分の技術的理想を実現する自由」としてだけ夢見るなら、そこにもフィクションがある。

技術者は万能な主体ではない。企業を救う必要もない。組織を救う必要もない。あらゆる事業矛盾を技術で吸収する必要もない。

自分の専門性に責任を持つ。技術的成立性を考える。リスクを説明する。判断材料を出す。根拠を持つ。そして、その先にある事業判断は、適切な責任主体に返す。

一方で、その責任主体になりたいのであれば、技術以外の価値まで引き受ける。予算を考える。契約を考える。人員を考える。売上を考える。顧客を考える。そして必要なら、自分が最善だと思う技術を捨てる。

理想の技術者像に自分を近づけることよりも重要なのは、次の問いに自分で答えることである。

あなたは、この構造のなかで何を負うのか。そして、何を負わないのか。

さらに言えば、どの権限を欲しいのか。そして、その権限に対応する役割まで、本当に引き受けたいのか。

その境界は、誰かが引いてくれるものではない。理想像のほうから提示されることも、まずない。

☕️よかったらコーヒー一杯。 https://buymeacoffee.com/mink_obs

著：霧星礼知(min.k) / リサーチ・構造支援：Claude Opus 5、ChatGPT / AI-assisted / Structure observation

For international readers

Tech communities share a remarkably consistent image of the "ideal engineer": one who learns continuously, chooses sound architectures, pays down technical debt, understands the business, influences the organization, and takes ownership. Each item is reasonable on its own. This essay questions whether that figure can be treated as a universally desirable decision-maker from the company's point of view.

Two fictions are embedded in the image. First, that technical optimality and business optimality coincide — in reality, running a company often requires deliberately discarding the technically best option in favor of budget, deadline, contract, or short-term survival. Second, that the individual engineer holds the authority to enact their judgment. The familiar complaint here is responsibility without authority, but the essay pushes the inverse question as well: are engineers prepared for the authority they ask for? Real authority means weighing non-technical values and, at times, abandoning the technology you believe is best.

The essay also argues that when Google, Amazon, or Netflix are cited, the thing worth copying is not the technology but the decision-making structure behind it: what constraints existed, who held the decision rights, and what was given up. It closes with a boundary question rather than an answer — what do you owe in this structure, what do you not owe, which authority do you actually want, and are you willing to accept the role that comes with it.

Keywords

Software engineering culture, engineering ideals, technical debt, technical optimality vs business optimality, authority and responsibility, ownership, decision-making structure, self-responsibility, professional boundaries, IT organizations

現代IT技術者像、理想の技術者、技術的負債、技術的最適、企業最適、権限と責任、オーナーシップ、意思決定構造、自己責任化、責任分界、専門職、IT組織論