最近よく聞く「DevRel」ってなに？ | 株式会社ユーティル
こんにちは。岩田です。 IT・WEB業界に飛び込んでみて、はや1年ちょっとが過ぎますが、最近「DevRel」という言葉をよく聞きます。 「DevRelって一体なんぞや？」と思ったので軽く調べてみました。今回はその共有です。 DevRelとは？ DevRelとは”Developer Relations”の略語のようです。リレーションズって？と思われるかもしれませんがこれは実は結構馴染みのある言葉で PR：Public Relations IR：Investor Relations という言葉はよく耳にしますね。 要はDeveloper（開発者）に向けて自社サービス等を知ってもらうためのマーケティング・広報活動を指す言葉ということみたいです。造語なんですかね。読み方は諸説あるみたいですが「デブレル」と読むのが一般的なようです。 DevRelが生まれた背景 なんでこういう「開発者に特化したマーケ
エンジニアリング組織論への招待を読んだ - blog.toxn
正確にはKindle本をiOSのテキスト・トゥ・スピーチで聴いた。 通勤中にajitofm 20: Refactoring Organizationsを聞いていて、会社着いたらポチっていた。 今の職場での失敗・成功体験が自分の中でも整理出来てきた頃、かつ、新組織のチームリーダーの立場でどうチームをまとめていくか不安もあった頃で、 この本がすべてを語ってくれていたので、とても良いタイミングで出会えたのだと思う。 自分の思考について 「嫌われる勇気」「幸せになる勇気」を読んで以来、アドラー心理学に感銘を受けていて、自分の考え方の軸になっている。 「エンジニアリング組織論への招待」も、同様の考え方が出てくるのだけど、アプローチがすごくロジカルで感動した。 例えば、 人は知らず知らずのうちに、「コントロールできないもの」 をコントロールしようとして、さらに思考が混乱するとか、ストレスに感じてしまい
初期スタートアップにおける社内文化の在るべき形とは - machio Development Diary
はじめに この記事は6人の小さなチームのマネジメントを3ヶ月齧っただけの僕が、それでも外部のメンターさん方に猛烈に相談に乗っていただいたりしながら 社内文化 について試行錯誤した道のりについて綴っています。拙文ですが温かく見守ってくださると幸いです。 背景 簡単に背景を共有させていただきたいと思います。 僕が3ヶ月間エンジニアのマネージャーを経験したこと 僕が所属している 株式会社Flatt のエンジニアチームは 12月まで 1月以降 実働人数 3人 2倍の6人に 社長の関わり方 手も動かしつつマネジメント 現場を離れて社長業に専念 （マネジメント層が不在） というように 2017年 => 2018年 という年の変わり目を境に大きく環境が変わりました。 そこで純エンジニアポジションでは1番の古株だった（それが理由かはわかりませんが）僕がエンジニアのマネージャーに抜擢され、この3ヶ月間 6人
サーバント・リーダー「10の特性」あなたはいくつ該当するか？ | プレジデントオンライン
なぜあの上司に人はついていくのか──。彼らが無意識にでも実践しているリーダーシップ哲学がある。もはや「オレについてこい！」だけで部下は動かない。今、注目を集める理論を紹介しよう。 「優しい人」とはどこが違うのか？ 「召し使い」を意味する「サーバント」と、組織を導く「リーダーシップ」という正反対の言葉を結合させたサーバント・リーダーシップとは「リーダーである人は、まず相手に奉仕し、その後に相手を導くものである」というリーダーシップ哲学である。この理論は部下に対して明確なミッションやビジョンを示し、それを遂行するメンバーに奉仕するリーダーシップと定義される。 上司は自分のミッション、ビジョンを実現させるための道具として部下がいると考えるのではない。それを実現するためにメンバーが行動してくれる。ゆえにそのメンバーがより活躍しやすいようにと環境を整え、支えるのがリーダーの役割だと考えるのだ。 サー
VP of Engineering Meetup by CA #3
ZABBIXの運用において、 自分で自分の労働力と時間を節約する為の工夫事例紹介 #zabbix_jp
「ベストを尽くせ」だけではベストは生まれない - 「マネジメントとは何か」を読んだ - $shibayu36->blog;
「マネジメントとは何か」を読んだ。 マネジメントとは何か 作者:スティーブン P. ロビンズSBクリエイティブAmazon この本は人間の行動に関する研究論文を多く読んだ筆者が、その見識を専門用語を使わずにまとめてくれている本。採用、モチベーション、リーダーシップ、コミュニケーション、チーム作り、衝突の処理、職務設計、業績評価、変化への対応というように、人間の行動に関する主要な問題分野ごとに章立てされていて、それぞれの章でテーマに沿った知見を得ることができる。非常に簡潔な言葉でまとめられていて、かつ250ページほどの分量なのでかなり簡単に読め、内容はかなり興味深いものが多かった。 マネジメントに携わる人、例えば経営、チームマネジメント、人事などを仕事としている人には非常に参考になる文献だと思う。 いつもどおり、この本の中で印象に残った話題について書いていきたいと思う。 「ベストを尽くせ」だ
マネジメントの要素を知る - 「マネジメント入門」を読んだ - $shibayu36->blog;
マネジメントの技術全体に興味があるので、その要素にはどういうものがあるかを知っておくために「マネジメント入門」を読んだ。 マネジメント入門---グローバル経営のための理論と実践 作者:スティーブン P. ロビンス,デービッド A. ディチェンゾ,メアリー・コールターダイヤモンド社Amazon この本は、マネジメントにはどういう話題があり、それぞれにはどのような研究や考えがあるかについて、ざっくり概要を教えてくれる本だった。マネジメントの機能を、計画する、組織する、リーダーシップを発揮する、コントロールするの四つに分類して話を進めている。目次は以下のとおり。 イントロダクション: マネジャーとマネジメント・マネジメント環境・マネジメント全般に関わる課題 計画する: 意思決定の基礎・計画策定の基本 組織する: 組織の構造と設計・人材を管理する・変革とイノベーションのマネジメント リーダーシップ
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
Infrastructure as Codeと組織構造
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
10分で分かる、いま話題の未来組織「ティール組織」 | ハイクラス転職ならdoda X（デューダエックス）
doda X（旧：iX転職）は、パーソルキャリアが運営するハイクラス転職サービス。今すぐ転職しない方にも登録いただいています。 今の自分の市場価値を確かめてみましょう。 ビジネス書の中でも、とりわけ王道なのが「マネジメント」のカテゴリー。どのように組織を運営し、上司は部下にどのように接し、会社ではどのように目標を設定するか。そして、どうすればより高い成果・業績が挙がるかについて、解説された書籍はゴマンとあります。 その内容はさまざまな切り口、さまざまな理論とともに紹介されており、どれももう出尽くしたのではないかと思われても、毎年毎年、新しい「マネジメント本」が発行されます。大ヒットは出なくとも、コンスタントに売れ続ける分野というわけです。 ところが最近、このマネジメントの分野でダントツの売上1位を記録し、一般書籍を含むランキングでも上位を席巻している本があります。『ティール組織』です。 2
管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
青学･原監督｢管理職の仕事は管理じゃない｣
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
マイクロソフトが人事評価の重点を「個人業績」から「協力」と「成長」へ舵を切ったぞ！ - ICHIROYAのブログ
この12日（2013年11月12日）、マイクロソフトの人事担当重役Lisa Brummel氏が、全世界の社員に送ったメモで、マイクロソフトは今後、「個人業績」よりも、チームへの貢献度、チームとの協同、個人の成長に重点を置く人事制度に刷新すると宣言した。（参照元ーメモの全文もあります） 詳しい内容は他のニュースメディアにお任せするとして、マイクロソフトが何を変えようとしているのか、僕なりに紹介したい。 彼女のメモの中に、「No more Curve」「No more ratings」とあるが、その意味は、マイクロソフトがいままで採用してきた、stack-rankingというマネジメントスタイルを辞めるということだ。 stack-ranking(もしくは、Vitality curve)が何かと言うと、ジャック・ウェルチ氏が有名にした評価モデルで、20-70-10システムとも呼ばれる。 どんな組
ドリコムを退職しました……弟子が | 外道父の匠
世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 本人には「退職エントリ書くね！」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4～5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン
より良い組織を作るために - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部部長の勝間です。 突然ですが、皆さんは「組織における課題」について考えたこと、意識したことはあるでしょうか。 「組織における課題」なんて言葉を使うと、たとえば 事業戦略の方向性 人事評価制度 マネジメント層の育成 など、少し高いレイヤーの話が思いつくでしょうか。 ともすれば自分とは無関係な話のように思えるものかもしれません。 一方で、このようなものはどうでしょうか。 なんとなく、最近社内の空気変わった気がする なんとなく、隣の部署が何やってるかよくわからない このような、もやっとした感覚、は普段働いている中で感じたことがある人も少なくないかもしれません。 こういった「具体的な何か」というより「抽象的な違和感」を私たちが抱くことも組織における課題といってもいいかと思います。 このような組織における課題、違和感を認識したとき、私たちはどのように向かい合うべきでし
U理論が面白い - 西尾泰和のはてなダイアリー
U理論の本を流し読みしてたけど、これは結構面白い。 PDCAサイクル(計画→実行→評価→改善)は、既にサイクルが回っている人にとっては納得感があるのだろうけども、回ってない人にやらせようとすると「で、計画はどうやって立てるの？」で悩んで止まってしまったり、逆に問題に対する知識が不足してる可能性に無自覚なまま、詳細すぎる計画を立ててしまって、後からわかった情報で瓦解したりする。 科学的思考法の「仮説→実験→検証→修正」のサイクルでも、流行りのリーンスタートアップの「仮説検証のサイクルを高速に回せ」でも、やっぱり実際にやろうとすると「で、仮説はどうやって見つけるの」というところでつまずく人がいる。 この手の「サイクル」に入る手前でつまずいている問題について、僕はいままで「まず観察を」と言ってきたのだけど、U理論はこの部分を7段階に分けて考えている。 一つ目は、物事を既成概念に当てはめて見ている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
成果を出し続けるエンジニア組織を目指してやってること
メルカリの組織は達成型？ティール型？これからの社会における組織開発とは - メルミライ - 未来を見るメディア。
【Omoroki 9 Hacks】 組織のあり方を考えている人へ
