Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

ルールは勝手に浸透しない

何かの反省を活かしてルールを決めることはよくあるが、ルールが勝手に浸透することはまずないと考えておいたほうがいい。まれにスッと馴染むこともあるが、浸透しないものだと考えておいた方が無駄にイライラしなくなるのでオススメ。

たとえば、ミーティングの前にアジェンダを作って目的とゴールを明確にしましょうと決めても、なかなか守られず効率の悪いミーティングが続くみたいな。浸透させるのに重要なのは、根底の課題の認識を揃えることと、口うるさく言い続けることの2点である。

そもそも課題だと感じていないと無用なルールとみなされて守られない。なんでルール決めてるのにちゃんとやらねえんだと思ったら、まず認識が合ってるのか確かめたほうがいい。その上で、口うるさく言い続ける役を作っておく必要もある。ルールが浸透するまでは、誰かがリードしなければならない。ちなみに自分はこの役割を伝道師またはオカンと呼んでいる。状況に応じて、チームに1人オカンを配置しておくと浸透しやすい。

オカンの役割は言う方も言われる方も結構つらくて、イライラして無駄な軋轢を生みがちなので、最初にコストかけてでも自動化してbotにやらせるほうがよい。毎週のリマインドならSlackのリマインド機能使うとか。Zapierで組めることも多い。botがやると角が立たないのだ。

ルールは勝手に浸透しない。浸透するまでは誰かが頑張る必要がある。メチャメチャ苦しい壁だって ふいに なぜかぶち壊す 勇気と POWER 湧いてくるのは メチャメチャきびしい人達が ふいに 見せた やさしさの せいだったり するんだろうね。ありがとうございます

天気の子見てきた

一回見ただけだけど、ネタバレ1000%で走り書く。雑に書くだけだから怒らないで。

  • 俺は好き
  • あらゆる妄想をぶち込んだような心地よさがある
  • 家出からの住み込みバイト、年上のセクシーなお姉さん、逃走劇、ラブホで一泊。もちろん本筋もよかったけど散りばめられた設定が中ニ心をくすぐるというか、とにかくよかった
  • 帆高の事情が深く触れられてないところも、現在の物語に集中できてよかった
  • 声最高。小栗旬と本田翼がクッソよい
  • さるびあ丸で神津島行ったことあるし、池袋の北口もよく行ってたし知ってる場所多すぎた。聖地巡礼したい
  • 最後の雨に沈む街、過去作を彷彿とさせる感じでとてもよかった
  • 帆高のキリト感
  • 君の名は。主要キャラめっちゃ出とった。花火大会の時のアナウンスの声よかったねぇ
  • カナとアヤネ!!!名字に花澤って出てきてワロタ
  • 新海監督のアイコンがマグストラップになって出とったな
  • 四葉ーーー!!!
  • 帆高が階段を駆け上がるところ、クレヨンしんちゃんの大人帝国を思い出した
  • 小説で証言として語られてるところがテンポよく音楽に載せて映像になっててワクワクした
  • いったいどれだけの研鑽を積めばこんな映像を作れるのかと勝手に想像してオープニングの時点でちょっと泣いてしまった
  • 夏美や須賀、帆高とそれぞれの立場と悩みが少しずつ表現されていた。このへんは小説で心情を補完したい
  • いろいろ裏の設定を補完してもっかい見たい

息子氏爆誕とリモートワーク

産まれて早2週間ほど経ち、ブクブクと成長を続けている息子氏。

7/4の朝、嫁氏と「もうすぐ産まれるかもね〜」などと談笑しながら出社。出社後10分くらいで今日産まれると連絡があり即退社。全てのタスクもミーティングも放り出して速攻で病院に行った結果無事立ち会えたので、フォローしてくれた同僚氏には大変感謝している。

出産報告後、たくさんの方からKyashでお祝い投げ銭をいただき、最新型のベビーカーが買えるくらいの残高になった。何かお祝いごとがあった時にお返ししたい。面識のないKyashユーザーやFintech協会の方からもお祝いが届いたのには驚いた。最近はいろんな意見を見るのが辛くてKyashエゴサもしなくなってしまっていたので、とても嬉しく優しい気持ちになった。送金機能をもっと磨いていきたい。

