builderscon tokyo 2018に参加して丸2日間色んな技術を学んできた

buildersconというカンファレンスに参加してきました。

builderscon.io

2018/09/07(金)〜2018/09/08(土)の2日間で開催されていましたが、両日ともためになる内容が沢山聞けて個人的にとても充実したカンファレンスでしたでした。この記事では2日間で受けた全てのセッションのメモを残そうと思います。

Kubernetesで実現するインフラの自動構築パイプライン

builderscon.io

Kubernetes で実現するインフラ自動構築パイプライン from Yusuke Nojima

• cybouzのインフラ
  • 物理サーバー1,000台以上
  • インフラのためのPythonコード100,000以上

• よくある自動化の流れ

  • 人が手でオペレーションする
  • オペレーションの回数が増えてくる（辛い）
  • 手順をPythonスクリプトにして自動化

• スクリプトを実行するための前提条件が難しい

  • 前提条件を満たすために人が頑張る
  • 考慮漏れがあると障害になる
• 手順ベースの自動化のつらみ
  • 「手順」は差分的
    • 現在の状態と理想の状態の差分
  • 手順をそのまま自動化すると脆いシステムになる
    • 現在の状態がちょっと変わっただけで動かなくなる
    • ちゃんと前提条件を満たせているのかどうかが不安
  • ではどうすればいいか
    • 理想状態への収束
      • 理想状態をシステムに与えると現在の状態との差分を自動的に抽出し、必要な手順を勝手にやってくれる
• プロダクトのAWS移管を機にスケールするインフラづくりを目指した
  • 「理想状態への収束」をするためにKubernetesを利用

手順書運用のなんとなく辛いと感じてた部分を言語化してくれててスッキリした。組織やプロダクトが常に変わり続けるようなWebサービスづくりをやってると前提条件が変わって手順書がすぐ使えなくなってしまうというのはすごくよく分かる。Kubernetesの具体的な話に関してはこちらの知見が少なくあまりピンとこなかったので、Kubernetesの情報収集してからスライドを見返そうと思った。

開発現場で役立たせるための設計原則とパターン

builderscon.io

設計原則もデザインパターンも勉強しよう…すごく分かりやすかったー！ #builderscon pic.twitter.com/qlzYTSuXK9

— ささ (@3neko_haco) 2018年9月7日

※ スライド資料が見当たらなかったので図解してくれてる方のツイートを貼っておきます

nekogata.hatenablog.com

[追記] スライドがアップされました！

• 設計とかパターン
  • 議論が空中戦になりがちで、発散しがち
  • 責務って考え方次第
  • 「DRY原則」→Utilクラス誕生→「Utilクラスは糞」→どうすればいいの？？？？
• 設計とは
  • ある問題に対して解決策となるような構造を与えるためのアクティビティ
  • 複数の分割構造の選択肢から最適な選択を選び出すこと
    • ここで設計原則やデザインパターンが武器になる
• デザインパターンと設計原則
  • デザインパターンとは
    • 分割構造とその実現方法のカタログ
  • 設計原則とは
    • 分割構造が良い構造かどうかを判断するための指針
    • 一回構造をつくって終わりじゃなくて、設計原則を使ってレビューして、さらに再構築する
• あかん
  • なんであかんのか言語化できますか？
    • できなければそれは暗黙知
    • ちゃんと設計レビューなどで言語化できた方がいい
    • 根拠がもってレビューしよう
• 重要な設計原則
  • 単一責任原則
  • 解放閉鎖原則
  • 凝集度と結合度
• 単一責任原則
  • あるクラスを変更する理由がふたつ以上あってはいけない
  • 変更Aと変更Bのどちらからも影響を受けるクラスはだめ
  • 逆にいうと「どこが変更されるか」が分からないと単一責任原則は使えない
  • 「どこが変わりやすいポイントなのか」を見極める必要がある
• 解放閉鎖原則
  • 拡張に対して開いている
    • 機能拡張、機能追加するときに他のクラスに影響がないようにしよう
  • 修正に対して閉じている
    • 内部を修正したときにそのクラスに依存しているクラスに影響がないようにしよう
    • あるモジュールを修正するときに、その呼び出し元も修正しなきゃいけないのはだめ
• 凝集度と結合度
  • 凝集度は高く
    • 関連するものはひとつにまとめる
    • ひとつの仕様変更でいろんなクラスに影響しないようにしたい
  • 結合度は低く
    • 片方の影響がもう片方に出ないようにする
• 設計は「問題」次第

• 抽象化しない勇気を持つ

  • KISS原則
  • YAGNI原則
    • どこが変わるかわからないときには現在分かってる範囲のみで極力シンプルにしておくべき

• おすすめリポジトリ

  • EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
    • どこが変わってもいいように書かれたFizzBuzz．問題を捉えそこねた抽象化を重ねた結果ひどいことになっている
• まとめ
  • 複数の選択肢を持つ
  • 変わりやすい場所を見つけ出す
  • 問題に対して適切な設計原則を適用する

一番聞きたかったセッションだけど期待通りめちゃくちゃためになる内容だった。コードレビューや設計レビューをする際、既存のソフトウェアのつくりにフォーカスしやすいけど、未来の仕様として「変わりやすいポイント」がどこなのかを予測しながら設計を考えるのが大事だという話は非常に納得感があった。問題を捉えそこねた上で設計原則しても意味無いというのもすごく同意。一概に◯◯原則を適用すればいいというものでもなくその前段階に何が問題なのかを見極める癖をつけていきたいと思う。

知らなかった時に困るWebサービスのセキュリティ対策

builderscon.io

• 実例
  • カラーミーショップで実際に起きた情報流出インシデントの実例を交えたセキュリティについての話
  • 不正プログラムを設置された
• 情報セキュリティ
  • 以下3つのうち一つでも損なわれるとセキュリティインシデントになる
  • 機密性: 盗まれない見られない
  • 完全性: ぶっこわされない
  • 可用性: 落とされない
• 基本的な概念
  • 脅威
    • インシデントを引き起こす可能性のある要因
  • リスク
    • 脆弱性に漬け込むことによって組織に損害を与えることの影響
  • 脆弱性
• 入口
  • 不正ファイル識別不足
    • ファイルのアップローダ部分の機能にPHP, CGIプログラムが含まれていないかを検証する機能を実装する
  • Webアプリケーション侵入に対する対策不足
    • WAF
• 出口
  • ロギング不足
    • データベースに対するクエリログ
    • ログはFluentdを使ってS3に集める
• 体制の強化
  • セキュリティ対策室の設立
• ISMS（情報セキュリティマネジメントシステム）
  • チームでPDCAをまわす
• ISMSのコスト増は確実にある
  • 全部は対処できない
  • 適切なリスク評価によって優先順位を決める

実例を交えたリアリティのある話が聞けて面白いセッションだった。改めて思ったのはセキュリティ対策は組織づくりとセットであるということ。インシデントにつながる脆弱性情報のキャッチアップもそうだし、インシデント発生時の対応は日頃からチームとしてポリシーを決めてリスク管理しておくことが大事。

機械学習を用いず数学でゲーム内の需要予測する

builderscon.io

機械学習を用いず数学でゲーム内の需要予測をする #builderscon pic.twitter.com/9nIuLG70QZ

— たかふぉい (@fffttt8514) 2018年9月7日

（資料公開待ち）

• 4つの分析
  • 記述的分析: 過去や現在を知る
    • BIツール
  • 診断的分析: 因果関係を見つける
  • 予測的分析: 未来を知る
    • 機械学習
  • 処方的分析: 未来をコントロールする
    • 機械学習
• ex 1ヶ月に1.02倍の成長→2年後には2.03倍になる
• 正しくデータを解釈できるようになるためにはどうすればいいか？
  • 数学しようぜ
• 数学者がやっていること
  • なぜの追求
    • 曖昧な理由（主観的要素）を排除し客観的な正しさを求める
    • 数値化することで客観性を担保する
    • 主観に基づく認知バイアスを取り除く
  • 数値と言語の行き来
    • 藤沢数希
      • モテ = 試行回数 * hit ratio
      • hit ratioはどんだけ頑張っても1なのに対し、試行回数は無限。
• ソシャゲ運用あるある
  • ex 新規ガチャめっちゃ売れた→ 復刻したときも売上期待できそうだ！→売れない。。
• 未来予測の流れ
  • 1. 前提条件とゴールの設定
    2. ex. ゴール: 現在のデータから次回のがちゃがどれくらい回るのかを予測する
  • 1. データを眺める
    2. 統計的にどれくらいのサンプル数を見れば十分かは求められる
    3. 所詮有限な数なので5000くらいは気合で見る
  • 1. 仮説作成
    2. ドメイン知識が重要
  • 1. 仮説を数値に落とし込む
    2. いきなりフィットすることはないので最初は最小値と最大値が合うような一次式を組み立てる
    3. 端点さえあっていれば中身はあとでいくらでも調整できる
    4. スキルレベルごとの所持人数をカウントしてそれに重みをつけた一次式を調整する
  • 1. 例外処理・微調整
    2. 土台となる式ができても2,3割くらいは実際の値からかけ離れていることがほとんど
    3. どのデータがずれているのかひたすら観測する
    4. データ数が少ないと特にデータがぶれやすい
  • ゴールと相関のある数字を見つけて例外をひたすら潰していく
• 機械学習にも挑戦したけど全然うまくいかなかった
  • 過去データがとれない
  • データの前処理を先にやらないといけない
  • 十分なデータがない

思ったよりがっつり数学の話だったけど数学を扱う人の生態系に触れられて面白かった。未来予測をどうするかの話は具体的な手順が分かりやすくて、うちのグロースハックチームで題材作って試してみたい。

次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス

builderscon.io

• 自己紹介
  • FastlyでOSS開発者をやっている
