モバイルアプリエンジニアが、サーバーサイドエンジニアになるために必要なことは何か?
背景と目的
クラスメソッド株式会社には、モバイルアプリの開発を業務とした「モバイルアプリサービス部(通称プリサー)」があります。
モバイルアプリサービス部のメンバーは、プロジェクトリーダー / モバイルアプリエンジニア / サーバーサイドエンジニア / デザイナーに分かれます。その中でも、部の名前にあるようにモバイルアプリエンジニアの割合が最も多いです。
最近では、サーバーサイド技術を勉強しているモバイルアプリエンジニアを部内でよく見かけるようになりました。技術書を片手にプログラミングを実践している姿が多いのですが、部内にはプロのサーバーサイドエンジニアが居るわけですし、サーバーサイド技術のスキルアップのために支援できることがきっとあるはずです。
そこでモバイルアプリ開発を行う組織の中で、モバイルアプリエンジニアがサーバーサイドエンジニアになるために必要なことは何か?を探るため、思いつくままに行動してみました。
具体的なアクション
今回、2つのアクションを実行してみました。
以下では、それぞれのアクションの成果をまとめました。
モバイルアプリエンジニアに向けた「サーバーサイドに対する意識調査アンケート」の実施
先日、部内のモバイルアプリエンジニアがどのくらいサーバーサイドに興味・関心があるか把握する目的で「サーバーサイドに対する意識調査アンケート」を実施しました。
最近、プリサーでサーバーサイドを学ぼうとしているモバイルアプリエンジニアが多い印象を受けています。サーバーサイドを学ぶことについて、どのような意識を持っているかお聞かせいただければと思います!
回答結果を、個人的な見解も踏まえながら公開します。グラフは見辛いものもあり恐縮ですが、グラフのあとに追記している情報を合わせてご覧いただければと思います。
Q1. サーバーサイドに興味はありますか?
結果
「その他」で書かれている内容は、やりたいけど何かしらのモヤモヤを抱えている人が多かったです。
- やりたい!けどモバイルも不十分だしなあ…。
- やりたいけど、案件直投入は怖い。
- 嫌ではないが、まずはモバイルを極めたい。
- やりたいが、当面はモバイルを考えている。
- アプリとサーバーサイドどちらかを選ぶならアプリだけど、サーバーサイドには興味がある。
- 必要であればやりたい。
コメント
総合的にみるとほとんどのメンバーがサーバーサイドをやりたいと思っていることが分かりました。しかし、色々思うところもあるようです。でも一番大事なのは何事も「やりたい」と思う気持ちを優先することだと思います。怖いと思っていたところは蓋を開けてみると意外と大したことなかったり、モバイルにも活かせる知識が得られたりします。興味があるならまずは飛び込んでみることが大事だと思います。
Q2. 「やりたくない」と答えた方にお聞きします。その理由をお聞かせください。
結果
理由 | 人数 |
---|---|
とにかくモバイル一本でいきたいから。モバイルを極め続けたいから | 1 |
仕事が増えそうだから | 1 |
コメント
モバイルアプリエンジニアも年々ますます増加傾向にあり、モバイルアプリオンリーでお金をいただくのは日に日に厳しくなってきています。モバイルアプリ + α を武器にする必要が出てきています。サーバーサイドだけが道ではありません。例えばデザイン、開発コンサル、チーム開発リーディングなどが挙げられます。もちろん、他社に負けないモバイルアプリ技術を持つために極めるというのも良いと思います。現状維持だけではいずれ仕事が無くなることが予想されるので、何かしらのアクションが必要かと思います。
また、サーバーサイドに手を伸ばすと仕事が増えるかというと、その限りではないと思っています。覚えることが増えるだけです。仕事が増えて大変になるかどうかは、チーム開発をどれほどうまくやるかにかかっていると思います。
Q3. どうして「やりたい」「やらないといけない」と思ったのですか?
結果
理由 | 人数 |
---|---|
楽しそうだから、刺激がありそうだから | 4 |
モバイルからサーバーサイドまで、まるっとできるようになりたいから | 4 |
モバイルの機能に必要な場面が多いから | 2 |
モバイルだけだと食べていけなそうだから | 2 |
(その他) モバイルをやるにしても、サーバー側を意識したほうが設計がよりよくなるから。言語毎の差が楽しいそうだから | 1 |
(その他) 社内ニートにならないために | 1 |
コメント
モバイルからの延長線上の動機は多いですが、何より楽しそうだから、刺激がありそうだからというシンプルな動機が多かったです。楽しむことは、学ぶ上で一番大切なことだと思います。
Q4. どの言語に一番興味がありますか?
結果
コメント
モバイルアプリエンジニアにとって、Node.js は取っつきやすいようです。これは私もそう思います。何となく取り掛かりやすいイメージはあります。あとは Scala も多いです。モバイルアプリサービス部では Scala 勉強会を半年近くやっていたため、その効果が出ているのだと思います。
その他にはこのような意見もありました。
- C#
- 全て同率
Q5. 一番興味がある理由がもしあれば聞かせてください。
結果
言語ごとに見ると、こんな感じです。
Node.js
- いろんなとこで使えそう、敷居が低そう
- Firebase の Cloud Functions で Node.js しかサポートされてなかったため
- AWS Lambda や Firebase で必要なケースがある為
Scala
- 型に厳格そうなのが良さそう
- すでに Swift をやっているので関数型プログラミングに慣れることができるなど相乗効果が得られそうだから。
- 以前 Play Framework(Java) を利用していたので、Scala 版に興味がある
Ruby
- 管理サイト系は昔作っていたのでなんとなく。
Java
- OOP で静的型付言語が好き
- 関数型はパラダイムシフトに失敗経験あり、動的型付言語は正直つらい
C#
- 非同期構文 (async/await)、LINQ などなど
コメント
Node.js については、敷居が低そうという意見のほか、AWS Lambda や Firebase Cloud Function などで必要なため、などという意見が多かったです。今後はサーバーレスを活用するケースがより増えてくると思うので、サーバーレスの知識も身に付けつつ言語の知識も学ぶと、直近の市場のニーズに応えられるようになると思います。
Scala は、設計やアーキテクチャについて徹底したいエンジニアに好まれるようです。
モバイルアプリサービス部では、今までの案件では Node.js と Scala と Ruby が採用率高めです。弊社に限った話で言えば、これらのいずれかのプログラミング言語を押さえておくとすぐ実践できると思います。
Q6. サーバーサイドの、どの分野をやってみたいですか?
結果
分野 | 人数 |
---|---|
モバイルアプリから叩くAPIを作りたい | 6 |
サーバーサイドのプログラム全般をやりたい | 4 |
Webアプリ開発をやりたい | 3 |
裏で動くシステム開発(ストリーミングデータ処理、バッチ処理、ETL処理)をやりたい | 5 |
認証周りをやりたい | 1 |
セキュリティ周りをやりたい | 1 |
AWSやネットワークなどのようなインフラ周りをやりたい | 4 |
Dockerなどのコンテナ技術を使った開発をやりたい | 2 |
SRE(Site Reliability Engineering)やDevOps方面をやってみたい | 0 |
(その他) データー分析まわり | 1 |
コメント
「モバイルアプリから叩く API」は、モバイルアプリサービス部のサーバーサイドエンジニアからも任せたいところ(モバイルアプリから叩きやすい API を考えて欲しい)という意見もありました。ここをまず初めの取っ掛かりにするのはすごく良いと思います。
「裏で動くシステム開発(ストリーミングデータ処理、バッチ処理、ETL処理)をやりたい」という意見が多かったのが意外でした。この辺りの機能を提供する AWS のサービスも増えてきているので、そのようなサービスを活かすスキルも必要かと思います。
まとめ
弊社ではモバイルアプリエンジニアのほとんどがサーバーサイドをやりたいと思っていることが分かりました。アンケートを取ったのは社内だけですが、きっと社内外問わず、世の中のモバイルアプリエンジニアはそう思っているのではないかな、と予想しています。
しかし、単純にサーバーサイドエンジニアに転向できるかというと、そうではありません。「モバイルアプリも不十分なのに良いのかな」「サーバーサイドが何となく怖い」などといった思いも同時に持ち合わせているので、これをうまく解消する必要があります。
また、サーバーサイドと一言で言っても、言語も分野も幅広いです。モバイルアプリエンジニアが興味のある言語・分野も人によって異なっていることが分かりました。技術の間口が広い組織の方が、モバイルアプリエンジニアの興味・関心に寄り添いやすいと言えるでしょう。
サーバーサイドエンジニアからの「サーバーサイド技術を効率的に学ぶ方法」についてのヒアリング
サーバーサイド技術を学ぶことについて、また技術分野の幅を広げることについて、サーバーサイドエンジニアのメンバーからヒアリングしてみました。組織内でサーバーサイド技術を学ぶ環境を作る際に、ぜひ参考にしてみてください。
W さん
- 一人で勉強して金になるレベルのものを作るのはむずかしい。
- 新しいスキルを手に入れようと思ったら、ジョブチェンジするのが手っ取り早くかつ確実(社内、社外問わず)。
- 準備するもの勉強することはそこから考えれば良い。
T さん
- サーバサイドの案件に入ることに尽きると思います。OJTが一番早い。
- その場合、工数が2人で1以下になることを許容します。教育コストとしてどこまで投資できるか次第です。
- また、仕様も自分で考えます。分野が変わると調べ方も変わるので、最初は遅いですが自分で調べられるように反復する時間的余裕を作ります。
実施するためには、以下の要素が必要です。
- 時間的余裕: ベロシティが下がるので、それを受入れられるだけの余裕が案件やメンターに必要です
- メンターのキャリア: メンターを引き受けることで今後どのような仕事をすることになるのか、確約でなくともある程度の道筋があると、動機づけになります
K さん
以下はモバイル開発者でプログラミング経験がある程度ある人向けへのアドバイス
- 作りながら学ぶ。分からないことが出てきてから勉強すれば良い
- Unix/Linuxに親しむ(運用から、カーネルの仕組み(さわりで良い)まで)
- 重量級と軽量級のプログラミング言語を一つずつ、業務で使えるレベルまでスキルを上げる
- 重量級: C/C++, Java
- 軽量級: Python, Ruby, Scala
N さん
- まずやる(今はいろんなツール、フレームワークなどがあるため、やること自体難しくない)。
- シンプルに書く(フロントエンドとちがってやることがシンプルなので難しい抽象化が有効なケースがすくないハズ)。
- パフォーマンスの勘所を掴んでほしい
- 距離の感覚(レジスタ << キャッシュ << メモリ << 越えられない壁 << ディスク << もっと越えられない壁 << ネットワーク)
- 計算量の感覚(オーダー)。莫大な数になる可能性がある箇所は計算量気にして書く。(O(N * M)、O(Nの2乗)を避ける
- 例えば正規表現でも書き方によって計算量爆発する。データ量が増えたときだけ問題がおこるので普通のテストではみつからない
- IO系はなるべくまとめる。(IP通信とかは重いし電池食う処理なはずなので多分アプリでもそうしてると思う)
- セキュリティの勘所を掴んでほしい
- ネットワークで送られてくるデータは基本的に全て偽装可能(メールのFROMから始まり、From IPとかも)なのでその前提で作る
- SSLとかもものすごく低い可能性で破られる場合もある(携帯も、ものすごく低い可能性で誤動作するとおもうけどその感覚ちかいかな)。その確率を必要十分に下げる事が重要
I さん
サーバサイドと言っても広いので...
- 興味がある分野についての師匠を見つける。
- 師匠に学習のステップを教わる。
- 仕事であれば師匠とペアワークをする。
- 趣味であれば、その分野の技術を使って何か作ってみる。
- 作りたいものが思いつかない時は師匠に聞く。
広く浅い知識を付けるのに手っ取り早いのは
- 他社の新人教育資料を読み漁る
APIサーバを作る場合
- HTTP
- RESTful API
- 何かの言語とフレームワーク
- 最初はコピペでもOK
- RDB/NoSQL
- Queue
- 書き出すとキリがない
インフラを作る場合の
- AWSを広く浅く
- ネットワーク
- ログ
- モニタリング
- 書き出すとキリがない
これらを前提知識として要求するのは無理があるので、ペアワークで小さなことからコツコツできることを増やしていくのがいいかと思います。
師弟関係でペアワークがコスパ最強だと思ってます。問題は師匠がスケールしないこと。スケールが必要になったら別の方法を考えるでいいと思う。
K さん
広く。浅く。
- RDBの知識
- HTTP Method、HTTP Statusあたり
- Linuxの初歩的知識
- コマンド
- サービスの実行箇所
- プロセスの探し方
- Logの場所
KB さん
サーバサイドはいくらでも深堀りできるのでとっかかりを得るために必要そうなことを書きます。
学ぶ人
- とりあえず何らかのフレームワークを使って自力で動くものを作ってみて感触を得る
- APIサーバ
- APIクライアント
- Webアプリ
- クローラー
- すごい人を見つける
- プログラミングもインフラ構築もベストプラクテスは経験の長い人に聞いた方がよい
- 最低限HTTPの知識は必要
- curlでWebAPI叩いてみる(ヘッダも出力して)
- APIクライアント作ってみる
- その後、telnetでhttpリクエストしてみてツラさを経験してみるとライブラリやフレームワークの便利さを感じる
- セキュリティ
- 徳丸本に書いてるような基本的なセキュリティは押さえておく
- RDB
- DBとテーブルの作成
- CRUD(簡単なjoinできるくらいまでは)
- 黒い画面に慣れる
師匠になる人
- 学ぶ人のスキルセットを考慮する
- マウンティングしない
- rebuild.fmでnaoyaさん(の元同僚)が話してた言葉
- 「遠慮がないのと思いやりがないのは違う。思いやりを持って遠慮なく言うことはできるでしょ」
- 1から10まで教えるのではなく自分で考えてもらうことも必要(結果が間違っててもいいので)
TK さん
やり始めの人間からの観点で
やりたい人
- どうとでもなる、言って行動すればいいだけ
- ダメだった時は謝る、謝罪ファースト
受け入れ担当者
- OJT担当者とマネージャは稼働が上がることを考慮する
何から始める
- モバイル開発者の観点から
- AWSのサービスを利用することから始める
- Amazon Cognito
- Amazon S3
- Amazon SNS
- Amazon DynamoDB
- AWSのサービスを利用することから始める
KSK さん
心構え的なことを記す。
- 自分が「カッコイイ」と思う人を見つける
- 考え方・話し方・PC の扱い方・コードの書き方・見た目、なんでもよし
- 勘違いでもいい
- その人に近づくために努力をする
- 決して「自分とは違うから」と諦めない
- 大した違いはない
- 決して「自分とは違うから」と諦めない
- プライドは捨てる
- わからなかったら質問する
- バカにされても、怒られても
- 今できないものはできない
- すぐにできるようになればいい
- 負けを認めることが重要
- 負けている理由と向き合えるから
- わからなかったら質問する
あとは本人次第。楽しめ!
S さん
個人的な経験からは、こんな感じだと楽しく学べると思います。
- まずはお勧めとされる気になる言語、フレームワークの入門書を、まるまる1冊全部やり切る
- やり終えると「俺はやったぞ感」が自分の中で滲み出てくる
- 解らないところは、詳しそうな人に遠慮なく質問しよう
- 誰かとやるとサボるから、必ず1人で全部やったほうが良い
- 何かが作れるようになっているので、具体的に何かを作ってみる
- 「TODO リストの API」とかでも良い
- モバイルアプリの延長線上で、作ってみたいものがあればそれを作る
- 自分の感覚や価値観が近い人にひたすら教わる
- 「がっつりしっかり」か「ざっくりいっぱい」のどっちが良いかは人それぞれ
- どっちも大事だけど、学ぶ上では楽しい方を何より優先したほうが良い
- 自分と価値観が近い人の方が、きっと楽しめることを多く教えてくれる
- 誰と価値観が近いかは、じっくり見てみるとわかると思う
- その人と同じ案件に入ると一番良い
何事も続けることが最重要。楽しいことは続けやすいので、楽しいことを見つけ、それをひたすらやると身に付きやすいのかなと思います。
あと「つまらないこと」は「楽しいところまで行き着けていない」場合もあります。もう少し掘ってみると楽しくなることもあるので、興味を持ったことはすぐ諦めない方が良いかもしれません。それか、一周回ってあとで楽しくなることもあるので一旦後回しにしても良いかもしれません。
継続は力なりです。
F さん
- ペアで作業を行う、プログラミングする
- プロジェクトとしてスキルを考慮した計画にする
- 何も知らないのにプロジェクトに貢献できるだろうか、進捗に影響しないだろうか、という不安を取り除くため、期待値を下げるため
- 技術領域が増えるほど、プロダクト全体を見る目が増える、人依存が弱まるので、次第にチームの利益の方が大きくなる
- 新しい事を始める場合は誰もが素人から始まるので、学習しあう組織の仕組みと文化をつくる
仕組案
- チーム内でペアを交代で回す
- スプリント内で一定時間はペア作業を必須にする
後付けで文化が作られるはず。
まとめ
弊社ではモバイルアプリエンジニアのサーバーサイドに対する意識は高い傾向にあるので、この機会を活かし、サーバーサイドもできるモバイルアプリエンジニアを育てたいと考えています(なお、去年から今年にかけて既に3名が転向しています!)。
近年のモバイルアプリ開発案件では、必ずと言っていいほどサーバーサイドの実装が必要となっています。さらに、1案件の工数のうち、サーバーサイドが占める割合はかなり大きいです。これは、案件の中でサーバーサイド実装に挑戦できる機会が増えていると言えます。
効率的・効果的に必要なスキルを身に付ける一番の方法は「OJT」や「ペアワーク」「メンターをつける」です。これらを実行するには、まずは「やりたい」という意思を伝えることが初めの一歩です。また、プロジェクトリーダーはそういった意見を尊重してチーム作りを考えると良いと思います。さらには「○○さんにメンターになって欲しい!」という主張もアリだと思います。自分が学びやすい環境は、主張することで作ることができると思います。
これまでの業務、これからの業務、これからやりたいこと、これから学びたいこと、目標のために必要なこと、ぜひぜひ考えてみてください。
この投稿が、誰かの何かを変えるきっかけになれば幸いです。