amareloのブログ（仮）

IT系勉強会で感じた想いや知見をメインに書いていきます。

JAWS-UG CLI専門支部 #231R AWS CLI入門 参加レポート

AWS 勉強会レポート

10/14（木）JAWS-UG CLI専門支部 #231R AWS CLI入門 に参加しました。 CLI専門支部にはずっと参加していましたが、復習ブログはしばらく書いていませんでした。 久々になってしまいましたが、ブログ書いていきます。 今回はいつもと違い、座学多めでハンズオン少なめでしたが、 波田野さんのAWS CLIへの熱量がいつもより強くて濃い内容でした。 この記事では座学パートとLTについてを参加レポートとして書いていこうと思います。 ハンズオンの方は別記事に書きました。

zenn.dev

目次

イベントページ

jawsug-cli.connpass.com

AWS CLIについて

AWS CLIの概要

  • AWS公式コマンドラインインタフェース
    • 以前からあった個別プロダクトを統一したもの
  • Pythonの Boto coreライブラリをバックエンドで利用している
  • 約280サービスに対応
    • 基本的には1サービス１コマンド
    • S3のみハイレベルコマンドがある（s3,s3api)

AWS CLIの特徴

  • AWSサービスはAPIの集合体
    • AWSを真に理解するとはAWS APIの働きを理解すること
  • AWS CLIは基本的にサービスAPIのラッパー
    • 公開されているAWS APIのほぼすべてを操作できる。
    • AWS CLIを理解することでAWS APIの働きを理解できる。
  • 最新機能への対応が早い
    • バージョン１の方が積極的に更新されている（ほぼ週５回）
      • バージョン２は週２回（水・金）
  • ブラウザ（Cloud9、CloudShell）・Linuxなど多様な実行環境

AWSの変更作業にCLIを使う

  • マネコンだと何となく理解していればつつがなく作業完了してしまう。
  • AWS CLIだと過去の資産を使える。
  • マネコンだと処理が隠蔽化されているので、Undoできない。
  • CLIだと変更差異が確実にわかるので、Undoできる。

なぜGUIを使う人が多いのか？

  • GUIは楽
  • 直感的に操作できるから
  • グラフィカルな表示は分かりやすいから

それは本当か？

  • 突然UI改訂が起こる。
  • 手順書修正が追い付かず混乱する。
  • 直感に依存することで、論理だったコンピューティングを利用しなくなった可能性がある。
  • 情報過剰になりやすく、論理構造が把握しづらい。本質的な理解を妨げる側面もある。
  • 何となく、たぶんで接するコンピューティングは「IT」なのか？
  • 理解があやふやなまま本質をとらえる機会が得られずにコンピューティングしている「つもり」になりがち。
  • 過剰な情報から適切な取捨選択や推論ができないコンピューティングは「IT」なのか？

手順書の工数と品質

  • GUI作成手順はCLI手順の3倍手間、1/3の品質

AWSとどうつきあいたいのか？

それぞれの特徴

  • GUI
    • メリット：柔軟性がある。
    • デメリット：反復、再現性がない。
  • CLI
    • メリット：柔軟性、反復再現性がある。
    • デメリット：学習コストは高い。
  • SDK
    • メリット：反復、再現性
    • デメリット：柔軟性がない、陳腐化が早い。学習コストは高い。

付き合い方

  • AWSで手作業したいときは、GUIとCLI
  • 自動化したいときは、CLIとSDK
  • 両方に対応できるのはCLI
  • CLIを軸にSDKかGUIに展開していくのが良い。
  • コストをかけないで良いところをCLIでやるのが良い。

AWS CLIの導入と更新

  • バージョン１
    • デフォルトブランチ
    • 週5回リリース
    • Cloud9、Amazon Linux2標準
    • パッケージ管理：pip3
    • シンプル

  • バージョン２

    • 週２回リリース
    • CloudShell標準
    • パッケージ管理：tar
    • 多機能・肥大

  • ハンズオンはバージョン１を利用

  • バージョン１の導入

    • Amazon Linux2では導入済
    • PIPでインストール
      • sudo pip install awscli==1.20.1(バージョン指定する必要があるならば、==<バージョン数>が必要)
    • aws --versionでバージョン確認

AWS CLIの構成要素

  • AWSの権限

    • IAMユーザ（マネコン）
      • MFA設定していないと悪用される恐れがある。
    • IAMユーザ（IAMアクセスキー）
      • アクセスキーが漏洩すると悪用される恐れがある
    • インスタンスプロファイル（IAMロール）
      • EC2インスタンス上では、インスタンスプロファイルに紐づいたIAMロールの権限で動作する。
      • AWSの認証情報をユーザが扱わない。認証情報が漏洩しないため安全。
        • Cloud9の場合はSSH接続できないのでさらに安全

  • AWSコマンド

  • jp.pyコマンド

    • AWS CLIに付属しているフィルタスクリプト
    • 標準出力やファイルに出力されたJSONをJMESPathでパース出来る

