“再構築プロジェクト”だからこそ知っておきたい、上流工程 ......“再構築プロジェクト”だからこそ知っておきたい、上流工程におけるコミュニケーションのツボ

Software Reliability Enhancement CenterCopyright © 2017 IPA, All Rights Reserved

Information-technology Promotion Agency, Japan

Software Reliability Enhancement Center

“再構築プロジェクト”だからこそ知っておきたい、

上流工程におけるコミュニケーションのツボ

独立行政法人情報処理推進機構（ＩＰＡ）技術本部ソフトウェア高信頼化センター（ＳＥＣ）

モダナイゼーションWG委員（東京海上日動システムズ株式会社）

内藤克郎

2017年3月10日

2Copyright © 2017 IPA, All Rights Reserved Software Reliability Enhancement Center

目次

1.会社概要

2.はじめに

3.事例紹介

4.最後に


１．会社概要

会社概要

設立 1983年9月

資本金 5,000万円（東京海上日動火災保険全額出資）

事業内容東京海上日動火災保険、東京海上日動あんしん生命保険等、

東京海上グループの情報システムの企画・提案・設計・開発・保守・運用

売上高 16,777（百万円）（2016年3月期）

事業所東京都多摩市（本社）

社員数 1,362名（男性945名、女性417名）(2016年4月1日現在）

平均年齢 38才

本社〒206-8510 東京都多摩市鶴牧2-1-1 多摩東京海上日動ビル


２．はじめに

・プロジェクトにおいて、コミュニケーションが大切なこと、そして、上手に取ることが難しいことを誰もが知っています。

・特に上流工程におけるコミュニケーションは、そのプロジェクトの行方を左右するとても重要な要素の１つとなります。

・今回、再構築プロジェクトを題材に事例を交えてお話させて頂くことで、押さえておきたいコミュニケーションのツボ（キーワードや場等）をお伝えします。


３．事例紹介

（１）”現行踏襲”という言葉に潜む罠

（２）ドキュメントの扱い方

（３）エスカレーション環境を整える


３.（1）”現行踏襲” という言葉に潜む罠

＜システム概要＞保険契約を更新頂く際、更新前後の補償や保険料の差異をわかりやすくするための比較表を作成するオフラインシステム

＜プロジェクト概要＞◆オンライン化することでメインテナンスロード削減◆機能は “現行踏襲”で実現

比較表作成システム






一括作成できる数に差異有！！

⇒一括作成数上限値の再検証＆本番稼働日延期

＜発生した問題（システムテストフェーズ）＞

オフラインシステムでは、大量の契約比較表を一括作成可能であった（ある意味、無制限）

一方、オンラインシステムでは、一括作成数に上限を設ける必要があった





＜ポイント＞

“現行踏襲”は、立場によって解釈にギャップが生じるリスクがあることを認識すべき

ドキュメントだけではわからないことを疎かにしない（特に、非機能要件や使い勝手の面）

多角的な視点で分析する

ユーザヒアリング、既存システムでいろいろ試してみる等


３.（2）ドキュメントの扱い方

＜システム概要＞UNIXサーバ上に構築されたオンラインシステム

＜プロジェクト概要＞◆WEBサーバのハードウェア保守切れに伴うリプレース◆サーバ集約を行い、運用コスト・ロードを削減◆基本的には単純移行のため、基盤担当主体で対応・Javaバージョンアップに伴う非互換対応・OS変更に伴う文字コード変換対応

・非互換対応・文字コード変換対応




・非互換対応漏れ・文字化け多発

⇒変換作業のやり直し＆要員を大幅に増員しての全画面再検証

＜発生した問題（システムテストフェーズ）＞

非互換対応の洗出し漏れがあり、動かないアプリケーションが複数発生

文字コード変換対応漏れがあり、文字化け多発！！




＜ポイント＞

必ずしも、ドキュメントがすべてではない（当システム構築当初のアプリ設計ガイド）

アプリ開発者と、“より具体的な内容”で会話をしておければ防げた可能性がある（リプレースに伴う変更点だけではなく、調査範囲や方法を具体的に説明する場を設ける等）


３.（3）エスカレーション環境を整える

＜システム概要＞メインフレーム上に構築された経理システム

＜プロジェクト概要＞◆老朽化対策ならびに四半期決算や国際財務報告基準(IFRS)等の環境変化へ柔軟に対応したい◆ERPパッケージ導入、BPR(※)を行わない（本番稼働優先）◆要求実現可否を分析するフィージビリティ期間を確保※ BPR：Business Process Re-engineering

・老朽化・柔軟性の確保



【ステアリングコミッティ】参加者ユーザ部門部長IT部門部長、PM、PMOベンダー営業責任者、統括責任者、PM、PMO

＜ポイント＞

ユーザ部門、IT部門、ベンダーの３者の部門長によるステアリングコミッティを設置し、関係者へ周知

プロジェクト進捗報告ならびに、大きな課題等を論議し、その場で方向性を確定



・老朽化・柔軟性の確保

⇒好取組み事例として社内情宣ステアリングコミッティの重要性認知度Up！！

＜実施効果＞

意思決定スピードの向上

組織的な対応力が求められることにより、プロジェクト推進力が強化

品質を確保しつつ、当初計画通りの期限およびコストで本番稼働


４．最後に

「システム再構築を成功に導くユーザガイド」

・２０数年の会社生活において、基盤担当・アプリ担当・PMOといった様々な立場で、多くのプロジェクトを経験させてもらいました。

・その経験（多くは反省！？）を踏まえ、かつ、出来るだけユーザー企業の方にわかりやすい表現にしました。

・是非とも手に取って頂き、少しでも皆さまの悩み解決の支援ができればと考えています。


ご清聴、ありがとうございました。

Documents

“再構築プロジェクト”だからこそ知っておきたい、 上流工程 ......“再構築プロジェクト”だからこそ知っておきたい、 上流工程におけるコミュニケーションのツボ

“再構築プロジェクト”だからこそ知っておきたい、上流工程 ......“再構築プロジェクト”だからこそ知っておきたい、上流工程におけるコミュニケーションのツボ