経営の”踊り場”問題 - Yamotty Blog
2016 - 12 - 28 経営の”踊り場”問題 プロダクト-プロダクトマネージャー 本記事は「経営の踊り場問題」と勝手に呼んでいる問題とその対策について、わざわざクリスマスの夜に行った4つのツイートをまとめ・補記したもの。主にスタートアップや新規事業など「急速な成長」を前提とした組織体を想定している。 停滞期に起きること 踊り場を抜けるにはユーザーやプロダクトと向き合い切る以外に解はないと思ってるんだけど、「これまで順調に伸びて来た売り上げがストップ」みたいな状況は社内の雰囲気を悪くする。 結果、マネジメントが組織や人間関係の問題にフォーカスしがちに。これを「経営の踊り場問題」と呼んでる。→続 — Yamotty (@yamotty3) December 25, 2016 踊り場が目線を内に向ける リリースした直後は底にいるので、サービスは伸びるしかない。難しいのは伸ばし続けること。ふ
エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017
Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017
結果的にスクラムになってる！なのがいいと思う！ #RSGT2017
Regional Scrum Gathering Tokyo 2017
効果的な 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 はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな
マネジメント語りについて - Kentaro Kuribayashi's blog
以下のnaoya氏のツイートを見て思ったところを書いてみる。書かれている文字通りのことには完全に同意で、自分自身の行いも反省する余地があろうかと思われた。一方で、多分この発言を読んだひとが誤解するだろうなということもあるので、そのことについて。 マネジメントって業績伸ばすためにやるんですよね？ 業績伸びてないのに俺たちはマネジメントうまくやってますって語るの意味あるんですかね— Naoya Ito (@naoya_ito) December 22, 2016 結論 結論から先に書くと、マネジメントについて語ることは、業績云々に関わらずおおいにやるべきだと思う。それは、たとえばソフトウェアエンジニアリングについての文書などと同様に、世の中にとって大きく役立ち得る。 ただし、それは一般化・抽象化された(つまり、組織が違っても役立ち得る)マネジメントの理論やテクニックに限る。自分たちがそれをうま
マネージャーに期待すること | ペパボ社長ブログ
この記事は、Pepabo Managers Advent Calendar 2016の23日目の記事です。 22日目は、経営企画グループマネージャーのいくおさんによる「ラーメンにライスをつけるか否か」でした。 ★ ★ ★ 突然ですが、経営幹部の人材配置は社長の仕事の一つだと考えています。ペパボは12月決算で翌年の3月に株主総会を行っていますので、今まさに次年度の組織体制について考えを巡らす時期だったりします。誰かに何かを任せるというのは、その人や組織に対して期待を寄せるということです。Pepabo Managers Advent Calendar23日目となる本記事では、ペパボの社長として私がマネージメント層に期待することについて書きたいと思います。 結論から言いますと、マネージャーにはメンバーのモチベーションを向上させ、目標を達成することを期待しています。企業や経営者によって考え
エンジニアがはてなでマネージャーをやるということ - An Epicurean
このエントリーははてなディレクターアドベントカレンダー2016の15日目の記事です。また、このエントリは先日の はてなエンジニアセミナー #7 でお話したことを、書き起こしたものでもあります。 Mackerel というサーバー監視・管理SaaSの開発チームのディレクターを務めている id:Songmu です。はてなのチーフエンジニアも兼務しています。 これまでの経歴としては、中国でITベンチャーの立ち上げに関わったり、その後語学学校で営業兼システム担当、SIer、Web企業でソーシャルゲームのリードエンジニアなどの経験を経て、2年ほど前にはてなに入社しました。 現在兼務している、ディレクターとチーフエンジニアという職位は、一般の企業では両方共課長格くらいで、W課長みたいな社内では珍しい立ち位置です。 Mackerelのディレクターとしては、プロダクトマネージャーとスクラムマスター的なことを
嫌われない勇気 - だいくしー(@daiksy)のはてなブログ
※ベストセラーになった書籍『嫌われる勇気』からタイトルをもじっただけで、その書籍とこのエントリの内容に関連はありません このエントリは、はてなディレクターアドベントカレンダー16日目の記事です。 advent.hatenablog.com サブディレクターという仕事 ぼくはMackerel というプロダクトの開発チームに所属しています。これまで、2年弱アプリケーションエンジニアとして仕事をしてきましたが、今年からチームのサブディレクターに就任しました。 サブディレクターということで、厳密にはディレクターではありません。チームのメインディレクションは、ディレクターのid:Songmuに権限があります。 Mackerelチームは、はてなの中でもかなりの大所帯で、エンジニア、デザイナ、セールス、マーケティングと多用な職種の人が在籍しています。ロケーションも東京と京都、愛知(自宅からのリモート勤務
効率的で課題解決的な態度にひそむ罠について - 下林のエンジニアブログ
この記事は「はてなディレクターアドベントカレンダー」の18日目の記事として書かれました。 id:shimobayashiと申します。数年前からはてなという会社でディレクターという肩書で働いています。コードも書いてますけどね。 今回はディレクターアドベントカレンダーということで、マネージャー的な側面から表題の件について書いてみることにしました。 さて、一般的に効率的であることと課題解決的であることは良い態度とされていると思います。 実際にはこの2つが重なると、現在の課題についてのみ話すようになりがちです。なぜなら、効率的であろうとするほど話題を絞りがちですし、課題解決的であるほど課題について考えがちだからです。会議の場なんかでは顕著ですね。 そうなると「ここがうまくいってないよね」という会話しかせずに「ここはうまくいってるね」という会話はしなくなりがちです。そうした会話が続くと段々と自己肯定
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
スケールする会社を支える開発組織のマネジメント
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
ぬるま湯 or 過重負荷のチームを脱却せよ–伊藤直也が「1人CTOナイト」で話したヒント - ログミーTech
2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。本パートでは、伊藤氏がチームが抱える課題をいち早く見つけるためのフレーミングと1on1について話しました。 チームが最もベストな状態は「責任と心理的安全性が高い」 伊藤直也氏（以下、伊藤）：次は、「組織課題の発見とアプローチ」について。 僕が最近すごく気に入っている考え方がありまして、それが「心理的安全性と責任」という話なんですよね。『チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ』に書いていたもので、ここでもやはり「2
はてなインターンの振り返りをYWTを使ってやってみた - だいくしー(@daiksy)のはてなブログ
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
生涯「エンジニア」として食っていくには何が必要？及川卓也氏×田中邦裕氏の答え - エンジニアtype | 転職type
各所でプログラマー不足が叫ばれる昨今。にもかかわらず、企業で働くエンジニアの中には、勤め先の要請によって「開発業務（コーディング業務）」から身を引かねばならない人も少なくない。なぜ、このような矛盾が生まれるのか。エンジニアが「好きな開発」と「キャリア形成」をうまく両立させる方法はないのか？データ分析と著名人対談を通じて考える。 「約4割のエンジニアが、ある時期を境に開発業務（コーディング業務）から完全に足抜けしなければならないと回答」 「マネジャー以上の年収分布では、技術専門職より一般管理職の方が年収が高い傾向に」 弊誌が今年3月に行った【IT・Webエンジニア300人調査】では、勤務先のキャリアパスについてこのような現実が浮き彫りになった。 >> 「コードで食っていく」は何歳まで可能か？エンジニア300人調査で見えた理想と現実 エンジニアという職業を選んだ以上、何かを作る仕事をし続けたい
リスクを直視しないという罪:『熊とワルツを』 - 詩と創作・思索のひろば
ウィッシュリストに入れてたのを同僚が贈ってくれた。 熊とワルツを リスクを愉しむプロジェクト管理 作者: トムデマルコ,ティモシーリスター出版社/メーカー: 日経BP社発売日: 2013/09/12メディア: Kindle版この商品を含むブログ (4件) を見る リスクのあることを知りながら何もアクションをおこさないことは罪である……といったエピソードからこの本は始まるのだけど、もうこの言葉だけで重要なことはほとんど言ってしまっているような感すらあった。自分が今までしてきたのこれは罪だったんだ！ と知らされる衝撃があった。いわゆる罪の文化というのもあるのかなと感じる。 もちろんこのことは導入であって、より詳細に、 リスクとは何なのか リスク管理をする理由・しない理由 リスク管理の方法 といった話がメインの内容として続く。 リスクとは何なのか この本では、リスクとは顕在化する前の問題であり、
ヤフー人事に聞いた、進捗管理で終わらせないための「1 on 1」
少人数で始まったスタートアップも、いつかは組織になるタイミングがやってくる。そんなとき、組織化のための一手として注目されているのが「1on1」（ワン・オン・ワン）だ。 「『1on1』は、単に上司・部下が仲良くなるための時間ではありません。“明日からの自分をもっと良くするためにはどうすれば良いか”を考えるための時間です。いわば、部下の“気付き”や業務を振り返って“内省”“経験に基づく学び（経験学習）”を支援するためのものですね」（ヤフー 人財育成リーダー 小向洋誌さん）。 小向さんは、ヤフーが2012年4月に新経営体制を発表した後、それに伴う組織開発・人財開発を進めてきた人物の一人だ。さっそく、1on1の定義や具体的なやり方について話を伺った。 小向洋誌（Hiroshi Komukai）。ヤフー株式会社 ピープル・デベロップメント統括本部 人財開発本部 組織・人財開発部 人財育成リーダー。起
ドラクエ風スキルマップ - nemorineのブログ
あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！ まあ会社という組織ではよくありますよね（苦笑 チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。 これもまさにゲーミフィケーションって感じですねぇ～ スキルマップを作る過程 元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ！！ 以下は川口さんのオリジナルから変更したところです。 要件定義のスペシャリストとして、商人を追加。 旅芸人はマネージメントのイメージに変更 スキルの方向を上方向に変更 盗賊のスキルレベルの見直し CやC++をイメージして文言を見直し 特性に対応するキーワードを追加 スキルマップを記述する チームメンバーに実際に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleと完璧なチーム
開発組織マネジメントのコツ - Speaker Deck
