テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



クリスマススペシャル『テストチャーターの作り方』

 

クリスマススペシャル『テストチャーターの作り方』

この記事はソフトウェアテスト Advent Calendar 2024の24日目の記事です。

今回は探索的テストの時に使うテストチャーターの作り方のお話です。

 

フリースタイルの探索的テストはマネジメントも実行も難しい

何かバグを見つけたいから全体的に探索的テストする、ということはテストを行っている皆さんは経験があるかと思います。

作者もよく実施します。

この探索的テスト実施によって「あ、そんな問題があったんだ!」ということが色々と見つかります。

ですが、マンガに描いたように何に対して探索的テストの目が通っているか、何に対して探索的テストの目が通っていないかなど、実施範囲の把握が難しくなってきます。

また、メンバーにお任せスタイルだと探索的テストの実施個所に偏りも発生します。メインの機能は深掘りされているけど、少しマイナーな機能は影響範囲にもかかわらずほとんど探索的テストの目が通っていないなどです。

不慣れなメンバーですと「全体的に何か探して」と言われてもどうしていいかわからずに動けなくなってしまいます。

 

テストチャーターを作る

「全体的に見て何かを探したい」を深掘りして分解するともう少しマネジメントしやすい形になります。

この「全体的に……」の理由は「なんか不安だから」がほとんどかと思います。

その不安をもう少し考えていくとこんなことが見えてきます。

「~とかなったらイヤだな」

「こういうことがあったらどうしよう」

これがあなたが想定するリスクです。リスクの識別です。

これができたなら、その列挙したリスクをひとつずつ狙って確認していきましょう。

そのリスクを狙うためのドキュメントがテストチャーターです。

 

テストチャーターのテンプレート

マンガにも書きましたがこんなテンプレートがあります。

 

Explore <Target>

Using <Tools>

To discover <Risk/Information>

by "Explore It!"

<リスク/情報>を発見するために、<ツール>を使って、<ターゲット>を探索する

 

テストチャーターによって、何を発見するためにどこを探索するかがハッキリします。その探索的テストで何をすればいいか、何がゴールかがわかるわけですね。

ちなみに「ツールを使って」になっていますが、これは別に外部ツールを必ず使えという意味ではありません。

何かしらのデータセットを使って、とか、意地悪漢字を使って、など何かしら用いるものを指定します。

マンガでも本当は「情報を使って……」と書きたかったのですが、発見する情報と被ってしまうので「データ/ツールを使って」という形で描いています。

 

他にも以下のようなチャーターがあります。(作者的には一番最後が好み)

My mission is to test <Risk> for <Coverage>

by Tips for Writing Better Charters for Exploratory Testing Sessions - EuroSTAR - Michael D.Kelly

私のミッションは<対象>で<リスク>をテストすることだ

※この方の話の内容的にCoverageは僕たちが思い描くカバレッジではなく、対象や範囲の意味を指していそうです。

 

Look at <Target>

To test for <Test Idea>

by Web API テスト技法

<テストアイディア>をテストするために、<ターゲット>に着目する。

 

とはいえ「想定していない何かを発見したい」もある

こういったことを書くと

「リスクが思い浮かばないからチャーターを使った探索的テストができない!」

となる人もいるかと思います。

蛇足かとも思いましたがマンガの4ページ目にその辺を描きました。

「機能Aに着目して何かしら探す!」といった、ひとまず何か対象に着目して漁ろう、といった形です。

もちろん対象は機能だけではなく、シナリオでも良いです。

フォーカスするターゲットを決めるだけでも、「全体的に何か探す!」よりも実施したカバレッジもわかりますしマネジメントしやすくなります。

 

セッションベースドテストマネジメント

セッションベースドの探索的テストの作者がイメージする流れは以下です。

探索的テストのサイクルが、1回のセッションの中と、セッション間でのサイクルの二重のサイクルになっているイメージです。

 

まずはテストチャーターを用意します。

(例:入力エラーをテストするために、入力ボックスに着目する。時間:15分)

そして時間を区切って(作者は40分とすることが多め)、テストチャーターに沿って探索的テストを実施します。

探索的テストの実施が終わると、様々見えてくることがあります。

