omuronの備忘録

個人的な備忘録

「re:Growth 2020 Online」"コンテナ系リリース総ざらい" #cmregrowth 受講メモ

クラスメソッドさんの AWS re:Invent ふりかえり勉強会のコンテナセッションの受講メモです。
re:Invent 追いかけるの大変だからほんと助かります。
すぐにブログに上がるでしょうが、気にせず自分用メモ。

コンテナ系リリース総ざらい 〜独断と偏見のランキングを添えて〜

講師:クラスメソッド CX事業部 マネージャー ハマコー

speakerdeck.com

AWS Batch Jobs for Fargate

  • AWS Batch は EC2 しか使えなかった
  • Step Functions でバッチ処理していた
  • Fargate で使えるようになった!

EKS Anywhere

  • オンプレで k8s クラスターを構築
    • コントロールプレーンとデータプレーンをオンプレに持っていける

ECS Anywhere

  • ECS を AWS のデータプレーンを外に持っていける
  • Systems Manager エージェントをデータプレーンにインストールする
  • ラズパイでも動いた

ECR Public

  • ECR がどこからでもアクセス可能に
    • $ docker run public.ecr.aws/<レジストリ名>/<コンテナイメージ名>
  • DockerHub の代替に

Managed Service for Grafana / Prometheus

  • k8s 界隈でよく使われる
  • kibana っぽいものの
  • マネージド・サービス
    • 監視は作るのではなく買うもの

所感

Docker 使えば使うほど便利で楽しいですが、やっぱりまだまだハードルが高く感じることもあります。
それをオーケストレーションさせるなんて意味がわからない世界。
ECS のおかげでなんとプロダクションでも使えるようになるので ECS も好きです...がこいつもなかなか難しい。
ハマコーさんのおかげでだいぶ使えるようになって馴染むこともできたので感謝感謝です。

Android の機種変更に伴う APN 設定にハマった話

嫁さんが使っている Android がたまに落ちて、再起動に失敗することがたまにあったので買い替えました。

起動に数時間かかる

たまに落ちるとサクッと再起動できることもあれば、数時間たっても起動できないことなどがありました。
キャッシュを消して数時間放置していると起き上がってくる状況。
再起動画面で数時間かたまって二度と立ち上がらないんじゃないかという恐怖を何度か味わったのでもう限界ということで買い換えることに。
Android 5.0 で古いし、ストレージも空きがなくアプリも入れれないという端末としてもストレスが多いのも要因です。

機種選定

おサイフケータイが使いたい」という要望だけ。
それ以外は LINE とかバーコード決済とか普通にアプリが動けばいいとのことだったので、かなり安くなっている AQUOS Sence2 に決定。
新品がほしいと要望もあったので、未使用品をフリマで検索して au の SIM ロック解除版を購入。

端末が届いた

端末が届いたので、まずは SIM ロックが解除されているか確認。
私が使っているドコモの MVNO SIM を指しても認識しない...
SIM ロック解除版を買ったはずなのに少し焦る。

「設定」アプリを再度見ていると「端末情報」から「ステータス」に「SIM ロックの状態」というのがあり「SIM カードの状態を更新」をタップすることで解除ができた。
キャリア版の Android 端末を最近触ってなかったし、Android 事情からすっかり離れていたのでこんなメニューがあるのを知りませんでした。

この操作をすることにより、無事電波を掴むようになり、発信と着信ができるようになりました。

APN 設定

次はネットワーク設定。
APN を設定して通信できることを確認。
これも問題なさそう。

私の SIM で動作確認ができたので、アプリの移行を進めます。

SIM サイズ変更

嫁さんの SIM は、マイクロ SIM だったため、ナノ SIM に変更が必要です。
SIM 変更手数料が 3,000円ほど取られるため、変更手続きはせずに SIM カッターを購入。
この作業をすると保証もなくなるのであくまで自己責任。

f:id:omron:20201216154853p:plain

これを使い、えいやーと勢いで SIM をカットする。
カットした SIM を端末に指すと、無事 SIM を認識!

