SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

ドキュメント作成にはMS-Wordを使おう

MS-Wordで実用的なドキュメント作成、使うメリットと注意点とは?

ドキュメント作成にはMS-Wordを使おう 第1回

  • このエントリーをはてなブックマークに追加

 仕様書や要件定義書を記述する際に利用されるMS-Word(Microsoft Word、以下ワード)。ワードは使いにくいというイメージを持つ方もいますが、技術者にとってワードは使いやすいドキュメントツールだと筆者は思っています。特に、ドキュメントを共有するメンバーに顧客や技術者でない方がいる場合には、より現実的な選択肢となるツールだと思います。積極的にワードを選択して利用する方でなくても、ちょっとした使い方や注意点を知るだけで、使いやすいツールに変わるはずです。そこで、筆者が必ず利用する機能や注意点に限定して、ワードの使い方について紹介します。

  • このエントリーをはてなブックマークに追加

はじめに

 既存のシステム開発の現場においてドキュメントはExcelが使われていることが多くあります。また、最近ではMarkdownからのHTMLやPDF出力なども使われることも増えてきています。

 本来、ドキュメント編集であれば、それに特化したワードを使う方がExcelやMarkdownを使うよりも、より多くの人が利用しやすいはずです。

 しかし、ワードと言うと、実際にはあまり利用されていない印象があります。筆者の経験では、技術的なドキュメントと言うと一昔前では記述者名や日付、プログラム名などがすべてのページに決まって印刷される帳票形式のドキュメントが多く、その場合には、Excelのように表組みが得意な形式が好まれました。

 一方、プログラムからHTML形式のドキュメントを自動生成するツールなども広がり、リファレンス的に参照される用途ではそちらのほうが便利であるように思います。そういった背景からHTML形式のドキュメントも普及してきています。

 しかし、技術者も仕様書や要件定義書や利用マニュアルのように顧客や役割が違う人たちと一緒にドキュメントを記述するニーズも多くなってきています。その際には、より幅広い用途でかつ、幅広い人たちが使えるドキュメントツールが望ましいはずです。そして、ドキュメント全体の統一感も大切な要素の一つです。

 そこで本稿では、そういった利用シーンにおいて筆者がよく利用する機能に限定してワードが使いやすくなる方法やヒントを紹介します。

 ただし、あくまで技術者が記述するドキュメント作成という目的で説明します。技術的なドキュメントを記述する上では、版組などの知識はあまり必要なく、章立てなどの構造や内容の方が重視されます。つまり、多彩な機能を使いこなす必要はないということです。また、技術者の視点を持つことでわかるワードというツールの特徴についても紹介します。

ExcelやMarkdownの課題点とは

 よく見るドキュメント形式としてExcel形式があります。また、API仕様やプログラムや環境構築の作業手順などを記す場合などではMarkdownなども用いられています。しかしながら、より汎用的なドキュメントである仕様書やマニュアルを作成する用途では少々、使いにくいと感じている方もいるのではないでしょうか。

 ワードをどこでどのようなシーンで利用するとより効果的かを考える前に、既存の方法の課題点についてまず考えてみます。

Excelの課題

 慣例的にExcelを使ってドキュメントを作成している場合には、Excelならではのシートやセルといった本来、ドキュメントとは関係ない管理構造が問題になることが多々あります。例えば、以下の問題が生じるはずです。

  • ほしい情報がどこに書いてあるのか探しにくく、直感的にわかりにくい(どのシートなのか、どのファイルなのかなど)
  • 印刷したときに微妙に印刷ずれや、印刷フォーマットを優先するために文章を不自然な場所で改行したり分割する必要があり、検索もしにくい。
  • 大量のページ数がある場合、目次などの情報がないので、全体像がわかりにくい。

Markdownの課題

 表示形式よりも、デジタルでの検索や参照の利便性を追求する場合には、HTMLやシステムデータとしての素材としてのMarkdown形式が望ましい場合もあります。

 しかし、こちらも同様に、以下の課題があります。

  • ドキュメント記述をする人がMarkdownを使ってくれない/覚えてくれない。
  • 顧客に見せる場合など、紙やPDFを想定した出力がしにくい、または難しい。
  • 編集中に出力イメージがどうなるかわかりにくい。

 もちろん、これらの欠点を部分的に補う方法はあります。例えば、Excelであればファイルを分割しファイル名のルールで解決しても良いでしょうし、Markdown形式が使えるエディタソフトを利用したり、または、自動変換プログラムを使ったり、などなど、さまざまな手法を駆使すれば欠点を補うことはある程度可能です。

 しかし、そのような方法は却って利用の難易度が上がってしまい、多くの人にとっては扱いにくくなる場合があります。これらの欠点を補いつつ、より汎用的なドキュメントを記述する際には、ワードのほうがより現実的なのではないか、と著者は思うようになりました。

