おそらく世のSaaS開発を行っている会社の9割は、ドキュメンテーションツールとしてNotionを活用しているのではないかと思います。
すごく書きやすくていいですよね、Notion。
けど僕はもう正直開発で使うのが嫌になってしまいました。
そもそもNotionは「個人が私的なドキュメント管理をしやすくするツール」という位置付けで作られました。
なので、「チームで開発するときのドキュメント管理」は本来の目的とは外れている使い方なんですよね。
そのくせ、ただ文書を書いていくにはとても良い体験に仕上がっているのでものすごい量を好き勝手に書いちゃう。
結果、何が起こるかというと。。。
- ルールを決めても守られない
- どこに何があるかわからん
- 何が変更されたかわからん (履歴機能があるのと、現実的にそれでトレースが可能かに大きな乖離がある)
- どれが最新かわからん
- どれが本物かわからん
- なぜこれが書かれたのかわからん
- そもそもnotionに無い (slackにある -> ねーよ！ という不毛なやり取り...)
もう愚痴をあげたらキリがありません。
私は開発者です。文句があるなら作るべき。よきエンジニアは行動で示します。
私はディレクションに振り切って、実装は全部Claudeにやらせる方式で以下のプロダクトを作りました。
成果物 Strand
Strand には「撚り糸」という意味があります。
なぜこの意思決定をしたのか を糸のように途切れずに繋いでいく というイメージを持たせました。
後で紹介しますが、視点を変える機能を使うと縦横に関係が見えるところも、
「糸が絡み合う」感覚に少し重なっています。
Strand は「用途を絞る」ことで成立している
Strand は、
チームでのプロジェクトにおける意思決定の履歴を残し切る
という目的に特化しています。
これ以外の用途は、基本的に考えていません。
そのため、自由記述をできるだけ排しある程度書き方を強制するようなUI/システムを採用しています 。
具体的には下記のように 情報を 5 つのノードタイプに分け、必ずこの順番でつながるというルールにしました。
VALUE（価値仮説）
「そもそも何のためにこれをやるのか」という問い。ここを曖昧にしたまま進むと、後で「これって本当に必要だったんだっけ」という話になる。顧客は誰か、何を達成したいのか、成功をどう測るのか。最初に言語化しておく。
PROBLEM（問題理解）
問題の理解が浅いと、的外れな解決策を作ってしまう。何が事実で、何が仮説なのか。本当の課題は何か。制約は何か。ここを丁寧に掘り下げる。
DECISION（意思決定）
選択の記録。「何を選んだか」だけでなく、「何を選ばなかったか」「なぜ選ばなかったか」も残す。半年後に「なぜAではなくBにしたのか」と聞かれたとき、答えられるようにしておく。選択肢を並べ、それぞれの長所短所を記録し、最終的な判断理由を残す。
SPEC（仕様）
決定を実装可能な形に落とし込む。ユーザーストーリー、受け入れ条件、技術的な考慮事項。DECISIONで「何をやるか」が決まり、SPECで「どうやるか」を詰める。
LEARNING（学び）
実行した結果の振り返り。何が起きたか、何がうまくいったか、何がうまくいかなかったか、次にどうするか。この学びが次のVALUEやPROBLEMにフィードバックされることを想定している。
チームで使うこと意識した機能
チームで使うことを前提に設計しているため、下記のような機能の実装にこだわりました。
議論とエビデンス
各ノードにはコメントを残し、ファイルやリンクをエビデンスとして添付できる。ただし、これらはデフォルトでは折りたたまれていてファーストビューがうるさくならないようにしています。まずは最新の状態が見れる、というのが重要。
変更履歴
「何が」「いつ」「なぜ」変わったのかをdiffっぽく見れるようにしています。
これは地味に気に入ってる機能ですね。Notionはこれがパッとやれないのしんどい。
関係性を一目で見るためのビュー
Strand では node を自由に配置できるキャンバスを用意しました
（Miro にかなり影響を受けています）。
これは、「何がどこにあってどうつながっているか」を一発で理解できるようにしたかったからです。
このフリーモードではnodeは自由に配置できます。
また、同じnode群をタイムラインという概念(要は日付) で並べて見せるように切り替えることもできます。
nodeの位置操作としては、横軸は設定した日付で固定され、縦軸はユーザーが自由に動かせます。
これはうまく活用すると、どのタイミングで何の意思決定をして、いつ解決策が実行されたか (されるために何をしなければいけないか)がわかるようになっています。
notionとJIRAを行ったり来たりするのがつらすぎるという背景からこの機能は生まれました笑
また、もう一つ作ったのが集約キャンバスというもので、集約したい概念を入力するとそれに伴ってnodeが関連づけられたビューが作成されます。
これは当初「各nodeはインセプションデッキのどの概念に紐付いているか見れるといいな〜」という発想で作りました。
特に価値仮説が何に立脚しているのかは重要だよなという。
いざ実装してみたらそれ以外の集約にも使えたのは嬉しい誤算でした。(例えば、APIに属するものを横串で見たいとか)
ちなみに、このインセプションデッキのようなプロジェクトを代表する原則を、Strandの中では「プリンシパル」という概念に保存できるようにもなっており、AIはこの辺を加味して各nodeの提案をすることも可能です
いざ自分で使ってみて
デバッグも兼ねて、友達から「こういうの欲しい」と言われていたテーマに関するものを入力してみたんですが、まあ結構大変ですね笑
自分で言葉を捻り出して仮説に当てはめていくというのは相当頭を使います。
物事を考えるというのは本来こういう営みのはずなんだよなというのを改めて感じ、自分で考えた制約条件は狙った役割を果たしているなと安心しました。
(逆言うと、Notionはこれがないからちゃんと本筋が通ってない文章とかが量産される)
ただやっぱり面倒だったんで、AIにサポートしてもらう機能を後から実装しました笑
たたき台はAI、清書は自分でという流れにするとスピードも担保できそうなのでまあよかったかなと。
おわりに
正直これが本当に現場の役に立つのかは分かりませんし、このデータの並べ方とか構造をnotionで再現するだけでもかなり近いことは実現できるのかなと思います。
自分の学びとしては、まずこの書き方の流れになっているのが本来の意思決定のあり方だ、というのを自分の中でちゃんと形にできたこと。これは本当に大きいです。
各フェーズで「なぜ？」をとことん掘り下げ、どのような理由に立脚して具体を実行していくのか。
AIを使って高速にものづくりができるようになったからこそ、何を作るのかを正しく考えること、その上で作って壊してを高速に回していくこと、回して得た学びを適切にフィードバックしていくことが重要だなと思っています。
Strandがその一助になれば幸いです。
Appendix
今回の開発は自分で考えた「エクストリームチーミング」というコンセプトを前に進めるためのツールという位置付けで考えています。また、このツールに至るまでのぼやきもなんかも自blogに書きましたのでよかったら見てやってください。
https://blog-isnt-that.vercel.app/posts/12_extreme_teaming
https://blog-isnt-that.vercel.app/posts/13_reflect_next_issue
お読みいただきありがとうございました。
ご興味のある方、ぜひ一緒にお仕事できればと思いますのでお気軽にコンタクトいただけると嬉しいです。