眠いところで書いているメモなので話がまとまってないのはご了承願いたい。
結論は、
アイデアトランプはアイデアを出すだけで無く、設計という行為を行えるツールだという事。
今までの経験ではソフトウェアの設計をおおざっぱに書くと以下になる。
仕様 → レビュー
→ 設計 → レビュー
→ コーディング → レビュー
設計は一人もくもくとやったり、設計検討会を開いて会議室に詰めて考えたりする。
一人で行う場合に煮詰まると他の人に相談したり、はまったりする。
設計検討会は色んな人と意見を交わして作りを込んでいくので一人でループにはまる事は減る。
ただし、工数がかかったり、会議好きな人が延々と会議をする落とし穴もある。
今回のハッカソンではアイディアソンで作成したA4一枚のみが仕様書にあたる。
そこからアイデアを膨らましたり設計を行っていくのだが、そこでアイデアトランプを使用した。
自分の中では、以下を考えていた。
・一人でアイデア考えるのもしんどい
・せっかく集まったメンバーと一緒に考えた方がいい
・ババ抜きしながらメンバーの個性や視点の違いもわかる
・元ネタをみんなのアイデアで膨らませたい
主には「アイデア」と言う視点だった。
ただ、今思うと非常に効率的な設計行為であったと思う。
ババ抜きと言うルールがある為、よくあるの設計検討会の様に何も喋らず会議にいるだけという問題も回避できる。
最初はアイスブレイクも含めた軽いネタ出しに始まる。
そうしてるうちに、ババ抜きをしている感覚がフランクな会話を産んでいく。
ただ、このままで続けるとアイデア出しで終わるので2つ条件をかぶせた。
1.アイデアを出すことが目的なので、他の人の番でもアイデアを出してかぶせていこう。
2.自分のやりたいアイデア、作り込みたい機能は?
自分のコーディングスキルで出来るアイデアは?
この二つを考えて出してください。
これらの条件をかぶせることでアイデアトランプの使用例にとらわれず自由にアイデアをかぶせることが出来る。
また、自分のやりたいことを話すことで自分の意見をみんなに聞いてもらえると同時に自分のスキルを羞恥心をおさえた形で発言できる。
今回のハッカソンはメンバーの組み合わせが良かったのでうまく回った。
普通にプロジェクトをやるのとは違うスピードが体験出来た。
みんな、ありがとう。
(気が遠くなってきたので、最後が雑でゴメンナサイ)