こにふぁー氏は何を基準に、開発組織の方針を決めている？ 事業・プロダクト・人の状況次第で変化するVPoEの動き方

株式会社Kyashは「新しいお金の文化を創る。」というビジョンのもと、デジタルウォレットアプリ「Kyash」を展開する、Fintechスタートアップ企業です。Kyashでは決済に関する機能を内製開発し、リアルタイム通知やカードロック、上限金額設定などユーザビリティの高い機能を実装してきました。また、「Kyash Card」のリリースや資金移動ライセンスの取得、3Dセキュア対応など、デジタルウォレットとしてさまざまなチャレンジをしています。

同社の開発組織を支えてきたのが、VP of Engineering （以下、VPoE）の小西裕介（通称：こにふぁー）さんです。「組織作りやプロダクトの方針策定、採用、開発など、VPoEとしての業務内容は企業のフェーズに応じて変化してきました」と語るこにふぁーさん。今回はこにふぁーさんに、Kyashがどのような判断基準のもと、開発組織の方針を策定してきたのかを聞きました。

Kotlin Multiplatformの導入で開発効率化を実現

――今回のインタビューでは、過去に取り組んだ技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。

まずはモバイルアプリ開発の事例です。KyashではAndroid・iOSの両方でアプリを展開しています。通常であれば、Android側はKotlin、iOS側はSwiftを用いて、画面やビジネスロジックなどをそれぞれのプラットフォームで別々に実装することが多いですよね。Kyashも昔はそうだったのですが、ある時期からKotlin Multiplatformという仕組みを導入しました。

画面はそれぞれKotlinとSwiftで別個に書くのですが、ビジネスロジックやデータ取得の処理などをKotlin Multiplatformで共通化したんです。これは、当時モバイルアプリチームのエンジニアリングマネージャーを務めていた@kkagurazakaが推進してくれた施策です。

――どのような経緯でKotlin Multiplatformの採用を決めたのでしょうか？

もともと、モバイルアプリチームのメンバーたちは「AndroidアプリとiOSアプリの両方に同じ処理を別々で実装するのは二度手間だ」とか「仮にAndroidアプリ側のエンジニアの手が空いていても、Swiftを書けないとiOSアプリ側のヘルプに入ることができない」といった課題を抱えていました。

その状況の改善に向けて、当時のエンジニアリングマネージャーがみんなを集めて、「1年後に、Kyashのモバイルアプリ開発の状況はどうなっていてほしいか」の認識を合わせるためのミーティングを実施したんです。そのミーティングでは、「なるべくAndroidアプリとiOSアプリでロジックを共通化して、爆速で開発できるといいよね」という話で盛り上がりました。

もしコードベースを統合して開発できれば、AndroidアプリとiOSアプリの両方で同じ処理を書かなくて済みます。かつ、人員のアサインもかなり柔軟にできるようになります。そこで、Kotlin Multiplatformを導入してロジックを共通化しました。ただ、画面に関してはそれぞれ別個で実装するほうがユーザー体験のよいUIを実現しやすいので、そこは共通化しない方針を選びました。

――Kotlin Multiplatformの導入における工夫はありましたか？

当時のエンジニアリングマネージャーがかなり上手にプロジェクトを推進してくれて、導入がスムーズにいきました。具体的には、Kotlin Multiplatform導入プロジェクトの初期フェーズで、そのエンジニアリングマネージャー自身が一気に手を動かして手本になるようなコードを書き、その内容を共有したんです。

また、業務委託のメンバーでKotlin Multiplatformに詳しい方がいたので、その人からも知識を上手に吸収して、アプリの一部分をスピーディーにKotlin Multiplatformへと移行しました。この一連の流れが、移行プロジェクトにおいてかなり有効に働きました。

こうした技術刷新のプロジェクトは、うまくいかないパターンがあります。たとえば、新しいアーキテクチャをそもそも設計しきれなかったり、設計方針は決まったものの移行プロジェクトの進め方がまずくて頓挫したり。でも、この事例ではそれが起きなかったんです。

この事例を踏まえた教訓として、まずは一部分でもいいから新しい技術を導入して運用に乗せること。そして、小さな成功体験を作ってそこから範囲を広げていくことの重要性が挙げられると思います。

