ITエンジニアが仕事に対して思うこと

ITエンジニアとして働く中で感じたことを、現場の温度感そのままに言語化するブログです。設計・実装・運用のリアル、学び続ける負荷、品質とスピードのせめぎ合い、コミュニケーションの難しさなど、きれいごとだけでは語れない「仕事の実態」を整理します。誰かを責めるのではなく、なぜそうなるのかを構造で捉え、明日から少し楽に、少し強く働ける視点を提供します。新人から中堅、マネジメントまで参考に。

令和7年度 春期システムアーキテクト試験 午後Ⅰ問2過去問題解説 ‐ システムアーキテクト特訓講座~E社の営業支援システム刷新・地獄のレガシー脱却編~ 【動画解説付き】

      [https://www.youtube.com/watch?v=YXY1ekTbDyQ:embed:cite]

今回の動画では、令和7年度春期システムアーキテクト試験午後Ⅰ問2を解説します。ExcelとRPAによるレガシーな営業支援システムを、ローコードとAPI連携を用いた新システムへ刷新する事例です。同期のタイムラグ、マスターデータの管理、データ移行のスコープ定義、業務フローの正確な把握など、アーキテクトとしての要点と失点防止のコツを分かりやすく解説します。 システムアーキテクト試験の午後問題を攻略する上で、まずは現状のシステム構成とそれに伴う業務上の課題を正確に把握することがすべての出発点となります。今回の事例では、10年間運用されてきた表計算ソフトと簡易データベースによる商談管理、そしてロボティックプロセスオートメーションを利用した1日1回の顧客データのバッチ取り込みというレガシーな環境が描かれています。ここで着目すべきポイントは、システム間のデータ同期タイミングです。バッチ処理による連携では、データが反映されるまでにタイムラグが生じるため、ユーザーが業務を行う上で意図しないエラーに直面する魔の時間帯が発生するメカニズムを読み解く必要があります。新しいシステム構想では、ローコード開発プラットフォームを採用し、アプリケーションプログラミングインターフェースを用いたリアルタイム連携によって、このタイムラグの問題を根本的に解消するアプローチが示されています。このような対症療法から根本治療への転換は、現代のシステム刷新において強く求められる考え方です。さらに、承認フローを設計する際には、どのシステムが最も信頼できる正しいデータを持っているかを見極める視点が欠かせません。この概念はシングルソースオブトゥルースと呼ばれ、組織や役職などの権限に関わるデータは人事システムを正本として扱い、そこから情報を取得することで、組織変更や人事異動に矛盾なく対応できるシステムを構築できます。また、新システムへのデータ移行要件の定義も重要です。過去のデータをすべて無批判にコピーするのではなく、実際の業務要件に照らし合わせて真に必要なデータのみを抽出する厳密なスコープ定義が求められます。直近数年間のデータしか利用されていないのであれば、関連しない古い顧客データは負債と見なし、移行対象から除外するという決断がシステムの最適化につながります。最後に、業務フロー全体のライフサイクルを漏れなく捉える読解力も不可欠です。商談の登録から完了に至るまで、単なる成功や失敗だけでなく、途中の審査NGによる取り消しといったステータス遷移も含め、業務のあらゆる分岐を正確に追いかけることが求められます。単に機能を並べるだけでなく、ビジネスの制約と理想の橋渡しを行うことがアーキテクトの役割です。