DDD本 8章 ブレイクスルー
===
###### tags: `エヴァンス本読書会`

# 関連リンク

* [エヴァンス本 輪読会リンク](https://hackmd.io/6JyudJcoTNqUqlzDlA91cQ)
* [Discord開始位置](https://discord.com/channels/432531367427964929/740202765619429487/797371829001388062)
* [connpass募集ページ](https://ddd-community-jp.connpass.com/event/199503/)
* ハッシュタグ: [#dddcj](https://twitter.com/hashtag/dddcj)

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 第3部 序章

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797426102998007838)

## 目安の時間
- 15分

## 感想・気づき
- コードレベルのリファクタリングを継続していく中で、次第にブレイクスルーに繋がっていくのは、リファクタリングする過程で、コードの移動や一連の流れに名前を付けてメソッド、クラス化することにより、名付けが度々発生するからだと思った。:+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797429726175821854)
- 名付けをするときに考えるのが、モデル、ユビキタス言語に沿った名付けをしているかどうか。
- ある処理はどのエンティティ、値オブジェクトの責務かと考えたときに、適当な場所が無かったりとか。
- そういうときには、xxxサービスとかって作りがちだけど。リファクタリングする過程でそういう怪しさ（本書ではぎこちなさ）を感じていき、モデルにフィードバックしていったりしていく？:+1::+1:
- :memo: 最後に書いてある通り、ユビキタス言語をに基づくコミュニケーションが改善したこととかがでかいですね。
- :memo: 名前がイビツなのは、「病原菌」を「悪魔」とか「呪い」とか呼ぶのと同じ。
- :memo: モデリングした結果、わかったつもりになっていたけれど、モデルの不整合を自分の脳内で勝手に補完していた、っていうのがあって。コードは書いた通りにしか動いてくれないので、その不備を突きつけられる感がある。
- :memo: 未だ統合されていない体系を統合する能力（＝暗黙知）を発揮するための土台作りとして、 「名付けを試みる」行為の比重は小さくないと思う
- > リファクタリングの方法に関する文献はほぼすべてが、コードを読みやすくするか、非常に詳細なレベルで機能を追加するといった機械的な変更に焦点を合わせている。
- 文献だけでなく、現場レベルでの「リファクタリング」も、専ら目前のコードを「上手に」切り分けたり組み合わせたりする観点からのみで語られがちな印象:+1:
- そうしたコードの変更が全体において（殊にドメインという観点において）何を意味するかという観点は、「リファクタリング」なるものを語る時にあまり（あるいは、全く）意識されないことが多い体感
- 本文で言及されている『パターン指向リファクタリング』も、（技術的な改善活動としての）リファクタリングと（技術的問題を解決する道具としての）パターンを結びつけるものという側面が強そうで、その意味でここでのEvansの問題意識を解決するには至っていなさそうなのは、たしかに
- > 本書は、リファクタリング―つまり既存コードの設計を改善するプロセス―とパターン―つまり繰り返し発生する設計の問題に対する規範的な解決策―とを結びつけるためのものである - 『パターン指向リファクタリング入門』 p. xii
- P.191 「目標は、コードが何をおこなっているかを開発者が理解できるようになることではなく、なぜそれを行うかを理解した上で、ドメインエキスパートとの継続的なコミュニケーションに、コードが行っている処理とその動機を関係づけられるようになることである」:+1::+1::+1:
- 第3部では、この目標を達成するためのプロセスを学ぶ
- この「なぜそれを行うか」というのは、ドメインについての洞察に満ちたモデルへ向かうリファクタリングのことかな
- > 『リファクタリング』（Fowler1999）に挙げられているカタログは、定期的に話題に上るマイクロリファクタリングのほとんどを網羅している。それらのリファクタリングを行う動機となっているのは、コード自体の中に見つけることのできる問題である。 - リファクタリングのレベル
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797460531748667393)
- 『リファクタリング』で提示された「不吉なにおい」のメタファは、実際「コード自体」を対象として感じるものとして記述されていた印象
- ここでEvansが問題にしているのは、コードではなくドメインモデルを対象として感じる「不吉なにおい」である、と読むことができそう
- 対象が異なるので、コードを対象とした「リファクタリング」の観点だけでは不十分だし、コードを対象とした「リファクタリング」とはまた性質が異なる（"包括的なカタログとしてまとめることができない"）、と言えそう。:+1::+1::+1::+1:
- > より深い洞察へ向かうリファクタリングは、学習と深い思考が導く所であれば、どこへでも従っていかねばならない。成功したモデルについての公開されているコレクションは、第11章で述べるように、役には立つが、ドメインモデリングをクックブックやツールキットに還元しようとして道を外れてはならない。モデリングと設計には創造性が必要なのだ。 - リファクタリングのレベル
- DDDが「抽象的すぎる」とか「わかりにくい」と言われるの、こういう「クックブック」「ツールキット」を求めて（それらが書いてあると思って）読んでしまうからかしら、とふと思ったり:+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797451681822146610)
- 少なくとも、モデリングおよびその改善のためのリファクタリングにおいては、「クックブック」「ツールキット」としての具体性を提供することは目指していない（むしろDDDにおいては忌避してすらいそう）のは、ここでは明確に見える:+1::+1::+1:
- 書いていないこと、むしろ書こうとしていないことを読み取ろうとするから「わかりにくい」「抽象的すぎる」（ときには「役に立たない」とまで言う）感想になってしまっていたりしないか、的な:+1:
- ここでは、コードの読みやすさや詳細レベルの機能追加しやすくするといった機械的なリファクタリングを行う先には、「モデルをコードで明確に表現する」といったもっと上位レベルでの動機づけをしているように読めた。:+1:
- ドメインエキスパートと共有したモデルを上手く表現できたコードを書く為に、リファクタリングを続けていくというほうが、説得力が出てきやすいのかと思った
- 読みやすい、綺麗なコードというのを言うと「君にとって綺麗なコードって何？」とか、「君にとって綺麗でも私にとってはあまり」みたいな言われ方も稀にあったので。
- > これは素人にはわかりにくいが、エキスパートにとっては、ビジネスとの関連がはるかに深いものだった。焦点が貨物を配送するというビジネスに移ったのだ。 - 深いモデル
- 「わかりやすい」という言葉を考える上でも重要なポイントに見える。
- 万人にとって「わかりやすい」が実現されていなくとも、そのドメインと現に関わる人の関心や活動を反映できているなら、それには価値が有る:+1:
- 少なくともEvansは、それにも価値を強く見出しているように見える
- 少なくともDDDが目指す地平は、「誰でも彼でも」というような無文脈・無秩序・一般的な「わかりやすい」ではなく、むしろ、「ドメインエキスパートにとっては」という文脈依存・制約付・特殊な知識体系である（誰にでも「わかりやすい」とは限らない）、とも言えそう。:+1::+1::+1::+1::+1:
- > 。それは、ビジネスエキスパートが好んで使用する、シンプルで、もしかしたら抽象的かもしれない言語である。 - 深いモデル
- 「言葉」でも「用語」でも「単語」でもなく、「言語」:+1::+1:
- > モデル駆動設計は、2本の足で立っている。深いモデルにより、表現力豊かな設計ができるようになる。同時に設計が、開発者が実験できるくらい柔軟で、何が起きているかを開発者に示せるくらい明確であれば、モデルを発見するプロセスに対して実際に洞察を与えられる。
- モデルがドメインの知識「だけ」を忠実に反映していても、設計がただ柔軟な「だけ」でも、（Evansの考える）モデル駆動設計は、少なくともその目的は達成できないと読めそう
- モデルの情報が豊かになることで、その豊かさを反映できるような（その意味で「柔軟」な）設計へ取り組み、設計が柔軟にあることでより豊かなモデルの探求が可能となる、というような
- これを実現するために、DDDが求める分析モデルと設計モデルの一致、というアプローチが重要になりそう
- この意味で、DDDという設計アプローチにおいて重要かつ他と一線を画すのは、やはり分析/設計それぞれのモデルの統合にあると言えそう
- 「モデルと設計との間には密接な関係があるため、コードのリファクタリングが難しいと、モデリングプロセスは止まってしまう - 発見のプロセス」ともつながるお話

