あかぎれが痛い

お腹が痛い人のブログです。Techネタや旅行ネタ中心に書いてます。

2年間マンションの理事をやりきった。またやりたい

こんにちは。

Twitterのbioにも書いていますが、2020年から2022年まで今住んでるマンションの管理組合の理事をやってました。なんなら今年は副理事長でした。

自分の思いとしては今後もやっていい(多分やったら理事長にさせられてた)と思っているのですが、プライベートな事情から今年で一度理事から退任することにしました(理由はそのうち書きますが、理事会や管理組合とは全く別な都合です)。

管理会社からは、どのマンションも理事の成り手不足で苦労しているというお話をされていて、うちのマンションに至っては基本輪番制をとっている状態なのですが、理事会について勘違いしている人が多いという側面もありそうだったので、体験談・感想、なぜ理事を続けたいと思うのか、書いておこうと思います。

なぜ理事をやろうと思ったのか

そもそも自分は今住んでいる仙台には縁もゆかりもなく、2018年に引っ越してきた直後はだれも知り合いがいない状態でした。 幸い、IT系の勉強会に参加したり嫁がフリーランスやってた頃に使ってたシェアオフィスにお邪魔したりして知り合いはだいぶ増えたのですが、それとは別に、マンション内や近所で顔を合わせたら気軽に挨拶するようなレベルのご近所付きあいができる知り合いが欲しかった、というのが一番大きなモチベーションでした。 ワンルームマンションならいざ知らず、ファミリータイプのマンションともなると、いざ子供ができた時は結局近所の人には迷惑がかかるだろうし、近所の目で子供を見守ってもらえるだろうという打算的な思いです。

もうひとつの理由は、単純に古ぼけた中古マンションなんだから、自分が住みやすい家にしたい、という理由です。 たとえば、うちのマンションは築30年を超えているので、電気設備が貧弱で、各戸に引ける最大アンペア数が40Aと規約で謳われていて、流石に今後オール電化にしたくなったら対応できないな、とか、 EVに乗ってみたいから 今後来るかもしれないEV時代に備えて充電スポットを建屋内にほしいという意見を素早く理事会に届けたい、といったところです。

実際に理事をやってみてどうだったか

まず、目的だったご近所さんと顔見知りになるという目的はある程度達成できました。 全員と顔見知りになったわけではなかったですが、理事会で積極的に発言する人との良好な関係性を作れたと思っています。

次に、自分が住みやすいようにする、という観点で、非常に満足いく結果となりました。 共益部の修繕に関する色決めは理事会での意見が全面的に採用されるため、個人的には色味についての不満はない状態にできました。(そもへんも区分保有者全員の合意を得るべきでは?という考えもあると思いますが、理事会は毎月1回程度の開催頻度で物事を決めていく必要がありますし、修繕は素早く終えないといけない(そしてシステム開発と同様、期間が長くなればなるほどお金がかかる)ので、素早く完了させる必要があり、意思決定も素早くなければなりません)

また、EVの充電スポットについては、自分が理事になったタイミングで希望する意見を出していたことと、近年のEVの低価格化(補助金の拡充)により、むしろタウンユースの日頃の買い物にしか車を使わない人には経済面でも最適解であるという理事会での意識変容があり、前向きに継続検討していくことになりました。

他にも、理事会のIT化も提案したんですが、これは残念ながら実現には至りませんでしたが、管理会社からのウケは良く(現地に来なくて良くなるんだから当たり前ですが)、今後改善されるだろうなと楽天的に考えています。

じゃあ良いことだけだったのかというとそうではなく、大変だったこともあります。

それは、世代間の考え方のギャップが相当しんどい、過去のしがらみ、理事会開催のために業務都合をつける難しさの3点です。

世代間の考え方のギャップが相当しんどい

繰り返しになってしまいますが、住んでいるマンションは築30年以上の中古物件ですので、ほとんどの住民は、新築時に子育てをしていた団塊ジュニアです。なので、これから子育てをする仕事をしている世代との考え方のギャップがどうしても生まれます。例えば、今後マンションをどのように良くしていくべきか、という考え方も異なり、今の価値観で子育てしやすい・プライバシー維持したいという考えと、最低限の修繕で良いからそれよりも管理費を安くしてほしい、というような具合です。

幸い、今回理事をされているような方は「世代交代ができないとマンション運営が行き詰まってしまうので、若者の意見を積極的に取り入れたい」という意識の方が多く、私の意見を聞いてもらえましたし、なぜ今のような運用ルールになっているのかという説明もしていただけ、勉強になりました。

