チームトポロジーを読んだ感想
はじめに 最近、チームってどんな構成にするのがいいんだろうか？と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか？ チーム間のコミュニケーション（インタラクション）をどう設計するか？ 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか？ チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、１つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
無料で使える 高機能なwikiツール マニュアルや企画書の共有、議事録の同時編集など、 チーム内での快適な情報共有と作業効率化を支えるツールです。 GROWIを始める
2019年7月6日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「インフラだってスクラムがしたい！」に登壇したのは、株式会社マネーフォワード・栗田茉緒氏。登壇資料はこちら インフラエンジニアがスクラムに挑む 栗田茉緒 氏：株式会社マネーフォワード、サービス基盤本部の栗田と申します。「インフラだってスクラムがしたい！」というタイトルで発表をさせていただきます。後ほどスライドを公開するので、そちらも合わせてご覧ください。 まず始めに、マネーフォワードは「MoneyForwordクラウド」や「MoneyForword ME」など
こんにちは、計測プラットフォーム開発本部システム部SREブロックの市橋です。2021年4月に新たに発足したチームで未経験ながらリーダーを任され、気づけば約2年が経過していました。これまでを振り返ってみると、まっさらな状態から安定したチームができてきたと感じています。今回は新米リーダーとして試行錯誤する中で、チーム状態を可視化して健全なチーム運営を目指した話を紹介します。 チーム状態の可視化を考えたきっかけ リーダーを任された当初、チーム運営上の課題が色々あるのは認識していましたが、どこから手をつけるべきかが自分の中で判然としませんでした。メンバーの時に一個人として感じていた課題も、チーム全体を俯瞰して見た時にどれから優先的に取り組むべきか自信を持って判断できませんでした。まるで大海原のど真ん中にいきなり放り出された感覚でした。 そんな悩みを抱えていた時、全社に導入されているWevoxのアン
はじめに 本日7月7日はクラスメソッド株式会社の創業記念日です。クラスメソッドは16期目を迎えました。つまり15周年ですね。ばんざーい。 さて、最近すっかりテクニカルなブログを書く機会が減ってしまった僕ですが、創業記念日の今日も、マネジメントについてポエムりたいと思います。なお、マネージメント論やマネージャー論は人によって大きく想いや解釈が違うものであり、その組織の状況やフェーズや文化によってそれぞれ違います。以下のブログはあくまで僕個人の価値観であることをご理解ください。 マネージャーは不要なのか？ という話題をよく見かけるようになりましたが、まずそもそもエンジニア組織のマネージャーって何やってるの？というところを細分化したいと思います。 エンジニア組織のマネージャーをロールに分けるのであれば、大きく以下の4つになると僕は考えます。 組織マネージャー 技術マネージャー ビジネスマネージャ
ゲームディレクターとして動いていると、企画やできたもののフィードバックをよくする。そうすると必要なのは、UX（ユーザー体験）を言語化して説明をして納得をしてもらうことだ。一緒にやっているプランナーから、UXの分解・言語化をどうやっているのか？という質問が来たので、書いてみる。 ゲームディレクターは、なぜUXの分解・言語化が必要なのだろうか？ これは簡単で、自分が感じていることを言語化できないとチームメンバーに伝えることができず、納得感を持って作ってもらうことができないためだ。「なんとなくダメ」とか、「理由は説明できないけどこうして」という指示は、繰り返せば繰り返すほどやらされる方はしんどくなっていく。当たろうが外れようが、何をやっているのかよくわからなくなってくる。主観ではなく、客観で伝えることができないと、チームは納得がしにくい。なので、ゲームディレクターにはUXの言語化能力がとても必要
プロダクトを長期運用するには、必要な知識やスキルをいかにチーム内でとどめておくかという視点が必要になります。本稿では、はてなの「Mackerel」というプロダクトで培った経験をもとに、「スキルマップ」と「ソフトウェア式年遷宮」という2つのアプローチを紹介します。（編集部） プロダクトチームにおけるスキル維持の難しさ プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。 これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが
サンフランシスコのモバイルゲーム会社に入って驚いたこと -リリースまで- - GAME NEVER SLEEPS
前回の日常編に続き、サンフランシスコにあるモバイルゲーム開発スタジオの業務編（2014-18）です。もう退社から2年も経つので、ずいぶん変わったことも多いと思いますがまあ記録として。どんな感じで働いているのかも知ってもらうと業務も伝わりやすくなる気がしますので、こちらで興味を持っていただければ日常編もぜひ。あくまでも僕がいたのはサンフランシスコにあった一スタジオで、それほど外注や他スタジオとのコラボもなかったので、どれくらい一般的なのかはぜんぜん知りませんのでご注意ください。 gameneversleeps.hateblo.jp 業務全般で驚いたこと 僕の職種はゲームデザイナーで、日本でいう企画職にあたります。売り切りのコンソールゲーム開発では納期までに面白いものをなるべく高いクオリティで作ることが正義なスタイルでしたが、ゲームが基本無料の運営型になると、ゲームデザインのゴールは「最高の1
前書き🤔これは何RIZさんという一見AIイラストレーターを装った風来のシレン廃人にそそのかされて作ったちちぷいチャレンジが多数の愉快犯たちにおもちゃにされた結果書かないといけなくなった記事です。 Stable DiffusionやMidjourney、Nijijourney、NovelAIの使い方を詳しく解説した文書は数あれど、ふだんパソコンを使わない一般の人向けまで踏み込んで網羅している解説記事って案外ないかもな？と思ったのもきっかけではある！ 書く前からわかってたんだけどボリュームがヤバいので稚拙な表現や抜け漏れ多数だ。公開後もちょくちょく手を加える可能性大だから、もし更新が気になるようであれば筆者のX, Blueskyアカウントをフォローするなり、気が向いた時にこのnoteに戻ってきてくれよな！！ しばらく前提条件を書いておくので、とっとと中身を読みたい人は飛ばしちゃってください。
新刊『チームトポロジー』発売のお知らせ
みなさんこんにちは。@ryuzeeです。 言いたいことはタイトルに書いたとおりなのですが、2021年12月1日に、新刊『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が発売になります。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632 原著はMatthew Skelton、Manuel Pais氏の『Team Topologies: Organizing Business and Technology Teams for Fast Flow』で、翻訳は株式会社アトラクタのアジャイルコーチ（いつ
2019年9月19日に開催された React.js meetup #9 の登壇資料です。 📝 note のフォローアップ記事にトーク内容をまとめています。 https://note.mu/featherplain/n/n4aa45eb267b6 デザインシステムを持たないキッチハイクが、プロダクト開発においてどのような取り組みをしてきたのかをテーマにお話しました。これまでの取り組みを踏まえて、デザインシステム検討のタイミングも考えてみます。
先日 ヘンリーで活躍中の 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
プロダクト主導型組織に向けて 〜「プロダクト・レッド・オーガニゼーション」概要〜 / Product-led Organization
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/
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.
こちらは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の互換性/再現性につい
質問に関することで悩む若手エンジニアは多い 「ちゃんと調べてから質問した？」 「今日の進捗は？ない？ずっと同じ場所で悩んでいたの？？」 「わからないところあったらすぐ質問してね？」 「すみません。どうして欲しいのかわからないです」 他にもいろいろあると思いますが、 上記の様なことを言われているうちに質問することへの心理的障壁が上がってしまい、 質問する行為自体が悩みの種になってしまうことも多いです。 自身のキャリアのキャリア初期に「こうするとうまくいった」・「こうしておけばよかった」 また、エンジニアキャリアをスタートしたばかりの人をサポートする様になって「こうすればうまくいくんじゃない？」と アドバイスする機会もあったので、今回は質問という話題に絞って、残しておきたい。 カテゴリ分けするともっと見やすくなるかもしれないが、思いついたエピソードや事柄を羅列する形にしたいと思います。 稚拙な
2020/09/19 「XP祭り 2020」登壇資料 https://confengine.com/xp2020/schedule
こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ
2021年7月1日に「モダンアジャイル 再考 2021」というイベントが分散アジャイルチームについて考える会の主催でありました。 distributed-agile-team.connpass.com このイベントのきっかけは、私のFacebookでのつぶやき？でした。 これへのコメントできょんさん、鬼木さん、川口さんらに反応していただけ、さっそくオンラインイベントとして開催されたのでした。 以下では、イベントでいろいろな方から出た話、意見、考え方を踏まえながら、私自身の解釈や思っていることを書いてみます。最初に議論したいと思っていた内容もあれば、イベントでのやりとりから感じたこともあるし、後から思い出しつつ考えが変わってきた部分もあります。内容や文章について責任は私にあります。 モダンアジャイルとは モダンアジャイル(Modern Agile)はJoshua Kerievskyが2016
スクラム開発におけるマネジメント、目標設定・フィードバック・評価 / 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），チームが最大限にパフォーマンスを発揮するために，チームの人数
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/
大規模にアジャイルをやるにはどうしたらいいですか？ 答え 大規模にしない 以上終わり。 先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね？って聞かれて出た感想が、「大規模にしない」だった。 ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う そんなチームのプロセスを同期や依存させる意味あるのかと。 「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね！」 って言われたらどう考えても頭おかしい人でしょ。 依存がいらないところをわざわざ依存させない。 偉い人が同じ？組織上同じだから？ 依存を増やしてどうやって変化に対応するのか？ 変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか？ そんなことを感じないでもない。 アジャイル界隈で悪名高い？Scaled Agile F
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
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OSS開発wikiツールのGROWI | 快適な情報共有を、全ての人へ
インフラエンジニアがスクラムをやって学んだこと
スクラムを導入してチーム状態を可視化し持続可能なチームを目指す - ZOZO TECH BLOG
創業記念日なのでエンジニア組織のマネージャーについて考えてみた | DevelopersIO
なぜディレクターはUXを分解・言語化しなくてはいけないのか？クソゲーが生まれてしまう原因｜かえるD
プロダクトに必要なスキルを10年維持するために――「スキルマップ」と「ソフトウェア式年遷宮」
AIイラスト始め方の網羅的案内 2024年版 / だいたい未経験者向け｜かいりん
デザインシステムを持たない組織のこれまでの取り組みと今後を考える
オンボーディングは3ヶ月で3連勝を目指す - id:onk のはてなブログ
うちのチームのデイリースクラム 2021年夏編 - 半空洞男女関係
さいきょうのCode of Conductを求めて - ものがたり
見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察 - yigarashiのブログ
テスト自動化の成功を支えるチームと仕組み/TestAutomation
「嫌われない」を諦めない / Never give up avoiding to be hated
SRE実践の形：7種類の SRE 実践パターン - 株式会社X-Tech5
チームの機能不全を起こす4つの “毒”を発生させないための感情の保ち方、心理的安全性を確保したチーム作りのために考えるべきこと【CEDEC2021】 | GameBusiness.jp
Strap（ストラップ） | 日本製オンラインホワイトボード
Gather | Virtual HQ for Remote Teams
CTOやVPoEと違いEMには再現性がある - 神様なんて信じない僕らのために
良い質問をして自己成長に繋げるためのあれこれ - Qiita
"群れる" アジャイル / Swarming in Agile
技術選定とアーキテクトの育成について - NRIネットコムBlog
モダンアジャイルについて - やっとむでぽん
大規模にアジャイルをやるにはどうしたらいいか、に対する答え - 海と山が好き
プログラミング言語Pythonの生みの親がDropboxを退社、Dropboxが語る一流プログラマーの姿とは？
半年モブプロしたらチームが大きく成長した話 - Feedforce Developer Blog