ボトムアップな設計ではだめなのか

清水吉男さんのもっとも素晴らしいところは、スペックアウトという言葉を生み出し、ボトムアップで設計を良くしていくことを肯定したところではないかと思う。リファクタリングという言葉もそうだが、今までの経験を活かしてトップダウンで設計を進めるとともに、ボトムアップで設計を進化させる・適応させる行為ももっと肯定されていくべきではないか。

「入門＋実践」要求を仕様化する技術・表現する技術改訂第2版 仕様が書けていますか？ [ 清水吉男 ] 価格：2786円（税込、送料無料) (2018/12/22時点)

個人的には第一版の方を持っているので、こちらの表紙のほうが思い入れがある。
(^-^)

USDMにそって仕様を書くと、How(実装) What(仕様) Why(要求) が関連付けて近くにきちんと書いてあるのはいいけど、仕様を全体的に読み解くのは結構しんどかったり、トレーサビリティマトリクス的にコードと対応させるのも難しくて、なんでこの本がそれほど評価されているのだろうかと思う。でもこの本の中で言われている通り、スペックアウトで実装を仕様に、仕様を要求に昇華させることで、設計、実装を改善することができるのではないか。
実装・仕様をうまく昇華できないままの なんちゃってスペックアウト では、ボトムアップで設計を改善するには至らず、ボトムキープのまま迷走しているのが悪いんじゃないかな。そういう点ではリファクタリングも闇雲にパターンを適用したり、コードをいじくり回して時間を浪費するだけなのは良くなくて、上位概念に昇華させて適用する必要があるんだろう。

---

Agileなプラクティス、XP のオンサイト顧客やモブプログラミングで暗黙知が暗黙知のまま共有しやすくなった。 Git のプルリクエストにWhat/Why(仕様/要求)を書くことで How(実装)と結びつけやすくなった。 チャットが普及し、単発的な事実を並べているうちにそれを昇華させて 文脈を読み取ることで、演繹的に説明する力がなくても帰納的に文脈を理解することが可能になった。

コミュニケーションのスピードとしてはこれらのほうが効率がいいんだろうけど、これらだけに頼りすぎると風化して忘れ去られるのが早かったり、体系的に伝えられず効率が悪いこともある。演繹的に伝える方法も学ばなければならない。

「派生開発」を成功させるプロセス改善の技術と極意 [ 清水吉男 ] 価格：2786円（税込、送料無料) (2018/12/28時点)

小さなスタートアップから始めて派生開発で育てていくのがセオリーになりつつある時代。影響範囲を考慮しながら仕様の統廃合を進めていく。そのためにはスペックアウト、リファクタリングのスキルが重要になっていくだろう。

サイエンスとしての公式・パターンが見つけられる前に、AIがデータサイエンスとして、公式・パターンが不明確なままの演繹的な予測も得られるようになっているから、どんな技術が重要になっていくかはよくわからないけど。