イベントの組み立て方

なぜ書こうと思ったのか

最近いくつかのイベントに参加したり運営として関わったりしてみて, 思ったよりも行き当たりばったりでイベントが作られているのかもしれないと感じました. そこでまずイベントの組み立て方について自分の知っていることを公開して, それに対する反応をもらったり, 議論のきっかけになったりしたらいいなと思い, この記事を書いています. 参加者も運営も幸せなイベントが増える方が嬉しいので.

この記事で言うイベントは

  • 比較的短期 (1日〜数日)
  • 当日のみ関わる参加者と事前準備をする運営がいる
  • イベント当日は皆が同じ場所に集まる

という形式を前提とします.

要約 (TL;DRあるいは今北産業)

書くとは言いましたが, たぶんけっこう長くなるので要約を最初に書いておきます.

  1. 「イベントが終わったときの参加者の内的状態 (心と思考の両方含んだ精神の状態) がどうなっていて欲しいか」をまず考えよう. これが最初です. 絶対に!
  2. 次に, その狙いを達成するための手段を各種制約の中で組み立てる.
  3. そしてイベント終了後すこし間を置いてから, 最初の狙いに照らして「狙い通りだったこと」「狙いが達成できなかったこと」「意外と上手く行ってしまったこと」などの点を振り返り分析する.

本文

この記事では「イベントを作るときに常に意識していること」について書いていきます. ここで言うイベントは, 大勢で集って飲み会をしたり, 何かの勉強会で発表をしたり, キャンプに行ったりなどけっこう広い範囲のことを想定しています.

自分の経験から事例を拾ってくると, 学部4回生での卒業ゼミの発表だったり, 数学カフェでの発表や数学茶屋の運営, YMCAでの (運営側である) リーダーとしての活動というものがあります. 公益財団法人YMCA (http://www.ymcajapan.org/) とはキリスト教を基盤として社会活動を行う団体です. この団体が開催していたキャンプに参加者としてお世話にもなったし, 大学生のときに運営側もやっていました. 4回生のときの卒業ゼミでは数学的な内容の指導以外に発表の方法の指導も受けました.

主にこのYMCAと卒業ゼミで身に付けたものをこれから書いていきます. 実践のみで身に付けたので理論面は雑かもしれませんが悪しからず.

狙いの設定

まず狙いの設定とその狙いを運営全員で共有することが一番大事です.

要約でも書いたように, 狙いとは「参加者にどんな状態で帰ってもらいたいか」ということです. たいていの場合

  • 参加者のイメージ
  • どんな気持ちになったり, どんな影響を受けたりして欲しいか

をセットで考えることになるでしょう. それはこの両者を1つずつ決めるには, もう一方が決まってないと判断が難しいからです. ちなみに私は後者のことを「おみやげ」と表現することが多いです. 参加者の方々にイベントの「おみやげ」として, 何らの気持ちや心境の変化を持ち帰ってもらうイメージです. (これは確か卒業ゼミで先生が仰っていた表現だった記憶がありますが, うろ覚えです.)

狙いとしては, 例えば数学のイベントであれば

  • 数学の理解レベルはどんな人を対象とするのか
  • 数学とどういう付き合い方をしている人を対象とするのか
  • どういう雰囲気の数学イベントを求めている人を対象とするのか
  • 終わったときにどんな感想を持って欲しいのか
  • 「数学する仲間と知り合えて良かった」なのか
  • 「知識が増えて嬉しい」なのか
  • 「全然分からなかったけどそれが刺激になった」なのか

のように考えられるパターンはけっこう多いです. そしてこの中から運営の方々のそれぞれの想いに近いものを拾い, それぞれの想いを伝え合い (ときにはぶつけ合って) 運営としての「狙い」を固めていきます.

なぜ必ずこれを最初にやらないといけないかと言うと,

  • 狙いが先に決まっていないと, イベントで実際にやることを決めるための基準が定まっていないために, 何をやるかの判断がブレる
  • 当日, 臨機応変な対応が求められる場面でちぐはぐな対応になってしまう
  • 事後の振り返りで, 何を良かったと評価し, 何を反省すればいいかがあやふやになる

など何のためのイベントか分からなくなり, 参加者も運営も幸せになりません.

逆の言い方をすると, 狙いを最初に定め運営で共有しておくことで,

  • イベントの内容を決める基準が固定されているので議論しやすくなる
  • 当日の突然のアクシデントにも運営が連携して対処でき, 参加者が感じる違和感も少なく済む
  • 基準に照らして振り返りをするため, 良かったところや悪かったところを客観的に評価でき, 今後のイベント運営に活かせられる

といういいことがあるということです.

また, この段階では具体的にやることには踏み込まず, 想いや気持ちのようなふわふわしているもので狙いを表現します. というのはその狙いを達成する手段というのは無数にあり, さらに会場の物理的な制約なども含めると検討するにはパターンが多過ぎるからです. まずは指針となるものを先に決めるのが大事です.

手段の組み立て

では狙いが設定されたということで, 具体的にどんな活動をするかという「手段」の部分について考えていきましょう. ここでは狙いよりも具体的かつ技術的なことについて書いていきます.

前提として, イベント当日には参加者と運営が一堂に会しているとします. 加えて参加者の中には初対面どうしの人もいる, ということにしておきましょう. その状態から全体を「1つの集団」にしていくことを目指します. (もし既に全員が知り合いだった場合でも, ここで説明する流れをアレンジして, お互いの知らなかった側面を見付けられるようなイベントにしてもいいかもしれません.)

導入

初対面の人どうしがいるのでまずはそこにある壁をどうにかしていきます.

参加者にいきなり隣りにいる初対面の人と話せとか, 前に出て長時間スピーチをしろとかはハードルが高過ぎるので, まずは集団に埋没したままできる簡単なことをしてもらいます. 例えば, 進行役vs.参加者でじゃんけんをして最後まで勝ち残った人が優勝というゲームとか, 順々に簡単な質問に答えてもらうとか (Yes/Noで答えられるものや「ごきげんよう」のサイコロトークみたいなイメージ) から始めます. とにかく参加者に声を出したり身体を動かしたりしてもらうのが大事です. これをすることで参加者の意識を「離れて見てる人」から「このイベントの一部」へ変えます.

この段階では各参加者と進行役が1対1でつながっている状態が作れれば十分です. 参加者からは「私は今この人の話を聞けばいいのか」と思ってもらい, 進行役からは「今私はこの人達に話し掛けているんだ」という雰囲気が出ていれば成功です.

ここで気を付ける必要があるは, 既に知り合いである参加者どうしがいるパターンです. 一見イベントの雰囲気にプラスなように思えますが, 意外と雰囲気作りの障害になることがあります. 知ってる人どうしで固まってしまい, (本人たちにはその意識は無いものの) それ以外の人達に疎外感を与えることも起き得るからです. そのため参加者に知り合いどうしがいることには一切触れず, 全員に平等に話し掛けることが進行役にとって大事なことです.

関係の移行

各参加者と進行役の間の関係が築けたところで, 段々とそれを参加者どうしの関係へ移行していきます.

運営は導入の部分で参加者がどんな人なのかを少しは知っているはずです. そこで参加者と参加者の間に入って同じ話題を振って会話するように促したり, 両者の情報交換の仲立ちをします. 具体的にやるならグループディスカッションやチーム対抗の競技などになります. その際, 各グループに運営が付きコミュニケーションを促すことになると思いますが, メンバーの年齢や個々人の性格によって状況は様々ですので臨機応変にコミュ力を振り絞って頑張りましょう(笑)

この時点で運営が参加者を観察するポイントとしては

  • 参加者ごとの発言回数, 特に極端に発言回数が少ない参加者がいないか
  • 参加者どうしの発言回数

です. そして発言回数が少ない人が発言しやすい状況を作ったり, あまり話していない参加者どうしの間に立って会話をしたりして, 参加者どうしの関係に濃淡を作らないようにします.

ここまで書いた関係の移行のやり方は勉強会の発表などには当て嵌まりづらいですが, 役割としては質疑応答の時間が相当すると思います. 受けた質問を発表者が聴衆全員に対して復唱することで質問者のことを皆に知ってもらうことができます. 実際に会話はしないものの, 同じ聴衆にいる人に目が向くことで参加者どうしの関係ができていくはずです.

集団の完成

関係の移行を色々な組み合わせや色々なサイズの集団で行っていき, 参加者と運営の全員がお互いのことを知り, 全体が1つの集団になればイベント自体は完了です. 運営の手助け無しに各所で会話が自然発生するような雰囲気になっていると思います. 勉強会の発表の例で言うと, 発表が終わった瞬間に聴衆どうしで自然と感想を言い合ったり, 分からなかったところを質問したりしていれば大成功です. ここまで到達できれば, もう運営がやるべきことはあまりありません. 運営も参加者としてイベントを楽しみましょう.

あまり頑張らなくてもこういった良い雰囲気になってるかもしれませんが, それは運営が参加者に助けられていただけですので, あくまで運営が狙いを定めてイベントを進めることが大事です.

振り返り

さて無事イベントも終わって, ここまでの準備を思い出しているところです. このときだいたいの人はやや興奮ぎみにイベントの成功を喜んでいるでしょう. 苦労して準備したことが報われた気持ちになっているでしょう. これはごく普通なことですし, それだけ頑張ったのだから存分にそのいい気分にひたりましょう.

イベントの振り返りを行うのはその熱狂から醒めてからです. イベント終了直後の高揚した状態ではポジティブな評価ばかり出てくるでしょう. ネガティブな評価が無ければ振り返りとして片手落ちです.

どんなイベントにも

  • 狙いどおり上手く行ったところ
  • 狙いは良かったが失敗したところ
  • 対処できた想定外なこと
  • 対処できなかった想定外なこと
  • 予想外に上手く行ってしまったこと
  • そもそも狙いが良くなかったと感じた瞬間

があると思います. それらが元々の狙いに照らして良かったことなのか悪かったことなのかを評価しましょう. 別に失敗したことは問題ではありません. それを次の改善につなげられないことが問題なのです. 誰かを責めるでもなく, 責任逃れをするでもなく振り返りの話し合いができると良いと思います. そして次のイベントでこの振り返りを活かしていきましょう!!

いくつか補足

ここまででほとんどの内容について書き終わりました. 最後に「私がどういうイベント運営が良いと考えているのか」をはっきりさせるため, いくつか思うところを書き出してみます.

参加者を想定しないと何がマズいのでしょうか? それは, つまらなそうにしていた参加者がいたり, イベント後に不満が出たときに「あの人はこのイベントが対象としていなかったから仕方無い」という言い訳が簡単にできてしまうことです. 本当に想定外の人だったのであれば

  • 今後そういう人も対象にするかどうか
  • 広報でイベントの狙いが上手く伝えられていたか

を考えるべきです.

イベントの狙いを定めておくと運営以外にもよい影響があります. (振り返りの内容を公開する前提を置きますが) 振り返りの内容を知ることで, 先行事例としてどういうイベントをやるとどんな効果があるのかを他の人も知ることができます. その人が別のイベントを開いたとすると, 元の運営は2つのイベントに対して良いことをしたことになります.

狙いの方向性が一致しない場合はどうしたらいいでしょうか? その場合は諦めましょう. それぞれの信念の不一致ですので距離を置いて棲み分けましょう. そしてそれぞれ別のイベントを開く方が平和だと思います.

では手段の方向性が一致しない場合は? 手段の話まで進んでいるなら狙いの方向性では一致しているはずです. その合意した狙いを基準にして手段の善し悪しを評価しましょう. 基準が決まっている議論であればそこまで荒れないはずです.

この記事を書いていて思い出したこと.「キャンプが参加者にどう影響したのかは, 次にキャンプに来たときに分かる」とYMCAのスタッフから言われたことがあります. たかだか数日の時間ですぐに変わるわけではなく, そこで得た何かの影響が少しずつ現れてきて, 次に会ったときに目に見える変化になっている. という意味だと思っています.

私は数学茶屋というイベントで運営だったのですが, 実はここに書いたことを考えながらイベントの準備と進行をしていました. ここまで観察されていることを気持ち悪く思うかもしれませんが, イベントを良いものにするためだったので, ご勘弁ください.

そして数学茶屋で一緒に運営をやった方々は, イベントの組み立て方への私の強いこだわりを知ってるんじゃないかと思います. その裏にはこんなことがあったんだよ, というネタばらしの記事でした.

めっちゃ長くなってしまいましたが, ここまで読んでくださってありがとうございました.

広告

√2の話の本歌取り 〜 プログラマのための数学勉強会第6回より

発端

第6回 プログラマのための数学勉強会 (とぎゃったは 『第6回 プログラマのための数学勉強会』のまとめ #maths4pg) という楽しそうな会が行われていました. その中のLT発表者が

ということをつぶやいていたので,「じゃあ自分なりの√2が導入できることのすごさを説明したい」と思い立って, この記事を書いています. 決して勉強会に参加できなくて羨しかったわけではありません!!

@taketo1024さんの発表資料はこちらです. 面白い内容ですので, ぜひ一度目を通しておいてください.

有理数しか知らない人に√2を説明する

LTの本歌取りということで, いったん@taketo1024さんの意図は敢えて見ないことにして, 自分が√2を説明するとしたらどうなるかを書いていこうと思います.

まず説明する相手は「数と言えば有理数で全てだ」と信じている人 (名前はQさん) とします. 現代ではそういう考えは少数派だと思いますが, ある時代では「数と言えば有理数」というのが常識でした. まぁ今回は「√2という有理数でない数もあるんだ」と主張しても, 相手を怒らせて殺されるようなことは無いとします. 詳しくは「ピタゴラス教団とヒッパソス」の話を調べてみてください.

私「ひとまず

root2

となる数があったとしましょう. 定義はこの式だけで計算は有理数と同じようにします. これの名前を√2としましょう.」

Qさん「√2なんて無いよ. ほら√2が数 (有理数) じゃないことが証明できるよ.」

私「まぁまぁ, すぐには信じられないかもしれないけど, √2で計算するとどうなるか眺めていってみようよ. 面白いことが見られるよ!」

私「じゃあ, まず足し算は

addition

みたいな感じで, 引き算は

subtraction

みたいな感じです.」

Qさん「みたいな感じ, って適当だなぁ. ところでその3とxを並べたものは何ですか?」

私「あぁ, これは3とxを掛け算したものです. もうちょっと複雑な掛け算のパターンだと

multiplication

みたいになります. この計算で初めて

root2

ってルールを使ってます.」

Qさん「うーん, ここまではまぁ分かるけど割り算は無理じゃないですか?」

私「実はなんと上手くできるんですよ. 例えば,

division

みたいに計算できます. これで加減乗除の全てが揃いました. これだけできれば数と認めてもいいでしょう?」

Qさん「むむむ. でも具体的にどんな数なのか全く分かってないんじゃ?」

私「graphのグラフとx軸が交わるところが√2です.」

Qさん「それじゃ, 該当する場所が2箇所ありませんか?」

私「ぐっ, そ, その2つはroot2からだけでは区別が付かないので, 正の方を√2, 負の方を-√2とします. 具体的な値の計算には, 二分法, ニュートン法, 連分数展開などがあります.」

Qさん「理論的には?」

私「さっきまで話していた方法は代数拡大を使うもので@taketo1024さんのLTはこれを使ってます. 他にはデデキント切断もあります.」

LTの資料だけでは詳しい部分が分からないかもしれないので, @taketo1024さんのこちらのシリーズを読んでください.

  1. 数とは何か?
  2. 群・環・体の定義
  3. 有理数を作ってみよう
  4. 時計の世界の「環」
  5. 小さな「体」を作ろう
  6. 多項式は整数によく似てる
  7. 代数拡大で数を作ろう!

「Asakusa Framework 勉強会 2014夏」に参加してきました

前回 (「Asakusa Framework 勉強会 2014春」に参加&発表してきました) は発表もしたので緊張してましたが, 今回は参加だけなので気楽に聞いてきました. 台風の影響で開催されるか心配していましたが, 台風は消滅し無事に開催されました.

最初の発表は土佐さんによる「Asakusa Framework はじめの一歩」でした. 前回も同じテーマで発表されていますが, 前回のライブコーディングとは打って変わって紙芝居形式の資料を使った発表になっていました.

DMDL エディタの新しいバージョンを使っているのは当然として, Toad エディタまで使いこなした開発過程を見て, この資料の完成度の高さに感動しました. 実は今日初めて Toad エディタでフローを作る方法が分かったりしました(苦笑) 現在, Toad エディタの解説資料はこれが唯一のものじゃないかしら?

2 人目は川口さんによる「Asakusa歴史探訪&ここ最近の新機能」で, Asakusa Framework の歴史を辿る内容でした. 自分自身は Asakusa Framework の発展に付き合いながら仕事をしてきたので, だいたいの部分は知っていたのですが, 自分が関わる ver 0.2.2 以前の話や「それぞれの機能をどんな目的と意図を持ってリリースしたのか」という話は面白かったです.

改めて Asakusa Framework の成長過程を振り返ると, 案件からの要求要望を受け, しかしむやみに機能や仕様を肥大化させないように気を遣いながら, バージョンが上がっていったことが分かりました. ここはとても Asakusa らしいところだと思います.

今後もどんどん機能が増えていくはずなので, 自分はユーザとして楽しみです.

3 人目は才所さんによる「Asakusa Framework 部会って何ですか?」です. 最初「OSS コンソーシアムに Asakusa のグループができるよ」って聞いたときには, 正直あまりイメージが湧きませんでした. しかし, どんな目的でどんな方向の活動をしていこうとしているのかを聞いて,「真剣に Asakusa のビジネスを作っていこう」という意気込みを感じました.

部会で行った Hadoop と Asakusa をどのくらい使ったことがあるか? についてのアンケートの結果は興味深かったです. 細かい数字は忘れましたが, Hadoop に比べ Asakusa は使用されていない傾向があり, 特に「試しに動かしてみる」が少なかったです. おそらくこれは Asakusa が Hadoop と比べてさえ, とっつきづらさを抱えているのでしょう. Jinrikisha や Shafu などの各種サポートツールも出ていますが, さらにとっかかりのハードルを下げる何かが必要な気がします. そういうツールなり仕掛けを作っていけたらな, と思っています.

4 人目は福垣内さんによる「Asakusa を使った Asakusa EMR 環境での分散分析基盤構築」です. 聞いてみると予想以上にガチで Asakusa や EMR を分散処理バッチ基盤として使い, 2 時間弱かかるくらいの規模のバッチを動かしていました. そこで印象的だったのが「このくらいの規模のバッチだと, 初期投資, 複雑な処理が書ける仕組み, 運用費などの面で Asakusa を EMR で動かすのがちょうど良かった」という発言でした. SQL でバッチ処理するには辛いし, Redshift だと大掛かり過ぎるようです.

基盤の構成も, MySQL –> S3 –> EMR –> S3 –> MySQL と前回の私の発表とそっくりな構成を取られていました. また S3 のパスを切り換えることで, 本番, テストの切り換えができるそうで, そこもそっくりです. やはり他の人も同じ発想になるんだなぁ, と面白かったです.

ということは Asakusa + EMR というのは 1 つのパターンになりそうなので, サンプルプロジェクトのバリエーションとして EMR 版を作っても面白いと思いました. これを使って気軽に Asakusa を試す人が増えてくれれることを狙いたいです.

 

次回と次々回の勉強会の予定も既に立っているそうで, 8/22 の「2014 真夏」はノーチラス・テクノロジーズにて, 10/17 の「10/17 秋」はサイトロック様にて行われる予定だそうです. 真夏の方はビアバッシュ形式らしいので, いったい何が起こるのか楽しみです!!

それでは.

「Asakusa Framework 勉強会 2014春」に参加&発表してきました

Asakusa 勉強会の第2回となる「Asakusa Framework 勉強会 2014春」(http://connpass.com/event/5475/) に参加して, 運用について発表してきました.

ここ2年くらい日次バッチの運用の面倒を見ていて, その経験から得られた教訓やノウハウを語ってきました. 体系立ててあるわけではないですが, どうやったらバッチの運用が楽になるかのポイントを整理して並べてあります. 運用を上手く回すのに銀の弾丸は無いので, 今回の発表も地味な話の積み重ねですが, 新たに Asakusa バッチを運用する人の指針になれば嬉しいです. 資料は http://www.slideshare.net/KinebuchiTomo/asakusa-batch-operation に上げてあります.

発表中の雰囲気や Twitter のつぶやきを見ると, 悪くない反応をいただいているようです. それだけにみなさんシステムの運用で苦労されているということでしょうか.

他の方の発表も多岐に渡っていて面白かったです. IaaS 基盤を構築する RACK というツールや, JobSchedular という機能そのままの名前のツールの紹介では, ツールの存在を知ることができました.

土佐さんによる車夫と DMDL エディタのライブコーディングによる紹介は素晴しかったです.「ツールはあるが, どう使えば良いのか?」というのは使い始めでよく引っ掛かってしまうところで, そこをフォローするような発表内容でした. 自分には無い発想で, あのような発表が Asakusa を知ったばかりの人には必要なのだなぁと納得していました.

Asakusa Framework に興味を持っているはずの今日の参加者でも, Asakusa を触ったことのある人は3割程度でした. もっと名が広まって, 使ってみる人が増えるには, まだまだ草の根的な運動を続けていく必要があるのでしょう. 既に次の勉強会も7/11に品川と決まっているそうです. 次回の勉強会では, 開発工程でずっと使う「Asakusa Gradle Plugin」あたりのネタで発表したいところです.

この勉強会を開催していただいた土佐さん, 会場を貸していただいた新日鉄住金ソリューションズ様ありがとうございました.

yum で CDH3 の特定バージョンをインストールする方法

https://kinebuchitomo.wordpress.com/2012/03/24/webdb-press-vol-67-補足-追記/ でも書きましたが, CDH3 の update のバージョンを指定できると嬉しいのです. ただ上の方法だと別のバージョンを入れるときに, わざわざ repo ファイルと書き換えなくてはなりません.

そこで複数バージョンに対応した yum 用の repo ファイルを作成しました. 内容と使い方は Gist  に載せてあります. https://gist.github.com/2651006 CDH3u4 はまだ mirror ファイルが用意されていないので, コメントアウトしてあります.

apt などでもきっと同じようにできるはずです. できたら是非 Cloudera の方や私に教えてください.

WEB+DB Press vol.67 補足 (追記)

2012/02/24 発売の WEB+DB PRESS Vol.67 で記事を書かせていただきましたが, 紙幅の都合上載せ切れない文章がありました. その部分の文章を追記としてここに載せておきます. (技術評論社様のサポートページからもリンクを張っていただけるそうです)

挿入箇所は P.100 右カラム「CDH のインストール」の節です.「詳細は Cloudera のページを参照してください。」の後に以下の文章を追加するものと思ってください.

4章で使用するAsakusa 0.2.5が対応しているCDH3u2をインストールするため、Clouderaのページの手順「Step 1: Download the CDH3 Repository or Package.」においてOSの種類に応じて以下の作業を行ってください。

Red HatとCentOSではStep1のTo add the CDH3 repositoryの項の手順に従ってcloudera-cdh3.repoをダウンロードし、その中にあるmirrorlistの設定値をhttp://archive.cloudera.com/redhat/6/x86_64/cdh/3u2/mirrorsに変更してください。

UbuntuとDebianではStep1のTo add the CDH3 repositoryの項の手順に従ってcloudera.listファイルを作成し、その中にあるcdh3という文字列をcdh3u2に変更してください。

SUSEではhttp://archive.cloudera.com/sles/11/x86_64/cdh/cloudera-cdh3.repoにあるファイルをダウンロードし、その中にあるbaseurlの設定値をhttp://archive.cloudera.com/sles/11/x86_64/cdh/3u2/に変更してください。以下のコマンドを打ってパッケージ情報の更新を行ってください。
$ sudo zypper addrepo -f cloudera-cdh3.repo
$ sudo zypper refresh

どのOSでもStep2移行はClouderaのページにある通りに作業してください。また忘れずにOracle Javaをインストールして、そのJavaが使われるように設定してください。

既に CDH3u3 以上をインストールしている場合は、パッケージマネージャに CDH3u2 のインストールが不要と判断されインストールされないことがあります。そのときは既にインストールされているコンポーネントをアンインストールし、パッケージマネージャのキャッシュを削除し、再度 CDH3u2 をインストールしてください。パッケージマネージャのキャッシュが残っている場合には上手く CDH3u2 がインストールされないことがありますので注意してください。

内容を読んでいただくと分かると思いますが, CDH3u2 を指定してインストールするための手順が記述してあります.

調べた限りでは Cloudera のページに少し書いてある以外には, update number を指定したインストール方法のまとまった情報はありませんでした. なのでちょっと貴重な情報です(笑)

冗談はさておき開発で使うとなると OS やミドルウェアのバージョンは固定したくなるので, そういう場面で使える情報だと思っています. 特に Asakusa は CDH3 の対応バージョンを update number まで指定してあるので, CDH3 の最新バージョンに勝手にアップデートされないようにしておくと良いと思います.

それでは.

Hello world!

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can always preview any post or edit it before you share it to the world.