ソフトウェア適応ライフサイクルとその支援手法の提案

全文

(1)Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. 1. はじめに. ソフトウェア適応ライフサイクルとその支援手法の提案. 池田浩志†. 松山浩士††. 本稿で述べるソフトウェアの適応とは，利用者（顧客）の要求に応じてソフトウェアの機能・振舞いを調整する作業である．ソフトウェア保守の一側面である適応保守に含まれる．本稿ではパッケージソフトの設定の追加・変更・削除による適応作業を扱い，要求の変化に対応する設計やプログラムの大幅な改変を対象とするものではない．だとすると単純作業ではないかと思われがちであるが，次章で詳述する本稿での事例（EDI-ASP）では通信手順や情報の構成・項目の定義記述に関する設定が複雑であるため，不用意な作業プロセスでこれを行えば誤りが混入しやすく頻繁に運用時の不具合が発生する．これはソフトウェアの適応作業自体がアトミックなタスクとして扱えるものではなく，要求分析・設計・テストを段階的に伴うライフサイクルとしてとらえるべきであることを示している．とくに設定という一見単純に見えるタスクにおいて，ドメインに依存した設計知識が多分に含まれることを認識し，その知識に依存するタスクを適応プロセス全体から分離することによってソフトウェア適応の品質と生産性の向上をめざす．. 鯵坂恒夫†. EDI-ASP (Electronic Data Interchange - Application Service Provider)の領域におけるソフトウェア適応が運用直前の単純な一作業ではなく，要求分析・設計・テストを段階的に伴うライフサイクルとしてとらえるべきであることを述べる．通信手順や情報の構成・項目の定義記述に関する設定は十分な複雑さをもった設計知識であり，これを適応プロセス全体から分離することによってソフトウェア適応の品質と生産性の向上をめざす．. A Software Adaptation Life Cycle And Proposal Of The Support Technique. 2. EDI-ASP サービス，ソフトウェア適応作業説明. Hiroshi Ikeda† and Koji Matsuyama†† and Tsuneo Ajisaka†. (株)サイバーリンクス（以降「弊社」と記述する）では EDI-ASP サービス（以降「本サービス」と記述する）を提供している．本サービスの内容は EDI(Electric Data Interchange)を ASP(Application Service Provider)型で提供している（図 1）．ここで用語を定義しておくと「EDI」とは企業間で商取引に関する情報(受発注・請求・支払等) を電子的に交換する仕組みを意味する．また「ASP」とはビジネス用アプリケーションソフトウェアをネットワークを介して顧客に提供する事業者を意味する．. Software adaptation in this paper means a process of adjusting software of shared use according to the specific and detailed requests of the user. It is not a simple task just befor cutting off, but should be considered as a lifecycle process including requirements analysis, design, and testing, because it involves a large amount of domain sensitive design knowledge. This paper discusses the improvement of quality and productivity of the adaptation process through identifying the design knowledge.. †. 和歌山大学 Wakayama University. †† 株式会社サイバーリンクス CYBERLINKS Co.,Ltd.. 1. ⓒ2009 Information Processing Society of Japan.

