back to top

課題感がどこにあるか考えている

Cover Image for 課題感がどこにあるか考えている
Me
Me

最近割と時間があるので散発的に個人開発などをしていた。

https://parse-me.com/https://parse-me.com/

https://learn-pm.vercel.app/https://learn-pm.vercel.app/

https://inception-deck-online.pages.dev/https://inception-deck-online.pages.dev/

生成AIのおかげで簡単にUI作ってデプロイできるようになったのは本当にすごいしありがたい。
コーディングしているだけでは得られない学びがある。

そこで、次に何を作ろうかを考えていたのだけど、前回記事であれだけでかいことを言ったわけだから、それの実現に向けて何か貢献するツールを自分で作っていくべきだろうと思った。
が、なかなかうまく言語化できない。ぼんやりとイメージはあるのだが、ぼんやり過ぎて作り始めるのも難しい。

そもそもなぜツールを作ろうと思ったのか。それは既存のツールにあまりいい思いがないからである。
特に最近違和感を感じているのがnotion。

notionはめちゃくちゃ書きやすい。なんでもできる。であるが故に、みんな一枚の中にめちゃくちゃ書く。自由に書く。
結果、どこに何があるかわかりにくくなっていると思う。
もちろんチーム内に「何をどこに書くか」のルールはある。
だが結局みんながモチベ高くそれぞれの視座で書きまくってしまうので、わからなくなる。
そんな現場をいくつ見てきたことか。。。

notionはそもそも個人がドキュメンテーションすることを想定したツール。
なので、一人で自由に使う分には最高だし、スタティックなサイトとして公開もできて素晴らしいけど、チームの情報管理には向いてないと思う。

もう一つの犯人がJIRA。というか、スクラムかもしれない。
これらがあるとプロダクト開発ではなくタスク消化になってしまう。
俺たちが作ってるのはプロダクトなので、それを良くするために向き合うという精神が損なわれてしまう気がするんだよな。。。

やることは常に目の前にあるんだから、それを管理する手間があったらすぐ潰したらいいじゃん。というハードコア思想で生きています。

そんな感じのメモを共有しながらClaudeと会話したものを箇条書きにしたものが以下です。
これを眺めながらもうちょっと考えてみようと思う。
ついでに、積読しているアジャイルサムライを読みながら。

プロダクト開発の本質について

  • プロダクト開発の目的はタスク消化ではなく、価値を届けること・学ぶこと
  • 「今週何かを学んでいればそれでいい」という姿勢が大事
  • 作らなければわからないことを、検討で解決しようとして止まっている
  • 完璧な仕様を作ってから実装、ではなく作りながら学ぶべき
  • インクリメント(毎週何かを届ける)よりも、決めた方向に向かっている実感が重要
  • 作ったものを破壊してもいい、全く別のものを明日作ってもいい

スクラムの問題点

  • スクラムが日本の組織文化に合っていない(少なくとも多くの現場で)
  • スクラムの儀式を守ることが目的化している
  • リファインメントが進捗報告会になっている
  • 要件検討が別の場で散発的に起こり、開発チームが蚊帳の外
  • POとデザイナーの間で仕様が整理されないまま開発に流れてくる
  • 並列作業がサイロ化を生み、全体像が見えなくなる

道具(ツール)の問題

  • JIRAがタスク消化を加速させている
  • Notionは書きやすいが故に情報が散逸する
  • ルールを決めて守らせるアプローチはうまくいかない
  • 道具に合わせて自分たちを変えてしまっている
  • 本当にやるべきは「プロダクトを作るための道作りと意思決定」なのに、道具がそれをサポートしていない

情報・コミュニケーションの問題

  • 会話が消えていく
  • 情報の繋がりが見えにくい(仕様の経緯を遡れない)
  • 「自分自身の感覚に基づく整理」はされても「誰が見ても整理された状態」にならない
  • 情報量が多すぎて頭に入ってこない