- P191 次の3点が導き出せる　の中で、1,2は断定しているのに3つめは「高度な設計スキルが必要かもしれない」と断定していない。これに対する考察がこれ以降あるのかなと感じた。(あるのかわからないけど) 実際には高度な設計スキルは必要とEvansは考えているのかな？

## 疑問
- P.192 「彼らが聡明でなかったわけではなく、ただ、深いモデルを発見するためのプロセスを経験していなかっただけなのだ」
- 深いモデルをそのプロセスを共有してない人と共有をするとき、どうする？　初期のモデルを見せながら、発見のプロセスを説明していく感じだろうか
- > 新たな洞察が現れたときには、ドメインモデルは極めて広い範囲にわたって変化するので、包括的なカタログにまとめることができない。 - リファクタリングのレベル(P. 191)
- 「マイクロリファクタリング」は、その範囲におけるテストが存在することを前提に、コードを変更するものだと思いますが、引用箇所のような「変化」が起きた場合、そもそもテスト自体が陳腐化してしまいますよね？ この場合、何を足がかりに「変化」をコードに落とし込みます？ :+1::+1::+1::+1::+1:
- [Discord](https://discord.com/channels/432531367427964929/740202765619429487/797426102998007838)
- そもそもカタログにまとめることができないとあるので、個別の事例としてどういうものがありましたか、的な
- :memo: 変化をコードに落とし込む --> テストを捨てる、スクラッチで書き直すなど
- :memo: モデルレベルの変化は、コードのリファクタリングにおさまらないことが少なくなく、リストラクチャリングになるのであればテストそのものを見直す、ということになりがちかなー。
- :memo: リファクタリングが出来ない場合、 既存のものをそこに閉じ込めつつ、変換レイヤーを設ける。
- :memo: 腐敗防止層など。3週間取れない場合などの現実的な方法
- :memo: クラスとかメソッド単位の（有る種ミクロな）テストは陳腐化するけど、 統合レベルの（よりマクロな）テストまで影響受けることは少ない（というより、そこには影響しないようにする）と思うので、そこを（例えば安心感の）足がかりにすることが多かったかもしれない
- :memo: 内部構造変えたら In/Out まで変わるのはおかしいよね的なアレです
- :memo: 仕様が変わる前のテストは、参考になることはあっても、動くテストとしては役に立たなくなるので。
- :memo: 常にではないですが、テストを作り直すときは、既存テストの一部見直しをするのではなく、新規にテストを起こして、捨てるテストから使えるものだけを移動してくる、という感じにすることも多いです。 前者だと、古い仕様を無理に使い回そうとして歪になることがありますね。後者のように心機一転とした方が安心できます。
- :memo: 観点が違うかもしれませんが、自分が大きいリファクタリングする時は、インテグレーションテストやe2eテストが通ってればいいかなって感じでやってますね… （バックエンドAppであれば、同じHttpリクエストに対して同じレスポンスが返ってくることが検証できていれば良い）
- 言い換えるなら、「深いモデル」が発見された後も、システム全体に要求される挙動（あるいは不変条件？）は変わらない気はするんですが、コードレベルのテストで担保できない部分をどう担保していますか？ という疑問です
- 結合テスト、システムテストで担保できるのでは？

---

# 第8章 序章

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797431001420005386)

