Scrum Fest Fukuoka 2025
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
Scrum Fest Fukuoka 2025
非エンジニアだからこそ要求定義と要件定義は極める[サンプルフォーマットあり]｜すぅ|PM
「あれ？思っていたものと全然違うな……」 「すみません。そもそもこの機能がないと業務が回りません。」 「・・・今言われても・・・」 こういった言葉は、プロジェクト後半やリリース後にたびたび聞かれるものです。一番テンション下がる瞬間ですね。笑 こうした状況になる原因のほとんどは、要件定義の過程でしっかりと機能や仕様、目的が固められていなかったからです。 特に非エンジニアの方であれば、用語や技術面でつまづくことも多く、開発サイドとのコミュニケーションの齟齬が起こりやすくなります。そうならないようにするためにも、要求定義と要件定義の流れと進め方、さらに注意点をしっかり押さえておきましょう。 この記事を読んでほしい人 ・初めてシステム開発やツール導入のプロジェクトを担当する方 ・非エンジニアで、ITプロジェクトの進め方に不安を感じている方 ・要件定義や要求定義の違いがよくわからない方 ・ベンダーに
![非エンジニアだからこそ要求定義と要件定義は極める[サンプルフォーマットあり]｜すぅ|PM](https://cdn-ak-scissors.b.st-hatena.com/image/square/8d73c3e5608edb1f0382a665b61c5287630ce490/height=288;version=1;width=512/https%3A%2F%2Fassets.st-note.com%2Fproduction%2Fuploads%2Fimages%2F172496252%2Frectangle_large_type_2_1ba5462da745a7c474cc41efaa7e92bc.png%3Ffit%3Dbounds%26quality%3D85%26width%3D1280)
見積り、計画の考え方や手法についてビープラウドの場合を紹介します/ introduce-the-concept-and-method-of-estimation-and-planning-in-the-case-of-BeProud
2025年2月18日(火)に開催されたBPStudy#210〜見積りと計画について学ぼう( https://bpstudy.connpass.com/event/344470/ ) の登壇資料です。
判断と決断の違いと決断のコツ - そーだいなるらくがき帳
判断と決断の話の違いはこのツイートの通り。 判断の話で言うとぼくはそーだいさんがしてくれた「判断と決断は違う」という話がだいぶ実になっていて、「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなければならないのは決断」という話をかなり大事にしている— しんぺいくんさん (@shinpei0213) 2021年12月10日 決断のコツ 結論から言えば、決断のコツは失敗できるようにすることだ。 失敗できる状態なら決断することができる。 そして素早くアクションして、失敗のフィードバックを受け取ることで新しい決断をすることができる。 そーだいさんがぼくに教えてくれた二大大事なこと「判断と決断は違う」と「ロールバック可能なことはどんどん試せばいい、ロールバックが難しいことは慎重に」です— しんぺいくんさん (@shinpei
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
Security Engineering - A Guide to Building Dependable Distributed Systems
I've written a third edition of Security Engineering. The e-book version is available now for $44 from Wiley and Amazon; paper copies are available from Amazon here for delivery in the USA and here for the UK. You can also download the chapters for free here: Frontmatter and Preface Chapter 1: What is Security Engineering? Chapter 2: Who is the Opponent? Chapter 3: Psychology and Usability Chapter
ウォーターフォールの反省とアジャイルの成功に必要なもの - Qiita
この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します 極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです 言いたいこと 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負契約にある 請負契約で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき 競争に勝つためには内製化は進む(でも内製化はとても難しい) ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」 目次 用語 ウォーターフォールは本当に諸悪の根源か？ 「ウォーターフォール＝諸悪の根源」という誤解 問題の原因は請負契約 なぜ請負契約は失敗しやすいのか？ ベンダーは「システム開発だけ
相手に「曖昧なフィードバック」をしていませんか？ オウンドメディア記事を制作会社と円滑に進めるコツ【前編 / 企画提案〜構成編】 - はてなビジネスブログ
オウンドメディアの運用は、自社だけでなく外部の制作会社にコンテンツ制作をお願いする（外注する）ケースも少なくありません。 ですが、記事制作をお願いしたものの「思い描いていたアウトプットと違う」「パートナーへ適切な指示ができているかわからない」と悩んだり不安を持ったりしたことがある人もいるのではないでしょうか。 特にオウンドメディアの担当者はライティングや編集未経験にも関わらず、記事の企画や内容をジャッジする編集長ポジションに就くこともめずらしくありません（オウンドメディアディレクターやコンテンツディレクター、といったポジションの方が記事の品質管理を担うケースもあります）。 そこで本記事では、主に編集プロダクションなどのコンテンツ制作パートナーとの適切な付き合い方の理解が深まるよう、はてなで公開中の「オウンドメディア制作パートナーとの付き合い方マニュアル」の内容を一部抜粋・編集し紹介します。
プロマネの右腕（IT編以外）
新しく企画担当になった人や新しく現場のリーダーになった人たちのための、 これから実践的なプロジェクトマネジメントをご一緒に学んでいただける番組です。
デザイナーとコーダーと開発PMを経験したからこそ、仕様の書き方が気になる話。 - Goodpatch Tech Blog
プロジェクトマネージャー（以下PM）のchakiです。私はデザイナーとコーダーを経験した後、PM（設計書の記載までを担当することの多い、開発PM）へキャリアチェンジしました。 サービスのシステム開発を行う場合、エンジニアはデザイナーから提供される表層デザインを理解した上で、基本設計書や画面設計書を書き起こします。その際にデザイナーからこんな情報も提供してもらえたらスムーズだなと感じるポイントがあるので、ご紹介していきたいと思います。 デザイナーが作成する説明（ASIS） エンジニア観点で考えること 共通ヘッダー キーワード検索 カテゴリ情報 製品一覧と検索数 おすすめ順（ソート） カテゴリ毎の製品一覧 もっと見る エンジニア観点まとめ デザイナーが作成する説明（TOBE） キーワード検索 カテゴリ情報 カテゴリ毎の製品一覧 まとめ デザイナーが作成する説明（ASIS） 今となってはもう記憶
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
GitHub - yoshi389111/kinokobooks: 「きのこ本」を勝手に電子書籍化
通称「きのこ本」とよばれるオライリー発行の書籍群があります。 これらの書籍は CC-by-3.0 などでライセンスされており、著者名を明記すればコピー/配布や改変が自由にできます（商用利用も可能）。 そこで、勝手に電子書籍（非公式版）を作っています。 再利用しやすいように元データもマークダウン形式で置いてあるので、ライセンスの範囲内でご自由にご利用ください。ただ、標準のマークダウン書式ではなく pandoc の拡張書式を使っているところもあるので、pandoc でお好みの形式に変換してから使うと良いかと思います。 また、zenn のサイトで同じ内容を公開していますので、見やすい方をお使いください（zenn では、章数の関係で日本語版での追加分は別のブック扱いになっています）。 プログラマが知るべき 97 のこと【web】/【 epub 】 ソフトウェアアーキテクトが知るべき 97 のこと【
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
会議中に発言してもらえない原因は、マネージャーの私にあった - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに チームのメンバー皆に意見を出してもらいたいような会議をすることはよくあると思います。 本稿は、そういう時に積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。 チームの皆に意見を出してもらいたい会議とは いろいろあると思いますが、以下に2つの例を挙げます。 UXレビュー 私のチームでは、開発中のプロダクトに対する改善点を皆で挙げるという活動を行っています。 チーム内では「UXレビュー」と呼んでいます。 具体的には、開発メンバーが開発中のプロダクトを実際にユーザーがよく使うユースケースでどんな体験をするのかを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践セキュリティ監視基盤構築
GitHub - Novatics/awesome-podcasts-tech: This list has awesome podcasts to listen in Portuguese, about technology such as programming languages, database, methodologies and community!
GitHub - comunidad-tecnologica/awesome-spanish-slack-dev-groups: Una lista de grupos de Slack en español para desarrolladores / A list of awesome Slack groups in Spanish for developers
GitHub - 01walid/awesome-arabic: A curated list of awesome projects and dev/design resources for supporting Arabic computational needs.
作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era
yoshi389111さんの本一覧
