《WORDは嫌》設計書をWikiで書くことを広めるスレ

オブジェクト指向全盛のこの時代にもかかわらず、
設計書には分割統治の原則はなく、WORDを使っている始末

もっと楽をするためにWikiもしくはAPTを使うための
情報をあつめて広めよ

WikiWikiWeb （ウィキウィキウェブ）リンク集
http://www9.ocn.ne.jp/~ymt/wiki/

XMLmind Aptconvert
http://www.xmlmind.com/aptconvert.html

2

WORDで作るにしても、フォーマットを決めるやつが、
WORDの機能をぜんぜん活用してないんだよ。
ちょっとした工夫で何倍も楽になるのに。

あと、とにかく罫線を使いたがるのも勘弁してくれってかんじ。

　　　　　　　　　　　　　　,,,,,,,,,,,,,,,,,,,,
　　　　　　　　　　　　 ／": : : : : : : : ＼
　　　　　　　　　　　/-─-,,,_: : : : : : : : :＼
　　　　　　　　　　/　　　　　'''-,,,: : : : : : : :i
　　　　　　　　　 /、　　　　　　/: : : : : : : : i　　　　　＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　r-、 ,,,,,,,,,,、　/: : : : : : : : : :i　　　 ／
　　　　　　　　　L_,　,　　 、　＼: : : : : : : : :i　　 ／　ダイエーの店内で、「ウィー アー ザ チャンピオン」
　　　　　　　　 /●) (●>　　　|: :__,=-、: /　＜　　　　　　　　なんて曲が流れてたのにﾜﾗﾀらファン失格かなと思っている。
　　　　　　　　l ｲ　 '-　　　　　|:/　tbﾉﾉ　　　　＼ 　　　
　　　　　　　　l ,`-=-'＼　　　　 `l ι';/　　　　　　 ＼ ダイエーファン（２４・男性）
　　　　　　　　ヽﾄｪ-ｪｪ-:）　　　 　-r'　　　　　　　　　￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　ヾ＝-'　　　　　／ /　　
　　　　　＿＿＿_ヽ::::...　　　／ ::::|
　　／￣　::::::::::::::l　`──''''　　 :::|

WORDなんてExcelのオマケです。
偉い人にはそれが分からんのですよ。

Wikiで書いて勝手に改ざんされまくる

>>6
ログインしなきゃ編集できないようにすりゃいいだけ。

WordPadしか使ったことないんですが、今回、がんばって
Wordで作ってみました。
http://www.ipa.go.jp/jinzai/itss/download.html

>>1よ、
blogはどうなのよ？

Eclipse対応Wikiプラグインを
使うと面白いぞ

最終的に目次と表紙のついたPDFになってもらわなきゃ、困る！

Wikiは入力が使いにくい。
テキストエディタで書いて、コピペするって方法でもいいけど、それなら、
マークアップしたテキストを、直接他のフォーマットに変換する
ツールでも作ったほうがいい。

WORDがいやなのはわかるが、

WikiはないだろWikiは。ははは。

Wikiはありえない。
道具に使われてる感たっぷり。
Wikiを推してる人をみると不憫。

MSアンチは低能だらけの法則が見事にあてはまる

http://www.flexwiki.com/default.aspx/FlexWiki.HomePage

Ｗｉｋｉは雑談場所。

>>15
MSのソフトにしては評判悪すぎ＞word

最近のワードは快適だよ。
でも更新履歴なんかそのまま印刷されて
業務に大打撃だよ。
なんとかしてよ。

excelのおまけ＞word

そういや2002以降使ってないな。
昔はけっこう使ってたけど。

wordは書きづらいし読みづらい。
読みやすさを追求した場合、なんらかのハイパーメディア
の方がはるかにわかりやすいと思うのだが書き込むツールで
適当なものがないんだよね

Wikiで設計書はちょっと…
webページ書くには便利だけど。

私はLaTeXを推したい。

ん、待てよ
LaTeXは清書用には良いが、始めから設計書を書くにはきついか…

オブジェクト指向は設計段階もそうだけど、
それ以前の分析段階からＵＭＬを使ってプロジェクトチームの
意思疎通を図ったんだけど、結構有効でしたね。
フリーソフトも出てるし、関連書籍もあるし、検定資格もある。
ＳＥなら知っておいたらなにかと便利ですよ。

UMLは便利なんだけど 絵を描くのがツール使ってもめんどい