(例:入力エラーは問題ないけど表示崩れがいっぱいあるぞ!)

それをデブリーフィングで共有、分析と学習を行い、次のテストチャーターに活かします。

(例:表示崩れをテストするために、出力表示箇所に着目する。時間:30分)

この時、新しいテストチャーターを用意するのか、「テストチャーターのリストを作ってるから次のチャーターをやろう」のように事前に用意したチャーターを実行するかはその時々です。

 

 

箸休め『日々を楽しむコツ』

箸休め『日々を楽しむコツ』

仕事では「目的は何か?」を意識することはとても大切です。

そこがフワッとしてしまうと、やっていることがブレブレになってしまうからです。

けれど、プライベートなことまで目的を考え始めてしまうと大変です。

プライベートのことまでそんなことを考えている人はいるの?と思うかもしれませんが成長を意識している人ほど多いように感じています。

コスパ・タイパを考え始めたら注意

当たり前のことですが、好きなことは好きなようにやればいいのです。

けれど時間やコスパ・タイパのことを意識しだすとそうなりません。

作者の場合です。

僕は絵を描くことが好きです。昔はジョジョの落書きを描いたりして楽しんでいました。

描きたいから描いていました。

ただ描いて、自分で見て「今回は上手く描けた!わーい!」とやっていました。

けれどマンガを描き始めてからは考えが変わってしまいました。

「この落書きを時間をかけて描いたところで何にもならないよな」

「描くのに1時間はかかるし……その時間があるならマンガを描いたほうがいいのでは?」

その落書きを描く目的がないので意味がない。そんなところです。

他にも以下のようなことがありました。

「映画で2時間とられるなら、その時間でもっといろんなことができるのでは?」

「プラモデルを作るのは楽しいけど、それ作って何か意味あるの?」

「ゲームで時間を溶かして自分は何を得られた?」

「アニメを見る意味とは?」

 

まえに実家にいたときに妹に言われたことがあります。

「休みの日くらい生産性を考えないで楽しんだら?」

我慢して「大人」になるとやりたいことがない状態になってしまう

「やりたい!」と思ったことについてアレコレ考えてやらないでいると、「やりたい」と思う気持ちがしぼんでいつしか「やりたい」とも思わなくなってきます。学習です。

「ただただ楽しむ」

この思考・行動が抑制されてきます。

こうなってくると「やろうかな……」と思ったところでこんなことが起きます。

「映画を見ている時間があるなら、その時間でもっといろんなことができるのでは?」

そう思って映画を見るのをやめるのですが、結局その時間にやりたいことが浮かばないので何もしない……そんな状態が発生してきます。

 

メリットもなくタイパも悪い。けどやりたいと思ったことを育てることは大事

好きなことは好きなようにやればいいのです。

その行動が何かの成長につながるかとか、タイパだとか考える必要はありません。

「映画を見たいと思ったから見てみる」

「プラモを作ろうと思ったら作ってみる」

「気になるアニメがあるから見る」

これでいいんです。

それが日々を楽しむコツです。

 

 

 

 

 

 

 

o1にテスト観点を出してもらった結果がエグい

o1(OpenAI o1)はGPTの冠が外れたLLMのモデルです。

o1は思考時間をとることにより、4oよりも高度な推論が可能となっているモデルです。

数学やコーディングのテストにおいて4oのスコアを大きく引き離しています。

そのo1-previewを用いてサンプルアプリのテスト観点を出してもらい、私が出したテスト観点と比較を行ってみました。

 

  • 話を進める前にテストについて大事なこと
  • 結論から
  • お題と僕が出したテスト観点
  • o1にテスト観点を出してもらう
  • o1が出したテスト観点を確認
  • 私が出したテスト観点と比較
  • o1ではどういったテスト観点が出せなかったか
  • 私はどういった観点が出せなかったか
  • o1が出した観点でテスト項目を作ってもらった結果
  • これらの結果からo1のテストの活用について
  • o1を使ったこんなテスト作成の流れはどうだろう?

 

話を進める前にテストについて大事なこと

テストにおいて仕様通り動くかのチェックはとても大切です。

ですが、それだけではテストは足りません。

