ユースケースによって分割し、データのコード体系と構造で統合する
自分が何らかのソフトウェアシステムを考える際に意識していることを平易に、直感的に書き起こしておく試み。
何を当たり前のことを、と思われたなら成功。
やりたいこととシステムの立ち位置
本来システムはユーザーと目的によって最適解が異なる
目的の達成をシステムは支援する。
たまたま同じデータを利用すると同じシステムを解としたくなる
- 例えばライン工のように何らかのデータが流れてきて決められた入力や処理をすればいいだけであれば問題ないかもしれない
- よくあるケースとしては役割が異なればそのデータに対する目的も異なるので、上手に作らないと無理が生じる
ダメな例
こういうものはだいたい、最終的に利用したい成果物を扱う人が用意する。
- 最も極端な例は巨大な Excel の共同編集。極端な例とは言ったが、実際にはとてもよくあるケースのはず
- 神Excel もこの例。これはデータで活用する気はなく、紙で提出されていればよいことから、まずその書類を作る業務に最も近かった人が、手元の OS、手元の Excel、手元のプリンタでテンプレートとなるファイルを用意し、その運用を（悪気なく）押し付けてしまう1
- 大統一フォーマット。最終的な成果物を扱う人はデータのフォーマットが整っていないと困る。しかしそのまま全ユーザーに使ってもらおうとした結果、例えばある人はある項目の入力の際に100ある選択肢から特定の3つしか使いません、みたいなものができあがる。これの積み重ねは単純にストレスでしかない。
これらは適切に分割されておらず、関係者全員が同じものを使っているため、当然変更すると関係者全員に影響するのでおいそれと変更できなくなってしまう。
短期で終了する作業のためのものならよいが、長期的な運用を始めてしまうと地獄の始まり。
やりたいこととUIの不満
行う作業によってUIの最適解は異なる
以下は目的と求められることの例。
| やりたいこと | 大切にしたいこと |
|---|---|
| 入力 | ひたすら高速に入力したい、チェックも速く |
| 進捗確認 | 全体の件数、入力の進み具合を確認したい |
| レポート （いわゆるBIの領域） | 個々の入力の具合ではなく、統計データだけが欲しい |
例えば巨大 Excel で実現するとやたらあちこちスクロールしないといけなくなったり、入力する場所に気を使ったり、様々な制約が生まれる。
これを毎日毎回使わされる側はたまったものではない。ミスしやすいし、ミスったらみんなが使うデータを壊す可能性もある。
ノーコードツールで困ること
システムを「開発」せずに実現できるノーコード、ローコードツールが増えている。しかしこれらは以下の点で最初から課題を抱えていることを承知しておいた方がよい。
- いわゆるノーコードツールは概ね UI の作り込みを省略、簡略化する2ので特に最適化してほしい場合に UI の不満が出やすい
- データ構造にも無理が出やすいのでエンジニアからも不評を買いやすい
- 特に多くの種類の業務を一つのフォーマットに落とし込もうとするとどんどん無理が出てくる
- これはノーコードツールに限らない話だが、上のような分割の視点がない3から起きることであり、こうなると詰みやすい
解決策
データ、コード体系によって分割と統合を行う
- データの突き合わせが可能なら一つのデータベース、一つのシステムにこだわる必要はない
- 突き合わせ可能なデータ（コード体系）をどう設計し、どうシステムを分解するかが腕の見せどころ
ただし、これをスマートに実現するためにはデータを中心に、データベースに近い位置での制御が可能であることが望ましい。
全体で大きなシステムだがユースケースごとに適切に最適化できているなら一つのシステムであってもよい。（伝統的な開発ではこのパターンが多そう）
実は、この「データに近い位置で」が苦手なツールの場合、そもそも無理が出やすい。
特定のツール、特定の言語を使えるか使えないかはそこまで重要ではない
ここまでを考えるに当たっては、少なくともどんなプログラミング言語が扱えるかといった点は重要ではない。あえて言うなら SQL DB の考え方は重要。
- データの可搬性、可用性を上げるのはツール、言語ではなく「コード体系」や「ID」、「データ構造」
- この知識、スキルは陳腐化しない
- 「このツールは使いにくいからあのツールの方がいいかも？」は基本的には隣の芝が青く見えているだけ
- 乗り換えても乗り換えた先で多かれ少なかれ別な苦労が生まれる
Google Apps Script が使えるからとか Python が使えるから、とかそういうところで有利不利はあまり出ない。少なくとも全体の整合性4を保ちつつ最適化できる余地を残す、みたいな設計力と特定の言語の利用経験はあまり関係がないと思う。たまたま目の前にあるのが Microsoft Office だから、Google Workspace だから、以上には有利にはならないと思う。
もちろんこれらのライセンス契約の領域に踏み込む場合は単にコードが書けるとかツールが使える、だけでは済まない交渉になったりするわけだけど、データとユースケースを中心に考えたらツールの持ち替えや追加がベスト、という判断は十分あり得る。
言語、ツールに必要以上に縛られず、選択肢を増やせる方が重要。もっとも、本当に選択肢を増やすためにはそれなりに経験を積まないといけないけど。
これから開発を専門としない人がシステム、データに関わるために
はじめよう！プロセス設計 ～要件定義のその前に | プログラミング・システム開発,開発技法・ソフトウェアテスト・UML | Gihyo Direct
が参考になる。
- なぜそのデータが生まれるのか？
- このプロセスはどこに繋がるのか？
この視点はとても重要で、特定の製品を知っている知っていないよりもはるかに寿命の長いスキルになる。
ただし、実際には自分でゼロベースでデータを中心としたシステムの構築経験なしにこの勘所だけを掴もうとするのはかなり無理があると思う。残念ながら。
特定のツールを導入して解決できるのは恐らくその時点で瞬間的に見える範囲だけであり、何らかのシステムを導入したらその瞬間から新たな課題が生まれ始めるだろう。
現実ってのはそういうものだ。