トーク

ソフトウェアエンジニアには、経済産業省のデジタルスキル標準にあるように、「変化の激しい状況の中でも、他のステークホルダーと柔軟に連携し、価値を生み出す」能力が求められます。

AI時代に求められるエンジニアの能力を伸ばすために、私たちは「エンジニアとクリエイターの共創」体験をつくり、たった一人のユーザーに絞って価値創出能力を鍛える「N1エンジニアリング」手法を活用しています。

本トークでは、クリエイターと共に開発を行う「N1エンジニアリング」の実績を基に、自らエンジニアとして共創した実体験と、全国の30名のエンジニアへ開発体験を提供した視点を持って、未来を担うエンジニアの育成手法を共有します。

具体的な内容は以下となります。
・他業種連携を強める共通認識の形成方法：
　プランナー・デザイナー・エンジニアの役割を再認識し、共創体験で見えた良き領域侵犯。
・ユーザーの本質理解を深めるためのN=1の分析方法：
　ユーザーの悩みにフォーカスし、課題解決に繋げるデプスインタビューと課題の着眼点。
・アイデアをMVP（Minimum Viable Product）に落とし込むプロセス：
　独自のフォーマットによるアイデア立案と、MVPへの棚卸し。

このトークが、次世代型エンジニアになりたいと思っている方や、次世代型エンジニアを育てたいと思う方へ、一つの手段として参考となれば幸いです。

音は重要な要素であり、よりリッチな体験を実現するためには不可欠です。
効果音やBGMが鳴ることで、アプリの世界観を強調するだけでなく、使い勝手やユーザーの満足度を高めてくれます。
しかし、タイミングを誤ると、ユーザー体験が損なわれる可能性もあります。

例えば、多く使われているフレームワークとしてAVAudioPlayerがありますが、もしサイレントモードでも音を鳴らしたい場合には他のアプリのバックグラウンド再生を止めてしまうことがあります。また、アプリ内で特定の画面でBGMを鳴らす際には、ライフサイクルを考慮しないとアプリを閉じてもBGMが鳴り続けてしまうこともあります。

本トークでは、iOS / iPadOS アプリにおける音の取り扱いに焦点を当て、ユーザー体験への影響と対処法について解説します。
具体的には以下の内容をお話しします。

• AVAudioPlayerを使用した音の再生・停止のライフサイクルの理解
• 利用シチュエーションでの課題
  • 効果音を鳴らすと、他のアプリがバックグラウンド再生を止めてしまう
  • SwiftUIでBGMを追加したら、BGMが流れない画面でも鳴ってしまう
  • 音量の調整とその影響
• プロダクトに適合した音の利用方法の提案

このトークが、音の体験について考えるきっかけとなれば幸いです。

Swiftのプロトコルは、異なる型に共通のインターフェースを定義・提供しますが、プロトコル自体は直接的に型として機能しません。プロトコルの利用は、存在型、ジェネリクス、およびOpaque Typeを介して行われます。このトークでは、Swiftにおけるプロトコルの利用方法の違いがコンパイル結果に与える影響を観察し、最終的なパフォーマンスにどう影響するかを解析します。

キーワードは、プロトコルを実装した構造体をコンパイルすると生成される "Protocol Witness Table" です。このテーブルは、プロトコルのメソッドが構造体の具体的な実装にどのように対応するかをマッピングします。このトークでは簡単な例から生成したコンパイル結果をSwiftライクな擬似言語でわかりやすく提示し、このテーブルの具体的な役割を解説します。
特にジェネリクスやOpaque Typeを用いた場合のメソッド呼び出しのインライン化や性能面における存在型の特徴といったパフォーマンスに関わる部分を重点的に解説します。
最後に今回の調査で分かったこれら3つの方法の利点と欠点を簡単にまとめます。

このトークはプロトコルの扱いに慣れてきたSwiftプログラマに向けたものです。
このトークを通じてプロトコルの理解が深まり、自信を持って3つの方法を使い分けられるようになることを目指しています。

iOSで地図を扱うには通常、MapKitが広く利用されています。MapKitを使用すれば地図上の現在位置情報を容易に扱えますが、このトークではMapKitを使用せずに任意の地図画像上に現在位置を表示する方法について解説します。

これを実現するために、以下のポイントについて詳しく説明します。

1. 位置情報の基準点設定
2. 位置情報の許可設定
3. 現在地の表示方法
4. 位置情報が更新された際に呼ばれるデリゲートメソッド
5. 地図上の2点の緯度経度情報から現在位置のXY平面座標を算出する際の計算処理
   これらの要素を組み合わせることで、MapKitを使用しない地図アプリの基礎から実装までを網羅的に理解できるようになります。

私はこの春、自社開発の企業に新卒入社しました。
かなり大規模なサービスを扱っているので、はじめはコードを読んでもちんぷんかんぷん。
バグ修正の際も、該当コードを特定するのでさえかなり時間がかかっていました。
すぐさまメンターの方に相談すると、
「自社のサービスに出来るだけ毎日触れてください。仕様書と照らしながら。」 と言われ、 「それだけ？」 と思いながらも実践してみることに。
それ以来、仕事プライベート問わず毎日30分から1時間ほど自社サービスに触れるようにしています。
その際、具体的には以下を意識しました。

1. ドキュメントやデザインと見比べて仕様を確認し、挙動や設計がよくわからないところはコードをチェックする
2. 疑問に思ったことは職種を問わず色々な人に聞く
3. 仕様書から漏れている内容はすぐにドキュメントを書く

この習慣を続けることで、バグ修正のスピードが大幅に向上しただけでなく、サービス全体の理解が深まり、遥かに効率的に業務を進めることができるようになりました。

入社間もない時期に仕様理解をガチるとめっちゃお得だよ！という話を具体例を交えてお話ししたいと思います。

Swift言語におけるエラー処理のメカニズムは、他のプログラミング言語と共通する命名や概念を持ちながら、その実装と性能の特性において独自のアプローチを取っています。本トークでは、Swiftのエラー処理の仕組みを具体的なコード例とそのコンパイル結果を通じて解説し、他の言語との比較を行います。

発表では、まずシンプルな例を通じて、エラー処理付きの関数がどのようにコンパイルされるかを示します。特に、throwキーワードの周辺で行われる処理、つまり通常の戻り値処理に加えたエラーオブジェクトの伝達、およびtry周辺でのエラー検知と分岐処理に焦点を当てます。

そしてコンパイル結果の観察から、Swiftが如何にして他言語と類似の構文を提供しながら、実行時の負荷を軽減しているかを明らかにします。比較対象としてJavaを挙げて、類似の構文を提供しながらもその実装方法と実行時の性能に違いがある点を簡潔に解説します。

このトークはさまざまなエラー処理方法を一通り学んだSwift中級者へ特にお勧めできるものです。
このトークを通じてtryを利用したエラー処理の性質をより深く理解し、さまざまあるエラー処理方法の中から状況に応じた適切な方法を選択できるようになると考えています。

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」では、デザインの一貫性や生産性を向上するためにデザインシステムを導入しています。
デザインシステムを構築するには、タイポグラフィ、カラー、UIコンポーネントなど多くの要素が必要であり、既存のプロダクトに取り入れるのは非常に労力がかかります。
このトークでは、機能開発の傍らでデザインシステムを段階的に導入していった経験と、2年間にわたり続けた結果どのような効果が得られたか、「REALITY」のiOSアプリにおける実例を元に紹介します。

• アプリにデザインシステムを少しずつ導入していくステップ
• デザインシステムによって、アプリ全体のカラーテーマの調整が容易になったこと
• FigmaからXcodeへ画像アセットを自動エクスポートすることで効率化したこと
• Figmaを使ったUIコンポーネントの管理と、SwiftUI/UIKitでの実装

アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」では、デザインの一貫性や生産性を向上するためにデザインシステムを導入しています。
デザインシステムを構築するには、タイポグラフィ、カラー、UIコンポーネントなど多くの要素が必要であり、既存のプロダクトに取り入れるのは非常に労力がかかります。
このトークでは、機能開発の傍らでデザインシステムを少しずつ導入していった経験と、その中でも特に効果的だったカラーと画像アセットの自動エクスポートについて、「REALITY」のiOSアプリにおける実例を元に紹介します。

