#1 RailsTutorial周回のあと…

投稿者: | 2021年1月16日

はじめに

いうまでもなくRails Tutorialは優れた教材です。Webシステムの開発をしたことがない人であっても、Githubなどのバージョン管理ツールのこと、ユニットテストのことなど周辺の必要な予備知識がちりばめられています。序盤ではMVCフレームワークでの開発の流れという開発の本筋が学べますし、後半のTwitterもどきを作る章ではそれなりにボリュームのあるWebアプリを作りきるので大変勉強になりますね。

しかしながら、Twitterもどきアプリはモデル数も少なく1画面1画面もシンプルなことしか扱っていません。SI業界でありがちな業務システム開発でRailsを使うことを考えると、RailsTutorialでやった内容を基本としながらもやり方を変えなくてはならない点が出てきそうです。

これから、RailsTutorialを1周以上したことを前提に、より複雑な仕様(≒より複雑なCRUD)のアプリを例に、設計や実装の記事を書いて行こうと思います。

目標

サンプルとして作るアプリを題材にしながら、「こういう時はこうする」というものを自身の知識や経験の整理もかねて、一例としてアウトプットしていこうと思います。(常にそれが正しいやり方だとは思いませんが…)

いわゆるSI系列の現場でお堅いシステムを開発するときによくあることに対応できるように書いていこうと思っています。

業務システム開発を見据えて

RailsTutorialで扱ったTwitterもどきはあくまで学習用のサンプルですから、実際に業務をするとなると下記の点の考慮が不足しています。

  • 一覧検索画面
  • 一括登録、一括更新、マトリクス式登録の仕組み
  • マスタ・トランザクション
  • 集計、ストックとフロー
  • ステータス、ワークフロー
  • 帳票

一覧検索画面

業務系のシステムでは、必ず存在します。基本は「単票CRUD画面」と「一覧検索画面」です。単票画面はform_forなどを使えば問題ありません。

一覧検索画面では、用意した検索条件に入力があれば合致する内容画面に一覧で表示します。Twitterもどきアプリではユーザの一覧などはありましたが検索条件はありませんでした。

一括登録、一括更新、マトリクス式登録の仕組み

一括での登録は、2つの側面があります。

1つ目は、テスト環境と本番環境で同じ作業を容易に行うためです。

例えば基幹システムなどでは組織変更の折に1人ずつ社員情報を変更するわけにはいきません。そのやり方では、「データの修正が抜けもれなく、誤りなく」できないからです。

よくある方法は、本番環境に適用する前に、手元に正しいメンテナンス予定の台帳を作成し、テスト環境で確認が取れた後、本番環境に同じデータを流す方法です。これで「データの修正の正しさ」を担保したいという要求はやはり定番です。

具体的には、ExcelやCSVのインポートで実装されることが多いですが、コピー&ペーストを介しても同等のことができればよいでしょう。

2つ目は、単純に単票画面(=モデルの1ID分の情報を確認、更新できる画面)に入りたくないという理由です。

一括承認の類は典型的なあるあるです。勤怠の承認など1つ1つ中身は確認しないことのほうが多いでしょう。

また、単票画面に入って戻るって次を更新する、という作業は相当ストレスになることがほとんどです。どこまでやったかわからなくなることもよくあります。

マスタ・トランザクション

顧客マスタ、仕入先マスタなどのマスタと、そこから派生する受注、発注などのトランザクションの概念はどうしても避けられません。簡単なTwitterもどきではいまいちマスタと呼ばれるものがありませんでした。

マスタが存在するときに注意すべきことは、マスタを変更したときの影響範囲を設計しておくことでしょう。例えば名称の変更であれば比較的リスクなく変更可能ですが、過去に作成した発注書の仕入れ先名が変わっていいのか?など考慮すべきことがあります。削除する際も、すでに登録されているトランザクションをどう扱うべきかがつきまといます。

集計、ストックとフロー

最終的には、countとsumくらいしかありませんが、受注や売上、発注、受入、在庫などでは、フローの集計とストック量の集計がよくあります。それに耐えられるようなデータベース構造にしておかないと後々辛くなります。

今回は典型的な集計である、先月末○○、当月〇〇高、当月××高、当月末〇〇のような集計と、「月末締め」の要素を盛り込んでみます。

(どのように辛いかというと、正しい集計方法がわからなくなってしまい、お客さんに詰められます。)

ステータス、ワークフロー

1人の人で業務が完結することは稀です。ある人が処理をしたら、次の担当者が処理する、ということが往々にして起こります。

わかりやすいのはワークフローですが、そこまで複雑なことは必要ない、という時にはステータスなどで「どこまで済んでいるのか」を管理していることもあります。

ステータスごとにどのような制御が必要なのか?を検討する必要があります。対象業務を理解し、ステータスごとにどうあるべきかを整理していきましょう。

帳票

CSVも帳票に含むことがありますが、それではつまらないのでどうせならばExcelを使って帳票を考えてみます。

Excelは印刷ずれの問題が常に付きまとうので、帳票ツールを使うこともあるかもしれませんが、今回は簡単にやりたいのでExcelでやります。