$shibayu36->blog;

プログラミングの話や自分の考えを色々と書いています。特にperl、emacsや読んだ本の話が多いです。

会議の前に決めることは何か - 「感動の会議!」読んだ

最近会議の主催が多くなってきて、いくつか自分でも成功体験をしたので、なぜ成功したのか早めに言語化しておこうと思い、会議の本を読むことにした。今回は「感動の会議!」という本。

感動の会議!

感動の会議!

今回の本は、

「感」・・・参加者が意気に感じ、自ら考え
「動」・・・自主的に動き出す

を達成できる会議のやり方をいろいろと教えてくれる本。会議をいろいろやってみて、うまくいく時とうまくいかない時の差がどこにあるのかわからない人や、そもそも会議どうやればいいかわからない人は読んでみると面白いと思う。

今回僕の中で印象に残ったのは、この本の第1部の会議を開く前に意識すること・決めておくことの部分。いろいろと意識することや決めておくことが書かれているのだけれど、その中で特にここを意識しておけば良いのではないかというポイントが2つあったのでそれについてと、それに似たブログ記事に言及して会議のまとめの話を書こうと思う。

  • この会議が終了時点でどのような状態になっていたら、成功といえるのか
  • この人にはこの会議中に何を期待するのか
  • 会議の最後にまとめをする

この会議が終了時点でどのような状態になっていたら、成功といえるのか

この本の中に、良い会議は必ず明確なゴールを持っていると書かれている。ゴールの例としては

  • 人材の活性化について、すぐできるアイデアを3つ出す
  • 〇〇の件について、A社が合意する提案をつくり意思決定をする

などのようなもの。確かにゴールを決めてないと大体の会議はどこを向いているかわからなくなる。よくあるのはアイデアを出しあいましょうとか、情報を共有しましょうとかそういう目的の会議だが、明確にこれが出来れば良いというものがないと、変な方向に流れてしまったり、無駄な話をしてしまったりということがよく発生する。

このゴールを決めるために、会議の主催者は次の質問に答える必要があると書かれている。

「この会議が終了時点でどのような状態になっていたら、成功といえるのか?」

この質問は非常に良く出来ていると感じた。実際にこれを試してみると、最近だと以下の様なゴールを決めることが出来た。

  • この会議では制作物の図を作りながら、全員が何をつくるかのイメージを一致させ、明日から作業が取り掛かれる状態になったら成功
  • この会議では先方に送るべき質問文を作成し、それに対して全員の合意が取れたら成功
  • この会議ではやりたいことをエンジニアの〇〇さんに伝え、会議後すぐに手を動かせるようになったら成功

このくらいに会議のゴールが具体化されていれば、会議の方向性がぶれないし、実際にこのゴールを達成できなかった時に何がうまく行かなかったのかと振り返ることもできる。ちょっとした質問を会議前に自分にするだけで、このように具体的なゴールが見えてくるので非常に良い質問と感じた。

この人にはこの会議中に何を期待するのか

この本の中に以下の様なことが書いてある。

あなたが主催している会議の参加者を一人ひとり思い浮かべてください。お互いにとって、本当に出席が必要でしょうか。

確かにあるあるな会議として、なぜか参加者が多いけど実際に会話しているのはその中の2~3人だけというものだ。その場合その2~3人以外はその会議に出る意味は殆どなかったと言える。このような会議を僕は絶対に避けたい。

その場合この本の中に、「参加者一人ひとりに、会議で何を期待するのかを明確にします」と書かれていた。このことから会議の前に参加者それぞれに対して、「この人にはこの会議中に何を期待するのか」という質問を自分自身に投げかけておくと、本当に会議に出る必要があるかということが明確になり良いと感じた。この質問をしてみると

  • 曖昧な答えしか作れなかった場合にはほとんど必要ないから参加してもらわなくて良いと結論づけられる
  • 会議の中の一部分にしか期待する箇所がないのであればその部分だけ切り出してその人は早めに終わらせる

などということも出来る。

なので会議の前には参加者それぞれの人に対して、「この人には何を期待するのか」と考えるということは必ずしたほうが良いと思った。

