はじめに 情報系の学部出身ではないですが、二ヶ月で基本情報処理技術者試験を合格できました！今回は合格までの道のりを記録としてまとめさせていただきます。 これから基本情報処理技術者試験にチャレンジするぞ！という方の参考になればと思います。 プロフィール 新社会人(2023年4月入社) デザイン系の学部の為ITは未学習 インターンなどでプログラミングをしていたのでコードは多少書けるレベル 受験のきっかけ 正直なところプログラミング経験には多少自信があったのですが…入社してすぐ、ITの基礎研修にて事件が起こりました… “ IT用語が全く分からないんです…! (プロトコル? ファイアウォール? 何の話…?)“ さすがにまずいと思い、研修期間中に受けると受けると決めていた 基本情報技術者試験 で最低限のITスキルを付けようと考え、本格的に勉強を始めました。 試験概要 基本情報処理技術者試験とは 情報処理技術者試験は、「情報処理の促進に関する法律」に基づき経済産業省が、情報処理技術者としての「知識・技能」が一定以上の水準であることを認定している国家試験です。 （ https://cbt-s.com/examinee/examination/fe より） エンジニアとして基礎的な知識を問う試験になります。 試験概要 A問題・B問題ともに パソコンを用いたマークシート方式(CBT方式)です。 科目A 試験時間: 90分 内容: テクノロジ系・マネジメント系・ストラテジ系の3分野から四択でそれぞれ出題されます。 問題数: 60問 (テクノロジ系: 41問、マネジメント系: 7問、ストラテジ系: 12問) 科目B 試験時間: 100分 内容: アルゴリズム・プログラミングとセキュリティーの2分野から問題が出題されます。アルゴリズム・プログラミング分野は、疑似言語を用いた出題になります。 問題数: 20問 (アルゴリズム・プログラミング分野: 16問、セキュリティー: 4問) 難易度 合格要件として、A問題 B問題ともに600/1000点を超える必要があります。 受験者数 合格者数 合格率 R2秋季 52993人 25499人 48.1% R3春季 32238人 13522人 41.9% R3秋季 52831人 21167人 40.1% 新制度移行前は、23~25%程度でしたが、新制度移行後に合格率が上がりました！合格率は40％台に上昇したので少し易化しているのかもしれません！ 勉強をした感じ、指定の範囲を繰り返し学習すれば短期間での合格が可能だと思います！ 情報学部の方は、A問題も少し学習すれば合格点に達すると思います！ プログラミング経験者の方は、B問題も問題の解き方や流れも十分に練習すれば合格点に達すると思います！ ※あくまで体感です 勉強方法 全体スケジュール 試験の2か月前から、本格的に勉強を開始しました。 最初の二週間は、IT初学者向けの動画を視聴して、ITの基礎を学習しました。 デジ戦ではUdemyのアカウントを1人1つ付与しているためUdemyの動画での学習です。 そのあとに、基本情報処理技術者試験対策の動画と過去問道場を並行し、午前対策を行いました。 試験から3週間ほど前から午後問題対策の動画を視聴し、問題演習を行いました！ 結果 結果としては、 午前問題: 805/1000 午後問題: 840/1000 と元々、ITの基礎知識はありませんでしたが合格することができました！ 次に対策方法を見ていきます！ 基本情報処理技術者試験 A問題(午前問題)対策 Udemy動画教材① ～始めから効率よく学ぶ～ 基本情報技術者試験 最速 合格講座 ITの基礎知識を学習すべく、最初に学んだ講座です！ 基礎理論〜セキュリティーなどのテクノロジー分野全般 + B問題を学習することができます！ IT全般のイメージを持つのにとても役立つのでおすすめです！僕は、テクノロジー系の動画を受講しました。動画も一分野1時間ほどで見れます！ ですが、午前問題で更に高得点を取るためにもう1講座受講しました。 https://www.udemy.com/course/lerning-fe Udemy動画教材② 現役講師が教える【基本情報技術者試験　科目A】講座 Udemy動画教材①よりもより実践的な内容を学べるのが、「現役講師が教える【基本情報技術者試験　科目A】講座」です。 動画の中で理論の解説・実際の過去問の演習を行うような形になります。 動画の中で実際の問題のイメージをつけることができるのでこの講座を学習すれば、もう過去問に入っても大丈夫だと思います！ https://www.udemy.com/course/kihon_joho 基本情報技術者過去問道場 実際に動画教材や本で学んだら次は実践です。動画で学んだ範囲の過去問を「基本情報技術者過去問道場」で学習します。 自分は全範囲全問題を演習したのですが、演習してみて75％ほど正答できていれば、その範囲に関しては追加で過去数年分の問題を演習すれば十分だと思います。 https://www.fe-siken.com/fekakomon.php IPA公式 サンプル問題 IPA公式からも2023年改定後のサンプル問題が出題されています。問題自体の基本的な変更はありませんが、問題の難易度をつかんでおくにはとても有用な問題だと思います。 https://www.ipa.go.jp/shiken/syllabus/henkou/2022/20221226.html 基本情報処理技術者試験 B問題(午後問題)対策 Udemy動画教材③ 現役講師が教える【基本情報技術者試験　科目B】科目B対策専門コース Udemy動画教材②の講師の方が解説されている午後問題対策講座、「現役講師が教える【基本情報技術者試験　科目B】Javaプログラミング言語を使った、科目B対策専門コース」です。 こちらの問題は午後問題のために必要な考え方や例題演習と解説を行ってくれるような教材です。 新方式に移行して問題がだいぶ変更になっていますが、まだ過去問や対策問題が少ないためこの教材の中に含まれている類題はとても勉強になりました。おすすめです。 https://www.udemy.com/course/kihon_joho_b IPA公式 サンプル問題 B問題に関しても、IPA公式から2023年改定後のサンプル問題が出題されています。一回分(20問) と 6問がサンプル問題として、公開されているので必須で解きたい内容になります！ https://www.ipa.go.jp/shiken/syllabus/henkou/2022/20221226.html まとめ 基本情報を勉強して良かったこと 基本情報を勉強してみて、幅広いITに触れることができました。当初、「IT用語が全く分からない」という不安が解消されて、研修・業務中に出てくる単語も基本情報処理技術者で勉強したから理解が出来る！ということが増えたので間違いなく資格を取得して良かったです。 　 おわりに 以上が、自分の基本情報処理技術者の合格体験記になります！ まだまだ未熟ですが、取得した基本情報を活かして今後の業務に取り組んで行きます！ ITの基礎的な知識を習得されたい方はぜひ挑戦してみてください！ 最後までご覧いただきありがとうございました！

はじめに はじめまして！2023年度新入社員K.NとM.Mです。 今回のブログでは、2023年度新入社員研修の中で行った「研修運営」について紹介したいと思います。 研修運営って何？なんでやるの？という説明から、実際に経験した新入社員との座談会の様子をまとめていきます！ ▼研修カリキュラムの詳細については別記事にまとめていますので、ぜひこちらもご覧ください！ ###card_post_id=1471### 本記事の編集者 アザラシさん 座談会のファシリテーター兼編集者 文系学部出身 研修で初めてプログラミングを学びました。 白米が好きです。 コアラさん 本記事の共同編集者 情報系学部出身 プログラミング経験が浅く、研修中は無駄に長いコードを書いていました。 スマートなコードをかけるように日々訓練中です。 研修運営について 研修運営って？ 研修運営とは、研修を進める上で必要な物品の準備や進行を、教育担当の上司に任せるのではなく、すべて新卒の自分たちで行うものです。 具体的には、 朝会/夕会の進行 講師の方との連絡やアテンド 研修会場やZoom環境の準備 研修のグループ分け 持ち物や連絡事項のリマインド　　etc… 円滑な研修運営に必要だと思うことを自分たちで考え実行します。 研修運営は、約2か月の研修期間を４つのタームに分けて、12~13人/グループで担当しました。また、各タームの最後には成果報告会を行い、同期や上司、研修の講師の方に運営での取り組みや振り返りを共有しました。 なぜ研修運営を行うの？ マイナビは自らビジネスを生み出す事業会社です。そのため、ただ依頼をこなすだけではなく、自ら課題を見つけて解決を目指す姿勢が求められます。それは営業職だけでなく、マイナビで働くすべての社員、私たちシステム職にとっても同じことです。 その一歩目として、主体性をみにつけるためにも新卒研修の研修運営を自分たちで行っています！ 研修運営についてはご理解いただけたでしょうか？ 続いて各運営班のリーダーとの座談会の様子をご覧ください！ 運営班リーダー座談会 座談会に参加する新入社員 うしくん：運営1班代表 運営1班のリーダー。 情報系の学部を卒業しました！ 最近、サウナに行くことが増えて、よく”伊良コーラ”を飲んでいます。 デトックス効果があるので、リラックスしたい時に是非！　　 うまくん：運営2班代表 運営2班のリーダー。 文系の学部を卒業しました。 最近はものすごく腰が痛くて、長時間座っているのがつらいです。 姿勢が悪いらしいので社会人っぽく背筋を伸ばしていこうと思っています。 しろくまくん：運営3班代表 運営3班のリーダー。 情報系の学部を卒業しました。 最近引っ越しをしたので新しいお店を開拓しています。 お金だけ心配です。 ひつじさん：運営4班代表 運営4班のリーダー。 情報系の学部を卒業しました。 つい最近旅行に行った後、体調崩して寝込んでいました。 体力が落ちているから運動しなきゃなと思って、1カ月が経ちました…。 座談会 研修運営を振り返って 早速ですが、研修運営について振り返ってみていかがですか？ 自分たちは、一番初めの研修運営班で、やることが何も見えていない状態だったため、前途多難でしたね。 その分、学びは多かったですが・・・ただ運営を担当していた期間の研修の記憶はあまりないです・・・。それだけ精一杯頑張りました。 初めの班は本当に大変そうでしたよね。ざっくりと研修運営については説明があったものの、研修を受けながら自分たちで運営していくというのは簡単ではないですよね。 2班はいかがですか？ 研修も同じだけど、運営はグループ活動だったから、同じチームになれた人とは仲良くなれたと思います。運営については、基本的には1班がつくってくれた基礎を引き継ぎ、改善できるところは工夫をしていきました。 2班はつつがなく終わっていたイメージがありますね。 一人ひとりが役割を全うしてくれていたから、そう見えていたのかもしれないです。 自分たちのグループも1班と2班がやってくれたことを引き継いだので、そんなに大変ではなかったですね。非常に協力的なチームだったので、成果報告会以外は大きな問題なく終わったと思っています。 成果報告会は急遽オンラインでの開催になったんでしたね。 報告会の形式を事前に確認していなかったから、段取りが悪くなってしまったんですよね。事前確認・調整の大切さを学びました。ただ、1班と4班に比べたら、全然大変ではなかったですよ。 私は1班同様、運営班を担当していた期間の記憶がないですね。(笑)　 1班が運営の0から1を作って、2班3班がよりよく変化させていたから、4班は最後どうするかハードルが上がっている状態でした。研修自体も大詰めでしたし、その焦りもある中での運営だったので、本当に大変でした。 各班の取り組み 各チームいろいろ工夫しながら運営を行っていたようですが、各班ならではの取り組みなどはありましたか？ 自分の班は主軸となって動く人を3人ほど決めました。その人たちで仕事の洗い出しをした後に、メンバーに割り振っていくという仕組みでやっていました。ですが、仕事量の差が出てしまったので結局全員で仕事を割り振るように分担を変えたりしていましたね。 途中で仕組みを変えたんですね。 そうですね。初日と最終日では変わったことが多かったですね。 やってみないと分からないことが多かったのでまずはやってみて、こっちの方が効率的なのではないか等意見をもらいながら試していきました。 試行錯誤しながらの運営だったんですね。 2班ではどんな取り組みがありましたか？ 2班の目標は、「何事も起こらないように終えること」だったので、新たな何かをやるというよりも1班がやっていたことを工夫できたらいいなというマインドでしたね。 メンバーがやった方がいいことを提案してくれて、それを1つずつ実践していきました。 2班から研修のチーム分けが自動になりませんでしたか？ メンバーがチーム分けのアルゴリズムを作ってくれたので、新しいチームを作るときにはそれを動かしていました。あと、在宅の日の出席確認をPower Automateを使って自動化しました。各役割を固定化していたので、やることが明確になって、みんなが自主的に自分の仕事をこなしてくれました。 チーム分けの自動化はとても画期的でしたよね。3班も自動で行っていましたが、2班のものを使ったんですか？ 3班は2班のものを改良して使用しました。2班のアルゴリズムの問題点として、1度同じチームになった人と何度も一緒になってしまうことがあったので、そこを改善できるようにしました。 2班のやっていたことを引き継いでさらに良くしていったのですね。新しく始めたことはありますか？ リモートワークでの自習日（※研修がなく、自分でスケジュールを立てて良い日。研修の振り返りをしたり、勉強会を開いたり…）があったので、ブレイクアウトルームの使い方を決めました。あとは、先輩への欠席連絡を始めましたね。細々したことをやっていました。 3班は仕組みづくりがしっかりされていた印象があります。細々と仰っていますがそういう小さなことが先輩社員の皆さんは非常にありがたいと好評だったそうですよ。 4班はいかがですか？ 4班は役割をローテーションさせていました。3班の成果報告会で司会が固定だったことが指摘されていました。 全ての役割に今の我々がやる意味があると思うので、全員が司会を経験できるようにしました。 たしかに、司会が毎日変わっていたのが印象的でした。 研修の目的として、失敗を恐れずにとにかく経験してみようというのがあったので、それに則してやってみました. ４班ならではの取り組みだと、意見箱の設置ですかね。フォームを作成して、新卒から随時意見をもらい、運営に反映できるようにしました。手探り状態で始めたので、教育担当の方と相談しながら試行錯誤しました。 今までやっていない施策に挑戦するということはうまくいかない可能性もある中で、うまく工夫して周りを巻き込みながら改善をしていたイメージがあります。 そうですね。4班のみんながいろいろ考えて動いてくれた結果、何とかうまくいったような気がしているので、班のみんなに感謝です。 研修後に活きていること では、最後に研修運営後に活きていることがあれば教えてください。 今まで、自分が正しいという考えが結構強くて、チームを引っ張っていかないといけないという気持ちがありました。自分に自信もありましたし・・・でも実際は全然そんなことはなくて、研修運営を通して周りにたくさん助けられているということに気づけました。 あとは、タスクを割り振ったり、細分化したりする能力が身につきましたね。 自分はメンバーを信頼することの大事さを学んだと思っています。今までメンバーを信頼していなかったというわけではないけれど、研修運営を通して、一緒に仕事をやる人たちを信頼してみんなでやろうという気持ちの持ち方がとても大事というのを感じました。 チームで何かをやる経験が今までなかったから、チームワークの大切さを学びました。研修最後のチームで行う開発演習で活きた感じがします。 開発演習で、僕のグループは、班員が1人体調不良で欠席というハプニングが起きたのですが、最後まで連携をとってやりきることができました。 誰かと協力しながら成し遂げようとする経験をできたのが良かったです。活かされていることとしては、運営をしているときに報連相の重要さを感じていたので、それを意識しています。 ただ自分の考えを伝えるのではなく、相手の立場に立って、どういう内容が欲しいのかを考えて発言するように心がけるようになりました。 あとがき いかがでしたでしょうか？ 研修運営の内容や、新入社員ならではのリアルな感想がお伝えできていれば幸いです。 研修運営を通して、社会人として必要なスキルである、「何事にもひとりひとりが主体性をもって取り組む姿勢」を身につけることができました。 コアラさん エンジニアは1つのチームで業務を行うことが多いので、協調性やコミュニケーション力は欠かせません。研修期間にチームで1つのことを成し遂げる経験ができたことは、今後の業務にも活きてくると思います。 研修期間に培った力を活かせるように今後も積極的に何事にも取り組んでいきたいです。 今回の記事は以上になります。最後まで読んでいただきありがとうございました！

はじめに こんにちは！23卒の開発エンジニアのＴ.NとN.Yです。 この記事では、今年度行われた、マイナビのシステム職向けの新卒研修について、具体的にどんなことを学んだのか紹介していきます。 主にマイナビのシステム職に興味のある学生の皆さんを対象として、イメージをつかめるような記事を作りたいと思いますので、ぜひ参考にしてみてください。 全体スケジュールと前提 前提条件 今年度システム職として採用された新入社員は、システムエンジニア、開発エンジニア、データサイエンティスト、デザイナー、マーケター、企画職など、配属職種は様々です。 しかし、新人研修では職種関係なく全員が３ヶ月間同じ研修を受けました。 これは、専門に関係なく基礎的なITスキルを身に着けることで、将来的に「複数職種を跨いで活躍する人材になる」ことを目的としているからです。 スケジュール 最初に、研修期間のスケジュールをまとめました。 システム職の新人研修は、３か月間にわたって実施されます。ビジネス基礎などの社会人として必要なことから、WEBアプリの開発演習まで多岐に渡って内容を網羅していきます。 いかがでしょうか？ マイナビについて知る研修から、ITの基本的な知識やアプリ開発の流れまで、３か月間盛りだくさんな内容であることが分かるかと思います！ 研修期間中は毎日の日報記入があり、長期間にわたるアウトプットを通じて、研修が始まる前と終わった後で自分自身がどのように成長し、変化があったのかを感じることができました。 また、１人三分で自分の好きな事などを発表する「三分間プレゼン」を実施し、スライド作成や短時間で伝える力、大勢の前での発表など、配属されてからも必要となるスキルを養うことができました。配属先の異なる同期の発表を聞くことができたのも研修ならではだったと感じています。 さらには、研修を受講するだけでなく、研修を自分たちで運営することもありました。 会場の用意や講師の方のアテンド、連絡事項などを新入社員自身で行いました。 ▼こちらに関しては、別の記事で詳しくまとめているので、併せて読んでみてください！ 2023年システム職新人研修・振り返り～研修運営編～ ただ技術を教わる以上に、社会人として、マイナビ社員として、必要な要素を身に着けられる研修だったのかなと思います。 ここからは、それぞれの研修について、一つずつ説明していきます。 ビジネス研修、事業部研修など 私たち新入社員が研修で学ぶものは、テクノロジーに関することだけではありません。 まずは、デジタルテクノロジー戦略本部の各部門の役割について、それぞれ説明を受けました。 他にも下記のように、様々な研修を通じて新社会人としての準備をしていきました。 オンボーディング研修 オンボーディング研修では、まずはテクノロジー分野の発展についてを学び、そこから自社事業についてを考えました。また、実践的に学びを深めるために、サービスについて分析するワークを行いました。 ペルソナ設定や３C分析といった、沢山のワークを通じて、マイナビの一員としてのマインドセットを養うことが出来たのではないかと思います。 事業部研修 マイナビには、就職事業本部（代表サービス：マイナビ20XX）、転職事業本部（代表サービス：マイナビ転職）、アルバイト事業本部（代表サービス：マイナビバイト）など、多くの事業部があります。 総合職の各事業部配属の新卒を対象とした本研修は、各事業部ごとに実施されます。サービスやビジネスモデルの理解から営業フローの学習まで、様々なカリキュラムが用意されていました。 私たちも、営業を始めとした他職種と共に研修に参加し、カスタマーへの提案やテレアポの練習に参加しました。「システム職なのに営業の練習？」と思う方がいるかもしれません。ですが、自分たちが携わる市場やサービスについて知ることは、今後仕事をしていく上でとても重要なことです。この研修を通じ、会社全体において課題を解決するためにシステム職が担う役割を学ぶことができました。 他にも、マーケティングの基礎や、ロジカルシンキングを学ぶ機会がありました。 どんな業務に携わるにせよ、問題解決能力やコミュニケーション能力は欠かすことができません。これらの研修は、今後ずっと使える力を養うキッカケになりました。 Python、フロントエンド、インフラなど IT研修では、web開発に関連する以下のような技術を学びます。 アルゴリズム Linux / AWS HTML / CSS データベース Python / Flask 短い期間で上記の範囲をカバーするカリキュラムですので、技術に関しての知識を深めるためだけのものではありません。 「自分で考えて、自分で行動していく力を身に着ける」力を養うことが、ゴールとして掲げられていました。 もちろん、技術に慣れている人もいれば、初めてエディタを開く人もいます。習熟度や得意なことはバラバラですので、研修中のワークでは、互いに協力しながら取り組むことが多くありました。教える側も教わる側も、どうすれば自分の考えが上手く伝わるか、工夫を重ねて上達したように感じます。 同期たちと共に頑張ることで、技術面の成長だけでなく、今後も役立つ自走力を身に着けることができました。 また、私たちは、自習日や空き時間を活用して、それぞれ基本情報やITパスポートなど資格試験の受験を行いました。 これからIT職として働く基盤を固めるための、有意義な時間を過ごせたと思います。 チーム開発 技術研修の締めくくりとして、チーム開発を実施しました。 ６〜７人の班に分かれて、要件定義から設計、実装、テストまでを２週間で行いました。 PythonのFlaskというフレームワークを利用して、チケット予約サイトを作成することが、今回与えられた課題です。 この課題には、「全員1人1機能は実装する」という条件がありました。 ですので、得意不得意に関わらず、全員がIT研修で学んだことを活かして開発に取り組む必要がありました。 一方で、開発を行うためのヒアリングや設計書を作ることも必須です。採用職種とは関係なく、上流から下流までをひと通り経験することとなりました。 下の画像は、とある班の作成した成果物です。 この演習では、それぞれの班は開発請負側であると同時に、ユーザーの立場も兼ねています。 例えば、A班はB班に対して「こんな機能があるサイトを作ってほしい」と依頼します。反対に、B班もA班に対して要望を依頼する、といった感じです。 二つの立場が並行するため、慌ただしくはありましたが、両方の立場を経験するからこそ、ユーザー側と開発側との合意を探る難しさを知ることができました。 個人的には、ヒアリングが難しかったです。班員のキャパシティやリリースまでの期間を踏まえて妥協を探ることが、特に大変でした。 また、チームでの開発ですので、個人が黙々と取り組んでいるだけでは成り立ちません。スムーズな協力と連携のためにも、メンバー間で役割分担やタスクを共有することは、必須の課題でした。 演習開始のころは、情報共有や連携が上手くいかず、手戻りの発生する場面が散見されました。中には、グループ内でgithubの運用が整備されておらず、コードが消え飛んでしまうアクシデントが起こることもあったそうです。 様々なトラブルが発生していましたが、運用マニュアルの作成や共有ツールの導入など、問題解決力を活かすことで、一つずつ解決できました。 成果報告会 ３か月の研修の最後、チーム開発の集大成として、成果発表会を行いました。 私たちは、実装したサイト紹介と開発演習から得た学び、また、研修を通じた成長の三項目について発表を行いました。 劇形式で発表してみたり、キャッチーなスライド構成にしてみたり、伝え方に関して個性が光る発表会となりました。 最後の締めくくりとして相応しく、３か月かけて学んだことを総動員することができたのではないかと思います。 成果報告後には、三部門での賞が用意されていました。参加してくださった先輩社員たちの投票によって最優秀賞と発表賞の班が、講師の方の評価からは技術賞の班が、ひとつずつ選ばれました。 賞を頂けることはもちろん嬉しいですが、何よりも、自分一人ではできなかった挑戦があったことが、この研修を通じた一番の収穫だったと思います。 研修で得たすべてを、これからの糧として活かせるように、今後も精進していきます。 さいごに 以上が、23卒システム職の研修カリキュラム振り返りになります。 もっと詳しく聞きたい方は、マイナビのインターンや説明会に参加するといいかもしれません。 ぜひ、いろんなイベントに参加してみてくださいね！

