この記事の途中に、以下の記事の引用を含んでいます。
Stop Separating People Problems from Engineering Problems
「技術」と「人」――分けて考えることの落とし穴
今回取り上げる記事は、ソフトウェア開発やエンジニアリングにおいて長年取り沙汰されてきた「技術的問題」と「人間関係的問題」は、本当に分けて議論すべきなのか？という本質的な問いに鋭く切り込んでいます。
特に、「エンジニアリング・マネジメント」から個人コントリビューター（IC: Individual Contributor）へキャリアを移す際に、「人の問題」を扱わなくなるのでは？という問いを受けた筆者が、その二分法の無意味さを主張する形で、現場視点でのリアルな考察を展開しています。
エンジニアリングの現場で働く方はもちろん、チームを率いるマネジメント層、さらには「技術」と「組織」の板挟みに悩むビジネスリーダーにとっても、極めて示唆に富んだ内容となっています。
技術問題≒人の問題という現実──記事が指摘する“根本”
まず筆者は、エンジニアリングの現場で根強い次の神話を痛烈に批判しています。
“The belief that you can specialize in one or the other, or that certain engineers are ‘people-focused’ while others are ‘technically-focused,’ is one of the most persistent and counterproductive myths in software engineering.”
（「人・組織中心」か「技術中心」かといった志向でそれぞれ専門特化できるという信念は、ソフトウェアエンジニアリングにおける最も根強く非生産的な神話の1つだ）
特にエンジニアリングの「技術的な課題」が、実は過去の意思決定者や関係者のコンテクスト、コミュニケーション、組織的制約から生じているケースが多々あることを、次の実例で端的に示しています。
“You will have to address this technically by throwing more hardware at it, rewrite the queries, migrate to a different database technology. But none of these solutions address the actual problem that architectural decisions were made under different constraints with different information.”
（技術的にはハードウェア増設やクエリ書き換え、異なるDBへの移行で対処できる。しかし、これらは異なる制約・情報下で下された設計判断そのものの問題には根本的にアプローチできていない）
逆に、チームの燃え尽き（バーンアウト）やモチベーション低下といったいわゆる「人の問題」も、単なる心理的安全性やサポート体制だけでなく、作業負荷を創り出しているシステム自体をエンジニアリング的に再設計しなければ持続的な解決にならないと強調しています。
「技術問題」と「人間問題」――安易な二分法の背景と、その陥穽
この指摘は、現場を知る人ほど「あるある」とうなずけるものではないでしょうか。
一般的に、技術者は「仕様に従って最適解をコードで表現する」ことに集中したい反面、“人との調整・説得・利害調整”といった業務を好ましく思わない場合も多いでしょう。
逆に、マネジメントやリーダー職は「人と組織の活性化＝自分の本分」と捉えがちです。
この分離構造がついしみ付いているため、「技術問題＝冷静な分析・合理的対応で完結」「人間問題＝心理や関係性へのケアで完結」と捉えがちです。
しかし現実問題として、システム障害や技術的行き詰まりの背景には、古い設計判断や部分最適化、拙い合意形成のツケが積み重なった結果が露呈していることが多いのです。
また、バーンアウトやモチベーション低下の背景には、「不安定なシステム運用」「ドキュメント残らず属人化している設計」「改善提案が通らない文化」といった、技術起因の構造的歪みが絡んでいるケースが大半でしょう。
組織と技術の“本当の関係”──現場からの考察
筆者の主張は、いわゆる“組織論”や“マネジメント論”の外側にある、現場レベルの本質を掴んでいると感じます。
例えばシステムのパフォーマンス問題。
表層的には「DBのクエリが遅い」あるいは「ハードが貧弱」などの技術的課題に見えます。
ですが、そもそもの設計思想や運用方針の決定が恣意的で、時に開発サイドと運用サイドの誤解や「とりあえず動けばOK」の合意不在が“隠れた負債”となります。
そしてこの負債が現場の火消し作業や、無駄なアラート対応として跳ね返ります。
また、チームの定着率やモラルの問題。
表面的には「人間関係がうまくいっていない」「刺激的業務が少ない」などの印象が語られがちです。
しかし、慢性的な障害・アラート対応が発生するシステム環境、改善案が技術負債によって却下される意思決定体系、属人化したシステム構造こそが“人を疲弊させる土壌”として作用します。
まさに筆者が言うように
“Happy engineers need more than supportive culture. They need robust, well-designed systems that don’t demand constant firefighting.”
（エンジニアが幸せであるためには、支え合う文化以上に、日々火消し作業を強いられない堅牢なシステム設計が必要だ）
という指摘が身にしみるのです。
体系的“二項対立”の解体が生む新しいスキルセット
ここで改めて重要なのは、二項対立的な専門化（人 vs 技術）に安住しない“複眼的視点”の必要性です。
すぐれたエンジニアや技術リーダーが持つのは、「問題の表層にとどまらず、その技術的背景と組織・人間系の構造の両面を観る目」です。
記事内で筆者は繰り返し述べています。
“The most effective engineers I’ve worked with don’t choose between solving for people or solving for systems. They recognize that:
Technical excellence requires collaboration. The best architecture in the world fails if you can’t build consensus around it, communicate its trade-offs, or bring the right people along.”
（最も有能なエンジニアは「人」か「システム」を選ばない。技術の卓越には協働が不可欠であり、最高の設計も合意形成や利害調整なくして機能しない）
この言葉の重みは、日々現場で「技術」と「組織」の隙間に悩む人ほど沁みるのではないでしょうか。
表面だけのコードスキルや業務効率だけでなく、「問題の本質を見抜き、バイナリ（白黒）ではなく連続体（グラデーション）として捉え直す力」こそ、現代のエンジニアに求められる資質です。
バランス感覚が生む“全体最適”へ──読者へのメッセージ
ここまで読んで、「やはり自分は技術寄りだから…」「私はマネジメントだけで精一杯で…」と分野分断的思考に無意識で陥っていた方も少なくないはず。
しかし筆者は、完璧なゼネラリストを目指せ、と言いたいわけではありません。
“This doesn’t mean every engineer needs to be equally strong in all dimensions. People have different strengths, and that’s valuable. But it does mean that recognizing when a problem requires both technical and interpersonal solutions is a core engineering skill, not an optional specialization.”
（すべてのエンジニアがあらゆる観点でバランス良く強くなるべき、という意味ではない。だが、「両面から解くべき問題」を正確に見極める力は、もはやオプションではない“必須のスキル”だ）
この点は、現場経験と客観的視点がなければなかなか身につきません。
むしろ「人（組織）vs 技術」ではなく、その両極の間にある無数の“グラデーション”を察知し、ケースに応じて「今はどちらの観点から入るべきか？」「目先の課題の裏に本質的連関があるのでは？」と問い直す習慣を持つことで、「全体最適」の解が見えてくるのではないでしょうか。
まとめ・読者への問いかけ
いかがでしたか？
“技術問題か人の問題か”という二択ではない、現場の現実とその解決法の本質。
本記事が提起しているのは、一見「当たり前」だと思い込みやすいテーマながら、現場で本当に実践できている人は決して多くはありません。
日々の開発や運用、チームマネジメントの中で、一歩引いて「何が本質的な課題か？」「安易な分断思考に陥っていないか？」と問い直す視点――それこそが、持続的に組織を前進させるための最大の武器になるはずです。
小手先のスキルアップや表層的な対症療法ではなく、「一段上の視座」から問題の全体像を見通す力を、これをきっかけに身につけてみてはいかがでしょうか。
categories:[technology]
コメント