元アニメ制作進行の同僚Project Managerとの雑談 - Konifar's ZATSU
この記事はSHIROBAKO Advent Calendar 2020 25日目の記事です。 実は今所属している会社にはアニメ制作進行をやっていた経験があるProject Managerがいる。彼の視野の広さ、進行の管理能力にはいつも感嘆している。 プロジェクトが並行で複数走り、Product Managerやエンジニア、デザイナー、法務にMarketing担当、時には経営陣まで巻き込んでリリースに向けて適切なコミュニケーションを取って進めてくれている。つまり宮森である。 そんなProject Managerの宮森と雑談した時の話を雑にまとめてみようと思う*1。 宮森ですね！ 「なんで新卒でアニメ制作会社に入ったんです？」 「アニメを作りたかったからですね」 「なるほど、宮森ですね！」 最初の『ねぇよ』話 「SHIROBAKOって、たしか『あるある』が50%、『こんなだったらいいな』が20
仕事で親切と言われ始めたら注意 - Konifar's ZATSU
仕事において親切と言われ始めたらちょっと注意したほうがいいと思っていて、その話を雑にまとめておきたい。 親切と言われるともちろん悪い気はしないんだけど、同時にやばいなと感じることがある。親切と言われる背景には、「本来その人がやるべきでないタスクを拾っている」場合があるからである。 誰かがやらなければいけないのだけれど、毎回同じ人がやることになってたりすると属人化するしあまりよくない。チームで捌けるように工夫できないか検討したほうがいい。 実は突き詰めると意味のない仕事だったと気づいたり、自動化で解決したり、他の人でもできるようにドキュメントにまとめて共有したり、そういうことができてないから毎回手を動かしてしまう。結果、親切に映って感謝はされるんだけれど、本当は効率よく仕事ができてないことを反省しなければならなかったりするのだ。 もちろん状況による。あと信頼関係を築くためにあえて親切な動きを
言いたいことあるけど言わんとこのパターン分け - Konifar's ZATSU
「言いたいことはあるけど言わんとこ」ってなることあるよね。言わなくて正解ってことももちろんあるんだけど、仕事の中でそういうのが積み重なるとストレス溜まるし、自分が逆の立場だったらどんなことでも言ってもらいたいのでなるべく言うようにはしている。 この意見はあるんだけど言わない/言ってくれないケースっていくつかパターンがあると感じているので、今後改善したくなった時のための整理としていくつか書いておく。 諦めている (今さら言っても仕方ないし) 言わんとこ (言ってもどうせ変わらんだろうし) 言わんとこ 気遣いしている (言ったら変な空気になりそうだし) 言わんとこ (時間押してるから長引かせん方がいいし) 言わんとこ (今ここで話すと誰かが嫌な気持ちになりそうだし) 言わんとこ (相手が感情的になっちゃいそうだし) 言わんとこ 線引きしている (○○さんが説明するべきだと思うし自分は) 言わん
どういう時に仕事を辞めたくなるか - Konifar's ZATSU
まだ現職辞めへんで！！ということを最初に宣言しておきつつ、どういう時に仕事/会社を辞めたくなるかを考えてみたい。 朝眠いとかだるいとかそもそも働きたくないとか5000兆円欲しいとかそういうやつではなく、基本的にはやる気がある状況でもふと環境をリセットしたくなるというか、ああなんだかめんどくさいなーと感じるみたいな、比較的ライトな感情の変化の話である。人によっては「にゃーん」とツイートしたり、シャワーを浴びながら「つらい…」とつぶやいてしまったりするアレだ。 なんでこんなことを考えてるかというと、最近TL上で「この人が辞めるのマジか」とか「この人が入社したのかすげえ」と感じることが何度かあり、全然そんな素振りを感じなかったのにやはり一期一会なのだろうかと思ったことがきっかけである。仕事を辞めるのにポジティブな理由だけということはまずないという持論がある。 自分にも感情の波みたいなものがあって
納得感のある決定事項の共有方法 - Konifar's ZATSU
意思決定の場にいない人に対して決定事項を共有する際、いくつか気をつけておくといいなぁと考えていたことを雑にまとめておきたい。 決定する前から進捗をちょっとずつ共有しておく 決定前の話なので後の祭りかもしれないが、いきなり結果をドーンだと相手を戸惑わせることがあるので事前に議事録を共有したり中間で説明する機会を作ったりするとよい 背景と前提条件を伝える なぜやるのかわからないまま結果だけ共有すると納得してもらいにくい。決定する上での前提条件を知らないと余計な反発をうむこともあるので注意が必要。それまでずっと考えてきた当事者は気づきにくいが、びっくりするくらい前提知識が違うことがある。相手は何も知らないものとして、イチから説明した方がよい 決定までの経緯を伝える 結論より経緯の伝え方が重要。どのような議論があってそんな決定になったか、完結に伝えましょう 捨ててきた選択肢も伝える 結果に至るまで
韓国では日本ほどAndroidにKotlinが浸透していないらしい - Konifar's ZATSU
韓国のDroidKnightsという大きめのカンファレンスに参加してきた。 「Is Kotlin necessary for us?」みたいな感じのタイトルのセッションが満員御礼でちょっと意外だったので、韓国のKotlin事情についての考察の話をしたい*1。一応先に言っておくと、遅れているとか言うつもりは全くなくて、何が違うのかと思って色々聞いてみたことをまとめただけである。 （韓国語だったのでGoogle翻訳で日本語にしている） なぜ意外だったかというと、2017年にGoogleがKotlinを公式に採用するとなって以降、日本ではこういった話はすでに話しつくされてKotlin当たり前やろみたいな空気になっていると感じているからだ。現地に「何で開発してる？」的なアンケートボードがあったので見てみたが、たしかに日本よりもJava比率が高い気がする。カンファレンスに来るような人たちという意味で
俺だけが頑張ってるという感情は危険 - Konifar's ZATSU
時間が微妙に空いてしまったので、その間に自分の経験を踏まえてガーッとまとめる。 特に誰のことを言ってるとかではないので「俺かな…」とか無駄に心配にならないようにしてほしい。 「なんで俺がこんなに頑張らないといけないんだ」みたいな感情湧くことあるよね。「なんで俺がアイツの仕事までしなきゃいけねえんだ」とかさ。「俺はこんなにちゃんとやってるのにあいつらは」とかさ。もうめっちゃあるよね。 その頑張りはたぶん正しいんだけど、この負の感情マジで無駄だなーと思っている。人と自分を比べだすとめっちゃ疲れるんだよね。大体さ、その怒りの根源は自分の不甲斐なさの認識から来てることもあるわけ。自分が圧倒的にできて、他の人にも影響を与えられるくらいなのであれば何も問題ないんじゃないかって。それができない分イライラしちゃって、自分だけなんでこんなに頑張らなきゃいけないんだろうって気持ちになる。 重要なのは、頑張りは
オンラインコミュニケーションでの相手での心遣い - Konifar's ZATSU
インターネッツでは毎日がエキサイティングである。これを見て、たしかに〜わかることもある〜と思った。 「コミュ障エンジニア」の他の特徴として、Slackやプルリク等での文章のやりとりにおいて「断定形/詰問形/命令形が非常に多い」というのがありまして、「違います/〜しましたか/〜してください」みたいな、ビジネスマナーを理解できてない稚拙な言葉遣いをしてしまう傾向が見受けられますねｗ(^.^;)— 勝又健太@テック系Youtuber (@poly_soft) October 20, 2018 たぶん嫌な気持ちになることが何度もあって、ひとしきり考えてからちょっと尖った言葉を選んだのだろう。コミュ障かどうか、稚拙かどうかは置いておいて、たしかに「ちょっと言い方変えた方がいいのになー」と思う人はいるよね。そういう人とのコミュニケーションに慣れていないと、気をつかってしまったりイライラしたりしてちょっ
新人の正論を取り込む準備と心構え - Konifar's ZATSU
最近新しく人が入ってきて、今まで手がつけられていなかった部分に対する正論をストレートにぶつけてきてくれて思わずにやけてしまった。 そう、新しい人には感じたことをそのまま言ってほしい。まだ自分が成果を出せるかわからないタイミングで正直に思ったことをぶつけるのはすごく勇気がいることだとは思うけれど、新しい旋風を巻き起こしてくれた方が嬉しいし、それをうまく取り込むのは既存メンバーの役割だと思っている。 正論をうまく取り込むには準備と心構えが必要だと思っていて、それをざっとまとめてみる。 社内ブログやSlackチャネル、定例など意見を言いやすい場所を用意しておく 感じたことは率直に言ってほしいと期待している役割などを伝えておく 口だけみたいになるのでは、という不安はいったん気にしなくていいと伝えておく 個人ではなく仕組みに対してという伝え方を意識してほしいと伝えておく 言ってくれたら、まず素直に感
モブオプスなかなかよかった - Konifar's ZATSU
最近opsチームに入って、まずは業務を知ることにした。 ドメイン知識とツールの習熟が必要な業務がまあまあ多くてキャッチアップに時間がかかりそうだったので、モブプロ*1ならぬモブオプスをやってみたらどうかと思い実行してみたところ、なかなかよかったのでざっと記録に残しておこうと思う。 やったこと モブプロの説明をする 入社したばかりでキャッチアップ中の人がドライバーとなってops業務を行う ベテランの人は助言や補足をする 自分(開発・ops初心者)はわからないところを聞く 業務の1つが終わる、または1時間経ったら終了 よかったこと opsの業務に対してツールが追いついておらずマジで工夫して何とかしてくれてるのだなということがよく理解できた ツールを改善するにあたり、業務を効率よくキャッチアップできた メモとして書いていったものがそのまま手順書にできそう ドライバーも知識の確認になってよかったと
採用基準における「地頭のよさ」とは何か - Konifar's ZATSU
どんな人を採用するかという会話の中で、地頭がいい人がいいよねという話になった。 なんとなく言いたいことはわかるが、同時に「地頭がいいって何だろうな」という話にもなり、結局結論は出なかった。 出なかったんだけど、やはり採用を強化する上で採用基準が明確じゃないのはよくないので、「地頭のよさとは何なのか」について雑に書きなぐって整理しておきたい。ちなみにこれを書いてる今も「何なんだろうな？」と思っているのでうまくまとまるかはわからない。 問題解決能力なのかなと思ったが、地頭のよさというのはその一部な気がする。問題を解決するためには色々なプロセスが求められるが、地頭のよさはそのうちのひとつでしかない。 じゃあもう少し分解して「問題定義」と「問題解決」にしてみると、なんだか問題定義の能力の方が地頭のよさに近いんじゃないかと思えてきた。思い返してみると、地頭がいいなーと感じる人って、会議中の発言でも何
SlicesのCodelabが激アツだった - Konifar's ZATSU
一日一善という感じで毎日ちょっとずつI/Oのキャッチアップをしていて、今日はSlicesのCodelabをやってみた。 Creating Android Slices Codelabめっちゃ簡潔で、ゆっくりやっても40分くらいで終わると思う。ところどころコードが間違ってたりするのはご愛嬌。 概要はCodelabをやればだいたいわかると思うのですごい雑にまとめると、アプリのコンポーネントを外部のアプリやNotificationなんかから簡単に呼び出せるようにする仕組みだった。UIつきのAPIみたいな感じ。 やってみたらわかるけど、これはかなり激アツである。今までSDKにして切り出して組み込んでもらわないといけなかった部分が、コンポーネントに紐づくURLを作るだけで外部から使えるようになる。 今所属しているKyashのアプリとかなり親和性高いなと思った。Googleアプリの検索結果にも表示され
Google I/O 2018初日キャッチアップ所感 - Konifar's ZATSU
普通にぐっすり寝て朝起きてから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の目指
数字目標と悪手 - Konifar's ZATSU
雑にまとめる。今所属している会社の話ではない。 ダサいけどやれば短期的には数字が上がる施策というのが存在する。 ダサいという表現は主観が混じっているし攻撃的な言葉だけれど、めんどくさいのでここではダサいと表現する。 例を上げると、ウザいPush通知とかだね。自分がユーザーだったらウザくてアンインストールしちゃうよなと思いながらも、全体の数字を見ると上がったりするからたちが悪い。 小さな組織なら軌道修正しやすいんだけど、異なる数字目標を持つチームが複数できてきたりすると、部分最適の集合みたいになる。 全体を考えて数字以外の責任を持つつよい役割の人をおいたほうがいいという組織課題な気もする。そりゃ短期間で設定された数字上げることに責任を持ってたら視野が狭くなるのは仕方ないよな。それかいっそトップダウンの命令でやっていったほうがいいのかもしれない。 友達のエンジニアさんから「アプリの通知ちょっと
登壇前の前座の必要性について - Konifar's ZATSU
先日DroidKaigiで登壇したのだが、緊張して胃がキリキリしていた。人前で話すのは、何度やってもなかなか慣れるものではない。 中でも緊張のピークは、自分のセッションの直前の数分である。 この待ってる時間一番きつい— こにふぁー (@konifar) 2018年2月9日 めちゃくちゃ静かなのだ。緊張が張り詰めているのだ。この状態で話し始めたらどう考えても最初から最後まで空気がヤバくなる、そんな予感がするのだ。 どうしようかと思っていたところへ、主催のmhidakaさんが「イェーイ！！！」と言いながら入ってきて、2人でちょっとした小噺をすることになった。「いやぁ、iOSの審査大変だったね」「ほんとですよ。なんで1万円も払ってこんな目に合わないといかんのかって話ですよ」などと適当に話しているうちに、会場内の空気が和らいでいくのを感じた。とてもとても感謝している。 思うに、登壇の空気感というの
フォームバリデーションと送信ボタンの状態の最適解 - Konifar's ZATSU
タイトルを見て「あーあれね」と思った人もいると思うが、アプリデザインの世界ではすでに議論され尽くされているであろうこの話題について雑に考えをまとめておきたい。とは言っても明確な答えがあるわけではないので意見がほしいというのが正直なところなので、もしフィードバックがあれば @konifarまで直接教えてもらえると嬉しい。 何を言いたいのかというと、『フォームに入力されていない or 入力された文字が異常である場合に送信ボタンを押せる状態にするか押せない状態にするか』という話だ。たとえば次のように氏名を両方入力しなければいけないケース。 初期状態の送信ボタンがdisabledで、入力に応じて状態が切り替わる。 本当に送信できる時だけ送信ボタンがenabledになるというのはわかりやすそうだが、問題もある。入力項目が多くなってきた時に、ユーザーがなぜ送信ボタンを押せないのかわからないかもしれない
どういうデザイナーとだと仕事しやすいか - Konifar's ZATSU
デザイナーさんと昼飯を食っていたら急に「どういうデザイナーとだと仕事しやすいですか？」と聞かれ、しばらく考えて色々話したけれどいい感じに伝えられなかったのでここに書き出しておきたい。 先に言っておくと、これはデザイナーさんの良し悪しの話ではなく、あくまで自分の経験的にこういうことを意識してくれていると楽だったなーやりやすかったなーという感想でしかない。人によって仕事のスタイルが違うのは当たり前だし、やり方を強要するつもりはない。ただ、お互いにこういう振る舞いだと仕事しやすいというのを伝え合うのは大事だと思うので、あくまでこういう風に考える開発者もいるんだなぁくらいにとらえてもらうのがいいのかもしれない。 1回目に見せるラフを作るまでがとにかく速い 人に見せる時に、今の完成度やどういう粒度のフィードバックを期待してるかを先に伝えられる 何かフィードバックを受けた時に、なぜ自分がそうしたかを論
Twitterを利用したエンジニアスカウト - Konifar's ZATSU
雑にまとめる。 これは自分の感想でしかないのだけれど、エンジニアの不満というのはTwitterにこぼれやすい。 それ自体が良い/悪いという議論はあるが、自分の置かれている環境をどうしようもできないという辛さがネット上に溢れてしまうことを第三者目線から責めることは酷である。 すごく言い方は悪いが、そういう不満がありそうなエンジニアというのは、人材を欲している人事にとっては狙い目である。 SNSに愚痴をこぼすような人は不安という意見もあるかもしれない。しかし自分の周りで辛そうな人たちはもう十二分に努力をした上で絶望しているということが多い。場所を変えれば生き生きしだすということは多分にありうる。 エンジニアを探している人事の人は、イケてるエンジニアをフォローしておくべきだ。そして重要なのは、決して人事から声をかけないということだ。人事から声をかけるのではなく、エンジニアから声をかけてもらった方
締切のない仕事を終わらせる方法 - Konifar's ZATSU
雑にまとめる。 締切のない仕事は仕事ではないという言葉がある。誰が言ったかは忘れたが、たしか偉い人が言ってた言葉だと思う。 締切がない仕事というのは、たしかに存在する。そんな仕事があるのは贅沢な会社かだらけた会社かのどちらかであるが、たまにそういう『やろうと思えば無限に時間をかけられる仕事』というのを見ることがある。 もちろん会社からすると無限に時間をかけていいわけはない。締切がないのではなく、明確じゃないだけなのだ。自分の経験だが、締切が明確じゃない仕事をうまく進められない人のほうが多い。要はだらけるのだ。特に100点症候群あるいは恐怖症の人はいつのまにかすごく時間をかけてしまいがちだ。 ビジネスマンなら当事者意識を持ってキッチリ線を引いて終わらせろよという話なのだが、皆が皆そううまくやれるわけではない。特にチームでの仕事の場合はやっかいで、責任者が明確でないと集団心理が働いてダラダラし
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のキャッチアップをしていた。 当時マネージャーだったその上司は、お世辞にもマネジメントが上手とは言えない人だったのだけれど、部署の中でも技術力はずば抜けていて皆に信頼さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
