1．はじめに

深層学習を始めとした機械学習技術の発展に伴い，人工知能（Artificial Intelligence：AI）技術の社会実装が始まっている．機械学習や自然言語処理といったAIの要素技術（AI技術）が一部Application Programming Interface（API）として公開され始めている．それに伴い，アプリケーション開発者は適用対象に関するデータを準備することでAI技術の業務適用を検討することが可能となりつつある．金融機関においてもAI技術の適用が開始されており，営業事務支援，コールセンタ（ヘルプデスク）のオペレーションといった領域はAI技術と親和性が高く，10年後の業務代替性が約40%になると推測されている[1]．このような背景から，AI技術の導入を評価する検証（Proof of Concept：POC）プロジェクトが多数実施されている．

AI技術のオフィス業務適用にあたって，経営者を始めとした利用者側には，AIに対する過度な期待がある一方，AI技術は業務の一部タスクにのみ適用可能であることが多い現実がある．また，システムの構築にあたって対象業務に関するデータを元に学習データを作成する必要があり，そのためには，業務に関連する知識や経験が必要となる．たとえば，事務手続きについての質問に回答する照会応答業務において，AI技術を用いて質問を自動分類し，回答候補を照会応答担当者に提示することを考える．この場合，業務マニュアル中の各記述について，どのような質問に対する回答かという情報を付与し，学習データとして作成することが考えられる．このような作業は，ベンダを含む開発部門側だけではできないため，開発を依頼する事業部門のメンバがプロジェクトに参画する必要がある．また，AI技術の中で重要となっている機械学習技術は，確率的な振る舞いをし，入力によって異なる出力が確率を元にした確信度とともに得られる．そのため，入力によっては望ましい結果が得られない場合がある．適用業務によっては，たとえば確信度の低い出力が得られた場合は複数の候補を出力するといった後処理を別途開発し，システムとしてその利用者が満足する結果を提示することも必要となる．その結果，事業部門側がシステム構築にかかるコストに見合う効果が得られる見込みを立てられず，業務適用の検証段階でプロジェクトが終わり，AI技術の検証に多くのコストをかけたにもかかわらず本格展開に至らない状況も生じている[2]．

このような状況に対して，AI技術の中核となる機械学習を活用したシステムの特徴やそのようなシステムの開発における工学的課題と解決策考案の必要性が機械学習工学として提唱されている[3]．しかしこれらの研究は自動運転を中心とした組込みシステムを対象としたものが多く，また開発プロセス中の実装やテストフェーズに注目しているものが多い．そのため金融機関のオフィス業務を含めたエンタープライズ領域におけるAI技術の活用についてプロジェクト管理上の課題を扱った研究はほとんどない．

本稿では，このような状況において，金融機関においてAI技術を適用したプロジェクトを分析し，プロジェクトの成否につながる共通の事象を同定し，プロジェクト管理に活用することを目的とする．具体的には，プロジェクトを開始するまでに関係者で行った議論の状況から，プロジェクトの準備状況をモデル化する．このとき，モデル化の手法として保証ケースを用いた．保証ケースは，ある対象に関する主張をサブゴールに分解し主張に関する議論状況を可視化する手法である．そして，作成した保証ケースを用いてプロジェクトの評価やプロジェクト間の比較分析を行い，プロジェクトの失敗を回避し成功に導く項目を成功要因として同定する手法[4] [5]を金融機関における実プロジェクトに適用する．また，同定された成功要因に着目し，プロジェクトの導入準備評価を行う手法や，システム内で利用する個々のアルゴリズムだけでなく構築するシステム全体を評価する方法といったプロジェクト管理における活用について検討する．

本稿では金融機関でのプロジェクトを分析するが，そこで得られる結果は金融機関における業務に大きく依存するものではないと考えられる．しかしながら，上述のように金融機関ではオフィス業務などにAI技術を適用するための検証プロジェクトが多数実施されているため，本稿で紹介するプロジェクト実践上の知見はより効果的に活用できると考えられる．

本稿の構成は以下の通りである．第2章で関連研究を述べた後，第3章で本稿の研究対象のシステムとその開発プロジェクトの課題を概観し，研究仮説を述べる．そして第4章でプロジェクト分析手法について説明し，第5章で金融機関における実プロジェクトを対象として分析した結果とプロジェクト管理上の知見について述べる．第6章で今後の方向性について考察した後，最後に第7章で本稿のまとめを行う．