## 目安の時間
- 15分

## 感想・気づき
- 「そういうモデルには、ほぼ常に、ある特徴が備わっている。それは、ビジネスエキスパートが好んで使用する、シンプルで、もしかしたら抽象的かもしれない言語である。」
- 現実では、ビジネスエキスパートがドメインを曖昧に解釈している場合もあったりするので、ベースは上記であると思いつつも、鵜呑みにはできないなぁと思った。:+1::+1:
- 長期的視点で大事なことが書かれているが、短期的視点で見ると、「掛けた時間に対する顧客価値」を感じづらい。モデルと実装に乖離があるからと、やるべきことが山積みの中で、直近で触る必要もないところに手を入れて良いものかどうか。「次の改修対象に違和感を感じたらやる」くらいでないと難しそう。反対に、このマインドが強過ぎてもリファクタを実施できなくなりそうで難しい。。:+1:
- >むしろ、マイクロリファクタリングを行うことによって、より一層の洞察に満ちたモデルへ向かう際に便利な、変更の単位が作り出されるのだ。- p.191
- 日々の小さなリファクタリングとドメインの新たな洞察によるリファクタリングは別の物だが排他な関係ではなくて、小さなリファクタリングから誘起されるものである。:+1::+1:
- 「Q.どれくらい頻繁にリファクタリングすべきか? - A.絶え間なくだよ。」に通ずると感じた。

