良い上司の条件・悪い上司の条件 | knowledge / baigie
「一緒に働くならどんな上司がいいですか？」と聞かれれば、具体的な要望の一つや二つはすぐ出てくるでしょう。しかし、「あなたはどんな上司になるつもりですか？」と聞かれたら、漠然としたイメージでしか答えられない人の方が多いのではないでしょうか。 これは、部下の立場から「上司にこうあってほしい」と願うことより、上司の立場として「自分はこうなろう」とイメージすることの方が遥かに難しいことを物語っています。 少ない例外を除けば、社会に出た人のほとんどがまずは誰かの部下になります。その会社に居続けて、やがて力が認められれば、誰かの上司になります。 上司も部下も、ほとんどの人が通る道です。だから、上司と部下にちなんだ書籍やブログ記事は数多く存在します。なぜなら誰もが自分事化しやすいテーマだからです。しかも未だに作られ続けています。なぜなら上司と部下の話には正解がないからです。正解がないから、話題が尽きませ
コンサルタントやってた時、重要な対人技術として『「ちがう」と言うな』と習った。
コンサルタントのころ。対人技術を教わった。 様々なものがあったが、その中でも群を抜いて重要な技術の一つは 「会話の時、人の話を否定しない」こと。 具体的には、人に『ちがう』と言ってはいけなかった。 ＊ 若干うろ覚えだが、客先で、こんなことがあった。 プロジェクトで、部門別の目標を立てて、発表してもらった時のことだ。 私：「では、営業部2課の目標の発表をお願いします。」 営業2課：「既存顧客を中心に、前年比10％の売上アップです。」 私はここで、おかしいな、と思った。 先日の経営会議で 「営業2課は、新規開拓を中心にした目標にしてほしい」 との指示があったからだ。 それがなぜか既存顧客中心にすり替わっている。 訂正させなければならない。 が、「その目標、間違ってませんでしょうか？」と否定するのはご法度だ。 私は思案した。 どうすれば担当者を否定せずに済むのだろう。 そこで確認した。 私：「確
クレディセゾンでDXを進めてきた5年間を振り返る｜小野 和俊
はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
メンバー1人1人のスキルアップを促す「等級（グレード）」と「給与テーブル」｜風音屋（かざねや）
風音屋（@Kazaneya_PR）では、メンバー1人1人のスキル水準をモニタリングし、さらなる成長を促すための仕組みとして「等級（グレード）」を設定しています。プロフェッショナル人材が少しでも正当な評価とフィードバックを受けられるように試行錯誤を経てきました。 採用選考を進める中で「自分の場合はどのくらいのグレードになるのか？」というご質問をいただく機会が多々あります。この記事では、どういった考え方でグレードを設計・運用しているのかを、給与テーブルとセットで解説します。 注意事項クライアントワークを担当するAnalytics部門を想定した内容となっています。Backoffice部門の給与テーブルは試行錯誤中ですが、ベースとなる考え方は同じような形に落ち着くはずです。 人事周りのルールは今後変わっていく可能性があります。最新状況についてはカジュアル面談でお問い合わせください。 すべての人にと
「東京駅集合で」と言われたので「東京駅のどこですか？」と聞いたら「1から10まで言わないとわからんのか！」とキレる人がいたらヤバいですよね。
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 「東京駅集合で」と言われたので「東京駅のどこですか？」と聞いたら「1から10まで言わないとわからんのか！」とキレる人がいたらヤバいですよね。そんなのたどり着けるわけないだろうと。 一方で「東京駅銀の鈴集合で」と言われて「銀の鈴までの道順詳しく教えて」と言われたら「1から10まで言わないとわからんのか！」となるのも当たり前と言える。それくらい自分で調べて何とかしろとなる。 これ仕事でも同じで、仕事のゴールと手順の違いなんですよね。ゴールを明確にせずに「1から10まで言わないとわからんのか！」という人は本当にヤバい。害悪なので本当にやめてほしい。 一方で銀の鈴までのたどり着き方を詳細に指示してもらわないと動けない人はもう少し自分の仕事のやり方を真剣に考えた方がいい。 2024-03-03 08:19:37 米村歩@日本一残業の
私が仕事をしてきた中で「最も合理的」と感じたリーダーの話。 | Books&Apps
もうずいぶん前のことになる。 あるIT業の業務改善プロジェクトに、私はいちメンバーとして参加した。 その会社のプロジェクトメンバーは全部で8名。期間は約9ヶ月だった。 経営陣肝いりの、それなりに大きいプロジェクトである。 そのため、プロジェクトマネジャーは、掛け値なしに優秀であった。 指示は的確で、果敢に新しいことにチャレンジするが、無用なリスクは取らず、守りが堅い。 メンバーとの関係も付かず離れずとバランスが良く、理想的な人物だった。 だが経験的に、プロジェクトメンバー全員が優秀であることはほぼない。 政治的な理由からか、教育効果を期待してなのか、リストラ予備軍だからなのか、それとも単なる人手不足なのか。 理由は様々だろうが、プロジェクトメンバーの中に、必ず２，３名はボンクラが含まれているのである。 そして、プロジェクトは一定の期間内に成果を出す、という厳しい制約があるため、無能の扱いを
仕事ができる人ほど、できない人に優しく振る舞うのは、マネジメントの定石。
昔、ある会社の営業MTGで、忘れられないやりとりがあった。 少々詳しく描写すると、出席者は以下の通り。 ・役員（部長） ・リーダー ・メンバー 7名のメンバーの能力は各々、高、高、中、中、中、中、低。 二人ぐらい優秀な人物がいて、一人「できない人」が混ざっているイメージだ。 また、役員とリーダーは切れ者で、部下の報告の論理矛盾やダメな点にはすぐに気づく。 さて、こんな状況で来期の「営業計画」について、MTGが開催された。このMTGの議長はリーダーだ。 リーダーはテキパキと議事を進める。 来期の営業部の方針に始まり、具体的な目標設定、個人の役割など、メンバーへの指示も簡潔でわかりやすい。 ここまではなんの問題もなかった。 だが、今年一年を振り返っての営業報告が始まると、雰囲気が変わった。 無理もない。メンバーの一人ひとりが、自分の過去の実績と、これからの具体的行動を発表しているのだから、緊張
チームで仕事をするなら、リアクションし続けよ｜森 一貴（Mori Kazuki）
チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に
タスク処理のコツは「考える」を事前に済ませておくこと。
この記事で書きたいことは下記のようなことです。 ・私が知っている中で一番「整理整頓」「片付け」が上手い人は、昔居候していたバーのマスターです ・マスターに「片付けのコツ」を聞いてみたところ、「頭と手を同時に動かそうとするな」と言われて、以下のようなことを教わりました ・片付けというのは要は「カテゴライズ」であって、単純化すると物品を分類するだけの行為 ・人間は複数のことを同時にやるのが苦手であって、「考えながら手を動かす」のは高いコストを要求される ・だから、「考えておけることは事前に考えておく」だけで片付けのハードルが下がる ・お前は片付けの時、手を動かしながら分類まで考えようとしているので全然片付けが出来ない、先に考えるべきことを考えろ ・その教えを後から思い出して、だいぶ(片付けに限らず)タスク処理が上手くなりましたので、片付けが苦手なひとはご参考まで 以上です。よろしくお願いします
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
「どうにも成長しないし、意欲も低い部下」をどうすべきか？
ある方から、「悩める新米の管理職にアドバイスを」と言われたので、記事を書くことにしました。 はじめて管理職になって一番の悩みは まず、「管理職になって一番の悩み」となり得るのは何でしょうか。 いろいろとあります。 ただ、実のところ最も頭を悩ませるのは、上司との関係でもなく、目標のキツさでもなく、会議の多さでもありません。 「向上心がなく、能力が低く、素直でない」部下です。 「教育の費用対効果が合わない人」と言い換えてもいいでしょう。 管理職の仕事の中には、部下を教育し1人前に育てる、というミッションが含まれていることが多いですが、やってみると「この人の成長にかけるコストと、この人が生み出すリターンが見合わない」ケースが少なからずあります。 そしてだいたい、そういう人は社内で「問題児」扱いされているのです。 たとえば知人にシステム開発業のマネジャーがいますが、 「（メンバーの）あの人、そもそ
「なんで私をもっと評価してくれないの！？」という人向けに、私がやってる評価ハッキング手法を伝授します - 斗比主閲子の姑日記
皆さん、自分が他人から評価されていないことに苦しんでいますか？ 私はまったく苦しんでおらず、それどころかありとあらゆる場面で高く評価されすぎて困ってしまっているわけですが、そんな私がどうして評価されるか、評価ハッキングと題して言語化してみたのが今回の記事です。 評価に悩む人の参考になれば幸いです。 なんていう、出来の悪いYoutube動画の煽りタイトルと、冒頭の鼻持ちならない文章で、多くの人を脱落させられたと思うので、ここからは上の文章を読んだ上で続きを読む気になった限定的な人向けに、真面目に書いていきます。 評価のされ方を知ろう！ 他者を評価する方法というのは大きく次の3つに分類されます。あ、人事評価ではなく、普段の日常生活も含めた、全般的な評価の仕方ですからね、誤解なく。 数字による評価 定性的な評価基準に則った評価 主観的な評価 一つ目は、分かりやすいですね。営業成績みたいに、「今月
「便利になる」だけでは人は動かないし、「当事者意識をもってくれる人」はめちゃ貴重だという話
この記事で書きたいことは、大筋下記のようなことです。 ・「これは問題だ」「だから改善したい」と、自分ごととして真剣に考えてくれる人というのは極めて希少です ・ただ「便利になる」というだけでは誰も動かないし、どんなにいいものを作っても使ってもらえません ・当事者意識を「持ってもらう」ということは基本的に出来ません ・当事者意識を持っている人を別に探し出すことで、なんとか状況を打開出来る場合もあります ・だから、「この人は当事者意識を持ってくれている/くれていない」を嗅ぎ分ける能力はとても重要です よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 以前にも書いたことがありますが、私はかつて、システム開発の会社に勤めていました。 社員数は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
作業ではなく、仕事をせよ - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実
正しいことは、正しく言わないと、正しく伝わらない - 下林明正のブログ
SNSを見ていたり人の話を聞いたりしていると、「職場で攻撃的な物言いをしてくる人に困っている」ということがある。 攻撃的な物言いをされる側は気分が落ち込んで生産性が下がったり、最悪退職してしまう。 そして攻撃的な物言いをする側は、いくら指摘しても態度を改めない、というもの。 割と長期間に渡ってそういう話を見聞きしてきて自分なりに思うことがあったので、書いておく。 攻撃的な物言いをするメリットはほぼ無いはず 言われる側の心構え 攻撃的な物言いをするメリットはほぼ無いはず 何かを指摘する際の目的は何なのかと考えてみると、指摘をすること自体は目的ではなくて、大体は相手に素早く正しく動いてもらうことが目的だと思う。 その観点で最適な指摘の仕方を考えてみたときに、本当に攻撃的な物言いが最適だと思えるならそうしたらいい。 けど、多くの場合は相手の反発感情を煽って咀嚼に余計なエネルギーを要したり、最悪怒
技術者には試行錯誤は圧倒的に悪であると腹落ちした話｜牛尾 剛
私はシアトルのクラウドの中の人として、ソフトウェアの開発を行っているが、先日ある問題がきっかけで、技術者には試行錯誤がとても良くないということが腹落ちしたので、忘れないように書いておきたい。 先日起こった事先日起こった事は、私がシアトルから一時帰国して、普段使わないラップトップを使って日本から仕事をしている。 Application Insights というログを管理するプラットフォームがあるのだが、とても不思議なことに、Application Insights のログファイルを見ると完全に正常に動いているようにしか見えないのだが、クラウドのポータルに行くと、テレメトリが来ていない。 Application Insights のチームのメンバーが助けてくれることになったので、彼女に、Teamsで画面共有をして、「ほら、出ないでしょ？」と見せると、なんとテレメトリがポータルに来ている。その後
「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット
「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
管理職必読 順番に読むと理解が深まる「マネジメントの名著」11冊