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が見ていましたが
Androidでクレジットカードの入力フォームの実装を楽にするライブラリを公開しました - Konifar's WIP
作りました。簡単に説明を書いておきます。 github.com モチベーション クレジットカードの入力フォームは、ちゃんと作ろうとすると意外とめんどくさいものです。 すでにGitHubには先人がいくつかのライブラリを公開していますが、下記を満たせるものがなかったので自分で作ることにしました。 カードブランドごとのカード番号フォーマットに対応している サポートするカードブランドを設定できる 有効期限の年月の単一フォームに対応している バリデーションのエラーが細かい CustomViewではなくロジックを提供している テストコードがある 以下は補足説明です。使い方はリポジトリの方を見てください。 カードブランドごとのフォーマットとバリデーションに対応 カード番号のフォーマットは4桁 * 4 = 16桁が多いですが、実はカードブランドごとに異なります。 Brand PAN format Secu
Kyash Android で UIテストを導入した時の方針 - Konifar's WIP
先日、Kyash のAndroidアプリのUIテストをEspressoで書いてCIで回すようにしました。 ユーザー登録、ログイン、カード登録のテストが、毎晩元気に走っています。 きっかけはKPTです。iOSでログイン直後に発生するユニットテストでは気づけない問題が見つかり、 Problem として上がってきました。 テストケースを15項目くらいSpreadSheetにまとめていて大きなリリースの時は手動で確認していたのですが、なぜか「今回はやらないで大丈夫」と判断した時に限ってバグが発生するんですよね。また、手動のテストケースはミスや形骸化しやすいので、 Try としてテストケースの一部を自動化してみることにしたのでした。 Espressoでテストを書く時は、@sumio_tymさんの素晴らしい資料があるので、下記2つを読んでおけば間違いないと思います*1。 DroidKaigi2017
Kyashに入社して半年くらい経ちました - Konifar's WIP
早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの？という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク
DroidKaigi 2018 iOS appのApple審査が通るまで - Konifar's WIP
FlutterでDroidKaigi 2018のiOSアプリを作りましたという記事を書いた後、Appleの審査で何悶着かありもう公開は無理だと諦めていたところ、DroidKaigi当日の2018年2月8日に奇跡的に審査が通りApp Storeからインストールできるようになりました。 DroidKaigi 2018 Flutter Yusuke Konishiユーティリティ無料 色々な人に知見をいただき、本当に感謝しています。iOSアプリを開発している人にとってはよくあることなのかもしれませんが、自分にとっては新鮮な体験だったので忘れないうちに時系列で残しておこうと思います。いつか、どこかの誰かが同じ思いをした時に少しでも助けになれば嬉しいかぎりです。 1/31 (水) 残り8日 - 初Submit かいた DroidKaigi 2018のセッションの題材として、iOSアプリをFlutter
FlutterでDroidKaigi 2018のiOSアプリを作りました - Konifar's WIP
DroidKaigi2018が来週に迫ってきましたね。 自分もコードで見るFlutterアプリの実装というテーマで発表します。 その題材として、DroidKaigi2018のiOSアプリを作りました。コードも公開しています。 github.com 作った理由は、以前の記事に書いたとおりです。 また、公式アプリではないですが今年はiOSアプリも用意したいなぁと思っています。iOSDC2017に参加した時にAndroidアプリが欲しいと思ったからです。 まだ申請中なので間に合うかどうかわかりませんが、iOS端末がメインの方に使っていただけると嬉しいです。 DroidKaigiの発表では、時間の都合上Flutterの基本的な部分の説明は省くつもりなので、ここで簡単にまとめておこうと思います。 Flutterとは Flutterは、iOS / Androidで動くアプリを作れるクロスプラットフォー
武蔵野アニメーション総務 興津由佳の左眼について - Konifar's WIP
SHIROBAKO Advent Calendar 2017 始まりました。ということで、興津さんの話をします。 出典 : http://shirobako-anime.com/character-12.html 興津さんは、現場の第一線を退き総務として武蔵野アニメーションを裏から支えるベテランです。序盤は朝礼で事務連絡をしているただのクールビューティーとして描かれていましたが、次第に周囲のキャラクターの反応から伝説じみた過去の実績と信頼が垣間見えてきます。 それらのエピソードを全て語ってもよいのですが 今回は興津さんの左眼にフォーカスを当てて紹介しようと思います。興津さんの左眼は通常時は前髪で隠れていますが、実は何度か両目が見えるシーンがあります。 アニメにおいて、半眼や片眼のキャラが"開眼"する時というのは、何らかのチート能力が発揮されるなど物語の見せ場であることが多いですよね。両目が
誰かにフィードバックを伝える時は内容よりも伝え方を工夫した方がいい - Konifar's WIP
主にTwitter上での話ですが、誰かの行為や何かのイベントに対するフィードバックを目にします。 「なるほど、わかる」と内容は理解できてもなんだか共感できないことも多くて、ただなぜ共感できないのか自分自身ちゃんと説明できなかったので、思考整理のために文章にまとめておきます。 先に結論をかいておくと、『その発言がフィードバックなのか単なる愚痴なのかを明確にした上で、フィードバックなのだとしたら感情や認識齟齬といったノイズを減らすように伝え方を工夫したほうがよい』という話です。Twitterくらい好きにやらせてよという話はごもっともで、それが『愚痴』なのだとしたらよいと思います。 過剰な怒りが含まれているかどうか たとえば『イベントの運営の対応が悪い』と感じた時、怒りの感情がぐわっと湧き上がることもあるでしょう。「なんでこんなに手際が悪いんだ」「普通に考えればありえないだろ」「運営は馬鹿なんじ
Quipper Limitedに入社して3ヶ月くらい経ちました - Konifar's WIP
株式会社奇兵隊からQuipper Limitedに所属が変わって3ヶ月ほど経ったので、忘れないように状況を記録しておきます。 先に言っておくと、まだ3ヶ月しか経験しておらずわかっていないことも多いです。なので、「まだ慣れきっていない人から見たらこんな風に見えてるんだなぁ」という感じで軽く読んでもらえるとありがたいです。 また、入社の経緯については、文章で説明すると誤解を生みそうので省略します。と言っても別に話せないようなことは何もないので、直接聞いてもらえれば話します。 今のチーム Quipperは日本と海外向けに教育サービスを展開していて、今はその中のAndroidチームで働いています。 隣にPermissionsDispatcherを作った@hotchemiさんがいたり、後ろに元柔道世界チャンピオンで低レイヤーに詳しい人がいたり、癖のある人ばかりのチームです。 仕事は忙しいかとよく聞か
新人にイラついてしまった時の備忘 - Konifar's WIP
組織にとって新人は期待の風です。しかしその期待の振り幅が大きい分、逆にイラついてしまうこともあります。 「何回も同じこと注意するの嫌だなぁ」とか「もっと考えてきてほしいなぁ」というのがよくある話ですが、ふとした時につい強く言ってしまうことがあるんですね。で、あとでいつも後悔するわけです。イラつきというのはそれ自体で何かがよくなるわけではないし、無駄に疲れるし、自分にとっては害でしかないです。 あとで自分で見返せるように、新人にイラついてしまった後に後悔しながら考えていることをまとめておこうと思います。先に言っておくと、ほとんどマインドセットの話なので万人に共通するような話ではないです。 期待を共有する 「なんでこんな完成度で出してきたんだ。。全然ダメじゃん」とイラついた時は、アウトプットに対する期待が相手の考えるレベルと食い違っているのかもしれません。その場合、「ちゃんとやれよ」という注意
potatotips #28 Android発表まとめ - Konifar's WIP
モバイルアプリの知見共有会であるpotatotipsにブログまとめ枠で参加してきました。 potatotips.connpass.com 会場は外苑前にあるエウレカさんのシャレオツなオフィスでした。 資料はいつものGitHubリポジトリに上がると思うので、Androidの発表を聞いて自分が考えたことをメインにざっくりまとめます。 API仕様書をいい感じに管理する yuyakaidoさんによる、アプリとサーバーサイドのAPI仕様の共有に関する知見の共有でした。 speakerdeck.com 「APIのレスポンスがサーバーと違う」「APIの開発待ちでアプリの開発が止まってしまう」といった、ありがちな問題を、APIドキュメントサービスを使って解決しようという話でした。ApiaryとSwaggerの2つが紹介されていましたが、Swaggerの方がクライアントコードの生成ができるなどApiaryよ
DroidKaigi 2016 公式アプリのOSS成功要因 - Konifar's WIP
オープンソース化した直後くらいに一度経過を書きましたが、今回はその後日談です。 konifar.hatenablog.com 個人的には、今回のOSSは大成功だったんじゃないかなと思います。成功の定義は難しいですが、自分だけで開発するよりもずっと速く開発できたこと、自分も知らないイケてる実装が次々にぶっこまれたこと、前夜祭のような盛り上がりを見せたことなどを鑑みると、成功したと言っていい気がします。 盛り上がりの様子は、ContributorsやPR、Issuesの数から見て取れます。 184個のPR、114個のIssuesが投げ込まれ、35人ものAndroiderがContributeしてくれました。2週間弱のプロジェクトとしてはスピード感あって、まさに集合知という感じで最高でした。 DroidKaigi 2016 Welcome Talk Day.2 // Speaker Deck 忘
登壇者として参加したDroidKaigi 2016 - Konifar's WIP
去年のDroidKaigi 2015は聞く側で参加しましたが、今回は登壇者として参加しました。うまくいったこともあれば失敗して申し訳ない気持ちになったこともたくさんあったので、少し整理しておこうと思います。次は登壇者として参加したい、CFP送ってみたいという方の参考になれば嬉しいです。 CFPの応募 CFPは、『実践！Android Studioプラグイン開発』と『17ヶ国の多言語対応Tips』の2つを応募しました。なぜCFPを応募したかというと、もともと会社から参加許可出るか確定しておらず、登壇なら問題なく参加できるだろうと思ったからです。まぁ結果的にはウチの社長の方針は 「DroidKaigi？どんどん行って来いｵﾗｧ！」みたいな感じだったわけですが。 内容は、自分が少し詳しいテーマで、30分以上話せる内容にしました。自分が送っていいのかな…という気持ちも少しありましたが、当時はそもそ
オープンソースでDroidKaigiのカンファレンスアプリ作ってる - Konifar's WIP
DroidKaigi 2016がいよいよ来週開催されます。 ふとした思いつきでDroidKaigiのカンファレンスアプリを作ったところ公式アプリとしてリリースさせていただくことになり、今現在完全オープンソースで色んな人がコミットしてくれています。スピード感あってなかなか面白いので、忘れないうちに経緯をまとめておこうと思います。 github.com アプリは現在こんな感じです。デモとしてアラビア語表示にも対応しています。 1/11（月） DroidKaigiの発表準備しないとまずいと焦り始めました。 最近は発表の内容に合わせてサンプルアプリを作って公開するようにしているんですが、ただのサンプルコードだと飽きちゃうので何を作ろうかなぁと考え始めました。 そこで思いついたのが、DroidKaigiのカンファレンスアプリでした。みんなが使えるアプリなら懇親会の時の話のネタにもなるし、ぼっちにもな
アニメの名言を簡単に引用できる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
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
社内でSHIROBAKOを広めるためにやったこと - Konifar's WIP
SHIROBAKOはアニメ制作の現場を描いたアニメです。全24話全てが神回と言っても過言ではなく、仕事をする上での姿勢やチームワークの大切さなど本当に学びが多いです。 shirobako-anime.com 人に好みのアニメを押し付けるのは申し訳ないので普段は何も言わないんですが、 SHIROBAKOはどうしても社内のメンバーにも見てもらいたくて、ついに布教してしまいました。少し前の話なんですが、どんな空気になったのかまとめておこうと思います。 結論から言うと、意外とみんな温かく受け入れてくれた上に実際に見てくれたメンバーもいたので、個人的には満足しています。 QiitaTeamに投稿 チームの情報共有にQiitaTeamを使ってるんですが、 『チームメンバーに見てもらいたいアニメSHIROBAKO』というタイトルでしれっと投稿してみました。 反応なければやめようと思ってたんですが、投稿し
エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP
非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー
毎日皆が見るところにKPIを出す重要性 - Konifar's WIP
自社サービス運用している会社では、KPIを設定して数字を追っているところが多いと思います。 どんなKPIをどう計測するかはサービスによりけりなのですが、弊社では重要なKPIを毎日チャットに流すようにしていて、これが結構良い効果をもたらしているので、どんな雰囲気になるのか簡単にまとめておこうと思います。 朝9時に毎日Slackに流れる DAU、 新規ユーザー数、 翌日継続率をSlackに流すようにしてます。『KPI』というチャネルを作っていて、毎日9時に マスコットキャラのTabbyが教えてくれます。可愛いです。 Slackはメンバー全員が必ず見ます。メールは見ないこともありますが、Slackは確実にチェックします。 この 毎日皆が見るというのは、実はかなり重要なことです。 異変にすぐに気づく 分析サービスやSpreadSheetを見に行かなくても毎日流れてくるので 異変にいち早く気づくこと
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
