同値分割を丁寧に行う

ソフトウェアテスト Advent Calendar 2023　の15日目としての投稿です。

めっちゃ久しぶりのエントリーです。小ネタも2019年が最後だった。。。

先日、久しぶりにガチ目にテストケース作成しました。割と複雑な処理のところでデグレードを起こしていたため、複数の状態遷移にともなう処理を確認するためのテストを考える必要があり、しかしテストの意図を丁寧にわかりやすくケースにすると、いとも簡単に爆発するため、ケース組みの時点で複数のことを考えて圧縮する必要がありました。それでも「え？こんなにやるの？マジめんどくさーい」と開発メンバーに思わせたらしいです・・・開発メンバーどころか受け入れ担当者にまで面倒くさがられたよ・・・そんなの、ケース組むあたしだってめんどくさいのだ！

本題に入りましょう。なんでこんな前置きを書いたかというと、この手のテストを考えるときに、こんな手順を踏んでいます、という紹介をしようと思っているからです。

いきなりテストケースを書き出す人、けっこういると思っています。今年関わった案件でも、まずパラメータリスト作ってね、と言ったら、みんないきなりテストケース作りまして・・・レビューも大変じゃねーかー・・・

もちろん、それで問題ない単純なテストもあるので、まったくダメではないのですが、入力項目がたくさんあって、影響しあう項目もあって、バリデーションも複雑で・・・なーんて画面を相手に、いきなりテストケースを作ろうとするのはちょっと危険。

だけど、期待値がセットになったテストケースしか考えたことがないと、パラメータリストを作れと言われても、どうしてよいのかわからないみたいです。そういうことが「技法を学んでも使いどころがわからない」につながるのかもしれません。

テスト設計の過程

1. テストパラメータを列挙する
2. 今回実施する（設計する）テストの意図に影響するパラメータを選ぶ（開発者と確認しながら選ぶ）
3. 必要なパラメータに対して、同値パーティションの確認をする（何をもって同値とするか、開発者と認識合わせをする）
4. テストケースの構成を決める（どの技法を適用するかを決める）
5. テストケースを作成する

上記のように書くと、テスト技法を使うのは手順5のように見えますが、手順1の時点からおそらくテスト技法は使っています。

そうです。同値分割法です。

今回私が一番言いたいことは、タイトルにあるように、この、同値分割をちゃんと意識しましょう！ここから丁寧にやりましょう！（テスト設計があまり上手くできないかも・・・と思っているならば、まずこの段階をしっかり踏みましょう。）ということです。手順1から3までが該当します。

もう一つ大事なこととして、テストの意図を明確にして、テストの意図に影響するパラメータでテストを構成しましょう。（影響しないパラメータを混ぜるのはテスト実装時にしましょう。）ということがあります。これは手順2が該当します。

テストパラメータを列挙する

いきなりテストケースにしないで、パラメータとしてなにがある？具体的にどんな値が必要？・・・ということを書き出しましょう。表でもよいですし、マインドマップのようなツリー構造を使ってもよいと思います。付箋でもよいと思います。この時点では、関係しそうなものは挙げてみる、なんか気になる値はすべて挙げてみる、という、発散型でよいと思います。考慮が漏れるほうが困るので、気になることはなんでも出してみます。

この作業は現場で行なっているかたも多いと思います。しかしながら、その後の作業（成果物）とつながらないケースもよく見ます。背景として、提示した過程の2と3の作業を雑にしてしまう、あるいは省いてしまうことで、上手く組み込めなかったり、余計なものまで組み込んでしまったり、ということが起こっている、というのが、いまのところの私の勝手な推察です。

テストの意図に影響するパラメータを選ぶ

テストの意図に影響するパラメータを用いてケースを構成しましょう。テストフレームを作ってみるとよさそうです。

テスト実行に対しては必要なパラメータではあるが、テストの意図を確認するためには必要ではないこと（影響しないパラメータ）は、テスト設計の段階で考慮してしまうと、よくわからないテストケースが出来上がります。

もちろん、本当に影響しないのか？という疑問を抱くことも大事です。ただ、「影響しないはずなんだけど影響しているかもしれないことを気にしたテスト」は、意図が異なるため、分けて考えましょう。たいていの場合、怪我します。（よくわからないけれどもパラメータいっぱいあるので組み合わせテスト技法を使って圧縮しました！なんていうパターンをかつてよく見かけたことがあります・・・テストの意図・・・orz）