はじめに 始めまして、23年新卒入社のG・Sです。 マイナビ2023年新卒入社で参加者を募って、6/3（土）4（日）開催のSECCON Beginners CTF 2023に参加してきました。 本記事は、我々新卒チームが解いた問題のwritupになっています。 今回参加したCTFについて SECCON Beginners CTF 2023 日本のCTF初心者〜中級者を対象としたCTFのコンテストで毎年6月の上旬に開催されています。今回は2018年の初開催から数えて6回目の開催となります。 出題範囲は、crypto、pwnable、misc、web、reversingでした。 Writeup 我々のチームはBeginnerを全て解くことができました！！！ ひとつずつ解説していこうと思います。 CoughingFox2(crypto) CougningFox2.tar.gzを展開するとcipher.txtとmain.pyが入っていました。 cipher.txtとmain.pyの内容はそれぞれ以下の通りです。 cipher = [4396, 22819, 47998, 47995, 40007, 9235, 21625, 25006, 4397, 51534, 46680, 44129, 38055, 18513, 24368, 38451, 46240, 20758, 37257, 40830, 25293, 38845, 22503, 44535, 22210, 39632, 38046, 43687, 48413, 47525, 23718, 51567, 23115, 42461, 26272, 28933, 23726, 48845, 21924, 46225, 20488, 27579, 21636] # coding: utf-8 import random import os flag = b"ctf4b{xxx___censored___xxx}" # Please remove here if you wanna test this code in your environment :) flag = os.getenv("FLAG").encode() cipher = [] for i in range(len(flag)-1): c = ((flag[i] + flag[i+1]) ** 2 + i) cipher.append(c) random.shuffle(cipher) print(f"cipher = {cipher}") プログラムを読むと暗号化を行い最終的に cipher というリストを出力していることが分かります。このことから cipher.txt に書かれていたものは暗号化がおこなわれた後のものでと考えられます。また暗号化の部分はi文字目とi+1文字目を足して2乗し、iを足したものであることから、一つの文字が分かれば次の文字を総当たりで探し (flag[i] + flag[i+1]) ** 2 + i を計算しcipher.txt内の配列に存在するか確認すれば芋づる式に解きFlagを得ました。 Flag : ctf4b{hi_b3g1nner!g00d_1uck_4nd_h4ve_fun!!!} 学び 暗号は一見難しそうなものでもプログラムを書いたりすることで容易に解けてしまうものも多く存在しています。 よって、暗号の選定をする際にはきちんと脆弱性がないものを選ぶことが重要であると感じました。 poem(pwnable) poem.tar.gzを展開するとpoemとsrc.cが入っていました。 poemは実行ファイルであり、src.cの内容は以下の通りです。 #include <stdio.h> #include <unistd.h> char *flag = "ctf4b{***CENSORED***}"; char *poem[] = { "In the depths of silence, the universe speaks.", "Raindrops dance on windows, nature's lullaby.", "Time weaves stories with the threads of existence.", "Hearts entwined, two souls become one symphony.", "A single candle's glow can conquer the darkest room.", }; int main() { int n; printf("Number[0-4]: "); scanf("%d", &n); if (n < 5) { printf("%s\n", poem[n]); } return 0; } __attribute__((constructor)) void init() { setvbuf(stdin, NULL, _IONBF, 0); setvbuf(stdout, NULL, _IONBF, 0); alarm(60); } このプログラムを読むと数値nを読み取り、配列に格納されているn番目のポエムを出力するプログラムであることが分かります。読み込んだnが5より大きいときはポエムを出力しないようにしてありますが、0より小さい場合はそのまま配列にアクセスすることになっています。 よってnにマイナスの値を入力することでほかの領域のアドレスにアクセスすることがで、-4を入力することでFlagを得ました。 Flag : ctf4b{y0u_sh0uld_v3rify_the_int3g3r_v4lu3} 学び Pythonなどでは、リストなどの範囲外のindexを指定した場合IndexErrorが出ますが、C言語ではエラーが出ずに別メモリ領域にアクセス可能になります。 これを防ぐためには、境界値を正しく設定し条件分岐することが大事たと感じました。 YARO(misc) YARO.tar.gzを展開するとrule_example.yarとserver.pyが入っていました。 それぞれ内容は以下の通りです。 rule shebang { strings: $shebang = /^#!(\/[^\/ ]*)+\/?/ condition: $shebang } rule maybe_python_executable { strings: $ident = /python(2|3)\r*\n/ condition: shebang and $ident } #!/usr/bin/env python3 import yara import os import timeout_decorator @timeout_decorator.timeout(20) def main(): rule = [] print('rule:') while True: l = input() if len(l) == 0: break rule.append(l) rule = '\n'.join(rule) try: print(f'OK. Now I find the malware from this rule:\n{rule}') compiled = yara.compile(source=rule) for root, d, f in os.walk('.'): for p in f: file = os.path.join(root, p) matches = compiled.match(file, timeout=60) if matches: print(f'Found: {file}, matched: {matches}') else: print(f'Not found: {file}') except: print('Something wrong') if __name__ == '__main__': try: main() except timeout_decorator.timeout_decorator.TimeoutError: print("Timeout") コードを見るとruleを入力させ、yaraというマルウェア解析・検知ツールを用いて検索を行っています。 下記のようなruleを書くことでflagの一文字目がAかどうか確認できます。 rule flag { strings: $shebang = /ctf4b{A.*}/ condition: $shebang } これを繰り返して探索していくことでFlagを得ました。 Flag : ctf4b{Y3t_An0th3r_R34d_Opp0rtun1ty} 学び ユーザーに任意の正規表現を書かせるようなプログラムを書くと秘匿情報を探索される可能性があるため注意が必要だと学びました。 polyglot4b(misc) polyglot4b.tar.gzを展開すると画像ファイルsample/sushi.jpgとpolyglot4b.pyが入っていました。 import os import sys import uuid import shutil import subprocess print( f"""\033[36m\ ____ _ _ _ _____ _ _ _ | _ \ ___ | |_ _ __ _| | ___ | |_ | ____|__| (_) |_ ___ _ __ | |_) / _ \| | | | |/ _` | |/ _ \| __| | _| / _` | | __/ _ \| '__| | __/ (_) | | |_| | (_| | | (_) | |_ | |__| (_| | | || (_) | | |_| \___/|_|\__, |\__, |_|\___/ \__| |_____\__,_|_|\__\___/|_| |___/ |___/ {"-" * 68} >> """, end="", ) file = b"" for _ in range(10): text = sys.stdin.buffer.readline() if b"QUIT" in text: break file += text print(f"{'-' * 68}\033[0m") if len(file) >= 50000: print("ERROR: File size too large. (len < 50000)") sys.exit(0) f_id = uuid.uuid4() os.makedirs(f"tmp/{f_id}", exist_ok=True) with open(f"tmp/{f_id}/{f_id}", mode="wb") as f: f.write(file) try: f_type = subprocess.run( ["file", "-bkr", f"tmp/{f_id}/{f_id}"], capture_output=True ).stdout.decode() except: print("ERROR: Failed to execute command.") finally: shutil.rmtree(f"tmp/{f_id}") types = {"JPG": False, "PNG": False, "GIF": False, "TXT": False} if "JPEG" in f_type: types["JPG"] = True if "PNG" in f_type: types["PNG"] = True if "GIF" in f_type: types["GIF"] = True if "ASCII" in f_type: types["TXT"] = True for k, v in types.items(): v = "🟩" if v else "🟥" print(f"| {k}: {v} ", end="") print("|") if all(types.values()): print("FLAG: ctf4b{****REDACTED****}") else: print("FLAG: No! File mashimashi!!") コードを読むと10回入力を受け取り入力を結合して file コマンドを実行しその出力にPNG、JPEG、GIF、ASCIIの文字列があるかを確認して全てあればフラグを出力しています。 まずsample/sushi.jpgを file -bkr sample/sushi.jpg を行うとDescriptionの欄にCTF4Bという文字を見つけられます。このことからDescription欄には、任意の文字を入れることができると考えられます。よってCTF4Bの後ろにPNGJPEGGIFASCIIを追加して、 nc polyglot4b.beginners.seccon.games 31416 < sushi.jpg とやることで、Flagを得ました。 Flag : ctf4b{y0u_h4v3_fully_und3r5700d_7h15_p0ly6l07} 学び fileコマンドを使ってファイルを識別する際に正しく処理を書かなければ、ユーザーの悪意によっていくらでも偽装できることが可能であるとわかりました。今回の問題のミスをなくすためには、fileコマンドの解析をファイルタイプを示している部分だけにするなどの工夫が必要であると感じました。 Forbidden(web) Forbidden.tar.gzを展開するとnginxで作られたWebアプリケーションが入っていました。 app/index.jsの内容は以下の通りです。 var express = require("express"); var app = express(); const HOST = process.env.CTF4B_HOST; const PORT = process.env.CTF4B_PORT; const FLAG = process.env.CTF4B_FLAG; app.get("/", (req, res, next) => { return res.send('FLAG はこちら: <a href="/flag">/flag</a>'); }); const block = (req, res, next) => { if (req.path.includes('/flag')) { return res.send(403, 'Forbidden :('); } next(); } app.get("/flag", block, (req, res, next) => { return res.send(FLAG); }) var server = app.listen(PORT, HOST, () => { console.log("Listening:" + server.address().port); }); コードを読むと block で/flagに遷移したとき403を返していることが分かります。 nginxは、URLの大文字小文字の区別がない。すなわち"/flag"と"/Flag"は、同じページであると判断されます。 しかし、JavaScriptでは、 if (req.path.includes('/flag')) で分岐を行いブロック処理を記述しているため、 https://forbidden.beginners.seccon.games/flag は403が帰ってくるが https://forbidden.beginners.seccon.games/Flag とすることでフラグを得ることができます。 Flag : ctf4b{403_forbidden_403_forbidden_403} 学び フレームワークの仕様をしっかり理解していることが大切であると感じました。 今回の例では、nginxとJSで文字列の大小の扱いが違っていてその違いを理解していないことで意図するように動いていないので、仕様理解をおろそかにしてはいけないと学びました。 aiwaf(web) aiwaf.tar.gzを展開するとnginxで作られたWebアプリケーションが入っていました。 app/app.pyの内容は以下の通りです。 import uuid import openai import urllib.parse from flask import Flask, request, abort # from flask_limiter import Limiter # from flask_limiter.util import get_remote_address ################################################## # OpenAI API key KEY = "****REDACTED****" ################################################## app = Flask(__name__) app.config["RATELIMIT_HEADERS_ENABLED"] = True # limiter = Limiter(get_remote_address, app=app, default_limits=["3 per minute"]) openai.api_key = KEY top_page = """ <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8" /> <title>亞空文庫</title> </head> <body> <h1>亞空文庫</h1> AIにセキュリティの物語を書いてもらいました。<br> 内容は正しいかどうかわかりません。<br> <ul> <li><a href="/?file=book0.txt">あ書</a></li> <li><a href="/?file=book1.txt">い書</a></li> <li><a href="/?file=book2.txt">う書</a></li> <!-- <li><a href="/?file=book3.txt">え書</a></li> --> </ul> ※セキュリティのためAI-WAFを導入しています。<br> © 2023 ももんがの書房 </body> </html> """ @app.route("/") def top(): file = request.args.get("file") if not file: return top_page if file in ["book0.txt", "book1.txt", "book2.txt"]: with open(f"./books/{file}", encoding="utf-8") as f: return f.read() # AI-WAF puuid = uuid.uuid4() prompt = f"""\ 以下の{puuid}に囲まれた部分のURLクエリはパストラバーサル攻撃でしょうか？ そうである場合Yesを、違う場合Noを返してください。 ../やflagという文字列が含まれていた場合もYesを返してください。 {puuid} {urllib.parse.unquote(request.query_string)[:50]} {puuid} """ try: response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ { "role": "user", "content": prompt, }, ], ) result = response.choices[0]["message"]["content"].strip() except: return abort(500, "OpenAI APIのエラーです。\n少し時間をおいてアクセスしてください。") if "No" in result: with open(f"./books/{file}", encoding="utf-8") as f: return f.read().replace(KEY, "") return abort(403, "AI-WAFに検知されました👻") if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=31415) コードを読むと 以下の{puuid}に囲まれた部分のURLクエリはパストラバーサル攻撃でしょうか？ そうである場合Yesを、違う場合Noを返してください。 ../やflagという文字列が含まれていた場合もYesを返してください。 {puuid} {urllib.parse.unquote(request.query_string)[:50]} {puuid} というプロンプトをAIに投げて帰ってきた値がYesだった場合、ブロックする仕様になっています。 プロンプト部分を見ると urllib.parse.unquote(request.query_string)[:50] となっており与えられたURLの50文字目までしかAIによる検知を行っていないことがわかります。 これにより、パラメータに適当なものを追加し file=../flag が50文字目以降となるように設定することでAIによる検知を抜けてフラグを得ることができました。 Flag : ctf4b{pr0mp7_1nj3c710n_c4n_br34k_41_w4f} 学び OpenAIは文字単位でお金がかかります。そのため、コストを下げようと途中で文字列を切ってからプロンプトを生成してしまうなどすると切り取った以降の部分に攻撃が含まれている可能性があり、攻撃が成立してしまう可能性があります。文字列を切る場合は、以降の処理も切ってから行うなどしないといけないと感じました。 Half(reversing) Half.tar.gzを展開するとhalfという実行ファイルが入っていました。 このプログラムを実行すると入力待ちになり、入力されたフラグの正誤判定をしてくれます。 この実行ファイルを strings コマンドを使って可読部分を表示して得られる結果が以下の通りです。 $ strings half /lib64/ld-linux-x86-64.so.2 libc.so.6 strncmp __isoc99_scanf puts printf strlen __cxa_finalize strcmp __libc_start_main GLIBC_2.7 GLIBC_2.2.5 _ITM_deregisterTMCloneTable __gmon_start__ _ITM_registerTMCloneTable u+UH []A\A]A^A_ Enter the FLAG: %99s%*[^ Invalid FLAG ctf4b{ge4_t0_kn0w_the _bin4ry_fi1e_with_s4ring3} Correct! :*3$" GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 crtstuff.c deregister_tm_clones __do_global_dtors_aux completed.8061 __do_global_dtors_aux_fini_array_entry frame_dummy __frame_dummy_init_array_entry main.c __FRAME_END__ __init_array_end _DYNAMIC __init_array_start __GNU_EH_FRAME_HDR _GLOBAL_OFFSET_TABLE_ __libc_csu_fini strncmp@@GLIBC_2.2.5 _ITM_deregisterTMCloneTable puts@@GLIBC_2.2.5 _edata strlen@@GLIBC_2.2.5 printf@@GLIBC_2.2.5 __libc_start_main@@GLIBC_2.2.5 __data_start strcmp@@GLIBC_2.2.5 __gmon_start__ __dso_handle _IO_stdin_used __libc_csu_init __bss_start main __isoc99_scanf@@GLIBC_2.7 __TMC_END__ _ITM_registerTMCloneTable __cxa_finalize@@GLIBC_2.2.5 .symtab .strtab .shstrtab .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt.got .plt.sec .text .fini .rodata .eh_frame_hdr .eh_frame .init_array .fini_array .dynamic .data .bss .comment この出力を見てみると20行目にFlagがあります。 Flag : ctf4b{ge4_t0_kn0w_the_bin4ry_fi1e_with_s4ring3} 学び 文字列は、実行ファイルにそのまま保存されるため、秘匿情報を文字列にしたまま実行ファイルに入れてしまうと容易に見れてしまうので、秘匿情報を載せないことを徹底しなければいけないと感じました。 終わりに 今回は、私は初参加ながら全てのbeginner問題を解くことができたので大変満足しています。 しかし、medium・herdあたりが全く解けなかったのでもう少し精進していきたいと感じました。 CTFに参加することで今まで知らなかった脆弱性などを知る機会になり、 セキュリティへの意識が高まるので是非皆さんも参加してみてください。 投稿 【CTF】SECCON Beginners CTF 2023 新卒チームWriteup は マイナビエンジニアブログ に最初に表示されました。

こんにちは。 2023年にデータサイエンティストとしてマイナビに入社をしたH・Hです。 この度、イギリスのダービー大学で開催された国際学会である自然言語処理学会に登壇をして来ました。 今回は参加の経緯と参加レポについて記載をさせていただきます。 主な流れ 時間 内容 2月上旬 国際学会提出に誘われる 3月30日 論文提出 4月25日 査読通過 5月23日~6月19日 スライド作成＋発表練習 6月19日 イギリスへ！ 6月21日 発表! 6月25日 日本に帰国 自分の研究について 概要 元々、Web上のデータはなかなか解析が進んでいないと思っていました。様々なデータがある中でWeb上ではオープンに学ぶことが出来ます。機械学習をさせることで精度が高い解析ができるのではないかと考えました。 自分の研究テーマは[機械学習によるTwitterユーザーの性別予測]です。 X（旧：Twitter）で投稿されたテキストや画像をもとに投稿したユーザーの性別を予測していきます。 例えばある商品について「いいね！」をしている人や自分をフォローしている人の性別を知ることで今後のマーケティング戦略につながるといった社会的目的も叶えることが出来ると思いました。 その中でも新規性として、性別をTwitterの外のサービスを用いて自動にラベル付けを行うことで、機械学習する際に人の手間を排除した方法を行い、十分な精度を出しました。 具体的には日本人では約2万人いると言われているX（旧：Twitter）のフォロワー数1万人以上の人に対してWikipedia等Web上の情報を用い、ラベル付けをすることができた6000人～7000人を学習させていきました。 大変だったこと ラベル付けについてなかなか精度を上げることが出来ず非常に苦労をしました。 画像の添付が有るときと無いときのデータに対してどのような対応をすべきか？等考えることが沢山あります。 最初に作ったモデルだと上手に行かず、いろいろなモデルを作っては試し、また作っては試し…と何度も繰り返しました。 また、データ数も非常に多く、1回の取得に2週間以上かかるものもあり回収が非常に難しかったです 参加のきっかけ 最初は卒業年である2023年の1,2月ごろ、研究室内で自分の研究内容を発表したときに助教授の方から「君の研究内容は面白い。近日、君に当てはまるテーマでの学会発表がイギリスであるから提出してみたら？」と提案を受けたのがきっかけです。 自分は英語がかなり苦手であまり積極的ではなかったのですが、サポートをしてくれるという言葉から提出に踏み切りました。助教授のアドバイスの元、卒論や、国内学会発表とは内容と差別化を図るように注目する点を少し変えて、結論をまとめていきました。 追加実験や論文をまとめ上げ3月30日に提出をしました。 査読が通った後 提出を終えたのち大学院を卒業し、はれてマイナビに入社し新入社員研修をしていた4月25日に査読が通り、掲載されることが決まりました。その時は研修と発表準備の両立への不安と、英語が本当に苦手という意識から、自分はイギリスにはいかず、発表は助教授に任せようと考えていました。ただ同期の仲間に背中を押され5月の中旬にようやく学会発表をすることを決意しました。 イギリスへ そこからはスライド、発表資料の作成を行い、複数回のミーティングと元研究室のみんなにも協力してもらいながら発表練習を複数回繰り返しました。(と言いつつもカンニングペーパーを作成しそれを間違えないように発音することで精一杯でした…) それから、初めてのヨーロッパということで移動、宿泊の準備もしていきました。 イギリスに到着してからもぎりぎりまで内容の確認を行い発表に臨みました。 学会発表 正直緊張して何も覚えていません（笑） 博士課程の方や大学教授レベルの方が非常に多く、ほぼ最年少での参加でした。 自分は、言葉を間違えないように必死で、ほとんどスライドを見ていました。 質疑応答の場面では周りの助けもありながらなんとか返答することができました。 中でも、「性の多様化が進んでいるなかで男女のみに絞ったのですか？」という質問に対しては「先行研究と比較するため男女のみに絞りました。」としか答えることができず、性別に関する認識を甘く見られていた点を突かれてしまいました。 他の人の発表を聞いて自分では考慮しきれなかった絵文字を含んだ文章解析など独自の視点による解析が多くあり視野が広がりました。 振り返り 結論として、とても楽しかったです！参加して本当に良かったと思います！ 最初は英語が苦手で、発表もけして大成功とはいえない結果でしたが、文化的にも、技術的にも多くの経験をさせてもらいました。特に、多くの国籍の方が発表していたので、注目する視点や、問題の定義にも個性が出ており、多様な物事の視点を獲得できた気がしています。 また、よく見ていた論文サイトで自分の論文が見れるようになっていてとても興奮しました！ もっと時間があれば性別だけでなく年齢や出身地も予測したいなと思っていました。ただ研究をしていくうちに「データ」そのものへの興味が湧いてきたのです。なので、これからマイナビでデータサイエンティストとして活躍できるよう、頑張っていきたいと思います！！ 投稿 【23卒】初めての国際学会体験記【自然言語処理学会】 は マイナビエンジニアブログ に最初に表示されました。

はじめに マイナビ内でTableau DATA Saber認定制度に挑戦された3名に、師匠（前編）・弟子（後編）それぞれの立場で2作に分けて体験記を書いていただきました。 本記事では後編・弟子についてお届けします。前編・師匠については こちら をご覧ください。 自己紹介 ご覧いただきありがとうございます。データソリューション統括部　データ活用推進1課のT・SとS・Sです。2023年2月からTableau DATA SABERプログラムに挑戦し、無事4月にDATA SABERに認定されました。 この記事ではTableau DATA SABERプログラムに挑戦していた時のことを回顧してみようと思います！ そもそもDATA SABERとは？ Tableauの技術はもちろんのこと、データのその先の世界を見通す技術力とデータドリブン文化を伝え、人々を導く力を身につける資格/制度です。 DATA SABERを目指す者は3か月間の限られた時間の中、 Tableauの技術力を磨くための十の試練 導く力を鍛えるための、コミュニティ活動(社内外でデータドリブン文化を広めるための活動) を行い、全てクリア/最後の試験を突破したものに与えられる称号となります。 (これをクリアするために3ヶ月で100時間以上の勉強時間が必要になります。) 1日1~2時間ペースで勉強をすればいいように見えますが、通常業務にプラスで時間をかけて勉強をしなければいけないので、大変な試練であることはお伝えしておきます。 詳しくは 公式HP をご確認ください それぞれの回顧録 T・SとS・S、それぞれがDATA SABERプログラムで過ごしてきた時間が異なります。 そのため、それぞれの歩んできた道を書いていこうと思います。 CASE 1 T・Sの場合 改めて自己紹介 私立大学文系学部卒。 「システムエンジニアってなんですか？」というレベルで、この業界に足を踏み入れました。 新卒1年目でSESの会社に就職し、某携帯電話キャリア会社に客先常駐。そこでBIについて色々と学びました。 新卒3年目の途中にマイナビに転職し、それからはBI開発に携わったり、現在ではセルフBIの導入、サポートなどを業務として行っています。 DATA SABERチャレンジ前のTableau歴・レベル DATA SABERチャレンジ前のTableau歴：4年ほど レベル：簡単なグラフや集計表とそれを組み合わせたダッシュボードが作れるレベル 初めてTableauに出会ったのが、某携帯電話キャリア会社で客先常駐していたころになります。 当時、新卒2年目の時に初めてTableauを触りました。そのころは簡単なグラフや集計表を作る程度で、ダッシュボードを開発したりなどのスキルは持ち合わせていませんでした。 マイナビに転職してからもしばらくはTableauは触っておらず、 2021年10月の部署異動を機に、久しぶりにTableauを触り、そこからは独学でTableauについて学んでいったというレベルになります。 独学だったため、Tableauの機能をちゃんと理解しているわけでもなく、有効活用もうまくできていませんでした。 チャレンジした経緯 簡単に言うと、Tableauのスキル・技術を身に着けるためです。 異動してから、Tableauでダッシュボードを作成する業務が発生しました。しかし、自分の知識不足のせいか、Tableauの機能を最大限に活かせていないと感じ、DATA SABERに挑戦しました。 また、同時に私はデータドリブン文化を社内に根付かせる部署に所属しています。Tableauのスキルや知識を他の方に展開する立場であるのに、Tableauの機能を活かせていない、機能を知らないのは、データドリブン文化を根付かせるうえで今後障壁になるのではないかと思いチャレンジしました。 弟子時代に取り組んだこと Tableauの技術力を磨くための十の試練 こちらについては与えられた問題に対して回答するものになります。 内容は、①tableauをつかってデータを可視化し回答を探し出すという問題と、②データドリブン文化を広めていく上でどのような考えでどのような行動を取ったらいいかを問われる問題と2パターンあります。 どちらも全問正解しないとCLEARにはならない課題です。 ①の問題例は こちら ②の問題例は こちら ①については技術力が問われる問題であるため、自分が持ち合わせている知識を使ったり、わからないものについては、別途、勉強動画を見たりして知識を習得しました。 ②については、どちらかというとデータドリブン文化を作る上で必要なマインドや考えを問われるものになります。そのため、答えを導くために一緒に挑戦していたS・Sさんとディスカッションしたり、師匠とディスカッションなどをして答えを導いてきました。 技術力を磨くための試練とあるように、知識や考えを問われる問題であるため、わからないものは素直にわからないと認めて、勉強動画をみたり師匠などとディスカッションを重ねたりしました。 導く力を鍛えるための、コミュニティ活動(社内外でデータドリブン文化を広めるための活動) いくつかお題が設定されており、そのお題ごとに取得できるポイントが決まっています。社内、社外それぞれ20ポイント、合計50ポイント取得してCLEARとなる課題です。 私が行った取り組みを社内向け、社外向けでいくつかご紹介します。 【社内向け】 Tableau Doctor Tableauを社内で利用している方々の悩みや、こんなことを実現したいという要望を聞いて、どのように解決すればいいかを提示するものになります。 悩みや実現したいことの内容は様々ですが、社内のユーザーがどんなことに躓いているのかがわかったり、またその悩みに対してデータ活用推進部署としてどのような施策を打つと良いのかなどを考えるきっかけになりました。 この取り組みは、最初はDATA SABERの時だけ開催しようとしていたのですが、社内のTableauユーザーから好評でありましたため、上長と相談し、月2回開催できるようにしました。 Tableau勉強会「Tableauにおけるパフォーマンス改善」 社内全体でTableauを利用する上での課題で、Tableau ServerのCPUやメモリの使用率が逼迫してしまい、大規模障害発生につながってしまう恐れがあるという課題がありました。この事象が発生する原因の一つとして、ユーザーがTableau Serverに負荷をかけやすいダッシュボードを作っていることがあげられていました。 ですが、Tableau Serverに負荷をかけにくいダッシュボードの作り方をユーザーが知らないということが根本原因でありますため、「ユーザーの皆さんでもすぐに改善できる」というポイントを中心に、勉強会ではお話しました。 その結果、早速パフォーマンスをよくするために、作ったダッシュボードの改善に取り掛かってくれるユーザーが出てきたり、新規作成する際にも、勉強会でお話したポイントを頭に入れてダッシュボードを作ってもらったりなど、社内で少しずつ改善する動きが起こるようになりました。 【社外向け】 Tableauに関するブログ記事の投稿 Tableauに関するブログ記事をいくつか投稿しました。 Tableau Serverのリポジトリについて TableauにはTableau Serverという、作成したダッシュボードを共有するWebアプリケーションツールがあります。その裏にはアクセスデータなどが蓄積されていまして、裏にはどんなデータがあるのかだったり、そのデータの活用事例などをまとめたものになります。 DATA SABER見習いがTableauを使っていて思うこと DATA SABERのプログラムを進めていく中で、Tableauに関する色んな知識、表現技法を習得しました。ですが、どんなに凝ったものを作ったとしても、見る人が正確にデータを読み取れないと意味がないと考えています。「見る人第一のダッシュボードを作りましょう」という自分への戒めの意味も込めた記事になっています。 Visual Analyticsについて こちらは、DATA SABERの課題で私が苦手に感じていた部分をまとめたものになります。データに応じた最適な表現の仕方や、色や形などの人間が無意識に把握できるものを効果的に利用すると、わかりやすいダッシュボードが作成できるということを記事にしています。 Tableau DATA SABERになったので、自分なりの勉強法書いてみる こちらはDATA SABERになった後に書きました。私がDATA SABERにチャレンジしていた際に、どのように勉強を進めていけばいいか悩んでいる時期がありました。そんな私と同じ悩みを持っている方々に向けて、道しるべになればと思い書いた記事になります。 このようにして、DATA SABERで学んだこと、気づいたことなどを、社内だけでなく社外にも展開してきました。 今後もマイナビのDATA SABERとして、データ活用に関する情報発信を実施していけたらと考えています。 苦労したこと 一つ目は時間のやりくりです。 私がDATA SABERにチャレンジしている期間は、通常業務も繁忙期でありまして、学習時間を割けられない日もありました。そのため、上長に許可を得て残業して学習時間を得たり、何とかしてDATA SABERの試練にチャレンジするための時間を得ていました。 また、動画で勉強することもできるのですが、通勤時間に動画を見たり、隙間時間などを勉強に活用していました。 二つ目はデータドリブン文化を作る上でのマインドなどを問われる問題について、何度もやり直しを食らったことです。 tableauをつかってデータを可視化し回答を探し出すという問題とは異なり、この問題はDATA SABERが持つべきマインドを問われるため、DATA SABERのことをちゃんと理解していないといけません。 何度も躓きはしましたが、一緒に挑戦していたS・Sさんと意見交換をしたり、師匠とディスカッションしたりなどを行うことで、DATA SABERとしてのマインドが少しずつ分かるようになってきました。そしてこのマインドこそが、マイナビ社内にはまだまだ足りていないものであり、データドリブンを推進する立場である私自身にも不足していたものであることを痛感しました。 このような苦労はたくさんありましたが、それを乗り越えたが故に、自信につながったかなと今では思っています。 学んだこと Tableauに関するスキルについてはもちろん多くの学びがあったのですが、一番はDATA SABERとして、データドリブン文化を根付かせるためにはどのように行動をすべきなのか、その姿勢や行動指針について学ぶことが多かったと思います。 今までの自分はデータ活用を推進する部門に所属していたものの、ユーザーから来た質問に対して答えたり、データ分析基盤の構築案件で任されたタスクに注力していたりしていました。これらの業務も勿論大切な業務ですが、DATA SABERの試練では 「自分から能動的に動く重要さ」 を学びました。今までの自分はどこか受動的な側面がありましたが、DATA SABERは データドリブン文化を創造する、浸透させる ことが使命です。 受け身の姿勢でいるだけでは、キャッチアップできる社内のデータ活用の課題や悩みなどは氷山の一角に過ぎないですし、データドリブン文化を推進する立場である人間が受け身の姿勢でいては、データドリブン文化はいつまでたっても生まれないと実感しました。 この学びがあったからこそ、最初はDATA SABERの活動の一貫として行っていたデータ活用相談会を、自分が上長に進言して今も継続して活動を実施したりなど、自分自身少しだけ能動的に行動を起こせるようになりました。 これからもこの学びを大事にし、DATA SABERとして能動的にアクションを起こし、データドリブン文化を根付かせていきたいと思っています。 今後のこと DATA SABERとして、データドリブン文化を根付かせるための活動を進めていきたいと考えています。社内外問わずとは考えていますが、まずは社内から根付かせて行けたらと思っています。 そのためには精力的に活動を行い実績を積み、社内にDATA SABERを認知してもらわないといけません。 まずは、データ活用相談会など、引き続きできることを地道に実施を行っていきながら、社内のデータ活用ユーザーと接点を作っていき、少しずつDATA SABERを認知してもらえるようにできたらいいなと思っています。 また、社内にインパクトを与えられるような取り組みも認知には必要かと思っています。ですので、社内でまだ誰も取り組めていないデータ活用のスキルベルト作成の検討も今後行いたいと考えています。 そして、私が今度は師匠となってDATA SABERを育成し、各事業部門でデータ活用が自走できる世界観を作っていけるようにしていきたいと思います。 CASE 2 S・Sの場合 自己紹介 私立大学理工学部数学科卒。 理工学部と聞くと一通りPC操作には慣れている印象を持たれますが、大学時代では採用活動でのESとレポート作成でしかPCを使わなかったくらいの初学者で入社しました。 2022年4月にマイナビに入社し、10月までは技術研修や社内インターンシップを行いました。 2022年10月にT・Sさんと同じ課に配属され、社内のデータ活用基盤の保守運用とデータ活用推進やデータ民主化を主な業務としています。 DATA SABERチャレンジ前のTableau歴・レベル DATA SABERチャレンジ前のTableau歴：2ヶ月 レベル：BIツールがどのような目的で利用されており、Tableauが社内でどのように活用されているのか知っている状態。 2022年8月に社内インターンシップ内でTableauのハンズオンを体験させていただく機会があり、そちらでTableauの存在を知りました。(インターンシップ担当はT・Sさんでした) 2022年10月の配属後に自身の課が行っているTableauの導入相談や利用推進のミーティングに同席するようになったため、Tableauの特徴や役割を知るようになりました。 TableauはセルフBIツールとして現場に提供しており、部署のメイン業務としてダッシュボード作成を行うわけではないため、利用経験はほとんどありませんでした。 チャレンジした経緯 そのままですが、Tableauの知見を増やすためです。 データ活用相談で課の一員として貢献するためにもTableauの知見は必須でした。 ユーザーサポートも一人では行えない状況であったため、Udemyなどを活用して学習を始めた段階でした。 また、社内のTableau利用を推進する為にTableau社主催のイベントに参加し他社事例を伺う機会もありましたが、その際にDATA Saberについての話も耳にすることが多くありました。 学習するなら資格取得という明確な目標を持って取り組んだ方が良いと考えチャレンジを決意しました。 弟子時代に取り組んだこと Tableauの技術力を磨くための十の試練 こちらについてはT・Sさんと同様のため割愛させていただきます。 導く力を鍛えるための、コミュニティ活動(社内外でデータドリブン文化を広めるための活動 ) T・Sさん同様に社内、社外に向けた取り組みを行いました。 【社内向け】 DocBaseによる情報共有 社内のドキュメント共有ツールであるDocBaseにてTableauのTipsをアップしました。 具体的には、細かなフィルターアクションの設定方法や二重軸の設定方法、ウォーターフォールチャートの紹介など知っているからこそ活用できるTableauの機能や活用方法についてご紹介しました。 【社外向け】 Tableau PublicへのVizの投稿 Tableau Publicとは世界中の方がだれでも自身で作成したVizを共有することができるTableauのサイトです。 私は趣味である、海外サッカーについてのデータの可視化を行いました。 ここで自身が作成したVizを共有する事の意義は、単にアイディアを発信するだけでなく、新たな繋がりを作る事ができる点にあります。 私もここでコミュニケーションをとった方のVizから学びを得る機会となりました。 Tableau関連記事の投稿 私は「Tableauの技術力を磨くための十の試練」の考え方について自身のブログに記事を作成しました。 具体的には、パフォーマンスを構成する要素についての記事や社内データ基盤の在り方について記事を作成しました。 この活動は正直他の誰の役にたったかは分かりませんが、インプットした内容をアプトプットする事で内容の整理ができました。 苦労したこと 苦労したことはタスク管理と時間の捻出です。 T・Sさんが初級の試験を着々と突破していく中で、頭からつまずいていました。 はなからそのつもりでのチャレンジではありましたが、想像以上に一つ一つの試験クリアに時間がかかってしまいました。 2022年10月の配属後は1ヶ月間各システムの説明を受けた後に、業務と課内技術研修(バッチや定義書の設計ワーク)を並行して行っていました。しかしその課内技術研修を完了させないままチャレンジを開始し、別途新規業務もいただいてパンク寸前でした。 終盤には上長のご協力で業務量を調整いただいたり、残業での学習時間の確保を許容いただき、なんとか合格する事が出来ました。 「これらの経験を経て、タスク管理について自分なりの方法を見いだす機会となりました。」 とはまだ言えないレベルなので引き続きこの問題と向き合っていきたいと思います。 学んだこと タスク管理やTableauのスキルに関してはもちろん学びがありましたが、その他について記載します。 私が学んだことは 文化醸成の重要性 です。 この資格勉強を通して、Tableauのスキルを叩き込まれました。しかし、Tableauの機能を熟知しているからと言って良いダッシュボードが作成できるわけではありません。 ダッシュボード作成はダッシュボードを作成する明確な目的を持ち、それを達成するためにどのようなデータを用いるか考える必要があります。 その為、直接的にビジネスに携わっていない言わばエンジニアサイドの私がこの力を発揮するには、ビジネスサイドの方々と共通認識を持ち、一緒にダッシュボードの作成を行う必要があります。 その方々の明確な目標とビジネス知識を正確に受け取り、ゴールへのサポートをするのが我々の役割です。 しかし、DataSaber認定後にユーザーのサポートを行った際にはサポートを円滑に行うことができませんでした。 何故かというとお互いの常識を理解していなかった為です。 私はビジネスサイドの理解が浅く、ユーザーはデータの理解が足りていませんでした。 複数の事業を持つ弊社にとって、全てのビジネスについてエンジニアサイドが理解する事はできませんし、他事業部のデータ活用の事例共有や分析用のデータ共通基盤を運用する事は、ビジネスサイドにはできません。 異なる役割の中で 両者が近い距離で、目標を共有し、足並みをそろえて働く事の大切さを学びました。 その為にはこの考え方についても共通認識を持つ必要があり、組織として文化を醸成する事が必要です。 その文化醸成こそが我々DataSaberに求められるものだと学びました。 今後のこと 現在社内に4名いるDataSaberを中心にデータについての考え方を発信して、文化を醸成していきたいです。 また、それに伴う様々な知識やスキルを積極的に会得していきたいです。 文化を醸成する手段がまだ明確ではありませんし、そこで活用するツールがTableauでなければならない訳ではありません。 様々な方法を模索して、一歩一歩着実にこの考えを広めていけたらと思います。 データが集まる会社でありそこにはたくさんの可能性があると思っています。 文化を醸成し、同じ方向を向いて、新たな価値創造に貢献できればと思います。 終わりに DATA SABERにチャレンジしたことを書いてみました。たくさん苦労したり、躓いたりしたのですが、頑張った結果DATA SABERになれたことは大変うれしく思っています。 ですが、2人とも、DATA SABERになれたことがゴールだとは思っていません。 社内に目を向けると、データドリブン文化を根付かせるという大きな目標が存在しています。また、データ活用人材を育成したり、データ活用を行っている人向けに情報発信したりなど、社外においてもDATA SABERとしての役目を果たさないといけません。 師匠は、私たちが社内外で精力的に活動できると期待して、DATA SABERに認定してくれたと認識しています。 その期待に応えられるよう、データ活用の中心的存在となって活動を行っていきたいと考えています。 投稿 Tableau DATA SABERにチャレンジした話 は マイナビエンジニアブログ に最初に表示されました。

はじめに マイナビ内でTableau DATA Saber認定制度に挑戦された3名に、師匠（前編）・弟子（後編）それぞれの立場で2作に分けて体験記を書いていただきました。 本記事では前編・師匠についてお届けします。 自己紹介 ご覧いただきありがとうございます。データソリューション統括部　データ活用推進2課のI・Rです。 この度マイナビのデータドリブン文化醸成の足がかりになればと、DATA Saber認定制度に挑戦し認定されました。また後進育成のため、私自身がDATA Saberで身につけた知識を伝え、弟子も育てることができました。 今回はDATA Saber認定制度のご紹介と、認定までの歩み、後進育成についてお話したいと思います。 データ利活用を進めたいが、勉強のとっかかりがつかめない。 自己流でBIツール（DATA Saber認定制度ではTableau）を利用しているが、技術力に自信がない。 データ利活用を推進するにあたり、周囲を巻き込む方法がわからない。 こういったお悩みをお持ちの方の参考になれば幸いです。 DATA Saber(データセイバー)とは？ DATA Saberは、周囲にデータの重要性を説くデータ分析スキルとマインドを持った人材の育成を目標としたプログラムです。 主催はTableau社の元社員であるKTです。このプログラムは2015年に開始され、2023年6月現在1,300名以上のDATA Saberが育成されています。 DATA Saberは一般的な認定制度とは異なり、単にTableauの知識を持っているだけではなく、データドリブンの文化を浸透させるために必要な情熱や意志を伝えるためのコミュニケーションスキルを身につけることが重要です。 その証拠として、DATA Saberでは必ず師匠と弟子の関係でチャレンジを進めます。 師匠を見つけることも最初の試験となり、DATA Saberになった後に何を成し遂げたいのか、なぜなりたいのかなどを師匠に説得する必要があります。 DATA Saberの試験概要 このプログラムでは、以下の試練を3ヶ月でクリアする必要があります。 ・データ理解に必要な技術力を身につける（全10回の技術試験に満点で合格する） ・データドリブン文化を推進するためのコミュニケーションスキルを身につける（コミュニティ活動を行う） また、試験突破に必要な勉強時間は約100時間程度となっています。 詳細については公式ウェブサイトをご覧ください。 https://datasaber.world/ DATA Saberに認定されるまでの歩み 前述の通り、DATA Saberになるためには現在DATA Saberの方に師匠になっていただく必要があります。 師匠探し まず第一歩目としてTableau社の営業職の方ににDATA Saberになりたい旨をお伝えしました。するとTableau社主催のイベントにDATA Saberの方が講演されると伺い、すぐに参加しました。 講演された方は、Tableauの教育プログラムを自社内用にカスタマイズし、モチベーションとなるよう報酬体系を社内で調整し、BIツールが当たり前に使われる文化を浸透させるまでの軌跡を実体験を交えてお話してくださいました。マイナビにデータドリブン文化を浸透させる足がかりとしてDATA Saberになろうと考えていた私にとって、まさに理想の師匠像でした。 講演後にお話する機会があり、優れた実績を持つ方の弟子として迎え入れていただきたい旨をお伝えしたところ、快諾していただき、無事にDATA Saberのチャレンジが始まりました。 全試験突破までの勉強時間は120時間 試験突破までの苦労については、私の弟子が後編で取り上げていただく予定ですので、詳細には触れません。 Tableauは独学で身につけたため、知らない機能に驚くことはもちろんですが、同じデータでもグラフの作り方1つでより直感的に理解できることを体験しました。 師匠からのレクチャー会や、Twitterを通じてDATA Saberに挑戦中のメンバーとの勉強会、ディスカッションを経て、約2ヶ月半でDATA Saberに認定されました。 DATA Saberになって、なぜ弟子を育てたのか？ DATA Saberになった後、すぐに弟子を取りました。その理由は大きく2つあります。 組織全体のデータリテラシーの底上げ データドリブンな文化を育成するためには、アイディアやノウハウ、気づきを組織内で共有する必要があると考えました。経験や知識を独占せず、他のメンバーと共有することで、個人だけでは気づけなかった洞察やアイディアが生まれるからです。 徐々に集合知を拡大することでデータリテラシーも向上し、組織が抱えるビジネス課題をデータを通じて正しく理解し、解決策を生み出せるようになっていくのではないかと考えています。 部門間の協力体制の構築 新しい文化の醸成は試行錯誤の連続です。1つの解決方法ですべての課題を解決する万能薬は存在せず、さまざまな施策を地道に試していく忍耐力が必要です。そしてこれらの施策には単一の部署ではなく、部門や職種を超えた協力関係が不可欠だと考えています。 DATA Saberでは師弟関係を築き、3ヶ月間で約100時間の密なコミュニケーションを取ります。ここでは、データの活用方法について深く話し合う機会も多くあります。この時間を通じて結束が生まれ、互いに協力し合える関係性を築くことができたと感じています。 今後の師匠としての未来像 ビジネスサイドの課題解決に貢献できるよう、課題の整理から関与し、共に取り組むことを考えています。エンジニア部門やビジネス部門といったセクショナリズムに陥ることなく、最終目標であるビジネス価値の創出に向けて、情報交換を行いながら課題解決を進めていきたいです。 そのための一歩として、データ利活用に興味を持つビジネス部門の方々にDATA Saberの活動についてお話をし、弟子として育成することでデータドリブン文化の醸成に貢献したいと考えています。 ビジネス部門の方々にデータの重要性やその有効活用方法について啓発を行い、共通の認識を持つことで、より効果的な課題解決とビジネス成果の向上を図ります。 またDATA Saberの数が増えた際には、定期的なワークショップや勉強会を通じて、ビジネス部門との連携を強化し、具体的なプロジェクトにおいても共同で取り組む機会を増やすことも考えています。さまざまな視点や専門知識を持つビジネス部門との連携は、より総合的な解決策の発見やイノベーションの創出に繋がると信じています。 これによって、データドリブンなアプローチが組織全体に浸透し、ビジネス課題に対する的確な洞察と戦略的な意思決定が行われるようになることを目指します。ビジネス部門との連携を通じて、より価値ある成果を創出し、組織の成長に寄与することが私の思い描く未来像です。 投稿 データドリブン文化の推進のためにTableau DATA Saberを取得し、弟子を育成した話 は マイナビエンジニアブログ に最初に表示されました。

