「関係」で結んでみる その1 〜TM技術を使ってモデルベースドテストの可能性を考える(第3回)〜
目次
前回の振り返り
前回の投稿「テストすべき対象を「並べる」 〜TM技術を使ってモデルベースドテストの可能性を考える(第2回)〜」にて、「モノの並べ方」を解説しました。 今日は、並べたものを「関係で結ぶ」ことをテスト対象に対してどのように結ぶかを書いていきます！
参照元は、事業分析・データ設計のためのモデル作成技術入門から学んだことから書いていきます。
テスト業務における「関係で結ぶ」こととは？
結び方を書く前に、「テスト業務において、関係とはどのようなものなのか？」について書いていきたいと思います。
主に、2つのことがわかってくるものと考えます。
- 「濃度」：テスト対象の規模感がわかる
- 「順序」：テスト対象の流れがわかる
EventとResourceの数 = "各集合の数"で、全体の規模感を表していますが、関係で結ぶことによって「関連の数 = 集合同士が関連する数」を表すことが出来ると思います。
元々、集合論における濃度とは「有限集合において、"元の数"を一般の集合に拡張したもの」であり、その様式でここで表すと、EventとResourceの「要素の数」を指すことになります。
ただ、テスト業務においては「1つの機能が、他の機能に対してどれくらいの機能が関連しているか」。もっというと、「テスト対象の1つの要素が、他の1つの機能に影響するのか。または、多くの機能に影響するのか」といった、影響の数を考慮することがあります。
これはテスト計画や分析、特にテスト設計においては以下の事を考慮して、テスト設計することがあります。
- 組み合わせのパターン(テストマトリクスなどの導出)
- デシジョンテーブルの条件
- n因子間網羅の要素や水準の数
上記を考慮し、テスト技法を用いてテスト設計は実行していきます。その際に、1枚の絵(TM技術で表した現実的写像 = システム・プロダクトのモデル図)で見れたほうが、パッと見れてその量感がわかりやすいと考えます。
順序については、「順番をある基準で並べたもの」と考えると以下のことがわかると考えます。
- 機能同士の帰属関係
- 処理の順序
- その処理のやり取りの方向(一方向なのか、双方向なのか)
これも、テスト設計やテスト実装においてテストケースの実行する順番を記述する際に、作成したモデル図から導出して記述できると考えます。
課題
とはいえ、当初から言及している「パッと見てとれる」ことに対して有用に思えるモデル図ですが、課題として「テスト観点漏れ(テスト対象の機能の内容を見落として観点が抜ける)の心配はないのか？」という点が挙げられると思われます。テスト設計において、テスト観点漏れは「一番気をつけなければならないこと」なので、この記事を読んでいる方にとっては、心配事の一つといえます。
また、他にも課題がいくつかあると考えられますがその件については、今後の記事にて、実際の現場での使用感や所感などを含めて書いていこうと思います。
おわりに
記事投稿が遅れてしまい、申し訳ないです。 前回の記事投稿から、いろいろとアクティビティが増えました(笑)
その中で、JSTQB Foundation Levelを合格し、やっとこさテストエンジニア・QAエンジニアとして「一人前」をもらったような気がして、ますます記事投稿に対して気が引き締まる思いであります。
次の投稿ではいよいよ、「関係の結び方」について投稿する予定です！ 2023年中に、投稿できるよう頑張ります！(できたら、いいなぁ)
ここまで、読んでくださりありがとうございます！
では、また！
テストすべき対象を「並べる」 〜TM技術を使ってモデルベースドテストの可能性を考える(第2回)〜
目次
前回の振り返り
前回の投稿「テストすべき対象は、「モノの集め方」によって決まる 〜TM技術を使ってモデルベースドテストの可能性を考える(第1回)〜」にて、テスト対象の集め方、もとい「モノの集め方」について、T字書式にてまとめる方法を投稿しました。
今回はその集めたものを、「並べる」ことについて書いていきます。
参照元は前回と同様、事業分析・データ設計のためのモデル作成技術入門から学んだことから書いていきます。
モノを並べる、とその前に…
本編に行く前に…
前回の「テストすべき対象は、「モノの集め方」によって決まる 〜TM技術を使ってモデルベースドテストの可能性を考える(第1回)〜」で、一つ書き忘れたことがありますので、それを書きます！ ※書き忘れて、すみません🙇
「モノを集める」の追加工程
T字書式で集めた後に、さらに以下の作業を実行します。
- 追加する作業：「1つの個体指定子について、1つのT字書式を作ってその他の項目(attribute)を"分ける"」
左側に記載した個体指定子から、更に1つの個体指定子ごとに1つのT字書式を作って、その他項目(attribute)を、対応する個体指定子ごとに分ける作業を実行します。こうすることで、モノを並べるときに「それがどういうモノなのか」を分かりやすくすることにより、並べやすくなると思います。
また、「現実的事態を写像する構造物」において、作成するモデルは、品質が保たれるとも考えます。
- 論理的に構築することによる、完全性または信頼性
- カスタマイズしやすいことによる、拡張性
- 修正や追加しやすいことによる、保守性
- モデルを継続して使用できることによる、可用性
- テスト対象・観点などを導出しやすくなることによる、使用性
- AのテストプロジェクトとBのテストプロジェクトで、名前が変わっても種別が同じテストプロジェクトで、作成したモデルの一部または全てを再利用することができることによる、互換性
- 別の環境・領域に変わっても容易に移行することができることによる、移植性
ここまで記載して、お気づきかと思いますがこのTM技術によるモデルは所謂「品質特性である「非機能要件が満たされる」※」ことに繋がると考えます。 ※「拡張性」を除いた品質特性
それらを、これからの投稿で示して行く予定です。
テスト対象を並べる
本筋に戻りまして、ここから集めたモノの「並べ方」について述べたいと思います。
まずは、T字書式で分けたモノを以下のカテゴリーに分類します。
- Event：その他の項目(attribute)に日付が入っているもの
- Resource：Event以外のもの
Eventは、日付が入っているモノを指します。例えば、以下のような日付が入っているものです。 - 保存した日 - 作成した日 - 更新した日 など
Resourceは、Event以外のモノで日付が入っていないものになります。
これらの2つのカテゴリに、Eventには「E」、そしてResourceには「R」というラベルをつけて分類します。
分類し終わったら、Eventを時系列に従って左から順に並べていきます。 例えば、ファイルを生成するシステムの場合、以下のEvent持っていると仮定します。
- ファイル生成のシステム(EventのT字書式で作成したモノと想定)
- ⚫︎新規作成
- ⚫︎保存
- ⚫︎更新
これらを「新規作成→保存→更新」の順に、各Eventの集まりを左から右に並べていきます。
Eventが並べられたら、Resourceの集まりをEventが配置している周り(上下)に配置していきます。
これだけです。
並べてみて判明すること
この「並べる」工程により、テストするシステム・プロダクトが「変化に強いシステム・またはプロダクトかどうか判断できる」とのことです。 ※Resourceの数 > Eventの数(Resourceの数が、Eventの数より多い)になっていれば、変化に強いものになっているとのことです。
ここから、テストするシステム・プロダクトに対して「そのシステム・プロダクトの仕様に対して、不足・欠損していることから起因する不具合の要否」が分かると考えます。 つまり、仕様の不具合がある程度そこで判明できるです。
課題
「時系列にEventを並べる」について、ここは開発側と一緒に確認しながら並べていく必要があると思いました。
具体的な機能処理を並べる訳なので、関連する領域ごとのシステムやプロダクトの処理の流れが分かっている場合、ある程度並べた後で開発チームに見てもらうといったことが有益でしょう。
逆に、処理の流れが分からなかったときは、開発側のエンジニア・プログラマーの方と一緒に、共通の理解を得ながら作業していくことが必要です。
おわりに
今回は、「モノを並べる」について書いていきました。
今週は、内容を凝縮して書いていきましたが、文章の適切なバランスをとるのって難しいですね😓
次は、「関係するモノを線で引く」について複数回に分けて投稿しようかと思います。
今回も、貴重なお時間を割いて本記事を読んでいただき、ありがとうございます。
では、また！
テストすべき対象は、「モノの集め方」によって決まる 〜TM技術を使ってモデルベースドテストの可能性を考える(第1回)〜
目次
はじめに
今日は、テスト計画やテスト分析、またテスト設計といった「テスト活動」において、「効果的にテスト対象を見つける方法」についてお話ししたいと思います。
基となっているのは、事業分析・データ設計で長く活用されている「モデル作成技術」です。
やり方をざっくり言うと、「モノを集めて、並べて、関係するモノを線で引き、クラス使ってセット(集合)に整える」になります。
背景にあるのは、以下の3つ。 - システムやプロダクトが複雑になればなるほど、全てを把握するのに時間がかかる。 - ドキュメントに書き起こす際に冗長的になりやすく、作るのに時間がかかる。 - 情報が整理しずらく、抽出漏れや観点の抜けといったことが起きやすくなる。
上記の3つにより、「高い品質のシステムやプロダクト」が作り辛くなってしまいます。
今までのやり方と、どう違うのか
今まで、様々な領域のテスト業務(システム開発では、通信系・銀行系・官公庁など。その他に、ゲーム開発や組み込み)をしてきた中で感じたのは 「インプットのドキュメントの書式、特に内容に対する書き方が、プロジェクトや領域・会社ごと・書く人によってバラバラで、読み解くのに時間がかかる」です。
前回の投稿「テスト業務である困りごとを「TM技術を使った、MBT(モデルベースドテスト)」で解決出来ないか？」にて、「困りごと3つ」を挙げました。
前回は長々と書いてしまい、根本的な問題について記事で言えなかったのですが、中でも一番言いたいのは、「書き分ける事により、時間がとられてしまい、テストに関わるドキュメントに対して、観点漏れや抜け漏れが多くなっていく」。
それによって最終的には、担保すべき品質が基準のレベルに達することが出来ない。システムやプロダクトの価値が下がってしまう、という事です。
なぜ時間がとられてしまうのか。これについては、前回の繰り返しになるので詳細は省きます。
「紙っぺら一枚でまとめられて、プロジェクトに関わる人たち、ひいてはユーザー含めてみんなが、仕様や機能がパッと見て理解できるようなモノってないだろうか。というか、欲しいっ！」
そんな中で出会ったのが、佐藤正美さんの著書でした。
「モデル作成技術」とはなにか
ここで言う「モデル作成技術」とは、TM(Theory of Models)技術を考案した佐藤正美さんの著書「事業分析・データ設計のためのモデル作成技術入門 技術評論社」から、事業分析やデータ設計で使われているモデル作成技術「TM」(T字型ER図を使ったモデル作成技術)のことを言います。
「モノを集めて、並べて、関係するモノを線で引き、クラス使ってセット(集合)に整える」。そのように作った一枚のモデル図から、事業を分析することにより、関わるすべての人と共通の認識を持ち、変化に強いシステムを構築することができる。
自分が思ってたこと、悩んでたこと、考えていたことに対する「答え」がそこにありました。
「そっか、モデルを作れば良いのか」
テストに導入出来そうなところはあるか？
作成したモデルには次の2点が現れると言います。
①事業構造が内包している強み・弱み ②事業構造が内包している環境適応力 出典：佐藤正美 著 事業分析・データ設計のためのモデル作成技術入門 技術評論社
「弱み」という部分を、テストに置き換えると以下のように捉えることができそうです。
- 欠陥(バグ)の原因となる
- •不足している部分
- •不明確な部分
- •不明瞭な部分
- 機能テスト(目的3つ)
- 機能完全性
- 機能正確性
- 機能適応性
- 非機能テスト(品質特性7つ)
- 性能効率性
- 互換性
- 移植性
- 使用性
- 信頼性
- セキュリティ
- 保守性
- 画面上に表示される情報名
- データ(各種ファイル、バイナリデータなど)に含まれる情報名
- 情報名
- 個体指定子("番号"や"数字のコード"が記述しているモノ。「xx番号」とか「〇〇コード」といった番号が付与されている)
- その他の項目("attribute"：属性のこと。個体指定子に付随している項目)
- ポイント：その他の項目を一意であるか(ユニークか)どうか、モノを集める段階では考えなくてOK
- 注意：管理対象となる「個体指定子」や「その他の項目」を、「勝手に変えて書いたりしない(変形しない)」。オリジナルのまま、そのまま書く
- システムやプロダクトを作る人が、問題解決やコミュニケーションの分野で使う思考法「具体↔︎抽象」
- 「モデルベースドテスト」で使われているモデル
この段階で、不具合(バグ)を発見することが可能。
また、システムやプロダクトの全体を俯瞰的に見た時に「テストすべき対象の要素」を導くことが出来る。 ※この点においては、後日「どのように導出するか」を述べたいと思います。
「環境適応力」についても、以下のテストタイプごとの目的や品質特性から「何を、どこで、どのようにテストするのか」を導出することも可能ではないかと思います。
ブラックボックステストやホワイトボックステストについても、それぞれのテスト技法やテスト手法からも、同じように導出することも可能だと考えます。
モノを集める
では、TM技術によるモデル作成の最初の工程「モノを集める」は、どのような方法なのか。どのようにして、集めるのか。
では、さっそく見てみましょう。
モノを集める→「情報」を集める
「モノを集めるとは、何か？」。もっというと、「集める"モノ"とは、一体どういうのを指すのか」。場所はどこ？何を見るの？
それは、「情報」です。
皆様から、「当たり前の事を言うなっ！」と、突っ込まれそうですが、そうなのです。「情報」です。
具体的にいうと、以下の二つになると考えます。
そして、その情報の集合は、
そう、「画面」や「データ」に集められていますよね。
とすれば、仕様書が仮になくても「システムやプロダクトに表示している情報」や「出力、参照しているデータの中身」から、テストに必要な情報を集めれば良い。
これで、場所や何を見れば良いのかわかりました。
あとは、「どう集めるか」です。
テスト対象の集め方
お待たせしました。ここから、技術的な本文に入ります。 ※待たせ過ぎかも、しれません。
ここから、 事業分析・データ設計のためのモデル作成技術入門について学んだことから、テスト対象の集め方について書いて行きます。
情報が集合している場所はわかったので、今度は「T字書式」に集めていきます。
T字書式については、上記書籍にてご確認ください。 ※図に出来なくて心苦しいのですが、すみません。もし、図にできるようになったら更新して載せる予定です。
そのT字書記の中に、
を、T字書式の「上側」「左側」「右側」の順で書いていきます。
ここでポイントと注意点が、各1つづつあります。
モノを集める段階では文脈、つまりは「構造」が判明していないので、とりあえず対応している個体指定子の箱に書いておく、とのことです。
今の「モノを集める」段階では、そのシステムやプロダクトが「どういう動きをするのか」「いつ、どこで動くのか」といった「How?」や「When?」「Where?」はわからないので、今はひたすら「What?」の部分を集めていくことになります。
この後の工程で整形するので、ひとまず「これは、ここでしょう！」というところに、その他の項目を置いておきます。
これから作るモデル図は、「システム、プロダクトを写像したもの」(写像ついては、後日書きます)になります。
いうなら、システムやプロダクトに関与している人たちが、認知している対象になるので、その場のフィーリングや勝手な解釈、また略すなどをしてはいけないです。
QAエンジニアやテスト設計者が、テスト分析や設計するときに「テスト対象の文言を変えない」のと同じように、もし文言を変えてしまうと、コミュニケーションがままならず、テスト対象が定まらなくなったり、レビューなどで「これ、何？」などと突っ込まれ、修正するために手戻りが発生したりと、効率が悪くなってしまいます。
そうなると、「モデル図としての機能」が果たせなり、モデルベースドテストの意味がなくなってしまいます。
なので、テスト対象は「そのまま書く」です。
Q.個体指定子には、「番号やコードがない」個体指定子ってあるの？
A.あります。というより、できます。
個体指定子は、「番号やコードがなくても、使うこと」が可能です。
なので「名称」しかない場合でも、それを個体指定子として使うことも出来ます。 テストの現場では、扱う領域のシステムやプロダクトによってまちまちだと思いますが、「名称」を個体指定子にできるのは、助かります。
課題
個体指定子は、基本的に「番号やコードが付与されている」というのが、もしかしたら今後テスト対象を集める際に、領域やプロジェクトごとに関係者同士の合意のもと、定義しておく必要があると思いました。
ある基幹系のシステムでは、個体指定子によるモノの集め方は適用できても、それ以外の領域では適用できないとなった場合の対応が必要ではないかと考えます。
また「名称自身を個体指定子にできる」について、参考にしている書籍上では「ごく稀である」と掲載があるように、多用するのは難しいのかなと思いました。
暫定的な案の一つとして、「商集合」の考え方を使ってはどうか？と思いました。
参考: 数学の基礎 齋藤 正彦著
「商集合」とは、以下の関係全体の集合のことを指します。
A/R : 関係Rが、集合A上の同値関係のときの、\\関係Rの同値類全部の集合
ここで、同値関係の条件3つを下記に掲載します。
同値関係の条件
1.反射律：
ならば、
2.対称律：
ならば、
3.推移律：
ならば、
…何のことなん？って、思いますよね。
ぶっちゃけ、私自身も数学基礎論(ここは現在勉強中)を勉強してく中で、この数式に出会い「？？？」と思った次第でして。
端的に言うと、「"同じ仲間だよなっ！"と言い切れる関係の集まり」で集めてもいいのではないか？と思った次第でして。
例えば、「恋人」とか「家族」とか「友達」っていう関係性があるように、「自分とこの人(もしくは、Aっていう人とBっていう人)とは、〇〇の仲と言い切れるよね」と、自分から見ても相手から見ても(Aから見ても、Bから見ても)、同じ関係性だと言い切れるのであれば、その関係性からなる集合として集めることが出来るのでは、と。
ならば「個体指定子に付随する」や「名称も個体指定子にできる」というルールに、「その集合の中で、商集合を作って(元同士が関係性を持つように、同じグループの仲間同士)集める」やり方も出来そうだなと。 そうすれば、番号やコード・名称というのに「機能ごと」にも集めることが出来そうだ、と考えてます。
とりあえず、「暫定的な案」なのでもう少し勉強してからこの課題に対する答えを出して行こうと思います。
方向性としては、一旦この方向での解決も視野に入れてみようとも思いました。
おわりに
後半に続くにつれて、濃い内容に差し掛かってきたましたが、そこは読者の方々に「沼」に入らぬよう、扱う言葉には注意したつもりです。
集め方については、一旦ここら辺で切り上げておきます。 更新があったら、随時更新してきます。
さて、次は「モノを並べる」です！ お楽しみに！
今後、以下のことも盛り込んで、新しいモデルベースドテストの可能性について記事にしたいと思います。
こちらは、追々書いていきます。
貴重なお時間を使って本記事をここまで読んでいただき、ありがとうございます！
では、また！
テスト業務である困りごとを「TM技術を使った、MBT(モデルベースドテスト)」で解決出来ないか？
はじめに
テスト業務を遂行していく中で、「ここ、こうだったらいいのにな〜」とか「もうちょっと、こうなればいいのに」思うことがあります。
特に、テスト計画・テスト設計といったテストプロセスにおいて、僕自身(QAエンジニア8年目)テスト業務に従事していく中で、いくつか困っている事があります。
僕のQiitaの初投稿は、その困りごとを何か新しい方法で解決できないか？その可能性についての概要を、書いていきます。 ※技術的なことについては、後日書いていきます。
テスト業務で「困っている事」
- 1. 書式がバラバラっ！
- 各プロジェクト・各部署・各会社さんによって、テスト計画書やテスト設計書の書式がバラバラになっていることが多く、それぞれに書き分けなければいけないケースがあります。
テンプレートを用意されて(もしくは、自前で用意する)も、そのルールを覚えて書き分けるのに「Aというプロジェクトのときは、こう」「Bという部署では、この書き方は禁止」「会社Cさんでは、〇〇文字以内でフォントは〇〇で手順は簡潔に…」などによって、一見効率的に見えそうで、実はかえって時間がかかってしまう。
自前で用意したテンプレートがそのテスト業務に合わないために作り直したり、逆に使われなくなったり、なんてこともあります。
- 2. 仕様書がないっ！
- これは、すべてのテスト従事者にとって一番困ること(開発者の方にとっても)であるのでは、と(笑)。
アジャイル開発の弊害とでも言いましょうか、アジャイルソフトウェア開発宣言による「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、」の部分の解釈を、「そうか、ドキュメントは作らなくていいんだっ！」と解釈してしまい、なんでもMTGやコミュニケーションツールで済まそうとする流れがあります。(こちらは、個人的に経験してきた中で思うことです。)
そのため、明示的に機能を定義したドキュメント(仕様書)が作成されず、5W1Hに落とし込んだり、テスト技法を用いて情報をまとめてテスト計画書やテスト設計書が作りづらくなる傾向にあること。
また、「言った言わない問題」「会話のログ収集」「裏取り(会話ログや他の人の話などを調査して、相手の話の裏を取る)」といった問題や、その実行にかかる時間が増えて、テスト業務に必要なドキュメント作成に時間がかかる、ということもあります。
- 3. 伝わらないっ！
- 最近では、開発側とテスト側で作成したドキュメントの内容に対する「バトル」は減ったのかなと感じます。
これは、開発側の知識(使用しているプログラミング言語や構造、アルゴリズムなどなど)と、テスト側の知識(使用しているテスト技法、用語、テストプロセスなどなど)をお互いに認識し合う・勉強会などで知ることにより、解決しているものだと感じます。
問題なのは、「上位の方々」といった経営陣に対して開発したシステムやソフトウェアの説明です。
ITに関わる知識をある程度持っていれば良いのですが、無かった場合の説明が難しい。
開発したシステムやソフトウェアを「定量的に示す、定性的に示す」際にも、使う用語に気をつけなければいけなかったり、説明したとしても「では、その説明で何が言いたいの？」の突っ込まれたり、相手が相槌を打ってくれても後で「ここって、どうだったんだっけ？」と再度説明しなければならなかったり。
別に、説明自体が嫌ではないのですが、理解してもらえるために準備がどれくらい必要なのか、また時間がどれくらいかかるのか、といった所が悩ましいところです。
※この問題は、特にPM・PdMの方が悩んでいることなのかな？と思いました。
1日でも早く、システムの品質を高めてリリースするために「生産性、効率性、品質保証の向上」目指して、頑張って改善策を策定し提言して実行しても、なかなか効果が出てこない、かえって時間がかかってしまい、最悪リリースが遅くなってしまい、時間・お金・人のコストが高くなることが、扱う領域によっても異なりますが、間々あります。
何か、良い方法は無いか？
長々と前置きが長くなりましたが、僕自身QAエンジニアとして従事している中で困っている事の多くが、この3つなのではと考えています。私と同じように、テスト業務に関わっている方が共感してくれたら幸いです。
では、本題として「その困り事を解消する、何か良い方法はあるの？」というところを述べたいと思います。
それが、「TM技術を使った、MBT(モデルベースドテスト)」です。
TM技術って、何？
この書籍でかかれている、「T字型ER図」を使い開発するシステムやソフトウェアを「一枚絵」にして、そこからテスト計画やテスト設計を導出出来ないか？と考えています。
こちらの本を手にして読んだときに、「これだっ！」と稲妻が走ったのを覚えています。
内容としては、事業のプロセスを「モデル」というものに置き換え関連性を記述し、その関連性から分析をしていくというもの。
困り事のそもそもの原因は、「ドキュメントを書くときに、読み手を限定・もしくは想定して書いていたことにあるのではないだろうか？」ということを思いつきました。
なら「誰が見てもわかるような、そして説明できるような、そんなものを書けたらなぁ」と考え、事業分析・データ設計のためのモデル作成技術入門に出会い、読みました。
この技術とテスト技術を掛け合わせれば、解決できそうで、何か面白いことが出来そうだと考えています。
ベースとなっているのが、数学の「集合論」や「記号論理学」といった「数学基礎論」をベースにしているので、バックグラウンドとしても確度が高いものである思いました。
なので、この書籍以外の数学の参考書などを日々読み漁って勉強してる毎日です(笑)
MBT(モデルベースドテスト)って何？
TM技術を取り入れようとした、もう一つのきっかけが上のリンクにあるテスト技法です。
日々のテスト業務の中で、既に取り入れてはいて(状態遷移図や直行表、デシジョンテーブルなど)、特にこれからのテスト設計ではこの手法をメインにして、出来ないかと考えています。
また、ノーコードで開発できるようになっている昨今では、その「ノーコード」の部分を「テスト業務」に適用できるのではないか？とも考えています。
ここから更に発展して、テスト自動化に繋げる手立てとしてとても参考になれるものであるとも考えています。
まとめ
今回は技術的な部分は、書けなかったのですが、これからのテスト業務の改善に必要な技術であると考えています。
なので、掲載した書籍や技法・他の書籍を読んで 学習したこと、また現場で技術的にどのように適用できそうかを、これからの記事で書いて行こうと思います。
※2週に1回は、記事を書けるように頑張ります！
ここまで読んでいただき、ありがとうございます。
では、また。