ほっと一安心して、後はネットワークの設定を残すだけとなりました。

再度 APN 設定

設定するのはイオン SIM だったため、イオンモバイルのサイトを参照して APN を設定。
APN には、3種類あるもよう。

  • docomo 回線
    • 音声通話付き SIM
    • データ専用 SIM
  • au 回線
    • 音声通話付き SIM

docomo の音声通話付き SIM なのでこの APN を設定して完了。と思いきや、全然ネットワークがつながらない... 以前の機種の APN を見ようとしても、SIM を抜いた時点で設定が消えていてもう参照ができない。
3時間ほど設定と格闘するがつながらないので、もやもやしたまま諦めて就寝。

SIM 変更検討

「SIM をぶった切った影響で、認識はするが通信はできず壊れた状態かなー」と思ったため、この機会にもっと安い別の MVNO に変更を検討を始める。
1GB/月 ぐらい通信容量があれば十分なので、その中で最安値を調べる。

調べているうちに、「イオンスマホ > イオンモバイル乗り換えキャンペーン」なるものを目にします。

え?イオンモバイルとイオンスマホは別なの? ということで、イオンスマホに存在している以下の APN の設定を順にやってみる。

無事 biglobe.jp で繋がりました。

さいごに

セットアップが完了したので、嫁さんに渡してこの話をすると
「うん、イオンじゃなくてビッグローブだよ」
と言われました...
最初から相談しとけば数時間溶けずに済んだのに、ネットワークのことだからと1人悩んでたのが敗因です。

モリサワ新ゴできれいな文字で表示できるので、ヨシと思っておきます!

『Corporate Engineering Study #1「コーポレートエンジニアのこれから」』受講メモ #CEStudy

forkwell.connpass.com ハッシュタグ:#CEStudy

最近聞くようになったコーポレートエンジニアが気になって受講しました。
また、今回の参加している企業が非常に魅力的です!

あつまれ 情シスの森:SmartHR島移住ガイド

講師:株式会社SmartHR yamashu氏

  • コーポレートエンジニア is 何?
    • 情シス+セキュリティ
    • オフィス移転、ヘルプデスク
      • 電気が通るもの全て
    • SmartHR に関すること(プロダクト)はやらない
    • 情シス+α
      • 開発もできる情シス
  • サービス/ID 管理を担当
    • オンプレなし
    • IdP + Password Manager
    • Okta 利用
  • Password Manager を導入した理由
    • IdP だけでは管理できない、自動ログインできない
    • 福利厚生で 1Password Business 利用可能
    • IdP が得意な領域は弱い
      • Directory, JIT provisioning...
    • LastPass は IdP にもなれるののですごい
  • 経費精算を Slack で
    • 社員同士でご飯行くと費用負担
      • 不正利用にならないようにオープン化
      • 同じ部署、同じメンバで何度も行くのはなしにしたい
      • 事前申請とかめんどくさいことはやめたい
    • 日付とメンバーを申請
      • 顔写真入の写真を投稿
      • 領収書をアップロード
        • OCR で自動処理
  • 作り終えた感想
    • 再考に楽しい
    • 便利、すごいとのフィードバックでモチベアップ
    • 飲食系経費精算をすべてこれに変えたいと経理から要望あり
  • やりたいことが 10 - 100 ある
    • 2 -3 しかできない
    • 仲間募集