Kyashでは、長期のリモートワークを認めてもらえることになった。嫁氏がここ数年体調を崩していること、子育てを手伝える親族も近くにいないことから、当面は週1出社、週4リモートで働く。もともとリモート制度はなかったが、事情を鑑みて認めてもらい来週から開始である。いやー正直不安だね。もともとリモートで働くより出社した方が成果を出しやすいし、デスクのすぐ右で息子氏が寝てる環境で集中できるんだろうか。10日くらい休みをもらっている間に色々試してみたけど、生産性6割くらいになりそうな気がする。リモートワークはリモートする人だけではなく会社全体で慣れていく必要があるので、少しずつ改善していきたい。うまく情報を拾えずストレスに感じることもあると思うけど、そういうのを解消するために週1は出社することにしている。まあいい機会だし、せっかくなのでKyashのリモート制度をブラッシュアップしていきたい。

育休も何やら制度ができるらしい。メル社みたいに2ヶ月育休で給与全額払いとかは無理だけど、社員のライフイベントに合わせて少しずつ制度を整えていってくれるのはとてもありがたい。思えば、自分が入社した時は有給も即時付与ではなかったけれど、今は入社即時付与されるようになっている。声をあげてちゃんと説明すれば変えていけるし、多少進みが遅いと感じることはあるけれど、そういうコントローラブルな領域が多いのは助かる。余談だが、今後は海外でのイベント登壇時の補助についても制度を整えていけると大変嬉しい。

いやー来週からどうなるかなー。同僚氏がとても優秀なので、リモートだと自分がどこで成果を出せばいいかわからなくて辛くなりそうな気もするなー。不安だなー。まあプランニング次第な気もするのでそのあたりはうまく進めていきたい。がんばるゾイ。

最後にお決まりのこちらを載せておきます。

kyash_id: konifar

あと欲しいものリストはこちら   https://www.amazon.co.jp/hz/wishlist/ls/3N2DZ8IZ9ONUM?ref_=wl_share

納得感のある決定事項の共有方法

意思決定の場にいない人に対して決定事項を共有する際、いくつか気をつけておくといいなぁと考えていたことを雑にまとめておきたい。

  • 決定する前から進捗をちょっとずつ共有しておく
    • 決定前の話なので後の祭りかもしれないが、いきなり結果をドーンだと相手を戸惑わせることがあるので事前に議事録を共有したり中間で説明する機会を作ったりするとよい
  • 背景と前提条件を伝える
    • なぜやるのかわからないまま結果だけ共有すると納得してもらいにくい。決定する上での前提条件を知らないと余計な反発をうむこともあるので注意が必要。それまでずっと考えてきた当事者は気づきにくいが、びっくりするくらい前提知識が違うことがある。相手は何も知らないものとして、イチから説明した方がよい
  • 決定までの経緯を伝える
    • 結論より経緯の伝え方が重要。どのような議論があってそんな決定になったか、完結に伝えましょう
  • 捨ててきた選択肢も伝える
    • 結果に至るまでに、考えたけどやめた案があればそれも軽く触れる。「考えた上でその結果なのだ」ということを簡単に伝えるだけで納得度合いがだいぶ変わる
  • メリット・デメリットを整理して伝える
    • 決定事項のデメリットが目立つ場合、整理して伝えるとよい。「当然デメリットも考えた上で決めている」ということを先回りして伝えてあげると無駄に不安にさせずに済む
  • 不安の解消案も一緒に伝える
    • 決定方針自体は理解してもらえても、「本当に大丈夫かな」と漠然とした不安が残る場合がある。そういった不安を先回りして想定し「こういう懸念は残るので○日までにブラッシュアップして詳細を詰める」といった感じで次の打ち手まで伝える。できればいくつかドラフト案を用意しておくとよい

内容が被ってるものもあるけどだいたいこのあたりを抑えておけば大丈夫そう。これ以外のところで納得できていないケースは、たぶん何かしらもっと根深い組織課題があるので今回は触れずにおく。

決定事項を共有されてなんだか腑に落ちない時は、だいたい背景や前提条件を理解できていないのだ。何かを決定する当事者はまわりの10倍くらい色々考えて決めているはずなので、伝え方の問題で納得してもらえないのはもったいない。

納得感なく何かが決定されてると感じると、すごく憤りを覚えて反論にも熱が入ってしまうことがある。そういう時はたいてい伝える側の説明不足か聞く側の想像不足である。上記のどれが抜けてて納得できないのか落ち着いて考えた上で話を深掘りしてみると意外とすっと納得できるかもしれない。何かを決定するのはとても疲れることなので、共有される側は優しく包み込むように聞くように意識しよう。

