Konifar's ZATSU

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

歯に衣着せぬ発言と美学について

雑に考えをまとめておきたい。雑すぎて気分を悪くしたらすまない。自分が「雑に書く」というときは別に深く考えていないわけではなく、「色んな印象で捉えられるのをできるかぎり想定して文章を練る手間を省くよ」という意味なので、ちょっとムッとしたとしても受け流してもらえると嬉しい。

職場でもどこでもあることだと思うんだけど、歯に衣着せぬ発言をあえてする人っているよね。例を出すのは難しいけど、「もうちょい言い方考えようよ」と思わせる言い方で人をイラつかせるというか。自分はわりと気が長い方なのでオイオイと思うだけでそんなにイライラすることはないんだけど、当然イラっとする人もいて、そういう時に空気が悪くなるのはつらい。

チームで何かするのに向いていない人だと言ってしまえばそれまでなんだけれど、そういう人は2種類のタイプに分かれるんじゃないかと感じている。自分の発言が空気を凍らせていることに気づいていない人と、気づいているけどあえてやっている人の2種類だ。

前者に関してはもうどうしようもない。先天的なものもあるのだろう。まわりの人間に恵まれることを祈るばかりである。

もう少し深掘りして考えたいのは後者についてだ。すなわち、あえて歯に衣着せぬ発言をしている人である。色んな状況があるだろうけど、ここでの話は会議でそもそも論をするみたいなレベルの話ではない。上司が部下に何かを気づかせるために厳しい発言をするのとも違う。もっと根本にある、人への"思いやり"みたいな話だ。嗚呼、自分で書いてきて悲しくなってきた。会社は学校じゃねえんだよレベルの話だが、そういう人はよくいるので仕方ない。

自分の感覚だが、何か物事を前に進めるためにリードする役割を担ったことがある人は、話がこじれそうな言い方をしない。思いやりとかそういう話というよりも、ちょっとした物の言い方の違いによって物事が進みにくくなるケースがあることを実体験から知っているからだと思う。こういう立ち振る舞いの微妙な調整というのは、きっと一度経験しないとできないものなのだろう。

なぜそんなめんどくさい言い方をしてしまう人がいるのかなーとたまに考えていたのだけど、結局今でもよくわかっていない。今のところ「そういう発言をするのがかっこいい」という発想が根っこにあるんじゃないかと考えている。数多く存在する中二病の一つといってもいいかもしれない。

どういう行動をするのがカッコいいかという感覚は、それ自体がその人の美学であると思う。そしてこれは持論だが、その感覚は22歳を越えるとなかなか変えられないと思っている*1。つまりそういうことだ。

雑すぎて心配になってきた。けどいいよね、ZATSUブログだもん。じゃあの。

*1:ちなみにこの持論は、るろうに剣心の高荷恵の「バカねェ。齢二十二に なるともう性格の矯正なんて出来ないわよ(クス…)」という台詞に大きな影響を受けている

優しさからくる過激な発言こわい

今日もインターネッツは怒りに満ちている。

この記事を読んで感じたことを雑にまとめておきたい。

type.jp

内容はすごく共感して、そうだよねーと思いながら読んだ。けどまず最初に感じたのは「この人口調きついなーいつも怒ってそうでこわいなー」ということだ。そっちの印象の方がつよい。

すぐ怒る人が嫌いなわけじゃなくて、むしろ感情をあらわにする人は好きなんだけど、なんなんだろうな。なんかこういう、本来自分以外の誰かへの思いやりからくる意見をあんまり優しくない過激な言葉で語られると「なんか根っこの部分で矛盾してない?」って思ってしまうんだよな。

この記事のケースだと「子育ては大変なんだぞ。考え古すぎだろ」という子育て中の女性や男性に向けた思いやりからちょっと強い口調になってきているわけで、根っこにあるのは想像力と他者への思いやりなんだよね。子育て中に人たちに対しては思いやり持てるのに、なんで別の立場の人には簡単に「バカ」とか言えちゃうのかなーと思っちゃうんだよな。本当に想像力と思いやりからくる意見なら、他の人にもいったん落ち着いて思いやりもつべきじゃない?直情的だとしても、いったん冷静になって言葉を選んだ結果だとしても、どちらにしろ嫌だなって思った。

ハンターハンターを例にすると、ノブナガとの腕相撲中にゴンがキレた時の心情に近い。

「仲間のために泣けるんだね。血も涙もない連中だと思っていた。だったらなんでその気持ちを少し…ほんの少しでいいからお前らが殺した人たちに、何で分けてやれなかったんだ!!」

うん、わかりづらいね。何でもない。