同値パーティションの認識合わせをする

例えば、申し込みステータスごとに編集可否やボタンの活性具合が変わる、というふるまいをするシステムに対して、申し込みステータスのパラメータに対して分割するとしたら、ステータスなのか？編集可否の状態なのか？はたまた別のなにかなのか？という、分割の方針を明確にしましょう。開発者がどのように作ったのか？を確認したうえで、テストの意図に合った同値分割をしていくことを超絶お勧めします。テストの意図を考慮せずパラメータに対して列挙した値をそのまま使ったり、思い込みで同値パーティションを決めたりしないように・・・

JSTQB テスト技術者資格制度 Foundation Levelシラバス Version 2023V4.0.J01 でも、同値分割法について、このような記述があります。

単純なテスト対象であればEPは簡単だが、実際には、異なる値をテスト対象がどのように扱うのかを理解することは、困難なことが多い。そのため、パーティションに分割するのは慎重に行うべきである。

（4.2.1 同値分割法　の記述より）

・・・具体例がないとわかんないんですけど？

・・・そうですよねごめんなさい・・・

今回、現物をそのまんまというわけいにもいかず、簡略的な例を用意・・・と思ったのですがっ・・・

お題を考えていたら結構果てしなくなってしまって、まずはお題の解説から始まっちゃいそうだったので、具体例はいったん諦めます。ただ、お仕事の都合もあって、演習できるネタを作ろうかなぁと思っているので、また例が見せられるようになったら続きを書こうかな、と思っています。

Scrum Master 研修を受けてきた

10月26日、27日で開催された、永和システムマネジメント社主催のスクラムマスター研修を受講してきました。
＋28日のエクスカーションで永平寺で坐禅もしてきました。

はるばる福井まで行ってきたわけですが、福井に行ったからこそ得られたものがあって、とても充実した時間を過ごせました。

推しポイント

• 実際にスクラムで開発している現場の見学ができる、実例の紹介もある
• 資料に沿った説明だけでなく、クイズ形式で進めて、選択肢に対してなにが適切でないのかまで考えることで、記憶の定着を助ける
• オンサイトならではのディスカッションができる、空気感を味わえる

他のスクラムマスター研修を受けたわけではないから、どこも同じかもしれないし、差があるかもしれません。（オンラインとオンサイトの違いはどこも同じだと思います。）

永和さんは実際に開発案件を持っているため、現場が近い感、リアル感が高いと感じました。実例を目にしてから講義が入ると、イメージも持ちやすくなりました。また、私自身も開発チームの活動をひととおり一緒に過ごすという体験をしたことも重なって、自分達の活動でここは変えられるかもしれない、最近やったこの活動は方向性が間違っていなかった、など、自身の体験と重ねてイメージすることができました。

自分が得た学び

• デモ大事だし、リアルタイムにフィードバックができるのも大事なので顧客にPOになってチームに入ってもらうのはすごく効果的
• スクラムはチームやプロダクトの成長だけでなく、組織の成長にも繋がる
• 人は相対的に見積もることが得意（先日現場で行ったTシャツ見積もりがなかなかうまくいったのはそういうことなんだなと思った）
• 自己と向き合う（永平寺でとくに実感しました。なぜエクスカーションが永平寺なのかは、永平寺に行くとわかると思う！少なくとも私は、あぁだから海外にも受け入れられて、ジョブズも憧れたのか、と思いました。）
• スクラムの体験はなくてもよいかもしれないけれども、あてはめるだけの実体験があるほうが、理解度が増す
• スクラムと刺身の違い

共感したこと

• 困らんやつほど困ったやつはおらん（その人は本当に困っていないのか？という疑問をもつことももちろん大事だと思う）
• スクラムはシンプルだが、簡単じゃない

その他よかったこと

• 食事がおいしい（ソースカツ丼・鹿肉ソーセージ他お肉盛り合わせグリル・そば　などなど）
• グランピング楽しい（夜の語り時間足りなかったー）
• 坐禅体験できた

研修後に資料を見返して、研修中に表示していなかったスライドも結構あるな。でもこの話は散りばめてしていたな。うーんでもこのバグの話はしてほしかったなって品質方面で行きてきた身としてはついつい思っちゃうな。なーんて思いました。時間が足りないなんて言ったらどれだけあってもきっと足りないわけで、2日間でちょうどよいのだと思います。

