タグ

ブックマーク / konifar.hatenablog.com (14)

  • マネジメントとしての意思決定振り返り - Konifar's WIP

    Engineering Manager Advent Calendar 2023 15日目の記事です。 KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。 体系的な話は HIGH OUTPUT MANAGEMENT や エンジニアリング組織論への招待、エンジニアリングマネージャーのしごと といった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。 KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP Engineering Managerをやめた - Konifar's WIP 先に書いておくと、綺麗にうまくいった / いっているという話は

    マネジメントとしての意思決定振り返り - Konifar's WIP
  • バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP

    1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました!」「Aクラスのドラゴンを相手にしてる最中だってのに!」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野(しっぽ) (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペインエンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペインエンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何

    バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
    ginga0118
    ginga0118 2018/06/15
    会社でも使ってみよう
  • 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 公式アプリのOSS成功要因 - Konifar's WIP
  • アウトプットは完璧を目指しつつ目指しすぎないようにしたい - Konifar's WIP

    今日、初Androidライブラリを作って公開してみました。 github.com Google I/O 2015で追加された、Floating Action Buttonの動きを簡単に実装できるUIアニメーションライブラリです。MaterialDesign関連かつ、みんな大好きFloating Action Button系だったということもあって、それなりに反応があってよかったです。 今回のライブラリ公開もそうなんですが、最近 アウトプットを出したい時には完璧を目指しすぎない方がいいんじゃないかなぁと感じているのでちょっと考えをまとめておこうと思います。 「アウトプットの内容によるよね」という意見はその通りで、会社の大事なプレゼンとかそういうのは完璧を目指すべきだと思います。今回は、ブログ書いたりとかOSS活動したりとか、個人の活動にフォーカスして考えます。 荒削りで公開したライブラリ 今

    アウトプットは完璧を目指しつつ目指しすぎないようにしたい - Konifar's WIP
  • 帰宅前の溢れるやる気を持続させる - Konifar's WIP

    他の人はどうかわからないですが、自分は 会社から帰宅する前にやる気が異常に高まることがあります。 仕事でも個人の活動でも「今日は家帰ったら朝までやってやるぜ」みたいな感じで、何でもできそうな気がするくらいやる気に満ちあふれるんですよね。完全にやる気MAX状態なんですが、そのほとばしるやる気のままに行動するかというと、まぁ実際はうまくいかないことが多いです。 参考までに、自分のダメパターンを書き出してみます。 まず家帰って飯って、ちょっとゆっくりしたら 「あれ?俺のやる気どこ行っちゃったの?」ってなり始めます。 23時くらいに 「よっしゃ23時半からやるぞ!」と思ってアニメ見てたら23時34分くらいになります。 「キリが悪いから0時からオールで頑張るぞ!」とか思ってたらいつの間にか1時になってて、 「まぁ6時まで5時間もある!俺たちの夜はここからだ!」とか考えつつTwitter見てたら2時

    帰宅前の溢れるやる気を持続させる - Konifar's WIP
  • すごそうに見える先輩も実は成長途中だったりする - Konifar's WIP

    先日、後輩エンジニアコードレビューで「ここはこうした方がいいと思うよ」みたいな指摘をしたら、 「けど、前にkonifarさんにこう言われたから…」というコメントが来て、めちゃくちゃ申し訳なくなりました。 実はこういうやり取りたまに発生するんですが、毎回心苦しい思いをします。言われた側からすると 「前と言ってること違うじゃん…」って感じるんですよね。自分もそういう経験があるので、当に申し訳なく思います。 前は考えが違ったんだよと言ってしまえばそれまでなんですけど、後輩に理不尽な思いをさせるのも嫌ですし、どう感じているのかちょっとまとめておこうと思います。 先に補足しておくと、自分の言い訳メモみたいな話なので、万人に当てはまるものではないです。 先輩も未熟かもしれない なんかすごそうに見える先輩も、実は未熟だったりします。これはスキルレベルが低いということではなくて、 初めての分野で先輩自

    すごそうに見える先輩も実は成長途中だったりする - Konifar's WIP
  • エンジニアの「できない」という言葉の裏側 - Konifar's WIP

    「ここ、こんな感じにできませんかね?」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか?」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「(できるけどやり

    エンジニアの「できない」という言葉の裏側 - Konifar's WIP
  • 社内でSHIROBAKOを広めるためにやったこと - Konifar's WIP

    SHIROBAKOはアニメ制作の現場を描いたアニメです。全24話全てが神回と言っても過言ではなく、仕事をする上での姿勢やチームワークの大切さなど当に学びが多いです。 shirobako-anime.com 人に好みのアニメを押し付けるのは申し訳ないので普段は何も言わないんですが、 SHIROBAKOはどうしても社内のメンバーにも見てもらいたくて、ついに布教してしまいました。少し前の話なんですが、どんな空気になったのかまとめておこうと思います。 結論から言うと、意外とみんな温かく受け入れてくれた上に実際に見てくれたメンバーもいたので、個人的には満足しています。 QiitaTeamに投稿 チームの情報共有にQiitaTeamを使ってるんですが、 『チームメンバーに見てもらいたいアニメSHIROBAKO』というタイトルでしれっと投稿してみました。 反応なければやめようと思ってたんですが、投稿し

    社内でSHIROBAKOを広めるためにやったこと - Konifar's WIP
  • 圧倒的に成長している時は実感がない - Konifar's WIP

    若いヨルダン人エンジニアの後輩がいるんですが、彼は当に前のめりで成長に対して貪欲です。 入社してすぐに「家で勉強するのに良い資料はありますかッ?!」と聞いてきたり、GW前には「何を作ったらいいですかッ?!」と聞いてきたり、とにかく勢いがすごいです。こういう訳がわからない前のめりさはとても重要だと思っていて、何かしら力になりたいなぁと思ったりします。 で、この前も昼時に 「konifarさんは新卒の時どんな風に成長したんですかッ?!」と聞かれまして。覚えてることを話したんですが、ふわっとしたことしか話せなくて申し訳なくなってしまいました。 自分でも成長とは何なのかよくわかってないなぁと感じたので、思考整理してみようと思います。 未来の成長は想像しにくい 自分は正直、『成長する』というのがどういうことなのかよくわかってません。 就活の時に、「他の会社の5年分を1年で身につけられますよ!」みた

    圧倒的に成長している時は実感がない - Konifar's WIP
  • 仕事で質問する時に意識していること - Konifar's WIP

    最近若いヨルダン人エンジニアが入社してきまして、新卒の頃の自分を見ているようですごく懐かしい気持ちになります。 当然わからないことも多いので色々質問してくれるんですが、 質問の仕方をもう少し工夫した方がお互いに効率いいんじゃないかなぁと感じて注意することがあります。すごく素直な子なので、注意するたびに「はいッ!すみませんッ!」と流暢な日語で答えてくれるんですが、逆に何度もそんなやり取りさせて申し訳ないなぁと思ってしまいます。 で、注意しつつも「自分自身こういうところに気をつけて質問してるよ」というのをちゃんと整理できてないなぁと思ったので、今後のためにもざっとまとめておこうと思います。 自分は小さい会社でエンジニアとしてしか働いたことがないので、他の会社では当てはまらないかもしれないです。あくまで 自分が仕事で質問する時に意識していることとしてまとめます。 タイミングを見計らう 大体みん

    仕事で質問する時に意識していること - Konifar's WIP
  • エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP

    エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー

    エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP
  • 個人アプリ開発中の寂しさをbotで紛らわす - Konifar's WIP

    個人のアプリ開発は楽しいです。けど時々寂しいです。 例えば深夜にアイコン作ってる時とか。 「いつもはデザイナーさんに助けられてるけど自分でやらないとなぁ…」とか考えて、無性に寂しくなったりします。ちょっと前からこの寂しさを何とかしたいなぁと思っていました。 で、今は Slackにhubotを住ませて1人じゃない感を演出することである程度解決しているので、どんな雰囲気で開発しているかまとめておこうと思います。 先に言っておくと、あくまで自分はこうやってるよという話なので 趣味がかなり入っています。以後その点だけ注意をお願いします。 統一された世界観を作る プロジェクトごとにSlackのチャネルを作ってそこに全て集約しています。GitHubのアクティビティ通知、CI結果通知、メール問い合わせ通知などですね。 ここで自分が大事にしてるのは、 統一された世界観を作るというところです。 例えば この

    個人アプリ開発中の寂しさをbotで紛らわす - Konifar's WIP
  • エンジニアに必要な説明能力 - Konifar's WIP

    最近、業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、

    エンジニアに必要な説明能力 - Konifar's WIP
  • 非エンジニアの嫁にエンジニアの仕事をわかってもらうために工夫したこと - Konifar's WIP

    嫁は専業主婦なんですが、エンジニアがどういうことをやっているのかをある程度理解してくれていて色々と捗ります。ただ嫁に限らずエンジニアじゃない人にエンジニアのことを理解してもらうのは結構難しくて、どう実現していったかを簡単に残しておこうと思います。 問題意識 仕事柄、突発的に問題が起こって帰りが遅くなることはざらにあります。特にリリース前は忙しくて帰りが遅くなることも多く、帰るたびに説明責任を果たす必要がありました。 また仕事以外でも勉強のために家で開発をしたりブログを書いたりすることも多く、ジトっとした目で不満を訴えかけられていました。 これは毎回同じような対応をするよりも、根的に教育した方がいいかなぁと考えていました。問題の質は 何をやってるか想像もつかないことにあると思ったからです。 クイズを出す こんな会話をしてました。 俺「(画面を見せながら)このボタン何%くらいの人が押すと思

    非エンジニアの嫁にエンジニアの仕事をわかってもらうために工夫したこと - Konifar's WIP
  • 1