情報システム部門（情シス）に配属されたら、誰と、何を、どこまで調整するのでしょうか。最初は、自分の仕事の範囲がつかみにくいものです。
システムを導入する企業を、この記事では「発注側」と呼びます。発注側が外部のSIer（システムインテグレーター）に設計・開発などを依頼しても、情シスの仕事がなくなるわけではありません。
私は大手SIerで20年以上、データベースの設計・構築からシステム基盤の統括、プロジェクトマネジメントまで携わってきました。その中で、発注側の役割が曖昧なまま仕事が進み、プロジェクトが行き詰まる場面を何度も見てきました。
「技術のことは詳しいSIerにお任せします」。技術的な設計や実装を専門家に委ねるのは自然です。しかし、自社の業務で何を実現するか、誰が合意するか、導入後に成果が出たかまで委ねることはできません。
これは担当者を批判したいという話ではありません。情シスの役割や発注側としての判断を体系的に教わる機会がなく、何を確認すればよいのか分からないまま現場に立つこともあると感じています。だからこそ、実務で役立つ入門記事を書こうと考えました。
これから情シスになる方、配属されたばかりの方に向けて、組織内の立ち位置、関係者、システム開発・運用の仕事を順番に説明します。後半では、主任クラスを目指す際に役立つ具体的な確認観点も紹介します。
なぜ企業に情シスが必要なのか？
システムを作ることが目的ではない
企業は、売上の拡大、納期の短縮、品質の安定、コストの削減など、事業上の目標を持っています。その実現には、業務の進め方を見直し、情報を適切に使える状態にすることが必要です。
例えば「納期を守れる会社にしたい」という目標があるなら、受注・調達・製造・出荷の状況を把握できていないことが課題かもしれません。必要なのは、いきなり新しいシステムを購入することではなく、どの情報を誰がいつ必要とするのかを整理することです。その結果として、既存システムの改修やSaaSの導入が選択肢になります。
流れは、経営・事業の目標 → 業務課題 → 業務の改善 → IT施策 → 効果の確認です。情シスは、この流れをITの側面から支える組織です。
図 情シスが支える基本の流れ
経営、業務、ITをつなぐ窓口になる
経営層は投資の目的や優先順位を考えます。業務部門は現場の仕事と制約を知っています。SIerは技術的な実現方法を考え、設計・開発を担います。
しかし、これらの情報を別々に持ったままでは、投資目的とシステムの仕様がずれたり、現場で使われない仕組みが出来上がったりします。情シスは、事業の目的をITの取り組みにつなぎ、導入後も目的を達成できたかを確かめる役割を持ちます。
なお、企業によっては情シス自身が開発や運用を行い、別の企業では外部委託を中心とするなど、担当範囲は異なります。この記事では、業務システムの企画・開発・運用を社内外の関係者と進める情シス担当者を中心に説明します。
情シスの仕事内容と、社内外の関係者との役割分担
まずは3つの仕事を押さえる
情シスの仕事は、大きく次の3つに分けられます。
| 仕事の領域 | 具体的な活動 | 新任担当者がまず知るべきこと |
|---|---|---|
| IT戦略・システム企画 | IT投資計画、製品・サービス選定、業務改善の企画 | なぜ導入するのか、誰が予算と方針を決めるのか |
| 開発・導入・運用 | 要件整理、ベンダ管理、設計レビュー、受け入れ、障害対応 | 自分が何を判断し、何をベンダに委ねるのか |
| 社内サポート・IT管理 | 問い合わせ、端末・アカウント・ライセンス管理、セキュリティ対応 | 利用者の困りごととシステム全体への影響を把握すること |
近年はクラウド・SaaSの組み合わせ、外部サービスとのデータ連携、情報セキュリティ、生成AIの利用ルールなども重要になっています。「自社で全部作る」だけでなく、「選び、つなぎ、継続して使う」仕事が増えています。
情シス内部の組織構造も知っておこう
情シスの中でも、役職による判断権限と、業務領域による担当分担があります。例えば、次のような体制です。
| 組織内の立場 | 主な仕事・責任 |
|---|---|
| 部門長・管理者 | 部門方針、予算・人員、優先順位、重要案件の判断・承認 |
| 主任・チームリーダー | 担当領域の進捗・品質・費用の把握、課題整理、担当間の調整、管理者への上申 |
| 担当者 | 自担当システムや業務の把握、要件の確認、ベンダ窓口、試験・課題管理の実務 |
これとは別に、企画・開発、運用・保守、社内IT支援などの担当グループが置かれることもあります。企業規模によっては兼務も珍しくありません。若手は担当するシステムと業務を理解するところから始め、主任クラスでは担当領域を横断して課題や判断をつなぐことが期待されます。
情シス担当者の周囲に、誰がいるのか
新任担当者は、まず社内外の関係者を整理してください。情シスはすべてを一人で決める部署ではありません。
| 関係者 | 主な役割 | 情シス担当者との接点 |
|---|---|---|
| 経営層・事業責任者 | 投資目的・予算・事業上の優先順位を判断 | 投資の根拠、重大な判断事項を報告する |
| 情シスの管理者・責任者 | 担当範囲、要員、部門としての判断・承認 | 方針の確認、課題の上申、意思決定の依頼 |
| 業務部門・システム利用者 | 業務要件を示し、業務仕様を確定・受け入れる | 現行業務を確認し、変更案や試験結果をすり合わせる |
| SIer・導入ベンダ | 技術方式の検討、設計・実装、技術試験、保守支援 | 仕様・見積り・進捗・品質・障害対応を協議する |
| 取引先・外部サービス | データ連携、取引条件、外部サービスの提供 | 業務責任者と協力して接続条件や変更可否を確認する |
図 新任情シス担当者の組織内の位置と社内外の関係者
担当者の仕事は「すべての関係者を指揮すること」ではありません。情報を集め、論点を整理し、権限のある人が判断できる状態を作ることです。ベンダへ技術的な詳細を任せても、判断の所在を曖昧にしないことが大切です。
【実体験】仕事が進む発注者は、決める人が明確だった
私が関わったプロジェクトの中には、発注側がキックオフMTGを自ら仕切り、業務仕様を決める責任者を当初から明確にしている案件がありました。業務ごとに課長級の責任者が判断し、SIerは論点の整理や技術的な選択肢の提示で支援する、という役割分担です。
反対に、発注側の業務部門間で意見が割れた際、ベンダが合意形成まで引き受けてしまうと、あとから「そういう意味で承認したのではない」という行き違いが起こります。業務部門間の合意形成は発注側が主導する。技術的な実現方法はSIerが主体的に設計する。 この線引きは、最初の会議で確認しておきたいことの一つです。
企画・開発・運用で、情シスは何をするのか？
情シスは、システム開発の特定の工程だけに関わるわけではありません。企画から導入、運用、効果の確認まで、仕事がつながっています。
| 段階 | 情シスが確認・推進すること | SIerに期待すること |
|---|---|---|
| 企画・調達 | 導入目的、対象業務、予算、関係者、RFP（提案依頼書）、評価基準 | 技術的な実現性、概算費用、制約・リスクの提示 |
| 要件定義 | 業務要件・非機能要件、業務責任者の合意、優先順位 | 要求の具体化、技術的な論点整理 |
| 設計・開発 | 重要な仕様のレビュー、変更影響の確認、課題の判断 | 技術方式・詳細設計・実装・内部品質の確保 |
| 試験・導入 | 試験方針のレビュー、業務受け入れ、移行判定、利用者への周知 | 技術試験、不具合解消、移行の準備と実施支援 |
| 運用・改善 | 障害の業務影響、運用費、改善要望、導入効果 | 契約に基づく運用・保守、原因分析、改善提案 |
図 発注側とSIerが工程ごとに担う作業
システム開発は、新しい機能を作る仕事だけではありません。既存システムを新しい環境へ移行する「システム更改」でも、現行調査、設計、試験、データ移行、運用引継ぎなど、多くの作業が発生します。
具体的な開発プロジェクトの進め方は、次の記事「システム更改で学ぶ、プログラミングだけではない仕事の全体像」で紹介しています。
発注側は「何を実現するか」を決める
業務要件や優先順位は発注側が決めます。一方、実現するための技術方式や物理設計は、SIerが専門家として主体的に検討・設計します。発注側は、その内容が自社の要求に合っているかを理解して承認します。
例えば、データベースの索引をどう設計するかまで情シスが指定する必要はありません。しかし、必要な性能や運用条件が満たされるか、費用にどのような影響があるかは確認すべきです。技術方式が業務や投資判断に大きく関わるなら、SIerが代替案を説明し、発注側と合意して進めます。
任せることと、丸投げすることは違います。
【実体験】RFPの一行から、設計上の論点を引き出す
以前、RFPに「オンライン受付は夕方で終了するが、必要に応じて延長できること」とだけ書かれていたことがあります。
SIerとして確認したいのは、延長をいつまでに申し込むのか、誰が承認するのか、延長範囲はシステム全体か処理単位か、延長対象外の接続はどう扱うのか、といった点です。帳票作成などの非同期処理が終了時刻をまたいだらどうするのかも確認が必要です。
私は質問表で条件を一つずつ確認し、パッケージの標準機能で実現できるか、追加開発が必要かを整理しました。他社パッケージの対応状況も検討材料にしつつ、発注側には「本当に必須か」「代替案を認められるか」を質問しました。
入札で質問・回答が参加各社に公開される場合、こうした質問は、発注側が自らの要求を具体化する機会にもなります。ベンダからの質問が多いことは、必ずしも悪い兆候ではありません。曖昧な要求を放置して進める方が危険です。
ある失敗ケースで考える、誰が何を確認すべきだったのか
ここまで説明した役割が欠けると、何が起こるでしょうか。問題を見つけやすいよう、あえて単純化した極端な例で考えてみます。実際の個別案件を紹介するものではありません。
経験者にとっては初歩的な確認漏れに見える内容ですが、開発を初めて担当する人には、そもそも何を確認すべきか分からないこともあります。まず「誰が、どの段階で気づけたか」を意識して読んでみてください。
取引先との連携で起きたこと
ある企業が、受発注管理システムをクラウドサービスに移行します。通常のデータ送受信は確認できていましたが、本番切替前の外部接続リハーサルで、受信確認が届かなかった場合の再送を試すと、同じ注文が二重に登録されました。
取引先との間には「注文番号で同じ注文を判定し、重複登録しない」という条件がありました。しかし、移行先サービスの標準機能は、その取引先固有の条件に対応していませんでした。この差異が、要件・設計・試験の確認対象から漏れていたのです。導入ベンダは技術的な対応案と費用・期間・リスクを提示し、発注側は業務への影響を検討した結果、追加対応と本番切替の延期を判断しました。
本来、再送時の重複登録防止は、要件定義・設計・試験で扱うべき基本的な確認事項です。本番切替直前まで残るのは重大な品質管理上の問題です。
さて、どの役割を果たしていれば、もっと早い段階で発見できたでしょうか。
欠けていた活動と、本来すべき活動
| 活動 | このケースで欠けていたこと | 本来すべきこと | 主な担当 |
|---|---|---|---|
| 業務要件の確認 | 連携ファイルの形式だけを見て、運用上の条件を拾わなかった | 現行運用担当・業務部門・取引先に再送時の取り決めを確認 | 発注側が情報収集、SIerが確認観点を提示 |
| 技術検討・設計 | 標準機能との差異と重複防止方式を詰めなかった | 連携の正常系・異常系を設計し、方式を評価 | SIer |
| 試験計画 | 通常送受信だけを確認対象にした | 再送・重複・通信障害などを試験項目に入れる | SIerが計画・試験、発注側が方針をレビュー |
| 外部調整 | 取引先との運用変更可否が未決定 | 変更する条件と合意責任者を明確にする | 発注側の業務責任者 |
| 課題・リスク管理 | 未確認事項が放置された | 担当・期限・影響・判断先を管理する | 双方 |
これは発注側だけの失敗でも、SIerだけの失敗でもありません。専門家が確認すべき技術的論点と、発注側が把握・判断すべき業務条件が結び付かなかったことにあります。
また、対応には品質（Quality）・費用（Cost）・納期（Delivery）、いわゆるQCDの観点が必要です。追加開発するか、取引先と条件を見直すか、安全に管理できる範囲で暫定対応するか。SIerが影響と選択肢を提示し、発注側が事業上の優先順位を踏まえて判断します。
この例から学んでほしいのは、極端な失敗そのものではなく、要件と試験の対応を追い、抜けている確認事項に気づく視点です。後半のVモデルの説明にもつながります。
今回のケースは、問題点を分かりやすくするために単純化した例ですが、上流工程で確認すべき事項を残したまま進めると、後工程で手戻りが発生するという構造は、実際のプロジェクトにも共通します。
別の例として、AWSへのクラウド移行で事前検証（PoC）が不足し、設計上のリスクが構築・試験段階で表面化する問題を次の記事「クラウドリフトの失敗は構築前に始まっている」で解説しています。
開発が終わってからが本番。運用と導入効果はどう評価する？
システムが予定どおり完成し、ベンダによる試験を通過したら成功でしょうか。情シスの評価は、そこで終わりません。
「作れたか」と「成果が出たか」は別の評価
開発段階では、必要な品質を確保できたか、予算と納期を守れたかというQCDが重要です。一方、導入後には、業務が実際に改善したか、投資に見合う便益が生まれたかを確かめる必要があります。
| 観点 | 主な問い | 確認する時期・担当 |
|---|---|---|
| 開発のQCD | 約束した機能・性能を、求めた品質・費用・時期で実現できたか | 開発中〜受け入れ時。発注側とSIerで確認 |
| 運用品質 | 安定して使え、障害時に業務を継続・復旧できるか | 稼働後。情シスと運用・保守担当 |
| 導入効果・ROI | 業務時間、誤処理、売上などが改善し、投資に見合ったか | 稼働後。情シスが業務部門・経理等と評価を主導 |
図 QCDと導入効果ROI
SIerはシステムが要求に沿って稼働しているかを検証できます。しかし、部門の実際の工数や取引の改善、事業上の収益への影響を、SIerだけで測ることはできません。業務の成果を測る責任は発注側にあります。
導入前にKPIと測定方法を決めておく
例えば、受注処理の効率化が導入目的なら、稼働前後で「処理件数」「担当者の作業時間」「手戻り件数」などを比較します。
仮に月400時間かかっていた処理が、導入後280時間になれば、月120時間、年間1,440時間の削減です。時間当たり3,000円で換算すると、年間432万円分の工数に相当します。
ただし、432万円がそのまま会社の現金支出削減になるとは限りません。 実際に残業代や外注費が減る場合もあれば、空いた時間を別の業務に振り向ける場合もあるからです。後者は生産性向上という効果ですが、費用削減と同じものとして扱ってはいけません。
このため、KPIは企画段階で決め、測定方法、導入前の数値、導入後の測定時期、データを持つ部署まで定めておきます。導入後に慌てて効果を測ろうとしても、比較する基準が残っていないことがあります。
ROIは「便益」と「費用」を同じ期間で比較する
ROI（Return on Investment、投資利益率）は、投資に対してどれだけの利益が得られたかを見る指標です。簡易的には、ROI＝（便益－費用）÷費用×100％で計算できます。比較期間と費用・便益の範囲をそろえることが前提です。
先ほどの年間432万円は、削減した作業時間の金額換算例でした。ここからは、それとは別に、実際に外注費などの支出を減らせると仮定した試算を示します。
初期投資900万円、削減できる費用が年間480万円、新しいシステムの運用費が年間80万円の場合、年間の差引便益は400万円です。単純な投資回収期間は、900万円÷400万円＝2.25年（約2年3か月）となります。
同じ条件を3年間で評価すると、次のようになります。
| 3年間の評価項目 | 金額 |
|---|---|
| 便益（480万円×3年） | 1,440万円 |
| 初期投資 | 900万円 |
| 運用費（80万円×3年） | 240万円 |
| 総費用（初期投資＋運用費） | 1,140万円 |
| 差引便益（便益－総費用） | 300万円 |
したがって、3年間の簡易ROI＝300万円÷1,140万円×100≒26.3％です。これは物価変動や資金の時間価値、税金、追加改修費用などを考慮しない説明用の試算です。
実務ではクラウド利用料、保守契約、ライセンス更新、追加改修、利用部門の負担なども評価対象に含めます。また、内部統制の強化や顧客サービスの改善など、金額にしにくい効果は、ROIと併せて別のKPIで評価します。
安定運用・障害対応・次の更改にも責任がある
稼働後の監視、バックアップ、障害復旧、更新作業などは、契約によってSIerや運用ベンダが担うことも多い仕事です。それでも情シスには、障害の業務影響を把握し、復旧の優先順位を決め、関係者に連絡し、改善の必要性を判断する役割があります。
導入後の効果が低ければ、運用を見直すのか、追加改善するのかを検討します。老朽化による「守りの更改」だけでなく、新しい事業のために仕組みを変える「攻めの更改」もあります。システムを知るベンダとは、稼働後もパートナーとして適切に連携しておきたいところです。
若手・主任クラスの情シス担当者が身につけたい実務能力
「業務を理解する」「関係者と円滑にコミュニケーションする」といった心得だけでは、日々の仕事で何をすればよいか分かりません。そこで、現場でベンダの窓口を担う若手が、主任クラスを目指す際の具体的な到達目標を示します。自担当システムの全体像を説明でき、計画書や報告書にある重要な抜けに気づけることが、一つの目安です。
① 自担当システムの構成と費用を説明できる
まず、担当システムがどの業務を支え、どのシステムと連携しているかを説明できるようにします。主要なサーバ・クラウドサービス、データベース、ネットワーク、認証、外部連携先を、構成図で指し示せる水準が目標です。
また、障害が起きるとどの部署や取引先に影響するか、バックアップや復旧の仕組みはどうなっているかも押さえます。自分が全装置の設定をできる必要はありませんが、どこが止まれば何が止まるのかを説明できることが大切です。
費用面では、初期開発費だけでなく、保守費、クラウド利用料、ライセンス、回線、外注費などの構造を理解します。「今の費用は何に対して払っているのか」「利用量が増えたらどこが増額するのか」が分かれば、更新や追加投資の相談にも参加できます。
② プロジェクト計画書をレビューできる
ベンダから計画書を受け取ったとき、「専門家が作ったから問題ない」と受け取るのではなく、次の点を確認します。
以下の10の観点は、PMI（Project Management Institute）の「PMBOKガイド」第6版※に示された10の知識エリアを参考に、情シス担当者が計画書をレビューするときのチェックポイントとして整理したものです。PMBOKを覚えることが目的ではなく、管理上の確認漏れに気づけるようになることが目的です。
※最新版はこちら
| 管理の観点 | 主任クラスを目指す担当者のチェックポイント |
|---|---|
| ① 統合・変更管理 | 全体計画と各社の計画がつながっているか。変更の申請・影響評価・承認方法はあるか |
| ② スコープ | 対象業務、対象外、成果物、発注側とSIerの作業境界が明確か |
| ③ スケジュール | 主要な節目、他部署・他社との依存関係、受け入れ期間は明確か |
| ④ コスト | 予算、見積り前提、追加費用が発生する条件が明確か |
| ⑤ 品質 | 機能・非機能要件の確認方法、レビュー・試験計画、合否判定基準は明確か |
| ⑥ 資源・体制 | 必要な要員、スキル、担当責任者、要員不足時の対応は決まっているか |
| ⑦ コミュニケーション | 会議体ごとの目的・出席者・決定事項、報告経路は明確か |
| ⑧ リスク | 重大リスクと未確認事項、対応担当、期限、判断先が整理されているか |
| ⑨ 調達・契約 | 委託範囲、契約上の責任境界、複数ベンダの調整方法が明確か |
| ⑩ ステークホルダー | 業務責任者、利用者、承認者、取引先など関係者を特定できているか |
10の観点が一冊の計画書にすべて詳しく書かれているとは限りません。 体制図、品質計画書、課題・リスク管理表などの関連資料も合わせて確認します。大切なのは、各観点について、確認先の文書や担当者を把握し、必要な質問ができることです。
③ Vモデルを理解し、品質の確認方法に目を向けられる
Vモデルは、要件・設計の各段階と、それを検証する試験の対応を考えるための代表的なモデルです。詳細な開発手順が異なるプロジェクトでも、「その要求は、どの試験で確かめるのか」という問いは役立ちます。
情シスの担当者がまず見るべきなのは、RFPや要件定義書に、機能だけでなく非機能要件が書かれているかという点です。非機能要件には、例えば性能、可用性、セキュリティ、バックアップ、障害時の復旧、運用条件などがあります。
非機能要件の中でも、セキュリティは発注側とSIerの認識を合わせておきたい重要な領域です。「セキュリティを強化する」といった抽象的な要求ではなく、どのリスクに、どこまで対応する必要があるのかを明確にすることが求められます。
具体的な検討方法は、次の記事「セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法」で解説しています。
次に、基本設計の内容が要件を反映しているか、基本設計に対応するシステム試験などで、必要な動作を検証できるかを確認します。正常系だけでなく、異常系、ピーク時の性能、障害復旧、外部連携の例外処理まで視野に入れます。今回の重複登録のケースは、まさにこの確認が欠けた例です。
個々の詳細なテストケースを情シスがすべて作る必要はありません。しかし、重要な機能・非機能要件に対して、どの試験で何をもって合格とするのかを説明してもらえることは、品質レビューの基本です。発注側による受け入れ試験は、技術試験の繰り返しではなく、実際の業務が成立するかを判断する場です。
図 Vモデルと要件試験の対応
重要なのは、試験項目の数だけを見ることではなく、要件や設計で決めた内容を、対応する試験で確認できるかという視点です。
この考え方については、次の記事「Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方」で詳しく取り上げています。
④ 会議体の目的・参加者・決定権限を見抜く
プロジェクト計画書に「週次定例会を実施」と書かれていても、それだけでは足りません。その会議が報告のためなのか、課題を解決する場なのか、正式に意思決定する場なのかを確認します。
| 会議体の例 | 目的 | 特に確認したいこと |
|---|---|---|
| 進捗定例会 | 進捗・遅延・次の作業の確認 | 遅延時の対応責任者、判断が必要な事項の上申先 |
| 課題・リスク会議 | 未解決事項と重大リスクの管理 | 担当・期限・影響、解決できない場合の判断者 |
| 業務仕様の調整会議 | 部門をまたぐ要求や運用の合意 | 業務責任者が参加し、決定権限が明確か |
| 品質・移行判定会議 | 工程完了、受け入れ、切替可否の判断 | 判定基準、証跡、承認者、持ち越し条件 |
ここで目を配りたいのは、「何を決める会議か」「決められる人が出席しているか」「決められないときは誰に上げるか」の3点です。会議が多くても、意思決定の経路が曖昧では意味がありません。
【実体験】全体統括は、すべての詳細調整を引き受ける仕事ではない
複数のベンダが参加する移行プロジェクトで、私は全体統括を担当したことがあります。各社の作業に依存関係があったため、要員を増やして重要な会議の参加漏れを減らし、各社のキーマンと直接連携しました。曖昧な回答が他社の作業の前提になっていないかを確認し、顧客側の責任者にも日々状況を報告しました。
ある会議を欠席した際、アプリケーション間の詳細仕様の調整を、私たち統括が担う前提で話が進みかけていました。しかし、統括は個々の業務仕様の詳細を把握している立場ではありません。発注側の担当者から連絡を受け、具体的な調整は担当者同士で進め、統括は課題の管理と必要な調整会議への参加を担う形に整理しました。
全体統括は、情報を集め、横断的な影響と課題を管理します。何でも自分が引き受けるわけではありません。なお、契約関係のない会社同士で調整する場合も、仕様変更や費用・納期に関わることは、発注者を含む正式な場で決めるべきです。
この経験は情シスの現場担当者にも通じます。各人の責任を明確にし、必要な情報を取りに行き、判断を適切な人へつなぐことが重要です。
⑤ 導入効果を自分の言葉で報告できる
最後は、開発したシステムを「使った成果」で説明する力です。稼働後のKPIは改善したか、運用費に見合う効果があるか、どこに次の改善余地があるか。業務部門と計画値・実績値・差異の原因を確認し、改善の選択肢と次のアクションを添えて情シス管理者に報告できる水準を目指します。
主任クラスに期待されるのは、すべてを一人で解決することではありません。構成・コスト・品質・関係者・導入効果をつないで、プロジェクトや運用の全体像を説明できることです。そこまで視野が広がれば、ベンダとの協議も、計画書のレビューも、単なる報告の受け手から一段進んだ仕事になります。
まとめ：情シスは、ITを業務の成果につなげる仕事
情シスは、システムを発注するだけの部署ではありません。経営や業務の目的を理解し、関係部署とSIerをつなぎ、開発中の判断や品質確認を行い、導入後の効果まで確かめる役割を担います。
新任担当者は、まず自分の周囲の関係者、担当システムの構成、費用、判断権限を把握してください。そのうえで、ベンダの計画書や試験方針を読み、「何を根拠に大丈夫と判断するのか」を質問できるようになることを目指しましょう。
技術は専門家に任せる。しかし、業務上の判断と導入成果の確認まで丸投げしない。 これが、SIerの立場から新任情シス担当者に最も伝えたいことです。
コメント