不確実性や心理的安全性に向き合い自己組織化するチームを作る実践プラクティス
こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。 「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」 「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」 ... などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。 結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？ 本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。 プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。 1. チーム構成と特性 2. 特性が生み出しうるリ
1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断
■イベント 【Sansan Tech Meetup マネジメント編 #1】 1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断 https://sansan.connpass.com/event/238006/ ㅤ ■登壇概要 登壇者：Bill One Unit プロダクト開発責任者 / 大西 真央 「請求書受領から、月次決算を加速する」をコンセプトに2020年 5月にローンチしたクラウド請求書受領サービス「Bill One」。その事業成長を支えるエンジニアリング組織は、直近の1年で5人から30人と急激にメンバーが増えました。 本発表では、組織拡大の過程を振り返るとともに、エンジニア部門のマネジャーがその渦中でどのような課題に向き合い、どのようなことを考え、どのような判断をしたのか。プロダクトグロースの中でのエンジニア組織の変遷と、具体的な取り組み例をご紹介します。 ㅤ ▼E
視座の可視化｜kgmyshin
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
LayerXのカルチャーと行動指針 (2021年版)｜mosa
こんにちは！LayerXの榎本(@mosa_siru)です。 この記事では、LayerXのカルチャーについて紹介していきます。特に、2018年に創業したLayerXが、様々な事業の変遷を経て、行動指針がどう変わっていったかを話していこうと思います。 私達は、創業当初から 5 つの行動指針をもとに活動しており、それらがカルチャーの源泉となっています。 ・Be Animal ・Bet Technology ・Trustful Team ・Fact Base ・徳これらについては、3年前に書いた記事の後半でも説明しています。 3年たった今、これらの行動指針は、どうなっていったでしょうか？変わっていったのでしょうか？ LayerXの変遷そもそも創業当初から、LayerXはどう変わっていったでしょうか。変わったことが多すぎるので、本当に一部だけピックアップしていきます。 2019年 ・オフィスを東日
失敗から学んだエンジニア組織のマネジメント。LayerX松本勇気氏が3社で得た知見 - Findy Engineer Lab
LayerXでCTOを務める松本勇気さんは、これまでGunosy、DMM.com、そして現在のLayerXという3社でCTOを経験した方です。事業開発や社内制度の立案・実行、開発組織のマネジメントなど、数えきれないほどの施策を講じ、技術的側面から企業の経営を支えてきました。 そんな松本さんですが、決して最初からCTOとしてのスキルが優れていたわけではないといいます。むしろ、「GunosyのCTO就任初期の頃はマネジメントの経験が浅く、至らない点がいくつもあった」と松本さんは語ります。 この記事では松本さんに、マネジメントの知見を習得した過程や、CTOを務めた3社で講じた施策の意図について語っていただきました。「開発組織のマネジメント論を学びたい」「学習し続けるCTOの知見を知りたい」という方は必見の内容です。 *…取材はリモートにて実施しました。 【Gunosy】マネジメント経験のほぼ無か
【超長文】スタートアップ経営で現れる壁と事例とその対策について｜Takaya Shinozuka
そして、最近は若手起業家や経営を志す人たちとの接点も多くあり、エンジェル投資などもしていることもあってかよくこういった似た話をするので、まとめておこうじゃないかとまとめてみた次第です。「あれ見ておいてね」って言えたら楽じゃないですか。だから最後まで書き上げてみた。 ということで今回のNoteは、起業してから必ず遭遇するであろう壁（困難）の概要、事例、対応策についてのまとめをお届けしたいなと思います。 ※なおここでの内容は「社内の新規事業」でもまぁ似たようなものです。 スタートアップの壁についてスタートアップのグロースにはある一定の定石があると思っていますが、私はその道半ばで現れる「壁」には内容の法則性、乗り越え方（解決方法）なんかがあるんじゃないかという仮説を持っています。ここで言う「壁」の定義をしておきますが、簡単に言うと「出会ったら最後、乗り越えなくては成長が停滞する課題」のことを指し
人事評価は不毛？〜評価なしで100名の壁を超えたUbieの事例〜｜sonopy@Ubie
こんにちは、Ubie Discovery(AI問診ユビー/AI受診相談ユビー)でカルチャー開発を担当しているsonopyです。 タイトルの通り、弊社Ubieには人事評価がありません。「スタートアップなのでまだ評価制度を作れていない」というわけではなく、「評価はしない」と方針を決めています。 一般的には、社員数30名程度か、遅くとも50名規模では評価制度を整えていくかと思います。Ubieは現在社員数3桁に乗ったところです。この規模で評価なしの組織運営は珍しいので、「どういうこと？」と聞かれる機会も増えてきました。 私自身も大小IT企業の組織を経験してきましたが、過去の経験にない、ユニークな制度だなと感じます。評価せずどうやって士気の高い組織づくりをしているか、そのメリット・デメリットなどについてご紹介します。 個人評価や等級・役職はなし。昇給は会社成長と連動 Ubieにおける「評価しない」の
Engineering Manager になってから身に沁みた12のアイデアと言葉 part2 - これはただの日記
2019/12 にこんな記事を書きました。 kths.hatenablog.com あれから一年たち、日々積み上げた新しいアイデアをみなさんとも共有したいと思います。 システム操作性スコア 私が勤めるスタディストでは、一部のサービスがマイクロサービスとして稼働しています。また、それ以外にも稼働している別プロダクトがあったりと、徐々に組織の管理対象となるサービスの数が増えつつあります。また、今後もその数は増加していくことが予想できます。 2020/12/26に発売されたばかりの書籍『モノリスからマイクロサービスへ』では、マイクロサービスが引き起こす可能性のある痛みの一例として、孤児サービスという言葉が登場します。これは文字通り、所有権や責任を負う人がいなくなってしまったサービスのことで、孤児サービスに対するトラブルシューティングは困難になることが予想されます。単に一部機能の停止で済めばマシで
突破するプロダクトマネジメント - クラシル開発チームで実践した事まとめ｜坪田 朋
こんにちは、坪田です。 dely Advent Calendar 3日目の記事です。 昨日は、エンジニアのmochizukiが NetflixのFast JSON APIを使ってみた を書きました！ 僕は、クラシルを運営するdelyでクラシルユーザー体験と、開発部門のマネジメントに責任を持っており、そのプロダクトマネジメントのスタイルを書いてみます。 よく、CXOって何をするのか聞かれますが、僕の場合は社長である堀江さんのビジョンを汲み取り、1秒でも早く、ユーザーに評価される最適な体験を作ってリリースする事を仕事にしてます。プレイヤー領域としては、UIデザインを武器にしているので、ユーザー体験を可視化しながら関係者を巻き込んで開発するスタイルが強みです。 今回は、突破するプロダクトマネジメントという内容で、クラシルで実践しているプロダクトマネジメントの手法について書きました。 タイトルを突
ユーザーファーストであり続けるために開発チームオンボーディング資料を作ってみた｜坪田 朋
※クラシル開発チーム向けの資料を外向けに公開した内容です これから開発メンバーが増えてくるので、カルチャーを言語化してみた。今できている文化もあると思うし、今後の考え方を言語化したモノもある。 これをクラシル開発チームのオンボーディング資料として、継続的にアップデートしていくことにする。 これは何に使うのか・新メンバー向けのカルチャー説明 ・メンバー同士で声を掛け合ってカルチャーを浸透させていく ・採用面接やリファラル採用時の文化説明 作った背景開発部もエンジニア、デザイナーが増えて組織が大きくなってきた。常にユーザーファーストであり続けられるよう今から言語化しておく事にする。 「成長痛」とも言われるが、ベンチャー企業の組織拡大に伴い30 / 50 / 100人の壁が存在していて、組織に歪が生じやすいし、個人で成果を出すのが難しくなってくるタイミングがある。 人が増えていく過程で様々なカル
開発体制をSquad化してきてわかってきたコツと課題｜坪田 朋
今年の4月からクラシルの開発体制をSquad化したので振り返りとコツ、課題をまとめてみました。 このnoteは dely Advent Calendar #2 の9日目の記事となります。昨日の記事は、@RyogaBarbie のクラシルとRxSwiftデビューです。 クラシルのSquad体制は、Spotifyモデルを参考にSquad部分だけを取り入れたスタイルです。 Spotify Engineering Cultureについては、Henrik Kniberg氏のYouTubeが参考になると思います。この図は組織設計する上で何度も見返しました。 何故Squad化したのか 意思決定やディレクションが特定の人に集中し、ボトルネック化する規模になってきたので、課題毎にチームを分け、達成に必要なメンバーをアサインして、その領域に特化した議論を重ねられるようにしたのが狙いです。 クラシルは100人超
なぜWebサービスの選定においてSAML/SSOが重要なのか
TL;DRクラウドネイティブな時代のビジネスではWebサービス活用は必須Webサービスをセキュアに利用していくには管理やセキュリティ面での工数・コストが増えるこの工数・コストを下げることこそがWebサービス活用推進ひいてはビジネスの加速に繋がる工数・コストを下げる為に導入するWebサービスにSAML/SSOは必須ログインをSAML/SSOに限定出来ることまでがマストWebサービス利用におけるセキュリティ面で一番重要なのがID周り個々のWebサービスのセキュリティ対策よりもID管理に特化したシステムに任せた方がよっぽどセキュア（餅は餅屋）Webサービス導入時には値が張ってもSAML/SSO出来るプランで契約するSAML/SSOが出来ないことによるデメリット（工数・コスト）の方が、SAML/SSOを有効にできるプランにアップグレードする費用に勝るB2BのWebサービスを提供する企業は全プランに
エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと
こんにちは、株式会社エウレカでCTOをしている kaneshin です。 この記事は CTOA Advent Calendar 2020 の21日目の記事です。エンジニア組織におけるキャリア設計について、今までの私の経験を踏まえて考察してきたスキルの礎の部分について、いろいろな方にお話しする機会が増えたこともあり、今年の締め括りとしてエンジニア組織のキャリア戦略について一本書こうと思い、本記事を書いています。 はじめに株式会社エウレカは、恋活・婚活マッチングアプリ「Pairs」の運用とオンライン結婚相談所「Pairsエンゲージ」の展開をしています。私は2012年にエンジニアとして入社し、当時ローンチしたばかりのPairsチームへの配属となりました。（Pairsは以下「ペアーズ」と表記します） 入社当時は出会い系と同じ括りとして認識されていたペアーズですが、今ではこのようなクリエイティブを世
タイミーのEMとしてどのようにマネジメントしているか - Sionの技術ブログ
はじめに 16歳からゲーマーとしてずっとチームマネジメントをやっており、 自身の強みなので本腰入れてやりたいという思いで1月にタイミーに入社しました。 結果、今はSREマネージャー(2人) + BI基盤チームマネージャー(3人) + コーポレートエンジニア(3人)として働いてます。 そんなにメンバーはいませんがマネージャーはやれてると思ってるので、色々と書いてみたいと思います。 そんなに掛け持ちして大丈夫なの？ スタートアップは仕方ないです。ぜひ強い方募集してます。 自分の脳内の長期計画は全てアウトプットしてチームと精査してるので出来る人がやればいい状態です。 私自身マネジメントしながら、業務でコードも書いてレビューもしてるので、自身の時間を作るために自走できるチームを作り上げるためのマネジメントでもあります。 マネージャーとしてどういう動きしてるの？ - ローテーション可能のものとする
ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る｜kyuns /キュン 今村雅幸
こんにちは、ZOZOテクノロジーズで執行役員CTOをしている @kyunsです。 本記事はCTOA Advent Calendar2020の 16日目の記事となります。 この記事ではZOZOでの2年半を振り返り、テックカンパニーを目指す中でCTOとしてどのようなことに取組み、結果としてどういう変化が起きたかについて紹介したいと思います。 同じような立場のCTOやこれからエンジニアリング組織を強化していきたい方々の参考に少しでもなればと思います。 自己紹介と背景 私はヤフーに2006年に新卒で入社し、3年働いた後に当時一緒に働いていた金山と一緒にVASILYというスタートアップを創業し、受託アプリ開発や「IQON」というサービスを開発していました。 何度かの資金調達などを経て、最終的に2017年にZOZOへ売却し、ZOZOの完全子会社となりました。その後、2018年の4月には当時のスタートト
CTO不在の企業で開発組織を作っていくために大事なこと｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 これは CTOA Advent Calendar 2020 の5日目の記事です。 今までウノウとUUUMの2社のスタートアップでCTOを足掛け10年近くやってきました。経歴柄、CTOのいない企業から開発組織の作り方の相談を受けることが多いですが、やはりCTOが不在で開発組織を作っていくのは非常に困難です。とはいえ、転職市場に都合よく即戦力になりうるCTO人材が簡単に見つかるのも稀です。そこでCTOが不在の中で開発組織を作っていくために大事なことをまとめてみました。 開発組織作りで大事なのは採用ではなく環境作り開発組織作りで大事なことはいろいろありますが、最も大事なのは採用と環境の2つではないかと思います。環境が良くなければ優秀なエンジニアは採用できないし、優秀なエンジニアに来てもらえなければ良い開発環境を作ることができません。いわゆる
職能横断型スクラム体制になってからのチーム改善活動 - STORES Product Blog
こんにちは、STORES ECでフロントエンドエンジニアをしている@daitasuとバックエンドエンジニアをしている@phayacellです。 STORES ECでは、今年の5月よりエンジニア内の大きな体制変更がありました。 その変更では、フロントエンド/バックエンドで分かれていたチーム体制から、デザイナーやプロダクトマネージャーも含めた職能横断型のチーム体制へと変更になったのですが、この記事では、その際に生じた、今まで各チームで行っていた開発の進め方とのギャップや手法をマージしていく上での課題について、またそれらをどのように解決していったのかについてをお話しします。 チーム改善までの背景 組織体制の変更 元々STORES ECでは、フロントエンド/バックエンド/デザイナーは独立したチームとして動いており、PJTとしてメンバーが切り出されてはいますが、活動の主体としては職能で分かれている組
カルチャー崩壊と再構築。 Goodpatchが取り組んだ組織デザインの2年間 - 前編｜Naofumi Tsuchiya / Goodpatch
会社組織を運営していく上で企業文化の重要性は多くの経営者が理解している事かと思います。僕ももちろん起業前から企業文化が一番の差別化ポイントになると理解し、会社運営をしておりました。 創業期から毎日の朝礼、朝礼ではLTと英語でのカンバセーション、毎週月曜日のプロジェクトレビュー、オープンでフラットなコミュニケーション、グローバルコミュニケーション、チームでデザインする、デザインに対してのディスカッションなど、多くのカルチャー醸成のために多くの取り組みを行ってきました。 しかし、僕の経営するGoodpatchは約2年半ほど前に組織とこれらのカンパニーカルチャーがほぼ全て崩壊するという事態に陥りました。 この2年間は自分にとってGoodpatchの失われたカルチャーを取り戻し、再構築するために奮闘した期間でした。 組織の急成長フェーズに起こる事例だと思うので、起業家やこれから組織を作っていく人達
他チームの人とうまくやりとりするための心がけ
個人的に大切にしていることを書いていきます。少しSREの話が出てきますが、私がSREチームだから出しているだけで、基本的にSREに関係の無い分野でも使えるはずです。 前提となる心がけまず前提となる心がけについて書きます。 エンジニアは恐いと思われている人は自分と関わりの少ない人のことを恐いと思いがちです。 システムはほとんどの人にとってブラックボックスです。そしてシステムを担当しているエンジニアのことも、ほとんどの人にとって未知の存在です。関わりが少ないからこそ、ほとんどの人にとってエンジニアは恐い存在です。 ビジネスをやっていく上で、エンジニアとのやりとりは非常に重要です。そのエンジニアと他の社員のやりとりがしにくい状況だとお互いにストレスが溜まり、不健全な組織となっていきます。 これを解消する一つの手として、例えばチャンネル名が z- から始まるチャンネルは雑談していいというようなルー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEO 360°レビューを受けました
