こんにちは、グループ経営ソリューション事業部の 米久 保です。 はじめに リファクタリングとは リファクタリングの定義 振る舞いのサイズ 振る舞いと自動テストとの対応 リファクタリングテクニック リファクタリングサイズ 技術的負債はどうして生まれるのか コードの守備範囲 変更への対応 技術的負債を返済する 早い返済が吉 新規開発時 変更時 開発チームの裁量で返済する 説得方法 大規模なリファクタリング まとめ 参考文献 はじめに 「 リファクタリング をする時間がない」「 リファクタリング の必要性を関係者に説得しなくてはならない」という悩みをよく聞きます。 リファクタリング という用語が広く普及した結果、意味の希薄化が発生し、元来の意味と異なる使われ方を目にすることもあります。また、似通った用語としてリアーキテクティングというものがあり、混同されがちです。 リファクタリング の課題と向き合い、それらを解消するための正しいアプローチを取れるようになるには、 リファクタリング に対する理解を深めることが重要です。本稿では、最初に リファクタリング の定義を確認します。そして リファクタリング を必要とする技術的負債がどのように生まれるのか、それを計画的に返済するにはどうすべきかについて述べます。 リファクタリング とは リファクタリング の定義 Martin Fowler 氏の有名な著書[1]では、 リファクタリング は以下のように定義されています。 リファクタリング （名詞）　外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。 リファクタリング する（動詞）　一連の リファクタリング を適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。 リファクタリング という用語のあいまいな使用については氏も以下のように述べています。 長年にわたって、業界では「 リファクタリング 」という用語を、コードをきれいにするあらゆる作業を指すものとしてあいまいに使ってきました。しかし、上記の定義では、コードをきれいにするための特定の手法であることを示しています。 リファクタリング は振る舞いを保ちつつ小さなステップを適用していくことであり、ステップを積み重ねていくことで大きな変化をもたらしていくものなのです。 Kent Beck 氏も最近の著書[2]で以下のように述べています。 「 リファクタリング 」という言葉は、機能開発の長い中断を指す言葉として使われ始めたときに致命傷を負った。「振る舞いを変更することなく」という条項さえもなきものにされ、「 リファクタリング 」は簡単にシステムを破壊できるようになった。 氏の言うように、 リファクタリング という言葉の不用意な使用が リファクタリング に対する共通認識を歪め、健全な リファクタリング 活動を阻害してしまうリスクとなり得ます。次項以降では解像度を上げて リファクタリング を捉え直したいと思います。 振る舞いのサイズ 外部から見た時の振る舞いを変えない ことは リファクタリング における必須要件です。注意すべきは、一口に振る舞いと言ってもそのサイズはまちまちであるということです。ソフトウェアは大小さまざまな構成要素から成り立ちます。設計の抽象度で捉えると、下図のように4つの抽象レベルに分けて考えることができます[3]。 アーキテクチャ 、あるいは アーキテクチャ を土台として実現されるソフトウェアは、求められる機能要求や品質特性を包括的に提供します。 モジュール は、 ユースケース やその一部を実現する振る舞いを提供します。ユーザー目線で何らかの意味をなす振る舞いだと言えるでしょう。 コンポーネント は、モジュールにおける部分的な振る舞いを提供します。税計算処理のように ドメイン 知識に対応する振る舞いもあれば、データの永続化のように技術的な振る舞いもあります。 クラス （ 関数型言語 であれば関数）が提供するのは最小単位の振る舞いです。 振る舞いと自動テストとの対応 外部から見た振る舞いを変えないという条件を満たす上で重要な役割を果たすのが自動化されたテストです。コードを直しても変わらずテストが通過（Pass）することで、振る舞いが壊れていないことを確認し、安心して リファクタリング を行うことが可能となります。 さて、振る舞いにサイズがあるように、自動テストにもサイズがあります。どのサイズのテストをどの程度行うべきかの方針立てを テスト戦略 と呼びますが、テストピラミッドはその代表的なパターンです。よりサイズが小さく、実行コストの低いテストの比率を高くするという考え方です。 振る舞いを実現するソフトウェア構成要素と、テストピラミッドの対応付けを次の図に表します。 テストピラミッドはテストタイプ（ ユニットテスト ／インテグレーションテスト／E2E）を用いて表現することもありますが、ここではテストサイズ[4]を用いて表現しました。モジュールに対するテストは、データベース等のプロセス外通信を実際に行うか、テストダブルで代替するかによってSmallにもMediumにもなり得ます。 テストピラミッドをベースとしたテスト戦略を前提とすると、図の上位に行くほどテストによって固定できる振る舞いの量は少なくなります。Largeサイズのテスト（主にE2Eテスト）だけでは、ソフトウェア全体としての包括的な振る舞いに対して機能退行（ リグレッション ）を漏れなく検知することはできません。下位のテストによってより詳細な振る舞いが担保されることを前提とします。 アーキテクチャ /ソフトウェアの抽象レベルでは、定義どおりに リファクタリング を行うことは実質困難なので、リアーキテクティングという用語を用いるのが妥当でしょう。たとえば、モジュール境界の引き方や相互作用の見直し、一部モジュールのマイクロサービス化などがリアーキテクティングに該当します。 リファクタリング テクニック 本稿において、 リファクタリング とは設計の抽象レベルのうちクラス、 コンポーネント 、モジュールのレベルにおいて適用可能なものであると考えます。次に、 リファクタリング テクニックについて考えてみましょう。 書籍[1]には多くの リファクタリング テクニックがカタログ化されています。その多くは、「 関数の抽出 」、「 ループの分離 」のような単一クラス内またはメソッド内に閉じたものです。「 ポリモーフィズム による条件記述の置き換え 」、「 サブクラスによるタイプコードの置き換え 」のような複数のクラスにまたがるものも一部あります。前者のテクニックの中には、 IDE の機能を使ってワンクリックで実施できるものも多くあります。 書籍[5] では、 デザインパターン を適用してコードを改善する、パターン指向の リファクタリング テクニックが紹介されています。そのほとんどが コンポーネント レベルのものです。 モジュールレベルの リファクタリング については、私が知る範囲では体系立てられたテクニック集は見当たりません。この抽象レベルでは複数 コンポーネント の協調によって ユースケース 相当の振る舞いを実現しますが、パターン化できるテクニックが少ないからかもしれません。中核ロジックと処理フローロジックの分離[3]や、SOLIDなどの原則の適用によって設計を洗練させることは可能ですが、小さなテクニックの 機械的 適用を超えたより高度な知的作業が求められます。 なお「 リファクタリング したくてもそもそもテストコードが存在せず、テスト容易性も低い」レガシーコードにどう立ち向かえばよいかについては、書籍[6]が参考となるでしょう。 リファクタリング サイズ 以降の議論のため、 リファクタリング のサイズを下記表のとおり3つに分類します。 リファクタリング サイズ 設計の抽象レベル テストサイズ リファクタリング テクニック 所要時間 Small クラス S 小さなステップ 短い Medium コンポーネント S パターン指向 比較的短い Large モジュール S または M - 長い 技術的負債はどうして生まれるのか 仮に熟練した プログラマー がきれいなコードを書き上げたとしても、時間経過とともに内部品質が劣化することは不可避です。なぜでしょうか。 コードの守備範囲 最初に完成したコードは、その時点で判明している振る舞いに適合した設計となっています。その振る舞いの中にある類の可変性が存在するなら、その軸において柔軟性を持っているはずです。たとえば、「サブクラスによるタイプコードの置き換え」の リファクタリング を適用していれば、サブクラスや Enum 列挙子によって新たな振る舞いを追加可能となっているでしょう。SOLID原則のひとつであるOCP（オープン・クローズドの原則）による拡張性です。 このように、コードには変更に対して コスパ よく柔軟に対応可能な範囲、いわば 守備範囲 があります。 変更への対応 守備範囲内の変更であれば、変更を実現するにあたって リファクタリング は不要か、最小限で済ませることができます。問題は、守備範囲外の変更が発生したときです。 その場合、既存の設計はその変更に対する柔軟性を持ち合わせていないので、取りうる選択肢は以下の2つです。 リファクタリング により柔軟性を持たせた上で変更を行う その場しのぎのパッチワーク的な対応を行う プログラマー 倫理に従えば前者の一択なのですが、実際には トレードオフ が発生し判断を求められます。守備範囲外ということは、既存の設計では想定できていなかった類の変更だということなので、 リファクタリング には一定のコストが生じます。それに変更そのもののコストを加えたトータルのコストが、 変更によって得られる便益の向上と比較して正当化できるか という話になるのです。 もちろん個々の変更案件毎ではなくプロダクトやサービス全体として中長期で費用対効果があるかという判断基準も大事です。しかし、その変更を素早くリリースすることがビジネス的に重要である場合に、以下のような判断は果たして間違っていると言えるでしょうか？ 「本来 リファクタリング をすべきですが、影響範囲を考えて今回はパッチワーク的な対応をしました」 「本来 リファクタリング をした方がよいと思いますが、影響範囲を考慮して今回はプルリクを承認します」 技術的負債を返済する ソフトウェア開発におけるあらゆる設計判断は、最終的にビジネス上の何らかの価値につながるべきです。そう考えるならば、一時的に技術的負債を許容することも判断としては正当化されます。重要なのは、 技術的負債の発生を認識することと、それを管理していくこと です。 早い返済が吉 パッチワーク的な対応を行うと、設計にほころびが生じます。このほころびは容易に積もり積もるだけでなく、やっかいなことに相互干渉する場合もあります。10回のパッチワーク的な対応を行ったら、技術的負債の量は10 ではなく50や100にもなり得るということです。技術的負債は 複利 であると考え、手遅れになる前に計画的な返済が必要です。 新規開発時 新しい機能を新規に開発する際は、可能な限りコードをきれいにし、技術的負債を生まないことが前提となります。新規開発時点で乱雑なコードが、その後きれいに リファクタリング される可能性は残念ながら非常に小さいです。 最も効果的な方法は テスト駆動開発 （TDD）のプ ラク ティスを採用し、Red - Green - Refactor のサイクルの中で高頻度に リファクタリング を実施することです。とは言え、TDDの習得に一定の修練が必要なのも事実です。最低限、プルリクを出す前には時間を取って リファクタリング しましょう。 変更時 変更に対応する際は、 リファクタリング の要否を検討し、 リファクタリング が必要な場合はそのコストを見積もります。コストが想定を上回る場合は、開発リーダーやプロダクトオーナーと相談しましょう。今すぐ リファクタリング を行うのか、それとも先送りにするかの意思決定が必要です。 先送りにする、すなわち技術的負債の発生を受け入れる判断をしたならば、その返済プランとして バックログ アイテムに リファクタリング のチケットを登録します。 リファクタリング チケットの解消方針はいくつか考えられます。チームとして戦略を定めて、継続的な負債返済を実現しましょう。 規模の大きい変更と併せて リファクタリング を実施する イテレーション の一定のポイントを リファクタリング に割り当てる リファクタリング を中心に行う イテレーション を設ける 開発チームの裁量で返済する リファクタリング に関して、プロダクトオーナーやビジネスサイドへの説得が必要、という課題を耳にします。 私は、サイズがSmallやMediumの リファクタリング は開発チームが自分たちの裁量で実施できるのが望ましいと考えています。そのためには、技術的負債の発生をなるべく小さく抑えつつ、定期的に解消していくプロセスや文化が欠かせません。 次の図は、 JVM などの処理系において GC （ ガベージコレクション ）によってメモリが自動解放されるイメージです。アプリケーションに割り当てるメモリが不足すると、参照が切れてゴミとなったオブジェクトが回収され、割り当て可能なメモリが増えます。いよいよメモリが足りなくなると、広範囲を対象としたフル GC が実行されます。フル GC は実行時間が長くなりアプリケーションへ与える影響も大きいため、なるべく回避したいものです。 リファクタリング による技術的負債の返済は、 GC による割当可能メモリの回収に似ています。長い時間を要し、その間開発を止めてしまうような大きな リファクタリング （Largeサイズ）やリアーキテクティングは、なるべく避けたいものです。そのためには、小さい リファクタリング （Smallサイズ、Mediumサイズ）を継続的に実施し、技術的負債を膨らませないことが大切です。 説得方法 とは言え、現時点ではそのような文化が醸成されておらず、 リファクタリング の必要性を認めてもらうために ステークホルダー の説得が必要な場合はどうしたらよいでしょうか？ まずはファクトを示す必要があるでしょう。たとえば変更リードタイム、リリース後の欠陥発生率などのメトリクスです。時間経過に伴う推移を示し、緊急かつ重要な課題であることを認識してもらうとよいでしょう。コストとリターンを明確にすることも効果的です[7]。 大規模な リファクタリング Largeサイズの リファクタリング や、リアーキテクティングが必要なときはいずれやってきます。これには相当のコストと期間を要するため、 ステークホルダー を巻き込んだ上でプロジェクトやタスクフォースとして取り組むべきです。プランニングや社内調整、コミュニケーション設計などが包括的にまとめられた書籍[8]は大いに参考となるでしょう。 まとめ 本稿では、 リファクタリング の定義を再確認した上で、 リファクタリング のサイズを3つに分類しました。「 リファクタリング が必要」と漠然と言うのではなく、どの粒度の リファクタリング を指しているのか解像度を上げてコミュニケーションを取ることが、開発業務の計画や進行において重要ではないかと思います。 後半では、技術的負債が生み出される仕組みや、負債に対する取り組み方について述べました。ソフトウェア開発の現実においては一 定量 の技術的負債は発生を回避できないという前提で、戦略的に立ち向かわなければなりません。 参考文献 [1] Martin Fowler 著、児玉公信・友野晶夫・平澤 章・梅澤真史 訳『 リファクタリング （第2版） 既存のコードを安全に改善する』 オーム社 （2019） [2] Kent Beck 著、吉羽 龍太郎・永瀬 美浦 ・細澤あゆみ 訳『Tidy First? 個人で実践する経験主義的ソフトウェア設計』 オライリー・ジャパン （2024） [3] 米久 保 剛 著『アーキテクトの教科書 価値を生むソフトウェアの アーキテクチャ 構築』 翔泳社 （2024） [4] Simon Stewart 氏による記事『 Test Sizes 』 Google Testing Blog（2010） [5] Joshua Kerievsky 著『Refactoring to Pattens』Addison-Wesley（2005） [6] マイケル・C・フェザーズ 著『レガシーコード改善ガイド 保守開発のための リファクタリング 』 翔泳社 （2009） [7] 松岡 幸一郎 氏による記事『 「リファクタリングの時間」を確保する技術 』株式会社ログラス テックブログ（2025） [8] Maude Lemaire 著『Refactoring at Scale: Regaining Control of Your Codebase』O'Reilly Media（2020） 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @tyonekubo 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは。 エンタープライズ 第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリや スマホ アプリの案件などを担当しています。あと、趣味でAIを勉強しています。 2025年1月の組織改編で部の名前がカッコよくなりました。戦略って言葉、好きです。 ITソリューション部(旧)より、戦略ソリューション部(新)のほうが頭良さそうですよね。 気のせいか、名刺もなんだかカッコよくなった気がします。 前置きはここまでにして、今日はFlutterFlowのAI機能の検証をします。 私は普段から軽いデモであればFlutterFlowを愛用しています。爆速で開発できて便利です。 そんな、ただでさえ便利なFlutterFlowになんとAI機能が追加されたので、その実力を試してみようと思います。 ※ 2024年10月のアップデート 追加された機能は以下の4つ。 New Page Creation： 自然言語 や ソースコード からページを生成できる機能 New Component Creation： 自然言語 や ソースコード から コンポーネント を生成できる機能 Sketch To Component：手書きやスクショから コンポーネント を自動生成できる機能 Page Autocomplete：部分的に構築されたページをAIが自動的に補間してくれる機能 さっそく試してみましょう。 1：New Page Creation(自然言語ver) 2：New Page Creation(ローコードver) 3：New Component Creation 4：Sketch To Component 5：Page Autocomplete さいごに 1：New Page Creation( 自然言語 ver) まずはスタンダードな使い方として、 自然言語 による画面生成を試してみます。 適当なプロンプトをChatGPT(4o)に作成してもらい、それを貼り付けます。 では、これらの文章をコピペしてFlutterFlowのNew Page Creationに貼り付けてみます。 PreviewPageを押下すると次の画面が表示されました。 要素としては足りていますが、レイアウトがイマイチだと感じます。 この結果をChatGPTに投げつけて、プロンプトを修正してみましょう。 修正されたプロンプトで再度生成を行ったら、こんな画面が出力されました。 まあ、ほぼ完璧といって良いんじゃないでしょうか。 色合いやフォントを調整すれば十分に使える品質だと思います。 作成された各 コンポーネント は、いつも通りレフトバーから操作することが可能です。 白紙から作成するよりよっぽど効率的ですね。素晴らしい。 2：New Page Creation(ローコードver) New Page CreationはFlutterの ソースコード から作成することもできます。 いや、Flutterの ソースコード があるならそれでええやん！というツッコミは無視します。 というか、FlutterFlowの醍醐味は GUI によるUI/UX設計&ノーコード開発です。論点が違います。 仕上げをFlutterFlowに任せたい という思いが強いです。なるべくコーディングはしたくないのです。 とはいえ、 ソースコード が手元にないと話になりません。v0を使いましょう。 v0については本記事では解説しませんが、 自然言語 でコーディングおよびUIのプレビューまでできちゃう優れものです。 v0に貼り付けましょう。 プレビューは良さそうですね。ただ、Flutterで書いてほしいという命令を忘れていました。Flutter FlowのAIToolsはFlutterで渡した方が精度が高いです。修正してもらいます。 . dart での リファクタリング が始まりました。少し待ちましょう。 こういったダイナミックな変更にも素直に対応してくれるのがAIの良いところです。 もし、これが仕事で相手が人間なら、変更依頼と信頼関係を天秤にかけなければなりません。 複数ファイルに分かれているので、フォルダ構成を伝えつつ、 ソースコード をコピペしてみます。 生成が完了しました。 先ほどのv0のプレビューとソックリ ですね。 テキスト送信のブロックが下に張り付いていないのが惜しいです。 仮ですが、containerをstackでwrapして画面下部に引っ張ってきました。 こうやって手軽に調整が効くのが良いですよね。FlutterFlowを使う意味があります。 3：New Component Creation 先ほどのチャット画面に画像投稿用の コンポーネント を作成することを目指しましょう。 進め方は先ほどと同じように、プロンプトをChatGPTに考えていただき、FlutterFlowに貼り付けます。 長くなるのでChatGPTとのやり取りは省略します。 で、自動生成された コンポーネント がコレです。良いですね。 プレビュー領域もあって使いやすそうです。 4：Sketch To Component この機能を使うには 手書きのイメージが必要 になります。 電通 総研の画伯として一筆描くとしましょう。 うおぉぉぉおぉぉぉぉ！！！ ｻｻｻｻｻｯ..ｻｻ..!!シュッ！！ ｶﾘｶﾘｶﾘ...ツー...ﾄﾝﾄﾝｯ！ 描けました。なかなかの出来栄えです。 この画像から コンポーネント を作成してみましょう。 完璧すぎて草。 用途としては、会議室のホワイトボードに殴り書きしたイメージを具現化するなどでしょうか。 5：Page Autocomplete さて、最後です。作りかけの画面に 自然言語 で修正を加えられる機能です。 先ほどのチャット画面を作りかけとして定義し、作りこみをしてみます。 チャット送信で添付ファイルを追加できるようにしてみましょう。 Page Autocompleteを押下すると、 現在の画面構成を 自然言語 (英語)に起こしたもの が表示されます。 その内容をChatGPTに伝えて、修正命令を考えてもらいます。 ChatGPTが考えた修正命令を張り付けて、Page Autocompleteを開始しました。 ファイル添付のアイコンが追加されました。 これは修正の提案であり、その内容をどれくらい受け入れるのか を選択できます。(Less←→More) 今回はMoreに振り切って受け入れてみます。 反映後の画面がこちらです。 ファイル添付が出来そうなUIに修正されていることが分かります。 このように、修正箇所を細かく指示しながら、少しずつ画面を作りこんでいくことができます。 さいごに さて、今回はFlutterFlowのAI機能について記事を書きました。 *1 個人的な感想を言うとイマイチな性能でした。全体的にpaddingに気を遣えていないのが残念。 これは私の命令の内容が悪かったのか、AI側の性能が悪かったのか。 時間があるときにもっと検証してみようと思います。 これからも AWS やAI関連の検証記事をたくさん書いていきます。 ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ 第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ） *1 : ※本記事に使用されている画像は、AI画像生成ツール「DALL·E」を使用して作成されています

