カテゴリー: 聴講メモ

聴講メモ：try! Swift Tokyo WWDC Recap 2025

今月何度目かわからなくなってきた、Apple Japan での Recap イベントに参加してきた。今回は、筆者も当日スタッフとして参加した try! Swift Tokyo 主催のもの。登壇は visionOS と Foundation Models のふたつとも筆者的関心の高いテーマでありがたかった。特に Foundation Models adapter training は未遂に終わっていたので、実際に触った所感を聞けたのが良かった。

タイムテーブルは筆者が確認していた限り直前まで公開されておらず、個人的に最もサプライズだったのは、 Swift Student Challenge に日本から入賞された学生さんがスピーカーとして登壇されたこと。Apple の Newsroom で取り上げられていたのを拝見していたので、すぐに分かった。入賞とひと言で言っても、世界 TOP50 に選出され WWDC に招待された上に、さらに11名だけが得られる Tim Cook へのピッチ機会も設けられた、とのこと。しかし彼のプレゼンを聞いていて、堂々とした語りと、なにより入賞した花札アプリのコンセプトが素晴らしく、これが世界レベルかと感動。ちなみに花札アプリは実際に触らせていただくこともできた。花札という古典ゲームにオリジナルの概念を盛り込んでいて、サウンドにも見た目にも細かな工夫が凝らしてあり、誰でも楽しみながら花札を覚えられるつくりとなっていた。

イベントページ：https://lu.ma/kd101ho8

visionOS 26 のアップデート内容と所感

satoshi さん

  • What’s new
    • Widget
    • instancing: メモリ効率がかなり上がった
  • 他セッション
  • 実機デモ
    • Enterprise APIでの両眼映像の取得
      • シェーダーを通したリアルタイム画像加工ができる（高速処理のためMetal使った）

Unleashing Foundation Models

shu223 さん

  • Tool calling
    • 制約：modalilty – multi-modal ではない
      • テキストのin/outのみ
      • 音声や画像の入出力はない → tool calling でやった
    • Tool calling の処理実装はなんでも実装可能
      • Speech + Image Playground
      • ツールとして渡しているだけなので、使わないという選択をモデルがすることもできる
        • → 画像生成を依頼しなければ使われない
  • Custom adapters
    • モバイルで動く小さめなモデル（Llama, Gemma の同程度のサイズのモデル）と比べてもやや劣る
    • Custom adapter で大幅に性能が向上した：すべてのベンチマークで、はるかに大きなモデルよりも優れた性能を発揮
      • GPT-4.1 や 4o を含む大規模モデルすらも超えるケースも
    • アダプター
      • 特定ケースにチューニングされた追加アダプター
        • e.g. .contentTagging
        • たくさんある？とおもっったら、general / contentTagging しかない
        • ほとんどのユースケースが、general に内包されている
          • tag, entity topic は tagging
    • 概要
      • LoRAを使用
      • ベースモデルの重みは固定し、アダプターの重みのみ更新
      • 必要なデータ量の目安
        • 単純タスク：100-1000 サンプル
        • 複雑タスク：5000サンプル以上
    • ツールキット
      • 必要なサンプルデータやコードが揃っている
      • .fmadapter ファイルがカスタムアダプターの実態
        • Xcode でプレビュー可能
    • Entitlement
      • アダプターのデプロイは、サイズがでかいのでバンドルするのではない、background assets フレームワークを使う
        • テストはアプリに組み込んでOK
    • サンプル（演劇）を使った学習結果のデモ
      • エポック（学習サイクル）を重ねるごとに、タグ構造を学習しフォーマットに沿った台本生成が可能になる（らしい）
      • 学習時間はMBPで10分程度：OSバージョンアップごとの再学習も現実的かも
  • Q&A
    • 回答のばらつきは temperature で指定可能
    • 基本メジャーバージョンごとにモデルが変わる sticky patch で上がることはない
      • 追従できなくてもアダプター自体は通るが、精度が落ちる