(2) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. と連携しサービス提供を実施している（図 2）．. 図 1. EDI-ASP サービス. 本サービスで提供している内容は大きく 6 つあり以下の表の通りとなる（表 1）．表 1 サービス名集配信サービスマルチプロトコル変換サービス. Web 自動化サービスデータ変換サービス Web-EDI( データ転送)サービス Web-EDI( 小売向け)サービス. 図 2. EDI-ASP のサービス内容サービス内容. EDI-ASP システム構成. 前述の本サービスの範囲内で，顧客は必要に応じて申請を出してくる．弊社では上記システムに対してソフトウェア適応作業を行っている．実際のソフトウェア適応フロー・ソフトウェア適応作業は次の通りである（図 3）．. 弊社が顧客の代行として，顧客の取引先と，定められた時間にデータの送受信を実施する．弊社が顧客の代行として，顧客の取引先と，顧客が対応していない通信手順で通信し，データの送受信を実施する．対応する通信手順は ebXML-MS・JX 手順・全銀・FTP・ BACREX 手順・JCA となる．弊社が顧客の代行として，顧客が取引先に対して手動で行っている Web ブラウザによるデータの送受信を，Web ブラウザの操作を自動化しデータの送受信を実施する．弊社が顧客の代行として，データの文字コード・レイアウト変換を実施する．弊社が顧客の代行として，顧客の取引先に対して，Web ブラウザによるデータの送受信画面（ファイル転送のみ）を提供し，データの送受信を実施する．弊社が顧客の代行として，顧客の取引先に対して，Web ブラウザによるデータの登録・変更・送受信画面(伝票型) を提供し，データの送受信を実施する．. 図 3. EDI-ASP ソフトウェア適応フロー. (1) 申請受付顧客からの EDI の新規や追加，削除の申請を申請書で受け付けるフェーズである．申請フォーマットは顧客毎に異なっている．申請書を受け付けた後，内容を精査し問題があれば，顧客に申請内容を問い合わせる． (2) EDI 通信設定受付した申請書に基づきソフトウェアの設定を行うフェーズである．設定はパッケージソフトの管理画面により手動で登録する． (3) EDI アプリケーション設定 EDI 通信設定の他に必要なソフトウェアの設定を行うフェーズである．データの変換定義や Web ブラウザの操作の自動化に必要な Web 自動化の Script を作成するフェ. 本サービスのシステムはパッケージソフトにて構築を行った．また，パッケージソフトで満たせないサービスに関しては自社でソフトウェアを開発し，パッケージソフト. 2. ⓒ2009 Information Processing Society of Japan.

(3) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. ーズである．また，Web-EDI の 2 種類のソフトウェアの設定もこのフェーズで行う．. 対顧客との通信１２３. 変換定義の作成 EDI データの文字コードやレイアウトの変換が必要な場合は，申請時に受付した変換レイアウトに基づき変換定義の作成を行う．作成はパッケージソフトに付属の変換定義作成ツールにて GUI により手動で作成を行う．. Web-EDI の設定 Web-EDI(データ転送)と Web-EDI(小売向け)サービスにおいては，申請時に受付けした，Web 画面用の設定を行う．設定は各 Web-EDI のデータベースに対して GUI ツールにて必要な情報を登録・変更・削除を手動で実施する．. 表 3 EDI 受け入れテストのフェーズの種類テスト名称テスト内容. フェーズ. (4) テストテストフェーズは 2 つの段階に分かれる．システム内部での EDI 結合テスト，顧客まで含めた EDI 受け入れテストの 2 種類となる． EDI 結合テスト EDI 通信設定フェーズで登録した設定と，EDI アプリケーション設定フェーズで作成した変換定義が連携して動作するかどうかのテストを行う．ここではシステム内にて擬似的にデータを受信した後の処理を起動し，システム内のみでのテストを実施し，設定の検証を行う．. １. ネットワーク疎通. ２. EDI システム疎通. ３. 業務データ送受信. ネットワーク接続性の確認ファイアウオールの確認 EDI サーバの動作確認要求された通信手順で EDI システム同士が通信できるかの確認実際の業務データを使用して，顧客から取引先まで問題なくデータの送受信・業務が出来ることを確認. (5) リリース・保守開始受け入れテストが完了した設定のリリースを顧客へ行う．リリースには 2 種類あり，次の通りである（表 4）．リリース完了後に保守が開始される．表 4. EDI 受け入れテスト顧客による受け入れテストを行う．実際のデータを用い顧客，取引先との実際の通信まで含めたテストを実施する．受け入れテストには 3 ステップあり次の通りである（表 2）．表 2. ネットワーク疎通 EDI システム疎通業務データ送受信. テストフェーズ１，２は対顧客・対取引先毎に別々に行われる．対顧客とのテストフェーズ１，２は基本的に顧客との契約後，一回のみの実施となる．対取引先とのテストは新規取引先が増える毎にテストを実施する．テストフェーズ３については顧客から取引先まで連携したテストを実施する．受け入れテストのフェーズが分かれているのは，問題発生時に問題の切り分けを容易にするために分けている．各テストフェーズの説明は以下の通りとなる（表 3）．. Web 自動化の Script の作成 Web 自動化サービスにおいては，Web ブラウザの操作を自動化するための Script の作成を行う．作成は Script 作成ツールにより Web ブラウザの操作を記憶させ Script を自動生成させる．完全自動生成で Script が完成するわけではなく，人手による Script の修正が多少必要である．. フェーズ. ネットワーク疎通 EDI システム疎通. 対取引先との通信. 名称立会い本番. EDI 受け入れテストの種類テスト内容. サービスイン. 3. リリースの種類内容. 旧通信との平行でのデータの送受信期間が存在する場合に，新通信による本番の初回データ送受信を立会い，確認を行う．上記，立会い本番後の平行データの送受信が無くなる場合，もしくは，平行本番自体がない場合の，本番の初回データの送受信を立会い，確認を行う． ⓒ2009 Information Processing Society of Japan.