- この時点ではもう当たり前のようになっているけど、モデルと実装が絶え間なく紐付いていることが、このブレイクスルーを起こしていると言えそう:+1::+1::+1::+1::+1:
- 丸めの処理の実装で出ていた不整合から、モデルが良くないのでは？　というフィードバックが得られ、そこからシェアパイバージョンのモデルへとリファクタリングし、実装レベルでもリファクタリングを反映させていった
- ここが綿密に紐付いていなければ、エヴァンスさんが実体験したブレイクスルーのチャンスは見逃していたのではないか。
- :memo: 「ドメイン課題を本質的に解決する手段を得た」のがブレイクスルーであり、その手段が深いモデルではないかと。
- :memo: 前のページから書いてある通り、要件定義の名詞や動詞からモデルを導くだけでは浅いモデルしかできないんで、そこからドメインに合わせて実体に沿ったモデル見つけることが深いモデル
- :memo: 浅いモデル「悪魔のシワザ」、深いモデル「病原菌」
- :memo: コッホが細菌を見つけて、初めて本質と向き合うことができた。
- :memo: 「違和感」を形式化する技能と、それを探る執念はある程度要求されるというか、 まるっきり無いと難しいかもしれない（それらを「特殊能力」と呼ばれてしまうとアレ）
- :memo: そっか、深いモデルって相対的な感じなのか
- :memo: 前と比べて深くなるもの
- :memo: 「モデルはあくまで未完成のものなので当然変わりますよ。 むしろ、あなたは育児放棄するつもりですか！」 っていってやりましょう。
- :memo: 言語化能力と、パターンとしての経験が多いと形式化できやすい気がします 経験の中で、対象と似たようなパターンを見たことがあるけど、目の前にあるモデルがそのパターンと合致しない場合、それが「違和感」としてまず表出するんじゃないかという気が 表出した違和感をまず捉えて、言語化能力でその違和感を説明するまでの「執念」という感じかなと
- > この種のブレイクスルーは、テクニックではなく、出来事である。課題は、何が起こっているかを認識して、どう対処すべきかを決めることである。この経験の雰囲気を伝えるために、数年前に私が取り組んだプロジェクトで実際に起きたことを例に、どのようにして非常に有益な深いモデルに到達したかを話すことにしよう。
- テクニックではなく出来事であり、ここで語られるのはEvansの体験であってプラクティスではない:+1:
- というのを踏まえて読まないと、変な誤読をしそうだなあという感触

## 疑問
- >**深いモデルは、ドメインエキスパートの主要な関心ごとと、それに最も深く関連した知識に関する明快な表現を提供するが、一方で、ドメインの表面的な側面は捨て去るのだ。** この定義は抽象化には言及していない。-p.192
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797431001420005386)
- "深いモデルかどうか" は抽象化されているかどうかではなくて、主要な関心ごとに深く関連しているかが重要ということ？
- 輸送コンテナがモデルから消えたのは主要な関心ごとではないことが導かれたのであるからで、輸送コンテナ自体が抽象化した訳ではないということ？
- 「表面的な側面は捨て去る」と書くと「抽象化の話？」と誤解を受けやすいので、「抽象化の話ではなく、ドメインに深く関連しないものを捨てるというだけの意味だよ」と念押しして伝えたかったのかと思いました。:+1::+1:

---

# ブレイクスルーの話

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797436122321911828)

## 目安の時間
- 10分

## 感想・気づき
- > 代表的な例としては、ファシリティの分担率は、特定のローンにおける引き出しに参加する上での指針にすぎないということが少しずつわかってきたことが挙げられる。
- 一定だとか、バリエーションは無いとか最初は思っていたものが、色々（モデリング、設計、実装、etc...）進めていく内に、実はよりメタなルール・構造のいち具体例でしかなかったとか、あるあるー:+1:
- 「ここで言う「出資」と「ローン出資」が一般的かつ本質的な概念の、2つの特殊なケースにすぎないと認識したことである - さらに深いモデル」とか、まさに
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797437371578056734)
- :memo: 「業務」なるもの、だいたいこの「いち具体例」でしかない 「これしかない（他に無いとは言ってない）」
- :memo: 逆に、あれとこれはこういう概念の一例だよね、ったまとめたら、あっちは特殊ルールがあったりみたいな感じで統合したのが徒になるケースもあるので、根掘り葉掘り聞いておきたくなる衝動に駆られる。
- :memo: ドメインスペシャリストの心を開く技術がまず求められるのかもしれない
- P.203 「しかもこの話は、こうしたプロジェクトでテストの自動化が幅広く使用されるようになる以前のことだ」という話も踏まえながら読み進めた方が良いと思った。
- テストが普及しているような現場であれば、「冷静な意思決定」の節で述べられている恐怖は多少なりは軽減されているだろうか。
- > これほど苦労するのは基本的な設計に問題がある兆候ではないかと、我々は疑い始めた。 - p.198
- 苦労している時に、苦労しているのはそもそもの基本的な設計ひいてはモデルに問題があるのではと疑い、そしてその設計およびモデルの改善へと至るの、(Evansが言うところの)モデル駆動感ある:+1:
- 実装やコードの細かな調整で済ませるのではなく、モデル・設計へと目を向けていくあたり
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797436432670392330)
- :memo: 「大変なので、こんな凄い仕組みで解決しました！」と、 リフレクションだったり動的ディスパッチの嵐が生まれたりして
- P.198 「これほど苦労するのは基本的な設計に問題がある兆候ではないかと、我々は疑い始めた」　→　「ある週になって突然、何が悪かったのかが理解できた」　という話の流れを読んでいて、「何かがまずいのでは？」といった疑いを持った状態で物事を見るようなプロセスが必要？
- P.198 「ただ、あえて言えば、なぜ我々がこんなに時間がかかったのか疑問に思ってもいただろう」
- 第3部の序章の「深いモデル」のところでも、発見のプロセスを経験してないから、深いモデルを理解できなかったという話があったので、ドメインエキスパートのメンタルモデルを理解する為には、そのドメインエキスパートがメンタルモデルを構築するまでに至ったプロセスを、エンジニア達が経験できなかったから、それだけ時間が掛かるのだろうか、とも思った。