2．関連研究

プロジェクトの成功とは，ビジネス目的を決められた予算および期間で達成することであり，プロジェクトの体制や計画について事前に列挙した項目とプロジェクトの成功度合いを，企業内データベースシステムの構築プロジェクトなどを対象に調査した研究がある[6]．また，各プロジェクトだけに注目せず，ITシステム構築プロジェクトを進める組織の特性とプロジェクトの成功との関係を調査した研究がある[7]．

ビッグデータ解析や，機械学習といったAIの要素技術を使ったシステムの開発プロジェクトに関する研究として，[8]ではプロトタイピングを活用し，関係者で要求の抽出と検証を繰り返し行いながら開発を進める手法が議論されている．また，ビッグデータ解析やAI技術の活用においてデータサイエンティストが担う役割や分析プロセスについても議論されている[9][10]．しかし，これらの研究ではプロジェクトを推進する際，前提や事前準備としてどのような項目を関係者で議論し合意するべきか，という点は考慮されていない．一般のソフトウェアシステムの開発における前提や制約については，抽象的な分類が提案されている[11]．しかし，AI技術の適用プロジェクトなどを考える場合，AI技術の特性に沿ってプロジェクト関係者で合意すべき前提を整理する必要があるが，そのような整理手法の検討は行われていない．

3．研究対象と研究仮説

3.1　AI実践システム

本稿では，オフィス業務などの金融機関などのオフィス業務へAI技術を適用するプロジェクトを対象とする．オフィス業務において人間はさまざまな知的活動を行っている．人間の知能には分析知能・創造知能・実践知能があると考えられている[12]が，本稿では，オフィス業務における分析知能を用いた活動をAI技術によって支援することを考える．

分析知能とは，与えられた入力に対して，複数ある選択肢の中から最適なものを選択する知能である．事務処理に関する問い合わせへの回答や，書類の審査などの活動では，この分析知能が用いられていると考えられる．AI技術を使った分析知能の実現として機械学習技術の活用が考えられる．対象業務に基づき選択肢（問い合わせ業務における回答や，審査業務における審査結果）を定義し，事前に用意した入力例に正解となる選択肢を付与することで学習データを作る．そして，それを機械学習させることで，さまざまな入力に対して選択肢を自動的に選び，出力することができる．このような分析知能を実現するAIエンジンは図1のように表される．

本稿では，図1のように表現される機械学習などのAIエンジンを組み合わせ，オフィス業務活動を支援するシステムを対象とする．このようなシステムをAI実践システムと呼び，その開発プロジェクトをAI実践プロジェクトと呼ぶ．

3.2　金融機関におけるAI実践システムの開発例

本節では，金融機関におけるAI実践システムの開発例について述べる．

3.2.1　コールセンタにおける照会応答支援

金融機関は多くの企業と同様にコールセンタを開設し，顧客や社内からの問合せに回答する照会応答業務を行っている．ここでは照会応答業務を支援するAI実践システム[13]について述べる．

金融機関のコールセンターのオペレータは，顧客や社員からの問合せに対し，関連する業務文書（FAQやマニュアル）を探し出し，それを指差し確認しながら回答を行っており，問合せによっては，関連する業務文書を探し出す時間が長くなっていた．このような状況に対し，質問者（問合せをして来た顧客や社員）とオペレータとの会話の声を音声認識によりリアルタイムでテキスト化し，そこから分類技術によって会話のトピックを推定，その結果を基に関連する業務文書を検索するシステムを開発した．システムの概要図を図2に示す．

このAI実践システムの活用により，オペレータは質問者と会話をしながら，画面に出力された回答候補から適切なものを選択し，指差し確認しながら回答を読み上げることで効果的に業務を進められるようになっている．

3.2.2　海外送金事務における仕向先判定支援

金融機関では，個人や法人から依頼を受け海外への送金を行っている．この海外送金業務では，顧客が指定する送金先に直接送金することは少なく，最終的な送金先に応じた仕向先に，いったん送金する．したがって，海外送金業務では，担当者は顧客からの依頼書を元に仕向先を判定し，検証者が判定結果を確認した後，仕向先情報を送金システムに入力するという一連のタスクを行っている．

