appendix_attendjointbook.re

= 付録B:合同誌に参加して

本章では、主に親方Projectの合同誌に参加した皆さんから実体験、感想をコメントしていただきます。

実際に皆さんが書いた内容はそれぞれの本を見ていただくとして、実施書いてみてどうだったかといった観点で読んでみてください。

本章の記載は、2018年の「合同誌を作ろう」執筆時点に基づきます。ご了承ください。

== 「合同誌を作ろう」に参加しました @ichi_taro3

==== 参加した経緯

Developers Summit 2019の「アウトプットのすすめ」というセッションがありました。技術同人誌や勉強会、Podcastなどを通じてアウトプットしている人たちによるとても熱い講演で、私は大いに刺激されました。居ても立ってもいられない気持ちになって、Twitterで「なんかやりたい」とつぶやきました。

何の気なしに発した一言だったのですが、登壇者の親方さんに捕捉されたことで、まさかの合同誌への初参加へと導かれたのでした。

==== 初参加して得たもの

本を書くことが思ったより自分に近い世界のことだと思えたのが大きな収穫です。やったことが無いというのと、やったことがあるという事の間には大きな隔たりがあるように見えるのですが、その境界線をひょいと気軽に乗り越えることができました。

加えて、こういった本がどのように作られているのかやどんなツールがあるのかなどを垣間見ることができました。親方ProjectではRe:VIEWという書籍執筆支援ツールを使っていたのですが、存在自体を初めて知りましたし、githubで原稿を管理するというのも新鮮でした。自分で書いて、自分でビルドして、PDFを眺めてニヤニヤできるってそれだけで楽しかったです。

==== 感想

書いてみませんか？ と声をかけられたときはどうしたらよいかさっぱりだったのですが、やってみれば案外書けるんだなと思いました。

いきなり自分のプロジェクトをもって何十ページも書こうと思うとだいぶハードルが高くなっていたはず。ところが、まずはコラムからということでちょっとだけ書かせてもらって、ついでに本文も一トピック...という風にすこしずつ誘導されたので、それほど気負うこともなく書いていくことができました。

初心者には上手いことおだてられながら書く、というところで心理的安全性が確保されていたのですごい恵まれた環境でしたね。

==== 困ったところ

記事を書いた後のソース管理で少々戸惑いました。勝手にコミットしていいのか、Pull Requestをつくって伺いを立てたほうがいいのか、温度感が分からなかったのです。Slackで一言質問すれば解決したので結果としてそこまで困らなかったのですが、ソース管理のポリシーはどこかにまとめられていると、後から参入した人が迷わなくて済むかもしれません。

個人的なところでいえば、仕事やプライベートなど他のやりたいことをこなしていくと、なかなか執筆にとりかかれなかったのも困りごとでした。とりあえずファイル名を決めるだけ、書きたい内容を箇条書きにするだけ、というように少しずつつでも進めていくのが大切なのだなと思いました。といいながら、この文は締め切り近くであわてて書いているんですが......執筆は計画的にですね。

==== よかったところ

親方さんのプロジェクトはREADMEを読むだけでだいたいわかるようになっていましたし、Slackで相談や質問もできたのでそれほど困ることもありませんでした。参入しやすいように心を配ってもらえるところがとても良かったです。

==== 総じて

自分の考えを文章にするということは、恥ずかしくもありますが快感も伴う楽しいものでした。アウトプットするということは脳内をハッキングするようなものなのかもしれません。

ということで、技術にかかわる人ならぜひアウトプットをしましょう。私はこれから挑戦していきたいと思っています。Happy Hacking!

== この合同誌に参加しました @ひらりん@


==== この合同誌に参加しました

 * Onestop 勉強会（親方Project）

==== 参加のきっかけ
2019年のデブサミの「アウトプットのすすめ」セッションに関するツイートをしていたところ、親方さんをはじめとした登壇者の方々にリプライをもらい、そこから合同誌への寄稿を誘われました。

セッションを聞いたことでアウトプットのよさを改めて感じ、「執筆してみたい！」という気持ちが上がっていたところだったので、そのテンションのまま即決で参加を決めました。

==== 初参加して得たもの

以前より「本を書いてみたい」と漠然と思っていたので、それがあっさり叶ってしまったことが大きいです。執筆はアウトプットの方法としてハードルが高い部類だと勝手に位置付けていたのを、見事に崩していただけたことが大きいです。

Re:VIEW等を使った執筆を実際に体験することができたのもとてもよい経験になりました。

==== 困ったところ

はじめは「締め切りがいつなのか」「テンプレートなどはあるのか」などわからないことも多かったですが、リポジトリ（特にREADME.md）を見ればわかることだったので、取り掛かるまでの疑問はすぐに解消はしました。

書きあがったあとは、その書いた文章をどう提出すればよいのかは迷いました。単純にRe:VIEWに慣れていないせいもありましたが、新規にファイルを作るのか既存のファイルに追記するのかがわからず、また今回は「寄稿」という形での参加だったところ、「寄稿」の場合は提出・追記方法が異なるのかなどわからなかったため、どうしたらよいのか困ってしまいました。

==== よかったところ

深く考えずに参加を決めてしまったものの、少ない量でも参加できる合同誌への寄稿という形式が、執筆が初めてでも参加しやすかったのでよかったです。

困ったところはいくつかあったものの、それらに対応するためにSlackという参加者のオープンな会話の場があり、そこで質問をしたり過去ログを見ることですぐに解消できる状態にあったのはよかったと思います。

CIでその時点での全体像がどうなっているのかをすぐ確認できたのもとてもよかったです。「この本に自分が参加するんだな」というイメージが非常にしやすかったです（はじめのほうで戸惑った部分もこれを見れば一発でイメージできたことも多いのでもっと早く気づければよかったというのはありますが）。

またたとえ締め切りが近くても殺伐とした雰囲気にはならず、参加させていただいたときからよい雰囲気が続いていたことはとてもありがたく思いました。

加えて、今回は湊川あいさんの漫画や表紙絵の作成過程を一部見ることができたのが感動でした。締め切り間際に多数の原稿がマージされ本が急成長していく様も圧巻でした。合同誌では他の方の執筆過程を覗くことができるので、そんな楽しみもあるのだなと思いました。

==== 感想

執筆の過程を見ることができたこと、そしてそこに参加できたことが非常に良かったです。Re:VIEWって便利だなとか、CIは執筆でも大事なんだなとか、執筆を支える技術を学ぶことができたのは大きな収穫です。

チームの雰囲気づくりから執筆環境の整備まで、振り返ってみれば至れり尽くせりなところでしたが、そこに気づくまで少し時間がかかってしまったのが個人的にもったいなかったかなと思いました。

特に自分の書いた文章がどう完成した本の一部になっていくのかは最初に見ておくべきでした。書いたものがどう集まり、どう本になるのかという流れをいかに早くつかめるかで、執筆のスムーズさに大きく差が出ると感じました。

とはいえ、今回はなにより執筆へのハードルが自分の中で下がったことがとても大きいです。これから執筆へも挑戦していきたくなりました。合同誌は執筆への意識を変えてくれるとても良い機会でした。

合同誌は執筆が初めてでも参加しやすく、一緒に参加している他の方の執筆（原稿内容や執筆・編集作業）を見て学べることも多いです。合同誌への参加は非常に楽しく素晴らしい経験になります。ぜひ、たくさんの方にチャレンジしてほしいと思います！

== 首無しキリン@Kill_In_Sun

==== 初参加して得たもの

 * Re:VIEWデビュー
 * 合同誌で本を書いた実績
 * 前職でやってきたことの整理を実体化

==== 感想

 * これでいいの？という感じが強かった記憶しかない・・・笑
 * 逆に言えば「こんなんでもいいんだ！」だった

==== 困ったこと

 * 周りの人は「慣れた人」だったのかもしれないけど、私は勝手がわからないのでどう進めていけばいいかわからなかった。
 * 本の構成上、章ごとに専任で書くスタイルだったので、「この章は私のところ」と、個人のテリトリーみたくなってしまった(本人にその気はないけど)

==== もっとこうしたらスムーズ

 * 合同誌の進め方に関しては、わかっている人たちが引っ張っていくしかない。　わからない人は章を追加してどう取り込まれるのか、どう切り捨てられていくのかイメージが沸かないまま書くことになる。
 * 自分の領域がDOINGなのかDONEなのか、自分以外からはわからないので、そのステータスが分かるようにしたらいいのかもしれない。

 合同誌を書く上での諸々の課題については、この本によって解消されていくでしょう！期待しております！

