マイクロアドの19新卒グループです。 全体研修が終わり、システム開発部の研修として「ぼーちゃん」という月間インセンティブ獲得者を決める、MVP投票システムの開発を行いました。 今回は、その概要と開発時に工夫した点をまとめて記事にします。
昨年度：マイクロアドの新卒4人が研修で社内システムを開発した話 はこちら
目次
ぼーちゃん？自己組織化？MVP投票制度の存在
MVP投票制度とは「自己組織化」を掲げる当部署において、
マネージメントの分散の点からインセンティブ獲得者(MVP)を広くみんなで決める必要がある
という考えから生まれた制度です。
これにより現場の納得感が得られ、チーム間での情報共有や「活躍」の定義が明確になり、モチベーションの向上が望まれます。
しかし、このMVP投票制度を運用するにあたり問題がありました。これまでは外部サービスを用いて投票を行い、データを集計、そこから手作業での計算によりMVPを決めていました。そのため、MVP投票制度の担当者は業務時間を大きく割かなければいけませんでした。そこで解決策として生まれたのが、ぼーちゃんです。
投票・集計・結果公開の一連の処理を全て担ってくれる、優れものです!!
ぼーちゃんは「投票 → Vote → ぼーと → ぼーちゃん!!」的なノリで決まりました。決して決まらなかった末に妥協した訳ではありません。
まずはじめに
開発を始めるにあたり、ソフトフェア開発手法として「スクラム開発」を採用することにしました。スクラムでは毎朝5分ほどのデイリースクラムを行い、進捗状況やその日のタスクをメンバー間で共有します。当部署にジョインしたばかりの私たちにとっては、コミュニケーションを積極的に取る機会を得ることができました(報連相は大事ですよね)。
設計
開発手法を決めた次は、ぼーちゃんを作るための設計をはじめました。今年はディレクターの強力なサポートを受けることができ、大まかな仕様やデータベースについては既に用意された状態でした。感謝感激です。
DB
まずはテーブル設計です。こちらの通りです。
- nanasan_db.member : (部署内)福祉厚生制度管理システム「ななさん」の社員データ
- vote : 社員一人一人の投票データを管理
- vote_form : 投票フォームを管理
- vote_result : 任意の投票フォームの投票結果を管理
- team_master : 社員が所属する部署内チームを管理
- relay_user_team : 「ななさん」の社員データと所属チームを関連付ける
- grade : 社員の等級データを管理
- logic_param : 集計計算に用いるパラメータを管理
nanasan は18新卒によって開発された、福利厚生制度を管理するシステムのことです。このシステムで使用している社員データのテーブルをぼーちゃんでも共有することにしました。そのため、「ぼーちゃん」は「ななさん」と今回作成する2つのデータベースに接続しています。
状態遷移
DBを考慮し、さらにエラー時の処理や UI/UX 周りについてチーム内で話し合った結果、状態遷移は以下のようになりました。状態遷移に関しては、開発に取り組みはじめてから抜け漏れが見つかったりして四苦八苦しました。
技術
5月から始まった開発は、昨年同様の約2ヶ月間を見積もり日数に設定して始まりました。メンバーが担当する箇所を、「フロント」「サーバー」「DB周り」「インフラ調整」などに大きく分割し、役割ごとに取り組む形で進めることにしました。ここで、メンバーが開発していく中で良かったこと、躓いたことについてフロントエンドとサーバーサイドを中心に話していこうと思います。
フロントエンド
フロントエンドの使用した技術はこちらです。
- 言語 : TypeScript
- FW : Vue.js
- CSS FW : Bootstrap
使用する言語は、当初は JavaScript での開発を考えていましたが、コードが増えた後のタイポや実行時の型エラーの発生などを考え、チーム内で相談した上で TypeScript を採用することにしました。TypeScript による型推論は非常に強力な開発サポートとなり、IDEの補完機能を用いた開発を効率よく進めることができました。
フレームワークは社内でも使用している Vue.js です。単一ファイルコンポーネントでコードを書いていくことにしました。単一ファイルコンポーネントは、1つのファイル内で HTML, Script, CSS をまとめて書くことができるものです。
開発取り組み序盤は、HTML や CSS, TypeScript の基本的な書き方を覚え始めるのに加え、Vue.js 独自の書き方も合わさって進捗がとてもスローリーでした。ですが、HTML などは学習サイトで勉強し直すことで知識を深め、Vue.js は公式リファレンスや技術共有サイトの関連記事とお友達になることで、中盤からはスムーズに開発に取り組むことができました。
開発を行なった2ヶ月間でかなりの知識と技術を習得でき、今ではもう一人前の Vue.js プレイヤーになれたかなと思います。(本当は、まだまだヒヨッコかも...。)
サーバーサイド
サーバーサイドの使用した技術はこちらです。
言語 : Java
FW : Spring Boot
- JOOQ*1
Spring Boot は社内開発でもよく使われているため、研修として用いることになりました。良かった点としては、この後の話に出てくるアーキテクチャのレイヤー間を「疎結合」にすることと、「DIスタイル」を意識できた事かと思います。これにより、単体テストが書きやすくなり、サービスの安全性を高められたと思います。
また、サーバーサイドの処理の流れは次のようにレイヤーで作りました。ぼーちゃんは シングルページアプリケーション(SPA)を採用しています。
SPAとは単一のWebページでアプリケーションを構成する設計構造の名称です。つまり、単一のページで表示の切り替えを行うことで、ページ遷移の必要がなく、ブラウザの挙動に縛られないWeb表現を可能にしたものです。
SPA の採用に当たっては、 SPAとSSR(Server Side Rendering) でどちらを採用するかの議論がありました。なかなか方針を決められなかったため、それぞれの利点と欠点を調べ「ぼーちゃん」を開発するに当たってはどちらが良いかを決めることにしました。そこで、以下の観点に着目してどちらが良いか議論しました。
開発工数：SPA 勝利！(SSR に比べ開発がしやすい)
サーバー準備：SPA 勝利！(SSR はサーバーサイドでレンダリングするため大変)
画面の初期読み込み：SSR 勝利！(SPA は初期表示時に全てのファイルを読み込むため)
これらの観点と研修についていただいた先輩方からの意見も参考に、結論として SPA を利用することが決まりました。
アーキテクチャについては新卒 T 君が暫定案を考えてくれました。この案をもとにチーム内でどのような層にするか考えた結果が下の図です。
フロントサイドからのリクエスト(PUT, POST)を Controller で受け取り、Domain > Service > Entity > Repository の順番でデータを渡していきます。 Form がリクエストのデータを保持し、Entity がデータベース(DB)のデータを保持します。
リクエストが GET, DELETE の場合は、 Form を使用せずに処理を流すようにしました。 DBから得られるテーブルデータは、 jOOQ を用いることでマッピングを楽に行うことができ、開発効率を上げることができました。JOOQ に関連する技術記事がインターネット上にたくさん上がっており、大きく苦戦することが無く、使うことができました。
苦戦した点としては、API をうまく決められなかったことがあります。API の仕様を初めに決めていなかったため、後半になるにつれ使い勝手が悪いものとなってしまいました。
今後の展開
現在、ぼーちゃんは稼働中ではありますが、今後も自己組織化を最大限に高められるように機能の追加・改修に絶賛取り組み中です。目下進行中なのが、サーバーサイドの使用言語を Kotlin へフルリプレースすることです。リプレースする理由と目的は次の通りです。
煩雑になってしまっているコードがあるため、リファクタリングをしたい
時間関連の制御処理が各層に散らばってしまっているため綺麗にまとめたい
上記2点を行うことで今後の機能追加時のバグ発生を防ぐため
さらに、リプレース後は使い勝手が悪い API を v1 から v2 にアップデートすることも考えています。 リプレース後は次のようなアーキテクチャになる予定です。
社内システムをリリースしてみて
新卒の研修として始まったMVP投票システムの開発は、社内システムではありますが、今後の一連の業務を学ぶことができる貴重な時間となりました。投票・集計・公開といった複雑な実装がたくさんある中、なんとか予定の2ヶ月間で作り終えられたことにほっと一息つけました。今後も担当業務をこなしつつ、この経験を元に精一杯頑張っていこうと思います。
*1:ORマッパーの1つ, JOOQ Object Oriented Querying - Wikipedia
