00:04
はい。11月3日木曜日、時刻は朝9時を回りました。
なんか最近ですね、しっかり寝たいと思う日に限って、あんま寝れなくて、次の日なんかめっちゃ早く起きてしまうんですよね。
今日もなんか6時半に起きてて、二度寝したかったんですけど、相変わらず二度寝できなくて、うーんって悶々してました。
はい。どうでもいいですね。はい、おはようございます。ひめめのkeeth孤独は肌です。
では本日も朝活を始めていきたいと思います。
はい。今日は、昨日読んでた記事ですね。
26 Things from 101 Things I Learned in Architecture Schoolっていう記事ですね。
タイトルの通りです。そういう101の物事ですね。
アーキテクチャ、建築学校から学んだ101のことっていうところですね。
それの26のアイディアをピックアップして、解説とか感想を書いているブログがあって、それを読んでいった感じです。
今日はそれの続きですね。
昨日は51番目まで読んだので、26のうちの51番目なんですけど、これが何個目か数えてなかったんですけど、
今日はその続き、57個目からやっていきたいと思っております。
では早速読んでいきたいと思います。
57番目の物事、アイディアですね。
いきましょう。
スタジオプロジェクトの効果的な口頭発表というのは、一般的なものから始まり、具体的なものへと進んでいきますというのが57巻のアイディアです。
もしあなたが次のカンファレンスでの講演のための無料のアウトラインというのが必要であれば、これをご利用ください。
あるいは、次の車内デモのためにでもSNSを買えますと。
これはかなりすごいことで、私たちがやっていることの多くが人間を道連れにすることだという考えをほどめかし始めているのですと。
改めてタイトル読むと、スタジオプロジェクトの効果的な口頭発表というのは、一般的なものから始まり、具体的なものへと進んでいく。
このやり方をしていくというのはすごくいいことですよということですね。
これがトークの内容だったりとかお話の中に人をどんどん引き込んでいくというか、その中にディープダイブ化させるようなほのかし始めるというテクニックだそうですね。
でもこれは僕も結構プレゼンやるときによくやりますね。
スライドとかプレゼンやるときに、自分はストーリーを考えてプレゼンを作るようにしているんですよね。
今回しゃべりたかったのは1時間でも別に15分もしくは5分のLTEでも、今回何を伝えたいのかなというところのゴールを設定したときに、そこまでのストーリーを書きますね。
ストーリーを書くときに、やっぱり最初は抽象的なところというか一般的なものから入って、最終的にどんどん突っ込んでいって、最後またそれを結論に持っていく。
僕は最後の最後にもう一回抽象化するというところですね。
皆さんも同じかもしれないですけど。
最初から具体的から入ると情報量がかなり増えたり、ニッチとかエッジケースだったりするので、実はあんまり聞いてて頭に入らなかったりすることも多かったりします。
もちろん理解はしやすかったりするし、なるほどねってなるんですけど。
とはいえ、そればっかりだと人間の脳は疲れるので、まずは一般的な抽象的なものから脳みそ的に理解できるではなく、感覚的に僕もそういう経験あるわという話から入るのはすごく共感を得られるのでいい話かなと思いました。
03:12
今のが57個目でした。
続いて60個目のアイディアですね。
記事中の個数で何個目かわからないですけど。
伝統的な建築というのは、ベース、ミドル、トップという3部形式を採用しているというところですね。
こちらはウェブサイトも同じだというふうに解説されていて、ヘッダータグ、メインタグ、そしてフッダータグの3つですというところですね。
これと同じような建築の流れをウェブでもやってますよということだそうですね。
ベース、ミドル、トップなんですね。
ヘッダーがベースで、メインがミドルで、フッダーがトップというわけでは多分ないと思いますけど、そういう3部構成の考え方をウェブも実はやってますよというお話でした。
ちょっとこれはこれだけしか書いてないので、抽象的すぎるので本当は本を読んだ方がいいと思います。
具体的にどういうことというのは解説されていますけど、コンセプトとか概念的にはそういうことをやってますよというのを理解しようという感じですね。
では続いて61個目ですね。
61個目はLess is moreだそうです。
ルード・ビッフィ・ミース・ファンデル・ローエという方が語られていますと。
とても良い一言ですね。分かりやすいですね。Less is moreですということです。
今でもいいアドバイスだなというふうにこの方もおっしゃってますね。
これはちょいちょい聞いたことがありますよね。Less is moreというのは。
多すぎるよりは全然いいですからね。というところでした。
では続いて、これに関しては僕が語るより世間一般にたくさん良い記事があったりするのでそこから見てもらったらいいと思います。
何かお勧めの記事あったかな?Less is moreで何かお勧めの記事とか。
ちょっと出てこないですけど、ググっていただけたら大量に出てきますね。Less is moreというところですね。
要は情報量が多すぎても良くないというか。
多いより少ない方が人の想像力に訴えかけたりとか、物事がシンプルになるのでLess is moreというのは本当に豊かだという意味ですね。
Moreというのは少ない方がより多く何かがあるというわけではなくて、少ない方が豊かですよというところですね。
これはちょっと有意物論とか実際の現実だとちょっと考え方が逆転するかもしれないですけど、
物が多い方が豊かじゃないという考え方もありますけど、実はそうではないですよね。
これはちょっと余談なんですけど、家の中の物が多い人の考え方と結構似てると思ってて、
安物に税金を失いみたいなその話がしたいわけではないですけど、
本当に自分の人生とかライフというレベルで満たされている、豊かであるというものは自分の中で本当にいいものというか、
自分が一番気に入っているものばっかりを集めるものと実は満足するよねという話です。
すべてのものが好きだから、目に映るもの全部が自分の中でハッピーですよね。
そうなると好きなものを本当に絞っていくことに絶対なると思うんですよ。
06:01
心からこれ好きっていう、これずっと使い続けたいみたいなものってそんなに実は多くなくて、
結果的に物は減っていくはずなんですよね。
というところで、レッスンのいつもの考え方。
僕、いつも聞くたびにこの考え方がいつも思い起こされる、想起されるという感じですね。
そのところでした。余談はさせておき、続けていきましょう。
続いては、連続しますね。68個目のアイディアです。
断面でデザインしよう、だそうですね。
デザインインセクション、セクションなので断面というかは難しいですけど、
しっかり区切って区切ってデザインしましょうというところだそうですね。
で、部屋から部屋へ、例としては部品から部品、もしくはページからページですね。
というのを部屋から部屋へ設計するのではなく、
建物、製品全体の断面の中で間取りとかアイディアがどのように収まるかというのを視覚化しましょうというふうに言っています。
なるほどですね。
よく考えたら、僕らはコンポーネントとかアトムズレベルから物を作ることって結構多かったりするし、
逆にページからページっていうところに設計することは確かに多いかもしれないですけど、
もう一つのウェブサイトという中で区切っていくってことですよね。
間取りアイディアがどのように収まるかっていうのを考えたり視覚化していくっていうことですね。
これは面白いですね。
ここら辺をやるのは本来はUIデザイナーだったりするかもしれないですけど、
僕らエンジニアはそれを具現化、具象化するだけなので、
出てきたものに対してどうやってそれを現実化するかって話に結構尽きると思いますが、
とはいえ、この考え方は設計ですね。
プログラミングの設計の方でも全然使えるアイディアというか発想だなと思いましたね。
なるほどね。
全体をまず見てからですね。
でもコーディングって確かにそうかもしれないですね。
例えばウェブページを作るときにHTMLを配置するんですけど、
ざっくりとヘッダー、メインインフッターですけど、
メインの中でも例えばサイドバーなんちゃらってありますけど、
別に詳細なものを最初からガタッと作るのではなくて、
とりあえずdivタグをゴンゴン置いていくんですよね。
置いてって中にとりあえずテキストをポンと置いておくと。
ここからこう、ここからこうみたいなのを、
ざっとHTMLの構造上でマークアップで置いておきます。
ただそれだとスタイリング的に段組みとかできてないので、
そういうのは一旦絵で起こすとか、
ラフでも手書きでかって適当に書いておくといいので、
そういうのを書いておいて、
その構成のようにまず一旦CSSで段組みをすると、
FlexboxでもいいですしGridでもいいので、
軽くざっくりとした絵と、絵じゃないわ、
色と段組みだけしておくということをやって、
そこからさらに中の詳細な文言だったり配置だったり、
画像だったり置いてあったりして、
実装していくというのをよくやりますので、
全体を見てからどうやって収まるかというのを、
具現化していくという、
結局この筆者の方がおっしゃっていることは結構一貫していて、
まず抽象化から入って、抽象的なところから入って、
具象に押し込んでいくというところですね。
徹底しているような印象がありますし、
この方も実際そうなのかもしれないですね。
建築自体がそうなのかもしれないとは思いました。
大きいものを作るときって、
小さいものを組み上げていって、
最後ガチャンとやるような印象がありますけど、
09:01
結果それが成功性が取れなかったり、
後からズレがあったときって、
ウェブなら別に修正できなくはないですけど、
ウェブもそうですし、建築もそうですけど、
それの修正の方がコストがめちゃめちゃかかるし、
何なら作り直しぐらいの話になったりする可能性もある。
ウェブの場合は作り直しをしなくても実際動いちゃうので、
いわゆる負の遺産ができてしまいます。
めでたくですね。
とかなるので、
本当は先に全体構成がでかいところから作るらしいですね。
建築というのはそれを作る土台とか足場とか、
作るための周りにもっと大きいものを建ててから、
中の建築を作っていくらしいですね。
そういうのを聞くと、それもそうかもねって言って、
僕はそこからウェブページとかアプリケーションを作る、
開発現場に入るときは、
まずHTMLでリブタグを置いていったりしてから、
中身を埋めていくようなことをするようにしました。
余談に余談が挟まりましたけど、こんなところでした。
デザインインセクションというアイデアでした。
これ、僕好きですね。
いい言葉だと思いますね。デザインインセクション。
ちょっとインプット帳。
続いて、また連続してますね。69個目のアイデアです。
69個目は、根拠のないランダムな仮説だそうです。
ほい。
ということ、根拠のないランダムな仮説。
平面図は組織の組織論理を示し、断面図はその環状体系を具現化すると。
へー、なるほど。
平面図っていうのは建物の組織論理っていうのを示していて、
断面図は環状体系を具現化すると。
ほうほうほうほう。
上から俯瞰するのと横から見るってことですよね。
これは全ページに言えることですが、非常に重要なことです。
前述と51のポイントにちょっと重なりますけど、
プロジェクトを横断的に見ることで、垂直方向のサイドを通して見るよりも、
実は経験についてより多くのことを知ることができます。
へー。
ちょっと考えたことなかったですけど、この考え方面白いですね。
へー、なるほど。
3回目ですけど、平面図ですね。
上から見る図っていうのは建物の組織論理を示していて、
組織っていうかアーキテクチャ的なところですけどね。
示していて、断面図、縦からスパッと切った横から見る図ですね。
縦でスパッと切って横から見た図っていうのは環状体系との具現化するというところでした。
うーん。
ちょっとこの69号のアイディア、根拠のないランダムな仮説と言っていることはあんまり一致しない気がしますけど、
これすごく重要なことですね。
はい。
横断的に見ることで垂直方向のサイドを見るよりも経験値より多くのことを知ることができると。
はい。
ちょっとこの考え方はやったことなかったんで、これ今後ウェブ開発においてのフィロソフィーというか
考え方思想の話につながると思ったので、
これは改めて深掘りしたくなりましたね。
はい。
とてもいい話でした。
じゃあ続いていきましょう。
続いては72個目ですね。
ちょっと飛びます。
72個目はデザインwithモデルズですね。
模型でデザインしましょうと。
モデルでデザインしましょうということです。
ちゃんとモデリングしようという話だと思いますが、
検討中のデザインアイディアをどのようにテストし評価するのでしょうかと。
その答えはプロトタイプです。
12:00
建築模型、プロトタイプというのは素晴らしいツールだというふうに言ってますと。
はい。
確かによく見ますよね。
建築現場とかでもそうですし、いろんな建築の美術展とかあったりしますけど、
必ず模型ってありますよね。
模型を置かないときもありますし、
でも流石こういう有名なものというか、
とても歴史的意義のあるものだったりするのはだいたいプロトタイプ、模型がありますよね。
それと同じことをWebでもやりましょうということですね。
デザイナーさん結構そのプロトタイプ的なものをよく書きますよね。
RAFでもいいしMockでもいいし、
CAMPでもいいし、いろんな名前ありますし、
使い方はそれぞれですけど、同じものを作ってて、
エンジニアの方でも先に実はプロトタイプをガーッと作る。
紙芝居的にデータもAPIとか作るのを待っていなくていいので、
雑にJSONでガッと裏で持っておいて、
とりあえずここのページでこういうアクションしたらこれが出ますとか、
こういう表示になりますというプロトタイプをガッと作って、
それをお客さんに見せたりして、実際にデモをしたり、
意思の疎通を取ったりとか、認識合わせをするとか、
ああだこうだを言うというのはすごくいい話で、
作り終わってから実際に見せたりとか、
コンポーネントレベルでも1週間とかの振り返りで、
スプリントごとにレビューし合う回とかやるかもしれないですけど、
それは別に悪くはないんですけど、
個人的には先にプロトタイプを一回ガッと作って、
紙芝居的に動くようなものを作ってから、
どのようにテストするとか評価をするっていうのはすごくいい話だと思っていて、
本当はですね、開発のフローというのはそういうことをしたいなと思います。
要件定義、要求定義をして基本設計したりとか、
場合によっては詳細設計してとか、
その設計している間にデザインも起こしたりしますけどね。
フロントエンドエンジニアはデザインを起きた後に結構設計をし始めたりするんですけど、
デザインと一緒にプロトタイプを本当は作っていけるっていうのが僕の認識ですね。
フロントエンドの界隈においては工程としてすごくいいことだと思っています。
もちろん工数がかかるし、
初めの方のスタートダッシュが遅いように見えるかもしれないですね。
実際にプロトタイプを作って、そこからさらにまた作り直すみたいな感じなので、
二度手間感あるかもしれないですけど、
実はビジネス的には早いんですよね。
後からかかるコミュニケーションコストをガッと削減でき、
最初の方により詳細かつクリアな情報で作り始めることができるっていう意味では、
実は最初に時間をかけていくほど後で失う時間とか、
あとでかかる工数っていうのはかなり削減できるんですよね。
ここは難しいです。
お客さん的には進んでないように見えるかもしれないですけど。
とはいえ、やっぱりプロトタイプでも動くものができたっていうだけで、
クライアント、お客さん側からするとめちゃくちゃビジネスインパクトが大きいんですよね。
っていうのがあるので、
本当は会社標準としてプロトタイプを一回作ってみせるみたいな工程を挟むように、
本当は僕は標準化したかったりはします。
できるかどうかわかんないですけどっていう感じですね。
というところでした。
デザインウィズモデルズっていうところでした。
モデルっていうかプロトタイプっていうほうがいいかもしれないですね。
ちなみにアーキテクチャルモデル、
Wonderful Toolsっていう別の記事のリンクもここで貼られてますので、
もし興味ある方は後ほど見てみてください。
一応30分のスタディモデルっていうところでYouTube動画が貼られてるんですけど、
15:03
それに対して若干の解説記事もあります。
というところでした。
では続いていきましょう。
75番目のアイディアです。
75個目は入っていた箱を描くっていうものですね。
Draw the box it came inですね。
素敵なアイソメトリック図法のヒントだそうです。
車やソファーを描く代わりに、
それが入っていた箱をプレスホルダーとして描いておき、
そこから絞り込んでいきます。
物体の漠然とした形から始めて、
後で詳細を詰めるという便利な実用的な考え方ですよと。
はぁはぁはぁ、そういうことですね。
さっきから言っていることと本当に一緒だと思います。
僕は。
重複になりますけど、
具体的には最初に抽象的にガンと箱だけ置いておいて、
後からその中身を詰めていくと。
HDMLでも一緒ですね。
まず最初にDivタグとりあえずガンと適当に置いておいて、
名前だけ付けておいて、
後からその中身の実装、コンポーネントの実装をしていくというところですね。
はい、これは本当に良い発想というかアイデアだと思うので、
これはぜひぜひそのままやっていきたいと思いますし、
ちなみにウェブ開発だけじゃなくて、
技術ブログとかノート記事とかもそうですし、
プレゼンのスライドだと一緒だと思います。
とりあえず大項目だけガッと、
もしくは各ページのタイトルだけガッと書いておいて、
その中で具体的にデータだったり図だったりテキストだったりとかを書いていく。
まあソースコードを置いたりとかもそうですけど。
という風にやっていく。
まず大枠から書いていくことが良いと僕も思っています。
この考え方は実生活いろんなところでも実際に使えるので、
おすすめです。
では続いて、77個目のアイデアですね。
続いては、
どんな設計システムも完璧ではありませんし、
そうあるべきでもありません。
はい。
詳細というか、
この筆者の方が書いているのがちょっと面白いですけど、
クソを喝杯を浴びたいという風に書いています。
まあ言いたいことはわかりますけど。
でもおっしゃる通りだと思いますし、
完璧なシステムなんて絶対ありえないと思います。
完璧って言ったらその時は多分いろんなものが漏れているか、
自分にとって完璧であって、
それはもう自分のためのシステムになっていくことですよね。
使っていただくユーザーにとって完璧はまずありえないです。
ユーザーが定まるわけではないし、
定まったユーザーですら時間が経過するにつれて
考え方や定価値観は変わるので、
どんな時を切り取ったって絶対に完璧はない。
ただ完璧を目指すことは本当に素晴らしいことなので、
そうあるべきだと思います。
というお話だと思いますね。
これは本当にフィロソフィーとしては良いマインドですね。
マインドセットとしては良いマインドだと思いました。
続いて、84個目のアイデアです。
建築に関する2つの視点と言っていますね。
2ポイントオブビューオンアーキテクチャーですね。
建築は真実のエクササイズと、
現実は物語のエクササイズという2つの視点があると言っています。
私はどちらも信じているということです。
真実のエクササイズと物語のエクササイズ。
これはちょっと予想抜きを出ないので、
実際に本自体を読みたくなりましたね。
何となく言っていることはわからないことはないですけど。
ちょっとわからないです。
続けていきましょう。
92個目のアイデアです。
ぼちぼち終わりが見えてきますね。
18:01
あと3つですね。
92個目は、
常に次の大きな文脈で考えて物をデザインすること。
部屋の中の椅子、家の中の部屋、環境の中の家、
都市計画の中の環境、みたいなことですね。
常に俯瞰視点でということですね。
これはエリエル・サーリネンという方がおっしゃっていたことだそうです。
ウェブの用語では、コンポーネント、他のコンポーネントの隣に、
他のコンポーネントの中に、モーダルの中に、
ページ上の唯一のコンポーネントとしてページが、
例えば12ページ連続で操作して考えてデザインしますと。
なぜ12ページがないのかちょっとわからないですけど。
なんかそういうのがあるんですかね。
12ページのページ数、12ページみたいなところが、
実はあったりするのかもわかんないですけどね。
ここはちょっと置いといて。
同じことだと思いますね、確かに。
とにかく、俯瞰視点でしてからデザインをしていって、
中のものを考えていく。
これ本当に一貫しているけど、これを切り取った。
切り口というか語り口として切り取られているだけであって、
言っていることは本当に一緒だと思いますね。
基本的に大きいもの、俯瞰的なもの、抽象的なところから
具象に入っていくっていう、
それに尽きるなという感じはしました。
もちろん関係性ですね。
コンポーネント間の連携とか兼ね合いとか、
余白とかっていう話はもちろんありますけど、
まず最初に考えるのは大きいものから考えて、
あとで小さいところに行きましょうというところですね。
続いて、93個目の間ですね。
政府が建物の設計を規則する主な仕組みというのは、
ゾーニング法、建築基準法、アクセシビリティ法だそうです。
この政府って言っているのは、
この本が書かれたら国の政府というような気がします。
日本で通称するか、全世界に適用するかわからないですけど、
大体これだっていうことだと勝手に解釈しました。
メタ契約、HOAとか賃貸契約なども、
政府が規則するものの上のレイヤーとして存在するのは
とても興味深いことです。
また法的規則を通じてアーキテクチャがアクセシブルな製品を
デフォルトにするために長い道のりを歩んできたこと
というのは注目に値します。
WEBはこれを必要としていますよというところです。
法規則とか政府レベルでの話と
何か紐付けるって考えたことなかったので、
とても興味深いと思いましたね。
ちょっとまだ今しっくりきてないし、
そうなんやっていう感じはしますけど。
とはいえ、アーキテクチャがアクセシブルな製品を
デフォルトにするために色々試行錯誤したり
時間をかけてきたっていうのはおっしゃる通りで、
今WEBはまさにアクセシビリティところが
かなり注目をされていて、今さら感はありますけど、
やっと色んな物事を受け入れる多様化が進んできた
ということもあって、今アクセシビリティって
本当に重要なのかと思いますね。
特に海外の方とかアメリカの方だと
アクセシビリティをちゃんと実装しないと
本当に嫌われているか、場所によっては
罰せられるぐらいの勢いの話を聞いたことがあって
ほんまかいなと思いましたけど、
それぐらいアクセシビリティはやっぱり重要で、
ちゃんとみんなに開けている、みんなが使いやすいよ
ということを考慮してあるのが
本当のWEBだよねっていう話だと思うので、
これは今後日本でも遅かれ早かれ
21:00
どのWEBサイトでもアクセシビリティの話は
絶対に出てくるなとちょっと思いました。
できればこれをデジタル庁とか政府レベルから
率先してやっていただけるのは本当にいいと思いますし、
デジタル庁のサイトがどれぐらい
アクセシビリティを考慮されているのか
僕はまだ検証していないので、
実はやっているかもしれないですけどね。
レスポンシブは確かやっていた気はしますけど、
アクセシビリティは一応本だけがって読んで
結局まだ具体的にちゃんとやったことはないので
ちゃんと勉強しなきゃなと思ったりはしますけどね。
はい、というところでした。
まあでも考え方というところは
WEBはこれを必要としているとおっしゃっていて
この記事が最近の記事なので
そうなのかもしれないですね。
はい、じゃあラストです。
100個目のアイデアですね。
Give it a nameです。
名前を付けましょうというのが最後のアイデアでした。
コンピューターサイエンスでは
名前を付けるのは難しいので
避けてロボットにやってもらいましょう。
しかし真面目な話、
誰もが参照できる共通の名前には
やはり力がありますよと言ってます。
これはですね、
まあいろんな観点があるんですけど
やっぱり大事だと思いました。
僕、名前を覚えるのが本当に苦手ですね。
昔なんかいろんな
数学の公式とかあったと思いますけど
公式の解き方とか使い方とか
何なら公式の動出の仕方だけ覚えて
名前は全然知らないことが結構あったんですけど
名前がわからないと
コミュニケーションがすごい遅いのと
お互いでちゃんと共通認識取れてるっていう
合意を取らなきゃいけないので
実は時間かかるしめんどくさいんですよね。
お互いにこの言葉はこういうことを意味してます
ということをちゃんと認識できていれば
そこのロスがなくなるので
実は名前つけることはすごく大事ですし
名は対応なすっていう言葉がある通りなんで
しっかり名前を考えてつけることは
とても大事だと思いました。
ただまあ、よく使う名前だったり
そんなにこだわる必要がないっていうところは
確かにロボットにも自動的にぺって
名前つけてもらうのでいいと思います。
とはいえ
例えばCSSのクラス設計とかだと
しっかり名前つけなきゃいけないとか
はあると思うので
名前をつける能力
スキルがすごく大事だと思いましたね。
というところで
この記事は今のがラストというところで
締められておりました。
前後半いかがだったでしょうかね。
結構通じるものは本当にあったし
やっぱり建築とウェブの開発
設計ってすごく似てるというか
お互いよくメタファーとして
使われますもんね、建築が。
それはシンパシー感じるのは正しいというか
よくある話だと思いますし
私の偉人の方々って意外と建築家の方
出身の方って結構多いし
建築の方が
こっちのウェブ業界とか
アプリケーションの分野に
手を、裾の伸ばしてきた方って結構いらっしゃるんですよ。
っていうところがあるので
まあそれはそうだよねっていうので
改めてこの
101 Things I Learned in Architecture School
っていう本ですけど
多分英語だと思いますがちょっと読みたくなりましたね。
買って読むとしたらすごくエネルギーと
時間はかかりそうですけど
今現在
現時点で
17.95ドルですね。
なので、まあまあ2000ちょい
3000いかないくらいの本なので
なんか読んでみたくなりましたね。
ちなみにAmazonで評価1316来て
だいたい
24:01
4点ちょいの評価なので
かなり高いですね。
みなさんほぼほぼ5スターつけてるみたいなところで
1000超えた
レビューの中で
星4点いくつ
すごいな。本当に名長なんだと思います。
もし興味ある方は見てみてください。
この後、この記事を改めてシェアしますけど
その時についでにこの本の記事の
本自体のリンクもシェアしたいと思います。
はい、というところで
いかがだったかわからないですけど
改めて読んで感じてもらったり
ご自身の中でもその言葉を読んで
自分の中で腹落ちする、自分の言葉として
咀嚼、理解をするってすごく大事なことなんで
やっていただけるととても良いのかなと思いました。
本当に素晴らしい記事だったと思うので
ぜひぜひやっていただけると
本当に嬉しいなと思います。
では、今日の朝活はちょっとおばしまして
以上にしたいなと思います。
今日は2名の方がご参加いただき
大変にありがとうございました。
わざわざ祝日の朝からご参加いただいて
すごく嬉しいなと思います。
また明日もゆるく何か読んでいきたいと思いますので
ご参加いただければ幸いです。
では終了したいと思います。
お疲れ様でした。
