「技術力が足りないので、支援してほしい」。
そう頼まれたら、まず技術で応えようとするのが自然だ。
足りないと言うのだから、足せばいい。

けれど、この要請を額面どおり受け取ると、たいてい妙なことになる。
言われたとおりに技術を入れても、プロジェクトは思ったように進まない。
システムは出来上がるのに、なぜか運用されない。
「技術力が足りない」という言葉が本当は何を指していたのかを、あとから考えることになる。

技術は「安全な問題設定」になりやすい

事業部門のプロジェクトから技術支援を頼まれたとき、その裏で何が起きているのかを考えてみる。

組織のなかで「マネジメントが機能していない」「要件定義が曖昧だ」と口に出すのは難しい。
人間関係に踏み込み、誰かの責任を名指しする構造になるからだ。
一方で、「技術力が足りない」は口に出しやすい。
誰の責任でもなく、外から知識を足せば済むように見える。

だから、本当の課題が別のところにあっても、それは「技術の問題」の姿を借りて現れる。
技術の要請は、組織のなかで許容される、いちばん摩擦の少ない問題設定なのだ。

適応課題の回避としての技術要請

なぜ摩擦が少ないのか。
ここでロナルド・ハイフェッツの区別が、その手ざわりに名前を与えてくれる。
彼は問題を、技術的課題と適応課題の二つに分けた。

• 技術的課題：既存の知識やスキルで解決できる問題
• 適応課題：価値観や行動様式の変化を伴う問題。当事者自身が変わらなければ解けない

この二つは、引き受け先が違う。
技術的課題なら、外部の専門家に任せられる。
適応課題は、自分たちが変わるしかない。
だから、適応課題を技術的課題として扱えれば、痛みのほうを外注できる。

事業部門の業務改善は、本質的に適応課題を含んでいる。
現場の業務フローを変えれば、誰かの仕事の領分が動く。
意思決定の流れを変えれば、誰かの権限が動く。
これを技術的問題として処理しようとすると、冒頭の「出来上がるのに運用されないシステム」に行き着く。

持っていないものを過大評価する

技術を持たない側は、技術を魔法の杖のように見てしまう。
「あの会社に頼めば全部解決する」「あのツールを入れれば変わる」。
この語り方は、技術の過大評価であると同時に、自分たちの資源の過小評価でもある。

業務知識、現場との関係性、意思決定の権限。
これらは、支援に入る技術者が持っていないものだ。
そして、支援される側だけが持っているものでもある。
プロジェクトを本当に動かすには、外から来る技術と、内側にしかないこれらの両方が要る。

ハードスキルとソフトスキルの混同

技術で代替できないものは、思ったより多い。

• 誰が何を決めるのか
• どう合意を形成するのか
• 抵抗にどう向き合うのか
• 変化を進める信頼関係を、どう作るのか

どれもソフトスキルの領域で、技術支援では埋まらない。
それでも「技術の問題」として相談が来るのは、ソフトスキルの不足を直視するより、ハードスキルの不足として処理するほうが、組織にとって扱いやすいからだ。

だとすれば、支援する側が最初にやるべきなのは、技術を見積もることではない。
要請の裏にある構造を、いくつかの問いで確かめることだ。

• この問題は、外部の技術力が入れば本当に解決するのか
• 解決しないとしたら、何が足りていないのか
• それを言いにくくしている力学は何か
• 支援側に何を期待し、される側には何が残るのか

これを支援される側と一緒に話す段階を、一つ挟むだけでいい。
それだけで、関係が「技術を渡す側と受け取る側」から、「課題を一緒に見る関係」へ動く。

冒頭の「技術力が足りない」に戻ろう。
その言葉は、たいてい嘘ではない。
ただ、足りないものの一覧のうち、いちばん口に出しやすい一項目でしかないことが多い。
技術支援の本当の入り口は、技術ではなく、課題を定義し直すところにある。
そしてその定義し直しに支援される側が加わらないかぎり、渡した技術は宙に浮いたままになる。