一方で、全住民を対象にした合意形成を行う場面ではそうもいかなかったシーンもあります。詳細は控えますが、丁寧に説得&場合によっては「あなた以外からは合意を得られている」というような、緩急のある意思疎通が必要なこともありました。これは、通常業務の中でも必要になる対人・マネジメントスキルが要求されるものでした。これも今の自分にとっては非常に勉強になるものでした。

過去のしがらみ

30年もマンションを運営していくと、本来とるべきルールが無視され、土地柄・住民の間で納得のいく合意が既に形成されていて、あるべき姿にする(戻す)ことができない・サンクコストが発生する、みたいなものもあります。たとえば、近隣の町内会との運用の整合性をどう取るか、みたいなものです。こればかりは、ステークホルダーが多すぎるので、一朝一夕にはいかないため、本気で取り組む人が出るまでは、そのままになるだろうな、という印象です。それがどうしても嫌で、理事会に参加したくない人や、そもそも自分が住んでいるマンションを嫌悪してしまうということが起こるような気がします。ここは、ある程度の割り切りや現実主義的な考えを持ち出さないとキツイな、という部分です。

理事会開催時の業務都合をつける

これが理事になりたい人が減っている・出てこない最も大きな理由ではないでしょうか。繰り返しになりますが、中古マンションでは主に定年を過ぎた人が重要人物になっており、基本的に理事会は平日に開催されます。私が住んでいるマンションのように、勤め人にも考慮した日程(平日だけど夕方に開催してくれる)であればまだ良いのですが、そうではないマンションの場合、いくら理事になりたいと思っていても、平日のコアタイムに仕事を中抜けさせてくれるような会社は少ないでしょう。 幸い、自分はフレックスなので、同じプロジェクトのメンバーに合意を取れば早退することは難易度が低かったので困りませんでしたが、来期の理事を輪番でお願いした方の数名が、仕事を理由に辞退されています。

なり手を増やすためには、IT化でオンラインミーティングを許可するとか、土日開催も検討するとかそういうソリューションが必要になってくるのですが、普通に考えて土日の貴重な休みをこのような議論の時間にしても良いという人は多くないのも理解できます。そして、オンラインミーティング化したところで、それに追従できる新築当時からの住民がどれほどいるだろうか、というのも大きな問題です。。。(肌感、半数以上の方はオンラインでも良いという意見ではあったのですが、声の大きな中心人物がNGを声高に叫んでしまうとなかなか難しい。。あえてその人の意見を否定するような近所付き合いがギスギスしかねない行動を取れないという、帽子を被り分けるのがしんどいという日本人らしい問題もあったりします_)

これからマンション理事をやらなければならない人に伝えたいこと

とまぁネガティブなことも書きましたが、普通に楽しいですよ、理事会。特に自分の住んでいるマンションをより良くする活動に参加できる、毎月払っている管理費の使い道を自分で決められるというのは、マンションを購入した人にしかできない権利なので、是非行使してほしいです。あと、知り合いが増えるのも個人的には楽しかったです。時代に反した考え方なのは理解していますが、他人に干渉しないということと、近所に住んでいる人と積極的に交流しないは意味が違うと思うんですよね。必要以上に交流する必要はないけど、少なくともコモンを共有している人たちなんだから、そういうコンテキストを共有できる人とは課題や良いことについて議論したり、井戸端会議をして、他の人がいろいろな事象についてどう考えているのかを知ることは大事じゃないでしょうか。

とはいえ、仕事の都合で参加が難しい場合でも、監査役という形で、合意形成結果についていちゃもんをつける議論が煮詰まっていない点を指摘したりすることは有意義ですので、理事会には参加しないけど書類には目を通すという形でも私はいいと思いました。

漫然と理事をやるとやらされ感を感じてしまうかもしれないので、任期中に自分が理事会で何を実現したいのか、個人的な要望で構わないので、何らかの目標を立てると、理事会の活動を自分ごと化できると思います。これが自分が理事を続けたかった理由で自分が巻いたEV充電スポット設置の話を自分が進めたいんですよね...(変な設備になったり、充電スポットの話自体が立ち消えにならないように...)

私は副理事までやりましたが、副理事は理事長が欠席したときのファシリや理事の意思決定をアシストするような意見だしをするだけでよいので、思ったほど大変ではなかったです。

ただ、理事長となると話は別で、管理費を管理している口座の名義を理事長名義に変えるとか、必要な書類に目を通して承認するという面倒な仕事があるので、業務都合がつきやすかったり、ご近所さんや管理会社の担当者からの信頼を得ているとか、ある程度条件が必要な気がします。いきなり理事長になるのではなく、まずは皆さんからの信頼を得るような行動をしたうえで、徐々に理事長の座を狙ってみてください。これは、マネジメントスキルに加えて、ある程度の人心掌握術も必要かもしれません(闇)。

新築マンションの事情は未経験なのでわかりませんが、皆さん顔見知りではない中、厳しいお金の話をする必要があるので、ある程度、面倒ごとが起こることを覚悟する必要かもしれません(管理会社がサポートしてくれると思いますが)。新築マンションだと、子育て世代が集まると思うので、理事会の開催日時やツール(オンラインミーティングなど)の提案は比較的楽かもしれませんね。

それでは。

ツーリング・キャンプ・登山をするときに気にしている天気のこと

アウトドアでのアクティビティにつきものな自然との対峙。色々あれど、最もハードルが高く、自分ではなんともできないのが天気。。

特にこの夏休み期間は、自分が住んでいる仙台周辺の天候が安定しないこともあり、予定していたキャンプ・登山の予定を変更し続ける前半戦でした。

登山やツーリングのような命に関わるアクティビティを予定している場合は流石にいろいろと気をつけていて、無理しないというのが心情です(各方面に迷惑をかけたくないので)。

とはいえ、雨予報でもこれくらいなら大丈夫だな、とかそういう日もあるわけです。その見極めのために使っている諸サービスでも紹介して、潰れてしまった夏休み前半戦の供養にでもしようかと思います。

長期的な予報の確認

そもそも自分の性格上、1ヶ月以上先の旅行や遊びをする計画を立てることは稀なのですが、交通機関や宿泊施設など確保の観点から1ヶ月先の予報を参考にすることもあります。

その場合、そもそも1ヶ月予報を出しているサービスが限られるため、以下の情報を参考に、統合的に判断しています。

  1. 季節予報 (気象庁) www.jma.go.jp www.jma.go.jp

統計的に向こう1ヶ月の傾向を発表しています。 ちなみに、気象庁(やその情報をもとに報道しているマスコミの気象に関するニュース)で利用される地域区分が複数種類あるので、こちらの解説資料に則って把握する必要があります。 www.jma.go.jp

北日本」や「東北地方」という言葉が混同して使われていた時、どこの話をしているのかは見極めておく必要があります。例えば、青森県だと津軽地域と下北・三八上北で区分が分かれているので、目的地に応じて確認すべき予報の内容は変わります。

  1. AccuWeather

www.accuweather.com

出どころ不明情報ですが、1ヶ月先までの具体的な天候をちゃんと表示してくれているので、判断に迷うときはこちらも見ます。海外予報サイトなので、精度は高くないので、後述する2週間以上先のおおよその天候を把握したい時に使います。

中期的な予報の確認

以下の気象予報サービスでは、10日先の天気まで確認することができます。

  1. ウェザーニュース

weathernews.jp

  1. tenki.jp

tenki.jp

ウェザーニュースは独自予報、tenki.jpは日本気象協会発表の公式予想となっています。双方の予報が一致しているときは大体変わることはないです。もちろん、台風が近づいている場合や、急に偏西風が蛇行した、みたいなことがあればどちらの予報サイトも急に予報が変わることがあります。

キャンセル料は最長で1週間前から発生するので、費用が発生する場合は日々ここの情報と睨めっこしながら2週間を過ごすことになります。

短期的な予報の確認

前日〜3日前の予報は、上記と同じくウェザーニュースとtenki.jpの情報に加え、気象庁の予報も加えて参考にします。

www.jma.go.jp

気象庁の予報は、1週間以内であれば信頼度まで表示してくれているので助かります。注意点としては、読めばわかりますが、晴れ予報でも、以下のような内容が書いてある場合は要注意です。

所により 夜のはじめ頃 まで 雨 で 雷を伴い 激しく 降る

お守りと同じで、大吉でも結構厳しいことが書いてある時があると思いますが、同じニュアンスで、急な天候の変化に注意します。

さらに、登山やキャンプ・ツーリングの場合は、山間部に滞在したり走行することになるので、こちらの予報サイトも確認しています。

tenkura.n-kishou.co.jp

特に登山となると、「里」の天気は良くても山の天気は悪かったり、その逆もあったりするので、単純な気象予報サイトだけを参考にすると、痛い目を見たりするのですが、このサイトはその山の登山適切度をA/B/Cの三段階で評価してくれます。最高ランクのAであれば、里の天気は良くなくても、山間部は風がなかったり、高層雲がないので頂上は晴れているということが大体判断できます。

高所の気温については、Windyが参考になります。指定の高度の風や気温の情報が確認できます。

www.windy.com

リアルタイム(1時間後〜最短だと5分後の天気の確認)

最後に、実際に行動を始めた後の気象確認です。ここまでくると予想ではなく、実況データを見て、登山の場合は下山判断、ツーリングの場合は早期離脱を判断するために利用します。キャンプの場合は、撤収を判断するかどうかになりますが、設営が終わっていたら覚悟を決めます(流石に雷が鳴った場合はテントへの落雷の危険性があるので、荷物を残して東屋やビジターセンターに避難します)。

ツーリングは運転しながら、登山は圏外になることもあるので、常時予報サイトを確認するわけにはいかず。なので、空模様を定期的に確認し、不穏な兆候がないかを見極めることが必要になります。不穏な兆候とは具体的にこんなやつです。

  • 進行方向に入道雲がある
  • 急に冷たい風/突風が吹いてきた
  • 霧が出てきた / 山肌を雲が登ってきた
  • じめっとしてきた
  • すれ違う車や登山者が濡れていたり雨具を装着している(登山の場合はすれ違う人に声かけて情報収集したりするし、ツーリング中であればバイク乗ってたっぽい人に声かけることもある)
  • 道路・登山道が濡れている
  • なんとなく頭が痛い、スマホ/登山時計の気圧が想定よりも下がっている

これらの兆候を察知したら、気象庁のナウキャストを確認します。

www.jma.go.jp

アニメーションで雨雲や雷雲の動きをある程度予測し、気にせず進んだほうがいいのか、撤退するほうがいいのか、その場に留まる(ビバーク)を判断します。

特に、登山中の雷雲の接近には注意が必要です。森林限界より高度が高い場所であれば、木や岩といった逃げ場がないためです。

引き返すことすら危険な場合は、金属製のものを外して雷雲が過ぎていくのを待つしかありません。非常に危険なので、そもそも発雷確率を確認し、確率が高い場合は登山を控えるといった危機回避が必要です。

www.imocwx.com

とまぁ、こんな情報を使って、家を出るかどうかを判断してます。大体、ここに書いていることを気にしているような日は、大体天気が崩れるので、家にいるという結果になっていることが多いですね。。。

星を見る時

天体観測のような、雲の晴れ具合が重要なシチュエーションの時は、SCWというサービスを使っています。

supercweather.com

航空祭とか飛行機の写真撮りたいとか、そういうシチュエーションでも使えると思います。

以上です。

なぜフロントエンドのコンポーネント分割に失敗するのか?

タイトルは釣り。

 

ユースケースvsドメイン

ユースケースは「こういう時に使うもの」と言えるもの、ドメインは「この業務知識」と言えるもの。

破綻する理由は、ユースケースドメインがひとつのコンポーネントで混ざり合ってしまっているから。

まず、ユースケース別なコンポーネントと、ドメイン知識が含まれるコンポーネントは明確に分けるようにするだけでもかなりマシになるはず。

以下は、それをどう実現するかの雑記。

 


バケツリレーvs状態管理(またはcontext)

propsのバケツリレーのネストの深さや親コンポーネントへのイベント通知のため、状態管理やcontextを使うのは、基本的に悪手になるケースが多い。特定コンポーネントが別なコンポーネントと一緒に利用されていないと使えない状態になるので、密結合になる。

今のところ1番気に入っているアーキテクチャは、ドメインロジックを含むコードをpagesのみに記述し、コンポーネントには一切のドメインロジックを記述せず、propsのバケツリレーにする方法。

バケツリレーのネストが深くなってしまう理由としては、ページ内のブロック単位で安易にコンポーネントを切り出していることで、パーツの依存方向がめちゃめちゃになってしまい、結果としてネストが深くなってしまっているだけで、状態管理やcontextを使っていい理由にはならず、とどのつまりアーキテクチャが良くないからそうなっているものを無理やり動かすために状態管理やcontextを使って繋ぎ止めているだけだろう。

 


