Kyash iOSアプリのライブラリ管理をSwift Package Managerへ完全移行しました

KyashでiOSエンジニアをしている@nekowenです。
今回はiOSチーム内で以前から取り組んでいたライブラリ管理のSwiftPMへの完全移行を果たしたため、その経緯と結果について公開します。

2023-03-13

iOS版 Kyash Widgetのエラーハンドリング事例

はじめに

はじめまして。KyashのモバイルチームでiOSアプリの開発を担当している emoto です。

今回は、KyashアプリのWidgetでどのようにエラーをハンドリングしているのかを紹介します。私自身、実際に開発してみてデータ取得時にエラーが発生した場合にどうやってViewに伝えるのか悩んだのでこの記事が誰かの助けになると嬉しいです。

KyashアプリのWidgetではアプリを開かずに残高とポイントが確認できるので是非使ってみてください！

データ取得の成功と失敗をどう区別するのか

Widgetで表示するデータを取得する際に呼ばれるメソッドは下記のようになっています。

func getTimeline(
    for configuration: ConfigurationIntent, 
    in context: Context, 
    completion: @escaping (Timeline<Entry>) -> ()
)

developer.apple.com

Viewにデータを渡す時は引数で渡される completion() に取得したデータをTimelineでwrapして渡して、呼び出します。

completion( Timeline(entries: entries, policy: .atEnd) )

Timeline でwrapするデータは TimelineEntry に準拠する必要があるので、

struct ResponseEntry: TimelineEntry {}

struct ErrorEntry: TimelineEntry {}

のように定義して、API通信処理の結果でswitch文で呼び分ければ良さそうです。

func getTimeline(for configuration: ConfigurationIntent, in context: Context, completion: @escaping (Timeline<Entry>) -> ()) {

    ...

    // API通信処理の結果
    switch result {
        case .success(let entries):
            let timeline = Timeline(entries: entries.map { ResponseEntry }, policy: .atEnd)
            completion(timeline)
        case .failure(let error):
            let timeline = Timeline(entries:[ErrorEntry(error)], policy: .atEnd)
            completion(timeline)
    }
}

しかし、これだと上手く行きません...

注意してcompletion()の定義を見てみると

completion: @escaping (Timeline<Entry>) -> ()

となっていて渡せる TimelineEntry は1つの型になっています。なので、API通信処理の結果によって ResponseEntry or ErrorEntry を渡すことができません。

そこでKyashではどう実装しているかというと、Widgetで表示するデータとAPI通信処理の結果を保持する TimelineEntry を定義しています。

struct ResponseEntry: TimelineEntry {
    let date: Date
    let result: Result
}

enum Result {
    case loaded(data: ResponseData)
    case error(message: String)
}

struct ResponseData {
    let hogehoge: String
}

enumで定義した Result は馴染みがある形じゃないかなと思います。

View側で参照する時は下記のように実装します。

import SwiftUI
import WidgetKit

struct SampleEntryView: View {
    let entry: ResponseEntry

    var body: some View {
        switch entry.result {
        case let .loaded(data):
            LoadedView(data: data)
        case let .error(message):
            ErrorView(message: message)
        }
    }
}

自分だったらこう実装する！というコメント大歓迎なので、コメントいただけると嬉しいです。

最後に

Kyashでは一緒に働いてくださるエンジニアを募集中です。 Fintechにご興味のある方是非是非選考のご応募待っております。

herp.careers

Kyashについてもう少し知りたい方はこちらからもどうぞ！

Productブログ：https://blog.kyash.co/
Kyash People：https://note.com/kyash_co/
Podcast：https://open.spotify.com/show/36D8klfwbNF3ger0blVXH3
採用リポジトリ : https://github.com/Kyash/recruitment

2023-02-17

Kyash QAエンジニア/マネジャーの募集要項の詳細

はじめに

こんにちは、Kyashの品質管理を担当している、Tokkiです。
Kyash QAチームで、QAエンジニアとQAマネジャーの募集を開始しました。

herp.careers

https://herp.careers/v1/kyash/Pe3iokatGiNGherp.careers

たくさんの方に興味をもっていただきたいので、募集要項で記載している人物像や業務内容を少し詳細にお伝えしたいと思います。

募集している職種について

組織構成

Quality Assuarance(以下QA)チームはプロダクト部門の中の一つとして存在しています。 Kyashのプロダクト品質をサポートする横断的プラットフォームとして、頼られる存在であるとともに、品質向上のためなら積極的に行動をしていくアグレッシブなチームを目指しています。

