[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

233users がブックマーク コメント 24

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

網羅的なPRDやDesign Docを書かなくなった - kosui

233 users kosui.me

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページ

記事へのコメント24

  • 注目コメント
  • 新着コメント
rryu
議論のためにフルスペックのPRDやDesign Docを書くのは重すぎるというのはそれはそう。これらは将来に読み返すためのフォーマットだと思う。

その他
tendanku
文章だけでやりたいことが全て伝わると思うのは幻想(戒め)形式が決まってる学術論文ですら発表し質疑応答もする

その他
als_uz
わかりみ。書くときクソめんどくさいんだけど残ってると「そういえばそうだった」となるので残っているのはいいけど、「忘れるなら最初から書こう」だし「忘れない自信があるなら確定したことを残そう」な気がする

その他
versatile
むずい。ドキュメント書きたくない。ないと何が何だかになる、人に説明できない、むずい

その他
atsushifx
アジャイルでのドキュメント不要と一緒かな。大事なのは、チームが認識を共有することであってドキュメントはその補助に過ぎない。だからこそ、議論の結果をドキュメントとして残す価値はある

その他
mohri
「たくさんドキュメントを書いてレビューしても関係者間でコンテキストを共有し問題発見へ結びつけることはできない。いずれにしても、私はビルドトラップにハマっていた」考えさせられる

その他
lizy
フローをストックにするのが面倒なので、その手間を減らすかフローをフローのまま扱える方法が欲しいところ

その他
sora_h
考古学のために文章に残しておくのに価値がある。会話は Design Doc 上のレビューコメントでやればいい。形式的な文章に拘りすぎなのでは...。雑でも後からフロー情報読むよりマシだよ

その他
Sixeight
コミュニケーションのためのツールだと思って使ってる

その他
habarhaba
同意なんだけど、これはドキュメントをしっかり書ける人だからこそ力を抜ける所がある、という話なんだよな...そうでない人が形だけ真似すると、ただのよくある無法地帯になるというオチ

その他
sora_h
sora_h 考古学のために文章に残しておくのに価値がある。会話は Design Doc 上のレビューコメントでやればいい。形式的な文章に拘りすぎなのでは...。雑でも後からフロー情報読むよりマシだよ

2024年06月13日 リンク

その他
hachibeechan
わかる、人間と向き合うとこういう結論になる......人間は人間なので......

その他
sbrtnpg
"アーキテクチャに関する意思決定についてはADR(Architecture decision record) が有用だ"

その他
mom0tomo
対話しながらのドキュメント作成大事。確かにDesign Docは重いフォーマットかも

その他
migrs
網羅的なドキュメントよりも、重要な観点に絞って早期に対話し、意思決定やその背景がまとめられたドキュメントの方が有用

その他
nabinno
LLMつかえば解決では?

その他
rgfx
対話しながらのドキュメント作成はコンテクストを強く意識したものができあがるので網羅的でないものの良いものができあがるのでは、という。

その他
kei3229

その他
Sixeight
Sixeight コミュニケーションのためのツールだと思って使ってる

2024年06月12日 リンク

その他
s-nanagi
意思決定のためには対話と議論を重視し、ドキュメントを用いるにしても議論に適したフォーマットを選べということね。PRDやDesign Docについては用途的にミスマッチだっただけで、それらが全く不要という話ではなさそう

その他
wata88
対話せよという話に尽きる

その他
lizy
lizy フローをストックにするのが面倒なので、その手間を減らすかフローをフローのまま扱える方法が欲しいところ

2024年06月12日 リンク

その他
atsushifx
atsushifx アジャイルでのドキュメント不要と一緒かな。大事なのは、チームが認識を共有することであってドキュメントはその補助に過ぎない。だからこそ、議論の結果をドキュメントとして残す価値はある

2024年06月12日 リンク

その他
dot
メンテできないドキュメントは悪なので、メンテにさけるリソースの範囲でドキュメントを残すしかない。ドキュメントは勝手に生まれてこないし勝手に改訂されないので、必要ならちゃんとリソースを確保すべき。

その他
yhara
"対話的な議論にフォーカスする"

その他
peketamin
"そして、対話的な議論を重ねた結果として、意思決定やその背景がドキュメントへ記録されるのだ。"

その他
tendanku
tendanku 文章だけでやりたいことが全て伝わると思うのは幻想(戒め)形式が決まってる学術論文ですら発表し質疑応答もする

2024年06月12日 リンク

その他
rryu
rryu 議論のためにフルスペックのPRDやDesign Docを書くのは重すぎるというのはそれはそう。これらは将来に読み返すためのフォーマットだと思う。

2024年06月12日 リンク

その他
honeybe
分割統治を原則とするなら全体俯瞰する短めの資料と個々の資料で分けた方が良いし、個々の資料は関係者と同期的に会話しながら作成していくのがよい。ので結論同意です(何

その他
for-my-internet-demo
だんだん開発チケットの設計タスクがツール移っただけみたいになってきた笑 整備せな

その他
versatile
versatile むずい。ドキュメント書きたくない。ないと何が何だかになる、人に説明できない、むずい

2024年06月12日 リンク

その他
mohri
mohri 「たくさんドキュメントを書いてレビューしても関係者間でコンテキストを共有し問題発見へ結びつけることはできない。いずれにしても、私はビルドトラップにハマっていた」考えさせられる

2024年06月12日 リンク

その他
als_uz
als_uz わかりみ。書くときクソめんどくさいんだけど残ってると「そういえばそうだった」となるので残っているのはいいけど、「忘れるなら最初から書こう」だし「忘れない自信があるなら確定したことを残そう」な気がする

2024年06月12日 リンク

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「網羅的なPRDやDesi...」が注目されています。

気持ちをシェアしよう

ツイートする

網羅的なPRDやDesign Docを書かなくなった - kosui

2024年06月12日 16:16 結論を追記 2024年06月12日 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを... 2024年06月12日 16:16 結論を追記 2024年06月12日 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024年06月13日 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー

ブックマークしたユーザー

  • habarhaba2025年02月21日 habarhaba
  • ikosin2025年02月07日 ikosin
  • Tomato-3602025年01月19日 Tomato-360
  • SHA-3202024年07月16日 SHA-320
  • techtech05212024年07月04日 techtech0521
  • mapk0y2024年06月30日 mapk0y
  • k1take2024年06月29日 k1take
  • miguchi2024年06月19日 miguchi
  • wonder-wall2024年06月16日 wonder-wall
  • inoyy2024年06月15日 inoyy
  • dhesusan46492024年06月15日 dhesusan4649
  • tjnet5552024年06月15日 tjnet555
  • uzuki052024年06月14日 uzuki05
  • akishin9992024年06月14日 akishin999
  • yug12242024年06月14日 yug1224
  • sora_h2024年06月13日 sora_h
  • hachibeechan2024年06月13日 hachibeechan
  • sinnra02024年06月13日 sinnra0
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /