イキりエンジニアのシステム設計編 part1
害獣がトキワの森の記事を
ハックしたぞぉーーー！
害獣についての解説は省く。
これから記載していく内容には、人によって異なる
見解があったりするので
違うぞ！😠という考えを持っている人こそ
アウトプットをしていって欲しい。
【この記事の目的 】
言語についての解説やフレームワークの設定等は、
世の中に多く出回っているけれども
顧客との関わり方やシステム設計の思想に
ついての記事が思ったより少なかったので
１匹の害獣の経験を元に、この記事を書いていく。
１．システムは5W1Hで考える
まず初めに、システムの基本は5W1Hで
考えるべきである。
『今更なんじゃ、分かっているわ！』
という方こそ原点に振り返って欲しい。
全てこの言葉に通じるので、これ以降の内容に
ついてもこの言葉を念頭に置いて読んで欲しい。
２．DB設計はアウトプットからインプット
まず前提として、
本来システムを作るということは、
何かしらの到達点となる目的がある訳で
伝票を出力するという目的の為に、様々な情報を
入力するのである。
つまり、我々は最終目標である伝票という
出力物の情報を整理し
アウトプット→インプットを考えなくては
いけない。
近年では、
【データ構造】と【画面】を同一視してしまって
いる方が増えている。
なんとなくで、
会員情報の登録 / 確認画面を作れるし
なんとなくで、
商品情報の登録 / 確認画面が作れる
仕組みが拡充した為
インプット→アウトプットの考え方でDBを設計し
仕様バグを生み続けるエンジニアが
増えてきているように思える。
また、
『顧客から機能はまだ確定していないのに
システムを作れと言われて出来る訳が無い！！』
と嘆いてるエンジニアは、正解であるが
もう一歩先に行く必要があると思う。
もう一歩先に行きたい方は、
顧客と一緒にシステムを思案していくことを
大事にした方が良いと思う。
３．顧客と情報を共有し一緒にシステムを作る
これから書く内容に、
職業や立場・環境を非難する内容ではないことを
明示しておく。
SESで働いている方に多いと感じたことは、
- 質問をしてこない
- 出来ないと言えない
この2点である。
これについては、実際に『出来ない』と言ったら
評価が落ちてしまう環境が多いので、
そうなってしまうのは仕方がないと思っている。
ただし、報連相が出来ないのは論外である。
『出来ない』と言うことを恥とし、出来たら
報告し褒められようとする糞みたいなプライドが、
チームだったり顧客だったりに迷惑をかけて
しまっていることを再認識するべきである。
私たちが目を向けなくてはいけないのは
【顧客】であり、
【納品に間に合わせなくてはいけない】ことが
目標になっている人に
顧客にとって良いシステムなんて作れる訳もなく、
顧客が納品を押し付けてくる敵として
見ている時点で良い仕事や良い関係性が
出来る訳が無い。
下手に業界用語を用い、出来る風とか
そんなくだらない事はどうでも良く
顧客目線でシステムを作ることが大事なのである。
また、顧客目線でシステムを作るとか
謳っていながらも、
『～機能について、マニュアルに書いたのに
読んでないのが悪い！』とか言っている
愚か者は断罪じゃ！
読んでも理解出来なかった物を作ってしまったと
反省するべき。
少し話が逸れてしまったが、
顧客と同じ目線でシステムを語るとき
文章で書いても共通認識と
異なってしまう場合がある。
そこで、フィッシュボーン（特性要因図）を
参考に業務フローを描いて話すと
お互い話が通じ合うぞ！
（※気づいたけど学生の検索とか漏れまくりの図）
書き方としては、1本でっかい線を引いて
一番右には、ゴールとなる事柄を書き
左から右へと時系列順に
流れるように【機能】を書いていく。
この図を書くだけで、
・このシステムの目的は何なのか
・このシステムの登場人物は誰なのか
・このシステムはどのタイミングで動くのか
などが一目で分かることになる。
前述したように、この図を書くことで
お互い必要な機能を認識するので、
【機能の漏れ】を事前に防ぐことが出来る。
これにより、お互いが納得し同じ方向を見て
仕事がしやすくなるのだ。
いつも要件定義の際には、ホワイトボードや
メモ帳にこれを書いてお互いの認識を
すり合わせているが機能の漏らしや、
お互いの認識に齟齬が発生しにくくなった。
長くなったので、次の記事へ
