論理設計_.pdf

Transcript

1. INTRODUCTION TO Logical Design Quoise 1
2. VimかEmacsかでいうと 断然VSCODE派 2
3. 皆さん初孫を見守るような目で講義を 受けてください 3
4. 今回の目標 開発合宿や業務で ちょっと DB設計に首を突っ込めるようになる 4
5. アジェンダ ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ 最後に 5
6. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ 最後に 6
7. そもそも データベースって何だろう？ 7
8. 紙の全盛期 登録よろしく！ 8
9. こいつが登場 9
10. 人、紙、コンピュータ 登録よろしく！ 10
11. データをもっと楽に扱いたい 11
12. 人はもっと便利に生きたい 12
13. データベースの登場 登録よろしく！ 13
14. かくしてデータベースは 我々の生活に欠かせないものと なりました 14
15. でもなぜデータベース？ 15
17. こいつらにもデータの 書き込み、読み取りはできます 17
19. アカウント登録、、、ログイン、、、 購入履歴、、、商品購入、 レコメンド、、、退会、、、 19
20. 4079万ユーザー 20
21. このユーザー数、、、 変なことするやつはいっぱいいて 予期していない値が入ってくるかもしれない 21
22. そしてエンジニアはしんじゃいます 22
23. データをいつでも便利に 蓄積する 利用する 検索する 整合性のある仕組みを提供する 23
24. これが私たちがデータベースに データを蓄積する理由です 24
25. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ 最後に 25
26. DBMSの種類と紹介するDBMS RDB OODB XMLDB KVS 26
27. RDBとは？ Relational DataBase 関係（リレーショナル）データベース 27
28. “リレーショナル”データベース？ 28
29. “リレーション”とはテーブル同士の関係 を設定し、関連付けるもの 29
30. テーブル？ 30
31. エクセルでもあの格子状のマス目に 値が入ったものをテーブルと呼びます 。。。よね？ 31
32. 表計算のテーブルの例 項目１ 項目２ 項目３ 項目４ 1 カントー 1 ヒトカゲ Charmander 3 関東 #001 キモリ Treecko 2 ジョウト #004 キティちゃん 1 カントー #016 ポッポ Pidgey 32
33. しかしこの表はRDBMSにおいては テーブルと呼べません 33
34. 先ほどの整合性のある仕組み という言葉を思い出してください 34
35. 整合性： 矛盾がなく一貫性のあること 35
36. 表計算のテーブル 項目１ 項目２ 項目３ 項目４ 1 カントー 1 ヒトカゲ Charmander 3 関東 #001 キモリ Treecko 2 ジョウト #004 キティちゃん 1 カントー #016 ポッポ Pidgey 整合性がない形に見えませんか？ 36
37. RDBMSのテーブル 図鑑No 名前 英語名 #004 ヒトカゲ Charmander #252 キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey 整合性が取れてるように見えませんか？ 37
38. 偉い人の話 テーブル名は全て 複数形 または 複数名詞で書ける Joe Celko 38
39. 要すると同じ属性を持ったもの集合とい う考えが重要だということです 39
40. 最初のは属性もバラバラで〇〇テーブル と特定し辛い 項目１ 項目２ 項目３ 項目４ 1 カントー 1 ヒトカゲ Charmander 3 関東 #001 キモリ Treecko 2 ジョウト #004 キティちゃん 1 カントー #016 ポッポ Pidgey 40
41. サンリオとかポケモンとかいろんなもの が同棲しちゃってます 41
42. でも次のはポケモンテーブルと命名 できる 図鑑No 名前 英語名 #004 ヒトカゲ Charmander #252 キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey 42
43. RDBMSのテーブルとは ただの二次元表ではありません 43
44. そのRDBMSのテーブルの構成って どうなってるんでしょう？ 44
45. 図鑑No 名前 英語名 #004 ヒトカゲ Charmander #252 キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey テーブルの構成 カラム(列) フィールド レコード (行) 45
46. テーブルのデータを使用したい時 どのデータを使用するか明確に 分からないと困りますよね？ 46
47. 図鑑No 名前 英語名 #004 ヒトカゲ Charmander #252 キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey どれ探せばいいんだ よ！ 47
48. そこでデータベースには キーという仕組みがあります 48
49. キーについて データベースのキーとは あるレコードを特定する為の 列の組み合わせ(単一の場合もあり)です 49
50. RDBMSのキーで知っておきたいキーが ２つあります 50
51. それが主キーと外部キーです 51
52. 主キーとは？ テーブル上に確実に1つ存在する属性 そしてそのキーから１行を特定できるもの 52
53. 図鑑No 名前 英語名 #004 ヒトカゲ Charmander #252 キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey 他の属性を全て特定できるキーを探す 主キー(PK:プライマリーキー) 53
54. 他にも主キーが主キーであるためには ルールがあります 54
55. 図鑑No 名前 英語名 #004 ヒトカゲ Charmander #004 キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey ルール①：主キーの重複は許されない 主キー(PK) 登録不可 55
56. 図鑑No 名前 英語名 #004 ヒトカゲ Charmander NULL キモリ Treecko #155 ヒノアラシ Cyndaquil #016 ポッポ Pidgey ルール②：主キーにNULLは許されない 主キー(PK) 登録不可 56
57. 外部キーとは？ 関連したテーブルのキー同士を 結び合わせる為のもの 57
58. 図鑑No 名前 英語名 地方名 #004 ヒトカゲ Charmander カントー #252 キモリ Treecko ホウエン #155 ヒノアラシ Cyndaquil ジョウト #016 ポッポ Pidgey カントー 外部キーについて 外部キー(FK：フォーリンキー) 地方名 カントー ホウエン ジョウト 58
59. 図鑑No 名前 英語名 地方名 #004 ヒトカゲ Charmander カントー #252 キモリ Treecko ホウエン #155 ヒノアラシ Cyndaquil ジョウト #740 ケケンカニ Crabominable アローラ 外部キー制約 外部キー(FK) 地方名 カントー ホウエン ジョウト 登録不可 59
60. 整合性のある仕組み このために上記のルールが存在している ということを再確認してください 60
61. RDBの種類 61
62. 各RDBの特徴、選定理由とか 大規模システムに microsoft大好き 多機能 シンプルなサービス向き 62
63. Herokuにアプリ上げる時 1万行まで無料やで 5mbまで無料やで 自前でHDD用意もす るのもあれだし、、、 63
64. こうして僕はPostgreSQLを採用しました <解せぬ 64
65. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ 最後に 65
66. いきなり論理設計とか変な言葉 出てきたけど一体なに？ 66
67. 皆さんはアプリとかシステム を作る時ってまずどうしますか？ DB使用した 67
68. 作るものが決まってたら いきなりプロジェクト作成して。。。 コード書いて。。。 B使用した 68
69. ってなることが今の若者は大半と 亡くなったおばあちゃんが 言ってました B使用した 69
70. プログラムを書く前にやるべきこと B使用した 70
71. すなわちそれが設計です B使用した 71
72. DOA(DATA ORIENTED APPROACH) プログラム書くよりも先にデータの設計を始める ということ 反語はPOA(PROCESS ORIENTED APPROACH) 72
73. プログラム書いて都度都度DBに対してアプローチするより DBの設計が先に決まってた方が開発しやすいよね 73
74. これが論理設計の ファーストステップです B使用した 74
75. この前提を頭においた上で… B使用した 75
76. 論理設計を行う上で必須の知識に 正規化というものがあります 76
77. 正規化とは？ >“リレーション”とはテーブル同士の関係を設定し、 関連付けるもの を体現することです 77
78. また重複した余分なデータ無くす行為 でもあります 78
79. ちょっといかつい単語並びますが やっていることは長ったるいテーブルを きれいに見せたいということだけです 79
80. 手順 80
81. 正規化の説明用に ポケモンテーブルを変えてみました ポケモンテーブル(拡張版) 作品世代 地方名 No.(地方別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ほのお 3 ホウエン #001 キモリ Treecko B くさ 2 ジョウト #004 ヒノアラシ Cyndaquil A ほのう 1 カントー #016 ポッポ Pidgey F ひこう 81
82. まずは主キーを探す ポケモンテーブル 作品世代 地方名 No.(地方別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ほのう 3 ホウエン #001 キモリ Treecko B くさ 2 ジョウト #004 ヒノアラシ Cyndaquil A ほのう 1 カントー #016 ポッポ Pidgey F ひこう 主キー(複合主キー) 82
83. 第一正規形 ⮚ フィールドには1つの値しか入れないようにする(スカラ値を満たす) ⮚ テーブルと呼べるものは既に第一正規系を満たしている ポケモンテーブル 作品世代 地方名 No.(地方 別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ほのう 3 ホウエン #001 キモリ Treecko B くさ 2 ジョウト #004 ヒノアラシ Cyndaquil A ほのう 1 カントー #016 ポッポ Pidgey F ひこう 83
84. 本題はここからです 84
85. 新作発売しますね！！！ 85
86. 新作はガラル地方というらしいです 86
87. とりあえずこのポケモンテーブルに 新地方名だけ登録しておこう 87
88. それができない ⮚ 主キーにNULLは登録できないから ポケモンテーブル 作品世代 地方名 No.(地方別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ほのう 3 ホウエン #001 キモリ Treecko B くさ 2 ジョウト #004 ヒノアラシ Cyndaquil A ほのう 1 カントー #016 ポッポ Pidgey F ひこう 8 ガラル ??? ??? ??? ??? ??? 88
89. ここで行う第二正規化 ⮚ 部分的関数従属を取り除く行為です ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID タイプ名 1 #004 ヒトカゲ Charmander A ホノオ 3 #001 キモリ Treecko B クサ 2 #004 ヒノアラシ Cyndaquil A ホノオ 1 #016 ポッポ Pidgey F ヒコウ 地方テーブル 作品世代 地方名 1 カントー 3 ホウエン 2 ジョウト 8 ガラル 地方テーブルとして切り出す 89
90. まず関数従属ってなんでしょう？ y = f(x):とある値が決まれば他の値が決まること ポケモンテーブル 作品世代 地方名 No.(地方別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ホノオ 3 ホウエン #001 キモリ Treecko B クサ 2 ジョウト #004 ヒノアラシ Cyndaquil A ホノオ 1 カントー #016 ポッポ Pidgey F ヒコウ 90
91. 部分的関数従属を見つける ポケモンテーブル 作品世代 地方名 No.(地方 別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ホノオ 3 ホウエン #001 キモリ Treecko B クサ 2 ジョウト #004 ヒノアラシ Cyndaquil A ホノオ 1 カントー #016 ポッポ Pidgey F ヒコウ とりあえず部分的に主キーから特定できるものを見つける 作品世代から地方名を割り出せる(部分的関数従属) 91
92. ここで行う第二正規化 ⮚ 部分的関数従属を取り除く行為です ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID タイプ名 1 #004 ヒトカゲ Charmander A ホノオ 3 #001 キモリ Treecko B クサ 2 #004 ヒノアラシ Cyndaquil A ホノオ 1 #016 ポッポ Pidgey F ヒコウ 地方テーブル 作品世代 地方名 1 カントー 3 ホウエン 2 ジョウト 8 ガラル 地方テーブルとして切り出す 92
93. あともうちょっと詰めましょう 93
94. 偶にポケモンは新タイプが追加されます 94
95. タイプ名が先じてリークされたとします とりあえずこのポケモンテーブルに タイプ名だけ登録しておこう と思う訳です 95
96. それもできない ⮚ これも主キーにNULLは登録できないから ポケモンテーブル(第二正規化後) 作品世代 No.(地方別) 名前 英語名 タイプID タイプ名 1 #004 ヒトカゲ Charmander A ホノオ 3 #001 キモリ Treecko B クサ 2 #004 ヒノアラシ Cyndaquil A ホノオ 1 #016 ポッポ Pidgey F ヒコウ 6 ? ? ? Z フェアリー 96
97. ここで行う第三正規化 ⮚やってることは第二正規形とほぼ同じです タイプテーブル タイプID タイプ名 A ホノオ B クサ F ヒコウ ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID 1 #004 ヒトカゲ Charmander A 3 #001 キモリ Treecko B 2 #004 ヒノアラシ Cyndaquil A 1 #016 ポッポ Pidgey F 地方テーブル 地方ID 地方名 1 カントー 3 ホウエン 2 ジョウト タイプテーブルとして切 り出す 97
98. 推移的関数従属を見つける 主キーからタイプIDを割り出せる、そのタイプIDからタイプ名を 割り出して分離する(推移的関数従属) 作品世代 地方名 No.(地方別) 名前 英語名 タイプID タイプ名 1 カントー #004 ヒトカゲ Charmander A ホノオ 3 ホウエン #001 キモリ Treecko B クサ 2 ジョウト #004 ヒノアラシ Cyndaquil A ホノオ 1 カントー #016 ポッポ Pidgey F ヒコウ 98
99. 色々言いましたが 実際ある程度自動的に正規化は 出来るようになると思います 99
100. 更に高次の正規形もあるんですが 第三まで知っていれば業務的に ある程度事足りるはずです 100
101. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ さいごに 101
102. 追加！ サロゲートキー ポケモンテーブル(第3正規化後) ID 作品世代 No.(地方別) 名前 英語名 タイプID 1 1 #004 ヒトカゲ Charmander A 2 3 #001 キモリ Treecko B 3 2 #004 ヒノアラシ Cyndaquil A 4 1 #016 ポッポ Pidgey F ⮚ “業務”上は意味を持たない連番するキーの事です ⮚ このカラム1つでレコードの特定が可能(1意)でめちゃくちゃ便利です ⮚ 多くのwebアプリケーションフレームワークではデフォルトで付いてきます 102
103. さっきまでのキーはナチュラルキー ポケモンテーブル(第三正規化後) 作品世代 No.(地方別) 名前 英語名 タイプID 1 #004 ヒトカゲ Charmander A 3 #001 キモリ Treecko B 2 #004 ヒノアラシ Cyndaquil A 1 #016 ポッポ Pidgey F ⮚ HDへの負担が少なくなる ⮚ “業務”上意味のあるキー 103
104. 散々ナチュラルキーで説明しといて なんですが、実際の業務では ほとんどサロゲートキーが見受けられる 気がします 104
105. ちなみになんですけど アローラ地方が舞台のS/Mでは 次作のUS/UMがパラレルワールド扱い で同じ地方だけど地方別No.が異なると いう事態が発生しています 105
107. 上の例だと全然一意にならないじゃない かというオチです 107
108. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ さいごに 108
109. • ER図について 109
110. ところで、、、、、 業務をもう行っている受講生さんいますか？ 110
111. サービスのテーブルってめちゃくちゃ 数多くないですか？ 111
112. 一目でどういう構造が分かりたくないですか？ 112
113. そこで役立つのがER図 113
114. ER図とは Entity Relationship Diagram 実体 関連 モデル ⮚ テーブルの関係性を図示するものです ⮚ 僕はこれないと物作れません ⮚ ポピュラーで分かりやすいIE記法(簡易版)で説明 114
115. エンティティを抽出する ポケモンテーブルは既に正規化を行い エンティティを抽出できています ＝ボトムアップアプローチ タイプテーブル タイプID タイプ名 A ホノオ B クサ F ヒコウ ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID 1 #004 ヒトカゲ Charmander A 3 #001 キモリ Treecko B 2 #004 ヒノアラシ Cyndaquil A 1 #016 ポッポ Pidgey F 地方テーブル 作品世代 地方名 1 カントー 3 ホウエン 2 ジョウト 115
116. 例えばECサイトを作りたかったら 会員エンティティ、商品エンティティ 作って、、、っていう話です 116
117. 最初からECを例にしろって話ですよね 117
118. リレーションを検討する このテーブルたちがどんな関係性にあるかを考えて 図時していきます タイプテーブル タイプID タイプ名 A ホノオ B クサ F ヒコウ ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID 1 #004 ヒトカゲ Charmander A 3 #001 キモリ Treecko B 2 #004 ヒノアラシ Cyndaquil A 1 #016 ポッポ Pidgey F 地方テーブル 地方ID 地方名 1 カントー 3 ホウエン 2 ジョウト 118
119. リレーションは基本の3つを覚えれば なんとかなるはずです 1 対 多 多 対 多 1 対 1 119
120. 1対多 ヒトカゲとヒノアラシは双方ともにほのおタイプです 120
121. ER図ではこう表します タイプ ID タイプ名 A ホノオ B クサ F ヒコウ N ノーマル 作品世代 No.(地方別) 名前 英語名 タイプID 1 #004 ヒトカゲ Charmander A 2 #004 ヒノアラシ Cyndaquil A ⮚ 一つのタイプは複数のポケモンを持つというアプローチ 121
122. 変な記号の意味 多 ０ １ 122
123. 多対多 ノーマル/ヒコウ の複合タイプって知ってましたか？ 123
124. こんなことするのは悪手です タイプテーブル タイプ ID タイプ名 A ホノオ B クサ F ヒコウ N ノーマル ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID 1 #016 ポッポ Pidgey F, N ⮚ スカラ値原則に反する 124
125. ER図でどう表現しましょうか？ 125
126. 連関エンティティ ⮚ 二次元のRDBの特性とスカラ値の原則上こういう表現しかできません ⮚ タイプは複数のポケモンを持ち、ポケモンは多数のタイプを持つという アプローチです 作品世代 No.(地方 別) タイプID 1 #016 F 1 #016 N タイプ ID タイプ名 A ホノオ B クサ F ヒコウ N ノーマル 作品世代 No.(地方 別) 名前 英語名 1 #016 ポッポ Pidgey 126
127. 1対1 地方ID No.(地方 別) 名前 英語名 タイプID 登場回トレ ーナー トレーナー 性格 … トレーナー 英語名 1 #004 ヒトカゲ Charmand er A ダイスケ 冷酷 … Daimian ヒトカゲレコードにアニメポケモンでの ヒトカゲの“初登場回の所持トレーナー”属性を追加したとします 127
128. こういう風にリレーションを張ります 地方ID No.(地方別) 名前 英語名 タイプID 1 #004 ヒトカゲ Charmander A 地方ID No.(地方別) 登場回トレ ーナー トレーナー 性格 … トレーナー 英語名 1 #004 ダイスケ 冷酷 … Daimian 128
129. 1対1関連は何の意味があるのか オブジェクト指向的にいけてない？ カントー ヒトカゲ Charmander ほのお 0.6m 129
130. MVCのModelとの関係 ActiveRecord型のORMではテーブルとModelクラスが1対1でマッピングさ れます ＝ポケモンテーブルがトレーナー情報を知りすぎてる事はOOP的に良くな い、もしくはイケてない 130
131. 最終的ER図はこんな感じになります タイプテーブル タイプID タイプ名 ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID 地方テーブル 地方ID 地方名 トレーナーテーブル 地方ID No.(地方別) 登場回トレ ーナー トレーナー 性格 … トレーナー 英語名 ポケモンタイプテーブル 作品世代 No.(地方別) タイプID 131
132. ER図を読み書きできるようになると 何が起こる？ 132
133. ・アプリ、システム制作に大活躍！ ・Joinした仲間にDB構成を説明しやすい！ ・ER図からテーブル作成する機能を使用でき る！ 133
134. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて 134
135. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 論理設計のアンチパターンについて ⮚ さいごに 135
136. DB設計には”べからず”集 所謂アンチパターンなるものがあります 136
137. このべからず集の一部を紹介したい と思います 137
138. ちなみにこれは私が担当している 採用管理ツールで実際設計されていたも のです 138
139. ジェイウォーク(信号無視) こんな形で一つのフィールドに複数の値を格納する真似をいい ます 139
140. 何がやばいか？ 140
141. まずスカラ値原則を守れてない >データをいつでも便利に 蓄積する 利用する 検索する 整合性のある仕組みを提供する 141
142. 更新コストぉ。。。。 142
143. 解決策 タイプテーブル タイプ ID タイプ名 A ホノオ B クサ F ヒコウ N ノーマル ポケモンテーブル 作品世代 No.(地方 別) 名前 英語名 タイプID 1 #016 ポッポ Pidgey F, N このテーブルを思い出して下さい 143
144. 連関テーブルを用いれば解決できます 作品世代 No.(地方 別) タイプID 1 #016 F 1 #016 N タイプ ID タイプ名 A ホノオ B クサ F ヒコウ N ノーマル 作品世代 No.(地方 別) 名前 英語名 1 #016 ポッポ Pidgey 144
145. まあそもそもこれ非スカラ値とかいう 次元の問題じゃない気もしますが 145
146. とりあえずのDeleteFlag 物理的にレコードを削除する代わりに 用いられます 146
147. 意図としては本当にデータを消さずに ナニカあったら無かった事にできる 147
148. 何がやばいか？ 148
149. 論理削除式でコードが塗れます Sample.Where(x => x.DeleteFlag == 0); Sample2.Where(x => x.DeleteFlag == 0); Sample3.Where(x => x.DeleteFlag == 0); . . . Sample100.Where(x => x.DeleteFlag == 0); Sample.where(DeleteFlag : 0) Sample.where(DeleteFlag : 0) . . . Sample.where(DeleteFlag : 0) 149
150. 解決策 とりあえずDeleteFlagカラムを作成するという 考えを捨てる RDBMSには障害が起こっても障害が起こる前に 巻き戻せる機能が備わっています 150
151. 色々申しましたが データベースはデータの整合性を保つ このために存在しているという ことを覚えていただけると幸いです 151
152. ⮚ DBについて ⮚ RDBMSについて ⮚ 論理設計について ⮚ 正規化とキーについて ⮚ 特殊なキーについて ⮚ ER図 ⮚ 最後に 152
153. DBの論理設計を行う機会って 会社だと意外と少ないのかなと 思ってます 153
154. 頭のいいひとはすんなり設計できるの でしょうけど。。。 154
155. 僕みたいに頭の良くない人は プライベートでサービス作ることが教わ るよりも一番設計の勉強になるのかなと 考えています 155
156. 以上です！ 156