定量的システム開発プロセスの確立

企業の概要

社員数：500名
業界：金融
自社では開発を行わないが、業務部門から出てきた要件を自社のシステム開発部門で整理し、システム構築はシステムベンダーが行う流れとなっていた。また、一部のシステムは内製で構築していたため、自社でシステム開発業務もおこなう

参画ポジション

■開発部
各業務部門からの開発依頼を受け、システム要件定義を作成し、開発ベンダーが開発し、マネジメントを行う。

■じゅん（私の役割）
社内規定を守りつつ、効率的なプロジェクト運営が可能となるように部内の仕組みを整備する。

■企画管理部
ITガバナンス全般、予算・契約管理業務を行う。CIO直轄の改善施策を推進する。

■品質管理部
監査指摘を踏まえ、社内基準の整備を行い、品質向上のためのシステム障害の原因分析・根本対応推進を行う。

■運用部
インフラ整備を行い、キャパシティ監視によりシステム運用を実施。システム障害時の暫定対応を実施。

実施期間　：　1年間

依頼背景

開発規程をはじめとした組織的なITガバナンスの整備はできたが、実際の開発案件を進め、品質を上げるための整備が必要となった。
開発と保守は体制上分かれておらず、同一のチームが内部でタスク配分を行った上で対応している。

発生していた問題

• ITガバナンスに沿った運営はできているが、現場レベルでは効率の悪い運営になっている
• 社内規定は整備されていて、規定通りの運営はされているが、実際はシステムそのもの品質判断をするための十分な情報が揃っていないため、適切な判断ができない状況になっている。
• 特にテスト品質では、テスト実施件数のみが報告されテスト1件あたりの粒度や網羅性などの評価はされていない状況で、不具合抽出数はゼロで報告することが良いシステムとされ、不具合は抽出されなかったと報告されることがほとんどであった。結果的にシステムリリース後にシステム障害となって問題となるケースが発生している。
• 不具合が抽出された場合、発生箇所のみプログラム修正するため、原因の深掘りなどがされず、類似の不具合がそのままの状態でリリースされてしまう。
• プロジェクト運営は現場リーダーの肌感覚による報告を重要視する体質となっていた。
• システム開発における評価基準が統一されていないことで横断的な評価ができない
• 現在のリソース把握ができておらず、適切に稼働しているかわからず、リソース計画・評価ができていない。

実施施策

開発プロセスの体系化

■管理・実施手法の確立
プロジェクトの管理手法・フォーマット統一（計画書、WBS、課題・QA管理、テスト計画・進捗管理）プロジェクトの実行手法・フォーマット統一（影響調査、設計書）。活用指導。

■ドキュメント体系化
プロジェクト、システムごとに点在していたドキュメントの収集および体系的な整理
メンテナンスサイクルを定義し、運用定着を推進。

■再発防止対策サイクルの確立
システム障害の原因深堀・分析手法を構築。
類似対応を含む対策立案、対応優先度付けの運営を実施。

■最適化サイクル構築
プロジェクト計画立案・定量情報を基にした実績値測定、乖離時の対策、プロジェクト完了後の評価、定量情報の指標値の見直しを行うサイクルを確立。

■ベンチマークデータ構築
プロジェクト定量基準の作成（開発規模step数、開発期間、開発工数の定義）
一般公開情報、社内過去案件と比較したベンチマークデータの蓄積と社内指標の設定。

■テスト工程の管理手法確立
テスト方法の確立と定着化に向けた指導。（影響調査との紐付け、シナリオの作り方、シナリオ数・バグ発見数の目標の立て方）

■稼働タスクの一元管理
開発案件以外の工数影響のある保守案件を一元管理し、稼働メンバの工数把握ができるようにする。

■リソース管理サイクル構築
現状稼働情報の収集（メンバの稼働報告の仕組み確立）。メンバ別生産性（Kstep/人月）算出・評価（ベンダーの場合は契約見直し）。

実施結果

• 規定に沿ったプロジェクトを効率的に現場のプロジェクトマネージャーが運営できるようになった。
• 経験を基にした計画や訂正的な判断ではなく、定量的な情報を基に計画を立て、意思決定ができるようになった。
• プロジェクト定量化によって問題の早期発見と対策が可能となった
• 生産性を基にした人材評価を行うことでスキルに応じた評価と契約の見直しを行うことがあ可能になった。