たとえば、以下のようなケースです。

• チラシやポスターに載っているQRコード
• メールや資料に貼られているQRコード
• 見慣れない短縮URLにつながるQRコード
• 開く前にリンク先のドメインを確認したいQRコード
• QRコードの中身がURLなのかテキストなのか確認したい場合

最近はQRコードを読み取る機会が増えていますが、QRコード自体は見た目だけでは中身が分かりません。

そこで、QRコードやバーコードを読み取ったあと、開く前に内容を確認できるアプリとして 「あんしんQRチェッカー」 を作りました。

あんしんQRチェッカーとは

あんしんQRチェッカー は、QRコードやバーコードを読み取り、開く前に内容をプレビューできるシンプルな読み取りアプリです。

読み取った内容がURLの場合は、リンク先のドメインを表示します。

そのため、すぐにブラウザで開くのではなく、内容を確認してから開くかどうかを判断できます。

あんしんQRチェッカーアプリ – App Store

NINJA SYSTEMの「あんしんQRチェッカー」をApp Storeでダウンロードしてください。スクリーンショット、評価とレビュー、ユーザのヒント、「あんしんQRチェッカー」に似たゲームを見ることなどができます。

apps.apple.com

あんしんQRチェッカー – Google Play のアプリ

QR・バーコードを開く前に確認できるリーダー。

play.google.com

主な機能

あんしんQRチェッカーでは、主に以下の機能を利用できます。

• QRコードの読み取り
• バーコードの読み取り
• 画像からのQRコード読み取り
• URLやテキストを開く前にプレビュー
• リンク先ドメインの表示
• 短縮URLなど、注意して確認したい形式のお知らせ
• 読み取り履歴の保存と削除
• アプリ内の言語切り替え

QRコードリーダーとしての基本機能に加えて、「開く前に確認する」ことを重視しています。

QRコードは便利だが、中身が見えない

QRコードは、URLやテキストなどの情報を簡単に読み取れる便利な仕組みです。

一方で、QRコードは見た目だけでは中身が分かりません。

読み取ったあとにそのままブラウザを開くタイプのQRリーダーもありますが、個人的には「一度内容を確認してから開きたい」と感じる場面がありました。

特に、短縮URLや見慣れないドメインの場合は、いきなり開くよりも先に確認できた方が安心です。

開く前にURLやドメインを確認できる

あんしんQRチェッカーでは、QRコードを読み取ったあと、まず確認画面を表示します。

URLの場合は、リンク先のドメインも表示されます。

たとえば、QRコードを読み取った結果がWebサイトのURLだった場合でも、すぐにブラウザを開くのではなく、以下のように確認できます。

• 読み取ったURL
• リンク先のドメイン
• 内容の種類
• 開く / コピーするなどの操作

これにより、「このQRコードを開いてもよさそうか」を自分で確認してから操作できます。

画像内のQRコードも読み取れる

カメラで直接読み取るだけでなく、画像からのQRコード読み取りにも対応しています。

たとえば、スクリーンショットや保存済み画像に含まれるQRコードを読み取りたい場合に利用できます。

スマートフォン上で受け取った画像や資料内のQRコードを確認したいときにも便利です。

読み取り履歴をあとから確認できる

読み取った内容は、履歴としてあとから確認できます。

一度読み取ったURLやテキストを再確認したい場合に便利です。

また、不要になった履歴は削除できます。

履歴は端末内に保存されるため、必要に応じて自分で管理できます。

プライバシーに配慮した設計

あんしんQRチェッカーでは、プライバシーにも配慮しています。

• カメラ映像は端末内のみで処理
• カメラ映像を保存・送信しない
• 読み取ったデータを外部サーバーに送信しない
• 履歴は端末内に保存
• 履歴はいつでも削除可能

QRコードの読み取りは日常的に使う機能なので、なるべくシンプルで分かりやすく、安心して使える設計を意識しました。

こんな方におすすめ

あんしんQRチェッカーは、以下のような方におすすめです。

• QRコードを開く前に内容を確認したい方
• 知らないリンクや短縮URLを慎重に扱いたい方
• リンク先のドメインを確認してから開きたい方
• QRコードだけでなくバーコードも読み取りたい方
• 画像内のQRコードを読み取りたい方
• 読み取り履歴を端末内で管理したい方
• シンプルで見やすいQRリーダーを使いたい方

利用時の注意点

本アプリは、リンク先の内容や安全性を保証するものではありません。

あくまで、QRコードやバーコードの内容を開く前に確認しやすくするためのアプリです。

表示された内容を確認したうえで、ご自身の判断で利用してください。

また、QRコードやバーコードの読み取りにはカメラの使用許可が必要です。

ダウンロード

あんしんQRチェッカーは、iOS / Android の両方で利用できます。

あんしんQRチェッカーアプリ – App Store

NINJA SYSTEMの「あんしんQRチェッカー」をApp Storeでダウンロードしてください。スクリーンショット、評価とレビュー、ユーザのヒント、「あんしんQRチェッカー」に似たゲームを見ることなどができます。

apps.apple.com

あんしんQRチェッカー – Google Play のアプリ

QR・バーコードを開く前に確認できるリーダー。

play.google.com

まとめ

QRコードは便利ですが、読み取った先を開く前に内容を確認したい場面もあります。

あんしんQRチェッカー は、QRコードやバーコードを読み取ったあと、URLやテキストを確認してから開けるシンプルなアプリです。

普段からQRコードをよく使う方や、知らないQRコードをそのまま開くのが不安な方は、ぜひ使ってみてください。

外出先でメールやSNSを確認したり、リモートワークでクラウドにアクセスしたりする機会が急増しました。便利な一方、カフェや空港のフリーWi‑Fiには通信の盗聴や改ざんといったセキュリティリスクが潜んでいます。本記事では「なぜ危険なのか」「どうやって守るのか」を体系的に解説し、最後に“今日からできる7つのチェックリスト”を提示します。

フリーWi‑Fiの危険性を理解する

ここでは専門用語をできるだけ避け、カフェや駅でスマホを使う“ふつうの人”がイメージしやすいように説明します。ポイントは「だれが・どこで・どうやって」あなたの通信を狙ってくるかを知ることです。

のぞき見（盗聴）

• 何が起きる？
  同じ無料Wi‑Fiにいる他人が、専用アプリであなたの通信内容をこっそり受信します。
• イメージ
  カフェで手紙を書いていたら、隣の席から双眼鏡でのぞかれている感じ。
• 被害例
  写真付きのSNSメッセージやネットショップのパスワードが丸見えになる。
• カンタン対策
  鍵マーク（🔒）付きサイトだけ利用する・VPNを必ずONにする。

偽物Wi‑Fi（なりすまし）

• 何が起きる？
  攻撃者が本物そっくりのWi‑Fi名を作り、あなたをだまして接続させます。
• イメージ
  本屋の隣に「本物そっくりの偽コンビニ」が出来て、入った瞬間に財布を抜かれる。
• 被害例
  ログイン画面だと思ったページが偽物で、IDとパスワードを盗まれる。
• カンタン対策
  店員さんにSSID（Wi‑Fi名）を確認してから接続する・VPNをONにしておく。

通信のすり替え（中間者攻撃）

• 何が起きる？
  悪い人があなたと本物サイトの間に入り込み、内容を書き換えたり盗んだりします。
• イメージ
  郵便配達の途中で手紙を開封し、内容を勝手に書き換えて封をし直す。
• 被害例
  銀行サイトにアクセスしたつもりが、偽物画面で暗証番号を入力してしまう。
• カンタン対策
  ブラウザのURLが「https://」で始まっているか確認・二段階認証を設定。

チケット横取り（セッション乗っ取り）

• 何が起きる？
  ログイン後の“入場パス”を他人に盗まれ、パスワードなしでアカウントに入られる。
• イメージ
  映画館でチケットを見せたあと、誰かがその半券を拾って席に座る。
• 被害例
  SNSが勝手に乗っ取られ、詐欺リンクを拡散される。
• カンタン対策
  ログインには必ず二段階認証を設定・使い終わったら必ずログアウト。

セキュリティの基礎：暗号化と認証をかんたんに理解しよう

「暗号化？認証？ IT用語はむずかしい…」と感じる方も大丈夫。ここでは“通信をカギ付きにする仕組み”と“本人確認の仕組み”を、玄関ドアと身分証に例えて解説します。

暗号化とは「通信にカギをかける」こと

• イメージ
  手紙をそのまま投函すれば誰でも読めますが、暗号化は手紙を“金庫”に入れて送るイメージ。途中で盗まれても中身は読めません。
• Wi‑Fiの暗号化方式

• ポイント
  • できるだけ「WPA3」表示のネットワークを選ぶ
  • パスワードなし（“OPEN”と表示）のWi‑Fiは金庫なし＝丸裸と覚える

認証とは「本人かどうか確かめる」こと

• イメージ
  アパートのオートロックで部屋番号と暗証番号を打つ、または免許証を見せる行為が“認証”です。
• Wi‑Fiの場合
  • 家庭用（PSK）：みんなで同じ合言葉を共有 → 入り口は守れるが、中に入れば住人同士が丸見え
  • 企業用（Enterprise）：社員ごとに別々の合言葉 → 部屋に入ってからも個室が分かれていて安心
