ベルフェイス株式会社を退職しました - 針は飲まれぬ
こんにちは、@24guchiaです。 タイトルの通り、1年勤めたベルフェイス株式会社を退社しました。 ベルフェイスの入社エントリーはこちら。 ベルフェイス株式会社に入社しました なぜやめるか？ 入社エントリーにある入社を決めた理由が満たされなかった点と、アサインされていたプロジェクトの中断が理由です。 事業会社である以上、プロジェクトの中断は仕方ないので納得しており、僕が残る理由はなくなってしまったのが大きいですね。 ここでスクラム開発におけるスプリント異常終了時の注釈を読んでみましょう。 重要なのは、チームメンバーはリソースではないということだ。自分のコミットメントを外部の力でだいなしにされたことに、意見も感情も絶対に持っている。 Ken Schwaber ‒ March 6, 2008 Ken Schwaber 氏はスクラムガイドを書いた作者の一人です。 さて、ベルフェイスで学んだこと
ベルフェイスを退職しました
10 月末日をもちましてベルフェイス株式会社を退職しました。 短い間でしたが貴重な経験ができたのでここに記録します。 経緯 入社前 前職をやめる決断をして転職先を探していた際に ぺすちん(@Mrr_ma) さんに誘われたことをキッカケに入社しました。前職のプロダクト開発を活かしつつより大きなプロダクトを扱ってみたいという願望が叶いそうだった点と、コロナ禍においてリモートを推奨するプロダクトが追い風になるであろう点が決め手となりました。 入社後 2 ヶ月間 リプレイスチームに配属され、マイクロサービス化及びシステムのモダン化業務に携わることになりました。チームメンバーにも恵まれ、つよつよリードエンジニアやつよつよデザイナー兼フロントエンドエンジニア、優しい兄貴分のバックエンドエンジニア兼サブリーダーと勉強家で頭の切れるリーダー、同期入社のバックエンドエンジニアでスクラム開発を行いました。自分
幻影旅団のチームマネジメントのすばらしさとそれでも鎖野郎に半壊させられた理由を考察する｜人事のなべはる
記事の中で映画、ゲーム、漫画などのネタバレが含まれているかもしれません。気になるかたは注意してお読みください。 悪の組織の心理的安全性ランキングの栄えある1位はハンターハンターの幻影旅団です！ 幻影旅団はほんとうに良いチームなのですが、ここでふと疑問に思うことがあります。それは、「ヨークシンシティ編で鎖野郎に半壊させられてるじゃん」というもの。この疑問に答えるべく、筆をとりました。 というわけでこの記事では、幻影旅団のチームマネジメントがいかに優れているか？と、優れたチームマネジメントにもかかわらずなぜ鎖野郎に半壊させられたのか？をチームビルディングの観点から考察します。ヨークシンシティ編のネタバレありまくりなので、ご了承ください。 団員どうしの仲が良く、リーダーは親しみやすい幻影旅団が他の悪の組織と大きく異なるユニークな点は、上下関係なく団員どうしの仲が良いことです。 例えば下記の描写。
誰も教えてくれないネガティブメンバーマネジメント - どこぞのエンジニアなマネージャーだった人のブログ。
さぶたいとる:サーヴァントリーダーシップの限界 ネガティブメンバーとは 今回のネガティブメンバーとは｢愚痴を言う｣、｢怒る｣など、恒常的にネガティブな表現を周りにする人のこととします。 成果が出ていない。というのは今回は対象外です。 育成コースに移すなりしましょう。 ネガティブメンバーの思考、行動一例 評価に不満 チームの判断に不満 スケジュールに不満 不満を喋りつづける 納得した。風で納得していない 周りの失敗を認めない 周りの状況を鑑みない 周りを手伝わない 代替の提案をしない、聞き入れない まじつらいわー、俺一番頑張ってるわー 想定する聞き手 ネガティブなメンバーをマネジメントしている。 ネガティブなメンバーのマネジメントを今後は避けたい方。 マネージャー職に向けて今後の心構えをしておきたい方。 はじめに マネージャーであるならば、第一に、環境に対して文化づくりや評価、メンバーに対し
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
自分の頭で考える機会を奪われるということ
「考える機会を奪うのは、よくないことだ」という考えは、特にマネジメント論を読み漁っているとよく出会うでしょうか。続いて「そうすると部下が育たなくなる」といった文が添えられているのを何度か見たことがあります。 ただこれは、立場が相対的に上の人から相対的に下の人に対してだけではなく、逆のパターンもおおいにありえるのだと最近は思うようになってきました。 たとえばあなたがとある族に属していて、メンバー全員で族長をヨイショしまくったとしましょう。そんでもって族長もまんざらじゃない受け止め方をして、いい気分になって、自分をヨイショしてくれる民ばかりでまわりを固めるようになりました。そうしてだんだんと族長はまともに考える力を失い、族をよくない未来へと導いてしまったのでした…。 ウオォオォオォオォーッ どんな立場の人であっても、考える機会を奪われ続けたら、考える能力を失って、ダメになってしまう可能性を有し
組織の新しいカタチ「Holacracy（ホラクラシー）」 - UXploration
ブログを移転しました。新しいページに自動で切り替わります。3秒お待ち下さい。 ---- 突然ですが、Holacracy（ホラクラシー）という言葉を耳にしたことはありますでしょうか？ 日本ではまだ参考文献が少ないためご存知の方は少ないかもしれませんが、サービスデザインないしは組織デザインのための学習の一環として調査し、まとめてみました。 Wikipedia によると、ホラクラシーとは従来のようにトップダウンのヒエラルキーによって意思決定がなされるのではなく、組織全体に権限を分散させ意思決定させることで、自走する組織を保つための社会技術または組織のガバナンス・マネジメント方法*1と定義されています。 (c) All Rights Reserved. 企業、NPO問わず今ではアメリカを始めフランスやドイツ、オーストラリア、イギリスで導入実績があるとのことですが、有名なところでは Airbnb、Z
計画する技術 - kakakakakku blog
今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，
グーグル会長が語った｢価値を生み企業を成長させる人材のたった2つの資質｣とは
｢『潤滑油』を雇いすぎるな｣とアルファベットのエリック・シュミット会長は語る。（ラスベガスで開催された2017年SALT会議にて） Richard Brian/Reuters エリック・シュミット氏が2001年にグーグルの会長兼CEOに就任した当時、従業員はほんの数百人しかいなかった。しかし10年後、同氏が会長職に専念する為にCEOを退任する頃には、従業員数は3万2000人にまで膨れ上がっていた。 シュミット氏は今や、グーグルの親会社であり、世界最大級の影響力を持つ会社、アルファベットの会長を務めている。現時点で、アルファベットの従業員数は6万人以上、時価総額は約6630億ドル（約72兆9000億円）。 ｢私自身のみならず、グーグル全体のマネジメント哲学の基礎は、急成長していたグーグル黎明期に築かれた｣ LinkedIn共同創業者兼会長リード・ホフマン（Reid Hoffman）氏が有名創
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
ソニー株式会社を退職しました
表題の通り、数年勤めたソニー株式会社を退職しました。 個別具体の退職理由はいろいろあってそれらは後述しますが、退職を決めた基本的な理由は、個人的なキャリアパスの設計と会社の方針のミスマッチ、労働観のミスマッチ、技術投資の考え方のミスマッチの三点に集約できると思っています。 キャリアパスの設計と会社の方針のミスマッチ私はソニーでソフトウェアエンジニアとして働いていました。 ソフトウェアエンジニア(を目指す人間)にとってソニーと言えば、"自由闊達な理想工場"、エンジニアが自由に活躍できる会社、日本のメーカーなのにソフトウェアもちゃんとつくれる会社、などのイメージがあるかと思います。私もそう思っていました。 実際会社は説明会などでそういった説明をしましたし、そういったイメージを前提に私はソニーを選び、「エンジニアとしてプロフェッショナルになる。品質が高く、お客の求める体験を作り出せる人間になる」
「複雑さ」と「普遍性」とエンジニアのキャリアについて最近考えていること - Qiita
この記事は クラウドワークス Advent Calendar 2016 19日目の記事です。 昨年の、あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。に引き続き、エンジニアのキャリアについて書いてみます。 クラウドワークスにおけるエンジニアの3つのキャリア 当社では、エンジニアのキャリアを以下の3本の柱で考えています。 技術（アーキテクトやCTOを目指す） プロダクト（PO・PMを目指す） マネジメント（マネージャー・VP of Engineeringを目指す） 「技術」のキャリア 基本的に、多くのエンジニアはこのキャリアを望みます。エンジニアなので当たり前と言えば当たり前ですが。ただしその一方で、多くのエンジニアは、30歳前後でキャリアに悩む時期が訪れるように感じます。 一般的に、年齢が上がると「マネジメント」を求められるようになる、という環境のせいもあります。結婚（あるいは同
えふしん「現場に必要なのは『フルスタック』より『デュアルスタック』エンジニア」
「フルスタックエンジニアよりもデュアルスタックエンジニアのほうが必要」と呼びかけるのが、「えふしん」こと藤川真一さん。Twitterクライアント『モバツイ』の開発者であり、現在はBASE株式会社CTOとして長年Web業界をリードしてきた同氏が考える、いま現場に求められる「デュアルスタック」の考え方とは？ フルスタックは「専門職に失礼」 ——藤川さんが提唱されているデュアルスタックエンジニアの話に入る前に、藤川さんが考えるフルスタックエンジニアの定義について教えていただけますか？ 一時期、流行りましたよね、フルスタックエンジニア。要は、「自分が思いつく範囲のことを全部やりましょう」という話だったと思います。とはいえ、フルスタックと言っておきながら、実は全然フルスタックじゃないんですよね。デザインをやるわけでもないし、そもそもフルスタックエンジニアの役割にマネジメントは含まれていませんから。
パレートの法則 8:2の法則
パレートの法則（パレートのほうそく）は、イタリアの経済学者ヴィルフレド・パレートが発見した冪乗則。経済において、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているとした。80:20の法則、ばらつきの法則とも呼ばれる。 概要[編集] パレートは所得統計を分析して、所得分布が安定的であり、時代によって変化しないという結論を出した。この結論からは、社会の所得格差は平等にならないが、不平等も強化されないことになる[1]。パレートの法則は、関数のパラメータ（パレート指数）によって所得分布を時間・空間的に比較したもので、貧困についての最初の数学的な研究ともいわれている[注釈 1][3]。 しかし、パレートが発表した当時から難点があった。パレートの法則は低所得層に当てはまらないという問題があり、パレート自身も認めていた[3]。パレートが用いた統計はイタリアやスイスのいくつかの都市と、プ
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
製造業で入社6年目の社員です．担当していたプロジェクトの撤退が決まりましたが，その報告を役員に行わなければならないのですが，どうすればいいか悩んでいま…
製造業で入社6年目の社員です．担当していたプロジェクトの撤退が決まりましたが，その報告を役員に行わなければならないのですが，どうすればいいか悩んでいます．参考になるサイトや書籍，あるいはアドバイスがあれば教えてください． 以下，もう少し具体的な状況を書きます．プロジェクト撤退に至った理由は，PJリーダーのマネジメントの問題，担当者の能力の問題，どちらもあると思っています．しかし，PJリーダーがPJから逃げてしまい，一切責任をとってくれません．ですので私があらゆる説明をしなくてはいけなくなっています．一歩間違えれば，私が全面的に悪かったことになりかねません．しかし，逃げたリーダーに責任をなすりつけようとしても，自分に刃が返ってくることになりかねないと感じています． 以上，すみませんがよろしくお願いします．
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策 / 20171013
開発組織マネジメントのコツ - Speaker Deck
in the looop | Looops communications