この記事でわかること
-
特定製品に縛られない「完全中立」な立場がもたらす本質的な顧客価値
-
レガシー刷新や非機能要件など、開発現場の経験が提案の「信頼」に変わる理由
-
AIには代替できない「タスクの連鎖設計」と、後悔しないキャリアの選び方
「このまま技術を磨き続けるべきか、それともマネジメントや上流工程へ進むべきか」。多くのエンジニアが一度は直面するキャリアの岐路です。また、現場で「言われたものを作る」ことへの限界を感じ、より経営に近い立場でビジネス課題を解決したいという想いを抱く方も少なくありません。
しかし、いざ「ITコンサルタント」への転身を考えると、自分の技術がどこまで通用するのか、あるいは「営業」的な役割に寄ってしまうのではないかという不安がよぎるものです。
今回は、開発のスペシャリストからULSコンサルティングのITコンサルタントへと転身し、現在は企業の変革をリードする前田利恵氏にインタビュー。エンジニア時代の「泥臭い経験」が上流工程でどう武器になるのか、そしてAI時代にこそ求められるエンジニアの真価について、実践的な知見を伺いました。
前田 利恵
ULSコンサルティング株式会社 ディレクター
東京理科大学 理工学部卒。日本ヒューレット・パッカードにて大規模システム開発のプロジェクトマネジメント等に従事後、2018年2月にULSコンサルティングへ中途入社。システム化企画・構想策定から実行支援、組織改革まで幅広く手掛け、現在は特定企業の包括的パートナーシップを担う組織の部長を務める。
【SNS】：https://www.linkedin.com/in/%E5%88%A9%E6%81%B5-%E5%89%8D%E7%94%B0-376a4534b/
ULSコンサルティング株式会社
特定の製品やベンダーに縛られない「完全中立」な立場で、企業のIT戦略から実行までを支援するコンサルティングファーム。「ダブルコア」「一心共創」といった独自のコンセプトに基づき、技術の目利き力を武器に、顧客のビジネス価値を最大化する最適なソリューションを追求している。
【HP】：https://www.ulsconsulting.co.jp/
目次
「作る」から「解決する」キャリアへ。「中立」だからこそ誠実に課題へ向き合える
まず、前田さんの現在のミッションについて教えてください。
大きく2つの役割があります。1つは「クライアントパートナー本部」での活動です。これは、お客様との最初の接点において課題や目的を深く理解し、当社の多様な知見を組み合わせて最適な支援体制をデザインする、「提案の入り口」を構築するセールス的な役割です。
もう1つは、特定のお客様との包括的パートナーシップの推進です。単発のプロジェクト支援ではなく、お客様の中期経営計画にまで入り込み、組織改革や人材育成、さらにはAI活用テーマなど、全方位から企業成長を加速させるための伴走を行っています。
中期経営計画にまで関わるとは、非常に裁量が大きいですね。前職では大手ベンダーで開発の第一線を歩まれてきましたが、なぜそこからコンサルタント、しかもULSコンサルティングという道を選ばれたのでしょうか？
前職は外資系のハードウェアベンダーでしたので、ハードウェアの進化はもちろん、システムがオープン化してLinuxが登場したり、オフショア開発が普及し始めたりと、IT業界の進化の波の最前線で仕事をしていました。
しかし、自社製品を豊富に揃えていたため、どうしても提案の前提が「自社ソリューションの活用」になっていたのです。 お客様にとっての最適解を追求しようとすると、それでは不十分なケースが出てきます。「本当はこうすべきなのに、立場上言えない」というジレンマが、私の中で大きなストレスになっていました。
自社製品という縛りが、お客様へのベストな提案の足かせになっていたのですね。
その点、ULSコンサルティングは、特定の製品を持たない完全中立な立場です。転職活動中、唯一「本当の意味で、お客様のことだけを考えてコンサルテーションしていいよ」と明確に言ってくれました。しがらみなく、純粋に最適な解決策を考えられる環境だと感じたのが決め手です。
自由であることは、同時に難易度の高さも意味します。ただ、マインドとして大切にしているのは、「技術はあくまで目的を達成するための手段である」と定義し直すことです。スタート地点をお客様のビジネス課題に置き、システム導入が解決策にならない場合も含めて、フラットに考えられるようになりました。
特定の武器（製品）がない分、自分自身の「思考力」が問われるわけですね。
エンジニア時代の「レガシー刷新」経験が、提案の説得力を生む
コンサルタントへ転身した後、エンジニアとしての実務経験が具体的に「助けになった」と感じる瞬間はありますか？
私の場合は、エンジニア時代に手がけた「レガシーシステムの刷新案件」の経験が圧倒的に活きています。古いシステムで何が起きていて、新しくする際にどんなリスクが潜んでいるか。新旧両方のリアルを知っているからこそ、「当てずっぽうではない、確度の高い仮説」を立てることができます。
確かに、現場を知っているからこそ言えるアドバイスは、お客様にとっても安心感が違いますよね。
例えばBCP（事業継続計画）の議論で、お客様が「バックアップを毎日取って復旧できるようにしたい」とおっしゃったとします。技術的には簡単ですが、実務レベルでは「全システムの整合性を取って、業務的に意味のあるタイミングで戻せなければ意味がない」という落とし穴があります。
こうした「運用で必ず直面する泥臭い課題」を企画段階で提示できるのは、間違いなくエンジニアとしてのバックボーンがあるからです。
| 経験が活きるシーン | エンジニア時代の知見の活用方法 |
| システム構想策定 | 新旧両方の特性を理解した上での「確実性の高い移行計画」の策定 |
| BCP・障害対策 | 物理的な復旧だけでなく「業務整合性を考慮した実効性のある復旧設計」の提案 |
| リスク察知 | 未検証の新しい製品導入時に起こり得る「現場レベルのリスク」の事前指摘/td> |
きれいごとだけではない「地に足のついた提案」ができるんですね。
そうですね。一般的にシステム導入などのコンサルティングでは、理想の姿である「あるべき論」を提示してしまいがちです。しかし、現場のお客様は「そんなことは百も承知だが、事情があってできないんだ」と内心思っていらっしゃることが多いのです。
「組織文化的に言い出せない人がいるのでは？」「単純にリソースが足りていないのでは？」といった現場の障壁を察知し、その障壁を取り除くためのアプローチができるのも、開発現場のリアルな空気を肌で知っているからこそだと感じています。
エンジニアの知見を活かし、組織の意思決定をリードする醍醐味
ベンダー時代とコンサルタントとしての現在とで、仕事に対するプレッシャーの種類に違いはありますか？
全く違いますね。ベンダー時代に感じていたのは、納期を守り、品質を担保しながら「システムを動かす」ことへのプレッシャーでした。コンサルタントの仕事では、自分の提言によってお客様が投資を決め、何百人という組織が動き出します。その「意思決定を支える責任」の重さを日々感じています。初めて自分の提案が採用され、本当にお客様が組織を動かし始めたのを見た時は、大きな衝撃を受けました。
自分が描いた絵の通りに、多くの人やお金が動き出す。それはやりがいと同時に、相当な覚悟が求められそうです。
だからこそ、単なる提案で終わらせず、「実行し、成功させるまで伴走する」ことにこだわっています。また、ビジネス視点とのバランスも欠かせません。例えば、開発側が「2年で完成させる」ことを目標にしたとき、経営側から見れば「その2年間、投資に見合う価値が出ていない」のは問題です。
施策を細分化し、早期に効果が見えるロードマップを設計するなど、常に投資対効果を意識した動きが求められます。
お客様の組織を動かし、改革を成功に導くためには、プロジェクトを前に進めるためのコミュニケーションも重要になるかと思います。現場のヒアリングなどでは、どのようなことを心がけていらっしゃいますか？
プロジェクトの初期段階では、必ずお客様の現状をヒアリングするインタビューを実施します。その際、すでに顕在化している「今困っている課題」はお客様から自然とお話しいただけますが、実はそれだけでは不十分なのです。
「本当はどうなりたいですか？」「正直なところ、本当はどうしたかったですか？」という、お客様の奥底にある本音を引き出すことに注力しています。
今見えている課題の裏にある、潜在的な課題を探るわけですね。
特に外部のコンサルタントが入ってくると、お客様は無意識のうちに「言っていいこと」と「言ってはいけないこと」を取捨選択して、当たり障りのない表面的な課題だけを伝えてしまう傾向があります。
しかし、改革を妨げている本当の理由は、「心の中で思ってはいるけれども、口に出せない、あるいは実現できない事情」の中に潜んでいるのです。
| ヒアリングで引き出すべき声 | 特徴とコンサルタントのアプローチ |
| 顕在化している声 （表向きの課題） |
お客様が自ら語る「困りごと」。 システム不足など当たり障りのない内容になりがち。 |
| 潜在化している声 （本当の想い） |
「本当はどうしたいか」「ココだけの話」。 聞き役に徹し、本音を引き出すことで改革の壁を探る。 |
なるほど。だからこそ、先ほどおっしゃっていた「できない理由の深掘り」が活きてくるわけですね。
いくら外から「こうすれば未来が拓ける」と語っても、お客様自身が腹落ちしなければ、決して組織の推進力は生まれません。まずは聞き役に徹し、お客様が本当に望んでいる変化の方向性を探り当てることが、プロジェクトを動かす最大の鍵になります。
AI時代のエンジニアに求められる力。AIが「点」なら、人間は「線」を引く存在になる
現在、生成AIの台頭により開発のあり方が大きく変化していますが、エンジニアの「ベーススキル」の価値はどう変わっていくと思われますか？
AIはコードを書いたり資料を作ったりと、「点」のアウトプットにおいては人間を圧倒するようになりました。しかし、その「点」と「点」を繋ぎ、次に何をすべきか、どのタスクを連動させるべきかという「タスクの連鎖設計（線）」は、依然として人間が担うべき領域です。
AIの回答を鵜呑みにせず、評価・判断できるだけの地力が必要だということですね。
これからはAIを「同僚の1人」と見立ててマネジメントする感覚が必要になります。AIは賢くスピーディーに答えを出してくれますが、その出力に対して「いいね」「全然違うね」と判断を下せるのは、自分の中に確固たる基準や仮説を持っている人間だけです。
もし自分の中に「おそらくこういう答えが返ってくるはずだ」という仮説がなければ、AIの出力結果にただ振り回されてしまいます。AIが生成した成果物を踏まえて、次にどの選択肢を選ぶべきか、どう分岐判断を下すかという「設計力」を磨くことで、AIには代替できない価値を発揮できるはずです。
最後に、キャリアに悩む中級エンジニアの中には、「技術を捨てるのが怖い」と感じる人も多いです。そんな方々へアドバイスをいただけますか？
私は3年後などの「将来の具体的な姿」を具体的に描くことはしていません。変化の激しいこの業界では、計画通りにいかないことの方が多いからです。大切だと思っているのは、「自分はどうありたいか」という軸を持つことです。
「ものづくりをして、実際に手を動かしている時が一番の喜び」なのか。それとも「本質的な課題を思考し、解決の仕組みを設計することが楽しい」のか。職種名で選ぶのではなく、自分がどの瞬間にやりがいを感じるのかに正直になって自分のありたい姿を持っていれば、コンサルタントという道も自然な選択肢として見えてくるはずです。
ライター
