サイト内を検索

Software Design編集長対談:ココネが考えるものづくりとエンジニアキャリアパス

ココネでは2023年より1年間、技術者のスキルアップのための総合誌である、Software Designへ記事を掲載させて頂きました。2024年4月号がシリーズの最後の掲載となりましたが、完走を記念し、Software Designの編集長である吉岡様と、ココネの現CTO・元CTOの2名での対談を行う運びとなりました。「エンジニアリングとデザイン」といったココネの話から始まり、生成AIやエンジニアのキャリアパスなどにも触れ、非常に有意義な時間となりました。本記事では、そのアツい対談の内容をお届け致します!

<参加者プロフィール>

◆ 吉岡 高弘 Software Design編集長(株式会社技術評論社)

金融系のSIerとして社会人をスタート。9年ほどシステムエンジニアに従事したのち、技術評論社へ入社。現在はSoftware Design編集部の編集長を務める。

◆ 倉 秀一(ココネ株式会社)

SIerとして社会人をスタートし、その後コナミ、グリーを経て2015年にココネへ入社。複数の新規サービスの立ち上げを経験。2023年7月にココネCTOに就任

◆ 髙山 大介(ココネ株式会社)

Web制作会社から社会人をスタート。様々な業界でフロントエンドエンジニア組織の立上げを経験し、2017年にココネへ入社。2022年7月にココネCTOに就任。

 

 

紙媒体だからこその信頼

ー1年間ありがとうございました。紙媒体を用いた連載でしたが、その感触や成果などは如何でしたか?また、紙媒体を選んだ理由とは何だったのでしょうか?

髙山 大介(以下、髙山):最初のきっかけとしては、ココネを知ってもらおうという会社全体の動きでした。どう魅力を伝えるかにおいて、雑誌における編集の力をお借りしたいという狙いがありました。

 

倉 秀一(以下、倉):ココネの中で、紙媒体に対する信頼感がまずありました。その中で、WEB+DB PRESSやSoftware Designといった歴史のある雑誌に掲載することが重要だと考えました。実際の効果として、前職以前の知り合いから声をかけられたり、初めてお会いする方からもお話に出して頂く機会がありました。「この雑誌に出てましたよね」というお声も多く、想像以上の結果となりました。

 

ー紙媒体への信頼感について、編集長としては、どのように考えてつくっていますか?

吉岡 高弘(以下、吉岡):紙媒体への信頼というのは意外にも感じました。Webだったとしても裏付けの取れた情報は発信することが出来るためです。Webには速報性がありどんどん新しい情報を出してゆきますが、一方で月刊誌は企画から含めると2ヵ月くらいかけて制作をします。逆に言えば2ヶ月くらいの期間で内容の検証などに時間をかけることができます。特にSoftware Designについては現場の方に執筆頂いており、このような積み重ねが信頼感に繋がっていると感じて頂けるのかもしれません。

「ココネが考えるものづくり」エンジニアリングとデザイン

ーあらためて、ココネはどういう組織や、メンバー構成でしょうか?

倉:お客様に触れていただいているサービスが中心となります。ポケコロ、ポケコロツイン、リヴリーアイランドが中心になり、そこにはクライアントエンジニアやサーバーエンジニア、UIデザイナー、モーションデザイナー、アイテムデザイナー、プランナー、プロモーションなど様々な職種が一緒に仕事をしています。新規サービスについては、10〜20人規模でフットワーク軽く進めています。それらを支える横軸の横断開発組織として、インフラ、ビリング、Web、分析などスペシャリスト集団がサービス側を支援しています。こうした、縦と横の組織で成り立っています。ココネが他の会社と一番違うのは、正社員のデザイナーの数が4割を超える点です。他の会社だと、外部に発注していたり言われたことをやるケースが多い印象もありますが、ココネはデザイナーから「こういったことをやりたい」という話が出るところから始まることが多いです。「これが素敵なんじゃないか」「これが可愛いんじゃないか」といったところから始まることが特徴的、かつ面白い部分だと思います。ゲームを作るのとは全く違い、どのように感性をカタチにしていくか、が重要になります。ここが他の会社との差別化、強みになっています。これらを受け止められるような開発組織にしたいです。

