最終更新日：
ラスベガスで CES（Consumer Electronics Show）が開催された。消費者向けの電子製品をあつかっている見本市である。2018年はこれまで縁がなかった企業が参入したと聞く。TOYOTA は自動運転、Google はスマートスピーカー、ある保険会社は居住地診断アプリと住宅修繕診断アプリを展示した。いずれもAIやデータサイエンスの知見をプロダクトに落とし込んだ好例であろう。
AI を活用したこのようなプロダクトを作れる企業がある一方で、プロジェクトが遅々として進まない企業がある。何人かのAIエンジニアやマネージャーにヒアリングしたり、飲みながら話を聞くと、「一部の成功企業とその他の企業で二極化している」と言う。これは B2C企業 だけでなくB2B企業 も同様である。テクノロジーの進化がこれまでのビジネスの思考パターンにそぐわなくなっているためである。私はその外観を「テクノロジーの進化とビジネスの常識」にまとめ、寄稿した。
外観はわかってもビジネスは現場で起きている。事業会社につとめる AI プロジェクトの責任者は、AI スタートアップに会い、提案を受け、「やってみないとわかりません」とよく言われる。これでは上長に説明しづらい。企業のトップはステークホルダーに対して説明責任があり、これは企業の隅々まで同様である。企業において説明できない者は責任がないことにひとしい。かくして事業会社のAI プロジェクトの責任者は「やってみないとわかりません」と説明責任の間で板挟みになる。AI プロジェクトの責任者は、自分の身を守るためにも、不確実性を説明するプロジェクトマネジメントを行わなくてはならない。
この記事では、説明可能な AI のプロジェクト管理について述べたい。とくにPoC フェーズにおいて、検証すべき課題の見立て、追加、消化を管理することを提案する。まずはAI 開発の特徴から始め、ビジネス要求の整理、プロジェクト管理へと論を進める。くわえて、今後顕在化する実運用の課題についても述べる。
AI 開発の特徴
プロジェクト管理について考える前に、AI開発の特性を考えてみたい。人によって様々な論点があろうが、ここでは産業を分類する手法を使う。「不確実性のマネジメント」から製品の複雑さ（製品構造複雑性）と市場ニーズの曖昧さ（市場ニーズ多義性）を軸にする分類方法で考察する。
一般に製品は部品の数とその組合せが増えると複雑になる。たとえば、OS は小さな部品の組合せから構成される。一つ一つのコマンドやモジュールは比較的シンプルな構造であるが、それが多数組み合わさった OS は複雑性が高い。医薬品は製品の構造はシンプルである。しかしながら効果のある成分を作り出すことが難しく、課題の難易度が高い。
他方で産業によっては市場のニーズが曖昧で特定しづらいことがある。服や化粧品は訴求するポイントが個人ごとに異なり、ニーズの特定が曖昧で難しいといえる。医薬品は特定の症状に効くか否かが重要で、ニーズの曖昧さは比較的低いといえる。
図.1 製品の複雑さとニーズの多様性による分類 （不確実性のマネジメント p.190の図を改変）
さて、AI 開発はどこに分類されるか。実現可能性を検証するフェーズ（以下、PoC フェーズ）とプロダクトに組み込むフェーズ（開発フェーズ）によって位置づけが異なる。PoC フェーズではコアとなる技術を特定し、その実現の可能性を検証する。このフェーズでは課題の難易度は明確化されておらず、探索的なプロジェクトになる。課題と仮説のスジ、アサインされる担当者の実力が鍵になることが多い。PoC フェーズはエンジニア主導の少数精鋭開発となる。
さて、開発フェーズはソフトウェアへの組み込みを前提にしたが、自動運転になると様相が異なる。課題の難易度が高く、製品の複雑なことに加え、市場ニーズが一意ではなく曖昧なためである。具体的に言うと、ハイエンド層は一般と違うことを求めるためにニーズが曖昧であり、シェアリングエコノミーはコスト最適を求めるために一様になり始めているように見受けられる。
余談であるが、Google の自動運転に対する批判として、車という製品の複雑さやリアルな製品の難しさをあげることが多いが、市場ニーズの曖昧さをあげている議論は少ない。Googleが自動運転を製品化したときにはシェアリングエコノミーをターゲットとし、ハイエンド層にはアプローチしないかもしれない。またTOYOTAはモビリティ・プラットフォームを立ち上げたことでシェアリングエコノミーと自動運転のトレンドに対応した。他方で、市場ニーズの曖昧さに対する知見を活かすために、ハイエンド層も別ラインで保持し続けるだろう。
ビジネス要求と課題の見立て
PoC フェーズはニーズが具体化され、技術で解決する課題が明確になっていることを前提とする。したがってPoCフェーズに入る前に、ビジネスの課題をブレイクダウンして技術を適用できる粒度まで具体化しなくてはならない。その粒度はインプットとアウトプットがある程度明確になっていることである。その品質要求が明確になっていることが望ましい。
そうするとビジネス課題に適用できそうなアルゴリズムの候補が、いくつか列挙できる。アルゴリズムの知見にはいくつかのレベルがある。論文で公開されているだけか、論文の実装が公開されているか、他社で実例があるか、他PJで実装した例があるか、などである。つづいて製品化する上で懸念される事項をあげる。画像を利用するのであれば、その数がどの程度必要か、画像の質が揃っているか、屋外か室内か、悪天候や夜間でも使用するか、などがある。これらの懸念事項は明確にすべき課題であり、その課題を技術的にクリアできるか明確にするため にPoC プロジェクトをおこなう。課題には技術的なものだけでなく、ビジネス課題が複雑に入り組んでしまうことがある。たとえば需要予測システムなどは、開放系であるがゆえに予測精度があがらないことがあり、業務プロセスで運用カバーしなければならないことがある。事前にステークホルダーと合意をとっておくことが、プロジェクト管理として重要になる。
課題には取り組む順序がある。手法はいくつかあるが、ここでは制約理論の思考プロセスにある、移行ツリーを紹介したい。中間目標と障害、アクションを洗い出す方法である。手順は以下のとおり。
- 初期の状態と最終目標をおく
- 中間目標をおき、矢印でつなぐ
- 二つの中間目標の間に発生しうる障害を書き出す
- これを繰り返して修正していく
- 書き出した障害を解決するアクションを追記する
中間目標と障害が複雑で、全体観を把握したい場合に有用なことが多い。初期の状態に近い位置にあるアクションから取り組んでいくことになる。
課題ベースのプロジェクト管理
プロジェクトはQCDS（Quality: 品質, Cost: コスト, Delivery: 納期, Scope: スコープ）のバランスをとることがキモである。通常のIT開発であれば品質とコストが決まっていて、納期とスコープを調整することになる。要は QC を固定して DS を調整することになる。もっともプロジェクトの後半になって見通しの甘さが発覚し、納期を遅らせることができなくなり、スコープを調整することになることもある。要は QCD を固定して S を調整することになる。
PoC フェーズは固定するパラメータが異なる。プロジェクトが探索的であるがために、イテレーションする前提で期間とコストを固定する。期間内に検証する課題のスコープを決め、どの程度まで品質を作り込めるか検証していく。要は CDS を固定して Q を作り込んでいくことになる。AIに限らずよくあることだが、発注者や営業はS（スコープ）を広げようとする。交渉でスコープを広げられるものと考える。しかしながらほとんどの場合で誤りである。結果的に求めたQ（品質）に到達しない。事前に関係者に説明していた期待値を満たせず、自らの信頼を貶めることになる。
データ解析では CRISP-DM というプロセスが受け入れられている。以下の６つの要素からなり、繰り返し改善していくことを前提にする。
- Business Understanding
- Data Understanding（生データの理解）
- Data Preparation（データのクレンジング）
- Modeling（AIのアルゴリズム適用はココ）
- Evaluation
- Deployment
いくつも難しい箇所があるが、もっとも難しい箇所はビジネス理解とデータの理解にあると思う。ミクロな視点とマクロな視点の両方でタスクに取り組むためである。
課題を検証するために①から⑤を繰り返す。イテレーションの中で課題を解消していくが、あらたな課題が発生することもよくある。一般にイノベーションのプロセスにおいては、初期は次々に課題が発生し、もっとも苦しい頃に課題が減少し始め、あるところで課題が収束し、ようやくビジネスがまわり始める。この課題は適切な粒度で管理されねばならない。粗すぎればいつまでも収束しないし、細かすぎれば杞憂になる。この課題の発生と収束の傾向をプロジェクトの KPI として見ていくことが良いだろう。
開発フェーズでは確実に動く製品をつくることが求められる。一般的な IT 開発と同じ管理でよいが、PoC フェーズから開発フェーズへ移行する際には様々なレビューや受け入れチェックが必要になるだろう。
運用フェーズ
開発が終了すると、本番環境に Deploy される。運用の開始である。事業会社としては投資からキャッシュを回収するフェーズに移り変わる。しかし現実はいつも簡単ではない。PoC で使用したデータとは傾向が変わることがある。精度は徐々に下がり始め、あるときにモデルが役に立たなくなることがある。バッチを実行して再学習すれば改善するかもしれない。恐ろしいのは、原因がわからず説明できないことである。無策のまま時間が経過することである。
こういった問題は基本的に事後対応になり、スピード感が求められる。PoC を担当した者がいれば解決できる可能性があるだろう。しかしながら優秀な AI エンジニアが引き抜かれていく市場状況では、経営者が金銭以上の価値を提供できるかが重要である。知識マネジメントを適切に行っていれば引き継いだ者が対応できるかもしれない。いずれにせよ運用フェーズでは、AIを開発した企業経営者のマネジメントの質が問われることになる。発注する側は運用も見越して考える必要があるだろう。
最後に
本稿ではAIのプロジェクト管理について留意すべきことを書いた。しかしながら私は本稿を「AIプロジェクト管理の教科書」とする気はない。プロジェクト管理ではPMの性格が出てくるものである。あなたの得意とするところ、価値ありとするところに応じて、おいしいところをつまみ食いすればよいと思っている。あなたの仕事が建設的なものになることを願いつつ、ここに筆を置く。
