私は受託開発・AI活用支援を行う会社を経営しながら、自分でも手を動かしているエンジニアだ。日常的に事業会社のIT部門と協働する中で、同じ役職でも、プロジェクトが前に進む人と止まる人がはっきり分かれる光景を繰り返し見てきた。違いは技術力の高さではなく、何を自分の判断範囲と捉えているか、そして決めるべきことを決めているかにある。発注を受ける側から見えてしまう「活躍している人」の共通点を整理する。
技術力が高い人が、必ずしも活躍しているわけではない
Photo by Startaê Team on Unsplash
事業会社のIT部門では、手を動かす量より決める量が成果を左右する。技術に詳しくても、判断を保留し続ける人のプロジェクトは進まない。要件の曖昧さを理由に検討を続け、ベンダー側に「まだ確認中です」と繰り返す担当者がいる。その間、開発チームは待機し、納期は削られていく。逆に技術の深さが中程度でも、決めきる人の案件は形になる。完璧な仕様を待つのではなく、現時点で分かっていることと分からないことを切り分け、分かる範囲から着手する判断を下す。ここで言う活躍とは、事業側から信頼され、次の予算を任される状態を指す。技術的な正しさと、組織の中で成果を出すことは、必ずしも一致しない。
エンジニアとITコンサルの違いを徹底比較｜仕事内容・スキル・向き不向きまで解説でも触れたが、事業会社では「正しい技術選定」と「通る技術選定」の両方が求められる。前者だけでは動かない。
「何を作らないか」を決められる
Photo by Christopher Gower on Unsplash
要望をすべて仕様に積むと、納期も品質も破綻する。活躍している人は、落とす機能とその理由を自分の言葉で説明できる。「この機能は初回リリースには含めず、利用状況を見てから判断します」と現場や経営に伝え、合意を取る。落とす判断を現場や経営に通すところまでを自分の仕事だと捉えている。ベンダーに「どうしますか」と丸投げしない。
発注を受ける立場からすると、すべての要望を同列に扱う人と、優先順位を明示する人では、提案の質が変わる。後者には、制約の中でどう最大化するかという代替案を出せる。前者には、言われたことをそのまま見積もるしかない。
ベンダーを評価者ではなく、当事者として扱う
Photo by Annie Spratt on Unsplash
見積と進捗を管理するだけの関わり方では、出てくるものは指示の範囲に留まる。背景と制約を開示すると、ベンダー側から代替案が出るようになる。「この機能は○○という業務フローの変更を避けるために必要だが、別の手段はあるか」と伝えれば、技術的に安価で済む選択肢が見えることがある。情報を出さない発注は、結果的に手戻りとして自分に返ってくる。仕様の背景を知らないまま実装したものが、実際の運用に合わず、作り直しになる。ベンダーコントロールは監視ではなく、共同で意思決定する設計のことだ。
コンサル経験者の転職とキャリア設計｜出口戦略と市場価値の作り方で扱った「支援する側から実行する側への転換」は、この協働の在り方にも表れる。
業務を理解しに現場へ行っている
Photo by EqualStock on Unsplash
IT部門にいながら、実際の業務プロセスを見に行く人と行かない人がいる。現場を見ている人の要件は、作った後に使われる。「この入力画面は立ち仕事の合間に使うから、片手で完結する設計にしたい」という指定が出てくる。見ていない人の要件は、正しいが使われないものになりやすい。業務フローとして整合しているが、実際の作業リズムに合わず、結局Excelに戻される。この差は技術スタックの知識では埋まらない。
要件定義の段階で現場に足を運び、どの作業がボトルネックになっているか、どの情報が手元にないと判断できないかを直接見ている人は、システムが解決すべき問題を正確に把握している。
運用と撤退まで設計に入れている
Photo by Kelly Sikkema on Unsplash
作って終わりではなく、誰がどう運用するかまで決めている。うまくいかなかったときにどう畳むかを先に考えている。特にAI活用はPoCで終わる案件が多く、本番運用の設計が分かれ目になる。「精度が○%を下回ったら人手に戻す」「運用負荷が○時間/週を超えたら中止を検討する」といった撤退基準を持っている人は、次の投資判断を任されやすい。投資した以上、成果を出さなければならないというプレッシャーは、事業会社では特に強い。だからこそ、畳む基準を先に決めておくことが、逆説的に挑戦を可能にする。
生成AIでエンジニアの仕事はなくなるのか｜採用する側が見ている評価軸の変化でも触れたが、AI案件の成否は技術選定より運用設計で決まる場面が増えている。
コンサル出身者がつまずきやすいところ
提案と整理は得意でも、決めて責任を負う立場への切り替えが要る。支援する側から、実行して結果を引き受ける側になる。社内の合意形成は論理だけでは動かない。正しい提案が通らないのは、提案の質の問題ではなく、誰がどのタイミングで言うかの問題であることが多い。この切り替えができる人は、事業会社で強い。
コンサルティングファームでは、提案を作ることと実行することが分離されている場合が多い。事業会社では、提案した人が実行し、結果を引き受ける。コンサルタントに向いている人・向いていない人の特徴｜SIer・事業会社ITのマネージャーが転身前に確認すべき適性で整理した適性の話は、逆方向にも当てはまる。
自分がどちらの働き方を望んでいるかを確認する
事業会社での活躍は、技術を深めることとイコールではない。決めること・巻き込むことに面白さを感じるかどうか。手を動かし続けたいなら、事業会社が最適とは限らない。社内SEの役割は、技術的な実装よりも、事業部門との調整やベンダーとの協働に重きが置かれる場合が多い。それを「本来の技術力が発揮できない」と感じるか、「技術を使って事業を動かせる」と感じるかで、向き不向きが分かれる。
現職に留まって決める経験を積むという選択肢もある。SIerやコンサルファームの中でも、顧客側の意思決定に深く関わるポジションはある。事業会社に移ることだけが、決める力を磨く道ではない。事業会社ではなく、コンサルだからこそできること — ものづくり出身者が失うものと得るもので扱ったように、コンサルの立場だからこそ提供できる価値もある。
自分が何に時間を使いたいか、どの成果に責任を負いたいかを確認してから動く方が、後悔は少ない。事業会社で活躍する人の共通点は、技術を手段として使い、決めることと巻き込むことを自分の仕事の中心に置いている点にある。その働き方を望むなら、事業会社IT部門は合う。技術そのものを深めたいなら、別の道を選ぶ方が誠実だ。
転職を検討する際は、在職エンジニアが現職にバレずに転職活動する方法【完全チェックリスト付き】も参考にしながら、慎重に情報収集を進めてほしい。
FAQ
事業会社のエンジニアに求められるのは技術力ではないのですか？
技術力は前提として必要だが、それだけでは成果に直結しない。技術的に正しい選択と、組織の中で通る選択の両方を実現する力が求められる。技術を理解した上で、事業部門や経営に説明し、合意を形成し、ベンダーと協働して形にするところまでが仕事になる。
社内SEに向いている人はどんな人ですか？
決めることと巻き込むことに面白さを感じる人。技術を手段として使い、事業の成果に責任を持つことを自分の仕事の中心に置ける人。逆に、技術そのものを深めることに時間を使いたい人には、社内SEの役割は物足りなく感じられる可能性がある。
事業会社に行くと技術力が落ちませんか？
落ちる場合もあれば、落ちない場合もある。自分で手を動かす機会が減る企業では、実装の勘が鈍ることはある。一方で、技術選定や設計の判断を繰り返す中で、技術の使いどころを見極める力は磨かれる。どちらの技術力を維持したいかによる。
ITコンサル出身者は事業会社で活躍できますか？
支援する側から実行する側への切り替えができれば、活躍できる。提案を作ることと、決めて結果を引き受けることは異なる。社内の合意形成は論理だけでは動かず、誰がどのタイミングで言うかが重要になる。この切り替えを理解している人は、コンサル出身の強みを事業会社でも発揮している。
ベンダーとの関わり方で成果は変わりますか？
大きく変わる。背景と制約を開示し、ベンダーを当事者として扱うと、指示の範囲を超えた提案が出てくる。情報を出さない発注は、仕様の手戻りとして返ってくる。ベンダーコントロールは監視ではなく、共同で意思決定する設計として捉える方が、成果につながる。
AI活用の案件がPoCで止まってしまうのはなぜですか？
本番運用の設計が抜けているから。誰がどう運用するか、うまくいかなかったときにどう畳むかを先に決めていないと、PoCで精度が出た後に進まなくなる。撤退基準を持っている人は、逆説的に挑戦を続けられる。投資判断を任される人は、畳む判断も含めて設計している。
