マネジメント半年くらいの自分へ - Konifar's ZATSU
あの頃の俺に伝えたい内容を雑に書く。 本を読め お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。 他社のマネージャーと話せ 社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。 引き出しを増やせ マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。 どこで成果を出すかを決めろ 自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編）
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
「できない理由」を並べる人々は、とりあえず無視して構わない。
コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか？」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか？」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には？クレームが来る、という事でしょうか？」 営業「まあ、そうかもしれません。」 企画「か
My 8 Best Techniques for Evaluating Character
I do a lot of odd things at The Honest Broker. Some days I even give advice. Today is one of those days. A few readers will dislike this post—mostly because I’m going to be brutally honest. Even worse, I’m gonna be judgemental. And that’s a big pet peeve among people who judge such things. (Footnote: See point 5 below.) But if I’m foolhardy enough to call myself the Honest Broker, I do have to tel
お答え申し上げます。 ブコメでもすでに指摘されているように、現在元増田..
お答え申し上げます。 ブコメでもすでに指摘されているように、現在元増田さんには上司として必要な能力に欠けているというのが結論になるだろうと思います。 ですが、それだけだと具体的に何がどう欠けているのかがおわかりにならないだろうと思い、100字ではとてもしたためられないため、このようにトラバで記しましたので、しばしお付き合いください。 まず元増田さんは「会社で怒鳴ってしまう自分は間違っていないと思うのですがどうですか？」と質問をしているわけですが、第三者がその是非を判断する場合最低限必要になる情報があります。 部下はどんな人間なのか、周囲の部下の評価はどんなものか（元増田さんの部下の評価との間に乖離はないか）、部下に施した教育はどんな仕方なのか、部下に与えたタスクの難度はどの程度か、部下は勤続何年目なのか、貴方は勤続何年目なのか、部下と貴方の歳の差はどの程度なのか、貴方の部下に対する叱責的な
1on1.md
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
重大事故の時にどうするか？｜miyasaka
ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して
権限を持つと人は偉そうになってしまう
最近配置転換があり、昇格してさまざまな権限を持つようになった。社内のほぼすべての書類を見ることができ、社員の管理ができ、各社員の給与を見ることのできる権限をもらい、予算の裁可権限までもらった。 権限を持つようになると「○○さんが知ってるよ」という情報をどこかから得てきた人が「お忙しいところすみません」というふうに声をかけてくるようになった。今までもそういう声かけは皆無ではなかったとはいえ、明らかに急増した。これが実に煩わしい。煩わしいので、一時しのぎの雑な対応になる。雑な対応になると「お忙しいところ申し訳ありません」というふうに声をかけられるようになる。権限がない人からすると、権限がある人になるべく早くやってもらわないと仕事が進まないのでどうしてもそうなるのだ。 そして、誰がどういう業務をやっているのかかなりハッキリ見えてくるようになった。これはすごい。まるで王様にでもなったかのような気持
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
Ayo.js について - from scratch
Ayo.js とは 「Node.js の fork です。」と言ってもまだできたばかりで正直このタイミングで記事にしてもまだ語ることはそんなに多くないです。 ただし、JavaScript界隈が騒ぎになりかけていることは確かです。日本でも発言が増えてきたので自分なりにまとめて今時点での話をしようと思います。 ちなみに読み方は好きに読んでくれ、と言われてます。 「アイ・オー」でもいいし、「エイ・ヨー」でも良いとのことです。ネーミング的には昔あった io.js fork騒動を想起させるネーミングになってます。もしも io.js についてご存じない方もいるのであれば、こちらをご参照ください。 yosuke-furukawa.hatenablog.com Ayo.js の目的 https://github.com/ayojs/ayo/blob/zkat/values/VALUES.md ここを見ると
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
https://thepedia.co/article/2298/
See related links to what you are looking for.
割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]
ピクシブ株式会社 Advent Calendar 2016 @8日目の記事です。 こんにちは、エンジニアのdo7beです。pixivFANBOXの開発などに携わっています。 さて、今回は新規開発プロジェクトに「割れ窓理論」を導入してサービスのクオリティ向上に繋がった話をご紹介したいと思います。 割れ窓理論とは 「割れ窓理論」とは、アメリカの犯罪学者ジョージ・ケリング氏が提唱した「建物の窓ガラスが割れたまま放置されると住民もゴミを捨てるようになり、治安が悪化し、より重大な犯罪が発生してしまう」という理論です。 つまり軽犯罪を取り締まることこそが、重大な犯罪を防ぐために重要であることを指しています。 私たちのチームではこれをWebサービスの新規開発プロジェクトに取り入れています。 WEBサービスにおける割れ窓は「軽度のデザイン崩れ」や「表記ゆれ」に、重大な犯罪は「バグ」や「全体のクオリティ低下
![割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/a00de9ce0520f085a20aefec43b00295df450362/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20161208%2F20161208130750.jpg)
ダイバーシティ・マネジメント - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "ダイバーシティ・マネジメント" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2023年4月） ダイバーシティ・マネジメント（Diversity Management）とは、個人や集団間に存在するさまざまな違い、すなわち「多様性」を競争優位の源泉として生かすために文化や制度、プログラムプラクティスなどの組織全体を変革しようとするマネジメントアプローチのことである。 特徴[編集] 多様性が企業の売り上げや発展に貢献し、競争力の源泉となるという考えに基づいている。具体的には多様性に基づくマネジメントで優位性があるとされる分野に、資源の獲得、マ
仕事ができる人が辞めてしまう9つの原因
トラヴィス・ブラッドベリー博士。シンクタンク、コンサルティング機関〈タレントスマート〉主宰・共同創立者。
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
｢人望がない人｣は､大体"話しすぎ"ている
いくら能力があっても、ひとりの人間には限界があります。よほどのカリスマ性がないかぎり（僕にはない）、人は無条件にはついてきません。僕がやっている監督という仕事は、人の力をどれだけ引き出すかにかかっています。では、どうやってその能力を引き出すのか？ そのコツのひとつは、「ウケる」です。 むやみに怒鳴りまくっていた、過去の僕 僕は「サラリーマンNEO」という番組の監督を務め、おかげさまでそこそこ人気番組になったのですが、その番組を始めた32歳の僕は、強烈なプレッシャーに駆られていました。 同期は局の顔的な番組であるNHKスペシャルなどを担当しているし、片や「サラリーマンNEO」は「これがNHKの番組？」と非難されること必至の番組です。だから、とにかく自分がリーダーシップをもって、現場を引っ張りまくることが必要だと、会議では自分の意見を押し通し、現場ではカメラマンを怒鳴りまくっていました。 殺伐
起業家が開発者のマネージメントで犯しやすい11の失敗 | readwrite.jp
ソフトウェア開発者達を育てるには、あなたのリーダーシップのスタイルを変える必要があるかもしれない。彼らは、一般的なマネジメントでは必ずしも輝かないのだ。何が一番重要か？前もってはっきりとした予測を立てる事、そして問題になる前に作業習慣の違いを考慮しておく事だ。 我々はYoung Entrepreneur Council （YECの11人の起業家達に、彼らが開発者を管理する上で経験したリーダーとしての大失敗と、同じ間違いを避けるためのコツを共有してもらった。彼らの回答は以下の通りだ。 彼らが意見を述べてくれると思い込む事ソフトウェア開発者達が自分の課題やアイディア、あるいは手柄についてさえも話してくれると思い込まない方が良い。多くの開発者達はチーム・ミーティングでこういった情報を進んでシェアしようとしない。開かれた、真摯なフィードバックは常にあなたから要求しなければならない。 自分の努力に対
【レポート】悪い上司にならないためには - やってはいけない3つの習慣 - ライブドアニュース
2013年10月8日 11時0分 by ライブドアニュース編集部 ざっくり言うと 上司が部下に行ってはいけない3つの習慣が存在するのだという １．部下の自信を蝕む 2. 部下を褒めない 3. 重要な情報を部下と共有しない 3つの習慣を部下に行うと、部下の態度は悪くなり、生産性はダウンするという 上司やチームリーダーがメンバーに及ぼす影響は大きい。「励まされている」「支えられている」と感じると、従業員のパフォーマンスが改善されるという米アイオワ大学の調査からみてもわかるように、上に立つ人間の責任は大きい。良い影響を与えたいのは当然のことだが、一方で、悪い影響を及ぼすことだけは絶対に避けたいーーOpenForumの記事「悪い上司がやっている3つの危機的なミス(原題:The 3 Deadly Sins Of Bad Bosses)」では、上司が絶対に回避すべき3つの習慣を指摘している。 組織やチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...