福祉・保険サービスの基幹システム更改という高い品質要求が課されたプロジェクトに、私たちのチームはどのように向き合い、乗り越えてきたのか――。
本記事では、弊社が実際に取り組んだプロジェクトから、トラブル対応やドキュメント整備に込めた現場目線の工夫、そしてコミュニケーションを軸とした信頼構築のプロセスなどを、実際の会話やエピソードを交えてご紹介します。
「品質」と「現場」を両立させるために何が必要だったのか。そのリアルな記録をお届けします。

【関連記事】SIerの課題を解決！PMOの導入メリットとは

本プロジェクトの概要と課題の整理

今回のプロジェクトは、福祉・保険サービスを提供する団体が長年利用してきた基幹業務システムの更改を目的としています。背景には、従来のシステム基盤サービスの終了があり、現場業務を止めずに新たなインフラへ移行することが最大のミッションです。対象となるのは、利用者情報の管理、給付金支給、各種申請受付など、日々の運用に直結する重要な業務です。

プロジェクトには自社社員（プロパー）6名とビジネスパートナー7名、計13名が参画し、要件定義から移行・運用まで約10か月間にわたって取り組みました。全体の開発・テスト工数は延べ約400人日規模となりました。

「現場を混乱させないことが大前提。まずはヒアリングの徹底を心がけました。」（現場担当者）

プロジェクトの背景

福祉・保険分野のシステムは、法改正や社会情勢の変化に応じて、柔軟に対応し続ける必要があります。今回のシステム更改プロジェクトでも、現場での運用や利用者サービスに影響が出ないよう、移行の計画が求められました。

「制度が変わるたびに現場のやり方も変わるので、細かいところまで現場の声を拾うようにしています。」（現場担当者）

基幹システムの基盤サービス終了が正式に通知されたことで、「このままでは業務が継続できない」「利用者に迷惑をかけてしまう」といった懸念が現場に広がりました。システムの安定稼働が利用者の生活や信頼に直結するため、早急な対応が必要とされました。

「このままじゃ困る、という声が現場からたくさん上がってきました。」（運用リーダー）

顧客からの品質要求

今回のプロジェクトで特に重視されたのは、品質に対する厳しい要求です。
主な要求事項は以下の通りです。

• すべての成果物に対して第三者レビューや二重チェックを必須とする
• 品質マネジメントシステム（QMS）に基づいた厳格な運用
• 業務停止やデータ不整合が一切許されない

「品質には絶対に妥協しないでほしい、と最初に言われました。正直、緊張感はありました。」（開発メンバー）

高い品質要求の背景には、福祉・保険分野の業務が社会的責任の大きいものであること、そしてシステムの信頼性や透明性がこれまで以上に求められているという事情があります。

現場の声とコミュニケーションの重要性

現場の担当者からは、以下のような声が上がっていました。

• 「制度改正やシステム変更のたびに業務フローが変わり、現場が混乱しがち。」
• 「現場の声をしっかり反映したシステムにしてほしい。」
• 「トラブルが起きた場合の対応力も重視したい。」

「また現場が混乱するんじゃないかという不安がありました。だから、私たちの意見をしっかり聞いてもらえるのはありがたかったです。」（現場リーダー）

こうした声に応えるため、現場・開発・運用の三者が密に連携し、コミュニケーションを重視したプロジェクト運営が不可欠でした。定例会議やチャットツールを活用した情報共有、勉強会やQAセッションを通じた知識の共有など、コミュニケーションの質と量を高める取り組みが計画されました。

「小さな疑問もすぐに相談できる雰囲気を作ることを意識しました。」（プロジェクトリーダー）

プロジェクトチームの体制と課題

今回のプロジェクトチームには、いくつかの課題がありました。

• 既存システムに精通したメンバーが少ない
• プロジェクトリーダーは初めてのマネジメント経験
• 過去の仕様変更や改修履歴の把握が難しい
• 短期間でのシステム更改と高品質な成果物の両立

「自分が知らないことは、他の誰かも知らないかもしれない。だから、みんなで知識を持ち寄るようにしました。」（開発メンバー）