ワードが使いにくい理由は「ドキュメント構造の理解」

 文章が多いドキュメントを記述するのであれば、ワード(ワードに限らず、文書編集アプリ)を使いましょうという話は多いですが、残念ながら、実際にはあまり使われていないと思います。

 それらの大きな理由の一つに、ルールがわかりにくいという点があります。例えば、図1のような問題がよく起きます。

図1:ワードで文書を作成する際のわかりにくい点
図1:ワードで文書を作成する際のわかりにくい点
  • 文章を書き出す位置が自由にならない
  • 図を思い通りに移動できない。もしくは図を移動するとテキスト位置がおかしくなる
  • 勝手に箇条書きになる。または箇条書きにならない
  • 文章の行頭の位置や、段落毎の位置が調整できない

 これらの中には、改行や空白などを無理矢理入れることで解決可能な問題もありますが、そのような力技で解決するならば、Excelの方がむしろ使いやすい人も多いでしょう。

 多くのITに携わる方にとっては、このような問題が生じても、調べればその場、その場の問題は解決できるかもしれません。一方で、多少の違いがあると分からなくなる、毎回、同じ問題で悩む、もしくは、操作方法が覚えられないという人もいるはずです。

 単純に使い慣れていないということも理由として大きいとは思いますが、筆者の経験上そのような人は、ドキュメントの管理構造を意識したことがないため、その管理のルールが想像できないケースが多いと感じています。

 そのような人は、「段落」にはどのような設定ができるべきか、または、「箇条書き」にはどのような設定ができるべきかということがイメージできません。よって、操作や設定が存在するのか、また存在する場合、それをどこで設定出来るべきかという視点が持てないので、複雑なツールに見えてしまっているのではないでしょうか。

技術者がワードを使うメリット

 先ほどワードの使いにくさや理解しにくさの原因の一つは「ドキュメント構造の理解」であると述べました。

 漠然と「ドキュメント構造」といってもイメージしづらい方もいることでしょう。しかし、HTMLの構造と言えばどうでしょうか。おおよそ分かりますという方もいるはずです。まさに、HTMLはドキュメント構造の表現方法の一つです。

 例えば「段落」であれば<p>で表します。ドキュメントの本文といえば<body>タグ、画像と言えば<img>タグ、箇条書きは<ul>や<ol>タグ...…というように、具体的にイメージできる方も多くなるはずです。

 そして、それぞれのタグに適用できるスタイル構文があり、それらが位置、装飾を含め表示ルールを決めています(HTMLの表示設定の難しさは、その親子関係などで決まる場合などがあり、少々難しい面もありますが)。

 タグのような内部構造を直接編集できないにせよ、ワードもまさに同じような考え方で構成されています。そして、HTMLと同様にスタイルを定義する際には、親子関係が関係するため、同じように難しさもはらんでいます。

 しかし、筆者が、技術者がワードを使うメリットがあると思う理由はその点です。HTMLを既に知っている人であれば、その理解をワードに応用することもできます。例えば、段落の書き始め位置を決める際にも、そのページの余白設定を利用するのか、または、その段落のマージン設定なのか、または、その段落の絶対位置なのかなど、多彩な設定があります。

 そして、それらの設定に応じて、そのほかの要素が影響してしまうということを、HTMLの経験から理解できる人もいるはずです。

 また、HTMLを知らなくても、ワードでドキュメントを作成することに慣れていけば、ドキュメント構造にも自然と慣れていけます。記述する内容をグループで考え、それらを構造化する癖をつけることは、システム設計やプログラム設計時の構造を意識する際にも役立ちます。

 このように、さまざまなことを構造化して考える必要がある技術者にとっては、ワードが難しいと思う必要はなく、何事も構造化して考える癖をつけることはメリットが多い習慣なのです。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
作成するドキュメント例

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
この記事の著者

WINGSプロジェクト 小林 昌弘(コバヤシ マサヒロ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。 主な著書に「入門シリーズ(サーバサイドAjax/XMLDB/PEAR/Smarty)」「独習シリーズ(ASP.NET/PHP)」「10日でおぼえる入門教室シリーズ(ASP.NET/PHP/Jakarta/JSP&サーブレット/XML)」「Pocket詳解辞典シリーズ(ASP.NET/PHP/Perl&CGI)」「今日からつかえるシリーズ(PHP/JSP&サーブレット/XML/ASP)」「書き込み式 SQLのドリル」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16705 2022/11/11 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング