ベンダーSESも顧客側も経験した私が語る「システムエンジニアが本当に大事にすべきこと」【両側のリアルを全部話します】

 こんにちは❗たねまつです👦

SESでシステム開発に携わり、その後事務職に転職して顧客側でシステム構築・導入に関わった。この「両側の経験」があるからこそ見えたことがあります。SE志望の方にも、今のSEにも、顧客側のIT担当の方にも届けたい話です 🙌

🙋 この記事を書いた理由

「システムエンジニアって、何がそんなに大変なの？」 「要件定義でいつも揉める原因って何？」 「顧客が不満を持つ本当の理由がわからない…」

ベンダー側とユーザー側、両方の現場を経験してから気づいたことがあります。多くの問題は技術の問題ではなく、「認識のズレ」と「コミュニケーションの設計ミス」から生まれていた、ということです。この記事では、両側を知る立場から正直に話していきます 📖

---

要件定義・基本設計——「決めた」ではなく「納得して決めた」にする技術 📋

システム開発で最も重要なフェーズを一つ挙げるなら、迷わず「要件定義・基本設計」です。ここの質が、プロジェクト全体の成否を左右します。

🔑 顧客の要望を「引き出す」ことの難しさ

顧客は「やりたいこと」を持っています。でも「やりたいこと」と「システムで実現できること」は必ずしも一致しない。ここのギャップを埋めるのがSEの仕事です。顧客が明確に言語化できていない要望をインタビューで引き出し、それを「標準機能でできること」「お金をかければできること（カスタマイズ）」「今回のスコープ外にすること」の3つに整理する。この線引きを曖昧にしたまま進むと、後工程で必ず炎上します 🔥

⚠️ 必ず確認すべき「前システムの引き継ぎ確認」

要件定義で絶対につぶしておくべき観点があります。それは、

「前のシステムでできていたことが、今回のシステムでもできるか？」

これを確認しないまま進めると、移行後に「前はできてたのに！」という話が必ず出てきます。顧客側は「当然できる」と思っていても、SEは把握していない——この認識ズレが後から致命傷になります。「前システムでやっていたこと」を一覧化して、新システムでの対応可否を一つひとつ確認すること。地味ですが、これをやるかどうかで後のトラブルの量が全然違います。

📝 「納得して決めた」を証跡に残す——議事録の本当の役割

要件定義・基本設計で決めたことは、必ず議事録として記録し、出来れば顧客に確認・署名してもらうこと。これは単なる記録ではありません。顧客側の担当者が変わることもある。「そんなこと言ったっけ？」「それは聞いていない」というトラブルは、議事録があれば防げます。大事なのは、「SEが決めた」ではなく「顧客が自分たちで納得して決めた」という形を作ること。顧客が主体的に関わった記録が後のトラブル防止と信頼構築の両方に効きます 📋

開発フェーズのリアル——「きれいなコード」より「動くシステム」を顧客は求めている 💻

これは両側を経験してから、改めて実感したことです。

🤔 顧客とエンジニアの「温度差」

エンジニアから見れば、コードの品質・可読性・保守性は非常に大事です。複数のエンジニアが長年にわたって触ってきたコードは、書き方がバラバラになりがちで、いわゆる「スパゲッティコード」と呼ばれる状態になることがあります💦読むのも直すのも大変で、現場では愚痴が出る。非効率なのは間違いない。

でも顧客が見ているのはコードの美しさではなく、「ちゃんと動くか」「エラーが出ないか」です。高いお金を払っているのだから、当然です。現場で実際に見てきたことを正直に言います。

・スパゲッティコードでも、エラーが出ず、レスポンスが保たれているなら顧客は満足する ・きれいで保守性の高いコードでも、バグやエラーが続けば「高い金払っているのに」となる

もちろん、理想はきれいなコードかつ品質も高い、です。でも「どちらを優先すべきか」というプライオリティは、顧客の視点に常に引き戻す必要があるということを、両側を経験して強く感じました。コードの品質議論はエンジニア内部でやりきって、顧客との会話では「動作・品質・納期」を中心に据える。この使い分けが、現場SEには求められます 🔧

顧客の不信感はどこから生まれるのか——3つの根本原因 😤

顧客との関係でプロジェクトが難しくなるとき、その根本には必ずこのいずれかがあります。

🔴 ① 「思っていたのと違った」——深掘り不足

「そんな機能は要件に入っていない」「いや、最初の説明ではできると思っていた」——このすれ違いは、要件定義・基本設計での顧客の意見の深掘り不足から来ます。顧客が曖昧な言葉で話しているときに、「それは具体的にどういうケースですか？」「例外処理はどうしますか？」と追いかけるかどうかで、後の認識ズレの量が決まります。

