この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2021年7月1日、クラスメソッドにLINE事業部が誕生しました。
このブログでは LINE事業部エンジニアの仕事内容と本事業部で働く 3 つの魅力を紹介しようと思います。 そもそも LINE事業部って何やねん。という方は上記のブログをご確認いただければと思います。
エンジニアの仕事内容
エンジニアの仕事は大きく分けるとクライアントワークと自社サービス開発の 2 つになります。今回は仕事の割合が多いクライアントワークについて簡単に紹介します。
作成するアプリケーション
クライアントワークではLINEミニアプリ/LIFFアプリの開発を行います。これらはLINEアプリに実装されたLIFFブラウザ（Webview）上で動作するウェブアプリケーションです。 以下はLINE事業部で作成したLINEミニアプリの一例です。
LINE経由でどこからでもトモズ様の店舗に処方せんの画像を送り、お薬の手配を依頼できるサービス
その他、このようなLINEミニアプリ/LIFFアプリの開発も行っております。
- 東急株式会社様 ポイントカード連携LIFFアプリ開発の事例
- PAL CLOSET様 会員証LINEミニアプリ開発の事例
- ビジョナリーホールディングス様 リファラルプログラムLIFFアプリ開発の事例
- テイツー様 会員証LINEミニアプリ開発のニュースリリース
- 株式会社トモズ様 処方せん送信LINEミニアプリ例
クライアントワークの流れ
アプリケーションの規模にもよりますが、ほとんどのプロジェクトは以下のような順序でアプリケーション開発をおこないます。
- プリセールス
- 要件定義
- 設計〜実装〜テスト
- アプリケーション運用保守
エンジニアがメインで担当するのは設計〜実装〜テストのフェーズですが、エンジニアによってはプリセールスから入ることもあります。各フェーズにおけるエンジニアのミッションは以下の通りです。
プリセールス
お問い合わせのあったお客様との打ち合わせに参加し、お客様のやりたいことを理解した上でそれが技術的に実現可能であるかを判断します。 技術的に可能であり、また弊社側のメンバーアサインが可能である場合、開発する際の工数見積もりをおこないます。
技術的に可能であるかを判断するのがエンジニアのミッションなのですが、LINE という観点で世の中のお客様が何を実現したいのか知れるのはとても面白いです。業界/会社の抱える悩みや今後の方向性を聞ける良い機会になっています。
要件定義
お客様、PdM（プロダクトマネージャー）、エンジニアで開発するアプリケーションの各機能の要件を整理します。その後デザイナーがワイヤーフレームを作成しアプリケーションのイメージを固めていきます。 エンジニアはそれと並行して非機能要件を整理します。アーキテクチャもこの工程である程度 FIX し、「このマネージドサービスを使うから XX くらいのアクセスは捌けそうだな」や「バックアップはマネージドサービスが提供している範囲で満たせそうだな」などを検討していきます。
ちなみにLINE事業部の開発規模は大きくても数人で半年くらいだということもあり、このフェーズにおいて膨大なドキュメントを作るということはありません。
設計〜実装〜テスト
エンジニアがメインで担当するフェーズです。以下の技術スタックを利用しアジャイル開発をおこないます。
- 開発言語: TypeScript
- フロントエンド: React, Redux, etc
- インフラ: AWS, CDK, Github Actions, GCP, etc
- サーバーサイド：Lambda, Fargate
- データソース: DynamoDB, Amazon Aurora, etc
- 認証：LINE, Auth0
- コミュニケーション: GitHub, Slack, Backlog
開発言語はTypeScriptで統一しています。そのためフロントもサーバーサイドもIaCも全てTypeScriptとなっています。TypeScript以外を使う選択肢がないということはありませんが、現状メンバーのスキル的にも開発効率が一番良いのでTypeScriptを利用しています。
フロントアプリとして開発するのはLINEミニアプリ/LIFFアプリと管理画面になるのですが、どちらもReactを使っています。LINEミニアプリ/LIFFアプリに関してはReact Native for Webを利用することが多いです。
インフラは基本的にはAWSを利用します。稀ではありますが、お客様の要求等によりGCPを使うこともあります。CI/CDの部分に関してはGithub Actionsを使うケースが多く、そのパイプラインの中でcdk diffやcdk deployコマンドを実行しています。
コンピュートリソースには、Lambdaを使うことが多いです。オンプレと接続要件などネットワークに関する要件がある場合やレスポンスの速度が求められる場合にはFargateを利用することもあります。最近はドメイン駆動設計（DDD）を意識した実装をしています。
データソースにはDynamoDBを使うことが多いです。DynamoDBを使い始めたばかりの頃はしばしばSQLを叩きたい衝動に駆られましたが、しばらく経つとDynamoDBとの付き合いも上手くなり、我々が開発するアプリの要件であれば問題なく満たせるようになりました。やはりネットワークリソースも不要で、スケールに関してもそこまで気にする必要がなく（基本オンデマンドを利用）、またアップデートも考えなくて良いのは魅力です。
LINEミニアプリ/LIFFアプリの認証はLINEログインにより実現します。管理画面の認証についてはAuth0を利用することが多いです。
最終的なAWSのアーキテクチャはこのようになることが多いです。
アプリケーション運用保守
弊社として運用保守することもありますし、パートナー様にお願いするケースもあります。サービスにもよりますが定常運用というのは基本的にはなく、何か問題が起きた時は Slack に通知が飛ぶように設定してるので、それをトリガーにトラブルシュートをします。LINE事業部としてアプリケーション運用保守をする場合、基本的に休日深夜の対応は実施しません。
3 つの魅力
次にLINE事業部エンジニアとして働くことの魅力を 3 つほど紹介したいと思います。
幅広い技術を身につけることができる
LINE事業部では、フロントエンドエンジニア/サーバーサイドエンジニアとロールは別れてはいますが、案件規模が小さめなこともありどちらもやるというケースが多いです。また、LINEミニアプリ/LIFFアプリを構築する上で、技術的な観点でLINEを意識しなければならない部分はかなり少ないため（体感としてLINEに関するコードを書く時間は全体の5%程度）、一般的な Webアプリケーションを開発するためのスキルを丸っと習得できます。LINE にロックインされるような感覚は全くありません。先程の構成図にあったようなアプリケーション（フロントエンドエンジニア〜インフラまで）を1人で作れるようになります。
toC アプリを作れる楽しさがある
LINEプラットフォームを利用しているということもあり、我々が開発するアプリケーションは全てtoC向けアプリケーションになります。toB 向けアプリケーションと比較した場合、以下の点に楽しさを感じます。
- 1 ユーザーとして本当に欲しいと思えるものを作れる
- 作成したアプリをプライベートで使うことができる
前者に関しては、自分の要望を通すということではなく、自分がユーザーだった時にどういった導線の方が使いやすいかなどを常に考えそれを議論できるところに楽しさを感じます。 ありがたいことにPdMもお客様も、よくしたいと思っていることを積極的に聞いてくれる現場なので活発に議論しています。 後者に関しては、実際の店舗で利用してみて、使わない場合に比べ何が便利になったのかという部分を体感できるところに楽しさを感じます。自分が関わったプロダクトで世の中が少し便利になったことを体感できるのは嬉しいものです。
特定の開発手法をチームで実践できる
何かしら実践したい開発手法がある場合にエンジニア全員で同じ方向を向いて進んでいける環境です。 最近だとチームメンバーでドメイン駆動設計入門の読書会などを実施し、あーだこーだ言いながら開発をしています。 DDDに限らず何か新しいものを取り込みたい時には、議論をした上で前向きに取り込んでいける環境に魅力を感じます。
気になった方は
LINE事業部行ってみたい！！という気持ちになった方はその熱が冷めないうちにエントリー（このブログを見たと一言書いていただけるとありがたいです）
応募までには至らないけど少し気になるという方は会社説明会に参加していただくのが良いかと思います。毎月のように開催しておりますので都合の良い時にご参加ください。