• ネットワークを信頼していいかという議論がここ最近巻き起こっている
  • スノーデン
  • みんな会社のWiFiだけじゃなくてパブリックなWiFi使ったりしてる
• アジェンダ
  • TLS1.3
  • QUIC
• TLS1.3がどういうものか
  • ほとんどメジャーバージョナップ（TLS1.2からガラッと変わってる）
  • 再接続する場合は0回
  • AES-GCM
    • 認証付き暗号化をやっている
    • AES-CTR
    • 問題としてはnonceを1回しか使えない
• TLS1.2のハンドシェイクプロトコル
  • やりとり
    • パラメーター
    • 証明書
    • 公開鍵
  • 問題点
    • やりとりを2回繰り返さないと暗号化できない
    • 証明書から誰と通信できるかバレてしまう。大規模なトラッキングができてしまう
• TLS1.3のハンドシェイクプロトコル
  • サーバーはクライアントからリクエストを受信した瞬間からアプリケーションデータを送りはじめることができる
  • 証明書が守られている
• 標準化まで時間がかかっていた
  • 企業向けのファイヤーウォールで通信を切られていた
  • TLS1.3だと証明書が暗号化されているから、誰と通信しているかがわからないため
  • TLS1.3を通せないgatewayがあったために、普及に時間がかかった。TLS 1.2の再接続要求に見えるようにフローを変更
• QUIC
  • 暗号化されたトランスポートで、ハンドシェイクにTLS 1.3を利用。
  • トランスポート層で複数のコネクションをまとめる機能、先頭のパケットが落ちても後続のデータが読める
  • QUICだと、ネットの接続先が切り替わっても接続が来れない
  • QUIC+TLS1.3だとHTTP+TLS1.2より通信の往復が少なくて済むのに加え、攻撃耐性ができる
• まとめ
  • プライバシーを侵害するような攻撃はほぼ防げるようになる
  • 暗号化は可用性のため、プロトコルの硬直性のためにも使われるようになる

専門ではない話が沢山でてきてセッション全体的に正直理解度5割くらい。ただ、通信インフラ面でどういう技術開発が行われているかをキャッチアップするという意味ではすごくよかった。社会的に現行のネットワークの信頼性に議論が生まれているというのは納得。TLS1.3やQUICというプロトコルの仕様策定や実装に関わってるからこそ話せる内容だと思うので貴重な機会になった。

すべてがgemになる - サービス密結合からの段階的脱却

builderscon.io

• 概要
  • 2つめ、3つめの既存サービスとデータを共有するサービスを作るときにどう連携するか
• サービスの構成
  • Wantedly
    • メインサーバ
    • 全サービス共通のユーザー認証サーバ
  • マイクロサービス
  • マザーRails
    • コアなドメインを扱うサーバはRails
• サービス密結合は何が悪いんだっけ？
  • ex. メイン◯◯サーバーの共有→相乗りする
  • うれしいこと
    • 既存の資産を存分に
    • サーバがいっぱいあるとつらいことが多い（エラーハンドリング、リトライ）
  • いやなこと
    • 障害起きたときの問題の切り分けが難しくなる
      • 影響範囲を調べるのに両方の知識がいる
    • 下手すると巻き添え食らって両方落ちる
      • 共有サーバーが単一障害点になる
    • モデルが混ざる
      • app/modelsをぱっとみてどれがどっちのサービスなのかわからない
      • 実現したいことが似ているからといってサービス間でモデルまで共有するとさらに見極め困難になる。変更するときの影響範囲の判断が困難に。
• 共有サーバーが落ちたのをきっかけに密結合を離すことに立ち向かった
  • ドメイン定義
    • DDDの本読んだ
  • 移行先サーバーづくり
    • 新機能は全部新しいサーバーに
    • これにより新機能追加を不安なく行えるようになった
  • コアモデルを新サーバーから触れるように
    • 特定のデータの読み書きにどうしてももとのサーバーを経由してしまうためつらい
    • Rubyならgemにすれば生産性を下げずモデルを共有できるのではないか？
• モデルをshared gemにした話
  • 1. DBを共有する
    2. マイクロサービスでは1つのDBを複数サービスが参照するのはアンチパターンだが、今回はモデルが共有される、ActiveRecord経由のみで読み書きするためよしとした
  • 1. 切り出し対象を決める
    2. 切り出し対象の中心になるモデルを決める
    3. 関連するモデルやサービスをクラス図とか書く
    4. fluent loggerなどを使ってログ収集してもいいか
    5. 切り出し対象のコードを決める
  • 1. 切り出し方（gem化のやり方）を決める
    2. 共有部分を新しいリポジトリに切り出す
    3. そのままgemにするとデバッグがしづらくなる
    4. gemの中身をすべてシンボリックリンクにしてしまう
    5. 実体はもとRailsのapp以下においておく

開発スピードを落とさずに、数年後に後悔しないで済む設計をするためにどうするかの話。うちもサービス拡大に伴ってどのようなアーキテクチャにするかは悩むポイントなので他人事じゃない感じで聞いてた。マイクロサービス化しながらDB共有するってかなりドラスティックな変更だと思うので、APIじゃだめだったのかなどもっとメリット・デメリットについて突っ込んで聞いてみたいと思った。もっとメリット・デメリットについて突っ込んで聞いてみたいと思った。

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

builderscon.io

• はてなブログの独自ドメインを常時HTTPS化にした話
• 現在万単位の独自ドメインが登録されている
• Let’sEncryptを利用
  • APIで利用可能な認証局（CA）
• Let’sEncryptの登場は朗報だけど、これだけだと足りない
• 万単位のTLS証明書を管理する戦術、戦略が欠けている
• HTTPS配信
  • 一般的なWebサイト運用の感覚だとなーバスすぎる
  • 万単位の証明書を一度に読み込むとproxyのメモリ使用量が著しく増加する
  • proxyの再起動にも時間がかかる
• SANを利用するか？
  • Subject Alternative Names
  • 1つの証明書に複数ドメインを紐付ける拡張
  • 結論から言うとはてなブログでは難しい
    • LEでSANを利用する場合ACME challengeはdns-01のみしか利用できない
    • DNS設定は各ユーザーに委ねられるので自動化できない
• ACMEとは？
  • 証明書発行などの作業を自動化するプロトコル
  • Let’sEncryptが主導
  • dns-01: ドメインのTXTレコードにワンタイムトークンを書き込む
  • http-01: CAのリクエストに対し所定のレスポンスを返す
• 証明書発行
  • 一貫性・網羅性が求められる
  • 発行に失敗するとブログが閲覧できなくなる
  • 要求は高いが不確実性は高い
  • 証明書を更新する際、ドメイン数に対してスケールすること
• 無効なドメインの削除対応
  • ACEM challengeに必ず失敗する
  • 放置するとAPI limitにあたってしまう
  • そのため失敗したドメインは必ず削除する
• 実際にできたシステムの紹介
• 配信システム
  • ngx_mruby: 証明書読み込み時にmrubyのコードを実行
    • cache gatewayへhttp getするだけ
    • リクエストごとに証明書を取得
  • AWS(DynamoDB)API呼び出しをHTTP APIに帰る
    • mrubyにはAWSSDKがない
  • 同居するmemcachedにも読み書きしてDynamoDBへの書き込みをへらす
• 証明書発行システム
  • AWS StepFunctions
    • 処理の実行順を管理、エラー処理、Lambdaを実行
    • エラー内容に応じたリカバリ・リトライ
  • AWS Lambda
    • 証明書を発行、DynamoDBへ書き込み
  • はてなブログのボタンを押すとStepFunctionsが起動。Lambdaが起動しLet’sEncryptにACMEチャレンジを行い成功したらDynanmoDBに保存
• 証明書定期更新
  • DynamoDBの「TTL Trigger」がLambda経由でSFnを起動
  • cert-reissue-confirmer: はてなブログにドメイン有効性を問い合わせて更新する必要があるかどうかを後続に伝える
  • DynamoDBのTTLTrigger機能について
    • TTL expire を DynamoDB ストリームのトリガーで掴む
• ぼくのかんがえたさいきょうのピタゴラスイッチ
  • ワークフローエンジンの導入
    • AWS StepFunctionsとそれから実行されるAWSLambda
  • pub/subモデルで対象データの増加に対しスケールさせる
    • pub/sub: DynamoDBとTTLTrigger
• Q&A
  • 更新失敗時の対応は？
    • DynamoDBを2種類用意して、TTLをそれぞれ分けている。 具体的には実際の期限前の2週間前くらいにしている。StepFunctionsの結果を取ってきて、Mackerelに通知するようにして、その猶予の間に手動などで対応する

うちでもまさにLet’sEncryptを使った独自ドメイン管理の自動化を行っていて比較しながらの聞けたのですごく勉強になった。ドメイン数が今後スケールして多くなっていったときにいかにスケールに耐えられる構成にするかいう視点でAWSのフルマネージドサービスに寄せるのは正しい選択な気がする。DynamoDBの機能など知らないこと多かったのでもっと勉強しようと思った。

つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側

builderscon.io

• SmartHRのデータベース移行プロジェクトの話
• もともとの問題
  • スキーマ変更のせいで時間がかかりすぎる
• マルチテナント
  • 複数の企業が同じWeb/DBサーバーを共有する（利用企業からみると専用）
  • 計画資源を共有しつつデータの分離を実現
• なぜやるか？
  • インフラにお金がかからない
• Railsのマルチテナントgemを採用
  • 「apartment」というgem
  • テナントが作成されると、MYSQLならCREATE DATABASEが実行される
  • 生成された対象に向けてスキーマ定義を適用
• apartmentの落とし穴
  • 全然関係ないけど去年台湾のRubyカンファレンスで「apartmentを使うな」という発表ｗ
  • DBマイグレーションにかかる時間の増大
  • データベースの起動にかかる時間の蔵絵代
  • ActiveRecordのキャッシュでメモリどか食い
