ゆるゆるメモ

日ごろ感じたことや学んだことをゆるゆると書いていく日記です。

社内イベントをむきなおりでやめることにした

新年あけましておめでとうございます。今年もよろしくお願いします。

昨年の11月に社内でAgile Japan サテライトを行いました。社内向けのイベントでしたが、社員+ビジネスパートナーさんが対象で全体で40人くらい集まり、なかなか盛況なイベントでした。

ふりかえりをやった

そのふりかえりを年明けに運営チームで行いました。1

最初はYWTかFun Done Learnあたりでふりかえろうかなーと思っていました。ですが、なんとなくうまく進むイメージができてなくて、とりあえず「次回どんな会にしたいですか?」と投げてみました。

この返答次第で、ふりかえりフレームワークを決めようと思ってました。2なのですが、最初に返ってきた答えが、

「これって需要あるんでしたっけ?」

というそもそも論な答えでした。私としては、前回のAgile Japanは過去最多レベルの人数参加で、当然需要があるものだと思ってました。それが覆されたわけです。

なので、そこまで考えていたふりかえりはやめました。

「そもそも何がしたかったんでしたっけ?」という視点からむきなおりをすることにしました。

その後の会議の進め方については、ぶっちゃけ適当です。雑談を交えながら本音を言いあい、それをファシグラしていくだけ。

色々話した結果、以下の結論を出しました。

  • "Agile Japan サテライト"と銘打つイベントはやめる
  • 別の形で他の現場のことを知るイベントをやる

結論を出すまでの経緯はちょっと書きづらいので、気になる方は個別に聞いてください。

今回の学び

むきなおりによりふりかえりとは違った結論を出せる

もし今回の進行をふりかえりベースで行っていた場合、(少なくとも私のファシリ力では)「やめる」という決断はできなかったと思います。

ザッソウでも会議ができる

雑談しながらファシグラって要はザッソウで会議してたようなものだと思います。運営チームは所属がバラバラで、特に利害関係がない事もあり言いたいことを言いまくってました。心理的安全が確保されているチームであれば、ザッソウでも会議は成り立つ3という経験を得られました。

※「ザッソウ」に関しては別の記事で本の感想を書いてますので、よければそちらもご覧ください。

acnaman.hatenablog.jp

ふりかえりフレームワークが全てではない

KPT、YWTなど、ふりかえりフレームワークはたくさんありますが、内容によってはフレームワーク外のことをやってみるのもアリです。(とはいえフレームワークは偉大です。今回は会議前にふりかえりのファシリ方針が決まっていないなど、私の準備不足がありそこは反省点です4。)

