建設業界のDXプラットフォームを目指す「ANDPAD」は、利用社数15.6万社、ユーザー数41.3万人を数えるプロダクトです（2023年1月現在）。それを支える開発組織は、現在200名以上在籍していますが、iOSエンジニアの一人である伊藤智行（いとう ともゆき）さんがジョインしたときは少規模な組織でした。

今回のインタビューでは、アンドパッドのエンジニア組織が成長する様子を間近で見てきた伊藤さんに、初期メンバーだけが知るエピソードや、iOSエンジニアとしてチームで取り組んできた技術課題とその打ち手についてなど、これまでの歩みを振り返っていただきました。

技術的な挑戦や、開発ポリシーを大切にしているエンジニアの方に読んで欲しいインタビューです。

伊藤智行（いとう ともゆき）
組込み系の開発からキャリアをスタート。その後フリーランスに転向し、SNSアプリやフォトブック制作アプリなどを手がける。ライブ配信サービスのRailsの管理画面開発やWebフロントエンドなどを担当するメインエンジニアを経て、2019年10月にアンドパッドへジョイン。「ANDPAD」の復数プロダクトのモバイル開発をリードし、現在は「ANDPADチャット」チームでiOSを中心とした開発を担当している。

マイホームを建てて生まれた「築く人へのリスペクト」 建築・建設業界のDXを目指すのは必然だった

ーiOSエンジニアとして活躍していた伊藤さんが、アンドパッドに入社したきっかけはなんでしたか？

自分の家を建てたとき、工務店で働いている人たちに対してリスペクトが湧いたからです。工務店のみなさんが、私たち家族の要望に応えながら「住みたい」と本気で思える家を完成させてくれました。それまで住んでいた賃貸住宅と比べて、マイホームにはなんとも言えない安心感があったんです。

その当時、私はユーザーが若い女性中心のモバイルアプリを開発していました。ユーザーと自分の興味が違うので、サービスに強いこだわりがなかったのが本当のところです。「誰に向かって仕事をするのかを大切にしたい」と思い、iOSとAndroidの開発スキルを生かして、建設業のソリューションに関わる開発をしようと考えました。そして、エンジニア向けの転職サイトで仕事を探し、アンドパッドの存在を知ったのです。

採用面接では、会社の魅力を熱心にアピールされたことが印象的でした。人事の方のレスポンスも良く、丁寧で、気持ちがよかったです。iOSの開発はある程度やれる自信がありましたし、「自分が培ってきたものを、自分がリスペクトしている人たちに届け、喜びの声を聞けたら嬉しいだろうな」とワクワクしていました。

少数精鋭の組織から事業グロースフェーズ、コロナ禍まで会社の成長に伴走！

ーそこから初期メンiOSエンジニアとして歩み始めたのですね。

初期メンの自覚はないですが（笑）、入社した当初はまだアンドパッドは小さな組織でした。開発組織も小規模でチーム分けもなく、手が空いた人が必要な開発をする、という感じでした。「ANDPADチャット」「ANDPAD検査」「ANDPADボード」など、プロダクトを跨いであっちこっちに行っていたことを思い出します。

エンジニア組織のマネージャーも、1人で全員を見ていました。今のオフィスは秋葉原ですが、以前は神田にありました。どんどん人が増えて、いつの間にか50人を突破し、ビジネス職の人もどんどん増えて、オフィスがぎゅうぎゅう詰めに。そこから秋葉原に移って、一気にキレイで広いオフィスになりました。

その後にコロナ禍に入り、リモートの比率が高まるなか、新しいエンジニアもたくさん入ってきて、久々に出社したときは別の会社に来たような感覚でした。良い意味で感慨深かったです。

ー前職のtoCサービスとの違いを感じましたか？

「ANDPAD」はtoCサービスと違って、ユーザーの離脱が少ないと思います。ずっと使い続けてもらえるから増える一方です。これは嬉しいことですよね。

例えば、「ANDPADチャット」というプロダクトは、工事ごとに専用のグループチャットを作成し、関係者がメッセージに加えて、データや写真、各種資料の共有ができるものです。全ての履歴が保存されるので「言った言わない」問題が解消されますし、工事作業の手を止めることなく報告や相談ができます。もちろん、セキュリティ面も万全です。