仕様には書いていない考慮漏れで問題が発生する、端末の画面サイズで問題が発生する、他のシステムと連携で問題が発生してしまうといったことがあります。

数年IT界隈にいる人でしたら、そういったところで本番障害に遭遇して苦労した経験があるかと思います。

仕様通り動くかのチェックは最低限のテスト活動であり、加えて仕様外に目を向け「発想」する必要があります。

尊敬する兄貴分の池田さんの資料より

テストとは、エラーをみつけるつもりでプログラムを実行する過程である

by Glenford J. Myers (ソフトウェア・テストの技法 第2版)

なぜこの話をしたかというと、これから話すo1の結果に関係があるからです。

 

結論から

  • 結果
    • o1-previewでは62.7% (42件/全67件)のテスト観点を出せた (全体 = 僕の出した観点とo1が出した観点のマージ後の合計)
    • o1-previewでは機能テストにおいては仕様に書かれた内容までである
    • o1-previewではユーザビリティ、セキュリティ、互換性などの~lity系の観点を出せる
  • o1活用の考え
    • o1にベースとなるテスト観点を出してもらって、人間が暗黙知、経験からテスト観点を追加しテストを作っていく
    • 仕様確認である動作チェック部分はo1で作ってしまいスモークテストとする。並行して人間が不足観点部分のテストを作る(o1と人間の分業)
続きを読む

YouTube動画「私はこうやってマインドマップでテストすることを出す!」

YouTube動画「私はこうやってマインドマップでテストすることを出す!」

作者は会社でよく「マインドマップを使ってテストすることを出そう」という講義をします。

そうすると「どうやって出すか実際に見せてください!」と言われることがあります。 今回の動画ではサンプルアプリの仕様を使って実際に僕がマインドマップを描いていく様子を見ながら、何を考えて描いたかを説明します。

サンプルアプリは前に書いたアプリです。

testerchan.hatenadiary.com

動画

www.youtube.com

 

動画で使ったスライド

speakerdeck.com

 

実際に描いたマインドマップ

Mindmeisterのリンク

箸休め回『境い目』

箸休め回『境い目』

テスターちゃん2巻の締め切りが10/31で必死に頑張っている作者です。

今は章と章の間の箸休めがないところが多いので一生懸命描いている最中です。

 

さて、今回は境い目の話です。

作者はここのところハードウェア系の人になっています。

ハードウェア(組み込み系)だとマンガに描いたように特定の境い目ひとつでON/OFFを切り替えてしまうと大変なことになってしまいます。

例えば温度が40度になったらON/OFFにする機械があったとします。

その機械が熱をもって40度になったらどうなるでしょうか?

40度まで温度が上がったら電源がOFFになります。

電源がOFFになるので当然機械の温度は下がります。

そうすると39.9度になるので電源がONになります。

電源がONになるので当然機械の温度が上がります。

そうすると40.0度になるので電源がOFFになります。

ウサコが言うように、これをひたすら繰り返してしまうことになるのです。

なので、こういった場合は40度で電源がOFF、35度で電源がONになるといったようにふたつの境い目を設けます。

このことをヒステリシスというそうです。

 

SESSAME(組み込みソフトウェア管理者・技術者育成研究会)の用語集では以下の様に記載されています。

【ヒステリシス(Hysteresis) / シュミット・トリガ(Schmitt Trigger)】《HW》

入力信号、電圧に対して上限下限別々の値のスレッショルドレベルを持つことをヒステリシスといい、上限値、下限値の差をヒステリシス電圧という。
この上限値、下限値のスレッショルドレベルより入力が大きくなるか、小さくなるかを変化のトリガーとするFF(フリップフロップ)をシュミットトリガという

https://www.sessame.jp/knowledge/terms_main_files/terms-ha.html

 

 

最後のお題は時間がある時にでも考えてみましょう!

 

 

///////////////////////////////////////////////////////

 

 

さて、お題について。

人で考えると某マンガに引っ張られそうなので、上に引き続き機械の電源ON/OFFで考えてみます(笑)

とりあえず38度の時を1回確認して終わり、だとテスト不足です。

前提条件が大切になります。

電源がONになっているとき、つまり40度に到達していないときは38度の時は電源ONが期待結果です。