つよい言葉じゃないと伝わらないとかいう意見もあると思うんだけど、本当にそうなのかな。少なくとも自分は言葉を丁寧に選んで自分の意見を伝えられる人の方が胸を打つと思う。

まあこの記事は編集でちょっと強めにアレンジされてしまったのかもしれないけど、どうもこういう子育て系とかって過激派が多い気がしてこわい。優しさからくる思いを過激な表現で主張する前に、その優しさが一方の誰かに偏ってないか考えてほしくなる。これは自分も注意しないといけないところだ。偏った優しさは視野を狭めるし厄介なので、常に自分の行動が矛盾していないかは細かいところまで確認するようにしないとなと思った。

誰かを応援するときの余計な言葉について

たまにさ、ちょろっと罵倒した上で「けど俺はお前を応援してるから言ってるんだ」みたいなこと言う人いるよね。あんまりよくないスポーツの監督とか。あれ言われる立場としては何も響かないし何なら嫌な感情のほうが強く残るのでマジでやめたほうがいい。

「こんなことも考えてないの頭大丈夫か?」っていうのと「こういうことも考えてくれると嬉しい」っていうのは全く別だからな。この場合、「頭大丈夫か?」は余計な一言であって応援でも何でもない。更に言うなら、前半も別に応援ではない。本当に応援するのならただ自分の言葉で厳しい意見を投げつけるのではなく、相手が受け取りやすい言葉を選ぶところも考えるべきだと思う。

相手が受け取りやすいかどうかなんて相手を知らないとわからないよね。だからこそ想像力が大事で、どんな相手でもすっと受け取れる言葉を選ぶべきだ。本当に相手を応援したいのなら、余計な言葉は入れないほうがいい。じゃなきゃ応援以外の部分の印象が強くなって批判と捉えられる。そこを気をつけるのがめんどくさいのなら、たぶん実際には応援したいわけではないってことなんだろうね。

よくわからない仕事に対する想像力とコミュニケーション

今日も今日とてインターネッツは怒りに満ちている。

わかる。これ系の話は定期的に出てきてなくならない。よほど共感を覚える人が多いのだろう。相手の言い方の問題でもあるけど、癇に触ることはあるよね。特に差し込みの仕事とかだとイラッとしちゃうよね。

ただ、「わかるー」と思う一方でそろそろこういう話飽きたというか、なんか毎度同じこと言ってて不毛だなと感じることもある。相手の性格や関係性にもよるからひとくくりの話にはできないけど、できれば想像力を持ってお互いに尊重しながら楽しくやりたい。怒ると疲れるからね。

相手の立場に立ってみると、正直知識がないことに対してちょっと癇に触る言い方しちゃうのは仕方ないと思うんだよな。たとえば自分がいきなりアニメ制作現場のデスクを任されたとして、最初は現場の具体的な作業とかわからないし本当に大変だと思う。

大事なのは、よくわからない仕事に対する想像力とコミュニケーションなのかもしれない。たとえば、必ず「ここってどのくらいかかりますか?」みたいな言い方で入ると摩擦も少なくなるのかもね。知ったかぶりとか自称中級者が一番やっかいなので自分もそうならないように注意したい。

関係性によっては「〇〇さんなら1日で終わりますよね」みたいなコミュニケーションもありかもしれない。けどそういう距離感を測るってかなり難しいし、どんなに仲のいい人でも余裕がない時はしんどいのでこういうのは避けておいたほうが無難なんじゃないかと思う。

想像力は経験をベースに成り立つので、何度も苛つくことが続いたら直接相手に伝えたほうがいい。イライラが募るとそういうコミュニケーションすら取りたくなくなるので、ちょっとでも癇に触ったらすぐに伝えていくのがオススメ。めんどくさがられるの怖いし勇気がいることだけど。

専門職の仕事は特に想像しにくいので、相手に少し体験してもらうのが一番よい。知識の多い方から少ない方に歩み寄るほうが色々うまくいくことが多い。少し時間とって、エンジニア以外の人向けに説明会とかハンズオンとかやってみるといいかもしれない。

ちなみに想像力は余裕がないと働かないので余裕を持とう。これが一番大事で難しい。

社内のエンジニア以外のメンバーにFlutterハンズオンをした時の振り返り

先日、Kyashのエンジニア以外のメンバーに向けてFlutterの環境構築からアプリをビルドして動かしてみるところまでのハンズオンをしてみた。

メンバーは企画・営業、Product Owner、デザイナー、カスタマーサポートの4人だった。結果から言うと、まあめちゃくちゃ悪くはなかったけどかなりグダグダになってしまったので忘れないうちにKPT形式でメモしておく。

