kumihan.typ (31625B)
1 #set text(lang: "ja", font: "Noto Sans CJK JP", size: 10pt) 2 #set par(leading: 1.5em) 3 #set heading(numbering: "1.") 4 #show heading: set block(below: 1.5em) 5 #set quote(block: true) 6 #set page(paper: "jis-b5") 7 8 #align(center)[#text(20pt)[組版について]] 9 10 = 組版とは 11 今回，この記事で取り上げようとせん，組版というものは，私の所属するサークルで不定期に出版している"部誌"についてです． 12 この部誌には，部内から寄稿を募り，まとめて部の刊行物として即売会などで頒布をしています． 13 ではなぜ，私がこのような文章を書くことになったかの経緯をご紹介しましょう． 14 15 = 経緯 16 == Pim Notes 2024発案 17 私は島根大学に2024年に入学し，その5月から島根大学ものづくり部Pim(以下Pim)に所属しています． 18 2024年の10月に部誌を作りたいねという話が持ち上がっていましたが，11月になってPimのコミックマーケット105(以下C105)への出店が決まり，そこに合わせて新刊を発行するという運びになりました． 19 Surfaceを使っていた先輩が，首からかけておけたら便利だなと言っていたので，私はPC用の鞄を作ってC105で頒布したのですが，その制作過程を記事にして部誌に寄稿しました． 20 それとは別に私と友人がHackUに出場したときの体験談をまとめた記事もあり，それらの寄稿が決まったのが11/14のことでした． 21 しかしながら，まだ入稿するための形式などが決まっておらずこのあたりが後に地獄へとつながるのです． 22 23 == 脱稿形式の選定 24 過去(2023年)の部誌の脱稿(Pim内では入稿という言葉を使っていたので以下では部誌取りまとめ側へ原稿を渡すことも入稿と表記します)はR Markdown形式で行われていたみたいです． 25 それを選定したA先輩に理由を訊くなどして，部誌の入稿形式の選定を考えました． 26 このとき，相談用のチャンネルをつくり，A先輩に訊くなどしていたのがB先輩です． 27 私と友人がTeXの導入に関して割と前向きだったこともあり，入稿の形式にはLaTeXが採用されました． 28 ちなみにA先輩はB先輩から選定理由を聞かれた際にVCに入ってきて「LaTeXで良いと思います」と言ってましたね． 29 この決定の日が11/15で，その際に予算との兼ね合いも相談して一人あたりのページ数目安が提示されました． 30 TeXに関しては部誌制作取りまとめ側がテンプレートファイルを用意する運びになり，執筆側だった私はそれを待ちつつ，草案や本文を書き進めるため，あらかじめMarkdown形式で下書きを始めていました． 31 翌，11/16にはその時に寄稿予定の人が名乗りを上げるためのスレッドが作成され，記事とその執筆者，ならびにそのレビュワーがつけられました． 32 33 == テンプレートTeXファイル 34 11/19 16:15にB先輩がA先輩にテンプレートTeXファイルの作成を依頼しました．期日は11/21です． 35 これはB先輩が修士論文の関係で忙しかったため，A先輩に業務を投げたような感じです． 36 翌11/20 13:16にB先輩がTeXのclsファイルの作成をOBの方に依頼しました． 37 OBの方に投げたTeXのclsファイルの作成は11/24にB先輩へ渡されて完了しました． 38 そのため，A先輩はこのclsファイルをもとにTeXテンプレートを作成する運びになりました． 39 40 そして12/03にA先輩がTeXテンプレートの作成として切られたチケットを完了にし，GitHubリポジトリにPRを投稿しました． 41 しかしそれはTeXファイルではありませんでした． 42 #quote(attribution: [A先輩])[ 43 Ticket: 44 45 LaTeXのユーザフレンドリーではないエラーと大量の依存関係に嫌気がさしたので、適当にTeXなりMarkdownで提出してもらった物を適当にHTMLにすることにしました。 46 47 最初からHTMLで出してもらってもとても助かりますが… 48 49 テンプレのレビューをお願いします。 50 ] 51 PRの原文(チケットのURLは削除しました)です． 52 clsファイルを作ったOBの方のTeX環境が若干特殊だったみたいな事情はあったみたいですが，B先輩曰く「適応力が足りない」だそうです． 53 普段，不眠なり，首を寝違えてTwitter等で緊急の用事じゃない限り対応できませんみたいなことを仰っているB先輩ですから，A先輩の適応力はとっても低かったのでしょう． 54 55 == #strike[TeX]HTMLテンプレート 56 私のところにもこのテンプレートのレビューが回ってきたので，伏せられてはいたがFワードと意味がちょっと伝わりにくいかなって箇所の修正をレビューしました． 57 さて，問題はですね，B先輩が送ったレビューなのですが 58 #quote(attribution: [B先輩])[ 59 取り急ぎMS Edgeでsample.htmlを開いて描画結果だけ見ました。 60 パッと見て思いついた改善点は以下の3点です。 61 62 - 2枚の画像を横並びに併記する場合もテンプレートファイルにあると良いかなと思います。 63 - 印刷物になることを考慮するともう少し余白が広い方が良いと思います。上端が狭いと圧迫感があります。左右の余白が不十分で印刷綴じと文章が近くなると非常に読みにくくなります。 64 - コラム欄もテンプレートに用意していただけると助かります。 65 ] 66 まあ，こんな感じの#strong[PRコメント]をB先輩がしました． 67 PRコメントってレビューじゃないのでブランチルールからマージできないんですね． 68 ここまでが12/03の話． 69 そして，12/09．余白に関してはどこにどのくらい欲しいか具体的に言われなかったので，A先輩が適当に増やした結果，それを見たB先輩は左右の余白が狭いって言ってました． 70 更にそれにA先輩が応えて修正をcommitしたんですね． 71 翌12/10，B先輩は「より初心者にやさしいテンプレートファイルを作成」というPRをつくりました．意図としては，余白を調整し，文章の例の英語を日本語にした感じです． 72 A先輩は 73 #quote(attribution: [A先輩])[ 74 パッチを保管してマージ後に再度master宛に開くか、直接ブランチを更新してください。 75 ] 76 としてそのPRをclose． 77 B先輩はそれを見てPRを再度Openし，A先輩のPRをしているブランチにcommitしました． 78 更にA先輩ではない私の友人にレビューをリクエストしました． 79 これを見たA先輩は「破壊的に行きます。」とPRにコメントを残しmasterにこのPRをマージし，テンプレートの完成となりました． 80 81 == 入稿期限の話 82 入稿期限に関しては11/14時点では12月初旬という回答がされていました． 83 12/06にはB先輩が未確定情報であるという前置きをしながらも12/14までは対応可能という情報が流れました． 84 私は12/03時点で草案のMarkdownファイルをPRに投稿し，レビューを求めました． 85 ですが割り振られていたレビュワーの方からのレビューは一向に来ず，私は別の2名にレビューをしてもらいました． 86 ちなみに割り振られていたレビュワーはB先輩とHack Uに一緒に出場した友人です． 87 友人もまた，自分の記事やコピー本で忙しそうだったので致し方ない部分はあるかなと思います． 88 私はテンプレートが完成した12/10にそれを適応して記事のPRに追加し，(恐らく最初の)寄稿者になりました． 89 90 ただ，友人は違いました．B先輩から実は12/14という期限はまだ余裕を持ったものであるという情報を知っていたのです． 91 そのため，彼がMarkdown形式で記事を提出したのは12/15のことでした． 92 私はその日にテンプレートのHTMLへ埋め込む作業を手伝った記憶があります． 93 ちなみに他の方々の記事も大抵は12/15にPRされ，マージされています． 94 95 また，私がPRしたときは命名則として80-で始まるように指示があったのですが，12/15の入稿ラッシュの後には，ルートに「author.html」みたいなものがあったりと，結構めちゃくちゃでした． 96 ま，当のB先輩が自分の記事をリポジトリにマージしたのは12/19になってからなんですけどね． 97 ま，12/18にB先輩があとがきとして記事執筆者のコメントを収集する旨を投稿され，それが集まりきったのが12/20の00:33でした． 98 12/20に印刷会社に注文をし，その日のうちにPDFを#strong[入稿]しまして，無事に部誌が完成しましたというお話でした． 99 100 == 壊れたスタイル 101 部誌を開いたらスタイルがぶっ壊れてました． 102 具体的には見出しの後で改行していたり，記事の続きがページの一番上，余白なしに始まっていたりです． 103 完成?したテンプレートに紐づけられていたcssファイルが強制マージの影響でぶっ壊れていて，スタイルが正確じゃなかったんですね． 104 そのcssファイルの修正がなされたのが12/11で，私の記事がマージされた12/10の後でしたので，ほんと，どうなってんでしょうか． 105 そもそも文字のサイズが技術書にしては大きくて，児童書の文字サイズでしたね． 106 Pim Notes 2024を持っている方はわかりますが，本当にめちゃくちゃです． 107 #strike[1000円で頒布されてましたが，金を出して買うクオリティじゃなかった] 108 私の出版デビュー作だったので当時は結構悲しくて，一部もらうのも，中身を読むのも避けてました． 109 HTMLなのは分かるのですが，記事の順番とかどんな風に一つのPDFにするかなど，何も知らされてなかったので，こんなことになっているとは思いもしませんでした． 110 せめて，あとがきを入れたくらいのときに，その時点での出力を出すようにお願いしていれば...... 111 112 == まとめ 113 ということで，Pim Notes 2024で起きた悲しい事例を割と事細かに紹介しました． 114 ちなみにPim Notes 2024のリポジトリは公開されており，closeされたPRでの議論は見ることができます． 115 引用している文言はすべてパブリックリポジトリにあるやり取りなわけです．良ければ御覧ください． 116 件のPRのリンクでも張っておきます． 117 https://github.com/shimane-u-pim/proj-2024-magazine/pull/3 118 119 = 考察 120 上記に示された例の中では，各人に指摘されるべき事項が幾つもあったことは明らかである． 121 以下に具体的な問題点を幾つか挙げる． 122 - 期日までに成されない仕事 123 - 仕事の一部を他に依頼したため，その完成を待つことになった 124 - 相談なしの仕様の変更 125 - 不適切なワードの混入 126 - GitHubのガイドライン違反 127 - 曖昧な改善指示 128 - 曖昧なPRへの指示 129 - PRへのPRの強制マージ 130 - ブランチルールの解除とmasterへの強制マージ 131 - 執筆者間で持っている情報の齟齬がある 132 - 取りまとめた後の状態を執筆者が確認しづらい 133 - 取りまとめ側の権力乱用 134 以上が具体的に挙げられる問題点かと思われる． 135 これらを抽象化してまとめると以下のようになると考えた． 136 1. ルールの不透明さ 137 2. コミュニケーションの量の不足 138 3. コミュニケーションの質の不足 139 4. 役割分担の曖昧さ 140 141 == ある先輩の話 142 私が部誌について思案している話をPimではない先輩にしたところ，その部での部誌発行の際の話について伺った． 143 曰く「執筆は希望者があつまり，word形式で提出された．編集(ここでいう取りまとめ)は名乗り出た一人が行い入稿した」ということだった． 144 145 ここで，Pim Notes 2024の例と比較してみる． 146 問題点1については，word形式というルールのみが決まっていたことになる． 147 集まった段階で編集を名乗り出た一人が入稿を行ったので，期限などはないし，ルールに不透明さはないが監査などもない． 148 問題点2については，そもそもコミュニケーションの必要性がない．ルールの周知さえされていればよかったので，コミュニケーションの量の不足は問題ではない． 149 問題点3についても，2と同様と考える． 150 問題点4については，役割がきちんと分担されていることは明らかである． 151 152 つまり，手っ取り早い策としては，一人が取りまとめを担当し，全権を移譲すればよいということになる． 153 しかしこれは，取りまとめる一人が優秀である必要がある． 154 やろうと思えば，レビューを通していない不適切な文章を含めて入稿することもできてしまう． 155 156 また，規模が大きくなるほど編集者の負担が大きくなるため，この方式を広く導入することは難しいと考えられる． 157 158 なので，これらに変わる技術系同人誌取りまとめに関する方策を検討したい． 159 先に上げた問題点と品質管理を考慮し，方策に必要な要請を以下に示す． 160 1. 執筆側に示すルールを明文化し広報すること 161 2. コミュニケーションなしに全体へ影響する変更ができないこと 162 3. 各人の役割を分担し，責任の分岐をすること 163 4. 品質についてレビューする機構を設け，これをスルーしての出版社への入稿を禁止すること 164 以上を満たす方策が必要なのではないかと考えた． 165 166 == ルール 167 ここで私が提案したい方策を述べる． 168 銘打った通り「ルール」である． 169 ここでいう「ルール」とは編集側から執筆側に提示されるルールのことではなく，合同誌の編集側と執筆側の双方が守るべき規則である． 170 ルールには以下のことが記載されたい． 171 - 行為(掲示・脱入稿・編集等)には行為者以外の承認者を設け，権限を付与すること 172 - 必要な事項は編集側から執筆側全員に掲示され，編集者が執筆者を兼任する際も，掲示されていない情報を使用しないこと 173 - 役割の分担と共に，権限と責任の分岐点を定めること 174 - 申し立てや意見は双方合意を原則とし，やむを得ない場合は権限と責任を有する側が決定すること 175 176 == ツールについて 177 ルール通りの運用について，助力となるツールの存在を周知されたい． 178 大きな軸であるのがGitHubである． 179 適切な権限設定と，ブランチルールを施せば，行為の承認と実行のフローがスムーズになることが期待される． 180 しかし，Pim Notes 2024では，ブランチルールで保護されていないPRのブランチが強制的にマージされるということが起きた． 181 このようなことを防ぐ方法はGitHub上には用意されていない(または難しい)ようである． 182 完全にツールに任せるのではなく，ルールに追記するなどして，適切な運用を探るべきである． 183 184 また，環境ごとにビルド環境が異なる組版システム(ローカルコンパイルのLaTeX)などは，執筆側にとっても編集側にとっても難しい． 185 そのため適宜GitHub Actionsを用いて自動コンパイルを実施するなどの工夫が求められる． 186 187 === 宣伝 188 私が用いているtypstというツールとLaTeXの為の自動コンパイルのリポジトリテンプレートを個人的に作成した． 189 - https://github.com/minerva-jupiter/typst-githubrun-template 190 - https://github.com/minerva-jupiter/latex-template 191 しかし，今年(2025)もB先輩の主導で部誌が作られる様子だし，今度は執筆者がPDFで脱稿するようだ． 192 私の作ったシステムはずっと日の目を見ることはないだろう． 193 そして，必要なルールも定まらないまま，Pim Notesはつくられていくのだろうか． 194 195 = まとめ 196 色々と考察をしたが，結局のところ，仕事でも何をするにもコミュニケーションの問題は起きるようだ． 197 それをどのようなルールやツールで解決していくかという問題は，今後も引き続き検討を重ね，改善を続けたいと思う． 198 この体験談と考察が，読者の皆さんの役に立つことを願います． 199 200 = 追記 201 この記事を寄稿した部誌が2025/12に刊行されました． 202 またここでも大きな教訓があったので，これまでと同じくらいの文量を割いて解説することにします． 203 204 B先輩は後継を育成するために，即売会に良く一緒に言っている友人(ここではC君とします)に裁量を持たせるつもりで，最初から取りまとめ側として様々に相談をしようとしていたみたいです． 205 A先輩とB先輩が相談して決まることも多数ありましたが． 206 典型的だったのは，入稿の作業や印刷業者の選定はすべてB先輩が行ったにも関わらず，A先輩がC君に締め切りを聞いていましたね． 207 勝手に入稿形式を相談とかしてたくせにそういうのはC君に聞くんだって思いました． 208 そもそも今回の入稿形式がJIS B5なのは，A先輩が一太郎で書こうとしたからという説がありまして…… 209 210 == 今回の方式 211 今回は寄稿者がPDFで提出をし，それをB先輩がAdobe Acrobatで結合するというものでした． 212 12/05 18:45にこんな投稿がされました． 213 #quote(attribution: [B先輩])[ 214 ## 部誌への寄稿の概要 215 216 ### 様式の必須要件 217 218 - 用紙サイズは**JIS B5**にしてください。B5と言ってもISOとJISがありますので、お間違えの無いようお気を付けください。 219 - B5サイズで印刷した際に適切な文字サイズを意識してください。 220 - Microsoft Wordで製作する場合は、Word上ではA4で製作し、出力するpdfをJIS B5に縮小してください。 221 222 ### 製作ツール 223 224 - 指定サイズのpdfに変換できれば、どんなツールでも大丈夫です。(例：文章主体であればWord、LaTeX、視覚的な記事ならPowerPointなど） 225 - テンプレートが必要な場合は順次対応いたします。お気軽にご連絡ください。 226 227 ### 提出先 228 229 後ほど用意するGoogle Driveのディレクトリにアップロードしてください。 230 231 ### スケジュール 232 233 - 部誌参加 募集締め切り: 12/5(金)23:59 234 - 進捗チェック日①: 12/7(日)12:00 235 - 進捗チェック日②: 12/10(水)19:00 236 - 締め切り: 12/13(土)23:59 237 ] 238 そして，進捗チェックの第一回目， 239 #quote(attribution: [B先輩])[ 240 ### 進捗チェック 第1回 241 @channel 242 243 今日は第1回の進捗チェックです！ 以下の情報をこのスレッドに返信してください。 244 245 - 記事のタイトル。まだ決まっていない場合は草案や方針を書いてください。 246 - 進捗状況 247 - Gmailアドレス。提出先のGoogle Driveに招待します。 248 ] 249 とのことで，つまり，PDFはGoogle Driveに提出することは決まりました． 250 なぜ，B先輩がGoogle Driveなのか，これまでの経緯を読んでいらっしゃれば，GitHubを管理できなくて諦めたことが想像できるような気がします． 251 252 12/14 15:47にこんなメッセージが 253 #quote(attribution: [取りまとめの友人])[ 254 ## 部誌について 255 @channel 256 📚 部誌に掲載する記事の提出期限は過ぎていますが、まだ提出可能です！ 257 提出がまだの方は、ぜひご対応ください。できるだけ多くの記事を載せたいと思っています。 258 ただし、入稿のタイミングに間に合わなかった場合は掲載できないことがありますので、ご協力お願いします。 259 ] 260 そして，寄稿者が続々とGoogle Driveに現在の版を提出するようになってました． 261 この時点で私は記事は完成していましたが，A先輩やB先輩が居るところにこのような文章を投稿することが憚られたので，このGoogle Driveを経由せずにC君や寄稿者の先輩にレビューを依頼していました． 262 そもそも部でだすやつなので，A/B先輩が気を悪くしそうなところは黒塗りにしました． 263 んで，A先輩からメールでリーガルチェックが飛んできたりはしましたが，なんとか進んでいきました． 264 ちなみにA先輩への返信にて指摘した3項目のうち，修正されたのは1項目だけでした． 265 大学ネット内にあるとはいえ，使っているFWの型番とそのソフトウェア更新が止まっている事を書くことは非常に危険だと思うんですけどね． 266 267 == 締め切り直前にて 268 12/13 23:45に第二回進捗チェックのスレッドにこんな投稿が 269 #quote(attribution: [B先輩])[ 270 報告が遅くなり申し訳ございません。アクシデントで昨日から今日の午前中にかけて体調を崩しており、作業が遅れています。 271 272 今夜中に記事の前半部をアップロードし、明日中に後半部に着手します。 273 間に合わなければ後半をカットし前半部だけで記事になるような構成に変更しています。 274 275 アクシデントとは言え、締め切り策定に関わった側が締め切りに間に合わなくなり申し訳ありません。 276 前半だけでも間に合わせます。 277 ] 278 279 == 締め切り後 280 12/14 15:08には寄稿者のOBの方が記事が書けたのでレビューしてほしい旨の投稿が． 281 これらを受けて 282 #quote(attribution: [C君])[ 283 ## 部誌について 284 @channel 285 📚 部誌に掲載する記事の提出期限は過ぎていますが、まだ提出可能です！ 286 提出がまだの方は、ぜひご対応ください。できるだけ多くの記事を載せたいと思っています。 287 ただし、入稿のタイミングに間に合わなかった場合は掲載できないことがありますので、ご協力お願いします。 288 ] 289 そして，12/15にC君が，進捗チェックでも反応は無かったものの参加の意思を示していた新入生二人にメンションで記事の確認を投稿され，一人は記事が用意できなかった旨を，もう一人は翌12/16に記事をアップロードしたという投稿をしました． 290 12/15のVCにて，期限は過ぎているし，そろそろ入稿しないと早割が効かないところまで来ていたので，さっさと入稿してしまおうみたいな話を私とB先輩とC君でしていたら 291 #quote(attribution: [B先輩])[ 292 後輩に，期限に間に合わなくて寄稿できなかったという思いをさせたくない 293 ] 294 と仰って，入稿日の決定を先送りにしました． 295 そして， 296 12/15 21:30 297 #quote(attribution: [B先輩])[ 298 遅くなってすみません。3ページ目まで文面とレイアウトができたのでアップロードしました。レビューしていただけると助かります。 299 ※ 1ページ目、2ページ目の文面も修正しています。 300 Google Drive URL 301 ] 302 続けて12/17 0:41に 303 #quote(attribution: [B先輩])[ 304 4ページ目（最終ページ）の文面とレイアウトができたのでアップロードしました。レビューしていただけると助かります。 305 306 ※ 3ページ目の文面は修正前です。 307 ] 308 続けて，2:32にこんな投稿が 309 #quote(attribution: [B先輩])[ 310 ## お知らせ 311 312 ### 入稿予定日 313 314 入稿予定日が確定しました！ 12月18日(木)です。 315 本日**12月17日(水)**いっぱいは記事などの作業に充てられます。 316 317 ### あとがき寄稿のお願い 318 319 製本の都合上2ページほど余裕ができました。 320 皆様、よければあとがきを書いていただけると嬉しいです！ 321 322 ### 表紙に使う画像の提出のお願い 323 324 記事に関係のある写真や、Pimの活動の様子を並べて表紙にしようと思います。 325 皆様、画像の共有をお願いします！ 326 ] 327 もしかして，B先輩が自分の記事に余裕を持たせるために後輩を方便に使った？みたいな解釈もできますね． 328 == 遅延の遅延の遅延の...... 329 12/18 12:33 330 #quote(attribution: [B先輩])[ 331 @C君 あとがきの掲載順を決めていただけると助かります :bow_light_skin_tone: 332 目次はこちらで作成してもよろしいでしょうか？ 333 ] 334 入稿の日に，まだ記事の順番は愚か，目次とかも決まっていない...? 335 ちなみに，この時点で奥付，目次，表紙，裏表紙，なにもできてませんでした． 336 表紙はC君が試作で作ったものがありましたが，決定というわけではまったくなかったです． 337 まあ，B先輩が12/18 10:13に自分の記事の修正版をアップロードしたみたいな話をしていたので，圧倒的に作業が遅延していることが伺えますね． 338 15:53にC君が記事の掲載順を決めてチャンネルに報告しました． 339 17:40にB先輩が，自分の記事は見開き想定だから，そうなっているかを確認してほしい旨を決定した掲載順に対して返信しました．． 340 その4分後に 341 #quote(attribution: [B先輩])[ 342 @C君 今夜20時以降、目次、あとがき、奥付をチェックし、必要に応じて手を加えたのち入稿します。 343 ] 344 と投稿しました． 345 その時点で，C君と寄稿者の先輩が主体となって決定していなかった部分についてデザインを詰めていたので，それがGoogleDriveにある旨を即座に返信しました． 346 20:38にB先輩から詰めていた分についてについて返信がありました． 347 #quote(attribution: [B先輩])[ 348 - 表紙はこちらでロゴを作成するので、後ほど相談させてください。 349 - 裏表紙めちゃくちゃ好きです 350 - 目次の上にPimと今回の部誌それぞれを軽く紹介する紹介文が欲しいところです。 351 - 奥付のページに余裕があります。部誌バックナンバー3冊の情報を載せませんか？ 352 ] 353 詰めてた人らからすると，ほんとこんな段階になって何を言ってくるんだって話です． 354 流石に業を煮やした寄稿者の先輩が 355 #quote(attribution: [寄稿者の先輩])[ 356 @channel 357 表紙・本文問わず，部誌内容と部誌編集についてなにか要望があれば巻き取りますので，本日23時JSTまでに具体的にお願いします． 358 1秒でも過ぎたものは私に起因するミスを除き対応しませんので，心残りがある方は今のうちにどうぞ… 359 （あまりにも高度なことには対応できかねます） 360 ] 361 と投稿． 362 これを受けて? 363 #quote(attribution: [B先輩])[ 364 では変更予定に優先度を付けます 365 366 - 必須：表紙のタイトルロゴ 367 - 推奨：目次の上の紹介文 368 - 編集時間が無ければ割愛：バックナンバーの情報 369 ] 370 これに対して 371 #quote(attribution: [寄稿者の先輩])[ 372 申し訳ないですがこちらで時間を決めさせていただきます 373 ロゴは22:15まで 374 紹介文はどなたが考えるにしても22:30まで 375 バックナンバーの情報も22:30まで 376 ] 377 とうのやり取りがあり，最終的に 378 #quote(attribution: [B先輩])[ 379 了解です。今すぐ対応します。 380 ] 381 意味がわからん．入稿って決めた日に今すぐ対応じゃないってどういうこった．(博士課程で忙しいのか知らんが) 382 私とC君と寄稿者の先輩で，ありそうだったタスクを分割して，必要そうなアセットをA先輩からもらったりしてました． 383 私はC君と機構者の先輩と作業を円滑にするために，私の個人のDiscordサーバーでVCをしていたのですが，そこにA先輩とB先輩が入ってきて，右往左往しました． 384 やっとこさB先輩から前回と同じロゴが表紙に挿入され，できたかなと思ったのですが． 385 私は表紙のロゴのフォントが気になりました． 386 それは単純に再現性の問題ですが，AIに画像を読み込ませてもあんまりだったのでA先輩に聞いてみたんです． 387 そしたら，数分して，A先輩が該当するフォントを見つけてきたんです．それはAdobeCCに収録されている(Adobeが作ったわけではない)フォントでした． 388 私，Adobeに金を払っていないので，表紙の再現できないじゃないですかってなって結構焦りました． 389 まあ，私はあのPim Notesのロゴはダサいと思ってるので受け継ぎたくなかったんですけどね． 390 問題は，有料サービスの中のフォントってことです．要するに，ライセンスの形態によっては別途使用料金がかかるということです． 391 色々調べて，英語のドキュメントを読んで，デジタルで頒布する画像に含んでいるようなのでなければ，AdobeCCからの利用で良いみたいなライセンスだったので良かったのですが，前作をBoothでデジタル販売していたら利用料(1万円近く)がかかっていたかもしれないと思うと，非常に怖いです． 392 ちなみにB先輩は私のVCに来た後，部の作業だからということで部のVCに移り，そこに寄稿もしてくださったOBの方が来て，しばしガンプラの話をしていたような形跡がありましたね． 393 今すぐ対応しますって何だったんだろう...... 394 B先輩が表紙のロゴの適応先を間違えていたり，あとがきで書いた名前を本人が変更を希望したとかでの変更が22:45にB先輩から連絡が来たりとかしました． 395 最終的には23:30に最終盤がGoogleDriveに揃えられました． 396 日付変更してからもB先輩が悠長にVCをしてたので，聞いたら，すでに入稿したとのこと． 397 そして12/19 0:17 398 #quote(attribution: [B先輩])[ 399 @channel すみません言い忘れてました！日付変更直前に入稿しました！ 400 明日チェックと決済が済んだらOKです！ 401 ] 402 恐ろしく仕事はほったらかすし，報告してほしいなって思いました．