🔴 ② 「聞いてないのにお金を取るの？」——見えないコストの問題

「追加要件が発生したので追加費用が発生します」と伝えたとき、顧客から「そんな話は聞いていない」という反応が返ってくることがあります。エンジニア側から見れば当然のルールでも、顧客はそのルールを知らないことが多い。最初の段階で「こういう場合は追加費用が発生します」というルールを明確に合意しておくことが、後のトラブル防止になります。

🔴 ③ ウォーターフォールの「後戻りできない」構造的問題

要件定義→基本設計→開発→テスト→納品と進むウォーターフォールモデルでは、一度進んだ工程に戻ることが非常にコスト高になります。顧客が「やっぱりこうしたい」と言っても、開発が始まっていれば大幅な手戻りになる。

理想を言えば、標準パッケージそのままで進む場合以外は、プロトタイプを作って顧客に見せながら確認・修正を繰り返すアジャイル的な進め方が、双方の認識ズレを最小化します。ただし現実には、予算・導入スケジュール・顧客組織内の意思決定構造がプロトタイプ開発を難しくするケースも多い。だからこそSEには、制約の中で最善を尽くす現実的な設計力が求められます ⭐

PMスキルこそが、これからの最強武器 🎯

開発の自動化が進む今、SEに求められるスキルの重心が変わってきています。

🏆 PMに求められる5つの要素

・顧客の予算・スケジュール・優先順位の整理：何を実現したくて、いつまでに、いくらで——この3軸を常に把握して調整する。 

・業務知識：顧客の業種・業務フローを理解していなければ、適切なシステム提案はできない。 

・システム全体仕様の把握：部分だけでなく全体像を見渡して、影響範囲を判断できる。

 ・顧客目線とエンジニア目線の両方を持つ：「顧客が何を求めているか」と「それを実現するための技術的現実」を同時に理解できる人が、最も価値が高い。

 ・AIを使いこなす判断力：コーディングがAIに代替されるほど、「何を作るか・なぜ作るか」を判断できる人間の価値が上がる。

💡 「システムに強い人は、どの現場でも強い」

顧客側の事務職に転職してから気づいたことがあります。システムの知識があると、ベンダーの言いなりにならない。「その仕様で本当に要件を満たせるのか？」「それは標準機能でできるのにカスタマイズ費用がかかるのはなぜ？」と、相手の矛盾や説明不足を突ける。これは顧客側にとって非常に大きな武器です✨

そして逆に、IT業界以外の普通の会社でも、システムに強い人材は本当に重宝されます。DX推進・基幹システム導入・業務改善のプロジェクトが増える中、「システム会社と対等に話せる社員」の価値はこれからどんどん上がっていきます 📈

AI時代のSEに求められるもの——正直な予測を話します 🤖

AIの進化によって、SEの仕事は変わります。でも「なくなる」のではなく、「求められるスキルの中心が移動する」という表現が正確です。

📉 AIが代替する方向に進むもの

・仕様通りにコードを書く作業（コーディングの大半） ・テストケースの自動生成・単体テストの自動実行 ・ドキュメントの自動生成・議事録の要約

📈 AIが進化しても人間が担う領域

・顧客の要望を引き出し、言語化し、優先順位をつけるプロセス 

・「これを作ることが本当にビジネス課題の解決につながるか」の判断 

・ステークホルダーの利害を調整し、プロジェクトを前に進めるPM力 

・AIが出力したコード・設計を評価・修正できる基礎技術力 

・責任を持って顧客と合意し、決断する能力一言でまとめると、「AIを使いこなしながら、顧客と人間として向き合える人」が、AI時代のSEのあるべき姿です。コーディングができるだけのSEから、「要件定義・顧客折衝・AIディレクション」ができるSEへ。この変化に早めに対応したエンジニアが、次の10年で大きく差をつけると思っています ✨

📣 最後に——両側を経験して、一番大事だと思ったこと

ベンダーSESも、顧客側の情シスも経験して、最終的に行き着いた答えはシンプルです。

「相手が何を不安に思っているかを、先回りして解消する」

顧客は「ちゃんと動くか・予算を超えないか・思った通りのものができるか」を不安に思っています。 エンジニアは「仕様が曖昧なまま進まないか・後から変更が来ないか・品質に納得してもらえるか」を不安に思っています。

その両方の不安を知っているSEが、最も強い。だからこそ、できれば両側を経験してほしいし、できなくても「相手の立場で考える」癖をつけることがSEとしての最大の武器になります。この記事が、あなたのSEキャリアを考えるヒントになれば嬉しいです 😊