直近でスクラムに関われるかどうかはわかりませんが、そうでなくても、日々の活動の中でなにか取り入れて変えていけたらいいな、と思っています。

テストのドキュメントに求められること

珍しく？ブログというよりメモ的な小ネタを投稿・・

テストのドキュメントをどのツールで扱おうか？というう課題に遭遇しまして・・

前提はクラウドベースなので、まぁテスト管理ツール使えよっていう話なのですが、テスト管理ツールもお値段がかかるのと、その前にテストの管理方針を定めるほうが先だよね（テスト管理方針がそもそもまだない）、という状況なので、いったんテスト管理ツール抜きでどうにか管理してみようということになりました。

とはいえ、できるだけケースレベルでも脱Excelしたいと思ったりしたので、スプレッドシート以外のツールでテスト実行をするとしたら？という実験などもしています。

まだまだ試行錯誤中なのですが、ツール比較をするために、テストのドキュメントに求められることはどんなことだろう？というのをまとめてみました。

• ドキュメント間のつながり（トレーサビリティ）
  • システム要件とのトレーサビリティ
  • （繰り返しテスト実行が必要な場合）テストケースバージョンと実行結果のトレーサビリティ
  • 進捗を妨げるもの（不具合・課題など）とのトレーサビリティ
  • テストの構造が把握しやすい（構成要素の段階的構造を表現できる、など）
• 作業状況の見える化
  • テスト設計とテスト実行の進捗を見せる
  • 優先的に対応すべきことがすぐにわかる
• ドキュメントの管理容易性
  • 作成・編集に手間がかからない
  • レビューのしやすさ
  • バージョン管理・変更履歴の記録が楽にできる
  • ケース展開のしやすさ
    （ベースとなるケースからテストデータをはめて実行する単位に展開するときのしやすさ）
  • ケース展開後の一括修正のしやすさ
  • 自動テストツールとの連携
  • 再利用を考慮した構造を持てる
    （次リリースへ複製・類似機能へ複製・類似プロダクトへ複製・基本テストを非機能テストに利用・など）
  • （繰り返しテスト実行が必要な場合）テストケースのピックアップのしやすさ

とりあえず思いついたものは以上です。他にもあるよーというご意見ありましたら、教えていただけると嬉しいです。

試行錯誤している話はまた後日書けたらいいなぁと思っています。

テストの意図を届けよう

JaSST '22 Tokyoで久しぶりに登壇してみました。

講演資料はこちら

実際スライドを作っていったら、伝えたいことがめちゃくちゃあって、
体験談を盛り込んで語り出したら、一人で２時間くらい話しちゃう勢いでした・・・

なんとか40分に収めたつもり・・・収まっていなかった・・・orz

個人的に伝えたかったこと

1. テスト設計の過程を見せよう
2. Whyを明確にしているのに伝わらないWhyを探ろう
3. 人の考えや解釈は十人十色、そして人は忘れる生き物

1. テスト設計の過程を見せよう

テスト設計しました！と言って、いきなりテストケースをどどどーんと提出して、レビューお願いしますって言っていませんか？
そうすると情報量がたくさんすぎて、さらにコピペなどで情報量増やしているから、確認する側はとてもつらい思いをして頑張って確認しているんだよ。
結果として、確認する側が、確認する時間が足りなくなってフィードバックが返せなかったり、余裕がなくなって厳しい反応を返してしまったりしているよ。
だから、段階的にちょっとずつ、完全な成果物でなくていいから、自分が考えたことをチーム内で共有しながら進めよう。

2. Whyを明確にしているのに伝わらないWhyを探ろう

例えば、仕様書に沿ってテストケースをつくれば、結果として仕様を網羅したテストケースになるという主張は、よさそうに思うけれども、多くの人は「そうじゃないよね」と思っている、そのように、よさそうに思うけれども不十分でイマイチ納得がいかない説明に遭遇したことはありませんか？
周りが納得していなさそうであれば、事実や見解を因果関係で示して主張を検証してみよう。
同じように「従来通り」とか「優先」とか「網羅」という言葉がでてきたときに、それは100%成立するのか？なにか前提はないか？さらに先の結果はどうなるのだろうか？ということを考えて、検証しみよう。

3. 人の考えや解釈は十人十色、そして人は忘れる生き物

