部族記憶を最小限にすると良さそうな話

オブジェクト指向カンファレンス2020で面白い発表があったので、自分なりにまとめなおしてみました。

基本的にはどうモデリング、ドキュメントを残すのが良いのか？という話です。前提として、gitやGitHubなどの当たり前のモノは知って使いこなしているものとします。

情報をどう過不足なく伝えるか？というラインを探る話だと解釈しています。

アジャイル時代のモデリング

モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングの手法を提案します。
アジャイル開発では、動くコード（そして自動化テスト）が重要な成果物として扱われます。では、設計はどこに行ったのでしょう？モデリングはもういらない？UMLは死んだ？ぼくはそう思いません。

"The code is the truth, but it is not the whole truth." -- Grady Booch

このセッションでは、アジャイル時代に相応しいモデリングの役割について探ってみたいと思います。合わせて、海外で話題の軽量モデリング手法、 C4 Model の概要もお話します。

一番コアとして明確化し残すべき資料

セッションでは、資料のうち、keeps （資料として残すべきモノ）と temps（その場で作成し、その場で消えていくべきモノ）という二種類の分け方を提示していました。

keeps では、アーキテクチャ構造、ドメイン知識（ユビキタス言語）と、ここからが重要なのですが、キーとなるユースケースの三種類が提示されていました。

この残すべき資料（keeps）の目的は、後々を考えてのものです。

・ チームに新しく入った人が、どれだけオンボーディングしやすいか？（チームや開発に慣れられるのか？）
・ 後々、新しいユースケースを考える時の手本

などの用途が考えられます。

プロジェクトの詳細を知らない立場で考えたとき、最初に欲しいものは、全体像であるアーキテクチャと、用語集と、システムの end to end で考えられるキーユースケースであるはずです。

逆にいうと、最初にそれ以上の情報があっても混乱するだけです。あとの情報は、キーユースケースを元に、ソースコードを追いかけていくなりすれば大丈夫なはずですし、そこで分からないことがあれば聞くというスタンスでいいと思います。

揮発性の情報をどう取り扱うべきなのか？

セッションでは temps （揮発的な情報）として、キー以外のユースケースが挙げらていました。

そもそも、キーユースケースがはっきりしていれば、差分情報として、リポジトリにあるソースコードや、そこから生成されるドキュメント（JavaDocとかJSDocとか、JSON Schema とか）を付け加えれば、他のユースケースもそんなに苦労なく復元できるはずです。

そうじゃないなら、設計に統一性が無いということであり、それはおそらく設計の失敗か、アーキテクチャのドキュメンテーションに失敗しているか、キーユースケースが足りてなかったということでしょう。

もちろん、現実にはソースコードの仕組みに統一性の無い、キメラのようなシステムもあるでしょう。そういったシステムでは、キメラ要素を理解するための追加情報はあるべきです（それはおそらくキーユースケースに追加すべき項目のはずです。

keeps以外で残しておくべき情報

ソースコードに記述するのが難しい、意思決定理由、つまり Why と Why Not は何かしらドキュメントあるいはコメントに残しておくべきです。単なるソースコードでは、Why / Why Not はとても表現しづらい情報であり、リポジトリの中から簡単に揮発します。

モデリング方法はUMLでいいのか？

UMLってある意味万能を目指していて、過剰な表現であるとは言えます。そこでセッションで提示されていたのは、C4というモデリング手法(というか案）です。

C4では、Context / Container / Component / Code という4つの階層でモデリングするという案らしいです。現代ではコンテナを使うのも当たり前ですし、コンテナの中に各種コンポーネントがあって、コンポーネントはさらにコードで構成されてるということでしょう。コンテキストは、結局ユースケースがどう成り立っているか、前提となる文脈を図に示したものです。（という理解）

なんとなくセッションを聞いたり、雑にぐぐったりしてる感じだと、「これ」と決まったものではなくて、こういうふうにすれば簡単にモデリングできるかも？という案のように思えます。

実際、あまりがっつりクラス図だのエンティティだのをモデリングする必然性はあまりなくて、キーユースケースを、誤解なく伝えられる最小限の図を記述できればいいはずです。

今の時代、UMLが考案された頃よりはよほど表現能力も多彩です。

式年遷宮と部族知識

セッションでは式年遷宮（一定期間でシステムを作り直す）の有効性について触れていたのですが、ちょっとおもしろいのは、式年遷宮は部族知識の継承（逆にいうと、いらない知識をふるい落とす）であるという表現でした。

結局、どういうプロジェクトも時間が経つと情報が過剰になるので、いらないものは壊して、記憶からも消してしまえばいいのです。

まとめ

部族（チーム）に簡単にオンボーディング（参加）するためには、部族の知識（アーキテクチャ解説とドメイン知識・ユビキタス言語の説明）をした上で、キーユースケースを示すことで「実際に部族の生き方を体験してみるといいよ」という流れが最適なのではないか？という話でした。

#ooc_2020 #ooc_a
さっきのセッション

「部族（チーム）に来た新入りよ！まずは我らの生き方（アーキテクチャと言葉）を説明しよう。そのあと実際に日々の生き方（ユースケース）についてお前の体にたたき込んでやろう」

みたいな感じやね

— えるぴぴ (@erukiti) February 16, 2020

情報が過剰だと、混乱しかないんですよね。でも、情報が足りなくても困る。そこでいい塩梅として、キーユースケースという絞り込みをする、というのはとてもいいアイデアだなと思いました。

C4も含めて、キーユースケースを記述するというのを、チャレンジしてみたいところです。