• マイグレーション問題
  • 1テナントあたりマイグレーション1回。10000テナントなら10000回
  • これのせいで100時間とかかかる
• 週1〜2ペースでマイグレーション実施してた
  • サービスリリース後徐々に顕在化するデプロイ問題
  • Webコンテナのデプロイは終わってるのにmigrationのデプロイが終わらず500エラーに
  • それを解消するために並列実行をやめたら時間がかかるように。。。

• 問題の整理

  • 並列デプロイは実践投入されたばかりで不安定

• 解決策

  • 金の弾丸
    • インスタンスはケチっちゃだめ
  • 優先マイグレーション
    • ログイン回数が多いユーザーや、課金ユーザーを優先的にマイグレーションする
• Citus
  • オープンソースのPostgreSQL拡張
  • 高いスケーラビリティ
  • クエリ並列化のための分散エンジン
  • とにかくマイグレーションが速くアプリケーションからは単一のDBのようにみえる
  • Citusに移行
• 移行に伴いコードフリーズ
  • 機能開発しながら移行はきつい
  • 5〜6月にかけて本体の開発を一ヶ月停止しますと全社通知

• 最終的に100時間のデプロイが23秒に。

• Q&A

  • 移行後のデータが壊れていないかどうかの検証どうしたか？
    • よくこけるデータは決まってるので、テストテナントで確認
  • 会社としてコードフリーズができた要因は？
    • プロダクトオーナーは開発チームの会話の中にいつもいるので、理解してもらいやすかった

マルチテナント構成のつらみとそれが巻き起こすデプロイに関する問題を解消するための壮絶な戦いの記録を聞いたという感じで発表後の満腹感がすごかった。サービスのユーザー価値に直接的に寄与しない開発にこれだけの労力を時間をかけて粘り強く取り組んで改善できたというのは素晴らしいと思う。特にコードフリーズの判断は会社としても強い意志を持たないとできないことなので、開発のつらみの空気を事前に共有できてるのはすごくいいことだなと思った。

RDB THE Right Way ~壮大なるRDBリファクタリング物語~

builderscon.io

• RDBの正しい道とは？
  • RDBの正しい設計
  • RDBと付き合っていく上でどうやって正しい道を歩いていくか
  • DBの寿命はアプリケーションより長い
• モデリングをするために必ずするべきこと
  • データと情報は違う
  • SQLアンチパターンのまえがき
    • 画面に表示するのは情報
    • 情報には目的がある。データは単なる事実
    • データを永続化して蓄えるのに適しているのがRDB、それから情報を生成するのがSQL
  • データ設計と情報設計は分けることが大事
    • Railsとかになれてると、混在しがち（1table1model）
    • データ設計: 事実をどのように記録するか
    • 情報設計: 事実をいかに加工・利用するか
• 情報優先でデータ設計をするとデータに矛盾が生まれる
• ではどうやって設計していくか
  • まずモデリングをする ← めちゃくちゃ大事！
  • いきなりデータ設計せずにER図を書く
• Entityを定義する
  • Entityとは
    • イベント（コト）
      • 事実
      • 5W2HのうちWhenとHow to
    • リソース（モノ）
      • 事実を生み出す元、未来、概念
      • WhenとHow to 以外
• Entityを関連付ける（リレーション）
  • リレーショナルモデルで定義 → 正規化
  • モデリングの前に正規化 → ✕
  • データに矛盾があるというのは正規化できていない
• 論理設計と物理設計
  • モデリングせずにいきなりテーブルを考え始めるのはいきなり物理設計してるということ
  • 物理設計
    • データをシステムとしてどのように保存するか
• 正規化で生じる問題
  • パフォーマンス問題
    • JOIN地獄etc
  • アプリケーションの制約
    • ID必須なのはアプリケーションの都合（ORマッパーの都合）
    • フレームワークの都合でDBマイグレーションが外部キー制約に対応していない
  • システム・アーキテクチャの制約
• データは常に成長する
  • 量は増え質が変化する。正しさを常に問うて設計を変化させていく
  • データベース実践入門おすすめ
• リファクタリング
  • データベースの不吉な臭い→技術的負債
    • チーズと腐った牛乳の違い。一緒くたに技術的負債にしてしまわないように判断する
    • スーパーテーブル作ってませんか？
      • ex. 婚活サービスでいうpartiesテーブル
        • 公開前のパーティー、公開中のパーティー
      • 値によって意味が変わる
      • 特定の列の値で他の列の値の意味が変わる
        • EAVというアンチパターン
  • SQLアンチパターンを読もう。今すぐ読もう
• DBテーブルを把握する上でおすすめの方法
  • table一覧を眺める会
    • チーム全員でただテーブルを眺める
      • 誰も知らないテーブルとかが出てくるｗ

DB設計についてすごく丁寧でわかりやすい内容のセッションだった。論理設計と物理設計を一緒くたにせずきちんとデータと情報を分けてモデリングしてから進めるという話意識しないとできてないケースも多い気がする。データベースの寿命は長いからこそより設計に力を入れるべきというのは納得感ある話だった。とりあえずSQLアンチパターンはすぐ読もう。

その他聞きたかったけど聞けなかったセッション

スライドへのリンクだけおいておきます。正直パフォーマンス計測の話はめちゃくちゃ聞きたかったけど、断腸の思いでAWSピタゴラスイッチを選びました。後悔はしていない。けどめちゃくちゃ気になる。。再放送してほしい。

• なぜエンジニアはパフォーマンス計測しないのか
• Using Chrome Developer Tools to hack your way into concerts
• パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと
• Webサービスにて200週連続で新機能をリリースする舞台裏
• 事前知識なしで理解する、静的検査のいろは

まとめ

今回初参加だったけど、どのセッションも中身が濃く聴講するだけですごくカロリー消費するような内容でした。とても楽しい2日間をありがとうございました。登壇者、運営の皆様お疲れさまでした！

パネルディスカッションのモデレーターを依頼されて準備したこと全て

ご縁あって、こちらのイベントでパネルディスカッションのモデレーターをしてきました。

eventregist.com

これまでパネリストとしての登壇経験はありましたがモデレーターとしてはほとんどありません。さらに訳あって依頼されたのが本番当日の2日前だったためかなりドタバタで準備をしました。

今回の記事ではモデレーターしてどんな準備をしたか、緊張対策のためにやったことなどについて紹介します。

トーク内容については後日logmiさんにて記事にしていただけるとのことだったので、この記事では触れません。

まずモデレーターについてググった

まずやったことはモデレーターについて参考になりそうな記事を片っ端から調べました。

急遽明日のイベントのモデレータをやることになったのでモデレートの技術について調べてたんだけど2012年くらいの記事しかでてこない。モデレータのみなさん記事かいてください狙い目ですよ。

— 香月雄介/ペライチ開発責任者 (@katsukii) 2018年8月28日

思わずつぶやいた通り、モデレーターについての記事自体がそんなに多くありませんでした。ただその中でもこちらの記事は2012年と古い記事ですが、とても具体的で参考になる内容だったので、準備する上で何度も読ませていただきました。

www.publickey1.jp

登壇者についてもググった

モデレーターについての調査と並行してやったのが、パネリストの調査です。準備全体の中でたぶんここに一番時間を使いました。

パネルディスカッションの内容を濃いものにするためには、パネリストの話に対してモデレーターが突っ込んだり深掘ったり疑問をぶつけたりしなければなりません。そのためには大前提としてパネリストの話す内容が瞬時に理解できる必要があります。

ディスカッション中にモデレータが会話の流れを止めてしまうことを避けるためにも登壇者の予習はマストでしておくべきだと考えます。

以下について時間が許す限り調査してEvernoteにまとめました。

• インタビュー記事
• Twitterでの発言
• 過去の登壇資料
• 所属企業、プロダクトの情報

特に今回は有名サービスのCTOの方々だったのでインターネット上から沢山の情報を得ることができました。

以下、調べる上で特に意識したの3つの視点について記述します。調べた内容はA4用紙1枚の資料にまとめ、当日参照できるよう手元に置いておきます。

1. 登壇者の信念を集める

信念というと言葉が強めですが、インタビュー記事などで「◯◯だと思います」といったオピニオンがあればそれを信念と呼んでいます。信念はバックグラウンドにWHYが隠れているので、本番中に深掘ることで深みのある話が聞ける可能性が高まります。

また、登壇者同士で相反する信念がある場合、後述する「対比」でその部分について聞くことでディスカッションにつなげることもできます。

2. 登壇者の得意領域を集める

得意領域というのはその人がインタビューなどで繰り返し喋っているような内容のことです。そこを深掘ることで独自性の高い踏み込んだ話を聞ける可能性が高まります。

3. 登壇者同士対比できそうなことを集める

対比というのは例えば以下のようなことです。

• プロダクトはtoB向けかtoC向けか
• 堅い業種かそうでないか
• CTOはVPoEタイプかテックリードタイプか
• CTOの見ているスコープの広さの違い、役割、現場との距離etc...

これらを調べておくことが本番中のディスカッションで生きてきます。例えば、「今の◯◯さんの話はプロダクトがtoC向けの場合だと思いますが、逆にtoB向けのサービスを展開されてる◯◯さんはいかがですか？」みたいな感じで対比することで話を深掘りやすくなります

主催者との事前打合せ

主催者との事前打合せでは、今回のパネルディスカッションのアジェンダを決めます。（以下の画像は本番で利用したスライドです。）

決める際のポイントとなるのが、主催者の目的と参加者の満足度です。

• 主催者としての今回のパネルディスカッションの成功の定義はなにか
• 参加者はどんな人で何を求めて来るのか

についてヒアリングをしつつ、主催者の目的を達成しつつ参加者満足度の高いものにするという視点でディスカッションテーマを決定します。