会議の最後にまとめをする

この本を読んでいて別のブログ記事を思い出したので言及しておく。

この記事の中で打ち合わせの最後に以下のまとめをしたほうが良いと書かれている。

・決まったことは何か
・決めようと思ったけれど決まらなかったことは何か
・各人のアクションは何か(そして〆切はいつか)
・次回の打ち合わせはいつか

このまとめのリストも非常に秀逸だと思う。まず会議の結論がきちんとついていて、決まらなかったことをはっきりさせておくことで何が達成できなかったか明らかにしていて、また各人のアクションを決めることで次のスタートをその場できっている。会議のエッセンスが集約されているまとめだと思った。


このまとめはさきほど書いた、「どのような状態であったら成功か」「この人にはこの会議中に何を期待するのか」に通じるものがあると思う。どのような状態だったら成功かが決まってなかったら、「決まったことは何か」「決まらなかったことは何か」も決まらないと思うし、出る必要のない人が出ていたら「全員のアクション」が決まらないと思う。いろいろつながってると感じた。

まとめ

今回は「感動の会議!」を読んで感じた会議の前に決めることについて書いてみた。またそれと関連して会議のまとめをするという部分にも言及した。それぞれから考えると会議の流れとしては

  • 会議前にその会議の成功条件を決める
  • 会議前にそれぞれの人に対して何を期待するか考える
  • それにそって会議をする
  • 最後の10分くらいでまとめをする

とするのが良さそう。

他にも色々やり方がありそうなので、会議に関する本をもう少し読んでみたい。

会議で事件を起こせ(新潮新書)

会議で事件を起こせ(新潮新書)

「シバソン」という名の何も準備しないイベント

最近、シバソンという名のほぼ身内でやっているイベントを開催している。シバソンとはシバハッカソンの略で、なぜか適当にハッカソンしますと会社で呼びかけたら自然とシバソンという名前になっていた。今日は勉強会について簡単に書きたいと思う。

Kyoto.pm

以前自分はKyoto.pmというperl界隈のイベントの主催をしていた。このイベントは最初もっといろいろな人にアウトプットする場を提供したいという気持ちで始めたイベントだった。有名な東京のperl hackerを呼べたり、東京からはるばる来てくれる人が何人かいて、けっこう面白いイベントに出来たと思ってる。


ただ問題点がいくつかあった。

一つ目は主催者が開催のために前準備(スピーカー集めとか)をするコストが非常に高かったこと。発表会形式にすると、特に関西ということもあって、全然スピーカーが集まらないということがよくあった。そのたびにいろんな人に声をかけたりしていて大変だった。

二つ目は開催中に自分自身があまり楽しめていなかったということ。開催中も懇親会のことや受付やマイクの設定などしていたら、自分自身はちゃんとトークを聞くことができなかったりして、あまり楽しめなかった。もちろんメインのトークが終わったあとの懇親会自体はけっこういろんな人と話すことが出来たし、東京から読んだperl hacker達といろいろ話せたのは楽しかった。しかしトーク形式の場では用意などもあって、自身は参加することが出来なかった。

上の問題点があったせいで、徐々に開催をするのが疲れてきてしまい、ほとんど開催しなくなってしまった。


そこで次に開催するときは、あまり主催者のコストが掛からないもので、自分が楽しめるというのを考えようと決めた。

第一回シバソン

最近仕事ではほぼコードを書かなくなった。けれど趣味ではコードはある程度書いていたいという思いがあった。でも一人だとあんまりコードを書こうという気持ちになれない。こういうことがあって、これはイベントチャンスだなと思った。

そう考えた時に、以前の失敗を踏まえて、「ただ自分がコードを書く機会をつくるために周りを巻き込んで開催し、かつ何も準備しない」という方向に振り切ったイベントを開催しようと考えた。それがシバソンというものの始まった経緯。

そこでとりあえず社内にこういう感じで呼びかけた。

