読めばこれまでより少しだけやりたくなる。プロジェクトマネージャーのやりがいとは。

  • 同じPJのプロジェクトマネージャー(PM)を見ていてつらそうだなー
  • キャリアパスとしてPMはなしだなーと思っている
  • PMなったら給料たかそうだけどつらそー
  • PMっておもろいの?っていう就活中の学生さん

現役PMがそう感じているみなさんにPMの辛さ、やりがい、キャリアの可能性を伝えます。

読んだ後には、きっとちょっといいかもと思います!

ポジショントークは少しあるかもですが客観的に見たつもりです。
ちなみに、私は以下のような経験があります。

  • 8PJのPM
  • PM歴3年

このように経験が豊富というわけではありませんが、PM初心者の方には少しは参考になると思います。ちなみに最近ではこちらのPMをやっていました。

私が言うPMはいわゆる管理だけをする人ではなく、プロダクトマネージャーにも近いです。なのでその前提で読んでもらえると嬉しいです。

プロジェクトマネージャーはやっぱつらい?

Photo by Martin Péchy on Unsplash

正直つらいことは多いです。笑
お客様からの目線や社内からの目線を痛いほど感じるからです。

お客様からの目線

おそらく大抵のお客様は対峙する営業さん以上にPMに「お前頼むぞ。」と思っていらっしゃると思います。

結局PMがほぼ最終意思決定をして、PJを進めているので、PMがイマイチならPJもイマイチな感じになる可能性が高まります。

なので、お客様はPMの一つ一つのメール、会話、報告からPJ状況を推察したり信頼できる人かを見定めているように感じます。お客様と対峙する人は全てそうかもしれませんが。

社内からの目線

PJの成果はお客様からの会社の信頼に直結するものです。

また、社内メンバーの数名、数十名を稼働させているPJでもあるので、収益にも大きな影響を与えるものでもあります。なのでPJ規模にもよるものの、社内からはPJの行く末についてはかなり熱視線を感じます。

遅れたり、問題が発生した際は、どうすんの?次の打ち手は?お客様の反応は?お客様の期待通りに終わらせられるんだよね?と聞かれます。なので常に説明のつく対応や行動が必要となってきます。そこでロジックが通っていないと質問攻めにあいます。笑

これまでの内容を読んで、うわ〜やっぱやりたくね〜と思ったかもしれません。ちょっと待ってください。もちろんその分やりがいもあります。

プロジェクトマネージャーのやりがいは?

お客さんから褒められて、それをPJメンバーや他の同僚が喜んでいる姿を見た時、諦めずやってきて良かった~とやりがいを感じます。

PJの全責任を負っているので、当然ですが、メンバー以上に結果にコミットしたい想いが強いです。

なので、メンバーにはなぜそこまで無謀なことに挑むのだろうと思われてしまうことも多々あります。そこを奮い立たせるのがPMの仕事でもあるものの、そういう想いの違いが孤独の原因となります。

その意識の違いを理解してもらうたった一つの方法が顧客から喜ばれる結果を出すことだけなのです。

だからこそお客さんに喜んで貰えた時にやって良かった、、やってきたことが実った。。と感じるのです。

え、やりがいを感じるのはサービスをリリースした後じゃないの?

と思うかもしれません。

確かにtoC向けサービスであればそうかもしれませんが、toB向けサービスの場合、よっぽど良いor悪いサービスでないとユーザーからの反響を聞くことが残念ながら少ないです。

評価という意味では、サービス納品先の担当者からのコメントをいただくくらいです。私はtoC向けサービスの経験がないので、私が感じる一番のやりがいはメンバーの喜んでいる表情を見た時です。

反響が少ないならやりがいにはあまりならないな〜と感じる人もいるかもしれません。しかし、toC向けサービスの場合はきっと直接的な表現で評価をされるので、逆に辛くなることもあるかもしれません。

toB向けのサービスは反応は少ないものの、良いコメントをいただいたときはとても嬉しいです。

ここまで読んでいただいて、少しPMに興味を持った人もいるのではないでしょうか?

私はもっとPMになりたい、目指したいという人がいてもいいのではと思っています。そう思う理由をここから書いていきます。

これからプロジェクトマネージャーのニーズはもっと高まるのでは

Gerd AltmannによるPixabayからの画像

完全自論ですが、きっとニーズが高まっていくと思っています。
そう思う理由は3つあります。

  1. エンジニアリングはno code化(自動化)が進んでいる
  2. 営業はモノを売る仕事ではなくなってきている
  3. 複数分野の強みがある人が求められている

エンジニアリングはno code化(自動化)が進んでいる

「ノーコード/no code」というワードを最近よく聞くかもしれません。近年コードを書かなくても(ノーコードで)アプリを作れたり、ソフトウェアを開発することが出来るようになっています。この流れは以前からあり、今後も加速していくでしょう。

この流れが加速すると、エンジニアが居なくても簡単なアプリやサービスを作ることが可能です。

少し話がそれますが、今後全くコードを書かなくて良くなるとは思いません。ただ、エンジニアにはこれまで以上にある分野に特化した技術力が求められていくでしょう。

先述の通り、簡単に作ることが出来るということは、お客様のビジネスの真の課題が何か、解決方法は何かをいかに早く見つけるかが大事になってきます。

真の課題を見つけるには、お客様のビジネスを理解することと、お客様やユーザからヒアリングで課題を見つけ出すという大きく2つの要素が必要になってきます。これはPMが普段やっていることに非常に近いので、得意分野と言えます。
また解決方法は何かを見つけることも、普段要件定義書に落としこんでいることが正にそれなので、PMの得意分野と言えます。

営業はモノを売る仕事ではなくなってきている

随分前から営業さんの仕事はモノを売るのではなく、解決策を売ることがメインになってきています。むしろ最近は解決策しか売ってないと思います。

解決策にはおおざっぱに

  • お客様の課題が何か
  • その課題を解決するための方法は何か
  • その方法を実現するのにどれくらいのお金がかかるのか
  • この解決策(方法)を実現することでどれくらいの効果が見込まれるのか(これは営業さんが考える場合が多いかもしれません)

といった要素が必要になってきます。

これらの要素はほぼ全てPMが普段常に考えていることです。つまり、PMの業務範囲が営業にまで及び始めていると言えるでしょう。

逆に言うと営業さんにもPM要素(上記4つを考えること)というものが求められていくのではと思っています。いづれにせよPM要素というものが今後より必要になってくると考えています。

複数分野の強みがある人が求められている

これは少しソフトウェア、アプリ開発とは逸れた話にはなります。最近「キャリアの掛け算」、「強みの掛け合わせ」が希少価値の高い人材の条件と言われています。

PMは複数分野の強みがないとこなせない仕事であり、それがあるからこそなれる職種でもあります。なので、PMというだけで複数分野の強みがあることが認められているとも言えると思っています。

以上から、転職するときにもPMという経験はきっと有利に働くと思っています。

まとめ

PMの辛いことややりがい、可能性について書いてきました。以下にまとめます。

  • 辛いと感じるのはお客様や社内からの目線が痛いから。
  • やりがいはお客様からの良い反応を見て喜ぶメンバーを見たときに感じる。
  • PMは以下3つの理由からニーズが高まっていくのでは?と思われる。
  1. エンジニアリングはno code化(自動化)が進んでいる
  2. 営業はモノを売る仕事ではなくなってきている
  3. 複数分野の強みがある人が求められている

興味を持ったけど、PMになるチャンスなんてないよーって方はこちらの記事も読んでみてください。
私がPMになったきっかけや、そこから考えるなり方を説明しています。そちらもぜひ読んでみてください。

プロジェクトマネージャーとは?現役PMが教えるPMの全体像

PM
  • どんな仕事だろう。。
  • 自分に合っているのか?
  • なれるのか?なるためには?
  • 楽しいのか?
  • PMになって給与上げたい

そういう疑問に答えます。この記事を読んでいただくと、PMとはどういうものかが分かります。具体的には向いている人、やりがい、辛いこと、年収、なるためにすべきことです。

私はこれまで

  • 8PJのPM
  • PM歴3年

といった経験があります。このように経験が豊富というわけではありませんが、PM初心者の方には少しは参考になると思います。

私自身15名以下のPJしか経験していないので、その前提で話します。ただ、いきなり数十名のPJをやるということはないと思うので、まずは小規模PJのPMってどんなことをするのかが分かれば十分と思います。

PMの仕事とは

プロジェクトマネージャー(PM)はいわゆるQ(Quality)C(Cost)D(Delivery)の3つの全責任を負う人です。

もう少し具体的に言うと、PMは要件を満たしたソフトウェアを予定していた予算内で納期までに納めることの責任を負います。

PMの業務内容の詳細については本記事のメインではないので詳細が整理されている記事を探しました。しかし、無さそうなので、全体像をざっくり紹介している下記を参照いただければと思います。

「プロジェクトマネージャーとは?仕事内容・スキル・年収・将来性」
〜プロジェクトマネージャーの仕事内容〜

PMに向いている人

周囲の15名以上のPMをみてきた中でお客様から信頼が厚いな、喜んでもらえているなと感じる人たちに共通するのは、

  • 違いに対して敏感
  • 常に悲観的
  • 課題があるほど楽しめる
  • どんな時でも顧客想い

であるということです。それぞれ説明します。

違いに対して敏感

違いが何かというと、例えばあるメンバーからの報告時の表情が少しいつもと違う(報告は問題なく進んでいるという報告)、採用する技術がこれまでと少し違う、お客様のメールの口調が少し違う、結果が微妙に違う、というようにあらゆる”違い”を意味しています。

お客様からの評価が高いPMはこういう”違い”にすごく敏感で違う理由を確かめています。なぜならこの違いこそがトラブルの予兆になりうるからです。

どんな問題も突如前触れもなく起きることはありません。必ずある良い状態から悪い状態に変化していっています。

過去にあったのは、各チームリーダーが集まる進捗報告にて、ある新人チームリーダーが毎週順調に進んでいると報告していたのに、実際は報告がほぼ嘘だったということです。

結果、そのチームの進捗巻き返しに他チームメンバー総動員という結果となってしまいました。。

これは新人だから予定通りに行かないというのが”平常”で常に順調という報告が平常との”違い”になります。

