個人コミュニケーションKPI - Konifar's ZATSU
嫁氏はナチュラルコミュニケーションお化けである。 昼飯の時に社交性上げていかなきゃねみたいな話をしていた嫁氏がお昼の散歩中にママ友ができたらしくマジかってなった— こにふぁー (@konifar) 2021年1月13日 嫁氏就活の職場体験的なやつで「いると場が明るくなる」「グループにいてほしい」と複数人からフィードバックをもらってるらしく完全に俺にない才能を持ってる— こにふぁー (@konifar) 2023年7月19日 自分から見れば初対面の相手や複数人の集団とあんなスピードで打ち解け関係を作れるのは才能だとしか思えない。相手について気になったことを深堀って話していくとよいというアドバイスを受けたが、"できる人"のアドバイスで自分にはあまり参考にならなかった。 色々話した結果、才能がなければコミュニケーションを分解して単純なKPIにしてそれを達成しに行くというのがよいという結論にたどり
マネジメント半年くらいの自分へ - Konifar's ZATSU
あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて
組織の"わからない"に対する不快感 - Konifar's ZATSU
組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか
Slackの内容を見落とさない工夫 - Konifar's ZATSU
Slackに慣れてない人は、流れが速すぎてメンションされていても見落としてしまう...という悩みがあると聞いた。そこで、Slackの内容を見落とさないために工夫できることを雑にまとめておくことにする。適当に書いていくので、自分にマッチしそうだと思ったら使ってみるといいかもしれない。 あまり見てないチャネルから抜ける いつの間にか参加しているチャネルが増えがち。チャネルが増えると未読が増えて、次第に未読を気にしなくなってしまう。このチャネル見てないし見てなくても実は問題ないなと思ったらエイヤとLeaveしてみるとよい。自分は定期的に10個くらい抜けたりする。 Mute機能で未読を無視するという手もあるけど、個人的には無視するくらいなら見なくていいはずなので抜けた方がいいと思っている。 スターを使う いわゆるお気に入り的なやつ。 スターをつけておくと、右上のスターボタンから一覧で確認できる。
うまくフィードバックをもらうためのTips - Konifar's ZATSU
春だ。初めてソフトウェアエンジニアとして働き始めた頃、いつも機能のレビューで突っ込まれまくって涙目になっていたのを思い出した。今ならそんなことにはならないので、意識していることを雑にまとめておこうと思う。 今の状況を最初に伝える ざっと考えた仕様や、とりあえず作ってみたプロトタイプを見てもらおうとしただけなのに、めちゃくちゃ細かい部分まで突っ込まれて「あー今そういう感じじゃないのになぁぐぬぬぬ」となったことはないだろうか。これを防ぐには、最初に今の状況を伝えて認識を合わせておくとよい。 「先に今の状況を伝えておくと、まだ完成度は20%くらいです」 「まだ叩き台なのでアラも多いと思うんですがとりあえずざっと作って持ってきました」 みたいな一言があるだけでもだいぶ違う。大事なのは、これを最初の説明で自分から言うことだ。意見をもらい出すと相手も白熱してきてなかなか言うタイミングが難しくなることが
モブオプスなかなかよかった - Konifar's ZATSU
最近opsチームに入って、まずは業務を知ることにした。 ドメイン知識とツールの習熟が必要な業務がまあまあ多くてキャッチアップに時間がかかりそうだったので、モブプロ*1ならぬモブオプスをやってみたらどうかと思い実行してみたところ、なかなかよかったのでざっと記録に残しておこうと思う。 やったこと モブプロの説明をする 入社したばかりでキャッチアップ中の人がドライバーとなってops業務を行う ベテランの人は助言や補足をする 自分(開発・ops初心者)はわからないところを聞く 業務の1つが終わる、または1時間経ったら終了 よかったこと opsの業務に対してツールが追いついておらずマジで工夫して何とかしてくれてるのだなということがよく理解できた ツールを改善するにあたり、業務を効率よくキャッチアップできた メモとして書いていったものがそのまま手順書にできそう ドライバーも知識の確認になってよかったと
社内のエンジニア以外のメンバーにFlutterハンズオンをした時の振り返り - Konifar's ZATSU
先日、Kyashのエンジニア以外のメンバーに向けてFlutterの環境構築からアプリをビルドして動かしてみるところまでのハンズオンをしてみた。 メンバーは企画・営業、Product Owner、デザイナー、カスタマーサポートの4人だった。結果から言うと、まあめちゃくちゃ悪くはなかったけどかなりグダグダになってしまったので忘れないうちにKPT形式でメモしておく。 ちなみになぜエンジニア"以外"のメンバー向けにハンズオンをやったかというと、よりコミュニケーションを取りやすくなるんじゃないかと思ったからだ。新卒の時、営業やコンサルも皆プログラミング課題研修を受ける会社にいたことがあって、当時を思い返すと少しでもコードを書いたりちょっとしたエラーで四苦八苦したりしたことがあるとだいぶやりとりしやすくなるなと感じていた。当時はCOBOLとMySQLで帳票出力というとっつきにくくクソつまらない課題だっ
採用基準における「地頭のよさ」とは何か - Konifar's ZATSU
どんな人を採用するかという会話の中で、地頭がいい人がいいよねという話になった。 なんとなく言いたいことはわかるが、同時に「地頭がいいって何だろうな」という話にもなり、結局結論は出なかった。 出なかったんだけど、やはり採用を強化する上で採用基準が明確じゃないのはよくないので、「地頭のよさとは何なのか」について雑に書きなぐって整理しておきたい。ちなみにこれを書いてる今も「何なんだろうな？」と思っているのでうまくまとまるかはわからない。 問題解決能力なのかなと思ったが、地頭のよさというのはその一部な気がする。問題を解決するためには色々なプロセスが求められるが、地頭のよさはそのうちのひとつでしかない。 じゃあもう少し分解して「問題定義」と「問題解決」にしてみると、なんだか問題定義の能力の方が地頭のよさに近いんじゃないかと思えてきた。思い返してみると、地頭がいいなーと感じる人って、会議中の発言でも何
技術的にも工数的にもできるけど歯切れが悪い返事をしてしまった - Konifar's ZATSU
会社で微妙な返事をしてしまって、しかもその気持ちをうまく伝えきれなかったので雑にまとめておく。 何が起きたかというと、技術的にも工数的にも何も問題ない機能なんだけど「うーん、それ今やるのかぁ」みたいな気持ちが拭えず微妙な返事をして結論を出しにくい空気にしてしまったのだった（完） コードを書く人がこういう反応をすると、デザイナーさんやビジネスのメンバーは対応に困ると思う。仕事に限らず、誰かに何かをしてもらうときには相手に納得してもらった上でやってもらいたい。その方がお互いに幸せなのは間違いない。 今回の話でいえば、「やる・やらないで言えばやった方がいい」というのは間違いなかった。問題なのは、「テストも含めると意外と時間がかかる改善になりそう」ということだ。といっても、1週間もあればできる話だった。 人によると思うけど、自分がそういうときに考えるのは「そのコストを払った分ユーザーか会社にメリッ
どういうデザイナーとだと仕事しやすいか - Konifar's ZATSU
デザイナーさんと昼飯を食っていたら急に「どういうデザイナーとだと仕事しやすいですか？」と聞かれ、しばらく考えて色々話したけれどいい感じに伝えられなかったのでここに書き出しておきたい。 先に言っておくと、これはデザイナーさんの良し悪しの話ではなく、あくまで自分の経験的にこういうことを意識してくれていると楽だったなーやりやすかったなーという感想でしかない。人によって仕事のスタイルが違うのは当たり前だし、やり方を強要するつもりはない。ただ、お互いにこういう振る舞いだと仕事しやすいというのを伝え合うのは大事だと思うので、あくまでこういう風に考える開発者もいるんだなぁくらいにとらえてもらうのがいいのかもしれない。 1回目に見せるラフを作るまでがとにかく速い 人に見せる時に、今の完成度やどういう粒度のフィードバックを期待してるかを先に伝えられる 何かフィードバックを受けた時に、なぜ自分がそうしたかを論
Twitterを利用したエンジニアスカウト - Konifar's ZATSU
雑にまとめる。 これは自分の感想でしかないのだけれど、エンジニアの不満というのはTwitterにこぼれやすい。 それ自体が良い/悪いという議論はあるが、自分の置かれている環境をどうしようもできないという辛さがネット上に溢れてしまうことを第三者目線から責めることは酷である。 すごく言い方は悪いが、そういう不満がありそうなエンジニアというのは、人材を欲している人事にとっては狙い目である。 SNSに愚痴をこぼすような人は不安という意見もあるかもしれない。しかし自分の周りで辛そうな人たちはもう十二分に努力をした上で絶望しているということが多い。場所を変えれば生き生きしだすということは多分にありうる。 エンジニアを探している人事の人は、イケてるエンジニアをフォローしておくべきだ。そして重要なのは、決して人事から声をかけないということだ。人事から声をかけるのではなく、エンジニアから声をかけてもらった方
WEB+DB Pressの思い出 - Konifar's ZATSU
WEB+DB vol95に『Androidアプリの国際化』という記事を書いた。 WEB+DBに『Androidアプリの国際化』という記事をかいたhttps://t.co/PUuUmvC2CY 商業誌に書くことの何がいいって、親や嫁氏にとってもわかりやすく喜んでもらえるところかもしれない pic.twitter.com/Y8ywWnk6HV— こにふぁー (@konifar) 2016年10月21日 で、Facebookに「書いたぞ」とポストしたら新卒の時の上司からいいねがついた。その瞬間に、WEB+DB Pressを初めて知った時のことを思い出した。 新卒の時の自分はコードを書いたことがない素人で、ヒィヒィ言いながらJavaのキャッチアップをしていた。 当時マネージャーだったその上司は、お世辞にもマネジメントが上手とは言えない人だったのだけれど、部署の中でも技術力はずば抜けていて皆に信頼さ
無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
雑にまとめるので何かあったら直接言ってほしい。⇒ @konifar チームで仕事をしていると、なんかあんまり意味のないことで議論している事態に陥ることがある。こういうのは議論の中心にいるとわかりにくいが、少し引いて眺めてみると「それそんなに重要なんだっけ？俺たちはこんなに時間使って何を決めようとしてるんだっけ？」という状態になってることも多い。 例えばAとBどっちがいいですかね？という意見の時、正直どちらでもいいと皆が思ってるのにAとBのそれぞれのいいところや懸念点なんかを皆で話しこんでしまっているみたいな。こういう時に難しいのは、単に「それどっちでもよくないですか？」みたいな言い方をすると場が凍って空気が悪くなるという点である。もちろんそういう本質的なことを言ってくれる人はありがたい存在なんだけど、言うタイミングが少し遅くなると「俺たちはなぜこんな無駄な時間を…」みたいな感じになることが
Google I/Oで発表されたConstraintLayoutで感じたこと - Konifar's ZATSU
Google I/Oで発表されたConstraintLayoutはわりと衝撃だったので感じたことを雑にまとめておこうと思う。 ConstraintLayoutはより簡単にレイアウトを組むために登場した新しいViewGroupという理解である。詳細は、圧倒的当事者意識によって書かれた以下の記事にまとまっている。 qiita.com tech.recruit-mp.co.jp ConstraintLayoutは、UI Builderを使ってGUIで簡単にレイアウトを組むことができる。簡単に、というと少し語弊があるかもしれない。正確に言えば、「簡単にレイアウトを組むことができるようになるかもしれない」という可能性を秘めたレイアウト。今はまだツールも少しバギーらしいが、これからの進化に期待という感じ。 もしConstraintLayoutが進化していくとしたら、Viewの作り方が従来とはガラリと変
Androidでよくあるめんどくささ - Konifar's ZATSU
最近Androidを楽に開発するためにはどういうクラス構造にすればいいかを考えている。 巷にはMVP、MVVM、MVC、FLUXなど様々な設計が溢れているが、サンプルコードを見てもなかなかイメージがつきにくい。理由はサンプルが簡単すぎるからだ。シンプルなTODOアプリではメリットよりコード量の増加や見通しの悪さといったデメリットの方が目についてしまい、どうしても『なぜ』その設計や構造が必要なのかを理解しにくい。理解できても1週間後には忘れている。 Android開発においてなぜ設計が議論されるかと立ち返ってみると、考えることを少しでも減らしたいからだと言える。わかりやすいところで言えば、複雑なライフサイクル、画面回転を考慮したデータのロードにエラーハンドリング、その状態に応じた画面表示あたり。Androidの開発をする上で、考慮しなければいけない事象はバージョンアップのたびに増しており、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