• ユーザーができること
  • カフェよりもホテルや空港ラウンジの「企業用Wi‑Fi」を優先
  • SSIDと一緒に「Enterprise」「802.1X」などの表示があれば安全度アップ

HTTPSは“インターネット上の暗号化”

• 鍵マーク🔒 を探そう
  ブラウザのURL左側に鍵マークが付いていれば、そのサイトとの通信は金庫入りです。
• HTTPとの違い
  • HTTP（鍵なし）：ハガキで送る → 誰でも読める
  • HTTPS（鍵付き）：金庫入り宅配便 → 配達員が開けられない
• コツ
  • 鍵マークが消えた、または赤い警告が出たサイトではログインしない
  • ChromeやSafariの設定で「安全でないサイトを自動ブロック」をONにする

VPNの役割と選び方

フリーWi‑Fiを安全に使う最大のコツは、VPN（Virtual Private Network） をオンにすることです。ここではしくみを小学生でもわかるイメージで説明し、失敗しないサービス選びのポイントを紹介します。

VPNって何をしてくれるの？

• たとえるなら
  公道（フリーWi‑Fi）を走るとき、あなた専用の屋根付き地下トンネルが出現し、出入口以外では誰にも見られない――それがVPNです。
• 得られる3つの安心
  1. のぞき見防止：トンネル内のデータは強力な暗号で保護
  2. なりすまし防止：偽Wi‑Fiに接続しても通信内容は解読不能
  3. プライバシー保護：アクセス元IPがVPNサーバーに置き換わり、位置情報がバレにくい

より詳しい仕組みやメリットは、こちらの記事で図解されています。

VPNサービスを選ぶ4つのチェックポイント

よくある疑問に答えます

• Q. 無料VPNでもいい？
  A. “タダより高いものはない”と言われるとおり、無料版は広告注入やログ販売で運営する例も。セキュリティ目的なら有料版が無難です。
• Q. どのタイミングでONにする？
  A. できれば “接続する前”、もしくは “自動で常にON” が理想です。難しければフリーWifi接続前後のONにする。
• Q. スマホもPCも保護できる？
  A. ほとんどの大手サービスはiOS/Android/Windows/macOSすべてに対応。1つの契約で家族全員まかなえるプランもあります。

より詳しくは以下の記事も参考にしてください。

Just a moment...

nordvpn.com

フリーWi‑Fiを使う前に！安全を守る7つのチェックリスト

外出先で「Wi‑Fiにつなぐ前・つないでいる最中・使い終わった後」に確認したいポイントを、やさしい言葉でまとめました。スマホにメモしておくと便利です。

まとめ ―― “便利”と“安全”を両立させよう

• フリーWi‑Fiは便利だけれど油断大敵
  盗み見・偽ネットワーク・ウイルス拡散など、知らないと引っかかるワナがたくさんあります。
• リスクは「知識＋ツール＋習慣」で大きく減らせる
  • 暗号化方式（WPA3、🔒HTTPS）を選ぶ
  • VPNで通信を“地下トンネル”化
  • 7つのチェックリストを毎回確認
• スマホもPCも“設定1分”で守れる
  自動VPN、二段階認証、共有機能のON/OFF切替はワンタップで完了。最初に設定しておけば、以後の手間はほぼゼロです。

旅先やカフェでも安心してネットを楽しむには「正しい知識」と「カンタンな予防」が最強の組み合わせ。
この記事を読み終えた今、まずはVPNアプリを入れて自動起動をONにしてみてください。今日からあなたの通信は、しっかり鍵のかかった“安全な通路”を通るようになります。詳しくはこちら。

エンジニアなら、「AWS」とか「Google Cloud」のようなクラウドサービスの話を振られることはよくあるが、先日エンジニアコミュニティの話で、セキュリティ関連の話題があった。
聞いてみると、統合セキュリティシステム を開発しているGenetecという企業があるらしい。

正直、セキュリティと聞くと「ファイアウォール」とか「ウイルス対策ソフト」みたいなサイバーセキュリティを思い浮かべることが多い。ただ「Genetecはそれだけじゃなくて、監視カメラや入退室管理などの物理セキュリティとデジタルセキュリティを統合した仕組みを提供している」らしい。

最近、企業のセキュリティ対策がどんどん高度化していることはニュースなどで目にする。特に 「ゼロトラスト」 という概念が広まり、外部はもちろん、社内ネットワークすらも「信用しない」前提でセキュリティを強化する動きがある。
確かに、リモートワークの普及やクラウド化が進む中で、物理的なアクセス管理とデジタルセキュリティを組み合わせるニーズは増えていそうだ。
なので今回は統合セキュリティシステム「Genetec」について調べてみることにした。

統合フィジカルセキュリティ管理システム・プラットフォームのGenetec

Genetecは、IPベースのビデオ監視、入退出管理、自動ナンバープレート認識 (ALPR)、通信、分析を組み合わせた総合セキュリティソリューションにより、お客様の日常業務を守ります。

www.genetec.com

そもそも統合セキュリティシステムとは？

「統合セキュリティシステム」という言葉を聞いて、最初はピンとこなかった。
普段エンジニアとして働いていると、サーバーのセキュリティ対策 や システムの脆弱性 には関心があるが、それとは違うアプローチの話のようだ。

調べてみると、統合セキュリティシステムとは、物理セキュリティ（監視カメラ・入退室管理など）とデジタルセキュリティ（ファイアウォール・アクセス制御など）を一元管理する仕組みのことらしい。
たとえば、大企業のオフィスでは、社員の入退室記録と、社内ネットワークのアクセスログを紐づけて管理することで、不審な動きを検知できる。
・「会社のサーバーに深夜ログインした人物が、実際にはオフィスにいない」
・「退職者のIDが使われているが、入館記録がない」
といった状況があれば、すぐに異常としてアラートを出せるわけだ。

物理セキュリティとデジタルセキュリティの融合

これまで、物理的なセキュリティと、デジタルなセキュリティは別々に管理されるのが一般的だった。
・オフィスのセキュリティ担当は「監視カメラ」や「入館証の管理」
・IT部門は「サーバーアクセス」や「ファイアウォールの設定」
というように、分業されていた。

でも、最近では サイバー攻撃と物理侵入が連携した犯罪も増えている らしい。
例えば、ある企業では「内部関係者がUSBメモリを社内のPCに挿してマルウェアを仕込む」といった内部脅威が問題になったこともあるという。
こうしたケースでは、単に「誰がどのPCにログインしたか」だけでなく、「その人物がオフィスにいたのか？」という物理的な情報も重要になる。

そこで登場するのが、統合セキュリティシステム だ。
「物理空間での行動」と「デジタル空間でのアクセス」をひとつのシステムで管理することで、より高度なセキュリティを実現できる。

企業にとってのメリット

この仕組みを導入することで、企業には以下のようなメリットがある。

1. 不正アクセスの検出
   → 物理入館記録とシステムログを照合し、不審なアクセスを即座に検知
2. 情報漏洩のリスク低減
   → 内部関係者の不正行為も含めて監視できる
3. セキュリティ管理の効率化
   → 複数のシステムを統合することで、管理の手間が減る

このあたりを見て、「なるほど、統合セキュリティシステムって単なる監視カメラの強化じゃなくて、もっと幅広い概念なんだな」と感じた。

そして、こうした統合セキュリティシステムを提供している代表的な企業のひとつが、Genetec だということがわかった。

カナダ発のGenetecとは？

Genetec（ジェネテック）は、1997年にカナダ・モントリオールで設立された企業で、主に 監視カメラシステム、入退室管理、ナンバープレート認識システムなどを統合したセキュリティプラットフォーム を提供している。
日本でいうところの セコム に近いイメージだが、単なる警備会社ではなく、高度なIT技術を活用して物理・デジタルの両方をカバーするセキュリティシステムを開発している点が特徴 だ。

例えば、監視カメラの映像をAIで解析し、不審者の行動パターンをリアルタイムで検出 したり、オフィスや工場の入退室データとネットワークのアクセス履歴を連携させる ことで、不正なログインや情報漏洩のリスクを軽減する仕組みを作っている。

もともとは北米やヨーロッパを中心に展開していた企業だったが、最近になって 日本市場にも本格的に進出 しているらしい。
実際、公式サイトを見てみると、日本語対応もしっかりしており、日本の企業向けのソリューションを積極的に提供していることがわかる。

また、Genetecの技術は、警察機関や空港などの公共機関にも導入されている という点も興味深い。
公共のセキュリティが厳しくなる中で、こうした高度な統合システムが必要とされているのだろう。

Genetecは、単なるセキュリティ会社ではなく、監視カメラ・入退室管理・ネットワークセキュリティを統合した「次世代のセキュリティプラットフォーム」を提供している企業 と言える。

次は、そんなGenetecの代表的なサービス「セキュリティセンターのGenetec」について詳しく見ていこう。

Genetecの主力サービス「セキュリティセンターのGenetec」とは？

Genetecが提供するサービスの中でも、特に注目すべきなのが 「セキュリティセンターのGenetec」 という統合プラットフォームだ。
公式サイトにも詳しい情報があるが、簡単に言うと、監視カメラ、入退室管理、ナンバープレート認識、アラーム監視など、あらゆるセキュリティシステムを一元管理できるソリューション というイメージだ。

