【送料無料】構造デザイン講義

内藤廣「構造デザイン講義」

王国社

2008年刊


 橋の美しさ・・について知りたくて手に取った一冊



 2006年から2008年までの3年間、東大土木学科で行われた講義録。


 構造は、物理的な仕組み・メカニズム
 デザインは、人間の思考や感情がもたらすモノ
 この各々独立したものを結びつけて考える「構造デザイン」論


 何かを「美しい」と思ったら、
 そのまま流してしまわずに、なぜ「美しい」と思ったのか、を考えてみることは、
 テクノロジーのブレイクスル―のヒントになる。
  
 建築や都市デザインの世界では、
 「機能的なものは美しい」
 「合理的なものは美しい」
 「経済的なものは美しい」
 ということになっている。

≪まず「美しさを発見」し、その「美しさに感動」し、
 その中に構造を発見する。

 さらに、その中に構造的な仕組みを発見し、
 最終的にそれを力学的な世界で再構築する、

 ということを目指してください。≫


≪ガウディ曰く「オリジナリティとはオリジンに帰ることだ」≫
 
 起源に帰ること、自然に帰ること、その法則を見出すことがオリジナリティである。




なぜWTCは崩壊したのか?

≪完成度の高いものは、部分的な破壊が全体に決定的なダメージを与える≫

突き詰めて考えられたものは、「リダンダンシー」が低いから。



≪その時代の最先端の技術を駆使した構築物というのは、
 その時代の最上の文化を組み込んでつくられるべきです。≫
 
 技術はそれだけでは短い間に優位性はなくなるが、
 技術と文化の融合の成果物は、未来に残る。


アークテクチュアとは?

 アークテクチュアは、ギリシャ語ではアルヒ・テクネー、
 アーチのテクノロジーのこと。
 アーチを形づくる知恵の意から転じて、
 何かを「構築しようとしたときに働く人間の意志と枠組み」を指す。





本当のエンジニアとは何か?

≪後々構造体に禍根を残すと判断した場合は、
 中止する勇気と決断が必要です。

 その人の経験と見識でその現場を止められるかどうかです。

 それが本当の意味でのエンジニアだとわたしは思っています。≫

・・たかだか20~30名のチームでも、中断を指示するのはためらわれます(>_<)

 
≪コンピューターの目覚ましい進化は、確かに多くの可能性を開いてくれますが、
 それがモノができるというのは幻想です。

 コンピューターは、構造の力学的なアウトラインを描くことはできますが、
 モノの成り立ちに関しては、極めて具体的なモノ作りの現場の経験値でしか
 フォローアップできません。≫
 
 エンジニアリングに関する工学知だけでなく、
 経験知・体験知などの身体的な感覚から得られる「知」も必要となる。

 「工学知・経験知・体験知」に裏打ちされた人間力がないと、
 現場の人たちは言うことを聞いてくれない。





<目次>
1章 総論
2章 組積造
3章 スティール
4章 コンクリート
5章 プレキャストコンクリート
6章 木造
7章 構造デザインの最前線

スポンサーサイト

【送料無料】デザインのためのデザイン

フレデリック・ブルックス『デザインのためのデザイン』

訳 松田晃一、小沼千絵

ピアソン桐原

2010年刊


 本書の特徴的なところは、後半3分の1は、デザインの実践例になっています。
 ブルックスさん自身が実際にデザインした別荘や自宅の
事例やIBMのシステム360や本の執筆におけるプロセスの事例が紹介されています。
 特に、デザインから得られた教訓が、とても興味深いものになっています。

 
 ビーチハウスのデザインでの教訓・・

 ユーザーやマネージャの立場で、
 
≪1.プロの建築家のデザインでも、細心の注意を払って確認し、その根拠を尋ねること。
 正直で、有能で、誠実な建築家であっても、間違いを犯すことはある。

 2.工事中に、頻繁かつ徹底的に点検すること。
 正直で、有能で、誠実な施工業者であっても、間違いを犯すことはある。

 3.メンテナンスのあらゆる側面についてじっくり考えること。
 うまくいった設計デザインは、長期間メンテナンスすることになる。≫



 IBMのシステム360のデザインでの教訓・・