QAチーム構成

新しいメンバーが加わり、嬉しくも1人体制からチームとして拡大・成熟していくフェーズになりました。
現在社内メンバーは、テスト自動化エンジニア2名、QAエンジニア1名、QAマネジャー1名。外部委託のQAエンジニアが5名（3月からは7名に増員予定）の構成になっています。

Kyashの開発は目的ごとにチームが構成され、QAメンバーも担当者としてアサインしています。チームメンバーの一員として朝会を始めとした各種ミーティングに参加し、企画立ち上げ段階からリリース、リリース後の振り返り・改善までを一緒に走ります。

まだ組織的にはスタートアップの要素が大きく、役職や職責に囚われすぎずある程度振り幅のある中で活躍が可能です。

各職責ごとの大きな役割を参考までに記載します。

Software Engineering in Test (SET)

E2Eテストの一部自動化、CI/CDの環境構築、テストツールの作成、自動化戦略の立案等
様々な自動化・効率化を行うエキスパート

Quality Assurance (QA)

品質向上に必要な仕組みづくり、取り組み改善（シフトレフト、テストプロセス、プロダクト）、テスト計画・設計・実行・改善・戦略立案・管理　等
QAチームのパフォーマンスを高める&プロダクト品質評価のエキスパート

Quality Assurance (QA) Management

Kyashに求められるベストな品質保証の体制を構築する
テスト自動化の牽引・プロダクトリリースに関する品質保証の管理・監督・向上
チーム全体の力を引き出し引き上げる、品質全体のエキスパート

Kyashのプロダクト開発

主力の開発であるKyash アプリへの新規追加以外にも、「法人送金サービス」(法人から個人のKyashアカウントへ、報酬や売上金などを送金できるサービス。また、事業者の所属社員に対する経費精算の支払いにも活用可能。)の開発と運用も行っています。

今年も大型の新規機能の追加が予定されており、会社としてプロダクト部門への期待と注力はより高まっています。お客様へスピーディに良い機能をお届けするためには、QAチームもより強いチームに成熟していくことが必要です。
そして今回の募集に至りました。

Kyash開発のスタイル 2023.2月現在

Kyashのプロダクトには大きく次の3つの特徴があります。

提供しているサービスが決済をはじめとした金融に関するもので、安全・安心・正確さを実現する高い品質保証が求められる
柔軟な開発を基本としており、リリースまでの開発からテスト実施期間は短く常に変更が加わる
金融などの法務関連の複雑さを、なんとかシンプルなプロダクト仕様に落とし込んでいる

これらの特徴をもつプロダクトにおいて、お客様へのサービス提供までの開発期間を短くし、品質はしっかり担保していくことが求められます。そのためには取り組んでいくべき課題、取り組みたいことがたくさんあります。

頼られる・強いQAチームへ成熟するために、今私たちが考えていることの一部をお伝えします。課題をみてメラメラと闘志の炎が燃えてきた方は、QAエンジニア、マネジャーへのご応募を是非ご検討ください。まずは話を聞いてみたいという方のカジュアル面談も大歓迎です。

QAエンジニア / QA Engineer - 株式会社Kyash

https://herp.careers/v1/kyash/Pe3iokatGiNG

「成熟」「強さ」のためにやること

『QAチームはKyashのプロダクト品質をサポートする、横断的なプラットフォームとして、社内から頼られている存在になること』

プロダクト作りはKyash全体で取り組む意識を持っています。そこでより良いプロダクトをリリースしていくために、QAが何をサポートしていくことができるのか？

アジャイル開発において、QAはより敏捷で柔軟な考え方・動きができる個人であり・チームであることが求められます。 ※出典：The Testing Manifesto www.growingagile.co.za

最後にテストするよりもずっとテストし続ける
バグの発見よりもバグの防止を重視する
機能性をチェックするよりもチームが理解している価値をテストする
ただバグを発見しシステムを破壊するよりもバグの作り込みを防ぎ、最高のシステムを構築することに努める
テスターの責任よりも品質に対するチームの責任として捉える

上記のようなアジャイルテストにおけるマインドセットが、親和性が高いかもしれません。目指すのは各文章の後半の考え方と行動です。チームをどうスケールさせていくのか、品質でのアプローチ体系をどう発展させていくべきか、各々が自ら考え・行動し成果をあげていく努力をしています。

