入社後CX事業本部での2ヶ月を振り返る
はじめに
CX事業本部東京オフィスの佐藤智樹です。
2月に入社から早2ヶ月。以前までの生活環境から開発環境まで様々なことが変わりました。せっかく環境が変わったばかりなので自分が2ヶ月で学んだことの振り返りと、もし今後開発者として入社する方の参考になればと思ったので開発環境などを記事にします。
バックエンドエンジニアとして入社した中でどんな仕事やツールを使っているのか、文化はどうなのかを簡単に紹介します。プロジェクトによって開発手法やツールは違いますのであくまで参考程度に見てください。
CX事業本部の全体的な概要はこちらの記事に書かれているので、CX事業本部が気になっていたり「CX事業本部って何?AWS事業本部と違うの?」って方は先に以下の記事をみてもらった方が良いと思います。
開発手法：スクラム開発
前職でウォーターフォールのときは要件定義→基本設計→詳細設計→コーディング→単体テスト→結合テスト→総合テストのような工程を踏まえてリリースを行なっていました。今の現場では、開発が初期フェーズに近いこともありアジャイル開発、特にスクラム開発をベースに仕事を行なっています。
スクラム開発の要点は以下から引用します。
- プロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作る。
- 固定の短い期間（1～4週間程度）の単位で開発を区切り、その中で計画を立てる。
- プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう。
- 作っている機能が正しいかどうか、定期的に確認の場を設ける。
今のプロジェクトではスプリント(固定の短い時間)の単位を1週間としています。そのスプリント単位でできる仕事量の機能を優先度順に作ることを基本として仕事をしています。
ツールとしてはBacklogをプロダクトバックログの整理、スプリントバックログをGitHub Projectで整理してから、さらに細かい個々のタスクをカードとして整理して着手しています。Github Projectの概要や使い方は以下の記事で書かれています。
最初に参加したとき自分は、スクラム開発も昔下記の本を少し読んだくらいの素人だったので、GitHub Projectのカードレベルまで整理されたタスクにペアプロで着手していました。今はスプリントバックログをタスクに区切って実装を行っています。
以前いた環境ではウォーターフォールでガチガチに仕様を固めてからコーディングしてましたが、優先順位が変わりやすい状況ならこのような開発工程の方が不必要なものを作る機会が少なくなるので良いと感じます。初期フェーズに近いプロジェクトなので開発スピードもかなり早く、１ヶ月目で自分も新規機能の作成と既存改修に着手しました。
コード管理：GitHub
コードの管理にはGitHubでワークフローとしてはgit-flowとGitHub Flowを混ぜたようなフローで行なってます。本番用のmasterブランチ、ステージング用のreleaseブランチ、開発用のdevelopブランチの3つをベースとして開発を行なっています。
普段の開発はdevelopブランチから開発用のfeatureブランチを作成して、改修後pull requestを作成してバックエンドチーム全員でレビュー後にdevelopブランチへマージしています。その後ステージング環境で動作確認し、本番環境へデプロイしています。Gitの操作はlazygitを使っています。commitなどコマンドをいちいち打たなくても1キーで実行できるのでかなり便利です。lazygitについては以下の記事で紹介しています。
インフラ管理：AWS CDK
Lambdaの設定やDynamoDBの設定などは全てAWS CDKで管理されています。AWS CDKを使うことでAWSのサービスをコードで管理できるようにしています。AWS SAMやAWS CloudFormationだとyaml形式やJSON形式の管理となるのですが、AWS CDKであれば開発者がイメージするようなコードでの管理が可能になっています。
以前は自分もSAMを使っていたのですが、CDKを使うと「これが真のIaCでは?」と感じるぐらいには良いサービスだと感じています。またライブラリ自体がドキュメントにもなっているので、今までの延々とマニュアルを見ながらの設定からある程度開放されます。
AWS CDKの使い方自体はこの前のJAWS DAYSで発表していた「インフラ食わず嫌いのフロントエンジニアがAWS CDKで自走するまで」という発表が一番わかりやすいかなと思ったのですが資料が見つからなかった…見つけたら追記します。
去年にGAしたばかりですが弊社内ではCDKが使われるところも増えているみたいです。もし最初に始める場合は、インストール時にAWS CDKのライブラリ同士のバージョンが違うと思わぬところでエラーになったりするので注意してください。
開発環境：VSCode
開発環境について特に決まりはないですが、入社前に個人で使っていたのとメンターの方が使っていて（メインで使用されているのはVimでした）教えてもらいやすいと思ったのでVSCodeを使ってます。以前いた方はIntelliJ IDEAを使っていたみたいです。
VSCodeの利点としてはプラグインがかなり豊富なところだと思います。VSCode特有のもので言うとLiveShareの機能がかなり便利です。LiveShareではソースコードをGitHubチーム内など特定のユーザにリアルタイムに共有できるので、遠隔地でも簡単にペアプロすることができます。特に今は自宅勤務しかできなく、となりで簡単に聞くことができない場合にネットさえつなげばペアプロできるのでかなり助かっています。参考までに現在個人的に使っているのは以下のプラグインです。
- EsLint
- Prettier
- GitHistory
- GitLens
- LiveShare
開発言語：TypeScript
開発内容自体はAWS Lambdaをメインに利用したバックエンドAPIの開発を行なっています。Lambdaの実装には、今メインで開発している箇所はTypeScript、別の箇所ではPythonで実装が行われています。
TypeScriptの最初の学習にはTypeScript Deep Diveがおすすめされました。なぜJavaScriptでなくTypeScriptが良いのか、JavaScriptとも共通するEqualityやTruthyなどの概念からJestなどのテストツールの紹介まで幅広く書かれているので最初に読む際には最適な文章でした。またLambdaをTypeScriptで書くときに非同期処理を大量に扱うので、Promiseに関するコーディング方法に関する資料も共有してもらいました。
アーキテクチャ：クリーンアーキテクチャ
API GatewayからLambdaを呼び出す際のHandleとビジネスロジックを書くDomainを切り離して実装することで変更箇所を小さくし、ユニットテスト実装がしやすいような設計をとっています。以前Serveless Meetupで和田さんが話していた以下の記事の設計が行われていました。テストをしっかり書くことでコードの変更を行って問題があってもできるだけすぐに検知できるような仕組みが整っています。
文化
最後に開発に間接的に関係する文化です。弊社自体のカルチャーは会社ホームページに書いており10個の内容が普段の仕事にもちゃんと反映されています。特にやってみるの文化が強いです。検討に長い時間をかけるよりも細かい単位で仕事を区切ってどんどん作っていってダメそうなら方向転換するという動きが多く、細かい単位で失敗するので方向転換もやりやすいです。このように文化が形骸化していなく末端にもちゃんと反映されている組織だと感じています。
後Slackの絵文字が多くて面白いです。前職にいたときはSlackの何が良いのかいまいち分かってなかったですが入社して初めて楽しさが分かりました。
感想
こうして振り返ると色々使用するツールや考え方はこの2ヶ月でがらりと変わったのですが、根本的な要件を整理、設計、コーディングとテスト、レビューのような流れ自体は変わっていないので今までの経験も一部は活かせているかなと感じています。ツールの紹介などはしていますが、まだまだ開発で至らない部分が多いので今後も精進を続けます。もしCX事業本部に入りたいと思った方が記事を読んで社員として働く際のイメージがもてたら幸いです。