顧客からの送金依頼書には，通貨名と金額とともに，送金先が自然言語で記載されている．仕向先判定担当者は，自然言語で書かれた送金先記述から顧客の送金先の金融機関に関する情報（銀行名，銀行コード，国名，都市名）を抽出し，それらの情報を銀行内のビジネスルールに適用し，仕向先を決定する．この作業では送金先の金融機関の情報の抽出は担当者の思考内で行われ送金依頼書には決定された仕向先情報が付加される．

仕向先判定作業において，経験の少ない担当者が行う場合，または，“BROWN BROTHERS HARRIMAN”のように銀行名かどうかの判別が困難な名称が送金先記述欄に書かれている場合，過去の事例や業務マニュアルなどを参照することになり，送金先となる金融機関の理解に要する時間が長くなる．そこで自然言語で記載された送金先から，金融機関に関する上記4つの情報を機械学習技術で自動抽出し，その結果をもとに仕向先判定を行うAIシステムを開発した．開発したシステムが行う処理概要を図3に示す．

過去の送金依頼書には決定した仕向先情報は付与されているが送金先金融機関の情報は明示的に示されていない．そこで，銀行名などの固有表現をアノテーションした．こうして作成した学習データを使い，送金先情報を得るためのAIエンジンとして，対象分野に合わせて独自に定義した固有表現を抽出する機械学習エンジンを訓練した．そして，この機械学習による自動抽出エンジンと，その結果をビジネスルールに適用し仕向先を決定するアプリケーションを開発した．この支援システムにより仕向先判定の作業が担当者の熟練度や送金先についての記載内容に大きく依存せずに進められるようになっている．

3.3　AI実践プロジェクトを進める上での課題

従来のオフィス業務システムのウォーターフォール開発では，開発部門がシステムの利用者である事業部門の担当者にヒアリングを行い，対象業務で用いられるデータ項目間の関係やビジネス遂行上の留意点などを要求として抽出し，それらをロジックとして実装しシステム化していた．それに対して，機械学習やビッグデータ解析技術といった先進技術を用いた新たな業務システムの構築では，システムに求められる要求を利用者から十分に獲得できないことが多い．そのような状況では，最初に必要最低限の機能のみからなるシステムとしてMinimum Viable Product（MVP）を開発し，業務適用で想定される課題が解決できることを事業部門と開発部門の両者で検証する．そして，検証結果を通して新たなる要求を抽出し，繰り返し開発するアジャイル開発を通して，業務への適用を本格化することが行われている[8]．

さらにAI実践プロジェクトはさまざまな価値の仮説検証を繰り返し行うのではなく，達成したい目標に出力が近づくまでデータや手法の適用を繰り返す．たとえば，第3.2節で述べた，業務や商品・サービスに関する質問に答える照会応答の支援や自動回答，さまざまな個別データが記入されている書類に対する審査業務での判断支援では，MVPを作成する段階でシステムが内部に持つ選択肢を対象業務に基づき定義することや，入力例に対して正解となる選択肢を付与する学習データの作成が必要となる．学習データを準備することでAIエンジンを初めて動かすことができる．そして学習データの量や適用するアルゴリズムを変え，システムの出力が目標を達成するかどうかを繰り返し検証する．そのため，想定したスケジュール通りに学習データを成果物として出すことが求められる．学習データの作成作業はシステムを動かす上で重要であるが開発部門で実施することは難しく，対象業務に精通した事業部門の担当者が参画し，実施する必要がある．

また，機械学習技術によって構築したシステムから得られる出力は，構築時に用いた学習データに大きく依存する．そのため，入力によって結果が異なり，入力によっては望ましい結果が得られない場合もある．そのため，業務適用時において必要となる精度を設け，それに向けてプロジェクト期間中に学習データを追加・改善し，精度を上げることや，望ましい結果が得られない場合にシステム全体としてどのように対応するかといった検討を開発部門および事業部門の両者で行い，実装する必要がある.

このように，AI技術のオフィス業務への適用では，利用者となる事業部門側がプロジェクトにおいて自身が担う作業について理解し，スケジュールに沿って遅延なく作業を進めることが重要である．通常，プロジェクト提案書を作成した段階で，開発部門側・事業部門側の作業項目やスケジュールは合意されている．しかしながら，事業部門側が，自身が担う作業（業務文書などのデータに学習用の情報を付加する作業など）の重要性を理解していないことから作業が遅れ，その結果，十分な学習データが準備できず，プロジェクト期間中に出力が必要とされる精度に達しないことが生じている．また，AI技術を使ったシステムの特性や出力の精度について，事業部門の担当者が適用する業務にそれらがどのように影響を与えるのか十分に理解できないことにより，出力の精度が低い場合への対応策を十分に検討できないことも生じている．その結果，対象業務への機能適合性を検証するために必要な作業をプロジェクト期間内に十分に行えず，本格展開に進まずにプロジェクトが検証段階で終了する状況が起きている（図4）.

　

