分業は悪だがやめると食えなくなる問題 - しゅみは人間の分析です
engineer-lab.findy-code.io こんな記事があって、「分業化するWeb開発の違和感」といういい言葉がでてきた。その通り、この世の不気味さ、不安さはぜんぶ分業のせいである。私は本気でそう思っている。 分業はいいことだ。全体の効率があがる。特に個人が食糧生産から解放されたことは大きい。ほんの少しの人たちが食糧を作ってくれるおかげで他の人たちは別の仕事ができる。こんなすばらしいことはない。今や都市生活者は全世界人口の半数を超える。分業のおかげで職業を選び都市で暮らすという選択ができるのだ。 分業はわるいことだ。個人の経験が分断され、コミュニケーションが成立しなくなる。隣の島で働いている人たちが何をしているのかわからない。同じ社内でも職種が違うと話が通じないことがある。前提がどこから違うのかわからない。こんなにもわからないのに、なぜか会社は利益をあげて決算報告書を提出している
TwitterをSpaceXやTeslaと同じようにはエンジニアリングできないのでは - きしだのHatena
Twitterを買収したイーロン・マスクが週80時間勤務に備えろといって、それができないなら退職という話をした結果、エンジニアを含め社員の多くが辞めたという話がでてます。 https://jp.reuters.com/article/twitter-departures-idJPKBN2S806D イーロン・マスクとしては、Teslaのようにハードに働く少数精鋭のチームを作りたいようです。 9.3/ 優秀な小規模チームを作るのが大事だと行っていて、TeslaのAutopilot AIチームにいる150人のエンジニアは競合の3,000人のエンジニアチームに勝っているとイーロンは語る— Tetsuro Miyatake (@tmiyatake1) 2022年11月11日 ただ、TeslaやSpaceXは製造業で、たとえばSpaceXならロケットを安く確実に作るというように、作るものは基本的に決
開発組織の生産性を可視化するState of DevOpsとFour Keysとは(増補改訂版) / Introduction to State of DevOps and Four Keys for Visualizing Productivity in Development Organizations expanded and revised edition
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。 その際にこのようなことを言われがちではないでしょうか？ 今動いているものを直す必要ある？ 効果測定どうやんの？ 費用対効果はどれくらい？ パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。 本セッションの目標 以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。 State of DevOpsとは Four K
日本のソフトウェア企業でよく見るエンジニア組織の構造と、近年推奨されるエンジニア組織の構造について
はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
意識的に職位を下げる - id:onk のはてなブログ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
個の最大化とチームの最大化を目指すために考えるべきこと｜奥野賢太郎 / Crescware Inc.
こんにちは、クレスウェアの奥野賢太郎です。今回は私の職業でもあるSaaS開発者という視点から、コードレビューに対する日頃の考えをまとめます。技術系の内容はQiitaに書くことが多いですが、今回はどちらかというと思想・哲学や日々の振る舞いに近いテーマとなるので、非技術系の方にも広く読んでいただきたく、noteでの掲載としました。 この記事でお伝えしたいこと・コードレビューの本質はコードのレビューではない ・チームの健康維持を目的に個のパフォーマンス、チームのパフォーマンス両方の最大化を目指す ・理想と現実を見つめるフェーズは異なる、2つの視座を持つSaaSとはこのnoteのフォロワーには技術系だけでない方もおられるので、簡単にSaaSについて説明します。 SaaS（サース）はSoftware as a Serviceの略で、ざっくりと表現するならばブラウザ上で動作するアプリのことと思ってもら
横断型テックリードという働き方 - 文字っぽいの。
みなさんこんにちは。FromAtomです。 自分は今『モバイルアプリ分野テックリード』という肩書で仕事をしています。世の中のテックリードの皆様におかれましては「"分野" テックリードって？」「横断型テックリードって？」という感じかと思います。そんなテックリード業を2019年末から2年ちょっとやってきたので、この記事では自分がやっていることの説明と、分野テックリードが置かれた経緯を紹介します。 なぜモバイルアプリ分野テックリードが必要になったのか 弊社では、全部で12つのiOS・Androidアプリを開発しています。これだけあると、各アプリのプロダクトオーナー毎に意思決定の精度にばらつきが出てきます。例えば、Appleのレビューリジェクトに対する姿勢が異なると「まぁ適当にごまかして通せば勝ちや！」というチームと「BANリスクもあるからちゃんとやるか。面倒だけど。」というチームが生まれる可能性
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
そのコードレビュー、使い捨てになっていませんか？
こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの
成功したスタートアップの初期のメンバー数は、バスケットチームより多いか少ないか？
田所雅之（たどころ・まさゆき） 株式会社ユニコーンファーム代表取締役CEO 1978年生まれ。大学を卒業後、外資系のコンサルティングファームに入社し、経営戦略コンサルティングなどに従事。独立後は、日本で企業向け研修会社と経営コンサルティング会社、エドテック(教育技術)のスタートアップなど3社、米国でECプラットフォームのスタートアップを起業し、シリコンバレーで活動。帰国後、米国シリコンバレーのベンチャーキャピタルのベンチャーパートナーを務めた。 また、欧州最大級のスタートアップイベントのアジア版、Pioneers Asiaなどで、スライド資料やプレゼンなどを基に世界各地のスタートアップの評価を行う。これまで日本とシリコンバレーのスタートアップ数十社の戦略アドバイザーやボードメンバーを務めてきた。2017年スタートアップ支援会社ユニコーンファームを設立、代表取締役CEOに就任。2017年、そ
デザイナーとエンジニアを巻き込んだワークフローの改善｜鈴木慎吾 / TSUMIKI INC.
「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」20日目の記事です。 今年の５月から、社内でクライアントワークのチームから自社事業のチームに異動し、映画・ドラマ・アニメのレビューサービスのFilmarksで有料会員機能のPMを担当しています。 以前はUIデザインやアプリ開発、あるいはその中間的な仕事としてプロトタイプ開発やディレクションなどを経験してきました。 PM業の傍ら、社内のデザイナーとエンジニアの受け渡し部分の改善に取り組みました。その検討過程について紹介します。 要件定義・UIデザイン・開発間のワークフロー改善もともとFilmarks内ではディレクターがGoogleスライドなどで要件資料とGithub Issueをつくり、 デザイナーがSketchでUIをつくりZeplinで書き出したURLをエンジニアに受け渡し、エンジニ
リモートワークのための質問力向上研修を実施しました - Classi開発者ブログ
この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに
Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs
https://jsconf.jp/2021/
Figma Flow
01. What is Figma Flow?Figma Flow is a collaboration model for Figma, created by Flow Platform Team. Heavily inspired by BDD and state machines, well suited to collaboration and scaling the product development process. It takes best practices from software development to the designers and product management world. 02. Key BenefitsGuided processFigma Flow is the way of working with your whole produ
「技術的負債」への処方箋と「２つのDX」 - Qiita
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
なぜ組織の透明性が大切なのか - 30歳からのプログラミング
個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし
問題はどこにもない - 余白
QuestionではなくProblemとしての「問題」についてのlacolacoの考え方 「事実として問題であること」はどこにも存在しない まず、「事実」なるものの存在を否定する まさしく事実なるものはなく、あるのはただ解釈のみ (ニーチェ『権力への意志』) 当然、「事実として問題であること」もない 「まさしく問題なるものはなく、あるのはただ嫌悪のみ 」 「これは問題だ」と感じるとき ここで疑いようのない確かなことは、 「私」に「これは問題だ」と感じさせる「何か」がある ということ 問題感・課題感 恐れ、憂い、抵抗、総じて不快なものに対する嫌悪の反応である 問題とは、 「何か」に対する「私」の捉え方 の名称である 「問題視する」とは言い得て妙 「問題として見ている」のは「私」自身 問題の解明 スタート地点は: 「私」に「これは問題だ」と感じさせる「何か」がある その「何か」が備える何らかの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
事業をスケールさせるエンジニアリング〜技術のコモディティ化にエンジニアは敗北する〜 - DMM inside
レビューの仕方
