手を動かさないマネージャーを試している - id:onk のはてなブログ
2 月から、Mackerel チームの所属になった。 今日から異動して Mackerel チームです。非正規ルートでの要望でもいい感じにやるので何でもください！— Takafumi ONAKA (@onk) February 1, 2023 これを期に、せっかくなのでコードを読まないマネジメントスタイルを試してみようと思って、実践している。 今までは自分が一番プロダクトのコードベースに詳しい状態を作ってきていて、障害対応でも嬉々として先頭に立つようなテックリードスタイルだった。 この姿が天職と思っているが、今までの人生で、コードの細かい話が通じない (というか、共通言語や会話のレイヤーが違う) けれども非常に信頼できるマネージャーと仕事をしてきた経験はあるので、自分も彼らのようなムーブが可能なんだろうかとやってみたくなったのだ。知識欲が減衰した老害化現象ではないと思う。きっと、たぶん。 も
オンボーディングの作法。入社してくる仲間のお手並みを拝見するな。 - フジイユウジ::ドットネット
今日はチームメンバーのオンボーディング時の作法、チームでの仲間の受け入れまたは受け入れられについて書きたいと思います。 ここ最近、ぼくは自分で会社をやりつつ、色々なスタートアップや事業会社にも入らせていただいて一緒に事業をやったりプロダクトを頑張ったりマーケティングをアレコレしたりしているのですが、その関係もありチームメンバーを沢山迎え入れることもあれば、新しいチームに迎え入れてもらう側ということもあります。一般的な人よりも両方のオンボーディング機会が多い人生を歩んできました。 そこで気づいたことというか、経験してみて考えたことを書いていこうと思います。 つよつよ人材が有名企業から来てくれたけど特に活躍しないで消えていくあるある GAFAや有名な企業・スタートアップで働いていたとか、いわゆる「つよつよ」とされる人。当然「つよつよ」と言われるのだから優秀であると認識されていると思います。 で
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
不満への過剰な共感は状況を悪化させる - Konifar's ZATSU
何かを相談された時、自分は相手の状況や主張にまず共感を示してしまいがちである。嘘をついて同調しているわけではないのだが、この姿勢自体が状況を悪化させることもわりとあるよなと思っていて、雑にまとめておきたい。 たとえば「他チームの◯◯さんが開発の状況を理解してくれていない。理解する気も見えない」といった相談をされたとする。それに対して、「あーなるほど、たしかにねぇ」みたいなことを言った瞬間に、溝を広げることになってしまうかもしれない。 この場合、本来はお互いの歩み寄りが必要な話なのだが、相談してくれた側に寄り添って話すことで当事者間の関係性がよくなるどころか悪化することもありうる。吐き出してスッキリするかもしれないが、根本の解決にはならない。 チームメンバー思いのマネージャーや組織の中の"いい人"ほど、知らず知らずのうちにこの罠に陥りがちな気がする。おそらくコーチングを学んだ人はこういう相談
失敗しない業務の兼任 〜兼任しても良い業務としてはいけない業務について〜
本業と副業であったり、あるいは本業の中での複数の業務であったり、仕事をしていると業務の掛け持ちというのはいずれ発生してきます。 それは自らの希望である場合も、組織の都合である場合も存在しますが、これが一度発生すると、以降複数の業務に対して自分のリソースをどう分配するかに頭を悩ませ続けることになります。 私自身、これまで幾度となく業務の兼任は経験してきましたし、その中でうまくいったものもあれば、失敗したものも勿論あります。 この記事では、そんな自分の経験を思い出し、私ならの業務の兼任に対しての結論について述べたいと思います。 兼任しても良いたった二つの業務 結論から言うと、兼任しても良い業務は、その片方が「プロジェクト型の業務であり、短期で完結するもの」または正反対の「期日などが厳格でなく、ベストエフォートでのコミットが許容されるもの」のみであると考えています。 そして多くの業務はその構成員
開発プロセスの変遷モデル - shimobayashiパブリック
#チェンジマネジメント 通称: #下林モデル 学術的な研究などに基づかない個人の感想ですが、 おそらく日本企業の一般的なウェブサービス開発プロセスは以下のような変遷をしてきたと思う。 進んだフェーズが偉いわけではない点に注意。 適用できる領域によって使い分ければ良いだけで、どのフェーズも成果にフォーカスはしている。 すでに成果が出ているなら、リスクやコストを背負ってまで次のフェーズに進む必要性は無い。 ただし、不確実性が高まり続けている時流を鑑みると、進んでいく必要は遅かれ早かれ出てくるはず。 そしておそらく、フェーズN→フェーズN+1への変遷と比較して、フェーズN→フェーズN+2への変遷は非常に難易度が高い。 なぜなら、進むべき理由を組織が共有できないため。 また、現実のフェーズはフェーズ1.6だったり、フェーズ2.3だったり、グラデーションの中にある。ここに書いたことは目安にすぎない。
うちのチームのデイリースクラム 2021年夏編 - 半空洞男女関係
「自分ができるタスクもうないので次のスプリントのPBIに着手します」問題をなるべくわかりやすく説明したい。良い例え話あるかな。— ama-ch (@ama_ch) August 6, 2021 を見ていて、うちのチームのデイリースクラムを紹介したくなったのでかいてみます。こういうのを書くのははじめてかもしれない。 全体デイリースクラム まず、決まった時間になったら一つの部屋に集まって、全体のデイリースクラムをする。今は3チームくらいあるので、全体でやりとりしたいことも多い。 全体のゴールとかあるわけでもないので、ただの朝会って感じ。(「朝会」でいいのかも) チャットで報告でおしまいでもいいのだが、「知らなかったー」とかはあるので、共有したい勤怠の連絡事項とか、今日はリリースがありますねーとか、この前の障害についてですがー、などなど、全体で知っておきたい情報はここで共有する。 現状、品証チー
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
グレードイメージ具体化のため昇格理由を公開する
スマートロック開発におけるSLI/SLOを用いた解錠体験の改善 / Improving the unlocking experience using SLI/SLO in smart lock development
成果で評価していくということ - そーだいなるらくがき帳
最近、この話をすることが多いのでブログに個人的な意見をまとめる。 まず成果主義と結果主義は違う。 勘違いされてる人が多いけど成果主義は成果とそれまでの過程を踏まえて評価する。 結果主義はその言葉の通り、結果のみで評価する。 そのため売上を至上と置いてる営業の評価をする場合などは結果主義はわかりやすい。 個人的な意見では結果主義は嫌いではないし、スポーツなどは完全に結果主義だ。 それは置いといて、多くの会社は成果主義であるし、だからこそちゃんと成果で評価すべきだ。 その点について次のようにまとめる 成果を評価するということ 成果を評価するためには 目標を設定すること と 行動すること が必要だ。 行動した結果、成果が生まれ、そしてその成果が目標を達成したかを評価する。 結果主義であれば目標に対して、成果がどの程度達成したかの差分だけで評価する。 成果主義はその過程も評価するので達成した上で、
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンドアポリシーはゴミ - 下林明正のブログ
AbemaTVの開発スタイル