はじめに こんにちは。ITソリューション部（現デジタルテクノロジー戦略本部）のS.Dです。 皆さん、ゲームは好きでしょうか？ 私は、将棋やチェスなどのボードゲームが大好きです。 先日、竜王戦の第二局が行われ、タイトル100期を目指す羽生善治先生が、現タイトル保持者の豊島竜王に挑み、1対1のタイになりました。 最近では、将棋AIがプロ棋士よりも強くなり、アマチュア、プロを問わず将棋AIを活用して将棋の研究が行われています。 チェスの世界では、私が生まれるよりも早く、人間が機械に敗れています。カスパロフさんという、当時の世界チャンピオンがDeepBlueと呼ばれるIBMが開発した機械に敗れました。 そして、ついこの間、機械が人間に勝つにはあと10年かかるといわれていた囲碁でも、Google傘下のDeep Mind社の開発したAlpha Goが、現役最強のイ・セドル9段を破ったことで非常に有名になりました。 少し前までは、個人で機械学習やAIなどの開発を行うには、機材などがとても高価で手が出ませんでした。 しかし、AWSやGoogle Cloudなどの、クラウドサービスが台頭してから、個人でも機械学習などの開発が盛んに行えるようになりました。 私も、囲碁の評価関数やAIを趣味で自作しており、いつの間にか自分より強くなってしまいました。 開発を行っている中で、「"ゲーム"とはいったい何なのか？」という問いがよく浮かんできます。 この、組み合わせゲーム理論はゲーム理論の中でも、不偏ゲームという比較的簡単なゲームを対象にした理論です。 とても面白いものなので、皆さんにご紹介できればと思います！ 組み合わせゲーム理論とは？ 組み合わせゲーム理論(Combinatorial Game Theory)とは、Nim・将棋・チェス・囲碁などの、二人零和有限確定完全情報ゲームに関しての理論です。 ゲームには、勝ち・負け・引き分けの3つの状態があります。(引き分けは存在しないこともあります） 先後が決まっており、状態遷移で勝負が決まります。例えば、将棋では玉が詰まされたら負けです。 手番は、交互に代わり、最終的に手が無くなるとき（＝つまり状態遷移がこれ以上進まないとき）に、勝ち負けや、引き分けになります。 組み合わせゲームは、必ず終わりがあり、ループは認められません。 一般的なゲーム理論との大きな違いは、運や不完全情報を含まない点です。 CGT(Combinatorial Game Theory、組み合わせゲーム理論)は、しばしば競プロとかで出問されていて、その多くは、ある発見をすると簡単にコーディングできます。 今回は、その端緒をご紹介します。 不偏ゲーム(Impartial Games)と非不偏ゲーム(Partisan Games) 組み合わせゲームは大きく分けて、不偏ゲーム(Impartial Games)と非不偏ゲーム(Partisan Games)の2つに分けられます。 不偏ゲーム:任意の局面において、2人のプレイヤーの選択肢とその結果が同じ 非不偏ゲーム:ある局面において、2人のプレイヤーの選択しとその結果が同じでない場合が存在する 例えば、以下のようなゲームは不偏ゲームです。 Nim: 各山にいくつかの石があります。 各ターンで、プレイヤーは1つの山(少なくとも石が1つ存在する)を選び、任意の数の石(少なくとも1つ)を取り除きます。 最初に上の操作ができないプレイヤーが、敗北です。 上記は、非常に有名な不偏ゲームの一つで、 Nim と呼ばれています。 逆に、将棋・チェス・囲碁を考えてみましょう。 両ゲームとも、自分の持ち駒(石)と相手の持ち駒(石)があり、両方のプレイヤーにとって選択肢は違い、動かせる駒や石も違います。このようなゲームは、非不偏ゲームと呼ばれます。 非不偏ゲームは、不偏ゲームと比べてはるかに分析が困難になることが多いです。 今回は、 不偏ゲーム を扱っていきます。 代表的な不偏ゲーム「Nim」について Nimとは まずは、Nimゲームについて考察していきましょう。 Nim: 各山にいくつかの石があります。 各ターンで、プレイヤーは1つの山(少なくとも石が1つ存在する)を選び、任意の数の石(少なくとも1つ)を取り除きます。 最初に上の操作ができないプレイヤーが、敗北です。 (出典： https://www.geeksforgeeks.org/introduction-to-combinatorial-game-theory/?ref=lbp ） 上の例をみていきましょう。 A・Bのプレイヤーがいます。山が3つ存在していて、それぞれ、3・4・5個の石があります。 A->B->A->B->…のような感じで、先手がAとして、任意の山から石を少なくとも1個以上取ります。最終的に、石が取れなくなったプレイヤーの負けです。 上の図のように遷移したとき、Aが勝利します。 さて、このゲームは必勝法が存在するのでしょうか？ また、必勝法が存在するとしたら、先手後手どちらが必ず勝つことができるのでしょうか？ Nimの必勝法とは Nimには、必勝法が存在します。 ただし、山の石の配置の仕方によって、勝つプレイヤーは変わってきます。 ここで一つ、 Nim-Sum と呼ばれる、重要な値を紹介します。 Nim-Sum:ゲームある時点での、各山の石の数の累積XORの値 (出典： https://qiita.com/kuuso1/items/778acaa7011d98a3ff3a ) ちなみに、XORとは上のような演算子です。C/C++だと、a ^ b のbit演算子のことです。 このNim-Sumの値を使うと、今回の勝負について以下のことがいえます。 AとBが自分にとって最適な行動(自分が勝つように動く)をとるとき、ゲーム開始時点で、 Nim-Sumが0でなければ、Aの勝ち Nim-Sumが0のとき、Bの勝ち つまり最適な戦略を考えるには、以下2つの定理が必要です。 定理1. n個の数値のXORの合計が、0のとき数値を一つ減らすだけで、XOR合計を0にすることはできない 定理2. nこの数値のXORの合計が、0以外のとき数値を一つ減らすだけで、XOR合計を0にすることができる Case1:最初のNim-Sumがゼロの場合 すでに紹介したように、この場合最適に動けば、Ｂが必ず勝ちます。 Bの最適な戦略として、AのターンのときにNim-Sumを必ずゼロにすることです。 Aの手番のとき、Nim-Sumは、もともとゼロなので、Aがどの山からどれだけ石を取ろうとも、Nim-Sumをゼロにすることはできません。(定理2.) 逆に、Bの手番のとき、Nim-Sumはゼロではないので、必ずNim-Sumをゼロにするような石の取り方が存在します。 ゲームは、最終的に全ての山に石が存在しなくなるまで行われるので、上の手順を繰り返せば、最終的にBが勝つことができます。 この手順、つまり相手のNim-Sumがゼロになるように動くことが、本ゲームでの最適な行動といえます。 Case2:最初のNim-Sumがゼロではない場合 上と同様に、今度は逆にＡがＢのNim-Sumをゼロにするように動けば必ずAが勝ちます。 Bは常に自分のターンがNim-Sumがゼロで回ってくるので、AのターンにNim-Sumをゼロにすることができません。 例えば、上で例を挙げた、3つの山にそれぞれ、3・4・5個の石が存在する場合は、 3 XOR 4 XOR 5 = 2 となって、必ずAが勝ちます。 Grundy数について ここからは、Nimを一般化したNimkを扱います。 Nimkは、以下のように表されます。 Nimk: 各山にいくつかの石があります。 各ターンで、プレイヤーは1つの山(少なくとも石が1つ存在する)を選び、K個の石(少なくとも1つ)を取り除きます。 最初に上の操作ができないプレイヤーが、敗北です。 Nimkには Grundy数 というものが、密接にかかわっています。 Grundy数とは Grundy数（Nimbers）とは、ゲームの状態を決定する数字のことです。 全ての不偏ゲームは、一度そのゲームのGrundy数を計算すると、ゲームをどのように解くことができるかがわかります。 ※Sprague-Grundyの定理とも呼ばれる Grundy数を計算する前に、まず Mex とは何かを説明します。 Mexとは Mex（Minimum excludant）とは、ある集合の要素でない最小の非負整数のことです。 (出展： https://www.geeksforgeeks.org/combinatorial-game-theory-set-3-grundy-numbersnimbers-and-mex/) Grundy数の計算 今回、Grundy数を以下のように定義します。 Grundy数: 先手のプレイヤーが次の手番で負けることが決定しているときは「0」 それ以外のときは「すべての可能な次の局面のGrundy数のMex」 例で、Grundy数を2つ計算してみましょう！ 例1 一つの山に、n個の石があります。 プレイヤーA・Bは、Aを先手として、交互に任意の自然数の数を選んで、山から石を取ります。 最初に、石を取ることができなくなったプレイヤーの敗北です。 A・B共に、自分が勝つために最善な行動をとる場合、どちらが勝利するでしょうか？ 上のGrundy数を求めます。 もし山に1つも、石がなかった場合Grundy数G(0) = 0 です。 もし山に1つ石があった場合、Aは必ず石を1つ以上取らなければいけないので、G(1) = Mex(0) = 1 もし山に2つ石があった場合、Aは石を、1つ取るか2つ取るかできます。 G(2) = Mex(0,1) = 2 同様にして、山にn個石があった場合 G(n) = Mex(n-1,n-2,….,1,0) = n となります。 常にGrundy数が0以上なのでプレイヤーAが必ず勝利します。 例2 1つの山に、n個の石があります。 プレイヤーA・Bは、Aを先手として、交互に1~3までの任意の数を選んで山から石をとります。 最初に、山から石を取ることができなくなったプレイヤーの敗北です。 A・Bともに自分が勝つために最善を尽くした場合、どちらが勝利するでしょうか？ 上のGrundy数を求めます。 もし山に1つも、石がなかった場合Grundy数G(0) = 0 です。 もし山に1つ石があった場合、Aは必ず石を1つ以上取らなければいけないので、G(1) = Mex(0) = 1 もし山に2つ石があった場合、Aは石を、1つ取るか2つ取るかできます。 G(2) = Mex(0,1) = 2 もし山に3つ石があった場合、Aは石を、1つ取るか2つ取るか3つ取るかできます。 G(3) = Mex(0,1,2) = 3 ここまでは、例1と同じです。 もし山に4つ石があった場合、Aは石を、1つ取るか2つ取るか3つ取るかできます。 G(4) = Mex(1,2,3) = 0 となります！ 数学的帰納法から、簡単に 山にn個石があった場合のGrundy数は以下のように求められます。 G(n) = Mex(G(n-1), G(n-2), G(n-3)) (出典： https://www.geeksforgeeks.org/introduction-to-combinatorial-game-theory/?ref=lbp ） Sprague-Grundy定理について 上の最後の例2について、さらに考察していきましょう。 例2 1つの山に、n個の石があります。 プレイヤーA・Bは、Aを先手として、交互に1~3までの任意の数を選んで山から石をとります。 最初に、山から石を取ることができなくなったプレイヤーの敗北です。 A・Bともに自分が勝つために最善を尽くした場合、どちらが勝利するでしょうか？ この問題は、nが与えられたとき、上のようなGrundy数の遷移で解けることがわかりましたが、一般に不偏ゲームにおいてGrundy数が適用できるのでしょうか？ Sprauge-Grundy定理とは 一般に、2人のプレイヤー(A先手・B後手)がいて、n個のサブゲームからなる不偏ゲームを考えます。 Sprauge-Grundy定理は、以下のことを述べています。 A・Bが、自身の勝利のために最善を尽くして動く場合、 ゲーム開始時に、すべてのサブゲームでのGrundy数のXORが0でない場合は、Aが勝利します。 逆に0のときは、必ずBが勝利します。 定理の適用 Sprauge-Grundy定理は、以下のように適用できます。 ゲームをサブゲームに分割する すべてのサブゲームで、その時点でのGrundy数を計算する 計算したGrundy数のXORを計算する XORが0でなければ、最初にプレーするプレイヤーが勝ちます。0であれば、後手が勝ちます。 このアルゴリズムで、問題を解くと以下のようになります。 例2 3つの山に、それぞれ、3・4・5個の石があります。 プレイヤーは、Aを先手として、交互に1~3までの任意の数を選んで山から石をとります。 最初に、山から石を取ることができなくなったプレイヤーの敗北です。 A・Bともに自分が勝つために最善を尽くした場合、どちらが勝利するでしょうか？ 一つの山から石を取りつくすことをサブゲームとします。 Grundy数を計算します。 (出典： https://www.geeksforgeeks.org/introduction-to-combinatorial-game-theory/?ref=lbp ） それぞれ3・4・5個の山のGrundy数のXOR G(3) = 3 G(4) = 0 G(5) = 1 G(3) XOR G(4) XOR G(5) = 2 となります。 4.　Grundy数のXORが0ではないので、プレイヤーAが勝利します。 最後に いかがでしたでしょうか？ 楽しんでいただければ幸いです。 CodeForcesやHackerRankなどで、面白い問題がたくさんあるのでぜひ解いてみてください！ 全く関係ないですが、とっても楽しいゲームなので、ぜひ これ をやってみてください！ Herbert Online Judge : http://herbert.tealang.info/index.php?lang=en <解説> CodeForces GeeksforGeeks <問題集> HackerRank CodeForces YukiCoder

こんにちは、マイナビエンジニアブログ編集部です。 今回は、「マイナビ Advent Calendar 2020」についてご紹介したいと思います！ Advent Calendar（アドベント カレンダー）について Advent Calendarは、通常クリスマス（12/1-12/25）までの日数をカウントダウンするという習慣のためのカレンダーの事です。 IT界隈ではQiitaで展開される「Qiita Advent Calendar」に登録するケースが多く、本年もそちらを活用していきます。 昨年に続いて、マイナビでも有志のエンジニアやマネージャーによる本イベントへの参加を行います。 ITに関する記事を毎日1本ずつ投稿していきますので、興味のある方は是非ご確認下さい！ 「マイナビ Advent Calendar」はこちらからチェック！ 本年のAdvent Calendarはこちらをご覧下さい。 「マイナビ Advent Calendar 2020」はこちら 昨年のAdvent Calendarは以下になりますので、併せてご覧いただければと思います。 「マイナビ Advent Calendar 2019」はこちら

はじめに こんにちは、マイナビエンジニアブログ編集部です。 今回はテレワーク制度や看護休暇などの社内制度を活用しながら、仕事と育児を両立しておられるT.Nさんにお話を伺いました。 仕事と子育ての両立はなかなか難しいことです。普段はどのような業務を行っているのか、子育てとの両立で工夫していることなど詳しくお話していただきました。 自己紹介 まずは自己紹介からお願いします。 T.Nと申します。 ソフトへの興味から独学でJavaを学び、前職ではアプリケーションエンジニアとして客先常駐で働いていました。 自社商材を持つ会社でより上流工程の業務を経験したいと考えて2016年マイナビに入社、プロジェクトマネージャーとして4サイトの立ち上げに関わりました。そして2019年に社内応募を使って今の課へ異動し、今はWebマーケティング業務を担当しています。 休日は、もうすぐ１歳になる子供の相手をしています。 最近では寝返りをしたりハイハイをしたり、毎日少しずつ成長している姿を見れることがとてもうれしいです。 エンジニアのスキルを活かしてWebマーケティングの世界へ 現在の業務について教えてください。 SEOや広告運用にもっと全社的に関わりたいという思いから、2019年には社内応募で今の課に異動しました。現在は、おもにグループ会社の広告運用などWebマーケティング業務を担当しています。データ取得のためのロジック作成やLP作成、BIツールでの分析や改善、サイト分析や各事業部からの問い合わせ対応などです。ガバナンス整備で部署間の調整やシステムについてわからない部署へのサポートなども行っています。 前職は客先常駐だったため、なかなか会社への帰属意識を持ちづらかったのですが、現在は自社の上流工程の業務に携わり「今、何をやっているのか」という業務の全体を見ることができるので、とてもやりがいを感じています。 1日の業務の流れについて教えてください。 出社後はスケジュールやメール・タスクなどをチェックし、その日にやることの確認をします。その後は問い合わせ対応や日次広告レポートの作成、改善案検討、広告のクリエイティブ作成や入稿などを行っていますね。日によって、会議への参加や部署間の調整もしています。 退勤はだいたい19時ごろ。21時前に家に着いてからは、妻と協力しながら子供が眠るまで面倒をみています。 子育てと仕事を両立するということ お子さまが産まれてから、生活はどのように変わりましたか？ 子供中心の生活に変わりました。夜泣きをしたときには寝るまで抱っこしているので、睡眠時間がとにかく減りましたね。けれど、子供との時間をもっと作りたくて、平日もできる限り早く帰宅するようになりました。休日も洋服やおもちゃを買いに出かけるなど、子供のための外出が増えましたね。 また、子供が産まれてからは社内の制度を利用して、週に3回テレワークをしています。社内でもチャットツールなどを利用してやり取りしていたので、自宅でも出社時と変わらずに作業できています。 テレワークの最大のメリットは、ひとりなので仕事に集中できること、そして仕事が終わったらすぐに育児に参加できることだと感じています。通勤に往復3時間ほどかかるので、自宅で業務ができることで育児の時間や睡眠時間が確保できるのはありがたいです。子供が夜中まで寝ないときもあり、テレワーク制度がなかったら睡眠不足で体調を崩していたかもしれないし、業務効率も悪くなっていたと思っています。 在宅で仕事ができる制度があるのは本当に助かります。 デメリットがあるとすれば、このテレワークが暫定的な制度だということでしょうか。これからテレワークがもっと定着していけば、社員がますます働きやすくなると思っています。 確かにテレワーク制度があると両立がしやすいですね。ちなみに、育児と仕事の両立をしていて大変なことはありましたか？ やはり朝が眠いということです。子供の寝かしつけが深夜にまでおよんだとしても、どんなに寝不足だろうと仕事の時間は決まっていますので、同じ時間に出社しなければなりません。 また、やはり自分の時間が前と比べて少なくなったことは大きいです。今までは趣味でプログラムを書いたり資格の勉強をしたりと1日1〜2時間は自分の時間が確保できていたのですが、今はそれが難しくなりました。テレビを見る時間も減り、以前はドラマもよく見ていましたが、最近はなかなか時間が取れません。 妻とふたりで協力しながら子育てをしていてもこれだけ大変なのだから、ひとりで全部こなされている方は本当にすごいと思います。 なるほど。育児と仕事が両立するように工夫していることはありますか？ まずは、仕事の時間と子育ての時間のメリハリですね。 仕事では、自分で簡単なスクリプトを構築したり、タスク管理ツールを用いて、作業効率を上げるように心掛けています。 私が仕事をしている間は子育てを妻に任せている一方、プライベートな時間は私が子供の面倒を見ることで、なるべく妻にゆっくりしてもらえる環境づくりを心がけています。 また、会社の制度を積極的に活用することも両立の工夫です。マイナビには看護休暇（年間5日）があり、今年は子供の予防接種で消化しました。子供連れで外出するときは何かと荷物が多いし子供もだんだん重くなりますので、なるべく妻とふたりで行くようにしています。 先にお話したテレワーク制度もそうですが、子育て中の社員が仕事と育児を両立できるよう会社の福利厚生が支援してくれる。有給以外にもこのような制度があることはとても助かっています。 メリハリをつけるのは重要ですね。いろいろと工夫されている中で、今後、改善していきたいと思ったことはありますか？ 特定の担当者しかその業務に対応できない"属人化"は、まだ改善の余地があると思っています。 業務フローを明確化してマニュアルを作成したり、単純作業は自動化して人が作業しなくてもいいように改善したりと、急にお休みをいただいても業務が滞らないようにしたいですね。 今は、マイナビで導入している情報共有ツールを使って、空き時間を見つけてマニュアルを作成したり、同僚にレビューしてもらいながら進めている最中です。 社内全体が協力的だからできること 世の中では「男性の積極的な育児参加は少ない」という風潮がまだ根強いと思います。周りからの理解は得られていると感じていますか？ 課長をはじめ、課のメンバーにはかなり協力的にフォローしていただいていると感じます。 以前、どうしても対応しなければいけない業務がある日に、子供が熱を出してしまったことがありました。 この日は広告配信の開始日で、クリエイティブ(※広告における制作物全般のこと)の追加が必要だったこともあり、当日に手動での作業が必要でした。 ですが、課のメンバー全員が広告管理画面の使用方法を習得しており、業務フローも明確化していたため、「○の広告を△時から開始にしてほしい」と連絡するだけで問題なく引き継ぐことが出来ました。 そのため、急だったにも関わらずお休みを頂けたので、子供の看病に時間を充てることができて、本当に助かりました。 もともと、仲間とは常にコミュニケーションを取り合いながら業務を進めているため、普段から相談がしやすい雰囲気の課だと思います。事前の休日申請に関しても打診がしやすい環境です。 また、私の所属部署では男性の部長が育休中ということもあり、全体的に育児に対する理解があると感じています。こうして私が子育てと両立しながら仕事にも向き合えているのは、社内全体が育児に対して協力的という環境のおかげです。 おわりに いかがでしたでしょうか。 今回は社内の制度を活用しながら、育児にも仕事にも真剣に向き合って両立されているT.Nさんについてご紹介しました。 子供を育てることは、気力も体力も必要でなかなか大変なことではありますが、周りのサポートや、社内の制度を積極的に活用しながら仕事と育児を上手に両立されていますね。 これからも奥さまと二人三脚で子育てを楽しんでいただきたいですね。

こんにちは、エンジニアブログ編集部のアイコです。 派遣社員ながらブログ編集部員になって早1年が過ぎ、システム統括本部（現デジタルテクノロジー戦略本部）での仕事にも慣れてきた今日この頃。前職の制作部署でのスキルを生かしながらシステム統括本部内（現デジタルテクノロジー戦略本部）で働かせていただいています。 今回は、そんな私目線で見た在宅ワークレポートをお届けしたいと思います。 派遣の在宅ワーク 新型コロナウィルスの影響もあり、マイナビでも４月から在宅ワークを導入しています。 システム統括本部内（デジタルテクノロジー戦略本部）でもやむを得ない場合の出社を除き、全従業員を対象に在宅ワークを推奨しており、いつもは賑やかなシステム統括室内もガラリとしていました。 人も少なければ機器も最低限の稼働状態、雰囲気的な寂しさも加わって異様に感じました。 (心なしか室温も寒かったような) 今回のようにコロナウィルスの影響で日本政府から緊急事態宣言が発令されたことにより、仕事にまで影響が出ると思わなかったですし、こういった状況になっても派遣社員という立場で出社時同様の業務をさせてもらえている状況は非常にありがたいことだと思っています。 在宅ワークでできること、不便なこと リモート設定を行い、自宅でも出社しているときと同じツールを使わせてもらっています。 自宅PCから会社のPCをリモート操作するため、ちょっとしたタイムラグや、会社PCの設定依存などに多少違和感がありましたが、ひと通り出社しているのと同様の作業はできました。 通勤時の天候を気にしなくてもいいし、通勤時間を有効活用できるのが在宅ワークのいいところですよね。 勤務が終了しても電車に乗って帰る必要はないし、まるでどこでも○アを使って出勤しているような感覚です。 また、定時内に一日の仕事を終わらせなければならないという使命感も芽生え、効率を考えてタスク処理しています。 在宅ワークをするにあたり、自宅ではできない、仕事をするうえで不便なことも多々ありました。 例えば、これは日本の文化とも言えるのかもしれませんが、上長のハンコを必要とする承認作業。 事務作業をメインとする私の業務では、 ①上長の確認が必要な書類をプリント ②上長に内容を確認いただいてハンコをもらう ③しかるべき部署へ提出 という流れが多く発生します。 通常この流れで業務を遂行するには、少なくとも私、上長、しかるべき部署の担当者の３人は出社しないといけません。 これがマイナビ規模ともなれば、密は避けられない状況になります。 とりあえず そこで私は付け焼刃の対策として、メール承認という手段を取りました。 必要な書類を作成・データ化しておき、提出書類と合わせてメール添付したものを送付。 上長に内容を確認いただいて問題がなければ返信をもらい、これをハンコの代わりの証跡とする、という方法。 予め提出先の部署には、こういった流れでハンコの代わりとなるのか、証跡として有効なのか確認をしておく必要があります。 出社して作業するのと比べると明らかに手間は増えますが、最初のメールをテンプレート化しておけば、各々のスケジュールを把握してハンコ巡礼するより結果的に見て楽になったと言えます。 ニャンサムウェアの被害 巷でもちらほら話題になっていますが、 我が家でも、コロナの弊害としてニャンサムウェアが猛威を振るっています。 Webミーティング中だろうが作業中だろうが、どんなに忙しくてもお構いなしに乱入してきます。 特にうちの猫はよく鳴く子なので音声にまで侵入し、さらには画面に映りこむという被害が出ています。 緊急事態宣言解除、その後 現在は、緊急事態宣言解除に伴い出社する方も増えましたが、 密を避け感染拡大を防ぐため６月下旬現在でも引き続き在宅ワーク可能となっています。 今回は緊急的な措置の在宅ワークという事で作業しましたが、 コロナ禍でも対応できる手段があることは発見でしたし、勉強にもなりました。 時間や場所を自由に選べるような働き方が進んでいくのと同時に こういった事務作業に便利なツールの導入も進んでいけばいいなと思いました。 ここまでお読みいただきありがとうございます。 今後も不定期で更新していきますのでお楽しみに！

こんにちは、マイナビエンジニアブログ編集部です。 今回はITソリューション部のアルバイト体験レポート第4弾！バックエンド編です。 アルバイトが働いているイメージがないマイナビですが、実はこれまで紹介したITシステム職のアルバイトさん以外にも、学校や独学で学んだ知識を生かしつつ、マイナビ社員のサポートを受け、様々なことにチャレンジしながら働いている方もいます。 そんな学業とエンジニアを両立している学生アルバイトさんに体験レポートしていただきました。 はじめに 私は情報系の学部の大学生で、プログラミングにもっと触れたくて、コーディングのアルバイトを探していました。 Python, VSCodeというキーワードに魅力を感じて、AtCoderJobs経由で応募したところ、採用されました。 Web系の知識は大学の講義で少し勉強した程度で、バックエンドの知識もほどんどなかったため、まずはFlaskでWeb Serverを立ち上げるなどの基本的なところから始めさせてもらいました。 マイナビのアルバイトとしてバックエンド、特にサーバーレスなどを開発しています。 内容としましては、この環境でこういうものが作りたいというまだ細かく決まっていない依頼がくるので、自分でドキュメント等をいろいろ調べながら数週間かけて完成させるということを繰り返していきます。 次に、実際に作った主なものを時系列順で紹介したいと思います！ シナリオ Slack App データベースのシナリオを読んで、SlackのBOTに流させるというアプリを作りました。 また、選択肢を提示させて、ユーザーが選んだ結果によってシナリオが分岐する機能を持たせました。 この時の私は、APIも分からないような状態でしたので、様々な箇所で詰まりましたが、先輩社員さんに助けてもらいました。 また、先輩社員さんなどのコードを見るという機会もあり、とても勉強になりました。 Web上の記事をGoogle Driveに転送する関数 ヘッドレスChromeを使ってWebページをPDF化して、Google Driveに保存するサーバーレス関数を作りました。 まずは、サーバーを実際に扱ってから始めていくという順序でしたので、比較的取り組みやすかったと思います。 また、これでNode.jsに初めて触れました。 AWSでAPI作成 ある特定の情報を取得するAPIをAWS LambdaとAPI Gatewayで作りました。 APIについて、いろいろと経験してから、実際に作る作業へと移行する順序がよかったと感じます。 マイナビの環境 業務内容 先輩方が作ったツール・APIを組み合わせて開発していくため、その仕様の詳細が書かれた英語のドキュメントや、日本語の記事を読むことが多いです。 それをもとに自分でコードを書いてみて、エラーメッセージを読んだり、検索したりしてデバッグを繰り返してプログラムを完成させます。 開発用の環境が与えられるので、あまり深く考えずにテストすることができます。 周囲の環境 自分の知識に適しながらも、新しいことを学べる案件をいただいていると感じます。 エラーなどで詰まってしまい、自分ではどうしようもない時には、詳しい社員さんに質問もできるので安心です。 また、細かい要件に関しては自分の裁量が大きいと感じます。 勤務時間 平日の業務時間のうち、自分で選んだ時間で働いています。 また、大学の勉強が忙しい場合など、すぐに勤務時間を変更してもらったり、長期の休みをもらったりと融通も利きやすいと思います。 編集部から いかがだったでしょうか。 企業にアルバイトとして働くというのは、学校や独学だけでは得られないことも多く、そこで働く人々の知識やノウハウを学びながら生かせる場でもあると思います。 マイナビには部署、職種、雇用形態の異なる多種多様な人材が肩を並べて働いています。 今後もマイナビで働く様々な方を紹介していきますので、是非ご期待ください。

こんにちは、マイナビエンジニアブログ編集部の井藁です。 新型コロナウイルスが猛威を振るうなか、マイナビ本社がある竹橋（東京）においては緊急事態宣言が出されており、基本的にはリモートワークが義務付けられています。 私もリモートにて業務を行っていますが、その環境や感想などをご紹介したいと思います。 自宅環境の紹介 まずは、自宅環境をご紹介したいと思います。 私は、基本的には私物のデスクトップPCを使用しています。 こちらにはスタンドマイクとWebカメラを接続しており、オンライン会議などではこちらを用いて参加しています。必要に応じて会社支給のiPadも展開し、そちらでしか見られないような情報を確認しながら業務にあたることもあります。 自分はもともと動画編集などを趣味で行っているので環境は整っている方ですが、自宅にPCがない方については、会社支給のノートPCを持ち帰る形で取り組んでいます。 業務のこなし方について 業務内容としては、大きく「社内ネットワークに接続するもの」「社内ネットワーク接続を必要としないもの」の2つに分けられます。 社内ネットワーク系業務はリモートデスクトップ まず、社内ネットワークに接続する必要のある業務については、リモートデスクトップの仕組みを用いて対処しています。これは私のように、会社PCを自宅などへ持ち出していないことが前提です。 この仕組みを用いると、会社PCを遠隔操作できるようになります。会社PCを社内ネットワークに接続していれば、その環境下でしか見られないような情報にもアクセスできるようになる、という仕組みになっています。 このリモートデスクトップについては、やや挙動にラグが生じるものの、ほぼ会社にいるのと変わらない状態で作業をすることが可能となっています。 社内ネットワークにアクセス不要なものは、自宅PCそのままでアクセス 次に、社内ネットワークへのアクセスを必要としない業務については、自宅PCから直接アクセスを行って作業をしています。こちらはIP制限などを掛けていないものが前提になります。 クラウドサービス上での開発などは、基本的に社内ネットワークを踏み台とする必要がないものが多く、リモートデスクトップによる操作をせずとも作業が可能です。自宅PCでアクセスした方が低遅延のため、こちらの方法で対応可能な業務を優先して消化するようにしています。 マイナビのシステム職社員から見た、リモートワークのメリットとデメリット ここからは、リモートワークに取り組むなかで感じたメリットとデメリットについてご紹介します。 通勤時間のカット、作業効率アップによる生産性の向上 まずメリットですが、特に自分が感じたのは 通勤時間が発生しないこと 作業時に干渉を受けにくくなったこと こちらの2点が挙げられます。 通勤時間については体力的・精神的な負荷に加え、持ち時間まで削られるメリットの少ない行動だということを強く再認識しました。この点では、リモートワークに多くのメリットがあると思っています。 リモートワークが本格化する前から時差出勤の取り組みはあり、快適な通勤が可能な環境とはなっていたのですが、切り替わってからはさらに時間的な余裕が生まれたと感じます。 また、集中して業務に取り組みたい時に他の業務が緊急的に割り込むことが大幅に減ったことも、大きなメリットであると感じています。 部署の特性上、問い合わせなどが多く発生するのですが、それらが電話ではなくメールやチャットベースに代わったことで、現在の作業がひと段落してからそちらに取り組む、ということができるようになりました。 マルチタスクをすることが少なくなった結果、作業効率が大きくアップしていると実感しています。 管理部門ゆえの業務、業務内外の境界線、コミュニケーションの取り方 次にデメリットについてですが、 管理部門として、現場にいる必要がある業務がこなしづらい 環境的に、業務内と業務外の線引きが難しい メンバーとのコミュニケーションを維持する難しさ 以上の3点を感じます。 我々は先述の通り管理部門である以上、現場に赴かないとこなせないような業務が一定数以上存在しています。 現在は、物理的に出社を余儀なくされる業務以外は在宅で取り組む必要があるため、その方法で苦戦するシーンが多いと感じています。 ただ、リモートワークをし始めてわかったのは、 ほとんどの業務は在宅ワークでも回る ということです。 「これは出社しないとこなせない」という先入観にとらわれていていたような業務も、工夫次第で何とかなることがわかったのは大きな収穫でした。 また、環境面でのデメリットとして、業務とそれ以外の線引きが難しいこと、チームメンバーとのコミュニケーションが不足しがちなことの2つが挙げられます。 こちらはどの業種でもありがちなことだとは思いますが、私は仕事の区切り（出社時や昼休憩時など）においてチャットツールで積極的に発言をすることで、自律しつつメンバーと交流するように工夫しています。 管理部門のシステム職であっても、リモートは働き方を大きく変える 結論としては、リモートワークでできない業務はかなり少なく、かつ作業効率が上がるということで、デメリットよりメリットの方が大きいと感じました。 新型コロナウイルスの猛威が収まった後も、積極的にリモートワークには取り組んでいきたいなと思います。

こんにちは、システム統括本部 ITソリューション部（現デジタルテクノロジー戦略本部）でアルバイトをしている羊羹です。 今回は、マイナビで約半年エンジニアのアルバイトをした体験をまとめたいと思います！ 自己紹介 名前 羊羹 所属 システム統括本部 ITソリューション部（現デジタルテクノロジー戦略本部） 学年 大学院1年 専攻 情報科学 趣味 ビリヤード 入社まで 私は大学院で情報系の学部に在籍しており、プログラミング経験はありましたが、会社でのシステム開発に使われている技術に触れてみたいと思い、アルバイトを探し始めました。 ビジネスSNS経由でマイナビのアルバイトを知りましたが、実際の業務に幅広く関わることができると伺い、そこに魅力を感じて応募しました。 面接は非常にフランクで、業務内容をしっかりと把握することができたため、入社を決めました。 実際の業務 リダイレクタ作成（研修） マイナビでの業務に慣れるため、初めにリダイレクタの作成という業務を振り分けられました。 具体的には、使わなくなっているドメイン名へのアクセスを新しいドメインへとリダイレクトするアプリケーションの作成です。この業務は言語としてPython、フレームワークとしてFlask、プラットフォームとしてGAEを用いました。これらを用いた開発経験は趣味レベルではあったのですが、外部に公開されるサイトを作ったのは初めてでした。 また、プログラミングができなくても保守運用が行えるように開発/ドキュメント化を行ったことも初めての経験でした。 マイナビニュースの開発業務 マイナビニュースはマイナビが運営するニュースサイトで、社内外の記者が作成した記事を編集者や社員がチェック・承認することで実際のサイトに公開される、という流れで運営されています。この記事管理システムや実際のサイトはruby on railsで開発されています。 バージョン管理にはGithubを用いており、イシューの作成、プルリクエストの発行、レビューを受けて修正、マージ、デプロイといった流れでチーム開発を行っています。チーム開発に参加してみたかった僕としてはこの業務に携わることができて大変満足しています。 感想 実際のアプリケーションの開発や、GA・GTMといったアクセス解析の技術に携わることができ良かったです。 またクラウド構築やフロントエンドの開発など幅広い業務の選択肢をいただいて、その中で開発に携わりたいという希望を尊重してもらえました。 授業や趣味でのプログラミングでは味わえない経験ができたので、業務としての開発経験がない、という人にはおすすめのアルバイトです！

こんにちは！マイナビのシステム統括本部 ITソリューション部（現デジタルテクノロジー戦略本部）でアルバイトとして働いているラです！ 今回は、システム職のアルバイトとして2か月間働いた体験を簡単にまとめたいと思います！ 簡単な自己紹介 名前 ラ 所属 システム統括本部 ITソリューション部（現デジタルテクノロジー戦略本部） 学年 大学１年生 専攻 情報科学 アルバイト面談時の感想 高校や大学でプログラミングの勉強はしていましたが、実際の業務で開発するのは初めてなので、今まで学んできたことが通用するかが少し不安でした。 働き始めてから行ったこと 特に研修はなく、入社2日目から開発を始めました。 DBまわりについてきちんと学んだことがなかったので不安でしたが、実際に開発するなかで様々な知識を習得できました。 Webクローラーの作成 AWS EC2上でwebサイトをクローリングしてデータをDBに保存するプログラムを、Pythonで開発しました。 以前、個人的にPythonでクローリングとスクレイピングを勉強したことがあったので、スムーズに開発することができました。 マイナビニュースの記事ランキング収集バッチ改修 現在は、Google AnalyticsのAPIからページビュー順にデータを取ってきて、閲覧数の順位と記事情報をDBに保存するPython製のバッチの改修に取り組んでいます。 今までプログラミングの勉強をしてきた中で自分で１から開発することはあっても、他人が開発したプログラムを改修する機会はありませんでした。そのため、700行以上あったプログラムの動作を理解するまでに時間が掛かってしまい、思っていたより苦労しています。 働いてみて感じたこと やりたいことにチャレンジできそう 自分が開発で使いたい技術にあまりこだわりがなく、入社前は「サーバーサイド寄りの開発ができたらいいな」くらいの気持ちでした。 実際に入社してからは、自分のやりたいことに合わせてタスクを振って頂き、楽しく開発ができています。また、社員の方や同じアルバイトの学生とも話しやすく、割と自由な雰囲気で楽しく働くことが出来ています！

こんにちは、ソリューションコンサルティング課の山本です。 今回は、業務で年齢制限のバリデーター対応をしたjavascriptをライブラリ化したのでご紹介します。 検索しても出てこなかったので、同じような悩みを抱えている方は是非使用していただければと思います。 本ライブラリの仕様・概要 自分のサービスに適してない人の生年月日について、表示させないようにします。 例） 20代限定のサービスなのに1980年生まれが選べるようになっている 適用させるにあたっての条件や必要処理は以下の通りです。 年、月、日がselect要素である select要素にid要素を付与する必要がある 下限年齢、上限年齢を制御・設定出来る 実際の動きは以下の通りです。 ※18歳以上65歳以下の選択肢のみしか表示させないように制御しています。 例） 2002年を選択した場合→月は今月より前の月しか表示させない 2002年2月を選択した場合→日は本日より前の日しか表示させない 使い方 １．【 リポジトリ 】（※GitHub）よりダウンロードしてください ２．解凍し、ageRestriction.jsをプロジェクト上に配置してください ３．該当ページでageRestriction.jsを読み込んでください サンプル <script src="../js/ageRestriction.js"></script> ４．年・月・日のselect要素にid属性を付与してください（option要素は削除してください） サンプル <select id="year" name="year"></select>年<select id="month" name="month"></SELECT>月<select id="day" name="day"></select>日 ５．ageRestriction.jsのインスタンスを作成します サンプル <script>new AgeRestriction(18, 65, 'year', 'month', 'day');</script> 第1引数：下限年齢 第2引数：上限年齢 第3引数：年select要素のid属性 第4引数：月select要素のid属性 第5引数：日select要素のid属性 以上です！ ソース説明 工夫した点のうち一部をご紹介します。 できるだけソースの追加をしなくても使用できるようにしたかったため、イベント系の動作はコンストラクタ内に記述しました。 結果として、インスタンス生成だけで動作できるようになりました。 月計算と日計算はインスタンス生成時、年select変更時、月select変更時に発火します。 jQueryで書いていたのですが、依存したくなかったのでバニラ化しました。 // コンストラクタconstructor(minAge, maxAge, yearId, monthId, dayId) { ~~~~ ~~~~ ~~~~ this.init(this);}// イベントセットinit(obj) { obj.outputYear(); obj.outputMonth(); obj.outputDay(); obj.yearObj.addEventListener('change', function () { obj.outputMonth(); obj.outputDay(); }); obj.monthObj.addEventListener('change', function () { obj.outputDay(); });} まとめ もっとスマートな書き方も全然できると思いますが、可読性を重視してプログラミングしました。 また使い方もできるだけ簡単にするように工夫しています。 生年月日から曜日を計算するサンプルソースは多数ありますが、このような生年月日自体を制御するソースがなかったのでぜひ使って頂ければと思います。 なお、フロントでのバリデーターだけではなくサーバーサイドでもバリデーターをかけるのは忘れないようにしてください！

こんにちは、システム統括本部 ITソリューション部（現デジタルテクノロジー戦略本部）でアルバイトをしているアスパラです。 マイナビには私のようなアルバイトがいるイメージはあまりないかと思います。 そこで今回は、マイナビシステム職のアルバイトとして約3か月働いた体験をまとめたいと思います！ 簡単な自己紹介 名前 アスパラ 所属 システム統括本部 ITソリューション部（現デジタルテクノロジー戦略本部） 学年 大学院2年 専攻 物理 趣味 絵を描くこと アルバイト内定時の感想 以前、ITベンチャーのシステム職でアルバイトをした経験があったので、初歩的なことは理解していると思っていましたが、特別なスキルを持ち合わせているわけでもなく、 「エンジニアのアルバイトとして社員と一緒に働けるのだろうか」 と心配していました。 紹介していただいた業務には以下のようなものがありました。 バックエンド開発 フロントエンド開発 業務改善ツール開発 画像加工やワイヤーフレーム作成、動画作成などクリエイティブ系 人材開発領域の補助（インターンシップ運営補助など） etc.. 「幅広い業務に関われる」という話を伺い、具体的な業務は内定時に決定していなかったので多少の不安はありましたが、面接時に話しやすい雰囲気で、スキル不足部分は研修で補って頂けるという点で安心できたため、マイナビのアルバイトとして働くことを決意しました。 働き始めてから行ったこと 基礎研修（python習得） ITソリューション部（現デジタルテクノロジー戦略本部）の開発でよくpythonが使われているようですが、私はこれまでにpythonを使ったことがなかったため、マイナビ側で用意していただいた初心者向けの動画やオンライン教材を使いながら、基礎的な部分を覚えました。 基礎文法の習得を行った後、python用のフレームワークであるflaskを用いて、簡単なwebアプリケーションを構築するといった研修を行いました。 基本的には一人で学習を進めていきましたが、まめに社員さんが声をかけてくれるため質問がしやすく、テンポよく習得することが出来たかなと思います。 エンジニアブログの改修 一通りの研修が終わった後、初めの業務としてエンジニアブログのデザインリニューアルのプロジェクトに参加しました。 主に旧環境からの記事データの移行、および移行後のサイトデザインのマークアップを担当しました。 ワイヤーフレーム作成 また、エンジニアブログのプロジェクトと同時並行で、マイナビのシステム社員向けのスキルマップ検索用サイトの立ち上げにも参加しました。 本プロジェクトでは、主にワイヤーフレームの作成を担当しました。 働いてみて感じたこと 質問しやすい雰囲気がある 分からないことは気軽に先輩社員へ聞けるのが良いです。 実際に、開発時に困ったところを助けてもらったりしました。 やりたいことにチャレンジできる環境が整っている 先述の通り、初めは業務内容が分からないため不安がありました。 しかし、研修をしていく中で、私のやりたいこととすり合わせていただく形でタスクを選ぶことが出来ました。 私は以前のアルバイト先でも経験のあるwebのフロントエンドに関わりたいと思っており、実際にその希望通りの業務を割り当てられたと思います。 特殊なスキルや実績が無くてもチャレンジできる 他のアルバイトの方がスキルをしっかり持っている方だったので、私に何ができるのだろうか…と弱気だったのですが、幅広い業務に関わるチャンスがあるため、 純粋なエンジニアのスキル以外にも役にたてる部分がある ことが分かりました。 面接でのお話の通り、 どんな業務にも携われる 職場です。 先輩とも話しやすく、割と自由な雰囲気なので、 スキルに囚われず柔軟に働きたい人 に向いているのではないかな、と思います！ まずは私自身、周りから積極的に学び、エンジニアとして戦力になれるよう引続き頑張っていこうと思います！

概要 この記事は、 マイナビ Advent Calendar 2019 　14日目の記事です。 デスクワークが多いエンジニア。キーボードやマウス・机の環境など毎日使うものだからこそ、こだわりたいものがあるのではないでしょうか。 今回は、マイナビのITソリューション部を中心に、こだわりの周辺機器についてアンケートを取りました。 キーボード 回答してくれたのは14名でした。その中でも約35%程の方がキーボードをこだわって購入したようです。 会社支給PCがノートであるため、別途キーボードを使っている人は少ないようです。 どんなものを使っているのか CK550 CK-550-GKGR1-JP 赤軸 値段：9,000円くらい 理由：安い光るメカニカルキーボードを使って見たかった REALFORCE 108US 値段：20,000円 理由： http://www.realforce.co.jp/products/108US_SJ38D0/ に全て書いてあります FILCO Majestouch 2 TKL S 静音 PGSセット 91日本語 MXピンク軸MechKB ブラック 値段：11,526円 理由：購入当時私物でFILCOのTKL青軸使っていたが、さすがにこれを会社に持ち込むのは躊躇われたので、同型で静音赤軸のこちらを購入。もっとカチャカチャさせたいが、流石にこれが限界かなー VARMILO社のキーボード 値段：日本円換算で2万円くらいだったはず 理由：キータッチが重いものが好みだが、キースイッチの軸が通常日本で一般的に使用されていない重いものがオーダー可能なため選択 こだわった点：87キーの省スペース・キートップの根本がカバーされていないデザイン・重いキータッチ DREVO ゲーミングキーボード Calibur 71Key 赤軸 US Layout Black Bluetooth対応 RGBカラー搭載 軽量コンパクトデザイン 値段：6,479円 理由：「ちょっと買って使用感を教えてよ」と言われたので買ってみた 使用感：特に製品名を見てなかったので、US配列だとは知らなかった。US配列だと知っていれば買わなかったかもしれないが、赤軸の打鍵感が良い。 みなさんの個性が出ている回答でした。 高いものは2万円のもので、こだわりを感じます。 会社で利用することもあり、キーが軽く静音である赤軸が多い印象です。 また、下記のように先輩エンジニアから譲り受けたという人も何人かいました。 Mistel BAROCCO MD650L 分離式 メカニカルキーボード 英語配列 Cherry ML Switch ML1A 採用 アイボリー/グレー MD650L-LUSMGAB1 一言：先輩エンジニアから譲り受けました。英字でキーボードが分裂するのでとても使いやすいです。 調べたところ、2万円するものでした…！その先輩は今はもっと良いキーボードを使っているのでしょうか。 マウス 会社支給PCがノートであるため、マウスは別途購入している人がほとんどでした。 どんなものを使っているのか SANWA社の有線エルゴノミクスマウス 値段：2,000円 理由：仕事のし過ぎで腱鞘炎が酷かったため こだわった点：エルゴノミクスデザインで手首の負担が少ない。有線であること（充電が切れると困る）。 logicool ワイヤレス トラックボール 使用感：手首を動かす必要がほとんどなく楽です。角度調整ができるので、持ちやすいです。もう普通のマウスやトラックボールには戻れません。 ロジクール G502 値段：5〜6,000円だったと思います 理由：スクロールホイールの動き方が変えられる、ボタンが必要十分な数付いている こだわった点：かっこ良いもの Logicool G300S 値段：3,000円くらい 理由：手にフィットする。値段も手頃。無線は反応速度がいまいち ロジクール ワイヤレスマウス M545BK 値段：2,466円 理由：サイドボタンが欲しかった && 当時ロジクールの無線キーボードを使っていたので、Unifyingレシーバー一個でUSBの占領を済ませたかった logicool 値段：1,500円程度 使用感：静音でシンプルで使いやすい BUFFALO Premium Fit シリーズ (BSMBW500M) 理由：無線(Bluetoothは相性が悪かったのでやめた)で静音のマウスが欲しかったため。 メーカー不明 値段：1,000円くらい 理由：安い無線 こだわった点：電源スイッチが無いのでOFFにするのを忘れることがない・センサーが赤いLEDではない メーカ不明 一言：静音マウス、カチカチ言わないのでおすすめです マウスについては、キーボードよりも利便性や使用感についてのコメントが多く、ロジクール製品が多いのが印象的です。 会社で使うこともあり、キーボードの時と同じように、静音のものが多いようです。 その他 他にも肘おきやマウスパッドなど、快適にデスクワークを行えるような工夫が見られます。 机をきれいに整頓できるディスプレイボードが、個人的には気になりました。 肘おき メーカー不明 値段：2000円くらいのものを使用しています。 MMTT ウッドパームレスト 値段：3,480円 理由：木を感じたかった こだわった点：木 マウスパッド Havit 大型マウスパッド ゲーミング 防水 900＊400＊3mm ブラックHV-MP855 値段：1,299円 理由：最初はSteelSeries QcK miniを購入するつもりだったが、会社でそこまで良いものを使う理由はないと思い、ちょうどセール中だったこの大型マウスパッドを購入。机全体を覆うことはできないが、マウスが移動しうる範囲全てを覆えるのでマウスの利用にストレスがなくなった。 他 ディスプレイボード 理由：机上のスペースが有効に活用できます。安い Anker PowerWave 10 Stand 値段：2,999円 理由：スマホの画面を見ながら仕事ができるのと、デスクの省スペース化のために購入。結局スマホの画面を見ながら働くことなんてなかったが、机の上が片付いたので満足 最後に ITソリューション部という内々で取ったアンケートであるため、偏りはあるかもしれませんが、結構みなさんこだわっていることが分かりました！ 毎日使うものだからこそ、満足のいくものを使って、快適に仕事の効率を上げていきたいですね。

こんにちは、マイナビの山本です。 今回はAdvent Calendarに掲載するための記事を、「Bitbucket Pipelines初級講座（マークダウン→HTML変換）」というタイトルで書いてみました。 この記事は、 マイナビ Advent Calendar 2019 　6日目の記事です。 概要 自身が担当しているサービスの中に、【 マイナビニュース 】というものがあります。 その中で使っているマニュアルサイトの内容に変更があった場合、今までは都度HTMLファイルを修正していました。 こちらは負荷が高く利便性にも乏しい状況です。 そこで、更新作業を誰でも可能にするために、「マークダウンからHTMLに変換を簡単に行えるツールを開発する」という内容のプロジェクトを発足しました。 今回、そのプロジェクトではマークダウンからHTML変更とデプロイの自動化ができるCIツールの Bitbucket Pipelines を使用しました。 実はマイナビではBitbucket Pipelinesを使う機会はあまりありませんが、個人的に勉強になりましたので紹介したいと思います。 なおこちらは初級者～中級者向けの記事になりますので予めご了承下さい。 フロー図 ユーザーがpushしたタイミングでPipelinesにてMarkdownからHTMLを生成後、 S3にデプロイするというシンプルなフローです。 ソース bitbuket-pipelines.yml image: atlassian/default-image:2pipelines: branches: master: - step: deployment: production script: - apt-get update --no-install-recommends - apt-get install -y pandoc - sh custom/transformation.sh - pipe: atlassian/aws-s3-deploy:0.3.7 variables: AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY AWS_DEFAULT_REGION: "ap-northeast-1" S3_BUCKET: "*****.****.mynavi.jp" LOCAL_PATH: "./" DELETE_FLAG: "true" '*': - step: deployment: staging script: - apt-get update --no-install-recommends - apt-get install -y pandoc - sh custom/transformation.sh - pipe: atlassian/aws-s3-deploy:0.3.7 variables: AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY AWS_DEFAULT_REGION: "ap-northeast-1" S3_BUCKET: "stg-*****.****.mynavi.jp" LOCAL_PATH: "./" DELETE_FLAG: "true" 説明 今回は、本番と検証で異なるS3にデプロイするため、ブランチによる挙動を変えました。 masterとmaster以外のブランチで挙動をわけています。 まず apt-get update をします。 ※これをしないと apt-get install が出来ません。 --no-install-recommends は時間短縮のためにいれています。 今回Markdown→HTML変換には pandoc を使用します。 pandoc： https://pandoc.org/installing.html pandocはさまざまなファイル形式の変換に使うことができるので、とても便利です。 PDF→マークダウンなどにも対応しています。 sh custom/transformation.sh ではpandocのコマンドをshで実行しています。（後述） S3へのデプロイはBitbucket公式ページを参考に実装しています。 参考ページ： https://ja.confluence.atlassian.com/bitbucket/deploy-to-aws-with-s3-976772858.html AWS CLIを用いてデプロイしている方も多いと思いますが、pipe方式の方が視覚的に分かりやすいと思います。（メンテナンス性） transformation.sh #!/bin/bash# mdファイルのループfor markdown in `ls | grep .md`do # マークダウンをHTMLに変換 pandoc -s --self-contained -f markdown -t html5 -o ${markdown%.*}.html $markdown -c custom/github.cssdoneexit 0 説明 markdownがいくら増えてもいいようなコマンドになっています。 markdown.md、markdown2.md、markdown3.mdがあった際、 markdown.html、markdown2.html、markdown3.htmlを生成します。 markdown4.mdが追加されても自動的にmarkdown4.htmlを生成してくれます。 また、cssを当て込むことができるのでgithub.cssを適用しています。 不満点 ブランチごとに異なる挙動をするためにbranchesセクションを使用しますが、 同じコマンドを一か所にまとめれないのが不便だと感じました。（shellを使えばできる） まとめ 結局このプロジェクトは、CIは使わずWordPressを立ち上げることになりました…（笑） なお、今回の記事執筆の背景ですが、冒頭でも触れたようにマイナビ社内でアドベントカレンダーが発足され、私に順番がまわってきたためエンジニアブログに記載しました（Qiitaやはてなブログ、個人ブログなど、メディアは問わず）。 アドベントカレンダーとは マイナビアドベントカレンダー マイナビの技術的なブログが見れるので、併せてご覧いただければと思います。 ここまでお読みいただきありがとうございました。 執筆：山本

Advent Calendar（アドベントカレンダー）とは？ 一般的には、クリスマスまでの日数を数えるために使われるカレンダーです。 毎日ひとつずつ、「窓」を開け、開け終わるとクリスマスを迎えた、ということになります。 マイナビ Advent Calendar 2019 今回ご紹介したい「 マイナビ Advent Calendar 2019 」は一般的なアドベンドカレンダーではなく、ブログ記事を一日ひとつ書いて、クリスマスまでのカレンダーを埋めていくようなものとなります。 参加者はマイナビの有志のエンジニア、ディレクター、マネージャーさん方です。 もし、興味があれば、是非、チェックしてみてください！ https://qiita.com/advent-calendar/2019/mynavi

こんにちは、マイナビエンジニアブログ編集部です。 ボードゲーム部の紹介 に続き、今回は部員の方に好きなボードゲームに関してアンケートを行いました。 その結果をもとに、オススメのボードゲームを紹介していこうと思います。 紹介するのは、以下の3つのボードゲームです。 宝石の煌き (Splendor) お邪魔者 パンデミック 宝石の煌き (Splendor) まずはじめにご紹介するのは、「宝石の煌き」。 外国発祥のゲームで、Splendorは海外でのタイトルになります。 2014年にドイツのゲーム大賞にノミネートされた、リソースマネジメント系ボードゲームです。 所持する宝石を消費してカードを購入し、カードの持つ得点の合計が15点以上になったら勝利となります。 宝石の煌きには値引きシステムがあり、カードには所持していると特定の宝石をn個値引きするという能力を持つものがあり、ゲームが進むにつれて手持ちの宝石以上のカードを購入できるようになります。 序盤の購入カード次第で、後半に購入できるカードが変化していくので、ただ何も考えずにカードを購入すればいいというわけではありません。 ほかにも、相手に欲しいカードを買われないように予約したりといった駆け引き要素も存在していて、単純ながらも面白いつくりになっています。 お邪魔者 スタート地点から道が描かれたカードを並べてゴールまでの道のりをつくり、ゴール地点の金塊を手に入れるというゲームです。 ただし、タイトルからわかるように妨害役となるプレイヤーが存在します。 妨害役は、他のプレーヤーがゴールにたどり着けなければ勝利となるので、道をあらぬ方向に捻じ曲げたり、行き止まりとつなげたり、さまざまな方法で妨害を行います。 開始状態では誰が妨害役かわからないので、序盤で妨害役としての仕事をして場をかき乱すか、終盤のここぞというところで妨害役として動くか、妨害役の性格が出るところもあります。 妨害役以外にも様々な役職があり、役職によって立ち回りが変わる所も面白いです。 お値段も手ごろで、ルールも覚えやすいので、手軽に行なえるゲームです。 パンデミック 最後にご紹介するのは、パンデミック。協力型ボードゲームの代表ともいえる、超有名ボードゲームです。 知らない人でも、パンデミックという名前からなんとなくゲームの内容を想像できるのではないでしょうか。 パンデミックというのは感染症の世界的大流行を指す言葉です。 このゲームは協力してパンデミックを防ぐというゲームです。 推奨人数は2～4人となっていますが、一人で複数役を操作する、もしくは一役を複数人で操作することが可能です。 よほど大人数でもない限り、遊ぶ人数を気にしなくてもいいという利点があります。 発売が2007年と古くはありますが、数年前に『パンデミック:新たなる試練』として新たにリメイクされていることもあり、古さを感じさせないゲームです。 通常版に追加することでより楽しむことができる拡張版、パンデミックの要素を残したまま別のゲームとして遊べる独立版、レガシー版など複数のシリーズが存在していて、非常に愛されているゲームといえるでしょう。 おわりに 他にも、マイナビのボードゲーム部にはさまざまなボードゲームがあります。 会社公式のボードゲーム部であるため、全社的にも紹介できるようになり、ボードゲーム部を知らなかった人も誘いやすくなりました。 今回のようにエンジニアブログに公開できるようになったのも、公式の部活としてのメリットです。 ボードゲームは他の人とも交流できるツールの一つで、楽しく相手の人となりを知ることもできます。 ボードゲームで遊んだことが無いという方は、ぜひ、遊んでみてはいかがでしょうか。

こんにちは、マイナビエンジニアブログ編集部です。 マイナビシステム職のなかにも、産育休を経て、仕事復帰している女性エンジニアがいます。 そこで今回は、仕事と育児にまい進するワーママエンジニアの一日に密着！仕事内容や取り組み方の工夫、家庭との両立の仕方などを伺いました。 プロフィール S.Mさん システム統括本部 業務ソリューション部 情報システム課所属（現デジタルテクノロジー戦略本部） 司書や学芸員を輩出する大学の文系学部出身。2014年マイナビに中途入社後、産休育休を経て、2018年に復帰。現在はRPAをメインに従業員データベースの管理を担当。 タイムスケジュール 9:15 本日のタスクを確認 出社後、まずはメールのチェック。 その後、Slackで課全体の仕事や、他プロジェクトの共有事項をチェック。タスクを整理し、一日のスケジュールを決める。 9:25 従業員データベースの保守・運用 パッケージ製品のベンダーなど、取引先の進捗確認や資料の確認。 10:00 RPA開発 UiPathやSVNを使用して、業務フロー整理しながらRPAロボットのプログラミング。月平均2、3プロジェクトを平行し、保守対応もしている。 12:30 ランチ パレスサイドビル地下で海鮮丼を購入。 13:30 RPA開発（集中タイム） 営業推進、事業推進、開発課系など、依頼元はさまざま。 一つひとつ業務を整理してフローを組み立てていく。 15:45 コミュニケーション 同僚とちょっと息抜き。席周辺の人を巻き込んで談笑。 16:00 RPA打合せ 新規案件の業務ヒアリング。 ウォータフロー型ではなく、直接事業部から細かくヒアリングをし、作っては直してを繰り返しながらフローを組み立てていく。 スマホで様子を録画して、何度も見返しながら設計やプログラミングの際の思考の整理、出来上がった設計の答え合わせなどをする。 17:00 退勤 保育園お迎えへ。ここからが戦争の始まり！ RPAで業務を自動化 私が所属している情報システム課は、おもにマイナビグループ働く方の、氏名や所属部署、役職などの基本データをデータベースで管理しています。これらのデータは、マイナビのシステムへデータ連携することが多く、毎月の人事異動に合わせてメンテナンスをしています。 また働き方改革の一環として、業務改革を推進する部署が主導となりRPAプロジェクトを進めています。RPAとはRobotic Process Automation /ロボティック・プロセス・オートメーションの略語で、パソコン上の操作を記録して人の代わりに作業をするソフトウエア型のロボットです。これまでの業務の流れを変えることなく自動化できるので、作業スピードが上がり、作業負担の削減と生産性の向上などの効果に繋がります。 現在マイナビでは、外部ベンダーが開発するパターンと、社員が内製で開発するパターンがあり、私は内製開発を担当しています。開発要員は私を含めて２名で動いており、もう一人の社員がリーダーとなって、プロジェクト管理やスケジュール調整、開発を行っています。私はプログラミング手前のヒアリングやフローの設計段階から、プログラミング、導入、保守、改修に携わっています。（RPAについて、詳しくは こちら ） RPAプロジェクトは、事業部からの「導入したい！」という声からスタートします。そこからRPAに向いている業務か、内製するかなども踏まえて開発スケジュールを整理したあと、具体的な業務のヒアリングやプログラミング作業に入っていきます。実際の業務フローを一つひとつ整理して、今まで人の手や判断が入っていた流れをシステム的なロジックに組み直すところは、実際の業務と齟齬が発生しないよう毎回とても神経を使うポイントです。依頼側と開発側でお互いにできるだけ業務知識のギャップをなくせるよう、実際のRPAで動作を確認してもらうなどして、こまめにキャッチボールしながら臨機応変に対応しています。私の一日の動きとしては、プログラミングがおもにはなりますが、ヒアリングや打合せで大半を占める日もあります。 やりがいを感じる瞬間 実装した動作を実際に見てもらって、喜びの声を直接聞けたときが一番やりがいを感じる瞬間です。「こんなこともできるんですね！」と感動してもらえると、私も「作ったよかった」という達成感を得られます。その一方で、新たな課題が見つかって改修しなければならない場合もあります。実際にマイナビで導入しているRPAは、人と同じように組織に所属するアカウントを与えています。はじめは新入社員と同じように、躓いて（止まって）は修正を加えたり、新たに機能を加えたり、「できることをどんどん増やしていけるよう一緒に育てていきましょう」と声をかけて進めています。 マイナビグループにおいては、まだまだITの力で効率化できる部分がたくさんあると思います。そこをRPA化することで「ここに充てていた時間を有効活用できる。とても助かった！」といった笑顔をもっと見てみたいなと思っています。 復帰後の変化 仕事に復帰してからは、子どものお迎えなどの都合で時短勤務していることもあり、周りにはとても助けてもらっています。 復帰直後は残業ができない分、だんだんと仕事が後ろ倒しになっていき、以前のようなクオリティを維持できないことに悩んだ時期もありました。上司に相談し、プロジェクト管理系の打合せはスキップさせてもらうなど、作業時間をできるだけ確保できるよう対応してもらいました。また個人としても、不明点を徹底的に深堀りすることはやめて「ここまで調べたらやめよう」など、ある程度作業に見切りをつけることで時間を有効に使えるよう考え方を変えました。 とはいえ、限られた時間でこなせない事もまだまだ多いので、その分何かで補填できるようになりたいなと思っています。RPA開発要員としては、まだスタート地点にたったばかりなので、できるだけ効率よく、スピード感をもって仕事をこなせていけるよう、日々精進です。 育児についても姑に頼ったり、夫と協力して家事を分担しています。それを当たり前と思わずに、感謝の気持ちを忘れないように心掛けたいです。 この記事に登場する部署 システム統括本部 情報システム課（現デジタルテクノロジー戦略本部） システム統括本部はマイナビ全体のシステムを統括する部門です。 その中で情報システム課では、社内向けの情報系サービス領域およびIDマネジメントを担当しています。 主に社員向けの各種システムやサービスについて導入・運用を行うとともに、事業部門への展開・運用設計サポートなどを行っております。

こんにちは、マイナビエンジニアブログ編集部です。 会社は、単なる仕事するだけの場所ではなく、社員同士や仕事を通じて築いた社外との交流に溢れた場所でもありますよね。 マイナビでは 福利厚生 として、『社員間の親睦』を目的とした会社公式のクラブを設立したり参加することが可能です。 ということで今回は、ボードゲーム部の紹介をします！ ボードゲーム部の紹介 ボードゲーム部はもともと、週に1回程度、社外で集まって活動していました。 徐々に人数が増えたこともあり、オフィシャルに活動するためマイナビ社内でのボードゲーム部設立に至りました。 活動内容 今でも、活動の頻度は週に一回程度。 ボードゲームは部員の持ち寄りや、皆さんが楽しめそうなゲームを部費で購入しているといいます。 実際にプレイするボードゲームは、集まった人数や、その時のフィーリングで選んでいるそうです。 活動の雰囲気 部員の方の多くは、いい意味で皆さん遊びに一生懸命になれるタイプだということで、初めてのボードゲームでも即時に戦略を立てられる方が多いそうです。 あと、なぜか野球好きな人が多いとのこと。それぞれが戦略を立て、相手の心理を読みながら進めていくところは、ボードゲームにも共通する部分なのかもしれませんね。 部長からのコメント ボードゲームを通して、社員交流の活性化やの相互理解強化をしていきたいと思っています。そのため、部員以外を含めた社内ゲーム会の実施や、社外の人を含めたオープン会の実施も積極的にしていければと考えています。 部員のなかには去年、「カルカソンヌ」は予選を突破して全国大会に進んだ方もいます。この他にも「カタンの冒険者たち」など、メジャーなボードゲームは全国大会も実施されていますので、今後はこちらへの参戦もしていくつもりです。 入部を希望される方、興味を持った方は、ITソリューション部 鈴木までご連絡ください。 まとめ ボードゲーム部のように、さまざま部署から個性豊かなメンバーが集まり、ひとつのボードゲームを囲みながら生まれる交流もあります。 マイナビには今回ご紹介したボードゲーム部の他にも多種多様な部活動が盛んに行われています。皆さんも自分に合った部活動を探してみてはいかがでしょうか。

こんにちは、マイナビエンジニアブログ編集部です。 とても有名なことわざがあります。 「腹が減っては戦ができぬ」 マイナビには営業、制作、エンジニアなど職種は多岐にわたりますが、 どの職種であっても、さまざまな案件を相手に、日々戦っています。 そう、職場は戦場。いいパフォーマンスは、美味しいランチがあってこそ！ そこで今回は、私たちの日々の戦いを支える脇役でもあるお弁当をご紹介します！ はじめに ランチはレストランで食べる料理だけではありません。 お弁当屋専門店やレストランで販売しているお弁当など、マイナビ竹橋本社のあるパレスサイドビルのなかだけでも、さまざまな種類のお弁当があります！ 外でリフレッシュしながら食べるのもよし。デスクで一緒に働く仲間と楽しく食べるのもよし。場所を選ばず食べられるのが、お弁当のいいところですよね。 ぜひ、この記事を参考にその日の気分にピッタリのお弁当を探してみてください。 ロースかつ弁当（まるや）　600円 1つ目はロースかつ弁当です。 今年の5月、西コア地下1階にオープンしたばかりの「とんかつ まるや 竹橋店」の店外で販売しています。 たったの600円でサクサクのとんかつを味わうことができます。 ロースかつ弁当以外にもヒレカツ弁当などの種類もあり、どれも食べごたえがあって美味しいです。 豚生姜焼弁当（彩月）　500円 2つ目は「彩月」の豚生姜焼弁当。 盛りだくさんのこのお弁当には、生姜焼き以外にも鶏肉の唐揚げやエビフライなども入っていて、生姜焼き以外は日によっておかずの内容が変わります。 東コア地下1階にある「彩月」は弁当専門店ということもあり、他にもさまざまなお弁当が販売されています。 中華丼弁当（赤坂飯店）　500円 3つ目は、地下1階の中央あたりにある中華料理店「赤坂飯店」の中華丼弁当です。 ご飯の上に乗っているものは鶏肉の唐揚げ、シュウマイ、ちくわ揚げです。 シンプルなビジュアルですが、具だくさんでご飯も量が多く、とてもボリュームがあります。 まとめ 今回紹介したお弁当は3つだけですが、どれもボリュームがあって、しかも美味しくてコスパ最高だと思います。 パレスサイドビルには、他にもさまざまなお弁当がありますので、また次の機会にご紹介します！

SMEW（スミュゥー）は、日本語で「ミコアイサ」というカモ科の鳥類の名称です。 本記事ではSMEWと名付けられた、マイナビの独自インフラサービスを紹介します。 はじめに SMEWとは、Simple ManagEd Websiteの略で、LP(ランディングページ)などの比較的シンプルな構成のWebサイトを短い期間で公開するためのサービスです。 従来は、Webサイトを構築する際、Webサーバーやデータベースサーバーの構築から始まり、ネットワークの設定をした上でコンテンツの作成や配置をするという手順を踏んでいたため、どうしても時間がかかっていました。 これに対し、SMEWの基本設計は、Webサーバーやデータベースサーバーをあらかじめ用意しておき、Webサイトを作りたいといった社内からの要望に対して「すでに用意されている環境」と「コンテンツを配置する場所」だけを提供するというものです。 このSMEWはシステム統括本部ITソリューション部で内製しており、すでにマイナビが管理する一部のサイトで利用されています。 今回はその構成について紹介したいと思います。 システムの構成 このサービスは、短期間でリリースできるということの他に、可搬性と可用性にも主眼をおいて設計しました。 Webサイト成長していった場合、このサービスの構成では不十分になってくることがあり、その時にコンテンツをできるだけそのまま別のWebサーバーに移植できるよう、可搬性を重要視しました。 また、可用性については、ひとつのWebサーバーで複数のサイトをホストすると、Webサーバーの再起動がすべてのサイトに影響するなどメンテナンス性に欠けます。そのため、すべてのWebサーバーが独立して動いている必要がありました。 この両方を実現するため、DockerコンテナでWebサーバーを稼動させ、コンテンツをDockerコンテナとは別のNASに配置するようにしました。 Webサーバーが稼働するDockerコンテナは、すべてのサイトで全く同じコンテナが動いており、違うのはNASに配置されたコンテンツだけという状態です。 これによりサイトごとにメンテナンスできる上に、環境に依存しないコンテンツしか配置できないという状態を実現しました。 システムの冗長化 前項で触れた可用性は冗長構成によっても実現されています。 サービス全体の前段にあるロードバランサーが、2台のリバースプロキシうちどちらかにアクセスを振り分けます。2台あるリバースプロキシは片方がダウンしていてももう片方がアクセスを捌くため、設定変更やメンテナンス時にもダウンタイムなしで運用できます。 同様にひとつのサイトに対してコンテナも2つ割り当てられます。これもリバースプロキシからどちらかに割り振られ、片方からのレスポンスがない場合は自動的にもう片方にアクセスを振り直します。 データベースサーバーに関してはデータの一貫性を保つためにシングルマスター構成になっています。常にスレーブサーバーへレプリケーションしており、データベースの障害が発生した場合にはスレーブをマスターに昇格させできるだけ短いダウンタイムでWebサイトを継続できるようになっています。 ユーザーからの見たサービス これまで説明してきたように、SMEWは比較的堅牢な構成をしていますが、利用者から見ると単純なサービスに見えるのも特徴のひとつです。 SMEWの利用申請をするとFTPアカウントとURLが発行されます。FTPを使ってコンテンツを配置したあと、発行されたURLにアクセスすると先ほど配置したコンテンツが見られます。 仮想マシンの数やデータベースの構成を考える必要がなくなり、コンテンツの作成に集中できるようになります。 まとめ コンテナを利用したWebサーバーを提供するサービスをシステム統括本部ITソリューション部で内製しています リバースプロキシの設定とコンテナの立ち上げとFTPアカウントの発行という3つの作業でWebサイトを利用し始められるため、従来のWebサーバーよりも格段早く利用できます 利用者は考慮しなくても冗長構成の取られたWebサーバーが利用でき、コンテンツに集中できます この記事を読んで、マイナビのサービスをより深く知ってもらい、 成功や成長のきっかけ を縁の下で手助けするマイナビのエンジニアに興味を持っていただけたら幸いです。

こんにちは、マイナビエンジニアブログ編集部です。 今回はマイナビの福利厚生をご紹介したいと思います。 会社に所属するうえで重要なポイントとなるのが、この 「福利厚生」 ですよね。 では、マイナビの福利厚生にはどのようなものがあるのでしょうか。 実際に働いているマイナビシステム職の方に、どのような福利厚生を利用しているのかを調査しました！ 充実した福利厚生制度 財形貯蓄 財産形成をしやすくし、生活の安定が図れるように作られた福祉制度です。 保養所・その他提携施設 社員の保養、健康増進をはかることを目的として、越後湯沢、軽井沢、箱根仙石原、箱根湯本、逗子、京都、有馬、沖縄 など9ヵ所に保養所を所有しています。 スポーツクラブ 月4回まで法人価格で施設を利用することができます。 社内クラブ 『社員間の親睦』を目的としたクラブ活動を会社公認で支援しています。 家事代行サービス 家事代行サービスを利用する際に、マイナビ提携企業のサービスを利用した場合、所定の割引を受けることができます。 マイケアルーム 竹橋・新宿・大阪に、マイナビグループ社員専用のマッサージルームを完備しています。 ライフプラン制度 老後資金形成のための支援制度です。 なんでも相談窓口 悩みを認知行動療法という手法を用いて、プロのカウンセラーが解決方法を一緒に探してくれます。 更に詳しい説明は こちら にありますので、ご覧ください。 実際に使用した社員の声 保養所・その他提携施設 新潟にも保養所があるので、 スキーに行く際に安く利用できて便利です 。 どこの保養所も 綺麗で広く 、調理道具なども整っていてとても満足しています。 スポーツクラブ スポーツクラブは、 自分のスケジュールに合わせて都度払いで安く利用できる のが良いです。 通常の金額では高額になるところが、 リーズナブル且つ気軽に運動できてよかった です。 マイケアルーム 社外と比較するとかなり安価で助かっています。鍼なども施術してくださるので 満足度が高い です。 気軽に予約できて、しかも安い！ 会社で施術を受けられるので、疲れが取れてしっかりリフレッシュできます。 実際に一番使われているものってなんだろう 福利厚生制度のなかでも圧倒的に人気なのは、 保養所とスポーツクラブ でした。どちらも利用するという方も多く、とても満足度が高いことが伺えます。 次に人気なのは、 マイケアルーム 。マッサージは何度も使用しているという方が多く、デスクワークが多いシステム職にとっては大変ありがたい制度ですよね。 まとめ 今回の調査では、ほとんどの方が働き方やライフスタイルに合わせて、適度に福利厚生を利用していることがわかりました。また、利用する福利厚生の種類やその利用方法も人それぞれ異なるので、周りの人が普段どのように利用しているのかを聞いてみるのもいいのではないでしょうか。 この記事を参考に皆さんがもっとマイナビの福利厚生を有効活用して、さらに充実した生活を送ってもらえたら良いなと思いました。

こんにちは、マイナビエンジニアブログ編集チームです。 今回は株式会社Nulab発、Backlogのボードゲーム「PROJECT THEME PARK」で、プロジェクト管理のシミュレーションワークを実施しました！ ここではワークの様子をレポート形式でお届けしたいと思います。 なお、こちらのボードゲームはNulabさんより頂いたものです、ありがとうございます！ 「PROJECT THEME PARK」とは？ 「PROJECT THEME PARK」は、プロジェクト管理をする難しさと重要性をゲーム形式で楽しく学ぶためのボードゲームです。 目標は、「 チームメンバーで協力し、決められた納期までにテーマパークを建築する 」こと。 実際のプロジェクト管理さながらの本格的な内容となっており、全体を見通す力や臨機応変な対応力、さらにはボードゲームならではの運などが求められるバランスの取れたゲーム性となっています。 今回はこちらを、マイナビエンジニアブログ編集部があるITソリューション部のメンバー5名で実際にプレイしてみました。 開始前にルールをチェック！ 初めてプレイするということで、まずはルールブックを見ながら手探りでセッティングに取り掛かります。 ざっくりとルールを説明すると、こんな感じ。 各人に固有スキルのある役職、およびやる気カードが与えられる 建築予定のアトラクションカードは20枚ある 5ヶ月（5ターン、最大+1ターン）以内に、チーム内で上記アトラクションを17枚以上建築成功させる アトラクションは、やる気カードの数値とサイコロの出目の合計値が特定条件を満たしていた場合のみ建築成功となる それぞれの月で特殊イベントが発生。プレイが有利になったり不利になったりする 事前に建築するアトラクションを宣言してから特殊イベントが明かされ、サイコロが振れるようになる ※我々は上記のような理解で取り組んでみました。もし解釈が異なっていたら申し訳ありません。 特殊イベントが毎月発生したり、事前に建築の見通しを立てなければならなかったり と、本格的な要素が垣間見えていますね。 手探りながらもゲーム開始！ ルールを確認しているなかで「ちょっと難しそうだな」と感じつつも、取りあえずやってみようという流れに。 まずはチームメンバーに役職を割り振ります。 私は「トラブルメーカー」の役に。 他人のやる気カードを約1/2の確率で失うということで、本当にトラブルメーカーですね…。 そして、建築会議がスタート。 「どのくらい建築すればいいのか」「そもそもどのくらい建築の幅を広げていいのか」など、チームメンバーでああだこうだ議論しながら方針を決定しました。 さっそくイベントが発生。 台風直撃やインフルエンザ流行など、現実に起こりそうなイベントが多く、ゲーム進行上も大きく方針転換しなくてはならないような自体にも出くわすことになりました。ゲームと言えど、そこまで見通させるとは…。 成功のカギを握るのは運ということで、実際にサイコロを振る場面では緊張感あふれる空気に。 というのも、 建築失敗するとクライアントからの信用を失い、最悪ゲームオーバーになる恐れもある ため、進行バランスを考えるのが本当に難しい。 実際にプレイしている過程では、運良く成功したり、逆に運悪く失敗したりと波乱万丈な展開になりました。 プロジェクト達成の成否は…？ 逆さまになっていて見えづらいですが、何とかプロジェクト達成！ 信頼度はゲームオーバー手前、期間も延長したうえでの達成、ということで本当にギリギリの戦いでした…。 プレイ後の感想は？ それぞれの役職や運は良かった方かなと思うのですが、それでも何とか達成できる難易度ということで、「プロジェクト管理は本当に難しいんだな」と改めて実感させられました。 「もっとあの時こうしておけばよかった」といった事後の反省会も盛り上がったので、また挑戦する際には、より円滑にプロジェクト管理ができればなと思います！ ここまでお読みいただきありがとうございました。