勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

2017年下半期に読んだ本まとめ

book

2017年7月～12月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2017年下半期に読んだ本

2017年7月～12月に最後まで読み終わった本はこんな感じ。

  1. アイデア大全
  2. バナナ剥きには最適の日々
  3. ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装
  4. 宇宙創成（上）（新潮文庫）
  5. 宇宙創成（下）（新潮文庫）
  6. 1Q84 BOOK 1
  7. 1Q84 BOOK 2
  8. 1Q84 BOOK 3
  9. シャンタラム(上) (新潮文庫)
  10. シャンタラム（中） (新潮文庫)
  11. シャンタラム(下) (新潮文庫)
  12. かくて行動経済学は生まれり (文春e-book)
  13. ビジネス・フォー・パンクス
  14. 脱出航路 (ハヤカワ文庫 NV 283)
  15. [asin:B01I4VPUVU:title]
  16. LIFE PACKING 未来を生きるためのモノと知恵
  17. [asin:B07123SDZX:title]
  18. 新しい分かり方
  19. SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
  20. 最後の晩餐 (文春文庫)
  21. スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
  22. ブラックアウト 上 (角川文庫)
  23. ブラックアウト 下 (角川文庫)
  24. 計画の科学　どこでも使えるPERT・CPM (ブルーバックス)
  25. 母の記憶に (新☆ハヤカワ・ＳＦ・シリーズ)
  26. クォンタム・ファミリーズ (河出文庫)
  27. 横浜駅SF【電子特典付き】 (カドカワBOOKS)
  28. システムを「外注」するときに読む本
  29. [asin:B074J8RZ6Z:title]
  30. 今すぐ実践！　カンバンによるアジャイルプロジェクトマネジメント マイクロソフト関連書
  31. バイエルの謎: 日本文化になった教則本 (新潮文庫)
  32. ライフハック大全―――人生と仕事を変える小さな習慣250

オススメ文芸書編

たまたま2017年下半期はパラレルな世界を扱う2小説を読んだ（「1Q84」「クォンタム・ファミリーズ」）のだけれども、どちらもよかった。それぞれ過去の作品のオマージュという意味でも相似形を成しているのが興味深い。「1Q84」とオーウェルの「1984」、「クォンタム・ファミリーズ」と村上春樹の「世界の終わりとハードボイルドワンダーランド」という関係。あえて一冊を選ぶなら「クォンタム・ファミリーズ」を推す。量子コンピュータについても盛り上がっていることだし（本作品は量子コンピュータにも少し関係がある）。

クォンタム・ファミリーズ (河出文庫)

クォンタム・ファミリーズ (河出文庫)

  • 作者:東 浩紀
  • 発売日: 2013/02/05
  • メディア: 文庫

オススメビジネス書編

面白さだけで言えばルイスの「かくて行動経済学は生まれり」である。鉄板の面白さ。なお本作で興味を持った勢いで、「ファスト＆スロー」まで読むのがベストだと思う。

かくて行動経済学は生まれり (文春e-book)

かくて行動経済学は生まれり (文春e-book)

ファスト＆スロー　（上）

ファスト＆スロー　（上）

ファスト＆スロー　（下）

ファスト＆スロー　（下）

オススメ技術書編

Googleで実際に利用されている運用、システム管理に関するベストプラクティスを紹介する論文集である、いわゆるSRE本が素晴らしかった。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

  • 発売日: 2017/08/12
  • メディア: 単行本（ソフトカバー）
なお原著の内容は全て公開されているのだけれども、日本語で読めるというのが有難い。

この半期の振り返り

実は10月頃から仕事が非常に忙しくなってしまって、あまり読書に投じる時間が作れなかった。というわけで、かなりの本を積んでしまっている状況である。かなり、まずい。
あと、上記まとめには含んでいないのだけれどもこの半年で雑誌類の（継続的な）購読を完全にやめてしまった。ずいぶん前から新聞も取らなくなっているので、紙に印刷された文字を読む機会はずいぶんと減ったことになる。なお仕事的にもペーパーレスが進んでおり、印刷物を見る機会も減っているので、なんというか少しずつ風景が変わり始めているような気がしている。

過去の読書ふりかえり記事

Incident Command Systemについて調べた