チャレンジしていきたいことは、たくさんあります！これらは一部です。

プロダクトのデリバリースピードを速めつつ、品質を落とさないためにはどうすればいいか？
強いチームになるためにはどうすればいいか？
新しいメンバーが現場に適用し、パフォーマンスを出せるようになるまで期間を短くするための改善方法は？
テスト自動化の運用を浸透させていくにはどうするか？

もちろん上記の課題の改善には取り組みをはじめています。でもまだまだ力が足りません。私たちと一緒にプロダクト全体と積極的に関わり、力を発揮してくれる方のご応募お待ちしております。まずはカジュアル面談のご応募でも大歓迎です！

QAエンジニア / QA Engineer - 株式会社Kyash

https://herp.careers/v1/kyash/Pe3iokatGiNG

最後に

Kyashにはプロダクト愛を持ったメンバーがたくさんいます。それだけに品質に関しての取り組みで生じるコミュニケーションも、誰もが積極的かつ好意的です。
世の中にあるQAエンジニアの定義に縛られず、Kyashで新しいQAエンジニア、QAマネジャーの存在と価値をあなたの手でつくりだしてみませんか？
ポジティブに行動できる人を応援する文化があるKyashで、一同お待ちしております！

2023-01-14

Zapierで毎月1日にSlackの雑談チャネル一覧をお知らせする

Kyashの @konifar です。

Zapierで毎月1日にSlackの雑談チャネル一覧をお知らせするようにしてみまして、なんだかよさそうなので紹介します。

2022-12-25

Kyashのある暮らしに向けて

この記事はKyash Advent Calendar 2022の25日目（トリ！）の記事です。 Kyash創業者の鷹取です。

今年の振り返り

早いもので2022年も残すところあと数日です。去年のアドベントカレンダーでは「Kyashが大切にするクラフトマンシップについて」について書きました。

2022年を振り返りますと、Kyashカードによる決済のポイントとは別でポイントが貯まる「Kyashリワード」や、国際ブランドのJCB/AMEX（American Express）や楽天銀行等をはじめとする金融機関様からの入金手段を追加させていただいたこと、そしてKyashとして初となるカードの共同発行の取り組みとしてブラジル人コミュニティの皆様向けにMAURICIO STUDIO CARDの発行を開始致しました。 Kyashがサービスとして日の目を浴びた2017年から5年が経ち、サービスの運用態勢の改善についても前進した年だったように感じます。

また、会社としては春先に54億円のシリーズDの資金調達を行い、今秋には表参道から青山一丁目にオフィスを移転致しました。引き続き、お金周りのライフスタイルサービスの開発に努めて行きたいと思います。

去年のAdvent Calendarエントリーの最後に予告的に記した、「Kyashは何を変えたのか」、「ユーザーの暮らしに貢献したポジティブな変化」について書きたいと思います。

Kyashが目指したこと

キャッシュレスやデジタル社会は、今まで不可能であった多くのことを可能にしてきました。同時に、仕組みや制度が追いついていないものが世の中にたくさん生まれました。金融も、その一つだと考えています。そういった社会の変化によって生まれる歪を解消したい。そして行く行くは、その歪みの解消に留まらず、テクノロジーによって便利になることを更に増やしていけることができれば、ユーザーにとっても社会にとっても重要な貢献を果たせるのではないかという大きな希望を持っています。

百貨店の掛け売りが起源とも言われるクレジットカードも、今では大変多くの利用者が様々な場所で利用する決済手段となりました。（下図）

キャッシュレス化の促進が叫ばれる日本でも、月間支出の半分以上をカード決済にされていらっしゃる方もいらっしゃいます。今まで、お財布の中で管理できていたお金がデジタルになる時、きっと多くの人がデジタルでお金を管理した方が便利になると考えたでしょう。現実は、支払う体験は確かに便利になったと言えますが、その後の管理については複雑さを増したように感じる方も多いのではないでしょうか。ニュース番組でも、キャッシュレスを「見えないお金」と表現することもあるくらいです。 Kyashでは、決済において「見える化」に着目して、人びとのお金をより扱い易くしていくところに貢献したいと考えてきました。そのために、日本でもいち早くカード決済時にプッシュ通知で決済の内容を通知する仕組みや、利用明細を即座に生成する仕組みを開発してきました。また、「見える化」の対象をKyashが発行するVisaカードに留まらず、Kyashのカードを紐づけられるSuica等の電子マネーやQRコード決済なども含めていきたいと考えています。

