要件定義の不安をなくす。要件定義の不安をなくす。ユニファのバックエンド分割に学ぶイノベーションメタバース開発に必要な技術の基本知識をおさらい。Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。Word、以下ワード)。ワードは使いにくいというイメージを持つ方もいますが、技術者にとってワードは使いやすいドキュメントツールだと筆者は思っています。ドキュメントを共有するメンバーに顧客や技術者でない方がいる場合には、より現実的な選択肢となるツールだと思います。積極的にワードを選択して利用する方でなくても、ちょっとした使い方や注意点を知るだけで、使いやすいツールに変わるはずです。そこで、筆者が必ず利用する機能や注意点に限定して、ワードの使い方について紹介します。最後にはじめに既存のシステム開発の現場においてドキュメントはExcelが使われていることが多くあります。最近ではMarkdownからのHTMLやPDF出力なども使われることも増えてきています。本来、ドキュメント編集であれば、それに特化したワードを使う方がExcelやMarkdownを使うよりも、より多くの人が利用しやすいはずです。ワードと言うと、実際にはあまり利用されていない印象があります。筆者の経験では、技術的なドキュメントと言うと一昔前では記述者名や日付、プログラム名などがすべてのページに決まって印刷される帳票形式のドキュメントが多く、その場合には、Excelのように表組みが得意な形式が好まれました。プログラムからHTML形式のドキュメントを自動生成するツールなども広がり、リファレンス的に参照される用途ではそちらのほうが便利であるように思います。いった背景からHTML形式のドキュメントも普及してきています。技術者も仕様書や要件定義書や利用マニュアルのように顧客や役割が違う人たちと一緒にドキュメントを記述するニーズも多くなってきています。その際には、より幅広い用途でかつ、幅広い人たちが使えるドキュメントツールが望ましいはずです。ドキュメント全体の統一感も大切な要素の一つです。そこで本稿では、そういった利用シーンにおいて筆者がよく利用する機能に限定してワードが使いやすくなる方法やヒントを紹介します。技術者が記述するドキュメント作成という目的で説明します。技術的なドキュメントを記述する上では、版組などの知識はあまり必要なく、章立てなどの構造や内容の方が重視されます。多彩な機能を使いこなす必要はないということです。技術者の視点を持つことでわかるワードというツールの特徴についても紹介します。ExcelやMarkdownの課題点とはよく見るドキュメント形式としてExcel形式があります。API仕様やプログラムや環境構築の作業手順などを記す場合などではMarkdownなども用いられています。汎用的なドキュメントである仕様書やマニュアルを作成する用途では少々、使いにくいと感じている方もいるのではないでしょうか。ワードをどこでどのようなシーンで利用するとより効果的かを考える前に、既存の方法の課題点についてまず考えてみます。慣例的にExcelを使ってドキュメントを作成している場合には、Excelならではのシートやセルといった本来、ドキュメントとは関係ない管理構造が問題になることが多々あります。以下の問題が生じるはずです。ほしい情報がどこに書いてあるのか探しにくく、直感的にわかりにくい(どのシートなのか、どのファイルなのかなど)印刷したときに微妙に印刷ずれや、印刷フォーマットを優先するために文章を不自然な場所で改行したり分割する必要があり、検索もしにくい。大量のページ数がある場合、目次などの情報がないので、全体像がわかりにくい。表示形式よりも、デジタルでの検索や参照の利便性を追求する場合には、HTMLやシステムデータとしての素材としてのMarkdown形式が望ましい場合もあります。こちらも同様に、以下の課題があります。ドキュメント記述をする人がMarkdownを使ってくれない/覚えてくれない。顧客に見せる場合など、紙やPDFを想定した出力がしにくい、または難しい。編集中に出力イメージがどうなるかわかりにくい。これらの欠点を部分的に補う方法はあります。Excelであればファイルを分割しファイル名のルールで解決しても良いでしょうし、Markdown形式が使えるエディタソフトを利用したり、または、自動変換プログラムを使ったり、などなど、さまざまな手法を駆使すれば欠点を補うことはある程度可能です。そのような方法は却って利用の難易度が上がってしまい、多くの人にとっては扱いにくくなる場合があります。これらの欠点を補いつつ、より汎用的なドキュメントを記述する際には、ワードのほうがより現実的なのではないか、と著者は思うようになりました。文章が多いドキュメントを記述するのであれば、ワード(ワードに限らず、文書編集アプリ)を使いましょうという話は多いですが、残念ながら、実際にはあまり使われていないと思います。それらの大きな理由の一つに、ルールがわかりにくいという点があります。図1のような問題がよく起きます。文章を書き出す位置が自由にならない図を思い通りに移動できない。図を移動するとテキスト位置がおかしくなる勝手に箇条書きになる。箇条書きにならない文章の行頭の位置や、段落毎の位置が調整できないこれらの中には、改行や空白などを無理矢理入れることで解決可能な問題もありますが、そのような力技で解決するならば、Excelの方がむしろ使いやすい人も多いでしょう。多くのITに携わる方にとっては、このような問題が生じても、調べればその場、その場の問題は解決できるかもしれません。一方で、多少の違いがあると分からなくなる、毎回、同じ問題で悩む、もしくは、操作方法が覚えられないという人もいるはずです。単純に使い慣れていないということも理由として大きいとは思いますが、筆者の経験上そのような人は、ドキュメントの管理構造を意識したことがないため、その管理のルールが想像できないケースが多いと感じています。そのような人は、「段落」にはどのような設定ができるべきか、または、「箇条書き」にはどのような設定ができるべきかということがイメージできません。よって、操作や設定が存在するのか、また存在する場合、それをどこで設定出来るべきかという視点が持てないので、複雑なツールに見えてしまっているのではないでしょうか。技術者がワードを使うメリット先ほどワードの使いにくさや理解しにくさの原因の一つは「ドキュメント構造の理解」であると述べました。漠然と「ドキュメント構造」といってもイメージしづらい方もいることでしょう。HTMLの構造と言えばどうでしょうか。分かりますという方もいるはずです。HTMLはドキュメント構造の表現方法の一つです。「段落」であれば<p>で表します。ドキュメントの本文といえば<body>タグ、画像と言えば<img>タグ、箇条書きは<ul>や<ol>タグ......というように、具体的にイメージできる方も多くなるはずです。それぞれのタグに適用できるスタイル構文があり、それらが位置、装飾を含め表示ルールを決めています(HTMLの表示設定の難しさは、その親子関係などで決まる場合などがあり、少々難しい面もありますが)。タグのような内部構造を直接編集できないにせよ、ワードもまさに同じような考え方で構成されています。HTMLと同様にスタイルを定義する際には、親子関係が関係するため、同じように難しさもはらんでいます。筆者が、技術者がワードを使うメリットがあると思う理由はその点です。HTMLを既に知っている人であれば、その理解をワードに応用することもできます。段落の書き始め位置を決める際にも、そのページの余白設定を利用するのか、または、その段落のマージン設定なのか、または、その段落の絶対位置なのかなど、多彩な設定があります。それらの設定に応じて、そのほかの要素が影響してしまうということを、HTMLの経験から理解できる人もいるはずです。HTMLを知らなくても、ワードでドキュメントを作成することに慣れていけば、ドキュメント構造にも自然と慣れていけます。記述する内容をグループで考え、それらを構造化する癖をつけることは、システム設計やプログラム設計時の構造を意識する際にも役立ちます。このように、さまざまなことを構造化して考える必要がある技術者にとっては、ワードが難しいと思う必要はなく、何事も構造化して考える癖をつけることはメリットが多い習慣なのです。NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。ASP/ASP.NET。執筆コミュニティ「WINGSプロジェクト」代表。NEW新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。