決定事項を共有する側もそれを聞く側も、相手への敬意を忘れずに。そして、次の曲が始まるのです。

タスクの目的と担当と期日を決めろ

世の中当たり前のことが一番難しい。

どんな粒度のタスクであっても必ずやらないといけないことがある。

タスクの目的を明確にして、責任を持つ担当者とケツの期日を決める

これだけだ。「いやいや他にもあるでしょ」と言われるかもしれない。うん、あるよ。実際にタスクを終わらせるにはいっぱいやることあるよ。完了の条件を決めたりやることを明確にしたりアサインを決めたりチェックポイントとなる日付を設定したり色々あるよね。けどそれらは全部担当と期日を決めてからの話だよね。

目的を明確にして担当と期日さえ決めさえすればだいたいのことはうまく進むはずなのに、それすら決めてないせいで全然進まないみたいなことあるよね。タスクを前に進めたければ、とにかく目的と担当と期日を決めろ。話はそれからだ。アデュー

職場での挨拶の是非について

職場での挨拶の是非の話題は、もはや半年に一回くらい訪れる風物詩と言っても過言ではない。

この話は自分の中では明確に答えがあるので雑にまとめておく。

まあどっちでもいいよね!!!

こんなしょうもない話で物申す必要あるのは高校生までやろ。会社は学校じゃねえんだよ。

というシャウトは置いといて、仕事する上で効率がよくなると思うなら挨拶すればいいし、そう思わないならしなくていいってだけだよね。もしチームで仕事してるなら、やはり普段の雑談は多い方が仕事しやすいと思うよ。挨拶もなしに雑談するのってめちゃくちゃハードル高くない?むしろ挨拶って定型文を発声するだけで最低限のコミュニケーション取れるしめちゃくちゃ楽じゃない?

さして意味のない定型文をわざわざ発声しなきゃいけないのが嫌だって人もいるかもしれない。たしかにチームによってはそうかも。そういう場合は挨拶しても特に効率よくならないからしなくていいと思う。挨拶以前の組織課題なので、まあなんていうか頑張ろう!!

そういうのを何とかしたくてまず挨拶から始めようみたいな動きが、もしかしたら「挨拶の強制してくんなよ」みたいに捉えられるのかもしれない。そういう場合は、まず課題の認識をチームで揃えたほうがいいのかもしれない。実は問題に思ってない人がいる中で解決策だけ出すと反発が起きやすいからね。

挨拶だけじゃなくて、絵文字を使うとか言い回しに気をつけるとかそういうの全部仕事が効率化されると思うならやればいいし、そうじゃないならやらんでいい。

例えば、個人で集中して進める仕事がほとんどで挨拶すると逆にめちゃくちゃストレスがかかって効率落ちるっていうならしないほうがいいよね。ちなみに自分は挨拶するかしないか判断する方がめんどくさいし、今まで挨拶して特にマイナスに働いたことはないし、雑談のきっかけとしてはめちゃくちゃ楽でチームで働く上でやったほうがいいと思うから挨拶はしてる。

自分の価値観なので人に押しつける気はないし、仮に強制するなら意図をちゃんと話して合意を取ろう。感情論に頼らず、無駄に語気の強い言葉を使わず、物事を説明できるようになろうな。それができないならとりあえず子供の頃の教えにならって挨拶くらいしとけばいいのでは。

Google I/O真っ只中に俺は何を書いているのか。

みなさん、おはこんばんちは!!!

韓国では日本ほどAndroidにKotlinが浸透していないらしい

韓国のDroidKnightsという大きめのカンファレンスに参加してきた。

「Is Kotlin necessary for us?」みたいな感じのタイトルのセッションが満員御礼でちょっと意外だったので、韓国のKotlin事情についての考察の話をしたい*1。一応先に言っておくと、遅れているとか言うつもりは全くなくて、何が違うのかと思って色々聞いてみたことをまとめただけである。

f:id:konifar:20190405232845p:plain

(韓国語だったのでGoogle翻訳で日本語にしている)