自分が持っている意図を自分なりに伝えたら必ずしも伝わるわけではないし、仮に論理的に伝えたとしても伝わらないこともあるし、その場では認識共有できても他の仕事に追われて忘れちゃうこともあるよ。
だから成果物1回確認してもらえば完成品！ではなく、一方的に伝えるだけでもなく、成果物を何度もたたき台にして、みんなで理解を深めて、成果物をみんなで育てよう。

他にもいろいろ・・・

伝えたいことはたくさんあり、いろいろ盛り込んだせいで説明がふわふわ中途半端になっちゃったなーとは思っています。。。難しいですね。
「実はみんな考えている！伝えたいことが隠れているだけだよ！」も伝えたかったひとつで、考えられないと言って逃げずに、伝える側も受け取る側も余裕をもってじっくり共有できると本当はいいよね・・・と日々思っています。

仕様書があるとその記述に沿ってテストケースの構成を組んでしまって、枠ができちゃって発想が止まるとか、気づいたことを盛り込めないとか、気づいたことをなんとなく差し込んでしまうとか・・・職場でもテスコンでも同じ現象をよく見ます。
そういう現場あるあるに対して、こんなことをしてみるといいんじゃないかな？を簡単に紹介してみました。
もちろん、ガチにテスト設計したら示した例じゃ済まないです。（実際、例を作るときに思わずガチに走りそうになった・・・）でも、いきなりはできないから・・・簡単な例を示すことで、身の回りでできることを探すきっかけになってもらっていたら嬉しいな、と思っています。

今回の講演資料を考えているときに、たまたま智美塾でも同じネタでテスト設計する宿題もあり、講演の中で例に挙げていた「雑な絵」を描きました。こんなに雑でもいいんだよ、という例なので、この絵にツッコミを入れたい人は多いかもしれません^^; 参考までに添付しておこうかと。

話題沸騰ポット要求仕様書 (GOMA-1015型) 第７版　を参照して描いた雑な絵

職場だともっと「なんじゃこりゃ」と言いたくなるような、○と→とで登場するなにか（概念だったり実体だったり）を書いて自分の理解を描くこともあります。そんな図でも、その場で議論が始まったら心の中でガッツポーズしちゃう。
その昔、SQiP研究会でそんな雑な図をホワイトボードに描いて認識共有したら、発表のときにその図（を写真に撮影したもの）を発表資料に載せられそうになり、「頼むから清書してください・・・」とお願いしたことがありましたねぇそういえば・・・

逆に、私はひたすらテキストで（それも口語で^^;）つらつら書き出す傾向があります。テキストで書くときはひたすら考えている最中で、その時点で出力を急がれてしまうと、その垂れ流し状態を出さざるをえないことがあります。私と同じように、本当は図にできるんだけども、図にする余裕がないなど、なんらか構造にできない理由があると思うので、構造を見せないとわからないと突っぱねるのではなく、一緒に作ってみるという歩み寄りができたらよいかもしれません。 https://blog.hatena.ne.jp/shiozi/shiozi.hatenablog.com/

私も日々修行中です。うまくできないこともたくさんあります。みなさんといろいろ学んで、少しずつ良い方向に変えていけたら嬉しいと思っています。

気ままにテスト実行するひとがスクリプトテストで陥ってしまうこと

くだらない話をだらだらと書きます・・・

4年前に自分のテストのスタイルを気ままに書きました

shiozi.hatenablog.com

はい。このとおり、そもそも作成したテスト実装成果物棚上げしてテスト実行する傾向があるんですよね、あたくし・・・（テスト実装物が自分でつくったものであろうが他人がつくったものであろうが；）

そんな私が「しかたがないからスクリプトテストをする」ときに陥ることについて書いてみようかなと思います。

なんでそんなことを書く気になったかというと・・・昨日Twitterで「実装実施時要検討事項」なる言葉を見かけたからです。設計意図に基づくと、値として（テストケースで確認したいことを邪魔しなければ）なんでもよいけれども、テスト実行の際にはなんか定めないと実行できないパラメーターとか条件とかが該当するそうで。

わかります。そうですね。これ、テストで確認したいことで気にしなきゃいけない条件とかパラメーターとかと混ぜちゃうケースをみかけます。全部混ぜちゃって組み合わせテストでどうだー！！みたいなテストケースを何度か見たことがあります。

