「決められた仕様の枠」に留まらない。プロダクトの土台づくりと開発の自動化を、自発的な提案から進めていける環境
「言われた通りの仕様を、ただコードに落とし込むだけの実装で本当にいいのだろうか」日々の開発を進める中で、そんなふとした疑問や、既存の設計・プロセスの制約に少し物足りなさを感じることはないでしょうか。
今回は、5年間のフリーランス活動を経てアイリッジに入社し、
現在はプロダクトサービス部SDKグループにて「APPBOX SDK」の基盤刷新や開発プロセスの自動化に取り組む斎藤さんにお話を伺いました。
少数精鋭のチームだからこそ得られる「プロダクトのコア領域に深く関わる裁量」とは何か。技術選定やAPIデザインへのこだわり、そしてAIを駆使した最新の運用効率化への試行錯誤など、実際の開発現場におけるリアルを等身大の言葉で語っていただきました。
プロフィール
齋藤さん プロダクトサービス部 SDKグループ
新卒でSESを中心とする企業に入社し、研究開発主体の企業に約10年間常駐。通信ライブラリやフレームワークといったミドルウェア開発に従事し、AndroidやiOSの開発スキルを磨く。その後、自社サービス企業へ転職し、Androidアプリ開発とともに仕様策定やドキュメント作成、タスク管理などのマネジメント領域も経験。約2年の勤務を経て独立し、フリーランスのiOS/ミドルウェアエンジニアとして5年間幅広く活躍。その後、「自らの意思決定がプロダクトの核に直接反映される環境」に魅力を感じ、アイリッジへ入社。現在はAPPBOX iOS SDKの開発・保守の中心的役割を担う。
現在担当している業務について
現在は「APPBOX SDK」の開発・保守、およびAPPBOXを導入しているOEMアプリの開発・保守を担当しています。
現在の開発フェーズは、あらかじめ決められた仕様に沿って新機能を追加していくことだけが役割ではありません。プロダクトが中長期的に安定して成長していけるよう、SDK全体の設計の再構築や、それに伴う運用・保守の効率化に注力しています。特に運用・保守のフェーズにおいては、生成AIなどの新しい技術を活用した自動化の仕組みづくりを進めており、開発効率を抜本的に向上させるためのアプローチを積極的に試みています。
開発の進め方についても柔軟で、上から提示されたタスクをそのまま処理するだけでなく、「この部分の設計やプロセスをこう改善したい」という提案をエンジニア側から発信する場面も多いです。プロダクトマネージャーやチームメンバーと双方向で密にコミュニケーションを取りながら、最適な方針を決定しています。
プロダクト自体に歴史がある分、既存の設計を見直すべき箇所や泥臭い課題も存在しますが、それをどうモダンに変革していくかを自分たちで考えられるのは面白いポイントです。今どきのAI技術をどのように実際の開発運用に落とし込めるかなど、最先端のツールを駆使しながらチーム全員で試行錯誤を重ねており、エンジニアとして知的好奇心を満たせる環境だと感じています。
プロダクトの企画や技術選定、意思決定に関われるシーンはありますか？
SDKチーム内で技術的な判断が必要になる場面では、メンバーそれぞれの意見が非常に重視されます。
複雑な課題に直面した際、一人の知識だけで判断するのではなく、チーム全員の知見や多様な視点を掛け合わせてベストな解決策を導き出すアプローチをとっています。年次や役職に関係なく誰もが対等に意見を交わすことができ、プロダクト全体の責任者である二木さんとも直接フラットにディスカッションができる環境です。
少人数だからこそコミュニケーションコストが非常に低く、必要があればいつでも、どこでも自然に技術的な議論がスタートします。
開発や運用のプロセス改善についても、エンジニア発信で具体的な提案を上げていくシーンが数多くあります。現在の開発ロードマップには、向こう1年先、2年先までやりたいことや解決すべき課題が数多く控えている状態です。やりたいアイデアが常に溢れているからこそ、単に決められたタスクを受け身でこなすような環境ではありません。
そのためチーム内では、開発全体のバランスを見ながら、メンバーが「プロダクトのコアとなる設計の意思決定」や「中長期を見据えた高度な技術的判断」といった最も重要な領域に集中してリソースを割ける体制を整えています。「このクラス設計で将来的な保守性は担保できるか」「機能追加した際に破綻しないか」といった、コードレベルでの詳細な議論も日常的に行われており、チーム全体でしっかりと納得感を持って、本質的な開発を進められるのが大きな特徴です。
iOSチームにおいて、個人の提案はどれくらい反映されますか？
設計のブラッシュアップや中長期的な保守性を高めるための提案など、実際に自身の意見が反映される機会は多いと感じています。
もちろん、プロダクトの制約や事業としての優先度があるため、エンジニアの思いつきや提案が何でも無限に採用されるわけではありません。しかし、「なぜその改善が必要なのか」「それを今行うことで、将来的にどれだけの運用コストが下がるのか」といった客観的な合理性やメリットがあれば、周囲もしっかりと耳を傾けてくれます。
例えば、現在取り組んでいるSDKの構造改善プロジェクトでも、私自身が提案した新しいインターフェース設計や実装方針が妥当だと判断され、実際に採用となって現在の開発プロセスに組み込まれています。
また、こうしたプロダクトコードの改善だけでなく、日常的な開発業務や運用フェーズの自動化といった「開発プロセスそのもののアップデート」に関しても、エンジニア発信で進めるケースが多いです。「もっとこの部分を仕組み化すれば効率を上げられる」と自発的に提案し、チーム全体の動き方や仕組み自体をより良い形へ変化させていくことが日常化しています。
現在のSDKチームの環境で、技術的挑戦の観点で面白い部分を教えてください
技術的挑戦というと、一般的には「トレンドの新しいフレームワークの導入」をイメージされるかもしれません。しかし、現在のSDKチームにおける最大のチャレンジは、そうした表面的な新しさではなく、「プロダクトの基盤そのものを抜本的に改善していくこと」にあります。
長年運用されてきた歴史のあるSDKだからこそ、今後も継続的にスケールし、新たな機能拡張に耐えられるように、アーキテクチャやインターフェース設計を一から見直していく必要があります。また、UI周りに関してもUI Kitベースの設計からSwiftUIを用いたモダンなアプローチへの移行を進めるなど、iOS開発における本質的な技術変遷にもしっかりと向き合っています。これらは決して派手な仕事ではありませんが、プロダクトの将来を支える強固な土台を作るという意味で、重要度の高い仕事です。
さらに、私たちが開発しているSDKは、一般のエンドユーザーではなく「他のアプリ開発者（エンジニア）」の皆さんに組み込んで使っていただくプロダクトです。そのため、APIのデザイン（設計）周りには強いこだわりを持っています。「同じエンジニアとして、どうすれば組み込みやすくなるか」「開発者にとって親切な設計とは何か」を考え、改善しています。
利用者が開発者だからこそ、実装のクオリティや設計の美しさがダイレクトに伝わりますし、そこに妥協せずこだわり抜ける点は、モバイルエンジニアとして非常に知的好奇心を刺激される、面白い部分だと感じています。
ビジネスサイドやUI/UXデザイナーとどのように連携してプロダクトを創り上げていますか？
プロダクト開発においては、ビジネスサイドが整理した要件をベースに、デザイナーとエンジニアが連携しながら形にしていきます。
私たちのチームでは、SDKグループの責任者である二木さんがビジネスサイドのニーズやユーザー体験の全体像をしっかりと見据えてコントロールしてくれています。そのため、エンジニアは「どうすればそれを最も安定した形で実装できるか」「中長期的な運用コストを抑えられるか」といった、技術的な視点や品質向上に集中してコミットできる安心感があります。
特にUI/UXデザイナーとは密に連携をとっており、上がってきたデザインをただ機械的にコードへ落とし込むようなことはしません。実装を進める中で「開発の観点から見ると、画面遷移のこの挙動は少し変更したほうがよりスムーズな体験になるのではないか」「SDKとして組み込む際の共通パーツとして、こちらの設計のほうが合理的ではないか」といった課題や改善案が見つかれば、その都度フランクに相談し、仕様のブラッシュアップを行っています。
また、UIが完成した後は必ず実機での確認やレビューを一緒に行うようにしています。画面上のデザインデータだけでは分かりにくい、スクロールの感触やアニメーションの微細な手触り、そしてデザイナーが意図した世界観が実機上で正しく表現できているかを双方の視点で確かめ合うなど、丁寧なコミュニケーションを大切にしています。
どんな人が弊社のSDKチームにマッチすると思いますか？
少人数のチームだからこそ、自ら課題を見つけ出して主体的に動ける方は特にマッチすると思います。指示されたタスクが降りてくるのを待つ受け身のスタンスではなく、「もっとここを効率化できる」「この設計の方が合理的ではないか」と、開発プロセスやプロダクト自体を自発的に変えていきたい方にとっては、動きやすく自由度の高い環境です。
もう一つ大切なのは、SDKの「利用者目線」を常に持って開発に臨めることです。私たちが開発しているプロダクトの先には、それを使って自社のアプリを構築する別のエンジニアがいます。自分の実装が自己満足で終わるのではなく、「これを使う開発者にとって、呼び出しやすく理解しやすいAPIデザインになっているか」「組み込む側のアプリでバグを誘発しにくい親切な設計か」を想像できることが重要になります。
同じエンジニアに利用されるプロダクトだからこそ、裏側のコードの美しさや設計のクオリティがダイレクトに伝わります。そうした同じ開発者向けのプロダクト作りにプライドを持ち、妥協せずにクオリティを追求していける方と、ぜひ一緒に開発をしていきたいですね。
「もっと大きな裁量を持って、プロダクトを自分の手でグロースさせたい」と考えている方にメッセージをお願いします！
私は、裁量というのは最初から仕組みとして与えられるものというよりも、「自ら行動し、周囲とコミュニケーションを重ねていく中で、結果として自然と広がっていくもの」だと捉えています。
日々の業務やチームが直面している課題に対して丁寧に向き合い、小さなことでも解決へのアプローチや工夫を重ねていくと、周囲からの信頼も少しずつ積み上がっていきます。そうした信頼関係が土台にあるからこそ、自分の提案や意見がチームにスムーズに受け入れられるようになり、プロダクトや開発プロセスに関するより大きな判断や意思決定にも、自然な形で関わっていけるようになるのではないかと思います。
私たちのチームは、ルールやプロセスが固まりきっていない部分があるからこそ、気づいた課題に対して自分の手で直接アプローチしていける環境です。「与えられた仕様をただ実装する」という枠に留まらず、プロダクトの土台づくりや開発環境の効率化など、自分が良いと思う改善を自発的に進めていきたいと考えている方にとって、非常に動きやすく、手応えを感じられる職場だと思います。仕組みづくりなどを一緒に楽しめる方と、ぜひ一緒にお仕事できたらと思います。
アイリッジでは一緒に働く仲間を募集しています。
ぜひお気軽にお問い合わせください！