決済は、暮らしにおけるお金の接点で最も身近なものだと思います。上記のような「見える化」は、キャッシュレスが浸透していく上で、地味ではありますが確実に必要なインフラだと信じています。

来年からはデジタル給与が解禁されるとも言われています。当社を含む資金移動業者にとっては、変化の大きな年になります。Kyashは、ユーザーの日々の様々なお金の接点で、必要とされる存在を目指していきます。

Kyashは何を変えるのか

Kyashは、テクノロジーを通じて従来の制約にチャレンジしていくことでサービスの利便を向上し続けていくこと、そして金融をライフスタイルサービスとして再設計することで利用者の暮らしに必要なサービスや機能を一元的に提供していくことを大切にしています。金融は、物質的なモノが存在しない分、差別化が難しいと言われます。確かにその側面はありますが、Kyashは機能やスペックの比較だけで差別化を目指しているわけではありません。 Kyashの挑戦は、上記二つの大切にしていることをユーザー起点で行うことです。ユーザー起点とは、お金に関わる行為に対してユーザーに主導権がある形で実現すること。ユーザーが、リアルとデジタルが融合する社会において自分のお金をいつでもどこでも好きなように把握して管理し、扱えるようになる状態、ここに近づけていきたいです。

インターネットとスマートフォンが浸透し、様々な業態が「民主化」されたと思います。例えば、道路で行き交うタクシーに「乗せてもらう」だった感覚が、手元のスマートフォンでタクシーを「呼ぶ」ような感覚になった。お金に関しても、このような体験を創っていけると思うのです。

「お金」が人類の大きな発明であり、姿や形状を変える中で、計り知れない利便をもたらしてきました。Kyashは、その変化に対してより多くの人びとが恩恵を受ける世の中に貢献すべく、独立系としてユニークな立場から挑戦を続けて参ります。 Kyashが、ユーザーの暮らしにポジティブな貢献を果たしていると言えるには、まだまだ長い道のりがあります。しかし、「小さくても」必ず存在していて、ゼロヒャクの世界でなく、着実な前進を続けていくのみだと考えています。

Kyashはおかげさまで今年、100人を越える所帯になりました。日々難しい挑戦に向き合い、道を創ろうと共に奮闘してくれるチームに感謝をしながら、来年もOne Teamで取り組んでまいります。引き続き、よろしくお願いします！

※ Kyashではミッションに共感してくださる方の採用を強化しています。こちらに募集ポジションを記載しておりますので、弊社の採用チームまたは私までご連絡くださいませ！

2022-12-19

カスタマーサポートの面接を担当して気づいた３つのこと

これは、Kyash Advent Calendar 2022の19日目の記事です。

Kyash（以下、当社）でカスタマーサポート（以下、CS）を担当しているすーもです。この記事では、私がCSで面接を担当して気づいた３つのことを紹介します。去年のAdvent Calendarでは『Kyashの全社会議"All Hands"が2021年にやったこと』をしたためました。

2022-12-17

2022年Kyash Androidチームがやってきたこと

これは Kyash Advent Calendar 2022 の17日目の記事ですこんにちは。@dosukoi_androidです。

2022年Kyash Androidチームは色んなことをやってきました。それをずらずらと書いていこうと思います。

Compose本格導入

2月にリリースしたKyashリワード機能からJetpack Composeを本格的に導入しました。それまでに試験的に一部画面でComposeを導入することはありましたが、丸々1つの機能をComposeで作り上げることは初めての試みでした。初めての本格導入ということで、まだチーム内のComposeに関するお作法が決まっていなかったり、ハマりどころがわかっていないこともあり、かなり苦戦する部分もありましたがこのプロジェクトで培ったナレッジをチーム全体で共有できたのは大きかったです。 Composeであまり使われていないMotionLayoutを使ったり、まだaccompanist時代のWindowInsetsなども使いました。

KMM本格導入

同プロジェクトでKMMの本格導入も始まりました。こちらもCompose導入と同じくお作法が決まっていない、ハマりどころがわかっていない、などの苦労もありましたが、なんとかリリースまで持っていくことができました。 KMMは未だにチーム内で設計の議論が多く行われていて、「Kyashの中でKMMのあり方はこう！」みたいなものが完全に決まっているわけではありませんが、日々の議論の中で少しずつ洗練されていっているので今後が楽しみです。

これはAndroidチームというより、Mobileチームの取り組みです。 Kyashで初めてWidgetのリリースを行いました。 Widgetのナレッジがない中、iOSエンジニアと相談しながら進めていきました。 Mobileチーム内に閉じた話だったので、仕様からリリース時期の設定まで全てエンジニアが行うプロジェクトでしたが、いい形に着地できたんじゃないかと思います。

独自ViewModelの廃止

KyashはJetpackのViewModelが誕生する前からリリースされていたアプリです。それ以前からMVVMというアーキテクチャは存在していたため、独自にライフサイクルに合わせてkillされるようなViewModelを作っていました。ですが、JetpackのViewModelが誕生してからそちらを使うようになり、JetpackのViewModelと独自のViewModelが混在している状況が発生していました。そこで2021年中頃から独自のViewModelを廃止して、JetpackのViewModelに統一しよう、という流れになっていました。 2021年にある程度の独自ViewModelを消すことができ、まだ残っていたかなり大きめの独自ViewModelを2022年にほぼ消すことができました。記憶は定かではないですが、統一しようと話が出てきた頃は100以上の独自ViewModelがあり、骨が折れる作業だなと思ってましたが、終わってみるとかなり嬉しいものですね。

Compose Themeの策定

これは主に@_rmakiyamaさんが主導してくれたものです。 Kyash AndroidはComposeを導入したのはいいものの、ダークテーマ対応を見越したThemeの設定ができていませんでした。というのも色の設定をするのに

@Composable
fun Hoge() {
    Box(modifier = Modifier.background(color = KyashTheme.colors.blue))
}

というように直接色の設定をしていました。本来はprimaryやsecondaryを使うべきです。それをmakiyamaさんが「ダークテーマ対応の時に泣いちゃうよ」と助言をくれたので、入社して2週目くらいのタスクでお任せすることになりました。

マルチモジュール分割

Kyash Androidは元々マルチモジュール構成にはなっていたものの、大半の機能がcoreモジュールに集約していました。新規機能は新しくfeatureモジュールを作るものの、既存機能はcoreモジュールから切り離せていない状況でした。これではマルチモジュールの恩恵をうまく享受できません。coreモジュールをいじるといちいちビルドに時間がかかるし、coreモジュール内ならどこへでも依存できてしまいます。ということで、機能ごとにモジュールに切り出すことになり、2022年初めは5つのfeatureモジュールだったところを12個のfeatureモジュールに分割できました。計測してないのでフルビルドが早くなったかは不明ですが、coreをいじることは確実に減ったと思います。

これから

今年は古くなっている技術を新しい技術に置き換えていったり、新しい技術を取り入れたりしてきました。ですが、まだまだ古い技術を採用している部分、Deprecatedになっているのに放置されている部分が数多く存在します。(warningが400近くあったり...) 新機能の実装も大切ですが、プロダクトの保守性もかなり大事です。そしてKyashはそれをエンジニアだけでなく、多くのPMやbizのメンバーも理解してくれているので、保守性を高めていくことを是とする文化になっています。来年も新しい技術の導入やリファクタリングをたくさん進めていけたらいいなと思っています。 Kyash valueの”頂点思考”にもあるように、これからもKyash Androidの技術を最高の技術に近づけられるように頑張っていこうと思います。

おわりに

Kyashの技術に興味がある方、俺ならもっとKyashをイケてるプロダクトにできるぜ！という方、イケてない技術を見るとワクワクする方、ぜひお話ししましょう。 * Podcast Kyashfm * Kyash People Team | note * 株式会社Kyash の全ての求人一覧

Kyash Product Blog

Kyash iOSアプリのライブラリ管理をSwift Package Managerへ完全移行しました

iOS版 Kyash Widgetのエラーハンドリング事例

はじめに

データ取得の成功と失敗をどう区別するのか

最後に

Kyash QAエンジニア/マネジャーの募集要項の詳細

はじめに

募集している職種について

組織構成

QAチーム構成

Kyashのプロダクト開発

Kyash開発のスタイル 2023.2月現在

「成熟」「強さ」のためにやること

最後に

Zapierで毎月1日にSlackの雑談チャネル一覧をお知らせする

Kyashのある暮らしに向けて

カスタマーサポートの面接を担当して気づいた３つのこと

2022年Kyash Androidチームがやってきたこと

Compose本格導入

KMM本格導入

Widgetリリース

独自ViewModelの廃止

Compose Themeの策定

マルチモジュール分割

これから

おわりに