混ぜていないときに、よく自分でも使うのが「任意の値」なんですけど。これもまた曖昧すぎるんですよね・・・任意ってゆーてもその値にだって有効と無効があるでしょみたいな。。。あぁ表現って難しい。

だけど私は「任意」って書かれるほうがいいなぁと思います。それはなぜなのか？という話をだらだらしようかと。

テスト実装物とか、テストの指示で、これまで困ったこと

1. 任意の値でよい箇所に、「test1」など適当に値が入っている
2. テスト設計していなくて「仕様書の記述どおりであるかをテストしてテスト終了したら記載箇所をペンで塗ること」という指示がだされた

1. のときには、「いやいやいやこれ毎回この値でやってるのよくないと思うのよ。どーせテストするなら普段やらない値を入れたほうがいいじゃん。何度もやるならいろんな値を入れたほうがいいじゃん。」って条件反射的に思うので、その衝動が抑えられなくて他の値でテストしちゃうんですよね・・・・・だけど根が真面目なので、テスト結果をOKにするためには「書かれているとおりにやった」でなければいかんと思うわけです。だって万が一そのとおりにやってNGだったら困るし；　ゆえに無駄だとわかっているんだけれども嘘をつきたくないので仕方がないから書かれていることもやるのです・・・だから私がスクリプトテストをすると人三倍工数がかかると・・・

2. のときは、「え？仕様に書かれていることって、これを証明するには仕様に書かれていないことも全部考慮しないとだめじゃん；え？どこまでテストするのよこれ；なんで周りの人はそんな簡単にさーさーと塗りつぶしていくわけ？？？？？」・・・はい。律儀に言葉どおりにやろうとする子なので、果てしなくなりすぎて崩壊レベルで進みませんでしたとさ・・・（この現場1ヶ月半で泣きながらやめてきたw）

こんななので、仮に「実装実施時要検討」なんて書かれた暁には、「え？なに？なにを検討するの？なんか検討しなきゃいけないの？」って・・・たぶんテスト設計し直すみたいな事態に陥るとおもうんですよね・・・気がかりな周辺全部拾ってくると思うんですよね・・・

つまり私にどれを渡しても結局なんかいろいろ考えて他のことをやってしまうので、だったら最初からおまかせにしてもらえると嬉しいんだけどなぁって思うのでした。

だけど、一般的には要検討って書いたほうがよいのだろうなぁって思いました。そう記載をしておくことで、再度立ち止まって、それがテスト実行にあたってどんな役割を果たす条件なのか？を見直す機会はあるほうがよいのだと思います。

よいものを目指すということ

今年もあと少しになりましたね・・・

相変わらずちょっとしたことというよりもポエムな感じですが、今年のふりかえり的につらつらと書いてみます。

昨年秋に、来年になったら仕様策定の仕事をやってみる？という話がありまして、そのために要件定義に関する勉強を簡単にしておいてねって言われまして・・・

今年の春に、要件定義の修行をしたいんですけど、なんかできることありますか？って訪ねた別のかたから降ってきた案件に乗った結果、

某管理システムの企画および導入支援(半分営業)という立場になりました(爆)
いや、修行にはなっている？し、お客様の声を直接伺う立場にもなっているし、間違ってはいないと思う。だけどプロダクト開発よりもサービス開発の域まで入っているし、まったく知らない業界だし、ちょっと待って待って！みたいなことがたくさんありました。

そんな中で感じたことを書こうと思います。

これまでは、プロダクト開発に関わっていて、それもQAや開発支援テスターで、更に社員ではなくパートナーとして関わっていました。
単にバグを見つけるとか出荷可能かどうかの確認という作業にとどまらず、よいプロダクトになること、プロジェクトとして嬉しくなるように振る舞うことを心がけていました。目指していたのはよいプロジェクトとよいプロダクトだったと思っています。

それが今年の活動を通して、狭い視野でしか見ていなかったんだな、と感じるようになりました。

よいプロダクトをつくったとしても、利用者がうまく使ってくれなかったら、そのプロダクトの価値は下がってしまいます。よいプロダクトの価値をできる限り最大限にすることを目指してうまく使ってもらうようにすることが必要で、そこはマニュアルで補えることもあるかもしれないし、支援サービスとして提供することもある。サービスのデザインが必要で、サービスの質が求められるんだな、というのを肌で実感しました。

