抽象の状態でコミュニケーションを取りたい

Figmaやコードでプロトタイプを作っても、もう既に具体的すぎ

理想的にはもっと前の状態で議論ができると良い

一人で全部作るなら別にそうすりゃ良い

概念レベルと表現レベルで分けて考えるをした時に、

前者の状態を維持したままコミュニケーションを取りたい

現状(誰の?)のフローでは二重の問題がある

なにかチームで制作する時に、

ドメインに詳しい人Aが要件を検討して、

それをデザイナが画面設計をして、

エンジニアが実装をして、

というのが、タスクの切り方として適切でなく歪に感じる

デザイナとエンジニアが、同じ対象を別々にモデリングをしてるのがおかしい

もう少しマシにするなら、

誰か1人がモデリングしてUIや機能の大まかまでを決めてしまって、

タスク分配という理由のみで、デザイナがUIを作り、エンジニアが機能を作る

という風に分けたほうが良い

そして更にできることなら、

1人がある機能を、モデリング、UI、実装をやって、

もう1人も、ある機能を、モデリング、UI、実装をやって、

というように縦に切るのが当然最も良い

ここまでが前提

(なのでページを切っても良いかもしれない)

チームでやっている以上、何かしら批判し合えるのが最も良い

一番早いタイミングでの批判ができるとしたら、モデリングしている過程

この時点では特に目に見える成果物がない

この状態でいかにコミュニケーションを取るか

このふわふわした概念レベルの状態で洗練したい

どうすればよいのか全く見えていない

そういうツールを使うとか

自然言語

イラストを描く

ユースケース図的な図を書く

抽象的なプログラミング言語を使う

何らかの静的型付言語の、型のみを使って表現する

Alloyを使う

なければ自分で作れば良い、という話もある

の3章で、データモデリングも外部設計であるという話が出てきた

外部設計ということは顧客に表出するべきということである

データモデルという抽象的な表現をどうやって顧客に理解させ、これを元に議論を進めるか

パッとなにかの相談をチーム内でするときに、

抽象的でありながらも厳密なツールを用いてコミュニケーションできると良い

簡単なもので言うなら、チームで使ってる言語の型とか

UMLのようなものでも良いが

厳密性を大事にするなら形式手法言語を使うとか

抽象度の高い状態で試行錯誤するをチーム内で行えると良い

方針の段階でCode Reviewもまあちかい