Wikiのような書式 で書くのはとても楽だな
これをコンパイルすると表紙と目次付PDFを吐き出すような
そんなツールがあるととても幸せだな

>>27
マなら作れよ

wikiって何がいいのかさっぱりわからん。
wordも使いにくいがいらない機能多すぎる

>>29
いらない機能は使わなければいい

割り切っちまえば便利だぜ

期待揚げ

雰囲気からしてスレ内容はみんなに指示されていない模様。

設計書っていうか作業記録とか共有備忘録みたいな使い方では使いまくってるな。
ブラウザあれば、ほぼ場所やOSに関わらず読み書きできるし
Office入れちゃまずい開発環境でも読み書きできるし。

入出力UIとファイル共有と外部ネットワーク接続をシンプルにやっつけときましょう的な。

Excelで書いてるうちはどうしよ。
いやもう、改行、改ページ、行末の文字欠けで最悪。
Wordを提案したら、そんな労力と技術は無いと言われました。orz
労力はともかく技術無いって

簡単なフォーマットで書きたい
XMLとかでうまく出来ないかな

どんな形式で書いておくかはともかく、仕様書に変更があるたびに、
どさっと紙を渡されるのは嫌だな。最近あんまりないけど。

何が嫌かって、どこを変更したのか分からない。
いつ変更したのかわからない。
誰が変更したのがわからない。

個人的には、Wikiよりも普通のHTMLかテキストで書いて、CVSで管理して欲しい。

Wikiって大抵それ自体にバージョン管理付いてるやん？

Wikiは操作が直感的でないから嫌い

ワードを使うにしてもフォーマットを決める責任者が、ワードのことをなんにも
知らなくて、すごい編集しにくいテンプレートを作ったりされると最悪。

ちょっと文字を挿入したり削除したりすると、フォーマットが崩れて、位置あわせに
すごい手間を取られるとか。
章やページのナンバリングも、ワードの機能を使わないで、手で入力させたり
するのとか、ほんとうにドカタをやらされてる気分になる。

Wordは原本用意されててもどこをどう弄ってあるのかファイルだけでは分かりづらいので
表現力とやらはなくてもどこをどう設定してるか分かりやすいExcelやHTMLで書くことが多いな。

大事なのは設計書を人間だけでなくプログラムが読めるかどうかってことだよね。

例えば、ワードなりWikiなりで書かれた設計書が1000くらいあったとして、
その文書の冒頭には設計書種別コードが振ってあったとする。
001画面設計、002プログラム設計、003オブジェクト設計、……等。
で、このうち設計書種別コードとして002を持つファイルの一覧を作りたい時って､
どうするんだろ。

>>41
コードに接頭子でもつけとくといいんんでねーの？
「SS-001」とか「説種-002」とか。
そうすりゃ単純に全文検索するだけやん。

>>42
そういう問題じゃなくてさぁ。
ごめん。あなたに説明できそうな気がしない。

>>43
そういう問題じゃないのか。
てっきり002だと他のコードも引っかかるから単純検索できないとかいう事なのかと思ったよ。

Apache Maven
http://maven.apache.org/

これで仕様書に書きたい情報は自動生成されるんだよな。
Mavenをうまく使えれば。

現状では未だに
仕様書＝分厚い紙の束
のところが多いが、
WikiやApache Mavenによって
仕様書＝Webサイト
なってくれることを望むよ。

Wikiを更新しやすくするフロントエンドツール無いかな？

2chブラウザみたいにさ

えー？
そんなんで仕様書作ったら検収印とか貰えないし
成果物として提出できないじゃん。

>>45
> 仕様書＝Webサイト

↑ここに同意。
Webだと、常に最新のモノをみる事が出来るからね。

WikiかWordかExcelかTextかって事よりも、「客先に提出する成果物としての仕様書」と、
「開発中に開発者が参照/更新する仕様書」は別物だ、ってことを認めないとダメかも。

仕様書はパワーポイントに決まってるだろ！

日本で一番流行ってるのはPukiWikiだけどデフォルトの状態だと使いにくいし
プラグインの組み込みはソースいじらないといけないから非常に面倒で危険。
Wikiのアイデア自体はいいけどツールとしての完成度は非常に低い。

>>47
> えー？
> そんなんで仕様書作ったら検収印とか貰えないし
> 成果物として提出できないじゃん。

電子署名つかえよ
それから指紋認証、
網膜認証、
手のひら認証
とかな