==== 参加者目線での知見

合間合間で書き進めてはコミットしてマージさせていたので、心の平穏はありました！「本を書いたことない」から一歩踏み出すのはとてもハードルが高い事だと思っていましたが、蓋を広げてみれば、普段私がVisualStudioCodeでブログを書いて投稿しているのと一緒じゃないか！という気付きでした。 ちょっとだけ丁寧なブログを何記事か書けば本が生えるって思うとすごい事だと思いませんか。 
 
締切ギリギリに快く参加を受け入れてくださった親方さん、ありがとうございました。  


 
== みずりゅ@MzRyuKa

==== この合同誌に参加しました

 * Onestop 勉強会（親方Project）
 * エンジニアの成長を応援する本（エンジニアの登壇を応援する会）

==== 初参加して得たもの

 * 一部分とはいえ、自分でも技術同人誌を書けるんだという前向きな気持ち
 * 合同誌でも「技術同人誌の著者」という実績解除！

==== 感想

 * 集合知が集まるとこんなに面白いんだ！
 * 他の人の文章がべた褒めされていると「自分なんて」と萎縮したけど、自分は自分でしかないと思い直すことで気分が楽になって執筆できた。
 * 書けなかった時は苦しかった。でも、書ききった後に振り返ると苦しみも含めて楽しかった！！

==== 困ったこと

 * 意外と他の人の進捗がみえないので、「本当に本は出るのかな？」なんて思っていました。
 * 主催の人が主導しないと、寄稿者は意外と動かない。自分も他の人の寄稿文章をしっかり見ようとは考えませんでした。
 * Re:VIEWの使い方を忘れていたので、他の人を真似ながら書いてドキドキしながらpushしてました。

==== もっとこうしたらスムーズ

 * 休みに時間を一気にとってやるよりも、日々少しずつでもコミットしていく方が気持ちが楽です。
 * 雑でも良いので文章は書ききった方が良いです。その上で、推敲していけば、落とすことは最悪ありません。
 * 締め切りまで待つ必要もなく、ある程度書いたら提出（GitHubを利用しているならプルリク）するようにして「進捗を出している」感を出しましょう。
 * 相互レビュー期間は、期間指定は大事。大体の人は土日といった仕事の休みの日に稼働するので、レビューア／レビューイもそこを意識した方がよい。

==== 参加者目線での知見

 参加時点でのモチベーションは高いものの、 期間が空きすぎると他にやることが出てきて優先順位が下がってしまいます。また、書いてないと「書かなきゃ・・・」とプレッシャーが少しずつかかってくるので、モヤモヤしながら日々を過ごすことになります。なので、申し込んだら優先して時間をとってしまいましょう。一旦書ききってしまうと良いと思います。

 
== かしい@rubys8arks

==== こんな合同誌に参加しました

 * 個人開発がやりたくなる本（#IndieCoderJP）※制作、記事の執筆
 * Onestop 合同誌を作ろう（親方Project）※記事の寄稿

==== 初めて合同誌を作って得たもの

今回、技術合同誌を作ってみて得られたスキルはこんなにあります！

　

@<b>{執筆者として}

 * ライティングスキル

 ブログ記事を書いていて1000~3000文字の文章には慣れていたのですが、寄稿では初めて1万文字を書きました。
 長文でもすっきり読ませる文章力、構成力などが身についたと思います。

　

@<b>{編集者として}

 * 編集・校正スキル（他の寄稿者の文章の修正、アドバイス）
 * コピーライティングスキル（本のタイトルの作成、目次の作成）

 読者がパッと見て手にとってもらえるよう、よりキャッチーでわかりやすいものを作る方法を学びました。

　

@<b>{デザイナーとして}

 * グラフィックデザインスキル

 #IndieCoderJPのサークルカットの作成、本を紹介するブログ記事のアイキャッチ画像の作成、Twitterヘッダーの作成、執筆者紹介画像の作成などを行いました。
 本を手に取ってもらうために、いかに「わかりやすく伝えるか」を考えてデザインする能力が身についたと実感しています。

 * DTPデザインスキル（表紙の作成、アンケート集計結果ページの作成）

 手間がかかりすぎるので結局断念したのですが、グラフの作成用にAdobe Illsustratorを初めて使って勉強になりました。

　

