Konifar's ZATSU

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

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

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

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

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

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

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

関係性によっては「〇〇さんなら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はすごかった

Google I/O 2018初日キャッチアップ所感

普通にぐっすり寝て朝起きてからTLと公式ブログあたりを見ながらキャッチアップした。現地のみなさんには感謝しかない :pray:

色々あったので雑に所感をまとめておきたい。間違いもあると思うので何かあれば優しく指摘してくれると嬉しい。

App Bundle

developer.android.com

新しいapp publishingの仕組みで、ユーザーがダウンロードするアプリのサイズを小さくできるのがメリットっぽい。公式ページの Stop managing multiple APKs という力強いタイトルが印象的だった。

自分の所属しているKyashのアプリでは、multiple apkで5個のアプリに分割することでアプリサイズが1/3くらいになっていたのだけど、それも必要なくなるのか。「Good bye Multiple apk」というPRを作る日も近い。

このApp Bundleの目指すところはアプリの肥大化を防ぐというところで、multiple apk以外にもDeliver features on-demandという機能ごとに配布する仕組みというのを用意している。ユーザーの属性ごとに分けた時に、新規ユーザーにとっては使わないような機能を別モジュールに分けておいて、そのユーザーが必要になったタイミングでfeature moduleをダウンロードして使うことができるという話のようだ。Kyashの中では今のところそんなに使わなくてもいいかなーと思ったけど、メルカリでは本人確認の部分だけ切り出すみたいな使い道がありそう。使いどころベストマッチだ。

Enable modules to run instantly, without install と言っているのは、Instant Appsのことだろうか。Instant Appsなー、Instant Appsを導入したら視聴時間が5倍に増えたという動画アプリの話がちらっと出ていたけど、正直あんまり実感がなくてなんでそうなるんだ?って印象である。Web版リリースしてるならWeb見ればよくない?Instant Appsの何が優位なのだろうか。そもそもWebがない場合とか、操作感の違いをユーザーが敏感に感じ取って数字に出るとか?いまだによくわかっていない。

発表の様子を見るかぎり、on demand機能を使おうが使うまいが機能ごとに細かくfeature moduleを切っておくのは筋が良さそうだなと感じた。Instant appsだけだと設計難しいし管理が煩雑になるしあんまりメリットないんじゃないかと思っていたけど、どうやら世はfeature multi module時代らしい。slicesのように一部の機能を外だしすることを考えても、分けておく方がよいのだろう。KyashではAuthと送金部分をfeature moduleに分けておくと、今後面白いことをしやすいのかもしれないと思った。マルチモジュールの実践についてはkgmyshinさんの本を読もうな

kgmyshin.booth.pm

ちなみにdynamic deliveryはAndroid5.0以上のみっぽい。すでにminSDKを21にしていたKyashでAndroid開発したい人ウォンテッド。

A fundamental component of Dynamic Delivery is the split APK mechanism available on Android 5.0 (API level 21) and higher.

ConstraintLayout

すぎょい。アニメーションエディタすぎょい。 morphをあんな感じでいじれたら楽しいだろうなと感じさせるデモだった。自分はまだGUIエディタを信じきれないところが大きいのだけれど、ConstraintLayoutのchainくらいはGUIを使い始めているし、ちょっとずつGUIとも仲良くしていかないといかんなと思った。

AbsoluteLayoutが死んだらしい?RelativeLayoutの番も近いので、Goodbye RelativeLayoutというIssueを立てた。こういうのは一日一善でちょっとずつ書き換えていくのがよい。

Navigation Editor

すぎょい。これが欲しかったという人も多いのではないか。これもGUIかーみたいな気持ちにちょっとなったけど、xml依存の考えは捨てて仲良くなるのが良いのだろう。

Navigation Editorからの派生か、できればSingle Activityにしとけよみたいなスライドもちらっと見た。まじか。 別にできなくはないけど、Fragmentだけでやっていくのかーという気持ちになった。Navigationいい感じに使えば問題ないのだろうか。Navigationに関してはすぐにCodeLabをやっておいたほうがよさそう。まあ公式にSingle Activityの方がいいと思うで、みたいな感じで言ってくれるのはありがたい。

↑ と思ったけど自分の勘違いで、むしろ逆に画面遷移にFragmentむやみに使うなってことらしい。安心した

twitter.com

Material2

相変わらずドキュメントが充実していてすごい。Sketchのプラグインもあるとはいたれりつくせりだと思った。 個人的には指針にブレがなければ変化に対してはとてもポジティブな印象である。Flutter向けのコンポーネントも公開されてる。

Material themingはカスタマイズするための指針という認識であってるのだろうか。エディタも用意されてるらしい

material.io

年々ユーザーが迷いなく使えるように手厚くしてくれている気がする。ありがたい。 個人的に気になるのは、このエディタで編集したテーマをそのままコードにエクスポートできるのかというところ。 Material designが出てきた時にさ、テーマでいい感じに見た目が共通化できるって話になってすげええって思ったけど、結局primaryColorってどこに適用されるんだっけ?とかこの色ここに反映されんの?!みたいになってつらかった思い出がある。今回そのへんも解決されると嬉しいなと思った。

これからしばらくGitHubでMaterial Design2ショーケースみたいなサンプルアプリが爆増しそうな予感。

Gallaryというデザイン共有ツールもよさそう。弊社デザイナー氏に共有したら、興味を持ってはいたものの、また覚えること増えるのかw週末やっていき!みたいなことを言っていた。わかる。めっちゃわかる。本当にいろいろ変わって大変だよね。一緒にやっていこうな。