はじめに この記事は2023年1月に、株式会社マイナビ デジタルテクノロジー戦略本部（以下「デジ戦」）内で定めた「コミュニケーションガイドライン」について、その背景を含めて紹介する記事です。 この記事のポイント コミュニケーションガイドラインとは、コミュニケーションを取るうえで守ってほしいこと、心がけてほしいことをまとめた資料 関心のある人に集まってもらいメンバーの声を聞きながらボトムアップ式に決めていった ガイドラインでは「オープンコミュニケーション」「アジリティの高さ」「目的意識」の3つを必要な心がけとして掲げている コミュニケーションガイドラインの効果については、半期に一度の定期的なアンケートをとることで測定する 背景 2019年末からのコロナ禍を経て、コミュニケーションの取り方は変わりました。 在宅ワークも一般化し、今までは当たり前のように顔と顔を突き合わせて会話していたものが、チャットやハドルミーティングなど、オンライン上での会話がメインになっていきました。 皆さんは、社内コミュニケーションがしやすくなったと感じますか？ 今までよりコミュニケーションが取りやすくなったと感じる方、逆に取りにくくなったと感じる方、様々いらっしゃるのではないでしょうか。 このような感覚の差は、皆さんのコミュニケーションの「常識」が異なることで生まれています。 なかには、コミュニケーションが取りづらくなってしまったがゆえに、仕事の効率が落ちたと感じる人もいるでしょう。 日常のコミュニケーションのモヤモヤによって、仕事にマイナスの影響が出るなんて、とても勿体ないことですよね。 そこで、「デジ戦」内において コミュニケーションの取り方に対する目線を合わせる ため、「 コミュニケーションガイドライン 」というものを作成することにしました。 コミュニケーションガイドラインとは 我々が作成した「コミュニケーションガイドライン」とは、その名の通り コミュニケーションをとるために守ってほしいこと、心がけてほしいことをまとめた 資料です。 コミュニケーションガイドラインを通して「デジ戦」内の コミュニケーションを最適化し、従来の業務の生産性を向上したり、部署を越えたコラボレーションを強化していく ことを目指しています。 あくまで「ガイドライン」ですので、これに違反したからと言って罰則があるわけではありません。 ただ、全員が必ず一度は目を通し、できるだけこれに沿ってコミュニケーションを取っていただきたいという位置づけになっています。 ガイドラインの詳しい内容は後ほどご紹介しますが、ガイドラインは大きく「 コミュニケーションの手段の選び方 」と「 会議開催/参加時のルール 」の2軸からアプローチをしています。 コミュニケーションガイドラインの作り方 プロジェクトの進行は事務局で行いました。 ただし、コミュニケーションガイドラインの作成は「デジ戦」全体に推進メンバーの募集をかけ、 興味のあった人が集まりプロジェクトを企画、そしてプロジェクトメンバーの声を聞きながら民主的に進めていきました。 「デジ戦」はとても人数の多い事業部かつ「デジ戦」の中でもたくさんの部署に分かれています。 そうすると、既にそれぞれの部署における特有のコミュニケーション文化が醸成されております。 また、役職や仕事内容における感じ方の違いも当然あります。 できるだけ多くの人が使いやすいガイドラインにするため、実際に色々な部署の社員の方にヒアリングをし進めていきました。 集まったプロジェクトメンバーは全部で11人。部署も役職もバラバラです。 募集をかけてすぐに予想していたよりも多くメンバーが集まりましたので、急遽締め切りを早めました。 その集まり方から、 社員のコミュニケーションに関する関心（課題）の大きさ を感じました。 ガイドラインはまず事務局で素案を作成し、その後プロジェクトメンバーを3人から4人のグループに分けそれぞれ2回ずつ計8回のディスカッションで意見を出してもらい、それを参考に詰めていきました。 プロジェクトメンバーはコミュニケーションに関心の高いメンバーであるため、ディスカッションでは鋭い意見をたくさん聞くことができました。 おかげで、多くの人に使ってもらいやすいガイドラインになったのではと思います。 完成したコミュニケーションガイドラインの紹介 マイナビ「デジ戦」内コミュニケーションガイドラインの構成はこのようになっています。 ※第1版完成後から改定をしており、2023年4月時点の内容をご紹介します。 必要な心掛け コミュニケーション方法 シチュエーションごとのコミュニケーション方法 会議のルールとコツ ①会議目的ごとのルール ②会議のコツ Web会議のカメラに関して デジ戦内でのチャット利用についてのガイドライン ガイドラインの概要 はじめに、このコミュニケーションガイドラインの目的や適用範囲などを記載しています。 あくまで「ガイドライン」のため、強制力は持ちません。 また、適用範囲は「デジ戦」内としていますが、活用できそうであれば「デジ戦」外の部署や社外の方とやり取りする際にも利用いただくこともOKとしています。 必要な心掛け まずは、コミュニケーションをとるうえでの基本的な心掛けについて言及しています。 我々は「 オープンコミュニケーション 」「 アジリティの高さ 」「 目的意識 」の3つを必要な心がけとして掲げました。 これらを常に意識していれば、自然とコミュニケーションガイドラインに沿った行動をするようになるはずというものです。 コミュニケーション方法 我々はコミュニケーションの種類として「 チャット 」「 短い会話 」「 会議 」「 つぶやき・メモ 」の4つがあると整理しました。 それぞれの定義といつどのように使うのがよいか、ということを説明しています。 シチュエーションごとのコミュニケーション方法 続いて、もう少し直感的にコミュニケーション方法を使い分けられるように、図解しました。 ここでは「緊急度」と「重要度」の2軸で整理していますが「何を緊急（重要）とみなすか」については、個人や部署によって感覚が異なりますので、あえて具体的に示さず、現場に判断をゆだねる形としています。 会議のルールとコツ 会議はどうしても時間を拘束されてしまうため、なるべく減らしたいと考えていますが、どうしても必要な会議はあります。 その会議の時間をなるべく質の高いものにするため、会議のルールを定めました。 また、会議の目的に応じて守るべきルールは異なると考え、会議の目的別にルールを決めています。 ルールとは別に会議の「コツ」として、オフラインとオンラインが混在する会議の際に心がけてほしいことに言及しました。 また、アジェンダや議事メモの作成をルールとしておりますので、そのテンプレートも作成しました。 Web会議のカメラに関して Web会議の「顔出し」についてある程度決めがあった方がいいというご意見のもと「デジ戦」全体にアンケートを取った上で、カメラオンを「推奨」としました。 デジ戦内でのチャット利用についてのガイドライン コミュニケーション方法の中でも特に多く使われるようになった「チャット」について、 メンションの後に「様」をつける や 定型句としての「お疲れ様です」をつける などが人によってバラバラになってしまっていました。 こちらも余計な気遣いなくコミュニケーションをとれるように、ガイドラインを定めました。 コミュニケーションガイドラインの効果測定 コミュニケーションガイドラインを作成したうえで作りっぱなしにしてしまうと、せっかく作ったものの効果がわからずもったいないですし、その時々に合わせて改良を重ねてよりよいものにしていきたいという思いがあります。 コミュニケーションガイドラインの効果がどのくらいあったかについては、半期に一度の定期的なアンケートをとることで測定する予定です。 また、それとは別軸で、ガイドライン作成に協力してもらったプロジェクトメンバーに各部署における状況をウォッチしてもらい、実際の肌感レベルでの状況も聞いていければと考えています。 あとがき 今回のコミュニケーションガイドラインの作成については、「デジ戦」内でそういった取り決めを行うことがあまりなかったため、新鮮で挑戦的な取り組みだったと思います。 プロジェクトメンバーからの意見を通して、隣の部署でもかなり文化が違うことがわかりましたし、意外と社内のコミュニケーションについて課題を持っている人は多くいることが発見でした。 今回のコミュニケーションガイドラインが、少しでもマイナビ「デジ戦」内での働きやすさにつながればいいなと思います。 投稿 デジタルテクノロジー戦略本部のコミュニケーションガイドラインを作成しました!! は マイナビエンジニアブログ に最初に表示されました。

はじめに 皆さんこんにちは。 本日はクリスマスですね！私は幼い頃に両親からクリスマスプレゼントとして、『人生ゲーム』を買ってもらったことがあります。 そんなキッカケもあり、現在はボードゲームが趣味でして、当社のボードゲーム部にも所属しております。 マイナビのボードゲーム部では、業務後、不定期にボードゲーム会を開催して、みんなでワイワイやっています。 そして、閑話休題、今回、当社がお世話になっている某社のご厚意により、非売品の「情シスすごろく」というボードゲームをご提供いただきました。 実体験を基に作成された、リアルな情シスの雰囲気を味わえるボードゲームという事でしたので、早速遊んでみたレポートをお送りします！ 「情シスすごろく」とは？ 「情シスすごろく」は、転職してきたばかりの情シス社員として、企業の情報システム部門の 「あるある」 や トラブル を追体験できることをコンセプトとした、4人用のすごろくゲームです。 トラブルまみれの1か月にしっかり対応して乗り切り、より平穏に過ごしつつ、他者のサポートをより多くできた人が、”情シスの鑑（勝者）”となります。 遊び方 ルール 基本的には手番のプレイヤーがダイスを振ってコマを進める「すごろく」となります。 大きな違いとして、各プレイヤーは5ターン以内にゴールしなければいけません。 （1ターンを1週間とし、5週間（1か月間）乗り切る事に見立てられています。） 途中で止まったイベントタイルに応じてイベントが発生し、メンタルや体力が変化していくのですが、このメンタルの状態に応じて次のターンに振るダイスの種類が変わります。 ※メンタルがボロボロになるとサイコロの目の期待値が下がり、なかなか進めなくなってしまいますが、極限状態では"7"が出ることも！？ 特定の条件を満たすことにより、イベントが発生した際に、他者に協力を仰ぐことができる「ユーザーコミュニティ」に所属することになります。協力したユーザーは協力に応じて「支援回数」を得ることができます。 最終的にゴールできた人（ 1か月乗り切れた人 ）の中で、より 平穏に過ごし （体力が多い）、 他者のサポートをより多く できた（支援回数が多い）人が ”情シスの鑑（勝者）” となります。 準備 各プレイヤーはそれぞれ個人ボードを初期値に設定する。 ■個人ボード プレイヤーの状態を管理するボードです。 ・ターン数 ・メンタル ・支援回数 ・体力 の4項目があり、ゲームで発生するイベントや行動によって変化していきます。 イベントタイルを裏面にしてすごろくのコースを作る。 ■イベントタイル マスに止まった際に発生するイベントが記載されています。 ・社員の端末からマルウェアが発見された ・従業員のIDとパスワードが漏洩した といったインシデントや ・古参エンジニアに相談したら、なぜか怒られた ・本部長に孫の〇witchの設定を頼まれた といったやるせないイベントなどが設定されており、回避するすべを持っていない場合はメンタルや体力にダメージを受けることになります…。 アイテムカードを各プレイヤーに7枚ずつ配る。 ■アイテムカード イベントを回避したり、メンタルなどを回復したりするために使用するアイテムとなります。　　 ・メール誤送信対策ツール ・多要素認証ソリューション といった、インシデントに対応できそうなソリューションや ・焼肉無料券 ・ビール といった、やるせなさを解消できる（？）アイテムなど、色々なものがあります。 イベントの中には「〇〇があれば回避可能」といった記載があるものがあり、該当するアイテムカードを使用することで回避できます。 また、ゲーム後半では、アイテムを捨てる事によってサイコロの出目にプラスしてコマを進めることができます。その際、そのアイテムが「必要ない理由」を宣言する必要があります。 これで準備完了です！ ゲームの進め方 スタートプレイヤーから時計回りに１ターンずつ行い、全員が５ターンずつ実施します。 ターンは以下のように進行します。 ターン進行 個人ボードのターン数を進めます。 アイテムカード使用 使用できるアイテムカードがあれば、このタイミングで使用することができます。 サイコロ振って移動 自分のメンタルに合ったサイコロを振り、出たマス分進みます。 イベントの処理 止まったマスのイベントタイルを開き、イベントの処理を行います。イベントを回避できるアイテムカードがあれば、このタイミングで使用します。 全員が5ターン終わったタイミングで勝者判定を行います。 ゴールまで進めた人の中で、個人ボードの「体力」＋「支援回数」の値が大きい人 が ”情シスの鑑（勝者）” となります。 やってみた はじまり 「もらった。やろうぜ」の課長からの一言で、今回の 「「情シスすごろく」で遊ぼうの会」 が企画されました。 そして翌日にはデジタルテクノロジー戦略本部全体に参加者募集の投稿が行われました。フットワークが軽い！ 幸いなことに多くの方から参加の申込をいただき、無事、開催決定となりました。 ありがとうございます！ 当日 とある日の業務後、会社の会議室で開催しました。 定時で業務を切り上げて会議室へ行くと、既に人が集まっており、みんなで軽い自己紹介を行った後、ゲームを始める事になりました。 ゲームには参加しないけど少しだけ見学を…という方にもちらほら来ていただいていて、そこから話の輪が広がる場面もあり、全体としてわちゃわちゃした雰囲気でした。 （私含め）みんな初めて行うゲームだったので、説明書を見ながらやんややんやと準備を行い、和気あいあいとゲームが進みました。 イベントタイルに止まり、 「突然、全社テレワーク環境の導入がトップダウンで降りてきた」 というイベントが発生した際には、 「あ～コロナ初期のあるあるですよねぇ…。」「ウチはコロナ以前から一部テレワークを導入してたから、他に比べたら多分マシだったと思いますけど…。」 といった、当社の情シスでの出来事を交えながら、リアルな経験を元にした会話が行われたり、 アイテムカードを捨てる際には そのアイテムが必要ではない理由 を宣言する必要があるのですが、 「ウチでは全部Excelで管理するので、プロジェクト管理ツールはいりません！！」 といった爆弾発言で周りから総ツッコミを受けたりと、終始なかなかの盛り上がりを見せていました。 1ゲーム30分程度で終わるため、メンバーを変えて複数回遊ぶことができましたが、色々なあるある話や当社情シスの話などが話され、初対面でも会話が弾んでいました。 感想 本質的にはすごろくなので、サイコロの出目次第のところが大きいのですが、そのおかげで初めての人でも楽しく遊ぶことができたと思います。 人によってアイテムカードを捨てて出目をブーストするタイミングや、捨てる際の言い訳に性格が出ていて、より深くその人を知ることができた気がします。 リアルに基づいたイベント（インシデント）に対して、「〇〇（ソリューション）があれば回避可能」といった回避策が記載されているので、 実際のソリューションに対する理解度 が上がり、ソリューションを導入していない時の リスク等について意識して学ぶ事ができた と思います。 楽しく学べて、情シスの雰囲気もなんとなくわかる良いボードゲームでした！ おわりに 今回「「情シスすごろく」やってみた」という形で記事を書かせていただいたのですが、情シスすごろくに限らず、ボードゲームはプレイスタイルに個人の性格がとてもよく出ると思っています。 自分以外の方の考え方に触れられたり、初めましての方の"人となり"がなんとなくわかったり、普段一緒に業務している人の意外な一面が見れたりと、コミュニケーションツールとして非常に優秀だと改めて感じました。 特に今回の情シスすごろくは、システム系の業務をしている人たちで行った事もあり、イベントタイルのインシデントで一喜一憂したり、アイテムカードを捨てる理由の苦しさにみんなで笑ったりと、和気あいあいと親睦を深めることができました。 また、楽しんでいるうちに情シスについての理解が少し深まるといった学びも生まれたので、情シスなんもわからんって方にも是非遊んでいただきたいボードゲームでした。 以上、お読みいただきありがとうございました。 投稿 「情シスすごろく」をやってみた話 は マイナビエンジニアブログ に最初に表示されました。

はじめに 気付いたらもう12月ですね！あっという間の1年間でした… 最近は冷え込む日々が続いていますが、みなさま体調はいかがですか。 こちらの記事は今年4月に入社し、システム部署の中でも「 基幹システムや情報システムの管理、運用 」を行っている部署に配属された新卒4人で書いています。 ・文系出身でIT職に興味がある方 ・IT職でも開発以外の業務に興味がある方 上記に当てはまる方向けにマイナビの基幹/情報システムに関わる仕事についてまとめました。 「社内SEとは何か」から「社員の1日のスケジュール」など、基幹/情報システム担当ならではの話が盛り沢山なので最後まで読んでいただけたら嬉しいです！ 一般的に社内SEとは？ 社内SEとは 社内のシステムを管理したり、 システム関連で社内で発生した依頼や問題を解決していくお仕事 です。 お客さんとなるのは弊社の社員、営業や経理など非システム職の人が大半です。 社内の人たちが使用するシステムに不具合がでたり、改良してほしいという依頼が出たときに私たちの出番がやってきます。 社内でマイナビすべてのシステムを開発しているわけではないので、ベンダーというシステムを開発してくれる方たちに改修依頼をすることが多いです。 そのため、お客様という意味では弊社内の人ですが、一緒に仕事をするパートナーとしてはベンダーの人も挙げられます。 「お客様（社内の人）の要望を汲み取って、ベンダーの方たちに伝える」というのは非常に重要な業務の一つです。 基盤を支える「 縁の下の力持ち 」であり、立場の違う人をつなぐ「 架け橋 」の役割を担っているのが私たちの仕事です。 新卒4人にインタビュー 配属されてから2か月。新卒の私たちが普段どんな業務をしているのか、業務をしていて感じたことなどを赤裸々に答えました！ ■M.Hさん(基幹システム担当) (1)現在どのような業務を行っていますか？ 「社内会計システムの保守・運用」を担当しています。システムにエラーがでていないかメールでチェックをしたり、案件のリリース準備のため、関係者に連絡を取る仕事を任せてもらっています。 また、週に１回ある会議の進行や議事録作成も行っています。 直近ではプロジェクトのテスト仕様書の作成やレビューの一部をお手伝いさせていただきました。 (2)どんな人が基幹系部署に向いていると思いますか？ 報連相がしっかりできて、状況把握が得意な人が向いていると思います。扱うシステムが多いわりに人が少ない少数精鋭な部署です。 なので、周りの人の仕事量を察して気遣いができる人や、無駄が発生しないよう効率化を意識することが得意である人、連携や確認を面倒くさがることなく行うことができる人が向いているのかなと感じています。 ■Y.Nさん(基幹システム担当) (1)現在どのような業務を行っていますか？ H.Mさんと基本的には同様の業務をしています。 その他に、経理からの質問対応や、申請書類の作成などもしています。 (2)配属前に抱いていた基幹系部署のイメージを教えてください。またイメージとのギャップはありましたか？ ミスが許されないという意味で緊張する部署というイメージが強くありました。 なぜなら研修で基幹系システムは「会社の業務と直接関わるシステム」であり、 基幹システムが停止した場合は、会社全体に影響するので会社への影響度が大きいと伺っていたからです。そのため、自信がある人でないと難しい部署だと考えていました。 安定稼働するのが当たり前のシステムである以上、ミスが許されないという部署イメージは変わっていません。 しかし、配属後ミスが許されないからこそ何事も自信を持っている人よりも心配になってきちんと確認できる人の方が多いというイメージに変わりました。 私たちの部署は、複数人で業務の確認をするなど心配性な人こそ安心できる場所であると現在は考えています。 ■Y.Sさん(情報システム担当) (1)現在どのような業務を行っていますか 「全社向け会計システム」と「システム職向けナレッジ共有ツール」を担当しています。 前者は全社向けということもあり非常に大きなサービスです。ひよっこの私が一朝一夕で管理できるシステムではないので、まずはシステムの使用フローや内部的な機能について学んでいるところです。 後者はアカウント発行依頼の対応や運用改善を行っています。運用改善では、アカウント発行の流れで余分にかかっている手間を省いたり、ユーザーがより記事を共有しやすくするための統制を考えています。 問い合わせ対応はどちらも共通して担当しており、サービスを利用している社員の方々の「困った」や「こんな使い方がしたい」といった問い合わせを調査/検証し、返答しています。 (2)配属前に抱いていた基幹系部署のイメージを教えてください。またイメージとのギャップはありましたか？ イメージとの相違あり/なしでお答えします！ イメージと相違なかったのは業務内容です。SEという職種ではあるものの、コーディングはほとんど行いません。私の場合は皆無です。 メインで行う業務はベンダーさんと社内ユーザーの間を取り持つこと。実際にお話ししている際中に認識齟齬を解決することもあれば、会議のアーカイブを見直して一つずつ取り決めを確認することもあります。 逆にイメージとギャップがあったのは先輩社員の方々の人柄です。 配属前は固い雰囲気なのかなと思っていたのですが、お話好きな方が多いのが少し驚きでした。仕事上で同期との絡みがないので、一人で黙々と作業するのかな…と震えていましたが、課の先輩、上司の方との雑談も交えながら楽しく仕事ができています。 お話しする機会が多いと、業務上で分からないことや困ったことがあったときに相談しやすいのでとてもありがたいです…！ ■R.Tさん(情報システム担当) (1)現在どのような業務を行っていますか 「Webデータベースソフト」と「マイナビグループ社員の情報を一元管理するID管理システム」を担当しています。 ユーザー(社員)からの問い合わせ対応では、システムの仕様をマニュアルで確認したり、実際に動かしてみて、手探りですが自分も学びながら対応しています。 一方で異動に伴う社員や組織の情報の更新や休退職対応や復職対応など、かなり人事に近い業務も行っています。 (2)業務を行う上で意識していること・気を付けていることはありますか？ １番意識していることは「自分の判断だけで進めない事」です。 私が担当しているシステムは人の情報を扱っているのできっとこうだろうという判断で 間違った情報を取り込んでしまったり、データベースを壊してしまうようなことがあれば 社員の業務に直接影響が出てしまいます。 そのため今は少しでも不安なことがあったら先輩に質問を確認をしています。 ただ自分から先輩に確認しに行くなどの積極性は忘れないようにしたいです！ いかがだったでしょうか。 担当するシステムや業務の内容は異なりますが、基幹/情報システムというマイナビの中枢を担うシステムの担当として、4人とも強い責任感を感じながら業務をしていることがわかりました。 先輩へのインタビューと1日のスケジュール これまでは、一般的な社内SEの仕事内容や、新人目線で思ったことや気付いたことについてまとめました。 「コーディングをしないシステム職」の業務についてなんとなくイメージできましたでしょうか？ 次は基幹/情報システム担当として経験を積んだ先輩方、課長・部長にご協力いただき、１日のスケジュールや業務の中で大切にしていることなどを伺いました。 先輩社員インタビュー ■N.Tさん(基幹システム担当) 債権管理システムの保守・運用を行う １日のスケジュール 時刻 作業 コメント 9:05 出社(在宅の場合はPC起動) 9:15 業務開始 基本的には前営業日の残作業や、メールチェックから入ります。対応が必要な事象が発生している場合は、そちらの確認を優先して実施します。 10:00～11:00 改修プログラムの検証環境リリースのために必要な書類の確認 11:00～12:00 昼の予定に合わせて早めのお昼休憩 12:00～14:30 サーバーの月例メンテナンス作業を実施 日中に停止させるので時間厳守で行っています。 15:00～16:00 週次のプロジェクト進捗報告会議と隔週での保守案件の進捗確認会議 プロジェクトごとに先週に実施した案件の説明と、来週にかけて実施する予定の報告をします。また、この日は隔週で実施している「不具合管理システムでのチケットごとの確認」を実施しました。 16:00～17:45 タスク整理と対応 10時からの会議内で話題に上がった内容などについてアクションが必要なものから対応していきます。 マイナビで働いていて思うこと スキルを得るための環境が整備されてきており、非常にありがたい点だと感じています。 会社経費での外部研修を積極的に受けるように推奨されており、自部署では業務へプラスになりそうな分野(直接、間接問わず)について、業務時間内で勉強時間を確保するよう求められています。 K.Sさん(情報システム担当) 全社員が利用するメールツールの管理及びMicrosoft製品全般の管理・導入 １日のスケジュール 時刻 作業 コメント 08:50～09:15 出社 早めに来て優雅な時間を過ごすタイプです。 09:15 業務開始 09:15～11:00 メール確認/スケジュール確認/定例作業 まず私はメール確認とその日のスケジュールを確認します。その後、定例作業(導入しているサービスの定期的なメンテナンスやお問い合わせの対応)を実施します。 12:00～13:00 会議 社内のコミュニケーションについての会議に参加しました。 13:00～15:00 会議 Microsoft製品についての会議に参加しました。 15:00～16:00 会議 実行中案件についての会議を行いました。 17:00～17:45 定例作業 終業前にメール確認・返信と、従業員の方から受けた導入しているサービスについての設定依頼を確認し対応します。 18:00 退社 ※インタビュアーコメント： 12:00～13:00の会議は別部署での企画会議です。 マイナビでは企画策定や開発作業に参加するための公募が多くあり、興味さえあれば参加することができます！ マイナビで働いていて思うこと 私は中途でマイナビに入社しましたが、前職と比べて「休暇が取得しやすい」という点が良いところかなと感じています。 社員の方の中には毎週１日午前休を取得している方や、最近では男性で育児休暇を取得されている方もいます。 上長から有給取得を促される風潮があり、比較的休暇は取得しやすい環境かな思います。 基幹/情報システム担当として大切にしていること 私たちが所属するコーポレートIT統括部ではITを通じて社員の働きやすさや、生産性を向上していくことをミッションにしています。 ■新入社員の気づき 配属されてから一番感じた大切なことは システムの利用者に寄り添うこと です。 これはシステム利用者の言う通りにすると言う意味ではなく、相手の業務内容を知り、 利用者にとってのベストを模索する ということです。 それを実現するために必要な作業は、まずユーザーがどのように担当システムを利用しているのか熟知することです。 例えば、ユーザー（社員）の業務を考えながら担当システムの動作確認をしたり、 ユーザーの普段の業務をヒアリングしたりしています。 ■部長・課長に聞きました 我らが部長・課長に「基幹/情報システム担当として大切にしていることはありますか？」と質問したところ快くお答えいただきました(ありがとうございます…！) 大切にされていることはそれぞれたくさんあったのですが、その中から３つをピックアップさせていただきました！ 1.安定稼働 「ユーザの本来の業務に対してシステムを意識させないほどの安定稼働」が第一です。 動いていて当然とされているシステムたちなので、安定稼働していないと全体的に支障がでます。 ここをいかに担保するかが重要になってきます。 2.現場社員の立場に立って考える システム導入や改修の際に、現場社員が実際の利用の流れを想像できるようにお手伝いするのが 私たちの仕事です。 なるべく画面キャプチャを多く使った資料を作ったり、とりあえず完成品に近いサンプル品を触ってもらうなどして業務が具体的にどうなるのかというのを意識してもらうように心がけています。 3.リスク共有 リスクを予想し未然に防ぐことと、問題が発生してから対処することでは、影響範囲も対応コストも全く変わってきます。 取り返しのつかない問題を発生させないためにも、リスクの予想/共有/対応策の検討は常に行っています。 そのため、ユーザー（社員）に対して事前にリスクを説明しプロジェクトを進めています。 「作業着手が遅れないように〇月〇日までに回答してもらう必要がある」 「数ある要望の中から取捨選択しないと予算オーバーとなってしまう」 「この要望を反映させると○○の処理時間が長くなる可能性がある」 など、具体的に伝えています。 あとがき 最後まで読んでいただきありがとうございました！ システム職＝プログラマーのようにコーディングをする人、というイメージを持っている方に 私たちのように社内のシステムを管理・運用する仕事もあるんだということを知っていただきたく、今回アドベントカレンダー企画に参加させていただきました。 またこの記事を読んで 「基幹/情報システム担当に興味がある！」 「性格的に結構向いているかも？」 と思ってくださった方が１人でもいらっしゃったら嬉しいです。 最後までお読みいただきありがとうございました！ 投稿 コーディングしないシステム職がいるってほんとですか！？～社内SEのお仕事紹介します～ は マイナビエンジニアブログ に最初に表示されました。

