イキりエンジニアのシステム設計編 part2
前回の続きから...
４．言われたことを実装したらバグが生まれた
これこそ、害獣が駆逐したい対象のNo１💫に
輝く素晴らしい人材。
我々、エンジニアが心掛けなくては
いけないことは、常に自分が作るシステムに
ポリシーを持つことだと考える。
出来るエンジニアと出来ないエンジニアを
見極めるときによく質問することは、
システムのポリシーについてだ。
私は、PHP出来ます！Ruby出来ます。
Mysqlが・・・とか
スキルはあればあっただけ良いが、
害獣にはどうでもいい。
『現場の意見を取り入れたら、間違っていた！』
とか顧客のせいにしているのを見ると、
バカにしたくなる。
システムのポリシーから外れたものを
実装している時点で
システムとして既に破綻しており
使えないものを生み出しているという
認識を持ってほしい。
では、システムのポリシーとは何か
具体例を挙げるとしたら
・一元入力（一度入力したら、再度同じ情報を入力させない）
・確定後の数字は、変更されない
などである。
例えば、請求書を出力するシステムにおいて
【既に確定された数字を変更したい】という
要望があったとする。
何も考えず、その数字をアップデートする機能を
実装したとして
簡単に金額などを変動させ、不正を助長する機能を
入れても良いのかということを
検討・精査せずにただ機能が作れるからといって
実装してしまう側に問題がある。
本来、確定後の数字は変更されないという
ポリシーがあるならば
伝票に対して、赤伝・黒伝の概念を設け、
もし仮に変更をしたとしても
伝票のデータをそのまま上書きせずに
新しく伝票のレコードを生成し、
【誰が】【何のために】【どのように】変更を
行ったのかなどの情報を
持たす必要があることは明確になるのだ。
何のポリシーも持たないで作業することは、
死んでいるも同義で
ただ言われた機能だけを作りバグを生み出し
使えないシステムを生み出す奴隷。
エンジニアは、サービス業ではなく
職人であるべきだ。
５．システムの項目を辞書化する
システム設計で、一番難しいのはDBの設計だと
思っている。
そこで、DBの設計や仕様を整理するのに
使える資料の作り方の例を挙げる。
まずは、辞書化を行うことをオススメする。
【辞書化】
このシステムにおいてどのような項目が
存在するかということを整理し管理することを指す。
Excelが一番扱いやすかった為、
Excelで辞書化を行った例が下記の図である。
この資料により、
【何の項目】が【どの画面】で
利用されているのか一目で分かるので
10万円の案件だろうと1億の案件だろうと
必ずやっておくことをオススメする。
辞書化の行い方としては、
- 管理したい項目をひたすらA列の2行目以降に記載していく
- 次に、画面名（または機能）を1行目のB列以降に記載していく
- 各列に表示（入力または出力）する内容に〇を付けていく
後は、どの画面でINPUTされるか
OUTPUTされるのかをこの資料に追記したり
みんな大好き正規化を行えば、良いのである。
最初は、このシステムが
項目数100個なのか200個なのかいくつで
構成されているとか把握することが大事で
この作業もせずにテーブル構成を考えている人は
天才じゃなかろうか？
６．シンプルイズザベスト
速度を上げるためには、intにした方が…
とか色々な事情がある場合を除き
基本的に～フラグや～ステータスは、
撤廃するべき。
【genderカラムにある１が男で、２が女です！】
とか仕様書を見なきゃ分からない数値で
管理している場合が多く
文字列で持ってもいいのでは？と思う箇所まで
数値化されており、
数値に【意味】を持たせてしまっている設計が
多いのではないだろうか。
このシステムだけで完結する場合は良いが、
他システムと連携を行った際に
お互いのシステム仕様書を突き合わせて
整合性を合わせる作業になった際は、
とんでもなくコストがかかる。
（コンバージョン作業等）
コード（id等）を持たせてしまうことで
如何にシステムを動かしづらくなるか分かるので、
フラグやステータスをなるべく減らす努力は
するべきだ。
本来、システムというのは
時系列ごとにデータが作られていくので
～フラグではなく、日付で管理されるのが
正解であると考えている。
ただし、フラグをどうしても持たないと
いけないときなどは、
～フラグテーブルなど、１つのテーブルにまとめ
システムを制御する仕組みにすればスッキリし
作成者も管理する箇所が減りバグが減るのである。
システムは、
シンプルが一番難しく一番素晴らしいものだ。
７．データを色んな角度で眺める
リレーショナルデータベースは、
親となるデータを登録した後に、
子となるデータを作成し紐づけるが
idだけで紐づける設計以外も
考えてみようというお話である。
例えば、伝票を作るシステムがあったとする。
１．ユーザー登録
２．商品情報の登録
３．売上入力
４．伝票作成
この４つのフローで伝票データを
作成するシステムがあったとして、
通常は、１・２・３の順番を絶対に
踏まないといけないことになる。
...なんて構造が多いけれども、
それを常識としないで欲しい。
例えば、idで紐づけていた場合は、
顧客から
『他システムに格納されている伝票の情報を
本システムに登録したい』
という要望が出た場合、
とてつもない労力になるのだ。
伝票テーブルの構造が、
～マスタのidや
～サブマスタのidやらが必要だった場合
それらを置き換えるプログラムの作成やら
検証やらを行う必要が出てくる。
しかし、伝票データの構造が
idで紐づけるのではなく【名前】などの名称で
紐づける仕組みになっていれば、
コンバージョン作業など一瞬で
終わるのではなかろうか。
伝票データの生成後にユーザーを作ろうが、
名称をキーとしている為、どちらからでも
データの取り込みが可能である。
上記のように、前からデータを入れていく
仕組みだけではなく
データを後ろから入れようが、
前から入れようが問題なく動作する仕組みを
考えてみるのも大事な観点である。
８．色んなところに意識が行き届いているか
自分が作ったものに、意識がきちんと
行き届いているかを確認をしましょう。
例えば、
自分が作った資料の【色】に注目し、
赤は、エラーであったり、
オレンジは、入力だったり
緑は、出力だったり
意味を持たせていますか？
ただ、カラフルにして見やすくしている方も
いるかもしれませんが、
目的を伝えたり、システムを作る上では
重要になる。
今回、例として挙げるときには統一出来なかったが
青色は時系列を示す。
選択ボックスは～色にするなど
統一されていれば、ユーザーもシステムを
理解するのに楽になります。
たかが、色と思うかもしれませんが
色に意味を持たせるなどの工夫はあるべきだと思う。
９．最後に
最後に、自分が作ったシステムに
愛を注ぎましょう。
10年後、20年後でも使って貰えるような
システムになれば良いなと思い、
害獣はシステムを作っている。
システムは成長をするものであり、それらを
直していくうちに自分自身も成長していくものだと
考える。
今回の記事は、
機能の納品という行為に疲れた人こそ、
読んでもらいたいと思い
今一度、自分は何をしたいのか？ということを
振り返っていただけたら、
この記事を書いた意味があるかと思う。
こんなに書きたいことが多く、まとまらないとは思わなかった...🐾
