T.MURACHIの日記： 文書作成ツールの適材適所 13
『テキストファイルとは何か？ 知らぬでは済まぬ電脳社会の常識』 (鐸木能光 著 / 地人書館)。買ってません (あれ?)。LAOX ザコン館 6F に移ってしまった Book フロアで見つけて、何だこれは? とか思いつつ広げて見て、「はじめに」のところで突き出されているテーマの着眼点に興味をそそられて、おとといと今日と立ち読みしていたのですが、何ていうか、所々「それは違うだろ」と茶々入れたくなる個所が散見されるというか、あまりにも一方向からしかものを見ていなさ過ぎて結論が早すぎる部分が多すぎるような感じの内容で、読んでいて辛くなってきたので購入は断念した次第なのであります。
ただ、この本で主張されている、「文章はテキストファイルで保存されなければならない」という考え方には、私も大いに賛同したいところではあります。今でこそ、OOo のような自由なソフトウェアが登場し、視覚的に整形された文書として保存される形式に、企業の強制力に左右されないものが存在しうることとなったわけではありますが、それでも、その他のさまざまな面を鑑みても、やはり最もシンプルなカタチであるプレーンテキストが、永続性 (未来に対する互換性)、汎用性ともに一番であり、最も安心して文章という情報を保存しておける媒体であると言えるからです。
で、今回書こうとしている内容は、実はここまで書いたこととはあまり関係が無いのですが (^_^;、この辺のスレッドから私が一人わめきだしたオフトピックに関連して、文書を作るツールとして選ぶべきものについてのお話になってゆくわけです。
議論の土俵に持ち上がっているツールは、今のところとりあえず Word と Excel 、それから PowerPoint なんて名前まで出てきていますが。。。とにかく MS のツールばかりです。なんだかんだ言ってずば抜けた普及力（ｗから、/. に足を運ぶような方々も職場ではやはりこれらの MS-Office なツール類のお世話になっているようです。
私は先のスレッドの中で、すべからく Excel を批判的に書いていますが、しかしながら、Word を嫌がって Excel を使う人の気持ちもまた、よく分かるのです。正直、日本語ワードプロセッサとしての Word は、決して出来のよいソフトウェアであるとはいえません。理由は多々ありますが、個人的にはパラグラフを重んじる西欧的なテキスト文化と、400 字詰め原稿用紙でキチンと文字を並べることに慣れている日本的な作文文化との違いが、日本語ワープロとして使うときの違和感の、一番の原因といえるんではないかと思います。それまでワープロでプロポーショナルフォントを採用していたものなんて無かったからね。Word で悪戦苦闘する人のほとんどが、とりあえず、空白文字を敷き詰めても、思った通りに文字を配置できない、という辺りから深入りを始めているように思われます。
勝手にスペルチェック入れられたり、勝手に番号リストとして扱われちゃったり、勝手にインデントを入れられて元に戻せなくなっちゃったり、といったおせっかいによる不便は、まぁ Excel なんかでも似たようなことは結構あるはずなので (勝手に式として扱われてアラートが出たり、勝手に日付として扱われて表示が変わっちゃったり…)、ここでは言及しません。
逆に、パラグラフということさえ理解できれば (あとは自分なりのカスタマイズを入念に施せば)、Word もそれなりにストレス無く使えるツールだったりします。少なくとも、文章を主体とした文書を作るのであれば、MS-Office のツールの中ではなんだかんだ言って Word が最も適していると言えます。そして、多くの文書は、文章を主体としたものであると言えます。
ここで、上記のイタリック書体の部分につまづき、「おや?」と思った方は大多数に登るのではないかと思われます。。。
つい先日、実家のパソコンの面倒を見に (ってなんだか犬みたいだなぁ ^_^;) 帰省したのですが、そのとき家族内で Word か Excel か? という (いささか不毛な) 議論になり、その中で完全に Excel 一辺倒派の父親が、ソファーの上に散らかっていた読売新聞を取り上げながら、こんなことを言ったのが、凄く印象的でした。
世の中の文書というものは、ほとんどが表の形をとっているんだ。例えばほら、この新聞だって、文章を表の中に並べて出来ているだろう?
もちろん、「新聞が表である」というのは極論であり、間違いな訳ですが (それこそ、HTML で文書の体裁を整えるのに ＜table＞ タグを使用するようなものです)、しかしながら、なんでもかんでも文書作るのに Excel 使う人っていうのは、そういう認識でいるわけだったのかと、非常に参考になるコメントではあったのでした。
一言で文書と言っても、さまざまなシチュエーションがあります。中には、表を多用する必要があるもの、そもそもが単一の一覧表でしかないものもあります。月間勤務表のように、表計算ツールとしての性質をフルに使ったほうが圧倒的に便利であるものももちろん存在します。そういうものには是非とも Excel を、というか表計算ソフトを使ってあげるべきでしょう。
しかし、仕様書であれ、設計書であれ、マニュアルであれ、それから DFT やら UML やらであれ、何でかんで表という形式を用いて文書を整形しようというのはどうだろう? と私は思うのです。それは本当に、表である必要はあるのか? 思い通りの罫線を引こうと無駄な努力をする前にまず、考えて欲しいのです。
表というのは、書き手が情報を整理するには最も便利な表現手法であると言えます。物事を二元的に捉え、各要素に関するあらゆる情報を項目だてて、それらをすべて横に並べることが出来るからです。すべからく、表という形をとる文書というのは、横に長くなる傾向にあります。たくさんの項目を敷き詰めるため、列の数が多くなり、そこへ文字を埋め込むために、フォントはどんどん小さくなってゆきます。たとえ紙を横長にしてでも、とにかく表であることを守り通そうとします。結果、ひたすら横に長くて、しかもやたらとたくさんの小さい文字がびっしりと敷き詰められた、読んでいるうちに眠たくなってくるような文書が出来上がるのです。
もちろん、すべてがそうであるとは言いませんが、えてして物事を表でまとめようとする人というのは、読む上でとっつきやすい文書であることよりも、長い文章が入る項目列がいかにかさばらずに済むかということの方が重要であるかのように見えます。Word は紙の横幅に制約を感じる、という方は、なるべく表を使用せずに文書を作ることを覚えれば、それがいかに取るに足らない悩みであるかということがよく分かるんではないかと思うのです。
表にはもうひとつ、重大な欠点があります。文章やリスト (アイテマイズ行) であれば、行の挿入は改行ボタン一発で出来ます。何行も挿入したいことがあれば、そのままキーボードをたたいていればいくらでもその位置に挿入することが可能です。したがって、Word のようなワープロソフトで (あるいは単純にテキストエディタで) 普通に作っている文書というのは、仕様変更に対応しやすく、メンテナンス性に優れていると言えます。その点、表はメンテナンス性が非常に悪い記述形式である、と言えます。行を一つ挿入するために、多くの場合、行を手前に挿入する行を選んで、挿入のためのメニューコマンドを実行します。複数行を挿入するには、Excel の場合、挿入したい行数だけ反転表示させて同じことをすれば、まぁ一発でその行数だけ挿入は可能です。しかし何行挿入すれば足りるのか分からない場合もあるでしょう。そうしたときに、結局この煩雑な操作を複数回繰り返し、逆に挿入しすぎた場合には後で削除しなきゃならなかったりするでしょう。
そもそも Excel のセルに埋め込んだ文章を細かく修正したい場合、一旦そのセルを編集状態にしなければならなかったりします。書いているうちに長くなってきて、あーこの辺りで改行したいなぁ、と思ったら、改行したい位置から先を一旦カットして、すぐ下のセルを編集状態にしてその先頭にペーストしないといけなかったりするのです。長い文章だとこの操作を何回も何回も繰り返さないといけなかったりする。例え、1 つのセル内で文章が改行されて収まるような設定にしていたとしても、今度はセルの大きさが中の文章の長さに追従して変化してくれなかったりして、そのつど行の高さを調整しなおしたりしなきゃならなかったりします (これはセル中の文章がぴったり収まる高さに自動的に収まるようにしてあげる方法もあるけど、これを使うと今度は印刷のときにフォントの大きさが微妙に変わって、そのために文章がセルに収まりきれずにお尻が切れてしまう、などといったバグを招いたりもします)。とにかく、こいつで文書をメンテナンスするのは酷く骨の折れる作業なのです。
私が文書ツールとして Excel が使われるのを酷く嫌がるのは、そうした理由からなのです。
ところで私は、仕事で作る文書なんていうものは、よほど外部に公開されるようなものでもない限り (顧客が企業である場合にその顧客にのみ閲覧されるケースは、ここでは「外部に公開」の範疇には含まれません)、見た目を美しく整形する必要なんてまったくないと思っています。Word でさえ、挿絵を入れるんでも無い限り、やたらめったら使うべきではないです。それどころか、挿絵を入れるにしたって HTML とかの方が手っ取り早いとか思っていたりするし、DFT だの UML だのに至っては、作らずにすむなら作らないほうがよいとさえ思っています（ｗ。どうしても必要なら Visio 使わせてくれって頼むし。
とにかく、文書作成にまつわる工数はなるべく掛けないようにすることが最も重要です (断言)。その為には、そうなるに最も適したソリューションを、よく考えることです。単にツール選択ということではなくて、どういう体裁でその文書をまとめるか、といった点も含めて。
ちなみに、今いる職場では多くの文書が TeX によって作られています。こいつもまぁ、微妙なツールですが（ｗ、少なくともプレーンテキストで保存しておけるという点が、CVS による履歴管理を可能としているという面も含めて、優れているとは思います。
バイナリ、テキスト、HTML、SGML/XML、TeX… (スコア:1)
私なりの結論を先にいうと、
私がExcelでの設計書記述に反対する理由はT.MURACHIさんとまったく同じで、Excelで作成されたドキュメントの修正コストが馬鹿にならないほど高いこと。これにつきます。
Excel大好きな人が多かったT.MURACHIさんの会社に勤めていたころ、某メーカのプロジェクトに参加しましたが、そのときメーカから提示された設計書フォーマットがすべてExcel。しかもページごと枠がくくられていました。このときの上流から参加しましたが、その時Excelを使用した場合のドキュメントの修正コストの高さからExcelを設計書に使用することに疑問をもち始めました。ええ、数百枚のドキュメントが数十のExcelファイルに分かれていて、ページ番号振りなおすだけでも一苦労でしたよ。
それから、当時はExcelの修正コストに疑問を抱いていましたが、Wordもそのおせっかい機能と罫線の扱いに戸惑い、まともに使いこなせていませんでした。ただ、それでも文章を修正する場合に圧倒的に楽だったことは確かです。文章を途中に追加することによるレイアウト崩れを気にする必要はありませんでしたから。
そしていま考えているのがXMLを軸として、HTML等必要に応じて変換を行っていくドキュメント作成。XMLからHTMLへの変換手段はXSLTなど複数のソリューションが提供されているものの、XMLの文章構造を定義しなければならないことと変換のための仕掛けを用意しなければならないこと、そしてXML自体の作成を如何に簡単にするが課題となる。
これらを解決する手段として、現在Adobe社 [adobe.co.jp]のFrameMaker [adobe.co.jp]というSGML・XML出力が可能なパブリッシングソフトを試用しています。このソフト自体文章構造が決まったテクニカルライティングの分野での使用を想定しており、XML出力を行わなくても単体で文章構造定義から実際のドキュメント作成まで行えるつくりになっている。しかもGUIでだ。当面のネックは高いライセンス料(約11万円)なのだが、ライセンス量に見合うだけの生産性向上があれば問題ないはずなのだが…。説得は難しいよなぁ…。
そういう訳で、現実的なところは「4.」であげた、プレーンテキスト・HTML併用と考えています。HTMLも、本格的な再利用(classなどのメタデータによる文章構造定義)
を気にしなければ覚えるべきタグもそれほど多くはありません。そして、実際に書いてみれば分かりますが、開発中にドキュメントを参照する場合にリンクの概念は非常に便利に感じるはずです。また、ExcelやWordなどだと特殊なソフトが必要な全文検索もプレーンテキスト・HTMLであればNamazuで検索可能になります。そして、T.MURACHIさんも言うようにCVSで管理を行う場合に相性がいいです。もちろん、CVSでバイナリを管理することもできますが、差分管理ではないのであんまり嬉しくはありませんからね。
# まあ、Word、Excelを版管理するのであればVisualSorceSafeを使った方がいい以下もれませんね。ライセンス料はあれですけど。
それから、TeXは私自身実際に使ったことはないので認識が間違っているかもしれませんが、HTMLなどと同様にプレーンテキストベースで文章構造を意識させるつくりになるので、これはこれでありだと思っています。ただ、大学などで勉強してきた人でないと、壁が厚いかもしれませんけど。それと、どちらかというと印刷用なので、開発中の参照用としてはHTMLより劣るのではないでしょうか。
Re:バイナリ、テキスト、HTML、SGML/XML、TeX… (スコア:1)
shima ちゃん返信どもです～ (。。)ゞ とっても参考になります (^_^)/。
見解は大方一致しているみたいです。やっぱり Excel は何かと辛いです (;_;)/。テキストですむならテキストで済ませたい。全文検索を筆頭に、生テキストはそれだけでデータベース的な性質も簡単に持たせうるというオイシサを知っていて、しかも仕事で活用している人って、なかなか居ないものです。みんな Perl っていうと CGI のことしか頭に思い浮かべんもんなぁ。。。おいらにとっての Perl は、文書周り雑用ツールなんだが（ｗ。
# Excel で送られてくるバグ潰し日報（ｗを、進捗の分類で統計取るのに、わざわざ CSV に出力して Perl で用意したツールで処理してたりしたなぁ。。。なんか間違ってる気もしなくもないが（ｗ。
XML は、賢い選択かと思われます。正直そこまで頭は回らんかったが（ｗ。メタ言語としての XML は理論上、ツールを選ばないことになってるからね。
FrameMaker は、製品カタログを読んだ限りではなかなか面白いツールだと思います。DTP の世界も文書構造によって制御される時代になったのねぇ～なんてしみじみ（ｗ。ワープロ感覚での編集も出来るということで、これはむしろ XML なんて知らないパソコン初心者層に浸透して欲しいソリューションだなぁとも思ったり。
特に、興味深いなぁと思ったのは、FrameMaker Server ってやつの方だったりします。仕事で作られる定型化された文書 (これは技術屋さんに限定されないお話ですが) を作るのに適したツールということであれば、結局はテンプレートを会社が独自で一から作るなら、出来上がっているテンプレートに応じて整形された文書を出力するツールと、そのツールにデータを供給するデータベースサーバーとがあって、ユーザーはフォームへの簡単な入力だけでデータを作っておいて、必要なときにデータを取り出して文書化するようにしておけば、それが一番楽なんじゃないかなぁなんて思っていたのですが (バージョン管理もデータベース内でやればいいしね)、なんてことはない、それをやってくれるパッケージ化されたシステムがこんなところにちゃあんとあったわけですねぇ。。。(^_^; 120 万円するソフトですが、120 万なら安いよーとか思ってしまう。まぁ、プログラムを CVS 管理している環境ではバージョン管理が同期しなくなって余計なお世話な気もしなくはないですが (^_^;。
TeX に対する推察は大体当たってます。こいつはとりあえず環境を構築するのが面倒くさい。。。んで、やりたいことをやるためにはスタイル定義ファイルの入った別パッケージが必要だったりして、どこかから拾ってきたパッケージを使って文書を作ったりすると、そのことを共同開発者に周知しておかなきゃならなかったりするし。。。LaTeX なんてスタイル定義の寄せ集めで成り立っているようなものなので、だれかれが作った TeX ファイルをコンパイルするたびに、あれが未定義だの、これが未定義だのと怒られて、コンパイルできなかったりして、結構大変だったりします (^_^;。もっとも、数式エディタとしてはとにかく優れているので (doxygen が数式の挿入に、外部数式生成エンジンとして TeX を使うんですよねぇ)、やっぱり論文書くにはこれしかないというか、これを凌いでくれるようなツールがなかなかないという状況だったり (学術方面で TeX が盛んに使われているのはそういうことらしいです、おいらが通ってた似非大学ではちっとも使われていませんでしたが)。
HTML は実際によく使っています。あれはそれなりに見栄えのする文書を手軽にでっち上げるのにかなり有用です (印刷することを考えなければ)。そもそも今の職場内で参照できる技術文書や資料の類は、所内のローカルサーバーマシンで動いている Apache くんから全部リンクが張られていたりします。ただこいつでちょっと危険なのは、文書内でクロスリファレンス張るのに夢中になって、結構無駄な時間を楽しく浪費してしまうことがあったりすることですが (ヲレだけだっちゅの ^_^;)。
そんなとこかな。
とにかく、私がわめき始めたあのスレッド辺りで、/. 内にも結構 Excel 派なひとがたくさん居るみたいに感じてしまったので、正直頭が重かったのですが、shima ちゃんの返信のおかげで、やっぱりちゃんと仕事できる人は考えてるんだなぁと思ってちょっと安心しました。
ちなみに。。。やっぱりあの会社は、Excel 好きな人ばっかりなんですかね? (;_;)/ 実際、今の職場に居着くようになってから、あんまり自分の会社の人間と交流持ってないんでよく知らんのですが（ｗ、先日なんて私が居るプロジェクトの下請けの会社が NG っちゃって、代わりの下請けがうちの会社になるかもーなんていって、某リーダーな人が交渉して
むらちより/あい/をこめて。
確かにExcel派が多いようですよね (スコア:1)
＃ちと過激な書き方をしてしまって…
Excelはレイアウトありきとは私も思います。
Wordに到った経緯などが少し分かった気がします。
さて、あくまでWordよりExcelにこだわったわけを少々書かせてもらいます。
私の場合は入社直後に再構築プロジェクトに配置され、納品物件のドキュメント体系からあーでもないこーでもないと議論する機会がありました。
定型フォーマットに沿ってドキュメントを作成するのと違い、フォーマットを作成する場面ではレイアウト用紙を用いて『外から内へ』規定する作業が必要な上に、当時の社内標準ツールは卓上OASYS。OASYSはワープロソフトといいつつ空間配置を得意とする（逆にいえば３ミリ方眼を使ってレイアウティングするような）ツールです。
後に社内標準ツールがOASYSからExcelになりました。さてどうなったか。
OASYSからコンバータを用いて作ったWord文書はまるきり使い物にならず、結局いちからWordで文書を起こす羽目になりました…。
Wordの表をメンテナンスするとすぐ壊れるのでExcel張り込み、最初から横に２段組されたA4横の設計書は都度作り直し、よりOASYSに近いスプレッドシートで作成するのは必然の流れじゃないですかね（汗
MS-ProjectとかVisioとかが標準ソフトでなかったことも災いしたと思います。スケジュールを作るならWordよりExcelでしょう。
あと、ページあたりの情報量を比較してもExcelに分があると思います。余白ぐらいコントロールさせろとかA4縮小印字させろとかってのはWordにとっては無理な注文ですね。
実際にはExcelにも、セル内のポイント計算がお馬鹿で印刷時にセル内が改行で切れるとか、計算書でもないのに別シートのセル間でリンクを張ってあってメンテナンスで血を見るとか、あらゆる弱点があるんですがそれを差し引いてExcelを選択してるわけです。
そういう私でも、障害報告書とか調査報告書とか限りなく公式文書の体を成すもの（社名のfooterとかのconfidencialなもの）はWordで書いてます。
＃今の常駐先ではそれすらもPowerPointなので萎えますね
＃ページあたりの情報量は、Excel>Word>>PowerPoint、でしょう
文書を滅多に外に出さない上にHTMLやらPHPやら最近はSmartyなどと格闘するSIだと、こんなもんでしょうか。
＃大学ではTeXも使ってました
＃それ以上に３ミリ方眼をノートにしてた経験が生きてるんでしょうか
長文乱筆で申し訳ないです。
---- 何ぃ！ザシャー
Re:確かにExcel派が多いようですよね (スコア:1)
zasha さんレスありがとうございます (^^)。返信遅れて申し訳ないです。
ツールの移行というのはたまらないですよね。。。私は (うんずユーザーでありながら) OASYS はほとんど使ったことないのですが、空間配置が得意と言うことは行末の右に自由にカーソルが動く感じということでしょうか? そもそも日本のワープロ専用機って多くがそういう感覚のインターフェースだったので (もちろん等幅フォントで、っていうかそもそもプロポーショナルフォントなんて概念無かったし)、そういう感覚で Word を嫌がって Excel に流れちゃう人は多いですね。
そもそも OASYS だって (確かにいつまで続くのやらって言う不安はあるんだろうけど)、まだまだくたばっちゃあいない [fujitsu.com]んだから、そうそうツール入れ替えなんてやらなきゃいいのに、って思うんですけどね。まぁここいら辺は文書をファイルでやり取りする都合とかで流されちゃうんだとは思うのですが。。。(はっきり言って Word や Excel のファイルをメールでやり取りなんてしたくないんだがなぁ、生理的に ^_^;)
あと、PowerPoint は、なんでそんなもん使ってんのよあんたらって感じなのですが。。。困ったものですねぇ。あれはもうプレゼンツール以外の何物でもない、時間差でアニメーション効果とか掛けて喜んでいるようなお偉いおっさんのおもちゃだろうに (悪口ｗ)。
えっと、あの、お仕事がんばってください (なんだそりゃ＞ヲレ T-T/)。
むらちより/あい/をこめて。
Re:確かにExcel派が多いようですよね (スコア:1)
OASYSについてはお察しの通りです。
一番の特徴は「罫線文字」です。PC-98でおなじみの罫線みたいなのが文字として書けます。具体的には罫線キー押しながらカーソル移動で文字の代わりに線を引く感じ。
スケジュール表をEXCELで作成する場合は図形としての線を使う必要がある（またはセルを塗りつぶす）んですが、OASYSだとすいーっと楽勝って感じですね。
まぁ、罫線が文字扱いのおかげでコンバータで化け化けになるんですが（汗
ちなみに某電力業界なんですが（って両手で足りますね）、上から「標準ドキュメントはMS-OFFICE以外はまかりならん」といわれると、って感じです。結局のところお客様つーかお得意様の意見には逆らえないわけでして。
＃officeのバージョンやLotusNotesも安定ver採用のおかげで古いのです
＃ま、納品物件にソースが必要とされる業界ですから:-P
officeには、PowerPoint外してVisioとProjectをいれて欲しいってのは贅沢ですかね（苦笑
しょうがないのでoffice2000と共存させてるOOo1.1.0を使う機会も増えています。
またまた長文で申し訳ないです。
---- 何ぃ！ザシャー
Re:確かにExcel派が多いようですよね (スコア:1)
この議論の元となったT.MURACHIさんの日記およびそれに対する私の書き込みと、zashaさんの考えているドキュメントには差があるのではないかと思います。
私とT.MURACHIさんが想定しているのは定型的な文章、それこそきちっと体裁の整った設計書や操作説明書など。それに対してzashaさんは設計書というよりは、設計書に付随する資料や概略説明書のようなものを想定しているんのではないでしょうか。
別の表現をすると、文章中心のドキュメントか、図中心のドキュメント、ということになるとおもいます。
図を中心とした資料・設計書の類であれば、Excelのような「書いた内容を目的の用紙に印刷する」方法は非常に楽で、私も使っています。ですが、それが数百枚にもなる設計書のフォーマットとなると話は別です。
いみじくも、zashaさんがおっしゃるような、
といってるように、自由度がありフォーマットを定めることができないことが問題となるのです。
設計書の雛型をExcelで作成し内容を詰めていく場合、
という現象にあたまを悩ませますし、縮尺がドキュメントごとにことなっていればいたで設計書としての様式を統一させることができなくなるのです。
Excelの印刷に関する問題は、Excelのデータがページに依存していないことに原因があります。これも非定型文章を1枚に印刷する場合は縮尺を自動調整してくれるおかげで楽に1ページにおさまりますが、それができない定型文章の場合は全てのページに対して印刷プレビューを行い確認・修正を行わなければならず、無駄な労力が発生します。
私が以前のプロジェクトで経験したこと、そして設計書にExcelを用いることに対して反対するのはこのようなことからなのです。Excelとりは、まだWordがましだというのは、すくなくとも印刷に関する問題は気にする必要が無くなるからなのです。
# いや、まあ、最終的には印刷して確認しますけどね。
HTMLの利点は上で述べている [srad.jp]とおりです。
あと、HTMLにはさまざまなドキュメントを繋ぐ「のり」のような役割があります。各種ドキュメントへのリンクが張られたHTMLを作っておけば、プロジェクトメンバが参照するのが楽になるのではないでしょうか。
それから、ちょっと話はずれますがExcel・Wordに限らずバイナリデータの欠点として、全文検索ができないことがあります。が、これは私自身が前のプロジェクトで使用 [srad.jp]したMitakeSearch [hp.com]や、Kabayaki [kabayaki.jp]を使用することで対応できます。導入の手間がかかるのはたしかですし、全文検索をしなければいけない状況にならないのが一番だとはおもいますけど。
長文の上まとまりがなくてすいません。
Excelの方が作者のルールに制約されやすい欠点が。 (スコア:1)
実のところ両方で重なってるドキュメント（設計書）があるようなので、どちらかというと企業色なのかも知れませんね。
富士通SDEMがベースになったドキュメント体系で、A4orA3の定型にほとんど２段組で構成されている感じです…って言うとイメージつかめますか？
文章のみで構成されたドキュメントを作成することは皆無です。利用手引とかは画面イメージ＋簡素な説明ですし、設計書は図なり表組なりが必須でしょうか。
＃業種ばかりか会社まで限定されそうだけどまーいいか
＞縮小印刷と余白
確かに、納品物として提出する書類はA4縮小しない（100%印刷）ですね。縮尺をいじるのは添付資料に限定されそうです。
もう一つ余白の方なんですが、上下左右の印字余白のことではなくて、Wordでの表の余白（htmlのcellpaddingにあたる）やテキストボックスの『内のり』のことなんです（実は
WordにExcelオブジェクトを挿入してもいいんだけど、修正しにくくなるので個人的には消極的。それならWordのみで作っちゃった方がいいと思います。
＃最近思うんですが、他社から納品されるdocumentって誤字脱字や表セルのはみ出しとか多くなった気が…
＃句読点や「てにをは」の校正、印字チェックは最低限で済ます風習なのかも
＃…会社に入った頃はドキュメント整備の工数も取れてたもんなぁ（苦笑
HTMLってのはいいですね。
許されるなら操作オンラインマニュアルをWikiで書きたいほど。
（PVCSなどのTrackerは敷居が高いですし）
検索はアスキー文書の強みだと思います。
バイナリ対応の検索環境の存在は耳に入ってたんですが、記述のあった"MitakeSearch","Kabayaki"、ちと後学のために自分でも調査してみますね。
ちなみに、アスキーデータならWebとして公開してGoogleBOTに食わせようかとも思ってました。Namazuの環境構築をすっ飛ばす代わりに全世界に発信もちょっと考え物ですが。
---- 何ぃ！ザシャー
Re:Excelの方が作者のルールに制約されやすい欠点が。 (スコア:1)
いえいえ、こちらこそ色々な人の意見が聞けて参考になります。
私がExcel反対はになったまさしくその原因は、富士通のSDEMドキュメントのせいなのです。といっても、SDEMで想定されていなかったパッケージ導入だったので、ヘッダーだけ流用してフォーマットはすべてこちらで１から起こしましたけどね。
ともかく、SA/UI行程のドキュメントそれぞれ数百ページにわたる設計書をすべてExcelで作りました。SDEMは１ページごとに枠線がひかれているため、最初書く分にはまだいいのですが修正する時には一苦労でした。それこそ数日がかりということもありました。
確かに図を用いた設計書の場合、HTMLだけでは表現しきれないということもあります。ですが、表であればHTMLでも十分表現することは可能です。
図の部分をExcel・PowerPointで作り、メインをHTMLで作成、適宜リンクを張っていくという方法が楽でいいのかなぁと考える次第なのです。
同感ですね。
私の周りには散々言っているのですが、内容ではなくフォーマット・見栄えに力を掛けるの、そもそも本質からはずれるので嫌いですし行う意義を認めることができません。
ですが、フォーマットがきめられているのであればそれに併せて見栄えを整えるのは最低限のことだと思います。SDEMのときに散々苦労はしましたが、その後のプロジェクトで他人が書いたぐちゃぐちゃのフォーマットを見ると、やはり体裁を整えることは必要だなと思います。
Wikiもいいですね。
設計書作成ではなく、プロジェクト内でのコミニュケーションツールとして最適ではないかと思っています。いい感じにゆるくて、みんなで好き勝手書いていける。
昔の会社だと、内部向けの資料さえWord・Excelで体裁を整えなければいけない、というような風潮があり非常に疲れました。情報を伝えることを主目的のはずなので、せめて内部向けのコミニュケーションに対して変な労力をさきたくないですね
PVCSは初耳ですが、なんだか結構おもしろそうなソフトですね。私も折角なのでちょっと調べてみます。
Re:Excelの方が作者のルールに制約されやすい欠点が。 (スコア:1)
＃Wikiから連想でつい書いちゃったもんで
とりあえずPVCSについての情報を。
MERANT社 [merant.com]の提供するVersionManager製品群です。
その中の"PVCS Tracker"が俗に言うTracker、つまりプロジェクト内で案件などの情報共有を実現するものと考えればいいでしょう。
以前Tracker導入を検討したときにWikiも対象に含めたんでつい勇み足で…
---- 何ぃ！ザシャー
(la)tex (スコア:0)
Re:(la)tex (スコア:1)
企業です。母体は結構大きなメーカーさんです。で、職場はそのメーカーさんの研究系の部署になります。
有名どころの大学から入ってきている人が多くて、しかも有名どころの大学の教授さんとかになっていく人も多いみたいなので、TeX が根強く使われているのもうなずけるっちゃあうなずけるわけです。
ちっとも有名じゃない弱小やる気なし大学もどきから今の会社に無理やり入って、そこから派遣でやってきている身としてはかなり肩身が狭いばっかりで。。。(なぁんて書いたら知ってる人が AC でやってきて「またまたぁ、いっつもふんぞり返って仕事してるふりしながら /. 見てカキコミしてるくせにぃ。# 関係者なので AC」とかレス付けられたらちょっといやだなぁとか思ってみたり T-T/)
TeX は今の職場を離れてしまったらその後は仕事では二度と使うことは無いかもしれなくてそれはちょっとあまりにももったいないので、自宅でも普通に使えるようにもうちょっと真面目に勉強しようかとも思っていたりします。XML → (La)TeX コンバータなんて作ってみようかしら (何か間違ってる…)。
むらちより/あい/をこめて。
Re:(la)tex (スコア:1)
> XML → (La)TeX コンバータなんて作ってみようかしら (何か間違ってる…)。
Javaベースでよければ、すでに実装されています。
ApacheのサブプロジェクトのApache cocoon [apache.org]です。まだ評価はしていませんが、XMLからHTML、TeX、LaTex、PDFなどへの変換ができるようです。
Javaベースなのでどこでもすぐに動くわけではありませんが使いではあるかもしれません。
# あー、左手疲れた。
Re:(la)tex (スコア:0)