最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に

最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作

はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい

これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ

はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間

「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要

<追記> 追加記事を書きましたhttp://getlife.hateblo.jp/entry/2013/12/07/034949 エクセルでできることができない何百万のシステム・・ 多分現場の人かな。往々にして、システム導入を決定したトップの目的が現場に伝わらず、既存ツールとの差だけが目につくってことはよくあるし。ま、一部業務をexcelで残すみたいに調整すればいいんじゃないかな。 オッサン、こういうシステムネタ好きです。昔高度情報技術者試験を受けた時を思い出すなあ。 大体、仕事やっているとこの手の「今やっている仕事と違う～」だとか、「役員はシステム導入ばっかり言って現場をわかってない」とかそんな揉め事ばかり。 まあ、そういう揉め事を丸め込む納得できるよう調整するのがオッサンの仕事なんですけどね。 本当にやりたいことを見つける システムの要件定義のキモは 必要なこと やりたいこと やらない

実際に、要求仕様から状態遷移表を作成するプロセスを紹介する。モデリングを行いながら、要求仕様書で定義されていない曖昧な部分を検討し、明確化。上流工程の段階でモデルを洗練しておくことで、無駄のない最適なソースコードを作成できる。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。 こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。 さて、前回は“なぜ状態遷移表を使うと、品質の良い開発ができるのか”を紹介しました。今回は「状態遷移表を使用した要求分析モデル」をテーマに、具体的に要求仕様から状態遷移表を

倉業サービスがランサム感染で30万人超の情報漏洩の恐れ、サーバーの脆弱性突かれる 2024.12.20

設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一

はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし

情報システムの調達におけるRFP（提案依頼書）の必要性は，ここ数年でかなり認知度が高まっている。以前はRFPを作らないユーザーも多かったが，厳しい経済状況の中，システム投資に慎重になっているユーザーにとって，RFPを作ることは不可欠になっている。本連載では，筆者が実際に経験したRFP作成・活用の現場の情報を基に，すぐに役立つ実践的な情報を提供していく。 なお，RFPの初歩から知りたいという方は，「RFP＆提案書完全マニュアル」（日経BP社）も併せて読んでみてほしい。 ■趣旨（目的・背景・狙い）」の実践的なまとめ方 趣旨はRFPの「ミッション・ステートメント」 「目的・背景・狙い」とは何か？ 趣旨をつかむための「ネタ」とは？ ケーススタディ：ガソリンスタンド会社の顧客情報システム 趣旨の具体的な書き方の例 ■業務要求とアウトプット RFPの基本構造 RFPにおける業務要求の洗い出しの目的とは

他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ

分量がある文書を作成する際には、文書全体の「アウトライン（骨格、構成）」をきちんと作り上げてから内容を記述する必要があります。今回は、「読みやすく分かりやすい提案書」にするアウトラインの作成方法について紹介します。 読みやすい文書は「階層構造」をしている 読みやすい、分かりやすい文書は、全体が階層構造になっています。文書は、一般的に下記のような階層で構成されています。 大見出し（章） 中見出し（節） 小見出し（項） 階層構造は、複雑で大量の情報を含んだ文書の内容を、分類・整理するために必要不可欠です。階層化した文書は、各トピックで記述される範囲が決まっているため、焦点を絞って読むことができます。このことは、読者の理解を大いに助けます。 階層構造の方法について、順を追ってみていきましょう。まず「大見出し」の層に分割します。その後に各「大見出し」を「中見出し」の層に、さらに必要であれば「中見出

要件管理をRedmineやTrac上で試しているが、しっくりこない原因をメモ。 【元ネタ】 チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11) チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索 RedmineへScrumのアイデアを注入: プログラマの思索 まちゅさんは、「チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)」で下記のようなコメントを残している。 TiDD は開発プロセス全体を網羅するものではない。開発プロセスを補完するもの。 * チケットの粒度が細かいことと、構成管理ツールと密接な関係があることから、アウトプットが明確な領域に適用しやすい。 * 要件定義な

要件を記述する際は，自然言語の文章だけで表現するのではなく，モデリング手法を活用するとよい。それにより，「要件の網羅性を確認しやすくなる」「記述のあいまいさを抑えられる」「要件の論理性，整合性を維持できる」「ビジュアルで視覚的に理解しやすくなる」という効果が期待できる（図4）。 ただし，形式化されたダイアグラムの情報だけでは詳細な要件を表現し切れないこともある。ダイアグラムと文章を併用し，相互に補完し合うようにするのが現実解だといえよう。適用に際しては，文章に慣れているユーザーや，初めてそのモデルに接するメンバーに対する配慮が求められる。戸惑うことなくモデルを取り入れられるよう，理解を助ける説明資料を準備し，説明会を開催するとよい。 ビジネス要件定義に使えるダイアグラム 現在，システム構築で使用されるモデルは，いわゆるUML（Unified Modeling Language）で表現された

文：Geoffrey James（Special to BNET） 翻訳校正：村上雅章・野崎裕子 2009-07-14 08:00 大きな契約を締結するにはたいていの場合、提案書を書く必要があるはずだ。筆者は以前に、営業チームに対する提案書作成支援という分野における世界的な第一人者とされているTom Sant氏と話す機会があった。そこで本記事では、同氏による「説得力ある提案書」を書くためのルールを10個紹介する。 ルール＃1：何かを売り込むための文書として提案書を書く。提案書を情報の羅列だけで終わらせてはいけない。そうではなく、問題／機会を定義し、実現可能な解決策／計画を提示するのである。 ルール＃2：顧客にあなたのことを知ってもらう。意志決定に携わる人が、あなたのことを信用できる業者だと判断しない限り、あなたの提案書はそのまま円筒型のファイルキャビネットに収納されることになるだろう（早い

思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。