開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
RFP作成術【中編】：提案しやすいRFPを作る
要求を伝えるための情報は，「何を書くか」と「どう書くか」に分けて考える。まず，書くべき内容を見ていこう良いRFPの条件，すなわちベンダーから質の高い提案や精度の高い見積もりを引き出すために必要な情報は2点。「今後どうしたいか」と「現状どうなっているか」である。 まずは，RFPの全体像を見てみよう。図4は，東京都民銀行が情報系システム基盤の開発に際して，実際に作成したRFPの目次である。案件によって項目の追加や省略はあるが，多くの案件で共通に挙げられる項目がほぼ網羅されている。 ITコーディネータであるフライの井門良貴氏（常務 エグゼクティブコンサルタント）は「RFPには，大きく3つの情報を入れる。(1)要求を伝えるための情報，(2)ベンダーを選ぶための情報，(3)トラブルを避けるための情報だ」とRFPの内容を説明する。 図4に当てはめると，(1)が「1 概要」「5 システム化の内容に関して
[Think IT] 【楽々デブドックを書こう！】手法別開発ドキュメントの書き方
シニアコンサルタント。「理論は大事だ」と言いながら、勘や直感も大切にするシステム屋。スペシャリストになるつもりが、いつの間にか「何でも屋」になっていることに悩みつつも、お客様のシステム開発プロジェクトを様々な側面から支援する日々を過ごしている。 http://www.ulsystems.co.jp/ シニアコンサルタント。間違った要求に正しく応えようと努力しても、決して報われない。正しい要求をお客様と共に考え、正しい要求によるシステム開発支援を行うことにより、参画メンバが良かったと思えるプロジェクトになるよう、日々コンサルタントとして奔走中。 http://www.ulsystems.co.jp/
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IETF Documents
