何かを作るプロジェクトにおいて、具体なしで関係者を説得するのは非常に困難だと感じる。
関係者が想像できないし、こちらも関係者が理解できているかを確かめにくいからだ。
ただ、同様に、具体だけで進めているとその時は説得できても、全体的な内容を俯瞰して理解できているかは怪しい。
具体だとスポットで理解はできていても、全体像としてどうなっているかを理解できず、要件を抜け漏れなく確認していくことが困難になるからだ。
ではどうするべきなのか？
少し前から一緒に作業しているメンバーがしていたことは非常に参考になった。
決めることは抽象的でありながら、見せる画面は今まで使っている画面で、差分を埋めていくような形で進めていくのだ。
見せる画面は今までのものだから、これになるわけではないのだろうと感じながらも、どこを変更するのかを現状の形を基準として決めて行けるし、判断が行いやすい。
ただ、全く新しいものを作る時はどうすれば良いのか。その場合はベンチマークとするプロダクトをベースとして同様に議論するのが良いのかもしれない。
既存のものがあるならばそれをベースに考えてゆけば良いのだ
そして、各ベンチマークが決まっていったら、そのベンチマークをベースとして、どこがどう変わるのか、必要な内容はなんなのか、逆に不要な要素はなんなのかをそのベンチマークをベースとして決めてゆき、原型がわからなくなって判断がつかなくなってきたところでワイヤーフレームに落とし込んでゆく。
そうすることで、どのように変わっていくのかが、明確にわかりつつ、変わった内容が理解できるようにできてゆく。
既存のものを変えるだけだとしても外からベンチマークをとってくることで、少し外れた提案をすることにもつながる。
ただ、具体を考える上で、全ての機能の詳細を考えなくて良い状態を作るためにもそういった工夫は必要になる。
また、この抽象を具体をベースに決めてゆくというフローはドキュメンテーションにも役立つ。
一つずつ具体を決めてゆくフローだと、ドキュメンテーションは手戻りになりがちだ。
ただ、抽象からうまく決めてゆくことで、その共有資料自体がそのプロジェクトを説明するに足るドキュメントとしての役割を十二分に果たしてくれる。
これは後々説明資料を作るだけでなく、ポートフォリオにする際にもかなり役立つことになると思われる。