カルチャー崩壊と再構築。 Goodpatchが取り組んだ組織デザインの2年間 - 前編｜Naofumi Tsuchiya / Goodpatch
会社組織を運営していく上で企業文化の重要性は多くの経営者が理解している事かと思います。僕ももちろん起業前から企業文化が一番の差別化ポイントになると理解し、会社運営をしておりました。 創業期から毎日の朝礼、朝礼ではLTと英語でのカンバセーション、毎週月曜日のプロジェクトレビュー、オープンでフラットなコミュニケーション、グローバルコミュニケーション、チームでデザインする、デザインに対してのディスカッションなど、多くのカルチャー醸成のために多くの取り組みを行ってきました。 しかし、僕の経営するGoodpatchは約2年半ほど前に組織とこれらのカンパニーカルチャーがほぼ全て崩壊するという事態に陥りました。 この2年間は自分にとってGoodpatchの失われたカルチャーを取り戻し、再構築するために奮闘した期間でした。 組織の急成長フェーズに起こる事例だと思うので、起業家やこれから組織を作っていく人達
『失敗の責任は私にあります』と言えない責任者たちの話。
昔、あるメーカーで経営企画職を担当していた時のことだ。 営業部の部長から、 「ウチの商品が絶対に安心で安全という証明書って発行できませんかね・・・」 と相談を受けたことがある。 聞けば、大口顧客との取引が受注寸前で、最後にそのような証明書を出せれば契約してもいいと言われているようだ。 しかし仕様書や保証書ならともかく、絶対に安心安全な証明書などどうしろというのか。 安心安全に使えるガスボンベだって火の中に放り込んだら爆発するし、腹痛を治してくれる胃薬でも用法・用量を守らなければ命に関わる。 どういうものを書いてよいのかわからず、先方ともう少し要件を詰めて欲しいと押し返すと、 「絶対安心安全の証明が要件なんですよ・・・」 と埒が明かない。 やむを得ず、一度部長に同行し先方の会社を訪れ、どのような証明を求めているのかをヒアリングすることにした。 応対に出てくれたのは、若い現場主任だ。 熱気と熱
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
スクラムで開発するときに大変なところをぼやーっと - Mitsuyuki.Shiiba
ぼやーっと書いてみようと思ったら、ほんとにぼやーっとした感じになってしまった。まいっか。 いい感じのスクラム？ バックログアイテムが小さく作られてて内容が明確で スプリントの途中で差し込みもなくて開発者たちは開発に集中できて 他のチームとの依存はなくてすべての開発がチームの中だけで完結する。 そういう状況だと、まぁ、なんかいい感じに開発できるんだろうなぁと思ったりする。 実際は？ (1) バックログアイテムを準備するのがまず大変。 (2) それから、サービスを運用しているので突然の依頼や問い合わせみたいな差し込みはあるし。 (3) 他のチームとの依存もある。 (1) バックログアイテムの準備が大変 バックログアイテムの準備のときには、プロダクトマネージャーが色んなステークホルダーと調整したり、ビジネスチームやデザインチームと相談したりしつつ、もちろん開発者たちの意見を聞いたりもする。 「開
管理職のための役職引退マニュアル | DevelopersIO
はじめに クラスメソッド株式会社で取締役及びAWS事業本部の本部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業本部の本部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって本部長を引退することにしました。 部長や本部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は本部長という役職で、事業本部の中に部があり
エンジニアがエンジニアの求人を本気出してつくったことを通して、本当に言いたかったこと｜河村 綾祐 (r-kawamura, clonable-eden)
はじめに こんにちは & はじめまして、エンジニアをやっている河村といいます。今は株式会社VOYAGE GROUPの子会社、株式会社Zucksでエンジニアをしていて、2019/10から取締役CTOをやっています。 今回は、就任からしばらく時間が経ってしまいましたが、就任エントリとして初noteを投下してみようと思います。 というのも、とある人事の方に 「（求人票を）数日かけて本気で書いたんで」がもったいない。 そのプロセス公開も魅力だと思うんですよ。こんな風に採用考えてくれるCTOがいる会社にいきてーわ。ってなるんですお。 というありがたいお言葉をいただいたのがきっかけです（引用は原文ママ）。 簡単に自己紹介します今は株式会社VOYAGE GROUPの子会社、株式会社Zucksで取締役CTOをしています。過去の略歴は以下です。 SIer〜採用関連サービスASP〜SIerを経て、2013年シ
ネットフリックスのような「ルールのない企業」は、どうやって社員の愚行を防いでいるのか。
45歳のプログラマーが、警察庁、NTT、SMBCの一部システムのコードを流出させたというニュースを見た。 三井住友銀行などのソースコードが流出 “年収診断”したさにGitHubに公開か【追記あり】（ITmedia） 三井住友銀行（SMBC）は1月29日、同行のシステムに関連するソースコードが外部のWebサイト上に無断で公開されていたと明らかにした。 情報漏洩の事件自体は既に珍しくないが、気になったのが、流出させたとみられる本人の反応だ。 「商用利用してないので、何も言われないと思う」という呑気なツイートをしている。 出典：45歳プログラマーさん、警察庁とNTTとSMBCのソースコードを世界に無償公開してしまう ツイートを見るに、年収を査定してくれるというサービスを利用するために、ソースコードをアップしたという。 だが、「普通に」考えたら、お客さんに納品したコードを「本人が使い方もままならな
社外の人とSlack でコミュニケーションする時は、こんな思想で運用すると完璧じゃないかな。
Slackが会社の中に浸透してくると、協業先、ベンダー、パートナー等社外のコラボレーターとのコミュニケーションもSlackでやりとりしたくなりますよね。 「Slackコネクト」がローンチされて、相互にSlackを契約している場合は、基本的に「共有チャンネル」を作成して、相互のSlackオーガナイゼーションが連携され、そのチャンネルに双方の関係者を招待することで、コミュニケーションできる様になります。 ただし、Slackコネクトは双方共にSlackを契約している必要がありますので、先方がSlackを契約していない等の時は、自社のオーガナイゼーションにゲストとして招待する運用をしています。 Slackコネクトを推奨する あくまでもゲストアカウントとして招待するのは、Slackコネクトが利用できない時に限り許可しています。それは以下に挙げられる利点及びセキュリティ上の懸念があるためです。 会話履
私たちの能力には「発動条件」がある。｜青田努（@AotaTsutomu）
優秀な人でも、環境が変わったら今までのように優秀でいられなくなることがあります。なぜなら、私たちの能力には「発動条件」があるからです。 万能の優秀さは存在しない これは私自身が経験したことですが、自分自身の能力をフルに発揮できた職場もあれば、あまり発揮できなかった職場もありました。 同じ人間なのに、基本的な保有能力が変わっていないはずなのに、優秀な自分と、そうでない時の自分がいる。ここから気づいたのは「万能の優秀さ」は存在しないということです 私たちが持っているのは、あくまでも「持ち味」であり、それがプラス発揮できる職場であれば「強み」に変わるし、できなければ「弱み」に変わることもあります。 たとえば「時間をかけてでも精緻なプランを立案する」ことがベースの職場で活躍していたAさんが、転職して「あまり時間をかけずに、まずはコア部分の最低限のプランを考えて素早く前進させる」ことを良しとする組織
組織の"わからない"に対する不快感 - Konifar's ZATSU
組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか
開発組織で重要なコンウェイの法則ともう一つの原則
原則を数個決めたら他のことはすべてそれらから導出されるような考え方が好きです。 開発組織の設計あたってはコンウェイの法則というのがよく参照されます。 コンウェイの法則：システム設計は、組織構造を反映したものになる コンパイラーを3チームで開発すると必ず３パスのコンパイラーになる、みたいな例を読んだことがあります。 これが起こる理由は、チーム内でのコミュニケーションコストがチーム間のコミュニケーションコストよりも格段に低いためです。同じチームで開発するシステム内はコミュニケーションコストが低いため密結合になり、チーム間のシステム結合はコミュニケーションコストが高いため疎になっていきます。 これを逆手に取って、最終的に実現したいシステムの形に合わせて組織を分けるのが逆コンウェイの法則です。 大きな単位のシステム設計は、３年、５年、あるいはそれ以上の長期間に渡って影響を及ぼします。ここを間違うと
やさしい「事業がわかるエンジニア」入門｜Jumbo
副業や本業で経営者の方や様々な管理職の方々と話してきて「事業のわかるエンジニアがほしい」という言葉を耳にすることがあります。一方でメンバーや社外の人と話していて「事業がわかるエンジニアになりたい」ということを聞いており、「ほしい側」「なりたい側」が存在し、それぞれ概念としてて言わんとすることはわかりつつもズレているなと感じることや言語化が足りないと思うことがよくあります。 ほしい側もなりたい側ももっと言語化してほしいな〜と思うので「事業」の意味するところ・なにを「わかる」べきなのかを私なりに分解していこうと思います。 「事業」とは何 事業とはなんぞや。そもそも定義を見てもよくわからないものでしゃべるなというのもあるんですが、一般的なインターネット企業などで思いつくだけでも以下のようなものがあると思います。 ・「売上や利益」を指す ・「原価やコスト」を指す ・「上記に関する副次的なKPI（有
キャリアのわがままを言える組織をつくる - Unknown Error
この記事は、Engineering Manager Advent Calendar 2020の23日目の記事す。 組織は個人で成り立っている これまで様々なチームや組織を見てきて、一つたどり着いた結論として、個人を無視してチームや組織を成り立たせることは不可能だということだ。 一人ひとり様々な事情を抱えてそのチームや組織に参画している。 そのプロダクトが好きで本気で良くしたいと思っている人もいれば、技術力を高めたいと思ってそのチームでの開発を足がかりにしている人もいれば、お金をもらっているので何でもやりますという人もいる。 チームに色々な人がいるのは当然なことで、目的が何であれ、何かしらの縁があってそのチームに参画している。 個人の事情を全く考えずに、チームや組織という単位で常に意思決定しているようであれば、もしかしたらものごとを単純化しすぎてしまっているかもしれない。 個人のキャリアに寄
CTO15年やってみた (その2) -大事にしている7つのこと- | GREE Engineering
ごあいさつ (読まなくてもいい前置き-1) みなさまこんにちは、グリー株式会社でCTOをやっているふじもとです。実はそのかたわら日本CTO協会、略してCTOAというところの理事をやらせていただいているのですが、勢いで「CTOでAdvent Calendarやろうぜー」と言い出してしまい、まぁ言ったからには1日くらい書くかー、後半にしておけば (おそらくそれまでに何日か書き忘れがあるだろうから) まぁ最悪書けなくても平気だろうと本気思っていたんですがなんと今日にいたるまで毎日継続しております、みなさんすごいー、すごすぎるー。 ということでこれは、CTOA Advent Calendar 2020 20日目のエントリです。僕のはともかく、他のみなさまの素敵なエントリが並んでいますので、ぜひぜひご覧ください。 大事にしていること？ (読まなくてもいい前置き-2) CTOとして何をすべきか、問題に
ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る｜kyuns /キュン 今村雅幸
こんにちは、ZOZOテクノロジーズで執行役員CTOをしている @kyunsです。 本記事はCTOA Advent Calendar2020の 16日目の記事となります。 この記事ではZOZOでの2年半を振り返り、テックカンパニーを目指す中でCTOとしてどのようなことに取組み、結果としてどういう変化が起きたかについて紹介したいと思います。 同じような立場のCTOやこれからエンジニアリング組織を強化していきたい方々の参考に少しでもなればと思います。 自己紹介と背景 私はヤフーに2006年に新卒で入社し、3年働いた後に当時一緒に働いていた金山と一緒にVASILYというスタートアップを創業し、受託アプリ開発や「IQON」というサービスを開発していました。 何度かの資金調達などを経て、最終的に2017年にZOZOへ売却し、ZOZOの完全子会社となりました。その後、2018年の4月には当時のスタートト
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
大規模組織でLeSSの再導入をしています - ねこのひたい
スクラムが好きです。ここ数年、スクラムをよく知らないけどスクラムイベントをやっているという現場でスクラムを再導入するということに向き合ってきました（よくよく考えると不思議な縁だなと思ったのですが、よくあることなのでしょうか）。 今まさにそろそろ始めるぞ！というタイミングなので、始めるまでにやったこと、考えたことをまとめていきます。 現在の現場ではスマートフォンゲーム開発をしており、組織規模は大きめです。エンジニアはスクラムチームが複数作れる人数、ディレクターが複数人いて、デザイナーは少なめ、QAチームがたくさんというチーム構成です。PMやEMも複数人います。スクラムを知ってる？と聞くと「なんとなく知ってる」「聞いたことはある」が若干名。 プロローグ 状況把握 弊社のEMは組織課題の解決やアジャイルな開発プロセスの導入が含まれています。 まずは現在どのような状態を把握するためにヒアリングから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Effective Remote Working
Engineering Ladder | メルカリエンジニアリング
