NISHIO Hirokazu[Translate]
見た目の進捗と中身の進捗
t0~t1: まずどんなものができる予定なのかのイメージ共有のために見た目のモックがつくられる
不確実性がある内容は適当に決める
必要なデータがなければ適当に作る
「もうリリースできそう!」「いやいや、中身がまだですから!」
>前回「もうリリースできそう」とか言ってたXさん向けに現状を建築に例えて説明しておくと、新しいマンションを建築する的な状況で、前回は「とりあえず見た目がどんな感じかわかった方がいいから裏口から道をつないでコンテナハウスでモデルルーム作って内装見れるようにしますね」をやって、その結果「あれ?この『裏口』だと思ってた経路の方が本番で人を流すのに向いてるんじゃね?」となって、今は本番マンションの廊下とか水道管とかの設計を修正している感じです
> モデルルームはまあまあ綺麗だったけど、本番マンションはまだトイレの水が流れないので入居はできない
t1~t2: ロジックの実装を進めると、色々当初の想定と違うことが出てくる
必要なデータが当初期待していた手段で得られないとか
表示すべき他のデータがあるのを忘れててUIに表示欄がないとか
それらをアドホックに解決するので見た目は一旦悪化する
中身の実装が優先なので見た目に労力を割いていない
>大手術をして型エラーが全部消えた!と思って実行したらXが型を定義してなかったのでそこでこけた、そういえばそうだったw 水道管を全部繋いだと思ったチェックもれがあって、トイレの下水管は繋がってるけど上水道が繋がってないので流せない状態ですw
数日後
>いま「水道管はつながって一応動いているけど、時々水が漏れる」を直しつつデータを入れて実験している感じ
t2~t3: ロジックがひと段落つくと見た目の改善ができるようになる
色々不確実性が減ってるのでスピーディーに進行できる
中身の実装が終わって手が空いたので見た目の改善に時間を使えるようになった
マンションで言うなら、いちおう入居はできる、内装をこだわるフェーズ


関連
ある意味t1の段階でプロトタイプを作って、それを破壊しながらt2の実装をしているとも言える

"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]