コンテキストとは

『コンテキスト ＝ 文脈、前後関係、事情、背景、状況など』

ITの分野では、利用者の意図や状況、環境などの総体を表したり、同じ処理や記述でも状況に応じて動作などが異なる場合に、その選択基準となる判断材料や条件などを指す場合が多い。

前提知識、みたいな感じですかね。
これソフトウェア開発のドキュメンテーションどうするかにすごく関係してきます。
全てはどこまでのコンテキストを想定するか、それが問題です。

ドキュメントの目的は「関係者にコンテキストを共有する」ことです。

• どんな理由で、何を目的として（Why）
• どう実現するか（How）

システム開発あるある

• 「ドキュメントがなんにもない」
• 「なんかあったけどメンテナンスされてなくて間違ってる」

スタートアップや開発スピード優先のチームにありがち
ドキュメンテーションの時間をプログラミングに当てるという戦略を採った感じですね

でこれ何が困るかというと、新しくJoinした人が途方にくれるんですよね
既存メンバーではコンテキストが共有されているので問題なく回っているけど...

さて、そんな不幸な経験をした人は大体一回はどちらかの思想にはまります。

• 保守派：初めての人でも読めば分かるドキュメントちゃんと作らな！
• 革新派：ドキュメントなんか要らんねんコード読めや！

保守派

ドキュメントを作ると言えばウォーターフォール開発ですよ！

要件定義 → 外部設計 → 内部設計 …

この流派のポイントは
「各工程のエンドで完璧なドキュメントがあるから、コンテキストがゼロでもOK（※理想は）」
ということなんです

ドキュメントがあるので前工程のことを一切知らなくとも完璧にわかる（※理想は）
工程ごとにベンダースイッチすることも可能（※理想は）

• メリット　：メンバースイッチコストが安い（※理想は）
• デメリット：開発スピードが遅い（特にドキュメントメンテしはじめると遅い）

皆さんも経験があることでしょう「工程が進むほど工数が膨大になっていく問題」
（ソースコードにしたら数行なのにドキュメントの影響範囲が大きすぎてすごく大変という問題）

これは決して開発ベンダーが工数をぼったくっているわけではなく、仕組み上仕方がないのです。
一度作ってしまったドキュメントは一生面倒を見ていかなければならないのです。
ドキュメントが負債になっているパターンですね。

ドキュメントは「資産でもあり負債でもある」この視点は重要です。
「無いよりは有ったほうが良い」は幻想です。
使ってない土地にだって固定資産税は掛かるのです。

革新派

実際にプロダクトとして動いてるのはコード。だからコードが常に正しい。
すべてはコードを作るための付属品。プログラミングに必要なら作る。なくても作れるなら不要というスタンス。
API仕様とかコードから生成すれば良いんじゃないと考えている。

アジャイル開発はどちらかというとこちら派閥ですね。ただし

• そもそも読みやすく理解しやすいコード体系
• コードコメントとかはきちんとする
• wikiとかreadmeとかちゃんと頑張る
• あえてこの流派を選ぶチームはスキルが高い傾向がある
• 別にドキュメンテーションが嫌いなわけじゃないが無駄なドキュメントは嫌い

何回も同じこと書くのは悪、という感じです。

• メリット　：開発スピードが速い
• デメリット：メンバースイッチコストが高い

よくある勘違いに「アジャイル開発ってドキュメント作らなくてよいんでしょ？」というものがあります。
これは正しくもあり、間違ってもいます。

アジャイル開発においては「ソースコードも含めて全てがドキュメント」です。
そのため「ソースコードで分からない情報を補完するためのドキュメントを作る」が正しいです。

『概ねHowの部分はコードに書かれているので、Whyを補完するドキュメントを作成します。』

バランス派

たくさんの前提知識をチームで共有しておけば開発スピードが上がります。

これはどちらか一択ではなく、無段階のスライダーをどこに設定するかというビジネス戦略です。

『大切なことはシステムのビジネス特性を踏まえて検討すること』

• ビジネスのスピード感
• メンバースイッチ予測（変更というよりは追加ですかね。サービスが成功したりすると規模が大きくなります）

実際ウォーターフォールでもある程度のコンテキストを前提としています。
（例：日本語が分からない人向けに日本語の説明から入ったりはしない。知っているのは前提だから）

開発スピードを上げるためには多くのコンテキストを前提とし、その分メンバースイッチコストが上がります。
これはトレードオフであり、まさにビジネスをどう展開したいか次第です。
（上記の例だとメンバーを「日本語が読める」に限定してスイッチコストを上げていますし、
枯れている言語やフレームワークを選択することはスイッチコストを下げます）

最近の風潮で言うとビジネススピードが上がっているのでスライダーがハイコンテキストに寄りがちな傾向があります。
かと言ってサービス規模が大きくなるとJoinする人が増えるので、ドキュメントなしは辛いよね、とのせめぎあいです。

個人的には新規に何か始めるときには、ハイコンテキストから初めて徐々にドキュメントを作成するに寄せていくのが良いんじゃないかと思っています。
（大当たりすると思ってプロセスきっちり守って開発したけど鳴かず飛ばずとかあるあるなので、はじめにコストを掛けるのもある意味リスクです）

作るべきもの、作らなくてもよいもの、バランスよく選択していきたいですね。