Project Management

Google SRE本を読み終わった。いや、これはすごい本だ。しかし非常に広範囲なプラクティスの詰め合わせ（というか論文集だ）のため、完全に消化不良である。ゆえに、同書で気になった箇所を少しずつ整理検討しているのだけれども、そのひとつがIncident Command Systemである。これはすぐに使いこなしたいプラクティスだと思っている。まぁ、仕事の規模や質次第かも。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Incident Command Systemとは何か？

14.3 インシデント管理のプロセスの構成要素
インシデント管理のスキルとプラクティスは、熱意ある個々人のエネルギーを正しい方向に向けるために存在するものです。Googleのインシデント管理のシステムは、明快でスケーラブルであることで知られるIncident Command Systemに基づいています。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

  • いや、知られていないよ！知らなくてごめんなさい！
  • 英語版は全文公開されているので、興味があればこちらから該当箇所が読める。Google - Site Reliability Engineering

何かと思ったら、災害（障害）発生時の対応組織をボトムアップに（ブートストラップ的に）構成する標準化されたマネジメントシステムだった。消防とか警察とか軍事関連のように見える。いろいろ調べてみたけれども、以下のWikipediaの記事が一番わかりやすい印象。

  • インシデント・コマンド・システム - Wikipedia
  • 1人の監督者（インシデント指揮者）が5-7名までのメンバーで構成される臨時組織を立ち上げて問題に対処する。指揮者の監督限界を超えた場合は組織を分割しなければならない。
  • 指揮、実行、計画、後方支援、財務・総務の5つの機能をチームで分担して実行する。

米国では、1970年代、多くの山火事が発生し、当時の現場指揮官が、

  • 一度に多くの人が、一人の監督者に報告するので処理しきれない（上がって来る報告を溜めるバッファがない）。
  • 関係機関がそれぞれ異なった組織構造になっており、組織的な対応が困難。
  • 信頼のおける情報が流れてこない。
  • 通信装置や通信手順が統一化されていない。
  • 関係機関の間で共通の計画を策定するシステムがない。
  • 指揮命令系統が不明確。
  • 関係機関が使用する用語が統一化されていない。
  • 目標が不明確。

等の多くの問題に直面したため、1979年に消防大学校（Fire Academy）が次のコンセプトの下で「ICS」を開発した。
インシデント・コマンド・システム - Wikipedia

というわけなので、ITシステムの障害対応においても上記のような対応の失敗や課題に直面したことがあれば、採用検討に値するものではないかと思っている。

参考

情報システムの障害状況ウォッチ（2017年前半）

Postmortem Project Management

SEC Journal50号で2017年後半の情報システム障害状況まとめが公開されたので読んでみる記事。単なる野次馬なんだけれど、勉強になるので続けている。

過去に書いた関連記事は以下の通り。

SEC Journal最新号の入手はこちらから。

情報システムの障害状況ウォッチ（2017年前半）

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。なお今期は割と注意して日経コンピュータ記事を読んでいたので、前期よりは情報は充実しているつもり。また4桁数字は元ネタ記事にあるトラブルNo.である。

数が多すぎて、調べるのも一苦労。

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

おすすめ
ZERO BUGS シリコンバレープログラマの教え

ZERO BUGS シリコンバレープログラマの教え

まだ読めていない

上司・部下間のコミニュケーションのKY問題

Project Management

最近コミニュケーションに関するいくつかの問題が身近にあって、いろいろと考えたことを書く記事。上司部下間のコミニュケーションの問題には階層があって、いちばん改善すべきなのは部下側ではなく上司側の問題だと思っていることについて。なお、顧客との（もしくは受発注者間の）コミュニケーションの話はまた別。
AIR!

「コミュ力」の問題はだいたい上司の問題説

あくまで主観的なものだけれども、いわゆる「コミュニケーション能力（いわるゆコミュ力）」の問題の多くは実際には上司（情報の受取り手）の問題で、部下（出し手）の問題は小さいと思っている。