土曜の10時くらいからハッカソンを開催します。10時から始まるかもわかりません。特に企画はありません。時間と場所だけを提供するイベントです。コードを書いても本を読んでも何をやってもいいです。あ、昼ごはんくらいは一緒に食べに行くか出前取るのが企画です。適当に何かしたい人は来てください。

こんなかんじで、第一回シバソンというのが始まった。

やってみたところ、id:y_uukiid:krrrrなど何人か参加してくれて、自分にとっては書きたいと思ってたコードを一日中書けて、周りには人がいたので軽く質問したり出来て、かつ自分はただ場所と時間を提供するだけのコストしかかからなかったというイベントになった。なぜかその時京都に来ていたid:moznionやmiyagawaさんが顔を出したりしてわけわからないイベントだった。ただ自分は楽しかったし、周りも成果がいくつか出ていたようだった。

第三回シバソン

自分が楽しめたので、あとは適当に毎週末暇な時間があれば自分がコードを書きたいがために開催するようにした。休みのうち一日暇な時間があれば適当に社内で呼びかけ、来たい人は来てねという感じで行う。

昨日開催した第三回はさらにわけ分からない感じになって、まず開催時間がちゃんと決まってなかった。主催者が起きたら開催(10時くらい)ということにした。そうしたらまあ適宜起きた順に参加してくるという状態になった。

またリモート参加も可ということにした。そうしたら最初は全員(4人くらい)リモートで、SlackとかSqwiggleとかZoomとかを利用して遊びながらハッカソンをするという状態になった。

なぜかこんなに適当にやってもけっこうハッカソンぽくなって、最終的に18時くらいにはそれぞれの人がいくつか成果を出して終わってた。僕も今回はFacebookのいいねの仕様についてけっこう調べることが出来たり、SqwiggleやZoomなどリモートの知見を得ることが出来たり、githubのissueからTrelloにカードをつくるというブックマークレット&拡張を完成させることができた。

今後のシバソン

とりあえず今後もこの状態で続けていこうと思う。一切主催者コストも掛からないし、自分も楽しい。自分が暇な土日のうち一日コードを書く機会を作るのに非常に有意義だし、周りを巻き込むと周りの人も同様に何か成果を出してくれる。これだったら適当に開催し続けられるような気がする。

まとめ

今回はKyoto.pmの時の反省と、それをうけて開催したシバソンのことについて書いた。

イベント開催というのは非常に大変だと思う。大きくなればなるほどどんどん大変になる。その時イベント開催して人が楽しんでいる事自体に充実を覚えないとなかなか難しいのではないかなと思う。

僕はそれ自体にはあまり充実を得られなかったので、以下の二つを意識することにしてシバソンを開催している。

  • 主催者のコストが掛からないイベントはそれだけで善である
  • 主催者自身が楽しいイベントは善である

今後も自分がイベントを主催するときは上の二つを意識するようにしていきたいと思った。

ghi便利だった

今日いろいろ探してたら、githubのissueをいろいろ扱ってくれるghiというのを発見したので使った。便利だった。

ghi listとかしたら、そのレポジトリのopen issueを出してくれる

$ cd prepan
$ ghi list
# CPAN-API/prepan open issues
  51: Allow login with CPAN 1
  50: When editing an existing entry, make the button "Save" not "Post"
  48: Add permalinks to comments
  43: Can't remove entry from web ui
  42: Twitter profile image doesn't show  bug  @
  40: Comment Edit and or Preview option
  39: module search feature

ほかにも

  • ghi list --sort updated でsort順を変更できる
  • ghi list -L bug でラベルで絞り込み出来る

などなど便利機能がある。


またghi show (issue number)でissueの情報を取得できる。これらを組み合わせるとpecoで絞り込みながら、issueの情報を見るというのができるようになる。

以下のようなコマンドを使う。

ghi show $(ghi list --sort updated | grep -v 'open issue' | grep -v 'Not Found' | peco | awk '{ print $1 }')

他にもアサインしたりとかそういうのがCLIツールでまとめてあるので便利だった。

インターネットの契約会社の人と話した

なんか最近家に人が来るたびに毎回雑談している気がする。今回はインターネットの契約会社の人と話した。

管理会社とオーナー