3.4　研究仮説

第3.3節で述べた課題に対して，本稿ではAI実践プロジェクトを分析し，その分析結果をプロジェクト管理に活用することを検討する．分析において，プロジェクト間を比較し何かしらの特徴を得るには，各プロジェクトの準備や実施の過程をモデル化する必要がある．本稿では，AI実践プロジェクトを開始する段階で収集するデータや構築するシステムを適用するビジネス内で利用方法について事業部門と開発部門の間で合意形成することが重要だと考える．そして，準備状況が，プロジェクトが検証段階で終了するか本番展開に進むかどうかに影響を与えるという仮説を立て，プロジェクトの準備状況をモデル化し分析することを考える．

具体的にはプロジェクト開始までの議論をもとにプロジェクトの準備状況をモデル化し，AI実践プロジェクトの評価やプロジェクト間の比較について分析を行う（図5）．このとき，対象に関する主張をサブゴールに分解し主張に関する議論状況を可視化する手法である保証ケースを本目的に沿って定義する．そして，分析結果から，

• AI実践プロジェクトにおいて，失敗を回避するための準備状況上の特徴を成功要因として同定できる
• 成功要因からプロジェクト管理上の知見が得られる

ことを検証する．以降，第4章で分析手法の詳細について述べ，第5章で実プロジェクトを分析した結果について述べる．

　

4．プロジェクト分析手法

プロジェクトの準備状況を保証ケースで表現することを考える．保証ケースは，抽象度の高い上位の主張を網羅的に分解し，根拠とともに記載する議論の記述法である[14]．プロジェクト関係者（利用者や開発者）間の共通の主張（ゴール）に対して客観的な記述を行うことで，プロジェクト実施にあたり，必要な作業の目的やその重要性について，利用者と開発者の双方の共通理解を期待できる．また，各サブゴールが満たされていることを調べることにより，最終目標である上位のゴールについてその達成度合いを評価することも期待できる．

まず，AI実践システムが持つべき特性を満たしていることを最上位のゴールとして保証ケースを作成する．保証ケースはGSN（Goal Structuring Notation）[15]を用いて記述する．AI実践システムの開発ではAI技術の業務適用の検証に必要な最低限の機能のみを持つシステム（MVP）を作ることが行われている．そこで，ISO9126で定義されている品質特性[16]のうち，機能性を満たすことを最上位のゴールとする．機能性には品質副特性が定義されている．それらは，合目的性（適切性），正確性，相互運用性，機密性，標準適合性であり，それぞれについてソフトウェアシステムとして満たすべき特性として定義されている．本稿では，図1で述べた分析知能システムの持つ特性を元に，これらの品質副特性を拡張する．AI実践システムの機能性品質副特性を表1のように定義した[5]．たとえば，合目的性は選択肢がシステム内に網羅的に定義されていることを示すが，これは対象が照会応答業務であれば業務に関する回答，審査業務であれば審査結果が，漏れなく定義されていることに相当する．

最上位のゴール（機能性を満たすこと）を表1に示した品質副特性をサブゴールとして分解する．ここで，合目的性，正確性，相互運用性を満たすというサブゴールはそれぞれ，選択肢，精度，入出力に関して必要となる前提条件となっている．対象業務に合わせてAIエンジン内に定義する選択肢は網羅性があるだけでなく，システム化できる形で外在化され，さらに機械処理が容易な形で電子化および構造化されている必要がある．また，正確性については，精度の定義が明確化できていることと，精度を向上させる手段がある必要がある．そして，入出力については，想定される入力の品質だけでなく，出力の品質が十分でない場合の対応策が検討されていることが重要となる．このような観点で合目的性，正確性，相互運用性のサブゴールをさらに分解する．作成したゴール分解木を図6に示す．

　