どうしてもcontextを使いたいのであれば、パーツとして共通利用可能なコンポーネントをまず作り、さらにそれを特定ドメインでのユースケースに限定したcontextでラップした新たなコンポーネントを用意し、意図しない共通利用を避けるようにし、このルールをコーディング規約として徹底させる。

この手法の場合の嬉しい副作用として、コーディングできるデザイナーが参加しているプロジェクトで威力を発揮する。デザイナーは共通利用できるコンポーネントのみに手を入れることで不意なロジックの破壊を防げるので、デザイナーが安心して積極的にコーディングに参加できるようになる。

 


加えて、Storybookを使っているプロジェクトであれば、基本的に特定contextで括られたコンポーネントについてはパーツ単位で見られるようにする必要はないだろう。

 


CSS設計

CSSは見た目におけるドメイン知識なので、コンポーネントを横断して伝播するような書き方を避ける。そうしないと、特定コンポーネント間の依存系の場合にのみ発生する見た目のずれがでたり、逆に特定コンポーネント間の依存であれば意図した通りの見た目になるのに、別なコンポーネントコンポジションすると意図した見た目にならならず、しょうがなくワークアラウンドのためコンポーネントユースケース毎の場合分けしたCSSが混入してしまうと、コードで言う密結合な状態となり、意図しないデザイン崩れが依存系に発生するなどの副作用がきつく、手がつけられなくなる。

 


対策としては今のところトライ段階だが、CSSセレクタをうまく使う(小結合子 > や、Owlセレクタ * + *)ことで、無駄なマージン定義クラスの爆発的増加を避けたり、意図しない子コンポーネントへのスタイル適用を防ぐような規約にできないか検討している。

 


Atomic Designをどう捉えるか

社内外問わず、色々な人から「Atomic Designはうまくいかない」という声を聞く。よく話を聞くと、Atomic Designであることがうまくいかない理由ではなく、上記のようなコンポーネントの切り方を誤り発生している依存関係がカオスな状態をAtomic Designのせいにしているだけなのではと最近は思う。大切なのは、依存関係を一方通行にさせること、コンポーネントコンポジション性を保つことで、それがまもられればAtomic Designでなくても、分割ルールを各プロジェクトや会社で決めてもらえればいいので、分割の手法そのものにこだわる必要はない。

ドワンゴBCD designや、食べログアーキテクチャなど、エンジニアを納得させやすいAtomic Design以外のアーキテクチャがある。カオスなプロジェクトに対して最も提案しやすくてことある毎に引き合いに出している程度にはおすすめ。

 


Figmaとデザイントーク

Atomic Designがうまくいかない理由はエンジニアのわがままやスキル不足であると述べたが、その上段、つまりデザインカンプに問題があるケースがあることもある。

たとえば、ボタンに法則性不明な複数のバリエーションがあったり、Rectangleの間隔に法則性がなかったり、そもそもコンポーネントが使われていないので修正漏れがぽろぽろ起きる、というものだ。

デザインレビューで無駄なボタンのバリエーション爆発が起こっていることは指摘できるが、間隔についてはそこまでチェックしていない現場が多いのではないだろうか。

 


間隔がまちまちになると、エンジニアがよしなにその意匠を読み取る必要が出てくるため、コミュニケーション齟齬が起きたり、実装コストが高くなるうえ、法則性が見出せないので、変更に弱いDOM構造やCSSスタイリングにせざるを得ないケースに発展する。

 


もしあなたが感度の高いUIデザイナーでFigmaを使っているのであれば、直ちにFixedなレイアウトをやめて、全てをAutoLayoutベースで作り直すべきだ。

 


また、、UIデザイナーはデザイントークンにも気を使ってほしい。

figmaを使うことでエンジニアは簡単に指定された色を使っことができるので、デザイナーはさまざまな色を指定してしまいがちだが、その結果、全ての特定の色を変更したくなったタイミングで、全置換になる(Figmaはそれを簡単にできるが、CSSではそうならない)。その色が正しく指定されていれば良いが、カラーパレットからピックした似たような色のバリエーションがあった場合、置換対象から漏れてしまい、色が変わっていないページが爆誕することになる。これはいわばデザインのバグである。

 


対策として、最低でもフォント・色はトークン化し、可能であれば design lint で不正な値が使われていないか確認する体制をとってほしい。

 


デザインフレームワークを使っている場合