最近読んだ本だと「職場の問題地図」がこの問題を非常に明快に示していた(ちなみに同書はとてもおすすめ)。

  • 3丁目 報連相できていない
    • 部下の伝えるスキルが低い
      • 報・連・相のやり方がなっていない
      • 適切なタイミングで報・連・相していない
    • 上司の受け止めるスキルが低い
    • 報連相をする場やルールがない
      • 上司が忙しすぎて、部下が話しかけるタイミングがない
      • 報・連・相のフォーマットがない

職場の問題地図 ?「で，どこから変える？」残業だらけ・休めない働き方

職場の問題地図 ?「で，どこから変える？」残業だらけ・休めない働き方

職場の問題地図 ?「で，どこから変える？」残業だらけ・休めない働き方

「部下の伝えるスキルが低い」と書かれていると部下の問題のようにも読めるけれども、適切な報告の仕方を指導教育していないという意味ではこれも職場や上司の問題である。同書でオススメしている指導フォーマットは次のようなもの。

  • 所用時間を示し相手の都合を確認する
  • まず「報」か「連」か「相」かを伝える
  • 結論を伝える
  • 論点を数で示す（ナンバリング）

「小松課長、いま５分間お時間よろしいですか？ 決算早期化プロジェクトの進め方について、ご相談が２点あります。キックオフの日程と、会場についてです。まず１点目の日程について。日程は延期すべきと思います。なぜなら・・・・」
職場の問題地図 ?「で，どこから変える？」残業だらけ・休めない働き方

こういった情報の受け止め方、どういう形で吸い上げるのかという業務プロセス設計上の問題を無視して、「アイツはコミュニケーション能力が低くて、情報が上がってこないんだよな」などと言ってはいけないという話だと思っている。

部下／メンバーに空気を読ませる時点で負け

報告の仕方というテクニック的な側面もあるとは思うけれど、むしろ問題の根っこには、雑なアサインメントやプロセスの組み立てによって、部下やメンバーに「空気を読ませすぎている」ことだと考えている。もちろん問題にはグラデーションがあって、どこまでやれば正解で、どこからが不備という線引きはできないのだろうが、

  • 責任範囲が不明確
  • 裁量の範囲があいまい
  • やっていいことと、いけないことの線引きがあいまい
  • 上司や組織の意思決定が場当たり的で一貫していない
  • 過去の意思決定の精度が不明なので踏襲していいのか常に不明

などが原因となって、なにをどこまでコミニュケーションすべきか常に空気を読みながらやらなければいけない状況が発生して、非効率やコンフリクトが発生しやすくなるのではないだろうか。

ではどうするか。いろいろ考えてみたのだけれどもまずは空気を読ませないために、個々人の役割を具体的かつ明確にするのが良いかと思っている。たとえばちゃんと職務記述(Job Descriotion)を書けばいいのではないだろうかというのが現時点での個人的な結論だ。

ひょっとしたらうまく対応できている組織や現場も多いのかもしれないが、割と日本企業の多くはこういった形で個々人の職務内容を明確化しないのが一般的じゃないかと思っている。

  • マネジメント側が組織やプロジェクトへのアサイン完了した段階で思考停止しまう
  • 何をすべきかを「考えることからが仕事だ」といってしまう、組織設計不備の責任転嫁

というあたりが根っこにあるのではないだろうか。

つまり、「空気読めよ」という批判はどれも他のフレーズに言い換えることができるわけだ。「空気読め」と言って個人を批判すれば、自分の考えや意向、思っていることを明確に言葉にする必要がないので、話者のコミュニケーションの怠慢とも言えなくはない。自分を含めた“周りの意向”を非常に曖昧な「空気」という言葉で表現し、空気にそぐわない個人へ責任転嫁しているだけの話である。

なぜ「空気読め」が日本人のコミュニケーションをダメにするのか？ 「空気読めない人」に対する海外の反応

ただし、これはあくまで組織内の話でである

というわけで、組織やプロジェクト内部で部下に「空気を読ませる」ことは悪手だと思っている。が、顧客や発注者に対しても同じ論法が通じるかというと、それはまた別の話だろう。「空気を読ませるようなRFPを出す発注者が悪い」と言ってはいけない（もちろん限度はある）。この場合は「空気が読める」ことは付加価値だからである。このあたりはまたどこかで考えてみるつもり。

一流の人は空気を読まない (角川oneテーマ21)

一流の人は空気を読まない (角川oneテーマ21)

日経コンピュータ2017/8/3号特集「変わるITトラブル」を読んだ

Project Management Postmortem

趣味のITトラブルウォッチャー活動として、日経コンピュータ2017/8/3号の特集「変わるITトラブル　実例1096件分析、新事実が明らかに」を読んだ感想。日経コンピュータ創刊の1981年から現在まで「動かないコンピュータ」コーナーなどに掲載された事例を分析したというもの。なお記事には残念ながらデータは掲載されておらず。

突然のシステムダウン、システム刷新プロジェクトの失敗----。
1981年の本誌創刊号から2017年までにわたって「動かないコンピュータ」などに載せたトラブル事例は実に1098件。これらを分析して、トラブル防止につながる知見を得られないか、こう考え、セキュリティ関連、システムダウン、開発失敗というITトラブルの3大リスクを対象に様々な角度から調べてみた。すると、知られざる傾向と対策が見えてきた。

  • 日経コンピュータ2017/8/3号 特集「動かないコンピュータ 変わるITトラブル　実例1096件分析、新事実が明らかに」

なお記事の詳細は同誌を確認いただきたい。

Campfire

三大リスクは本当に「三大リスクなのか？」

最初に気になったのは、この特集で取り上げられた三大リスク（セキュリティ、システムダウン、開発失敗）が本当に重要なものなのかがよく分からなかったというもの。概要でもいいのでデータ全体に触れられていれば良かった。もちろん掲載されているリスクはそれぞれ重要なものではあるが。

三大リスク①セキュリティ編

不具合やハードの故障以外の要因として、サイバー攻撃や脆弱性関係のトラブルが大きなリスクとなりつつあるという分析。記事の中では以下のような分析があって興味深い。

嫌な世の中になったものだ、といっても仕方が無いのだけれども、ユーザの要求に従ってシステムを構築しただけではNGな時代に突入したということだと理解している。また、セキュリティのリスクは常に(攻撃手法等や発見される脆弱性が)変化するので、システム開発時だけではなく運用でもどう刈り取っていくのかよく考えなくてはならない点だ。個別エンジニアのスキルで討ち取るのは困難なので、支援体制がちゃんと整っているかどうかがポイントだと思っている。

しかし、この傾向は別に日本に限った話でもないわけで、そういう意味ではグローバルのトレンドも気になるところだけれども、どこかに整理されているものはないか、別の機会に調べてみようと思っている。

三大リスク②システムダウン編

システムダウンのうち「全面ダウン」の比率が10年代に比率として増加しているという話と、いくつかの最近増加しているトレンドについて整理されている。こちらの章で紹介されている分析は以下の通り

  • システムダウン全体に占める全面ダウンと一部ダウンの割合(年代別) 日経コンピュータ調べ
    • 2000年代で若干全面ダウン比率下がるも、2010年代でまた上がる
  • 全面システムダウンの原因別割合(年代別) 日経コンピュータ調べ
    • ハード起因の比率が微増
  • ハードウェア故障の原因別割合(年代別) 日経コンピュータ調べ
    • サーバーに起因するトラブルが増加
  • 平均ダウン時間の変化(年代別) 日経コンピュータ調べ
    • ダウン時間は増加トレンド

記事を注意して読まないといけないのは、システムダウン自体が増加しているわけではなくて、システムダウンのうち「全面ダウンの比率」が増えているという件。件数自体は2000年代から2010年代は減っている。もちろん、件数としてカウントされているのは日経コンピュータの取材、情報収集の範囲に限定されるので実際にシステムダウンが増えているのか、減っているのかというのはなんとも言えないように思える。

ただ、平均的なシステムの複雑度は以前より上がったのは事実だと思っている。

  • そもそものシステムに対する要求がゼロ年代から難易度アップ
  • システム間の連携も複雑化（というか世の中のシステムが増えた）
  • ゼロ年代に構築されたシステムが再構築を経て魔窟化、もしくは延命されて妖怪化
  • 採用テクノロジーが複雑化、組み合わせが多様化

で、複雑度が上がれば予期せぬ全面ダウンのリスクも増えるわけで、アンチフラジャイルとかレジリエンスなどは今後重要なテーマになっていくような気がしている。

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

反脆弱性[下]――不確実な世界を生き延びる唯一の考え方

反脆弱性[下]――不確実な世界を生き延びる唯一の考え方

三大リスク③開発失敗編

システム開発失敗の主因は要件定義にあるというストーリー。ただ、ここでも注意が必要で、システム開発失敗の件数そのものは減少傾向である。失敗はしにくくなったが、失敗するときには要件定義工程で大コケする、という話と考えたほうがいいと思っている。本章で提示されている分析は以下の通り。

  • 開発失敗の4大要因とその割合(年代別) 日経コンピュータ調べ
    • 2000年代から2010年代について、トップ要因は「ユーザ企業が要件をまとめられず」であるが、2位の「ベンダーが要件を理解できず」が2000年代再開から急浮上している
  • 工期遅延理由の分類 JUAS「ユーザ企業ソフトウェアメトリックス調査2016」より
    • 遅延理由の4割が要件定義関連
  • 開発失敗の事例におけるソフトウェア開発形態別の割合(年代別) 日経コンピュータ調べ
    • パッケージ導入タイプの失敗が大幅に増加
  • 開発失敗により稼動延期期間の割合(年代別)
    • 稼動延期期間は短縮傾向、超リスケは減っている

システム構築の受注者側であるSIベンダ等の開発能力や管理能力の向上の結果、適切な要求オーダーがあればシステムを完成させる能力は向上していると思っている（もちろん色々な課題はある）。ボトルネックが要件定義などのいわゆる上流工程に移っているという理解。発注者・受注者の共同作業である要件定義で、どちらかの能力不足によって「ユーザ企業が要件をまとめられず」または「ベンダーが要求を理解できず」で失敗するというのは当然だろう。

あと記事では言及されていないけれど個人的に気になるのは、システム再構築プロジェクトの増加だと思っている。記事の中では「再構築プロジェクトは大規模・ビックバンになってしまい開発規模の大きさからトラブルになりやすい」といったニュアンスの言及はあるけれども、再構築プロジェクトそのものの難しさ、要求／仕様抽出の困難性や人的要因（「わかる人がもういない」）は失敗トレンドの変化に越境を強く与えているのではないか。まぁ、あくまで感覚論なのだが。

なぜ、システム開発は必ずモメるのか？

なぜ、システム開発は必ずモメるのか？

ポジティブな客先常駐システム開発を考える

Project Management

株式会社アクシアさんのブログで、常駐開発バッシング(?)記事が最近掲載されている(http://axia.co.jp/2017-08-01)ことについて考えている。指摘されているような「不適切な常駐開発」というのは確かにあるのだろうけれども（ちなみにあまり目撃したことはない）、適切に運用すればポジティブな常駐開発も有りえるはずだし、自分は一応そうやってきたと思っている。じゃあ、注意すべきところは何だろうか。

なれる！SE7 目からウロコの？客先常駐術 (電撃文庫)

なれる！SE7 目からウロコの？客先常駐術 (電撃文庫)

何が問題なのか？

常駐や多重請負が問題なのではなくて、請負という形態において受注者が「裁量を持っているか」というのが最大の論点だと思っている。例えば以下のようなもの。

  • 作業プロセスについての裁量（やり方を一定の範囲で自由に決定/変更できる）
  • スケジュールについての裁量（マイルストーンまでの進め方を自由に決定/変更できる）
  • リソースについての裁量（目標達成に必要なリソースを自由に決定/変更できる)

これらが制限された時に批判されるような不適切なプロジェクトになるのではないだろうか。逆に言えば、裁量の範囲について受発注者が事前に合意出来ていれば、ポジティブな常駐開発が実現できるのではないかと考えている。

もちろん多重請負の構造において、特に途中段階の契約会社がポンコツだった場合は裁量を維持するのは相当な努力を要するだろう。「発注者が＊＊と言っているのでその通りにしてください、反論は受け付けません」という契約関係は論外である。もちろん請負側も「すべて指示してください、自分たちでは考えられません、教えてください」というスタンスではいけないのは言うまでもない。

ところで非常駐開発は常駐開発に比べて上記の裁量を得やすいというのは事実だと思う。
ただし、非常駐開発が裁量を得られているのは非常駐開発が優れているからではなく、顧客に対して透明性が無いからにすぎない。

  • 客から見えないから、作業プロセスを変えてもいいだろう
  • 客から見えないから、スケジュールを変えてもバレないだろう
  • 客から見えないから、リソース変更してもOK

