土壌の基礎知識 第一章 を読んだ
- 作者: 藤原俊六郎
- 出版社/メーカー: 農山漁村文化協会
- 発売日: 2013/02
- メディア: 単行本
- この商品を含むブログを見る
特にこれを選んだ理由も知識もない。私が世話してる畑なんて、畳３枚分ぐらいしかない。
ここ半年ぐらいであった生産者の方々は以下のような方が多かった。
- 畑をキレイに保って、石灰や肥料等で土のバランスを整える人
- 自然農法（？）で、雑草や土は比較的自然なままにしている人
1 の人たちは「肥料をやらないから作物が病気になる」といい、2 の人たちは「自然じゃないものをやるから作物が病気になる」という。正直良くわからないけれど、どちらの人も自分たちが正しいと思っているから、結構強く言われたりすることもある訳です。
実際自分が本格的に農業をするかどうかはさておき、ちゃんと土について理解して、見聞きする事を少しぐらいは理解したいなと思い読んでみる事にしました。
第一章 土と土壌
考えた事も無いが、「土」と「土壌」は異なるものらしい。
「土」となると、単に岩石が風化したようなものも土と呼べる。よって、月面上にも土があると言えるらしい。
一方で「土壌」となると、生物によって作られ、生物の生育を支える事ができるというものになるらしい。
土と土壌のライフサイクル
これは結構驚きで、土・土壌のそれぞれにライフサイクルがある。
土は前述の通りで岩石が風化したり削られてできる。その前に岩石自体はマグマが地表で冷えてできたり、火山噴火したものが堆積してできたりするらしい。また、地震等で地殻変動し、隆起してくるケースもある。
地表に現れた岩石は崩落や雨水で削られたりで「土」になる。土はその後、雨や風で流されて低地に蓄積して後述するが「土壌」に変化する。
さらにその土壌もいずれ流亡したり老化し、再び堆積し岩石となって土ではなくなる。この周期が実に数百万年から数億年周期で起こっているらしい。なんというか途方も無い。。
土壌は土のなかに微生物が活動してくる事で植物生育に適する環境に変化していくことで土壌化していくようです。
土壌はそこに生育する植物や微生物によって、徐々に肥沃になっていくものの、数千年単位でその肥沃度は低下し老化していくらしい。
老化と一口にいっても、土壌の階層化、上層のミネラルの溶脱、鉄やアルミニウムの下層での蓄積と成分レベルでの変化のことを指すようです。
興味深かったのは、農耕地は化学肥料の施用で土壌が酸性化することで土地の荒廃が進みやすいとのこと。
酸性化すると、アルミニウムが活性化して作物の根の生育を害するとか、リン酸を作物に吸収されない形で固定化するとか、難しい事も書いてあった。。徐々に理解していきたい。
感想
自然土壌と畑や水田の土壌での土壌の変化は、「連作はダメ」とか「石灰をまいて中性にしないと」といった事の理解に繋がった。
「農業機械踏圧での土に耕盤が作られる」とか何言ってるのか分からないが、土壌は実に多くの要因で成立していて難しいという事がわかった。。先は長いぽいです。。
FabLife 対談1 と 2章の②まで
対談1
一章の内容以上にファブラボのコミュニティの側面が伝わってくる。アムステルダムでの世界ファブラボ会議での、いきなりレシピと材料を渡されてみんなでディナーを作る様子やコンペでボートを作ったり、なんでもありの会議の様子はすごく楽しそう。
その他だと、
- 世界のファブラボのネットワークの繋がりの重要性
- ファブラボは個性があるが、振り返ってみると運営している人の顔や人柄が思い出される
- ファブラボは、個性、自発性、多様性に支えられたネットワークであることが魅力
とかが気になりました。
スペースや道具、直接の知識の共有は１つのファブラボでできるけど、それだけじゃなくて、世界中のファブラボと共有できる仕組みを思案しているらしい。
会社という組織にいても暗黙知だらけになるのに、世界の会ったことも無い人達との情報の共有に情熱を燃やせる事はすごいなーとか。もしかすると、ある程度距離感があった方がちゃんと共有とかするんだろうかとかリモートワーカーは思ったりする。
２章①②
MIT のなんでも作れるようになる授業は前から知っていて詳細知りたいなーと思ってたので読めて嬉しい。
- 30 名のスキルも人種も年齢も違う人が集められ
- とにかく How （どう作るか）を叩きこまれ
- アイデアが新鮮なうちにとことん作らされる
ラピッドプロトタイピング
本には IDEO の例も乗っているが、最近は何かを作るにしても LEAN がなんだ、仮説検証のサイクルがなんだ、学びがなんだ、ピボットがなんだと、なんかちょっと個人的についていけてない。たぶん、（スタートアップにしろ違うにしろQCD を考える）経営者としての観点では、理にかなっているんだろうけど、個人的に性に合わない感じがずっとあったりした。
なんとなく、面白い事を思いついたら週末で荒くても全部作ってしまいたいのが昔からの性分なのだと思う。（だからコード汚いのだと思う）
アイデアが新鮮な間に、その期待感とともに「もの」に外化できることが重要だ というのは、すごくいいなーと感じた。
もちろんお仕事でもスパイクして見積もってーみたいなプロセスを踏む事もあるから似てるかもだけど、まあ、それが自分にとって期待感のあるアイデアかどうかだけみたいなものか。
でも最近ホント、わーと作る力が衰えてきて辛い。本にも書いてあるけどただただ勉強不足なのだ。
/dumped
FabLife 一章だけ読んだ
最後まで読んでからと思うと、だいたい時間空きすぎて忘れてるのでとりあえず一章で。。
一章はファブラボの歴史みたいなものと、世界各地のファブラボやそこでどういう事が行われているかが説明されています。
私のファブラボのイメージは、書籍にも出てきますが、鎌倉や渋谷にあるファブラボのイメージで（最近だと秋葉原の DMM のもそう呼べるのかな？）コワーキングスペースの延長みたいなもんかと思ってました。
でも、読んでみると全然違って、工房であり、学校であり、カルチャーセンターであり、遊び場でもある、そんな感じでした。ソフトウェアの話に置き換えるとハッカソンを年中やってるスペースがあるような感覚なんだろうか？
Make 系のイベントや場は（まだ東京に居た頃の） 2 年前の MAKER Fair Tokyo に行ったことしか無くて、あれはカンファレンスな感じだったので、たぶん全然空気感みたいなものを分かっていなかったんだと思うけど、それでも、そこで話している人や聞いている人もすごく楽しそうで羨ましさを感じたのを覚えている。（もちろん、ソフトウェア業界がそうではないとかではないけど、なんとなくです）
残ったキーワード
パーソナル・ファブリケーションとは、大量生産に向かう前の時代の精神を現代の眼でとらえ返し、いまの技術環境の上にアップデートしていくことでもあるのだ。この技術がときに「新しいようで懐かしい」といわれる理由は、おそらくそこにあるのだろう。過去を捨てて未来へ突き進んでいくのではなく、過去を未来へ繋げる手段なのだ
なんとなく「ラダック 懐かしい未来」を思い出した。
僕は山村に住んでいても、テクノロジーに頼って生きているし、ヒッピーのような生活がしたい訳でもない。それでも、手作りのものが好きだし、テクノロジーも自分たちに寄り添ってくれるレベルのものでなんとかできないかと思ったりする。 そういう事をいうと、「前時代的」「技術者なのに何を言ってるんだ」と言われそうだけども、少なくともパーソナル・ファブリケーションは技術を自分たちに取り戻そうとしている点ですごく共感できる。（とはいえ、MIT Media Lab でやっているような、未来ぽい取り組みはすごく好きなので激しく矛盾はしておりますが。）
「世界の周縁の人こそ、先端技術を真に必要としているのだ」（ニール・ガーシェンフェルド教授）
一昨年まで東京に住んでいて、今も東京と山村を行き来していたり、東京の仕事をしていたり、テクノロジーのニュースを見ていると、東京にコレ以上何が必要なんだろうと思うことがあったりなかったり。
とまあ、都会は都会ゆえに不便になる部分があったり、生活が過密になったりするので、そこを解消したり効率化したりというのはあるのは分かるので必要は必要なんだと思います。（実際、私も住んでてそう思いましたし）
私の住んでる山村なんて世界の周縁とは言えないですが、少なくとも日本の周縁ではあると思う。田舎はホント良くも悪くもいろんな前提が通じなくて、驚く程に 人 が有効に機能している。（逆に人が機能しないところは、かなり辛い）
また、いろんなものがコンパクトであるがゆえに、大型の機械や自動化がされていない部分がたくさんある。（人でやった方がコストが安いから） 加えて、土地によって条件が異なるため、カスタマイズ無しにしては辛いものがあったりする。
たまに地方の課題解決系のハッカソンみたいのを見かける。素晴らしい取り組みだと思うし、現地の人の話まで聞いて出てくるソリューションは有用なものになるかもしれないと思う。 ただ、最終的には、ファブラボのようなものが地域に根付き、高度にローカライズされて、最終的にはパーソナライズされる事で、役立つものが仕上がるのではないかと思ったりする。（そんな事はないかもしれない）
そして、そういう場所で利用されるのは実は東京から遅れたものではなく、先端技術なのではないかというのは、なんとなく感じる。
「ファブラボのクリエイティブな雰囲気をつくるのにいちばん大事なのは、いい音楽（Good Music）とおいしい料理（Free Food）だよ」（ファブラボ・アムステルダム アレックス）
まあ、均一に机が並べられたオフィスではないってことだけは分かる。
とは別に、ポートランドに旅行に行った時も、いろいろお店回ったり、現地のガイドの人にスタートアップの話を聞いて思ったのも似たようなことだった。（ポートランドはビールだったけど）
なんか自分も、せっかく山村の一戸建てをオフィスにして働いてるんだから、いい音楽と美味い飯の中で仕事すれば、もすこし楽しめるかなと思ったりした。（クリエイティビティが求められる仕事ではないけど。）
/dumped
Yosemite にした後に出た Ruby と Homebrew の問題の対処
たぶん Yosemite だけじゃなくて、他のセキュリティアップデートとかも絡んでたり自分のやり方の問題もあったと思う。
bundler が動かない
Ruby は 2.1.2 を rbenv 経由で使っていたのですが、急に Symbol not found: _SSLv2_client_method (LoadError) を含むエラーが出るようになりました。
事象、解決策ともに以下と同様で、インストールしなおしたら大丈夫でした。
ついでに恒例の therubyracer でハマる。。
なんか以前もこのサイトにお世話になった気がします。
置き換えまでしなくても、一時的に参照する先を変える方法も見たよという同僚情報があったことも付け加えておきます。
Homebrew が動かない
明らかに何の関係も無い気がしますが、なぜかついでに brew update で失敗してgit の変更が残ってる的なメッセージで絶望感を与えてくれました。
とりあえず、brew のディレクトリに移動して、変更を無しにしようとし git stash とか打ってみたら権限無いと怒られる始末。。
brew doctor 大事。。
結局は以下で大丈夫でした。
$ cd `brew --prefix` $ sudo chgrp staff . $ sudo chmod 775 . $ git fetch origin $ git reset origin/master --hard # 上記の git の操作は git stash && git clean -f でもいいのかも
ぶつかった問題の記録を残してくれている先人に今日も感謝です。
Homebrew と dotfiles 周りの設定見直し
滅多にやらないのだけど、いつぞやから brew bundle がなくなっていたのをついにスルーできなくなってしまったので。（仕方ないから brewfile 使ってるのに普通に brew install するというダメさ。）
Brew-file
前準備
- brewfile から
|| trueの記述をざくっと取り除く。開いたのが Vim だったので:%s/|| true//gとかした。 - brewfile から
tap homebrew/versions || trueの記述を取り除く。なんで入ってたのかは覚えていない。 - dotfiles を管理するリポジトリに既存の brewfile を追加する。ちゃんと push しておこう。
Brew-file を使うようにする
$ brew install rcmdnk/file/brew-file $ brew file set_repo -R dany1468/dotfiles # https の URI 入れたら結局 <user>/<repo> で聞き直されたので、最初からこれでいい気がする $ brew file edit # 既存の brewfile が開く $ brew file push # これで Github のリポジトリに push 完了
この後は、新しく brew install hogehoge した後に brew file update するか、直接 brew file brew install hogehoge していくのかと思う。
既存の brewfile が無い場合は brew file init してから使いはじめるのかな。もろもろ参考リンク参照で。
homesick
dotfiles の運用は前から homesick 使ってたのだけど、いつからかコマンド忘れてちゃんと更新しなくなってたので改めて。
場所
$ ~/.homesick/repos/dotfiles/ $ ls home brewfile $ homesick cd dotfiles # これでも移動できる
dotfiles はそういう名前のリポジトリだから。homesick 的には CASTLE と呼ばれます。
直接編集したい場合は homesick edit dotfiles でも大丈夫。（$EDITOR の設定が必要）
変更する、追加する
$ homesick diff # 変更してたら変更点が見えるよ $ homosick track 変更したファイル dotfiles # 最後は CASTLE 名 $ homesick commit $ homesick push
track で git add、commit, push はそのまま git commit, push が行われているイメージ。
他にも機能ありそうだけど、とりあえず直近困らないここまでで。
強いチームの作り方（WEB+DB PRESS vol 83）を読んだ
都会に居ると、少々感度が低くても、本屋に行くと技術書も自然と目に入るのですぐ買えたのですが、田舎に来ると本屋がそもそも無いので WEB+DB も、もう次の号が出そうという所でギリギリ買えた。。
ここ数年こういう内容の興味をなくしていたので、知らないプラクティスがたくさんあって面白かった。
ざっくりメモ
- 強いチームの違い
- 状況を把握する
- 対応策を検討する
- 必要な能力を身につける
- 繰り返す
- 強いチームは環境変化に対応し続けられる多様性を持つ
- チームが負っている責任は「説明」と「改善」
- 自分たちが従うルールは自分たちで決めて、守り、状況を改善する
- 拳から５本指
- チームメンバーの育成もチームで
- 失敗ワークショップ
- 多能工星取表
- チームのマネージャーの役割の変化
- 権限の移譲レベル
- チームのコミュニケーション
- コミュニケーションの基本モデル
- 同期型と非同期型の使い分け
- それぞれのコミュニケーションのやり方（会議・メール・チャット・ドキュメント共有・チーム外）
- チームの評価
- 評価の方法
- フィードバックの方法
特に気になったこと
拳から５本指
チームも人数増えてくると、どうしても社歴や職歴に幅が出てきますし、発言もぐいぐい来る人とそうでない人がいます。個人的には、全員がぐいぐい発言するようになる必要は無いと思いますし、マイノリティの意見は小さくなってしまうという傾向もあると思います。
意思表示として Yes/No しか無いと、消極的な人やマイノリティは（ある意味面倒くさくなって）Yes とあげてしまうかもしれません。
拳から５本指はそういう時にプランニングポーカー的に意思表示できていいなーと思いました。
まあ、それでも声の大きい人が仕切ってしまうと結果は同じになってしまうかもしれませんが。
どういう意思表示ができるかで、今話し合ってる課題に対する理解度なんかも分かっていいんじゃないかなーと。つい、よく分からないけど Yes って言っちゃう事あるじゃないですか。（お前の仕事への姿勢が悪いって言われそうですが、実際みんながみんな遠慮無く発言できる訳じゃないと思うんですよね。）
多能工星取表
リーダーの人とかは、なんとなく「この人はこういうの得意そう」ってのを知っているんですが、それでもなんとなくだったりすると思います。意外に「最近入ったこの人ってどういう事が得意なんだろう」って話し合わない気がします。（なんでだろ？プライバシーと思われたりするのか？）
タスクの割り振りや、誰に質問すればいいか、どういうペアでアサインすればいいかももちろんですが、本にもあるようにスキル育成の意味でも星取表ってゲームぽくていいなーと思います。（coderwall のバッヂみたいで楽しい）
なんか会社に居ると「学びたい」って発言しにくくなるのなんでしょうね。結局学びたいことは、そういう人を新しく雇用される事でそのポジションは埋まっていったりするんですよね。
I message
私は初めてこのワードに出会いました。コーチングとかで使う用語なんですかね？「YouメッセージとIメッセージとWeメッセージ」みたいに説明されている記事が見つかりました。
自分を振り返ると、無意識ですが、IメッセージとYouメッセージの両方を使っているなと思います。
主語を「私」にするというのはすごい大事だなと思います。コードレビューのコメントとかのテキストコミュニケーションだとそれに加えて、ちゃんと良い反応が返ってくる書き方をするべきだなーと考えさせられました。
例えば、「理由をちゃんと述べる」とか、「相手の意見を促す」とかですかね。 「それは違うんじゃないですか」と書かれても、相手は「違う」の意図も分かりませんし、何を考えていいかも分からない。「私は似たクラスのこの書き方に合わせた方がいいと思いますが、どう思いますか？」だと理由もわかるし、それに対する反応もちゃんと書ける気がします。
まあ、チームのテンションとかレベル感にもよると思いますが、個人的には「相手がどう感じるか」みたいなのは大事にしたいなーと思いました。
えてしてそういうのは「冗長」「簡潔に書いて」と注意されたりするんですけどね。。まあ、それもチームのルールとして決める事なんでしょうね。
評価の項目
評価に関しては、個人的に課題感ある部分です。ピアレビューの話しとかはよく聞いたりしますが、なかなか社風もありますし、技術者に対する評価やフィードバックをどう考えてるかとかもあるので、導入は難しいんだろうなーと。。
個人の評価を行うのは個人のパフォーマンスの改善のためでもある と本にも書かれていましたが、給与査定というよりも、そういう視点が必要だなぁと感じました。（まあ、それは別にやれよという事かもしれませんが）
最近だと ペパポ さんの評価制度に関する記事をよく見ますが、いろいろ考えられているなぁと感心します。
よりよい評価結果というアウトプットを、評価者と被評価者との協働でつくり上げる というのは、かなりグッと来るフレーズです。
- ペパボのエンジニア評価制度を、社内の一般エンジニアはどうみているのか？
- ペパボの2014年上半期エンジニア評価について
- ペパボのエンジニア評価制度をパワーアップした
- エンジニア評価のしくみをイイ感じにいじりましたであります
/dumped
四国の山奥で Ruby のイベントを開いてみた IN 神山
ホントは Github pages の方に書いたほうがいいんだろうけど、そこで手が止まるのが２週間続いたのでこっちに書く！
イベントページはこちら 神山.rb 第一回 - Doorkeeper
レポート
神山.rb の「神山」は徳島県のとある山村である神山町を指しています。なんか渋谷区にも神山町があるのでお間違えなきようお願い致します。
当日は当日飛び入りで来てくださった方も含めると私含めて 19 名の参加者となりました。最初は割りと登壇者と仕事仲間だけになるかと思ってましたが、たくさん集まっていただき本当に感謝です！！
神山コワーキングスペース名物のこたつも使わせていただきました。当日は薪ストーブは付けていなかったので、実は室内結構寒く、皆外にいるような格好でしたｗ
ではセッションレポートなど。
セッション1
神山.rb を開催しようと思うにあたり、真っ先に着手したのが、懸田さんに来ていただく了解を取り付ける事でした。先日の Agile Japan 四国・徳島サテライトで神山町に来てくださったご縁もあったのですが、今の仕事仲間の元同僚であったり、愛媛や四国に対する思いをお聞きする中でも、是非お願いしたいという思いが強くありました。
ちょうど XP祭りでの講演の直後であったこともあり、その再演という形で引き受けていただき本当に感謝です。
第一回 神山.rbでXP祭り2014のXP白本話をする意味とは？
上記の懸田さんのレポートがすでに上がっていますが、ちょうど私自身ここ神山に来て感じていたこと、悩んでいたことにリンクする内容で、本当に聴くことができて良かったです。（と書いておきながら録画できておらず、すみません）
セッション2, 3, 4
株式会社永和システムマネジメントから、3 名の方にセッションを持っていただきました。今一緒にお仕事をさせてもらっているというご縁ではあるのですが、こうやって神山まではるばる来てお話していただき本当にありがたい限りです。
「プロジェクトで重要なことはだいたいSHIR○BAK○で学んだ(仮)」鍛治舎 浩さん (株式会社永和システムマネジメント)
タイトルと写真が謎な感じになってますが、最初に SHIROBAKO の動画を流して DCI の真面目な話しにもっていくという超展開になっておりましたｗ メインは最近作ったという Ruby 向けの DCI ライブラリの作成経緯や実際使ってどうだったかという事をお話いただきました。
「神山ラボ開発日誌」千葉 啓介さん (@chibamem) (株式会社永和システムマネジメント)
自身のこれまでの Ruby, Rails プロジェクトの経緯を前段にお話していただいた上で、途中からフリー質問コーナーに持っていくという、こちらも超展開になりましたｗ
千葉さんが Java と Ruby on Rails プロジェクトを行ったり来たりしているという経緯の中から Java 等から入った開発者であっても Rails Tutorial から始めて、まずは Java ぽくなってしまっても、少しずつ Rails ぽく書けるようになっていくのが大事という事でした。
Rails の熟練者が居ないプロジェクトにおいては、とにかく動くものを書き始めようとせずに、まずは Rails Tutorial 等の既存の有用なサンプルから学習し始めるのが良いのかなーと思ったりしました。
「読みやすいエンドツーエンドテストが書きたい！」田垣 亜季さん (@akiinyo) (株式会社永和システムマネジメント)
エンドツーエンドというか feature spec の話しという事だったようですが、思い当たる話しが多すぎていろいろ見なおしたくなりました。。なんとなくアサートとかすごいしてる気がする。。読みにくいですよね。心を改めます。
そして、チャットモンチーがこういう活動もしてるの知らなかった。。（最近聴かなくなってしまったなぁ）
LT
なんと、当日までエントリが３人しか無かったのに、結果 8 人の LT になって結構盛り上がりました！（ホントよかったーっとほっとしました。）
Ruby の AI ライブラリを使うお話。皆にただよう「これ、絶対デモの途中で終わる」感が的中し、いい感じにドラで中断させられましたｗ
新卒が半年間 Ruby を学んだお話。彼が半年でどういう勉強をして、何を学んだのかがよく分かります。スライド共有されないかな。
iOS & Android エンジニアが Ruby でスマホアプリのテストをするお話。デモまできっちりやりきってさすがでした。tokushima.rb でも発表されているようですので、そちらでも聞けるかも？？
懸田さんが再登場。こちらも先日のポートランド勉強会の再演となりました。が、当然 5 分で終わるはずもなく。。これはまたじっくりお聞きしたい内容です！
複数のマイクロサービスが連携して動作するシステムの場合の運用戦略についてのお話。１つの例として、EC2 インスタンス１つに全てのサービスをデプロイし、それを VirtualHost でポートを変えて運用する例が紹介されました。利点としては、スケールアウトしている場合にも、何も考えずに全サービスをデプロイしたインスタンスを追加すればいいので楽なのだそうです。
こちらは私の妻の発表なのですが、神山に移住してきて一年の振り返りとなりました。「移住者」としてのリアルの内容だと思いますので、移住を考えている方の奥様に読んでいただきたい内容です。
こちら私の発表なのですが、当初はセッション5 にしようと思っていた内容でしたので、即効でドラ鳴らされて終わりました。。Spending.jp のチュートリアル的な内容でした。
最後は tokushima.rb の ka さんが締めてくれました。間違いなく一番 Ruby イベントぽい発表内容で、さすがの一言でした。
実は、予定が重なり一度も tokushima.rb には参加できていないので、近いうちに必ず参加したいと思います。
場外レポート
発表者の横に鎮座していたお花は、本企画の裏プロデューサーである @koic から贈っていただいたものです。お花を贈っていただけると DM いただいた時は感動のあまり固まりました。
神山.rb は開催自体は 9 月後半ぐらいにノリで決めて、後はバタバタと調整していったのですが、構想自体は年明けぐらいに東京の飲み屋で koic がぶち上げたもので、「これはいずれやらないと＞＜」と心に誓っていたものの、ズルズルと遅くなりつつもなんとか実現できて本当に良かったです。懸田さんとのご縁も作っていただいたので、ホントにプロデューサーでした。
当日振る舞ったかぼちゃのケーキです。妻が朝からせっせと作ったものですが、せっかく皆さん山奥まで来てくれたので、何か美味しいものでも振る舞わないとなーという願いが叶って良かったです。妻には感謝感謝です。
ホントは愛媛のゆるふわ.rb のような地元の素敵なものが振る舞えたら良かったのですが、、、準備不足でした。。
神山.rb 第一回のまとめ #kamiyamarb - Togetterまとめ
安定の 鎌玉大様 の togetter まとめをいただきました。大大大感謝です＞＜
神山でイベントを開くということ
一部では神山町は「なんか盛り上がってるらしい田舎」みたいな見方もあるかもしれませんが、現実はやはり主要駅からは遠く、車が無いととてもこられない場所にあります。徳島市内に住んでいる人でも、よほどの理由が無いと来ない場所だと思います。
正直なところ、登壇者や弊社メンバー以外の参加者は望めないかなと最初は諦めていましたが、結果として半数は市内や県外（！）からも来てくださって驚きました。とはいえ、そこは tokushima.rb で宣伝してくれた方が居たり、登壇者の方が誘ってくれたりと縁があってのことではあるのですが、きちんと形になった事は素直に嬉しかったです。
それでも田舎のイベントでは参加人数は限られてきます。その状況の中で、自分はどういう人の繋がりを見たいのか、作りたいのか、何より何を大事にしたいコミュニティにしたいのか、そんな事を考えさせられましたし、そうでなければ簡単に継続するモチベーションをなくしてしまうだろうなぁと思いました。精進します。
次回はどうしようかな
冬になると、ますます神山に来る人は減ると思うので、次回は春だと思います。桜の時期とか神山はキレイだからいいんじゃないかな？
とはいえ、最近リモートワークも盛り上がってきていますし、ちょっと徳島はサテライトオフィスやらリモートワーク（テレワーク？）をヨイショし過ぎな面があるので、負の成分多めの「リモートワークの現場ミートアップ」ができると面白いんじゃないかなぁと思ったりしています。一度とことんまで Problem の部分を洗い出さないと次に繋がる Try は出てきませんし、未来に繋がる話しができたりしないかなと。（これ Ruby かって気もしますが、僕にとって Ruby コミュニティとは何か世界に貢献するコミュニティなのだってことで。）
ではまた次回！
写真撮るのが遅れて数人帰ってしまいましたが集合写真を＞＜
