@kmasahiroYHK （個人的にはふるさと納税を拡大した行政主導のオンライン販売の拡充みたいな形の地方支援の方が、地方そのものにお金を流せてよいと思いますけどね。既に行われている牛乳支援とか。Go toで外資や大手資本の宿泊施設に止まられてもあまり意味ないと思いますし…）
posted at 09:29:34
| Stats | Twitter歴 4,033日（2009/07/02より） |
ツイート数 87,123（21.6件/日） |
表示するツイート :
2020年07月15日(水)16 tweetssource
@kmasahiroYHK 5年とか10年とかそれくらいのスパンで見れば観光業は戻ると思いますので、全員を他の産業にがっつり移動させる必要はないのですけどね。とりあえずその5年を凌ぐために地方に都心からお金を流すふるさと納税的な仕組みを作れるのか、そこにリソースを使っていくのがよいと思います。
posted at 09:24:13
@MURAIII @sei_hayashi_ 私がまとまった文章を書くための壁役として村井ちゃんに話を聞いてもらわないといかんのだよ。壁になってくれ！自分が面白くても一般的に面白い話か分からんのだ。
posted at 08:38:11
@kmasahiroYHK 話の順序が逆かと。業者が歓迎しても心象的には無理ですよ。経済規模は関係なくて「何しても支えられない」です。状況が全く変わり、それを受け入れないといけない。
検討すべきは「この状況でどうやってお金を稼ぐか」であって「これまで通りの宿泊業を続けたい」はしばらく無理だと思いますね…。
posted at 08:36:55
@MURAIII @sei_hayashi_ いや、それがまさにGitやパッケージ管理の仕組みの話なのですよ。
今のweb開発ってまさに「基準法-施工例-告示」という関係に近い形で「プログラム言語-フレームワーク-ライブラリ」という関係があり、それが有機的に管理できる仕組みが作られているので、これはパクった方がよいと思う。
posted at 08:22:16
どの業界も変わらないなーと思うのは、世の中の変化に対して「自分の仕事を変えないでくれ」という要望だなぁ。
そんなものに補助金を使うんじゃなくて、新しい取り組みの方に補助金を出して欲しい。
posted at 08:19:16
@kmasahiroYHK その宿泊施設のある地域を危険にさらしてまで、今国内を流通する人間を増やすべきだとは思いませんけどね…。
むしろ宿泊施設を助けるために地域全体を危険に晒す必要性はあるのでしょうか？「東京から来ました」と言って街の人から「ようこそ」と言ってもらえるのでしょうか？
posted at 08:10:44
posted at 08:02:51
@kmasahiroYHK 感染症前と同等の再開なんて無理ですよ。他の業界に移るための一時金を出すしかないです。
業界を全て支えるなんて無理ですよ。
転職しても生きていけますけど、お金を求めて死んだらいかんのです。
また観光業が復興してきてタイミングで業界に戻る、で良いと思います。
posted at 07:55:31
へー。「音は補聴器で増幅できるが、言葉の聞き取り能力がダメ。ダメです。聞き取り能力が落ちたら取り戻せないと思っていい。聞き取り能力と、聴力は、別物です。」：補聴器ははよ使ってくれ https://anond.hatelabo.jp/20200714232736
posted at 07:52:33
「感染リスクのある行動は避けるべき」という一般人の行動に対する批判ではなく「公的な補助を行うために感染リスクのある行動を要求する」という政治的な手段に対する批判ですね。
規制がない限りは、個人が自分の判断で旅行に行くのとかは良いと思います。
posted at 07:50:22
@kmasahiroYHK 「お金を受け取るために」接客しないといけないって話ですね。休業補償なら接客しないでお金を渡せるはずなのに、補助金以上の消費促進を見込んだという部分が悪手だと思います。
スーパーや小売り業は医療と同じくらい大切な生活インフラなので、そこは万全の体制で業務にあたってもらいたいです。
posted at 07:43:52
@MURAIII @sei_hayashi_ web開発業界のGitやパッケージ管理の仕組みを導入すればよいんだよー。そしておそらく実際そうなるはず。
それに業界がついていけるかだねぇ。
posted at 07:36:36
業界が死んでもそこで働いてた人は他の業界に移動できるけど、人が死ぬのは避けないといけない。
だから問題なのは「今の仕事を失ったら死ぬ」という日本っぽい1本道の人生観なんだろうなぁ。
posted at 07:33:53
経済が死ぬとか観光業が死ぬとか言うけど、補助金を渡すことと旅行を促すことは同義じゃないよね。一部助成してより大きくお金を使ってもらおうって話だと思うけど、感染症が広まる中で接客しなさいってお達しは頭悪いんじゃないの？って気がする。
posted at 07:24:50
この次男くんの話、人の認識を理解する上で非常に大切な話だよなぁ。
posted at 07:09:32
2020年07月14日(火)17 tweetssource
@sei_hayashi_ @MURAIII 村井さん！どういうことですか？
posted at 21:30:53
昔の松川さんと藤村さんのやり取りを思い出しました。
個人的には建物そのもののあり方を建築と捉えるか、建物を見出す時の人の認識まで含めて建築と捉えるかの違いなような気もします。 https://twitter.com/sei_hayashi_/status/1282470938424930306…
posted at 19:55:06
@1988_nakajima じゃー何かやりましょう！
posted at 16:00:21
@warapuri これかと思いました。自動補完してたんですね…
https://twitter.com/hal_sk/status/1281853581218336768?s=21… https://twitter.com/hal_sk/status/1281853581218336768…
posted at 15:34:07
@yontengoP こういうの。
https://www.silhouette-illust.com/illust/19946
posted at 14:38:08
@yontengoP ¥0じゃないかなぁ。
posted at 14:37:22
@Takeru_y313 やりたいことはその方向で良いのですが、それを実現するのにRevitで制御しない方がいろいろと楽だとは思います。BIM360の特定の名前のフォルダ内のrvtデータファイルに一律で同じテンプレートを適応する仕組みとかをForgeで作るとかのが、仕組みとしては良さそうかな、と。
posted at 09:36:58
@kokaraka 設定項目の量はあまり問題ではないかな、と思います。設定項目へのアクセスの制御の問題ですかね…。
クラウドを利用したAutoCADの設定管理とかは今でも需要あると思います。
posted at 09:34:34
査読できるのかなぁ。
posted at 08:18:09
だから今BIMに取り組んでいる会社が考えるべきは、ソフトウェアのRevitから設定関係の情報をできるだけ剥がすこと。
ファミリやプロジェクト情報、図面の設定やオブジェクトの集計ロジックなどを別画面で閲覧・操作できるように剥がしていけばよい。
業務の整理とシステムのMVCの整理を重ねれば良い。
posted at 07:41:34
Revitだと逆で、画面は基本一つでユーザーが必要に応じてそれぞれの制御ロジック情報を設定しにいく必要がある。
Model管理がバラバラになっていて、それがView側の初期UIから辿れるような作りになっている。
これは、ソフトウェアにはユーザー属性って考え方がなかったから仕方ない問題なんだよね。
posted at 07:34:46
すこし拡張して考えると、「ユーザーに何を触らせるか」と「ユーザーに触らせる情報の制御」を切り分けるという話なんだけど、クラウドだと原則「ユーザー属性に応じて画面を出し分ける」という制御になる。（Modelをシンプルにしてユーザーごとに画面を切り分ける）
posted at 07:30:56
例えばアプリケーションを実装する時のプログラム構築の考え方として以前からMVCモデル（Model/View/Controller）が提唱されていて、ユーザーの画面とアプリの制御ロジックを分けて管理するフレームワークがあったりする。
https://qiita.com/s_emoto/items/975cc38a3e0de462966a…
posted at 07:28:05
@MURAIII ふぁ！
posted at 07:27:45
ちょっと自分の書き方が悪いなーとも思うけど、これはRevitの問題というよりもハードにインストールして利用するソフトウェアの問題だよね。
今ではクラウドサービスが当然のようになってるから自分としては改めてRevitを触って変に感じたんだけど、PCベースで作業してると気づかないのかもしれない。
posted at 07:19:10
Revitって今振り返るとかなり不思議なソフトウェアで、DBの保持と定義、データ入出力とその画面の定義、みたいな今だったら切り分けるであろう機能が一体化してるんだよねぇ。
だから共有パラメータみたいな重要な機能がデータ入力の影に隠れてしまう。
https://www.youtube.com/watch?v=lwg9yYK-t2s…
posted at 07:15:37
んー、気になる。パースの付いた円は楕円になるのか。なんか証明できるのかなー。 https://twitter.com/tokoritomotori/status/1282346457824034819…
posted at 05:38:44
2020年07月13日(月)5 tweetssource
https://adndevblog.typepad.com/technology_perspective/2020/07/design-automation-command-line.html…
posted at 19:29:26
@kamex それ知ってる人がやってるやつだ。
posted at 05:42:46
「建築を依頼する人が、自分が手に入れる建物のことをどれくらい把握するべきなのか」という問題なのかもしれない。
車なんかと比較すれば、理想と現実の間の落とし所を探る方向になるだろうから、まぁそれは面白くはない議題のかもしれない。
posted at 05:08:56
「商品化」に対しては「体験」という回答がここ10年くらいで出てるわけだけど、体験を建築に持ち込む時は「空間を体験する」だけじゃなくて「設計を体験する」という状態を目指す必要があるのかもしれない。
そう考えると、自動設計が悪いのではなく、意図が見えないことが問題なのだろう。
posted at 05:05:47
建物の自動生成、あれは建物を建てる上での合意形成はどうあるべきなのか？って問いが抜けてる感じに見えてしまうんだよな。
建築のオブジェクトはルールの範囲で構成されてはいるから計算可能だとしても、建物を利用する主体がその建物に対して何を評価することができるのだろう。
posted at 05:01:34
2020年07月12日(日)5 tweetssource
@MURAIII BIMのルール作りも業務のマネージメントも全ては地続きなのだよ…みんなで同じ認識を作らないといけないんじゃ…
posted at 16:47:10
「仕事」って認識を合わせるのがすごい難しい。「自分は仕事ができる」みたいに自分の視点でだけ仕事をしてる人と一緒に仕事すると、自分に渡ってきた業務の処理にしか注目してなかったりする。
そのままマネージメント職になるとなおたいへん。
posted at 16:37:17
@Takeru_y313 BIM360のデータを見れる（いじれる）ので、その辺りを触れるようにすると面白いんですけどね〜。立体よりも属性を見れるのが良いですよ。いろいろ使えそうで。
友人に教えてもらいましょう。
posted at 16:08:01
@Takeru_y313 Forgeはプログラムを勉強しないといけないからねぇ。できる人を捕まえていろいろ聞けると良いんだけども。
サンプル動かしてみるくらいなら簡単なんですけどね。
posted at 15:45:43
@Takeru_y313 そのためのForgeですな。ルール作るくらいなら作業ごとに専用画面を作ってやれること縛ってしまえば良いと思います。
posted at 15:19:27
2020年07月11日(土)5 tweetssource
商品化の問題とは、認識の作り方の問題だと思うと解決できそうなんだけどなぁ。
posted at 23:21:08
建築の商品化が嘆かれたのが80年代だったと思うのだけど、「自動設計によって作られた住宅を選択する」というシステムは評価が難しいなぁ…。技術者の夢、という感じがしてしまう。
posted at 23:18:37
テレビは本当に薄くなったなぁ。
posted at 12:02:21
これはズルいw
posted at 11:20:56
なるほど感。これは大事なことだ。
posted at 11:19:59
2020年07月10日(金)16 tweetssource
Revit の設備のトレーニング教材が新しく追加されてる。
http://bim-design.com/learning/mep.html…
posted at 06:59:02
そして大事なのは、これまでの業務手順ですら疑えるということ。プログラムに任せることができる部分はこれまでよりも頻繁にチェックを行うことが可能になる。コストの問題で回数に制限があった作業が低コスト化によって大量に行えるようになることで何を変えられるのか。
posted at 06:12:48
今の業務が今の図面に反映されているのは確かだけど、今の図面をBIMで再現できれば既存業務に対し十全であるはず、という話になりがち。これは本末転倒な状況なので避けないといけない。
posted at 06:05:53
BIMが難しいのは、自分たちの業務の言語化、ルール化を行う必要があり、その後それに従ってBIMモデルを作るためにシステム構築をする必要があるという進め方になっているから。言語化されていなければシステムを構築できない。
けど多くの場合は業務を図面に重ねてしまうからうまくいかない。
posted at 05:59:36
話が逸れたけど、BIMで積算を考える時に最大の障害は「自分たちが積算に求めている精度の言語化」であり、次いで「精度に沿ったBIM入力手法の構築」になる。これはつまり①BIMモデルの情報変換の部分にかかる話で、そこまでできれば②集計、④図面化はさほど問題ではないように思う。
posted at 05:53:20
（実際、普段の概算積算では部屋面積に特定項目を計上するだけで概算しているような状況なのだから、BIMだからといって精度を求めるのではなく、今の業務を簡単にする方向で動くほうがよいんじゃないかと思ったりする）
posted at 05:49:15
積算精度は様々で、実際の施工で想定される全ての部材を厳密にBIMモデルとして入力し精度の高い積算を志向する手法（デジタルツイン原理主義的手法）もあれば、割り切って特定のサイズの柱があった場合に対して仮定の部材数を想定して数字として計上し概算する、という手法もある。
posted at 05:46:46
RC造の柱1本を取り上げて見ても、意匠設計的には「柱」で良いわけだけど施工まで見据えれば構造や法規に対応した条件を満たした上で配筋や型枠など設置までに必要な全ての部材を洗い出さないといけない。
これは積算のために精度をどのレベルで確保するのか、誰かが決めることを意味する。
posted at 05:41:29
そのため設計用BIMモデルから積算を行うには、①積算に対応したBIMモデルへの情報変換と、②建材情報の集計、③それだけでは不足する情報の補完、④それらの図面化と4つ程の異なるシステムを考えないといけない。
posted at 05:37:33
例えばBIMで簡単な積算することを考えてみると、BIMモデルと現行の積算ルールは必ずしも対応関係にないことが分かる。建材単位でBIMモデルが入力されていれば部材数を洗い出すことは簡単だが、積算≠部材数ではない。そしてまた、建材単位でBIMモデルを入力するのも非常に手間だ。
posted at 05:34:39
BIMデータというのは、要素単位で入力された各要素データの集合（データベース）が本体で、図面というのはそのデータベースをどう切り取るのかという観測手法の定義なのだけど、これらをまとめて「BIMソフトで可能なこと」と理解されてしまっているような気がする。
posted at 04:38:13
相手が口に出した言葉と、相手が実際に必要にしている情報が違うことは良くある。
posted at 02:59:09
パプリカっぽい
posted at 02:52:53
あ、これ既視感あるな。たぶんあの辺のグループの犯行な気がする。
posted at 02:10:50
建設業界はデジタル技術を「体系的に教えてない」ってより、技術を「体系的に使えてない」って感じるなー。各分野ですごいおサムライがたくさんいる感じ。
posted at 02:07:32
サムライ駆動開発。 https://twitter.com/toyoda_noiz/status/1281227524505128962…
posted at 02:00:11
