CASE STUDY

開発プロセスおよび開発成果物に対する第三者品質検証

金融系の大規模システムの保守開発における、開発プロセス、中下流工程の成果物、本番障害に対して、第三者的に品質を検証し、単に成果物だけでなく、作業プロセスに関しての改善点などの指摘やアドバイスを実施し、システム全体(プロダクト品質およびプロセス品質)の向上を図りました。

業種:企業向け金融サービスのシステム運営会社(以下、「A社」という)

01

保守フェーズにおける品質向上の要請

障害が多発している状況に対する対策として、第三者による客観的な品質評価・検証が求められていた

A社が運営、管理する金融サービスの管理システムは、これまでのメインフレームでのシステムからVB.NETにより再構築されたシステムで2004年に稼働を開始した。オープン化の流れの中で、これまでのメインフレームでのシステムからWindowsプラットフォームを全面的に採用した。2004の稼働開始以降、親会社からの数々のサービスの改善や機能追加などに合わせて改修を重ねてきており、現在では、システムの全体規模は数百万ステップにおよんでいる。また、現在のアプリケーション開発については、再構築当時のメインとなったベンダー2社(以下、ベンダーX社、ベンダーY社とする)が引き続き担っている。なお、X社の下で、一部開発をオフショア(中国)で対応する体制としている。

現在、年間大小合わせて100件程度の改修案件(事務の堅確化、機能追加、潜在的不具合対応など)の対応が必要であり、常時100名ほどの体制で複数の案件が同時並行的に進められている。

こうした状況の中、利用者からの品質向上や数々のサービスの改善に強い要請が出ており、外部の第三者を入れての客観的な品質評価と改善を実施することとした。

02

アークシステムの提案

提示されたRFP、当社提案ポイント、採用ポイント

A社からのリクエストに基づき、当社としての考えを提示し、最終的に、外部の第三者として複数のベンダーの中から、アークシステムが選定された。

A社からのRFP

A社としては、親会社でのユーザーや多数の開発要員が関係する中で、複雑化したシステムに対する考慮漏れ、検討漏れ、認識相違などを防ぐためには、中下流工程における成果物(特に外部設計書)の品質向上がまずは必須であると考え、ベンダーが作成する成果物に対する品質に関する検証を、外部の第三者によるダブルチェックを実施する方針とし、当社を含む複数のベンダーに提案依頼を実施した。

当社提案

当社としては、今回の第三者検証の目的・目標は、大きく以下の2点と捉えた。

  • 今回対象となる中下流成果物の品質確保
  • この先、開発部署が自律的、継続的に品質向上のためのPDCAプロセスを実行できるようにすること

これらを踏まえ、提案ポイントしては以下のとおりとした。

  1. そのために、個々の成果物に対する客観的な品質検証・評価の実施。
  2. 検証結果・評価にもとづいて、A社の各種標準類および開発手順やプロセスの改善・改良に向けてのアドバイスおよび支援の実施。その際、不十分な部分の指摘だけでなく、無駄な(冗長な)作業の見直しなども視野にいれ、目標とする品質を効率的に確保する。
  3. 実際の検証作業については、修正計画にあわせ、ポイントごとに客観的に評価したうえで、開発部署に改善のアドバイス、フォローをしていくことで実効性のあるものにしていく。
  4. 開発技術だけでなく、管理的な側面やテスト技術も重視した経験豊富なメンバー(10年以上)による少人数の精鋭チームとした。

特に今回の修正対応は影響が広範囲に及ぶことが予想され、最初の「修正に対する基本方針」(=戦略)がきわめて重要と考え、それら方針の策定段階から検証を実施し、費用対効果等を考慮した実効性・実現性のある方針および実施手順策定をフォローしていくこととした。

成果物に対する第三者検証の実施

選定理由

本件はコンサルティング社、ベンダー社など複数社によるコンペ案件となったが、以下の点を評価いただき当社が選定された。

  • 提案内容が、A社の要望に対して的確であったこと。(現実的であり、過大なものにはなっていない)
  • アークシステムは完全に独立系ベンダーであり、特定の製品などに依存することはない。(大手ベンダーの場合、自社の製品の利用や導入等が前提となる場合がある)
  • 大手ベンダーよりも小回りが利き、柔軟な対応が可能である。
  • 既存ベンダーとの間での競合的な立ち位置にはならず、関係性を良好に維持し、既存ベンダーの生産性や品質に影響をあたえない様にすることに主眼を置いた提案であったこと。
  • 経験豊富な少数精鋭の体制を適切なコストで提供できる提案内容であったこと。

 

03

第三者検証の実施プロセス

4つの観点からの検証を実施

第三者検証としては、以下の4つの観点からの検証を実施した。

