LCL Engineers' Blog

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

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

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

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

techblog.lclco.com

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

8月の振り返り

iOS v2.8 リリース

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

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

このUI実装には、Layout Frameworkの PinLayout を利用しています。前のバージョンでコードレイアウトを止めたと書きましたが、早速採用しました😅

PinLayoutは描画パフォーマンスが非常に優れているため、情報量の多い検索結果一覧で利用することでスクロール時でも60fpsを出せる可能性を感じたのと、UI単位の共通化がしやすそうだったことが採用の背景です。
また、XcodeのバージョンアップによりPlaygroundが安定したため、リアルタイムにUI実装の確認がしやすくなったのもコードレイアウトを再度採用したひとつの理由です(以前はXcodeが直ぐにクラッシュしてしまう問題がありました)

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

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

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

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

モバイル管理画面の機能追加

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 移行 フェーズ1: 試験導入

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

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

その他、お手伝い

  • エンジニアブログ編集部としてメンバーに執筆してもらった記事の添削
  • モバイルアプリエンジニアの受け入れ準備

この月に公開した記事

techblog.lclco.com

techblog.lclco.com

おわりに

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

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

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

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

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

www.lclco.com