Microsoft Wordなどではなく、プレーンテキストのマークアップ言語を使用する場合の開発プロセスで直面する障害は何ですか？

Question

私は現在、政府の請負業者のインターンであり、Wordがソフトウェア開発プロセスの事実上の標準であるという（不愉快に避けられない）感情を感じています。

そのバイナリ形式では、コードベースでの共同作業に慣れている方法でドキュメントを共同作業することが非常に困難になります。プレーンテキストマークアップ（LaTeX、Markdown、ReStructured Text、etc。などの言語を使用）を使用すると、開発者の通常のワークフローでうまく機能するdiffフレンドリーなドキュメントが可能になります。言語でサポートされていないコメント（Markdownなど）については、コードベース（GitHub、Bitbucketなど）で共同コメントを許可する既存のソリューションが多数あり、簡単にを他のプレーンに適用できます-マークアップを含むテキストファイル。

技術的に文盲の管理に協力する必要性がすべてに何らかの種類のグラフィカルインターフェイスを必要とすることを理解していますが、そのようなインターフェイスはこれらのフォーマットのほとんどに存在します。たとえば、LaTeXには、LyXと呼ばれる一種の「フォーク」があり、グラフィカルなフロントエンドをプレーンテキストのLaTeXのような構文に配置します。このファイルは、編集は主にグラフィカルですが、まだ差分に対応しています。（Wordスタイルのコメントも含まれています。）これらのソリューションの多くはまだWordの代わりに使用でき、大半は無料またはオープンソースです。

ただし、Wordは、他の誰にも見られない独自の内部ドキュメントにも使用されます。私たちはキャリアのかなりの部分をテキストで扱っています-なぜドキュメントがそれほど特別なのですか？「私たちはこれ以上何も知らなかったため、ここで立ち往生している」というささいなことを除けば、そのような決定を支持する理由があるはずです。他の口語的な（そして議論の余地のないほど強力な）文書を書く手段の代わりにプレーンテキストの文書を使用する場合、ソフトウェア開発プロセスが直面する課題は何ですか？

理由は異なるため、おそらくこれら2つの密接に関連するシナリオに個別に答えることが必要です。

最初からプレーンテキストのドキュメントを使用する
時間の経過とともにプレーンテキストのドキュメントに移行する

Jimmy Hoffa · Accepted Answer

ソフトウェア開発プロセスの多くの参加者は開発者ではないため、関係なくドキュメントと対話する機能が必要です。 QA /マーケティングではWordを使用し、開発者は他のものを完全に使用する必要がありますか？一貫性がなく、メンテナンスチェーンに別のツールが追加され、企業のIT部門は、Word文書ストアの管理方法や保守方法を完全に理解している場合、ファイルの処理方法がわからない可能性があります。

何よりも、多くの非開発者が大学で長年Microsoft Wordを使用して仕事を提出し、Wordの使用方法に関する実際のトレーニングクラスを頻繁に行ってきました。彼らはそれを代替案よりはるかによく知っています。 Open OfficeとWordで作業しているときの違いはほとんどわかりませんが、義理の姉にお金を節約するために使用させたところ、1週間後に夫にWordを購入してもらい、「大好きなWordを手に入れてから私の新しいラップトップ！」そのようなものを膨らませる考え方について考えてみてください。彼らが慣れ親しんでいるもののわずかな変化は、彼らにとって「わずか」ではありません。

最新のWordでは、バージョンの違い、バージョン追跡付きの注釈、変更のマージも可能です。コードのマージほど簡単ではないかもしれませんが、多くのプロジェクトマネージャーが簡単に行うことができるので、開発者も確実に行うことができます。

それ以上に、開発者以外の人が編集できるほどシンプルなままテキスト表現に戻るため、開発チームの間でウィキでドキュメントを作成することは非常に一般的になっています。

aboy021 · Answer

個人的には教育の問題だと思います。

ほとんどの人は、MS Wordなどのツールを使用すると高品質のドキュメントを簡単に作成できると思い込んでいますが、私が見たところ、実際にはそれが難しくなっています。結局、フォーマットを際限なくデバッグし、必要な結果を得るためにツールと戦わなければなりません。

Scrivener のようなツールを使用すると、Wordの場合のようにドキュメントと戦わなくても、ドキュメントの現実に少し近づくことができます。 WYSIWYGが実際にうまく機能していないという認識のせいもあります。

私の組織では、ほとんどのドキュメントのニーズにMarkDownを使用する人が増えるほど、より幸せで生産的な人が増えます。

stoj · Answer

あなたは本当に2つの質問があります：

まず、非開発グループがソフトウェア開発プロセスでLaTeXやその他のMarkdownを使用しないのはなぜですか？

LaTeXへの移行に伴う問題は、特に技術者以外のユーザーとやり取りする場合に認識される学習曲線です。ユーザーはすでに他のフォーマットを知っており、彼らが行っているのと同じことを行う別の方法を学びたくありません。彼らは2つのドキュメントを比較する方法について少しでも知っているので、それらをテキストベースの形式に変更してもほとんど意味がありません。あなたが彼らが持っていることを知らなかった問題の解決策を持っていることを人に説明することはかなり難しい売りです。

また、前進運動量の価値を過小評価することはできません。新しいフォーマットに移行するためには、チェーン内の他の人々を本当に説得する必要があります。何か新しいことを学ぶことに投資することは価値があります。彼らが何かを編集することを期待していない場合でも、既存のフォーマットが機能する場合（たとえ不十分であっても）、新しいフォーマットに移行するには時間と多大な労力が必要です。

2番目の質問：私のチームは、より良いオプションがあり、それらがそれらを学習する能力を超えているのに、なぜWord文書を引き続き使用するのですか？

これは、チームの人々と話し合うべきことです。彼らがWord文書を維持することを選択する正当な理由があるかもしれませんか、それはそれが常に行われてきた方法であるだけであるかもしれません。

変更に関連するコストがあり、数百または数千のドキュメントを新しい形式に移動するには、費用と時間がかかります。あなたが環境を変えようとするつもりなら、なぜ変える必要があるのかについての主張をしなければならないことを期待します