この記事は「HIKKY開発者ブログ」より移動されたリバイバル記事となっています！

------------------------------------------------------

目次

1. はじめに
2. やったこと
3. 入社してすぐに感じた既存の業務の進め方
4. 自分に求められている役割の確認
5. 取り組んだこと
6. 1) 依頼フォームの作成とタスクの可視化
7. 2) 外形監視の見直しと再設定、アラート確認
8. 3) 課金関連の日々の可視化
9. 4) 各種ドキュメントの作成、周知
10. 三ヶ月経過した結果と今後の展望

はじめに

はじめまして！
VR法人HIKKYにてインフラ・バックエンドを担当しているきよまるです。
このたび開発チームブログの執筆をさせていただくことになりました。

どのようなテーマで書こうかな。。と考えまして自分が入社してからやってきたことのうち、この記事を読んだ方にもトレースできるような内容にしたいと思い、チームビルディング、業務改善に焦点を当てたものにすることにしました。

全体的な構成としては期待値の確認、課題の発見、解決のアプローチ、結果というようなものにしました。
業務改善などを担当することになった方には参考になるかと思いますので最後までご覧いただけると幸いです。

やったこと

先に結論になりますが下記の内容を実施することで業務フローは改善されました。

• メンバー間コミュニケーションによる課題の発見、ゴールの設定
• 業務フローの一元化とタスクの可視化
• 属人化しているタスクを減らす

どのようなことをしてきたのか具体的に書いていきます。

入社してすぐに感じた既存の業務の進め方

元々は少人数で業務をしていたため、各個人の得意なところを合わせて回している印象でした。

• どのようなタスクがあるのかよくわからない
• インフラ系タスクはバックエンドエンジニアの方が兼務していた
• 特定タスクに対して属人化している
• 依頼が個人に対するチャットベースのものであった
• 個人に対する依頼であるためタスク量と期限感がつかめない

これは決して悪いわけではなくその時の最適解だったと思います。
むしろよくその人数で回していたな。。という感想でした。

自分に求められている役割の確認

上記に記載した業務の進め方に課題を感じたため、まずは業務フローを改善するのが良いだろうと考えました。
そこで、インフラ業務を兼業しているバックエンドエンジニアの方と課題とゴールについて認識合わせを行いました。

課題は以下の通りです。

• チームとして動き、タスク分散 & ドキュメント作成をして属人化しているタスクを減らしていくこと
• インフラ観点から、プロジェクトの進行で危険なことがある場合にフォローすること

これらの課題を改善していくことにしました。

取り組んだこと

定量的に誰が見てもわかる状態にしないと、何か改善をする場合に課題が見えてこないし何をしていいかわかりません。
そのため、基本方針としては属人化タスクを減らすことと、タスクを可視化をして情報共有をすることに注力をしました。

下記の優先度で対応しました。

• インフラ系作業の依頼フローの統一化し属人化タスクの削減
• • チケットシステムによる依頼フォームの作成
• 可視化のアプローチ
• • チケットによるタスク管理
  • 提供しているサービスの監視の見直し
  • クラウド系サービスのコストの可視化
  • ドキュメント作成による知見の可視化

個別にやったことを記載します。

1) 依頼フォームの作成とタスクの可視化

現状のインフラチームといってもメンバーの方はバックエンド開発、フロントエンド開発、プロジェクトの上流工程などを兼務している状況です。
そこで、その方に集中しているタスクを分散するためにチームとして動く体制づくりが必要と考えました。

始めの一歩として、どのようなインフラタスクがあるのかを認識することと、タスクの属人化を避けるために依頼窓口の一元化が必要です。
既にあったチケット管理システム(Jira)の依頼フォームを活用することにしました。
可視化されないことにはタスクの作業分担やそのタスクに対する課題が見えてこないので、まずは一度みんなが見えるテーブルにタスクを載せました。

しかし、上記ような依頼フォームを作成しただけでは意味がなく、運用していかなければなりません。

そこで依頼フォームによる依頼フローを定着させるために、毎週開催されている開発チーム定例会議のアジェンダに依頼フォーム情報を記載しました。
加えて、会議にて口頭で毎回フォームを使った依頼をお願いすることにしました。
その結果、一ヶ月ほどで周知が行われて、現在はフォームから依頼する運用フローが確立しました。

