ドキュメント作成時のあるあるアンチパターン20 - Qiita
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
わかりやすいドキュメントを書くには 〜 全体像を把握できることが重要 - Qiita
はじめに エンジニアなら誰でもたくさんのドキュメントを読むことになります。 その中にはわかりにくいドキュメントも少なからずあると思います。 自分はわかりにくいドキュメントは「全体像が掴みにくい」ことが多いと感じています。 そこで、ここではわかりやすいドキュメントを書くための方法を「全体像を把握できるようにする」という視点でまとめてみました。 また、最後に具体例としてQiita APIドキュメントでわかりにくい点の指摘と改善をしてみました。 ここで扱うドキュメントの種類 ここでは仕様書やリファレンスマニュアルといった類のドキュメントを想定しています。 Qiitaの投稿やブログの記事といったものでも共通する部分は多いのですが、これらには他にも重要な要素があると思うので、ここでは扱いません。 わかりにくいドキュメント=全体像が掴めないものが多い 先ず、わかりにくいドキュメントとはどんなものでしょ
詳細設計書（前半）
前回までに表1の? 7「機能設計書」の基本設計ドキュメントとして、「表紙」「I/O関連図」「画面レイアウト」「帳票レイアウト」について紹介しました。今回からは、詳細設計に関するドキュメントについて順に説明していきます。 "機能"単位での設計書 機能設計書は、機能単位でドキュメントが作成されます。例えば、「プロスペクト登録画面」と「プロスペクト一覧画面」と「プロスペクト一覧表」という3つの機能があれば、3セットの機能設計書を作ることになります。ここで注意して欲しいのは、設計書の記述はあくまでもユーザのイメージする"機能"単位で、プログラミング単位の"プロシージャ"や"クラス"ではないということです。この"機能"という概念について、図1「プロスペクト登録画面」を例に説明しましょう。 図1を見ると、「プロスペクト登録画面」という機能は、画面、イベント、BL（ビジネスロジック）などのオブジェクトか
ドキュメントを作成しないユーザーは、失敗する − ＠IT情報マネジメント
ドキュメントを作成しないユーザーは、失敗する：ユーザーサイド・プロジェクト推進ガイド（15）（1/2 ページ） システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか？ コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか？ 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか？ あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか？ 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
開発ドキュメントの最適化(2)
Part1●効率化を図る リスクを考えながら無駄をなくす ドキュメントを大幅に削減したいのであれば，開発プロセスを見直すのが最も効果がある。ユーザーや開発者同士の意思疎通が図られ，お互いの合意がとれているのであれば，ドキュメントは省略可能だ。この特徴を最大限に生かしたのが，XP（Extreme Programming）による開発である。 ただ，XPを含め，お互いの合意がとれている状態にするのはかなり難しい。規模が大きくなればそもそも困難になるほか，ユーザーの立場からするとリスク回避のためにどうしてもドキュメントが不可欠になる。開発プロセスの見直しが難しい場合は，合意がとれているものは省略する，できるだけ再利用する，などして地道にドキュメントを削減していくしかない。 開発プロセスを見直す 一般に，システム構築では要求→分析→設計→実装→テストといった手順を踏んでいくが，このようなプロセスでは
設計書仕様書テンプレート PocketDOC | 株式会社イーイノベーション
弊社サービスをご利用頂き、誠に有り難うございます。 ドキュメントのダウンロード件数が2007年5月の開設以来300000件を突破しました！ 今度ともご愛顧の程よろしくお願いいたします。 PocketDOC(ポケットドック)とはシステム開発に必要な設計書や仕様書などのドキュメントやテンプレートはもちろんのこと、 議事録、納品・検収書、近年話題になっている個人情報に関しての取扱管理表などの ドキュメントやテンプレートも提供しています。 実際に弊社のプロジェクトで使用されているため精度も高く、カスタマイズなしでも利用可能なほどです。 上流工程から下流工程まで広い範囲をサポートしているので、 必要なテンプレートだけをダウンロードして利用することも可能です。 ドキュメントやテンプレートのファイル形式はWord(doc形式)やExcel(xls形式)です。 ダウンロード後、すぐにお使いいただけるように
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
基本設計書