@<b>{広報として}

 * セールスライティングスキル（本の紹介ページの作成）

 買いたい！と思ってもらえるよう、「本を読むことで何が得られるのか」「どんな困りごとを解決できるのか」にフォーカスして書きました。

 * WEBマーケティングスキル（SNSを利用した本の宣伝、いいねやRT・最終的な販売部数を伸ばす方法を考える）

 個人開発者のアカウントをいいねして回ったり、ネット上のインフルエンサーにRTされようとして失敗したりしました。

　

@<b>{アンケート作成・分析者として}

『個人開発がやりたくなる本』では、WEBアンケートを行って個人開発者141名の方から回答をいただきました。

 * 社会調査スキル（アンケートの設問作成や回答を集める方法の立案、Google Formによるアンケート実施）
 * データ加工スキル（Googleスプレッドシートによるアンケートの表記揺れ修正、集計、ワードクラウドの作成）
 * データ分析スキル（データからどんな傾向があるのかを把握）

　

@<b>{合同誌制作チームの一員として}

 * チームマネジメントスキル（プロジェクトにおける進行管理）
 * コミュニケーションスキル（初対面のメンバーとの、オンラインコミュニケーションによる共同作業）
 * タイムマネジメントスキル（本業と同人誌を作る時間のバランス）
 * タスク管理スキル（やるべきことをリストアップし、優先度に応じて取り組むスキル）
 * 技術同人誌の制作スキル（Re:VIEW、Docker、Keynote、Adobe Illustrator、マークダウン記法など）

==== 困ったこと

 * 参加者間のモチベーションの差

 合同誌の参加メンバーの中には、「本が出るだけで嬉しい」と考える人と「本の完成度を高めたい、たくさんの人に届けたい」と考える人がいます。
 メンバー間のモチベーションに差があるので、「相談したい」と思ってもあまり反応がなかったのが悲しかったです。

 * オンラインコミュニケーションのみでプロジェクトを進めること

 Slackは既読がつかないので、読んだ上で反応がないのか、そもそも通知を切っていて見ていないのかよくわからないことに困りました。
 同人誌はあくまで仕事のスキマ時間で作るものなので、寄稿者のタスクは「原稿を完成させること」に絞ってあげるのがよいと学びました。
 最初に「本つくってみませんか？」と声をかけてくれた方が合同誌の作成に参加しなかったため、主催がウヤムヤなままプロジェクトが進んだことがかなり辛かったです。
 
 * 厳しい意見をどう言うべきか

 他の執筆者の書いた記事にどこまで介入すべきかが難しいと感じました。
 本の内容をよくするためには、それまで話したこともない初対面の方に対してアドバイスをしないといけないわけです。
 自分が「読みにくい」と感じた部分を直していったら人の原稿を大幅に変更することになってしまって、「こんなに変更してしまって大丈夫なのか？」と不安になりました。
 また、自分はグループの中で「唯一の女性、年齢も若い、エンジニア経験も浅い」と特に立場も弱かったので、どう振る舞えばチームを動かすことができるのか、とても悩みました。
 普段からエンジニア界隈に対して発信して、「この人はこんな人ですごい」と信頼されていればプロジェクトが進めやすくなるのかなと思います。

 * マークダウン記法

 ブログ記事はマークダウンで書いたことがあったのですが、Qiita、はてな、GitHubなどそれぞれで独自記法がありどれがRe:VIEWでも使えるのかよくわかりませんでした。
 PDFに出力してみないとどう表示されるかわからず、Re:VIEWの設定を担当している編集者の作業を待ってからでないと原稿を修正できなかったのが歯がゆかったです。

 * GitHubによる原稿管理

 マージし忘れやコンフリクトで原稿の修正がうまく反映されていなかったり、見ているブランチが違って編集長と執筆者で認識が食い違うということがありました。
 原稿の特定の部分について議論するときは、ブランチやGitファイルのリンクなどを参照しつつ進めるとよいかと思います。
 また、最新版の原稿が完成原稿に反映されているか、執筆者にチェックしてもらう期間を設けるのが大切だなと思いました。

==== 感想

 「同人誌」というと、まだまだ二次創作のイメージが強くあります。二次創作系合同誌を作るノウハウは知られていても、「技術系合同誌」を作るノウハウはまだまだ知られていません。
