この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita
前提としての情報 単に「Figmaで要件定義のためのUMLも、外部設計のためのデザインも、内部設計のためのERDも全部つくるよ〜〜」という話をすると、ERD書くならデザインツールなんて使わないで、DBMSから自動生成できるツールとか使った方がいいじゃん、みたいな疑問が出るのは重々承知なので、そもそもこの形式に落ち着いた前提事項を書いておきたいと思います。 ご興味がなければ読み飛ばしてください。 筆者の仕事範囲 さて、冒頭で「事業会社でデザイナーとPMの狭間みたいな仕事をしてます」と書きました。キャリアの背景的には受託のPMっぽい仕事（厳密には違うんですが、本旨ではないので割愛します）→事業会社のインハウスデザイナー→現職という感じで、外渉から手を動かす所まで、必要ならなんでもします。 ざっくりいうと、機能の起案をして、経理などの関連部署に相談して、WBS引いて、UML書いて、画面遷移図書い
退職エントリを書くつもりはあまり無かったけど、はてブに退職エントリが多くあがっていて書く気力が高まったので書いてみた。 DMMに入社した理由 去年の5月に入社しました。 大きな企業の便利な社内ツール・サービスを見たい 色んな種類のサービスの裏側を見たい Railsアプリをゼロから作る機会 仕事で rails new できる プロジェクト初期からレビューできる あたりに魅力を感じて内定を承諾した。 DMMでやっていたこと とあるサービスのリプレイス案件*1のサーバサイドエンジニアを担当していた。 既存のデプロイ方法の修正 AWSのアーキテクチャ設計 APIや管理画面をRailsで実装 RubyやRailsに関するレビュー（他メンバーがあまりRailsに慣れていなかった） Terraformを使ったインフラ業 死活監視の設定 タスク管理 この案件、入社して2ヶ月でデスマの気配を感じていた。 自
TL;DR : ひとことでいうと 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう たまに遭遇するシーン ソフトウェアプロダクトの企画（プロダクトデザイン、プロダクト設計）を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。 「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は（程度の大小はあれど）起こってしまう と思っていて、今回はそういったケースを想定しています。 特に、以下のような思いがあるからそうしている、というケースを話題に上
東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ
#RSGT2020 テックリードは未来の話をしよう / Tech Lead in Scrum
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890/tech-lead-in-scrum
ストックマークの開発体制は、プロダクトの成長フェーズに合わせて、2021年夏に大きく進化しています。本エントリでは、何が課題でどう進化したのか？を紹介いたします。本エントリを読むことで、スタートアップの開発体制で発生する課題と、その解決方法の1つを理解できます。 サマリ開発チームのパフォーマンスが最大化できていなかった開発チームに自由と責任を委譲し、より自律的な行動を促進したスクラムを辞めて、カンバンを主軸とする開発へその結果、開発スピードが大きく向上し、より迅速にアウトカムを提供できるようにどんな課題が存在していたのか？大きく分けて、開発チームに関する2つの課題が存在していました。 課題1: リソースの偏りストックマークの以前の開発体制(〜2021年8月)では、Anewsの開発チームは大きく分けて、 以下の2つが存在していました。 情報収集機能を開発するチームコミュニケーション機能を開発
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
株式会社ドリコム 知的ヘンタイ六番勝負「第四戦 LT王者決定戦」 http://recruit.drecom.co.jp/event/event4.htmlRead less
ソフトウエア開発力のさらなる強化へ 及川卓也氏・吉羽龍太郎氏・和田卓人氏がNTT Comの社外技術顧問に就任 - Shines｜ドコモビジネス｜NTTコミュニケーションズ
事業共創プログラム OPEN HUB for Smart World 未来をひらく「コンセプトと社会実装」の実験場 OPEN HUB for Smart Worldは、社会課題を解決し、わたしたちが豊かで幸せになる未来を実現するための新たなコンセプトを創り、社会実装を目指す事業共創の場です
15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ
【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA #Forkwell_Library
アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
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,
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
プロダクトオーナーが最低限守るべき10のこと
みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数です。チェックリストに100個の項目があっても覚えられません。プロダクトバックログに100個の項目があった場合、覚えているのは先頭の方と、気になる項目だけになるでしょう
IT業界の「多重下請け地獄」が横行し続ける真の理由
新型コロナウイルスの感染拡大や、政府による緊急事態宣言などの影響を受けて、多くの企業が中途採用の求人を減らし始めている。IT業界でも今後エンジニアの中途採用の規模縮小が心配される。業界で常態化している多重下請け構造のもとで、業務委託や派遣社員のエンジニアの人数を減らす企業が増えていくことも十分考えられる。 業界の多重下請け構造にはさまざまな問題があるとして、構造改革に取り組んでいるのが、東京都渋谷区に本社がある情報戦略テクノロジーだ。企業の事業部門と直接ビジネスをする「0次請け」と、エンジニアのスキルシートの統一化を進めている。 同社の高井淳社長は、IT業界の1次請けから3次請けまでのビジネスを経験。「構造改革をしなければ日本のソフトウェア開発の技術向上も、エンジニアの育成もできない」と訴える。日本のIT業界の課題と、高井社長が取り組む改革についてのインタビューを前後編の2回にわたってお伝
トヨタはハードウェアアジャイルをどう強みにしているか？ 自動車開発におけるスクラムとモブの実践 - Agile Journey
アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering T
仕事の進め方のヒントになるかもしれない 「アジャイル」からのつまみ食い（開発者じゃなくても、ひとりでも） / Sneak Tips From Agile
Regional Scrum Gathering Tokyo 2021 #RSGT2021 での発表です
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community
はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
講師をつとめる研修の終わりに、参加者からの質問というか相談に答えるようにしている。先日の研修で、ある受講者から「職場の開発をアジャイルにしていきたいがどうしたら良いか」というよくある相談が寄せられた。実はこの手の相談はやりとりに手間がかかる。相手の置いている前提、置かれている状況を的確に把握しなければならない。 私「なぜ、アジャイルに取り組みたいのですか」 まず、狙いを聞かねばならない。Start With Why。ここが分からないと何を聞いて答えても的外れにしかならない。ここで、いきなり「見える化から取り組むといいですよ」「もちろんスクラムですね」と、手段を提示しはじめるような相手だと、相談するのはやめたほうが良い。 受講者「スピード感のある開発をしないといけないと思っています。ユーザーの声を聞いて、それを実装していけるように」 私「なるほど、"何をつくるべきか分からない" ソフトウェア
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！ - ブロッコリーのブログ
目次 目次 はじめに（本記事の見どころなど） テストについて話し合わなくてはならない テストの目的 「うまくいかないかもしれないものは何ですか？」 なぜテストをするのですか？ この場合に限り…… テスト駆動開発 〜テストについて語る前に説明が必要です〜 テストについて話しましょう なぜすべてのテストを自動化しないの？ テストカバレッジは有用な指標ですか？ 「テストをシフトレフトする」とはどういう意味ですか？ いつ、どこでテストすべきですか？ 十分なテストとはどれくらいですか？ おわりに はじめに（本記事の見どころなど） 今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。 dannorth.net 本記事はDaniel Terhorst-North(Dan North
雇用市場の変化がコロナ禍で後押しされている。政府の会議のメンバーも務め、論客の新浪剛史サントリーホールディングス社長の口から飛び出した「45歳定年制度」。その背景は? 実現性は? ◇ ◇ ◇ 9月9日。緊急事態宣言の最中ということでオンラインで開催された「経済同友会・夏季セミナー」。経済界だけでなく一般にも名の知られた経営者らが参加し、「日本が三流国に落ちていかないようどう変わるべきか」という危機意識のもとに議論が行われた。ここではその中で出た2つのキーワードに注目したい。 オイシックスの創業者でオイシックス・ラ・大地の社長を務める高島宏平氏(48)の発言。「先の見通せない時代にはいかに社会をアジャイル化するかだと思う」。 アジャイル…。もともとは開発の現場で使われてきた言葉で「すばやい」「俊敏な」という意味だ。完成図ありきの「ウォーターフォール」と対比される手法で、「アジャイル」はテスト
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに
ryuzeeさんの記事で紹介されていたスクラムマスターを雇うときに聞いてみるとよい38個の質問 に答えてみました。 38個すべてに一度に答えていこうとするとかなりハードですが、1日1個ずつこつこつと、回答をしていっています。 この回答は、年月を重ねることに変わっていくかもしれません。 2019/12時点の回答がこちらです。 スクラムマスターの役割について 1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？ スクラムマスターはプロセスを順守する・させるためだけの存在ではありません。プロセスを順守する行為は「どのように行うのか（How）」を守らせることに注力してしまいがちですが、「なんのために行うのか（Why）」のほうを重視すべきです。 アジャイルにおけるチームの成功は、「よいプロ
新型コロナウイルスの接触確認アプリ「COCOA（ココア）」が機能しなかった問題は日本の役所の旧弊を浮き彫りにした。最たる例が金額や仕様に厳格であるがゆえに硬直的な公共調達だ。IT（情報技術）の世界で普及しつつある機動的な開発手法との相性が決定的に悪かった。デジタル時代に対応した行政のアップデートが改めて問われる。スマートフォンのアプリなどは、短いサイクルで機能変更や改修を繰り返すアジャイル開発
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
情報システムってなんなん
この間情報システム部ですって人がいた。 「今、会社でスクラムを導入する大きなプロジェクトを任されてて、、、」みたいなこと言ってた。 なんかこれみよがしに分厚いスクラムの本読んでた。スクラムマスターになるんだって。 なんか夜はそれのコースみたいなのやって大変なんだって。 君情報システムやんな？ 携帯とかWIFIとかセットアップする人やんな？ システム全部外注やんな？ なんでスクラム必要なん？ ここでスクラムの説明をすごく簡単にしときます。 まずそもそもスクラムというのはIT界隈でシステム開発を進める際のお仕事のやり方です。私も詳しく知らないのでラーメン屋で例えます。 ラーメン屋で新しいラーメンを開発するときに、スープの開発、チャーシューの開発、麺の開発、メンマの開発があるとします。 そしてそれぞれ担当者が割り当てられるとします。 スープ担当が開発を始めるとチャーシュー担当はこう言いました。
こんにちは丸山@h13i32maruです。コロナの影響により、昨年からリモートで働き始めました。最近転職して新しい職場になりましたが、こちらもリモートで働いています。同僚もリモートで働く人がほとんどです。 そんなリモートワーク、基本的には最高なのですが、現状「雑談」はオフィスワークより明らかに劣っていると思います。そこで、前職では「帰りの会」という雑談タイムを自分のチームで運用していました。これが結構楽しく満足度も高くて大変良かったです（僕が退職したあとも続いてるらしい）。 残った3名で今もやってます！（笑） いい相談＆雑談時間です— 堀犬 (@horiinu) March 7, 2021 今回はこの「帰りの会」という雑談タイムが何故良かったのか振り返ってみます。結論としては「仕事の話をメインのネタにした」「画面共有や開始時間などの小さな工夫を積み重ねた」という感じです。 ちなみに、今回の
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
DMMを退職しました - アジャイルSEの憂鬱
プロダクト企画にエンジニアを早めに巻き込む（嫌がられずに協力を得る方法） - ykmc09 blog
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s
自由と責任を開発チームにもたらしたら開発速度が上がった話
Webアプリケーションは難しい
毎朝15分以上のデイリースクラムをしてる - Mitsuyuki.Shiiba
スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
(翻訳) ストーリーポイント再考 - forest book
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
Agile and Requirement : アジャイルな要件定義について考える
スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ
人の相談になんてのるな。｜市谷 聡啓 (papanda)
『45歳定年制』？ 進む、人材の新陳代謝（日本テレビ系（NNN）） - Yahoo!ニュース
プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に答える - Qiita
「アジャイル開発」阻む役所の流儀 COCOA失敗招く - 日本経済新聞
仕事納めとスクラムの話 - imog
「帰りの会」というリモート雑談の形 - maru source