(4) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. けデータ変換パターンが存在する．よって，通信設定では通信手順の 8 種類掛ける顧客の数だけ申請書が最大増加する可能性がある．また，データ変換に関しては現時点で無数のパターンが存在する．. 3. ソフトウェア適応作業における課題本サービスは，大半がパッケージソフトにより構築を行った．パッケージソフトが統一された汎用的なインターフェースを提供している為，ソフトウェア適応作業自体に手間がかかる・問題が発生する可能性は低いと考えられていた．しかし，実際ソフトウェア適応作業が始まり，ソフトウェア適応作業が増えてくると，いくつかの課題が発生してきた．本章では，本サービスのソフトウェア適応作業で実際に起こった課題を述べる．. (3) 課題３：ソフトウェア適応作業のパターンの増加への対応本サービスの発展に伴い，ソフトウェア適応作業のパターンが増加してきた．適応作業のパターンの増加には以下の理由が関係している． z. (1) 課題１：申請数の増加への対応本サービスの発展に伴い，顧客からの申請数が増加してきた．申請数の増加には以下の２つの理由が関係している． z z. 課題 2 で述べたとおり，本サービスの多様化に伴い，通信手順が 1 種類から 8 種類に増加した為，現在は EDI 通信設定フェーズで 8 パターンのソフトウェア適応作業が存在する．また，EDI アプリケーション設定フェーズのデータ変換定義作成作業に関しては課題 2 で述べた通り無数のパターンが存在する．. 顧客あたりの申請数の増加顧客の増加. 4. 課題の対策. 顧客あたりの申請数の増加理由は，弊社と顧客との信頼関係の向上により，顧客から弊社への委託範囲が増えた為である．また，顧客の増加理由は，営業活動により本サービスの利用顧客の獲得を随時行っている為である．. 本章では，前章で述べた課題の解決すべき内容と対策を明らかにする． (4) 課題１の対策課題１の問題点を掘り下げると，申請数の増加により，ソフトウェア適応作業の工数が不足するというものである．対策としては，ソフトウェア適応作業自体を効率化し工数の削減を実施するか，もしくはソフトウェア適応作業者の増員により工数を補うかの 2 つ選択肢が考えられた．ソフトウェア適応作業は１適応当り５∼１０人日必要である．当初本サービスのソフトウェア適応作業者は 2 名で行っていた為，1 ヶ月の最大適応数は４∼８が限界であった．適応作業の効率化と作業者の増員を比べた場合，作業者の増員の方が効果的であった為，申請数の増加に対しては，まずは作業者の増員により対策を実施した．また，対策に際して単純な作業者の増員を行うだけではなく，今後の申請数の増加に対応できるよう，以下を目標に，ソフトウェア適応作業の見直しを実施した．. (2) 課題２：申請フォーマット増加への対応本サービスの発展に伴い，申請フォーマットの種類が増加してきた．申請フォーマットの増加には以下の 2 つの理由が関係している． z z. 本サービスの多様化. 顧客の増加本サービスの多様化. 本サービスのシェア拡大により，顧客の数が増えた．本サービスの標準の申請フォーマットは存在するが，顧客に標準の申請フォーマットを強制することは出来ない．殆どの顧客が自社の独自の申請フォーマットにより申請を行う為，申請フォーマットが増加する．本サービスを開始した当初は，通信手順は ebXML-MS の 1 種類，データ変換のパターンも１パターン（8 データ種）のみであった．申請フォーマットも標準化団体が定める 1 種類でのみであった．しかし，本サービスの多様化に伴い，現在では通信手順は 8 種類取り扱う為，8 種類の申請フォーマットが存在する．またデータ変換のパターンはデータのレイアウトが規定されていない通信手順に関しては，顧客の取引先の数だ. z. ソフトウェア適応作業の一部を外部委託可能とする. 上記，ソフトウェア適応作業を外部に委託可能とする為に，ソフトウェア適応作業を細かく分解し，外部に委託可能な作業とそれ以外の作業に分けた．その結果，外部に. 4. ⓒ2009 Information Processing Society of Japan.