聴講メモ：WWDC25 Recap – Japan-\(region).swift

昨日に続き、WWDC25 Recap イベントへ @Apple Japan。全国５会場を繋いでのLT10本立てで、多岐にわたるテーマが並び充実した時間だった。各拠点の盛り上がりが映像を通して伝わったのも温もり感じられて良かった。また、Twitter でアイコンは知っているが面識なかった方々とお会いでき、懇親会含めてちゃんとお話できたのが嬉しかった。

Liquid Glass を Metal で再現するテーマで、登壇者の方がガラスルーペなるものを購入され（Apple のデザインチームと同様に）実際に見え方を自分で試されていたのが、非常によかった（筆者もその場で注文した）。

あと Foundation Models について、追加学習はできないものだと思い込んでいたが、Adapter training という手法を用いることで可能なことを参加者の方に教えていただいた。これは試してみよう、、

イベントページ：https://japan-region-swift.connpass.com/event/353002/

Liquid Glass を Metal Shader で描きたいだけの人生だった…

temoki さん

  • 実際にガラスルーペ買って再現してみた
  • Alan Dyeの言葉 → それってMetalのこと？
  • 作ってみた
  • layerEffect modifier を使う
  • 光の屈折を distortion effect で実装
  • 他にも、、
    • 光の反射のハイライト
    • ガラスの種類
    • 液体のような近接形状の融合
    • 背景ブラー
  • 大変なので、Gemini CLI、liquid_glass_render に頼る
  • Metal への移植を Gemini にやってもらった
    • Metal の Geometry Functions に Liquid Glass 向けっぽい関数（物理ベースのレンダリングが必須）
    • アーキテクチャをドキュメント化してもらった
  • Demo

動画エフェクトに関する新技術の紹介

ShomaKato さん

“聴講メモ：WWDC25 Recap – Japan-\(region).swift” の続きを読む

聴講メモ：MOSA2025：夏のTech Dive! Follow WWDC25

昔から一度参加してみたかった、MOSA主催のイベントにようやく参加することができた。しかも会場は Apple Japan。今年2月にも、大阪でMOSA主催のイベントがあり、粒揃いのセッションテーマの中でも特に「キューティマスコットを作り直してみる」という二度とはお目ににかかれないセッションは是非拝聴したく大阪に飛ぶ覚悟もあったのだが、予定が被り叶わなかった。

全体を通して牧歌的（？）で、思い思いに技術や未来予想（妄想？）を語らう空気感がとても心地よかった。筆者が福岡時代によく通っていた Apple Users Group や、各地で開催されていた AUGM の雰囲気を思い出して、懐かしくもあった。

今回はWWDC25のフォローアップイベントということで、特に Liquid Glass のテーマが多く取り扱われていたが、その他さまざまなアップデートについても多面的に取り扱われていた。今回、大谷さんのキーノートのために参加応募したようなものだったが、Apple プロダクトの歴史を遡った上で、今回の Liquid Glass というデザインシステムのアップデートから Apple の今後を説かれており、非常に説得力があった。浮遊するUIマテリアルに関しては個人的にも、（グラス型に限らず）フォルダブルなど多様なデバイス環境を予期したものだろうと思っていたが、、グラス型にフォーカスして語られるともはや、その布石であるとしか思えなくなってしまった。しかも WWDC25 という発表タイミングは、グラス型登場の前仕込みの段階であるという推測も、、Apple やその歴史を熟知されている大谷さんだからこその見解で、目から鱗だった。

Apple 豊田さんからの Recap セッションは、ひととおりセッションビデオを観た上でもなお有用だったし、Liquid Glass の解説については先の大谷さんのセッションと並べて聞けたことも幸運だった。

