【レポート】「Developers Festa Sapporo 2022」に参加してみた

「Developers Festa Sapporo 2022」に参加してみました。

Developer Festa Sapporoとは？

北海道内外のIT業界のトップエンジニアである講師陣が、Web・オープン系技術やクラウドなど、幅広いジャンルの最新情報や注目情報を発信していくイベントです。

現地（今年は札幌コンベンションセンター）か、オンラインで参加できますが、事前の申し込みが必要です。

申し込み方法

期日が近づいてきたら、イベントサイトに申し込みページが設けられます。

参考 イベントトップページDeveloper Festa Sapporo

2022年は11月24日開催でしたが、1か月前ぐらいには申し込みページが設けられます。

オンラインで申し込んだ方は、申込時に指定したメールアドレスに、開催の2~3日ぐらい前にオンライン参加用のURLが送られてきます。

受けてみてどうだった

いやーーーーーーーもう。良い（語彙力）
とにかくモチベが上がりますね。来年度もぜひ参加したい。

2022年度のプログラム

講義のメモ

こんな講義だったよーのメモ

メタバースはどうあるべきか～開発視点からみたバーチャルキャストの葛藤～

インフィニットループはこんなことしている

・初音ミク公式テーマパーク：年に1~2回開催
・VRグリーティング：推しのVTuberと写真を撮ったり
・教育：N高等学校、S高等学校でのVR学習

VR上で面接のトレーニングしたり、友人のコミュニケーションしたりできる。
VR空間内で体育祭もできたりするらしい。

メタバース開発とは

「仕様として設計するとき、世界を作る哲学が必要」
「メタバースとは？がまだ定義されていない中で、人それぞれのメタバースをぶつけ合いながら作る」

ほうほう。

（アイスブレイク）メタバース空間上のセクハラについてどう思う？

「リアルだと逮捕されるけど、メタバース空間だと運営にBANされる」
「メタバースの世界では、その相手を見えなくすることもできるので、個々人でも対策できる。」
「初対面の人にいきなり近づくのはやめよう（現実の距離感と同じだよ）」
「リアルでダメなものをメタバース空間にも適用してしまうと、逆につまらなくなることはある」
「他人に迷惑をかけない、他人に不快を与えない、基本的なルールは守るべし」
「いい方向に独自性が出せればいいよね」

今のメタバース業界とそれを取り巻く環境についてどう思う？

「バズワード化する前からやっているので、全力で乗っかっていきたい」
「メタ社の参入前後ですごい状況が変わった。」

そもそもメタバースってなんだ？

「それぞれ独自の解釈がある。」
「NFTとかWEB3とかが入ってきているので、より分かりづらくなっている。」
「もうWEB3は遅い、今はWEB5。これはWEB2とWEB3の良いところを足したもの。分散型インターネット。」

今のメタバースに足りないものは？

「立場上のアバターだけど、そのアバターの姿を他のPFで使えるための相互運用性（インターオペラビリティ）が足りない。」
「全員が鳩になるハトバースのような遊びになってもいい」

「リアルにあるXXショップをメタバースに再現してみた。公園を再現してみた。とか。そういうデジタルツインはあってもいいけど、本物があるので劣化版になってしまう。」
「リアル＋ユーザ体験によって、はじめて価値が生まれる。」
「バーチャル渋谷はうまくいっている。雪まつりはどうだろう？」
「静岡のスキャンデータを構築して、デジタル静岡を作っている。熱海で土砂崩れが起こったときに、そのデータを使うことができた。雪まつりもどのようにコンテンツ化することができるか、考える必要がある。」

足りないものを補うためにはどのような技術が必要？

「インターオペラビリティはひたすら作りこむしかない。技術基盤はコストも高い。３Dモデルを作るのも特殊技能を使うのも、細かい調整が必要。コストを下げて、みんながもっと参入しやすいように！」
「柔軟な発想、意見をバンバン聞いて、今までにないものを作れる、そういう環境が必要」
「みんなルンバとか便利なものにはお金を使うけど、ヘッドマウントディスプレイにはお金を使わない。」