Google Assistant

普通に人間じゃんと思った。むしろここまできたら次はキャラづけしていくしかないやろ。 サイコパスのキャンディーとかドミネーターとかタチコマとか夢が広がる話であるが、おそらくそういうことはやらなそう。

真面目な話をすると、Google Homeの対応とか早めにちゃんと考えて実装しておくのがよさそうだと思った。 Kyashで「Kyashでkobakeiに1000円送金して」とか言ってできるようにしておくのがいいかも。嫁さんに話したら「なんで声に出してそんなこと言わなきゃいけないんだ、恥ずかしいじゃん」とか言われそうだけど。


Material Design2はもっとキャッチアップしたい。 この発表の内容、こう取り入れたら本業アプリでも活かせそうだねみたいな話を社内メンバーとできるのは楽しいなと思った。とりあえずApp Bundleは迷わず対応しておけばいいんじゃないかな。と言ってもdeliver feature on demandをやらない限り実際にやることはほとんどないけども。

真面目な文章にカッコを多用するのはやめたほうがいいのではないか

うまく言語化できないんだけど、カッコを多用するのはやめたほうがいいと思ってる。言語化できていない以上自分の感覚による好みでしかないのだけれど、雑に考えをまとめておきたい。

どういう文章かというとこういうやつ。

カッコを多用するのはやめたほうがいいと思ってる(もちろん例外はあるが)。言語化できていない以上自分の感覚による好みでしかないのだけれど、雑に考えをまとめておきたい(言語化には時間がかかるのでまだ整理ができていない)。

Twitterでは文字数上限と空気感のせいかあんまりいなくて、特にFBの投稿に多い印象ある。

なんでよくないと思うかというと説明が難しいのだけど、なんか文章が練られていないような印象を与えるんだよな。言い訳がましいというかいちいち面倒くさいというか。雑に例えると、対面で話しているときに「その時にミッちゃんがね、あっミッちゃんっていうのは仲いい友達なんだけど〜」みたいな感じの補足の仕方と似ている。

自分もパッと考えて話すのが苦手で、話すときはこんなふうになってしまうんだけどね。けど文章は練る時間があるから別だと思う。

すべての文章に対してそんなに気を遣う必要はないんだけど、真面目な文章や意識高めな文章を書く時は気を遣ったほうがいいと思う。真面目な話でカッコを多用すると伝えたいことをちゃんと練って伝えられないようなまとまりのない文章になる。すごく悪い言い方をすると馬鹿っぽく見えてしまう。

じゃあどうすればいいかというと、まずカッコの中の文章が必要なのかどうかチェックするといい。カッコの中身は大抵言い訳だ。誤解されるの怖くて言い訳書きたくなる気持ちもめっちゃわかる。わかるんだけど必要かどうか一度確認したほうがいい。その上で本当に必要ならカッコの前に持ってきて文章を整えるか、脚注にするほうがいい。

この感覚は自分だけなのだろうか。気になるところである。

何も起きなかったことを評価する

猫を2匹飼っているんだが、2匹目のツーがワンパクで常にいたずらを考えて生きている。しかしごく稀にいたずらを"しないで"いい子にしていることがある。そういう時に「偉いねぇ〜」と褒めようとして考えたことを雑にまとめておきたい。「何もしなかった」あるいは「何も起きなかった」ことをどう評価すべきなのかということだ。

 

猫の例だと、おとなしくしていたことに対する評価をする上で2つの問題がある。

 

まず、よく考えたらそもそも偉いわけではない。普段のいたずらが過ぎる分、相対的に偉く見えているのだ。この行動を褒めて評価してしまっていいのかという点。不良が更生して称賛されるのに似ている。

 

2つ目は、なぜ褒められたかわからないのではないかという点。何もしなかったことに対して褒めるという行為は、本人にとってもなぜ評価されたのかわかりづらい。もしくは本人はわかるかもしれないが、まわりから見たら何が評価に値するのかわからないことがある。常にいい子にしている猫ワンがこの評価を見たら不服に思うかもしれない。

 

こういう話は人間界の仕事の場でも悩ましいところである。たとえばインフラは何も起きないで安定可動していることが素晴らしい。アプリを作っている人もバグが起きないことは評価されるべきだ。

 

猫ツーのように、すでに何かが「起きている」状況での相対的評価はやりやすい。傾向に対して改善したかを見て、改善具合に対して評価すればよい。

 

対して、絶対評価は難しい。縁の下の力持ちは縁の下にいるから見つけにくいし、いなくなったら今の日常が壊れることを想像しにくい。健康な時に病気の時のことを想像して感謝できる人は少ないよね。

適切に定量的に評価するにはどうしたらいいのだろうか。

 

何も起きないことが評価されるべき仕事の場合には、想定とプロセスを評価すべきなのかもしれない。アプリのバグ0件だったとしたら、バグがなくなる工夫を必ずしているはずだし、バグがなくなったことで他に時間をかけられるようになったはずである。こういうのを深堀りすれば適切に評価できるのかもしれない。

 

問題は、その深堀りはめんどくさいということだ。他者にわかってもらえるくらい説明するのは意外とめんどくさいのだ。結局、何も起きないことの価値をわかっている人が評価するしかないのかもしれない。

 

とか考えているうちに猫ツーがエサを食い終わり、猫ワンのエサを漁ろうとしていた。何も起きないことの価値を本人がわかっていないこともあるのだ。