他にも、Yoshikawa さんによる Claude Code によるいわゆる Vibe Coding の実践談は手法が具体的で、取り入れるイメージが湧いたし（Cursorメインで使っている）、いけださんによる Foundation Models のデモでは、筆者も実践しながら再現性をなんとなく感じていた ＜ローカライズはプロンプト言語に依存＞ ＜ただし出力言語が一定しない（説）＞ を裏付けてくださり、興味深かった。

中野さんの発表に被せるかたちで、iPad の Full screen 対応 や Liquid Glass 対応のリミットに関して Apple 豊田さんによる追加補足があり、Xcode 26 の次のバージョン以降では猶予がないという温度感だった。現実的に、開発者としてはその猶予は数年は伸びそうだと思いたいのだが、、

しかし本日さまざまな登壇者が言及していたように、Liquid Glass の目指す方向性はその見た目の「新しさ」ではなく、将来登場する新たなフォームファクタ含め、多様なデバイスに対し、いかにソフトウェアやコンテンツを溶け込ませるかにあると考えている。なので、開発者が Liquid Glass への移行を余儀なくされるのは、その見た目が古いかどうかではなく、新しいデバイス上では使い勝手が悪いから、という理由で対応圧が迫るのではないかと予想する。

イベントページ：https://mosa.connpass.com/event/354216/

Liquid Glassから見えるAppleの未来戦略

なぜLiquid Glassのアイコンの丸みはデバイスに合わせてあるのか？

大谷 和利 さん

  • 小さいことに見えて未来戦略から見ると大きいのでは？
  • デジタル環境と現実との折り合いの付け方：その最新成果だと言える
    • Liquid Glass は visionOS 26 には採用されていないのはなぜか？
    • Alan Dye「ハードウェアとソフトウェアを緊密に統合する」
    • 年代別の統合の変遷
      • OS + ソフト + ハード（’80-’90）
      • → サービス（’00）：iTunes, iCloud, Apple Music
      • → シリコン（’20）：Mチップ
      • → 現実の統合（24~）
    • UIの変遷
      • スキューモーフィズム（現実の模倣）
        • コンピュータを身近に感じさせる
        • GUIの歴史：比喩を使うことで、使い方が最初から分かる
      • フラットデザイン（現実との線引き）
        • ユーザーがデジタル環境に慣れ、画面の中だけでの完結
        • ユーザーも進化した
      • Liquid Glass（現実との融合）
        • Rを同じにした。装置と画面内との境界線を意識状で無くしていくポリシーが含まれているのでは
        • Vision Pro では現実と仮想の区別がそもそもつかない
        • それ以外はデバイスを手にするので現実仮想が区別される → Rを一致し（透明にし）一体化させることで意識状は現実と仮想の境界をなくし融合する、のではないか。
      • 半透明表現やグラスモーフィズムは、これまでも段階的に取り入れられていたが、本質的に異なる（e.g. Control Center）
        • 透明度が高いだけでなく、場所を取らないようにしている（従来的なMax幅表現でなく、寄せることで背景コンテンツの存在を多く見せている）
        • → UIがコンテンツを邪魔しない：意識の上で透明化していく
          • Vision Pro だと現実の風景
      • Alan Dye「（ガラスの工学的特性と）Appleにしか実現できない流動性を組み合わせ」
        • 他社プラットフォーム上の模倣はあくまで静的なもの、本質的な模倣ではない
        • Liquid Glass
          • 物理法則に従う、すべてに実体がある感覚（Appleは「素材」と表現）
          • 従来の拡散だけでなく、反射や屈曲もシミュレート
          • Liquid Glass の動き自体で情報を見せている
          • 背景が透けていることが重要：今は画面上だが、Vision では現実世界。そこに「素材」が浮かんでいる見せ方
          • visionOS 26 で組み込まれていないのは、まだ煮詰めができていない？隠し球になっている？
        • Material 3 Expressive
          • スケール・高さ・空間の変化に軸足を置く構造的な情報設計、動きが構造の理解を助ける。フラットをベースに奥行きと触覚フィードバックで補助
          • Expressive（表現力）を売り
          • 例：壁紙カスタマイズ機能
            1. カスタマイズ、パーソナライズの多様性
            2. 天気エフェクト：現実の天気と同期するわけではない、現実とデバイスとが分離する（Appleはこれはやらない）
      • Alan Dye「将来の新しい体験を生み出す基礎」
        • visionOS 表現がヒントになったが、visionOS に採用しているわけではない
        • 固定的デバイスよりも考えることが多くあり、実現に至っていない、その段階で他社に模倣されることを避けるために隠し球としている？
        • なぜトランスルーセント？→ より多くのコンテンツを見せるため（Visionなどグラスデバイスでは、現実世界）UI の主張が強いと、その先のものを隠してしまう。
        • Android XR のライブデモ
          • 準備中にヘッドバンド部分を擦っていた：タッチコントロールがありそう
          • 現段階では、UI が単なる透明かつ枠付き（ほとんどデザインされておらず、情報をそこに表示しているだけ）
          • Material 3 Expressive とは関係ないつくり、UI がまだ固まっていなさそう
        • Apple は、かならず来たるグラス型デバイスを、Mac や iPhone ユーザーが迷いなく使えるよう準備している、今のうちから現実との融合を図る新しいデザイン基盤に慣れてもらうための仕込みが Liquid Glass と思われる（視界を遮るUIにはならないだろう）
        • M3 Expressive は主張を強めてしまい、XR では暫定的な作りになっている可能性
      • デバイスの進化の方向性
        • Jonathan Ive：OpenAI とのプロダクト開発。
          • 自らの過ちはスマートフォンを作ったこととする内省。みなスマホばかり見ている。
          • → スマホ漬けから人々を解放するために（グラスではなく）ポケットのなかに入れたまま使えるものを開発
        • Apple Glass は、AirPods や Watch と併用により、最大限機能活用できるだろう
          • ソーシャルメディアを追うデバイスにせず、周辺デバイスと分散的に機能を補い合い、スマホ漬けから脱却する
          • Liquid Glass の発表により、登場は近いだろう
          • Android XR は Gemini によるアプリ間連携できるが、Siri ではできない：WWDC25で Siri Shortcuts などでのアプリ関連系の補強が発表された

