はじめに
こんにちは。mikanでバックエンドエンジニアをしているnixiiです。
今年の7月にmikanにジョインし、そこから1ヶ月ちょっとが経ちました。最近は本格的に開発にもコミットするようになり、本エントリテーマにあるようなスキーマ設計を議論したり、がっつりコードを書いている日々です。
先日出した入社エントリから早くも1ヶ月が経ったと思うと、時の流れは早いな〜と実感しています。
こちらの入社エントリでは、私の自己紹介や、なぜmikanにジョインしたのかについて色々と深ぼって書いています。是非ちらっと読んで頂けると嬉しいです！
。。と前置きが長くなりましたが、今回は「チームでスキーマ設計した時のハマりポイントと勘所」と題して、私を含めバックエンドチームがスキーマ設計を行った際に出会ったつまづきと、そこから得た学びをシェアしていきます。
そもそもスキーマ設計とは
スキーマ(Schema)は広義には「図式・構造」などと訳され、データベース分野においては「DB(データベース)の構造」を指します。
例えばRDB(リレーショナルデータベース)であれば、現実で扱いたいデータに応じてテーブルを定義し、必要なカラムも考慮した上で、テーブル同士の関連についても考えることになると思います。こういったDBの構造(= スキーマ)の設計を考えることが、即ち「スキーマ設計」です。
特にテーブル間のリレーションなど、実世界をデータモデリングしているものは「概念スキーマ」、それをRDBであればSQL文などで表現したものを「外部スキーマ」と呼びますが、本エントリでは便宜上、両者スキーマの設計を合わせて「スキーマ設計」と呼んでいます。
ハマりポイント
今回mikanでは、英単語アプリで新たな教材をアプリ上で扱うため、その教材に応じたスキーマを新たに設計する必要がありました。
スキーマ設計を進めていくうち、こうした設計タスクなどでよく出会うハマりポイントに、今回バックエンドチームもハマってしまっていました。具体的には以下の2つが挙げられます。
チーム内で設計への見通しが異なっていた
検証フェーズについて考慮漏れしていた
「チーム内で設計への見通しが異なっていた」点について
スキーマ設計の工数としては、元々チームでは1日程度と見積もっていました。が、実際には素案レベルでのスキーマをチーム内で仕上げ、ビジネスサイドと認識をすり合わせつつ調整するために、結果としてトータルで3, 4日以上かかってしまっていました。
元々1日で完了すると踏んでいた理由として、じつは過去すでに類似したスキーマを作っており、このスキーマが流用出来ると考えていた点があります。しかし実際には、このスキーマは今回RDB向けに設計しようとしていたフォーマットとは異なり、Cloud Firestore向けに設計していたものでした。
Cloud FirestoreはNoSQLのドキュメント指向データベースで、key-value値が入れ子構造のようにドキュメントとして保存されていく構造です。これは各テーブルを必要に応じて正規化したり関連させることでデータモデルを表現するRDBとは大きく構造の異なるデータベースで、当然出来上がるスキーマも自ずと違ってきます。
このように前提の異なるスキーマを再利用するのは実際にはかなり難しく、チーム内で議論しつつ、RDB向けにほぼスキーマを設計し直す形となりました。結果として工数が膨らみましたが、元々資産として参考にする予定だったスキーマについて、事前にチーム内で目線を合わせることで気づけていた点でもあり、走り出し時点でチームで認識を揃える重要さを体感しました。
「検証フェーズについて考慮漏れしていた」点について
本来スキーマ設計をチームで進める場合、議論しつつスキーマ設計の素案を作成するだけでなく、「作成したスキーマが実際に解決したい現実の問題を扱えるのか」を検証する必要もあります。
しかし、設計に着手時には後者について考慮しておらず、着手中に検証フェーズの必要性に気づいた結果、1~2日ほど工数が膨れていました。今回に限らず、新規事業でのPoCや実装におけるテストなど、考えたコト・作ったモノに対して正しく機能するかどうかを担保するための検証フェーズは不可欠なものだと思いますが、常にその点も考慮に入れるべきだと振り返りました。
チーム内で認識を揃え、問題解決にあたる際には解決案の検証まで行うというのは非常に基本的な事ながら、日々それを常に徹底することの大切さと難しさを痛感した週でした。
スキーマ設計の勘所
スキーマ設計に限らないのですが、こうしたチームレベルで考え、検討した上で設計するタスクでは、事前にチーム内で
- 今明らかになっているものは何か
- まだ不明瞭なものは何か
- 現在やろうとしている事は何か
について認識を揃えておくだけでも、予期せず工数が膨らむといった事態は避けやすくなるだろうと振り返りました。
今回の例だと、「明らかに過去の資産を今回の設計に活かせる」と考えていたものの、実はチーム内でその点について触れることで「実は明らかではなく、活かせるかどうかは不明瞭だった」という事が把握出来たためです。
中でも「一見明らかだけど、明らかだと思い込んでいて実際には不明瞭だった」というパターンは結構曲者だと思っていて、上記はこのパターンにチームで早期に気づくための勘所でもあるなと思います。
また、現在やろうとしている事についても認識を揃えることで、本当にそれらを完了すれば設定したゴールに辿り着けるかもチームで確認出来ます。今やっている事をこなすことで設定したゴールに到達出来るのか、最初にチームで目線を合わせるのもこうしたタスクでは重要だと思いました。
mikanでは現在ほぼフルリモートで開発を行なっていますが、今回のリモートでのスキーマ設計の議論ではmiroというオンラインホワイトボードのようなツールを使ってみました。ホワイトボード上で図を書きつつ議論するような使い方が出来る点で、非常に使いやすいな〜と感じています！
(miroを使って概念スキーマの議論をしている画面)
他にも必要に応じてZoomにiPadを繋いでイメージ図を書いたり、チーム内で必要に応じてサッと情報を共有していくのもこうした設計の議論では大切だなと実感しています。
コロナ禍前ではオフラインで実際のホワイトボードを前にワイワイ議論出来ていたのですが、オンラインでこういった設計の話を進める上では正直やっぱりハードルが上がったなと感じています。
一方で、お互いにこうしてツールや通信環境をより良くしたり、進める上でのちょっとした障害が無いかどうか都度フィードバックをし合うなど、ハードルを下げる方法はまだまだ沢山あるな〜と思いました。
さいごに
私がmikanチームにジョインしてから度々思うのが、こうやって自分たちが過去やったこと・現在やっていることへの振り返りと、そこから学びを得ようとするカルチャーが徹底されているなという事です。
良い結果を得るために出来たこと、芳しくない結果になった経緯などを、次により良い仕事をやり切るためにチームでシェアするというmikanのカルチャーは個人的にすごく好きで、他のメンバーの振り返りも見ていて非常に勉強させて貰えたりします。
チームにとって良い影響を与える事を継続し、プロジェクトの進行を妨げる要因になりそうなものを排除する上でも振り返りはとても重要だと考えていて、個人・チームレベルのどちらでも日次や週次で振り返り、かつチーム内から色んなフィードバックをもらえるというのはすごく良い環境です。
最後になりますが、このような環境で働いてみたいと少しでも思った方、英語が好きだったり教育を変えていきたいという想いのある方、是非一緒に働いてみませんか？
以下の私のTwitterに気軽にDMして頂いても構いませんので、ぜひ気軽に声をかけてみてください！
