AIの教師モデル開発や画像のタグ付けを目的としたBPO的なプロジェクトにはベトナムオフショアが向いている理由

AI vs 人間

AIは人間を超えるのか？などの質問をされることがよくある。シンギュラリティと呼ばれているが、超える超えないの単一線上で比較できるものではないと考える。たとえば、計算の速さだけでいうと人間よりも、はるかに早いと言える。

AI導入の両面性

とにかく労働人口の減少によって、機械化やAI化が急がれていると思う。すでに、画像作成や文章作成などは置き換わっている事例も多くみられるようになった。そんな中で、よくあるのが「AIで何かできませんか？」という問い合わせである。

AI時代のDX

DXという概念にも通ずる話だが、デジタル化するだけでは、いわゆるデジタル変革にはならない。ペーパーレス化ってやつだ。同じように、AIを使うことを目的としてしまうと業務に対して便益がない場合も多いようだ。したがって、AIを利用するということをDXと定義するのであれば、日常業務を整理して、どこをAIに任せるのかを検討することが大切である。

AI活用の極意

AIにも得手不得手があり、計算はもちろん得意だが、質問の仕方や指示の仕方で活用レベルは大きく変わる。プロンプトと呼ばれるものはコピーして使えるが、AIを活用しきろうとするならば、自分でプロンプトを考えれる必要がある。つまり、現時点では賢いAIなのではなく、使う側が上手に使わないとならない。

まとめ

AIの使いどころについて、多くは無理やり使おうとするため、AIを活用する場面でないことも多くある。また、ユーザー企業に関わらずシステム会社でもAIの活用は進んでおり、画像の生成やプログラミングの一部はすでに人間が行わなくてもよい段階にある。これから先もこれは加速することだろう。

相場の不在

フルスクラッチでのシステム開発に相場はない。相場とは商品が一般的に流通している商品など数が多い場合は、競争原理も働き、金額がある一定の範囲に収まってくるものである。

建築との差異

たとえば、一戸建て建築であれば、建物の規模と資材、それに加えて職人の人工で金額が決まる。フルスクラッチのシステム開発は、つまり極めて特殊な特注品を作るようなものであるため、システム開発に相場という概念が基本的にはないのである。

人件費の実態

システム（ソフトウェア）は一戸建てのように、基本的には材料費はかからない。システム開発の費用のほとんどは人件費である。大工職人の人工と同じように人月単価と呼ばれるSE1人が1ヶ月働く金額で相場を知ることができるのである。

工期の変動

建物を建てることと比べるとシステムやソフトウェアは無形の物となるため、1ヶ月の労働力を推し量ることは困難である。個人のプログラミングの早さによって、納期が早くなったり遅くなったりするのである。

まとめ

SEは過去のプロジェクト参画実績から、同じようなプロジェクトに何度も参画していれば手練れでスキルが高いと評価される。システムに関わる人材の評価が困難な点は、プロジェクトに参画する経験値と、本当の意味でのスキルが比例するわけではないことである。本当の意味でのスキルとはプロジェクトを成功させられるかどうかを指すのである。

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。