こんにちは。クロス イノベーション 本部 AI トランスフォーメーションセンター 所属の村本です。 私は普段、 Know Narratorシリーズ の開発や、生成AI関連の技術検証などに取り組んでいます。 今回は、タイトルの通り私の作業環境について紹介します。 私は業務のほとんどを在宅で行っており、作業環境がほぼそのまま生活空間にもなっています。そのため、快適に仕事ができる（暮らせる）ような環境にしているので、作業環境について悩んでいる方の参考になればと思います！ 仕事も生活もしやすい環境を目指して アイランド型のデスク配置で壁を背中に デスクになるべくモノを置かない 昇降デスクでときどき立つように モニターはType-C接続できる27インチを2枚（メインの4Kモニターとゲーム対応のWQHD 180hzモニター） ガジェット類の簡単な紹介 作業環境にこだわった結果 まとめ 仕事も生活もしやすい環境を目指して 作業環境、デスク周りがほぼ生活空間であると書きましたが、実際には以下のような目的で利用しています。 仕事 食事 映画などの動画鑑賞 ゲーム 家にいる間は基本デスクにいると言っても過言ではないですね... アイランド型のデスク配置で壁を背中に 早速ですが、作業環境の実際の写真を。（いろいろと趣味要素が写っているのは無視してください） 最大の特徴はアイランド型のデスク配置をして壁を背中側にしていることだと思います。以前は壁にデスクをつけていましたが、モニターの後ろがすぐ壁になっているためか、少し圧迫感を感じていました。この圧迫感を回避するために、アイランド型のデスク配置を採用したのです。 結果的にこの配置は大成功で、圧迫感を感じなくなりました。1日の大半を過ごすのに圧迫感を感じるかどうかは大きな違いだと思います。 そして、 圧迫感がなくなったことにより、作業効率が上がったような気がします。 ※検証はしていません。気分の問題です。気分が大事なのです。 また、壁を背にしたことによって、カメラを付けてオンライン会議を行う際に後ろを気にする必要がなくなりました。仮想背景は使っているのですが、物理的にも気にしなくてよくなったのは思わぬメリットです。 デメリットもあげておくと、「部屋のスペースを使うこと」、「ケーブルが目立ちやすいこと」の大きく2つだと思います。 1点目に関しては、私の場合、家にいるときは基本的にデスクにいるか寝ているかなので問題ありませんでした。たまーに筋トレをすることがあるのですが、そのスペース分は空いているので問題ありません。 2点目に関しては、ケー ブルトレ イや、配線カバーやケーブルを束ねるアイテムを利用して目立たないようにしています。上の全体写真でもほとんどケーブルが見えていないと思います。ケーブルがごちゃごちゃしているのは好きでないので、可能な限りまとめました。このあたりの整理グッズは比較的安い値段で調達可能なのでおすすめです。 ケーブル周りの様子 デスクになるべくモノを置かない 以前はデスクの上にもいろいろとモノを置いていましたが、今は極力モノを置かないようにしています。今使うものだけを置くということを心がけています。 モニター台を利用してモニター下の空間をできるだけ利用したり、デスク上用の棚を利用して本を置いたりしていましたが、これらも圧迫感につながる要因だったかなと思います。 利用頻度の低いものは周囲のラックに置くようにして、使うときだけ取りだすようにしました。こうすることで、デスクを広々使うことができますし、使わないものは空いているスペースに一時的に動かすことも簡単です。 普段の目線からの写真を載せようかと思ったのですが、部屋がしっかり写ってしまうので真上から撮影。 置いてあるものは、 ペン立て ミニトレイ（一時的に小物を置くところ） フェイクの草（プラスチック製） ディフューザー モニター キーボード マウス ノートPC（スタンドで立てている） です。 個人的なお気に入りは草ですね。緑があるだけで少し気分が明るくなる気がします。 ちなみにデスクは奥行き70cm、横幅140cmのものを利用しています。昔奥行きが60cmのものを利用していたのですが、微妙に狭く感じて70cmにしました。このサイズで現状不満はないです。 昇降デスクでときどき立つように デスクはFlexispotの「E7 pro」という電動昇降デスクを利用しています。ボタン1つで、デスクの高さを変えられる便利なアイテムです。電動昇降デスクは在宅ワーカーが1度は夢見るアイテムだと思っていて、社会人5年目のタイミングで思い切って購入しました。 定期的に立って仕事をしたり、会議の時に立った状態でオンライン会議に参加したりしています。立つことで気分転換になりますし、座りっぱなしは良くないですからね。 また、座っている状態でも、座り方や椅子の高さ次第でデスクの高さを変えることはあります。仕事の時はもちろん、ゲームの時や映画をゆっくり見たいとき、様々なシチュエーションに合わせて高さを変えられるのは魅力です。 ちなみに椅子は エルゴヒューマン の「 エルゴヒューマン プロ」を利用しています。最近「 エルゴヒューマン プロ2」が出ているので、これから買う人は2をお勧めします。 モニターはType-C接続できる27インチを2枚（メインの4Kモニターとゲーム対応のWQHD 180hzモニター） 作業環境で気になるポイントの1つがモニターの構成だと思います。私もいろいろな構成を試してきました。もともとは1つの大きなモニターで良い派だったのですが、現在は同じサイズのモニターを2枚使っています。理由は、コミュニケーションツール（Teamsなど）を開きっぱなしにしておきたいのと、オンライン会議時に共有している画面とそうでない画面を分けたい欲が出てきたからです。 基本的には、メインモニターの27インチ4Kのモニター上で作業しつつ、サブモニターのもう1枚でTeamsなどを開くようにしました。複数枚利用すると、どうしても首を振るので疲れてしまいます。その対策として、メインとサブの役割を明確にして、基本はメインしか見ないという形にしました。（写真でもメインモニターがキーボードの前にあるのが分かると思います） ちなみに、メインのモニターは4Kの拡大率125%で利用中です。チームメンバーには4Kモニターを拡大率100%で利用している人もいるようですが、さすがに小さくなりすぎるので自分には無理でした。また、モニターは2つともType-C接続で映像出力、給電可能なモデルなので、ノートPC周りのケーブルが少なく済んでいます。 2枚のモニターに対しType-Cで接続している様子 見出しに「ゲーム対応のWQHD 180hzモニター」と書いていますが、サブモニターはゲーム用としても利用しています。PS5やSwitchでしか利用していないので、180hzに対応していれば十分な性能かなと。 ガジェット類の簡単な紹介 エンジニアとして働いていますので、一応キーボードやマウスなども簡単に紹介しておきます。 キーボードはKeychronの「 Q1 Max QMK/VIA JIS（バナナ軸）」を使っております。持ち運び用にKeychron「K3 Pro QMK/VIA（バナナ軸）」を持っていますが、家では、Q1 Maxを使っています。エンジニアですが、US配列は使えません。US配列使っている人はデキるエンジニアのイメージがありますが、JIS配列でもやれるんだぞというところを見せたいと思います。 マウスは Logicool の「MX MASTER3s」を使っています。マウスといえば トラックボール タイプも良いと聞くのですが、現状こちらで満足しているので変える予定はないです。マウスも持ち運び用があり、同じく Logicool の「MX Anywhere 2S」を使っています。こちら7年くらい使って、落としまくってますが全く問題なく使えています。 上が自宅用セット、下が持ち運び用セット 作業環境にこだわった結果 このように作業環境にこだわった結果、ストレスの少ない快適な作業環境になっていると思います。いろいろ試行錯誤を重ねてきた中でかなり満足のいく環境です。 ただ、いくつかデメリットがあるので注意が必要です。 終わることのない、 PDCAサイクル にハマる 別の環境になると気分が下がる 1点目、どれだけ納得のいく作業環境になっても、時間がたつと気になることが出てきて改善したくなるんですよね。こんなところで PDCAサイクル は回したくないものです。 2点目、普段の環境を自分に最適化しすぎると、別の環境になった時に「あれもない」「これもない」と感じてしまいます。「弘法筆を選ばず」と言いますが、全く持って逆の状況です。「弘法でもないのに筆選びまくり」状態です。 とはいえ、デメリットを感じる時間は、メリットを感じる時間に比べはるかに少ないので問題ないかと思います。 まとめ 今回は、私の作業環境を紹介しました！ これからも作業環境の改善は続けると思いますが、作業環境をどう整えていくか悩んでいる方の参考になれば幸いです ご覧いただきありがとうございました！ 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社 電通総研 新卒採用サイト AI系プロジェクトマネージャー/リーダー AIサービス開発エンジニア 執筆： @naoki.muramoto 、レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

初めまして。 エンタープライズ 第一本部の佐藤悠です。 本記事では AWS Certified Solutions Architect - Professional(以下:SAPro)をほとんど業務経験のない新人の私が、勉強のみで取得した 経験談 を紹介します。 想定読者は AWS Certified Solutions Architect - Associate(以下:SAA)を取得済みの方です。未経験の場合はSAAからの取得をお勧めします。 目次 著者背景 SAProとは 取得理由 学習方法 試験概要 学習教材 CloudLicense Udemy AWS Certified Solutions Architect Professional Practice Exam 方法 テスト当日 まとめ 著者背景 大学や院ではほとんど情報をやっていない 基本情報取得（入社後） 新人1年目 インフラ業務にまつわる OJT 課題を1か月間実施 2週間で AWS Certified Cloud Practitioner（以下:CLF）を取得 1か月でSAAを取得 インフラの知識はなかったので、試験対策を行う中で学習をしました。CLFの試験勉強を始めた当初は IPアドレス のネットワーク部と ホスト部 の概念を知らないくらいのレベルです。 SAProとは AWS Certified Solutions Architect - Professional は、 AWS での クラウド アーキテクチャ の設計とデプロイにおいて2年以上の実践的な経験を持つ個人を対象とするものです。 対象となるレベルは以上のようになっており、業務経験がない人が学習を行うと分からないことの量、試験範囲の広さや問題のボリュームに挫折してしまうと思います。したがって、未経験者の方は50~100時間ほどコミットすることを覚悟して、学習する時間を確保する必要があります。ただ2年以上の実務経験は受験のための必須条件ではないので、未経験で取得出来たら2年分の 知識 を獲得できるチャンスでもあります。 複雑な問題に対する複雑なソリューションの提供、セキュリティ、コスト、パフォーマンスの最適化、および手動プロセスの自動化における高度な知識とスキルを証明するために役立ちます。 この資格を取得することによって得られる知識は以上のようになっています。問題も詳細は後述しますが、想定される課題に対して複数のサービスを組み合わせたシナリオにおいて、最も効率的なものを選択する形式であるため、用意された選択肢から選ぶということ以外は実践的であると感じています。 取得理由 SAProはSAAに比べてさらに具体的で実践的な ユースケース や課題に対処するような出題形式をとっていたので、試験対策を通じて課題解決のための手法を深く理解できるのではないかと考えたのがきっかけです。 また、新人で最上位資格を保持していることで AWS に関しては他の人と差別化できて自分がやりたいインフラの仕事に立候補できると考えました。これがあきらめかけた時の支えになっていました。 学習方法 試験概要 試験の概要は以下のとおりです。 SAAに比べて試験範囲がわずかに狭くなり頻出の分野が特定しやすいですが、その分問われる内容は深くなっており、要求される正答率も高くなるので試験の難易度は難しくなっていると感じました。 内容 複雑な組織への対応 ソリューション設計と継続的改善 移行とモダナイゼーションの加速 出題形式 選択肢から単一または複数選択をする形式 時間 180分 問題数 75問 合格点 75% 学習教材 以下の学習教材をお勧めします。 CloudLicense メリット 日本語に違和感がなく解説が詳しい 本番で出る内容が多かった デメリット 問題文をコピーできないので間違えた問題をまとめるには手打ちが必要 https://cloud-license.com/ F12キーを用いて問題文のテキストブロックをコピーできるので許容はできますが、やや手間でした。 Udemy AWS Certified Solutions Architect Professional Practice Exam メリット 本番でほぼ同じ内容が問われた コピー&ペーストが可能 デメリット 英語の問題文を google翻訳 にかけると意味不明な時がある https://www.udemy.com/course/aws-certified-solutions-architect-professional-aws-practice-exams こちらは変な翻訳を原文を見て補正する作業が出来れば問題の雰囲気が近いので良い教材だと思います。 方法 以下の試験問題のサンプルをもとに学習方法を解説します。 https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-pro/AWS-Certified-Solutions-Architect-Professional_Sample-Questions.pdf このような形式で問われるので「背景」「現状」「要求」に分離します。 この3要素に綺麗に分離できないこともありますが、ざっくりと切り分けることで問題文の見通しが良くなります。大体の場合は文末にある要求の部分に目を通してから、背景と現状を理解することで要求に対する課題がどの点にあるかを把握しやすくなるということです。 このサンプル問題を例に考えます。 要求は過剰な支出を防ぎ、各アカウントのコン トロール を維持するソリューションを提案することです。 背景は攻撃者による インスタンス の起動で請求が高額になったことです。 最後に、現状はセキュリティ侵害には対応したが過剰な支出を防ぐソリューションはないということがわかります。 この時の要求を満たすにはセキュリティ上の問題は考慮しなくていいということが分かり、この長い問題文でも読むべきは後半部分に限定できたので大分見通しが良くなりましたね！ そのあとで、選択肢を見ていきます。 この条件を満たす選択肢はCですが、私はそれ以外の選択肢が違う理由も解説できないと解けたことにしませんでした。 解説や公式ドキュメントを参考にしながら、問題がどの分野に属するものかとどのサービスに関連するものかを分類して以下のようにmdファイルでメモをまとめていきました。 VScode の環境下で見出しの 命名規則 を決めて静的解析の 拡張機能 を使用すると、同じ見出しがある際には警告が出るので情報を一つの場所にまとめることができます。 学習のコツとしてはドキュメントを写さないことです。分からないことを写すのは負荷が小さいので記憶に残りづらい気がします。なので、問題を解くためのドキュメントを読み込んだ後にノートをまとめる際には参考資料を見ないようにします。つまりインプットとアウトプットは分離するということです。 以上の方法で先述の問題集を解きます。この方法でやると時間がかかりますが質を高めれるため、200問前後で合格できると思います。私が実際に解いたのも210問でした。 テスト当日 テストセンタで受験しました。 試験時間は長いので事前にトイレに行くことをおすすめします。 問題を半分解いたら休憩してください。 せっかく受験するのですから、太刀打ちできない問題も選択肢から絞って回答できるようにしましょう。 この選択肢のパターンの場合はAとB、CとDとEに選択肢を分けることができ選択肢を2つ選ぶ際にはそれぞれ1つずつ選ぶ 傾向があります 。 またサンプル問題にはなかったのですが、以下のような選択肢の場合 A ) CloudFrontを使用して～ B ) CloudFrontを使用して～ C ) CloudFrontを使用して～ D ) S3で静的ウェブサイト ホスティング をして～ これはA～Cに正解があることが多いです。 結局、この傾向が分かるくらい問題解いていると普通に試験合格できるのですが、どうしても時間がなくて選択肢から逆算したいときに参考にしてください。 そして、あくまで傾向なので切羽詰まった際の参考程度でお願いします。 まとめ AWS 試験のなかで一番難しかったですが試験対策の過程で通常のハンズオンでは検証が難しい内容、例えばControl Towerなどの組織管理に関する部分をシナリオに基づいた課題を解決することで理解出来たので合格自体もそうですが、それまでのプロセスに意味があったなと感じる試験でした。 未経験だと厳しい道のりでつらいですが、合格はできるので同じ境遇の人は頑張ってください！ ここまで読んでいただきありがとうございます。 一人でも多く AWS の認定試験に興味を持ち合格していただけたら嬉しいです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

はいどーもー！ エンタープライズ 第一本部の宮澤響です！ （組織改編の影響で部署名が変わりました！） 本記事では、現役のIT企業社員（新卒5年目）という立場から、大学入学共通テスト（旧： 大学入試センター試験 ）に今年度から新たな出題科目として設定された「情報Ⅰ」の試験問題を解いてみた感想をお伝えします！ 問題・正解 感想 解答者として 大問1 大問2 大問3 大問4 IT企業社員として おわりに 問題・正解 本記事の対象は、令和7年度の本試験問題となります。 問題および正解は、以下に公開されています。 問題PDF （遷移先： 毎日新聞 デジタルWebサイト）※ 正解PDF （遷移先： 独立行政法人 大学入試センター Webサイト） ※公開され次第、 独立行政法人 大学入試センター Webサイトのものに更新予定です。 感想 （以下、当然ですが全て個人の感想です！） 解答者として 何よりもまずみなさまにこれだけは伝えたいという感想として、 「情報Ⅰ」で受験生に求められているものは、「情報学の知識」ではなく、「情報を読み取る／活用する能力」なのかな と感じました。 もちろん、後述の大問1 問1 aのように、情報学の知識を問う問題も含まれてはいるのですが、問題の大半は 「記載された文章や図表の内容を正確に理解し、そこから分かること／考えられることを解答する問題」 でした。 いわゆる「問題文の中に答えがある」タイプの問題です。 その意味では、情報学というよりは日本語と論理的思考力の問題といえるのかもしれません。 私自身、こうして実際に問題を解くまでは「プログラミングやネットワークのような情報学的な問題が多いのかな？」というイメージをもっていたため、そのイメージは見事に覆されました。 「 SNS をはじめとするインターネット上の情報に振り回されることなく、情報を正しく理解・活用してほしい」という 大学入試センター の思いが込められているのかもしれません。（？） ということを踏まえまして、以下、大問の一部を抜粋しての雑多な感想です。 大問1 記念すべき1問目、大問1 問1 a、いきなり「デジタル署名」なんて単語が飛び出してきました！ 問題を見る限り、少なくとも「デジタル署名を利用することで、情報の発信者が本人であるかと、情報が改ざんされていないかを確認できる」ということを、今どきの高校生は既に理解しているようです。 もうね、びっくりですよね！ 私が高校生の頃はデジタル署名なんて知りもしませんでしたし、たとえを耳にしたとしても「 ニンテンドーDS みたいにタッチペンで荷物受け取りのサインができるのかなぁ」くらいにしか考えなかったと思います。笑 大問2 大問2 B、「現金で6,000円ずつ集金する際のおつり」というテーマ設定が単純に面白いなと思いました。 確かに千円札で払う人も一万円札で払う人もいるよなぁと、ちょっとしたあるあるでした。 大問3 人日計算による 工数 計画のようなテーマ設定でした。 そのため、少し「 SIer っぽさ」も感じました。 また、この大問のみ唯一プログラムの話が登場しました。 とはいえ、特定の プログラミング言語 の知識がないと解けないような問題ではなく、ごくごく簡単な アルゴリズム の問題でした。 そのため、前提として必要な知識は「変数」「配列」「代入」という概念のみでした。 大問4 「尺度水準」なんて私は大学に入って初めて学んだのに…やっぱり今どきの高校生は凄い…。 IT企業社員として 数年後の新社会人は、程度の差こそあれ、全員がこのレベルの知識や思考力を有した状態で社会に出てくるわけです。 嬉しいような、ワクワクするような、恐ろしいような、不思議な感覚です。 もちろん、全社会人が共通テストを受験しているわけではありませんが、科目としての情報Ⅰが必修化していることも踏まえると、 情報リテラシー は確実に底上げされていると考えられます。 そのため、新入社員に「そんなことも知らないんですか？？？」と思われないよう、私自身も学びを継続していくことが大切だなと感じました。 また、私が興味をもっている人材開発的な観点から考えると、新人研修の内容にも影響があるのではないかと感じました。 これは、「現在のIT未経験者」と「数年後のIT未経験者」とでは、前提知識のレベルが大きく異なっている可能性が高いためです。 現在実施されている「現在のIT未経験者」向けの研修の中には、「数年後のIT未経験者」からすると、「そんなの全員高校でやってるし…」と思われる内容が含まれている可能性も否定できません。 そのため、近い将来、弊社に限らず、多くの企業（研修実施側、研修受講側、ともに）がIT系の研修プログラムを見直す必要に迫られるのではないかと感じました。 おわりに 本記事では、令和7年度大学入学共通テストの「情報Ⅰ」の本試験問題を解いてみた感想をお伝えしました。 少なくとも今年度の本試験問題では情報学の知識はそれほど要求されないため、IT業界のみなさまはもちろんですが、それ以外の業界のみなさまや学生のみなさまも、お時間のあるときに解いてみてはいかがでしょうか。 最後までお読みいただき、本当にありがとうございました！ 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @miyazawa.hibiki 、レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

初めまして。 エンタープライズ 第一本部の佐藤悠です。 本記事では Amazon Lightsailを用いて簡単に、 WordPress を用いたブログサーバーを立てる試みを記します。 目次 想定読者 Amazon Lightsailとは WordPressとは ハンズオン（実際にやってみる）でサーバー作成 IAMユーザについて Amazon Lightsailの起動 想定読者 読者想定としてはprogateでHTML/ CSS とか学習したけど、その後にウェブサイトを作るまで何をしたらいいか分からない、発信用のサーバーを作りたいと考えているだけで実行に移せない人向けです。 今回のサーバーを立てる場合には AWS アカウントの登録と、そのまま継続して環境を使用する際には毎月5ドル程度の出費が想定されます。ご了承ください。 Amazon Lightsailとは 以下公式サイトより https://aws.amazon.com/jp/lightsail/ Amazon Lightsail は、使いやすい仮想プライベートサーバー ( VPS ) インスタンス 、コンテナ、ストレージ、データベースなどを費用効果の高い月額料金で提供します。 これが基本的な内容説明になりますが、今回利用する特性は以下の部分。 数回クリックするだけで、ウェブサイトやアプリケーションを作成できます。ネットワーク、アクセス、および環境を自動的に設定します。 これが本当に数クリックで終わります。 サーバーを立てるところを飛ばして学習できるという良さを感じることができると思います。 WordPress とは 以下公式サイトより https://ja.wordpress.org/ クリエイターや中小企業から大企業にまで、世界中の何百万ものウェブサイトに選ばれている オープンソース のパブリッシングプラットフォームです。 多くの利用者が存在しており、コミュニティが発達しているのでわからないことがあった際にググればたいてい解決できる強みがあります。 ローコードで、ほとんどコードを書かなくてもいいのでブログくらいならあまり手間をかけずに作成できます。 当然HTMLも直接記述できるので、ローコードの仕様を理解するだけにとどまらないところが学習教材にあっていると思います。 以上の理由から、 Amazon Lightsailで立てたサーバーで WordPress を使用するのが楽にWebサイト作成に入門できると考えます。 ハンズオン（実際にやってみる）でサーバー作成 それでは、実際に手順を示しながらサーバーを作成します。 IAMユーザについて まずは AWS アカウントを作成してください。 https://aws.amazon.com/jp/register-flow/ 以上の手順を参考にアカウントを作成します。 ここで作成したルートアカウントに 不正アクセス されると AWS 上でできる全てを実行できてしまうので、以下のドキュメントを参考にMFA（多要素認証）をアカウントで有効にします。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root このルートアカウントは権限が強すぎるため、IAMユーザーを作成します。 IAMユーザーとは以下の図の通りで、現在作成したルートユーザーが権限の範囲を限定したユーザーを作成することが必要になります。 管理者が権限を限定したIAMユーザーを作成して、そのユーザーとして操作を行います。今回の場合は管理者もユーザーも自分になるのでこの意図が分かりづらいですが、意図しない操作を権限を弱めることで強制的に禁止し、安全にリソースを作成・使用するための措置です。 Amazon Lightsailの起動 AWS マネジメントコンソールの画面で、以下の画像のように検索窓でLightsailと検索し、表示されたアイコンを押下します。 次に以下の画面でCreate instanceを押下します。 遷移先ページで以下の表示があるので Linux 上で WordPress を動かすための写真のようなシンプルな構成を選択します。 次に ssh キーの生成を選択する部分があるので表示にしたがって実行します。 ssh キーのダウンロードが走りますが、このファイルの 削除 や 公開 をしないでください。 PC上の安全な場所で保存するようにしてください。 続いて以下のように インスタンス （使用するサーバー）選択をします。 正直一番小さいサイズの$5のものを選ぶのが経済的でいいと思います。 最後に インスタンス に名前を付けて作成を押下するとサーバーは完成です。 以上のような操作にてサーバー自体を作成することができました。 次回は完成したサーバーに HTTPS でアクセスできるようにする方法を解説し、実際にブログを作成できるようになるための具体的な操作を紹介します。 ご覧いただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

