IVRyに入社して駆け抜けた3ヶ月。
みなさまこんにちは。(あるいはこんばんは)IVRyに2023年4月に入社した松崎(まつざき)と申します。2023年7月で入社から3ヶ月が過ぎました。3ヶ月の間何をやっていたか、またどのように感じているかをこのnote記事でお伝えできればと考えています。
入社エントリに関してはこちらをご覧ください。
入社後のIVRyでの私の役割
入社後、私の役割はインフラ担当となりました。IVRyでは明確的なエンジニアの役割分類はしていませんが、ある程度の役割分類を行うレベルの組織規模となりました。その上で私の役割がある程度定まった形となりました。
インフラ担当は何をするか3点にまとめます。
Terraform によるHCLを用いたインフラリソースの作成・管理 (IaC)
バックエンド向けのステージング環境・本番環境の構築
インフラ観点からみたパフォーマンスや技術的なレビュー・指摘
Terraform によるHCLを用いたインフラリソースの作成・管理 (IaC)
IVRyでは、Terraformを利用しインフラリソースの管理・構築を行なっています。弊社島筒によりTerraformによるインフラリソースの管理を行うことができるようになりました。インフラリソース管理をTerraformで管理を行うための経験話に興味がある方は以下のnote記事をお読みください。
島筒より一部インフラ業務を引き継ぎ、ほぼTerraformの経験値がゼロだった私はIVRyのインフラに関するキャッチアップと合わせてTerraformの扱い方・resourceの書き方・Terraform moduleの切り分け方・整理を行うことを続けました。
入社時はTerraformを中心にしたインフラリソースの管理・設計・レビューを回すことができるか不安でした。3ヶ月経ってIVRyのエンジニアメンバーからのサポートを受け自走してTerraformを中心としたインフラ管理・新規サービスのためのインフラ構築整備を行えるようになりました。
安心して、と3ヶ月前の自分に声をかけてあげたいぐらいです。
バックエンド向けのステージング環境・本番環境の構築
3ヶ月前の入社時に書いた記事でマルチステージング環境の記事を書きました。
2023年3月中旬から業務委託として契約しIVRyの開発チームが抱えている課題に手をつける形で関わり始めました。
最初に関わった課題はマルチステージング環境の構築です。IVRyではデプロイ前の動作検証で利用する検証環境があるのですが数は1つしかなく長期間にわたる新規課題を解決するための変更を検証する際、他の開発プロセス・デプロイプロセス・担当者に対して許可を取らなければならない状況でした
入社時の記事に書いたマルチステージング環境は主にフロントエンド向けの環境となっており、バックエンドの環境に関しては非同期処理・データベースの作成・初期化、ALB/ELBのセットアップなど関わるインフラリソースが多く調整に時間がかかっていました。
バックエンドのマルチステージング環境構築については運用できる直前まで進んでおり、リリースができればより細かく開発要件に応じた環境を作成して早く社内で機能確認が行える環境を実現できます。
3ヶ月経過後も引き続き続けていますが、入社6ヶ月目以内までには実現するために進めています。😃
インフラ観点からみたパフォーマンスや技術的なレビュー・指摘
インフラ観点からパフォーマンスや技術的なレビュー、タイトル通りですがその観点でのレビューを行っていました。
IVRyでは技術的なレビューに関して、技術的という観点もありますがお客様の利用、新規機能のリリースなどシステムリソース以外のサービス運用の観点からみた検討を行う文化があります。
リリースするにあたりリスクを考慮する必要はあるがリスクをどこまで許容しうるのかの検討や、レビューをした結果リリースの予定・設計の内容を見直すこともありました。
インフラ担当なので、小項目通りインフラ観点からみたパフォーマンス、技術的な指摘をしていましたがビジネス担当者(マーケティング担当、セールス担当、カスタマーサクセス担当)を交えてすぐに相談・指摘を受けることができ非常に心地よく案件を進めることができています。🙏
3ヶ月で気づいたこと
IVRyへの入社が3ヶ月経過し取り組んだこと・感じたことをまとめます。
市場・ニーズを捉え迅速に変化するインフラ構成を実現する重要性
品質に関して可用性・安全性・保守性を担保しつつ、リリース速度を上げるためIVRyの開発担当者との密な連絡・仕様の相談、現実的な落とし所の調査、将来的に予想される構成の変化・変更の見通しなどリリース時にインフラのあるべき姿をデザインする上で検討箇所は上げるとたくさんあります。
開発・案件・市場の変化及び将来のIVRyが関わるプロダクトの成長を見据えたインフラ設計を行うことは必然ですが、サービスの新規機能・改善をリリースしお客様に提供する速度も重要です。時間がかかるとリリースに行う変更量も増え、QAに掛かる作業も合わせて増えていきリリースに対する負担が大きくなります。
速度・品質両面でIVRyの開発リソースで行えることを短期・中期で判断しサービスリリース・改善を進める姿勢が全社的に浸透しています。
困った時に頼れる体制・雰囲気に対する心理的安全性
IVRyのエンジニアに関して課題への解決を行うために各個人が動くのはもちろん、解決に必要な経験・専門知識を持つメンバーにレビュー・意見を伺い案件の実装・見積もり修正を行う、お客様への影響を第一に考えた上でのリソース判断・リスク判断を行うといったことを日々行なっています。
開発していく上で自分ができる・求められている役割に応じたアウトプットを出しつつ協力していく姿勢をとることができ楽しく開発しています。
情報共有の面から見ても、ビジネス判断を行った要因の説明・日々変わる戦略の変化を会社全体で共有する文化・考えがIVRyのメンバーに根付いています。
スプリント単位で効果測定・方針確認をすることの有用性
IVRyではスクラム開発の考えを取り入れており、スプリントを1週ごとに区切りタスクを整理しポイントを管理、開発チーム全体の消化ポイントを経過測定しチームの調子を測定しています。
リファインメントも合わせて採用し週ごとにPBI(プロダクトバックログアイテム)の整理を行いプロダクトの修正や改善に繰り返し取り組んでいます。
インフラは比較的割り込み作業が入りやすいと経験していましたが、IVRyに入社してから今のところスプリント以外で急を要する割り込みが入ったことはほぼありません。(完全に割り込みをなくすのは難しいところです)
スプリント単位の効果測定・方針確認により実績に対する予測タスク消化の予定を立てやすくなりました。タスク内容による技術詳細の誤認等による巻き戻りの発生はしておりません。
この記事をお読みなった方々へ
もし、興味をお持ちのエンジニアがいらっしゃいましたらぜひカジュアル面談をしませんか？
エンジニア職以外も随時ポジションを募集しております！皆様からのご連絡をお待ちしております。