Whyを言語化する
コストを筆頭に、設計は様々な要素とのトレードオフなので、なぜその選択が妥当だと判断したのか
機能は非エンジニアにも見えるから、Whyをわざわざ言語化しなくても話を通しやすいんだ。でも設計は本当に見えない。認知困難だから、whyを分かる形に言語化する能力がとんでもなく必要 どんなに良い設計や実装に見えても、動かすときや検証するときに「何が正しいか」がわからないとどうしようもない。
その資料があったとしても、whyが無いとその妥当性を判断することもできない。 知らないシステムのドキュメントはその機能の超細かい処理の動きよりも、理由(WHY)に関する情報がほしい。
極論、細かい動きはソースコード見ればわかる。
全体の中で機能がどの立ち位置を担っているのか
要件定義(提案書)と概要設計、基本設計があれば詳細設計は無くても大丈夫という感じ
機能は非エンジニアにも見えるから、Whyをわざわざ言語化しなくても話を通しやすいんだ。でも設計は本当に見えない。認知困難だから、whyを分かる形に言語化する能力がとんでもなく必要 どんなに良い設計や実装に見えても、動かすときや検証するときに「何が正しいか」がわからないとどうしようもない。
その資料があったとしても、whyが無いとその妥当性を判断することもできない。 知らないシステムのドキュメントはその機能の超細かい処理の動きよりも、理由(WHY)に関する情報がほしい。
極論、細かい動きはソースコード見ればわかる。
全体の中で機能がどの立ち位置を担っているのか
要件定義(提案書)と概要設計、基本設計があれば詳細設計は無くても大丈夫という感じ
月別アーカイブ