はじめに
サービス要求の扱いは、ITIL® V3 において要求実 現プロセスの管理対象としてインシデント管理から 切出された。しかしながらインシデントと同様にサ ービスデスクで受付け、分類され処理されていくと いう従来の手続きから大きな変更が強調されている 訳ではなく、要求実現という対応手続きの区分が示 されたに留まっているという印象である。 一方、技術動向としては例えばプライベート・ク ラウドの普及に伴い、クラウド・サービスの利用申 請がサービス要求のメニューに飾られる時期を迎え ている。従来のサービス要求はパスワード・リセッ トのようなインシデントの一種のような概念だった が、最早「売る」べきサービスを提供するものとと らえるべきである。 本稿では、この積極的に「売る」ことを意識すべ き時期を迎えたサービス要求の管理について、サー ビス要求管理プロセスを IT 基盤上に実装した幾つ かの経験を踏まえ、インシデント管理との重複部分 も含めて純粋にサービス要求を管理するという観点 から改めて考定する。 また ITIL® で述べられるサービス要求は IT サービ スの要求をターゲットにしたものであるが、ITSCM が BCM を下支えするように、ビジネス・サービスの 要求とそれを下支えする IT サービス要求の位置付 けでサービス要求管理をとらえ、ビジネス・サービ ス要求を含めたサービス要求管理への統合について 考察する。*ITIL® is a Registered Trade Mark of the Cabinet Offi ce.
I. ITIL® におけるサービス要求の位置付け
ITIL® において従来、サービス要求はインシデン トと同様もしくはその一種としてインシデント管理 のインプットとなり、一部を除き共通のプロセスを 経て対処されるものとされてきたが両者の違いにつ いて整理しておこう。 I.1 ITIL® におけるインシデントとサービス要求 ITIL® V2 においてサービス要求はインシデントの 一種 (「インシデントの中で IT インフラストラクチ ャ側の障害にあたらないもの」サービスサポート / OGC) と定義されていたし、ITIL® V3 においてもイ ンシデント管理のフローチャートには、インシデン トと同様に識別・記録されカテゴリ化の結果、サー ビス要求に分類された場合は要求実現プロセスに分 岐される形で説明されている。( 図 I-1) 図 I-1. インシデント管理におけるサービス要求 / 要求実現のイメージ会員寄稿
Service Request Management 改考
～サービス要求管理システムの構築とビジネス ・ サービス要求の統合～
せồᐇ⌧䛾 ᡭ⥆䛝 せồᐇ⌧䛾 ᡭ⥆䛝 䜲䞁䝅 䝕䞁䝖 䝃䞊䝡䝇 せồ 䛭䛾 䜲䞁䝅䝕䞁䝖䛾 ㆑ู 䜲䞁䝅䝕䞁䝖䛾 グ㘓 䜲䞁䝅䝕䞁䝖䛾 䜹䝔䝂䝸 せồᐇ⌧䛾 ᡭ⥆䛝 䜲䞁䝅䝕䞁䝖⟶ ⌮䛾⥆䛝䞉䞉䞉 䝃䞊䝡䝇 せồ䛛䠛 䜲䞁䝅䝕䞁䝖⟶⌮ 䝥䝻䝉䝇 せồᐇ⌧ 䝥䝻䝉䝇インシデントを「IT サービスに対する計画外の中断、 または、IT サービスの品質の低下」、サービス要求 を「ユーザが IT 部門に提出するさまざまな要求一般」 として分類するものの両者は同様にサービスデスク などで受付けられ必要に応じて担当者 に割当て / エスカレーションし対応が 進められるものとして描かれている。 只この「対応」の部分は、サービス要 求ではサービス個々に手順化されてい るため、インシデント管理のような共 通のフローではなくサービス個々の手 続きとして要求実現プロセスとして別 に括り出された格好になっているので ある。 I.2 インシデント vs サービス要求 ITIL® V3 ではサービス要求を、ユーザが IT 部門 に提出するさまざまな要求を一般的に示すものと説 明され、用語の定義には、「例えば、パスワードの リセットや、新しいユーザに対する標準的な IT サ ービスの提供など」(ITIL® V3 用語集 /OGC) といっ た記述がある。 昨今の技術動向からはこの「要求」の中にはサー バ仮想化技術を用いたプライベート・クラウドのサ ービス提供を依頼するような形で例えば、「新規シ ステムのデモ環境として仮想サーバを 1 ノード貸し 出して欲しい」といったケースのための利用申し込 みがサービス要求のメニューに並ぶようになってい る。これらは「パスワードのリセット」のように当 然のごとく無料になっているサービス要求の価格付 けについて、改めてサービス要求は有料であること を気付かせる良い機会でもある。 ここで、インシデントとサービス要求について価 格に限らず主要な違いを整理しておこう。表 I-1 の ように、サービス要求には、ユーザ自身が識別でき ることによるメニュー化、価格の明確化、申込みの 完全なセルフサービス化というインシデントにない 特徴がある。 このようにサービス要求が価値・対価を伴ってき ている点、ユーザ自身によるメニューからの申込み 機能をもったシステム化が進んできている点などか ら、ITIL® V2 で言えばサービスサポートの範疇を出 て、サービスデリバリとしての色合いが強くなって いると言える。 表 I-1. インシデントとサービス要求の比較
II. Service Request Management の
観点と業務フロー
ITIL® V3 2007 でサービス要求に対処するプロ セスがインシデント管理プロセスから切り離され たが、その名称は筆者に限らず少なからぬ ITIL® 利用者が想定していただろう「サービス要求管理 (Service Request Management。以下 SRM とも )」プ ロセスではなく「要求実現」プロセスであった。 確かに図 I-1 で示されるようにインシデント管理 から分岐して要求実現に向かうインタフェースは ITIL® V2 から説明されており、「要求実現」として 括り出した方が一貫性の点で説得力がある。 しかしながら本稿では I.2 でまとめたようにイン シデントとサービス要求の違いを意識した上で、サ ービス要求の発生ポイントである「要求申請」即ち サービス要求の申請をプロセスの開始として、クロ ーズまでのサービス要求のライフサイクルをサービ ス要求管理としてまとめたい。 II.1 サービス要求管理と要求実現
ITIL® V3 の要求実現は ITIL® 2011 Edition にお いてサブプロセスに分解されたプロセスフローや 個々の記述が強化されており今後それとの比較にお いて説明したい時期ではあるが、本稿では現時点で 普及している ITIL® V3 (2007) の記述を踏まえて筆
者の SRM システム構築経験からサービス要求に関わ る業務フローモデルを整理しておきたい。 このモデルのスコープはインシデントから分類さ れた後の要求実現のプロセスではなく、サービス要 求を申し込むところから始まるもので、大きくはビ ジネス組織 (=IT 利用組織 ) に割当てられる「要求 申請」の活動群と、サービスデスクなど窓口におけ る「要求受付」の活動群、サービス提供組織 (=IT 組織などサービスプロバイダ ) に割当てられる「要 求実現」の活動群によって構成される。 図 II-1 に示したように「要求申請」の活動を視 野に入れてこれら全体を示すには、その一部にあた る「要求実現」プロセスではなくサービス要求管理 プロセスと呼ぶのが相応と考えられる。 図 II-1. サービス要求管理プロセスのフロー II.2 サービス要求管理のサブプロセスと活動 II.1 にあげたサービス要求管理のフローに沿っ て、サブプロセスに分類し各活動を説明する。 1) 要求申請 ビジネス部門など IT サービスの利用側で実施さ れる活動群である。「申請の起票」以外は主体な どの明示がないものの ITIL® V3 の要求実現の記 載でも触れられている。 (1) メニューの選択 サービスの利用者がサービス要求のメニューか ら自身の要求しようとするサービスを選択する。 (2) 申請の起票 所定の申請フォームがあればそれを利用し申 請を起票する。メニューにおいて価格が明ら かでない場合は、見積を取得する。価格など の条件により承認が必要であれば所定の承認 者に承認を求める。承認が不要であれば要求 受付に進む。 (3) 財務上の承認 有料のサービス要求の場合は、所属組織の上 司などの承認者が費用面の承認 / 否認を行う。 (4) その他の承認 目的の正当性や権限上の制約、コンプライア ンス上のチェックなどその他の承認が必要な 場合に担当の責任者が承認を行う。 2) 要求受付 サービスデスクなどインシデント管理 の初期プロセスとして実施される活動 群である。下記はインシデントをサー ビス要求 (SR) と置き換えて記載して いる。 (1) サービス要求の識別 インシデント管理の活動「インシデン トの識別」に相当する。 承認状況など必要な申請手続きが行わ れていることを確認し受け付ける。 (2) サービス要求の記録 インシデント管理の活動「インシデン トの記録」に相当する。 (3) サービス要求のカテゴリ化 インシデント管理の活動「インシデントのカテゴ リ化」に相当する。 インシデントと同様に受付けられたサービス要求 がここで分類され、要求実現の対象となる 3) 要求実現 要求受付を経たサービス要求は、必要な対応作業 を各担当チームに割当てられ実施される。サービ ス要求のメニューによりその対応作業が異なるが、 複数の担当チームに割当てられる一連の対応作業 の総体として要求が実現される。 (1) 対応作業依頼の受付 サービス要求の受付もしくは先行する対応作 ᙺ ἥ Ἂ Ἃ ᢿ ᧉ ⏦ㄳ⪅ ㈈ົୖ 䛾 ᢎㄆ⪅ 䛭䛾 ᢎㄆ⪅ ᵧ ᵲ ᢿ ᧉ 䝃䞊䝡䝇 䝕䝇䜽 ᢸᙜ 䝏䞊䝮 A ᢸᙜ 䝏䞊䝮 B ᢸᙜ 䝏䞊䝮 C 䝯䝙䝳䞊䛾 㑅ᢥ ⏦ㄳ䛾 ㉳⚊ ㈈ົୖ䛾 ᢎㄆ 䛭䛾䛾 ᢎㄆ SR䛾㆑ู SR䛾グ㘓 SR䛾 䜹䝔䝂䝸 SR䛾 䜽䝻䞊䝈 ᑐᛂసᴗ ౫㢗䛾ཷ ᑐᛂసᴗ䛾 ᐇ ḟ䛾ᑐᛂస ᴗ䜈䛾ᘬΏ ᑐᛂసᴗ ౫㢗䛾ཷ ᑐᛂసᴗ䛾 ᐇ ḟ䛾ᑐᛂస ᴗ䜈䛾ᘬΏ ᑐᛂసᴗ ౫㢗䛾ཷ ᑐᛂసᴗ䛾 ᐇ ḟ䛾ᑐᛂస ᴗ䜈䛾ᘬΏ せồᐇ⌧ せồཷ せồ⏦ㄳ ͤSR: 䝃䞊䝡䝇せồ
業が完了すると、開始すべき対応作業につい て担当チームもしくは担当者に依頼が行われ、 これを受け付け、担当者に割当てる。 (2) 対応作業の実施 担当者が対応作業を実施する。 (3) 次の対応作業への引渡 対応作業が完了した際、次の対応作業があれ ば次の担当チームにサービス要求を引き渡す。 (4) サービス要求のクローズ サービスデスクにて要求実現の全ての対応作 業が完了したことを確認しサービス要求をク ローズする。 この活動は要求受付の最終活動と位置付ける こともできる。
III. サービス要求管理の自動化
II.2 に述べたサー ビス要求管理の活動 は、近年のツール普 及によりかなりの部 分が自動化の対象と なりうる。本章では SRM システムの構築 に際し期待される自 動化要件、サービス 要求管理プロセス上 の各活動への効果を まとめる。 III.1 サービス要求管 理の自動化要件とメト リックス SRM の 自 動 化 シ ス テムが構築され、シ ステム上でサービス 要求管理を運営する 場合、活動のニュアンスは II-2 の記載と違ったものに なる。表 III-1 に一般的に期待される自動化の要件を まとめておく。基本的にワークフロー管理製品の利用 により実現可能なものであるが、導入される ITSM ツー ルとの統合を考慮することでシステム面でも SPOC（単 一窓口）が実現される。 またサービス要求管理の自動化により管理プロセ スの KPI 計測が可能、乃至は容易になる。メトリッ クス収集の例を合わせてまとめる。 表 III-1 にあるように、全般に画面入力支援や自 動通知などのワークフロー管理機能の恩恵を受ける ことになる。特に要求受付の活動は、要求申請の段 階をコントロールすることでサービス要求の識別、 分類や申請内容のチェックなどの自動化が実現し、 非常にシンプルに集約され画面で言えば１画面の操 作へと効率化できることが期待される。 尚、メトリックスの取得については全般にサービ ス要求や対応作業の各レコード自体とそれらの起 票・更新時のタイムスタンプの記録 / レポート機能 が前提となる。 表 III-1 サービス要求管理活動の主な自動化要件 άື 䛺⏬㠃 ᮇᚅ䛥䜜䜛⮬ືせ௳ 䝯䝖䝸䝑䜽䝇䛾 せồ⏦ㄳ 䝯䝙䝳䞊䛾㑅ᢥ 䞉ㄆドไᚚ 䞉䝃䞊䝡䝇せồ㑅ᢥᨭ(䝯䝙䝳䞊䛾ศ㢮䜔ㄝ᫂) 䞉⏦ㄳ䝣䜷䞊䝮䛾ㄏᑟ 䞉㑅ᢥ䛥䜜䛯䝃䞊䝡䝇せồᩘ ⏦ㄳ䛾㉳⚊ 䞉ධຊᨭ䞉⮬ື 䞉ධຊ䝕䞊䝍䛾䝏䜵䝑䜽 䞉ᢎㄆ⪅䜈䛾㏻▱ 䞉⮬㌟䛾㉳⚊䛧䛯⏦ㄳ䛾᳨⣴ 䞉㉳⚊䛥䜜䛯䝃䞊䝡䝇せồᩘ ㈈ົୖ䛾ᢎㄆ/ 䛭䛾䛾ᢎㄆ 䞉⏦ㄳෆᐜ䛾⾲♧ 䞉ᢎㄆᮇ㝈䛾㏻▱ 䞉ḟ䛾ᢎㄆ⪅䜈䛾㏻▱/ཷ䜈䛾㏻▱ 䞉⏦ㄳ⪅䜈䛾䝇䝔䞊䝍䝇㏻▱䜒䛧䛟䛿⾲♧ 䞉ᢎㄆᚅ䛱䛾䝃䞊䝡䝇せồᩘ 䞉ᢎㄆᚅ䛱㛫/ᢎㄆ䛻䛛䛛䛳䛯㛫 䞉ᢎㄆ䛥䜜䛯/ྰㄆ䛥䜜䛯䝃䞊䝡䝇せồᩘ せồཷ 䝃䞊䝡䝇せồ䛾 ㆑ู/ 䝃䞊䝡䝇せồ䛾 グ㘓/ 䝃䞊䝡䝇せồ䛾 䜹䝔䝂䝸 䞉ཷᢸᙜ⪅䛾⮬ືᙜ䛶 䞉ᑐᛂᮇ㝈䛾㏻▱ 䞉䜹䝔䝂䝸ศ㢮䜔䝃䞊䝡䝇せồ㆑ู䛾⮬ືධຊ 䞉ᢎㄆෆᐜ䛾⮬ື☜ㄆ(ᢎㄆ῭䛾䜒䛾䛾䜏ཷ) 䞉ᚲせ䝕䞊䝍䛾⮬ື☜ㄆ/☜ㄆᨭ 䞉ᑐᛂసᴗ౫㢗䛾㏻▱ 䞉⏦ㄳ⪅䜈䛾䝇䝔䞊䝍䝇㏻▱䜒䛧䛟䛿⾲♧ 䞉ཷ䛡䜙䜜䛯䝃䞊䝡䝇せồᩘ 䞉ཷᢸᙜ⪅䛻ᙜ䛶䜙䜜䛯䝃䞊䝡䝇せồ ᩘ 䞉ཷᢸᙜ⪅⮬㌟䛷ᑐᛂసᴗ䜢ᐇ䛷䛝䛯 䝃䞊䝡䝇せồᩘ 䞉ྠྜ(䛔䜟䜖䜛䠍ḟゎỴ⋡) せồᐇ⌧ ᑐᛂసᴗ౫㢗䛾 ཷ 䞉సᴗᢸᙜ⪅䛾⮬ືᙜ䛶 䞉సᴗᮇ㝈䛾㏻▱ 䞉ᢸᙜ䛩䜛⏦ㄳ䛾᳨⣴ 䞉⏦ㄳ⪅䜈䛾䝇䝔䞊䝍䝇㏻▱䜒䛧䛟䛿⾲♧ 䞉ཷ䛡䜙䜜䛯సᴗ౫㢗ᩘ ᑐᛂసᴗ䛾ᐇ 䞉సᴗෆᐜ䛾ධຊᨭ 䞉ධຊ䝕䞊䝍䛾䝏䜵䝑䜽 䞉⏦ㄳ⪅䜈䛾䝇䝔䞊䝍䝇㏻▱䜒䛧䛟䛿⾲♧ 䞉ᐇ୰䛾సᴗ౫㢗ᩘ 䞉సᴗ䛻䛛䛛䛳䛯㛫 䞉䛧䛯సᴗ౫㢗ᩘ ḟ䛾ᑐᛂసᴗ䜈 䛾ᘬΏ 䞉ḟ䛾ᑐᛂసᴗ౫㢗䛾㏻▱ 䝃䞊䝡䝇せồ䛾 䜽䝻䞊䝈 䞉㐃⤡᪉ἲ䛺䛹⏦ㄳ⪅ሗ䛾⾲♧ 䞉ධຊ䝕䞊䝍䛾䝏䜵䝑䜽 䞉⏦ㄳ⪅䜈䛾䝇䝔䞊䝍䝇㏻▱䜒䛧䛟䛿⾲♧ 䞉䜽䝻䞊䝈䛧䛯䝃䞊䝡䝇せồᩘ 䞉䝃䞊䝡䝇せồ䛾䛻䛛䛛䛳䛯㛫 䞉䝃䞊䝡䝇せồ䛾ཷ䛛䜙䜎䛷䛻 䛛䛛䛳䛯㛫 䝯䝙䝳䞊 ⏦ㄳ ᢎㄆ ㏻▱ ᳨⣴䞉 ୍ぴ ☜ㄆ䞉 ධຊ ☜ㄆ䞉 ධຊ ㏻▱ ㏻▱ ㏻▱ ☜ㄆ䞉 ධຊIV. 要求実現における対応作業の管理と
ビジネス ・ サービス要求
上記で説明したサービス要求管理プロセスは、サ ービス要求が個々に独立した流れで実現される場合 の流れを示している。本章では、異なるサービス要 求の実現が連携するケースに発展させて考えてみよ う。ワークフロー管理製品の IT サービスへの利用や SRM ツールの市販化は IT に対するサービス要求だけ でなくビジネス上のいわゆ る業務サービスのサービス 要求の管理を自動化する基 盤を提供し、IT とビジネス のサービス協調を支援する 状況を迎えている。 IV.1 要求実現における個々の対応作業の管理 サービス要求の要求実現において一連の対応作業は 通常、サービス要求のメニュー毎に紐づけられた手続 きとして定型化が求められる。運用改善活動の中で、 サービス要求の必要対応時間の分析を試みることが良 く行われるが、要求実現の手続き全体で計測・分析す ると少なからぬ割合のサービス要求について、個々の 実績値にばらつきが大き過ぎて、非定型な要素が多く、 定常的な改善が困難なものと分類されることになる。 実はこのような手続きは、手続きを構成する個々 の対応作業の単位に踏み込むことで管理・改善が可 能になるケースが多い。手続きが複数の対応作業で 構成されている場合に特定の対応作業にばらつきを 伴う待ち時間が発生すれば、手続き全体の対応時間 にそのまま影響が出てしまうからである。他の対応 作業を切り出して計測すれば十分に定常的な改善対 象にできたり、ばらつきを伴う対応作業自体にも明 確な対策を打てることがある。尚、待ち時間が発生 する対応作業の例としては次節で述べるような異な るサービス要求間で共有される対応作業を含んでい る場合が少なくない。 IV.2 異なるサービス要求の実現手続きの連携 要求実現の手続きに用いられる個々の対応作業に 視点を移してみると、対応作業自体は必ずしも一つの サービス要求手続きだけではなく複数のサービス要求 手続きの中で発生するものがある。例えば、自社向 けの PC 調達サービスで発生したサービス要求も顧客 ( 他社 ) 向けの PC 調達サービスで発生したサービス 要求も、その要求実現の手続きにおいては同一の対応 作業として PC キッティング作業を同じ担当組織が実 施することが考えられる。その前後の作業は資産管理 上の手続きや配送上の手続きなどサービス要求により 別々の作業となっているケースである。( 図 IV-1) 図 IV-1 異なるサービス要求で共有される対応作業 このようにサービス要求の単位で管理している場 合は別々のサービス要求に埋没してしまうような 個々の対応作業であるが、管理単位を対応作業にま でブレイクダウンすることで異なるサービス要求に 共通で発生する作業 ( 上例の PC キッティング作業 ) についてもパフォーマンス管理や改善策をうつこと が可能になるのである。勿論対応作業を担当するチ ーム別の視点で分析・把握することもできる。 IV.3 ビジネス・サービス要求への拡大と サービス要求の包含関係 ITIL® におけるサービス要求は、IT 部門や IT サ ービスプロバイダに対するリクエストを対象にして いるが、従来、ビジネスを支える業務サービスにも 同様にサービス要求は存在しているし、ITO(IT アウ トソーサ ) が BPO( ビジネス・プロセス・アウトソ ーサ ) を兼ねることも少なくない。ITIL® プロセス で言えば ITSCM が BCM を下支えするのも近しい包含 関係を示している。 例えば、新入社員の配属先オフィス情報・連絡先 まで含めた人事情報をインプットし社員証など総務 関連の準備を依頼できる業務上のサービス要求 ( ビ ジネスサービス要求 A) があるとする。一方で新入 社員や派遣社員に関わらず、作業 PC 一式を調達す る IT 上のサービス要求 (IT サービス要求 B) がある。 䝃䞊䝡䝇せồB 䝃䞊䝡䝇せồA ᑐᛂసᴗA-1 ᑐᛂసᴗC ᑐᛂసᴗA-2 ᑐᛂసᴗB-1 ᑐᛂసᴗB-2 ⏦ㄳA ⏦ㄳB上例のケースではビジネス・サービス要求 A と IT サ ービス要求 B は別々のサービス要求である。サービ ス要求管理システムの範囲を拡大し、ビジネス・サ ービス要求 A のようなサービス要求を同一の SRM シ ステム上のメニューに加えた場合を考えてみよう。 新入社員を迎え入れる上司つまり SRM システムへ の申請者にとっては二つのサービスは同じ時期に必 要となり、また共通の情報を都度入力しなければな らないため、同一の申請で済ませたいという要望が 強まることは間違いない。その対応として、ビジネ ス・サービス要求 A に IT サービス要求 B を含めた ビジネス・サービス要求 C というサービス要求がメ ニューに追加される ( 図 IV-2)、もしくはビジネス・ サービス要求 A と置き換えられることになる。 図 IV-2 ビジネスサービス要求による IT サービス要求の包含 このようにサービス要求のメニューが業務サービ スにまで範囲を広げ、サービス要求の間に包含関係 が生まれることで、IV.1 にあげた個々の対応作業は ますます多様なサービス要求に埋没していくことに なる。このため要求実現のパフォーマンス改善のた めには対応作業単位の管理がより必要になってくる ものと考えられる。
V. まとめ
本稿ではインシデント管理の一環で扱われがちな サービス要求についてインシデントとの違いを見直 し、要求の申請から始まり要求実現を含んだサービ ス要求の管理プロセスの活動をまとめた。またワー クフロー管理製品や ITSM ツールを活用したシステ ム化基盤の普及を鑑み、サービス要求管理の自動化 における主な要件を抽出した。 今後 IT サービス要求に留まらずビジネス・サー ビス要求を含めて一元化していくことによりサービ ス利用者の利便性が向上する一方で、要求実現のマ ネジメントにおいては対応作業の単位での管理の必 要性が高まってくるものと考えられる。 小澤 一友 株式会社シグマクシス / マネージャITIL® V2 Manager/V3 Expert Certifi cate、PMP、ISO/ IEC 20000 Consultant Certifi cate
1992 年、自然言語処理への関心から IT 企業に入社、 システム開発／保守、特に広域監視システムの研 究・構築などシステム運用管理関連の経験を経て、 2004 年 4 月 ITIL® マネージャ認定を取得、組織的な ITIL® 活用推進、品質改善活動に取組む。以降 IT 企 業数社にて IT 運用改善、IT サービスマネジメント 導入コンサルティング、IT アウトソーサ創業に際し た品質マネジメントシステムの構築などを経験。 IT䝃䞊䝡䝇せồB 䝡䝆䝛䝇䝃䞊䝡䝇せồA ᑐᛂసᴗA-1 ᑐᛂసᴗA-n ⏦ㄳA ᑐᛂసᴗA-2 IT䝃䞊䝡䝇せồB ᑐᛂసᴗB-1 ᑐᛂసᴗB-n ⏦ㄳB ᑐᛂసᴗB-2 䝡䝆䝛䝇䝃䞊䝡䝇せồC ᑐᛂసᴗA-1 ᑐᛂసᴗA-n ⏦ㄳC ᑐᛂసᴗA-2 ᑐᛂసᴗB-1 ᑐᛂసᴗB-n ⏦ㄳB ᑐᛂసᴗB-2