(5) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. 委託可能な作業とは，マニュアルと指示書のみにより作業が可能なものが対象となった．具体的には EDI 通信設定フェーズにおけるパッケージソフトへの設定作業である．逆に外部に委託不可能な作業とは EDI の知識が必要な作業や，顧客とのやり取りが必要な作業である．ソフトウェア適応作業の外部への委託可否は次の通りである(表 5)．表 5 フェーズ. ソフトウェア適応作業の外部委託の可否外部委託の可否外部委託否の理由. 申請受付 EDI 通信設定 EDI アプリケーション設定テストリリース・保守. 否可否否否. 図 4. EDI 通信設定フェーズでは申請受付フェーズにて顧客から受付した申請書と，EDI 設計フェーズにて作成された設計書をもとに，マニュアルと指示書に従ってパッケージソフトに EDI 通信設定が実施できるようソフトウェア適応フェーズを改善した． EDI 通信設定フェーズを外部委託することにより，外部委託での作業実施後に検収作業を実施する必要が出てきた．また，単一作業者による作業は 100%ミス無く行うことは不可能であり，自分の実施した作業を作業者自身で確認しても，作業のミスは 0% にはならないものである．よって，以下の 2 点を目的として他者による作業のレビューを行うこととした．. 顧客とのやり取りが必要な為 EDI の知識が必要な為顧客とのやり取りが必要な為顧客とのやり取りが必要な為. さらに，EDI 通信設定フェーズ内の適応作業を細かいタスクに分類すると次の通りとなる(表 6)．表 6 タスク. z z. EDI 通信設定フェーズ内の外部委託の可否外部委託の可否外部委託否の理由. グループ設定の命名ユーザ設定の命名ファイル設定の命名アプリケーション設定の命名ジョブ構成の設計変換定義の命名グループの設定ユーザの設定ファイルの設定アプリケーションの設定ジョブの設定. 否否否否否否可可可可可. EDI-ASP ソフトウェア適応フロー（EDI 設計追加）. EDI の知識が必要な為 EDI の知識が必要な為 EDI の知識が必要な為 EDI の知識が必要な為 EDI の知識が必要な為 EDI の知識が必要な為 -. 設定作業の外部委託実施における作業検収単一作業者による設定誤りの低減. 具体的には，ソフトウェア適応作業の全てのフェーズにおいて作業完了後，作業内容を他者によりレビューを実施することとした．（図 5）．. 図 5. EDI-ASP ソフトウェア適応フロー（レビュー追加）. (5) 課題２の対策課題２の問題点を掘り下げると，申請フォーマットの増加によりソフトウェア適応作業の申請受付フェーズの作業が多様化するというものである．対策としては，申請フォーマットの統一を実施するか，もしくは多様な申請フォーマットの受付作業の効率化を実施するかの 2 つの選択肢が考えられた．申請フォーマットの統一は顧客の業務の都合により即座に統一されることは現実的にありえない．よって顧客毎の申請フォーマットから EDI 通信設定を実施できるよう，顧客の申請フォーマット毎にパッケ. 上記 EDI 通信設定フェーズにおけるパッケージソフトへの設定作業のみが外部委託可能となった．よって，EDI 通信設定フェーズにおける作業において，EDI の知識が必要な作業を EDI 通信設定フェーズから切り出し新たに EDI 設計フェーズとした．また，残りのパッケージソフトへの設定作業のみを EDI 設定フェーズに残した．変更後の本サービスの適応作業の流れは次の通りとなる(図 4)． 5. ⓒ2009 Information Processing Society of Japan.

