たとえばMicrosoft Wordとは対照的に、プレーンテキストマークアップ言語を使用する場合、開発プロセスに直面する障害は何ですか？[閉まっている]

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

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

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

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

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

• 最初からプレーンテキストのドキュメントを使用する
• 長期にわたるプレーンテキストドキュメントへの移行

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

何よりも、多くの非開発者は大学でMicrosoft Wordを使用して仕事に転向するために何年も費やしており、多くの場合、単語の使い方だけで実際のトレーニングクラスがありました。彼らはそれを他の選択肢よりもはるかによく知っています。Open OfficeとWordで働いているときの違いはほとんどわかりませんが、義理の妹にお金を節約させるためにそれを使ったとき、1週間後に彼女の夫に彼女のWordを買ってもらい、私の新しいラップトップ！」。そのようなものを制約する考え方について考えてください。慣れているもののわずかな変化は、彼らにとって「わずか」ではありません。

最新の単語では、バージョンの違い、バージョントラッキングによる注釈、および変更のマージも可能です。コードをマージするほど簡単ではないかもしれませんが、多くのプロジェクトマネージャーが簡単にそれを行うのを見たことがあります。

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

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

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

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

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

本当に2つの質問があります。

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

LaTeXに移行する際の問題は、特に非技術ユーザーを扱う場合に認識される学習曲線です。ユーザーは既に他の形式を知っているので、同じことをする別の方法を学ぶ必要はありません。彼らは2つのドキュメントをどのように比較するかについてほとんど知らないので、それらのテキストベースのフォーマットに変更することはほとんど価値がありません。自分が持っていると知らなかった問題の解決策があることを人に説明することは、かなり難しい販売です。

また、前方運動量の価値を過小評価することはできません。新しい形式に移行するには、チェーン内の他の人に、新しいことを学ぶことに投資する価値があると確信させる必要があります。あなたが彼らが何かを編集することを期待していなくても、既存のフォーマットが機能しているとき（たとえ貧弱であっても）新しいフォーマットに移行するには時間がかかり、多くの労力がかかります。

2番目の質問：優れたオプションがあり、それらを学習できる以上の能力がある場合、チームはなぜ単語文書を使用し続けるのですか？

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

変更にはコストがかかり、数百または数千のドキュメントを新しい形式に移動するのは費用と時間がかかります。環境を変更しようとする場合は、変更する必要がある理由を説明する必要があります