形式スクラムの功罪

2023/07/01 開催
スクラムフェス大阪 | Scrum Fest Osaka 2023 での発表資料です。

Transcript

1. 形式スクラムの功罪
 Motoki Hirao

2. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 発表者について
 • Motoki Hirao
 • twitter: @__yumechi misskey: @__yumechi@misskey.systems
 • ４月から転職して開発者になりました（それまではスクラムマスターを１年 ほど）
 • なぜかスクラムとかアジャイルを入れるぜ！ってタイミングで会社や組織に 所属しています
 • 趣味はゲームやカンファレンス（主に関東）に参加すること

3. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 初めての大阪、どきどきわくわくしてます
 • 通過駅や乗り換えのタイミングでご飯食べに降りたことはありますが、それ 以外では来たことがない
 • 日曜日は観光して帰る予定なので、おすすめスポット有ればおしえてくださ い！
 • 特になければ大阪城行くつもりです

4. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 この発表に関しての注意事項
 • 私個人の経験による主観のため、N=1の内容でしかありません
 • 記憶ベースで書いているので事実が若干歪んでいる可能性もあります
 • 特定の所属組織の話ではなく、多くの場所でアジャイル・スクラムを実践す るんだ！となって現実的に私・私たちが見てきた課題点を取り上げていま す

5. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 本発表の概要
 • ウォーターフォールライクな開発チームにスクラムを導入する難しさ
 • 形式的なスクラムで解決できた問題
 • 形式スクラムの問題
 • 今後うまくやれそうな導入を考えてみる

6. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 本発表の概要
 • ウォーターフォールライクな開発チームにスクラムを導入する難しさ
 • 形式的なスクラムで解決できた問題
 • 形式スクラムの問題
 • 今後うまくやれそうな導入を考えてみる

7. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 本発表の概要
 • ウォーターフォールライクな開発チームにスクラムを導入する難しさ
 • 形式的なスクラムで解決できた問題
 • 形式スクラムの問題
 • 今後うまくやれそうな導入を考えてみる

8. ライクって
 なんやねん！
 https://soco-st.com/1722 より

9. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 なぜウォーターフォール「ライク」なのか
 • 厳密にウォーターフォールを実行するのは難しいし、体感100%そのプロ ジェクトやプロダクトルールの何かが運用されている
 ◦ 参考： だったら WF でやればいいぢゃない! 
 ◦ https://www.docswell.com/s/tommy109/K2XRMZ-2023-01-12-231349
 • おそらく社会の共通認識的にこれくらいの概念のなにかだけが残っている （と、発表者は考えている）
 ◦ 要求分析、設計、実装、テスト、総合・受入テスト、リリース 

10. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 そんな中でスクラム・アジャイルを学習する壁
 • 人はパターン認識的に学習しようとするので、ウォーターフォールライクな 手法と対比して学習しようとする
 ◦ https://ja.wikipedia.org/wiki/パターン認識
 ◦ アジャイルソフトウェア開発宣言は対話・協調を大事にし、変化し続けるソフトウェア開発 という点でイメージがしやすい（表面的には…）

11. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 マッピングできないスクラムの概念
 • スクラムイベントがそもそもマッピング不可能
 ◦ 朝会、夕会 → デイリースクラム
 ◦ プロトタイピングなもの？ 基本設計？ → スプリントレビュー
 ◦ 計画や要件定義？？ → スプリントプランニング
 ◦ 振り返り？（そもそもウォーターフォールライクにはない） → スプリントレトロスペクティブ
 • 役割についてもマネージャー → スクラムマスター？？
 • プロダクトオーナーとマネージャーの違いは？？

12. 知識が共通認識
 になっていない場合は
 更に色々出てくる…

13. はい、理解できません
 終了です

14. はい、理解できません
 終了です
 https://www.irasutoya.com/2014/03/blog-post_2687.html より

15. うまく行った
 ワークを紹介

16. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 頑張ってみんなで学びましょう
 • 実際やってみて良かったこと
 ◦ スクラムガイドをみんなで読んで理解を深める（定期的に） 
 ◦ スクラムガイドをみんなで音読する
 ◦ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて 可視化する
 ▪ ドキュメントの準備が大事、体制図は大事 
 • 実際やってみてうまく行かなかったこと
 ◦ 各々でスクラムガイドを読んでもらう 

17. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 頑張ってみんなで学びましょう
 • 実際やってみて良かったこと
 ◦ スクラムガイドをみんなで読んで理解を深める（定期的に） 
 ◦ スクラムガイドをみんなで音読する
 ◦ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて 可視化する
 ▪ ドキュメントの準備が大事、体制図は大事 
 • 実際やってみてうまく行かなかったこと
 ◦ 各々でスクラムガイドを読んでもらう 

18. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 頑張ってみんなで学びましょう
 • 実際やってみて良かったこと
 ◦ スクラムガイドをみんなで読んで理解を深める（定期的に） 
 ◦ スクラムガイドをみんなで音読する
 ◦ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて 可視化する
 ▪ ドキュメントの準備が大事、体制図は大事 
 • 実際やってみてうまく行かなかったこと
 ◦ 各々でスクラムガイドを読んでもらう 
 みんなで アンラーンだ！
19. 自分もよくわからない！
 というのを相手に伝えながら
 同期的にワークするのも
 時には大事

20. 心理的にも自分一人だけが
 わからないという
 状態を防げる（副次的な効 果）

21. みんなで行け
 的なやつ
 https://loosedrawing.com/illust/1129/ より

22. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 • 関係者に我々はスクラムをやります！ということを伝える
 ◦ コミュニケーションが増えて手戻りが減るとかのメリット 
 ◦ MTGが多少増えて、リーダー・マネージャーを介さないコミュニケーション増えるデメリット 
 • スプリントやイベントをいつ行うのか調整する
 ◦ 体感、なぜか２週間スプリントで始めるものの１週間にすることが多い 
 ◦ （スプリントの経験数が増えるとその分うまくスプリントが回るようになるため） 
 ◦ スクラムイベントの時間が長すぎても良くないので調整する 
 スクラムのメリットや進め方を浸透させる

23. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 本発表の概要
 • ウォーターフォールライクな開発チームにスクラムを導入する難しさ
 • 形式的なスクラムで解決できた問題
 • 形式スクラムの問題
 • 今後うまくやれそうな導入を考えてみる

24. 形式スクラムの定義…
 スクラムイベントと
 各種役割は決めて
 動いていることとします

25. twitter: @__yumechi misskey: @__yumechi@misskey.systems

26. まとめると、
 納得感かなぁ
 https://loosedrawing.com/illust/1378/ より

27. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 ウォーターフォールライクで起きがちな問題
 • これまでのコミュニケーション
 ◦ リーダー・マネージャーが決めてくる 
 ◦ その決定に対して、開発者視点での問題は上がりづらい 
 • これまでのスプリント・イテレーション
 ◦ 機能ごと・プロジェクトごとになるので スパンが長い、リズムがない
 ◦ 毎回ふりかえることはない、というか 忘れる

28. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 スクラムの持つ性質によるメリット
 • コミュニケーション
 ◦ スクラムイベントで必然的に増える 
 ◦ いろいろな人の発言を通して、知見や考え方が共有される
 ◦ ふりかえりから課題や問題を共有し、より良いアイディアで解決できる 
 • スプリント・イテレーション
 ◦ タイムボックスが明確に区切られているので、 次までに何をするかが明確
 ◦ どこまで進められるのかの合意形成もできる 
 ◦ イベントを通してプロセスの改善もできる

29. ただし、これは
 どちらかといえばこれまでの
 コミュニケーション
 に問題があり、それが顕在化
 しただけに過ぎないのだ…

30. 開発者も言われたものを
 作るのではなく、
 より便利になるものを
 作りたい（はず）

31. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 専門性を生かした仕事をする
 • コミュニケーションが改善されて専門性を生かし、色々任せながら進められ るようになる
 ◦ コミュニケーション量が増え、タスクの取りこぼしが減り役割分担が明確に 
 ◦ POはプロダクトのことを考えながら優先順位を考える 
 ◦ SMは開発者を支援しつつ、プロダクト開発がうまく進むようにいろいろ動き回る 
 ◦ 開発者は開発視点で意見しながらプロダクトに貢献する 

32. コミュニケーションを
 密にすることで
 私たちはプロダクトの
 方向性を理解し、
 ユーザーの行動変容をどう
 起こしたいのかを理解する

33. プロダクトが向かう
 方向やユーザーから
 考えたときの
 納得感がある！
 https://loosedrawing.com/illust/987/ より

34. 言われたものを作る
 を超え始めた！

35. ただし、
 デリバリ速度の改善
 まではわからないなぁ
 という感想…（これまでの 計測が甘い問題も含む）

36. ＝スクラムは開発速度を
 改善する銀の弾丸ではな い

