→ドキュメント作成ツール
→プロジェクト管理
→要件定義・基本設計
→要件定義書の一般的な項目
→詳細設計・アルゴリズムなど
→開発支援ツール
#contents
*文書作成・管理 [#wa512fce]
-[[Excel方眼紙がダメな２つの理由>http://watanabek.cocolog-nifty.com/blog/2012/07/post-430e.html]] 2012.7.13
--まとめると、「Excel方眼紙」がダメな根源的な理由は２つある。プログラミングが合理化されない点、そして仕様情報管理が合理化されない点だ。これらに比べたら「Excelでは保守しづらい」とか「印刷するとずれる」など可憐なほどに瑣末である。
--そういうわけで、この問題への対応状況には次の３段階がある。使っているツールがExcelだろうがWordだろうが、せめてレベル１を目指そう。レベル０の現場で人生を無駄使いしてはいけない。
---＜レベル０＞汎用ツールで仕様書を書いて、いちいちプログラミングしている
---＜レベル１＞汎用ツールで仕様書を書いて、プログラミングを合理化している
---＜レベル２＞専用ツールで仕様書を書いて、プログラミングと仕様情報管理とを合理化している
--参考記事：[[美文書作りには「方眼紙」シートを使う>http://wol.nikkeibp.co.jp/article/column/20130523/153361/]] 2013.5.23
-[[ネットワーク図の書き方>http://d.hatena.ne.jp/elwoodblues/20120404/1333474343]] 2012.4.4
-[[情報の構造化、してますか？>http://bizmakoto.jp/bizid/articles/1202/08/news010.html]] 2012.2.8
-[[報告書の書き方>http://el.jibun.atmarkit.co.jp/yokoyama/2011/10/post-9411.html]] 2011.10
目標は何だったか
その目標は達成されたか
達成されたのは何が原因か
達成できなかったのは何が原因か
問題があった場合、解決のために自分はどんな努力をしたか
解決できなかった問題は、どうすれば解決できるか
そのためには何をしてほしいか
-仕様書の記述要領を決めるときに注意すべき一般的な項目
--大勢で仕様書を書くとき、平仄を合わせることが必要になり、以下のような規約をあらかじめ決めておく必要がある。決めて置かないと後から治すハメになる。
--スペースの表現方法。△を使うか、クォートで囲うか。
--改ページしたときにヘッダを再度表示するか。表で改ページした場合も
--注のつけ方。章ごとに注の本体を書くのか、ページごとに書くのか
--章立て、項目立ての項番体系。単項目になったときに番号をつけるか（外すことが多い模様）
--既存の仕様書を修正で項番を削除するとき、詰めるのか、欠番にするのか。取り消し線を引くのか
--ファイル名のつけ方のルール
--修正履歴の書き方。修正の理由も書くか。いつからバージョン1.0とするか
--図表の番号、キャプションのつけかた
--Wordの場合、見出しにどんなスタイルをつけるか
--テンプレート(.dot)を使うか
--英数字は全角か、半角か
-[[ソフトウェアレビューが成功する進行役の6条件>http://www.atmarkit.co.jp/im/carc/serial/review/04/01.html]] 2010.4.14
--レビューアがエラー発見に集中できているか
--レビューアがエラー発見の手掛かりを得られているか
--遠慮して発言していないレビューアがいないか
--適切なエラー指摘がなされているか
--進行のペース（時間配分）は適切か
--作成者は指摘を受け入れているか
-[[読みやすい文章の極意は「修飾語」にあり>http://jibun.atmarkit.co.jp/lskill01/rensai/writing06/01.html]] 2010.1.19
-[[MSが長音付けルール変更、「ドライバ」を「ドライバー」に>http://www.atmarkit.co.jp/news/200807/25/microsoft.html]] 2008.7.25
-[[発注者が理解しやすいシナリオの記述方法>http://www.nikkeibp.co.jp/news/flash/578821.html]] 2008.7.17
--システム化業務説明書とは，ある「システム化業務」の中で「利用者がシステムに対して行うこと」「システムが利用者に対して行うこと」「システムが内部的に実行する処理」を，「シナリオ形式」で記述した仕様書のことです。
--基本，代替，例外の3つのシナリオを記述すること
--システム化業務のシナリオを利用者とシステムに分けて記述すること
-[[ユーザと意思疎通が取れない外部設計書は危ない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080508/301039/]] 2008.5.22
-[[議事録を書くときに意識すべきこと>http://d.hatena.ne.jp/HappymanOkajima/20110225/1298608948]] 2011.2.25
-[[議事録のプロ>http://itpro.nikkeibp.co.jp/article/COLUMN/20080328/297379/]] 2008.4.8
--議事録には決まったことだけ書く
-[[どんな作業のマニュアルも３時間あれば作れる>http://d.hatena.ne.jp/tgk/20061124#1164341828]]
--個人的には以下のようなマニュアル観は間違っていると思う。
---不完全なマニュアルを配られても困る
---マニュアルに書いてある通りにやって問題が起きるぐらいなら、そんなの無いほうがいいんじゃないの
---書いてある通りにやって問題が起きても作業者の責任ではない。嘘のマニュアルを書いたやつが悪い
---マニュアルとは「書いてある通りに作業するためのもの」なのだから、例外事項がたくさんある作業のマニュアルなんて書けない
---マニュアルがあると、それに頼り切って頭を使わなくなるので、作業者が成長しなくなるのが問題だ
--どこが間違っているかというと、こう考える組織では永遠にマニュアルができないから
-[[計画書をコピペしてはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080326/297094/]] 2008.4.8
--「参考にする」ということと「コピペ」するということは違う
--ここはコピーしても大丈夫だろうと思っても，必ず一度自分の頭で考え，判断した上でコピペすべきである
-[[文章チェックを省略してはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080326/297187/]] 2008.4.7
--「○○だけで（も）動く」と「○○でだけ動く」の違い
-[[仕様書の意義:http://dain.cocolog-nifty.com/myblog/2006/10/6_f44b.html]]
--仕様書について人々が犯す最大の過ちは、公式のレビュー会議を開催するまで内容のフィードバックを得ようとしないことです。レビューは確認と洗練を行うための場であり、たたき台の検討と最終決定を同時に行うための場ではありません
*関連サイト [#n2961b30]
-[[ドキュメント作成に役立つ「日本語スタイルガイド」の紹介>http://codezine.jp/article/detail/2669]]
-[[ラプラス取説研究所:http://www.laplace-lab.org/index.shtml]]
*ツール [#e1f0a203]
→ドキュメント作成ツール
*Markdown記法 [#e5605cee]
-[[意外と知られてないっぽいMarkDownのリンクの書き方>https://qiita.com/h1na/items/d305d49b5a27e92d132a]] 2014.4
*Help File [#c2427639]
-[[Sandcastle Help File Builder:http://www.codeproject.com/useritems/SandcastleBuilder.asp]]
-[[HTMLHelp:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hwMicrosoftHTMLHelpDownloads.asp]]
*PDF [#l1bb0614]
-[[さまざまな文書をPDFファイルへ変換、ページ移動や追加などの編集もできるフリーソフト「PDF24 PDF Creator」>http://gigazine.net/news/20120726-pdf24-pdf-creator/]] 2012.7.26
-[[PDF変換ソフトのガイド>http://www.pdf-soft.com/]]
-[[Adobe Acrobatはトロイの木馬>http://d.hatena.ne.jp/karasuyamatengu/20110227/1298764935]] 2011.3.1
-[[無料でウェブページをPDFに変換するオンラインサービス-PDFmyURL.com>http://coliss.com/articles/web-services/online-pdfmyurl.html]]
-[[Adobe Readerの重たさに辟易したら「Perfect PDF Reader」>http://www.moongift.jp/2009/03/perfect_pdf_reader/]]
--http://soft-xpansion.com/index.php?p=pdftech/pdfqr
-http://convertpdftoword.net/
--PDF -> Word変換
-http://pdfforge.org/
-http://www.html2pdf.biz/free_edition.php
--WebサイトやhtmlからPDFを生成
-[[PDFファイルを簡単に分割・結合できる PDF Split and Merge>http://coliss.com/articles/software/1415.html]]
-[[PDFをデスクトップで変換させるフリーソフト>http://www.lifehacker.jp/2008/08/pdfpc.html]]
-[[Foxit Reader for Windows>http://www.altech-ads.com/product/10001352.htm]]
--軽快なPDFビューワ
-[[PDF Unlocker>http://www.lifehacker.jp/2008/07/pdf_unlockerpdf.html]]
-[[PDFフォント○×チェッカー>http://pdf.printjapan.com/]]
-[[オンラインで手軽に使えるPDFツールまとめ>http://www.designwalker.com/2008/03/pdf-tool.html]]
-[[KoolWIRE紹介>http://gigazine.net/index.php?/news/comments/20080208_koolwire/]]
-[[Gios PDF .NET library:http://www.codeproject.com/cs/library/giospdfnetlibrary.asp]]
-[[JavaでPDFファイルを出力する(iTextライブラリ)【準備編】>http://d.hatena.ne.jp/MoonMtLab/20130913/1379021689]] 2013.9
-[[iTextSharpによるPDF出力@CodeProject>http://www.codeproject.com/useritems/iTextSharpTutorial.asp]]
-[[iTextSharpによるPDF出力:http://codezine.jp/a/article.aspx?aid=462]]
-[[文書のPDF化:http://homepage3.nifty.com/cinema1987/pdf/pdf_make.htm]]
-[[ConcatPDF:http://www.ujihara.jp/ConcatPDF/ja/]]
--PDFの結合・抽出・暗号化などをしてくれるツール
-[[Acrobat のエディション別の機能差一覧:http://support.adobe.co.jp/faq/faq/qadoc.sv?3610+001]]
-[[PrimoPDF:http://www.primopdf.com/]] フリーのPDFコンバータ
-PrimoPDFで出力したPDFをReaderで表示すると「フォントが無効なので削除」とか言われて文字化けして読めないとき
--以下のようにすると解決した
--プリンタ(PrimoPDF)のプロパティを表示
--「全般」タブの「印刷設定」ボタン→「レイアウト」タブの「詳細設定」ボタン→「TrueType Font Download Option」を「Automatic」から「Outline」に変更
--&ref(primo.PNG);
--(2006.9.20 最新バージョンでは解決している模様）
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