ちなみになぜエンジニア"以外"のメンバー向けにハンズオンをやったかというと、よりコミュニケーションを取りやすくなるんじゃないかと思ったからだ。新卒の時、営業やコンサルも皆プログラミング課題研修を受ける会社にいたことがあって、当時を思い返すと少しでもコードを書いたりちょっとしたエラーで四苦八苦したりしたことがあるとだいぶやりとりしやすくなるなと感じていた。当時はCOBOLMySQLで帳票出力というとっつきにくくクソつまらない課題だったのだけれど、Flutterなら環境構築も簡単だし目に見えるものを作れるしいい教材になるんじゃないかと考えたのが最初のきっかけである。

Keep

  • 2時間はギリギリ疲れないくらいの時間でちょうどよかった。
  • 事前準備を何もしなくていいというのは気軽でよかったっぽい。
  • 各種ツールをダウンロード中に座学を挟んで説明できた。
  • エンジニアが普段やっていることの雰囲気がなんとなーくわかったと言ってもらえた。
  • WindowsのPCがセットアップできなかった時用にMacを用意しておいたのがよかった。
  • 最初にFlutterのサンプルアプリを見せてイメージを共有できた。
  • Macのセットアップのしやすさはすごい。
  • 一通りやったあとで、自分がライブコーディングでリストを表示するところまで見せられたのはよかった。

Problem

  • 人数が多かった。4人を1人で見るのは結構きつい。やるなら他にもチューターが必要。
  • ダウンロードするものが結構いっぱいある。Flutter SDKとAndroidStudioとXCodeは事前にダウンロード・インストールさせておいたほうがいい。
  • 環境変数SDKといった概念をわかりやすく伝えるのが一番むずかしい。普段意外といろんな知識を前提に仕事しているのだなと思った。
  • Windowsの環境構築はかなりめんどくさいので、別途準備しておいたほうがよかった。
  • 色を変えてみる、文字のサイズを変えてみる、といった簡単な課題をちゃんと用意しておけばよかった。適当にいじってみましょうではダメ。
  • 英語のドキュメントに対して苦手意識のつよい人もいるので、そのままドキュメントを渡すとウッとなるかもしれない。

Try

  • チューターを誰かに頼む。
  • 概念の説明は、できればスライドを用意する。
  • 時間のかかることを先にやらせて、その間に座学という流れでやってみる
  • ある程度までやったらモブプロ形式にするといいのかもしれない。ホットリロード最高。

次回はCodeLabの写経をする予定。Firebaseを入れるとさらに知るべき概念が増えてしまうので、Widgetを使ってリストを表示するやつをやってみる。逆にBizチームの勉強会も出てみると面白い。営業のステータスをTrelloみたいなカンバンで管理してたりしてすごいなーと思ったし、お互いにやっていることが少しでも具体的にわかるとコミュニケーションが取りやすくなる。

社内の勉強会だけど、もしチューター手伝うよって人がいたらぜひ声をかけてください。

おやすみ。

採用基準における「地頭のよさ」とは何か

どんな人を採用するかという会話の中で、地頭がいい人がいいよねという話になった。

なんとなく言いたいことはわかるが、同時に「地頭がいいって何だろうな」という話にもなり、結局結論は出なかった。

出なかったんだけど、やはり採用を強化する上で採用基準が明確じゃないのはよくないので、「地頭のよさとは何なのか」について雑に書きなぐって整理しておきたい。ちなみにこれを書いてる今も「何なんだろうな?」と思っているのでうまくまとまるかはわからない。

問題解決能力なのかなと思ったが、地頭のよさというのはその一部な気がする。問題を解決するためには色々なプロセスが求められるが、地頭のよさはそのうちのひとつでしかない。

じゃあもう少し分解して「問題定義」と「問題解決」にしてみると、なんだか問題定義の能力の方が地頭のよさに近いんじゃないかと思えてきた。思い返してみると、地頭がいいなーと感じる人って、会議中の発言でも何かのキャッチアップ中の質問でも、そこを抑えれば前にすすむという部分をピンポイントに突いてくる気がする。

1を聞いて100を知るみたいな人はどうなんだろうか。そういう人を地頭がいいと言う人もいると思う。ある物事とある物事を有機的に繋げて考えられる人は、それができない人と比べて指数関数的に差をつけていくのだろう。

なんだかこのまま考えてもうまく整理できない気がしてきた。こういう抽象的なことを考える時はまず具体的なことを連想して共通要素を抽象化していくのがよい。ということで、地頭がよさそうなキャラを思い出してみることにしよう。