• アプリにデザインシステムを少しずつ導入していくステップ
• デザインシステムによって、アプリ全体のカラーテーマの調整が容易になったこと
• FigmaからXcodeへ画像アセットを自動エクスポートすることで効率化したこと

Swiftでのアプリ開発は直感的であり、多くの開発者に支持されていますが、性能や安全性で注目を浴びている言語Rustと組み合わせることによって、プロダクトの移植性や性能をさらに引き上げることができます。このトークでは、Rust製ライブラリをSwiftアプリケーションに組み込む手順を、わかりやすく説明します。

前半は、RustをC言語のライブラリとしてビルドし、ライブラリをSwiftや他のclang系言語で使えるように、適切な設定を施す方法を紹介します。

後半はライブラリをSwiftで使う方法を二つ紹介します。一つはSwiftのコンパイラを使った直接的なアプローチ、もう一つはSwift Package Managerを利用した方法です。各手法の特長と具体的な適用手順を簡潔に説明します。

また、SwiftUIとの組み合わせ例も紹介するので、Rustの機能をフロントエンドにどう活かすことができるか、具体的なイメージを持っていただけるはずです。

このトークは、Rustなど他の言語にも興味があるSwift開発者や、アプリの移植性や性能を高めたい方に向けたものです。RustとSwiftの組み合わせにより、アプリ開発の新しい可能性がどのように広がるかを提示します。

「家族アルバム みてね」(以下「みてね」)では、2023年10月から本格的にSwiftUIを導入し、新規画面の実装を中心にSwiftUIを積極的に使ってきました。現在約15%の画面がSwiftUIで実装されています。

みてねには「職能にとらわれずにタスクを取る」という文化が根付いているため、iOSやSwiftに詳しくない人にもわかりやすくなるよう、以下の特徴を持ったシンプルな設計を採用しています。

• プレビューがしやすい
  • 高速にプレビューできる
  • さまざまなUIの状態を簡単に用意できる
• OSSライブラリに依存していない
• みてねAndroidアプリと似た設計
• Observationフレームワークへの移行が容易

本セッションでは、どのようにして上記特徴を実現しているのか、具体的なコードを交えてご紹介します。

OSSのコントリビュートに対して、不安や敷居を不用意に大きくしていないだろうか？

「ましてや、AppleのOSSなんて仮にトライしてもメタメタにされる・・・」、と過剰に ざわざわ・・・ する必要はない。

実際にはオープンで新参者にも公正なスタンスのコミュニティが待っている。

驚くほど小さな修正でも価値がある。
先日、初めてAppleのOSSにコントリビュートした。
内容はselfキーワードが不要な部分を削除するだけ、それでも、レビューを貰いマージすることができた。

小さな修正であっても、どういった構成や方針を元に運用されているかを知るキッカケになり、非常に勉強になった。

具体的なステップとして、以下のポイントを取り上げていく。
・OSSプロジェクトの探し方
・PRを立てるまでの具体的な一例
・取り組んで得られたこと

コントリビュートはPRを送信するだけではない、質問に答えたりバグを報告することも含まれる。（Swift.orgのContributingより）

エンジニアであるなら、人生でOSSにコントリビュートしてみたい気持ちが少なからずあるのではないだろうか？
平凡な自分が踏み出した小さな一歩を共有して、誰か1人の一歩を踏み出すキッカケができたなら嬉しい限りである。

「だがこれでいい！」の精神で、OSSにコントリビュートしよう！

現在、多くのアプリではABテストが広く使われていますが、次のステップとして個別最適化が求められています。
AとBを比較するだけでなく、ユーザーの行動パターンに基づいたセグメント分割を行い、ABテストでは拾えなかったユーザーにもアプローチすることでより高い効果を得ることができます。
私たちのアプリではユーザーごとに異なる最適な課金画面を提供することで、収益の最大化を目指しました。