これらの課題を乗り越えるため、部門長がサポート役として加わり、リーダー育成も意識した体制が組まれました。また、リスク管理表を活用し、課題やリスクを「見える化」して早期対応を目指すことも決まりました。

「一人で悩まず、みんなで相談できる雰囲気を大切にしました。」（部門長）

初期対応と体制づくり

初期段階では、次のような対応が取られました。

• 勉強会やQAセッションを開催し、既存システムや新しいインフラについて知識を共有
• 週次定例会議や日常的なチャットで情報共有を徹底
• 全員が「自分の知らないことは、誰かも知らないはず」と考え、率直に質問し合える雰囲気づくり

「質問しやすい雰囲気ができてきたことで、細かいミスや不安も早めに解消できるようになりました。」（開発担当）

こうしたオープンなコミュニケーションは、品質向上と現場の安心感につながる重要なポイントです。

このような体制と課題をもとに、プロジェクトは本格的に動き始めました。
次章では、チームの組成から作業開始までの具体的な取り組みを紹介します。

チームの組成と作業開始まで

システム更改プロジェクトの発足が決まり、最初に取り組んだのは、実行部隊となるチーム体制の構築でした。今回のプロジェクトは、プロパー6名、ビジネスパートナー7名の総勢13名体制。役割ごとにPM（プロジェクトマネージャー）、PL（プロジェクトリーダー）2名、開発担当、検証担当、ヘルプデスク（現場業務に密着した問い合わせ対応担当者）など、機能的に分かれたチーム編成としました。各担当がそれぞれの専門性を活かしつつも、分野を越えた協力体制を築くことを重視しました。

「プロジェクトリーダーが初めてのマネジメントということもあり、部門長がサポート役としてしっかり入る体制を作りました。」（部門長）

サポート体制とリーダー育成

今回、PM・PLには若手と経験者がペアで配置されました。リーダー経験が浅いメンバーには部門長が伴走し、進捗管理や意思決定の場面でアドバイスやサポートを行う方針を取りました。
また、ヘルプデスク担当や検証担当も早い段階からプロジェクトに加わり、ユーザーから寄せられる問い合わせや運用現場の声をプロジェクトに反映できるようにしました。

「最初は不安もありましたが、“困ったらすぐ相談できる”という安心感がありました。」（プロジェクトリーダー）

知識の共有と底上げ

既存システムに精通したメンバーが少なかったため、知識の共有と底上げはプロジェクト初期の最重要テーマでした。勉強会は「調査・報告・質問・回答」の場として機能し、各担当が自分の調べた仕様や運用のポイントを持ち寄りました。

ある日の勉強会のやりとりです。

「帳票出力の仕様を調べたのですが、現行システムではCSV形式での一括出力が標準のようです。ただ、帳票ごとに出力条件が異なっていました。」（開発担当）

「その出力条件って具体的にどう違うんですか？」（検証担当）

「利用者情報の帳票は、申請日ごとにまとめて出力ですが、給付金支給の帳票は月単位でしか出せない仕様です。」（開発担当）

「ユーザーから“日単位での出力ができないと困る”という問い合わせが以前ヘルプデスクに寄せられました。今回の更改では日単位でも出力できるか確認したいです。」（ヘルプデスク担当）

このように、各自が調べた内容を持ち寄り、疑問点やユーザーからの要望をその場で共有・解決することで、知識のギャップを埋めていきました。

情報共有とコミュニケーションの工夫

チーム内外の情報共有とコミュニケーションの質は、プロジェクトの成否を左右する重要な要素でした。
毎週の定例会議では、進捗状況や課題、今後の予定を全員で確認し、議事録はすぐに共有されます。日常のチャットやショートミーティングも活発で、開発・検証・運用・ヘルプデスクの垣根を越えたやりとりが生まれました。

ある日、チャットでのやりとりです。

「昨日の申請処理、少し遅れが出ていましたが、何かトラブルありましたか？」（検証担当）
「サーバの一部でレスポンスが遅くなっていました。今朝は復旧していますが、念のため監視を強化します。」（開発担当）
「ユーザーからの問い合わせがあった場合は、ヘルプデスクで状況を整理して連携します。」（ヘルプデスク担当）

