システム開発と「具体と抽象」

第1章 具体と抽象

抽象化とは、複数の具体例から共通点を抜き出して名前をつけること。逆に言えば、具体例が1つしかない段階で抽象化すると、だいたい外す。設計を早く固めたがる癖への戒めとして読んだ。

第2章 会話の粒度

話が噛み合わないとき、意見が違うのではなく抽象度が違うだけ、というケースが多い。片方は実装の話、片方は方針の話をしている。まず「今どの高さの話をしているか」を揃える。

第3章 開発の往復運動

要件と実装は往復する。実装してみて初めて要件の矛盾が見えることがあるので、往復を前提に計画する方が現実的。一方通行の工程表は、この往復を「手戻り」と呼んで責める。

第4章 目的へ戻る

議論が細部で止まったら、一つ上の目的へ戻る。「そもそも何のためだったか」を出すと、選択肢が増えるか、争点そのものが消える。魔法の質問というより、抽象度を上げる操作。

第5章 問題の型

違う見た目の問題が、同じ型をしていることがある。型で捉えられると、過去に解いた問題の解法を持ち込める。経験が効くというのは、たぶんこの型のストックのこと。

第6章 議論を引き上げる

具体に降りすぎた議論は、細部の正しさを競い合うだけで前に進まない。誰かが引き上げる役をやる必要がある。会議のファシリテーションは結局これをやっているのだと思う。

第7章 抽象から具体へ

抽象論で終わらせない。方針を決めたら、必ず1つ具体例に落として確かめる。落とせないなら、その方針はまだ言葉遊びの段階にある。

第8章 原則を試す

設計原則は覚えるものではなく、手元の実例で試すもの。読んで納得した原則ほど、自分のコードに当ててみると例外が見つかる。その例外こそ理解の入口。

第9章 チームの共通言語

チーム内で同じ言葉が違う粒度で使われていると、議事録は揃っているのに実装がズレる。用語の粒度を合わせる作業は、地味だが一番効く。

第10章 レビューの視点

レビューで見るべきは、コードの正しさだけではなく、抽象度が揃っているか。1つの関数の中で、業務の言葉とバイト列の話が混ざっていたら、それは読み手に往復を強いている。