【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
AWS JumpStart for NewGradsで、はてな新卒エンジニアがクラウドアーキテクチャ設計に取り組んできた - Hatena Developer Blog
アマゾン ウェブ サービス ジャパン合同会社の主催するAWS JumpStart for NewGradsという新卒向け研修の案内をいただき、id:momochi29とid:arthur-1の2名が参加しました。本エントリでは、このイベントではてなの新卒エンジニアが何を学んできたのかを紹介します。 AWS JumpStart for NewGradsとはどんな研修か アーキテクチャを3日間で検討する 1日目 - 設計の土台となる議論を深めることに集中 2日目 - 各自が素案を作成して比較 3日目 - 実装コストを重視してアーキテクチャを決定 アーキテクチャ設計で工夫したこと 画像をセキュアに配信する リアルタイム性を実現する 研修の振り返り 最後に AWS JumpStart for NewGradsとはどんな研修か AWS JumpStart for NewGradsとは、クラウドアーキ
会社辞めたい小学校校歌(プログラマー分校版)
空のマス目に設計書き込む 1000行超えた関数見つめて 7重if文 書き込めコード 己の手使い関数試験 VSSでファイルロックし繋がり強めよ変わらずの ああ会社辞めたい ああ会社辞めたい小学校～
ネットワークエンジニアとして
◆ ネットワークエンジニアのメモ：ブログ ⇒ iPhone、キャリア契約者数、成功する働き方 ◆ ネットワークエンジニアのランチ：ブログ ⇒ ランチ、ITニュース、Cisco、Network ◆ ネットワークエンジニア 役立つ物理ツール ⇒ 構築作業や保守作業で役立つ物理アイテム ◆ サーバ技術入門：サーバの基礎をはじめから ⇒ インフラエンジニアに役立つサーバ技術解説 ネットワークエンジニアとしての Network Studyでは、これからネットワーク エンジニアになりたいと考えている方や、CCIEレベルのネットワークエンジニア になりたいと考えている方に役立つよう基礎から上級レベルまでNW技術を解説。 Network Studyの内容は、国家資格であるネットワークスペシャリストの取得や CCNA/CCNP/CCIE取得に役立つ内容に仕上げているだけではなく仕事で役立つ ようにCisco
プロデューサ・プロダクトマネージャに頼られるエンジニアについて考える - LiBz Tech Blog
はじめに 社内の会話で一緒にサービスしたいならどんなエンジニア？という話があり、プロデューサ・プロダクトマネージャ目線で欲しいと思うエンジニア像を社内で話していたものを書きます。 サービスを作るフローについて まず「どんなエンジニアが頼られるか？」の前にサービスを作るフローについてまとめます。 ①期初に目標設定 ↓ ②目標を達成するために○○すればいいのでは？という仮説を立てる ↓ ③仮説を検証(企画→開発→テスト→リリース後の分析) ↓ ④成功！ ↓ ⑤目標達成！ そんなうまくいきません・・・ 実際は 仮説・検証を何度も行って、「仮説が正しい！」を繰り返しサービスを成長させていきます。 そのため、検証の数を増やせるエンジニアが頼られるエンジニアになります。 「検証」「仮説は正しい」を多くするためには？ 検証からの仮説は正しいの率を上げる(野球でいう打率) 主に企画時点での規模感の分析など
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
監視 入門 ~ マイクロサービス時代の監視設計