...

2008 年度 芝浦工業大学大学院 修士論文 題目:Web

by user

on
Category: Documents
64

views

Report

Comments

Transcript

2008 年度 芝浦工業大学大学院 修士論文 題目:Web
2008 年度
芝浦工業大学大学院
修士論文
題目:Web Learning Studio の再構築による建築設計教育支援
―Building Information Modeling 概念の導入―
専攻
工学研究科(修士課程)
学籍番号
507068-5
ふりがな
ながと
氏名
長門
宏明
指導教員
衣袋
洋一
ひろあき
建設工学専攻
目次
Web Learning Studio の再構築による建築設計教育支援
―Building Information Modeling 概念の導入―
第一章
はじめに
1-1
研究背景
1-2
研究目的
1-3
研究内容
第二章
Building Information Modeling
2-1
Building Information Modeling の概要
2-2
Building Information Modeling の効果
第三章
Web Learning Studio
3-1
Web Learning Studio の概要
3-2
Web Learning Studio の経緯
3-3
Web Learning Studio の特徴
第四章
Building Imagination Management の提案
4-1
情報の一元管理の重要性
4-2
WLS の問題点
4-3
システムの提案
第五章
建築設計授業での実践と検証
5-1
提案の実践
5-2
提案の検証と考察
5-3
次期システムの提案
第六章
6-1
総括
総括
謝辞
付録
1
第一章
第一章
はじめに
2
はじめに
第一章
1-1
昨今,建設業界では Building Information Modeling(以下 BIM)という概念が広
研究背景
まっている.BIM は,建築プロジェクトの関係者が共通のプラットフォーム上で情報
共有,一元管理する建築生産の新たな概念である.BIM は,その特性から業務プロセ
スの短縮化やコストの削減が建築の実務の世界で期待されている.しかし,建築設
計教育の世界,主に意匠設計においては,その有効性が実証されていない.そもそ
も BIM は意匠設計の質を高めることを目的としているのではなく,上記で述べた利
点から端を発している.だが, BIM の概念であるすべての一貫した情報管理は,建
築設計教育においても重要視されるべき点である.意匠設計の行為は,アイデアを
発想することに端を発するが,突然の思いつきによってスタートすることは一般的
なことではない.設計条件や設計者の意識やモノの見方等の様々な情報が存在し,
その中から設計へと結び付けていくのである.設計者は断片的な情報を整理・管理
し,プロセスとして明確化していき,フィードバックやループを繰り返しながら,
設計の質を高めていくことが重要である.
3
はじめに
第一章
1-2
衣袋研究室において,1998 年度より「いつでも」
「だれでも」「どこからでも」を
研究目的
コンセプトに,学生と教員・外部アドバイザーによる直接的なやり取りが可能な,
エスキスシステムとして Virtual Design Studio(以下 VDS)の開発を開始した.継
続的な研究,開発により,2002 年度「Web Learning Studio(以下 WLS)」が教育シ
ステムのプロトタイプとして一定以上の成果を挙げたことを受け,2004 年度以降の
研究では,建築設計教育へのさらなる有効化を図るため,設計教育プログラムでの
充実を目指した.WLS は情報共有支援,情報管理支援として開発されたシステムでは
あるが,BIM の概念であるすべての一貫した情報管理が可能なわけではない.
本論は,BIM の概念から情報共有・管理の重要性を示唆し,WLS において不足して
いた情報共有・管理支援を補うために,断片的な情報を共通のプラットフォームで
一元的に整理・管理し,プロセスを明確化することができるシステムを開発する.
建築設計教育において,BIM の概念を新たに読み直し,意匠設計の現場で生かすこと
で建築設計教育の新たな可能性を探る.
4
はじめに
第一章
1-3
『第 2 章
Building Information Modeling』では,BIM の特徴と重要性を読み解く.
研究内容
『第 3 章 Web Learning Studio』においては,衣袋研究室で継続的に開発された,VDS
システムとしての集大成である WLS の理念,開発に至る経緯,特筆すべき特徴を述
べる.
『第 4 章
Building Imagination Management の提案』においては,意匠設計におけ
る情報の一元管理の必要性を示唆し,そのためのシステムの提案を行う.
『第 5 章
建築設計授業での実践と検証』においては, 第 5 章で提案したシステム
を,本研究のケーススタディである「建築設計リテラシー」(2 年次
後期
選択授
業)で実践し,検証する.
5
はじめに
第二章 Building Information Modeling
第二章
Building Information Modeling
6
第二章 Building Information Modeling
BIM の定義と沿革
2-1
Building Information Modeling
の概要
建設産業は,生産性において経済の他部門から立ち遅れているばかりか,過去数
十年において後退しているのが現状である.プロセスの節目ごとに情報ロスが発生
し,生産効率を低下させていた.この解消に向けた取り組みとして,BIM が提唱され
た.
*1 資料:ACAD Fan vol.19
【図 2-1
労働生産性の推移(*1)】
7
第二章 Building Information Modeling
BIM
2-1
Building Information Modeling
の概要
Building Information Modeling の略
BIM とは,建築のさまざまな情報が統合された建築モデルとそれを用いた
設計/施工/維持管理手法を指し,多くの場合,3 次元モデルがその中核と
なる.BIM で使用する建築 3 次元モデルは,
「壁」
「柱」
「窓」などの建築要素,
「空調」
「電気」
「衛生機器」などの設備要素,
「鉄骨」
「鉄筋」などの構造要
素,各要素の「寸法」や「仕様」などの属性を含むオブジェクトデータの集
合体である.このデータの作成作業が設計作業の一部となり,各種の図面や
数量などが取り出せる.このように,BIM において,建築 3 次元モデルは「デ
ータベース」のように活用され,CG パースなどで使用する建物形状だけを表
す 3 次元モデルとは,情報量に大きな差がある.1 つの建築プロジェクトに
は多数の会社がかかわっており,各社各様のソフトが使用されている.こう
した会社間では従来,2 次元図面データや紙図面を介して情報を伝達してい
るが,2 次元データの場合はデータの二重入力やフォーマット変換による情
報の欠落,紙図面の場合は再利用性の低さなどが問題となっている.一方,
BIM では,建築ライフサイクルに必要なすべての情報がコンピュータ上で作
成/変更/管理されるため,データの一元管理と高い再利用性が期待できる.
*2 資料:IAI
【図 2-2
情報の一元管理(*2)】
BIM の由来については 2 つの説がある.1 つは,
「3D オブジェクト指向建築 CAD」を
表すために 2002 年に Autodesk 社によって発案されたとするもの.2 つ目は,ジョー
ジア工科大学の Charles M. Eastman 教授が発案したとするものである.この説は,
「Building Information Model」が「Building Product Model」と基本的に同義で
あるという見方に基づいている.2 つの説とも Jerry Laiserin によって,デジタル
形式による情報の変換および相互運用を支援するための建設工程のデジタル表現を
指す一般的な名前として認知された,という事で意見は一致している.
8
第二章 Building Information Modeling
建築ライフサイクルでは,多数の人が複雑なコラボレーション環境の中で日々の
2-1
Building Information Modeling
の概要
業務を進めている.設計者は,他分野の設計者や技術者,施主,行政などの関係者
に対し,設計内容に関する数値的,工学的な裏付けを示しながら,合意形成を行わ
ければならないが,その際,データの流通が効果的に行われていないと,データの
二重入力や転記間違い,フォーマット変換作業など,多数の手戻りや手間が発生し
てしまう.これらの課題を改善するために,関係者間のコミュニケーションを活性
化し,共同作業を支援するための仕組みが求められている.BIM は最も効果が期待さ
れている仕組みの1つだが,中でも,BIM でプロジェクト全体の生産性向上を図るに
*3 フロントローディング
製造業の製品開発において初
あたり,大きな役割を担うと期待されているのが設計の「フロントローディング」
(*3)
である。設計の初期段階で建築 3 次元モデルを作成することにより,施主に設計意
期段階のうちに問題点を洗い
出して解決し,高い設計品質
を実現する手法.
図を理解してもらいやすくなり,早期に合意が得られれば,後工程での設計変更に
よる手戻りも少なくなる.また,建築 3 次元モデルを使い,日影/構造/環境など
のシミュレーションを行うことで,設計上の問題点を早期に解決できる.どこまで
フロントローディングをできるかが,プロジェクトにかかるコストを大きく左右す
るといっても過言ではない.
9
第二章 Building Information Modeling
BIM 概念による 3 次元設計ツール
2-2
Building Information Modeling
の効果
BIM 概念による 3 次元設計ツールは,Autodesk 社の「Revit Architecture」,
Graphisoft 社の「ArchiCAD」,Bentley Systems 社の「Bentley Architecture」など
がある.BIM では,柱や壁など,使用する個々のパーツに属性,数量などの情報が含
まれており,パーツ同士についても接続や従属の情報が備わっている.壁に窓が配
置すれば,自動的に壁に穴が開くので,設計作業の効率化が図れる.これが,線や
面で構成される 2 次元 CAD と大きく異なる点である.
【図 2-3
従来の CAD と BIM 対応 3 次元 CAD】
10
第二章 Building Information Modeling
企画,設計,施工,維持管理の生産プロセスをつなぐ一貫した情報共有を実現し
2-2
Building Information Modeling
の効果
ようという BIM の概念は,納期短縮,ミス削減,コスト削減など大幅な生産合理化
につながる可能性を秘めている.
企画段階
BIM のワークフローでは,プ
ロジェクトの企画段階で 3 次元
モデルを作成する.例えば,
Revit Architecture では,「マ
スモデル」というスタイロフォ
ーム模型のようなモデルを作成
し,壁や床,カーテンウォール
などの建築要素を張り付けてい
く機能があるが,こうした簡易
【図 2-4
企画段階のワークフロー】
なモデルを作成するだけでも,大まかな空間構成の把握には有効である.さらに,
CG パースやウォークスルー,景観シミュレーションを交えてプレゼンテーションを
行うことにより,施主を含むプロジェクト関係者間のイメージ共有が進み,施主の
要望を引き出す効果もある.また,マスモデルと地理情報システム(GIS)の周辺地
形/建物データを組み合わせれば,斜線規制/日影によるボリューム検討,風や熱
環境などの各種シミュレーションなども可能である.形状/機能のデザインに対し,
法規的/エンジニアリング的な裏付けを,企画段階で与えられる.初期段階におけ
る設計検討の幅が広がることにより,コンセプトや実現可能性,建築コスト,ライ
フサイクルコスト,事業計画などについての大まかな検討を前倒しで行い,これら
のプロジェクトリスクの低減が図れる.建築プロジェクトでは,プラン立案からプ
レゼンテーションまでの時間が限られていることが多いが,そうした短期間の中で
も,コストや法規制,環境条件,技術的条件など,さまざまな設計条件を考慮した
提案が可能となる.
*4 資料:BIM JAPAN
【図 2-5
ゾーニングモデル,マスモデル,コンセプトモデル(*4)】
11
第二章 Building Information Modeling
設計段階
2-2
Building Information Modeling
の効果
基本設計
BIM のワークフローにおける
基本設計は,企画段階で作成し
たコンセプトモデルを,より具
体化することからスタートする.
施主の要望や各種法規制,技術
的条件,コスト条件に沿うよう
に,デザイン上の課題を解決し
ながら,建築 3 次元 CAD を使い,
より詳細にモデリングしていく.
作成した建築 3 次元モデルを利
用し,解析/シミュレーション
【図 2-6
基本設計段階のワークフロー】
やデザインレビュー,意思決定を進める.建築 3 次元モデルを見せることで,設計
の意図を施主に理解してもらいやすく,早期の合意も得やすい.その結果,従来の
紙図面や 2 次元図面データを用いたワークフローより,設計期間は短縮される.併
せて,構造や熱負荷,空調に関する解析/シミュレーションを行えば,施主や維持
管理のしやすさも検証できるため,現実にきわめて近いレベルで建設コストを把握
することが可能である.こうしたサイクルを効率よく繰り返すことで,プロジェク
トにおいて「ボトルネック」となる設計上の問題点を早期に発見し,後工程での手
戻りを削除する「フロントローディング」が実現する.さらに,作業量は従来のワ
ークフローに比べて増加するが,そのぶん,設計品質は向上し,基本設計段階で,
従来の実施設計並みの高精度な設計が可能になる.
*5 資料:BIM JAPAN
【図 2-7
デザインレビュー(*5)】
12
第二章 Building Information Modeling
実施設計
2-2
Building Information Modeling
の効果
BIM を導入すると,企画段階
や基本設計段階から 3 次元モデ
ルを作成し,詳細な設計検討が
行えるようになる.このフロン
トローディング効果により,基
本設計と実施設計は連続したプ
ロセスとなり,従来のワークフ
ローのような明確な境目はなく
なる.このように,スパイラル
【図 2-8
実施設計段階のワークフロー】
に展開される BIM のワークフローの中で,設計図書の図面や数量表は,ある時点の
建築 3 次元モデル(データベース)から取り出される「副産物」と考えてもいいだ
ろう.実施設計段階では,意匠/構造/設備など,複数のパート(部門,会社)が
それぞれ作成した 3 次元モデルをまとめ,建物の完成イメージに近い「BIM 統合モデ
ル」を作成する.BIM 統合モデルを作成するには,
「Bentley Architecture」や「Revit
Architecture」など BIM の概念を取り入れた建築 3 次元 CAD に構造 3 次元モデルや
設備 3 次元モデルをインポートする.それらのソフト上で,柱や梁,設備の干渉チ
ェックやウォークスルー,4 次元/5 次元シミュレーションを行うことにより,意匠
設計と設備設計,構造設計の間の不整合を確認し,施工上,建物運用上の問題点を
検証する.こうしたプロセスを繰り返し,意匠/構造/設備の各設計者間ですり合
わせを行った結果を,それぞれの 3 次元モデルにフィードバックしていくことにな
る.平面図や立面図,断面図など設計図書に含まれる図面は,3 次元モデルから切り
出すように容易に作成できる.高精度な図面を作成するには,設計変更や検討結果
を,意匠/構造/設備など個別の 3 次元モデルに正確にフィードバックすることが
鍵となる.
*6 資料:BIM JAPAN
【図 2-9
意匠モデル,設備モデル,構造モデル,BIM 統合モデル(*6)
】
13
第二章 Building Information Modeling
施工
2-2
Building Information Modeling
の効果
施工段階では,建築 3 時限モ
デルは施工計画のシミュレーシ
ョンに活用される.施工する建
物形状を 3 次元で確認できるほ
か,建築 3 次元モデルと,プロ
ジェクト管理情報に含まれる時
【図 2-10
施工段階ワークフロー】
間や人/ものなどの情報をリンクさせれば,施工手順やスケジュールを事前に検討
する「4 次元シミュレーション」も可能になる.また,コストに関する情報をリンク
させて検討する場合は「5 次元シミュレーション」と呼ぶ.3 次元プリンタを利用す
ると,建築 3 次元モデルから直接,模型を作成することも可能で,複雑な構造を施
工現場などで説明したい場合などに有効である.
*7 資料:BIM JAPAN
【図 2-11
施工工程のシミュレーション(*7)
】
14
第二章 Building Information Modeling
維持管理
2-2
Building Information Modeling
の効果
建物が竣工し,維持管理段階
に入ると,建築 3 次元モデルは
ファシリティ・マネジメント(以
下 FM)分野で活用される.企画
から基本設計,実施設計,施工
と各段階に受け継がれてきた建
【図 2-12
維持管理段階ワークフロー】
築 3 次元モデルには,FM の基本情報となる部屋/ゾーン,設備機器,什器などの資
産情報が蓄積されており,海外では,建築 3 次元モデルをそのままデータベースと
して活用する FM システムの構築も始まっている.建築 3 次元モデルに格納されてい
るオブジェクトデータを図面や履歴データとリンクさせると,建物情報の検索性や
一覧性が向上し,維持管理業務における意思決定が効率よく行えるようになる.
*8 資料:BIM JAPAN
【図 2-13
設備とデータベースの連携(*8)】
15
第二章 Building Information Modeling
BIM を活用した事例
2-2
Building Information Modeling
の効果
日建設計・山梨設計室
日建設計の山梨知彦氏率いる山梨設計室が設計/デザインを手がけた個人美術館
「ホキ・コレクション」では,BIM に対応する建築 3 次元 CAD「Revit Architecture」
で作成した 3 次元モデルを基本設計から実施設計まで一貫して利用し,ビジュアラ
イゼーション,風環境/空調解析,光の明るさ解析,干渉チェックなどを行ってい
る.
*9 資料:BIM JAPAN
【図 2-14
ホキ・コレクション(設計/日建設計・山梨設計室)
(*9)】
・基本計画
BIM 概念の建築 3 次元 CAD を使用し,基本計画段階
のモデリングから各種スタディ,プレゼンテーショ
ンに活用している.
【図 2-15
展示室のパース】
【図 2-16
抽出された図面】
・基本設計/実施設計
設計段階で 3 次元 CAD を活用するメリットは,作
成した 3 次元モデルを任意の位置でカットし,空間
構成や納まりを確認できることである.基本計画段
階におけるビジュアライゼーションから納まりの確
認まで同一のモデルで行えるため,作業効率は大幅
に向上する.
16
第二章 Building Information Modeling
・環境解析
2-2
Building Information Modeling
の効果
「Revit Architecture」で作成した 3 次元モデルを使用し,さまざまなソフト使
うことで,光,風,温度等のあらゆる環境を検討することができる.
【図 2-17
*10 資料:BIM JAPAN
光・風・温度の解析(*10)
】
・干渉チェック
建築 3 次元モデルと設備モデルを統合表示し,干
渉チェックを行うことで躯体と設備機器の干渉を瞬
時に確認することができる.
【図 2-18
赤が干渉している個所】
山梨設計室では,設計プロセスのうち「基本設計」「環境シミュレーション」「構造
解析」の 3 つの部門で,早くからコンピュータ/ソフトウェアを活用していたが,
それらのアウトプットをつなげるプラットフォームとしての役割を BIM に期待して
いる.BIM ソフトの活用により設計プロセスの早期に詳細を詰め,設計変更によるコ
ストへの影響を抑えることを目指す.
17
第二章 Building Information Modeling
シドニー・オペラハウス
2-2
Building Information Modeling
の効果
2003 年 4 月から続いているシドニー・オペラハウス改修プロジェクトでは,建物
が持つ重要な文化遺産としての価値と,多目的文化/芸術施設としての実用的な機
能を後世に残していくことが重要な課題とされ,これを果たすための中心的な戦略
として BIM が導入された.米 Bentley Systems 社の構造/建築 BIM ソフトを使用し
て作成された,構造/建築の 3 次元モデルは,複雑な空間を視覚化してプロジェク
トの理解を促しただけでなく,将来的な改修や維持管理に必要となるさまざまな情
報を集積したデータベースと関連付けられて有効利用されている.
【図 2-19
*11 資料:BIM JAPAN
シドニー・オペラハウス(ヨーン・ウッソン)
(*11)
】
・改修
有名なシェル状の屋根をはじめとして,複雑な形
状が多く,2 次元の図面のみでは空間の把握は困
難であった.そのため,レーザー測量によって 3
次元空間の正確な位置情報を割り出して,既存部
分の正確なモデルを作成し,改修工事が行われた.
また,「Bentley Architecture」と「Bentley
Structural」を使用して意匠と構造のモデルを作
成したことで,建築/構造の一貫性と干渉チェッ
クが実現し,作業時間の短縮や設計変更の容易な
調整などが可能となった.
【図 2-20
3 次元モデル】
18
第二章 Building Information Modeling
・維持管理
2-2
Building Information Modeling
の効果
このプロジェクトでは,建築 3 次元モデルから
維持管理用のデータベースに素早くアクセスでき
るシステムが構築された.
19
第二章 Building Information Modeling
以上のように,建築の実務における BIM の効果は様々に期待されている.しかし,
2-2
Building Information Modeling
の効果
建築設計教育における意匠設計では,その効果は実証されていない.そもそも,こ
こでいう情報とは意匠,構造,設備などの各設計図面情報をはじめ,積算数量情報,
部材・設備の耐用年数情報,面積情報,内装・家具調度品を含めた資産管理情報な
ど,建物のライフサイクルで付加される情報などのことである.これは建築設計教
育における意匠設計で扱われる情報とは種類が異なり,意匠設計の質を高めること
を目的としているのではない. だが, BIM の概念であるすべての一貫した情報管理
のように,建築の意匠設計の行為においても,実際にモノを創造する行為だけでは
なく,情報を整理・管理する行為,情報リテラシーも重要と考えられる.BIM の概念
を企画から設計までに集中させ,建築設計教育の新たな可能性をさぐる必要がある.
20
第三章 Web Learning Studio
第三章
Web Learning Studio
21
第三章 Web Learning Studio
1990 年代に始まった情報通信技術の発展とコンピュータ技術との融合は,メンバ
3-1
Web Learning Studio の概要
ー間に存在していた時間と空間のギャップを埋めることで,設計活動を支援するシ
ステムを生み出す契機となった.教育的視点から注目した大きな流れとして,MIT
の W.J.Mitchell 教授等のグループにより提唱された VDS の概念があげられる.VDS
とは,その名が示すように情報通信技術を利用して,分散している人々が,あたか
も仮想のスタジオ内で共同作業を行うことを可能にするというものである.現在,
VDS の概念に触発され様々な大学で遠隔地協調設計研究として行われている.
「Web Learning Studio」 とは?
「教える教育」から「学ぶ教育」への転換を図るべく,衣袋研究室において開発
された VDS の基本原則である,
「いつでも」
「だれでも」
「どこからでも」,
「セキュリ
ティ確保」,「実際の運営の検討」を守り,システム全体が汎用化しているコミュニ
ケーションツール・ネットワークコラボレーションツールである.
システムを開発する上では,どのような目的で,どのような手段を用いてシステ
ムを構築していくのか,という基本方針を明確にする必要がある.衣袋研究室では
1998 年度より,インターネットの特性を活かし,コラボレーションシステム及び
e-LEARNING システム構築の基本方針を以下の 3 点とした.
①
「いつでも」「だれでも」
「どこからでも」
昨今の私達の生活の中で,コンビニエンスストア,ディスカウントストア,ファミ
リーレストランに代表される 24 時間営業の店舗の出現により,時間という概念は大
きく覆された.インターネット環境も Web サーバーが活動していれば全世界の人々
と常に更新が出来,時間と場所を越えた新たな社会が展開されている.
・インターネットを利用できる時間であれば,「いつでも」
・インターネットを利用できる人であれば,「だれでも」
・インターネットを利用できる環境であれば,「どこからでも」
現在のパソコンはアプリケーションをハードディスクの中に取り込む単独の固定
システムである.フリーソフトとして配布されている Web ブラウザを利用し,コン
ピューター言語を使い Web アプリケーションという動的なシステムを開発すること
が上記の条件を満たす方法である.
22
第三章 Web Learning Studio
②
3-1
外部に対するセキュリティの厳守と運営
Web Learning Studio の概要
システムを構築する上で最も大切なことはセキュリティの厳守という点である.芝
浦工業大学にはファイヤーウォールが存在し,不必要なポートなどは閉じられ,外
部からの侵入を未然に防ぐ.このファイヤーウォールに穴をあけずに運営をするこ
とが重要である.ファイヤーウォールに穴をあけると外部からのハッキングやウィ
ルス等の影響を受け衣袋研究室だけでなく芝浦工業大学全体にまで影響を与えかね
ない.そのため衣袋研究室は開放してある HTTP ポートのみを利用している.
③
実学としての運営と実践
どのようなシステムも実際に運営し利用しなければユーザーの声を聞くことができ
ない.その際に生じる様々な問題に耳を傾けシステムを構築することが大切である.
実際にシステムを運営することで評価点や反省点を明確にし,次期システムへ向け
てのバージョンアップへとつなげていく.
23
第三章 Web Learning Studio
1989 年以来続いてきた,
「情報/ 建築」というテーマも,
「住むための機械」とし
3-2
Web Learning Studio の経緯
てのル・コルビュジェの思考プロセス分析に始まり,分析結果の知識工学に基づく
構造化とデータベース構築,思考ツールとしての CAD の利用形態の構築,それらの
総合として,インターネット,イントラネットを用いた建築設計授業とデータベー
ス(抽象概念参照モデル)との連携による CAAD 設計方法論の展開,そしてインターネ
ット上での時間と場所を共有しない建築設計教育システム VDS の構築へと続き,こ
れまでの継続的な研究・開発から,学生の勉学意欲を刺激し,
「教える教育」から「学
ぶ教育」へ,新たな教育方法へ移行するための教育システム「Web Learning Studio」
へと進化を遂げた.
24
第三章 Web Learning Studio
3-2
Web Learning Studio の経緯
年度
研究内容
1998
html を主体とした VDS を構築.各学年のホームページ上に html 形式で
図面,テキストをアップロードする.
1999
Microsoft 社の Active Sever Page を導入した VDS.画像ファイルのア
ップロードを行うだけで Web ページが自動生成される.
2000
外部者参加型設計教育システムとして,管理面,インターフェイス,閲
覧方法など見直しを図る.提案とレスポンスを 1 つの流れに収め,作品
の生成過程が理解しやすいものとなり,個人設計においては一定の水準
に達した.
2001
リアルタイム/非リアルタイム・分散型コラボレーションシステムとし
て,遠隔地間のグループワークをサポートするコミュニケーションツー
ルのひとつである「チャット」を組み込む.
2002
遠隔地非常勤講師の採用に伴い,コミュニケーション環境,知識の共有
環境,知識の整理/分類環境の充実を図る.必要な機能の洗練化,再構築
を行い,「Web Learning Studio(以下 WLS)」として個人設計・グループ
ワークを支援するコミュニケーションツールを実現する.
2003
WLS を利用した新たな教育形態の充実に視点が向けられる.個人設計で
は「Web Design office」,グループワークでは「ブレインライティング」
を実践する.
2004
グループワークにおけるリーダーの必要性に注目し,意思決定との関係
について分析,有効なコラボレーションのあり方を模索.
2005
設計教育プログラムの更なる改善により,NC システムとの連携により
「設計教育システム」のプロトタイプとして完成した.
2006
ネットワークコラボレーション円滑化を図る新たな機能を追加し,グル
ープワークでの意思決定の際に必要な条件を導き出した.また,授業の
人数増加によりシステムの限界を経験し,新たなシステムを構築する必
要性を示唆した.
2007
WLS の問題点を解決するシステムを開発し,実際の授業の中で実践して
いくことによって WLS を建築設計教育支援システムとして安定性を向上
させることと,ユーザビリティーの改善を実現した.
25
第三章 Web Learning Studio
(1)1998 年度
3-2
Web Learning Studio の経緯
1998 年度本研究室においては,システム思考を基本概念とする CAAD 設計方法論及
び,その具体化としてシステム構築を図り,設計教育の現場に供することを目的と
した.CAAD 設計環境では,WWW のブラウジング機能,コミュニケーションツール,
データベースを用いた思考支援と,WWW サーバー,コミュニケーションツールによ
るコラボレーションを目的とした設計環境の内容を満たすシステムを展開する.
CAAD 設計システムの構築及び運用
CAAD 設計システムは,イントラネットの情報共有システム及びプロセス重視の設
計・シミュレーション行為に対応するシステムとして,建築設計全般,特に設計の
初期段階である企画・エスキ境,CAAD 設計教育の3つの事柄を念頭に WWW のブラウ
ジング機能を利用したデータベース,VDS,ネットワークコラボレーションをも可能
にする設計環境といったシステム構築とその実験的運営である.
図 3-1
1998 年度 VDS
思考支援システム
思考支援システムは,
「発想」を促すことに重点をおき,より恣意的・概念的な部
分からアプローチできる CAAD 設計システムとして構築したものである.具体的には,
建築理念,哲学,そしてデザイン論が構築されていると認められる建築家,建築作
品をテクストとして,分析から得られたデータをもとに,建築家,建築概念・哲学,
建築作品,建築生成過程などを参照させ,ユーザーが抽象的内容から具体的内容へ
と移行しながら思考できる階層構造,リンク構造によって構成している.
コミュニケーションツールとしての検討
私たちはコラボレーション型コミュニケーションツールを使用することにより,
インターネットやイントラネットを利用して電子会議の開催,共有したアプリケー
ションによる共同作業等を行うことが可能である.アプリケーションの共有は3次
元データをも可能にし,現在,様々な場でスタディの実地がなされている.
CAAD 設計システムにおける思考支援システムはユーザーに様々な要素と知識の
関係性について考慮することを促し,設計・計画の細部から全体までいたる継続的・
統合的思考を,システム思考として消化させることを促した.これは個人設計のみ
だけではなく,グループウェアでは時間・場所を問わず,共通の情報を元にコラボ
レーションが行え,グループ外のユーザーとインタラクティブな関係を構築するこ
とで,リアルタイムなレスポンスを行うことができるという利点を導き出した.
26
第三章 Web Learning Studio
(2)1999 年度
3-2
Web Learning Studio の経緯
1998 年度,環境システム学科3年生前期「居住環境デザイン演習」の2課題,
「住
宅設計」(個人設計)」,「まちづくり(グループウェア)」においては,Web 上の対象
作品に対して,アドバイザー(教員,院生,卒業生等)によるエスキス結果を学生自
身が html で書き込み,Web 上に表示するとう,html 主体の VDS を試みた.終了後,
VDS での設計の進め方を体験したユーザー(学生)の印象,実感のアンケート調査を
行った. 欠点として表明された代表的な意見は以下の通りである.
・デジタルエスキスでは細かいニュアンスを伝えきれない
・意図していることと違った解釈をされてしまう
・デジタルデータとすることの作業効率の悪さ
・一方的な意見交換で対話的でない
・率直な意見を言いにくい
・html をつくることに満足してしまっている
等の回答があった.
図 3-2
1999 年度 VDS
1999 年度は上記の意見を考慮し,
・操作が容易であること
・対話的であること
・履歴を参照しやすいこと
・情報交換がしやすいこと
・学生間の意識の向上につなげること
という5点を軸に,これまでのシステムを全面的に見直し,新たなシステム構築を
行った.
Microsoft 社の「Active Sever Page」を用いることで,「図面の閲覧」「ダウンロ
ード」「エスキス」「アップロード」等を,シームレスに行う Web アプリケーション
の構築を目指した.「ASP」はスクリプト処理をサーバー上で行うので,セキュリテ
ィに優れ,Visual Basic や Java といった汎用性の高い言語を使うことが出来る.
1998 年度までの VDS は,各学年のホームページ上に html 形式で図面とテキストを
アップロードしていたが,
「ホームページとしてきれいに表現するよりも,その人の
思考の軌跡が順序を追って見えたほうが,より有効ではないか」という反省のもと,
1999 年度はデータとしての扱いの容易な画像形式(JPEG)で図面と文章を変換し,
掲載することとした.1999 年度の VDS による最大の利点の一つとして,学生各自の
27
第三章 Web Learning Studio
課題に取り組んでいく思考プロセス(履歴)が常時表示させておくことが可能とな
3-2
Web Learning Studio の経緯
ったことが上げられる.それと同時に,教員・アドバイザーのエスキスのフォーム
を学生各自のページと併設することによって,図面のエスキスはもちろんのこと,
文章によるコメント,説明も簡単に参照することが可能になった.このことにより,
昨年度に比べコミュニケーション方法,コラボレーション環境が充実したといえる.
28
第三章 Web Learning Studio
(3)2000 年度
3-2
Web Learning Studio の経緯
1999 年度の VDS において様々な問題点があがった.
・表現手段の少なさ
・通信速度が遅いと見えない
・時間軸がバラバラなのでどこを見たらいいのかわからない
・新しい更新が分からない
・スクリプトミスが多い
・課題を増やすのに手間がかかる
・管理者の負担が大きい
上記の問題に対して以下の4点を盛り込み,新たなシステムを開発した.
通信速度の考慮
実際にインターネットを利用して実践を行った結果,1998 年度は更新された情報
すべてをサムネイルとしてロードしていたため,ユーザーがファイルをアップロー
図 3-3
2000 年度 VDS
ドするほど時間がかかるという反省点が挙げられた.そこで,サムネイルの表示を
廃止し,観覧するファイルを選択してダウンロードさせることで,通信にかかる時
間を減らしアクセシビリティの向上を図った.
表現手段の向上
1999 年度まで,画像ファイルの送受信のみで VDS を進めてきた.しかし,ユーザ
ーは図面の線がつぶれる等の問題により,表現の幅に制限を感じていた.Web ブラ
ウザのプラグイン機能を用いることで,PDF や SWF,VRML といったベクトルデータ
による表現手段の導入を行い,掲載する図面の質によって,ベクトルデータ,ラス
ターデータを選択可能とした.
管理者主体のプログラム
前年度は課題が増えるたびにファイルをコピーし,設定を変更していたため,人
為的ミスが重なり,様々なエラーが起こっていた.そこでファイルの共有を図り,
課題の増減やユーザー管理等を行った. その結果,出題が効率的に行え,管理者サ
イドの負担が大幅に軽減された.
検索システム
従来の CAAD 設計方法論で作成したデータベースや Internet Gallery を効率的に
利用し,VDS に検索システムとして組み組んだ.学生は参考にした「言葉」を,ア
29
第三章 Web Learning Studio
ドバイザーは学生が参考にすべき「言葉」を「キーワード」として記述し,検索を
3-2
Web Learning Studio の経緯
行う.これにより,学生とアドバイザー間で「言葉の意味」の共有がスムーズとな
り,コミュニケーションを取る上で大きな助けとなることを期待した.
1999 年度の VDS は,学生,教員,アドバイザーの領域が確保されていたため,提
案とレスポンスの関係が理解しにくかった.2000 年度は提案とレスポンスを一つの
流れに収め,作品の生成過程が理解できるものとした.また,表現手法の向上や管
理者主体のプログラム構成など,個人設計においては,一定の水準に達したといえ
る.
30
第三章 Web Learning Studio
(4)2001 年度
3-2
Web Learning Studio の経緯
2000 年度の VDS を利用した学生及び外部アドバイザーにアンケート調査を行い,
グループウェアとしてシステムを分析した結果,問題点として
・意思決定ができない
・互いの意見が通じにくい
・相手がどのような思想,思考をしているかうかがいにくい
・外部アドバイザーの意見に反応できない
等が挙げられた.これまでに実施されたグループワークの課題を通して蓄積された
データから,NC を目的とした協調設計システムに必要とされる基本概念をあげる.
インフォーマル性:自分の考えや相手の思考がすぐに読み取れる
表現力:多数のプラグインをサポートし表現の幅を限定しない
思考の継続性:非同期の場合でも自由に意見を発言することができる
履歴性:外部者や途中者,協力者も思考のプロセスが閲覧できる
図 3-4
2001 年度 VDS
アクセシビリティ:利用するユーザーを主体とし通信速度を考慮する
安全性:ファイヤーウォールに穴をあけないセキュリティの確保
上記の基本概念に基づき,2001 年度の研究では,チャットをベースとしたインフ
ォーマルな会話を同軸上に組み込み,遠隔地におけるコミュニケーションを可能と
し,グループのやり取りの中で生まれるコミュニケーションをログとして蓄積する
ことで,自己や他者の意見から学習することを基本方針とした「リアルタイム/ 非
リアルタイム・分散型コラボレーションシステム」の構築を図った.
以下に追加した機能を示す.
内外部閲覧
内部のやり取りを外部閲覧者に対してすべて提示できない理由から,外部閲覧用
と内部閲覧用で異なった表示方法をとる.外部用では,提案の一連の流れが閲覧で
き,内部用では,外部に表示できない発言やイメージスケッチなどコラボレーショ
ンを目的とした機能を付け加える.また,内部用 URL を非公開にすることで不当な
アクセスを未然に防ぎ,ハッキング等の防衛に役立ち,サーバー管理という面でセ
キュリティが向上する.
チャット
インフォーマルコミュニケーションの重要性を認識し,提案のみを行なう非同期
31
第三章 Web Learning Studio
の時間軸にチャットによる同期的なコミュニケーションを同軸上で展開する.提案
3-2
Web Learning Studio の経緯
や外部アドバイザーのエスキスに対してすばやい対応が取れ,互いの意思疎通が図
れる
ログ
チャットに参加していなくても「ログ」がデジタル議事録となり,確認・合意が
得られる.外部アドバイザーはグループ内のやり取りが伺え,学生は自己確認や自
分達の間違えや考え方の推移が確認できる.
決定案提出
9 週間に及ぶ課題に対して,出題者側が意思決定を意識的におこなわせるために週
ごとにステージを設定した.決められた期限までに話し合いをまとめ決定案を提出
し,展開していく.
32
第三章 Web Learning Studio
(5)2002 年度
3-2
Web Learning Studio の経緯
2001 年度,構築した「リアルタイム/ 非リアルタイム・分散型コラボレーション
システム」は,自分の考えや相手の思考をすぐに読み取れるインフォーマル性を重
視し,チャットによるコミュニケーション,履歴性を重視したものであった.2001 年
度の反省点として
・チャットを利用した学生と外部アドバイザーによる直接的指導が見受けられなか
った
・スムーズに時間の共有を図ることができる機能が必要
図 3-5
Web Learning Studio
・ログの量が多くなると時間の経過・提案の洗練化と共に内容が薄れてしまうため,
ログに対して編集・分類を行う必要性がある
等が挙げられたが,チャットログの利用により自身の会話内容,自己決定のプロセ
スの確認等々で,自己を振り返り,思考プロセスを確かめるのに効果がある支援シ
ステムであることが確認され,次期システムへの研究・開発を促し,新たな教育シ
ステムを生み出す契機となった.2001 年度の成果,反省から同期・非同室のグルー
プワークを行う概念として以下の3つを挙げる.
コミュニケーション環境
学生同士やコーチとのアポイント,意思の疎通,協調・共同作業を行う環境であ
る.コミュニケーション空間環境がグループワークのベースを担うため,通信速度
の考慮や理解しやすいインターフェイスの構築など,利用者にとって使いやすい環
境を整えることが重要である.
(グループミーティング,提案・レス,授業チャット,アポイント)
知識の共有環境
グループ内でのコミュニケーションが円滑に行われるためには,グループ全体で,
過去に行った討論による知識とその変化,最終的な結論等の蓄積・共有化が必要で
ある.その結果,時間を気にすることなく,途中参加も可能である.
(チャットログ,ファイル共有)
知識の整理/ 分類環境
共有される知識が時間の経過とともに変更や追加など,洗練化される過程におい
て,どの段階までみた,興味ある知識がどれだけあったか分からなくなる.効率よ
くコラボレーションを行うためには,知識の整理/ 分類が必要である.洗練化され
ていく過程の中で,以前の続きを素早く検索することができ,思考の継続に要する
33
第三章 Web Learning Studio
時間が短縮される必要がある.また各人が行った整理/ 分類の結果を公開すること
3-2
Web Learning Studio の経緯
で,相手がミーティングをどのように受け止めたのかが,分かり,グループの意思
決定を促すことにつながる.
(Clip,その他)
「Web Learning Studio」は教育システムのプロトタイプとして一定以上の成果を挙
げた.次期システムでは,ハード面の更新のみならず新たなソフト面の提案・開発
が望まれた.
34
第三章 Web Learning Studio
(6)2003 年度
3-2
Web Learning Studio の経緯
2003 年度,
「居住環境デザイン演習」第一課題は,
「Web Learning Studio」を「Web
Design Office」(仮想オフィス(へと置き換え,実社会に近い設計環境を体験するも
のとした.加えて,第二課題のグループワークでは,「ブレインライティング」(以
下,BW)という技法を用いて,パートナー型コラボレーションの教育方法を試みた.
Web Design Office
「Web Design Office」とは,より実社会に近い設計環境を擬似的に体験する Web 上
図 3-6
Web Design Office
の仮想デザインオフィスである.仮想の施主,所長,スタッフを取り決め,その間
で交わされる対話,イメージ創出への展開など実際の設計プロセスを疑似体験する
ことで,コミュニケーションスキルを磨くというものである.
<施主と施主要望リスト>
仮想の施主となった大学院生・TA は,スタッフとしての各受講生に対して要望リ
ストを作成し,それをもとに課題が開始される.要望リストは施主によって異なり,
図 3-7
WDO 概念図
受講生の数だけ課題が存在することになる.
<総合ミーティング(同期・非同室型) >
週に1回,所長,TA,スタッフが集まり,全体のミーティングを行う場として「総
合ミーティング」
(Web 上のチャット)があり,学生はそのときどきに課せられた提
案を行う.総合ミーティングを行うことにより,スタッフサイドは互いに知識の共
有化をはかることにもなる.
<プライベートミーティング(同期・非同室型) >
「アポイント」機能を利用した,スタッフと所長の対話(Web 上のチャットなど)
の場としての「プライベートミーティング」を設けた.
<企画・提案(非同期・非同室型) >
上記に記した「プライベートミーティング」
「総合ミーティング」とは異なり,非
同期・非同室型のエスキスシステムを用いている.ここで展開されるのは,プライ
ベートミーティングで重ねてきた文字情報を基に,実質的なイメージ,図面をスタ
ッフが作成し,
「企画・設計」に掲載し,掲載された提案に対して所長がレスポンス
として修正案又はコメントを付加し掲載する.
ブレインライティング
教員が学生に対して一方向のやり取りの中で展開される「教える教育」から,学
生各自が自主的,積極的に参加,意見を述べる双方向の「学ぶ教育」へ,
「リーダー
35
第三章 Web Learning Studio
型コラボレーション」から「パートナー型コラボレーション」への転換を図り,
「協
3-2
Web Learning Studio の経緯
調」と「発想」を促すべくブレインストーミングの改良版といわれるブレインライ
ティングを「Web Learning Studio」に導入した. 中心的なリーダーに他のメンバ
ーが依存する「リーダー型コラボレーション」では, 学生によって GW への参加頻
度に偏りが出てしまい「学ぶ教育」に格差が生まれてしまった.BW を行う際に重要
となるのは,強制的にメンバー全員が参加し,平等に提案を出し合うことが出来る
点にある.BW 導入により, 全員参加,提案の平等性,知識の共有化等,グループ
間での協調性の強い「パートナー型コラボレーション」への展開が図られた.
36
第三章 Web Learning Studio
(7)2004 年度
3-2
Web Learning Studio の経緯
Web Design Office の更新
2003 年度の第一課題では,受講生参加姿勢の種別と成果が得られたが受講生のタ
イプにより,課題の進捗,結果に大きな差があった.受講生の取り組み方によるも
のだが,専任教員,遠隔地非常勤講師,外部アドバイザーがより一体的な連携をと
ることで,受講生の参加意識を高め,より立体的な指導を行えると考える.
2004 年度の「居住環境デザイン演習」
(3 年次・受講生 14 名)第一課題(住宅・
8 週間・個人設計)にて展開される「Web Design Office」において, 建築設計の段
階に応じた学生とアドバイザーの関わり方の変化,デジタルエスキス(Web 上の非
同期・非同室及び同期・非同室で行われるエスキス)とアナログエスキス(同期・
同室の研究室及び教室で行われる対面型のエスキス)の関係性に着目することによ
り, 以下の 4 点をねらいとする.
・様々な個性を発見的に育てる
・それぞれに自らスキル開発の糸口をつかませる
・設計プロセスを分かりやすく体験させる
・受講生間の交流(互いを知る)を深める
双方が学び刺激し合えるような弾力的で双方向性のある教育環境の実現を目指す.
2004 年度の具体的な試みとして以下 3 点を挙げる.
①
計プロセスの段階に応じたシステム運用
建築設計を 4 段階に区切り,各段階に応じた課題や対応を行うことで,2003 年度
見られた参加姿勢のばらつきの解消をめざした.以下に段階分類と段階ごとのテー
マや課題を示す.課題では, 大きく分けると 4 段階をステップすることを想定した.
建築設計の段階
学生に課せられたテーマ
第 1 段階
施主チャットで得られた与条件からキー
施主要望のまとめ
ワード発想,アドバイザーによる記号,
参考作品
文字だけのデジタルエスキスの段階
キーワード
施主要望のまとめ
第 2 段階
テーマ
キーワードからコンセプトを設定する段
コンセプト
階
37
第三章 Web Learning Studio
3-2
Web Learning Studio の経緯
第 3 段階
コンセプトから抽象的な形・イメージに
抽象的な形・イメージ
変換する段階
第 4 段階
図面
イメージを建築設計図面にする段階
【表 3-1
段階の分類と各段階で学生に課せられたテーマ】
38
第三章 Web Learning Studio
(8)2005 年度
3-2
Web Learning Studio の経緯
2004 年度,
「居住環境デザイン演習」第一課題において,WDO 及び設計段階を意識
したエスキスを実施したことで,受講生の参加意欲が向上し,段階を意識した教員
陣の連携を緊密にするなどの成果を得た.一方問題点として,設計期間(9 週間)に
対する各段階で用意した期間の割合が不適当であっため多くの最終提出案の完成度
が低下したことが挙げられる.以上の反省を基に, 2004 年度は設計教育プログラム
の見直しと設計段階の簡略化を行った.
設計教育プログラムの見直し
提案や図面の密度を上げるために,昨年度のような建築設計の段階を追わせず,
第 3 週目から図面を提出させた.結果的に昨年度での「コンセプトから抽象的な形・
イメージに変換する段階」を第 2 段階の中に集約した.
1 週目から 2 週目に行われる与条件を聞き出す「施主ミーティング」に加えて,
本年は 7 週目から 8 週目(最終段階の手前)にかけて,設計条件を再度確認できる
「施主ミーティング」の期間を設けた.図面化作業のなかで,施主要望事項を再確
認し図面にフィードバックできる機会として位置付けた.
思考の連続性
非同期・非同室型のシステムを採用することにより,教える側と教えられる側が
時間と場所に制約されることなく,設計教育を継続的に行うことが出来る.時系列
図 3-8
Web Learning Studio
に沿って提案が積み重ねられるため,思考過程が見えやすく,プロセスを確認しな
がら建築設計を学ぶことが出来る.
ログの有効性
同期・非同室のシステムでは,チャット機能を採用している.思考したことを文
字情報に置き換える瞬間,一時的に冷静になり,発言内容が整理されるため,円滑
にコミュニケーションが進められる. 音声でのやり取りも可能であるが,基本方針
のセキュリティの厳守に反してしまう.また,記録に残らない音声よりも,全ての
会話の記録が「デジタル議事録」となり,確認・合意が得られるチャットの方が有
効である.
汎用システム構築
従来の VDS システムに対して汎用化を目指しプラットフォーム,プラグ・インとい
う概念を導入し,授業の利用形態に合わせた最適な機能を組み合わせて利用するこ
39
第三章 Web Learning Studio
とができる.プラグ・インとは,アプリケーションに機能を追加する機能拡張ファイ
3-2
Web Learning Studio の経緯
ルプラグインのファイルを特定のフォルダに入れることにより簡単に機能を追加す
ることができる.プラグインは単体で動作せず,必要に応じて組み込んだり取り外
したりできる.2005 年度版 WLS では,
『企画・設計』
『アポイント』
『総合ミーティン
グ』
『プライベートミーティング』
『グループミーティング』
『ブレイン・ライティン
グ・ステージ』
『Clip』
『検索』
『アンケート』といったプラグインが搭載され,必要
な項目を随時組み込む.プラットフォームは,他の科目等でも共通に利用可能な項
目として,授業科目選択機能「SUBJECT」,授業課題機能「PROJECT」,情報共有化機
能「INFORMATION」(シラバス&教材・資料,共通掲示板)とした.
40
第三章 Web Learning Studio
(9)2006 年度
3-2
Web Learning Studio の経緯
設計行為の支援
2005 年度までの継続的な研究と開発により, WLS を用いた技術面と教育プログラ
ムの統合による設計教育モデルがほぼ完成したといえる.設計を行う環境が設計プ
ロセスに十分影響を及ぼすように,WLS を使用した設計行為は,インターフェイス及
び諸機能等のシステム環境にある程度依存せざるを得ない.システム的,技術的な
視点から現状の WLS を見てみると,非同期非同質型の建築設計及び,NC を実現する
ための環境を構築してきたといえる.2006 年度の方針として,設計環境の実現と提
図 3-9
リソース機能
供という立場から,設計行為の支援といった,より設計主体に近づき影響を与えて
いく立場への移行を図った.WLS へ「ソフト」的な役割を担う機能を導入することで
設計プロセスを円滑にすることを目論む.
Web ベースコミュニケーションシステム
Web ベースコミュニケーションシステムとは,WWW 環境を利用とした双方向性のコ
ミュニケーションシステムの総称であり,WLS の拡張概念として捉えることが出来る.
WEB カメラ,IP 電話,TV 会議システムといった双方向型の環境を構築,支援するシ
図 3-10
サムネイル機能
ステム群と,それらを円滑に進めるためのプログラムとの連携によって構成される.
従って,これまで NC システムとして開発されてきた WLS は,Web ベースコミュニケ
ーションシステムの概念の中において,上記環境を構築する数あるシステムの中の
一つとして捉えられる.WLS の 2006 年度以降の展開として,Web ベースコミュニケ
ーションシステムという大きな枠組みを視野に入れ多種多様な双方向型のシステム
を活用することで,建築設計教育のみならず,WWW 環境を利用したコミュニケーショ
ンの生成及び円滑化のために必要な環境の構築を行うことを目的とされた.
リソース機能
リソースとは,エスキス図面,参考画像,敷地に関する情報,スタディしたデー
図 3-11
イメージ評価機能
タ等といった設計プロセスで作成・参照される全てのデータを指す.リソース機能
は,各ページで扱われているデータ群を集め関連付けを行い,それらを体系的に扱
うことが出来る.これにより,グループメンバー同士でデータの共有化を促し,設
計プロセスや思考の変化を把握しやすい環境を整えることができる.
サムネイル機能
サムネイル機能とは,ミーティングページの右側に,イメージ発言によって掲載
図 3-12
決定案機能
された画像のサムネイルを表示するスペースを設けた機能である.サムネイル機能
41
第三章 Web Learning Studio
を導入することで,テキストの発言とイメージ発言を表示する場所を分離させ常に
3-2
Web Learning Studio の経緯
イメージが表示出来る環境を提供する.その結果,個々のイメージを用いた対話が
可能となり,対話すべき内容も明確化する.
イメージ評価機能
評価基準のページを導入することで,メンバー全員が適切に評価を行える環境を
提供する.また,評価結果を常時表示させておくことで,評価基準を基にメンバー
間で意思疎通を図りながら決定案を絞り込むこませることを目的とする.
決定案機能
決定案機能の導入により,決定案を直ぐに認識できる環境を整える.また対話ご
とに決定案を意識的に選出させるよう誘導する.
42
第三章 Web Learning Studio
(10)2007 年度
3-2
Web Learning Studio の経緯
2006 年度飯島論文において,ネットワークコラボレーション円滑化における WLS
の有用性とそこに現れる特徴を指摘し,システムの限界と発展可能性を論じた.2007
年度では,飯島論文によって指摘された WLS の問題点を解決するシステムを開発し,
実際の授業の中で実践していくことによって WLS を建築設計教育支援システムとし
て安定性を向上させることと,ユーザビリティーの改善を目的とした.
データベース
図 3-12
Access と SQL のデー
タ呼び出し方法の違い
2006 年度までのシステムに使用されていたデータベースソフトである Access に
代わり,PostgreSQL を採用した.SQL はサーバー側で検索を行いクライアント側に
必要な情報だけを返すので,ネットワークにかける負担が少なく,複数のアクセス
が同時に集まるような場合に有効である.また,サーバサイドスクリプトとして
PostgreSQL との互換性も高く,ASP に似た構造を持つ PHP を採用した.
図 3-13
one user・one license
one user・one license
ユーザーID の増加に伴い,ユーザーの管理をより効率よくするために,授業ごと
にアカウントを発行するのをやめ,一人のユーザーが複数の授業で同一のアカウン
トを使用できるようにした.
one window
これまでの WLS で別々に表示されていた各ウィンドウをフレームで処理すること
により一つのウィンドウに収めた.また,クリックした項目に色を付けることによ
図 3-14
one window
り,迷うことなく必要な情報に到達できることができる.よりシンプルな構成にす
ることによりユーザーが迷う余地を無くした.
データ登録・閲覧ページ
Web 上でデータ登録や修正を行うページを作成した.このページでは,ユーザ登
録,科目登録,課題登録,データ削除,データ修正を行うことができる.管理者権
限をもつアカウントのみが閲覧可能となっており,それ以外のアカウントからは閲
覧できないようになっている.
図 3-15
データ登録・閲覧ページ
スケジュール機能
設計を進めていく中で,スケジュールを管理することを意識させるために提出期
限やスケジュールなどをより具体的な形で示した.また,ユーザーがデータをアッ
43
第三章 Web Learning Studio
プロードした日が表示されることによってユーザーがどれだけその課題に取り組ん
3-2
Web Learning Studio の経緯
でいるかが一目瞭然となっている.
2007 年度に構築した開発した WLS では PostgreSQL の必要最低限の機能を盛り込ん
だシンプルなものとなっている.その分,小規模なバージョンアップを頻繁に行う
ことのできる自由度の高い柔軟なシステムになっている.そういった小規模なバー
ジョンアップを繰り返し行うことによって少しずつシステムの安定性を高めていき,
ユーザビリティーの高いシステムを構築することが可能になっている.
図 3-15
スケジュール機能
44
第三章 Web Learning Studio
以上がこれまで,衣袋研究室で継続的に開発が行われてきた WLS の全容である.
3-3
Web Learning Studio の特徴
以下に現状の WLS の概要を示す.
概要
・データベース機能
設計を行う際に有用な情報を WLS 上で提供していくことを目的に,当時研究室で
作成していた「思考支援データベース」との連携を行い,WLSへ導入された.
(1999
年度導入)
【図 3-16
データベース機能】
教える側と教えられる側が時間と場所に制約されることなく,設計教育を継続的
に行うことが出来る. 時系列に沿って提案が積み重ねられるため,思考過程が見え
やすく,プロセスを確認しながら建築設計を学ぶことが出来る.
45
第三章 Web Learning Studio
・チャット機能
3-3
Web Learning Studio の特徴
方針決定・初期イメージ創出等を決定する初期階において,個人の独自性を生か
しつつブレインストーミングの長所を生かした発想支援システムとして導入された.
決められた時間内でチャットページ上ブレインライティング(以下 BW)を行うこと
で,メンバー全員が時間内で集中して思考すること,同等の数の提案を出すことを
促す.(2002 年度導入)
【図 3-17
CHAT 機能】
46
第三章 Web Learning Studio
・スケジュール機能
3-3
Web Learning Studio の特徴
設計を進めていく中で,スケジュールを管理することを意識させるために提出期
限やエスキススケジュールなどをより具体的な形で示した.また,ユーザーがデー
タをアップロードした日が表示されることによってユーザーがどれだけその課題に
取り組んだかが一目瞭然となっている.(2007 年度導入)
【図 3-18
スケジュール機能】
47
第三章 Web Learning Studio
これらの機能は,以下の 3 つに分類することができる.
3-3
Web Learning Studio の特徴
(1)情報共有支援
(データベース機能)
デザイン検証のために必要となる情報群を共有するための支援システム.
(2)発想支援
(チャット機能)
発想する行為を,自ら考え情報を生み出す行為と捉え、考える行為をより創造的に
する支援システム.
(2)情報整理支援
(スケジュール機能)
デザイン検証のために必要となる複雑で多様な情報群の整理を,カレンダーを元に
支援する.
以上,衣袋研究室において継続的に開発が行われてきた WLS の概要を述べた.情
報通信技術を利用して,遠隔地協調設計研究として行われてきた WLS ではあるが,
BIM 概念である情報の一元管理に関しては,まだまだ不足している部分がある.次章
では,建築設計教育の現場である意匠設計の分野において,情報の一元管理の重要
性を示唆し,それを元に WLS を再構築するシステムを提案する.
48
第四章
第四章
Building Imagination Management の提案
Building Imagination Modeling の提案
49
第四章
4-1
Building Imagination Management の提案
「何を建てるか」
「どんな建物にするか」を決める建築の意匠設計は偶然の思いつ
情報の一元管理の重要性
きではなく,何らかの思考の結果である.リニアに決定が進められていくのではな
く,代替案との間で選択がなされたり,手戻りが生じたりとストレートに物事が決
定されない.さまざまな試行錯誤が繰り返されるために,断片的な情報や条件を整
理・管理することが大切になる.その内容をプロセスとして明確化することにより,
フィードバックやループを繰り返し,設計の質を高めていくことに繋がる.
【図 4-1
設計プロセスパターン】
50
第四章
4-1
Building Imagination Management の提案
意匠設計における情報
情報の一元管理の重要性
意匠設計におけるプロセスで発生する情報を明確化し,BIM を意匠設計の現場で生
かす足がかりとする.
・設計目標
どんな設計も無条件ということはありえない.必ず設計条件が存在する.この設
計目標とは,課題作成者が学生に対して,与えた条件すなわち与条件ではなく,学
生がその与条件から建築の設計について問題を作成し,その問題に対して建築化す
るための設計条件としてまとめたものが設計目標となる.与条件は限られた範囲内
の要求であることが多く,それらからただちに建築化への設計行為になることは一
般に困難である.まず,与条件から設計条件を明確にしていき,学生の経験や知識,
受けた教育などから何らかの形で問題を整理することになる.
そうして,与条件を整理し,しだいに建築的な設計条件を構成していく.
51
第四章
4-1
Building Imagination Management の提案
・プログラミング
情報の一元管理の重要性
今日においては,設計の方法が個人的なスケールを超えて大きく変革を要求され
ており,設計手順の科学的なアプローチによる計画性の有無は設計そのものの質を
大きく左右する要因の一つとなっている.
設計対象の機能の複雑化・高度化それに巨大化といった要因に関連して設計に必要
なデータ,情報量の激増性,そしてこれらに反比例するかのように期限の短縮化は
日ごとにその度合いがきびしく要請される中で設計行為をなされなければならない.
数多い作業をどのようにくぎって,いかに関連づけるかスケジューリングしていく
かというのは,設計のプログラミングとしては最も重要なものである.
52
第四章
4-1
Building Imagination Management の提案
・アイデアと資料
情報の一元管理の重要性
アイデアは,ある要求が存在するとき,その要求をいかにして満足させるかとい
う手段として考えられるが,一般に建築が完成するまでにたどる思考の筋として,2
つの方向が考えられる.1 つはその建物にはどのような機能が要求されるかというこ
とであり,他はこの建物を生産するのにいかなる技術的または経済的背景を必要と
するかというような条件であろう.
新しい創造のメカニズムは建築のもつシステムを新たなサブシステムに分解し,こ
れに対応したさまざまなアイデアを一連のプロセスの中で考えなければならない.
この一連のプロセスの中で新たな創造につながるものとしてつぎの点に注目する.
(1)
新たなサブシステムの構成はいかにして可能か,言い換えればシステム転
換の方法はなにか
(2)
この新たなサブシステムに対応して生まれるアイデアの発想とその処理
“記憶にたよらず,記録にたよれ”という言葉がある.たよれるような記録を集
めてこれを使いやすいシステムに整えておくこと,つまりある目標達成のために有
効なおよび潜在的に有効可能性のある情報の計画的収集,評価選択とその資料化,
さらに要求に応じ随時ただちにこれらの中の特定なものへの到着を可能とする分類,
整理.きわめて一般的には,ドキュメンテーションと呼ばれる技術はこうした一連
の情報処理過程をさす.ここで資料とは,ある情報を有効に伝達するべく記録,定
着された媒体物をいうものと規定しておく.なお,有効な情報が必ずしも資料化さ
れているとは限らない.
53
第四章
4-1
Building Imagination Management の提案
・総合化
情報の一元管理の重要性
この段階に至るまでに設計条件が分析・検討され,プログラムが組まれ,適切な
資料・収集・整理が行われ,またさまざまなアイデアが提案されてきた.ここでは,
これに対応して,それらをひとつの原型(プロトタイプ)に定着させる作業が行う.
いわゆる基本設計をここでうきぼりにすることになるのである.
【図 4-2
基本設計と建築】
54
第四章
4-1
Building Imagination Management の提案
・展開
情報の一元管理の重要性
総合化までに行ってきた基本設計から最終提出のために,ダイアグラム・パース・
図面・模型等を完成させる.
【図 4-3
【図 4-4
【図 4-5
パース】
模型】
ダイアグラム】
55
第四章
4-1
Building Imagination Management の提案
ここまで,第 2 章において建設業界で注目され始めている BIM から情報の一元管理
情報の一元管理の重要性
の重要性を説いた.しかし,BIM の情報の一元管理とは,建築設計行為の全般を指し
ており,建築設計教育の現場での有効性は示されていない.それは,BIM 概念の情報
の一元管理とは,意匠設計の質を高めるものではなく,業務プロセスの短縮化やコ
ストの削減を目的としているからである.しかし,第 4 章の「情報の一元管理の重
要性」で述べたように,意匠設計のみの分野においても様々な情報が発生する.そ
れらを一元的に整理・管理することでフィードバックやループを繰り返し,設計の
質を高める可能性があることを示唆した.これを元に,WLS を再構築する.
56
第四章
4-2
WLS の問題点
Building Imagination Management の提案
第4章の「情報の一元管理の重要性」で,意匠設計においても断片的な情報や条件
を総合的に整理・管理することが重要と説明したが,現行のWLSではそれに対応しき
れていない.
データベース機能における問題点
データベース機能は,時系列に沿って提案が積み重ねられ,思考過程が見えやすく,
プロセスを確認しながら進められるが提案される情報は最終的なまとめられた提出
データが多い.
【図 4-6
データベースとまとめられた最終的なデータ】
この最終的なデータは,「情報の一元管理の重要性」でいうところの展開もしくは総
合化にあたる.しかし,それまでに至るには本章の最初で述べたように,設計目標・
プログラミングやアイデアと資料等,多くの情報が発生する.現状のWLSでは,これ
らの情報を整理・管理するインターフェイスは存在しない.そのため,学生が設計に
おいてフィードバックやループを行うことは少なく,設計の質を高めることができな
い.
57
第四章
4-2
WLS の問題点
Building Imagination Management の提案
スケジュール機能における問題点
設計を進めていく中で,スケジュールを管理することを意識させることを目的と
し,提出期限やエスキススケジュールなどをより具体的な形で示すために,カレン
ダーをベースとして 2007 年度からスケジュール機能を導入した.
提案をアップした日
chat を行う日
【図 4-7
スケジュール機能】
情報整理支援機能として導入されたスケジュール機能ではあるが,日ごとにアップさ
れたデータは,どのようなデータなのか,誰がアップしたものなのか等の細かな情報
が不足しているため,整理支援機能としては未熟なものとなっている.
58
第四章
Building Imagination Management の提案
新たな支援機能の提案
4-3
システムの提案
BIM の概念から情報共有・管理の重要性を示唆し,WLS の問題点の考察から,WLS
において不足していた情報共有・管理支援を補うために,断片的な情報を共通のプ
ラットフォームで一元的に整理・管理し,プロセスを明確化することができる支援
機能を開発する必要性がでてきた.
下図に本年度,新たに導入した支援機能と改善した支援機能をまとめた表を記す.
導入及び改善した
Project Management 機能
スケジュール機能
データベース機能におけ
スケジュール機能に
る問題
おける問題
建築作品データベース機能
支援機能
問題点
分類
情報の整理・共有
情報の管理
情報の取得
解決策
インターフェイスの作成
情報のビジュアル化
インターフェイスの作成
【図 4-8
新支援機能と分類】
以上の支援機能を導入した結果,2008 年度 WLS は図のようになる.
【図 4-9
2008 年度 WLS 概要】
59
第四章
Building Imagination Management の提案
スケジュール機能
4-3
システムの提案
情報整理機能として,2007 年度に導入されたスケジュール機能.第 4 章の「WLS
の問題点」で指摘したように,表示される情報不足により,整理機能としては未熟
なものとなっていた.
目的
スケジュール機能は,WLS の最大のツールとして存在しており,ユーザーは必ずこ
のスケジュール機能を中心として,情報をやりとりする.つまり,WLS 上に情報の一
元管理・整理を目的とするシステムを確立するためにはスケジュール機能の強化を
図る必要性があるのである.
【図 4-10
情報の明確化】
改善点
2007 年度のスケジュール機能の問題点から,
「何時・誰が・何を・どのように」を
ビジュアルにカレンダーに表示されるようにシステムを再構築した.
2007 年度までのスケジュール機能
【図 4-11
2008 年度のスケジュール機能
改善されたスケジュール機能】
60
第四章
Building Imagination Management の提案
Project Management 機能
4-3
システムの提案
Project Management 機能とは,意匠設計過程において,発生する様々な情報群を
カレンダーをベースとして,ユーザーが WLS 上で一元的に整理・管理・共有できる
支援機能である.
【図 4-12
情報群】
目的
Project Management 機能は,ユーザー自らがインターネット上で断片的な情報を
一元的に整理・管理することで,設計過程の効率化,時間短縮を狙い,設計行為に
おいてフィードバックやループを多く発生させることで,設計の質を高めることを
目的としている.
【図 4-13
Project Management 機能による設計の質の向上】
61
第四章
4-3
システムの提案
Building Imagination Management の提案
使用方法
Project Management 機能を用いることで,カレンダーをベースに「いつ・誰が・
何を」を確認しながら,整理・管理できる.また,今まで,PDF・JPG 等の限られた
拡張子のデータのみしか WLS 上には保存できなかったが,Project Management 上に
はあらゆる拡張子に対応しており,制限なくアップできるようになっている.
以下にその流れを記す.
①「PROJECT」において「Project Management」を選択する
②「USERS」において自分の名前を選択する
③「新規データアップロード」をクリックし,データをアップ
④表示結果がカレンダー一覧もしくは,日付・データ別に表示される
⇒情報の整理・管理
⑤必要な情報のアイコンをクリックし,ダウンロードする
⇒情報の共有
Project Management
Name
新規データアップロード
情報の整理・管理
情報の共有
【図 4-14
Project Management の流れ】
62
第四章
4-3
システムの提案
Building Imagination Management の提案
情報の整理
Project Management における情報の整理は,カレンダーを元に行う.また,カレ
ンダーの他に,ツリー状に情報の一覧が表示される.これらは,WLS が自動で行うた
め,ユーザーはデータの情報(何時・何を・コメント等)を入力するだけで整理で
きる.
【図 4-15
カレンダーをベースとした情報の整理】
63
第四章
【図 4-16
4-3
システムの提案
Building Imagination Management の提案
ツリー構想をベースとした情報の整理】
建築作品データベース機能
4-1 の「情報の一元管理の重要性」における「アイデアと資料」において,たよれ
るような記録を集めてこれを使いやすいシステムに整えておく,目標達成のために
有効な及び潜在的に有効可能性のある情報を資料化し,分類・整理することが重要
であると示唆した.
目的
建築作品データベース機能は,建築家の作品を WLS 上で一元的に保存・管理・表
示する機能である.
「模倣は創造の始まり」という言葉があるように,誰しも 0 から
建築は設計できないはずである.過去の作品を参考にし,分析することは学ぶこと
が多い.そのための情報を WLS から瞬時に得ることができるようになっている.
使用方法
建築作品データベース機能は,著名建築家の作品を網羅しており,あらゆる作品
をデータベース化してある.
以下にその流れを記す.
①「INFORMATION」において「建築作品データベース」を選択する
②参考にする建築家の作品を選択する
⇒情報の取得
名前・用途・年代・場所別
表示
建築作品データベース
64
第四章
【図 4-17
4-3
Building Imagination Management の提案
建築作品データベースの流れ】
システムの提案
情報の集積
建築作品データベース機能は,誰でも閲覧・編集ができるようになっている.こ
れは,多くの利用者が参加して情報を出し合うことで,Wikipedia のようにその蓄積
が全体として巨大な「集合知」を形成させるデータベースを作成させるためである.
【図 4-18
情報の編集】
65
第四章
4-3
システムの提案
Building Imagination Management の提案
第 2 章で述べたように,BIM は建築設計業務における一般的なマネージメント,特
に現在は施工管理と情報管理となっているのが現状である.これに対し,衣袋研究
室での新たな取り組みとして,現状の BIM を Building Imagination Modeling(以下
bim)と新たに読み替える.これは BIM の概念を企画から設計までに集中させること
で,BIM を建築設計教育に特化させることである.
建築プロジェクトに関わるあらゆる設計情報をモデル情報とあわせて一元管理す
ることで,ドローイングの自動化,レポーティング、設計・構造分析,スケジュー
ル予測,施設管理などの他にも多岐に渡る情報を 3D モデリングに関連付けて一元管
理することにより,建築プロジェクトに関わる全ての「思考プロセス」
「モデル構築」
の情報を管理するという既存の BIM の概念を元に,bim は,企画(発想)・設計・プ
レゼンテーション・完成図面(実施図面)まで「設計系」に関して一元管理・集中
化を特化させることと定義する.本年度,WLS において新たに提案した支援機能は,
この bim の概念を実際に実現化及び建築設計教育の現場において,実践させるため
のシステムとなっている.
次ページに,本年度 WLS の全体図を記す.
66
新システムの構成
企画提案でアップしたものが表示される
提案・設計
提案・設計
新規データアップロード
ようこそ 長門 宏明さん
sun
削除
Subject
授業一覧
08 建築・地域プロジェクト特論
title
08 居住環境デザイン演習
修士論文
08 建築設計情報特論
from
08 建築設計情報
長門 宏明
08 建築計画
day
08 修士論文
2008/07/10
08 Diploma
filesize
07 建築設計リテラシー
50KB
Information
情報一覧
tue
次の月
wed
1
thu
2
企画設計
レスポンス
総合ミーティング
16:30 ∼ 18:00
fri
3
sat
4
デジタルエスキス
15:0 ∼ 19:30
シラバス
Project
第一課題
「住宅設計」
提案・設計
Chat
Progect Management
5
クリック
RESPONSE
デジタルエスキス
15:0 ∼ 19:30
7
変更
chat
2:00 ∼ 3:00
8
9
企画設計
10
総合ミーティング 11
16:30 ∼ 18:00
chat
2:00 ∼ 3:00
12
企画設計
レスポンス
13
today
削除
共通掲示板
建築作品データベース
科目一覧
mon
企画設計
レスポンス
Subject
08 居住環境デザイン演習
7月
前の月
変更
アップされたデータの表示
title
修士論文
クリック
from
14
長門 宏明
day
企画設計
レスポンス
15
16
17
企画設計
18
総合ミーティング
16:30 ∼ 18:00
23
24
総合ミーティング 25
16:30 ∼ 18:00
30
31
2008/07/10
企画設計
レスポンス
19
デジタルエスキス 20
15:0 ∼ 19:30
26
27
filesize
50KB
RESPONSE
第二課題
「私のつくる街の診断書」
提案・設計
Chat
変更
21
削除
22
Progect Management
シラバス
共通掲示板
建築作品データベース
履修者一覧
建築作品データベース
UPLOAD
◇共通掲示板◇
cad のデータなどに限り、zip で圧縮してから
学生,アドバイザー,教員が自由に発言する
アップしてください。そのままでアップする
場
とダウンロードできない症状が発生していま
追加・編集
( 書き込み ) ( イメージ書き込み )
タイトル
検索実行
日時
画像
Architect
顔写真
02 建築計画とは
03 建築計画1_ 独立住宅
04 建築計画2_ 集合住宅 _01 熊本保田窪団地 .
filesize
竹内慶太郎 50KB
28
企画設計
レスポンス
29
久木野陽一 削除
画像:なし
50KB
OPEN FILE
comment
title
上野翔 修士論文
from
長門 宏明
記入者:山嵜
2008/07/10
filesize
responce 山嵜(ロンドン)
アポイントメント作成
総合ミーティング作成
宮地洋 大野剛 長門 宏明
day
変更
青木淳
芦原義信
修士論文
from
お願いします
中島彩 吉田新 title
comment
竹下悦子 芦原太郎
メビウスがややこしくなっているのならば、まずはそれを横に置いておいて、どのように出会うのかの場所を描けばいいのではないか?登場人物も3つではなく、仮想と現実で生活している人々として
Back to today -> 2008 / 7 / 9
対になって考えればよいのではないでしょうか? で、関係性、どのような配置(壁を隔てて活動しているとか、床で仕切られているとか)が見えてきたら、そこにメビウスの輪として取り込めば、しっ
くりいくかもしれません。メビウスの輪から考えていてもナカナカ建築にならないかもしれない。関係性とその配置を具現化するときにメビウスが使える、また、緩やかに繋がっているというイメージ
を示すのに最適な図として使えばいい。あと、考えられることとして、輪という線より、面で考えると建築的になるかも。メビウスの面 とか。
day
梓設計
東孝光
アトリエ・ワン
阿部勤
コメント
阿部仁史
わからないということを理解することも大事
描けないのか?目指すべき文化が見当たらな
コート .pdf
いのか?参照すべき建築が見えないのか? 9 坪ハウス "Tall"
Type
04 建築計画2_ 集合住宅 _03 東雲キャナル
G-2
から手をつけてよいかわからなくなってしま
います。ですので、どこら辺が進んでいて、
04 建築計画2_ 集合住宅 _05 アパートメント
どこらが行き詰っているか、一度紙に書き出
1.pdf
してみてはどうだろうか?問題点がリスト
_06dancing_trees_singing_birds.pdf
分けにして括ることで、考え方が交通整理さ
れるということもあろう。もちろん、どこら
SOB
前の月
菅野美術館
WHOPPER
ようこそ 長門 宏明さん
2008/9/28
Subject
2008/9/25
みちのく風土館
アルティファータ
08 建築・地域プロジェクト特論
2008/9/22
08 居住環境デザイン演習
2008/9/20
08 建築設計情報特論
2008/9/19
n-house
しらさぎ橋
ば、私たちからもアドバイスもできるだろう。
クリック
カド 001
この課題の最初に街の問題点を見つけ出すと
クローバーハウス
いう診断書を作成しましたが、あれは私たち
コントワール青葉亭
が設計するとき、デザインをするときにも有
08 建築設計情報
2008/9/18
宮崎県総合運動公園高架水槽
08 建築計画
2008/9/17
宮城スタジアム
08 修士論文
2008/9/16
08 Diploma
2008/9/15
07 建築設計リテラシー
2008/9/12
ネージュ ルネ フルール 雪月花
効です。受験勉強のときのようにただ答えを
関井レディースクリニック
考えるというのではなくて、問題から考えて
遅くなりました。申し訳ございません。
松島ヨットハーバー・公園事務所
07 建築計画と構造 .pdf
青葉亭
読売メディア・ミヤギ ゲスト ハウス
07 建築計画と構造 _ 免振 _ 制振構造事例 .
苓北町民ホール
08 建築計画と建築内外環境と設備 .pdf
有馬裕之
アルセッド建築研究所
09 建築計画と材料 _ 構法 .pdf
飯田善彦
11 建築計画 _ 特別授業 _ 環境共生 .pdf
11 建築計画 080707 深川特別講義 .pdf
昨日の提案
wed
thu
2
fri
3
sat
4
Project Date
5
2008/9/11
共通掲示板
2008/9/10
シラバス
2008/9/8
建築作品データベース
2008/9/5
Project Date
8
9
Project Date
10
Project Date
11
16
Project Date
17
Project Date
18
24
Project Date
25
Project Date
・途中過程
12
13
today
途中過程
Information
石井修
7
DGN
池原義郎
伊藤喜三郎
tue
ファイルをダウンロード
08 居住環境デザイン演習
五十嵐淳
池辺陽
mon
1
Subject
安藤忠雄
10 建築計画と生産・施工システム .pdf
sun
AI
荒川修作
新居千秋
次の月
2008/9/30
XX-BOX
辺を悩んでいるという問題点が洗い出せれ
pdf
7月
M 歯科医院
Location
けばよいわけだし、漠然としている問題を小
新規データアップロード
M- ハウス
アップできば、後はそれを一つ一つ解いて行
04 建築計画2_ 集合住宅
Project Management
I-house
Chronological
それだけでパニックになってしまって、どこ
ス .pdf
Project Management
AIP
C-house
わからないことが一気に押し寄せてくると、
04 建築計画2_ 集合住宅 _04 ヒルサイドテラ
06 建築計画4_ 設備コア形式 .pdf
2008/07/10
鈴木英明 赤堀忍
だと思います。どこに迷っているのか?絵が
06 建築計画4_ 架構式構造 .pdf
day
小谷野舞香 タイトル:迷子
日時:2008/07/09
06 建築計画4_ 事務所建築を中心に .pdf
長門 宏明
喜多村佳典 大倉健 Project
04 建築計画2_ 集合住宅 .pdf
05 建築計画3_ コミュニティ施設を中心に
from
大貫結衣 相田武文
アーキテクストファイブ
コメント
04 建築計画2_ 集合住宅 _02 森山邸 .pdf
修士論文
大川郷 成富康朗 記入者
pdf
title
name 大塚駿亮 す。
01 建築計画ガイダンス
User
chat
2:00 ∼ 3:00
クリック
クリック
Project
第一課題
14
Project Date
15
21
Project Date
22
Project Date
Project Date
19
Project Date
20
「住宅設計」
提案・設計
Chat
Progect Management
第二課題
「私のつくる街の診断書」
建築データベースにアップされたデータが表示され
る
提案・設計
Chat
23
26
27
Progect Management
別ウィンドウ
User
name chat page
大川郷 大貫結衣 喜多村佳典 小谷野舞香 鈴木英明 Project Date
28
29
Project Date
30
31
竹内慶太郎 竹下悦子 AAA
中島彩 吉田新 大塚駿亮 久木野陽一 成富康朗 宮地洋 上野翔 アポイントメント作成
総合ミーティング作成
Back to today -> 2008 / 7 / 9
大倉健 作品名 菅野美術館
設計者 阿部仁史
主用途 美術館
竣工年 2006
所在地 宮城県
敷地面積 建築面積 階数
構造
素材
大野剛 ファイルをダウンロード
ファイルをダウンロード
BBB
CCC
DDD
EEE
第五章
第五章
建築設計授業での実践と検証
建築設計授業での実践と検証
68
第五章
建築設計授業での実践と検証
WLS を再構築した上で,2008 年度建築設計リテラシー(2 年後期 選択 受講生 20
5-1
提案の実践
名)において提案した支システムを実践,検証する.
検証方法
本年度の WLS の有効性について検証するために以下の項目から分析を行った.
1,受講生から得られたアンケート結果
2008 年度建築設計リテラシー第 1 課題から第 7 課題までを対象に,アンケートを
実施した.そこで得られたアンケート結果より検証を行う.
2,Project Management 機能のログから抽出したデータ
Project Management 機能を使用して,情報を整理・管理・共有を有効的に行って
いるかを判断し,検証する.
分析視点
分析視点は主に以下の点である.
「設計プロセスの一元管理の影響」
設計情報の整理・管理に対する受講生の意識と取り組み.
Ⅰ.「情報整理・管理」
複雑化した設計の情報群を整理・管理しながら,フィードバックやループが発生し,
設計の質を高めているか
Ⅱ.「情報共有」
共同設計において共通のプラットフォーム上で,情報共有しながらコラボレーショ
ンできているか
69
第五章
建築設計授業での実践と検証
2008 年度建築設計リテラシーの授業概要
5-1
提案の実践
2008 年度建築設計リテラシーのスケジュール
第 1 課題
個人設計
9/17~10/1
第 2 課題
個人設計
10/1~10/15
第 3 課題
個人設計
10/15~11/5
第 4 課題
個人設計
11/5~11/19
第 5 課題
個人設計
11/19~12/3
第 6 課題
個人設計
12/3~12/17
第 7 課題
共同設計
12/17~1/21(冬期休業を挟む)
2008 年度建築設計リテラシー授業進行
建築設計リテラシーは,課題出題,作品提出,講評という流れで行われる.課題
出題時には,その課題の敷地データや参考資料が提示される.受講生は講評前日ま
でに作品を仕上げ,提出する.課題提出までに,衣袋研究室の WLS を使用し,授業
日以外でも提案を WLS 上にアップロードし,教員,授業 TA からのエスキスを受ける
ことができる.尚,第 7 課題は共同設計となっている.本年度は第 4 章で提案した
システムを導入し,設計に関わる情報の一元管理の重要視を試みる.
【図 5-1
2008 年度建築設計リテラシーシラバス】
70
第五章
建築設計授業での実践と検証
アンケート
(1)Project Management 機能
1-1. 個人設計において Project Management 機能は使用しましたか.
いいえ
10
はい
いいえ
はい
10
1-2. 1-1 で「いいえ」と答えた方にお尋ねします.使用しなかったか理由を教えて
ください.(複数回答あり)
・必要性がなかった.
・USB メモリでデータを管理していた.
・使い方が分からなかった.
・他人との情報共有の嫌悪.
・手間がかかる.
・firefox 環境に対応していなかった.
5
5
4.5
4
3.5
3
2.5
2
2
2
1.5
1
1
1
1
0.5
firefox環境に対応していなかった
手間がかかる
他人との情報共有の嫌悪
使い方が分からなかった
0
USBメモリでデータを管理していた
提案の検証と考察
必要性がなかった
5-2
71
第五章
建築設計授業での実践と検証
1-3. 1-1 で「はい」と答えた方にお尋ねします.個人設計において,節目ごとに
Project Management 機能を使用し,プロジェクトで発生した情報の整理・管理
を行いましたか.
いいえ
5
はい
5
はい
いいえ
1-4. 1-3 で「いいえ」と答えた方にお尋ねします.どのようなことに対して Project
Management 機能を使用しましたか.
2
2
2
1
1.5
1
0.5
有効的な使用方法がわからなかった
0
自分の作品をjpgで見せる時に使用
提案の検証と考察
データの保存
5-2
72
第五章
建築設計授業での実践と検証
1-5. 1-3 で「はい」と答えた方にお尋ねします.個人設計において,情報を一元的
5-2
提案の検証と考察
に整理・管理することで,フィードバックやループが起き,設計の質が向上し
たと実感しましたか.
はい
1
はい
いいえ
いいえ
4
1-6. 1-5 で「いいえ」と答えた方にお尋ねします.何故設計の質が向上したと実感
しなかったのですか.
・一課題,二週間という短期間のため,フィードバック等は行わなかった.
・情報の一元管理による設計の進め方を学ぶ機会(授業等)がなかったため,機能
の重要性がわからなかった.
・データを上書きしていたため,過去のスタディに振り替えることがなかった.
・自分の PC 上でデータを管理し,機能を使わずとも設計の質は向上できたから.
1-7. 1-5 で「はい」と答えた方にお尋ねします.どの課題で,どのように設計
の質が向上できたかを詳しく教えてください.
・それまでやってきたことを,カレンダーで見ることができ,次回設計をするとき
に参考にできた.
1-8. 個人設計において,Project Management 機能は有効だと思いますか.
有効ではない
2
普通
10
有効である
8
有効である
普通
有効ではない
73
第五章
建築設計授業での実践と検証
個人設計における Project Management 機能についての考察
5-2
提案の検証と考察
1-1 より,設計過程において Project Management 機能を使用した学生は半々で
あった.しかし,1-5 より,機能を使用して,設計の質が向上をしたと実感し
た学生は 1 人だけことがわかった.
1-2 より,Project Management 機能を使用しなかった主な理由として,
・USB メモリでデータを管理した
・使い方,必要性がわからなかった
と回答している.また,1-4 より機能を使用したが,情報の整理・管理を行わ
なかった理由として,
・有効な使用方法が見つからなかった
・データの保存
と回答している.また,1-6 から,機能を使用しても設計の質の向上を実感し
なかった理由として,
・短期課題のため,フィードバックが発生しなかった
・自らの管理媒体を使用し,それだけで設計の質が向上したから
・情報の一元管理による設計の進め方を学ぶ授業がなかったから
と 回 答 し て い る . 授 業 の 性 質 上 , 短 期 間 の 課 題 と な っ て お り , Project
Management 機能使用しなくても,自らの管理媒体(USB メモリ,学内フォルダ
等)で十分管理することができてしまっている.
これらを総合すると,ハードとしての機能だけではなく,その機能をなぜ使う
か,その効果をしっかりと伝える必要があった.これは著者である私の説明不
足もあったが,BIM 概念をしっかりと理解し,情報の一元管理を設計の現場で
実践している設計者に授業を行ってもらう等の必要性が考えられる.意匠設計
においてデザインの教育だけではなく,情報リテラシーの重要性を踏まえた教
育(授業等)の場をつくる必要がある.
74
第五章
5-2
提案の検証と考察
建築設計授業での実践と検証
1-9. 共同設計において Project Management 機能は使用しましたか.
いいえ
1
未回答
1
はい
はい
18
1-10.
いいえ
未回答
1-9 で「いいえ」と答えた方にお尋ねします.使用しなかったか理由を教
えてください.
・必要性がなかったため.
1-11.
1-9 で「はい」と答えた方にお尋ねします.共同設計において,Project
Management 機能を使用し,チーム間で情報の共有を行いましたか.
いいえ
0
はい
いいえ
はい
18
75
第五章
1-12.
5-2
提案の検証と考察
建築設計授業での実践と検証
1-11 で「はい」と答えた方にお尋ねします.共同設計において,チーム
間で情報共有をすることで円滑にコラボレーションが行うことができ,設計の
質が向上したと実感しましたか.
いいえ
8
はい
10
1-13.
はい
いいえ
1-13 で「いいえ」と答えた方にお尋ねします.何故設計の質が向上した
と実感しなかったのですか.
・設計の質は向上したが,チーム間の人間関係により,円滑にコラボレーションお
こなえなかった.
・共有した情報によって,とらえ方が千差万別になり,様々な意見が出て収集がつ
かなくなった.
・チャット機能によって情報共有は十分に行えたため,Project Management 機能を
使用して設計の質の向上は感じなかった.
・他メンバーが利用していなかったため.
・Project Management に載せた時点で作業が終わってしまった気分になってしまう.
・共同設計自体慣れない作業であったため,設計の質の向上には至らなかった.
76
第五章
1-14.
5-2
提案の検証と考察
建築設計授業での実践と検証
1-13 で「はい」と答えた方にお尋ねします.どの場面で,どのように設
計の質が向上できたかを詳しく教えてください.
・ネットワークを利用して設計の質が向上することには疑問を感じるが,project
management 自体の概念は設計を進めるにあたって重要であり,身につける必要が
あると感じた.
・文字だけではなく,グラフィックに情報共有することができた.
・データの種類に縛られずに,いつでも情報共有がスムーズに行えたため.
・学校に行けないときでも,共有できたため.
・グループ一人一人の意見や主張を円滑に伝えることができたため.
・各自のイメージだけでなく,CAD データも共有できるので,ディテールや形状等の
相互理解ができた.
・様々な案を検討できた.またそれを共有し,話し合うことで質の向上ができた.
1-15.
共同設計において,Project Management 機能は有効だと思いますか.
普通
2
有効である
8
非常に有効で
ある
9
非常に有効である
有効である
普通
77
第五章
建築設計授業での実践と検証
共同設計における Project Management 機能についての考察
5-2
提案の検証と考察
1-9 より,共同設計において Project Management 機能の使用率は 90%と高い.また,
1-12 より,機能を使用し,円滑にコラボレーションが行われ,設計の質が向上した
と実感したのは 18 人中 10 人であった.実感しなかった理由としては,
・学生の授業意欲の問題
・共同設計に対するグループ間の問題
と回答しており,Project Management 機能自体の問題は見つからなかった.また,
1-14 より,設計の質が向上したと実感した理由としては,
・文字だけではなく,グラフィックに情報共有できる点
・イメージだけではなく,CAD データも共有することでディテールや形状等の相互理
解ができる点
・これらが場所・時間に縛られない点
と回答している.
これらを総合すると,共同設計という必然的に情報共有・管理をしなくてはいけな
い場面において Project Management 機能はその利点から非常に有効であることが実
証された.特に,今までの画像等のイメージの共有だけではなく,CAD データを共有
することでグループ間に詳細な相互理解が生まれ,設計の質が向上されることが明
確に実証された.
78
第五章
建築設計授業での実践と検証
2-1. 建築作品データベース機能は使用しましたか.
5-2
提案の検証と考察
いいえ 未回答
0
1
はい
いいえ
未回答
はい
19
2-2. 2-1 で「はい」と答えた方にお尋ねします.建築作品データベース機能は有効
だと思いますか.その理由も記入してください.
普通
2
有効ではない
1
非常に有効である
有効である
普通
有効である
5
有効ではない
非常に有効で
ある
11
有効だと思う理由
・写真や図面が掲載されているため.
・用途別,年代別になっているため検索しやすかった.
・授業中に先生が上げた事例の作品をすぐにみることができたため.
・一人の建築家に対して多くの作品が見れたためどのような経緯で設計をしてきた
かをみることができた.
・図書館で資料を探すよりも素早く情報を手に入れることができたため時間を省く
ことができた.
・今まで知らなかった作品を閲覧できるため,参考にする幅が広がった.いろいろ
な建物,建築家に対して興味を持つきっかけとなった.
・膨大な量の情報を一度に閲覧できるため.
・特に目的がなくても気軽に閲覧できるという点が有効だと感じた.
79
第五章
建築設計授業での実践と検証
有効ではないと思う理由又は改善したほういいと思う点
5-2
提案の検証と考察
・ひとつの作品に対しての情報量が少ないため,本を見たほうがいいと感じたから.
・検索機能があまり充実していないと感じたため.
・ない作品があったとき.
・システム上見にくいデータがあったため.
・画像が粗いかったため.
・どの建築雑誌に掲載されているかの情報も同時にわかることができればいい.
・リンク部分をサムネイル等で表示できれば使い勝手があがると感じた.
建築作品データベースにおける考察
2-2 より 85%の学生が建築作品データベース機能を有効であるという意見が得られた.
有効な点として機能の最大の利点である膨大な情報量と情報取得速度があげられる.
一方で,有効ではないという点に関しては,一つの作品に対する情報不足やインタ
ーフェイスの問題があげられる.情報不足に関しては,機能自体 Wikipedia のよう
に集合知によって情報を追加できるので問題ないが,インターフェイスに関しては,
次期管理者に改善してもらう必要がある.
80
第五章
建築設計授業での実践と検証
Project Management 機能のログから抽出したデータ
5-2
提案の検証と考察
ログから抽出したデータは付録に掲載している.そちらを参照していただきたい.
考察
個人設計における Project Management 機能は,ログから抽出したデータを検証し
てもわかるように十分に活用されていないといえる.受講生は,ただデータをアッ
プしているだけであり,それをもとにフィードバックを行った形跡がない.これは,
アンケートからの考察でも述べたように,情報リテラシー教育の充実を図る必要が
あると考えられる.
共同設計ではその利便性から,十分に活用されており,有効性が実証された.
81
第五章
建築設計授業での実践と検証
ツリー状によるビジュアル化
5-4
次期システムへの提案
ユーザーが自分の情報をツリー状にビジュアル化することで,プロセスをより明
確化するの助け,大量のデータの中から必要な情報を取り出すデータマイニングを
容易にする.
【図 5-1
ツリー構造】
82
第五章
建築設計授業での実践と検証
google eatrh api
5-4
次期システムへの提案
google earth api とはブラウザ用プラグインのことである.これは,google earth
の 3D 画面をそのまま Web ページに埋め込むことができる.これにより,ユーザーが
使用するローカルのパソコンに google earth がインストールされていなくても,サ
ーバー上から google earth を閲覧できる.また,データベースとの連携により,ユ
ーザーが KMZ ファイル(google
earth のファイル形式)をデータベースにアップし,
蓄積していくことで google earth の情報共有が可能になるかもしれない.
【図 5-1
google earth api】
83
第六章
第六章
総括
84
総括
第六章
6-1
本研究は,衣袋研究室において 10 年間という長い年月を経て,
今日に至っている。
総括
情報化の世界は日々進化している.今後も Web ベース型の設計支援システムの構築
と実践を繰り返していく中,新たなツールの可能性,新たなデジタル環境の取り組
み,より効果的な建築設計(教育)環境の構築を目指していくことが必要である.
85
総括
参考文献
参考文献
参考文献
86
参考文献
●芝浦工業大学大学院:「修士学位論文」
参考文献
「WWW を利用した建築設計教育に関する研究」岩崎庸浩 2004
「Web ベースコミュニケーションシステムにおける建築設計教育支援」飯島貴広
2006
「建築設計教育支援システムの開発と更新に関する研究」
高木雄介 2007
●日本建築学会(編):「設計方法」 彰国社 1972
●日本建築学会(編):「設計方法Ⅵ 設計方法論」 彰国社 1981
●日本建築学会(編):「設計方法Ⅴ 設計方法と設計主体」 彰国社 1989
●斗光 佳輝:Access ユーザーのための SQL Server7.0/2000 移行ガイド
●宮坂 雅輝:JavaScript ハンドブック 1998
●Web ユーザビリティー・デザイン 石田優子 2007
●使いやすさのためのデザイン 山崎和彦他 2004
●PHP×PostgreSQL で作る最強 Web システム 石井達夫 2003
●PHP ポケットリファレンス 大垣靖男 2003
●PHP ハンドブック 伊藤浩一 2002
●スタイルシート辞典 ㈱アンク 2002
●JSP/PHP/ASP サーバサイドプログラミング徹底比較 山田祥寛 2002
87
謝辞
謝辞
88
謝辞
WWW を利用した建築設計教育は,芝浦工業大学システム工学部環境システム学科
衣袋研究室において,継続的に行われてきた研究の上に成り立つものです.本研究
の取り掛かりから遂行,及び論文の作成において多くの方々からご指導,ご協力を
頂きました.皆様に心から感謝致します.長年に渡る研究の集大成である Web
Learning Studio の研究の一環に携わる事が出来たことを大変光栄に思います.
衣袋洋一教授には,大学院 2 年間を含め,大学時代より多大なるご指導を頂きま
した.今の自分があるのは,衣袋教授のご指導によるものだと実感しています.深
く感謝致します.副査である相場亮教授,木本健二教授には,本論文に関しての的
確なご指摘,ご意見を頂きました.厚く御礼を申し上げます.
衣袋研究室・建築研究会の同輩,先輩,後輩,OB の皆様には多くの支援をしてい
ただきました.この場をお借りして感謝の意を表します.研究室の仲間である大槻,
榎本,あまり仲は良くなかったけど君たちがいたから楽しい大学生活を送れました.
ありがとう.
論文作成において,膨大な量のデータを取りまとめてくれた小松君,建築作品デ
ータベースを作成するために手伝ってくれた M1,4 年生の皆さん,本当にありがと
うございました.また,建築設計リテラシー受講生の皆様には,新システムを用い
たシステムの実施,アンケートの回答にご協力頂くと共に,沢山の貴重なデータ,
アイデアを提供して頂きました.この場をお借りして感謝の意を表します.
最後に,多くの支援を尽くしてくれた家族に御礼を述べ,謝辞に代えさせて頂き
ます.
89
付録
付録
90
Calender
All Data
Data
September
9/24∼10/1
24
25
26
27
28
30
Project Data
・T house_jpg
29
Project Data
・情緒障害児短期...
Project Data
・T house_jpg
第一課題
30
Project Data
・T house_jpg
1
Project Data
・情緒障害児短期...
Calender
All Data
Data
September
第二課題
10/1∼10/7
1
Project Data
・イメージスケッ..
1
Project Data
・イメージスケッ...
2
Project Data
・イメージスケッ...
3
Project Data
・見えない秩序03
3
4
Project Data
・見えない秩序03
Project Data
・ラフモデリング
5
Project Data
・shot_01
6
Project Data
・ラフモデリング
7
Project Data
・模倣から創造へ
Project Data
・模倣から創造へ
Project Data
・模倣から創造へ
7
Calender
All Data
Data
October
10/8∼10/14
8
9
10
Project Data
・エスキス内容
11
11
Project Data
・エスキス内容
14
Project Data
・ちいさなハコの...
12
Project Data
・ちいさなハコの...
13
Project Data
・ちいさなハコの...
14
Project Data
・ちいさなハコの...
第二課題
Calender
All Data
Data
October
10/15∼10/21
15
Project Data
・即日イメージ
16
16
Project Data
・即日イメージ
17
Project Data
・レスポンスを受けて
17
Project Data
・レスポンスを受..
Project Data
・第一週エスキス
18
Project Data
・第一週エスキス
19
20
21
Project Data
・第一週エスキス
第三課題
21
Calender
All Data
October
Data
第三課題
10/22∼10/28
22
23
Project Data
・エスキスを受けて
23
Project Data
・エスキスを受け..
Project Data
・エスキス内容
24
25
26
27
28
Calender
All Data
Data
October
Project Data
・エスキス2
10/24∼11/4
29
Project Data
・エスキス2
29
30
Project Data
・エスキス2
31
1
Project Data
・エスキス内容
November
1
Project Data
・エスキス内容
Project Data
・エスキス内容
2
4
Project Data
・jenga
3
Project Data
・jenga
4
Project Data
・jenga
第三課題
Calender
All Data
Data
November
11/5∼11/12
5
Project Data
・即日イメージ
6
Project Data
・即日イメージ
5
7
12
8
Project Data
・虚実の螺旋
Project Data
・エスキス
9
Project Data
・エスキス
10
Project Data
・エスキス
11
12
Project Data
・虚実の螺旋
第四課題
Calender
All Data
Data
November
11/13∼11/19
13
Project Data
・エスキス内容
Project Data
・エスキス内容
13
14
Project Data
・虚実の螺旋
15
Project Data
・虚実の螺旋
15
16
17
18
Project Data
・図書室/遊び場/.
第四課題
19
19
Project Data
・図書室/遊び場/...
Project Data
・図書室/遊び場/...
Project Data
・図書室/遊び場/...
Project Data
・図書室/遊び場/...
Project Data
・図書室/遊び場/...
Calender
All Data
Data
November
11/19∼11/25
19
Project Data
・即日イメージ
Project Data
・即日イメージ
19
20
21
25
Project Data
・森の余白
22
Project Data
・森の余白
23
Project Data
・森の余白
24
25
Project Data
・森の余白
第五課題
Project Data
・森の余白
Calender
All Data
Data
November
第五課題
11/26∼12/3
26
Project Data
・森の余白
26
Project Data
・森の余白
27
Project Data
・森の余白
28
29
30
3
Project Data
・森の余白
December
1
Project Data
・森の余白
Project Data
・森の余白
2
Project Data
・森の余白
3
Project Data
・森の余白
Project Data
・森の余白
Calender
All Data
Data
December
12/3∼12/9
3
Project Data
・即日イメージ
Project Data
・即日イメージ
3
4
5
6
9
Project Data
・壁の向こう側。
7
Project Data
・壁の向こう側。
8
Project Data
・壁の向こう側。
9
Project Data
・壁の向こう側。
第六課題
Project Data
・壁の向こう側。
Project Data
・壁の向こう側。
Calender
All Data
Data
December
第六課題
12/10∼12/17
10
Project Data
・エスキス内容
Project Data
・エスキス内容
12
11
12
13
17
Project Data
・大きな木の下で。
14
Project Data
・大きな木の下で。
15
16
Project Data
・大きな木の下で。
Project Data
・大きな木の下で。
Project Data
・大きな木の下で。
17
Project Data
・大きな木の下で。
Calender
All Data
Data
December
共同設計
12/17 ∼ 1/21
17
18
Project Data
・現状(写真)
CREATOR
・岩間貴昭
19
20
21
22
Project Data
・テーマ
CREATOR
・岩間貴昭
22
Project Data
・テーマ
CREATOR
・岩間貴昭
Project Data
・テーマ
CREATOR
・岩間貴昭
23
Project Data
・テーマ決め
CREATOR
・岩間貴昭
23
Project Data
・テーマ決め
CREATOR
・岩間貴昭
24
Project Data
・スケジュール
CREATOR
・岩間貴昭
Project Data
・テーマ決め
CREATOR
・岩間貴昭
25
26
Project Data
・テーマ決め
CREATOR
・岩間貴昭
All Data
Calender
Data
December
共同設計
12/17 ∼ 1/21
27
28
29
Project Data
・studey AI
CREATOR
・岩間貴昭
29
Project Data
・study AI
CREATOR
・岩間貴昭
30
Project Data
・study CAD
CREATOR
・岩間貴昭
31
January
1
2
3
4
5
Calender
All Data
Data
January
12/17 ∼ 1/21
6
Project Data
・最終課題
CREATOR
・太田成実
7
8
11
Project Data
・イラレ
CREATOR
・岩間貴昭
9
Project Data
・CAD
CREATOR
・岩間貴昭
10
Project Data
・CAD
CREATOR
・岩間貴昭
11
Project Data
・イラレ
CREATOR
・岩間貴昭
13
Project Data
・あるこ
CREATOR
・中村在
12
13
Project Data
・あるこ
CREATOR
・中村在
14
Project Data
・課題
CREATOR
・太田成実
共同設計
Project Data
・aruko
CREATOR
・中村在
Project Data
・AI
CREATOR
・岩間貴昭
Project Data
・CAD
CREATOR
・岩間貴昭
Project Data
・CAD
CREATOR
・岩間貴昭
Fly UP