この blog は移行しました
以下に移行しました
‘Intro to TensorFlow for Deep Learning | Udacity’ を受講した
Intro to TensorFlow for Deep Learning
Udacity の Free Course で Intro to TensorFlow for Deep Learning を受講した
空き時間などで少しずつ進めて、だいたい1ヶ月ちょっとで一通り終えられたと思う
この記事は受講した上での感想と、忘れないために受講後にわかったこと/わからないことを挙げている その後に簡単に自分の目線でのコースの説明も付けておいた
感想
コースの全体的な構成としては、数分の説明用のビデオ(Youtube)を見た後に Colab と呼ばれる Google が提供している Python のオンラインの実行環境で課題を行うという流れだった
以前受講した Coursera の Machine Learning というコースは Octave という Matlab ぽい数値解析言語を使っていたのに対して、この Colab + Python(numpy) という環境が気軽に実行できるかつ分かりやすくてとても良かった
課題の内容自体は、基本的には前回のビデオの内容から分かるもので自力で頑張るというより、そこからパラメータを変更したりして学習内容の結果を比較したりなどが多い印象 なのでどこかでスタックしてやる気を無くすみたいなことは無かった。反面、身に付いているかどうかは少し疑問が残るので以下に身に付いたこと、全然わからないことなどメモとして残す
身に付いたこと
- TensorFlow を用いた学習のパイプラインと実際のコーディング
- ただし見ないで書けるわけではない
- CNN
- Convolution/Pooling layer についても大枠理解
- また CNN が画像系で力を発揮することも理解した
- この blog もわかりやすかった
- Transfer Leraning とはなにか
- 大体これでいい結果出るのでは…?
- Overfitting の避け方
- これは単純に面白かった
- 意図的にニューロンを消したり(Dropout)、テストデータを擬似的に増やしたり(Image augmentation)など
全然わからないこと
- NNのモデルのレイヤーやパラメータをどうやって決めるのか
- 各レイヤーのニューロンの数、レイヤーの数など
- 何かセオリーがあるのか
- 問題にアプライするNNへの勘どころ
- CNN/Transfer Learning
- Transfer Learning だとしてどれを使うのか
- ImageNet, Inception V3 など(それぞれのアーキテクチャについてはもちろん知らない)
- Inception の論文
- Inception V3 の論文
- ImageNet, Inception V3 など(それぞれのアーキテクチャについてはもちろん知らない)
- Transfer Learning だとしてどれを使うのか
- CNN/Transfer Learning
- Python 3/Numpy がまだまだ怪しい
- 特に tensor のサイズ違いでのエラーなど多い
コース内容
Introduction to Machine Learning
Fahrenheit = celsius * 1.8 + 32 の温度の変換式を、簡単な NN モデルを使って学習し求める
Your First Model: Fashion MNIST
Fashion MNIST と呼ばれるテストデータを使って分類器をつくる ReLU や Softmax などの activation function に関する説明もここであった ReLU の説明は Kaggle のこの Notebook が分かりやすい
Introduction to CNNs
CNN とは何かの説明 CNN で扱う Convolution layer/Max Pooling layerについても説明あった 最後に CNN を使って再度 Fashion MNIST 分類器を作った
Going Further with CNNs
CNN を行う上でのデータ正規化(Resizing)や、カラー画像の扱い方についての説明や、overfitting を防ぐ手法(early stopping/image augmentation, dropout)について説明があった
Transfer Learning
MobileNet を使って dogs/cats 分類器を作った
Saving and Loading Models
学習したモデルを file export どうやって別の環境で load するかなどの話
Time Series Forecasting
時系列予測に関してのはなし 最初の方は machine learning というよりは平均などいくつかのmetricsでも十分一定の予測を行っていた その後からRNNなどを使っていたが少し内容が難しかったので飛ばした
Introduction to TensorFlow Lite
TensorFlow Lite と次のコースへの説明
この後
直近はこのコースの最後でも触れられていた Udacity の Intro to TensorFlow Lite を受講してみようと思う
長期的にはもう少し実践的な内容を期待しているので、並行して kaggle などにも少しずつ取り組んでいきたい
‘A Philosophy of Software Design’ を読んだ
A Philosophy of Software Design
Kindle だと 1000 円ちょっとで買えた。 Comment に関する Chapter は飛ばしたが、ざっと全部読んだ。 英語も平易な感じなので苦労せず読めた。
A Philosophy of Software Design
- 作者:Ousterhout, John
- 発売日: 2018/04/06
- メディア: ペーパーバック
内容を簡単に説明すると
- Complexity とは何か
- Complexity を最小化する大きな2つのアプローチ
- その2つについての具体的な複数手法(Design Principles)についての説明
- Complexity 増加の原因となりうる red flag
と、全体を通して Complextity と戦う話になっていた。
この本は code review や architecture design を複数人で行うときなどに revisit すると良いと思った。
テキストエディタの設計などもあり、かなり具体的な例も豊富だった。
ちなみに最近ななめ読みした Clean Architecture 本とも Complexitiy はじめ繋がるところが結構あった。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
- 作者:Robert C.Martin
- 発売日: 2018/07/27
- メディア: 単行本
Complexity とは
この本には Complexity の定義として以下のように書かれている。
Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
合わせて、測定するための目安として以下のような数式も用いられていた。