なぜ意外だったかというと、2017年にGoogleがKotlinを公式に採用するとなって以降、日本ではこういった話はすでに話しつくされてKotlin当たり前やろみたいな空気になっていると感じているからだ。現地に「何で開発してる?」的なアンケートボードがあったので見てみたが、たしかに日本よりもJava比率が高い気がする。カンファレンスに来るような人たちという意味では同じなので、やはり少し違いがあるように思う。

f:id:konifar:20190405232908j:plain

もしかしたら参加者の層にもよるのかもしれないが、実際に現地の人と話してみると 「うーん、そんなにめちゃくちゃ浸透しているわけでもないね。Javaでいいじゃんみたいな空気がある」とのことだった。retrolambdaを使ってJava8対応して書いていることが多いらしい。Kotlinを採用しないので当然Coroutineの話もそこまで盛り上がってはいなかった。

なぜKotlinが浸透してないのかと聞いてみたところ、「たぶんサーバーサイドも含めてJavaが根付いているからじゃないかなー」という話だった。韓国では、国が企業に発注する仕事というのが結構あって、そのサーバーサイドはSpringフレームワークを拡張したものを使ってJavaで書くことが多いらしい。国が発注して作ったものは、運用中に言語を変えるような変更をすることはまずない。余談だが、韓国では銀行や政府関係のサービスなどはIE10じゃないと動かないサービスがいまだに多いらしい(全体の50%くらいのサービスはIE10をサポートしていると言っていた)。

加えて、Kotlinはビルド時間が長くなるといった部分についての懸念もあり、 「Javaのままでいいじゃん」という意見がまだ多いとのことだった。サーバーサイドKotlinの話も、自分が話したかぎりだとまったく聞かなかった。

たしかに、慣れているものを変えるのはパワーが必要だ。不便さというのは、便利なものが当たり前にならないと気づけないことも多い。しかし、その話で言えば日本でも同じようになかなかKotlinが浸透しないはずである。かくいう自分も、結構長いことKotlinを様子見していてなかなか採用しなかった。何が状況を変えたんじゃろかと思いながら話していたら、ひとつこれかなーと思う話があった。

それは「韓国では日本に比べてコミュニティ活動がかなり少ない」ということだ。東京のAndroid界隈だと、shibuya.apk、potatotips、kyobashi.dexをはじめ、様々なmeetupが毎月のように開催されているが、韓国ではほぼないそうだ。じゃあどこで情報収集しているのかと聞くと、Googleのブログを読んだり動画を見たり本を読んだり、日本語ができる人はDroidKaigiのYouTubeを見たりして、自分でブログにまとめて発信しながら勉強しているらしい。すごい。Androidの膨大な分野をそんなふうに個人戦でキャッチアップできるのすごすぎる。

日本では、@satorufujiwaraさんや@ngsw_taroさんがかなり早くからKotlinについて色々とよさを語っていたし、@shiraj_iさんもKotlinのContributeについての話をして盛り上げていた。コミュニティがあると、こういった主張の流れを加速させ、パッションとともに多くの人に伝えられるのだろう。もちろん個人で知見を共有しまくっているだけでも意味はあると思うが、JavaからKotlinのようなドラスティックな変化を浸透させていくには、コミュニティがあった方が加速しやすいのかもしれないと思った。まあ自分が何人かと話して感じただけなので何の確証もないのだけれども。

DroidKaigiの雰囲気をみると、おそらく非同期通信まわりがRxじゃなくCoroutineを使うのが多数という状況になるのもすぐなんだろうなと思う。一方、韓国ではMVPやMVVMといった設計の基盤となるDataBindingやRxについては結構深く議論されていて、なんだか別の世界線を見ているようで興味深かった。カンファレンス全体の感想はまた真面目な方のブログで書きたい。→かいた。

[2019/04/06 (土) 0:25 補足]

色々トレードオフを考えた結果、今はまだKotlinに移行しないという判断をしている人が多いのだという話なのかもしれない。DroidKnightsに登壇している人たちはいわばアーリーアダプターで彼らはKotlinを使っているだろうとのことだった。もしかしたら600人くらいの参加者の中ではJavaの方が多数だったという話なのかもしれない。あるいは、自分が住んでいる東京のコミュニティやSNSの中での割合と比較して考えると違うというだけかもしれない。 韓国日本 というくくりは雑すぎた。申し訳ない。

*1:自分の聞き取りの間違いもあるかもしれないです。間違っていたらごめんなさいすぐ修正します