ですが電源がOFFになっているとき、つまり40度まで到達してから温度が下がってきて38度になったときは電源OFFが期待結果です。

同じ38度という温度でも期待結果が前提条件によってふるまいが変わります。

さらに機械によっては、40度に到達しておらず電源ONの状態で38度の時にコンセントやバッテリーを抜き差しする(根本から電気の供給を切ってしまってリセットする)と、電源がONになるのかOFFのままか、といったことも考えたりします。

 

 

「勉強する必要あるんですか?今のままでよくないですか?」の質問のレス

「勉強する必要あるんですか?今のままでよくないですか?」

このような質問があったりしたので、「勉強する必要ある?」という動画を作ってみました。

作者の考えもブログの下部に記載しています。

作ったスライド

speakerdeck.com

動画

www.youtube.com

 

「仕事まわっているし良くないですか?」は、知識がないため別の方法や問題に気づかない状態

動画の最初にこの話をしています。(他の内容が気になりましたら動画にてです)

「残業もたくさんあるけど、毎回なんとかリリースはできてるし、これでいいか」

という状態だったとしましょう。

本当は今まで通りの結果を得るために、もっと簡単な方法があるかもしれません。

実は問題が発生し始めているかもしれません。

ですが知識がそもそも頭の中にないため、それに気づくことさえできない状態である可能性が高いです。

例えてみます。

"コピー機"を知らなかったとしましょう。

「この資料の複製を作ってくれ」

と言われました。なので一生懸命写生して

「みんなで分担して2時間で終わった!」

こうなりそうです。

そして次頼まれたときも

「前もみんなで分担してすぐ終わったし、残業にはなっちゃうけど今から頑張ってみんなで写生しよう!」

こうなりそうです。

だってこの人は"コピー機"を知らないのですから。

知識(引き出し)がないのでそんな方法があることは発想できません。

思いつくきっかけすらないのです。

 

知識があると「今まで見えていなかったものが見えてくる」と言い換えられそうです。

「全数組み合わせで500項目もある!? "ペアワイズ法"を使って項目減らすことができるのに……」

「毎日手動でリグレッションテストを回してるの!? "自動テストツール"を使えばいいのに……」

「ここのテスト、全部サーバー側のロジック確認なんだから全部アプリを操作して確認しなくても"APIテスト"で戻り値を確認すればいいんじゃないかな……」

ダブルクォーテーション部分は先の例でいう"コピー機"にあたる部分です。

 

さて、例に挙げたコピー機で話を進めましょう。

これで周りの人も全員"コピー機"を知らなければ幸せかもしれません。

「あぁ、写すの大変だよね。手伝おうか」

そういってくれるに違いありません。

ただきっと

「書類の複製作業が毎回重いんだよなぁ。どうにかならんものか……」

そう思っていることでしょう。

 

ただ作業者以外の人が"コピー機"を知っていたらどうでしょう?

「書類の複製作業には5人で6日かかります!」

作業する人は"コピー機"を知らないので写生するとするとこうなるでしょう。

けど知っている人は「ええ!?」と思いそうです。

コピー機を使わないのかな……そう思うかもしれません。

コピー機を使ったりはしないのです……?」

というかもしれません。

けどここで

「コ…コピ……? いやいやいや無理っ無理です!! そのコ……コピー機?とやらの使い方は全然わからないですし、今まで複製作業は写生することで回っていたんです。上手くいっているのだからそれでいいじゃないですか」

このような感じでしょうか。

 

勉強をすると「今まで見えなかったものが見える」ようになります。

"コピー機"の存在に気づいて使い方を学んで、業務プロセスが改善され、今まで残業まみれだったものが定時以内に終わるようになるかもしれません。

 

勉強は大変なので無理強い(むりじい)はしません。

あなたがやりたいと思ったときに勉強するのが一番です。

そのご褒美は。

知識によって視界が開けて新しい世界を見ることができるでしょう。

 

 

 

 

 

 

 

 

 

 

テスト分析、テスト設計練習用の仕様とアプリを作ったので共有

こんにちは。今はテスターちゃん書籍2巻作成に追われる作者です。

 

今回はテスト分析、テスト設計の研修/練習で使うための仕様とアプリを作成したので共有します。

