【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション（DX）」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは、要件定義の過程で直面する問題への対応をガイドすることが、ユーザへのよりいっそうの支援策となると考え、「ユーザのための要件定義ガイド(初版)」の内容を一新し、「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」と
プロダクトバックログアイテムの分割方法
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え
ホロラボの社内勉強会で話した資料です。 RSGT2023でも話しました https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17590
みずほフィナンシャルグループ（ＦＧ）が、基幹システムの開発などを担当する人員を、システムの本格稼働後に約６割削減したことが３１日、分かった。今年６回の障害を起こしたみずほのシステムは全体像を把握するのが難しいほど規模が大きく、システムに習熟した人員を削減したことが障害の多発に影響した可能性もある。 みずほＦＧは３１日、金融庁に今年５回目となった８月１９～２０日の障害に関する報告書を提出。この時はみずほ銀行などの営業店と基幹システムをつなぐ機器が故障し、全国の店舗窓口で入出金などができなくなった。
メガベンチャーがデジタルがちょっと得意な中堅企業になる理由～とあるメガベンチャー社員との対話から考える「スタートアップ・ピーターパン現象」～
中野 仁 (AnityA) @Jin_AnityA 長いので少しまとめると... ・ベンチャーは上場前後から人材と文化の変質が起きる ・中間層が厚くなり、そこにいい感じに情報の非対称性を取るのに長けた人材(Taker)が増え始める ・足らない部分の仕組みを人手で回していた有能な善人(Giver)たちが逃げ始める 2022-06-25 19:14:10 中野 仁 (AnityA) @Jin_AnityA ・経営が全体を把握する為に必要な仕組み(ルール・システム)も未成熟な状態から、混乱と停滞が発生しやすい ・結果、仕組み化を備えたエンプラにもならず、ベンチャー的な雰囲気とデジタルが得意な中堅企業として固定化する 2022-06-25 19:15:56 中野 仁 (AnityA) @Jin_AnityA とあるメガベンチャーの文化と人材の会話メモ： ・「成功したら自分の手柄。失敗したら他人のせ
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。まずは、ウォーターフォールモデルとアジャイルにおける品質担保の変化について話します。 セッションの概要説明 高橋寿一氏（以下、高橋）：高橋です。今日は講演というよりは、できればディスカッションみたいな感じにしたいと思っています。「アジャイル開発での品質視点の変化」というところを1時間弱お話しします。 ステレオタイプですが、ウォーターフォールからアジャイルへいったと。みんなハッピーなんですよね。書店に行くと、どんな本を読んでも「アジャイルが素晴らしい、ウォーターフォールじゃない」みたいな。やはりものを作る上でも、もののフレキシブルな使い方という
システムの要件定義とは、そのシステム開発を行う上で実施すべき業務の内容を整理してわかりやすく文書化することです。基本の考え方や要件定義書を作成するまでの進め方、必要な準備について、IT業界経験10年以上のシステムエンジニアが説明します。 システム要件定義とは システムの要件定義とは、システム開発を行う上で実施すべき業務内容をあらかじめ想定し、わかりやすく文書化するプロセスです。 実際にシステム開発プロジェクトを進めていく上で、目的や内容はもちろん、スケジュールや開発予算、開発に関わるメンバーなど、想定しておくべきことはたくさんあります。 こうした各要素をあらかじめ具体的に想定し、文書化しておけば、プロジェクトを計画通りに進められる可能性が高まります。計画通りにプロジェクトが推進できれば、事業を成功に導くことができます。 つまり、要件定義の成否によって、プロジェクトを計画通りに進めることがで
「スクラムフェス仙台」はアジャイルコミュニティの祭典です。初心者からエキスパートまで様々な参加者が集い、学び、楽しむことができます。ここで登壇したのは、岡田謙一朗氏。組織を変革する最初の一歩の道のりをふりかえり、学んできたことを話しました。 Unipos株式会社・エンジニア兼スクラムマスター 岡田謙一朗氏（以下、岡田）：よろしくお願いします。発表の練習を何回かしたのですが、時間がけっこうやばかったので急ぎ気味にやります。「組織を変革する最初の一歩に躓いたけど、それはそれで良かった話」というタイトルで発表させてもらいます。 Unipos株式会社の岡田といいます。「Unipos」というプロダクトを作っているエンジニア兼スクラムマスターです。マネージャーもしています。 最初に、今日の目標を述べさせてください。（目標は）組織やチームに新しいアイデアを持ち込む最初の1人に、ちょっとの勇気をお裾分けす
要求定義と要件定義についての記事というのは需要があるようですね。 検索されるだけなのか？そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。 役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。 ##最近の近況 バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。 ##はじまり はぁ… なんでシステム開発が失敗するんだろう… 仕様の変更が多くて… 言った言ってないのトラブルから避けたい… システム動かしてみても全然使えない… 実は．． 事業運用をオペレーションレベルに展開しないままに、 システム開発をして
「魔法部」 ブランドサイトのつくりかた｜MEFILAS
今回より、Webサイトの制作方法を実際の案件を通してお伝えする「Webサイトのつくりかた」シリーズをスタートします！ Webサイトは目的や狙いによって制作方法はさまざま。いざつくろうとすると... ・制作の進め方がわからない ・企画のアイデアがまとまらない ・どんなデザインが良いか判断できない ・アニメーションが考えられないなど、わからないこともたくさん出てきますよね。 このシリーズでは、そんな「実際どのように制作しているのか」という疑問を、制作を依頼される方・制作を担当される方の参考となるように、弊社の制作実績を通してお伝えしていきたいと思います。 第一回目は、魔法の世界観が魅力的なファッション・雑貨ブランド「魔法部」ブランドサイトのつくりかたをご紹介いたします。 01. 魔法部とは 魔法部 https://www.felissimo.co.jp/mahoubu/ 「魔法部」とは、通販会
【2020年版】ドメイン駆動設計（DDD）初学者へ贈るおすすめ書籍 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。west-cです。 携わっている新規サービスにてドメイン駆動設計（以下、DDD）を取り入れた開発を行っていることから、去年の秋頃からDDDの学習をはじめました。 今回は、私が学習にあたり読んだおすすめ書籍を紹介します。 目次 目次 ドメイン駆動設計とは おすすめ書籍 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 実践ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 おわりに ドメイン駆動設計とは 本題へ入る前に、「そもそもDDDって何？」という方へ3行でとてもざっくりと説明します。 DDDとは、ソフトウェアで問題解決しようとする領域（ドメ
はじめに こんにちは。 株式会社デジサク の多森です。 今回の記事では、要件定義・プロジェクト企画を推進するためのネゴシエーション術について扱っていきます。 ITプロジェクトを推進していて、こんなことを感じた経験はないでしょうか？ 「バラバラな意見・要望を収集できない」 「発言力がある人の影響に負けてしまう」 「いつまでも追加要望が止まらない」 関係者の意見を尊重しつつも優先順位を明確にして、全員で同じ目的に向かってプロジェクト推進するバランス感覚が欲しいと常々感じます。 こんな悩みを解決するために、、 「センスに頼らない！要件定義・プロジェクト企画のネゴシエーション術」 こんなテーマで、様々な関係者とスムーズに調整する考え方を３つの軸（タイプ別・役職別・フェーズ別）で整理しました。 本記事の章立ては以下の通りです。 ーーーーー 企画・要件定義のほとんどは関係者との調整 ポイント①：思考タ
システム障害は2月28日午前に発生した。店舗内外の自行ATMやネットバンキングの「みずほダイレクト」において一部の取引ができなくなった。ATMに関しては、みずほ銀行が保有する約5900台のうち、ピーク時は7割超に相当する4318台に不具合が出た。 さらに、ATMからキャッシュカードや通帳を取り出せなくなる顧客が続出。コールセンターの要員不足により、ATMの脇に設置した電話もかかりづらく、多くの顧客が店舗などで足止めされた。キャッシュカードや通帳が取り出せなくなった事象は累計5244件に及んだ。 取引メインとATMの間口を絞る 一連のシステム障害の引き金を引いたのは、2月28日の定期預金に関するデータ更新作業にある。みずほ銀行は同日、定期預金に絡み、計70万件のデータ更新処理を実行した。定期預金の積み立てなど定例のデータ更新が25万件あったほか、一定期間取引がない顧客を不稼働のステータスに変
本連載では、スピードと品質を両立するためのアジャイルテスティングにおける重要なキーワードである「テストの自動化」について、WebブラウザやAPIレベルのエンドツーエンドテスト（E2Eテスト、この連載でのテスト自動化は主にE2Eテストの自動化を指しています）が求められる時代背景から、戦略や戦術、組織づくり、ノーコード・SaaS型のAIを活用したテスト自動化サービスの進化と具体的な実装、ベストプラクティスを解説します。第1回は、アジャイル開発やDevOpsが当たり前になった時代において求められるテストや品質について、時代背景を追っていきます。 はじめに 技術の進化とともに開発スピードは格段に上がり、システムはより複雑になり、求められる品質も高まっています。アジャイル開発やDevOpsという言葉が一般的になった今、これまで幾度となく議論されてきた「スピードと品質」の問題は、トレードオフではなく、
プロジェクトを機能・ストーリー・タスクに分割する方法と、それぞれの見積もり、優先順位付け、スケジューリングのガイダンスを提供します。 見積もりは細かく細分化するほど精度を上げることができるのは明らかです。しかしその代償として時間がかかります。不正確にすべきではありませんが、見積もりのコストは抑えたいと考えます。 有効な技法として「三点見積り」があります。この見積りは、「最良ケース」「最有力ケース」「最悪ケース」の３つの数値で構成されます。これらの数値は信頼性のより見積もられます。これはPERT法として調べると詳しい情報が得られるでしょう。 しかしながら三点見積りは長期のプロジェクトには有力ですが、プロジェクト内部のマネジメントで使うには精度が悪すぎるため、「ストーリーポイント」を用いるとよいということです。 ユーザー視点での機能であるユーザーストーリーに対し、具体的な時間の工数ではなく、相
Agile Studio プロデューサーの木下です。アジャイル開発をはじめるには、基本的な語彙やプラクティスをチームにいる全員が知ることが大切です。また、アジャイル開発を実践していく上ではスクラムのみ...
失敗してしまう個人開発 趣味の個人開発で過去にいくつものプロダクトを作ってきました。 ユーザがたくさんついて、ゆくゆくは収益化したいななどと思いながら作っていましたが、残念ながらどれも一瞬だけ少人数の人に使われるだけで、そのさきを描けずにいました。 「いいアイディアが思いついたからいきなり作り始めた」とか「顧客が不在のままとにかく作ってしまった」とかは個人開発でやりがちです。最初にアイディアや顧客について詰めていなかったために誰にも使われないで終わってしまう、というのはよくある失敗なのではないかと思っています。 趣味の開発や、技術力向上という意味ではそれでもいいのですが、あわよくばビジネスにしていきたいという思いがある時は一旦考え直す必要があるかもしれません。 誰も課題だと感じていない領域を攻めていたり、自分の解決策がユーザにとってお金を払いたいほど魅力的でない場合はユーザを定着させること
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察� ～Text-to-MusicとText-To-ImageかつImage-to-Musicを例に～
サービスの詳細 日本でも2018年頃に画面遷移図をテキストベースで作成できるguiflowが有名になりましたが、今回のサービスは、その類似サービスになります。 Quick Diagramは、普段からPower Pointやエクセルを利用していないプロダクトマネージャーやテクニカルディレクターやにオススメのサービスです。 サービスを設計したり要件定義を作成する際に必要になる、シーケンス図やクラス図、画面遷移図の作成、修正を簡単に実施できるサービスです。 早速、サービスの詳細を確認していきましょう。 アカウント作成し、ログインするとダッシュボードが表示されます。 左上から、作成したい図を選択します。 今回は、フローチャートを選択しました。 左側にQuick Diagramが指定する記法でテキストを記述していきます。 記法はこちらのドキュメントを参照してください。 記法の大まかな説明すると、それ
ラボラトリーオートメーションのためのソフトウェア思想教育（非プログラマ―が知っておくべきプログラミングの本質）
非プログラマ―が知っておくべきプログラミングの本質 https://laboratoryautomation.connpass.com/event/224912/ Read less
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
アジャイル開発における要件定義 〜DXプロダクト開発における要件定義の理解を深める〜 | TC3株式会社｜GIG INNOVATED.
1. はじめに 前回の「アジャイル開発プロセスの本質」（前編・後編）では、ソフトウェア・エンジニアリングの基本に従いアジャイル開発プロセスを設計していくことにより、アジャイル開発プロセスの進め方、実施する活動、作成する成果物についてなぜそうなっているのかを知り、アジャイル開発プロセスへの理解を深めました。 本記事ではその続編として、DX（デジタルトランスフォーメーション）の文脈におけるプロダクトをアジャイルに開発していくにあたり、特に要求プロセス部分に絞ってソフトウェア・エンジニアリングの基本とアジャイル開発プロセスでの対応をより詳細に解説することで、DXプロダクト開発における要件定義の理解を深めるということを目的としています。 本記事のタイトルにある「要件定義」という言葉はフェーズではなく、要求を決めるまでの活動の分類＝要求プロセスという意味で使っています。この使い方の違いについては、前
デジタル庁は、ダッシュボード開発において品質向上、および設計の効率化に貢献するため、実践ガイドブックとダッシュボード開発ツールのPowerBIのチャート・コンポーネントライブラリを公開します。 資料のダウンロードから取得してください。 公開の目的デジタル庁は、データと根拠に基づいた政策判断・効果の可視化を日本政府内で推進を先導する役割を担っています。その役割の一端を担い、行政や公共機関、民間企業などに従事する方が、わかりやすいダッシュボードを効率的に開発できるように、実践ガイドブック等を提供しています。データをわかりやすく可視化できるようにすることで、多くの関係者間で正しい共通認識を持ち、意思決定の質を向上させ、より良い行動に繋げられるようになることを目的にしています。 実践ガイドブックは、デジタル庁で実践してきた政策データダッシュボードの作成時の知見に加え、行政職員や民間有識者のダッシュ
サイバーエージェントのフィーチャーフラグを活用した高速開発 | CyberAgent Developers Blog
3月24日、サイバーエージェントのエンジニア・クリエイターによる技術カンファレンス「CyberAgent Developer Conference2022」を開催しました。本記事では「サイバーエージェントのフィーチャーフラグを活用した高速開発」の様子をお届けします。 目次 ■フィーチャーフラグと開発 ■フィーチャーフラグのメリット、デメリット ■社内フィーチャーフラグ基盤「Bucketeer」 ■「Bucketeer」のユースケース ■「ABEMA」におけるフィーチャーフラグの活用方法 ■フィーチャーフラグを管理する「Flagfit」 ■まとめ ■フィーチャーフラグと開発 フィーチャーフラグとは、静的または動的に機能のON/OFFを切り替える手法で、コードで表すと以下のようになります。 もしフィーチャーフラグがtrueであれば何かをして、そうでなければ別の何かを行なうといったコードを書くこ
アマゾンのジェフ・ベゾス会長。 Amazon; Clodagh Kilcoyne/Reuters; Samantha Lee/Business Insider アマゾンがイギリスにあるドローン配送チームの100人以上の従業員を一時解雇した、とワイアードが報じた。 アマゾンのプライム・エア・チームは、2016年からドローンによる配送に取り組んできた。 プライム・エアの元従業員は、この部門は2019年から崩壊し始めたとワイアードに語っている。 ワイアード（Wired）によると、アマゾン（Amazon）はイギリスにあるプライム・エアのドローン配送チームで100人以上の従業員を一時解雇し、その規模を大幅に縮小したという。 同部門が目指していたのは、ドローンによる配送を実現させることだった。アマゾンでは2016年からイギリスでプライム・エア・ドローンのテストを行っている。 ワイアードが話を聞いたプラ
デジタル社会推進標準ガイドライン｜デジタル庁
デジタル社会を実現するためには、「共通ルール」の下で関係者が協働し、価値を生み出すことが重要です。 デジタル社会推進標準ガイドライン群は、サービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理についての手続・手順や、各種技術標準等に関する共通ルールや参考ドキュメントをまとめたものです。 各ドキュメントの位置づけには、次の2種類が存在します。 標準ガイドライン（Normative）：政府情報システムの整備及び管理に関するルールとして順守する内容を定めたドキュメント実践ガイドブック（Informative）：参考とするドキュメントこれまでは、「デジタル・ガバメント推進標準ガイドライン群」という名称で各種ガイドラインを策定しておりましたが、デジタル庁として政府内部だけでなく社会全体のデジタル化を推進するという観点から、これらのドキュメント体系の名称について「デジタル社会推進標準ガイド
翔泳社のアジャイル・スクラム関連書
ソフトウェア開発の現場で用いられている「アジャイル」の考え方や手法が、組織運営などのビジネス現場でも注目されています。 これから「アジャイル」や「スクラム」を導入しようと考えている方、もっとうまく活用したいと考えている方におすすめの書籍を紹介します。 『アジャイル開発とスクラム 第2版』著者 平鍋健児氏からのメッセージ 日本でアジャイル、スクラムの導入が進んでいる2021年、みなさんの現場は元気ですか？ アジャイルをやれば、スクラムをやればうまくいく、なんてことはまったくなく、日々自分たちの現場で起こるのは、一つ一つが個別具体の問題であり、「あなた」が自分で考えていかないといけない、という宿命が白日に晒されたのです。この宿命に最初に気づいたとき、「聞いてたのと違う」と思うかもしれません。そこが最初の起点になり、みんな道を歩むのです。 このラインナップは、その道々での問題を解決していくための
2021.02.02 働き方 ゲームチーム 2020年９月に行われたゲーム制作者向けのカンファレンス『CEDEC2020』で、『龍が如くスタジオ』のQAエンジニアが発表した「全自動バグ取りシステム」が大きな話題になった。 『龍が如く』といえば、巨大歓楽街に生きる熱い男たちの生き様をドラマティックに描く大人のためのエンタテインメント作品。2005年の発売開始から15周年を迎えるセガの人気シリーズで、毎年のように新作タイトルがリリースされることでも知られている。 『龍が如く７ 光と闇の行方』より @SEGA シナリオのスケールもゲームシステムもタイトルを追うごとに巨大になる中、『龍が如くスタジオ』ではQAエンジニア（※）の開発する「全自動でテストやデバッグを行うシステム」を使い、開発効率や品質の向上につなげているという。 ※QAエンジニアとは QAは 「Quality Assurance」の略
皆さんは技術的負債や○○コードとか、○○な設計に苦しめられていませんか？ ※○○には食事時などに見るべきでは無い、あまり綺麗ではないお言葉が入ります 技術的負債を生み出す背景には組織・人・金、など、技術では対処しきれない問題が多く含まれますが、技術的要因ももちろん無視できません。 今回は「知識の露出・共有」について説明します。ここで覚えて欲しいことは、知識とその露出と共有についてです。 技術書典7では東京ラビットハウスというサークルで「TypeScriptとクリーンアーキテクチャで、最高の開発者体験をしよう！」という本を出す予定です。ご興味有ればサークルチェックお願いします。 分かりにくい、ここ間違ってないか？など何かしらツッコミや感想がありましたら是非お気軽コメントなりいただければ幸いです。 対象読者 技術的負債に苦しみたくない人。密結合が大体良くないこと位は知っていても、なぜ密結合が良
ある日の我が家 ワイ「う〜ん・・・」 ワイ「どないしたら実現できるんやろなぁ・・・」 娘（8歳）「パパ、どうしたの？」 ワイ「おぉ、娘ちゃん」 ワイ「いやぁ」 ワイ「実は、面白いアイディアを思いついてな？」 娘「へぇ、どんなアイディア？」 ワイ「AIと連携した技術記事投稿サイトがあったら面白いんちゃうかな、って」 娘「何だか、フワッとしたアイディアだね」 娘「よく分かんないけど、パパが自分で作ってみたら？」 ワイ「いや、ワイはフロントエンドしかできへんから」 ワイ「記事投稿サイトはちょっと、作る自信ないわ」 ワイ「サーバサイドとか、データベースとか」 ワイ「よう分からんし」 娘「じゃあ、私が作ってあげるから」 娘「要件を教えてよ」 ワイ「AIがいい感じに記事をアレしてくれるサイトや」 娘「いや、だからフワッとしすぎなんだって」 娘「そのサイトを作りたいと思ってるのは、パパなんだからさ──」
Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you. By Jeremiah Lee Sunday, April 19, 2020 • Listen • Watch • En français • 日本語で • Português (Brasil) About the cover illustration Of all the allures of startup culture, few are more desireable than the speed and nimbleness of a small team. Maintaining that feeling as a company grows is a challenge. In 2012, Spotify sha
（著者提供） 「ツーブロック」とは、上図のように、刈り上げた下部分と上部分を繋げずに、髪のブロックが二つに分かれる状態のことを指します。耳上の部分でも後頭部でも、上下が分かれていればツーブロックと呼びます。分かれた上の髪の部分は、下の部分よりも長くなります。 ツーブロックは、むしろ清潔感アップ 「ツーブロック」は「耳周り」や「襟足」を短く刈り上げるため、清潔感のある印象になります。そのため、ビジネスヘアにも用いられますし、昨今のメンズヘアに定着しています。 （著者提供） ちなみに、Twitter上には「現天皇陛下も、昭和天皇もツーブロックじゃん」などと指摘する沢山のツイートと画像が投稿されています。つまり、それほどフォーマルなヘアスタイルにも用いられているのです。 そのため、この見た目が「校則違反」と言われても、我々美容師や理容師には理解し難いのです。「むしろ推奨するべきでは？」と考えてい
今日から使える「実例マッピング」 / How to Use Example Mapping #pmconf2022
Product Manager Conference 2022での登壇資料です！
プロダクトエンジニアリング部のカマトです。 普段はマーケティング・エンジニアとして、LIFULL HOME'SでLINEやメールを活用したサービスの開発に従事しています。 今回は業務でシステムの刷新を行う中で、アーキテクトにクリーンアーキテクチャを採用し初めて経験しましたのでこちらについてお話しをさせていただきます。 新しいアーキテクトに触れるときは、このレイヤーは何を担当しどのような概念でどのような機能を持たせればいいのか？と理解するをするまでいつも苦戦するのですが、クリーンアーキテクチャは特に登場人物が多く今まで以上に大変でした。 このクリーンアーキテクチャの処理の流れを日常のものに置き換えれば、別な視点で理解が深まるのではと考え、各レイヤーの概念を定食屋のフローに落とし込んで表現をし振り返りをしてみようと思います。 参考にしたイメージ図に沿ってのレイヤーと概念ですので、これにそってな
チュートリアルでDDD体験: ドメインモデルの成長を紹介 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」 僕もこのドメインで振る舞い中心のモデリングをしてみた。実装は可能なモデルを書いてみましたが、今回は細かい実装の話はありません。 イベントを抽出まずイベント(起こった事実)から考えました。日々の勤怠で何が起きるのだろう。出勤したり退勤したり休憩したりと打刻するのは間違いない。システムが何か命令(コマンド)を受理したらこういうイベントが発生するはず。 「出勤した」イベントには、誰がいつ出勤したかを説明する事実が記載されている。「退勤した」や「休憩を開始した」や「休憩を終了した」なども同じ。あと、打刻間違いの修正もあるので「打刻を修正した」もある。ちょっと荒削りだがこんな印象。 出勤した 退勤した 休憩を開始した 休憩を終了した 打刻を修正した ちなみに
私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます：「訴えてやる！」の前に読む IT訴訟 徹底解説（88）（1/5 ページ） 連載目次 この連載を始めて、7年になる。長くご愛読いただいている読者の皆さまに感謝の念が絶えない。このように長くIT紛争を見続けていると、同じような問題、同じような言葉に何度となくぶつかることがある。街中にある主要な交差点のように、気が付くとその場に立っていて「さて今日はどの方向へ曲がればいいか」と考える場所。そんな言葉である。 「契約の目的とシステムの要件」――IT紛争の勉強や著述などをしていると、いつもこの言葉にぶつかる。「定義されていない要件であっても、それなしには契約の目的を達成できないものであれば、事実上定義されていたと考えなければならない」「たとえ要件通りでも、契約の目的に資することのないシステムを作れば、債務不履行に問われる危険も
システム開発の上流工程である要件定義では、顧客が抱える課題に対してどのようなシステムを作るのかを概要レベルで決定する。 要件定義が必要なのは「作ったはいいが使えないシステム」という状況を防ぐためで、システム開発におけるW...
アジャイルの対義語はウォーターフォールではなく未来予知だと思っている - 下林明正のブログ
「アジャイルの対義語はウォーターフォールではありません」というのはよく聞く話だけど、じゃあ何なのか？というと、あまり聞くことはないように感じる。 自分は、アジャイルの対義語は未来予知だと思っている。 なぜなら、もし未来予知ができるのならアジャイルである必要は全く無くなるから。 未来予知に基づいて、一切のムダがない完璧な計画を立てればいい。 そういう意味では、変更の余地が無い巨大なウォーターフォールは未来予知的で、アジャイルの対極にあると思う。 でも実際は、未来を予知することは今の僕らにはできない。台風の進路でさえ、予想することしかできていない。遠い未来ほど曖昧だ。 じゃあ、どうせ未来は分からないのだから計画を立てなくて良いのか？というと、そうではない。台風の進路を予知できなくても、予想することはできている。予想することで事前に備えることができるし、予想のモデルを修正して精度を上げていくこと
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザのための要件定義ガイド 第2版 | アーカイブ | IPA 独立行政法人 情報処理推進機構
ソフトウェア開発って なにか？を学ぶ勉強会
システム担当者を６割削減 みずほ、障害多発に影響か：東京新聞 TOKYO Web
「旧来のテスト担当者の仕事は、たぶんどんどん減っていく」 アジャイルへの移行に必要な品質向上の定義
システムの要件定義とは 進め方や必要な準備をわかりやすく解説
組織を変えようとしてメンバーに言われた「働くなら他のチームがいい」 スクラムマスターが盛大な躓きの中で見つけた光明
要求定義と要件定義の違いを考える - Qiita
要件定義・プロジェクト企画に必要なネゴシエーションをロジカルに学ぶ記事 - Qiita
みずほ銀行システム障害の全容、データ更新のオーバーフローが発端に
なぜテスト自動化は当たり前にならないのか？ アジャイル・DevOps時代のスピードと品質の考え方
【アジャイル】書籍「Clean Agile」より「小規模開発のアジャイルプラクティス」
アジャイルプラクティスマップを公開しました | Agile Studio
リーンスタートアップで個人開発の成功率を上げる - Qiita
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
要件定義に必要なフロー図をテキスト入力だけで作成できる【Quick Diagram】
アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
ダッシュボードデザインの実践ガイドブックとチャート・コンポーネントライブラリ（ベータ版）｜デジタル庁
アマゾン、ドローン配送開発チームを大量解雇…元従業員｢このプロジェクトは誇大広告だった｣
『龍が如く』シリーズはなぜ業界異例の“爆速リリース体制”を実現できる？ 全自動バグ取りシステムを開発するQAエンジニアに聞く - エンジニアtype | 転職type
Webサイトリニューアルの成否を分ける「要件定義」のプロセスとポイントを徹底解説 | 【レポート】Web担当者Forumミーティング 2019 Autumn
知識の露出・共有を適切にしてクリーンな設計をしよう - Qiita
なぜ顧客は「本当に欲しいもの」を言ってくれないのか？ - Qiita
Spotify’s Failed #SquadGoals
「ツーブロックというのはそもそも…」現役美容師が解説する、ツーブロック禁止の学校が“勘違い”していること | 文春オンライン
クリーンアーキテクチャの各概念を定食屋で表現する - LIFULL Creators Blog
集約はイベントから考えると考えやすい｜かとじゅん(j5ik2o)
私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます
要件定義における成果物一覧と書き方（要件定義書サンプルあり） | 若手エンジニアの羅針盤
arisa0.st.coresv.net
news.tv-asahi.co.jp
www.okinawatimes.co.jp
note.com/try_nestate
gahalog.2chblog.jp
yoko1.ub.geo.jp