初めまして。 エンタープライズ 第一本部の佐藤悠です。 本記事では AWS Solution Architect Associate(以下:SAA)を受験料のみで取得した 経験談 を紹介します。 読者想定としてはCloud Practitionerを取得した後にSAAの取得を考えているかつ コスパ 良く学習したい人向けです。 目次 著者スペック 受験の理由 学習方法 学習教材（無料の教材を知りたい人向け） テスト当日 まとめ 著者の経歴 大学や院ではほとんど情報をやっていない 基本情報取得（入社後） 新人1年目 インフラ業務にまつわる OJT 課題を1か月間実施 Cloud Practitionerを取得 勉強は苦手 資格取得の勉強にかかる金額は安く済ませたい！ OJT 課題は、EC2/RDS インスタンス を作成しCloudWatchで監視して SNS で通知するというような環境をInfrastructure as a Code(以下:IaC)で作成した内容ですが、この経験で大きく合格に近づくかといったらそうでもないです。2~3日、初心者向けハンズオンで GUI を触るとすぐに相応の知識は取得できます。 どんなハンズオンかというと以下が良いと思います。 AWS ハンズオン チュートリアル Create and Connect to a Microsoft SQL Server Database with Amazon RDS https://aws.amazon.com/jp/getting-started/hands-on/create-microsoft-sql-db/?ref=gsrchandson&id=updated AWS 環境のセットアップ https://aws.amazon.com/jp/getting-started/guides/setup-environment/?ref=gsrchandson 当然 無料 です。 Cloud Practitionerは可能なら取得しておいてください。後述しますがSAAに対しては段階的なアプローチが必須だと思います。 IaC 余談ですがIaCはその可搬性や再現性に意味があり、コード一発で同質のインフラが構築できたり、修正もコードベースで管理しているので簡単にできたりなどの強みがあります。このロジックを理解することはインフラを理解するにあたって重要です。ただ、再三ですがこの内容はまれにCloudFormationの部分で似た概念が出題されるかも？のレベルなのでIaCに関する知識を深堀りすることが合格の要因にはならないです。 受験の理由 Cloud Practitionerは点的な知識の連続であり、相互の連携が要求されるインフラ業務にはもう一段踏み込んだ学習が必要だなと感じたためです。 特に AWS ではすべてをハンズオンでやっていると無料枠や、個人利用の規模感から逸脱してしまって大変なので試験対策を通じて体系的に理解したいと思いました。 合格後は自分が期待した通りの知識を獲得できていたので取得して正解でした。 あれ？案件のインフラ構成図が理解できる！！！（感動） 火垂るの墓 くらい泣けます。 学習方法 試験概要 内容 サービス間連携と以下を満たすソリューションの選択 コスト最適化 運用上の優秀性 セキュリティ 信頼性 出題形式 選択肢から単一または複数の選択をする形式 時間 130分 問題数 65問 合格点 7割 公式に従うと1年の実務期間が取得者の目安らしいです。 これを学習のみで詰め込むと最低50時間は絶対に確保する必要があります。試験のバージョンがC-03になってからはSAAの難しさが段違いで現在勉強中のSAProとの差が小さいように感じます。 先述したCloud Practitioner取得を勧めるのはこの理由からです。実務経験がない場合は、多分全てがわからない状態で始まるので、最低限の知識なしにいきなりこのレベルにあたるのはハードルが高いです。 学習教材（無料の教材を知りたい人向け） 以下のサイトがとても良いです。 ping -t AWS SAA 最強問題集 https://mondai.ping-t.com/g 無料の会員登録で勉強できるのですが、出題数を絞ったり進行度合いを表示してくれたりと、なんで無料なんだろうと思うくらいです。丁寧な解説も回答の途中で見られるので適当にチェックつけて正解したから、あとで見返せないという心配も必要ない。 これは最強の名にふさわしいです。 ありがとう...「 ping -t」...本当にそれ以外の言葉が見つからない。 こちらの「【試験レベル】Well-Architected Frameworkに基づいた設計」の部分を5問単位で切って解きなおしのスパンを短くすることでストレスなくできます。 私は間違いをメモに丁寧にまとめながら2周で合格しました。 テスト当日 テストセンタで受けました。自宅受験を考えている人はおすすめしません（1敗）。 試験時間は長いのでトイレに行くことと、問題を半分解いたら休憩することをお勧めします。 あと解答に自信がない場合はチェックマークを付けて最後に見直すと他の問題の文脈で語られていたサービスをヒントに解けることがあるので、やってみてください。 まとめ この試験は AWS サービス間の連携など、体系的で意味ある単位での学びになるいい機会だと思います。日常のアイディアが AWS のこのサービスで実現できそう！とかなんで動かないの？に対して予測をつけるのにかなり役立ちます。 試験取得後に自分が実感した変化は、困りごと解決の選択肢が浮かぶようになったことです。 例として、今持っているPCの GPU のスペックが足りないんだけど、これ クラウド 側で レンダリング できないかな？とか、EventBridgeがStepFunctionをキックしないのは権限許可あたりかな？など着想や思考の幅が広がりました。 AWS について詳しくなりたい人は是非、取得を検討してみてください！ 最後に ping -tは最強です。これは繰り返し言いたいです。 ここまで読んでいただきありがとうございます。 一人でも多く AWS に興味を持っていただけたら嬉しいです。 そして試験合格を祈ります。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは、株式会社 電通 総研の新卒2年目の宮崎 博寿 です。 クロス イノベーション 本部 クラウド イノベーション センターに所属しております。 24年の12月上旬に、世界最大規模の AWS カンファレンス 「 AWS re:Invent」 に参加しましたので、現地で体験した学びや感想、 GameDay の話を中心にレポートします。 re:Inventとは？ 一言でいうと、 AWS のすべてが詰まった祭典です。数多くのセッションやワークショップ、ゲーム化された学習イベント（GameDay）、IT各社主催のExpoなどが同時多発的に行われます。 現地の熱気や規模感は想像以上で、 AWS がどれだけ世界に インパク トを与えているかを肌で感じることができました。 概要 場所： アメリ カ・ ネバダ 州ラスベガス 期間：例年5日間（例年11月下旬〜12月上旬） 参加者数：世界中から6万人以上、日本からは2000人超と現地で聞きました。（ SIer や事業会社のIT部門の方など幅広い業界の方々） コンテンツ数：5日間で約3500以上（re:Invent公式サイトのカタログで確認） 参加した主なコンテンツ 1. 基調講演 AWS のCEOをはじめとした幹部陣が、最新サービスの発表や将来的なロードマップを紹介します。 講演前にはバンド演奏などのライブパフォーマンスが行われ、ラスベガスらしい華やかな雰囲気の中で開幕しました。 ※主な新機能についてはこちら ・ https://aws.amazon.com/jp/blogs/news/top-announcements-of-aws-reinvent-2024/ ・ https://www.youtube.com/live/XhUemgp7LHo 2. ブレイクアウト セッション 約1時間の講義形式で進行される専門セッションです。興味のある技術分野を深掘りできます。 こちらは AWS 公式 YouTube チャンネル（ AWS Events）に アーカイブ として公開されているためご興味のある方はご覧ください。 AWS Events公式チャネル 3. ワークショップ 2時間程度のハンズオン型セッションです。各自のPCで新機能やサービスを実際に触りながら学びます。 短時間で実践的に習得できるため、普段使わない技術に初めて挑戦する絶好の機会でした。 参加したワークショップの内容を1つピックアップして別の記事でご紹介します。 4. Certification Lounge AWS 認定資格 保有 者向けの専用ラウンジです。 無料の飲食や休憩スペースを利用できるので、会場を走り回る間の良いリフレッシュになりました。 ※右の方は他社の方で掲載の許可は得ています。 5. 5Kマ ラソン 朝早起きして、皆で5キロ走るというシンプルなコンテンツです。 朝食にスムー ジー や果物などの軽食が用意されており、充実した1日をスタートすることができました。 6. ネットワーキング（懇親会） 近畿日本ツーリスト （ AWS re:Inventのパッケージツアー主催会社）の前日懇親会 JapanNight（総勢200名以上が参加されていました） AWS パートナー限定ネットワーキング 普段そもそもリモートで多くの人になかなか出会えない中、多くの他社・他業種の方々との名刺交換、そこからの交流が生まれました。 特に、同世代との出会いは大きな刺激になり、今後のモチベーションにもなりました。 7. GameDay AWS サービスを組み合わせて技術的課題をチームでクリアしつつ、スコアを競うゲーム化された学習イベントです。 参加者同士が少人数のチームを組み、模索しながら実際の AWS サービスを用いてコミュニケーションを取りながら行うのが特徴です。 合計3つに参加し、現地で会った日本人の方や、外国の方に混ざってチームを組んで参加しました。 GameDayとは？ 公式引用 3〜4人のチームで与えられた課題をクリアし、スコアを競い合う 手探りで AWS リソースを使いこなしながら、実践的なスキルを身につけられる トラブルを解決するスピード感やチームメンバーとのコミュニケーションが重要になる 参加したGameDay2つ抜粋 実際に参加して感じたこと等 アプリケーションの監視・処理エラー対応、既存 インスタンス タイプからGravitonを使用したタイプへの移行、 アーキテクチャ 見直し等と、多種多様な課題が様々でてきました。 それぞれ得意分野が違うケースもあるため、担当を決めてスタート。後半になると協力しつつ取り組む等チームワークも必要な部分が楽しかったです。 今回現地のGameDayでは Amazon Qという生成AI機能が使用でき、質問するとヒントやエラーの解決手順を、コンソール上のリソースのパラメータを踏まえて提案してくれました。実践的な課題をこなしながら、最新機能にも触れられたのが面白かったです。 チームでスコアを競うため、ゲーム感覚で盛り上がります。学びつつ楽しめるのは魅力でした。 結果は？？ 日本人チームとしては、全体で40位台でした。中盤までいいペースだったのですが、後半にスコアが伸び悩み… とはいえ、学びが多くあり非常に充実した時間でした。 外国の方々ともチームを組ませていただいた際は約70チーム中19位とまずまずの結果を残すことができました。 私が1つの項目ををクリアしてcomplete！nice！！ぐらいの会話をしたことを覚えています（笑） AWS GameDayの魅力や学べること スキルの向上 一般的な認定試験や座学では得づらい AWS 上のリアルなトラブルに短時間で向き合うことができます。 自分で考える、時にはチームで協力しながら対応策を練ることで、問題の切り分けや クラウド における実践力が伸びると思います。 GameDayでは横で実際に課題に対処している姿を目にしつつ、時には助言をいただくことができ、特に若手にとっては目で見て学べるいい機会でもあると感じました。 モチベーション 自由度が高い分、なかなか課題が解決できず打ちひしがれる場面もあります。 それでも課題を解決する道筋を考え実際に点数が取れた時の達成感があり、今後もっと経験を積み頑張ろうと前向きになりました。 交流 re:Inventのような大型イベントでは、様々な参加者が集まるため、普段接点がない海外の方や他社のエンジニアと交流するきっかけが生まれます。 技術者同士の情報共有として「こんなトラブルがあった」というリアルな声を聞き合えるのも、GameDayの大きなメリットだと思います。 GameDayまとめ 一言で言えば、 AWS のゲーム化された実践ト レーニン グ です。 認定資格や座学の知識を超えて、実際の クラウド の課題を短時間で体験しながらスキルを養えます。 AWS re:Invent のGameDay に加えて、 AWS Summit等でも開催されることがあるので、特に若手エンジニアの皆さんはぜひ一緒に参加しましょう。 短い時間でも多くの学びと交流、そして新たなモチベーションが得られるはずです。 AWS に注力されている企業さんだと、会社内でチームを組んで出場するというケースもよくあるみたいです。 終わりに AWS re:Invent は、世界規模で AWS の最新情報や技術トレンドを発信する超大規模イベントです。現地に行くと想像を超えた情報量と熱気が待っていました。 新サービスや新機能の発表のみならず、GameDay をはじめとした実践的な学習イベントでの スキルアップ の場、5キロランやre:Playという最後の打ち上げパーティの開催等、一度に様々な体験ができる貴重な場でした。 今後 AWS をはじめとした クラウド 関連の技術を今以上に深めていきたい！といった大きなモチベーションになりました。 個人的には普段の業務での活用はもちろんですが、 Amazon Bedrockや Amazon Qの今後の活用が気になっており、自身で触れたり動向を追ったりしていければなと思っています。 もし AWS に興味を持たれた方は、まずは AWS 認定資格の取得や、毎年日本でも開催される AWS SummitやGameDayへの参加を検討してみてはいかがでしょうか。 AWS Summit2024 私たちは一緒に働いてくれる仲間を募集しています！ 株式会社 電通総研 新卒採用サイト 執筆： @miyazaki.hirotoshi 、レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

初めまして。 エンタープライズ 第一本部の1年目の新人、佐藤悠です。 本記事ではやりたいことがない新人やIT企業を志望する学生に向けた AWS 学習のすすめと資格取得の勉強法について紹介する。 目次 なぜAWSを勉強するのか AWSとは 個人レベルでの使用感 Cloud Practionerの取得方法 AWS Cloud Practitionerとは 受験の理由 著者スペック 学習方法 学習教材 テスト当日 まとめ なぜ AWS を勉強するのか ITサービスにはインフラが必ず存在し、インフラの需要はそれに伴って存在する。近年は クラウド 化の潮流もあり クラウド 技術を学ぶこと自体がインフラを理解することに近似してきている。 AWS は クラウド の市場シェアがもっとも高いためニーズある人材になるには AWS を理解することが最短である。やりたいことのない人は来たるときにそれを実現できる力をつけられるという意味でも AWS をやると良いと私は考える。 AWS とは Amazon Web Services の略。 クラウド サービスを提供しておりそのサービスは200種類を超え、多種多様なニーズにこたえることができる。 個人レベルでの使用感 発信する力もエンジニアの力といわれる昨今、私もブログを作成したいと思い、サーバーの立ち上げを試みたが一向にできない。しかし、すでにあるプラットフォームを利用するのはプライドが許さない。そんな時に AWS Lightsailである。様々なテンプレートの中から GUI の操作で好きなものを選び、ブログサーバーが5分でできた。最高である。 このように業務から個人的なものまで大小問わず、さまざまな環境をサクッと作れるのが実感できる良さである。 Cloud Practionerの取得方法 AWS Cloud Practitionerとは AWS の認定資格の1つ。入門資格に位置づけられるが AWS クラウド の基本やサービス、用語を網羅した全体観を知るにはピッタリの資格である。 受験の理由 冒頭に述べた通り。インフラの知識に実務経験があれば飯を食うのに困らなさそうだから。 著者スペック 学部は非情報系 大学院は情報系であるがAIが研究対象なのでインフラの知識はない 新人でインフラの業務は一切していない（取得当時） 基本情報は3か月かけて取得した 記憶力は弱い。インフラのイの字も知らなかった。 学習方法 試験概要 内容 AWS サービスの名称と内容 ベストプ ラク ティスの概念 出題形式 選択肢から1つ正解を選ぶ形式が多数 複数選択が一定数出題される 時間 90分 合格点 7割 一般的には取得のために50時間とするサイトが多いがいらない。 なぜならば選択式だから。 複数選択式は全体割合のうち少数なので、単一選択の4~5択のうち一つを選ぶなら20~25%の確率で正答できる。つまり確実に分かるレベルの知識は過去問に対して半分あればいいのだ。あと合格するかは 正規分布 に従うだろう。 実際に1日1時間を2週間の継続で想定される時間に対し、半分と少しの28時間で合格できた。 学習教材 Udemyで以下の問題集を解いた。 【CLF-C02版】この問題だけで合格可能！ AWS 認定 クラウド プ ラク ティショナー 模擬試験問題集（6回分390問） https://www.udemy.com/course/aws-4260 先述の通りこの問題を1周した後、これは確実に正解できると思える問題を50%に引き上げるだけ。2周で十分。 テスト当日 自宅で受験したがこれはおすすめしない。 不正防止のための部屋を整備するのに時間を要した。 ポスターをはがしたり、手の届く範囲にものが存在しない状態にしたりと大変である。 また、受験中に画角から外れることもできないので集中できなかった。 このような手間がかかるので、受験に集中するためにはテストセンターで受験した方がいい。 まとめ CloudPractitionerの受験にあたり効率を重視した手法を紹介したが、これはあくまで全体感をつかむためであり、ここで得た点的知識を 有機 的に紐づけるのは興味を持った分野を自分で触ってみることであったり、資格ベースで進めたい人は次のレベルの取得で検討できたりする。 何よりもやってみることが大事である。試験設計自体がそう言っていると思う。 次回はSolutions Architect Associate取得の勉強方法の記事を書く。 ご覧いただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

祝3周年 こんにちは。 X（クロス） イノベーション 本部プロダクト イノベーション センターの中村です。 本テックブログは12月をもって開設3周年を迎えました！ 私たちは、この3年間で毎週1本以上の記事を継続的に公開してきました。総数は390本を超え、単純計算で1週あたり2、3本の記事を公開したことになります。手前味噌ではありますが、3年間継続できていることを誇らしく思います。 この記事では、テックブログを継続するために「編集部」が取り組んでいる活動の一端を飾らずに紹介したいと思います。 本記事は、 電通総研 Advent Calendar 2024 の25日目の記事となります。 編集部とは？ テックブログ継続のための工夫 レビュープロセス トレンド入りやランキング入りの称賛 アドベントカレンダーの企画 まとめ 編集部とは？ 最初に「編集部」について説明します。テックブログの運営には旗振り役の組織が必須です。私たちはその組織を「編集部」と呼び、部門横断で参画希望者を募り現在14人で運営しています。 編集部の活動には、例えば次のようなものがあります。 ブログサービス利用料など各種運営に必要な予算の管理 採用や広報との連携 執筆者へのフィードバックとサポート 編集部の人員入れ替えを意図的に実施することで多くの方に編集部に関わってもらう工夫もしています。これにより、新しい視点やア イデア を取り入れ、継続的な改善の促進を狙っています。 テックブログ継続のための工夫 以下、テックブログを継続するために実施している3つの工夫を紹介します。 レビュープロセス 記事のレビューは編集部と広報担当部署が中心となって実施します。私たちはレビューに Shodo というツールを活用しレビュー効率を高めています。Shodoは誤字脱字や表記ゆれなどを自動検出してくれるため、レビュアーは本質的な部分に集中してレビューが可能です。基本的には執筆者の意思を尊重したいので、レビューアーは、「非開示情報が含まれていないことの確認」や「より多くの人に読まれるための助言」といったフィードバックを中心に行います。 また、あらかじめ「質より量」や「等身大の自分たちを表現する」といったポリシーを定めているため、記事の品質や技術的な優劣を問題にしてレビューが紛糾することはありません。 ツールの活用と事前に定めたポリシーの存在がレビューの負荷低減に繋がっています。レビューでレビューアーとレビューイーの双方が消耗しないことは重要なポイントだと考えています。 トレンド入りやランキング入りの称賛 執筆記事が はてなの企業技術ブログのトレンド や何らかのランキングに掲載された際は、執筆者コミュニティ内で共有と称賛を行っています。トレンド入りを目標にしているわけではないのですが、多くの方に注目されたということの証左の一つだと思いますので、素直に「素晴らしい！」という想いを皆で共有しています。 ささやかなものではありますが、称賛を表明する機会や場は、モチベーションの向上にポジティブな効果があると感じます。 アドベントカレンダー の企画 12月は毎回 アドベントカレンダー （25日まで毎日記事を公開する企画）を実施しています。今回を含めてこれまで4回実施していますが、いずれも執筆者募集から数日で応募枠が埋まるほどの人気ぶりです。 アドベントカレンダー は編集部からすると少し負荷が掛かる取り組みではありますが、年に1度くらいであれば日常のスパイスとなって皆で楽しめますし、テックブログ参加者の活気を維持するのに役立ちます。 多くの アドベントカレンダー では、12月1日から25日まで休みなく継続することが多いと思いますが、私たちは土日祝日を休むという選択をしています。休みの日に無理して執筆する・公開するほどまでに頑張らなくてもいいよね、というスタンスです。しっかり休むことで執筆者と編集部の負担を軽くしています。 多くの人が無理なく一緒に盛り上がれるようなイベントを定期的に行うことは、テックブログのような活動を続ける上で大切だと考えています。次のイベントに向かってまた頑張ろうという活力が生まれやすくなるからです。 アドベントカレンダー は来年も継続できればと考えています。 まとめ テックブログを継続するためには、いくつかの重要なポイントがあります。 まず、無理をしないこと。私たちは、執筆者が無理なく記事を書ける環境やポリシーを整えることを大切にしています。また、執筆者だけでなく編集部も無理なく運営に携われることを常に意識しています。 次に、執筆者へのフィードバックや称賛も重要です。公開前に適度なレビューを行うことで「この情報を公開して良いのだろうか？」といった不安は除去されますし、称賛により努力が認められればモチベーションの向上に繋がります。 さらに、 アドベントカレンダー のようなイベントを楽しむことも大事にしています。ちょっとしたことではありますが、皆でワイワイと記事が途切れないように協力するのは面白いだけでなく一体感を生む良い機会にもなります。 私たちは今後も週に1本以上の記事の公開を目標に活動を続けていきます。引き続き、本テックブログをよろしくお願いします！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @nakamura.toshihiro （ Shodo で執筆されました ）

皆さんMerry Christmas！コーポレート本部 サイバーセキュリティ推進部 セキュアシステムデザイングループの福山です。 本記事は、 電通総研 Advent Calendar 2024 の24日目の記事となります。 今回は、私の好きな AWS サービスの一つである Amazon Detectiveについてお届けしたいと思います。 はじめに Amazon Detectiveとは Detectiveを有効化してみよう！ 管理アカウントでの作業 メンバーアカウントでの作業 GuardDutyアラートの生成 Detective管理アカウントによる調査方法 検出結果グループ（finding groups） 調査機能（Detective Investigation） IAMユーザーを調査 ロールを調査 検索機能（search） アカウントIDで検索 インスタンスIDで検索 インスタンスに紐づくロールで検索 IPアドレスで検索 IAMユーザー名で検索 まとめ 最後にちょっとだけ補足 はじめに AWS 上で発生した セキュリティインシデント を調査する際、GuardDuty の検出結果、CloudTrailや VPC フローログ等を読み解く作業が発生します。 しかし、これらのログ調査には知見と労力が必要です。 そんな課題を解決し得るサービスが AWS には存在します。 Amazon Detectiveとは Amazon Detectiveは、 AWS 上で発生した セキュリティインシデント の調査を容易にするサービスです。 CloudTrail／ VPC フローログ／GuardDutyの検出結果などのログデータを自動で収集し、"動作グラフ"と呼ばれる各アカウントに紐づくデー タセット を生成し、 機械学習 ・統計分析を用いて可視化します。 下図は セキュリティインシデント の調査のプロセスを示しています。 Detectiveを使わない従来の調査方法では、それぞれのプロセスで利用するサービスが異なるため、時間と手間が発生していました。 Detectiveを使うことで、各サービスのログがDetectiveに集約・分析され、 セキュリティインシデント の調査を 一気通貫 で進めることができます。 引用： https://www.youtube.com/watch?v=Vf-s3ZQmJhc Detectiveを有効化してみよう！ と言いたいところですが、その前に重要なポイントがあります。 それは、Detectiveでは マルチアカウント連携が可能 であるということです。 例えば、複数の AWS アカウントを抱える組織のSOCやCSIRTが、Detective管理アカウント（ログの集約アカウント）を使って、メンバーアカウント（ログを吐くアカウント）で起きた セキュリティインシデント を調査する、といった構成を組むことができます。 詳細は下記のユーザーガイドを確認してください。 https://docs.aws.amazon.com/ja_jp/detective/latest/userguide/accounts.html 以降の説明では、マルチアカウント連携を行う前提で進めます。 管理アカウントでの作業 まずはDetective管理アカウントとなるアカウントでDetectiveを有効化しましょう。 必要に応じてオプションデータソースを有効化します。 " AWS セキュリティ検出結果"を有効にすると、メンバーアカウントのSecurity Hubの検出結果を収集することが可能です。 メンバーアカウントでEKSを利用している場合はEKS監査ログも収集できますが、ログのデータ量によってはメンバーアカウント側に想定外の課金が生じるため注意してください。 30日間の無料期間がありますので、その間に費用感をチェックすることをお勧めします。 各アカウントを招待しましょう。DetectiveはOrganizations連携にも対応しています。 組織アカウントを Detective メンバーアカウントとして有効にする 個々のアカウントを動作グラフに招待する メンバーアカウントでの作業 メンバーアカウント側で設定すべき内容は以下です。 GuardDutyの有効化（必須） Detectiveに取り込まれるためには、GuardDuty有効化後、48時間が経過している必要があります。 GuardDutyの検出結果のエクスポートオプション で更新結果の取り込み頻度を15分に変更する（推奨） デフォルトは6時間になっており、GuardDutyの更新結果がDetectiveに反映されるまでに時間がかかります。 15分に設定することをお勧めします。 招待を承諾 （マルチアカウント連携の場合は必須） 招待を承諾してから、管理アカウントが情報を取り込むまでに最大24時間を要します。 メンバーアカウント側で事前にDetectiveを有効化してしまうと、メンバーアカウントの動作グラフが管理アカウント内およびメンバーアカウント自身に存在するため、それぞれに課金が発生します。 メンバーアカウント側でDetectiveを使って調査する必要がなければ、メンバーアカウントでDetectiveを明示的に有効化する必要はありません。 アカウント連携前のログはDetectiveに取り込まれません。 Security Hubの有効化（必要に応じて） Inspectorの有効化（必要に応じて） GuardDutyアラートの生成 続いて AWS 上にリソースを立てて、擬似攻撃を起こしてGuardDutyアラートを生成しましょう。 今回は、コマンド1つでサンプルではない実際のGuardDutyアラートを生成できるツール"GuardDuty Findings Tester"を用います。 https://github.com/awslabs/amazon-guardduty-tester GuardDuty Findings Testerでは、攻撃元となるリソース（Kali Linux ）と、攻撃対象となるリソースをCDKでデプロイします。 アラート生成方法としては、FindingType指定をはじめ、リソース種類別、ログソース別、MITRE ATT&CKの Tactics （攻撃戦術）別などがあります。 今回は下記のFindingTypeを指定して検出させてみました。 UnauthorizedAccess:EC2/RDPBruteForce UnauthorizedAccess:EC2/SSHBruteForce なお、以下の点は予め留意した上で、デプロイ先のアカウント、GuardDutyの通知先を事前に考慮することをお勧めします。 本環境はTorノードにアクセスする仕様になっているため、CDKをデプロイした後にUnauthorizedAccess:EC2/TorClientが勝手に検出される FindingTypeを指定して検出させても、複数のアラートが発生する場合がある Detective管理アカウントによる調査方法 お待たせしました。Detectiveを使って調査を始めましょう！ Detectiveで利用できる機能は大きく分けて3つあります。 検出結果グループ（finding groups） 関連性のありそうな検出結果を検出結果グループとしてまとめてくれる機能です。 検出結果グループの概要を要約してくれたり、各エンティティ間の関連性を可視化してくれます。 注意点として、GuardDutyアラートが生成されて検出結果グループが作成されるのに最大48時間を要するということ、 利用できるリージョン に限りがあります。 検出結果グループの一覧 検出結果グループの概要を要約 生成AIによって個々の検出結果グループを要約する機能で、以下のような内容を確認できる i-0dc6330b23830eb27は、ポートスキャン、他のIPに対する SSH /RDP ブルートフォース攻撃 、Torとの通信を実行した。 また、悪意のある IPアドレス から API コールを行った。 i-010e2e28e9486f520はポートスキャンと SSH ブルートフォース アタックを実行した。 この インスタンス では悪意のあるファイルも検出された。 172.16.0.169は、i-0dc6330b23830eb27とi-010e2e28e9486f520からのポートスキャンと SSH ブルートフォース アタックの標的となった。 関連する以下の検出結果を一覧で確認できる GuardDuty Security Hub Inspector（ネットワーク到達可能性とソフトウェアの 脆弱性 ） 各エンティティ間の関連性を可視化（Finding group visualization） 攻撃の起点や関連しているリソースを図から読み取れる ブルートフォース 系のアラートはインバウンド/アウトバウンドで色分けされる Finding group visualizationから特定のエンティティを選択してドリルダウン的に検索することが可能（→ インスタンスIDで検索 に遷移） 調査機能（Detective Investigation） IAMユーザーまたはロールに関連する IoC （Indicator of Compromise; 侵害の証跡）を調査し、レポートを作成します。 対象のIAMユーザーまたはロールが セキュリティインシデント に関与しているかの判断に役立つ機能です。 リソース（IAMユーザーまたはロール）を選択し、調査を実行するとレポートが生成され、影響度に基づいて調査結果の重要度が割り当てられる IAMユーザーを調査 MITRE ATT&CKのTTP（攻撃手順）によって マッピング され、重要度が判定された例 ロールを調査 重要度が高いアクティビティがある IPが表示され、関連するGuardDuty検出結果が表示された例 IPアドレス でドリルダウンしたい場合は IPアドレス のリンクをクリック（→ IPアドレスで検索 に遷移） 検索機能（search） アカウントレベル、またはアカウント内の各エンティティレベルで分析できる機能です。 いくつか例をあげてみました。 アカウントIDで検索 GuardDuty、Security Hub、Inspectorの検出結果を一覧で確認できる（各エンティティレベルでも確認可能） 新しい動作では、新たに観測された位置情報を確認できる（各エンティティレベルでも確認可能） 時間範囲内に観測された位置情報はオレンジの丸で表示される 位置情報を一覧でも表示でき、全体の API 呼び出しに占める割合なども確認できる インスタンス IDで検索 対象 インスタンス の詳細（作成者や作成時刻など）を確認できる ロールをドリルダウンしたい場合はロール名のリンクをクリック（→ インスタンスに紐づくロールで検索 に遷移） インスタンス に紐づく IPアドレス を確認できる VPC フローログに基づいて観測されたリモートの IPアドレス を一覧で確認できる リモートの IPアドレス の通信の方向、allow/denyについてフィルターできる インスタンス に紐づくロールで検索 検出結果グループや調査レポートとの紐付けがあれば確認できる 調査（Detective Investigation）が未実施であればその場で実施できる（→ ロールを調査 に遷移） IPアドレス 別 -> サービス別の API の呼び出し結果を一覧で確認できる IPアドレス で検索 IPアドレス の詳細を表示。逆引きが出力されたりはしない（3.x.x.xなので AWS という想像はつきますが）。 リソースとのインタ ラク ションを確認できる IAMユーザー名で検索 検出結果グループや調査レポートとの紐付けがあれば確認できる 調査（Detective Investigation）が未実施であればその場で実施できる（→ IAMユーザーを調査 に遷移） 対象のIAMユーザーによって呼び出されたサービス別の API の結果を一覧で確認できる（キャプチャは割愛） まとめ Detectiveを活用することで、 セキュリティインシデント に関連したリソースが可視化され、調査が容易になります。 以下のポイントを押さえ、効果的な活用を目指しましょう。 Detective管理アカウント／メンバーアカウントにて事前に必要な設定を実施する。 Detectiveの各種機能を活用 検出結果グループ： 複数のセキュリティイベントの関連性を俯瞰的に把握する。 調査機能： IAMユーザーやリソース単位での分析を行い、侵害の痕跡（ IoC ）を特定し、 セキュリティインシデント への関与を判断する。 検索機能： エンティティレベルで詳細に分析できるようになっており、問題の根本原因を特定する。 コストへの配慮 Detectiveの利用においては、30日間の無料期間中にデータ量や費用感を確認する。 メンバーアカウント側で予め明示的にDetectiveを有効化しないこと。 オプションデータソースであるEKS監査ログは必要なければ有効化しないこと。 最後にちょっとだけ補足 Detectiveの使い方としては、検出結果グループで概要を掴み、その後は調査機能でインシデントの有無を判断したり、検索機能で詳細調査する流れが理想的かと考えています。 ただし、検出結果グループが反映されるまでにGuardDutyアラート生成後、最大48時間を要するという制約があり、検出結果グループを見たい時にまだ見られないということが起こり得ます。 上記について改善要望を挙げていますが、より早く検出結果グループが生成されるように改修されることを期待したいと思います。 また、Detectiveがその効果を最も発揮するのは、 Amazon Detectiveとは で図示されている通り、Inspector、Security Hub、GuardDutyの検出結果から、それぞれの関連性を読み解く必要性が生じた時だと思います。 例えば、利用している OSS にSSRFの 脆弱性 があり、 インスタンス IMDS v2が適用されておらず、GuardDutyから"UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS"が検出された。みたいなケースです。 参考： https://aws.amazon.com/jp/blogs/news/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ 今回利用したGuardDuty Findings Testerではそのようなシナリオを作ることが難しいため、あくまで機能紹介という形でお伝えしました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @fukuyama.kenta 、レビュー： @nagamatsu.yuji （ Shodo で執筆されました ）

はじめに Iceberg とは？ Iceberg Table for BigQuery Iceberg Table を作る 用意するもの テーブル作成 データを入れる Time Travelできないし、なんだかメタデータがめっちゃ少ない！！！ 次へ はじめに 当記事を開いていただきありがとうございます。 電通 総研 エンジニアリングオフィスの徳山です。 この記事は、テーブルフォーマットの Iceberg についての初歩的な内容を説明します。 BigQuery で Iceberg 形式のデータを作成し、実体ファイルの中身をお見せすることで、Iceberg が一体どういうものなのか実感を持つきっかけになればと意図しています。 ただし、タイトルのとおり期待どおりにはいきませんでした。私の事前調査不足でございます。 Iceberg とは？ Apache Iceberg は、分析向けに作られたフォーマットの1つで、テーブルフォーマットと呼ばれます。 データ分析基盤のデータレイクに格納するデータファイルのフォーマットに使用されます。 Iceberg などのテーブルフォーマットを使用して機能的に統合されたデータレイクはレイクハウスと呼ばれ、データウェアハウスやETLツールなどと組み合わせて相互補完的に使用されます。 データレイクへ格納されるデータファイルは、 CSV などのファイルフォーマットや Parquet などのデータフォーマットで格納されます。さらにそれらデータファイルを Iceberg などのテーブルフォーマットが梱包するようにフォーマットし、様々な機能が加わります。 Iceberg ( Apache Iceberg) を使用することで以下の機能がデータレイクで利用できるようになります。 Schema evolution ： スキーマ の変更 Hidden partitioning ： Icebergの内部で パーティション 値を生成・保持し、ユーザは意識せずに利用可能 Partition layout evolution ： パーティション の改変を実現 Time travel ： データのスナップショットを取得し、 スキーマ の変更の追跡や ロールバック などを実現 これらの機能はリレーショナルデータベースやデータウェアハウスなどではお馴染みのものに見えます。しかし、データレイクではデータはファイルで格納されるため、それらファイルをテーブルのように スキーマ 変更したり パーティション を組み替えたりできるようになることが画期的なものと理解しています。 Iceberg Table for BigQuery Google Cloud の BigQuery は、Iceberg Table というBigQuery用のテーブルフォーマットとして Iceberg をサポートしています。 テーブル作成時に、 Iceberg 形式を指定し、データの格納先として Google Cloud Storage (GCS) のフォルダパスを指定することで Iceberg Table のテーブルが作成されます。 これは External Table （外部テーブル） に似ていますが、BigQueryにおいては、 External Table ではありません。 External Table とは、ストレージ上のデータファイルをデータウェアハウスなどからテーブルとしてフォーマットする技術です。 クラウド サービスや Apache Spark 、Hive などで以前から存在し、データレイクに対して使用されてきました。 一般的に External Table はデータファイルを読み取ってテーブルのようにクエリすることはできますが、Iceberg のような機能はありません。 BigQuery には External Table と同類の機能で BigLake External table というテーブル形式があり、Iceberg 用の BigLake External Table が別途存在します。 Iceberg Table を作る 用意するもの Google Cloud Storage の バケット とフォルダ ： Iceberg Tableのデータファイル格納先 BigQuery のデー タセット ： BigQuery 側のテーブル BigQuery の外部接続 ： BigQuery から Google Cloud Storage への接続で使用するサービスアカウント テーブル作成 以下のクエリでテーブルを作成します。 # BigQueryのプロジェクトIDやデータセット名、カラムなどの記述を省略しています。 CREATE TABLE IF NOT EXISTS <プロジェクトIDやデータセット名>.call_center_iceberg ( PRIMARY KEY (cc_call_center_sk) NOT ENFORCED, cc_call_center_sk STRING NOT NULL, cc_call_center_id STRING NOT NULL, ＜ カラムの指定省略 ＞ cc_tax_percentage DECIMAL(7, 2), processing_date DATE, ingestion_date DATE ) CLUSTER BY processing_date WITH CONNECTION ＜外部接続ID＞ OPTIONS ( file_format = 'PARQUET', table_format = 'ICEBERG', storage_uri = 'gs://<GCSバケット名>/raw-data/store-sales-iceberg') ; 作成されたテーブル (Iceberg Table) 通常のテーブル スキーマ のように見えます。通常のテーブルは "プレビュー" というタブが表示されますが、Icheberg Table の場合は表示されません。 テーブル作成時に指定のデータファイルの格納先フォルダ metadata というフォルダが作成されて、中に json ファイルが入っています。 データを入れる insert into を実行してデータを入れてみました。 テーブル (Iceberg Table) 側で見えるデータ テーブル形式のデータのように見えます。 テーブル作成時に指定のデータファイルの格納先フォルダ data というフォルダが作成されて、中に parquet フォーマットのファイルが入っており、これが BigQuery の画面へ表示のデータです。 Time Travelできないし、なんだか メタデータ がめっちゃ少ない！！！ 次にデータや スキーマ を更新して Time Travel の機能を使ってスナップショットを見ていきたかったのですが、BigQuery の Iceberg Table では使えないことが分かりました。 そういえば、前述の metadata に格納された json に メタデータ がほぼ記録されていないことに気づきました。 記録されていた メタデータ (v0.metadata. json ) { "properties": { "bigquery-table-id": "xxxxxx.xxxxxx.call_center_iceberg" }, "current-snapshot-id": -1 } 本来の Iceberg では、データや スキーマ が更新されるとスナップショットが作成されて、この metadata. json へ記録されます。 BigQuery の Iceberg Table では更新しても metadata. json は特に変化がありませんでした。 次へ Iceberg Table on BigQuery はまだプレビュー版のため今後に期待したいと思います。 その間、 AWS や Databricks、 Snowflake 、DuckDBなどで Iceberg を使って深掘りしていきたいと思います。 ここまで読んでいただき本当にありがとうございました！！！ どうぞ良いお年をお迎えください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @shikarashika 、レビュー： @nagamatsu.yuji （ Shodo で執筆されました ）