① セキュリティの全機能を統合

通常、企業や施設のセキュリティシステムは バラバラに管理されている ことが多い。
例えば、

• 監視カメラシステム → 別のメーカーのものを導入
• 入退室管理 → 専用のICカードシステム
• 警報システム → 防犯会社の契約サービス

こうしたシステムが分かれていると、データを連携させるのが難しく、異常が発生してもすぐに気づけないことがある。
例えば、「あるエリアで不審な人物が検知されたが、入退室管理システムにはその人物の記録がない」といった事態が起きた場合、すぐに対応できるとは限らない。

しかし、「セキュリティセンターのGenetec」なら、すべてのセキュリティ機能を一つのプラットフォームで統合管理 できる。

• 監視カメラと入退室管理を連携
• 特定のエリアで異常が発生した場合、自動でアラートを出し、カメラ映像を確認
• 施設のセキュリティ全体をリアルタイムで可視化

このように、個別のシステムを一つのインターフェースで管理できるのが大きな特徴だ。

② クラウド対応で柔軟な運用が可能

もう一つの特徴は、クラウド環境での運用が可能 という点だ。
一般的なセキュリティシステムは オンプレミス（社内サーバーで運用） が多いが、Genetecは クラウドベースのソリューション も提供している。

これによって、

• 複数拠点のセキュリティを一括管理 できる
• リモートワークや出張中でも、管理画面から状況を確認 できる
• AIを活用した異常検知システムを導入しやすい

といったメリットがある。

特に、昨今のセキュリティ環境では 「ゼロトラストセキュリティ」 が重視されており、「社内ネットワークにいるから安全」という考え方は通用しなくなっている。
そのため、クラウドを活用して遠隔からでもセキュリティを強化できる仕組みは、今後ますます需要が高まりそう だ。

③ 企業や自治体での導入事例

Genetecの「セキュリティセンター」は、企業だけでなく、自治体や公共機関でも採用されている という。
例えば、

• 空港や鉄道の監視システム
• 大規模な商業施設やオフィスビルのセキュリティ管理
• 警察機関の防犯監視

といった用途で使われている。
実際に、Genetecのシステムを導入することで「監視業務の効率化」「異常発生時の迅速な対応」が実現できたケースが多数あるそうだ。

このように、「セキュリティセンターのGenetec」は、企業のセキュリティ管理を一元化し、よりスマートに運用できる次世代のソリューション と言える。

実際にGenetecの統合セキュリティシステムを見て思ったこと

ここまで調べてみて、「統合セキュリティシステム」という考え方は、これからの時代にますます重要になりそう だと感じた。

特に印象的だったのは、クラウド対応で複数拠点の管理ができる点。
セキュリティといえば「物理的な警備」が主流だったが、IT技術を駆使することで、オフィスだけでなくリモート環境でも一貫したセキュリティ管理ができる のは大きな強みだと思う。

また、「監視カメラ＋入退室管理＋ネットワークログの統合」という仕組みは、サイバー攻撃と物理的な不正アクセスを同時に防ぐ という点で、今後さらに導入が進みそうだ。

企業や自治体だけでなく、中小企業でもこうした統合型のセキュリティシステムが一般的になれば、よりスマートで安全な環境が実現できるかもしれない。
この分野は今後さらに進化しそうなので、引き続き注目していきたい。

まとめ：統合セキュリティシステムの進化とGenetecの可能性

今回、「統合セキュリティシステム」について調べる中で、物理的なセキュリティとデジタルセキュリティを統合する流れが加速している ことがよく分かった。

特に、Genetecの「セキュリティセンターのGenetec」は、監視カメラ、入退室管理、ネットワークセキュリティを一元管理できる次世代のプラットフォーム という点が魅力的だ。
企業のセキュリティ対策は年々高度化しており、従来のバラバラな管理では限界がある。そうした中で、一元管理できるソリューションが今後さらに普及していく可能性は高い だろう。

また、Genetecは日本市場にも本格進出しており、今後、国内の企業や自治体での導入が増えるかもしれない。
セキュリティの課題は、企業規模を問わず重要になってきているため、この分野の技術進化には引き続き注目していきたい と思う。

　これまでのFirebase Cloud Messaging（FCM）では、各デバイスに割り当てられるトークンを取得し、そのトークンを使って通知を送信する必要がありました。しかし、最新のFCMでは、このプロセスが簡略化され、トークンを明示的に管理しなくても、より簡単にプッシュ通知を送信できるようになっています。この変更により、Firebase Notificationのセットアップがさらに簡単になり、通知の送信までのステップが大幅に短縮されました。

　本記事では、FCMにおけるトークン不要での通知送信の変更点について詳しく解説し、従来の方法との違いや、実装におけるメリットについて紹介します。

Firebase Cloud Messaging（FCM）とは？

　Firebase Cloud Messaging（FCM）は、Googleが提供する無料のクロスプラットフォームプッシュ通知サービスで、アプリにリアルタイムの通知機能を簡単に統合することができます。FCMは、サーバーからモバイルアプリやウェブアプリに通知を送信するために利用され、ユーザーに新しい情報やアラートを即座に届けるのに最適なツールです。

これまでのトークンベースの通知送信

　従来のFCMの通知送信方法では、デバイスごとにFCMトークンを取得し、サーバーにそのトークンを保存する必要がありました。このトークンは、デバイスが一意に特定されるIDであり、サーバーからデバイスに通知を送信するための必須要素でした。

従来のトークンベースの通知送信の流れ：

1. デバイスがFCMトークンを取得：各デバイスがFirebase Messagingインスタンスからトークンを取得。
2. トークンをサーバーに保存：取得したトークンをバックエンドサーバーに保存し、デバイスごとに管理。
3. 通知の送信：サーバーから特定のトークンを使って通知を送信。

　このプロセスは、シンプルに見えますが、複数のデバイスやユーザーを管理する場合、トークンの管理が大変になることがありました。また、トークンが変更されたり無効になった場合の処理も必要でした。

最新のFCM：トークン設定不要で通知を送信可能に

　最新のFCMでは、ユーザーやデバイスごとに明示的なトークンを取得しなくても、通知を送信できるようになりました。この変更により、従来のようなトークン管理の負担が軽減され、通知の送信がさらに簡単に行えるようになっています。

トークン不要での通知送信の流れ：

• 簡単な通知送信：サーバー側でのトークン管理が不要になり、コードがシンプルに。
• ユーザーセグメントやトピックを指定：トークンを個別に取得する代わりに、ユーザーのセグメントやトピックに基づいて通知を送信。
• Firebaseによる自動管理：FCMがユーザーやデバイスごとの通知管理をバックエンドで自動的に処理。

どのようにしてトークン不要になったのか

　FCMの新機能により、トピックベースまたはユーザーセグメントベースでの通知送信が可能になり、個別のデバイスに対してトークンを管理しなくても、通知が届く仕組みが導入されました。これにより、複数のユーザーに対して一斉に通知を送信する場合でも、トークンを介さずに操作ができるようになっています。

トピックベースの通知送信：

　トピック通知を利用することで、アプリの特定の機能やカテゴリーに対して、ユーザーが登録したトピックに基づいて一括通知が送信できます。たとえば、「ニュース」や「スポーツ」などのトピックにサブスクライブしたユーザーに対して、一度の操作で通知を送信できます。

{
  "to": "/topics/news",
  "notification": {
    "title": "最新のニュース",
    "body": "本日のトップニュースをご確認ください"
  }
}

ユーザーセグメントベースの通知送信：

　Firebase Analyticsと連携して、特定のセグメント（例：アクティブユーザー、特定の行動を取ったユーザーなど）に対しても通知を送信できます。これにより、パーソナライズされた通知を容易に実装可能です。

トークン管理が不要になることのメリット

1. 通知管理の簡素化

　トークン管理が不要になったことで、サーバーでのトークンの保存や更新処理が不要になり、通知送信のロジックが大幅に簡素化されました。トピックベースで一括通知を送信できるため、特定のグループやセグメントに対する通知が容易に行えます。

2. スケーラビリティ

　トークンを個別に管理しなくてもよいため、特に大規模なユーザー基盤を持つアプリケーションにおいて、スケーラブルな通知システムが実現できます。これにより、何百万ものデバイスに対してもシンプルなコードで対応可能です。

3. コストの削減

　サーバーサイドでのトークン管理にかかるコストやメンテナンスが削減されます。トークンの保存、更新、無効化の処理を省けるため、サーバー側のリソースを節約できます。

4. Firebase Analyticsとの連携

　Firebase Analyticsと連携することで、特定のユーザーグループに対して通知を簡単にターゲティングできます。これにより、マーケティングキャンペーンやプロモーション通知などが効率的に実行可能です。

トークンが必要な場合は

トークンが不要になったとはいえ、トークンベースの通知が完全に廃止されたわけではありません。特定のデバイスに通知を送信する場合や、個別に通知を送るケースでは、引き続きトークンを使用できます。

トークンベースの通知が必要なユースケース：

• 個別のセグメント化が必要でない場合や、サーバー側で特定のデバイスに対する高度な制御が必要な場合。
• 特定のユーザーやデバイスに対して直接的な通知を送りたい場合。
• ユーザーごとにカスタマイズされたメッセージを送りたい場合。

