[概要]
生成AI市場は非常に変化が早く高速なデリバリーが求められる環境下のため、必然的に開発速度の向上を目指す必要があります。
そのため弊チームでは、より良いものを取り入れるための技術選定の工夫や、エンジニアがより開発のしやすい環境を整えるための取り組みを積極的に行なっています。

そんな0->1の新規サービスの開発チームで、エンジニア一丸となり様々な取り組みを始めてから約1年経ちました。
(3ヶ月時点での記事: https://zenn.dev/aishift/articles/ce9783a0d7acd0)

[話すこと]
下記の事柄について良かったこと、つらみを沢山話します。

• 頻繁に変化する仕様とそれに耐えうる設計
• 新しいものを積極的に取り入れた技術選定とその後
• バックエンド/インフラのアーキテクチャとつらみ
• 実際開発体験どんなもん？

業務に関する大規模ソースコードから趣味レベルのものまで、基本的に全ての開発作業をNeoVimで行っています。
LspやDap、FuzzyFinder等々の機能を自前で入れる必要があるNeoVimですが、それ故の良さに「カスタマイズ性の高さ」があります。要は自分が求める機能を自分で実装できます。
今回はNeoVimをさらに強化する為にIDEであるIntelliJを実際に使用したりVimMasterの動画を見て便利機能を取り込んだ話や、なぜ自分で実装する工数を使ってまでNeoVimなのかについて話すセッションになります。

また、Vim系エディタでチーム開発を進める上で重要になるのがTUI（terminal User interface）の話です。
最近の「Rust製」の勢いを踏まえて、VimやTUIを活用した「Terminal IDE」（個人的命名）についても話します！

今から約50年前、カール・ヒューイットによって提唱されたアクターモデルは、
50年の時を経て再び現代のシステム設計において世界中で脚光を浴びています。

このセッションでは、まずアクターモデルの歴史的背景に触れ、その基本的な考え方を理解しながら、
50年後の現在において、当時の並行計算の限界を克服するための革新的なアイデアが、
どのように現代の複雑なシステムにおいて役立っているのか、どのような影響を及ぼしているのかを探ります。

アクターモデルの歴史的背景から現代への応用までの道のりを、
まるで未知の大陸を再発見する旅のように感じ、
過去の知識を新たな視点で理解し、未来のシステム設計に活かすための冒険に一緒に出かけましょう。
この旅を通じて、アクターモデルの奥深さと、その持つ無限の可能性に触れることができれば幸いです！

AWSにおいて「サーバーレスアーキテクチャ」は非常にメジャー、かつ多くのアプリケーションで採用されいるアーキテクチャです。
そしてその中核を担っているのはAWS Lambdaで、数多くの処理をLambdaで行っていると思います。

しかしその結果、Lambdaの数が膨大になり、金銭コストや単体テストなどの管理コストが負担になってしまうという問題もあるのも事実です。

そこでこのセッションでは「Lambdaレス」という、「あえてLambdaを使わない」というサーバーレスアーキテクチャを紹介するとともに、
「Lambdaレス」を採用することでどのようなメリットがあるのか？逆にどのような点がデメリットなのか、そして「Lambdaレス」のユースケースは？などをお話ししたいと思います。

また、もちろんAWSだけではなく、AzureやGoogle Cloudにも適用できる内容になります。

CloudbaseではCNAPP(クラウドネイティブアプリケーション保護プラットフォーム)製品を提供しており、発表者も日々脆弱性スキャンの機能を開発運用しています。
このセッションでは一般的にtrivy、vuls、syft/grypeなどに代表される脆弱性スキャナのソフトウェアのバージョンから脆弱性データベースを突合し、ライブラリやパッケージの脆弱性を検知する仕組み、実装方法を解説します。

話すこと

• 脆弱性データベースについて
• 脆弱性スキャナの仕組み、作り方

昨今、政治資金に関する問題が世間を賑わせている。政治資金に関しては我が国に政治資金規正法という法律があり、これに基づき政党や政治家個人の政治資金の支出入はすべて政治資金収支報告書という形で総務省のHPなどで多くが公開されている。しかしその中身は紙の書類をスキャンしただけのPDFデータで、政治資金の詳細な集計や分析は困難な状況となっている。

この問題を解決するために発表者は趣味のプログラミングの一環として、オープンソースのOCRエンジンなどを用いて政治資金収支報告書の解析・分析プログラムを実装し、これらを最終的に【政治資金データベース】というWEBサービスの形にまとめて公開した。
本発表では政治資金の問題の背景や先人たちの取り組み、そして政治資金データベースの今後の開発の方向性やプロジェクトのオープン化、コミュニティー活動化の可能性を探り、実現したい未来の政治活動や政治資金の姿を示したい。

マネジメント未経験から20人ぐらいの開発組織のCTOになれた経験を通じて、将来、CTOやEMを目指す方が「自分でもできるかも？」と思ってもらえるような内容をお話しします。

コロナ禍に社会人になり今年で5年目です。
キャリアの半分以上をCTOとして過ごしてきているので技術以外ゼロからのスタートでした。
そんな僕でもマネジメントを学び、採用を学び、リファラルで集まった数名の開発組織から20人ほどの開発組織にまで成長させることができました。
その経験を経て学ぶべきことやマインドについてお伝えします。

下記のような内容を具体的にはお話ししようと思っています。

• コミュニティに入っていろんな人と仲良くなる
• CTOの師匠となる人を見つける
• マネジメント研修を受ける
• 採用は採用が詳しい人に聞く
• 苦手意識があることも全部やってみる

動画配信サービスには、ユーザーが快適に使用するための多くの工夫が凝らされています。再生ボタンを押してからの素早い再生、効率的な動画のエンコード処理などがその一例です。今回、自宅サーバーで1から個人開発した動画配信サービス「YuoVision」では、これらの課題に取り組みました。

この発表では、本サービスの作成において工夫した点や苦労した点についてご紹介します。

対象者

• 動画配信の仕組みに興味がある方
• 動画処理技術に興味がある方
• 本サービスの運用体制や開発体制に興味がある方

エンジニアがフルスタックに開発するだけではなく、デザインやビジネスの領域に越境して顧客課題を中心に開発することでプロダクトの提供価値は飛躍的に向上します。
本トークではプロダクト志向を持つエンジニア達が未来を切り開くために「プロダクトエンジニア」という向き合い方を紹介します。
日本で最もデジタル化の遅れた物流産業で業務系SaaSのPMFをするまで試行錯誤を含めてプロダクトエンジニアの開発方法を説明します。
これにより、多くのエンジニアが事業の成功や顧客の喜びの声を得られるようにすることを目指します。

お話しすること

• プロダクトエンジニアの役割
• 活躍するための５つのコンピテンシー（好奇心、越境、仮説思考、アンラーン、オーナーシップ）
• プロダクト価値を上げるための組織設計、技術選定、開発プロセス
• プロダクトエンジニアコミュニティの立ち上げ

新規事業や新規プロジェクトは多くの会社が取り組んでいると思います。
私はエンジニアとして、テックリードとしてなど役割を変化させつつ事業やプロジェクトに関わってきました。
その中には立ち上がってすぐに撤退したものや、プロトタイプの時点で終わったもの、構想だけで終わったものなどもありました。
今回は、過去の異なる失敗の中で自分が悩み学んだことから何を次につなげて今どのように新しい事業に挑んでいるのかをお話ししたいと思います。

Ruby on Railsがリリースされたのは2004年。Perlで馴染みのあるCatalystは2005年です。かたやNext.jsは2016年。では、今、Webフレームワークを作るとしたらどのようなフレームワークをつくるでしょうか？

僕にとってその答えがHonoです。実はHonoはPerlのMojoliciousから強く影響を受けています。一方で強力なTypeScriptサポートやReact互換を入れたりと攻めています。

今回はHonoを題材に、この時代にWebフレームワークを作るとしたら過去から何を学び、未来に何を提案できるのかを考えます。

• Web StandardsとPSGI/Plack
• ORMはいるのかどうか
• バリデータを移譲する
• ミドルウェアとヘルパー
• 型をRPCとして使う
• Rooter::Boomは速い
• テンプレートエンジンの代わりにJSX

皆さんモブプロやってますか？私の所属する企業では週に2,3回モブプロを行っています。
主な目的は以下の3つです。

1. チーム内のコミュニケーション量の増加
2. 技術の共有
3. プロダクトの仕様の共有

それぞれを簡単に説明すると、
1つ目はフルリモートなのでコミュニケーション機会を増やしたい
2つ目は技術力に幅のあるチームなのでモブプロを通して技術の共有をしたい
3つ目は関わっていないプロダクトの仕様を知る機会を作ってサービスの全体を把握したい
ということを目的としています。

一定の効果を感じ、1年以上継続して行っております。
これらの詳細について、お話しさせていただきます。

「未来」を切り拓くようなプロダクトの開発は、得てして「未知」な状態からスタートします。
例えば、どのような技術が必要か、法的な制約はなにか、どのようなリスクがあるのか、だれも何もわからないといった状況です。
そのような状況下で、未知を既知にしていき、プロダクトを適切に開発するには、どのようなアクションが必要でしょうか。

この発表では、わたしがキャッシュレス決済サービスの立ち上げからエンハンスに関わる中で得た、未知のプロダクト開発に立ち向かうための術をお話します。
話したいこと:
・事業ドメインを深く理解するためのノウハウと活用方法
・仕様書もない中で未知なシステムを作るための戦略
・未知だらけの開発でどうチームとして協調するか
・未知のプロダクト開発に挑む際のマインドセット

新卒時代、様々な人から「視座を上げろ」「メタ認知は大事」と言われました。しかし、育む方法がわからず困っていました。

成人発達理論に出会い「全部書いてあるやん！」と驚きました。メタ認知のレベルが定義され各段階における特徴と移行期の障壁がまとまっていたからです。

技術広報チームマネージャーとして働く私が、様々な価値観・専門性を持つ人と折り合いをつけながら働けるようになった実体験を話します。

対象

• 全く成人発達理論を知らない人
• 視座、メタ認知をどのように育むか分からない人

話すこと

• なぜ仕事でメタ認知が大切なのか
• 成人発達理論とはなにか
• メタ認知にも段階がある
  • 人の価値観の中で生きる層
  • 自らの価値観の中で生きる層
  • 折り合いの中に生きる層
• 移行期は自己喪失を伴う
• 持てる価値観が増えれば、共に価値を生める人の幅が広がる

私は株式会社ヌーラボで会計周りのシステムのプロダクトオーナーをしています。
知名度の高い弊社製品Backlogとは異なり、非常に重要だが地味な領域です。それゆえユーザーとの接点が持ちにくく、ユーザーの声を聞くことに難しさを感じていました。

巷ではユーザーインタビューの重要性が至る所で囁かれていますが、そもそもユーザーを見つけられない。。。ってことはないでしょうか。
どのようなシステム開発にも応用可能な、以下の内容についてお話しします。

概要

• ユーザーとの対話が難しい時にすること
  • ユーザーに一番近い人間を探せ
  • 問い合わせ、バックオフィスの稼働時間、証憑等数字から読み解く
• システムは業務フローの中に存在する
  • 業務フローを紐解くとシステムのあるべき姿が見えてくる
• フィードバックは声ではなく数字に現れる
• 計測をすることで士気を高める

エンジニアにとって、アウトプットすることは重要な活動の一つです。
コロナ禍を経て、技術コミュニティが以前よりも活況になり、アウトプットとしての「登壇」が重要になっています。
一方で、最初からアウトプットが得意というエンジニアは少なく、特に「登壇」は経験の数が物を言うため、心理的ハードルが高く、上達が難しいものです。

私たちの組織では、アウトプット経験を養うために社内 LT 会を発足し、研鑽のための場を作っていきました。
本発表では、組織で行うアウトプットへの考え方・取り組みや、社内 LT 会を発足する際の進め方や組織内の風土作り、開催・継続の中での学びについて話します。

内容予定

・エンジニアにとってのアウトプットとは
・組織で続けるために考えたこと
・組織の変化や今後の課題

目標

・組織でアウトプットする文化を醸成するためのヒント
・開発業務以外の取り組みへの動機づけ

ユーザーインターフェイス（UI）は全てのユーザーが製品に触れるための重要な境界であり、これがなければ製品は成立しません。現代においてはUIデザイナーという専門職が確立されていますが、様々な事情により、エンジニアがUIデザインを担当する場面も少なくありません。例えば、創業期にはUIデザイナーを雇う余裕がない場合や、デザイナーがいてもリソースが不足している場合などが挙げられます。この発表では、突然UIデザインを任されたエンジニアの皆さんに向けて、どのように仕事を進めるべきかの指針を示します。

含まれる話題

• 発表者のフロントエンドエンジニアとUIデザイナーの兼業経験
• ユーザーのメンタルモデルを理解し獲得する方法
• 実用的な70点のUIを仕上げる方法
• エンジニアがUIデザインを学ぶことの未来像

含まれない話題

• ブランドデザイン
• 大規模組織でのデザインシステム

過去作られたコードに最大のリスペクトをしつつも、サービスの成長とともに少しずつ技術的負債が溜まっていくことは多いと思います。
弊社も開発と並行した改善を続けていましたが、一度立ち止まって考え、１ヶ月の間、「品質UP」に全エンジニアのリソースを集中させる意思決定をしました。
本発表では、コアドメインとなる「予約 / 決済」機能を中心に、実施した具体的な取り組みとポイントを共有したいと思います。
品質を諦めず、今後の体制強化に取り組んだこと、そして未来への施策が、「Open the future」のきっかけになりますと幸いです。

＜話すこと＞
・経営陣やビジネスマネージャーの理解を得て意思決定した話
・全ての因子（テストすべきテスト条件）の洗い出し　〜　シナリオテストの作成　〜　Rspec、コンポーネントテスト作成の話
・未来を切り拓く開発プロセス改善の話
・得られた副次的効果

創業（創刊）から140年以上の歴史を持つ長寿企業であり、メディア企業として保守的な体質を持つ当社は、10年以上前からソフトウェア開発の内製化に取り組んできました。その取り組みは実を結び、現在では全社で70人を超える内製エンジニアを抱える組織に成長しています。
しかし、プロダクトマネジメントについては未熟な部分があり、開発者とビジネス部門の双方にストレスがかかる状況が続いていました。この数年間でその問題を解決し、透明化されたプロセスを導入することで、全員が納得できる状態を構築しました。
今後数年は、生成AIという新しく破壊的なテクノロジーを取り入れ、さらなる進化を遂げる必要があります。保守的なメディア企業でありながら、長期間生き延びてきたのは、新しいテクノロジーを取り込む力と環境変化に対応する能力があったからです。これらの点について、さらに詳しくお話ししたいと思います。

コロナ禍においてはオフラインでの勉強会の実施が難しく、オンライン勉強会として YouTube Live のようなライブ配信プラットフォームや、 Zoom などオンライン会議プラットフォームを使うことがありました。
しかしオンライン勉強会ではオフラインであった交流や雑談が起こりづらく、淋しい経験をしたことはありませんか？
このトークでは近年発展しつつある VRSNS とそこで行われる勉強会、また私が「分散システム集会」として実施している勉強会の開催例をご紹介します

話すこと

• VRSNS (メタバース) の今
• 勉強会開催のプラットフォームとして見たときの VRSNS の良さ
• なぜ私は VRChat で勉強会を続けるのか