1
/
5

開発効率を上げる!Gitを使ったER図とテーブル定義書の管理方法

※このストーリーは、noteで発信した記事を転載しています。

開発効率を上げる!Gitを使ったER図とテーブル定義書の管理方法|株式会社カンリー 公式note
株式会社カンリー エンジニア部の志摩です。 普段は「フクリー」の開発を行っています。 はじめに これまでテーブル定義書をスプレッドシートで管理していましたが、テーブル数が増えてくるにつれて管理が大変になり、様々な問題に直面していました。 本記事では、その問題点を解決するためにER図とテーブル定義書の管理方法についてフクリーチームで行っている方法をご紹介します。 改善したかった問題点 ...
https://note.com/canly/n/n4c5379fbf569

株式会社カンリー エンジニア部の志摩です。
普段は「フクリー」の開発を行っています。

はじめに

これまでテーブル定義書をスプレッドシートで管理していましたが、テーブル数が増えてくるにつれて管理が大変になり、様々な問題に直面していました。
本記事では、その問題点を解決するためにER図とテーブル定義書の管理方法についてフクリーチームで行っている方法をご紹介します。

目次

  1. はじめに
  2. 改善したかった問題点
  3. 選定基準
  4. 何を選定したか
  5. チームメンバーからの声
  6. まとめ
  7. 最後に

改善したかった問題点

  1. 最新バージョンの把握が困難
    • 複数のスプレッドシートで管理していたため、どのシートが最新でどのシートが最新ではないのかが分かりにくくなっていました。
  2. 変更履歴の管理
    • いつの時点でその変更が入ったかなど過去の履歴を追うのも手間がかかるような状態となっていました。
  3. レビュー
    • レビュアーが変更内容をすばやく理解するのが難しくなっていました。
    • 変更点に関してどういうレビューコメントがあったのか、どういう開発内容に対してのレビューコメントだったのかが後から追いづらくなっていました。
  4. 開発効率
    • 同様のシート内でカラム追加などを行っていたため、直近追加した変更差分がわかるように強調表示させるためだけの工数が発生していました。
    • 開発時に修正する際や確認する際にエディターとの往復回数が増え開発効率が下がっていました。

そのような問題点を解決するにあたり検討した方法の選択肢は以下になります。

ER図の主な候補

  • tbls
  • draw.io
  • dbdiagram.io
  • PlantUML
  • Mermaid
  • DBeaver
  • A5:SQL Mk-2
  • MySQL Workbench

テーブル定義書の主な候補

  • SchemaSpy
  • Markdown
  • A5:SQL Mk-2
  • DBSchema
  • tbls
  • Notion

選定基準

様々な方法がある中で、まず満たすべき条件を改めて整理し、それに基づいて以下の選定基準を設けることにしました。

  • 差分箇所が自動的かつ明確に表示され、該当箇所を指定したレビューコメントを残していけること
    • 変更箇所が自動的かつ明確に表示されることで、レビュアーが内容を素早く理解でき、具体的なフィードバックを提供できます。
    • また、変更点を強調表示させるための手動操作を省くことで、作業効率も向上します。
  • ブランチ単位でER図・定義書の管理ができること
    • 各ブランチで行われた変更の詳細な履歴を保持することができます。これにより、どの時点でどのような変更が加えられたかを正確に追跡できます。さらに、普段のDB設計以外の開発プロセスと同様に、ブランチ運用を通じて管理できることがベストだと考えていました。
    • 簡単に過去のバージョンに戻ることができるため、新たな変更が問題を引き起こした場合にリスクを軽減できます。
  • VSCodeで修正中のリアルタイムプレビューが表示されること
    • リアルタイムプレビューにより、変更が図にどのように反映されるかを直接確認でき、作業の効率が向上します。
    • また、VSCodeなどのエディター上で表示できるようにすることで実装中に確認したい場合でもツール間の移動がなくなり開発効率が向上します。
  • ER図の矢印やテーブル定義書の表など作図に時間を浪費しないこと
    • 手作業による作図で時間を消費しないようにすることで工数削減ができます。
    • また、作図を手動で行わないようにすることで誰が修正した場合でも図や表のスタイルが一貫し、ドキュメント全体の整合性が保たれます。
  • 外部ツールに依存せずエクスポートやインポートを必要としない管理方法であること
    • 普段の開発プロセスで使用していない別のツールへのエクスポートやインポートに関わる手間や時間が省けるため、全体的な管理コストが低下します。
    • また、全ての情報が一つの場所に保持されるため、情報の散逸を防ぎ、情報の追跡と更新が容易になります。
    • そして外部ツールでしか表現できない場合だとそのツールが使えなくなった時の移行コストが高いため、汎用的に使える方法がベストだと考えていました。

何を選定したか

検討した結果、上述した選定基準を満たすことができるPlantUML(ER図の管理用)Markdown(テーブル定義書の管理用)を選択しました。

Github上でテーブル定義書を表示した際のイメージ

VSCode上でER図をプレビュー表示した際のイメージ(※モザイク加工有り)

チームメンバーからの声

今回導入してみてどうだったのか実際にチームメンバーから意見をいただきました。
小泉:以前スプシで管理していた時は変更したシートやカラム、文字に色を付けていたのですが、その作業がなくなり変更点が見やすくなりました。
また、レビュー時に指摘してもらった箇所の修正漏れがなくなり、変更履歴を追うのも簡単になりました。
今後の改善点としては、ER図(PlantUML)をVSCode上で開いてプレビューするのが手間なので、その手間を省けるとより効率化できそうだと思いました。

まとめ

課題を改善し効率を上げるためにER図とテーブル定義書の管理をスプレッドシートから変更し、フクリーチームはPlantUMLとMarkdownを選択しました。
これにより、以下の問題点が解決されました。

  1. 最新バージョンの把握が困難
  2. 変更履歴管理の手間
  3. レビュープロセスの煩雑さ
  4. 開発効率の低下

今回選定基準として設けたのは、プルリクエストでの差分確認、ブランチ単位での管理、リアルタイムプレビュー、作図の効率化、外部ツールへの依存排除になります。
ER図とテーブル定義書をGitで管理することで、バージョン管理やレビュープロセスの効率化が図れました。
特に、GitHubのPR機能を活用することで、変更内容の可視化とレビュープロセスの効率化が大きなメリットとなりました。
また、開発メンバーが普段から慣れ親しんでいるGitHubを活用したことで、これまでの方法と比べてコメントのやり取りが一層活発になったと感じています。
さらに、Gitに集約できたことで管理コストの削減と情報の一元化も実現できました。
今後もこの運用を継続し、さらなる効率化を図っていきたいと思います。

最後に

カンリーでは、共に働く仲間を募集しています!
まずはカジュアル面談からでも問題ありませんので、興味のある方は是非お問い合わせください。

Invitation from 株式会社カンリー
If this story triggered your interest, have a chat with the team?
株式会社カンリー's job postings
1 Likes
1 Likes

Weekly ranking

Show other rankings
Like カンリー 採用広報担当's Story
Let カンリー 採用広報担当's company know you're interested in their content