――Kotlin Multiplatformを導入したことによる成果はいかがでしょうか？

開発効率が良くなり、タスクのアサインの調整もしやすくなりました。それから副次的な効果として、他の部分をKotlin Multiplatformに載せ替えていく作業そのものにエンジニアたちが楽しさを覚えて、モチベーションが向上しています。新技術の導入プロジェクトですし、移行にあたって考えることが適度な難易度で存在しているので、技術的探究心をくすぐられる状況になったんだと思います。

組織の形態がアウトプットやアウトカムにも影響を与える

――他の事例についてもお話しください。

次は組織についての話で、これは失敗した事例なのですが、2022年頃に「開発組織全体でタスクの優先順位づけをして、最も優先度が高いタスクから順に担当するプロジェクトチームを組成して進めていく」という方針を選んだことがありました。社内のリソースをなるべく有効に活用するための方針策定で、ウォーターフォール開発などでは一般的に用いられる方法ですよね。エンジニアリングマネージャーたちとも会話をしたうえで、「今のフェーズならばこの方針が良いだろう」ということで決めました。

良かった点として、予定していた機能は確かにリリースできました。でも、だんだんとメンバーが主体的に物事を考えにくくなってきて、タスクの割り振りや人のアサインなどを考えるのが中央集権的になり、マネジメント層の負荷がどんどん大きくなってくるんですよね。そしてメンバーからマネージャーに対して、「次は何をやりましょうか」という趣旨のコミュニケーションが増えていきます。

なぜなら、優先度の高いタスクというのは事業を左右するくらいの影響度があるので、企業や開発組織全体の状況を鑑みたうえでリソースの配分を決める必要があるからです。となると、マネージャー以上のレイヤーでないとなかなかリソースプランニングができません。

そうすると、だんだんとメンバーは「これをやるべきだと思います」「私がこれをやります」といった意見を出しにくくなり、「何かを上長やプロダクトマネージャーが決めてくれることが当たり前」というスタンスになってしまうんです。自発的に動かなくなってしまいます。また、障害対応のように突発的に発生するタスクもすべてマネージャー以上のレイヤーが判断して優先順位づけをせざるを得なくなってしまいました。

結果として、調整作業が大変だったわりにはアウトプットも増えず、プロダクトとしてのアウトカムもついてこない。そして、エンジニアリングマネージャーやプロダクトマネージャーも疲弊して、メンバーのモチベーションも下がるという悪循環になってしまいました。

現在はその仕組みをやめて、もっとみんなが主体的に動けるような組織にしていくために、プロジェクト単位ではなくプロダクトのフィーチャーごとにチームを分割しています。例を挙げると「ユーザーを新規に呼び込むことを担当するチーム」などで、昨年の11月にリリースされた新機能「Kyashコイン」を担当したのはそのチームです。

――この事例を踏まえて、チーム編成における読者へのアドバイスはありますか？

『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』のように、組織構造のデザインパターンを紹介している書籍が世の中には存在します。そういった本をエンジニアリングマネージャーや事業責任者たちが読んだうえで、チームメンバーにも内容を共有し、チーム編成の方針を決めていくのが良いと思います。

ただ、あくまでその知識はメンバー同士が共通認識を得て、考えるとっかかりにするくらいに留めるべきかなと思っていて。自社の組織構造をすべて書籍で紹介されているような「あるべき論」に当てはめようとすると、どこかで無理が生じると思うんですよね。ある程度、自分たちの組織の状況に合わせた調整や、チーム間での役割の越境なども必要だと考えています。

「VPoE自身が手を動かすこと」が最善のケースもある

――他にはどのような事例がありますか？

VPoEとしての動き方に関する事例として、2023年の中頃から終わり頃にかけて「自分自身もプレイヤーとしてコードを書く」という選択をしました。Kyashでは多言語対応や「Kyashコイン」、ユーザー登録フローの改善など複数機能の開発が予定されており、かつ2023年中にそれらの成果を見たいという方針を打ち出していました。

