Engineering Managerをやめた - Konifar's WIP
この記事は Kyash Advent Calendar 2021 2日目の記事です。 2020年1月から2021年6月まで、1年半ほどKyashでEngineering Managerをやっていました。2021年7月からはロールを変えて、QAチームのいちメンバーとしてAPIのテストやテストの効率化に取り組んでいます。 EMをやめた経緯とやめた後の所感を備忘として残しておきます。 EMとしてやっていたこと 2020年にやってきたことは去年まとめました。 konifar.hatenablog.com 2021年は、共有口座やイマすぐ入金、セブン銀行出金などのリリースに向けてMobile / サーバーサイド / QAのチームでプロジェクトを進めたり、プロダクト開発フローを整えたり、エンジニア採用のリードをしたりしていました。 EMをやめるきっかけ そんな中で、3月くらいに「なんだか最近仕事が面白
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が見ていましたが
Kyashに入社して1年3ヶ月くらい経ちました - Konifar's WIP
時が経つのは早いもので、入社半年くらいの時に近況を書いてから9ヶ月くらい経ちました。 課題はたくさんありますが、今までの経験の中では結構楽しくやっているので、あとで見返せるように記録を残しておこうと思います。 やっていたこと プロダクト開発全般 : ユーザーサポート : 採用 = 6 : 3 : 1 くらいでやっていました。 プロダクト開発全般 Android、API、Webサイト、社内ツール ユーザーサポート SNS対応、レビュー対応、問合せ対応、効率化のためのツール開発 採用 ブログ執筆、Meetup登壇、スカウト、面談・面接 プロダクト開発全般 ユーザーの目に触れる大きめの開発だと、以下の3つくらいです。見返してみると結構少ないですね。 polcaやAudiostockから報酬をKyashで受け取り Android セブン銀行チャージ Android カードから金額指定してチャージ
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登壇におけるKyashを使った投げ銭の経緯と結果 - Konifar's WIP
先日DroidKaigiで登壇した際、自社プロダクトであるKyashの紹介とアイスブレイクを兼ねて「もしもこの発表がよかったなぁと感じていただけたら、このスライドのQRコードから39円*1送ってみてください」と言ってみたところ、 25人の方から7,400円もの投げ銭をいただきました。 送っていただいた皆さん、本当にありがとうございました。想像の10倍以上のフィードバックをいただいたので、事の経緯と結果を備忘として残しておこうと思います。 経緯 念のため先に言っておくと、「最高だったからみんなKyashで登壇投げ銭やっていこうぜ」という話ではないです。Kyashはまだ機能も投げ銭に最適化されているわけではありません。法規制やタスクの優先順位を鑑みて、Kyashが会社として投げ銭を訴求していくにはまだ尚早だと考えてきたからです。 たとえば、現状の仕様だと送金時に本名が表示されますが、クリエイタ
DroidKaigi2018で発表したFlutterアプリの話のスライド補足 - Konifar's WIP
DroidKaigi2018で『コードで見るFlutterアプリの実装』というタイトルで話をしてきました。 speakerdeck.com 聞きに来ていただいた皆さん、資料を読んでフィードバックをくれた皆さん、運営の皆さん、発表前に場を温めていただいた @mhidakaさん、ありがとうございました。 スライドだけだと話がわかりづらいところもあると思うので、書き起こし形式で補足しておこうと思います。当日用のスライドを一部削ったり、アドリブの台詞を省いたりはしています。 ちなみにこのやり方は、@yanzmさんが去年、今年にやっていてとてもよいなぁと思ったので真似させていただきました。 コードで見るFlutterアプリの実装 今日はFlutterアプリのコードの話をします。Flutter自体の内部の詳しい実装ではなく、Flutterでアプリを作る時にどうコードを書くのかという話です。よろしくお願
FlutterでDroidKaigi 2018のiOSアプリを作りました - Konifar's WIP
DroidKaigi2018が来週に迫ってきましたね。 自分もコードで見るFlutterアプリの実装というテーマで発表します。 その題材として、DroidKaigi2018のiOSアプリを作りました。コードも公開しています。 github.com 作った理由は、以前の記事に書いたとおりです。 また、公式アプリではないですが今年はiOSアプリも用意したいなぁと思っています。iOSDC2017に参加した時にAndroidアプリが欲しいと思ったからです。 まだ申請中なので間に合うかどうかわかりませんが、iOS端末がメインの方に使っていただけると嬉しいです。 DroidKaigiの発表では、時間の都合上Flutterの基本的な部分の説明は省くつもりなので、ここで簡単にまとめておこうと思います。 Flutterとは Flutterは、iOS / Androidで動くアプリを作れるクロスプラットフォー
iOSDCで『Sketchからアイコン切り出し ⇒ Asset Catalogを自動生成 ⇒ 差分があればPullRequest』という流れをCIで自動化する話をしました - Konifar's WIP
2ヶ月くらい前にiOSDC 2017のプロポーザルを出したんですが、2つ出したうちの1つが採択されたので登壇してきました。 speakerdeck.com サンプルリポジトリはこちらです。資料だけだとわかりにくい部分もあると思うので、少し補足しておこうと思います。 Import Sketch Icons to Asset Catalog on CI Sketchからアイコンを切り出して、Asset Catalogを生成して、差分があったらiOSのリポジトリにPull Requestを出すというのをCIで自動化している話です。 私の所属するQuipper Limited.で実際に運用している知見です。 @konifar konifarという名前で、TwitterやGitHubをやっています。 プライベートで、専業主婦の嫁さんとエンジニアリングやエンジニアの仕事に関する雑談をするyome.fm
誰かにフィードバックを伝える時は内容よりも伝え方を工夫した方がいい - Konifar's WIP
主にTwitter上での話ですが、誰かの行為や何かのイベントに対するフィードバックを目にします。 「なるほど、わかる」と内容は理解できてもなんだか共感できないことも多くて、ただなぜ共感できないのか自分自身ちゃんと説明できなかったので、思考整理のために文章にまとめておきます。 先に結論をかいておくと、『その発言がフィードバックなのか単なる愚痴なのかを明確にした上で、フィードバックなのだとしたら感情や認識齟齬といったノイズを減らすように伝え方を工夫したほうがよい』という話です。Twitterくらい好きにやらせてよという話はごもっともで、それが『愚痴』なのだとしたらよいと思います。 過剰な怒りが含まれているかどうか たとえば『イベントの運営の対応が悪い』と感じた時、怒りの感情がぐわっと湧き上がることもあるでしょう。「なんでこんなに手際が悪いんだ」「普通に考えればありえないだろ」「運営は馬鹿なんじ
DroidKaigi 2017 アプリコード公開してから10日経ちました - Konifar's WIP
DroidKaigi 2017のアプリのコードを公開して10日ほど経ちました。 忘れないうちに今の状況をざっとまとめておこうと思います。 konifar.hatenablog.com PullRequests、Contributors こ10日間のPullRequestは200件くらいでした。Contributorsは60人くらいです。すごくたくさんの方々に毎日修正や改善を送っていただいて、本当にありがたいかぎりです。 公開して5日間くらいは1日30件くらいPullRequestが来ていました。あまりに速すぎて、Issueにアサインしても同じPullRequestが30分くらいの差で送られてきたこともありました。迷惑をかけてしまって申し訳なかったです。 コンフリクトしてしまうと申し訳ないので、基本的にPullRequestはすぐに見ています。小さい修正であれば即LGTMを出し、CIが完了し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