インターネットの契約ってこういうマンション系の場合、どこに営業かけるんですかって聞いてみたところ、管理会社もしくは管理会社を通してないオーナーに直接ということだった。

管理会社に営業かけておくと、そこからその管理会社が管理している物件のオーナーに提案してくれるらしい。なのでそこに営業かけることがあるっぽい。でもこちらからじゃあ管理会社に営業かけたほうが効率いいんですねって話したら、そうでもないって言われた。管理会社を通してないオーナーは非常にたくさんいるようで、そこにも営業をかけないと母数として多くならないらしい。また管理会社を通してない場合のほうが確約率も高い(?)ようだった。

だいたい管理会社とオーナーで半々くらいの比率で営業しているらしい。面白い。

古いマンションとインターネット

また確約率の話をしていた時に、実は古いマンションのほうが確約率が高いと言っていて面白かった。古いマンションは相対的に人が入りにくくなるので、インターネット無料という追加バリューを付けることにより人を入れようとする戦略があるみたい。なので確約率が高くなる傾向にあると言っていた。

クリーニング屋のおっちゃんと話した

この前染み抜きをクリーニング屋にやってもらおうと思って、適当に探してた。そうしたら、見つけたクリーニング屋が店舗を持って無くて、受け取りに来てくれるらしいと聞いたので来てもらい、その時5分くらい雑談した。その話が興味深かったのでメモ。

なぜクリーニング屋?

そのクリーニング屋は米屋の傍らクリーニング屋をやっているらしい。米屋とクリーニング屋何か関係有るのかな。洗濯に米のとぎ汁使ったりするとか聞いたことあるけど、そんな単純でもない気もする。

なぜホームページ持ってない?

またその店インターネット上に情報が無かったので(大抵クリーニング屋はホームページなかった)、適当になんでホームページとかブログ作ってないんですか?と聞いてみた。そうしたら店舗構えてないので作ってないんですよと言っていた。

「店舗構えてないので作ってないんですよ」という言葉を聞くと逆に店舗構えてないからこそインターネット使わないとだめだろと思うのだけど、そこは置いておく。あんまり話せなかったので、ハードルが高いのか、そもそもインターネットを利用するというのが選択肢にすら入ってないのかよく分からなかったが、まあインターネットとかで情報を作るというのが難しいと思ってて、難しいならそこまでする必要ないかって思ってるのじゃないかなと思った。最近は適当にブログとか作っておくだけでもインターネットで情報ゲットできて信頼性増すので、ハードル高いと思う人が減って欲しい。

「デザインのデザイン」読んだ

デザインのデザイン

デザインのデザイン

読んだ。「クジラは潮を吹いていた」を読んだ - $shibayu36->blog;で話していたのと同様、他職種のマインドを知るために読んでみた。


全体的に面白くて1日くらいで読んでしまったのだけど、何が面白かったのかと言われるとあまり言語化できない。なんとなくデザイナマインドがあったらきちんと言語化できたのだろうか。


その中でも面白いなと思ったのが、この本に書かれている一部分の話。

ちょっと考えただけでも、感覚が五つに集約されるはずもない。たとえば、指先で微かに触れるようなデリケートな接触と、手のひらでドアノブを押すような感覚は同じ「触覚」と分類するには抵抗がある。

これを読んだ時に、これまでその分類に抵抗があるとそんなに感じなかった自分と、それに抵抗を感じるデザイナとの間で、若干の認識のずれというのがあるのだなと感じた。「人がどう感じるか」というところに焦点を当て、高い精度で観察し、感受性が高くなると、感覚というものが徐々に細分化されていって、感覚が五つというのに違和感を感じるようになるのかもしれない。


面白かったが、言語化できない。これに関してはちょっと悔しいので、デザイナとちょっと会話して、どういうところが面白いかについてちょっと話してみたい、そう思った本でした。あとこの本で紹介されていた陰翳礼讃という本も面白そうなので読んでみたい。

陰翳礼讃 (中公文庫)

陰翳礼讃 (中公文庫)

twitter
hatena
rss
Social Icon ブログパーツ