エンジニアリング組織論への招待を読んで 〜歴史と技術と組織論〜

TL;DR

  • エンジニアリング組織論への招待を読んで、最高だったので、おすすめする記事です
  • 最高になっているので、エモめ
  • 歴史はいいぞ
  • エンジニアリング組織論への招待はいいぞ

始めに

出た当初、結構話題になり、知っている方も多いと思いますが、エンジニアリング組織論への招待を読みました。

gihyo.jp

内容があまりにも好物だったので、技術評論社に誤字脱字訂正まで送ってしまった。

何がよかったのか、内容をかいつまみながら説明していこうかと思います。

内容

5章立てとなっており、目次は以下の通りです。

Chapter1から順に、個人の思考 -> 1対1の関係 -> 1対多（チーム）の関係 -> プロダクトとチームとの関係 -> アーキテクチャと組織の関係という風に説明されていきます。 詳細は読んでください。

何が良かったのか

一言で言えば、歴史的背景の解説を丁寧にしてくれている点です。 例えば、昨今、流行りのアジャイルについてその思想的背景から説明してくれている本はなかなかないと思います。 アジャイルという思想の源流を辿れば、そこには世界に冠たるトヨタのかんばん方式があり、さらにその後ろにはデミング博士の開発した馴染み深いPDCAサイクルがいます。 そして、その隣には戦後から続くベトナム戦争で疲弊したアメリカ国内での思想潮流の変化と東洋文化の融合がいるわけです。 ジョブズが東洋思想に傾倒していたのはそれなりに有名ですし、シリコンバレーがカリフォルニアにあることもちょっと世界地図を見れば分かりますが、この2つに関係があるとはまったくもって知りませんでした。 まったく関係なさそうに見える事柄でも、意外な関係にあるものはそれこそ無限にあります。 それを紐解いていける手がかりの1つが歴史だと思います。 きっと、要素分解的な思想を持つ西洋文明の裏には、第一次世界大戦がいますし、産業革命がいますし、ルネサンスもいます。一方で東洋文化の裏には、明治維新がいますし、清帝国がいますし、インドや東南アジア諸国も関係してくるでしょう。 このダイナミクスに心がウキウキしてしまいませんか？　　今まさに、そういう世界に生きていると思うとちょっと楽しくなってきます。

少し脇道にそれると、私は大学で経営学をやり、高校では世界史と日本史がやりたいから文系（もちろん、数学・理科が苦手だったのもある）に行ったタイプの人間です。 なので、一見関係ないけれども、歴史を振り返ると実は関係があるものが大好物なのです。

本書は、コンピューターサイエンスがめちゃくちゃ好きでコードを書いているタイプの人には刺さらないと思います。 ある程度、経済学・経営学を学んだことがあって戦後の経営学の流れが分かっていると一層面白いと思います。 もっと言えば、戦後のアメリカ史も軽く学んでおいたほうが面白いと思います。

組織とアーキテクチャについて

コンウェイの法則は圧倒的に正しい。 業務でフロントエンドがメインで、マイクロサービスの話がアツいので興味があったりするんですが、これも組織構造の話と切っても切り離せないなあと思うことしきりです。 興味ある人は以下をどうぞ。 www.atmarkit.co.jp

歴史について

何かについて深く知りたいってなったときに歴史に当たるのは結構重要だと思います。

最近だと、Real World HTTPもHTTPの発展の歴史を織り交ぜつつ、コードとロジックで実践するタイプの本になってて、めっちゃ良かったです。

www.oreilly.co.jp

1年どころか1ヶ月1週間で劇的に状況が変化していく今だからこそ、歴史に当たるというのも大事なことだと思います。 Libraryの歴史とか、言語の歴史とか。

最後に

エンジニアリング組織論はいいぞ。

P.S.

著者さんのTwitterのbioに『「エンジニアリング組織論への招待」というタイトルの本を書きました。控えめに言って名著です。』って書いてあって笑いました。 悔しいですが、控えめに言って名著です。

twitter.com

DevFest 2018 Tokyoに参加してきた話

TL;DR

DevFest 2018 Tokyoに参加してきたけど、すべてのセッションを聞くことは分身するか時間遡行しないと無理だったのでレポートだよ！ 他の人も書いてくれると私が他のセッションに参加した気になれて幸せなので、書いて欲しいっす。

