皆さんこんにちは!
こちらはABEJA Advent Calendar のクリスマスイブ(12/24)の記事です。
はじめに
私は、ABEJAでお客様へのAI導入のプロジェクトマネージャーを務めています@hjmです。
技術の記事が多い弊社Advent Calendarで、異色のビジネスベースの話をします。
私自身結構「技術」という言葉に思い入れがあって、アーキテクチャーやコード以外でも再現性がある・改題解決に繋がる整理と構造化が出来れば「技術」になり得ると思っています。なので、これまでの経験を少しまとめて見ようと思い投稿します。
あなたは誰?
前職ではコンサルティングファームで主に製造業を主戦場として生産機能とか資材購買機能などのコンサルティングを行っていました。
その中で、Tableauに触れたり、AIの検討に参加することにより、データの世界・それを高度に使いこなす世界を目指したくなりABEJAに入りました。
想定読者とお持ち帰りポイント
想定読者としては以下のような方を考えています。
- 機械学習とかAIに興味はあるが、実装関連は出来ない。
- 社内でちょっと詳しいと思われていて、色々相談に乗るけど自信が無い。
- AIプロジェクトに参画しそうだ、無茶振りされている、すでに苦しんでいる
そんな方々が、上司からAI導入やプロジェクトの登用を打診されたときに、生存するためのポイントを少し考えたいと思います。
- AI導入の要件定義を考える
- 実は要件よりも要求を明確にする
- 要求を明確にするための3つの小技
1.AIプロジェクトの要件定義を考える
はい、AIプロジェクトの最大の地雷ポイントです。システム開発ではもう数十年と言われていますが、何をどのように実現するか。という要件定義がとにかく大変になりがちです。
なぜ、AIプロジェクトの要件定義が大変かというと、AIを使う事が目的に来ているケースがとても多いからです。
システムやアプリでも要件定義が出来ないケースはありますが、AIになると殊更多い印象です。
最近はだいぶ世の中に事例が普及してきているとは思いますが以下のように考えている方は少なくありません。
- AIを使えば何でも解決出来る
- たくさんデータがあるから何か出来るだろう
- CEOから「AIでなにかやれ」と言われている
この3つに共通するのは、解決したい課題(What)の前に解決する手法(How)が先に来ていることです。これがAI導入の要件定義の最大の壁です。
そして何がやりたいか分からない中でプロジェクトが始まってしまい転けてしまう。
最近Twitterでも以下の投稿がバズっていて、まさにAIもこの通りだなと思います。
皆さんは要件定義をしたいのに要件の前段となる要求がないのです。
みなさん「会社の課題はなんだ?」
上層部「AIを使え、AIで何かやれ」
みなさん「それは要件だ!要求を言え」
上層部「・・・」
前職のコンサルタント、ABEJAのプロジェクトマネージャーとして、様々なプロジェクトに参画していますがデジタル系については特にこのパターンが無視出来ないほど多いと思います。
一方で、要求を明確にすることそのものが案外難しいのでは無いかとも最近思い始めています。
2.要求を理解する事は結構難しい。
5年くらい前でしょうか、忌み嫌われている日本人のシリコンバレーツアーに参加したときに講演してくださった方がこんなことを言っていました。
「人は自分が思っているほど自分が必要としているもの(つまり要求)が分からない」
その後にこんな事例も出されていたのが強く心に残っています。
- あるとき、新製品のマーケティングで料理好きを集めてどんなお皿がほしいかのヒアリングを行った
- どの料理好きも「最近の皿はみんな同じような形と色だ」「もっと違う物がほしい」「お皿=白のイメージが強いので反対の黒や他の色がもっとあってもいいのでは無いか」「丸皿以外の皿がほしい」という目新しい意見が出した
- 最後に企業から「本日はご協力ありがとうございます。最後に弊社の販売しているお皿の中から好きなお皿をお持ち帰りください」と言われると、みな白くて丸い皿を持って帰った。
この逸話から得られるのは、要求を理解する事は、誰かに尋ねれば良いという出来るとは限らない事です。
一方で、要求が無いと要件を決められない。この真の要求に迫っていくことが、AIプロジェクトの炎上させない一番のミソだと私は思います。
3.要求を明確にするための3つの小技
ここからは私が実際のプロジェクトでの体験や失敗から、ふわふわ要求をある程度固めていく小技を紹介したいと思います。書いていると別にAIでも何でも無い「問題解決技術」と言ってしまえばその通りですね。
①厳密に言葉で書いて、読んでみる。
何をどうしたいか。一度書き出してみてください。
ここでのポイントはPowerPointでチャートを書くようにふわっとオブジェクトを矢印でつないでなんとなくそれっぽい資料を作るのでは無く、テキストエディタ(メモ帳でも良い)でやりたいことを理路整然と文章で書いてください。
「不良削減をする為に、AIを使って効率化する」
例えば、こんな文章が最初に浮かんできたとしましょう。スタートとしてはいいですが、これで終わってはいけません。
まず、不良削減つまりWhatが出てきている理由を文字にしましょう。
製造業において不良が悪だ。といわれればその通りですが、不良削減するにも必ず理由があるはずです。
不良廃棄のコスト、不良検査員のコスト、クレーム対応、顧客のエンゲージメントなど一つに絞れないケースもありえますが、Whatが生まれてきているWhyをまず考えます。
不良検査員のコスト削減などはAIに置き換えれば削減出来るかもしれませんが、クレーム対応や顧客のエンゲージメントはどうでしょう。
その製品のダイレクトな不良によるクレームと他の要因のクレームがどれくらいの割合かもしくは影響しているか、気になりますよね。調べましょう。もしかしたらAIじゃなくてもいいかもしれません。
重要なことは、考えた内容が正解かではなく、多面的に考え・上層部含めたメンバーと共通認識を持つことです。
次にWhatの解像度を上げましょう。Whyを考えていくとすべての不良を検出出来ないと行けないと勘違いするのですが、それもまた難しいです。
重要なのは最後の姿(様々な不良を検出出来る)とそこまでのステップ(1st ステップでは重要な2つ、2ndステップでは次の5つ、最後に細かいもの含めて全部)を分けることです。
世の中ではスモールスタートとよく言いますが、着地点を見据えないスタートは無謀です。なので、最後の姿を書き出す必要があります。
またこのステップ分けも、適当に2:3:5などの配分で分けてはいけません。不良対象の類似性や頻度など判断する要素を理解し、Howとのすりあわせをしながら決めることが重要です。
最後に、「AIを使って」の部分をかみ砕きます。ここまでWhyとWhatが具体的に書きだして、初めてHowに入る事が出来ます。画像でやるのか、センサーデータでやるのか、その組み合わせなのかを書き出していきます。
この段階くらいからデータサイエンティストから使えそうなモデルやデータ量などより専門的なアドバイスをもらうと、Howが深まっていきます。。
データサイエンティストとしてもWhyとWhatが腹落ちして初めてどのようなモデルが使えそうかの正しい判断が出来るので、このHowを検討する前段階まではAIに関係なく問題解決の技術を持って立ち向かうべきです。
近年、課題整理をデータサイエンティストの方々がやっているケースを多く目にします。
私の持論としてはビジネスサイドが徹底的にやるべきだと思います。むしろデータサイエンティストは出てきた課題に対して、アルゴリズムの力を使って解決するという役割分担の方が良いと思っています。
②触る、撮る、見る、体験する
一つ目では、要求の設定の第一歩として徹底的な書き出しを上げました。小技の二つ目は、事実を掴む事です。
テーブルデータ、画像データ、音声データ、何を使おうと実際にそのデータができあがる現場を見に行く(もしくは実験する)ことと、その結果できあがったデータを咀嚼することは重要です。
私もいつも陥りがちなのですが、PowerPoint上でのなんとなく出来そう感が出てきた時が一番の危険信号です。
すでにデータがある場合でも、これからデータ作成する場合でもデータが作られていく過程の体験には気づきがたくさんあります。
撮像環境の問題に気づけたり、実際にスマホなどでサンプル撮影してみたら想像していた絵が撮れない、データのノイズとなる事象がある、など気づくためには現場を見て体験するのがもっとも効率的かつ効果的です。
また撮影したデータを見る・聞く・簡単に集計することも必須です。
画像や音声の場合、正解ラベルと不正解ラベルに分けて確認する。テーブルデータの場合は簡易なEDAを自ら行う事が大切です。
ケースにもよりますが、これらはPythonのスキルが無くても、PCについている標準のビューワーとExcelでも可能です。大事なことは、高度な分析をするのではなくデータの構造や傾向を掴むことです。
正解ラベルと不正解ラベルの割合、不正解ラベルの具体的な内容、テーブルデータの件数や平均値など、必ず自分でやってみることが重要です。
私の体験にも、PowerPointで使っている写真が頭にすり込まれてしまい無意識的にすべてのデータが同じようなレベルで撮影できると誤認してしまったことがあります。
実際にデータを撮影してみるとイメージに似ているが考慮できていない事象(オクルージョンやノイズ)が露見し、撮影方向の修正。
さらにはモデルを変更したり追加で前処理をするなど、ある程度避けられるはずの手戻りが発生しました。
今思えば、一度状況を再現して撮影してみるステップを挟んでいれば、もう少しヘルシーにプロジェクトを進められたと思って反省しています。
③示唆を生みながら、再考する
最後は、小さいことで良いので結論や示唆を考えながら再考することです。
要求を明らかにすることと離れているように感じる方もいると思いますが、これまでの経験上要求がある瞬間にカッチリと決まるケースは稀だと感じています。
定義が曖昧な言葉ですが、アジャイル的に進めていく事が、上層部やお客様の要求を明確にしていくことに効果的です。
正直、AIのプロジェクトは他のプロジェクトに比べると失敗率がかなり高い感覚です。PoC後に実装まで行くケースは5-10%が良いところかと思います。
私個人としては成功を狙って関与することは当たり前なのですが、成功と同じくらいプロジェクトメンバーや会社に示唆を残すことを意識しています。
AIプロジェクトで一番避けなければいけないのは、「なんだかよく分からないけど、ダメだった」ということです。
- 出来たこと分かった事、
- 難しかったけど出来たことと改善要素
- 出来なかったこととその理由
など、次のプロジェクトや活動への示唆をどれだけ持てるかがAIプロジェクトもしくはプロジェクトマネージャーの生命線だとも思っています。
#まとめ
話をまとめると、以下の3点が今回伝えたかったことです。
- 要件を決める前に要求をいかに咀嚼するかが大事
- とは言っても要求はぱっと分かるものでは無い
- 要求を明らかにしながら進めていく事とサバイブしやすい
書いてみるととっても当たり前なことに着地してしまいました。
しかし、クライアントワークに関わって10年以上になりますが、原理原則はさほど変わらないようにも思えます。
今、もしくはこれからAIプロジェクトに臨まれる方がサバイブすることに少しでも参考になれば嬉しいです。
最後に：ABEJA awaits your joining!
現在ABEJAでは一緒にAIの社会実装を進める仲間を募集しています。
私の様にデータサイエンティストやエンジニア以外でも活躍できる会社です。
ABEJA Advent Calendar 2021 を読んで少しでもいいねとおもったら、まずはお話を聞きに来てください。
【募集職種一覧はこちら！】 はこちらから確認できます。ご応募をお待ちしております