なので、予兆となる”違い”を見つけることが大切なのです。

常に悲観的

どんなPJでも当初計画通りにいくことはありません。

考慮漏れが原因のバグが見つかり修正に時間がかかる、キーマンが体調を崩す、予定していた人をアサイン出来ない、などなどいろいろな問題が発生するのがプロジェクトというものです。

それを想定外としてしまうと毎度想定外が発生するたびに対応に時間が取られることにより更に計画通りに進めることが難しくなります。計画通りに進めるためには、どれだけ想定外を無くすかが大事です。

悲観的な人ほどいろいろと思考を巡らせて発生しうる課題とそれに対する対応案を考えるので、想定外を無くすことが出来るのです。

課題があるほど楽しめる

なぜこれが共通している、つまり大事かというと、どんなPJも課題・壁だらけだからです。うまくいきそうなPJも、どれだけ上述のように悲観的に考え対策を取ったとしても、どこかで課題が発生するものです。

よくあるのは、他のPJも始まり人が足りない、想定以上の工数がかかる、要件が大きく変わってしまい手戻りが生じるなどなどです。

でもこういう課題を楽しみながら解決策を考えられる人は最終的にお客さんの期待を超えていき、満足してもらっているように感じます。

課題ばかり発生するのにそれを解決するのが苦しくて仕方ない人はやっていけないですよね。結局は課題があるほど楽しめる、つまりドMな人が合っていると思います。笑

どんな時でも顧客想い

これが一番大事だと思います。結局評価するのはPJメンバーでも上司でも社長でもなく、顧客です。

ここがぶれて社内にベクトルが向いてしまうと、顧客に喜んで貰えなくなります。ただ、PMをやっていて感じるのは、これを貫き通すことは意外と難しいです。PMが妥協した瞬間にそのPJのクオリティは落ちてしまいます。

しかし、PJメンバーの働きぶりをみたり、社内でのそのPJの位置付けが低かったりすると、その優先順位がくずれてしまいそうになります。

例えば、納期がギリギリでやることが多い中、テスト結果の確認やドキュメント品質をあげるといった品質に関わる部分は、メンバーからすると手を抜きたくなる気持ちが芽生えてしまいます。ものがあれば終わったことにはなるからです。

ただこれを顧客ファーストで考えられているPMであれば、そのメンバーの気持ちは一旦無視し、品質にもこだわったものに仕上げてきます。

QCDの中でQは見えづらいときがあるので、どうしても手を抜きたくなってしまう気持ちがあります。

そこも最後まで拘ることがいつかは顧客にも伝わるのです。

PMの辛い面

hmmm

過去の自分の意思決定を自分で疑ってしまう時です。

PMとしてPJの中で色々な意思決定をします。その中で最良と思える判断でないことが時折あります。

それを後から気付き、取り返しがつかないくらい悪影響が出てしまっているときにめちゃくちゃ辛って感じます。。

例えば、PJメンバを増員すべきと思っていたものの、甘い見通しが原因で増員しなかった結果、遅延してしまったようなケースです。こういうときめちゃくちゃ後悔します。

というのもPMの判断ミスは影響範囲が大きいからです。

PJメンバー全員のワークロードやひどいときは他PJから応援を貰う必要があるので他PJにも影響が出ます。

PMのやりがい

自分がPMを担当したシステムがお客様やエンドユーザに喜んでいただけた結果、PJメンバーが喜んでいる姿を見た時です。

お客様やエンドユーザから良いフィードバックをいただいた時はもちろん嬉しいです。それ以上に私は一緒にPJを進めてきた仲間がそれら良いフィードバックをみて喜んでいる姿を見るとPMとしてのやりがいを感じます。

なぜなら、QCDを守るためPJメンバーに無理をお願いすることがたくさんあるからです。そのお願いに応えてくれたPJメンバーの努力が本当に報われるのが納品した時ではなく、お客様とエンドユーザからの良いフィードバックを貰えた時なのです。

なのでPJメンバーの喜んでいる姿を見ると、みんなに無理を言ってきたけどその努力が報われてよかった..と感じます。

PMになると給与はあがるのか

IT関連職種のなかではかなり平均給与は高いと思われます。

以下のレバテックフリーランスの記事によるとコンサルタントの次に高いです。なので、コンサルタント以外の方はPMになることで給与を高めることは出来るでしょう。

salary
2017年 経済産業省による調査結果

こんなに給与高いならPMなりたいな~と思った方もいるでしょう。

しかし、TECH:CAMPのように体系的に教えてくれるところは私が知る限りなく、会社の中でPMに関連する研修はとても少ないと思います。

また、PMに関する資格はあるものの、実務経験がないと取得することはかなり難しいです。以下の記事でも同様のことが書かれています。

「プロジェクトマネージャーとは?仕事内容・スキル・年収・将来性」
〜プロジェクトマネージャーになるには〜

PMになるには?なんでもいいからリーダー経験をつめ

leader

あくまで私の経験をベースにお伝えします。

私は元々メーカー系Sierで銀行向けシステム開発を行っていました。やっていたのはプロジェクトリーダーとプログラマーです。

そこから転職し、今はAIベンチャーでPMをやっています。なぜAIベンチャーのPM職として入社出来たかというと、以下の点を評価してくれたのではないかと思います。

  • IT、AIに関する素養
  • 顧客との折衝経験
  • リーダー経験

もちろん他にもいろいろと今の会社で求められることはあります。ただ、PM職をやるにはこの当たりが必要だと判断しているでしょう。

ちなみに私がPM職の面接をするときにもこういう観点は必ず確認します。おそらくこれらの上2つは既に持っている人が多いのではないでしょうか。

しかし、3つ目のリーダー経験は職種やポジションによっては中々得られるものでは無いと思います。

なので私がお勧めするPMヘの第1歩はなんでもいいからリーダー経験を積める機会を掴め!ということです。

例えば、飲み会幹事を進んでやる、モジュール開発を数人でやる場合はそのチームのリーダに立候補してみる、社外でのイベントを企画してその責任者をやる、研修のグループワークでリーダをやる等です。

こういう機会でリーダーシップを発揮すると、周囲にリーダーが出来る人という認識が広まり、社内でも次第にリーダーになる機会を得られるようになっていきます。

そうすると、プロジェクトリーダーになれる可能性が高まり、PMへの道が見えてきます。

そんな機会ないんだけどという人でも、自分がリーダーだったらどうするかを考えた結果をリーダーに常に伝えていけば、そのうちリーダーに任命されるでしょう。

まとめ

PMの全体像となるためにはどういう行動が必要かというテーマで書いてきました。これまでの内容を一気にまとめます!

  • PMとは、QCDすべてに責任を負う人
  • PMに向いている人は、①違いに対して敏感②常に悲観的に考えられる③思考を止めない④どんな時でも顧客想い という考え方を持つ人
  • PMの辛いこととは、過去の自分の意思決定を自分で疑ってしまうこと
  • PMのやりがいとは、お客様やエンドユーザに喜んで貰えたことによりPJメンバーが喜んでいること
  • PMになると、給料は多くの場合上がりそう。
  • PMになるには、なんでもいいからリーダー経験を積もう

最後まで読んでいただきありがとうございました!自分はこうしているという意見やコメントありましたら書いていただけますと絶対にSNSフォローさせていただきます!

ビジネスにも通ずるスポーツで結果を出すたった1つの考え方

win
  • 結果が出ない
  • 努力しているのに成果につながらない
  • 周囲からも不思議がられるくらい上手なのに成績は大したことない

こういうこと感じていませんか?私もモーグルを競技としてやっていた時、よく感じていました。しかし、本記事の考え方をしたことでこれまでにない成果をあげることが出来ました。この考え方はビジネスでも似ていると思いますので、今スポーツ選手じゃない方もぜひ最後まで読んでいただけると嬉しいです。


私は元々鳴かず飛ばずのモーグル選手でした。
モーグルとは?と思う方はこちらをご覧ください。
しかし、目標設定方法とそこまでの到達方法を変えることにより、全日本で入賞することができました。嘘だろと思う方のためにリザルトのリンク(2013年の6位が筆者)を掲載しておきます。

2013年以前は全日本で決勝に残ったことはありませんでした。元々実力的には入賞出来る可能性があったかもしれませんが、一度も決勝に残っていないことは事実です。

いかに目標までの道のりをリアルにイメージ出来るか

station

結論、いかに目標が具体的でそこまでの道のり(マイルストーン)を描けているかが大事です。これが出来ていれば1試合1試合の目標成績や年間の目標(日本総合ランキングで何番になるとか)が明確になります。

それにより、今の自分の実力と目標との差が明確になるので強化すべき点や伸ばすべき点が明らかになります。

実は私はこのような考え方をしていませんでした。これまではどんな試合でも今の実力の100%を出すべきだと考えていました。それで結果が付いてこないならそれが自分の実力なんだというような考え方でした。

そのため、100%を出さなくて良い試合でも100%を出していたが故に失敗することが多かったのです。その結果、大きな成果をあげることができないまま、自分が決めていた引退の歳が見えてきました。最後には成績を出したいという思いで考え方を変えたのです。

これまでの常に100%を出すという考え方を変えて、自分の目標を具体的に設定し、それを達成するためには何をすべきかを整理しました。

まず目標は2013年の全日本で表彰台。に立つということです。何をすべきかについては、目標を達成するために必要な点数(モーグルは採点競技)を過去の試合から推測。そして自分の実力からどういう滑りをすればその点数が高い確率で出るか(守りの滑りでよいのか、攻めた滑りがよいのかなど)を決めました。

その結果、2013年の全日本で表彰台という目標は達成できませんでしたが、入賞することは出来ました。これまでと比べて大きな進歩となりました。

目標までの道のり立てるなんて当たり前と思われるかもしれません。しかし、意外と出来ている選手は少ないです。私がライバルとして戦ってきた周囲の選手の中にもゴールから逆算して毎試合の目標成績や練習計画を立てている選手はいませんでした。

逆にこれが出来ている選手だけが世界の大舞台で活躍(W杯出場)していると感じました。

世界の大舞台で活躍する選手になるために、いかに目標を具体的に設定し、そこまでの道のりを描くかが重要だと思います。

美学にこだわりすぎていた過去の自分