こんにちは。 電通 総研の多田圭佑です。 本記事は 電通 総研 Advent Calendar 2024 の12月 20日 の記事です！ 前日の記事は平岡恵里さんの「 Azure SOCで活躍している便利なサービスたち 」でした。 はじめに axumとActix Web axumの概要 Actix Webの概要 Hello, world! mainマクロ axumの場合 Actix Webの場合 ルーティング リクエストとレスポンス コンパイル後のバイナリについて まとめ はじめに みなさんはRustのWebフレームワークを使用したことはありますか？ RustにはいくつかのWebフレームワークがありますが、中でもaxumとActix Webは機能が豊富で開発も活発なことから人気があります。 どのような違いがあるのか、今回は簡単に「Hello, world」を比較しながら違いを見ていきたいと思います。 使用した環境およびバージョンは以下です。 項目 情報 OS Windows 11 Rust 1.83.0 axum 0.7.9 Actix Web 4.9.0 axumとActix Web 冒頭で述べた通りRustのWebフレームワークはいくつかあります。 以下がよくまとめられていて参考になります。 https://github.com/flosse/rust-web-framework-comparison?tab=readme-ov-file#server-frameworks 掲題の2つのWebフレームワークについては GitHub から引用しつつ概要を記載します。 axum の概要 axum is a web application framework that focuses on ergonomics and modularity. 「axumは人間工学とモジュール性に重点を置いたWebアプリケーション フレームワーク である」 とでも訳せるでしょうか。axumの特徴は以下のとおりです。 Rustの非同期ランタイムである Tokio とHyper（HTTPライブラリ）で構成されている 設計の中心にRustの強力な型システムを据え、リク エス トやレスポンスの処理を安全かつ明確に行える Tower ミドルウェア を活用することで、柔軟で再利用可能な構成が可能となっている また、axumを人間工学やモジュール性の観点から見た特徴は以下のとおりです。 人間工学 シンプルな API と型安全性、Rustエコシステムとの統合により、直感的でミスを減らす設計がなされている モジュール性 Towerの利用や、ハンドラや ミドルウェア を独立した構成単位として扱える設計により、拡張性と再利用性の高い設計がなされている ちなみにdocs.rsはaxumで動いています。 https://docs.rs/ Cargo.toml あと余談ですがaxumのaは小文字が正式です（私はActix Webに引きずられてずっと大文字だと思ってました）。 Actix Web の概要 Actix Web is a powerful, pragmatic, and extremely fast web framework for Rust 「Actix WebはRustで開発された高性能で拡張性の高いWebフレームワーク」といったところでしょうか。 概要は以下のとおりです。 Actorモデルに基づいた非同期 フレームワーク であるActixがベースとなっている 高速かつ安全なHTTPサーバー構築が可能で、大規模なアプリケーションにも対応している 非同期処理のために Tokio ランタイムを使用している 全文検索 で有名なmeilisearchはActix Webを使用していますね。 https://www.meilisearch.com/ Cargo.toml Hello, world! さて、本題です。さっそくコードを見ていきましょう。 まずはaxumです。 use axum :: { extract :: Path, response :: IntoResponse, routing :: get, Router}; async fn greet ( Path (name): Path < String > ) -> impl IntoResponse { format! ( "Hello, {name}!" ) } #[tokio::main] async fn main () { let app = Router :: new (). route ( "/hello/:name" , get (greet)); let listener = tokio :: net :: TcpListener :: bind ( "127.0.0.1:3000" ) .await . unwrap (); axum :: serve (listener, app).await. unwrap (); } 続いてActix Webです。 use actix_web :: {get, web :: Path, App, HttpServer, Responder}; #[get( "/hello/{name}" )] async fn greet (name: Path < String > ) -> impl Responder { format! ( "Hello, {name}!" ) } #[actix_web::main] async fn main () -> std :: io :: Result < () > { HttpServer :: new ( || App :: new (). service (greet)) . bind (( "127.0.0.1" , 8080 )) ? . run () .await } いかがでしょうか。雰囲気はとても似ていますね。 両者の細かな違いとして以下をピックアップします。 mainマクロ ルーティング リク エス トとレスポンス mainマクロ axum: #[tokio::main] Actix Web: #[actix_web::main] となっています。 それぞれmain関数を非同期化するためのマクロを使用していますが、利用しているライブラリが違います。 マクロを展開した後のmain関数を見てみましょう。 cargo expand を使用すると展開されたコードを簡単に確認できます。 まずはaxumです。 fn main () { let body = async { let app = Router :: new (). route ( "/hello/:name" , get (greet)); let listener = tokio :: net :: TcpListener :: bind ( "127.0.0.1:3000" ).await. unwrap (); axum :: serve (listener, app).await. unwrap (); }; #[allow(clippy::expect_used, clippy::diverging_sub_expression)] { return tokio :: runtime :: Builder :: new_multi_thread () . enable_all () . build () . expect ( "Failed building the Runtime" ) . block_on (body); } } 続いてActix Webです。 fn main () -> std :: io :: Result < () > { < :: actix_web :: rt :: System > :: new () . block_on (async move { { HttpServer :: new ( || App :: new (). service (greet)) . bind (( "127.0.0.1" , 8080 )) ? . run () .await } }) } axumの #[tokio::main] は Tokio のmain関数を非同期化するマクロでaxum固有のものではありません。 そのため詳細は Tokio の公式ドキュメントなどを参照していただければと思いますが 今回のコードはサーバーを起動し、サーバーが停止するまでmain関数の終了をブロックしている、というイメージです。 Actix Web側も同様に block_on(...) がありますね。 実はこちらも裏で Tokio が使用されているため、コードのイメージはaxumとほぼ同じです。 Actix Webはactix-rtというActixエコシステムの非同期ランタイム（以降、Actixランタイム）を使用しています。 Actixランタイムはもともと Tokio を使用しておらず、独自の非同期ランタイムでした。 しかし、 Tokio がRustエコシステムの標準ランタイムとして確立されたことなどから、 Tokio ベースにリライトされました。 そのためActix Webは Tokio に対応しており、実は #[tokio::main] も使用できます。 ただしActixのActorの機能を使う場合はActixランタイムが必要なため、 #[actix_web::main] を使用する必要があります。 各サーバー処理（ axum::serve と HttpServer::new... ）の裏側はかなり異なるのですが、長くなってしまうため今回は軽くご紹介する程度にとどめます。 別の機会に当ブログでご紹介したいと思っていますが、興味のある方は調べてみてください。 axumの場合 axumのサーバーはシンプルな構成で Tokio ランタイムとHyperがリク エス トを非同期タスクとして処理します。 コードもかなりシンプルです。 https://github.com/tokio-rs/axum/blob/9983bc1da460becd3a0f08c513d610411e84dd43/axum/src/serve.rs#L224 Actix Webの場合 Actix Webのサーバーは起動時にワーカースレッド（OSスレッド）を用意します。 ワーカースレッドの数はデフォルトだと論理CPU分ですが、コードで数を設定することも可能です。 このワーカースレッドたちがリク エス トを非同期タスクとして処理する形になります。 Actixランタイムの場合と Tokio ランタイムの場合で内部的な動作が若干異なりますが、こちらも詳細に入ると長くなってしまうため別の機会にします。 コードは以下のあたりです。 Actixランタイムの場合 Tokioランタイムの場合 axumも new_multi_thread() でOSスレッドが起動しますが、管理は Tokio ランタイムにお任せでActix Webのように独自の管理はしていません。 ルーティング Actix Webはマクロベースのルーティングを提供していますが、実はaxumのようなルーティングも可能です。 axumと比較すると、axumの方が to(...) が無い分ほんのわずかにシンプルですが、ほぼ変わりませんね。 use actix_web :: { web :: Path, web :: get, App, HttpServer, Responder}; async fn greet (name: Path < String > ) -> impl Responder { format! ( "Hello {name}!" ) } #[actix_web::main] async fn main () -> std :: io :: Result < () > { // HttpServer::new(|| App::new().service(web::resource("/hello/{name}").to(greet))) // ↑も可能 HttpServer :: new ( || App :: new (). route ( "/hello/{name}" , get (). to (greet))) . bind (( "127.0.0.1" , 8080 )) ? . run () .await } リク エス トとレスポンス リク エス トはどちらも関数の引数として受けています。 axumは デストラクチャリング する形で受け取っています。 （ JavaScript のスプレッド構文と同じような感じです） パスパラメーターが増えた場合は以下のように拡張可能です。 async fn greet ( Path ((name, friend_name)): Path < ( String , String ) > ) -> impl IntoResponse { format! ( "Hello {name} and {friend_name}!" ) } タプル構造体である Path はメンバーを公開しているため（ pub T の部分）、上記のようにデスト ラク チャリングできます。 // axumのPath pub struct Path < T > ( pub T); あるいは構造体を使用することも可能です。 #[derive(Deserialize)] pub struct PathInfo { pub name: String , pub friend_name: String , } async fn greet ( Path (p): Path < PathInfo > ) -> impl IntoResponse { format! ( "Hello {} and {}!" , p.name, p.friend_name) } 一方、Actix Webはaxumのようにデスト ラク チャリングする形で増やせません。 下記は コンパイル 時にエラーとなります。 // コンパイルできません #[get( "/hello/{name}/{friend_name}" )] async fn greet ( Path ((name, friend_name)): Path < ( String , String ) > ) -> impl Responder { format! ( "Hello {} and {}!" , name, friend_name) } これはActix Webの Path がメンバーをaxumのように公開していないためです。 // Actix WebのPath pub struct Path < T > (T); しかしできなくても全く問題ありません。構造体は問題なく使用できるからです。 // 構造体はaxumと同様 #[get( "/hello/{name}/{friend_name}" )] async fn greet (p: Path < PathInfo > ) -> impl Responder { format! ( "Hello {} and {}!" , p.name, p.friend_name) } p は Path<PathInfo> 型であるものの、Rustの 型推論 などにより自動的にPathInfo型への参照に変換されます。 そのため PathInfo のフィールドにアクセスできています。 レスポンスはほぼ同じですね。 レスポンスのトレイトである IntoResponse (axum)、 Responder (Actix Web)を実装すればOKのようです。 主要な型（今回のStringなど）はWebフレームワーク側でだいたい 実装済 です。 https://docs.rs/axum/latest/axum/response/trait.IntoResponse.html https://docs.rs/actix-web/latest/actix_web/trait.Responder.html コンパイル 後のバイナリについて ここまでコードの違いを見てきましたが、最後に コンパイル 後のバイナリについて触れます。 それぞれ コンパイル 後のバイナリサイズを比較したところ、Actix Webはaxumと比べて大きくなりました。 これはActix Webで使用しているライブラリがaxumに比べて多いためと推測されます。 ただ、Hello, worldで使用しているルーティングのマクロだけに機能を絞るとほぼ同じになりました。 Cargo.tomlで default-features を無効化し、 features を設定することで絞れます。 最適化なし 最適化あり axum 2476kb 486kb Actix Web 9417kb 1798kb Actix Web（絞った後） 3642kb 592kb 使用した最適化オプションは以下のとおりです。 [profile.release] strip = true opt-level = 's' lto = true codegen-units = 1 panic = "abort" まとめ 今回はaxumとActix WebのHello, worldを比較してみました。 雰囲気は似ているものの、細かな部分で違いがありました。 mainマクロで触れた各 フレームワーク のサーバー処理の詳細についてはまた別途ブログにまとめたいと思います。 コードは以下にまとめました。 https://github.com/keisuketada/axum-actixweb-hello ここまでお読みいただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @tada.keisuke 、レビュー： @nagamatsu.yuji （ Shodo で執筆されました ）

