竹内広宜(武蔵大学)です。MLSEの運営委員もつとめています。機械学習技術を活用したサービスシステムの開発におけるプロジェクト管理や要求分析などに興味を持っています。本記事では、最近取り組んでいるトピックについて説明します。
#はじめに
機械学習(Machine Learning:ML)技術の急速な発展に伴って、社会の様々な分野でML技術を用いたシステムが開発されつつあります。本記事では、オフィス業務などにML技術を適用するプロジェクトを主な対象として考えます。人工知能(Artificiail Intelligence: AI)の中心技術であるML技術の企業で活用する際、事業部門には経営者を中心にAIに対して過度な期待を持っていることがあります。例えば，AIを導入することによって業務のほとんどが自動化されるといった期待されることもあるでしょう。しかし現実にはML技術が適用されるのは業務の一部タスクにのみに留まることが多いです。したがって、期待値コントロールを適切に行わないと、開発したシステムへの期待およびかけたコストと、結果として得られる適用効果との間に事業部門側がギャップを感じてしまいます。その結果、業務適用の検証段階でプロジェクトが終了してしまうことも多々あると思われます。
このような状況以外にもML技術の業務実用化を進めるにあたっては様々な課題が生じており、ML技術を活用したシステムの開発における工学的解決策考案の必要性が述べられ、機械学習工学(MLSE)と呼ばれる研究分野が注目されるようになったのだと考えられます。
ML技術を用いたシステムの開発では、上流工程の要求分析からテスト検証まで様々な課題があります。例えばML技術を活用したプロジェクトにおける代表的な課題が"9 Reasons why your machine learning project will fail"として公開されています。これらはプロジェクト経験者にとって”あるある”です。 このうち以下の1から4はプロジェクト管理上の課題と考えられます。
- 課題設定が間違っている
- 間違った問題を解くために機械学習を使っている
- 適切なデータが十分にない
- 適切な評価方法を用いていない
これらの課題は、事業部門(オフィス業務を実施する部門)と開発部門が開発対象について共通理解を持つことができるプロジェクト計画時に解決できると期待されます。そこで、ここでは、ML技術を業務適用する開発プロジェクトを企画する際、対象業務で目指すゴール、開発するアプリケーション、必要となるデータなどとの関係を示すビジネスITアライメントのためのモデルについて、エンタープライズアーキテクチャ(Enterprise Architecture: EA)の考え方に基づき表現したモデルとその作成方法について述べます。
#エンタープライズアーキテクチャとMLサービスシステム
エンタープライズアーキテクチャ(Enterprise Architecture: EA)は企業の活動をモデル化する手法です。Open Groupが開発したEA用の標準モデリングArchiMateがあります。ArchiMate専用のモデリングツールとしてArchiがあり、フリー版もあります。ArchiMateでは対象をビジネス、アプリケーション、テクノロジーの層に分けて表現するとともに、対象業務のゴールなどもEAとして表すことができます。ここでは、ArchiMateを用いてML技術を活用したシステム(MLサービスシステム)の開発プロジェクトをモデル化します。
ご存知の通り、MLサービスシステムは訓練データを機械学習アルゴリズムに投入し訓練済みモデルを作成する部分(訓練エンジン)と，訓練済みモデルに対して入力データを投入し出力を得る部分(ランタイムエンジン)に分かれます。MLサービスシステムを開発する場合、対象業務のデータから訓練データを準備し、そこから学習によって訓練済みモデルを作るプロセスと、訓練済みモデルを利用するMLエンジンを使った業務アプリケーション(MLアプリケーション)を開発し、それをユーザーが利用するプロセスがあります。これらの要素をArchiMateで表現すると以下の図となります。
ArtchiMateの記法についての説明は、アーキテクトなら知っておきたいアーキテクチャ・モデリング言語ArchiMate（イントロ編）が参考になります。なお、本記事のモデルに登場するアイコンや矢印の簡単な説明は以下の通りです。
#MLサービスシステムのためのビジネスITアライメントモデルとその構成方法
業務システムの検討や評価ではビジネスゴール、ビジネスプロセス、アプリケーションの関連付けし、ビジネスITアライメントと呼びます。このビジネスITアライメントにより経営者も含めたステークホルダーが対象システムに対して共通理解を持ち、ITシステムの変革に対して俊敏に対応できるようになると期待されています。EAモデリングに基づくとMLサービスシステムに関するビジネスITアライメント(ビジネスMLアライメント)の汎用モデルは以下のように表されます。
上図のビジネスMLアライメントモデルはMLサービスシステムプロジェクトを表す汎用モデルであり、個々のプロジェクトに適用するには具体化する必要があります。この具体化の作業では、ビジネス視点や機械学習とはじめとした技術の視点が必要となり、事業部門の担当者やデータサイエンティストの参画が望まれます。しかしながら、プロジェクトの初期検討段階で彼らの参画を期待することは難しく、現実には、プロジェクト提案作業の中でプロジェクトマネージャー(PM)などが中心となって作業することが想定されます。
ここで、ビジネスモデルのモデリング手法に関する既存研究にある課題分析表およびASOMG表を拡張した具体化手法を示します。開発対象に応じたビジネスMLアライメントモデルの構成方法は以下の通りとなります。
(1). ビジネス課題をステークホルダー、問題状況、原因分析、あるべき進歩などをビジネスレベルとサービス設計レベルの視点で分析する初期課題表を作成する
(2). 対象業務をステークホルダー(A)、サービス(S)、サービス情報 (O)、主要成功要因(G)、評価記述(A)をサービス利用、サービス設計、MLサービス設計の3段階の視点で分析するASOGA表を作成する
(3). 初期課題表にサービス設計とMLサービス設計の視点を追加したものを拡張課題分析表と呼び、ASOGA表の分析結果をもとに作成する
(4). 拡張課題分析表およびASOGA表の要素をビジネスMLアライメント汎用モデルに反映させる
ここで、初期課題表、ASOGA表、拡張課題表は以下のようなものです。
これらの表を用いた上記の手順を図示すると以下のようになります。
#実践例
ここでは銀行における海外送金業務にML技術を適用する実プロジェクトに適用した結果について述べます。銀行では、個人や法人から依頼を受け海外への送金を行っていますが、この海外送金業務では，顧客が指定する送金先に直接送金することは少なく、最終的な送金先に応じた仕向先に銀行は一旦送金します。したがって、海外送金業務では、担当者は顧客からの依頼書を元に仕向先を判定し、検証者が判定結果を確認した後、仕向け先情報を送金システムに入力するという一連のタスクを行っています。
顧客からの送金依頼書には、通貨名と金額とともに，自然文で書かれた送金先が記載されています。仕向先判定担当者は、自然文で書かれた送金先記述から顧客の送金先の金融機関の情報(銀行名、銀行コード、国名、都市名)を抽出し、それらの情報を銀行内のビジネスルールに適用し仕向先を決定します。この記述は請求書に書かれた記載がそのまま書かれており、スペルのミスだけでなく、一見すると銀行名とは考えられない名称(例えば，BROWN BROTHERS HARRIMAN など)が書かれていることがあります。ですので、この仕向先判定作業は担当者の経験によって作業時間が大きく変わる場合があります。
これらの業務課題をもとに分析手順に沿って表を埋めると以下のようになります。
こうして埋められた表の値を汎用ビジネスMLアライメントモデルにマッピングすると、仕向先判定作業に対するMLサービスシステムのビジネスITアライメントモデルが以下のように出来上がります。
作成された仕向先判定作業に対するMLサービスシステムのビジネスITアライメントモデルを参照することで、事業部門のミッションは海外送金業務であり、その課題(Goal)は、
- (送金)事務コストの削減
- 仕向先判定作業の短縮
- 仕向先判定の自動化
と業務レベルからMLエンジンレベルに分解されます。そして開発するビジネスサービスやアプリケーションコンポーネントによってそれぞれの課題が解決されることが表現されています。作成したビジネスITアライメントモデルにより、事業部門、開発部門がプロジェクトを進める中で、それぞれの視点でどのような課題が解決されるのかを把握できると期待できます。
またこのビジネスITアライメントモデルでは、それぞれの課題に対する評価指標が設定されています。適用例プロジェクトでは
- 送金事務1件あたりの平均作業時間
- サービス利用時の仕向け先判定の正解率
- 固有表現( 銀行名・コード・国名・都市名)抽出の精度・再現率
としました。これにより、各レベルの課題を実現するプロジェクト関係者は、上位の課題の関係者が評価指標を算出するのに必要な情報として、自身が行った評価結果を提供することになります。
このようにMLサービスシステムについてビジネスITアライメントモデルによって、事業部門の経営者に対しては、所管する業務のどこにML技術が適用されるのか、どのような効果が得られるのかを俯瞰して示すことができます。また、事業部門の担当者にとっては、自身は事業部の視点としてどのようにシステムを評価すれば、良いのか、業務上十分な性能を得るためにはML技術の性能がどうあるべきかを判断することが容易になると期待されます。
#最後に
ML技術の業務に適用するプロジェクトを企画するにあたり、プロジェクト全体を事業部門およびIT部門で俯瞰し、共通理解するためのビジネスITアライメントモデルを考えました。実例も示しましたが、より多くのケースで、どれだけ容易にモデルを作れるのか、データサイエンティストではないプロジェクト担当者でも作成する際の勘所は何かといったところについてはこれから検討すべき課題です。また、プロジェクトの企画や実施に置いて、このようなモデルをどう活用できるのかについても検討したいと考えています。これらについては、MLSEのプロセス・事例収集WGや、ソフトウェア工学ウィンターワークショップのセッション(T2:機械学習応用システムの不確かな要求の抽出とモデル化)で議論できたらいいな、と思っています。