## 疑問
- 参加者の中で「ブレイクスルー」を経験した人がどれくらいいるのか、できれば具体的なエピソードも交えて知りたい:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- ブレイクスルーの予兆みたいなものがあれば、その予兆をどう感じとったかが気になる
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797444021458174002)
- :memo: 某ショッピングサイトのクーポンを開発していて、クーポンの対象商品・ユーザーの絞り方（カテゴリで絞る、ブランドで絞る、ユーザー属性で絞る…）を追加する開発が多いことに気付いて、JavaのEnumのポリモフィズムを使ってターゲティングをうまく表現するといったリファクタをしましたが、深いモデルだったかもなーと思いました。

---

# 好機
## 目安の時間
- 10分

## 感想・気づき
- P.204 「より深いモデルへのブレイクスルーが訪れそうな時は、恐怖を感じることが多い。」
- 確かに、変更する量が多いと恐怖を感じるのと同時に「面倒くさい」とも感じそう。
- 「こういう設計であるべきなんだけど」みたいな言葉で封殺される（してしまう）事もありそうなので、打ち勝つための方策とか仕組みはあらかじめ用意しておきたい。
- ブレイクスルーによる設計変更をやれる、やれない、の判断が難しそう。:+1:

## 疑問
- ブレイクスルーの話では３週間の遅延をプロジェクトマネージャーが承諾してくれたが、深いモデルへの移行のために時間がとれない場合はどうすべきなのだろう？:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797439004332916786)

---

# 基本への集中
## 目安の時間
- 10分

## 感想・気づき

- ブレイクスルーはテクニックではなく、出来事であると序章にも書いてあったとおり、適度なリファクタリングを何度も行った後の積み重ねの結果なのだろうと思った。
- P.204 「ブレイクスルーの舞台を整えるためには、知識をかみ砕き、強固なユビキタス言語を育成するのに集中すること」
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797440381951541259)
- この知識をかみ砕くために、モデルとコードが紐付いているようにしなければならないし、リファクタリングがしやすい環境（自動テストの整備など）がまずは必要だと感じる:+1::+1:
- ドメイン層とそれ以外の分離（入出力とビジネスロジックの分離）
- :memo: ブレイクスルーは狙うものではなく、着実にあるべき姿を求めていった結果、ブレイクスルーとなる深いモデルへの変化が発生するもの、という理解。
- :memo: ドメイン駆動設計なので、少なくともモデルとコード（と設計）を紐付けようとする態度は前提条件になっている感
- :memo: これもいつも言ってるあれだけど、DDDはそれが一番重要で モデルとコードが紐づいている事。それによりモデルの成長にコードの成長が合わせられる。 だから、モデルはないけどDDDやってますってのはほぼ存在しない。
- :memo: 「ブレイクスルーを引き起こそうとして麻痺してはならない」というあたりからも、ブレイクスルーはあくまで結果。 ただ、その結果はそこに目掛けて積み重ねてようやく到れるもので。

## 疑問

---

# エピローグ：新しい洞察の連鎖
## 目安の時間
- 10分

## 感想・気づき
- P.205 「シェアパイバージョンのソフトウェアをリリースしてから、わずか数週間後、我々はモデルにまた別のぎこちない側面があることと、それが設計を複雑にしていることに気づいた」
- シェアパイバージョンで完成というわけではなく、それを皮切りにして新たな洞察が生まれやすくなっている。:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797441817003950121)
- :memo: 「99%の努力と1%のひらめき」ですよね、積み重ねをしたものだけが、目の前の幸運に気づくことができるし、セレンディピティの前髪を掴むことができる

## 疑問

---

# 放課後

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/797451681822146610)