タグ

ryuzeeのブックマーク (10,589)

  • 【西川和久の不定期コラム】 無料でWin32/64アプリがBig Surで動作! Apple M1も対応の「WineskinServer」

    【西川和久の不定期コラム】 無料でWin32/64アプリがBig Surで動作! Apple M1も対応の「WineskinServer」
    ryuzee
    ryuzee 2022/07/25
    これでJust RightもMac上で動いた
  • なぜ「スクラム開発」という用語に違和感があるのか?

    みなさんこんにちは。@ryuzeeです。 今日はポエムです。役に立つ話でもないので適当にスルーしてください。 巷で「スクラム開発」という単語をたまに見かけるのですが、ずっと違和感を持っていました。 自分自身は使わない単語なのですが、どこに違和感があるのかを改めて考えてみたいと思います。 まずは国語的な観点から見てみよう「スクラム開発」という単語を国語の観点で見ると、「スクラム」と「開発」の複合名詞だと言えます。 日語の複合名詞の解釈のルールは以下のようにまとめられます(諸説あるようです)。 一般に、複合語の意味関係には、主に①修飾関係(Modification)②叙述関係(Predication) ③並置関係(Apposition)の 3つのタイプがあると考えられている(cf.Spencer1991, Lieber 2009, Scalise & Bisetto 2009)。これらは、日

    なぜ「スクラム開発」という用語に違和感があるのか?
    ryuzee
    ryuzee 2022/07/23
    何の役にも立たないポエムを書いた。個人的にはめちゃくちゃ違和感があるのだよねぇ。
  • 「チームトポロジー」を読んで人間にできるソフトウェア開発を考えた - miyarappoの試行錯誤

    はじめに 社内の輪読会で読んだチームトポロジーというが、非常に良かったので自分自身の整理ためにまとめてみました。 概要を把握するなら訳者自身による説明が一番まとまっていて分かりやすかったです。 現代におけるソフトウェア開発の難しさ そもそもソフトウェアを構成するコードは大きくて複雑である。また、ソフトウェアは日々変更されるものである。大きくて複雑なものを変更するので難易度はさらに上がる。 現在のIT組織は、ソフトウェアシステムをすばやく安全に提供、運用すると同時に、成長を続け、ビジネスや規制環境の変化や圧力に適応しなければならない。企業が最適化の目的を安定性の向上か速度の向上かで選べた時代は終わったのだ。 多くの場合、ソフトウェアをデリバリーする組織の設計が間違っているというのが書の主張である。 組織図を額面通りに受け取ってしまうと、人間をソフトウェアのように設計し、コミュニケーション

    「チームトポロジー」を読んで人間にできるソフトウェア開発を考えた - miyarappoの試行錯誤
    ryuzee
    ryuzee 2022/06/20
    「概要を把握するなら訳者自身による説明が一番まとまっていて分かりやすかったです」と書かれて喜ぶの巻
  • Do you really have to do Scrum by the book? About ScrumBut, ScrumAnd and maturity

    ryuzee
    ryuzee 2022/05/24
    ScrumAndとScrumButの話。よくまとまってる
  • Testing in Production, the safe way

    Author’s Note: I’m greatly indebted to Marc McBride for reading a draft of this post and offering some excellent suggestions. This is the second installment in my series on testing distributed systems. The posts in this series are the following: Testing Microservices, the sane way (published December 2017) Testing in Production, the safe way (published March 2018) Testing in Production: the hard p

    Testing in Production, the safe way
    ryuzee
    ryuzee 2022/05/22
  • 300+ Agile and Scrum Statistics for 2024

    Trying to convince your team or CEO to go Agile? Need some hard data to back up your claims? You’ve come to the right place! We’ve combed the internet for all the agile statistics we could find, including data on Scrum, Kanban, metrics, meetings, and more. So whether you’re writing a blog, a research paper, or preparing a deck on agile effectiveness, we’ve got what you’re looking for.

    300+ Agile and Scrum Statistics for 2024
    ryuzee
    ryuzee 2022/04/25
    アジャイル関連のさまざまな統計データ
  • [Obsidian] コミュニティプラグイン全集 改訂版

    Obsidianには標準で用意されたコアプラグインとコミュニティプラグイン(いわゆるサードパーティプラグイン)が存在します。 その中でもコミュニティプラグインは多数存在し、また今後もその数は増え続けるでしょう。 それ自体は非常に楽しく、またそうあるべきですが、一方で必然的にいくつかの問題も引き起こします。 プラグインの数があまりに多く、ダウンロード数という指標だけでは探しにくい何のためのプラグインなのか、またどう使うのかが分かりにくいそこでこのページでは「特性による分類」と「ワンポイントアドバイス」によって、あなたが今最も必要とするプラグインに出会い、そして使い始める手助けをしたいと考えています。 「特性による分類」とは何か? 難しく考える必要は全くありません。たとえば「HUNTER×HUNTER」の念能力になぞらえるなら、プラグインはこんなふうに分類できるでしょう。 (Output 0.

    [Obsidian] コミュニティプラグイン全集 改訂版
    ryuzee
    ryuzee 2022/04/23
    これは良いまとめ
  • 本を書くときに編集さんに期待していること

    いままで多くの機会をいただいて、兼業ながら商業出版で、IT技術についてそれなりの数のを書いてきました。 ぱっと数えたら、単著5冊、共著・ムック6冊で、その他に雑誌寄稿が多数あります。 その中でそれなりに多くの編集さんとお仕事をする機会がありまして、著者として担当さんに期待する振る舞いが見えてきたので記録しておきます。 あなたがわたしと同じ状況になったとき(=執筆機会を得たとき)、担当さんに要請しておき、担当さんが応えてくれた場合、そのは素晴らしいものになるでしょう。 自分の想い できるだけミスを減らしたい(当たり前品質) そのために、原稿を版管理・差分管理したい そのために、Linter、検索ツール、文書校正ツールなどを活用したい ならば、極力テキストフォーマット状態で作業するのが都合が良いという認識 できるだけ良いものにしたい(魅力的品質) そのために、力を出し合って制作したい 著者

    ryuzee
    ryuzee 2022/04/20
    第三者レビューでもガッツリ手を入れるので、個人的にはそのタイミングであらかた校正してもらう必要はないんだけど、あとは同じかなー
  • 『チームトポロジー』から学んだ組織設計 #ちいとぽ | クラッソーネ開発者ブログ

    こんにちは。プロダクトマネージャーの田原です。 社内のSlackに社員の誕生日と入社記念日を通知する仕組みを作ったところ、各方面から割と好評なようで嬉しいです。 https://twitter.com/shogocat/status/1485925356070924288 この度、話題の『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』を読みました。 https://www.amazon.co.jp/dp/4820729632/ (アトラクタ様のプレゼント企画にて御をいただきました。ありがとうございます!) 『チームトポロジー』の紹介 チームトポロジーについては書訳者の吉羽さんの【資料公開】30分で分かった気になるチームトポロジーやその講演の様子を見ていただくと概要をすぐに掴めるのでおすすめです。変化が激しく正解の見えないソフトウェア開発において、チームが適切に機

    『チームトポロジー』から学んだ組織設計 #ちいとぽ | クラッソーネ開発者ブログ
    ryuzee
    ryuzee 2022/04/13
    クラッソーネさんの実例!!
  • チームトポロジーで描く、リンクアンドモチベーション開発組織の4年間の歩み - Link and Motivation Developers' Blog

    はじめに リンクアンドモチベーションでSRE/QAチームのEMをしている河野です。 記事では、SREチームから見た開発組織の変遷をチームトポロジーを用いて解説します。 チームトポロジーとは 一言でいうと、「ソフトウェア開発体制の"定石"をモデル化したもの」です。これにより、組織におけるパターンランゲージ(共通言語)として扱うことができます。 詳しくは2022/3/16に行われたイベント「チームトポロジーを成功させる実践方法の探求」の資料と動画が分かりやすいのでそちらを参照ください。 slide.meguro.ryuzee.com timee.notion.site www.youtube.com Ph1. 内製化開始 時期: 2018年-2019年 社員数: 4-16名 2018年から開発組織の内製化を開始しました。 パートナーさんの力を借りながら、研修やOJTを通じて新卒をエンジニア

    チームトポロジーで描く、リンクアンドモチベーション開発組織の4年間の歩み - Link and Motivation Developers' Blog
    ryuzee
    ryuzee 2022/04/12
    こうやって同じ語彙やアイコンで見える化してくれるのは本当にありがたい! #ちいとぽ
  • DevOpsトポロジー

    みなさんこんにちは。@ryuzeeです。 2021年12月1日に発売した『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者/訳者:マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社:日能率協会マネジメントセンター発売日:2021-12-01単行:280ページISBN-13:9784820729631ASIN:4820729632 今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。 このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。 2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、こ

    DevOpsトポロジー
    ryuzee
    ryuzee 2022/04/11
    チームトポロジーの元になったDevOpsトポロジーを紹介がてら翻訳してみました。
  • WordPress テーマ Snow Monkey

    Snow Monkey は Gutenberg ブロックエディターに対応した 100%GPL の WordPress テーマです。 web 制作で使えるブロックやパターンを多数用意。スピーディーにサイトを立ち上げられます。 開発を意識したテンプレート構造やフックで高度なカスタマイズも可能です。

    WordPress テーマ Snow Monkey
    ryuzee
    ryuzee 2022/04/08
    SORACOMさんが使ってて知った。なかなかよさげ
  • ソラコムのプロダクトマネジメント 成長する組織と役割の変化 - SORACOM公式ブログ

    皆様こんにちは。ソラコムでプロダクトマネージャー兼プロジェクトマネージャーをやっております江木と申します。みんなからは nori と呼ばれています。 はじめに ソラコムでは昨年プロダクトマネジメントチームを立ち上げました。文字通り、プロダクトマネジメントをチームでやっていこうということです。そして私もプロダクトマネジメントをやることになりましたので、 プロダクトマネジメントチームを立ち上げることになった経緯まず、なにをやったか。 を書きたいなと思っております。 正直、思いつくまま勢いで書いているので冗長な部分などもありますが、特にこれからプロダクトマネジメントをやることになった方の参考になれば、あと、これまでのソラコムの様子も伝わればいいなと思っています。内容は完全に私個人の考えだったり、記憶によるので、そこのところはよろしくお願いします。 そして私が最もお伝えしたいことは「ソラコムではプ

    ソラコムのプロダクトマネジメント 成長する組織と役割の変化 - SORACOM公式ブログ
    ryuzee
    ryuzee 2022/04/08
  • Four types of Product Managers and how to deal with them

    ryuzee
    ryuzee 2022/04/01
    プロダクトオーナーの良くあるタイプ。相手に合わせちゃうカメレオン、先のことまで見通した気になってる予報士、考えることばかり夢中な研究者、正しさばかりを追求する戦士。
  • 7 Different Product Roadmap Formats

    [Originally published on my personal site. You can read it there — https://www.antmurphy.me/blog/22/3/28/7-different-product-roadmaps] After writing about ‘8 different ways to organize your Product Backlog’, which has since been transformed into Miro templates, I thought I would write something similar for Product Roadmaps. Here are a few different shapes a Product Roadmap can take. I hope this gi

    7 Different Product Roadmap Formats
    ryuzee
    ryuzee 2022/04/01
    プロダクトロードマップのフォーマット7種類。ロードマップは約束でもないしスケジュール表でもないからな
  • 高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割 - yigarashiのブログ

    最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。 【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。 チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料 課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした

    高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割 - yigarashiのブログ
    ryuzee
    ryuzee 2022/03/23
  • How to Diagnose and Correct Poorly Attended Sprint Reviews

    ryuzee
    ryuzee 2022/03/21
    スプリントレビューにステークホルダーが参加してくれない7つの理由。単に日が悪い / 退屈 / 参加すべき理由がわからん / 長い / フィードバックに反応してくれない / 目に見える進捗がない / 忙しすぎる
  • これだけは押さえよう!住所フォームの作り方 - ケンオールブログ

    まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基。「建物」フィールドはオプション 文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース(住所フォーム)は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能(郵便番号による住所補完)は、住所フォームの改善方法として最も効

    これだけは押さえよう!住所フォームの作り方 - ケンオールブログ
    ryuzee
    ryuzee 2022/03/02
  • 「自動テストとテスト駆動開発、その全体像」を執筆しました(Software Design 2022年3月号) - t-wadaのブログ

    【更新】寄稿した記事が Web に公開されました 技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます! gihyo.jp はじめに 2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発(TDD: Test-Driven Development)の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。 ソフトウェアデザイン 2022年3月号 作者:大竹 章裕,瀬戸口 聡,庄司 勝哉,光成 滋生,

    「自動テストとテスト駆動開発、その全体像」を執筆しました(Software Design 2022年3月号) - t-wadaのブログ
    ryuzee
    ryuzee 2022/02/22
    買いました。最長間隔なのでは?「雑誌記事を初めて書いたのは実は Software Design 誌で、同誌への執筆はそれ以来となる17年1ヶ月ぶりです」
  • GitLabで学んだ最高の働き方 Developers Summit 2022-02-18

    Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling

    GitLabで学んだ最高の働き方 Developers Summit 2022-02-18
    ryuzee
    ryuzee 2022/02/22
    素晴らしいよねー