Startup CTO of the year 2022に参加しました！

概要

以下のイベントにオンラインで参加したのでメモを残します。
https://np2022.startup-coy.com/

解釈の違い(誤解)があるかもですがメモなので大目に見てください・・・

ピッチコンテスト

FastLabel株式会社　恋塚 大さん

AIデータプラットフォームFastLabel

• プロダクトの提供
• 教師データ作成代行

AIによる教師データ作成の自動化→一般公開されたAPIでは自動化できない
エンタープライズ向けの汎用AIを作ることは難しい
案件ごとにエンジニアがAI開発するのにも問題がある(採用が難しいなど)

ノーコードで解決

• SageMakerを使用
• コンテナで実行できる

今後は画像以外の動画、3D、テキスト、音声などに挑戦していくらしい

[感想]
案件ごとにエンジニアがフルスクラッチで作成するのではなく、ノーコード(SageMaker)で実現しているところが素晴らしいと思った。
少ない人数でいかにスケールさせることができるかをしっかり考えて選定したらしい。

テックタッチ株式会社 日比野 淳さん

プロダクトを堅実に伸ばすための大きな意思決定

日本のデジタル競争力:2022年は29位
企業のSaaS製品導入は年々増加傾向→ユーザーの定着化が課題(73%)

WEBシステム画面上に操作方法や業務フローのナビゲーションを表示する
入力アクションを捕捉して項目説明やバリデーションを自動で実行

対象システムと共存するため、動作が不安定になることがある
→対応するごとにコードが複雑化

拡張部分を0ベースで作り替える意思を決定→1年後に完了

作り直しの意思決定はビジネスサイドからの理解を得るのが大変じゃなかったのか？
→反対意見はなかった。機能追加よりもどんなシステムでも動くようにすることが課題だったため、理解を得られた

[感想]
作り直すとなると既存システムとの兼ね合いもあってかなり大変なイメージだが、自分達が乗り越えるべき課題を解決するためにその決定を行ったらしい。
なかなかできる決断では無いのですごいと思った。

株式会社ログラス　坂本 龍太さん

お客様に徹底的に向き合うプロダクト戦略
経営管理クラウドログラス

外資系サービスがトップシェアで、昨日の数では勝負できない
→100社以上に徹底的にヒアリング

お客様とライブでデータモデリングを行い、課題を整理

経営管理版「GitHub」を作ろう！→特許も取得している

エンジニアが直接お客様とお話しするスタイルで開発しているらしい。
ただ、知識が無い状態で挑んでもダメなので有識者からの知見共有を行っている。

[感想]
ユーザーファーストなモチベーションがとても共感した。
この人を救うのは自分だ！！みたいなモチベーションがとても凄かった。
それにしても2000ファイルのExcelを扱う状況、凄まじいな・・・

株式会社FLUX　Edwin Li(李然)さん

高速成長を支えるCTOの役割

データ活用のハードルが高く、テクノロジーを利用できない
→データ収集から活用までを自動化

ブルーオーシャン戦略
→大学機関と連携し、早期に人材発見、育成
→外国籍エンジニアの採用

エンジニアの成長環境の整備
→独自の技術テスト制度の導入
→勉強会や学習支援制度

海外エンジニアを採用したときに言語の壁やコミュニケーションコストが発生するがどう対応しているか？
→多言語マネージャーの育成、アウトソースも英語で行えるようにしている

[感想]
エンジニア採用に対する課題の解決方法がなかなか他社でできていないことを実行していてすごいと思った。

株式会社スマートラウンド 小山 健太さん

スタートアップ業界の基盤となるサービスを目指す

スタートアップ向け
投資家向け

システム規模が大きく、ドメイン知識が複雑
SaaSでありながら他社とデータ連携する

スクラムを改変した独自開発スタイルを実施
→開発者個々のパフォーマンスを上げる

モジュラモノリス化で複雑さを軽減

なぜ作るのか？の理解に時間投資
→全社員が理解できるようにした

AWS認定ソフトウェアに認定されている

採用を強化したいにも認知力が足りない
→コンテンツの発信はレッドオーシャン
→勉強会を立ち上げた(Kotlin Meetup)
結果、Kotlinエンジニアの採用にも繋がった

[感想]

なぜ作るのか？の理解に時間投資
→全社員が理解できるようにした

この文化めっちゃいいな・・・

株式会社ナレッジワーク 川中 真耶さん

スタートアップのジレンマ

早くローンチしたい、技術負債を作りたくない
→両方を満たしたい
→エキスパートによる完全分業体制

コミュニケーション課題が出てくる
→ドキュメント文化と会議体を設計

体制を分けたため、フロントとバックエンドが分業しやすい(SPA)

拡大に向けて、ビジネスチームとプロダクトチームが分業
→リリースノートと会議体で解決
→顧客からのフィードバックをビジネスからプロダクトへ共有

[感想]
分業化された時のコミュニケーション課題をドキュメントと会議体で解決しているところがとても参考になった。
特にビジネスチームから顧客のフィードバックをプロダクトチームへ連携している部分がとても良い(羨ましい)と思った。