はたしてこれが、常駐開発より優れているのかというと疑問である。

ポジティブな客先常駐システム開発

適切な裁量が確保されているのであれば、あとは常駐開発を選択するかはメリット／メリットの比較だと思う。

メリットとして最も大きいのはコミュニケーション効率化である。利害関係者が一箇所に集まって開発に従事することを、「缶詰」（組織パターン）や、「ウォールーム」と呼ぶのだが、このメリットは非常に大きい。またファシリティコストのメリットもあるだろう。

組織パターン

組織パターン

一方でデメリットとしては、最初に紹介したブログ記事にも書かれている通り、顧客の拠点を間借りするためにドレスコードや勤務時間などの制限を受けることはあるだろう（交渉次第だと思うけれど）。また見える場所で作業していることから余計な割り込みの問合せ、コミュニケーションが発生するということもある。

このあたりを冷静に比較して、どのような形態でシステム開発するかは判断すればいい。
というわけで、どちらにしろ常駐開発＝悪というのは、ちょっと違うのではないかと考えたのだった。

Fireタブレットだけでゼロから学ぶDeep Learning

Kindle programmer

ちょっと思うことがあって、Amazon Kindle Fire HD8で「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装」(電子版はAmazonではなくOreillyから購入)を読みつつ、Fireタブレット上にPythonの実行環境を作ってコードの実行までやってみた。出来ないことも多いが、意外と戦える。実質的にFire 7980円＋電子書籍2938円で意外と面白い勉強環境を構築することができる。


Fireタブレットで出来ることと、出来ないこと

Fire HD 8 タブレット (8インチHDディスプレイ) (第7世代) 16GB

Fire HD 8 タブレット (8インチHDディスプレイ) (第7世代) 16GB

  • 発売日: 2017/06/06
  • メディア: エレクトロニクス

先に結論から。

なお今回はFire HD8でやってみたが、他のFireやAndroidタブレットでも同じことができると思う。

どうしてそうなった

  • 家にもデスクトップPCはあるのだけど、家族共用なので長時間占有しにくい事情あり。コドモがマイクラやり始めたので状況悪化！
  • 社用のノートPCもあるけど環境を汚したくない。
  • クラウドに学習環境を構築してタブレットから接続することも考えてたが、ローカルで戦えることがわかったので試してみたら意外と出来た！

FireでPython実行環境構築

  • 実施環境はKindle Fire HD 8(第7世代)+FireOS 5.4
  • termuxというandroidアプリをインストールしてlinux環境を構築、Python及び必要なライブラリをセットアップ、Jupyter Nootebookまで導入する

$ packages install clang python python-dev fftw libzmq libzmq-dev freetype freetype-dev libpng libpng-dev pkg-config git
$ LDFLAGS=" -lm -lcompiler_rt" pip install numpy==1.12.0 matplotlib pandas jupyter

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

  • 作者:斎藤 康毅
  • 発売日: 2016/09/24
  • メディア: 単行本（ソフトカバー）

$ git clone https://github.com/oreilly-japan/deep-learning-from-scratch.git

  • Jupyter notebook起動

$ jupyter notebook

うまくいかない事

  • 冒頭にも書いたけれど、Jupyterから計算量の多いバッチ処理を実行すると termux自体が死んでしまう。具体的には第4章にあニューラルネットワークのバッチ学習処理のサンプルコード「train_neuralnet.py」はJupyterからは実行できなかった
    • おそらく原因はJupyterからの非同期コード実行プロセスにある印象。ipythonから実行すると物凄い遅いが、誤差逆伝播法の処理は実行できる。
  • まぁ、こいつはあくまでおもちゃの類なので、ちゃんとしたスペックの環境を別途構築しようかとは思っている(とりあえずCloud9に環境を建てて試し始めているところ)

スクリーンショット

具体的にはこのような感じになる。動く、動くよ！
f:id:kent4989:20170704225237p:plain:w200f:id:kent4989:20170704225249p:plain:w200f:id:kent4989:20170704225259p:plain:w200