特に「自分が参加者だったらどんな話が聞きたいか」という視点が考えやすいと思います。

アジェンダ以外では、当日の段取り、タイムキーピングなどについても確認しておきます。

進行表を作る

主催者との打合せで当日の流れとアジェンダが決まったら、スプレッドシートで進行表を作成します。これは当日の流れをシミュレーションするための自分の練習用のものです。

作るものはシンプルでよくて、アジェンダを縦に箇条書きに並べ、その右側に「アジェンダの振り方」「深掘りたいこと」の列をつくり、上述した登壇者の調査で調べたことをもとに内容を記入しておきます。

• アジェンダの振り方
  • そのアジェンダを誰に何と言って振るかについて記入します。
• 深掘りたいこと
  • そのアジェンダに関して登壇者の持つ信念や、得意領域、対比する相手について記入します。

またアジェンダ同士を矢印で結んで、その横に次のアジェンダに移るときの「口上」を記載しておきます。

シミュレーションする

進行表をベースに練習する

上記で作成した進行表をベースにシミュレーションをします。

それぞれのアジェンダだけを見て「アジェンダの振り方」「深掘りたいこと」をパっと想起できるよう記憶の強化をしておきます。

動画で雰囲気をイメージする

脳内だけでシミュレーションしてると、パネルディスカッション自体の雰囲気がどんな感じか分からなくなってくるので動画で雰囲気を確認しておきます。

パネルディスカッションでググってでてきた動画で比較的明るい雰囲気の動画を選んでモデレーターの様子を観察するととてもいいイメージトレーニングになります。

www.youtube.com

www.youtube.com

登壇者顔合わせ

いよいよ当日。本番30分前に登壇者との顔合わせをします。

ここでそれぞれのアジェンダに対してどのパネリストから面白い話が聞けそうかについてヒアリングします。

「このアジェンダは◯◯さんなにか話せるネタ持ってますか？」という感じで直接確認して事前に作っておいた進行表にメモしておきます。

ここでおすすめしたいのが、各パネリスト、特に初対面のパネリストとはしっかり会話をしておくことです。

どんな感じの人なのか、コミュニケーションするときの雰囲気などをある程度つかんでおくことで、本番中に心の余裕ができます。

本番

いよいよ本番です。壇上に上がってからの流れとしては以下の形が一般的かと思います。

• イベント全体の司会者からの紹介
• モデレーターの挨拶
• パネリストの自己紹介
• アジェンダに入る

モデレーターの挨拶については一言だけ「本日モデレーターとして進行を務めさせていただきます。株式会社ペライチで開発責任者をしています、香月と申します。よろしくお願いします。」くらいでいいかと思います。そのあとパネリスト一人ずつ、簡単な経歴と現在の仕事について自己紹介をしてもらいます。

自己紹介のときは、それぞれの所属と名前がわかるスライドを出しておくとわかりやすくていいです。

そのあとアジェンダに入るわけですが、その前に今回やってよかったと思ったのが会場アンケートです。「エンジニアの人〜？」「スタートアップの人〜？」という質問で挙手してもらって会場の属性確認をするのです。

これによってどんな属性の人が来ているのかパネリストが知ることができるので、よりオーディエンスが興味のある話をしてもらいやすくなります。

あと、その流れでアイスブレイクもできます。ムダに「朝ごはん食べてきた人〜？」という質問を入れてみたら全体的に笑ってくれて空気がほぐれたように感じました。おすすめです。

本番中のモデレーターの頭の中

さて、アジェンダに入ってからはモデレーターは頭の中で主に以下の3つのことを考えなければなりません。

1. アジェンダの振り方、深掘り方
2. 次にどのアジェンダを話すか
3. 時間配分

1. アジェンダの振り方、深掘り方

アジェンダの振り方

まずアジェンダの振り方についてですが、コツはそのテーマを得意とする人に名指しで振ることです。例えばセキュリティについてであれば「FOLIOさんは金融系のサービスなので脆弱性やセキュリティには特に気を配ってると思いますが特に取り組んでいることはありますか？」みたいな感じです。

全体に対して抽象的な振り方をしてしまうと、一人ずつ広く浅く意見を述べるような形になってしまい深掘りがしづらくなるためです。

話の深掘り方

アジェンダを振って「WHAT（何をやっているか）」が聞き出せたら、「HOW（どうやっているか）」「WHY（なぜやっているか）」について深掘っていきます。

一例ですが「うちの会社でも似たような取り組みをしてますが、こういうところを課題に感じています。その点どう対応されてますか？」（HOWの深掘り）といった感じで、モデレーター自身の視点で疑問やツッコミを投げかけていきます。

注意しなければならないこととして、深掘れば深掘るほど一人のパネリストが喋る時間が長くなって時間を圧迫していきます。そのため適度に喋ってもらったら事前準備の「登壇者の調査」にて調査した「対比」を使って他の人にも話を振ります。

このようにしてて、「アジェンダを振る→深掘る→他の人に振る/対比する→次のアジェンダに移る」という流れでまわしていきます。

2. 次にどのアジェンダを話すか

本番中はモデレーターは終始パネリストと会話し続けなければならないため、「次にどのテーマについて話そうかな〜」なんてじっくり考える暇はありません。口では会話しながら、頭の中では全体の流れを整理しておく必要があります。

僕の場合は慣れてない中でのぶっつけ本番で上記をこなす自信がなかったので、事前にシミュレーションしておくことで対処しました。基本的に本番中ディスカッション全体の流れをコントロールすることは不可能に近いですが、アジェンダベースでこの話のあとはこれが振りやすいという個別の流れについては想定することは可能です。

準備段階で作成した進行表をベースにシミュレーションしておくことでよりスムーズな流れを作れます。

イケてないのが、「そろそろお時間がアレなので、次のアジェンダに移りたいと思います」と話の流れを切って進めることです。（僕は今回これをやってしまいましたが。。）

3. 時間配分

今回のパネルディスカッションは全体で40分でしたが、結果的には3つか4つくらいのアジェンダで終了しました。つまり、だいたい1つのアジェンダで10〜15分（パネリスト1人につき3〜5分）くらいの時間を使ったことになります。正直全然時間が足りなくて焦りました。

なので上記の通り全体の時間とパネリストの人数から逆算して事前にアジェンダを組むことが大事になります。ただしどんな話の流れになるかわからないのでアジェンダ自体は多めに用意しておく事をおすすめします。

また、本番中に残り時間がわかるようにしておくことも重要です。壇上から見える位置に時計はあるかどうか、残り時間の合図を出してくれる人はいるかどうかは事前打合せでかならず確認しておく必要があります。最悪自分の時計でタイムキーピングできるようにしておきましょう。

おまけ: コンディション調整について

最後に、本番に向けたコンディション調整について書きたいと思います。

睡眠

本番前日は準備が不十分だと感じても睡眠時間を優先します。睡眠不足は当日緊張を増長させることにつながるからです。

夜更かしはその前日までに済ませておきます。

食事と水分補給

本番直前に消化のよくないものを食べると血液が胃や十二指腸の方にいくため脳の働きが悪くなります。逆に空腹すぎるのも集中力の妨げになるためNGです。

なので、本番前1時間前くらいに手軽に摂取できて胃に負担がかからない軽食（バナナとかウィダーインゼリー的なやつ等）をとることをおすすめします。僕は会社に常備してあるプロテインを飲んでから会場に向かいました。水分補給については30分前くらいまでに済ませておきます。

コーヒーを控える

コーヒー（カフェイン）は交感神経を優位にし脳を覚醒させる作用があり緊張を促進させるため、当日は控えた方がいい飲み物です。僕も依頼を受けた本番2日前からコーヒー断ちをしてました。

しかし思わぬ事態が発生。コーヒーを毎日結構な量飲んでるせいで当日になって離脱症状による頭痛と眠気に襲われてしまったのです。

慌ててコーヒーを一口だけ口に入れたら予想以上にスッキリして難を逃れました。日常的にコーヒーを飲んでいる人がカフェイン断ちする場合は1週間くらいかけて徐々に減らすべきだと学びました。

しかしカフェインって麻薬ですね。。

自意識をなくす

半分精神論のような話ですが、僕は緊張の原因は自意識にあると考えています。「自分が恥をかきたくない」「失敗して自分の評価を下げたくない」と思っている限り緊張します。

逆に相手のニーズを満たすことだけに意識が集中できていれば緊張している暇なんてないはずです。

じゃあ具体的に何をするかというと、今回のパネルディスカッションの目的はなにか、そのためにすべきこと、意識すべきことなどを白紙のA4用紙に1分間で思いつく限り書き出します。これを10セットくらい繰り返します。書き出すことにより意識のベクトルを内側から外側に向けて上げることで緊張を和らげることができます。

ちなみにこれは「ゼロ秒思考」という思考のトレーニング方法で、上記のシチュエーション以外にも一人でアイデアを発散したいときなどに使えるのでおすすめです。

ゼロ秒思考 頭がよくなる世界一シンプルなトレーニング

まとめ

以下、準備でやったことをまとめます。

• モデレーターについてググる
• 登壇者についてググる
  • 登壇者の信念を集める
  • 登壇者の得意領域を集める
  • 登壇者同士対比できそうなことを集める
• 主催者との事前打合せ
  • アジェンダを決める
    • 主催者の目的はなにか、参加者はどんな話を聞きたいか
  • 当日の段取り、タイムキーピングも確認しておく
• 進行表をつくる
  • アジェンダを箇条書き
  • アジェンダの振り方
  • 深掘りたいこと
• シミュレーションする
  • 進行表をベースに想起
  • 動画でイメトレ
• 登壇者顔合わせ
  • 持ちネタのヒアリング
  • 初対面のパネリストとは会話を

終わりに

