タスクを効率的に処理していくと高速にクソアプリを実装してしまう
要望きた！→即実装！をするとクソアプリになる
その機能がユーザーが望まれていて、自分も欲しいと思っていたとしても、すぐに機能として組み込まない方が良い
まあ2割詭弁、8割本気なんだけど
こういう詭弁を弄しておかないと、焦ってしまう
いつでもどこでも無限に仕事できてしまうし、深夜でも何でも対応できてしまう
速度が上がっていくとハイになりすぎて、わからなくなる
ただの思いつきなのか
本当に必要な機能なのか
（と言いつつ、わりと本気でクソアプリになるだろうなとも思っている）
以前/remoteというイベントで話した事の中から、ブレーキをかける事に自分で自分を納得させる為の考えをまとめる
機能をどんどん追加しちゃだめ
機能の数だけUIが必要になる
ツールバーとボタンだらけのやばいUIになる
プロ用ならそれでもいいんだけど、思考をブロックする要素を減らしたいという事情がある
機能が増えるのは悪い事だ
覚える事が増えると工夫ではなく暗記になってしまう
汎用的な小さな機能を組み合わせる事こそが楽しさ
複数の要望を解決できる小さな機能
それどころか、開発者の予想していない使い道が産まれるような汎用性がほしい
バグが増える
バグは正常に動いている2つの機能の狭間に発生する
追加した機能に思わぬ副作用があるかもしれない
行毎に更新者情報を自動的に表示してみた場合
「最後に書いた人」という意味の情報なのに、「私の意見です」に見えてしまう
他人の書いた行を編集して誤字脱字を修正してあげる事ができなくなってしまった
これはsemiraraでやった失敗
ページリスト画面にもテロメアを出してみた場合
2,3人のprojectなら、未読リストとして正常な効果がある
20人ぐらいいると未読マークだらけになる
ものすごい圧迫感がでて、ウンザリした
けっこうがんばって実装したんだけど、通知地獄とか圧迫感とか嫌だよねという事が再確認できた
知見が得られたので、捨てるのにためらいは無かった
何事も作ってみなければわからないので、プロトタイプを作るのは良いと思う
最初からproductionに組み込む前提で気合入れすぎると良くない
機能を追加する事が目的になってしまう
pull requestの数を競争させる人事評価制度があると、クソアプリを作る原因になりそう
1ヶ月後にもっと良い機能を思いつくが、機能が衝突していて矛盾が起こるかもしれない
特に記法まわりは面倒なので慎重にやる
ユーザーから来る機能追加要望はだいたい間違っている
感じている不満は正しい
不満は現実に存在するのだから
不満から考えだした機能案のうち、9割ぐらいはそのまま実装すると色々ブチ壊しになる
自分と異なるシチュエーションで使う他のユーザー像を想定していない
ブラウザ等の技術の進化予想を予定に組み込んでいない
高コストからの低クオリティの恐怖を考慮していない
いい感じに料理するために、ホイホイYesを返さない
フォーラム等の返事は
でいい
こうする
要望などは3ヶ月ぐらいは置いておいてもいい
Cosenseで個別にページを作って整理しておく
要望を300個ぐらい入れておいても、全て頭に入る
個別項目ではなくネットワークとして知覚できるから
関連ページを眺める
そういえばコレはアレと似ているから、一緒に解決できるかもなあ
等の情報をリンク記法で書いておくと、関連ページリストが生成される
リンクのリンクつまり2hop先まで計算して、関連度順に自動的にソートされる
調査してメモする
これもリンクで整理する
そのうち何か思いつく
Scrapboxのネットワーク構造は脳の記憶や連想のしくみと極めて近いと思う
こういう「整理してまだ盤上に出てないピースをあぶり出す」ような作業と相性がいい
思いついたら3時間ぐらいで実装する
下手に言語化しない方がいい場合もある
考えるために作る、作る事で考えを深めるのを意識してやっていく
考える速度で実装できるように、日頃からリファクタリングしっかりしておく
ドキュメントを書く
コード書いてる時間と、Scrapboxにアイディアを書いてリンク繋いでコネコネしている時間は同じぐらい
ドッグフーディングになる
足りない物は見える
まあ3ヶ月置いておくといっても
そもそも全く思いもよらない要望や感想が外部から来た事は、ここ10年ぐらいほとんどない
なぜ、何のために、というのは作りながらしっかり考えるようにしている
欠けている物もそこそこ見えている
人から意見をもらった時
結論は既にほぼ出ている
大抵のユーザーの感じる感情はシミュレート済み
稀に、そうでない場合ももちろんある
優先順位は上がる
やはりそう思う人もいるんだなあ、というだけ
scrapboxに関する要望は/forum-jpにお願いします