見出し画像

【中小企業DX】戸建て建設工事会社でAWS活用したシステムを初内製!!

はじめに

 株式会社クロスティーホールディングスの開発担当七海です!今回はついにAWSを活用した社内システムを初リリースしたのでそのプロジェクトについて書いていこうと思います!

何を作ったのか

 今回、初のAWSを活用した内製システムとして、開発したのは、
「職能評価システム」です!!
今思うと、初にしては程よい規模感のシステムだったと思います。開発した機能に特段難しいことはありませんが、何分初のフルスクラッチ内製だったので、社員の方々に使っていただけたときはなかなかに興奮しました!!

職能評価スクショ

システムの全体像

ランニングコストは驚きの0円
嘘です。本当はほぼ0円です。bubbleについては評価月間のみ有償契約(29ドル)にして、それ以外の月は無償プランにする予定です。

職能評価AWS簡易

背景

すごく省略すると、会社の成長に合わせて既存の職能評価制度ではうまく 評価できない部分が増えてきたこともあり、項目だけではなく仕組みなども変えようということになりました。そこで、新たに検討された評価の仕組みを実現するためのシステムが必要となってきたという背景がありました。

丁度その頃、我々デジタル推進室では、
・内製化に向けてクラウドベンダーを比較し、AWSに決定
・アカウントを作り2FAを設定して、ルートアカウントは封印!!

さあ・・・あとは作るだけだ(炎炎)

といった状況でした笑

画像3

道のり

どんな感じで、今回の内製開発プロジェクトが進んでいったのかを、ここで述べようと思います。(半分僕の振り返り的な側面がありますが汗)
人員と期間に関してですが、実工数的には1.5人/月(実期間では約2ヶ月)ぐらいで開発しました。各工程と期間について振り返っていきます!

まず、開発工程についてですが僕はSler上がりの人間ではないので上流の知識は皆無です。なので、事前に何冊かの本や、IPAさんが提供している、  これとかこれとかを読んで、システムを作るのは難しいなと頭を抱えながら、最終的にはかなり簡略化して以下の4工程にしました。

・要件定義
・詳細設計
・技術検討及び技術検証
・開発

それぞれ、何をやったかを書いていきます。

要件定義(約3日間)

 この工程では、とにかく何が達成したいのかをヒアリングして考えました。その結果、マストな要件として「新たな評価の仕組みを使って、社員が安全に自己評価を行えて、二次評価まで評価が行えること」という最低限の要件が出てきたので、まずはここをMVPとしました。データモデルとしては、概念モデルを考えて、「評価の流れってこんな感じですかね?」という合計形成を取ります。

ちなみに今回は非機能要件については、自社のIdPを使ったSSOでのログイン以外は、「ベストエフォート」としました!笑(なるべく早く動かして、いい感じのUIにしますと・・・)

詳細設計(約10日間)

この工程では、以下の順に設計を行いました。

1、どんな機能が必要なのかを考える
社員評価の結果を、どのように振り返っていくのかや、今後どのように  使っていきたいのかといった展望などから、必要機能を考えていきました。

2、論理モデルを考える
後から変更があったときに改修が大規模になってしまいそうなデータがどこにあるのかを分析しました。結果として、「後でここは変更できませんよ、もし変更したら莫大な変更工数がかかりそうですよ」と事前に説明できるようになりました。

3、フロントの画面を考える
通常はどのような順番で考えるのか全くわかりませんが、このあたりで画面を考えてみました。理由としては、実は今回DBにはDynamoDBを採用する前提で進めており、先に叩きたいAPIを洗い出しておきたいという考えがありました。個人的には画面デザインがあったほうがAPIを設計しやすいなと感じています。

4、Web API
RESTのWeb APIを機能と画面を見ながら定義します。あまり最適化についてはこだわらず、必要なAPIを良しなに作りました笑。Pathの設計だけは開発中に迷子にならないようにちゃんと考えました。

5、DynamoDBのテーブル定義
論理モデルとAPI仕様から、必要なクエリが見えてきたので、やっとDynamoDBのテーブル設計ができます。DynamoDBは、とっても便利ですが、クエリありきで設計しないと後々どん詰まりしてしまうので、そこだけが難しいなと思います。

6、 サーバーのソフトウェアアーキテクチャの設計
今回のサーバーは、機能数もそこまで多くなりませんし、特に今後大きな拡張が入る予定もなかったので、あまり深く考えずレイヤードアーキテクチャっぽい形で、上から下へ単純に依存させました。DBにDynamoとS3を使ったので接続情報のみRepository層において使い回しました。まだまだ、アーキテクチャ弱者ではあるので、ここは今後の成長ポイントではあります。

技術定義と定義のための検証(約7日間)

技術定義については工程として書いていますが、実際は詳細設計しながら、頭の中ではほぼ固まっていたので工数は無いに等しいかもしれないです。この工数はドキュメントにまとめる作業と技術検証の時間が多いと思います。今回の開発ではフロントの開発には、ノーコードツールのBubble.ioを活用しているので、IdPを使ったSSOの振る舞いやデプロイ戦略の検証などに少し時間がかかった感じはありました。また、使ったことがない技術についての学習の時間なども取りながらだったのもあります。

開発(約20日間)

ここまで来たら、無心で開発!
開発順序としては、インフラ(CDK+コンテナ周り)→サーバー(Golang)→Bubble(ノーコード)の順番で触りました。依存関係に従って作った形です。一人なので、Mockサーバーなどは立てていません。

完成!!

バグは有るかもしれませんが、動かしながら直します🙇‍♂

終わりに

今回は、システムの規模にしては少し重厚に作ってみましたが、その甲斐があり、今回のコードを種に新しいプロジェクトを始める準備をテスト的に行ったところ、ものの数十分ほどでビジネスロジックを書くところまで行くことができました!

今後は、この種を改良しながらどんどん質の高いシステムを高速に開発していけるように進化していきます。

長くなってしまいましたが、読んでいただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか?