【勉強会メモ】カイゼン・ジャーニー ／ たった1人からはじめて、「越境」するチームをつくるまで (発刊イベント)
- 日時：2018-03-12（月）19:30 - 21:30
- 場所：TIS株式会社 大阪本社
著者のおふたりによる発刊イベントに行ってきました。以降のメモを読んでいただければわかりますが、予想通りおふたりの想いのこもったアツい内容でした。
カイゼン・ジャーニーは現場を変えたいと考えているエンジニアがひとりからでも現場を改善していくのを支えるための、カイゼンの旅のガイド本です。それと同時に著者のおふたりにとってはこの本の執筆活動自体がエンジニアの現場に向けたカイゼンの旅でもあると感じました。
市谷さんの説明にもありますが、この本の想定読者は仕事の経験が浅い人ということなので、ある程度経験を積んでスクラムも経験している私はメインの読者層ではないかもしれません。しかし、現場を変えたいカイゼンしたいという思いは同じで、今回のイベントもとても共感出来る内容だったので、もしも孤軍奮闘している若者に出会ったらこの本を薦めたいと感じました。ただ、その若者に胸を張って「あなたは何者なのか？」と言えるような人間になるためには、自分自身もまだまだカイゼンの旅を続けていく必要があると感じたイベントでもありました。
書籍『カイゼン・ジャーニー』について
市谷さん
インセプションデッキで説明
なぜわれわれはここにいるのか？
現場、仕事場を変えていく人たちに寄り添う存在をつくりたい
- 自分たちの状況を変えるというのは一人で始める事が多い
- 周りの巻き込みを助ける本
エレベータピッチ
- まだ周りを巻き込めていない状況で
- チームでの仕事のやり方をより良くしたい
- チームの外側にいる人も上手く巻き込みたい
仕事の経験がまだ浅い人たちを想定読者とした
⇒変化の旅に向けたガイドブック
「ストーリー」と「解説」
- 解説：仕事に必要なプラクティスの理解
- ストーリー：導入のための背景、前提、応用の理解⇒ストーリーの追体験
3部作
- ひとり→チーム→チームを超える
- 理解の段階的な積み上げ
- 自分の状況にあわせた読み方ができる
ストーリー
- 著者の体験をベースとしている
- 現実感と実践レベルの知識
パッケージデザイン
Ver.1→ドラクエっぽい→変更
ご近所さんを探せ
やらないことリスト
- コンフリクトを恐れる
- 著者や編集さんとの衝突を恐れない
- 尊敬と信頼をもって衝突する
- 妥協
- 世の中に出す→誠実に取り組む
技術的な解決策
- 自分から缶詰合宿
- 月1,2回
- 寝ない
- 夜の時間を使う、徹夜数回
- レビューはユーザーテスト
- 読む、ひたすら読む
- テストコードやCIがない
- バグの検知が人力
- 「ざらざら」を「つるつる」にする
- 名分をかけるわけではない→下手くそは時間をかけるしかない
トレードオフスライダー
Q>D>S>C
- Q（品質）…つるつるになるまで
- D（納期）…締切
- S（範囲）…1章分追加、付録追加
- C（費用）…合宿、イラスト
夜も眠れない問題
- 3回挫折→できるのか？
- 最初の構想は2014年
- 会社の立ち上げと重なってギブアップ2回
- 自分でやるしかない
- やれない理由はいくらでもある
⇒だからこそバディはかけがえが無い
期間をみきわめる
- 構想から数えると4年
- 実質的に書いたのは4ヶ月
何がどれだけ必要か
ありったけのパッション
How To Read カイゼン・ジャーニー
新井さん
遡ること2015年
2015年9〜1月
- 第1部がだいたいできあがる
- 起承転結・ストーリー・まとめ
- 片鱗はあるが今の役に立った？
2016年1月
- 旬がなくなったテーマだった
- モチベーションなくなり
- 全文章が没
- 編集者にお詫び
2017年秋
- 8月に声をかけられ
- 10月初旬…殴り書き
- 11月初旬…校了予定
- 11月中旬…追加（付録など）
- 1月中旬まで悪あがき
どうやって書いたか
- 一気に書く
- 確認・遂行
- 読者に押し付けの著者のエゴはないか
1週間合計45時間⇒マネしない方が良い
- 平日
- 朝2時間
- 日中は会社業務
- 夜3時間
- 土日は全部執筆
- 土日10時間
12/23だけ脳みそを完全停止
- 国語力…天才10分、凡人2時間
- エンジニアリング要素必要
- チームビルディング
- コミュニケーションなど
- 合宿から合宿のはしご
- 神奈川、東京、千葉
How To Read
ひとりでも始める
- タスクマネジメント、タスクボード、朝会、ふりかえり
- この4つから始めるのがよい
- まずやってみる
チーム
- 問題ありません問題
- メリハリがない
- ファイブフィンガーを使おう
- 足りない指は何が原因か聞いてみる
- マンネリ化を避ける
- がんばりすぎるのも良くない
チームで強くなる
- 新しいメンバーが入ってくる時
- モブプログラミング
- メンバーの成長とチームの成長
- 一体感
- 全員が犯人であり全員がヒーロー
5つの価値
- 越境
- 自分から始める
- フィードバック
- リフレーミング
- 巻き込み巻き込まれる
Why #1
- 変化の兆しを感じた時に機会を逃すか？
- 疲れるし大変だし
- 自らの足で同じバスに乗り込もう
- 大義・信頼
- 感謝
- ぼっちでもできること
- 自らの意思で何かをやろうと決めた時にその波紋が何かを呼ぶ
Why #2
- 自分の定義を変えてみる
- 会社で初のパターン
- 書籍を書く、副業
- 起業や執筆で定義が変わる経験
- 管理職→残業の定義が変わる
- 副業→労働の定義が変わる
- 会社起業→時間の定義が変わる
- 自分から始めフレームを変える
- 社内外の共感する仲間を作る
- 巻き込み巻き込まれていく
- 気がついたら越境している
- 5つの価値がサイクルする（境目がない）
- 越境、自分から始める、フィードバック、リフレーミング、巻き込み巻き込まれる
- 孤軍奮闘している相棒に
あとがきにかえて
われわれはなぜここにいるのか？
- 問いに答えられないことはある
- 答えられないことが重たくなってどうしても向き合わなければならないことがある
大切なのは答えではなくて問い
- 答えは状況や受け取り方によって変わる
- 問いが良い状況を生む
「あなたは何者なのか」という問い
- 人を立ち返らせるほどの問いは貴重
- 良い問いを得るということはとても貴重なこと
生きるとは、問いを作り続けること
立ち返りの問いは？
- いろんな物語に触れて自分の物語を紡ごう
- 問いは人の生きざまのなかに現れる
補足
サポートサイト
書籍で紹介したスライドのリンクやイラストなど
クラウドエナジャイズ
越境を応援する
【読書メモ】カイゼン・ジャーニー
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/15
- メディア: Kindle版
- この商品を含むブログを見る
DevLove関西の発刊イベント に参加する予定なのでそれまでに読もうと思いつつ結局前日までかかってしまいました。
『カイゼン・ジャーニー』は開発の現場をより良くしていくためのカイゼンのプラクティスを架空の物語をベースに紹介していく改善の旅の話です。物語は一人から始めて、チームで強くなり、みんなを巻き込むという3部構成で展開します。
物語とともに紹介される改善プラクティス
著者の1人である 市谷さんのブログ によるとそのプラクティスは全部で61個あるそうです。これらのプラクティスはどれも一般によく知られたもので、内容は解りやすく魅力的ではあるものの、実際にやってみようとするとなかなかうまくいかないことも多いものです。スクラムもそうですが、これらのプラクティスは定義は解りやすく理解は容易ですが、適用は各自の裁量に委ねられており各現場の事情に合わせて取り入れる必要があるためうまく活用するのは簡単ではありません。そのためこの本ではプラクティスを物語の一部に組み込んで適用の一例として紹介することで、定義を理解するだけで終わらせないように工夫されているのだと思われます。
スクラム開発と改善プラクティス
本書で紹介されている改善のプラクティスはスクラム開発がベースになっていますが、スクラム開発でなければ取り入れられないわけではありません。朝会やふりかえりをはじめとして、従来の開発プロセスでも取り入れられるものはたくさんあります。もちろん、技術が多様化し複雑さの増す開発の現場でスクラム開発は重要な改善プラクティスの1つとも言えます。しかしスクラムを取り入れてもそれだけで現場が大きく改善するわけではなく、他の様々な改善プラクティスを取り入れて前進させる必要があると感じました。
改善のための越境
物語の終盤部分を読んで私は不覚にも泣いてしまいました。ネタバレになるので詳しくは触れませんが、この本で度々語られる「越境」は改善のための重要な手段ですが、改善の究極の価値は越境することで得られるのではなく越境によって自分が救われることなんだろうと感じた瞬間でした。
スクラムマスターと改善
ところで、1つだけ欲を言うと物語の中でもっとスクラムマスターを巻き込んで欲しかったなと思いました。もちろん、究極的にはスクラムマスターがいなくても自ら改善を進められるチームが理想ではありますが、技術が多様化し複雑さの増す現代の開発の現場においてスクラムマスターと開発チームが協力して現場を前進させていくことは不可欠ではないかと思っています。スクラムマスター1年生としての偏見にまみれた個人的な感想です。
改善プラクティス
最後に、個人／チーム／チーム外の3部それぞれで紹介された改善のプラクティスを箇条書きでピックアップしておきます。これらをどうやって現場に取り入れるのか、興味があれば是非一読をおすすめします。プラクティスの中で実践していないものがあるならば、それはまだ改善の旅が途中ということなのかもしれません。
なお、文中では「インセプションデッキのアップデート」のようなプラクティスもありましたが、プラクティス名をキーワードとして紹介したいだけなのでここでは省きました（なので数えても61個はありません）。
一人から始める
- タスクボード
- 朝会
- ふりかえり
- 1 on 1
- XP
チームで強くなる
- スクラム
- スプリントプランニング
- プロダクトバックログ
- スプリントレビュー
- スプリントリファインメント
- インセプションデッキ
- Working Agreement
- 成功循環モデル
- 期待マネジメント
- ドラッカー風エクササイズ
- ファイブフィンガー
- 狩野モデル
- むきなおり
- 合宿
- 星取表
- モブプログラミング
- バリューストリームマッピング
- ECRS
- カンバン
- ポストモーテム
- 感謝のアクティビティ
みんなを巻き込む
【勉強会メモ】React Beer Bash!
- 日時：2018/03/07(水) 19:00 〜 21:00
- 場所：さくらインターネット本社 オープンエリア
大阪でもReactを盛り上げようという勉強会です。初開催ということもあり基礎知識的な話や別のコミュニティやサービスの事例紹介などもあってボリューム的には多かったのですが、メモを残したのは技術的なテーマだけだったので他のテーマは割愛します。
Reactの案件で感じた成功と反省
Gemcook 前田さん
Reactの実例紹介
名簿管理サービス
- グラフ
- メール送信
- 検索機能
- 地図と連動
ディレクトリ構成
- Reduxの構成要素
- actions
- containers
- reducers
- 部品
- components⇒共通コンポーネント
- route.jsx⇒ルーティング
- その他
- settings⇒アプリの設定
- stylesheets⇒css
- utils⇒共通関数
サロン商品発注
- 受発注
- CSV
ディレクトリ構成
- Reduxの構成要素
- actions
- containers
- models
- reducers
- 部品
- components⇒共通コンポーネント
- route.jsx⇒ルーティング
- その他
- config
- styles⇒css
- utils⇒共通関数
⇒ActionからModelを分離
- Redux Actionsを使うことでActionのコードが減る
- 学習コストは上がる
※メモ qiita.com
ライブラリ
- Semantic UI React ⇒シンプルなUI
- Recharts ⇒グラフ
- Reapop ⇒通知
- Redux Form⇒Form関連（フォームの作成、バリデーションなど）
- react-bootstrap-table ⇒Bootstrap式のデータテーブル
成功と失敗
- ページ、コンポーネント単位での分割した作業ができる
- 既存ライブラリを探しておくほうがいい
- Reactのバージョンアップによるライブラリの仕様変更についていくのが大変
- 日々ベストプラクティスが変わるので毎日調査が必要
React x Fluxで脱jQueryコード
ねっこ さん
背景
React × Flux
Flux
※メモ
Flux Utilsの利用
注意点
- 単一方向データフローを基本は遵守する
- Fluxは二重にDispacheできない
- どうしても行う場合はsetTimeoutを0秒に設定してDispacheする
- アニメーションが絡んでくると期待通りの動きにならない
- 必要な場合はレンダリングを発生させずにステータスの更新を行う
- レンダリングチューニングのためのshoundComponentUpdateメソッドは必ずデフォルトにしない
- keyに気をつける…ReactがViewを管理するために重要
脱jQuery
どう共存するか？
- 状態管理を処理しないアニメーション⇒jQueryにやらせる
- 順次表示するだけはOK
- 5件まで表示してボタンを押すと6件目以降を表示する場合などは状態管理が必要なのでNG
React
- jQueryを使うから意識することはない
ReactでDecoratorを使う
平野 さん
Decoratorsとは
- EcmaScriptドラフトの機能
- 処理の追加や置き換え
@マークを付ける- Javaのアノテーションのような記述
例）プロパティの追加
@name("React")
- nameのプロパティが追加される
Decoratorsの使い方
Decoratorsの事例
- react-redux
@connectで簡潔に書ける
- Mobx
- stateを管理
@observalbeでobservableにしてくれる
- react-log-decorator
@logでpropsとstateの引数をconsoleログに出す
- pure-deep-equal
shouldComponentUpdateの中でdeep compare- 参照：SPAをパフォーマンス・チューニングした話 // Speaker Deck
まとめ
- コードが簡潔になる
- アスペクト指向的に使う
- まだ提案中なので自己責任で
【勉強会メモ】Osaka Venture Today Meetup #3 - テスト自動化
- 日時：2018/03/05(月) 19:00 〜 21:00
- 場所：サイボウズ株式会社 大阪オフィス
大阪のベンチャー企業でエンジニア界隈を盛り上げようという趣旨で開催されている勉強会で別名Oventoとのこと。過去2回は参加できなかったので今回が初めての参加でした。テーマは テスト自動化 ということで各社様々な工夫をされていてとても参考になりました。ユニットテストとかE2Eテストとかはもはや当たり前で、性能系、セキュリティ系も自動化が進み、複雑なドメインのキャッチアップのために社労士さんにデータをインプットしてもらう工夫なども行われているようでした。そしてどの会社もまだまだ課題はある、やりたいことがあると言われていたのも印象的で、知恵と技術を駆使して粘り強く取り組んでいるからこそ、ここまでの自動化ができているのだろうと感じました。
kintoneをとりまく自動テストと新しい仲間を追加した話
鈴木 亜耶さん
www.slideshare.net
kintoneの自動テスト
kintoneのリリース
- 1ヶ月1回のリリース
- 開発期間＋試験期間
- 開発はスクラムで実行
- 社内はタスクごとにデリバリ
- 社外へは1ヶ月単位にリリース
自動テストのタイミング
- GitHub Flowで開発
- ローカルからリモートのtopicブランチへPush⇒devlopにマージ
- topicブランチへのPushとdevelopのマージで自動テスト
- 手動でも実行可能
- Jenkinsのジョブをパイプライン化
- テストが通らないとマージ不可
- カバレッジ：74〜88
自動テストの種類
その他
- 静的コード解析
- コードフォーマットチェック
APIテスト
ブラウザテスト
APIパフォーマンステスト
APIテストを性能検証に転用
従来の性能検証
- QAが主に性能検証（必須）
- 試験期間に実施する
- 開発期間中に個々のタスクごとに性能検証することもある
負荷テスト
- Scale Bench…独自ライブラリ
- ユーザー操作がシナリオ＝ブラウザテストに近い
⇒より狭い範囲で開発期間にできる性能検証がほしい（APIごとに叩くなど）
API単位で性能検証
- not負荷テスト but パフォーマンステスト
- レスポンスタイムを見る
- 毎日まわせる
⇒遅くなっているAPIがあったらJenkinsがチャットへ通知
苦労したこと・工夫
環境面
測定方法
- テストを並列実行しない
- ひとつのAPIで数十〜数百回測定
- inputはバラす（キャッシュに乗るのを避ける）
- 中央値で集計…外れ値につよい（平均だと外れ値があるとブレる）
性能劣化の検知ロジック
- 当初：どのAPIも過去の中央値よりN％遅かったら通知
- 中央値が小さいほど外れやすくなる
- Kenkins先生が毎日怒っている
- 改善：APIごとにしきい値を設定
- 今までの実施値より決定
- ⇒その日だけ偶然遅かったというのがまあまあある
- 現在：3日連続で遅かったら通知
メモ
Q）パフォーマンステストにかかる時間
- 5時間
- 従来は数日かかっていた
株式会社ロックオン自動テストへの道
奥 清隆さん
E2Eテスト
脆弱性検査
www.slideshare.net
隣のとあるプロジェクト
- CIやりたい
- テストは昔書いてた
CIサーバを立てる
- Jenkinsを採用
- Jenkinsfileをローカルで実行できるツール
- 編集したあとでいちいちリモートのJenkinsで事項しなくても良い
Docker
- 開発環境/CI環境/ステージング/本番をコンテナ化
JenkinsfileとDockerfile
- ローカルでも試せる
- 他のプロジェクトへも展開しやすい
増えないテストコード
- レガシーなコードはテスタビリティが低い
- 動いているコードに手を加えたくない
- 教科書通りには進まない
- でもやる気はある
- 毎週決まった時間を確保して改善中
参考：Paypalの事例
⇒デリバリーまでのリードタイム
- 1ヶ月⇒最初の頃
- 1日⇒現在
- 5分⇒将来
メモ
Q）VAddyの効果について
- 脆弱性が見つかったことはない
- 手軽に使える
- 日々チェックされていることの安心感
複雑なドメインと自動テスト
増原 賢秀さん
人事労務freee
- 書類がPDFで出力
- リスク
- 社員が入社日にいないとやばい
- PDF書類が出力されないとまずい
給与明細・賞与明細
- 従業員はモバイルアプリでも確認
- リスク
- 給与計算が正しく行われまい
- 権限まわりがデグレするとヤバイ
- （他人の給与が見れる、管理者と同じ物が見える）
勤怠管理・勤怠打刻
- モバイルアプリから打刻可能
- リスク
- 打刻データが勤怠データに入らない
他
- 書類出力機能
- 会計freeeと連携機能
- マイナンバーfreee
自動テストの紹介
デプロイフロー
- PRコミット
- Circle CIでまわる
- RubocopやEsLintなど静的解析
- Stagingにデプロイ
- E2Eテスト実行
- PR単位
APIテスト
- PR単位
Integration
- ユースケースの正しさ
- PR単位で実行
- ドメインのキャッチアップとしてまずここから書く
- inputとoutputをCSVでマスタデータ化
- テストコードを書けない社労士さんも確認、修正が可能
- エンジニアはドメイン部分の正しさが担保できる
ブラウザを使ったE2E
E2Eテストが活きること
- フロントエンド周りのアーキテクチャ変更の対応漏れ検知
- サインアップや課金給与計算等のサービスとしてクリティカルな部分のデグレ
- お客様の業務が止まらない
- 課金部分（テストが難しい）
- サービス間連携のデグレ
- freee外の部分の動作確認
課題
Integration
E2E
- ステージングに上げて初めて不具合がわかる
- デプロイは1日1回
- 16並列で全部通るのが10分
- 課金ツールの検証環境が突然メンテ
- e-Gov （電子政府の総合窓口）が突然メンテに入る
- マルチブラウザ対応
- コードのメンテがQAだけ
- プロダクトコードと別リポジトリ
- PDF書類のデグレチェックが無い
最近の取り組み
webdriver.ioへの移行中
- Node.jsのE2E
- PageObject
- デフォルトで並列実行
- 公式ドキュメントが豊富
- VISUAL REGRESSION SERVICEによる画像diff
QAチームの発信
- テスト勉強会を3ヶ月実施中
- テストに関する用語を開発者と認識合わせ
- scrapbox でテストがよく落ちる箇所を共有
- Slack通知
【勉強会メモ】PyData Osaka Meetup #9
- 日時：2018/02/28(水) 18:30 〜 21:00
- 場所：ヤフー株式会社 大阪グランフロントオフィス
データサイエンス関連のコミュニティで久々の開催とのことでしたが、個人的には初参加でした。専門分野ではないので前提知識が少ない状態で参加してしまいましたが、この分野はITサービスとしても欠かせない領域になってきておりデータを連携する側としても切り離せないものとして知識を深めたいと考えています。
今回のテーマは「PyDataツールの最新情報」とのことですが、Notebook系のツールやサービスはクラウドも絡めて広範囲に浸透しており、ここ1,2年でかなり充実していきている印象があります。また、Apache Arrowは今後使うケースが増えそうで特に期待値の高いツールだと感じましたが、データ連携という意味ではWeb側にとっても重要なツールなので本当に切り離せないものとして把握しておくべきと感じました。
最近のPySparkとPydata
玉川竜司さん（ @tamagawa_ryuji ）
O'Reilly本の翻訳者さん
ヘルシープログラマ
ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack
- 作者: Joe Kutner,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/07/23
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
長く健康に開発をするための本
SREサイトリライアビリティエンジニアリング
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
入門PySpark
入門 PySpark ―PythonとJupyterで活用するSpark 2エコシステム
- 作者: Tomasz Drabas,Denny Lee,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/11/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
Qiitaでも海外のブログ等を翻訳して公開
データサイエンスとデータエンジニアリング
- データサイエンス…数学の世界
- データエンジニアリング…デバイス、メモリ、CPU、コードなど
分散処理って必要ですか？
やらなくてすむならやらないほうがいい
- ちゃんと使えばパフォーマンスは上がる
- 落とし穴はたくさんある
- サイエンス系は落とし穴をあまり意識しない
- 落とし穴は縮小傾向にはある
ハードウェアの変化
- メモリの低価格化
- SSDの普及と大容量化
- CPUのコア数の増大
- ネットワークの高速化
⇒大々的に分散処理するまでもないケースが増加
分散処理の難しさ
参考：「みんなが知っているべき数値 by Jeff Dean」P.4
www.slideshare.net
- ZIP圧縮⇒時間かからない
- HDDシークやNW経由のデータ通信⇒時間かかる
分散処理で問題になること
- 気楽にやった操作が重くなることが多い
- 非分散の場合メモリに乗っかってしまえばあまり考えないで良い
クラウドサービスは便利
Sparkへの移行が進む
- 新規開発でHadoopを使う理由はなくなってきている
Sparkの使いどころ
- メモリに収まるサイズならPyDataのツール群が有効（Pandasなど）
- オンメモリに収まらないサイズならSparkが有効
- 小規模のデータでも小回りがきく
- Hadoopは違う（大きいサイズだけ）
※注意：Spark 1.2まではPySparkはめちゃくちゃ遅い
なのでPySparkではDataFrameを使いましょう
速度が遅くなる理由
- RDD API
- DriverがStorageから読み取ってデータを処理する際にPythonVMを使う（PythonVMにデータが流れる）
- DataFram
- UDFを使うとPythn VMにデータが流れるので注意
- Spark 2.3からVectorized UDFがサポート
- Pandas UDFは早くなる
ファイルベースはParquetがオススメ
⇒分散フアイルシステムがなくても事足りるケースも多い
Parquetの特徴
インメモリのデータ変換の問題
- pandas⇒Sparkはかなり遅かった
- 2.2からArrowに対応して早くなった
Apache Arrow
- インメモリ列指向データフォーマット
- 無駄なデータコピー変換をすることなくツール間でデータをやり取り
参考：Arrowについての翻訳
SciPyの概要と各モジュール紹介
大橋宏正さん（ @wrist ）
SciPyとは
- NumPyの上に作られた数学的なアルゴリズムや便利なサブモジュール
- SciPy 1.0⇒2017/10/25にリリース
- 最初のリリース2001年⇒16年（ 「SciPy 1.0」リリース、最初のリリースから16年 | OSDN Magazine ）
なぜ1.0か？
- プロダクション環境で使われるほどに成熟し安定したこと
- 技術的な目標と組織的な目標の両方を達成
SciPyを学ぶ際のリソース
https://www.scipy-lectures.org/
1.5. Scipy: 高水準の科学技術計算 — Scipy lecture notes
Azure Notebookを使ってデモしながら解説
scipy.io
- matlabの代わりに使える
scipy.special
- 特殊関数が含まれる
- cythonバインディングも存在
scipy.linalg
- 線形代数関連の操作
numpyとの違い
scipy.fftpack
- 高速フーリエ変換、離散コサイン変数
- 周波数を取る
scipy.interpolate
- 曲線の補間
- 補間関数の生成
- 補間値の算出
scipy.signal
- 信号処理
- フィルタ設計・フィルタリング
- 畳み込み・時間相関計算
- 窓関数
- ホワイトノイズに対するローパスフィルタの適用
参考
scipy.optimize
- 各種最適化アルゴリズム
- 曲線フィッティング
- 最小値を見つける
scipy.stat
- 統計や確率分布
- 統計的検定
scipy.spatial
- 空間データや距離を扱うためのモジュール
- 距離行列を計算
scipy.misc
- face…アライグマが描画できる
おまけのデモ
fftpackとsignalで音の信号処理
⇒ベースの音だけ抽出
Jupyter とコラボレーション
入江敦央さん
大規模ではない数人程度のチームでデータ分析を含むコラボレーションをJupyterベースで進める際に地味だけど起こりがちな問題を防止する
JupyterConからピックアップして紹介
コラボレーションを阻害する要因
共同作業を問題なく進めるための共通基盤がない⇒ここにフォーカス
架空ケース：レコメンドAPIの企画
データの交換
前処理はつらい
- Apache Arrowを使う
Python同士での交換
- バージョン違いでimportエラー
- 通知計算の結果の扱いが変わる事がある
バージョン情報を記述
- version_information
- watermark
環境をコピー
- pip+requirements.txt
- conda+environments.yml
- Anaconda Project+anaconda-project.yml
環境インストールだけでなく環境変数設定やサービスプロセスの開始なども面倒みてくれる
- JupyterHubによる中央管理
- 参照： Zero to JupyterHubのチュートリアル
Notebook系サービスを使う
- 小規模なら
非プログラマーへの配慮
NotebookをHTML出力して配布
- インタラクティブなHTML
- Plotly やJavaScriptベースのプロット用ライブラリ
- nteract …ipynbファイルのビュワー
- 閲覧とテキスト編集レベルは可能
インタラクティブなNotebook
簡易なダッシュボードサーバ
⇒より深い洞察を得られる
分析ストーリーの共有化
- 分析内容を図と文章で説明
- コード実行だけが延々と続いているのはツライ
- グラフだけもつらい
- notebookはストーリーテリングツール
- 分析ツールとして使うだけでなく物語る
変更管理
システム担当との共闘
- 製品デプロイまで面倒をみる
- Notebookから定番クラウドへモデルデプロイ