じゃあなぜ過去の自分は成績を出したいと思いながらもそれが出来ていなかったのか。

なぜ目標を立てて、そこまでの道のりを描くということをしていなかったのか。

一言で言うと美学にこだわりすぎていたからだと思います。

以前は強い選手はどんな試合でも圧倒的な強さで勝ち、成績にこだわるのではなく自分と勝負するものだという美学がありました。この美学を意識した結果、毎回100%の滑りをしようとすることから失敗をしてしまう回数が増え、先述のように何も成績を残していない選手になってしまっているということに気づきました。

とにかく目標を達成することだけを考える

私は上にも書いたように”勝ち方”(≒目標達成の仕方)にこだわってきたのです。しかし、私の場合勝ち方に拘った結果、思うような成績をだすことが出来ませんでした。

そこで学んだことは勝ち方にこだわる前にまずは勝て。ということです。オリンピック3連覇の吉田沙保里選手へのインタビュー記事の中でこのように書かれています。

「とにかくレスリングは勝ってナンボ。私はあくまで勝ちにこだわっていきます。」

吉田沙保里「相手のケガ」を攻めるのは卑怯なのか?

なので、目標を達成するためならなどんな手段であっても良いと思います。それがたとえ泥臭い方法だったとしても目標を達成するために必要な手段であればやるべきだと思います。

目標設定方法と目標までの道のりの描き方、次の試合でのアクション

todo

どんな手段を使っても目標を達成する。とは言っても具体的にはどうやるのかがイメージついていない人もいると思うので、私の目標設定方法と目標までの道のりの描き方、次の試合でのアクションをお伝えします。
まずは、目標設定方法です。

目標を立てるときは、自分がなりたい姿を具体的に決めます。おすすめは5W1Hを意識することです。

例えば、2024年のパリオリンピックの100mで9.42sの世界新を出し、金メダルを獲得するという目標を立てたとします。

目標を立てる時に、同時にその結果を出すときの試合運びと会場もイメージします。

例えば試合運びは100m後半の伸びが武器なので前半は離されないようについていき、残り30mで他の選手を抜き去る。会場はパリの〜競技場で、気温は32℃、タータン(競技場の地面の素材)は固めで。。。のような感じ。

このように具体的な目標と試合運び、会場をイメージすると、自分がどういう環境下でどんなパフォーマンスを発揮しないといけないのかがリアルにイメージすることができます。

次に目標までの道のりの描き方です。

道のりを描くときは具体的な目標から直近の試合で求められる成果まで逆算します。

例えば、今シーズンは地域ランキングで1位を取り来シーズンの全国大会に参加するため、3個の地域シーズン戦で1位を取る。来シーズンは全国大会で10位以内に入るため、全国大会にて〜の結果を出す。

このとき、短期的な目標ほど現実的に、長期的な目標ほどチャレンジングな目標をおいた方が良いと思います。短期的な目標をチャレンジングなものにしてしまうと、すぐに目標を達成できなくなり意味のない計画になってしまう可能性があるからです。

ここまでで直近の試合での目標が決まりました。最後に次の試合の目標を達成する方法、つまり次の試合でのアクションです。

まず、その試合で目標を達成するために求められている成果の10~20%増しのパフォーマンスが何かを想定します。
そして、そのパフォーマンスを出すためにどういう行動が必要かを考えます。

このような形で目標設定を行い、そこまでの道のりを描き、次の試合でのアクションが分かれば、普段の練習でも何をすべきかが見えてきます。なので、これまで以上に根拠を持って練習に打ち込むことが出来るので、日々のモチベーション維持がしやすくなります。その結果、目標達成の確度も高まるでしょう。

まとめ

本記事では、スポーツで結果を出すにはどういう考え方が必要かというテーマについてまとめました。

最後まで読んでいただいた方はビジネスでも同じだと感じたかもしれません。ビジネスにおいても全ての仕事には目標とするアウトプットがあります。そこを意識せず、がむしゃらにやっていても目標には近づきません。目標達成に必要なことは具体的な目標を設定し、それを達成するための道のり(計画)を描くことです。目標から逆算することにより日々の仕事(練習)が意味あるものになるのです。

もし、成果が出ないと悩んでいる方がいれば、この考え方を参考にしてもらえればと思います。

外国人社員とのプロジェクトで注意すべきコミュニケーション上の3つのポイント

外国人社員が入ってくるがどのように接するべきかわからない・・
コミュニケーションで気をつけることは?
英語に自信ないけどどうしよう。。。

そう思っている方に役立つと思います!

外国人社員と1年半プロジェクト進めてきました

私は10数カ国の方が働く会社で1年半働いています。国籍はアメリカ、ドイツのような欧米だけでなくアルゼンチン、インドネシア、バングラデシュといった世界中の方々が働いています。彼らとはもちろん同じプロジェクトのメンバーとして働いたことがあります。私はプロジェクトマネージャーなので、プロジェクトの日本人は私1人で、エンジニアが外国人だけということもありました。

このような経験から外国人とプロジェクトをする上で気をつけたほうがいいポイントをお伝えできると思います。

基本はみんな同じ人間だから心配しなくて大丈夫

実際のところ外国人だからと言ってコミュニケーションのポイントはそんなに違わないなというのが私が1年半一緒に働いてみた感想です。

外国人社員とは言語の壁は若干あるものの、ある程度同じ志を持った方々が会社に入ってきているはずなので、皆目指したい方向性に大きな違いはありません。なので、誰かが仕事で協力してくれないとか、チームワークが悪いといったことは起きにくいです。

例えばソフトウェア開発のプロジェクトの場合、あるお客様の業務を効率化する、売上を高める、などが目的です。これが共有できており、理解されていれば誰であろうと目的に向かって動いてくれます。

逆に、目的を共有し、理解してもらえるような説明ができていないとモチベーションやチームワークの悪化に繋がります。これは日本人でも同じだと思います。特に外国人の場合、これによるモチベーション低下が顕著に現れる気がします。

その説明ってのを外国人社員にするのが難しいんだよと思われるかもしれません。

(日本企業なら)英語が下手でも大丈夫

英語のスキルは大して心配ありません。使い古された表現ではあるものの、結局は気持ちがあれば伝わります。

私の場合、流暢な英語は完全に諦めています。なので、ホワイトボードとメモを必ず使ってスピーキングスキル以外の力をフル活用しています。その結果熱意でやりたいことやお願い事が伝わっているようです。笑

しかし、ビジネス英語が求められる会社では上記のようなやり方だけでは仕事をスムーズに進められないかもしれません。友人の話を聞く限り議論の場で意見を言えないのはいないのと同じとみなされるようです。議論についていくにはそれ相応のスキルが必要と思います。

外国人とプロジェクトを進める上で私が気をつけている3つのポイント

外国人とコミュニケーションを取るだけでなく、モチベーション高く働いてもらってプロジェクトの成果を高めるためにはいろいろと気を付けなければいけないと思っています。私が気をつけているのは以下の3点です。

①ちゃんと伝わっていない前提で、話す・伝える

英語が流暢であればこれを意識する必要はないです。しかし、そうでないなら伝わっていない前提で話した方が良いと思います。

よくあるのは、こう言ったつもりだったのに違うように受け取られたということです。正しい英語で伝えているつもりでも、自分の英語が間違っていたり発音が違ったり、はたまた文化の違いで違うように理解されてしまったりすることがあります。それを全て相手が理解していないからだとか、分かっていないのに言ってくれなかったと思い始めるとどんどん関係性が悪くなっていきます。

なのでおすすめは話しながら英語でメモを取るor取ってもらうことです。ちょっとした進捗確認レベルの会話で生まれたtodoや方向性に関わる話であっても、基本的にはメモをslackで共有しています。それにより言った言わないを減らせるよう心がけています。

②仕事の依頼時には必ずお願い理由と目的、その仕事が今後にどう繋がるのかを伝える

私はプロジェクトマネージャーとして働いているので仕事をお願いする機会が多いです。その際に毎回気を付けているのが、この仕事の目的は何なのか、なぜあなたにお願いしているのか、その仕事が今後にどう繋がるのかの3つを必ず伝えるということです。

1つ目の仕事の目的を伝える理由は、特に外国人の場合、仕事の必要性を理解できなければやる気を出してくれないからです。日本人であってもきっとそうだと思います。なぜこの仕事をやるのかを言わない上司がいますが、それが分からないと創意工夫の余地も限られるし、やる必要性に納得ができないからみなさんも嫌ですよね?

2つ目のなぜあなたにお願いしているのかを伝える理由は、お願いされた方が承認されたと感じるからです。例えばあなたのこういうところがこの仕事に合っていると思うから担当してほしいと言われると、自分を認められたと感じますよね?

3つ目のその仕事が今後にどう繋がるのかを伝える理由は、責任感を持ってもらうためです。理由なく納期を遵守しようとしてくれる外国人は少ない印象です。先述と同様、納期に対しても納得感を持ってもらわないといけません。なので、あなたの仕事の成果を使ってその後誰々がこういうことをするといったように伝えると「自分が担当する仕事」から「プロジェクト全体に影響を与える一部の仕事」という意味に変わります。これにより納期に対しても納得感を持ってもらえます。

これら3つとも理解してもらえるとモチベーション高くその仕事に取り組んでもらえると思っています。

③その人が大事にしている価値観とは何かを知ろうとする

プロジェクトマネージャーとして働いている以上、これはとても大事だと思います。なぜかと言うと、プロジェクトを進めていて、その人が大事にしている価値観に反することをしなければいけないタイミングがどうしてもあるからです。

わかりやすい例で言うと、家族重視か仕事重視かということです。日本人以上に外国人は家族との時間を大事にする人が多いように思います。そんな外国人にも急な残業をお願いしないといけないタイミングがどうしてもあります(そもそもそんなマネジメントじゃだめだと言われるかもしれませんが、、)。そんな時にその人が何を大切にしているかを知っていれば、対策は取れるのです。このケースで言えば、その日はお願いして残業してもらうものの、他の日は早めに帰ってもらうとか、家族が誕生日の日は早めに教えてもらって休みにするといった感じです。

このように何を大事にしているかを理解した上でそれを尊重しようという姿勢が外国人社員にも伝わってモチベーション維持にも繋がるのです。

外国人とのコミュニケーションにおける具体的アクション

