年に一度の技術者の祭典、Developers Summit 2020（デブサミ）へ参加した。かなり遅くなってしまったが、このエントリでは1日目に参加したセッションについて簡単にまとめと所感を書いていく。なお、公式にて登壇資料とtogetterまとめへのリンク集を設置済み。
13-E-1「UXデザインが大事なのはわかるけどエンジニアの私ができることってなんでしょう？」（安藤 昌也[千葉工業大学]）
セッション概要はこちら。理想のユーザー体験(UX)を企画の段階から作っていくUXD(User eXperience Design)について、基礎となる理論や活用法を開発者向けに分かりやすく解説していただくという、朝イチから刺激的なセッションだった。
UXDとは、UXを色々なレベル・詳細度のレンズ（とらえ方）で行き来し、仮説と検証の中で真の実現したい体験を計画すること、という。このとらえ方の分類のため、様々な軸でモデル化できるとのこと。時間軸でモデル化すると、利用前（予期的UX）・利用中（瞬間的UX）・利用後（エピソード的UX）・利用体験全体（累積的UX）の4つに分けられる。既存の産業においてもこのモデルは適用されており、例えばお化け屋敷は入口と出口を近くに配置し（予期的UX）、恐怖コンテンツの体験（瞬間的UX）後は、わいわいと語り合う（エピソード的UX）ようになっている。
この例でも分かる通りUXは個人的なものであるが、UXDではこれを量産・再生産することを計画することが求められる。また、これらのUXを満たす機能により商品・サービスには競争力が備わる。UXDにおいてはこれらのUXを行き来し、様々な見方をすることで全体のUXを向上させていくことになる。
事例としてタクシー配車アプリ（JapanTaxi、MOV、S-Ride）を取り上げた。公式サイトのデザインからどのUXを強調しているかを分析すると、JapanTaxiは累積的UX（全国どこでも使える）、MOVはエピソード的UX（マッチング精度とスピード）、S-Rideは瞬間的UX（1アクションで配車）と、各アプリの特徴・機能をUXコンセプトとして意識的に強調していることがわかった。
UXモデルは、アプリ開発者がUXデザイナと対する際にも役立つとのこと。相手がどのUXを意識しているかが判れば、意思疎通が早くなる、とのこと。顧客と直接対峙するアーキテクトだけでなく、デベロッパーにも役立つわけで、今後のエンジニアの必須スキルになるかも、と感じた。
13-A-2「ノーコードPower？だけど開発者だからこそ知っておきたい、Power Platformの使いこなしかた～〜W王子より愛を込めて」（廣瀬 一海[日本マイクロソフト]/清水 優吾[セカンドファクトリー]）
セッション概要はこちら。Power PlatformはPower Apps、Power Automate（旧Flow）、Power BI、Power Virtual Agentsの4つの製品で構成されている。清水氏はPower BIの勉強会を長く主催されている方なので、最新情報に期待して参加したところ、Power Platformの2019年のトピックスを3つ紹介。
- AI BuilderによりAzure CDS（Common Data Service。Azureのストレージサービス）に置いたデータにユーザモデル含むAIを適用可能に。
- Virtual Agentsによりbotもローコードで作成可能に。
- Power Platform dataflowsによりCDS/Data Lakeの様々なデータソースに対しQuery発行やETL(Extract/Transform/Load)適用が可能に。
続いてデモ。デブサミの公式サイトをスクレイピングしてセッションリストを作成し、icsファイルをダウンロード（＝Outlookと連携）できるサービスをPower BIで作成したものを紹介。また某テーマパークのアトラクション待ち時間をデータとして蓄積し、参照や分析をして見せた。
続いて日本MSの廣瀬氏からAzure CDSのご紹介とデモ。デモは先ほどのテーマパークの待ち時間データをCDSからData Lake Storage Gen.2に格納後、Machine Language Studio WorkspaceによりMLを適用、Machine Language Studio Web ServiceによりAPI化してAzure Logic Appsから予測結果を参照するものだった。APIへの接続はCustom Connectorを使っているが、この設定にはMLS Web ServiceのAPI作成時に使ったSwaggerのJSONファイルを使えるとのこと。
ノーコード／ローコードでアジリティが向上するということで、自社だけでも導入できないか、道を探ろうかと考え中。あと、プログラミング言語を扱わない開発者の登場と謳っていた。今後、アジャイルプロジェクトのプロダクトオーナー自身がスキルを身につけ、簡単なやつは開発しちゃう未来がやってくるかも？
13-F-3「音声認識で質の高い議事録を！議事録サービス「GIJI」」（川端 光義[アジャイルウェア]）
セッション概要はこちら。音声認識による議事録作成サービス「GIJI」に関するセッション。音声認識のエンジンはNICTの研究成果を使っていたり、Amazon Echoのような専用デバイスを使うことで、発話方向が異なる複数名の発言を同時に認識したり、事前に話者の言語を設定することで外国語の認識もできたり、といった特徴があるとのこと。無料トライアルがあるものの人気が高すぎて数か月待ちらしい…確かに導入したらすぐに役立ちそう。
13-E-4「Webパフォーマンスガチ勢が本当に使っている技術」（中村 けん牛[プライム・ストラテジー]）
セッション概要はこちら。超高速に実行できるWordPress仮想マシン「Kusanagi」提供の中で活用している、「ガチ勢」な高速化技術についてのセッション。
高速化の最大の目的は「UXの最大化」であり、コンバージョンレート向上や5G化によるバックエンドの相対的速度低下への対策としてフロントエンドのレンダリングとバックエンドの両方で対策することが重要とのこと。具体的には①サーバ（キャッシュ戦略、サーバ自体の選定基準）、②ソフトウェア（nginx/php/MySQL/WordPressの設定）、③ネットワーク（HTTP/2、バックエンド側のネットワーク帯域幅、画像リソース、レンダリングプロセスの順序構成）といった観点で最適化を積み上げているとのこと。
「ガチ勢」すぎて一部難解だったが、ゲームアプリやショッピングサイトなどはこういったWebパフォーマンスの改善がそのままユーザ体験と売上に直結するわけで、技術がカネを生む最前線ならではの話を聴けた。
13-A-5「楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇」（柳本 浩一[楽天]・新井 庸介[日本マイクロソフト]）
セッション概要はこちら。楽天市場やPay、クレジットカードなど楽天グループが提供する全サービスのインフラ提供や運用を行っている柳本氏から。十数年稼働しているサービス（DMC、画像ストレージ関連API群）の改善に取り組んだ際にハマったところなどを解説して頂いた。
面白かったのはSDNの後ろにAzure Cacheとストレージを置く構成にしたらAzureは外向きの通信量に対する課金だったため意味がなかった、Azure MySQLはメンテ頻度の面でSLAを満たせず使えなかったという失敗談。クラウドシステムの構成は課金の仕組みやメンテまで知らないと最適化できないというのが良く分かったセッションだった。
13-E-6「なぜ技術力評価会の評価者はペアなのか？ – 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 -」（小賀 昌法[VOYAGE GROUP]）
セッション概要はこちら。社員評価を上長だけが行うのでなく、複数の他部署の人が相互評価を行う「技術力評価会」という仕組みを運用してきた話。評価システムを作る側として興味津々で聞いた。
エンジニアの技術力を適正に評価するというのは難しい。その原因は下記の通り多岐にわたり部門責任者だけで評価すること自体が難しいとした。
- バイアス：「ハロー効果（特定領域の評価にひきずられる）」「寛大化（客観視できない）」「中心化（自分の評価力に自信がない）」「極端化」
- 評価対象である技術自体の多様化（評価者がフォローしきれない）
- 他人を評価するスキルを磨く機会が少ない
- 同じ上司が長く評価することによる偏り
これを解決すべく半年ごとに「技術力評価会」を実施している。メンバは本人と評価委員・評価者（2名）。その流れは下記の通り。
- 事前準備：評価委員から本人へヒアリング。評価委員とCTOで評価者を選定。必要に応じてプレゼンの事前チェック「素振り」。
- 当日：本人によるプレゼン30分＋評価者による質疑応答60分←たっぷり
- 後日：評価委員＋評価者＋CTOが評価のすり合わせを実施。
- フィードバック：評価レポートは本人に事前公開の上、全社公開←なかなかできないけど透明性確保って言うならやらないとダメ
ペアで評価することにより、最初に挙げた「技術力評価が難しい原因」をクリアできるが、同時にメリットも見えているという。
- バイアス→評価者が固定化されないのは良いが、評価者がベテランだと逆にバイアスが増加する傾向も
- 技術の多様化→評価者を2人としている事で評価者が苦手な分野を補完できるメリットあり
- 評価機会不足→評価すり合わせを通じて評価者のスキルが向上
- その他のデメリット：日程調整コストが大きい←まあわかる
所感としては、これだけ手間をかけて評価するだけのメリットはあると感じるが、果たして自社に取り入れられるためには上層部や幹部社員の考えから変えていかないとな…と感じた。特に、上層部のコミットメントが重要と思う。
13-E-7「クラウドサービスとゲーミフィケーション:「TwilioQuest 3」を用いた開発者オンボーディング」（池原 大然[Twilio Japan]）
セッション概要はこちら。自社サービス「Twilio」のチュートリアルにゲーミフィケーションを大胆に取り入れた事例の紹介。サービスの拡販には、当初想定したユーザ（ペルソナ）以外に届ける必要がある。しかし、製品ドキュメントは読んでもらえない。そのため、TwilioではRPGっぽいゲームでチュートリアルを提供することにしたとのこと。
実装について。過去はWebアプリだったが、現在はローカルアプリで提供。適用技術としてはElectron、React、Phaser、Tiledあたり。Twilioのサービスが日々進化するため、ゲームコンテンツだけを追加・変更できるような仕組みを持っているとのこと。
導入効果としては、アクティブユーザ数95%増ということで、新規ユーザ獲得やリテンションに貢献している。一方、ゲームに嫌悪感を持つタイプの人への対応や、UX改善（日本語版未提供）が課題とのことだった。まあ、ゲームに嫌悪感を持つタイプの人とは仲良くなりたくない、という選択肢もあるんでは？と個人的に感じた。