会社の研修や練習でご自由に使っていただいてOKです。

仕様

speakerdeck.com

 

開発したアプリ

https://jam0824.github.io/warikan/

 

github

github.com

 

目的

仕様書からそのままテストケースを作ると、仕様に書かれた動作をなぞるだけのテストになってしまいます。けれど仕様に全てのことが書かれていることはありません。

例えば最小値については書かれているけれど最大値は書いていない。例外処理については書かれていないことがあります。

今回用意した仕様は、よくあるメインとなる部分だけが書かれた仕様です。

この仕様に書かれたことだけのテストでは全くテストは足りません。

企画者に質問をしてより具体的にする(仕様の抜け漏れを伝えることで問題の作り込みを防ぐ)、行間を読む、といった必要があります。

この仕様とアプリを使って、テスト分析、テスト設計の練習をしてみましょう。

実際に動くアプリも用意したので、テスト実行の練習もできます。

 

仕様書に書いていないその他の仕様

以下は仕様書に書いていない仕様です。

研修などの実施者は質問に回答するためにお使いください。

  • 対応ブラウザはChrome,Edge,Firefox,Android chrome, iOS safari
  • 対応OSはWindows8以上、macOS12以上、Android8以上、iOS14以上
  • サーバーとのやり取りはなし。クライアント側での処理のみ。
  • リロードすると値はリセットされる
  • エラーはポップアップで表示
  • 整数以外の文字列が入力に入っていた場合は「整数以外の文字が含まれる箇所があります。」を表示
  • 合計金額が空だった場合は「合計金額が空です。」を表示
  • 合計金額が999999より多かった場合は「合計金額が999,999円以上です。」を表示
  • 割り勘をしたい人数が空だった場合は「割り勘をしたい人数が空です。」を表示
  • 割り勘をしたい人数が0だった場合は「割り勘をしたい人数が1人未満です。」を表示
  • 割り勘をしたい人数が99より多かった場合は「割り勘をしたい人数が99人を超えています。」を表示
  • 金額を固定したい人数が99より多かった場合は「金額を固定したい人数が99人を超えています」を表示
  • 固定する金額が999999より多かった場合は「固定する金額が999,999円を超えています。」を表示
  • 割り勘の金額が1円を下回った場合は「割り勘の金額が1円未満です。」を表示
  • エラー発生時は「一人の金額」「不足金額」の表示は0円にする
  • 計算された一人の金額は小数切り捨て

 

パワーポイントのデータ

docs.google.com

画像のデータ

 

2023クリスマススペシャル「バグバッシュ大会」【全部】

2023クリスマススペシャル「バグバッシュ大会」

ソフトウェアテストAdvent calendar 2023 の24日目のマンガです。

ちまちまと描いていましたが、ようやく完成です。

ゆっくりでも完成できればいいのです(笑)

以下のマンガと、今回描いたノリエ・きゅんチームのまとめとなります。

2023クリスマススペシャル「バグバッシュ大会」その1 - テスターちゃん【4コマ漫画】

2023クリスマススペシャル「バグバッシュ大会」その2 - テスターちゃん【4コマ漫画】

 

バグバッシュ

一般的に、チームの様々な役割の人が限られた時間の中で手動テストを行いバグを探し出す手法です。

手動の探索的テストのために普段から我々が利用するアプローチとして、バグバッシュがある。エンジニアのチームと関連人員(マネージャー、プロダクトマネージャー、テストエンジニア、その製品に親しんでいる者全員)が「会議」の予定を設定するが、そのセッションでは、関係者全員が製品を手動でテストするのだ。

Googleのソフトウェアエンジニアリング p346

よく発表される事例で見かけるのは、マンガの様にイベントとしての実施ですね。

 

メリットとしては以下のようなことがあります。

  • 多角的な観点からのバグ探しができる
  • 関係者同士が知識を共有して相互に学びあうことができる
  • アイディアの共有により改善のきっかけになる
  • エンゲージメントの向上(チームワークの強化、コミュニケーションの促進)

イベントとしてのバグバッシュ

作者はイベントとしてのバグバッシュをまだ行ったことがありません。

ですので実施したことが語られているブログを紹介します。

楽しそうなので、そのうち作者もイベントをやってみたいと思っています(笑)