FAQ

  • Slackの裏で持っている組織や人事マスタ情報のメンテナンスの色見をお聞かせいただきたいです。
    • SmartHR は個人情報満載だから持ってない
  • コーポレートエンジニアが担当するタスクは、どのように優先度を決めて着手されていますか?
    • 明確に締め切りがあるものから着手
    • それ以外はグループ内で決めた目標やミッションに沿うものから本人のやりたいものをとっていく
    • 組織が大きくなるとすべてがそうできるわけではない状況
    • Slack をめっちゃ使うので Slack を使う仕事がしたい
  • IdP に Okta を選択した理由を聞いてみたいです!またオススメされていた LastPass を選択されなかった理由も気になります。
    • Okta は今まで使っていた IdP の上位互換だった
    • 1Password をすでに使ってる人が多かったので LastPass を使わなかった
      • 更新も多いし、UI もよかった
  • 実践されているAWSの構成やセキュリティ原則を、聴ける範囲で教えて頂ければ嬉しいです。
    • AWS 触り始めなので答えれない
    • Heroku を社内の開発では使っている
      • Heroku は昔から使っているのが理由
    • 求人などは AWS を利用中
      • Heroku だと組めない構成だった場合など
  • 開発すると、メンテナンスコストも増えてこないでしょうか。負債とはどのように向き合っていますか?
    • メンテコストがかかるから基本開発はしたくない
      • プロダクトと違って人が少ないので避けたい
      • 他の手段で解決できないか検討する
      • 運用で回避、オートメーションツールで解決できるならそれでいい
      • 迷う時間で作れるなら作る
  • SlackAppのバックエンドってどの言語/インフラでつくりましたか?
  • 先程、チームが抱える課題が人が足りないと仰っていらしたと思うのですが、業務的な部分で、最も困ってらっしゃるのは、どんな部分になるのでしょうか?SmartHRさん規模のような会社になられると、どんな課題が発生する事を予測しなくてはいけないのか気になりました。
    • 社員の生産性を上げるのが仕事だが人的リソースが無いのが課題

ペパボのコーポレートエンジニアリングのこれまでとこれから

講師:GMOペパボ株式会社 大和田 純氏

  • インフラ支援部から情シスをえて業務プロセス革新室へ
    • コーポレートエンジニアリンググループが誕生
  • 1月から在宅になり、6月からテレワークを基本へ
  • コーポレートエンジニアリングの仕事相手
  • 事業部をまたいで横串で活動
    • 共通の問題点の解決
    • いろんな部署と繋がりを持つハブのような部署
  • ペパボ全体の特徴
    • みんなが勝手に便利ツールをつくるから便利
      • どんどんやってもらって把握
    • 経営陣も含めて新しいことに理解が合って便利
      • 社長的に Slack に移行したほうがいい理由(という社長ブログあり)
    • やっていきとのっていきの文化が合って便利
      • その分なにかをすすめるならしっかりと考える
  • ペパボの CEG のこれから
    • 企業理念
    • ペパボテックカンパニービジョン
      • 構造化、自動化、再起化
    • 業務を徹底的に構造化する
      • コード化できるものはコード化
      • コード化難しいものはワークフローとドキュメントで構造化
      • SPOF を少なくしピアレビューを通じて業務の質を高める
      • ソフトウェアによって問題を解決、成果物の管理と共有、構造化しやすいツールの選定
    • チームの力をたかめる
      • 強力な個人に甘えずチームでことを成す
      • 業務を構造化しながら属人性とうまく付き合う
      • 状況の変化に強いしなやかなチームを目指す
      • パプロ・ペアオペを推奨、GitHub Flow の積極採用、チームでの技術選定
    • ラクティスを取り入れる
      • ソフトウェア開発のプラクティスをどんどん試す
      • 他部署のエンジニアと共通の語彙を持つ
      • 孤立した特殊なチームではないと理解する
      • 種々のプラクティスの学習と導入、IaCやSRE/CREの考え方を自分たちの領域に応用して適用

FAQ

  • 技術部の中のひとつとしての CEG とのことでした。フロントのプロダクト開発をするエンジニアと兼任したり、入れ替わったりすることはあるのですか?
    • たくさん例があるわけじゃないのでカジュアルに移動できるようにしていきたい
  • お恥ずかしいのですが、勝手に社内ツールを作るエンジニアの、モチベーションはどこからくるのでしょうか?
    • お客様向けに喜んでもらうコードと社内向けに書くコード、どちらも人のために書くコードなので違いがない
    • 自分の評価にもつながる
  • 属人性を解消するために具体的に取り組まれていることについて教えていただけるものがありば伺ってみたいです
    • ペアプロ、ペアオペをたくさんやる
    • 建設現場とか物理的に危険な現場だと1人は禁止
      • 同じ考えで複数人でやる