このセッションでは、複数パターンの課金UI検証を通じて得た以下の内容についてお話しします。

• 複雑な検証をデグレさせることなく、高速に実現するための設計と、その実装手法
• 複数パターンの課金画面を安全に運用するための工夫とその課題
• 個別最適化の成果として、ユーザーの課金率にどのような影響を与えたか

このセッションを通して、皆さんのアプリでも効果的なUIの個別最適化を実現しましょう。

Swiftは型安全な言語です。
しかし、Swiftで書かれたものが全て型安全になるわけではありません。
Swiftで書かれたコードの中にも、より型安全なコード、あまり型安全ではないコード、のように「型安全の度合い」は異なってきます。
型安全性が低いと、安全でないキャストが必要だったり、不正な入力値がコンパイルエラーにならなかったりし、開発者は多くのことを考えコードを書く必要があります。
一方で型安全性が高いと、より多くのことをコンパイラに委ねることができ、開発者が考えるべきことは減ります。

このトークではNotificationCenterのラッパーを題材に型安全性を高める方法を取り上げます。
NotificationCenterはObjective-C由来のインターフェースを持つため、安全でないキャストが要求され、不正な値を渡してもコンパイラエラーにならず、型安全性はあまり高くないといえます。
そんなNotificationCenterのラッパーの作成を題材に、Swiftの言語機能であるジェネリクスやマクロを用いて、型安全性を高めていく技術について紹介します。
題材はNotificationCenterですが、皆さんがこれからデザインするインターフェースにも通じる考え方と技術を紹介します。

このトークを通して、皆さんが"より"型安全なコードを書けるようになることを目指します。

手塩にかけて育てたミュージックライブラリがぶっ壊れた経験はありますか？私はあります。

5年前、OSX Catalinaの登場時にiTunesが廃止され機能ごとにアプリが分かれました。
その後、新しいミュージックアプリでは様々な問題が起こりました。

• アルバムアートワークが消えた
• 読み仮名のコピーができない
• ジャンルが勝手に書き換わる

(※全部筆者が経験したことです)

万単位にのぼる楽曲を1個1個精査して正しい状態に復旧するのは当然ながら非現実的です。
更にミュージックアプリの使い勝手の悪さも相まって泣き寝入りを余儀なくされました。

ですが、そこに救世主が現れました。そう、 ScriptingBridge です。
しかし ScriptingBridge はObjective-CがベースなのでSwiftで扱うには一工夫が必要です。

本セッションでは、macで他アプリケーションと連携するための仕組みである ScriptingBridge を使ってミュージックライブラリから楽曲情報を取得・編集する方法と、それによって壊れた楽曲情報を半自動で復旧した話をします。

多くのプロジェクトでは何らかのライブラリを活用してアプリの機能開発や自動化等を行っていると思います。
「家族アルバム みてね」でも、現在約30個のライブラリを活用して日々開発を行っております。

しかし、ライブラリのおかげで効率化できている一方で、ライブラリ起因の負債も多々ありました。具体的には、「更新が止まっているライブラリに依存している」「古いバージョンのライブラリを使い続けている」などです。これらの負債によって、Xcodeのアップデートでビルドエラーが発生して予想外に時間を取られたり、ライブラリの新しい機能を使えないことで追加の開発が必要になるなど、作業のスピード感に影響が出てしまっていました。

本セッションでは、依存するライブラリ起因の負債を解消するまでの具体的なステップと、負債を生まないために導入した仕組み、実際に運用してみた成果をお話します。特に以下のポイントについて詳しく説明します。

• ライブラリ周りの負債の分類と対応方法
• ライブラリのアップデートにおける仕組みづくりとQA

「Tint Colorをデフォルトのまま使うと、初心者感がありチープに見えるから避ける」
ある日の自分はそう考えていました。しかし、Appleが推奨する色をこのような理由で軽率に変更するのは適切なのでしょうか？いいえ、デフォルトの設定には、それなりの理由が存在するはずです。実際、デザインの一貫性やユーザー体験の向上を考慮した結果として、デフォルトの青色が選ばれている可能性があります。

