00:06
はい、7月1日ですね。時刻は昨日もありました。
今日から下半期スタートですね。
はい。おはようございます。きみみのきーすことくろはろです。
ではまた本日も朝活を始めていきたいと思います。
はい、まさきろさんご参加ありがとうございます。
昨日はちょっとですね、私がコロナウイルスワクチンのワクチン接種の3回目を受けてきて、
それの副作用でダウンをしていたのでできなかったんですけど、
今日はまたやっていきたいかなと思います。
でですね、今日もタイトルにある通りですけど、
フロントエンドウィークリー東京っていうサイトがあって、
これがいわゆるいろんなフロントエンド周りの記事をウィークリーで、
10個ぐらいピックアップしてまとめたものになりますけども、
これを上からずっとダラダラと読んでいこうかなと思います。
はい、てんきゅうさんですね。ご参加ありがとうございます。
タイトルにある記事をダラダラ読んでいきたいと思います。
えっとですね、このサイトは大体10個ぐらいの記事がバッと書いてあるんですけど、
それをざっと読んでいって、その中で具体的にどの記事を読んでいくかっていうのは、
その場で決めようと思うので、
もしかしたら皆さんの意図にそぐわない記事を読むかもしれないですけど、
そこはご了承くださいって感じですね。
はい、じゃあ行っていきましょう。
一つ目ですね、一つ目はオープンウェブ、Advocacyですね。
これっていうのは何かって言うと、世界中から集まったソフトウェアエンジニアの集団で、
規制当局だったり立法者であったり政策立案者っていうのが、
我々の業界における主要な反競争的問題と、
その解決方法を理解するために必要な複雑な技術的詳細を提供することによって、
オープンウェブの将来を提唱していますと。
オープンウェブの将来について興味があれば、
Discordなどを通じて活動支援できますよと言っています。
オープンウェブ、Advocacyですね。
はい、というのが一つ目でした。
二つ目です。
二つ目は、読み方がまじで分かんない。
CUPIDって何ですかね。
Cupidって読むんですかね。
Cupid for Joyful Codingとです。
Cupidの原則で、ソースコードの品質が良いほどコーディングは楽しいものとなる。
それを実現するための5つのプロパティをCUPIDと定め。
それらが頭文字ですね。
この記事で紹介していますよと。
それぞれの頭文字ですけど、
一つ目はコンポザーブルで構成可能性ですね。
二つ目がユニックスフィロソフィーでユニックス哲学ですと。
三つ目がプリディケイタブルですね。
予測可能性か。
四つ目がイディオマティックで勧誘ですね。
五つ目がドメインベースです。
その頭文字CUPIDを取っているということですね。
というのを原則側のご紹介でした。
続いて三つ目の記事はプロフェッショナルプログラミング
The First 10 Yearsということで
プログラマーとして10年のキャリアから学んだこと
というのを書いていただいてますね。
また全然名前が分からない方ですけど
03:01
そのキャリアを通して学んだことを
記事として紹介してますよということでした。
六つ目ですかね。
え、六つ目?
一、二、三、四つ目ですよね。
はい、四つ目です。
四つ目の記事はプライバシープリンシプルですね。
ウェブのプライバシーに関わるガイデンの定義
そして信頼できるプラットフォームを開発するために
ウェブの開発をガイドするプライバシー原則の
ドラフトノートというところです。
はー、なるほどですね。
原則に関わる話はちょっと僕気になる。
なるほどでした。
で、五つ目。
五つ目はネーミングカラーズインデザインシステム
ということでデザインシステムにおいて
色の名前をどのように付けるかっていう
付けるべきか
スペクトラムのリードコンテンツデザイナーである
ジェスシーがそのアイディアを提案していますよ
ということでした。
うん、これはこれでちょっと気になりますね。
はい。
で、残り五個はインブリーフになってますので
インブリーフだけだったら読んでいきましょうか。
はい。
で、六つ目ですね。
六つ目はLCH is the best color space for UI
ということですね。
はい、Deep Dive into Color Theoryというところで
LCHとはHSLよりも優れている理由
先にどのように明け出すかっていうところを書いている
ということですね。
はい。
で、七つ目。
七つ目はHow we think about UX qualityですね。
ショピファイのUX部門がどのように品質を改善しているか
その事例のメンタルモデルを紹介しますと。
あー、これは気になりますね。
僕ECサイトずっと昔やってたので
ショピファイの話ちょっと気になりますね。
はい、で、八つ目。
こちらはGet to know your browser's performance
パフォーマンスプロファイラーか。
はいはいはい。
ブラウザのパフォーマンスプロファイラーについて紹介しますよ
というところでした。
あー、これもやはり今日全部気になるな。
で、九つ目。
九つ目はReading source code react queryということですね。
React queryのソースコードのリーディングを行って
どのようなテクニックが使われているか解説しますと。
はい、これも読みたいけど
おそらくソースコードのオンパレードで
ラジオ配信ではちょっと向かない気がするので
後ほど皆さんに読んでくださいって感じになりそうですね。
はい、ラスト10個目です。
Kubernetes for frontend developersというところで
我々フロントの開発者のための
Kubernetesの解説をしているそうです。
はい、これも気になるけど
設定もありや何やらのソースコードで
いくんじゃないかって気はしますので。
えー、悩ましいですね。
今以上10個の中でどれが悩ましいかね。
読みたいかってすごく悩むんですけど。
個人的にパッと記事開いて
読みやすそうだったものは
さっき言ってたCupidの法則ですね。
これCupidって読むのか本当に知らないですけど。
読みたいがめちゃめちゃ膨大な量なんで
これ今日中に読み切らん気がします。
続いていくとなれば
さっき出てきた
プログラマーとして10年のキャリアから
学んできたこととかっていう
無難な記事になっちゃいそうですね。
こっちもちょっと長い。
06:02
どれもこれも長いな。
そうすれば
ショピファイの話にいこうかな。
メンタルモデルなんでちょっとプログラミング感
あんまり技術的な話じゃなさそうな気がしますけど
とりあえずこちらがちょっと短そうだったんで
読んでいこうかなと思います。
How we think about UX qualityのところを
ちょっと読んでいこうかなと思います。
ちょっとフロントエンドエンジニアとしての
技術的な話ではないので
皆さんも興味ない話かもしれないですけど
ご了承って感じですね。
いきましょう。
今回の記事ですけども
書かれている方はサディ・レデンさんですね。
読み方合ってるかわからないですけど
外国人の方ですね。
じゃあ早速この辺を読んでいこうと思います。
いつも通り翻訳します。
じゃあいきましょう。
UX品質についてどう考えるかということですね。
新しいチームがショピファイの管理画面における
デザインの塞いに対処しています
ということでした。
この記事は厳密に言うと
サディ・レデンさんと
ジョーダン・オーレットさんの
2人で書かれてるそうですね。
いきましょう。
ショピファイでは誰もが品質に対して
責任を負っています。
しかし時には品質に特化したスペースが
必要なこともあります。
それはまさにショピファイの新しいチームの
行っていることです。
我々のチームはショピファイの管理画面全体を
水平に渡すことに注力をしています。
視覚的なデザインの調整から
ページやコンポーネントなど
コンポーネント的な再構築まで
品質に関する問題に取り組んでいます。
チームには私たち
私たちっていうのはシニアスタッフ
プロダクトデザイナーとかシニアコンテンツデザイン
スタッフデベロッパーのマーク・トーマスなどが
参加しています。
理想的な組織であれば
私たちのチームは存在する必要がないと
言われています。
自分たちも言ってるそうですね。
しかし私たちは理想を追い求めて
仕事をしているわけではありませんし
今後もそうなることはないでしょうと
それはそれで問題なんですけどと言ってますね。
なるほど。
理想を求めることは確かに
やるべきだと思うんですけど
今後もそうならないらしいですね。
へぇー。
我々の理想と
実際の需要とか
現場とかでどういうことを求めるのか
という話があったりすると思うので
現場主義の方々なんだろうなという印象を
受けましたね。
はい。
我々はAdminに多くの改良を加えて
リリースしていますと。
この記事の後半でそのうちのいくつかを
紹介します。
またブログやソーシャルメディアに投稿する
一連の記事の一部として
リリースされた改良点についても振り返る予定です。
このブログ記事っていうのは
全体的な品質を向上させるという
私たちの幅広い目標の中で
これらの前進的な改善を位置づけることを
目的としています。
また他のチームが同じように
品質にアプローチできるように
リリースしている品質に関するメンタルモデルの
概要も紹介します。
09:01
ぜひ参考にしてくださいよということでした。
これがいくつかの項目ごとに
分かれているっぽいですね。
はい。
それを一個一個言っていきましょう。
一つ目は
ナビゲートデザインデッドということですね。
デザインの塞いをまずナビゲートしましょう
というところでした。
一つ目いきましょう。我々の仕事を
理解するためには初期界の管理画面の
背景を理解することが重要です。
これはアプリケーションなら絶対そうですよ。
ショピファイの管理画面というのは
2006年頃から何年もかけて
多くの人の手によって
建てられ、改装され、装飾され
いろいろメンテナンスされてきた
というところですね。
本当に大きな家のようなものですと。
しかしあるものは早く作らなければならず
またあるものは私たちが最終的に作ったような構造を
支えることを意図していない土台の上に
作られたものでした。
長いな。まあまあ。
そしてこの数年の間に多くの変化がありました。
我々は成長し続けます。
市場も変化し続け
雑多なものが積み重なっていってますと。
これらは全て人の高いユーザー
エクスペリエンスに影響を及ぼしますと。
まあそれはそうでしょう。
どのアプリケーションもそうだと思いますし。
僕は昔試作をずっと作ってたんですけど
やっぱり長くなればなるほど
やっぱり現在の市場が
やっぱりどんどん変わっていくので
ニーズが変わっていくんですよね。
なのでこの機能そもそもいらなかったりねとか
この機能としては欲しいんだけど
求めてるバリューが出てないよねとか
結構あったりするし
明らかさまに使ってないものが
たくさん出てきたりするんですよね。
というところでエクスペリエンスに
どんどん影響を及ぼすのは
本当によくある話だなと思いました。
我々のチームっていうのは
この現状を率直に受け止めて
片付けを行うことをやり遂げました。
変化はもちろん簡単ではないし
労力も大変でしょうと思ってますね。
ショピファイはあっという間に大きくなったので
細部にこだわるのではなく
素早くコーチルックすることに
頭を悩ませていました。
それは昔の話で
現在は我々の間では意識を変え
行動を変えていきたいという思いが高まっています。
確かにショピファイって
一気に
市場に出てきたというか
知名度も上がっていったという印象はありますね。
昔だと
何ですかね、分かんないです。
僕がECサイトを作ってた頃は
ECビーングであったりECキューブみたいな
パッケージソフトがあって
それ以外にも
ECサイトパッケージソフトって
結構あったんですけど
僕がやっていた職場では
そういうものを使ってました。
厳密に言うと
ECビーングは使ってなくて
それはライバル企業だったんですけど
というところですね。
続いての話です。
続いてはプロダクターザピラミッドというところで
ピラミッドとしての製品というタイトルですね。
どういうことだろう。
読んでいきましょう。
ショピファインの管理画面の様々な部分を
どのように再構築し
再編成しているか
というのを説明するために
我々の作業に対するメンタルモデルを
とりあえず用意します。
高品質な製品というのは重要なレイヤーの
ピラミッドになります。
12:01
これらのレイヤーのうち
一つでも欠ければ製品に隙間ができてしまい
低品質なエクスペリエンスが生まれてしまいます。
そしてもちろん
これらのレイヤーの間にはグラデーションがあります。
ではそのレイヤーとは何でしょうか。
ピラミッドのような図があって
大きく3つのレイヤーに分かれています。
一番下にある
基本的な
UXのレイヤーです。
ファンダメンタルです。
ユーザーフローであったり
情報のアーキテクチャーであったり
コンテンツだったり、データモデリングなど
問題を本質的な部分まで絞り込んで
正しい問題解決につなげるレイヤーだそうです。
2つ目のレイヤーは
ビジュアルデザインというところですね。
これは美的感覚で
表現されることもありがたが
UXの職人芸の域だと言っています。
ビジュアルデザインとは
ビジュアルデザインのテクニックを活用し
基本レイヤー
を洗練させた意味のある方法で
表現することをやっています。
例えば
読めない
読めないに英語が多すぎるな。
ヒエラルキーか。
ヒエラルキースペースと呼ばれる
階層的な配置がその例ですね。
なるほど。
ビジュアルデザインとは
ビジュアルデザインのテクニックを駆使して
基本的なレイヤーを意味のある形で表現することを
とりあえず意味しています。
最後かな。
違うわ。
続いてが
なんだっけ。
英文を。
ヒエラルキーのオブ
なんちゃらかんちゃら
エレベンツか。
はいはいはい。
確かに訳がちょっと難しいな。
はいはい。
とりあえずビジュアルデザインとは
ビジュアルデザインのテクニックを駆使して
基本的なレイヤーを意味のある形で表現することを
意味するような要素です。
はい。
ポラリスなどのデザインシステム
とか要素
要素やコンポーネント、レイアウトなど
多くの場合この要素をすぐに提供してくれるようになります。
ポラリスというのは
僕は存じ上げないんですけど。
しかしこれらが販売店なのにとって
最適で使い勝手の良い体験
になるようにすることがもちろん重要です。
箱の中に入っているものを
要素やコンポーネントの形にして
意味のあるエクスペリエンスにする必要があるんですよ
と言ってました。
この辺がデザインシステムの領域だそうです。
ラストですね。
3つ目。ピラミッドのトップの要素ですけど
そのレイヤーは磨きだと言ってますね。
はい。ポリッシュですね。
磨きのレイヤーですと。
これはレストランでシェフの料理を味わうようなものと考えています。
はい。
しかしどの食材、調味料、味のバランスに
特定することはできません。
その違うと感じる部分を特定するのは
とても大変な作業です。
しかし一度そこに到達し
細部にまでこだわると驚くほど味が変わるのです。
うん。
磨き上げられたレイヤーでは
そのような細部にまで
気を配ることが重要です。
フロントエンドでは10ピクセルの追加になるかもしれませんが
15:01
ディテールは関係性を持ち
意味や階層を提供しています。
このような最終的なディテールを100%にするために
フロントエンドの開発者が取り組んでいる
プルリクエストの
ローカルバージョンを実行し
ブラウザでインスペクトを使って
問題を探し、モックアップと比較するアプローチを
今のところとっています。
一方では地道な作業をしているという感じですね。
ショピファイでは。
はい。
フロントエンドで最終的にやることが
単純に10ピクセルの
余白とかの追加になるかもしれないけど
そこはやっぱりUXの人たちが考えた
関係性だったり意味とか階層というのがあって
それを
現実に落とし込むためにやっていることだということですね。
まあちょっと意味がちゃんと
分からないと僕らにとってもこれ何でやねん
というのは思うかもしれないですけど
そういう意図があってやっているということを言っているんじゃないかなと
勝手に考えました。
このピラミッド型のアプローチは
なぜその作業が重要なのかを
ステークホルダーに説明するのに役立つだけではなく
私たちが対処しようとしている品質の問題が
どこにあるのかを
理解するのにも役立ちます。
またプロジェクトや機械を特定するための
レンズとしてもこのピラミッドを使用しています。
これからピラミッドの上層部まで
及んでいるようなプロジェクトというのは
不細に取り組むよりも
遥かに長い時間がかかると思われます。
一般に私たちは一度に
複数の大きなプロジェクトを
進行させたくはありません。
しかしピラミッドの中間層と最上層を
改善する必要があるプロジェクトでは
いくつかのプロジェクトを同時に進めることができますと
言っていますね。
引き続きどんどん行きましょう。
今のがいわゆる
メンタルモデルと言われるものですね。
3階層のピラミッドでした。
続いて
シッピングビジュアルチェンジ
送料のビジュアルの変更と言っていますが
本当に送料と訳して
合っているのかな?
画像を見てますけど
送料ではなくて
配送だと思いますね。
配送のビジュアルの変更だらしいですね。
最近のミドルレイヤープロジェクトの
一つに
販売者が出荷する商品の
送料とか配送を設定する
設定のカードっていうのがあるんですけど
これらは基本的に
全く同じものを異なる方法で
表現することで販売者が対話するための
ユーザーインターフェースの
明確なモデルを作り、より作りやすい
エクスペリエンスを
使いやすいか、エクスペリエンスを実現した一例になります。
配送周りのビジュアルは
すごく大事なんですよね。
ECサイトをやるときには。
いろんなところと連携しますしね。
会社もそうですし、機関運賃システムもそうですし、
在庫管理もそうですし。
その辺に関わる人たちとか
実際に管理をする人たちもそうですよね。
ECサイトで
サイト自体を管理する人たちもそうですし。
そこのビジュアルとか
見た目が使いやすくなればなるほど
それは体験が良くなるし、ビジネスが早くなりますので
そこは大事だよなと思いますね。
これは美的なプロジェクトじゃなくて
18:01
ユーザビリティのプロジェクトでした。
デザイナルデザインのテクニックを使って
より有意義な方法で問題を解決しているのですよ
と言ってますね。
うん。
まさにその通りって感じですね。
一応図示されてるんですけど
図的には
左から右にビフォーアフターがあって
ざっくり言うと
見た目をしっかりコンパクトにして
なおかつ
割とちゃんと余白をつけた感じですね。
テキストもかなり減らしてます。
項目ごとにしっかりカードに分離させてる感じですね。
確かに見やすくなったと思います。
前のビフォーアの方は
ただただ上から順に
ラレツがある感じですね。
それは見づらいなって感じでした。
はーい。
続けますね。
また先週、また価格とプランのページに
改良を加えまして
ページ全体の階層構造とか
視覚的リズムであったり
および認知的塞いというのを改善しました。
これは現在販売店様向けの
新しいベースラインエクスペリエンスとなっています。
成長チームというのは
この変更の
より良く理解するための実験として
この変更を最初にリリースし
コンバージョンが増加するようになりました。
しかしこの実験によって
情報のビジュアル表現以外に
根本的な変更がないため
ビジュアルデザインの細部までこだわることの
重要性とインパクトが証明されましたよと言ってますね。
なるほど。
なるほどですね。
一応今のが
また次の図でガーッと出てきてるんですけど
全体的に今言った通りの感じですね。
ほい。
で、えーっと
もうちょいですね。
次がセクションとしてはラストですね。
次のセクションは
Excellence
Not Perfection
って言ってますね。
完璧ではなくて卓越というか
素晴らしいというかそういう意味なのですね。
はい。
いきましょう。このような変更を加えることは
細部にわたっていわゆるゾクゾクするような
仕事になるよと言ってます。
しかし我々は単に汗をかくだけではなく
細部をリリースすることに重点を置いてます。
もちろん完璧さではなくて
その卓越性ですね。
Excellenceに焦点を当てて
いたいのですと。
つまり最善を尽くし、誠実に決断し
好奇心を持ち続け直感と繋がる
ということですと。
このマインド本当にいい子だと思いますね。
正直完璧さを求めるっていうのは
難しいというか、誰にとって完璧なのかって
定義をすることすら
すごく難しいと思うんですよね。
確かに完璧さを求めるのは
ナンセンスな気が僕はしてます。
はい。
完璧でないことに不安を感じないようになるらしいですね。
これをやっていくと。
完璧を求めると麻痺してしまいますと。
最初は完璧でないものを出荷してもいいのですと。
それもありますね。
早くリリースするっていう観点でも確かにそうですね。
出荷することは
旅の一部であり次のイテレーションの
一歩手前なんですと。
自分の作品にどのように優れた点があるかって
あるいは現れないかを知るためには
自分の作品を明確に見る必要がありますと。
21:01
我々は常に
ピッカピカの最新機能をリリースしてから
次の機能リリースへと
飛び回っているわけにはいけませんと。
ある機能が本当に完成したわけではないことを
認識するために
スケジュールを確認する必要があります。
それもそうだよね。
不完全でもいいから一旦出してみて
そこからリファクタリングだったり改善をするので
次の機能リリースへと
飛び回るわけでは
確かにいかないなと思いますよね。
我々が望む変化の一つは
ショピファイでより多くのチームが
10%の時間を品質問題の解決に費やし
実行と反省として
再構築の循環プロセスの一部として
取り組むようになることです。
望む変化の一つってことは
まだできていないのか。
けど、多くのチームが
10%の時間を品質問題の解決に費やす
っていうところですね。
これやっぱりプロダクト開発をやっている会社ならではの
議論って感じですね。
なるほど。
言うて
住宅も一緒か。
ちゃんと品質を求めるんだったらそこに対して
時間をちゃんと取りにいくっていうのは
大事な話だと思います。
そして我々が構築したものを維持するための
必要な時間を
インセンティブによって確保することです。
優れたものを維持するためには
反復し細部にまでこだわる時間が必要です。
我々が望む変化の一つは
ショピファイでより多くのチームが
実行と反省そして再構築という
一環として品質問題への取り組みに
10%時間を費やすことです。
と言ってますね。
なるほどですね。
一環として品質も取り組む
だから全部やるってことを
最終的には言いたいのか。
その循環プロセスがすごく大事なので
そのプロセス自体を大事にしていきたい。
その中の品質問題にちゃんと10%の時間を
費やすことですね。
結果的に10%の時間を
費やさない可能性もありますけど
それはそれでいい話だと思うので
最低でも10%ってことだと思います。
やっぱりプロダクト開発をやっている中で
品質ってのは本当に大きな課題ですからね。
じゃあラスト、コンクルージョンですね。
アトメです。
UXデザインというのは科学であり
芸術でもあります。ニュアンスの違いもあり
主観的なものもあります。
我々の品質向上には数値化できないものも
ありますし、これからもそうでしょう。
また我々が変更した
ことの中には個々の数字が
動かなかったりとか、製品を使っている
人たちの間で優位に立てなかったりするものも
あります。これは私たちの長期的な
ゲームなんですよ。
私たちが変更することの中には
個々に数字を動かしたり、製品を
使用する人たちは優位に立たせたりすることも
あります。
優れた体験を実現するために
最後にわたって
汗を流しリリースする。その積み重ねが
本当にいい製品を生み出し
多くの人を動かすのです。
製品設計の品質に
10%投資することで
100%良くなるのです。
1つのチームだけでは
管理画面や初期ファイ全体の高い品質を確保することが
できません。また、突然文化的な
変化が起こり、全てのチームが突然
品質の問題を解決するようになることを
24:00
期待するのはあまりにも野心的です。
我々は今
移行期にあって、その解決策は
バランスを取ることなんですよと言っています。
チームの存在そのものが
この文化的な変化はどのようなもので
なぜそれが重要なのかっていうのを
社内の他のメンバーに説明するための
デモンストレーションとなるのです。
我々は初期ファイの品質に対するコミットメントを
我々自体が体現をしているよ
ということでした。
というので、いったんこの記事は終了
というところですね。
時間的にもいい感じですかね。
ちょっと早いかもしれないですけど。
以上、How we think about UX Quality
ということで、初期ファイの
中の人たちがUX Qualityを
どういう風に考えているのかっていうところのお話でした。
とても
共感の深い記事だと
僕としては思いますね。
結構学びもあったと思いますけど。
途中で出てきたメンタルモデルのところも
割と面白かったですね。
ここを、ただUXなんて
基本的なデザイナーチームだと思うんですけど
のところの話がしっかり
言語化されているというのはいい話だなと思いましたね。
ただ途中でやっぱり
フロントエンドの開発者も
若干触れていたところもあって
やっぱり一つのチームとなって
一丸となり動けていることっていうのも結構重要かな
と思ったし、ショップ会の中の人たちは
そういうことが描けているんだろうな
という風に感じましたね。
はい。
でまた、結構リリースサイクルを
早めているんだろうなっていうのはなんとなく思いましたね。
はい。
うん、なんか
本当にいいチームだなっていう風に感じたっていう
ただただ感想になってしまうんですけど。
もう少し理論的な話があるかと思ったらそうではなかったですけど
でもこのやっぱりメンタルモデルって
みんな動いているっていう
根本があるのはすごく大事なことだと思いますね。
根本になればなるほど人間ってやっぱり
性格だったり価値観の違いとか
動き方も全然変わってくるんですけど
その根本マインドっていうところを統一というか
意思の
認識の合意が取れているというのは
すごくいいなと思っているので
この辺はちょっと真似したいかなという風に思いましたね。
はい。
というわけで、残り時間
残り2,3分しかないですと
残りの時間で読める記事が
たぶん1個もないので
一旦今日の発表はちょっと短いですけど
こちらで以上にしようかなと思います。
次回明日はですね
明日はすごく気になってた
さっき言ってた
CUPID
For Joyful Coding
コーディングに関する
5つの
プロパティですね
っていうのを紹介している記事があるので
それをちょっと読んでいこうかなと思います。
コードの品質に関する記事だと思いますけど
これがちょっと長いので
もしかしたら明日は1日で終わらないかもしれないですけど
明日はその辺を読んでいこうかなと思います。
で、幸いにも
記事の中見ているんですけど
ソースコードほぼほぼ出てこないので
結構読みやすいのかなと思いました。
じゃあ、そんな感じで
明日もやっていきたいなと思います。
では、一旦今日の朝活はこちらで以上にしたいかなと思います。
本日もたくさんの方ご参加いただき
ありがとうございました。
金曜日ですね。今日もお仕事頑張って
土日ゆっくり休日を過ごしていただければなと思います。
では、
27:00
終了です。お疲れ様です。