自分が合同誌を作る中でも、「技術系合同誌のノウハウがまとまった本があれば…」と思う瞬間が何度もありました。

@<b>{この本を手に取っているあなたはラッキーです！}

今回、自分が本を作っている中で得た学びをこの本に全て込めました。はちゃめちゃに辛いこともありましたが、少しでも自分の体験を役立てていただけたら、それが何よりの喜びです。

== 合同誌寄稿体験 ｺﾊﾞﾗｽｷﾏﾛ@kobarasukimaro

==== 自己紹介
初めまして。ｺﾊﾞﾗｽｷﾏﾛ@kobarasukimaro です。
とある小さな企業（40名弱）でソフトウェアエンジニアをやってます。
フロント〜インフラまで広く浅くやる感じのいわゆる「何でも屋」に近い感じです。
使える言語はJava、PHP、Python、JS、Swift などです。


==== この寄稿について
元々はおやかたさんが執筆されている「ワンストップ勉強会」の寄稿にお誘いいただいて書いていましたが、
「よかったら別の本にも・・・」とさらにお誘いいただいたので書いている次第です。


==== 書くことになった経緯
ワンストップ勉強会の寄稿にもちょっと書きましたが、
デブサミ2019でおやかたさん達が発表されたセッション中に、ツイッターで「技術書典で本出してみたいな〜」みたいなことをつぶやいていたところ、
おやかたさんにお声がけいただいて寄稿するはこびとなりました。
自分としても技術書典出展の第一歩として良いチャンスだと思った為、おやかたさんのお誘いに二つ返事でOKしました。


==== 書いてみての感想
勉強会について寄稿するということでしたが、ちょうど自分が社内LTを企画していたことや
おやかたさんが寄稿についてのテンプレを用意くださっていたおかげでお題について悩むことがなかったのは運がよかったです。

普段あまり文章を書くわけではなく、書いたとしても伝えたいことを上手くまとめるのが苦手なのでとっちからった感があるので
今後の目標に向けて他の人の文章を参考にしたり、文章を組み立てる基礎を学んだ方がいいのではないかと考えています。

書いた内容は自分が主催したLT大会についてでしたが、寄稿するのがわかってた上で運営してみると
客観的な視点で運営出来たかなと思いました。例えば運営しながらでも「ここをこうした方が良さそうだな」みたいな
観察眼を持ってやれたという感じでしょうか。

今回自分が書いたのはほんの1ページ分ぐらいでしたが、
おやかたさんはじめ、技術書典に出展される方や、自分が普段お世話になっている技術書を執筆される方々は、
考えてみると何百ページにも渡る本を書いているんですよね。

そう考えると自分なんかはまだまだ足を踏み入れたばかりですが、今回の経験をもとに、大きなアウトプットの目標として本を出すというところに近づいていければと思います。

==== 参加者目線での知見

今回おやかたさんの合同誌寄稿に参加したので参加者としての感想を書かせていただきます。

やはり文章を書くというのは大変なことだなということを思い知りました。
人に何かを伝えるために文章を書くわけですが、どうやったら伝わりやすいかというのは考えると結構難しいものであります。
同時に自分が何を伝えたいのかというのは意識しないとすぐブレてしまいがちだなと思いました（笑）
これはブログやSNSでも同じことですね。

文章を書く際に1日でまとめて頑張るのではなくて、少しずつ書いていけたら良かったなというのもあります。
書いた資料とか文章は後から見直すと、ほぼどこかしら書き直すものなので、その余裕を持って書ければなというのがありました。

この文章も技術書典で日の目を見ることになるので未来の感想になってしまいますが、
サークル側で参加して本を手に取る方の観察だったりコミュニケーションも経験してみたいところです。
実際に本を手に取る方からのフィードバックが一番の今後の改善ポイントになるのかなという部分があるので、これは是非体験したいです。

つらつらと感想を書いてしまいましたがこの辺りで失礼します。

== またーり生息中@mi_kodayo

==== 自己紹介

仕事はAWS,ADなどのインフラ周りとRoR,Python,Shellなどを使います。趣味は電子工作、自作キーボード、アニメと漫画が大好物のオタクです。2才児を育てています。

==== この合同誌に参加しました

Onestop 勉強会(親方 Project )