さらに、よいプロダクトをうまく使ってもらえるようにしても、売れなきゃ意味が無いんだな、ということも実感しました。売れるために何を実装すべきなのか？それはプロダクトなのかサービスなのか？あるいはプロモーションなのか？・・・ここまで来ると質なのかなんなのかよくわからないけれども、ともかく、プロダクトとしては、売れて初めて価値が出せるんじゃないのかなって思ったのでした。よいものを目指すっていうのは、売れて価値を届けられるものを目指すってことなんじゃないかな。そこにたどり着くまでは、様々な立場の人たちの協力によるものなんだなって。そして、全体を俯瞰する立場だったり機会だったりが必要なんじゃないかな。

もちろん、ソフトウェアテスターとしてプロダクトの一部と向き合うのはとても大事なことだと思います。そういう役割は必要です。ただ、プロダクト開発の中だけで生きていると見えない世界っていうのがあって、それは、できるだけ積極的に見に行くほうがいいんだろうな、見せられるなら見せたほうがいいんだろうな、と思ったのでした。現実としては組織が異なると見せられないこともあるから、自分から違う世界を見に行く機会を掴むほうがよいかもしれません。

テストフレームをつくってみた

最近、スクラムチームの中でテストをする機会があり、テスト要件を挙げて、ハイレベルのテストケースを挙げて、あとは探索的にテストをするという流れを何度か経験しました。自分にとってやりやすいこととか、流れがよくないというかつながっていないところがあることに気づく、よい機会になりました。

気づきとして、テスト要件を挙げることと、いわゆる観点に該当するものを挙げることはできるのですが、それがどう関連するのか、というところがうまく見せられないことがわかりました。だから、「これで十分なのかがわからない」と言われることが多かったです。。。テスト要件だとざっくりしすぎで、テスト要件に対して観点を見せるのはなかなか難しいなぁと。。。(テスト要件単位で観点並べるのをさぼったからっていうのはわかっているんですけれど、並べたところでテストケースがイメージできる状態にならないとか。。。)

それとは別に、そういえば、テスコンチュートリアルで紹介されている「テストフレーム」をつくる演習ってあまり聞かないなぁと思い、じゃぁテストフレームを作る演習を考えるといいのかもーと考えまして・・・まずは自分で明示的にテストフレームをつくってみるかぁ・・・と思ったのでした。

テストフレーム：テストケースの構造をテスト観点で表したもの
(チュートリアル資料47ページ参照)
http://aster.or.jp/business/contest/doc/2020_OPEN_V1.0.0.pdf

やってみた結果、どうもテストフレームはテスト要件をまとめる過程でつくり、テスト要件単位で詳細に落とし込んでいくのがよさそう、という見解になりました。

テストフレームを形成する観点を用意する必要があるので、観点の列挙も含めると、こんなプロセスになるなぁと・・・

テストフレームを用いてテスト要求分析・テスト設計を行う

試しに、一般的なLogin処理を想定してテストフレームをつくってみました。

Login処理のテストフレーム

これをテスト要件ごとに展開してみました

入力値に対してログイン可否を判定して判定結果を出す、というところをテストしたいときは、こうなるかな？と思いました。

一方、いろんな条件でログインに成功することを確認したいとき(組み合わせテストを想定している場合)は、↓のように変わってくるなぁと思いました。

更に、エラーになる条件に対してエラーメッセージを表示することを確認したいのであれば、どこにエラーの条件があるかを洗い出して展開されます。この場合はServerの状態やNetworkの状態に注目がいくはず。

そして、テストアイテムを適切に設定する必要があることもわかってきました。テストアイテムの抽象度が高いと、テスト要件に落とし込んだときに必要ない(単一条件でも必要がない)観点が存在してしまう。そうなったらテストアイテムが適切ではないと疑ったほうがよさそうだな、と思いました。例えば画面単位でテストアイテムを設定すると、パーツが混ざっていることでごちゃごちゃしたテストフレームが出来上がってしまいます。他には、UIの処理とシステムの処理は分けたほうがよい、など。

自分の頭の中で処理していることって相当あるんだなぁというのが正直な感想です。
これを都度やるのは面倒臭いなぁ・・・でもツールを活用することで面倒臭さは解消されるかもしれないなぁ・・・と思うので、ツールを使ってうまくできないか試していこうと思います。