AWS CLIの利用方法

  • ハイレベルコマンド（UNIXライクな出力）
    • 引数指定
      • UNIXライクな入力
      • S3のみ対応（バージョン１）
  • APIコマンド（JSON出力）
    • パラメータ指定
      • UNIXライクな入力
    • JSON指定
      • JSONによる入力
        • --generate-cli-skeleton オプションでテンプレートが生成される

AWS CLIの入力

  • 書式

    aws s3api list-objects --bucket hoge

    • aws ではじまり、左からコマンド（s3api）、サブコマンド（list-object）、パラメータ（--bucket）、オプション

    • APIエンドポイント名とCLIコマンド名は、原則同じ

      • iam,route53,ec2,s3/s3api,lambda

    • APIエンドポイント

      • グローバルサービス　https://iam.amazonaws.com
      • リージョナルサービス　https://ec2.{リージョン}.amazonaws.com

    • APIアクションとCLIサブコマンド名は原則同じ パスカルケース　チェイン（ケバブ）ケース

    • パラメータ

      • APIパラメータ名とCLIパラメータ名は原則同じ
        • InstanceType（パスカルケース） = --instance-type（チェインケース）

    • オプション

      • --query
        • JMESPath記法を利用
      • --output
        • defaultはJSON形式
        • テキストやテーブル形式での出力も可能
      • --debug

AWS CLIの出力

  • サーバサイドフィルタ
    • filterパラメータ
      • describe系コマンドは、filterパラメータが定義されている。
      • 定義されていないものはフィルタリングできない。
  • クライアントサイドフィルタ
    • queryオプション
      • すべてのJSONを処理できる。
      • APIの出力情報をすべて出力して転送するためパフォーマンスは良くない。データ転送量も多い。
      • 出力結果から特定のノードを取り出すことができる。
      • 「存在しない」を条件にすることは出来ない。
        • その場合は、jq.pyを使う必要がある。

AWS学習の中長期戦略

  • 早めにAWSと付き合う
  • 公式ドキュメントと付き合う
    • AWSが積極的に技術的なトピックやノウハウを公開している。
    • すべて読み込んで手を動かせば、誰でも国内有数のAWSエンジニアになれる。
      • すべて読み込むのは不可能（数十万ページ）
  • ビジネスで使ってみる
    • ビジネスで使えそうなプロダクトをつまみ食いする。
    • すべてのプロダクトを使うのは非現実的
    • 特徴ある使い方出来る人が強い。
    • 芋づる式に関連プロダクトに手を出していくと、その領域では数少ないAWSプロフェッショナルになれる

LT

バージョニング有効なS3バケットのオブジェクト一括削除（JQコマンド）　emiさん

※資料が公開されたことを確認出来たら、追記します。

  • バージョニング有効なS3バケットの削除は、オブジェクト（過去バージョン含む）と削除マーカーすべての削除が必要
  • バージョニング有効なS3オブジェクトをたくさん消すのは大変
    • JQコマンドが使える
      • Cloud9環境にはないのでsudo yum -yu install jqでインストールが必要
      • CloudShellにはインストールされている
  • list-object-versionとjqコマンドでバージョンIDを一括取得
    • 削除マーカーなしのオブジェクトIDをすべてを取得できる。
    • 削除マーカーを指定してオブジェクトID取得もできる。
      • フォルダの削除マーカーはマネコンからは見えない。
  • オブジェクトの一括削除
    • バージョンIDを取得してオブジェクト削除をwhile文で繰り返す。
      • 削除マーカー以外のオブジェクトは削除できた。
    • 削除マーカーしか入っていないバケットの削除はできない。
      • 削除マーカーのオブジェクトIDを取得して一括削除できた。
      • その後バケットも削除することができた。

最後に

応用情報の受験も終わり、AWS SysOps Administrator Associateの勉強に重点を戻したところで今回のハンズオンに参加できた良かったです。 改めてAWS CLIを勉強することのメリットを見直すことができて、またAWSの勉強へのやる気が出てきました。 AWSの勉強の際は、GUIからだけでなくAWS CLIもできる限り取り組もうと思いました。

あとはやはりアウトプットは大事。CLI専門支部の復習ブログもまた出来る限り書いていきたいと思いました！！

JBUG Autumn 2021参加レポート

勉強会レポート

10/7（木）JBUG Autumn 2021に参加しましたので、レポートを書いていきます。

目次

イベントページ

jbug.connpass.com

セッション・LT内容

セッション1 私がマネージャーになって１番最初にやったこと 株式会社スノーピークビジネスソリューションズ 松井 勇樹 さん

課題

  • 案件進捗を各人からの報告に頼っている。
  • スケジュールが綿密に練られていない。
  • 予定に対する進捗が可視化されていない。

backlogの導入をしてみた。

  • 導入後1年、スケジュールとやることが明確になった。進捗が予定通りか正確に把握できるようになった。
  • backlogを導入してから、売り上げの目標値を達成で切るようになった。現在も更新中。

なぜうまくいったのか？

  • backlogはシンプルでわかりやすい。
  • メンバにメリットをもたらした。