得られた分解木に根拠を付与し，プロジェクト導入準備状況を表す保証ケースを作成する．分解木の末端のサブゴール（G_5，G_6，G_7，…，G_15）に対して，プロジェクト開始までの議論内容を分析し，その内容を根拠として付与する．しかしながら，プロジェクト開始までに，すべての末端サブゴールが議論されないケースもある．その場合は，ゴールを保証するための十分な議論または根拠がないことを示すため，保証ケースで定義されている未展開記号を付与する．一方，サブゴールの中には開発者の判断で議論不要とするケースも存在する．たとえば，AIエンジンの仕様により，ゴールが自動的に満たされる場合が相当する．このような状況を表現するために，点線の楕円記号を新たな記法として導入し，そこに議論が不要である理由を記載し未展開記号に付与する．これにより，プロジェクト開始までの段階で，議論が不要と判断したことを明示的に示すことができる．これらの根拠の付与パターンを図7に示す．

　

こうして作成された保証ケースを用いて，プロジェクト開始時点での準備状況を評価する．具体的には，プロジェクト開始時の情報を元に作成された保証ケースに対して，関連する議論がないサブゴールの数を求める．そして，その数が全末端サブゴール数に占める割合を求め準備状況指数として評価に用いる．第3.2.1項で述べた照会業務を支援するAI実践システムの構築プロジェクトにおいてプロジェクト開始時までのディスカッションペーパーやそれを元に行った議論の内容を根拠として付与した保証ケースを図8に示す．本ケースでは，プロジェクトの準備状況として，議論不要のサブゴールは存在するが，すべての末端サブゴールについて必要な議論が行われていることが分かる．このケースでは準備状況指数は1.0となる．

　

5．AI実践プロジェクトの成功要因分析とプロジェクト管理への活用

5.1　AI実践プロジェクトにおける成功要因の同定

第4章で述べた分析手法を，すでに実施したAI実践プロジェクトに対して適用した．分析の流れと分析結果のイメージを図9に示す．

　

提案手法では図6の分解木に根拠を付与することで保証ケースを作成し，分析する．本手法を本格的に適用する場合，プロジェクトマネージャが，保証ケースを作成することになる．本分析では，プロジェクトマネージャへの手法の教育も兼ね，筆者らがプロジェクトマネージャとともに保証ケースを作成し，プロジェクトの導入準備状況を分析した．根拠の付与は，プロジェクト提案書と提案までに実施した事業部門と開発部門（ベンダ）の間の会議におけるディスカッションペーパーや議事録を元に行った．

作成されたプロジェクトの準備状況を表す保証ケースについて根拠の付与状況を分析した．このとき，11の末端のサブゴールに対して，議論を通してサブゴールを満たすことを確認したケースに○，議論はしたがサブゴールを満たすことを明確に確認していないケースに△，議論をせずサブゴールを満たしていることを確認していないケースに□を付与した．また，開発部門側で事業部門との議論は不要と判断したものは△とした．対象プロジェクトでは，開発部門側の品質管理チームによってプロジェクト提案書のレビューが行われおり，データの準備は誰がいつまでに行うのか，プロジェクトで目標とする指標の定義は何か，といったことは記載されていた．加えて，本分析では，提案書作成までの議論内容をもとに，それぞれの項目について，事業部門と合意形成がなされていたかどうかをプロジェクトマネージャと分析し保証ケースを作成した．

対象となるプロジェクトは以下の3種類からなる6プロジェクトである．

• 照会業務の支援や自動照会応答
• 新規販売先の候補抽出
• 文書の審査業務

照会業務とはコールセンタにおいて顧客や社員からの問合せに回答する業務である．プロジェクトでは第3.2.1項で述べたシステムを構築し，コールセンタの担当者を支援することや，専用端末を用いて問合せをする人が自身で回答を得ることを目指した．問合せ元が顧客か社員か，また照会する業務によって対象となる回答も，所管する事業部も異なる．本分析では，複数の事業部の照会応答業務に対して業務担当者支援や自動照会応答のシステムを開発したAI実践プロジェクトを対象とした．新規販売先の候補抽出では，金融機関の取引先企業の情報を入力とし，協業先の候補を見つけ提案するというものであり，企業分析の専門家の支援を行うシステムを構築するプロジェクトを実施した．審査業務の支援では，入力文書の内容を元に担当者が融資のように何らかの判定をする際に，システムが事前に判定結果を出すことで担当者の作業を短縮することを目指す．具体的なプロジェクトとして，第3.2.2項で述べた海外送金事務における仕向先判定支援システムの開発が該当する．これらのプロジェクトについて保証ケースを作成し，プロジェクト開始時の準備状況の分析を行った．機械学習技術を用いて，あらかじめ定義した選択肢の中から，入力に最も適したものを選び出力するAI実践システムの開発プロジェクトは，定義したゴール分解木を用いて保証ケースを作成することで，その準備状況をプロジェクト間で比較分析することが可能となる．