WWDC25 Recap

Apple WWDR Design Evangelist 豊田さん

“聴講メモ：MOSA2025：夏のTech Dive! Follow WWDC25” の続きを読む

聴講メモ：CA.aab #6

Android エンジニアに転身したのもあり、会場に来てみた。ひとつひとつの取り組みが大きく聴き応えがあった。AIエージェントをQAテスト自動化に活用するユースケースはナルホド感ありとても興味惹かれた。画像ベースのE2Eテストは構築コストもメンテコストも掛かるイメージなので、試験項目書に基づく指示通り＆実質目視でテストしてくれる未来が来て欲しいし、AIエージェントとの相性も良いと思った。

イベントページ：https://cyberagent.connpass.com/event/353611/

RemoteBuildCacheの導入とビルド時間メトリクス計測のススメ

@zume_poposora さん

  • ビルド時間計測のメトリクス構築
    • ビルド時間の課題：開発生産性体験の悪化、CIコスト増大
    • メトリクス構築 → ボトルネック発見、進捗可視化、改善サイクルの確立
    • measure-builds-gradle-plugin (Automattic) を使用
      • 外部サービスに収集データや分析情報を送信
    • ビルド時間 アーキテクチャ OS情報、ビルド成否、gradle 設定情報 → 環境情報を取得送信することでビルド時間との相関性調査に
    • ローカルビルドキャッシュだけでは効率化に限界（以下ABEMA例）
      • CI runner が分かれており環境ごとでしかキャッシュ活かせない
      • M3/M4 などでもフルビルド2,30分かかり生産性下げている
    • リモートキャッシュにより：
      • 他の開発者のローカルPCでも使えるようにした
      • 大規模やマルチモジュール構成に対し恩恵大きい
  • RBCの導入
    • gcp-gradle-build-cache でリモートキャッシュを導入
      • 導入の前提条件の説明（何が必要か、セキュアの担保）
      • リージョン指定の必要性、キャッシュの自動削除設定について
  • RBCの効果
    • 定性的に「かなり早くなった」
    • 運用費：ABEMA規模でも1万円程度（CIも安くなるので十分payできる）