==== 参加のきっかけ
技術書典への憧れはありながらも本をひとりで1冊書ききれる自信がなく、@oyakata2438さんの『技術書を書こう！』を眺めつつ技術書典の回数が++されるのを尻目に燻っている日々でした。
できることならサークルを作って複数人で書きたかったのです。しかしコミュ障の自分にとっては人を誘うことは非常にハードルが高いことでした。
そんなある日私に1通のメッセージが。『本書きませんか』という@oyakata2438さんからのお誘いでした。
正直神かと思いました。

==== 初参加して得たもの

 * 技術書展で本を書きたいという憧れが現実になった喜び
 * Re:VIEWなどの執筆環境
 * 次回本出せるんじゃないのという自分への期待

==== 困ったところ
章立てや書式は事前に共有して頂いたので問題なかったです。
あえて言うなら、DMでの提出でOKと親方さんはおっしゃってくださったのですが個人的にはどうしてもRe:VIEW環境を作りたい思いがありました。しかし私のWindowsマシンは古くてDockerが入らず、Dockerを使わずにMSYS2で必要なものをコンパイルしていく方式でトライし相当に時間を溶かしました。最終的にLinuxマシンで作ったら速攻で環境が作れました。心が折れないためにWindowsでDockerが使えない場合はMacおよびLinuxで作ることを強くおすすめします。

==== 良かったところ
 * 合同誌の最高に良い点はプレッシャーが少ないことです。なのに合同誌に参加できたという自信を得ることができます。
 * 環境を作成できたことで大きな一歩が踏めました。

 上記のようにいいことしかありませんでした。その分、取りまとめる方は大変だと思うので本当に感謝しています。
デビューをこちらの合同誌でできたことをとても嬉しく思います。親方さん、皆様、ありがとうございました。

== ふーれむ@ditflame

==== 自己紹介

仕事は受諾開発SE→社内SE→クラウド系SaaSのエンドユーザサポートとかCIをやるSE（の予定）

==== この合同誌に参加しました

技術書同人誌博覧会２パンフ
、ワンストップ見積もり(商業版)
、ワンストップカンファレンス
、ワンストップ生き方
、ワンストップオンライン生活
、ワンストップ目標設定(商業版)
、積み基板を作らないための電子工作入門
、１００コミュニケーション
、ぎぽたる本
、ぼくのアジャイル100本ノック
、この本
、エンジニアのための「カジュアル面談のトリセツ」＠さっぴー川原著

==== 参加のきっかけ

技術書同人誌博覧会の技書博キャラバン＠大阪に参加→技術書同人誌博覧会２パンフに寄稿→その後のおやかた合同誌にほぼほぼフル参加中　綺麗な流れすぎるわ……改めて見ると。

==== 初参加して得たもの

最初に書いたのは技術書同人誌博覧会２パンフへの寄稿だったのですが、
もともとQiitaに書いてた記事をブラッシュアップして出したので、意外に書けるなという感触を得られました。

==== 困ったところ

技術同人誌で、それこそ合同誌だと無限にネタが書ける人は書けてしまうので、書き出すと時間が足りないのが最大の問題。あと妻に冷たい視線で見られる事が増えたが仕方ない……

==== 良かったところ

言い出すと切りがないが３つぐらいに厳選するとこんな感じです

 * 気づいたら増えまくる商業誌執筆実績
 * 技術同人誌のレビューなどもさせてもらえる機会が増えて色々学びが
 * 壁打ちとか相談に乗ってもらえる友人が非常に増えた(大阪在住なので困るケースも多かった)

遠隔地(大阪)からの参加であるため、どうしても個人サークル主としてはやりにくいという事情がありまして、
おやかたさんの合同誌は非常に助かりました。原稿は書けば出るし、本来同人誌における合同誌って出資もして
何部か受け取って売ったりするものでもあるというのは認識していたので……　えっ一切お金出さなくていいの？　みたいな。(昔に同人やってたことはあったのでその感覚だった)
あと、個人的な経緯でやってきたITの芸幅だけは無駄に広いのが幸いし、2019年の技書博キャラバン＠大阪以降、ずっと親方Projectに関わり続けていた事もあって
現在はおやかたさんの所で副編集長っぽいロールもしています。おやかたさんが忙しそうだと私がCI回すみたいな事をしている(笑)

私が個人サークルを持つ事は今後も無いので、これでうまく回っているのです。たぶんね。