エンジニアだけが優遇されるのではない組織をつくりたい - Unknown Error
※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。 手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって本当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2 一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。 会社はエンジニアの
組織変更したら部長がいなくなりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、最近愛媛から広島に移住した組織運営チームの水戸です。 2019年からサイボウズの開発本部から職能・地域毎に分かれた部署がなくなり、チーム主体の組織になりました。 組織変更をオープンに議論するというチャレンジングな試みの中で、新組織の理想はユーザー価値の最大化に定まり、個人やチームがより主体的に動ける組織構造に変わりました。 この記事では私がファシリテートを担当した組織変更をご紹介します。 開発本部の状況 開発本部の役割は製品を開発することです。 2018年までの開発本部はマトリクス組織を採用しており、プロダクト開発チームには様々な職能・地域毎に分かれた部署のメンバーが所属していました。 この組織構造は事業の中心がオンプレミスだった10年以上前から、事業の中心がクラウドに移った2018年に至るまで変わっていません。 一方、プロダクト開発チームに求められるものは大きく変わりました。
Kyashに入社して半年くらい経ちました - Konifar's WIP
早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの？という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク
効率化の果てに、最大の非効率が潜んでいる｜サイロ・エフェクト 高度専門化社会の罠 - ツイブロ｜ゲーム感想とか色々
『サイロ・エフェクト 高度専門化社会の罠』という本を読みました。 著者はフィナンシャル・タイムズ紙アメリカ版編集長であるジリアン・テット氏。本の帯に写っている方がそうです。 組織に蔓延る新しい形の腐敗を描いた一冊（正確には腐敗といってしまうと語弊があるかもしれませんが）。 高度に複雑化した社会に対応するため、大企業をはじめ様々な組織が専門家たちの「サイロ（窓がなく周囲が見えない状態）」になり、変化に対応できなくなっていると著者は言います。 本書ではサイロが組織におよぼす悪影響「サイロ・エフェクト」について、いくつかの実例をもとに、多面的に取り上げられていました。 ニューヨーク市庁 ソニー UBS銀行 シカゴ警察 クリーブランド・クリニック（アメリカの医療機関） フェイスブック 途中、金融関係の話は複雑で眠気を催したりもしましたが、警察や病院組織については海外ドラマの影響もあって、受け入れは
会社は真面目に経営されるほど「学習しない組織」になってしまう | ハイクラス転職ならdoda X（デューダエックス）
doda X（旧：iX転職）は、パーソルキャリアが運営するハイクラス転職サービス。今すぐ転職しない方にも登録いただいています。 今の自分の市場価値を確かめてみましょう。 世界的な大企業、いわゆるビジョナリーと言われる企業では、この30年ほど「学習する組織」をどのようにして創るかということが、大きなテーマとして扱われ続けてきました。 生き残る種とは、最も強いものではない。最も知的なものでもない。それは、変化に最もよく適応したものである（チャールズ・ダーウィン） 変化が激しい時代において、「企業や組織に集う人同士が学び、変化し続けることこそ重要である」という認識は多くの人が賛同するものではないでしょうか。 ところが、この点を多くの現役ビジネスパーソンや経営者と議論していくと、実は下図に示すようないつも慣れ親しんだ企業の運営体制こそが、実は「学習しない組織」にとても陥りやすいという衝撃的な指摘が
技術組織をスケールするためのCTL = チーフテクニカルリード - Kentaro Kuribayashi's blog
GMOペパボにおいて、チーフテクニカルリード(略称: CTL)という職位を作りました。既に以下のブログエントリで新任の2人がエントリを書いているところですが、制度設計者として、その背景を述べてみたいと思います。 diary.shu-cream.net ten-snapon.com GMOペパボの執行役員CTOになって1年半*1、その前に技術責任者に就任してから早2年*2が経過しました。その間、組織面においては、「いるだけで成長できる環境」*3、技術面では「事業を差別化できる技術」*4というコンセプトでやってきました。まだ道半ばではあるものの、逆にいえば、通るべき道は見えているともいえます。 そんな中で、この2年間、ずっと気にかかっていることがありました。 組織的にはエンジニアの人数が90人弱になり、近いうちに100人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい
『組織にテストを書く文化を根付かせる戦略と戦術』を聞いて #jopf - miyohide's blog
はじめに 先日開催された『開発を活性化するためのポイントとテストに関する勉強会』にて、『組織にテストを書く文化を根付かせる戦略と戦術』のお話を聞いてきたので、そこでの内容と自分が所属している組織への適用について記してみます。 各種資料 発表資料 組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada Togetter togetter.com 感想 衝撃的だったのは、「テストを書く文化の醸成には2年ぐらいかかる」という言葉。 t_wada「文化の醸成は年単位の事業になる。だいたい2年ぐらいかかる。」 #jopf— みよひで。オシャレ男子になりたい (@miyohide) 2016, 2月 16 一日二日でできるとは思っていないんですが、まさか年単位とは。 そのため、勢いで乗りきれるほど甘くはなく、戦略と戦術でもってテストを書く文化を醸成しましょうという話に続きます。
オレの理想の組織
2015/08/27 22:00 ※ 商品のリンクをクリックして何かを購入すると私に少額の報酬が入ることがあります【広告表示】 「 サービスがある程度完成してるクッ○○○○にエンジニアが居ついている理由も興味ある 」 サービスの大まかな形ができあがるとエンジニアは新しい何かを求めて辞めてしまうことがあると思っているので、ふと不思議に思いました。 ※念のため言っておくと今自分が属しているエンジニアチームはサービス立ち上げ前から1人も辞めていません（もっといえばその前の動画共有サービスを旅する元AWSエバンジェリスト？から 押しつけられて もとい、引き継いで以来6年間誰も辞めていません。あくまでも現時点では…だけれども）。 理由も とあるのはもう一つ興味のあることが同時にあって、 「 あれ？D○N○ってフラット組織なの？あの規模でどうなってるのか興味ある 」 上意下達というか、上司がいて部下へ
大きな業績を上げている部下が、職場で決められたルールを守らないとしたらどうするべき - ICHIROYAのブログ
もう30年以上前のことになる。 マネージャー向けのある研修で、こんな質問が出された。 「たとえば自部門の売上の3分の1を占めるような大きな業績を上げている部下が、職場で決められたルールを守らないとしたらどうするか」 ざっくりとしか覚えていないがそういう質問だった。 ああ、そういう部下を抱えながら、どうすべきか悩むのが管理職というものなんだなと、その時、管理職の仕事の難しさに震えた。 選択肢がふたつしかないとする。 A. その部下を叱責しルールを守らないなら他部への放出も辞さない構えで対応する B. その部下の業績に注目し、ルールを守らないことには目をつぶる その時の講師の答えは、いくつかの付帯条件がついていたが、基本的にBであった。 いや、しかし、ほんとうにそうなのかな、とも僕は思った。 たしかに、その部下を放出すれば、売上は3割下がる。 だけど、その部下が評価されて昇進していくにしても、
組織の新しいカタチ「Holacracy（ホラクラシー）」 - UXploration
ブログを移転しました。新しいページに自動で切り替わります。3秒お待ち下さい。 ---- 突然ですが、Holacracy（ホラクラシー）という言葉を耳にしたことはありますでしょうか？ 日本ではまだ参考文献が少ないためご存知の方は少ないかもしれませんが、サービスデザインないしは組織デザインのための学習の一環として調査し、まとめてみました。 Wikipedia によると、ホラクラシーとは従来のようにトップダウンのヒエラルキーによって意思決定がなされるのではなく、組織全体に権限を分散させ意思決定させることで、自走する組織を保つための社会技術または組織のガバナンス・マネジメント方法*1と定義されています。 (c) All Rights Reserved. 企業、NPO問わず今ではアメリカを始めフランスやドイツ、オーストラリア、イギリスで導入実績があるとのことですが、有名なところでは Airbnb、Z
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
イノベーションが失われた組織から脱却する10のルール | GREE Engineering
こんにちは！ ガレージスタジオ部 岸田崇志です。 記念すべき『GREE Advent Calendar 2014』1日目の記事となります！ GREE Engineers' Blogを書くことに憧れて入社したのですが、5年半経ってようやく夢が叶い感慨深いです。 と、前置きはさておき、本題に入らせていただきます。 ここ数年大ヒットが生み出せていないグリーですが、会社が大きくなる中でゲームが作りにくい組織になっていました。 そこで、その課題と現在行っている取り組みについて紹介させて頂きたいと思っています。 めっきりクリエイティブなイメージが薄くなってきたグリーかなと思っているのですが、 「グリーらしくない！」と言われるゲームを作ることが私の狙いの一つでもあります。 過去の自分を振り返り会社が大きくなる中で、自分自身の至らないところもあり以下の様なケースがあったかと思っています。 今までの課題事
上司が信用できない会社の内部統制 - slideshare
第32回WebSig会議「便利さと、怖さと、心強さと〜戦う会社のための社内セキュリティ 2013年のスタンダードとは？！」2013年3月9日 http://websig247.jp/meeting/32/ チームラボ佐伯さん，高須さんの発表資料です。Read less
「民主的なチーム」が崩壊した話 | サイボウズ式
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は、日野瑛太郎さんによる「話し合い重視で雰囲気の良いチームが必ず成果を出せるわけではない」という話です。 「民主的」であることはチームにとって重要か？ 僕がまだ会社員として働いていたころの話です。 ある時期に所属していたチームは、とても「民主的なチーム」でした。チームリーダーは意見を押し付けるような物言いを一切しない人で、メンバーの話をとてもよく聞いてくれました。プロダクトの仕様を決める際にも役職関係なく思ったことが言えるので、「気が進まないけど、仕事だからしょうがねーな」といったようなやさぐれた気持ちで働くことが非常に少なく、気持ちの面ではだいぶ働きやすく感じていました。 しかしこのチームは（働いていた会社はサイボウズではありません。念の
失敗プロジェクトの通夜 - Strategic Choice
どういうこと？心血を注いだプロジェクトが中断されたときは、「プロジェクトの死」を悼んで、「通夜」を開催します。どうして？仕方のない外的要因のせいであっても、チームにとって、心血を注いできたプロジェクトのキャンセルは、特に士気を下げる原因となります。キャンセルの裏にある事情を、チームが理解しているかどうかは、さほど問題ではありません。とにかく、悲しい気持ちになるのです。無力に感じたり、無気力に陥ったり、時には裏切られたように感じます。チームには、即座に始めなければならない次のプロジェクトがあったとしても、なんらかの休憩は必要です。です。最悪、チームメンバーは辞めてしまうかもしれません。プロジェクトがキャンセルされたのは、自分たちのせいではないにも関わらず、成功したプロジェクトにしか、報酬は与えられません。これは、きわめて強い不公平感を生む可能性があります。どうすれば？失敗したプロジェクトのた
チームビルディングで大富豪をやった話 - yohei's diary
先日リーンスタートアップセミナーというので、札幌に行って話をしてきた(発表資料)んですが、本題と外れたところでチームビルディングについて喋ったら思いのほか受けたので、ここにも書いておきます。 その当時は部門再編の時期で、僕たちは主に二つの拠点、三つの部署から寄せ集められた20数名の開発部門でした。当然それまでやってきたことはバラバラで、お互いのことをよく知らない。組織として何を作るかも決まっておらず、上からの具体的な指示もない。新横浜のオフィスに集結することは決まったけど、そのフロアは什器がまだ何もなくがらんどう、という状況でした。 そんな状況だったので、みんな何をやったらいいかわからんし、そもそも暇そうだから、一度集まれる人で集まって、話をしようと提案しました。 当時のメールをひっくり返したら、こんな風に書いてあった、と書きたいのだけれど今メールが見られないので★あとで書く→書いた★ 調
クソゲーを作る組織とそうでない組織 2012 05-12
1. クソゲーを作る組織と そうでない組織 株式会社 Aiming ジェネラルマネージャ / テクニカルディレクター 2012年5月12日 於 ゲームを作る勉強会 小林 俊仁 ( @toshi_k ) 2. About: 小林 俊仁 http://about.me/toshi_k オンラインゲームを作って早10年 基本はゲームも分かる web っ子 @toshi_k Community Engine でオンラインゲーム作って (2001~2003)、中国で子会社作っ てモバゲータウンの中国版（加加城）とか Play Online China とか作って (2003~2007)、子会社を閉じて日本に帰ってきて、その後オンゲの技術ディレク ターとかプロマネとかやってた 最近は、 ONE-UP → Aiming で組織横断的に開発プロセスの改善とかスクラム マスターとか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザのために技術をどう活かすか
営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの3+1のポイント | リブセンス
長文日記