マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。開発副本部長の okady です。 サイボウズ開発本部では2019年に組織変更を実施し、当時のインタビュー記事で私はこんなことを言っていました。 「マネージャー、いないと無理なら、またつくればいい」 サイボウズの開発本部がマネジャーをなくしてみた「いないと無理なら、またつくればいい」 | サイボウズ式 そして今回の記事は、当時の私自身の言葉に応えるタイトルにしました。 「マネージャー、いないと無理だったので、またつくりました」 2019年の組織変更から3年が経ち、目的は概ね達成できました。しかし、思い通りにいかなかったことや当初想定していなかった問題もたくさんありました。そして2022年5月、開発本部の組織力をさらに強化すべく再び大きな組織変更に取り組むことを決断しました。 この記事では、2019年の組織変更とその後を振り返った上で、2022年に実施した新たな組織変更についてご
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
なぜ組織の透明性が大切なのか - 30歳からのプログラミング
個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし
エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita
Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。 マネジメントを始めて悩んだこと 約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー（以下、EM）としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。 そんな中で常に「自分がマネージャーとしてきちんとできているのかが分からない」という不安を持っていました。また、どんなスキルをつけて、どうなれたら正解なのかというイメージが見つからず悩んでいました。 ある時、先輩との1on1で、「（メンバーとの1on1やメンバーの育成を）どうしてそれをやるのか」と問われ
Building Self-Managed Teams: A Case Study from Riot Games
Receive our best content two weeks before anyone else! Join 5000+ tech leaders and managers. Building Self-Managed Teams: A Case Study from Riot Games - Interview with Mike Seavers (ex-CTO, Riot Games) Building self-managed teams sounds way too optimistic to be a viable strategy. Or does it? Imagine this: a team where you don’t have to hold anybody’s hand. A team that delivers results with you onl
管理職のための役職引退マニュアル | DevelopersIO
はじめに クラスメソッド株式会社で取締役及びAWS事業本部の本部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業本部の本部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって本部長を引退することにしました。 部長や本部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は本部長という役職で、事業本部の中に部があり
組織の"わからない"に対する不快感 - Konifar's ZATSU
組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか
Engineering Manager になってから身に沁みた12のアイデアと言葉 part2 - これはただの日記
2019/12 にこんな記事を書きました。 kths.hatenablog.com あれから一年たち、日々積み上げた新しいアイデアをみなさんとも共有したいと思います。 システム操作性スコア 私が勤めるスタディストでは、一部のサービスがマイクロサービスとして稼働しています。また、それ以外にも稼働している別プロダクトがあったりと、徐々に組織の管理対象となるサービスの数が増えつつあります。また、今後もその数は増加していくことが予想できます。 2020/12/26に発売されたばかりの書籍『モノリスからマイクロサービスへ』では、マイクロサービスが引き起こす可能性のある痛みの一例として、孤児サービスという言葉が登場します。これは文字通り、所有権や責任を負う人がいなくなってしまったサービスのことで、孤児サービスに対するトラブルシューティングは困難になることが予想されます。単に一部機能の停止で済めばマシで
開発組織におけるマネージャの責務を分解し、チーム運用してみる - Techtouch Developers Blog
この記事はテックタッチアドベントカレンダー14日目の記事です こんにちは、テックタッチ株式会社の kenyu (@mxxxxkxxxx) です。ソフトウェアエンジニア兼ピープルマネジメントを担当しています。 弊社ではマネージャの責務を分解し、チーム運用しています。この記事では実例を交えつつその説明をしたいと思います。 注意 当記事は B2B SaaS のスタートアップにおける15人程度の開発組織を前提としています。そのため、記事の内容は組織によって成立しない可能性があることをご了承ください。 背景 弊社は B2B SaaS のスタートアップです。それがゆえに、ヒト・モノ・カネのようないわゆる経営資源の乏しい会社です。 そんな状況で普通にやっていては、例えば IPO のような大きな目標を達成することは困難です。ではどうすればいいか？と自分に問いを立てたとき、脳裏に浮かんだのは、 メンバーひと
Engineering Managerの役割 - 組織と成果の視点から｜Yoichi Tagaya
この記事は、Engineering Manager Advent Calendar 2020 の初日向けに書いたものです。Engineering Managerの役割を、組織自体の強化と組織が成果を出すプロセスの強化に分けて解説します。 Engineering Managerを続けていると、組織課題を解決しても一向に状況が改善しないという悩みを持つ時はありませんか？自分自身が課題の中に入ってしまうと、一歩引いて真の課題を見つけることが難しくなりがちです。そのような場合や抽象度の高い課題に取り組む場合など、Engineering Managerの役割を2つの視点で持つと、本質的な課題の発見と解決につながるはずです。 私は現在株式会社メルペイでDirectorとして組織やプロセスの課題の解決にあたっています。メルカリ・メルペイの組織が急拡大するフェーズで学び、経験してきたことを元にこの記事を書
組織規模とCTOの求められる役割の変化に関する雑記｜Matsumoto Yuki
CTOA Advent Calendar 1日目のバトンを受け取りましたので、1日目となる今回は、CTOに求められる役割の変化について、自分のこれまでの振り返りを兼ねて記事を書いてみようと思います。ちなみに今週はマガジンの連載をこちらの記事に代えさせていただければと。 普段はこちらのマガジンでソフトウェアと経営についてつらつらと書いています。ご興味ある方、年末の時間のあるときにでもご一読いただければ幸いです。 はじめにこの10年、エンジニアとしてのキャリアをスタートして今に至るまで、一桁人のスタートアップから1000人近い規模の開発組織を抱えた大企業まで様々な規模の組織のCTOを経験してきました。おおよその流れとしては、学生時代に小さなスタートアップを3社、その後Gunosyにて一桁人から60人前後の開発組織、現在はDMMのグループにて合計1000人弱の開発組織にてCTOをしています。 C
管理職のきみと、いつか管理職になるきみと、管理職が苦手なきみへ | サイボウズ式
マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！ こんにちは、Twitterで平安文学や読んだ本の話、働き方や好きなソーシャルゲームの話をしていたら、いつの間にかフォロワー数がだいぶ増えて、あちこちでいろんな原稿を書くことになった、「たられば（@tarareba722）」と申します。普段は出版社で情報系Webサイトの編集長を務めております。 本日はサイボウズさんからのご依頼で、仕事と働き方、それから「そのがんばりは、何のため？」という、いわゆるモチベーションにつ
コミュニティマネージャーへと"進化"する管理職～「実態に組織をあわせる」これからのマネジメント～｜河原あずさ@書籍「コミュニティづくりの教科書」 #コミュつく 共著者／コミュニティ・アクセラレーター
Potage代表 コミュニティ・アクセラレーターの河原あずです。コミュニティづくりのノウハウを活かし、企業向けの組織開発や人材育成研修のお手伝いもしています。 何度かCOMEMO向け記事で取り上げてきた「コロナ禍で変化する働き方」に関してですが、最も変化が訪れる職種に「管理職」があります。働き方改革の名のもとにコロナ禍前に変化は進んでいたのですが、リモートワークなどが当たり前になる世の中になることで、更に加速した、という表現がより正確かもしれません。 コミュニティづくりの専門家である私は、管理職の変化を促す根本は「組織のコミュニティ化の広がり」にあるととらえています。不確実性の高い環境においてビジネスを継続させていくには、旧来型のピラミッド組織ではなく、それぞれの決めたミッションをもとに生まれたチームが自律して動いていく組織形態の方がより柔軟に事業環境の変化に対応できるためです。 世の中の
専門職と視座
こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座！視座！」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ
Spotify’s Failed #SquadGoals
Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you. By Jeremiah Lee Sunday, April 19, 2020 • Listen • Watch • En français • 日本語で • Português (Brasil) About the cover illustration Of all the allures of startup culture, few are more desireable than the speed and nimbleness of a small team. Maintaining that feeling as a company grows is a challenge. In 2012, Spotify sha
エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
特別な経験なしスキルなし、成果を出せず悩み続けた25歳新任マネージャーが「THE CULTURE CODE」で最強チームを作るまで
初めまして、Uniposの川村と申します！ 僕は新卒からピアボーナスⓇ「Unipos(ユニポス)」を提供するUnipos社で働き、間もなく4年目を迎えようとしています。 昨年12月末までの計1年半ほど、UniposのSDR(インサイドセールス)チームでマネージャーを務めていました。Unipos SDRは立ち上げ時には自分を含め2名ほどのチームでしたが、事業成長と共にメンバーが増え、最終的には5名体制のチームになりました。 新卒3年目で4名のマネジメントを任された僕ですが、チームを率いる特別な経験やスキルを持っていたわけではありません。当然ながら人が増えたことでマネジメントの壁にぶち当たり、成果を出せず大いに悩みました。 ただどうせやるからには最高のチームを作りたい！と、それでも諦めずもがき続けた結果、最終的には商談数が前年比4倍まで向上するという、上半期の目標を大きく上回る成果を残すことが
マネージャーを否定しない組織をつくる - Unknown Error
RSGT2020が1/8~10に開催された。 昨年は楽しかったの一言に尽きたが、今年はとにかく考えさせられた。 というのも、私にとってここ2~3年のテーマだった、Agile × マネージャーというドンピシャなキーノートがSahotaさんよりあったためだ。 confengine.com 本記事では、このキーノートに焦点をあてる。 マネージャーを否定してはいけない Sahotaさんのセッションで最も印象に残った言葉が、「組織を変革させるとき、誰も取りこぼしてはいけない」というものだ。 私がBas(LeSSの提唱者)の認定スクラムマスターの研修に参加したとき、どんな役割を今やってますか？と質問された。 私はそのときScrumを推進する人ではあったが、Scrum Masterではなかった。なぜなら、私の行う役割にはエンジニアの評価やエンジニアの採用も入っていたからだ。 そのときはEngineeri
エンジニア組織のマネージャーが実施した10個のチームビルディング施策をメンバーの満足度別に紹介！ - ZOZO TECH BLOG
こんにちは！ 開発部SREチームの指原(@sashihara_jp)です。 弊社にはSREチームが複数あり、私が所属しているチームは主にZOZOMATなどの計測システム、ZOZOERPと呼ばれる服の生産に関するシステムなど複数のプロダクトを担当しています。 本記事では私がSREチームのマネージャーとしてチーム内で行ってきた施策についてご紹介したいと思います。現在チーム内で行っている施策は全部で10個程度あるのですが、今回チーム内で事前に各施策について満足度アンケートをとりました。ここでは満足度の高かった施策とそうでなかった施策について、その理由と共に解説していきたいと思います。 前提 満足度が特に高かった施策 1on1 チーム目標設定 意義目標 成果目標 行動目標 満足度が高かった施策 テックリードサポートタイム チーム内ZOZOエール 中長期タスク設定 KPT LT、技術記事執筆 輪読会
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織の持続可能性について