本トークは、青色が選ばれた背景を以下の観点から考察していきます。

・他OSとの比較から見える共通点
・初代iPhone OSから現在のiOSまでのデザイン変化
・iOSとMac OS のデザインの共通点と違い
・カラーディスプレイの登場による影響
・ハイパーリンクが青色である理由
・青色が持つ視覚的効果と心理的影響について

このトークを通じて、Appleのデザイン哲学や、その背後にある考え方を深く理解することができるようになります。デフォルトの青色を軽視せず、その価値を再評価することで、より洗練されたデザイン選択ができるようになるでしょう。

iOS開発者なら誰しも一度は目にする、デフォルトの青いTint Color。この色が選ばれた理由について、考えたことはありますか？本トークでは、その裏に隠された秘密を探ります。

まず、Appleのデザイン哲学や他OSとの比較、歴史的な経緯に基づき選択の理由を明らかにしていきます。次に、青色が持つ視覚的な特性について、色彩理論や人間の視覚に関する研究を交えながら、なぜ青色が適しているのかを探ります。

このトークを通じて、Appleのデザイン哲学やその背後にある考え方を深く理解することができるようになります。そしてデフォルトの青色を軽視せず、その価値を再評価することで、より洗練されたデザイン選択ができるようになるでしょう。

iOSアプリ開発のCI/CD運用には、どのツールを使用していますか。多くの企業がソース管理にGitHubを利用していると思いますが、GitHub Actionsの利用には無料枠があり、それを超えるとビルド時間に応じて料金が発生します。

本トークでは、GitHubホステッドランナーからセルフホストランナーに切り替えた際のメリットとデメリットについて、具体的な事例を交えてご紹介します。これにより、皆さんがセルフホストランナー環境を構築する際のヒントを提供することを目指しています。

具体的には以下のポイントをカバーします:

1. 切り替えの動機と背景
2. セルフホストランナーのセットアップ手順
3. コスト削減効果の具体例
4. 運用中の課題とその解決策
5. セキュリティとパフォーマンスの比較

「SwiftってAppleデバイスでしか動かないじゃん？」
そう言われ続け10年、しかし現状は大きく異なります。
Swiftは現在、LinuxやWindowsのような他OSでも動作することに加えて、組み込み機器での利用を想定した軽量なバージョンも提供されています。
つまりSwiftは多種多様な環境で実行できるポテンシャルを秘めているのです。

そして、それはゲームボーイアドバンス（以降、GBA）のようなレガシーなデバイスも例外ではありません。
GBA開発は誰でも手軽に実行環境を用意できるという魅力があります。
今年4月からApp Storeでのエミュレータ配布が認められたのは記憶に新しいかと思います。

しかし、GBA向けに開発をするにはいくつかの工夫が必要です。
GBA向けにコンパイルの設定をしたり、リンク時に参照できないシンボルの解決をする等、開発環境を整えるのにも一手間かかります。
本セッションでは、SwiftのプログラムをGBAで動作するようにコンパイルする方法を解説します。また、Swift Packageを使った開発環境構築、BreakPointの貼り方等のデバッグ方法、および具体的なプログラム例も併せて紹介します。

このセッションを通じてGBAの開発環境を構築する方法や、swiftcやEmbedded Swiftについての知識を得ることができます。

今では多くの開発者にとって、APIはアプリ開発の基盤となっています。しかし、個人開発においてニッチな情報を取得したい場合、APIが提供されていないことが少なくありません。このトークでは、APIがない環境でも学生向けの学修サポートアプリを実現するために、WKWebViewによるJavaScriptとの相互通信などの活用事例について経緯を踏まえて紹介します。

APIが当たり前の時代に開発を始められた方々にとって、これらの技術を習得することで、APIがない環境でも柔軟に対応できるようになり、開発の選択肢が大幅に広がるようになります。このトークを通じて、あなたも新たな技術的アイデアを得ることができるでしょう。

また、大学に学生用のアプリがない学生開発者の皆さんへ
「自身で大学のアプリを作り、学生生活を向上させたい！」と思うきっかけなれば嬉しいです！