まとめ

　Firebase Cloud Messaging（FCM）は、トークン不要で簡単に通知を送信できるようになり、サーバーサイドでのトークン管理が大幅に簡素化されました。この変更により、開発者はトピックベースやユーザーセグメントベースの通知を活用し、スケーラブルで効率的な通知システムを構築できます。特定のユーザーに通知を送信する場合は、引き続きトークンを使用することも可能です。

　これにより、プッシュ通知の実装がさらにシンプルになり、通知の管理や運用が容易になります。今後のアプリ開発において、Firebase Notificationを活用して効果的なメッセージングを行いましょう。

　Firebaseには、アプリに通知機能を組み込むための2つの主要なツールがあります。それがFirebase Notification（Firebase Cloud Messaging）とFirebase In-App Messagingです。この2つは、ユーザーにメッセージを送信するための便利な手段ですが、それぞれ異なるユースケースや目的に向けて設計されています。

• Firebase Notificationは、主にプッシュ通知を通じてユーザーにリアルタイムでメッセージを届けるためのツール。
• Firebase In-App Messagingは、アプリをアクティブに利用しているユーザーにアプリ内で特定のメッセージを表示するためのツールです。

　本記事では、Firebase NotificationとFirebase In-App Messagingの違いを徹底解説し、それぞれの強みや使い方を紹介します。

Firebase Notificationとは

　Firebase Notification（Firebase Cloud Messaging, FCM）は、プッシュ通知を通じてユーザーにリアルタイムでメッセージを送信するためのツールです。アプリがバックグラウンドにある場合でも、システムの通知領域にメッセージが表示され、重要な情報やリマインダーを即座に伝えることができます。

主な特徴：

• デバイスへのプッシュ通知：Firebase Notificationは、ユーザーがアプリを利用していない場合でも、デバイスのシステムトレイに通知を表示します。これにより、ユーザーはアプリを再度開いたり、通知内容に基づいたアクションを取ることができます。
• バックグラウンド通知：アプリがバックグラウンドにある場合でも、通知を受け取れるため、重要な情報を見逃さずに届けられます。
• 通知メッセージのカスタマイズ：プッシュ通知のタイトル、本文、画像、アイコンなど、さまざまな要素をカスタマイズすることができます。
• 高いスケーラビリティ：数千、数百万のデバイスに対して、同時にプッシュ通知を送信できるため、規模の大きなアプリにも対応可能。

Firebase Notificationのユースケース：

• リマインダー：イベントのリマインダーや予約確認。
• 新コンテンツの通知：新しいブログ記事、ニュース、またはアプリ内の新機能を紹介するための通知。
• プロモーション通知：セールやキャンペーン情報をユーザーに知らせる。

メリット：

• ユーザーがアプリを開いていなくても、メッセージをデバイスに届けることができる。
• 直接的でわかりやすい方法で、ユーザーに重要なメッセージを通知可能。

デメリット：

• アプリがフォアグラウンドにある時のエンゲージメントは低め。
• 通知が多すぎると、ユーザーにとって煩わしく感じる可能性がある（通知オフにされるリスク）。

Firebase In-App Messagingとは

Firebase In-App Messagingは、アプリ内でユーザーにメッセージを表示するツールです。ユーザーがアプリをアクティブに使っている間に、ポップアップやバナー、またはフルスクリーンで特定のメッセージを表示できます。これにより、ユーザーの操作を促したり、新機能の紹介、プロモーションを訴求することが可能です。

主な特徴：

• アプリ内でのメッセージ表示：ユーザーがアプリを使用している間に、特定のイベントに基づいたメッセージを表示できます。たとえば、特定のページを訪問したユーザーにのみメッセージを表示する、といったターゲティングが可能です。
• カスタマイズ可能なデザイン：バナー、ポップアップ、全画面メッセージなど、さまざまなスタイルでメッセージを表示でき、ユーザーに直接アピールすることができます。
• 特定のアクションを促す：Firebase In-App Messagingは、特定のアクションをユーザーに促すのに最適です。たとえば、アカウント作成を促進したり、新しい機能を紹介するメッセージを表示します。
• セグメント化とターゲティング：特定のユーザー層に対してメッセージを表示したり、ユーザーのアクションに基づいてメッセージをパーソナライズすることが可能です。

Firebase In-App Messagingのユースケース：

• 新機能の紹介：アプリに新機能が追加されたときに、ユーザーにその使い方を説明するメッセージを表示。
• プロモーションの案内：アプリ内での特典やセール情報を訴求。
• ユーザー行動の促進：例えば、「登録して10%オフ」や「この機能を試してみてください」などのCTA（Call-to-Action）を促す。

メリット：

• ユーザーがアクティブにアプリを利用しているときにメッセージを表示できるため、エンゲージメントが高い。
• 特定のユーザー行動や条件に基づいて、柔軟にメッセージを表示できる。

デメリット：

• アプリを利用していないときにはメッセージが届かない。
• ユーザーがメッセージをすぐに閉じてしまう可能性がある。

Firebase NotificationとFirebase In-App Messagingの違い

どちらを使うべきか？

• リアルタイムで重要な情報を伝えたい場合は、Firebase Notificationを使用しましょう。例えば、新しいメッセージが届いた場合やイベントのリマインダー、システム通知などに最適です。
• アプリ内でユーザーに特定の行動を促したい場合は、Firebase In-App Messagingが適しています。例えば、新機能の紹介やアクションを誘導するプロモーションメッセージなど、ユーザーがアクティブにアプリを使っている時に効果的です。

まとめ

　Firebase NotificationとFirebase In-App Messagingは、どちらもアプリにメッセージを届けるための重要なツールですが、その使用方法は大きく異なります。Firebase Notificationは、ユーザーがアプリを利用していない場合でもプッシュ通知を送信できる一方で、Firebase In-App Messagingは、ユーザーがアクティブにアプリを使用している時にのみメッセージを表示し、特定の行動を促すことが可能になります。

　両者を効果的に組み合わせることで、ユーザーのエンゲージメントを高め、重要な情報をタイムリーに届けることができるため、アプリ開発における通知戦略を強化することが可能です。

量子コンピューターとは

　量子コンピューターとはそもそも何でしょうか。従来のコンピュータと一体何が違うのでしょうか。まずはここから解説してみたいと思います。
　従来のコンピューターはビット(bit)という0と1の世界(2進数)で作られており、2進数同士を計算することで演算を行っています。一方量子コンピューターでは量子ビットという単位が用いられており、0と1と重ね合わせという状態を持っています。この重ね合わせという状態を利用することで従来のコンピュータでは出来なかった特定の問題に対しての複雑な問いを解くことが期待されています。
　これまで従来のコンピューターでは数十年に渡り飛躍的に性能向上が図られており、ムーアの法則と呼ばれる「半導体の集積率が18ヶ月で2倍になること」従って伸びてきました。一方ビッグデータ処理や機械学習が流行っていく中で計算領域の限界に来ていることも事実であり、スパコンでも数千年かかると言われる計算を量子コンピューターで解くことが期待されています。

量子とは

　そもそも量子とは何でしょうか。Wikipediaを見てみましょう。

量子（りょうし、quantum）は、物理学において用いられる、様々な物理現象における物理量の最小単位である。主に巨視的な物理を取り扱う古典力学では、物理量は実数で表される連続量だが、量子力学では、量子を数え上げたものとして扱われる。たとえば電気量は、電気素量の整数倍の値となる。

量子 – Wikipedia

　少し小難しい言葉が並んでいますが、覚えるポイントは物理現象における物理量の最小単位である、ということです。量子(光子や粒子)と通常の物質で何が違うのでしょうか。それは量子の場合は観測時によって状態が変わるということです。これは二重スリット実験という有名な実験で証明されたもので、、、説明が難しいので分かりやすいYoutubeを載せておきます笑

量子コンピューターの計算方法

　量子コンピューターでは0と1と重ね合わせという量子ビットを利用することと、量子の性質が分かったところ、実際にどうやって問題を解いていくか学んでみます。
　今回はGroverのアルゴリズムという方法を用いて4桁のパスワードを解くことを例に考えてみましょう。一般的なコンピューターでは4桁のパスワードを解くときに0000から9999までを1つ1つ入力することで当てるため、最大10000回の試行回数(平均10000/2 = 5000回)が必要になります。一方量子コンピューターでGroverのアルゴリズムを利用するとおよそ100回の試行回数で当てることが可能になるようです。
　※アルゴリズムについては勉強中なので別の記事で詳しく解説してみます…

ゲート型とアニーリング型

　量子コンピューターにはゲート型とアニーリング型という2つに別れています。
　ゲート型は前述で説明したような量子ビットを用いた計算機であり、1994年にショアのアルゴリズムが発明されると注目を浴びました。しかし実現には様々な課題があり、現在は因数分解程度の問題しか解くことができず実用化にはまだまだ掛かると言われています。最近ではIBM社がIBMQと呼ばれるゲート型量子コンピューターを川崎市に設置したようです。
　一方アニーリング型は焼きなましという方法が用いられ、元々は熱処理の方法であったものを量子コンピュータに応用した技術になります。ゲート型より実用化面で注目されており、カナダのD-Wave社は2011年に「D-Wave One」(128量子ビット)の発表から始まり、2020年には「D-Wave Advantage」(5000量子ビット)が発表されています。