>>50
だからフロントエンドツールが欲しいんだよ。
2chぶらうざみたいにさ

リッチクライアント環境で差


仕様書をblogで書くってものええなあ。
MovableTypeとか使ってw

>>51
で、紙と電子ファイルでどうやって納品すんの？
競合も含めたバージョン管理は？
あ、このスレ 1 から読まないで言ってるけど解決済みか？

競合も含めたバージョン管理ができないという意味がよくわからない
説明ｷﾎﾞﾝ

GUIフロントエンド前提ならそもそも腐れHTTPに依存したCGI自体不要。

>>55
そこはアレだ
出先のネカフェでも仕事が出来るようにという・・・

>50
お前PukiWiki知らないだろ。

Wiki病患者の隔離施設はここですか？

>>55
お前リッチクライアント知らないだろ

>>53
> >>51
> で、紙と電子ファイルでどうやって納品すんの？
電子のほうだが、証明書ってもんを知らん？
納品もサーバに納品するだけで解決できるシステムをつくってしまえばいいんだよ。
顧客はブラウザからパスワードを入力して納品を確認すればいい。
最近ではサーバアプリケーションの仕事が多く、
大抵、納品されたものはそのままサーバにアップするだけですむものが多いから
それでも大抵は十分。もちろんバックアップはとる。
スタンドアロンアプリの場合も、納品サーバたるものを用意すればいい。

顧客がブラウザを使えない？　そんな時代遅れな糞ジジイな馬鹿は
この業界から追放されてしまえばいい。
我々が時代の最先端を率先すべきだ。
そｓてい顧客に最先端技術を使わせるために顧客を引っ張っていくのだ。



> 競合も含めたバージョン管理は？
？？？？　意味がわからん。
バージョン管理システムCVS, Subversionを使っているんだったら
んな「競合」という事態には陥らんと思うのだが。

紙切れの時代はもう終わった。
もう無駄に印刷することによって
資源の無駄遣いをすることもない。
もう地球温暖化の原因としてボランティア団体に
非難されることもない。
ペーパーレスの時代だ！！！！

どうしても紙を使いたい？
そんなお前は電子ペーパーをお勧めする。
この技術を顧客に普及させろ！

紙の批判はまあわかるとして
電子ペーパーを導入することによるメリットを語らないと

語って顧客を魅了させなきゃダメなんだよね。
でないと何も変わらない。
上の方で偉そうに語ってる奴がいるが
そんな奴に限ってマーケティングなんて考えてないんだろうなｗ

