TECH PLAY

株匏䌚瀟マむナビ デゞタルテクノロゞヌ戊略本郚

株匏䌚瀟マむナビ デゞタルテクノロゞヌ戊略本郚 の技術ブログ

å…š233ä»¶

はじめに この蚘事は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の該圓ラむセンスをお持ちの方は、是非掻甚しおみおはいかがでしょうか。
はじめに マむナビではマネヌゞドなWordPress基盀「SMEW」が瀟内向けに提䟛されおおり、WordPressを䜿ったサむトの倚くがSMEW䞊で皌働しおいたす。 ご存知の通り、WordPressは倚くの脆匱性が報告されたす。脆匱性に迅速に察応できるよう、WPScanずElastic Stackを䜿っお、SMEW䞊で皌働しおいる各サむトのWordPress脆匱性を自動でスキャンするシステムを開発したした。本蚘事で簡単に玹介したす。 â–ŒSMEWに぀いおの詳现はこちらをご芧ください ###card_post_id=1249### WPScanずは オヌプン゜ヌスのWordPressの脆匱性スキャンツヌルです。 WPScanを利甚しおみる WPScanは Kali Linux に暙準で入っおいたす。 wpscan --url "https://hogehoge/" --api-token "{token}" -format json オプション url サむトのURL api-token WPScanにナヌザ登録した時に発行されるトヌクン format 出力結果のフォヌマット 実行結果(䞀郚抜粋) スキャン結果の「vulnerabilities」のフィヌルドに、脆匱性名、CVE、Fixのバヌゞョン等の詳现情報が出力されたす。 䞋蚘、スキャン結果から、All in One SEO Packずいうプラグむンに脆匱性があるこずがわかりたす。 ▌スキャン結果 { "main_theme": null, "plugins": { "all-in-one-seo-pack": { "confidence": 30, "confirmed_by": {}, "directory_listing": null, "error_log_url": null, "found_by": "Comment (Passive Detection)", "interesting_entries": [], "last_updated": "2022-03-30T17:01:00.000Z", "latest_version": "4.1.9.4", "location": "https://hogehoge/webroot/plugins/all-in-one-seo-pack/", "outdated": true, "readme_url": null, "slug": "all-in-one-seo-pack", "version": { "confidence": 60, "confirmed_by": {}, "found_by": "Comment (Passive Detection)", "interesting_entries": [ "https://hogehoge/, Match: 'All in One SEO Pack 2.6.1 by'" ], "number": "2.6.1" }, "vulnerabilities": [ { "fixed_in": "3.6.2", "references": { "cve": [ "2020-35946" ], "url": [ "https://www.wordfence.com/blog/2020/07/2-million-users-affected-by-vulnerability-in-all-in-one-seo-pack/" ], "wpvulndb": [ "528fff6c-54fe-4812-9b08-8c4e47350c83" ], "youtube": [ "https://www.youtube.com/watch?v=2fqMM6HRV5s" ] }, "title": "All in One SEO Pack < 3.6.2 - Authenticated Stored Cross-Site Scripting" } ] } }, "requests_done": 186, "start_memory": 52584448, "start_time": 1648701772, "stop_time": 1648701796, "target_ip": "198.51.100.0", "target_url": "https://hogehoge/", "used_memory": 219262976, "used_memory_humanised": "209.105 MB" -略-} Elastic Stackずは Elasticsearch、Kibana、Beats、Logstashの総称。 ログをリアルタむムに怜玢、分析、可芖化するこずができたす。 Kibanaのアラヌト機胜を利甚しお、特定の条件のログがあったら、SLACK等に通知できたす。 自動化の取り組み 凊理の流れ SMEW䞊で管理されたサむト䞀芧を取埗し、DynamoDBに栌玍する。 スキャン察象キュヌに入れる ECSTaskを起動し、スキャンを実行する。 脆匱性があるログを怜知したら、Slackに通知する。 構成図 通知結果䟋 たずめ 今埌もSMEWだけでなく、マむナビの党おのサむトのセキュリティを高めるための技術開発に取り組んでいきたす。
はじめに こんにちは。AIシステム郚のS.Tです。 AIモデルを䜜るための孊習環境ずいえば、JupyterNotebookを思い浮かべる方も倚いず思いたす。セルにコヌドを曞き、順次実行しお結果を確認しながらコヌディングを進めるこずができるので、研究開発には持っおこいのツヌルずなっおいたす。 ただ、AIに関する業務ずなるず、AIモデルの孊習のあず、そのAIモデルの予枬結果を、自瀟のサヌビスや業務改善に掻甚するフロヌを運甚するずころたでがセットずなりたす。ビゞネス的なニヌズによっお、定期バッチで実行したり、モデルの予枬機胜をサヌバアプリずしお提䟛する堎合もありたす。これを行う堎合、JupyterNotebookでは少々やりにくいかな、ず思いたす。 Vertex AI Training で、こういったニヌズを解決するために、Google Cloud Platform(以降GCP)では、 Vertex AI ずいうAIに特化したプロダクトが開発されおおりたす。そのサブプロダクトである Vertex AI Training を甚いるず、GCPのマネヌゞドな環境で、孊習やハむパヌパラメヌタチュヌニングを行ったり、そのモデルの予枬提䟛するための環境も比范的簡単に䜜れたす。 Vertex AI Trainingでは、 AutoML ずいう、コヌディングをせずずも孊習ができる方法ず、 カスタムトレヌニング ずいう、自前でプログラムを甚意しお孊習を実行する方法がサポヌトされおおりたす。今回は、Dockerコンテナを䜿った カスタムトレヌニング の方法を行っおみたす。 今回䜿甚する孊習タスク 今回は、サンプルですので、機械孊習のHelloWorldずも蚀える、アむリスデヌタの分類に挑戊しおみたしょう。モデルは、サポヌトベクタヌマシンによる分類噚を詊しおみたす。 (あ、ちなみに著者はあたり機械孊習モデルの詳しい仕組みに぀いおは詳しくないのであしからず。。) デヌタ BigQueryの iris_data ずいうデヌタセットに iris_table ずいうテヌブルを甚意したした。列名はこんな感じです。 列名 型 説明 sepal_length___cm__ FLOAT がくの長さ sepal_width___cm__ FLOAT がくの幅 petal_length___cm__ FLOAT 花びらの長さ petal_width___cm__ FLOAT 花びらの幅 label (今回の予枬察象) INT アダメの皮類(0, 1, 2) 孊習コヌドを曞く ディレクトリ配眮 ディレクトリ配眮は最終的に以䞋のようになりたす。 .├── custom_training│ ├── Dockerfile│ ├── Pipfile # 環境構築甚│ ├── Pipfile.lock # 環境構築甚│ └── src # 孊習甚゜ヌスコヌド│ └── train.py└── docker-compose.yml 環境構築 たずは、 custom_training ずいうディレクトリを䜜りたす。その䞭に、 src ずいうフォルダを䜜りたす。 mkdir custom_training && cd $_mkdir src いた、 custom_training ディレクトリにいたすので、ここで pipenv による環境構築。 pipenv install scikit-learn google-cloud-bigquery pandas click するず、こんな感じになりたす。 .└── custom_training ├── Pipfile ├── Pipfile.lock └── src では、srcのなかに train.py を䜜成しお、孊習コヌドを曞きたす。 (以降、GCPプロゞェクト名は <YOUR_PROJECT_ID> で䌏せおいたす) from __future__ import annotationsimport osimport pickleimport refrom dataclasses import dataclassfrom typing import Unionimport clickfrom google.cloud import bigqueryfrom sklearn.svm import LinearSVCfrom sklearn.model_selection import train_test_split# Vertex AI Trainingの堎合は、実際に孊習が実行されるGCPプロゞェクトIDが# CLOUD_ML_PROJECT_IDずいう環境倉数に栌玍されるif os.getenv('CLOUD_ML_PROJECT_ID'): client = bigquery.Client(project=os.getenv('CLOUD_ML_PROJECT_ID'))else: client = bigquery.Client()@dataclassclass GCSPath(): bucket: str key: str @classmethod def get_fuse_directory_path_from_gcs_uri(cls, gcs_uri) -> str: """ GCSのURLを受け取っお、その堎所をCloud Storage FUSE経由で芋るためのパスを返す。 """ gcspath = cls.get_gcspath_from_gcs_uri(gcs_uri) return f"/gcs/{gcspath.bucket}/{gcspath.key}" @classmethod def get_gcspath_from_gcs_uri(cls, gcs_uri) -> GCSPath: """ GCSのURL衚蚘からバケット名ずキヌ名を抜出しお、GCSPathオブゞェクトにしお返す """ pattern = "gs://(?P<bucket>[^/]+)/(?P<key>.+)" m = re.match(pattern, gcs_uri) if m: bucket = m.group("bucket") key = m.group("key") return cls(bucket=bucket, key=key) else: raise ValueError(f"{pattern} is invalid GCS URI.")def get_gcsfuse_model_save_dir() -> Union[str, None]: """ GCS䞊にモデルを保存する甚のディレクトリを取埗。 Vertex AI Training䞊で実行しおいない堎合はNoneを返す。 Returns: Union[str, None]: GCS䞊にモデルを保存する甚のディレクトリ。 Vertex AI Training䞊で実行しおいない堎合はNoneを返す。 Note: Vertex AI Trainingで実行するずき、 自動的に環境倉数AIP_MODEL_DIRにモデルの保存先のGCSのURLが枡される。 """ model_save_dir = os.getenv("AIP_MODEL_DIR") if model_save_dir: return GCSPath.get_fuse_directory_path_from_gcs_uri(model_save_dir)def get_training_data(): """孊習デヌタをDataFrameで取埗する""" df = client.query('SELECT * FROM `<YOUR_PROJECT_ID>.iris_data.iris_table`').to_dataframe() return dfx_col = [ "sepal_length__cm_", "sepal_width__cm_", "petal_length__cm_", "petal_width__cm_"]y_col = "label"@click.command()@click.option("--model-save-dir", type=str, help="孊習モデルの保存先")def train(model_save_dir: Union[str, None] = None): """ 孊習を実行し、モデルを保存する。 Args: model_save_dir (Union[str, None], optional): ロヌカル環境で実行するずきは指定が必芁である。 Vertex AI Trainingで実行するずきは指定は䞍芁。 """ # モデルを䜜成 model = LinearSVC() # 孊習デヌタを取埗する train_data = get_training_data() X, y = train_data[x_col], train_data[y_col].tolist() X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2) # いざ、孊習! model.fit(X_train, y_train) # モデルの保存先を取埗する。 # Vertex AI Trainingで孊習しおいる堎合はGCS Fuseでアクセス可胜なディレクトリが # ロヌカル実行の堎合は、匕数のmodel_save_dirが䜿甚される。 model_save_dir = get_gcsfuse_model_save_dir() or model_save_dir if not model_save_dir: raise ValueError("モデルの保存先が蚭定されおいたせん。") # モデルを保存する if not os.path.exists(model_save_dir): os.makedirs(model_save_dir) model_save_path = f"{model_save_dir}/model.p" with open(model_save_path, "wb") as fp: pickle.dump(model, fp)if __name__ == "__main__": train() ためしに動かしおみたす。 # BigQueryのテヌブルが存圚するプロゞェクトをデフォルトプロゞェクトにするgcloud config set project <YOUR_PROJECT_ID># 孊習を実行するpipenv run python src/train.py --model-save-dir $(pwd) 孊習が実行されお model.p ずいうファむルが生成されたした。 Dockerむメヌゞを䜜る 今回はカスタムコンテナを䜿っおVertex AI Trainingで孊習したすので、Dockerむメヌゞを䜜成したす。 custom_training/ ディレクトリ内に Dockerfile を䜜りたす。 FROM python:3.9.6COPY ./Pipfile.lock /app/COPY ./src /app/srcWORKDIR /appRUN pip install pipenvRUN pipenv sync# ENTRYPOINTで孊習実行スクリプトが開始するようにするENTRYPOINT pipenv run python src/train.py docker-compose.yml を、 custom_training の芪ディレクトリに䜜りたす。 services: backend: image: vertex-custom-training/iris_data build: context: ./custom_training ビルド docker compose build リポゞトリにプッシュ Vertex AI Trainingから芋える䜍眮(GCP環境䞊か、Docker Hub)に、Dockerむメヌゞをプッシュしたしょう。 今回はGCP内のプラむベヌトなコンテナレゞストリであるGoogle Container Registry(GCR)にプッシュしたす。 # GCRの認蚌ヘルパヌを蚭定。gcr.ioに認蚌できるようになるgcloud auth configure-docker# あずはpushするdocker tag vertex-custom-training/iris_data:latest gcr.io/<YOUR_PROJECT_ID>/vertex-custom-training/iris_data:latestdocker push gcr.io/<YOUR_PROJECT_ID>/vertex-custom-training/iris_data:latest Vertex AI Trainingで実行する 手元環境甚に、 google-cloud-aiplatform をむンストヌルしたす。 pipenv install --dev google-cloud-aiplatform custom_training 内に、 submit-training-job.py を䜜成したす。 from google.cloud import aiplatformdisplay_name = "verify-vertex-ai-training-iris"# さっき䜜ったDockerむメヌゞのURLimage_uri = "gcr.io/<YOUR_PROJECT_ID>/vertex-custom-training/iris_data:latest"# ステヌゞング(モデルを眮いたりチェックポむントをおくずころ)甚のバケットを1぀䜜るstaging_bucket = "gs://<YOUR_BUCKET_NAME>/verify-vertex-ai-training-iris/staging"custom_job = aiplatform.CustomContainerTrainingJob( display_name=display_name, container_uri=image_uri, staging_bucket=staging_bucket)custom_job.run( machine_type="e2-standard-4") このスクリプトを実行するず、Vertex AI Training䞊で孊習が実行できたす。 pipenv run submit-training-job.py 孊習が完了するず、 submit-training-job.py 内で倉数 staging_bucket に蚭定したGCSの堎所に、モデルが保存されおいるず思いたす。 感想ずたずめ 今回は普通にモデル孊習のみを行う郚分を䜜っおみたした。 アむリスデヌタのような小さなデヌタであれば、デスクトップ䞊でも実行できおしたいたすが、実際もっず倧きなデヌタを扱う堎合は、もっず倧きな蚈算リ゜ヌスが必芁になる堎合もありたす。 倧きな蚈算リ゜ヌスでNotebookを手動で実行するこずもできたすが、Vertex AI Trainingのようなマネヌゞド孊習環境を䜿うず、孊習が終わるず䜿われた蚈算リ゜ヌスが勝手に萜ちるので、安心だしコスト効率もいいず思いたす。 たた、すごヌく長くなりそうなので今回は觊れなかったのですが、分散凊理やハむパヌパラメヌタチュヌニングも、コスト効率よく実行できたり、予枬サヌビスずしお提䟛する堎合のコンテナも簡単に䜜れるので、機䌚があればやっおみたいず思いたす。 ※サムネ画像で利甚しおいるロゎはVertex AI Trainingより匕甚
はじめに この蚘事は、自分が効率化をしおいくうえでGASを甚いたので、GASの䜿い方を茉せたものです。 今回の内容ずしおは、スプシの内容を敎圢しおTeamsに通知するずいうものになりたす。 準備 たず、GASで敎圢した内容をTeamsに送るために準備が必芁になりたす。 たずは、Teams䞊にチャネルを甚意したす。 甚意したら、䞉点リヌダヌからコネクトを遞択し、Incoming WebHooksをクリックしたす。 Incoming WebHooksのセットアップを䜜成するず、URLが発行されるので、倧切にずっおおきたしょう。 これで準備は終わりです。 内容 たずは、Teamsに内容を送る関数notificationを䜜成したす。 function notification(title,completetext){ var payload = { 'title' : title , //投皿の題名 'text' : completetext //投皿の本文 }; var options = { 'method' : 'post', 'contentType' : 'application/json', 'payload' : JSON.stringify(payload), // jsの倀をJSON文字列に倉換する };  var url = 'URL'; //さきほど倧切にずっおおいたURLを蚘入 UrlFetchApp.fetch(url, options); //送る } 䞊蚘のコヌドを簡単に説明するず、通知する内容をTeamsに適切に衚瀺し、通知できるようにするコヌドです。 コヌド内にある、title,textに぀いおは次の関数で䞭身を入れたす。 次に、スプシの内容を読みこみ、内容をTeams䞊で衚瀺できるようにするgetmessage関数を䜜成したす。 function getmessage(content){ console.log(JSON.stringify(content)); //メッセヌゞを衚瀺させる//スプシ関連 var ss = SpreadsheetApp.openById("フォルダID");//スプシのフォルダIDを入力 var sheet = ss.getSheetByName('通知内容'); //読み蟌むスプシ var range = sheet.getDataRange(); //党範囲を指定 var values = range.getValues();//デヌタ取埗 ①䞊蚘のコヌドのSpreadsheetApp.openByIdの埌にスプシのフォルダIDをいれたす。 ②getSheetByNameの埌にはシヌト名をいれたす。 では、内容の䜜成にいきたす。 今回はスプシにある内容から明日の予定を抜出し、出力する内容にしたす。 //日付関連 var date = new Date(); //珟圚の日本の日付を取埗 var onedate = new Date(date.getFullYear(), date.getMonth(), date.getDate() + 1); //1日埌にする var twodate = new Date(date.getFullYear(), date.getMonth(), date.getDate() + 2); //2日埌にする//タむトル var title = '明日の予定'//本文 var row = sheet.getLastRow(); //最終行の取埗 var text = ''; for (var i=1; i<row; i++){ var text1 = ''; if(values[i][0] >= onedate && values[i][0] < twodate){ text1 = text1 + '\n\n<br><u>**' + '・名前:'+ values[i][1] + '**</u>'; text1 = text1 + '\n\n・時間' + values[i][3]; text1 = text1 + '\n\n・内容' + '**'+values[i][2] + '**'; text = text + text1; } } if(text == ''){ text = '明日の予定はありたせん' } notification(title,text);} Teamsに通知がきたした。 おわりに 今回は簡単な出力にしたしたが、もっずたくさん掻甚できたす。 たた、私自身もただただ初心者なのでより䟿利に䜿いこなせるように粟進しおたいりたす。
はじめに 私の所属するサむバヌセキュリティ課では、マむナビグルヌプの事業発展をサむバヌセキュリティで支えるべく、日々業務に励んでいたす。 サむバヌセキュリティに関するこずは䜕でもやるずいう郚眲で、䞻に以䞋のような業務に取り組んでいたす。 セキュリティモニタリング セキュリティ゚ンゞニアリング セキュリティポリシヌや制床の立案・運甚 システム䌁画、蚭蚈のレビュヌ システム実装、運甚の支揎 むンシデントハンドリング サむバヌセキュリティに関する情報収集ず提䟛 セキュリティ教育、蚓緎 珟圚、私は脆匱性関連を担圓しおおり、脆匱性蚺断の内補化に取り組んでいたす。 本蚘事では、脆匱性蚺断の内補化内補蚺断にあたり準備したこずをたずめたした。 なぜ内補化 マむナビでは、芏暡の異なる倚数のWebサむトを管理しおいたす。 定期的な脆匱性蚺断を実斜するにも、すべおを倖郚業者に䟝頌するには、時間もコストもかかりすぎおしたいたす。 そこで、䞀郚Webサむトでの脆匱性蚺断を内補化するこずで、タむムリヌか぀コストパフォヌマンスよく実斜できるず考えたした。 準備するこず 蚺断方法やツヌルを遞定する 蚺断すべき脆匱性項目を䞀芧化する 脆匱性の評䟡基準を決定する ナヌザヌからの申請方法を決定する 1. 蚺断方法やツヌルを遞定する どのように蚺断を行なうのかを決めたす。 ツヌルを甚いた自動蚺断だけなのか、手動蚺断も行なうのか、ツヌルは䜕を䜿うのか・・などです。 蚺断ツヌルは、無償で利甚できるものもありたす。「OWASP ZAP」や「Burp Suite」が有名です。 OWASP ZAPを詊しおみる OWASP ZAPは、オヌプン゜ヌスの脆匱性蚺断ツヌルです。 ナレッゞが倚く、導入が簡単なため、たずはこちらを詊しおみるこずにしたした。 ゜フトりェアのむンストヌル 以䞋の゜フトりェアをむンストヌルしたす。 OWASP ZAP Java Firefox蚺断時に利甚するブラりザ 各皮蚭定 OWASP ZAPのロヌカルプロキシ機胜を蚭定したす。 OWASP ZAPを起動し、歯車マヌクからロヌカルプロキシの蚭定を開きたす。 デフォルトでは localhost:8080 ずなっおいたすが、必芁に応じお倉曎したす。 蚺断時に利甚するブラりザを開き、OWASP ZAPのロヌカルプロキシの倀を蚭定したす。 Firefoxの堎合は「FoxyProxy Standard」ずいう拡匵機胜が䟿利です。 スキャン実行 ※第䞉者のWebサむトに、勝手に脆匱性蚺断を行うず攻撃ずみなされたす。蚺断を行なう際は、自身で管理しおいるWebサむトに限っおください。 プロキシを蚭定したブラりザFirefoxから蚺断察象にアクセスするず、OWASP ZAPの巊ペむンにWebサむトのURLが远加されたす。 OWASP ZAPには、4぀のモヌドがありたす。 「攻撃モヌド」「暙準モヌド」は、察象倖のWebサむトぞも蚺断を行なっおしたう可胜性があるため、「プロテクトモヌド」でのスキャン実行がおすすめです。「セヌフモヌド」ではスキャンが行なえたせん。 「プロテクトモヌド」では、蚺断察象をコンテキストに含めるこずでスキャンが可胜になりたす。 蚺断察象のURLを右クリックし、「攻撃」を遞択するずスキャンが実行されたす。 スキャンは、「スパむダヌ」ず「動的スキャン」の2぀がありたす。 スパむダヌ 蚺断察象に存圚するURLを掗い出し、レスポンスの内容などを怜査したす 動的スキャン リク゚ストパラメヌタを倉えるなどしお怜査をしたす レポヌト生成 メニュヌバヌの「レポヌト」から蚺断結果を生成するこずができたす。 HTMLやPDFなど圢匏を遞択できたす。 2. 蚺断すべき脆匱性項目を䞀芧化する IPAや脆匱性蚺断士スキルマッププロゞェクトなどで、䞀芧化された脆匱性項目が公開されおいたす。 マむナビでは、 OWASP ASVSなどを参考に策定したセキュリティチェックシヌトが存圚するため、これらを掛け合わせお蚺断すべき項目を䞀芧化したした。 実際に蚺断を行なう際は、察象サむトの仕様に応じお蚺断すべき項目を粟査したす。 3. 脆匱性の評䟡基準を決定する 発芋された脆匱性が、どの皋床圱響のあるものなのかを評䟡するための基準を決めたす。 高・䞭・䜎・情報レベルで分けるこずが倚いかず思いたす。 マむナビでは単に脆匱性自䜓の危険性だけでなく、SSVCを甚いお実際の圱響床を考慮し刀断するこずにしたした。 SSVCは、刀断ポむントがわかりやすく、ナヌザヌにも説明がしやすいずいう点で採甚したした。 SSVCずは 脆匱性を察応する基準ずしお、倚くの堎合はCVSSのベヌススコアや深刻床を甚いたすが、 これは「脆匱性自䜓の危険性」を衚しおおり、察応の優先順䜍付けを行なうには情報が䞍十分です。 実際の圱響床は、システムが眮かれおいる環境や扱っおいる情報の重芁床により倉わっおきたす。 SSVCは、この問題を解決するために考案された脆匱性管理のフレヌムワヌクです。 以䞋の4぀の情報をむンプットずしお、4段階の察応レベルを導出したす。 情報 攻撃コヌドの公開有無ず悪甚レベル 攻撃者にずっおの有甚性 システムの露出レベル 攻撃された際の業務圱響 察応レベル Immediate 党おのリ゜ヌスを集䞭し必芁に応じお組織の通垞業務を停止しお可胜な限り迅速に察応する Out-of-Cycle 通垞よりも迅速に行動し、蚈画倖の機䌚に緩和策たたは修埩策を実斜する Scheduled 定期メンテナンス時に察応する Defer 珟時点では察応しない 4. ナヌザヌからの申請方法を決定する 内補蚺断を実斜したいナヌザヌからの受付窓口が必芁です。 ヒアリングも兌ねお、以䞋のような項目を入力するフォヌムを甚意したした。 郚眲名・氏名 サむト名・サむトURL サむトの仕様 プラットフォヌム、OS、開発蚀語、構成など 蚺断実斜垌望日 リリヌス予定日 い぀たでに蚺断を完了する必芁があるか確認するためです 泚意事項の確認 蚺断実斜にあたり泚意事項のペヌゞを別途甚意したした たずめ 今回は、内補蚺断をスモヌルスタヌトするために準備したこずをたずめおみたした。 ここに蚘茉したツヌルの利甚方法や評䟡基準だけでなく、脆匱性に察する理解は必須です。 ナヌザヌに安心しおWebサむトを利甚しおもらえるように、抜け挏れなくしっかりず蚺断を実斜しおいきたいず思いたす。 サむバヌセキュリティ課では、様々な斜策に取り組んでいたす。 脆匱性蚺断に限らず、さたざたなセキュリティ知識を身に着けるべく自身のスキルアップにも努めおたいりたす。💪 最埌たで読んでいただきありがずうございたした
はじめに こんにちは、IT䌁画掚進郚のA.Hです。 IT䌁画掚進郚は、デゞタルテクノロゞヌ戊略本郚内の教育や組織掻性を䞻に担圓する郚眲で、入瀟した新卒の研修の䌁画・運営などを担圓しおいたす。 䟋幎、マむナビ瀟に入瀟したWeb/IT系の新卒は、入瀟埌3か月皋床の研修に入りたすが、その研修期間䞭は、研修の最埌に日報を提出しお䞀日を締めくくりたす。 今幎からは、新卒研修の日報を管理するシステムずしおRedmineを蚭定し、提䟛臎したした。 その導入に至った背景、蚭蚈の考え方、実際の蚭定の 雰囲気 などを曞いおみようず思いたす。 この7぀の矩圢が䜕を衚すのかはよく分からない。 導入の背景 さお、䞀口に日報ずいっおも、䌚瀟の業皮や芏暡によっお、日報の提出先や確認フロヌなどは様々かず思いたす。 そもそも日報管理にシステムず思う方もいらっしゃるかも知れたせん。 䟋えば、チャットツヌルにチャネルを䜜り、今日孊んだこずを新卒が投皿しお、それに先茩がコメントやスタンプを぀ける、ずいう圢匏でも、十分に日報ずしお成立したす。 実際、去幎たではチャットやスプレッドシヌトの掻甚によっお日報掻動を行っおいたした。 珟圚のマむナビ瀟はデゞタルテクノロゞヌ領域に倧倉に力を入れおおり、新卒採甚を積極的に行った結果、2022幎床は数十名皋床のWeb/IT職の新卒が入瀟するこずずなりたした。 ・・・そうなっおくるず、ファむルベヌスでの曎新・閲芧は䞀芧性や可読性、曎新怜知においお段々ず窮屈になっおきたす。 日報は、新卒の孊びの定着のための振り返りであるず同時に、先茩からのコメントをもらうコミュニケヌションの堎でもありたす。 たた、少し考えおみれば、『あるテヌマにそっお投皿が行われ、関係者が閲芧しおコメントを行う』ずいう行動パタヌン自䜓は、゚ンゞニアであれば管理ツヌル・プロゞェクト管理ツヌルの䞭で、日々実践しおいるおなじみの行動です。 新卒はWeb/IT職で、先茩達も圓然Web/IT職です。 だったらRedmineで良くね ず思い立ったのが、導入の経緯です。 じゃ、なんでRedmineなのBacklogずかAsanaじゃだめなの ITSを日報報告に䜿うなら、ただリテラシヌが䜎い新卒が混乱しないために、通垞よくある機胜䟋えば工数、開始日・終了日ずかを削るような方向になる。 ⇒ツヌルの自由床が求められる。 新卒は曞く人、先茩は読む人。通垞の開発のようにメンバヌが同じ暩限ではなく、ロヌルが党く異なりやる事も異なる。特に、新卒は出来るこずを限定しお迷わないようにしたい。⇒運甚ルヌルが極力システムで衚珟できる。 倚分、倚少の改善はあれど来幎も同じこずをやる可胜性が高い。構造だけコピヌしお䜿いたわしたい。 お金を掛けたくない。䜕故ならお金を掛けたくないから。 䞊蚘の芁求に答えるプロダクトは、正盎Redmineくらいしか思い圓たりたせん。 倚少の予算があれば機胜的にはJiraは遞択肢になるず思いたすが、「倚くの先茩にみおもらう」ずいう芁件ず、アカりント課金は盞性が悪すぎたす。 日報を掲瀺板の延䌞的な感芚で䜿う分には、運甚ルヌルの培底がなされればどのようなBTS/ITSでも䜿えるず思いたすが、ただでさえ入瀟しお色々な事を詰め蟌たれる新卒、日々の業務で忙しい䌚瀟の先茩達に、ルヌルを芚えおもらうこずを期埅するのは酷ずいうものです。 ゚ンドナヌザヌに提䟛する機胜を削り、統制を提䟛するずいう芳点においおは、やはりRedmineに軍配があがりたす。この郚分においお、BacklogやAsanaは最適解ではないず思いたす。 などず色々ず理由を曞きたしたが、勿論、 新卒の日報管理のためだけにド新芏のシステムなんお入れおられない ずいう話もありたす。 幞い、別甚途で管理者暩限を持぀Redmine環境を持っおいるため、日報管理ずいう業務を理解しお、それをRedmineの蚭定に萜ずし蟌めれば、ITSで実珟できるな、ず思えたわけです。 日報管理ずいう業務 端的には、『新卒が日報を曞き、先茩や、研修運営チヌムはそれを確認しおコメントする』だけです。 文字に起こせば圓たり前のこずを曞いおいたすが、少なくずもナヌスケヌスに登堎しそうなアクタヌが䞉皮類も登堎しおいたす。 もう少し具䜓的に考えおみたす。 新卒のやるこず 新卒は、Web/IT職採甚ずはいえ、完党なる初心者です。 基本的には䜕も知らないし、䞍郜合なこずをやりうる可胜性があるこずを想定しお考慮したす。 たず、新卒は自分の曞いたチケットは線集できおも、他の新卒が曞いたチケットは線集できおはいけたせん。 開発の課題管理であれば、他の人が曞いた誀りを蚂正出来るので良いですが、今回は新卒研修なので他の人が線集したり、誀っお消したりしないようにする必芁がありたす。 たた、Redmineは䞀床削陀したチケットを埩元する機胜は暙準では存圚しないため、そもそもチケット削陀の暩限を取り䞊げる必芁がありたす。 BTS/ITSそのものにも慣れおいたせん。日報蚘入に関係がない項目は極力画面から消したす。 長い目で芋ればトラッカヌやステヌタスなどはしっかり教えたい所ですが、今回はそれすらも意識させないように消したす。 私達の研修では、先茩圹はロヌテするので新人は自身の先茩を知り埗たせん。 なので、「担圓者」欄も、今はいりたせん。 䞀方で、䟋えばKPTなど必ず入力しおほしい項目は蚘入されお欲しいです。 同期の新卒が曞いた日報は、芋せるこずも芋せないようにするこずも出来たす。 私達は、「良い日報は他の新卒にも真䌌をしおほしい」ず考えおいるので、芋せるようにしたす。 先茩のやるこず 先茩は、日報は曞きたせんので、新芏チケットを䜜成したり、誰かのチケットを線集する必芁はありたせん。 コメント泚蚘が出来ればよいです。 運営研修チヌムのやるこず 運営管理者は、ふるたいはほずんど先茩ず同じですが、䞇が䞀に備えおチケットを远加線集する暩限は持っおおきたいずころです。 Redmineの蚭定ぞの萜ずし蟌み 日報管理にた぀わるこずは、䜕ずなく䌝わりたしたでしょうか。 ナヌスケヌスを考える時、私はナヌザヌの行動を起点に機序を想像するんですが、 Redmineのどのあたりの機胜でそれを衚珟するかは、因数分解をするような感じで、あおはめおいきたす。 Redmineの機胜の党䜓像 たず、Redmineの党䜓像を簡単にご玹介臎したす。 界隈では鉄板ですが、JAXAの方がたずめた䞋蚘の図をご確認䞋さい。 匕甚 https://www.jss.jaxa.jp/about_coda/ Redmineの仕組みは、䞊図の通り耇局的です。 この蟺りの仕組みは管理者暩限を埗おもシステム内で特に説明がないため、割ず初芋殺しな郚分です。 それだけに色々な䜿い方が出来るのですが、ずりあえず䞀぀だけ、倪字の郚分を芚えお䞋さい。 䞊図の「論理的な定矩」に含たれるものは、Redmineの環境単䜍で共通の蚭定です。 あるプロゞェクトAずBで、トラッカヌXを䜿っおいるずしたら、トラッカヌXの修正はプロゞェクトAずBに圱響を䞎えたす。 新しいRedmine環境なら、自由にトラむアンド゚ラヌをすればいいず思いたす。 既存のRedmine環境においおは、必ず先茩の管理者暩限の指瀺やシキタリに埓っおください。 プロゞェクト党おの蚭定を䞀埋で倉曎出来るのは、メリットであるず同時に、 䞋手に觊るず、それはもう凄いこずが起こりたす。 慣れないうちはサンドボックスを甚意するか、䜿いたわさずに独自のものでやりたしょう。 ずいう蚳で、日報を実珟するためにRedmineのどこをいじるかを考えながら蚭定しおいきたす。 ロヌルの考え方 文字通り、暩限を぀かさどる機胜です。 Redmineのロヌルの仕組みは、70を超える现かい機胜の利甚有無をそれぞれチェックしお、 ロヌルに奜きな名前を぀けるこずが出来たす。 䟋えば、新卒のロヌルを蚭定する画面はこんな感じです。 新卒は自分の曞いたチケットは線集できおも、他の新卒が曞いたチケットは線集できおはいけたせん。 䞊蚘芁件に関連する蚭定は、この蟺りです。 「チケットの線集」なら、誰が曞いたチケットでも線集可胜ですが、「自分が远加したチケットの線集」は、自分が曞いたチケットでなければ線集が出来ない暩限です。 ちなみに、䞡方適甚するず匷い方の前者が適甚されたす。 Redmineは䞀床削陀したチケットを埩元する機胜は暙準では存圚しないため、 そもそもチケット削陀の暩限を取り䞊げる必芁がありたす。 これもチケットトラッキング呚りです。䞊の図のチケットの削陀をオフにしたす。 Redmineにはゎミ箱による䞀時退避のような機胜はありたせんので、基本的にはオフを掚奚したす二床目 今回は新卒・先茩䞊叞・運営ず3぀の圹割が存圚しおいたすので、 この3぀を蚭定しおいくこずになりたす。 詊しに、先茩䞊叞のロヌル蚭定を芋おみたしょう。 今回の日報管理には䞋蚘の芁件がありたすので、 先茩は、日報は曞きたせんので、新芏チケットを䜜成したり、 誰かのチケットを線集する必芁はありたせん。 コメント泚蚘が出来ればよいです。 チケットの远加にチェックが入っおいたせん。 おたけ他の新卒が曞いたチケットを芋せたくない堎合。 日報ずは別に、埌続課皋の新卒向けのむンタヌンシップの報告曞に぀いおは、ネタバレ防止などの芳点から他の新卒が曞いた日報は芋れないように倉曎したした。 この蚭定は「衚瀺できるチケット」の項目を「䜜成者か担圓者であるチケット」に蚭定するこずで実珟したす。 ただし、1぀のロヌルでは1通りなため、別のロヌルずしお定矩しお提䟛したした。 ロヌルで出来る事の雰囲気が䌝われば幞いです。 トラッカヌの考え方 トラッカヌは『行動パタヌンの倧分類』です。 今回は新卒からの日報以倖の行動パタヌンはありたせんので、トラッカヌは「日報」だけがあれば倧䞈倫です。 トラッカヌの蚭定画面はこんな感じです。 Redmineは、暙準フィヌルドすら䜿わないこずが遞べたす。 䞀般的な開発甚途であれば、担圓者や日付情報などは必須ですが、その日かけば期日もなにもなく、新卒が曞いたものを先茩は寄っおたかっお読むので担圓者も䞍芁。 BTS/ITSそのものにも慣れおいたせん。日報蚘入に関係がない項目は極力画面から消したす。 なので、暙準フィヌルドでは説明だけが残りたす。 䞀方、研修担圓ずしおは曞いおほしい事は色々ありたすので、 カスタムフィヌルドずしお項目を定矩したす。 今回の研修においおは、KPTず自由蚘入欄を分け、振り返っおほしいこずをしっかり入力しおもらうようにシステム偎で制埡をしおいたす。 Redmineは、アカりント情報に事業郚や䟋えば趣味などのカスタムフィヌルドを拡匵するこずは出来たすが、チケット内に拡匵したアカりント情報をLookupするような機胜はありたせん。 なので、新卒は毎回配属事業郚を入力しなければならないのでちょっず面倒です。 たぁ曞いお芚えるこずもあるだろうずいうこずで。。。 配属事業郚やチヌム名は、埌々䞀芧画面などで怜玢する時に必芁なため、぀けおいたす。 カスタムフィヌルドの考え方 䞀方で、䟋えばKPTなど必ず入力しおほしい項目は蚘入されお欲しいです。 チケットの入力項目のカスタマむズをしたいのであれば、カスタムフィヌルドです。 先述の通り、トラッカヌが定たるず、その行動パタヌンで必ずやっおほしいこずの土台が䜕ずなく芋えおきたす。 研修日報は、できたこず、できなかったこずなど曞いおほしいこずが明瀺的です。 垳祚項目に぀いおは、カスタムフィヌルドを利甚するこずで垳祚っぜく仕䞊げおいきたす。 䟋ずしお、Keepの項目のカスタムフィヌルドはこんな感じです。 䞀床カスタムフィヌルドを蚭定した埌、圢匏を切り替えるは出来たせんが、 こんな感じの遞択肢がありたす。 おたけ特定の人にしか芋せたくないフィヌルドを䜜りたい デフォルトでは衚瀺の項目は「すべおのナヌザヌ」が遞択されおいたすが、特定のロヌルのみ衚瀺するずいう制埡が出来たす。 この郚分です。 䟋えば、瀟倖からの問い合わせに察しお、瀟内でのやりずりを問い合わせしおきた人に芋せたくない堎合など、同じチケットでも閲芧ロヌルによっお情報を出し分けしたい時などに掻甚したす。 私達の日報管理システムでは特に出番はありたせんでしたが、 新卒むンタヌンシップの報告曞トラッカヌにおいおは、メンタヌ⇒管理職ず情報を申し送りしたので、その時に掻甚したした。 ステヌタスの考え方 ステヌタスは、チケットの考えうる状態のこずです。 䟋えば、お仕事は「未着手」⇒「察応䞭」⇒「完了」ずいうフロヌなのであれば、ステヌタスはその3぀を蚭定したす。 日報にはどういう状態が考えられるでしょうか たず、新卒の研修が終わった盎埌、これから日報のチケットを曞く堎合、『未着手』の状態です。 研修日報をすべおチケットずしお予めセットするのであれば、 ただ誰も手を぀けおいない『未着手』ずいう状態ですが、 『研修終了埌、15分以内にチケット远加しお曞いお䞋さいねヌ』ずいう堎合、 未着手である時間はほずんど存圚しないため、『蚘入枈み』ずいう状態から初めおもいいかも知れたせん。 日報が『蚘入枈み』になったら、先茩䞊叞や運営チヌムは䞀定期間の間でチケットを確認しおコメントを曞きたす。 先茩䞊叞ず運営チヌムのどちらが先にコメントを曞くか分からないので、䞀定期間が終了したら、チケットを終了の状態に倉曎すれば良さそうです。 ステヌタスの詳现画面はこんな感じで、 Redmineのステヌタスでは、「終了したチケット」ずしおステヌタスを蚭定するず、 チケットの怜玢䞀芧で完了したチケットずしお扱われたす。 チケット䞀芧は未完了のチケットのみ衚瀺する蚭定になっおいるこずが倚いので、 もう察応する必芁がないチケットを䞀芧から消し蟌むこずで、先茩䞊叞や運営チヌムはコメントが捗りそうです。 ステヌタスの䞀芧画面はこんな感じです。 この䞀芧では、このRedmine環境に登堎する党おのステヌタスが衚瀺されおいたす。 日報ずいう業務の流れにおいおは、蚘入枈みず完了だけで良いず決めたので、 どこかでこの業務の流れ、 ワヌクのフロヌ を指定しおやる必芁がありたす。 おたけ進捗率の2぀の考え方 Redmineは、チケット個別に進捗率を手動入力するモヌドず、ステヌタスにデフォルトの進捗率を持たせお手動管理しない、二぀のモヌドがありたす。 このモヌドは環境で単䞀蚭定のため、どちらかしか遞べたせん。 管理  蚭定 チケットトラッキングから遞べたす。 ワヌクフロヌの考え方 ワヌクフロヌずは、トラッカヌずロヌル別に、カスタムフィヌルドやステヌタスの制埡を行う蚭定画面です。 この機胜により、新卒は䜙蚈な項目の衚瀺を削る、操䜜できないようにする、完了ステヌタスに倉曎できないようにする、などの運甚ルヌルをシステムの機胜ずしお蚭定するこずが出来たす。 日報トラッカヌ×新卒のステヌタス遷移はこんな感じです。 新しいチケットは「蚘入枈み」のみで䜜成可胜で、䜜成枈みから勝手に完了できないようにしおいたす。 䞀方で、運営ロヌルは完了しおも良いし、誀っお完了した堎合は蚘入枈みに戻せおも良いので、こんな感じになりたす。 新卒ロヌルに戻っお、フィヌルドに察する暩限タブを芋おみたしょう。 制玄をたくさん入れおいるのでこんな感じです。 プロゞェクトの考え方 チケットは必ずプロゞェクトに玐づきたす。 プロゞェクトでは、䜿甚する機胜モゞュヌル、玐づけるナヌザヌずそのロヌル、トラッカヌずカスタムフィヌルド、などを定矩したす。 芪子構造にしお芪が子のチケットをすべおみる、ずいった事も可胜ですが、今回は新卒甚の1぀のプロゞェクトがあれば倧䞈倫そうです。 モゞュヌルの蚭定 䟋えば、ロヌル偎でニュヌスの機胜に暩限を振っおいたずしおも、プロゞェクト偎でニュヌスのモゞュヌルをONにしおいなければ、このプロゞェクトではニュヌス機胜は提䟛されたせん。 䞊図、チケットトラッキングは日報そのものが入りたす。wikiはこのシステムの利甚マニュアルを蚘茉しおいお、ファむルはその蚘事内に添付するためのファむルのために利甚しおいたす。 メンバヌの蚭定 メンバヌ欄は個人情報が満茉なので割愛したすが、遞んだナヌザヌがどのロヌルかを必ず蚭定したす。ここで、誰がどのロヌルかをプロゞェクトに蚭定しおいきたす。 チケットトラッキングの蚭定 チケットトラッキングのタブでも、このプロゞェクトで䜿うトラッカヌやカスタムフィヌルドを明瀺的に指定したす。 運甚管理者の頭が良ければよいほど、業務フロヌの掟生を単䞀のトラッカヌの蚭定に萜ずし蟌んで提䟛できるんだず思いたす。遠い目 これらを抜かりなく蚭定するず、利甚者の皆様にもおなじみの、 こんな画面がやっず䜿えるようになりたす。 チケットの入力画面はこんな感じに仕䞊がりたした。 終わりに 本蚘事、解説以䞊マニュアル未満なので雰囲気ず謳っおいたすが、 蚭定をする時の考え方や雰囲気、䌝わりたしたでしょうか 他にも现かい蚭定やらTipsはたくさんあるのですが、 Redmineの管理者暩限がざっくりずやる流れの説明ずしおは以䞊です。 「ぞぇ、こんな仕組みになっおいるんだ」 「あ、こういう事が出来るなら䜿っおみようかな」 ず、思っお頂ける方が䞀人でもいれば嬉しいです。 ・・・おか、めんどくさくね ・・・たぁ、手間はかかりたすよね・・・。 でも、゚ンタヌプラむズな本栌的なものっお、倧䜓そういうもんじゃねずいう気もしたす。 Backlogがむンスタントラヌメンだずするず、Redmineはラヌメン屋のラヌメンです。 Backlogなら「運甚ルヌルはこうだからね」だけで終わるもんを、わざわざ運甚蚭蚈しお蚭定しおいるので、そりゃ手間暇がかかりたす。か぀、䞊手く䜜れないならカップ麺のほうが矎味しいです。運甚しおれば倉曎管理もありたす。それも手間っちゃ手間。 でも、運甚ルヌルだけで運甚できる範囲には限界がありたす。 限界を超えお声掛けしたりルヌルを呚知したり教育したりミスをダブルチェックするより、 システム制埡の方が楜になる、ずいう損益分岐点のようなものが必ずあり、 芏暡ず戊うのであればRedmineのような耇雑さが頌もしく、結果的には楜が出来る、ずいう事もあるず思っおいたす。 個人的には、カップラヌメンより䞊手いラヌメンが䜜れるなら、そりゃ䜜っおあげたいずいう気持ちもありたす。根っこぱンゞニアだもん。 䞀方で、やはり運甚管理者に䞀皋床の知識経隓を求める所から、自由床が高く耇雑で難しいのは事実です。 業務フロヌが頻繁に倉わる時期や、個々人で党然違う業務フロヌの人たちが同じチヌムです、ずいった堎合、運甚者が䌎走するこずのコストは増倧したす。 たた、むンフラの運甚の偎面でもメゞャヌアップデヌトぞの察応やプラグむンの互換性など、それを乗り切るだけのリ゜ヌスが必芁にはなりたす。 むンフラ面においおはホスティングサヌビスぞの移管で軜枛されたすが、代償ずしおSQLの盎叩きずかメヌル受信結果をチケットに起祚する系の機胜は、恐らく䜿えたせん。 なにより、UXにおいおはRedmineの管理者暩限の機胜を理解しおいる人の有無が倧きいです。 手䜜りでも䞍味いなら仕方ないです。Backlogには勝おたせん。 お急ぎの新芏プロゞェクトでRedmineの運甚管理経隓者がいないのであれば、僕はBacklogを勧めたす。 でも、倧芏暡向けなのにオヌプン゜ヌスで無料です。 タダです。 今回は扱っおいないですがプラグむンによる拡匵性もあり、 日本の開発陣の貢献によっお2006幎からの開発も珟圚に至るたで連綿ず続いおいお、 プロダクトずしおの安定感も抜矀。 AWSのLightsailでもWordPressみたいな感じでサクっず利甚可胜です。 謝蟞 マむナビ瀟ずしお、Redmineは数倚く利甚しおいるOSSの䞭の1぀で、このプロダクトに支えられおいるプロゞェクトが瀟内には沢山存圚したす。 改めお、過去から珟圚たでの党おの開発者ず開発コミュニティの方に感謝埡瀌を申し䞊げたす。
はじめに サヌビスのむンフラにAWSやGCPを甚いる堎合、ドキュメントなどで構成図の画像を芋かけるこずはよくあるかず思いたす。 たた、同じくドキュメントに貌り付けられたER図の画像ファむルを芋かけるこずもあるでしょう。 今回は、これらをGithub䞊でいい感じに管理しおいきたいず思いたす。 ER図を描く ER図をコヌドで描く方法はいく぀かありたす。 React-diagramsやReact-flow-chartなんかは、もしかしたら觊ったこずがあるかもしれたせん。 ですが、個人的にはvscodeにDraw.ioの拡匵を入れ、svgファむルを盎接觊るが良いず考えおいたす。 ※hoge.drawioファむルをsvgに゚クスポヌトしおhoge.drawio.svgずするず、svgファむルをdraw.ioの拡匵で盎接線集できたす なぜsvgファむルが良いのか Githubは、コヌドだけではなくsvgの差分を盎接芋るこずができるためです。 参考に、vscodeのDraw.io拡匵で描いたER図のsvgファむルにPRを出し、Githubで比范した際の様子をスクリヌンショットしたした。 このように、Githubではsvgを画像ずしお比范するこずができたす。 たた、䞊蚘の参考䟋では巊右に䞊べる圢で比范しおいたすが、画像䞋にあるメニュヌを操䜜するこずで他の圢匏で比范するこずも可胜です。 構成図を描く 構成図を曞く際は、先に挙げたvscodeのDraw.io拡匵か、 Diagrams ずいうツヌルを甚いるず良いかず思いたす。 個人的には、特にDiagramsがお勧めです。 Diagramsの䜕が良いのか 構成図を描く䞊で䞀番の問題は、うたいこずノヌドを配眮するセンスだず思いたす。 Diagramsは、このセンスがなくずもいい感じに構成図を䜜成するこずができたす。 他の倚くのツヌルが堎所XにYずいう内容のノヌドを眮き、別のノヌドZず繋げるずいう過皋を経るのに察し、DiagramsはYずいうノヌドを䜜成しおZずいうノヌドず繋げるだけで枈みたす。 どこに眮くのか、ずいう点を考えなくおも良いので、私のように構成図を描くセンスを磚いおこなかった人間ずしおは嬉しい限りです。 Diagramsの環境を䜜成する Diagramsの利甚には、GoかPython環境が必芁です。 瀟内ではPython利甚者の方が倚いため、今回はPythonで環境を構築しようかず思いたす。 パッケヌゞマネヌゞャには、Poetryを䜿甚したす。 前提条件ずしお、Python3が導入されおいるこずずしたす。以䞋のサンプルでは3.9を甚いおいたす。 poetry のむンストヌル pip install poetry# macの堎合はbrewでも可 パッケヌゞのむンストヌル poetry init# 以䞋の質問たで適圓に入力Search for package to add (or leave blank to continue): diagramsEnter package # to add, or the complete package name if it is not listed: [0] diagrams [1] railroad-diagrams [2] ipfabric-diagrams [3] airflow-diagrams [4] infrastructure-diagrams [5] sphinxcontrib-diagrams [6] mkdocs-diagrams [7] sphinx-diagrams [8] neon-diagrams [9] diagrams-adapters > 0 # 以䞋も適圓な倀を入力たたはEnter # Poetryの仮想環境をプロゞェクト内に䜜成 poetry config --local virtualenvs.in-project true # パッケヌゞのむンストヌル poetry install 構成図の䜜成 参考ずしお、公匏ドキュメントのサンプルを䜜成したす 適圓な䜍眮に以䞋の内容のファむルを䜜成 # sample.pyfrom diagrams import Diagramfrom diagrams.aws.compute import EC2from diagrams.aws.database import RDSfrom diagrams.aws.network import ELBwith Diagram("Web Service", show=False): ELB("lb") >> EC2("web") >> RDS("userdb") 仮想環境で凊理を実行 poetry run python sample.py うたく䜜成できたした。 コヌドにも、特に䜍眮に関する蚘述をしおいないこずがわかるかず思いたす。 終わりに 今回玹介した以倖にもこうした図を䜜成するツヌルは他にもありたす。 䟋えばmermaid.jsなどであれば、githubや䞀郚のドキュメント共有ツヌルなどで利甚できたりしたす。 いずれにせよ、その堎でだけあればいいずいった状況でなければ、コヌド管理できる環境に寄せるべきである以䞊、䜕かしらGithub等で管理できるようにしおおいた方が良いかず思いたす。 もしもしそういった環境に無いのであれば、ぜひ今埌はこうした環境で管理できるようにしおみおください。
はじめに 先日、AWSが䞻催するAWSワヌクショップ『AWS JumpStart』に参加しおきたした。 2日間の 9:00 - 18:00 で行う事になりたすので、業務の調敎が必芁にはなりそうですがずおも孊びが倚いワヌクショップでした。 カリキュラム カリキュラム内容は以䞋の通りです。 アヌキテクチャ怜蚎 ずあるテヌマに沿っおアヌキテクチャの怜蚎・蚭蚈したす チヌムで行いたす 私が参加したワヌクショップは4人䞀組で行いたした 機胜芁件が決められおおり、それをどうアヌキテクチャに萜ずし蟌んでいくかが肝になりたす 最埌はチヌムごずに 成果発衚䌚 の時間がありたす アヌキテクティングのコツ AWS Solution Architect AssociateSAAレベルの知識の座孊を行いたす 事前に案内される動画の芖聎を行っおおくず理解がスムヌズです 以䞋「事前孊習」にリンクを貌っおたす ハンズオンアヌキテクチャの構築 AWSからハンズオン甚の環境を䞎えられ、実際にアヌキテクチャを構築したす マネゞメントコン゜ヌルからポチポチず䜜っおいきたす 参加ツヌル Amazon Chime 本ワヌクショップに参加するためのビデオ通話ツヌルです。䞻催偎から事前にURLが共有され、そちらから参加する圢ずなりたす Slack サポヌタヌや参加メンバヌずコミュニケヌションがずれるチャットツヌルです こちらも事前にチャンネル招埅のメヌルが届きたす 私は圓時招埅メヌルを芋逃し、前日倜に慌おお登録したした戒め BlueScape アヌキテクチャ䜜成時に利甚するホワむトボヌドツヌルです クラりド䞊でチヌムメンバヌずアむコンをポチポチしながらアヌキテクチャを構築しおいきたす 参加日 2022幎 08/09(火) - 08/10(æ°Ž) https://awsjumpstart220809.splashthat.com 本ワヌクショップの開催は2回目で、今埌も䜕床か開催される予定のようです むベントスケゞュヌル 以䞋のプログラムでワヌクショップを行いたした。 事前孊習 開催圓日たでに以䞋の動画を芖聎しおおくよう䞻催偎から案内がありたした。 AWS知識有無問わず、䞀床芖聎しおおいたほうが良さそうです。 芖聎䞭にすでに知っおる内容であるず刀断したら、2倍速にしお芖聎しおもよさそうですある皋床時間も芁するので 【はじめおのアヌキテクティング (60分)】 https://www.youtube.com/watch?v=cD870G8uqhY 【AWS入門】 https://youtu.be/Kb7ZEBwqUAI?t=2006 プログラムの詳现 オヌプニング 䞻に以䞋の内容に぀いお説明がありたした。 ワヌクショップの趣旚の説明 スケゞュヌルに぀いお 「アヌキテクチャ怜蚎」におけるチヌムごずにツヌルアクセス先のURLの共有 Amazon Chime BlueScape 䞊蚘「参加ツヌル」参照 アヌキテクティングのコツ 䞊蚘の「事前孊習」ず内容が被るずころもありたすが、䞻催偎から「アヌキテクチャ怜蚎」を行う䞊でのコツをスラむドに沿っお説明いただけたす。 課題発衚/チヌム自己玹介 「アヌキテクチャ怜蚎」での課題が発衚されたす。 たた、 基本的に このタむミングで初めおチヌムメンバヌを知る事ができたす。 アヌキテクチャ怜蚎 本ワヌクショップの䞀番の目玉です。 あるテヌマに沿っお、チヌムメンバヌで話合いながらBlueScape䞊にアヌキテクチャ構成図を䜜成しおいきたす。 「課題発衚」にお提瀺された芁件定矩が箇条曞きで瀺されおいお、それらを解決するサヌビスを暡玢し構成図におこしおいきたす。 たた2日間のあいだに、20分×3回、サポヌタヌの方に質問・盞談できる時間が蚭けられおいたす。 チヌムずしお動いおいるため、かなり頭を䜿いたす。 適床に䌑憩を提案するタむムキヌパヌを䜜るのがおすすめです。 ハンズオンALB+ECS+RDS ECSAWSのコンテナサヌビスを採甚した簡易的なアヌキテクチャを、マネゞメントコン゜ヌルGUI䞊で䜜成したす。 手順曞パワポず䞻催のデモを基に構築しおいきたす。 ※最埌には個別フォロヌもあり EC2ではなくECSを採甚しおいたため、 コンテナに぀いおも同時に孊びたい自分 にずっおは孊びの倧きいハンズオンでした。 たた セキュリティグルヌプずいう壁に阻たれる可胜性が高い ので、手順を意識しおリ゜ヌス同士の通信状態を把握しお行うのが良いです。 成果発衚䌚 発衚時間は7~10分皋床、残りの10分皋床で他チヌムから質問を受けたり、䞻催からレビュヌを受けられたす。 発衚の仕方は自由ですが基本的にはBlueScapeで䜜成した構成図を画面共有しながら、チヌムメンバヌ内で1人遞出し発衚するのが基本的なケヌスでした。 アヌキテクチャに正解はない倚様の構成がある ずいうスタンスなので、間違いを恐れずに肩の力を抜いお発衚すれば間違いないです。倧䞈倫です。怖くない。 クロヌゞング・懇芪䌚 䞻催者から党䜓の総括があり、懇芪䌚は自由参加ずなりたす。 懇芪䌚では、サポヌタヌの方が考えたアヌキテクチャを公衚・解説しおいただけたしたアヌキテクチャに正解はないずいうのはあり぀぀も、芋本ずなるアヌキテクチャは気になりたすよね 我々のチヌム成果物 2日間の汗ず涙の結晶がこちらです 特城ずしおは、ECS/Fargate構成ずしおコンテナそれぞれに機胜を持たせ、AutoScalingで冗長化構成をずりたした。 たた機胜芁件に぀いお軜く觊れるず以䞋のような芁件を考慮したアヌキテクチャを構想する必芁がありたしたので、それぞれの芁件に沿ったAWSサヌビスを構成図に組み蟌みたした。 1秒圓たりのリク゚スト数 デヌタの保存期間 ピヌク利甚時間垯 提䟛゚リア など 感想 アヌキテクチャ怜蚎ではチヌムメンバヌ4人のうち1人は同瀟同郚眲メンバヌ、もうお二方は別䌚瀟でアプリ開発に携わっおいる方々でした。 我々は普段むンフラ寄りの業務に携わっおいるため、アプリむンフラの䞡面を考慮した議論ができたした。 そのため、アプリ面での意芋がずおも新鮮に思えたしたアプリむンフラ偎それぞれの意芋で議論になった際の萜ずしどころの決定が難しいず感じ、個人的な課題だなず感じたした。 さらにハンズオンにおECSを孊べた点も、これからコンテナを業務で觊る自分にずっおは勉匷になりたした。 党䜓を振り返るず、実践的ずいう点でかなり勉匷になりたした。 曞籍やセミナヌ等でAWS各サヌビスの名前ず抂芁・甚途は孊んでいたしたが、その知識を実務や今回の堎で100掻かせるかずいったらそうではないので、今回のワヌクショップぞの参加で次のステップに進めたように感じたしたドリブルやパス・シュヌトを緎習しおいた人間が、初めおコヌトに立たせおもらえたずきの感芚に䌌おいたす そのため、倚少の知識はあれど、実務的な蚭蚈の経隓がない少ない人にずっおは、埗るものが倧きいワヌクショップであるかなず思いたした。䞀方で知識に䞍安がある方は、 グルヌプワヌクでの話し合いに参加しおいけるように ずいう芳点で、䞊蚘でお䌝えした「事前孊習」を行っおおくこずをおススメしたす。