【CTO×CIO対談】AI時代のエンジニアは、ストラテジストであるべし|株式会社カンリー 公式note
こんにちは! カンリーでエンジニア採用を担当している宮本です。 ボードメンバーのみなさんに、"カンリーの未来"について話してもらう企画も、いよいよ第4回目。残り1回となりました。 ...
https://note.com/canly/n/nf9062a80e2a4
※このストーリーは、noteで発信した記事を転載しています。
こんにちは! カンリーでエンジニア採用を担当している宮本です。
ボードメンバーのみなさんに、”カンリーの未来”について話してもらう企画も、いよいよ第4回目。残り1回となりました。
今回は再度、CIO萩野に登場していただき、「目指すエンジニア組織」についてCTO小出とディスカッションしてもらいました。どんなエンジニア組織にしていきたいのか、また、エンジニア一人ひとりにどのような成長機会を提供したいと思っているのか—組織をリードする2人が何を考え、何をしようとしているのか、ぜひ、ご覧ください。
▼前回のCTO小出・CTO萩野の対談記事は、以下リンクよりご覧いただけます
執行役員CTO 小出 幸典
慶應義塾大学大学院修了。アクセンチュア株式会社を経て、2014年7月に株式会社Gunosyへ入社。メディアプロダクトの配信アルゴリズム開発や、全社データ基盤構築等を担当し、2019年7月にCTOに就任。2022年より業務委託としてカンリーの事業に携わり、2024年9月に執行役員CTOに就任。エンジニア部を管掌。
▼参考記事:カンリーにCTOとしてジョインしました
専門役員CIO 萩野 貴拓
高校、大学時代から起業やテックリードを経験し、ビズリーチ入社後は、求人検索や研究開発部門の設立、AI技術の事業実装を推進し、同社最多の特許を出願。執筆、オープンソース活動の他、技術顧問やCTOとして多くの企業での支援実績を持つ。カンリーでは新規事業の立ち上げを経て、2024年に専門役員CIOに就任。小出とともにエンジニア部を管掌、主にHR領域のプロダクト開発をリード。
▼参考記事:【カンリー CIO就任】信念をもって事にあたり、 世界観をもとに業を成す〜最高の仲間と、歴史を作ろう。〜
宮本:
すごくざっくりした質問になってしまうのですが、理想のエンジニア組織についてお聞きしたいです。
萩野さん(以下、萩野):
事業と人の成長がシンクロしているのが、理想ですね。
小出さん(以下、小出):
事業が成長すると組織が拡大して、新しいポジションが生まれる。すると、キャリアアップの機会ができて個が成長する。そうなると良い人材が集まってきて、それによってさらに組織が良くなっていく、みたいな感じですかね。
萩野:
ですね。この循環を作るためには、職種や部門といった境界線をできるかぎりなくしていくことが必要なのかなと思っていまして。エンジニアもセールスもカスタマーサクセス(以下、CS)もプロダクトマネージャー(以下、PdM)もお互いに積極的に関わり合える環境が重要だと考えています。
小出:
今も連携してはいるものの、垣根を取っ払って、より話せるようになるといいですよね。加えて、エンジニア自身が積極的に情報を取りにいく姿勢も大事だと思います。こうしたスタンスで、お客さまと接する機会の多いセールスやCS、PdMとコミュニケーションを取ることで、お客さまの課題やニーズに対する解像度がぐっと上がって、良い意思決定ができるようになるんじゃないかなと。
宮本:
エンジニア自身にとってどんなメリットがあるのか、もうちょっと具体的に教えていただけると嬉しいです。
小出:
たとえば、「この機能を作るとどんなインパクトがあるのか」や、「売上がどのくらい増えるのか」といったことがわかるようになります。また、開発した機能がお客さまの課題を解決していることを目の当たりにすれば、自然とやりがいを感じられるようになると思うんですね。
萩野:
逆もしかりですよね。セールスやCSがエンジニアの状況だったり、テックで何ができるのか、つまり技術の部分を深く理解することで、お客さまに対して適切な期待値を設定できるようになるのかなと。
勝手にまとめてしまうと、エンジニアとビジネスサイド、お互いが理解を深めていくことで、サービス全体として質の高い価値提供をしていきたい、ということですね。
小出:
その通りだと思います。もう少しだけ上段の話をすると、カンリーでは「店舗経営を支えるインフラ」を目指していて、店舗運営に関わるあらゆる業務においてDXを推進しようとしていますよね。
「DXを推進する」ためには、どんな業務をしているのか、どんなビジネスプロセスなのかを理解して、本質的な課題が何かを見極める必要があるんですね。エンジニアもこういった視点を持つことで、どんな機能が必要なのかを能動的に考えられるようになり、結果、プロダクトの価値を高めていけると考えています。
萩野:
本来の目的に立ち戻ってみると、当たり前の話なんですよね。プロダクトはあくまでも手段であって、僕たちが提供しているのはお客さまの課題解決なんですから。
小出:
今の話で思い出したのですが、この前、友近さん(CPO)に「お客さまがカンリーを使ってくださっている理由」を聞いてみたんですね。そうしたら、プロダクト単体ではなくCSも含めたトータルに優位性があるとお話しされていて。トータルのサービスを作ろう、売っていこうとするのであれば、お客さまに対する理解、解像度は持ってないといけないですよね。
さらに言うと、僕らってDXというワードをよく使うじゃないですか。このDXには、ワークプロセスやビジネスプロセスのリデザインが含まれてると思っていて。トランスフォームするためにはやっぱり、どんな業務をしていて、どんな課題があるのかを知らなくちゃいけないのかなと。
萩野:
DXにはいろいろな定義がありますが、一般的には、①デジタイゼーション、②デジタライゼーション、③デジタルトランスフォーメーションの3段階と言われていますよね。
①のデジタイゼーションは紙でやっていたことをWebでできるようにしたり、自動化したりとデジタル形式にすること。②のデジタライゼーションは、外部環境やビジネス戦略も含めたプロセス全体をデジタル化すること。そしてカンリーが目指す③のデジタルトランスフォーメーションは、デジタル技術を活用して新しい価値を創出し、競争上の優位性を確立させることを指しています。
具体的には、ビッグデータなどのデータとAIやIoTを始めとするデジタル技術の活用により、新しいプロダクトやサービス、新しいビジネスモデルを生み出すことで、ネットとリアルの両面での顧客エクスペリエンスを変革していくこと。わかりやすくいうと、デジタルを活用して新しい価値を創出していきましょう、ということです。
①を超えるにも課題がたくさんあって、ここを乗り越えられる企業は多くはありません。そうなると、③まで達成できる企業は、数少ない限られた企業になってしまっているというのが現状だと思います。エンジニアが担うべき責任は、デジタイゼーション、デジタライゼーションではなく、真の意味でお客さまの業務、事業を変革することにコミットしなければらないのですよね。
ちょっと発散しすぎてしまったので、話を戻しますね。組織として、また、エンジニア一人ひとりが取り組むべきなのは、お客さまの解像度を上げることだと考えています。お客さまがどういう価値を作ろうとしていて、その中の何が課題で、課題をクリアするためにどういう意思決定をしなくてはいけないのか。ここを理解していないと、プロダクトを作るだけで終わってしまい、本当の意味でのお客さまへの価値提供ができないまま終わってしまう気がします。
宮本:
エンジニアがお客さまの課題を理解して、どんな価値提供をしたらいいのかを考えたり、主体的にお客さまや事業に貢献できるようにするには、なにが必要なのでしょうか?
小出:
さきほどもちらっと触れましたが、エンジニアがPdMやセールス、CSと密にコミュニケーションが取れるようにするのが一番大事な気がしています。そして、こうした環境を整えるのが僕らのミッションですね。
萩野:
すでにいくつかのプロダクトで定期開催しているユーザー会を、すべてのプロダクトで徹底していくといいかもしれませんね。実は、カンリーのユーザー会は、すごくユニークでして。お客さまと文字通り、膝と膝をつき合わせて、機能改善や新規機能についてディスカッションをさせていただいているんです。
プロダクトに関わるメンバーみんなが参加して、ユーザーであるお客さまと直接、議論する。エンジニア自身がユーザーの生の声に触れることで、事業課題への理解が大きく進むと考えています。
小出:
もうひとつ別の観点として、エンジニアがPdM、セールス、CSと対等に話すには、環境や仕組み以外になにが必要なのか、ということを最近よく考えているんですね。
エンジニア自身は、技術的負債などに向き合う中で「リファクタしたほうがいい」とか「将来を見据えてこういう修正を入れたほうがいい」みたいな課題を感じていて、それをなんとかしたいとも思っているはずなんです。でも、どうやって説明したらよいかわからず、困っているんじゃないかと。対等に話すには、共通言語が必要ですからね。
たとえば、「技術的負債が溜まった結果、こういう影響が出ていて、その影響に対してこのぐらいコストを払えばこの影響を解消できる上に、事業やお客様にも、こういうポジティブな効果が生まれる」といった感じで伝えられるようになると、いいのかなと。
萩野:
要は、ストラテジーという共通言語を持っていないと、同じ土俵で話せないということですよね。基本戦略とかでよくある図(※図1参照)だと、いわゆるMVVが上にあって、その下にストラテジーがあります。ストラテジーの下にあるストラクチャーは、セールスやCSといった役割のことで、お互いにここの理解はあるし会話もできる。それに対して、事業という軸で話そうとすると、ストラテジーで会話するしかないんですね。
(図1)
じゃあ、ストラテジーってなんなのかというと、問題の設定と問題を解く、または、ゴールに辿り着くためのリソースの分解のことなんですね。セールスやCSは、このゴールに近いんです。たとえばセールスなら、今月の売上目標を分解したKPIで会話ができます。一方、エンジニアの場合は、もうひとつドリルダウンしたところにKPIがあるので、ゴールからもストラテジーからも距離が遠くなってしまう。
こうした状況でストラテジーについて話すのは、なかなかむずかしいですよね。そこで、ゴールに近いところで会話をする機会や仕事を、意図的に増やしていくことが必要なのではと思ってます。
萩野:
たとえばこの1週間、ぼくは1行もコードを書いていないのですが(笑)さっきGithubを見たらDevinが1万行ほどのコードを書いてくれていて。AIがコードを書けるようになってきた今、プログラミングを上手くできるとか、きれいに書くみたいなことは、あまり意味を持たなくなってきているのではないかと感じています。
小出:
よく言われていることですが、コーディングなど人から指示を受けてやるタスクは、AIがやってくれるようになりますからね。タスクの分解と指示ができれば、AIで自分のバーチャルチームを組成して作業を任せる、といったこともできてしまいます。メンバーひとりひとりにAIの部下ができるイメージですね。
そして、おそらくは「タスクを分解する」というところも、すぐにAIに取って代わられる気がしてます。
となると、萩野さんがおっしゃっていたように、よりストラテジーに近いところにいって、抽象的な問題に立ち向かえるようにならなきゃいけないですよね。
萩野:
おっしゃるとおりだと思います。
そうなるとまずは、AIを使う側になることを目指すべきですよね。最近「コード書くの禁止」とする会社を散見しますが、極端なことを言えばアリなのかなと。今後、プログラミングが徐々に人からAIに置き換わっていくのが確実な中では、これくらいの強制力を持たせてもいいと思っています。
その上で、課題設定や事業戦略など、正解が決まっていない抽象的な物事を考え、実行できるようになるといいですね。そのために、お客さまやPdM、セールス、CSなど社内のステークホルダーと直接、コミュニケーションを取っていくことが必要になってくるわけですね。
小出:
そこでいうと、戦略や課題をタスクに分解できる能力も必要ですね。これができれば、AIを活用して、より効率よく、高いレベルの問題解決ができるようになるはずですから。
理想は、エンジニア全員がストラテジーで会話できるようになることですかね。そのためにエンジニアには、事業に興味を持って、事業を理解して、ほかの職種ともストラテジーという共通言語で話せるようになってほしいなと。そして、そうできるように、僕たちが全力でサポートしていきたいと思ってます。