2017年8月30日に開催されたDDDAlliance( https://ddd-alliance.connpass.com/event/64219/ ) のLTの資料です。

1. オブジェクト指向を学んで
図解力、仕事力アップ
株式会社ビープラウド
佐藤治夫
2017/8/30
@DDD Alliance 様

2. 自己紹介
•名前 佐藤治夫（Sato Haruo）
•株式会社ビープラウド代表取締役社長
•Twitter http://twitter.com/haru860
•connpass企画・開発・運営
•IT系勉強会 BPStudy 主催

3. 書評を書かせて頂きました
・はてなブックマーク：547（8/29現在)
・kindle本49冊、紙本21冊売れました
https://goo.gl/toL35B

4. オブジェクト指向を学ぶと
図解力がアップ！
→仕事力がアップ！

5. オブジェクト指向+UMLを学び始める
新卒の研修（C言語）：1997年
「なぜ、こんなにプログラムが分かりづらく、面倒くさいんだ」→自分は向いてないかも。。
↓
書籍（「最新オブジェクト指向技術応用実践」）でオブジェクト指向を知る：1998年
人に理解しやすく、開発生産性が高いなどメリットがさまざまにあるらしい
↓
Javaを学び始める
↓
UMLを学び始める
↓
実践でどうしてもやりたくて転職（2000年）
↓
実務でJava、UMLを使い始める（2001年）

6. オブジェクト指向+UMLを実践で継続
システム関連のドキュメント（仕様、設計）を作成するときは、必ずUMLを使うようにした
↓
レベル１（2001年〜2002年）：自分でやってみる
最初は、なかなかシンプルなモデルができない＝力不足
↓
きれいなモデルにまとまった時は、頭が整理できている
↓
繰り返すうちに、モデルの質が向上し、スピードアップ
↓
レベル２（2003年〜2004年）：チーム内
プロジェクトや案件の初期で、たたき台としてUMLを作成して議論や認識合わせのたたき台に
↓
レベル３（2005年〜現在）：社外
社外の提案資料にも、UMLを活用した図を積極的に活用

7. 社外の提案資料にも、UMLを活用した図を積極的に活用
レベル３（2005年〜現在）
社外の提案資料にも、UMLを活用した図を積極的に活用
↓
10社のコンペで当選（2011年）
「名だたる一流企業がいる中から、御社を選びました」
「最初に話した時に、本質をついていると思った」
→ オブジェクト指向で抽象化を学んでいた成果
「提案資料も圧倒的な品質で、役員全会一致で決まりました」
提案書の一部

8. 余談：MDAも取り組みました
UML2.0→ソースコードの自動生成に対応
↓
MDA
UMLでモデリング
→ソースコードも自動生成（＋差分プログラミング
）
↓
劇的な生産性と品質の向上
Codezineで記事も書きました（2005年）
①AndroMDAでMDAの世界を体験する（コード生成編）
〜AndroMDAでStruts、Spring、Hibernateの
ソースを自動生成する
http://codezine.jp/article/detail/132
②AndroMDAでMDAの世界を体験する（コード分析編）
〜AndroMDAで自動生成された
Struts、Spring、Hibernateのコードを読み解く
http://codezine.jp/article/detail/133
今は、匠Methodに取り組んでいる
→人が想像したものを、いかに現実・カタチにするか

9. 私のUMLの使い方

10. ヒアリング＋見積もり（ロバストネス図）
■ポイント
・ユースケース図は使わない
・Controlオブジェクトは図が複雑になるので、
バッチ処理以外は使わない
・見積もりの段階で基本設計まである程度進める
↓
その後、画面・処理の一覧表を作成し、見積もる
■考慮点
・画面数
・画面以外の処理（バッチ処理など）の数：
・処理の複雑さ
所要時間目安：１〜３時間（システム規模により
）→ クラス図、シーケンス図で詳細化

11. 会員の状態管理（ステートマシン図）
■ポイント
・ステートマシン図は、お金が関係するシステムの場合に特に有効
・フラグの組み合わせで判断するシステムにも有効
所要時間目安：30分

12. 業務フロー・システム間連携（アクティビティ図 or シーケンス図）
所要時間目安：30分〜1H

13. サーバー、ミドルウェアの検討（配置図）
所要時間目安：30分
■ポイント
・クライアント（スマホ、PCなど）も想定する
・チームミーティングで画面に映しながら作ると楽
・AWS、GCPなどのサービスを使う場合に特に有効
（さまざまなサービスを活用するため）