他製品や他社とその信者の批判なら Sony GateKeeper でもできるからな(　´∀`)

>>63
ちゃんと分業しろよ。
技術ドカタは営業の犬を納得させれば、バカ顧客を納得させるのは犬の仕事。
バカ顧客からの無茶な要望を切り分けするのが、技術ドカタの仕事。

どうかねぇ....
お客を納得させるより営業を納得させる方が難しいと思うけど....

>>66
客を納得させれるなら何も考えなくていいだろ。
好きにやれ。

>>66
っつか、営業さえも説得できないのに客を納得させれるのは
ユルい客なんだろ？

PukiWikiのプラグインってただのインクルードファイルじゃん

え！？ソースいじらなきゃダメなの？

ちょっとしたカスタマイズからプラグインの組み込みまで全部ソース修正。
ひどいのになると〜行目当たりにif文追加とかもあるし。

>71
PukiWikiのPlug-inの仕様を嫁。
ttp://pukiwiki.org/dev/?PukiWiki%2FPlug-in%A4%CE%BB%C5%CD%CD

少なくともプラグインはソースを変更しなくてもいけるものが多い。

>>62
> 紙の批判はまあわかるとして
> 電子ペーパーを導入することによるメリットを語らないと

今のところ、メリットは無い！　orz

とりあえずWiki + ブログ + リッチクライアント

電子ペーパーは紙好きな人向けに・・・・・・・。

とにかく電子ペーパーは今のところ二の次！

電子ペーパーなら紙と同じように素早くページを捲って
大雑把に概要を掴むことができる、持ち運びにも丁度いい
というメリットがある。再利用できるメリットもある。
これをアノトペンと組み合わせれば最強！

けど今のところは供給が足りないので後回し！

その前にタブレットPCがもっと使いやすくなればなあ〜。
タブレットPCが普通の紙やペンと同じように使えれば・・・。
起動が速ければ・・・・。電源オンで瞬時に！ 紙よりも速く起動！
タブレットPCも、技術的にもまだ貧弱なので後回し。

とにかく、今はどの会社の会議室にも無線LANを徹底導入し
顧客が即座に仕様書を読めるようにする！

>>63
> そんな奴に限ってマーケティングなんて考えてないんだろうなｗ

2chだからわざとこう書いているのだ！
考えちゃいる！
表の世界では宣伝だ！　

Officeのコラボ機能はどうなんよ

>>66
営業が、営業らしくない、
元技術者ってこともある。
その元技術者でもトンデモがいるもんだよ。
胡麻擂りばかりでとりあえず仕事をとるだけに満足して手
イエスマンで自分の能力の限界を超えるような
とんでもないことをしゃべる営業が。
その営業のお陰でエンジニアは大変だ。
顧客からの信頼も失うし。営業は一応マネージャで会社役員も兼ねているし
怒りっぽいし下手なことは言えない。

>>75
UMLは？

>>76
俺は今までそういう営業しか見た事ねーよ。

ひでー営業だ。

営業のせいでデスマーチの魔の手が(ry

実は営業より顧客の方が新しい手法に野心的な場合が多い。
特に追加予算の必要無しとなればかなり積極的になる.....当たり前か。

最悪だ。
急がされると嫌だね。
あせると新しい手法もうまくいかない。

顧客側にも
すごいピラミッドを持っていることがあるらしいね。

手前の顧客の上にいる会社の顧客がしきっていて
そいつが仕様を追加しろと言ったらそれが間接的に
こちらに伝わってくる。
直接指示をくだしてくれたほうが
そのピラミッドの頂点にいる香具師の意図している
ことがよくわかると思うのだが。
間接的なので不安定。急げ急げと文句ばかり言って
うちと直に交渉している顧客が精神的に疲労を抱えて
病院通いになることまで起きている。
その顧客の上司だか会社の方針があまりにも
無茶すぎて精神的につらくて病院通いになってしまったらしい。

その顧客はクッションだったようだ。

ドキュメントに対する客の評価は
印刷した紙の枚数で決まる。これ常識。

どうせ読まないだろうしなぁ

>>82
そんな愚かな常識がしがらみとして
残っているからこのIT業界が腐ってゆくんだよ。

わざと文字サイズをでかくして、わざと
行間、文字送りをでかくして
わざと余白を広くして
わざと無意味な図を大量に貼り付けて
わざと索引を作って
わざと各章毎にタイトルページを作って
わざとGUIの操作手順をプリントスクリーンでコピーしたもの
を何枚を貼り付けて

それで顧客は満足か？

顧客は馬鹿だ。

>>84
82ではないけど。82の言うような顧客は確かに実在する。
その「愚かな常識」とやらを払拭するための方法を記述しないと
貴方のレスには価値が無いな

おじゃまんが山田君で反省文を原稿用紙に一文字ずつ書くっていうネタがあったな

>>85
すべては金だからな。
良い設計書？俺が欲しいのは目先の金だよ。

たまにはWikiの話しろよ

BTSプラグイン作ってくれ

Wikiなんて論外ってことでＯＫ？

>>88
キャッシュフローってものを知ってるか？

こちらが良い設計書を書いて
顧客に先進的な手法を見せつければ
顧客はお金の出し方を変え設計書の書き方に対する価値観
を変えてくれるんだよ。

こちらが率先して新技術を導入し顧客の考えを変えるように動き出せば
業界は変わる。世界は変わる。我々が世界を変える。

そうすれば悪い設計書に対する印象が悪くなりそのような設計書を
求める者は誰もいなくなり悪い設計書の価値がさがる。
そうすれば新しい技術が導入された設計書の価値が高まり、
こちらとしても開発効率が非常に高まり
顧客にとっても我々にとっても大いにプラスになる。

適当なドキュメントを作っても困る人は誰もいないから
今までどおりで問題なし。

つーか、作るのが面倒くさい。
上司があれこれうるさいし。
部下にいろいろ注文突きつける前に顧客の真の要望を把握しろよ
営業やってる馬鹿上司！　っていいたいんだがなあ。

顧客はもしかしたら新しいスタイルも欲しがっているかも知れないし
本当に仕様書をwordで書く必要があるかどうか
顧客にちゃんと聞けよ馬鹿営業！　ってな気分

>>94
とりあえず文句ならここで聞こう。щ(ﾟДﾟщ)ｶﾓｰﾝ!!

この会社辞めようと思ったダメ上司の一言＃0x14
http://pc5.2ch.net/test/read.cgi/prog/1102652286/

顧客っていうのは
元請のこと？

Wiki病 - 新種の病気
http://www.yamdas.org/column/technique/wikiphiliaj.html

設計書欲しがるエンドユーザーってのはそんなにいないんじゃない？

ファイル単体でしか運用できないWordではなく
Wikiで書いてグループ内で共有しようという話ではないん？

Wordってセクション分けると、途端にファイルヘッダの整合性が合わなくなる確率上がるな。
Wikiを利用するのも良いけど、うちでは表現力の問題で却下。

>>99
WikiはWikiであっても良いけど、表現力の問題があるんで記述はWordでやりたいな。
そのうちスマートクライアントに対応した製品か何かがでるかもね。＜OFFCE2003

HTMLのようなもので記述したい。
スタイルが自由に変更できるが、ベースはテキスト、みたいな。
まんまHTMLだと印刷時に自動生成目次とかが問題になるから
やってないが。

・・・XMLで書きゃいいのか？
XMLで書いた仕様書やアニマルをうまく表示するツールが
あればいいのか

>・・・XMLで書きゃいいのか？
つWORD

pLaTeXeとかでもいいぞ。書きにくいが。

Wikiを勧めたい意図はよくわかる。利便性もな。
ただ、Wikiではそれ以外の表現力とかがまったくもって力不足。

どっかでパッケージソフトウェアとして作ってそうだけどな。

お前らが薦める物って、どこか一つ足りない物ばかりだな。

所詮ちゃちなオプソだからな。
Officeのコラボ機能って使えないのかね。

wikiは完璧じゃないかもしれんが
updateするのが大変だとか言ういいわけを盾にして
いつまでも仕様書を作っていない状況よりはましかと

>>101
そのためのXSLT。
XMLはツールを前提で入力するようになってなきゃ、絶対に使おうとは思わん。

結局WordでXMLを出力するのが最善ってことね。

内部データ構造などどうでもいい

>>109
どうでもよくない。汎用的なフォーマットを求む。
XMLだったら章毎の変更管理とかも容易に知る事が出来そうだし、それを管理する機構も単純で済みそうだ。

ただ、PDF出力と単体での履歴管理は必須な。
上記の点から、WORD2003を設計書として使う事に何の不自由も無いんだけど。

>出来そうだし
>済みそうだ
結局内部にはのータッチだし。言うだけ番長だな。

xmlに幻想を抱きすぎだな
コラボレーションをするのに文書の表現形式がxmlである必然性はない
コラボレーションができさえすればどんな形式でもかまわん

表現力表現力って。
うちらは印刷屋じゃ無いんだからWordのフル機能必要なほどのレイアウトは要求されてないと思うのだが。

要は機能が多すぎてそれだけのためにガイドラインでも作らんと
統一されたグループ運用できないのが糞いからいっそWikiで、なんて極論になるわけで。

内部の文法はwikiレベルでいいと思うんだ
なにしろタグとか使うのは面倒だし

世にあるフリーのアウトラインプロセッサもどきレベルの
というかwikiレベルの方がテキスト印刷にも耐える。

日常ではテキストでのみ更新し、いざというときに
カッコよく見てくれを整えてPDF出力してくれれば
それで十分と思う

Web上で共同編集できるからWikiがよいという話ではないのか。
Wiki文法のような記述方法が好きなら一人でhowmでも使っとれ。

>>113
なるほど、そうだよな〜
なんか色々機能があると使いたくなるし、使わないともったいない感が出る。

たしかにレイアウト整えるのに半日費やした憶えがある…
書いた後にフォーマット決めるのやめれ

>>115
共同編集は ついで

>>116
> なんか色々機能があると使いたくなるし、使わないともったいない感が出る。

この意見がかなり核心をついている気がする。

「罫線は非行の始まり」「画面偏愛症」という名前で、体裁に懲りすぎる行為を
指摘しているページがあったなぁ。

「ユーザの画面偏愛症」
http://www.kogures.com/hitoshi/opinion/toukou-netclip/wave4.html

開発者たるもの、こんなユーザと同じレベルじゃいけないんだけど、
でもまだいるもんなぁ。

楽で安価な方法をとったらWikiになった訳だが。