ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

MANABIYA「エンジニアのための自分経営戦略」聴講メモ

マネジメント／リーダーシップ 勉強会/セミナー 道標

はじめに

MANABIYA(【国内最大級のエンジニア向け技術祭典】MANABIYA -teratail Developer Days-)
2018/03/24（土）2時間目
エンジニアのための自分経営戦略
スピーカー：西尾 泰和 さん [サイボウズ・ラボ]
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。
https://www.dropbox.com/s/iese0p9iq6y33hr/MANABIYA_%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E8%87%AA%E5%88%86%E7%B5%8C%E5%96%B6%E6%88%A6%E7%95%A5.pdf

（2018/03/28 追記）
西尾さんの講演の前編ともいえる及川さんの講演メモもアップしています。
ぜひ併せてご確認ください。
MANABIYA「技術者としての成長のための技術トレンド」聴講メモ - ぱと隊長日誌

基本戦略：損失額の限定

及川 卓也さんの講演（西尾さんの講演の前にあった）で1万時間をかければプロになれるという話の紹介があったが、それだけの投資を決めるのは怖いこと（毎日取り組んでも何年もかかる）。だから、まずは損失を小さく（まずは１時間だけとか）限定して取り組む。

経営戦略とは何か

限られたリソース、つまり24時間をどう使うかということ。

東工大で経営を学んだあと、どう活かしてよいかわからなかった。だから、未踏の理事着任のチャンスに乗った。

列挙を疑え

今回のプロジェクトで使うプログラミング言語をA言語/B言語/C言語のどれから選ぶべきか？これこそが列挙だ。単独で使うのではなく、複数を組み合わせるという手段だってあるはず。

配分をして何を得たいのか

より多くの利益を稼ぐことばかりが戦略ではない。

狙って赤字を出す会社がある。これは内部留保より投資をする（競争力を強化する）という経営戦略を選んだということ。

給料を下げれば利益を増やすことができるが、従業員満足度は下がることになる。

あなたは知識に価値を感じている

自分の価値観や経営判断を自覚すれば、その後の行動が変わってくる。

多くの方が自身の価値観や経営判断に無自覚であり、自分がそれを自覚するだけでその他大勢から抜き出ることができる。

知識の交換によって学ぶ

知識の交換は双方に先生と生徒の関係になる。

相手が自分より知識の少ない方だとしても、得意分野がずれていれば、そこで知識の交換ができる。知識交換の必要条件は「相手と違うことを知っている」ことであり、知識が全く同じ分野で重なっていると交換できない。

質問に回答する例

スライドで挙げた例はQ&Aサイトでしばしば発生している。

フリーライダーの発生

「情報共有は例外的～」の一例が勉強会。リスナーがいくらいても発信できる。ただ、お互いを知った上でのコミュニケーションをすることはできない。

最初はひっそり非公式でよい

最初は2,3人程度で会の名前も決めず、情報共有しようと緩く始めるのがよい。

知識交換の必要条件

スライドの図で赤線が自分だとする。グループA/Bそれぞれで周囲の知識水準より低い。

だが、グループAと自分（赤線）だけで考えると、グループAが持っていないグループBに関する知識を自分は持っており、それを提供することができる。

T字型人材というが、専門性の軸が1本である必要はない。何本あってもいいはずだ。

専門性のレベル

「ググっても入手できない知識」の一例が実際に行動・実験した経験。マニュアルに記載のない事象にはまった経験はまさに「ググっても入手できない知識」といえる。

ただ、これをブログに書けば「ググれば入手できる知識」となり、海面のレベルが上がるため、新しい経験を得るためにより行動する必要がある。

最初の一歩

作った非公式グループが失敗に終わるのは悪いことではない。そこで終わらせるのではなく、振り返ることが大切だ。

おわりに

この講演に関連してFacebookグループが作成されました。
180324 エンジニアのための自分経営戦略

講演資料に「思い出しトリガーをセットする」という話がありましたが、このグループはその実証実験ともいえそうです。

このまま忘れられていくのか、活発に議論されるのか。それは参加者の行動次第といえます。質問にも答えていただけるということなので、まずは講演を聞いたり資料を読んで感じた疑問を投稿してみてはいかがでしょうか。

（2018/03/28 追記）
上記Facebookグループでは西尾さんによる補足や質問への回答も行われています。当日参加できなかった方も資料を読み込んだうえで、ぜひグループにご参加ください。

二乗平均の分母はなぜ平方根に含めるのか？