量子コンピューターを動かすには

　量子コンピューターを直接動かすには、設備を保持している施設に直接出向くか(といっても見学程度かな？）、クラウド上で展開されているサービスを利用するのが良いでしょう。最近だとAWS BracketやAzule Quantumが利用可能なので金額に気をつけて利用してみてください。気づかぬうちに高額請求になることは避けましょう。
　またシミュレーターなども色々出ているみたいですので、私も今後試してみようと思いますが、みなさんもぜひ試してみてください。IBM Quantum Simulators、qsim

将来の期待

　ここまで量子コンピューターとは何か、どんなメリットが有るのかなどを簡単に説明しましたが、続いて実際にどのような事に役立つのかを解説してみます。
　現在有力視されているのが、化学・金融・EC・広告・物流など分野において従来のコンピューターやスパコンで解くことに時間がかかってしまうような問題を解くことが想定されています。例えば渋滞を回避するための最適化問題だと一つの区画を絞っても数千台という車が走行しており、これらの車に最適な経路を示すには膨大な計算が必要なことは想像で分かると思います。こうした問題を量子コンピューターで早い時間で解ければ、日常生活がより便利になるでしょうか。
　また、ECサイトなどでレコメンデーションをユーザーに表示するアルゴリズムがあるとすると、ユーザーの趣向を表す状態は購入履歴、閲覧履歴、性別、居住地、年齢など条件を加えれば加えるほど、計算処理に時間がかかることが想定されます。こうした問題を解決し、より既存ECサイトの売上が上がるようになるでしょうか。

エンジニアとして

　最後に、私は普段はAndroidアプリの開発、バックエンド、AWSなどのクラウドを中心に開発をしているただのエンジニアですが、今後量子コンピューターの領域を学んでいくべきかを考えてみます。

　現在の量子コンピューターはまだまだ実用化段階で、すぐにビジネスに直結できるものではなくPoCが主流になっているという感覚です。一方実用化の兆しも見えてきており、実用化された際には従来のコンピューターが主流にはなりつつも、多くの日常生活の問題は量子コンピューターを利用して解決されるようになるでしょう。そうした場合現代のエンジニアが将来求められることは、こうした複雑な問題を解きビジネスの価値を上げることであると考えています。
　また、現代のように設計をしてプログラムを書いてサービスを作る、お客様に納品する、運用するといった作業は最終的にはNoCodeツールや人工知能で置き換わることも想定されます。

　そういった中で、今後10年、20年を見据えると、今流行りのDARQと呼ばれるブロックチェーン、AR/VR、機械学習、量子コンピュータのいずれかの技術スタックが求められる予想ができますので、エンジニアとして何かしらの専門性を作っていく上で、量子コンピューターを少しずつ学んでいくのは将来の投資になるのではないかと思います。(私自身も今後どこまで学ぶかは悩み中…笑)

以上です。

前提知識

　まず試験を受ける前の私の業務経歴としては、3ヶ月ほどAWSを業務で使用しており、主にサーバーレス周りを利用していました（Lambda, SQS,SES,Step Function,ECS,Fargateなど）。ただ、業務の中でAWSのみを開発していたわけではなくバックエンドなどの開発と並行していましたので、業務経験としてはかなり乏しい状態だったと思います。

試験計画

　次に試験を受けるまでの勉強の流れを考えます。勉強の流れとしては、試験の概要や問題のテイストなどを知るためにサンプル問題や他サイトの問題集などを少し漁ります。そして試験問題の方向性を掴んだ上で、一通り書籍などでAWSサービスを学習します。その後、Udemyなどで出ている試験問題を解きつつ弱い問題に関してはBlackBeltを活用して、各AWSサービスの機能や注意点などを詰めていく流れです。

３ヶ月間の勉強

3ヶ月前

　私の場合はAWS Solution Architect Asociate(SAA)用の本を2冊買い、AWSサービスを網羅的知ることにしました。購入したの下記の２冊で３資格に対応しているという白い方の本から読んでみました。しかし３資格対応と銘打っているだけに内容が全体的に浅く理解まで行くことが出来なかったので、白い本の方は１週間ぐらいで読むのを辞めました(笑)
　結局重点的に利用したのはオレンジ本の方で、AWSの各サービスの概要や細かい設定、ユースケースなどを知ることができるため、こちらで網羅的にAWSとは何ぞやというのを学びました。また、このとき割と有名なEC2やLambdaは自分で手を動かしながら実際に触ってみて記憶の定着を図っています。(無料枠を利用することに注意してください)

2ヶ月前

　この頃にはUdemyという勉強用の動画をパッケージとして提供している動画サービスを利用しています。ちょうどセールが始まっていたので、AWSの全サービスを説明してくれている動画をベースに、手で動かしながら説明を聞くということをしていました。やはり本で読むだけよりも実際に手で触ってみて動かすのが一番効率がよいです。

【SAA-C03版】これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座

03版の新試験対応！アソシエイト試験突破に必要な経験と知識を1000ページ以上の理論学習、40サービス以上のハンズオン、3回分の模擬テストで獲得していきます！　網羅的にAWSを利用していく基礎力を身に着けることが可能です！

www.udemy.com

　また、下記の試験問題集６回分のUdemyもありましたので、こちらも購入しこの期間で1週したと思います。ただこの時期に点数が取れなくても悲観しなくて大丈夫です。実際私自身も全く点数が取れず全体的に40~50%ぐらいの正答率だったと思います。正解できなかった問題については必ず復習し、なぜその問題が正解だったかをしっかりと理解してください。

【2025年版】AWS認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

2025年最新のSAA-C03版に適用した問題集です。試験レベルで難易度の高めの問題などを中心に構成しており、今一歩合格が出来ていない方向けの最終仕上げとしての問題集です。

www.udemy.com

　ちなみにこの試験問題は実際の問題ではないので、あくまで試験を受けるときの考え方や理解をするためのものとして利用してください。試験を受けた感想では、同じような問題は２問ぐらいしかなく、ベースのAWSの考え方や各サービスのユースケースをきちんと理解しないと、確実に受からないと思います。

1ヶ月前

　この頃には手で動かすことは徐々に減らし、Udemyの試験問題を解きつつ、理解度が低いAWSサービスについてBlackBeltで学習していました。BlackBeltはAWSが出している各サービスを説明した資料になりますが、Youtubeなども出ているものがあるため、一つ一つのサービスを深く学ぶことができます。

AWS サービス別資料

アマゾン ウェブ サービス (AWS) は安全なクラウドサービスプラットフォームで、ビジネスのスケールと成長をサポートする処理能力、データベースストレージ、およびその他多種多様な機能を提供します。それらを活用するために役立つ日本語資料、動画...

aws.amazon.com

　私の場合はEC2,S3,SNS,RDS,CloudFormationなど、試験に出やすいサービスで深く知らないものを中心にBlackBeltのyoutubeを聞いたり、pdf読んでいました。結構時間がかかるものなので、１日から２日に１つ読むようなイメージでいいと思います。

１週間前

　この頃にはUdemyの高難度問題の試験問題集を２週程度解き終わり、大体平均7,80%は取れるようになっていたので、割と自身がついてきた時期だったと思います。残り1週間程度でしたので、どちらかというと新しいことを学ぶよりは既に学んだことを復習することが多かったです。

　更に下記のサイトのようなでAWS SAAの他のパターンの問題も解いてみて、今まで自分が解いたことのないような問題が来ても、AWSサービスの理解し解くことができるかを試していました。実際に見てみると、やはりサイトによって問題の形質や粒度が大きく違うので、どんな問題が来ても答えられるようにしておくのがベストです。

SAA

cloud-license.com

試験当日

　私は朝が弱い方なので、、、比較的遅い15時ごろからの試験を選択しました。そのため午前中は復習などをした後に試験に挑んでいます。ちなみに試験時は本人確認書類など身分証の確認や写真を撮ったりしますので忘れないようお気をつけください。

　実際の試験問題はというと、文が長く難しい！！と思ったのが率直な感想です。今までUdemyの高難度と言われる問題を解いていましたが、正直それらの問題と同等レベルか少し上のレベルの問題が出てきました。単にAWSサービスを答えさせるような問題はほとんどなく、ユースケースに応じた適切なサービスは何か考え、性能、コスト、セキュリティなど問題文にある注釈に注意しながら最適な答えを考えさせる問題が多かったという印象です。

　日頃から問題を解くときに、各サービスの特徴は何かということと、ユースケースパターンをインプットしておくことが必要だと感じました。結果は合格でしたが正答率は70%だったので、かなりぎりぎりといった感じです。以上がAWS SAAの合格体験記になります。

　もし受験される方は、本記事が参考に、なれば幸いです。
エンジニアを1から学びたい方は、【CodeCampGATE】もオススメです！

　スクラム開発は、1990年代にジェフ・サザーランド氏とケン・シュエイバー氏が中心となって作り上げた手法です。その名称「スクラム」は、日本人の野中郁次郎氏と竹内弘高氏によって提唱されました。

　　スクラムはアジャイル開発の一種であり、定期的なレビューを行いながらチームをより強固にすることができます。詳しいスクラム開発の内容については、こちらをご覧ください。

最近注目のスクラムによるアジャイル開発とは？メリットは何？

スクラム開発はユーザーのニーズが目まぐるしく変わる現代では、アジャイル開発とセットで用いられることが多い開発手法です。スクラムを導入することで強固で柔軟なチームを作り上げることが可能です。

techgrowup.net

プロダクトオーナー(PO)の役割とは？

　プロダクトオーナー（PO）は、スクラム開発におけるプロダクトの最終的な意思決定権を持つ人物です。また、プロジェクトには常にゴールがあり、そのゴールに向けてどのような優先順位で進めていくかを判断する役割も担います。

　「プロダクトの意思決定や優先順位付けは、具体的にどうすればいいのか？」という疑問が浮かぶかもしれません。以下に、プロダクトオーナーが果たすべき8つの役割を紹介します。

1.　プロダクトのビジョンを考え、伝える

　プロダクトオーナーは、プロダクトの最終意思決定者であり、プロダクトに対する責任を持ちます。そのため、プロダクトに対する強い意志や成し遂げたいビジョンを考える必要があります。

　ビジョンを考えるだけでなく、スクラムチームやステークホルダーに明確に伝えることも重要です。言葉でしっかりと伝えなければ、チームはゴールを見失ってしまいますので、繰り返し伝えることを心がけましょう。

　また、プロジェクトには上司、顧客、他社などのステークホルダーが存在しますが、最終的な意思決定はプロダクトオーナーが行うため、プロダクトの責任を持ってビジョンを立てる必要があります。

2.　プロダクトバックログを作る

　プロダクトオーナーは、プロダクトのビジョンに従ってプロダクトバックログを作成する必要があります。厳密には、バックログはスクラムマスターやデベロッパーが作成しても構いませんが、最終的な責任はプロダクトオーナーが負うため、率先して作成することが求められます。

　プロダクトに対する熱意を最も強く持っているのはプロダクトオーナーです。そのため、開発する機能や能力、価値を最もよく理解しているのはプロダクトオーナーであり、バックログを最も正確に作成できるのもプロダクトオーナーです。

3.　バックログの優先順位を決める

バックログが作成されたら、次にプロダクトオーナーが優先順位を決定します。この作業はスクラムマスターやデベロッパーが行うことはできず、プロダクトオーナーのみが行えます。

　優先順位は、MVP（Minimum Viable Product：実用最小限の製品）の考え方を用いて決定します。最低限リリースに必要な機能や要素を考えることで、自然と優先順位が決まるでしょう。また、市場のニーズや状況に応じて優先順位は変わるため、適宜アップデートすることが重要です。バックログ同様、一度決めたら終わりということはありません。

4.　リリーススケジュールを決める

　バックログの優先順位が決定したら、リリーススケジュールを決めます。スクラムチームはスプリントごとに開発物をリリースしますが、市場や顧客へのリリース時期はプロダクトオーナーの判断に委ねられます。

　また、リリーススケジュールをチームに共有することで、メンバーの意識がリリースに向かうため、スケジュール共有も欠かせません。

5.　スクラムチームへの社内外からの妨害を防ぐ

　仕事をしていると、雑務や相談などでスクラムチームが妨害されることがあります。プロダクトオーナー（またはスクラムマスター）は、プロダクト開発を最優先するため、社内外からの妨害を防ぐ必要があります。

　スクラム開発では、それぞれのロール（役割）に基づいて仕事が割り振られています。そのため、他の仕事に時間を割くことは、スクラム開発の失敗に直結します。場合によっては、デベロッパーへの連絡手段をすべてシャットダウンし、プロダクトオーナーがすべての窓口になるといった強硬手段も必要かもしれません。

　これは、プロダクトオーナーがプロダクトビジョンに基づきリリースに責任を持ち、デベロッパーがプロダクトを開発する責任を負っているためです。開発チームが妨害を受けないようにすることが、プロダクトオーナーの重要な役割です。

6.　ステークホルダーとスクラムチーム両方と接する

　スクラム開発の基本方針では、プロダクトオーナーはステークホルダーとスクラムチームにそれぞれ50％ずつの時間を割くべきとされています。

　これは、プロダクトオーナーがステークホルダーとコミュニケーションを取りながらプロダクトを最善に導く責任がある一方で、スクラムチームに対しては現在作るべきものや優先すべきことを明確に伝える必要があるからです。

　もちろん、ステークホルダーの人数やスクラムチームの自立度に応じて、この比率を柔軟に変えることも必要ですが、常に両者との適切なコミュニケーションができる体制を整えましょう。

7.　開発物をレビューする

　プロダクトオーナーは、開発されたものがイメージ通りかどうかを判断しなければなりません。イメージと異なる場合は、修正を依頼することも必要です。

　また、開発物は実際に動くものでレビューするべきです。パワーポイントで作られた模造品や口頭説明を受け入れてはいけません。常に目に見える形で、プロダクトオーナーが「OK」か「やり直し」かを判断する必要があります。

8.　マーケットを理解する

　最後に、プロダクトオーナーはマーケット（市場）を理解する必要があります。革新的と思われるプロダクトでも、多くの場合、他社製品と似ている部分があるものです。チームが開発しようとしているものについて、他社がどのような取り組みをしているかを理解し、プロダクトの価値を向上させる必要があります。

　また、ペルソナと合致するユーザーにヒアリングを行うことも有効です。プロダクトの価値を高めるためには、ユーザーのニーズを明確にし、市場で受け入れられるかを検討することが重要です。

プロダクトオーナーの考え方

　これまで、プロダクトオーナーの役割として8つのポイントを紹介しましたが、プロダクトオーナーの仕事は非常に大変です。ビジョンを明確に伝える能力、決断力、判断力、分析力など、さまざまな能力が求められる役割です。

　日本の一般的なSIerのようにプログラマーからシステムエンジニア、プロジェクトマネージャーへと単にステップアップする役割ではなく、明確なビジョンを持ち、人を動かす能力を備えている人物がプロダクトオーナーになるべきです。（※スクラム開発に序列はありません。単なるロールです。）

　常にプロダクトオーナーはプロダクトを、どのようにすれば価値を高められるかを考える必要があるため、単にエンジニア能力が高いことや、管理能力が高いというのではなく、開発しようとしているプロダクトに対して強い気持ちがある方がなるのが良いと私自身は思います。

　また、スクラムチームを先導する役割として失敗しないために、下記のアンチパターンなども参考にしてみてください。

スクラム開発の半数が失敗？　失敗させるプロセスアンチパターン１０選

アジャイル開発手法の１つであるスクラム開発では、ソフトウェア開発を柔軟に正確に進めることを可能にします。一方間違った方法で行っていれば、上手く行きません。そんな失敗するパターンを10選まとめました。

techgrowup.net

まとめ

　プロダクトオーナーは大変な仕事ですが、ぜひこれらを参考にして頑張ってください！
もしスクラム開発をもっと学びたい方がいれば、下記のような書籍を読んでみてください。

開発プロジェクトのマネジメント

　ドラッカーのマネジメント論を開発に置き換えて見ると、プロジェクトをマネジメントをする上で最も大切な要素は次の3要素である。

Point

①　プロジェクトの使命
②　プロジェクトの生産性
③　プロジェクトの社会的責任

プロジェクトの使命

　ドラッカーはどんな組織(政府や組織、教育機関、企業)であっても使命が大切で、誰かのニーズを満たすために存在していると論じている。

　開発プロジェクトも同様で、使命なきプロジェクトを完遂することなど不可能であり、システムやサービスは誰かに利用してもらうために開発プロジェクトが存在すると考える。本来プロジェクトでは特定の個人が、一時的な期間を伴った共通の目的のために存在しているものであり、ゴールに到達すれば解散するというのがプロジェクトの本質である。

　皆さんも、「このプロジェクトは何のためにやっているのだろうか」と思ったことはないだろうか。これはプロジェクトが存在する意味（使命）が伝達されていないか、そもそも明確に決められていないことが多く、このようなプロジェクトは大抵炎上している。少なくともプロジェクトをマネジメントする場合には、ドラッカーが掲げる5つの質問に答えられないのであれば、プロジェクトとして成り立っていないので、見直す必要があるだろう。

Check

①　われわれのミッションは何か？
②　われわれの顧客（ユーザー）は誰か？
③　顧客（ユーザー）にとっての価値は何か？
④　われわれにとっての成果は何か？
⑤　われわれの計画は何か？

　ここで注意しておきたいと思うのが、「④　われわれにとっての成果は何か？」である。短期的に見ればシステムを納品することが成果になってしまうが、そうなってはいけないと考えている。他の問にもあるように、開発プロジェクトの目的は常に顧客（ユーザー）目線で、価値を提供することにあり、開発することが目的になってしまうことは避けたいところである。

プロジェクトの生産性

知的労働社会

　現代では1900年代の大量生産社会と違って、大量に同じものを作っても売れない。既に世の中にモノは溢れかえっている。そして2000年代には知的労働社会になり、単純に作って売るというビジネスモデルから、労働者の知識を活用して各企業独自の製品やサービスを作っていくことが必要である。

　最近ではアウトソーシングや副業なども流行ってきており、ますます個々人が持つ専門性に焦点が当てられている。また、大量生産社会では企業が生産設備を持ち、労働者はそれを利用することでモノを作っていたが、現代では専門性を持つ労働者達そのものが生産設備を所有していることと同等になっている。そのため、専門性を持つ方たちは生産設備を「移動」することが簡単になっている。

　このような時代に大事になってくるのは、専門性を持つ人達を如何にマネジメントして生産性をあげていくかということになる。ドラッカーは生産性向上のための条件を6つ定義している。

Point

①　仕事の目的を考える
②　自らがマネジメントを行う
③　継続してイノベーションを行う
④　自ら継続して学び、人に教える
⑤　量より質だと知る
⑥　組織にとっての資本財

　

変化をマネジメントする

　知的労働社会では知識が生産設備となるため、常に知識をアップデート（変化）させていくことが必要になる。これは個人の労働者だけでなく企業も同様。ドラッカーが推奨している方法として、「体系的破棄」というものが存在する。

　これは、全ての仕事や作業を実行していないと考え、その上で今からでも実行するかと問い、「ノー」ならば破棄するという考え方である。プロジェクトを始めると報告のための資料作りや、大した意味もない進捗会議などあるのではないだろうか。プロジェクト開始直後であれば必要であったものでも、必要がないものはどんどん破棄していくことが必要だ。

　この考え方と似ている開発手法としてアジャイル開発/スクラム開発というものがある。アジャイル開発は簡単に言えば必要な要件を優先度を上げて開発し、常にリリース可能なシステムを開発していくことである。スクラム開発はアジャイル開発手法の一つであり、決定しない要件に対して柔軟に変更を加えていくことで、よりユーザーのニーズに合った開発をしていくことが可能になる。詳しい説明は下記を参照してください。

最近注目のスクラムによるアジャイル開発とは？メリットは何？

スクラム開発はユーザーのニーズが目まぐるしく変わる現代では、アジャイル開発とセットで用いられることが多い開発手法です。スクラムを導入することで強固で柔軟なチームを作り上げることが可能です。

techgrowup.net

強みにフォーカスする

　プロジェクトを複数メンバーで行っていれば、各個人によって「強み」「弱み」が出てくるだろう。ただ、この時に「弱み」に着目して克服しようとしないことが知的労働者会では重要になってくる。日本の教育制度だと受験などもあってか、弱い教科を重点的に克服することを求められるため、弱みを克服させようとする会社は多い。

　一方ビジネスでは、より専門性を持ったビジネスモデルや企業が勝つことは明確になっている。アップルでは従来コンピュータのハードウェアを製造していたが、中国などが台頭してきてからは撤退をしている。アップルでは製造は弱みだったからだ。

　開発プロジェクトでも同じで、各エンジニアに弱みを克服させようと無理に強いることは辞めておきたい。例えば、開発・実装が得意で管理が苦手なメンバーに、管理業務を割り当てることは必要ない。それならば管理が得意なメンバーに任せれば良い。ただ、1点注意しておきたいのは、その「弱み」によって「強み」が阻害されている場合は、早急に克服させるべきだろう。

プロジェクトの社会的責任

　ドラッカーは企業が果たすべき最も重要な社会的責任とは、特定の社会目的の達成、つまりは使命の遂行と論じている。これをプロジェクトに置き換えて考えてみると、少し大袈裟な感じもするが、プロジェクトにも必ず使命が存在し、その使命が社会的責任に繋がっていることは間違いない。

　現在日本では老年人口（65歳以上）が増え、生産年齢人口（15〜64歳）が減り続けている。2065年には生産年齢人口は現在の60%程度から50%程度まで減少し、人口全体では9000万人近くまで減少すると見られている。

　こうした中で1プロジェクトが社会的責任を負うというのは中々考えづらいところではあるが、製品やサービスを開発することで顧客（ユーザー）を想像し、ひいては経済的発展につながるということを考えれば、製品を生み出すことへの責任と、将来に対する責任を持つと言えるだろう。

　前者については言わずもがなで、新製品を作り経済を回していくことで社会に対して何らかの貢献ができることはイメージできる。後者については、例えば選挙における投票システムを開発したとしよう。日本が抱える人口減少による生産労働人口の減少を考えれば、現在のような投票所を運営していくことは到底困難になるとともに、投票システムが存在することで将来の労働者は、より専門的な仕事を行うことが出来る。こういった側面を考慮すると、将来の社会問題に対しての社会的責任を負っていると考えられる。

顧客（ユーザー）とは誰か？

　何度か顧客（ユーザー）という言葉が出てきているが、これをもう少し深堀りしてみよう。顧客にはシステム・サービスと直接している想像しやすい顧客と、潜在的な顧客がいると考えられる。ベンダー企業であれば目の前にいるクライアントが顧客になるだろう。ユーザー企業であればシステム・サービスを利用してもらうインターネットを介したユーザーかもしれない。

　しかし、実際には想像しやすい顧客（ユーザー）だけでなく、潜在的にいる顧客（ユーザー）を見落としてはいけない。例えば分かりやすい例で言うと、認証システムを伴った経理システムがあるとする。経理システムそのものは依頼元のクライアントが利用するためのシステムなので顧客（ユーザー）はクライアントになるだろう。

　一方認証システムのみが欲しい潜在的な顧客も存在するかもしれないという前提に立てば、認証基盤はベンダー企業で所有し、その上に経理システムをサービスとして乗せることで、潜在的に認証システムのみを利用したい顧客に別サービスをコストを下げて再開発することができる。いわゆるシステムの再利用性と言われるものだ。エンジニアだとライブラリなどがそれに値するだろう。こうした顧客を見落とさず、我々の顧客は誰になるのかということを本質的に考える必要がある。

まとめ

　今回は、ドラッカーのマネジメント入門を軸に、経営・企業マネジメントを流用して開発プロジェクトに応用できないかと考察してみました。少々強引な部分はあると思いますが、現代では開発プロジェクトそのものがビジネスになり得るケースが大半を占めており、活かせる部分は大いにあると思います。

　特に、プロジェクトの使命を考えることは最も大事なことがだと考え、企業が存在する意義からブレークダウンし、「なぜこの開発プロジェクトが必要なのか」ということを明確にした上で、プロジェクトを始めることが成功に繋がる大きな要因であることは間違いないと思う。

　一方実際に開発を行っていく上では、使命があるだけでは不十分で、アジャイル開発/スクラム開発のような具体的な手法を活かしていくことも必要だと考えます。下記にスクラム開発においてのアンチパターンを書いていますので、開発を行っている方はぜひ見ていただきたいと思います。

スクラム開発の半数が失敗？　失敗させるプロセスアンチパターン１０選

アジャイル開発手法の１つであるスクラム開発では、ソフトウェア開発を柔軟に正確に進めることを可能にします。一方間違った方法で行っていれば、上手く行きません。そんな失敗するパターンを10選まとめました。

techgrowup.net

　最後に、オススメのドラッカー書を紹介して終わりたいと思います。

]]> https://techgrowup.net/drucker-management-develop/feed/ 0 https://techgrowup.net/scrum-anti-pattern/ https://techgrowup.net/scrum-anti-pattern/?noamp=mobile#respond Fri, 04 Jun 2021 17:32:08 +0000 https://techgrowup.net/?p=1306

