今年４月からソフトウェアエンジニアとして働き始めたものです。 くまぎさんの会社ではソフトウェア開発でコード以外にはどういったものをアウトプットしていますか？ 配属された部署では設計/テスト関連では基本設計書、詳細設計書、単体試験項目書、結合試験項目書などなどをエクセル等でガチガチに作成しており非常に驚きました。 学生時代はそこまでしっかりとしたドキュメントを作成して開発したことはなく、どういったものが普通なのか、効率的なのか気になった次第です。 | mond

外部公開されてるSaaSのAPI定義書でさえ、書かれてない仕様があるもんな。 APIでは設定できないがAPI定義項目から、自動で算出される値とか、nullの時の挙動とか。 資料づくり難しい。

さすがkumagiさん! いい本を推薦されますね。

どんなドキュメントかどうかより、「誰が何のために読むことを想定したものか」が明確になってるほうが重要。そういう決まりだから、以上の理由がないなら書かないほうがマシ、と思う。

ちょっとしたツールなんかを展開してみて、ドキュメント無しでどこまでやれるかチャレンジしてみるといい。コードは想像以上に人の手を渡り魔改造される

必要なのは entity の集約（Aggregation root）同士の関連図で、集約さえわかれば要素や時間的存在はそこから引っ張ってこれる。のだが私以外に Aggregation を重視する人を見たことがない。DDD論者？あいつらVOの話しかしないだろ

「アホでも理解可能度」をどれだけ突き詰めるか、だな。デカいプロジェクトほどこの水準は低くなりアホみたいなドキュメントを書く羽目になる。そしてVibeコーディングで全人類が逃れられなくなった

普通、といわれるとな。。SIerでも全然違うので何とも。おそらく正しいものも効率的なものもないと思う。大規模システム開発ではガチガチに作成せざる得ず、それを延々と繰り返して今になってる。歴史の積み重ね

エクセル地獄にゃんて、ボクには無理だにゃ！モフモフ癒やしで解決にゃ！

インタフェースとかはないと連携出来んからな。何がいるの、と、何を出すの、は最低限。基本設計書は、他の設計書へのリンクとか概略図が載ってる認識。