毎日が越境だ！

毎日が越境だ！

1. 1. 毎日が越境だ！ エンジニアの学習と成長 有限会社システム設計 代表 ギルドワークス株式会社 取締役 増田 亨 DevLOVE201 越境ジャーニー
2. 2. エンジニアの学習と成長 ３つの越境マインド ９つの越境スキル
3. 3. エンジニアの学習と成長 3 Special thanks to 慶應義塾大学 湘南藤沢キャンパス 井庭研究室 http://learningpatterns.sfc.keio.ac.jp/index.html
4. 4. ソフトウェア開発の技術者として 仕事としてのソフトウェア開発 開発の中心はプログラミング プログラミングの腕をあげたい そのために分析・設計スキルを磨く
5. 5. 分析設計のスキル：私のアプローチ • Modularity モジュール性 – 高凝集 疎結合 • 「型」によるモジュール化 – データとロジックのカプセル化 – 小さなインタフェース、少ないインタフェース • ドメイン固有の「型」の発見と実装 – 金額型、数量型、日付型、… – 顧客区分、商品区分、在庫区分、… • ドメインロジック（ビジネスルール）の発見と整理の技法
6. 6. モジュール性の探求＝分析設計スキル 第３章 モジュール性 第５章 オブジェクト技術への道 第10章 しなやかな設計 第14章 モデルの整合性 第15章 蒸留 第12章 大きなリファクタリング 第15章 部品から全体へ 第３章 業務ロジックの整理 第４章 ドメインモデル 第８章 アプリケーション間の連携 6
7. 7. 私の越境：学習と成長の軌跡 – 原価計算シミュレータ（表計算ソフトのマクロ、製造業の管理部門） – グループウェア(自社プロダクト,Unix, C） – データベース中心の世界へ (Oracle, SQL, DOA) – インターネットバブル (Java as better C) – eコマース専業のソフトウエアハウスの雇われ社長 • 大炎上プロジェクトの火消し役 – 人に「善い設計」を伝えることの難しさ – リファクタリング、ドメイン駆動設計との出会い • 善い設計の模索 – 人材領域 （求人、転職、人材紹介などで、２０くらいの似て非なるサービス） – ISPサービス （レガシーとの戦い） – 成功したスタートアップ （大きな泥団子との戦い） – 30年物の販売管理システム再構築（歴史ある中堅商社の情シスとの遭遇） • 現在進行形 – 善い設計の探求、そのための分析スキル、そのための業務知識 – 善い設計の考え方・やり方の言語化と普及活動
8. 8. ３つの越境マインド 8
9. 9. 毎日の小さな変化への「気づき」 ビジョンという「思い」 自分の道
10. 10. 毎日の小さな変化への気づき ３年前の自分 ３年後の自分 ３カ月前の自分 ３か月後の自分 三日前の自分 三日後の自分
11. 11. 毎日の小さな変化への気づき 自分の変化への気づき まわりの変化への気づき 世の中の変化への気づき
12. 12. 昨日と同じ、明日も同じ 昨日と変わった、明日はもっと変わる • 経験値がワンポイントあがった • 安定性が増した • 方向が明確になった • 逆境への耐久力が増した • 思考停止の病が悪化した • 自分への嘘が増えた • 衰えた
13. 13. ビジョンという「思い」 思い描く自由 思い描く楽しさ 「思い」が生み出すパワー
14. 14. 自分の道
15. 15. 自分の道 自分の思いを大切に
16. 16. 自分の道 自分の思いを大切に 道はひとつではないかもしれないが
17. 17. 自分の道 自分の思いを大切に 自分で扉を開けながら 道はひとつではないかもしれないが
18. 18. 自分の道 自分の思いを大切に 自分で扉を開けながら 道はひとつではないかもしれないが 自分らしく成長を続ける
19. 19. 自分の道 自分の思いを大切に 自分で扉を開けながら 道はひとつではないかもしれないが 自分らしく成長を続ける 自分らしさが集まって より大きな成長を生み出す
20. 20. ３つの越境マインド 毎日の小さな変化への気づき ビジョンという思い 自分の道
21. 21. ９つの越境スキル 21
22. 22. ９つの越境スキル 22 「古い設計スタイル」の呪縛を解く４つの合言葉 「だいたい知っている／いちおうできる」の壁を乗り越える ５つの学習パターン
23. 23. 古い設計スタイルの呪縛を解く ４つの合言葉 23
24. 24. インクリメンタルな設計 ビジネスルール 型によるモジュール化 ソースコード as ドキュメント
25. 25. インクリメンタルな設計 25
26. 26. インクリメンタルな設計 • アップフロントの設計よりも、インクリメンタルな設計を – 最初から良い設計は見つからない – 「これで完成」という設計はない • ざくっと設計してみる – 書いてみてフィードバック – 動かしてみてフィードバック – 改善ネタが見つかったら実験してみる • 繰り返す – 毎日が設計 自分がアップフロントの設計にとらわれていることを自覚する
27. 27. ビジネスルール 27
28. 28. ビジネスルール • 業務アプリケーションの複雑さの根源 • 事業の運営が複雑なことの反映 • システムの構成要素として、ビジネスルールを独 立させると、新たなシステム開発の道筋が見え てくる – ビジネスルールのモジュール – ビジネスルールの分析・設計・実装の活動 – ビジネスルールのスコープ／品質／進捗の管理
29. 29. ビジネスルール 従来の設計スタイル • 入出力中心の設計 – 画面定義 – データベース設計 – 機能設計＝入出力処理 • ビジネスルール記述の重複 – 入出設計と機能設計の中に埋 め込む – 重複記述 • 暗黙知 – if code == 13 then flag = 1 これからの設計スタイル • ビジネスルールに焦点 – ビジネスルールの発見と整理 – 入出力設計／機能設計から独 立させる • 記述の一元化 – ビジネスルールを表現する データとロジックをカプセル化 – モジュールとして独立させる • コードで表現 – if メーカー直送 then 送料請求 29
30. 30. ３層アーキテクチャ 30 プレゼンテーション層 データソース層 アプリケーション層 30 入出力処理 画面入出力 Web API データベース入出力 メッセージ送信 入出力設計＋機能設計 ビジネスルールが 入出力処理の手続きに 暗黙的に埋め込まれる
31. 31. ３層＋ドメインモデル 31 プレゼンテーション層 データソース層 アプリケーション層 31 入出力処理 ビジネスルール実行 ビジネスアクション指示 画面入出力 Web API データベース入出力 メッセージ送信 入出力設計＋機能設計 ビジネスルール 計算ロジック 判定ロジック ビジネスルールの分析設計 金額、数量、期日、場所、… 金額範囲、数量範囲、期間、… 顧客区分、商品区分、… 配送区分、地域区分、請求区分、… ビジネスルールの記述を 独立したモジュールに 分離する
32. 32. 型によるモジュール化 32
33. 33. モジュール性の向上 従来の設計スタイル • 分解のしやすさ • 機能単位のモジュール化 • データの正規化/一元化 • 概念と実装の分離 • 「既存」を変更しない 増築/外付けでがんばる くさいものにふたをする これからの設計スタイル • 組み立てやすさ • データとロジックのカプセル化 • ロジックの正規化／一元化 • 概念と実装の連続性 • 変更（組み立て直し）を続ける 変更の影響の局所化 日常的に変更する 33
34. 34. モジュール性の向上＝分析設計スキル 第３章 モジュール性 第５章 オブジェクト技術への道 第10章 しなやかな設計 第14章 モデルの整合性 第15章 蒸留 第12章 大きなリファクタリング 第15章 部品から全体へ 第３章 業務ロジックの整理 第４章 ドメインモデル 第８章 アプリケーション間の連携 34
35. 35. 独自のデータ型の設計者になる ©有限会社システム設計 35 数値 日付 判定結果 コレクション 汎用の型 int long BigDecimal LocalDate boolean 配列 List<T> Map<K,V> アプリケーション 固有の型を用意 して記述する 金額 数量 単価 年齢 日数 ポイント 期限 予定日 誕生日 確定日 顧客種別 割引可否 送料区分 年齢区分 価格表 カタログ 在庫表 履歴 スケジュール 売買契約
36. 36. ビジネスルールを記述する型の設計 • 計算ルールを記述するための型 – 値オブジェクト：金額型、数量型、日付型、… • 計算の元データと計算結果を表現する型 • 内部に計算ロジックを持つ • 判定ルールを記述するための型 – 区分オブジェクト • 分岐条件(input)としての区分 – 顧客区分、商品区分、地域区分、… • 判定結果(output)としての区分 – 出荷可否、配送方法、料金区分、… ©有限会社 システム設計 36 本日の演習の中心テーマ ・イベントの区分 ・状態の区分
37. 37. ３層＋ドメインモデル 37 プレゼンテーション層 データソース層 アプリケーション層 37 入出力処理 ビジネスルール実行 ビジネスアクション指示 画面入出力 Web API データベース入出力 メッセージ送信 入出力設計＋機能設計 ビジネスルール 計算ロジック 判定ロジック ビジネスルールの分析設計 金額、数量、期日、場所、… 金額範囲、数量範囲、期間、… 顧客区分、商品区分、… 配送区分、地域区分、請求区分、… ビジネスルールの記述を 独立したモジュールに 分離する
38. 38. 型によるモジュール化 • 汎用のデータ型だけで記述するスタイル – データクラス（データ構造体） – 機能クラス（トランザクションスクリプト）：処理単位にモジュール化 – ビジネスルールの暗黙的な記述 – ビジネスルールの記述の重複 • 固有の型を設計して記述するスタイル – ビジネスルールの結果（目的）を「型」で明示 • 計算結果 • 判定結果 – ビジネスルールで扱う値と計算ロジックを「型」で明示 • 金額型、数量型、日付型、… – データとロジックを「型」（クラス）という単位にモジュール化する – ひとつのビジネスルールの記述を特定の型に一元化できる ©有限会社 システム設計 38
39. 39. ソースコード as ドキュメント 39
40. 40. エンジニアのアウトプット ソースコード 説明資料 図表 方眼紙 ブログ tweet
41. 41. ソースコード as ドキュメント • クラス名、メソッド名、パッケージ名という説明 • 式の型、メソッドの型、引数の型という説明 • アノテーションという説明 • 図や一覧がほしかったら自動生成する ソースコードをドキュメントとして活用する工夫を積み重ねる
42. 42. 古い設計スタイルの呪縛を解く ４つの合言葉 インクリメンタルな設計 ビジネスルール 型によるモジュール化 ソースコード as ドキュメント
43. 43. 「だいたい知っている」 「いちおうできる」 この壁を乗り越える ５つの学習パターン 43
44. 44. 量が質を生む 広げながら掘り下げる 鳥の眼、虫の眼 隠れた関係性から学ぶ 三日坊主を繰り返す
45. 45. 量が質を生む Quality from Quantity 大量の情報を凝縮すると、理解や思考の飛躍が起きる。 読書量 積読量 パケット量 コミット量 リファクタリング量 失敗量 … 壁を超えるために大量の情報を体にインプットする
46. 46. 広げながら掘り下げる Triangle Scaling 多くに目を向け、ひとつを極める。 これがすべての基本である。 深堀のために、多くに目を向けてみる 多くに目を向けるために、深堀をしてみる 堀が浅いと視野が狭くなる 視野が狭いが堀が浅くなる
47. 47. 鳥の眼、虫の眼 A Bird's- & Bug's-Eye View 俯瞰して全体を見ることと、詳細に部分を見ること。 この二つの視点を行き来する。 全体と部分は同時には見れない だったら行ったり来たりすればよい 俯瞰と詳細の行ったり来たりを習慣にする そうすると、 俯瞰から詳細が見え 詳細から俯瞰が見える ようになる
48. 48. 隠れた関係性から学ぶ Hidden Connections 意外なつながりこそ面白い！ 見えていなかった関係性に気づくとき それが、ブレークスルーの瞬間 そのために 量で質を生み 広げながら掘り下げ 鳥の眼、虫の眼を行き来する
49. 49. 三日坊主を繰り返す 三日坊主でよい 飽きたら、別のことをやる 続かないことを卑下することはない みんなできていない 思いついたらいつでも再開すればよい それでまた三日坊主でよい 三日坊主を繰り返せば、量を生み出せる ある時、量が質になり、隠れた関係性が見える 継続は難しい ブレークスルー
50. 50. 壁を超える５つの学習パターン 量は質を生む 広げながら掘り下げる 鳥の眼、虫の眼 隠れた関係性から学ぶ 三日坊主を繰り返す
51. 51. エンジニアの学習と成長 51 Special thanks to 慶應義塾大学 湘南藤沢キャンパス 井庭研究室 http://learningpatterns.sfc.keio.ac.jp/index.html