数学

はじめに

二乗平均の計算は各データを2乗して足してデータの個数で割り、そのあと平方根をとります。
\displaystyle\sqrt{\frac{a_{1}^2+a_{2}^2+\cdots+a_{n}^2}{n}}

各データを2乗して足すのはマイナスの符号をなくすためで、このままでは単位が2乗になるために平方根をとる、と多くの資料で説明されます。

ですが、単位の問題だけであれば、各データを2乗した分子だけ平方根をとればよい気がするのは私だけでしょうか…？
そこで、分母も含めて平方根をとる理由について考察してみました。

今回、裏付け（もしくは否定）となる資料を探したのですが、見つけることができませんでした。もし関連する情報をご存知の方がいましたら、ぜひご連絡ください。

平均の計算式

算術平均はデータを全て足してデータの数で割る、いわゆる「平均」のことです。
\displaystyle\frac{a_{1}+a_{2}+\cdots+a_{n}}{n}

二乗平均とは2乗した値の平均をとる、というのが根底にあります。ですから、まずはこの値を計算します。これは算術平均と同じ形であることが分かります。
\displaystyle\frac{a_{1}^2+a_{2}^2+\cdots+a_{n}^2}{n}
単位の計算はこの値に対して行います。この結果として、分母を含めて平方根をとることになります。
\displaystyle\sqrt{\frac{a_{1}^2+a_{2}^2+\cdots+a_{n}^2}{n}}
これが分母を含めて平方根をとる理由となります。

平均の単位

単位の計算を次のように習った方もいるかもしれません。
時速は距離[km]を時間(hour)[h]で割る。だから[km/h]と記載する。

だとすれば、平均の単位とはどうなるのでしょうか？
距離の平均は距離[km]をデータの個数[個]で割るのだから、km/個とすべきでしょうか…？もしそうだとすれば、距離の2乗[km2]をデータの個数[個]で割ったとき、単位を[km2/個]とすべきなのでしょうか？
この単位の分子は[km2]ですから元の単位の[km]に戻すために平方根をとるのは理解できますが、単位の分母の[個]は2乗していないのに平方根をとってもよいのでしょうか？

そこで、まずは算術平均の単位を考えてみます。距離[km]の平均値の単位は[km]です。データの個数の単位[個]はどこにいったのでしょうか？
まず、距離というのは[km]という単位を持つ量です。これに対し、データの個数というのは単位を持ちません。単位を持たないため、[1]で表現することにします。すると、距離[km]の平均は 距離[km]/データ個数[1] = [km/1] = [km] となり、平均値の単位は[km]と言えることが分かります。

「データの個数」について補足すると、これは物理的な数ではありません。物理的な数ではないので単位をつけません。
例えば、3個のリンゴの平均の重さを計算する時、「3個のリンゴの重さの合計[g]/3」と計算します。この時、分母の3が「リンゴの個数」と考えると[個]という単位をつけたくなりますが、すると単位は[g/個]となり、1個当たりの重さの単位になってしまいます。
ここで求めたいのは平均の重さですので、単位は[g]であるべきであり、そう考えると分母は「データの個数」で単位がない（もしくは[1]）とすることで距離の平均の場合との整合性をとることができます。

次に二乗平均の単位について考えます。
距離の二乗をデータの個数で割った値の単位は (距離[km])2/データ個数[1] = km2/1 = km2 となります。であれば、この値に平方根を取ることで[km]になることが分かります。

もし、二乗平均をとるデータの値に単位がなくても、その単位を[1]と考えれば、2乗した時の単位が[12]であり、それに平方根をとることで[1]となります。平方根をとらなくても[1]ではありますが、二乗平均をとる値の単位の有無に応じて公式が変わるのを避けるため、常に平方根をとっています。

まとめ

二乗平均は2乗した値の平均を計算し、データと単位を合わせるために平方根をとります。計算式は次の通りです。
\displaystyle\sqrt{\frac{a_{1}^2+a_{2}^2+\cdots+a_{n}^2}{n}}

分母も含めて平方根をとるのは、二乗平均は平均の計算が主軸にあり、まずはその計算を行ってから単位の計算を行うからです。

「二乗平均」は「二乗平均平方根」とも呼ばれます。「二乗した値の平均値の平方根をとる」という計算方法を考えると、「二乗平均平方根」という呼び方のほうがしっくりくるかもしれません。

参考

完全独習　統計学入門

完全独習 統計学入門

完全独習 統計学入門