≪1.デザインには十分なプロジェクトの時間を割くこと。
 それにより製品は遥かに優れた、長い間役に立つものとなり、作り直しの作業が減る
 ことで、より速く出荷することさえ可能になるだろう。≫


 IBMのOS360のデザインでの教訓・・

≪システムアーキテクトに、デザインに関する全権を与えること。≫

≪どれほどスケジュールの圧力があろうとも、デザインとプロトタイピングを
 十分に行えるだけの時間を取ること。
 そのように投資した時間によって、プロジェクトは遅れるどころか、
 早く完成するだろう。≫




【送料無料】デザインのためのデザイン

フレデリック・ブルックス『デザインのためのデザイン』

訳 松田晃一、小沼千絵

ピアソン桐原

2010年刊




≪「あらゆる可能な要求仕様をプロジェクトの開始時に明確にしようとする試みは、
  どのようなものであっても失敗し、かなりの遅れを引き起こすことになる」(Pahl and Beitz)≫
 


 デザインプロセスを、系統的かつ段階的に行われるプロセスとしてモデル化されるべきものであるとする考え方は、
 ドイツの機械工学界で最初に発展した。
 デザインプロセスを系統化するという取り組みは、いきなりコーディングすることに
 比べれば、格段の進歩ではある。

 でも、デザインプロセスの定義は、漠然と思っているよりはるかに難しい。

 デザインプロセスにおける「決定木」にしたがって、デザインを粛々と進めていけば
 よいのだろうが、そもそも「決定木」が事前に決まらない。
 デザインを進める過程で、「決定木」が決まってくる。


≪高度な技術分野のデザインでは、その領域の基本的な決定木を描けるほどの
 十分な知識を持ったデザイナはほとんどいない。≫
 

 なぜなら、

 ≪デザインの最も困難な部分は、何をデザインするか決めることにある≫し、

 だからこそ、

 ≪デザイナが提供する主なサービスは、顧客が何をデザインしてほしいのかを
  見つけ出す手助けをすることにある≫


 要件とその重みづけは、デザインのプロセスを通じて変更し続ける。

≪要するに、トレードオフをじっくり考えていくと、複雑に絡み合って相互作用する
 要因として、デザインの問題全体が新しく理解されてくるのである。
 同時に、要件の重みづけも変わってくる。≫

 顧客自身が、自分の要求が明確になるにつれ、優先順位づけも替わり得る。


しかし、

≪古典的なウォーターフォールモデルでは、要求仕様はデザインが始まる前に
 設定されるからである。≫


≪「・・創造的なデザインとは、まず問題を確定し、それから条件を満たす解とは
  どのようなものかその概念を探求するということではない。
  そうではなく、問題と解という2つの「空間」の間で、絶え間なく解析、統合、
  評価のプロセスを繰り返しながら、問題の定式化とその解に対するアイデアの
  両方を一緒に開発し、洗練していくことだと思われる」(Nigel Cross and Kees Dorst)≫



<目次>
第1部デザインのモデル
第1章デザインの課題
第2章エンジニアはデザインプロセスをどう考えるか 合理的モデル
第3章このモデルではどこがいけないのか?
第4章仕様,罪,契約
第5章より良いデザインプロセスモデルとは何か?

第2部協同作業と遠隔協同作業
第6章デザインにおける協同作業
第7章遠隔協同作業第III 部デザインの観点
第8章デザインにおける合理主義と経験主義
第9章ユーザモデル---曖昧であるよりは間違っている方がよい
第10章長さ,重さ,ビット,お金 計画配分すべきリソース
第11章制約は味方
第12章テクニカルデザインにおける美学とスタイル
第13章デザインの手本
第14章熟練デザイナはいかにして失敗するか?
第15章デザインの分離
第16章デザインの軌跡と根拠を表現する