スクラム開発での失敗について

　今やスクラム開発の導入率は20%も越えようとしている現代ですが、一方そのうち半数は失敗してしまっているというデータもあります。その多くでは一体どんな原因で失敗しているのでしょうか。

　ウォータフォール型のプロジェクトでは、要件追加や仕様の考慮漏れなど、手戻りが発生することで炎上するケースが多々見られますが、アジャイル開発では基本的に柔軟に対応できるよう設計された開発手法ですので、こういった理由は少ないと考えられます。

　一方、柔軟に対応できるからこそ、厳格なルールがあるのです。特にスクラム開発では守らなければいけないことを遵守しないと、チームが壊れてしまいます。今回はそんな事例を10選としてまとめてみました。

　スクラム開発について「役割」、「作成物」、「会議体」などがよく分かっていない方は、まずは下記記事をご覧ください。

最近注目のスクラムによるアジャイル開発とは？メリットは何？

スクラム開発はユーザーのニーズが目まぐるしく変わる現代では、アジャイル開発とセットで用いられることが多い開発手法です。スクラムを導入することで強固で柔軟なチームを作り上げることが可能です。

techgrowup.net

アンチパターン１０選

1.　ロールが決められていない/兼任

　スクラム開発では、「プロダクトオーナー」、「スクラムマスター」、「開発メンバー」と厳格に役割が決められています。プロダクトオーナーはプロダクトに対しての責任を、スクラムマスターはスクラムプロセスへの責任を、開発メンバーはプロダクトを開発することへの責任があります。

　スクラム開発を始めるにあたり、これらの役割を明確に決めていないとスクラム開発を上手に回すことは出来ません。また、「スクラムマスター兼開発メンバー」など人のリソースが少ないときには、しばしば兼任されるケースもありますが、絶対にしてはいけません。　

　開発に慣れたチームメンバーであれば大丈夫と思うことがあるかもしれませんが、ロールはあくまで責任領域が違うので責任範囲の矛盾してしまう部分が出てきます。兼任していると、どちらの役割の責任を全うすべきか暗黙的に優先順位が付けられてしまうので、結果的に良いプロダクトが作れなくなってしまいます。

2.　プロジェクトのゴールとミッションが明確でない

　プロジェクトを始める前にはゴールとミッションを必ず決めておきましょう。「ゴール」とはプロジェクトを進めるにあたって、最終的に目指すプロダクトや製品のことです。具体的なデザインなどを決める必要はありませんが、プロジェクトはどんな課題を解決するのか、どんなソフトウェアを作るのかをメンバー全員で共通の認識を持つ必要があります。

　「ミッション」とはゴールに進んでいくにあたって、課せられている大きな課題のことで、例えば「3ヶ月後に必ず納品をしなければならない」であったり、「Bバグは必ずあってはならない」などの大きな基準が当たります。

　プロジェクトを始めるということは、何かしらの目的があって始まります。ゴールやミッションが決められていないにも関わらずスクラム開発を始めることは絶対にやめましょう。出来ればインセプションデッキにようなものを作ることをオススメします。

3.　プロダクトバックログが作れていない/更新できていない

　プロダクトバックログはスクラム開発の中で根幹とも言えるものです。プロダクトバックログに従ってチームは実現すべき要求を進めていき、プロダクトバックログで現在の進捗が見えるのです。基本的にプロダクトオーナーが中心となってバックログを作成していきますが、プロダクトバックログが作れていない状態は避けるようにしましょう。

　プロダクトバックログは本来どのメンバーが作成しても構わないものなので、プロダクトオーナーが作成していなければスクラムマスターなどが作成をしたり、プロダクトオーナーに時間を取ってもらえるように調整をかけることが必要です。

　また、プロダクトバックログは1度作ったら終わりではありません。ステークホルダーの要求は常に変化し、市場もまた変化していきます。プロジェクトのゴールに進むに連れて、より透明度の高い要求が入ってくる場合もあります。こうした状況に対応できるように、常にプロダクトバックログを見直し、更新し続けていくことが必要です。

4.　見積もりに時間を掛けすぎている

　ウォータフォール型の開発の場合は、全ての要求仕様が完成した後で、設計・実装・テストなどの見積もりをします。しかしスクラム開発（アジャイル）の場合では、要求が固まっていないことがベースにあるので、正確な見積もりをすることは困難です。それにも関わらず見積もりをすることに大きな時間を使っているのであれば見直しましょう。

　スクラム開発では見積もりをする際に、ストーリーポイントという見積もりをすることが一般的です。人間は絶対性より相対性の方が物事の基準を決めやすいので、基準となる作業を決めたら、それより「難しそう」「同じぐらい」「簡単そう」など比較をしていくことで見積もりがしやすくなります。

　見積もりに時間が掛かっている場合は、その分作業時間を減らしているということになりますので、プランニングポーカーなどを利用して、時間を掛けないようにしましょう。

5.　レビュー時にデモを実施しない

　スクラム開発ではスプリントレビューと言われる会議が存在します。そのスプリント期間中に開発したものをプロダクトオーナーやステークホルダーに見てもらう時間です。この際に開発メンバーから資料でのレビューや口頭での説明をしてしまうことは絶対に辞めましょう。

　ソフトウェアとは本来目に見えないため、共通認識が難しくイメージしづらいものです。スクラム開発でも同様で、実際にどんなものが作られているのかを目で見ない限り、完成しているのかどうか、どんなものになっているのかが分かりません。開発が進んでいないと、資料での説明をしたくなるという気持ちは分かりますが、アジャイル開発では常に動くソフトウェアを作ることが定義されています。

　動作するものでレビューが出来ないのであれば、スプリント中に実施する開発作業を減らしたり、そもそもプロダクトバックログやスプリントバックログ、スプリント計画の進め方を見直し、スプリントレビューでは必ず動くものをレビューできるようにしましょう。

6.　自己組織化しようとしない

　スクラム開発では、スクラムチームが自己組織化され、機能横断的になることが求められています。機能横断的とは1人の開発メンバーが特定の領域だけの仕事だけでなく、他のメンバーが困っていれば助けられるような存在になるということです。複数のメンバーが複数の領域をカバーできることで、チームが自律的に助け合い相互作用を生むことが出来ます。

　良くある失敗として、「この人は設計が得意だから設計だけ」「この人はフロントエンドが得意だからフロントエンドの実装だけ」のように特定の領域を作業するようにチームが決めてしまうことです。もしかしたら偉い人が勝手に決めてしまう可能性もあるかもしれません。

　しかし、それではチームとして成長することは出来ません。スクラム開発は個人単位の成果を測るものではなく、チーム全体を強くしていくためのものですので、全員がT字型人材を目指せるよう進めていきましょう。

7.　開発者の中に専門家がいる

　これはスクラム開発を初めてやってみようというチームに良くある失敗です。チームの中に開発の専門家（エキスパート）がいる場合です。例えばECサイトを開発しようといった際に、チームの中にバックエンド、インフラのエキスパートが居て、他のメンバーがそれらの知見がない場合はどうでしょうか。

　この場合に起こり得ることとして、他のメンバーが専門家の人を頼りにしてしまうことが想像できると思います。チームとして専門家がいる場合、頼ってしまうというのは人間の普通の心情です。このような場合には専門家はスクラムチームからは外してしまい、アドバイザーとしてチーム外に居てもらうようにしましょう。

　システム開発では往々にして、炎上プロジェクトにスーパースターを投入して、沈下させるといった人海戦術がありますが、スクラム開発ではそもそもスーパースターをチームの中に入れることは結果的にチームの生産性を上げることに繋がりません。しかし専門家が居ないと進められないという場合もあるでしょう。

　特に大きなプロジェクトであればあるほど、専門家は必要になってきますので、専門家たちにいつでもアドバイスを受けられるような体制をスクラムチーム外で作っておくことがベストプラクティスです。

8.　タイムボックスを変更する

　スクラム開発ではタイムボックスを守ることは絶対です。スプリント期間の中で開発・テスト・レビューなどを必ず実行する必要があり、例えば、「後1日あればレビューが上手くいく」のような場合に、スプリントレビューを1日ずらすことを検討したくなるでしょう。

　しかしスクラム開発をする場合は、スプリント内のイベント（会議）の時間をずらすことはしてはいけません。スクラム開発でタイムボックスを利用する理由の大きな点としては、開発速度を図れるということです。スプリント期間内にレビューが上手くいかなかったのであれば、スプリント計画が失敗していたということになりますので、そのスプリント期間ではレビューは出来るところまで実施し、次のスプリント計画で綿密に見直しましょう。

　もちろんデイリースクラムの時間などは、チームメンバーの状況に合わせて1日の中の時間で、朝から夜に変更するのような柔軟性は必要ですので、大事なのは目的をしっかりと理解することです。

9.　ベロシティを無理に上げようとする

　スクラム開発をすることは開発速度をあげることに繋がるわけではありません。ベロシティとは開発速度のことで、作業をストーリーポイントで見積もれば、1スプリント中にどのくらいのストーリーポイントを消化できるか測ることができるようになります。これがベロシティです。

　納期やリリース日が迫ってくるとベロシティを上げたくなることもあるでしょう。「一時的に皆が残業をすれば」「一時的に人を増やせば」など解決しそうな案はたくさん出てきます。しかしこれらは応急処置に過ぎません。スクラムチームとは安定的にベロシティを維持・成長させていき、リリース日までのスケジュールを正確に見積もることが大切なのです。

　一時的に残業を増やせばベロシティは上がるかもしれませんが、それは本来のチームのベロシティではありませんので、そもそもベロシティを上げなければリリースが間に合わないという状態を作ってしまうことが間違いなのです。もちろん絶対に残業がいけないという意味ではありませんが、一度そういう状況を作ってしまったとしたら、次のスプリント計画やスケジュールを決める際には必ず見直しが必要です。

　また、一時的に人を増やしてもスクラムチームのベロシティは大抵あがりません。スクラムチームは今までやってきたメンバー同士の相互作用や経験があって初めてベロシティになるのです。単に人を増やしても逆にその人への教育コストなどが発生し、結果的にベロシティが下がることに繋がりますので、気をつけましょう。

10.　問題を早期に解決しようとしない

　どんな開発でも大きな問題から小さな問題まで発生します。大きな問題に対してはすぐに対処する気持ちになると思いますが、小さな問題を見過ごしてはいけません。小さな問題はいずれ大きな問題となり、プロジェクトの終盤になって炎上の原因となるのです。

　基本的にはスクラムマスターがリードしてチームの問題を解消していくことが求められますが、もしスクラムマスタがーが積極的に動いていないようであればチームメンバーから働きかけてみるものよいでしょう。また、問題を発見したら報告・共有し迅速に解決するチーム作りをしましょう。

まとめ

　スクラム開発はしっかり進めることができれば強力なチームになることは間違いないですが、失敗パターンで行っている場合はウォーターフォール型より上手くいかない場合が想定されますので、ぜひ気をつけてみましょう。

スクラム開発をもっと知りたい方は、下記のような本を読んでみてください！

]]> https://techgrowup.net/scrum-anti-pattern/feed/ 0