工事関係者の使いやすさに特化して作られているのですが、ユーザーが増えてからLINEなどのツールと比較されることも増えました。例えば、「ANDPADチャット」のメッセージは未読・既読のステータスを持っています。ごく稀に更新できないことがあるのですが、その場合はチャットルームを開き直せば更新されます。でもそれでは不十分で、ユーザーから更新を強く求められました。ユーザーの期待と、私たち開発サイドの意識の間で、隔たりがあったと思い反省した出来事です。

toCの場合、こういう不満をユーザーは開発者へ伝えることがないまま離脱してしまうことも多いですが、toBの場合はユーザーの生の声を届けてくれるCX（カスタマーエクスペリエンス）やCSS（カスタマーサクセス）がいます。そういうユーザーの生の声を、反映できるところがtoB開発のやりがいですね。

SwiftUIや、Kotlin Multiplatform Mobile…チームでチャレンジを重ねる！

ー今の仕事のメインはどんな内容ですか？

現在はiOSとAndroidの「ANDPADチャット」の保守・運用・新機能の開発をしているところです。技術的チャレンジとして、最近SwiftUIを取り入れました。今までは制約があってUIKitにしていましたが、古いOSのサポートが終わり、SwiftUIを使えるようになったのです。

アンドパッドでは、ユーザーが使用しているデバイスやOSバージョン、アプリバージョンをデータ可視化ツールのRedashやMetabaseを使って集計しています。古いOSバージョンの利用率が低くなったらサポート終了を検討します。基本的には新しいOSバージョンを使用していただけるように、CXと協力しアップデートを促しています。

SwiftUIの導入と合わせて、Swift5.5から登場した非同期処理・並行処理をサポートする機能であるSwift Concurrencyも導入しました。メンバーにはSwiftUIなど、新しい技術を積極的に使ってほしいので、どんどん導入を進めてもらっています。ちなみに、UIKitとSwiftUIでの実装を比較したところ、SwiftUIのほうが、UI部分の実装において1/3程度のコード量で書くことができます（画像を参照）。あくまで弊社での場合ですが、工数が減り開発スピードが上がりました。

ーいろんなトライをしているのですね！

技術的なトライはまだまだあります。アンドパッドでは、これまでREST APIやFirestoreのリアルタイム通信を用いてクライアントとサーバー間の通信を行ってきました。しかし、新しい機能開発ではGraphQLを採用することに。GraphQLはクライアントとサーバー間で扱うデータ型やクエリをスキーマによって共有できるため、開発するエンジニア間で齟齬が起きにくくなります。また、GraphQLはリアルタイム通信にも対応しており、Firestoreが担っていた部分を置き換えることで、クライアント側の負荷を減らせます。そういった理由から、将来的に幅広い活用ができると期待しています。

「ANDPADチャット」のチームでは、Kotlin Multiplatform Mobile（KMM）の導入も進めています。KMMを使うことで、ワンコードでiOSとAndroidの開発を行えます。また、iOSとAndroidとの動作が同じであるため、クロスプラットフォームのアプリを効率的に開発することができます。

基本的にKMMは機能のロジックの部分のみ共通化し、 UIはiOSとAndroidをそれぞれ切り分けて開発しています。なぜかというと、iOSとAndroidはOSやデバイスによって違いがあり、それぞれのOSの標準的なUIをユーザーが使い慣れているため、OS標準のUIを利用したほうがユーザーフレンドリーです。そのため、見えないところはKMMで共通化し、見えるところはネイティブでつくる方針にしました。

KMMは既存のサービスプロダクトに対しても導入しやすいのがメリットです。また、Kotlinを普段使っている開発者にとっては使いやすいです。FlutterやReact Nativeだと、DartだったりJavaScriptだったり、違う言語で考える必要がありますが、KMMだとKotlinのみで開発ができます。アンドパッドではFlutterで開発しているチームもあるので、チームやプロダクトの事情に合わせて選定しています。

ノーコードツールによるE2Eテスト自動化や、デザインシステム導入による一貫性向上、ベトナムメンバーとの協働も進行中！

ー直近の開発トピックを教えていただけますか？