noteのコーポレートエンジニアリングと、『伝える努力』のこと

講師:note株式会社 東 耕輔氏

  • note のコーポレートエンジニアリングの定義
    • 社内の情報の循環を最適化する
      • 必要な情報を必要なときに必要な人へ
    • 業務の改善、手を動かして、PM的に立ち回る
    • セキュリティなどの足回りのエンジニアリング
  • note の社内 IT の変化
    • 情シス業務が分散、漏れありダブリあり
      • ITヘルプデスクは善意のエンジニアによる温かみのある運用
    • 足回りのエンジニアリングの開始
      • 統合整理、Slack へ集約、PC を個人から会社資産利用へ
    • コロナ禍と大きな変化
      • 3月からリモート推奨4月から完全リモート
      • キッティングと配送処理のために1人オフィスに行く
      • 社名変更、イベントスペース開始
    • 業務改善へ
      • 足回りのエンジニアリングの仕組み化をして手を離した
      • 社内業務改善プロジェクトへ参画
      • 前者の業務フローカイゼンPJTを立ち上げる
  • 伝える努力について
    • つくる、つながる、とどける
      • 全ての仕事に通じる
    • つながるために必要なこと
      • 話を聞いてもらうための下地を作る
      • 要望に運用的確に応えていく
      • 自己開示する
    • とどけるために必要なこと
      • シンプルに意図を伝える
      • 思いを合わせて伝えきる
        • エモに働きかけることも大事
    • note を書く
      • 仕事に関係すること関係ないこともとにかく書く
      • 仕事も思いを乗せて書く
  • いいことが3つあった
    • 話を聞いてもらうための足場ができた
    • 言葉に対する感覚が敏感になった
    • エンドユーザと繋がることができた

FAQ

  • 利用しているマシンは Mac のみですか?ゼロタッチデプロイはどのように実現されていますか?
    • 銀行向け以外はほぼ Mac
    • Jamf ベース
  • 各所最適から全体最適へ進めていくにあたり、どういう作戦を立てたのか具体的に伺いたいです。課題の洗い出しなど結構色々な部門を巻き込むと思いますが、どうしましたか?
    • 全社のヤミを聞いてまとめてできることからやる
    • 走り始めたチームの PDCA を回して強靭化して大きなことをやる
    • 課題を洗い出して見えるところからやる
  • 最近、新しいMacが届くのが昔より遅くなっていると思うのですが、いくつか在庫をストックされていたりされるのでしょうか?またMacApple Careには入らずに一括で購入されるような形で対応されてらっしゃるのでしょうか?デバイスの予算があまりないので、どのようにコスト最適されていらっしゃるのかなと。
    • 在庫はストック済み、4−5台程度
    • 月に4-5人の入社に合わせている
    • Apple Care は無し

所感

SmartHR、GMO ペパボ、note どれも好きな企業でとてもおもしろい内容でした。
途中で Google が落ちるというトラブルにもめげず最後まで無事にこなせたのはさすがです。
コーポレートエンジニアというのは最近聞き始めた職種です。
コロナ禍でますます内製化が必要で社内のエンジニア力が求められる時代だと思いますので、組織力上げるにはこのような人材が求められるんでしょうね。

アウトプットを続けること

この記事を投稿する前のブログ数のキャプチャーがこちらです。

f:id:omron:20201209101618p:plain

今年の4月から始めたブログも、この記事にて100記事を達成することになります。
アウトプットを始めたきっかけなどについては、MixLeap に登壇して話をしました。
その内容は、前回の記事 にしております。

最初の1週間

ブログ記事を書き始めた当初は、「とりあえず1週間平日は毎日書いてみよう」を目標にしました。
「土日は一旦忘れる。平日は頑張ってみる。」というスタンスです。
この小さな目標は無事に達成することができました。

最初の1ヶ月間

