アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ
【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA …
大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師としても勤務。『SCRUM BOOT CAMP THE BOOK』（翔泳社）をはじめ、専門領域に関する著書も数多く手がけている。 吉羽龍太郎氏 セッションはまず「アウトプットとは何か」という問いかけから始まった。「アウトプットに似た言葉として、アウトカムやインパクトといった言葉がある。まずこれらの関係性を整理したい」と吉羽氏。 アウトプットは「人や機械、組織が作ったものの『かたまり』や『量』を示すもの」。プロダクト開発におけるアウトプットとは、リリースしたプロダクトの機能やこな
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
Broken Ownership
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
SMBC三井住友銀行が流出認める：艦これ発端で発覚したGitHub経由のコード流出（三上洋） - エキスパート - Yahoo!ニュース
1月28日夜からTwitterで大きな騒ぎになっていたSMBC・三井住友銀行のコード流出騒ぎは、GitHubアカウントに自分が書いたと思われる企業のプログラムのコードをアップしていたことが原因でした。艦隊これくしょんというゲームにまつわる諍いから、過去のツイートが見られて発見されたものです。 発端は艦これ有名配信者・きぃのん氏と「S氏」の諍い艦隊これくしょんは約8年前から続く人気ゲームです。最近ではゲーム運営側の問題もあってユーザーが離れがちで、残ったファンの間でSNS上の諍い・論争が絶えない状態でした。（この部分、事件と関係ないだろうとのご指摘を頂戴しました。そのとおりです。すみません） そんな中、艦これのゲーム配信最大手である「きぃのん」 氏と今回の流出のきっかけとなったS氏がTwitterで論争となります（筆者はきぃのん氏の配信のリスナーです）。煽り合う中で、きぃのん氏の配信のリスナ
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
平尾誠@ARUTEGA.Inc @Makopontass コーディングを外に出すことが増えてきた。 やはり経験値が少ない人の品質管理は大変だと感じつつも、しぶとくピクセルパーフェクトを狙ってくる方に仕事を任せてよかった。 この再現性への執着心がないと伸び代を感じれない。 吉本 集 / aru inc. @tsuDoi220 いやー、実際そうなんですよねー。 ピクセルパーフェクトに、そもそも拘っていない人に、仕事お願いしたくない。テクニックどうこうより、全然こっちのほうが大事。ほんとに。 後、速度とちゃんと納期守ること。 当たり前のようだけど、意外とね、、、 twitter.com/makopontass/st…
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
プロダクトオーナーが最低限守るべき10のこと
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数
2024年7月25日紙版発売 2024年7月25日電子版発売 柴田芳樹 著 A5判／208ページ 定価2,860円（本体2,600円＋税10%） ISBN 978-4-297-14293-3 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto この本の概要 本書は，著者が1993年から約30年間経験してきたAPI仕様の作成，2003年から20年間経験してきたテストファースト開発／テスト駆動開発の知見をまとめたものであり，一般的なソフトウェア開発者が習得することが容易ではない事柄を，本書を通して学び，実践してもらうことを目的としています。 本書が提唱する「API仕様ファースト開発」はWebサービスにおける大域的なテスト駆動開発の
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
長年 Chromium (Chrome) ブラウザの開発に携わっていたのですが、やめてチームを移ることにしました。2021年10月1日が最後の日です。 チームを変わるだけで転職ではないのですが、結構いろいろやったなと思ったのと、瞬間最大風速的に沢山お礼を言ってもらって嬉しかったので、記録として書いておくことにしました。最初は褒めてくれてるtweetだけ貼ってﾄﾞﾔｧ的なやつを作ろうかと思ったのですが😇、いい機会なのでやったことも書ける範囲で書いてみました。オープンソースはこういうとき気楽でいいです。 Personal update. After 10+ years I’m leaving Chrome and doing something else. I started with a small API and ended up owning entire Loading & Netw
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手
fx1jp @fx1jp1 ひどい。。 サービスリリース発表と同時にサービス終了のお知らせ。 こんなに見事にハシゴを外されるのをみたことない。 沖電気、「LINE Pay かんたん送金サービス」と連携できるソフトウェア開発キット発表→同日、日本国内における「LINE Pay」サービス終了に関するお知らせ pic.twitter.com/SnKeWvotWk
トヨタはハードウェアアジャイルをどう強みにしているか？ 自動車開発におけるスクラムとモブの実践 - Agile Journey
アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering T
IT業界の「多重下請け地獄」が横行し続ける真の理由
新型コロナウイルスの感染拡大や、政府による緊急事態宣言などの影響を受けて、多くの企業が中途採用の求人を減らし始めている。IT業界でも今後エンジニアの中途採用の規模縮小が心配される。業界で常態化している多重下請け構造のもとで、業務委託や派遣社員のエンジニアの人数を減らす企業が増えていくことも十分考えられる。 業界の多重下請け構造にはさまざまな問題があるとして、構造改革に取り組んでいるのが、東京都渋谷区に本社がある情報戦略テクノロジーだ。企業の事業部門と直接ビジネスをする「0次請け」と、エンジニアのスキルシートの統一化を進めている。 同社の高井淳社長は、IT業界の1次請けから3次請けまでのビジネスを経験。「構造改革をしなければ日本のソフトウェア開発の技術向上も、エンジニアの育成もできない」と訴える。日本のIT業界の課題と、高井社長が取り組む改革についてのインタビューを前後編の2回にわたってお伝
『ユニコーン企業のひみつ―Spotifyで学んだソフトウェアづくりと働き方』 - snoozer05's blog
翻訳を担当した書籍『ユニコーン企業のひみつ―Spotifyで学んだソフトウェアづくりと働き方』（オライリー・ジャパン）が4月26日に発売になります。本書は2019年3月にPragmatic Bookshelfより出版されたJonathan Rasmusson著『Competing with Unicorns: How the World’s Best Companies Ship Software and Work Differently』の全訳です。 本書は、『アジャイルサムライ』（オーム社、2010年）の著者として日本でもよく知られている、Jonathan Rasmussonの3冊目の著作であり、ある時期のSpotifyに身を置いていた著者が、そこでの経験などを元にユニコーン企業のソフトウェアづくりと働き方について解説した書籍となります。 www.oreilly.co.jp 大規模な成
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
日本の医療システムの再構築を目指すスタートアップ「カケハシ」のフロントエンド領域でのチャレンジ / Challenges in the frontend domain at “Kakehashi”
仕事の進め方のヒントになるかもしれない 「アジャイル」からのつまみ食い（開発者じゃなくても、ひとりでも） / Sneak Tips From Agile
Regional Scrum Gathering Tokyo 2021 #RSGT2021 での発表です
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
Nuxt Scriptsって何ができるの？ Nuxt4メインセッションに添えて@Vue.js v-tokyo Meetup #21
はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！ - ブロッコリーのブログ
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
雇用市場の変化がコロナ禍で後押しされている。政府の会議のメンバーも務め、論客の新浪剛史サントリーホールディングス社長の口から飛び出した「45歳定年制度」。その背景は? 実現性は? ◇ ◇ ◇ 9月9日。緊急事態宣言の最中ということでオンラインで開催された「経済同友会・夏季セミナー」。経済界だけでなく一般にも名の知られた経営者らが参加し、「日本が三流国に落ちていかないようどう変わるべきか」という危機意識のもとに議論が行われた。ここではその中で出た2つのキーワードに注目したい。 オイシックスの創業者でオイシックス・ラ・大地の社長を務める高島宏平氏(48)の発言。「先の見通せない時代にはいかに社会をアジャイル化するかだと思う」。 アジャイル…。もともとは開発の現場で使われてきた言葉で「すばやい」「俊敏な」という意味だ。完成図ありきの「ウォーターフォール」と対比される手法で、「アジャイル」はテスト
プロジェクト管理はNotionしか勝たん！MLチームのスプリント管理を改善した話 - LayerX エンジニアブログ
こんにちは、バクラク事業部のMLチームでソフトウェアエンジニアをしているTomoakiです。 今回はMLチームのスプリント管理におけるタスク・プロジェクト管理にNotionの新概念であるProjectを導入してみたら嬉しいことがたくさんあったので、それらを紹介したいと思います。 イントロダクション Notionの2.30リリースでプロジェクトという概念が登場し、プロジェクトの管理のテンプレートが公開されるなど大きなアップデートがありました。 www.notion.so 本記事でも紹介しますが、このリリースで紹介されているテンプレートが優秀すぎるので、まだみてない方は是非見てみてください。 MLチームでは5月末ごろから、ちょうどスプリント管理に課題感を感じており、早速NotionのProjectを取り入れて6月中に運用してみましたかなり良かったので、本記事では我々目線でのその効果を紹介したい
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
Software Design連載 2022年2月号 大規模Webアプリケーションの開発環境をモダナイズする - MonotaRO Tech Blog
こんにちは。モノタロウの八木(t_yagi)です。 モノタロウのECシステムは創業から20年以上ずっと動き続けており、絶え間なくビジネスを支え続けています。 その間、周囲のIT技術も大きく進歩してきました。 そんな中、開発者が増えたり機能も拡張され続けた結果、当初はさほど問題にならなかった開発に関する課題が浮き彫りになってきました。 今回はそんなレガシーな開発環境にモダンなIT技術を取り入れることで「当時は出来なかったことを現代の技術で実現する」を書きました。 流行りのモダンな技術がイケイケだから乗り変えるといったような輝かしいものではなく、長年積まれ続けてきた課題が現代の技術だから解決できたという時代の恩恵にうまく乗れるかを率直に記事にしています。 どうするとデメリットを抑えながらメリットを得ることができるか読んでいただける人に少しでも感じ取っていただければ嬉しいです。 サーバアプリの開
はじめに 本記事はBASE アドベントカレンダー 2022の6日目の記事です。 はじめまして！BASE株式会社で、ネットショップ作成サービス「BASE」のプロダクトチームのマネージャーをしている @yusaku と申します。記事を書くに当たって、自分がいままでやった1on1を振り返りつつ、数えてみました。 時期によってもちろん変動はあるのでざっくり試算ではありますが、社内では自分の組織でのメンバーや上長と週1回の15分〜30分の1on1、新しく入社して頂いた方がいるオンボーディング時では毎日15分の1on1を行っていたので、週5~15回くらい1on1していました。またプライベートでは、プロコーチとしてパーソナルコーチングも行っており、2022年では100回ほど1on1を行っていたので、合わせて500回以上は1on1をしていました。 その結果わかった1on1で大事なことを記事にしていきたいと
私はソフトウェアエンジニア、宮川達彦さんが運営するポッドキャスト Rebuild.fmの大ファンです。当時の同僚に勧められて初めて聞いた2014年から今まで聞いていない回はおそらくなく、何度も繰り返し聞いた回がいくつもあります。 自身で書いたブログなどでもRebuild.fmを参照させてもらったことも多く、2021年に翔泳社さん運営のWebメディア BizZineにプロダクトマネジメントに関する記事を投稿した際にも、記事内でRebuild.fmの回に触れ、放送回のタイトルを記事タイトルに引用させていただきました。 ビジネス寄りの媒体であるBizZineにRebuild.fmへのリンクが貼られているのは私の記事だけではないかと自負しています。
新型コロナウイルスの接触確認アプリ「COCOA（ココア）」が機能しなかった問題は日本の役所の旧弊を浮き彫りにした。最たる例が金額や仕様に厳格であるがゆえに硬直的な公共調達だ。IT（情報技術）の世界で普及しつつある機動的な開発手法との相性が決定的に悪かった。デジタル時代に対応した行政のアップデートが改めて問われる。スマートフォンのアプリなどは、短いサイクルで機能変更や改修を繰り返すアジャイル開発
ryuzeeさんの記事で紹介されていたスクラムマスターを雇うときに聞いてみるとよい38個の質問 に答えてみました。 38個すべてに一度に答えていこうとするとかなりハードですが、1日1個ずつこつこつと、回答をしていっています。 この回答は、年月を重ねることに変わっていくかもしれません。 2019/12時点の回答がこちらです。 スクラムマスターの役割について 1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？ スクラムマスターはプロセスを順守する・させるためだけの存在ではありません。プロセスを順守する行為は「どのように行うのか（How）」を守らせることに注力してしまいがちですが、「なんのために行うのか（Why）」のほうを重視すべきです。 アジャイルにおけるチームの成功は、「よいプロ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
毎朝15分以上のデイリースクラムをしてる - Mitsuyuki.Shiiba
スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
https://twitter.com/tanakahisateru/status/1566467377357012992
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
Agile and Requirement : アジャイルな要件定義について考える
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
ピクセルパーフェクトは必要なのか？ HTMLコーダーの考え方まとめ
スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita
Web API設計実践入門 ――API仕様ファーストによるテスト駆動開発
長くいたチームから移る日のこと｜Kinuko Yasuda
多様なメンバーが気持ちよく効果的に働けるチームにしていきたい
ひどい。。サービスリリース発表と同時にサービス終了のお知らせ。こんなに見事にハシゴを外されるのをみたことない。
タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt
機能は追加すればいいというものではない
サービスの持続的な成長と技術負債について
再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ
『45歳定年制』？ 進む、人材の新陳代謝（日本テレビ系（NNN）） - Yahoo!ニュース
第二のコインハイブ事件生み出さないためには 弁護人らが最高裁無罪判決振り返る - 弁護士ドットコムニュース
年間500回1on1した結果わかった大事なこと - BASEプロダクトチームブログ
テープが擦り切れるまで聞いた Rebuild.fm 厳選オススメ回 4選
「アジャイル開発」阻む役所の流儀 COCOA失敗招く - 日本経済新聞
「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に答える - Qiita
hideki.ue.bulog.jp
realsound.jp
togetter.com
karapaia.com
7-24blog.com
www.gizmodo.jp