チャットツールでチケット書いたよーって連絡をいただくこともありますが、定期タスクとして上記のダッシュボードを毎日見る対応することで漏れがないようにしています。

2) 外形監視の見直しと再設定、アラート確認

HIKKYでは様々なサービスを構築し運用しています。
既に監視の仕組みは入っていましたが内容が不十分なものがあったため、追加で監視を導入することにしました。
このような場合の監視アプローチとしては、まずはユーザから見たときを想定した「サービス監視」を入れていくのが鉄則と考えています。

クラウドサービスではAWSを使っているため、AWSのサービスの一つの「CloudWatch」を用いて監視データの取得、アラートの発報をするようにしました。

監視するために収集するデータ(メトリクスともいいます)の取得間隔とアラートの発報条件(トリガ)ですがこちらは短ければ短いほど良いです。

しかし、CloudWatchは従量課金制であるため、ここの間隔を短くしすぎると費用がかさんでしまいます。
そのため、どのサービスの監視を厚くするかをダウンした時の影響の大きさを考慮し調整しました。
お金は有限なので節約できるところは節約をして、インフラ運用体制の強化を進めています。

3) 課金関連の日々の可視化

HIKKYでは複数のAWSアカウントを持っておりAWS Organizationsによる一元管理を行っています。
ここで気になってくるのが各AWSアカウントのコスト管理です。

AWSではCost ExploerにてAWSアカウントに紐づくリソースのコストを見ることはできます。
しかし、複数のAWSアカウントがあると個別で見ていくのは大変ですし、何かの理由により急激にコストが増加するかもしれません。

そこで、AWSアカウント毎にコストを可視化することで急激な増加があった場合に検知できるようにしました。
さらにどのくらいのペースでコストが増加するのかを分析するためにデータを蓄積する仕組みを作りました。

これでAWSのコストが急激に増加した時にdiscordに通知が来るので気がつけるようになりました。
加えて、バーチャルマーケット等のイベント時にどのくらいのコストがかかっているかを分析できるようになりました。

4) 各種ドキュメントの作成、周知

可視化のアプローチとしてシステム的なものだけではなくドキュメント作成も力を入れました。
主にインフラ系タスクを兼務している方がしていた手順をヒアリングして自分で実践、Confluence(チームwiki)に手順を書いていくというシンプルなものです。

こうすることでこれから入ってくる方にもタスクをお願いしやすくなります。
もちろん業務が変わったりしてドキュメントは陳腐化するという課題はありますが、それでもまずは可視化を進めることが重要だと考えています。

またHIKKYではミーティング時にConfluence(社内Wiki)に議事録ページを作成し、書ける人が議事録を記載する方法を取っているため、率先して議事録を書くようにしています。
とにかく記録に残すことが大事と考えて行動しました。

三ヶ月経過した結果と今後の展望

入社して三ヶ月で下記の状況の業務改善ができました。

• タスクと期限が可視化されチームとしてタスクを分担できるようになった
• ドキュメントが充実しはじめてたこともあり属人化タスクが減ってきた
• 監視強化を行いトラブル時の対応ができるようになった

ここまではできましたが、まだまだ課題があるため引き続き業務改善及びインフラ構築と運用を進めます。
直近だとTerraformやServerless FrameworkによるIaC(Infrastructure as Code)を推進しています。
今後もインフラのメイン担当としてHIKKYの業務を支えていきます。

採用情報

HIKKYでは一緒にお仕事する仲間を募集しています！

自分はもともとインフラメインでしたが現在ではRuby on Railsを用いたバックエンド開発も担当させていただき、自分がやりたい！と手を上げたものは挑戦できる風土があります。
新しいことやってみたい！面白そうと思う方はぜひご応募いただければと思います。自分は楽しく仕事しています！

なお、きよまるはバックエンドエンジニア(Web)系になります。
以下から応募が可能です。皆様のご応募お待ちしております！

以上、「リバイバル記事・Webカメラでトラッキングした手をThree.js上で動かす」でした！