経験の浅い人ほど全体を見通せぬまま判るところから記述しようとします。細かい記述を集めてみると、つながりが機能していないことがその時になって判ります。

まず、「要件」の整理が必要です。

VBAの勉強はしました。では、それを実践で生かすステージに上がるわけです。
勉強の結果をこれから示すわけですが、要求されている「何を仕組みにする」か、その範囲や機能内容がきちんと整理できていますか？
まず、これは大変重要なことです。ここにブレがあるとその「仕組み」が完成しても使い物にならない結果になる場合もあります。作成の指示を出している人だけでなく実際に利用する人の側に立って、 作成されたものがどのように利用されるのか、機能だけでなく利用具合や処理結果、運用サイクル、やり直し方法などまで考えて、危惧がある点はよく確認を取っておく必要があります。
作成要求の発令者の指示では細かい要件が漏れることが多く、また利用者自身では新たな仕組みとしての要望ではなく現状の不満解決の意見ばかりになりがちです。
一般にVBAなどで作成する仕組みは手軽さがあって細かいことの打ち合わせなどを省いてしまうことが多いですが、もし、そうなら作成後に追加・変更の要望があることを覚悟しなければなりません。

いきなりコードを書くことができるのは、よほど単純なものだけです。

では、「要件」の整理が終わったものとしましょう。次にどうしますか？ いきなりシートを作成したり、VBAのソースコードを書き始めますか？
いろいろリクエストを聞いていくと、例外条件などがどんどん出てきて複雑な要求になっていくことがよくあります。いままで学んだことですぐに作成できますか？ VBAだけを見ても簡単なマクロのレベルを超えて、数百、数千行のソースコードを書くような仕組みでも動作します。場合によってはこのようなレベルになってしまうかも知れませんが いきなりコードを書くような方法でこなす自信はありますか？ いつまでに完成させるというメドは立てられますか？
などと言って、別にVBAを使って「仕組み」を作ることに尻込みさせようと言うのではありません。自信を持って取り組んでもらうための基本となる考え方を確立してもらおうというのがこの章の趣旨です。

単純なもの以外は「設計」という手順が必要です。

モノを作る場合には、「製造」する前に「設計」という工程があります。「設計」というのはどのように実現するかの筋道を明確にする作業であって、これを行なわずして「製造」はあり得ません。 いきなりコードを書いて実現できるようなモノであっても、それは頭の中で「設計」というが行なわれているはずです。 ここの章では、これらの説明を「難しいこと」にしないために、この「設計」を単にコードの中の「プロシージャ」の切り分け方というような視点に限定してみます。 VBAの経験が少ない方は、いきなり数千行のコードを書くことはないかも知れませんが、機能要望が複雑かつ多岐に渡って、結果的に数千行のコードを書くようなことになるかも知れません。 この「機能要望が複雑かつ多岐に渡って」をVBAのコードにする手前で、どのようなプロシージャをどう組み合わせるかを導くことを「設計」の工程で行ないます。
この考え方が身につけば、より高度な要求があっても同じ手順で作成作業が進められるようになるはずです。

「設計」の手法はいろいろありますが．．．．

VBAはプログラム言語ですから、これを学んだ方はコードを書く前提に立って「設計」を行なおうとするものです。 この典型的(伝統的？)な設計手法に「フローチャート」というものがあります。「最初の何をして」「次に何をして」「続いて何の判断があってNGならAのポイントに戻る」などを図式化する手法です。 非常にソースコードを書くレベルに近い手法ですから、この設計書があれば容易にコードを書くことができると思います。
ですが、この方法は大きな「仕組み」には対応できません。「最初の何をして」などは、あくまで細かいことを頭に置いていないと進められない方法なので、大きな「仕組み」の設計には向きません。 では、どのように考えていけば仕組みの大小問わず作成段階でメドがつけられるような「設計」ができるのでしょう。

このページの見出しには「考え方は「大づかみ」から始めます。」と書いてあります。

このページでは考え方の方向の説明だけにして、次のページ以降に具体的な説明を少しずつ進めていきますが、「大づかみ」とは何でしょうか。 別の言い方だと「トップダウン」でも良いと思います。
「トップダウン」「ボトムアップ」などの言葉を、処理機能のプログラム開発に当てはめると、「ボトムアップ」の考え方(細かい部分を先に仕上げる方法)は、全体を見据えられないままで行なうべきではありません。その方法では、おそらく「見通し」が立たないでしょう。
ここで言う「見通し」とは、「いつになったらできる」「後どのくらい掛かる」のメドが立つのか、と言うことを指します。
もちろん、「部品」としてテストを完了させておき機能の確立したものを用意することは重要ですが、それを並べただけでは「製品」にはなりません。
ですから、設計の考え方を「トップダウン」にするべきなのです。