仕様理解と調整経験

SIer時代には、公共系Webサイト改修、業務システムのバグ改修、金融系公的機関の不動産管理システム改修に携わりました。特に長く関わった案件では、一次請け企業のシステムエンジニアとして、基本設計工程から総合テスト工程まで参加しています。

その中で強く意識したのは、顧客折衝や品質管理では、話し方だけでなく仕様を読み、根拠を持って論点を整理する力が必要になるということです。

担当した役割

金融系公的機関の不動産管理システム改修では、顧客折衝、ベンダーコントロール、設計書・テスト仕様書の確認、品質管理、仕様変更に該当するかどうかの整理などを担当しました。

ベンダー成果物の提出が遅れた場面では、一次請け側で作業を巻き取ることもありました。その際、一時的に他部署から2〜4人程度のメンバーを受け入れ、テスト実施、バグ修正後の改善確認、設計書のフォーマット修正などを割り振ることもありました。

業務システムの改修では、顧客側が求める修正が、バグ修正なのか仕様変更なのかを整理する場面があります。仕様変更に該当する場合は追加費用や契約上の整理が関わるため、印象やその場の話し合いだけでは判断できません。

たとえば、減価償却の計算方法に関する論点では、設計書にそのまま答えが書かれていたわけではありませんでした。ただ、業務全体の流れや数値の整合性を追うと、その数値でなければ説明がつかないと整理できる場面がありました。

そこで、過去に合意した仕様、業務ルール、帳票出力の数値を確認しながら、お客様側と相談しました。最終的には、業務全体で見たときの整合性をもとに、仕様変更として扱う形にできました。

顧客折衝では、相手と円滑に話す力はもちろん必要です。ただ、顧客側、ベンダー側、一次請け側の利害が分かれる場面では、合意済み仕様を根拠にして整理する力が土台になります。

自分が大切にしていたのは、仕様書、業務ルール、過去の確認結果を読み、必要な情報を調査したうえで相談することです。根拠を持って話せれば、請負側として説明責任を果たしながら、現実的な落としどころを探すことができます。

公共系・業務系システムの現場では、目立つ新規機能の開発だけでなく、既存仕様を壊さずに読み解き、関係者の認識差を整理し、品質を保ちながら前に進める力が求められます。この経験は、自分の実務上の強みのひとつです。