IT技術者の3段階の成熟モデル——技術を大事にしたあとは、技術を「相対化」する
Three Stages of Maturity for IT Engineers — Learning to Value Technology, Then Learning to Relativize It
著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)
1. 成熟した技術者ほど、「技術だけ重視」はしない
IT業界では、技術者として成長することは、しばしば次のように語られる。
より深く技術を学ぶ。より良い設計を知る。より高い品質を求める。技術的負債に敏感になる。最新技術を追う。技術文化を改善する。
これは間違っていない。実際、技術者として一定の段階まで進むには、技術そのものに強い価値を置く時期が必要になる。それを経ずに「技術は手段にすぎない」と言う人の言葉は、たいてい薄い。
しかし、その先にもう一段階あるのではないか。
十分に技術を理解したあと、技術的に最善であることと、組織として最善であることは違うと理解する段階である。
成熟とは、技術をより強く信じ続けることだけではない。ときには、技術を相対化できるようになることでもある。
この記事では、IT技術者の成熟を「技術への関心の強さ」ではなく、技術をどの位置に置いて意思決定するかという観点から整理する。
三つの段階
先に結論の骨格だけ示しておく。
- 技術を手段として扱う
- 技術そのものを価値として扱う
- 技術を理解した上で相対化する
重要なのは、第3段階が第1段階への回帰ではないという点である。これについては後半で詳しく扱う。
2. 第1段階：技術を手段として扱う
「動けばよい」という世界
最初の段階では、技術は主に仕事を成立させるための手段である。
要件がある。それを実現する。動けばよい。必要な品質を満たせばよい。
この段階では、次のような問いへの関心はまだそれほど強くない。
なぜこのアーキテクチャなのか。なぜこの設計原則なのか。長期的にどのような負債が生まれるのか。他の設計ならどうなるのか。
この段階を軽視しているわけではない
誤解されやすいが、この段階の技術者は、決して技術を軽視しているわけではなく、技術それ自体を独立した価値として、強く意識していないのである。
ここで彼らに取っては、技術は業務を実現する道具として存在している。道具に良し悪しがあることは知っていても、その差が自分の判断を左右するほどの解像度では見えていない、ということなのだ。
3. 第2段階：技術そのものを価値として扱う
経験を積んで差が見えるようになる
経験を積み技術を学ぶにつれて、技術そのものが見えるようになる。
設計には良し悪しがあること。保守性には差があること。可用性には設計思想が反映されること。技術的負債は将来のコストになること。運用性を考えない設計は危険であること。適切な抽象化には価値があること。
そして、技術は日々更新されていき、何かを身につければ終わりではなく、学び続けなければ技術者として停滞すること。
こうしたことが、実感として分かってくる。
この段階では、技術そのものが価値になる。
単に「動くかどうか」ではなく、「どう動くべきか」「どう設計されるべきか」「長期的にどのような状態が望ましいか」を考えるようになる。
ここで初めて、技術者としての職能意識がかなり強くなる。自分は道具を使う人ではなく、技術という領域に責任を持つ人だ、という自覚が生まれる。
この段階も必要である
この段階を通過することは、避けて通れない。
一度も技術そのものを価値として考えたことがない人が「技術は相対的だから」と言っても、それは単なる技術軽視になりやすい。相対化には、相対化される対象への十分な理解が要る。
4. 技術コミュニティが最も魅力的になる段階
技術コミュニティは、実はこの第2段階との相性が非常に良い。
そこでは、良い設計、良いコード、良いアーキテクチャ、良い開発文化、技術的負債への向き合い方、SRE、DevOps、クラウド設計、セキュリティ、パフォーマンス、新しい技術について、深く語ることができる。
会社の予算や顧客都合から一度離れて、技術として何が望ましいのかを考えられる。
これは技術者にとって非常に重要な場所である。第2段階を形成する上で、コミュニティが果たす役割は大きい。もしも(SESなどにはどうしてもある構造なのだが...)所属する会社や現場の中だけで技術を考えていると、その制約が技術の限界だと錯覚してしまう。外に出て初めて、制約と技術が別物だと分かるというわけだ。
相対化直前の引力
ここで一つ仮説を置きたい。
著者(霧星礼知)が仮に「相対化直前の引力」と呼んでいる現象がある。
技術コミュニティは、技術を相対化する「直前」の段階にいる人々を、最も強く引きつけやすい構造を持つ、という仮説である。
第1段階では、そもそも技術そのものへの関心がまだ強くない。したがって、休日や業務外に技術記事を読み、勉強会に参加し、設計思想について語る動機もそれほど強くならない。
第2段階になると、問題意識が一気に強くなる。
もっと良い技術を使いたい。もっと良い設計をしたい。なぜ会社はこの判断をしないのか。技術者の意見をもっと反映すべきではないか。
この問題意識は、会社の中では受け止めきれないことがある。だからこそ、第2段階のエンジニアはコミュニティに向かう。
そしてコミュニティは、この問題意識に対して非常に良い応答を返してくれる。
一方で、第3段階へ進むと、技術に関する問いそのものが変わってくる。問いが変われば、答えを探す場所も変わってくる。
つまりコミュニティの主要な参加層は、構造的に「第2段階の人」に偏りやすいのだ。これはコミュニティの欠陥では決してない。コミュニティが果たしている機能の裏面である。
5. 第3段階：技術を理解した上で相対化する
技術的正しさは、「最終判断ではない」と知る
第3段階では、技術の価値を否定しない。
むしろ、第2段階を経ているからこそ、技術的な良し悪しは十分に理解している。
その上で、技術的に最善であることが、常に最終判断になるわけではないと理解する。
たとえば、こういう判断ができるようになる。
技術的には刷新した方がよいが、あと3年延命する。技術的負債になるが、市場投入を優先する。内製した方が柔軟だが、外部サービスを採用する。より堅牢な構成は可能だが、予算上そこまではやらない。長期的にはAが優れているが、今期はBを選ぶ。
ここでは、技術的正しさは消えていない。むしろ、Aが優れていることは正確に見えている。
ただし、それが唯一の判断軸ではなくなる。
第3段階は、「第1段階への回帰」ではない
この三段階モデルで、最も誤解されやすいのがここである。
第1段階も第3段階も、外から見ると「技術的に最善ではないものを選ぶ」ことがある。行動としては似て見える。
しかし、中身はまったく違う。
第1段階では、技術的な差が十分に見えていないため、結果として技術を相対化している。
第3段階では、技術的な差を理解した上で、それ以外の価値も含めて相対化している。
前者は、AとBの差が分かっていないからBを選ぶ。後者は、Aが優れていると知りながらBを選ぶ。
同じBという選択でも、失っているものへの自覚がまるで違う。そして、その自覚があるかどうかは、次に同じ状況が来たときの判断に出る。
第3段階とは、決して技術を軽視する段階ではないのだ。技術を十分に理解したからこそ、技術だけに支配されなくなる段階なのである。
6. 技術的最適と企業最適は違う
技術は「変数の一つ」である
第3段階で強く意識されるのは、技術的最適と企業としての最適は一致しないということである。
企業には、売上、利益、予算、人員、契約、納期、市場、顧客関係、法務、組織、将来の事業計画がある。
技術は重要だが、その一つである。
技術だけを見ればAが正しい。しかし、全体を見ればBを選ぶ。
この判断は、技術を知らないから起きるとは限らない。技術を理解した上で、あえてBを選んでいる可能性がある。
「なぜこの会社は分からないのか」という感覚
第2段階にいると、「なぜこの会社は技術を分かっていないのか」と感じる場面が増える。
なぜ技術負債を返さないのか。なぜ技術刷新しないのか。なぜこんな技術構成を選ぶのか。なぜ、会社はもっと技術者の話を聞かないのか。
もちろん、会社組織が、本当に技術を理解していないケースもある。それは実在する。
しかし、すべてがそうとは限らない。
その判断をしている人は、予算、契約、営業、顧客、人員、経営計画といった、技術者からは見えにくい変数を見ている可能性もある。
技術的には不格好でも、全体として合理的な判断というものが存在する。
そして厄介なことに、その判断根拠は多くの場合、技術者に共有されない。共有されないからこそ、外からは「分かっていない判断」と「分かった上での判断」が区別できない。この区別のつかなさが、第2段階の人間の苛立ちを増幅させる。
だが：参照される企業も、技術最適をしているわけではない
ちょっと意地悪なことを一つ。
Google、Amazon、Meta、Apple、Netflixといった企業は、技術コミュニティでその技術文化が頻繁に参照される企業である。
だが。
しかし、これらの企業も技術的に最も美しいものを選び続けているわけではない。
彼らが見ているのは、事業規模、成長速度、開発速度、ユーザー体験、コスト、競争環境、組織規模、市場である。
つまり、事業最適化の中で、技術を非常に高い水準で扱っている。
ここを絶対に取り違えてはいけないのである。
技術コミュニティから見て「高度な技術組織」に見える企業も、実際には技術を企業全体の一変数として扱っている。技術が最優先されているのではなく、その事業構造において技術への投資が高いリターンを生むから、高い水準に置かれているのである。
だから、彼らから学ぶべきは技術そのものよりも、どういう制約の下で、誰が、何を諦めて、その判断に至ったかという意思決定の構造の方かもしれない。
7. 第3段階では、問いそのものが変わる
第2段階と第3段階の違いは、答えの違いではなく、問いの違いとして現れる。
第2段階では、「どうすれば良い技術を採用できるか」と考える。 第3段階では、「この会社はいま、良い技術にどこまでコストを払うべきなのか」と考える。
第2段階では、「この技術的負債をどう返すか」と考える。 第3段階では、「この負債は本当に今返すべきなのか」と考える。
第2段階では、「技術者の裁量をもっと増やすべきだ」と考える。 第3段階では、「この意思決定について、誰がどこまで権限を持つのが合理的なのか」と考える。
技術への関心がなくなるのではない。問いのスコープが、技術から組織全体へ広がる。
そして問いが広がると、答えを出すために必要な情報も変わる。
技術記事だけでは足りなくなる。予算の話、契約の話、事業計画の話が要る。
ここで多くの人が、技術コミュニティとの距離を少し変えることになるのである。そして、第2段階にいる人が多くを占めるコミュニティの人たちとの会話も、自ずと変化していくことになるのだ。
8. 第3段階は経営者だけのものではない
注意が必要な点を一つ。
この段階に進むことは、必ずしも管理職や経営者になることを意味しない。
技術者のままでも、次のようなことは考えられる。
この案件ではどこまで品質を求めるべきか。この負債は今返すべきか。どの部分だけ改善するのが合理的か。技術的理想と顧客要求をどう折り合わせるか。
重要なのは役職ではなく、技術的正しさを、他の制約と同じテーブルに載せて考えられることである。
むしろ、実装の現場にいる人がこの視点を持つことの価値は大きい。技術的な差を最も正確に見積もれるのは実装者だからである。
第3段階の判断には、第2段階の解像度が要る。しかし、その両方を持っている人は、実は多くない。
9. 技術コミュニティを否定するモデルではない
念のため書いておくと、このモデルは技術コミュニティを否定するためのものではない。
第2段階は非常に重要である。そして第2段階を深めるための場として、技術コミュニティに代わるものはほとんどない。
その意味で、技術コミュニティは重要な成熟装置である。
問題があるとすれば、それは第2段階を最終地点だと思ってしまっていることである。
技術を深く知ることが技術者の完成形だと考えると、技術以外の変数で判断する人々が、すべて「分かっていない人」に見えてしまう。そう見えている限り、その人たちが実際に何を見ているのかは分からないままになる。
10. 真の成熟とは、技術を強く信じ続けることではない
技術者として成長すると、技術への理解が深くなる。
しかし、それと同時に、技術だけでは世界が決まらないことも理解するようになるはずである。
技術は重要である。ただし、常に最優先ではないかもしれない。
優れた設計は重要である。ただし、常に採用すべきとは限らない。
負債は少ない方がよい。ただし、負債を意図的に抱えることが合理的な場合もある。
成熟とは、技術的正しさを失うことではない。
技術的正しさだけで判断しない能力を得ることである。
11. 結論：技術を大事にしたあと、技術を相対化する
まとめると、IT技術者の成熟には、少なくとも三つの段階がある。
第1段階、技術を手段として扱う。 第2段階、技術そのものを価値として扱う。 第3段階、技術を理解した上で相対化する。
第3段階は、第1段階への回帰ではない。技術を知らないから軽視するのではなく、技術を十分に理解した上で、技術以外の価値も含めて判断する段階である。
技術コミュニティは、第2段階を深めるための非常に重要な場所である。同時に、技術を相対化する「直前」の段階にいる人々を最も引きつけやすい構造を持っている。
だからこそ、その先にもう一段階あることを意識しておいた方がよい。
最後に、答えではなく問いを置いて終わりたい。
あなたが今、技術的に納得できないと感じている判断がある。
それは、判断した人が技術を分かっていないから起きているのか。それとも、あなたにまだ見えていない変数が、そこにあるのか。
その二つを見分ける方法を、あなたは持っているだろうか。
☕️よかったらコーヒー一杯。 https://buymeacoffee.com/mink_obs
著：霧星礼知(min.k) / リサーチ・構造支援：Claude Sonnet 4.6、ChatGPT / AI-assisted / Structure observation
For international readers
This essay proposes a three-stage model of maturity for IT engineers. In the first stage, technology is treated purely as a means to an end — the engineer does not yet perceive technology as an independent value. In the second stage, technology itself becomes a value: design quality, maintainability, and technical debt become visible and matter deeply. In the third stage, the engineer relativizes technology — not by abandoning technical judgment, but by placing it alongside budget, contracts, staffing, customers, and business strategy as one variable among many.
The central point is that the third stage is not a regression to the first. Both may result in choosing the technically inferior option, but the first does so without seeing the difference, while the third does so while seeing it clearly.
The essay also advances a hypothesis: technical communities are structurally most attractive to people in the stage immediately before relativization. First-stage engineers lack the motivation to engage; third-stage engineers ask questions that technical discourse alone cannot answer. This is not a flaw of such communities but the flip side of the function they serve — they are essential engines for developing the second stage.
Maturity, the essay concludes, is not losing technical correctness. It is gaining the ability not to decide by technical correctness alone.
Keywords
IT engineer maturity, technical decision-making, technical debt, engineering culture, technical community, organizational optimization, engineering career stages, relativizing technology, business constraints, software architecture judgment
IT技術者, 成熟モデル, 技術的負債, 技術コミュニティ, 技術的最適, 企業最適, 意思決定, キャリア段階, 相対化, アーキテクチャ判断, 組織論