ここからは無理しないで書こうというスタンスにしました。
次の目標は「習慣化する」こと。
最初の1ヶ月は書いてみたいネタも色々あったので特に困ることはありませんでした。

GW 突入

最初の1ヶ月が過ぎ、ある程度習慣化できるようになったところで GW 突入です。
平日しか書かないと言っていると見事に記事が止まってしまいました。
ここからは休みでも気にせずに書きたいときに書くように変えました。

2ヶ月目

ネタが付きてきたので、勉強会のメモと所感を投稿するようにしました。
全ての勉強会の所感を投稿しているわけではありませんが、ブログを書くためにも勉強会に参加するという相乗効果ができました。

3ヶ月目

Auth0 の調査をしていたので、勉強した内容をまとめたりしてました。
SNS でシェアすると中の人からアドバイスを貰えたりしてとても助かりました。
3ヶ月も過ぎると、習慣化できてきたので書かないと気持ち悪いと感じるようにもなりました。

まとめ

質はさておき、まずはブログでのアウトプットがある程度できるようになり、100記事まで達成しました。
次は登壇にチャレンジしていきたいと思います。
ブログよりも登壇のほうがとてもパワーを使うと感じております。
登壇者のみならず、運営の皆さんとか本当に尊敬します。
過去オフラインで登壇したことは何度かありますが、こちらも慣れの問題なので引き続き登壇にもチャレンジして行きたいと思っております。

『MixLeap Live LT #34 - 初心者大歓迎!!「フリーテーマ」」』に登壇しました #mixleap

『MixLeap Live LT #33 - 特別編「LTのはじめかた」』アーカイブ受講メモ #mixleap - omuronの備忘録 のプレゼンに刺激されたこともあり、1年ぶりに MixLeap に登壇しました。
この情報を参考に、資料を作りたかったのも動機の一つです。

yahoo-osaka.connpass.com

登壇資料

アウトプットはじめました

speakerdeck.com

所感

私は、自粛が本格化する前の今年2月を最後に登壇をしておらず、オンラインでの登壇は初めてです。
過去参加した LT は、ドラ娘がいて5分ジャストで切られるものが多かった状況でした。
逆に5分に満たない場合は、5分立つまで終わることもできない厳しいケースもあったりしました。

MixLeap での登壇は、このあたりはゆるく5分前後でも問題ないので参加しやすいですね!
今回ジャスト5分で話すことができたのもの、過去鍛えられたおかげだと思っております。

オンラインでの登壇は、参加者の顔が見えず反応がわからない部分は難しいと感じました。
一方、プレゼンモードで台本を準備しておくと、それを読むだけでこなしても大きな問題がないのがいいところではないでしょうか。
お客さんの前で話す場合は、身振り手振りや会場の反応に合わせた対応も入れたほうがいいですが、このあたりは慣れが必要です。
その点も踏まえて、オンラインのほうがハードルは低い気がしました。

やっぱり登壇は面白いですね。
ヤフー大阪さんありがとうございました。

(小ネタ) AWS CLI v2 のページャー出力をやめたい

CLI v2 のページャー出力はその場で表示を見るのは楽ですが、ファイル等に出力するときはじゃまなので切る方法を探しました。
ここ に記載があります。

結論としては ~/.aws/config に以下の設定を追加すれば解決しました。

[default]
cli_pager=

追記

環境変数でも消せるようです。

export AWS_PAGER=""

「CloudNative Days Tokyo 2020 Recap」 #CNDT2020 受講メモ

cloudnativedays.connpass.com

去年は東京までいって参加したのですが、今年はオンラインも見れなかったので Recap があって助かりました。
ということで、気になる部分の受講メモです。

モノリスからクラウドネイティブへ - 設計思想の違いを知り乗り越える

講師:山本 泰宇

原則駆動開発 (PDD) pdd.dev

  • Be Declarative
  • Define by Software
  • Test Everything

誘導された開発成果

  • 仮想データセンターによる CI/CD Test Everything
  • k8s 自体 GitOps で更新 Be Declarative
  • ストレージネットワーク on k8s Define by Software

