新機能の最初のリリースを早くする方法
最初のリリースを早くする技を解説しました。1時間ぐらい喋ったshokai.icon
proof of conectすべき核ギリギリまで削ってさっさとドッグフーディング開始しろ
重要ではない所は手を抜け
詳細は下を読んで下さい
2024/12/3(火) 17:00〜18:00
今回掘り下げる話題はここ
2. プロトタイピングと最初のリリース
とにかく無から形にするのが求められる
かつ、ものによっては性能改善や機能の余白を残しておく さっさとリリースする
実際に使ってみて、その機能のスジが良いか感触を確かめるため
ここの精度を上げると、1の領域にも少し入ってこれるようになるはず
3を複数並列して進めれるようになるはず
ケーススタディ
採用した実装、やった事
採用しなかった実装、やらなかった事
shokai.iconの採っている方針
早めに手触りを確かめる
最初から作り込みすぎない
1プルリクで実現できる簡易版を考える
段階的実装
負けた場合の撤退
抽象化して別の機会にも活かす
実はこれで十分ですよね？を考える
最低限の機能で十分な部分は手を抜く
いやこの話は1. 状況や要求の分析とコンセプト構築の領域に入っててややこしいからやめとくか？
バックエンドにデータがないとUIを作れない、でもUIを作らないとデータをどう保持するのが正解かわからない問題
答え
1回のプルリクで両方まとめてやれshokai.icon
ただし最小限のセットで
コードの量が多くなってきたからプルリクわけますとか、絶対やっちゃいけないshokai.icon
レビューで見るのは3つ
コンセプト
問題をちゃんと解決できてるか
設計
コンピューターサイエンス的な意味でおかしな事になってないか
負荷、処理速度、精度
実装の詳細
コードの細かいアレコレ
この方向性であってるか、改良したらいけそうか、を検証する
こうやる↓
もともと、page list filterを含めたもっと大きなdashboardを想定しているが、page list filter単独でリリースした
この機能単体で
大きな展望から分割した小問題を解決できている
大きな展望と方向性がズレていない
適度に機能の余白があるので、この上に積み上げれる感覚がある ユーザー名を入力するフォームのデザインはwindow.confirmでいい。とりあえず
ブラウザの機能だけでやって楽している
独自の入力modal作ってデザインを超かっこよくしても、「アイコンでフィルタしたらmentionや更新通知の代わりになる」というコンセプトがダメだったら無意味になる
最小限まで削って、「アイコンでページフィルタする事で、mentionや更新通知の代用になるかどうか」「現実的なDB負荷で表示できるか」を先に検証するべき
作業量や管轄領域が広がりすぎて手が回らなくなっちゃう
例えばpage list filterのページ名入力はwindow.confirmでとりあえずいい、みたいな判断
今回はそっちの話の比重が少ないので、また次回深堀りしたいshokai.icon
コンセプト分割して、最初のリリースが「単独でまあまあ便利な機能」まで削ると、おのずと重要ではないから手を抜いて良い部分もみえてくるのではないか？
最初の技術検証はCLIでやっていた
技術だけでなく、コンセプトも検証している
営業の商談ログから必要な情報を抜き出せて、便利だと感じれるかを検証している
CLIを使っていたら、イメージがさらに具体的に見えてきた
最初は「ページ書いたら右サイドバーに抜き出す」程度だったが
色々気付いた
従業員数・拠点数・売上数、などの項目を入力して、抜き出された結果を複数並べて流し見すると、じゃあ追加で「既存のAIチャットを導入しているか はい・いいえで答えて下さい」とか、項目を追加したくなる
項目を追加したらすぐ結果も反映されたら相当気持ちいいぞ、と
結果を正規化したくなるだろうな、等も気づいた
将来的に項目名に注釈を書いて拡張したくなる事は、この時点で気付いていた
だから、拡張の余地があるテーブル記法をInfobox定義方法に選んだ
「問題を解決できるか」だけでなく
もっとやれる事や便利にできる事、ユースケースなどを探るためのプロトタイプという面もある Infoboxそのものの最初のpull requestのコード量としては結構大きめ
これは必然的に大きくなってる
これが重要だった。絶対にこの時点で検証から外してはいけなかったshokai.icon
一括置換ができない穴があったらなるべくはやく知りたい
ChatGPT APIのrate limitとか
一括更新ができないとしたら、それをごまかすUIやbatchのしくみが必要で、そうすると表現もぜんぶ変わってくる
具体的には「保存ボタン」が必要になるはず
書いたら即座に抜き出されるではなくなる
この方向性のUI、保存ボタン押さなくて良い、ただ本文書くだけで抜き出される、で進めていけるか？を確認する最小セットがこのpull requestだった
だから、とりあえずテーブル表示はこの時点では必要なかった
balar.iconへの作業依頼を4段階に分けた
最初3段階だった。2段階目を使ってみて、さらに分割が必要だとおもったので計画修正したshokai.icon
matsumotius.iconへの作業依頼を、とりあえず最初の2段階まで書き出した
人にタスクを渡す時は、こうしてページ作ってプロセスを計画しているが
shokai.iconや、自分で作る時はページにしてない事が多い
頭の中で自然にできてしまっているから
具体例が必要だ
やってみた
例：ページの文字数・行数を表示する機能の場合、私ならこうやりますshokai.icon
第一段階
ページ編集するとpage.charsCountやpage.linesContを更新するcommit/change機能
Page info menuにそれを表示するUI
簡単に作れるからさっさとやる
なぜこうするか
DBを見なくてもbugの確認ができる
社内の、開発者ではない人たちでもバグや異変に気付ける。報告に参加してくれる
レビュアーが動作確認する時にDB見なくて済む
ふつうにページの文字数がわかる機能は単体で便利
入稿記事の文字数が正確じゃなくてもおおまかにわかるだけで便利
第二段階
ページリスト画面テーブル表示モードに、文字数や行数の列を追加
なぜこれがbatchより先か
リスト画面で文字数みれたらどういう気分になるのか早めに検証したい
気分があがる。文字数がついてるページとついてないページが混在してて気持ち悪い！となると、どうにかしたくなる
これは自分のエサを自分で作るモチベーションハック
ものによってはヤバイ。監査ログ等を歯抜けにすると、気持ち悪い通り越して不審なので、問い合わせ対応が多発すると思う
こういうのは先にbatchで綺麗にするべし
歯抜け・不完全状態でもまあ許される場合だけやってよい
第三段階
batchで全ページに文字数・行数を追加
練習：batchで文字数行数つけたら誰がうれしい？を考える
lastUpdateUserIdが歯抜けだと開発者がめんどくさい
実装がシンプルになって我々がうれしい
項目の有無を考慮しなくて良くなる
これはあるshokai.icon
古参のprivate projectユーザー
3年前のページ表示したら確実にクラッシュするとか
我々は文字数データがついてるページばかりの中で生活しているから、こういうbugに遭遇する率が低いshokai.icon
オンプレ版ユーザー
年1回ぐらいしかdocker imageを更新しないかもしれない
文字数データがついてないページがたくさんあるのに、テーブル表示で文字数の欄があって、中身が空でナニコレってなってる
と考えると、オンプレ版でも実行できるようなbatchにしておくといいねshokai.icon
ohnishiakira.iconには、練習としてページ作って段階的な実装の計画書を作ってみてほしいshokai.icon
こういう問題があって、こういう機能を作ってくれ、と言われたら
その中の機能の構成をリストし
第一段階、第二段階、…とプランをたてる
どれがどれより先にリリースされるべきか
どれとどれはセットでリリースするべきか
余談
尖らせた最小コンセプトと実装のセットは、サッとリリースしてだめなら引っ込めればいい。捨てる事を躊躇しなくなる
突然window.confirmが表示されてもズコーッってならないテイストのUIにしている。あえて。
今回の話は3. リリース直後のブラッシュアップに効いてくるやり方になっている。次は3を掘り下げるのもアリだな