プロジェクトが定着し組織が活性化する時の鉄則

  • プロセスの共有
  • WHYの合意形成
  • 全員参加型でスモールスタート

  • 良好な人間関係

  • 組織の成功循環モデル

    • 関係の質
    • 思考の質
    • 行動の質
    • 結果の質

まとめ

  • 良好な人間関係を構築しメンバにもメリットを感じてもらえるように。

セッション2 合言葉は「Backlog感出しますか」 株式会社ジーティーアイ 佐藤 毅

Backlog感を出すとは？

  • BacklogをBacklog然とした使い方をするだけ！
  • JBUGで見たかっこいいプロジェクトをマネするだけ！

その１：課題は最小単位のタスクで数多く

  • タスクを細分化して登録する
  • タスクを全部出し切るつもりで登録する。

その２：担当者をその都度変更する

  • 課題が終わったら、確認者を担当者に変更する。
  • タスクに責任の所在を明確にして優先して取り組めるように！
  • 相手が受け取りやすいように工夫すること。

その３：ステータスをどんどん進める

  • 進捗をこなすとどんどんタスクをこなしたくなる。
  • カンバンボード上でステータス変更して気分を盛り上げる。
  • ステータスの変更ルールは最初に決めておこう。

まとめ

  • Backlogでプロジェクトをスムーズにいくとは限らないけど、プロジェクトをより楽しく進めることができる。
  • 組織にあったBacklog感を出して、その内容をJBUGで登壇してみよう。

LT1 グラレコで猛攻撃に遭った後、救われた話 安積 津友香 さん

  • グラレコとは？

    • 話しの本質だけを見抜いて描く。

  • グラレコで議事録を書いていたが、チームリーダから攻撃を受けてやめていた。

  • プロマネからグラレコを褒められて救われた。
  • 別の部署のデザイナーさんから勉強会の依頼が来た。
  • 人と人とのつながりを創るためにグラレコを続けたい。

LT2 WikiとFigmaを活用したら全員ちょっと幸せになった話　恩田 淳子さん

チームのこれまで

  • 資料、課題、デザインデータがとっ散らかっていた。
  • 職人たちの勘と経験、そして気合で乗り切る。
  • 情報が適切に連携されておらず、属人的・非効率
  • 品質管理が難しい。

取り組んだこと

  • BacklogのWikiとFigmaに情報をまとめる。
    • プロジェクトに関わる主要な情報すべてWikiに記入。
    • ビジュアルに関わる要件をFigmaに記録。
    • WikiとFigmaを見て開発、検品をした。
  • 申し送りミーティング

成果

  • 小さな変化だけど、全員ちょっとだけ幸せになった。
  • 各自やるからチームでやるマインドへ
  • 情報探しが大幅に減った。
  • 検品工数が20%減った。

まとめ

  • あなたの困ったはチームの困ったかもしれない。
  • 情報はまとめよう。

LT3 システムエンジニアとして過ごした2年間の振り返り Kazuhiro.Yoshida さん

  • SEとPMの兼任
  • SEとしての悩み
    • 知識不足
    • エンジニアへの仕様の伝え方
      • backlogとチャットを使ってコミュニケーション
  • PMとしての悩み
    • プロジェクトが終わらない。
    • 人の管理

パネルセッション 〜JBUGのプロマネに聞いてみたい、あんなことやこんなこと〜

今と昔のプロジェクトマネジメントで変わったと思うこと

  • プロジェクト管理ツールの発展で見える化しやすくなった。
  • チャットツールでコミュニケーションしやすくなった。

  • プロジェクトのマネジメントとプロジェクトのマネジメントの違いが出てきた。

  • PMの権限が変わってきている。

    • 無理やりにでも働かせるかより、メンバに気持ちよく働いてもらうことを考える必要がある。
      • 少ない時間で多くのアウトプットを出せるようにムダなことを無くす。
      • 「四の五の言わずにやれ！」はもう通用しない。
      • 優しいだけでなく、背景や時代に合わせた「喝」を入れることは必要。

プロジェクト管理ツール、チャット、通話、リアルでの会話どう使い分けしている。

  • オンラインとオフラインの切り分けは模索中。
  • 込み入った話の場合は通話、エンジニアとの話は書いて示すなど、その場その場でよいツールを使っていく。

45歳定年説について。プロジェクトマネージャーのターニングポイント。

  • NeedsとWantsがあれば年齢がいくつでもやれると思う。働き盛りの年齢でもそれがなければやらない方が良い。
    • 良くないプロマネの下につくメンバが不幸になる。
  • 身体的な変化、環境の変化に合わせながらアップデートしていく必要がある。
  • ビジネスに旬なセンスを持っている人が不確実性のある決断をしていくのが良いと思う。
  • 45以上の人が活躍できるような場面はあって良いと思うが、自己研鑽する意欲がある人に任せる仕事だと思う。
  • 経験と勘がものを言う領域は増えていくと思う。腹をくくって経験と勘を基に判断を見せられる人は続けられると思う。