Session1

はてな×Qiitaと考える。いま求められる、企業・個人の“情報発信戦略”

なぜエンジニアははてな・Qiitaを通じて情報発信するのか？

社員エンジニアの発信が技術のブランドになる
→現場の声の方が信頼される、会社の知名度向上、採用に繋がる

一方、採用を意識しすぎて発信できない
→本来はWeb+Log = Blog
日々の問題解決を記録する

はてなは全体の37%がIT関連、25%がエンジニアが使用している

どうしてはてなが選ばれるのか？
→書きやすい、他社同士て連携しやすい、見てもらいやすい、読んでもらいやすい

Qiitaは8,9割がエンジニアが使用している

なぜアウトプットしているのか？

• 自分がインプットしたスキルを定着させるため
• ポートフォリオとして
• 恩返しのため(先人の知恵から学んだので今度は自分が発信)

はてなの文化として、ナレッジを社内だけじゃなくて社外にも共有してください。と言っている
→ブログを書く時間を業務時間として扱っている
→アウトプットしやすい文化を作る
(この文化好き。)

はてなはナレッジを過去から全て見れる状態になっている
→まずは社内からの情報共有から実施する
→Qiitaも同じく

やってみたい！という人をみんなで盛り上げる文化生成
→若手が折角頑張ろうと思ってもリスク検討から入ってしまってモチベーションが下がってしまう
→まずは書いてもらって確認する

アウトプットは業界全体を盛り上げる！！！

Session2

なぜ、経営と技術の融合が必要なのか？
ビジネスとテクノロジーの関係性を学ぶ50分

テクノロジーが変える、ビジネスの未来

Software is eating the world

ほとんどのソフトウェアがAI化していく

「箱根 x 旅館」で調べるときに「いい感じ」みたいな曖昧な表現だと検索が難しい
→ChatGPTだとそれなりにいい感じの旅館が返ってくる(すごい)

逆にAIで取れない情報が貴重になってくる

昔はソフトウェアから人間が遠い存在だった
→CLIから入力して演算して返ってくる
→言葉から入力するように近くなってきている

GitHub Copilotのように細かいことを自動でやってくれるような仕組みも出てきている

人間でしかできないことが残るのでは？(ビジネス視点で)
→意思決定？

経営と技術の理想の関係性とは？

GoogleはCTOポジションが無い
経営者が全員CTOできるよね的なスタンス

宿の値段は全て同じ、ユーザーエクスペリエンスが競争基準 (一休)
→経営 = 技術
昔は商品が違った(高級ホテル、ビジホ、ペンション)
そのうち商品が揃ってきてこの形となった
→商品以外のところで勝負するときに技術の競争になってくる

エクスペリエンスの差はどうやって測定する？
→仮説をモデルにしてひたすらA/Bテストしている
仮説すらAIが行えるようになる未来があるのか？(今は人が行う)

求められる思考方法やスキルとは？

一番質の良い情報は対話からしか出てこない
一人で認知できる領域は限界がある

新しい技術をどうキャッチアップするか？

• 情報が転がっているのでコミュニティから仕入れる
• 同じ問題、課題でも別の考え方や解答がある(人から仕入れられる情報)

この技術がどれだけビジネスに影響があるのか？
コミュニティは活発か？などを常に考える

最近、人がソフトウェアで作られている感覚がある
→ソフトウェアに影響を受ける(多分TwitterなどのSNSやゲーム、文化とか？)
情報が多すぎる

CTO/テックリードはこの先どうするべきなのか？
何かに使うための資産を作っているという意識
→一番投資効率が良いものでビジネスにインパクトを残すことを考える
→新しい技術を使うことをダメにすることもある(枯れている技術を使ったり)
エンジニアとして仕事すると新しい技術を触りたくなる
→うまくバランスの良いところを通る (激しく同意)

質の良い情報を得るにはどうすべきか？
データを見るべき。
非エンジニアだったらSQLから着手してみては？
データが分かってそこからプロセッシングになる
→非エンジニアならまずはエンジニアと仲良くなるところから

経営サイドと技術サイドがぶつかった時にどうするか？
衝突する時点でちゃんと対話をしていないのでは？
まずはどの問題を解きたいのかをちゃんと話すべき。
ゴールがずれているとダメ
衝突が起こった瞬間は問題解決のチャンス
ちゃんとゴールが共有されているか？
同じゴールでも登り方が違うことがある
→まず作って段々良くする(ビジネスサイド)
→ミスを少なくして完成させる(エンジニアサイド)
登り方が違うことをお互いに認識してユースケースによって選定する

CTOはとにかくコードを書いてきた人が多い。
ビジネス側との衝突は多いと思うが、ちゃんと何がしたいか一つずつ紐解いていくことが重要

このセッションめちゃめちゃ面白かった。
是非アーカイブで！

結果発表

Startup CTO of the year 2022
株式会社スマートラウンド 小山 健太さん

オーディエンス賞
株式会社ログラス　坂本 龍太さん

おめでとうございます!!