engineerteam.note.jp

qiita.com

tech.asken.inc

作者が行ったバグバッシュ

作者がどういったバグバッシュを行ったかを記載しておきます。

その時取り扱っていたものは「音声認識」です。

話した言葉を認識(音声→テキストに変換)して、該当機能を実行します。

完璧に音声→テキストに変換できればいいのですが、声や言い方によってはうまくいかない場合があります。

例えば「天気」と言っているのに「ペンキ」と変換されてしまう人がいる……といったことがあります。

AIの再学習で解決するのはコストが高く、「ルール」で変換をすることが多々あります。先の例では「今日のペンキは?」というテキストになっていたら「ペンキ→天気」と変換してしまうような手法です。

大勢で試してその時に発生した誤変換を一気に処理したかったが開催目的となります(バグバッシュとは違う気もしてきたけど…)

行ったこととしては

  • 時間は1時間
  • 参加者はテスター、開発者、企画者(8人くらいだったはず)
  • そのときリリースしようとしている機能に対して実施

このような感じです。

広い会議室でみんながひたすら声を出していました(笑)

誤変換されて機能が実行ができないときはその場で報告して、開発者がその場で即時修正していきます。

これによって、テスターだけでは出せない問題(声質、言い方など)が一気に出せましたし、それ以外にもテストケースを用いたテストでは出なかった機能的なバグも見つけることができました。

他、「そういえばこの場合はこう言うよね」と今まで気づいてたけど特に言うほどでもない問題を共有してもらえる、誤爆で面白い返事があるとみんなで爆笑するなど和気あいあいと実施させてもらいました。

ただ、開発者はお一人が修正専門にはなってしまってはいました。(そりゃそうなりますよね……)

 

きゅんちゃん姉のセリフの翻訳

きゅんちゃん、またこったにマンガばし買って~

きゅんちゃん、またこんなにマンガばっかり買って~

 

「おこづかい足りる?あげよっか?」も本当は津軽弁で書こうと思いましたがさすがに伝わらないのでやめました。

「じぇんこあんな? けらが?」

です。

 

きゅんちゃん姉の設定

