モバイルエンジニアとして成長を続けるために — Eureka Advent Calendar 2023
私はエウレカで約10年間、サービス開発にiOSエンジニアとして携わり、現在はMobile Development Directorとしてマネージメント+開発を担当しており、その多くはPairsのiOSアプリ開発である。 それなりに長い時間アプリ開発に時間をかけているわけだが今でもやりたいことが尽きずに将来が非常に楽しみな開発経験が出来ていると実感している。
これには環境が非常に恵まれていることは事実ではあるが、自分自身の考え方が毎日のように変わっていくことが新しい面白さを作り出す源になっていると考えている。
この記事では 「エンジニアとしてのものづくりの楽しみ方とモバイルエンジニアとしての開発の面白さ」 を自分の持論を踏まえて紹介する。
モバイルエンジニアとしてスキルの伸ばし方に悩める人たちの参考になることがこの記事が持つ価値の一つになると期待する。
モバイルアプリ開発はその他の開発領域と同様に底なしの深みのある領域であり、考えるべきことは一生尽きることはないだろう。
「どのようなものを、どのようにつくるか」に対してさまざまな考えを巡らせることで自分が強い動機を持って取り組むべきチャレンジが見えてくる。
会社として事業としてサービスを開発する以上はチーム開発でありビジネス視点は大前提となる
仕事は楽しくある方が良いに越したことはない。エンジニアであれば要求に対して「どのように作るか」を自分の仕事の楽しみのひとつにすることが出来るだろう。
しかしながらゆっくりと楽しんでいる間に事業は存続不可能になることも起こり得る。価値提供のスピードは絶対である、しかしながら品質も譲ることは出来ればしたくはない。
無茶な話に聞こえるがこれはまさに「エンジニアリング」の領域だと私は捉えている。世の中に存在するライブラリなどオープンソースを含むソフトウェアは少ない労力(時間)で大きな価値を提供することに貢献することを目的としているものもあります。
事業は競争であり、エンジニアが持つ最もプリミティブな担当領域としては「どれだけ早く効率的に素晴らしいもの作れるか」がテーマであり、そこに対しエンジニアリングをすることは魅力的なことだろう。
「ネイティブ」で開発する意味
読者はiOSまたはAndroidのアプリエンジニアであることを想定しているが、ネイティブアプリの大まかな定義としてはApple Googleが提供するAPIを利用して開発されたアプリのことを指すとする。つまりプラットフォームを超えた移植は難しいということを意味する。
近年では一つのコードベースから複数のプラットフォームにソフトウェアを提供していくクロスプラットフォームの技術が話題として存在する。Webの技術もその一つと呼ぶこともできるだろう。
身近な例ではFigmaを取り上げることができる。 個人的には本当に感動しているプロダクトのひとつであり、WebベースでありWebAassemblyを用いて、CRDTを活用した同時編集のサポート。
一般にグラフィックを扱う処理は相当にうまくやらないと簡単にマシンリソースを使い果たしてしまう。
これをFigmaは巧みに制御して巨大なファイルであろうがそれをどうにか処理している。当然負荷は増えていくのだが。
彼らのエンジニアリングブログは圧巻のクオリティである。テックブランディングにも惜しみなく投資していることが伺える。
少し昔であればグラフィックだったらネイティブだろう。という先入観もあったかもしれないがそれはもはや昔の話である。
を見てもWebベースであり3Dモデリングを可能にしている。
ここに対してどのようなトレードオフが生じているのかは私にはわからないが表面だけを見れば、「Webでこんなに出来ているのに自分たちはなぜネイティブアプリで開発しているのか？」となることもあるだろう。
これに対して結論を出すべきという話をここでするわけではない。 このような話題はずっと続くものであり、それを自分の領域から手を動かしながら考え続けること自体がスキルアップにつながるということを共有したい。
複雑なことを簡単に、簡単なことを複雑に考えてみる
ソフトウェア開発にブレークスルーはしばしば必要になる。ブレークスルーを通してソフトウェアの品質が飛躍的に向上することがある。
そこには技術的な進化があるとは限らない。何らかの観点での考慮を捨てることで成立しているケースもあるだろう。
サービス開発の中での機能開発などは大抵は何らかの形で以前やったことのあるようなものの繰り返しになることはよくあることで、そこで退屈しないようにすることは「違うやり方はないのか」を考えてみることにある。大きなことを一気に考えるのではなく、現実的なユースケースを題材にあえて複雑に難しく実現方法を考えてみることで新しい発見があり、それは時に抽象的な考え方に昇華されサービス全体に適用されることになるアイデアにつながることもある。
トレードオフは常に存在する — 「その技術は何を諦めたのか？」
アーキテクチャを代表に新しいとされる技術の話題は定期的にトレンドになる。 エンジニアとしてはもちろんここには感度を高く持っておきたいが、それに囚われることや批判的になる必要はなく、ニュートラルな視点を持ち、「それは一体何を得て、何を得ることを諦めているのか。」を考えることが本質的である。
一方で、この視点の裏返しとして、何かを諦めることで新しい可能性が開く可能性があることにも注目しておきたい。 革新的なことを考える時に、「何を諦めてみるか」を一度考えてみることはアプローチのひとつになるだろう。
現在のソフトウェア開発ではコンピュータに対して命令を与え、処理を実行するために多くのレイヤーが開発され十分に抽象化された上で開発を行う。抽象化にはオーバーヘッドを伴うことが多い。実際には何が起きているのかを覗いてみることは理解を深めるための良い方法の一つである。
モバイルアプリに必要なパフォーマンスは何か
クライアントアプリはサーバーからのデータの表示に集中するため、パフォーマンスに関して心配する必要はないのだろうか？とはいえ、やはりケースによっては何らかのパフォーマンスが重要な要素となる場面も存在するだろう。
パフォーマンスと一口に言っても、実行時間やリソースの使用量、エネルギー効率など様々な側面を意味する。モバイルアプリに必要なものはどのような側面だろうか？それはどのようなモバイルアプリなのかにもよって異なってくるだろう。
例えばSwiftUIをはじめとした、いわゆる宣言的UIというデータを真実としてUIを構築する技術を用いる場合、使用するデータ構造がパフォーマンスにボトルネックを生み出すケースはしばしば起こる。
データ構造の設計がユースケースに対して適切でない場合、UIの更新を適用するために膨大な時間をデータ更新に消費してしまうことも考えられる。
UIの構築や更新に対する複雑なオペレーションをデータの更新による操作に置き換えることによるトレードオフとも捉えることはできるだろう。
データ構造を用いて情報を取り扱うことになる際に関連して登場するものが「正規化」などのデータベースに用いられる考え方である。
モバイルアプリがインターネットに常に接続しているとは限らない
モバイルアプリはやはりモバイル端末上で動作するのであり、その端末が都合よく理想的な通信状態にあるとは限らないことを踏まえたソフトウェア設計を行いたい。
アプリを起動するために一定の通信が必要な設計になっているとどれだけ軽量で高速なソフトウェアであっても通信のボトルネックによって見た目はとても遅いものになり得る。
インターネットが常に高速とは限らない
アプリが行う処理が通信に依存することは多く存在するケースである。
5Gが普及している現代であってもやはり電波が弱い場所が存在することは変わらない。モバイル端末がWi-Fiに接続しており、その接続が不安定で端末が5G接続に上手にフォールバックされないことから通信が不安定になることも想定される。
そのような不安定な処理をUIの状態更新も含めて行うとすると複雑度が一気に跳ね上がる。
- 通信が速いケース
- 通信が遅いケース
- 通信が失敗したケース
通信処理はアプリが行う中で一般に多くの時間を消費し、通信状態にも依存することから完了までの時間は悲観的に見積もる必要がある。
通信中の間はUIにローディングインジケータを表示して全ての操作をブロックすることでUIの処理は相当楽になるがユーザーには大きな負担とストレスとなる。
ここに対してサーバーチームの協力も得ながらエンジニアリングを行うことが面白みの一つではないだろうか。
ユーザーはあらゆる操作を妨害されることなく実行し続けることができることを「非現実的な理想」としながら、その理想に対して技術的に実現していくことを考えていく。
時間あたりの開発効率を向上させる必要性
機能単位やアプリという単位にて動作の理想は日々高まっていく。それは実装として対応する項目が徐々に増えていくことを意味する。 自分が知っているやり方を繰り返しているだけでは機能を開発するための必要な時間がどんどん長くなってしまう。 より効率的に時間を節約し、より多くの要求を実現していくためには新しいテクニックを身につけることはもちろんのこと、自らなんらかの抽象化を行い効率的な手段を開発することも求めらるだろう。
このような文脈からも「コンポーネント指向」のような言葉が生まれたりしているわけだが、実際にはクラスや関数を上手に分割することのような一見すると地味な話であったり、フレームワークやライブラリの開発といった大掛かりに見えるようなことである。
この取り組みには非常に洗練された思考能力が求められ、実行者のセンスにも多く依存する側面があると考える。
個人的には一番自分が考えることに時間をかけたテーマであり多くのことを学ぶことができたと感じている。
必要なら技術を作り出す技術力
Aという技術とBという技術があり、どちらにもトレードオフが存在している状況。その両者の良いところをどちらも獲得することは出来ないだろうか。
技術的課題からビジネスに対して制約をかけることは当然発生することだが、解決されるべき課題には可能性を模索し続けたいものである。
市場の先頭を走るテックカンパニーは時には自ら技術を作りだし自分たちが抱える課題をより根本から解決しようと常に挑戦し続けている。
その例の一つがMetaである。Reactを開発した例もそうだがモバイルアプリ開発領域でも多くの挑戦を行い、時代の変化とともに基本に立ち戻るような動きもとっている。
事実、Metaの提供するInstagramはiOSとAndroidともに非常にパフォーマンス高く動作していることに注目してもらいたい。
一般的な実装をした場合であればドロップフレームが発生するであろう場面でもそれが発生していない。それが彼らのソフトウェア開発に対する価値観なのだろう。
エンジニアの精神としては「無いのなら作ることは出来ないか」を考えるようにしていたいものである。
エンジニアリングは「理(ことわり)」をもとにそれらを組み合わせて新しい価値が作り出され今ではそれが何十にも重なった上に成り立っている。
それらをケースに合わせて適切に選択することもエンジニアリングの一つであると考えるが、さらなる掛け合わせで新しい価値にならないかを模索することも意味のある振る舞いだろう。
「学習コスト」という側面の意識ももちろん大切であるが、目の前の達成すべき目標にも目を向けるべきであり、学習コストが全てではない。
エンジニアリングで機能開発の効果を最大化させることを考える
ビジネス上の要求は多岐にわたるが、最も重要なのはユーザーにとって魅力的と感じることのできる価値を提供することである。そのためには、ソフトウェアとして正しく動作する基盤を提供し、それを土台として機能が快適かつ正確に動作することが大前提となる。 理想的な環境だけを想定したプログラムは、ユーザーの手元では期待通りに動作しないことも考えられる。
したがって、機能が魅力的であっても、その前提となるソフトウェア基盤がしっかりと整備されていないと、本来のビジネス価値を発揮できないまま終わってしまうことも考えられる。
私はエンジニアとしてはビジネスに関心を持ち「我々は何を作るのか、何のために」に対しても感度高くあるべきであると考えているが、それよりも手前にある大切なマインドはソフトウェアとしての「品質」に対する取り組みである。
ここではあえて「品質」という大きな言葉を用いたが、その中身は何かを考えることも自身のスキルアップにつながることだろう。
ビジネスで走り続けるためにエンジニアとして「効率よく良いものを作り続ける方法」を模索しながら実行と投資を続けていくことが必要不可欠であり、エンジニアとして生きる面白さの一つになるだろうと私は考えている。