縦横無尽に駆け回るフォーカスをユーザーフレンドリーに制御する feat. Compose for TV

@taked_oO さん

“聴講メモ：CA.aab #6” の続きを読む

聴講メモ：Mobile勉強会 #20 ウォンテッドリー × チームラボ × Sansan

コーディングエージェント（AI）による開発の話が3割で時代の流れを感じた。が、がっつりプロダクト開発現場におけるの知見というより、まだ個人利用でのノウハウが中心（開発現場での知見は、AI専門の勉強会の方で聞けるイメージ）。Animatable や Metal などUI開発系の話は作例も見れて楽しい。懇親会でも終始、各社／個人のAI活用について（Devin や Cursor の使い分けなど）情報交換ができて参考になった。Devin について各社どれくらいACUを消費しているのか気になったが、聞き出せなかった。

個人的に深く共感した点として、堤さん発表で言及されていた、0→1が苦手な人間の性質を逆手に取り、AIに任せてしまう、はまさに初手で年々腰が重くなる筆者が同じことを考えており、人間の元来もつ（負の）性質をAIでカバーすることで、いかにして人間の本質であるクリエイティビティを解放するか？そこに夢を見ていきたいと思った。

イベントページ：https://wantedly.connpass.com/event/350442/

SwiftUIにおけるPreferenceの基礎概念

ウォンテッドリー/湊 さん

  • Preference とは
    • 子→親 の情報伝達
    • Binding Environment との比較解説
  • 活用事例
    • 下スクロールでボタン非表示：子ビューで発生したスクロールイベントを親に伝達

入社初期に意識した3つの取り組み

@hikaengineer さん

“聴講メモ：Mobile勉強会 #20 ウォンテッドリー × チームラボ × Sansan” の続きを読む

聴講メモ：Sansan×DMM.com Android Tech Talk

今月から Android 開発の担当もすることになり、勉強し始めたところ。Android のみの勉強会参加は今回が初めて。Google Codelabs で勉強したことが実際にキーワードとして登場するので、あらためて理解が深まった。

イベントページ：https://sansan.connpass.com/event/349010/

CodeRabbitと過ごした1ヶ月 ─ AIコードレビュー導入で実感したチーム開発の進化

mitohato14 さん

  • CodeRabbit 導入の経緯
    • メンバー全員の approveでマージ、朝夕口頭レビュータイム
    • レビューは細かい指摘多め、細かい部分見落としがち、品質が人に依存
    • 時間が掛かり、細かい指摘は相互に負担増
  • CodeRabbitとは
    • リポジトリ全体を考慮したレビュー
    • 概要生成、シーケンス図作成、類似リポジトリ列挙やチャット機能
    • チャットの過去やり取りは将来にも持ち越されどんどんレベルアップ
  • CodeRabbitの設定
    • GitHub アカウントログイン、ダッシュボードで有効化
    • すぐに使える、yaml で追加設定
      • instrucrions でレビュー観点を自然言語で記述可能
  • 導入しての所感
    • PR内容の要約：どのファイルがどういった内容で、まで一覧化
    • シーケンス図の生成：レビューがしやすくなる
    • 不要な指摘は、チャットでフィードバックすることで抑制可能
    • （具体的な指摘内容はスライド参照）
  • 嬉しかったこと
    • 変更要約、チャット形式でのやり取り、レビューの早さ（数秒）
    • やりとりを通じ、背景や議論をログに残せる
    • 人力レビュー前に細かい問題を減らせる
  • 変化したこと
    • 細かい指摘が減り、広い視点での実装改善レビューが可能に
    • 指摘から気づきや議論が生まれる
  • Kotlin/Android 的な指摘
    • あった（スライド参照）

