実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経
最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ！ ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、
ITエンジニアと法的要件の考慮 - 勘と経験と読経
XP祭り2016で発表された「巷にはびこる間違ったUX論へのヘイトをぶつける集い」という発表をめぐる一連の議論を読みながら考えた事。ちなみにUXについては門外漢であるし、そこについての意見は無い。ただ、この中で出てくる「UXデザイナーは法律の考慮も行うべきなのか」については異論を唱えたいところ。 UX論は間違っているんじゃなくて時代遅れなんじゃないの？という疑問 - architecture_database XP祭り2016で発表してきたことと「UX論は時代遅れなんじゃないの？」論に対する回答 #xpjug - ミッションたぶんPossible UX論はサービスの設計で役に立たないって結論 - architecture_database もはやユーザー満足度では分からないことを設計に組込む必要があるよね、という話 - architecture_database なお一言断っておくと、「巷
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
もしもソフトウェア開発のPMがTRPGのGMだったら - 勘と経験と読経
妄想妄言の類い。工程の区切りで正気度チェック！という話ではなく。InfoQで「ロールプレイングゲームのダンジョンマスタとして学んだことをアジャイルコーチングに活用する」という記事を読んで考えたことなど。ちなみに「TRPGのGM」は、「テーブルトークロールプレイグゲームのゲームマスター」のこと。 テーブルトークRPG - Wikipedia ゲームマスター/ダンジョンマスターの役割 TRPGのGMの役割は、わたしの理解ではざっとこんな理解である。 物語りの背景と舞台、大まかなシナリオを用意する メンバーの振る舞いに応じて少しずつシナリオを進めて、メンバーと一緒に物語を作り出す メンバーの行動を指示することは出来ないが、舞台設定である程度行動の方向性に影響を与えることはできる 「轟音とともに洞窟の入り口は崩れた岩によって塞がれてしまった。どうやら後戻りはできないようだ」 この「メンバーの行動を
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
