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
非エンジニアのための 0からわかる プログラミング・開発講座
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Yui Nishimura
March 24, 2021
Programming
210
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
非エンジニアのための 0からわかる プログラミング・開発講座
Yui Nishimura
March 24, 2021
More Decks by Yui Nishimura
See All by Yui Nishimura
未踏ジュニアに参加して/mitoujr-2019-yuinishimura
nisshi79
2
380
Other Decks in Programming
See All in Programming
メールのエイリアス機能を履き違えない
isshinfunada
0
230
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
540
Foundation Models frameworkで画像分析
ryodeveloper
1
600
変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル | What Doesn't Change Decides What Can — IDD × Event Sourcing × Immutability
tomohisa
0
1.4k
【QA Test Talk Vol.8】AI-DLC による Whole Team Approach の加速
pkshadeck
PRO
0
120
Go 1.27 における memory allocation の高速化
andpad
0
110
Detecting Compromised CI with eBPF and Cilium Tetragon
lizrice
0
160
関東Kaggler会_NVIDIA_Nemotron_コンペ_振り返り
rick_ds
0
490
Japan Community Day at Kubecon + CloudNativeCon Japan 2026: Learning Container Privilege Control by Building My Own Low-Level Container Runtime
ternbusty
1
150
AI時代、エンジニアはどう育つのか -未経験エンジニアの成長を間近で見て考えたこと-
thasu0123
0
220
人間の目はかわらない、だからJPEGは30年もつ
yuzneri
12
18k
源内ハンズオン概要編
hideg
0
130
Featured
See All Featured
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
480
Abbi's Birthday
coloredviolet
3
9.3k
Navigating Team Friction
lara
192
16k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
3
420
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
480
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
66
57k
Optimising Largest Contentful Paint
csswizardry
37
3.9k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
63
45k
Design in an AI World
tapps
1
280
HDC tutorial
michielstock
2
790
What's in a price? How to price your products and services
michaelherold
247
13k
Transcript
⻄ 非エンジニアのための ゼロからわかる プログラミング・開発講座
01 ⽬的 02 アプリが動作する仕 みを ・例で 快に 03 の開発はどの に
めて いくのか 04 プログラミング 05 疑 résumé
⽬的 1 なぜ 、プログラミングを この 義で得られること ぶことが必 か
なぜ 、プログラミングを ぶことが必 か 13 01 ⽣の攻略 の1つ 現代において、コンピュータ ーは
隷、プログラムは と⾒なすことができる。 政 の でもある り、 現代の「 み・書き」算 になっている。 ある 味、コミュニケーシ ョン・異 理 ⼒ 02 基 として 03 「 き」を発⾒するために プログラミングで物が動くのは 「 しい」 優 なプログラマーはなぜ優 か。
これまでの「⾃ のために働いてくれる他者」 を 隷にする。 現代では禁⽌されている により、 を従わせる ⾃由にできる が1 円
上あるひといる? 構 ・ ⼒構 を作り、 が動く構 をマネージ メントする 、 、王 授 ⼒を持ち、 が⾃ら動くようにする アイドル、 、 、配偶者、Youtuber 、可処 時間ハッカー 現代は「コンピュータに働いてもらう」が可 になった ⼀ が で「 隷」を持てるようになった めて の時代 だからコンピュータについて ぶ必 がある 01 ⽣の攻略 : ⾃ の為に働いてくれる 他者を⾒つける https://www.slideshare.net/TokorotenNakayama/21-131325177
https://twitter.com/fladdict/status/774988305062506496?s=20
お金→ 材( エンジニア)→ システム→ お金 07 ニューヨークにあるゴールドマン・サックス の⽶国株の ⾨には、 盛期の2000
年に 600 のトレーダーが在籍し、⼤⼝ の ⾏の に じ、株を売買していた。現在、こ の ⾨にはたった2 しか っていない。 株式売買の⾃動 プログラムが、他のトレーダ ーの を ったのだ。プログラムを えるのは 200 のコンピューター・エンジニアだ。 https://www.technologyreview.jp/s/24542/as-goldman-embraces-automation-even-the-masters-of-the-universe-are-threatened/
02 DX 時代の 基 として 何をするにしても、 プログラミングは わってくる 業をやりたい →プログラミングが必
作物の 理システムetc.. の 業も、dx しないと⽣き れない DX 戦略はどうする DX 材/ エンジニアの採⽤は コミュニケー ションはどうする https://youtu.be/nKIu9yen5nc
https://scrapbox.io/nishio/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BB%E9%9D%9E%E3%83%97%E3%83%AD%E3%82 %B0%E3%83%A9%E3%83%9E%E3%81%A8%E3%81%84%E3%81%86%E8%AA%A4%E3%81%A3%E3%81%9F%E4%BA%8C%E5%88%86%E6%B3%95 だけが 国 を すればいいわけではない とコミュニケーションをとるには、 国 の知識 が必を間に挟んだとしても、相⼿の国の
や⾵ は 知っておく必 プログラマだけがプログラミングを覚えればいいわけで はない プログラマとコミュニケーションをとるには、コンピ ュータの知識が必 プログラマを間に挟んだとしても、 コンピュータの や⾵ は知っておく必 Computational Thinking は現代の君主論 間よりも圧 的な労働⼒を持つ 算 をいかにし て するか 為政者は ができなくとも理 しておく必 がある https://www.slideshare.net/TokorotenNakayama/21-131325177 プログラマだけ すれ ばよいのでは?
3. 「作りたい何か」を 発⾒する 優 なエンジニアは「プログラミングを ばないと」と って ばない プログラミングで作りたいものが作れると しい、と
じ てもらいたい あくまで⾃ で決めた⾃ で作りたいものを る事が重 この では、 ⼤ 「どう活⽤しよう」「何作ろう かな、と える」に げるためのきっかけにしたい https://twitter.com/linux123pc/status/1373565403390038017?s=21
2. アプリが動作する仕 みを ・例で 快に
None
None
None
None
None
https://www.google.com/url?sa=i&url=https%3A%2F%2Fjapanese.engadget.com%2Fjp-2019-02-09- casio.html&psig=AOvVaw2wPFeIsVn6q4S5CS8gAMyB&ust=1616521466801000&source=images&cd=vfe&ved=0CAIQjRxqFwoTCMD27PG5xO8CFQAAAAAdAAAAABAD コンピュータに指⽰するためには、 マシン に する必 がある コンピュータ = 算
Instagram で を できるのも Youtube で動 を⾒られるのも モンストで べるのも マシン を使っているから コンピュータは2 しか えない マシン に する必 がある
操作を のレイヤを し、 マシン に翻 する
レイヤとは ≒抽 度 料理の場 : 低レイヤ(抽象度:低、具体的) ⾼レイヤ低レイヤ(抽象度:低、抽象的) 「料理を 作りたい」 「中華料理が
作りたい」 「 を 作りたい」 ミンチ⾁を... の⽪を... 」
コンピュータ の歴史 コンピュータは、歴史上より いレイ ヤからも れる に してきた Apple は何が⾰
的なのか これから こること
期のコンピュー タ の り、⼿で スイッチをパチパ チ切り替えて使っ ていた ENIAC より いレイヤからも
れる に だけの味 気ない ⾯だ が、OS として使 えた。 MS-DOS OS にGUI( マウス で操作する ⾯) を し⾰ を こした Macintosh
タッチ、キー ボード等指で の操作に え 声での操作に も iphone 声での操作に 常に曖昧な 葉にも
するように Echo
低レイヤ 操作( ボタン・ ⼒・など) 令 果・ ⾯ ⽰ API コール
果 果・ ⾯ ⽰ 電気 算 果
レイヤ( レベル) ≒抽 度 レイヤ: ハードウェアに いかという 味。 レベルが いほど⽣のハードウェアを
識する。 械 に い ⼀ 下のレイヤはCPU ⼀ 上のレイヤは ⾯(UI) 常、我々の操作はアプリケーション→OS→ ハードウェアの順 に翻 ・ され、 的にCPU で 算される。 低レイヤ ⾼レイヤ
抽 ( ブラックボックス ): プログラミングの重 な え 抽 の⽬的はいくつかのまとま りに
前を付けることで,内 の を気にせずに り うことで す。「ブラックボックス 」とも います。ブラックボックスでは ⼒と ⼒だけが決まっていて内 の処理を隠しています。 ブラックボックスの例として電卓 がある。キー ⼒ , 晶 ⽰を み るだけで 算が ⾏できる が,内 でどのような処理をして いるかは からない。 https://xtech.nikkei.com/it/article/COLUMN/20050913/221049/ ブラックボックス「みじん切り」 ブラックボックス「 める」 半 に切って、切れ みを れて、.... フライパンに油を いて、 をつけて、... 例) 料理の場 品を作って、 み わせるイメージ。 回中 の処理を書くのではなく、⼀度書いた処理を み わせて使う
プログラミング も、より いレ イヤから れる に してきた
プログラミング のレイヤー け レベルの が しい? レベルプログラミングを ぶの は、 レベルプログラミングを
ぶ事に べ 常に しい マシン アセンブラ C++ 等 レベル Javascript 等 レベル フレームワーク Nocode
フレームワークとは 年はフレームワークによって仕事も かれている フレームワークとは、簡単にアプリケーションやシステムを開発するために、 例えばWeb サイトでよく使う「ボタン」「メインメニュー」といった 品が⽤ されている フレームワーク に書き
が く異なるため、採⽤する ・開発する はほとんど別 として われる。 必 な が予め⽤ された⾻ み 代 的なフレームワーク:
代 的な / フレームワーク
主な⽤ ・レイヤー モダン/ レガシー 01 02 perspective
レイヤ フロントエンド レイヤ バックエンド・OS モダン レガシー
エンジニアの中でトレンドになっている と 開発の現場よく使われるプログラミング レガシー モダン エンジニアが む しい 描きやすい より
レイヤの が い フレームワークが い や開発セオリーがすぐ わる プロの開発の現場でよく使われる 受 、金 お い ( 性重 ) はあまり わらない 立された開発セオリー コストが く作れる 性・ ⽣ 性・ 頼性
: 金 のサービス開発は⼤ 性が⼤事 東 の件 にアップデートだと 性が必 なため前書き しができない
式年
レガシーな技 の例 COBOL
モダンな / フレームワーク
Flutter は Google が開発しているオープンソースのアプリケー ションフレームワークです。 クロスプラットフォームに しており、ワンソースで のプ ラットフォーム(iOS 、Android
、Web 、Windows 、Mac 、Linux ) に したアプリを開発することができます。 また、マテリアルデザインによる しい UI を利⽤することがで きます。 クロスプラットフォーム(iOS 、Android 、Web 、Windows 、 Mac 、Linux ) Dart による開発 異なるプラットフォームで共 の UI (独⾃のマテリアル UI ) ホットリロード( したコードをリアルタイムに 映) な動作 クロスプラットフォーム 1つのコード iOS Web Android
Go は2009 年11 ⽉にGoogle がオープンソースで 開したプログラミング です。 サーバーサイドがメイン Google App
Engine for Go というPaaS を使うこと ができる Go は 常にコードが書きやすく、冗 な は 不 。 パフォーマンスの良いコードを書きやすい がシンプルで みやすい AI のライブラリchainer 等もpython で書かれて いる。 AI といえばPython パフォーマンスは り良くない
の開発では、 の ・フレームワークを み わせる API
フロントエンドとバックエンドは、 API で がれる API とは、バックエンド(サーバー側)に⽤ する、受付 ⼝の なもの フロントエンド側から、APi
を利⽤する事により、サーバー側での処理と すr API ⼒された⽇付の予 状況を すAPI ⽇付を ⼒ 予 状況 予 状況が ⽰される
3. の開発はどの に めていくのか
エンジニアのイメージ ずっと黒い ⾯ ずっとキーボードをカチャカチャ ずっとコードを書いている
スラスラ書いて、1 発で動く ↓ 書いたらエラーが当たり前 のエンジニア: 2 つの間 い ずっとコードを書いている ↓
えている/ べている時間も い
Twitter べる える コード を書く エンジニアの開発における時間配 ( 例) 構な時間こんな じで
え んでいる。 ( しかけないで... )
エンジニアに必 な Top3 耐⼒ べる⼒ 英 ⼒ 1. 2. 3.
書いたらエラーは当たり前 に指⽰しないと1mm も動かない 書かれた りに動く タユピンコ の 徴 1 箇
でも間 い・1 でも間 いがあると⼀切動かない
エラーを⾒れば、 どこが間 っているか かる file not found: ファイルが ⾒つからなかったよ 「エラーを
してくれる」と うの もプログラミング の 常に重 な たまにエラーが ないのにバグが て⼤ ... エラーを したらまた しいエラー が、の り し
仕 ・エラーの 策を べる stack Overflow で 問 式ドキュメントを む(
重 ) GOogle
ポイント: 式ドキュメントを むこと 個 のブログに有 な情 が っている場 もあるが、そ の
とは が う/ その が間 っている可 性もある 問題にハマってしまうこともある 基 的に使っている ・フレームワーク等の 式ドキュ メントを む が作ったものなので、作った が書いている 書 が⼀ 良い。 界中の が作るので、英 が い
・フレームワークは、 界中の が、 界中の に向けて 作っている Flutter: Google Vue.js 中国の個
Facebook Ruby: ⽇ ( ) 英 でドキュメントが書かれている バグの情 も英 に にある
チーム開発の ⼿ について で開発する場 、「どうプログラミング するか」 に、「どうチームをマネージして いくか」という事を えなければいけません。 GAFA
でも採⽤されている⼿ から、気をつけ るべきポイントまで、⼀気にご します。
1. ウォーターフォール 受 開発でよく⽤いられる。 からの を固め、 するビジネスモデルに マッチしている まずは を
て固めてから、 体 を めてゆく、 と う⼿ 開発スピードが早い、と う利点がある。 ユーザーの をソフトウェアに 映しづらい、と う 点がある。
https://qiita.com/bonybeat/items/a175d3ef8c9631ce3f84
ウォータフォール・モデルの歴史は古く,1968 年にさかのぼる。この年,⻄ドイツのガルミッシュに おいて、NATO 援の国 が開かれ,ソフトウェア開発をそれまでの 的な作成 から, 代 的な⼯業 品としての
作成 に えることが された。 その 果,ソフトウェアを開発する をいくつかの⼯ (フェーズ)に け,各⼯ の 了を 味す るドキュメントを作成して, を 理するとともに作成したドキュメントを 査することによって早 いうちから品 の作り みをしようとする えが提 された。 これがウォータフォール・モデルである。このときのモデルはベームに よって 正され, ⽇ 界中で使われるものになった。 ウォーターフォールモデルの に する ウォーターフォールに する を く ⼩ NATO の にて提唱
2. アジャイル 02 スタートアップで主に⽤いられる開発⼿ イテレーション( 復) と呼ばれる い期間で、 や開発 を
り し⾏う⼿ 。 に を て決めてしまうウォーターフォールに し、 単なる開発⼿ だけでなく、 論も まれた 念にな っているの な再 価、 を わせた 思 の 重 、 的 ない 書 ユーザーの を り れながら開発を⾏う。
トライ& エラー を り す スタートアップ 業では、 りがあることを前提に、それをできる り早期に 正する、つまり、「⼩さく、早く失敗する」ことを重
しています。その開発⼿ として 奨されているのが「アジャイ ルモデル」です。 アジャイル開発では、「 復(イテレーション)」と呼ぶ い開発 期間を1 つの単 とし、その単 ごとに成果物を提⽰し するこ とで、失敗するリスクの ⼩ を ります (中略) ウォーターフォールモデルでは 期⼯ で正しい 件が得られなけ れば で⼤きく失敗するのに し、アジャイルモデルでは、 期 から⼩さな失敗を り みながら、 しずつビジネスを していけることがわかると思います。 https://qiita.com/bonybeat/items/a175d3ef8c9631ce3f84
アジャイルソフトウェア開発 たちは、ソフトウェア開発の あるいは を⼿助けをする活動を じて、 よりよい開発 を⾒つけだそうとしている。 この活動を して、 たちは
下の価 に った。 プロセスやツールよりも個 と を、 括的なドキュメントよりも動くソフトウェアを、 よりも との協 を、 に従うことよりも への を、 価 とする。すなわち、左 のことがらに価 があることを めながらも、 たちは右 のことがらにより価 をおく。 Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas © 2001, 上 の著者たち この は、この 書きも めた形で を めることを 件に ⾃由にコピーしてよい。
アプリ開発のリアル
その⽇の掃 当 を知らせる 掃 当 BOT
LINE BOT にした 理由 クラスメイト 員にLINE が すでにあるクラスのLINE グループに 知ができる
「便利そうだからうちのクラスにも しい」
None
の中の 当 の問題点 ⼿間がかかる 01 ⼿間がかかる 01 物理的制 がある 02
為的トラブルが きる 03
掃 当 BOT は 回プログラミ ングが必 … 簡単に できるよう にすれば
々な当 に使える
None
当 に わる⼿間を ⼩ にしたUX
None
None
None
None
None
None
がToubans! を作った
⼿回し 掃 当 ・ ⼿に回す ・回し れ ・ れ
スマホで 1 ⽇で Java で 授業中、 の下でコードを書いては べ、プリントの 裏にアルゴリズムを書いて のコード
その 、PHP で 書き し その 、Java のままではLINE Bot として
開するには不向きであったため、PHP に書 き え。
リリース 、Discord バージョンを作りたいと われた 僕の発 を いていた⼩ ⽣の男の オープンイノベーションを じた
OSS の開発で こりやすい
ふつう、ソフトウエアのソースコードは知的財 として保 され、ソフトウエ ア・ベンダーと呼ばれる 業は、そこから作成されたバイナリ( ⾏イメージ) のみを 売してビジネスとしています。 それに して、OSS
(オープンソース・ソフトウエア)とは、ソースコードが 償 で 開され、 良や再配布を⾏うことが に しても 可されているソフトウエ アのことです。 OSS と たようなソフトウエアにフリーウエア(フリーソフト)があります。 フリーウエアも 償で提供され、だれでも使うことができます。 しかし、フリーウエアの くは、個 向けのちょっとした便利な (圧 ・ 凍とか)を 現するツールで、開発も個 で⾏われている場 がほとんどです。 ⼀ 、OSS は、OS やデータベースといった 業向けシステムでの利⽤を⽬的とした ものが となります。OSS は、このようなシステムでも使⽤に耐える や品 を 現するために、 くのボランティア開発者がインターネットを して共同開 発しており、この 団のことをOSS コミュニティと呼びます。 OSS Open Source Software https://www.ossnews.jp/oss/ Firefox
OSS の仕 み https://www.google.com/url?sa=i&url=https%3A%2F%2Fthinkit.co.jp%2Fcert%2Fbooks%2F1%2F1%2F2%2F3.htm&psig=AOvVaw0IyPxUtCBoEbRL0W4Hg6G8&ust=1616617469756000&source=images&cd=vfe&ved=0CAIQjRxqFwoTCJjls8Kfx-8CFQAAAAAdAAAAABAN
OSS コミッターだと採⽤に 常に有利 OSS コミッターとして活 する の需 は 常に い
https://www.wantedly.com/projects/450399 https://type.jp/et/feature/11311/
4. プログラミング 助⾛は⼗ です までの知識を活かし て、 プログラミングの 界に2 、3 踏み
れましょう 11
な落とし は⼤ な「 構築」 さあコードを書き めましょう!... と いたいところです が、開発を める前にもう1
仕事する必 があります。 「 構築」とは、あなたのPC に、プログラミングが め られる を える事です。 者が もつまづきやすい ポイントになっています。
クイックに めたいなら、Web 上で めよう 構築は 常に⾯ で な作業ですが、(しかもプログラミングの とはなんら ない)
年、Web 上の開発 が ってきています。ちょっとした ⾨なら⼗ ですし、プロ⽤の も いつつあります。 Code Pen( ⾨⽤) codespaces( プロ⽤)
半 5m の問題を 決する。 ⾃ から半 5m 内で、問題は必ず こっている。 「プログラミング」を
ぶためにベストな は、 何か⾃ の作りたいものを1つ、作ってみる事で す。半 5m; 場の 、 のホーム、⾃宅の の上 に、プログラミングで 決できる 題は っていま す。 「作りたいもの」 の⾒つけ
5. 疑 何でもどうぞ! 11