設計って、何をするの？
今回は設計、だよね？
そうだね😎
正直さ、設計って聞くと
“難しい図”とか
“大量の専門用語”のイメージがあるんだけど…
大丈夫、今日やる「設計の型を決める」のはもっとシンプルだよ☺️
システムを、どう分けて考えるか を決めるだけだね
本格的な設計書はAIに生成してもらうよ😀
答えを一つに縛るための“型”を作る工程じゃ
型がないと、人もAIも、好き勝手な答えを出してしまうからのぅ😏
まずは大きく分ける（図①向き）
今回のシステムは、大きく言うと三つじゃ
1. 画面 … 人が触るところ
2. データ … 商品・在庫の情報
3. ルール … 誰が何をできるか
これも図にまとめたほうが分かりやすそうだね
こんな感じかな？
上出来じゃ☺️
画面という軸で考える
じゃぁまず「画面」から考えよう
ここで言う画面は、デザインとかではなく、
画面に見える情報、見えない情報ということだよ
情報が見える・見えない、の話だよね
そう、ここで考えるのは、
誰に、どこまでの情報を渡すべきかじゃ
要件定義の内容を振り返ると、だいたいこんな感じになるかな
ゴリ夫（営業）：判断に使う情報
ネコ美（事務）：正確性を確認する情報
ヤギ沼（課長）：全体を俯瞰する情報
カキカキ…書けた☺️
なんていうか、こんな抽象的な情報でいいの？
うん、大事なのはデータの性質を見極めることなんだ😎
データの設計
次はデータじゃ
今のExcel管理って、商品情報と在庫数が1つにまとまってるよね？
うん、ひと目で見やすいからこの形になってるけど、
正直上書きの温床になってる気がする…
そうだね
在庫の上書きで間違った値になったり、在庫を動かしても商品情報が変わったり、
そんなことが起こらないように商品データと在庫データは分けて持ったほうが良いね
まとめると、データ軸はこんな感じかのぅ
ゴリ夫（営業）：日々変動する数値
ネコ美（事務）：正しさが保証された他部署も信用して使うデータ
ヤギ沼（課長）：判断材料としてのデータ、直接触らないデータ
よし…っと☺️
だんだん背骨が見えてきたのぅ☺️
ルールの設計
次はルールだね
ルールって、要件定義で決めたこととは違うの？
要件定義で決めたのは「方針」じゃ。
設計で決めるのは「どこで守らせるか」なんじゃ
ほえー🤯
たとえば、
・営業が忙しいときに、つい確認せずに在庫更新する
→ 営業にはルール遵守を期待しすぎない
・誰でも商品情報が更新できる
→ 商品情報の正確性はは事務が責任を持つ
とかとか😎
なるほどー！ 使う人が気をつけるんじゃなくて、システムのルールで
ミスをせき止めるんだね
左様じゃ
これがミスが起きない設計じゃな。
ここには「期待してはいけないこと、任せるてはいけないこと」を入れるぞい。
それぞれまとめると、
・営業
注意深さに期待しない
ルール遵守に期待しない
・事務
正確性への責任は持つ
他からの操作を信用しない
・課長
個別操作には関与しない
例外対応に追われない
よし、こんな感じかな
なんかゴリ夫くんとか営業部がお説教されてるみたい😂
弱点をシステムでカバーする意味合いもあるからのぅ
文字にすると、苦手なことを攻めてるように見えてしまうこともあるな😂
ここでAIの出番
ここまで整理できたらAIの出番だね
・業務分析
・要求定義
・要件定義
結構長い道のりだったなー💦
ふぉふぉふぉ
街中にあるビルを見てみぃ
ただのビルに見えるが、その影には途方もない計算と設計が隠れておる
システムも同じじゃ☺️
たしかに！ いままで意識したことなかったな…
いろんなモノに、ありがたみを感じるようになるよ🤣
次はいよいよ「設計書の生成」
次はこれまでの情報をAIに入力して、設計書を完成させるのかな？
左様じゃ、設計書を形にするフェーズじゃな☺️
ここからはAI活用がグッと増えてくるよ😎
どんなにAIが優秀になっても、良いシステムは良い設計からしか生まれん
そのことを肝に銘じて進めるぞぃ😎
次回予告：第７話 最終回「設計②」
設計の型が揃ったとき、
AIは一気に設計書を書き始める。
人間が決め、AIが広げる。共同作業は、最終フェーズへ。
前の話、次の話、を読む
お問い合わせ
もし今、
・AIでシステムを作ってみたいけど、何から考えればいいか分からない
・SaaSを増やしすぎて、業務がかえって複雑になっている
・AIで作り始めたが、この進め方で合っているのか不安
と感じていらっしゃいましたら、
無理に作り切る前に、一度ご相談ください。
「まだ構想段階」「考えがまとまっていない」状態でも問題ありません。
一緒に整理するところからお手伝いします。
