マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
効果的な 1 on 1 ミーティングのためにマネージャができること
2016 年に逝去した、元 Intel CEO の Andy Grove による High Output Management の日本語訳が復刊され、さらに Hard Things の Ben Horowitz の序文がついたことで、改めてスタートアップ界隈でも 1 on 1 (ワンオンワン) ミーティングの効果が注目され、各社や各人の 1 on 1 のノウハウが共有されるのではないかと期待しています。 Y Combinator の Sam Altman はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな
これからマネージャーになるエンジニアのあなたへ - yashiganiの英傑になるまで死ねない日記
こんにちは、新米ディレクターのid:yashigani_wです。 この記事ははてなディレクターアドベントカレンダー2日目の記事です。昨日はid:moretのそろそろ5年生なので右も左もわからない新卒のころの自分にアドバイスする - el cineでした。 私は8月にアプリケーションエンジニアからディレクターになりました。 はてなではディレクター職には担当するサービスの成長に責任を持つプロダクトオーナーとしての役割と、担当するチームの成果を最大化するマネージャーとしての役割が求められます。 マネージャーというと、多くのエンジニアはあまりなりたがらないとおもいますが、それはマネージャーに求められる責任を具体的にイメージできないことや未知の仕事に対する不安からではないでしょうか？ この記事は私の経験から、これからマネージャーになるエンジニアに向けてマネージャーがまず意識すべきことと、最初に陥るで
1on1ミーティングに備えるアンケート - しるろぐ
最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか
見えない壁に突きあたった中堅エンジニアが学ぶべき、三つのこと | タイム・コンサルタントの日誌から
先週の4月2日(土)に浜松市で、合同シンポジウム「サプライチェーン戦略とプロジェクト・マネジメント」を開催した。主催はOR学会・日本経営工学会・スケジューリング学会で、その配下にある「サプライチェーン戦略研究部会」（主査・日本IBM 米澤隆氏）と、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」が実行主体だ。 講演者には、倉庫管理システムiWMSの開発元として有名な(株)フレームワークスの渡辺重光会長と、ヤマハの曽根卓朗主席技師のお二人をお招きした。お二人の話はどちらも非常に興味深いもので、渡辺氏はロジスティクスとIoTの広範な展望を話され、曽根氏は通信カラオケの製品開発を題材に、生々しい体験をお話しいただいた。最後にパネル・ディスカッションを行い、わたしもパネラーとして参加した次第だ。 幸い大勢の方に来ていただき、立ち見が出そうになったので椅子を補充したほどだった。製
【厳選】リクルートやLINE人事役員に聞いた本当に役立つ組織論・ビジネスおすすめ良書12選
これまでのキャリアで、DeNAやリクルート、LINEの経営者と繋がりがあり、飲みに行かせてもらう度にビジネス本を頂戴しています。勉強になるものばかりなので、その中から特にオススメな本をご紹介します。 スポンサーリンク 組織論系 学習する組織 なぜ人と組織は変われないのか MBA組織と人材マネジメント 思考向上系 確率思考の戦略論 なぜハーバード・ビジネス・スクールでは営業を教えないのか？ 未来に先回りする思考法 アナロジー思考 エッセンシャル思考 共通しておすすめされた本 究極の鍛錬 イシューからはじめよ HARD THINGS 大人げない大人になれ！ 組織論系 マネジメント層は必読の本。リクルートや上場ベンチャーで僕が人事をやっていたときに役員の方におすすめされた組織に関する本です。人事制度設計などで使えました。研修などでも使った本なので、部課長、マネージャー、リーダーなどにもお薦めです
エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと - Hatena Developer Blog
こんにちは、 id:stanaka です。 先日、社内ミーティングでディレクターから「エンジニアの専門性を伸ばすためにディレクターとしてなにができるか」という質問を受けて回答した社内向けエントリを公開します。 (ちなみに、はてなでのディレクターは、エンジニア、デザイナーなどの数名のメンバーからなるチームの率いる、現場にもっとも近いマネージャー、というポジションです。) エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと 1. 引き出しの数を増やすことができるようなタスクを振る エンジニアにとって自分が持つ引き出しの数と専門スキルは強い相関関係があります。サービス開発において遭遇するさまざまな局面において、いくつかの選択肢を提示でき、さらにその中から最適なものを選びとれることは、エンジニアの専門性が高いことの証です。 そのためには、いろいろな経験をさせてあげることが大事
非エンジニアのプロダクトマネージャーが抱える悩みと強み - Noize
日本最大のProduct Manager Community blog.kentarok.org こんなコミュニティがあったんですね。ビズリーチPM id:tannomizuki さんのブログを通じて知りました（id:antipop さん、改めて設立ありがとうございますm( )m）。 早速参加して過去ログをすべて読み漁りました。現時点で300名超が参加しており、対話や議論が生まれるコミュニティとしてはおそらく日本最大規模といって良いんじゃないでしょうか。 このコミュニティの議論の流れをサマると以下の様な感じ。 日本において製品開発におけるプロダクトマネージャーは主に自動車産業でその役割を発展してきた経緯がある が、知見が閉じておりなかなか他の産業まで浸透していなかった。 日本のIT産業の拡大と、OSS的な指向からその開発手法が会社に閉じることなく広がり始めてきた。 その中でここ数年、急激に
技術理解の浅い会社にプログラマーとして入社すると辛いよという話 - プログラミングとデザイン、スタートアップの話
プログラマーとして就職するならその会社の体質として技術理解度がどれほどかという点はしっかり見た方がいいです。 営業畑出身の人ばかりが経営陣にいる会社やシステム構築の外注率が高い会社は、総じて技術理解度・技術者に対する理解が低い傾向にある気がします。 工数の感覚が合わない テストの重要性が理解できない 新しい技術への関心の違い 企業の口コミサイトを見たほうが良い 工数の感覚が合わない プログラミングについての理解が浅い人がプロダクトマネージャーだったりすると、ほとんど実現不可能な工数での開発を求めてくる輩がいます。 ５ヶ月位は見積もらないといけない案件だったとしても、３ヶ月でやってくれとか言われてげんなりします。 なんとかその工数について摺り合わせを行って機能削減などで工数の折衷案を取り付けたとしても安心できないです。 開発中の突然の仕様変更、新規機能追加などが舞い込んできます。 別にそれ自
リードエンジニアを３ヶ月やって得た開発マネジメントに関する教訓 - seri::diary
ここ３ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実
エンジニアリングのマネージメント | GREE Engineers' Blog
こんにちは、岡崎です。最近はグリーのインフラチームにおける開発のマネージメントを担当しています。 このエントリーは「GREE Advent Calendar 2014」2日目の記事です。昨日は岸田さんによる「イノベーションが失われた組織から脱却する10のルール」でした。 さて、気がつけばここに書くのも昨年のAdvent Calendar 2013「開発ワークフローを、いつどう変えるか」以来です。去年は開発プロセスについてやってきた事の振り返り記事でしたが、今年も同じようにこれまでのプロジェクトを振り返りながら今回はエンジニアリングのマネージメントについて考えてみます。 エンジニアリングマネージャーとはどのような責任を持っているか エンジニアリングマネージャーとはどのような責任を持った役割でしょうか。本題に入る前にまずは「責任」という言葉の定義について確認しておきます。 「責任」と一言で言う
プロジェクトマネジメントなう＼(^O^)／ | ぽんぽんぺいんなう＼(^O^)／
２０代後半から１５年ほどSIプロジェクトのリーダー／マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル（MLB監督） ●ポリシー １）全てのメンバーが目的・段取りのわからない仕事をしない／させない。 ２）プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 ３）プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 ４）プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 ５）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ６）みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 ７）人は一人一人別人であり仕事に対するスタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
