ビープラウド社長のブログ

株式会社ビープラウドの社長が、日々の思いなどを綴っていきます。

DDD AllianceのLTで登壇しました

2017年8月30日(水)にDDD AllianceのLT(時間10分)で登壇しました。

ddd-alliance.connpass.com

以下が発表資料です。

LTのきっかけ

LTのきっかけは現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法の書評をブログで書いたことです。

shacho.beproud.jp

はてなブックマークが500を超え、そのタイミングで書籍の売上も伸びたそう(私のブログからも2日間で70冊売れました)なので、DDD Alliance運営の高崎さんからお声がかかりました。

LTの内容

「現場で役立つシステム設計の原則Night!」という全体テーマなので、オブジェクト指向に関係することで内容を検討し、UMLを中心とした図解の効果について話すことにしました*1

f:id:haru860:20170913091842j:plain

プログラマーは図解が苦手?

プログラマーはプログラムを書くのは得意ですが、図解は苦手な人が多いと感じます。

やればできるのかも知れませんが、文章で情報を表現する人がほとんどです。

テキスト以外はキーボードに打ち込むのが面倒くさいのかも知れません。

図解の効果

プロジェクト(特にシステム開発プロジェクト)における図解の代表的な効果は、以下の3つです。

  • コミュニケーションコストの削減
  • ミス発見の可能性の向上
  • 設計の向上
コミュニケーションコストの削減

1枚の図は1024の単語に値する*2という言葉にあるように、図には多くの情報を盛り込めますし、ひと目で情報の全体像を伝えることができます。

ひと目で理解できるということは、理解する側のコストを削減することであり、プロジェクト全体のコスト削減につながります。

読み手の負担が削減されることで、読み手から積極的なフィードバックが得られます。逆に負担が大きい場合は、読み手は理解することをあきらめてしまうことが多く、フィードバックも得にくくなります。

情報伝達は伝達する側が手抜きをすることで、理解する側のコストがあがります。複数人に情報を伝達する場合、その後にかかるコストは膨大になります。

文章は読み手が頭のなかで情報構造を組み立てながら内容を理解する必要があります。

図はすでに情報構造が組み立てられていますので、情報構造の組み立てをスキップすることができ、内容の理解から始めることができます。

ミス発見の可能性の向上

図は全体を俯瞰でき、視点を移動しやすいので、違和感を感じる部分に気づきやすくなります。図はプロジェクトのたたき台に最適で、プロジェクト全体の品質アップに役立つでしょう。

設計力の向上

図が複雑になりすぎているときは、設計が複雑になっているサインです。作成した図を「もっとシンプルにできないか?」という視点で見直すことで、改善点に気づくことができます。常にシンプルに図を洗練させるように心がけることで、設計力が向上します。

図解ができるようになった理由

私も最初から図解ができたわけではありません。

なぜ、できるようになったのか。

それは型を覚えたからです。

型とはUML(Unified Modeling Language:統一モデリング言語)のことです。私の経験上、システムに関係することがらの80%はUML表現できます。

どのようにマスターしたのか

私は16〜7年前から「自分の頭の中を表現するには、UMLのどのモデルを使えばよいか」と考えていました。そのように日頃の仕事で図をつくり、プロジェクトメンバーと共有し、フィードバックを得ているうちにUMLをマスターしていきました。

図解ファーストを心がける

心がけていたのは、文章に図をつけるのではなく、図に文章をつけるということです。

図のなかに文字をいれるときは、文章ではなく単語や単文で表現することで、読み手が図を直感的に理解できるようにします。

UMLはオワコン?

UMLがメディアなどに話題にのぼらないからといって、UMLが役に立たないわけではありません。オブジェクト指向はソフトウェア開発に関わらず、現実世界を捉えるのに有効な考え方です。

オブジェクト指向で捉えた世界をモデルで表現するためのツールがUMLです。オブジェクト指向が有効だとしたら、UMLも有効なはずです。

ドキュメントのメンテナンス問題

ドキュメントや図を作成すると、開発していく中で、保守されなくなるという問題があります。

そのため、ソースコードをいちばん重要なドキュメントとして扱うべきという考えがあります。

これはある面では正しいですが、これだけだと片手落ちです。

機能単位のドキュメントはソースコードで十分な場合が多く、機能単位で図をつくりすぎてしまうと、ドキュメントがメンテナンスされないという問題に陥ります。

一方、システム全体をソースコードで理解するのには時間がかかりますし、スキルにも依存します。

システム全体の理解を共有するには、図解で俯瞰したドキュメントが必要でしょう。

RUP(Rational Unified Process)に「アーキテクチャー中心」という考えがありましたが、アーキテクチャーの一貫性を保つためには、ソースコードではなく図によるドキュメントが理解共有の助けになるでしょう。

f:id:haru860:20170913085104p:plain

最後に

今回LTの機会をいただき、オブジェクト指向、UML、図解についてあらためて考えてまとめる良い機会になりました。

図を情報を表現できると、コミュニケーションコストの削減につながります。

図解により、情報共有ができるひとはプロジェクトの中で価値ある役割を果たしているといえます。

いままで、図をあまり作成してこなかったというひとは、ノートに簡単な図を書くことから始めてみてはいかがでしょうか。

図の作成は、型を覚えて場数をこなせば書くのが速くなりますし、ビジネスや開発において大きな武器になることでしょう。

*1:本来は書評をLTで話すという趣旨だったようですが、私は「書評を書いた人のLT」と認識し、書籍に関係することならフリーに話して良いと考え、このテーマになりました。他の方は書評について話していました

*2:ソフトウェア要求

ソフトウェア要求

ソフトウェア要求

より