また、プロジェクトの要所ではクライアント（顧客）側にも積極的に情報提供と協力を呼びかけました。

「仕様変更や運用ルールの確認が必要な場合は、クライアント側のご担当者にも参加いただき、ヘルプデスクに寄せられた問い合わせ内容も共有しました。」（プロジェクトリーダー）

「今週の進捗報告会では、今後のテスト計画についてもご説明しますので、ご担当者のご意見をぜひお聞かせください。」（開発担当）

こうした工夫により、クライアント側との認識合わせや協力体制も強化され、ユーザーや運用現場の実情や要望を反映したプロジェクト運営が実現しました。

品質管理への意識と役割分担

プロジェクトの特徴の一つが、全員が品質管理の役割を自覚していた点です。セルフチェックや内部レビューは各工程で必須とし、成果物の品質を担保するためのルールを明確にしました。レビューの際には、経験の浅いメンバーも積極的に意見を出し合い、気になる点があれば遠慮なく指摘する文化が根付きました。

「自分の作業だけでなく、他の人の成果物も“もう一度見る”ことで、ミスや抜け漏れに気づきやすくなりました。」（検証担当）

また、品質報告書の作成やリスク管理表の更新もチーム全体で分担し、品質向上のための取り組みを日常的に行いました。

作業開始に向けての準備と心構え

作業開始に向けては、各担当が自分の役割を明確にしながら準備を進めました。ヘルプデスク担当は、システム移行時に想定される問い合わせやトラブルの内容を洗い出し、事前に対応策を検討。開発担当は要件定義や設計作業に入る前に、ヘルプデスクやクライアント担当者とのヒアリングを重ね、業務の流れや細かな運用ルールを丁寧に確認しました。

「ユーザーからどんな問い合わせが来るかを想像しながら、少しでも不安を減らせるように準備しました。」（ヘルプデスク担当）

運用・検証担当は、移行後のサポート体制やトラブル時の連絡フローなども整理し、どんな状況でも迅速に対応できるような体制づくりを進めました。

「何かあったときにすぐ動けるよう、事前にフローを確認しておきました。」（検証担当）

こうして、PM・PLを中心に開発・検証・ヘルプデスク・運用の各担当が一体となり、「業務を止めない」「品質に妥協しない」「コミュニケーションを絶やさない」という共通の意識を持ちながら、作業開始に向けて着実に準備を進めていきました。
次章では、実際の作業開始からトラブル対応、そして成果物の納品までのプロセスを詳しく紹介します。

トラブル対応と成果物の納品

本格的な作業開始後、要件定義をもとに基本設計・詳細設計を進め、現場の意見も反映しながらシステムの仕様を具体化しました。その後、各担当が分担してプログラムの製造（開発）を行い、セルフチェックやレビューを通じて品質を高める取り組みを重ねました。
設計・製造工程を経て、いよいよテスト工程と本番切替という山場を迎えます。これまで積み重ねてきた知識共有やコミュニケーション、品質管理の工夫が、現場でどれほど力を発揮するのか。チーム全員が期待と緊張を抱えながら、最終フェーズに臨みました。

テスト工程で発生した不具合と切替直前のトラブル

テスト工程が始まると、いくつかの想定外の不具合が発生しました。特に大きかったのが、帳票出力機能に関する問題です。日単位での出力対応を新たに実装しましたが、実際のデータ量が多い場合に処理が途中で止まる現象が発覚しました。

「テストデータを増やしたら、帳票出力が途中で止まってしまいました。」（検証担当）

「ログを確認したところ、バッファの設定が足りていませんでした。すぐに修正します。」（開発担当）

ヘルプデスクからは「本番環境で同じことが起きたら大変なことになる」という声もあり、全員が“現場目線”でのチェックを徹底しました。

トラブルが発生した際は、すぐにクライアント側にも状況を報告し、対応方針を共有しました。

「現在、帳票出力機能の一部で不具合が発生しています。原因の特定と修正作業を進めておりますので、進捗は随時ご連絡いたします。」（プロジェクトリーダー）