本分析において，対象プロジェクトはすでに実施済みであるため，各プロジェクトを，その状況を示す実績値（Status）に分類した．具体的には，プロジェクト実施期間中に特段の課題が発生せず，後続のプロジェクトが開始しているケース（Status=3）から，プロジェクト開始前の合意不足などに起因する課題がプロジェクト実施期間中に発生したケース（Status=1）までの3段階の状態を付与した．

以上から，根拠の付与状況を示す分析結果とプロジェクト実績値から根拠の付与とプロジェクトの実績の間に関連があるかどうかを，相関係数を求め調査した．プロジェクト実績と相関係数0.75以上の強い正の相関を持つサブゴールを表2に示す．

この結果から，分析知能をシステム化するAI実践プロジェクトにおいて，失敗を回避し成功に導くために有効な項目を優先して得ることができることが分かる．これらを成功要因としてまとめると以下のようになる．

• システムが選択して出力する各選択肢に対して十分な学習データを準備することができる（G_12）
• 出力が正確でない場合において，システムのユーザによる対応も含め，システム全体として対応できる（G_15）
• 選択肢となるデータが，機械処理が容易な形式で準備されている（G_8,9）
• 定義した選択肢に対して，網羅性を確認する準備ができている（G_10）

一方，プロジェクト実績と根拠の付与状況の間の相関が低いサブゴールは，機密性（G_5）と標準適合性（G_6）であった．これらは，表1にある通り従来のソフトウェアシステムの開発と同じ項目であり，また，金融機関におけるシステム開発ではプロジェクト開始にあたり検討が必須とされているためサブゴールとして意識するか否かの影響は小さいと考えられる．

5.2　分析結果のAI実践プロジェクト管理での活用

5.2.1　AI実践プロジェクトの導入準備評価

機械学習のような事前に定義した選択肢の中から最適なものを出力する技術をシステム化してオフィス業務に適用するAI実践プロジェクトにおいて，その成功要因を同定できることが，実施済みのプロジェクトへの提案手法の適用から分かった．これは，このようなAI実践プロジェクトを開始する際には，提案手法を用いて保証ケースを作成し，成功要因に関連した議論の有無を分析することで，プロジェクトの成功を予測できる可能性が高いことを示している．したがって，第4章で述べた分析手法を指標としてAI実践プロジェクトの導入準備評価を以下の手順で行うことができると考えられる．

• ① 第4章で定義したゴール分解木（図6）に対し，プロジェクト提案書に至るまでの議論内容を用いて保証ケースを作成する．
• ② 保証ケースの各末端サブゴールに対する根拠（議論や合意）の有無を確認する．
• ③ 根拠がないサブゴールについては，プロジェクトの成功要因と強い関連があるサブゴール（G_12，G_15，G_8，G_9，G_10）を再度議論し，根拠を付与して保証ケースを更新する．
• ④ 成功要因と関連が弱いその他のサブゴールについては，確認を行った後，議論不要の記法を用いて保証ケースを更新する．
• ⑤ すべての末端サブゴールに根拠または議論不要の終止記号が付与された保証ケースが得られた段階で導入準備評価を終了し，プロジェクトを開始する．

この評価手順を実施することで，プロジェクトの成功に不可欠な項目を確実に合意した上で，プロジェクトを開始することができるようになる．この手順ではゴール分解木のすべての末端サブゴールに対し議論の有無を調べ，保証ケースを作成する．これによって，プロジェクトの成否と関連が薄い項目についても「議論は不要と判断した」または「何も検討していない」のいずれの状態であるかをプロジェクト開始後に確認できる状態になる．これはプロジェクトの品質管理上，有効であると考えられる．

5.2.2　AI実践プロジェクトの性能評価指標

同定した成功要因の1つに「AIエンジンの出力が正確でない場合において，システム全体として対応できる」ことが挙げられている．この項目を満たすためには，システム内で用いられるAIエンジンを個別に評価するだけでなく，AIエンジンの外側で実装したロジックの性能を含んだ性能を，システムを利用するユーザの視点で評価する必要もある．そこでAI実践システムの評価指標として以下を考える[17]．

