サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2 id="content0">はじめに</h2>

<p>この記事は&nbsp;<a href="https://qiita.com/advent-calendar/2023/dmm" target="_blank">DMMグループ Advent Calendar 2023</a>&nbsp;の10日目の記事です。</p>

<p>こんにちは。動画配信事業部でフロントエンドエンジニアをしている今西(<a href="https://twitter.com/nisshii0313" target="_blank">@nisshii0313</a>)です。<br />
ここ2年くらいは<a href="https://tv.dmm4all.top/vod/" target="_blank">DMM TV</a>というサービスの開発に従事しており、主に動画再生プレイヤーまわりのコンポーネントの開発および保守・運用を行っています。<br />
最近では各種テレビや<a href="https://prtimes.jp/main/html/rd/p/000004300.000002581.html" target="_blank">PS4</a>、<a href="https://prtimes.jp/main/html/rd/p/000004195.000002581.html" target="_blank">PS5</a>でもDMM TVを視聴可能にするための開発・保守・運用を行っています。</p>

<p>このDMM TVですが、今年の12月でリリースから1周年を迎えることができました。<br />
おかげさまで、徐々に新機能の追加を含めた保守・運用フェーズに移行してきています。</p>

<p>しかし、動画再生プレイヤーの開発知見(特に各種テレビ・PS4・​PS5向け)においては「属人化問題」に直面しつつあります。</p>

<p>今回は、その属人化対策として、「Di&aacute;taxis」というフレームワークを用いた体系的なドキュメント整備のアプローチ方法についてご紹介します。</p>

<h2>Di&aacute;taxisとは ~概要~</h2>

<p><a href="https://diataxis.fr/" target="_blank">Di&aacute;taxis</a>は、体系的なドキュメント作成に用いられるフレームワークで、ドキュメント化したい内容を次の4要素に分類することで「整備しやすさ」「読みやすさ」を両立することを目指しています。</p>

<ul>
	<li>Tutorials</li>
	<li>How-To&nbsp;guides</li>
	<li>Reference</li>
	<li>Explanation</li>
</ul>

<p>各要素について詳しく説明をする前に、具体的な内容(知識)について4要素で分類をし、雰囲気を掴んでみます。<br />
その際に、知識自体の「とっつきやすさ」、つまり初学者から見た理解しやすさという軸で簡略化して考えてみます。</p>

<h2>Di&aacute;taxisとは ~まずは簡略化して捉えてみる~</h2>

<p>私がフロントエンドエンジニアということもあり、フロントエンド分野の知識について前述した&ldquo;とっつきやすさ&rdquo;を軸に軽く分類すると次の図のようになります。</p>

<p style="text-align:center"><img alt="フロントエンド知識の階層化" height="340" src="https://image.dmm-corp.com/8cyfmjfyh141zw1ez8j5weq1mmh9" width="800" /></p>

<p>さらにDi&aacute;taxisの4要素に振り分けてみると次のようになります。</p>

<p style="text-align:center"><img alt="階層化したフロントエンド知識を4分類" height="340" src="https://image.dmm-corp.com/6t8kp24e4glmfk5n0nuvzcpjywcn" width="800" /></p>

<p>TutorialsやHow-To guidesは「基礎」で、普段仕事をするために必要な実践的な内容が該当します。</p>

<p>一方、ReferenceやExplanationは「専門的」で、数年後のスタンダードを決めるような議論の場が該当します。</p>

<p>大まかに4要素の雰囲気が掴めたところで、各要素の詳細な要件やうれしい点について説明していきます。</p>

<h2>Di&aacute;taxisとは ~各要素について~</h2>

<h3>Tutorials</h3>

<blockquote>
<p>Tutorials are&nbsp;<strong>lessons</strong>&nbsp;that take the reader by the hand through a series of steps to complete a project of some kind. Tutorials are&nbsp;<strong>learning-oriented</strong>.</p>
</blockquote>

<p>とあるように、初学者にとっての&ldquo;とっつきやすさ&rdquo;が求められています。ライブラリのREADMEの内容を整備するような感覚ですね。</p>

<p>具体的には、主に以下のような要件があります。</p>

<ul>
	<li>学習に必要なものを、あらかじめ十分に提供してスタートラインを揃える</li>
	<li>学習フローとして詰まらないことを担保する</li>
	<li>学習者目線で、それまでのフローにミスがないことを確認しやすくする</li>
	<li>仮に学ぶ中でミスを犯しても、最初からやり直しやすいこと</li>
	<li>なるべく具体的な手順を記載する</li>
	<li>誤解を招かないためにも、必要十分に書くようにする</li>
</ul>

<p>環境をコンテナ上で用意したり、各手順で期待値のスクショを載せたり、ミスや不必要になれば立ち上げた環境ごとdownやdestroyしてもらう感覚ですね。</p>

<p>こうすることで、読み手にとっての学習コストを下げたり、最初の1歩のハードルを下げることができます。</p>

<h3>How-To&nbsp;guides</h3>

<blockquote>
<p>How-to guides are&nbsp;<strong>directions</strong>&nbsp;that take the reader through the steps required to solve a real-world problem. How-to guides are&nbsp;<strong>goal-oriented</strong>.</p>
</blockquote>

