シェア
はてブ
近い将来、エンジニアに求められる役割やスキルが大きく変わるのではないか―― 近年の急速なAI技術の発展に伴い、そういった考え方が強まっていく一方、依然として先行き不透明な側面もあります。今後、プロダクトやその開発にAIが浸透していくなかで、エンジニアのあり方とはどのように変わっていくのでしょうか。
今回は、2012年に創業し、ChatGPTの登場以前からAIの社会実装に取り組み続けている株式会社PKSHA Technology（以下、PKSHA）にインタビュー。同社の執行役員兼VPoEである松江宏樹さんに「エンジニアの役割や求められる能力の変化」「プロダクト及び社内活用の仕方」などを伺いました。
生成AIは万能ではなく、便利なツールのひとつ
――生成AIが登場したことで、エンジニアの役割はどのように変化してきたのでしょうか。
我々PKSHAは、アルゴリズムを活用して社会の課題を解決している会社です。近年の生成AIの隆盛前からAIを活用しているわけですが、生成AIにより、課題解決の選択肢が増えました。エンジニアとしては、生成AIも手段に含めて課題解決を考える役割が増えましたね。
また、エンジニアの役割には、プロダクトを作る以外に新しい技術のキャッチアップがあります。生成AIの登場以後は進化のスピードが速いため、開発をスムーズに進める工夫もこれまで以上に考える必要が出てきています。
生成AIの特徴として、ただ単に「使えるツールが増えた」だけでない部分もあります。ひとつは、間違った情報を生成するハルシネーションが起こること。人間のように回答できるからといって、「生成AIを入れればすべて解決する」というのは大きな間違い。例えば、ユーザーからの「解約方法を教えてほしい」という問い合わせに対して全く違うやり方を教えてしまう場合があるんです。実際のサービスでそういった間違いがあると大問題なので、特に気を付けているポイントです。また、内容によっては生成AIを導入したことで従来より余計に時間やコストがかかる場合があります。
生成AIは万能ではなく、あくまで便利なツールとして捉えています。我々としては、やるべきことがガラリと変わったわけではなく、考えたり、気を付けたりするポイントがいくつか増えたという認識なんです。
――開発をスムーズに進める工夫が必要というお話でしたが、新しいツールが出るスピードもアップしている分、大変さがあるのではないでしょうか。
便利なツールが増えたので、キャッチアップして社内で活用するようにしていますが、とにかくスピードが速いので、新しいツールを使い始めたら、1ヶ月後にはさらによさそうなツールが登場することもある。進化を追いかける大変さは増しているかもしれません。ただその分、これまでよりも簡単に始められるケースも増えています。GitHub Copilotなどのチャットで依頼したらプログラムを書いてくれる機能は、普段話しているように使えばいいのでとっつきやすい。ただ、複雑なタスクを依頼すると期待通りに生成されないなど、実務で活用するには慣れが必要な部分もあります。
情報をキャッチアップするために、私自身は、MicrosoftやOpenAI、Anthropic、Googleなど、生成AIのモデルを提供する企業が発信している公式な情報は英語、日本語問わずよく見ています。また、社内のメンバーもよくチェックしていて、新しいツールが登場すると社内Slackの専用チャンネルで知らせてくれるので、それで知ることも多いです。
生成AIの使い方に工夫を凝らす
――ツールが増えたことによるエンジニアの役割の変化はあるのでしょうか？
開発に役立つ強力なAIツールが増えたことで、プログラムを書く部分を支援してもらえて、プログラミング能力を底上げしてもらえる感覚はあります。コードを書く力が重要なことに変わりはないものの、その上流の部分で「何を作るべきか」「何の課題を解決するべきか」と考え、判断して、AIに依頼する方向を定める力がより大切になります。
それに伴い、特定の開発に使うフレームワークやプログラミング言語を使いこなす力は、これまでよりは優先度が下がっていると言えるかもしれません。フレームワークや言語にそれほど長けていなくても、AIツールの支援を受けられるからです。
その分、ユーザーが使いやすい、壊れにくい、といった観点で設計する能力が求められていくでしょうね。想像力はもちろんですが、過去事例の知識がその能力に関わってきます。
我々は過去にAIのソフトウェアを数多く提供しており、事例をたくさん持っています。過去事例を知っていると、課題に対するAIの活用方法や、活用した後のユーザーさんの体験などを思い浮かべやすくなる。そのために、社内で過去事例を一覧にして共有したり、定期的に勉強会を開催したりしています。「AIってこういう風に使えるんだ」という知見が増えると、新たな課題でも活用できる機会が増えていきますね。
社内にそういった情報が少ない場合でも、プレスリリースや他社製品の新機能などを見ることで課題解決のヒントになったり、課題解決の種が見つかったりする場合もあります。例えば、生成AIで増えたのは、情報の要約や構造化の部分。議事録ツールでは、ただ書き起こすだけでなく会議の要点を書き出してくれたり、要約をしてくれたりする。Perplexityというサービスでは、情報を検索するといくつものWebページを見て、それをまとめたものを出してくれます。情報を的確に加工したり抽出したりするサービスは非常に増えていますよね。そのあたりから課題解決の糸口を見つけることもできると思います。
社内でも、プログラミング以外にも生成AIを活用していて、そのひとつが例に出した議事録ツールです。これまでは頑張ってメモを取っていましたが、メモを取らなくても要点や次のアクションがわかるので、生産性が向上しています。
新しいツールが出てもすべてを使いこなすのは無理なうえ、「これまで通りのやり方がいい」と考えてしまう“引力”は誰にでもある程度あります。それでも、自主的に試して感想を共有してくれる人がいたり、人に依頼して試してもらったりと、チーム全体で促していく心がけも大切ですね。
プロダクトづくりではHuman in the Loopを念頭に入れる
――社内の開発環境について教えていただきましたが、プロダクトづくりで大切にしている仕組みなどはありますか。
先ほども少し申し上げましたが、AIは精度が100%ではないところがあります。人間と一緒でミスしたり、間違えたことを言ったり、答えるのに時間や費用が掛かったりします。
精度については、新しい情報に対してAIが答えられない場合、人間が教えてあげる仕組みが必要です。間違えたり誤作動したりした際に、人が介入することで次から答えられるようになります。AIと人が一緒に改善していく、ヒューマンインザループ（HITL：Human-in-the-Loop）のような考え方です。
そのために、人がフィードバックできる仕組みを作るのは、私たちが提供するシステムで常に大事にしているポイントです。AIが絡まないソフトウェアは基本的にはずっと同じ動きをするはずですが、AIが絡むと「教えればできるようになる」という現象がある。使えば使うほどよくなるという性質を前提にして、開発に取り組んでいます。
「人」というのは、サービス提供する企業側、つまり管理者の場合もありますし、その先のエンドユーザーの場合もあります。鉄道会社のシステムの場合なら、電車の運賃が変わる際に管理者が教える場合もあれば、電車に乗る人が「○○駅までいくらかかるか」と聞いたあとに間違っているとわかり「役に立たなかった」とフィードバックを返す場合もあります。これらを、企画段階、設計段階で組み込んでおかなくてはなりません。AIはあくまでも90点か95点くらいのものだと理解して、業務フローを構築していく必要があります。
このように、共に改善していくことを我々は「共進化」と呼んでいます。ソフトウェアは、人に教えてもらうことでこれまでできなかったことができるようになり、人はプログラム支援ツールを使うように、やり方をAIに教えてもらえる。そのように、お互いが進化していくという概念を大切にしています。
時間やコスト面についても、課題を見極める時点での判断が必要になります。例えば、簡単に文字起こしができるからといって、「社内全員の会話を書き起こそう」と考えてしまうと、コストがかかったのに書き起こしのドキュメントだけが増え、得られたメリットがよくわからない、価値を生み出せていない、という結果になりますよね。成果とかかるコストが見合うかどうか、事前に見極める必要があります。
そのために、見積もりや試算をあらかじめ出しておきます。例えば、業務時間を削減するためのシステムを提供するとして、1億円の費用削減になるとしても、システムに1億2000万円かけてはだめですよね。お客様に本当に価値が提供できる形をあらかじめ見極めています。
今後求められるエンジニアの3つのスキル・能力
――これまでのお話を踏まえて、AI時代のエンジニアにはどういう能力が求められるのでしょうか。
まずは、学習して成長し続ける力だと考えています。次から次へと登場する新しいAIツールをキャッチアップしていくのはもちろん、新たなツールを使うことで別の課題が生まれるケースもあります。技術だけでなく、ビジネスニーズも含めて学び続けるマインドセットは必要ですね。
学び続けることで生成AIや各種アルゴリズムの持つ特徴や、気を付けるポイントを把握しているからこそ、システムを設計・デザインしていく力が養われると考えています。課題を解決するために使える技術を理解して判断し、サービスを企画し、設計・構築していく能力が非常に重要になります。
2つ目は、コミュニケーションのハブになる力です。自分のスペシャリティから「染み出し」ていくというのでしょうか。エンジニアでなくても、簡単なプログラムなら書けるようになってきており、より境界があいまいになっています。エンジニアでない人がツールを使って簡単なものを作り、それを基に他のチームメンバーと会話していくような動きは、今後求められていくでしょうね。
エンジニアとしても、いちからデザイナーに任せていたデザインの部分を、生成AIに依頼して簡単なものを作り、それを基にデザイナーと会話をするなど、染み出しやすくなっていると考えます。
同様に、技術とビジネスの交差点に位置できる力はますます重要になっています。プログラムを書けるだけでなく、サービスを作るための構想やチームビルディングができ、プロジェクトやビジネスを進められる力が今後はより求められていくでしょう。
3つ目は、プロトタイプなどを通じて実験的なアクションができる力ですね。先ほどお話した通り、専門外でも専門内でも、プロトタイプを作りやすい環境ができています。例えば、これまではお客様のニーズを持ち帰って数週間かけてプロトタイプを作り、改めてフィードバックをもらう流れでしたが、今なら会議中にさっと作って見せられる場合もあります。その場で「これはちょっと違う」「こういうのが欲しかった」といったフィードバックが得られるので、スピードが圧倒的に速くなります。
能力というより行動習慣といったほうが良いのかもしれません。1人で長く構想するのではなく、できるだけ早く吐き出して周囲からフィードバックをもらい、直していくという姿勢が求められていると感じます。
――これらのエンジニア像は、PKSHAの求める像と一致していますか。もし違いがあれば教えてください。
基本的には同じです。ただ、我々は社会実装により重きを置いています。AIを目的よりも手段として捉えているので、求めるのは実現したいこと、解決したいことに目が向いている方ですね。また、周囲と協力しながら自走できる方。1人でできることには限りがあるので、メンバーと協業して成果を高められる人を求めています。
さらに、新しいAIツールの活用や、染み出した分野でのプロトタイプづくりなど、「必要だからやる」のではなく、「楽しいからやっちゃう」という方が活躍できると思っています。チーム内でも、コールセンターの方の支援として、「次の言葉を教えてくれる『耳打ちしてくれる君』とかあったらいいよね」と考えたり、僕も今取材していただいている中で、「この後すぐに原稿の下書きが生成されたらどうなるかな」など考えたりしています。「これがあったらおもしろそう」と、楽しんで妄想できる方がいいですね。
取材・執筆：栃尾江美