こんにちは。コーポレート本部サイバーセキュリティ推進部セキュアシステムデザイングループの平岡です。 弊社のAzure クラウド SOC（以下Azure SOC）では、各プロジェクトのAzure環境のセキュリティ設定の可視化と改善、および セキュリティインシデント の早期発見と調査支援を行っています。 私はAzure SOC運営メンバーとして主に Microsoft Defender for Cloudを活用し、各プロジェクトのAzure環境のセキュリティ設定の監視を行っています。 1年以上経ってしまいましたが、 前回書いたブログ ではAzure Lighthouseを利用して他テナント（ サブスクリプション ）の情報を権限委譲により集中管理する方法を紹介しました。 今回はAzure SOCで活躍している Microsoft Defender for Cloudのサービスや機能、 Microsoft Defender for Cloudと連携することで更なるセキュリティの向上を見込めるAzureサービスについてご紹介したいと思います。 なお、 AWS SOCサービス に関するブログは既に同じグループの耿さんがまとめているので、興味がある方はこちらも是非ご覧ください。 Azure SOCが提供しているサービス Azure SOCは社内のプロジェクトに対し主に以下のサービスを提供しています。 Azure環境のセキュリティ設定不備のチェック（主に Microsoft Defender for CloudのCSPM機能を利用） Azure環境での脅威検知（主に Microsoft Defender for CloudのCWP機能を利用） 使用しているAzureのサービスは構成図のとおりです。 Azure Lighthouse を用いてマルチテナント間の Micorosoft Defender for Cloud のセキュリティ情報を集中管理し、セキュリティ設定不備状況をグラフや表で一覧にして可視化するために Azure Workbook を利用しています。 また、 Microsoft Entra Privileged Identity Management (PIM) を活用し、プロジェクトの サブスクリプション に対する権限を最小限に抑えるようにアクセス制御を実施しています。 今回は主な構成要素である4つのAzureサービスを紹介したいと思います。 構成図 主な構成要素 1. Azure Lighthouse 2. Microsoft Defender for Cloud 3. Azure Workbooks 4. Microsoft Entra Privileged Identity Management (PIM) 1.Azure Lighthouse Azure Lighthouse は、リソース間でのスケーラビリティ、自動化の向上、ガバナンスの強化など、 マルチテナントの管理 を実現します。 各プロジェクトが使用している サブスクリプション から、Azure SOCの サブスクリプション へAzure Lighthouseを用いて権限の付与を行います。この権限付与により、各プロジェクトの サブスクリプション のセキュリティ設定やアラートを取得できます。ただし、Azure Lighthouseはポータルの画面操作だけではデプロイを完結することができず、委任元環境で ARMテンプレートを使ってデプロイ してもらう必要があります。 （Azure Lighthouseの活用方法や詳細なデプロイ方法を詳しく知りたい場合は、 前回のブログ をご確認ください。） 2. Microsoft Defender for Cloud Azure Lighthouseを使用することで、各プロジェクトの サブスクリプション の Microsoft Defender for Cloudの情報を集中管理できるようになりました。次は、Azure SOCでよく利用している Microsoft Defender for Cloudの機能について紹介します。 2-1.推奨事項 推奨事項画面では、デフォルトで無償のFoundational CSPMプランが有効化されているため、 クラウド 環境のセキュリティを強化するための改善点 や、 対応すべき事柄が一覧化 されています。 更に有償のDefender CSPMプランを有効化すると、表示されている Microsoft Defender for Cloudによってモニターされる組み込みのポリシー（以下、組み込みポリシー） のリスクレベルが表示されます。 Microsoft がリスクレベルを定めており、何から着手しようか迷った場合はリスクレベルに基づいて 重要な組み込みポリシーから対処 できます。 また、画面の上方に"Azure サブスクリプション 31"とありますが、これがAzure Ligthouseによって参照権限を与えられた サブスクリプション の数です。さらにその横には" AWS アカウント"、" GCP プロジェクト"とあるように Azure以外の クラウド のセキュリティ情報を集中管理 することもできます。 組み込みポリシーを選択すると 詳細情報 が表示され、具体的な説明や修復方法を確認できます。 組み込みポリシーの中には クイック修正機能 を利用できるものがあり、修正ボタンを押すだけでセキュアな設定に変更できます。クイック修正ができない組み込みポリシーもありますが、手動での修正手順も掲載されているので調査の手間を削減することができます。 似たような機能で 規制 コンプライアンス がありますが、この画面では推奨事項とは異なる観点で組み込みポリシーが整理されています。デフォルトの Microsoft cloud security benchmarkイニシアティブ （組み込みポリシーをまとめたグループのようなもの）には、ネットワークセキュリティ、ID管理など関連する組み込みポリシーが分類されてまとめられているため、どのような組み込みポリシーがあったか確認するのに便利です。 イニシアティブは自分で作成することもできるため、特に 注視したい組み込みポリシーをまとめたイニシアティブを作成 するのも良いと思います。 2-2.セキュリティ警告 セキュリティ警告画面では、 クラウド ワークロード保護（CWP）を有効 にすることで、 クラウド 環境内での脅威が検知 されるようになります。エージェントベースもしくはエージェントレスの監視が可能で、 クラウド 環境で稼働する 仮想マシン やコンテナイメージの 脆弱性 をスキャンしてくれます。表示されている各アラートの重要度は Microsoft が定めており、複数アラートが出てしまった場合は重要度が高いアラートから対処できます。 有効にするプランによりカバー範囲が異なる ため、環境設定画面でどのような機能を使いたいか事前に確認するといいと思います。 環境設定画面の上部に"すべてのプランを有効にします"というボタンがありますが、全てを有効化するとコストが多く掛かるため、 必要なプランをよく検討すること をおすすめします。 © 2024 Microsoft Corporation. Microsoft Microsoft Defender for Cloudの価格 の スクリーンショット （2024/12/19） 原典: https://azure.microsoft.com/ja-jp/pricing/details/defender-for-cloud/ 2-3.ワークフローの自動化 ワークフローの自動化では、上述の組み込みポリシーやアラートを見逃さないために、これらが検出されたときの対応を 自動化 することができます。 例えば、監視している サブスクリプション 内でアラートが検出された際に、 Logic Appと連携 しておくことで Slackや Microsoft Teamsなどにアラートの内容を即時に通知する ことができます。これにより、定期的に Microsoft Defender for Cloud画面を見なくても、ワークフローの自動化を設定することで イベントの見落としを減らし、効率的で迅速な対応 ができます。 また、ワークフローの自動化およびLogic Appの設定はノーコード・ローコードでできてしまうので、 プログラミング経験がなくても簡単に設定できる のも良いところです。 3.Azure Workbooks Microsoft Defender for Cloudの基本機能を上述しましたが、もっと Microsoft Defender for Cloudを使い倒したいという方はAzure Workbookを利用することをおすすめします。 Azure Workbookでは、 クラウド 環境のセキュリティ情報を分析しやすいように カスタマイズ して可視化することができます。 Microsoft Defender for CloudやAzure Monitorで収集したデータを グラフ、テーブル、チャート にして視覚的にわかりやすく表示できます。 とても便利な機能ではあるのですが、 KQL（Kusto Query Language）の知識が全くない状態だとやりたいことが出来ない可能性がある ので、KQLの勉強も兼ねてチャレンジしてみてください。 Kusto documentation： https://learn.microsoft.com/ja-jp/kusto/?view=azure-data-explorer 4. Microsoft Entra Privileged Identity Management (PIM) 最後に Microsoft Entra Privileged Identity Management （PIM）について紹介します。 PIMは、 Microsoft Entra ID の機能の一つで、 組織内の重要なリソースへのアクセスを管理、制御、監視 を行うことができます。 Azure SOCでは、プロジェクトの サブスクリプション から"セキュリティ閲覧者"や"セキュリティ管理者"のアクセス権限を付与してもらっているため、各 サブスクリプション を監視することができていますが、基本的に"セキュリティ管理者"の権限はワークフローの自動化を設定する時しか使用しません。 そのためPIMを利用して権限制御を行い、 "最低限必要な権限" を "最低限必要なユーザー" に "最低限の期間" 付与するようにしています。 Azure SOCのリソース（Logic AppやAzure Workbook等）を編集する場合なども同様です。 日常的にこれらのリソースを編集する必要はないので、"所有者"権限はもちろんのこと、"ロジックアプリの共同作成者"や"ブック共同作成者"等の権限も PIMを用いた承認制 で運用しています。 実際にPIMを使ってみると 権限周りの運用が楽 になり、権限解除を忘れてしまうこともなくなったので 心の負担も軽くなった と思います。ただし、こちらの PIMも利用にあたりライセンス契約が必要 となります。使用するユーザー全員分のEntra ID Premium P2 ライセンスが必要となり、現時点（2024年12月）では¥1,349 ユーザー/月の費用がかかります。 Microsoft Entra Privileged Identity Management とは： https://learn.microsoft.com/ja-jp/entra/id-governance/privileged-identity-management/pim-configure PIMを利用せずにダブルチェック等を行って運用できればお金もかかりませんが、定期的なアクセス権限の棚卸を忘れてしまったり、所有者権限などの強い権限の解除を忘れてしまった…といったリスクが高まります。 アクセス制御と心の平和のためにも、個人的には是非一度利用を検討していただきたい一押しサービスです。 終わりに 今回はAzure SOCで活躍している Microsoft Defender for Cloudのサービスや機能、 Microsoft Defender for Cloudと連携することで更なるセキュリティの向上を見込めるAzureサービスの一例をご紹介しました。 私たちは日々セキュリティに関する知見のキャッチアップを行っており、Azure SOCサービスもこれからどんどん改善していく予定です。 今後も検証してみて便利だと感じたAzureのサービスや機能について発信していきたいと思いますのでお楽しみに！ 私たちは一緒に働いてくれる仲間を募集しています！ 株式会社 電通総研 新卒採用サイト 執筆： @hiraoka.eri2 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは、 電通 総研の金融ソリューション事業部の上野です。 普段の業務ではアーキテクトで案件に関わっており、現在は Java 、React、Next.jsを利用したソリューション開発に従事しています。 業務で利用する OSS のバージョンアップや技術選定はアーキテクトの重要な業務の一つであると考えており、今回は直近リリースされたReact19について調査した内容を一部記事にしました。 本記事は、 電通総研 Advent Calendar 2024 の18日目の記事となります。 はじめに Reactは、バージョンアップのたびに レンダリング 戦略や非同期処理周りの仕様が進化してきました。直近では、2022年3月に登場したReact 18では並行 レンダリング （Concurrent Features）やSuspenseの実用化による非同期処理の新しい書き方が可能となりました。さらに2024年12月に登場したReact 19では、useフックをはじめとしたより自然で宣言的な非同期パターンへと進化することが期待されています。 非同期処理は、ユーザエクス ペリエ ンス（UX）向上に直結する極めて重要な要素です。データ取得や状態の変化を ブロッキング することなく画面を表示し、スムーズな操作体験を提供するためには、React側が標準で非同期 レンダリング やデータフェッチをサポートしていく必要があります。またReact本体の GitHub Issueや議論でも、非同期処理やSuspenseをめぐる活発なやり取りが続いており、コミュニティとしてもこの分野への関心は非常に高まっています。 そこで本記事では、React 17から18、そして19へと進むにつれて非同期処理の書き方がどのように変わってきたのかを解説します。 （参考） RFC: First class support for promises and async/await [Suspense - React])( https://ja.react.dev/reference/react/Suspense ) use - React Reactの各バージョンの非同期処理 非同期処理記載方法のまとめ まず初めに、それぞれのReactバージョンにおける非同期処理を記載した際の課題についてまとめました。 〇は課題が解決された状態を表し、React19ではReact17の記法における課題はすべて解決しています。 課題 React17 React17(+useQuery) React18(+useQuery) React19 （1） hooksによる状態管理が複雑 × 〇 〇 〇 （2）ifの分岐が多くなる（宣言的ではない） × × 〇 〇 （3） コンポーネント の責務が多い × × 〇 〇 （4）外部 OSS に依存 〇 × × 〇 次章から、各バージョンにおけるサンプルコードを載せます。 React17以前の非同期処理（Reactプリミティブな方法） useEffect および useState をラップしたカスタムフックを作成し、非同期にフェッチを行う。 フェッチ後のステータスに応じて、 コンポーネント のだし分けをする。 import { useState, useEffect } from 'react' ; // いずれかのデータフェッチを非同期で行うカスタムフック function useFetchData ( url ) { const [ data , setData ] = useState( null ); const [ loading , setLoading ] = useState( true ); const [ error , setError ] = useState( null ); useEffect(() => { async function fetchData () { try { const response = await fetch (url); if (!response.ok) throw new Error ( 'Failed to fetch data' ); const result = await response.json(); setData(result); } catch (err) { setError(err); } finally { setLoading( false ); } } fetchData(); } , [ url ] ); return { data , loading , error } ; } // 非同期データのfetch後にレンダリングを行うコンポーネント function MyComponent () { const { data , loading , error } = useFetchData( 'https://api.example.com/data' ); if (loading) return < p > Loading... </ p > ; if (error) return < p > Error: { error.message } </ p > ; return ( < div > < p > { data. title } </ p > </ div > ); } export default MyComponent; このコードの課題としては、以下が挙げられます。 （1）hooksによる状態管理が複雑。 useStateによるdata,error,loadingの状態管理が必要。 useEffectによる レンダリング 後の非同期 API コールが必要。 （2）ifの分岐が多くなる（宣言的ではない）。 loading状態を判定する、ifによる分岐。 error状態を判定する、ifによる分岐。 （3） コンポーネント の責務が多い。 loading待ち、エラーハンドルは業務処理と直接関係がない。やりたいことは <p>data.title</p> を表示したいだけ。 React17以前の非同期処理（ OSS の利用） カスタムhook部分を tasntack/react-query に任せることで、fetchに応じた結果をより短いコード量で受け取ることが可能。 フェッチ後のステータスに応じて、 コンポーネント のだし分けをする。 import { useQuery } from '@tanstack/react-query' ; // 非同期なデータfetch async function fetchData ( url ) { const response = await fetch (url); if (!response.ok) { throw new Error ( 'Failed to fetch data' ); } return response.json(); } // 非同期データのfetch後にレンダリングを行うコンポーネント // Promiseの扱いを`tanstack/react-query`に委譲 function MyComponent () { const url = 'https://api.example.com/data' ; const { data , isLoading , error } = useQuery( [ 'data' ] , () => fetchData(url)); if (isLoading) return < p > Loading... </ p > ; if (error) return < p > Error: { error.message } </ p > ; return ( < div > < p > { data. title } </ p > </ div > ); } export default MyComponent; このコードの課題としては、以下が挙げられます。 （2）ifの分岐が多くなる（宣言的ではない）。 loading状態を判定する、ifによる分岐。 error状態を判定する、ifによる分岐。 （3） コンポーネント の責務が多い。 loading待ち、エラーハンドルは業務処理と直接関係がない。やりたいことは <p>data.title</p> を表示したいだけ。 （4）外部 OSS に依存。 できればReactのプリミティブな機能だけで実現したい。 React18の非同期処理 React18で登場したSuspenseと tanstack/react-query が連携することで、Suspense状態を管理することが可能に。 fetch中、fetchの成功、fetchの失敗を分岐処理を設けずに宣言的に記載することが可能に。 import React, { Suspense } from 'react' ; import { useQuery } from '@tanstack/react-query' ; import { ErrorBoundary } from 'react-error-boundary' ; // 非同期なデータfetch async function fetchData ( url ) { const response = await fetch (url); if (!response.ok) { throw new Error ( 'Failed to fetch data' ); } return response.json(); } // 非同期データのfetch後にレンダリングを行うコンポーネント // Promiseの扱いを`tanstack/react-query`に委譲 function MyComponentContent () { const url = 'https://api.example.com/data' ; const { data } = useQuery( [ 'data' ] , () => fetchData(url), { suspense : true } ); return ( < div > < p > { data. title } </ p > </ div > ); } // エラー時に表示するフォールバックコンポーネント function ErrorFallback ( { error } ) { return < p > Error: { error.message } </ p > ; } // fetch中、fetch成功時、fetch失敗時にそれぞれ適切なコンポーネントを表示する export default function MyComponent () { return ( < ErrorBoundary FallbackComponent = { ErrorFallback } > < Suspense fallback = { < p > Loading... </ p > } > < MyComponentContent /> </ Suspense > </ ErrorBoundary > ); } このコードの課題としては、以下が挙げられます。 （4）外部 OSS に依存。 できればReactのプリミティブな機能だけで実現したい。 React19の非同期処理 React19で登場した use と cache の組み合わせにより、Reactプリミティブな API のみでSuspense状態を管理することが可能に。 import { use, Suspense, cache } from 'react' ; import { ErrorBoundary } from 'react-error-boundary' ; // 非同期なデータfetch const cachedFetchData = cache( async ( url ) => { const response = await fetch (url); if (!response.ok) { throw new Error ( 'Failed to fetch data' ); } return response.json(); } ); // 非同期データのfetch後にレンダリングを行うコンポーネント // Promiseの扱いをはReactプリミティブな`use`を利用 function MyComponentContent () { const url = 'https://api.example.com/data' ; const data = use(cachedFetchData(url)); return ( < div > < p > { data. title } </ p > </ div > ); } // エラー時に表示するフォールバックコンポーネント function ErrorFallback ( { error } ) { return < p > Error: { error.message } </ p > ; } // fetch中、fetch成功時、fetch失敗時にそれぞれ適切なコンポーネントを表示する export default function MyComponent () { return ( < ErrorBoundary FallbackComponent = { ErrorFallback } > < Suspense fallback = { < p > Loading... </ p > } > < MyComponentContent /> </ Suspense > </ ErrorBoundary > ); } 終わりに Reactに限らず、昨今のフロントエンド界隈は群雄割拠であり、目まぐるしい進化を遂げています。その中でも今回は個人的に注目している非同期処理に特化して解説してみました。 書ききれなかった内容については、参考ブログやリンクを記載しておきます。 use API に関する補足 最速攻略！　ReactのuseRFC Suspenseに関する補足 Suspenseはどのような機能なのか 実際の案件ではNext.jsを利用することも多いため、Reactの非同期処理の進化でNext.js13以降どのような破壊的Updateが行われたのか、機会がありましたらまた筆をとろうと思います。最後まで読んでいただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 新卒採用ページ クラウドアーキテクト 執筆： @kamino.shunichiro 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部 AI トランスフォーメーションセンター 所属の山田です。 本記事は 電通総研 Advent Calendar 2024 の 12 月 17 日の記事です。 はじめに 私達は普段、 Python を使ってアプリケーション開発をしています。 本記事では、チームでアプリケーション開発を進めていく中でテスタビリティを上げるために意識していることを紹介したいと思います。 なおコード例は Python ではありますが、採用言語に関わらず品質を高めたいと考えているエンジニアやリーダーにとって参考になる内容を目指しました。 テスタビリティとはなにか 「テスタビリティ」はプロダクションコードをどれだけ容易にテストできるかを指します。 テスタビリティが低いコードは ユニットテスト や統合テストの作成に時間がかかるだけでなく、コードのメンテナンス性が低下し デバッグ 、新機能の追加が難しくなる傾向にあります。 テスタビリティそのものを 定量 的な指標で測ることは難しいため、本記事ではテスタビリティを下げてしまう事例から、どのように改善するとテスタビリティを高められるかを紹介したいと思います。 テスタビリティが低くなる事例とその対応策 1. インスタンス 化が困難なクラス テスト対象クラスのコンスト ラク タを確認することで、そのクラスのテスタビリティについてはある程度把握できます。 テスト対象のクラスの インスタンス 化が困難な場合、そのクラスのテスタビリティは低い傾向にあります。 インスタンス 化を困難にする要因としては以下のことが考えられます。 多すぎる引数 これは ビジネスロジック を記述するサービスクラス側で問題となることが多いものです。 コンスト ラク タに渡すべき引数が多いと、テスト対象クラスを組み立てる際の設定が煩雑になります。 またテスト時に多くのパラメータを準備する必要があり、設定ミスも発生しやすくなります。 不適切な型の定義 これはデータを保持するデータクラス側で問題となることが多いものです。 特定の外部ライブラリの型（ pandas.DataFrame 、 numpy.array など）を直接利用した設計は、テスタビリティを大きく下げる可能性があります。 対応策 クラス設計の見直し インスタンス 化が困難なクラスを解決するには、多くの場合はクラス設計を見直す必要があります。 コンスト ラク タで多くの引数を受けるクラスは大抵の場合、責務を持ちすぎています。クラスを分割できないかを考えてみましょう。 外部依存を隔離して適切な型を利用する 外部ライブラリの型に依存しないプリミティブな型や ドメイン 固有型のクラスによる設計をしましょう。 pandas.DataFrame 、 numpy.array などからデータを変換する必要がある場合は、定義した ドメイン 固有型のクラスにファクトリーメソッドを用意するなどのアプローチを取りましょう。 import numpy as np from dataclasses import dataclass @ dataclass class Vector : values: np.ndarray # 外部ライブラリ依存 @ dataclass class Vector : values: list [ float ] # Python標準のfloat型のリストを利用する 2. 関数・メソッド内に依存関係が含まれている 関数・メソッド内に依存関係が含まれているコードもテスタビリティを下げます。 例えば以下のコードを考えてみましょう。 from dataclasses import dataclass # データクラスとしてのUser型 @ dataclass class User : name: str email: str class UserRepository : def save (self, user: User) -> User: # ユーザーデータをデータベースに保存する処理（詳細は省略） # ... return user class UserService : def register_user (self, user: User) -> User: # メソッド内で直接リポジトリをインスタンス化 repository = UserRepository() saved_user = repository.save(user) return saved_user 関数・メソッド内で依存関係が生成されると、テスト時に差し替えることが困難になります。 テスティングライブラリ側で差し替え方法が用意されている場合もありますが、そのようなコードはトリッキーで可読性が低くなりがちです。 対応策 関数・メソッド内に依存関係が含まれている場合は、外部から依存を注入できるようにパラメータ化した設計にします。 いわゆる、 Dependency Injection: DI の考え方です。 上記のコード例はコンスト ラク タで UserRepository を注入するように変更することでテスタビリティを高めることができます。 from typing import Protocol # リポジトリのインターフェースを定義 class UserRepository (Protocol): def save (self, user: User) -> User: ... # リポジトリ実装 class DatabaseUserRepository : def save (self, user: User) -> User: # ユーザーデータをデータベースに保存する処理（詳細は省略） # ... return user # サービスクラス class UserService : def __init__ (self, repository: UserRepository) -> None : self.repository = repository def register_user (self, user: User) -> User: saved_user = repository.save(user) return saved_user これによってテストコードを書く際に UserRepository の実装を置き換えることも容易になります。 3. 返り値のない関数・メソッド 返り値のない関数・メソッドのテストは大抵、困難になります。 プロダクションコードにおいて、返り値のない関数・メソッドは副作用を伴う処理を実施している場合がほとんどだからです。 例えば、ファイルを クラウド ストレージなどにアップロード処理をするコードに返り値がない場合を考えてみましょう。 class FileUploader : def upload (self, file_content: str ) -> None : # 実際のアップロード処理 # 返り値はない ... この処理が完了したかを確認するためには、アップロード先の クラウド ストレージの状態を確認する操作が必要になり厄介です。 対応策 このような場合は関数・メソッドを返り値を持つ設計にし、動作結果をテストできるようにしましょう。 from dataclasses import dataclass @ dataclass class UploadResult : success: bool url: str | None class FileUploader : def upload (self, file_content: str ) -> UploadResult: try : # アップロード先のURL uploaded_url = f "https://..." return UploadResult(success= True , url=uploaded_url) except Exception as e: print (f "Failed to upload: {e}" ) return UploadResult(success= False , url= None ) 返り値があることによって、ファイルのアップロードの成否を検証しやすくなります。 また返り値があることで該当クラスの FileUploader だけでなく、 FileUploader クラスに依存している他のクラスでは返り値を変化させたモックを使うことで容易にテストを行うことができるようになります。 4. 時間に関する処理 時間に関する処理もテスタビリティを下げる要因となります。 これは時間に関する処理を記述する場合、冪等性のない処理になる可能性が高いからです。 例えば、ユーザーの誕生日の情報をもとに年齢を算出する場合を考えてみましょう。 from datetime import date from dataclasses import dataclass @ dataclass class User : name: str birth_date: date # 誕生日 def get_age (self) -> int : # 現在の日付を取得 today = date.today() return today.year - self.birth_date.year - ((today.month, today.day) < (self.birth_date.month, self.birth_date.day)) get_age メソッドは現在の日付を取得して、ユーザーの誕生日情報との差分から年齢を算出します。 現在の日付情報を取得する date.today() の結果は実行するタイミングで変化するので、このままでは冪等性がなくテストが難しくなります。 対応策 テスティングライブラリ側の機能で時間を固定する機能が提供されている場合もありますが、可能であれば時間情報をパラメーターとして受けるようにしましょう。 時間情報をパラメータとして受け入れるようにすることでメソッドの冪等性を担保できます。 @ dataclass class User : name: str birth_date: date # 誕生日 def get_age (self, today: date) -> int : # 引数で受け取った日付情報をもとに年齢を算出 return today.year - self.birth_date.year - ((today.month, today.day) < (self.birth_date.month, self.birth_date.day)) 引数から時間情報を渡す設計にすることで、安定したテストを行うことができます。 実際の 開発プロセス において価値を引き出すために ここまではプロダクションコードのテスタビリティを高めるために意識するポイントを紹介しました。 しかし実際の 開発プロセス では、ここまで紹介した個別の事例と対応策だけではテスタビリティの高いコードを整備し続けることは難しいでしょう。 ここからは、テスタビリティの高いコードを整備し続けるために、実際の 開発プロセス で重要な要素について紹介します。 テスト戦略の共有 そもそもなぜテストをするのかやテストは何を担保するものなのかを含めてチームでテストに関する全体的な方針を立てることが重要です。 テスト戦略への意識が希薄だと形式的にテストを追加するだけになり、本質的な品質向上には繋がりません。 テスト戦略の共有では、テストレベルに合わせたテストのスコープを定めるのが良いです。 出発点としてはテストピラミッドをベースにすると良いでしょう。 テストピラミッドは「E2E テスト」「インテグレーションテスト」「 ユニットテスト 」の 3 つのテストレベルの関係性についてピラミッド図で表したものです。 ピラミッド上位のテストレベルほどテストの実行にコストを要するため、 ユニットテスト のテストケースを重要であることを示します。 ただし戦略を考えるに当たって重要なのは、やみくもに ユニットテスト を増やすのではありません。 ユニットテスト 、インテグレーションテスト、E2E テストで何をカバーするのかを明確にし、どのようにしたら効果的なテストを実現できるかを示すことです。 またテストピラミッドは機能要件をテストするための概念であるため、非機能要件のテストについては直接的に考慮されていません。 非機能要件のテスト戦略については機能テストとは別で考える必要があります。 非機能要件のテストは個別の機能ではなくシステム全体に関わる特性を評価するものです。 そのためリソースや時間が限られる中では優先度を決めて、現実的に可能な範囲で実行することが重要になります。 パフォーマンステストなどの負荷テストではシステムが提供する ユースケース やビジネスフローに基づいて、特に重要なシナリオから始めることが重要です。 高度な専門知識が必要となるセキュリティテストは外部の専門チームに依頼することも有効なテスト戦略の 1 つです。 テストコードの書き方についての ガイドライン プロダクションコードの書き方についてはよく取り上げられますが、テストコードの書き方については意外と軽視される部分です。 しかしテストコードは開発において品質保証の基盤になるため、プロダクションコードと同様に整備すべきものです。 テストコードの書き方についてもチームに共有しておくことが重要です。 以下はテストコードの書き方についての ガイドライン の一例です。 構造化されたテストコード 「given」「when」「then」を意識してテストを記述をしましょう。 given: テストの前提条件となる準備部分 when: テスト対象の振る舞いの呼び出し then: 実施結果の検証 明瞭なテストケース名をつける テストケース名には日本語を使って何をテストしているかが一目でわかるようなテストケース名を付けましょう。 テストコードが書きにくいと思った場合のアクション テストコードが書きにくい場合、それはプロダクションコードに改善の余地があるサインです。テストが難しい箇所を見つけたらプロダクションコードを見直してテスタビリティを下げている要因を探しましょう。 以下はガイドに基づきながら書いた、先の例で取り上げたユーザーの誕生日から年齢を算出するメソッドのテストコード例です。 from datetime import date @ dataclass class User : name: str birth_date: date # 誕生日 def get_age (self, today: date) -> int : # 引数で受け取った日付情報をもとに年齢を算出 return today.year - self.birth_date.year - ((today.month, today.day) < (self.birth_date.month, self.birth_date.day)) # テストコード def test_user_ 誕生日の算出ができること() -> None : # given birth_date = date( 2000 , 4 , 4 ) user = User(name= "テストユーザー" , birth_date=birth_date) today = date( 2024 , 12 , 15 ) expected_age = 24 # when actual_age = user.get_age(today=today) # then assert expected_age == actual_age また ガイドライン を整備するだけでなく、テストコードの記述も含めてモブプロで取り組むのも良いアプローチです。 モブプロを活用してテストコードを記述することで、チーム全員のスキル向上や設計改善につなげることができます。 テストコードは単なる補助的な存在ではなく、システムの品質を支える基盤として、適切に整備することを目指しましょう。 テストケースの洗い出し テスタビリティが高くなったコードを最大限に活用するには、テストケースの設計が不可欠です。 テストケース設計の際はテスト技法を押さえておくことで網羅性を高めながら効果的にテストケースの設計を進めることができます。 以下は基本的なものですが、個人的には効果が大きいと感じているテスト技法です。 境界値分析 境界値分析は入力値や条件の境界に着目して動作を確認するテスト技法です。 主に入力値の上限/下限が決まっているフォームバリデーションのテスト項目の設計に有効です。 同値分割 同値分割は入力データや条件をグループ化し、代表的なケースをテストすることで効率的にケースをカバーするテスト技法です。 データのパターンが多い場合に代表値を使って効率的な検証が求められるテスト項目の設計に有効です。 テストマトリクス（ デシジョンテーブル ） テストマトリクスは デシジョンテーブル とも呼ばれ、複数の入力値や条件の組み合わせを整理しテスト項目を設計するテスト技法です。 複数条件の組み合わせを網羅的に検証する際のテスト項目の設計に有効です。 ユーザーストーリーテスト（シナリオテスト） 実際にシステムを使うユーザーのフローを再現しシステムの動作を確認するテスト技法です。 E2E テストなどテストピラミッドの上位のテストレベルにおいて効果的なテスト項目を設計するにのに有効です。 これらのテスト技法を組み合わせて活用することで、テストレベルに応じたテストケースの設計をスムーズに進めることができます。 テスト カバレッジ の計測と指標の理解 テストの品質を評価するためにテスト カバレッジ の計測が用いられることが多いです。 テスト カバレッジ は、テストケースがテスト対象のプロダクションコード上でどの程度実行されたかを示す指標です。 しかし単に カバレッジ といっても計測方法にはいくつかの種類があり、それぞれ異なる視点からコードの網羅性を評価します。 ここでは一般的に使用される C0、C1、C2 と呼ばれる カバレッジ の計測方法について紹介します。 C0: ステートメント カバレッジ プログラム内の ステートメント （命令）が少なくとも 1 回実行されたかを計測します。 C1: ブランチ カバレッジ プログラム内の条件分岐の各分岐が少なくとも 1 回実行されたかを計測します。 C2: 条件 カバレッジ プログラム内の条件式内の個々の条件が True/False の両方を少なくとも 1 回満たしたかを計測します。 テスト カバレッジ を導入する際には、まずは C1 のブランチ カバレッジ の指標を採用することがおすすめします。 C1 のブランチ カバレッジ は多くのテスティングライブラリでサポートされている計測が簡単です。 また分岐漏れに起因するバグを発見しやすい指標であり、C0 よりも効果的で、C2 よりも現実的なコストで導入が可能です。 また カバレッジ を計測し運用するに当たっては、数値目標に依存しないことが重要です。 テスト カバレッジ の値を単なる数字目標として設定されると、見せかけの カバレッジ 向上のために C0 の指標を採用するなどのハックが行われてしまうことがあります。 重要なのは指標を理解した上で カバレッジ を計測し、 計測時点から カバレッジ を下げないように開発を進めることです。 計測開始から カバレッジ が下がる場合、新機能を追加する際にテストが不足していたり修正や リファクタリング によって既存のテストが削除されていることを意味するからです。 カバレッジ の不足部分から追加すべきテストケースの議論材料として活用しましょう。 まとめ 本記事では、テスタビリティを低くしてしまう事例をベースにテスタビリティを向上させるための方法を紹介しました。 そして実際の 開発プロセス において、それらの方法が価値を発揮するための要素を取り上げました。 チーム全体でこれらのポイントを意識することで、テスタビリティを意識した開発を進められるのではないでしょうか。 本記事で紹介した内容によって、より堅牢で信頼性の高い開発活動への一助となれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 株式会社 電通総研 新卒採用サイト 電通総研グループ キャリア採用サイト：電通総研 執筆： @yamada.y （ Shodo で執筆されました ）