第4部コンピュータサイエンティストが夢見る家屋デザインシステム
第17章コンピュータサイエンティストの夢見る家屋デザインシステム 
 頭脳から機械へ
第18章コンピュータサイエンティストの夢見る家屋デザインシステム
 機械から頭脳へ

第5部偉大なデザイナたち第19 章素晴しいデザインは素晴しいデザイナから生まれる---素晴しいデザインプロセスからではない
第20章素晴らしいデザイナはどこからくるのか?

第6部デザイン空間を巡る旅:ケーススタディ第21 章ケーススタディ:ビーチハウス“View/360”
第22章ケーススタディ:家の増築
第23章ケーススタディ:キッチンのリフォーム
第24章ケーススタディ:System/360 のアーキテクチャ
第25章ケーススタディ:IBM Operating System/360
第26章ケーススタディ:Computer Architecture: Concepts and Evolution の本のデザイン
第27章ケーススタディ:共同計算センターの組織編成:トライアングルユニバーシティ計算センター
第28章推奨文献


【送料無料】ビュ-ティフルア-キテクチャ

【送料無料】ビュ-ティフルア-キテクチャ
価格:3,150円(税込、送料別)




「1章 アーキテクチャとは何か?(ジョン・クライン、デビッド・ワイス)」
(『ビューティフル・アーキテクチャ』)より 




 従来のさほど条件の厳しくないシステム開発であれば、
 アドホックで(その場限りの・その場しのぎの)形式化されていない工学的手法でも、 構築できたのかもしれませんが、
 大規模・複雑化の中での、高性能・高信頼・高品質なソフトウェアシステムの開発は、
 全体をカバーする単一のアーキテクチャを開発・維持することが必須となります。
 
 部分的な場当たり的な開発は、テストや統合の失敗の原因となる。



 そもそもアーキテクチャとは何か?

≪「システムがステークホルダたちの関心事を満たすことの保証手段、
  そしてシステムの構想・計画・構築・保守時の複雑さへの対処手段になり得る」もの≫




 現在のアーキテクチャに求められるものは、
 
 ・顧客の要求する機能が実現できる
 ・予定通りのスケジュールで安全に作り上げることができる
 ・正しく実行できる
 ・信頼できる
 ・安全である
 ・予算内で作ることができる
 ・必要な設計・開発メンバーを揃えることができる
 ・法律・コンプライアンスに準拠している
 ・保守コストが安い
 ・変更・改良しやすいこと
 ・拡張性に優れている

 ソフトウェアアーキテクトの関心事は、直接的には、システムの機能要件にはなく、
 いわゆる「非機能要件」にある。

 この非機能要件は、トレードオフの関係にあるため、
 何を活かし、何に制約をつけるか、を整合性のある統一されたコンセプトにより
 決める必要がある。

 アーキテクチャ構築にあたって、アーキテクトが行う最初の仕事は、

 ステークホルダたちと一緒になって、システムの品質要件や制約について理解し、
 それらの優先順位づけを行うことにある。
 
 ステークホルダたちの関心事は実にさまざま・・
 ・プロジェクト・オーナーは、プロジェクトが予定通りのQCDに収まるかに関心があある
 ・アーキテクト、設計者、開発者は、システムを構築できること、
  構築後は保守・変更・改良に関心がある
 ・プロジェクト・マネージャは、チームを組織し、計画・実施できるかに関心がある
 ・エンドユーザは、システムを使って自分の仕事ができることに関心がある
 ・営業は、非機能要件そのものと、それで実現されたシステムが、いかに競合製品・
  システムと差別化されているかに関心がある

 だから、機能要求だけに飛びつくと、機能要求を実現できても、
 変更可能性、保守性、拡張性などの非機能要件が十分に実現できない。、
 逆に、非機能要件を充足させるために、後から機能要求に制約が加わりかねない。
 また、機能要求を実現できるアーキテクチャは複数ありうる。

 
 アーキテクチャの持つ普遍的原理・・

 1つのことは1箇所に・・重複は誤りにつながるために避けるべきもの。それぞれの「こと」は、単一の分解できない単位とし、他の「こと」とは独立させる。
 たとえば、階層構造によって、各層(レイヤ)がそれぞれ抽象化やドメインを担当することで、
 情報や動作を局所化させることができる。

 自動伝播・・「1つのことは1箇所に」を原則とした場合でも、効率化を考えると、
 一部のデータや動作が重複する場合がある。その際、一貫性・正しさを保つために、
 そのデータや動作の本来の存在個所から自動的に伝播されるようにする。

 アーキテクチャには構築が含まれる・・アーキテクチャは実行時システムだけではなく、
 いかにして作りだすか、も含んでいる。
 美しいアーキテクチャは、実行時に用いられるのと同じでデータ、機能、手法に
 基づいて構築される。
 
 エントロピーに逆らう・・自然に保守を行うと、エントロピーの法則にしたがって、
 時間を経るごとに、システムは乱雑さ増していく。
 美しいアーキテクチャは、この保守の抵抗が最も小さくなるようにし、アーキテクチャ
 そのものが美しくあり続ける必要がある。



 そして、
 アーキテクチャの最も重要な属性は、コンセプトの一貫性にある。
 
 「たくさんの良いアイデアが独立に調和なしに含まれているシステムよりも、
  1つの設計上のアイデアを体現したシステムの方が、ずっと好ましい」(フレデリック・ブルックス) 



 だから、

 美しいアーキテクチャが持つ特徴は、