AndroidアプリエンジニアもMCPを触ろう

@kgmyshin さん

“聴講メモ：Sansan×DMM.com Android Tech Talk” の続きを読む

聴講メモ：CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜

設計実装のみならず技術浸透のための取り組みも含めて解像度高く紹介されており、どのプレゼンも非常に濃い内容だった。ひとつめのTCAに関するプレゼンは、すでに自社プロダクトにTCAを導入している身としては復習要素もありつつ、Reducerの採用／非採用について感覚的だった部分が言語化されていたため、学びになった。

イベントページ：https://cyberagent.connpass.com/event/342952/

The Composable Architecture (TCA) を用いたAmebaのリアーキテクチャ

@devdazy さん

  • 従来：MVVM + RxSwift、VMは状態持たずデータを流すハブだけ
  • 課題：ロジックの複雑さ。モデル肥大化、可読性低下、保守性拡張性の低下とともに開発速度が低下
  • VM が状態を保持せず SwiftUI と相性悪い、RxSwift 依存が Concurrency と相性悪
  • TCA の概要
  • メリット・デメリット
    • Good：ロジックが明確になり、見通しが良くなる
      • すべてのイベントが列挙される。非同期処理のEffectで状態更新できないため、成功失敗を網羅的に書かざるを得ない
      • テストの網羅生にもつながる
      • e.g. 読み込みだけでなく、読み込み完了後の処理もテスト書かなければ失敗する
    • Good：画面遷移をシームレスに移行できる
      • SwiftUI → UIViewControllerへの遷移
      • TCA x UIKitでは、ほとんど SwiftUI と同じインターフェイスで実現できる
    • Good：ロジック分割が簡単にできる
      • ロジックである Reducer を別の Reducer に分割・合成したりできる
      • Action / State は親からも観測できる
    • Bad：学習コストが高い
      • フレームワーク丸々ひとつに対する理解が必要
      • TCA独自の記法
      • 例を作り、マイグレーションドキュメントを作り、テンプレ機能を活用する
    • Bad：パフォーマンスが最良ではない
      • Reducer を分割しやすい反面、不要な View にも Reducerをつけがち。（Action送る処理は負荷が高い）
      • Action を極力減らすよう吟味が必要
      • View 側での処理完結も選択肢に
    • Bad：Point Freeに依存
      • RxSwiftの例に同じ
    • 記法のブレがかなり抑制されるのは Good

Q&A

  • 分割粒度について：画面の量にもよるが、スクロールしない画面では基本的に1画面 1 Reducer だが、セクション持つような単位ではセクションごとに分割する
  • ロジック持たない限りは Reducer 持たせない（ボタン置いてあるだけとか）、通信して自身を更新するばあいは Reducer を持たせる

SwiftUI導入から1年、SwiftUI導入とVueFluxライクな状態管理

@TyrionJP さん

“聴講メモ：CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜” の続きを読む

聴講メモ：potatotips #90 iOS/Android開発Tips共有会

同僚と物理参加。ネイティブアプリへのFlutter組み込みで、Add-to-app の存在は知っていたが具体的な手法を知れて良かったし懇親会でも詳しく話を聞くことができた。ほかiOSDC運営の方ともお話しでき、今年のiOSDCでは5、6年ぶりに当日スタッフで参加しようかと考えていたところなので、その熱意をお伝えした。

イベントページ：https://potatotips.connpass.com/event/341264/

Flutter の Add-to-app でナビゲーションスタックが Flutter → ネイティブ → Flutter になってしまう場合の技術選定事例