メンバのレベルを上げながらプロジェクトを完遂できるようなコツ？

  • 人によって接し方を変える。
    • 熟練者には抽象的な話し方、そうでない人には細かな指示を。
    • きめ細やかにコミュニケーション
  • 全体の底上げ
    • 能力差が出ないようなレベル上げ
    • 人によってやり方を組み合わせながら、全体のレベルを上げていく。

プロジェクトが殺伐としたときはどうする？

  • リーダーがユーモアを出して緊張感を緩めていく力が必要。
  • 殺伐とする予兆があるときにつぶしていく。

仕事の可視化を嫌がる人への対応

  • その人は成果を出してくれればよい。
  • 手がかかる方に手をかける。
  • 仕事に前向きになれないなど、別の要因があると思われる。その問題にアプローチした方が良いか考える。

全メンバでの定例ミーティングはどれくらいでやっている？

  • 基本は週一。
  • 規模とゴールまでの期間による。
  • 最初決めたやり方に固執しすぎず、状況見ながら見直していけるスキルが大事。
  • プロジェクトマネージャーが聞きたいタイミング。

感想

自分が推し進めたいことのメリット、困りごとを改善した後の景色を理解してもらえるように伝えなければならないし、 それ以前に信用してもらえるだけの人間関係を作り維持していきたいと思いました。

ユーモアは良好な人間関係作るのに必要だなと思いました。 オンラインだとそれが発揮しづらいところだけど、そこはツールをうまく使うことでカバーできると思います。 雰囲気的にやりづらいところはあるけど、もっと肩の力抜いてコミュニケーションしてみようと思いました。

安積さんのグラレコで人と人のつながりを創ったお話は、人間関係と和やかな雰囲気を創ってとても素敵だなぁ思いました。 絵を描くの得意ではないですが、自分も描いてみました！グラレコ一度挑戦してみようかな？

今回も仕事への取り組み方に参考になる話を聞けて多くの気づきをいただけました。 登壇者の皆様、運営の皆様、遅くまでありがとうございました。

JAWS-UG朝会 #25 参加レポート

AWS 勉強会レポート

9/30（木）JAWS-UG朝会 #25　に参加しましたので、レポートを書いていきます。

イベントページ

jawsug-asa.connpass.com

セッション内容

子どもたちにPay管理スキルとPay修正ページを作った話 フォージビジョン株式会社 尾谷 紘平さん

資料

公開されたら追記します。

管理スキル

  • 自分でゲーム時間を管理する

  • 自分でゲーム時間を創造する

    • この2つができないと大抵定量になってしまう。定量だと頑張る意欲が湧かない。

  • 子供のPayを貯めるのに、Alexaスキルを作った。

  • DynamoDBに子供のPayやお手伝いのリスト（お手伝い名と付与ポイント数）
  • AlexaスキルからLambdaを実行してSlackに
    • 自己管理能力の育成になった。

PDCA

  • 聞き取り間違いによる修正の手間が発生していた。
    • Amplify + Vue.js で管理画面を作った。

まとめ

  • AlexaカスタムスキルはAlexa道場を見れば創れる
  • Amplifyならば爆速で作れる
  • ご褒美を自分たちで創出する仕組みは、子供たちの自己管理能力を育成できる。

AWS公式チュートリアルから始めるAWS StepFunctions クラスメソッド株式会社 あしさん

資料

speakerdeck.com

アウトプットについて

  • ハンズオン学習におけるアウトプットとは？
    • 完了することを最優先すること（全体把握）
  • 必ず復習すること（インプット）
    • すべてを把握するのではなく、分かりやすいところやハンズオンでやったところを重点に。
  • 自分なりにカスタマイズしてオリジナル手順にしてみること（アウトプット）

AWS公式チュートリアルについて

AWS Stem Functions について

  • 様々なAWWSサービスを組み合わせてイベント駆動ワークフローをサーバレスに構築てできるサービス
  • WorkFlowStudio での構築ができるようになった。

実際にやってみた

  • 一通りハンズオンをやってみる
  • 実施した内容を復習する
    • 使用したコードの確認（Lambda、StepFunctions）
    • StepFunctionsのステートについて学ぶ
  • 改良版ハンズオン手順の実施
    • ステートマシンの作成（WorkFlow Studio）
    • ステートマシンのテスト（AWS CLI）
      • CloudShell から実行

まとめ

  • 全体把握⇒インプット⇒アウトプット　の流れでより効果的に学ぼう！
  • 公式チュートリアルは良い学習教材

AWS nuke触ってみた 富松 広太さん

資料

www.slideshare.net

使うことになった経緯

  • 社内でハンズオンをやることになり30個アカウントが必要
    • OrganizationsからAccoutを切り離す
    • 利用終了したら環境を綺麗にしたい。
      • セミナーのたびに一つ一つアカウント削除するのは手間
      • Organizations連携のAccout削除は面倒
    • アカウント入れ替えではなく、AWS Nukeを使うことに