これまでの内容をまとめると共に、少しでも参考になるよう具体的アクションを整理します。

①ちゃんと伝わっていない前提で、話す・伝える

Todoや会話内容はメモで共有する

②仕事の依頼時には必ずお願い理由と目的、その仕事が今後にどう繋がるのかを伝える

  • この仕事の目的は何か
  • なぜあなたにお願いしているか
  • あなたにお願いした仕事は何に影響するか

の3つを毎回伝える。

③その人が大事にしている価値観とは何かを知ろうとする

ランチや休憩中の雑談でその人の価値観を知る。
ex. 休日は何してたの?仕事終わりは何してるの?と聞いてみる

まとめ:だれであっても相手を理解しようとすることが大事

これまで読んでいただいて分かる通り、何一つ特別なことは無かったと思います。結局外国人社員だからと言って、コミュニケーション方法を大きく変える必要はないのです。むしろ国籍の違いよりも個人差の方が大きいと私は思っています。外国人だからと気負わず〇〇さんはどういう人なんだろうと、その人を1人の人間として理解しようと心がけた方が良いコミュニケーションが出来ると思います。

多様性の時代、人を完全にグルーピングするのは不可能と思います。なので、一人一人を理解しようとする姿勢が相手にも伝わりお互いの理解を促進すると感じています。

現役PMが伝える今日から実践できるAIプロジェクトの進め方〜PoCフェーズ編〜

poc

AIプロジェクトをリードすることになったがどのように進めるか分からない…

いろいろな話や本から意識することは分かったけど、具体的なアクションが分からない…

今PMをやっているが体系化できていない…

私も初めの頃はこういう悩みを持っていました。なのでなにをすべきかまとめました。

これまで、私はAIプロジェクトを8つ経験してきました。AIプロジェクトのPM歴は1年半とまだまだ若輩者です。今も模索しながらやってるので随時アップデートしていこうと思ってます。

本記事を読んでいただくとAIプロジェクトの構想フェーズにおいてやるべきことがイメージできます。そのために、可能な限りやることをイメージできるよう書きました。

上述の通り若輩者ですが、初めてプロジェクトをリードする人にとって本記事はきっと有益な情報になると思います。今後の記事も読んでみてください。

  1. 構想フェーズ編
  2. PoCフェーズ編(本記事)
  3. 実装フェーズ編
  4. 運用フェーズ編

前提

ちなみに、わたしはベンダー側として働いているので、そちら側の目線で書きます。自社内で行う場合は少し違うところもあると思います。ただ、ポイントは同じと思います。

最初にAIプロジェクトとは、PoCフェーズとは、という話をするので知ってるよ!って方は飛ばしてください。

AIプロジェクトを成功させるためにやるべき4つのこと

success

「成功」を私なりにAIプロジェクトの結果に全員が納得できることと定義します。

その場合以下の4つが大事です。これが出来ていれば仮に目標を達成できない結果となったとしても、不満をもたれることはないでしょう。

  1. 目的を常に意識すること
  2. ゴールまでのマイルストーンを置くこと
  3. すべての結果の根拠を見つけにいくこと
  4. 専門家並みのドメイン知識をつけること

理由を説明する前にAIプロジェクトとは、PoCフェーズとはについて念のため記載しておきます。

AIプロジェクトの全体像

AIプロジェクトはこちらの記事にも書いてる通り、①構想フェーズ、②PoCフェーズ③実装フェーズ④運用フェーズ の4つに分かれています。システム開発PJをやったことのある人ならだいたい同じだなということがわかるでしょう。しかし、若干異なる部分やAIプロジェクトならではのところもあるので、これまでの経験を元にどういうことを行うか解説していきます。

本記事では、前回記事からの続きで②PoCフェーズについて説明します。ちなみに詳細な説明はしないので、始めてで右も左も分からない!と言う方はこちらの本がおすすめです。めちゃくちゃ分かりやすく書かれていて、読み終わる頃にはPJのイメージが掴めます。

PoCフェーズでやることってなに?

PoCフェーズでは以下のような5つのことを行います。

  1. データの特徴理解(入力データがちょー大事)
  2. 前処理
  3. モデル構築
  4. 後処理
  5. 評価

これらをPoC期間中番号順に繰り返し、目標となる精度、エラー率などを目指します。

