目次
Contents
前回のブログ「コールセンターの運用について ～第１回 運用保守～」ではコールセンターでの運用保守についてご紹介しました。
今回は開発作業についてご紹介します。
以前担当していたコールセンターでの開発についての解説がメインテーマですが、開発作業の内容が場所や案件で大きく変わる事はほとんどありません。
もちろんオフショア開発をする場合も、今回ご紹介する内容とほぼ同じ作業を行っています。
なので、今回ご紹介する内容を読んでいただければ、コールセンターだけでなく、一般的な開発作業についてもご理解いただけると思います。
それではよろしくお願いします。
【開発作業とは】
まずは言葉の意味について確認します。
開発作業とは名前の通り新しい機能を開発する作業のことです。
もう少し詳しく説明すると「業務の効率化や最適化を目的に、ソフトウェアプログラムを使って業務システムを構築すること」という意味になります。
また、開発作業は作業内容ごとに、上流工程と呼ばれる「要件定義、設計」と、下流工程と呼ばれる「実装、テスト、リリース」に分類されます。
工程の順番としては「要件定義→設計→実装→テスト→リリース」となります。
また、オフショア開発を行う場合、オフショア先で行う作業は”実装”がメインとなります。
開発作業の中で最もコストが掛かる実装工程をオフショア先で実施することでコスト削減が可能となり、実装で必要な設計や実装完了後のテストを日本側で実施することで、品質を一定に保つことができます。
開発方法にもいくつか種類があります。
主流なものだと「ウォーターフォールモデル、アジャイル開発」の２種類です。
前者はリリースまでの各工程を一つずつ順番に完了させるのに対して、後者はシステムをいくつかの機能（サブシステム）に分割して優先度の高いものから順番にリリースを行います。
両者の違いは要件定義工程の内容です。
前者では手戻りを防ぐため綿密に要件定義を行うのに対し、後者は繰り返し開発を行うため前者ほど綿密な要件定義は行いません。
開発方法の採用傾向として、大規模なプロジェクトの場合はウォーターフォール、アプリケーション開発などの場合はアジャイル開発が採用される傾向にあります。
ちなみに、私が参加したコールセンターの案件では、ウォーターフォールを採用していました。
【コールセンターでの開発作業】
一般的な開発作業とほぼ同様の工程を実施します。
私が以前担当した案件では、設計工程を「要件定義の結果をもとに作成する“基本設計”」と「基本設計の内容をより詳細に記述する“詳細設計”」に分割していました。
またテスト工程も「作成したＰＧのみをテストする“単体テスト”」「他システムとの接続以外をテストする内部結合テスト」「他システムも含めたシステム全体をテストする外部結合テスト」の３つに分割していました。
３つの工程に分割したテスト工程ですが、それぞれで確認するべき観点があります。
単体テストは作成したＰＧの正確性、内部結合テストは詳細設計の正確性、外部結合テストは基本設計の正確性をそれぞれ確認します。
それら３つのテストすべてで合格することで納品物の品質を保証していました。
【依頼される案件の種類】
コールセンター向けシステムで開発案件が発生する場合、案件の依頼者は「オペレーター、サービス提供会社、行政」に分けられ、依頼者によって案件の規模や納期も変わります。
ただし、それぞれから個別に開発依頼されることは無く、あくまで開発依頼の発生元が３つに分けられます。
Ｃａｓｅ１：オペレーター
実際にコールセンターシステムを利用する方たちです。
使用される中で感じた不満点や改善点について依頼されることが多いです。
依頼内容が画面単位の追加や変更依頼が多いため規模は小さい場合が多いですが、業務への影響を最小限にするため納期は短くなる傾向があります。
Ｃａｓｅ２：サービス提供会社
コールセンターの対象となるサービスを提供する方たちです。
提供しているサービスでのキャンペーンなどに合わせて改修を依頼されることが多いです。
機能単位の追加や削除依頼が多いため規模は大きくなりやすいですが、既存システムへの影響を確認しながら案件を進めるため、納期は長くなる傾向があります。
Ｃａｓｅ３：行政
行政からコールセンターシステムに直接指導が入ることはほぼありませんが、法令の施行に伴い開発作業が発生することがあります。
最近だと元号改正対応や祝日変更対応がありました。
影響範囲がシステム全体に及ぶことが多く規模は大きくなりやすいですが、行政から発表されてから運用開始まで時間が無いことも多く納期は短くなる傾向があります。
【事例紹介】
案件の依頼者が「オペレーター、サービス提供会社、行政」に分類できることは先ほどご説明した通りです。
ここでは、それぞれの依頼者ごとに事例紹介という形で、それぞれの案件ごとの特徴的な作業内容についてご紹介します。
Ｃａｓｅ１：オペレーター
コールセンターで取り扱っている情報のうち、ある照会画面に非表示だった情報も追加で表示してほしいという依頼がありました。
事前調査の結果、その照会画面で表示するためには、表示に必要な情報を新しく取得する必要がありましたが、共通的な部品を使用して情報を取得していたため、その部品を使用していた他の画面にも影響が出る可能性があることがわかりました。
依頼内容とは直接関係が無い他の画面での影響有無を確認するために、内部結合テストと外部結合テストの2工程で影響が出る画面の打鍵確認を行い、修正前と同じ動作をすることの確認を行っていました。
Ｃａｓｅ２：サービス提供会社
新しいサービスを展開するために、そのサービスと紐づけたキーワードをコールセンターのシステムに追加してほしいという依頼がありました。
このような依頼の場合、すでに似たようなキーワードが存在するケースが多いため、実装はそれほど難しくありません。
ただし、実装する前にキーワードを追加する場所を正確に把握しておく必要があります。
キーワードの追加漏れや不要なキーワードの追加などを行ってしまうと、エンドユーザーに直接影響が出てしまうためです。
そのため案件開始時には、管理している全資産を対象に「キーワード追加による影響の確認」と、確認結果をお客様に提出し「対応が必要な箇所の特定作業」を行っていました。
Ｃａｓｅ３：行政
元号が平成から令和に変更されるため、コールセンターシステムに表示しているカレンダーからシステムの内部処理で使用しているモジュールまで、和暦が影響するすべての箇所の改修を行いました。
生年月日など個人情報にも影響があることが分かっていたため、元号の改正後すぐの納期となっていました。
ただし、新元号の事前告知などは無く改正当日まで新元号が分からないため、通常通りの開発スケジュールでは間に合いませんでした。
そこで、新元号発表前は仮元号を使うことでテスト工程までを完了させ、新元号が発表された段階で仮元号を新元号に差し替えてリリースするというスケジュールで対応を行いました。
【まとめ】
今回はコールセンターでの開発作業についてまとめてみました。
開発作業には「要件を整理する上流工程」と「要件を形にする下流工程」があることと、各工程の詳細な作業内容についておわかりいただけたかと思います。
冒頭でも説明しましたが、オフショア開発を活用した場合でも上流工程やテスト工程以降は日本側で実施します。
次回はお客さまへ提供するサービスの質についてまとめてみようと思います。
記事： Y.F