AWS Nukeとは？

  • AWSアカウントからすべてのリソースを削除する
  • 特定リソースのみ削除、削除対象外にすることも可能
  • 細かいフィルタ指定も可能
  • 管理用リソースをSCPでDelete不可にして、Nukeで全リソース削除を実行
    • 消したいものだけ全削除できる。
  • 検証環境や繰り返し利用したい環境に使うと便利

SNSのサブスクリプションが消せない！ emiさん

資料

speakerdeck.com

AWS CDKにふまんがあります　Tech Do 塚原さん

資料

speakerdeck.com

文句をいうのはわるいこと？

  • 良い文句と悪い文句がある。
    • 良い文句：フィードバック、事実、リスペクト
    • 悪い文句：クレーム、理不尽、ハラスメント
  • 欧米ではクレームは創造的な行為という認知が一般的
  • 伝え方が大切
  • 不満を上手に伝えよう
    • 感情的にならない
    • 事実と主観を区別する

AWS CDKへの不満

  • CDKのすごいところ
    • 頻繁なバージョンアップ
    • デバッグがはかどる
  • 不満
    • デフォルトプロファイルが適用されない
      • あらかじめprofile定義して、コマンド実行時に都度指定
    • エラーメッセージが分かりづらい
      • High/Low Level Constructを混ぜれない
      • 重い
        • 10分待つのはザラ
        • 待ち時間が手持ち無沙汰で生産効率低下
  • 不満があるのはそれだけ好きになっていること

最後に

あしさんのアウトプットについてのお話聞いて、また朝会で登壇したい欲が出てきました。 来月は応用情報技術者試験も終わってるので、また登壇したいです。 そちらの勉強が中心になっててAWSの勉強量がここ2か月くらいは少なくなっているので、まずはネタ探しから。

塚原さんのお話聞いて、不満があるのは、それだけ一つの技術に惚れ込んでガッツリ使い込んできた証拠だなぁと思いました。 そこまでして出た不満はとても建設的な意見だし、サービスの改善になると思います。自分には好きなところと不満の両方を言えるだけの技術やサービス（AWSに限らず）はまだない… 自分が関わっていることやサービス、物など、ガッツリ深掘りしてみようと思いました。それが登壇のネタになるかもしれない。

最近精神的に余裕がなく、勉強会に腰を据えて参加できていませんでした。すごく久々に勉強できた感じがしました。 久々にブログも書けて良かったです！無理のない範囲で少しずつ心の余裕を取り戻して、勉強会に参加したりブログ書きたいです。

JAWS-UG朝会 #24 参加レポート

AWS 勉強会レポート

8/26（木） JAWS-UG朝会 #24 に参加しましたので、レポートを書いていきます。

目次

イベントページ

jawsug-asa.connpass.com

セッション概要

EC2 の起動するインスタンスタイプを制限する方法 小倉 大さん

資料

www.slideshare.net

AWS Service Catalogで制御

IAMポリシで制御

  • IAMポリシ内に追記する。
  • ポリシを適用したIAMユーザが指定外のインスタンスタイプを起動しようとすると、権限不足で作成失敗する。

AWS Config で制御

  • AWS Configとは？

    • AWSリソースの設定を評価、変更管理

  • パラメータでインスタンスタイプを指定

  • 指定インスタンスタイプ以外を起動しようとすると警告が出る。
  • Configルールの修復オプションを設定

まとめ

起動するインスタンスタイプを制御することで、意図せず大きなインスタンスタイプを選んで高額請求が来ないようにできる。

利用するリージョンを限定しよう 〜 「おひとりさまOrganizationsのススメ」 波田野 裕一さん

資料

speakerdeck.com

利用するリージョンを限定しよう。

  • Organizationsのポリシ（SCP）を利用する。
  • 子アカウントならrootさえも制約される。
  • 親アカウントの制限はできない。
  • 組織ツリーを作り、SCPをアタッチする。
  • 利用しているリージョンやサービスをSCPで制限する。

Organizationsの理想的な構造

  • SCPが効かないので、親アカウントには支払以外やらせない。
    • ベストプラクティスに合致
  • 子アカウントには使うリージョンのみ制約する。

まとめ

個人でもSCPで「使っていないリージョン」への攻撃を防ごう！

AppSyncに全集中！subscriptionでハマったところ　三浦 一樹さん

資料

speakerdeck.com

  • 番組テロップみたいに、動画の外側も番組内容に合わせて情報を切り替えたい。
  • AppSyncとは
    • GrpahQLのマネジメントサービス
  • Subscriptionを有効にし、WebSocketでデータを受け取るセッション張れるようにしているところ。
  • AppSyncのSubscriptionきっかけに前ユーザにQueryをリフェッチするのは、アンチパターン
    • 1秒間に1000アカウントまでのため、見てる人から一斉にQueryが来るとマズい。
  • 回避策
    • AppSyncの上限緩和申請をする。
      • DynamoDBのホットパーテーション（300RCU）に引っかかるので、根本解決ではない。
    • QueryをAPI Gateway + Cache + Lambda + DynamoDBにする。
    • Subscriptionで降ってくるデータだけで表示変更する。
      • これがあるべき姿。