14. オブジェクト指向・UMLを使うメリット

15. メリット①
オブジェクト指向を学ぶと、ものごとの本質を捉え、カタチにできる
オブジェクト指向
で捉える
現実の事象
目に見えるカタチにする
抽象化
（シンプルな本質）
具象的なもの（複雑）
オブジェクト指向
=現実世界を認知し、抽象的に表現する手法

16. オブジェクト指向だとなぜシンプルに認知できるのか
・カプセル化（データ、ルールの隠蔽）
・抽象化（スーパークラス）
↓
俯瞰した視点を得ることができる

17. メリット②
UMLを使うと、スピーディーに図を作成することができる
我流の図解法
・表記法まで考える必要がある
（四角なのか、丸なのかなど）
・ツールも、パワポ、キーノート
UMLの場合
・アイコン、表記法が揃っている
・頭の良い人たち（スリーアミーゴ）が
考えたシンプルな記法が使える
・UMLをサポートしているツール(astah*など)
でサクサクモデルを作成できる

18. メリット③
プロジェクトの安定化、スピードアップ効果
・文章よりもすぐに理解することができる
→ イメージの共有
・認識のずれという「リスク」の回避
・全体が見えることの安心感
「見えない」不安からの解放
→プロジェクトの活力
↓
プロジェクトの
安定化、スピードアップ効果
現実の事象
「１枚の絵は1024の単語に値する」

19. UMLを使う注意点その１ 全てのことを、UMLで表現できるわけではない
現実の事象
UML
他の図法自分が認知したことは図で
どのように表現できるか？
考える順番
①UMLで表現できないか？
※システムが関係する場合、
ほとんどの場合、UMLが使える
②UMLで表現できない場合、
どの図法が良いか？

20. UML以外でよく使う図（ピラミッド）
顧客・ユーザーのレイヤーを表す場合など

21. UML以外でよく使う図（四象限）
２軸で分類
以下の場合、社会のニーズと自社のニーズで分類
戦略の提示
使い方その① 使い方その②

22. UML以外でよく使う図（因果関係ループ）

23. UML以外でよく使う図（ピクト図）
ビジネスモデルを表現
http://www.dhbr.net/articles/-/2438?page=3 より

24. UML以外でよく使う図（匠Method）
現在（AsiS）と実現したい未来（ToBe）を描く
現在（AsiS） 実現したい未来（ToBe）

25. ロバストネス図
※ 変換コストを考えると、社内はなるべくUMLで済ませたい
より直感的に理解できるように変換
・アクターの表記
・バウンダリー
・データ、エンティティ
UMLを使う注意点その２ TPOに合わせて、表記を変換する

26. UMLを使う注意点その3
全てをドキュメント化しようとするとドキュメント過多になり、保守コストがあがる
※あとで質問があり、このスライドを追加しました
。
・基本設計、アーキテクチャーとなる箇所はドキュメント化
→ 全体のイメージをチームで共有する
・各機能→ソースコードがドキュメントがベスト
・開発の経験が少ない、またはチームに入って日が浅いメンバー
機能単位でもクラス図やシーケンス図などをつくると、理解が整理できて良い
つくった図は、基本使い捨て。保守の対象からは外す

27. 図が有効な領域
機能 機能 機能 機能
基本設計
（アーキテクチャー）
要求
要件定義
←図、特にUMLが最も有効な領域
←図、UMLが有効な領域
（文章も重要：曖昧さの排除）
←ソースコード読めの領域

28. オブジェクト指向を学ぶと、図解力がアップ！
その結果、仕事力がアップ！
メリット③
プロジェクトの
安定化、スピードアップ効果現実の事象
抽象化（シンプルな本質）具象的なもの（複雑）
メリット①
オブジェクト指向で、ものごとの本質を捉え、カタチにできる
メリット②
UMLを使うと、スピーディー
に図を作成することができる

29. 頭の中を、図にする習慣からはじめましょう
ステップ１：自分が認知したこと、表現したいことは、図でどのように表現できるか？と考える
①UMLで表現できないか？
※システムが関係する場合、ほとんどの場合、UMLが使える
→ オブジェクト指向で考える
②UMLで表現できない場合、どの図法が良いか？
ステップ２：実際に書いてみる
ツールを使っても良いし、ノートやホワイトボードに書いても良い

30. ご静聴ありがとうございました！