00:06
11月18日金曜日ですね。遅刻は昨日もありました。
今朝ですね、ポケモンスカルットバイオレットが発売あったということで、
僕何も調べてなかったんですけど、今回もオープンワールドということで、
もうそれだけやりたいと思って急遽買いました。あのマーボン。
ポケモンは僕実は金銀で止まってて、そこからすっとばしてアルセウスまで飛んでしまうんですけど、
アルセウスでオープンワールドすごく楽しかったっていうのにもう味を占めました。
ここから以降多分オープンワールドのポケモン全部買うんじゃないかぐらいな勢いですね。
ちなみに僕はバイオレットの方買いました。
そのCMとかをダラダラ見てたら、気づいたら9時を超えてしまってたっていうのが遅れた原因です。申し訳ない。
はい、じゃあやっていきたいと思います。おはようございます。
いめみのkeethこと桑原です。
本日は大阪勢やりますが、今日はタイトにやりますけど、
昨日か、おとといかな?そうっすね、3日前ですね。
昨日にジェイソン・ワーナーっていうGitHubのCTOの方が語られてた連続ツイートがあって、
それが面白そうだったっていうのと、いろんな方がリツイートしたり、
引用ツイートしてたので、そんなにいい連続ツイートなんだなっていうところで読んでいこうと思います。
ツイート自体の数が多いんですけど、一個一個のツイートは短いので、
もしかしたら時間早めに終わってしまうかもしれないですけど、ご了承いただければ幸いです。
ではやっていきたいかなと思います。
長谷川達也さんとけいさんですね。おはようございます。ご参加いただきありがとうございます。
今日もダラダラやっていこうと思います。
タイムリーにけんじさんですね。おはようございます。ご参加いただきありがとうございます。
では早速やっていきましょう。
私は過去10年間のアーキテクチャ上の最大の間違いの一つというのは、
完全なマイクロサービス化であると確信をしています。
モノリスからマイクロサービスまでのスペクトラムで、私は次のように提案します。
モノリス、アプリ、サービス、マイクロサービスの順番で、
モノリスが一番上なんですね。
モノリス、次にアプリ、次にサービス、最後にマイクロサービスというような順番だそうですね。
意外ですね。モノリシックのほうを最優先の提案とするんですね。
GitHubのCTOが。これ興味深いですね、確かに。
それではいくつか考えていきましょうという導入でした。
まずですけど、これは考え方であってルールではないよというところを前置きされていますね。
一つのこの方の考えている話であって、
こういうルールでやるべきではないよという話ですね。
大規模な分散システムを構築したことがある人なら、
誰でも実際にはそのように機能せず、それに適応していなければならないことを知っています。
第二にステージというのが重要であります。
もしあなたが5人から50人の会社でこれを読んでいるならば、
モノリスにこだわるべきです。私を信じてくださいと。
面白いですね。
5人から50人の会社でマイクロサービスは機能しないよということですね、おそらく。
多分最後にマイクロサービスでわざと出しているんだからマイクロサービスかというのの
03:03
よしよしの話をされるんだろうなというのはよく分かりますけど。
とりあえず会社のステージとして、チームのステージとして
5人から50人の会社なんだったら、まずはモノリスにこだわっていこうというところですね。
分散せず、一つの大きなチームで一枚岩となって動いていくことがまずは大事だということですね。
ここは結構僕も経験ありますからね。
大規模なシステム開発は僕も何回か動画をやらせていただいたんですけど、
本当に超大なシステムになると自社で受け取ったというよりも、
僕は常駐して別の会社さんのお仕事を手伝ったということがあるんですけど、
確かにそこまでいくんだったらマイクロサービス化も大事だと思うんですけど、
一方でマイクロサービスの誰が管理するのかとか、ブリッジエンジニアがすごくコスト高いなってすごく感じましたし、
これのマネージャーってめちゃくちゃ求められる、要求されるレベル高いなってつくづく感じたというのがありますね。
続いていきましょう。
もしあなたが1万人規模の会社でこれを読んでいるのであれば、
おそらくこれら全てをある程度は持っていると思います。
全てって言ってるのは先ほど冒頭に述べた通り、
モノリスとAppsとサービスとマイクロサービス全部ですよね。
全部のパターンを持っていると思いますが、
私の迅速な考えでいきますと、これまでと異なるかもしれないところを以下に示していきます。
まずは流用だそうです。
定義の話をしましょう。
これらの全ての定義、正確な定義があるわけではないですけど、
一旦この方が考える定義というのをここから語っていきましょう。
定義について議論する代わりに私は通常次のようにまずは考えます。
モノリスというところが別のドメインが張られていますね。
xyz.comだから適当なやつかな。
Appsですね。
アプリの方はabc.xyz.comというような感じですね。
のドメインで切っています。
価値とか価値創造の主要なもの、可能なコア要素をいくつかのアプリに制限するということですね。
モノリスについては説明する必要がないということでした。
アプリというのは今言った通りで価値の主要なものとか可能なコア要素とかを
いくつかのアプリに制限して作っていくということです。
ただドメインとしてはモノリスがxyz.comと例えばしたやつをすると
アプリというのはその上にもう一個サブドメインを切った
abc.xyz.comというようなふうにアプリに切り出すということだそうですね。
別URLにするのではなくてサブドメインで切って連携させると。
続いてサービス、サポートアプリ、もしくはモノリス、コアインフラ、
多くの表面積で必要とされるようなコアのコンプライアンス機能とか
アプリチームによって書かれていない可能性があるものとかがあります。
サービスですね。
さっきまでモノリスとアプリの説明で、次はサービスの話で
サポートアプリとかモノリスとかコアインフラとか
多くの表面積で必要とされるようなコアコンプライアンス機能というのが
アプリチームによって書かれていない可能性がある。
インフラがそれを維持するというのがサービスだそうですね。
最後マイクロサービスですけど、
マイクロサービスというのは数百行のコード、ほとんどが1回限りのもの、
06:02
もしくはライブラリやSDKになる可能性が高い、もしくはそうなるべきだというものが
マイクロサービスだと言っています。
SDKかライブラリになるぐらい、結構細かなものになってくるんですね。
数百行のコードというのがマイクロサービスだと言っています。
ここまでの定義をしました。
そんなことはさておき、なぜこういうことなのかというのを話していきましょう。
私の考え方は基本的に次のようなものです。
スピードとリスクだと言っています。
スピードとリスク、品質の話だと思うんですけど、一応読んでいきます。
とりあえずスピード&リスクがJSONさんの考え方だそうです。
エンジニアリングチーム全体が一つの大きなアプリ、
例えばRailsアプリのサイト全体と考えてみましょう。
の中で作業する方がマイクロサービスがどのように失敗するかを考えるより
一般的には簡単ですよと。
そうですね、一つの大きなアプリなので。
今のがA案で、次がBCですね。
B案は分散システム、ディストリビューティッドシステムというのは
成長するにつれて必ず必要になるものではありますが、
独自のリスクプロファイルを持つ何十何百ものマイクロサービスを導入することは
マイクツーでは説明できないほど難しいことです。
まあ、経験していないとこれは分からないかもしれないですね。
一応考えれば多少のリスクがあるとか難易度がどこにあるかというのは予想はつきますけど、
やってみないと出てこない難易度は絶対に出てくると思います。
それはシステムごとによって要件とか仕様が違ったりするので、
それに応じた問題というのがいくつか出るのはよくある話なので。
何十ぐらいのマイクロサービスならぶっちゃけると何とかなるんですけど、
何百までいってしまうと、僕も何百のマイクロサービスは実はやったことがないので、
ここまでいくとかなりカオスな気がしますけどね。
実は使ってませんよというようなサービスもあったりするような気がしたりしますけど。
今のがB案です。
分散システムは成長するにつれて必要になりますが、
独自のプロファイルを持つような何十何百ものマイクロサービスというのは
リクスルでは説明できないほど難しいよねという話でした。
完全マイクロ化はいろんな方もおっしゃってますけど、
あんまりよろしくないと思いますね。
最後、4つ目D案ですね。
D案というのはとっても大きなものです。
あ、ビッグバンって書いてますけど。
オーダーメイドのインフラサービスとかマイクロサービスというのは
それぞれの負債の極端なバージョンであるIMVになってしまいますよと。
コードというのは負債ですけど、サービスはその極端なバージョンになります。
それが自分にとって何を意味するのかというのをよく考えてみてください。
負債とはあったらいいなではなくて、文字通り最も高いレバレッジを発揮するものであるべきだと言っています。
はぁ、はぁ、はぁ、はぁ。
面白いですね。負債って本当ただのマイナス要素としか思ってなかったんですけど、
最も高いレバレッジを発揮するものであるのが負債だと言っているんですね。
09:02
捉え方が面白いですね、これ。
そんな考え方は仕方なかった。
オーダーメイドのインフラサービスはあんまやらんほうがいいなと僕は思いますけど、
一応、ジェイソン・ワーナー氏が言うにはオーダーメイドのインフラサービスとかマイクロサービスというのは
負債の極端なバージョンであるIMVになっていると言っていますので、
そういう捉え方をすると一つの評価にはなるということですね。
高打負債ですけど、いいとは思わないなという感じはしますけどね。
続いて、遅いな、はい来た。
私たちはディストリビューションエンジニアというのが抱えている課題というのは重複を避けたいということです。
そのためいくつかの場所で行われていることを見て、これを取り出してマイクロサービスを作ろうというふうに考えます。
ディストリビューションエンジニアというのがそもそもいるんですね。
どういうことをやるエンジニアなのか、僕も今名前だけだとわからないんですけど。
ちょっと後で調べます。
そういうことを調べつつ、必要なところでマイクロサービスというのを作っていくことを提案していくと。
理論的にはこれで良いんですと。
数十のインスタンスに対して行われるのであればそれは問題ない。
それが数十のマイクロサービスになると、あるいはもっと悪いことに巨大な企業の境界を越えて、
例えばMSだったりGoogleだったりAppleだったりの全てに一つのカラーサービスを提供すると考えてみてくださいと。
そういうものが巨大な企業の境界を越えて、技術的ではなくより組織的な課題にそういうものがなっていくということですね。
むずいですね。理論的にはこれで良い。
ただ、数十のインスタンスが数十であれば特に問題はない。
それがマイクロサービスになると、もっと悪いことになっていく。
イメージは超巨大な企業の境界を越えて、そういうものにカラーサービスを提供すると考えてみて。
1個の巨大企業であれば別に良いんですけど、
MS、Google、Appleのような3つの超巨大な企業を渡り歩いたようなものに対して、
1つのカラーサービスを提供するようなものという風にマイクロサービスを捉えた方が良いよと。
それは危険だな、確かに。
それが何十ものって言ったらそれはそうだ。
それは技術的ではなくより組織的な課題になってきます。
最終的には経営課題にマイクロサービスは結局なりがちだと思います。
私が提示したものは誤った二項対立のように感じられますけども、
実際にはマイクロサービスには明確な技術的課題がありますが、
それ以上に組織的な課題もあります。
私が心配しているのはこの点です。
組織的な課題というのがJSONの話が心配しているところです。
まず最初、第1にインフラというものですね。
インフラは異常にやり気のCEOが率いる会社でない限りは、ほとんどの場合優先順位が低くなってしまいます。
まあ、そうだろうな。
インフラって見えてないというか、
当たり前みたいなものに僕らが勘違いしてしまっているので優先順位が低くなるかもしれないですけど、
ちゃんと当たり前に動いてくれることをやってくれるエンジニアがいるから、
12:04
僕らはその上に乗っかってサーバーサイトでAPIを作ったり、
ウェブフロントエンドのサービスを作ったり、デザインができたりという話なので、
その乗っかっている土台がないことには物事は始まらないのですけど、
確かにインフラは優先順位が低くなると思いますね。
最初の方でインフラ構成だったりネットワーク構成とかを考えて設計して、
そこをインフラエンジニアがガーッと構築するんだなという印象はありますけど、
いろんな会社さんのやり方があるし、
サーバーサイトエンジニアがインフラクラウドまで担保しているという方もいらっしゃれば、
本当に全員が全員フルサイクルエンジニアとして全部やりますよという人たちもいるし、
それは会社によってはマチマチですけど、
うちの場合はインフラは専門部隊がいて、そこに頼るということは結構多いので、
逆に言うとインフラ知識がなかなか乏しいので、
その辺は今は有料すべき点だし、来年どうしようかなというのにも考えたりしていますね。
特に僕はフロントエンドギルドに所属しているので、
余計ですよね、フロントとインフラってかなり遠いので、
ただ知らないといけないところはあるし、
もうフロントエンドやフロントだけで食っていけるみたいな時代はぼちぼち終わるだろうなと僕は思ってはいますね。
結局何か掛け合わせだったり、いろんなマルチスキルが持っているエンジニアがこの先生き残っていくんだろうなというのは何となく思っていますという雑談でした。
とりあえず第一にインフラっていうのは、
そういうやり手のCEOがいるとか、
そういう発言力と権限を持っている人がグイグイ引っ張っていかない限りは優先順位が低くなるでしょうねというのはその通りだと思いました。
二つ目ですね、第二にサービスが多すぎるとですね、
一般的に所有権の欠如とか境界の問題が発生します。
これもその通りだと思います。
このサービス、誰が担保しているとか誰が持っているとかオーナーシップ誰なのっていうところもあるし、
それが人抜けた瞬間に意外と欠如しますよ。
引き継いだとはいえ、もともとのサービスをちゃんと把握している人もいなかったりするしっていうのはあるので。
あとはそのサービス間ですね、マイクロサービス間の連携だったりその境界ですね。
この問題、例えば一つのバグが発生したり何か不具合が起きた時に、
これどこが問題ですかっていう特定がまず大変で、
特定しようにも意外とこっちのこの原因にひも付いてここが起きるけど、
この原因、このチームの中でサービスAとサービスBがあった場合に、
Aが引き起こした何かからBが最後の不具合のキックをしたみたいな感じになるかもしれないですけど、
元を辿っていくとここがそもそも設計良くないみたいな話がいっぱい出てきて、
じゃあどこが担保するのっていうと、
すごい曖昧で責任の押し付け合いみたいな話を僕は何度か経験しているんですけど、
サービス多すぎるっていうとそういうことの確率が上がるので、
まあ怖いよねって感じです。
ただこれは技術の問題じゃなくて完全に組織的なものですとか、
チームビルディング全体の話というか話になる気がしますね。
システム全体の設計になるっていう話もあると思いますけど、
その設計をするには結局組織の話が絶対出てくると思うのでって話でした。
続いて第3ですね。
多すぎるマイクロサービスに対処するために、
15:01
さらに多くのツールを投入することになります。
なるほどです。
普通は辞めればいいんじゃないの?
マイクロサービスやっぱりきついねとか大変だなっていうので、
辞めればいいんじゃないかと思ったりはしますけど、
もちろん辞めてしまったサービスの機能をまたどっかで移植しなきゃいけないので、
それはそれで大変ではあるんですけど、
ただ一方でそのマイクロサービスの対応、
維持するため、もっと良くするために、
他のサービスを入れたりとかツールを導入するっていうのも確かによくある話ですね。
結果ツール地獄になるみたいな話になる気がします。
どっちもどっちですね。
茨の道なかもある。
こうやって聞くとマイクロサービスで悪意にしか聞こえないですけど、
そんなことはもちろんないですよ。
ちゃんと用法・容量とか欲しいところにパチッとはまったら
マイクロサービスでやっぱりいいなと思ったりはします。
それだけだから書籍書かれたりとか、
みんながこうやって導入したりするっていうのはよくある話なので。
最も重要なことっていうのはですね、
ライブラリーとかSDKなどにできた、
もしくはするべきだったマイクロサービスそれぞれが
生産リスクをもたらすということが最も重要なことです。
より多くの行動っていうのは確かにオーバーヘッドであり、
より多くのサービスは顧客が直面する生産体験のリスクになります。
どちらのアプローチもオーバーヘッドやリスクはありますが、
その割合っていうのは実は異なりますよと。
はぁね。
そこで私がお勧めするのは通常次のようなものです。
合計5つですね。
5つの提案があります。
1つ目がまずできるだけ長く1枚岩であること。
これが最初のモノリスっていったお話ですね。
まずは長く1枚岩であることが1つ目。
2つ目はサービス開始っていうのはインフラ側の理由からで、
アプリエンジンからではないと。
はいはい。アプリ側ではなくてインフラ側からの理由で
サービスの開始がキックされるべきですと。
3つ目。モノから脱却する場合、
小規模なサービスじゃなくて大規模なアプリに脱却しましょうと。
ifbreakingoutモノって書いてますから、
モノから脱却する場合1つですね。
いわゆる1枚岩から脱却するときは
小規模なサービスにどんどん切り出していくとかじゃなくて
大規模なまずアプリに脱却、逃げていこうと。
ちょっと規模が大きくてスコープとかレイヤーも増えているけど
でも小さく小さくただ数が少ないアプリに
まずは作っていこうということですね。
いきなりドカンと細分化して
小規模にしていくんではないほうがいいよって話ですね。
なるべくでかいものはでかいまま
ちょっとずつ切り出すのがいいんじゃないのっていう話だと思いますね。
4つ目の提案は
新しいアプリっていうのは社内の仮想的な壁だと考えてください。
面白いですね。壁かーすごいな。
そういう例え方をするんですね。
言いたいことはわかります。
アプリを担当するチームとか責務とか
そこのスコープとかっていうのが
さっき言った通りマイクロサービスで起きる問題は
マイクロチームと同じことが結局起きるんですよね。
そのサービスを結局メンテするのはチームなので
そのチームの人と同じ話が出るっていう話ですね。
そういう壁が生まれるっていうのがなかなか面白い表現でした。
18:00
最後5つ目です。
可能な限りマイクロサービスよりも
ライブラリーっていうのを優先しましょうと。
マイクロサービスは最終的に
ライブラリーとかSDKになるべきだっていうのが
この方の主張です。
なるべくライブラリーっていう風に言うことを優先しましょうと。
例えばカラーサービスを導入したというのは
古典的な例っていうのがあるんですけど
私がサービスよりもライブラリーを選ぶ場合の極端な例として
とても気に入っていますと。
確かに極端な例ではありますが
真髄をついた例として非常に話題になります。
さっきのカラーサービスの導入の例っていうのは
超ビッグ企業ですね。
GoogleだったりMSだったりAppleだったり
共通の一つのカラーコードっていうのを提案するっていうのが
その一つですね。
さっきの古典的な例ですね。
それが古典的で極端な例なんですけど
やっぱりそれは気に入っているというところでした。
そろそろ結論が来そうですね。
ちょっと引用ですけど
バッツ、ジェイソン
でもアマゾンやウーバーはどうなの?
という話ですけど
また別の例ですけど
おいお前はお前だ
私が経験したことは言っただけですと。
全部こっちに考えるので
自分でもちゃんと考えるよってことか。
2つ目にアマゾンのように
サービス提供の義務付けが行われたときに成功したんだら
それは大いに結構だよってことですね。
最後3つ目
これはルールというよりもガイドラインだということですね。
あくまでガイドラインとしてこういうのを持っておく。
道具じゃないですけど
ちゃんと必要であればマイクロサービスを使えばいいじゃんって話で
必ずこういうルールに従わっていかなきゃいけない
という意味ではないよっていう話でした。
それはでっかい企業いっぱいあるし
そりゃそうですけど
他の例を出してたらそりゃキリはなくてですね。
そんな議員の段階みたいな
論理とかルールなんてものは存在しないよって話で
だと僕は解釈しました。
では続いて
世界中の企業の90%っていうのは
プライマリーDBクラフターに対して
DBバックアップだったりキャッシュだったり
プロ機種を実行するモノリスで済ませることができるでしょうと。
この辺はそうですね。
バックアップしたファイルそのものを
どっか別のサーバーに置くぐらいはやるかもしれないですけど
キャッシュもどこか別のCDNだったりとか
Redisだったりとか
いろんなキャッシュのサーバーを作ることもあるかもしれないですけどね。
切り出すことはできなくはないですけど
やっぱりモノリスで実行済ませることが
やっぱりいいなと思いますしね。
ただなんだかんだプロ機種を実行するっていうところがあるんでしょうね。
世界中の企業の90%はそういうのを
実はモノリスで済ませることができるだろうと
やっているという意味ではないんですね。
For the 10%
惑星規模の10%の企業にとって
この問題を解決するのは大変なことです。
洒落じゃないよってことですね。
結果やっぱりマイクロサービスをやって
そこ成功してるっていう事例は確かに僕はあんま聞かないですね。
まずはモノリスでやるっていうのは確かにいい話かもしれないし
モノリスから必要なものを最低限切り出すぐらいが
ちょうどいいスタンスなのかもしれないですね。
結果的にはですね。
分散システムと企業のスケーリングとの組み合わせは非常に複雑で
それを行った人は非常に少ないため
21:01
それらの企業から特定の教訓を引き出すことはやはり困難です。
それぞれの状況や事例が異なるからです。
まあそうよね。
なかなか他に転用できるような事例かっていうと
それは多分そうではないと思いますし
なかなかピンポイントのここだけは
この要素は確かに当てはまるなとか
参考になるなとかはあるかもしれないですけど
私がここで話しているのは
問題にどのようにアプローチするかついての
あくまで考え方ですと言ってます。
最後ですね。これ連追最後です。
そして冒頭の話に戻ります。
モノリス、アプリ、サービス、マイクロサービスの順番ですね。
の優先順位で物事を作っていけばいいよって話ですけど
基本的にはスケールするためのアプローチであって
できるだけ長く一つの大きなものであること
小さすぎるものを過剰に修正することはなく
成長に合わせて、たとえ急成長であっても
それを乗り越えていくことができると。
これは組織や技術に当てはまりますということですね。
技術だけじゃなくて組織にも当てはまるよって話でした。
で、繰り返しますが
これはアートだっていう風に言ってます。
面白いですね。最後。
技術とか組織の誤答について
これをアートだって言っているのは
僕結構この表現が好きですね。
組織とか仕事をアートするっていうような
考え方っていうのが
あんまり浸透はないですけど意外とあってですね。
この考え方で組織とかっていうのを
見ていくっていうのは意外と面白いですね。
アート観点で物事を見ようとするスタンスと
やはり設計者として見るっていうのって
違った観点が見えてきたりするので
アートという観点で組織設計だったり
サービスなし、システム設計を見るのはいいと思いました。
ただ、この方がおっしゃった通りだけど
モノリスがいいっていうのは僕も経験上
そうだなって思う時はあります。
いきなりドラスティックにモノリスから
マイクロサービスまでドーンと飛ぶことは
やはり危険だって言ってますし
大きな課題がたくさん出てくるよと。
1個小さいアプリっていうレイヤーに
切り出しただけでもいきなり壁っていうのが生まれて
そこから責任の話が出たりとか
衝動、コンフリクトも起きるっていう話があったので
これも本当にその通りだって感じました。
というところで今回の連継は以上になりますと。
ここから引用ツイートもたくさんありまして
海外の方がすごいレースで
いろんなコメントをされてるんで
これもちょこちょこ僕がかいつまんで
読んだことありますけど結構面白かったので
それらへんも参考になるので見てみてください。
リプライの中で別の記事のリンクが貼られてあるとか
本当にいろんな方がいろんな考え方を
ガーッと書かれているので
これを読むだけでも参考になるなと思いました。
僕自身はマイクロサービスとして
本当にそんなにちゃんとやったことはないので
1,2案件ぐらい常駐でしかやったことがないので
ちゃんと自分たちがオーナーシップを持って
自分たちの組織をマイクロサービス化するっていうのは
ちょっと考えてみたいなと思いましたし
組織そのものをマイクロサービス化する
マイクロマネジメントっていう別のワードが
出てくるかもしれないですけど
マネジメントとは別で
ちゃんと権限以上をした組織設計したらどうなんだろう
っていうのは気になった感じですね。
でもすごく参考になりましたし
やっぱモノリズがいいんだっていうところは
結構僕も共感するところが多いなと思いました。
ただモノリズ、アプリ、サービス、マイクロサービスって
24:02
4つの切り方をされてますけど
主にやっぱモノリズとアプリとマイクロサービスで
3つ目のサービスっていうレイヤーは
あんまり考えられてないなっていうか
そこはそんなに重要にならない
問題にならないんだろうなってちょっと思いました。
ただ途中の話に出てきましたけど
そのディストリビューティッドシステムとか
あとやっぱりインフラの話ですよね。
インフラエンジニアの話っていうのはすごく
この方がちゃんとおっしゃってくれたっていうのは
すごくいいなと思いました。
結構優先度が低いっていうのは本当にその通りだと思いますけど
インフラ無くしてシステムは動かないっていう話だもん。
ここも観点としては持っておきたいし
インフラはインフレンスに全部任せればいいじゃん
ってなった結果優先度が下がるんだろうなっていう感じがすごくするので
専門家に任せるのはそうですけど
でも専門家とちゃんと会話できたり
その辺技術的なところのお話ができるレベルには
ちゃんと勉強はしておきたいなという風には思った次第ですね。
というところで時間30分過ぎましたので
今日の朝勝は以上にしたいと思います。
後ほどこの本、年追ですね
はリツイートしますので
皆さんの方でも興味があれば読んでみてください。
一個一個は短いので結構読みやすかったですね。
というところで朝勝は以上にしたいと思います。
金曜日ですね、今日週末というところ
週末じゃねえわ
ところで最後頑張っていきたいと思いますけど
ぶっちゃけた毎週金曜日ってもう終わりじゃんっていうのもあって
僕は結構流れ作業間の仕事をするのに
生産性がクソ悪いのが禁愛なんですけど
なんとか仕事をしたという体裁を保ちたいと思います。
頑張っていきたいと思いますので皆さんも頑張っていきましょう。
週末はポケモンを僕は頑張って楽しんでいきたいと思います。
ポケモンがすごく楽しみで仕事にならん気がしますが。
じゃあ終了したいと思います。
今日も参加いただき大変にありがとうございました。お疲れ様です。