tokyo2018.gdgjapan.org

参加したセッション

技術領域 セッションタイトル
Web 仮）実践！！Web パフォーマンス改善！
Web PWAのイマ
ML Google AIY Vision kitで遊ぼう　～麻雀牌のリアルタイム識別
Flutter FLutterとの1年
Firebase Realtime Database for high traffic production application
Web TypeScript導入で得られる「変えていく勇気」
Firebase Firebase Realtime Database in Production

Webばっかりに偏るかと思ったら、意外とバランスがいい感じになりました。

セッション詳細

仮）実践！！Web パフォーマンス改善！

基本情報

内容メモ

  • ライブコーディングをしながら、自作したウェブサイトのパフォーマンスを改善していくというセッション。
  • 作成した釣りのブログでまず、Lighthouseで現状分析 -> 18点
  • ひたすら改善
    • リソースのサイズを圧縮（gzip化 / コードのminify）
    • 使ってないCSS/JSを送らないようにする（Code splitting / Dynamic import ）
    • 画像の最適化（tool入れる / CDN活用 / Lazy Load）
    • リソースの取得順を調整（Resource Hintsでpreconnect / font-displayでフォント戦略の設定）
  • 最終的にはLighthouseで99点
  • パフォーマンスの改善は1つ改善して、auditsするの繰り返し
  • JSはDownload -> Parse -> Compile -> Executeの4段階を持つので、コストが高い
  • 高速なJSは4つのすべてで速い
  • Page Load時に見えるところを最優先して、地道に減らしていく
  • ほとんど同じ話がWeb performance made easy (Google I/O '18) - YouTubeで見れる

感想

  • devtools、めっちゃ便利
  • Webパフォーマンス改善のやっていきが高まった
  • ライブコーディングで改善前と改善後の差が一目瞭然で、分かりやすかった
  • ライブコーディング用のCheatsheetの用意めっちゃ大事

リンク

www.youtube.com

PWAのイマ

基本情報

内容メモ

  • PWAの魅力の1つは、UXがよくなること
  • PWAはNativeアプリをインストールするほどにはロイヤリティが高くない人にもアプローチできる手段
  • PWAはだいたい2つの技術でできている
    • Service Worker
    • Web App Manifest
  • SafariのPWAはかなり渋い
  • GitHub - Polymer/pwa-starter-kit: Starter templates for building PWAs.でPWA with Polymerができるし、PWAに限らないhelper関数を提供してくれる
  • PWAがGoogle DevelopersのWeb Fundamentalsにあるように、Webアプリの必須項目になりつつある
  • 世界的に見れば、Android優勢な国ほどPWAの成功事例が上がってきている（Ex. スタバ、航空会社）
  • 日本はApple次第かも
  • PWAは完全にNativeアプリを置き換えるものではない、あくまで別物
  • ページロードのタイミングで通知の許可を取りに行くのはアンチパターンオブアンチパターンなので、絶対にやらないこと
    • アプリでは、起動時に許可を求めるので、それと同じにしがちなウェブサイトがかなり多い
    • 1度、拒否されると現状では2度とアプリから通知の許可を求めるバナーを出すことができない
    • PWAはロイヤリティの低いユーザー向けなので、ストーリー設計がより重要になる

感想

  • iOS SafariのPWA対応が想像以上に渋くて驚いた
  • 世界的に見ると、PWAじゃないの？マジ？みたいな世界線になりつつあるのすごい

リンク

Google AIY Vision kitで遊ぼう　～麻雀牌のリアルタイム識別

基本情報

  • Presenter: RIo Kurihara
  • 資料：後日公開

内容メモ

  • 麻雀が好きだけど、符計算ができない -> 物体検出で符計算させるアプリを作ろう
  • 先輩の協力でイケてる学習モデルができた
  • 東北大学の学生チームとか、KDDIによる麻雀アプリがリリースされて焦る
  • LINE Botの開発をしたが、若干もっさり...
  • Google AIY Version Kit（スマートカメラ自作キット）でやろう
  • 実演デモ
    • 速度は改善したが、学習モデルの制約で精度は低い
  • 今後の展望

感想

  • ものづくりしてて、めっちゃ良い発表だった
  • エッジ・モバイルデバイス上でMLを動かすニーズが高まってきてる -> TensorFlow.jsのとかに繋がってきてるのだろうか
  • 実演デモで「3筒」とか「5索」がきちんと認識された
  • 実演デモで「發」が「西」に認識されてた
  • どれぐらい早くなったのか分からなかったので、比較みたいなの欲しかったかも

Flutterとの1年

基本情報

内容メモ

  • FlutterをProduction投入して1年経ったので、四方山話
  • 去年のGoogle I/Oから使ってる
  • 思うように動かなければ最悪、ネイティブで書けるとの確信からproductionへ投入
  • Hot Reload便利
  • Dartでのクロスプラットホームのコード共有率は、画面数ベースで95%、コードベースだと70%
  • ちょいちょいネイティブとFlutterの連携画面がある（OpenCV使う、テキスト周りのバグ回避）
  • Alphaから使ってるので、バグを踏み抜いてきた
  • BetaになってだいぶFixされた
  • UIのバグは大抵、回避策がある

感想

  • Flutter、よさそう
  • Flutterもreact-nativeも、クロスプラットホームは特殊文字が含まれるテキストは鬼門感がある
  • Alphaから使っていて、どっちのプラットフォームもネイティブコードを見れるってめちゃくちゃすごい
  • Hot Reloadは最高

Realtime Database for high traffic production application

基本情報

内容メモ

  • Firebase Realtime Databaseをproductionに投入して1年経ったので、開発と運用と少しの技術的テクニックの話
  • メルカリチャンネル（Live e-commerce）で使っている
  • 開発
    • クライアントからは直接、Firebaseを叩かずに、メルカリのサーバーを挟んで、サーバーからFirebaseのAPIをcallする構成にしている
    • この構成によって、更新頻度の間引きや禁止ワードのフィルタリングなどができ、Realtime Databaseに対するクライアントのpermissionを考えなくて済む
  • 運用
    • メルカリは全体で59000/secのAPI callがある規模感
    • メルカリチャンネルはだいたい1500stremers/day, 30K viewers/day, 5M yen / streamという規模感
    • Realtime Databaseはauto scaleしない、かつdatabaseごとに制約があるので、自前で15台以上のインスタンスを立てて、Vertical Shardingしてる
    • 今ならFirestoreがあるよ
    • モニタリングは自前ツール（KibanaとMackerel）とStackdriverでダッシュボード化して、異常状態と正常状態を可視化
    • 「すべてのサービスは落ちる」ので、問題発生->検知->対応のフローを迅速かつ円滑にいくように整備
    • メルカリチャンネルはしかるべき権限を持つ人がボタン1つで、メンテナンスモードに切り替えられる
  • Cloud FirestoreとRealtime Databaseの違いはThe Firebase Blog: Cloud Firestore for Realtime Database Developersを読んでね
  • 詳しいアーキテクチャが気になる人はRealtime Messaging with Firebase #phpcon2017 - Speaker Deckを読んでね

感想

  • メイン開発者のきりんさんがjoinしてから開発期間1ヶ月でメルカリチャンネル機能がローンチされてるのすごい
  • メルカリの規模感で本番運用してる知見、めっちゃ貴重
  • 障害発生時のAlertボットの配慮が行き届いて本当に良い
    • CSメンバーしか起きていないときでも意思決定ができるだけの情報を提供するために英語->日本語翻訳をかけてる
    • 障害発生は@channelだけど、復帰はつけない

リンク

TypeScript導入で得られる「変えていく勇気」

基本情報

内容メモ

  • Typescriptの歴史
    • JSは、HTMLの中に書けば手軽に動かせる言語から.jsファイルじゃない何かをJSへと変換して動かす言語に変化してきた
    • 変換するなら処理を足してコンパイルも変換に入れてもより安全にしたっていいんじゃない？ -> Typescript
  • コードが腐る
    • コードは変わらないけど、コード以外の部分（チームメンバーの技量、増減、仕様変更etc.）が劇的に変わっていく
    • 現代では、常にリファクタリングが求められ、それを行うためには「変えていく勇気」が必要
  • 型検査の安心感
    • とはいえ、信用ならないこともあるので、値オブジェクトや混同防止プロパティを使っていこう
  • 継承は抽象的性質の表現、Not、処理の共通化手段
  • コンパイルエラーを有効に用いたリファクタリングメソッド：「炙り出し」の紹介

感想

  • 型定義ファイル、昔はnpmで管理できなかったのか...つらそう...
  • 昔は.jsと.tsを混ぜて運用もできなかったのか...つらそう
  • とある人が型検査は第1のテストって言ってたけど、まさにそういう話だった
  • なぜ今Typescriptなのかという歴史から入って、実際にどんなTipsがあるかの紹介の構成は本当に分かりやすかった
  • Typescriptやりたみが高まった

リンク

Firebase Realtime Database in Production

基本情報

内容

  • AI MessengerというBtoB向けのチャットボットにFirebase Realtime Databaseを使っている話
  • データの書き込みはメルカリと同じく、Clientから直接Firebase Realtime Databaseは叩かず、一旦サーバーを経由する
    • メルカリと同じ構成ではあるものの、その理由はちょっと違い、主にRealtime Databaseのクエリの制約の厳しさ・データマイグレーションの大変さから
  • いくつかの技術的問題にどう対処したか
    • Realtime DBは意外と書き込みの反映が遅いので、Client側で管理が必要
    • 値のクエリでフィルタリングが非常に苦手なので、データ設計の段階からそうならないように考慮すべき
    • Firebaseで大量のデータにFilterをかけるとReadが100％になり、読み書きが停止する。Googleから何したんだと連絡が来たらしいｗ。Big Tableへのダブルライトで回避
  • Full ManagedなServiceだろうと、すべてのサービスは止まる
    • だが、BtoBなので、サービスが止まるは許されない（元々の仕様では、そこまで厳しいダウンタイム運用になる予定ではなかったらしい）
    • Realtime DB障害時はBigTableなどにダブルライトされているデータをPollingして擬似的にRealtime DBを再現
  • Cloud Firestoreへの移行していきたい

感想

  • 奇しくも、きりんさんのセッションとほぼ同じタイトルで、青野さんも苦笑いしてた
  • それだけFirebase Realtime Databaseがアツいということでもある
  • サービスを止めることができないという要件がPJ最初期に上がっていたら、Realtime DBの選定には行かなかった可能性もありそうな感じだった
  • Realtime DB、工夫が結構いりそうだった

リンク

全体を通して

  • セッション間の移動がめちゃくちゃ混んでて、運営チーム大変そうだった
  • Google Dev User Groupめっちゃあって、コミュニティ多くて楽しそう
  • セッション7本連続で聞くと、頭がパンクする
  • Realtime DBの話、2つあったが、別のサービス間で使い方の似ている所、違う所が比較できて良かった
  • 部屋が満室で入れないのは悲しい
  • WiFiはできれば、欲しい
  • セッションのプレゼンターは、ウェブ・ネイティブアプリ・MLなど色々なバックグラウンドの人が集まるので、どういう発表の組み立てにするか苦心しそう
  • 全体的なやっていきが高まった

最後に

運営チームの皆様、発表者の皆様、素敵なお祭りをありがとうございました！🎉

P.S.

DevFest 2018 Tokyoの資料をまとめてくれている方がいらっしゃるので、他のセッションの資料が見たい方はご覧ください

技術書典#4の戦利品の感想の話

はじめに

もう、技術書典#4から1ヶ月近く経ってしまいましたがようやく戦利品すべてを読了したので軽く内容紹介と感想をば。

戦利品一覧

  • 技術季報
  • Cheap Dive into React Native
  • ネコミミでもわかるフロントエンド環境構築
  • オレオレ仮想DOM作りたいだけだった
  • こまるUI よくしてみた本
  • Libraries of React
  • Get Ready for Next.js

感想たち

基本情報は技術書典4公式サイトより一部抜粋。

技術季報

基本情報

  • 運営チームによる公式パンフレット
  • サークルマップ（物理）とか技術書典レポートとか特別寄稿が掲載されてる
  • 技術書典

感想

  • 運営へのお布施のつもりで購入
  • 技術書典レポートめっちゃ面白い
  • 特別寄稿は、普段の情報収集では入ってこない情報の発見がある
  • あまりに面白かったため、技術書典に参戦したあとの喫茶店でほぼ読破した
  • 初めての人は買っておくのが吉
  • 次回も買う

Cheap Dive into React Native

基本情報

  • なかざんさんのReact Native本
  • 技術書典後払いiOSアプリをcreate-react-native-appで作った話
  • React NativeでWebアプリとAndroidアプリを同時開発した話
  • React Native Androidの内部実装の話

感想

ネコミミでもわかるフロントエンド環境構築

基本情報

  • 汐瀬なぎさんのフロントエンド環境構築本
  • ネコミミ

感想

  • package.json, yarn, npm, babel, webpack, ESLint, Prettierなどフロントエンド環境構築で単語だけは知ってるみたいなやつらを丁寧に解説してくれている
  • Jest, Flowも解説してくれている
  • めっちゃわかりやすい、もう2週間ぐらい早く読みたかった
  • フロントエンド、魔法の言葉多くて怖い人におすすめ
  • ネコミミはいいぞ

オレオレ仮想DOM作りたいだけだった

基本情報

  • ukyoさんのオレオレVirtual DOM実装本
  • Virtual DOMのアルゴリズムとか色々

感想

  • React Nativeを仕事で触っているので、役に立つかと思い購入
  • ukyoさんに「Virtual DOM実装するには役に立つけど、React書くには役に立たないと思う」と言われたｗ
  • JSXがJSでどのようにトランスパイルされるかから始まり、VDOMのレンダリングロジック、ライフサイクルメソッドの実装、果てはReactFiberの簡単なやつを使った非同期レンダリングの実装と盛りだくさん
  • 完全には理解できなかったので、読みなおす
  • VDOMのレンダリングロジックを知っていると、最適化に役に立つかもしれない
  • Virtual DOMが作りたい人におすすめ
  • ダウナーな女の子が目印

こまるUI よくしてみた本

基本情報

  • いしまるさん、ゆずさん、ナユさんの共著
  • UI本

感想

  • あー、これ見たことあるというUIがいっぱい
  • 解法もいっぱい
  • ユーザーとして使っているときは、なんだこのUIと思うものの、作る側になるとすぐに忘れるので気をつける
  • noteで読める
  • 「こまるUIよくしてみた本」for note #技術書典｜ナユ｜note
  • ブースで草ステッカー売ってた
  • 表紙の女の子が持ってるのは積み木？

Libraries of React, Get Ready for Next.js

基本情報

  • どちらも著者はれいなさん
  • ReactのtipsとNext.jsの入門書

感想

  • Libraries of React
    • ReactのStateless Functional Componentの書き方やJSX記法など明日から使えるテクニックがいっぱい
    • ライブラリとして、recompose, Parcel, styled-componentsの3つを紹介
    • styled-components導入したさがある
    • 表紙は魔女っ娘
  • Get Ready for Next.js
    • Next.jsとNuxt.jsの違いに気がついておらず、Nuxt.jsの入門本だと思っていた
    • Next.jsはReactのServer Side Renderingライブラリ、Nuxt.jsはVuewのServer Side Renderingライブラリ
    • Next.js、めっちゃシンプルっぽいので触ってみたい
    • Server Side Renderingの利点とかなぜするかがいまいちよく分かってないのでその辺を調べねば
    • 表紙はメイドの人形
  • どちらもBOOTHで買える
  • れいな＠底なし沼の魔女 - BOOTH（同人誌通販・ダウンロード）

おわりに

なんだか販促記事みたいになってしまいました。 今回は、ReactやReact Nativeなど割とフロントエンドに焦点を当てて買ってきましたが、次回はもうちょっと裾野を広げたい。 次回の技術書典でも素敵な技術書に遭遇できますようにと祈りを捧げておきます。

おしまい

技術書典#4に一般参加してきたお話

TL;DR

  • 10:40（開場20分前）に行くと整理券800番代
  • 11:20（開場20分後）には整理券900番まで入場列に並べる
  • 11:30（開場30分後）には入場できた
  • 後払いアプリ便利
  • 事前のサークルチェックは念入りに

はじめに

技術書典の第4回に参戦してきたので、その覚書です。 初参戦ということもあって、事前準備として、なっぴーさんの技術書典入門記事を読み漁ったりしてました。 めっちゃ分かりやすかったので感謝。 napplecomputer.hatenablog.com

ただ、何時に行くとどれぐらいの整理券番号で何時間待ちになるんじゃろ？という情報が いまいち見つからなかったので、第5回以降の参考値になればと思い書きます。 何かのブログで第3回の整理券番号の話を読んだ気もするんですが、見つからなかった...

もう1週間も経過してしまって、今更感が半端ない。

事前準備

後払いアプリは認証も事前のテスト購入もしっかり済ませておきました。 当日のTLを見た限りSMSのAPI上限か何かで認証ができなかった方もいたみたいなので、次回以降も踏襲しようと思います。 事前のサークルチェックは、ざらっと気になるところをチェックしておいたぐらいでした。 あまり欲張らなかったのは正解だった気がする。

当日

30分前に到着すれば、直接入場列にいけちゃうのでは？と考えていたのですが、まったく甘かったです。 UDXのエスカレーターを上がってみると人が並んでいるわ、座っているわでどこを見ても人がたくさん。 とりあえず、緑の運営Tシャツを来た人の案内にしたがって、整理券配布列の最後尾へ。

整理券配布列も結構な長さがあって、これはかなり待たないともらえないやつかと思いきやスイスイ進む配布列。 10分もしないうちに自分の番になり、整理券番号879番をゲット。 どれぐらいの待ち時間になるのか想像がつかなかったのですが、昼を食べるほどの時間にはならないだろうと踏んで秋葉原を散策。 駅前をぐるっと回ったぐらいで入場できる受付番号を確認すると700番まででした。 そのあとスマホを見ているうちに900番までになったので、会場へ。

入場するための列へ並んで待機した後に、会場へ。

会場内は、一番混んでいる時間の小田急線よりは混んでいませんでした。 入ってすぐに運営のブースがあり、技術書典袋（緑のアレ）と技術季報を入手。 とりあえず、サークル配置図を片手に目当てのサークル目指して一目散しました。 サークル配置図が一時落ちていたらしいですが、私が見た時には見れた。

入口付近の混みはさほどでもなかったんですが、入口の窓側の通路（「お」と「か」の間）はめっちゃ混んでました。 正直、見本紙を手にとって見るほどの心の余裕はなかったです。 技術書典であれなら、夏コミとか一体どんなことになっているんだろう...

幸い、チェックしたサークルは売り切れもなく回りきれたので、そのまま撤退を決めました。

その後はカフェで、技術書典の戦利品を読み漁るオタクになっていた。

戦利品

読んだら感想書きます（宣言）

  • こまるUI よくしてみた本
  • オレオレ仮想DOM作りたいだけだった
  • ネコミミでもわかるフロントエンド環境構築
  • Cheap Dive into React Native
  • 技術季報
  • Libraries of React

よかった

  • 後払いアプリ
  • 導線管理・誘導etc.
  • 整理券システム
  • サークルチェックリスト / サークル配置図

めっちゃ便利でした。 さすが、技術書典。あっちこっちに参加者の利便性を考えた工夫が随所に見られて最高。

改善できそうなところ

  • 通路の混雑

通路の混雑はあんなものなのかもしれないのですが、結構つらい。 ブースの間の通路に人が4列で移動したり、ブースで本を購入する形になるのですが、ブースに面していない内側の2列がカオス。 入口方面に行きたい人と出口方面に行きたい人がごちゃごちゃにいるので、移動だけでもめちゃくちゃ時間がかかります。 中央で分けて一方通行にすればいいのではと思いつつ、あの混雑ではそれも難しい気もします。何より人を配置するのが大変。 パーティションで区切ればいけるか？？？ 入れる人を減らすことでもいけると思いますが、それは整理券の捌けが悪くなるので良い手でもなさそう。 あれが、同人誌即売会の洗礼だった可能性が...

参加者の人数に対して箱の限界を感じる。これが晴天の力。

最後に

サークル参加の皆様、運営の皆様、お疲れ様でした。 次も参加したいと思います。

おしまい。