今回の疑問を抱くきっかけになった一冊です。統計学を学び始めたい方の最初の一冊としてお勧めします。平均とは何かというレベルから解説しています。
中学数学（それも簡単な範囲）のみを利用して解説しています。それゆえに逆に難しい解説になってしまっている箇所もありますが、全体を通してみれば学びやすいと感じました。

Wikipediaの「無次元量」の解説

無次元量 - Wikipedia

「データの個数に単位はない」という発想はここから得ています。ただ、ぴったりに当てはまる項目がなく、私が考え違いをしている可能性もあります。
ご存知の方がいらっしゃいましたら、ぜひご教示ください。

デブサミ2018「【16-C-3】Gitで安定マスターブランチを手に入れる」聴講メモ

アーキテクチャ 勉強会/セミナー インフラ プログラミング

はじめに

Developers Summit 2018 (Developers Summit 2018)
【16-C-3】Gitで安定マスターブランチを手に入れる
スピーカー：井上 誠一郎 さん [ワークスアプリケーションズ] ／ 三宅 泰裕 さん [ワークスアプリケーションズ]）
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
【デブサミ2018】16-C-3「Gitで安定マスターブランチを手に入れる」 #devsumiC #devsumi - Togetter

【参考】としている個所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ

用語

このセッションでの用語の定義として、マスターブランチとデベロッパーブランチを同じ意味で用いており、開発している最新のコードを指す。

マイクロサービス

既存のモノリスなシステムのマイクロサービス化を図ると、機能によってはライブラリの重複する物が発生する。だが、それを無理に切り分けると無駄が発生する。

マイクロサービス化したことにより、ビルド時間やデプロイ時間が短くなった。ビルドに37時間かかっていたのが5時間へ減った。

マイクロサービスの定義と現実のギャップでエンジニアから不満の声（こんなのはマイクロサービスといえない！）が上がることもあるが、ビルド時間の短縮をターゲットにして、できる範囲で進めている。

業務ドメインをきれいに分けたくても、重複はどうしても発生する。

開発拠点が世界各地かつ様々なコミュニケーションチャネルを持つ中で、後方互換性を保つことに対するコンセンサスを取るのが大変だった。
例えば、以下のようなことを考慮しなければいけない。

  • ライブラリやサービス間のAPIの互換性
  • データベースのスキーマ変更への対応
  • メッセージキューの内容の変更

後方互換性を確保する標準的な方法もあるにはあるが、大規模な人数だと必ずしも徹底できない。

業務ドメインの境目はあいまいで、エリックがいうほどきれいにはできなかった。

【参考】
エリックは言わずと知れたエリック・エヴァンスのことです。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

テストと開発環境

テスト環境に存在しているライブラリと業務ドメインのバージョンがばらばらだとしたら、果たして本質的なテストが実施できるのだろうか？

開発環境の競合が問題となった。DBを共有すると、スキーマ変更の度に環境の利用者全員が待たされることになる。
マイクロサービスなら共有のAPも必要となる。モックを用意すればよい、という意見もあるかもしれないが、実際にはうまくいかなかった。
そこで、最終的には実物を用意することにした。

開発環境をクラウドでいくつも作ろうとすると、台数が多いだけに意外とお金がかかる（クラウドだから安いというのは幻想）。社内に空きサーバが転がっていたため、Openstack + Kubernetes (k8s) で構築することにした。

開発環境はチームもしくはドメイン単位で切り分けた。

開発環境が共有だったころ、環境を壊すと世界中の開発拠点から怒られた。
手元に開発環境が用意されたことで、環境を触ろうという意欲が出てきた。例えばCIに取り組むとか。

開発環境の分離とサーバリソースの効率化はトレードオフの関係にあり、そのバランスが肝になる。

開発者もQE(Quality Engineer)も同じ物を見てテストしたい。ユニットテストでカバーできないこと、例えばUI/UXのように人手で見るしかテストできないことを早くテストしたい。

だが、QEのテスト環境を壊すと怒られる。これをユニットテストで防ぐというのは簡単なことではない。だから、壊さないのではなく壊れても良い環境を用意する。

OpenStackのCinder。AWSのEBSに相当する。

【参考】
Cinderについては以下の記事が参考になります。
OpenStack 2012.2で追加された新機能「Cinder」を使う | さくらのナレッジ

業務アプリのバグはロジックと言うよりデータのバリエーションが多いことに起因することが多い。この種のバグをどう防ぐかが今後の課題となっている。