キャリアチェンジの動機
こんにちは、シニアソフトウェアエンジニアのリトルです。このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回はですね、私がインフラアプリエンジニアときてですね、次はモバイルエンジニアにキャリアチェンジをしたときの話をしたいと思います。
そもそもですね、私がモバイルエンジニアに挑戦しようと思ったのは、ミクシーという会社に働いていたときに、前やってオーストラリア向けのベッディングサービスの仕事をしていたんですけれども、
そこでモバイルアプリをちょうど作っていたので、そこを挑戦させてほしいというところで挑戦しました。
使っていたのはですね、Flutterと呼ばれるフレームワークで作っているものでして、FlutterってAndroidもiPhoneもどっちも一つのダートという言語と
Flutterというフレームワークを使って作れるので、非常に楽というか、2つ覚えなくていいみたいな感じでやらせていただきました。
その頃にはですね、バックエンドとしての仕事も結構行わせるようになっていて、そこをリードする形でもあったので、
割とプログラミング自体には結構慣れていたんですけれども、やっぱりですね、触手が変わると新しいことが増えるもので、またいろいろと困難が待っていました。
ということで今回は実際に遭遇した困難を紹介したいと思います。まずはですね、1つ目、デザイナーの方と交流する機会が爆増したんですよ。
で、そこでデザイナーの方から作っていただいたものを受け取って、我々のようなモバイルエンジニアがそれを形にするんですけれども、
これね、作る前に先に見るんですけど、そこに対して何かどこまで口出ししていいのかが分からないっていうのがまず1個目ですね。
これはね、ありますね。何を言いたいかというと、モバイルのデザインの世界に大体決まったアーキテクチャがあって、
例えば今だとマテリアルデザインみたいなものがあるんですよ。で、マテリアルデザインっていうのは何かトーストとかハンバーガーメニューとか
スライドとかスライダーとかがいろんなそのコンポーネントがあるんですけども、そのコンポーネントの形はこういうふうに作ろうねみたいなものを
これGoogleが確か規定してくれていて、それに沿ってデザインするといい感じになるよみたいなのが決まってまして、
で、Flutterはですね、Googleが作った言語、言語じゃないですね、フレームワークなので、非常にそのマテリアルデザインに対してそれと一対一対応したようなコンポーネントが
初めから用意されているので、マテリアルデザインに乗っかっていればすごい作るのが簡単なんですよ。
ただですね、デザイナーの方が出してきてくれるそのデザイン案というか、こういう画面にしますよみたいなものがですね、そのマテリアルデザインと全然一致しないものだったりするわけですね。
そうすると別にできないわけじゃないので、そのデザインを実装するために普通よりも長い時間というか、結構な工数が取られたりするんですね。
ただ、持ちは持ちやと言いますから、そういうデザインがその理由であるっていうのは、やっぱデザイナーの方の何かしらの教示というかロジックがあった上でそのデザインになっているはずというふうに自分は思っているので、
ここで自分が多少工数をかけてこのデザインを再現するってことに一定の理由があるんだろうなと思ってしまうわけですね。
最終的には何やかんやあって、そのデザインをそのまま作ったんですけど、後々他の人ともいろいろ話してみると、いやそれは何かマテリアルデザインになるべく寄せた方が全体的にもコスト小さいし、
プロダクト開発という文脈においては、やっぱり早く作って出してユーザーの評価を見るみたいなところも非常に大事だから、あまりそういうデザインの細部のところに気をつけて実装しないといけないみたいなのはあんまりないよみたいなことをデザイナーの方に教えていただいてからはそういうもんだなというところで結構これだと結構工数かさみそうですみたいなことをコメントで残したりする機会も増えるようになりましたね。
そこで割とデザイナーの方の仕事とモバイルエンジニアとしての仕事の境界線というか、この辺で調整するといいんだなっていうところはちょっと一つ経験として学びました。
プログラミングの新たな挑戦
はい2つ目ですね。2つ目はまたデザイン関連なんですけども、ピクセルパーフェクトに恐れる。これもありますね。これはどういうことかというと、これは人によるんですけどもデザイナーの方が作ったものを100%再現できない。
もしくは難しい。妥協するみたいなことがどうしてもあるんですね。それは先ほどのやっぱり難しい部分をカットするっていうこともあるんですけども、そもそもデザイナーの方が作っているフィグマとかアドビとかの画面と実際のモバイルとかPCのブラウザの状況って完全に一致しないこともあるんですよねどうしても端末の画面の大きさだったり
ディスプレイの大きさだったりいろいろ要因があるので難しいケースもあったりしますと。ただですね1ピクセル単位で全部同じにしないといけないっていうそういう思想のデザイナーの方もいらっしゃって、そうなるとですねそれがゼとされる職場であればそれを実現するためにエンジニアの方が本当にいろんなテクニックを使ってですね
1ピクセルも違いがないようにとうまく再現するっていうことをやるんですよね。これはねこっち側からしたらというか私のようなデザインに対してあんまりこう勉強量が足りなくてですねあんまりこの1ピクセルの違いがどう影響するのかをちゃんと判断できない人間にとってはこの工数はなんか本当にかける必要があるのかっていうのをめっちゃ思ってしまいますね
いやちょっとねそれはもう自分がわかんないんでわかんない世界なのでもうなんかもうちょっとよく話さないといけないんだろうなと常々思います。はい3つ目ですね3つ目はこれちょっと今度は言語の方に入っていくんですけれども
ステートという概念が結構とっつきづらいです。ステートって何かというと状態のことですね。普段バックエンドとかスクリプトとか書いているとですねあんまり状態ってものは気にすることないんですよね。
というのも例えばサーバーってAPIを作ることが大半と思うんですけども外部から何か呼び出しがあってそのAPIの中でデータベース参照したりとかデータベースに処理を書き込んだり
またはアプリケーションのロジックで何かを変換したりとかそういったケースよくあると思うんですけどもその時って基本的に入ってきた通信に対してデータベースに問い合わせとかしますけど
何かメモリ上にずっと何か状態を持っていてこのユーザーは前回こういう問い合わせをしたから次はこう返そうみたいなのを
例えばメモリで持っているデータで何かそれを考慮してどうのこうのするっていう実装はほぼしないんですよね。したことないですね。
というのもサーバーサイド側って大多数のユーザーからいっぺんにいろんなリクエストを受け付けるのでそのリクエストをなるべくステートレスに
返せるような感じに作ることが多いんですよね。なのでそもそも設計リストは違っていて一方でモバイル側の場合ってその端末を使っているのって基本的にそのユーザーだけなので
そのユーザーの情報というか今何しているかっていう情報を非常にたくさん抱えた方がやりやすいんですよね。
なので同じプログラミングといってもステートレスにするかステートフルにするかっていうので結構特性が変わっていて
自分はステートレスな方で育った人間だったのでこのステートというものをうまく管理して例えばここをタップしたらこれを出しますとか
この通知が来てこれを押したらここに飛んでその後この状態だったらこういうことをしますとか
なんかそういういろんなことをステート機能で管理していくっていうステート中心の思考のプログラミングが結構合わなかった。合わなかったっていうか難しかったですねはい続いてデバッグが難しい
エラー調査が難しいですねこれもねめっちゃありますねいや本当に難しいんですよ
バックエンドの開発は本当に楽でというのは何が楽かというとデバッグがめちゃくちゃしやすいんですよ
APIで何かエラーが起きましたってなったら別に最悪いろんなところでブレイクポイントつけてここまでは ok ここまでは ok ここからダメだなんでだって言ったらどんどん深掘っていけば最終的に原因がわかることが多いんですよ
もちろんねいろんなそのインフラとか別のライブラリとかクラウドの環境とかに依存しているものも多いので
一概にめちゃくちゃ簡単とは言わないですけれども 範囲をだんだん狭めていくっていうのは比較的簡単なんですね
一方でモバイルの場合って先ほど言ったステートっていうものが密接に変わってくるので このエラーが起きた時のステートの状況がわからないと再現が難しかったりするんですよ
ただステートの状況ってリアルタイムにどんどん変わっていきますし エラーが起きた時にそのステートの情報をダンプしたりすることもないので
モバイルエンジニアの課題
ダンプしたところでねどうやって戻すんだって話もあるんで それをすると状況の再現も難しいし何が起こっているか全然覚えないんですよ
しかもですねモバイルとかフロントエンドの場合って非同期処理がめちゃくちゃ多いんですよね それはアプリを使っててもわかると思うんですけどなんか自分がこの処理やってる裏で実は裏側に問い合わせて
くれてちょっと更新してくれたりとか プッシュ通知が飛んできて通知が変わったりとかウェブソケットで通信してリアルタイムに画面の中の数字
がいろんなところが変わるみたいな処理を非同期にパンパンパンパンを行ってるんで 例えばですね
id とかでデバッグのところを仕掛けてそこで止めたとしてもなんかちょいちょいって進んだら 次の瞬間には全然違う
コードに飛んでたりしてまともに使えないんですよデバッカーが もしかしたら使う方法があるのかもしれないんですけど自分の場合は少なくとも
モバイルエンジニアやってる時にその方法を発見できなかったので今までバックエンドで使ったデバッグの技術が全然通用しないみたいな感じになったんですよね
結局最終的にこれという方法にはたどり着いてないで結局は仮説思考みたいななんか多分こうだからこうでこういう仮説があるから
多分こうここ終わりみたいなのをいろいろね手探りでやりながら解決していくという力技を結構やった気がします
これは大変でしたねはいそして最後俺はね一番大変でした何か変わると丸ごと作り直しになるですね
俺もねありますねバックエンドって何か作り直すになることってそんなに多くないんですよ 例えばまあプロジェクト開発をしていてなんか新機能を作りました
それをプロダクトのオーナーとかユーザーに実際に触ってもらってフィードバックをもらいました これもっとこうなったほうがいいなーとかああなったほうがいいなーって
95%ぐらいの確率になると思うんですよ そうなるとですね機能にもよりますけどあんまりバックエンドに手を入れることって少ないんですよ
バックエンドってユーザーからの入力によってなんかデータが格納されて でなんかあちらを取りたいよって言われたらそれを返すだけなんで
別にあんま処理に関係ないっていうと語弊ありますけど 処理の例えば画面の見た目が変わったところで裏側でやること変わんないんで
別にデータベースのスキーマとか変わるわけじゃないんで 特になんかこういう機能をもうちょっとこうしたいなーって言われたときにそれがUIとかだけの話であれば何の影響も受けないんですよ
APIレベルも変わんないんで 一方でですねほぼ100%の確率でこの機能をもっとこうしたいなーって時って絶対UI変わるんですよ
見た目が そうなるとどうするかっていうとデザイナーの方がもう1回新しい見た目 UIを作ったりボタンを変えたりとかいろんなことをやるんですね
そうするとですねもうワイルエンジニアとかフロントエンドのエンジニアはそれ見て作り直しですよ 今までめっちゃ頑張って作ったやつを捨てるってことですね
なのでこれがもしその冒頭に話したような めっちゃリッチに作ったUIを頑張ってギリギリ作りまくって
ピクセルパーフェクトに作ったのにってやつを ちょっと違うなーって言われたから捨てるってことですよね
これはねマジで辛いな本当に辛いこれは多分ねモバイルエンジニアさんみんな辛いと思うじゃないかな いやフロントの人もそうだと思いますけど
まあ多分デザイナーもそうだと思いますねみんな辛い まあでもね大体の場合で一発で通ることって少ないですからこれはもう仕方ないことかもしれませんね
はいちょっといろいろですねバックエンドからキャリアチェンジした際にですね モバイル側のまあいろんな難しいというか大変なところを知れました
成長と経験
実際にモバイルエンジニアやってみて良かったなというところはですね サービスのもう全部を自分でいじれるようになったなっていうのは結構大きくてですね
これはモバイルエンジニアをやっただけで得られるってわけじゃないんですけど 自分のキャリアとしてインフラやってバックエンドやってモバイルもやれたんで
フロントはやってないですけどフロントもまあ多少似てるんでモバイルと そうなるとですねなんか新機能を作りたいってなった時に
モバイルの画面自分で作るしロジックも作るし裏のバックエンドも自分で作るし もしインフラが必要なら自分で作るしっていうことで一通りのやつが全部自分でできるようになったんですよね
これはめちゃくちゃ大きくてなんかその作業をなんかやれって言われた時に 分解するのも簡単だし分解した時に例えば人にお願いする時もなんか見積もりもだいたいできるし
難しそうなポイントもわかるし プラスこうシステム全体が見えてるとシステムに対するセキュリティとかも一貫して考えられやすいとか
タイムアウトの設計とかもやりやすいんですよね そういうのもあってモバイルやって良かったなと思いますし
あとはそのステートを中心の考え方とかデザイナーの数とのコミュニケーション取り方とか そういうのを学べたのも大きかったと思いますね
あとあれだな自分からこういう機能を作りたいんですって提案して勝手に作っちゃうみたいなことができるようになったのも大きいですね
それで喜んでいただいたこともあるので はいということで今回はですね私リードルがバックエンドエンジニアからモバイルエンジニアにキャリアチェンジした時の話をしました
大半がですね大変だったという話になっているんですけども 結果的に言えばですね良い経験だったなと強く思っております
このポッドキャストはハッシュタグLITで皆様からの感想やコメント募集しております またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です
ありがとうございました