MUIやVuetifyといったフレームワークを使う場合に気をつけないといけないのはカスタマイズとの兼ね合い。デザイナーの方でガツガツスタイリングしても、ライブラリのほうではそのトークンはカスタム不可能ということが普通にあり得る。

その場合の選択肢としては二つあり、

ライブラリの利用をやめる
カスタマイズ可能な範囲で妥協する
これだけだ。ある程度グロースしていたり、その意匠やuiがプロダクトのブランディングユーザビリティに不可欠なものでありながらコンポーネントを0から開発するコストが取れない場合は、頑張ってカスタマイズすることも選択肢には入ってくるが、ある程度のカスタマイズまで行くと、スクラッチで開発した方が安上がりになることの方が多い。特にVue系のフレームワークは成熟が進んでおらず、カスタマイズ性に難があるため、早々に諦めた方がいい。

 


ただし、カスタマイズしすぎると、特定ユースケースに特化したコンポーネントにせざるを得なくなり、コンポーネントのメンテナンス性に問題が起こる。デザインシステムが未整備のプロジェクトでMVPやABテストをやる場合は、デザインもある程度妥協する必要が良いだろう。

 


このためにも、エンジニアとデザイナーは相互理解しながら双方の妥協点を見出せる関係性を作らなければならない。

 


まとめ

正直これはMVVMの再発見にすぎない。

強いて言えば、MVVMを拡張したなにか?


Model、ViewModelは技術領域、Viewはプレゼンテーション領域とした時、NextやNuxtのpagesに相当するレイヤーは既存の枠組みだとどこになるのかと考えた時、pagesはActionでありながら、Controllerでもあるのだろうと思う。

 

ただし技術的な制約で、controllerをactionから引き剥がすことができない(hooksやsetup)ため、Action&Controllerが蜜結合したものとして使うことが必要になる。

 


そこまでやるならRailsやLaravelのようなフルスタックFWのほうがいいのではと思う方もいると思うが、その通りだと思う。ただし、この思考でエンジニアを規定してしまうと、それはフルスタックにデザイン領域が含まれてしまい、さらに採用が難しくなる。現実的な解として、メンテ性、グロース性、スケール性を考えると、やはりフロントとバックは分けておくに越したことはない。

コーヒーから抹茶に乗り換えたら体調がすごく良い件

あけましておめでとうございます(?)

タイトルの通りです。毎日コーヒー飲むのをやめました。

これまで、仙台の某コーヒー豆屋さんから仕入れた美味しい豆をミルで挽いて毎朝淹れて飲んでいました(出社時は近所のコンビニやカフェでコーヒーを買って飲みながら仕事していました)。

去年の年の暮れ、キッチン周りの片付けをしていたら、コロナ禍が始まった直後に買ったと思われる、伊藤園の抹茶粉末(未開封・賞味期限切れ)が発掘されます。おそらく、抹茶系のお菓子を作るつもりで買ったんだと思いますが、あんまり覚えてないです。

開封だし賞味期限切れてても飲めるだろうということで、飲みきるまでのつもりで毎朝飲んでいるコーヒーをやめて抹茶に切り替たのですが、それをきっかけに抹茶にハマってしまいました。賞味期限切れの抹茶を飲み干したので、今度は伊右衛門の抹茶を飲んでます。

緑茶の粉末と何が違うのかわからないんですが、ほのかに出汁っぽい風味とあの香りに非常に癒やされるというか…あと、コーヒーの甘い香りとも違って、ホッとするというか。それと、コーヒー飲んだ直後のシャッキリ感も穏やかというか、まぁそんな感じを気に入ってしまったんでしょうね。

まぁそんな感じでコーヒー派から抹茶派になったわけですが、副次的な効果として、体調の改善が見られました。私のようなお腹ヨワヨワマンならわかっていただけると思うのですが、コーヒーって飲んだあとだいたいお腹ぐるぐる来ますよね。あれが結構辛くて、1日1杯を上限に意識してました(コーヒー自体は大好きなので、可能であればいくらでも飲みたいのですが)。しかし、それがないので、いくらでも飲めてしまう。それでいてトイレの心配がなくなる(水分なので前は近くなりますが…)。

ということで、今後もしばらく仕事中は抹茶を飲んでいこうと思います。

ハマりすぎて、仙台の茶室を調べてしまってます。1回くらい、教養として、茶道やってみたいですね…

2021年買ってよかったもの3選

今週のお題「買ってよかった2021」

今年もこんな季節になりましたね。