≪「システム全体を通じて使われる抽象技法と規則の集合が、可能な限り簡単にまとまっている」≫




【送料無料】ビューティフルアーキテクチャ

ビューティフル・アーキテクチャ

編 Diomidis Spinellis , Georgios Gousios

訳 久野禎子 , 久野靖

オライリージャパン

2009年刊


 アーキテクチャの美しさ・・って、どういうものだろうか?

 漠然と考えてもイメージがわからなければ、

 1930年にスイス人のマイヤールが設計した

 サルギナトーベル橋を見てみることです。

 このシンプルで美しい橋が、20名の設計者による競争入札の結果、最も安かったことも
 驚きでしたӤä




序文より・・

「美しいアーキテクチャ」の普遍的原理


1.1つのことは1箇所に

 重複排除、単一で分解できない単位、
 正規化(normalization)、
 くくり出し(factoring)、
 階層構造(layering)

2.自動伝播
 
 もし重複が避けられない場合、自動的に伝播されるしかけとする。

3.アーキテクチャには構築が含まれる

 実行時とともに、
 いかにして作り出すか。

 自己反映的(reflective)
 
 実行時に用いられるのと同じデータ、機能、手法に基づいて構築されることで、
 構築時も美しくなる、

4.メカニズムを最小にする

 全体最適、最小セット

5.エンジンを組み込む

 個別にコントローラーを作らず、VMをアプリケーション基盤として提供する。
 データ中心アプローチにおけるデータ基盤

6.成長のオーダーO(G)

 アルゴリズムの「オーダー」を考慮する。
 要素数と処理時間

7.エントロピーに逆らう

 保守に対する抵抗が最も小さくなるような経路を確立する。

 アジャイルの「メタファ」


「美しいアーキテクチャは、より少ないものでより多くを成し遂げるのです。」




「はじめに」より・・

アーキテクチャの原理と特性・・

1.多目的性(versatility)

2.概念の整合性(conceptual integrity)

3.独立に変更可能(independently changeable)

4.自動伝播(automatic propagation)

5.構築可能性(buildability)

6.成長対応(growth accomodation)

7.耐エントロピー性(entropy resistance)


アーキテクチャ的構造

1.モジュール
  隠蔽

2.依存性
  要素の構造化

3.プロセス
  隠ぺい・隔離

4.データアクセス
  


1章 アーキテクチャとは何か?(ジョン・クライン、デビッド・ワイス)


アーキテクチャとは、