Agile Japan サテライト」はやめますが、代わりに今まで以上に意味のあるイベントを提供していきます。今年も引き続きがんばります。


  1. 本当は昨年末にふりかえる予定だったのですが、私のインフルエンザで流会となってしまいました(汗

  2. 例えば、「今回はコンテンツが良くなかったから次回はこうしたい」みたいなのが出てくれば、課題がありそうなのでProblemを洗い出せるKPTかなとか、「イベントはよかったけど運営を楽にしたい」とかなら、運営のモチベーションが上がりそうなFun Done Learnかなとか…

  3. ただし、最低限のファシリテートはあったほうが安心できます

  4. とはいえ本業外での運営なので、あまり時間をかけられないというジレンマもあります

出現する未来 ~±10年をU理論で見つめ直す~

f:id:acnaman:20191221003440j:plainこの記事はDevLOVE Advent Calendar 2019の21日目の記事です。

DevLOVE Advent Calendar 2019のテーマは「それぞれの10年、これからの10年」です。私も10年をふりかえってみたいと思います。

そのまえに

すぐ埋まるようなアドカレでもないにもかかわらず、21日(土)という、後半かつ休日の一番書きやすそうな日を真っ先に取ってしまってすみませんでした。

なぜこの日を選んだのかというと、今日入籍するからです。まさに人生の節目。むきなおりエントリを出すのには丁度いい日かなと。

ちなみに早朝に婚姻届を出しに行って、そのまま諸々の予定で家に帰れない予定のため、私にとって今日は全然書きやすい日ではありません。

10年間の棚卸し

10年間をふりかえります。ほぼ自分の整理のために書いているので、読み飛ばしていただいて構いません笑

2010年~2012年:大学生

まだ大学生でした。この頃は合唱のサークル一筋で、もっとちゃんと勉強しとけばよかったなぁと思います。反面、サークルに没頭した経験は今でも生きていると感じるので、これで良かったのかもなぁとも思います(なんだそりゃ)。

就活を始めるまではDevな仕事に就くとは全く思っていませんでした。そればかりか情報系の授業の単位は2回くらい落としてました。

2012年~2014年:新卒でもがく日々

新卒で入社した会社で、帳票パッケージソフトの開発をやってました。

配属されてすぐに新機能の開発をさせてもらったり、開発要員ひとりでのカスタマイズ案件に放り込まれたりと、新人にしては重めなタスクに対して、頑張ってかじりついていたと思います笑

当時は30人くらいの会社で、オフィスを見渡せば全員の顔が見える。そんな職場でした。社長の距離も近かったです。不安定ではありましたが、楽しく仕事してました。この会社でガッツリ開発して、担当の製品をお守りしていく人生かなーと思っていたら…

2014年~2016年:大きな組織の1部署の1要員

2014年に、私の所属していた会社はグループ会社に吸収合併されました。会社はまるまる1部署になりました。

だからといって個人としてやることはあまり大きくは変わらず、製品の開発は継続して行っていました。この頃は新製品の開発を(やはり個人で)割り当てられていたので、残業が多かったように思います。残業続きで思考停止しつつも、なんとか新製品をリリースさせました。

2016年〜2017年:このままじゃダメだ!と気づいて動き始めた

「正直もっといいやり方ないんかな」と思って参加したのがJapan Product Manager Conferenceでした1

ここが転機になりました。それまでの私はプロダクトマネジメントの考え方なんてまるで持ち合わせていませんでした。自分がいかに無駄なものを作ってきたのかというのを思い知らされました。世界が違う。このままじゃダメだ。

この日を境に外部の勉強会に参加しまくるようになりました。でも、このときは完全にただの参加者だったんですよね。参加して、啓発されて、おわり。そんなんが1年くらい続きました。

2017年〜2019年:参加者から越境者へ

ひょんなことから、匠塾、DevLOVEといった運営に参加するようになりました。参加しているだけじゃダメだったんですね。そこから何を行動に移すか。いかに挑戦するか。部署を超え会社を超え、いろいろなことを経験させてもらえました。仕事内容も、自社製品の開発から新規事業系の仕事に変わりました。

ちなみに今年何やってきたかについては、別のアドカレネタで既に書いてますので、よければこちらもご覧ください。

acnaman.hatenablog.jp

ここからの10年をどうするか

まず10年後の話をしますが、果たして私は10年後も同じような仕事をしているでしょうか?答えはNoだと思います。10年の棚卸しを見てもわかるように、10年前の私は今日の私を想像することができなかったはずです。10年後の私は、今の私の延長線上にはいないと考えます。U理論で言うところの「出現する未来」にあるはずです。

U理論で10年間を整理

U理論的な考え方をすると、これまでの10年は2016年を起点に緩やかにUプロセスをたどっていたように思います2

2010年~2016年:Downloading

→現状に疑問を持たず、与えられたものを一筋にこなしていた。

2016年~2017年:Seeing

→今までのやり方ではダメだと言うことに気づいた。だが、現状を打破するための行動には結びつかなかった。

2017年~2019年:Sensing〜Performing

→現状に疑問を抱きつつも自分が行動に移せていなかったことに気づき(Sensing)3
→自分がチームを変える姿を想像し(Presencing)、
→小さく始められることに目星をつけ(Crystallizing)、
→実践し(Prototyping)、
→継続化した(Performing)。

できていなかったこと

ここ数年での自分の変化は凄まじかったと思います。ですが、Presencingで真の「出現する未来」をつかめていたかと言われると微妙だなと思います。このときに鍵となるのが「私は何のためにここにいるのか」という問いです。私はこの問いに対する明確な答えをまだ持てていません。上に書いたUプロセスで得られたのは「ここ」を会社に限定した答えです。自分がエンジニアであるという前提を崩すレベルでの出現する未来は、まだ描けていないのです。

そのために何をするのか

Presencingで前提を崩すのには、まだ自分の中の世界が狭いと感じます。「私は何のためにここにいるのか」という問いに答えられるようになるためにも、自分の世界を拡げることをまずします。

多種多様な本を読む

これは少しずつ始めているのですが、今までの自分ではあまり手を出さなかったであろうジャンルの本に手を付けることをしたいです。本はある意味疑似体験なので、手っ取り早く世界を拡げるにはもってこいです。

自然を感じる

私は埼玉出身なのですが、近くに海なし、山なしの環境で育ったからか、自然を感じる機会が少なかったように思います。自分のセンスを磨くためにも、自然を感じる活動を増やしたいです。

社会課題を目の当たりにする

今うっすら感じているのは、社会課題の中に自分がやるべきことがありそうだということです。社会課題も様々ありますが、ネットで得られる情報だけでなく、自分の目で見て感じる情報がもっと増えてもよいのかなと思います。

マインドフルネスをやる

具体的にPresencingに到達しやすくなる方法として、マインドフルネスがあります。自分を見つめ直す時間として、確保していきたいです。

雑感

人生の節目ということで、U理論で自分のキャリアを見つめ直してみました。結果的に結論を出すところまでは至らなかったのですが、結論を出すためにやるべきことは見えてきました。マクロな視点で見つめ直すには有効な手段かと思います。

U理論の本は色々出ていますが、初めての方は「U理論入門」や「マンガでやさしくわかるU理論」あたりから読んでみることをオススメしますよ。(最初から本家行くと難しくて挫折しますw)

人と組織の問題を劇的に解決するU理論入門

人と組織の問題を劇的に解決するU理論入門

  • 作者:中土井僚
  • 出版社/メーカー: PHP研究所
  • 発売日: 2014/01/21
  • メディア: 単行本(ソフトカバー)

マンガでやさしくわかるU理論

マンガでやさしくわかるU理論

次の記事は来年かな〜。今年お世話になった方々、ありがとうございました。来年もよろしくおねがいします。


  1. ちなみに、一番インパクトが大きかったのはナイアンティックの河合さんのセッションでした。

  2. もちろん、各フェーズの中で小規模なUプロセスを繰り返しています。

  3. これに気づけたのはカイゼン・ジャーニーの「あなたは何をしている人なんですか」の影響が大きいです。

小~中規模の勉強会・カンファレンスの懇親会の準備(主に発注周り)

この記事はコミュニティ・カンファレンス運営 Advent Calendar 2019の18日目の記事です。

私はDevLOVE匠塾という勉強会コミュニティで運営メンバーをやっています。ここ最近のイベントでは懇親会準備担当になることが多かったです。自分の経験の整理の意味も込めて、懇親会準備についてまとめてみました。なんもやったことがないけど急に懇親会担当になっちゃった!という方の助けになるための情報を載せていきます。

※なお、担当したのはここ数回のイベントです。プロ並にできるようになったというわけではありません。あしからず。

【懇親会を担当したイベント】

小~中規模の懇親会運営にありがちな悩み

小~中規模の懇親会運営をしていると、以下のような悩みが出てきます。それぞれに対して、私の考える対策を書いていきます。(大規模カンファレンスの懇親会運営は別の悩みがありそうです…)

発注に関する有識者がいない

小規模ゆえに、懇親会運営経験者が運営チーム内にいなかったりします。そうなると、以下のような問題が発生しがちです。

  • 丁度いい量がわからない
  • どこで購入すればいいのかわからない
  • 予算が立てられない
  • 意見を求めても適切なフィードバックが得られない

対策1

早めに見積もりを作る。注文用のサイトで、実際に注文するつもりのものをカートに入れて、注文内容と金額を仮で出してみる。モノと金額が出ればイメージしやすくなりますので、知見が浅くても意見出しやすくなります。

対策2

記録を取る。あくまで2回目以降にしか使えないワザですが、懇親会の発注内容と懇親会終了時の残っている食べ物、飲み物を写真に撮っておくことで、次回以降の発注の参考資料に使えます。こんな感じで↓↓↓

f:id:acnaman:20191217233017j:plain
終了時の写真

ちなみに↑は厳密には中締め時の写真なので、全体の締めのタイミングではもうちょっと減ってます(そっちは撮り忘れたという致命的なミス)

対策3

この記事を読む。お力になれればよろしいのですが^^;

ぼっちになりがち

小規模の場合、運営メンバーもそこまで多くはないです。 そうなると、懇親会に関しては一人で最初から最後までやり遂げなければならない状況になりがちです。 発注は一人でもできるんですけど、当日の受け取りとかも一人になると、他の運営タスクとの兼ね合いで無理が出てきたり…ということもでてきます。

対策

情報共有する。「XX時~XX時の間に〇〇社さんが△を運んできますよ」という情報を共有して、他の人でも最低限の対応ができるようにしておきましょう。とはいえ、懇親会担当の属人化は避けられないので、配送が到着する時間は極力別のタスクを入れないようにしてもらいましょう。

実際の参加者数が読めない

小規模イベントだと、当日キャンセルの発生が結構な痛手になります。特に参加費が当日支払いになっている場合。食べ物や飲み物が余る上に、お金も回収できない。場合によってはシビアな計算が求められます。

対策1

事前に参加意思調査を行う。懇親会への参加が任意のイベントであれば、事前に参加意思を聞いておくことで大幅なズレを回避することができます。

対策2

参加者数の悲観的な値も見積もっておく。申し込み人数の7割くらいの人数を悲観的な参加者数として見積もっておき、そのときの集金額、人数ベースで発注をかける。ちなみに有料イベントだと参加率は高くなる傾向にあるので、(コミュニティにもよりますが)私は7割で十分だと考えています。無料イベントだともっと下がって5割くらいで見積もっておいたほうがいいです。(無料イベントの場合は週金額には影響なさそうですが)

対策3

料金を前払い制にする。これができるならそれに越したことはないです。赤字の心配はありませんし、お金を事前に支払ったというだけで参加率は良くなります。

※当日キャンセル時の返金ポリシーについては明確にしておきましょうね!

懇親会運営のいいところ

悩みばっかり書いているとネガティブイメージでやる人がいなくなりそうなので、いいところも書いておきます。

好きなチョイスができる

懇親会担当だと割と好きなものを選んで買い足せます。 私の場合、ビールはサッポロ派なので、ビール業界4位だろうが1必ず注文しますし、ピザも自分が食べたい味のを選びます(もちろん予算&常識の範囲内ですが)。

懇親会が終わったときの達成感

もはや気持ちの問題ですが、懇親会が無事終了したときの達成感は他の人よりも断然あります。何十人、何百人という人たちが懇親会を通じて笑顔になり、つながっていく。自分が準備しなかったらこの懇親会はなかったのですから、達成感はありますよ。

大まかな流れ

【イベント3日前まで】

  • 買うものを決める
  • サイトなどで発注をかける

【イベント前日まで】

  • 配送の時間を整理
  • 受け取り人員などの調整
  • 会場のレイアウトを決める

【イベント当日】

  • 配送の受け取り
  • 領収書の受け取り
  • イベント会場への搬入
  • イベント会場のセッティング

【当日または後日】

  • 立て替えた金額の精算

買うもの

購入が必要なものについて、それぞれ何をどれくらい買うか、どうやって買うかと、それに対する注意点を書いていきます。

※量は、懇親会の時間が2時間前後の想定で書いてます

■飲み物

何をどれくらい買うか?

  • ビール(350ml缶):人数の約2倍の本数
  • サワー+ハイボール:(合わせて)人数の約1~1.5倍の本数
  • ソフトドリンク(2L):最低3種類(水、ウーロン茶、ジュース)
注意点
  • ビールの銘柄は可能な限りバラけて注文する
  • 予算に応じてビールの本数を減らし、代わりに発泡酒ハイボールを増やす
  • 意外と(?)ほろよいは人気
  • 酒に関しては余ったら参加者に配って持ち帰ってもらえばいいので、ちょっと余るくらいの本数を注文するのが吉です
  • ソフトドリンクは絶対余るのですが、最低3種類確保するようにしてください。お茶は男性の飲めない人用、ジュースは女性の飲めない人用、水は酔っ払った人のチェイサー用です。余ったら持ち帰るか会場に寄付してください。

どうやって買うか?

いつもカクヤスで注文しています。飲み物に関しては、品揃えや、冷やして配送などのサービス面を考えるとカクヤス一択だと思います。

注意点

カクヤスは「18時~19時」など、広めな配達時間設定しかできません。例えば平日19:30スタートの勉強会だと19:30に飲み物が到着していないのは困るので、「18時~19時」の枠で注文せざるを得なくなります。こうなると、最悪の場合18:00に配送されてしまうので、その時間には受け取れる人がいないといけないわけです。会場の人が受け取れないときもあるので、急いで移動する必要が出てきたりと、地味に不便。

■ピザ

何をどれくらい買うか?

  • Lサイズピザ:人数の0.3〜0.8倍の枚数
    • 大きめの惣菜がない場合は0.5倍以上
注意点
  • 種類をバラけさせる。4種類くらいあると吉。
  • ピザを少なくする場合は惣菜や乾き物を増やす
  • ピザは持ち帰ったり保存ができないので頼みすぎると詰みます

どうやって買うか?

いつもドミノ・ピザで注文しています。(他のピザ屋と比べて安いと思っていたのですが、最近そうでもないかも?と思ってきました。) 配達は15分単位の指定ができて便利です。

注意点
  • 注文時はクーポンを適用するのを忘れないようにしましょう。
    • ドミノ・ピザの場合何故かクーポン発行アプリと注文用アプリが別になっている
  • 受け渡し場所が懇親会会場以外の場合は受け取りに注意
    • 配達員の方はピザがたくさん入る専用のかばんに入れて持って来るが、受け渡し後に持ち帰ってしまう
    • 複数人でピザを受け取りに行かないと詰みます。

■惣菜

何をどれくらい買うか?

  • オードブル:会場のサイズによりけりです

どうやって買うか?

DevLOVE Xのときは銀座萌黄亭に発注しました。前知識が少なかったので、ネットで色々調べてコスパが良さそうなところを選んだ気がします。

匠塾LT大会はドミノ・ピザのサイドメニューで済ませちゃいます。唐揚げとかサラダとかあります。5人テーブルにそれぞれ2種類1個ずつあれば十分でした。

■乾き物

何をどれくらい買うか?

  • 柿ピー、カルパス、カントリーマアムなどの徳用セット:人数の0.5倍くらいの袋数
注意点
  • 小分けできるものにしておくと、余っても配れるので楽

どうやって買うか?

飲み物と同じくカクヤスで注文しています。かなり豊富な種類が注文できますので、あえて他で注文して配送の数を増やすことはないです。受け取りが大変なので。

■備品類

何をどれくらい買うか?

  • 割箸:人数の約1.5倍
  • 紙皿:人数の約2倍
  • 紙コップ:人数の約1倍
  • ゴミ袋:すみません、私用意したことないです(後述)
  • ウェットティッシュ:60枚くらいあれば十分
注意点
  • 紙皿は個人用にも取り分け用にも使われるので、人数よりもかなり多めの数を用意する

どうやって買うか?

これもカクヤスに売ってるのでカクヤスで。あえて他で注文して(以下略

…と言いたいところなのですが、DevLOVE Xに関してはAmazonで注文しました。

なぜか

カクヤスの備品類は数が少ない+単価が高いです。匠塾LT大会の規模であれば問題ないのですが、人数が100を超えるようなイベントではコスパが悪いです。Amazonだと「割り箸200膳」等、業務用の大量セットが売ってますので安く済みます。 配送ですが、会場近くのコンビニなどを受け取り場所を指定しておくと自由な時間に受け取りに行けるのでおすすめです。取りに行く手間はありますが、いつ届くのかわからないという不安要素を一つ消すことができます。

落とし穴

よくある落とし穴について書きます。

配送の人はいつ来るの?

カクヤスのように配送の時間帯の幅が大きいと、いつ来るのかわからなく不安になります。事前に、建物に着く直前などのタイミングで電話をしてもらうように連絡しておきましょう。発注の入力フォームに備考欄があればそこに書いておけばOKですし、なければ発注後のメールに書いてあるお問い合わせ先にメールなりで連絡を入れておけば大体の場合は対応してもらえます。

その備品、大丈夫?

会場によっては、ゴミ袋など、会場備え付けの備品を使わないといけないことがあります。 買っても無駄になりますし、当日のオペレーションにも混乱を招きかねません。無駄なものは買わないで済むように、必要な備品に認識のズレがないか、事前に会場へ確認しておきましょう。

領収書はどこへいった?

領収書は、多くの場合は配達員の方が手渡しで渡してくれます。特に、当日の受け取りを他の人にお願いする場合、領収書をどうするかを予め認識合わせておいたほうがいいです。(一度、領収書がなくて会場中を走り回って探したことがあります。)当たり前だと思うかもですが、勉強会運営はバタバタしているのが常なので、気持ちに余裕があるうちに取り決めておきましょう。

立て替えできそう?

規模にもよりますが、中規模カンファレンスの懇親会では個人で一時的に建て替える額が数十万になることもザラにあります(DevLOVE Xのときは40万くらい立て替えてた記憶)。イベント当日は極力現金を持ち歩きたくないと思いますので、事前にカード決済しておきたいところ。ここで気になるのがカード残額です。個人的な買い物など別件で数十万使っていて、カードの残額が…という可能性もあります。立て替え能力に問題がないか、事前に確認しておきましょう。

おわりに

ふりかえりは以上となります。量については多少アバウトなところもありますが、お許しください。

DevLOVE Xにて、コミュニティマーケティングの第一人者である小島英揮さんにご登壇いただきました。その時の発表の中で、「ピザとビールで人を集めているうちは、コミュニティは成長しない」といったお話がありました。その日の懇親会に大量のビールとピザを用意していた私としてはギクリとした瞬間でした笑2

懇親会について長々と書いてきましたが、積もるところ、懇親会はイベントの目的ではないということです。イベント参加者同士をつなぐ潤滑油的な役割を担うものだと考えています。無事に開催できて、参加者が交流できていればそれで大成功なわけです。どうしても動くお金の量が多くなってしまうので、大事に感じてしまいがちですが、準備さえ済ませてしまえば、あとは参加者がどうにかしてくれます。この場を作ったのは私だ。胸を張って、あとは懇親会を楽しみましょう。


  1. https://moov.ooo/article/5d5b48d30b30b835b990a888

  2. 趣旨としては、イベントの客寄せのために無料でピザとビールを提供するような状況を想定した話し方だったので、有料イベントであるDevLOVE Xは直接は該当しません。

2019年アウトプット総括

久しぶりの更新です。

この記事は『エンジニアの登壇を応援する会』 Advent Calendar 4日目の記事です。 https://adventar.org/calendars/3934

↑のAdventerより引用

このカレンダーには、あなた自身の「今年の成長」を寄稿してください。 あなたが1年を通して行ったアウトプットを振り返り、それによってもたらされた変化や成し遂げた成長について教えてください。

ということで今回は、2019年のアウトプットについて、ふりかえっていきます。

2019年のアウトプットですが、大別すると以下の4パターンに分けられるかなと思います。(中には複数カテゴリまたいでるのもありますがご勘弁を。)

  1. コミュニティ運営
  2. 書き物
  3. 登壇
  4. 業務外コラボレーション

それぞれのパターンごとに、やったこととそのふりかえりを書き連ねていきます。

やったこととそのふりかえり

1. コミュニティ運営

やったこと

  • DevLOVE運営
  • 匠塾運営
    • 通常会
    • LT大会×2
    • 会場提供
  • Agile Japan社内サテライト運営
  • 社内サークル運営
  • 社内読書会運営

ふりかえり

運営については自分でもよくやったなと思います。時期によっては複数の運営ごとが並行で走ってキャパ超えしそうになりましたが、(睡眠時間を削って)なんとかしました。(Teck関係ないから書いてないけど、↑と並行して合唱の演奏会の運営もやってました) ただ、いかんせん力技だったので、本来はやることをもっと減らすべきだったかなと反省はしてます。

2. 書き物

やったこと

ふりかえり

冒頭に「久しぶりの更新です。」とあるように、習慣化できませんでした。これについては反省しかなく、来年は改善します。 良くなかったのはブログの更新頻度を最初から週1に設定してしまったことかなぁ。最初から達成が簡単ではない目標を立てるとうまくいかないということを実感しました。 まずは月2回くらいから始めよう。今月はアドカレをもうひとつ登録済みなので、それさえ守れば達成できるはず。

3. 登壇

やったこと

ふりかえり

小さくも、登壇する機会は確保していました。 特にIoTイノベーションチャレンジのプレゼン審査に関しては、5分間に命かけてプレゼンを作りこみ、練習を重ねたので、話すスキルはかなり上がったのではないかと思います。(プレゼンスキルだけの評価があったのだとしたら圧勝だったと思う) 残念だったのは「自分の経験を話す」機会が少なかったことです。2018年はそっち系のネタで登壇することが多かった&そっちの方向を目指しているので、そういった機会を来年は増やしていく必要があると感じました。

FlashTalk大会で紹介した日本酒【東鶴】はなかなか好評で嬉しかったです。日本酒でトークできるの良いですね。またあったら参加したい。

※東鶴酒造さんは8月の豪雨で被災しました。復興資金集めとして、クラウドファンディングを立ち上げています。FT大会のときにちゃんと宣伝できなかったので、再掲しておきます。

www.makuake.com

ちなみに、匠塾LT大会は12月も開催します。私も乾杯の挨拶がてら、匠メソッドについての紹介という形で登壇します。まだ今年のアウトプットは終わらないよー!

it-takumi.connpass.com

4. 業務外コラボレーション

やったこと

ふりかえり

年初には全く想像してなかったアウトプット(?)でした。機会に恵まれていたと思います。 他社メンバー同士で、わざわざ業務外の時間に集まって、意見をぶつけ合うのはなかなか熱量が高く、有意義な時間でした(疲れますが)。こういう活動は貴重なので、来年も何かできるのであればやっていきたいし、他の人にも経験してほしいです。

結局のところどこが成長したのか?

なんとかする能力

どうしようもない状況をなんとかする 能力がやたらついた気がします。DevLOVE Xやら、IoTイノベーションチャレンジやら、大変な状況はたくさんあったのですが、粘り強さと体力でなんとかしてきました。(もちろん、他の人の助けあってのことですが)

話すスキル

先ほども書きましたが、話すスキルはかなり上がりました。 IoTイノベーションチャレンジやFlashTalk大会への登壇の中で、事前準備をどうやればいいかのノウハウが身につきました。

懇親会を運営するスキル

DevLOVE Xと匠塾LT大会では立て続けに懇親会を運営していました。ド◯ノピザさんとカク◯スさんにはお世話になりっぱなしです。(来週もお世話になります) 注文数と余り具合を記録しているので、最初の頃よりも注文の見積もり精度は上がってきたかなと思います。 (会の雰囲気によって食べ物飲み物が減るスピードが変わっちゃう部分はありますけどね)

来年は何をカイゼンするのか?

やることを絞る

来年は勇気を持ってやることを絞る必要があると感じています。もちろん全部のことを期待されているだけやりたいという気持ちはあるのだけど、自分の作業スピードが急に倍になったり、1日が28時間になったりということはありえない。新しいことに挑戦し続けるためには何かを捨てる必要があります。

アウトプットの継続化(するために、1つの量を小さくする)

こうやって書いてると、今年は色々やってたんだなぁとしみじみ思いますが、それと同時にそれをブログという形でアウトプットできてなかったのはもったいなかったなぁとも思います。 なんで書けないのかというと、1回に書く量が多すぎるからというのが1つの原因としてあります。1つ1つのサイズを小さくすれば、書くのもあまり負担ではなくなるかな?と。

次回(?)予告

長々と書いてきましたが、以上、今年のふりかえりと来年へのカイゼン項目をアウトプットを中心に考えてみました。

もうひとつのアドカレネタでは10年のふりかえりと今後10年の方針について書きます。

そんな何度もふりかえってどうすんじゃ、と突っ込まれそうですが、ミクロ視点とマクロ視点の違いということで。

【本のスケッチノート】ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

倉貫さんの新作ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」を読みました。久しぶりですがスケッチノートも作成しました。

f:id:acnaman:20190908092830p:plain
スケッチノート

感想

倉貫さんの「ザッソウ」を広めたい!という気持ちが全面に伝わってくる一冊でした。そしてこれは確かに広めるべきだと感じました。電子書籍で買ったけど物理本を買って会社にも置こうかな…。

「ザッソウ」は新しいコンセプトではありますが、普段の仕事の中にもザッソウするシーンは含まれています。例えば朝会やチャットツールです。アジャイルソフトウェア開発宣言にある「プロセスやツールよりも個人と対話を」にある通り、アジャイルな組織だと無意識のうちにザッソウしている傾向が強そうです。 普段の仕事のシーンの例が載っている分、会社にザッソウを取り入れた後のイメージもしやすいですし、何より読み手のハードルを限りなく低くしているというところに、ザッソウを広めたい気持ちを感じます。

「おわりに」に書いてある「実は雑談が苦手だった」というのも、雑談が苦手な私にとっては勇気をもらえました。雑談がかなり苦手な人でもザッソウに取り組んでいいんだなと思うことができました。

社内で読書会を開いている身としては、読書会はザッソウの絶好の機会というのにはとても共感します。私の開いている読書会はみんなで同じ本を読むタイプではないので、本に書かれていた内容と完全一致はしないのですが、本を媒介にすることで思っていることを話したり、そこから他愛のない話に飛び火したり、また真面目な話に戻ったりと、かなりザッソウしている気がします。というわけで(?)、次回の読書会ではこちらの本を紹介しようと思います(笑)

良い本でしたので、皆さんも是非読んでみてください。

DevLOVE Xの運営を振り返る(前編)

f:id:acnaman:20190701010035p:plain

7/22〜23にDevLOVEのお祭り、DevLOVE Xを開催しました。 かなりの大盛況のイベントとなり、運営としては嬉しい限りでした。

振り返りの意味も込めて自分のやってきたことを記録していきます。

当初の想定規模

実は、DevLOVE Xをやると決めた最初のミーティングでの想定規模は違いました。 「2拠点8トラック並行100人登壇」2019年春ごろに開催 のつもりでした。1

と、決めたものの、何も進展がないまま月日が過ぎ、現実味がなくなってきたタイミングでリスケ&規模の縮小を行い、実際の開催した 「1拠点5トラック並行60人登壇」 に落ち着きました。

私のやってたこと

運営メンバーはある程度役割が決まっていて、それぞれの担当のタスクをこなす&定例ミーティングで進捗確認みたいな感じでやってました。

私はその中でも特設サイト運営、Doorkeerper対応、スポンサー対応、懇親会あたりを担当してました。

特設サイト

特設サイトはメインで担当してました。最初はある程度見た目を作って2、公開。その後は登壇者の方のプロフィールを頂いたタイミングでタイムテーブルとプロフィールを更新してました。

ちなみにサイトはWIXで作りました。Wordpressで作っても良かったんですけど、どこに立てる?という話がややこしくなってやめました。

良かったこと

手順書を作ってた

途中まで作った後に更新方法を手順書としてまとめていました。最初は手順書なんて作って意味あるんだろうかと思ってましたが、準備期間終盤でタスクが増えてきたところに強力な助っ人が参戦し、サイト更新を引き継ぐことができました。定形作業に入ったものは、手順書に残したほうが良いですね。急に忙しくなったときに、その作業を人数でスケールできるのか、できないのかは大きく違うと思います。

WIXを使い倒した

WIX Codeを有効化し、JavaScriptやデータベース機能を使ってスピーカーページを作成してました。WIXのデータベース機能だと改行が使えなかったりするので、改行データを一旦 <br> で保存しておいて、表示するタイミングのJavaScriptでテキストをhtmlコードとして読ませる3、とかやってました。

良くなかったこと

WIXの限界

WIXを使い倒した結果、サイトのスピーカーページの表示速度が遅くなるという問題が発生しました。おそらく通常利用の想定の範疇を超えていたのだと思います。こちらは開催前日に表示数を減らしたページを作ることによって突貫工事したのですが、最初に遅くなったタイミングで対策を入れるべきでした

ファビコンが入れられなかった

独自ドメインを設定しないとファビコンが設定できないというWIXの制限に引っかかりました。 独自ドメインは設定できる有料プランにはしていたものの、イベント終了後に無料プランに置き換える予定だったので独自ドメインを設定していませんでした。ファビコンがないとSNSシェアしたときなどにちょっと残念な表示になってしまったりするので、気がかりでした。

Doorkeeper対応

Doorkeeperの更新、問い合わせ対応などをやってました。

良かったこと

特設サイト担当との親和性

特設サイトとDoorkeeperを両方触れるのは私しかいませんでした。なので、何の情報をどの媒体で発信しているのか、ということについては私が一番詳しかったです。

Doorkeeperの機能に詳しくなった

Doorkeeperのイベント管理画面の機能についてはだいぶ詳しくなった気がします。 今回は「チェックイン」機能を本格的に利用して受付の省力化を行ったり、参加費の集計を管理画面が自動生成してくれたりと、かなりDoorkeeperの機能に助けられたところがあります。

良くなかったこと

決めごとの公表が後手に回った

今回は初めて1万円という安くはない参加費を頂いて開催をしておりました。そのため、参加者の方からいろいろなご意見・お問い合わせをいただくことがありました。ほとんどのお問い合わせは、初めにルールを決めてはっきりとサイトに明記しておけば回避できた問い合わせでした。 こういった決めごとは、早めに決めておくのがベストではあるのですが、運営メンバーも運営に慣れているわけではなかったということと、どのような問い合わせが来るかというのは最初から全て予測するのは不可能という風に考えると、なかなか難しかったのかな、とも思います。

他の役割についても書きたいのですが、やたら長くなってしまいそうなので、ここらで一旦区切ります。また次回に。

とある並行世界の元号対応奮闘記

「新しい元号は、レイワであります。」

官房長官がそう発言するのを、テレビを囲ったたくさんのチームメンバーが見つめていた。

私たちは帳票を扱うシステムの保守開発チームだ。お客様のシステムで出力する帳票には和暦を用いた日時表記がある。そのため、この数ヶ月をかけて、新元号に対応するためのシステム改修を行ってきた。和暦変換の処理は、システム内で直接処理しているもの、帳票ツールの処理を使ったものなど、帳票によって別れていた。改修はそれなりに大変だったが、なんとか3月中にテストを終え、いくつかの設定ファイルを発表された新元号に変更するだけで良い、という状態だった。

「え、今なんて言った?」

「エイワ?とかそんな感じ?」

「頼むから簡単な漢字であってくれ…!」

次の瞬間、官房長官は伏せていた額縁を上に揚げた。

*1

これを見たチームメンバーは安堵の表情を浮かべた。

「命令の令に、平和の和だって」

「あー、レイワ、ね。」

「よかった、小学校でも習う簡単な漢字だ。」

元々、どんな新元号になるのか、というのは世間で度々話題になっていた。様々な予測が飛び交う中、「漢字二文字である」「書きやすく、読みやすいもの」「イニシャルがMTSHではない」など、条件もありそうだ、という噂もされていた。

ただ、これらはあくまで噂に過ぎなかった。当日になっていきなり3文字の元号が発表されたら、日付を固定長で確保しているDBの改修が必要になる。難しい漢字が使われていたら、SHIFT_JISでの処理を捨てきれていない一部のモジュールで扱えないかもしれない。そんな不安を抱えていた。(想定外の文字に対応するところまでは、流石にコストパフォーマンスが悪いということで見送っていた)

だから、「令和」という2文字かつ簡単な文字の組み合わせで構成されている新元号を見て、みんなホッとしたのである。

官房長官の発表会見を見終わったチームメンバーは、それぞれ自席に戻り、各々に割り振られていた新元号の対応作業を始めた。 新元号の設定ファイルを発行し、それぞれのサーバーに配置。午後からテストに入る予定だ。

作業は順調に進み、午後から新元号対応部分のテストが始まった。

テストを初めて数時間後のことだった。

「なんかちょっと違うよなぁ?」

そう声を上げたのは新人のSくんだった。心配になった私は、Sくんに話を聞いてみた。

「発表された『レイ』の文字と、帳票に印字されてる『令』の字形が違うんすよね。これ大丈夫ですかね?」

Sくんの主張は正しかった。昼に発表された「レイ」の字は、下の部分が「点+マ」になっていたが、帳票上には「横棒+アみたいなやつ」の形の「令」が印字されている。

Sくんには、とりあえず文字の違いは一旦無視してテストを続けるように伝え、私は2つの文字の違いについて調べることにした。

調べたところ、2つの文字は単に書体が違うだけであって、基本的には同じ漢字らしい。*2

「同じ漢字なのであれば、まぁ、大丈夫だろう」と思い、少し安心した。念のため、上司に報告することにした。上司からは次の答えが返ってきた。

「一応、発表どおりの文字で表示できないか、調べてもらえるかな?」

面倒なことになった。このテストさえ終われば元号対応は無事終了となるのに、書体の違う文字が表示できるかどうかの調査とは。しかし、文句ばかり言っていても仕方ない。調べよう。

調査には数日を要した。何ぶん知見のない分野だったため、思っていたよりも時間がかかってしまった。

「令」の書体を変えて見せる方法はどうやら以下の3通りの方法がありそうだという結論に至った。

  1. フォントを変える
  2. 外字を利用する
  3. 異体字セレクタを使用する

1は、使用しているフォントを変更するというもの。フォントの中には「点+マ」の令の字を表示してくれるものがあり、そのフォントに切り替えれば表示も変わる。 他の令の字も変わってしまうのが懸念ではあるが、フォントを変える対応だけで済むため、他の2つよりも工数が少なくて済みそうだ。だが、「点+マ」の形式で出力できるフォントのライセンスについては別途調査が必要だ。

2は、外字として令の字を登録し、それを帳票に埋め込むというもの。方法として存在することは理解したが、クライアントでの表示がどこまで担保できるのかが怪しい上に、検索性も落ちるのであまり得策ではない。

3は、異体字セレクタと呼ばれる情報を付与することで文字の見た目を変更できるというもの。対応しているフォントは多くないが、1つのフォントで両方の「令」を表現できる。一応、「IPAmj明朝」というフォントが対応しているらしい。 しかし、この異体字セレクタが鬼門で、「令」の後にUnicodeの「U+E0102」に該当するコードの文字を出力する必要がある。「U+E0102」はサロゲートペアとかいう技術を使う必要があるらしく(?)正直良くわかんなくなってきたので一旦ここで調査をやめた。

私は、これらを踏まえた上で、やはりここは対応無しとしたいことを上司に告げた。上司は納得し、事なきを得た。

2週間後、政府から発表があった。「新元号名で使用する文字コードについて(周知)」と題された文書が公表されたのだ。*3

資料には以下の記載があった。

元号で使用される文字である「令」及び「和」に対応する文字コードは、以下の通りと考えられます。
JIS X 020846区 65点4E61(JIS)97DF(シフト JIS)
JIS X 021346区 65点4E61(JIS)97DF(シフト JIS)
ISO/IEC 10646U+4EE4
(中略)新元号で使用する文字を情報システムで扱う際には、上記の文字コードを用いることが推奨されます。

勝った、と思った。政府発表の中で「令」の文字コードが明示されたのだ。設定ファイルに記載した文字コードとも合致している。

こちらの資料も、念のため上司に報告した。上司はこう言った。

「この下の説明は読んだ?」

下の説明?最初は何を言っているのかわからなかった。よく見てみると資料の下部に以下の説明が書いてあった。

「令」の文字に関しては、上記の文字コードのほかに、Unicode において、U+4EE4 に続けてU+E0102 の文字コードを使用することで、元号発表時の令󠄂󠄂󠄂󠄂の文字を表現できます。フォントにも依存しますが、こちらの表現が相応しい場合にはこちらの文字コードを使用することも推奨されます。*4

不覚だった、読んでいなかった。

「どう…しましょうか?」

「まぁ今回の場合はいいんじゃないか?E+U0102 無しの表現に関しても推奨されているわけだし。お客さんに説明してみるよ。」

数日後、上司が顧客に事情を説明した。説明用の資料は私が作成し、打ち合わせにも同席した。顧客には内容を了承いただき、この問題は今度こそ収束した。

私の場合は上司や顧客に理解がある職場だったから良かったものの、この問題に苦しんだSEは、少なからずいるのではないだろうか。その人たちはきっとあの額縁の文字を書いた人を恨んでいるんだろうなぁ。

※この物語はフィクションです。登場する人物・団体・名称等は架空であり、実在のものとは関係ありません。

*1:しょぼい字ですんません

*2:みなさんは学校でどちらの漢字で教わりましたか?私は「点+マ」でした。

*3:現実世界の資料はこちらhttps://www.meti.go.jp/policy/it_policy/kaigen/20190405_kaigen_code.pdf

*4:この記載は現実の資料にはありません