.NET 7 (C# 11) の話

.NET概要

マイクロソフトがオーブンソースで開発しているアプリケーション開発、実行環境
対応言語：C#,F#,Visual Basic
マルチプラットフォーム対応：windows,macOS,Linux,Android,iOSなど

今までは、
.NET Framework、.NETCore、Xamarinがあったけど、全部.NET（C#）に統合された。

.NETで開発できる種類
・クラウド
・Web
・デスクトップアプリ
・モバイルアプリ（MAUI、Xamarin）
・ゲーム（Unity）
・IoT（ARM32,ARM64）
・AI（ML.NET）

・コンパイル
C# Program ⇒ (コンパイル)⇒中間コード⇒ (JITコンパイル) ⇒実行ファイル

・Xamarinとは
Android/iOS向けのアプリ開発が可能
C#でコード共通化しながら作れる
Monoランライムがベース
今後は.NETに統合される。

・.NET Standard
.NET Framework、Xamarin、.NET Coreで使える共通のAPIセットを定義したもの

パフォーマンスの向上について

クラウドを使う場合、パフォーマンス向上は費用に直結するので重要。
.NETは早いぞー。

C#の歴史

2002年：C#1が誕生
2005年：C#2（ジェネリックが生まれた）
2007年：C#3（コレクションの操作が楽になった、暗黙的型付けvarができた）
2010年：C#4（動的型付け変数ができた）
2012年：C#5（非同期処理async/awaitができた）
2015年：C#6（オープンソース化した）
2019年：C#7（タプルできるようになった）
2019年：C#8（switchできるようになった）
2020年：C#9（方推論）
2021年：C#10（名前空間）
2022年：C#11（生文字列リテラル）

C#はいいぞ！

Googleを支える推論モデル「Two-Tower」とベクトル近傍検索技術

Google検索はどうできている？

一般的なキーワード検索：文字列やタグ、ラベル等でコンテンツを検索する。
ベクトル検索：ベクトル近似度でコンテンツを探す。
（数ミリ秒で探すことができる）

Embeddings:AIで賢いベクトルをつくることができる

ベクトル検索の応用

文書や画像の内容で探す
似ている製品を探す
似ているユーザを探す
おすすめの音楽や動画を探す
故障しそうなIoTデバイスを探す

などなどが、DBや全文検索を使わずにできる。

既存手法の問題点

協調フィルタリング（※）などのレコメンド手法は、大量の閲覧/購入履歴が必要
・サービススタートから間もない
・日々大量の新しい商品が追加される
→サービス開始間もないメルカリShopsには不向きだった。

※買った商品の類似の商品をレコメンド
→履歴がないと推薦できない（コールドスタートである）デメリット

Matching Engineによる実装

特徴量の選定
・Shop毎に画像に特徴があり異なる
・見た目よりも概念が似ているものを探したい
→テキストの特徴量を採用

モデルの選定
・word2vec + TF-IDFで満足のいく水準
・モデルの軽量さ

→18人月かかっていたのが、1人月でできた。
→今まではステークホルダと調整が必要だったけど、自分一人でできるようになった。DSが、よりビジネス寄りの領域まで踏み込むことができるようになった。

特徴抽出パイプライン

特徴抽出
・商品作成/編集イベント
・Dataflowでword2vec + TF-IDFで特徴ベクトルを検索

embeddingsの作り方

Resources
Two-Towerモデル：クエリと候補のペアからembeddindsの抽出
Swivelモデル
tensorFrowモデル

強調フィルタリングの課題

良い点
・ドメイン知識が不要
・偶然性が期待できる
・実装例や実装が豊富

いまひとつな点
・コールドスタート問題
・多彩な特徴量を再現できない

Two-Towerモデル

例）映画のレコメンデーション
rating/タイトル/説明/ジャンルなどから特徴量を抽出する

クエリの映画と検索結果候補の映画それぞれの特徴量のペアでモデルを学習
embedding空間のインデックスを作る
→クエリと候補の組み合わせは自由に作れる

Two-Towerモデルのメリットデメリット

良い点
・特徴量と特徴量の関係を学習
・多彩な特徴量を加味できる

いまひとつな点
・まだ広く利用されていない
・モデルの設計と学習が必要

モデル作成の選択肢

こんな選択肢がある
・TensorFlow Recommender
・Universal Sentence Encoders for Q&A
・Two-Tower model built-in algorithm(※depricateになった)
・Recommendations AI

今からAWSを始める人はここからはじめよう。そして、きっと使っている人もしらないかもしれないアップデート

学び始めるときは

サービスが生まれた背景を知る。
AWSは、お客様のバックグラウンドに合わせた商品を提供している。

MVP(Minimum Viable Product)
お客様の声を可能な限り早く提供する精神

You Build, You Run it
作った人がそのまま運用までしようの精神
→今の時代、作って運用チームに渡すみたいなやり方が難しい

AWSは2006年にリリースされているが、その時はDevOpsがなかった。

開発をしていると「なんか違う」に直面して、方向転換がしづらいこともある。
でも、開発はそれを運用に言えない。みたいな状況が往々にしてある。

そして「基盤が最初からあればいいのでは？」から、クラウドコンピューティングが誕生し、アプリケーションをいつでも変更できる仕組みにつながった。

Amazon SQS

7,050万回/秒の処理を実現できた。
イベント駆動アーキテクチャにより成り立っている。

イベント駆動アーキテクチャ

複雑な状態遷移を取り扱うソースを独立させて、ミニマムにしておくことが大事。

コードとステートの切り離し

例）貰った注文に対してリアルタイムに注文決済
セキュリティセンシティブな取扱いになる。

単純なアジャイル開発はできない
→ユーザの住所を触る部分と、セキュリティカードの部分を切り離す
→それとは別にフロント部分をアジャイルで実現

小さいビジネス判断を行える独立性を実現すべき
→こうすることで余分な調整が生まれず、スピーディに回す

Messagingサービス

・Amazon SQS
・Amazon SNS
・Amazon Event Bridge

がある。今後も増やして、使いやすい基盤を作る。

Micro Service Architecture

アプリケーションを細かく分割すると、統括する人がいなくなるので、セキュリティとして許容できない。

・分散モノリス型：フロントだけマイクロサービス
・モジュラーモノリス型：デプロイだけ専門のプロセス

を採用する企業が増えている。

可観測性（Observability）

ログ、メトリクス、トレースによって検知して修復する。

AWSの基本的な機能

・Amazon VPC(Visual Private Cloud)
クラウド内にお客様専用のプライベートアドレス空間を構築。社内ネットワークとインターネットVPNやキャリアの閉域網で接続可能

・AmazonEC2
・Application Load Balancer
・Amazon RDS

学ぶには

AWS BlackBelt：オンラインセミナー
Hands-on：ハンズオン
AWS Basic：ベーシックトレーニング資料

Amazon Aurora

DBのサービス。RDSの拡張版。
3つのAZに6つのコピーを配置し、高可用性、高耐久性、高いパフォーマンスを実現

Aurora Serverless v2

負荷に応じた動的なリソース拡張
プロビジョンドノード、サーバレスノードをクラスターに混在可能
→最新のDBエンジンにしか対応していないのがネック

Lambda

リクエストが来ていない間が、メモリが確保されていない。
リクエストがあったタイミングで、動的にアロケーションして、どこかのタイミングで破棄される。

→今まではColdStartだったので、リクエストから待ってしまっていたが、改善した。

最後に

AWSのサービスが使いづらかったら、必ず文句を言ってほしい

啓発期を迎えたIoTが切り拓くこれからの社会と、エンジニアの学びの道

IoTが浸透してきた

モノのインターネットと書かれなくなってきた。
世間にも浸透してきた？

IoTとは

「センサー/デバイスなどの”モノ”」「ネットワーク」「クラウド」
を用いて、人手に頼らず、データを集めたり、現場を動かす

IoTエンジニアとは

現実世界と人をつなげて、価値を作り出す

どんな製品がある？

スマートモビリティ：自動車いす
HelloLight：電気の点灯・消灯がわかる

パソコンやスマホからインターネットを使うITやICTとは何が違う？
モノとモノをつなげるM2Mとは何が違う？

M2M

モノとモノをつなげる点では、IoTと大差ないが、通信設備を自ら敷設・運用
⇒IoTは敷設済みの公衆網を利用する。

IoTはデータ活用までの時間が勝負

課題の発見、解決策や企画、センサーやデバイスの選定、データ活用の仕組みの選定、設置・実施、データ蓄積、データ活用
→このデータ活用に至るまでの時間をいかにスピーディにするかが鍵

「巨人の肩の上に立つ」
→作らず、創る。あるものをうまく使う。

パーツを組み合わせて”創る”
・解決課題を理解する
・入出力に注目する
・組み合わせ方を知る

ソフトウェア開発プロジェクトの壊し方

トラブルをどう捉えるか

ポジションによって異なる。

監査部門：機密性、セキュリティが大事
マネージャ：リリース、品質が大事

「品質を無視すれば、すべてのプロジェクトは成功する。」
けど、それではよくない。作ったけど、すぐ運用できなくなることもザラ。

トラブルプロジェクトとは

2種類ある。

1.プロジェクトそのものに問題がある
→プロジェクト計画、進め方
2.業界や組織などに構造的な問題がある
→文化、常識、性格、目的

どちらもプロジェクト単体では対応できない。

例）素早くトラブルを捕まえるには

トラブルを発見したとき、担当間でのメールのやり取りが増える。
やり取りのログで取れるようにしておいて事前に察知することはできるはず。

プロジェクトの壊し方

・コミュニケーション管理
・スコープ管理
・品質管理
・発注者の的確な参画
・有識者の確保
・品質と管理の予兆検知を行う

によって壊れる。なぜ？

コミュニケーション管理

人が増えれば増えるほど、コミュニケーションパスが増える。
→小集団に分けるべし。

ただし、
・階層構造組織で他チームに直接尋ねる
・アジャイルなチームで「有識者」に直接尋ねる
・一人で勝手に走る、独走が許されると思い込む

適切なコミュニケーション量や比率はPJによって違うはず。
リーダーにコミュニケーションが負担してリーダーが死ぬケースは多い。
→コミュニケーションの前に、まずは自分で考える

スコープ管理

・やってみないとわからない
・全影響を想定・予想できない
・開発中に不確定性が変化

なことがある。

1.スコープの見誤り：開発目途が立たない
2.スキル不足：低品質・納期遅れ
→体制強化、オーバーラン

新しい技術（だけ）を常に意識する

1.細切れ・使いにくい
2.キーの概念が無くなる？
3.不整合・重複が多発？

ビジネスデータモデルが80~90年代で止まっている。
→企業全体のデータモデルを知っている人が必要
→スキルの継承もしっかりと

品質＝テストを重視する

システムの複雑化により、多くのテストが必要
如何に少ない件数で、品質を保つか。（ライフル射撃のような）
→テストをどれだけちゃんとやるべきか、プロジェクトで協議するか。

発注者の的確な参画・助言の確保

ステークホルダの数が増えると、調整のコストが増える。
（ステークホルダマネジメント）

スキル・有識者を確保する

有識者が仕組み、考え方を教えて若手を育てる。
→どこかから有識者を確保すると、別のプロジェクトが破綻する。
→有識者を、横断的に見えるポジションに配置する

品質と課題の予兆検知を行う

A 10,000step ファイル数1 バグ数5(0.5kloc)
B 10,000step ファイル数100 バグ数5(0.5kloc)
→クラスサイズ、クラス数で割って、クラス当たりの欠陥密度にして比較

さて、問題

共通点は何？
→言われた通りやってはダメ。
→従来の成功体験が「今回もこれなら失敗しない」と思い込ませる

「いつもこうやってきたから」
は、ダメ。言われたとおりにやったら壊れる。