新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
GitHub Projects を利用したタスク管理 - 一休.com Developers Blog
宿泊開発チームでエンジニアをしている @itinao です。 昨年の10月に入社しました。 今回は GitHub Projects を利用したタスク管理について記載します。 なんとなーく GitHub Projects 使うと、KANBANにしてみたり リストにして使ってみたり で終わってしまいます。 もっと色々できるんだよってことが伝えられればと思います。 背景 どんな機能があるか Custom Fields Views Group by Slice by Workflows ISSUEと Pull requestの紐づけ Insights タスクの進め方 タスクの洗い出し 見積もり 現状の課題と今後の展望 まとめ さいごに 背景 一休ではチームごとにタスクの管理方法が違い、 Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法
ふりかえり手法にはKPT、Fun Done Learnなど様々な手法が知られています。 今回はその中でもチームの課題と向き合う手法「象、死んだ魚、嘔吐」について説明します。 また自分達が実際に実践するにあたって行った工夫を紹介します。 ふりかえり手法「象、死んだ魚、嘔吐」とは？ 2024.1.17追記 「象死んだ魚嘔吐のうた」を制作し、Reginal Scrum Gathering Tokyo 2024にて発表しました。 ↑使用したオリジナルの背景画像です。お好きなツールの背景としてどうぞ。 「象、死んだ魚、嘔吐」とは、Airbnbの共同創業者ジョー・ゲビアが提唱した手法です。 カリスマ性があり完璧主義のジョー・ゲビアが率いるチームでは、雰囲気が重苦しく、メンバーはゲビアを恐れ、自分の考えていることを発言できなくなっており、チームは崩壊寸前でした。 そのような状態で考案されたふりかえり手法
質の低い決定しかできない上司や社長に「どうしますか」と決定を丸投げするのは悪手だよ(パート2) - フジイユウジ::ドットネット
以前、質の高い打ち手を選択できる人が判断をせず、質の低い決定しかできないような上司や社長に「どうしますか」と委ねるのはチームがダメになる要因なんよという記事を書いたのですが、今日はその逆で課題解決に必要な能力と情報を持っている人が判断をしなくても上手くいったことについて雑に語ります。 先日、会議に参加してたんですよ。 その会議では、ある課題をどう解決するか話し合って打ち手を決定するというものだったのですが、参加者のひとりが僕より明らかに専門性を持っているプロフェッショナルだったのですね。 なので僕は「どうするかは専門性のある人に決めてもらった方が質の高い意思決定になるし、僕は相手がそれをしやすいよう情報を渡すような役割に徹しよう」と考えていました。 しかし、実際の会議を進めてみると、一番質の高い打ち手を決められる能力があるはずの人が「フジイさんどうするか決めて欲しいです。」と言ってくるので
ヘルプデスク業務を楽にするためにSlackとGitHub Projectを同期するヘルプデスクツールを自作した - MNTSQ Techブログ
こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 ( Twitterもやっている のでフォローしてもらえると嬉しいです！ ) 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と整備してい
開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity
2024/2/15 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと
「なんちゃってスクラム」に気づくためのコツ
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち
長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog
弁護士ドットコム クラウドサイン事業本部でエンジニアをしている山田です。 主にフロントエンドを担当しています。 普段の業務でフロントエンド開発のコードレビューをすることが多く、今回は長い時間がかかりがちだったコードレビューを以下の施策で改善した話をします。 タスクへの認識合わせを拡充 タスクを小さく分割 類似するタスクのレビュー内容は共有 必要に応じて同期的にレビュー 達成されないスプリントゴール スプリントゴールが達成できない原因 コードレビューが長くなる要因 レビュアーのレビュー期間が長い タスク担当による対応期間が長い 対応策 タスクについての認識合わせの時間を設ける タスクをなるべく小さくする 類似する複数のタスクはレビュー内容を共有 必要に応じてオンラインミーティングなどで画面共有し会話しながら同期的にレビューする スプリントゴールも達成できるように まとめ 達成されないスプリン
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏（以下、西村）：最初にやったことに価値がありました。そして、次は第2段。 原トリ氏（以下、原）：この説明会やった時に、6月は一回止めますと（話しました）。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村：これ、カミナシの歴史で初めてですね。 原：たぶん、初めてだと思います。 西村：そこは「大丈夫なのかな？」とかなかったんですか？ 原：「この1年大きい機能、出てないよね？」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村：なるほど。なにか技術的にうまくいっていないというのがあった。 原：そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
こんにちは。カケハシでソフトウェアエンジニアをしている椎葉（@bufferings）です。私の所属するチームでは先日「質とスピード」についてのふりかえりを実施しました。この記事では、チームが「質とスピード」をふりかえってどのようなことを話し合い、何を決めたのかご紹介します。 この記事は カケハシ Part 1 Advent Calendar 2023 10日目の記事です。今年のカケハシのアドベントカレンダーにはPart 1とPart 2があるので、両方とも楽しんでいただけると嬉しいです。 カケハシ Part 1 Advent Calendar 2023 カケハシ Part 2 Advent Calendar 2023 「質とスピード」の社内講演会 カケハシでは、9月に和田卓人さん（@t_wada）をお招きして「質とスピード」の社内講演会を開催しました。 講演中には社内のSlackで「わかる
Prettierを使わない理由
この記事はPrettierを使用している人を非難したり、脱Prettierを推奨する事を目的としていません。 こういった考え方もあるということをひとつの意見としてご覧いただければ幸いです。 勘違いしている人が多そうなので追記します。 Prettierを使わないというのは私が独断で決めた事ではないです。 チームが発足する際の技術選定で合意は取れていますし、私が関与していない別のチームでも同様にPrettier無しで開発しています。 私達のチームはメンバー同士を互いに信頼していますし、細いスタイルで喧嘩を始めるようなメンバーは居ないので安心してください。 はじめに Prettierはコードフォーマッターとして広く使われているツールです。 コードスタイルに関する議論をなくすことを目的としており、ESLintとは異なりデフォルト設定のままですぐに使えるのが特徴です。 さらに、PrettierはJS
こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。 「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」 「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」 ... などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。 結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？ 本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。 プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。 1. チーム構成と特性 2. 特性が生み出しうるリ
こんにちは、ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、転職サービス Findy の開発チームにおける開発生産性の向上に対する取り組みをご紹介します。 以前の状況 モノリスの解体 開発基盤の刷新 コンポーネント設計の刷新 テストの拡充 CI の高速化 改善の効果 まとめ 以前の状況 2020年頃の Findy は Ruby on Rails と React のモノリス構成で作られていました。 機能の増加に従いコードが複雑化し、しだいに開発スピードが伸び悩むようになりました。 ここで Findy Team+ で算出した当時のリードタイムを見てみましょう。 2020年のFindyのリードタイム 上記のグラフから次のことがわかります。 改修が本番に適用されるまで 約1週間 かかる プルリクエストがレビューされるまで 約5日 放置される
こんにちは、プロダクトマネージャーの髙田です。辛いものが好きです。 最近は、昼ごはんに台湾ラーメンを食べて、夜に二郎インスパイアで台湾まぜそば（辛口）を食べました。 麺半分コール忘れて胃が爆発 入社からいつのまにか1年経過し、振り返りも込めてエムスリーで働く人を「観察」して学んだことを書こうと思います。 私は入社後半年ほど、インプット8：アウトプット2の時間の使い方をしていて、特に最初の3ヶ月は「エムスリーの型・勝ちパターン」のインプットを重点的に行っていました。 具体的には、 コミュニケーション・行動・思考法などをMTGやSlack等から観察し 学んだことを週1で取締役CTOの山崎さんに報告 会話を通してさらに学びを深める＆誤学習してないか確認 という手順で進めていきました。 この一連の経験が今でも役に立っていると感じる & 入社初期に「見習うべき型・勝ちパターン」のインプット期間があっ
北欧神話の世界で、村を作りながら新大陸を開拓する『NORTHGARD』というストラテジーゲーム*1を遊んだ時に、とても印象的な体験をしました。村人が増えて食料やお金も整って、いざ遠征するぞと準備を始めた時に、村人の士気が急に下がり始めたのです。食料やお金を用意したり、手当たり次第に介入しても士気は下げ止まらず、隣の村からの侵略を受けて占領されてしまいました。 何回かやり直してわかったことは、村がある程度大きくなった時には、家や酒場のような憩いの場がとても重要になるということでした。そして、憩いの場は、士気が下がり始めてから作り始めても効果はなく、村は崩壊します。とはいえ、最初に憩いの場を作ってしまうと限られた食料やお金がなくなり村は力を失います。 この例はいろいろと単純化していますが、遠征を「大胆さ」や「挑戦」、憩いの場を「思いやり」や「信頼」と置き換えることでチームでのソフトウェア開発に
社内で脆弱性診断を行なっている理由や、どのように診断から修正までを行なっているか、また社内で脆弱性診断をやることでどのような変化が起きたかについて紹介します。
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
うまくいっていても、組織にはスクラップアンドビルドが必要。タイミーが「短期的な非合理」を選び続ける理由【kameike×赤澤】
TOPインタビューうまくいっていても、組織にはスクラップアンドビルドが必要。タイミーが「短期的な非合理」を選び続ける理由【kameike×赤澤】 うまくいっていても、組織にはスクラップアンドビルドが必要。タイミーが「短期的な非合理」を選び続ける理由【kameike×赤澤】 2024年3月18日 株式会社タイミー VPoE 赤澤剛（Go Akazawa） 2009年に株式会社ワークスアプリケーションズに入社、ERPパッケージソフトウェアの開発とプロダクトマネジメントに従事。2015年よりシンガポール及びインドにてR＆D組織の強化、海外企業向け機能開発をリード。その後LINE株式会社での新銀行設立プロジェクト、株式会社アルファドライブ及び株式会社ニューズピックスでの法人向けSaaSの開発に携わった後、2021年1月にアルファドライブ執行役員CTO、2023年4月に株式会社NewsPicks f
私のプロジェクトでは Architecture Decision Record (以降 ADR と記載) を導入しています。プロジェクトで ADR を使い始めてから 1 年以上が経過したので、実際に使ってみての感想と今現在の捉え方についてここに残します。 ADR とはなにかという説明や具体的な運用方法については検索したら十分に発見できると思うので、ここでは割愛し、私たちのチームでの経験にフォーカスします。 私たちのチームの状況 私たちのチームは、新しいプロジェクトの開始にあわせて 1 年ほど前に結成したチームです。 現在は 4 人くらいのチームですが、開発スピードを上げるためにフロントエンドとサーバーサイドでほぼチームが独立して動いているような時期もありました。 そのときは最大で 10 人以上が同じプロジェクトに関わっているような状態でした。 私たちのチームでの使い方 ADR の導入はチー
生成AIはプロダクト開発をどのように変え、ソフトウェアエンジニアに必要なスキルはどのように変化するのかーー。 日本の10年先を行くと言われているシリコンバレーで、18年に渡ってプロダクト開発を経験している河根拓文氏が、シリコンバレーと日本の違いのリアルについて話します。 シリコンバレーに来て、早18年 河根拓文氏：みなさん、初めまして。河根です。よろしくお願いします。今日は簡単に「生成系AI時代のプロダクト開発」とは何か、何が変わってきたのか。そこで必要なチームのスキルはどんなものになっていくのかを簡単に、私なりの経験や考え方を紹介していければなと思っています。 まずは本題に入る前に軽く自己紹介からしたいと思います。私はシリコンバレー、サンフランシスコのベイエリアに来て、早18年ぐらいになりました。 行く前は日本のマッキンゼーでコンサルタントをしていて、プロダクトマネジメントやテック系の企
開発生産性を改善するためにやったこと
こんにちは、株式会社スマートショッピングでエンジニアリングマネージャーを担当しているleafです 先日開催された Findy Team+ Award 2023 にて組織別部門(50人未満の組織規模)とチーム別部門(レビューリードタイムが早い)を受賞することができましたので、Findy Team+ 導入から今までに取り組んだこと、今後の取り組みについてご紹介させていただきます 初めにやったこと 初期に取り組んだことは2点で、正確な現状把握と目標設定です 運用中のリポジトリに計測を導入したため、放置されたPRなどが残っており、開発状況に関係なく数値が上下することがありました そのため、対象リポジトリの放置PRなどを全て棚卸しし、どうしても制御できないPR(自動生成されるものや隣接チームの依存が大きいもの)に関してはタグを設定し除外することでようやく現状が把握できる状態となりました 目標設定に関
180件のPRを遡って、良いレビューコメントをLintのルールに組み込んだ - BASEプロダクトチームブログ
はじめに こんにちは。シニアエンジニアのプログラミングをするパンダ（@Panda_Program）です。本記事は BASE アドベントカレンダー 2023 の11日目の記事です。 BASE のバックエンド開発では巨大なモノリスからモジュラーモノリスへの移行が進んでいます。この記事では、モジュラーモノリスの中で自分のチームが担当しているモジュールに導入した PHPStan のカスタムルールの導入とその効果について紹介します。 PHPStan は BASE のモジュラーモノリスなバックエンドシステムに既に導入されていました。モジュラーモノリスの中で PHPStan のカスタムルールは2種類あります。各モジュールが守るべき共通のルールと、それぞれのモジュール内で特有のルールです。 PHP のコード品質を担保する PHPStan は多くの開発現場で採用されていますが、具体的なカスタムルールの事例は
アジャイルにおけるフロー効率を追い求めた結果、開発メンバーのエンゲージメントが低下したので改善した話 - バイセル Tech Blog
はじめに こちらは バイセルテクノロジーズ Advent Calendar 2023 の 2 日目の記事です。 前日の記事は早瀬さんの「開発効率を上げるためのモダンなフロントエンド構成」でした。 こんにちは！株式会社バイセルテクノロジーズのテクノロジー戦略本部開発 2 部でバックエンドのテックリードをしています藤澤です。 現在私の所属しているチームではアジャイル開発を取り入れて開発に取り組んています。その中でフロー効率を重視して価値提供のスピードを上げる取り組みをしていたのですが、思わず開発メンバーのエンゲージメントが低下していまうという問題が起きました。今回はその問題の経緯とそれをどのように改善したかについてまとめたいと思います。 はじめに 元々チームが目指していた姿 実践していたこととその成果 フロー効率を重視して起きた問題 機能が完成し切らない時がある 個人の成長実感がない 自身の重
私はソフトウェア開発を10年以上仕事として続けています。いつからか、どうすれば不確実性を減らして早く、要求通りのソフトウェアを開発できるかを考え始めていました。特に今年の4月に、フロントエンドチームのテックリードになってからは、フロントエンドチームが対峙する不確実性が少なくなるように考え、行動することに時間を使っています。 テックリードになってから6ヶ月経ち、反省することはたくさんありますが、プロジェクトのスケジュールに大きな遅延がなく、現時点で達成すべき水準の品質を満たしているので、ある程度の成果は出せていると自己評価しています。一方で、不確実性を下げるために考えたり行動することに少し飽きているというか、もうちょっとワクワクした気持ちで開発できないか悩んでいました。 そんな時に、庵野秀明監督が不確実性を保ったまま商業アニメーションを制作することに挑戦し、成し遂げた作品が『シン・エヴァンゲ
これらの数値は、数多くの開発チームを分析しクラスタリングした上で、ハイパフォーマーの特徴として抽出されたものです。ここでの重要な問いとして、「Four Keysといった数値を高めたら、自分たちが目指す強い開発組織の状態になるのか？」というと答えは、NOです。 特に開発生産性の可視化は、管理や監視のために測定するのはアンチパターンで自分たちのケイパビリティー向上のために使わなければ、逆効果になるケースもあります。よくあるケースとしては、開発生産性の指標をハックして無理やり数値をよく見せる行為です。自分たちのために計測していれば極端にハックする意味がないことは明白ですが、開発生産性を存在価値のために数値を提供すると、ある事象が起きやすいので気をつけたいところです。 こういった事象を「グッドハートの法則」と言います。または「キャンベルの法則」という類似の法則もあります。どちらの法則も、組織や制度
最近読み終えた本の中でこれはアタリだったなと思う本がある。 GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ、というものだ。 この本は昨年、私がプロジェクト伴走支援をしている会社の代表の方からオススメしてもらった。 タイトルどおりGitLab（ギットラボ）社とは世界最大のリモート組織である。 ・世界67カ国以上に従業員2,000名以上 ・自社オフィスを持たない世界最大のオールリモートカンパニー ・リモートワークのための方法論やカルチャーを「GitLab Handbook」として公開 ・リモートワークの方法だけでなく評価、給料の決め方、部門ごとの仕事の進め方など、社員として必要な知識をすべて支える「ドキュメント文化」が浸透 GitLab社のマニュアル原本は大変情報が膨大らしく、いきなりこれらすべてを読み解くの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog
ふりかえり手法「象、死んだ魚、嘔吐」でチームの闇と向き合おう - Qiita
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
開発者ポータル Backstage とは - Carpe Diem
「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程
チーム開発における技術選定の進め方 - ROUTE06 Tech Blog
質とスピードとゆとり - KAKEHASHI Tech Blog
不確実性や心理的安全性に向き合い自己組織化するチームを作る実践プラクティス
Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog
エムスリーで活躍する人の型を観察してみた その１ - エムスリーテックブログ
思いやりから始めたリーダーシップ、その先へ - ROUTE06 Tech Blog
社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化
アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
チームにおける ADR 導入から 1 年経った振り返りと感想 - ROUTE06 Tech Blog
「AIに仕事を奪われてどうのこうのという段階ではない」 シリコンバレーで18年働く河根拓文氏が教えるエンジニアに必要なスキル
不確実性を保ちながらソフトウェア開発を進める呪文「てみて」 - ROUTE06 Tech Blog
生産性が低いチームを強くするには？ うまく成長するための「順番」がある
「属人性を高める行為は知的謙虚さにかける」という考え方を知り、プロジェクト推進の標語にすぐにしたいと思った話。