(6) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. つの成果が得られた．. ージソフトへ EDI 通信設定のマニュアルを作成し，EDI 通信設定作業の外部委託可能とした．顧客のフォーマット毎にマニュアルを作成するというコストは必要であるが，一旦マニュアルを作成した後は，外部委託が可能となることにより，マニュアル作成のコストを生産性の向上により十分吸収することが出来た．. z z. (6) 課題３の対策課題３の問題点を掘り下げると，ソフトウェア適応パターンの増加によりソフトウェア適応作業の申請受付フェーズ・設定フェーズが多様化するというものである．対策としては，課題２と同様，申請フォーマットから EDI 通信設定を実施できるよう，適応パターン毎にパッケージソフトへの EDI 通信設定のマニュアルを作成し，EDI 通信設定作業の外部委託可能とした．. (2) ソフトウェア適応ライフサイクルの支援手法の提案次章で考察するように，ライフサイクルプロセスを導入した適応作業により，運用に供するソフトウェアの安定性は大きく向上するものの，作業工数はかえって増加する．当然のごとく，品質と生産性のトレードオフが生じているわけである．これを改善するには，増加した工数の一部をルーチンワーク化ないし自動化するしかない．適応ライフサイクルの導入により，ソフトウェアの設定に関する設計知識，業務知識が抜き出されているので，そのような知識を使いながら行うレビュー作業など自動化のできない部分と，整理された知識をもとにマニュアル化した流れ作業との分割を明確にすればよい．設計知識，業務知識は，データ交換・変換における情報の要素項目とその構成に関する意味的理解がもとになっている．すなわちプロダクト（もの）に関する知識である．これをソフトウェア設定の流れ作業，すなわち自動化可能なプロセスにいかに展開するかがポイントである．このプロセスは複雑な条件分岐を含むものになるはずであるので，プロダクトに関する知識を分岐の判定条件に正確にあてはめていくことがライフサイクル支援の要といえる．. 5. ソフトウェア適応ライフサイクルとその支援手法の提案本章では，ソフトウェア適応作業を，要求分析・設計・テストを段階的に実施する為のソフトウェア適応ライフサイクルを定義し，またその支援手法を提案する． (1) ソフトウェア適応ライフサイクル今回提案するソフトウェア適応ライフサイクルを次の通り定義する（表 7）．表 7 フェーズ要求分析設計設定テストリリース保守. ソフトウェア適応作業を知識（設計）と作業（設定）に分離し，作業に関しては外部委託可能にすることにより，ソフトウェア適応作業の生産性が向上した．ソフトウェア適応作業を知識（設計）と作業（設定）に分離することにより，作業者増員に際し，作業の習得と，知識の習得を段階的に実施することが可能となった．. ソフトウェア適応ライフサイクル内容. 顧客からのソフトウェアの設定に対する追加・変更・削除の要求を受付その内容を分析する．要求に基づき，ソフトウェアの設定に必要な設計作業を実施する．ドメインに依存した知識をもとに，要求とソフトウェア設定に必要な要素項目間の紐付けを行う．設計に基づき，ソフトウェアの設定を実施する．ドメインに依存した知識は必要なく，ソフトウェアの設定のみを行う．設定した内容の検証を行う．設定者による単体テスト，結合テスト，顧客による受け入れテストを行う．受け入れテスト完了後，本稼動開始の立ち会いを行う．リリースしたソフトウェア設定を保守する．. 6. 考察 6.1 新たな課題. 実際の業務において，ソフトウェア適応ライフサイクルを適用することにより，安定的にソフトウェア適応作業を実施することが可能となった．しかし，ソフトウェア適応ライフサイクルを実施することによるデメリットも生じてきた．そのデメリットとは作業工数がかかることである．実際に従来のソフトウェア適応フローとソフトウェア適応ライフサイクル適応後のソフトウェア適応フロー・ソフトウェア適応作業の違いは次の通りである（図 6）．. EDI-ASP の領域にソフトウェア適応ライフサイクルを適用することにより，以下の 2. 6. ⓒ2009 Information Processing Society of Japan.