はじめに こんにちは。金融ソリューション事業部エンジニアリングオフィスの加藤です。 仕事でGKEや AKS といったマネージド Kubernetes サービスを利用したインフラ構築を経験してきました。 この記事では、 Raspberry Pi 5で K8s クラスタ を構築しながら、マネージド K8s のありがたみについて学んでいきます。 ゴール 以下の作業を通して、 Kubernetes クラスタ のオンプレ環境における構築手順の全体的な流れと、設計判断のポイントについてざっくり理解する Raspberry Pi をセットアップする Kubernetes クラスタ を作る Prometheus, Grafanaを入れて クラスタ の監視環境をセットアップする Cloudflare tunnelを利用して、セキュアにインターネット経由からのアクセスをできるようにする 構成 Raspberry Pi 5は手元に3台あります。以下の戦略で構築します。 マスター 1, ノード 2　の IPv4 シングルスタックの Kubernetes クラスタ をkubeadmで構築する あとでマスターにもノードを追加できるように、高可用性の構成とする Host Name IP Address Description PC 192.168.3.x 作業用のPC master-1 192.168.3.81 マスター1: Raspberry pi に Ubuntu 24.04 LTS node-1 192.168.3.82 ノード1: Raspberry pi に Ubuntu 24.04 LTS node-2 192.168.3.83 ノード2: Raspberry pi に Ubuntu 24.04 LTS kubernetes -frontend 192.168.3.90 コン トロール プレーンの API サーバ負荷分散のための仮想IP (LoadBalancer Service用) 192.168.3.91-99 Service Type:Loadbalacerで使用するIPレンジ 構成イメージは以下のとおりです。 大まかな流れ 準備: Raspberry Pi を台数分セットアップ Raspberry Pi のセットアップ カーネル の設定 コンテナランタイムの設定 ツールのインストール クラスタの構築 HA構成のAPIServer クラスタ 作成 Nodeの追加 テスト用のPodをデプロイして確認 PrometheusとGrafanaのセットアップ(オプション) kube-prometheus-stack Helmチャートによる簡単なセットアップ インターネット経由でアクセスできるようにする 1. 準備 記事のボリュームの関係上、 Raspberry Pi そのものについての記述は少し端折ります。 Raspberry Pi Imager を利用して、 Ubuntu 24.04 LTSのイメージをSDカードに焼きます。 複数台ありますので、自宅環境の要件を満たすための汎用的な設定はuser-dataに書いた上で起動したりshell スクリプト にしたりすると、セットアップが捗ります。 user-dataのサンプル を一番下に書きましたので、一つの参考としてご参照ください。 環境 SDカードを入れて起動します。以下のようになりました。 # 各種情報確認 $ cat /etc/os-release PRETTY_NAME="Ubuntu 24.04 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo $ uname -a Linux node-1 6.8.0-1004-raspi #4-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 02:29:55 UTC 2024 aarch64 aarch64 カーネル の設定 K8s クラスタ のシステム要件を確認しながら、設定します。 # カーネルの設定 ## カーネルモジュールのロード $ cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF $ sudo modprobe overlay $ sudo modprobe br_netfilter ## カーネルパラメータの設定 $ cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF # 確認 $ sudo sysctl net.bridge.bridge-nf-call-iptables $ sudo sysctl net.bridge.bridge-nf-call-ip6tables $ sudo sysctl net.ipv4.ip_forward $ sudo sysctl --system コンテナランタイムの設定 コンテナランタイム、CNI Pluginを入れていきます。今回は cotainerd + runc の一般的な構成としました。また、コンテナ管理にcgroupを利用するように設定します。 # containerdのインストール $ ARCH="arm64" $ CONTAINERD_VERSION="1.6.32" $ curl -fsSL https://github.com/containerd/containerd/releases/download/v${CONTAINERD_VERSION}/containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz -o containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz $ curl -fsSL https://github.com/containerd/containerd/releases/download/v${CONTAINERD_VERSION}/containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz.sha256sum -o containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz.sha256sum $ sha256sum -c containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz.sha256sum $ sudo tar -C /usr/local -xzvf containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz $ rm containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz containerd-${CONTAINERD_VERSION}-linux-${ARCH}.tar.gz.sha256sum # containerdの設定 $ sudo mkdir -p /etc/containerd $ containerd config default | sudo tee /etc/containerd/config.toml $ curl https://raw.githubusercontent.com/containerd/containerd/main/containerd.service | sudo tee /etc/systemd/system/containerd.service > /dev/null # containerdをサービスとして起動 $ sudo systemctl daemon-reload $ sudo systemctl enable --now containerd $ sudo systemctl status containerd # runcのインストール $ sudo apt-get update -y $ sudo apt-get install -y libseccomp2 gpg $ curl -fsSL https://github.com/opencontainers/runc/raw/main/runc.keyring -o runc.keyring $ gpg --import runc.keyring $ RUNC_VERSION="1.1.12" $ curl -fsSL https://github.com/opencontainers/runc/releases/download/v${RUNC_VERSION}/runc.${ARCH} -o runc $ curl -fsSL https://github.com/opencontainers/runc/releases/download/v${RUNC_VERSION}/runc.${ARCH}.asc -o runc.asc $ gpg --verify runc.asc runc $ sudo install -m 755 runc /usr/local/sbin/runc $ rm runc runc.asc runc.keyring # インストール確認 $ containerd -v $ runc -v # CNI Pluginのインストール $ sudo mkdir -p /opt/cni/bin CNI_VERSION="1.1.1" $ curl -fsSL https://github.com/containernetworking/plugins/releases/download/v${CNI_VERSION}/cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz -o cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz $ curl -fsSL https://github.com/containernetworking/plugins/releases/download/v${CNI_VERSION}/cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz.sha256 -o cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz.sha256 $ sha256sum -c cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz.sha256 $ sudo tar -C /opt/cni/bin -xzvf cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz $ rm cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz cni-plugins-linux-${ARCH}-v${CNI_VERSION}.tgz.sha256 # systemdを利用するようにcontainerdの設定を変更 $ sudo cp /etc/containerd/config.toml /etc/containerd/config.toml.bak $ sudo sed -i '/\[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options\]/,/\[/ s/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml $ diff /etc/containerd/config.toml /etc/containerd/config.toml.bak 127c127 < SystemdCgroup = true --- > SystemdCgroup = false $ sudo systemctl restart containerd # swapをOFFにする $ sudo swapoff -a Kubernetes 関連のツールのインストール 今回は クラスタ の構築に kubeadm を利用するので、 kubeadm をインストールします。その他、 kubelet も必要になるのでインストールしておきます。 kubectl は必要に応じて入れます。 $ sudo apt-get install -y apt-transport-https ca-certificates curl gpg $ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list $ sudo apt-get update -y $ sudo apt-get install -y kubelet kubeadm kubectl $ sudo apt-mark hold kubelet kubeadm kubectl # 確認 $ kubeadm version $ kubectl version --client=true $ kubelet --version 2. クラスタ の構築 今回は以下の戦略とします。 Kubernetes v1.30を入れる 高可用性 クラスタ として構成する ※現時点ではマスターノードは1台だけですが、将来的に追加できるようにするため。途中で変更できないため、 クラスタ 作成時にこの構成にしておく必要があります マスターノード上で以下のように構成する HAProxyでコン トロール プレーンの API Server宛のリク エス トをリバースプロキシする Keepalived で仮想IPを設定する 各ノードのkubelet,kubectlからはこの仮想IPを使用するようにする 上記の名前解決は簡易的にhostsを用いる HA構成のAPIServer まず、 Keepalived をインストールし、固定したIP(今回は192.168.3.90)でアクセスできるように設定します。 #Keepalivedのインストール/設定 $ sudo apt update $ sudo apt install keepalived $ K8S_VIP="192.168.3.90" $ cat <<_EOF_ | sudo tee /etc/keepalived/keepalived.conf vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { ${K8S_VIP} } } _EOF_ # keepalivedを利用するためのカーネルモジュールのロード設定: https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-initial-setup-forwarding-vsa $ echo "net.ipv4.ip_nonlocal_bind = 1" | sudo tee -a /etc/sysctl.d/k8s.conf $ sudo sysctl net.ipv4.ip_nonlocal_bind $ sudo systemctl start keepalived $ sudo systemctl enable keepalived # 確認 $ ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:cf:67:2c:e4:9a brd ff:ff:ff:ff:ff:ff inet 192.168.3.81/24 brd 192.168.3.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.3.90/32 scope global eth0 # ←これができる valid_lft forever preferred_lft forever ...中略... # hostsを編集して名前解決できるようにしておく # /etc/cloud/templates/hosts.debian.tmplは起動時にhostsを生成するテンプレートのため、一旦リブートするか、hostsにも直接書くかどちらが必要 $ cat <<_EOF_ | sudo tee -a /etc/cloud/templates/hosts.debian.tmpl # These entry is for testing keepalived configuration for k8s apiserver ${K8S_VIP} kubernetes-frontend.local _EOF_ 続いて、HAProxyを設定します。 # HAProxyのインストール $ sudo apt update $ sudo apt install haproxy $ sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_bak # frontendにKeepalived, backendに後で作成するKubernetes API Serverを設定 $ cat <<_EOF_ | sudo tee /etc/haproxy/haproxy.cfg global log /dev/log local0 log /dev/log local1 notice user haproxy group haproxy daemon defaults log global mode tcp timeout connect 5000 timeout client 50000 timeout server 50000 frontend kubernetes-frontend bind *:8443 default_backend kubernetes-backend backend kubernetes-backend mode tcp balance roundrobin server master-1 127.0.0.1:6443 check verify none _EOF_ $ sudo systemctl reload haproxy クラスタ 作成 K8s クラスタ を作成し、Podをデプロイできる状態にします。以下のような流れになります。 コン トロール プレーンの設定 Pod Network アドオンの設定 Nodeを クラスタ に追加 MetalLBの設定 テスト用のPodをデプロイして確認 コン トロール プレーンの設定 kubeadm init を使います。コン トロール プレーンの作成は、以下のような処理が行われることで実現しているようです。 # https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#synopsis # 以下の順序で処理される preflight Run pre-flight checks certs Certificate generation /ca Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components /apiserver Generate the certificate for serving the Kubernetes API /apiserver-kubelet-client Generate the certificate for the API server to connect to kubelet /front-proxy-ca Generate the self-signed CA to provision identities for front proxy /front-proxy-client Generate the certificate for the front proxy client /etcd-ca Generate the self-signed CA to provision identities for etcd /etcd-server Generate the certificate for serving etcd /etcd-peer Generate the certificate for etcd nodes to communicate with each other /etcd-healthcheck-client Generate the certificate for liveness probes to healthcheck etcd /apiserver-etcd-client Generate the certificate the apiserver uses to access etcd /sa Generate a private key for signing service account tokens along with its public key kubeconfig Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file /admin Generate a kubeconfig file for the admin to use and for kubeadm itself /super-admin Generate a kubeconfig file for the super-admin /kubelet Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes /controller-manager Generate a kubeconfig file for the controller manager to use /scheduler Generate a kubeconfig file for the scheduler to use etcd Generate static Pod manifest file for local etcd /local Generate the static Pod manifest file for a local, single-node local etcd instance control-plane Generate all static Pod manifest files necessary to establish the control plane /apiserver Generates the kube-apiserver static Pod manifest /controller-manager Generates the kube-controller-manager static Pod manifest /scheduler Generates the kube-scheduler static Pod manifest kubelet-start Write kubelet settings and (re)start the kubelet upload-config Upload the kubeadm and kubelet configuration to a ConfigMap /kubeadm Upload the kubeadm ClusterConfiguration to a ConfigMap /kubelet Upload the kubelet component config to a ConfigMap upload-certs Upload certificates to kubeadm-certs mark-control-plane Mark a node as a control-plane bootstrap-token Generates bootstrap tokens used to join a node to a cluster kubelet-finalize Updates settings relevant to the kubelet after TLS bootstrap /experimental-cert-rotation Enable kubelet client certificate rotation addon Install required addons for passing conformance tests /coredns Install the CoreDNS addon to a Kubernetes cluster /kube-proxy Install the kube-proxy addon to a Kubernetes cluster show-join-command Show the join command for control-plane and worker node kubeadm init を実行する際のオプションは、コマンド引数として渡すか、 yaml で書いて渡すことができます。今回は以下のとおり kubeadm-config.yaml を書きました。デフォルトから変更する設定項目は以下のとおりです。 コン トロール プレーンを高可用性構成にするための controlPlaneEndpoint / apiServer.certSANs Podに割り当てるサブネットを設定するための networking.podSubnet $ cat <<_EOF_ > ~/kubeadm-config.yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: 1.30.0 controlPlaneEndpoint: "kubernetes-frontend.local:8443" apiServer: certSANs: - kubernetes-frontend.local # hostname of keepalived - 192.168.3.90 # VIP of keepalived - master-1.local # hostname of master-1 - 192.168.3.81 # IP of master-1 networking: podSubnet: "10.64.0.0/16" _EOF_ # kubeadm initを実行する # 他のノードを構成する際の手順を簡略化するために `--upload-certs` オプションをオプションを追加 $ sudo kubeadm init \ --config kubeadm-config.yaml \ --upload-certs # 以下が出力されたら完了 Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config Alternatively, if you are the root user, you can run: export KUBECONFIG=/etc/kubernetes/admin.conf You should now deploy a pod network to the cluster. Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/ You can now join any number of the control-plane node running the following command on each as root: kubeadm join kubernetes-frontend.local:8443 --token {token} \ --discovery-token-ca-cert-hash sha256:{discovery-token-ca-cert-hash} \ --control-plane --certificate-key {certificate-key} Please note that the certificate-key gives access to cluster sensitive data, keep it secret! As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use "kubeadm init phase upload-certs --upload-certs" to reload certs afterward. Then you can join any number of worker nodes by running the following on each as root: $ kubeadm join kubernetes-frontend.local:8443 --token {token} \ --discovery-token-ca-cert-hash sha256:{discovery-token-ca-cert-hash} # 完成したらkubectlを使えるようにしておく $ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config $ source <(kubectl completion bash) $ echo "source <(kubectl completion bash)" >> ~/.bashrc Pod Network アドオン この時点では、まだcorednsが起動してきません。Podが動作するようになるには、Pod Network アドオンをインストールします。 Pod Network アドオンは、主に以下のような責務を負う コンポーネント です。 コンテナに対する NIC の設定 IPアドレス の管理、動的割り当て ネットワークポリシーによる分離(Calicoの場合) クロスホスト通信 Pod Network アドオンはCalicoやFlannelなど複数の選択肢がありますが、今回はCalicoを使用します。 現時点で、Calicoは、KubeadmプロジェクトがE2Eテストを行っている唯一のアドオンだそうです 今回はCalicoをオペレータを使ってインストールします。 # Calicoをインストールするためのマニフェストを一旦ダウンロード $ curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml -O $ curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml -O kubeadm init 時と同様、Podサブネットをこちらにも設定する必要があります。 # custom-resource.yaml # クラスタ構築時に指定したPod SubnetのCIDRを指定する # This section includes base Calico installation configuration. # For more information, see: https://docs.tigera.io/calico/latest/reference/installation/api#operator.tigera.io/v1.Installation apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: # Configures Calico networking. calicoNetwork: ipPools: - name: default-ipv4-ippool blockSize: 26 - cidr: 192.168.0.0/16 + cidr: 10.64.0.0/16 $ kubectl create -f tigera-operator.yaml $ kubectl create -f custom-resources.yaml Nodeの追加 クラスタ へのノードの追加は、先ほどの kubeadm init を実行した後に出力されていた内容に従うだけで簡単にできます。 今回はワーカーノードを2台追加します。 # 先に、API Serverの仮想IPに解決されるホスト名をhostsに追記しておく（リブートして反映） $ cat <<_EOF_ | sudo tee -a /etc/cloud/templates/hosts.debian.tmpl # These entry is for testing keepalived configuration for k8s apiserver ${K8S_VIP} kubernetes-frontend.local _EOF_ # kubeadm init時の出力に従ってノードごとに実行 $ sudo kubeadm join kubernetes-frontend.local:8443 --token {token} \ --discovery-token-ca-cert-hash sha256:{discovery-token-ca-cert-hash} # nodeが上がっている $ kubectl get node NAME STATUS ROLES AGE VERSION master-1 Ready control-plane 6d11h v1.30.1 node-1 Ready <none> 6d11h v1.30.1 node-2 Ready <none> 6d11h v1.30.1 # Calicoの状態を確認 # Calicoでは、各ノードがBGPピアリングして経路情報を交換し、L3のレイヤでルーティングする $ sudo ./calicoctl node status Calico process is running. IPv4 BGP status +--------------+-------------------+-------+------------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-------------------+-------+------------+-------------+ | 192.168.3.82 | node-to-node mesh | up | 2024-06-07 | Established | | 192.168.3.83 | node-to-node mesh | up | 2024-06-07 | Established | +--------------+-------------------+-------+------------+-------------+ IPv6 BGP status No IPv6 peers found. MetalLBの設定 オンプレ環境の K8s クラスタ 環境では、Type: LoadBalancer のServiceを公開するためにL4のLBを用意する必要があります。今回はMetalLBをLayer2モードで使用し、また、特定の IPアドレス が自動的にアタッチされるように設定します。 # MetalLBのインストール kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml # ServiceのExternal-IPに割り当てるIPアドレスを設定する cat <<_EOF_ | kubectl apply -f - apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 192.168.3.91-192.168.3.99 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: example namespace: metallb-system _EOF_ テスト用のPodをデプロイして確認 準備ができたので、テスト用のNginxをデプロイし、複数のタイプのService経由で疎通できるかどうかを確認します。 #テスト用Nginx kubectl create deployment test-nginx --image=nginx --replicas 3 kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES test-nginx-56cc9db4bc-26955 1/1 Running 1 (6d19h ago) 34d 10.64.84.143 node-1 <none> <none> test-nginx-56cc9db4bc-67ddw 1/1 Running 1 (6d19h ago) 34d 10.64.247.16 node-2 <none> <none> test-nginx-56cc9db4bc-6gffj 1/1 Running 1 (6d19h ago) 34d 10.64.84.142 node-1 <none> <none> cat <<_EOF_ | kubectl apply -f - # Service type: ClusterIP apiVersion: v1 kind: Service metadata: name: test-nginx-clusterip spec: type: ClusterIP ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: test-nginx --- # Service type: NodePort apiVersion: v1 kind: Service metadata: name: test-nginx-nodeport spec: type: NodePort ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 nodePort: 30080 selector: app: test-nginx --- # Service type: LoadBalancer apiVersion: v1 kind: Service metadata: name: test-nginx-metallb spec: type: LoadBalancer ports: - name: "http-port" protocol: "TCP" port: 8080 targetPort: 80 selector: app: test-nginx _EOF_ Pod / Node / PCなどいろいろな場所から疎通確認してみます # Pod間通信をテストする用のPodを作成 kubectl run test --image=ubuntu -it --rm # From test pod ## -> APIServer curl https://kubernetes/healthz #OK ## -> Type: ClusterIP / NodePort / LoadBalancer curl http://test-nginx-clusterip:8080 #OK curl http://test-nginx-nodeport:8080 #OK curl http://test-nginx-metallb:8080/ #OK # From Node ## -> Type: LoadBalancer curl http:/192.168.3.91:8080/ #OK # From PC ## -> Type: LoadBalancer curl http:/192.168.3.91:8080/ #OK 3. PrometheusとGrafanaのセットアップ kube-prometheus-stack Helmチャートによる簡単なセットアップ 最後に、PrometheusとGrafanaを設定して監視基盤を構築します。 AlertManager、各種Monitor、Ruleなどの他にも、NodeExporter、Grafanaなど必要な コンポーネント がたくさんあるので、今回は一括構築・管理が可能なHelmチャートである kube-prometheus-stack を使います。 ※ いくつか手段 が提供されていますが、設定のカスタマイズや管理をする上ではHelmチャートを使うのが融通が利きそうでした ※ Raspberry Pi 5にもM2. SSD HATが発売されたので、master-1を NFS サーバとしても設定していました。今回、取得した各メトリクスを共有 ディレクト リに保存したくなったのですが・・・ PrometheusはNFSをサポートしていない ようでした。知りませんでした。 # https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # GrafanaダッシュボードとPrometheusのUIはPort-ForwardなしでPCから確認したいので、ServiceのTypeを変更 cat <<_EOF_ > values.yaml prometheus: service: type: LoadBalancer grafana: service: type: LoadBalancer _EOF_ # monitoring Namespaceを作ってそこにデプロイ kubectl create ns monitoring helm install prom-stack prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml ダッシュ ボードは初期の状態でたくさん設定されていますが、追加で、 Raspberry Pi & Docker Monitoring というのを入れてみました。 Raspberry Pi は温度を気にしたくなりますので、良い感じに表示されていて嬉しいです。 インターネット経由のアクセス (オプション) この K8s クラスタ のメンテナンスを外出時にもしたい、Grafana ダッシュ ボードを外出先からも確認したい、となった場合、どのようにすれば良いでしょうか。 Cloudflare を使ってみて、非常に体験が良かったので最後に紹介します。 簡単にいうと、オンプレ側のマシンにcloudflaredをインストールして、そこからCloudflareが管理するエッジ環境に対してトンネルを張り、その経路を利用してセキュアに通信できる、かつその仕組みを利用する際、認証機能、 サブドメイン 用の自動証明書管理、セキュリティを維持するための各種機能も提供されているというものです。自分の ドメイン さえ持っていれば、今回の用途では無料で利用できます。 Cloudflare Tunnel の作成 UIでの作成方法 に従うと、簡単に設定できます。 cloudflaredは、すべてのサーバに入れる必要はなく、トンネルを作成したいマシンに対して入れれば足ります。残りの設定はUIから行っていきます(今回はmaster-1に入れました) Public Hostname（ サブドメイン として利用できるHostnameになります）とService(ローカル側からアクセス可能なIP/ポートの組み合わせ)を関連付けます。今回はGrafana ダッシュ ボードと、 SSH アクセスを有効にしたいので、以下をサービスとして登録し、それぞれに対して サブドメイン を割り当てました。 http://prom-stack-grafana.monitoring.svc.cluster.local:80 ssh://localhost:22 Application の設定 上記で設定したPublic　Hostnameに対して、アクセスポリシー、認証の設定などを有効化できます。 自分のメールアドレスだけアクセスできるようにしつつ、パスワードをメール ワンタイムパスワード に設定しました。 Browser SSH タイプでApplication設定を作成すると、ブラウザ上でターミナルが表示されます。 まとめ Raspberry Pi で K8s クラスタ ーを作ってみました。これから育てていきます HA構成や家庭のLAN環境特有の問題に対処することで、L2/L3周りの学びを得る機会になりました オンプレ Kubernetes を業務運用する際の難易度の高さを改めて実感しました(N/W、マシン、ストレージ、可用性・信頼性の確保、継続的な改善とメンテナンス、大規模運用・・・) Cloudflareはもっと色々な用途に使ってみたいです user-data 　のサンプル 初期設定系はすべてこちらに突っ込みたくなりますが、うまくいかない時の デバッグ が難しいので、簡単な最低限の設定項目だけをuser-dataに、それ以外は スクリプト を書くなどして初回起動後に実行する方が個人的には好きです。 #cloud-config hostname: { HOST_NAME } # Configured by Raspberry Pi Imager manage_etc_hosts: true +package_update: true +package_upgrade: true packages: - avahi-daemon + - libseccomp2 + - gpg + - apt-transport-https + - ca-certificates + - curl + - raspi-config apt: ...中略... users: ...中略... +write_files: + # Configure IP Addrress Fixation + - path: /etc/netplan/99_manual_config.yaml + owner: root:root + permissions: "0600" + content: | + network: + version: 2 + ethernets: + eth0: + dhcp4: true + addresses: + - 192.168.3.83/24 + nameservers: + addresses: + - 192.168.3.1 runcmd: - localectl set-x11-keymap "us" pc105 - setupcon -k --force || true + - netplan apply + - | + cat <<_EOF_ | tee -a /etc/cloud/templates/hosts.debian.tmpl + # These entry is for testing keepalived configuration for k8s apiserver + 192.168.3.90 kubernetes-frontend.local + + _EOF_ 参考 kubeadmを使用したクラスターの作成 Pod Networking kubeadm kubeadm: High Availability Considerations containerd Install Calico networking and network policy for on-premises deployments CalicoによるKubernetesピュアL3ネットワーキング MetalLB 執筆： @kato.shota 、レビュー： @kobayashi.hinami （ Shodo で執筆されました ）