長々と書きましたが、以上がパネルディスカッションのモデレーターとして今回準備したことの全てです。今回慣れないモデレーターに挑戦してみて実感したのは、パネルディスカッションのモデレーターにはすごく高度なスキルが求められるということです。パネリストとはまた全然別の筋肉が必要だなと思いました。

準備から本番までとても濃密な時間でとても多くのことを学ぶことができました。また次の機会に繋げられるように沢山学んでより進化していきたいと思います。

お声掛けいただいたPlug and Play矢澤さんはじめ関係者の皆様、パネリストの御三方、拙い進行にも関わらず終始和やかな空気で聞いてくださった参加者の皆様に感謝の気持ちでいっぱいです。ありがとうございました！

追記:

logmiさんに記事にしていただきました！

logmi.jp

Serverless Meetup Tokyo #10に参加してきた

最近キャッチアップしてるサーバーレスの事例が知りたくて「Serverless Meetup Tokyo」に参加してきました。全体的に具体的な内容が多くとても参考になりました。

serverless.connpass.com

サーバーレスなマルチテナントSaaSの権限管理

• サーバーレスでのマルチテナントの権限管理をCognitoとIAMで実現している
• 道に迷って到着が遅れたため発表内容は最後の方しか聞けず。。

Software Testing in AWS IoT with The Power of Python

• IoTを使ってシステムでのインテグレーションテストにLambdaを活用しているという話し
• AWS IoTでIoTデバイスからデータ収集。それをKinesis Data Streams経由→Lambda→DynamDBに。
• インテグレーションテストはモック系ツール（LocalStack, moto）を用いる。（ネットワーク遅延を防ぐため）

IoTについて知らないことばかりで面白かった。モック系ツール初めて知ったので試してみたい。

BtoBスタートアップとサーバーレス

• SaaSサービス向けの顧客行動分析ツールを提供。
• カスタマーサクセス（=いかにチャーンレートを下げるか）のためのデータマイニングにサーバーレスを活用している話
• ログ収集の可用性/レスポンス速度を重視
• プロダクトごとに異なるさまざまな型のデータを扱えるようにDynamoDBを利用し、ElasticSearchを用いて可視化している

行動データ解析におけるLambdaの使い所の事例が聞けてよかった。また技術的な部分だけでなくユーザーの行動データ分類の仕方などが参考になった。

LambdaとSQSでhttp://wwdjapan.com のアクセス負荷を下げた話

（資料公開なし）

• メディアのアクセス負荷をサーバーレスで解決したという内容
• EC2にワードプレスを載せて、RDS書き込みを行っていた。メディアへのアクセスログも全て同一のRDSに → 大量アクセス時にいつも落ちてしまう
• キューイングで解決。構成をLambda + RDS → Lambda + SQS + RDS
• RDSにインサートが走ったらSQSで通知が来るようにした。
• 記事表示したら Lambda → SQSでQueで溜め込んでから → RDSに書き込み。
• コネクションは常に1ですむように。CMS落ちなくなった。

すごいわかりやすい事例だった。SQSを活用したサーバーレスの事例はよく聞くので相性よさそう。

まとめ

• 全体的に具体的な事例が沢山聞けて勉強になった
• 全員の発表が終わったら懇親会もなくサクッと帰る感じは嫌いじゃないと思った
• メモできなかった発表の方すみません

GitHubリポジトリにセキュリティ脆弱性の警告が表示された

GitHubでリポジトリ開いたらこんな表示が。

We found a potential security vulnerability in one of your dependencies. A dependency defined in Gemfile.lock has known security vulnerabilities and should be updated.

（翻訳）依存関係の1つに潜在的なセキュリティ脆弱性があります。 Gemfile.lockで定義された依存関係には既知のセキュリティ脆弱性があり、更新する必要があります。

クリックしてみてみると、sprocketsのバージョンが古いとのこと。

以下でアップデート。

$ bundle update sprockets

アップデートしたGemfile.lockをコミットしてpushしたら無事アラートは消えました。

まとめ

見たことない警告表示でしたが、2017年から運用開始された機能とのこと。

GitHubがユーザーコードの安全でない依存性を警告、コードの見つけやすさも改善

こういった形で通知してもらえるのはありがたいですね。

dotfilesリポジトリでPCの設定ファイルをクラウド管理する

最近vimの勉強をしてる中で.vimrcなどの設定ファイルをGitHubで管理する方法を知ったので記事にしようと思います。

dotfilesとは

dotfilesというのは「.vimrc」「.bash_profile」などの文字通りドットからはじまる設定ファイルを指します。これらの設定ファイルをローカルだけで管理するのは心もとないのでGitHubにリポジトリを作ってクラウド管理しようというものです。

この管理方法であればPCが新しくなっても環境設定をいちからやり直す必要がなくなります。

やり方

1. GitHubにてdotfilesリポジトリを作成する

GitHubにてdotfilesリポジトリを作成し、PCのホームディレクトリにしcloneします。

2. 管理対象のファイルをdotfilesディレクトリに移動

cloneしたdotfilesディレクトリに管理対象のドットファイルを移動します。以下のようにmvコマンドで移動してもいいですし、Finder操作でも構いません。

$ mv .vimrc dotfiles
$ mv .bash_profile dotfiles
…

僕はコマンド打つのが面倒だったのでFinderで複数選択してファイル移動させました。

※ うっかり秘密鍵などを移動してしまわないよう必ず目視確認しながら作業することをおすすめします。

3. シンボリックリンクを貼る

一つひとつのファイル、ディレクトリに対してlnコマンドでシンボリックリンクを貼るのは大変なのでこちらはシェルスクリプトを使います。このファイルもdotfilesディレクトリの直下においておきます。

#!/bin/bash

for f in .??*
do
    [[ "$f" == ".git" ]] && continue
    [[ "$f" == ".DS_Store" ]] && continue
    ln -snfv ~/dotfiles/"$f" ~/
done

4. GitHubにpushする

GitHubのdotfilesリポジトリにpushして完了です。

参考までに僕のリポジトリを載せておきます。

github.com

参考リンク

上記手順はこちらのリンクを参考に作成しました。 https://qiita.com/okamos/items/7f5461814e8ed8916870 https://qiita.com/b4b4r07/items/b70178e021bef12cd4a2

日々の運用方法

設定ファイルに新しい内容を記述したらcommitしてGitHubにpushします。また、新しいPCに設定を反映するときはリポジトリをcloneした上で上記手順の2と3を行えばOKです。

まとめ

バックアップという意味だけでなく、設定ファイルにいつどんな追加をしたのかが追えるようになるのは便利そうだと思いました。

リモートワークをやらない理由

うちの会社は基本的にリモートワークを積極導入していません。 もちろん災害時や悪天候、家庭の事情などでやむを得ない場合はリモートワークOKにすることはあります（この夏は35℃以上の猛暑日はリモートワーク推奨にしました！）が、積極的にやらない（やりたくない）と思っている理由について個人的意見をまとめてみました。

リモートワークのメリット

まず、言うまでもなくリモートワークには会社にとっても従業員にとってもメリットがたくさんあります。

• 通勤にかかる時間、エネルギーを節約できる
• 身だしなみに気を使わなくていい
• 同期型コミュニケーションが減るため作業に集中できる
• 子供が熱を出したとかに柔軟に対応できる
• 会社はオフィスの座席を用意しなくてすむ（フルリモートの場合）
• 採用の機会が広がる

などです。

リモートワークをやらない理由

ではなぜ積極的にとりいれないかというと、主に以下の理由です。

カルチャー醸成における不具合

急成長を目指すスタートアップ企業で働いているとさまざまなイベントが起こります。

• 移転してオフィスが大きくなる
• テレビに取り上げられてサーバーが落ちる
• 半年かけて作った新機能をリリースする
• KPIを達成して喜びを共有する
• キャッシュが尽きそうになる

このようなイベントを現場で体験できるのはベンチャーで働く上で大きな機会だと思います。

目の前の出来事に対してどんな判断をくだすのか、なぜその判断なのか、どんな温度感なのか等、その場にいるからこそ伝わる非言語情報がたくさんあります。そしてそれは同じ場所にいるからこそ価値観（=判断軸）として浸透し、それが組織のカルチャーとして形成されます。また働く個人にとってもそのような経験は暗黙知として資産になります。

価値観が浸透することでコミュニケーションコストが下がり、結果的にチームワークの生産性が上がることを考えると、リモートワークはカルチャーづくりという面で機会損失が大きいと考えます。

マネジメントと評価での不具合

• 報連相が適切にできる自立した人でないとマネジメントコストが大きくなる
• そういう意味で、社会人経験が浅いメンバーとのやりとりはよりコストが大きい
• また評価が成果ベースになるためプロセスが無視される

成果というのは適切な行動から生まれるので、役職的にマネージャーレイヤーより下に位置するメンバーに対しては結果だけでなく行動も評価してフィードバックをする必要があります。特にマイクロマネジメントが必要な新入社員や学生インターンに対してプロセスを評価してあげられないのは育成の機会を逃しているといえます。

コミュニケーション面での不具合

• 対面だと一瞬で済む内容の共有に時間がかかる
• 心理的安全性が低いチームだとよりつらみが大きい

例えばチームビルディングがまだ済んでいないチームは対面より更にやりづらさある気がしています。テキストでのコミュニケーションは対面より冷たく感じやすいので、ちょっとしたフィードバックでも受け手にとっては怒ってるように感じてしまうことってあると思います。そういう意味では少なくとも互いのことをある程度分かっていて気兼ねなく雑談できるような関係性ができていないと、コミュニケーションにかかるコストが大きいと感じます。

まとめ

デメリットにフォーカスして書きましたが、リモートワークはいい面もたくさんあります。会社として柔軟で多様性のある組織に成長するためにも避けて通れないとは思っているので、デメリットを回避する方法を考えながら部分的に取り入れていきたいと思っています。