カードの利用明細を見ながら、今年のベストバイを振り返ります。

スキー

スキーに行くときは大体実家経由で蔵王温泉スキー場に行っていたので、高校の部活(アルペンスキー部でした)用に仕入れた、10年以上前に買ったサロモンのGS用の板かクナイスルのSL用の板と、ロシニョールの競技用ブーツを使っていたのですが、せっかく宮城側にいるのだから、山形経由しなくても宮城側のゲレンデでも遊べるように、新調しました。

買った板は、Fischerのロッカー「PRO MT PULSE」の2018-2019年モデル。楽天で2万円でビンディングセットを購入してます。ちなみに、ブーツはハードオフでたまたま見かけたロシニョールのブーツです。これは5000円くらいだったかな。ガチで競技をやるわけではないので、中古で十分です。

www.instagram.com

これで宮城側のゲレンデにも行けるようになったのですが、雪質などの関係で、結局山形側に行くことが多いです。

キャンプ道具 + 新しいバイク

10年前にバイク乗り始めてからずーっとやってみたかったソロキャン。会社の人からソロ用テントをもらったこともあり、今年こそ始めようと一念発起し、登山用に持っていた道具以外の足りないものを買い足して、秋に秋田へソロキャンしてくることができました。今年は1回しかできなかったので、来年はもうちょっとソロキャンできるといいな。

道具とかバイクのことは、ここに買いたので、割愛します。

akagire.hatenablog.com

しかし、7月に修理に出したバイクが帰ってこないまま雪が降りシーズンオフになっちゃいました…まぁ、来年ですね。

ポストイット

最後に、仕事関係。

基本的に仕事のToDoは、瑣末なものであれば脳内キャッシュにスタックさせておき、プロジェクト関係のToDoはZenHubに、プロジェクトに関係しない会社関係のToDoはMacのリマインダーに記録していました。

となると問題になるのは一覧性。いろんなToDoが散り散りになってしまい、ぽろぽろ漏れるようになってきていました。また、ToDo管理で陥りがちな、ToDo化することで脳のメモリを解放した結果、やること自体を忘れてしまうということも起きてしまいました。