<p>とあるように、実務上の課題とその解決策がある前提で、ケースごとに紹介していくことが求められています。ポストモーテムを書くような感覚と似ているかもしれません。</p>

<p>具体的には、主に以下のような要件があります。</p>

<ul>
	<li>課題とその解決策にフォーカスして、詳細説明などは別セクションに委ねる</li>
	<li>課題とその解決策が端的に伝わるようなタイトルにする</li>
	<li>ある程度汎用的に活かせる課題解決のほうが好ましい</li>
</ul>

<p>書き手にとっては散乱しがちな実装や課題解決の経緯をまとめておく場所ができ、読み手にとっては今タイムリーに必要な具体的な解決策を、タイトルから検索するだけで探すことができます。</p>

<h3>Reference</h3>

<blockquote>
<p>Reference guides are&nbsp;<strong>technical descriptions</strong>&nbsp;of the machinery and how to operate it. Reference material is&nbsp;<strong>information-oriented</strong>.</p>
</blockquote>

<p>とあるように、情報の正確性と必要十分な詳細さが求められます。世間一般的に&quot;ドキュメント&quot;と言われるものは、ここを網羅しているものが多いのではないでしょうか。</p>

<p>具体的には、主に以下のような要件があります。</p>

<ul>
	<li>語彙に一貫性を持たせる</li>
	<li>個別具体的な説明や議論、指示、推測はノイズになるので、他箇所に委ねるか省く</li>
	<li>ノイズにならない程度に理解を助けるものとして、各項目に凡例を載せる</li>
	<li>常に正しく、最新であることを心がける</li>
</ul>

<p>書き手にとっては前述までで省いてきた詳細をここにまとめておくことができ、読み手にとってはHow-To&nbsp;guidesで事足りない場合に頼るという使い分けができます。</p>

<h3>Explanation</h3>

<blockquote>
<p>Explanation is&nbsp;<strong>discussion</strong>&nbsp;that clarifies and illuminates a particular topic. Explanation is&nbsp;<strong>understanding-oriented</strong>.</p>
</blockquote>

<p>とあるように、議論の場であることが求められます。ライブラリや提供するサービスの仕様について議論するといった、いわゆるOSSのissue内での議論やサービス開発の上流工程のイメージで良いかと思います。</p>

<p>具体的には、主に以下のような要件があります。</p>

<ul>
	<li>これまでとは打って変わって、関連性のある項目の内容に積極的に触れていく</li>
	<li>なぜ？に答えるために、背景情報を説明する</li>
	<li>議論の場として提供し、反論の余地も残しておく</li>
	<li>上記を満たしながらも、他の3セクションと役割的に被らないように注意する</li>
</ul>

<p>このセクションが存在することで、書き手同士の間で議論が生まれ、結果としてReferenceが更新されるなどの新しい知見が生み出されます。</p>

<h2>弊チームでの取り入れ方</h2>

<p>公式ドキュメントにも記載がありますが、Di&aacute;taxisはあくまでフレームワークとしてドキュメントの体系化を助けてくれるだけで、その活かし方はケースごとに最適な形を見つけていく必要があります。</p>

<p>今回の「DMM TVの再生プレイヤー部分についての開発知見(特に各種テレビ・PS4・PS5向け)」という場合ではいくつかカスタマイズしている点があるのでご紹介します。</p>

<h3>別枠でドキュメントの歩き方(Q&amp;A)を用意</h3>

<p>読み手にDi&aacute;taxisの理解を求めるのは少々酷な話です。</p>

<p>そこで読者パターンをいくつか想定して、どこから読み進めるべきかをQ&amp;A形式でまとめています。</p>

<h3>How-To&nbsp;guidesをラベルで管理</h3>

<p>前述したように、How-To&nbsp;guidesの肝としてタイトルによる検索性が挙げられていました。</p>

<p>ドキュメント管理ツールにもよるとは思いますが、弊社で使用している「Confluence」ではラベル機能があるので、動画の配信形式やデバイスなどのトピックごとにラベルを用意し、検索性を担保しています。</p>

<h3>Explanationは省く</h3>

<p>Explanationは議論の場ですが、あくまで今回やりたいことは「知見の属人化回避」です。</p>

<p>サービスの機能追加や仕様の議論、動画配信技術についての先進的な取り組みは別のドキュメントでまとめられているため、省きました。</p>

<h2>まとめ</h2>

<p>Di&aacute;taxisを使う使わないに関係なく、共同でドキュメントを整備していくには何らかのフレームワークに従わないと乱れが生じることは想像に難くないと思います。それが原因でドキュメントが形骸化していく例もこれまでに何度か見てきました。</p>

<p>Di&aacute;taxisは比較的理解しやすく簡単に始められるフレームワークかなと思います。ぜひ使ってみてはいかがでしょうか。</p>


DMM TVはリリースから1周年を迎えました。サービスも成長し、保守・運用段階に移行してきています。しかし、再生プレイヤーの開発知見については属人化問題に直面しつつあります。そこでその対策として、Diátaxisを用いた体系的なドキュメント整備のご紹介をします。

Diátaxisによる知見の体系化を図ろうとしている話

シェア

関連する求人

関連する記事

関連するサービス