Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

オブジェクト指向を学んで図解力、仕事力アップ

4,213 views

Published on

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

Published in: Software
  • Be the first to comment

オブジェクト指向を学んで図解力、仕事力アップ

  1. 1. オブジェクト指向を学んで 図解力、仕事力アップ 株式会社ビープラウド 佐藤治夫 2017/8/30 @DDD Alliance 様
  2. 2. 自己紹介 •名前 佐藤治夫(Sato Haruo) •株式会社ビープラウド代表取締役社長 •Twitter http://twitter.com/haru860 •connpass企画・開発・運営 •IT系勉強会 BPStudy 主催
  3. 3. 書評を書かせて頂きました ・はてなブックマーク:547(8/29現在) ・kindle本49冊、紙本21冊売れました https://goo.gl/toL35B
  4. 4. オブジェクト指向を学ぶと 図解力がアップ! →仕事力がアップ!
  5. 5. オブジェクト指向+UMLを学び始める 新卒の研修(C言語):1997年 「なぜ、こんなにプログラムが分かりづらく、面倒くさいんだ」→自分は向いてないかも。。 ↓ 書籍(「最新オブジェクト指向技術応用実践」)でオブジェクト指向を知る:1998年 人に理解しやすく、開発生産性が高いなどメリットがさまざまにあるらしい ↓ Javaを学び始める ↓ UMLを学び始める ↓ 実践でどうしてもやりたくて転職(2000年) ↓ 実務でJava、UMLを使い始める(2001年)
  6. 6. オブジェクト指向+UMLを実践で継続 システム関連のドキュメント(仕様、設計)を作成するときは、必ずUMLを使うようにした ↓ レベル1(2001年〜2002年):自分でやってみる 最初は、なかなかシンプルなモデルができない=力不足 ↓ きれいなモデルにまとまった時は、頭が整理できている ↓ 繰り返すうちに、モデルの質が向上し、スピードアップ ↓ レベル2(2003年〜2004年):チーム内 プロジェクトや案件の初期で、たたき台としてUMLを作成して議論や認識合わせのたたき台に ↓ レベル3(2005年〜現在):社外 社外の提案資料にも、UMLを活用した図を積極的に活用
  7. 7. 社外の提案資料にも、UMLを活用した図を積極的に活用 レベル3(2005年〜現在) 社外の提案資料にも、UMLを活用した図を積極的に活用 ↓ 10社のコンペで当選(2011年) 「名だたる一流企業がいる中から、御社を選びました」 「最初に話した時に、本質をついていると思った」 → オブジェクト指向で抽象化を学んでいた成果 「提案資料も圧倒的な品質で、役員全会一致で決まりました」 提案書の一部
  8. 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. 9. 私のUMLの使い方
  10. 10. ヒアリング+見積もり(ロバストネス図) ■ポイント ・ユースケース図は使わない ・Controlオブジェクトは図が複雑になるので、 バッチ処理以外は使わない ・見積もりの段階で基本設計まである程度進める ↓ その後、画面・処理の一覧表を作成し、見積もる ■考慮点 ・画面数 ・画面以外の処理(バッチ処理など)の数: ・処理の複雑さ 所要時間目安:1〜3時間(システム規模により )→ クラス図、シーケンス図で詳細化
  11. 11. 会員の状態管理(ステートマシン図) ■ポイント ・ステートマシン図は、お金が関係するシステムの場合に特に有効 ・フラグの組み合わせで判断するシステムにも有効 所要時間目安:30分
  12. 12. 業務フロー・システム間連携(アクティビティ図 or シーケンス図) 所要時間目安:30分〜1H
  13. 13. サーバー、ミドルウェアの検討(配置図) 所要時間目安:30分 ■ポイント ・クライアント(スマホ、PCなど)も想定する ・チームミーティングで画面に映しながら作ると楽 ・AWS、GCPなどのサービスを使う場合に特に有効 (さまざまなサービスを活用するため)
  14. 14. オブジェクト指向・UMLを使うメリット
  15. 15. メリット① オブジェクト指向を学ぶと、ものごとの本質を捉え、カタチにできる オブジェクト指向 で捉える 現実の事象 目に見えるカタチにする 抽象化 (シンプルな本質) 具象的なもの(複雑) オブジェクト指向 =現実世界を認知し、抽象的に表現する手法
  16. 16. オブジェクト指向だとなぜシンプルに認知できるのか ・カプセル化(データ、ルールの隠蔽) ・抽象化(スーパークラス) ↓ 俯瞰した視点を得ることができる
  17. 17. メリット② UMLを使うと、スピーディーに図を作成することができる 我流の図解法 ・表記法まで考える必要がある (四角なのか、丸なのかなど) ・ツールも、パワポ、キーノート UMLの場合 ・アイコン、表記法が揃っている ・頭の良い人たち(スリーアミーゴ)が 考えたシンプルな記法が使える ・UMLをサポートしているツール(astah*など) でサクサクモデルを作成できる
  18. 18. メリット③ プロジェクトの安定化、スピードアップ効果 ・文章よりもすぐに理解することができる → イメージの共有 ・認識のずれという「リスク」の回避 ・全体が見えることの安心感 「見えない」不安からの解放 →プロジェクトの活力 ↓ プロジェクトの 安定化、スピードアップ効果 現実の事象 「1枚の絵は1024の単語に値する」
  19. 19. UMLを使う注意点その1 全てのことを、UMLで表現できるわけではない 現実の事象 UML 他の図法自分が認知したことは図で どのように表現できるか? 考える順番 ①UMLで表現できないか? ※システムが関係する場合、 ほとんどの場合、UMLが使える ②UMLで表現できない場合、 どの図法が良いか?
  20. 20. UML以外でよく使う図(ピラミッド) 顧客・ユーザーのレイヤーを表す場合など
  21. 21. UML以外でよく使う図(四象限) 2軸で分類 以下の場合、社会のニーズと自社のニーズで分類 戦略の提示 使い方その① 使い方その②
  22. 22. UML以外でよく使う図(因果関係ループ)
  23. 23. UML以外でよく使う図(ピクト図) ビジネスモデルを表現 http://www.dhbr.net/articles/-/2438?page=3 より
  24. 24. UML以外でよく使う図(匠Method) 現在(AsiS)と実現したい未来(ToBe)を描く 現在(AsiS) 実現したい未来(ToBe)
  25. 25. ロバストネス図 ※ 変換コストを考えると、社内はなるべくUMLで済ませたい より直感的に理解できるように変換 ・アクターの表記 ・バウンダリー ・データ、エンティティ UMLを使う注意点その2 TPOに合わせて、表記を変換する
  26. 26. UMLを使う注意点その3 全てをドキュメント化しようとするとドキュメント過多になり、保守コストがあがる ※あとで質問があり、このスライドを追加しました 。 ・基本設計、アーキテクチャーとなる箇所はドキュメント化 → 全体のイメージをチームで共有する ・各機能→ソースコードがドキュメントがベスト ・開発の経験が少ない、またはチームに入って日が浅いメンバー 機能単位でもクラス図やシーケンス図などをつくると、理解が整理できて良い つくった図は、基本使い捨て。保守の対象からは外す
  27. 27. 図が有効な領域 機能 機能 機能 機能 基本設計 (アーキテクチャー) 要求 要件定義 ←図、特にUMLが最も有効な領域 ←図、UMLが有効な領域 (文章も重要:曖昧さの排除) ←ソースコード読めの領域
  28. 28. オブジェクト指向を学ぶと、図解力がアップ! その結果、仕事力がアップ! メリット③ プロジェクトの 安定化、スピードアップ効果現実の事象 抽象化(シンプルな本質)具象的なもの(複雑) メリット① オブジェクト指向で、ものごとの本質を捉え、カタチにできる メリット② UMLを使うと、スピーディー に図を作成することができる
  29. 29. 頭の中を、図にする習慣からはじめましょう ステップ1:自分が認知したこと、表現したいことは、図でどのように表現できるか?と考える ①UMLで表現できないか? ※システムが関係する場合、ほとんどの場合、UMLが使える → オブジェクト指向で考える ②UMLで表現できない場合、どの図法が良いか? ステップ2:実際に書いてみる ツールを使っても良いし、ノートやホワイトボードに書いても良い
  30. 30. ご静聴ありがとうございました!

×