新機能の開発としては、「ANDPADチャット」のブックマーク機能を公開しました。Biz部門からは、「ユーザーが扱う案件は膨大で、その数だけチャットも存在します。その中で、後で読み返したい、後からこのメッセージに記載対応する必要がある、などTodoリストのような使い方で活用できそうだ」という声をもらいました。

また、Webとモバイルのデザインに一貫性を持たせるために、これからデザインシステムの導入も進めていくところです。共通のデザイン要素を落とし込んだライブラリを構築し、デザインの一元化を目指しています。前述したとおり、ユーザーが慣れ親しんでいるOS標準のUIと共存することや、OS独自のUIを優先することも重要な観点ですから、モバイル側のデザインシステムの導入について議論を重ねているところです。

ー開発技術やツールは自分たちで決めているのですか。

基本的に、技術やツールの選定についてはエンジニアに主導権があります。必要な技術を習得するために必要な書籍を購入できる制度もあり、助かっています。クラウドサービスを使うときも、それがエンジニアの仕事のサポートになるのであれば、会社が積極的に出資してくれます。

たとえば、品質を改善するチームをつくったときは、コードの複雑さを測定するクラウドサービスを導入したり、E2Eテストの自動化のため、ノーコードテスト自動化ツールのMagicPodを導入したりもしました。

また、新しいチャレンジとして、海外メンバーとの協働もあります。2022年夏からベトナム支社のメンバーがチームに加わりました。当初はSlackで、英語でのコミュニケーションをしていましたが、最近、日本語が話せるブリッジSEに間に入ってもらうことになりました。それでも、細かな不具合を伝えることは難しいのだな、と感じています。日本人同士のコミュニケーションと違い、雰囲気を読んでもらえないので、明文化することが大事だと痛感しました。

技術開発における徹底したこだわりを受け止める土壌がアンドパッドにはある！

ー最後の質問です。アンドパッドに向いているのはどんな人ですか？

組織が大きくなってきたので適度にコミュニケーションが取れて、何かしらの開発ポリシーがある人だと思います。例えば、気持ちの良いUIをつくる人、SwiftUIでどんどん書き換えましょうと進めてくれる人…という感じです。これらはあくまで一例ですが。

アンドパッドのモバイルアプリ開発に携わるエンジニアは、チームごとに扱う技術の違い、プロダクトのフェーズの違い、メンバー構成の違いなどさまざまで、向き合っている課題も違います。ワーキンググループのような活動を通して、相互にナレッジをシェアし、それぞれのコードベースの改善を促しあえる体制を構築しているところです。

一方で、課題もあります。KMMを導入したことにより、AndroidとiOSで同じロジックの部分はコードが共通化され、開発が効率的になりました。ただし、KMM部分の修正時にそれぞれのプラットフォームでの動作確認をしっかり行うフローができていません。メンバーが集まって、担当範囲と協力方法を明確化し、スムーズにタスクを完了させられるフローを構築することが、今後の改善ポイントだと思います。

また、いくつかの画面ではSwiftUIを使って実装していますが、OSバージョンごとに使えるAPIが異なるため、古いOSバージョンでは細かいカスタマイズが難しい部分がありました。仕方なくデザインを妥協したところもあります。UIKitにあるコンポーネントがSwiftUIにはなく、自作が必要な部分があったりして悩ましかったです。

課題はあるものの、AndroidとiOSのエンジニアが密にコミュニケーションをとっている様子を見て、これまでのプラットフォームごとに差異が発生していた問題もいずれ解消するだろうなと感じています。これからも、エンジニアの個性を受け止め、それぞれが新たな挑戦を見つけてチャレンジできるような組織であり続けたいです。

私が入社してから目まぐるしく組織が変わりました。これからも、ブレずに目の前の課題に取り組み、その中で新しい課題を見つけ、挑戦し続けます！

アンドパッドでは、建築・建設業界全体の生産性を改善するプラットフォーム化の実現を目指して開発を進めています。まだまだ成長過程にあるプロダクトにおいて、建築・建設業界に寄り添いながらDX化を進めていくためには、開発体制のさらなる強化が不可欠です。SwiftやFlutter、またはKotlinを扱うエンジニアとして、ANDPADの様々な機能、アプリを通して、建築・建設業界を変えていくための開発をしませんか？

技術的チャレンジをずっとし続けられる環境で働きたい方、こだわりのある開発をしたい方はぜひご応募ください！