「システムがステークホルダたちの関心事を満たすことの保証手段、
 そしてシステムの構想・計画・構築・保守時の複雑さへの対処手段になり得る」

「アーキテクチャは、トレードオフのゲームである」

 


2章 2つのシステム:今風ソフトウェア物語(ピート・グッドリッフ)


「貧弱な企業の構造と不健全な開発プロセスは、
 貧弱なソフトウェアアーキテクチャとして現れます。」

「ソフトウェア設計の品質を維持するのは大切なことです。
 悪いアーキテクチャ設計は、さらにもっと悪いアーキテクチャの設計へつながります。」

「開発チームの仕事上の関係が健全かどうかは、直接的にソフトウェア設計に影響します。
 関係が不健全だったりエゴが膨らむようなら、不健全なソフトウェアができ上がります。」

「悪いアーキテクチャがもたらす結果は、コードの中だけに押し込めることはできません。
 その結果は洩れ出して、人々、チーム、プロセス、スケジュールなどすべてに影響を及ぼします。」

「デザインをはじめる前に、何をデザインしようとしているのかわかっておくのが大事です。

 デザインするのが何か、そしてそれはどんなことをするのかがわからないのなら、
 まだデザインしてはいけません。
 自分で必要だとわかることだけをデザインするべきです。」

「アーキテクチャは、機能を付け加えたり、変更したり、修理するときに、
 機能のありかを特定するのに役立ちます。
 アーキテクチャは、作業内容をシステムにはめ込む際のテンプレートと、
 システム内をナビゲートするための地図を与えてくれます。」


「アーキテクチャの品質は維持する必要があります。
 それは、開発者がその責任を負わされ、かつ引き受けてはじめて可能となります。」



13章 ソフトウェアアーキテクチャ:オブジェクト指向対関数型(バートランド・メイヤー)
・信頼性 ソフトウェアの正しさと頑健性の確立を助けるか?

・拡張性 変更への対応がどれくらい容易か?

・再利用性 解決策は一般的か? 追加機能は、コンポーネントに変換できるか?





 イタロ・カルヴィーノ「なぜ古典を読むのか」
なぜ古典を読むのか

なぜ古典を読むのか
価格:3,465円(税込、送料別)




 GoF「デザイン・パターン」



<目次>
推薦のことば
訳者まえがき
序文(スティーブ・J・メラー)
はじめに

第1部 アーキテクチャについて
1章 アーキテクチャとは何か?(ジョン・クライン、デビッド・ワイス)

2章 2つのシステム:今風ソフトウェア物語(ピート・グッドリッフ)

第2部 エンタプライズアーキテクチャ
3章 スケーラビリティのためのアーキテクチャ設計(ジム・ウォルド)

4章 メモリーを作る(マイケル・ニガード)

5章 リソース指向アーキテクチャ:「Web上にある」こと(ブライアン・スレッテン)

6章 データの成長:Facebookプラットフォームのアーキテクチャ(デビッド・フェターマン)

第3部 システムアーキテクチャ
7章 Xenと仮想化の美(デレク・マレイ、キア・フレイザー)

8章 Guardian:フォルトトレラントなOS環境(グレッグ・レーシー)

9章 JPC:ピュアJavaのx86 PCエミュレータ(リス・ニューマン、クリストファー・デニス)

10章 Jikes RVM:メタサーキュラーな仮想マシンの威力(イアン・ロジャーズ、デイブ・グローブ)

第4部 エンドユーザアプリケーションのアーキテクチャ
11章 GNU Emacs:漸進的機能追加方式が持つ力(ジム・ブランディ)

12章 バザールが伽藍の建築に乗り出す時(ティル・アダム、ミルコ・バーム)

第5部 プログラミング言語とアーキテクチャ
13章 ソフトウェアアーキテクチャ:オブジェクト指向対関数型(バートランド・メイヤー)

14章 古典再読(パナギオティス・ロウリーダス)

あとがき(ウィリアム J. ミッチェル)
著者・編者紹介
索引

PAGETOP