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

息子氏爆誕

— こにふぁー (@konifar) 2019年7月4日

産まれて早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倍くらい色々考えて決めているはずなので、伝え方の問題で納得してもらえないのはもったいない。

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

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

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

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

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

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

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

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

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

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

「みんなに挨拶をする」がちゃんとリストに入っているのは、多分ドーシーさんが意識しないと挨拶出来ない人だからだとは思うのですが、一部のエンジニアさんもマジでこういうリストを朝読んでからご出社頂きたいですなｗ😅

「関係性ができていれば挨拶なんて不要」論は一体誰が唱え始めたのか…ｗ💧 https://t.co/pmpds8TSUF

— 勝又健太@テック系YouTuber (@poly_soft) 2019年5月7日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

もしかしたら参加者の層にもよるのかもしれないが、実際に現地の人と話してみると 「うーん、そんなにめちゃくちゃ浸透しているわけでもないね。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の方が多いと思いますよ。

— Pluu (@pluulove) 2019年4月5日

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

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

うまくフィードバックをもらうためのTips

春だ。初めてソフトウェアエンジニアとして働き始めた頃、いつも機能のレビューで突っ込まれまくって涙目になっていたのを思い出した。今ならそんなことにはならないので、意識していることを雑にまとめておこうと思う。

今の状況を最初に伝える

ざっと考えた仕様や、とりあえず作ってみたプロトタイプを見てもらおうとしただけなのに、めちゃくちゃ細かい部分まで突っ込まれて「あー今そういう感じじゃないのになぁぐぬぬぬ」となったことはないだろうか。これを防ぐには、最初に今の状況を伝えて認識を合わせておくとよい。

• 「先に今の状況を伝えておくと、まだ完成度は20%くらいです」
• 「まだ叩き台なのでアラも多いと思うんですがとりあえずざっと作って持ってきました」

みたいな一言があるだけでもだいぶ違う。大事なのは、これを最初の説明で自分から言うことだ。意見をもらい出すと相手も白熱してきてなかなか言うタイミングが難しくなることがあるので注意が必要である。

どういう観点で指摘がほしいかを伝える

「フィードバックをください」とだけ言うよりも、より具体的にどういう観点で見てほしいか伝えておいたほうがよい。そうしないと、無限に白熱して収集がつかなくなることがある。

• 「今日はまず大きな方針について問題なさそうか確認してほしい」
• 「細かい仕様の部分はまだ詰められてないので、そういう方向に話が進みそうになったら一旦切ります」
• 「いろいろツッコミどころはあると思いますが、今日はユーザーサポート観点で問題ないかフィードバックが欲しい」

みたいな感じで伝えておくと、想定していなかった方向からツッコミを受けまくってぐるぐる目になることもないはずだ。

目的を再確認して流れを戻す

最初に認識を合わせていても、細かい枝葉の議論になってしまうことがある。そういうときはいったん流れを元に戻さなければならない。これは目的をちゃんと明確にしておかなければならないし、ファシリテーションのスキルも必要になるので慣れないと難しい。そういうのが得意な人に事前に相談して、「なんか変な方向で白熱しだしたら方向修正できるよう発言してほしい」と伝えておくのも手である。

• 「今日はいったん全体のフィードバックをひと通りもらうところまでやりたいので、次いきますね」
• 「そこはたしかにちゃんと考えた方がいいので、今日は宿題にして後で自分が叩き台作ります」

みたいな感じだろうか。状況によるが時間を見ながら流れをコントロールする必要がある。流れを汲めずに発言をしがちな人に対しては、先に軽く話しておくとよいかもしれない。

礼を言って潔く立ち去る

そもそも論みたいな話になってしまって空気がやばくなることはよくある。要は、思ってもみない方向に話が進んでツッコミサンドボックスと化し、フィードバックどころではなくなるみたいなケースだ。

そうならないように想定して準備するのが大事なのだけれど、もしもそういう空気になった時は、潔く終わりにしたほうがよい。

