タグ

Managementに関するkazuomabuoのブックマーク (10)

  • 体制を考えるときに意識していること - id:onk のはてなブログ

    1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

    体制を考えるときに意識していること - id:onk のはてなブログ
  • 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎

    ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」>「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ(解決策わからない) では詳細を書いていく。 勝手に学ぶ人:自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人

    「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎
  • ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary

    早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントやがあるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基的にそのためにやることは3つしかないと

    ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary
    kazuomabuo
    kazuomabuo 2023/03/03
    動機づけがすごく近い。まぁ、そんなもんかもな。
  • カスタマイズをしない

    自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して+アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう

    kazuomabuo
    kazuomabuo 2020/12/07
    カスタマイズの意義は常に考える。
  • 部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;

    マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと!」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事エンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい

    部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
  • 【後編】転職活動で気づいた、採用が下手な会社と上手な会社 - ジンジニアニッキ!

    前回の続きです。 前回のエントリーが予想外にバズっており、小心者の私は非常にビビっております。 皆様のコメントがとても優しいのが嬉しいです。 ところで、ブコメの中に「お見送りの理由ってわかるものなの?」といった反応があったのが目に留まりまして…。 返答としては、「できるエージェントを利用していると、わかる場合も多い」です。 できるエージェントの人は採用企業側からも信頼がされているため、面接後の感想や評価を回収することができます。 自己応募だと企業側の反応やフィードバックを手に入れることはなかなか難しいですので、転職活動においてエージェントを利用する大きなメリットだと思います。 採用が上手だなぁと思った会社に見られる共通項 前回書いたことの反対です。 …と言うと元も子もなくなってしまうので、頑張って書きます。 良い印象を持った会社や面接に共通して言えることは、「素早く」「誠実で」「丁寧な」対

    【後編】転職活動で気づいた、採用が下手な会社と上手な会社 - ジンジニアニッキ!
  • 【前編】転職活動で気づいた、採用が下手な会社と上手な会社 - ジンジニアニッキ!

    様々な事情があってしばらく自宅警備員をしながら転職活動をしていたのですが、ようやく落ち着いたので書いています。 タイトルちょっと煽り気味ですが、今回の転職活動では20社くらいの話を聞いたりしていました。 そこで「なるほどなぁ」って思うこともあったのでちょっとまとめてみようかなと思った次第です。 記事をを書くにあたっての前提として、自分のステータスですが 後期アラサーなので社会人経験も人生経験がそれなりにあり、第二新卒ではもうないし、「若手」とも言えずベテランに片足突っ込んでる感じ 人材紹介会社にいたりコミュニティにいたり採用人事やってたりなどしているので、IT業界の他社のことはなんとなく情報が自動的に入ってくる (転職活動の中で気づいたことだが)経験年数の割にどうやら仕事上の修羅場経験はそこそこある 今回は人事とかバックオフィスとかのいわゆる「ビジネス系職種(エンジニアではない)」で転職

    【前編】転職活動で気づいた、採用が下手な会社と上手な会社 - ジンジニアニッキ!
  • 社内横断の技術組織を終わらせました - nottegra’s blog

    内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が

    社内横断の技術組織を終わらせました - nottegra’s blog
  • なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列

    営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか? 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン

    なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
  • なぜ会社はダメな管理職を「降格」しないのか。

    一般的にリーダーをヒラ社員に戻したり、部長を課長にしたりする「降格」が行われている会社は少ない。 降格することが人のプライドを傷つけたり、ヤル気を損なわせたりすることを経営者が危惧するからだ。 しかし、中にはこれをうまく使っている会社もある。 あるテクノロジー企業では「降格」を人事制度の一種として普通に用いており、社員からも普通に受け止められている。 なぜ彼らは降格をうまく使うことができているのか。 その会社の経営者は30代半ばである大手企業から独立し、起業したやり手だ。 彼は独立する前、大手企業で働いている時、常にこう思っていたという。 「有能な管理職が少ない、なぜ、あれほど多くの無能な上司が上に立っているのか?上が入れ替われば、もっと事業はうまくいくのに」 彼は社内で「できる」とされる役員に、この質問をぶつけたという。するとこんな答えが返ってきた。 「うちは年功序列だからな。必ずしも

    なぜ会社はダメな管理職を「降格」しないのか。
  • 1