なので、原点回帰として、ポストイットに全てのToDoを書き出して、自宅の書斎のモニター裏の壁に貼って管理するようにしました(プロジェクト関係のToDoはZenHubにも書き出す必要があり、若干手間ではありますが、やること自体を忘れることがなくなり、めちゃめちゃいい感じです。

ToDo管理の原則は 「いつも目に留まるところにある」 ことだと再認識したのでした(ZenHubとかリマインダーは、自分から見に行かないと見れないので、あんまり良くない)。

まとめ

こんな感じです。今年もありがとうございました。来年もよろしくお願いします。来年の抱負は、建てないでおきます。

Atomic Design を実装におけるコンポーネント分類手法として利用するのは悪手なのでは説

前提条件として 、 Atomic Design はデザイナーであるブラッド・フロスト氏が考えた デザインシステム だ。

bradfrost.com

フロントエンド開発者は、Atomic Design の概念をソフトウェア開発に持ち込み、デザイナーとのユビキタス言語とすることで、アジャイル開発におけるデザイナーとの早期コラボレーションを 実現している 目指している。

一方で、Atomic Design の考え方は、開発者なら誰もが耳にしたことがある DDD (ドメイン駆動開発 ) や クリーンアーキテクチャを強く想起させる。

blog.cleancoder.com

f:id:seal2501:20211121222328j:plain ※上記ブログより引用

こちらのブログで紹介されている Onion Architecture がまさに、 Atomic Design の概念に親しい。

jeffreypalermo.com

f:id:seal2501:20211121222609p:plain ※ブラッド・フロスト氏の記事より引用

よって、以下のような記事は、非常に合理的な考え方に見える。

a-suenami.hatenablog.com

だがしかし、見逃しがちな Atomic Design と Onion Architecture の違いは、ブラッド・フロスト氏の別なブログで記載されている以下の一文に集約される。

atomicdesign.bradfrost.com

Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms.

日本語訳すると 「Organismsは、Molecules・Atoms・他の Organismsから構成された、比較的複雑なUIコンポーネント だ 。つまり、 Organisms は Organisms に依存される可能性がある。これではクリーンアーキテクチャと言うことは難しい。これが、意外と知られておらず、実装者の理解によって、 Organisms が Organisms を依存している構造が許容されたりされなかったりする。

正直、この点はよく目にする「このコンポーネント、Molecules にすべきか Atoms にするか論」よりも、よっぽど問題だと思っている。

もちろん、このルールを拡張して、Organismsは他のOrganismsを利用しないようにするという規約で縛ることでクリーンアーキテクチャ然に使うことはできるかもしれないが、基礎的な設計では Atomic Design はクリーンアーキテクチャにはなりえないと言える。

にもかかわらず、バズワード的に Atomic Design という言葉が広まったことで、属人的な理解の側面が強いまま、コンポーネント分類手法として広く定着してしまった。

このことから、食べログの note で紹介されたような、独自のコンポーネント分割を行うアプローチの事例も散発的に目に留まることが増えてきた。

note.com

再掲になるが、上記記事でも言及されている通り、 Atomic Design はあくまで デザインシステム であり、ロジック実装に関する事柄には触れられていない。

この辺の、どう捉えるべきかに余地がある(抽象度の高い)概念は拡張性がある一方、誤解を生みやすく、開発を始める前や、新規メンバーが参画した際の適切なインストールを行う必要がある。また、カスタマイズする場合はなおさらインストールが大変になることに注意した方がよさそうだ。

(特に、使う言葉が同じなので、言葉の上では「理解したつもり/共有したつもり」という誤解が生まれやすいのでなおさら厄介なのです)

なので、ぼんやり思っているのが、 Atomic Design の概念を拡張する 場合でも、格コンポーネントの分類をする際に名称を変えた方がいいのではないかということだ。

例えば、Atomic Designが原子物理学の比喩表現なので、工学の比喩表現(特にクルマ)を使ってみると、こんな感じに言い換えることができる。

原子物理学 工学 備考
Atoms Parts これ以上分解できない部品(例:ギア・ギアボックスケース・タイヤ・ホイール)
Molecules Assemblies 部品が組み合わさって構築されたそれ単体では機能が提供できない組み合わせ(=ASSY)(例:トランスミッション・タイヤがホイールに取り付けられた状態)
Organisms Mechanisms 部品やASSYが組み合わされてできた、それら単体で動作する機構(例:エンジン)
(該当なし) Units 部品、ASSY、機構で構成された、もう少し大きい粒度(例:エンジン+トランスミッション+プロペラシャフト+デフ+ドライブシャフト+タイヤ)
Templates Templates この辺は提供する媒体(Webなのか紙なのか、はたまたクルマなのか)に引っ張られる。フロントエンドなので、Templateのまま
Pages Pages 同上

とまぁこんな感じ。

結論は、ラベリングし直しただけなんだが、 Units 層を加えたことで、クリーンアーキテクチャとまでは言わないが、依存関係は一方通行にすることができるようになった。

個人的にこの比喩表現が気に入ったのは、アプリケーションもまた工業製品であり、工学との相性のほうがいいのではないか、というところ。

デザイナーと会話する際はAtomic Designに翻訳して会話し、エンジニア間はまた別な意味合いのレイヤリングで会話することになるので万事が解決するわけではないが、対応表まで用意してあげればある程度問題にはならないのではないかと思う。

他にも、天体物理学の比喩表現も考えたが、「Atoms(チリ)が集まって高密度になったところが恒星になる(核融合反応で炎上する)」というのがあまりソフトウェア工学との相性が良くないので考えるのをやめた。(燃えるという点が縁起が悪い。なにより、わかりづらく、燃えた後に冷えていくというのはソフトウェア工学的に悪手の考え方。。。まぁ、炎上プロジェクトを冷やしにかかる時は有効かもね。。。)

11/22 追記

BCD Design というコンポーネント分類手法があるらしい。

atoms (Base) と molecules (Common) という粒度だけを共通の基底コンポーネントとし、命名規則ユースケースでDomain 別のコンポーネントを作る概念。新たに携わるプロジェクトで試してみよう。

朝会のない人だけで朝会をやってみることにした

現職で、今までプロジェクト単位で朝会をしていたが、いろいろあって、朝会の時間がない人が出てきている。

自分もその中の一人なのだが、その人とたまたま雑談する機会があったので、その際に「もう俺らで朝会してみませんか?」と提案されたので、明日からやることにした。今回は、やってみますという宣言のみ。

どういう結果につながるかちょっと楽しみ。

余談

毎日インスタに撮った写真はアップできてるけど、毎日ブログ書くって結構しんどい。

できれば統一したいけど、やってる目的が微妙に違うから難しい。