データの特徴理解(入力データがちょー大事

ここでやるべきことはこの記事に詳しく書いているので読んでみることをおすすめします。

データは1つ前の構想フェーズにてデータを軽くみている場合が多いです。しかし、このフェーズではさらにいろいろな観点でデータを理解します。例えば、平均や分散のような統計値、外れ値、欠損、一定のデータ毎の統計値などです。

だいたい最初にドメイン知識から仮説を立てます。それを基にマクロな観点でデータを確認します。その後、ドメイン知識とマクロなデータ理解からより粒度の細かい仮説を立てます。同様にその仮説に基づきデータを確認します。念のため具体例を用いて説明しましょう。

例えば、飲食店の売上を予測するという課題があります。飲食店の場合、週末の夜は売上が高く、平日ランチは単位時間当たり客数が多いだろうとドメイン知識(この場合は一般常識レベルですが)から仮説が立ちます。その仮説に基づき曜日と売上、曜日と単位時間当たり客数を可視化します。その結果、予想通りのグラフとなっていれば仮説は正しかったと言えます。そのグラフから別のことが分かれば、それを確かめるために更にデータを用いて深堀していくようなイメージです。

このようなイメージでデータに対する理解(=課題に対する理解)を深めていきます。

前処理

モデルに入れるための説明変数を何にするかを検討します。上の飲食店売上予測の場合は、人が予測している場合にどのような項目をみているか、どのような見方をしているかを反映させてあげるようなイメージです。

例えば、先週の売上や昨年の売上を考慮し、向こう1週間の売り上げを予測しているのであれば、先週と昨年の売上は必ず必要になってくるでしょう。

モデル構築

前処理で作成した説明変数と学習データを使ってモデルを構築します。

データを何回学習させるか、説明変数はどれを使うか、どのモデルをアンサンブルするかとか試行錯誤を繰り返します。このあたりは最近自動化が進んでいるのでやることは減ってきている感じですね。

後処理

モデルの出力結果を補正する必要があれば補正します。

ルールベースで補正できることを実装するイメージです。上の売上予測の例で言うと、年末年始やお盆に休むからその日の売上を0にするといった感じです。

評価

ここまでで入力から出力までの一連の流れ(パイプライン)が完成したので、それぞれ設定を変えて作成したパイプラインの比較を行います。その比較からそれぞれの得意不得意を把握し、パイプラインに改良を加えていきます。

ここまではPoCにてチーム全体としてやることの説明をしてきましたが、PMがどういう動きをするかについても後の内容理解のために少しだけ書いておきます。

PMタスク

論文調査継続(構想フェーズでやっているものの継続する)、問い合わせ対応、資料作成、会議、方針決定

AIプロジェクトを進める上で大変なことは?

hmmm

一番は先が見えなくなることです。そのほかにも大変なことはいくらでもあります。しかし、やはりこれが一番辛いなというのが経験上思うことです。

実際にPoCの具体例を交えながら説明します。

過去の失敗PoC:画像内の傷検知と傷のサイズ判定

このPoCは画像内のある傷を検知し、更にそのサイズを数レベル程度に分けるという課題でした。

当初からお客様も難しいと認識されていた課題だったので、どれくらいの精度が必要かという目標値はありませんでした。

それ自体は問題なかったのですが、PMの私はPoC内での目標というかゴールイメージを持たないまま進めてしまいました。例えばこれこれの仮説を検証し、その結果分かったことや課題を報告するというように最低でもこれくらいのゴールイメージは持っておくべきでした。

このPoCは前任者から引き継いだものでしたが、始めから今ある画像だけでは難しいのではと感じていました。なので、いろいろな方法を考え、無作為にと言ってもいいくらい試行錯誤した結果、何が分かってどれが良かったのかが分からなくなってしまいました。。

PoC期間は終わりに近づきPoCの結果を整理する段階になって整理の仕方にとても苦労しました。それぞれの結果はあるものの、精度が良い理由をある程度の根拠を持って確認できていなかったのです。また、いろいろな傷検知を行う中で、どの画像を苦手としているのかという現状の課題を定量的に理解できていませんでした。

その当時はPJが経験が浅く、画像認識の知識やこの課題のドメイン知識が少なく、他の解決方法がほぼ思いつきませんでした。今思えば、運用から変えるという提案をしても良かったのかもしれないと感じています。

つっこみどころはたくさんあると思いますが、当時の私はこれでも必死にやってました。笑

こんな感じで失敗も経験してきて、こういうことを意識できていないとうまく行かなくなるなというのが少し分かってきたのでまとめます。

この4つが出来ていないAIプロジェクトは失敗する

mistake

ここまでの内容をまとめると、以下のことができていないと失敗すると言えるでしょう。

  1. 目的を常に意識できていないこと
  2. ゴールまでのマイルストーンがない
  3. 結果の原因を理解できていない
  4. ドメイン知識不足

それぞれ理由を解説していきます。

目的を常に意識できていないこと

これ一番大事です。他の記事でも言っていますが、私自身PJをやっていて何度も感じてきたことなので書きました。

難易度が高いPoCだと進めていくうちにどんどんいろいろな種類の課題が発生するんですよね~…それら全ての課題を決められた時間内に解決するのは無謀です。すべてを解決しようとするのではなく、PoCの目的と照らし合わせて最初にどの課題を解くべきかを考えます。そしてその選んだ課題に取り組み、また次に解くべき課題を選ぶというサイクルを進めていくべきだとこれまでの経験から学びました。

ゴールまでのマイルストーンがない

これもめちゃ大事です。高難度の課題であっても一旦仮でゴールイメージを持ち、そこまでどうたどり着くかっていうマイルストーンを置かないと、メンバーは迷走するし、モチベーション下がるし、いいことなしです。

これをPoCで提出することのある報告書を例にもう少し具体的に書きます。報告書を最後にまとめようとすると、あれも検証しなきゃ、これの根拠ってちゃんと検証できてるんだっけ?みたいにやることが溢れ出てきて全然間に合わなくなります。なので、報告書記載イメージをPoC期間の半分を過ぎる前にはしておいた方がいいです。できれば最初からしておいた方がいいです。これがすなわちゴールまでのマイルストーンを置くことになります。

でもそんなの無理だろって思うかもしれません。そうです。最初はできません。自分もまだ全然できていないですが、これを繰り返すことによりできていっている実感はあります。なので前より自分が思った通りにPoCが進められるようになってきています。また、1つ1つ結果の原因を確認する時間を設けることができているため、報告書の内容に誰もが納得できるような説明が出来るようになってきています。

結果の原因を理解できていない

結果の原因がわからないのは危険です。結果の原因を想定でこういうことだろうと決めつけ、なんとなくでいろいろな検証を続けても得られる知見はありません。

例えば何か将来の値を予測するAIを複数構築した際にその精度に若干の違いがあったとします。その時にこれくらいは誤差かと片付ける(本当に微々たる誤差であれば誤差としても良いと思います)のと、予測結果を目視確認し、その原因を確かめようとするのでは後々大きな違いが生まれてきます。前者のやり方はいろいろな結果が出力されるものの、その理由を説明できないでしょう。後者のやり方は、1つ1つの原因の積み上げがあるので、どうしてそうなったか説明できるでしょう。また、原因が分かった状態で進めているので、きっとゴールへ近づく方向に進められるでしょう。

この考え方自体は当たり前なんですが、これを突き詰めてやれる人が意外といないので書きました。

ドメイン知識不足

当たり前ですがないといけないので書きました。どれくらい必要かを伝えるのは難しいですが、感覚値を書いておきます。そのドメインの関連論文や最新論文を理解し、お客さんと会話できるレベルになるくらいです。そのドメインを専門でやられている方と仕事をするというのは、その専門家が悩んでいること(=そのドメインの課題)を解決するということになります。なので、その専門家の悩みの背景を知るためにはそれくらい必要だなと感じています。

AIプロジェクトを成功させるために今日から実践できるアクションプラン

win

これまでのところである程度AIプロジェクトを成功させるために意識すべきことが何かについては理解してもらえたと思います。これらを活かしていくために、アクションに落としこんだものをお伝えします。ちなみに4点の内特に大事な2点に絞りました。

これは私がプロジェクトで実際に活用している方法になります。そのアクションは2つです。

アクション①:図でPoCのプロセスを整理する

上に「目的を常に意識できていないこと」はだめだと書きました。これの防止策として私は以下のように図で実施したことを整理しています。

idea flow

書き方は、最初にスタート(PoCのテーマ)とゴール、そして書けるところの仮説を書きます(図の赤色)。次に仮説を書き、それに対して検証を行ったら結果と結果の理由を書きます。再度次の仮説を立てます。このように仮説検証を繰り返し行った結果を図として残しておくことで思考の整理になります。また、目的を忘れることがなく、常に目的に向かって進んでいけると考えています。

この図はゴールまで直線的に進んでいますが、実際はいろいろと枝葉が生まれていく感じになります。

アクション②:報告書を早めの段階で書く

上に「ゴールまでのマイルストーンがない」はだめだと書きました。これの防止策として私は以下のようなやり方をしています。

PoC開始後、出来る限り早い段階でPoCのゴールと照らし合わせて、報告書で伝える内容を決めます。そして、それを可能な限り報告書に落とし込みます。

こんな感じでPoC開始後早い段階で書き出します。

ちなみにこの方法は以下の本(仮説思考)の中で紹介されている方法を真似しています。実はこちらの記事でも紹介しています。この本ばっかかよと思われるかもしれませんが、私が紹介した意外にもこの本の中に仕事を爆速で進めるTipsがたくさん詰まってますのでご購入を激しくおすすめします。

伝える内容

売上予測精度は85%となった。大型連休前後の予測は~の理由から外れやすいが、通常の平日土日については実運用にて使用可能なAIだと考える。また、運用コストを考えても人が予測するよりAIに置き換えるべきと考える。そう言える根拠は以下の3つである。

根拠①

通常の平日土日の予測精度は92%で最小の日でも82%と外れても問題ない範囲であるため

根拠②

大型連休の予測は人も外れており、現段階では予測の重要性が低い

根拠③

人の場合は¥~の費用と予測が外れたことによる¥~のコストが発生している。一方AIの場合はシステム運用費用を考えても¥~のコスト削減効果が見込まれる

一旦これくらい書ければ、報告書として記載すべき内容も洗い出され、尚且つ検証すべき内容がリストアップできます。そうすると、いつまでに何を検証できていないといけないのかが分かります。もちろん最初はうまくできないのですが、間違えていたら修正を繰り返していけば良いのです。

まとめ

ここまで読んでいただきありがとうございました!

最後にまとめますと、AIプロジェクトで失敗しないためにやるべきことは以下の4点です。

  1. 目的を常に意識すること(アクション①)
  2. ゴールまでのマイルストーンを置くこと(アクション②)
  3. すべての結果の根拠を見つけにいくこと
  4. 専門家並みのドメイン知識をつけること

記事を読んで感想やご意見ありましたらコメントいただけると幸いです。よろしくお願いします!

現役PMが伝える今日から実践できるAIプロジェクトの進め方 〜構想フェーズ編〜

AIプロジェクトをリードすることになったがどのように進めるか分からない…

いろいろな話や本から意識することは分かったけど、具体的なアクションが分からない…

今PMをやっているが体系化できていない…

私も初めの頃はこういう悩みを持っていました。なのでなにをすべきかまとめました。

記事の信頼度

これまで、私はAIプロジェクトを8つ経験してきました。

AIプロジェクトのPM歴は1年半とまだまだ若輩者です。

今も模索しながらやってるので随時アップデートしていこうと思ってます。

本記事を読んでいただくとAIプロジェクトの構想フェーズにおいてやるべきことがイメージできます。そのために、可能な限りやることをイメージできるよう書きました。

上述の通り若輩者ですが、初めてプロジェクトをリードする人にとって本記事はきっと有益な情報になると思います。今後の記事も読んでみてください。

前提

ちなみに、わたしはベンダー側として働いているので、そちら側の目線で書きます。自社内で行う場合は少し違うところもあると思います。ただ、ポイントは同じと思います。

この2つを抑えていないAIプロジェクトは失敗する

それは以下の2つです。

  1. 真の課題は何か
  2. 決裁者はこのプロジェクトに対して乗り気か

あまりAIプロジェクトに関わったことのない方もいると思うので、AIプロジェクトの全体像と構想フェーズについて簡単に説明した後に理由を説明します。知ってるよって方はすっ飛ばしてください。

AIプロジェクトの全体像

AIプロジェクトはこちらの記事にも書いてる通り、①構想フェーズ、②PoCフェーズ③実装フェーズ④運用フェーズ の4つに分かれています。

システム開発PJをやったことのある人ならだいたい同じだなということがわかると思います。しかし、若干異なる部分やAIプロジェクトならではのところもあるので、これまでの経験を元にどういうことを行うか解説していきます。

本記事では①構想フェーズについて説明します。

ちなみに詳細な説明はしないので、始めてで右も左も分からない!と言う方はこちらの本がおすすめです。めちゃくちゃ分かりやすく書かれていて、読み終わる頃にはPJのイメージが掴めます。

構想フェーズでやることってなに?

一言で言うと、AI開発した方がいいよねってことをPJ参加者全員で合意することです。

そのために、以下のことを行います。

  1. 課題ヒアリング
  2. 課題の解決策の検討
  3. 工数の概算算出
  4. 開発リソースの割り当て可否の検討
  5. ROIの概算算出
  6. 社内外の承認を得ること

これらを概ねこの順番に沿って行います。それぞれを簡単に説明していきます。

課題ヒアリング

課題ヒアリングにおいてやることは想像の通り、どういうことに困っているか、今はどうしているかといったことについて質問することです。つまり真の課題は何かを明らかにすることです。このタイミングで可能な限り多くの情報を聞き出すことが大事です。なぜなら、ここでの情報量が2.以降に影響するからです。

課題の解決策の検討

1. の情報を元に解決方法を検討します。ここで大事なことはAIに捉われず最短かつ最も簡単な解決策を検討することです。どの本や記事にも書いてあることですが、とても大事なので改めて書きました。

工数の概算算出

1.2.の情報を元にどれくらいの期間がかかりそうかを概算します。工数の概算はゴールと開発するシステムの要件が明確に決まっていれば可能です。しかし、大抵の場合明確に決まっていないです。なので工数はざっくりで出すしかないかと思ってます。

開発リソースの割り当て可否の検討

社内でだれがプロジェクトの責任者となり、だれがデータサイエンティストとして参画するかを決めます。

ROIの概算算出

1. で得た情報からある程度ゴールを達成した場合のリターンを計算します。また、3. の工数概算から投資額が分かります。これらからROIを算出するのです。

…とスムーズに算出できれば良いのですが、そうではない場合がよくあります。例えば以下のようなケースがあります。以下はあくまで例です。

①比較対象がない

工場の機器操作を置き換えるという課題では、人の操作ログは残っていない場合があり、比較対象がないことがあります。それにより、何を目標とするか定めづらくなります。

②求めている精度が実際より高い

人が出荷量を予測してシフトを立てるという課題では、人の出荷量が外れていても運用でカバーしている場合があります。具体的には熟練の勘で予測の信頼度が低いと考えている場合はシフトを増やすというような運用です。この場合、AIに求められている精度は高くなることがあります。

こんな課題はナンセンスでしょと思うかもしれませんが、こういう場合でも無理くりゴールとそれを達成した場合の効果を推定します。

上記の例であれば以下のような目標を立てることができると思います。

①比較対象がない 場合の目標設定方法

  1. AIによる操作を人がレビューし、異常な操作でなければOKとする
  2. 工場をシミュレータで再現できる場合は、シミュレータにAIの操作と人の操作を入力し、出力値の差異が10%以内とする(人の操作と似た操作ができているか)

②求めている精度が実際より高い 場合の目標設定方法

  1. 理想の精度を目標とする
  2. 人の精度を目標とする。(運用でカバーする)
  3. 予測に確率で幅を出す(これくらいの幅に予測が当てはまりますみたいな感じ)

ゴール設定の仕方に正解はないと思っていて、AIを使う方々が納得できるのであればなんでもよいと思っています。

社内外の承認を得ること

PJ全体計画と目標、ROIなどについてPJ参画者で合意します。ROI的にやるべきPJであったとしても決裁者の中での優先度次第ではPJ開始が遅れたり、無くなったりする場合もあるので、決裁者がだれかおさえておくことはとても大事です。

絶対に抑さえておかないといけないポイントは?

抑えておかないといけないのは「真の課題は何か」、「決裁者はこのプロジェクトに対して乗り気か」です。

まず「真の課題は何か」についてです。

これが分かっていないと解決策が少しずれたものになったり遠回りになってしまいます。当たり前だろと思うと思いますが、常に意識していないと意外と真の課題からずれていってしまうなーとこれまでの経験から感じています。

過去にあったのが、課題ヒアリングにてお客様が発言された課題が真の課題ではなかったということです。これはヒアリングする側とされる側の前提知識が異なることから生まれたと思っています。このとき、ヒアリングされる側(お客様)は私たちにお願いしたい課題について説明してくださったのですが、長期的には別の課題を解決したいと思っていらっしゃいました。

例えば、短期的には頻発する小さな異常を検知したい。長期的には、まれに発生する大きな異常を検知したいという感じです。これらはアプローチが大きく異なってきますので、長期的に解決したい課題を意識してPJを進める必要があります。

なので、お客様が言ったことを鵜呑みにせず、常に真の課題は何かを意識することが大切です。

次に「決裁者はこのプロジェクトに対して乗り気か」です。

どれだけROIが高いと分かっていても決裁者が責任を持つPJの中で他によりROIの高いPJがあれば私たちのPJの優先度は下がります。そもそもその人にとってメリットのあるものでなければ優先度は下がってしまいます。そんなの自分たちでコントロールできねーよと思うかもしれません。しかし、PJをリードする側としては、できる限りこのPJが決裁者にとってメリットがあるようなストーリーを作らなければなりません。

決裁者は大抵ある程度経営に関わっている方が多いので、やれることとすればこのPJがどれだけ転用可能性があるのか、経営にインパクトを与えられそうなのかを定量的に示すことです。正直私はまだまだこのあたりをうまく訴求することはできていませんが。。。

決裁者が乗り気になれば、若干の向い風要因(例えば新型コロナの影響や成功確度が低そうなチャレンジングな案件)があってもPJをやろうとなると思います。

AIプロジェクトを失敗させないためにやるべきこと

ここまでめっちゃ長くなりましたが、結局何をしたら良いのか?に対する回答をしたいと思います。

大事なのは上に書いた通り2点「真の課題は何か」、「決裁者はこのプロジェクトに対して乗り気か」だと思っていますので、この2つを抑えるためにやるべきことを以下に書きます。

真の課題は何か に対するアクション

・様々な確度から真の課題を探ること

私は時間・役職・聞く方向の3つを変化させて質問し、時折自分の仮説をぶつけて意見を引き出しています。お客様と私たちでは前提知識・条件が異なるので、自分がいろんな前提に立って質問するべきだと考えています。具体的には以下のような質問をします。

時間観点

今一番困っていることはなんですか?
将来的にはどうなっているのが理想ですか?

役職観点

Aさん(決裁者の方)は何が課題と感じていますか?
Bさん(現場の方)は何が課題と感じていますか?

聞く方向の観点

逆にこういう解決策はどうですか?

これらは私が実務の中でよく実践している方法です。これ以外にも観点はいろいろあり、この本にはより詳細に書かれています。

私もPJをリードする立場になりたてのころは、この本を読んで会議前に会議のイメトレをして臨んでいました。

決裁者はこのプロジェクトに対して乗り気か に対するアクション

・発展可能性を示すこと

このPJで開発したAIを使うとどういうことができるのか、ほかにどういう可能性があるのかを言語化します。そのために、お客様の商流やステークホルダー、業界における立ち位置などを調査します。

2つ目が具体性に欠けていてすみません。場合によってやり方が大きく異なるのでこのような書き方となりました。

まとめ

AIプロジェクトを失敗させないためにということで説明してきました。
改めてポイントを振り返ります。抑えておかないといけないのは以下の2点です。

  1. 真の課題は何か
  2. 決裁者はこのプロジェクトに対して乗り気か

これらを抑えていれば、PJを進められる可能性が高まるのではないかと思います。

お読みいただきありがとうございました!最後までお読みいただいた方にはおまけです↓。

また、わたしはこうやってるというコメントや反対意見ありましたらコメントいただけると嬉しいです!

おまけ

ヒアリング観点一覧を晒しておきます。

カテゴリ質問内容理由
背景なぜPJを検討しているか。
(課題があるからか、AI導入命令があるからか)
担当者モチベーションやPJ予算の把握、本気度を探るため
課題何に一番困っているか
短期、長期的な課題は何か
〜さんは何に困っているか(役職毎)
真の課題を知るため
目的どれくらい改善したいか
優先するのはどちらか(いくつか課題がある場合)
どうなっているのが理想か
PJのゴールを定めるため
過去の
分析実績
過去に同様のPJやってるか
その時はなぜうまくいかなかったか
過去の知見を得るため
比較対象を知るため
評価方法精度か、改善度合いか、摘出率かAIの評価指標を揃えるため
データどれくらいあるか
偏りはあるか
難易度と実施可否を見定めるため
説明変数人は何を重要視しているか
要因となるのは何か
説明変数候補を知るため
競合他社なぜ弊社か、他の会社もいるか比較対象、方法を確認するため
リテラシーどれくらいAI導入を検討しているかAI周辺の理解度を探り、認識のずれを認識するため
決裁者誰がこのPJを評価するか誰を一番意識すべきかを理解するため
スケジュールいつまでにPJを終え、運用にもっていきたいかPJの想定期間を知るため

未経験からAIエンジニアに 採用面接も行う社員がチェックする3つのスキルとは

AIエンジニアになりたいけど何から始めて良いかわからない。

AI関連の勉強はしたけど採用面接では上手くいかない。。

採用面接では何を見られているんだろう。。etc.

AIエンジニアとして働きたいけどなれるんだろうか?と不安に感じているあなたへ。

私はプロジェクトマネージャとして働いていますが、AIエンジニアの面接も行っているので、どういうところを面接官として見ているのかをお伝えします。

結論:仕事に取り組む時に3つの考え方をしているか、を見ている

私は技術的スキルももちろん大事ですが、仕事に対する取り組み方が大事だと思っています。

ここで言う仕事に対する取り組み方というのはある課題に対してどのようなアプローチで解決したのかという意味です。

具体的には以下の3つの考え方をしているかということを面接で見ています。

  1. 仮説を立てて仕事(課題)に取り組んでいるか
  2. その課題における最も重要な原因が何かを把握しているか
  3. その課題の現状を定量的に捉えているか

これがどのような取り組み方かが伝わりにくいと思いますので、具体例で説明します。

例えばAさんに働き方改革で生産性向上を図れ!というお達しが来たとします。

Aさんは始めに以下のような現場の課題に対する仮説を立てました。

  1. 会議が長い&多いのではないか
  2. 社内向け資料が多すぎるのではないか
  3. リモートワークで良いのではないか

次にヒアリングやデータから検証をしました。

そうすると、生産性向上における一番の課題は営業効率が低いことではないかという新たな仮説が生まれました。

原因は確度の低い顧客へのアプローチに時間がとられていることだとわかりました。

それを定量的に把握するため、同業他社の営業社員数に対する売上と自社のそれを比較した結果、30%もの開きがありました。

Aさんは並行して最初の3つの仮説の影響も定量的に評価していましたが、営業効率が一番の課題であることが改めてわかりました。

実際の面接ではこのような取り組み方をしているかどうかを見ています。

なぜかというとそれぞれ理由があります。

なぜ3つの考え方が必要か

  1. 仮説がないと技術があっても素早くゴールに辿りつけないから
  2. 課題は複雑にいくつもの原因が絡み合っており、1つの重要な原因を解決することにより効率的に解決できることが多いから
  3. 現状の課題を数値で捉えていないと重要な原因が何か分からないから

1.の根拠

マコなり社長(↑)や仮説思考(↓)の中でも言われていることで、当然AIエンジニアにも当てはまります。

ちなみに仮説思考はボストンコンサルティンググループ元日本代表の内田和成氏が執筆された本で仮説思考の実践方法とそれによるメリットが分かりやすく書かれているので大変おすすめです。

AIエンジニアは人の判断や行動を置き換えるAIを構築することが主な仕事です。

つまり人の言語化されていない情報をAIに学習させる必要があります。

そのためには人の判断や行動の際に使われる情報が何か、どのような思考で判断行動しているかを推測(仮説)することが必要になってきます。

もちろん置き換える対象の人に聞けばある程度言語化できる部分はありますが、膨大なデータを見て判断していたり、長年の経験を頼りにしている熟練の方の判断や行動は言語化することは容易ではありません。

2.の根拠

どんな課題でも複数の課題が複雑に絡み合っています。

それを全て解決することも良いですが、大抵の場合時間切れとなります。

そのため、複数の原因の中から最もインパクトのある課題を見つけ、その課題の解決に全リソースを投下することがROIの高い解決策となるのです。

3.の根拠

上述の通り課題の中には複数の原因があり、そのどれを解決するのが最もインパクトがあるのかを決める必要があります。

そのためには、課題解決度合いを図ることができる指標(上述の例であれば、時間当たりの売上)で評価する必要があります。

それで初めて最も解決すべき課題が何か分かるのです。

抽象的な話がつづいたので、AI開発における上記3つの考え方の活用例を紹介したいのですが、業務の話は契約上公開できないので、実例をデフォルメして書きます。

実例:あるパン屋の売上を予測するPJ(実例をデフォルメしてます。)

始めに、パン屋さんが売上を予測したい理由をヒアリングしました。

その理由はパンの仕込みに時間がかかり、想定の販売個数より少なすぎると採算悪化、多すぎると販売機会の損失や欠品していることによるクレームに繋がるとのことでした。

そこで各商品の売上と仕込み時間を定量的に比較したところ売上予測が外れた際に店舗の売上に最も影響が大きいものはメロンパンであることがわかりました。(3つの考え方の内、2.と3.です。)

ここで最も予測精度の高さが求められる商品が分かったので、メロンパンの売上に影響のある要素は何かを分析することになりました。

始めにメロンパンの売上に影響のある要素を仮説でリストアップし(3つの考え方の1.です。)、そのうちの1つ「メロンパンは子連れのお母さんが夕方に買う」という仮説を検証しました。

この仮説を検証するために分析を行いました。

その結果ある程度仮説が正しいことが分かったので、家族構成と年齢、時間を売上予測AIの説明変数としました。

その結果、15%の誤差となり、人の予測誤差の1/2となりました。

このような流れで実際にはPJを行ないました。

もし、3つの考え方をしなかった場合は以下のようになるでしょう。

3つの考え方をしない場合のPJ例

始めに、パン屋さんが売上を予測したい理由をヒアリングしました。

その理由はパンの仕込みに時間がかかり、想定の販売個数より少なすぎると採算悪化、多すぎると販売機会の損失や欠品していることによるクレームに繋がるとのことでした。(以下の下線部が上の例と異なる部分)

そこでパン屋全体の売り上げを予測するAIを構築するために、パン屋全体の売上に関わる情報を全てリストアップし、売り上げに相関がありそうな情報を調査しました。

その結果、一部のデータは若干の相関が見られたものの、相関が強いとは言えませんでした。

その状況をパン屋さんに報告したところ商品によって売上のトレンドは全然違いますとコメントをもらいました。

その情報を参考に全商品の売上のトレンドを確認したところ、パン屋さんのコメント通り、商品によって全くトレンドが異なることがわかったので、商品毎に売上を予測することになりました。。

上述の3つが重要な理由が理解できましたでしょうか?この3つがなければひたすらにデータ分析とAI構築を繰り返していくことになりかねません。

とはいえスキルもいるのではと思われる方がいると思います。

全くその通りですが、あくまで分析手法をたくさん知っている、プログラミングスキルがあるというのは手段を持っているのであって、重要なのは目的を意識できているかだと思っています。

今日から意識すべきポイント

未経験からAIエンジニアになるためには、3つの考え方を意識してkaggleに挑戦することです。

世の中にはkaggle攻略に関連する記事や本がたくさんありますが、一旦それらは無視して上述の3点を意識して以下のように取り組んでみましょう。

  1. 最初に課題を読み、課題を解く上で最もインパクトのある原因は何かをデータから確認します。
  2. その原因を解決するために分析を繰り返し行います。
  3. 最もインパクトのある原因がわかったら、それを解決する最も簡単な方法は何かを考えます。
  4. その考え方でAIを構築します。(大抵はシンプルなモデルになりますが、シンプルなほど入力と出力の関係が分かるので、その次のアクションが取りやすくなります。)
  5. 出来たAIの出力結果から次の仮説を立て、AIを改善していきます。

実務経験がない方でもこのアプローチでkaggleに取り組んでいることが面接で分かれば、私ならすぐに実務で活躍できそうだなと判断します。

kaggleが初めてなら色々な人の日本語解説が公開されているtitanicがおすすめです。

最もシンプルなモデルと重要な説明変数2~3個程度のみでも80%程度の精度は出せます。

実際のビジネスならこの精度でも十分かもしれません。

まとめ

何度も繰り返しになりますが、AIエンジニアの採用面接においてスキルはもちろんのこと、以下の3点も重要視しています。

  1. 仮説を立てて仕事(課題)に取り組んでいるか
  2. その課題における最も重要な原因が何かを把握しているか
  3. その課題の現状を定量的に捉えているか

この3点を意識すれば今の仕事も格段に効率が上がり、採用面接においても通過率が上がるのではないかと思います。

そもそもプログラミング経験がほぼ無いよ、って方はこちらを参考にしてみてください。

なるほどと思った方は是非シェアやコメントお願いします!

また私はこう考えているというご意見あれば参考にさせていただきたいです。

よろしくお願いします!

PM(プロジェクトマネージャー)が意識すべきメンバへの仕事依頼時の4つのポイント

記事を書く理由

なぜこの記事を書こうと思ったかというと、以下の3点が主な理由です。

  • PMがPJメンバに仕事を依頼する際に意識していることを言語化したものが少ない
  • 4つのポイントを出来ていないPMが多い気がする
  • PJメンバがかわいそうと思うPMをよく見かける

PMとメンバの両方の立場で働いた経験もあり、こういうPMの元では働きたくないな、こうなりたいなという思いがあったことからまとめてみました。

対象読者

  • PMになる人
  • PJメンバがうまく動いてくれないと感じる人

本記事の信頼度

  • 8PJを経験
  • PM歴3年

このように経験が豊富というわけではありませんが、PM初心者の方には少しは参考になると思います。

得られる情報

本記事を読んでいただくと以下の情報が得られます。

  • PMが意識するべきポイントと今後のアクションが分かる
  • PMだけでなく、仕事を依頼する場面において役立つ

結論

先に結論です。私は日々のPM業務の中で以下の4点を気をつけてPJメンバに仕事を依頼しています。

  • 仕事を依頼するときに必ず目的を伝える
  • 任せた仕事を途中で引き取り、他の人に依頼したり自分でやったりしない
  • 任せた仕事は必ずFBする 
  • プレッシャーをエンジニアに転嫁しない(チーム全体でシェアする)

これにより、PJメンバとの関係が起因となりPJ進捗に影響が出たことはありません。

本記事で対象とするPJ

PJというと様々な規模の多様な目的のPJが対象になりますが、あくまで私が経験してきたPJを対象にしたいと思います。それは以下です。

  • 小規模システム開発やデータ分析案件、AI開発案件
  • PJメンバ数5~10名
  • PJ期間は1年弱
  • PJメンバはやる気溢れる人が多い(これ重要)

本記事におけるプロジェクトマネージャーの役割

こちらも上記と同様PMの役割はPJによって異なるので、本記事では以下をPMの主な役割とします。

  • PJの責任者
  • PJの方針策定
  • スケジュール策定
  • 顧客の窓口
  • 実装、分析よりも管理や方針策定、顧客への説明をすること

PMが意識すべきメンバへの仕事依頼時の4つのポイント

前提が長くなりましたが、ようやく本題です。

私がPMとしてPJメンバに仕事を依頼するときには先述の4点に注意を払っています。それぞれその理由を説明していきます。

仕事を依頼するときに必ず目的を伝える 

仕事を依頼するときはそれをやる理由を必ず伝えるようにしています。

なぜなら、目的を理解していれば大きな手戻りが少なく、目的を達成するためにやるべきタスクが何かを皆が考えるようになり、チームの生産性を高めると思っているからです。

PM経験のある方、胸に手を当ててみてください。仕事を依頼するときに、どんな仕事でも目的を伝えていますか?

正直言って私も忙しさにかまけて出来ていない時があるものの、常に意識しています。

これを伝えないとどうなるかというと、依頼された方は間違った成果を出してしまったり、その仕事の意義を見出せず仕事の効率が低下したりととにかく仕事の効率が下がります。

逆に目的を伝えることのメリットは、やり方を自分で工夫できること、仕事のやり方をお互いにチェックできることです。

私も目的を伝えたことにより、PJメンバに別の仕事を提案されたことがあります。

PMがやり方を指摘されるようではだめだと思う方はいると思いますが、私は完璧なPMなどいないと思っていますし、チームで成果を作っていくことが良い結果に繋がると信じています。

任せた仕事を途中で引き取り、他の人に依頼したり自分でやったりしない

任せた仕事は任せ切る!これが後々チーム全体の生産性向上につながると思っています。

自分が作成した資料を知らない間に大きく改編した上で提出されている、仕掛かり中の仕事を「もういいからこっちやっといて」と取り上げられる、このような経験ありませんか?もしくは自分がこのようなことをしてしまっていませんか?

自分が依頼された側だったらモチベーション下がりますよね?

私が周囲を見ている限り、意外と気にしていない人が多いように思います。

期限が迫る仕事でこれを常に守ることは本当に難しいですが、これを守らないことにより確実に依頼された方のモチベーションは下がります。

まだましなのは、納期があるからとか、別の優先タスクをやって欲しいからという理由がある場合ですが、基本的には任せきる方が後々チームとして上手く回っていくと感じています。

任せた仕事は必ずFBする 

どんなに忙しくても、任せた仕事に対して期待以上、期待通り、期待と異なる のどれかを伝えることはとても大切です。

なぜなら、その成果が人に何かしらの影響を与えていると感じられるからです。

成果に対して反応がないと本当に寂しいですよね。やった意味はあったのか?期待通りなのか、そうでないのか。

アウトプットを出した方はもちろん褒められたいし、期待する成果と違っていても、その違いについてコミュニケーションをとれれば納得できますよね。

依頼した方はもらった成果を自分の中でOKかNGかを判断し、NGの場合のみ端的に伝えて修正してもらうというケースをよく見かけますし、そういう対応をされた経験が私もあります。

だから私は常に任せた仕事に対して何かしらのFBをするよう心がけています。

FBがあることにより、人として認識されていると感じることができるのです。

ただ、なんでも感じたことを言えばいいのではなく、成果に対する期待との差に応じて伝えることは変えた方がよいと思っています。

特に期待と異なる場合についてはなぜそう思うのかを伝えて、お互いにその違いを理解するまで会話すると違いの原因が分かるので、再発防止に確実につながります。

プレッシャーをPJメンバに転嫁しない(チーム全体でシェアする) 

 PMは顧客や協力会社、社内の上層部、PJメンバなど多くのステークホルダーがおり、プレッシャーを受けやすいポジションと言えます。

そのため精神的に辛いこともよくあります。

私がみてきた中では、それをそのままPJメンバに転嫁する人や自分で抱え込んでしまう人がいますが、どちらもダメです。

それぞれについて理由を説明していきます。

PJメンバに転嫁するのがダメな理由は、プレッシャーに答えられない場合にそのメンバがプレッシャーを解放or共有する先がないためです。

例えばあるPMがあるメンバに仕事を依頼する際に、「期限内にこれだけの成果の出してくれないとPJ全体のスケジュールが遅れるのでお願いしますね!」と過剰にプレッシャーをかけたとします。

そうすると、そのメンバはPMをチームの一員としてみられず、PMにアラートをあげづらくなるのです。

結果的に、仕事の質が下がるか突然遅延してしまうかのどちらかを招いてしまいます。

逆にPMがプレッシャーを抱え込むことがいけない理由は、PJメンバに適度な緊張感を持たせることが出来ないからです。

そのPJに対する周囲からのプレッシャーを共有することにより、適度な緊張感を持たせると、同じ窯の飯を食う仲間ではないですが、メンバ全員が同じ状況下に置かれているように感じます。

そうすると自然と一体感が生まれ、チームワークが高まります。

実は、私は元々抱え込んでしまう方でした。

当時担当していたPJでは、あまりにも顧客からの評価が良くなく、しばらく辛い時期が続いたのですが、抱えきれずにメンバに状況を全て打ち明けました。

その結果、次第にメンバからの提案が増えチームワークが高まり、状況は改善していきました。

まとめ

改めてではあるものの、以下の4点が私がPM業務をする中で気をつけていることになります。

  • 仕事を依頼するときに必ず目的を伝える
  • 任せた仕事を途中で引き取り、他の人に依頼したり自分でやったりしない
  • 任せた仕事は必ずFBする 
  • プレッシャーをエンジニアに転嫁しない(チーム全体でシェアする) 

これらに共通するのは自分が考えていることや感じていることを正しく伝えること、伝えた場合にどう感じるかを想像することです。

どんなに忙しくても一緒に仕事をする仲間には思いやりを持って、誠実に接することが大事だと思っています。

これを意識していれば自然とお客様から喜んでいただけるような成果を出せると信じています。

最後に

最後まで読んでいただきありがとうございました。

共感した方は是非シェアをお願いします!

また私はこう考えているというご意見あれば参考にさせていただきたいです!

コメントお待ちしてます。

AI業界における2025年に生き残っている会社と人材とは。

直近の業界動向から5年後に生き残っていそうな会社と人材の特徴を考えてみました。

AI業界やAIの開発フローを知っているという方は「AI開発における各社の立ち位置と直近の動向」以降を読んでください。

記事の信頼度

元々はSIerでリーダ業務をしており、今はAIベンチャーでプロジェクトマネージャーをしています。

1年半程度AI業界におり、歴は浅いもののAI業界の動向は分かってきたつもりです。

対象読者

  • 就活生
  • AI業界(基本的にはAIベンダー側)に転職を考えている人
  • AI業界に投資を考えている人

得られる情報

今のAI業界がどのような状況で今後どういう会社や人材が生き残っていくかを考えるヒントが得られます。

AIに幻滅?日本における AIに対する認識とは

ガートナー社の日本におけるテクノロジーのハイプサイクル 2019年によるとAIは幻滅期に入ったと評価されており、各業界リーダーによるAIの実証実験は一巡し、AIのケイパビリティが見えてきたと言えるでしょう。

つまり、これから本格的に社会実装が進むことが予想できます。

ガートナーのマネージング バイスプレジデントの長嶋 裕里香は次のように述べています。「2019年現在、例えば『モノのインターネット』『人工知能』『ブロックチェーン』は、幻滅期に位置付けられています。

ガートナー、「日本におけるテクノロジのハイプ・サイクル:2019年」を発表 – デジタル・ビジネスを推進する上で特に注目すべきテクノロジと そのトレンドを明らかにhttps://www.gartner.com/jp/newsroom/press-releases/pr-20191031

実際に、こちらに掲載されている記事のようにAI導入が始まっている業界は多岐に渡り、導入検討が行われていない業界の方が少ないと言えるかもしれません。

業態業種別-AIの導入活用事例-/記事一覧

AIsmiley
https://ai-products.net/category/case-study/

AI業界の会社は4種類に分けられる

AI業界と言っても、先述の通り無数に会社があるので、どのような会社があるのかを説明したいと思います。

AI業界マップ(カオスマップ) を見ると分かる通り、まさにAI業界はカオスです。

AI専門メディアの「AINOW」が2017年9月5日に発表した、B向け人工知能関連ビジネスを展開する会社をまとめたカオスマップ

これだと分からないので、私の経験から4つに分けてみました。

  1. AI開発を効率化、高速化するライブラリやapiを提供するプラットフォーマー(PF提供会社
  2. AI開発を一般化するアプリケーションを提供する開発会社(AI開発アプリ提供会社
  3. 顧客向けにカスタマイズしたAIを構築するAIベンダー(AIベンダー
  4. 自社でAIを構築し、AIを組み込んだ製品を提供する開発会社(AI自社開発会社

世の中のAI関連会社というのはだいたいこれらのどれかorいくつかに属しています。例えばAmazonは1と4に属します。

AI開発とは?4フェーズからなるAI開発

AI業界の外観は分かったと思いますが、実際にどうやってAI開発をするのかはまだ分からない方もいると思います。

そこで実際のAI開発のワークフローを基に業務内容を簡単に紹介します。詳細は以下の記事に分かりやすくまとめられているのでそちらを参照ください。

(1)構想フェーズ

課題の選定、ROI検討、人員体制構築、社内承認獲得

(2) PoCフェーズ

機械学習の仮モデル構築、ROIやスケジュールの妥当性検証

(3) 実装フェーズ

モックアップモデル最終化、設計、開発、テスト

(4) 運用フェーズ

保守、点検、現実世界の変化に合わせたチューニング

https://ledge.ai/ai-development-project/

各フェーズにおいて上記のような内容を行います。

ちなみに、私の実務経験から補足すると解けそうな課題で、ROIを出すことができ、データが豊富にあるというテーマが理想ではあるものの、少なくともこれらの内1つに大きな課題がある場合が多いです。。。

それでも何かしらの代替案で無理やりPJを成立させる努力をするのがプロジェクトマネージャーの仕事だったりします。笑

AI開発における各社の立ち位置と直近の動向

AI業界の各社は先述の4つに大別されますが、それぞれが専門とする範囲は異なっています。

3(AIベンダー)、4(AI自社開発会社)の会社はこのすべてのフェーズを担当します。

一方1(PF提供会社)は(2)PoCフェーズの汎用的部分をライブラリやapiとして提供しており、2(AI開発アプリ提供会社)は(2)PoCフェーズのモデル構築部分をアプリケーションとして提供しています。

図解した方が各社の立ち位置が分かり易いと思うので、下図で説明します。

上から下に向かって、技術の汎用性が高くなっていきます。逆に下から上に顧客のビジネスとの関連度合いが高くなっていきます。

AI業界における各社の立ち位置

各レイヤーをどの会社が専門としているかというと、PF提供会社はLibrary,APIのレイヤーを主に専門としており、AI開発アプリ提供会社はMethod(Application)のレイヤーを専門としています。

AIベンダーはMethod(Application)レイヤー~Purposeレイヤーまで、AI自社開発会社はMethod(Application)レイヤー~Customerレイヤーまでを担当しており、PF提供会社のライブラリやapiを活用してアプリケーションを開発しています。

PF提供会社の対応範囲は変化してきています。

例えばAmazonはSagemakerというSaaSを提供しており、上述の特徴抽出と後処理以外のほとんどを自動化できるような機能を備えています(詳細は以下参考記事参照)。

ASCII.jp×TECH、「平均的な開発者にも機械学習の力を」―AWSジャシーCEO基調講演

https://ascii.jp/elem/000/001/998/1998309/
AI開発関連会社の方向性

これを上図で示すと、PF提供会社は対応範囲をLibrary,APIレイヤーからMethod(Application)レイヤーまで拡げていくようなイメージになります。

一方DataRobotのようなAI開発アプリ提供会社もすこしずつ対応範囲を拡大し、Method(Application)レイヤーの一部を対応範囲としていましたが、横に範囲を拡げていっています。

また、ある業界に特化したアプリケーションへと変貌しているものもあります。(上図の右上矢印のような動き)

これまで各会社の棲み分けが行われていましたが、その境目はどんどん曖昧になり、PF提供会社が業界を独占しつつあるとも言えます。

2025年におけるAI業界の予想。会社と人材は二分される。

2025年に生き残る会社

GoogleやAmazonのようなプラットフォーマーは汎用的な(自動化、ルール化が出来る)要素は全て、現状提供しているサービスに追加していくでしょう。

しかし、顧客によって要求が変わる部分までは手をつけないでしょう。

なぜなら顧客毎にカスタマイズするということは顧客毎に工数がかかり、利益率が低くなってしまうからです。

このカスタマー向けのカスタマイズが必要な部分が上記会社のカバーしきれない領域であり、マーケットが残されている領域と言えます。

PF提供会社がAI開発のハードルをどんどん下げていくと、AI開発が出来ることの価値は下がっていき、何が課題で、解決方法は何が最適かという課題解決アプローチが重要になっていくと考えます。

これまでは課題を理解しているのがカスタマー側で、解決方法を知っていて、解決方法としてのAIを開発するのがAIベンダー側ということが多かったですが、AIの認知拡大とAI開発の障壁が下がっていっていることからカスタマー側によるAI開発がすすんでいくでしょう。

伊勢神宮の鳥居前町にある創業100年を超える老舗料理店「ゑびや」がその良い事例です。

伊勢神宮の鳥居前町にある創業100年を超える老舗料理店「ゑびや」は、営業戦略づくりにAIをフル活用し、2012年からの6年間で売上高を4.8倍に伸ばした。

生成発展、神様も驚くAI経営 来客予測で食品ロス激減
https://change.asahi.com/articles/0018/

このように、今後はPF提供会社とAI自社開発会社のこっていくのではないかと考えます。

2025年に生き残る人材

会社に求められることから人材に求められるものも見えてきます。

上述の通り、会社はPF提供会社とAI自社開発会社に2分されていくと考えます。

プラットフォーム提供を行う会社に入りたい場合はAI、ITにおけるある分野のエキスパートになることを目指すべきでしょう。

そうでない場合はある分野(AI、IT以外)のエキスパートでありながらもAI全般の素養をもっていることが求められるので、自分がエキスパートになりたい分野の知識を身につけながらもAI全般についてもオンラインコースや書籍等で身につけることをおすすめします。

まとめ

AI業界はPF提供会社とAI自社開発会社に2分され、それに伴い求められる人材もAI、ITにおけるある分野のエキスパートと課題解決対象分野のエキスパートの2種類に分かれていくでしょう。

いずれにせよ、ある分野のトップになるつもりで日々勉強を続けていくことが必要と思います。