LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログです。

年度末なので今期のお仕事を振り返ってみた 第二部(8月~11月)

モバイルアプリエンジニアの山下です。前回の記事に引き続き、今回は8月~11月を振り返りたいと思います。

第一部をまだ読んでないよという方はこちらからお願いします👇

techblog.lclco.com

※ この記事の内容はあくまでも"私の"お仕事と取り組み方となります

8月

iOS v2.8 リリース

このリリースでは「個別便画面」を追加しました!これにより、バス便の詳しい情報をチェックできるようになりました。「検索結果画面」と前のバージョンで追加した「閲覧履歴画面」から開くことができます!

f:id:shymst:20190329021709p:plain:w500

このUI実装には、Layout Frameworkの PinLayout を利用しています。前のバージョンでコードレイアウトを封印したと書きましたが、さっそく次のバージョンで封印を解きました 😅

なぜ封印を解いたかというと、PinLayoutを利用して同じUIを使っている「検索結果画面」のリプレースをしたかったのと、XcodeのバージョンアップによりPlaygroundが安定したため、リアルタイムなUI実装の確認がしやすくなったからです。(以前はすぐにXcodeが落ちてました)

PinLayoutは描画パフォーマンスが非常に高いと訊いて、これを使えば情報量の多い一覧画面のスクロールでも60fpsくらいでるのでは?という希望を抱いたのとコード量の少なさに惹かれて採用してみました。

f:id:shymst:20190329021744p:plain https://github.com/layoutBox/PinLayout

結論から言うとスクロールパフォーマンスは上がりませんでした。(逆に少し下がりました)
というのも、元の実装でもAutoLayoutを使わずに緻密にチューニングされていたため、単純に置き換えただけでは意味がありませんでした。コード量は減り、腐敗の進んだxibからも解放されてよかったのですが、パフォーマンスが悪化したので「検索結果画面」での採用は見送り、「個別便画面」でのみ利用することにしました。xibベースで進めている今となっては完全にお荷物です

また、この機能では新規のAPIも必要だったため、クライアントとサーバサイドを行き来しながら開発を進めていました。APIが使いにくかったら自分ですぐに修正できるので、効率的には一番良い進め方でした。

このバージョンでは、初のEmbedded framworkの採用にも挑戦しました。リスクが少ないExtensionのみを対象にして、まずは証明書などの扱い方や無事にCI/CDを通せるかを確認していきました。案の定、Bitriseでコケたりもしましたが無事に導入することができました。

モバイル管理画面

4月に作ったきりになっていたモバイルアプリ専用の管理画面ですが、PUSH通知の動作確認をする際に対象バージョン全ての端末に対して送信される状態となってました。(本番環境とテスト環境は分かれていました)

そのため、テスト端末にいつも大量のPUSH通知が溜まっていたり、他の用途で利用しているメンバーや端末置き場の近くの社員が急に届いたPUSH通知に驚くことが頻繁にありました。これではテストもしづらくなってしまうので、新たに2つの機能を追加しました。

  • 社内端末管理機能
  • PUSH通知個別送信機能

社内端末を管理する目的も兼ねて、PUSH通知に必要な情報と端末情報一緒に登録できる機能を追加しました。これにより、管理画面上から端末を特定しやすくなったので、その情報を元に個別に送信できるようにしました。

この月に公開した記事

techblog.lclco.com

techblog.lclco.com

9月

バス比較なび(旧:夜行バス比較なび)の名称変更が翌月に迫っていたため、それに備えてモバイルアプリの開発は名称変更のみとしました。そのため、この月はWeb側の業務を行いました。

バス比較なび(Web)

サービス名称変更準備

至るところにサービス名が含まれていたので、一括変換と画像の差し替えをしつつ五月雨に対応していました。細かい作業で気の滅入る作業ではありましたが、この段階のサービスでの名称変更は滅多にないですし、今となっては面白い経験だったなと思います。全体のリソースが少ない中、サポートをしっかりできたのはよかったです!

コンテナ環境の構築

外部サービスとの機能連携に伴い、サーバに高い性能を必要せず、本体とは独立させた別のRailsアプリケーションを用意する案件がありました。LCLは、常に新しい技術に挑戦できる環境にあるため、これを機に社内で初のECSを使った構成を作ることにしました。

以前からDockerを使っていた私は、コンテナのインフラ環境に興味があったので検証と導入の担当を引き受けることにしました。AWSのスキルとしてはEC2やS3を触ったことがある程度で、着手当初は「IAMってなに?サブネット?セキュリティグループ...」といった状態から始めたのですが、実践でのキャッチアップやAWS勉強会を通して全てが繋がり、無事にステージング環境と本番環境を用意することができました! IAM、CodePipelineのデプロイ設定、Fargateの設定、動的IPの自動アタッチ(サービスディスカバリー)の勘所をつかめたので非常に貴重な経験でした。

この知見はブログでも公開しています!

techblog.lclco.com

AWS勉強会で「CodePipelineを使えば、デプロイ環境が1時間でできます」という発表を訊いた時は、少しショックを受けたのはいい思い出です。ちなみに現在はAWS ソリューションアーキテクトの参考書を読んでも問題なく理解できるようになりました💪

その他、お手伝い

  • 改善
    • SpeedCurveのデータをRedashへ追加
  • 他部署との輪読会(題材:OKR)
  • 毎月のチームの振り返りを体系化

この月に公開した記事

techblog.lclco.com

10月

iOS v3.0 & Android v2.0 リリース

アプリ名を「高速バス比較」から「バス比較なび」に変更し、アイコンも新しくなりました! これにより、Webと統一された名前&アイコンとなりました。

f:id:shymst:20190329022015p:plain f:id:shymst:20190329022035p:plain

バス比較なび(Web)

コンテナ環境の調整やChatOps対応

ECSを利用した環境ははじめてだったことから、スペックやログ周りの管理の調整を地道に行いました。又、バックエンドメンバーがリリースをしやすいようにチャットでのデプロイ実行に対応したり、開発基盤の整備も行いました。

採用

インフラやバックエンドの業務を担当することも増え、チームとしても私がモバイルアプリ以外のリソースを割くことを必要としていたため、モバイルアプリエンジニアの募集を始めました。

採用活動の中心メンバーとして面接や基盤づくりには以前から携わっていましたが、モバイルアプリエンジニアの採用ということで、私が中心となってスケジュールの調整や人事とのやりとり、面接中の会社説明を行うようになりました。そのため、この月は以前よりも採用活動が活発で開発の時間はあまり確保できなかった記憶にあります。

障害対応メンバーに参加

これまで障害対応はインフラ知識のあるメンバーに属人化していましたが、障害に強いチームを作るために組織的な対応シフトとフローを組むことにしました。このメンバーに私も加わり、週替わりに担当するようになりました。

この取り組みについては、以下の記事でまとめられています。

techblog.lclco.com

私はDotfilesを作って環境を整備する程度にコマンド操作には抵抗はないですが、障害対応となるとサーバの知識や普段使わないようなコマンドを覚える必要があるため、これまで対応していたメンバーの作業ログやドキュメントを読みつつキャッチアップしています。幸い、まだ大きな障害はまだ起きていませんが、日々の小さな警告でもログやメトリクスをチェックしたり、普段から正常値を気にするようになりました。

その他、お手伝い

  • エンジニアブログ編集部(添削)
  • 脆弱性セミナー参加

この月に公開した記事

techblog.lclco.com

11月

モバイルアプリは計測基盤の整理に入りました。そして、引き続き採用活動中で多忙な日々を過ごしていました。

食べログ 技術交流会

LCLは2018年1月からカカクコムの子会社となり、その直後にカカクコムエンジニアとの技術交流会を行いました。今回は2回目の交流会となり、食べログのフロントエンドエンジニアの方々にオフィスにお越しいただきました。オフィスで交流会とLCLエンジニア行きつけのお店で懇親会を行いました。

techblog.lclco.com

サーバ スペック変更

RI(リザーブドインスタンス)が切れる時期となったため、サーバを一時的に止めてスペックを更新しました。最近インフラ業務に携わっていた私もこの対応に参加しました。この時にRIという存在をはじめて知りましたが、お高いサーバ維持費を一括で決済するのはサーバでの作業以上にダブルチェックが必要と感じました。

サーバメンテナンス

これまで365日24時間ずっと稼働してきたバス比較なびですが、サービスの成長と共にサーバも増えており、稼働した状態で全てのサーバスペックを変更するのは手間とリスクが掛かるということで初めてサーバを止めることにしました。この対応方法の検討と作業に参加し、夜遅い時間にオンラインで集まってメンテナンスを決行しました。※ 翌日のAMが代休となりました

techblog.lclco.com

Slack 試験導入

以前からSlackへの移行したいと考えており、ブログ編集部メンバーの協力を得て9月辺りから一部のチャンネルで試験導入をしていました。その期間で運用上問題ないことを確認できたので、今度は全社移行を見据えたロードマップと移行のメリデメをまとめたスライドを作ってエンジニアチームにプレゼンしました。(プレゼンをしなくてもエンジニアメンバーはSlackが優れたツールであることを認識していましたが、具体的な事例を並べることで意味も無く移行をしたいと言っている訳ではないことを伝えたかったのです)

これにより全員の同意を得ることができ、チームでの試験導入を始めました。

その他、お手伝い

  • エンジニアブログ編集部(添削)
  • 引き継ぎサポート
  • モバイルアプリエンジニアの受け入れ準備

この月に公開した記事

techblog.lclco.com

techblog.lclco.com

おわりに

後半はいつの間にかインフラ中心になっていました。この3ヶ月でスキルの幅や経験が一気に広がりました。もちろん、この間もモバイルアプリの開発は進めていますが、機能追加ではない作業が続いてます。。採用活動は11月に一区切りつけることができました。

エンジニアブログは編集部としての活動はしているものの、9月・10月で月に1本出せていないのは残念ですね。

このように振り返ってみると、今やっていることは唐突に方向転換したわけではなく、ちゃんと繋がっていることを再認識できました。 残りの4ヶ月を振り返った時に、ここまでの8ヶ月と比べてどうなっているかが気になります。

ここまでお付き合いいただいた方、ありがとうございます。 次回、第三部もよろしくお願いします!

LCLでは特定の技術に縛られずに開発やチームの課題に取り組めるメンバーを募集しています! このブログを読んで興味を持っていただけた方は、是非一度お話を聞きにいらしてください。

www.lclco.com