ユーザ企業所属の初学者による「AWS認定のすゝめ」 小林未来さん

資料

www.slideshare.net

なぜAWS認定を？

  • ベストプラクティスを知りたかった。
  • 自信を持ってPJ推進したかった。
    • SAさんときちんと会話できるようにしたい。

認定取得してどうなった？

  • CLF取得後、NACLとSGで何となく制御していたのをSG制御に統一した。
  • SAA取得後、Systems Manager とCloudWatch Agentを利用してハイブリット環境を実現した
  • SAP取得後で、RTOとRPOをきちんと決めて手順と自動復旧を決定した。

まとめ

  • AWS認定学習はAWSを「きちんと利用する」きっかけんある。
  • さまざまなユースケースを学習でき、新ビジネスの足がかりになるかも。
  • ユーザ企業が自走するきっかけになる。

感想

小林未來さんの認定取得ペースと業務に還元できている姿は驚異でした。ただただ見習いたい！自分も勉強したことを業務に活かしたいと思いました！！

リージョン制御とEC2インスタンス制御は早めにやった方がいい！と危機感感じました。 どちらかというと、自分のように個人利用している人はやっておいた方が良さそうに思いました。数百万の請求とか来たらまったく笑えないし…

今月は参加できるか怪しかったので登壇での参加申し込みはしませんでしたが、いろんな意味で危機感感じる会だったなと思いました（汗）。 参加出来て本当に良かった！と思うばかりです。

今日の登壇者皆さんのお話を聞いて、参加者に何か感じ取って持って帰ってもらえるような話をできるようになりたいと改めて思いました。 先月まで3か月連続で登壇させていただきましたが、たぶん自分はそんなレベルの話はできていなかったなと、ふと思いました。 登壇のレベルを上げられるよう勉強を続け、また登壇参加したいです！

AWS Startup Tech Meetup Online #7 参加レポート

AWS

8/25（水）AWS Startup Tech Meetup Online #7 「【Day1】あつまれ！大企業/SIer 出身スタートアップエンジニア！！」に参加しましたので、レポートを書きます。

目次

イベントページ

aws-startup-community.connpass.com

アーカイブ

www.youtube.com

セッション概要

Happy building with AWS App Runner Tori Haraさん

App Runnerとは？

  • WebアプリやAPIサービスなどステートレスサービスを、非常に高い抽象度でシンプルな体験で実行できるサービス。
    • Amazon ECRにコンテナイメージを置く、またはGitHubにコードをPushすると、App Runnerにコンテナをデプロイする。
  • マネジドロードバランサを持っており、エンドユーザーはこのLBにアクセスする。
  • Auto Scaling対応。
  • デフォルトでブルーグリーンデプロイを行う。
    • LBの向き先も自動で変えてくれる。
  • アプリケーションログは標準設定で、CloudWatch Logsに送信される。
  • App Runnerはアプリケーション部分のみがユーザの責任範囲となる。それより下はAWS側の責任範囲。
    • ビジネスにフォーカスしたいスタートアップにとっては、責任分界点を上げることはコスト削減の観点で重要。

Progate から「創れる人」は生み出せるのか？ 島津 真人さん

創れる人とは？

  • 解きたい課題があるとき、手を動かして解き進めることができる人。

最短で創れる人になれるよう「知の高速道路」を整備したい。

  • 基礎的なプログラミングを躓きなく体験できる環境を作りたい。
  • 初心者向けには躓きなくできるが、そこから先を広げたい。
    • そのためにはプログラミング以外の要素を経験できる環境も必要（鋭意制作中）
      • 環境構築
      • エラー分析
      • デバッグ
      • 問題の分割　など

新卒2年目、何も分からず始めたスタートアップでやってきたこと 鈴鹿 優太さん

  • 突如見知らぬ大学生からDMが来た。出会って1時間で一緒に起業を決意した。
  • いろいろやって気が付いたら、CTOをやりつつUIデザイン・エンジニア・PdMをやっていた。
  • プロダクトしてのコンセプト、作りたい世界観を考えるようになった。
    • 大切なのは作りたい世界観。それを映像でイメージできるように。
  • 経理労務まわりもやりつつコラボレーションしやすい組織を作る。

SaaSのプロダクトを飛躍させるSIerの仕事術　渋谷 和暁さん

SIerでもSaaSでも本質的なスキルセットは同じ

  • いかに課題を見つけることができるか。
  • ユーザの課題をどう解決するか。誰でも分かるように書くことはすべての基本。
  • ドキュメントの内容をどう構築するか。アーキテクチャの考えはどんなシステムでも普遍的。
  • タイミングや目的は違えど合意を取る行為は変わらない。細かいコミュニケーションはいつでも大切。
  • テストすべき項目は決まっている。どんなシステムでもテストの勘所は変わらない。
  • 「丁寧」の定義は人・組織で異なるが、丁寧に仕事をすることはいつでもどこでも超重要。

SIerではやらなかった自己決定するスキルを身に付ける必要がある。

  • スタートアップでは誰も正解を知らない。
  • ユーザが仕様を判断してくれるわけではない。
  • 強い気持ちで自分たちが決める必要がある。
  • SIerでしなかった「自分で決断」しないとむしろダメ。

役職の変化に見るスタートアップのスピード感 岩成 達哉さん

スタートアップに向いている人

  • 役職に拘らない人
    • スタートアップは何でもやらないといけない。
    • 責任と権限の順番は鶏と卵
  • 自分ドリブンで動ける人
    • 当事者意識がある人
    • 自分で問いを見つけて解決方法を考えないといけない。
    • 仲間は助けてくれるが引っ張らないと会社の成長に置いていかれる。
  • アンラーニングできる人
    • フェーズの違いで必要とされるものは異なる。
    • 自分より出来る人がいたら代わるべき。そうならないように必死で成長する。
    • 謙虚さと新しいことに挑戦する気概。

最後に

重大なビジネスにおける決断の最適解を見つけ、事業を推進することは、普通の企業だと役職者にならないと経験できないことだと思います。 その苦労とプレッシャーは並大抵ではないと思いますが、自分が情熱を注げるミッションであればその分やりがいを感じられそうと思いました。 今の自分がスタートアップ企業で働くことは想像できませんが、少し興味が湧いてきました。

スタートアップ企業でなくても、仕事に取り組むためのマインドを多くアウトプットしていただき、とても刺激になる会でした。 来週にはDay2があるため、また参加したいです。

aws-startup-community.connpass.com

Happy Hacking Keyboard（HHKB） Lite2 for MacをWindowsで使ってみた

雑記

今日、たまたま近所のハードオフを見に行ったら、Happy Hacking Keyboard（HHKB） Lite2 for Mac を見つけました。

以前からHHKBには興味があったものの、Happy Hacking Keyboard Professional は値段が高く、おいそれと手が出せない物でした。 また、HHKB LIte2は生産が終了しており、中古でしか手に入らないものになっていました。

Mac用ということもありちょっと悩みましたが、PFU社のサイトでfor Mac は、Windowsでも使えることを書いていたため、HHKB触ってみたさに購入しました。余裕で手が出せるお値段でしたし（笑）。

faq.pfu.jp

早速試しにHHKB Lite2でこのブログを書いてみます。

目次

HHKBとは

株式会社PFUより販売されているキーボードです。HHKB Lite2 は、メンブレンスイッチ仕様の廉価モデルです。 詳しくをWikipediaを参照してください。

ja.wikipedia.org

購入してみようと思ったキッカケ

HHKB触ってみたさもありましたが、5月にMicrosoft Sculpt Ergonomic Keyboard（以下、Ergonomic Keyboard）を購入して使っていました。 （ブログには書いていませんでした…書く機会を逃していました…）

肩こり対策としては良かったかもですが、打ちづらさを感じていました。 自分のタイピングが下手、もしくは慣れていないだけかもですが。。。 他のキーボードを購入して使い比べてみようと思ったためです。

ちなみに、中古とはいえ状態は悪くなかったです。少し黄ばんでいるとのことでしたが、そんなに気になりません。

f:id:amarelo-n24:20210815234547p:plain

とりあえず使ってみた感想

Windows10（20H2）のPCに接続してみました。ちゃんと使えました！ ひとまず、HHKB Lite2 を2時間くらい使った感想を書きます。

文字の打鍵については、HHKB Lite2の方が打ちやすい感じがしました。 細かいところですが、キーボード本体にUSBハブ機能が付いているのは良いなと思いました。 トラックボールのレシーバーを指してみましたが、何の問題なく使えてます。

f:id:amarelo-n24:20210815234756p:plain

一方、これまで普通のキーボードを使い続けていたためか、

  • ファンクションキーがないこと
  • 半角全角の切り替えキーの場所の違い
  • Ctrlキーの場所の違い

にはまだ戸惑いを感じています。ショートカットキーとファンクションキーを結構使うので、慣れるまでに時間がかかるかもしれません。 ただ、慣れてファンクションキーをうまく使えるようになると、指の移動は少なく済んで入力効率は良くなるかもしれません。 何気に矢印キーを押すときにタイプミスすることが多いし、ファンクションキーを押す時は意識的に手を広げなければならない（手があまり大きくない）ので、 使いこなせれば、最短距離で打鍵できそうに思えました。

※ファンクションキーは、Fn + キーキャップの側面に書いてあるファンクションで可能（例えば、F1 の場合、Fn ＋ 1）。

f:id:amarelo-n24:20210815235205j:plain

※上下左右はこちら。例えば、左の場合は[Fn ＋ ; ]。

f:id:amarelo-n24:20210815235232j:plain

他にも、Windowsキーがなくて最初焦りました（汗）。しかし、これは、Fn + ⌘ を一緒に押すことで対応可能です。 例えば、ウインドウの最小化のショートカットキーは、[Windowsキー + D] ですが、HHKB Lite2 for Mac の場合は、[Fn + ⌘（コマンドキー） + D]で可能です。 結構多用するショートカットキーでしたので、使えなくなると逆に生産性が落ちると懸念していましたが、杞憂に終わって良かったです。

最後に

まだErgonomic KeyboardとHHKB Lite2、どちらが良いかはわかりませんので、両方とも使い込んでどちらが使いやすいか検証してみたいと思います。

いずれブログに書けたらと思います。

応用情報技術者試験を受験します

雑記

タイトルの通り、今年秋のIPA情報処理技術者試験で「応用情報技術者」を受験します。

これまで、情報セキュリティアドミニストレーターやネットワークスペシャリストなど高レベルの試験に挑戦してきましたが、ここに来てなぜ応用情報技術者を選択したのか、書き留めておこうと思います。

応用情報技術者試験とは？

www.jitec.ipa.go.jp

筆者のスキルセット

以前も書きましたが、自分は、コーヒー焙煎人兼エンジニアと名乗っていますが、堂々と誇れるエンジニアスキルはあまりありません。今までにネットワーク構築やアプリ開発にガッツリ関わった経験もほとんどありません。 そんな人間ですが、とある企業の情報セキュリティ統括担当者をやっています。IT技術、特にセキュリティとネットワークについては必要性を強く感じて独学で勉強してきました。これまでに、

を取得しました。ちなみに、理由は伏せますが、情報処理安全確保支援士（以下、支援士）には登録しませんでした。今のところ、再受験及び支援士に登録する気はまったくありません。

応用情報技術者を受験しようと思った理由

主に以下の３つです。

  • そもそも応用情報技術者を受験していない。
  • 高度試験への挑戦に限界を感じたから。
  • 今後強化したい分野を再確認したい。

そう思った経緯

上述の通り、セキュリティとネットワーク知識の必要性を強く感じて、情報セキュリティアドミニストレーター（以下セキアド）とネットワークスペシャリスト（以下ネスペ）を勉強してきました。しかし、そこで応用情報技術者を受けようとはまったく思わず、2019年秋にネスペを受験することにしました。それ以前にセキアドに受かったからというだけのあまり根拠のない自信からそう思ったのでしょう。さらに、2019年秋試験で不合格だったものの午前１試験を通過したことから、次の試験は午前１免除を使えるうちにネスペ再チャレンジしようと思ったのでした。

2021年春（2020年はコロナ禍の影響で延期）にネスペ再チャレンジしましたが、午後１で敗退…

二度も午後１で不合格だったことから、そもそもネスペ以前のレベルでは？と思ってしまいました。これまで応用情報は一度も受験したことはなく、応用情報レベルの知識を身に付けて結果を出していません（セキスペには合格したものの、支援士に登録していない以上、堂々と「結果を出した」と言い張れるものではありませんし）。たぶん、セキスペ合格とネスペ午前１通過は、色々と上手くいってただけなのかなと…そう思ったら、現時点での高度試験への挑戦に限界を感じるようになりました。

また、土台の部分が固まっていないと、今後ネスペに挑戦し続けて仮にどこかで合格しても、投資し続けたコストに見合う仕事ができるか、不安になりました。というか、「本当にネスペでいいのか？」も見つめなおした方がいいかもと思いました。

以上から、応用情報技術者の勉強を通して知識の再確認と地固め、今後伸ばしたい分野の見直しをした方が良いと判断しました。

なお、AWS認定SysOpsアドミニストレーターアソシエイト（SOA）を9月に受験しようと考えていましたが、そちらは受験時期を少し遅らせるかもしれません。勉強して自信があれば受けるかもですが、焦る必要はないかと思います。応用情報と一緒に勉強して、両者の知識をうまく深められるように工夫して勉強したいです。

実際に勉強してみて

8月に入ってすぐに応用情報技術者の受験を決め、参考書もすぐに購入して勉強開始しました。思いの外、基礎理論とコンピュータシステムの分野についての理解が低く、午前問題を自信もって解けませんでした。「ほんとよく今日までIT業界で仕事してきたもんだなぁ（汗）」と思ってしまいました。気づいたのは遅かったかもしれませんが、遅すぎることはないはず（たぶん）。今回は丁寧に勉強して理解を深めた上で午前も午後も臨みたいと思いました。

ちなみに、今読んでいる参考書は以下です。

book.impress.co.jp

物理本買うことで、物理本の全ページのPDFと過去問（午前午後共に）の解説をPDFで読むことができます。在宅勤務や休日は物理本で、出社やちょっとした外出時の隙間時間にはPDFで勉強するようにしています。

最後に

まだ勉強し始めたばかりですが、もう試験日（2021/10/10）まで2か月切りました。夏季休暇期間も勉強をしていますが、もっとペースを上げなければ（汗）当日の試験に余裕もって臨めるように。

応用情報技術者試験が終わったら、勉強方法を詳しく書きたいと思います。堂々と書けるように、合格したいです！