ssmjp 201712 はたのさん祭での「運用自動化、不都合な真実」の発表資料です。 詳細: https://www.opslab.jp/publish/20171212-ssmjp-automation.html (運用設計ラボ合同会社 波田野裕一)
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 本記事について Findy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した内容を元に作成しています。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像
これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。(書いているのは21日です。) 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■:実作業日(問題なければできそうな工数) □:バッファ日(例えば50%の確率で問題おきたときに使う予
システム構築の上流工程強化(非機能要求グレード)紹介ページ 本ページの情報は、2023年8月時点のものです。本事業は終了しているため、お問い合わせには対応できません。 国民生活や社会経済活動における基盤となった情報システムは、「大規模化・複雑化」、「利用の広がり」の点からますます高度化しています。このような高度化に伴い、情報システムの安定的なサービスが求められるようになっており、複雑なシステムを構成する多様なコンポーネントがきちんと連携してそのようなサービスを提供する「システム基盤」の実現が重要になっています。そのためには、提供したいサービスに対応する要求を適切に定義する必要があります。 機能/非機能要求の相違点と課題 システム構築における要求には機能要求と非機能要求があります。このうち、非機能要求については、以下のような要件定義上の課題があります。 非機能要求グレードとは 「非機能要求グ
CTO室 相談室でCARTAの各部署の技術メンター・コーチをしている前田@brtriver です。 自分の仕事内容を説明するのが難しいですが、スタッフエンジニアでいう右腕です! いろんな部署のサポートをしていると開発要望タスクのリストを確認する場面がよくあります。 そして、その中の「優先度」という項目で正しく優先度をつけることができていない現場が多いと感じます。 そこで、今回はどのように「優先度」を考えればよいかについて私自身が意識していることをまとめてみるので、ぜひ一緒に考えてみましょう。 優先度が「高」だらけになってしまう チケット管理において優先度が「高」だらけになってしまう現象を目にしたことはありませんか? チケットは困ってる本人が書くため、基本とその優先度は「高」が多くなります。 チケットに残すために書いたとしても、優先度低いタスクはそもそもやらないという判断されることが多く、そ
「人が増えても速くならない 〜変化を抱擁せよ〜/倉貫義人」 について一部要約しご紹介したいと思い ます。 この書籍で語られている内容は、私がこの業界に従事した当初、いえそれ以前から何度となく言及されつづけていた課題について、非常にわかりやすく言語化されています ビジネス・テックいずれの職種を問わず、プロダクト開発のプランニングに関わる方には是非おすすめしたい内容です もし、この記事で興味を持たれたら是非手にとってみてください。 そしてできるならば、感想戦をできれば幸いです 本書の要点人を増やしたり、プレッシャーをかけても速く作ることはできない。むしろそれは、コミュニケーションコストや技術的負債を蓄積し生産性を低下させてしまう 正確な見積もりと約束をとりつけようとしてはいけない。事業側と開発側が”受発注”関係ではなく、協働の関係を築くこと。「何を作るのか」ではなく、「何を実現したいのか」を
プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。 1. プロジェクト概要1-1. 背景プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。 1-2. ゴールゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。 1-3. 目的プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5
どうも、まさとらん(@0310lan)です! 今回は、ユーザー登録や決済フォームなど、さまざまな機能を搭載できるWebサービスをご紹介します! ドラッグ&ドロップで誰でも簡単にフォームを作成できるノーコードツールで、高度なロジックや他サービスとの連携機能も提供されています。ご興味ある方はぜひ参考にしてください。 【 Feathery 】 ■「Feathery」の使い方! それでは、「Feathery」をどのように使えばよいか詳しく見ていきましょう! サイトにアクセスしたら【Sign up】ボタンをクリックして、無料のユーザー登録をしておきます。 メールアドレスを入力するだけなので簡単です。 登録したメールアドレス宛てに、ログイン用の認証リンクが送付されるので、そのリンクをクリックすればユーザー登録ができます。 最終的に、以下のようなダッシュボード画面が表示されたら準備OKです! この画面か
お知らせ: Web制作の基礎から学べる「Webコーディングスクール」を渋谷で開催します!動画受講も可能です。 Web制作の基礎からJavaScript、AIを活用したコーディングまで学べる、土曜開催のスクールです。動画受講はお好きなときに観られます。詳しくはこちら ChatGPTの回答は間違っている場合があります。おかしいなと思ったら別の方法でも調べてみましょう おかしいと気づけるように、書籍や スクール 等で基礎知識を身につけておきましょう ChatGPTには2023年10月までの知識しかありません。それ以降のことは正しく回答することができません 質問した内容とその回答は、このサーバーやOpenAIのサーバーに一定期間保存される場合があります。企業秘密やプライバシー情報は送信しないでください 1日の利用回数は20回まででお願いします。同一人物と思われる方から大量の利用があった場合、利用を
Translations: Brazilo-Portuguese Chinese (Traditional) Czech Dutch Estonian French Georgian German Greek Hindi Hungarian Indonesion Japanese Lithuanian Polish Portuguese Russian Spanish Ukrainian Uzbek If you want to copy, mirror, translate, or excerpt this document, please see my copying policy. Many project websites link to this document in their sections on how to get help. That's fine, it's th
開発環境の構築をより簡単にしてくれるツール Devbox について紹介しようと思います Devbox とは Devbox とは jetpack.io がオープンソースで開発している、開発環境構築ツールです ローカルの環境を汚すことなく、開発用に必要なパッケージがインストールされた状態で Shell を簡単に作成することができます Devbox をなぜ利用するのか Devbox は Docker コンテナや独自の環境を構築・管理するよりも多くの利点があります チームのための一貫した Shell Devbox の設定ファイルである devbox.json に開発必要なツールを宣言することで、チームメンバー全員が同じ環境で開発をすることができるようになります 環境を汚さず新しいツールを試せる Devbox はローカルとは分離された環境を提供するので、新しいツールを試してみたいといったときにローカ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く