まず最初に思いつくのは、ぶっちぎりでハンターハンターのフランクリンだよね。「シャル、今オレ達にとって最悪のケースってのは何だ?」というセリフ。あの短く本質的な発言によって、発散しそうになった議論を軌道修正することができたんだよ。ああいう発言をあるべきタイミングでできるってのは地頭がいいと言えるのではなかろうか。と思ったけど、あれって「本質を見極める」とか「問題定義能力」みたいな言葉の方がわかりやすいよね。地頭がいいってのはやはり抽象的すぎる。

もう一つ思いついたのは、アルドノア・ゼロ界塚伊奈帆だ。スレインが現れ、敵か味方かわからず皆がどよつく中で放ったセリフ。「どっちでもいいよ。敵の敵なら、味方でなくても役に立つ」これって地頭よくないですかね?今集中するべき問題は何かを冷静に見極めて次の行動を速攻で決めてるんだよな。こういう論理的思考の瞬発力みたいなものも地頭がいいに入るのかもしれない。

ここまで書きなぐってきて思ったんだけど、そもそも地頭がいいという言葉をそのまま採用基準に入れるのはめちゃくちゃイケてないと感じた。いろんな要素を含みすぎだし、直感的に何を見ればいいのかわからないし、「地頭がいい人が欲しい」という言葉を使った時点で欲しい人材をちゃんと言語化できてないと思った方がいい。

結局地頭のよさとは何なのだろうか。自分にとって一番しっくりくるのは「問題の本質を見極めて定義する能力」「解決までの論理的思考能力と瞬発力」だろうか。うーん、なんかかっこいい言葉を並べただけみたいになってしまった。そんなことより最後までやり遂げられるかとか、必要に応じてまわりをいい感じに巻き込めるかとかの方が重要な気もする。

余談だが、地頭のよさについてググってみた時に「地頭のよさは後から身につけられるのか」みたいな話を書いている人材系の記事があった。個人的には「できるけど、素直な人に限る」と思っている。地頭のよさの定義にもよるけど、変にプライドが高い人は無理なんじゃないかな。「地頭がよい」の逆を考えると、「頭が固い」になるのかもしれない。本質を疑ったり、誰かの意見を柔軟に取り入れられることも地頭のよさに入るのかも。

とにかく、ここまででわかったことは「地頭のよさ」という言葉を使うのはやめた方がいいなということだ。抽象的で役に立たない言葉だと思うけど、もしかしたら「あなたは地頭がいいと思いますか?また、地頭のよさとは何だと思いますか?」という質問をすれば、求める答えが得られるのかもしれない。

SlicesのCodelabが激アツだった

一日一善という感じで毎日ちょっとずつI/Oのキャッチアップをしていて、今日はSlicesのCodelabをやってみた。

Creating Android Slices

Codelabめっちゃ簡潔で、ゆっくりやっても40分くらいで終わると思う。ところどころコードが間違ってたりするのはご愛嬌。

概要はCodelabをやればだいたいわかると思うのですごい雑にまとめると、アプリのコンポーネントを外部のアプリやNotificationなんかから簡単に呼び出せるようにする仕組みだった。UIつきのAPIみたいな感じ。

やってみたらわかるけど、これはかなり激アツである。今までSDKにして切り出して組み込んでもらわないといけなかった部分が、コンポーネントに紐づくURLを作るだけで外部から使えるようになる。

今所属しているKyashのアプリとかなり親和性高いなと思った。Googleアプリの検索結果にも表示されるようになるので、例えば「kyash konifar 送金 100円」とか売ったらKyashの送金コンポーネントが出てきて、ワンタップで送金とかできるんじゃないかなーと思った。もちろんUIのカスタマイズや認証あたりはもっとちゃんと調べないといけないけど、あそこで使えそうみたいなアイデアはめっちゃ出てきそう。

Codelabでは adb install -r -t slice-viewer.apk でインストールした slice-viewer.apk を使って sliceの表示確認をする。

Getting started  |  Android Developers

まだ調べられていないこととして、提供されたSliceを組み込む方はどんな感じで実装するのかなということだ。 SliceViewというのがあるみたいなのでそんなに大変ではないだろうけど、シームレスな体験を提供できるのかというのは調査しておきたい。

何が言いたいかというと、とにかくアツそうな機能だったということだ。Google I/OAndroid関連の発表はたしかにいっぱいあったけど、開発者にとって嬉しいツールやコンポーネントの更新が多くて、ユーザーにとってガツンとわかりやすい価値を提供できるもの意外と少ないなーと思っていた*1。そんな中で、Slicesは使いどころによってはすごく体験が変わるいいアップデートだと思うし、みんなSlices対応しまくってカオスで面白い感じになってほしい。

*1:AIはすごかった