タグ

マネジメントに関するatm_09_tdのブックマーク (179)

  • 組織とは何か?~集団と組織の違い | DevelopersIO

    CDOとしてクラスメソッドにジョインした私の役割は、「デザイン組織を作ること」です。 しかしそもそも「組織を作る」とはどういうことなのでしょうか? さらにいえば「組織」とは何なのでしょうか? 例えば4人が集まっていればそれは「集団」であるといえますが、何があれば「集団」ではなく「組織」になるのでしょうか。 この「組織の定義」を紐解くことがデザイン組織作りの大きなヒントになるのではないかと思い、改めて考えを整理してみました。 組織の定義 「組織」という言葉はあまりにも当たり前に存在しすぎてて、組織がテーマのビジネス書であっても明確な定義がなされていないことも多いです。 P.F.ドラッカーの名著『マネジメント(エッセンシャル版)』では、「マネジメントなしに組織はない」と冒頭に語られます。しかし組織が何であるかの定義は特になく、そのまま話は進んでいきます。 世界中の経営者やマネージャーに影響を与

    組織とは何か?~集団と組織の違い | DevelopersIO
  • アプリケーション・エンジニア職位ガイドライン

    2021/9/23プロジェクトリードにおける考察について取り入れた2021/10/11職種の人数が多い、アプリケーションエンジニアを対象として、まずは内容を詳細化してアップデート2021/12/10プロフェッショナルの年収を520~550万を520~570万に変更チーフプロフェッショナルの年収を550~600万を570~620万に変更マルチリードエンジニア、チーフテックリード、リード・アーキテクト、チーフマイスターエンジニア年収上限を950万から1000万に変更アーキテクト、リードアーキテクトの職位ガイドラインの詳細(暫定)を追加2022/4/11リードエンジニア年収レンジを650-700万についてを、650-720万に変更チーフリードエンジニア年収レンジを超える700-800万から、720-800万に変更2023/3/13 プロフェッショナルのチームコラボレーション(主体性)に追加

    アプリケーション・エンジニア職位ガイドライン
  • 「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」

    「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。2回目は、誰も嫌な思いをしない変化のために実践したことについて。前回はこちらから。 誰も嫌な思いをしない変化のために「相手に期待しない」 椎葉光行氏:その頃の自分と、今の自分でいろいろと変わったとは思うんですけど、大きくこの2つかなと思います。 「相手に期待をしなくなった」それから「相手の気持ちを考えなくなった」です。 言葉にすると、人としてどうなのという感じがしますけど(笑)、でもこの2つが自分の中でけっこう大きな軸になっています。 何年か前に、娘が「2桁のかけ算教えて」っ

    「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」
  • 現場のセンサーデータ取得から、製造マネジメントデジタル化までの、意外な道のり | タイム・コンサルタントの日誌から

    製造実行システム(MES)に関するオンライン・シンポジウムが、10月7日(木)午前9:00-12:30に、(財)エンジニアリング協会「次世代スマート工場のエンジニアリング研究会」の主催で開催されます。内外の有力ベンダー5社による最新の製品と事例紹介等に加えて、わたしも最初に基調講演「実務者の目線から見たMESの重要性」をお話しします。

    現場のセンサーデータ取得から、製造マネジメントデジタル化までの、意外な道のり | タイム・コンサルタントの日誌から
  • なぜエンジニアはマネージャーになるのに不安を覚えるのか - asken テックブログ

    こんにちは。askenでエンジニアリング戦略や組織づくりを担当しているやすにしです。 マネジメントを中心にしておりまして、せっかくなのでブログでもマネジメントについて書いてみますね。 私はこれまでVPoEとしてエンジニア組織のマネジメントや、様々な会社でマネージャー向けにコーチング 1 をやってきました。そこで接してきたエンジニアリングマネージャーに共通しているのは「キャリアに悩んでいる」ということです。 例えばこのようなことです。 コーディングをしなくなり、技術的に取り残されて、エンジニアとしてやっていけなくなる感じがする 自分でやらないから成果が見えない。やっている感じがしない。 マネジメントをどうやればいいか、どう学べばいいかわからない。 マネージャーのキャリアで自分は定年(?)まで生きていけるのか? 共通点は、色々理由を言葉にしているものの、どれもしっくりきている感じではなく、「な

    なぜエンジニアはマネージャーになるのに不安を覚えるのか - asken テックブログ
  • エンジニアリングマネージャーとしてどんなことをしているのか? - tuneの日記

    はじめに エンジニアリングマネージャーとは? メンバーのサポート・育成・評価 メンバーの状態観察 目標設定・人事評価 後進の育成 日常の労務管理 開発 プロダクトマネジメント エンジニアリングのリーダーシップ 採用・採用広報・アドバイザーの招聘 採用 採用広報 アドバイザーの招聘 他社との情報交換 終わりに はじめに 今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。 私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が

    エンジニアリングマネージャーとしてどんなことをしているのか? - tuneの日記
  • 体制を考えるときに意識していること - id:onk のはてなブログ

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

    体制を考えるときに意識していること - id:onk のはてなブログ
  • リモートワークに必要なスキルの言語化を試みる - $shibayu36->blog;

    最近リモートワークでしばらく暮らしたところ、オフィスの時より人によって成果の差が出やすいと感じている。また昔からリモートワークしてきた人の様子を見ていると、仕事の進め方がうまいと感じることが多い。このことから、リモートワークに重要なスキルが何かあるはずだと感じていたのだが、自分の中でちゃんと言語化できていなかった。 そこで以下の資料を読み、少し言語化してみたのでメモ。 リモートワーク大全 作者:壽かおりポプラ社Amazon Effective Remote Working - Speaker Deck いくつか読んで、自分の中で以下のキーワードが重要なのかなと考えている。 セルフマネジメント モチベーション・集中力コントロール メンタルケア タスクマネジメント コミュニケーション こまめなアウトプットによる状況の可視化、それによる信頼の醸成 曖昧でない言葉で全てを伝えるコミュニケーション

    リモートワークに必要なスキルの言語化を試みる - $shibayu36->blog;
  • 全てをスケジューリングする必要はない | タイム・コンサルタントの日誌から

    前回の記事で、日企業はしばしば、過剰に計画したがる傾向がある、と書いた。その主な理由は、先にお金の出入り(予算)を押さえておきたいためと、リスクに対する不安があるためだ。研究開発や業務改革などは、スコープ自体が柔らかくて、行うべきアクションの内容や仕事量が精度よく見積もれないのに、過剰な細部まで先に決めたがるのである。 似たような事情は、プロジェクト・スケジュールや、生産スケジュールにおいても起こり得る。そもそもスケジューリングとは計画作業の一部だから、まぁ当然と言えば当然である。 この傾向は、日よりも計画重視の傾向が強い米国発で、日に持ち込まれたのかもしれない。もともとPERT/CPMなどのプロジェクト・スケジューリングの手法は、1950年代に、アメリカで開発されたものだ。 実は同じ頃、生産スケジューリングの理論においても、アメリカで重要な発見がなされた。それは、ジョンソン法と、ジ

    全てをスケジューリングする必要はない | タイム・コンサルタントの日誌から
  • オープンでフラットな組織が突然「閉鎖的」と言われるとき|柴田史郎

    柴田(@4bata)です。「それぐらいわかるだろ・・・」が通じなくなるタイミングがあるんだなという発見です! 考えたきっかけ:「オープンでフラットだと思ってたけど、結構閉鎖的なところもある」というセリフを聞いたその人に情報が伝わってなかったのかな。私の最初の感想は「前からそうだった気がするけどな・・・」。以前から整った形で情報はちゃんと流れてない。私にとっては、今働いている会社が閉鎖的には見えてない。実際には閉鎖的な部分があるのだろう。その差を理解してみたくなった。 情報の伝わり方を単純化して考える近くにいる人には自分の活動内容や背景にある意図が勝手に届くとする。携帯の電波が届く範囲、みたいなイメージ。 接触頻度が高い人同士は、いろいろ理解できている。 人数が少ないときは、何もしなくても相互に活動内容や意図が伝わっている・自分が理解できない情報も、一緒に仕事してる隣の人に聞けば情報の背景が

    オープンでフラットな組織が突然「閉鎖的」と言われるとき|柴田史郎
  • エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita

    Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。 マネジメントを始めて悩んだこと 約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー(以下、EM)としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。 そんな中で常に「自分がマネージャーとしてきちんとできているのかが分からない」という不安を持っていました。また、どんなスキルをつけて、どうなれたら正解なのかというイメージが見つからず悩んでいました。 ある時、先輩との1on1で、「(メンバーとの1on1やメンバーの育成を)どうしてそれをやるのか」と問われ

    エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita
  • 「チームの生産性向上」のためにリーダーができること9つ | ライフハッカー・ジャパン

    1.チームメンバーに当事者意識を持たせるチームメンバーに当事者意識を持たせることで、チームメンバーが行う決定と行動に関して説明責任を持たせることができます。 その結果、社員は責任感が強くなり、より注意深く仕事に取り組むようになります。また、仕事に対する取り組み方が変わってきます。 物事を決めるとき、そうしたことがすべて、チーム全体のパフォーマンスにも影響を及ぼします。 Image: MakeUseOf当事者意識を持たせるとは、そのタスクを担当したり、プロジェクトをリードしたりするなど、さまざまなことを意味します。 目標は、リーダーがチームメンバーを信頼しており、そのタスクを仕上げる戦力として期待していることを示すことです。信頼はそこから生まれるのです! 2.コミュニケーションこそ成功の鍵チームメンバーが自分の考えを適切に伝える方法を知らないと、不必要に物事が複雑になったり、メンバー同士の衝

    「チームの生産性向上」のためにリーダーができること9つ | ライフハッカー・ジャパン
  • キャパシティか、スループットか 〜 生産能力を理解する | タイム・コンサルタントの日誌から

    生産マネジメントに関連して、混乱しがちなもう一組の用語について考えよう。それは生産量(生産能力)を表す言葉だ。 『キャパシティ』とは何か。それは、ある機械設備なり、一連の工程なり、あるいは工場全体の生産能力を表す、設計上の値である(そしてたぶん、この言葉の用法については、あまりブレがない)。 たとえば、前回の記事と同じく、パン焼き窯を題材にしてみよう。窯には30個までのパンの材料を置くスペースがあり、焼き上げるまでに必要な時間は2時間だ。ということは、平均すると、(パンを窯に出し入れする時間を無視すれば)1時間あたり15個、ないし1分あたり0.25個、という「キャパシティを持っている」といえる。

    キャパシティか、スループットか 〜 生産能力を理解する | タイム・コンサルタントの日誌から
  • リードタイム、サイクルタイム、タクトタイム 〜 何がどう違うのか | タイム・コンサルタントの日誌から

    なぜ、あえて『言葉を大切にする』を最初にあげたのか。理由は簡単。「言霊のさきわう国」のはずだった、わたし達の社会で、多くの人が言葉をぞんざいにしているからだ。いや、ぞんざいという意識はないのだろう。だが、自分の使っている言葉が正確に何を指しているのか、そして、その言葉が自分の所属するムラを離れて通用するのか、意外と無頓着に思えたからだ。 たとえば、「リードタイム」という言葉がある。リードタイム短縮、などという課題もよく耳にする。だが、そこでいうリードタイムとは、具体的に何を意味しているのか? そこを置き去りにしたまま、自分たちの文脈で勝手に理解して、議論が始まってしまう。そこで時々、リードタイムという言葉で何を指そうとしているか、問いたださなければならない。

    リードタイム、サイクルタイム、タクトタイム 〜 何がどう違うのか | タイム・コンサルタントの日誌から
  • (くどいけれど)マネジメントにはテクノロジーが存在する | タイム・コンサルタントの日誌から

    このサイトの目的は、『マネジメント・テクノロジー』について考え、それを読者と共有・議論することにある。マネジメント・テクノロジーとは聞き慣れない言葉かもしれないが、ま、要するにマネジメントのテクノロジーである。 ・・えーと、これじゃ何も説明したことにならないか。日語で『管理技術』と言ってもいいし、スペース節約と通じやすさのために、そう書くこともある。だが、ほんとは少しニュアンスが変わってしまう。とくに「管理」という日語は、英語のManangementと守備範囲も異なるし、人びとの受け取る感情も違う。なので、決してカタカナ好きではないのだが、マネジメントという表記を選ぶ テクノロジーの方は、単純に日語の技術でいいじゃないか。もちろん、そう思いたい。だが、日語の『技術』がまた、曖昧に使われすぎているのだ。たとえばあなたは、技術と技能を線引きして、使い分けているだろうか? 「あの人のPy

    (くどいけれど)マネジメントにはテクノロジーが存在する | タイム・コンサルタントの日誌から
  • 属人化を排除した結果、「あなたはいてもいなくても同じ」と部下に言われた。 - Everything you've ever Dreamed

    僕は品会社の営業部長、自分で言うのもなんだが部下に慕われている部長と自負している。その証拠に、先日、休みを取ろうとしたら、部下の一人が気を使ったのだろうね、「いてもいなくても同じですから休んでください」と言われた。一瞬、思うところはあったけれども、ポジティブシンキングで目指していた自由に発言できる風通しのいい組織の証明ととらえた。実際、営業部を今の体制に変えたのは僕なのである。 4年前、僕は中途入社した。それまでの経験から案件の発掘から成約まで一人でやりきってしまう営業マンを揃える営業組織に限界と疑問を感じていて、意見を同じくする社長のもとで、これまで組織を変えてきたのだ。ホークアイで見込み客を見つけ、マジカルトークで有力案件に育て、ミラクルな企画提案で契約を取るスーパーな営業マンを僕は否定しない。でもスーパーマンに依存した仕事のありようは組織としては正しくない。スーパーマンが退職したと

    属人化を排除した結果、「あなたはいてもいなくても同じ」と部下に言われた。 - Everything you've ever Dreamed
  • プロジェクトのリスクはコストの増減で管理する - プログラマの思索

  • 管理のシステム化は可能か? | タイム・コンサルタントの日誌から

    「管理不行届」という言葉がある。時折、新聞などをにぎわす言葉だ。通常は人間を対象にした問題が生じた際に使われる(危険物などの保管で使われる場合も、ないではないが、かなりの問題を起こした場合に限られよう)。多くの場合、組織の構成員が、社会問題になるような不適切な行いをした際に、上長とか代表者などの「管理責任」を問うために使われる。管理のかわりに「監督不行届」という場合もある。 「不行届」という漢字を、「ふゆきとどき」と音訓まぜた読み方にして、しかも送り仮名をつけないスタイルから見て、かなり古い時代から使われている言葉らしい。実際のところ、江戸時代などでも、家中で不祥事があると、大名や重役が幕府から管理責任を問われ、蟄居閉門だのお家断絶などを命じられたようだ(ただし、管理責任を厳しく問いすぎると、問題発生を隠して偽装する、という別の問題行動が生じるのは、江戸時代も今も変わらない)。 ちなみに、

    管理のシステム化は可能か? | タイム・コンサルタントの日誌から
  • 『失敗の責任は私にあります』と言えない責任者たちの話。

    昔、あるメーカーで経営企画職を担当していた時のことだ。 営業部の部長から、 「ウチの商品が絶対に安心で安全という証明書って発行できませんかね・・・」 と相談を受けたことがある。 聞けば、大口顧客との取引が受注寸前で、最後にそのような証明書を出せれば契約してもいいと言われているようだ。 しかし仕様書や保証書ならともかく、絶対に安心安全な証明書などどうしろというのか。 安心安全に使えるガスボンベだって火の中に放り込んだら爆発するし、腹痛を治してくれる胃薬でも用法・用量を守らなければ命に関わる。 どういうものを書いてよいのかわからず、先方ともう少し要件を詰めて欲しいと押し返すと、 「絶対安心安全の証明が要件なんですよ・・・」 と埒が明かない。 やむを得ず、一度部長に同行し先方の会社を訪れ、どのような証明を求めているのかをヒアリングすることにした。 応対に出てくれたのは、若い現場主任だ。 熱気と熱

    『失敗の責任は私にあります』と言えない責任者たちの話。
  • 道の真ん中をきれいにするプロジェクトマネジメント~イケてるチームになるための10原則~ - Qiita

    はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが

    道の真ん中をきれいにするプロジェクトマネジメント~イケてるチームになるための10原則~ - Qiita