37. ただ納得感があることは
 もっと良いステップに
 つながるはず
 （うまく言葉にできない…）
 https://loosedrawing.com/illust/1434/
 より

38. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 本発表の概要
 • ウォーターフォールライクな開発チームにスクラムを導入する難しさ
 • 形式的なスクラムで解決できた問題
 • 形式スクラムの問題
 • 今後うまくやれそうな導入を考えてみる

39. よし、順調にイベント が回っているな！

40. ただなんかうまくいっ てない気がするぞ？

41. アジャイルソフトウェア
 宣言に立ち返ると

42. 「プロセスやツールよ りも個人と対話を」
 と一番上に書いてある
 
 https://agilemanifesto.org/iso/ja /manifesto.html
 

43. アジャイル宣言の背後 にある原則
 に立ち返ると

44. 「顧客満足を最優先 し、価値のあるソフト ウェアを早く継続的に 提供します。」
 https://agilemanifesto.org/iso/ja/principles.html より

45. 「チームがもっと効率を高 めることができるかを定期 的に振り返り、それに基づ いて自分たちのやり方を最 適に調整します。」
 https://agilemanifesto.org/iso/ja/principles.html より

46. おやおや？？？

47. 形式スクラム最大の
 弱点、それは…

48. 顧客への価値提供より
 プロセスに従う
 選択をしてしまうこと
 🙀
49. プロダクトを良くする
 という本質から
 離れてしまうこと
 😇
50. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 イベントが定義されていることによるデメリメ
 • スクラムイベントが明確に定義されていることが良い面も悪い面も包含して いる
 ◦ 良い面： 開発を一定のリズムで行う、コミュニケーションを取れる、スプリントゴールを設定 して明確な形で進められる
 ◦ 悪い面: スクラムイベントをやっていればスクラムという誤った認識や誤解を持ってしまう、 スクラムイベントに参加することが仕事になってしまう（コミュニケーションを取ることはしな くてもよい）
 

51. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 ウォーターフォールライク概念の亡霊
 • ウォーターフォールライクな開発プロセスにマッピングされたアジャイル・ス クラムから外れた概念のまま進行してしまう危険性
 ◦ リリースなのか、デプロイなのか、納品なのか 
 ◦ ストーリーポイントなのか、工数なのか 
 ◦ 設計？実装？テスト？
 • これまでの開発プロセス・関係性に引き戻される危険
 ◦ 今までのやり方でもなんとかうまくやれていたから戻そう 
 ◦ 開発者はMTGに出ずに開発に集中したい etc…
 

52. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 これが進行していくとどうなるのか？
 • 必要なメンバーが揃わないままスクラムイベントスタート
 ◦ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー 
 ◦ あとから議事録を眺めて個別の追加の MTGなどが色々組まれる
 • ファシリテーターだけが方向性を定める形になってしまう
 ◦ 気がついたらファシリテーターが１時間話して終わってしまった！ 
 ◦ ファシリテーターが毎回固定…
 • etc…etc…
 

53. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 これが進行していくとどうなるのか？
 • 必要なメンバーが揃わないままスクラムイベントスタート
 ◦ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー 
 ◦ あとから議事録を眺めて個別の追加の MTGなどが色々組まれる
 • ファシリテーターだけが方向性を定める形になってしまう
 ◦ 気がついたらファシリテーターが１時間話して終わってしまった！ 
 ◦ ファシリテーターが毎回固定…
 • etc…etc…
 
 もう 疲れちゃって…
54. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 疲れてくると負のループに陥る
 • これまで問題になってたことが戻ってくる
 ◦ リーダーだけMTGに出ましょう→コミュニケーション不足
 ◦ ふりかえりはしません！→ プロセスが改善されない
 ◦ スケジュールを決めたのでこの通りやりましょう →開発の課題が上がりにくくなり、大変に なる
 • 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱…
 ◦ 疲れて労働時間が長くなる、全くあまりいいことはない 
 ▪ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる 
 ▪ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018p df/20180601041.pdf

55. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 疲れてくると負のループに陥る
 • これまで問題になってたことが戻ってくる
 ◦ リーダーだけMTGに出ましょう→コミュニケーション不足
 ◦ ふりかえりはしません！→ プロセスが改善されない
 ◦ スケジュールを決めたのでこの通りやりましょう →開発の課題が上がりにくくなり、大変に なる
 • 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱…
 ◦ 疲れて労働時間が長くなる、全くあまりいいことはない 
 ▪ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる 
 ▪ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018p df/20180601041.pdf
 スクラムマスター 出番です！
56. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 正しいスクラムに向き直りをするために
 • すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス クラムサバイバルガイドを読んで実践する
 ◦ https://www.maruzen-publishing.co.jp/item/b304740.html
 • アジャイルソフトウェア開発宣言やスクラムガイドの読み直し
 ◦ 概念をもう一度捉え直す
 ◦ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い意味で外れてい るのかを考える
 • ファシリテーターを毎回変えてみる
 

57. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 正しいスクラムに向き直りをするために
 • すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス クラムサバイバルガイドを読んで実践する
 ◦ https://www.maruzen-publishing.co.jp/item/b304740.html
 • アジャイルソフトウェア開発宣言やスクラムガイドの読み直し
 ◦ 概念をもう一度捉え直す
 ◦ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れている のかを考える
 • ファシリテーターを毎回変えてみる
 
 あんまり うまくいかなかった
58. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 それぞれに対してうまく行かなかったポイント
 • すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス クラムサバイバルガイドを読んで実践する
 ◦ https://www.maruzen-publishing.co.jp/item/b304740.html
 • アジャイルソフトウェア開発宣言やスクラムガイドの読み直し
 ◦ 概念をもう一度捉え直す
 ◦ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れている のかを考える
 • ファシリテーターを毎回変えてみる
 
 自分一人で理解してもついてこない なんとなく反応薄め… 個人のファシリテーション能力に強依存、 イベントの再現性がなくなってしまう
59. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 今ふりかえるとこうしたい
 • すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビス クラムサバイバルガイドを読んで実践する
 ◦ https://www.maruzen-publishing.co.jp/item/b304740.html
 • アジャイルソフトウェア開発宣言やスクラムガイドの読み直し
 ◦ 概念をもう一度捉え直す
 ◦ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れている のかを考える
 • ファシリテーターを毎回変えてみる
 
 みんなでスクラムに問題があることを理解し、 改善に向けて活動する 外部者やアジャイルコーチに入ってもらう 何度か様子を見る、まずはデイリースクラムから。 デイリースクラムは回数をこなしやすいので最適。
60. チームメンバー自身が
 各々アジャイルって
 何だ？を理解する
 必要がある

61. 結局最後は
 マインドセットの定着 で本質的に考えられる チームに
 なるのを待つしかない

62. よし、順調にイベント が回っているな！

63. 着目すべきは
 ソフトウェアの提供価値。
 プロセスを見てるのは
 危険信号。

64. 確 集 公 尊 勇
 約 中 開 敬 気

65. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 チームの局所最適化は起きていた
 • 開発手法が同じプロダクト内でバラバラしていた
 • システム間で開発手法を分断すると…？
 ◦ POと話している量が違うので、エンジニア間でも視座の違いが生まれやすくなる 
 ◦ プランナー・ディレクター間でもエンジニアの理解度が変わってしまう 
 ▪ ただ開発を委託する人から、一緒にプロダクトを盛り上げていく人に代わっている人 に代わっている
 ▪ 人によって扱いが…
 

66. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 開発手法は違ってもいいけれど
 • アジャイル・スクラムを採用していないチームにも文化的に浸透が必要かも しれない
 • ステークホルダーに対してアジャイル・スクラムは手法が変わるだけではな く、文化形成が変わり関係性も変わること、と認識を変えてもらう必要が あったのかも
 • いろいろな手法がある状態が無視できないレベルになったら、組織自体が 変わっていく決断も必要かもしれない（私に権限はないですがｗ） 

67. 昨日のKeynote聞いた
 感想では、このあたりの
 突破力は身につけないと
 あかんなとなりました😇😇

68. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 本発表の概要
 • ウォーターフォールライクな開発チームにスクラムを導入する難しさ
 • 形式的なスクラムで解決できた問題
 • 形式スクラムの問題
 • 今後うまくやれそうな導入を考えてみる

69. これはもう、
 スクラムという言葉も
 概念も一回持ち込まない

70. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 スクラムを導入する前にアジャイルマインドをやる
 • 過去の経験からアジャイルの代表例としてスクラムを導入しようと試みてき たが、スクラムイベントというプロセスに飲み込まれた
 ◦ スクラムのプロセスに頭を固定するのは絶対に避けたい 
 • なのでいきなりスクラムに変えよう、はなんとしても避けたい
 ◦ アジャイルソフトウェア開発宣言や、アジャイル宣言の背後にある原則を読む 
 ◦ 現状の自分たちの開発においてコミュニケーション不足なところから変える 

71. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 レトロスペクティブ（ふりかえり）から入れたい
 • 自分たちを知らないと手の打ちようがない、まずは自分たちを知ろう
 • 経験上、その結果やプロセスについてのふりかえりは十分でないことも多 い
 ◦ うまくいかなかったプロジェクトとかでものど元過ぎれば … みたいな実感はある
 ◦ とりあえず今の方法でやれているのでやっている、とかは十分にある 
 • コミュニケーションが少なめでもうまく行くのであれば問題ないので無理に やらない
 ◦ 場合によってはアジャイル・スクラムを導入しないのも選択肢に入れて良い 

72. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 どうふりかえるか
 • ふりかえりカタログを見ながら選定する
 ◦ ふりかえりカタログ / Retrospective Catalog - Speaker Deck 
 ◦ https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45d d-911b-f8e5f1308333
 • テーマによってふりかえり手法を変えたり…
 ◦ 普段の開発プロセスのふりかえりは KPTA
 ◦ 前向きになりたいときは Fun, Done, Learnなど
 • ふりかえりの手法選定は自分もまだまだ経験不足なので試行錯誤中

73. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 次はデイリースクラムをやりたい
 • 普段から顔合わせしてコミュニケーションは増やしておきたい
 ◦ コミュニケーションしたことがない相手を減らしておくのは大事だと思う 
 • 毎日話すことによって日々の動向を知りつつ、課題となっている点を共有 し、問題解決や優先順位を相談したい
 • 可能ならモニタリングとかも一緒に見ながら話せるといいなーとか
 

74. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 以降のスクラムイベントは必要に応じて
 • 本質的にやりたいのは気持ちよく働いて、良いプロダクトを顧客・ユーザー に届けることであるので、スクラムを導入することではない
 ◦ スクラムを導入するという方法の目的化は避けなければいけない 
 • 他のスクラムイベントはチームの様子を見ながら
 ◦ デイリーのところでコミュニケーションがいっぱいいっぱいな感じであれば、一旦デイリー に慣れてもらうまで待つ
 ◦ チームが成熟していないのにコミュニケーション頻度が高いスクラムを行うのは難しいの で…

75. 対話しながら
 そのチームにとって
 必要で成長できる
 方法を提案したい
 https://loosedrawing.com/illust/1411/ より

76. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 自分はスクラムマスターが適切だったのか？
 • 技術に触れる時間が減ったことに違和感があった
 ◦ 元々、開発のリードとしてテックリード寄りの考え方だった 
 ▪ 開発したいものを渡すことにやや抵抗があった 
 ◦ アジャイルスクラムについて教えながら、技術的なインプットもアウトプットも行っていた 
 • スクラムマスターになった経験自体はとてもよかった、一方で今の自分が 貢献できることは開発のほうが大きいという感覚
 ◦ 開発者視点でアジャイルを支えられることもたくさんある、自動化など 

77. 自分のキャリアの壁打ち を誰か… 懇親会で…

78. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 まとめ
 • 導入時にはみんなでアジャイル・スクラムを学習しよう
 • アジャイル・スクラムはコミュニケーションが増えるため、コミュニケーションフローの 改善に繋がり、プロダクトの方向性に納得感が生まれる
 • スクラムのイベントをこなす流れになると、定期的にあるイベントをこなすだけになり プロダクトへの指向性が薄れ、本質から遠ざかってしまう
 • スクラム導入を目的とせず、アジャイルなマインドを身につける。発表者も試行錯誤 中！まずはチームとの対話を行う「ふりかえり」が鍵

79. twitter: @__yumechi misskey: @__yumechi@misskey.systems
 利用情報
 • スライド作成: Google Slide https://www.google.com/slides/about/
 • フォント: Noto Sans https://fonts.google.com/noto/specimen/Noto+Sans
 • 利用画像
 ◦ フリーイラスト素材集｜ちょうどいいイラスト https://tyoudoii-illust.com/
 ◦ Loose Drawing | 無料で商用利用可なフリーイラスト https://loosedrawing.com/
 ◦ shigureni free illust │ 素朴で可愛い、女の子のイラスト素材サイト https://www.shigureni.com/
 ◦ 商用可・フリーイラスト素材｜ソコスト https://soco-st.com/
 ◦ ドット絵ダウンロードサイト DOTOWN|無料の素材サイト https://dotown.maeda-design-room.net/
 ◦ かわいいフリー素材集 いらすとや https://www.irasutoya.com/