July Tech Festa 2018に参加して戦略思考などについて学んできた

インフラの祭典July Tech Festa 2018に参加してきました。

2018.techfesta.jp

一日を通して参加しましたが、各社具体的な事例をたくさん聞けて参考になりました。また技術以外にも面白そうなテーマについて扱ったセッションが多くありとても楽しめたのでメモしておこうと思います。

組織の生産性を上げる役割「VP of Engineering」とは？

メルカリ、ハートビーツ、Gunosy3社それぞれのVPoEが、役割と責務についてパネルディスカッション。

• 3社共通なのは技術の責任はCTO、組織づくりとマネジメントの責任はVPoE。
• ただし、VPoEにどこまで任せるかについては会社によって定義が結構バラバラ。
• VPoEが組織、マネジメントに加えて事業責任まで持つとなると組織がスケールするに従ってVPoEの責任がかなり大きくなってしまうというのはありそう。
• そんな中でCTO, VPoE, VPoPを分けて運用しているというGunosyの職務分担はうまく分けてる印象だった。解釈が合ってるかはわからないけどVPoEは縦軸（組織）の責任を、VPoPはを横軸（事業）の責任を負うというのは綺麗だと思った。

少し話はそれるけどIVSのCTONightで課題についてディスカッションすると毎回といっていいほど組織やマネジメント採用の話が上がってくるのは、CTOが実質VPoE職務を兼任するという企業が多いのだと思う。

急成長するスタートアップの開発組織においてCTOの責務がどうしても大きくなってしまう問題はあるので、組織の成長に応じてVPoEを役割として立てる会社が増えてくるのは合理的な流れだなと思う。

副業で収益化を目指す！月数百円から始めるWebサービスの立ち上げから運営まで

• 収益化するためにはとにかく支出を削る。（逆説的だが）そのためには身銭を切ってどケチになる。人は自分のお金じゃないと節約できない。
• 一人で作ることが大事。その理由は「人的コストが最小で済む」「意思疎通コストがゼロ」「リソースが最小のため単機能にせざるを得ない（運用・開発コスト減）」こと。
• 「大きな問題」は解こうとしない

中でも一人で作ることが大事という話は的を射ているなと思った。普段スタートアップをやってていかに人を巻き込むかばかり考えてるせいで忘れがちだけど、どこかでみたポール・グレアムの「スタートアップは避けられる限り採用するな」という主張ってまさにこういう事だった気がする。あと、大きな問題を避ける意思決定は後述する戦略話と重なるところがありおもしろかった。

イゼルローン要塞攻略に学ぶエンジニアの戦略思考

The strategy from the Iserlohn fortress at JTF2018 from irix_jp

• 戦略は戦う前の話。戦術は戦う時の話。
• どのレイヤーの話をしているのかを意識するのは重要。
• ツール（戦術）にこだわりすぎると手段の目的化が起こって上位レイヤーの大切なことを見失う。
• 個人レベルの話でいうと特定のスキルだけ発達させる（芸の絶対化というらしい）のはキャリアを考えても危険
• 技術の変化が早く、習得したスキルがあっという間にレガシーになるIT業界では特に言えること。そのため常に成長し続ける工夫をすることが大事
• その上で何を学べばいいか、上位の戦略レイヤー（世界観、目指すべき状態）からブレイクダウンさせて考えよう

（スライドより参照）

普段よく使うけど言葉として正確に理解してはいない「戦略」について考えるいい機会になった。思考のフレームワークとしても戦略学、戦略のフレームワークは改めて勉強してみたいと思った。

ソフトウェアで構築する成長し続けるインフラストラクチャとメルカリの挑戦

• 最初はさくらのVPSでリリース
• JPリリースから1年半という恐ろしい速さでUS版リリース。
• チーム、組織のスケーラビリティを高めるためにマイクロサービス化
• QAとデプロイがボトルネックになりがちだったものをマイクロサービス化で解消
• 国によってAWS、GCPなど使い分けている

利用技術

• Container/Docker
• Kubernetes
• Spinnaker
• Terraform

まとめ

メルカリに限らずKubernetesについて取り上げてる会社が多く事例が沢山聞けて参考になりました。また、それ以外にも知らないサービスがたくさん聞けたのでキャッチアップしようと思います。

人見知りのための懇親会テクニック

勉強会やカンファレンスの懇親会が昔からあまり得意じゃないんですが、回数をこなすうちにそれなりに有意義な過ごし方ができるようになってきた気がしてます。

今週末もJuly Tech FestaというITイベントに参加するのですが、参加するにあたって自分なりに心がけていること結構あるなと思ったので、まとめてみようと思います。

事前準備

目的とKPIを決める

懇親会の何が苦手かって、中身のない会話を延々と続けることになったり、逆に誰とも話す機会を得られず孤独感を感じながらスマホをいじる羽目になったりすることなんですよね。

で、それを避けるには自分から話しかけることが大事で、目的を事前に設定し意識することで少なくとも漫然と過ごすことは防げるかなと思っています。

目的というのは例えば以下のようなものです。

• 勉強会の技術テーマをディスカッションを通して深掘りする
• 採用候補者を見つける。
• 会社やサービスの説明をしたりビジョンを話す練習をする。

で、KPIは上記目的を達成するために「5人以上に話しかける」とか「2人以上とランチの約束をする」とか定量的なものを設定します。

学生時代ティッシュ配りのアルバイトしたことありますが、目的があると不思議と人に話しかけるのって苦じゃなくなるんですよね。

自分がギブできるネタを用意しておく

こう書くと敷居が高い感じがしますが、要は自分の話せるネタを用意しておけばいいのです。

懇親会で初対面の人と話すときにやってしまいいがちな失敗が質問攻めです。これはシンプルに自分から喋れることがないから起こることだと思っています。

話し好きの相手であればそれでもいいのかもしれませんが、質問ばかりだと相手に得るものがないため辟易されてしまう可能性が高いです。

そうならないためにも自分が喋る内容を事前に準備しておくのがおすすめです。

• 名刺交換するときの自己紹介
• 仕事で取り組んでいること
• なぜこの勉強会に参加したのか
• 最近興味のある技術テーマ

などです。

これらを自分から先に話した上で相手にも問うのです。互いに興味のある話題につなげることができれば自然と盛り上がります。

ここで、話題としておすすめなのがその日の勉強会のテーマです。

事前に勉強会で扱われるテーマについて技術調査をし、知見を深めておきます。そのテーマに興味がある人ばかりが参加しているはずなので、こちらからギブできる話題としては絶好のネタとなり話も弾みます。

当日の動き

登壇者に話しかける

勉強会に参加するメリットとして、登壇者の生のスピーチを聞けたり質問できたりすることが挙げられると思いますが、懇親会はそのメリットを享受する絶好のチャンスです。

勉強会中登壇者の話でわからなかった箇所や詳しく聞きたいと思った箇所をメモしておき、懇親会のときに質問するのです。

登壇する立場からすれば、興味を持って話を聞きにきてくれる人には親切にしたくなりますし、スライドではオープンにしづらい裏話やスライドに盛り込めなかった内容とかも話したくなります。

またここで事前準備で調査しておいた勉強会テーマが生きてきます。質問するだけでなく登壇者と議論を深めることができれば間違いなく有意義なものになったと言えるでしょう。

食事に負けないようにする

これは半分精神的な話です。懇親会では大抵の場合軽食が出されますが、ここに罠が潜んでいます。

仕事終わりで登壇者の話をひととおり聞ききった後ということもあり、懇親会が始まる頃にはだいたいかなり空腹状態です。そしてそんな状態で目の前にピザがでてきたら本来の目的を忘れて食べることに意識が向いてしまいます。

さらに、料理を食べて満腹中枢が刺激されると今度は逆に落ち着いてしまいダラダラ過ごしてしまいがちになります。

なので、できれば食事はダラダラしないようサクッと済ませるか、食べないくらいのスタンスでいましょう。

コツとしては、あらかじめ空腹にならないような工夫をしておきます。勉強会に参加する前に自分で軽食をとっておくのです。サンドイッチとかカロリーメイトとかなんでもいいです。

話をうまく切り上げる

話を自然な感じでうまく切り上げるのって結構コツがいるなと思っています。特に相手に会話のペースが握られる事が多い人見知りとしては終わり時を自分から作ることが難しくなります。

話を切り上げる時は、話のキリがいいタイミングで以下のような文句を言ってからさっとその場を離れるのがおすすめです。

• 「ちょっとお手洗い失礼します」
• 「他の方にも挨拶してきますね」
• 「飲み物とりにいってきます」
• 「よかったらまたお話しましょう。Facebook申請してもいいですか？」

さっさと帰る

気分が乗らないときや、逆に今日はもう目的が達成できたと思ったときなど、これ以上得られるものがないと思ったらその時点でさっさと帰るのも大事なことだと思います。

別に最後までいなければいけないルールなんてないですし、早退したからといって主催者はほとんど気にしてないです。

ダラダラ過ごすことになるなら、その時間で家でコード書いたり技術書読んでた方がずっと有意義な時間になります。

まとめ

ということで、普段意識してることをまとめてみました。使ってみていただけると幸いです。

プルリクエストを出す際に意識してほしいこと

最近コードレビューをする機会が多いのですが、プルリクエストの中でもレビューしやすいものとそうでないものがある事を実感しています。

というわけで、レビュアーとしての観点からどんなプルリクエストだと助かるのかについてまとめてみました。上から重要だと思う順に書いています。

1. 何を実現したいのかを書く

そのプルリクエストで何を実現したいのかのインプット情報が多いほどレビューしやすくなります。例えば以下のような項目です。

概要、目的、要件、設計、テストケースetc...

また、併せてどのような観点でのフィードバックを求めているかも伝えられると親切です。

レビュアーに対してだけでなく、あとからチームに加わったメンバーが読んだときにも理解しやすくなります。