The overall complexity of a system (C) is determined by the complexity of each part p (cp) weighted by the fraction of time developers spend working on that part (tp).
システム全体の Complexity = システム内の各パーツの Complexity * そのパーツに開発者が費やす時間
というもの
Complexity 最小化への大きな2つのアプローチ
以下の2つが挙げられている
The first approach is to eliminate complexity by making code simpler and more obvious.
The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once.
- コードの単純化、より明確にすること
- Complexity をカプセル化してプログラマがそれに触れることなく開発できるようにすること
僕の認識だと、前者はシグマ内の (cp) を、後者は (tp) を減らすものだと思った
Complexity の兆候
Complexity の定義は上記のとおりだが、具体的にどういったことが起きると Complexity が高いか、についても以下の主に3つの視点から書かれている
- Change amplification
- Cognitive load
- Unknown unknowns
1つの修正を行うために様々な箇所を修正しないといけなかったり、1つの修正を行うために色々と前提として知ることが多すぎる状態だったり、そもそも何が分からないか分からない状態といった具合。文字だけみても最後のが最悪な状態なのが分かる
Design Principles & Red Flags
この本では、上記で話した Complexity に対してのアクションとしての Design Principles を十数個挙げてその中で具体例を用いて解説している。
またその中で Red Flags も合わせて十数個解説してくれていて、どのような Design/Architecture が Complexity を招きうるか、を示してくれていてとても分かりやすい。
いくつか挙げることもできるが、タイトルだけ聞くと「そうですね」で終わったしまう可能性あるので、実際に具体例交えて本を読むのが良いと思う。
‘An Elegant Puzzle: System of Engineering Management’ を読んだ
Summary
An Elegant Puzzle: Systems of Engineering Management (English Edition)
- 作者:Will Larson
- 出版社/メーカー: Stripe Press
- 発売日: 2019/05/28
- メディア: Kindle版
Yahoo, Digg, Uber, Stripe などの会社で EM/VPoE などの組織をリードしてきた(現在もしている) Will Larson @lethain さん。
エンジニアリング組織において発生する色々な課題に対して筆者が考える解決策を分かりやすく書いてくれている本になっている
以下は序文からの引用になるけれど
There’s a saying that people don’t leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to good solutions for complex management challenges can make the difference between fulfillment and frustration for teams, and, ultimately, between the success or failure of companies. Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 6). Stripe Press. Kindle Edition.
とある通り、 ”人は会社というよりマネージャーから去る”とよく言われる通りマネジメントはいかなる組織運営でも重要な部分。けれどそれについてはあまり構造だった訓練だったりはなく自身で考えることが未だに多い。複雑なマネジメントの挑戦に対する良い解決策を通してチームを不満から満足に変え、更に会社を失敗から成功に変えることができる
Notes
取りこぼしもあるけれど自分の中で特に印象に残った章は以下
この中でピンとくるものが一つでもあったら読んでも良いと思った
メイントピックは Organizations
Tools
Approaches
Culture
Careers
に分かれている
- Organizations
- Sizing teams
- Productivity in the age of hypergrowth
- Tools
- Introduction to system thinking
- Running an engineering org
- Time management
- Approaches
- Saying no
- Ways engineering managers get stuck
- Culture
- Opportunity and membership
- Kill your heroes, stop doing it harder
- Careers
- Roles over rocket ships, and why hypergrowth is a weak predictor of personal growth
- Hiring funnel
- Performance management systems
- Career levels, designation momentum, level splits etc
現在の自分自身の課題感もあってやはりエンジニアリング組織系のものに偏っていた
また Appendix にある Books I’ve found very useful もとても良くて、読んでみたいものがいくつかあった
- 作者:Donella H. Meadows
- 出版社/メーカー: Chelsea Green Pub Co
- 発売日: 2008/12/03
- メディア: ペーパーバック
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
- 作者:Tom DeMarco
- 出版社/メーカー: Currency
- 発売日: 2002/04/09
- メディア: ペーパーバック
- 作者:Michael D. Watkins
- 出版社/メーカー: Harvard Business Review Press
- 発売日: 2013/05/14
- メディア: ハードカバー
The Deadline: A Novel About Project Management (English Edition)
- 作者:Tom DeMarco
- 発売日: 2011/12/15
- メディア: Kindle版
Will Larson @lethain さんは blog の執筆も結構されているので、上記の本に関するトピックもあるので興味あれば読むのが良さそう
An Elegant Puzzle: Systems of Engineering Management (English Edition)
- 作者:Will Larson
- 出版社/メーカー: Stripe Press
- 発売日: 2019/05/28
- メディア: Kindle版
EOF 2019 でエンジニアリング組織について発表しました
EOF 2019
2019/10/31 に行われた EOF 2019 というイベントで登壇しました。
https://eof-github.github.io/eof2019/index.html
Slide
発表してみて
改めてスライドを作って言語化してみると、自分が考えてることなど言語化できて良い機会を頂いたなと感じました。
あまり普段は Engineering Manager の話をする機会ほとんどないので、来場者の方とも Ask The Speaker などで話すことができて良い刺激をいただきました。
20191211 追記
文字起こしした記事も作成していただきました。
メルペイiOSエンジニアが「EMとしての1年半」で気づいた、チームに必要な3つの要素 #eof2019 | mercan (メルカン)