• 「最初に言っておくと、あまりにも方向性がまずくてヤバい空気になったら5分で終わって出直します」
• 「たぶん今この状態から議論しても時間内にまとまらないので、自分が持ち帰って考え直します」

みたいな感じで伝えて、シュッと立ち去るのだ。それはそれで空気が変な感じになっちゃうんだよなという人は、「すみません、けど今の段階でフィードバックもらって修正できるのでよかったです！ありがとうございました」といった具合にお礼だけきっちり伝えるとマシになるかもしれない。

---

この話だけ見ると小手先のやり方に見えるかもしれない。そうだよ！！！けどちょっとした工夫でいい感じの雰囲気で効果的にフィードバックもらえるならそっちの方がいいよね。あと、このへんの話を意識すると、自然とちゃんと想定して準備することになると思うので、まあ悪くはないと思う。

自社のことを紹介する文章のレビューについて

今日も今日とてインターネッツは騒がしい。今日はたくさんの人がラグビーになっていた。

style.nikkei.com

『GAFA』『ラグビー』『乱入』という本来混じり合うはずのない言葉のハーモニーに、インターネッツの住人の心がコチョコチョとくすぐられたのだ。しかし、こんな真偽も実際の状況もわからないような話自体をいくら話題にしても不毛である。こういう話題は明日は我が身と考えて、学ぶべきことを探した方が生産的だ。ここで学ぶべきことはひとつで、「自社やチームのことを紹介する文章を公開する前にどういう観点でレビューすればいいのか」ということである。

まあ今回の話について言えば外部のメディアなのでレビューできなかったみたいな事情もあるのかもしれないが、自分が普段社のブログレビューで指摘しているポイントを雑に書き出しておく。

読者との間に温度差がありすぎないか

• 温度感をもった記事はそれはそれでよいが、ありすぎると危険
• 内輪感を不快に思う人もいるので、自分たちを持ち上げすぎないバランス感が大事だったりもする

言葉だけで誤解されない表現になっていないか

• 言葉だけだとどうしても正確に状況を伝えられない可能性もある
• 例えば楽しさや盛り上がりは効果的に写真を使ったりしないと伝わらないことが多い

インターネッツで拒否されやすい表現をつかっていないか

• 「いかがでしたでしょうか？」とか
• (笑) みたいな語尾の表現も危険な場合もある

背景の説明が十分か

• 育ってきた環境が違うので、背景をちゃんと説明しないと伝わらないこともある
• 背景を共有しないと変なところで噛み付かれたりするので注意が必要

複数の読み手の視点で読んでみても問題ないか

• 社員、ユーザー、知り合い、投資家、パートナーなど色々な人が読む可能性がある
• 事実と違うことが書いてあったり、前置きが足りなかったりしないかチェックした方がよい

機能など専門用語に揺らぎがないか

• 社内用語になっていたりとか
• この辺はTextLintでチェックしたい

肯定表現できる部分がネガティブな否定表現になっていないか

• 基本的に肯定表現の方が読んでいて気持ちがいい
• ここもLintでいい感じにできるかもしれない

日付に曜日が入っているなどフォーマットが同じか

• Lintだね

---

あのラグビーもさ、本当はみんなニコニコ楽しくやってるかもしれないし、あの施策によって普段の雑談が増えて仕事しやすい雰囲気になってるかもしれないよね！施策自体は良し悪しわからんよね。悪かったのは、良し悪しわからんような記事を公開しちゃったところだけだよ。そもそもGAFAの話と絡めてあの話が必要だったのかという観点もあるけど、ラグビーボール持ってニコニコしている写真とかが2〜3枚あるだけでだいぶ印象変わってたと思う。

インターネッツは馬鹿っぽい人に厳しい。馬鹿ではなく馬鹿っぽい人に厳しいのだ。自社のことを紹介するときは、馬鹿っぽく見なされないように最低限のレビューが必要。私からは以上だ。

あわせてよみたい。

konifar.hatenablog.com