リポジトリ直下に PULL_REQUEST_TEMPLATE.md という名前のファイルを配置することでプルリクエストをつくるときのフォーマットを設定できるので、運用の際はそれを活用するといいと思います。

2. プルリクエストの粒度はなるべく小さくする

変更の差分が数十ファイル以上もあるようなプルリクエストはレビュアーの精神をとてもすり減らします。

逆に粒度が小さいほどレビューする方も気持ち的に楽なのですばやく取り組むことができます。

感覚的には10ファイル以内に収めてもらえると助かります。

なぜプルリクエストが巨大になるのか？

設計が完了する前にコードを書き始めることがだいたいの原因かなと思っています。どこで分割していいかわからないまま結局一つのプルリクエストにすべてが収まってしまうのではないかと。

設計が完了してイシューが分割できていればプルリクエストも細かくできるはず。いやほんと、差分ファイルが多すぎるのは見るだけで疲弊します（切実）。

3. 自らコメントをつけておく

実装者がプルリクエストのレビュー依頼を出す前にあらかじめ補足事項や相談をコメントしておきます。例えば以下のようなコメントです。

• 「ここは◯◯の意図でこのような実装になっています。」
• 「ここはこうしたけど◯◯の点で問題はないでしょうか。」

このようなコメントはレビュアーの理解を助け、設計における建設的な議論にもつながるため積極的に行うべきだと考えます。

4. 綺麗なコミットログをつくる

プルリクエストの粒度を小さくしたほうがいいと書きましたが、やむを得ず差分の量が多くなってしまう場合もあると思います。

そういったときにコミットログが綺麗だとストーリーに沿って順を追ってレビューできるためとてもやりやすいです。逆に複数の変更内容を1コミットにまとめられるととてもレビューしづらいです。

コミットメッセージの内容

コミットログに書くコミットメッセージは以下のような感じでサブジェクトに「変更内容（What）」を、メッセージに「変更理由（Why）」書きましょう。変更理由があることで、ソースコードから書き手の意図を頑張って読み取るコストが省けます。

1行目：変更内容の要約（タイトル、概要）
2行目 ：空行
3行目以降：変更した理由（内容、詳細）

参考: Gitのコミットメッセージの書き方

まあこれら関しては正直毎回いちいち綺麗にするの大変なので、大量の差分が出たときだけはせめてやってほしいという感じです。

Status checkはクリアしとこう。

あれ、大丈夫？ってなるので。

クリアしてなくてもいいけど、その場合は理由を書いておいてもらえると助かります。

View変更のスクショを貼る

Viewを変更している場合はBefore, Afterのスクショを貼ってもらえると動作確認する手間が省けて助かります。

まとめ

少しの工夫を加えるだけで何倍もレビューしやすさが変わるので、ぜひ参考にしていただけると幸いです！

勉強を1日30分習慣化する方法

「1日30分を続けなさい！」という本を読みました。いかに勉強を習慣化し成果を上げるかについての方法論が書いてあり、勉強時間の確保に課題を感じる忙しいエンジニアにとっては特に参考になる本だと思いました。

｢1日30分｣を続けなさい！Kindle版: 人生勝利の勉強法55

勉強の成果において一番重要なのは「勉強時間」

本書では長期的に勉強で成果を上げるために必要な要素は以下であるとし、特に勉強時間の確保が大事だとしています。

勉強の成果 = (教材の質) × (集中力) × (勉強時間の2乗) + (過去の勉強の蓄積)

教材の質よりも勉強時間の方が重要という点は言われてみればなるほどと思いました。

勉強の成果はしばらくすると累積効果が効いてくるので、ある一定の時期を過ぎると急激に勉強の成果が表れます。それは半年かもしれませんし、1年かもしれません。大切なことは、「勉強の成果はすぐには出ない」ということを知りつつ、日々勉強を続けることです。

脳科学の観点からも、知識が増えるほど脳が無意識にパターン認識できるようになるため勉強の成果は累積効果により勉強時間に応じて指数関数的に上がっていきます。そのため、最初はちんぷんかんぷんの内容も積み重ねることによってわからないことがある日突然わかるようになったりします。

習慣化するためには痛みを避ける

長期的に勉強時間を最大化するには習慣化することが不可欠です。本書ではそのための方法の一つとして不快な状態での勉強を避けることが大事だと述べられています。

脳の行動パターンは非常に単純です。

1. 痛みを避ける
2. 快楽を得ようとする

イヤイヤ勉強するということは、脳にとっては痛みになるわけです。すると、脳は痛みを避けようと、勉強をしないように指示を出し、勉強が長続きしなくなります。

これは非常に大事で、不快に感じることって無意識に脳が拒否するため習慣化できません。特に脳は変化を嫌うため新しい事をはじめようとするときはどうしても負荷を感じます。一度習慣化してしまえばなんということはないですが、新しく習慣を作ろうと取り組みはじめるときこそ気をつけなければと思いました。

また、本書ではこうも言っています。

長期間勉強を続けていると、どうしても「最近は勉強する気にならない」とか「気分が乗らない」という時期が必ず来ます。（中略）このような場合は、思い切って2～3日全く勉強に手を付けないことをおすすめします。そうすると、3～4日目には「最近勉強していないので、中期目標が達成できないぞ。まずい」という焦りの感情が起こりますから、そうしたらまた勉強を再開します。

まとめ

上記以外にも勉強を通して高い成果を上げるための具体的な方法論として、動機づけから時間の捻出方法、食事、睡眠のコントロールまでさまざまな内容が記載されておりとても参考になりました。

ちなみに本書では通勤時間にオーディオブックを聞くという勉強法がありましたが、過去に書いたKindleの読み上げ機能がとても役立つと思ったのでリンクしておきます。 katsuki.hatenablog.com

ということで、総じていい本でした。特に資格試験を受ける人や勉強を習慣化したい人にはご一読をおすすめします！

｢1日30分｣を続けなさい！Kindle版: 人生勝利の勉強法55

感謝を込めてKobitoのデータを移行した

KobitoというMarkdownエディタをスニペットツールとして愛用しているのですが、2017年の12月にサポート終了し新たなダウンロードもできなくなったのですね。

まあそれ以降も気にせず使っていたのですが、新しいPCを購入したため中のデータを別のツールに移行せざるをえなくなりました。

どうしたものかと思いとりあえず検索してみたところ、同じ課題を自作スクリプトで解決している方を発見。 https://qiita.com/jnchito/items/3a6861c179e2ab4a28a2

QuiverというMarkdown形式対応のメモアプリに移行するというものです。

早速スクリプトをCloneし、動かしてみました。

手順

1 ) 手元にソースコードをCloneする。

git clone git@github.com:JunichiIto/kobito-to-quiver.git 

2 ) リポジトリのルートに移動し、Kobitoのバックアップデータを所定ディレクトリにコピー

cd ~/kobito-to-quiver
cp ~/Library/Containers/com.qiita.Kobito/Data/Library/Kobito/Kobito.db ./db 

3 ) gemをインストールし、バックアップデータをもとにoutputディレクトリにMarkdownファイルを生成

bundle 
bundle exec rake export 

4 ) Quiverを起動 > File > Import > Markdown で、上で生成したMarkdownファイルをすべてインポートする。

5 ) 上記によりQuiverデータとして生成されたqvnotebookディレクトリの名前を確認（6E2E7794-D4B5-48F6-AB34-B8DBB09DB2EB.qvnotebookのような名前のものがそれ）

ls -lt ~/Library/Containers/com.happenapps.Quiver/Data/Library/Application\ Support/Quiver/Quiver.qvlibrary/ | grep .qvnotebook 

6 ) 所定のqvnotebookディレクトリ配下に、上記ディレクトリをコピー

cp -r ~/Library/Containers/com.happenapps.Quiver/Data/Library/Application\ Support/Quiver/Quiver.qvlibrary/6E2E7794-D4B5-48F6-AB34-B8DBB09DB2EB.qvnotebook ./qvnotebook 

7 ) 記事タイトルとタグを更新する処理を走らせ、Quiverデータにコピー

bundle exec rake update_qvnotebook 
cp -rf ./qvnotebook/6E2E7794-D4B5-48F6-AB34-B8DBB09DB2EB.qvnotebook ~/Library/Containers/com.happenapps.Quiver/Data/Library/Application\ Support/Quiver/Quiver.qvlibrary/ 

無事、Quiverに移行完了しました！ちなみにruby2.4以上と書いてましたが、ruby2.3.3でも動きました。

Kobitoのおかげで得られたもの

Kobitoはスニペットツールとしてとても重宝していましたが、それだけでなくQiitaに投稿するきっかけを作ってくれました。

記録したメモをワンクリックでQiitaに投稿する機能があるため、メモった内容をカジュアルに公開することができるのです。気づいたらKobitoにメモった技術調査の内容やスニペットをQiitaに公開するのが習慣になっていました。

おかげで過去たくさんのリアクションをもらう事ができました。中には感謝のコメントをくれる人や間違った内容を指摘してくれる人もいて自らのアウトプットを世の中に公開する意義を大いに感じることができました。

人から反応をもらえるのは励みになります。 些細な内容だとしても、世の中に1ミリでも還元できているという実感が得られるからです。

KobitoとQiitaがあったから、些細な内容でも恥ずかしがらず公開してみよう！というメンタリティを得られたように思います。

サービスとしては終了してしまったKobitoですが、得られた教訓を胸に今後もアウトプットを続けたいと思います。

開発チーム勉強会はじめました

先月から新しい取り組みとして隔週に1度の開発チーム勉強会をはじめました。輪読会形式で進めているのですが、なかなかいい感じに進んでいるのでどんな風にやってるか紹介します。

やり方

各回テーマに応じた内容について書籍を使って学習します。

1. 勉強会の日時、テーマを決める