はじめに 唐突ですが VSCode の拡張機能作ってみたくありませんか？ 私は日々のコーディングの業務ではもちろん VSCode を使っていますが、痒いところに手が届かないといいますか、自分の思い通りのコードエディタにするために、あと一歩足りない・・・この機能があれば・・・と思うことがあったりします。 みなさんもこう感じた経験ないですか？ こういったニッチな要望に答えてくれる拡張機能があればいいですが、なければ自分で作るしかありません。 ということで今回は VSCode の拡張機能の作り方をこの記事で紹介したいと思います！ とりあえず Hello World してみる デバッグで動かしてみる VSCode の公式ドキュメント の Get Started を見てみるとサンプルの拡張機能（拡張機能の雛形）を作る方法が載っています。 この手順に従ってサンプルの拡張機能を作ってみます。 以下のコマンドを打って必要なモジュールをインストールして雛形を作ってみます。 npm install -g yo generator-code yo code 雛形は yo コマンドが対話的に作成してくれます。 今回は TypeScript を使って雛形をつくることとして、名前は適当に HelloWorld とします。 # ? What type of extension do you want to create? > New Extension (TypeScript) # ? What's the name of your extension? HelloWorld # ? What's the identifier of your extension? hellowold # そのまま Enter # ? What's the description of your extension? Sample extension # ? Initialize a git repository? n # リポジトリとしたい場合は Y を選択 # ? Bundle the source code with webpack? N # ? Which package manager to use? npm # お好みのものを選んでください # ? Do you want to open the new folder with Visual Studio Code? > Open with `code` これで、HelloWorld 拡張機能の雛形が作られました。 このまま F5 を押して拡張機能をデバッグモードで起動させてみます。 HelloWorld 拡張機能が有効になったデバッグ用の VSCode のウインドウが開きます。 この状態で、 Ctrl + Shift + p を押して、コマンドパレットを表示させ、 Hello World と入力するとコマンドがでてきます。 コマンドを実行してみると、右下のテキストボックスに Hello World from HelloWorld が表示されました。 コードを見てみる 拡張機能のエントリポイントは、src/extension.ts 内の activate 関数になります。 中身は です。（実際のコードではコメントが丁寧に入っています。） ▼helloworld/src/extension.ts import * as vscode from 'vscode'; export function activate(context: vscode.ExtensionContext) { console.log('Congratulations, your extension "helloworld" is now active!'); let disposable = vscode.commands.registerCommand('helloworld.helloWorld', () => { vscode.window.showInformationMessage('Hello World from HelloWorld!'); }); context.subscriptions.push(disposable); } export function deactivate() {} コードの中盤あたり の disposable オブジェクトが Hello World を表示させているコマンドの実態です。 let disposable = vscode.commands.registerCommand('helloworld.helloWorld', () => { vscode.window.showInformationMessage('Hello World from HelloWorld!'); }); ここでは、 vscode.window.showInformationMessage 関数を呼び出すコマンドを作成して、そのコマンドの ID を helloworld.helloWorld としています。（ showInformationMessage はVSCode の右下部分にメッセージを表示させるメソッドです） ここで、サンプルの拡張機能で Hello World を表示させたときのことを思い出してみます。 右下に Hello World が出るのはコマンドパレットに Hello World を入力し、コマンドを実行したときでした。 このようにコマンドパレットから実行可能なコマンドにしている部分の記述が実は package.json に記載されています。 package.json の16-23行目に該当の記述があります。 ▼helloworld/package.json（一部抜粋） "contributes": { "commands": [ { "command": "helloworld.helloWorld", "title": "Hello World" } ] }, この部分で、コマンドのタイトルを Hello World とし、 helloworld.helloWorld をこの拡張機能が提供するコマンドとして登録しています。 このようにして、VSCode の拡張機能では package.json とソースコードに所望の処理を記述して、拡張機能を作っていくことになります。 パッケージ化 してみる サンプルの拡張機能の中身を理解できたところで、次はこれを実際に使える形でパッケージ化 してみます。 パッケージ化するところについては の記事がよくまとまっているので参考にします。 （ https://dev.classmethod.jp/articles/easy-vs-code-extension-development/ ） ※ 今回の記事では拡張機能を公開する部分についてはやったことがないので触れません。 パッケージ化するためには vsce コマンドを使うようです。 とりあえずインストールしておきます。 npm install -g vsce 正しくパッケージ化するために、まずは README を編集します。 ここを編集しないと vsce コマンドを実行したときに以下のエラーが発生してパッケージ化できません（2敗） ERROR Make sure to edit the README.md file before you package or publish your extension. # helloworld README sample extension README を直したら vsce コマンドを実行して拡張機能をパッケージ化します。 npx vsce package 場合によっては警告がでるので、適切に対応します。 WARNING A 'repository' field is missing from the 'package.json' manifest file. Do you want to continue? [y/N] y # git リポジトリにしてない場合に発生します WARNING LICENSE.md, LICENSE.txt or LICENSE not found Do you want to continue? [y/N] y 完了すると、 {拡張機能名}-{バージョン}.vsix ファイルが出来上がりました。（ちなみにバージョン名や拡張機能名は package.json で管理されています。） これでパッケージ化は完了です 実際にインストールするときは Ctrl + Shift + x で拡張機能のビューを表示させ VSIX からのインストール を選択し VSCode にインストールします。 おすすめのやり方について話してみる VSCode の API リファレンス を見ると様々な API の使い方が載っているわけですが、API の呼び出し方を説明するのみで、その機能を使うことで見た目がどう変わるのか、内部で何が起こっているのかをイメージすることは正直厳しいと思います。 例えば、エクスプローラーのようなツリー型のビュー（ みたいなやつ）を作りたい場合に、膨大な使い方から作り方を探すのは大変だと思います。 そんなときは、VSCode の公式が公開している サンプル集 をみて、動くものから学んでいくのがおすすめです。 ここでは、よく使いがちな機能のサンプルをまとめており、クローンしてきて実際に動かしてみることで中で何が起こっているのか、見た目にどう影響するのかを確認してみることができます。（ vim エディタ:memo:を作ってみる ってのもあったりします ） 実際に動かしてみて、中身を確認したあと API リファレンス を見ることで理解がしやすくなるんじゃないかと思います。（実際私はそうやって拡張機能の開発をしてます） また、VSCode の UI 構造やロジック部分の記述に慣れてくると、 dockerの拡張機能 や gitlens といった有名な拡張機能のソースコードから、所望の処理の部分を参考にして実装してみるのもいいと思います。 サンプル拡張機能に機能を追加してみる 最後に、紹介したおすすめのやり方でサンプルの拡張機能に の機能を追加してみます。 VSCode の下部ステータスバーに文字を表示させる 文字情報は VSCode の設定画面から指定する ステータスバーに文字を出す部分について調べてみる ステータスバーに文字を追加している拡張機能をサンプルのリポジトリから探してみます。 のコード内、 StatusBar クラスの vscode.StatusBarItem が該当の部分っぽそうです。 https://github.com/microsoft/vscode-extension-samples/blob/main/vim-sample/src/extension.ts ▼vim-sample/src/extension.ts class StatusBar { private _actual: vscode.StatusBarItem; private _lastText: string; constructor() { this._actual = vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left); this._actual.show(); } public setText(text: string): void { if (this._lastText === text) { return; } this._lastText = text; this._actual.text = this._lastText; } } 文字を表示させるには vscode.StatusBarItem オブジェクトを作る必要があり、それは vscode.window.createStatusBarItem 関数で、できるようです。 表示させる文字はどのように設定するのかも見てみます。 同じクラスの setText メソッド内のコードを見ると、 vscode.StatusBarItem オブジェクトの text プロパティに表示する文字を入れているみたいです。 API リファレンスも見てみます。 createStatusBarItem 関数は このリンク をちょっとスクロールした部分に定義がありました。 StatusBarItem クラスについてはこちらの リンク に使い方があるみたいです。 text プロパティを見てみると、どうやら特殊な書き方でアイコンも表示させることができることもわかりました。 設定画面から文字を取得する部分について調べてみる 次に設定画面から文字を得る部分を調べてみます。 このコード の あたりが設定から値を持ってきているところみたいです。 ▼codelens-sample/src/CodelensProvider.ts if (vscode.workspace.getConfiguration("codelens-sample").get("enableCodeLens", true)) { getConfigration 関数の リファレンス も見てみると、 WorkspaceConfiguration クラスのインスタンスを返していることがわかり、 その部分のリファレンス も見てみると get メソッドの使い方も分かってきました。 次に configration とは何かについても調べてみます。 リファレンス を探してみると、package.json に記述する設定みたいです。 参考にした拡張機能の pakcage.json を見ると configration の記述があることも確認できます。 ▼codelens-sample/package.json "configuration": { "properties": { "codelens-sample.enableCodeLens": { "type": "boolean", "default": true } } } 実装してみる これで機能追加する上で必要な情報が出揃ったので、実際に機能追加してみます。 今回は statusBarText という設定を追加してみて、ここの値をステータスバーに出すことにします。（デフォルトの値として default という文字を入れておきます。） また、文字の表示はウインドウが立ち上がったときにしたいので、 activationEvents に onStartupFinished を追加しています。 ▼helloworld/package.json（一部抜粋） "activationEvents": [ "onCommand:helloworld.helloWorld", "onStartupFinished" // 追加部分（拡張機能が有効化されたときに active 関数を実行する） ], ... "contributes": { "commands": [ { "command": "helloworld.helloWorld", "title": "Hello World" } ], // 追加部分 "configuration": [ { "type": "object", "title": "helloworld", "properties": { "helloworld.statusBarText": { "type": "string", "default": "dafault", "scope": "resource", "description": "ステータスバーに表示する文字を設定します" } } } ] } extension.ts にはサンプルのコードを見て学んだ API の使い方を参考に、以下を行うコードを追記します。 ステータスバーを作る 文字を設定から読み込む ステータスバーの文字として設定する ▼helloworld/src/extension.ts import * as vscode from 'vscode'; export function activate(context: vscode.ExtensionContext) { console.log('Congratulations, your extension "helloworld" is now active!'); let disposable = vscode.commands.registerCommand('helloworld.helloWorld', () => { vscode.window.showInformationMessage('Hello World from HelloWorld!'); }); context.subscriptions.push(disposable); // 追加部分 const statusBarItem = vscode.window.createStatusBarItem(); statusBarItem.text = vscode.workspace .getConfiguration('helloworld') .get('statusBarText', ''); statusBarItem.show(); } export function deactivate() {} それではデバッグモードで実行してみます。 値が表示されています 起動したばっかりでは、設定画面で値を指定していないのでデフォルトの文字が表示されています。 思った通りの動作をするか見てみる 次に設定ファイルに値を記入して、表示する文字を変更してみます。 Ctrl + , を入力して設定画面を出して、検索ボックスに helloworld と入力します。 のように設定が出てくるので適当な文字を入れてみます。 この際どうせならアイコンも表示させてみます。（ アイコンの一覧 ） 文字が表示されるのは拡張機能が読み込まれたときなので、再読み込みさせます。 デバッグコンソールを表示している方の VSCode ウインドウから更新ボタンを押して再度デバッグを実行してみます。 下の文字が変更されました！ アイコンもうまく表示できているみたいです！ おわりに 今回は VSCode の拡張機能の作り方と、実際に作るときに参考にしたら良いドキュメントやサンプルコードを紹介しました。 これだけ多くのことができて、自由度が高いところが VSCode が使いやすいソースコードエディタとして知られている理由なんだと思います。 日々の業務で感じている僅かな苛立ちを、自分で拡張機能を作ってみて解決してみてはいかがでしょうか。 投稿 VSCode の拡張機能を作ってみる は マイナビエンジニアブログ に最初に表示されました。

副題: AWSのおかげでグリーンカレーが作れなくなった話 はじめに ※本記事は、AWS Organizations + CloudFormation StackSetsで複数AWSアカウントへのリソース展開を管理している方向けの内容になっています。 昨年、 マイナビ Advent Calendar 2021 にて、 こんな記事 を書かせていただきました。 要約すると、 CloudFormation StackSetsで組織やOUに展開しているCFnスタックについて、 そのデプロイステータスを通知するようにしたかったので、 グリーンカレーを作るついでに強引にデプロイステータスを確認するサーバーレスアプリケーションを作った。 という内容でした。 当時、StackSetsの各スタックインスタンスのイベントを、StackSetsやOrganizationsの管理アカウント側で検知する手段が無かったため、Step Functionsを使って 定期的にステータス変更をポーリングする ことで解決したわけです。 が、 それから約1年の時を経て、2022年11月にAWSから こんなアナウンス が。 Build event-driven applications with AWS CloudFormation StackSets event notifications in Amazon EventBridge 本日より、AWS CloudFormation StackSets で、Amazon EventBridge を介したイベント通知の提供が開始されました。イベント駆動型のアクションは、CloudFormation のスタックセットを作成、更新、削除した後に、トリガーすることができます。これを、CloudFormation スタックセットのデプロイで、CloudFormation API を介して定期的に変更をポーリングするカスタムのソリューションを開発または維持しなくても実行できます。 (　ﾟдﾟ) (つд⊂)ｺﾞｼｺﾞｼ 定期的に変更をポーリングするカスタムのソリューションを開発または維持しなくても実行できます。 (；ﾟдﾟ) (つд⊂)ｺﾞｼｺﾞｼ 　_, ._ (；ﾟ Дﾟ) …！？ つ、ついに待望の機能が実装されました！！！！！ というわけで、とにかくイベント検知ができるようになった以上それを活かさない手はないだろうと、新しく各スタックインスタンスのデプロイステータスを検知する基盤を作り直しました。 本題 通知したいのは、「各スタックインスタンスのデプロイステータスの変更」です。 構成は別に図にするまでもないんですが、一応こちらの青背景部分になります。 SAM実装部分だけ見るとだいぶスッキリしました。 Slack通知をするだけなら、Chatbotを使ったりEventBridgeのトランスフォーマーでSlackAPIを叩いたりすればLambdaを書かなくても良いんですが、 Chatbotの通知内容だと情報が少なすぎる 参考: [アップデート] CloudFormation StackSets が EventBridge を介してイベント通知できるようになりました | DevelopersIO 条件分岐で通知内容をカスタマイズしたい といったことから、Lambdaを通してWebhookでSlackに投げる形にしています。 ついでに、アカウントIDだけでなくアカウント名も通知結果に含めるため、OrganizationsのAPIを叩いています。 また、StackSetsの管理自体は専用のアカウント（StackSets Account）に委任して行っていますが、その場合でもサービスマネージド型のStackSetsのイベントは Organizationsの管理アカウントで検知される ので注意。 実装 SAMテンプレート 何の変哲もない、EventBridgeルールとLambda関数を定義しているテンプレートです。 EventBridgeで拾うイベントタイプは CloudFormation StackSet StackInstance Status Change 、ステータスコードは 公式リファレンス を見てとりあえずオペレーションの失敗・成功を拾うために SUCCEEDED / FAILED / CANCELLED の3つとしています。 ▼template.yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: | Service-Managed StackSets' Stack Instance Status Notification to Slack(webhook) #-----------------------------------------------------------------------------------# Parameters: #-----------------------------------------------------------------------------------# SystemName: Type: String Description: input System Name. Default: stacksets-status-notify Env: Type: String Description: input Env Name. AllowedValues: - dev - stage - prod SlackWebhookUrl: Type: String Description: input Slack Incoming Webhook URL #-----------------------------------------------------------------------------------# Conditions: #-----------------------------------------------------------------------------------# isProd: !Equals [ !Ref Env, "prod" ] #-----------------------------------------------------------------------------------# Resources: #-----------------------------------------------------------------------------------# #---------------------------------------------------------------------------------# # EventBridge Rule #---------------------------------------------------------------------------------# StackInstancesStatusChangeEventRule: Type: AWS::Events::Rule Properties: EventPattern: source: - aws.cloudformation detail-type: - CloudFormation StackSet StackInstance Status Change detail: status-details: detailed-status: - SUCCEEDED - FAILED - CANCELLED Targets: - Id: !Ref NotifyFunction Arn: !GetAtt NotifyFunction.Arn #---------------------------------------------------------------------------------# # Notify Function #---------------------------------------------------------------------------------# NotifyFunction: Type: AWS::Serverless::Function Properties: Description: !Sub - Stack ${AWS::StackName} Function ${ResourceName} - ResourceName: NotifyFunction FunctionName: !Sub ${SystemName}-${Env}-NotifyFunc CodeUri: notify_function Handler: app.lambda_handler Runtime: python3.9 MemorySize: 128 Timeout: 30 Role: !GetAtt NotifyFunctionExecRole.Arn Environment: Variables: SLACK_WEBHOOK_URL: !Ref SlackWebhookUrl IS_PROD: !If [isProd, true, false] NotifyFunctionExecRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${SystemName}-${Env}-NotifyFunc-Role ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Policies: - PolicyName: NotifyFunctionExecRolePolicy PolicyDocument: Version: 2012-10-17 Statement: - Sid: AllowDescribeAccountName Action: - organizations:DescribeAccount Resource: '*' Effect: Allow AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: - sts:AssumeRole Effect: Allow Principal: Service: - lambda.amazonaws.com FunctionLogGroup: Type: AWS::Logs::LogGroup DeletionPolicy: Retain UpdateReplacePolicy: Retain Properties: LogGroupName: !Sub /aws/lambda/${NotifyFunction} RetentionInDays: 30 StackInstancesStatusChangeEventRuleToNotifyFunctionPermission: Type: AWS::Lambda::Permission Properties: Action: lambda:InvokeFunction FunctionName: !GetAtt NotifyFunction.Arn Principal: !Sub events.${AWS::URLSuffix} SourceArn: !GetAtt StackInstancesStatusChangeEventRule.Arn 余談ですが、今回のtemplate.yaml作成にあたっては先日プレビュー版が出た Application Composer を使ってみました。 ただ、 うっかり余計なLambda関数作っちゃってから消してもフォルダは消えてない デフォルトのNode.jsからPythonに切り替えてもindex.jsとpackage.jsonが消えてない handler.handlerをapp.handlerに書き換えてもディレクトリ名は変わらない ポリシーが直書きのみで、IAMのマネージドポリシーを当てる手段が無い そもそもParameterつけられない 、、、と、まだ色々と粗く、結局大半はyamlを直接編集しました。 Windowsじゃなかったらまた違うのかもしれませんが… 今後に期待したいです。 Lambda イベントを受け取って、OrganizationsのAPIで対象アカウント名取得して、整形してSlackに投げてるだけです。 ▼notify_function/app.p import json import os import re from datetime import datetime # noqa: F401 from logging import getLogger, basicConfig, INFO, DEBUG import boto3 import requests # Logger Settings logger = getLogger(__name__) log_level = INFO if is_prod else DEBUG basicConfig(level=log_level) logger.setLevel(log_level) def get_account_name(account_id): """! Get Account Name AWSアカウントIDからアカウント名を取得する @param account_id(str) @return AWS Account Name.(str) """ logger.debug('start func: get_account_name') logger.debug('input: {}'.format(account_id)) if not account_id: return '' client = boto3.client('organizations') res = client.describe_account(AccountId=account_id) account_name = res['Account']['Name'] logger.debug('return {}'.format(account_name)) return account_name def generate_slack_data(data): """! Generate Slack Post Data SlackのWebhookに投げるPOSTデータを生成する。 @param data input event data. @return Slack Post Data.(dict) """ logger.debug('start func: generate_slack_data') logger.debug(data['detail']) stacksets_url = 'https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacksets?permissions=service' # noqa: E501 # Stack Instance account, region stack_instance_stack_arn = data['detail'].get('stack-id', '') arn_pattern = r'^arn:aws:.*?:(.+?):(.+?):(stackset|stack)/?(.*)$' stack_instance_region = re.sub( arn_pattern, '\\1', stack_instance_stack_arn ) stack_instance_account_id = re.sub( arn_pattern, '\\2', stack_instance_stack_arn ) stack_instance_account_name = get_account_name( stack_instance_account_id ) # Stack Instance status stack_instance_status = data['detail']['status-details']['detailed-status'] # StackSet stack_set_name = re.sub( arn_pattern, '\\4', data['detail']['stack-set-arn'] ).split(':')[0] # emoji if stack_instance_status == 'SUCCEEDED': color = '#2EB886' emoji = ':white_check_mark:' else: color = '#A30100' emoji = ':rotating_light:' slack_data = { 'attachments': [ { 'color': color, 'blocks': [ { 'type': 'section', 'text': { 'type': 'mrkdwn', 'text': '{} *<{}|StackSets StackInstance Status>*'.format( # noqa:E501 emoji, stacksets_url ) } }, { 'type': 'section', 'fields': [ { 'type': 'mrkdwn', 'text': '*Account*\n{}\n`{}`'.format( stack_instance_account_id, stack_instance_account_name ) }, { 'type': 'mrkdwn', 'text': '*Region*\n{}'.format( stack_instance_region ) }, { 'type': 'mrkdwn', 'text': '*StackSet*\n{}'.format( stack_set_name ) }, { 'type': 'mrkdwn', 'text': '*Status*\n{}'.format( stack_instance_status ) }, ] } ] } ] } logger.debug('return {}'.format(slack_data)) return slack_data def post_to_slack(slack_webhook_url, slack_data): """! exec HTTP POST request to Slack Incoming Webhook. Slack Incoming WebhookへデータをPOSTする。 @param slack_webhook_url @param slack_data @return Slack Post Result.(bool) """ logger.debug('start func: post_to_slack') headers = { 'Content-Type': 'application/json' } try: res = requests.post( slack_webhook_url, headers=headers, data=json.dumps(slack_data) ) except requests.exceptions.RequestException as e: err_str = str(e).replace(slack_webhook_url, '****') logger.error('[Error posting to slack] {0}'.format(err_str), stack_info=True) # noqa:E501 return False else: logger.info('Slack Post OK.') return True def lambda_handler(event, context): """! lambda handler Lambdaイベントハンドラ。 @param event input Event by EventBridge. """ logger.info('input event: {}'.format(event)) slack_webhook_url = os.environ.get('SLACK_WEBHOOK_URL') if slack_webhook_url: slack_data = generate_slack_data(event) slack_result = post_to_slack(slack_webhook_url, slack_data) if slack_result: logger.info('Function Normal End') else: logger.warn('Slack Webhook URL is Null.') return ログとかdocstringのお作法はこの時点では割と適当です。ごめんなさい。 動かしてみる StackSetsを管理しているus-east-1リージョンにてデプロイ後、適当なCFnテンプレートをSandbox用OUに展開して、テスト用アカウントをOU間で動かしてみたところ、以下のように無事リアルタイムでSlackに通知が来ました。 （念のため、ぼかさなくて良いようなところまでぼかしています） 良い感じですね。 ap-northeast-1リージョンのスタックインスタンスの結果までちゃんと拾えています。 通知のフォーマットは改良の余地がありそうですが、一先ず運用上は充分です。 ポイント 先にも触れましたが、サービスマネージド型StackSetsのイベントはOrganizationsの管理アカウントで発生します。StackSets管理用に委任したアカウントではありません。 Organizationsの管理アカウントで余計なリソースを管理したくない場合は、イベントバス転送で他のアカウントのEventBridgeに転送してやれば良さそう。 「StackSetsを管理しているリージョン」のEventBridgeであれば拾えます。スタックインスタンスがデプロイされるリージョン毎にEventBridgeルールを仕込む必要はありません。 あとがき 今回のAWSの対応で、StackSetsのデプロイ周りが簡単にリアルタイムイベントとして検知できるようになりました。 スタックインスタンス単位で通知が来るので、全スタックインスタンスのデプロイが終わるまで待つ必要もありません。 グリーンカレーを作る時間もなくなりました。 …昨年記事書いてた時は「仮にAWSが対応してこの記事が用済みになっても、レシピとして残そう」とか適当こいてたんですが、本当に対応していただけるとは！！！AWSさん神対応ありがとうございました！！ 投稿 AWS CloudFormation StackSetsの自動デプロイ結果通知を簡単に受け取れるようになったのでやってみた は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは、N.Tと申します。 今回は スマホで始めるRPA と銘打ってRPAを学んで3ヶ月目の新米エンジニアが記事を書かせていただきます。 ・RPAってそもそも何よ！ ・RPA聞いたことあるけど、どんなことできるのよ！ ・RPA触ってみたいけど始め方わかんなーい！ という方にお勧めの記事となっています。 そもそもRPAとは？ RPAとは"Robotic Process Automation"の略となります。 直訳すると "ロボットによる自動処理"で、 意訳すると "人間の行動をロボットに覚えてもらい、人間の代わりにロボットにその行動をしてもらうこと"、となります。 つまるところ、 "業務自動化" の意味合いで良く使われています。 本記事ではその一端となるものをおひとつ紹介しようと思います。 まずは準備を～アプリのインストール～ 今回扱うのはMicrosoft社提供の「PowerAutomate」です。 世界的に使用されているRPAソフトは有名なもので、「 UiPath 」「 WinActor 」「 BizRobo! 」等があります。 そんな中、比較的最近に無料公開されたPowerAutomate君はモバイルアプリver.もリリースされています！ よって RPAをスマホでも始めること ができるわけです！ また、PowerAutomate君はシステムに詳しくない人でも扱えるように、 多くのテンプレートが標準搭載されている のも魅力の一つなのかなと思います！ 本記事ではそんなテンプレートを用いていきます。 毎朝お天気の通知をする！ 私はテレビ離れをしてしまったZ世代なのです。 それゆえに毎朝テレビをつけて天気を確認するといった習慣はとうに消え去ってしまったのです…。 また、朝はできるだけぎりぎりまで寝ていたいタイプです。 コーヒーとトースト片手にベランダで優雅なモーニングに憧れていますが、憧れているだけでいつも寝ています。 出来るだけ、手間は排除したいですね...！ ついでに毎朝欠かさずにモーニングメッセージくれる友人がいたらその日は元気に過ごせるでしょう！ というわけで、エンジニアっぽくこれらの要求をまとめると、 朝起きたタイミングでその日の天気や気温が目に入るようにメッセージをくれる友人が欲しい！ となります！ そんな友人はどこにいるのだろう…？ 答えはスマホの中にあります。 このあとの3ステップでその友人を見つけに行きましょう！ 1st.テンプレートを開こう！ 最初にアプリを開いてテンプレート検索窓に「天気」と打ちます！ 出てきた検索結果から上記のテンプレートを選択、 開いたページから「このテンプレートを使用」を押下し、 以下のような画面が開かれるのを待ちましょう！ 2nd.テンプレートをいじろう！～時間と場所の設定～ 続いて、本格的にテンプレートを触っていきます！ 画像の赤ラインのように「Recurrence(再帰、周期的な起こり)」の中身の 「フロー名」を「毎朝お天気通知をする！」 「タイムゾーン」を「（UTC;09:00）大阪、札幌、東京」 「設定時刻（時間）」を「7」 にそれぞれ変更します！ これで日本時刻の毎朝7時にこのロボット君は動いてくれるようになりました！ それから、 「Get forecast for today(今日の天気予報を取得)」の 「場所」を「東京」に、 「単位」を「Metric」に変更します！ これでロボット君は東京の天気予報をメートル法で取得してくれるようになりました！ 3rd.テンプレートをいじろう！～通知方法と内容の設定～ テンプレートいじりも最終フェーズです！ もともとあった「Send me an email notification(メール送信による通知)」を削除し、 別の通知方法を設定しようと思います！ 下画像の「新しいステップ」を押した後、「アクションの追加」を選択します！ 表示されたアクションの中から、 画像の通り、 「Notifications (モバイル通知を受け取る)」 を選択します！ 無事選択ができたら下のような画面に切り替わると思います。 テキストの欄を自由に記述します！ 今回は画像のように 「おはよう！今日の○○は、日中は○○で、夜は○○だよ！」 とテキストを用意し、 一覧表示される天気情報から「場所」、「日 条件」、「夜 条件」を埋め込んでいます。 これでロボット君がスマホの画面に設定したテキスト内容で通知が届けてくれるようになりました！ いざ実行！ さて、ここまでの流れでロボット君は 朝起きたタイミングでその日の天気や気温が目に入るようにメッセージをくれる友人！ に本当になれたのかをチェックします！ 画像の通り、 下部メニューの「フロー」を選択後、 「今すぐ実行」を押下します。 するとすぐにバナー通知が飛んでくると思います！ 成功ですね！ また、指定した時刻にもロック画面に通知を届けてくれました！ 少々ネイティブですが... 終わりに 改めて、今回は スマホで始めるRPA といった内容の記事を書かせていただきました！ 通知を飛ばしてくれるアプリを使えばもっと楽に天気を知ることができるかもしれないですし、デスクトップ版のRPAツールを用いれば人によってはもっと簡単につくってしまうかもしれません…！ それでも、 RPAってスマホでも簡単に作れるんだ～ って思うきっかけになればいいな～と思って今回の記事を書いてみました！ 少しでも多くの人に興味を持っていただければ幸いです。 今回は、私自身が初心者なこともあり簡単な内容にさせていただきましたが、 もっといろんな使い方ができるのでぜひ調べていただければと思います！ また別の使い方を紹介できるように精進して参ります…！ 投稿 スマホで始めるRPA～チュートリアル編～ は マイナビエンジニアブログ に最初に表示されました。

