下手に言語化しない
プロダクトのコンセプトを一言で説明するみたいな変な風習、重要な情報が欠落するのでやめたほうがいいと思っている
対外的なプレゼンテーションの為には仕方ないと思うけど
一言コンセプトでチームをまとめようとするの良くない
どうとでも解釈できる
ふんわりしてしまう
外国語に翻訳すると意味が変わったりする
最初に決めたボンヤリした物にみんなで向かっていくぞ！
どう考えても無理
実際の体験・エピソードに基づく言語化の方がまだマシ
◯◯の時にAさんがナントカカントカしてこうなった時のような経験を誰でも味わえるシステムを作りたいよね、とか
劣化コピーにならないように気をつける必要はある
安直に◯◯を模したプロダクトが元ネタを超えられないのよく見る
プロトタイプの方がわかる場合が多い
でもプロトタイプどころか動いている完成品を見ても、良いとは感じるのに、なぜ良いのか？まではわからないレイヤーの設計がある
実際にやっている事はだいたい
が書いてくれている
（管理という感じでは無い気もするが）
> 機能は独立していない
このへんは本当にそう思う
確かにScrapboxにたくさん書くけど、アイディア管理という感じでは無い気がする
なので言語化してみる
このページの上の方にも書いたが、よくわからないし、物が動いていてもよくわからない部分すらある
なるべく意味や意義は明確にしていきたいのだが…
ここは「下手に言語化しない」方がいいな、という場面がある
重要な情報が落ちない
自分の発見の機会が減らない
そういう時はあえて言語化しないようにしている
グチャグチャでいい
グチャグチャで断片的な大量の考えがある
具体像は見えてるような見えてないような感じ
断片同士の関係性を見つけながら具体的な形を探したい
個別にCosenseにページを書いて、見つけていく
見つけていくといっても、連続的なプロセスではない
こねて、しばらくするといきなりビジョンが見えて3時間ぐらいで実装できる
人間の言語の表現力は低い
同時に並行して起こる物事や、複雑な条件、排他的な処理などを表現するのに向いてない
よい表現方法が他にあるなら、それをそのままプログラムとして実行できるインタプリタ作ったほうが良い
人間語捨てていきなりコード書いたほうが良くね？
事前に頭のなかで意義とか意味とかを整理して、イメージ作る必要はあるけど
要件をScrapboxに書き出せるだけ書き出して、リンク作って
要所要所はProcessingのSketchのような感覚で作れるようにしたい
リファクタリングをしっかりしておく
実際にプログラム書く事で考えが深まる事がよくある
動いている物を見て（自分が作ったのに）ようやく意味がわかる事がある
最初から完全に説明できるなら、自分でプログラム書く必要は無い
外注すればいい
わからないから作る
自分が最初に想定した事以外にも使い道があったら面白い
web標準とか、汎用的な小さな機能とかを意識すると、開発者も予期せぬ機能間の組み合わせが発生して面白い
Scrapboxの目的の一つとして、「書く・考える・伝えるを同一化する」というのもあるけどそれに近い
わりと実装失敗する
3回ぐらい失敗して、しばらく寝かしておくか・・ってなる事もある
何が良くなかったのか、Scrapboxにメモしておく
全体としてダメだけど良かった部分や新しい発見もあるし
俺は手戻りを一切恐れてないので、細かく仕様詰める無駄な時間を過ごす間に3回作って捨てる
実際の使用環境、実際のデータで開発する
架空のユーザーに向けて架空のデータで作ると、ショーケースのような美しい、うまく動かない物になる
ここに向かって行くんだというイメージ作りには有用
しかし動的なUIが生み出す没入感までは作れないので、そこが重要な場合は机上の空論になる
没入感とか必要ない場合はペーパープロトタイピングでいい
言語化する物
レビュー・現状分析
実際に存在する物に対しての、どこがどう良いか・悪いかという事
感想ではなく
他と比較して効果の差を述べたり
あるいは、◯◯に似ていて同じ効果があるとか
要望・苦しみ
実際に困っている感情は存在するし、とても重要
青写真
最終的にそのプロダクトを使って何がどう変わるか
完全には言語化しない物（多少はする）
画面遷移
UI
インタラクション
なお実装できて動くようになったら、pull requestの時までに言語化する
意図
何が問題か
現状がどう変更されるか
というような事を考えてやっていっている