実現するためにさまざまな選択肢がありましたが、自分で手を動かそうと決めました。Kyash社内には、プレイヤーとして私より優秀なメンバーはたくさんいるんですよ。でも、社内のステークホルダーとの調整とかプロジェクトの進め方といった面で、私自身が直接的にプロジェクトに関与したほうが進めやすいのは確かでした。

そこで、昨年の後半はそういった動き方をしたほうが良いと判断し、プレイヤーに徹しました。そうして各種の機能がリリースできたので、今後は徐々にチームから抜けて、より長期のスパンを見据えた仕事に手をつけていきたいです。

――読者のなかにも、エンジニアリングマネージャーやVPoEなどを務めていて「自分自身が手を動かすべきか、そうでないか」を判断しなければならない局面に置かれている人がいると思います。どのような基準で方針を決めるべきでしょうか？

「どのくらいのタイムスパンでどういった成果を出したいのか」によると思います。冒頭で述べたKotlin Multiplatformの事例のように「まずは誰かが短期間で目に見える成果を出して、その実績を踏まえて後続の作業を他の誰かに任せるほうがうまくいく」というケースもあります。その場合は、むしろマネージャーが率先して例を示すほうが良いですよね。

私自身の事例のように、「2023年のうちに成果を見たい」という短期的なスパンでプロジェクトを進める場合も、自分が手を動かすほうが良い結果が出ると予想できます。でもこれが、たとえば数年がかりでプロジェクトを進めていきたいというように、より長期のタイムスパンでものごとを考える場合は、その役割を担ってくれる人を採用するなど組織作りにフォーカスした動き方になったと思います。

腰を据えて、Kyashの成長に貢献していきたい

――今後、こにふぁーさんがKyashで実現したいことは何ですか？

2023年にはいろいろなことが改善して、Kyashの事業や開発組織はすごく良い状態になってきました。VPoEとして、これをさらに良くしていきたいです。これは余談ですが、以前自分は他の人に「Kyashで働きませんか」と声をかけるとき、すごく緊張していたんですよね。

スタートアップは事業がうまくいくかどうかが保証できないですし、その人の考えや働き方と、企業の文化とが合うかどうかもわからないですからね。「音楽性の違い」みたいなハレーションが起きる可能性もあります。だから、これまでは「この人をKyashに誘って、本当に幸せにできるだろうか」と考えてしまっていたんですよ。でも今は、徐々に自信を持って誘える状態になりつつあります。Kyashに所属していたことを、その人のキャリアにとってプラスにできると思います。

それから、事業や組織と長く向き合い続けられる人になりたいですね。私は株式会社一休の執行役員CTOである伊藤直也さんを一方的に尊敬しているんですが、その理由として彼は一休という会社と真摯に向き合い続けていて、時にすごく悩みながらも「どうすれば事業に貢献できるか」ということをずっと考えているように見えます。それを見ると「格好良いな」と思うわけですよ。

私はKyashで働き始めてから6年ですが、そのうちエンジニアリングマネージャーが1年半くらい、VPoEが2年くらいで、開発組織のリーダーとして働いた年数はまだまだ短いです。過去の職場も、長くて4年くらいで転職していたんですよ。だからこそKyashでは腰を据えて、長期的な目線で事業や組織を成長させていくことに挑戦したいですね。

――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。書籍やWeb記事などを通じてエンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

一般論としてよく言われるのは、「他の方々の事例を疑似体験して、同じ轍を踏まないようにする」といったことですよね。それに加えて、特にインタビュー記事のようなコンテンツの場合、「その人の生の声が伝わること」はすごく重要だと思っています。「みんな、これくらい悩んでいるんだ」とか「誰しも失敗しているんだ」とわかるじゃないですか。「この人はこんなに頑張っているんだから、自分もやらなければ」という気持ちを持てるのも良い点です。

「what we use」で以前取材されていた株式会社カミナシの取締役CTOのHara Toriさんは、実は新卒入社した会社の同期なんです。彼がいろいろな技術イベントやメディアなどに登場しているのを見ると、自分と比較してめちゃくちゃ焦るんですよね。そういった、自分の成長につながるような健全な焦りや悔しさを持てることも、他の方々の事例を学ぶことの価値だと思います。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul