[LSM] 認定スクラムマスター(Licensed Scrum Master)合格体験記/研修概要

LSM/研修の概要

LSM(Licensed Scrum Master):認定スクラムマスター

  • スクラムマスター資格として有名な、二つ(LSM, CSM)の一つ
  • LSMはScrumの生みの親のジェフ・サザーランドが監修している

LSMとCSMどっちがいいか?

  • 結論としてはどちらでもOK
    • 会社で枠が空いている方にしました。また、個人で費用を払うならLSMの方が安価
  • LSM研修について
    • Scrumの生みの親が監修しているだけあって、内容は素晴らしかったです
    • スクラム経験者から見ても、為になるプラクティスが多かったです。後輩にも受けさせたい
    • 少なくともLSMにして後悔することはないと感じました
  • CSM: Scrum Aliance 認定スクラムマスターは以下のようなイメージ
    • 講師は意図的に厳しいスタンスを取る為、演習が非常にハードらしい
    • CSMは2年で有効期限を向かえて2年毎に更新料$100が発生する
  • 以前取得したEXIN Agile Scrum Foundationで得た知識もとても役立ったが、メジャーな資格ではない
    • LSMを受けるまで表面だけしか分からないプラクティスも多かった

LSM研修概要

  • Scrum Inc. Japan主催
  • 2日間 9~17:30
  • ワークがメイン
    • 参加者達を複数のスクラムチームとして分ける
    • スクラムを学ぶという行為自体をスクラム開発PJとして進めます
  • 各チームにScrum Inc.のトレーナーがつく
    • 質問の機会が多く、普段の業務で溜まっていた疑問を全て解消できた

試験の概要

  • 試験準備
    • 研修終盤に、Scrum Incのサイトで登録を行う
    • 指示に従って、マイページ登録を完了すれば受験可能な状態となる
    • 好きなタイミングで受験可能だが、推奨受験期間は90日以内
  • 試験概要
    • 形式:オンライン
    • 選択式30問
    • テストは2回まで無料で受験可能(3回目から有料)
    • 試験中に手元の資料を参照することができる

試験までの学習

  • 学習すべき事項は以下の三点
  • スクラムの別の資格を取得済みで基礎知識があったので、研修受講後に即受験した
  1. スクラムガイド
    • 以下が重要
      • スクラムの理論、価値基準
      • ロールと役割
      • Event
      • Output
    • スクラムの理論(透明性、検査、適応)と価値基準(確約、集中、公開、尊敬、勇気)が各イベント、アウトプットにどのように関係しているか理解しておく
  2. アジャイルソフトウェア開発宣言
    • スクラム開発を始めた際にメンバによく見せるページ
  3. アジャイル宣言の背後にある原則

試験本番

  • ScrumIncのサイトから開始
  • 時間制限は特になし
  • 資料を見ながら受けられる
    • 細かい用語はスクラムガイドや研修のスライドで確認しながら進めるイメージ
  • 講習受講後に即受験して正答率は 28/30(93%)
    • 元々別のスクラム資格を持っていて、スクラム開発を経験していることもある
    • スクラム経験無しの場合、研修受講だけでは少々戸惑いそうな問題も散見された
      • スクラムガイドや研修のスライドを読み直してから受験すると良さそう
  • 受験後に間違えた問題も確認できる
  • 合格後に試験を受けたサイトで認定証(pdf)をダウンロード可能になる
  • 期限は1年間
    • 更新料は5,000円

LSM取得後のラーニングパス

研修のノート

自身のScrumチームに適用できそうなこと

  • スプリントパターンの適用(研修スライド参照)
    • スウォーミングが重要
      • 「チームの全員が、最優先のバックログアイテムが完了するまで、それに集中すること」
      • タスクの担当を確定せずに手が空いたメンバが消化していくべき
      • 優先度の高いPBIがIn Progressであれば、リソースを集中させるべき
  • アフィニティ見積もり(用語リスト参照)
    • PBIを想定的なポイントで見積もる方法の一つ
    • S,M,Lだけでやっていたが、必要に応じてXS等も追加してよい
    • その後数値のポイントに変換する
    • ラベルごとに定義するPointはフィボナッチ数が望ましい
  • PBI毎の受け入れ条件
    • Task毎には設定しなくて良い
    • Task毎のDoDはAPI、フロントエンド等のカテゴリで同様になるため、共通のDoDにまとめる
  • SP計画について
    • 計画段階で担当者を確定させるとスウォーミングができなくなるのであまり望ましくない
    • 手が空いた人がやって良い
  • デイリースクラムについて
    • 朝会ではSPボード(カンバン)を映し、Milestoneの%を毎日見る
    • 可能であればPBI & タスクのバーンダウンを両方表示
    • パーキングロットを適用する
      • 議論を掘り下げる必要があるが、デイリースクラムから溢れる時に活用するプラクティス
      • パーキングロット(駐車場)を作って議論が必要なものを一時停車しておく
      • 議論に参加する必要のある人だけが後に残り、他の人はSPバックログの仕事に残る
  • SPレビューについて
    • Velocityはステークホルダーにもここで見せるべき
    • スプリントサマリ(スライドp210)
    • PBIを基に、リリースまでのバーンダウンチャートも見せる(SP毎のバーンダウンとは別)
  • レトロスペクティブについて
    • 改善バックログを採用する
    • Velocityは本来PBIで図るべきだが、Velocityの低い状態ではタスクで図ってもOK
  • Scrum of Scrumについて
    • サービス群を管轄している上位者をCPO(チーフプロダクトオーナー)と置き、ハイレベルのバックログを提示して頂く
  • Scrum@Scare
    • 大規模な組織にスクラムを広げていく手法。良いチームをまずは二つ作って、そこを真似る形でスケールしていく。自社でも適用できそう

ノート

デイリースクラム

  • コミュニケーションの浸透度と仕事の進み方に相関がある
  • 前回のDSから何をしたか?
  • SPゴールの達成を妨げる障害物はないか?
  • SPゴールを確実に達成するには次に何をすべきか?
  • パーキングロット
    • 議論を掘り下げる必要があるが、デイリースクラムから溢れる時に活用するプラクティス
    • パーキングロット(駐車場)を作って議論が必要なものを一時停車しておく
    • 議論に参加する必要のある人だけが後に残り、他の人はSPバックログの仕事に残る

Scrum of Scrum(SoS) p156

  • 協力する必要があるチームの集まり
  • チームの中のチーム
  • チーム毎のSCMが連携する
  • POも複数にして良い
    • ハイレベルのバックログを作るチーフPO
    • Teamごとのバックログを作るPO
      • TeamごとのPOは一人
  • ハイレベルのバックログを作るチーフPO

Scaled Daily Scrum(SDS) p157

  • スクラムオブスクラムマスター(SoSM)がファシリテートするイベント
  • チーム横断の調整を可能にする
    • SoSのSpゴールを実現するために再計画をする機会
    • 可能であれば、障害物を表面化させて除去
    • 継続的改善のための学習を共有する

Scrum@Scale

  • チームの集合をSoSと呼ぶ

  • Whatの整理方法

    • Shared Backlogに責任を持つのがCPO
    • Module毎にPOを立てる
    • CPOとPOたちが集まってTeam Backlogに分解していく
  • 各Teamのインクリメントを統合することで一つの価値になる

  • Scaled Daily Scrumでチーム間調整を実施

  • ハイレベルのバックログをCPOに作ってもらうとよい

  • PdMについて

    • POより業務範囲が広いイメージ

PBの見積もりについて

  • デルファイ法についての研究

    • 人間は絶対的な見積もりよりも想定的な見積もりが得意
    • 専門家は1人で見積もる必要がある
      • アンカリング(他の意見に引きずられる)を避けるため
  • アジャイルな見積もりの戦略 p156

    • speed, time, distanceのうち調整できるのはdistanceのみ
      • そこで見積もるStory Pointを調整する
    • 時間を見積もらない
      • ストリーの相対的な大きさを見積もる
      • SPごとにベロシティを測定する
      • リリース計画を導出する
    • 見積もりは実際の作業をする人たちが行う
    • PJの開始前だけでなく、期間を通じて常に見積もりを行う
    • 詳細に記述したドキュメントよりも、口頭での会話を用いる
  • MSにおける見積もりの正確さ p157

    • Pointの方が正確
  • NJ Telecom

    • Pointの方が見積もりにかける時間も50倍早い
  • アフィニティ見積:相対サイズに選別

    • XS,S,M,L,XLをPBIごとに定義
      • 足りなければX○を増やしても良い、チームで考える
    • 相対サイズをポイントへ置換 p161
  • 国防コントラクター

    • チームはポイントの方が幸福
  • リファレンスストーリー

    • 相対サイズの見積もり
      • これからやる仕事と、よく知っているorDone済みの仕事とを大きいか小さいかを比較すること
    • 様々なサイズのリファレンスストーリーを選び、「ものさい(定規)」を作成する
    • 古くなったらUpdateする
    • フィボナッチ数にする理由
      • 数理的分析により、指数的に大きくなる方が、線形に大きくなるより見積もりに向いている
  • プランニングポーカーの無料アプリ

    • iPhone: Scrum Inc Poker
    • Android: Scrum Planninf Poker
  • 正確な見積もりの手法: Planning Poker

    • 開発者メンバーフィボナッチ数が一つづつ書かれたカードを配る
    • 合計の数字が三つの数のハニに治っていれば、合計して平均値を出し、次のタスクに移る。(平均して四捨五入)
    • 4つ以上に跨っている場合
      • 最小値と最大値を出したメンバが根拠を説明
        • 議論はしない
      • 再度全員でカードを出す
      • 合計3回繰り返しても治らない場合は、最大値と最小ちを除外し、残った数の平均をとる
    • すり合わせは不要。コンセンサスを目指しているわけではない
    • 最終的な見積もり値はフィボナッチ数にならなくてもいい
    • 基準を一つきめて、そこにフィボナッチ数を定義してからスタートする
  • 見積もりでの重要な点

    • 決してチーム間で見積もりを標準化しない
    • 決してチーム間でVelocityを比較しない
    • Velocityが50ポイントのチームは30ポイントのチームより実際は遅いかもしれない。ポイントはチーム内の相対値。したがって標準化はできない
    • ベロシティの傾向(トレンド)はチーム間で比較できる

リリースプランニング

  • POがリリース計画、日付、ROIを受け持つ
  • 1つのSP分を準備完了(Ready)のPBにする
    • →チームが始められる
  • 2つのSP分を準備完了(ReadyのPBにする)
    • チームが加速する
  • リリース計画を立てる
    • 顧客がデリバリー日を信頼できる
    • 会社が収入を予測できる
  • 年間ロードマップを作る
    • 会社の戦略を顧客に簡単に説明できる
    • 会社に明確なビジョンができる
  • リリース日に関する重要な数値
    • PBの見積もり
    • Undone作業(DoDの外側の、デプロイに必要な作業)
    • 後発的な要求

PBI

  • PB→リスト自体のこと(一つ一つのことではない)
  • PBIがPBの項目
  • 例:〜〜の情報を管理できる=エピック
  • ストーリー=PBI
    • 登録できる/編集できるなどのアクション単位のイメージ
  • PBIを分解したタスク
      • 登録機能のAPI開発
      • フロントエンド開発

Velocityの測り方

  • タスクにSmall, Middle, Largeを定めているが、Velocityの測定方法としてどうか?
    • タスクレベルの見積もりは不要で、PBIのみが望ましい
    • Story Pointの方がいいか?
      • SMLをポイントに変換すれば良い
    • 3段階程度にしなければ破綻すると別の研修で習ったことがあるが、XS, XLも足して良い?
      • 問題ない、必要があれな足すべき
  • PBIに関して、一部の作業のせいで開発後半までDoneとできない場合はどうする?
    • チームとしてのDoneを決めて、Doneとしても問題ない
    • ただし、Undoneを定義する
      • チームのDoDとユーザーに提供するまでのGAP
      • これをバックログとして何SPか見積もっておく
      • リリーススプリントの作業はここに定義される

POが開発するのは問題か?

  • ミニマムなチームで回るのであれば問題ない
  • POの稼働もVelocityに数えてもいい

スプリントボードの注意信号

  • 目で見るフロー管理ツール

  • スプリントボード

  • SPプランニング時点で明確にアサインしない方が良い

    • スウォーミングができなくなる
    • 手の空いているメンバにアサインし直していくべき
  • スクラムボード

    • TO DO, DOING, DoneがあればOK
    • To Do
      • PB
      • Release Burndown Chart
    • Doing
      • Sprint Board(看板)
      • SP Goal
    • Done
      • Reviews
        • インクリメント
      • Velocity
        • 毎回のSPでどの程度のVelocityか
  • ex. Miro/Muralでスクラムボードをまとめる

バリューストリームマッピング

  • 制約理論と継続的なフロー

    • ビジネスチームの検討や投資審査がボトルネックになっている
    • 対応 → 審査単位を小さくする
  • 無駄な待ち時間を減らすには

    • PBIの最小化
  • スライド p209例

    • 開発開始まで6ヶ月待ち → 開発期間は3ヶ月というパターンが多い
    • プロダクト開発の高速化は、要員追加よりも、プロセスの改善で達成できることが多い
    • バリューストリームマッピングはボトルネック検出の優れたツール
    • スクラムはボトルネック除去に優れたツール
      • 落とし穴:局所最適化
      • 開発チームだけでスクラムをやっても効果が薄い
      • 関連チームまで含めたスクラムが必要

スプリントレビュー

  • インクリメントをステークホルダーにデモし、フィードバックを求め、バックログに反映する

    • スクラムチームはSPゴールとSPで作成したインクリメントについて、デモと話し合いを行う
    • ステークホルダーの反応とプロダクトのFBを収集することが重要な成果
  • インクリメント:最終的な成果物

    • 調査、研究や新しいプロセスも含む
    • 価値があるもの、検査できるもの
  • プロダクトインクリメント

    • SPゴールを達成した全てのPBIの総和
  • 完成の定義はプロダクトのインクリメントに対するコミットメント

  • SPレビューからの成果物

    • 出荷可能なプロダクトインクリメント
    • Velocity(完成したもの)
    • フィードバック
  • SPサマリーの参考 スライド p217

ストーリーに含まれないユーザーにとって価値のない作業はどう扱う?

  • PBIとして含めていい
    • 例:CI/CD Pipelineのような共通作業
    • チームがやるべき仕事は全てPBに入れるべき

スクラムマスターが置かれる状況と対策例

  • Case: チームの中の上級エンジニアの存在

    • 問題
      • 議論の全てを個人が支配している
      • 人的依存
      • 作業に取り掛かる際にまず相談
    • どのようにコーチできるか?
      • ルールで心理的安全性を作る
        • 自由に意見を出しやすい環境の整備
      • メンバの自立を促す
      • 作業に取り掛かる際にまず相談
        • -> SP計画 アーキテクチャを定めてしまい、曖昧さを残さない
  • Case: 繰り返される持ち越しバックログ

    • 根本原因
      • ❌SPの期間が短い?
      • チームはできると思っていたか?
      • 能力不足だった場合?
      • SP計画がうまくできていない
        • Velocityを把握できていない、バーンダウンを見ていない
    • SCMとしてどのようにチームを助けられるか?
      • 期間の変更をPOに提案
        • 納得感のある改善案とセットでなくてはだめ
      • レトロスペクティブ
        • KPT出し→障害物のバックログを設ける
      • PBIを小さくできないか?
      • 能力不足だった場合は?
        • ->見合ったものにする
      • Velocityをうまく把握させる
        • バーンダウンチャートを使う
      • 外部のテックリードに支援を仰ぐ
      • Velocity以上にできると言わない
      • レビュー以外のタイミングでいつでも見れるメトリクスを用意する?
        • バーンダウンチャートを見せる
  • Case: デイリースクラムの問題

    • やる気がない、気が散っている、状況報告以外話さない
    • 原因
      • スクラムボードをみんなで見る機会を設けていない?
      • 固定的なアサインがされている
        • デイリースクラムの目的が理解されていない
    • どのように助けられるか
      • まずは理由を聞く
        • 幸福指標を図る
      • 時間の見直し
        • 昼回にする?
        • 何かとかぶらない時間にする
      • スクラムボードやバーンダウンチャートを見るコーナーを設ける
  • Case: 孤立した専門職のチームメンバー

    • 起こりうるリスク
      • 人的依存によりタスクが滞留
    • 彼にアジャイルなマインドを少しでも理解してもらうために何ができるか?
      • アジャイル憲章を理解させる
      • 助け合いの空気感を出す
      • チームとしての成果を共有する
      • 弟子をつける

ベロシティを高める11の方法

  • 小さなチーム
  • Readyのバックログ
  • T字型の人

効果が高そうだが、適用が難しいプラクティスと対策

  • スウォーミング
    • 難しくしている要因
      • メンバのスキルが限定的
      • 割り込みが多い
    • 改善策
      • スキルアップ/育成
      • T字型メンバを一人は入れる→周りにも教えてもらう
      • 会議時間の効率化/短縮
      • スキルマップを作って計画的に育成していく
  • 俗人化の排除
    • 難しくしている要因
      • メンバのスキルが限定的
    • 改善策
      • 手順化 → 自動化(CFn/SAM Templateなど)
      • 一般的に使われていないフレームワークを避ける
      • 必要な技術スタックを減らす
        • フロントエンドエンジニアがいたら、バックエンドにNodejsを使うなど
  • 開発チーム以外も含めたスクラム的な進め方
    • 難しくしている要因
      • WF前提のルール
      • ステークホルダーの理解
      • 審査プロセス
    • 改善策
      • ステークホルダー(上位者)の理解
      • 実績と効果を見せる
      • お客さんがいない場で取り込んでいく
      • 投資対効果を見せていく
      • ステークホルダー/上位者向けに教育する
        • Scrum Inc研修にリーダークラスを入れる
        • アジャイルのマインドセットだけの研修をよく開催されている
      • アジャイルが適している理由が示せればいい
      • 承認を小さく通す
        • プロトタイプで承認を通す
        • PoCで年間いくらで通す

SCMやPOが倒れたら?

  • POサポートが一人入ることは多い(PBIをReadyにする等)

幹部に生産性を示せと言われたらどうする?

  • ROI 投資対効果を示す
    • インクリメントのビジネス価値
    • これだけの費用/労力でこれだけの価値を産みましたと話す
    • プロダクトの価値を判断するメトリクス/KPIを策定して示す
  • 価値説明はPOの責任
  • Velocityの変化率を示す

自分がPOでSCMが未熟な場合は?

  • SCMをコーチングして育成する。SCMには横の連携が重要

参考

関連記事

その他

AWS Developer Associate 合格体験記/学習方法 [AWS認定4冠]

  • AWS Developer Associate 合格までの学習方法についての記録
  • 先にSAA, SOAを取得していたので、これでアソシエイト3種をコンプできました
  • SAA/SOAとDVAは試験の毛色が大分違う為相応の準備が必要でした
  • AWS認定のオンライン試験も初めてだったので、その辺りも書いておきます

試験までにやったこと

  1. AWS 公式研修: Developing on AWSの受講
    • 試験前にポイントと各モジュール末の問題を復習
  2. AWS WEB問題集
    • 2周 & 模擬試験
  3. AWS公式 模擬試験
  4. 書籍で問題集を実施
  5. AWS公式 試験対策ワークショップ
  6. AWS公式研修: DevOps Engineering on AWSの受講
  7. 公式ドキュメントを読む

0. 事前の知識レベル

AWS認定

  • 先に取得したアソシエイト試験

  • Developing on AWS研修受講前の業務経験

    • 複数のサーバレスアプリケーションのPoCを経験
    • CloudFormationやS3、CloudFront、WAF、AWS SDK等を頻繁に利用
    • Codeシリーズはあまり使っていなかった(Github Actionsなどを活用)
    • PO/SCM等のマネジメント寄りの業務や、SPA開発とそのHosting環境構築等を担当していたため、バックエンド(API Gateway, Lambda, DynamoDB等)を自ら手を動かして実装する機会に恵まれなかった

1. Developing on AWSを受講

  • 概要

    • 日程: 3days
    • テキストはGlimoreでPDFを閲覧する。受講後も閲覧可能。試験前の学習にも役立つ。
    • プログラムからSDKでAWSのサービスを動かす
    • 前提知識
      • AWSのサービスの知識
      • Java, C# /.NET, Pythonの実務的な知識
  • 所感

    • 費用を出して貰える会社であれば、確実に受講すべき
    • 各サービスの概要は基本的に別のAWSの資格取得時に理解していたが、Labで本業のPJ内で扱えていないサービスを触れたことが非常に大きかったと感じる
    • 特にCodeシリーズやLambda, API Gateway, X-Rayは必ず一度は触った方がいい
    • 本業ではNode.jsを活用しているので、研修のLabがJava, C#, Python縛りなのは残念であった
    • 研修内で講師が教えてくれる試験のポイントは本当に重要
  • 上位の研修として以下がある

    • DevOps Engineering on AWS
    • Advanced Developing on AWS
  • 試験直前に講師が話していた試験頻出ポイントを復習

    • 例:DynamoDBのRCU/WCUの計算方法(計算問題は必ず出る)
  • 各モジュール末の問題も復習した方が良い

2. AWS WEB問題集サイトを2周

  • AWS問題集サイト
    • AWS認定の学習で最も有名なサイト
    • 有料なので課金が必要
    • 過去にSAA, SAP, SOAもこのサイトで学習
    • アップデートのタイミングには注意
      • サイトのアップデートと公式試験のアップデートのタイミングがかなり離れている時は注意
      • 公式試験が改訂される直前にこのサイトでSAPやSOAの学習をして、本番が改訂版で大分違うという経験があります…
    • 少なくとも2021/9月末時点のDeveloper 認定ではドンピシャでした
      • 不安があれば、後ほど紹介する書籍も使った方がいいです
    • 模擬試験モードもある
  1. 問題集

    • 各7問 x DVA#40をコツコツ実施
      • サイト内でも他の試験と比較して問題数が少ないので楽であった
    • ミスした問題をMarkdownでノートに整理
    • 合格者は2周している方が多い
    • 回答後に表示される解説まで読んで理解しなければ、試験では太刀打ちできない
    • 解説のリンクや分からなかった問題を調べた際に登場する公式のホワイトペーパーを読むほど合格に近づく
  2. AWS認定試験モード(AWS WEB問題集でできる模擬試験)

    • AWS認定デベロッパー - アソシエイトを受験
      • 試験時間:130分
      • 65問題
      • 合格点:720点
      • 問題ストック総数: 280問
    • 1周目終了時点
      • 57/65問 855/975点 (87.69%)
      • 残り1時間程度を残して終了。だらだら進めたので、サイトの前半の問題は忘れている状態
      • サイト利用者の平均点は93.85%

AWS公式模擬試験

  • 概要
    • 本番よりもかなり難しい
    • 料金: 2200円(税込み)
    • 所要時間: 35分
    • AWS Web問題集は非公式であるため、公式の問題傾向は確認しておくべき。ここで問題の傾向が著しく異なっていたら注意

申し込み手順

  • 公式サイト/試験のスケジュールを立てる

  • サインイン

  • アカウントへ移動

  • 新しい試験の予約

  • ピアソンVUEで模擬試験をスケジュールする

  • DVA-P01: AWS Certified Developer - Associate Practice

  • 申し込みが完了するとメールが届く

  • 試験開始ボタンの押下で試験前の説明画面に遷移する

    • 申し込んだ当日に好きなタイミングで受験可能
  • 引っかかった問題は試験中にメモして後に確認した

    • Cognitoオーソライザーについてなど、WEB問題集では登場しなかった問題もあった

結果

  • 30分のうち20分程度で完了

  • 合計スコア: 65%

  • トピックレベルのスコア:

    • 1.0. Deployment 50%
    • 2.0. Security 60%
    • 3.0. Development with AWS Services 67%
    • 4.0. Refactoring 100%
    • 5.0. Monitoring and Troubleshooting 67%
  • 以降の学習では点数が低いカテゴリに重点をおいた(書籍で問題集を解いた)

試験の予約

  • AWS認定サイト
  • AWS Certified Developer - Associate
    • PSIによるスケジュール or ピアソンVUEによるスケジュールを選択
  • 試験オプションの選択
    • テストセンター
    • オンライン
      • 今回はこちらを選択
  • 試験の準備
    • PCのシステムテストは必ず実施すべき(会社のPCでは無理でした)
    • onVUEというアプリをダウンロードする
    • このアプリが頻繁に固まることがあるので注意
  • 確認ができたら次へ
  • 試験言語/試験監督の言語を選択
  • 日付を選択

4. 書籍:ポケットスタディ AWS認定デベロッパーアソシエイト

  • ポケットスタディ AWS認定デベロッパーアソシエイト

    • 最近Developer Associate対策専用の書籍が初めて出版された
    • 試験前の週末に購入
    • 試験問題集 50問を実施
      • 解説が丁寧でかなり理解が深まった
    • 「1章 公式サンプル問題と問題傾向、解説」
    • 模擬試験で点数の低かったカテゴリ(展開、セキュリティ、開発)の章末問題も実施
      • 解説が丁寧で理解が深まった
  • AWS認定3試験対策という書籍もある

    • 私はSOA受験時に購入してすでにやっていたので、今回の試験のためには使わなかったが、SAAやSOAを取っていない方には必要かも

5. AWS公式 試験対策ワークショップ

  • 概要
    • 定期開催されており、よくAWSからメールで案内が来る
    • 無料
  • 会社で業務時間内に受けてOKと言われたので受講
  • 所感
    • 暇があれば受講推奨
    • 試験のポイントを解説してくれる
    • 受けなくとも勉強すれば合格はできる
  • 試験前に章末問題と模擬試験などで引っかかったカテゴリのスライドを確認

6. AWS公式研修: DevOps Engineering on AWSの受講

  • 上位の試験の研修をDVA試験前に受講
  • この研修までに受験しようと考えていたが、結果的にDVAの対策にもなった

オンラン試験本番

  • オンライン試験について
    • 試験の30分前がチェックイン時間
      • スマホで部屋中を撮影して回るなど結構面倒
      • チャット形式で試験監督と会話する
    • モニターにつなげてはならない
      • なるべく大画面のPCを用意すべき
    • 試験中に部屋に人が入ってはならない
      • 子供が入ってしまう環境は危険
    • 余計な操作をするとonVUEが何度も固まるので注意
      • Command + で文字サイズを変更しようとしたり、試験開始後にチャットを操作したら、この事象が発生した
      • 事前のシステムチェックでは全く問題なく、試験開始後に初めて発生した
      • 一度PCを再起動する羽目にもなった
        • メールで届いたURLから復帰はできた
      • 固まったり途中離脱した際にも時間は進んだ状態で再開する。0からやり直しはできない
      • フルスペックのMacBookProで他のAPを閉じていたため、マシンのスペックの問題ではない。もしかしたら、Bluetoothで繋げていたLogicoolのマウスが問題となっていたかもしれない。何も繋げない方が良さそう
    • 正直なところストレスフルで最悪のUXだった

結果

  • 60分ほど残して試験を完了
  • 無事合格
  • 忘れないうちにDevOps Professionalも受けてみようと思います

参考

関連記事

Amazon API Gateway WebSocket APIでリアルタイム通信を行うチャットAPを開発 [SAR/SAM]

  • リアルタイムの双方向通信を可能にするAmazon API Gateway WebSocket APIについてのメモ
    • 活用例: チャットアプリ、金融取引システム
  • リアルタイムの双方向通信にはAppSyncを活用する手もあるが、条件によっては使えないことがあった(個人的にはAmplifyでAppSyncを自動生成するのが一番楽だと思います)
  • 下記はAWSブログで公開されていたリアルタイムチャットAPの開発方法とGithubに公開されているSAMテンプレートの内容の個人的理解のまとめ

Amazon API Gateway WebSocket API

WebSocketAPIとは

  • Amazon API Gatewayには以下の3種のタイプがある

    • HTTP API
    • REST API
    • WebSocket API
  • WebSocket API

    • リアルタイムでの双方向通信に用いられるAPIタイプ
    • 公式説明
      1
      2
      チャットアプリケーションやダッシュボードなど、リアルタイムのユースケース向けの永続的な接続を使用する WebSocket API を構築します。
      双方向の振る舞いにより、クライアント/サーバーとのやりとりがより豊富になります。これは、明示的なリクエストをする必要のないクライアントにデータをプッシュできるためです。 WebSocket APIは、チャットアプリケーション、コラボレーションプラットフォーム、マルチプレイヤーゲーム、金融取引プラットフォームなどのリアルタイムアプリケーションでよく使用されます。
  • 従来WebSocket APIを構築するためには、WebSocketプロトコルの基礎となる永続的な接続の管理を担当するホストの設定が必要であったが、API Gateway Web Socket APIであれば、こういった作業をショートカットできる

WebSocket APIの概念

  • ルート
    • 新しいリソースタイプ
      1
      ルートは、API Gatewayが特定のタイプのクライアントリクエストを処理する方法を記述し、ルートを識別するために提供する値であるrouteKeyパラメータを含みます。
    • WebSocket APIは1つまたは複数のルートで構成される
      1
      WebSocket APIは、1つまたは複数のルートで構成されています。特定のインバウンドリクエストで使用するルートを決定するには、ルートセレクションエクスプレッション(選択式)を指定します。式は、ルートのrouteKey値の1つに対応する値を生成する着信リクエストに対して評価されます。
  • API Gatewayでルートに使用できる3つの特別なrouteKey値
    • $default
      1
      選択式がAPIルート内の他のrouteKeyに一致しない値を生成する場合に使用されます。 これは、例えば、一般的なエラー処理メカニズムを実装するために使用できます。
    • $connect
      1
      クライアントがWebSocket APIに最初に接続するときに、関連するルートが使用されます。
    • $disconnect
      1
      クライアントがAPIから切断すると、関連するルートが使用されます。 この呼び出しは、ベストエフォート方式で行われます。

構築手順

開発サンプル:リアルタイムチャットAP

WebSocket Chat App Architecture

  • WebSocket APIとAPI Gatewayを使用してサーバーレスのリアルタイムチャットAPを構築する

  • 主な機能

    • クライアントはWebSocket APIに接続するときにチャットルームに参加
    • バックエンドは、ユーザーがWebSocket APIに接続した後に提供されるコールバックURLを使用して、特定のユーザーにメッセージを送信できる
    • ユーザーはルームにメッセージを送信できる
    • 切断されたクライアントはチャットルームから削除される
  • ロジック概要

    1
    アプリケーションは、クライアントとサーバー(1)間の接続を処理するAPI GatewayのWebSocket APIで構成されています。 クライアントがAPIに接続(2)または切断(5)すると、2つのAWS Lambdaが反応します。 sendMessage関数(3)は、クライアントがサーバーにメッセージを送信するときに呼び出されます。 サーバーは、新しいAPI Gateway管理APIを使用して、接続されているすべてのクライアント(4)にメッセージを送信します。 接続された各クライアントを追跡するには、DynamoDBテーブルを使用して接続識別子を保持します。
  • 構築方法は3つあったので全て試した

    • 手動でAWS Consoleから構築
    • AWS Serverless Application Repository(SAR)のsimple websocket-chat-appを実行
      • SARであればボタン一つで自動構築できる。SAMのテンプレートがAP単位で公開されている
      • 今回のチャットAPの一式(Lambda関数、DynamoDBテーブル定義、IAMロールなど)が提供されている
    • SAM(Serverless Application Model)テンプレートをSAM CLIで実行
      • GitHubリポジトリにSARで使われているテンプレートが公開されている
      • 上記のリポジトリを手元にCloneしてSAM CLIで実行する
  • AmplifyではWebSocket APIはまだ使えないっぽい(2021/08/20時点)

SAMテンプレート

  • SAM CLIを用いると以下のテンプレートで環境を自動生成できる

    • オリジナルのWebSocket APIを開発する際もここから改変すると楽そう
    • ParameterはDynamoDBのテーブル名のみ
    • 内容の説明は以降のコンソールでの実装手順と一緒にまとめた
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      79
      80
      81
      82
      83
      84
      85
      86
      87
      88
      89
      90
      91
      92
      93
      94
      95
      96
      97
      98
      99
      100
      101
      102
      103
      104
      105
      106
      107
      108
      109
      110
      111
      112
      113
      114
      115
      116
      117
      118
      119
      120
      121
      122
      123
      124
      125
      126
      127
      128
      129
      130
      131
      132
      133
      134
      135
      136
      137
      138
      139
      140
      141
      142
      143
      144
      145
      146
      147
      148
      149
      150
      151
      152
      153
      154
      155
      156
      157
      158
      159
      160
      161
      162
      163
      164
      165
      166
      167
      168
      169
      170
      171
      172
      173
      174
      175
      176
      177
      178
      179
      180
      181
      182
      183
      184
      185
      186
      187
      188
      189
      190
      191
      192
      193
      194
      195
      196
      197
      198
      199
      200
      201
      202
      203
      AWSTemplateFormatVersion: '2010-09-09'
      Transform: AWS::Serverless-2016-10-31
      Description: >
      simple-websockets-chat-app
      SAM Template for simple-websockets-chat-app that has the DynamoDB table and Lambda
      functions needed to demonstrate the Websocket protocol on API Gateway.
      Parameters:
      TableName:
      Type: String
      Default: 'simplechat_connections'
      Description: (Required) The name of the new DynamoDB to store connection identifiers for each connected clients. Minimum 3 characters
      MinLength: 3
      MaxLength: 50
      AllowedPattern: ^[A-Za-z_]+$
      ConstraintDescription: 'Required. Can be characters and underscore only. No numbers or special characters allowed.'

      Resources:
      SimpleChatWebSocket:
      Type: AWS::ApiGatewayV2::Api
      Properties:
      Name: SimpleChatWebSocket
      ProtocolType: WEBSOCKET
      RouteSelectionExpression: "$request.body.action"
      ConnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $connect
      AuthorizationType: NONE
      OperationName: ConnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref ConnectInteg
      ConnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Connect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnConnectFunction.Arn}/invocations
      DisconnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $disconnect
      AuthorizationType: NONE
      OperationName: DisconnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref DisconnectInteg
      DisconnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Disconnect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnDisconnectFunction.Arn}/invocations
      SendRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: sendmessage
      AuthorizationType: NONE
      OperationName: SendRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref SendInteg
      SendInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Send Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${SendMessageFunction.Arn}/invocations
      Deployment:
      Type: AWS::ApiGatewayV2::Deployment
      DependsOn:
      - ConnectRoute
      - SendRoute
      - DisconnectRoute
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Stage:
      Type: AWS::ApiGatewayV2::Stage
      Properties:
      StageName: Prod
      Description: Prod Stage
      DeploymentId: !Ref Deployment
      ApiId: !Ref SimpleChatWebSocket
      ConnectionsTable:
      Type: AWS::DynamoDB::Table
      Properties:
      AttributeDefinitions:
      - AttributeName: "connectionId"
      AttributeType: "S"
      KeySchema:
      - AttributeName: "connectionId"
      KeyType: "HASH"
      ProvisionedThroughput:
      ReadCapacityUnits: 5
      WriteCapacityUnits: 5
      SSESpecification:
      SSEEnabled: True
      TableName: !Ref TableName
      OnConnectFunction:
      Type: AWS::Serverless::Function
      Properties:
      CodeUri: onconnect/
      Handler: app.handler
      MemorySize: 256
      Runtime: nodejs12.x
      Environment:
      Variables:
      TABLE_NAME: !Ref TableName
      Policies:
      - DynamoDBCrudPolicy:
      TableName: !Ref TableName
      OnConnectPermission:
      Type: AWS::Lambda::Permission
      DependsOn:
      - SimpleChatWebSocket
      Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref OnConnectFunction
      Principal: apigateway.amazonaws.com
      OnDisconnectFunction:
      Type: AWS::Serverless::Function
      Properties:
      CodeUri: ondisconnect/
      Handler: app.handler
      MemorySize: 256
      Runtime: nodejs12.x
      Environment:
      Variables:
      TABLE_NAME: !Ref TableName
      Policies:
      - DynamoDBCrudPolicy:
      TableName: !Ref TableName
      OnDisconnectPermission:
      Type: AWS::Lambda::Permission
      DependsOn:
      - SimpleChatWebSocket
      Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref OnDisconnectFunction
      Principal: apigateway.amazonaws.com
      SendMessageFunction:
      Type: AWS::Serverless::Function
      Properties:
      CodeUri: sendmessage/
      Handler: app.handler
      MemorySize: 256
      Runtime: nodejs12.x
      Environment:
      Variables:
      TABLE_NAME: !Ref TableName
      Policies:
      - DynamoDBCrudPolicy:
      TableName: !Ref TableName
      - Statement:
      - Effect: Allow
      Action:
      - 'execute-api:ManageConnections'
      Resource:
      - !Sub 'arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${SimpleChatWebSocket}/*'
      SendMessagePermission:
      Type: AWS::Lambda::Permission
      DependsOn:
      - SimpleChatWebSocket
      Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref SendMessageFunction
      Principal: apigateway.amazonaws.com

      Outputs:
      ConnectionsTableArn:
      Description: "Connections table ARN"
      Value: !GetAtt ConnectionsTable.Arn

      OnConnectFunctionArn:
      Description: "OnConnect function ARN"
      Value: !GetAtt OnConnectFunction.Arn

      OnDisconnectFunctionArn:
      Description: "OnDisconnect function ARN"
      Value: !GetAtt OnDisconnectFunction.Arn

      SendMessageFunctionArn:
      Description: "SendMessage function ARN"
      Value: !GetAtt SendMessageFunction.Arn

      WebSocketURI:
      Description: "The WSS Protocol URI to connect to"
      Value: !Join [ '', [ 'wss://', !Ref SimpleChatWebSocket, '.execute-api.',!Ref 'AWS::Region','.amazonaws.com/',!Ref 'Stage'] ]
  • Resourceのまとめ

    • AWS::ApiGatewayV2::Api x 1
    • RouteとIntegration x 3セット
      • AWS::ApiGatewayV2::Route x 3
      • AWS::ApiGatewayV2::Integration x 3
    • デプロイ関係
      • AWS::ApiGatewayV2::Deployment x 1
      • AWS::ApiGatewayV2::Stage
    • AWS::DynamoDB::Table x 1
    • Lambda関数と権限 x 3セット
      • AWS::Serverless::Function x3
      • AWS::Lambda::Permission x 3

WebSocket APIの作成(コンソールからの構築手順)

コンソールでポチポチする場合は先にLambda関数を作ったほうが手間が少ない
コンソールでの構築手順とテンプレートの該当箇所を以下に示す

  • AWS Console/API Gateway/APIを作成

  • APIタイプを選択

    • WebSocketAPIの”構築”を押下
  • Step1 APIの詳細を指定する

    • API名
      • ex. My Chat API
    • ルート選択式
      • ex. $ request.body.action
      • ルート選択式の値で記述された属性は、クライアントがAPIに送信するすべてのメッセージに存在する必要がある。リクエストメッセージの例↓
        1
        2
        3
        4
        {
        "action": "sendmessage",
        “data”: "Hello, I am using WebSocket APIs in API Gateway.”
        }
      • WebSocket APIは、メッセージの内容に基づいてメッセージをルーティングするために、ルーティングキーとして機能するJSON形式のメッセージを必要とする
    • 次へ
  • Step1の設定内容はSAMテンプレートの以下に該当する

    1
    2
    3
    4
    5
    6
    SimpleChatWebSocket:
    Type: AWS::ApiGatewayV2::Api
    Properties:
    Name: SimpleChatWebSocket
    ProtocolType: WEBSOCKET
    RouteSelectionExpression: "$request.body.action"
  • Step2 ルートを追加

    • $connectや$disconnectなどは事前定義されている
    • カスタムルート
      • “カスタムルートを追加”
        • こちらから独自のルートを作成する
      • ルートキーを入力
        • ex: sendmessage
    • 次へ
  • Step3 統合をアタッチする

    • 公式説明
      1
      この API をデプロイするには、少なくとも 1 つのルートを設定する必要があります。設定するすべてのルートに統合がアタッチされている必要があります。後で統合をセットアップするには、ルートの統合タイプとして [Mock] を選択します。
    • 統合タイプ
      • 以下がある
        • Mock, Lambda, HTTP, AWSのサービス VPCリンク
      • 今回はLambda
        • 既存のLambdaを選択
        • 先に作成しておく必要がある
      • Mock
        • 後で統合する場合はMockを選択
    • 次へ
  • Step2,3の設定事項(Route/Integration)はSAMの以下に該当する

    • RouteとIntegarationはセット(今回は3セット)
    • IntegrationでLambdaとの紐づけを行っている
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      ConnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $connect
      AuthorizationType: NONE
      OperationName: ConnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref ConnectInteg
      ConnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Connect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnConnectFunction.Arn}/invocations
      DisconnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $disconnect
      AuthorizationType: NONE
      OperationName: DisconnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref DisconnectInteg
      DisconnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Disconnect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnDisconnectFunction.Arn}/invocations
      SendRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: sendmessage
      AuthorizationType: NONE
      OperationName: SendRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref SendInteg
      SendInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Send Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${SendMessageFunction.Arn}/invocations
  • Step4 ステージを追加

    1
    ステージは、API をデプロイできる個別に設定可能な環境です。API 設定の変更を有効にするには、ステージにデプロイする必要があります。開発や本稼働などの環境を表すステージを追加できます。
    • ステージ名
      • 任意のステージ名を定義
      • ex: Prod, dev
    • 次へ
  • SAMテンプレートでは以下のResourceが該当する

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    Deployment:
    Type: AWS::ApiGatewayV2::Deployment
    DependsOn:
    - ConnectRoute
    - SendRoute
    - DisconnectRoute
    Properties:
    ApiId: !Ref SimpleChatWebSocket
    Stage:
    Type: AWS::ApiGatewayV2::Stage
    Properties:
    StageName: Prod
    Description: Prod Stage
    DeploymentId: !Ref Deployment
    ApiId: !Ref SimpleChatWebSocket
  • Step5 作成してデプロイ

    • 内容を確認して”作成してデプロイ”を押下
    • ルートやステージが生成される
  • SAMテンプレートでは、ここまでの設定の他にLambda関数や実行環境、DynamoDBテーブルなどが定義されていた

  • 残りのResourceの詳細

    • AWS::DynamoDB::Table x 1
    • Lambda関数と権限 x 3セット
      • AWS::Serverless::Function x3
      • AWS::Lambda::Permission x 3

Lambda関数の構築(コンソールから)

  • コンソールから作る場合

    • Console/Lambda/関数の作成
    • sendMessage, onConnect, onDisconnectで関数を生成。コードスニペットを貼り付けてdeploy
  • コードスニペットはGitを参照

    • sendMessage関数
      • この関数は、クライアントの1つが送信したデータを受け取り、現在接続されているすべてのクライアントを検索し、それぞれに提供されたデータを送信する
    • onConnect関数
      • requestContextからのconnectionId値をDynamoDBテーブルに挿入する
    • onDisconnect関数
      • 指定されたconnectionId値に対応するレコードを削除
  • 手動の場合はAPI Gatewayとの統合と権限設定も必要

    • API GW.MychatAPI/ルート/各ルート/統合
      • 統合タイプ: Lambda関数として作成した関数を選択
  • SAMテンプレートでは以下のように表現される

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
ConnectionsTable:
Type: AWS::DynamoDB::Table
Properties:
AttributeDefinitions:
- AttributeName: "connectionId"
AttributeType: "S"
KeySchema:
- AttributeName: "connectionId"
KeyType: "HASH"
ProvisionedThroughput:
ReadCapacityUnits: 5
WriteCapacityUnits: 5
SSESpecification:
SSEEnabled: True
TableName: !Ref TableName
OnConnectFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: onconnect/
Handler: app.handler
MemorySize: 256
Runtime: nodejs12.x
Environment:
Variables:
TABLE_NAME: !Ref TableName
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref TableName
OnConnectPermission:
Type: AWS::Lambda::Permission
DependsOn:
- SimpleChatWebSocket
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref OnConnectFunction
Principal: apigateway.amazonaws.com
OnDisconnectFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ondisconnect/
Handler: app.handler
MemorySize: 256
Runtime: nodejs12.x
Environment:
Variables:
TABLE_NAME: !Ref TableName
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref TableName
OnDisconnectPermission:
Type: AWS::Lambda::Permission
DependsOn:
- SimpleChatWebSocket
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref OnDisconnectFunction
Principal: apigateway.amazonaws.com
SendMessageFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: sendmessage/
Handler: app.handler
MemorySize: 256
Runtime: nodejs12.x
Environment:
Variables:
TABLE_NAME: !Ref TableName
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref TableName
- Statement:
- Effect: Allow
Action:
- 'execute-api:ManageConnections'
Resource:
- !Sub 'arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${SimpleChatWebSocket}/*'
SendMessagePermission:
Type: AWS::Lambda::Permission
DependsOn:
- SimpleChatWebSocket
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref SendMessageFunction
Principal: apigateway.amazonaws.com

SAR(Serverless Application Repository)で自動構築

  • SARにも今回の環境のテンプレートが公開されており、自動構築できる

  • 以下にアクセス

  • “Deploy”

  • 自分のAWSアカウントの確認画面で”デプロイ”

  • 以下のメッセージが表示された

    1
    承認が必要です。デプロイするには、[アプリケーション設定] セクションのチェックボックスをオンにしてください。
  • 該当箇所をチェック

    1
    このアプリがカスタム IAM ロールとリソースポリシーを作成することを承認します
  • デプロイを押下

  • Lambda/アプリケーションで生成されたAPスタックを確認することができる

  • 生成されていたリソース

    • DynamoDBテーブル: simplechat_connectionsはconnectionIdのみを保持する
    • API GW: SimpleChatWebSocket
      • $connect, $disconnect, sendMessageの3ルート
      • ダッシュボードからWebSocket URLを確認することができる
    • Lambda関数

      SAMテンプレートで自動構築

  • SAM CLIを使えば、SAMテンプレートで今回の構成を構築することもできる

    • SARでは裏側でSAMテンプレートを使っている
  • 今回のチャットAPのSAM Template手元にクローンしてCLIから実行する

### WebSocketAPIの検証/検証ツール wscat

  • WebSocket APIのテストには、OSSのコマンドラインツール wscatが役立つ
  1. NPMをインストールします。
  2. wscatをインストール
    1
    $ npm install -g wscat
  3. コンソールで、次のコマンドを実行して公開APIエンドポイントに接続します。
    • AWS Cnsole/API Gateway/My Chat APIのダッシュボードでWeb Socket URLとして下記のURLを確認出来る
      1
      2
      $ wscat -c wss://{YOUR-API-ID}.execute-api.{YOUR-REGION}.amazonaws.com/{STAGE}
      Bash
  4. sendMessage関数をテストするには、次の例のようなJSONメッセージを送信する。 Lambda関数はコールバックURLを使用してそれを返す:
    1
    2
    3
    4
    $ wscat -c wss://{YOUR-API-ID}.execute-api.{YOUR-REGION}.amazonaws.com/dev
    connected (press CTRL+C to quit)
    > {"action":"sendmessage", "data":"hello world"}
    < hello world
  • wscatを複数のコンソールで実行すると、それぞれが “hello world”を受信する。これで、WebSocket APIからメッセージを送信したり、応答を返すことができるようになったと言える
  • この検証方法は今回のサンプル以外でも使えそう

参考

関連記事

その他

[Angular x AWS CI/CD] CodePipelineの構築 (Github main更新→build→test→deploy to S3)

  • SPA(Angular)をAWSのS3でホスティングする際のCI/CDについてのメモ
    • 今回はGithubのbranchの変更をトリガーとしてCodePipelineを動かす
  • Amplifyであればコマンド一発で自動構築できるが、Github Enterprise Serverのリポジトリをソースプロバイダーとして選択できないという弱点があるので、会社では結局使えないケースもある

Angular x AWS Codepipeline

実装の流れ

AngularPJやHosting環境(S3 bucket)を構築済みであることを前提として、Githubのmain branchの更新時に自動でng buildとS3へのデプロイが実行されるようにする

  1. 事前準備
    • Githubにリポジトリを作成
    • Angular PJを作成
    • Hosting環境の設定
      • S3 bucketやCloudFront Distribution
  2. buildspec.ymlの生成
  3. CodePipelineの構築

1. buildspec.ymlの生成

  • Angular Projectに直下にbuildspec.ymlという名称で設定ファイルを生成する

  • buildspec.yml

    • CodeBuildの設定ファイル
    • ここでbuildやtestなどのコマンドを実行させる
  • my-angular-pj/buildspec.yml

    • 以下では、build以外のtest等の工程は一旦コメントアウトしている
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      version: 0.2 # Codebuildの設定ファイル Angular PJの直下に必要

      phases:
      install:
      commands:
      - if [ -e /tmp/node_modules.tar ]; then tar xf /tmp/node_modules.tar; fi
      - npm install -g @angular/cli # Angular CLIをinstall
      - cd ./my-angular-pj # AngularPJ直下へ移動
      - npm install # AngularPJ配下にnode_moduleをinstallする必要がある
      #- npm ci
      # test時にchromeを利用可能にする場合には以下が必要
      #- curl https://intoli.com/install-google-chrome.sh | bash

      build:
      commands:
      #- npm run lint
      - npm run build --prod # buildを実行
      #- npm run test:ci
      #- npm run e2e:ci
      #- npm run e2e -- --protractor-config=e2e/protractor-ci.conf.js
      #- npm audit

      post_build:
      commands:
      - tar cf /tmp/node_modules.tar node_modules
      artifacts:
      files:
      - '**/*'
      base-directory: ./my-angular-pj/dist/my-angular-pj # build時に生成されるアーティファクトのパス
      cache:
      paths:
      - /tmp/node_modules.tar
  • npm ciについて

    • npm ciを用いるとpackage-lock.json を使用してパッケージをインストールできる
  • chromeについて

    • testまで実行する場合は、Chromeをinstallする必要がある

CodePipelineの構築

  • AWS Console/CodePipeline/パイプラインの作成

  • パイプラインを作成する

    • 任意のpipeline名を入力
      1
      例: pjname-web-pipeline
    • サービスロールはデフォルトの設定で自動生成される
    • next
  • ソースステージを追加する

    • ソースプロバイダ
      • 今回はGithubを選択
        • バージョン1,2があり、2が推奨されている
      • Amplifyで構築する場合はここでGithub Enterprise Serverを選択できない
    • 接続
      • “Githubに接続する”から、任意のOrganizationとの接続を作成することができる
      • 一度作成した接続は、同様のOrganizarion配下の別リポジトリにも活用可能
    • リポジトリ名
      • 任意のリポジトリを選択
    • ブランチ名
      • mainを選択
    • 検出オプションを変更する
      • “ソースコードの変更時にパイプラインを開始する”でOK
    • 出力アーティファクト形式
      • 特別な要件が無ければ、CodePipelineのデフォルトでOK
    • next
  • ビルドステージを追加する

    • プロバイダー
      • AWS CodeBuildを選択
    • リージョン
    • プロジェクト名
      • “プロジェクトを作成する”で新たなプロジェクトを作成
  • ビルドプロジェクトを作成する

    • プロジェクトの設定
      • Project名、Descriptionを任意で設定
        • ex: my-angular-app-build-pj
      • 追加設定
        • PJ名や所有者程度はタグ付けしておく
    • 環境
      • 環境イメージ
        • マネージド型かカスタムイメージを選択
      • OS: Ubuntu
      • ランタイム: Standard
      • イメージ
        • ここは常に最新のものを指定する: aws/codebuild/standard:5.0
      • イメージのバージョン: 最新のものを指定
      • 環境タイプ: Linux
      • 特権付与
        • Dockerイメージを構築するか、ビルドで昇格されたアクセス権限を取得する場合は、有効化
      • サービスロール/ロール名
        • 自動生成されたロールがデフォで指定されている
    • Buildspec
      • Githubリポジトリ直下にbuildspecファイルがある場合は以下でOK
        • ビルド仕様: buildspecファイルを使用する
      • 今回はGitリポジトリ配下にAngularPJがあり、その直下にbuildspec.ymlを配置するため、以下のようにパスを指定する
        • ./my-angular-pj/buildspec.yml
    • バッチ設定
      • 今回は設定不要
    • ログ
      • CloudWatch Logs - オプショナル
      • グループ名,ストリーム名を定義
        • ex: xxxx-build-log-group
        • ex: xxxx-build-log-stream
      • S3
        • S3ログオプショナル: 今回は不要
    • CodePipelineに進む
  • 特に追加する環境変数が無ければ、next

  • デプロイステージを追加する

    • デプロイプロバイダ
      • Amazon S3を選択
    • リージョン/バケットから作成済みのホスティング用バケットを選択
    • デプロイする前にファイルを抽出する
      • こちらにチェック
    • next
  • 以上でパイプラインが生成される

    • パイプラインの画面に飛び、最初のビルド・デプロイ処理が開始される(buildspec.ymlファイルをgitにpushする前の場合は失敗する)

参考

関連記事

その他


AWS Amplifyによるバックエンド(認証認可,API,CI/CD,AI/ML)の高速開発とCloudFormationとの使い分けについて

AWS Amplify 概要

AWS Amplify

  • AWSを用いたWEB/Mobileアプリを高速にリリースするための開発プラットフォーム

    • 競合はGCPのFirebase
    • どちらも利用経験があるが、Amplifyの方ができることが多く、連携部分も自動構築できるのが強みだと感じている
      1
      2
      3
      Amplify を使用するお客様は、数分の内にバックエンドを構成しアプリケーションと接続でき、
      また、静的なウェブアプリケーションのデプロイは数クリックだけで実行できます。
      さらに、AWS コンソールの外部でも、簡単にアプリケーションコンテンツの管理が行えます。
  • 目的:差別化につながらない重労働の排除

    • 認証周りのようなバックエンド構築やアプリへの組み込みをショートカットできる
      • 特にサーバレス構成に適している
    • バックエンドをCLIから対話形式で手軽に自動構築
      • AWSのベストプラクティスが反映された、フルマネージドなサービスを数分で即活用できる
  • Amplifyで提供されるもの
    Amplify Console

  1. Amplify CLI

    1
    2
    Web/Mobile APのバックエンドをインタラクティブに
    作成・管理するためのOSSツールチェーン
    • やりたいことから宣言的にバックエンドを構築できる
      • 自動構築言えばCFnもあるが、Amplifyは対話形式細かい設定を決めずにべスプラに沿った構成を瞬時に構築できる
  2. Amplify ライブラリ

    1
    Web/Mobile APとAWSを統合するためのOSSライブラリ
    • AWSのバックエンドとの連携に利用。SDKと比較して短く直感的にかける
  3. Amplify Console

    1
    2
    フルスタックサーバレスWebアプリをビルド、テスト、デプロイ、
    ホスティングするためのOSSライブラリ
  4. Amplify Admin UI

    1
    2
    Web/Mobile APのバックエンドとコンテンツを管理するための
    GUIツール
    • ユーザーとコンテンツの管理
    • GUIを用いたデータモデリング
      • GraphQLスキーマを自動生成できる
      • シンプルなデータモデルで完結するAPのバックエンドを手軽に開発できる
      • Admin UI (GUI)で作成されたデータをpullすることも可能

ユースケース

Amplify Usecase

AmplifyはCloudFormationと競合するか?

  • Amplifyを活用する前に分かっていなかったポイント

    • CloudFormationでPFを管理する場合、Amplifyが邪魔になってしまう?
  • 競合しなかった

    • Amplifyの構成もCFnテンプレートに取り込める
    • PF構成がパラメータレベルで定まっていれば最初からCFnを、試行錯誤しながら進めていくのであればまずはAmplifyが適している
    • 個人的には以下の開発フローが望ましいと感じた
      • 初期はAmplifyで高速開発&検証 → PF構成が確定 → Former2などを活用してCFnテンプレート化 → Gitで差分管理 → 他環境やPJに同一構成を展開
  • 新規開発(Serverless or PF構成未確定)

    • Amplifyによる自動構築が適する
    • 認証周りやCI/CD, モニタリング、DB, Serverlessサービスなどをコマンドで俊敏に構築していく
  • 新規開発(PF構成が確定済、サーバレスや認証周りを使わない)

    • こういったシンプルなケースは、はじめからCloudFormationで構築してOK
    • 無理にAmplifyを使う必要はない
  • 開発が進み、PF構成が確定

    • ここでCFnテンプレート化を図れば良い
    • Former2を活用して実環境をCFnテンプレートに落とし込む
    • 固定値のテンプレートを汎用化(変数化など)する
    • GitでPF構成の差分管理を実施
  • CloudFormtionとは用途が異なる

    • CFnはPFの管理、再現性の確保を重点においている
    • Amplifyはどちらかというと、俊敏性/高速開発に重点が置かれている
      • 差別化を図れない重労働の削減が目的
      • CFnと異なり、細かい設定を規定しなくともAWSのベストプラクティスに即したPFを作れる
        • 使ったことがないサービスをいきなりCFnテンプレに起こすのはしんどい
      • 個人的にはスタートダッシュを図る為のものというイメージ

利用手順

Amplifyによる自動構築の流れ

基本的に以下の順序でバックエンドを数分で自動構築できる

  1. Amplify CLIのインストール&設定
  2. PJの作成、Amplify初期化コマンドを実行
  3. API追加コマンドを実行
  4. デプロイコマンドの実行

Amplify CLI インストール/設定

  • インストール

    1
    npm install -g @aws-amplify/cli
  • 設定

    • 以下のコマンドを実行するとブラウザにAWS Consoleのログイン画面ができる
      1
      2
      3
      4
      5
      6
      > amplify configure
      Follow these steps to set up access to your AWS account:

      Sign in to your AWS administrator account:
      https://console.aws.amazon.com/
      Press Enter to continue
  • 立ち上がったブラウザでログインを実施

  • CLI上でEnter

  • 次にデフォルトリージョンを選択する

    • 東京であれば ap-north-east-1にカーソルを合わせてEnter
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      Specify the AWS Region
      ? region: (Use arrow keys)
      ❯ us-east-1
      us-east-2
      us-west-2
      eu-west-1
      eu-west-2
      eu-central-1
      ap-northeast-1
      (Move up and down to reveal more choices)
  • Amplifyが使うIAM Userを設定

    • これは新規に作成するユーザー
      1
      2
      Specify the username of the new IAM user:
      ? user name:
  • ブラウザでAWS Consoleのユーザーを追加画面が立ち上がる

    • ここでIAM Userを作成する
    • 別のIAMがあれば、プログラムによるアクセスのみでOK
    • 権限はデフォでAdmin, AdministoratorAccess-Amplifyがおすすめ
  • ユーザーが生成されたら、アクセスキー/シークレットキーを控えておく

  • CLIに戻りEnter

  • accessKeyId/secretAccessKeyを入力

    1
    2
    3
    Enter the access key of the newly created user:
    ? accessKeyId: ********************
    ? secretAccessKey: ****************************************
  • profile名はデフォルトでOK

    1
    2
    This would update/create the AWS Profile in your local machine
    ? Profile Name: (default)
  • 以下が表示されれば完了

    1
    Successfully set up the new user.

アプリケーションのプロジェクトにAmplifyを導入する

  • アプリのProjectのトップディレクトリに移動
  • コマンドで初期化処理を実行
    • いくつか質問される。基本defaultでOK
      1
      amplify init
  • amplifyフォルダが生成される
    • この中にバックエンドに関する設定ファイルが入る
    • つまり、テキストベースで設定変更が可能。Gitで差分管理もできる

Amplify CLIによるバックエンドの構築

  • 基本的に以下のコマンドの後ろにカテゴリ名を入れて構築する
    1
    amplify add XXXX

認証周りの自動構築

Amazon Cognito

  • Amazon Cognito

    • 標準的な認証基板に求められる機能とAPIを提供。認証トークンの発行もできる
  • AmplifyではUIの構築済みコンポーネントも用意されている

    • 構築をコマンドだけで済ませ、認証のフォームも数行書くだけ済む
      • 数分で認証周りの実装が完了する
    • クロスプラットフォームにも対応
  • Cognitoの自動構築

    • 以下のコマンドを実行して、Defaultの設定でEnterを押していくだけで、Cognitoのバックエンドの設定が完了する
      1
      amplify add auth
  • Amplify UI Componentsを使ってSign-Up画面を追加

    • 以下の要素を使って数行で実装できる
      1
      <AmplifyAuthenticator>...

Amplify UI Component Auth


API(GraphQL/REST)の自動構築

AppSync DynamoDB

  • AmplifyではGraphQLとRESTに対応しており、バックエンドとクエリや設定ファイルを含めて自動構築できる
    • GraphQL API
      • AppSync, Dynamo DB
    • REST API
      • API Gateway, Lambda

AppSyncとは

AWS AppSync

  • AWS AppSync API基盤(GraphQL)

    • フルマネージドGraphQLサービス
    • DynamoDBを初めとする様々なAWSデータリソースにアクセスするためのマネージドなGraphQL基盤を提供
      1
      2
      アプリケーション開発が加速できるという理由から、各組織では API の構築に GraphQL を選択しています。この API により、フロントエンドのデベロッパーは、複数のデータベースやマイクロサービス、そして API に対し、単一の GraphQL エンドポイントから迅速にクエリができるようになります。
      AWS AppSync は、GraphQL API の開発を容易にする、完全マネージド型サービスです。このサービスは、AWS DynamoDB や Lambda、その他のデータソースとの安全な接続に必要な、面倒な作業を自動的に処理します。パフォーマンスを向上させるためのキャッシュや、リアルタイムの更新を可能にするためのサブスクリプション、そして、オフラインのクライアントを簡単に同期できるようにするクライアント側のデータストアなどが、簡単に利用できるようになります。デプロイが完了すると、API リクエストのボリュームに合わせた GraphQL API 実行エンジンの自動的なスケールアップとダウンが、AWS AppSync により行われます。
  • マイクロサービスへの統合されたアクセス
    マイクロサービスへの統合されたアクセス

    1
    単一的なインターフェースを使用して、(REST API や GraphQL API のエンドポイントなどが置かれている) VPC 内のコンテナで実行中の複数のマイクロサービスからのデータにアクセスし、それらを組み合わせて使用できます。
  • Subscriptionを用いる事で、データの更新(Mutation)をリアルタイムにクライアントAPに通知可能
    AppSyncリアルタイム同期

    1
    データは、バックエンドと接続されたすべてのクライアントの間 (1 から多)、もしくは、クライアント間 (多から多) でブロードキャストされます。同じデータを 1 秒以内にすべてのクライアントにブロードキャストし、それらのクライアントから応答を得るシナリオが実現できます。
  • シンプルかつ安全なデータアクセス

    • 短くコードを記述できる。セキュリティについてはWAFをアタッチできる

GraphQLとは

  • API用のクエリ言語およびサーバーサイドランタイム
  • 機能
    • 3種類のデータ処理形態
    1. 取得(Query)
    2. 変更(Mutation)
    3. 購読(Subscription): リアルタイムにデータを受け取るための存続期間の長い接続
  • 特徴
    • 型指定されたスキーマ
    • サブスクリプションを利用したリアルタイム処理

Amplify CLIによるAPIの作成

  1. API追加コマンドを実行
    • デフォルトではシンプルなTodoデータのスキーマを作成
    • 任意のGraphQLスキーマによるAPIを作成することも可能
  2. デプロイコマンドを実行
  • GraphQL APIを追加する手順
    • Step1 Amplify CLIでAPIカテゴリを追加
    • Step2 schema.grapfqlにスキーマを定義
    • AppSync経由でDynamoやLambdaと連携できる
      • @model @keyディレクティブ
        • DynamoDBのスキーマを意識しなくても必要なデータモデルの定義が可能
      • @connectionディレクティブ
        • DynamoDB間のリレーションを定義する

GraphQLのスキーマを定義

定義方法は二つある

  • PJ/amplify/backend/apiにGraphQLの設定が入っている

    • schema.grapfql が定義ファイル
    • デフォルトのスキーマが定義されているため、APに即した形式に変更する
    • property名に対して型を決めて、スキーマを定義していく
      • 型の右に!をつけると必須(required)のpropertyになる
    • @model
      • このスキーマに即したテーブルをDynamoDBに作成する
    • このスキーマを定義することで、それに即したAppSyncとDynamoDBのテーブルが生成される
  • Amplify Consoleでのスキーマの定義

    • クライアント側のコードの自動生成
    • 一からGraphQLをクエリするコードを書く必要がなくなる
    • Queryの深さには注意

GraphQL APIのローカルテスト

  • Step1 Amplify GrapfQL Explorerの立ち上げ
    1
    amplify mock api
  • Step2 deploy
    1
    amplify push api

Hosting環境の自動構築

  • add hostingコマンドでホスティング環境を構築できる

    • ここで amplify console コマンドを叩くと、このアプリの管理コンソールがブラウザで立ち上がります。
      1
      2
      3
      4
      5
      6
      7
      8
      $ amplify add hosting
      ? Select the plugin module to execute (Use arrow keys)
      ? Hosting with Amplify Console (Managed hosting with custom domains, Continuous deployment)
      ? Choose a type Manual deployment

      You can now publish your app using the following command:

      Command: amplify publish
  • amplify publish でアプリをアップロード

    1
    amplify publish
  • 参考

AIサービス(Recognition)との連携

  • AI/ML系のサービスを利用する際のコマンドは以下

    1
    amplify add predictions
  • Recognitionによる物体検知は以下

    1
    2
    Identify
    Identity Labels
  • 他の設定はDefaultを利用

  • Recognitionの機能を使えるのは、認証されたユーザーのみかゲストユーザーか?

    1
    2
    ? Who should have access
    > Auth users only
  • 以上でRecognitionに関するバックエンドの設定は完了

Storageの追加

  • 以下のコマンドでstorageカテゴリを追加狩野
    1
    amplify add storage

開発端末上でのAmplifyの設定をAWSに反映

  • amplify addを実行した時点で設定は作成されているが、AWSの実環境にはまだ構築されない
  • 以下のコマンドで実環境に反映できる
    1
    amplify push
  • push前にどのような設定がされるか確認画面が出る
  • ContinueでYes
  • GraphQLのスキーマにアクセスするためのクエリを自動生成してくれる
    • 言語をTypescriptに指定
    • AppSyncのスキーマに投げるためのクエリ&設定ファイルがローカルに生成される
  • クラウドに設定が反映されると同時にローカルにAWSの設定ファイルが吐き出される
  • graphqlフォルダも作成される
    • AppSyncのスキーマに投げるためのクエリのソースコードが自動生成されている

運用周りについて

CI/CD

  • amplify envコマンド

    • 複数バックエンド環境を管理可能
  • Amplify Console: PR Preview

    • プルリク時の一時的なバックエンド環境
      • Step1. Amplify CLIでHostingカテゴリを追加
        1
        amplify add hosting
      • Step2. Gitリポジトリと紐付け
        • 関連付けるリポジトリやbranchを選択
      • Step3. Pull Request Preview
      • Step4. Merge PR & Deploy
  • Amplify Console E2E Test

    • cypressを使用したE2Eテストとの統合によるフルスタックCI/CDパイプラインの作成
    • Step1 cypressのインストール
      1
      yran add -D cypress
    • Step2 amplify.ymlにtestフェーズを追加

モニタリング

  • Amplify Console Monitoring Metrics

    • CloudWatchアラーム・SNSトピックの作成、アクセスログの閲覧をAmplifyから一元管理
    • Amplify HostingがAmazon CloudWatchの統合でモニタリング機能をサポート
    • リクエスト数やデータ転送長、エラー数、TTFB(レスポンスまでの時間の平均)
  • AWS X-Ray

    • Step1 AppSyncコンソールからXーRayを有効化
    • Step2 LambdaのコンソールからXーRayを有効か

セキュリティ

  • AWS WAF with AppSync
    • Web ACLを作成
    • AppSyncコンソールからWAFを有効化

その他

Amplifyのラーニングパス

  • AWS Summit 2021 セッション

    • AmplifとAWS App Syncを使ったフルスタックアプリケーションの開発
    • ChimeSDKを使ったオンラインミーティングのサンプルAP
  • AWS Amplify Social Network App Workshop

    • CI/CDやE2Eテストにも触れられている
  • AWS Samplesの活用

    • GitでそれぞれのAWSサービスを利用したシステムのリファレンスアーキテクチャとソースが公開されている
  • AWS Amplifyに関連するコミュニティ

    • Amplify Japan User Group
    • AWS Front-end Community

参考

関連記事

その他

[PdM/PO] プロダクトの構想フェイズについて(4層の仮説立案→リーンキャンバス→インセプションデッキ→ストーリーマッピング→プロダクトバックログ化)

  • アジャイル開発における、プロダクト像の構想〜タスク化までについての個人的まとめ
  • PO(プロダクトオーナー)PdM(プロダクトマネージャー)は以下の流れで、何を作るか?をまとめていく必要がある
  1. プロダクト像の仮説を立案
    • 抽象度で4層程度に分解して考える
  2. リーンキャンバスを作成
  3. インセプションデッキを作成
    • ex. エレベーターピッチ/やらないことリスト
  4. ユーザーストーリーマッピング
  5. 重み付け(各ストーリーにSMLを定める)
  6. 優先度付け(MoSCoW法や狩野モデルを活用する)
  7. 優先順位付け→プロダクトバックログ
  8. 受入条件の設定
  9. プロダクトバックログアイテムに分割
    • ここでタスク単位になる
  10. DoD(完了の定義)の設定
    • 各アイテムにはDoDが必須
  11. スプリントプランニング~スプリント開始
    • バックログの中からスプリントないで取り組む物を決定する
    • ここで開発が始まる

概要/用語

PO/PdM

  • アジャイル開発においては、以下のロールがプロダクトについての責任を持つ
  1. プロダクトオーナー(PO)

    • プロダクトに関する全ての責任と権限を持つ
    • プロダクトビジョンを確立し、育み、伝達する
    • プロダクトバックログの管理・優先順位に責任を持つ
    • ROIの最大化に責任を持つ
  2. プロダクトマネージャー(PdM)

    • 人によって認識が異なるが、POとスクラムマスターの機能性を合わせた存在と定義されていることが多い
    • スクラム開発においてはPOとスクラムマスターに分解されており、PdMは存在しない。兼任すべきでないと言われている

ユーザーストーリーマッピング

  • ユーザストーリー

    • システムやSWのユーザーにとって価値のある機能を記述したもの
    • ある特定の役割の持ったユーザーから要望された結果を記述し、そのプロセスで何を行いたいのか?その効果(実現価値)も表現する
    • 書式
      1
      「<役割>として<機能>ができる (それは<理由>のためだ)」
  • ユーザーストーリーマッピング

    • ストーリー(ユーザーにとっての価値)を付箋などに書き出し、ユーザーの体験順に時系列で左右に整理、似た機能は上下(基本機能を上、派生的な機能は下)に整理して壁などにマッピングしていく手法
    • 通常ワーク形式で実施する
      • 複数名で3h程度で実施する場を設ける

プロダクトバックログ

  • プロダクトバックログとは?

    • ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリスト
      • 機能開発以外の作業も含まれる
      • バックログへの項目の追加&変更は誰でもいつでも可能
      • POが項目の優先順位付とリストの管理の責任と権限を持つ
      • プロダクトバックログはスクラムチームに限らず、誰でも(ex. ビジネスチーム)参照できる
    • ストーリーを元に作られる
      • 最低限の分解や重み付け、優先順位の定義を経てプロダクトバックログになる
    • バックログ=タスクではない
  • プロダクトバックログアイテム

    • プロダクトバックログを分解してタスク単位にしたもの

リーンキャンバス

リーンキャンバス

  • リーンキャンバス
    1
    リーンスタートアップという著書で有名な起業家のエリック・リースから応用されたビジネスモデルを一枚の図にまとめたフレームワーク
    • ユーザーストーリーマッピングの前に、プロダクト像の意識合わせに利用する
    • 目的
      • アイディアに対してビジネス視点からも検討できるようユーザーとビジネスのバランスを考えること
      • ユーザー視点で事業の価値を定義し、価値の構造を可視化することで実現性を検証することが可能になります。

インセプションデッキ

インセプションデッキテンプレート

  • インセプションデッキ

    • プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメント
    • 質問 x 10で構成されている
    • プロジェクト憲章に近い存在でPJ計画書のインプットにもなる
    • 考案者: Robin Gibson (ThoughtWorks社)
    • アジャイルサムライの著者(Jonathan Rasmusson氏)によって広まった
    • プロジェクト計画書ができる時点で盛り込まれていればいいので、初めから全て必須ではない
      • プロダクト像を揃える為の最低限として、エレベーターピッチや、トレードオフスライダーやらないことリストを作っておくと良い
  • エレベータピッチ

    • 以下の書式で[]の中身を書き換えていき、プロダクトを表現する
      エレベーターピッチ
    • リーンキャンバスと同様に、ユーザーストーリーマッピングの前に、プロダクト像の意識合わせに利用する
  • やらないことリスト

    • その名の通り

やらないことリスト


プロダクト像の仮説立案〜タスク化までの流れ

  • ストーリーマッピングの前にプロダクト像を合わせる
  • 1~はワーク内で実施することが多い
  1. 仮説立案
    • プロダクト像を抽象度に応じて階層分けして定義する
  2. リーンキャンパス
  3. インセプションデッキ
  4. ストーリーマッピング
    • ストーリー出し/分類/分割
  5. 重み付け(SMLを話し合う)
  6. 優先度づけ
  7. 優先順位付け
  8. 受入条件設定
  9. バックログアイテムに分割
  10. DoD(完了の定義)の設定

プロダクト像の仮説立案

  • プロダクトのあるべき姿はステークホルダー間で認識齟齬が生まれ易いため、以下のような抽象度で階層分けした仮説を共有することで、アジャイルPJを円滑に進めることができる

抽象度で階層分けしたプロダクト像の仮説

  • 上段が下段のインプットとなる
  • 下段に行くほど抽象度が下がり具体化される
  • Whatばかり話し合っていて、上段のCoreやWhyがずれていることが多い
  • この仮説はアジャイル開発を進めながら何度も見直してブラッシュアップしていく物なので、最初に完璧にする必要はない
    • ステークホルダーでビジョンを共有する

リーンキャンパス

  • 以下の9つの項目を埋め、ステークホルダーと共有する
    • 特にビジネスチームや予算承認者との合意が重要

リーンキャンバス

インセプションデッキ(エレベーターピッチ/やらないことリスト/トレードオフスライダー)

インセプションデッキテンプレート

  • インセプションデッキのテンプレートは以下のURLから入手可能

    • https://cacoo.com/diagrams/nsgCdwRZAHJBXTLy/F96B8
    • インセプションデッキはアジャイル開発におけるPJ憲章やPJ計画書に相当する
    • ストーリーマッピングに入る前に、エレベーターピッチとやらないことリストを作っておくと円滑に進め易い
  • エレベーターピッチ

    • 以下の[]の箇所を埋めて、ステークホルダー間の認識を合わせる
    • [差別化の決定的な特徴]の認識が承認者やビジネスチームとずれていると後で揉めかねない
1
2
3
4
5
6
7
[潜在的なニーズを満たしたり、潜在的な課題を解決したり]したい
[対象顧客]向けの、
[プロダクト名]というプロダクトは、
[プロダクトのカテゴリー]です。
これは、[重要な利点、対価に見合う説得力のある理由]ができ、
[代替え手段の最右翼]とは違って、
[差別化の決定的な特徴]が備わっている
  • やらないことリスト
    • 進める前にやらないことを明確に定めることで、承認者やビジネスチームとの齟齬が生まれにくい

やらないことリスト

  • プロジェクトコミュニティ

    • ステークホルダー全員を明文化
  • トレードオフスライダー(何を諦めるか?)

    • 何を優先するか?メンバとスタンスを揃えられる

トレードオフスライダー

  • その他アクターの認識合わせも実施しておくと良い

ここまででプロダクトの大枠の認識を合わせることで、ストーリーマッピングを円滑に実施可能になる。経験上、ストーリーマッピングは結構な時間がかかるので、こういった前提条件の設定は効果が高い。

ストーリーマッピング

  • マッピングはメンバ間の齟齬を回避するためにワーク形式で行う
  • 難しければ、少なくともPOがマッピングしたものに過不足がないかコメントをもらう

ワークについて

  • 所用時間:3h程度
  • 参加者
    • できうる限り多くのステークホルダーを集めた方が良い
  • ワークの流れ
    • マッピングの前にメンバ間のプロダクト像を整合する
      • ここで、リーンキャンバスやエレベータピッチ、抽象度分けされた仮説を用いる
    • ストーリーマッピング(全部ワーク内でやらなくてもOK)
      • ストーリーを付箋に書き出す
      • 時間軸で物語順に並べる
        • ex. ログイン→認証→…
      • フィチャーとして分類/分割
        • 共通するワードをフィーチャーとして上に付箋を貼る
        • その下に細かいストーリーを並べる
        • 大きすぎるストーリーは分割する
  • 開催形式
    • Localで集まれる場合
      • 複数名でホワイトボードに付箋を貼っていく
    • Remoteで実施する場合
      • Mural, Realtime Boardなどでホワイトボードを代用する
      • BOXなどの同時編集可能な環境があれば、そこのファイルにマッピングする

INVEST

  • ユーザーストーリーはINVEST要素を保持していることが望ましいと言われている
  • INVEST
    • Independent(独立している)
      • 可能な限り他のユーザーストーリーに依存しない
      • 実装、見積もり、テストが容易
    • Negociatiable 交渉可能
    • Valuable 価値がある
    • Estimatable 見積もり可能
    • Small 小さい/適切な大きさ:一つの反復に収まるサイズ
    • Testable:テスト可能
      • ストーリーが完了したかを示すことができる

エピック

  • エピック
    • まだ明確に表現できないものや緊急度の低いもの、NicetoHaveな事柄は大きな塊(エピック)としておいておく
    • 必要に応じてユーザストーリーとして詳細化する
    • 複雑で1つの反復で完了することはできない
    • リリース開始までに1回の反復で完了できる大きさに分割する必要がある

ストーリーの分割

  • 見積もったストーリーがアジャイル開発の一反復に治らない場合にはストーリーの分割を行う。タスクへの分割とは別

分割のガイドライン

  1. データ境界に沿って分割
  2. 操作の境界で分割
  3. 横断的な関心ごとを分離する
  4. パフォーマンス制約をストーリーにする
  5. 優先度に沿ってストーリーを分割する
  6. ストーリーをタスクに分割してはならない

ストーリーとフィーチャーの書き出しが終わったら過不足について議論を行う。その後、各ストーリーの重み付けと優先度付けを実施する。

重みづけ

  • 重み付け
    • 優先順位付の前にSMLで重みづけを行う
      • 重み(ストーリーを達成するまでのコスト)&優先度(ストーリーが産む価値)を先に定めてから順位づけをしないと混乱が生じてしまう
    • Small, Middle, Largeをメンバ間で話し合う

優先度付け

優先度と優先順位は別物

  • 優先度づけ→優先順位付け
    • 優先度
      • 高中低、ABCなど
    • 優先順位
      • 明確な序列
    • 優先順位がつくとバックログになる

優先度付けには様々な手法がある

  • MoSCoW法(各ストーリーに以下のタグを定めていく)
    • Mo: Must Have
      • 絶対必要
      • MVPに必要なフィーチャーはここに含まれる
    • S: Should Have
      • できれば実装すべき
    • Co: Could Have
      • 他への影響がなければ実装できるとよい
    • W: Won’t Have
      • 今回は実装しないが将来に実装するかも

重み付のSMLと頭文字が被って混乱を招くことがあるので注意

  • 可能であればMVPを定義しておくと優先的な機能を可視化しやすい
    • MVP (Minimum Viable Productivity)
      • 実用最低限の製品のこと
      • 使い勝手はともかく最低限の価値を生み出せる状態
    • MVPに含まれる機能は、自ずとMust Haveになる

その他、狩野モデルも有名

  • 狩野モデル(利用者の好みでタグ付)
    • 魅力的(あると魅力的)
    • 一元的(なくても良いがあると差別化できる)
    • 当たり前(あって当たり前)
    • 無関心(どうでもよい)
    • 逆行(あったら困る)

プロダクトバックログの定義(優先順位付け)

  • 先に各ストーリーに設定した重みや優先度を参考に、優先順位をつける

  • ストーリーを優先順位で上から並べる

  • Walking Skelton

    • 実装が短期間で終わる場合は注意深く優先順位付けしなくて良い
  • 判断基準

    • ビジネス価値
      • ex. 同等のビジネス価値を提供可能な場合、開発工数の少ないほうがROIが高いため、つけられる優先順位も高くなる
    • 技術的なリスク
      • 技術的なリスクが高い項目ほど早いスプリントで対処して、リスクを減らすべきである
      • ただ、新設チームの場合は始めにもってこな方が良いケースもある
    • 市場リスク
      • 早く市場に出してフィードバックを得る必要がある物を優先する
      • 他社に先出しされると致命的になる機能など
  • 例えば、MoSCoW法であれば、Must Haveの項目から先に取組み、MVPを完成させる必要がある。

    • 必須の機能が実装されることで、技術的なリスクが序盤で下がり、少なくともプロダクトが動く状態になる
    • その後にビジネス価値に基づいてShouldの項目を片付けていくイメージ
  • ここまでのアウトプット

    • プロダクトバックログ
      • 優先度付されたフィーチャー/ストーリーのリスト

プロダクトバックログを起点として、スプリント計画や詳細なタスクへの落とし込みを行っていく


プラダクトバックログアイテムの定義

  • プロダクトバックログを細分化するとタスクになる
    • プロダクトバックログアイテム(項目)=タスク
    • これらのアイテムにはDoD(完了の定義)を定める必要がある
    • バックログごとに表を作るイメージ
      • カラムはバックログ、バックログアイテム、各アイテムのDoD(完了の定義)

完了の定義:DoD(Difention of Done)を追加

  • DoD(Difention of Done):完了の定義

    • アウトプット
      • ex. 関連する設計ドキュメントがある
    • 状態
      ex. 2名以上がレビュー、テスト実行済み
  • DoDを定めなければ進捗の実態の測定や品質管理が難しくなる

ここまでで、プロダクト像の定義〜タスク化が完了


2レベルプランニング

アジャイル開発は適当に進めていいわけではなく、2段階で計画を立てて、順次見直しながら進めていく

  • リリース計画
    • ユーザにコミットするリリースの時期
  • スプリント計画
    • 対象スプリント期間内に行うべきことの計画

リリース計画の立案

まずは全体の進め方を検討する

  1. SPの長さを決める
    • スクラム開発なら2w程度
    • 通常のアジャイル開発では4~8w程度
  2. ユーザーストーリー。エピックの規模を見積もる
    エピックは見積もり可能な大きさに分割する
  3. ユーザーストーリー、エピックに優先順位をつける
  4. 1反復で消化できるポイントなど(ベロシティ)を見積もる(例:一反復=15ポイント)
    • 立ち上げ段階の予測はとても難しいので厳し目に見積もる
    • 一度スプリントを回せば、前回はこの程度消化できたので…という測量が可能になり精度が上がっていく。段々精度が上がっていくものという認識でOK
  5. 反復にユーザーストーリー、エピックを配置する
    • スプリントの期間と、ベロシティが定まった箱の中にどのストーリーを詰めていくか?考えるイメージ
  • プロダクトオーナーは、ROIを最大化するにはどうすべきか?を常に考えて、責任を持つ必要がある

価値とシステムにおけるリスクの二軸のマトリクスで分類する

スプリントプランニング

次にスプリントごとの計画をする

  • バックログの中から次のスプリントで取り組む物を選択する

    • ここでやっと開発を始めることができる
    • 以降のスプリントサイクルについては別記事に記載
  • 2部構成で実施する

    • パート1
      • 開発チームはPOと一緒に次のスプリントでどのような機能を実装するか
      • SPで対象とするバックログの選定
      • ストーリーの確認
    • パート2
      • 開発チームがその機能をどのようにプロダクトに追加するかを決定する
        • ストーリーの作成
  • スプリントバックログ

    • タスクボード To Do/Doing/Done を使う
      • ここでGitのカンバンなどを用いる
    • ここでの単位はプロダクトバックログアイテム(タスク)
  • 三角測量 プランニングポーカー

    • 見積もるための基準となるストーリーやタスクを1つ決める、
      比較しながら見積もっていく手法
    • 相対的見積もり
    • 異なる数字を出した場合は、最も大きい数字を出した人と、小さい数字を出した人で根拠を説明しあう

参考

関連記事

その他

[Ionic入門] Angular/React/VueベースでWeb/iOS/Androidを同時開発可能なクロスプラットフォームフレームワーク

  • クロスプラットフォームで動作可能なアプリを開発できるIonic Frameworkの概要と初期開発手順についてのメモ
  • モダンフロントエンドフレームワーク(ex. Angular,React,Vue)ベースで開発したAPをモバイル(iOS/Android)に変換することができる
    • Web系のフロントエンドエンジニアが覚えると、ほぼ学習コスト無しで全てに対応可能になる
  • Flutterとどちらを採用すべきか?は開発チームのエンジニアによる
    • WEB技術(Typescript)が軸→Ionic、0からDartを学びたい→Flutter

Ionic Framework概要

クロスアプリケーションフレームワーク

Ionic概要

  • SPA(Webアプリ)ベースのアプリをiOS/Androidで動くネイティブアプリに変換できるフレームワーク

    • Web/iOS/Androidのアプリをハイブリット展開可能
      • 1つのIonic Projectから Web/iOS/AndroidのAPをビルドするイメージ
    • 特に、既存のWEB APのモバイル化に迅速に対応できる
  • コンポーネントやコード(HTML/Scss/Typescript)を使い回して開発可能

    • Typescriptで書いたロジックをそのまま使い回せる
    • Swift等を使うと、Webとモバイルで同じロジックを別言語で書き直す手間が発生する
  • WEBフレームワークとはUI開発で一部差分がある

    • 例えば、Angularで使われるWeb専用のUIコンポーネントは使用できない

      • 一般的にAngularではAngular Materialを活用して、htmlやcssをあまり書かずにUIを実装していく
        • ヘッダー、メニュー、テーブル等の部品がある
          Angular Material
    • Ionicではモバイル向けのUIコンポーネントを活用する
      Ionic UI Component

      • IonicのUI ComponentはiOSとAndroidでそれぞれ異なる最適なマテリアルデザインが表示される
  • ネイティブ機能のAPIとドキュメントが豊富に公開されている

    • WEBベースで開発するが、ネイティブデバイスの機能もドキュメントを見てNative APIsを使えばハマらずに実装できる
    • Ionic Framework - Native APIs

Ionicの強み

  • Web系のフロントエンドエンジニアが学習コストなく活用可能
  • WEB APのロジックをそのまま使いまわせる
    • Flutterを採用する場合はDartで書き直さなくてはならない
  • 複数のWEBフロントフレームワークに対応
    • Angular, React, Vue, Nuxt.js
      • 日本ではなぜかReactが流行っているが、海外ではフルスタックなAngularやNuxt.jsが主流になりつつある認識
    • React NativeはReactにしか対応できない為

Ionic vs Flutter

  • 組織のエンジニアのスキルベースで判断
    • 軸がWEB(TS, JS) → Ionic
    • 軸がモバイル & 一からDartを学びたい → Flutter
  • WEB/モバイル以外にも対応したい場合はFlutter
    • FlutterはWindowsやmacOS、Linux、車載、テレビ、スマートホーム関連のモジュールに組み込むこともできる
  • すでにWEB APが存在していて、追加でモバイル対応したいケース
    • Ionicであれば、ロジックの書き直しが生じない
    • Flutterの場合はDartで書き直すことになる
  • 結局は新たにDartの記法を学ぶ必要があるか?が判断ポイント
    • 個人的には、WEBエンジニアはIonicで困ることが特に無い為、Flutterを覚える旨味が特に無いと考える

Ionic UI Component

Ionic UI Component

  • IonicのUI Componentを活用すれば、iOSとAndroidでそれぞれ異なる最適なマテリアルデザインを表示できる
    • それぞれデザインする必要は無く、デザイナー無しでも高いUI品質を担保できる

Ionic UI Template

Ionic FirstApp Temaplate

  • Ionicではテンプレートを活用することで、↑のようなUIを自動生成することができる
    • タブメニューやカメラ機能程度なら自分で実装する必要が無く、手軽にモバイルAPらしさを出せるので、WEB開発になれたエンジニアでも機能開発に集中できる

Ionicの学習方法

  • WEBの公式ドキュメントと書籍で基本的に困ることはない

書籍

以下がとても分かりやすかった

WEB

Ionic Document

後はベースに採用するWEBフレームワークの学習をすればOK


IonicによるAP開発手順

環境構築

  • Ionicの開発に必要なものは以下
    • Node.js
    • Ionic CLI

Node.js

Ionic CLIのインストール

  • Ionic CLI

    • これを入れるとIonicコマンドを実行可能になる
  • Nodeのバージョンが古い場合は先にバージョンアップ

  • Macの場合

    1
    2
    3
    4
    5
    sudo npm install ionic -g

    ...
    + ionic@5.4.16
    added 225 packages from 149 contributors in 10.316s
  • Windowsの場合

    1
    npm install ionic -g
  • バージョンを確認

    1
    2
    > ionic -v
    5.4.16

モバイルアプリ開発用ツールのインストール

  • 実機での動作確認やリリース作業(App Store/Google Play)に以下が必要
    • Xcode
      • iOSアプリの実行/リリースに必須の統合開発環境
      • Windowsでは利用不可
    • Android Studio
      • Androidアプリの実行/リリースに必須の統合開発環境
        Android Studio

Xcode

  • XcodeはApp Storeから入手
    • インストールには20分以上かかった

Xcode App Store

  • ランタイムのインストール
    1
    2
    3
    sudo gem install cocoapods # iOSのパッケージ管理システム
    xcode-select --install # Xcodeのコマンドラインツール
    pod repo update # CocoaPodsの依存関係を更新

Android Studioのインストール

  • Android Sudioサイトからダウンロード
    • インストーラーを起動してインストール
    • 指示にしたがって初期設定を実施

About Android Studio

Ionic向けのVSCode Pluginをインストール

  • VSCodeにはIonic/Angular向けのPluginが豊富にある
    • 必要に応じて開発環境に取り込む

Ionic projectの開始〜テンプレートからのUI自動生成

  • Ionic Projectを開始

    1
    ionic start --type=angular
  • Project名を入力

    1
    2
    3
    4
    5
    6
    Every great app needs a name! 😍

    Please enter the full name of your app. You can change this at any time. To bypass this prompt next time, supply
    name, the first argument to ionic start.

    ? Project name: sample-pj
  • 次にテンプレートを選択する

    • モバイルアプリのUIの大枠は自動構築できる
    • tabs
      • モバイルアプリの定番のタブ型のアプリ
    • sidemenu
      • サイドメニューがハンバーガーで開くタイプ
    • blank
      • Home画面のみのシンプルな画面
    • camera with gallery
      • カメラ機能とデバイスの画像を操作する機能があるタイプ
1
2
3
4
5
6
7
8
9
10
11
Let's pick the perfect starter template! 💪

Starter templates are ready-to-go Ionic apps that come packed with everything you need to build your app. To
bypass this prompt next time, supply template, the second argument to ionic start.

? Starter template: (Use arrow keys)
❯ tabs | A starting project with a simple tabbed interface
sidemenu | A starting project with a side menu with navigation in the content area
blank | A blank starter project
my-first-app | An example application that builds a camera with gallery
conference | A kitchen-sink application that shows off all Ionic has to offer
  • 指定したProject名のディレクトリが生成される

    1
    2
    > ls
    sample-pj
  • プレビューを起動

    • Angularのng serveと同様にlocalhostで動作確認可能
      1
      2
      > cd sample-pj
      ionic serve
  • Sidemenuテンプレートを使った場合の初期画面

    • メールアプリ風になっている

Ionic tabs template

  • Tabsテンプレートを使った場合の初期画面
    Ionic Tabs Tenplate
  • –labオプション
    • Ionic ComponentはiOSとAndroidでそれぞれ異なるマテリアルデザインを持っている
    • labオプションで同時に確認可能
      1
      ionic serve --lab
      Ionic Serve Lab

tabsテンプレートのコンポーネント構成

  • sample-pj/src/app
    • ディレクトリ構成は通常のAngular PJと同様
    • 以下のコンポーネントが自動生成されている
      • tabs, tab1, tab2, tab3, explore-container
1
2
3
app % ls
app-routing.module.ts app.component.scss app.component.ts explore-container tab2 tabs
app.component.html app.component.spec.ts app.module.ts tab1 tab3

UIの改修例

  • 自動生成されたUIの改修手順について
    • タブのアイコンやタイトルの変更

tabs component

  • デフォルト

    • tabs temlateで自動生成されるコード
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      <ion-tabs>

      <ion-tab-bar slot="bottom">
      <ion-tab-button tab="tab1">
      <ion-icon name="triangle"></ion-icon>
      <ion-label>Tab 1</ion-label>
      </ion-tab-button>

      <ion-tab-button tab="tab2">
      <ion-icon name="ellipse"></ion-icon>
      <ion-label>Tab 2</ion-label>
      </ion-tab-button>

      <ion-tab-button tab="tab3">
      <ion-icon name="square"></ion-icon>
      <ion-label>Tab 3</ion-label>
      </ion-tab-button>
      </ion-tab-bar>

      </ion-tabs>
  • 改修方法

    • アイコンを変更
      • 設計した各画面に適したion-iconを選定
    • タイトルを変更
      • 各画面のComponentのion-titleを変更
  • ion-iconについて

    • ion-iconのアイコンは以下のマテリアルデザインの名称をname=で指定することで活用できる
    • 各画面のアイコンとしてふさわしいものを公式ドキュメントから探せば良い
      ion-icons
  • tabs.page.htmlを以下のように実装
    • タブの一つをホーム画面とする
      • アイコンを家マークに変更
      • アイコン下のタイトルをHomeに変更
1
2
3
4
5
6
7
<ion-tabs>

<ion-tab-bar slot="bottom">
<ion-tab-button tab="tab1">
<ion-icon name="home"></ion-icon>
<ion-label>Home</ion-label>
</ion-tab-button>
  • serveで変化を確認

    • tabsのボタンのアイコンが切り替わっていることを確認
      1
      ionic serve --lab
  • ion-toolbarについて

    • 以下の書式でツールバーとタイトルを定められる
      1
      2
      3
      4
      5
      6
      7
      <ion-header [translucent]="true">
      <ion-toolbar>
      <ion-title>
      <!--アプリのタイトルに変更-->
      </ion-title>
      </ion-toolbar>
      </ion-header>

ここまでで、モバイルAPらしいタブ型の基本的なUIの骨子を開発することができる。この後、使えそうなUI Componentを公式ページから探して、各画面を作り上げていく。

デバイスのネイティブ機能の実装: Ionic Native API

Ionic - Native APIs

  • Ionic Native APIs
    • こちらを利用すればデバイス本体の機能を活用できる
      • ex. カメラ、センサー、写真フォルダ、3D Touch、クラウド連携…
        1
        CapacitorやCordovaを使って、どんなIonicアプリにもネイティブデバイスの機能を簡単に追加できるようにするための、オープンソースのコレクションとプレミアムプラグインと統合します。このことによって、ネイティブパワーのアプリ体験を構築することができます。
    • ベースとするフレームワーク毎の説明がドキュメントとして公開されているので、そこで記法を確認して利用すれば良い
      • この豊富なAPI群により、WEB開発しか経験の無い方でも、大抵のモバイルAPを開発できる

その他の実装については、ベースとしたWEBフレームワークやTypeScriptの書式を調査しながら進めれば良い。


参考

関連記事

その他

EXIN Agile Scrum Foundation 合格体験記 [スクラムマスター資格]

Exin Agile Scrum Foundation 概要

  • EXIN社が提供しているアジャイル/スクラム開発に関する認定資格
  • 現役のスクラムマスターによる二日間の研修と資格試験がセットになっている
    • スクラム開発をマネジメントする中で、細かいレベルまで具体的にどうすべきか?が分かりとても有益であった
    • 他の参加者とワーク形式でストーリーマッピングや優先度付、分割、バックログ化といった流れも体験できる
      • 参加者は経験者と初級者が半々程度
    • 会社に受講料を出してもらえるなら、受講しておいて損は無い
  • 難易度
    • 元々アジャイル開発を学習/実践していた為、あまり難しさは感じなかった
    • 研修受講後にまともに学習をすればほぼ確実に合格する
  • 位置付け
    • スクラム開発に関する資格と言えば、認定スクラムマスターとスクラムマスター認定の2つが有名
    • 上記は結構難易度も高いと聞くので、この資格を先に取得してから挑戦すると良さそう
    • どちらかというと、これからスクラム開発を始める人や、良く分からず何となく進めてしまっている人向け
  • 試験はオンラインで受験可能

合格までの流れ

EXIN社研修を受講

  • 2日間リモート形式

    • Zoomのブレークアウトルームやmural(オンラインホワイトボード)を使用
    • muralは自社でのテレワーク時のワークにも使えそうであった
  • PDF教材をもらえる

  • ワーク形式で以下の工スクラム開発の工程を具体的に体験できた

    • ユーザーストーリー出し ⇒ 分割 ⇒ 優先度付け ⇒ プロダクトバックログ ⇒ スプリントプランニング ⇒ スプリントバックログ ⇒ スプリント ⇒ レトロスペクティブ(振り返り)
    • 優先度や重み付けの手法やDoD(完了の定義)など、具体的な手法を多く知れた
  • レトロスペクティブ(振り返り)のKPT出しは、どんなPJにも即取り入れられるものだと感じた

    • K: keep
      • 良かったこと、キープしたいこと
    • P: Problem
      • 問題/課題や心配事となっていること
    • T: Try
      • 次に改善したい、トライしたいこと
  • 現場経験豊富な講師が参加しており、質疑も多くできた

  • アジャイル開発の研修ではスプリントは412wと習ったが、スクラム開発では2
    4w程度が適するなど、スクラムの特徴も知ることができた

模擬試験/学習

  • 研修の最後に模擬試験を受ける

    • 一度目 25/39点 合格点25
      • アジャイル開発経験者が受講した直後の点数
    • 二度目 39/39
      • 間違えた問題と試験頻出事項の振り返りと、研修のノート全体の見直しを実施
      • 学習期間は1日
  • プライベートをあまり削らずに取れる、実用的でコスパの良い資格という感触

試験を予約

  • 試験はコロナの影響もあり、オンラインのみ

  • 研修初日の夜にメールでバウチャーコードが送られてくる

  • 必ず試験環境の動作チェックを実施する

    • カメラの性能が悪いPCだと受験できないこともあるので注意(会社のPCではダメだったので、自分のMacを使用)
      動作チェック

オンライン試験

  • 研修二日間の翌日に学習して受験
  • 試験監とオンラインで対面するのではなく、録画して、後に試験監がそれを確認する形式
    • なので、夜など好きな時間に受験できる
  • 部屋を一周撮影したり、受験前の作業で落ちたりなど、かなり面倒でUXは最悪であった
  • 試験中に部屋に人が入ると失格になる為、子供がいる方は注意が必要そう
  • モニターをつなげることも禁止されている
  • 難易度
    • 研修全体と模擬問題やポイントをまともに復習すれば問題なく解けるレベル
    • 日本語的に微妙な問題が多いので注意
  • 無事合格

合格後のステップアップ

上位の資格

英語が特別得意でない人は、LSMかCSMを取るイメージ

書籍

研修で現役のスクラムマスターがおすすめしていた書籍は以下

参考

関連記事

新人がAWS認定 SysOps Administratorに合格するまでの学習方法詳細 (2021年)

  • AWS認定 SysOps Administrator(SOA)の合格体験記

  • SAA(Solution Architect)は一度もAWSを触らず黒本問題集だけで合格できたが、SysOpsは専用の教材も無く、格段に難しかったので、学習方法やレベル感について詳細をまとめておきます

  • Developer Associateについては以下を参照

AWS認定 SysOps Administrator 概要

AWS認定

  • AWS 認定 SysOps アドミニストレーター – アソシエイト

    • AWSアソシエイト資格三種の一つ
    • AWS でのデプロイ、管理、運用に関しての問題が出題される
      1
      2
      3
      4
      5
      6
      7
      認定によって検証される能力
      ・スケーラブルで、高可用性および高耐障害性を備えたシステムを AWS でデプロイ、管理、運用する
      ・AWS との間のデータフローを実装および制御する
      ・コンピューティング、データ、セキュリティ要件に基づく適切な AWS のサービスを選択する
      ・AWS 運用のベストプラクティスの適切な使用方法を識別する
      ・AWS の使用コストを予測し、運用コストコントロールメカニズムを識別する
      オンプレミスワークロードを AWS に移行する
  • SAA(Solution Architect Associate)の次にとる資格としておすすめ

  • SAAと比較してかなり実用的

    • SAAは”AWSが得意”ではなく、”最低限の知識があります”程度のレベル感だが、SysOpsを持っていれば、組織内のAWSアカウントの管理や運用中のサービスの運用監視周りの設計をリードすることができる
  • 上位資格に挑戦する前のステップになる

    • AWS DevOps Professional合取得にはDeveloperの内容よりも、SysOpsの細かい内容の方が障壁になる
    • SAP(Solution Architect Professional)はSysOpsほど細かくでないが、運用周りの細かい知識を先に固めておくと手堅く点数を稼げる
    • DeveloperとSysOpsのどちらを先に取るべきかは実務経験にもよるが、SysOpsの方が比較的簡単

難易度

  • SAA取得済みでProfessionalレベルに挑戦する前に受験すると丁度良い

  • SAA(AWS Solution Architect)と比較して遥かに難しく、出題内容が細かい

    • SAAは黒本問題集サイトを1, 2ヶ月集中して取り組んだらAWSを触ることなく余裕を持って合格できたが、SysOpsは厳しかった
  • AWSのサービス全般についての一般的な知識があっても、2択までしか絞れないことが多い

    • 実際に手を動かした経験のあるサービスのみ確実に答えることができるレベル
    • 問題集サイトの問題を覚えるのではなく、説明まで読み込んで深く理解しなければ歯が立たない
  • SysOpsは完全に机上の学習のみではハードになる

    • 少なくともCloudFormationと運用監視関係のサービスは、実務で利用する機会が無くとも、自分で触ってみた方が良い
    • 利用したことの無いサービス(KMS, Systems Manager, RDS)も沢山あったが合格できた(経験があるほど難易度が下がる程度)

合格までの道のり

0. 先にSAA(AWS Solution Architect)を取得

  • 新卒配属三ヶ月程度で、AWSを一度も触ることなく受験

    • SAA取得後に実務でAWSを触り始めた
  • 運用を専門的に極めたいという特殊な希望がなければ、SysOpsの前に必ずSAAを取得すべき

1. AWS公式の研修を受講

Systems Operations on AWS

  • Systems Operations on AWS

    • 3日間の講義
    • AWSのSolution Architectが講師を務めてくれ、質問も沢山できる
  • 会社経由で無料だったため受講

    • 会社で受けられない場合は、最低限の実務経験があれば受けなくてもOK
      • 個人では20万以上かかるので注意
    • CloudFormationも運用監視関連のサービスも利用したことない場合は、先にう毛ておくと理解し易い
  • 実務経験が豊富な人以外は、これだけでは間違いなく受からない

2. 書籍

3. 実務経験

試験合格には以下の経験が大きく活きた

  • CloudFormationテンプレートの開発

    • CFnを触った経験があると合格に大きく近づく
    • 業務内でAWSを使っていて、IaCを実践できていなければ、指示されていなくともCFnテンプレート化してみると、仕事での評価も知識も獲得できるのでおすすめ
    • 業務内で使う機会が無ければ、個人でWEBに落ちているテンプレートを改造して試してみると良い経験になる
  • 実際のサービスの運用

    • CloudFront, S3, WAF, その他運用監視関係
    • 運用監視周りのサービスは実際に手を動かしてみなければ暗記だけでは厳しい
      • 自分のアカウントを作って簡単に通知設定などを設定してみると良い

4. 問題集サイト

AWS WEB問題集サイト

  • 有名なAWS 問題集サイトを2週(SAAもここで学習)
    • 試験対策の勉強はこれがメイン
    • Udemyなどで学習した人もいるようだが、英語らしい。Linked in LearningのSysOpsの研修は情報が古かった
    • 1ヶ月ちょっと学習。余裕を持つなら二ヶ月必要
      • #88まであり、平日は一日5つ程度(各7問)のペースで取り組んだが、結構大変
    • 他の人の体験記を見ていても実務経験が浅い人は1周では危険
    • サイトの問題は定期的に更新されているが、毎年の公式の更新直後は問題がかなり異なっていた
      • 筆者は試験問題更新直後に一度受験し、問題集サイトと全く範囲が違い落ちてしまった…
      • 2度目の受験時はかなりの精度で出題範囲が似通っていた
        • 各問題の説明まで全て読み込むことで合格レベルに達した
        • SAAほど問題が似ていないので、深い理解が必要

5. 模擬試験

  • 模擬試験で高得点を取れていても本番の試験の方が難しいので注意

模擬試験概要

WEBから公式の模擬試験を受験することができる。時期によっては問題集サイトとAWS認定試験の範囲が異なることもあるため、必ず受験して感触を掴んだ方が良い

  • SOA-P01: AWS 認定 SysOps アドミニストレーター – アソシエイト模擬
    • 費用: 2000円(税込み 2200)
    • 時間: 35分
      • 試験開始前に「受験者行動規範」を読んで確認するため時間が 5 分含まれている
    • 難易度
      • 問題集サイト #88まで一周解説の読み込みまでやっていればほぼ全て解ける

申し込み手順

  • AWS認定の認定サイトから以下を申し込む

    • SOA-P01 AWS Certified SysOps Administrator - Associate Practice
  • 試験の申し込みタブ

    • ピアソンVUE(or PSI)で模擬試験をスケジュールする
    • 画面下部の受験資格がある試験欄には模擬試験がないので注意
  • 受けたい試験を選択

    • SOA-P01: AWS 認定 SysOps アドミニストレーター – アソシエイト模擬
  • 試験言語を選択

  • 試験の詳細が表示され、問題なければ次へ

  • 支払情報と請求情報を入力

    • バウチャーコードがあれば入力
      • 本試験のバウチャーは会社から支給されていたが、模擬試験は自腹で払う必要があった…
    • バウチャがなければクレジット情報を入力
    • 住所は英語表記でなければ弾かれるので注意
  • 申込事項に問題がなければ予約内容を確定

    • 予約されましたと表示される
  • この画面の試験開始ボタンを押すと模擬試験が始まる

    • はじめに説明があるので、身構えなくてOK
  • 試験終了後にE メールでスコアのリンクが送られてくる

    • 5分程度待つことになる
    • 認定サイトのピアソンVUE試験の管理からみれる
    • スコアレポートの表示

問題集サイト#88まで一周した後のスコア

  • 合計スコア: 90% = (18/20)
    • ミスっていたのは以下のトピックのみなので復習をした
      • Monitoring and Reporting
        • モニタリングレポート 試験比重 22%
      • Security and Compliance
        • セキュリティとコンプライアンス 試験比重18%
1
2
3
4
5
6
7
8
トピックレベルのスコア:
1.0. Monitoring and Reporting 80%
2.0. High Availability 100%
3.0. Deployment and Provisioning 100%
4.0. Storage and Data Management 100%
5.0. Security and Compliance 75%
6.0. Networking 100%
7.0. Automation and Optimization 100%
  • 一度目の受験では模擬試験スコア 85%で余裕だと思ったが、本番で不合格となった
    • 合格最低点720,スコア700であった
    • 本番の方が圧倒的に難しいので注意

6. 試験

  • オンラインか、全国の試験センターで受験可能

    • コロナの影響で、2020からオンライン受験が可能になった
    • オンラインの方が先に埋まってしまうので早めに予約した方が良い
  • 一度目の受験

    • AWS利用経験ほぼなしでWEB問題集に取組み(説明は読み込まず)、模擬試験を受けたら85%だったので甘くみて即受験
    • 合格点720に対して20点足らず不合格
      • 試験問題更新直後で学習範囲がずれており、理解度も足らないため2択までしか絞れない問題が多かった
  • 二度目の受験

    • この間に運用監視サービスやCloudFormationを実務で経験
    • 書籍の該当範囲を読み込み、問題集サイトを二週実施(説明まで読み込んだ)、間違えた問題は全てノートにまとめて復習も実施
      • 間違えた問題はAWSの公式ページを読んで理解するよう努めた
    • 本番の試験はかなり余裕を持って取り組めた
    • 900/1000点で合格。合格点は720なのでかなり余裕があった
  • 合格すると認定サイトでスコアレポートとPDFの証明書を確認でき、デジタルバッジも発行可能になる

    • PDFに書かれているValidation Numberは、本人確認のためによく使う機会があるので、控えておくと良い
  • 追記:SysOpsの次にはDeveloperを取得した

関連記事

[Ionic Framework] Web/iOS/AndroidアプリのBuild方法

前提: モバイルの動作確認

  • 以下のコマンドでiOS/Andoridのそれぞれの画面を動作確認できる
    1
    ionic serve --lab

Ionic FirstApp Temaplate

Ionic ProjectのBuild

  • 単一のIonic Projectから、三種のAPをビルドできる
    • WEB(SPA), iOS, Android
  • 生成されたソースを各アプリストアで公開する

WebアプリとしてBuild

  • ここはベースとするフレームワークと同様

    • /dist配下にSPAとして動作するソースが払い出される(Angularベースの場合)
    • S3やFirebase Hostingに置けばサービス公開できる
  • WEB APのビルドコマンド

    1
    ionic build --prod

モバイルアプリとしてBuild

buildに必要なパッケージをPJにインストール

  • /wwwディレクトリが生成される
    1
    ionic integrations enable capacitor

iOS

  • buildしてiOSアプリとして動かす
    • /iosディレクトリが生成される
    • ここのソースをApple Storeに公開すれば良い
      1
      ionic cap add ios

以下はMac前提。IonicならMacでなくとも開発自体は問題なくできるが、動作確認をするにはMacである必要がある

Android

  • /androidディレクトリが生成される
    • ここのソースをGoogle Playに公開すれば良い
      1
      ionic cap add android
  • Android Studioを起動して実機確認

参考

関連記事

その他

@EventEmitter @Input @Output @ViewChild ACM AMP API Gateway AR AR.js AR.js Studio AWS AWS Amplify AWS Budgets AWS Cost Explorer AWS SDK for JavaScript AddThis Adobe XD Alexa Amazon CloudWatch Amazon Honycode Amazon SNS Android Angular Angular Material AngularFire AppSync Augury C CDN CI/CD Cloud Craft Cloud9 CloudFormation CloudFront CloudTrail Cognito Cost Anomaly Detection Cubase ai Cubasis LE DTM Disqus DynamoDB Elgato HD 60S Firebase Firebase Hosting Former2 Github Github Actions Github.com GithubEnterprise GithubPages Google Chrome Google Cloud Shell GraphQL Hexo Hosting IAM Ionic JSON JavaScript LadioCast Logging LowCode MFA MS Authentication MacBook Pro 16 Mind Node NETDUETTO Netflix Party Netlify Network NoCode Observable PO PdM Promise RPA ReactiveForm Recognition Route53 S3 SAM(Serverless Application Model) SAR SSL SYNCROOM Schematics ScrumInc Serverless Service Siri Sitemap Spark AR Steinberg UR44C Teams Touch Cast Studio Treetable TypeScript UI UI Bakery WAF WAFv2 WEB Page Dev WEB会議 WebAR WebSocketAPI Webhook Windows Power Automate Wireshark aot async/await aws config cloud9 display.land draw.io e2e test filter() forkJoin() google search console hexo-generator-amp iOS iPad Pro iPhone icarus map() mat input mat tree mat-checkbox mat-input mat-selection-list mmhmm ngFor plantUML popIn Aladdin2 then() vscode ”global is not defined” らくがきAR アジャイル アジャイル開発 クロスプラットフォーム ショートカット スクラム スクラム開発 テレワーク ファイル操作 ブラウザ型IDE プロダクトオーナー プロダクトマネージャー プロトタイピング リモートセッション 共同開発 双方向データバインディング 待ち合わせ処理 認定スクラムマスター 静的WEB Hosting 静的WEBサイトHosting
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×