(7) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report 6.2 新たな課題への対策. ソフトウェア適応ライフサイクルの適応による工数の増加への対策は，手動作業を自動化することにより工数の削減を実施する．ソフトウェア適応作業における自動化の可能性は次の通りになる（表 9）．表 9 フェーズ. ソフトウェア適応作業における自動化の可能性全体作業に占める作業割合自動化の可能性. 申請受付 EDI 設計 EDI 通信設定 EDI アプリケーション設定テストリリース・保守開始. 図 6 従来のソフトウェア適応とソフトウェア適応ライフサイクル適応後のソフトウェア適応フローの違い. 9.6% 8.7% 34.2% 14.1% 6.5% 26.8%. 一部可能一部可能ほぼ可能一部可能一部可能不可能. EDI 通信設定を自動化することにより作業全体の約 1/3 を削減することが分かった．自動化によりソフトウェア適応のフローは次の通りとなり，EDI 設定作業自体はほぼ自動化で実施可能となる．また，自動化は前フェーズの EDI 設計書に基づき自動化されるため，自動登録後のレビュー作業は必要無くなる．（図 7）. また，各フェーズにおけるソフトウェア適応の作業内容は次の通りソフトウェア適応ライフサイクルを適応することにより作業が増えている（表 8）．表 8 従来のソフトウェア適応とソフトウェア適応ライフサイクル適応後のソフトウェア適応作業の比較従来のソフトウェア適応ソフトウェア適応ライフ追加になった作業作業サイクルを適応後のソフトウェア適応作業申請受付. 申請受付 EDI 設計. EDI 通信設定 EDI アプリケーション設定テストリリース. EDI 通信設定 EDI アプリケーション設定テストリリース. レビュー作業設計作業設計書の作成レビュー作業レビュー作業レビュー作業レビュー作業レビュー作業. 図 7 ソフトウェア適応作業自動化後のソフトウェア適応フローその他フェーズにおいても自動化は一部可能でありそれによりさらに作業工数を削減することを目指す．. 7. おわりに 7.1 まとめ. 3 章述べた本サービスにおけるソフトウェア適応作業の課題の解決策として，最終的に 5 章にてソフトウェア適応ライフサイクルの提案し，またその支援手法を述べた．ソフトウェア適応という作業に対して，設計知識を分離しソフトウェア適応の品質と. 7. ⓒ2009 Information Processing Society of Japan.

(8) Vol.2009-SE-166 No.6 2009/11/5. 情報処理学会研究報告 IPSJ SIG Technical Report. 生産性の向上を実現した．また，6 章ではソフトウェア適応ライフサイクルを適用することによるデメリットである作業工数の増加への対策として，ソフトウェア適応作業の自動化の可能性を提案した． 7.2 今後の課題. 今後の課題を以下に示す． z. EDI-ASP の領域における，EDI 通信設定フェーズの自動化の実施. z. EDI-ASP の領域における，申請受付フェーズ・EDI 設計フェーズ・EDI アプリケーション設定フェーズ・テストフェーズの自動化可能な部分の自動化の実施. z. EDI-ASP の領域以外における，ソフトウェア適応ライフサイクルの適用とその効果の測定. 参考文献 1). 鰺坂恒夫著：ソフトウェア工学入門, サイエンス社, 2008.. 8. ⓒ2009 Information Processing Society of Japan.

(9)