• モデル性能：機械学習アルゴリズムなどAI実践システムを構成する各エンジンの性能
• アプリケーション性能（アプリ性能）：AI実践システムの利用者視点での性能
• ビジネス性能：AI実践システムによるビジネス効果

モデル性能を測る指標は従来技術である適合率，再現率，F値となる．一方，アプリ性能やビジネス性能を測る指標はプロジェクトごとに定義する必要がある．また事業部門側が自身のビジネスの視点でアプリ性能やビジネス性能を理解できることが重要となる．

AI実践システムのオフィス業務への適用では，AI実践システムが業務全体を担うのではなく，業務の中の一部のタスクを担う．つまり，システムは前行程の作業者が行ったタスクの出力を入力とし，何らかの判断をして結果を出力する．その出力をもとに，次の工程の作業者は自身のタスクを行う．ここでAI実践システムの前後の行程を担う作業者は人間または別のシステムとなる．この利用シーンを図示すると，図10のようになる．

　

この利用シーンに基づき，AI実践システムのアプリ性能を示す指標を，

と定義することを考える．業務を遂行するには，業務を構成する各タスクが滞りなく実施される必要がある．そのため，AI実践システムの出力結果を用いてその次行程が遅延なく進むかどうかを評価する指標の定義は，対象業務にAI実践システムを用いることができるかどうかを評価する必要条件になっている．したがって，ゴール分解木のG_13サブゴール（AI実践システムの正確性の判定指標を共通理解する）が満たされていない場合は，この視点に基づきプロジェクト関係者で議論し，その結果を根拠とすることでサブゴールを達成することができる．また，利用者視点で評価指標を解釈でき，評価結果を使ってビジネス性能を容易に定義することが期待できる．これにより，開発部門と事業部門の双方がシステムの性能を理解しながらプロジェクトを進めることが可能となる．

6．考察

金融機関での実プロジェクトへの適用から，保証ケースを用いてプロジェクトの準備状況をモデル化した．そして，プロジェクトを失敗から回避し成功に導く項目を，プロジェクト担当者の経験の有無によらずに客観的に抽出できた．この結果から分析結果をもとに検討した導入準備評価指標は有効であると考えられる．

しかしながら，必ずしもプロジェクト開始時に十分に議論ができない項目もある．たとえば，「選択肢の網羅性を確認する手段について合意する（G_10）」について，「想定ユーザによるテスト利用を通してあらためて検討する」のように合意が保留となる場合がある．このような場合，プロジェクト開始後，適切なタイミングで再度議論を行う必要があるが，提案手法では保留やその場合の再検討のタイミングを明示化することができない．これは検討したプロジェクト導入準備評価の適用限界の1つとして考えられる.

また，AI実践システムの評価指標としてAIエンジン内のアルゴリズムの性能（モデル性能）だけでなく，利用者視点でシステムの性能を評価するアプリ性能の定義を導入した．これによって，プロジェクト開始時にシステムが目指す性能を事業部門と開発部門で共通理解するとともに，プロジェクトの進捗とともに得られるビジネスへの効果についての議論が容易となる．しかし，具体的なアプリ性能は対象業務に依存するため，その導出を容易に行う手法の考案が必要となる．これは今後の課題である．

7．まとめ

本稿では，金融機関におけるAI実践プロジェクトを分析し，プロジェクト管理へ活用できる知見を得ることを行った．AI技術を適用するプロジェクトでは学習データの準備や，必要となる出力の精度の決定や誤った出力への対応策の検討などに利用者側が大きくかかわる必要がある．そのため，開発部門と事業部門がそれぞれの作業の目的やその重要性を共通認識する必要があったが，プロジェクト推進者の経験に依存していた．この課題に対応すべく，保証ケースを用いてAI実践プロジェクトの準備状況をモデル化する手法を検討し，金融機関における実プロジェクトへ適用した．そして分析結果からプロジェクトの成功要因を同定するとともに，同定した成功要因からAI実践プロジェクトの導入準備状況の評価手順やプロジェクトにおける性能評価指標の定義を導出した．

AI実践プロジェクトをさまざまなオフィス業務に本格展開する上では事業部門の経営層も含め，プロジェクトの意義や実現効果を共通理解することが重要である．そのためにはさまざまな関係者がプロジェクト全体を概観できる手法の開発が必要であり，今後の課題となっている．