デザイン・仕様の問題

  • デザイン先行だと工数が取れず進まない、仕様の見逃しも発生
  • デザインがないと構想が進みにくい
  • 両者をうまく行き来することが重要(UIの前に情報設計をすべき)

解決の方向性

  • XPのプラクティスを状況に合わせて柔軟に取り入れる
  • モブプロ・シングルタスクで会話を生み、チーム全体で共有
  • 自分たちのために道具を使う、必要なら自分で作る
  • 「誰が見ても整理された状態」を強制するツールが必要

理想的なツールのコンセプト

基本コンセプト

  • 「プロダクト開発という仕事のやり方自体を規定するツール」で、その制約の中で仕事を進めることで、副産物として綺麗に整理された意思決定の履歴が残る
  • タスク管理でもドキュメント管理でもなく、思考と対話と意思決定の流れを記録・可視化するもの

具体的な機能イメージ

1. 会話駆動の仕様構築

  • 「何を作るか」より「なぜ作るか」「何を学びたいか」を中心に記録
  • 議論のスレッドと意思決定がセットで残る(Slackみたいに会話が流れない)
  • 「この仕様、どういう経緯で決まったんだっけ?」が一発で辿れる

2. 学びと仮説のトラッキング

  • 「今週の学び」を記録する仕組み
  • 「作って捨てた」ことも価値として記録される
  • 仮説→検証→学び のサイクルが可視化される

3. 強制的なシンプルさ

  • 書ける情報量に制限がある(長文を書かせない)
  • 「誰が見ても整理された状態」を構造的に強制
  • 必要最小限の情報だけが残るような設計

4. 文脈の自動的な繋がり

  • 情報同士が自動的に繋がる(手動でリンク貼らなくていい)
  • 時系列だけでなく、トピックや決定事項でも辿れる
  • 「今、何のためにこれをやってるのか」が常に見える

5. モブワークとの統合

  • リアルタイムでチーム全員が同じものを見ている前提
  • 個人のメモではなく、チームの共有思考の場
  • デザイナー、PO、エンジニアが同じ場所で対話できる

6. プロトタイピングとの連携

  • 「作りながら考える」を前提に、作ったもの(スクショ、コード、デザイン)と議論が紐づく
  • デザインと仕様を行き来しやすい構造

追記:
書いた後で思ったこと

  • スクラムは、もともとアジャイルなマインドを持ったメンバーが集まることで効果を発揮するFW

  • あるいは、スクラムを実行することで人がアジャイルになっていくことを想定しているのかもしれんが、実際にはそうならないケースが多いよなと (初期のスクラムガイドで「理解は簡単、実行は困難」と言われていたのはこの辺が理由？)

  • これは色々要因はあれど、どこか日本人気質にあってないということなんじゃないかなと（要言語化

  • 逆に海外の人は元々「仕事はチームで助け合う」というマインドセットができてるのでスクラムが容易にハマるのかもしれない

  • 「一人でやりたがるくせに合意は取りたい」っていう日本人マインドがよくないのかなあ

  • エクストリームチーミングはそもそも一人で仕事をさせないことでこの問題を解決したいと思っている (+続けることでアジャイルマインドを育てる)

  • notionの問題点として、人間が一度に認知できる限界を超えた文章量を、容易に一枚に書けてしまうという問題がある

  • そして、それを元に会議を設定するから毎回発散する笑

  • 人間が理解できる文章量に噛み砕いて書ける、それをコンテキストを持って整理するというのが要点ぽい

  • 実例としては会議のエグゼクティブサマリーは大変コンパクト。扱う事例の規模を考えたら、比例して文章量は増えなければならないが、そういうことはしないはず。なぜか？ その資料を見る経営者は、書かれていることの背景を想像することができるから。具体->抽象->別の具体 という想像力を使って理解しているから文字は少なくてもいい

  • もう一つ、そこにある文章を信頼して見ている。信頼できないと過剰にエビデンスを要求することになって文章量が増える

  • 書いてて思ったけどプログラミングに似てるな。契約的にプログラムができていれば、要素は分解されそれぞれのSpecは少なくて良い