VPoE READMEを書いて3ヶ月経った振り返り - Konifar's WIP
2022年1月からKyashで VP of Engineering（以下、VPoE）という役割で開発組織全体を見ています。VPoEになった背景はまた別途書くとして、この3ヶ月は反省も学びも多かったので振り返りを書いておきます。 自分がVPoEになった時、VPoE README というドキュメントを社内に共有しました。同じ内容をKyashの採用GitHubリポジトリで公開しています。 github.com 今回はこれを自分で読み返して引用する形で振り返ってみます。先に注意をしておくと、体系だった話やどこでも応用が利くような話というよりは、完全に自分個人の振り返りの内容になっています。 README書いてよかった READMEを書く目的を以下のように書いていました。 VPoE の最初にやるべきことは、何をミッションにして何をやっていくかを定義し、周囲に理解してもらうことだと考えています。その一
新人にイラついてしまった時の備忘 - Konifar's WIP
組織にとって新人は期待の風です。しかしその期待の振り幅が大きい分、逆にイラついてしまうこともあります。 「何回も同じこと注意するの嫌だなぁ」とか「もっと考えてきてほしいなぁ」というのがよくある話ですが、ふとした時につい強く言ってしまうことがあるんですね。で、あとでいつも後悔するわけです。イラつきというのはそれ自体で何かがよくなるわけではないし、無駄に疲れるし、自分にとっては害でしかないです。 あとで自分で見返せるように、新人にイラついてしまった後に後悔しながら考えていることをまとめておこうと思います。先に言っておくと、ほとんどマインドセットの話なので万人に共通するような話ではないです。 期待を共有する 「なんでこんな完成度で出してきたんだ。。全然ダメじゃん」とイラついた時は、アウトプットに対する期待が相手の考えるレベルと食い違っているのかもしれません。その場合、「ちゃんとやれよ」という注意
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 忘
朝の自由改善開発、進捗いいです - Konifar's WIP
クックパッド社の 朝Lint活動の記事を見て、最高じゃん…！と思い自分も真似して運用してみることにしました。 techlife.cookpad.com とりあえず自分だけで勝手にやることにしたので 「Lint警告解消に限らずやりたいこと好き勝手やってやるぞ！」って感じで2週間くらいやってみました。わりと進捗よくて成果出てきた気がするので、どう考えて何をやったかを残しておこうと思います。 なぜやろうと思ったのか 普段の開発タスクに追われて細かいところに手がつかず歯がゆい思いをしていたからです。 今作っているTaptripはグロースフェーズにあり、新規ユーザーの流入やDAU・MAUの向上といった数字から逆算した施策を高速にこなすべく開発を進めています。 この方針自体には納得しているんですけど、直近で数字が出るかよくわからない細かい改善というのはやはり優先度が低くなってしまうんですよね。そしてそ
仕事を任された時は目的を意識した方がいい - Konifar's WIP
後輩から質問された時、質問の意図がわからなくて「これってそもそも何のためにやってるんだっけ？」と逆に聞き返すことがあります。 で、たまに「わかりません」と返されることがあって、「じゃあなんでやってるの？」と聞くと、だいたい 「○○さんからそう言われました」という感じの返事が返ってきます。 これ別に後輩だけが悪いわけではないんですけど、そういう仕事のやり方だと色々しんどいだろうなぁと思うんですよね。ただ、じゃあどうすればいいのかってところを整理できてなくていつも伝えられないので、思考整理しておこうと思います。 もちろん仕事のやり方というのは組織によって様々ですし、全てのケースで当てはまるものではないと思います。また、そもそも仕事を渡されるのを待ってる時点でダメだろみたいな考えもあるかもしれませんが、あくまで自分自身の整理としてまとめます。 言われたことをそのままできるのも重要 まず勘違いして
「できない理由よりできる理由を考える」を人から言われると辛い - Konifar's WIP
「できない理由よりできる理由を考える」という言葉があります。 ◯◯だからできませんとか言ってても仕方ないから、やると決めたらどうすればできるか考えたほうがいいよね、という考えです。 自分はこの「できない理由よりできる理由を考える」みたいな文化の組織でずっと働いてきました。前職も今の職場も同じ雰囲気なのでやりやすいです。 ただ、この言葉は時に反感を覚えるというか、なんかすんなり受け入れにくいことがあるなぁと感じていました。一言で言うと 「なんかイラッとする」ってやつです。 そう感じるのはなぜなのか整理できてなくてよくわからないので、ちょっとまとめておこうと思います。 言葉自体には納得してる 「できない理由よりできる理由を考える」という言葉は、仕事をする上での姿勢としてはとても納得しています。 仕事をしていくと大変なことでもやりきらないといけない状況というのはたくさんあるので、その度にできない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
