綺麗なだけじゃ意味がない！ディレクターが見落としがちな仕様書作成の４ポイント : LINE Corporation ディレクターブログ
こんにちは。ウェブサービス本部の河野です。 ディレクターの業務の重要なものの一つに、仕様をまとめたりドキュメントを作る業務があります。限られた時間の中でシステムを開発しなければならない際に、どのようなドキュメントをどこまで作成するか悩むことも多いかと思います。 そこで今回はディレクターがドキュメントを作成する際の心がけやポイントについて考えてみたいと思います。 １．ドキュメントを作ることが目的とならないようにする 当たり前のことですが、一番重要なのは進めているシステム開発が納期通りに不具合なくリリースできることです。仕様をメンバーに理解してもらうことが第一で、その手段としてドキュメントがあるという優先度を間違えないようにしましょう。 きちんとしたドキュメントの作成には時間が掛かり、変更時の更新にも同じく時間がかかります。また、更新をせず情報が古いままの場合、開発メンバーがそれを最新バージョ
「WBSでプロジェクトを成功させる」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
WBSでプロジェクトを成功させる（6）： 上手なプロジェクトの進ちょく管理とは？ 最終回となる今回は、これまで学んできたWBSを活用したプロジェクトの進ちょく管理手法を取り上げる。（2010/9/24） WBSでプロジェクトを成功させる（5）： 良いとこ取りの「ハイブリッド型」 今回は、これまでに取り上げてきた「作業分解型」WBSおよび「成果物分解型」WBSの双方を良いとこ取りした「ハイブリッド型」WBSを解説する。（2010/8/2） WBSでプロジェクトを成功させる（4）： “成果物に分解するWBS”を習得せよ WBSの要素分解の1パターンである「作業に分解」について前回解説した。今回はもう1つのパターンである「成果物に分解」を詳しく解説する。（2010/6/23） WBSでプロジェクトを成功させる（3）： “作業に分解するWBS”を極める WBSの要素分解には、「作業に分解」するパタ
プロジェクトが頓挫したので、18億円請求します
プロジェクトが頓挫したので、18億円請求します：「訴えてやる！」の前に読む IT訴訟 徹底解説（35）（1/3 ページ） IT紛争解決の専門家 細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「基本契約」と「フェーズごとの個別契約」を結んでいたプロジェクトが頓挫した場合の支払いについて、判例を基に解説する。 連載目次 契約を「基本」と「個別」に分けるのはIT開発の主流 IT開発プロジェクトでは「基本契約」と「個別契約」に分けて契約を取り交わすことがよく行われる。 基本契約には費用やスケジュール、成果物の詳細は記さず、とにかく「開発全体を受注者であるベンダーに任せる」ことを記して締結する。 個別契約では、基本契約で記した作業を分割し、おのおのの「費用」「成果物」「詳細なスケジュール」などを決める。ウオーターフォール型の開発であれば、「要件定義」「設計」「
ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門
ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門：プロジェクト成功確率向上の近道とは？（1）（1/2 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 連載目次 はじめに 本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。 筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
使えないシステムをなくすBABOKとは？
使えないシステムをなくすBABOKとは？：BABOK 2.0を読んでみよう（1）（1/3 ページ） 2009年3月末に「Business Analysis Body Of Knowledge（BABOK）」のバージョン2.0が、International Institute of Business Analysis（IIBA）からリリースされました。 本連載では、BABOKバージョン2.0の概要を紹介しながら、いま注目を集めている超上流のアプローチ、ビジネスアナリシスがどのようなものであるかを見ていきます。 “使えないシステム”を作っていませんか？ せっかく高いお金を払って開発したシステムが、とても使いづらかったり現場の業務にマッチしなかったりで、“現場で使ってもらえない”というケースがよくあります。 これではユーザーにとっては無駄な投資となり、もちろん大変な損失になります。システム開発し
要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション
要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要アクション：明日から使えるシステム開発プロジェクトの進め方 再入門（2） 本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、要件定義の準備作業について解説する。要件定義をスムーズにこなすためには作業に着手する前に綿密な計画を立てる必要がある。 連載目次 要件定義へ拙速に突入してはいけない システム開発プロジェクトの進め方をあらためて解説する本連載。前回の「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」では、今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介した。今回からプロジェクトの進め方についてから具体的なノウハ
要件定義をうまくこなすためのポイント――要件定義の完了条件と要求の引き出し方
要件定義をうまくこなすためのポイント――要件定義の完了条件と要求の引き出し方：明日から使えるシステム開発プロジェクトの進め方 再入門（3） 本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、要件定義をうまくこなすためのポイントについて解説する。手間を惜しまず丁寧に対応しよう。 連載目次 皆、悩んでいる――そもそも、要件定義とは システム開発プロジェクトの進め方をあらためて解説する本連載。連載第1回の「若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実」では、今のSIerが直面している問題点を提示し、本連載の意義や概要などを紹介した。前回の「要件定義を本気で成功させたいなら、その前に実践しておきたい4つの最重要
ソフトウェア開発方法論 - Wikipedia
ソフトウェア開発方法論（英: software development methodology; SDM）は、ソフトウェア開発に用いられる一連のルール・ガイドライン、またそれを扱うソフトウェア工学の一分野である[1]。システム開発方法論（英: system development methodology）とも。 概要[編集] ソフトウェア・情報システムは目的を達成するために開発される。開発を1つのプロセス（ソフトウェア開発工程）として捉えると、開発スタイルにより様々な構造・制約（ルール）・原則が見いだされる。一連のルール・ガイドラインからなる1つの開発スタイルがソフトウェア開発方法論である。また様々なスタイルに共通するあるいは特有なルールを研究するソフトウェア工学の分野もソフトウェア開発方法論と呼ばれる。 歴史[編集] ソフトウェア開発方法論 (SDM) のフレームワークが生まれたのは19
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
SE虎の巻
最近はRPA（ロボティック・プロセス・オートメーション）が大変流行しており、日本が今後抱えることになる人材不足の問題を解決してくれる可能性を秘めています。WinActorやUiPathなど、これらのツールに精通するエンジニアの需要が高まり、作業の自動化に向けた概念が今後も続々と登場していくのでしょう。 また、IoTやAI技術が急速に発展し、あらゆる情報をネットワークとデバイスによって繋がる社会となりました。ビッグデータやBI、クラウドなどのキーワードは今や古めかしい単語のように聞こえるほどのスピードでITは進化していますが、それを取り巻くシステムエンジニアに求められる本質は変わらずにあります。 システムエンジニアである管理人が、システムの開発ノウハウを公開し、世の中のシステムエンジニアの皆さまにとって役立つような情報を提供するサイトです。 特定業界の実務知識を生かした業務系システムエンジニ
プロジェクト管理と要求定義の肝
要求定義の肝 発注者のためのプロジェクト管理 日経コンピュータ（日経BP）の2009年7月8日号に寄稿した「発注者のプロジェクト管理」の元原稿です。 アーキテクトの仕事～立ち上げ・要件定義 システム開発ジャーナル（毎日コミュニケーションズ）の創刊号に寄稿した「アーキテクトの仕事～立ち上げ・要件定義」の元原稿です。 著書 なぜ今、「発注側のプロジェクト管理」なのか 工事進行基準の適用が始まった。システム開発における数々のグレーゾーンを排除するために、ベンダにはこれまで以上に高いプロジェクト管理能力が求められることになる。この影響は当然、発注側にも及ぶ。役割分担や要件のグレーゾーンの扱い、仕様変更の扱いなど、これまで発注側の「ごり押し」で通ってきた要求が、（良いか悪いかは別として）簡単には通らなくなってくる可能性が高い。発注側としても、この状況に対応するために、問題定義や要件の明確化およびステ
最終回 システム要件を定義し最終成果物にまとめる
シフトフェーズは、要求開発からシステム開発への橋渡しをするフェーズです。デザインフェーズで定めた新業務をもとに、システムが担うべき役割をシステム要求として定義していきます。デザインフェーズまでは、業務を中心に検討を進めてきましたが、シフトフェーズでは、システムへと視点を移して作業が行われることになります。このフェーズの成果物は、RFP（Request For Proposal:提案依頼書）やシステム化構想書、要件定義書などになります。 シフトフェーズで押さえておくべき勘所 本連載の「第1回 BA/BABOKが注目される背景と「要求開発」が必要な理由」で、要求開発のベースには要求開発方法論「オープンソロジー」があり、それをまとめたものが書籍「要求開発」であると紹介しました。 シフトフェーズに関して、書籍「要求開発」には、「『システムToBeモデリング』『IT基本要求定義』『システム移行計画作
要件定義、要求分析とは何か - SE虎の巻 -
顧客がどのようにして商売を行っているかを、十分に理解する必要がある。なぜシステム化することが必要なのか、なぜそのようなビジネスモデルを考えたのかを理解し、不足なく要件を汲み取ることが求められる。後々になって、不足した要件が見つかれば、システム開発全体にダメージを与えることになる。 一方で無駄な要件が発覚したときは、その機能自体を破棄してしまえば良く、スケジュールへの影響も少ない。しかし、不要な機能の開発に投入したコストは捨て金であるため、顧客ではなく、開発側が責任を負うことになるだろう。
要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
超上流から攻めるIT化の事例集：要件定義 | アーカイブ | IPA 独立行政法人 情報処理推進機構
・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
「要件定義書のアウトライン作成」完全マニュアル
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
WBSがプロジェクトとあなたを変える | 日経 xTECH（クロステック）