業務システムのライフサイクル管理におけるツール利活用（１）
こんにちは豆蔵note編集室です！
今回は豆蔵技術情報より、【業務システムのライフサイクル管理におけるツール利活用（１）】をご紹介します。
豆蔵技術情報とは？
株式会社豆蔵公式HPにて公開している技術情報のことです。
その時にホットな技術的な情報、社内の活動について発信をしております。
それではどうぞ！
近藤 正裕 今田 忠博
当記事は2018年に再編集し、連載として体裁を整えたものです （ツールのバージョン等は内容に影響しないので適宜読み替えて下さい）
背景とコンセプト
業務システムは企業の経営資源であり、日々の業務に適合し業務の変化にも追随できるよう可変性を備えている必要があります。従って業務システム開発の失敗は深刻な経営の足かせとなります。そして、実際に多くの開発プロジェクトが失敗し、業務遂行・業務革新をストップさせてしまっているのです。
業務システム開発の失敗原因は、「発注側が十分に要求を伝達できていない」「開発側の要件定義が不完全なまま設計・実装に進んでしまっている」「発注側と開発側で役割・責任が曖昧なままプロジェクトを進めている」「開発現場が非効率的である」など様々な原因があり、これらが複合した原因を構成している場合もあります。業務システムの開発・保守をベンダーに丸投げし、明確な仕様も提示しないままでプロジェクトが進行し、受け入れ段階でトラブルになることも珍しくありません。
このホワイトペーパーでは、業務適合性・保守性の高い業務システムを妥当なコストで開発するためのプラクティスを提案します。基本コンセプトは次の3つです。
発注者と開発者の役割・責任範囲を明確化する
アプリケーションライフサイクル管理の観点を導入し、要件と設計・実装のトレーサビリティーを確保する
開発ツールを積極的に利活用し、開発生産性を向上させる
開発ツールに関しては、MicrosoftのVisual Studio 2010および、Team Foundation Server 2010を中心に取り上げ、これらのツールが開発をどのようにカバーしており、どのように効率化されるのかを述べます 。
なお、業務システムのモデリングやアーキテクチャー設計については、本ホワイトペーパーの対象外とし、管理面とツール適用にフォーカスします。
役割・責任範囲の明確化
多くの企業は、業務に必要なシステムを自社で内製することはせず、第三者であるベンダーに開発を依頼します。自社の業務をよく理解したベンダーと長く良好な関係を構築できれば、要求伝達が多少曖昧だったとしても、ベンダー側が「空気を読んで」、納得のいくコストで業務に適合するシステムを開発・保守することが可能です。
しかし、テクノロジーの変革や業務改革などでシステムを刷新しなければならなくなると、このような特定ベンダーとの関係がボトルネックになります。多くの業務要件は暗黙知で文書化されていないため、(新規のテクノロジーを得意とする)新しいベンダーは、レガシーなシステムを解析したり、利用者にヒアリングをしたりしなければなりません。新たなベンダーが十分に業務に精通しシステム仕様を書けるレベルに達するまでには多くの時間を要します。
テクノロジーやベンダーが変わっても、業務を止めないようにするには、業務モデルやシステム要件を企業側の管理下に置く必要があります。最初のモデルの構築はベンダーの支援を受けて実施しても構いません。ポイントはそれを維持・管理する責務は発注者側にあるということです。
表 1に発注者と開発者の役割分担の例を示します。この表は、IPAの「共通フレーム2013」 で示されている例ですが、示されている役割分担は絶対的でなく企業の状況に合わせて定義すべきものです。
表１：組織と役割の関係の一例(共通フレーム2013より引用 ○:主体 □:支援)
表では業務要件定義は、業務部門が主体で実施し、情報システム部門が支援するという分担になっています。
情報システム部門のスキル不足やリソース不足などで支援を実施できない場合、ベンダーに準委任契約で支援してもらうという選択肢もあります。
ここでのポイントは、ベンダーが支援して行う場合でも、要件定義の成果物に関する責任は発注者(業務部門と情報システム部門)が負うということです。その際にもベンダーからのスキルトランスファーを心がけ、発注者側担当者が要件定義内容を理解し、管理できるようにする必要があります。
アプリケーションライフサイクル管理
アプリケーションライフサイクル管理(ALM : Application Lifecycle Management)は、「要件」「設計」「構築」「配置」「運用」「最適化」といったアプリケーションのライフサイクル全般を連続的に捉え、統合的に管理する活動です。業務システムをライフサイクルという観点で捉え管理することで、開発・保守の非効率性を排除し、業務要件との整合性や保守性、変更容易性を向上させる方向に関係者の意識付けを行うことができます。ライフサイクルの各フェーズで関係者の役割・責任を割り付けることも可能です。
業務システムライフサイクル管理の基盤
発注者と開発者の役割・責任を明確にし、業務システムのライフサイクルを管理・統制するためには、適切な方法論とライフサイクルを高度にサポートするツールの利活用が不可欠です(図 1)。
ここでは、ALMの「要件」「設計」「構築」に焦点をあわせて、その管理の基盤となる方法論・ツール群を俯瞰します。
表 2に方法論、表 3にツールをまとめました。
表２：業務システムライフサイクル管理のための基盤 ～方法論
要求開発 方法論は、IPAの「共通フレーム2013」における「システム要件定義」を扱う方法論で「業務システムは業務から導き出されるべきであり、すべての業務システムは、業務の一部として機能すべきである」という考えに基づいています。この方法論に基づき作成された具体成果物(各種モデル、文書)の関連を要素レベルで追跡可能なように構成したものが「システム開発地図 」です。
表３：業務システムライフサイクル管理のための基盤 ～ツール
ツール群については、業務分析、システム要件定義、設計に用いるUMLモデリングツール、ユーザーインターフェースの要件 を定義するためのプロトタイピングツール、コーディングとテストを行うための統合開発環境(Integrated Development Environment : IDE)、ソフトウェア構成管理(Software Configuration Management : SCM)ツール、ソフトウェアの問題管理を行うためのITS(Issue Tracking System)ツール、常に結合試験をしながら開発を進めるCI(Continuous Integration)ツールなどの各種管理ツールをまとめています。
Visual StudioはこれまでIDEの位置づけでしたが、2010では、UMLモデリング機能が利用できるようになり、ALMのカバー範囲が広がっています。また、Team Foundation Serverは、SCM, ITS, CIを統合しており、業務システム開発に関連するあらゆる情報を一元管理が可能という点で優れています。
業務システムのライフサイクル管理の全体像
業務システムのライフサイクル管理における「要件」「設計」における全体像を把握するには、「システム開発地図」で俯瞰するのが分かりやすいでしょう(図 2)
システム開発地図は、システム要件定義の成果物を中心として、業務分析および設計・実装における成果物をどのようにつなぐのかを俯瞰した地図です。
地図に描かれた成果物は、企業の在庫管理業務をモデル化し実装するまでの、実際のモデルや文書・図表などが詳細に描き込まれて、成果物の要素レベルまでを詳細にトレース可能です。情報量が非常に大きいため、紙面で詳細を示すことはできません。
システム開発地図は、豆蔵サイト技術情報ページ にて公開されており、PDFをダウンロードすることで詳細を閲覧することが可能です。
システム開発地図で発注者と外部の責任分界を示しました(図 3)
外部部分は、準委任領域と請負領域に分けて例示しています。発注者領域の成果物を外部に準委任で作成依頼しても構いません。
システム開発地図で、業務システムのライフサイクル管理におけるツールの適用例を示しました(図 4)
Visual Studio Projectとして示されている部分は、ほとんどがモデリング機能によるものです。
図では表現されていませんが、Microsoft Office(ExcelやVisio)のドキュメントは、Team Foundation Serverと連携して動作するSharePointサービスにより、チームプロジェクトの一部として管理できるため、Visual Studioのチームエクスプローラーからすべての情報をブラウズすることが可能です。
開発者は、Visual Studioをフロントエンドとして、ドキュメントやタスク、ソースコードを管理することができます。
図では成果物の関連を人が管理する部分とツールで管理する部分を識別しています。
Visual StudioのUMLモデリング機能では、各フェーズのモデルのトレーサビリティーを管理する機能は提供されていませんが、これは他の多くのUMLモデリングツールでも同様です。
システム開発地図ではALMの「構築」の部分は示されていませんが、Visual StudioとTeam Foundation Serverは「構築」の全域をカバーするツールと言うことができます。
※転載元の情報は上記執筆時点の情報です。
上記執筆後に転載元の情報が修正されることがあります。