KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP
2020年1月から1年ほどKyashでEMをやっています。 今までチームをリードしてきたことは何度かありましたが、いわゆるマネジメントという役割は初めてでした。EMについて抽象化した話ができるほど自分の中で咀嚼できているわけではありませんが、思考整理を兼ねてやってきたこととやっていくことをまとめておこうと思います。 ここに書く内容は当然自分だけでやってきたわけではありません。他のメンバーによって支えられてきたことの方が多いです。文章量の都合で端折ることもありますが、自分だけで色々やってきたみたいに捉えられるとなんだかむず痒い気持ちになるので一応前提として書いておきます。 1~6月 : Android/iOSチームのEM 1月にiOSエンジニアが1名入社したタイミングで、Android/iOSチームのEMをやることになりました。 それまではTechチーム全体を@ymzkmctが見ていましたが
誰かにフィードバックを伝える時は内容よりも伝え方を工夫した方がいい - Konifar's WIP
主にTwitter上での話ですが、誰かの行為や何かのイベントに対するフィードバックを目にします。 「なるほど、わかる」と内容は理解できてもなんだか共感できないことも多くて、ただなぜ共感できないのか自分自身ちゃんと説明できなかったので、思考整理のために文章にまとめておきます。 先に結論をかいておくと、『その発言がフィードバックなのか単なる愚痴なのかを明確にした上で、フィードバックなのだとしたら感情や認識齟齬といったノイズを減らすように伝え方を工夫したほうがよい』という話です。Twitterくらい好きにやらせてよという話はごもっともで、それが『愚痴』なのだとしたらよいと思います。 過剰な怒りが含まれているかどうか たとえば『イベントの運営の対応が悪い』と感じた時、怒りの感情がぐわっと湧き上がることもあるでしょう。「なんでこんなに手際が悪いんだ」「普通に考えればありえないだろ」「運営は馬鹿なんじ
Android アプリの設計についての本を執筆します - Konifar's WIP
技術書のクラウドファンディングサービスPEAKSで、Androidの設計について本を書くことになりました。 peaks.cc 自分は第5章 OSSにおける設計者の役割を担当し、DroidKaigi2017アプリの設計について書きます。 今回は執筆する側なんですが、実は自分はこういう本を即購入することはほとんどなくて、色んな情報を集めてから購入を判断するタイプなんですよね。なので、自分自身が買いたくなるような情報を少しまとめておこうと思います。 活きた設計の意図が説明される 最近はGitHubにも設計のサンプルとなるリポジトリもたくさんあります。しかしそれらのサンプルは簡単であるが故に、設計そのものの意図を読み取りにくいという難点があります。 コードを読んでもなぜクラスを分けているのかわからず冗長に感じたり、ServiceやNotificationなどサンプルにない部分をどう扱えばいいのかわ
Cloud Functions for Firebaseを使って、自分にPush Notificationを送るデバッグメニューを作りました - Konifar's WIP
Cloud Functions for Firebase（以下Cloud Functions）は、Firebase Databaseへの書き込みやHTTPSリクエストなどのイベントをトリガーにして、任意の処理を追加できるサービスです。 例えば Firebase Storageに画像が保存された時にサムネイル画像も生成して保存する Firebase Databaseにレコードが追加された時にPush Notificationを送る HTTPSリクエストのパラメータで渡したURLを短縮URLにして返す といった具合に、様々な処理をJavascriptコードで記述できます。 他にどんなことができるかは、公式のfunctions-samplesにまとまっています。 今回、仕事でCloud Functionsを使って自分にPush Notificationを送るデバッグメニューを作りました。Prod
登壇者として参加したDroidKaigi 2016 - Konifar's WIP
去年のDroidKaigi 2015は聞く側で参加しましたが、今回は登壇者として参加しました。うまくいったこともあれば失敗して申し訳ない気持ちになったこともたくさんあったので、少し整理しておこうと思います。次は登壇者として参加したい、CFP送ってみたいという方の参考になれば嬉しいです。 CFPの応募 CFPは、『実践！Android Studioプラグイン開発』と『17ヶ国の多言語対応Tips』の2つを応募しました。なぜCFPを応募したかというと、もともと会社から参加許可出るか確定しておらず、登壇なら問題なく参加できるだろうと思ったからです。まぁ結果的にはウチの社長の方針は 「DroidKaigi？どんどん行って来いｵﾗｧ！」みたいな感じだったわけですが。 内容は、自分が少し詳しいテーマで、30分以上話せる内容にしました。自分が送っていいのかな…という気持ちも少しありましたが、当時はそもそ
アニメの名言を簡単に引用できるChrome extension『Kotoha』作りました - Konifar's WIP
思いついた勢いのままに Chrome extension『Kotoha』を作って公開しました。 chrome.google.com コードもGitHubに公開してます。 勢いのままに作ったと言いましたが、Javascript触るの久しぶりな上に初めてのChrome extension開発ということで、 実質15〜6時間くらいかかりました。 完全に俺得Extensionなんですが、せっかく作ったので何を考えてたのかまとめておこうと思います。 知らぬ間にGIGAZINEにも紹介されていました。圧倒的感謝。 gigazine.net どんなExtensionか イケてるアニメの名言を簡単に引用できるようになるExtensionです。 名言をキーワードで探せます。 作品タイトルやキャラクター名でも探せます。 名言はアドレスバーの隣のアイコンから登録できます。 詳細はREADMEに全部書いてあるので
アウトプット増やしたらぼっちじゃなくなってきた - Konifar's WIP
2015年は『アウトプット量を増やす』というのを目標にしています。 そのために4ヶ月くらいサービス作ったりQiita書いたり勉強会で発表したりしてみたんですけど、少しだけ変化を感じるようになったので、振り返りを兼ねてまとめておこうと思います。 一言で言うと、 勉強会でぼっちになることが少なくなった気がするという話です。 今年やったこと まず今年に入ってやってみたことをまとめてみます。 1. 開発コンテストに応募してみた YOKOHAMA Ups!という横浜市の開発コンテストに出て、優秀賞もらいました。 もともと出る予定はなかったんですが、PCほとんど触ったこともなかったはずの母親から 「ExcelのMicrosoft Office Specialist試験1000点満点で合格したわ」という報告が来て、自分もとりあえず何かしないとヤバいと思ったのがきっかけです。 詳しい流れは以前にブログにま
帰宅前の溢れるやる気を持続させる - Konifar's WIP
他の人はどうかわからないですが、自分は 会社から帰宅する前にやる気が異常に高まることがあります。 仕事でも個人の活動でも「今日は家帰ったら朝までやってやるぜ」みたいな感じで、何でもできそうな気がするくらいやる気に満ちあふれるんですよね。完全にやる気MAX状態なんですが、そのほとばしるやる気のままに行動するかというと、まぁ実際はうまくいかないことが多いです。 参考までに、自分のダメパターンを書き出してみます。 まず家帰って飯食って、ちょっとゆっくりしたら 「あれ？俺のやる気どこ行っちゃったの？」ってなり始めます。 23時くらいに 「よっしゃ23時半からやるぞ！」と思ってアニメ見てたら23時34分くらいになります。 「キリが悪いから0時からオールで頑張るぞ！」とか思ってたらいつの間にか1時になってて、 「まぁ6時まで5時間もある！俺たちの夜はここからだ！」とか考えつつTwitter見てたら2時
エンジニアの「できない」という言葉の裏側 - Konifar's WIP
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
社内でSHIROBAKOを広めるためにやったこと - Konifar's WIP
SHIROBAKOはアニメ制作の現場を描いたアニメです。全24話全てが神回と言っても過言ではなく、仕事をする上での姿勢やチームワークの大切さなど本当に学びが多いです。 shirobako-anime.com 人に好みのアニメを押し付けるのは申し訳ないので普段は何も言わないんですが、 SHIROBAKOはどうしても社内のメンバーにも見てもらいたくて、ついに布教してしまいました。少し前の話なんですが、どんな空気になったのかまとめておこうと思います。 結論から言うと、意外とみんな温かく受け入れてくれた上に実際に見てくれたメンバーもいたので、個人的には満足しています。 QiitaTeamに投稿 チームの情報共有にQiitaTeamを使ってるんですが、 『チームメンバーに見てもらいたいアニメSHIROBAKO』というタイトルでしれっと投稿してみました。 反応なければやめようと思ってたんですが、投稿し
結局動くコードが一番楽しい - Konifar's WIP
個人でアプリ作ってるんですが、なんだか最近めんどくさくなってきました。 いつも個人開発って早く続き作りたくてたまらない感じなんですが、最近は 「…よし、やるか！」という感じで気合い入れないと作業に入れないようになってきちゃってます。楽しくなくはないんですが、良くない傾向です。 ちょっとやり方というか、自分のマインドを切り替えないと辛そうなので整理してみます。 個人開発のフリーダムさ 仕事で開発してる方は経験あると思うんですが、業務での開発は色んなしがらみがあることが多いです。もちろん環境にもよりますが、100%自由に何でも開発できるというのは稀な気がします。 それに比べて、個人開発はもう完全に自由です。何を作ってもいいし、どれだけ時間をかけてもいいわけです。好きな言語で開発するのも、話題になり始めたばかりのクールなライブラリを使ってみるのも全部自分で決めていいわけです。 何かを作る上で、こ
ライブラリの守備範囲は狭い方がいい - Konifar's WIP
開発で使うライブラリってどう選定してますか？ たぶん選定基準は様々ですよね。社内で基準が明文化されてるところもあるかもしれません。 選定の際には、GitHubスターの数やドキュメントの充実度、最終更新日といった客観的な指標はもちろん、キャッチアップコストやサービスの規模といった開発上の様々なトレードオフを考慮する必要があります。自分は漠然と「ライブラリはあんまり大きくない方がいいなぁ」と考えていたんですが、ちゃんと思考整理できていなかったので、ざっとまとめておこうと思います。 Android開発が多いので、Androidのライブラリを例に話します。あくまで現在の自分の考えのまとめなので、それ違うんじゃない？と思われるところもあるかもしれませんが、その辺は優しくツッコミいただけると嬉しいです。 ライブラリはみんなの課題を解決する そもそもなぜライブラリを使うかというと、その方が楽だからですね
図星と感じる言葉ほどイラッとする - Konifar's WIP
誰かに何かを言われてイラッとすることありますよね？自分はあります。 最近ようやくそういう時の自分の気持ちの切り替え方みたいなものが固まってきたので、考えをまとめておこうと思います。 これは自分の経験に基づく考えなので、万人に当てはまるようなものではないです。あくまで自分はイラッとした時にこう考えてるよという話としてまとめます。 イラッとすると疲れる 自分はできることならイラッとしたくないです。周りに伝播しちゃうと迷惑になりますし、何より感情の起伏が激しいと自分自身疲れるからです。 仕事がいくら忙しくてもあんまり疲れないんですけど、イラッとするとめちゃくちゃ消耗します。消耗するとパフォーマンスが上がらなくなって、またイラッとなりやすくなるという悪循環に陥ってしまいます。これは精神衛生上よくないので、何とかしたいなぁと思っていました。 瞬間的にイラッとするのは仕方ない 3年くらい前は、 「イラ
ふとした一言で心が軽くなってパフォーマンスが上がる現象 - Konifar's WIP
長いGWが終わって、明日から仕事に戻ります。たぶんめちゃくちゃ忙しくなる予感がします。 自分は忙しいと結構まわりが見えなくなって、気分の浮き沈みが激しくなりがちです。ちょっとしたことですごくテンションが上がったり悲しくなったりします。もちろん仕事なのでやりきるわけですが、 こういう感情の起伏は仕事のパフォーマンスに大きく影響します。すぐに疲れてしまったり全然集中できなかったり、要するにろくなことがないです。 その起伏の波が最底辺まで沈んだ時、どうやってテンションを戻してたかなぁと考えてみると、 誰かのふとした一言で一気に心が軽くなったことが多かった気がします。なんだか単純な性格みたいですけど、思い返して見るとやはりそういうことが多かったなぁと思うわけです。 GWが終わり、明日から最大のパフォーマンスで仕事するために、今まで助けられた言葉を思い出しつつ整理してみようと思います。 あくまで自分
エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP
非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
考えることを減らすという指針 - Konifar's WIP
最近チームメンバーが増えてコードレビューの数も増えてきました。 レビューでお互いが納得できるような説明を何度もするのも嫌だし、『よいコードとは何か』ということについて自分の思考を整理すべきかなぁと考えていました。 よいコードについてはすでに議論されつくされていて、最後は好みの問題という人もいるしケースバイケースだという人もいると思います。たしかにそうだなぁとも思うんですが、レビューで指摘する際にそのように伝えてしまうと相手は次から何をどう考えてコードを書けばいいかわからなくなってしまうし、最低限自分なりの指針を明確にしておく必要があります。 で、自分の指針を整理した結果、 考えることを減らす に落ち着きました。 この指針に沿って、考えたことをまとめておこうと思います。項目とか綺麗にまとまってないですが、このブログはタイトルの通りwork-in-progressなのでまぁいいかなぁと言い訳し
個人アプリ開発中の寂しさをbotで紛らわす - Konifar's WIP
個人のアプリ開発は楽しいです。けど時々寂しいです。 例えば深夜にアイコン作ってる時とか。 「いつもはデザイナーさんに助けられてるけど自分でやらないとなぁ…」とか考えて、無性に寂しくなったりします。ちょっと前からこの寂しさを何とかしたいなぁと思っていました。 で、今は Slackにhubotを住ませて1人じゃない感を演出することである程度解決しているので、どんな雰囲気で開発しているかまとめておこうと思います。 先に言っておくと、あくまで自分はこうやってるよという話なので 趣味がかなり入っています。以後その点だけ注意をお願いします。 統一された世界観を作る プロジェクトごとにSlackのチャネルを作ってそこに全て集約しています。GitHubのアクティビティ通知、CI結果通知、メール問い合わせ通知などですね。 ここで自分が大事にしてるのは、 統一された世界観を作るというところです。 例えば この
伝えたいことがあるなら汚い言葉は控えた方がいい - Konifar's WIP
最近Twitter眺めたりブログ読んだりしていると、 「伝えたいことがある時は汚い言葉は使わない方がいいんじゃないかなぁ」と感じることが多いです。 自分もブログを書くようになったので、自戒を込めて考えをまとめておこうと思います。 汚い言葉のエネルギーすごい 汚い言葉や過激な言葉の与える印象ってすごく強いです。 政治の話題だと特にありがちなんですが、例えば「老害は引退しろ」とか「馬鹿な政治家に任せてられない」とかよく目にするんですけど、すごく目立ちますよね。主張や印象がどうかは置いといて、とりあえず目立つ。 そう考えると、汚い言葉のエネルギーはやはりすごいなぁと思うわけです。 汚い言葉を使うと伝えたいことがブレる エネルギーはすごいんですけど、どうも主張が伝わってこないなぁと感じてしまうことが多いです。主張したいことに意識を向けてみるとそんなに悪いことは言っていないのに、言葉の汚さの方に気が
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