はじめに 突然ですが、この記事を読んでいるあなたには 「推し」 はいますか？ 愛してやまない人やキャラクター、はたまたツールやプログラミング言語など、何かしら「推し」と呼べる存在がある人は多いのではないかと思います。 筆者にもいわゆる「推し」がいるのですが、ある日こんなことを思いました。 「推しの存在を業務中も感じていたい...！」 そこで今回は、筆者の切な願いを叶えるために、業務に欠かせない存在であるSlackのテーマカラーを、画像ベースで「推し」の概念を感じる色に変える方法を紹介したいと思います。 Slackのテーマカラー まずはSlackのテーマカラーについて仕様を確認します。 Slackでは、環境設定からテーマカラーを変更することが出来ます。 デフォルトで21種類のテーマを選択することが出来ます。 しかし、実はSlackでは自分でカスタムテーマを作成し、好きな色を設定することができます。 （参考： Slack のテーマを変更する | Slack ） それぞれの項目は以下の場所の色に対応しています。 補足 4. アイテムハイライト_ホバー時：サイドバーの項目をマウスオーバーした時に表示される色 6. アクティブアイコン：ユーザがオンラインの時にアイコンにつく印の色 これより、カスタムテーマを作るためには 9色 選ぶ必要があることがわかります。 方法の概要 カスタムテーマに必要な色数がわかったところで方法を紹介していきます。 以下の流れでSlackのテーマカラーを変えていきます。 画像からカラーテーマを抽出する 抽出したカラーをSlackのカラーテーマに割り当てる コントラストを確認しながら微調整する 画像からカラーテーマを抽出する まずは「推し」の画像を用意します。 今回は「いらすとや」さんからお借りしたこちらの画像を使用します。 ゆめかわ天使のイラスト | かわいいフリー素材集 いらすとや 「ゆめかわ天使ちゃん」です。かわいい。 推しの概念を感じる色、それはつまり推しを表現している色に違いありません。 推しの色を知るためには、画像上の色情報(カラーコード)を取得するカラーピッカーツールが便利です。 世の中には多くのカラーピッカーツールがありますが、今回は Adobe Color を使用していきたいと思います。 Adobe Color Adobe Colorを使う理由は以下の通りです。 無料で利用できる 画像に使われている色の数が多くても自動で数色に絞って抽出してくれる 操作が簡単＆時短（休憩中にサクッと設定できる） コントラスト比を簡単に調べられる それではさっそくAdobe Colorを用いて色を選んでいきましょう！ Adobe Colorで色を抽出する方法 Adobe Colorの 「テーマを抽出」 タブを選ぶとファイルをアップロードする画面になるので、説明の通りに画像を選択します。 すると画像の中でメインとなる5色を選択してくれます。 しかし、よく見るとイラストに使われていない黒(#0D0D0D)が選択されてしまいます。 これは元の画像の背景が透過されていることにより、透明部分が黒として認識されるため発生する事象となります。 このような場合や意図しない色が選択されてしまった場合は、ピッカーをずらして選択しなおすと良いです。 今回は目の色に使われている水色部分を選択しなおしました。 これで5色抽出することが出来ました。 一旦Slackに5色配置して、残りの4色を考えていきましょう。 抽出したカラーをSlackのカラーテーマに割り当てる カラーコードってなに？ 各箇所の色はカラーコードで指定することが出来ます。 技術記事っぽくするために カラーコードについて軽く説明させていただきます。 カラーコードとはWebページ上の色指定で使われるコードで、シャープ（#）に続く16進数6桁で表されています。 コンピュータのディスプレイなどの光で色を表現するデバイスは、赤・緑・青の光の三原色を混ぜ合わせる(加法混色する)ことで色を表現します。 赤・緑・青は256段階の強さで光らせることができ、3色の強さの組み合わせで256×256×256=約1600万色を表現することが出来ます。 ＃の次に続く2桁が赤(R)、中央2桁が緑(G)、末尾が青(B)の強さを表します。 前述の通り、光の三原色がもとになっているので、＃000000は黒になり＃FFFFFFは白になります。 カラーコードの意味を知っておくと、コードからなんとなく色味がわかるようになります。 カラーコードにおける＃の右隣の数値を1桁目にした時、1・3・5桁目がe~fであれば白寄りの色だな～とか、RとGの値が大きくてBが少ない時は黄色っぽい色だな～とかが掴めるようになります。 そんなことを思わなくても、世の中にはカラーコードを入れるとその色を表示してくれるサイトはたくさんあるので安心してください。 実はSlack上でカラーコードを入力しても色を表示してくれます。 さて、カラーコードの意味を踏まえたところで実際に配色していきましょう！ 一旦配色してみる まずは画像から色の使われている面積を捉えます。 元にしたキャラの画像を見ると、髪と服のリボンに使われているピンク(#F29BBB)と、天使の輪や髪のリボンに使われている黄色(#F2DAAC)が広い面積に使われていることがわかります。 線の色に使われている薄い紫(#CAC4F2)や目の色に使われている紫(#B48FD9)や水色(#B9E5FF)はアクセントとして使われていることもわかります。 ここでもう一度カラーテーマと画面との対応を見ながら、面積通りに設定していきます。 今回はデフォルトテーマである「オーバージーン」をベースに、 サイドバー背景：ピンク(#F29BBB) トップナビゲーション：黄色(#F2DAAC) テキスト：薄い紫(#CAC4F2) アイテムハイライト_選択時：水色(#B9E5FF) アイテムハイライト_ホバー時：紫(#B48FD9) で配置してみました。（仮置きなのである程度お好みで色配置してもらっても大丈夫です） するとどうでしょう？ 文字、読めない......。 いくら推しの色とはいえ、文字が読めず業務に支障をきたしたら本末転倒です。 これはコントラストを全く考えず配色してしまったため起きてしまった事故です。 次はコントラストを考えながら色を配置し、ついでに残りの4色も決めていきましょう。 コントラストを確認しながら微調整する コントラストとは、 「明暗の差」 のことです。 コントラストが高い、つまり明暗の差が大きいと色と色の境界がはっきりします。 なので文字をはっきり見せるには、背景色と文字のコントラストを高めることが必要になります。 コントラスト比は相対輝度を使って求めることが出来ます。 ざっくりと説明すると、黒の輝度を0・白の輝度を1とした時にコントラスト比を知りたい2色の相対的な輝度を求め、その比を計算することで求められます。 ※詳しく知りたい方は「相対輝度」や「Web Content Accessibility Guidelines (WCAG) 2.1」といった言葉で調べてみてください。 今回は計算する手間を省くため、Adobe Colorを利用してコントラスト比を求めてみます。 Adobe Colorのタブから 「アクセシビリティツール」 を選択します。 先ほどのテキストカラーと背景色を設定しコントラスト比を求めると 1.25:1となりました。 参考に、WCAG 2.1という基準では、「文字を見やすく表示するには 最低限コントラスト比が 4.5:1 必要 」という記載があります。 3分の1以下ですね！！ ですが、これは誰にでも見やすいWebページを作るための基準なのでSlackで自分で使う分には絶対満たさなければいけない条件ではありません。 体感ですが、 2:1以上であればちゃんと読める と思います。 ※個人差もありますしディスプレイによっても変わります 色のついた四角をクリックするとカラーホイールを使って色を調整することができます。 明度を変えるだけではなく、色味(色相)を変えてもコントラスト比は変わるので色々いじって色を調整します。 個人的にコツは、 カラーホイールとカラーハーモニールール を使うことだと思います。 「これだけは絶対使う！」という色を1つ決めて、タブから　 「カラーホイール」 を選び、その色をベースカラーに設定します。 そして、 カラーハーモニールール を変更した時に出てくる色を補助で使うと上手くまとまると思います。 また、カラーホイール上で距離が近い色はまとまりが生まれ、離れている色はアクセントになります。 ※この辺のテクニックは調べるとたくさん出てくると思います。 あとは、サイドバー背景の色は目が疲れないような色(白または黒に近い色が無難)をオススメします。 「テーマの抽出」に戻って、取得しなかった部分の色をピッカーで取得するのも良いと思います！ 今回は、カラーハーモニールールの「類似色」を選択して得た色も使い、カスタムテーマを組みました。 完成！！ というわけで完成しました！ ポイントは 目の色に合わせてアイテム選択時のハイライトとテキストのカラーを合わせた アイテムハイライトのホバー時と選択時の色味を紫に合わせた サイドバー背景とテキストは、髪色のピンクと目の色の紫を調整して配色し、文字を読みやすくした トップナビゲーションに髪色に近いピンクと天使の輪やリボンの黄色を配色 メンションバッジのテキストカラーは白固定なので、メンションバッチの色はコントラスト比の高い色を選んだ という感じですかね！ 正解はないので 自分がそこに「推し」の概念を感じられたら正解 です。 カラーテーマの共有 せっかくなので作ったテーマの共有をしてみます。 Slackにカラーコードをカンマ区切りで投稿するだけで、人に共有できるだけでなくそのままテーマを変更することが出来ます。 さらにカラーテーマ設定画面から、今使っているテーマのカラーコードセットをコピーすることも出来ます。便利！ ぜひ、作ったテーマを共有してみてください！ 今回作成したテーマと普段私が使っているテーマを共有します。 yumekawa-tenshi #FFDFEE,#FFF8D4,#B48FD9,#B1E2FF,#CAC4F2,#916DB5,#FFA1BA,#79CAF2,#FF9CB6,#FFEAAF Blossom Pink #FFE7E3,#89CFF0,#F77D8A,#FFFFFF,#FFC5AD,#F55358,#FFB12E,#DF3232,#EC686C,#FFFFFF オマケ 「とはいえ作るの大変...。」「もっとサクッと作れないの？」「推しなんていないから、キャラクターの画像以外からも良い感じに作れない？」という声もあるかと思うので、他の方法も少し共有させていただきます。 カラーテーマ配布サイトを使う Slack Themes : https://slackthemes.net/#/jellybeans 例えば上記のようなカラーテーマ配布サイトを見て、お気に入りのカラーテーマを見つけるという方法があります。 IDEを模した配色はこのようなサイトで配布されている場合が多いです！ ぜひ探してみてください。 写真から色を抽出する Adobe Colorでは色数の多い写真からも色を5色抽出することができます。 お気に入りの風景写真やCDジャケット・衣装の写真などからも、同様の方法でカスタムカラーテーマ作成が出来ます。 Adobe Colorの「探索」機能を使う Adobe Colorには 色を言葉から検索する機能 があります。 ここから自分好みの色を探してから作れば楽にカラーテーマの作成ができると思います！ 最後に ここまで読んでいただきありがとうございました！ 今回はSlackのカラーテーマに絞って解説しましたが、色の選び方やAdobe Colorといったサービスの使い方は、資料作成に使ったり他のところでも応用できると思います。 働いている時間であっても、少しでも遊び心や楽しい気持ちを感じていただけたら幸いです。 投稿 Slackを「推し」色に染める ~オリジナルカラーテーマの作り方とコツ~ は マイナビエンジニアブログ に最初に表示されました。

はじめに この記事では、AWSの資格であるSAAを取得したもののそこまでAWSを触っていなかったAWS初心者が、業務にそこまで影響がない範囲内でAWSでなんか作ってみようと思い立ち、学習目的半分で試行錯誤した結果触ってみて初めて知った苦労などを記載しています。 AWSを日常的に触っている人にとっては知ってる内容かもしれませんが（もしくは触ったことなくても別に躓かないかもしれない）、AWS初心者でかつ日常的にコードも書かない、データベースの扱いにも全く慣れていない人間としては苦労したポイントがいくつかありました。 「そんなんも知らんのかプークスクス」と笑わずに大目に見てくれると嬉しいです!! 目指したもの Slackのフリープランでも90日前のメッセージを遡れるシステム きっかけ 2022年9月1日からのアップデートで、フリープランだとSlackで共有されたメッセージやファイルは90日経過後に閲覧できなくなりました。 社内のコミュニケーションにメイン使っているエンタープライズプランのものとは別に、アラート発報用のワークスペースをフリープランで契約しており、Slackでの契約プランは変更せずなんとか90日経過後でもメッセージが遡れるようにできないかという思いから作ってみました。 作ったシステムの概要 簡易構成図 大体の仕組み EventBridgeで毎月1回Lambda実行し、Slackに全メッセージを取りに行く Lambdaで取得したメッセージのファイル形式を変換し、S3に保管する Athenaで取得したい要件に合わせてクエリを投げる チャンネル名、日付、etc... 90日経過で消えるので月一じゃなくてもいいのですが、万が一コケた時に気付くのが遅れないよう月一実行にしました。 ※2022年8月のまだプラン内容が変わる前に、下準備として取り急ぎ全メッセージ取得しておきました。90日過ぎたら泣いても笑ってもプラン変更しないとメッセージ取得できませんのでご注意ください。 また、通常ログの保存や検索にはElasticSearchを使うのがベストプラクティスかと思いますが、今回は以下を理由にAthenaを採用しました。 クエリごとの課金となるので比較的コストを抑えられる システムの使用頻度的に、正直そこまでクエリ投げないであろう想定 サーバレスなのでインフラの面倒を見る必要がない クエリできるデータ形式が豊富である 正直に言うとAthenaを良い感じに使ってみたかった（本音） 個人的に苦労した実装に対しての感想 何度でも言いますが、大目に見てください... Athenaでクエリできるファイル形式がなんか思ってたのと違ったんだけど Athenaでクエリできるファイル形式としてcsv、parquet、jsonなどが公式で紹介されています。 AWSユーザーガイド : サポートされる SerDes とデータ形式 今回はSlackの検索結果がJSON形式で簡単に取得できるためJSON形式を選びましたが、 厳密には単なるJSONではない ことにすぐ気付けず、少し悩んでいた時間がありました。 公式ドキュメントには、サポートされるJSON形式について以下のように説明されています。 JSON (JavaScript Object Notation) JSON データでは、各行がデータレコードを表します。 各レコードは属性/値のペアと配列で構成され、それぞれがカンマで区切られます。 つまり、複数レコードの場合は、 [ {"key1": "value1", "key2":"value2"}, {"key1": "value1", "key2":"value2"}, {"key1": "value1", "key2":"value2"} ] ではなく、 {"key1": "value1", "key2":"value2"} {"key1": "value1", "key2":"value2"} {"key1": "value1", "key2":"value2"} としてファイル出力する必要があり、この形式は JSON Lines と言われている書式となります。 つまり、取得したJSON形式のファイルを更にJSON Lines形式へ変換する必要があります。 JSON Lines形式を扱う方法はpandasなどいくつかありますが、今回は jsonlines のライブラリを使って実装しました。 import jsonlines content = [ {"key1": "value1", "key2":"value2"}, {"key1": "value1", "key2":"value2"}, {"key1": "value1", "key2":"value2"} ] path = "/your/path/to/store/file.json" with jsonlines.open(path, mode="w") as writer: writer.write_all(contents) JSON形式と言われると、通常はファイル全体がJSONオブジェクトとして解釈可能である必要と思い込んでいました。 自分としては正しいJSON形式で出力しているにも関わらず、Athenaでクエリが失敗するため、何故…となり、地味に調査に時間がかかったポイントでした。 Athenaを使ったことがある方なら知っていることかもしれませんが、Athena初体験だったので印象に残っています。 S3にファイルをアップロードする際の暗号化の仕方ってマネージメントコンソール使わない時どうすればいいの？ S3にファイルをアップロードする際、何らかの暗号化を施すことが多いかと思います。 マネージメントコンソール上で操作する際は画面上で選択すればよさそうですが、API上でどう指定すればいいのか知らなかったため苦労しました。 API上では、呼び出す際に指定する引数に以下のように ExtraArgs 内で指定するとSSE-S3により暗号化され、アップロードできます。 import boto3 bucket_name = "bucket name" object_name = "object name" s3 = boto3.resource("s3") s3.Object(bucket_name, object_name).upload( ExtraArgs={ "ServerSideEncryption": "AES256" } ) ちなみに、ここで AES256 を aws:kms に置き換えると、AWS KMSと連携して別のキーで暗号化できるため、ここは要件によって変えればよさそうだなと思っています。 Athenaのスキーマ作成の手間が思ってたより多くて諦めそうだった AthenaでJSONをクエリするためには、テーブルを作成する必要がありましたが、通常のSQLとスキーマの定義方法が異なります。 特に、 ネストしたJSONをテーブル上で定義する SQLとのデータ型の違い 暗号化・GZIP圧縮した元データの参照方法 は、テーブル作成において何度か詰まって確認したポイントです。 ただでさえデータベース苦手なので、何言ってんだこりゃあ…となりました。 以下は実際に作成したスキーマです。 CREATE DATABASE IF NOT EXISTS your_database LOCATION 's3://your-bucket/'; CREATE EXTERNAL TABLE IF NOT EXISTS `your_database`.`your_table` ( iid string, team string, channel struct< id: string, name: string>, type string, user string, username string, ts timestamp, text string, permalink string ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' WITH SERDEPROPERTIES ( 'ignore.malformed.json' = 'FALSE', 'dots.in.keys' = 'FALSE', 'case.insensitive' = 'TRUE', 'mapping' = 'TRUE' ) STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://your-bucket/' TBLPROPERTIES ( 'has_encrypted_data' = 'true', 'classification' = 'json', 'write.compression' = 'GZIP', 'classification' = 'json' ); テーブル定義内の channel のカラムで、このキーはJSON上ではネストしたオブジェクトとして表現されていました。 このようなデータはAthenaでは struct（構造体） と表現されています。 AWSユーザーガイド : Amazon Athena のデータ型 今回は、 channel のオブジェクトの内一部が必要だったため、構造体として以下のように定義しました。 channel struct< id: string, name: string>, また、 timestamp にはJSON上では小数点付きのUNIXエポック時間が格納されていますが、このままでは不便なのでこのカラムには timestamp型 を設定しました。 これにより、日時でクエリしたい場合は、 SELECT * FROM "your_database"."your_table" WHERE ts > timestamp '2022-10-25 00:00:00' のように、日付文字列で直観的に検索が可能となります。 さらに、今回は参照するオブジェクトをSSE-S3による暗号化とGZIP圧縮しています。 そのため、テーブル定義の TBLPROPERTIES セクションにて以下のように指定しました。 TBLPROPERTIES ( 'has_encrypted_data' = 'true', 'classification' = 'json', 'write.compression' = 'GZIP', 'classification' = 'json' ); これで、元データが圧縮かつ暗号化されたデータでもクエリしてくれるようになります。 ちなみにですが、今回はAthena検索時のS3のパーティションは分けずに進めています。 ファイルは月毎に生成される想定なので、クエリを投げる際は全文検索のようになり、パーティション分けても分けなくてもこのシステムの構成上変わりはないです。 しかし、ファイル保存量が多かったり、クエリを投げる際の条件でもっと絞れるようでしたら、パーティションを分けた方が費用面でとてもよいです。 Amazon Athenaの料金 現在はこのシステムを作ったばかりなのでファイル量が多くなく、クエリ回数が少なく済んでいますが、今後のことを考えるとファイル保存方法の仕様を見直したいと思います。 EventBridge「cron式です（大嘘）」 EventBridgeで毎月実行のスケジュール登録する際、普通のcron表記と書き方が違ったのでおや…と思った部分になります。 今回はマネージメントコンソール上でやってたので時間がかかったとかよくわからなかったとかではないのですが、マネージメントコンソールを使わず設定してたら詰まったかもしれないなと思います。 AWSユーザーガイド : ルールのスケジュール式 例えば、毎月6日の7:00に実行する、というのを書こうと思うと 0 7 6 * * となると思いますが、AWSのドキュメントでは以下のように記載されています。 ? (疑問符) ワイルドカードは任意を意味します。 [日] フィールドに 7 と入力し、7 日が何曜日であってもかまわない場合、[曜日] フィールドに ? を入力できます。 さらに、最後尾には年も指定することになります。 今回は下記のようになります。 0 7 6 * ? * 実際の設定画面はこちら↓ マネージメントコンソールに従って設定していくとそこまで時間のかかる躓きポイントではないのですが、気になったのでいろいろ調べてみると下記の記事を見つけました。 記法に注意が必要そうな場面も出てきそう、ということで覚えておこうと思います。 参考 : クラスメソッド AWSでのCron表記でハマったので仕様を確認しておく なんやかんやあってできあがったもの こんな感じのものができました。 例えば、チャンネル名を指定して、指定のチャンネル内で交わされた全メッセージを見てみたいと思います。 見せられる部分が少なくて恐縮ですが…一応当初の想定通り、90日以上前のメッセージも取得できています。やったね！ おわりに 今回はAWSの学習目的の元、Slackメッセージを取得しておいていつでもメッセージを見ることができるシステムを作りました。とりあえず動いてはいます。動いてるってすばらしいね。 ここまで書いておいてすごい今更なのですが、メッセージ数によっては有料プランに変更した方が結果的に安く済むかもし楽じゃない？、みたいな見方ももちろんあります!!ただ、今回のことを通じて1つ勉強になったので、良い機会だったなと思います。 まだまだ改修すべき点や設計を見直したい箇所、考慮漏れもありそうですが、とりあえず今動かしている部分で書ける分だけ今回記事にしてみました。 今後勉強すると共に、定期的に見直していきたいです。 今回の体験で、資格取得だけでは知り得ない世界を少し垣間見ることができてとてもよかったです。 お読みいただきありがとうございました。 投稿 普段AWS触ってない人間がLambdaとAthenaでなんか地味に苦労した話 は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは。 プロセスデザイン部 コミュニケーションデザイン課です。 ITを通じコミュニケーションを最適化する ことをミッションとして、今年の4月に新しく発足した部署です。社内のコミュニケーションを活性化させることで「 横串の業務改革 」や「 サイロ解消 」を目指しています。 今回は組織の紹介も兼ねて、私たちがどのような活動を行っているのかを書いてみたいと思います。 どんなことをする部署？ ITの企画部門 私たちは全社のITを管理する部門の中で、 今後の社内のIT環境を考えることを専門としている企画部門 です。 企業は常に変化し続けていかなければならず、 それに対応して社内のIT環境も変化し続けていく必要がある と考えています。 DX推進PJに参加 マイナビでは、IT部門だけでなく総務や経営企画といった管理部門と、事業部の有識者を集めて全社横断のDX推進PJを発足しています。 DX推進PJでは「横串の業務改革」「データ利活用」など様々なテーマを扱っています。私たちはその中の「 サイロ解消・情報共有 」に関する分科会に参加しています。 コミュニケーションの活性化を目指して サイロ化ってなに？ 「サイロ化」という言葉を知っていますか？ 組織ごとに業務プロセスやシステムなどが独自に存在し、全体で連携できていない状態のことを指します。 特に、企業で部署同士が縦割り状態になり、部署間の横の連携が取りづらい状態のことを「 組織のサイロ化 」と呼びます。 組織の縦割り状態は、各部署が各々の役割に専念できるというメリットがある一方で、互いが何をしているのかがわからないため、 企業全体でみたときには効率が悪く成長を阻害する 要因ともいわれています。 私たちの部署では、社内のコミュニケーションを活性化させることで、サイロ化を解消することを目指しています。 オープンコミュニケーションが大事 私たちの部署のミッションを達成したとき、マイナビはどのような状態になっているんだろう？ 組織が発足したときにみんなで考え、以下のような状態を"目指すべき姿"としました。 組織を横断したコミュニケーションが活発化することで、 今まで共有されていなかったナレッジが共有されたり、新しいコラボレーションがうまれる など、様々な化学反応が起きる状態 そのためには、誰もが見られる場所でコミュニケーションをすること＝ オープンコミュニケーション が重要になると考えています。 まずは社内の課題を洗い出す 今年の4月に部署が発足してから、まずは社内のIT環境の実態を調べることから始めました。 サイロ化は本当に起きているのか？何か原因となっているツールがあるのか？など、今後のあり方を考えるために現状の課題を知ることを目的としました。 マイナビ社員約7,000人を対象にしたアンケート調査と、全国の様々な職種の社員15名にインタビューを実施しました。 社内調査をスクラムですすめてみた 社内の課題を洗い出すプロジェクトでは、運営をアジャイルの代表的な手法である「スクラム」をベースとして行うことにしました。 スクラムというとシステム開発で用いられるのが主流ですが、今回のような システム開発ではない案件にも適用できます 。 スクラムを用いることにした背景は大きく分けて2つあります。 一つ目は「 チームメンバーがほぼ全員初対面同士であったから 」です。 コミュニケーションデザイン課とEX推進課という二部署共同でおこないましたが、どちらも2022年4月に新設されたばかりでした。3月までの職種や業務内容もみんなバラバラでした。 それぞれ価値観にギャップがあり、プロジェクトに対する目線を合わせるのが難しい状況だったのです。 そのため、コミュニケーションをとる頻度が多くなるように工夫されているフレームワークを用いたいと思い、スクラムを取り入れることにしました。 二つ目は、「 全社的な規模でのアンケート実施を行った実績がなかったから 」です。 IT部門が主催する調査としては前例がないものであり、ノウハウや工数などが非常に不透明な状態で進める必要がありました。 そのため、プロジェクトレベルで見ても臨機応変に動くことのできるよう、工数を相対的に見積もりつつスプリント単位で動きを変えることのできるスクラムを取り入れることにしました。 スクラムの経験値があるメンバーは過半数以下でしたが、 初動で丁寧にスクラムについて説明を行った ことで上手く浸透し、プロジェクト自体もスムーズに進行することが出来ました。 皆さんも、 初対面のメンバーで新規案件を取り扱う場合には、スクラムで進めてみてはいかがでしょうか？ これから取り組むこと 社内調査でわかったこと ITツールに関する社内調査によって、同じような役割のツールが社内でたくさん使われていることがわかりました。 特にチャットツールは、IT運用部門が管理している全社導入済みのツールが2種類あるほか、各現場が独自に導入しているツールも散見されました。 各現場によってメインで使っているツールが違う 状態です。 ツールが異なることにより、他事業部と連絡したいときに何のツールを使えばよいかわからなかったり、色んなツールから連絡がくるので通知を見落としたり、どこでやり取りしたか分からなくなるなど、 ちょっとした不便が起きている ことがわかりました。 ▼各コミュニケーションツールの利用率 C～Eは現場が独自で導入しているチャットツールですが、多いものだと約3割の社員が使っているという状況です。 インタビュー調査から、メールを含めると 常時3～4つのツールを使い分けている 社員がいる（！）こともわかりました。 社内の交通整理が必要 こういった状況を受けて、社内向けにチャットツールのガイドラインを作成しました。 マイナビで利用可能なツールを一覧化し、利用を推奨するツールや各ツールの特徴、現場で独自に導入する場合の申請方法などをまとめています。 社外からの要請などやむを得ない事情もあるので、利用するチャットツールをひとつに限定することは難しいと考え、まずは 社内のやり取りのスタンダードを決めて社内に発信 しました。 とはいえ、ツールの数の多さ自体にも問題があると考えており、今後は抜本的な見直しも図っていきます。 まだ結論は出ていませんが、今後 社内のチャットツールを統一し、全社共通のコミュニケーション基盤を構築していく 想定です。 ツールを統一するだけでよいの？ 残念ながら、社内の チャットツールをひとつにしただけでは、コミュニケーションは活性化しない と考えています。 部署を横断したやり取りや新しいコラボレーションが発生する状態になるためには、 オープンコミュニケーションの文化をつくっていく 必要があります。オープンな場で気軽に発信できるような、心理的安全性が確保されている組織風土の醸成です。 文化や風土の醸成は、一朝一夕でできるものではありません。 コミュニケーション基盤を構築した後には、その環境をどのように使ってもらうかを考えながら、 オープンコミュニケーション文化を醸成できるよう、様々な仕掛けをおこなっていきます！ 投稿 DX推進のために社内ITツールの利用状況を調査した は マイナビエンジニアブログ に最初に表示されました。

はじめに AIシステム部のS.Kと申します。 今回はAtCoderで水色まで到達した身として、さまざまな場面で役に立つ計算量についてまとめていこうと思います。 計算量という概念はアプリケーションに必要な計算リソースを見積もるのに便利な道具です。 従量課金制のクラウドサービスが主流 になっているこの世の中で、必要な 計算リソースを意識するのはとても重要 です。 また、AtCoderをしていると、嫌でも 計算時間 を気にする必要があります。基本的に1回の実行に対して 実行時間は2秒まで という制限があるからです。自分が書いたソースコードの実行時間が2秒程度で収まるのか、計算量を考えるとおおよその見積もりが立ちます。 アルゴリズムの性能を測る上で避けては通れないキーワード 「計算量」 について、可能な限り分かりやすく解説できればと思います。 計算量って何？ そもそも計算量とはなんでしょうか？ 計算量という概念は主に計算複雑性理論で使われる言葉です。 計算複雑性理論のWikipedia ではこんな記載がありました。 以下引用 アルゴリズムの計算量（けいさんりょう）とは、計算機がそのアルゴリズムの実行に要する計算資源の量をいい、アルゴリズムのスケーラビリティを示す。形式的には計算機をチューリング機械やランダムアクセス機械（random access machine）などの計算モデルとして定式化したうえで、アルゴリズムの使用する資源の量を入力データ長などに対する関数として表す。計算モデルの瑣末な詳細に影響を受けないよう、計算量はその漸近的な挙動のみに注目し、定数倍を無視するO記法で書き表すことが多い。 えーーっと……？ よく分からないので コトバンクの「計算量とは」 のページを見てみましょう。 以下引用 世界大百科事典 第２版「計算量」の解説 けいさんりょう【計算量 computatinal complexity】 アルゴリズムの計算効率や問題の難しさを測るための尺度。主なものに，時間効率を測るための時間計算量，メモリー効率を測るための領域計算量などがある。他にも，計算回路の性能を議論するための計算量や，分散処理でのプロセス間の通信効率を測るための計算量など，用途に応じてさまざまな計算量が用いられている。　コンピューターで仕事を処理したり問題を解く場合，計算手順(アルゴリズム)の善し悪しで，プログラムの計算時間や使用する記憶容量が大幅に異なってくることが多い。 少し分かってきました。まとめてみると、計算量とはこういう概念です。 計算量の代表的なものとして、 時間計算量 と 領域計算量(空間計算量とも言う) がある。 計算手順の良し悪しで、必要な計算時間や記憶容量が異なる。 時間効率を測るのに時間計算量が用いられる。 メモリー効率を測るのに領域計算量が用いられる。 他にも用途に応じてさまざまな計算量が用いられている。 すなわち、以下の二つのことが言えます。 時間計算量が小さい→計算時間が短い 領域計算量が小さい→必要な記憶領域(メモリ量)が少ない なので基本的に 「計算量が小さければ小さいほど、いいアルゴリズムである」 と言っていいでしょう。 計算量の記述方法「ランダウの記号」とその意味 計算量を記述する方法として「ランダウの記号（ 参考:Wikipedia ）」が用いられます。\(O\)という記号を使った、このような記述方法です。 このアルゴリズムの時間計算量は、入力とするデータの個数を\(n\)とした時、\(O(n)\)である。 「\(O(n)\)」の部分は「オーダー \(n\)」と読みます。これの意味は 「このアルゴリズムの時間計算量は、入力とするデータの個数に(\(n\)に)比例する。」 という意味です。言い換えると、「データの個数(\(n)\)が倍になると、計算時間も倍になる」という意味になります。 このカッコの中身は、任意の\(n\)についての関数が入ります。 具体例を見てみましょう。 時間計算量が \(O(n^2)\) 時間計算量は\(n\)の2乗に比例する。つまり、\(n\)が2倍になると計算時間が4倍になる。 \(n\)が増加すると、 計算量が\(O(n)\)のアルゴリズムよりも計算時間が長くなりやすい 。 時間計算量が \(O(\log(n))\) 時間計算量は\(log n\)に比例する。つまり、\(n\)が2倍になると計算時間は\(log2\)増加する。 \(n\)が増加しても、計算時間は少しずつしか長くならない。 時間計算量が \(O(2^n)\) 時間計算量は\(2^n\)に比例する。つまり、\(n\)が2倍になると、計算時間が\(2^n\)倍になる。 \(n\)が少しでも増加すると、計算時間がとても長くなる。 時間計算量が \(O(c)\) （cは実定数とする。） 時間計算量は 常に一定 である。つまり、\(n\)が増加しても計算時間は変化しない。 つまり、この記述が表すのは 「データ量 \(n\) が増加(減少)した時、処理時間がどの程度増加(減少)するか」 なのです。計算量が空間計算量の場合は、 「データ量 \(n\) が増加(減少)した時、処理に必要する記憶領域がどの程度増加(減少)するか」 を表すことになります。 計算量が\(O(log n)\)であれば、データ量が増えるとしても、計算時間はそこまで長くならないので対して心配する必要はありません。しかし計算量が\(O(2^n)\)であれば、少しでもデータ量が増えると、計算時間がとても長くなってしまう、ということが分かりますね。 この様に計算量は何か基準となる変数(上記の場合は\(n)\)を決めて、それを使って記述します。\(n\)の取り方は他にも以下の例があるでしょう。 入力が文字列\(S\)の時、文字列\(S\)の長さ(文字数) 入力が整数\(N\)の時、\(N\)そのもの \(N = 2^n\)と表した時の\(n\)、(すなわち\(log N\))を基準とすることも多いです。 入力がグラフ構造を持つとき、その頂点の数。 色々書きましたが、ここでは、 「\(O(n)\) （オーダー \(n\) ）ってそういう意味なのか！！」 というのが伝われば大丈夫です。そして 「\(n\)について増加しやすければしやすいほど、計算量が大きい」 ということに気を付けましょう。 詳しい数学的な定義が気になる方は、 ランダウの記号のWikipedia に十分な記述がありますので、目を通していただければと思います。 計算量の求め方 では、具体的な計算量の求め方を見てみましょう。今回は時間計算量に焦点を当ててみようと思います。 以下のPythonのソースコードを見てください。 cnt = 0for x in range(n): for y in range(n): for z in range(n): if x + y + z == w: cnt += 1print(cnt) このソースでは0以上\(n\)未満の整数3つの組み合わせで、その和が w になるものがいくつあるかを計算しています。 このソースの計算量は\(O(n^3)\)になります 。 この計算量になる理由は、 「【x+y+zがwと一致しているか】を確かめる演算を合計で\(n^3\)回するから」 です。forループの中の演算が何回行われるかを数えればいい訳ですね。 では次のコードを見てみましょう。 cnt = 0for x in range(n): for y in range(n): if 0 <= w - x - y < n: cnt += 1print(cnt) これは1つ前のコードと全く同じ結果を出力します。wと、2つの整数の和の差が0以上 \(n\) 未満であれば、整数3つの組み合わせで、その和がwになるものが存在するからです。 このソースの計算量は\(O(n^2)\)になります 。 「【w-x-yが0以上、\(n\)未満であるか】を確かめる演算を合計で\(n^2\)回するから」 が理由です。 計算量を求める場合はこのように、 「演算を行う回数を\(n\)を用いて記述した式」 を考えればよい訳です。これを考えることで、\(n\)が増加すると計算時間がどの程度長くなるのかが分かる、という訳ですね。 こうして計算量を考えることで、「処理の内容が同じだとしても、記述の仕方で処理速度がどの程度変化するか」を定量的に把握することができるのです。 ライブラリを利用する場合 現在のアプリケーション開発において、ライブラリの利用は不可欠なものです。そうなった時、 アプリケーション全体の計算量 を見積もるためには、 ライブラリで提供されている関数や、クラスのメソッドの計算量 を把握しておく必要があります。 これに関しては以下の対応が必要かと思います。 ドキュメントから仕様を確認する。 どのような処理を行っているのかドキュメントを確認し、その処理に必要な計算量を見積もる。 場合によっては計算量そのものの記載がある。 ドキュメントのみからでは正確な見積もりができない場合もある。 実際のソースコードを読み込む。 上記の手法で計算量を見積もる。 かなり正確な見積もりができるものの、ドキュメントを読むよりも時間がかかることが想定される。 どこまで正確な見積もりが必要になるかは、ケースバイケースだと思います。実際に実行した時の処理時間を計測した方が有効な場合もあるかと思います。 業務での計算量 例えば、Webアプリの計算量(時間計算量、空間計算量の両方)を小さくすると、以下のメリットがあるかと思います。 バックエンドでの計算量が小さい時 ユーザーの待ち時間が短くなる。 処理時間に対して従量課金がある時、利用料金が安く済む。 使用したメモリに対して従量課金がある時、利用料金が安く済む。 フロントエンドでの処理時間 ユーザーのPCにかかる負荷が軽減される。 UI/UX改善に繋がる。 フロント側の処理が重くても待ち時間の増加に繋がります。 以下のような場合は特に、より正確な計算量の確認が重要でしょう。 処理で取り扱うデータの量が膨大なとき。 計算リソースに制限があるとき。 「どの処理について」の計算量を考えるか 先ほどは時間計算量を比較演算の回数で見積もりました。しかし、どの処理の回数を基準として計算量を見積もるかは場合によって変わると思います。以下のような処理の回数はとても重要です。 外部との通信の回数と容量 回数や容量が多いことは、帯域の圧迫であったり、余計な費用増加に繋がります。 API等を利用する際は、APIの呼び出し回数に制限がある場合もあります。 DBにアクセスする処理の回数 回数が多いとDBの負荷が増加します。 クエリ回数に対して課金があるDBサービスもあるかと思います。 パスワードやトークン、秘密鍵といった機密情報が必要な処理の回数 特定のソースコードというよりかは、システム全体の設計で意識することかと思います。 計算量を定義する際に、 「他にも用途に応じてさまざまな計算量が用いられている。」 と述べたのはこれが理由です。「上記の処理の回数を少なくすることで、処理時間が短くなる」 という訳ではない こともあると思います。計算時間を短くすることを優先するべきなのか、はたまたDBの負荷を減らすべきなのか。 システムの仕様や要件と相談する必要があるかと思います。 計算量は常に考えるべきなのか ここまで計算量を小さくして、処理を効率化することばかり論じてきましたが、 計算量をあまり気にしなくていいケース もあります。 データの量や長さが固定、あるいは少ないとき システムの仕様上どうしてもその処理が必要なとき この様な場合は計算量が多少多くなっても問題ないかと思います。 なぜこのような場合をわざわざ論じたかと言うと、 計算量を小さくすることで以下の問題が生じる 可能性があるからです。 処理内容の無駄を極力省いた結果、他者がそのソースコードを読んだ時に、どんな処理が行われているのかが分からない。 特定の処理を効率よく行うことに特化するあまり、再利用性が損なわれてしまう。 効率がよいコードを書こうとするあまり、コーディングにかかる時間が長くなってしまう。 これらの問題から、 常に計算量を小さくするべき とは単純に断ずることができない部分があります。システムの要件や仕様、場合によっては納期も考慮した上で、どのような実装を行うべきなのか判断するべきです。 AtCoderにおける計算量 この章は競プロに取り組もうと思っている方向けです。 AtCoderにおいて意識するべき数字があります。それは \(O(10^8)\) という数字です。 AtCoderでは、実行時間が2秒に制限されています。これを超えないためには \(O(10^8)\) あたりが限度だということです。これを超えたアルゴリズムはTLE（実行時間制限オーバー）になる場合が多いです。 入力が長さNの配列として与えられる場合を考えてみましょう。 AtCoderにおいては、Nの最大値が制約として与えられています。そのため、それぞれの制約に対して、「これくらいの計算量ならTLEにならない」という目安を書いておきます。 \(N\)が最大で \(10^2\) \(O(N^3)\)のアルゴリズムを動かしても問題ないでしょう。 多くの場合、特に計算量を減らす工夫をする必要もないかと思います。 \(N\)が最大で \(10^3\)～\(10^4\) \(O(N^2)\)あたりが限度でしょう。 \(N\)が最大で \(10^5\)～\(10^6\) \(O(N \log N)\) あたりが限度でしょう。 一つ一つの処理が重い場合は\(O(N)\)にするべきかもしれません。 これはクイックソートの計算量にあたります。ソートができるのはこの辺りまでです。 2重ループによる全探索は難しいです。 \(N\)が最大で \(10^7\)~\(10^8\) \(O(N)\)が限度でしょう。 \(N\)が最大で \(10^9\) \(O(N)\)で軽い処理ならギリギリTLEにならないでしょう。 そもそも入力に\(O(N)\)時間がどうあがいてもかかります。処理が軽ければ間に合うはずです。 \(O(\log N)\)や定数時間(\(N\)に依存しない時間)で処理が終わるものが理想です。 表にまとめるとこんな感じです。慣れてくるとこの表がなんとなく頭に入ると思います。 \(N\)の最大値 計算量 備考 \(10^2\) \(O(N^3)\) 計算量を考慮する必要はほとんどない。 \(10^3\)～\(10^4\) \(O(N^2)\) \(10^5\)～\(10^6\) \(O(N \log N)\) クイックソートによってソートを行うことができる。 \(10^7\)～\(10^8\) \(O(N)\) \(10^9\) \(O(\log N)\) 若しくは\(O(c)\) 処理が軽いのであれば\(O(N)\)でもいける可能性あり。 AtCoderでは、 難易度が高いほど入力長の最大値が大きくなる場合が多いです 。そのため実装に工夫や知識が必要になってきます。なのでAtCoderで上位になるためには、計算量(主に時間計算量)が小さくて済むアルゴリズムについて学び、それを実装する技術が必要です。 すなわち、 優秀な色の持ち主はアルゴリズムに対する知識が深く、その応用方法を熟知している という訳です。 まとめ 私は競プロや研究のために計算量について学びましたが、気がつくと常に意識するようになっていました。まずはなんとなくでもこれを理解し、できるだけ計算量が小さくなる実装を心がけることは大事だと思います。 計算量が小さくなるような実装を行うには、様々なアルゴリズムの知識が必要になることがあります。その知識が足りていなかったとしても、「これから書くプログラムの計算量、これくらいかな…？」と分かるだけで、相談することや、実際に動作させたときに何が起こるか想像することができます。 まずは「この処理の計算量はこれくらいかな…？」と考えるところから始めてみてはいかがでしょうか。

はじめに 皆さんこんにちは！開発系の部署に配属された、2022入社新卒R.Mです！ メイン業務はモバイルアプリ開発で、Flutterを使用しています！ 学生時は生命科学系を専攻してましたが、3年生くらいからプログラミングに興味を持ち始めて、簡単なiOSアプリを開発してました。 研究はPythonを使って、創薬に関することを色々やってました。技術を学ぶことも楽しいですが、ビジネス関連の話を聞くのも楽しい人間です。 ちなみに、趣味の中で今一番熱いのがK-POPです🔥 背景 この記事を書こうと思った理由・背景なのですが、自分自身配属されてから、触ったことのない技術(Flutter・Dart)を、社内で教えてくれる人がいない中で開発ベンダーさんと協力しながら勉強し、約2ヶ月間過ごしてきました。 はじめは課長とベンダーさん、自分含めて4人で定例会議を行っていましたが、今では一人でベンダーさんと進捗共有などを行い、プロジェクトを進行しています。 新卒でこれらの経験は中々無く貴重であり、得られたものも多かったと思っているので、 プロジェクトを進めていく会議上でやったほうが良い！ と思ったことを個人の主観でまとめてみました🎉 ⚠️やっておくと良いと書いてますが、絶対必要でしょ！っていう意見もあると思うのでそこはご了承ください。 具体的にそれをどうやるかまでは書いてません🙏 【１】情報を同期すること 情報を同期するとは： 会議に参加しているメンバー全員が、プロジェクトに関して知らない情報を共通認識として持つことを指しています！ 私達のチームは開発タスクをここで共有しているのですが、この仕組みがあるだけで、 新しいタスクはあるか 既存のタスクの状況はどうなっているか 未対応・対応中・対応済み どのバージョンでこの機能（タスク）を実装するのか ※スマホアプリなので、バージョンごとにリリースする機能を事前に話して決めます このタスクにかける時間はどのくらいか このタスクは誰が担当するのか などを決めることができ、その場のメンバーに共有もできます。 これらができていれば、、、 ■タスクが終わっていれば順調と判断でき、終わっていなければその原因と課題、次への対策まで検討が可能！ ■タスクの管理漏れがなくなる！🔥 →今日、誰が何をしているのかが分かり、PMも全体状況を把握しやすい！ 【２】ロードマップを立てること スマホアプリ開発の場合では、 バージョンごとに、「いつ」そのバージョンを世にリリースするかを決定 タスクごとに、「いつ」そのタスクを「どの」バージョンに含めるかを決定 タスクにかかる時間を元に、1スプリントで完了させるタスクを決定 スプリント = 単位の無い一定の期間。私達は1スプリント = 1週間と定義しています〜 これらをロードマップを立てる、として実施しています。 これらができていれば、、、 ■いつまでに、何が終わるのかが見やすい！ →臨機応変に、プロジェクト進行の調整を行うことができる！ ■次スプリントのスケジュールも立てやすい！ →仮に1週間程度で5個くらいのタスクを終わらせたとすると、次の1週間にタスクにかける時間の目安もすぐ分かる！ 【３】パーキングロットを確保すること パーキングロットとは： 議論する際に、今すぐ話し合うべきではないと判断される話題などを一旦保留しておくために、机やホワイトボードの隅などに設けられるスペースのこと。 ▷▷▷会議が終わった後に、話したい議題について必要なメンバーだけ集まって話す流れのこととして定義しています！ 私の場合によくパーキングロットで話す内容が、 モバイルアプリ開発における技術的な質問 使用するツール 細かい話 コミットメッセージの規則 タスク要件の再定義など など、たくさんありました！中でも技術的な質問が一番話していましたね😌 会議が終わった後に、個別でパーキングロットを開きます。話したい人は話して、聞く必要がある人は聞くイメージですね。 これができていれば、、、 ■議論の混乱や、無駄な議論を避けることができる！ ■話を聞かなくても良いメンバーの時間を奪うことがない！ 【４】変化があったものは記録を残すこと（その場で） イメージは、議事録という「誰に見せても分かるようなテキスト」ではなく、「話した内容が思い出せる粒度のメモ書き」みたいなものを想像してもらえると嬉しいです！！ それを、会議の最中に書いてしまいます！会議後ではなくです！ これができていれば、、、 ■メンバー間で共通認識が常に取れる！ →専門的な話でも、言語化して記録されているので、どのような内容かはざっくり把握できる ■後から証拠として出せる！ →相手の認識に齟齬がある場合に、メモを見せれば即解決！ ■図や画像なども乗せることができて、イメージしやすい！ →これも口頭で説明するより図で説明したほうが圧倒的にすぐ終わる ※記録がないと、後から再度聞くという二度手間になりますし、見返したい！と思った時に見れない、図が合ったほうが良い時に分からない、という最悪なことになります😇新卒研修の際にも可視化することの重要性を知りました。 【５】認識の齟齬がなくなるまで会議を終わらせないこと これは、曖昧な理解のままで会議を退出するなあああああ！！！！って意味ですね😇 チームでやることというより、 個人で 意識してやっておくと良いことになります。 分からない、と思ったまま退出するのが、自分にとってもチームにとっても危険です、、 ちょっとした疑問でも、その会議中で質問して解消するまで行うとGoodかなと、個人的には思ってます！ これができていないと、、、💦 ■自分がこれから何をするのか分からない状況に陥ってしまう、、 →会議終了後にすぐ動ける状態になっていないのは、自分が一番困ってしまいます！席に座ったら何をしたらいいか想像できるくらいまで、理解の粒度を細かくしましょう〜！ ■後から分からない点を聞くはめに、、 →自分のも、相手の時間も奪ってしまいメリットありません！（手戻りってやつですね）わかってはいるものの実行に移すのが難しいのですが😇 【※】開催頻度は毎朝☀️ これは、自分がプロジェクトを進めるにあたってスムーズに進められている要因の一つでもあ ったので書きました！ 毎朝開催すると、、 ■プロジェクトの進行状況が1日置きで分かる！ →何が進んで何が進んでいないかが明確！ ■手元にきた重要な情報もすぐ共有できる！ →共通認識がとりやすい！ ■分からないことがあれば、直接聞ける！ →テキストで聞くより圧倒的に早いから工数削減につながる 逆に毎朝開催しなかった時に一番困ったことは、自分目線、「分からないことを聞くこと」でした。 技術的な質問なんて、細かいところを文章で書き起こさないといけない場面がいくつもありました。 それを長文で返して、長文で返ってくる、それをまた長文で返す、みたいな繰り返しで ほぼ1日経ってるやんけえええ！！ って思った日もあります。 毎朝であれば質問があれば聞く機会が既に設けられているので、心理的安全性もありますし、聞きたいことがない日はそれでOKなので非常に助かっています！ 最後に。 以上です！ （書いた内容がMECEにそってないかもしれませんが、追々意識します、！） 見返すと、意外と当たり前なことやな🥱って思った方も多いかもしれません！ ただベンダーさん会議とは別で、社内の会議にいざ参戦！してみると、そんなこともなく、バラバラでした。 「会議」って一言で表せるけど、かなり奥深くて大変ですね😇 ベンダーさんもいつまでも契約が続くわけではないので、この当たり前は自分の中でも維持して、プロジェクトをスムーズに進めていきたいな！と思ってます！ ※余談ですが、この間ちょうど社内の会議やコミュニケーションの最適化について議論する場に参戦したのですが、少し似たような話も上がってたので、少しは考え方が共通しているのではないかと思いましたっ 閲覧いただきありがとうございました〜！🥰

はじめに 本日12月15日は C++14 (ISO/IEC 14882:2014) と C++20 (ISO/IEC 14882:2020) のリリース日です。 C++14 は8年前の2014年12月15日、C++20 は2年前の2020年12月15日 にリリースされました。 C言語といえば、先日(2022/11/19)に「人間Cコンパイラコンテスト」に参加し、ランキング1位を獲得することができました。このエントリーでは人間Cコンパイラのはじめかたをまとめていきます。 人間Cコンパイラコンテストとは？ 「人間Cコンパイラコンテスト」(HCCC)とは競技者自身がCコンパイラとなり C言語からアセンブリを生成し、その時間と正確さを競う競技です。日本ネットワークセキュリティ協会（JNSA) の SECCON実行委員会が実施する「SECCONCON」内で第一回大会が開催されました。 HCCC / 人間C言語コンパイラコンテスト 詳しくは、以下の 公式説明スライド を参照ください。 この大会ではチュートリアル問題も含めて全20問が出題されています。単純に数字を戻り値として返す問題から、四則演算、ローカル変数利用、文字列処理、ハローワールド、Fizzbuzzなど典型的なプログラムが多く出題されました。 人間C言語コンパイラコンテスト Problems チュートリアル チュートリアル問題 チュートリアル問題を解いていきましょう。実際に一問目として出題された 究極の疑問の答えを返すプログラム を題材とします。 //return_42.cint main(void) { return 42;} 開発環境の構築 これくらい単純なプログラムであればそのままポータルサイトに入力しても問題ありませんが、複雑なプログラムではローカル環境でのデバッグが必須です。ここでは公式が提供している検証環境を利用して開発環境を構築します。 ~$ git clone https://github.com/HumanCCompilerContest/HCCC_local_env~$ cd HCCC_local_env~/HCCC_local_env$ docker build -t hccc_local_env .~/HCCC_local_env$ docker run -it --rm hccc_local_env アセンブリコードの作成 開発環境では vim や emacs などコーディングエディタが利用できます。 ここでは、vim を利用して ファイル return_42.s を新規作成し、先のC言語のソースファイルをx86_64アークテクチャのアセンブリに変換してコーディングしていきます。 root@a741545b3735 ~$ vim hccc/return_42.s ▼return_42.s .globl mainmain: push %rbp mov %rsp, %rbp mov $42, %rax mov %rbp, %rsp pop %rbp ret アセンブルと実行 開発環境では アセンブリコードのアセンブル＆実行するコマンド「asm2bin」 が用意されています。 作成したアセンブリコードファイルを引数にして実行します。 root@a741545b3735 ~$ asm2bin hccc/return_42.s 実行後、返り値として「42」が返っていることが確認できました。 root@a741545b3735 ~$ echo $?42 デバッグ 開発環境では PEDA 拡張された gdb が利用できます。 asm2bin 実行すると、実行オブジェクトファイルはカレントディレクトに「tmp」として保存されていますので、これをデバッグ実行します。 $ gdb tmp$ break main$ run 命令ポインタ前後の命令やレジスタ値、スタックフレームなどが可視化させれているため、効率的なデバッグが可能です。 人間コンパイルの知識リソース C言語からx86_64アセンブリにコンパイルするためには、C言語(C99)、CPU命令(x86_64)、ABI (System V Application Binary Interface)、アセンブラ疑似命令に知識が必要です。 以下、参考になるインターネットリソースを記載します。 (※競技中はレギュレーションで認められたもののみ閲覧可能です) 公式リソース 公式レポジトリ 公式チュートリアル C99 System V Application Binary Interface AMD64 Architecture Processor Supplement その他のリソース x86 Assembly Language Reference Manual : Assembler Directives AMD64 ABI の特徴 低レイヤを知りたい人のためのCコンパイラ作成入門

はじめに マイナビでは、一部のシステム職員に向けてDaaS環境を提供しており、サービスには「Azure Virtual Desktop」を採用しております。 Microsoft社が提供するAzure Virtual Desktopはなんと Windows 10 Enterprise Microdsoft 365 Business Premium以上 のライセンスがあれば、追加ライセンスは不要で利用が可能なDaaSとなっています。 加えて、Azure AD P1以上があれば条件付きアクセスによる詳細なアクセスコントロールもできます。 今回は、そのAzure Virtual Desktopを構築し利用できるまでの道のりと共に、メリットデメリットを含めて共有できればと思います。 Azure Virtual Desktopサービスとは？ Microsoftが提供するクラウド型のDaaS(Desktop as a Service)は、実は2種類存在しています。 1. Windows 365 決められたプラン(スペック)の中から利用ができる、シンプルな構成のDaaS。 利用者数が少ない、利用要件が少ない…など「とりあえずDaaSが使いたい」環境向けサービス。 24H365Dで稼働しっぱなしのため、ランニングコストは安くない。 2. Azure Virtual Desktop 様々なカスタマイズ、利用方法を提供する上位のDaaS。 1台を複数人で利用できる「マルチセッション」や、細かなポリシーカスタマイズが可能。 利用状況に応じて自動シャットダウンも可能なため、費用をコントロール出来ます。 ある程度の数を展開する場合や、要件が明確な場合はこちらをオススメします。 Azure Virtual Desktopの構成を理解しよう Azure Virtual Desktop(以下、AVD)は、既存のVDIシステムと似ている部分が多々あります。 構築をしてみる前に、まずはどのような要素から成り立っているかを把握しましょう。 引用元： エンタープライズ向け Azure Virtual Desktop - 主要な論理コンポーネント間のリレーションシップ AVDは大きく、 コントロールプレーンと呼ばれる管理環境 ホストマシンやプロファイルの仮想デスクトップ実行環境 2つに分けられます。 コントロールプレーンはMicrosoft社の管理下にあるため、利用側での設定や運用は不要です。実際に、設定や運用管理が必要なのは仮想デスクトップを実行するための環境だけですね。オンプレでVDI環境を運用する場合、管理環境の維持だけでも大変なのでこれはありがたいですね。 また、ある程度の規模間の企業様であればExpressRouteを既にご利用の場合もあるかと思います。 オンプレ～Azure間を閉域でつなぐ場合はこちらも利用しましょう。 過去、AVDを利用するにはAD＋AADのハイブリッド構成が必須でしたが、現在では、AADのみの環境もサポートされています。 ただし、一般的にはハイブリッド構成を利用している環境の方が多いと思いますので、今回は仮想マシンをオンプレADに参加させる方式で説明いたします。 構築をしてみよう ここまで概要を説明いたしましたが、ここからは実際にAVDを構築し仮想デスクトップを利用してみましょう。 まず、今回の前提条件としては下記構成で構築に臨みたいと思います。 ・ExpressRouteを利用し、オンプレとの相互通信が可能である・オンプレ上にActive Directoryが存在している・オンプレ上にAzure AD Connectが存在している(AD⇔AADが同期済みである) ①リソースグループを作る Azure上に作成される各コンポーネントを取りまとめるため「リソースグループ」を作成します。 リージョンは「東日本」か「西日本」のどちらかを選択しましょう。 ②仮想ネットワーク(VNET)を作る AVD環境で仮想マシンがドメインに参加できるように、オンプレADの名前解決が可能なサーバをDNSに指定しましょう。 ADサーバがDNSを兼ねている場合は、ADサーバを指定してあげると良いでしょう。 そのほか、仮想ネットワークではサブネットの設定も可能となっています。 ネットワークの環境や要件に応じて設定を行ってください。 ③マスターイメージの作成 FAT・VDIともに展開ではおなじみのマスターイメージを作成していきます。 このマスターイメージを元に、仮想マシンを展開していきます。 まずは、マスターイメージとなるAzureVMを作成しましょう。 AVD固有機能である「マルチセッション」を使う場合は、イメージを「Multi-session VM」から展開しましょう。 シングルセッションの場合は、Windows10であれば特に指定はありません。 展開後は、通常のWindowsマスタと同様にOSにカスタマイズを施していきます。 ※AzureVMのWindows 10は英語がデフォルトのため、日本語化が必要な場合はOSで設定変更がマストです。 マスターイメージである程度カスタマイズが完了したら、sysprepを行います。 AVDのsysprepでは、応答ファイルがサポートされていません。 弊社で検証した限り、応答ファイルを利用すると展開に失敗します。 そのため、プロファイルのコピーが応答ファイルで実施できません。 応答ファイルを使わないプロファイルコピー設定を事前に行うことで実現は可能です。 ※AVDのサポート対象外となる可能性が高いため、本記事では言及致しません。 sysprepまで完了したら、Azure上でイメージ化するために「キャプチャ」を行いましょう。 これでマスターイメージの完成です。 ③ホストグループの作成 ここまで来たら、あと一歩です。 AVD上の仮想マシンを束ねる「ホストグループ」を作成しましょう。 マルチセッションの仮想マシンの場合は「プール」を選択します。 「個人用」を選択した場合は、仮想マシンと利用者は1:1になります。 ホストプールを作るタイミングで、同時にAVDで利用する仮想マシンも作成することができます。 先ほど作ったマスターイメージから仮想マシンを展開するために「全てのイメージを表示」を選択しましょう。 「マイアイテム」を確認することで、キャプチャしたマスタイメージを選択できます。 あとはドメイン参加するための情報や仮想ネットワークの設定やらを入れてあげれば完成です。 初回作成の場合は、ワークスペースもここで一緒に作成すると展開が楽です。 無事展開が完了すると、ホストプールに仮想マシンが作成されます。 最後に、仮想マシンを利用できるユーザを設定してあげます。 シングルセッションの場合は前述の通り1:1ですが、マルチセッションでは複数人設定が可能です。 シングルセッションの場合↓ マルチセッションの場合↓ 接続してみよう ここまでの準備ができたら、いよいよ接続が可能になります。 AVDには2種類の接続方法があり、 ブラウザからのアクセス 専用RDPアプリからのアクセス が可能です。 ただし、ブラウザからのアクセスはレスポンスが悪いのでオススメしません。 今回は専用アプリから接続してみます。 専用アプリにAzureADアカウントでサインインをすると、割り当てを行った仮想マシンが表示されていますね。 選択してみるとこのように仮想マシンに接続ができます。簡単ですね！！！！ ※オンプレADとAADのハイブリッド環境の場合、展開時に自動的にAD参加を行ってくれます。 　そのため仮想マシン自体へのログインにはオンプレADアカウントを利用します。 運用編 ここまでで、なんとなく作り方や使い方のイメージが付いたかと思います。 ただし実際には、もう少し作りこみが必要です。 例えば、 このサービスは従量課金制です。 そのため、仮想マシンは使った分だけ課金され続けます。 ここで重要なのは「シャットダウン」だけでは課金され続けてしまいます。 停止 (割り当て解除) は、仮想マシンが稼働する物理ホスト サーバーから割り当てられているリソースの割り当てを解除する操作であり、起動は物理ホストサーバーからリソースを割り当てる操作です。 再デプロイと異なり、明示的に別の物理ホスト サーバーでデプロイを行うための手段ではありませんが、起動によって仮想マシンがデプロイされる物理ホストサーバーは前回と異なる場合がほとんどになります。 停止 (割り当て解除) では、仮想マシンとしての課金はかかりません。(※ ディスクの課金はかかります。) 引用元： Azure 仮想マシンにおける操作 (再起動、停止/起動、再デプロイ、再適用) について つまりは、仮想マシン側でシャットダウンをしたところで、 Azure側で割り当てを解除しなければ課金され続ける ということですね。 幸い、Azure Virtual Desktopには「スケジュールに応じて自動的に割り当てを解除する」仕組みがあります。 利用時間が決まっている環境であればこの実装だけで費用を抑えられます。 ただし、スケジュール外のメンテナンスで使っている場合などで、急に割り当てが解除されると困りますよね。 そういった場合は、仮想マシンへのセッション有無を定期的にAzure側で判断し自動で割り当てを解除する仕組みを導入する必要があります。 合わせて、 ARMテンプレートを利用しない場合ホスト名の規則に融通が利きません。 この二つの実装は、インターネット上に先駆者の情報がありますので、参考にしてみてください。 まとめ AD・AADのハイブリッド環境かつ物理リソースを持たないVDI という点は非常に魅力的です。 ただし、細かいカスタマイズが難しいのは否めません。このあたりは「Citrix with AVD」や「Horizon Cloud with AVD」を活用すると、オンプレVDIと同じ感覚で運用ができるかもしれません。 とはいえ、弊社環境では社員用のFAT PCと同様のカスタマイズが実現できていますし、本番運用環境は一人で構築しています。 元々Azureに知見がある、マスタ展開の経験がある、VDI構築に携わったことがあるなど、なんらかの条件があれば、抵抗なく構築運用が可能かと思われます。 PCの持ち出しができない環境がある場合、このDaaSの仕組みは非常に魅力的かと思います。既にM365の該当ライセンスをお持ちの方は、是非活用してみてはいかがでしょうか。