名前:並岡六華(なみおかりっか

きゅんちゃん(並岡九華)のお姉ちゃん。

青森の役場に勤めている。

ワープロソフト一太郎を自在に操り、役所のみんなから頼りにされている。

それが気に入らないのか、お局様方に嫌味を言われるが本人はそれが嫌味だということにはまったく気づかず楽しくお仕事をしている。

自分では訛っていない方だと思っているが、どこからどう聞いても津軽弁である。

とはいえ周りはみんなもっと訛っているので特に問題はない。

九華(きゅんちゃん)には昔からとにかく甘い。

九華も就職したのに、会うとついついおこづかいをあげてしまう。

家では寒くなると大体ドテラ(はんてん)を羽織っている。

 

ぞあっ

パロが好きなのと、絵の練習のためにこういうコマをついつい描いてしまいます。

ちなみにトリコ3巻の絵です。

この辺です。

 

 

 

 

 

 

自分のマンガのキャラをAIに学習させてみた[Stable diffusion+LoRA]

僕は絵を描くことが好きだけど、マンガで大量に絵を描くときはメンドイと思うことがあります。

今マンガを描いていてそんな気持ちがわいて「そうだ、AIに自分のキャラを覚えさせて出力させよう」と考えました。

試してみた結果を書こうと思います。

 

 

今は簡単に絵を学習させるようなサービスはない(2024/5/2現在)

以前、絵柄を学習・出力させるサービスが一瞬出ました。

案の定絵師の間から大クレームが出てクローズしました。

絵師の間では、トレースした絵を自分の絵として発表する人が問題視されています。

そこに絵柄を覚えさせて出力するサービスの登場です。

自分の絵ではなく、人の絵を勝手に覚えさせて出力させてしまう人は出てきてしまうでしょう。

そのようなわけで気軽に試せるツールは残念ながらありません。自分の絵を覚えさせるにしても自分で環境構築・学習を行う必要があります。

僕はLoRA(Low-Rank Adaptation)という手法を使いました。

これは既存のモデルのパラメータに、別途学習したパラメータを追加することで新しいタスクやデータに対応させます。

モデル全部を再学習させるわけではなく、既存のモデルはそのままで、それに新しいパラメータをくっつけることで新しい知識をゲットさせるやり方です。

オプション装備と言えばわかりやすいかもしれません(笑)

 

構築方法は割愛

詳しい構築方法は記載しません。

sd-scriptsを使用しました。

windowsですと途中tritonwindowsに対応していないので詰みます。

windowsの方は wsl -d ubuntu といったようにwslを使う必要があります。

また様々なブログに書かれている方法でも結構エラーが発生します。

エラーを調べてどのライブラリが足りないか、バージョンの依存関係など調べてpip installしていきましょう。

学習については以下のような設定で行いました。

学習回数は20回。lossは0.06ほどでこれ以上学習させてもこれくらいでした。

 

学習データは使ってもいいです

学習データは「テスターちゃん」に出てくるりんちゃんです。

以下のリポジトリにTrainingData.zipを置きますのでどなた様も使っても問題ありません。(エッチな絵はダメ)

GitHub - jam0824/LoRATrainingData: LoRA用の学習データです

タグデータは作るのが面倒だったのでイメージtoテキストのAIで出力させたものをそのまま入れてます。また全てに"rinchan"タグを入れています。

吹き出しや背景を消した画像が入っています。

 

そんなことはいいから結果は!?

結果としては

特定のキャラを出すのはやっぱり難しい。手直しして使う必要あり。

モブキャラを描いてもらうには良さそう

です。

結構イイ感じではあるのですよ。

けどちょっときらら系になるといいますか幼くなるといますか……。

出力を並べてみます。

 

ControlNet + LoRAも試してみた

ControlNetとは、ポーズや構図を画像で指定する技術です。

それとLoRAでよりイメージしたものに近い絵を出そうと試みました。

こちらは……

下絵には使えそうだけど、これでいけるかというと難しい

でした。

以下のような下絵段階の絵を指定してみました。

出力させるとこうなりました。

イイ感じではあるけど、そのままきれいな線になってくれたら嬉しかったんだけどなーといったところです。

 

まとめ

自分の絵を学習させて出力させるのは、おおよそそれっぽい絵が出てくることがわかりました。

ただ、オリジナリティがある特定キャラを安定して出すのは今のところ難しそうに見えます。

飾り気がなくてシンプルなキャラならいけそう、または毎度変わってもいいようなキャラ――つまりモブキャラに活用するのは良さそうです。

また、最終的なキャラとして使わずとも、ネーム段階である程度あたりをつけるのにつかっても良さそうです。

 

僕は絵を描くことが好きなのか、最終成果物が欲しいのか?

AIで絵を出力していて思ったこと。

 

僕は絵を描きたいんだっけ?

最終成果物(出来上がった絵)が欲しいんだっけ?

 

マンガであれば、僕の場合は「初心者のみんなにソフトウェアテストの知識を面白おかしくわかりやすく届けたい!」という想いがあります。

それを表現するための絵は僕が描いてもAIが描いても最終的に上のことが届けられていたらヨシとなります。

ならば「出来上がった絵が欲しい」がコスパ/タイパ的には良いです。

実際、この実験を行った目的はそうです。

 

けどそう考えて、AIで出力された絵を切り貼りしているシーンを想像したとき「僕は面白くないな」と感じました。

僕は「みんなが知識が得られたらそれだけで幸せ」といった聖人君主ではなく、自分自身も楽しみたいわけです。

僕は絵を描くたびに

「今回は可愛く描けた!」

とか

「前よりうまくなってんじゃん~」

なんて毎度まさに自画自賛しています(笑)

自分の手で少しずつ形ができていくのも好きだし、自分が頭の中でイメージしていることがその通り絵に描き表せたときはとても嬉しい。自分の成長を感じたときなんてニマニマしています。

そんな「お絵描き活動」が僕は好きなんだと思います。

 

だからと言ってすべてをすべて自分で描くのが好きかというと今度は「メンドイ」が首をもたげてくるわけです。

僕はわがままなのです(笑)

なので最終的には

「自分で描きたいところは描く。そうでもないところはAIでいっか」

と自分の中で決着しました(笑)