はじめまして、X（クロス） イノベーション 本部プロダクト イノベーション センターの瀧川亮弘です。 本記事は、 電通総研 Advent Calendar 2024 10日目の投稿です。 もともとネイティブアプリを主戦場とするFlutterですが、Web開発にどれほど活用できるのか調査したため共有します。 Flutter とは Flutter for Web とは Flutter for Web の注意点 注意点1. ネイティブアプリがメインターゲット 注意点2. 実装言語がDartに限定される 注意点3. SEOに弱い 注意点4. 初期ロードが重い 対策方法 Flutter for Web の使いどころ 終わりに Flutter とは Flutterは、2017年に Google が発表した オープンソース のUI開発 フレームワーク です。 プログラミング言語 には コンパイル 型の Dart を採用しており、高いパフォーマンスと開発効率を実現しています。 単一のコードベースから iOS 、 Android 、デスクトップ、Webといった 複数のプラットフォーム向けにアプリを開発できる点が特徴 です。 また、 マテリアルデザイン に準拠した多彩な ウィジェット （部品）が標準で提供されており、美しく直感的なUIを比較的簡単に作成できます。 Flutter for Web とは Flutterは当初、 iOS および Android 向けのネイティブ アプリ開発 をターゲットとしてスタートしましたが、現在ではデスクトップやWebにも対応しています。 ここではFlutterによるWeb アプリ開発 のことを Flutter for Web と呼びます。 Flutter for Web は、モバイルアプリやデスクトップアプリと 同じコードでWebアプリも一緒に開発したい という場合に便利です。 コストや開発期間を削減できるだけでなく、 プラットフォーム間でのUIの差異を最小限に抑える こともできます。 また、Webアプリのパフォーマンス向上のためにWebAssembly（Wasm）へのビルドもサポートされています。 Flutter for Web の注意点 FlutterでWebアプリを開発する場合、以下のような注意点があります。 注意点1. ネイティブアプリがメインターゲット Web向けのサポートも進んでいるものの、モバイル向けと比較するとやはり劣る部分があります。 たとえば、モバイル向けパッケージにはWeb非対応なものが多く、Web対応であっても、 Web専用の機能改善やバグ修正は劣後となる傾向 にあります。 また、ネイティブ アプリ開発 では Hot Reload が利用可能ですが、Web開発では Hot Restart しか利用できず、開発体験が落ちます。 Hot Reload：アプリを停止せずにコード変更を即座に反映する。状態が保持される。 Hot Restart：アプリを再起動してコード変更を反映する。状態はリセットされる。 注意点2. 実装言語が Dart に限定される 通常のWeb技術（HTML, CSS , JavaScript ）と異なり、 全てのロジックやUIを Dart のみで実装する必要があるため、実装難易度が高い です。 また、 サードパーティ の JavaScript ライブラリを型安全に利用したい場合、 Dart 側で独自に型定義を行う必要があります。 TypeScriptのように標準で豊富な型定義が存在しない点も、開発のハードルを上げる要因のひとつです。 注意点3. SEO に弱い Flutterはシングルページアプリケーション（SPA）の構成を採用しており、初期ロード後にクライアント側で動的にDOMを生成します。 標準ではサーバーサイド レンダリング （ SSR ）やマルチページアプリケーション（ MPA ）に対応していないため、 検索エンジン のクロールやインデックスが難しくなり、 SEO に弱くなります 。 さらに、 Canvas による画面描画では、 検索エンジン による解析が困難となります。これも SEO に弱くなる要因のひとつです。 また、スクリーンリーダーによる読み上げも困難となるため、 アクセシビリティ の低下にもつながります。 注意点4. 初期ロードが重い Flutterでは ビルド時に比較的大きなファイルが生成されるため、初期ロードが重くなります 。 空のプロジェクトでも数MBになり、ページ数や機能が増えるとさらに肥大化します。 標準ではNext.jsのような自動コード分割機能も備わっていないため、ユーザー操作とは関係のない画面ソースもブラウザにダウンロードする必要があり、非効率です。 対策方法 いくつか対策方法はあります。 Webサーバーで gzip 圧縮を行い、転送時のファイルサイズを小さくする。 ユーザー操作に応じて必要最小限のライブラリを遅延ロードする。 手動でコード分割を行い、画面単位で必要最小限のファイルを取得する。 根本解決ではありませんが、初期ロード時にローディングアニメーションを表示してユーザー体験を改善する。 Flutter for Web の使いどころ 一般的なWeb開発には従来のWeb技術（HTML、 CSS 、 JavaScript など）を用いるのが望ましいです。 しかし、モバイルアプリやデスクトップアプリと同じコードベースでWebアプリも開発する必要がある場合、本記事で紹介した注意点を認識したうえでFlutterを選択するのが良いでしょう。 終わりに 最後までご覧いただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 株式会社 電通総研 新卒採用サイト 電通総研グループ キャリア採用サイト：電通総研 執筆： @takigawa.akihiro 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは！ X（クロス） イノベーション 本部 プロダクト イノベーション センターの佐藤です。 電通総研 Advent Calendar 2024 、12日目の今日は、DRY 原則の再解釈を通して、設計上の落とし穴である「誤った共 通化 」に陥らないためにはどうするべきかを考察していきたいと思います。 本稿は、設計の世界に足を踏み入れたばかりの方から鍛え抜かれた達人 プログラマー まで、幅広い方々に気づきを提供できるような内容を目指しました。 初学者の方は手元に参考書を、達人の方はくつろぎのコーヒーを携えながら、気軽にお読みいただければ幸いです。 DRY SRP 再び、DRY 誤った共通化 DRY をコードで捉えない まとめ 参考文献 DRY DRY 原則は、プログラミングや設計の初学者が最初期に学ぶ考えだと思います。 そして、それはしばしば 「 コピペ をしてはいけない」「 同じコード を繰り返し重複して書いてはいけない」 といった説明がなされることから、「DRY 原則は コードそれ自体 を対象とする」と理解されている方々は決して少なくないのではないでしょうか。 しかし、筆者としては「この理解は、ともすれば誤解につながるケースが多いのではないか」と考えています。 実は、DRY 原則を世に広めた名著 達人プログラマー の第2版においても、この点について言及されています。 本書の初版では、「DRY 原則」が意味することについて書き足りない部分がありました。多くの人々はこれがコードの話だと受け取ってしまったのです。つまり、DRY を「 ソースコード のコピー＆ペーストをしてはいけない」と解釈してしまったのです。 これも DRY 原則の一部ですが、ほんの些細な一部でしかありません。 [1], p.40 確かに、コードのコピペや繰り返しが好ましくない結果をもたらす可能性があることは事実です。 しかし、この「コード」に着眼した理解は、その分かり易さがゆえに 「であれば、同じコードは 共 通化 しよう 」 といった拡大解釈を招いている可能性が、一定以上あるように思います。 達人 プログラマー は以下のように続けます。 DRY 原則は「知識」や「意図」の二重化についての原則です。 [1], p.40 本記事では、この忘れ去られがちな DRY の本質について「知識」や「意図」とは別のもう一つの観点、「 責任 」の観点から捉え直してみたいのです。 SRP ここで一度 DRY から離れて、SOLID 原則のイニシャルを務める、SRP（単一責任の原則） を思い出してみます。 クラスを変更する理由は１つ以上存在してはならない。 [2], p.122 ここではクラスと書かれていますが、設計思想としてはクラスに限ったことではありません。 なぜ、1つ以上（厳密には2つ以上ですが、ここでは引用元の訳に倣います）存在してはいけないのでしょうか。 それは、設計に硬さと脆さを与えることにつながるからです。 エンティティ （本記事では、メソッド、クラス、モジュール、 コンポーネント といったシステムの構成要素を意味します）が独立した複数の責任を担っている時、ほとんどの場合において、そのエンティティを 変更する理由もまた、責任ごとに独立して生じます 。 すると、ある責任に関する変更により他の責任が意図せず果たせなくなり、予想外の欠陥が発生する（＝脆さ）可能性があります。そして、往々にしてこのような実装は変更し辛い（＝硬さ）ものです。 一般に、責任と変更理由は対応します。 アジャイルソフトウェア開発の奥義 （以下、奥義本） は、そこに一つ「役割」という概念も合わせて、SRP における言葉を以下のように定義しています。 役割（責任）＝ 変更理由 [2], p.123 再び、DRY 奥義本は、「腐敗するソフトウェアの兆候」の一つ「不必要な繰り返し」について、以下のように説明しています。 システム内に重複するコードがあると、システムの変更はとても骨の折れる作業になる。[...] コード中にある同じような部分をすべて修正しなければならないからだ。 [2], p.111 また、 プリンシプル オブ プログラミング にも、DRY を適用すべき理由として同様のことが記載されています。 同じようなコードが複数あると、その複数箇所を正確に修正しなければ、全体としての整合が取れません。慎重に作業しないと、修正漏れの危険性があります。 [3], p.50 これら、DRY 適用の動機（＝DRYを破った場合の問題）から逆算すると、そこには「それらが同じ 変更理由 である」という前提が浮かび上がってきます。 すなわち、DRY とは「同じ理由で変更されてしまうエンティティは、重複して存在するべきではない」と説明されるのが、より適切ではないでしょうか。 筆者は、ここであえて飛躍してコードをエンティティと言い換えましたが、なぜコードという記述を避けるのかについては後述します。 奥義本は、SRP における言葉を以下のように定義しています。 役割（責任）＝ 変更理由 [2], p.123 これは、重要さを伝えるための意図的な繰り返しです。 DRY と SRP の間に、 責任 を軸とした関連を見出だせる気がします。 誤った共 通化 SRP と DRY。 この二つの原則は、いずれも設計における構成要素としてのエンティティについて、責任の観点から、その凝集性と一意性を論ずるものだと言えます。 SRPは エンティティは単一の責任を担うべきである ということを説いています。 一方で DRY は 同じ責任を担うエンティティを重複して定義すべきでない（繰り返してはならない） と説いています。 DRY の表層だけを捉え、責任の考慮なしに安易な共 通化 に走ると、それは SRP に違反しかねません 。 共 通化 されるエンティティは、SRP に準拠、すなわち単一の責任のみを担っている必要があります。そして本来、責任というのは意図的な設計のうえに見出され与えられるものです。 したがって、「ここはこの前実装したロジックと（コード的に）同じだから、メソッドに切り出して双方から使おう」といった後づけの共 通化 や再利用は、高確率で失敗すると思われます。 EC サービスを例に考えてみましょう。 このサービスには会員限定割引が存在し、その割引率の計算について責任を担う calcMemberDiscountRate メソッドが存在するとします。その計算ロジックの一部が、後から実装される クリスマスセール 割引率計算ロジックと偶然にも重複することが分かりました。 この時、 calcMemberDiscountRate メソッドの該当コードをコピペして、 calcXmasDiscountRate メソッドを実装することは、果たして悪でしょうか。 むしろ「それは DRY に違反している」として共 通化 された場合に誕生する calcMemberAndXmasDiscountRate メソッドの方が、よっぽど恐ろしく感じられます。 これは説明のための極端な例に過ぎません。実際にはもっと巧妙に、例えばそれらしい抽象的な名前を隠れ蓑にして、複数の責任を担うエンティティが人知れず実装されるのです。 DRY をコードで捉えない 前節では、DRY を以下のように捉えました。 同じ責任を担うエンティティを重複して定義すべきでない（繰り返してはならない） ところで、 オブジェクト指向 の世界において、責任を担えるエンティティの最小単位は何でしょうか。 レガシーコードからの脱却 に、以下のような記載があります。 デジタルの領域では、ものごとはラベルによって定義されるのではなく、ふるまいによって定義されるのである。 [4], p.144 これは、凝集性の文脈におけるオブジェクト（クラス）に関する説明ではありますが、この「ふるまい」（いわばインターフェース）こそ責任の基本であり、その最小単位はメソッドではないでしょうか。 だとすれば、そもそもそれ以下のコード断片については、実装の詳細のそのまた一部である可能性が高く、そういった責任の伴わない単なる欠片としてのコードについては、DRY 適用を論ずるには時期尚早だとも思えるのです。これが、「再び、DRY」節にてコードをエンティティと言い換えた理由であり、そのようなコードのコピペの良し悪しは、その断片だけからは判断が難しいでしょう。 前節で述べたような誤った共 通化 に陥らないためには、常に責任の観点から DRY を捉え、以下のように自問自答することが有効です。 「今、自分が実装しているこのエンティティの責任は、既にほかのエンティティが担ってくれていないか、あるいは他にこの責務の適任者はいないだろうか」 そして、特に何かを共 通化 し始めようという時には、まずは一呼吸おいて、そのエンティティが担う責任を注意深く観察し、隠れ蓑をまとった意図しない責任（変更理由）がいないかを、慎重に確認することが重要だと言えるでしょう。 まとめ 本記事では、DRY 原則の本質を SRP における責任の観点から紐解き、誤った共 通化 に陥らないための新たな DRY 原則の捉え方を検討しました。 設計原則は奥深く、たとえ表面上は単純なルールのように思えても、深く検討することで新しい気づきや解釈を与えてくれます。 本記事の解説が、皆様が今後取り組む設計やコーディングの一助となれば、嬉しい限りです。 参考文献 [1] David Thomas 他, 村上訳. 達人 プログラマー 第2版 熟達に向けたあなたの旅. オーム社 , 2020. [2] Robert C. Martin 他, 瀬谷訳. アジャイル ソフトウェア開発の奥義 第2版 オブジェクト指向 開発の神髄と匠の技. SBクリエイティブ 株式会社, 2008. [3] 上田勲. プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則. 株式会社 秀和システム , Kindle 版. [4] David Scott Bernstein, 吉羽 他 訳. レガシーコードからの脱却 ソフトウェアの寿命を延ばし価値を高める9つのプ ラク ティス. 株式会社 オライリー・ジャパン , 2019. ※ 本稿に掲載された画像は AI により生成されました 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研グループ キャリア採用サイト：電通総研 執筆： @satorin 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは、 電通 総研の金子大地です。 本記事は 電通総研 Advent Calendar 2024 の12月11日の記事です！ 前編 に引き続き、今回も学生さんに読んでいただくことを想定して、実プロジェクトを進める「現場」で行っているPM育成活動について投稿します。もちろん、 電通 総研に興味のある社会人の方も大歓迎です。 前編では以下を説明しました。 電通 総研にはプロジェクトマネージャー（以降、「PM」）を育成する文化があること 会社全体での取り組みのほか、開発の現場でPM育成活動が行われていること 私自身がその活動をしたこと 今回の後編では、私が資料化して社内共有した「PMノウハウ」 の概要と、PMに求められるスキルを紹介します。 1. 私が社内で共有した「PMノウハウ」の概要 1-1. PMの役割 1-2. マスタースケジュール・成果物体系 1-3. PM活動の難所 1-4. その他 2. PMに求められるスキル 2-1. タレント・トライアングル 2-2. 私の考える「PMに求められるスキル」 ①踏み出す力 ②言語化能力 ③論理的思考能力 ④言葉のキャッチボール能力 ⑤もう一歩踏み込む力 おわりに 1. 私が社内で共有した「PMノウハウ」の概要 私がどのような「PMノウハウ」を資料化して所属部署（コミュニケーションIT事業部）に共有した、テーマ別の概要を一部紹介します。具体的なノウハウそのものには触れませんが、"どのようなことが書いてあるか" のイメージは沸くでしょうか。 1-1. PMの役割 「1-2」以降の説明の前提となる、一般的な用語や 電通 総研に特有の情報を資料化しました。 ちなみに、 電通 総研では「いわゆるPM作業」に留まらず、業務・ITスキルの領域に深く踏み込むPMが多い印象です。私は「業務 スペシャ リスト → PM」というキャリアを歩んだこともあり、「業務に強いPMスタイル」と言えるかもしれません。プロジェクト規模・体制にはよりますが、PMを担当しつつ、私自身が設計書の作成・レビューも行うことが多々あります。 ※ ちなみにここで言う「業務に強い」というのは、下記を意味しています。 顧客業務の内容・背景・意図を早期に理解して、プロジェクトメンバーと技術リスク・持っていきたい方向性などを認識合せし、顧客と仕様調整して設計に落とし込むスキルがある 上記をふまえたテスト・移行の方針策定、および テスト設計・移行設計ができる ※ 電通総研の社員紹介ページ も、ぜひご参照ください。 ＜コンテンツ概要＞ PMとは　※ 前編 をご参照ください 電通 総研におけるPMに至るキャリア 電通 総研では入社後からPMに至るまで、どのようなキャリアを歩むことが多いか。 プロジェクト体制の組み方 社内・パートナー会社さんのメンバーを集めて、どのように体制を組むか。 PMの具体的な作業内容 PMが担当する成果物・作業のラインナップと、PMと各メンバー（チームリーダー等）との役割分担。 例）要件定義工程では、「マスタースケジュール、テスト計画書、移行計画書」をPMが作成する。 1-2. マスタースケジュール・成果物体系 プロジェクト個別の事情を考慮してスケジューリングをします。そして、各工程（要件定義・設計・テスト・移行等）で何を成果物とするかを定め、計画的に作業を進めます。 ＜コンテンツ概要＞ マスタースケジュールの作成方法 マスタースケジュールは、プロジェクトの全体スケジュールのこと。 大きいレベルでのスケジュール管理をマスタースケジュールで行い、詳細作業（数100～1,000程度がよく見られる）を「 WBS （Work Breakdown Structure）」で管理する。 作成のためのテクニックはあれど、一番大事なことは「開始から終了まで、このスケジュールで進められそう」という感覚を持てるまで考え抜き、それをスケジュールに反映すること。 成果物体系の作成方法 成果物体系は、各工程の成果物を洗い出し、成果物間の関係性を示すもの。 基本的には、「その工程で何を作成すれば、 ステークホルダー 間で必要な認識合せができ、後続工程のインプットが完成するか」を考える。 1-3. PM活動の難所 私が難しいと思うPM作業に、「要件定義」・「テスト計画」・「移行計画」があります。若手PMはまずこの3つの壁にぶち当たるので、その壁を乗り越え易くするためのノウハウをまとめました。実務経験が無いと理解しづらい内容なので、ここでは簡易な説明に留めます。 ＜コンテンツ概要＞ 要件定義の進め方 要件定義の「開始前準備・実施中・終盤」それぞれの進め方 例えば「終盤」では、”スコープ定義” という大事なプロセスの進め方を紹介 テスト計画・移行計画の作成方法 計画段階で決めるべきことや、決めるための考え方。 移行タイムチャートの作成方法 お客様・ 電通 総研・その他 ステークホルダー （関係ベンダーさん等）の各移行作業の前後関係をどのように整理してタイムスケジュールに落とし込むか。 ※ 移行とは プロジェクトで開発・テストしてきたプログラムや準備したデータ等を、システムの本番環境に反映する作業のことです。本番移行が完了すると、開発してきた新規機能をエンドユーザが利用できるようになります。 本番移行は限られた時間内に完了させる必要があるため、あらかじめ各作業の前後関係を明確化したタイムチャートを作成して作業の予定・実績時刻を管理します。また、本番移行前に移行リハーサルをして、作業手順や移行データに不備が無いかチェックし、作業時間を計測することで、本番移行を時間通り正確に進められるようにします。 1-4. その他 工程共通のPM活動である「コミュニケーション管理」・「課題管理」・「ドキュメント管理」や、本稼働後の「保守運用」、PMが関わる「契約・手続」についてもノウハウを整理しました。ここでは説明を割愛します。 2. PMに求められるスキル 2-1. タレント・トライアングル PMに求められるスキルは、PMI（Project Management Institute）、IPMA（International Project Management Association）、 IPA （ 情報処理推進機構 ）等のPMに関する団体が定義しています。例えばPMIでは、「プロジェクトマネジメントに携わる人にとっての理想的なスキルセット」として、 タレント・トライアングル を提唱しています。 私が行ったPM育成活動は、 暗黙知 だった「Ways of Working」および「Power Skills」を実践的な 形式知 にし、それらをメンタリングにより強化する活動、という位置付けでした。 トライアングル要素 説明 Ways of Working プロジェクト管理手法などのPMに関するテクニカルスキル。 Power Skills リーダーシップなどのヒューマン系のスキル。ソフトスキルと呼ばれることもある。 Business Acumen ビジネス感覚や業務知識。 ※ PMIのページから画像を引用しています 2-2. 私の考える「PMに求められるスキル」 さて、ここからは「イチ現場担当者（私個人）の意見」として捉えてください。 電通 総研の新卒採用の方針とすり合わせなどはしていません。 以下のとおり、PMに求められるスキルの1つである「Power Skills」について、学生さんに伝わる言葉で表現することにトライしてみました。 大前提として①が必要であり、そのうえで②③④が求められます。さらに⑤を発揮することで、もうイチ段高い②③④が発揮される、と考えています。なお、②③を除き、一般用語ではありませんのでご注意ください。 では、それぞれのスキルがどういうものかを見ていきましょう。 ①踏み出す力 自分が分からないこと・未経験のことを「やってみる力」、未知のことに「飛び込む力」、案件・組織等の「壁を越える力」です。明るく前向きであろうとするマインドや、できない理由を探すのではなくどうやったらできるかを考える思考特性が重要です。 入社後はぜひ、所属の「部」という枠組みを超えて知り合いを増やし、話しやすい関係性を築きましょう。それが、“会社には味方がたくさんいる” という気持ちに繋がり、「踏み出す力」への追い風となります。 ② 言語化 能力 事実・自分の考えを、プラス・マイナス無く、ありのまま・誤解なく伝える力です。文章・口頭説明のいずれにも求められます。日常でも「説明が難しいこと」はあると思いますが、諦めずに 言語化 に取り組んでみてください。また、判断が分かれる話題になった時に、「自分は〇〇がいいと思う。なぜならば△△だから」というように、自分の考えを明確にしてください。それがこの力の強化に繋がります。 ③論理的思考能力 前提・事実・考え 等を、分かりやすく組立てて説明する力です。例えば、お客様との限られた会議時間で様々なテーマを扱いますので、急に「〇〇ですか？」と問いかけても、「何の話？」と言われてしまいます。したがって、情報を整理して筋道立てて認識合せする必要があります。 論理的思考能力は、他のスキルよりも書籍・研修が多く存在するため、業務外でも学びやすいと言えるでしょう。 ④言葉のキャッチボール能力 相手の理解度を確認しながら話したり、相手の質問を理解して噛み合った返答をしたりする力です。会議前の準備段階で考え抜き、「こう説明したらこういう意見が出てきそうだな」と想定問答を考えておくことで、短時間に有意義なコミュニケーションを取れます。 ちなみに、コロナ禍を経てリモート会議が増え、相手の表情が読み取れなくなったので、「ここまでの説明でご不明点・ご意見などはありますか」といった意識的な問い掛けで理解度を確認する重要性が高まりました。 ⑤もう一歩踏み込む力 「答えらしきモノ」を得た安堵・小さな達成感を乗り越えて、あるいは会話に登場した「思考停止ワード」で止まらずに、もうイチ段階 深掘り、具体化して、考え・話し・聞く力です。例えば「お客様に確認して得られた回答に基づき、後続作業（例. 設計作業）を進められるか」を考え、不足があればさらに踏み込んで確認します。 必要なことを突き詰める・深掘りする「粘り強さ」とも言えそうですね。スキルというより、行動特性と呼べるかもしれません。 おわりに 前編 ・後編を読んでいただき、「PM」という仕事の解像度が少し上がったでしょうか。また、「PM」をやってみたくなりましたか。 誰しも、初めてPMを担当する時は不安がいっぱいです。でも、 電通 総研には勉強する材料はたくさんありますし、フォローしてくれる先輩もたくさんいます。お客様に説明予定の資料に不備があれば、事前にチェックして改善できるよう寄り添ってくれることでしょう。お客様への説明が言葉足らずならば、あなたの横にいる先輩が「補足ですが、・・」とフォローしてくれることでしょう。 PMという仕事は簡単ではありませんが、だからこそやりがいがあり達成感を得られる仕事だと思います。 私は、方針・計画・仕様等の合意形成の舵取りをしてプロジェクトを推進していくという、「大きなものを動かす感覚」を持てることに、PMとしてのやりがいを感じます。様々な作業における進め方の自由度が高いので、自分の考えを詰め込んだ ”たたき台" で道を切り拓き、関係者と認識を合わせて、慎重にまたは大胆に進めるプロセスは "腕の見せ所" と思って取組んでいます。そして、お客様との協同作業をスムーズに進められた時、課題が解決した時、システムが無事にサービスインした時、メンバーに感謝しながら達成感を噛み締めます。 電通 総研でPMをやってみたいと思った方は、ぜひ下記もご参照ください。 私たちは同じ事業部で共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社 電通総研 新卒採用サイト 株式会社 電通総研 キャリア採用サイト 執筆： @kaneko.taichi 、レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）