@tfandkusu さん

  • Add-to-app : ネイティブの一部だけをFlutter実装
  • 3つの概念
    • FlutterEngine：ネイティブから作成、複数可
    • FlutterFragment (or FlutterViewController)
    • MethodChannle：ネイティブ間との情報受け渡し
  • 2つの問題
    • 以前の表示が一瞬残る
    • 1つのFlutterEngine x 複数の FlutterFragment で古い方が真っ白
  • 解決方法：FlutterFragment の付け外しをせず複数使う
    • アプリの性質上 Fragment 間の連携なさそうだったのでOK

iOSアプリの定期リリースとそのための自動化

@hiragram さん

“聴講メモ：potatotips #90 iOS/Android開発Tips共有会” の続きを読む

聴講メモ：Sansan x DMM.swift

大規模なSwift移行プロジェクトから、最新のiPadOS対応のテクニックまで。
Pro SwiftUIは、発表を聞くに4、5年前に読んだ「Thinking in SwiftUI」と重なる内容も多いと推測されるが、あらためて最新情報を体系的に学びたいため、プレゼン終わり即購入した。

イベントページ：https://dmm.connpass.com/event/336359/

DMMオンラインサロンのSwift移行

大門 弘明 さん

  • SwiftUI アプリで Redux を採用
    • VIPER での課題を解決したい
    • RN 時代の設計を流用、宣言的 UI や SSOT な状態管理を実現したい
  • Redux を SwiftUI でどう実装したか
    • Redux+Saga
    • SelectState と UseDispatch
  • 状態の更新が View に即座反映され、共通処理の一元化ができるようになった
  • 処理順序が旧アプリと同じのため、移行時にビジネスロジックの考慮漏れを防げた
    • が、同時にイケてない部分の解消ができなかった
  • パフォーマンスに課題があり（メモ化検討）

Q&A

  • TCA 採用に至らなかった理由
    • 流行り始めたのが Swift 化のあと、キャッチアップに時間が掛かる
    • 外部ライブラリへの依存をしたくなかった（RxSwift の二の舞）
    • Redux であれば Web でも使っているし、薄く作れるものとして採用
  • 既存実装の再利用について
    • アーキテクチャは全て捨てたが、API クライアントやコンポーネントなどは再利用した

DMMブックスへのTipKit導入

宗像 恒 さん

“聴講メモ：Sansan x DMM.swift” の続きを読む

聴講メモ：Ebisu.mobile #8 大忘年会 STORES kubell Kyash asken

良いユニットテストの書き方、イベントログの確認方法とaskenさんおふたりの発表内容が自社課題にダイレクトヒットして明日から実践したいと思える内容だった。失敗談から導かれた「コト」に向かう組織作りの取り組みも、目指したい効果に立ち返ってトライしたいと思った。

イベントページ：https://hey.connpass.com/event/335971/

開発生産性から振り返るエンジニアリングマネジメントの失敗2選

@sudo5in5k さん

  • Four Keys の計測結果から得られたEMとしての失敗
  • ドメイン知識に対するメンバー間の知識差から、組織体制変更の影響が発生 → 誰が欠けても生産性を出し続ける仕組みづくり
  • 組織で「コト」へ向かうために
    • モブプロ／ドキュメント作成／プロセス標準化（担当が変わっても取り組めるくらい丁寧に。チケット、PR、docs）
  • Four Keys 測定意図のすり合わせ
    • 本来の意図は健康状態の測定だったが手段と目的が逆転
    • 共通理解・共通価値観の設定が大事 → パフォーマンスを出すにはケイパビリティを変えよ（DORA Core Model から）
  • 個人の価値観にブレはあるが、会社のバリューは絶対的価値観
    • バリューに即した価値観や行動の洗い出し

いいね問題に対する技術選定事例

@tfandkusu さん

“聴講メモ：Ebisu.mobile #8 大忘年会 STORES kubell Kyash asken” の続きを読む