「本番切替までに十分な検証期間が取れるよう、修正版のリリース日程を再調整しましょう。」（クライアント担当者）

このように、トラブル時にはチーム内外で迅速に情報共有し、クライアントとも密に連携しながら対応を進めました。

本番切替を目前に控えた最終リハーサルでも、思わぬトラブルが発生しました。システム切替手順書の一部に記載ミスがあり、運用担当が手順通りに作業を進めたところ、想定外のエラーが発生したのです。

「手順書通りに進めたのに、途中でエラーが出ました。」（運用担当）

「どの手順で止まったのか、すぐに画面キャプチャを送ってください。」（QA担当）

この際も、クライアント側に状況を説明し、手順書の最新版を共有し直すなど、情報の行き違いがないよう細心の注意を払いました。

品質報告書とドキュメントの作成

品質重視のプロジェクトとして、品質報告書と各種ドキュメントの作成・管理には徹底的に取り組みました。

品質報告書は定期的に作成し、以下のような内容を詳細に記録・共有しました。

• 基礎数値・品質目標
  改修規模（プログラムのステップ数や対象機能数）、品質目標指標（テストケース数、不具合検出目標件数、重大不具合ゼロなど）
• テスト計画と進捗
  テストケースの一覧と消化状況（進捗率、未消化の理由）、テスト実施日程、各工程の完了予定と実績
• 不具合の発生・対応履歴
  不具合発生件数と分類（機能別・重要度別など）、発生日時、環境、再現手順、原因分析、影響範囲、対応状況（修正完了、再発防止策、未解決事項）
• 品質評価・リスク管理
  品質メトリクス（テスト通過率、バグ密度、レビュー指摘件数）、重大リスクの抽出と対応策、今後の課題、テスト消化曲線やバグ曲線などのグラフ化による可視化
• 各種ドキュメントの整備状況
  システム切替手順書、運用マニュアル、操作手順書、FAQ、障害対応フローの作成・レビュー履歴、ドキュメントの最新版管理、関係者への配布状況

これらの品質報告書は、テスト工程やリハーサルのたびに最新版を作成し、クライアントと共有しました。特に不具合の発生状況や品質評価指標は、表やグラフを用いて直感的に理解できるよう工夫し、関係者全員が現状と課題を正確に把握できるようにしました。

また、品質報告書の内容は定例会議や進捗報告会でも活用され、問題発生時の迅速な意思決定や、リスクへの先手対応につながりました。
さらに、運用現場やヘルプデスク、クライアントが実際に使うための運用マニュアルやFAQ、障害対応フローなども網羅的に作成し、全員が参照できるよう最新版を一元管理しました。

納品とその後

最終的に、システムは予定通り納品され、本番稼働を開始しました。納品後もヘルプデスクや運用担当と連携し、初期トラブルの有無や問い合わせ状況をモニタリングしましたが、大きな不具合や業務停止につながる問題は発生しませんでした。

プロジェクトを通じて得たもの

本プロジェクトを振り返ると、最も大きな成果は「品質要求への徹底した対応」と「コミュニケーションの力」だったと感じます。顧客から求められた高い品質基準に対し、私たちは品質報告書やテスト計画、ドキュメント整備を通じて、客観的かつ具体的に品質を可視化し、全員が同じ目線で課題と向き合うことができました。トラブル発生時にも、チーム内外で迅速かつ正確な情報共有を行い、クライアントとも一体となって問題解決に取り組めたことが、最終的な信頼と成果につながったと実感しています。

また、プロジェクトを通じてチームやメンバーの意識にも大きな変化が生まれました。役割や立場を越えた率直な意見交換や、知識・経験の共有が自然と根付くようになり、全員が「自分ごと」として品質や運用を考える文化が醸成されました。特に、若手リーダーや初参加メンバーの成長は目覚ましく、今後のプロジェクト推進に向けた大きな財産となりました。

今後もこの経験を活かし、顧客との信頼関係をさらに深めながら、「現場目線」「品質重視」「コミュニケーション重視」を軸としたプロジェクト運営を続けていきたいと考えています。