ーエンジニアはどのくらいの割合でしょうか?また、技術に詳しいとは限らないケースがあるデザイナーさんから、エンジニアが思いつかないような難易度の要望がくることが特徴的ではと感じます。

倉:エンジニアは2割くらいです。

 

髙山:実際にデザイナーの方からのほうが、ココネの知名度はあります。エンジニアは知名度がまだ少なく、こうした割合なのかもしれません。

 

倉:デザインドリブンです。頂いた要望に対して、どうすれば出来るのか、と受け止めることから始めます。そもそも出来るんだっけ?ということもありますが「できない」とは言わず、受け止めたあとに、何をやりたいのかなどの話を聞いて行きます。

 

吉岡:新しい技術を積極的に取り入れる風潮がある、というお話が連載の中でも何回かあったと記憶しています。こういったデザイナーさんの要望に応えるために、新しい技術を取り入れているのでしょうか?

 

倉:両軸あると考えています。もちろんデザイナーのために技術を取り入れるという面もありますが、エンジニアの私たち自身のためにも新技術を取り入れないと、という文脈もあります。裁量が大きく、色々なところで新しいものが産まれるようなチャレンジが出来ると良いと考えています。

ーエンタメ領域においてβ版という概念はありますか?また、サービスを幅広い世代にご利用頂いていると、その目線合わせも重要に感じます。

倉:スモールスタートで届けることはします。例えばポケコロツインは最初は課金要素すらない状態で「2人居る」というMVPを届けるようなこともしていました。既存のサービスとしては期間限定という形で反応を見ています。うまくいったら定常的な施策にしていく、といった形です。

 

髙山:β版のサービスを出して、ダメだったら引っ込めるみたいなことはしていないですね。

 

倉:世代について、遊び方も10代と30代で違ったりします。時には世代ごとに、違うご意見を頂くことがあります。とある方達には好評でも、とある方達には不評、ということはあります。そういう時は「これは必須なものではない」といったメッセージにすることが多いです。新規プロジェクトですとまた違う割り切りはするかもですが、既存のサービスだと長く遊んで下さっているお客様がいらっしゃいますので、そこを蔑ろにすることは絶対にしません。

 

ー技術の採用基準について、それぞれ新旧CTOのお二人はどのようにしていましたか?ボトムアップだった、トップダウンだった、などあれば教えてください。

髙山:現場の声は大事にしてました。新規サービスを増やしていく中で、また1から作ることがないようにモジュール化していこうというミッションは出しましたが、それをやってもらうのは現場にお任せしました。その他、Flutterを使っていくという決定はしました。

 

倉:GitLabからGitHubへの移行は大きな決断としてトップダウンで行いました。一方でAWSの中でどのサービスを使いたい、といった話は現場から上がってきます。普段開発に従事しているメンバーの方が余程詳しかったりしますので、課題解決は現場のエンジニアにお任せしています。実際に手を動かしていく人たちの話を取り入れていますが、利用する言語を揃えたり、同じものを作ろうとしていないか、といったところは調整はしています。クライアントはUnity、サーバーはGo言語を利用する、といった形です。

 

髙山:大きなアドバイスをするくらいですね。あとは、メンバーへの信頼が重要だと思います。

 

CTOのローテーション、エンジニアのキャリアパス

ーCTOのローテーション、キャリアパスについて、お二人はどういう経緯で今に至っておりますか?また、一般的にはCTOは次のステップとして他の会社へ行ってしまうケースも多いかと思います。社内に戻る、というのが特徴的に思えます。

髙山:まず入社したあとはフロントエンドチームをチーム長として担当し、そのあとVPoEや開発本部長を経てCTOとなりました。ちょうど入社した時は倉がCTOをやっていました。そのあと数名のCTOを経て私がCTOになっております。他社さんと比べると、CTOが変わる頻度が高いことは特徴だと思います。移り変わりが早い業界において、次の大きなミッションをCTO自身が担うことが多く、元々Webの強みがあった私は、Web関連で新たな技術を研究開発するために交代に至っています。

 

