これから書く場所を、はてなブログから「しずかなインターネット」に移すことにしました。
はてなブログはこのまま残しておきます。
過去の記事についても、いくつか移しています。
これからは、生活のこと、趣味のこと、仕事のことなど、そのとき書いておきたいと思ったことを新しい場所に書いていく予定です。
新しい場所はこちらです。
今後はこちらで書いていきます。
モバイルエンジニアのAI活用事例紹介
この記事は、 Kyash Advent Calendar 2025 4日目の記事です。
昨日は加藤さんの EM半年の振り返り、プレイヤー脳を捨てきれていない自分へ でした 👏
はじめに
KyashでiOSアプリを開発している tamadon です。
皆さん、AIエージェント使ってますか？
KyashではAIツールの利用補助が出ることもあり、エンジニア全員が積極的に活用しています。最近はClaude Codeを利用することが多いです。
勤務開始が早めなこともあり、同僚が稼働する前の時間に 設計の壁打ちをAIとできるのが特に助かっています。
この記事では、モバイルアプリ開発において私が日常的に利用しているAIの活用例を2つ紹介します。
続きを読むカードゲームはいいぞ
はじめに
この記事は、 Kyash Advent Calendar 2023 の14日目の記事です。
今日は自分が趣味で遊んでいるカードゲームについて書こうと思います。
遊戯王、ポケモンカードゲーム、ONE PIECEカードゲーム等、世の中にはたくさんのカードゲームがありますが自分がプレイしているのはマジック:ザ・ギャザリング(以下マジックと略)です。
マジックは1993年に発売された世界初のトレーディングカードゲームで、子供の頃ビックリマンシールにハマっていた自分は「友達とカードを交換できて、しかもそのカードで対戦出来るなんて最高やん！」ということですぐにマジックの虜になりました。
大会にも積極的に参加し、自分の人生に大きく影響を与えた趣味です。
過去の履歴を探したところ、初めて大会に参加した1996年からかれこれ27年間遊んでいるみたいです。
頻度は減りましたが、この趣味を通じて知り合った友人とは今でも連絡を取りあって遊んだりお酒を飲んだり、年賀状のやり取りで近況報告したりする生涯の友人です。
カードゲームをやっていて良かったこと
自分の経験から、カードゲームをやっていて良かったことについて書いてみようと思います。
論理的思考が鍛えられる
カードゲームというのは手札や場にあるカードを使用して最適解をみつけ、勝利を目指すゲームの性質上論理的思考が必要になります。
上達するコツとして「自分の選択肢を論理的に説明できる」というものがあり、「なぜ自分がその選択肢をとったのか」他者に説明することで自分の思考を言語化することで有識者からのフィードバックを得られるようになり更に上達出来るという側面もあります。
そう考えると、仕様をアルゴリズムに落とし込んで実装するというエンジニアの仕事に似ているかもしれません。
想像力・分析する力が鍛えられる
カードゲームというのは基本的に相手の手札が見えません。
相手の手札を想像したり、刻一刻と変化する状況を分析しながら「自分がこうしたら相手はこうしてくるだろう」とか「相手にこのカードを使われたら厳しいから、今はこういう行動をとっておこう」といった感じで数ターン先を見越した思考をする場面が多いです。
自分が日常生活でもこういう思考を自然と行うようになったのは、カードゲームの影響が大きいと考えています。
メンタルが鍛えられる
カードゲームにはトップデッキ(トップデック)という用語があります。
意味は「重要な局面で一番必要なカードを山札の一番上から引くこと」といった感じでしょうか。
「自分がこのカードを引いたら勝てる」「相手にこのカードを引かれなければ勝てる」ということがたまに発生します。
それまで優勢だった状況をこのトップデッキによりひっくり返されて負けたことも数え切れないくらいあります。
そういった経験から「人生や仕事で今順調に進んでいてもいつどうなるかわからない」という思いが根っこにあるため、大抵のことでは一喜一憂することはなくなりました。
過去に働いた会社でも「安定感がすごい」という評価をいただいていたので、カードゲームで遊んでいて良かったと思います。
ただ、家族からは「感情の起伏に乏しい」と言われています 😂
さいごに
このように自分にとってはかけがえのない趣味であるカードゲームについて紹介しました。
最近はデジタル版もあるので、比較的始めやすい環境かなと思います。
この記事を見て少しでも興味を持ってくれる方が居たら嬉しいです。
ユーザーの負担を下げる会員登録画面
はじめに
この記事は、 Kyash Advent Calendar 2023 の6日目の記事です。
自分が所属しているチームでは、「会員登録完了率(アプリのインストールから会員登録を完了させるまで)の最大化」を目標の一つとして取り組んでいます。
先日リリースした施策の一つとして、会員登録画面の改善を行ったので紹介します。
画面表示時にTextFieldにフォーカスをセットする
TextFieldがある画面を表示する場合、画面表示時にTextFieldにフォーカスがセットされているとすぐに入力を開始出来るので会員登録率の改善が見込めるかも知れないということになり対応しました。
今回はiOS15以降で利用可能なFocusStateを使用することにします。
以下のようにSwiftUIのonAppearでBool型のFocusStateにtrueをセットすることで実現可能です。
struct ContentView: View { @State private var text: String = "" @FocusState private var isFocused: Bool var body: some View { TextField("", text: $text) .focused$isFocused) .onAppear { DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) { isFocused = true } } } }
実際の挙動はこのように、画面表示のタイミングでメールアドレスのTextFieldにフォーカスがセットされていることが確認できました。
キーボードの改行ボタンを押した時に次のTextFieldにフォーカスを移動する
また、複数の入力項目がある画面では次のTextFieldをタップせず、キーボードの改行ボタンをタップすると次のTextFieldにフォーカスがセットされるとユーザー登録時の負担が軽減できそうです。
こちらもFocusStateを使用することで実現可能です。
以下のようにEnum型のFocusStateを用意して、TextFieldのonSubmitでfocusStateに値をセットすることで実現しました。
struct ContentView: View { @State private var text1: String = "" @State private var text2: String = "" enum Field: Hashable { case textField1 case textField2 } @FocusState private var focusedField: Field var body: some View { TextField("", text: $text1) .focused($focusedField, equals: .textField1) .onSubmit { focusedField = .textField2 } TextField("", text: $text2) .focused($focusedField, equals: .textField1) .onSubmit { focusedField = .textField2 } } }
実際の挙動はこのように、改行ボタンを押すことで次のTextFieldにフォーカスがセットされている事がわかるかと思います。
まとめ
SwiftUIのFocusStateを利用することで、結構簡単にフォーカスの制御が行えることがご理解いただけたかと思います。
現在はこちらの施策をリリースしてABテストによりデータを分析しているフェーズですが、これからもより良いユーザー体験を実現するために改善を行っていきます。
iOSアプリエンジニアがKotlin Multiplatform Mobileを使って感じたこと
はじめに
この記事は、 Kyash Advent Calendar 2022 の14日目の記事です。
Kyashのモバイルアプリ開発ではKotlin Multiplatform Mobile(以降KMM)を採用してUI以外のロジックを共通化しています。KotlinやAndroid Studioに触れてこなかったいちiOSエンジニアの感想を書いてみたいと思います。
KMM関連の記事については、チームメンバーの記事も公開されているので興味があればご覧ください。
KotlinとAndroid Studioについて
KMMはKotlinで記述されており、Kotlinでコードを書くにはAndroid Studioを使うのが便利です。
どちらも業務でガッツリ使用するのは初めてだったので、最初は若干不安がありました。
実際は、Androidチームメンバーとペアプログラミングを行い不明点をその都度質問が出来たので、とてもスムーズに開発することが出来ました。
KMM開発の理解度の高いチームメンバーに感謝しかありません。
Xcodeと異なる操作感に戸惑うことも0ではないですが、Android Studio（というかJetBrains製IDE?）の完成度が高い点にうならされることが多いです。
特にコードのサジェスト機能（こう書いた方がKotlinっぽいよと推奨してくれる）が優秀だなと思いました。
ロジックの共通化について
上記画面の赤枠で囲った部分はKMMで表示条件を管理しています。
一部抜粋ですが実際のコードを紹介します。
KMMでこのようにStateの状態を定義し
// 各ステップにチェックを入れるか
val isApplicationCompleteChecked
get() = when (applicationStatus) {
REQUESTED, PREPARING, SHIPPING, ACTIVATION_REQUIRED, ACTIVATED -> true
else -> { false }
}
// "申し込み完了"と"郵送"の間にあるバーの進捗状況
val betweenApplicationAndShippingProgress: ApplicationProcessProgress
get() = when (applicationStatus) {
REQUESTED -> InProgress(0.5f)
PREPARING, SHIPPING, ACTIVATION_REQUIRED, ACTIVATED -> Complete
else -> { Todo }
}
Swift UI Viewはstateの値を参照して表示を切り替えるのみという実装にしています
IssueStatusView(
isChecked: state.isApplicationCompleteChecked,
applicationProcessProgress: state.betweenApplicationAndShippingProgress
)
このコンポーネント表示条件判定処理に誤りがあり、修正が必要になったのですが、KMM側を修正するだけでiOS・Androidのコードは修正不要で、正しい挙動をするようになりました。
そのための仕組みなので当たり前ですが、強力なメリットを感じました。
課題に感じていること
ここまでは良いことを書いてきましたが、自分が課題に感じていることもいくつかあるので書いてみたいと思います。
リードタイムの増加
KyashではiOS・Android・KMMを別リポジトリにて管理しています。またKMMの成果物をXCFrameworkとしてSwiftPMで配布しています。
つまり、KMMに修正があると以下の処理が必要になります。
KMMの修正 -> KMMの成果物を配布 -> 成果物をiOSアプリで取り込み
この成果物配布とiOSアプリへの取り込む時間が結構かかっており、何とかしたいとチームメンバーが問題提起してくれて、対策を考えている状態です。
Gradleチョットムズカシイ
KMMはGradleというビルドツールで管理されています。これがiOSアプリエンジニアである自分には馴染みがなく、何となく苦手意識を持っています。
社内でGradleの基本（普段実行しているgradlewコマンドのwはwrapperのwだよ、等）から理解する勉強会を実施していただいたことにより、苦手意識は結構減りましたがエラーが出るとドキドキしています。
こればっかりは経験を積むしかないですね。
おわりに
いかがでしたでしょうか。
まとめると「KMMは大変な点もあるけど、チームメンバーと一緒なら乗り越えられるしロジック共通化のメリットは大きくこれからも拡大していきたいです！」って感じです。
「KMM興味あるけど、実際のところどうなの？」と気になっている人の参考になれば幸いです。
Kyashでは仲間を募集しています。興味があれば是非ご応募ください。
2021年 Kyash のiOSチームがやってきたこと
この記事はKyash Advent Calendar 2021の14日目の記事です。
KyashでiOSチームのTech Leadをしているtamadonです。
自分が入社当時は2名だったiOSチームも現在は3名になり、以前より機能開発以外でもやれることが増えてきました。
この1年でKyashのiOSチームがやってきた改善についてご紹介します。
Swift Package Manager(以下SwiftPMと略)の導入
iOS版Kyashの依存ライブラリ管理は今までCarthage+CocoaPodsを併用していましたが、Carthage管理しているライブラリの更新を行う際に差分が大量に発生してつらいという問題がありました。
そこで、Xcode12.5から外部ライブラリをDynamic Frameworkとしてビルドできるようになったこともあり、Carthage管理化のライブラリをSwiftPMに移行しようということになりました。
一部、SwiftPM対応していないライブラリがあるのでそれはCocoaPodsに移行しました。
ライブラリ更新時に差分が大量に出ることもなくなり、Appleが公式でサポートする仕組みに乗るというのは安心感がありますね。
ライブラリの更新処理を一部自動化
サーバサイドのチームがDependabotを利用してライブラリの更新Pull Requestを自動作成しているのを見ていて、うらやましかったのでiOSチームでも導入することにしました。
fastlaneはBundlerでインストールしており、Dependabotで更新チェック出来るようになったのですがCocoaPods管理のライブラリはそうはいきません。
色々調査した結果、Timersさんのブログを発見しこちらのスクリプトを参考に導入しました。
今まで何となく気づいた人がライブラリの更新作業を行っていたのが自動化されたので良かったです。
SwiftPM管理ライブラリの更新処理はまだ行えていないので、もし良いやり方をご存じの方がいればご連絡お待ちしております🙏
毎週App Store Connectへのアップロードを自動で行いアップロード可能な状態になっているか確認するようにした
以前、Appleへの申請直前になってアップロードがエラーになることがありバタバタした経験から定期的にアップロードが成功しているか確認出来るようにしました。
導入したことにより、申請時にドキドキすることが減りました。
一部画面をSwiftUIで実装
履歴詳細画面をリファクタリングするのと一緒にSwiftUIで実装するトライを実施しました。
最近は新規画面をSwiftUIで実装することも多く、ここで先にリリースしたSwiftUI実装の構成が新たに実装する際のお手本になっており非常にありがたいです。
詳しい話は以下の記事を参照ください blog.kyash.co
一部処理をGitHub Actionsに移行
iOS版Kyashの開発では、今までCIサービスをBitriseに一本化していました。Mobileチームのメンバーも増え、Android版の開発でもBitriseを利用していることもあり同時並行数上限に到達してBitrise Workflow完了まで待ち時間が発生するようになっていました。
そこでBitrise Workflowで実行しなくても良いもの、例えばPull Request作成時のDangerによる静的解析等をGitHub Actionsへ移行しました。
これによりPull Request作成時のチェック処理がBitriseとGitHub Actionsの並列で実行されることになり、チェック処理も若干早くなったように感じます。
また、今まで手元のローカル環境で実行していたアプリのバージョンアップスクリプトの実行等もGitHub Actionsへ移行しました。
こちらもローカルの環境に依存することがなくなり良い変更だったと思っています。
App StoreのメタデータをGitで管理しfastlaneで更新するようにした
今までは手動でApp Store Connectからストア画像やリリースノート等のメタデータを更新していましたが、これをGitで管理しfastlaneから更新するようにしました。
更新する際にGitHub上でレビューが可能になり、細かいtypoにも気づきやすくなりました。
また、メタデータをGit管理することで過去の情報が追えるようになりました。
QA用バイナリ配布時にAutifyにもアップロードするようにした
KyashではAutify for Mobileを使用してE2Eテストの自動化に取り組んでいます。
今まで手動でアップロードしていたのですが、QAメンバーにテスト用アプリをDeployGateで配布する際にAutifyへのアップロードもするようにしました。
こういう、手動で繰り返しやると地味に面倒な作業は積極的に自動化していきたいと考えています。
まとめ
軽い気持ちで「今年1年のチーム振り返りを書いてみるか」と思ったら結構多くのことが出来ていて、ボリューム増になってしまいました。
自分一人では出来ないことばかりなので、チームの皆に感謝です。これからも色々な改善を行い、ユーザーへ価値を届ける速度を上げていきたいと思っています。
Kyashでは仲間を募集しています。興味があれば是非ご応募ください。カジュアル面談でも大歓迎です。
Kyashに入社して1年くらい経ちました
この記事はKyash Advent Calendar 2020の14日目の記事です。
KyashでiOSチームのTech Leadをしているtamadonです。
早いものでKyashに入社してもう1年が経とうとしているので振り返ってみようと思います。
何をやっていたか
プロダクト開発：採用：その他 ＝ 8： 1.5： 0.5 くらいの割合でやっていました。
- プロダクト開発
- 採用
- 書類審査・面接
- 面接方法の整備
- 新メンバー用オンボーディングフローの整備
- その他
- iOSアプリのリリースフロー整備
- 過去バージョンiOSのサポート終了ルール決め
- iOS Test TeaTime #1登壇
入社前は「Kyashって結構プロダクトとして完成されている印象があるから今から入社して新規の機能開発とかあるのかな？」と思っていたのですが、目指す世界の実現のために実装していく機能が多く開発タスクが無くて暇になるということはありませんでした。 ガツガツプロダクト開発をしたいと思って入社したのでこれはありがたかったです。
ガツガツプロダクト開発をした結果、iOS版Kyashリポジトリのコミット数が2位になりました（Deleteがメチャ多いですがCarthageで管理しているライブラリの更新をしたからです）ちなみに1位とは文字通り桁が違うので自分が1位になる日はだいぶ先のことになりそうです。
リモートで勉強会に登壇したのも良い思い出です。最初はどうなるか不安もありましたが参加者のリアクションを後で確認したら好意的に受け取られているようで嬉しかったです。
Kyashで働いていて気に入っている点
質問に対するレスポンスが早い
詳しくはPdM（プロダクトマネージャー）araiの記事を参照いただきたいのですが、こういう風に考えて行動しているPdMが居るのはありがたいです。
PdM（スクラムにおけるPO）にはあらゆる方面から常に質問が飛んできます。心がけているのは、質問に対して即答できること、そして理由も一緒に伝えること。 そのためには瞬時に判断できるように考えつくしておく必要があります。 もちろん自分が想定できていなかった有難い指摘には感謝し、朝令暮改の判断をすることも。日々鍛錬あるのみです。
開発していて仕様について悩んだ時、質問してシュッと回答が来なかった事がないです。自分もそれに影響されて既存仕様について質問されたらシュッと回答出来るように心がけています。
実装難易度が良い感じに高い機能開発が多い
Kyashの機能開発は自分にとって実装難易度が良い感じに高くてやりがいを感じています。
具体的にはアニメーションを用いたユーザー体験を提供する機能やユーザー認証系ですね。今まであまりこういった実装を経験してこなかったので、学ぶことが多くて楽しいです。
Sign in with AppleのiOSアプリ側の実装を担当したのですが、どうすればセキュアな実装になるかサーバサイドエンジニアと議論しながら実装したのも良い経験になりました。 Sign in with Appleを既存ユーザーも利用可能にするか？という点についても議論して、既存ユーザーの自分が使いたいというのもあり実装工数が増えましたが、チームの皆でこだわって実装した事により社内からは良いフィードバックがもらえたのも良い思い出です。
 | |
ここらへんの話は別の機会にKyash Blogの方で書いてみようと思っています。
色々改善する速度が早い
Kyashでは毎週金曜に振り返りを行っているのですが、そこで問題提起した事が来週には改善されているという事が多いです。
例えば、1週間のうち水曜と木曜にミーティングが散らばっていて開発に集中しづらいという問題を提起したら、翌週から木曜に一本化されてミーティングも連続して実施されるようになりました。
もちろん全てが自分の思い通りという訳ではないですが、変化していける組織というのは良いですね。Kyashで働いていて継続的にストレスを感じたことはないように思います。
おわりに
そんな感じで、毎日楽しく働いています。もしKyashで働くことに興味があればTwitterのDMで良いのでお気軽に連絡ください。
