Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術書・方法論とのお付き合い / how to learn theory
Search
philomagi
July 19, 2020
Technology
4
1.2k
技術書・方法論とのお付き合い / how to learn theory
philomagi
July 19, 2020
Tweet
Share
More Decks by philomagi
See All by philomagi
ドメイン駆動設計のホーリズム的側面 / domain-driven-design and holism
tooppoo
0
180
アート、サイエンス、「わかりやすさ」 / art, science, "easy to understand"
tooppoo
1
20k
ソフトウェアと「動的平衡」 / software-and-dynamic-equilibrium
tooppoo
1
1k
javascriptでも条件式を使いたい話 / want to use conditional expression in javascript
tooppoo
0
6.4k
Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component
tooppoo
4
3.6k
「オブジェクト指向」を再考する / reconsider "object-oriented"
tooppoo
2
820
「モデル」の二面性と設計を考える / dual nature of "model"
tooppoo
2
1.7k
「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain
tooppoo
9
2.9k
WEBフロントエンドにおけるソフトウェア設計の考察 / Consideration of software design in WEB front end
tooppoo
34
8.7k
Other Decks in Technology
See All in Technology
AWS環境のリソース調査を Claude Code で効率化 / aws investigate with cc devio2025
masahirokawahara
2
640
JavaScript 研修
recruitengineers
PRO
6
1.3k
生成AI時代に必要な価値ある意思決定を育てる「開発プロセス定義」を用いた中期戦略
kakehashi
PRO
1
220
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
140
【 LLMエンジニアがヒューマノイド開発に挑んでみた 】 - 第104回 Machine Learning 15minutes! Hybrid
soneo1127
0
200
実運用で考える PGO
kworkdev
PRO
0
120
「魔法少女まどか☆マギカ Magia Exedra」のグローバル展開を支える、開発チームと翻訳チームの「意識しない協創」を実現するローカライズシステム
gree_tech
PRO
0
320
努力家なスクラムマスターが陥る「傍観者」という罠と乗り越えた先に信頼があった話 / 20250830 Takahiro Sasaki
shift_evolve
PRO
2
120
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.6k
「AI2027」を紐解く ― AGI・ASI・シンギュラリティ
masayamoriofficial
0
150
Yahoo!広告ビジネス基盤におけるバックエンド開発
lycorptech_jp
PRO
2
320
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
3
630
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Art, The Web, and Tiny UX
lynnandtonic
302
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
The Invisible Side of Design
smashingmag
301
51k
Automating Front-end Workflow
addyosmani
1370
200k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Code Review Best Practice
trishagee
70
19k
A Tale of Four Properties
chriscoyier
160
23k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Practical Orchestrator
shlominoach
190
11k
Transcript
技術書・方法論とのお付き合い 〜技術書・方法論からどのように学び、使うか〜 1 @Philomagi 2020/07/18@Webエンジニア勉強会inVR 第4回 #WESinVR
発表者 @Philomagi • WEB系プログラマ • 自称フロントエンド寄り ◦ 最近のマイブームは SelfとSmalltalk ◦
vanila jsも久しぶりにちょっと触りたい • 設計の話とかが好きです ◦ DDDとかクリーンアーキテクチャとか ◦ 最近のSOLID原則の推しはI 2
今回のテーマ 3
初心者の頃に知っておきたかったこと 4
技術書・方法論と どうお付き合いするか 5
6
7 多種多様な技術書・方法論 • 様々なジャンル・観点の技術書・方法論が存在する ◦ ソフトウェアアーキテクチャ ▪ クリーンアーキテクチャ ▪ エンタープライズアプリケーションアーキテクチャ
(PoEAA) ▪ パターン指向ソフトウェアアーキテクチャ (POSA) ◦ ソフトウェア設計 ▪ ドメイン駆動設計 ▪ ユースケース駆動開発 ▪ テスト駆動開発 ▪ リファクタリング ▪ デザインパターン(GoF) ◦ etc...
どうお付き合いするか? 8
どのような姿勢で知識を得、 どのような姿勢で活用するか? 9
問題が起きやすいお付き合い 10 • 「この本に書いてあることに従えば、今困っていることが 解決できるはずだ!」 • 「この本に書いてある方法を実践することが、良いソフト ウェア開発なんだ!」 • 「この本を実践すれば、良いソフトウェアができるんだ!」
• 自分たちが直面している課題の「正解」が、外部に自立的に存在 しているかのように認識してしまう ◦ 結果、課題解決のために課題を深堀りするのではなく、どこかにあるはず の「正解」を探すための放浪に終始してしまう • 目的ではなく手段への注目が、”無自覚に”発生しがち ◦ 結果、目的に合わせて技術を選択・加工するのではなく、技術に合うように
目的が”無自覚に”選択・加工されることになりやすい どんな問題が起きやすいのか? 11
外部に「正解」を求める 12
問題・課題の外部に「正解」を求める 13 問題・課題
問題・課題の外部に「正解」を求める 14 問題・課題 「正解」
問題・課題の外部に「正解」を求める 問題・課題 「正解」 15
外部から「正解」は得られるのか? 16 • そもそも「正解」は実在するか? • 「正解」が実在したとして、人間は「正解」を認識・理解 できるのか? • 技術書・方法論は「正解」を語っているのか?
個人的な回答 17 • そもそも「正解」は実在するか? ◦ なんとも言えない。ただ、「有るかどうか分からないもの」を前提に置くのは危険に感じ る。 • 「正解」が実在したとして、人間は「正解」を認識・理解できるのか? ◦
何かを「これが正解だ」と解釈はできても、「正解」そのものを正確に認識・理解はでき ないのでは。 • 技術書・方法論は「正解」を語っているのか? ◦ これらが語るのは抽象化された理論であり思想であって、「正解」を語っているのでは ない。
個人的な回答 18 • そもそも「正解」は実在するか? ◦ なんとも言えない。ただ、「有るかどうか分からないもの」を前提に置くのは危険に感じ る。 • 「正解」が実在したとして、人間は「正解」を認識・理解できるのか? ◦
何かを「これが正解だ」と解釈はできても、「正解」そのものを正確に認識・理解はでき ないのでは。 • 技術書・方法論は「正解」を語っているのか? ◦ これらが語るのは抽象化された理論であり思想であって、「正解」を語っているのでは ない。
個人的な回答 19 • そもそも「正解」は実在するか? ◦ なんとも言えない。ただ、「有るかどうか分からないもの」を前提に置くのは危険に感じ る。 • 「正解」が実在したとして、人間は「正解」を認識・理解できるのか? ◦
何かを「これが正解だ」と解釈はできても、「正解」そのものを正確に認識・理解はでき ないのでは。 • 技術書・方法論は「正解」を語っているのか? ◦ これらが語るのは抽象化された理論であり思想であって、「正解」を語っているのでは ない。
個人的な回答 20 • そもそも「正解」は実在するか? ◦ なんとも言えない。ただ、「有るかどうか分からないもの」を前提に置くのは危険に感じ る。 • 「正解」が実在したとして、人間は「正解」を認識・理解できるのか? ◦
何かを「これが正解だ」と解釈はできても、「正解」そのものを正確に認識・理解はでき ないのでは。 • 技術書・方法論は「正解」を語っているのか? ◦ これらが語るのは抽象化された理論であり「思想」であって、「正解」を語っているので はない。
問題・課題の外部に「正解」を求める 問題・課題 「正解」 21
問題・課題の外部に「正解」を求める 問題・課題 「正解」 22
目的ではなく手段への ”無自覚な”注視 23
問題が起きやすいお付き合い(再掲) 24 • 「この本に書いてあることに従えば、今困っていることが 解決できるはずだ!」 • 「この本に書いてある方法を実践することが、良いソフト ウェア開発なんだ!」 • 「この本に従えば、良いソフトウェアができるんだ!」
何が起きるのか? • 注目する対象が、ソフトウェアの目的・対象ではなく方法 論・プロセスになる • 「何を作るか」「何を実現するか」ではなく、「どう作るか」 「どんな手順を踏むか」が第一になる • 目的のために技術を選択するのではなく、技術のために 目的を決定することになる
25
目的のための知識・方法論 26 ◦◦をできるようにしたい! ◦◦を世の中に実現したい!
目的のための知識・方法論 27 ◦◦をできるようにしたい! ◦◦を世の中に実現したい!
目的のための知識・方法論 28 ◦◦をできるようにしたい! ◦◦を世の中に実現したい!
目的のための知識・方法論 29 ◦◦をできるようにしたい! ◦◦を世の中に実現したい! 目的に技術を当てはめる 目的を前提として技術を解釈する
知識・方法論のための目的 30 ◦◦をできるようにしたい! ◦◦を世の中に実現したい!
知識・方法論のための目的 31 ◦◦をできるようにしたい! ◦◦を世の中に実現したい!
知識・方法論のための目的 32 ◦◦をできるようにしたい! ◦◦を世の中に実現したい!
知識・方法論のための目的 33 ◦◦をできるようにしたい! ◦◦を世の中に実現したい! 技術に目的を当てはめる 技術を前提として目的を解釈する
目的のための知識・方法論(再掲) 34 ◦◦をできるようにしたい! ◦◦を世の中に実現したい! 目的に技術を当てはめる 目的を前提として技術 を解釈する
目的と手段の逆転 ◦◦をできるようにしたい! ◦◦を世の中に実現したい! 目的に技術を当てはめる 目的を前提として技術 を解釈する 技術に目的を当てはめる 技術を前提として目的 を解釈する 35
目的と手段が入れ替わる「臭い」 36 • 「◦◦を使う/するのが良い開発方法だ!」 • 「◦◦のXXではこのようにすると書いているので、このやり方は間 違いです」 • 「〇〇って、結局コードはどういうふうに書くのが正解なの?」
目的と手段が入れ替わる「臭い」 37 • 「◦◦を使う/するのが良い開発方法だ!」 • 「◦◦のXXではこのようにすると書いているので、このやり方は間 違いです」 • 「〇〇って、結局コードはどういうふうに書くのが正解なの?」 「〜を実現したい」「〜のために」という言葉が無く、「◦◦を実践するに
は〜」「〇〇では〜」という会話に終止する
手段に注目するのは「不正解」か? • 手段に注目すること自体が問題、というわけではない ◦ 新しい技術を習得する、「この手段で目的が解決できるか」を検証するなど、手段自体 に注目するシーンもある 38
手段に注目するのは「不正解」か? • 手段に注目すること自体が問題、というわけではない ◦ 新しい技術を習得する、「この手段で目的が解決できるか」を検証するなど、手段自体 に注目するシーンもある • 問題なのは、自分がどこを向いているのかに無自覚なまま、特定 の何かに拘泥すること ◦
目的達成に指向しているなら、その達成手段は目的の内容・性質に依存する。目的の 内容・性質を無視した手段の選択は成立し難い ◦ 手段の実践や習得に指向しているなら、手段自体が自己目的化する。手段を適用す る対象は、「手段」という「目的」を達成するための道具にすぎない 39
問題になりがちなお付き合いのまとめ • 技術書・方法論を「正解」を語るものとして取り扱う • 技術書・方法論の手段に”無自覚に”注目し、技術 に合わせて目的を”無自覚に”加工する 40
技術書・方法論と どうお付き合いするか 41
個人的に目指している接し方 • 技術書・方法論の「手順・方法」ではなく「思想・理論」に注目する ◦ 「どのように」ではなく「なぜ」「なんのために」 ◦ 著者が目指している方向や到達点はどこか、記述されている手順・方法が導かれた理由は何 か、の方に注目する ◦ これらは抽象的であるが故に、個別具体的な問題を直接は解決してくれないが、故により広い
範囲をカバーし得る(=自分の問題を解くためのヒントになるかもしれない) • 「正解」を求めてではなく、問題解決の視点を増やす ◦ 手順・プロセスに従うというよりは、自分が物事を考えるための視点・引き出しを増やすことを目 指す(ために、著者の思想・理論自体に注目する) ◦ 視点・引き出しが増えれば、いざ具体的な問題にあたった時に「こういう方法が使えるのでは」 と、その問題に即した解決方法を( webや脳内で)検索することができる 42
個人的に目指している接し方 • 技術書・方法論の「手順・方法」ではなく「思想・理論」に注目する ◦ 「どのように」ではなく「なぜ」「なんのために」 ◦ 著者が目指している方向や到達点はどこか、記述されている手順・方法が導かれた理由は何 か、の方に注目する ◦ これらは抽象的であるが故に、個別具体的な問題を直接は解決してくれないが、故により広い
範囲をカバーし得る(=自分の問題を解くためのヒントになるかもしれない) • 「正解」を求めてではなく、問題解決の視点を増やす ◦ 手順・プロセスに従うというよりは、自分が物事を考えるための視点・引き出しを増やすことを目 指す(ために、著者の思想・理論自体に注目する) ◦ 視点・引き出しが増えれば、いざ具体的な問題にあたった時に「こういう方法が使えるのでは」 と、その問題に即した解決方法を( webや脳内で)検索することができる 43
この発表との「接し方」 • 技術書・方法論の「手順・方法」ではなく「思想・理論」に注目 する • 「正解」を求めてではなく、問題解決の視点を増やす 44
この発表との「接し方」 • 技術書・方法論の「手順・方法」ではなく「思想・理論」に注目 する • 「正解」を求めてではなく、問題解決の視点を増やす この発表内容自体にも↑は適用可能 (実際に、この発表は「正解」を提示するものではありません) 45
この発表内容との「お付き合い」 • 「技術書・方法論とのお付き合い」の「手順・方法」ではなく 「思想・理論」に注目する • 「技術書・方法論とのお付き合い」の「正解」を求めてではな く、問題解決の視点を増やす 46
まとめ • 以下のような取り扱い方は問題を起こしがち ◦ 技術書・方法論を「正解」を語るものとして取り扱う ◦ 技術書・方法論の手段に”無自覚に”注目し、技術に合わせて目的 を”無自覚に”加工する • 個人的に取ろうと努めているスタンス
◦ 「手順・方法」ではなく「思想・理論」に注目する ◦ 「正解」を求めるのではなく、問題解決の視点を増やす 47
ご清聴ありがとうございました 48