倉:最初にCTOをしていた時は、まだポケコロのみが事業の中心となっておりました。2本目の柱が欲しい、ということで新規プロジェクトを世の中に出すミッションがあり、ポケコロツインやリヴリーアイランドの開発を牽引しました。

 

吉岡:CTOが変わるタイミングは、社内を改善するタイミングでもあると思います。CTOが変わる頻度が高いと、その分、改善も早く回ったりするものでしょうか?

 

髙山:はい。今回、倉に交代した時に大きく開発組織が変わりました。自身の時は、CTOが全部やる「何でも屋」になってしまっていましたが、そこがシステム化されている印象です。整備された今、CTOをやってみたいですね(笑)

 

倉:組織規模に応じて求められることは変わるため、やる範囲や内容も変わってきます。ちょうど組織が増えきったタイミングだったので、システム化をすることができました。

 

髙山:CTOが変わる頻度が高いと、CTOに依存することが減り現場が強くなることはあるかもしれません。

 

倉:CTOであってもただの役割の1つであるという点は、強く浸透しているかもしれませんね。この点は、良いと思います。

 

吉岡:現場のエンジニアも異動の頻度が高かったりするのですか?

 

倉:頻繁ではありませんが、完全に固定化されている訳ではありません。入社すると、新卒でも中途でもココネの基幹となる事業で慣れて頂きます。その後に新規プロジェクトへの異動などはあります。

 

吉岡:メンバーからの希望での異動などもありますか?

 

倉:日頃からの1on1で収集した内容をエンジニアリングマネージャー組織の定例で共有をして、異動時に配慮を行ったりはします。

 

今後ココネで求めるエンジニア。エンタメのSRE。

ーどういった部分に注力しており、どういったエンジニアを求めていますか?また、悩みなどはありますか?

倉:SREエンジニアと、サービスセキュリティのエンジニア、グラフィックに強いエンジニアを求めています。悩みは、なかなか採用に苦戦している点です。

 

髙山:昔は会社の人数も多くなかったので1人が多くを担当していましたが、サービスの数も規模も大きくなり「特化した」専門性の高い人を求めるフェーズになりました。

 

倉:エンジニアブランディングがより重要になってくると考えています。ここだったら自分が活躍できるかもしれない、と思っていただくことが大事なのではと思います。また、ここ数ヶ月だと生成AI関係で例えば大学院などで研究テーマとして関わっているような方達を採用していかなければならないと思います。生成AIを「効率化」だけでなく、「サービスに取り入れる」ということを考えていく必要があるからです。ChatGPTでやりとりをしていると、誰かがそこにいる感覚になるかと思います。デジタルワールドにおいて、生成AIで「繋がっている」ように感じさせるなど、個々人、自分自身に対してサービスを提供してくれている感覚になると思います。感性をカタチにするココネと生成AIの親和性が高く、なるべく早くサービスに組み込みたいと考えています。

 

吉岡:雑誌作りにおいても生成AI関連で聞くのは、サービスに取り入れるにしても効率化という例が多かったです。個人に向けて「繋がっている」ように感じてもらうために生成AIを活用しよう、というのはとてもココネさんらしいと感じます。

 

倉:楽しみでもありますし、少々怖くもありますけどね。

 

ーメディアや雑誌から見て、ココネで取り組まれている分野に関して、媒体として取り上げたい部分はありますか?

吉岡:SREは編集部でも力を入れている分野で、2023年は特にCI/CD、Observability、クラウドネイティブといった話がSREと密接に関わると思い、多く取り上げてきました。読者の皆様にも興味を持っていただけました。ココネさんでは、SREに対してどのような課題をお持ちでしょうか?

 

