先日 ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3] - Hatena Developer Blog という対談記事でもオンボーディングについて話したんだけど、社内では最近「3ヶ月で3連勝」を標語にしている。 オンボーディングとは 採用や異動などでチームにジョインした後に行う、早期戦力化のための施策のこと。開発環境のセットアップやチームの説明だけじゃなく、戦力になるまでのプロセス全部を指していそう。 僕らは各アカウント作成や開発環境構築はチェックボックス化してドンドン進められるようにしている *1 し、事業の説明、組織の説明、システム構成の説明をする場を設定したり、技術スタックへの入門のための実績解除システムを用意したりしてきた。 これらのドキュメントに従って作業を進め、実績を解除していくことで、作業的・技術的な道標はあるものの、オンボーディングプロセス
エンジニアリング組織の設計と実践──「メルペイ」の事例から学ぶ、組織とアーキテクトの関係性とは？ - TECH PLAY Magazine
2017年末、メルカリからメルペイが設立された。メルカリ関連のお金まわりはもちろんのこと、独立した金融会社として、決済など各種金融サービスを展開していくためだ。 そして会社設立から約1年半で、サービスをローンチ。その裏側にはどんなストーリーがあったのか。技術と経営をつなぐアドバイザーとして数多くの企業の経営支援を担う、レクターの広木大地氏をモデレーターに迎え、メルペイCTOの曾川景介氏、同じく同社VPoEの木村秀夫氏との対談から考える。 【組織設計論】プロジェクトベースからマトリックス型組織に──その結果は？ 広木：メルペイはメルカリのアプリに組み込まれる形で利用でき、お客さんから見ると単一のサービスには見えます。しかし実際には会社も違えば組織も異なります。互いの組織間で行う目標設定の調整は苦労があったのではありませんか。 ▲株式会社レクター 取締役 広木 大地氏 筑波大学大学院を卒業後、
「自分ができるタスクもうないので次のスプリントのPBIに着手します」問題をなるべくわかりやすく説明したい。良い例え話あるかな。— ama-ch (@ama_ch) August 6, 2021 を見ていて、うちのチームのデイリースクラムを紹介したくなったのでかいてみます。こういうのを書くのははじめてかもしれない。 全体デイリースクラム まず、決まった時間になったら一つの部屋に集まって、全体のデイリースクラムをする。今は3チームくらいあるので、全体でやりとりしたいことも多い。 全体のゴールとかあるわけでもないので、ただの朝会って感じ。(「朝会」でいいのかも) チャットで報告でおしまいでもいいのだが、「知らなかったー」とかはあるので、共有したい勤怠の連絡事項とか、今日はリリースがありますねーとか、この前の障害についてですがー、などなど、全体で知っておきたい情報はここで共有する。 現状、品証チー
ソフトウェア開発における人的リソースの理想的な配分
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか？ タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
「始めるのをやめて、終わらせることを始める」ことを始めた開発チームの話 / Rakus Meetup Osaka 2020-02-05
Rakus Meetup Osaka #5 の発表資料です。 https://rakus.connpass.com/event/182082/
失敗して攻め続けるために - freeeのエンジニアが障害対応で実践していること - freee Developers Hub
2015年10月入社でコアエンジンチームの@kompiroと申します。普段は下記の３つの業務に従事しています。 お客様が自社の情報を把握するためのデータアグリゲーション機能の開発 マイクロサービスに切り出したデータアグリゲーション機能をEKSに移行 チーム横断で開発者のみんなが開発しやすい環境の構築 そんな私ですが、最近しくじり開拓者のつどいという社内イベントを開催しています。これは障害対応の一環として始めたイベントです。今日はしくじり開拓者のつどいというイベントをみなさまに紹介するとともに、背景となる障害に対する考え方と障害対応の流れを解説します！ freeeの開発文化と障害対応 freeeの開発文化 こちら弊社の紹介スライドからの引用です。 freeeのエンジニアチームが大切にする開発文化が言語化されたものが 失敗して攻めよう 何でもやれる、何でもやる 必殺技 カッとしてシュッとやる
データサイエンティストはどこまでエンジニアリングをすべきか？ | CyberAgent Developers Blog
AI事業本部 Dynalystでデータサイエンティストをしている藤田です。 Dynalystの開発チーム内にはデータサイエンス（以降DS）チームがあり、そこにはデータサイエンティスト・機械学習エンジニア（以降まとめてデータサイエンティストと呼ぶ）たちが所属しています。私がこのチームで働く中で、「プロダクト所属のデータサイエンティストがどこまでエンジニアリングをすべきなのか」ということを考えることがあったのでまとめてみました。当然これは一般的な答えではなく、人・チーム・組織の現状や目指すべきところによって答えは変わるので、あくまで1チームの1個人が考えたこととして読んでもらえればと思います。 プロダクト所属と横断DS組織所属 エンジニアリング云々の話をする前に、まずプロダクト所属と横断DS組織所属のデータサイエンティストの違いについて軽く説明します。両者のメリット・デメリットについても書きた
こんど新しく勉強会を立ち上げるのだけど、2020年に新規コミュニティを立ち上げるのは、自分が今までやってきたような勉強会（Xamarin.Forms読書会とかmono meetingとか）を作ってきたようなのとはだいぶ状況が違うようだ。特に最近よく話題になるのはCommunity Code of Conduct（CCoC, CoC）に対する何かしらの意思決定を求められる、というところだろう。 今回いろいろ考えてCoCをまとめることにしたのだけど、一般的なCoCに比べてだいぶ大きな改善を施したので、それに至るまでにいろいろ検討したことを参考までにまとめておきたい。 目次 完成品 CoCの本質は何か CoCを策定することに対する批判的議論とそれらへの対応 他人の行為を「禁止」できる「コミュニティ」とは一体何者なのか? 参加者が合意していないものを強制できるのか? CoCに合意できない一部のメン
マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。開発副本部長の okady です。 サイボウズ開発本部では2019年に組織変更を実施し、当時のインタビュー記事で私はこんなことを言っていました。 「マネージャー、いないと無理なら、またつくればいい」 サイボウズの開発本部がマネジャーをなくしてみた「いないと無理なら、またつくればいい」 | サイボウズ式 そして今回の記事は、当時の私自身の言葉に応えるタイトルにしました。 「マネージャー、いないと無理だったので、またつくりました」 2019年の組織変更から3年が経ち、目的は概ね達成できました。しかし、思い通りにいかなかったことや当初想定していなかった問題もたくさんありました。そして2022年5月、開発本部の組織力をさらに強化すべく再び大きな組織変更に取り組むことを決断しました。 この記事では、2019年の組織変更とその後を振り返った上で、2022年に実施した新たな組織変更についてご
昨年の10月頃から締め切りのある大きなプロジェクトに参加し、部分的にではありますがプロジェクトマネジメントを担当しました。この記事では、その業務を通して得た見積もりに関する知見をまとめます。教科書的な知識は「アジャイルな見積もりと計画づくり」に依りますので、詳しくはそちらをご参照ください。 見積もりの基礎知識 見積もりは、提供したい機能をどれくらいの期間で実装できるかを予想し、計画について議論をするために行います。見積もりを行うことによって、全くアタリがつかない状態から、「プロジェクトのフェーズがこの辺りなので、平均で N 週間、最悪で 2N 週間くらいかかる可能性があります」などと答えられるようになります。さらに、プロジェクトのフェーズが進んで不確実性が減少すれば「平均で M 週間、最悪で M+1 週間くらいかかります」と答えを正確にできるかもしれません。まさにこれが「アジャイルな計画づ
テスト自動化の成果をどう評価し、どう次につなげるか/Test Automation Next Step
SRE （Site Reliability Engineering）の実践パターンの話をします。 わたしたちが自身の経験をもとに書いたものですが、参考資料の影響を多大に受けています。参考資料がどれも厚すぎて参考にしきれていない感はあります。 これらの実践パターンはどれかが優れているというものではなく、組織やプロダクトの状況によって選択するものだと考えています。 なお次のエントリでSREを成していく道のりの話をしています。 SRE実践への道：ボトムアップの場合 SRE実践への道：トップダウンの場合 7種類のSRE実践パターン これらは順番に発生していくものではありません。また これらの実践パターンは排他的ではなく、複数を並行実施する ことがあります。 わたしたちが知る限りSREのミッション（あるいはSREに対する期待値）は両極端で、全体を俯瞰し全体最適を図る方向性の場合と、可用性・パフォーマ
STORES.jp のフロントエンドチームがイイ感じなので紹介する - おいちゃんと呼ばれています
今年の 7月末でリブセンスを退職して、8月からはフリーランスとして STORES.jp / hey という EC のサービスを作っているスタートアップで働いている。2か月半ほど働いてみた感想として、友人にも自信をもってオススメできる企業なので紹介したい。 できるだけ中立的な立場で書く 少し話が逸れるけど、以前 OLTA という企業にカジュアル面談に行ったときに、業務委託として OLTA で働いていた @ffu_ さんが中立的な立場で同席してくれて、とても助かった（発言が信頼できた）のを覚えている。可能な限りそういうスタンスで、友人に伝えるような感じで、良いところもそうでないところも書こうと思う。 あと、できるだけ印象ではなく、こういうことがあったなどのファクトベースで書いていくつもり。 なんか、みんな、ちゃんとしてる（語彙） 僕は正社員5名、業務委託4名、計9名という規模のフロントエンドチ
自己組織的な開発チームを如何にして作り上げるか / how to build self-organizing team
Developer Summit 2020 での発表資料です https://event.shoeisha.jp/devsumi/20200213/session/2417/
こちらはEngineering Manager Advent Calendar 2023 12日目の記事です。 こんにちは、Isoparametric（Yuki Tamura）といいます。 今回はEMはCTOやVPoEの下位互換ではないということについて書きます。 私は今estieというスタートアップでEMをしております。 前職では不動産テックのCTOをしていて、その前はスマートニュースという会社でEMをしてました。 その前は、ディライトワークス、gumiという会社でCTOだったりしたこともあります。 それが何故またEMをという感じですが、入社の経緯などは、会社のブログの方にありますので興味があれば読んでみてください。 CTOを辞めて各社のCTOや最強のエンジニアが集う梁山泊estieに入社した理由 - estie inside blog では、CTO/VPoEとEMの互換性/再現性につい
Strap（ストラップ）は、デザイン会社であるグッドパッチが開発した、日本製のオンラインホワイトボードです。チーム作業やコミュニケーションを効率化し、リモート環境・オンライン会議におけるコラボレーションの可能性を広げるアプリケーションです。
This website uses cookiesThis site uses cookies to analyze traffic and performance and to save user preferences. Learn more about how we use cookies.
質問に関することで悩む若手エンジニアは多い 「ちゃんと調べてから質問した？」 「今日の進捗は？ない？ずっと同じ場所で悩んでいたの？？」 「わからないところあったらすぐ質問してね？」 「すみません。どうして欲しいのかわからないです」 他にもいろいろあると思いますが、 上記の様なことを言われているうちに質問することへの心理的障壁が上がってしまい、 質問する行為自体が悩みの種になってしまうことも多いです。 自身のキャリアのキャリア初期に「こうするとうまくいった」・「こうしておけばよかった」 また、エンジニアキャリアをスタートしたばかりの人をサポートする様になって「こうすればうまくいくんじゃない？」と アドバイスする機会もあったので、今回は質問という話題に絞って、残しておきたい。 カテゴリ分けするともっと見やすくなるかもしれないが、思いついたエピソードや事柄を羅列する形にしたいと思います。 稚拙な
2020/09/19 「XP祭り 2020」登壇資料 https://confengine.com/xp2020/schedule
こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ
スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / Management in Scrum
Scrum Fest Osaka 2020の登壇資料です。 スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / Management in Scrum https://confengine.com/scrum-fest-osaka-2020/proposal/14019
Team Topologiesを読んだ
https://teamtopologies.com/ DevOps consultantとして技術と組織の両面からDevOpsの支援を行なってるMatthew SkeltonとManuel Paisによる本．Consultant本は大体中身が薄く感じることが多くなり手に取ることは少なくなってきたが，各所で見かけたり，2人によるDevOpsにおけるチームのあり方のパターンをまとめたWhat Team Structure is Right for DevOps to Flourish?が良かったので読んでみた． 本書はDevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかについてまとめている．個人ではなくチームをDeliveryの最も重要な単位と考え（Team first-thinking），チームが最大限にパフォーマンスを発揮するために，チームの人数
2021年7月1日に「モダンアジャイル 再考 2021」というイベントが分散アジャイルチームについて考える会の主催でありました。 distributed-agile-team.connpass.com このイベントのきっかけは、私のFacebookでのつぶやき？でした。 これへのコメントできょんさん、鬼木さん、川口さんらに反応していただけ、さっそくオンラインイベントとして開催されたのでした。 以下では、イベントでいろいろな方から出た話、意見、考え方を踏まえながら、私自身の解釈や思っていることを書いてみます。最初に議論したいと思っていた内容もあれば、イベントでのやりとりから感じたこともあるし、後から思い出しつつ考えが変わってきた部分もあります。内容や文章について責任は私にあります。 モダンアジャイルとは モダンアジャイル(Modern Agile)はJoshua Kerievskyが2016
2022年からCTO交代！新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化 / developers-summit-2022
VOYAGE GROUPは事業会社として1999年から22年間さまざまな事業・サービスを生み出し、成長させてきました。2022年からはVOYAGE GROUPはCARTA HOLDINGSとして新たな挑戦を始めます。 このセッションでは、2010年から10年間CTOを勤めた小賀が2010年代のエンジニア組織と文化をふりかえり、2022年からCTOを務める鈴木が2020年以降の未来を語ります。 Developers Summit 2022 https://event.shoeisha.jp/devsumi/20220217/session/3692/
by Sagaru9535 プログラミング言語Pythonの生みの親であるグイド・ヴァンロッサム氏は、2018年7月12日に突如Python開発のBenevolent Dictator For Life(BDFL、優しい終身の独裁者)を退き、Pythonの仕様策定から離れる意向を示しました。そんなヴァンロッサム氏は2013年1月からDropboxの主任エンジニアを務めていましたが、2019年10月29日時点で既にDropboxを退社していることをDropboxの開発チームが公表。公式ブログでヴァンロッサム氏のエピソードと共に謝意が述べられています。 Thank you, Guido | Dropbox Blog https://blog.dropbox.com/topics/company/thank-you--guido ヴァンロッサム氏はアムステルダム大学で数学と計算機科学の修士号を取
こんにちは！フィードフォースで EC Booster というプロダクトを作っている @sukechannnn です。 この記事は Feedforce Advent Calendar 2020 の 11日目の記事です。 昨日は kogai さんの 趣味の本屋を始めました でした。実際に自分でECサイトを立ち上げて運営するのって、言うは易く行うは難しですよね。すごいです。 さて、内容に入っていきます。 EC Booster チームではメイン開発をモブプログラミングで行っています！ EC Booster はEC事業者様の集客を支援するサービスで、主に Google ショッピング広告を扱っています。また、今年１１月にフリープランをリリースし、より多くのEC担当者様をご支援できるよう機能開発を進めています。 アプリケーションの構成は、フロントエンドが React + Flow (TypeScript
基礎からわかる内製化
みなさんこんにちは。@ryuzeeです。 2022年7月6-7日のGoogle Cloud 内製化 Dayの1日目で光栄にも特別講演をさせていただきました。 資料については、イベントページにすでに掲載されていますのでご案内します（このページにアクセスして、「公開資料」の下にある「特別講演」をクリックしてください）。 なぜ内製か？ 今の世の中はソフトウェアが企業の競争力の源泉になっていますが、そこで必要なのは、「素早く」「頻繁に」「安定的に」価値を届けること、つまり安定した「価値のフロー」の実現です。 ソフトウェアの構築は知的労働であり、実際の作り手はチームです（マネージャーや管理者、経営者ではありません）。 したがって、企業としては、安定した「価値のフロー」を実現できるチームを手にいれる必要があります。 安定したフローを実現するためには、専任が必要です。複数のプロダクトやプロジェクトを同時
はじめに チームのメンバー皆に意見を出してもらいたいような会議をすることはよくあると思います。 本稿は、そういう時に積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。 チームの皆に意見を出してもらいたい会議とは いろいろあると思いますが、以下に2つの例を挙げます。 UXレビュー 私のチームでは、開発中のプロダクトに対する改善点を皆で挙げるという活動を行っています。 チーム内では「UXレビュー」と呼んでいます。 具体的には、開発メンバーが開発中のプロダクトを実際にユーザーがよく使うユースケースでどんな体験をするのかをデモしながら説明し、それに対して他メンバーが気付いた改善点を挙げるという活動です。 人によって感じ方が異なるため、複数人で実施して、各自が感じたことを積極的に意見してもらった方が多様な観点での改善が期待できます。 設計レビュー 複数人で開発するプロダクトに対
「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編もエンジニア教育も一つ一つ丁寧に積み上げてモダナイズを進めた話｜CTOロングインタビュー - MonotaRO Tech Blog
独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
ITエンジニアの課題解決能力を社会にインストールするために、2020年2月に発足したコミュニティ、ハッカーライフラボ。 第4回目のオンラインイベントは、2019年10月に刊行された『ソフトウェア・ファースト』の著者である及川卓也氏が「ソフトウェア・ファースト」の考え方、日本企業の課題などについて紹介します。後半は、質問を通して現状及川氏が考えていることに迫ります。 リモートワークにはすごく否定的だった 岩切晃子氏（以下、岩切）：ありがとうございました。みなさん、Zoom越しではありますが、拍手をお願いします！ 及川さん、この分厚いものをギュギュギュと20分にまとめる力はすごいですね（笑）。ありがとうございました。 それでさっそくなんですけれども質問があったので、及川さんにぜひ答えていただきたいです。「書籍を読ませていただきました。4章で開発組織について書かれていますが、現在のウィズコロナ、
株式会社アンドパッドのアカウント基盤チームで認証基盤に関するエンジニアリングをしているid:shiba_yu36です。最近はチームのテックリードロールも担っています。 現在アンドパッドではFindy Teamsを導入し*1、生産性の可視化を行っています。自分は生産性向上のためのチーム改善に興味が強いため、2021/10に入社してからアカウント基盤チームのFindy Teams指標を観察し、チームのボトルネックを見極め、チームの生産性改善をしてきました。結果として、Findy Teamsの平均プルリク クローズ時間の指標が、チームに入った2021/10当時は120時間だったのが、現在は23時間ほどまで改善しました。今回はその様子について書きたいと思います。チーム改善の流れの一例として、参考にしてもらえればと思います。 チーム改善の全体的な流れ Findy Teamsで定量的にチームの生産性を
ミラティブサーバチームで行っている障害振り返りを紹介します！！ - Mirrativ Tech Blog
こんにちは、サーバエンジニアの夏（なつ）です。今回はミラティブのサーバチームで行っている障害振り返りを紹介したいと思います。 ミラティブのサーバチームではサービスに障害が発生した場合、その後、担当者を決めて障害の振り返りのたたき台を作成し、チーム内で振り返りを行って、今後の改善に活かす努力を続けています。 今回はその振り返りの目的やフォーマット・注意点についてお話したいと思います。 目的 システムを運用していれば障害はつきものです。ましてや改善を続けるならば、その代償として不確実性が障害として表面化し、放置していけば徐々にユーザの信頼を失っていくことになります。かといって、障害の防止にコストをかければかけるほど、費用対効果は見合わなくなり、障害を絶対に起こしてはならないという心理的圧力はメンバーのメンタルを擦り減らしていきます。そのため障害の振り返りでは障害の詳細や原因をチームメンバーと共
Engineering Managerをやっていた間の振り返りとまとめ - masartz->log(type=>'hatenablog')
TL;DR; Engineering Managerを降りることになりましたので、振り返りとまとめです。 ※会社は辞めませんので、退職エントリではございません（別チームへの異動です） 時系列 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い 2018/04: SREのEngineering Managerに登用される 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた 2018/10: 2チーム兼任からMicroser
Penpot is the web-based open-source design tool that bridges the gap between designers and developers.
AWSにおけるアプリチームとインフラチームのコワーク設計 / Co-working Design about App and Infra on AWS
AWSにおけるアプリチームとインフラチームのコワーク設計 / Co-working Design about App and Infra on AWS
はじめに こんにちは。モノタロウで開発を担当している渡邉です。半年前に初めて開発チームのチームリーダーになり、スクラムを使った開発を行ってきました。今回はこれらの取り組みを振り返ってみようとおもいます。 はじめてのリーダー業って不安ですよね。どう行動すればよいのか、何を変えるべきなのか、うまくチームの目標を達成できるかなどなど・・・。私自身、そのような不安をかかえてチームリーダーになりました。 しかし、開発プロセスとしてスクラムを取り入れたことにより、想像していたよりスムーズにチーム運営を進めることができました。これから初めてリーダー職につく方や、スクラムをこれから取り入れてみようかなと思っている方の参考になれば嬉しいです。 アサインは突然に・・・ ある日のグループ連絡会で、当時のリーダーから突然の連絡がありました。 これまでのリーダーは経験豊富で、技術面でも行動面でもチームを率先してまと
※クラシル開発チーム向けの資料を外向けに公開した内容です これから開発メンバーが増えてくるので、カルチャーを言語化してみた。今できている文化もあると思うし、今後の考え方を言語化したモノもある。 これをクラシル開発チームのオンボーディング資料として、継続的にアップデートしていくことにする。 これは何に使うのか・新メンバー向けのカルチャー説明 ・メンバー同士で声を掛け合ってカルチャーを浸透させていく ・採用面接やリファラル採用時の文化説明 作った背景開発部もエンジニア、デザイナーが増えて組織が大きくなってきた。常にユーザーファーストであり続けられるよう今から言語化しておく事にする。 「成長痛」とも言われるが、ベンチャー企業の組織拡大に伴い30 / 50 / 100人の壁が存在していて、組織に歪が生じやすいし、個人で成果を出すのが難しくなってくるタイミングがある。 人が増えていく過程で様々なカル
スキ・キライ・得意・苦手を可視化したら、互いに成長を支え合うデザインチームができた話｜宇野雄 / note inc. CDO
クックパッド VP of Design／デザイン戦略本部長の宇野です。 みなさんは苦手なスキル、得意なスキルをどのように把握し成長につなげていますか？今日はそんなお題に向き合ったクックパッドでの取り組みをご紹介します。 僕が今年2月に入社したとき自身の自己紹介資料に入れた簡単なチャートがあります。それがコレ。 スキルマップって基本的には「得意」を可視化するためにあります。でも「得意」だから好きとは限らない。「苦手」だけど好きだってある。 それを可視化するために「得意／苦手」「スキ／キライ」の2軸で表したものです。 こうするとざっくりこの4分類にわかれます。 ・得意 × スキ ・得意 × キライ ・苦手 × スキ ・苦手 × キライ このチャートには絶対値が存在しないし、第三者評価もない。あくまで「自分では自分のことをこう考えていてこうしていきたい」という意思表示です。まさしく「私はこういう
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
うちのチームのデイリースクラム 2021年夏編 - 半空洞男女関係
さいきょうのCode of Conductを求めて - ものがたり
見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察 - yigarashiのブログ
テスト自動化の成功を支えるチームと仕組み/TestAutomation
SRE実践の形：7種類の SRE 実践パターン - 株式会社X-Tech5
チームの機能不全を起こす4つの “毒”を発生させないための感情の保ち方、心理的安全性を確保したチーム作りのために考えるべきこと【CEDEC2021】 | GameBusiness.jp
CTOやVPoEと違いEMには再現性がある - 神様なんて信じない僕らのために
Strap（ストラップ） | 日本製オンラインホワイトボード
Gather | Virtual HQ for Remote Teams
良い質問をして自己成長に繋げるためのあれこれ - Qiita
"群れる" アジャイル / Swarming in Agile
技術選定とアーキテクトの育成について - NRIネットコムBlog
モダンアジャイルについて - やっとむでぽん
プログラミング言語Pythonの生みの親がDropboxを退社、Dropboxが語る一流プログラマーの姿とは？
半年モブプロしたらチームが大きく成長した話 - Feedforce Developer Blog
会議中に発言してもらえない原因は、マネージャーの私にあった - Qiita
リモートワークにはすごく否定的だった 及川卓也氏が語る「ソフトウェア・ファースト」と世界の変化
Findy Teamsの指標を使ってチームの生産性を改善しよう - ANDPAD Tech Blog
Penpot: The Design Tool for Design & Code Collaboration
アサインは突然に -チームリーダーになって気づいたこと- - MonotaRO Tech Blog
ユーザーファーストであり続けるために開発チームオンボーディング資料を作ってみた｜坪田 朋
kakuyomu.jp
kakuyomu.jp
mangafree.xyz
retty.me
arabic.kharuuf.net
www.sponichi.co.jp