データの構造とデータを扱うプログラムの構造ほ互いに深く関わっている。もし、正しいデータ構造を選択すれば、アルゴリズム（とそのコード）は容易に書け、容易に読め、したがって容易に保守することができる。アルゴリズムまたはデータ構造に関する本をどれでもいいから読むべきだ（しかし、１冊読めば後は同じだ）。
プログラムを書く準備として、アルゴリズムとデータ構造を一緒に考えるべきだ。最良のものを選択する前に、２組、または３組、またはそれ以上の異なる組を試してみよ。そして、データ構造を一つのコンポーネントにカプセル化する（原理６５）ことを忘れるな。そうしてあれば、後でもっと良いデータ構造を見つけたときは、それを容易に取り替えることができる。
（２０１の鉄則：原理９３＜コーディングの原理＝最適なデータ構造を使え＞）
この原理は「コーディングの原理」の中に入っていますが、「設計の原理」に含める方が適切かと思われます。
コンサルティングの仕事をしていて、気になることがあります。それは、「設計」が為されなくなっていることです。言語が“ビジュアル化”してきたことも背景にあるのでしょうが、とにかく、思いつくままプログラムを書いている姿を眼にすることが多くなりました。
原因は、「設計する」という行為が、実は何をすることを意味しているのかを理解していないことにあると思われます。「設計」という言葉は知っているのですが、正しい「設計の概念」を持っていないようです。そのために、適切な「設計行動」がとれないのでしょう。
「プログラムはデータ構造で決まる」ということを理解している人はどれほど居るでしょうか。初めに処理があって、次にデータがあるのではなく、初めにデータ（構造）があって、そのデータの変化（遷移）やサービスを実現するために処理があるのです。これは、構造化手法であろうとオブジェクト指向であろうと同じです。構造化分析で「ＤＦＤ」というダイアグラムを書きますが、これは「データフロー・ダイアグラム」というように、データを先に決めることを要求します。このように「設計する」という行為は、そこで実現が求められている仕様を実現するために最適のデータ構造を考えることでもあるのです。
私が勧めるタスクやモジュールの設計書は、そこで扱うデータの構造の記述を前に持ってきます。それによって、自然に処理や処理構造が決まってくるのです。
たとえば、３つのテーブルで実現したほうがよいか、それよりも全面的に単一方向のリスト構造で対応した方が、処理は簡単になるといったように、データ構造を絡めて幾つかの実現方法を考えるのです。もちろん、機能的要求だけでなく、そこでは保守性が要求されているのなら、どちらが将来に予想される変更に強いかということも判断の材料になります。
コンピュータの世界でのアルゴリズムも、データ構造に依存しています。データベース・システムも、もちろんデータ構造に大きく依存しています。
残念ながら、組み込みシステムの世界では、事前にデータ構造とアルゴリズムについての学習が不足しているように思えます。組織によっては、ハードの技術者がソフト部門に転向していることもあって、どうしてもデータ構造の学習が手薄になってしまっているようです。ところが、情報処理を専攻してきた人でも、意外とまともに習得していないことがあってがっかりさせられることもあります。
たぶん、現実的な状況設定なしに「データ構造」を教えられたものと思われます。この手の適切な文献には、必ずと言ってよいほど練習問題が付いています。これらの問題にきちんと取組んでいれば、設計するということは、データ構造を検討することであるということも、容易に理解できたものと思われますが、実際の授業ではどうなっているのでしょう。
既に、ソフト開発の仕事に就いている人で、データ構造の知識に不安がある人は、直ぐにでも、しっかりした文献を探し求めて勉強してください。そこで選ばれたデータ構造によっては、要求を満たすための処理が複雑になったりして、それだけバグが入り込みやすくなります。
この仕事に就くには、少なくとも必要最小限のデータ構造の知識は身に付けておいて欲しいものですが、かって“技術者不足”を言い訳にして、プログラムさえ書ければ良いとばかりにハードルを下げてしまったことが、データ構造も学習していない人を大量に参加させる結果になってしまったと考えています。
そして今、プログラム言語の“ビジュアル化”が、再び「処理優先」の風潮を広げ、データ構造の重要性が忘れられる傾向を助長するように思えてなりません。画面の配置やクラスのパターンを選ぶだけで、プログラムのスケルトンが作られ、あとは、そこに示される指示に従って「処理」を書き加えていくことで、ある程度のプログラムが出来てしまいます。ただし、品質的要求も含めて、機能的要求がきちんと「設計」によって織り込まれるかどうか怪しい限りです。そうして出来上がってきたものが、要求を満たしきっていないとき、果たして、どう手直しすれば漏れている要求を適切に実現できるか考えることができるかどうか。
結局、「出来上がったところが仕様」として使うことになるかもしれません。当然、そのシステムを使っての生産性は低下するでしょう。９０年代に入って、アメリカはＩＴ技術の展開によって、大幅な生産性の向上を実現しているのに対して、我が国では、殆ど生産性は向上していません。職場へのコンピュータの普及は、決してアメリカに劣っているとは思えません。
Web 関連のシステムも、実際には設計という行為が十分に行われることなく、便利なツールを使って、ホームページの展開を含めたシステムが作られてしまいます。確かに、それらは「現状」の要求はある程度満たしているかもしれませんが、将来に発生するであろう要求に対応できるように「設計」されたかどうか。もしかすると、その時も、今回と同じように、簡単に作り替えてしまうのでしょうか。