AWS開発事例 AWSにて構築した社内評価360度システムが今年8月からコウェルで導入スタート

1.プロジェクト概要

Vision360icon

コウェル・グループは、日本(東京、宮崎)、ベトナム(ハノイ、ダナン)の4カ所を拠点(グループ全体で社員数約450名)に、ITシステムの開発リソースをお客様に提供すべく、《グローバル開発》、《グローバル人材紹介》、《海外IT開発子会社支援》の3つをコア事業とし展開しています。

この3つの事業に共通するのは「人材」。この「人材」について長年着目し、日本・ベトナムにおいて採用、教育(IT教育、語学教育等)、人事制度には積極的に投資を行っています。グループ全体の社員数も年々増加し、将来を見据えて2018年から2019年にかけて日本とベトナムで人事制度の刷新を行いました。

その一環として、『社内評価制度に360度評価制度』を導入。 その運用には、外部ツールの利用も検討されたが「”人材”が事業のコアである。内製化しよう」との方針により、自社開発することが決定しました。 内製化プロジェクトがスタートしたのが2019年5月、要件定義・設計・実装を約2ヶ月、AWSの構築においては約2週間の短期間で完了し、当社の新年度である2019年8月よりシステム運用がスタートしました。



2.インフラはAWSありきでプロジェクトがスタート

臼田写真

臼田 歩/Ayumu Usuda HR-Biz Headquarters. TECH Group Manager.

AWS採用の決定の経緯について、
「プロジェクトの発足に伴い、まず議論されたのは、単なる社内システムにとどまらずお客様へのサービス展開に応用できるよう、最新の市場ニーズを取り入れ、開発スタイルやシステム構成を目指すことでした。
当社のシステム開発を支援するグローバル開発事業の方でも、アジャイル・開発スピードの向上、CI/CD、AWSの各種サービスの有効活用・提案を求められるケースが多いため、VISION360の開発ではインフラは自然とAWSの活用が決定しました。」(臼田)

「VISION360は、社内人事用の360度評価システムです。社員全員が自分以外の全社員に対し、評価を行います。社内システムとして、そもそも“この評価スタイルが我々に合うのか?”からのスタートだった為、積極的に新技術を取り入れて実験的な要素も多分に取り入れたプロジェクトとして開始しました。
今回のシステムは、当社では初めての360度評価制度の導入になるため、システムへの要望も直前まで人事部門、経営サイドから多くなることが想定され、改修する頻度が非常に多くなることを前提としてありました。
システムデザインで意識したのは、上述などの要望に耐えられる開発スピードを確保することと、 当社だけでなく、お客様にも提供・提案できる「開発運用プラットフォーム」の現時点でのベストプラクティスのスタンダードを定義することでした。
そのため、Infrastructure as Code(IaC)にてインフラを定義/構築するという前提があり、AWS CloudFormationを利用し、各環境変数をパラメーター化することで、横展開も可能としました。」(臼田)

VISIONインフラ構成図 VISIONインフラ構成図

vision360cap1 実際のvision360管理画面①

3.AWS上でのDocker運用

インフラ担当森下写真

森下 健人/Kento Morishita . Site Reliability Engineering Div. Senior Manager.

「現在は、同テンプレートを使って、既に複数のプロジェクトに利用していますが、運用プラットフォームを意識する上で、重要だったのがDockerです。
私は、これまで開発環境と本番環境の環境差異によるミスを起こしたプロジェクトをいくつも見てきました。
Dockerを使うことで、どの開発者に対しても常に同じ環境を提供し、さらに本番まで同じ環境を利用することができます。ソースの一貫性と同様に動作環境でも複数人同時でも差異の無い環境での作業は大切になってくるので、Docker + ECSを組み合わせることにしました。」(臼田)

「それに加えて、IaCを運用する上でインフラエンジニアチームとアプリエンジニアチームで、責任分界点をどうするかという議論もありました。 開発者が構成を管理すれば自由度が増すだけでなく、開発スピードが上る可能性が高いからです。
ただし、アプリエンジニアのスキルのバラつきが原因となり、堅牢だった構成を破壊する懸念がありました。実際に過去にお客様のご支援の中でも、アプリエンジニアの手によって構成が破壊されるという苦い経験をしたプロジェクトもありました。このため、開発者はローカル上ではdocker-composerで運用し、AWSにデプロイする場合には、〔CodeBuildが実行できる状態にコンバート〕してもらうという運用方法を選択しました。
また、運用としては、コンバート作業がオーバーヘッドになる懸念がありましたが、現在は逆に〔コンバート癖〕をあえて工程に入れることで、構成が担保できると思っています。当分は今の運用スタイルを継続したいと考えています。」(森下)

vision360管理画面 実際のvision360管理画面②



4.開発スピード向上のために

AWS開発担当者

・CI・CD
次に、開発スピードをあげる上で重要なのがご存知の方も多いCI/CD環境です。
「コウェルではバージョン管理システムにGitlabを導入しています。 GitlabはAWS CodePipelineを活用する上で、フック元には対象とされていませんでした。 そのため、Jenkinsをフックのために一度挟むことで解決し、後は一貫して、AWS CodePipelineのジョブで実行することができます。」(森下)

・メンテナンスとロールバック
リリース時に課題となるのは、メンテナンスとロールバックです。
「今回もこの工程も自動化しています。メンテナンス画面は、デプロイ中は自動でALBを切り替えて、メンテナンス画面を表示するようにしています。
ロールバックでは、DB更新があったかどうかを管理させ、あった場合はDBのロールバックを実行するようにしました。
それでもまだ、単純に戻せない場合もあるため、最悪の場合はスナップショットから戻すという運用もフローに入れています。開発スピードという点では、DockerのBuildの高速化も課題としてあがりました。
Dockerはエフェメラルであることが前提ですが、環境構築についても同じ考えで、「いつ」・「どこで」ビルドをしても同じ環境である状態を意識しています。
そのため、AWSでのDockerビルド時も確認の為に一からビルドを実行する事としています。
当初は、コンパイルが必要のないPHPでありながら、環境構築には全体で約15分かかっていました。
それを各箇所でチューニングを行うことで5分ほどまで短縮することができました。
その他にも、Dockerを運用する上でファイルの共有やスケールする単位をどうするか等の運用を意識し、考察しながらシステムを構成しました。」(森下)

今後について

人材支援サービス

「現在、HR-Biz本部で展開する「人材紹介事業」において、様々な自社システムの構築が計画されています。すでに進行中の内製プロジェクトでは、今回のモデルケースが開発環境のスタンダードとして活用しています。
今後は、社内利用にとどまらず、今回のAWSを含めたシステム構成・運用スタイルを、様々なお客様の要望に耐えられるよう、プラットフォームのテンプレート化を進化させ、《開発スピードの向上》と《運用負担の軽減》等に役立てていきたいと思っています。」(臼田)



各サービスの詳細についてはこちらから↓
AWS インテグレーションについて : https://www.co-well.jp/services/cloud/index.html
グローバル開発事業 : https://www.co-well.jp/vietnam_offshore.html
人材紹介事業 : https://www.willandway.jp/