アイスブレイク
パソコンが古かったので新しくRyzenのCPUを買いました。
流石に最新のCPUは早いですね、快適です。
まあ、メモリが刺さらなかったり、内蔵GPUないからグラボ要るやん！というトラブルはありましたが…
アジャイルとは
アジャイルをテーマに書いてください、ということなので基本に立ち帰ってみましょう。
そう「アジャイルソフトウェア開発宣言」です。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
要は「気の持ちよう」ってことですね！
・・・
というのは冗談です… が、まあ宣言というものはスローガンで一種の行動指針です。
道に迷ったらとりあえずここに戻って考える。灯台みたいなものですかね。
これから私が感じるのは「ソフトウェア開発に正解なんてない、いくら考えても確実な答えなんて出ないのだからやってみよう」
ということで、俗に言う「Trial And Error」の精神ですかね。
今回は「包括的なドキュメントよりも動くソフトウェアを」の部分について考えたいと思います。
コンテキストとは
まずはドキュメントを語る上で大切な概念「コンテキスト」
コンテキストとは、文脈、前後関係、事情、背景、状況などの意味を持つ英単語。ITの分野では、利用者の意図や状況、環境などの総体を表したり、同じ処理や記述でも状況に応じて動作などが異なる場合に、その選択基準となる判断材料や条件などを指す場合が多い。
前提知識、みたいな感じですかね。
これソフトウェア開発のドキュメンテーションどうするかにすごく関係してきます。
全てはどこまでのコンテキストを想定するか、それが問題です。
ドキュメントとは
まずウォーターフォール的な考えでいくと以下の様なものがいわゆるドキュメントと言われています。
- 要件定義書
- 基本設計書(外部設計)
- 業務フロー、システム構成図、ER図、テーブル定義、機能概要 etc…
- 詳細設計書(内部設計)
- 画面遷移、機能詳細 etc…
- テスト仕様書
（※何がどこにあたるのかは諸説あります）
ドキュメントの目的は「関係者にコンテキストを共有する」ことです。
ざっくり言うと以下のようなことです。
- どんな理由で、何を目的として（Why）
- どう実現するか（How）
システム開発あるある
- 「ドキュメントがなんにもない」
- 「なんかあったけどメンテナンスされてなくて間違ってる」
スタートアップや開発スピード優先のチームにありがち
ドキュメンテーションの時間をプログラミングに当てるという戦略を採った感じですね
（あえてその戦略を採ったのか、それしか道がなかったのかは神のみぞ知る…）
でこれ何が困るかというと、新しくJoinした人が途方にくれるんですよね
既存メンバーではコンテキストが共有されているので問題なく回っているけど
新規メンバーは大体思います
「まじか…」
宗教論争
さて、そんな不幸な経験をした人は大体一回はどちらかの思想にはまります。
保守派：初めての人でも読めば分かるドキュメントちゃんと作らな！
革新派：ドキュメントなんか要らんねんコード読めや！
ドキュメントちゃんと作らな派
ドキュメントを作ると言えばウォーターフォール開発ですよ！
要件定義 → 外部設計 → 内部設計 …
というステップを踏むことによってゴールを目指す開発方式
この流派のポイントは
「各工程のエンドで完璧なドキュメントがあるから、コンテキストがゼロでもOK（※理想は）」
ということなんです
ドキュメントがあるので前工程のことを一切知らなくとも完璧にわかる（※理想は）
工程ごとにベンダースイッチすることも可能（※理想は）
メリット ：メンバースイッチコストが安い（※理想は）
デメリット：開発スピードが遅い（特にドキュメントメンテしはじめると遅い）
皆さんも経験があることでしょう「工程が進むほど工数が膨大になっていく問題」
（ソースコードにしたら数行なのにドキュメントの影響範囲が大きすぎてすごく大変という問題）
これは決して開発ベンダーが工数をぼったくっているわけではなく、仕組み上仕方がないのです。
一度作ってしまったドキュメントは一生面倒を見ていかなければならないのです。
ドキュメントが負債になっているパターンですね。
ドキュメントは「資産でもあり負債でもある」この視点は重要です。
「無いよりは有ったほうが良い」は幻想です。
使ってない土地にだって固定資産税は掛かるのです。
ドキュメントなんか要らんねん派
実際にプロダクトとして動いてるのはコード。だからコードが常に正しい。
すべてはコードを作るための付属品。プログラミングに必要なら作る。なくても作れるなら不要というスタンス。
API仕様とかコードから生成すれば良いんじゃないと考えている。
アジャイル開発はどちらかというとこちら派閥ですね。ただし
- そもそも読みやすく理解しやすいコード体系
- コードコメントとかはきちんとする
- wikiとかreadmeとかちゃんと頑張る
- あえてこの流派を選ぶチームはスキルが高い傾向がある（※高いとは言っていない）
- 別にドキュメンテーションが嫌いなわけじゃないが無駄なドキュメントは嫌い
まあDRY(Don’t Repeat Your Self)原則を忠実に実践しているとも言えます。
何回も同じこと書くのは悪、という感じです。
メリット ：開発スピードが速い
デメリット：メンバースイッチコストが高い
よくある勘違いに「アジャイル開発ってドキュメント作らなくてよいんでしょ？」というものがあります。
これは正しくもあり、間違ってもいます。
アジャイル開発においては「ソースコードも含めて全てがドキュメント」です。
そのため「ソースコードで分からない情報を補完するためのドキュメントを作る」が正しいです。
概ねHowの部分はコードに書かれているので、Whyを補完するドキュメントを作成します。
バランス
コンテキストって要はパソコンのメモリみたいなものなんです。
たくさんの前提知識をチームで共有しておけば開発スピードが上がります。
（極論、「いい感じ」の共通認識があれば「いい感じにやっといて」で「いい感じ」になります）
これはどちらか一択ではなく、無段階のスライダーをどこに設定するかというビジネス戦略です。
大切なことはシステムのビジネス特性を踏まえて検討することです。
- ビジネスのスピード感
- メンバースイッチ予測（変更というよりは追加ですかね。サービスが成功したりすると規模が大きくなります）
実際ウォーターフォールでもある程度のコンテキストを前提としています。
（例：日本語が分からない人向けに日本語の説明から入ったりはしない。知っているのは前提だから）
開発スピードを上げるためには多くのコンテキストを前提とし、その分メンバースイッチコストが上がります。
これはトレードオフであり、まさにビジネスをどう展開したいか次第です。
（上記の例だとメンバーを「日本語が読める」に限定してスイッチコストを上げていますし、
枯れている言語やフレームワークを選択することはスイッチコストを下げます）
最近の風潮で言うとビジネススピードが上がっているのでスライダーがハイコンテキストに寄りがちな傾向があります。
かと言ってサービス規模が大きくなるとJoinする人が増えるので、ドキュメントなしは辛いよね、とのせめぎあいです。
個人的には新規に何か始めるときには、ハイコンテキストから初めて徐々にドキュメントを作成するに寄せていくのが良いんじゃないかと思っています。
（大当たりすると思ってプロセスきっちり守って開発したけど鳴かず飛ばずとかあるあるなので、はじめにコストを掛けるのもある意味リスクです）
作るべきもの、作らなくてもよいもの、バランスよく選択していきたいですね。