DBデータ構造の改修タスクを通して得た学び

 

はじめに

業務委託で参画している伏田大貴と申します。

クロスマートではバックエンドを主に担当しており、
今回はDBテーブル構造の改修タスクを通して得た学びについてお話します。

 

DBテーブル構造を変更する開発業務自体は良くあると思いますが、

クロスマートでは、スタートアップというフェーズであることもあり、

大規模なデータ構造変更が求められる機会が多いと感じています。

 

クロスマートにjoinしてから、データ構造改修系の開発案件を何件か担当させていただいたので、そこで得た学びを共有します。

前提

  • 当時の筆者のステータス
    • 大規模なDBデータ構造変更の開発業務経験なし
    • 業務でがっつりdjangoを触るのは初
    • toCwebサービス開発経験が約4年。バックエンドがメイン。フロントも少しいじれる。
  • このレベル感の筆者による主観的な内容になります。
  • 今回お話しするデータ構造改修タスクについては、設計はメインではなく、実態としては大規模リファクタタスクに近いです。

携わったデータ構造改修タスクの例

クロスマートでは、卸と飲食店の受発注のサービスを提供しており、

代表的なマスタテーブルとしては、卸、取引先(飲食店)、 商品テーブルなどがあります。

それらのテーブルについて、例えば以下のようなデータ構造改修を行いました。

 

取引先マスタに関するテーブルのリレーション変更
  • 卸と取引先(飲食店)テーブルのリレーションについて、多:多から1:多に変更
  • 取引先(飲食店)に付随する複数のテーブルについても同様に、リレーション変更や別テーブル移行
 商品テーブルの単位カラムに関するデータの持ち方変更
  • 1レコードに複数の単位が詰め込まれた非正規な形を、レコードごとに一単位ずつ持つように正規化する変更

データ構造改修系タスクの難しさ

影響箇所が多い

商品や取引先といった主要なマスタテーブルを変更するとなると、それらを参照している全機能に影響し得ます。

各機能や実装に関する理解が求められ、把握するだけでも時間がかかります。

 PJが長期間におよぶ

影響箇所が多いため、PJの期間が長めになりがちです。一度始めたら途中で引き返したりやめたりすることはできないので、根気強さが必要になります。

 リリース時に不具合を出してはいけない

顧客の業務に支障がでると致命的であるため、エラーや不具合を出さないように慎重に進める必要があります。

また、不具合が出てしまうと、対応作業の工数もとられるため、開発効率向上という点でも、慎重に進める方が好ましいです。

経験して学んだ進め方のコツ

進め方を定期的に見直す

前提として、作業内容を一度に全て洗い出すのが困難という課題があります。全て洗い出した上で進められると理想ですが、影響箇所が多すぎるため難しいです。

 

そのため、作業内容の洗い出しはある程度で切り上げて、着手可能な所から実装を進めていく流れが現実的と考えています。

この進め方には以下のメリットがあります。

  • 手を動かすことで解像度があがり、副次的に作業内容の把握が進めやすくなる。

  • 作業内容への理解が深まることで、進め方自体をより効率的なものに見直し・改善ができる。

とはいえ、やみくもに手を動かすだけだと、手戻りのリスクが高くなるデメリットもあります。

 

そこで、調査 <-> 実装 を交互に取り組んで、最適な作業の進め方を臨機応変に調整する方法にたどり着きました。

「広く浅く」と「狭く深く」を切り替えながら進めるイメージです。

プロトタイピング的に動くものをざっくり高速に作って、それを元に詳細を詰める進め方も活用できます。

 

このような工夫によって、大規模で長期間要するPJでも、着実に進捗を出しやすくなりました。

ただ、現時点では我流すぎるため、もう少しアジャイル開発について勉強したいと課題感を持っています。

 

漏れなく影響箇所を洗い出す方法

一か所でも漏れるとリリース時に不具合がでるので、漏れを生まないことが重要です。

そのために以下の点を工夫しました。

 

静的解析で辿れない部分が厄介で注意が必要

影響箇所調査で漏れがちなのは、静的解析で辿れず、手動で調査しなければならない箇所です。

例えば、

  • リレーションの逆参照の変数
  • grepしにくいキーワード
    • 一般名詞のような検索結果にノイズが多く含まれるようなキーワード
  • コード外の影響箇所
    • レコードにjson文字列で持っていて、影響を受けてしまう箇所等

のような箇所に注意を払いました。

 

複数レポジトリを横断した調査の効率化

フロントとAPIリポジトリが分かれているのですが、影響箇所調査の際には、横断的に見れると作業がはかどります。

エディタの設定で、複数リポジトリを同時に見れるようにして、効率化しました。

シンプルですがかなり効果的でした。

 

調査方法を記録して残す

後で調査を再現できるようにしておくと、実装後に再度セルフレビューする際の効率が上がります。

また、こうすると漏れている箇所がないか不安に思うことが軽減されるので、自信や集中力の向上にもつながります。

 

段階リリースを活用

まず、段階リリースしやすくするための仕組みとして、フィーチャートグル機能という仕組みを簡単に構築しました。

これにより、影響が大きな変更も対象ユーザーを絞ってリリースできるようになり、リスク軽減できます。

 

また、PRやブランチを細かめに切り、細かく段階的にリリースするといった開発手法を意識しました。

リスキーなPRは他と切り分けてリリースすることで、全体的なリスク軽減につなげられました。

 

コードだけからではよくわからない背景については、詳しい人に必ず相談する

実装上の細かすぎる疑問点については、心理的に相談するのがはばかられる場合もありましたが、遠慮せずに相談することを意識しました。

気軽に相談できる環境に恵まれていたというのもあります。

 

確実にタスクを完了させに行くメンタリティーを養う

精神論になりますが、重要な部分としてメンタル管理があります。

 

圧をかけるぐらいの勢いで積極的に動く

作業の手、コミュニケーションの両面で”圧”をかけに行くようにしました。

ただ、コミュニケーションにおける礼儀は忘れないようにだけは注意ですw

 

フルリモートで業務委託という働き方が逆風にならないようにする

フルリモートで業務委託という自由な働き方をさせていただいていますが、

 

物理的にも心理的にも距離が生まれがちなので、

気を抜くと、仕事の進みが遅れてしまうことが時々おきていました。

 

作業環境を見直したり、意志力を鍛えたり(w)など、

モチベを自己管理することが大切だと感じています。

まとめ

データ構造改修タスクとして、どんな開発業務に取り組んでいるか紹介しました。

また、その難しさと経験して得た学びをまとめて共有しました。

 

業務委託という立場ですがデータ構造改修という大きな仕事にチャレンジできたり、

日々様々な学びが得られる刺激的な環境が魅力的だと感じています。

 

クロスマートでは絶賛エンジニア募集中です。

このお話を読んでちょっとでも気になった方がいたら

「話を聞きに行きたい」を押してみてください!

www.wantedly.com