成果物(ドキュメント)検証

  • 対象は、外部設計、内部設計、製造、テストフェーズで作成されるドキュメントとした
  • ドキュメント検証については「縦」と「横」での整合性チェックを実施した
    • 【縦の関係】:開発フェーズ間の上位ドキュメント→下位ドキュメントの整合性検証の実施
      ※ 例えば、内部設計書の場合は外部設計フェーズのドキュメントを正として、検証対象のドキュメントの検証を実施
    • 【横の関係】:同じフェーズで作成されるドキュメント間の整合性検証
  • 検証のインプット情報は以下を利用した
    • 検証対象ドキュメント
    • 上位ドキュメント
      ※ 例えば、内部設計書の場合は、外部設計フェーズのドキュメント
    • 各開発種規定、開発標準類
    • ベンダー内でのレビュー結果報告
  • 性能やセキュリティ面などの非機能要件に関するチェックもあわせて実施した

ソースコード検証内容の検証

  • 改修ソースコードのツール(※)および目視によるチェック
    ※ ツールについてはMicrosoft Visual Studio 2005 Team Edition for Developers
  • 検証のインプット情報として以下を利用
  • 検証対象ソースコード(改修箇所)
  • 外部設計書、内部設計書、テスト結果報告書
  • 各種開発標準類

2.	ソースコード修正内容の検証

開発標準規定等へのフィードバックの実施

  • 検証結果に応じて、必要な各種標準もしくは開発規則/規定、開発プロセスの見直しのための提言の実施

開発標準規定等へのフィードバックの実施

開発現場の実地検証(必要に応じて)

  • 実際の開発作業現場での作業手順、課題管理、情報共有の仕方、開発メンバースキルなどについての検証実施
    (実地検証については、ドキュメントやソースコードの検証を通じてその先の品質確保に懸念が生じた場合など、必要に応じて実施するオプション。例えば、オフショア開発などを想定したものである)

開発現場の実地検証(必要に応じて)

04

実施効果や評価

本番リリース時の障害が80%以上減!

これら一連の検証を実施した結果、以下の効果が得られた。

  • 本番リリースに伴う障害は最終的には80%以上削減(年数件への削減)された。また、顧客への影響のあるような重大障害についても、それに合わせて激減した。
  • 検証対象となったドキュメントについては、ソースコードとの乖離がなくなるなど、品質が向上した。
    (ただし、すべての機能、ドキュメントを検証対象としていたわけではない)
  • 当初、開発標準類は存在していたものの、内容的には不十分なものであり、開発標準のレベルアップを提言し、新たな開発標準を作成することとなった。新たな開発標準へのインプットして、これまでの障害の原因となった事象(プロセス面や技術面)を回避するための対策について盛り込むことができ、本来のあるべき開発標準類を整備することができた。今後の保守開発の品質を担保するための基盤ができたといえる。

今回の第三者検証については、単に成果物の品質を評価するだけでなく、親会社を含めての案件の切り出し方~最終的な移行までの一連のプロセスについての品質を評価してきたことに特徴がある。本質的な品質改善を図るためには、品質が悪化する根本的な原因を取り除くことが必要であり、それは単に個々のプロダクトの品質をチェックするだけでは取り除くことが難しく、一連の開発プロセスを含めたチェックと改善が必要である。

これらは単にベンダーに責を問うだけでなく、依頼元となる親会社からの要望の出し方、要件の整理の仕方にもメスを入れることが重要である。

こうした一連の活動を通してその成果を得るためにはある程度のスパンでの対応が必要であり、この点についてのお客様の理解が得られたことが、着実かつ確実に成果を出せた理由でもある。(拙速に進めても、効果は限定的で、かつ短期的なものに終わってしまうケースが多い)

05

開発品質を保持するためのアプローチ

第三者検証の発展形として

アークシステムは、特定の製品・言語、業界・業種などには依存しておらず、さまざまな業種のお客様からの開発業務を請け負ってきている。各メンバーは開発業務について熟知している精鋭の集まりであり、単なる検証業務ではなく、以下のような状況においても、改善の提案および改善策の実施が可能である。

  • 現開発体制の開発品質がよくない、生産性が悪い、あるいは開発の品質や生産性が評価できない
  • たびたび障害が発生するが、その根本的かつ客観的な原因をつきとめ、対応を施したい
  • 自社独自の開発プロセスおよび開発手順を整備したいが、スキル、ノウハウがない
  • アプリケーション基盤(アプリケーション・フレームワーク)を整備したい
  • システム更改が予定されているが、どのような手続き、手順で進めればよいのかわからない

など。

上記の状況における支援については、第三者という形よりも、お客様の情報システム部門の一員として参画することで、より私たちのノウハウが活かすことでできると考えている。

お問い合わせ

サービスの導入をご検討されている
またはサービスについてのご質問などがございましたら
お気軽にお問合せください。

お問い合わせはこちらから