倉:私たちの一番の関心ごとはサービスをお客様に提供し、サービスが成功することです。私たちはこれから100万DAUのサービスを作っていく目標を持っています。SREに期待していることは、持続的にサービスが成長するための指標だったり、仕組みづくりです。現在は「なんとなくエラーログが多いな」とか「お客様からの問い合わせが多いな」といった主観的な判断になってしまっていますが、より沢山のお客様にご利用頂くサービスにおいては、SREとしてここを可視化して行くのが重要であると考えます。

 

髙山:最近はプラットフォームエンジニアリングという概念も流行ってますね。エンジニアに提供するという領域だと思うが、色々なサービスがあっても色々なプラットフォームがあり、使いまわせるのが理想だなとは思います。どうしても現場の1エンジニアに依存してしまっています。

 

吉岡:SREは幅広いと思っており、コンテナ周りなど開発環境を整える仕事をしている人もいれば、アプリやサービスのユーザー行動を可視化してサービスの成長や売上に貢献する人もいます。

 

倉:元々はGoogleなどプラットフォームとして機能を提供しているところでの概念だったと思います。エンタメ領域においてはお客様へ提供するサービスの品質という面で、どこが指標になるのだっけ?という点が悩ましいですね。

 

吉岡:SREとして足元の整備が進んでいくと、そうしたサービス品質の可視化の部分に応用していく流れなのだろうと思います。ただ、そこまで着手して成果が出ていて情報発信まで出来ている企業は少ない印象ですね。

 

 

ーSoftware Designは2024年以降、どのような方針がありますか?

吉岡:これまでは、プログラミングとかサーバーサイドのOSやネットワークとかの機能や実装の話を多く扱ってきており、サーバサイドエンジニアの方を中心によく読んでいただきました。ただ、Software Designという雑誌名なのに、設計の話が少なかったと思っています。そのため、最近では意図的に設計の話を増やしています。1つの言語の話になると、その言語を使う方しか読まないことが多いが、設計の話になると、言語を横断して共通に利用出来る話があるので、応用が効くような内容になります。CI/CDの構築の方法にしても、テストの方法にしても、設計部分の話を特集で取り上げるようにしており、今年もそれを継続しようと思っています。基本的な技術の話や、設計を踏まえてどう実装したら良いのかという話は、第2特集などで取り上げようかなと思っています。

ー2024年以降、お二人が目指すココネのものづくりとは、なんでしょうか?

髙山:今までココネにR&Dチームは無かったのですが、今年は新しくココネでは使っていなかったRustを使ったり、Rust+Webアセンブリを使ってアプリ内のサービスをWeb化しようという動きと流れがあります。今まで使えていなかった技術を使って、既存のリソースを有効活用して新しいサービスを生み出して行きたいと考えています。それに加え、Webアセンブリの領域はエンタメで使えることが多いので、今後も対応していくことで新しい価値を出せると考えています。こうした新しい技術に挑戦したいエンジニアも、ココネのR&Dに向いています。

 

倉:ココネの開発組織をより強くしていくのがミッションです。具体的には社内のエンジニアが新しいスキルを身につけたり、新しい技術を試したりといったことをしやすい制度を導入したり、社内での勉強会を通じてだったりを整備したいです。新しくスペシャリストを採用していくことも仕事で、そのためにエンジニアブランディングもしてゆきます。その中でもグラフィックエンジニアを強化することで、ココネの可愛い、癒される、といった見た目や動きについて、世界でもトップレベルに到達したいです。これからココネのサービスが10倍、100倍の規模になるために、先ほどお話ししたSREと、それを守るためのサービスセキュリティの強化も必要です。また、新しいサービスは必ず当たる訳ではないので、打席と打率を上げていく必要があります。共通部分は共通化モジュールを揃えてゆき、短い期間でコンテンツのみに注力してチャレンジしていくことが、100万DAUだったり、1000万DAUだったりの世界を見るための方法だと思っています。これらが今年形になれば良いですし、2025年に向けて花開いていけば良いなと考えています。

 

ー貴重なお話をありがとうございました!

 

Tag

Category