• 業務時間内でみんなが集まれる日時を決めます
• 学びたいテーマをメンバーからヒアリングして決めます

2. 参加者に本を配る

• テーマについての書籍を会社で人数分購入し、参加者に配ります

3. 当日までに読んできてもらう

• 業務時間内に読んでもらっても構いません

4. 当日、学びになった箇所についてディスカッション

• 読んできた内容で印象に残った箇所や学びを自由に発表し合います。
• 最後に次回のテーマと日時を決めて終わります。

どんなテーマにするか

以下にのような内容がいいんじゃないかと思っています。

• 直近の仕事で取り組むべき課題に関するもの
• チーム全体で伸ばしたいと思っている技術
• その他一般的にエンジニアとして身につけておくべきスキル etc....

なぜ輪読会か

一番の理由は準備が比較的楽だからです。参加者は最低限渡された本を読んでくればいいので準備が大変で続かないという事が生じにくいのではないかと思っています。

また、以下のような効果も感じています。

発表を通して学習効果が高まり新たな視点が得られる

輪読会のいいところはただ書籍を読むよりもインプットした知識の理解が深まることです。人に説明する行為を通して情報が頭の中で整理され、より深く記憶に定着します。また、自分とは異なる視点からの意見を聞いたりディスカッションしたりすることで知識が強化され、多様な考え方を身につけることにもつながります。

チームのコミュニケーションの質向上

さらに、実際にやってみて気づいたはチームの共通言語ができることです。コミュニケーションがより円滑になる効果もあると思いました。

例えば先日輪読した書籍に登場した「ウィルパワー」という言葉。これは意思決定をするたびに消耗するエネルギー的な意味を持つ言葉なのですがこれが共通言語化することで「そこにウィルパワー割く必要ある？」とか「その設計は読む人のウィルパワー消費するからよくない」などの使い方が通じるようになります。

チームの言葉が増える → コミュニケーションの質＆スピード向上

となりとてもいいなと思いました。

成長に寄与しよう

このようにまだ始めたばかりですが、いまのところ楽しくやっています。

ペライチには大切にしているカルチャーの一つに「成長に寄与しよう」というのがあります。今後もメンバー一人ひとりがエンジニアとして成長できる環境を整えていくためにこういう取り組みをどんどんやっていきたいと思います！

エンジニアインターンの研修用教材としてProgateがめちゃくちゃ使えそう！

久しぶりに会社にエンジニアインターンが入社することになったので研修教材を探したところProgate がよさそうだったので使ってみることに。試しに自分でも触ってみましたが、特に初学者向けの教材としてとても使えそうだと思いました。

Progateの特徴

環境構築が不要

自前で開発環境構築などが必要なく、PCとインターネット環境さえあればブラウザ上で利用できます。

UIはこんな感じ。

イラストでわかりやすい

解説がイラストつきでとっつきやすいです。ふしぶしにゆるいキャラクターが登場し、とにかくプログラミングに対してハードルを下げようという姿勢を感じます。

フィードバックをくれる

何が間違っているのか具体的にフィードバックをくれるため、何がわからないのかわからなくてハマることがほぼありません。

安い

法人プランは一人当たり1480円/月です。安い。

いままで使ってた教材の難点

以前はドットインストールを使っていましたが、以下の問題がよく発生していました。

• 序盤の環境構築でハマって進めなくなる
• 問題の原因がわからないので自力で調べることが困難
• そのためリモートで進められない

特に初学者は何がわからないのかもわからない事が多いのでトレーナーがそばについてナビゲートしないといけない事が多いです。正直トレーナーにとってもそれなりの負担がかかります。

それに対してProgateの場合は上述の特徴があるため細かいところは一旦おいといてサクサク進められます。人に聞かなくていいから心理的に楽だしモチベーションが継続しやすいと感じました。

まず全体感を知ってもらうというやり方

全体を把握できない中で学習の本筋ではない部分でハマり、暗中模索する作業はとても辛いものがあります。

それを解消するためにも細かい事は置いておいてまず一周してもらい全体感を把握してもらう。そんな使い方に最適だと思いました。

場合によって使い分けられるといいかも

上述でドットインストールを下げた感じになってしまいましたが、要は以下のように場合によって使い分けができればいいのかなと思っています。

• 全くの初学者: Progate
• 開発経験あり: ドットインストール, Udemy etc

書籍や動画などの情報が一方向的な教材でも、ある程度わからないことを調べるスキルがあれば有効に使いこなせるはずです。

ということで、さっそく試してみます。ほかにいい教材知ってる方教えて下さい！

7日間断食して得られたもの

断食といっても正確にはファスティングという水と酵素ドリンクだけで過ごすやつを7日間行いました。

2月に受けた人間ドックで脂肪肝と診断されたのでよくいく鍼灸の先生にその話をしたところ、ファスティングやれば？といわれて興味を持ったのがきっかけです。

結論からいうと当初の目的だった脂肪肝とかどうでもよくなるくらいいろんな変化がありました。

やったこと

まずトレーナーを探した

ファスティングは素人が単独でやると危険なこともあるので、まず適切な指導をしてくれる専門家の人を見つけなければいけません。僕はネットで見つけた断食メガネさんという専門家の方に教えてもらいながらやりました。後から知ったのですがメガネさんはペライチのユーザーさんでした。

スケジュール調整

ファスティングはざっくりいうと 準備食（2日間） → ファスティング（7日間） → 回復食（3日間） という流れで行います。

期間中は外食ができないので、飲み会やランチが入れられずいろいろ調整する必要がありました。振り返ると断食よりここの調整が一番大変だった気がします。

いよいよ断食開始

準備食（2日間）

ファスティング中は肝臓が忙しいため、前段階で肝臓に負担がかからない食事をとって極力肝臓を休ませます。具体的には添加物の多いお菓子スイーツ、お酒、カフェイン、肉、魚、卵、動物性たんぱく質、揚げ物などを避けます。必然的に病院食みたいな感じの食事になります。

ファスティング（7日間）

準備食期間を終えたら本格的にファスティング開始です。期間中に摂取するのは以下だけ。

• 水
• 酵素ドリンク
• 塩

酵素ドリンクというのは、なんか乳酸菌とかが入ってて腸内環境良くしてくれる＆最低限のブドウ糖が摂取できるようになってる飲み物です。

ファスティング期間は人によっては3日間や5日間で行うみたいですが、メガネさんによると3日目から本格的に脂肪が燃焼しはじめるという話だったので、僕は思い切って長めの7日間とりました。

回復食（3日間）

ファスティング後に直後にいきなり体への負担が大きいものを食べると倒れたりするそうなので、準備食同様やさしいものを食べます。

どんな変化があったか

さて、結論まで長くなってしまいましたが、断食することでどんな変化があったか書きます。

• 体重: 79.5kg → 73.4kg
• 体脂肪率: 18.2% → 12.8%

結論、めちゃくちゃ痩せました。

それも筋肉はあまり減らず脂肪が減るという嬉しい結果に。ビジュアルの変化としてはお腹まわりの脂肪がすっきりなくなり、シックスパックが出てきました。

ジムでの計測ですが、当初の目的である内臓脂肪が減少し、ウエストも引き締まっていました！

体型以外に起こったさまざまな変化

上記の変化以外にも、ファスティング中は思いもよらない変化が沢山ありました。

• 日中の集中力が高まった
• 慢性疲労や慢性咽頭炎がなくなった
• 睡眠時間が減り、寝覚めがよくなった
• メンタルが安定し、ぶれることがなくなった

一番驚いたのは、数ヶ月悩まされていた慢性的な疲労感がなくなったことです。むしろ体力が有り余りすぎてファスティング中は毎朝欠かさず5km〜8km走ってから出社してました。消化にエネルギーを使わない分睡眠の質が高くなり、短時間睡眠でもすっきり目が覚め、まるでスーパーマリオ状態でした。

ケトン体質になるおかげでいいことが起こる

ファスティング中は体内のブドウ糖が枯渇するため、代わりに脂肪酸から作り出されるケトン体をエネルギーとします。ケトン体が脳に入るとα波の分泌が高まり高い集中力が保てることがわかっています。

さらにケトン体は脂肪酸から作り出されるため、期間中はボーナスステージのようにカロリーを消費すればするほど脂肪を燃焼する体質になります。これが運動すればするほど驚くほど脂肪が落ちるしくみです。

そして、胃腸が休まることで腸内環境が整うため、幸福ホルモンであるセロトニンや快楽ホルモンのドーパミンが分泌され、自律神経が整いメンタルが安定しさまざまな不調が改善されます。

ファスティングはダイエットの文脈で語られることが多いですが、本来は健康法の一種です。胃腸を休め、ホルモンバランスを整え、免疫細胞の生まれ変わりを促進することで体に蓄積された毒素を排出します。

今回とてもよかったので1〜2年に一回くらいは体の大掃除のつもりでやってもいいかなと思いました。

20代の若手エンジニア向けにキャリアについて話してきました

明日が見えない若手エンジニアナイト

というイベントで20代のエンジニア向けにお話してきました。

「会社員 → フリーランス → スタートアップ起業」というキャリアを通じて学んだことや自分が若手エンジニアだったらどのように過ごすかという軸でお話してきました。 短い時間だったので多くの内容は話せませんでしたが、参考にしてもらえたらうれしいです。

発表資料

キャリアについて考えるということ

自分が若い頃は正直それほどキャリアについて細かく考えていませんでした。ただ新卒で会社員になる前から20代のうちに起業するという方向性は胸に抱いていたため、それに向けて何が必要かを考えながらいろんな選択をしてきた気がします。

遠い未来に自分がどうなっていたいか具体的にイメージするのは難しいかもしれませんが、エンジニアとしてどういう方向性を目指すかというざっくりした指針くらいは考えておくといいのかもと思います。