何を使うかよりどうやっていくかが大事

開発モデル

コンセプト検証 (PoC)

対策

  • 工数はよまない
    • 順番だけ決める
  • 積み上げた成果を利用者に順に提供
  • 改善作業専任チーム

学習

  • 輪講や勉強会を業務時間に
  • KubeCon に全員派遣
  • アウトプット
    • ブログやミートアップで成果発表

OSS

  • アップストリームへの貢献
  • 頻繁なアップデートへの対応
    • 更新試験の自動化は必須
  • OSS ポリシー、ガイドラインを整備

まとめ

  • アーキテクチャ:何を使うかよりどう使うか
  • 運営:作って終わりではなく作り続ける
  • 人材:専門家を育成するより組織作り
  • OSS:社員の支援とテストの充実

独りよがりのプラットフォーム

講師:原 トリ

リアルトリさんの公演です!
(一度リアルで会ったことはあるけど)

プラットフォームの話をしましょう

プラットフォームの類義語

  • 共通基盤
  • インフラ基盤
  • 次世代開発プラットフォーム
  • 次世、統合、インフラ、共通、開発、基盤...

共通基盤

  • 実現方法の話し合いから2年たった
    • 陳腐化してきた
    • k8s きてる?

うまくいかない共通基盤

  • 課題設定は大きくふわっと
  • ユーザーヒアリングは無駄
  • 課題解決できるかは計測せず雰囲気
  • 共通基盤は使わせるもの
  • 共通基盤は作りきり

共通基盤と課題設定

  • 現実とかけ離れたでかすぎる TODO リストは終わらない
  • タスクに落とし込める課題設定が必要
  • Acceptable なゴール設定

共通基盤とステークホルダー

  • 基盤を取り巻く人々が抱えている課題はそれぞれ異なる
  • ユーザーヒアリングがとにかく大事
    • 何困っているか?(何が欲しいかではない)
    • 原因の解消方法の仮説立て
    • ユーザーに提案して意見もらう
      • 実装はしない
      • ホワイトボーディングやドキュメント
      • ユーザのフィードバックで修正
    • MVP での実装

どうやって AWS をつくってきた?

  • 90 - 95% の新機能はユーザーリクエストをベースに作成
    • 仮設を立ててヒアリング
    • 内部の声はカウントされない
      • どこの顧客がいっているんだ?とヒアリングされる
      • 別のサービスのチームは「ユーザー」
  • お客様を起点に考える
    • プレスリリースを最初に必ず書く
    • リリースに対する FAQ を実装前に書く
    • 顧客視点で課題が解決できるか確認するプロセス

なぜ計測可能な課題設定が重要なのか?

  • プラットフォームとチームの存続意義
    • ステークホルダーへの説明責任
    • 成果のない基盤チームはただの負債
    • 計測できない成果は成果ではない
  • 計測できないものを課題として設定しない
    • e.g. コスト削減、生産性バク上げ、モダン、クラウドネイティブ、超セキュア

共通基盤はなぜ使われないか

  • 必要ないものを無理に使わせる
  • 説明ニグレクト
  • 最初は良さげに見えたが新たな課題や世の中の流れについていかない

誰のための共通基盤なの?

価値のある意味にあるプラットフォームを

  • 適切な粒度の課題設定
  • 共通基盤のステークホルダーは顧客
  • ひたすらユーザーヒアリングと MVP の繰り返し
    • 顧客から逆向きに課題を探り出すべし
  • 計測、計測、計測
    • 何を計測するかはすぐには見えない、メトリクスを見つけるもの大事な仕事
  • 共通基盤は社内向けのサービス
    • 継続的に改善、継続的にユーザーヒアリング
  • 形のある基盤という存在にこだわらない

所感

どちらの話もとてもささりました。
適切な粒度や MVP での実装は意識している。
ヒアリングと計測...これはわかっているけど難しい。
計測は意識しやすいけど、プロダクトオーナーが近くにいないとかを言い訳にヒアリングが全然できてない。
とても耳が痛い内容でした。