Download - 20160128 jjug Nightセミナー_Git実践入門
![Page 1: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/1.jpg)
Git実践入門
JJUGナイトセミナー Git入門 2016-01-25(月)19:00 - 21:00
![Page 2: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/2.jpg)
• しょぼちむ • @syobochim
こんばんわ!
![Page 3: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/3.jpg)
受託開発
お客様は金融系
基盤チームのメンバーとして案件に参入
![Page 4: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/4.jpg)
結論から言うと 少人数チームでGit導入するのはいいけど
大規模でやるためには 本当にちゃんと運用フローを考えて
体制を整えるか ある程度妥協しないと
大惨事になるということ
![Page 5: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/5.jpg)
※あくまでイメージです
![Page 6: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/6.jpg)
今日は私や、私の周りの人が 案件にGitを導入・運用した時の
開発プロセスについて お話ししていきます
![Page 7: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/7.jpg)
まずソースコードを管理するための 基本的な開発スタイルについて
![Page 8: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/8.jpg)
開発スタイル
![Page 9: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/9.jpg)
構成管理サーバ : GitBucket
![Page 10: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/10.jpg)
CI : Jenkins
![Page 11: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/11.jpg)
mavenリポジトリ : artifactory
![Page 12: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/12.jpg)
ちなみに全部無料!
![Page 13: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/13.jpg)
(Redmine以外は)JVMで動く!
![Page 14: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/14.jpg)
今日はここの話をします
![Page 15: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/15.jpg)
ちなみに全体のざっくりした説明は ↓に書いてます
http://syobochim.hatenablog.com/entry/2015/09/03/214050
![Page 16: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/16.jpg)
GitBucket
構成管理用の リポジトリ管理ツール
![Page 17: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/17.jpg)
GitBucketのいいところ
• インストールが簡単 • 無料! • GitHubに似ているから普段GitHubを使っている人には親しみやすい
![Page 18: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/18.jpg)
GitBucketのインストールDEMO
![Page 19: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/19.jpg)
warを直接起動できる!かんたん!
ちなみに環境構築についての ブログ書きました
http://syobochim.hatenablog.com/entry/2015/05/31/232650
![Page 20: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/20.jpg)
https://github.com/gitbucket/gitbucket/wiki/Backup
極たまにデータが飛ぶことがある バックアップを取得しておくことが大事
困ったこと
![Page 21: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/21.jpg)
GitBucketは無償と思えないほど使いやすい! 無償+インストールが簡単なので「とりあえずやってみよう!」の ハードルが低い
ただ、トラブル対応などで 導入・運用のコストはかかってしまうので 可能なら最初から有償ツールを 検討した方がいいかも
![Page 22: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/22.jpg)
プロジェクトの構成とブランチモデルについて
![Page 23: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/23.jpg)
プロジェクト構成やブランチモデルは プロジェクトの体制や要員のスキルに 合わせて一番検討する必要があります
![Page 24: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/24.jpg)
• ケース1 ‣ 小規模で構成管理の大切さを知っている人が各拠点に一人はいる体制
• ケース2 ‣ 小〜中規模でGitを知らない+構成管理について知らない人たちがほとんどを占める体制
• ケース3 ‣ 中〜大規模でGitを知らない+構成管理について知らない人たちがほとんどを占める体制
![Page 25: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/25.jpg)
ケース1
• アプリチーム2つ×基盤チーム1つ
• プロジェクトの体制は小規模(1チーム10人未満)
• アプリチームも基盤チームも主体的に行動している • 基盤チームはアプリ開発への影響を理解している • アプリチームは基盤部品の重要度を理解している
• 必要な基盤部品の提供時期がアプリチームの計画とマッチしている
• 構成管理についてある程度のスキルや知識をもっている人が各チームに一人はいる
![Page 26: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/26.jpg)
プロジェクト構成• チームや拠点ごとにリポジトリが分かれるようにする • 画面・バッチ・基盤ごとにチームや拠点が分かれている • ベースリポジトリとサイトリポジトリに分けている
![Page 27: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/27.jpg)
ベースリポジトリ• ライブラリアンのみmerge / pushする権限がある • リリースしてもいいソースのみを格納する
![Page 28: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/28.jpg)
サイトリポジトリ• 拠点ごとにリポジトリを分けている • 各開発者が直接push / pullする
![Page 29: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/29.jpg)
サイトリポジトリ開発拠点は違うが同じフレームワークを使う場合は
共通用リポジトリから更にリポジトリをforkさせていく
fork
![Page 30: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/30.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
![Page 31: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/31.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
![Page 32: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/32.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
![Page 33: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/33.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
![Page 34: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/34.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
![Page 35: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/35.jpg)
いいところリポジトリごとにpush権限を変更できるので 「あっ!間違えてpushしちゃいました!」 というミスをシステム的に防ぐことが出来て安全
自分たちがどのチームにいて 何を開発しているのかが明確になる
フレームワーク用にリポジトリを分けているので 自分たちの好きなタイミングでフレームワークの変更を 取り込むことができる
拠点間でのビルドの失敗が他の拠点に影響を与えない
他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい
![Page 36: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/36.jpg)
いまいちなところ
運用コストが高い
フレームワークの変更の取り込みタイミングを 各拠点に任せるので 「後でいいや」って思い続けられると死ぬ
![Page 37: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/37.jpg)
ケース3つのまとめケース1
運用コスト ×
フレームワーク変更の取り込む速さ △
フレームワーク変更の取り込みタイミン
グを決められる◯
リリース成果物への権限設定 ◯
レビューしたもののみ成果物に出来る ◯
所感 重厚
![Page 38: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/38.jpg)
ケース2• アプリチーム複数×基盤チーム1つ
• プロジェクトの体制は小〜中規模
• 構成管理についてあまり知識がない人ばかり
![Page 39: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/39.jpg)
プロジェクト構成• 画面・バッチ・基盤ごとにモジュールが分かれている • ブランチ単位で開発拠点やリリース用ソースを分けている
![Page 40: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/40.jpg)
プロジェクト構成• リリース用のブランチを作って、そこからリリース成果物を
作成する • 開発者はリポジトリに対して直接pull / pushをする
![Page 41: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/41.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
![Page 42: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/42.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
![Page 43: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/43.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
![Page 44: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/44.jpg)
ブランチ• 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
![Page 45: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/45.jpg)
いいところ自分たちがどのチームにいて 何を開発しているのかが明確になる
フレームワークの変更をdevelopにmergeするので 素早く変更を反映・取り込むことが出来る
拠点間でのビルドの失敗が他の拠点に影響を与えない
他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい
![Page 46: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/46.jpg)
いまいちなところ
「あっ!間違えてmasterにpushしちゃいました!」 というミスがたまに発生する
フレームワークの変更の受け入れタイミングを アプリ開発者が自発的に決められない (もちろん事前に調整することが前提)
![Page 47: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/47.jpg)
ケース3つのまとめケース1 ケース2
運用コスト × △
フレームワーク変更の取り込む速さ △ ◯
フレームワーク変更の取り込みタイミン
グを決められる◯ ×
リリース成果物への権限設定 ◯ ×
レビューしたもののみ成果物に出来る ◯ ◯
所感 重厚 無難
![Page 48: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/48.jpg)
ケース3• アプリチーム1つ×基盤チーム1つ
• プロジェクトの体制は中〜大規模
• アプリチームは完全にオフショア開発
• 構成管理についてあまり知識がない人ばかり
![Page 49: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/49.jpg)
プロジェクト構成• 画面・バッチ・基盤ごとにモジュールが分かれている
• ブランチ単位でリリース用ソースを分けている
![Page 50: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/50.jpg)
ブランチ• svnと同じdevelopブランチへの直接commit • masterブランチへのマージは受け入れ時にやる • 基盤チームはパターン2と同じブランチのフローで開発
![Page 51: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/51.jpg)
いいところ教育・運用コストがかからない
フレームワークの変更をdevelopにmergeするので 素早く変更を反映・取り込むことが出来る
他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい
(契約によっては開発フローを強制出来ないので 相手のやりやすいように開発してもらう)
![Page 52: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/52.jpg)
いまいちなところ
「あっ!間違えてmasterにpushしちゃいました!」 というミスがたまに発生する
フレームワークの変更の受け入れタイミングを アプリ開発者が自発的に決められない (もちろん事前に調整することが前提)
レビューしていない成果物が リリース対象に入ってしまう可能性がある
![Page 53: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/53.jpg)
ケース3つのまとめケース1 ケース2 ケース3
運用コスト × △ ◯
フレームワーク変更の取り込む速さ △ ◯ ◯
フレームワーク変更の取り込みタイミン
グを決められる◯ × ×
リリース成果物への権限設定 ◯ × ×
レビューしたもののみ成果物に出来る ◯ ◯ ×
所感 重厚 無難 不安
![Page 54: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/54.jpg)
導入・運用してみて思った事
![Page 55: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/55.jpg)
ガイドを用意するとスムーズググったらわかるので皆さん調べてください! ではなく、ガイド化してあげると受け入れられやすい
エンジニアならコマンドくらい使えろ!じゃなく プロジェクトメンバーが使いやすいと思うツールを 選んであげる事が大事
ちなみに、ガイドをGitHubで公開しています
http://syobochim-doc.readthedocs.org/ja/latest/index.html
![Page 56: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/56.jpg)
ややこしいことはさせない
必要最低限な操作しかやらせない
cherry pickやrebaseなどは、 ある程度知見がたまっている、この人なら安心できるなーと思う人に「こういうことも出来ますよ。ただ、こういうところに注意してください」と個人的に教えてあげる方がいいと思う
よくわかってない人がよくわからないまま何かすると死ぬ
![Page 57: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/57.jpg)
ある程度の柔軟性も必要今までのやり方と違うので出来ない!生産性が上がらない!!という人は絶対数いると思う
『こう使うと、こんなメリットがあってね』って説明はしてあげるべきだけど「こうやるんだ!!」って強制すると「うまくいかない!全てGitが悪い!!」って思っちゃう人もいて、自分が疲れちゃうので 「じゃあ、そちらのチームとこちらのチームで使い方変えましょう」くらいの柔軟性も必要
![Page 58: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/58.jpg)
とにかくやってみるとイイ私はGitをお仕事で使ったことなかったし、GitHubもブランチ切ったりしたことなかった でも導入・運用してみたら、辛いこともあったけど なんとかなった
運用についてのドキュメントや相談相手がチーム外にでもいると、より安心して運用できると思う
なお、今日お話ししたケース1の事例詳細はドキュメントにまとめられてる https://www.gitbook.com/book/uga/mastering-builder/details
![Page 59: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/59.jpg)
改善が必要だと思うこと
![Page 60: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/60.jpg)
featureブランチは息短めにする
featureブランチが長生きすると、コンフリクトしたり共通部品をうまく使えなかったりと、めんどうなことが起こりやすくなる
注意喚起はしているけど、実際何週間もfeatureブランチで開発し続けている人がいるので、解決策募集中!!
ちなみに「syobochim/XXX」のようなブランチ名になっていたら息が長くなる兆候なので即刻やめさせる
![Page 61: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/61.jpg)
できれば最初にデモしてあげる
たまに、「えっ?!そんな使い方してたの?!」って人がいるので、最初に実際の開発フローがイメージできるようにデモしてあげればよかったと思う
![Page 62: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/62.jpg)
ちゃんとトレーニングを重ねていく
継続して改善していくためには ちゃんとしたトレーニングが必要
sandboxやhandsonを使って開発者が自由に触れる環境で遊んでもらうことで Gitに慣れてもらう+使い方を知ってもらえればよかった
![Page 63: 20160128 jjug Nightセミナー_Git実践入門](https://reader031.vdocuments.pub/reader031/viewer/2022021918/58a985a41a28ab412d8b504f/html5/thumbnails/63.jpg)
ありがとうございました