Konifar's ZATSU

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

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

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

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

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

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

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

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

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

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

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

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

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:自分の聞き取りの間違いもあるかもしれないです。間違っていたらごめんなさいすぐ修正します

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

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

今の状況を最初に伝える

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

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

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

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

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

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

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

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

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

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

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

礼を言って潔く立ち去る

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

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

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

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


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

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

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

style.nikkei.com

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

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

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

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

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

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

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

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

背景の説明が十分か

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

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

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

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

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

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

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

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

  • Lintだね

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

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

あわせてよみたい。

konifar.hatenablog.com

何で成果を出したいかを共有して期待感の齟齬をなくす

zatsuというブログ名に恥じぬよう雑に考えを書いておく。

チームで働くときは自分がどこで成果を出そうと思っているかをちゃんと言語化して共有しておくとみんな幸せになりやすい。EMやPMなど、個々人が思い浮かべる役割のイメージが違う場合は特にやっておいたほうがよい(念のため書いておくと、いま一緒に働いている同僚氏にめっちゃ不満があって書きなぐっているとかではない)

仕事に限らず、ほとんどの人は気づかぬうちに他人に何かを期待していることが多い。一方的な期待に対して成果が足りないと感じるとストレスがたまり、それが積み重なると信頼関係が崩れていく。

あの人にはもっとこういうことしてほしいとか、私ならこうするのにとか、頭の中で勝手に期待して勝手に裏切られるのは不毛だ。イライラしている様子は相手に伝わるが、相手からするとなぜイライラしているかわからないことが多く、めんどくさい大人の関係が始まってしまう。

そういった期待感の齟齬にイライラしてるなと感じたら、すぐに相手に直接伝えるべきだ。ただ、イライラした状態だと理性的に言語化してコミュニケーションを取れない人もいる。つまり、そういった状態になってからでは遅いのだ。

防止策として、何で成果を出したいと思っているかを先に周囲に共有しておくとよい。期待感の齟齬にイライラする前に最初に潰しておくのだ。組織内で個人の目標設定をするフローがあるのであれば、その目標を公開しておくだけでも効果はあるかもしれない。

マネジメント層であれば、マネージャーという役割をどう捉えているかとか、何に責任を持って何に取り組むかといった話を文章にして共有するとか、すでにやっている人はたくさんいると思う。たとえば「組織のマネジメントはノータッチで、ひたすら技術的なリードをやる予定です」みたいにやることとやらないことを話しておくと、周りもそういうスタンスで接する心構えができるのでお互い楽になる。周囲からの期待の齟齬がなくなることで本来やるべきでない仕事を抱えることも減り、成果を出すべき仕事に集中できる。

ちなみに今の自分はどうかというと、ちゃんと伝えられていない気がする。あまり範囲を限定したくはないけれど、少なくともこの領域では120%の成果を出しますという話を来週にでもチーム内で共有しておこうと思う。

余談だが、自分が朝起きたときに猫のトイレ掃除をしなかったことが続いて、最近嫁氏の機嫌が悪い。これは自分が100%悪いのだけれど、こういうのも期待感の齟齬によるものなのかもしれない。

行動の優先順位

当人としてはよく考えて選択して行動や言動なんだろうなと納得しつつも、なんだか自分とは相入れないなと思うことがある。

どういう話でそう感じることが多いかとふと考えてみると、大きなスケールのことを考えた行動に対してかもしれない。

例えば、とある業界全体の意識を変えたくて書いた記事だったり、人類全体のことを考えて起こしたデモだったり。当人は外野の10倍は物事を考えているものなので、様々な懸念は考慮した上で選択した行動なのだろう。しかし、その熟考の果てに取った行動がそれなのかと考えてしまうことがあるのだ。身近にいる人に対する影響よりも全体のことを優先するのだなというか。うまく説明できないけれど、行動の優先順位のつけ方が矛盾していると感じてしまうことがある。Fate/Zeroの切嗣くらいいけば逆に清々しいのだけれどね

Slackでよく使うフレーズ

自分がSlackやオンラインでよく使うフレーズをメモしておく。他の人のも知りたい。

「質問です! :raising_hand:」

  • 質問をしたい時に最初に書く
  • 例) 質問です!これって○○ということですか?

「進捗です」

  • ひとまず進捗報告する時に最初に書く
  • 例) 進捗です!結論から言うと1日分くらい遅れてます :bow:

「just ideaですが」

  • ポッと思いついたアイデアを伝えたい時に最初に書く
  • 例) just ideaですが、○○というのはどうでしょう?

「間違ってたら指摘してください :pray:」

  • 誰かの考えられた意見に対して意見を言う時に書く
  • 例) これって○○の方がいいかもと思ったんですがどうでしょう?間違ってたらすみません指摘してください :pray:

「:cool:」

  • よいと思ったときに最初に書く
  • 例) Cool :cool:

「念のため確認です!」

  • 相手もすでに考えてるであろうことに対して何か言うときに書く
  • 例) もうすでに考慮済みかもしれませんが念のため確認です!

「天才なので」

  • いいことをした時に最初に書く
  • 例) 天才なので今のところクラッシュフリーレート100%です(不安)

「オッ」

  • オッと思った時に最初に書く
  • 例) オッすみません、すぐ見ますね

「流石です!」

  • 流石だと思った時に最初に書く
  • 例) 流石です! :sasuga:

「:eyes:」

  • まず見たということを示したほうがいい時にすぐに書く
  • 例) :eyes:

「ありがとうございます!」

  • 何かしてくれた時に最初に書く
  • 例) ありがとうございます!!

「すぐわかったら教えてください」

  • 誰かにとりあえず聞いてみる時に最初に書く
  • 例) もしすぐわかったら教えてください!〇〇ってどこで見れますか?

「ヤッタネ!」

  • やったと思った時に書く
  • 例) ヤッタネ!!