記事へのコメント24

    • 注目コメント
    • 新着コメント
    ken1028-kufc
    ken1028-kufc システム開発でコア人材(1番中心の自在になるには?)

    2020/09/24 リンク

    その他
    teruyastar
    teruyastar 「元々何をやりたくて」「なぜこの方法を選んだのか?」という設計書残していくの大事。

    2020/08/28 リンク

    その他
    naglfar
    naglfar 今までに「なぜ」を書いてるドキュメント、ほとんど見た覚えない。意識的に残していきたい。

    2020/08/03 リンク

    その他
    strow0343
    strow0343 要求からコードまでのトレーサビリティを担保して欲しいけど、メンテのコストがね

    2020/07/30 リンク

    その他
    htnmiki
    htnmiki 運用マニュアルがちゃんと作られるの稀なのでもう設計書にエラー発生時のアクションやリカバリ方法を書いといてほしいという自分では何もしないユーザー側のひとりごと

    2020/07/30 リンク

    その他
    akabekobeko
    akabekobeko 私は仕様に関係する Redmine チケットや GitHub Issues のリンクを掲載している。合意形成の過程を知るのに便利。改めて議論するための踏み台にもなる。

    2020/07/30 リンク

    その他
    hatest
    hatest 要求(やりたいこと)のヒアリング時に文書にして顧客と合意しないまま進めて最後にもとからひっくり返されるPJをよく見る

    2020/07/30 リンク

    その他
    aox
    aox 番付表ですね

    2020/07/30 リンク

    その他
    ku__ra__ge
    ku__ra__ge Joel on Software - やさしい機能仕様 https://web.archive.org/web/20070216023409/http://japanese.joelonsoftware.com/Articles/PainlessFunctionalSpecifi-2.html

    2020/07/30 リンク

    その他
    SundayIsEveryday
    SundayIsEveryday 以前の職場では、設計検討書(機能の実現方法のしぼりこみ過程が書かれたもの)と設計書(しぼりこんだ結果が書かれたもの)がわかれていて、設計書から検討書へと辿れるようになっていたので、非常によかった

    2020/07/30 リンク

    その他
    jaguarsan
    jaguarsan 開発に使う設計書と保守に使う設計書を分けるべきなんじゃないかと最近考えてる。前者は使い捨て、後者は自動生成

    2020/07/30 リンク

    その他
    Tomato-360
    Tomato-360 参考になる

    2020/07/30 リンク

    その他
    tumo300-500
    tumo300-500 設計書って名前がプライマリなのが悪いのではとふと。企画書の方がしっくりきそう

    2020/07/30 リンク

    その他
    kyuuuuuji
    kyuuuuuji 「どうなっているのか」は最悪コード読めばわかるから「なぜこうしたのか」を知れると大変助かる

    2020/07/30 リンク

    その他
    reannkara
    reannkara 意思決定の過程は残しておくと後々メンテする人にとってはありがたい。

    2020/07/30 リンク

    その他
    iselegant
    iselegant よく結論や決まったことしか書いてなくて、結局なんで当時はその方式にしたのか?が書かれてないと妥当性を説明できないですよね。

    2020/07/30 リンク

    その他
    golden_eggg
    golden_eggg Whyの言語化大事

    2020/07/30 リンク

    その他
    su_zu_ki_1010
    su_zu_ki_1010 この手ので言いたいことはただ一つ。サンプルを提示してくれ。

    2020/07/30 リンク

    その他
    jacoby
    jacoby Whyは自然言語で書いてないとねぇ

    2020/07/30 リンク

    その他
    kei_0000
    kei_0000 自分なりのまとめ 1.要求(やりたいこと) 2.要件(やると決まったこと) 3.方式(実装方法の概要・方針) 4.詳細設計(実装方法の詳細)

    2020/07/30 リンク

    その他
    hogeaegxa
    hogeaegxa 何してるのかはコードが設計書だが、そもそも何がしたいのか?何故したいのか?はコードには情報が残らない。保守とかで設計書みようとするときはまずこのへんを求めてるし、そのへんあるとうれしいね

    2020/07/30 リンク

    その他
    jssei
    jssei 本来的な設計。現実としては、手段の洗い出しから選定のあたりの部分が結論ありきで取ってつけたような形になってることが多い印象。

    2020/07/30 リンク

    その他
    Wacky
    Wacky “2.要件はまあまあ書かれるのだが、それに対して 1.要求は「ちゃんとした設計書」ですら書かれていないことがあり、やはり「なんでこの要件になったんだっけ?」が発生しがちになる。”

    2020/07/29 リンク

    その他
    donchan23
    donchan23 要求も要件も方式も詳細設計も中途半端にしかないシステムの保守してるけど、機能拡張で設計書書けと言われて元の設計がわかりませんって言うとめちゃくちゃ怒られるの不条理すぎる、、、

    2020/07/29 リンク

    その他

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

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

    関連記事

    設計書には何を書くべきなのか - terurouメモ

    設計とは、 要求(やりたいこと)をヒアリングする 要求を要件(何を満たさないといけないのか)に落と...

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

    • mogmogpasty2024/04/30 mogmogpasty
    • techtech05212023/05/10 techtech0521
    • shigo4052022/06/30 shigo405
    • thotentry_hatebu1972020/12/12 thotentry_hatebu197
    • ken1028-kufc2020/09/24 ken1028-kufc
    • Kenji_s2020/09/14 Kenji_s
    • teruyastar2020/08/28 teruyastar
    • masarky2142020/08/27 masarky214
    • teriyaki32020/08/26 teriyaki3
    • RIKOTEKI2020/08/03 RIKOTEKI
    • naglfar2020/08/03 naglfar
    • sanko04082020/08/02 sanko0408
    • s_ryuuki2020/08/02 s_ryuuki
    • yoh5962020/08/02 yoh596
    • kabukisan2020/07/31 kabukisan
    • sskoji2020/07/31 sskoji
    • ayaniimi2132020/07/30 ayaniimi213
    • blackwatcher2020/07/30 blackwatcher
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

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

    いま人気の記事

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

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

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

    新着記事 - テクノロジー

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

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