Colorful Bullet 2023-02-22T16:00:00+09:00 bulletgroup Hatena::Blog hatenablog://blog/17680117127000844097 新卒エンジニアがフルリモートで感じた不安と解消法 hatenablog://entry/4207112889964774154 2023-02-22T16:00:00+09:00 2023-02-22T16:00:02+09:00 皆さん初めまして、コーポレートIT室(CIT室)の y-niki です。 今年の4月で入社してからちょうど 2 年になります。 今回は新卒入社のスタートから 2 年間フルリモートで働いてきて、当初感じた不安や悩み、またそれをどう解消してきたかをご紹介したいと思います。 ここ数年は、コロナが広がった影響でリモートワークする機会が増えた方も少なくないと思いますので、自分と同じような悩みを持つ方や、これからリモートワークを考えている方などの力に少しでもなれたらな嬉しいです。 質問への不安 働き始めですぐに質問への不安を抱えることになりました! 質問することに対して不安を覚えるのは新卒あるあるだと思う… <p>皆さん初めまして、コーポレートIT室(CIT室)の y-niki です。 今年の4月で入社してからちょうど 2 年になります。</p> <p>今回は新卒入社のスタートから 2 年間フルリモートで働いてきて、当初感じた不安や悩み、またそれをどう解消してきたかをご紹介したいと思います。</p> <p>ここ数年は、コロナが広がった影響でリモートワークする機会が増えた方も少なくないと思いますので、自分と同じような悩みを持つ方や、これからリモートワークを考えている方などの力に少しでもなれたらな嬉しいです。</p> <h3 id="質問への不安">質問への不安</h3> <p><figure class="figure-image figure-image-fotolife" title="不安"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/y/y-niki/20230222/20230222151752.png" width="328" height="400" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></figure> 働き始めですぐに質問への不安を抱えることになりました! 質問することに対して不安を覚えるのは新卒あるあるだと思うのですがリモートだと余計に大変だなと感じました。</p> <p>例えば、メッセージを送信後に返事がくるまで他のことをしていれば良いのですが、自分は文章を確認しては編集するを繰り返し、気づいたら作業が進んでいないということがありました。</p> <p>リモートだと相手から自分が何に困っているのか把握しにくかったりするので、困ったら 1 人で悩まずに直ぐに相談することが大事です! 自分も先輩に相談して下記の記事を紹介していただきました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.jnito.com%2Fentry%2F2020%2F04%2F17%2F072343" title="【初心者ITエンジニア向け】上手な質問は「相手にエスパーさせない質問」です - give IT a try" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.jnito.com/entry/2020/04/17/072343">blog.jnito.com</a></cite></p> <p>他にも新卒で入社してからのメンタルを保つための記事も置いておきます</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fkensuu.com%2Fn%2Fn0d93853b546d" title="新卒で入社したときの最初のつらさをくぐり抜ける考え方|けんすう" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://kensuu.com/n/n0d93853b546d">kensuu.com</a></cite></p> <p>TDに所属していた頃から、雑談用の Discord が用意されていたのでチームが集まって会話することもあり、気軽に質問できる場所があることで質問することの不安は解消され、とても助かりました。</p> <h3 id="雑談のしにくさ">雑談のしにくさ</h3> <p>リモートだと集中して業務を行っているといつの間にか就業時間になって誰とも会話をしなかった時がありました。</p> <p>そんな日々を過ごしている中、1 年目の秋頃から毎週 15 分間上長と1on1 を行うようになりました。 1on1 の時間は普段改まって質問するまでもないことについて聞いたり、雑談したり、いろんな主題で会話できるので自分はすごいありがたかったです。(話が広がって時間が伸びることもしばしば、、、)</p> <p>1on1 以外にも毎日進捗の共有をする場を設けることで困っている人に対してチーム全体で手助けする事が出来る環境を作ったりと、自分のいるチームではリモートで仕事を行うための工夫をいろいろと行っています。</p> <p>リモートワークを行う、行う予定のチームでコミュニケーションを改善したいなどある方は、今回話した 1on1 や Discord での通話などを導入した上長が書いた記事があるので参考にしてもらえればと思います。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2021%2F12%2F29%2F150000" title="2021年におこなったコミュニケーションカイゼン - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2021/12/29/150000">blog.bltinc.co.jp</a></cite></p> <h3 id="おまけ">おまけ</h3> <h4 id="リモートでの過ごし方">リモートでの過ごし方</h4> <p>リモートだと通話することが多いのでイヤホンをよく使っていましたが、耳が痛くなったりするので会議用スピーカーに変えたら通話のストレスが無くなりました。</p> <p><a href="https://www.ankerjapan.com/products/a3306">Anker PowerConf+</a><cite class="hatena-citation"><a href="https://www.ankerjapan.com/collections/conferencespeaker/products/a3306">www.ankerjapan.com</a></cite></p> <p>他にも骨伝導もありますがものによっては音が反響したりするらしいので注意が必要です。</p> <p>後は運動不足になりやすいので自宅で自転車を漕いだりしています。考え過ぎているときに運動すると思考がいったんスッキリするのでおすすめです!</p> <p>リモートワークでのお困り事は様々あるかと思いますが、今回の記事が誰かのためになれたなら幸いです。</p> y-niki 縦型動画を編集する際に気をつけたこと hatenablog://entry/4207112889955001175 2023-01-25T15:00:00+09:00 2023-01-25T15:00:00+09:00 みなさんこんにちは! コーポレイトIT室でブランディングチームに所属しているmaripigです。 今回は昨年から徐々に社内での依頼が増えてきた動画編集のお話です。 その中でも、最近流行りの縦型動画の編集を行なった際に気をつけた点などをご紹介したいと思います。 縦型動画とは? 今回作成した動画について 気をつけたこと 1. UIによるデッドスペースを考慮する 2. 文字の大きさ 3. サムネイルのデザイン まとめ 縦型動画とは? 縦型動画とは、その名の通り動画の比率が縦長になっている動画のことです。 動画というとこれまではテレビのような横長の画面で視聴することが多かったため「横型」が主流でしたが… <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/maripig61/20230117/20230117115230.png" width="1200" height="718" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>みなさんこんにちは! コーポレイトIT室でブランディングチームに所属しているmaripigです。</p> <p>今回は昨年から徐々に社内での依頼が増えてきた動画編集のお話です。 その中でも、最近流行りの縦型動画の編集を行なった際に気をつけた点などをご紹介したいと思います。</p> <ul class="table-of-contents"> <li><a href="#縦型動画とは">縦型動画とは?</a></li> <li><a href="#今回作成した動画について">今回作成した動画について</a></li> <li><a href="#気をつけたこと">気をつけたこと</a><ul> <li><a href="#1-UIによるデッドスペースを考慮する">1. UIによるデッドスペースを考慮する</a></li> <li><a href="#2-文字の大きさ">2. 文字の大きさ</a></li> <li><a href="#3-サムネイルのデザイン">3. サムネイルのデザイン</a></li> </ul> </li> <li><a href="#まとめ">まとめ</a></li> </ul> <h2 id="縦型動画とは">縦型動画とは?</h2> <p>縦型動画とは、その名の通り動画の比率が縦長になっている動画のことです。 動画というとこれまではテレビのような横長の画面で視聴することが多かったため「横型」が主流でしたが、TikTokのようにスマートフォンを縦向きのまま視聴できるプラットフォームの増加に伴い、若者を中心に「縦型」の動画も需要が伸びてきているようです。</p> <h2 id="今回作成した動画について">今回作成した動画について</h2> <p>今回作成した動画は「もともと Instagram でライブ配信を行った時の動画を YouTube でも配信できるように編集したい」という依頼をいただいて作成しました。 なのでそもそも素材が「縦型」だった、というのがまず縦型動画を作成しよう!と思ったきっかけです。 さらに、視聴ターゲット層が就活生のため、まさに縦型動画世代!忙しい就活生でも、隙間時間に気軽に見れる動画にしたいという思いもありました。</p> <h2 id="気をつけたこと">気をつけたこと</h2> <p>それでは早速、縦型動画の編集で気をつけたことをご紹介します。 作成するにあたって、まず気になったのはアップロードの方法でした。 自分は YouTube の縦型動画というと<strong>ショート動画</strong>を思い浮かべたので、30分越えのインタビュー動画はアップロードできるのか気になりましたが、、、調べてみると、単純に縦型の動画をアップロードするだけでOKでしたので、それ以外の内容を下記にまとめます。</p> <h3 id="1-UIによるデッドスペースを考慮する">1. UIによるデッドスペースを考慮する</h3> <p>スマホでYouTubeを視聴する場合、概要欄を表示すると上部10%と下部25%が隠れてしまいます。 そのため、その部分に必ず読ませたい質問タイトルが被らないように配慮しました。 下部25%の中にはテロップが入っていますが、これは音声をONにしていれば隠れても困らない部分なので今回はよしとしています。 スマホ画面のサイズも色々なので、だいたい 2:1 くらいの画面サイズで作成すると良いみたいですね!</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/maripig61/20230117/20230117113502.png" width="1200" height="802" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>(こちらを参考にさせていただきました:<a href="https://android.benigumo.com/20181206/youtube-movie-landscape-portrait/">YouTube&#x306B;&#x7E26;&#x9577;&#x52D5;&#x753B;&#x3092;&#x3069;&#x3046;&#x30A2;&#x30C3;&#x30D7;&#x3059;&#x308B;&#x3079;&#x304D;&#x304B;?</a>)</p> <h3 id="2-文字の大きさ">2. 文字の大きさ</h3> <p>普段の横型動画は文字が大きくてもそこまで気になることはないですが、スマホ画面だと結構文字の大きさって気になるんですよね。大きすぎると読みづらかったり、、、 なので、一度編集が完了したら限定公開でアップロードして実機で確認してサイズ調整しました! PremierePro を使用して、1080×1920px の画面サイズで作成していましたが、フォントサイズは 55 くらいがちょうど良さそうでした。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/maripig61/20230117/20230117104247.png" width="1135" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h3 id="3-サムネイルのデザイン">3. サムネイルのデザイン</h3> <p>せっかく作った縦型動画ですが、サムネイルで普通の横型動画に紛れてしまうと勿体無い・・・!ということで、しっかり内容を訴求しつつも縦型動画であることがわかりやすいよう右側にアイキャッチを入れてみました。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/maripig61/20230117/20230117105056.jpg" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h2 id="まとめ">まとめ</h2> <p>今回初めて縦型動画を作成してみましたが、作成し始めてみると意外と気をつけるべき点があったなという印象です。 サイト制作などでも画面の大きさの違いによって見せ方や気をつけるべき点がありますが、それに似ている部分がありますね。 縦型動画を作成する際の参考になれば幸いです。</p> <p>また、今回作成した動画は弊社のYouTubeアカウントにて配信していますのでご覧いただけると嬉しいです!</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.youtube.com%2F%40bullettv8979" title="Bullet TV - YouTube" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.youtube.com/@bullettv8979">www.youtube.com</a></cite></p> <p>最後までお読みいただきありがとうございました。</p> maripig61 2023年セキュリティ強化宣言! hatenablog://entry/4207112889948409275 2023-01-11T15:30:00+09:00 2023-01-11T15:30:00+09:00 新年あけましておめでとうございます。コーポレートIT室(CIT室) Usekです。 本年もバレットグループとカラフルバレットをよろしくお願いいたします。 カラフルバレット1年の計は最初の記事にあり。今回は私の決意表明に関わるような記事を書かせていただきます。 2023年セキュリティ強化宣言の背景 2022年も多くのセキュリティ事故が世間で話題となりました。 3月:製菓会社がサイバー攻撃により顧客の個人情報が流出した可能性があると発表 5月:不動産管理会社の元従業員が退職した際、入居者に関する個人情報を不正に持ち出し営業活動に利用 6月:尼崎市全市民の個人情報入りUSBメモリの紛失 8月:厚生労… <p>新年あけましておめでとうございます。コーポレートIT室(CIT室) Usekです。 本年もバレットグループとカラフルバレットをよろしくお願いいたします。</p> <p>カラフルバレット1年の計は最初の記事にあり。今回は私の決意表明に関わるような記事を書かせていただきます。</p> <h3 id="2023年セキュリティ強化宣言の背景">2023年セキュリティ強化宣言の背景</h3> <p>2022年も多くのセキュリティ事故が世間で話題となりました。</p> <ul> <li>3月:製菓会社がサイバー攻撃により顧客の個人情報が流出した可能性があると発表</li> <li>5月:不動産管理会社の元従業員が退職した際、入居者に関する個人情報を不正に持ち出し営業活動に利用</li> <li>6月:尼崎市全市民の個人情報入りUSBメモリの紛失</li> <li>8月:厚生労働省が委託した企業がクラウドのセキュリティ設定ミス+メール宛先ミスにより機密情報が閲覧可能な状態に</li> </ul> <p>いずれも全く他人事に思えません。一歩間違えれば自分たちが被害者、加害者になる可能性は十分に考えられます。 バレットグループのセキュリティ担当者として、より一層セキュリティを強化しなければという気持ちでいっぱいです。 セキュリティを強化するために必要なタスクはちょっと見回せばいくらでも見つかり、まさに終わりがありません。</p> <p>さらに厄介なのは、これほどセキュリティが重視される社会でありながら、セキュリティ強化それ自体は利益を生み出さず(損害を防止するという意味では会社の利益に貢献しているのですが)利益を生み出す業務がどうしても優先されてしまうという点。セキュリティは<strong>"重要度は高いが優先度が低い"</strong>という難しい立場にあります。</p> <p>とはいえ後悔先に立たず。セキュリティ担当者として、利益を生み出す業務をこなしつつ、セキュリティ対策も並行して進めていかなければいけません。</p> <p><figure class="figure-image figure-image-fotolife" title="バレットグループセキュリティ強化宣言2023"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20221226/20221226183324.png" width="716" height="402" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>バレットグループセキュリティ強化宣言2023</figcaption></figure></p> <p>弊社では毎月"Bullet Headline"という社内向け動画を配信していますが、今月は全社に向け"バレットグループ セキュリティ強化宣言2023"をアナウンスします。 そして今年は以下の施策を実施することを宣言します。言ったからにはやらなければならない、という背水の陣です😅</p> <h4 id="バレットグループセキュリティポリシーの普及">バレットグループセキュリティポリシーの普及</h4> <p>セキュリティポリシーとは、ISMS(情報セキュリティを確保するための仕組み)を実現するための、社内規定といった組織全体のルールや、どのような情報資産をどのような脅威からどのように守るのかといった基本的な考え方から、情報セキュリティを確保するための体制、運用規定、基本方針、対策基準などが具体的に記載されたポリシーです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbltinc.co.jp%2Fnews%2F20230104%2F" title="グループ会社統合のお知らせ | バレットグループ株式会社/Bullet Group Inc." class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://bltinc.co.jp/news/20230104/">bltinc.co.jp</a></cite></p> <p>弊社のホームページの案内でもありますように、これまでバレットグループ、BULLBASE、BGテクノロジーと別れていた各会社がバレットグループに統合されます。 私は統合後を見据え、各事業部の担当者を交えた上で全社共通で利用可能なセキュリティポリシーを策定してきました。 2023年よりこのポリシーを全社に展開、運用を開始します。 これにより、社内全体のセキュリティレベルの強化に加えて、将来的なISMS認証の取得を見据えることができます。</p> <h4 id="セキュリティポータルの継続運用">セキュリティポータルの継続運用</h4> <p>セキュリティ事故に関するニュースやソフトウェア・ライブラリの脆弱性報告、セキュリティを改善するテクノロジーなど日々たくさんの情報が発信されますが、これを全てチェックするのは一般の人には困難です。 展開が必要と判断した情報をピックアップし、社内で運用しているセキュリティポータルに記事を作成し、社内SNSで共有しています。 昨年は以下のような情報を発信しました。</p> <ul> <li>社内で利用しているOS、ブラウザ、WordPressプラグインの脆弱性とアップデートの依頼</li> <li>OpenSSL脆弱性に対する社内インフラの影響と対応</li> <li>Emotet感染拡大に対する注意喚起</li> <li>社内で受信した不審なメールについて情報共有</li> <li>巧妙化する偽サイトの注意喚起</li> <li>不正に取得されたドメイン上で稼働する偽サイトの注意喚起</li> <li>ドッペルゲンガー・ドメインの事例に対する注意喚起</li> <li>(先日紹介した)アンチウイルスソフトESETが、何から社内PCを保護しているのかの説明</li> <li>新技術”パスキー”によるパスワードレスな未来についての考察</li> <li>忘年会シーズンにおけるセキュリティ注意喚起</li> </ul> <p>小さいニュースでも継続して情報を発信しています。企業のセキュリティを高める最も重要な要素は人間・つまり従業員です。 ランサムウェアの侵入経路で最も多いのは電子メールの添付ファイル。基本的な啓発を継続して行うことが重要と考えています。</p> <h4 id="e-learningの強化">e-learningの強化</h4> <p>企業のセキュリティを高める最も重要な要素は人間・つまり従業員です(大事なことなので二度言いましたよ) どんなに強固なセキュリティシステムやルールを用意したとしても、それを無効化・無視されたりすると結局意味がないのです。 e-learningについては導入している企業も多いと思いますが、ただ問題を配布しただけ、で終わりでは効果は十分ではないでしょう。 実際尼崎市USB紛失事故での報告書にも以下のような記述がありました<span style="font-size: 80%">※</span>。</p> <blockquote><p>当該 e-learning における理解度の確認テストは繰り返し受験を行えば正答を暗記して完了できるような形式となっており、理解が不十分でも e-learning の受講を完了することが可能であった。</p></blockquote> <p>おりしもCIT室でもより効果がある社内教育を検討しており、過去のe-learningの結果を分析したところ、同じように繰り返し受験を行なって合格にこぎつけた従業員がいました。再三依頼しても受講してくれない従業員もいました。これでは意味がないので、上長を経由してイエローカードを出しました。 今年からは毎回試験の結果を分析して、上記のような従業員の存在を逐一チェックするとともに、正答率が低かった問題の解説をおこなったり、e-learningを提供している会社が用意してくれている教材をただ流用するのではなく、自社に関係がある知識について解説した教材を自作することにしました。 残念ながらセキュリティ教育自体は退屈なモノです。どうすればモチベーションを上げることができるのか、自分ごとにできるのか、どこの会社のセキュリティ担当者も頭を悩ませていると思います。年間通じて優秀な成績だった社員に何らかのご褒美を出せればと思うのですが、自分には決裁権がなく・・・😅</p> <p><span style="font-size: 80%">※企業や組織が提出する障害報告書は目を通しています。自社にも同じセキュリティホールが存在することがわかり、新たなセキュリティ施策の動機になります。 </span></p> <h3 id="最後に">最後に</h3> <p>バレットグループは今年1月末で設立10年を迎えます。今後も更なる発展を続けられるようCIT室は後方支援をガッチリおこなっていきたいです。 セキュリティは重要で責任は重大ですが、バレットグループのメンバーが安心安全に本業に集中できるよう、さまざまな施策を進めてまいります。</p> Usek 2022年をふりかえる hatenablog://entry/4207112889946506484 2022-12-21T15:00:00+09:00 2022-12-22T10:56:46+09:00 はじめまして。コーポレイトIT室の室長をしております、ikueです。 今年最後のColorful Bullet記事ということで、2022年の活動ふりかえりと、2023年に向けた思いについて語らせていただければと思います。 2022年の活動ふりかえり コーポレイトIT室始動 その背景や意義、体制についてはusekさんが詳しくまとめていますが blog.bltinc.co.jp ミッションをひとことで言うと「バレットグループのビジネスをテクノロジー&デザインで支える」です。 マーケティングとシステム開発という2つの主軸ビジネス、そしてそれを作り育てる技術者たちを、横断的な観点で支えていく活動に励ん… <p>はじめまして。コーポレイトIT室の室長をしております、ikueです。 今年最後のColorful Bullet記事ということで、2022年の活動ふりかえりと、2023年に向けた思いについて語らせていただければと思います。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221222/20221222105610.jpg" width="1200" height="672" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h3 id="2022年の活動ふりかえり">2022年の活動ふりかえり</h3> <h4 id="コーポレイトIT室始動">コーポレイトIT室始動</h4> <p>その背景や意義、体制についてはusekさんが詳しくまとめていますが <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2022%2F10%2F26%2F150000" title="コーポレイトIT室とは? - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2022/10/26/150000">blog.bltinc.co.jp</a></cite></p> <p>ミッションをひとことで言うと「バレットグループのビジネスをテクノロジー&デザインで支える」です。 マーケティングとシステム開発という2つの主軸ビジネス、そしてそれを作り育てる技術者たちを、横断的な観点で支えていく活動に励んでおります。</p> <h4 id="Bullet-Disco">Bullet Disco</h4> <p>コーポレイトIT室としての最初の大きな仕事のひとつとして、エンジニア・デザイナー横断コミュニティを立ち上げました。 Discordをベースに、技術の話、雑談、リアルタイムの音声チャットなど、テレワーク時代に適した形で、ビジネスや部署の垣根を超えて交流ができ助け合える「場」づくりを目的としています。 ツール選定や運用ルールづくり、各部署に協力者を募って草の根勧誘からはじめ、現在はメンバー70人以上、awsからスプラトゥーンまでさまざまな話題で盛り上がっています。</p> <h4 id="Colorful-Bulletのリニューアル">Colorful Bulletのリニューアル</h4> <p>コーポレイトブランディングの大黒柱、maripigさんの手で、このブログのデザインが一新されました。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2022%2F10%2F12%2F142452" title="Colorful Bullet リニューアルしました! - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2022/10/12/142452">blog.bltinc.co.jp</a></cite></p> <p>以前のブログも同じmaripigさんデザインだったのですが、同じ人からまったく違うイメージのデザインが出てくるなんて、デザインのお仕事は本当に不思議ですごいなと思っています(語彙力皆無)。</p> <h4 id="社内ツールの統合統制重複サービスの整理">社内ツールの統合、統制、重複サービスの整理</h4> <p>普段なにげなく使っている、似たような機能のサービスやツールたち。あなたの周りにもありませんか。 弊社にもあります。ビジネスの幅が広がり、顧客が増えていくにつれ、必要とされる道具は変化していくものです。</p> <p>単純なツールの利用料金だけでなく、複数のツールを理解して使い分ける作業のコストも無視できないものがあります。 情報の分散による業務効率の低下や、セキュリティリスクの拡大など、散らかってるといいことがないのは、昨今の断捨離お片付けブームでも盛んに言われているのと同じかなと思います。</p> <p>そんなわけで、どこでどんなツールが使われているかを把握し、整理・統合していく作業をCITで実施しました。というか、現在も絶賛進行中です。</p> <h4 id="ゼロトラストセキュリティプロジェクト">ゼロトラストセキュリティプロジェクト</h4> <p>取締役4人からスタートした弊社も、気づけば10周年目前。人数も増え、ビジネスも大きくなり、それに伴って拡大する情報セキュリティリスク。 お仕事道具もPCやMac、スマホやタブレットなど多岐にわたり、以前から一部導入されていたテレワークもコロナ禍で一気に拡大しました。 大きなビジネスを成功させても、ちょっとしたセキュリティ事故で水の泡になってしまっては悲しすぎます。 そんな事態を防ぐため、CITの重点取り組みとして情報セキュリティ対策を進めていますが、ゼロトラストセキュリティは複雑化するセキュリティリスクに対応するための新しい考え方(モデル)です。 (詳しくはそのうちCITの誰かが記事にしてくれると思います)</p> <p>さまざまな対策を組み合わせて実施しますが、その一つとして、セキュリティソフトESETの導入をおこないました。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2022%2F11%2F30%2F150000" title="セキュリティソフトの切り替えを行いました - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2022/11/30/150000">blog.bltinc.co.jp</a></cite></p> <h4 id="そのほか">そのほか</h4> <p>こちらに書けないことも、大小さまざまな施策を実施してきました。決して人数の多くないチームですが、メンバー全員が社内のさまざまな声にアンテナを張りながら、さまざまなバックグラウンドを活かしてお互いに相談しつつ、着実に取り組んでくれました。 とても頼もしく、そして一緒に楽しくお仕事ができるチームメンバーに恵まれています。本当に感謝しかありません。ブログの運営もありがとうございます。遅筆で申し訳ございません。</p> <h3 id="2023年に向けて">2023年に向けて</h3> <p>来年明け、バレットグループは10周年を迎えます。十年一昔という言葉がありますが、歴史を振り返ると(私はその半分くらいの在籍年数ですが)実にダイナミックに変化しつづけてきた会社だなと思います。そして、今もなお、変化のまっただ中にいます。</p> <p>CITというチームが、会社とともにその変化にしなやかに対応しつつ、荒波に足元をすくわれないように気を配り守っていく役割を担っていければと思っています。</p> <p>10年を超えて、さらにその先へ進み続けるバレットグループを、来年もどうぞよろしくお願いいたします。</p> bulletgroup セキュリティソフトの切り替えを行いました hatenablog://entry/4207112889935350968 2022-11-30T15:00:00+09:00 2022-11-30T16:41:24+09:00 初めまして。 コーポレイトIT室で情シスチームに所属しているskskhhhです。 よろしくお願いいたします。 今回は、社内のエンドポイント製品の切り替えを行なった話について書いていきます。 ESETを選んだ理由 ESETの管理設定で気をつけたこと ESETに切り替え時に苦労したこと ESETの運用を始めて以前よりよくなったこと 今後について 最後に ESETを選んだ理由 先日、弊社では新たなエンドポイント製品として「ESET」を導入しました。 企業向け製品の中にも会社の規模や用途に応じていくつか種類があり、弊社が導入したのは「ESET PROTECT Advanced クラウド」です。 こちら… <p>初めまして。 コーポレイトIT室で情シスチームに所属しているskskhhhです。 よろしくお願いいたします。</p> <p>今回は、社内のエンドポイント製品の切り替えを行なった話について書いていきます。</p> <ul class="table-of-contents"> <li><a href="#ESETを選んだ理由">ESETを選んだ理由</a></li> <li><a href="#ESETの管理設定で気をつけたこと">ESETの管理設定で気をつけたこと</a></li> <li><a href="#ESETに切り替え時に苦労したこと">ESETに切り替え時に苦労したこと</a></li> <li><a href="#ESETの運用を始めて以前よりよくなったこと">ESETの運用を始めて以前よりよくなったこと</a></li> <li><a href="#今後について">今後について</a></li> <li><a href="#最後に">最後に</a></li> </ul> <h2 id="ESETを選んだ理由">ESETを選んだ理由</h2> <p>先日、弊社では新たなエンドポイント製品として「<strong>ESET</strong>」を導入しました。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><a href="http://f.hatena.ne.jp/skskhhh/20221125150249" class="hatena-fotolife" itemprop="url"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/skskhhh/20221125/20221125150249.jpg" width="391" height="269" loading="lazy" title="" class="hatena-fotolife" style="width:700px;height:250px" itemprop="image"></a></span></p> <p>企業向け製品の中にも会社の規模や用途に応じていくつか種類があり、弊社が導入したのは「<strong><a href="https://eset-info.canon-its.jp/business/ep-advanced-c/">ESET PROTECT Advanced クラウド</a></strong>」です。</p> <p>こちらの製品を選んだ理由は主にこんな感じかなと思います。</p> <ul> <li>以前使用していたエンドポイント製品よりも安い</li> <li>クラウドで管理ができて、手作業でのアップデート作業を行わなくて良くなる(定義ファイルのアップデート・製品自体のバージョンアップデート)</li> <li>社内に管理サーバーを置かなくてよい</li> <li>以前使用していたエンドポイント製品の機能を網羅している</li> <li>以前使用していたエンドポイント製品の機能でできなかったことが実現できる(Apple製品のハードウェア情報の確認・PCインストール済みのアプリケーションの確認)</li> </ul> <p>以前使用していたエンドポイント製品よりも、コストがかからなかったり、管理する手間が省けたりとメリットが沢山あるなと感じました。</p> <p><iframe width="560" height="315" src="https://www.youtube.com/embed/LS3TI7wgF0E?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen title="エンドポイントセキュリティソリューション「ESET PROTECT Advanced クラウド」 ~おしえて!オフィスを飛び出したPCたち、どうやって守るの?~"></iframe><cite class="hatena-citation"><a href="https://youtu.be/LS3TI7wgF0E">youtu.be</a></cite></p> <h2 id="ESETの管理設定で気をつけたこと">ESETの管理設定で気をつけたこと</h2> <p>ESETを導入することが決定してからは、評価版を使用し検証を行いました。 導入検証では、以下のことに気をつけました。</p> <ul> <li>以前使用していたエンドポイント製品と同等の機能を設定すること</li> <li>案件のセキュリティ要件で必要な制御を抜け漏れなく設定すること</li> <li>ESETを導入したことによって影響がでてしまうアプリケーション・WEBサイトがあった場合は、影響が出ない状態に設定を変更すること</li> </ul> <p>弊社では社内コミュニュケーションツールとして、Teamsを使用しているのですが、ESETを導入したことによって通話が聞こえないなど影響が出てしまいました。</p> <p>その際に、ファイアウォールのポートに許可をする設定を追加するなど、入念な検証とその対処を行いました。(⏬その時参考にした設定方法です)</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Feset-support.canon-its.jp%2Ffaq%2Fshow%2F3562%3Fsite_domain%3Dbusiness" title="Windows環境で通信の許可ルールを作成するには? | ESETサポート情報 | 法人向けサーバー ・ クライアント用製品 | キヤノンITソリューションズ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://eset-support.canon-its.jp/faq/show/3562?site_domain=business">eset-support.canon-its.jp</a></cite></p> <p>その他のアプリ・サイトでも業務に影響がないように細かく検証を行い、とにかく慎重に管理設定をしました。</p> <h2 id="ESETに切り替え時に苦労したこと">ESETに切り替え時に苦労したこと</h2> <p>検証も一通り終わり、いよいよ切り替えを行おうと思った際に、ユーザー側の負担を減らすために、以前使用していた管理サーバー上でできることがないかをまず確認しました。</p> <p>以前使用していたエンドポイント製品のアンインストールは管理サーバー上で行うことができたのですが、ユーザーによってアンインストールできるタイミングが異なったため、導入できるタイミングも違ってきました。</p> <p>なので、こちらで一人一人案内を出したり、切り替え状況を管理するのが地味に苦労しました。</p> <p>また、ユーザー側でインストーラーがきちんと作動せず、正常にインストールできていない方がちらほらいて、対処法がわからず困りましたが、再インストールを行うことで正常にインストールもできるようになりました。</p> <p>検証の段階で起きなかった不具合の解消は、ユーザー側に影響がでてしまうので、最優先で行いました。</p> <h2 id="ESETの運用を始めて以前よりよくなったこと">ESETの運用を始めて以前よりよくなったこと</h2> <p>実際に運用を開始してみて、3ヶ月ほど経ちましたが、ESETの利点がいくつか見えてきました。</p> <ul> <li>インストーラーの作成が視覚的にわかりやすくて、簡単</li> <li>一度作成してしまえば製品のアップデートが自動的に行われるので、メンテナンス不要</li> <li>インストールが一瞬で終わる!(キッティング時間が短縮された)</li> <li>管理クラウドとの同期間隔が短いので常に安心安全!</li> <li>インストール済みのアプリケーションを確認できるようになったので、脆弱性のあるアプリケーションを保持している方を把握できるようになった</li> <li>ダッシュボードからPCの状態や検出されたウィルスなどがわかりやすく見れるようになった</li> </ul> <p>などなど</p> <p>今までのエンドポイント製品にも似たような機能があったと思いますが、ESETは画面が簡潔でわかりやすいのであまり迷うことなく機能を使用することができるのもいいところだと思います。</p> <p><figure class="figure-image figure-image-fotolife" title=" "><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/skskhhh/20221125/20221125172409.jpg" width="1200" height="577" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption> </figcaption></figure> 引用:<a href="https://eset-info.canon-its.jp/business/ep-advanced-c/">ESET PROTECT Advanced &#x30AF;&#x30E9;&#x30A6;&#x30C9;&#xFF5C;ESET PROTECT&#x30BD;&#x30EA;&#x30E5;&#x30FC;&#x30B7;&#x30E7;&#x30F3;</a></p> <h2 id="今後について">今後について</h2> <p>ESETの機能はまだまだ沢山あるので、正直全然使いこなせていません。 今後は以下の機能を調査した上で、活用できたらなと思っています。</p> <ul> <li>ESET LiveGuard Advanced</li> <li>モバイルへの導入</li> <li>レポートの活用</li> </ul> <h2 id="最後に">最後に</h2> <p>ESETのいい点ばかり挙げたので回し者みたいになっていますが、今よりもコストがかからなかったり、利便性が上がったりと弊社にとってはいいことづくしでしたので、導入を検討されているかたは是非参考にしてみてください。</p> skskhhh 要点整理!Next.js を Firebase にデプロイする方法 hatenablog://entry/4207112889934980392 2022-11-16T15:00:00+09:00 2022-11-17T15:00:13+09:00 こんにちは。 最近盆栽になるであろう芽に水をあげるのが日課の id:hokupod です。 Web フロントエンド界隈に手を出すのは今じゃないと心の中で言い続けてきました。。 しかし React の勢いが留まることを知らないため、社内ツールから Next.js をはじめて見ようと決心した際の記録です。 (決心したら、今度は Astro で MPA いいよね!という声も出て来て、本当安定しない界隈だなと感じました。発展し続けているのはスゴイこと) ということで、今回は Next.js を使用して Firebase にデプロイする際に詰まったこと、得た学びについて書きたいと思います。 実際にどんな… <p>こんにちは。 最近盆栽になるであろう芽に水をあげるのが日課の <a href="http://blog.hatena.ne.jp/hokupod/">id:hokupod</a> です。</p> <p>Web フロントエンド界隈に手を出すのは今じゃないと心の中で言い続けてきました。。 しかし React の勢いが留まることを知らないため、社内ツールから Next.js をはじめて見ようと決心した際の記録です。 <del>(決心したら、今度は Astro で MPA いいよね!という声も出て来て、本当安定しない界隈だなと感じました。発展し続けているのはスゴイこと)</del></p> <p>ということで、今回は Next.js を使用して Firebase にデプロイする際に詰まったこと、得た学びについて書きたいと思います。 実際にどんな社内ツールを作ったのかというと、シンプルな管理画面付きの短縮 URL サービスです。 <figure class="figure-image figure-image-fotolife" title="短縮URL生成してくれる君"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hokupod/20221109/20221109120048.png" width="1200" height="619" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>短縮URL生成してくれる君</figcaption></figure></p> <ul class="table-of-contents"> <li><a href="#動機">動機</a></li> <li><a href="#技術スタック">技術スタック</a></li> <li><a href="#デプロイの流れ">デプロイの流れ</a><ul> <li><a href="#ライブラリのインストール">ライブラリのインストール</a></li> <li><a href="#必要ファイルの追加と編集">必要ファイルの追加と編集</a><ul> <li><a href="#firebaserc">.firebaserc</a></li> <li><a href="#firebasejson">firebase.json</a></li> <li><a href="#firebaseFunctionsjsファイル名は-packagejson-で指定するため任意">firebaseFunctions.js(ファイル名は package.json で指定するため任意)</a></li> <li><a href="#packagejson">package.json</a></li> </ul> </li> <li><a href="#デプロイの実行">デプロイの実行</a></li> </ul> </li> <li><a href="#まとめ">まとめ</a></li> </ul> <h2 id="動機">動機</h2> <p>そもそもなぜ Next.js と Firebase の組み合わせで開発をしたのかについて、触れていこうと思います。 まず Next.js については、下記が選定理由です。</p> <ol> <li>触りたかった<strong>React が使用</strong>されていること。</li> <li>フルスタックであり、バックエンド処理も記述することが出来るため、多少だがバックエンド処理を別のフレームワークにするより<strong>学習コストが低い</strong></li> <li>Remix など他フレームワークと比べるとシェアが高いように思える(要出典)</li> </ol> <p>Firebase については、下記が選定理由です。</p> <ol> <li><strong>Google ワークスペースを利用した認証</strong>がおこなえる</li> <li><strong>安い</strong></li> <li><strong>サーバ持ちたくない</strong></li> <li>大抵の物は揃っている</li> <li>Next.js をどうやらデプロイできるらしい</li> </ol> <p>両方とも大した理由ではないと言われてしまいそうですねw 今回は社内ツールということもあり、<strong>長生きしそうか・安価か・社内からのアクセスに限定ができるか・チャレンジ要素はあるか</strong>を特に重視しました。</p> <p>当社は、AWS パートナーネットワーク(APN)を取得していることもあり、普段は AWS を使用した開発が主です。 しかし前述の通り、チャレンジ要素としての技術調査で Firebase を使用した形です。</p> <h2 id="技術スタック">技術スタック</h2> <p>技術スタックとしては、ざっくりですが下記の通りになります。</p> <ul> <li>フロントエンド/バックエンドフレームワーク <ul> <li><a href="https://nextjs.org">Next.js</a></li> </ul> </li> <li>View ライブラリ <ul> <li><a href="https://reactjs.org">React</a></li> <li><a href="https://material-table.com/#/">material-table</a></li> </ul> </li> <li>ログイン認証基盤 <ul> <li><a href="https://firebase.google.com/docs/auth/">Firebase Authentication</a>(管理画面の認証)</li> </ul> </li> <li>データベース <ul> <li><a href="https://firebase.google.com/products/firestore?hl=ja">Cloud Firestore</a>(短縮 URL の情報を保持)</li> </ul> </li> <li>ホスティング <ul> <li><a href="https://firebase.google.com/docs/hosting/">Firebase Hosting</a></li> </ul> </li> <li>バックエンド環境 <ul> <li><a href="https://firebase.google.com/products/functions?hl=ja">Cloud Functions for Firebase</a>(Next.js のバックエンド)</li> <li><a href="https://cloud.google.com/functions/">Cloud Functions</a>(短縮 URL から登録した URL に変換する処理)</li> </ul> </li> </ul> <p>短縮 URL を登録する管理画面、短縮URLからリダイレクトする処理はそれぞれ別にリポジトリを用意して管理しています。</p> <p>ではここから実際に Next.js のプロジェクトを Firebase にデプロイする流れを追っていきます。</p> <blockquote><p>パッケージマネージャーとして、<code>yarn</code> を使用しますので、<code>npm</code> を使用されている方は適宜読み替えください。 また事前に Firebase プロジェクトは作成済みであるとします。</p></blockquote> <h2 id="デプロイの流れ">デプロイの流れ</h2> <p>今回使用した構成は、下記のとおりです。</p> <blockquote><p><strong>ファイル名に付与している絵文字の説明</strong> 🆕 Firebase を使用するために新規追加したファイル ✍ Firebase を使用するために編集したファイル</p></blockquote> <pre class="code tree" data-lang="tree" data-unlink>. ├── .firebaserc ├── dprint.json ├── 🆕 firebase.json ├── 🆕 firebaseFunctions.js ├── next.config.js ├── node_modules ├── ✍ package.json ├── postcss.config.js ├── src │   ├── components │   ├── contexts │   ├── libs │   ├── pages │   ├── public │   ├── styles │   └── types ├── tailwind.config.js ├── tsconfig.json └── yarn.lock</pre> <h3 id="ライブラリのインストール">ライブラリのインストール</h3> <p>Firebase を使用するためのライブラリをインストールします。 下記のうち <code>firebase-tools</code> はデプロイなど Firebase の操作に使用するライブラリになります。</p> <pre class="code lang-sh" data-lang="sh" data-unlink>yarn add firebase-functions yarn add <span class="synSpecial">-D</span> firebase-tools </pre> <h3 id="必要ファイルの追加と編集">必要ファイルの追加と編集</h3> <p>前述の構成にもマークを付けておりますが、下記 4 ファイルを Firebase にデプロイする上で追加・編集します。</p> <p><strong>新規追加</strong></p> <ol> <li>.firebaserc <ul> <li>Firebase Hosting で使用するリソースファイル</li> </ul> </li> <li>firebase.json <ul> <li>Firebase 用の設定ファイル。今回は Firebase Hosting / Cloud Functions for Firebase の設定を記載する</li> </ul> </li> <li>firebaseFunctions.js(ファイル名は任意) <ul> <li>Cloud Functions for Firebase にデプロイされる関数。Next.js のバックエンド処理に委譲する</li> </ul> </li> </ol> <p><strong>編集</strong></p> <ol> <li>package.json <ul> <li>Cloud Functions for Firebase のエントリポイントの設定、Node のバージョン指定、ビルドタスクをまとめるために使用</li> </ul> </li> </ol> <p>ではここから一つ一つのファイルの詳細を見ていきます。</p> <h4 id="firebaserc">.firebaserc</h4> <p>使用するプロジェクト名を記載します。</p> <pre class="code lang-json" data-lang="json" data-unlink><span class="synSpecial">{</span> &quot;<span class="synStatement">projects</span>&quot;: <span class="synSpecial">{</span> &quot;<span class="synStatement">default</span>&quot;: &quot;<span class="synConstant">firebase-project-name</span>&quot; <span class="synSpecial">}</span> <span class="synSpecial">}</span> </pre> <h4 id="firebasejson">firebase.json</h4> <p>重要な点は、下記2点になります。</p> <ol> <li>Next.js で Firebase Hosting に配置する静的ファイルを生成するコマンド <code>next export</code> の吐き出し先は <code>out</code> になるため、<code>hosting.public</code> で指定する</li> <li>Node のバージョンを合わせるため、<code>functions.runtime</code> を指定する</li> </ol> <pre class="code lang-json" data-lang="json" data-unlink><span class="synSpecial">{</span> &quot;<span class="synStatement">hosting</span>&quot;: <span class="synSpecial">{</span> &quot;<span class="synStatement">public</span>&quot;: &quot;<span class="synConstant">out</span>&quot;, &quot;<span class="synStatement">ignore</span>&quot;: <span class="synSpecial">[</span>&quot;<span class="synConstant">firebase.json</span>&quot;, &quot;<span class="synConstant">**/.*</span>&quot;, &quot;<span class="synConstant">**/node_modules/**</span>&quot;<span class="synSpecial">]</span>, &quot;<span class="synStatement">rewrites</span>&quot;: <span class="synSpecial">[</span> <span class="synSpecial">{</span> &quot;<span class="synStatement">source</span>&quot;: &quot;<span class="synConstant">**</span>&quot;, &quot;<span class="synStatement">function</span>&quot;: &quot;<span class="synConstant">nextjsFunc</span>&quot; <span class="synSpecial">}</span> <span class="synSpecial">]</span> <span class="synSpecial">}</span>, &quot;<span class="synStatement">functions</span>&quot;: <span class="synSpecial">{</span> &quot;<span class="synStatement">source</span>&quot;: &quot;<span class="synConstant">.</span>&quot;, &quot;<span class="synStatement">runtime</span>&quot;: &quot;<span class="synConstant">nodejs16</span>&quot; <span class="synSpecial">}</span> <span class="synSpecial">}</span> </pre> <h4 id="firebaseFunctionsjsファイル名は-packagejson-で指定するため任意">firebaseFunctions.js(ファイル名は <code>package.json</code> で指定するため任意)</h4> <p>Next.js のバックエンド処理部分のエクスポートである <code>next build</code> の吐き出し先を、下記ソースの <code>nextjsDistDir</code> に指定する必要があります。 デフォルトは <code>.next</code> ですが、もし <code>next.config.js</code> にて <code>distDir: 'your-dist-dir-path'</code> と指定している場合は、<code>next.distDir</code> を使用することも可能です。</p> <p>Cloud Functions for Firebase への HTTP リクエストをすべて Next.js のサーバサイドに委譲する形を取っています。</p> <pre class="code js" data-lang="js" data-unlink>const { https } = require(&#39;firebase-functions&#39;) const { default: next } = require(&#39;next&#39;) const nextjsDistDir = &#39;.next&#39; const nextjsServer = next({ dev: false, conf: { distDir: nextjsDistDir, }, }) const nextjsHandle = nextjsServer.getRequestHandler() exports.nextjsFunc = https.onRequest((req, res) =&gt; { return nextjsServer.prepare().then(() =&gt; nextjsHandle(req, res)) })</pre> <h4 id="packagejson">package.json</h4> <p>package.json には、ビルドタスクを設定するだけではなく、Cloud Functions for Firebase の設定も記載します。</p> <ol> <li><code>main</code> には関数を記載したファイルを指定します。</li> <li><code>engines.node</code> には関数で使用する Node.js のバージョンを指定します。</li> </ol> <hr /> <p>scripts へは <code>login</code>, <code>serve</code>, <code>shell</code>, <code>deploy</code>, <code>logs</code> を追加をしています。</p> <ol> <li><code>scripts.login</code> は、デプロイ前などに CLI から Firebase にログインするために使用</li> <li><code>scripts.serve</code> は、開発用サーバである Firebase のエミュレータ起動用</li> <li><code>scripts.shell</code> は、Cloud Function for Firebase のローカル起動用(使ってない</li> <li><code>scripts.deploy</code> は、本番環境へのデプロイ用</li> <li><code>scripts.logs</code> は、デプロイ後の Cloud Function for Firebase のログを見る用</li> </ol> <pre class="code lang-json" data-lang="json" data-unlink><span class="synSpecial">{</span> &quot;<span class="synStatement">private</span>&quot;: <span class="synConstant">true</span>, &quot;<span class="synStatement">main</span>&quot;: &quot;<span class="synConstant">firebaseFunctions.js</span>&quot;, &quot;<span class="synStatement">engines</span>&quot;: <span class="synSpecial">{</span> &quot;<span class="synStatement">node</span>&quot;: &quot;<span class="synConstant">16.x</span>&quot; <span class="synSpecial">}</span>, &quot;<span class="synStatement">scripts</span>&quot;: <span class="synSpecial">{</span> ... &quot;<span class="synStatement">login</span>&quot;: &quot;<span class="synConstant">firebase login</span>&quot;, &quot;<span class="synStatement">serve</span>&quot;: &quot;<span class="synConstant">next build &amp;&amp; next export &amp;&amp; firebase emulators:start --only functions,hosting</span>&quot;, &quot;<span class="synStatement">shell</span>&quot;: &quot;<span class="synConstant">next build &amp;&amp; firebase functions:shell</span>&quot;, &quot;<span class="synStatement">deploy</span>&quot;: &quot;<span class="synConstant">next build &amp;&amp; next export &amp;&amp; firebase deploy --only functions,hosting</span>&quot;, &quot;<span class="synStatement">logs</span>&quot;: &quot;<span class="synConstant">firebase functions:log</span>&quot;, ... <span class="synSpecial">}</span><span class="synError">,</span> <span class="synError">}</span> </pre> <p>以上でファイルの追加・編集は完了です。 続いて、デプロイの実行です。</p> <h3 id="デプロイの実行">デプロイの実行</h3> <p>デプロイ前に注意事項です。 Cloud Functions for Firebase を利用するためには、<strong>Blaze プランにする必要</strong>があります。 つまりは、無料枠だけを使うという安心感は手放す必要があるということです。。</p> <p>とはいえ、無料枠は十分にありますので、すぐさまお金が多くかかるという事態には陥らないはずです。 (もちろん、セキュリティには注意が必要です。)</p> <p>Blaze プランに変更が完了したら、あとは簡単です。下記を実行するとデプロイされます。</p> <pre class="code lang-sh" data-lang="sh" data-unlink>yarn login yarn deploy </pre> <p>これだけで実は Next.js から見ている環境変数ファイル <code>.env.local</code> も参照されている状態でデプロイされます。 私はこれだけでちょっと感動しました。 だって環境変数周りって、毎回ゴニョゴニョするじゃないですか。。</p> <h2 id="まとめ">まとめ</h2> <p>こうまとめてみると、意外と簡単に(?)Firebase 環境に Next.js をデプロイできることがわかります。 Firebase さまさまです。 社内ツールでは、<strong>必ずなんらかの認証を挟まないといけない</strong>という制約が生まれます。 Firebase では Google Workspace での認証、Azure では Azure Active Directory での認証など、<strong>ツールのためのアカウントを作成する</strong>といった利用者の手間を省ける仕組みは積極的に利用したいと思いました。</p> <p>Next.js の話にはなりますが、<strong>フロント・バックの両方を JS で一貫して書ける</strong>というのは、<strong>頭の切り替えが最小</strong>で済むというメリットがありました。 React は<a href="https://klemiwary.com/bibliography">りあクト!</a>で学びましたが、歴史含め体系的にまとまっており、フロントエンド初心者の私でもやり切れる知識を付けることができたので大変オススメです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fklemiwary.com%2Fbibliography" title="刊行書籍のご紹介 - くるみ割り書房" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://klemiwary.com/bibliography">klemiwary.com</a></cite></p> <p>また今回 Copilot (with Vim) を使用してコーディングをしたのですが、<strong>フレームワークに乗っかるための書き方・ライブラリの使い方は Copilot が教えてくれて</strong>面白かったです。 もちろん思っていたのと違う形に補完されてしまったりするので、レビューはちゃんとする必要がありますが、さささっと<strong>プロトタイピングするには向いている</strong>と思いました。 ライセンス問題など、まだまだ課題があるようですが、解決されて気持ちよく使える日がくることを心待ちにしています。</p> <p>最後になりますが、今回のチャレンジをするキッカケをくださった人事および情シスのみなさま、実装に際してアドバイスをくださったエンジニア・デザイナーのみなさま、そして長文にも関わらず最後までお読みいただいたみなさま、大変ありがとうございました。</p> hokupod コーポレイトIT室とは? hatenablog://entry/4207112889927089293 2022-10-26T15:00:00+09:00 2022-10-27T14:59:22+09:00 初めまして&お久しぶりです。Usekです。 昨年度まではTechnology&Design部のSREチームに所属し、カラフルバレットの記事更新も行ってきました。 現在は、バレットグループの体制変更により4月に新設された「コーポレイトIT室」に所属しています。 今回はこのコーポレイトIT室について自分なりに考えていることを書いていきます。 コーポレイトIT室 = 情シス? コーポレイトIT室の体制 なぜコーポレイトIT室が作られたのか ①プロダクトおよび情報システムの安定した運用 ②ビジネスを取り巻くIT環境の変化へのすばやい対応 ③技術人材のスキルおよびコミュニケーションの維持向上 ④ビジネス… <p>初めまして&お久しぶりです。Usekです。 昨年度まではTechnology&amp;Design部のSREチームに所属し、カラフルバレットの記事更新も行ってきました。 現在は、バレットグループの体制変更により4月に新設された「コーポレイトIT室」に所属しています。 今回はこのコーポレイトIT室について自分なりに考えていることを書いていきます。</p> <ul class="table-of-contents"> <li><a href="#コーポレイトIT室--情シス">コーポレイトIT室 = 情シス?</a></li> <li><a href="#コーポレイトIT室の体制">コーポレイトIT室の体制</a></li> <li><a href="#なぜコーポレイトIT室が作られたのか">なぜコーポレイトIT室が作られたのか</a><ul> <li><a href="#プロダクトおよび情報システムの安定した運用">①プロダクトおよび情報システムの安定した運用</a></li> <li><a href="#ビジネスを取り巻くIT環境の変化へのすばやい対応">②ビジネスを取り巻くIT環境の変化へのすばやい対応</a></li> <li><a href="#技術人材のスキルおよびコミュニケーションの維持向上">③技術人材のスキルおよびコミュニケーションの維持向上</a></li> <li><a href="#ビジネスサイドと技術サイドのコラボレーション促進">④ビジネスサイドと技術サイドのコラボレーション促進</a></li> </ul> </li> <li><a href="#私の業務">私の業務</a></li> </ul> <h3 id="コーポレイトIT室--情シス">コーポレイトIT室 = 情シス?</h3> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20221017/20221017181432.png" width="1000" height="625" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>私が組織変更でSREチームからコーポレイトIT室に転属することを知らされた時、真っ先に思ったのは「要するに情シスなのでは?」でした。 情シスというと「壊れたパソコンを修理に出す」とか、「従業員から依頼されてパスワードをリセットする」とか、自分が長年生業としてきたシステムエンジニアリングと毛色が違うと思いました。 果たしてそれは自分のやりたいことなのだろうかと不安になりました。 しかし調べた結果、コーポレイトIT室は私の想像していたイメージとかなり異なることが分かりました。</p> <p>そもそも「コーポレイトIT室」という用語は弊社が勝手に定めたフレーズではありません(世間的には「コーポレ<strong>ー</strong>トIT室」のようですが😅)</p> <p>こちらはLINEさんの記事。 <a href="https://line-hr.jp/archives/54140344.html">&#x3010;LINE&#x306E;&#x306A;&#x304B;&#x307F;&#x3011;&#x30B3;&#x30FC;&#x30DD;&#x30EC;&#x30FC;&#x30C8;IT&#x5BA4;&amp;IT&#x6226;&#x7565;&#x5BA4;&#x306E;&#x4ED5;&#x4E8B;&#x3092;&#x7D39;&#x4ECB;&#x3057;&#x307E;&#x3059; : LINE HR BLOG</a></p> <blockquote><p>社内ポータルに公開されている紹介文には、「LINEグループのIT業務に関わる戦略立案・企画・開発・運営」と記載しています。要はLINEグループが業務を行い、成長するためのシステムを担う部門です</p></blockquote> <p>こちらはnoteさんでコーポレートITエンジニアとして働いている方の記事。 <a href="https://note.com/khigashi/n/n38b270317aab">&#x30B3;&#x30FC;&#x30DD;&#x30EC;&#x30FC;&#x30C8;IT&#x3068;&#x3044;&#x3046;&#x4ED5;&#x4E8B;&#xFF08;&#x4E00;&#x822C;&#x8AD6;&#x7DE8;&#xFF09;&#xFF5C;&#x30D2;&#x30AC;&#x30B7; note inc.&#xFF5C;note</a></p> <blockquote><p>コーポレートITは様々な仕事を領分とするので、要求されるスキルも多様です。 コーポレートITは元々ITエンジニアとして開発をやっていた人がほとんどです。僕もそうですし、前職の上司も先輩も部下もかつては開発をやっていました</p></blockquote> <p>上記の記事の後編にあたる<a href="https://note.com/khigashi/n/n7468c57250c1">「自らの志向編」</a>には非常に感銘を受けました。 「僕もこれまでの自分の経験を活かし、コーポレートIT室メンバーとして頑張ろう」という気持ちになりました。</p> <p>また、私の疑問そのものズバリのタイトルの記事もありました。 <a href="https://logmi.jp/tech/articles/322251">&#x60C5;&#x30B7;&#x30B9;&#x3068;Corporate IT&#x3001;&#x4F55;&#x304C;&#x9055;&#x3046;&#x306E;&#xFF1F; Web&#x7CFB;&#x5DE8;&#x5927;IT&#x4F01;&#x696D;4&#x793E;&#x304C;&#x8A9E;&#x308B;&#x3001;&#x793E;&#x5185;&#x30B7;&#x30B9;&#x30C6;&#x30E0;&#x30A8;&#x30F3;&#x30B8;&#x30CB;&#x30A2;&#x306E;&#x4ED5;&#x4E8B; - &#x30ED;&#x30B0;&#x30DF;&#x30FC;Tech</a></p> <p>この中で紹介されていた「情シスとコーポレートITの比較」の図は、情シスの定義が自分のイメージと合致していたため、コーポレートIT室に求められているものもはっきり見えるようになりました。</p> <blockquote><p>Corporate ITは、レガシーシステムの数は少なめです。インターネットがないと呼吸ができない人たちが大量にいます。クラウド利用は大前提で、クラウドファーストについてことさら言うまでもないという感じです。比較的内製志向が高く、自分たちでやる、ないしは人が足りないので中々できないけどやりたいという意思はある感じの方が多いです</p></blockquote> <p>コーポレイトIT室は次に紹介する体制図のように、情報システム部門を内包します。 その上で情報システム部門が従来おこなってきた業務もクラウドを利用して内製するなど、よりソフトウェアエンジニアリングに重きを置いた組織と考えています。</p> <h3 id="コーポレイトIT室の体制">コーポレイトIT室の体制</h3> <p>コーポレイトIT室は以下のように構成されています。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20221019/20221019142418.png" width="409" height="247" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <ul> <li>R&Dチーム:技術検証を主業務とし、社内の技術関連課題を解決</li> <li>ブランディングチーム:コーポレイト関連のアートディレクションおよび実制作</li> <li>情報システムチーム:業務で利用するPCやWebサービスの選定・メンテナンス・運用のサポート</li> <li>スペシャルミッション:将来の新サービスに向け特別な研究開発を外部で進行</li> </ul> <p>私はR&Dチームに所属しています。</p> <h3 id="なぜコーポレイトIT室が作られたのか">なぜコーポレイトIT室が作られたのか</h3> <p><strong>「バレットグループが大きくなったから、そして今後さらに大きくなっていくため」</strong>だと考えています。 バレットグループ株式会社は来年で設立10年を迎えます。 4名でスタートした弊社も現在では200名超の仲間と共に多様なビジネスを展開しています。 拠点も本社の他に仙台支店、新潟支社、江田島ラボと拡大しました。 会社の規模が大きくなることは嬉しいことですが、大きくなるにつれて様々な問題が生じてきました。</p> <ul> <li>各事業部で業務利用しているサービスがばらばらで管理統制できていない、そもそも情シスが把握していないサービスを利用しているケースがある</li> <li>各事業部の業務内容が見えづらくなった。安全安心に業務を行えるよう会社が定めたルールを全事業部に対して適応したい</li> <li>メンバーと関連会社が増えたことに加え、リモートワークの普及によりメンバーの横の繋がりが薄くなった</li> </ul> <p>今までと同じ体制で業務を遂行していては問題を解決することはできず、新たな対処が必要となります。 部署設立時の全社向けアナウンスでは、コーポレイトIT室が「解決すべき問題」について以下の4つが挙げられていました。</p> <ol> <li>プロダクトおよび情報システムの安定した運用</li> <li>ビジネスを取り巻くIT環境の変化へのすばやい対応</li> <li>技術人材のスキルおよびコミュニケーションの維持向上</li> <li>ビジネスサイドと技術サイドのコラボレーション促進</li> </ol> <p>以下私なりの解釈となります。</p> <h4 id="プロダクトおよび情報システムの安定した運用">①プロダクトおよび情報システムの安定した運用</h4> <p>サービス規模が大きくなるにつれ責任も重くなります。サービス停止やセキュリティ事故によるリスクも高くなります。 システムを安定稼働させることで従業員の負担を減らし、サービスの信頼性を守る必要があります。 そのためにはシステムを安定して稼働させるインフラ構築を実現するためのガイドラインの作成と、障害発生時に迅速に対応できるフローが必要です。これらのガイドラインの作成がコーポレイトIT室の役割の一つです。 また、セキュリティの課題について情報を収集・自社サービスに影響がないか調査検証することも重要な役割になります。</p> <h4 id="ビジネスを取り巻くIT環境の変化へのすばやい対応">②ビジネスを取り巻くIT環境の変化へのすばやい対応</h4> <p>コスト削減、業務効率の改善、セキュリティ強化、企業の成長発展のためにICTが必要となります。 今年だけでもこれまでの私たちの常識を覆すさまざまなテクノロジーが発表されました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgigazine.net%2Fnews%2F20220622-gitHub-copilot-available-all-developers%2F" title="ソースコードの「続き」を自動で補完する「GitHub Copilot」がすべてのユーザーに利用可能へ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://gigazine.net/news/20220622-gitHub-copilot-available-all-developers/">gigazine.net</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.publickey1.jp%2Fblog%2F22%2Fawsamazon_codewhiperer.html" title="AWSも、プログラミングを機械学習で支援する「Amazon CodeWhisperer」プレビュー公開。コメントを書くとコードを提案" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.publickey1.jp/blog/22/awsamazon_codewhiperer.html">www.publickey1.jp</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.itmedia.co.jp%2Fnews%2Farticles%2F2208%2F02%2Fnews124.html" title="「神絵が1分で生成される」 画像生成AI「Midjourney」が話題" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.itmedia.co.jp/news/articles/2208/02/news124.html">www.itmedia.co.jp</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fforest.watch.impress.co.jp%2Fdocs%2Fserial%2Fyajiuma%2F1444554.html" title="自然な日本語で注文するとソースコードを作ってくれるサービス「AI Programmer」が登場/プロトタイプとして無償公開【やじうまの杜】" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://forest.watch.impress.co.jp/docs/serial/yajiuma/1444554.html">forest.watch.impress.co.jp</a></cite></p> <p>こうして振り返ると、2022年はAI技術が普及した1年と言えそうです。 既存事業の改善や新規事業のアイディアに活かすために新技術を積極的に検証し、良いものについては既存サービスや新規プロダクトに取り入れていかなければいけません。 既存サービスに対して業務を遂行するプロフィット部門とは別の部門がこの業務を担当する方が機動力があります。 バレットグループがこの先成長し続けるためにも、コーポレイトIT室の責任は重大です。</p> <h4 id="技術人材のスキルおよびコミュニケーションの維持向上">③技術人材のスキルおよびコミュニケーションの維持向上</h4> <p>社内のコミュニケーションを活発にし、エンジニア間のコラボレーションを促進させる必要性はどこの企業も感じているようです。 また、バレットグループの成長のためには技術に加えて、その技術を活用できる優秀なエンジニアが必要です。 素晴らしいエンジニアをバレットグループに迎えるために、人材採用にエンジニアの観点からよりコミットしたいと考えています。</p> <h4 id="ビジネスサイドと技術サイドのコラボレーション促進">④ビジネスサイドと技術サイドのコラボレーション促進</h4> <p>ビジネスニュースを見ていて「DX」という言葉を聞かない日はありません。 ビジネスサイドがビジネスのプロフェッショナルであるように、技術サイドはエンジニアリングのプロフェッショナルでなければなりません。 プロフィット部門のコスト削減や・品質改善・トイル<a href="#f-74e0cc37" name="fn-74e0cc37" title="手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業のこと。元々はSRE用語">*1</a>の撲滅などを行い、メンバーが本来の業務に注力できるようにすることで会社の利益に貢献します。 「コーポレイトIT室はコストセンターだから・・・」と言われたくないという思いは強いです。</p> <h3 id="私の業務">私の業務</h3> <p>このように、コーポレイトIT室は広範かつ重要な業務を行います。以下は私がコーポレイトIT室で実施した業務の一例です。 セキュリティ関連の業務が目立つかもしれませんが、これは私が”情報処理安全確保支援士”(通称”登録セキスペ”)であることも起因します。 セキュリティのスペシャリストとしての役割が特に期待されていると考えているため、不足している施策を思いついては対応しています。</p> <ul> <li>従業員のセキュリティレベル把握のため、e-learningの結果をGoogle Colaboratoryを用いてデータ分析</li> <li>ゼロトラストセキュリティを導入するための手順の作成と利用するソリューションの選定</li> <li>従業員のセキュリティ教育方針の決定</li> <li>セキュリティ啓蒙のためのプレゼン資料と動画の作成</li> <li>提供サービスのSLOの策定</li> <li>地方拠点のネットワーク機器を収納するラックの組み立てとラッキング</li> <li>上記タイミングで地方メンバーに業務内容をヒアリング&業務改善ツールの作成</li> <li>沖縄バックアップセンターからAWSへのデータ復元手順の改良</li> <li>グループメンバーが横断して交流できるコミュニケーションツールの導入と社内への宣伝</li> <li>エンジニア向け社内勉強会の実施</li> <li>🆕カラフルバレットの記事更新</li> </ul> <p><strong>「コーポレイトIT室はバレットグループの技術のハブになる」</strong>を口癖としています。その実現のためにはコードも書きますし、クラウドも触ります。ただデザインは範囲外。 しかしコーポレイトIT室にはカラフルバレットをデザインリニューアルしてくれたmaripigさんがいます。maripigさんはHTML/CSSのようなコーディングだけでなく、イラストや動画の作成もどんと来いなのです。いつも助けてもらっています(今回の記事でもサムネイルとなる画像を差し込んでいただきました🙏)</p> <p>コーポレイトIT室はこれからもメンバーで力を合わせてバレットグループの成長をサポートしていきます。コーポレイトIT室の活動を社内にもっと周知して、バレットグループの”技術の駆け込み寺”と認知して欲しいと思っています。</p> <div class="footnote"> <p class="footnote"><a href="#fn-74e0cc37" name="f-74e0cc37" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業のこと。元々はSRE用語</span></p> </div> Usek Colorful Bullet リニューアルしました! hatenablog://entry/4207112889926772613 2022-10-12T14:24:52+09:00 2022-10-12T14:25:43+09:00 皆さんこんにちは!コーポレイトIT室(通称:CIT)でブランディングチームに所属しているmaripigです。 2019年からスタートしたこの技術ブログColorfulBulletですが、私たちの所属するバレットグループ株式会社が来年10周年という節目を迎えるにあたりこちらのブログデザインを一新することになりました^^ 今回は本ブログのリニューアルを担当した私が、「コンセプト設計」と「はてなブログテーマのカスタマイズ方法」に焦点をあててお話ししたいと思います。 コンセプト設計 まずはキーワードを整理 リニューアルの方向性として挙げられていた要望 変更点として意識したいと思ったポイント イメージの… <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20220930/20220930145830.jpg" width="1000" height="520" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span> 皆さんこんにちは!コーポレイトIT室(通称:CIT)でブランディングチームに所属しているmaripigです。<br> 2019年からスタートしたこの技術ブログColorfulBulletですが、私たちの所属するバレットグループ株式会社が来年10周年という節目を迎えるにあたりこちらのブログデザインを一新することになりました^^</p> <p>今回は本ブログのリニューアルを担当した私が、「コンセプト設計」と「はてなブログテーマのカスタマイズ方法」に焦点をあててお話ししたいと思います。</p> <ul class="table-of-contents"> <li><a href="#コンセプト設計">コンセプト設計</a><ul> <li><a href="#まずはキーワードを整理">まずはキーワードを整理</a><ul> <li><a href="#リニューアルの方向性として挙げられていた要望">リニューアルの方向性として挙げられていた要望</a></li> <li><a href="#変更点として意識したいと思ったポイント">変更点として意識したいと思ったポイント</a></li> </ul> </li> <li><a href="#イメージの収集">イメージの収集</a><ul> <li><a href="#画像の収集">画像の収集</a></li> <li><a href="#カラー選定">カラー選定</a></li> <li><a href="#フォント選定">フォント選定</a></li> </ul> </li> <li><a href="#コンセプトボードへ">コンセプトボードへ</a></li> </ul> </li> <li><a href="#はてなブログのテーマカスタマイズ">はてなブログのテーマカスタマイズ</a><ul> <li><a href="#はじめに">はじめに</a></li> <li><a href="#デザインカスタマイズページで設定したこと">デザインカスタマイズページで設定したこと</a><ul> <li><a href="#ヘッダ">ヘッダ</a></li> <li><a href="#サイドバー">サイドバー</a></li> <li><a href="#フッタ">フッタ</a></li> </ul> </li> <li><a href="#管理画面で設定したこと">管理画面で設定したこと</a><ul> <li><a href="#ブログアイコン">ブログアイコン</a></li> <li><a href="#アイキャッチ画像">アイキャッチ画像</a></li> <li><a href="#トップページでの表示形式PRO">トップページでの表示形式<PRO></a></li> <li><a href="#ヘッダとフッタPRO">ヘッダとフッタ<PRO></a></li> <li><a href="#webフォントの読み込み">webフォントの読み込み</a></li> </ul> </li> <li><a href="#デザインCSS">デザインCSS</a><ul> <li><a href="#一覧画面カードデザインの要素の順番変更">一覧画面:カードデザインの要素の順番変更</a></li> <li><a href="#フッタに画像を入れたい">フッタに画像を入れたい</a></li> </ul> </li> </ul> </li> <li><a href="#まとめ">まとめ</a></li> </ul> <h2 id="コンセプト設計">コンセプト設計</h2> <p>今回のリニューアルでは、まずデザインの軸となる<strong>コンセプトボード</strong>の作成から入りました。<br> 普段デザインをする際は参考イメージやカラー設定などを初めにすることはあっても、コンセプトボードの作成まではなかなかしていませんでしたが今回はいざ始めようと思ったときに方向性で結構悩んでしまい中々作業が進まなかったので、頭の中を整理する意味で作成することにしました。</p> <h3 id="まずはキーワードを整理">まずはキーワードを整理</h3> <p>頭の中でぼんやり考えていたことを言語化していきます。</p> <h4 id="リニューアルの方向性として挙げられていた要望">リニューアルの方向性として挙げられていた要望</h4> <ul> <li>白を基調とした清潔感のあるデザイン</li> <li>アメリカ西海岸風のテイスト</li> </ul> <h4 id="変更点として意識したいと思ったポイント">変更点として意識したいと思ったポイント</h4> <ul> <li>バレットグループのロゴとの親和性を高めて、以前よりも「<strong>バレットグループの</strong>テックブログ」であることがデザインからも伝わるようにしたい</li> <li>愛着のある「カラカバくん」は活かしたい</li> <li>カテゴリとタグの整理をして情報を見つけやすくしたい(余計なものは削ぎ落とす=サイドバーは不要かも)</li> </ul> <p>言葉にして整理するだけで、だいぶ頭の中がスッキリしますよね。<br> キーワードを抽出しないと、この後のイメージ収集が難航するので大事な工程です。</p> <h3 id="イメージの収集">イメージの収集</h3> <p>キーワードが揃ったらイメージを収集していきます。</p> <h4 id="画像の収集">画像の収集</h4> <p>イメージ画像の収集は pinterest さんにお世話になってます。<br> デザイナーにはお馴染みのサービスだと思いますが、近いイメージが見つかったらそこから類似した画像をどんどん辿っていけるので方向性を固めていくのに非常に重宝しますよね。</p> <p>その他では Shutterstock でキーワード検索してみたり。<br> 画像がある程度集まってきたら、そこからカラー選定とフォント選定を進めていきます。</p> <h4 id="カラー選定">カラー選定</h4> <p>まず「白が基調であること」「ロゴとの親和性を高めたい」この2点があるのでモノトーンベースは前提として、「西海岸風」「清潔感」のイメージに合う<strong>ブルー</strong>は使いたいと思いました。<br> ブルーを選定したら、これらにあうアクセントカラーも選定。<br> 今回ブログのカテゴリを3つに絞ろうと考えていたのでプラス2色、オレンジとグリーンを選びました。</p> <h4 id="フォント選定">フォント選定</h4> <p>デザインの要ともなる英字フォントから選定。<br> ロゴとの親和性も高く、西海岸風のイメージもあるハンドスクリプト系かつボールド系のフォントをまず探しました。<br> また、ハンドスクリプト系だけでは視認性で劣る部分があるので、インパクト系のゴシックフォントも。<br> できればwebフォントとしてあるものを使用したかったのでGoogleフォントで検索。<br> 下記を選びました<br></p> <ul> <li>ハンドスクリプト系:Yellowtail <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006112718.png" width="1200" height="148" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></li> <li>インパクト系:Oswald <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006112723.png" width="1200" height="129" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></li> </ul> <p>数字や記号の見え方もチェックして選ぶと良いと思います!<br> 次にそれらにあう日本語フォントを選定。</p> <ul> <li>Zen Kaku Gothic New <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006112941.png" width="1200" height="390" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></li> </ul> <p>※ブログでは使用しませんでしたが、その他のクリエイティブに使用予定</p> <h3 id="コンセプトボードへ">コンセプトボードへ</h3> <p>あとはここまで集めた素材たちを任意のボードに張り付けて、コンセプトボードとしてまとめます。 私はXDで適当なボードを作って、そこに貼り付けて作ってます。<br> <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006113155.png" width="1200" height="807" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span> コンセプトボード完成!<br> やはり、ここまでまとめると方向性が明確になりますね!<br> これをもとにこのあとデザインを作成しましたが、指標があるのでとても進めやすかったです。<br> また、チームで作業するときやデザイン経験の少ない依頼者との認識合わせにも役立つのでそういったシチュエーションで制作する際には特におすすめですね。</p> <h2 id="はてなブログのテーマカスタマイズ">はてなブログのテーマカスタマイズ</h2> <p>デザインが完成したらいよいよテーマのカスタマイズへ。<br> ブログ立ち上げ当初のデザイン&実装も自分が担当したのですが、当時はまだコーディング学びたてだったのでカスタマイズするほどの自信はなく既存テーマを使って背景画像などの変更を行うまででした。<br> あれから3年、ある程度のコーディング経験も積みましたので今回はテーマのカスタマイズに挑戦しました!</p> <h3 id="はじめに">はじめに</h3> <p>まずは公式のデザインテーマ制作の手引きにもあるとおり、公開範囲を自分のみにしたブログを新たに作成しサンプル記事を作成します。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fhelp.hatenablog.com%2Fentry%2Ftheme%2Fcustom-theme" title="デザインテーマ制作の手引き - はてなブログ ヘルプ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://help.hatenablog.com/entry/theme/custom-theme?_ga=2.57665187.800226881.1665024084-1553181025.1662084987">help.hatenablog.com</a></cite> ある程度スタイルの入った状態からカスタマイズしたかったので、公式でカスタマイズ用に公開しているBoilerplateテーマをダウンロードするところからスタートしました。<br> ダウンロードしたCSSをまずは適用して表示を確認し、いよいよカスタマイズスタートです!</p> <h3 id="デザインカスタマイズページで設定したこと">デザインカスタマイズページで設定したこと</h3> <p>cssをカスタマイズする前に、まずはカスタマイズページで設定できるところから行っていきます。 今回変更したのは以下の項目です。</p> <h4 id="ヘッダ">ヘッダ</h4> <ul> <li>ロゴ画像をアップロード</li> <li>表示設定を画像のみにする</li> </ul> <h4 id="サイドバー">サイドバー</h4> <ul> <li>モジュールの削除</li> </ul> <p>モジュールを選択して挿入することもできますが、カテゴリなどはオリジナルのフッターに入れようと思っていたのであらかじめ入っていたものは全て削除しました</p> <h4 id="フッタ">フッタ</h4> <ul> <li>HTMLコード貼り付け</li> </ul> <p>今回オリジナルのフッタを作成しているので、HTMLコードをここに貼り付けています。<br></p> <blockquote><p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006140810.png" width="1200" height="444" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p></blockquote> <h3 id="管理画面で設定したこと">管理画面で設定したこと</h3> <p>ついでに管理画面で設定できることも変更しておきましょう。<br> 今回設定したのは以下の項目です。</p> <h4 id="ブログアイコン">ブログアイコン</h4> <p>設定>基本設定 の中にあります。</p> <h4 id="アイキャッチ画像">アイキャッチ画像</h4> <p>設定>詳細設定 の中にあります。<br> アイキャッチのない記事での自動設定もチェックを入れておきました!</p> <blockquote><p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006131128.png" width="1200" height="502" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p></blockquote> <h4 id="トップページでの表示形式PRO">トップページでの表示形式<PRO></h4> <p>設定>詳細設定 の中にあります。PRO版のみ設定可能のようです。<br></p> <ul> <li>一覧表示 に設定</li> </ul> <h4 id="ヘッダとフッタPRO">ヘッダとフッタ<PRO></h4> <p>設定>詳細設定 の中にあります。PRO版のみ設定可能のようです。<br></p> <ul> <li>ブログにヘッダを表示しない に設定</li> <li>ブログにフッタを表示しない に設定</li> </ul> <p>ここでいうフッタは↓この部分↓のようです。<br></p> <blockquote><p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006131911.png" width="1200" height="68" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p></blockquote> <h4 id="webフォントの読み込み">webフォントの読み込み</h4> <p>設定>詳細設定>head内タグ という項目の中の図の部分にGooglefontの読み込みタグを設置しました。</p> <blockquote><p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20221006/20221006132024.png" width="1200" height="359" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p></blockquote> <h3 id="デザインCSS">デザインCSS</h3> <p>cssのカスタマイズについて詳細をここで書いても仕方ないかとは思うので、ここはちょっと戸惑ったな・・・というポイントを解説しておきます。</p> <h4 id="一覧画面カードデザインの要素の順番変更">一覧画面:カードデザインの要素の順番変更</h4> <p>HTMLを変更できない場合、要素の順番変更って「どうするんだ。。。」ってなりました・・・が、こういった場合便利なのが flexbox ですよね!<br></p> <ul> <li>flex-direction で順番をHTML要素の並びとは逆順に変更<br> <code>flex-direction: column-reverse;</code></li> </ul> <p>また、サムネイルは一番上にしたかったので order を使って並べ替えも行っています。</p> <ul> <li>サムネイルは <code>order: 1;</code></li> <li>サムネイル以外は<code>order: 0;</code></li> </ul> <h4 id="フッタに画像を入れたい">フッタに画像を入れたい</h4> <p>今回作成したオリジナルのフッタには画像がいくつか配置されています。<br> はじめは「どこに画像をアップロードすれば・・・」と戸惑いましたが、はてなフォトライフというサービスで画像をアップロードすれば良いようです。 この存在に気づいたものの、貼り付けるURLがわからない・・・orz<br> 結局サンプル記事に貼り付けて、公開した記事のURLを確認してコピペしました。(もしかしたらもっとちゃんとした方法があるのかも?)<br> おそらくURLはこんな感じです↓<br></p> <pre><a href="https://cdn-ak.f.st-hatena.com/images/fotolife/">https://cdn-ak.f.st-hatena.com/images/fotolife/</a>アカウントの頭文字?/アカウント名/年月日/ファイル名(記事に貼り付けた時に出る14桁の数字).拡張子</pre> <h2 id="まとめ">まとめ</h2> <p>ブログリニューアルについてざっと書いてみましたがいかがでしたでしょうか。<br> 今後記事をあげていく中でまた気になる点も出てくるだろうと思うので、ちょこちょこアップデートしていこうと思います。<br> 今回の記事が少しでもどなたかの参考になれば嬉しいです。<br> 最後まで読んでいただきありがとうございました!それではまた٩( ᐛ )و</p> maripig61 社内読書会で読んだ書籍を紹介します hatenablog://entry/13574176438054711132 2022-03-02T15:00:00+09:00 2022-10-11T12:36:25+09:00 Technology&Design部(T&D部)SREチームのUsekです。2022年もカラフルバレットをよろしくお願いします。 T&D部では読書会を定期的に開催しています。 思い返すと私がバレットグループにアサインした初日、18時になるとメンバーがフリースペースに移動し始め、いったい何が始まるのかと聞くと「情熱プログラマーの読書会があるんだよ」と回答をいただき、バレットグループのメンバーの向上心の高さを感じました。 IT企業では読書会が盛んに開催されていますが、自分も参加することで、以下のようなメリットがあることが分かりました。 一人で読書するよりモチベーションが高まる 自発的に何冊、何十冊… <p>Technology&Design部(T&D部)SREチームのUsekです。2022年もカラフルバレットをよろしくお願いします。</p> <p>T&D部では読書会を定期的に開催しています。 思い返すと私がバレットグループにアサインした初日、18時になるとメンバーがフリースペースに移動し始め、いったい何が始まるのかと聞くと「<a href="https://shop.ohmsha.co.jp/shopdetail/000000001848/">情熱プログラマー</a>の読書会があるんだよ」と回答をいただき、バレットグループのメンバーの向上心の高さを感じました。</p> <p>IT企業では読書会が盛んに開催されていますが、自分も参加することで、以下のようなメリットがあることが分かりました。</p> <p><strong>一人で読書するよりモチベーションが高まる</strong></p> <p>自発的に何冊、何十冊と本を読める人もいるかもしれませんが、残念ながら自分はそうではありません(笑) しかし読書会という場を設けられることで動機が生まれ、またモチベーションにも繋がり、結果たくさんの本を読むことができました。</p> <p><strong>自分には無い気付きを得ることができる</strong></p> <p>読書会のスタイルはいくつかありますが、T&D部では事前に1章を読んだ上でその感想を話し合う形式を採用しています。 感想会では自分では思いつかなかった考え方や価値観、自分とは正反対の意見を聞くことができました。 自分の中で間違えて覚えていた知識の訂正や、既に古くなった情報のアップデートなどもあり有意義でした。</p> <p><strong>業務では関わらないメンバーとコミュニケーションできる</strong></p> <p>T&D部内でもチーム外メンバーのコミュニケーションはどうしてもチーム内メンバーより不足してしまいます。 普段業務に関係しない内容の書籍をテーマとした読書会に参加することは、普段関わりのないメンバーと交流を深める機会でもあります。 話が脱線すると結果として「この人こういう趣味の人なんだ」という意外な発見もあります。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20220120/20220120131413.png" width="338" height="400" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>読書会での交流がきっかけでDevチームのメンバーからボルタリングに誘ってもらえました😄</p> <p>今回はT&D部で2021年に読んだ書籍を皆さんに紹介します。</p> <h4 id="SRE-サイトリライアビリティエンジニアリング">SRE サイトリライアビリティエンジニアリング</h4> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.oreilly.co.jp%2Fbooks%2F9784873117911%2F" title="SRE サイトリライアビリティエンジニアリング" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.oreilly.co.jp/books/9784873117911/">www.oreilly.co.jp</a></cite></p> <p>私の所属するSREチームの名前の基にもなっている”SRE”(Site Reliability Engineering)はGoogleが提唱した用語です。 その名の通りサイト(サーバ、サービスとも言い換えることができるでしょう)の信頼性のためのエンジニア活動と言えます。 それだけですと伝統的なインフラエンジニアとあまり変わらないように聞こえますが、SREの取り扱う業務はもっと広範囲にわたります。 インフラの構築はもちろん、そのインフラの運用保守、障害対応、そして古い世代の私にとっては「それはソフトウェアエンジニアの役割では・・・?」と思うような開発環境の構築など、さまざまな事象に対応します。 インフラを自動で運用する目的でコーディングも行うため、ソフトウェアエンジニアリングの知見も必要になります。 この本は<a href="https://sre.google/sre-book/introduction/">GoogleがSREについて説明した英文</a>が翻訳されたものとなります。 Googleの過去の経験に基づいた大規模データセンター内の活動など、一般企業には適用しづらい実例もありますが、参考になる事例も多く紹介されています。 T&D部もこの本の内容を業務に反映させました。例えば</p> <ul> <li>「<a href="https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles">トイル</a>」について、私たちの日々の業務でも「これはトイルではないか」「トイルを撲滅しなければ」が合言葉になった</li> <li>インシデントが発生した際には処置完了後、必要に応じてポストモーテムを作成するようになった</li> <li>GitHub Actionsによるデプロイの自動化、Terraformによるインフラ構築の自動化を実施した</li> </ul> <p>などが挙げられます。</p> <h4 id="テスト駆動開発">テスト駆動開発</h4> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.amazon.co.jp%2F%25E3%2583%2586%25E3%2582%25B9%25E3%2583%2588%25E9%25A7%2586%25E5%258B%2595%25E9%2596%258B%25E7%2599%25BA-Kent-Beck%2Fdp%2F4274217884" title="テスト駆動開発 | Kent Beck, 和田 卓人 |本 | 通販 | Amazon" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.amazon.co.jp/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA-Kent-Beck/dp/4274217884">www.amazon.co.jp</a></cite></p> <p>こちらは開発チームが主催した読書会でしたが、私もテスト駆動開発という概念に興味を持っていたため勉強のため参加しました。 結論から言うと、今までその概念を「素晴らしい発想の転換」と思っていたテスト駆動開発ですが、いざ自分が手を動かしてみると途中からはちんぷんかんぷんでした😅 redをgreenにする作業がゲーミフィケーション的な要素によりコーディングの楽しさも生まれ、モチベーション維持につながるのかもしれないと思う一方で、章が進むほどにプログラミングというよりパズルをやっているような気持ちになってきて、”何故わざとわざわざ通らないことがわかっているテストを書かなければいけないのか”などが納得できず、テスト駆動開発の文化に染まることはできませんでした。 あとケント=ベック氏の独特な婉曲的な言い回し(海外の文章ではこういうのは普通だったりするのでしょうか)が却って理解を難解にさせているように思えます。</p> <p>ただ、自分一人でこの本を読んだら絶対に序盤で挫折していましたが、周囲の仲間が理解できない箇所をアドバイスしてくれるなどのサポートのおかげで最後まで進むことができました。 これも社内勉強会の良いところだと思います。</p> <h4 id="Web配信の技術">Web配信の技術</h4> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgihyo.jp%2Fbook%2F2021%2F978-4-297-11925-6" title="Web配信の技術 ―HTTPキャッシュ・リバースプロキシ・CDNを活用する" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://gihyo.jp/book/2021/978-4-297-11925-6">gihyo.jp</a></cite></p> <p>CloudFrontや静的サイトホスティングなど、私たちの業務になくてはならない配信技術。配信とは広義ではキャッシュとも言えますが、現代のインターネットにおいてキャッシュは最重要要素であることがよく分かる本でした。 最初はインターネットの構造について説明がありますが、Webアプリやクラウドを利用して日々業務を行なっているメンバーにもイメージが付きにくいインターネットを理解できたと好評でした。 キャッシュに対する理解を深め、アプリケーション側でヘッダの設定を行えば、今までnginxなどのWebサーバのリバースプロキシ機能がよしなに行ってくれていたキャッシュ機能もより高度なチューニングができるようになります。 本の中で紹介されていた情報を基に、自社サービスやコーポレートサイトの設定を確認し、コンテンツのキャッシュ比率の調査やマネージドサービスを利用したコンテンツ表示時間短縮の検討など、読書会の内容をチームの業務にフィードバックすることができました。</p> <h4 id="Linuxのしくみ">Linuxのしくみ</h4> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgihyo.jp%2Fbook%2F2018%2F978-4-7741-9607-7" title="[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://gihyo.jp/book/2018/978-4-7741-9607-7">gihyo.jp</a></cite></p> <p>AWSやコンテナ技術を利用して業務を行うからには避けては通れないLinux。そのLinuxについて改めて理解しようという理由でこちらの本をチョイス。 「デバイスドライバ」「カーネル」「システムコール」など『聞いたことあるけど・・・』な用語や、これまで考えたことがなかったコンピュータの低レイヤの部分を知ることができました。 パフォーマンス向上のために、Linuxでもストレージにデータを保存せず、キャッシュ目的でメモリにデータを保存する技が使われていることを知り、Web配信の技術と共通点を見出しました。技術は突然変異で現れるのは稀で、既存のテクノロジーを参考にしている、異なる分野でも類似した技術が利用されているものなのだと思いました。 コアCPUがn個あれば性能はn倍というのはあくまで最良ケース。パソコンショップの店員にはもう騙されません(笑)</p> <h4 id="Real-World-HTTP">Real World HTTP</h4> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.oreilly.co.jp%2Fbooks%2F9784873119038%2F" title="Real World HTTP 第2版" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.oreilly.co.jp/books/9784873119038/">www.oreilly.co.jp</a></cite></p> <p>我々の生活になくてはならないインターネット、その根幹を担うプロトコルであるHTTPとその周りの技術について広範に説明している書籍になります。 この本を読んで「自社のWebサービスで実装されているとある機能は、この技術を利用したものでは?」と開発チームメンバーに質問して「その通り」と回答がもらえてとても嬉しかったです(笑) 鍵交換による公開鍵認証方式やSSLアクセラレータなど、昔は試験問題に出てくる「お約束」の要素も現在は非推奨や不要になっており、知識は随時学びアップデートしていかないと、時代遅れになってしまうと痛感しました。 SSLもHTTPも、インターネット上でやりとりされるデータ量の爆発的増加という需要に対して、回線帯域の拡張とテクノロジーの進歩によりどんどん形が変わっているのですね。感動しました。</p> <p>とにかくボリュームのある本で、網羅している分野も高レイヤーから低レイヤー、プロトコルやフレームワーク、ハードウェアにセキュリティとさまざま。一度読んで内容を全て覚えるのは不可能でしょう。仕事の中でふと「そういえばあの本に言及があったような・・・」と思い出すために使えそうです。 この本を読むとSRE本と同じ感想を持ちます。すなわち、現代ではソフトウェアとインフラの両者の領域は溶け合っており、両方の知識が必要になるということです。</p> <p>いかがでしたでしょうか。 こうやって振り返るとさまざまな分野の書籍を読んできました。一人では絶対にチョイスしない書籍に出会えるのもまた社内読書会の大きな利点ではないでしょうか。 2022年1月現在も、昨年末から始めた<a href="https://www.amazon.co.jp/AWS%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E8%A8%AD%E8%A8%88%E3%83%BB%E6%A7%8B%E7%AF%89-%E6%9C%AC%E6%A0%BC-%E5%85%A5%E9%96%80-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E9%87%8E%E6%9D%91%E7%B7%8F%E5%90%88%E7%A0%94%E7%A9%B6%E6%89%80/dp/4815607656">AWSコンテナ設計・構築[本格]入門</a>を読んでいます。こちらの紹介も今後できればと思います。</p> <h5 id="ITエンジニア本大賞2022">ITエンジニア本大賞2022</h5> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.shoeisha.co.jp%2Fcampaign%2Faward%2F" title="ITエンジニア本大賞2022" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.shoeisha.co.jp/campaign/award/">www.shoeisha.co.jp</a></cite></p> <p>今年で9回目になるITエンジニア向けおすすめ本を投票する企画です。こちらで選ばれた本も今後の読書会で採用したいと思います。</p> Usek 優れたUIデザインを設計するために、いま出来る3つのこと。 hatenablog://entry/26006613640089183 2022-02-16T15:00:00+09:00 2022-10-12T14:00:09+09:00 皆さんこんにちは! Technology & Design 部のデザインチームに所属している、かみしろです。 前回に引き続き、UI(UX)ネタについて書いていきます。 前回の記事はこちら→(【2行読めばOK!】UI/UXについて「ちょっと」だけ理解する。) サイトやアプリ制作においてUIデザインって大事!って聞くけど UIデザインってセンスがある人じゃないと出来ないんじゃないの?って 思っている方いると思います。(私もそうでした。) そんな方のために! 今回は、優れたUIデザイン設計をするために、いま出来る3つのことについて紹介します。 結論から書きます。 優れたUIデザインを設計するために、… <p>皆さんこんにちは! <br> Technology &amp; Design 部のデザインチームに所属している、かみしろです。</p> <p>前回に引き続き、UI(UX)ネタについて書いていきます。<br></p> <p style="font-size:12px;">前回の記事はこちら→(<a href="/entry/2021/01/12/090000">【2行読めばOK!】UI/UXについて「ちょっと」だけ理解する。</a>)</p> <p>サイトやアプリ制作においてUIデザインって大事!って聞くけど<br> UIデザインってセンスがある人じゃないと出来ないんじゃないの?って<br> 思っている方いると思います。(私もそうでした。)</p> <p>そんな方のために!<br> 今回は、優れたUIデザイン設計をするために、いま出来る3つのことについて紹介します。<br></p> <p>結論から書きます。<br> 優れたUIデザインを設計するために、いま出来る3つのことって?</p> <div style="border:2px solid #cccccc; border-radius:10px; margin:15px 0;padding:15px 10px;"> <ul>  <li>様々なUIを実際に体験してみる</li>  <li>UIの知識をインプットする</li>  <li>UIについてのブレストを行う</li> </ul> </div> <p>次から具体的に書いていきます。<br> 気力のある方はぜひ読んでみてください!<br></p> <h1 id="様々なUIを実際に体験してみる" style="border-left:3px solid #59CACC; text-indent:10px;">様々なUIを実際に体験してみる</h1> <p>「優れたUI」を実現するためには、自分自身がUIを体験することが重要です。<br> 他社が制作したサイトやアプリを使ってみましょう。</p> <p>ほしい情報がすぐに見つかって分かりやすい。<br> ボタンが押しにくい、どれがボタンが分かりにくい。など<br> 体験することで得られる情報があると思います。<br></p> <p>可能ならば、閲覧しているサイトやアプリのターゲットになったつもりで<br> 使ってみると尚更良いかと思います。</p> <h1 id="UIの知識をインプットする" style="border-left:3px solid #59CACC; text-indent:10px;">UIの知識をインプットする</h1> <p>UIデザインはセンスで作り上げるものではなく、<br> 論理的に組み立てるものだと思っています。</p> <p>優れたUIには規則やルールがあります。<br> 「UIデザイン ルール」「UIデザイン ポイント」などのワードで調べれば<br> 分かりやすい記事がたくさん出てくるのでぜひ調べてみてください。</p> <h1 id="UIについてのブレストを行う" style="border-left:3px solid #59CACC; text-indent:10px;">UIについてのブレストを行う</h1> <p>先ほどまでインプットの方法について紹介してきましたが、<br> せっかく身に付けた知識です。<br> アウトプットして更に自身のレベルアップを図ってみましょう。</p> <p>普段一緒に働いている仲間でもいいです。<br> サイトやアプリを題材にして、UIについてブレストしてみましょう。<br> (ブレストすることでUXについても学べます!)</p> <p>他者の意見を聞くことで、新たな気付きが生まれたり、自身の視野も広がります。<br> 話す機会を設けることで、論理的にデザインを説明する練習も出来ます!</p> <h1 id="まとめ" style="border-left:3px solid #59CACC; text-indent:10px;">まとめ</h1> <p>優れたUIデザインを設計するために、今すぐ出来る3つのことって?</p> <div style="border:2px solid #cccccc; border-radius:10px; margin:15px 0;padding:15px 10px;"> <ul>  <li>様々なUIを実際に体験してみる</li>  <li>UIの知識をインプットする</li>  <li>UIについてのブレストを行う</li> </ul> </div> <p>UIデザインの設計は誰にでも出来ます。<br> あまり難しく考えず、まずはインプットを繰り返してUIの知識を蓄積してみましょう!<br> (私も絶賛勉強中!)<br> 最後まで読んでいただきありがとうございました!</p> m9kami 2021年におこなったコミュニケーションカイゼン hatenablog://entry/13574176438040124009 2021-12-29T15:00:00+09:00 2022-10-11T12:38:41+09:00 すでにタイトルを書くだけでドキドキしている id:hokupod です。 Technology & Design という部署でエンジニアリングマネジメントを担当しています。役職としてはマネジャーです。 エンジニアリングマネジメントの経験としては、1年ほどかと思います。 チームは 10 名ほどの小さいチームです。 どうぞ最後までお付き合いください。 自分を知ってもらう Scrapbox ポッドキャスト ザッソウ部屋の開設 1on1 の実施 ふりかえりの導入 勉強会の開催 AWS Black Belt 試聴会 読書会 おわりに 開始早々謝罪になりますが、なにも土台がない状態から手探りでここまでやっ… <p>すでにタイトルを書くだけでドキドキしている <a href="http://blog.hatena.ne.jp/hokupod/">id:hokupod</a> です。<br /> Technology &amp; Design という部署でエンジニアリングマネジメントを担当しています。役職としてはマネジャーです。<br /> エンジニアリングマネジメントの経験としては、1年ほどかと思います。<br /> チームは 10 名ほどの小さいチームです。</p> <p>どうぞ最後までお付き合いください。</p> <ul class="table-of-contents"> <li><a href="#自分を知ってもらう">自分を知ってもらう</a><ul> <li><a href="#Scrapbox">Scrapbox</a></li> <li><a href="#ポッドキャスト">ポッドキャスト</a></li> </ul> </li> <li><a href="#ザッソウ部屋の開設">ザッソウ部屋の開設</a></li> <li><a href="#1on1-の実施">1on1 の実施</a></li> <li><a href="#ふりかえりの導入">ふりかえりの導入</a></li> <li><a href="#勉強会の開催">勉強会の開催</a><ul> <li><a href="#AWS-Black-Belt-試聴会">AWS Black Belt 試聴会</a></li> <li><a href="#読書会">読書会</a></li> </ul> </li> <li><a href="#おわりに">おわりに</a></li> </ul> <p>開始早々謝罪になりますが、なにも土台がない状態から手探りでここまでやってきてます。<br /> エンジニアみなさまの役に立つため、日々精進しております。 こうした方が良さそうなどございましたら、ぜひ教えていただけますと嬉しいです。</p> <h1 id="自分を知ってもらう">自分を知ってもらう</h1> <p><figure class="figure-image figure-image-fotolife" title="自己紹介をする私"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hokupod/20211222/20211222215641.png" width="800" height="800" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>自己紹介をする私</figcaption></figure> まず取りかかったのは、これでした。<br /> 一体私は何者なのかをエンジニアのみなさまが知らないと、会話が弾まない。<br /> 知らないものに触れるのって、怖くないですか?私は怖いです。</p> <p>ということで、いくつか発信をおこなうことにしました。</p> <h2 id="Scrapbox"><a href="https://scrapbox.io/hokupod/">Scrapbox</a></h2> <p>本来はノウハウを溜めるためのツールになりますが、私は日記として利用しています。<br /> たまにメモも入れちゃってますが。<br /> 前々から、やっていれば良かったのでは?と言いたい気持ちはわかります。</p> <h2 id="ポッドキャスト"><a href="https://anchor.fm/yowayowafm">ポッドキャスト</a></h2> <p>日記をやっていく内に、<strong>仕事中にラフに聞ける</strong>ものを用意出来たらいいなと思い始めました。<br /> そこで着手したのがポッドキャストです。<br /> トークの中で、なにに課題を持っていて、今なにが熱いと感じているのかを知ってもらえたらと思って続けています。<br /> ポッドキャストを始めることで、<strong>日記が徐々に更新されなく</strong>なっていったことには触れないでください。</p> <h1 id="ザッソウ部屋の開設">ザッソウ部屋の開設</h1> <p>出社していたとき同様に<strong>ザッソウ(雑談の中で相談)が可能な状態</strong>を作りたいと思い、Discord サーバを建てました。<br /> 意識的に集まれるようチームで相談し、<strong>毎日 16 時からをザッソウタイム</strong>としています。<br /> 時刻になると Slackbot が教えてくれるので、集まりやすいです。 <figure class="figure-image figure-image-fotolife" title="Slackbot による通知"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hokupod/20211222/20211222194629.png" width="856" height="127" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Slackbot による通知</figcaption></figure></p> <p>サーバアイコンは個人的にお気に入りの <strong>TD 子</strong>です。このファンキーさ素晴らしすぎます。 <figure class="figure-image figure-image-fotolife" title="TD 子(実際には頭だけをアイコンとして使用しています)"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hokupod/20200824/20200824103427.png" width="841" height="1024" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>TD 子(実際には頭だけをアイコンとして使用しています)</figcaption></figure></p> <h1 id="1on1-の実施">1on1 の実施</h1> <p>上期は隔週30分、下期は毎週15分で続けています。<br /> リモートがメインとなり、直接会話する機会も減ったため、まずは<strong>回数を重ねお互いを知る</strong>ことが大切だと考え頻度を増やした形です。</p> <p>話す内容は、事前に決めておく形ではなく、その場その場で話したいことを主題としています。<br /> そうすることで<strong>今一番重要だと感じていること</strong>に時間が割けます。<br /> また業務報告で終わらないよう「今一番頭の中を占めているものをいくつかあげていただけますか?」と確認するようにしています。</p> <p>他にも自身で気をつけていることを列挙します。</p> <ol> <li>極力傾聴する</li> <li>伝える際は、どういったことを期待しているのかも含めて伝える</li> <li>翌週までの宿題を用意して、再度話を聞く</li> <li>宿題が体制面に及ぶ場合は、ToDo に追加して翌週までに答えを用意する</li> </ol> <p>あと、、、本音でぶつかる。<br /> 私自身がいい感じに振る舞えるタイプの人間であればよいのですが、どうも性に合わないので大分人間味が出ます。<br /> 1on1 に向いていないのでは?とも当然思うのですが、<strong>自己開示をして安心感</strong>を与えることも必要だと考えています。 <br /> アイスブレイクで、家族の話とか出てくると自然と安心感ありますよね。私だけかも知れないですが。</p> <h1 id="ふりかえりの導入">ふりかえりの導入</h1> <p>日々のメンバーの取り組みをみんなに知って欲しい、またメンバーの中で取り組みをカイゼンしていく輪をつくりたいという思いから、ふりかえりを導入しました。 具体的な手法につきましては、ふりかえりガイドブックを参考にしました。 有名な KPT や YWT だけではなく、ユースケースに応じて様々なふりかえり手法が紹介されておりますのでオススメです。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.seshop.com%2Fproduct%2Fdetail%2F24265" title="アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット | SEshop.com" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.seshop.com/product/detail/24265">www.seshop.com</a></cite></p> <p>弊チームでは、週一回のふりかえりに下記メニューをおこなっています。</p> <ol> <li>テーマの設定/共有</li> <li>みんなで守るお約束の設定/共有</li> <li>メンバーへの感謝を各人伝える</li> <li>Y(やったこと)W(わかったこと)T(YW から出てきた次にやること)</li> <li>このふりかえりで上手くいったこと/カイゼンできることの共有</li> </ol> <p>特に <strong>YW から出てきた次にやること</strong> は、個々人で検討するとただのタスクになりがちなので、チームのカイゼンを意識し参加者全員で検討するようにしています。</p> <p>ふりかえりを導入し、他者のタスクを自分ごととして考えることができ、定期的な開発/仕事の見直しおよび軌道修正、気軽に協力のお願いが行えるようになりました。 忙しいからこそ、立ち止まることの大切さを実感しています。</p> <h1 id="勉強会の開催">勉強会の開催</h1> <p>はじまりは <strong>コミュニケーション回数を増やせたら</strong> といった目的でした。 内容としては、AWS Black Belt の動画の試聴会から読書会へと移っていきました。</p> <h2 id="AWS-Black-Belt-試聴会">AWS Black Belt 試聴会</h2> <p>AWS さんが公開している動画を参加者で見て、どういったサービスに活かせそうか意見をぶつけ合う会です。<br /> 特に普段利用しているサービス以外も知ることで、システムの <strong>提案幅を拡げる</strong> といったことも狙いとしてあります。</p> <p>AWS の資格取得も奨励しているので、後押しにもなっていたら嬉しい限りです。<br /> 以前のブログ記事もありますので、よろしかったら。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2020%2F05%2F11%2F090000" title="弊社のAWS BlackBelt視聴会を紹介します! - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2020/05/11/090000">blog.bltinc.co.jp</a></cite></p> <h2 id="読書会">読書会</h2> <p>AWS Black Belt の動画を見尽くしたこともあり、読書会をおこなうことにしました。<br /> 題材としては、<strong>内容が奥深く、共感者なく勉強するには辛い本</strong> です。<br /> 言語習得のような個人で進められるようなものではなく、チームのみんながいるからこそ続けられる読書会をおこなっています。</p> <p>実際に読んだ本としては、SRE 本や、Web 配信の技術、Linux のしくみ、Real World HTTP などです。<br /> 毎週事前に一章ずつ読んできて、感想を esa に記入しそれを見ながら意見を交わすといった流れでおこなっています。</p> <p>読書会からポストモーテム文化の導入など、実際にカイゼンにむけての行動が行えているのがよい傾向だと考えています。</p> <h1 id="おわりに">おわりに</h1> <p>カイゼンとしておこなった施策の中でも新たにカイゼンが生まれています。<br /> 状況が変わっていく中でも、柔軟に動ける組織でいるためには、日頃のコミュニケーションから生まれる信頼関係が重要だと実感している毎日です。<br /> 小さな組織の話ではありますが、少しでも参考になりましたら幸いです。</p> hokupod 2021年におこなった技術的な改善のふりかえり hatenablog://entry/13574176438042337389 2021-12-22T15:00:00+09:00 2022-10-11T12:40:24+09:00 Technology & Design Department の Engineering Section に所属している水野 (id:zuno_onuz) です。 フルリモートワークを始めてもうすぐ2年が経過しようとしていますが、腰痛に悩み始めてきました。 日々の通勤で結構な運動になっていたことをひしひしと感じるこの頃です。 さて、今回は2021年におこなった業務として、技術的な改善に絞ってふりかえりました。 既にうろ覚えな改善もありますが、先に社員の皆さんと協力して箇条書きしたので、いくつか選択して紹介いたします。どうぞよろしくお願いいたします。 改善したこと ランディングページの配信に静的… <p>Technology &amp; Design Department の Engineering Section に所属している水野 (<a href="http://blog.hatena.ne.jp/zuno_onuz/">id:zuno_onuz</a>) です。<br /> フルリモートワークを始めてもうすぐ2年が経過しようとしていますが、腰痛に悩み始めてきました。<br /> 日々の通勤で結構な運動になっていたことをひしひしと感じるこの頃です。</p> <p>さて、今回は2021年におこなった業務として、技術的な改善に絞ってふりかえりました。<br /> 既にうろ覚えな改善もありますが、先に社員の皆さんと協力して箇条書きしたので、いくつか選択して紹介いたします。どうぞよろしくお願いいたします。</p> <h1 id="改善したこと">改善したこと</h1> <h2 id="ランディングページの配信に静的サイトホスティングサービスを利用">ランディングページの配信に静的サイトホスティングサービスを利用</h2> <p>バレットグループでは多数のランディングページを運用していますが、ほとんどが WordPress を利用して構築していました。<br /> しかし、WordPress での構築には下記のようなデメリットが挙げられました。</p> <ul> <li>構築・運用の工数やコストがかかる <ul> <li>KUSANAGI を利用して WordPress の構築をしていたが、バレットグループのセキュリティガイドラインの反映に多くの工数を割く必要があった</li> <li>運用開始後もサーバー監視や WordPress プラグインのアップデートが必要になり、ランディングページの増加により運用の工数も比例して増加</li> <li>ランディングページはたくさんの画像を載せることが多く、それなりのスペックが必要になりインスタンス費用がかさむ</li> </ul> </li> <li>ページの描画が遅い <ul> <li>WordPress はデータベースからデータを取得してサーバー側で描画するため、表示まで時間がかかることがあった</li> </ul> </li> <li>セキュリティリスクが高い <ul> <li>WordPress は高いシェアを持つため、攻撃の対象として狙われやすい</li> <li>プラグインの脆弱性が放置されていることもある</li> </ul> </li> </ul> <p>上記のようなデメリットを軽減するために、用途に合わせて様々な静的サイトホスティングサービスの利用を進めていきました。<br /> 実際に利用したサービスは下記になります。</p> <ul> <li>Cloudflare Pages</li> <li>Amazon CloudFront + Amazon S3</li> <li>Netlify CMS</li> </ul> <p>Cloudflare Pages を題材にした記事を <a href="http://blog.hatena.ne.jp/Usek/">id:Usek</a> さんが執筆されていますので、ぜひご覧になってください。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2021%2F09%2F30%2F150000" title="【脱WordPress】CloudFlare Pages + GitHubを使って簡単&無料で静的サイトをホスティング - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2021/09/30/150000">blog.bltinc.co.jp</a></cite></p> <h2 id="Datadog-導入によるアラート集約">Datadog 導入によるアラート集約</h2> <p>これまで検知したアラートを手作業で Google スプレッドシートに転記して管理する IT エンジニアらしからぬ作業をおこなっていました。<br /> この作業を数年おこなっていたわけですが、転記漏れなどのヒューマンエラーが発生し、信頼性が損なわれて分析に影響が出ていました。</p> <p>そこで、Datadog のインシデント管理機能を利用し、検知したアラートを集約することにしました。</p> <p><figure class="figure-image figure-image-fotolife" title="構成図"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/z/zuno_onuz/20211214/20211214195510.png" width="639" height="252" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>ざっくりとしたイメージ</figcaption></figure></p> <p>CloudWatch Alarm で発生したアラートを検知し、 SNS を介して Lambda を起動して Datadog の API を実行することでインシデントを作成しています。</p> <p>上記の流れでアラートを Datadog に自動で集約し、トイルを軽減することができました。</p> <h2 id="管理画面のデザインリニューアルに伴うシステム構成の変更">管理画面のデザインリニューアルに伴うシステム構成の変更</h2> <p>BGテクノロジーにて運営している成果報酬型プラットフォームの <a href="https://bgtech.co.jp/slvrbullet/">SLVRbullet</a> で、2020年4月に管理画面のデザインリニューアルプロジェクトが始動しました。<br /> デザインは外部の企業様にご依頼し、綿密な打ち合わせのもと、素敵なデザインへと生まれ変わりました。</p> <p>デザインの詳細に関しては Design Section の皆さんに執筆をお願いすることになっていますので、残念ながら今回は省略させていただきます。<br /> せっかくなので、ログイン画面の before after のみ掲載します。</p> <p><figure class="figure-image figure-image-fotolife" title="before"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/z/zuno_onuz/20211216/20211216184020.png" width="1200" height="723" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>before</figcaption></figure> <figure class="figure-image figure-image-fotolife" title="after"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/z/zuno_onuz/20211216/20211216183938.png" width="1187" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>after</figcaption></figure></p> <p>本題に入りますが、本題も別で詳細に執筆する予定となっているため、掻い摘んでお話します。</p> <p>当初は既存のアプリケーションの View をそのまま変更する予定でしたが、デザインのリニューアルによる UI の変更や、新規機能の追加が必要なことも徐々にわかり、一筋縄では行かないことがわかってきました。<br /> 加えて SLVRbullet では下記のような問題を抱えていました。</p> <ul> <li>重要な機能のパフォーマンスが悪く、表示までに時間がかかる</li> <li>Controller にビジネスロジックがずらずらと書かれている</li> <li>言語やフレームワークのバージョンが古く、サポートが対象外になりそう</li> <li>開発環境、検証環境、本番環境で環境の差異があり、予想外のエラーが発生しがち</li> </ul> <p>このようにデザインだけ切り替わっても、パフォーマンスは変わらず、改善すべきところが改善できていない状況で進行するのはよろしくないと考えました。</p> <p>そこで「このタイミングでリプレイスしてしまおう!」と思い立ち、デザインのリニューアルと共にシステム構成の変更も同時に始動しました。<br /> 具体的には別の記事で説明する予定ですが、フロントエンドとバックエンドを分離し、すべての環境をコンテナで管理するように変更しました。</p> <p>無事デザインリニューアルとシステム構成の変更のどちらもリリースが完了していますが、上記もひとつの起因として悲劇がいくつかありました。<br /> 自責の念を込めて、いつか執筆できればと思っています。</p> <h2 id="PHP-のエラーレベルの設定を見直し">PHP のエラーレベルの設定を見直し</h2> <p>弊社が保守しているアプリケーションに、いくつか素の PHP で実装しているアプリケーションがあります。<br /> 該当のアプリケーションで Nginx のエラーログを確認して調査しようとした際に、<code>E_NOTICE</code> のエラーで埋め尽くされてしまっていて、設定漏れがわかりました。</p> <p>エラーの見直しのついでに、本番環境のみ <code>E_NOTICE</code> のエラーを Nginx のエラーログに出力しないように変更しました。<br /> 初歩的なミスや漏れって以外と気付けないことがありますよね・・・。</p> <p>変更方法は簡単で、設定ファイルの <code>error_reporting</code> を以下のように修正しました。</p> <div class="code-title" data-title="php.ini"> <pre class="code lang-php" data-lang="php" data-unlink>error_reporting(E_ALL <span class="synError">&amp;</span> ~E_NOTICE); </pre> </div> <p>調査の手間になることは少しずつ排除していきたいですね。</p> <h2 id="その他の改善">その他の改善</h2> <p>せっかくいくつか箇条書きしていただいたので記事に載せておきたいと思います。</p> <ul> <li>メールフォームの実装を構成管理ツールを用いて工数の削減</li> <li>チケット管理システムを Jira Cloud に移行</li> <li>Git ホスティングサービスを GitHub に移行</li> <li>データベースの遠隔バックアップ方法の改善</li> <li>AWS Certificate Manager の認証方式をメール認証からドメイン認証に変更</li> <li>FujiSSL GO を利用し、証明書の自動更新</li> <li>デッドロックが発生したときにログを出力するように改善</li> <li>Pull Request に SQL の実行計画を載せてパフォーマンスに気を配る</li> <li>使用しているライブラリの OSS ライセンスを一元管理</li> </ul> <h1 id="最後に">最後に</h1> <p>ふりかえってみると今年は濃い一年であったと感じました。<br /> 自分が担当していなかった対応の理解にも繋がったので、機会があればまたまとめてみたいですね。</p> zuno_onuz 社内でLT大会を開催した話 hatenablog://entry/13574176438037760979 2021-12-09T15:00:00+09:00 2022-10-11T12:41:21+09:00 どーも皆さまお久しぶりです!Technology & Design Department SREチームの山口(id:gucchon90)です! 今回は先日2回目の社内LT大会をオンラインにて開催しましたのでその模様を少しだけお送りします。 まず弊社でのLT大会開催の目的は大きく下記の3つがあります。 半期毎に開催を行い社内やチーム内に頑張りを知らしめたい! 日頃関わらないメンバーが何をやっているのかをチーム外に知らしめたい! 当社(や個人)の技術力を世間に知らしめたい! またテーマは「業務で得た知見や取り組みについての自慢」として、今回は自分も含め5名の方に登壇いただきました。 それでは当日の… <p>どーも皆さまお久しぶりです!Technology &amp; Design Department SREチームの山口(<a href="http://blog.hatena.ne.jp/gucchon90/">id:gucchon90</a>)です!</p> <p>今回は先日2回目の社内LT大会をオンラインにて開催しましたのでその模様を少しだけお送りします。</p> <p>まず弊社でのLT大会開催の目的は大きく下記の3つがあります。</p> <ul> <li>半期毎に開催を行い社内やチーム内に頑張りを知らしめたい!</li> <li>日頃関わらないメンバーが何をやっているのかをチーム外に知らしめたい!</li> <li>当社(や個人)の技術力を世間に知らしめたい!</li> </ul> <p>またテーマは「業務で得た知見や取り組みについての自慢」として、今回は自分も含め5名の方に登壇いただきました。<br /> それでは当日の様子と登壇いただいたメンバーの感想をお届けします。</p> <h1 id="開催当日">開催当日</h1> <p><figure class="figure-image figure-image-fotolife" title="LT大会用スライド"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20211203/20211203115706.png" width="1200" height="676" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>LT大会用スライド</figcaption></figure></p> <p>まず開催にあたり有志で運営メンバーを集めて準備や調整、また当日の司会進行も行なっていただきました。<br /> またデザイナーの方にも協力を得て、LT大会用のスライドを作成いただきました。<br /> 質問はslidoで受け付けたり、Teamsにて配信を行いましたのでスレッドでも暖かいコメントいただき、当日登壇者は比較的リラックスして発表できていたのではないかと思います。</p> <h1 id="タイムテーブル">タイムテーブル</h1> <p><figure class="figure-image figure-image-fotolife" title="タイムテーブル"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20211207/20211207112739.png" width="960" height="540" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>タイムテーブル</figcaption></figure> 発表時間10分、質問5分と一般的なLTより少し長めの発表時間ですが、初めて登壇される方もいましたので余裕を持たせるために設定しました。 <br /> 全員の発表後にトークセッションを行い、発表時の率直な感想やLT大会にかけた想いなどを語っていただきました。<br /> また、LT大会終了後懇親会も開催し当日の裏話などもあり大変盛り上がりました。</p> <h1 id="発表内容と感想">発表内容と感想</h1> <p>登壇いただいたメンバーに対してLT大会後にアンケート実施し、発表内容と感想について赤裸々に回答いただきました。<br /> 発表資料については都合上一部割愛して公開している資料もありますので予めご了承ください。</p> <h2 id="1人目">1人目</h2> <ul> <li>発表者:<a href="http://blog.hatena.ne.jp/mtakakurar/">id:mtakakurar</a></li> <li>登壇テーマ:サポート対応ってなにを行っているのか</li> <li>登壇内容:<br /> Consulting Sectionが担当している業務についての説明。</li> <li>特に注目して欲しい点:<br /> ふんわりとした依頼から原因などを突き止める点。</li> <li>発表を終えての感想:<br /> 技術者ではない方への説明方法は皆さんも気にしているのだなと感じ、もっとわかりやすい説明をできるように理解度を深めようと思いました。</li> <li>発表資料<br /> <iframe id="talk_frame_802678" class="speakerdeck-iframe" src="//speakerdeck.com/player/496100f4e11b4829ac9f96a93959534e" width="710" height="399" style="aspect-ratio:710/399; border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe> <cite class="hatena-citation"><a href="https://speakerdeck.com/mickeytaka/sapotodui-ying">speakerdeck.com</a></cite></li> </ul> <h2 id="2人目">2人目</h2> <ul> <li>発表者:<a href="http://blog.hatena.ne.jp/awagatsuma/">id:awagatsuma</a></li> <li>登壇テーマ:タスク管理を考える2021</li> <li>登壇内容:<br /> 自分の中で一番の課題であったタスク・スケジュール管理を改善するのに何を実践しているのかを発表させていただきました。</li> <li>特に注目して欲しい点:<br /> 課題としていることから実際に何をやったことで改善できたのかをまとめさせていただいたので、ビフォーアフターがわかりやすいかなと思います。<br /> 夏休みの宿題が終わらないタイプの人は自分のことのように感じてくれると嬉しいです。終わるタイプの人は温かい目でお願いします。</li> <li>発表を終えての感想:<br /> 前回のLT大会では運営として参加していたので、今回は実際に登壇者として参加できてよかったです。</li> <li>発表資料<br /> <iframe id="talk_frame_802660" class="speakerdeck-iframe" src="//speakerdeck.com/player/f871745b87524093acd4149b28946bc3" width="710" height="399" style="aspect-ratio:710/399; border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe> <cite class="hatena-citation"><a href="https://speakerdeck.com/awagatsuma/thinking-about-task-management-2021">speakerdeck.com</a></cite></li> </ul> <h2 id="3人目">3人目</h2> <ul> <li>発表者:<a href="http://blog.hatena.ne.jp/thotta/">id:thotta</a></li> <li>登壇テーマ:仕事の効率を考える</li> <li>登壇内容:<br /> 自分なりに日々大切にしている業務管理のコツについてです。</li> <li>特に注目して欲しい点:<br /> タスク管理や開発手法も、技術の一部であること。</li> <li>発表を終えての感想:<br /> 当たり前と思ってしまっている内容でも、まとめ直すことで重要と考えているものが目視化できました。<br /> また、他の発表者と一部重なる内容もあり、より考えを強調・共有できる場面もあったのかなと思います。</li> <li>発表資料<br /> <iframe id="talk_frame_804310" class="speakerdeck-iframe" src="//speakerdeck.com/player/03bf33701c7b4a808e744a2eef6f00b1" width="710" height="399" style="aspect-ratio:710/399; border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe> <cite class="hatena-citation"><a href="https://speakerdeck.com/thotta/shi-shi-falsexiao-lu-wokao-eru">speakerdeck.com</a></cite></li> </ul> <h2 id="4人目">4人目</h2> <ul> <li>発表者: <a href="http://blog.hatena.ne.jp/hiro_blt/">id:hiro_blt</a></li> <li>登壇テーマ:業務で使用したOSSにプルリクを投げてみた話</li> <li>登壇内容:<br /> 業務で使用したOSSにプルリクを出すことで色々学びがありました!</li> <li>特に注目して欲しい点:<br /> 見てる人が退屈しないように、なるべく簡単に&非エンジニアにも分かりやすいようにまとめました!</li> <li>発表を終えての感想:<br /> LTを発表したのは初めてだったので緊張しました!<br /> もうちょっと笑いを誘えるかなと思いましたがリモートの発表だとリアクションが難しいですね...(単にスベっていただけかも)<br /> 自分のやったことを周りに共有する機会を頂けてとてもありがたかったです🙇‍♂️</li> <li>発表資料 <iframe id="talk_frame_802155" class="speakerdeck-iframe" src="//speakerdeck.com/player/ae8caf8863f84798913f8acf61d9468f" width="710" height="399" style="aspect-ratio:710/399; border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe> <cite class="hatena-citation"><a href="https://speakerdeck.com/hiro_ff/ye-wu-deshi-yong-sitaossnipururikuwotou-getemitahua">speakerdeck.com</a></cite></li> </ul> <h2 id="5人目">5人目</h2> <ul> <li>発表者:<a href="http://blog.hatena.ne.jp/gucchon90/">id:gucchon90</a></li> <li>登壇テーマ:コード化でトイル撲滅へ</li> <li>登壇内容:<br /> SREチームの掲げている目標の一つであるトイル撲滅を一つ事例をあげながら、どういったアプローチで改善したのか、それによりどのようなインパクトがあったのかという内容。</li> <li>特に注目して欲しい点:<br /> 手動で行っていたものをコードに置き換えることによって長期的に見て幸せになりますよーという点。</li> <li>発表を終えての感想:<br /> 内容を詰め込みすぎた感があり時間的にもギリギリとなった。<br /> 枠として10分いただいていたが、本来LTは大体5分とかなのでそういった場合さらに発表や資料作りには一工夫がありそうだなと感じた。<br /> また、今回はあえてエンジニアを対象にして資料作成したので色々と割り切って発表したが、ペルソナをどこに置くかによって資料の作り方や内容が変わるのでそこが難しいと感じた。</li> <li>発表資料 <iframe id="talk_frame_802121" class="speakerdeck-iframe" src="//speakerdeck.com/player/b9067b578fd849098eb4a5cfef62109f" width="710" height="532" style="aspect-ratio:710/532; border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe> <cite class="hatena-citation"><a href="https://speakerdeck.com/guccii07/coding-to-eliminate-toil">speakerdeck.com</a></cite></li> </ul> <h1 id="最後に">最後に</h1> <p>今回は社内で開催したLT大会の様子を少しだけお送りしましたがいかがだったでしょうか。<br /> 登壇者された方は「業務で得た知見や取り組みについての自慢」というテーマのもとしっかりと自慢できたのではないかと思います! <br /> 開催にあたり動いていただいた運営の皆様、LT大会用のスライドを作成いただいたデザイナーの皆様、発表いただいた登壇者の皆様、そして何より盛り上げていただいた参加者の皆様のおかげで無事開催できたかと思います!ありがとうございました!!<br /> また次回はさらにより良い発表ができるように日々の業務に邁進して会社と個人の成長につなげていきます!</p> gucchon90 広報業務をもっと楽にするため、textlintを導入した話 hatenablog://entry/13574176438026432204 2021-11-04T15:00:00+09:00 2022-10-12T14:02:08+09:00 皆さんこんにちは! Technology & Design DepartmentのDEVチーム所属の定吉です。 広報業務も担当してから記事を書く機会が増えました。ブレインストーミングから草稿やドキュメントチェックなど、一連のフローを通じて記事を公開するまでの労力って結構かかります。 特にドキュメントチェックは、単純な文字の誤りや表現を見るだけでなく、コンテンツ内容まで踏み込んで徹底した事実確認を行います。 そのため、「単純な文字の誤りや表現」をなくす作業はより正確かつスムーズに進めたい!そんな思いから、textlintという文章校正ツールを使い、ドキュメントチェックに取り入れてみました。 te… <p>皆さんこんにちは! Technology &amp; Design DepartmentのDEVチーム所属の定吉です。</p> <p>広報業務も担当してから記事を書く機会が増えました。ブレインストーミングから草稿やドキュメントチェックなど、一連のフローを通じて記事を公開するまでの労力って結構かかります。</p> <p>特にドキュメントチェックは、単純な文字の誤りや表現を見るだけでなく、コンテンツ内容まで踏み込んで徹底した事実確認を行います。</p> <p>そのため、「単純な文字の誤りや表現」をなくす作業はより正確かつスムーズに進めたい!そんな思いから、textlintという文章校正ツールを使い、ドキュメントチェックに取り入れてみました。</p> <h1 id="textlint-とは">textlint とは </h1> <p>textlintは、文章を書く場合の誤字脱字や読みづらい表現などを検知し、知らせてくれる校正ツールのことです。</p> <p>例えば、「確かにそういったケースはない事はない。」や「それが事の発端だったといえなくもない。」など、「〜ないことはない」「〜なくもない」という二重否定。このような読みづらい表現をtextlintは検知し、テキストで教えてくれます。</p> <h1 id="textlintを使ってみる">textlintを使ってみる</h1> <p>では実際にtextlintの環境構築をしてみましょう。</p> <h4 id="1textlintの導入">(1)textlintの導入</h4> <p>npmを使ってtextlintをインストールします。</p> <pre class="code" data-lang="" data-unlink>$ npm install textlint</pre> <p>インストール後、ディレクトリ下に<code>.textlintrc</code>ファイルを作成します。 これでtextlintの導入自体は完了です。 あとは、どんな校正ルールを入れるかを選びます。</p> <h4 id="2使用する校正ルールを選ぶ">(2)使用する校正ルールを選ぶ</h4> <p>ここからは、校正ルールを選びます。 今回は、<a href="https://github.com/textlint-ja">textlint-ja</a> という日本語関係のルールを扱うリポジトリを集約したところから 使用したい条件があるリポジトリを選んで導入します。</p> <p>今回は、試しに先述した二重否定をチェックするため、下記を使います。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Ftextlint-ja%2Ftextlint-rule-no-double-negative-ja" title="GitHub - textlint-ja/textlint-rule-no-double-negative-ja: 二重否定をチェックするtextlint rule" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://github.com/textlint-ja/textlint-rule-no-double-negative-ja">github.com</a></cite></p> <p>はじめに、二重否定ルールを導入します。</p> <pre class="code" data-lang="" data-unlink>$ npm install textlint-rule-no-double-negative-ja</pre> <p>導入後、<code>.textlintrc</code>ファイルで下記を記載します。</p> <div class="code-title" data-title=".textlintrc"> <pre class="code lang-json" data-lang="json" data-unlink><span class="synSpecial">{</span> &quot;<span class="synStatement">rules</span>&quot;: <span class="synSpecial">{</span> &quot;<span class="synStatement">no-double-negative-ja</span>&quot;: <span class="synConstant">true</span> <span class="synSpecial">}</span> <span class="synSpecial">}</span> </pre> </div> <p>記載後、文章を記入するファイルを作成します。私はdocsフォルダの中にsample.mdファイルを置きました。</p> <pre class="code" data-lang="" data-unlink>├── docs │   └── sample.md ├── node_modules ├── .textlintrc ├── package-lock.json ├── package.json</pre> <p>sample.mdに下記例文を書いてみます。</p> <div class="code-title" data-title="sample.md"> <pre class="code" data-lang="" data-unlink>確かにそういったケースはない事はない。 </pre> </div> <p>例文記載後、<code>textlint docs/sample.md</code>コマンドでtextlintを実行します</p> <pre class="code" data-lang="" data-unlink>$ textlint docs/sample.md /Users/----/text_lint/docs/sample.md 1:17 error 二重否定: 〜ないことはない no-double-negative-ja ✖ 1 problem (1 error, 0 warnings) </pre> <p>二重否定の部分が検知されました。 上記がtextlintを導入し、校正を行うまでのフローです。 どこの行が検知されたか分かるので、業務でも使えそうです。</p> <h1 id="執筆経験から必要だと思ったルールを紹介">執筆経験から必要だと思ったルールを紹介</h1> <p>校正ルールは他にもたくさんあります。 二重否定を検知するルールを例に、textlintの設定方法が分かったので、 執筆時に使用したいルールを幾つか紹介します。</p> <h3 id="textlintリポジトリの紹介">textlintリポジトリの紹介</h3> <p>① <a href="https://github.com/textlint-ja/textlint-rule-no-doubled-joshi">「文中に同じ助詞が連続して出てくるのをチェックするルール</a></p> <p>執筆時につい没頭してしまうと、同じ助詞を連続して使ってしまう時がありました。 連続しても文章として成立するケースはありますが、読み辛くなることが多いです。<br> 広報業務を始めて間もない頃、執筆時に先輩から「助詞が続くと読みづらいよね〜」と指摘頂いたことから、 その後の執筆では意識して書くようになりました。セルフチェックでも注意する重要項目の一つだったので、 嬉しいルールです。<br> <br> ex)材料不足で代替素材で製品を作った。</p> <pre class="code" data-lang="" data-unlink>3:10 error 一文に二回以上利用されている助詞 &#34;で&#34; がみつかりました。 no-doubled-joshi ✖ 1 problem (1 error, 0 warnings)</pre> <p><br> ② <a href="https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression">冗長な表現を禁止するルール</a></p> <p>「であると言えます」など冗長的な表現を書いてしまいませんか?私はついつい書いてしまいます。 本当は「である」や「と言えます」など簡潔な表現にしたいです。そのため冗長的な表現を検知してくれるこのルールを使いたいと考えました。</p> <pre class="code" data-lang="" data-unlink>3:3 error 【dict3】 &#34;であると言えます&#34;は冗長な表現です。&#34;である&#34; または &#34;と言えます&#34;を省き簡潔な表現にすると文章が明瞭になります。 解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict3 ja-no-redundant-expression ✖ 1 problem (1 error, 0 warnings)</pre> <p><br> ③ <a href="https://github.com/textlint-ja/textlint-rule-no-dropping-the-ra">ら抜き言葉を検知するルール</a></p> <p>「食べられない」を「食べれない」と書いてしまうなど、口語でよくも用いられる「ら抜き言葉」を検知してくれます。 会社としてメディアを発信する上で、ビジネスシーンでは好まれない口語を使うことはなるべく避けたいので、採用したいと考えました。</p> <pre class="code" data-lang="" data-unlink>3:9 error ら抜き言葉を使用しています。 no-dropping-the-ra ✖ 1 problem (1 error, 0 warnings)</pre> <p>その他採用したいと考えているルールがいくつかありましたが、紹介しきれないので抜粋しました。 他にもたくさんのリポジトリがあるので、執筆時に求めているルールを探してみましょう。</p> <h1 id="さいごに">さいごに</h1> <p>今回は文章校正ツールであるtextlintとその活用方法をご紹介致しました。</p> <p>チェック基準が多く見づらい場合は、<code>.textlintrc</code>ファイルでのルールを調整して使うこともできるので、 工夫して校正作業が行えます。<br></p> <p>また文章の方向性によって採用するルールを変更できるため、 適材適所で使用できれば、「単純な文字の誤りや表現」をチェックする作業が効率化できます。<br></p> <p>セットアップが簡単であるためエンジニアだけでなく、普段執筆やドキュメントチェックを業務でされている方にとっても、作業工数を避ける意味で非常に有益なツールになると考えているので、おすすめです!<br></p> <p>この記事がご覧頂いた方の参考に少しでもなれば幸いです。</p> Dakki_Sadaking AWSの料金を Slack に通知する hatenablog://entry/26006613610377084 2021-10-14T15:00:00+09:00 2022-10-11T12:43:38+09:00 みなさんこんにちは! Technology & Design Department インフラチーム所属の髙橋です。 今回は、AWSの料金を Slack に通知するシステムを2つ実装したのでそちらについて書いていきます。 1. S3 使用料金アラート通知 やりたいこと S3の月の使用料金が、月の予算の60%を超えた時に Slack に通知を行う。 使用するAWSサービス AWS Budgets AWS SNS AWS Chatbot サービスの関係図 手順 ①SNS トピック作成 AWS SNSコンソールを開き "トピックの作成" を選択。 "名前" に任意のものを入力し、"トピックの作成" を… <p>みなさんこんにちは!<br /> Technology &amp; Design Department インフラチーム所属の髙橋です。<br /> 今回は、<strong>AWSの料金を Slack に通知するシステム</strong>を2つ実装したのでそちらについて書いていきます。</p> <h1 id="1-S3-使用料金アラート通知">1. S3 使用料金アラート通知</h1> <h2 id="やりたいこと">やりたいこと</h2> <p>S3の月の使用料金が、月の予算の60%を超えた時に Slack に通知を行う。</p> <h2 id="使用するAWSサービス">使用するAWSサービス</h2> <ul> <li>AWS Budgets</li> <li>AWS SNS</li> <li>AWS Chatbot</li> </ul> <h2 id="サービスの関係図">サービスの関係図</h2> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20211004/20211004144429.png" width="559" height="100" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h2 id="手順">手順</h2> <h3 id="SNS-トピック作成">①SNS トピック作成</h3> <p>AWS SNSコンソールを開き "トピックの作成" を選択。 <img width="640" alt="image.png (30.7 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/58d85827-c886-4f45-af66-24c232a4b364.png"></p> <p> "名前" に任意のものを入力し、"トピックの作成" を選択。 <img width="640" alt="スクリーンショット 2020-08-04 18.18.35.png (169.5 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/0e90bc47-edfb-4e8e-b4dd-ada9d8c980f1.png"></p> <p> "編集" を選択し、アクセスポリシーへ追記を行います。 <img width="640" alt="スクリーンショット 2020-08-04 18.24.21.png (49.5 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/06/84571/1acde21d-0c4d-468a-a892-1fdb4383a62e.png"></p> <p>ポリシーのテキストフィールドで、<code>"Statement": [</code> の後に以下のテキストを追加します。<br /> "your topic ARN " の箇所は、作成したトピックのARNに書き換えてください。</p> <pre class="code" data-lang="" data-unlink>{ &#34;Sid&#34;: &#34;E.g., AWSBudgetsSNSPublishingPermissions&#34;, &#34;Effect&#34;: &#34;Allow&#34;, &#34;Principal&#34;: { &#34;Service&#34;: &#34;budgets.amazonaws.com&#34; }, &#34;Action&#34;: &#34;SNS:Publish&#34;, &#34;Resource&#34;: &#34;your topic ARN&#34; },</pre> <p>そして、[トピックの作成] をクリックすると、SNSトピックが作成されます。</p> <p>SNSでの作業は以上です!</p> <h3 id="AWS-Chatbot-の設定">②AWS Chatbot の設定</h3> <p>次に、AWS Chatbot のコンソールを開きます。</p> <p>"新しいクライアントを作成" を選択します。 <img width="640" alt="スクリーンショット 2020-08-04 18.49.25.png (19.8 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/d010b89b-75ab-417e-b001-762845c5c823.png"></p> <p>"新しいクライアントを設定" と出てくるので "Slack" を選択します。 <img width="640" alt="スクリーンショット 2020-08-04 18.50.19.png (32.5 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/4e3774b1-9013-4eb1-bc4e-e4d3ff36e71f.png"></p> <p>ワークスペースへサインインしたのち、下記のような画面となるので "許可する" を選択します。 <img width="640" alt="スクリーンショット 2020-08-04 18.53.01.png (76.8 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/197f3252-3b46-45f0-a5f3-f523fe76a197.png"></p> <p>追加されたワークスペースから "新しいチャネルを設定" をクリックします。 <img width="640" alt="スクリーンショット 2020-08-04 19.13.41.png (57.0 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/cce286f1-e6c7-4f3b-8361-3abc91d200e0.png"></p> <p>Slack チャネルの設定をしていきます。</p> <p>"設定名" に任意の名前を記入をします。<br /> "Slackチャネル" から通知先の Slack チャネルを選択します。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20210924/20210924102553.png" width="817" height="664" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>"アクセス許可" で、「テンプレートを使用してIAMロールを作成する」を選び、任意のロール名を記入します。<br> "通知 -オプション" で先ほど作成したSNSのリージョンとトピックを選択し、最後に"設定"をクリックします。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20210924/20210924103515.png" width="817" height="867" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>AWS Chatbot での作業は以上です!</p> <h3 id="コストの予算の作成">③コストの予算の作成</h3> <p>次に、Billing and Cost Management コンソールを開き、ナビゲーションペインの [Budgets] を選択します。</p> <p>ページの上部で、[予算を作成] を選択します。 <img width="640" alt="スクリーンショット 2020-08-04 18.29.52.png (59.2 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/83545152-16ff-4ca1-ac1f-0a789ab52797.png"></p> <p>[予算タイプの選択] で、[コスト予算] を選択し、"予算の設定"をクリックします。</p> <p>[予算の設定] で予算の詳細を決定していきます。<br> 今回は[間隔] は "月別" 、 [予算額] は "固定" で任意の予算を設定しました。<br> 記入ができたら、"アラートの設定" をクリックします。 <img width="640" alt="スクリーンショット 2020-08-04 18.35.23.png (100.8 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/ff3c5e69-8ff3-430a-abe5-79f2b9655a54.png"></p> <p>[アラートの設定] で "実際のコスト" を選択し、アラートのしきい値を "60" に設定します。<br /> "Amazon Simple Notification Service (SNS) トピックを通じて通知" にチェックを入れると、"SNSトピックのARN" を入力する箇所が出てくるのでそこに先ほど作成したトピックのARNを入れます。<br /> 全て終わったら "予算の確認" をクリックします。 <img width="640" alt="スクリーンショット 2020-08-04 19.21.09.png (153.3 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/52edc50b-79dc-4e35-861b-8d1494e510eb.png"></p> <p>最後に、確認画面を表示されるので "作成" をクリックしてください。</p> <p>お疲れ様でした、以上で全作業が終了です!<br /> 今後はS3の使用料金が設定予算の60%の超えたとき、下記の形で Slack に通知がきます。 <img width="640" alt="スクリーンショット 2020-08-04 19.24.27.png (29.8 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/04/84571/82f2a238-9296-458e-bab0-d0856f476168.png"></p> <h2 id="参考">参考</h2> <p><a href="https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/sns-alert-chime.html">https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/sns-alert-chime.html</a></p> <h1 id="2-Athena-実行による発生金額を通知">2. Athena 実行による発生金額を通知</h1> <h2 id="やりたいこと-1">やりたいこと</h2> <p>Athena でクエリを実行した際に、実行日時、スキャン量、料金、実行SQLを Slack に通知する。</p> <h2 id="利用するAWSサービス">利用するAWSサービス</h2> <ul> <li>Amazon Athena</li> <li>Amazon CloudWatch</li> <li>AWS Lambda</li> </ul> <h2 id="サービスの関係図-1">サービスの関係図</h2> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20211004/20211004144747.png" width="561" height="102" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h2 id="手順-1">手順</h2> <p>CloudWatch Events で Athena クエリのモニタリングができるので、それを使って Athena 実行時に Lambda の発火を行います。</p> <h3 id="Lambdaの設定">①Lambdaの設定</h3> <p>では、Lambda の設定から始めていきます。<br /> CloudWatch Events から Athena のクエリIDを取得し、それを元に必要な情報を取得し Slack に通知する関数を作成します。</p> <p>Lambda のダッシュボードから "関数の作成" をクリックします。<br /> オプションで "一から作成" を選択し、関数名を記入、ランタイムで任意の言語を選択してください。<br> 今回は Python を選択しました。 その後、"関数の作成" をクリックします。<br /> <img width="640" alt="スクリーンショット 2020-08-05 10.50.16.png (163.8 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/05/84571/fc95098a-5507-4086-b3f2-fc5da467c7e8.png"></p> <p>作成すると、下記のように関数コードを記述できるようになります。 <img width="640" alt="スクリーンショット 2020-08-05 10.53.22.png (72.4 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/05/84571/b3e4612d-c505-4c7e-af88-6dd211d936c6.png"></p> <p>あとは、</p> <pre class="code" data-lang="" data-unlink>1. CloudWatch Events からクエリIDを取得 2. クエリIDを元に GetQueryExecution APIを叩いて DataScannedInBytes を取得 3. 取得したスキャン量を元に金額を算出 4. 算出した金額を Slack に通知 (直接 webhook で通知させます)</pre> <p>を実行できるプログラムを作成します。</p> <p>例として、Python でのコードを記載します。</p> <pre class="code" data-lang="" data-unlink>import boto3 import urllib.request import json import datetime from decimal import Decimal athena_client = boto3.client(&#39;athena&#39;) sns_client = boto3.client(&#39;sns&#39;) slack_url = &#39;****************&#39; MAX_TEXT_LENGTH = 1400 def lambda_handler(event, context): response = athena_client.get_query_execution( QueryExecutionId=event[&#39;detail&#39;][&#39;queryExecutionId&#39;] ) submission_date_time = response[&#39;QueryExecution&#39;][&#39;Status&#39;][&#39;SubmissionDateTime&#39;] jst = submission_date_time.strftime(&#34;%Y/%m/%d %H:%M:%S&#34;) scanned_bytes = response[&#39;QueryExecution&#39;][&#39;Statistics&#39;][&#39;DataScannedInBytes&#39;] print(scanned_bytes) display_scanned_bytes = scanned_bytes / 1024 / 1024 cost = 0 if scanned_bytes &lt; 10 * 1024 * 1024: scanned_bytes = 10 * 1024 * 1024 print(scanned_bytes) cost = round(scanned_bytes / 1024 / 1024 / 1024 / 1024 * 5, 10) sql = response[&#39;QueryExecution&#39;][&#39;Query&#39;] print(sql) return post_slack(jst, display_scanned_bytes, cost, sql) def post_slack(jst, display_scanned_bytes, cost, sql): sql_len = len(sql) if sql_len &gt; MAX_TEXT_LENGTH: sql = sql[0:int(MAX_TEXT_LENGTH/2)] + &#39;\n\n...省略...\n\n&#39; + sql[sql_len-int(MAX_TEXT_LENGTH/2):sql_len] send_data = { &#34;text&#34;: &#34;クエリ実行結果&#34;, &#34;attachments&#34;: [ { &#34;color&#34;: &#34;#00ffff&#34;, &#34;blocks&#34;: [ { &#34;type&#34;: &#34;section&#34;, &#34;fields&#34;: [ { &#34;type&#34;: &#34;mrkdwn&#34;, &#34;text&#34;: f&#39;実行日時 \n `{jst}`&#39; }, { &#34;type&#34;: &#34;mrkdwn&#34;, &#34;text&#34;: f&#39;スキャン量 \n`{&#34;{0:.10f}&#34;.format(Decimal(display_scanned_bytes))}MB`&#39; } ] }, { &#34;type&#34;: &#34;section&#34;, &#34;fields&#34;: [ { &#34;type&#34;: &#34;mrkdwn&#34;, &#34;text&#34;: f&#39;料金 \n`${&#34;{:.10f}&#34;.format(cost)}`&#39; }, { &#34;type&#34;: &#34;mrkdwn&#34;, &#34;text&#34;: f&#34;SQL \n ```{sql}```&#34; } ] } ] } ] } print(send_data) send_text = &#34;payload=&#34; + json.dumps(send_data) print(send_text) request = urllib.request.Request( slack_url, data=send_text.encode(&#34;utf-8&#34;), method=&#34;POST&#34; ) print(request) try: with urllib.request.urlopen(request) as response: if response.status == 200: print (response.reason) return True else: print (response.reason) return False except Exception as e: print (e.message) print (&#34;slackへの送信失敗&#34;) return False</pre> <p>このコードのこだわりポイントとして、<code>MAX_TEXT_LENGTH</code>に指定している1400字を超えたクエリであった場合、下記の箇所でクエリの中間を省略するようにしています。<br> これは約1500字以上で Slack 投稿しようとした場合、投稿ができない不具合が発生してしまうのでそれを防ぐ役割をしています。<br> またクエリの中間を省略した意図しては、先頭もしくは後方を省略してしまうと<code>SELECT</code>や<code>FROM</code>の対象が分からず確認のしやすさが低下してしまうので、それを避けるため中間を省略しています。<br></p> <pre class="code" data-lang="" data-unlink>sql_len = len(sql) if sql_len &gt; MAX_TEXT_LENGTH: sql = sql[0:int(MAX_TEXT_LENGTH/2)] + &#39;\n\n...省略...\n\n&#39; + sql[sql_len-int(MAX_TEXT_LENGTH/2):sql_len]</pre> <p>では、コード記述後 "保存" をクリックしてください。<br> Lambda の作業は以上です。</p> <h3 id="CloudWatch-Events-の設定">②CloudWatch Events の設定</h3> <p>次に、CloudWatch Events の設定をしていきます。<br /> CloudWatchのメニューから イベント > ルール を開き、"ルールの作成" を選択します。 <img width="640" alt="スクリーンショット 2020-08-05 10.31.12.png (110.2 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/05/84571/d9b3fc62-cac9-4d1f-9a74-e6f7e06e2a49.png"></p> <p>ルールの作成画面となるので、イベントパターンのプレビューから "編集" をクリックし、下記の内容を記載します。<br /> ターゲットに先ほど作成したLambda関数を選択し、"設定の詳細" をクリックします。<br /> 遷移先で、作成するルールの名前を入力し、ルールの作成をクリックします。</p> <pre class="code" data-lang="" data-unlink>{ &#34;source&#34;:[ &#34;aws.athena&#34; ], &#34;detail-type&#34;:[ &#34;Athena Query State Change&#34; ], &#34;detail&#34;:{ &#34;currentState&#34;:[ &#34;SUCCEEDED&#34; ] } }</pre> <p>もう一度 Lambda に戻り、作成した関数のコンソール上部にあるデザイナーのボードを開くと CloudWatch Events がトリガーに追加されることがわかります。<br /> <img width="640" alt="スクリーンショット 2020-08-05 11.17.44.png (71.9 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/05/84571/4d75e1c6-68d0-48c4-bf35-13da67a4adab.png"></p> <p>これで、CloudWatch Events の設定も完了です! <br /> これにより Athena を実行するごとに、下記の形で Slack に通知を飛ばすことができます! <img width="500" alt="スクリーンショット 2020-08-05 11.19.49.png (28.6 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2020/08/05/84571/c2cb31d8-0fd6-469b-a2f3-2858b3229ddb.png"></p> <h2 id="参考-1">参考</h2> <p><a href="https://docs.aws.amazon.com/ja_jp/athena/latest/ug/athena-cloudwatch-events.html">CloudWatch イベントを使用した Athena クエリのモニタリング</a> <br> <a href="https://docs.aws.amazon.com/athena/latest/APIReference/API_GetQueryExecution.html">Amazon Athena Documentation</a></p> <h1 id="最後に">最後に</h1> <p>このようにAWSでは比較的簡単に、コンソールからぽちぽちするだけで実装できる便利機能がたくさんあります。<br> 今回の予算のアラート通知に関しても、より目につきやすい Slack に通知を飛ばせることによってより一層予算への意識が高まり、予算オーバーを防ぐことが期待できます! <br> 今後さらに知見を広げると共に、使えそうなサービスを導入し社内のシステムの最適化に役立てていきたいです!</p> Takahashi_Blt 【脱WordPress】CloudFlare Pages + GitHubを使って簡単&無料で静的サイトをホスティング hatenablog://entry/26006613800345397 2021-09-30T15:00:00+09:00 2022-10-11T12:44:01+09:00 こんにちは、テクノロジー&デザイン部所属、SREチームのUsekです。 暑かったり寒かったり、異常気象な2021年夏でしたね。皆さん体調管理にはお気をつけください。 はじめに なぜ「脱WordPress」なのか ①構築・運用の工数の負荷が大きい ②表示の速度が遅い ③費用がかかる ④セキュリティのリスクがある 静的サイトホスティングのメリット ①構築・運用の工数が下がる ②表示の速度が早い ③費用が安価 ④セキュリティが堅牢 静的サイトホスティングのデメリット ①WordPressほど凝ったレイアウトのサイトを作れない ②非エンジニアには若干敷居が高い CloudFlare Pagesについて… <p>こんにちは、テクノロジー&amp;デザイン部所属、SREチームのUsekです。 暑かったり寒かったり、異常気象な2021年夏でしたね。皆さん体調管理にはお気をつけください。</p> <ul class="table-of-contents"> <li><a href="#はじめに">はじめに</a></li> <li><a href="#なぜ脱WordPressなのか">なぜ「脱WordPress」なのか</a><ul> <li><a href="#構築運用の工数の負荷が大きい">①構築・運用の工数の負荷が大きい</a></li> <li><a href="#表示の速度が遅い">②表示の速度が遅い</a></li> <li><a href="#費用がかかる">③費用がかかる</a></li> <li><a href="#セキュリティのリスクがある">④セキュリティのリスクがある</a></li> </ul> </li> <li><a href="#静的サイトホスティングのメリット">静的サイトホスティングのメリット</a><ul> <li><a href="#構築運用の工数が下がる">①構築・運用の工数が下がる</a></li> <li><a href="#表示の速度が早い">②表示の速度が早い</a></li> <li><a href="#費用が安価">③費用が安価</a></li> <li><a href="#セキュリティが堅牢">④セキュリティが堅牢</a></li> </ul> </li> <li><a href="#静的サイトホスティングのデメリット">静的サイトホスティングのデメリット</a><ul> <li><a href="#WordPressほど凝ったレイアウトのサイトを作れない">①WordPressほど凝ったレイアウトのサイトを作れない</a></li> <li><a href="#非エンジニアには若干敷居が高い">②非エンジニアには若干敷居が高い</a></li> </ul> </li> <li><a href="#CloudFlare-Pagesについて">CloudFlare Pagesについて</a></li> <li><a href="#実際に静的サイトをホスティングしてみる">実際に静的サイトをホスティングしてみる</a><ul> <li><a href="#GitHubのリポジトリを作成しホスティングするソースコードをアップロードする">GitHubのリポジトリを作成し、ホスティングするソースコードをアップロードする</a></li> <li><a href="#CloudFlare-Pagesのアカウントを作成する">CloudFlare Pagesのアカウントを作成する</a></li> <li><a href="#CloudFlare-PagesとGitHubを連携させる">CloudFlare PagesとGitHubを連携させる</a></li> </ul> </li> <li><a href="#その他の機能">その他の機能</a><ul> <li><a href="#カスタムドメイン機能">カスタムドメイン機能</a></li> <li><a href="#メンバー追加機能">メンバー追加機能</a></li> <li><a href="#アクセスポリシー">アクセスポリシー</a></li> <li><a href="#Web分析">Web分析</a></li> </ul> </li> <li><a href="#まとめ">まとめ</a></li> </ul> <h3 id="はじめに">はじめに</h3> <p>テクノロジー&amp;デザイン部ではバレットグループ内各事業部のコーポレートサイトやランディングページ(LP)を多数運用しています。 これまではWordPressを利用して構築・運用してきましたが、最近「脱WordPress」を掲げ、様々な代替技術を検証しています。 今回はその中でも私が最近推している<b>CloudFlare Pages</b> + <b>GitHub</b>を用いた静的サイトホスティング技術を紹介します。</p> <h3 id="なぜ脱WordPressなのか">なぜ「脱WordPress」なのか</h3> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210916/20210916170748.png" width="225" height="225" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>WordPressについては説明不要でしょう。世界で最も普及しているオープンソースのブログソフトウェア。 直感的なデザインでブログを作ることができます。デザインのテーマや便利なプラグインも多数用意され、大企業から個人まで、様々な人が利用しています。 公式の説明によると、Web 上の42%のサイトが WordPress を使っているとのことです。</p> <p>”脱WordPress”という言葉自体は新しいものではありません。インターネットで検索すれば数年前の記事も出てきます。 私がバレットグループにアサインされた2年前には既にSREチームで話題に上がっていました。 しかし日々発生する新しい業務や調査検証の中で既に運用フローが確立されているWordPress構築を改善することがなかなかできない状況が続く中、短納期で多数のWordPressを構築する業務が発生しついに現場はオーバーフロー。脱WordPress待ったなしとなりました。 WordPressを用いた静的サイト構築の問題は以下が挙げられます。</p> <h4 id="構築運用の工数の負荷が大きい">①構築・運用の工数の負荷が大きい</h4> <p>バレットグループではAWSを多用しているのは過去の記事でも紹介してきました。 AWSではLightSailという軽量なVPSを提供するサービスがあり、こちらを用いてWordPressを素早く構築することもできますが、スペックや機能面において望む条件を満たしていませんでした。 これまではKUSANAGIを利用してWordPressを構築していましたが、リソースに対するセキュリティガイドラインの反映などにかなりの工数を割いていました。 構築完了後もインスタンスやURLに対する監視やソフトウェア・プラグインのアップデートが必要になり、サイトが増えるほど運用工数も増加していきました。通常業務や改善業務はたくさん存在するため、これらのタスクは<a href="https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles">トイル</a>になっていました。</p> <h4 id="表示の速度が遅い">②表示の速度が遅い</h4> <p>ページの表示速度が遅いことは利用者にとってマイナス点です。WordPressはDBからデータを取得してWebページを生成する処理が走るため、どうしても描画までに時間がかかります。</p> <h4 id="費用がかかる">③費用がかかる</h4> <p>大量の画像や記事が存在するWebサイトを配信する場合、メモリやCPUにパワーが必要となり、結果インスタンスの費用が高額になる傾向がありました。 もちろん構築中・構築後の運用自体にエンジニアの稼働工数が必要になり、コストとなって計上されます。</p> <h4 id="セキュリティのリスクがある">④セキュリティのリスクがある</h4> <p>WordPressは高いシェアを持つソフトウェアです。そのため攻撃の対象として狙われやすいです。また数々の便利なプラグイン が提供されている反面、そのプラグインの脆弱性が放置されたままという問題も存在します。</p> <p>WordPressは初リリースから20年近い長い歴史を持つソフトウェアです。互換性を保っていることもあり、古い技術が使われ続けています。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210916/20210916180039.png" width="450" height="449" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h3 id="静的サイトホスティングのメリット">静的サイトホスティングのメリット</h3> <p>静的サイトホスティングは技術的には単純明快です。アップロードされたhtml・画像・CSSをインターネット上に公開します。 近年注目されている静的サイトホスティングサービスは、ユーザにとって多くのメリットがある機能をパッキングして提供しています。</p> <h4 id="構築運用の工数が下がる">①構築・運用の工数が下がる</h4> <p>ファイルを指定された場所にアップロードするだけで、すぐにWebサイトを公開できます。 多くの静的サイトホスティングサービスはGitHubなどのソースコード管理サービスと連携しており、エンジニアにとってはコンテンツの管理が容易です。 さらにはGitHub ActionsのようなCI/CDと組み合わせることで、ビルド・デプロイまで一気通貫で行ってくれます。 運用負荷を静的サイトホスティングサービス側にオフロードでき、自分たちでリソース監視や障害対応を行う必要がありません。(死活監視は自分たちで設定しますが)</p> <h4 id="表示の速度が早い">②表示の速度が早い</h4> <p>作成済のファイルが配置・表示されるため、表示はWordPressと比べると高速です。 さらに静的サイトホスティングサービスの多くはCDNの機能を持ちます。これによりクライアントアクセス元から距離が近い場所から記事が配信されるため、この観点でも高速です。 CDNを使うことで耐障害性が強固になる側面もあります(先日のFastlyの障害のように完全無敵ではありませんが・・・)</p> <h4 id="費用が安価">③費用が安価</h4> <p>無料で実運用に耐えられるサービスになっています。有料サービスを契約するとさらに大規模な静的サイトホスティングでも利用できます。 メンテナンスフリーなので、これまでメンテナンスにかかっていた工数を本来やりたい業務、利益を生み出す業務に充てることができます。</p> <h4 id="セキュリティが堅牢">④セキュリティが堅牢</h4> <p>WordPressのセキュリティ問題の原因の一つに、phpがDBからデータを取得し、htmlを生成する処理に脆弱性が含まれることがありますが、静的サイトホスティングについてはサーバ上に配置されているファイルは全て生成済のものなので、セキュリティリスクが低いと言われています。 CDN自体にDDoS対策やWAF機能が標準されていることもあり、個人で対策するより堅牢なWebサイトを公開することができます。</p> <p>最大のメリットはやはりコストですね。ホスティング、CDN、セキュリティ対策など物理的リソースが無料で提供されていることはもちろん、運用保守にかかる稼働工数が削減されるのも大きいです。エンジニアとしても面倒なことはやりたくないですし(笑)</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210916/20210916180144.png" width="400" height="400" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h3 id="静的サイトホスティングのデメリット">静的サイトホスティングのデメリット</h3> <p>優れた点を多く持つ静的サイトホスティングですが、デメリット、というより技術的制約もあります。 したがって自分たちが実現したいことが実現可能なのかを吟味したうえで利用を決めると良いでしょう。</p> <h4 id="WordPressほど凝ったレイアウトのサイトを作れない">①WordPressほど凝ったレイアウトのサイトを作れない</h4> <p>これは世界的シェアの高さと長い歴史を持つWordPressの長所です。WordPress界にはたくさんのプラグインとテーマが用意されています。 Webサーバを管理しないため、アクセス元IPアドレスによる分岐処理や描画ページの変化、さらには高度なコーディングによるWebサービス化など複雑な操作も行えず、静的サイトのホスティングに特化しています。</p> <h4 id="非エンジニアには若干敷居が高い">②非エンジニアには若干敷居が高い</h4> <p>ページをGitHubなどソースコード管理サービスを使用することは、非エンジニアにとっては意外とハードルが高かったりします。 WordPressをエディタ目的として利用する人もいます。一方で非エンジニア向けに静的サイトホスティングにおいてもWordPressの管理画面のようなCMS(コンテンツ管理システム)を用意してくれているサービスも存在します。</p> <h3 id="CloudFlare-Pagesについて">CloudFlare Pagesについて</h3> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210830/20210830151129.png" width="157" height="58" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>静的サイトホスティングのサービスについて説明したところで、CloudFlare Pagesを紹介します。 CloudFlare Pagesはその名前の通り世界最大規模のCDNサービスを展開するCloudFlareが提供する静的サイトホスティングサービスです。Netlify、GitHub Pagesと競合し、それらと比べると後発のサービスになります。 各サービスの比較はこちらのページに詳しく紹介されています。</p> <p><a href="https://zenn.dev/catnose99/scraps/6780379210136f">Cloudflare Pages&#x30FB;Vercel &#x30FB;Netlify &#x306E;&#x9055;&#x3044;&#x3084;&#x4F7F;&#x3044;&#x5206;&#x3051;&#x3092;&#x307E;&#x3068;&#x3081;&#x308B;</a></p> <p>上記にあるように無料で帯域無制限かつホスティング可能なサイト数も無制限という太っ腹。競合サービスは複数アカウントでのサイト管理は有料になりますが、こちらも無料。どの静的サイトホスティングを利用するか悩んでいたのですが、初期費用がかからないことに魅力を感じて検証を開始しました。</p> <h3 id="実際に静的サイトをホスティングしてみる">実際に静的サイトをホスティングしてみる</h3> <p>構成は以下のようになります。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210916/20210916175433.png" width="813" height="289" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h4 id="GitHubのリポジトリを作成しホスティングするソースコードをアップロードする">GitHubのリポジトリを作成し、ホスティングするソースコードをアップロードする</h4> <p>こちらの手順は省略します。 のちのちCloudFlare Pages内で自身のGitHubアカウントと連携してリポジトリを選択しますが、リポジトリにadmin権限が付与されていないとエラーとなるので注意してください。</p> <h4 id="CloudFlare-Pagesのアカウントを作成する">CloudFlare Pagesのアカウントを作成する</h4> <p><a href="https://pages.cloudflare.com/">https://pages.cloudflare.com/</a></p> <p>上記URLよりメールアドレスを用いてアカウントを作成します。 メールアドレスに検証URLが送付されますので、検証を行います。</p> <h4 id="CloudFlare-PagesとGitHubを連携させる">CloudFlare PagesとGitHubを連携させる</h4> <p>トップページからPagesを選択します。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210825/20210825105711.png" width="1189" height="459" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>Connect GitHub account を選択し、自身のGitHubアカウントと連携します。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210917/20210917122953.png" width="340" height="594" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>連携後、[Create a project]ボタンを押します。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210825/20210825125232.png" width="1200" height="696" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>[Connect GItHub account]をクリックします。 [Select a repository]から静的コンテンツが管理されているリポジトリを選択すると、リポジトリ名の右にチェックマークがつきます。 [Begin Setup]をクリックします。</p> <p>Set up builds and deploymentsページでは以下のように設定します。</p> <ul> <li><p>"Project name"ではサイトの名前を入力してください。<サイト名>.pages.devがページのURLになります。</p></li> <li><p>"Production branch"では公開するブランチの名前を選択してください。 ※ここで選択した以外のブランチについてはアクセス認証をかけることができます(詳しくは後で説明します) <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210928/20210928174036.png" width="842" height="764" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p></li> </ul> <p>今回は説明しませんが、Build settingsを使うと、高度なビルドを簡単に実現できます。 例えばBuild Commandに"yarn build"と書くことで、TypeScriptで書かれたGitHub上のソースをビルドした結果をデプロイすることもできます。</p> <p>[Save and Deploy]を押すと画面遷移します。若干時間がかかりますがビルドとデプロイが実行されます。 [Continue to Project]をクリックします。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210928/20210928174301.png" width="842" height="770" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>静的サイトがホスティングされました。あっという間でしたね! CloudFlareのCDNが利用されているため、非常に高速に表示されることが可能です。HTTPSにも対応済みで、証明書の更新作業も不要です。</p> <h3 id="その他の機能">その他の機能</h3> <p>CloudFlare Pagesの管理画面には他にも以下のような機能が用意されています。</p> <h4 id="カスタムドメイン機能">カスタムドメイン機能</h4> <p>カスタムドメインの設定も可能です。CloudFlare自体がDNS機能を持っていますが、それ以外のDNSを利用している場合でも、CNAMEレコードで希望するカスタムドメインとCloudFlare Pagesのドメインを紐づけることで、簡単にカスタムドメインが設定できます。</p> <h4 id="メンバー追加機能">メンバー追加機能</h4> <p>アカウントを複数ユーザで使い回すのは好ましくありませんが、CloudFlare Pagesは無料で複数ユーザでの管理に対応可能です。</p> <h4 id="アクセスポリシー">アクセスポリシー</h4> <p>こちらを有効にすると、Production branch以外のブランチが更新された際に提供されるURLにアクセス制限を施すことができます。 URLにアクセスするとメールアドレスを入力する画面が表示され、メンバーとして登録されているユーザのメールアドレスを入力することで、メールアドレス宛に認証コードが送信されます。 公開前のWebページの見た目を確認するのに役立ちます。</p> <h4 id="Web分析">Web分析</h4> <p>viewer数、アクセス元やアクセス先ページをグラフィカルに確認することができます。</p> <h3 id="まとめ">まとめ</h3> <p>いかがでしたでしょうか?拍子抜けしてしまうほど簡単に静的ファイルをインターネット上にホスティングできます。かかる費用は独自のドメイン代だけです。 ただしシンプルな静的ファイルをホスティングすることにおいては優れた方法であるCloudFlare Pagesも万能ではありません。 今回は説明しませんが、「エディタを使って記事を作成・公開したい」という要望に対してはNetlify CMS + Hugo + GitHubの組み合わせを提案したり、「アクセス制限を施したWebページを利用したい」という要望に対してはCloudFront Function + s3 + GitHubの組み合わせを提案するなど、依頼者のニーズに応じて最適なインフラ構成を提案できるよう、テクノロジー&amp;デザイン部は新しい技術の検証を日々進めています。</p> Usek 情報共有にesaを使っている話 hatenablog://entry/26006613617659121 2021-09-16T15:00:00+09:00 2022-10-11T12:45:40+09:00 皆さんこんにちは! Technology & Design DepartmentのSREチーム所属のしょーやです リモートワークも長くなってきて自宅の作業環境がだいぶ整ってきましたが 部屋が狭いため、居住空間を侵食しており試行錯誤を繰り返してます... リモートワークでの悩みといえば、対面でのコミュニケーションがどうしても減ってしまうため「リモートになってから情報共有が行いにくくなった」という方も多いのではないでしょうか 弊社では、フルリモート開始以前から esa を利用させていただいており、そのおかげで「リモートワークになってから情報共有が行いづらい」という事態に陥ることなく、今まで通りお互… <p>皆さんこんにちは! Technology &amp; Design DepartmentのSREチーム所属のしょーやです</p> <p>リモートワークも長くなってきて自宅の作業環境がだいぶ整ってきましたが<br /> 部屋が狭いため、居住空間を侵食しており試行錯誤を繰り返してます...</p> <p>リモートワークでの悩みといえば、対面でのコミュニケーションがどうしても減ってしまうため「リモートになってから情報共有が行いにくくなった」という方も多いのではないでしょうか</p> <p>弊社では、フルリモート開始以前から esa を利用させていただいており、そのおかげで「リモートワークになってから情報共有が行いづらい」という事態に陥ることなく、今まで通りお互いの知見や経験を共有することができております</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fesa.io%2Fconcept" title="コンセプト" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://esa.io/concept">esa.io</a></cite></p> <p>そこで、今回は esa を使って弊社でどのように情報共有を行なっているのかをご紹介させていただきたいと思います</p> <h1 id="esaio-とは-">esa.io とは 🐥</h1> <p><strong>esaの初期READMEから引用</strong></p> <blockquote><p>esa.io とは、「情報を育てる」という視点で作られた、自律的なチームのためのドキュメント共有サービスです - <a href="https://docs.esa.io/posts/18">esa.ioの使い方</a> - <a href="https://docs.esa.io/posts/13">チームへの招待方法</a></p></blockquote> <p>下書き状態でも情報を公開して貯めておくことが出来るため「とりあえず書いておく」という情報公開の敷居がかなり下がるため、まさに「<strong>情報を貯め・育てていく</strong>」ことに適したツールであると利用してみて感じております</p> <p>また、esaではチームの画像を変更することができるため、弊社ではオリジナルアイコン<span itemscope itemtype="http://schema.org/Photograph"><a href="http://f.hatena.ne.jp/bulletgroup/20210917174534" class="hatena-fotolife" itemprop="url"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/b/bulletgroup/20210917/20210917174534.jpg" width="388" height="388" loading="lazy" title="" class="hatena-fotolife" style="width:45px" itemprop="image"></a></span>を使用してます</p> <p>※ <a href="https://docs.esa.io/posts/125">esaのロゴマークは「クリエイティブ・コモンズ 表示-非営利-改変禁止 4.0」に指定されています</a>が 、このアイコンは本記事のへ掲載にあたり、問い合わせにてesa LLC様に確認し許可をいただいて掲載しております。</p> <p>これだけでもかなり愛着が湧き「<strong>早くエサをあげなきゃ</strong>」となります!(個人の見解です</p> <p>また、esaにGA4を導入しようとした際、GA4に未対応っぽい挙動であったためサポートに下記のお問い合わせさせていただいたところ、驚くほどの爆速対応してくださったことがあり「ああ、もっとesaを使って情報を育てていこう」という強い気持ちが芽生えました (サポートの対応も素晴らしかったです。ということが言いたい) <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/show--ya/20210805/20210805183338.png" width="1162" height="892" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>弊社では、導入当初は「まず情報を貯める文化を作る」ことを目指し、特に運用ルールは定めず各々自由に利用してもらいながら情報を貯め続けてきました</p> <p>そして、ある程度の情報量が溜まって来た頃にゆるめのルールを作成し、現在もその運用ルールを利用しております</p> <h1 id="弊社のesa運用ルール">弊社のesa運用ルール</h1> <h2 id="READMEmd-について">README.md について</h2> <p><code>README</code> で始まるドキュメントは、いつもカテゴリページの一番最初に表示される  (<code>foo/README</code>というタイトルにすると、<code>foo</code>カテゴリの一番上に表示される)</p> <p>チームでよく使うページのリンクなど、頻繁に見たい情報を貼っておくと便利です</p> <h3 id="READMEの扱い">READMEの扱い</h3> <ul> <li><strong>このREADMEをプロジェクト/チームのIndexページと捉えてください</strong> <ul> <li>新規参画メンバーが最初に見て全容を把握するページ</li> </ul> </li> <li><strong>後述するディレクトリ構造にREADMEと書かれている箇所には基本的に配置してください</strong> <ul> <li> 他にも必要と思われる箇所には自由に置いてください</li> </ul> </li> </ul> <h3 id="README-に記載して欲しい基本的な内容">README に記載して欲しい基本的な内容</h3> <ul> <li>プロジェクトの簡単な説明</li> <li>関連する人々とその関係性 <ul> <li>システム利用者</li> </ul> </li> <li>gitリポジトリの場所</li> <li>jiraのプロジェクト</li> <li>関連するslackチャンネル</li> <li>リンク集 <ul> <li>esa以外にドキュメントを置いている場所(google drive等)</li> </ul> </li> </ul> <h2 id="タグについて">タグについて</h2> <p><a href="https://docs.esa.io/posts/361">タグの使い方</a></p> <ul> <li><strong>基本的にカテゴリで階層分けをしていく</strong> <ul> <li>作業したプロジェクトやチームの下に記事がたまる</li> </ul> </li> <li><strong>タグは利用技術やツールで検索したい際の補助とする</strong> <ul> <li>例) aws, ec2, cloudfront, gitlab, ruby, php, nginx, docker, terraform, capistrano ...etc</li> </ul> </li> </ul> <h1 id="BulletGroup流-ディレクトリ構造">BulletGroup流 ディレクトリ構造</h1> <pre class="code bash:構造ルール" data-lang="bash:構造ルール" data-unlink>README #esaのルールや使い方など 日報 #個々の作業状況などを記録 ┗ %{Year}/%{month}/%{day}/%{me} 作業メモ #どこに入れていいかわからない記事や個人的な記事などを一時的に格納 ┗ %{me}/title Poem #記憶ではなく記録に残そう。名言を ┗ %{me}:title Designer #デザインチーム用のディレクトリ ┗ チーム内でよしなにご利用ください Operation #オペレーションチーム用のディレクトリ ┗ チーム内でよしなにご利用ください Projects #各プロジェクトの情報を集約するディレクトリ ┗ {product/team名} #プロダクトやチームごとに作成 ┗ README #プロダクトの紹介, プロダクト情報のindexページ ┗ tips #プロダクトについてのHowToや作業記録など ┗ 手順書 #リリース手順や確認手順などの情報 ┗ releases #リリースに含んだ内容など ┗ 議事録 #プロダクトに関するMtgの議事録 Tools #社内ツールの情報を集約するディレクトリ ┗ {tool名} #ex) esa, gitlab, mackerel ...etc ┗ README #ツールの紹介, ツール情報のindexページ ┗ tips #ツールについてのHowToや作業記録など ┗ 手順書 #ツールのアップデート手順など Template #記事のテンプレート一覧 ┗ {テンプレートを配置} Archived #アーカイブした記事が集まる場所 ┗ {アーカイブした記事達}</pre> <p>このような形でざっくり大枠だけでも決めておくことで<br /> 「いつでも・誰でも必要な情報にたどり着ける」環境を作ることができます</p> <h1 id="チーム分割">チーム分割</h1> <p>esaには記事や階層毎での権限分割はできません<br /> これは <strong>情報の透明度</strong> という観点から見れば納得の仕様なのですが、 実際には様々な理由により閲覧できる人を絞りたいケースがあると思います(弊社でもありました)</p> <p>そのため、弊社では複数のチームを用途毎に作成してesaを利用しております</p> <p>チームを分けるといっても <strong>この人には見せたくない</strong> という切り分け方ではなく <strong>この人に見えても邪魔な情報</strong> となるものを分割するにより <strong>必要な情報をより見つけやすくする</strong> ことを目的に情報のカテゴリにあわせてチームを分けてます</p> <p>チームを複数作成すると「チーム毎にユーザ課金されて費用が膨らまないのか」という疑問を持たれる方もいるかと思いますが、esaでは決済連携をすることで <strong>同じ人が複数のチームに参加していても1ユーザとしてカウントされる</strong> という素敵仕様となっているため、その心配はありません!</p> <p>詳しくは公式の情報をご覧ください</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.esa.io%2Fposts%2F190" title="help/複数チームの決済連結(1会社で複数チームを持つ際の、お得な料金決済方法)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://docs.esa.io/posts/190">docs.esa.io</a></cite></p> <h1 id="さいごに">さいごに</h1> <p>今回は弊社で利用している情報共有ツールのesaとその活用方法をご紹介させていただきました</p> <p>対面でのやりとりが減りドキュメントとして知見などを共有することの重要性は高まっている今だからこそ、これまで必要性を感じながらも取り組めていなかったドキュメント化を進めてみてはいかがでしょうか</p> <p>文章に書き起こしながら作業をすることで、自身の頭の中を整理することもできるため個人的には大変おすすめです!</p> <p>この記事がご覧いただいた方の参考に少しでもなれば幸いです</p> show--ya AWS Systems Manager Incident Managerってなに? hatenablog://entry/26006613781596425 2021-08-19T15:00:00+09:00 2022-10-11T12:46:00+09:00 AWS Systems Manager Incident Manager を紹介 概要 Technology & Design Department SREチームで内定者インターンをしている若林と申します。 今年4月からインターンを開始し、様々な経験をしながら日々成長を感じています。 本記事では、AWS Systems Manager Incident Manager(以下、Incident Manager)についてまとめ、AWS初心者ながらも、これからの使用を検討している方、もしくは使用しているがまだあまり理解ができていない方にむけて共有ができれば、と感じております! チームとしてIncid… <h1 id="AWS-Systems-Manager-Incident-Manager-を紹介">AWS Systems Manager Incident Manager を紹介</h1> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/show--ya/20210806/20210806163920.png" width="656" height="368" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h2 id="概要">概要</h2> <p>Technology &amp; Design Department SREチームで内定者インターンをしている若林と申します。 今年4月からインターンを開始し、様々な経験をしながら日々成長を感じています。 本記事では、AWS Systems Manager Incident Manager(以下、Incident Manager)についてまとめ、AWS初心者ながらも、これからの使用を検討している方、もしくは使用しているがまだあまり理解ができていない方にむけて共有ができれば、と感じております!</p> <h2 id="チームとしてIncident-Managerをどう扱っていくか">チームとしてIncident Managerをどう扱っていくか</h2> <p>SREチームではでインシデントの管理や分析のより良い方法を探し続けています。<br /> また、今年からポストモーテムを導入しており効率的な管理方法も求めています。</p> <p>その中で Incident Manager がインシデント管理とポストモーテム作成を行えるとの情報を目にしたため、SREチームとして導入できそうか調査を行いました。</p> <p>本記事では Incident Manager がどういった仕組みで動いているのか、どういったメリットデメリットがあるのか、を紹介します。</p> <p>インシデント管理ツールを選ぶにのあたり、重要になってくる項目として</p> <ul> <li>値段</li> <li>機能</li> <li>汎用性</li> </ul> <p>などがあると思います。 そのため本記事では Incident Manager の上記項目を中心にご紹介できれば、と思っております!</p> <h2 id="Incidentとは">Incidentとは</h2> <p>インシデント、と聞いたときどういったものが頭に浮かびますでしょうか。私は真っ先に「事故、故障」などが思い浮かびました。では実際にインシデントはどういったものなのかを調べると</p> <blockquote><p>3.1.122<br /> incident<br /> event (3.1.96) that can be, or could lead to, a disruption (3.1.75), loss, emergency (3.1.87) or crisis (3.1.60)</p> <p>引用:<a href="https://www.iso.org/obp/ui/#iso:std:iso:22300:ed-3:v1:en">https://www.iso.org/obp/ui/#iso:std:iso:22300:ed-3:v1:en</a></p></blockquote> <p>と記述されていました。<br /> 直訳すると <strong>混乱(3.1.75)、喪失、緊急事態(3.1.87)、または危機(3.1.60)である可能性がある、またはそれらにつながる可能性のあるイベント(3.1.96)</strong> ということになります。</p> <p>要するに「とあるページが画面遷移しなくなった」など、提供しているサービスやシステムがなんらかの理由で停止してしまったり、品質が低下してしまうと、それは<strong>インシデント</strong>になる、ということですね。</p> <p>上記の引用先に飛び <strong>3.1.75</strong> などを検索してみると、混乱が何を指すのかなども記載されておりますので興味のある方は見てみてください。</p> <h2 id="Incident-Manageとは">Incident Manageとは</h2> <p>インシデントが何かわかったところで、それを管理するものはどういったことを表すのでしょうか。 「画面遷移が行われない」という上記の例でいきますと、このインシデントを管理するので</p> <ul> <li>プログラムを修正</li> <li>正常に作動するか確認</li> <li>インシデント解決</li> </ul> <p>あたりだけに注目しがちですが、実際には</p> <ol> <li>インシデントの検出</li> <li>インシデントの分類</li> <li>インシデントの解消<br />  ・担当者によるインシデントの解消対応<br />  ・担当者からエスカレーションし、管理者やマネージャがインシデント解消対応</li> <li>インシデントの記録/分析</li> <li>終了</li> </ol> <p>と、細分化した手順を行って管理する必要があります。</p> <p>こうやってみると意外と面倒だな...という印象かもしれませんが、インシデント管理をすることによってさまざまなメリットがあります。</p> <p>いくつか紹介しますと、</p> <ul> <li>過去に発生したインシデントからその知見を活かし、迅速な対応が可能</li> <li>発生したインシデントを分析することにより、システムやサービスの品質向上</li> <li>トラブル発生から解決までの時間短縮</li> </ul> <p>などがあげられます。 現代においてたびたびAWSの障害がインターネット上でニュースになるように、インシデントが発生しないということはありえません。こういったメリットがあるならば、インシデント管理はやるに越したことはありませんね。</p> <p>また、このインシデント管理の考え方自体はインフラ監視だけではなく、日頃の様々に業務にも応用できますのでぜひ意識してみてください。</p> <p>それでは、ここからはタイトルにも記載してあります Incident Manager のご紹介をさせていただきます。</p> <h2 id="Incident-Managerとは">Incident Managerとは</h2> <p>Incident ManagerはAWSが2021年5月10日にリリースした、まだまだ新参者のツールです。 しかしこのリリースにより今まで苦労していたインシデント管理がAWS内で一括管理できるかもしれない!という期待の眼差ししまくりのツールでした。 ここから Incident Manager がどういった機能を持ち合わせており、どのように設定を行うかをご紹介します。</p> <p>まず、 Incident Manager は、AWS Systems Managerの新機能としてリリースされました。では、AWS Systems Managerにはどういった機能が備わっているのでしょうか。本記事のメインではないので軽くご紹介しますと、</p> <blockquote><p>AWS Systems Manager は、AWS の運用上のハブです。<br /> Systems Manager は、統合されたユーザーインターフェイスを備えており、AWS のアプリケーションとリソース全体の運用上の問題を一元的に追跡および解決できます。</p> <p>Systems Manager を使用すると、Amazon EC2 インスタンスまたは Amazon RDS インスタンスの運用タスクを自動化できます。<br /> また、アプリケーションごとにリソースをグループ化し、監視とトラブルシューティングのための運用データを表示、事前に承認された変更ワークフローを実装し、リソースのグループの運用変更を監査することもできます。</p> <p> Systems Manager によって、リソースとアプリケーションの管理が簡略化され、運用上の問題の検出と解決までにかかる時間が短縮されます。また、大規模なインフラストラクチャの運用と管理を簡単に行えるようになります。</p> <p>引用:<a href="https://aws.amazon.com/jp/systems-manager/">https://aws.amazon.com/jp/systems-manager/</a></p></blockquote> <p>とAWS公式では紹介されていました。ざっくり掻い摘みますと、オンプレミス/AWS両環境で運用に必要な作業の実施を助けるサービス、ということになります。</p> <p>このAWS Systems Managerの新機能としてリリースした Incident Manager ですが、どういった機能を持ち合わせているのか、ご紹介いたします。<br /> (参照:<a href="https://aws.amazon.com/jp/about-aws/whats-new/2021/05/introducing-incident-manager-aws-systems-manager/">AWS Systems Manager の Incident Manager のご紹介</a>)</p> <ul> <li>インシデントが発生した際の対応プランの作成</li> <li>エンゲージメントプランとエスカレーションプランの作成</li> <li>AWS Chatbotとの統合</li> <li>インシデントの追跡</li> <li>インシデントの分析</li> </ul> <p>等がメインの機能として紹介されておりました。 次項から実際に Incident Managerを設定しながら機能などを紹介していきます。</p> <h2 id="事前準備">事前準備</h2> <p>Incident Managerを設定、使用するにあたり、必要なものは下記になります。</p> <ul> <li>AWS アカウント <ul> <li>AWSアカウントに関して、本記事ではルートユーザを用いて設定、準備を行っております。</li> </ul> </li> <li>インシデントを発生させる機能(本記事ではAWS EC2を使用しています) <ul> <li>発生させたインシデントは、EC2サーバのCPU使用率を基準に設定いたしました。ある閾値を設定し、閾値を超えたらアラートを出しインシデントが発生する、という流れになります。</li> </ul> </li> <li>連絡先 <ul> <li>連絡先はインシデントが発生した際に誰に、どの手段で連絡するか、を設定する際に必要ですので、ご準備ください。本記事では記事を書いている若林と同SREチームの先輩の連絡先を設定しました。</li> </ul> </li> <li>AWS Chatbotの設定 <ul> <li>AWS Chatbotの設定などは、様々なサイトで紹介されていますので、割愛させていただきます。<br /> 参考:<a href="https://aws.amazon.com/jp/builders-flash/202006/slack-chatbot/">Slack と AWS Chatbot で ChatOps をやってみよう</a></li> </ul> </li> </ul> <h2 id="実際に-Incident-Managerを設定使用">実際に Incident Managerを設定、使用</h2> <p>ここからは Incident Managerを使用するための設定を行っていきます。</p> <h3 id="Incident-Manager実装までの手順">Incident Manager実装までの手順</h3> <ol> <li>レプリケーションの設定</li> <li>連絡先の設定</li> <li>エスカレーションプランの設定</li> <li>対応プランの作成</li> </ol> <p>上記の手順を踏むことにより、Incident Manager側の設定は完了、となります。 Incident Managerを初めて開く際にAWSが丁寧に紹介してくれるので、そこまで迷子になることはない、と思われます。 <del>迷子になったらAWSが悪いです。</del></p> <h3 id="1-レプリケーションの設定">1. レプリケーションの設定</h3> <p>まずレプリケーションの設定を行います。ここでは、使用しているリージョンが何らかの理由でダウンした際に備え、インシデントデータの複製先を設定します。デフォルトでは Incident Managerを設定しているリージョンが選ばれていますので、もし必要ない場合はデフォルトのままで構いません。本記事ではデフォルトのまま進めさせていただきます。 <img width="842.25" alt="2.PNG (49.6 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/fb79051d-d894-43ea-b161-e27891cc5098.PNG"></p> <h3 id="2-連絡先の設定">2. 連絡先の設定</h3> <p>レプリケーションの設定で<strong>作成</strong>を選択しますと、次は連絡先の設定を行います。 インシデントが発生した際に、<strong>誰に</strong>、<strong>どの手段で</strong>、連絡をするかを設定します。 本記事作成者の意見ではありますが、連絡先は複数作成することを推奨します。理由はエスカレーションプランで説明させていただきます。 連絡先の設定では</p> <ul> <li>連絡先の詳細</li> <li>連絡先チャンネル</li> <li>エンゲージメントプラン</li> </ul> <p>の3つの設定を行います。下記ではそれぞれの詳細をご紹介させていただきます。</p> <h4 id="2-1-連絡先の詳細">2-1. 連絡先の詳細</h4> <p>ここでは、連絡先の名前を設定します。電話帳などに出てくる名前ですね。 <img width="834" alt="3.PNG (24.0 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/701ef04a-161d-46cc-bd23-0a9614979e48.PNG"></p> <p>注意:ここでは、連絡先の名前を人物の名前にしていますが、決して人の名前にする必要はありません。例えば役職の名前や、グループ名などに設定することも可能です。</p> <h4 id="2-2-連絡先チャネルの設定">2-2. 連絡先チャネルの設定</h4> <p>連絡先チャネルでは、Incident Managerが<strong>誰に</strong>、<strong>どの手段で</strong>連絡をするかを設定します。 記入するものとしては</p> <ul> <li>タイプ <ul> <li>どの手段で連絡をするかを設定します。Eメール、SMS、音声メッセージの3つから選択が可能です。</li> </ul> </li> <li>チャネル名 <ul> <li>連絡手段の名前を記入します。下記の画像にもあるように、タイプによって名前を区別するのを推奨いたします。</li> </ul> </li> <li>詳細 <ul> <li>電話番号やメールアドレスなどを記入します。</li> <li><strong>注意</strong> 電話番号を使用する際には、国番号を指定する必要があります。もし日本の電話番号をご使用の場合、先頭に+81をつけ、電話番号を記入してください。 <ul> <li>電話番号が090-1234-5678の場合、<strong>+819012345678</strong>と記載 <img width="822" alt="4.PNG (22.5 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/2f5217e0-a5eb-4aeb-ad69-c5c11ed7778d.PNG"></li> </ul> </li> </ul> </li> </ul> <h4 id="2-3-エンゲージメントプランの設定">2-3. エンゲージメントプランの設定</h4> <p>エンゲージメントプランでは、インシデントが発生後、連絡先チャネルで登録した連絡先に<strong>どのタイミング</strong>で連絡するかを設定します。 本記事ではインシデントが発生直後にEメールを、インシデントが発生から5分後に音声メッセージを送るように設定しました。</p> <p><img width="825.75" alt="6-1.PNG (15.9 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/50ac7f49-35e9-4be4-96ef-86456e4ba24a.PNG"></p> <p>以上で連絡先の設定が完了、となります。 記載はしていませんが、同じ手順により同SREチームの先輩の連絡先も設定いたしました。</p> <h3 id="3-エスカレーションプランの設定">3. エスカレーションプランの設定</h3> <p>エスカレーションプランでは、連絡先を<strong>どのような優先度</strong>で連絡するかを設定します。 例:連絡先で、チームA、チームBの連絡先を設定したとします。この時、チームAの担当箇所でインシデントが発生</p> <ul> <li>チームAの担当箇所なので、最優先で連絡</li> <li>チームAが対応しなかった場合、もしくは対応不可の場合、チームBに連絡</li> </ul> <p>といった形でインシデントの対応の保険をかけることができます。</p> <p>エスカレーションプランでは連絡する優先度を<strong>ステージ</strong>と呼びます。ステージにはステージ1、ステージ2とあり、ステージ数が後になれば優先度は低くなります。ステージ間の時間を設定可能で、最小1分から設定可能です。 本記事では下記のように設定しました。</p> <ul> <li>ステージ1 → 若林</li> <li>ステージ2 → 同SREチームの先輩</li> <li>ステージ1からステージ2に移行するまでの時間 → 2分</li> </ul> <p><img width="1094" alt="Inked7_LI.jpg (501.7 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/17/103442/5553cab6-5f95-412c-aba8-3fcfc6775b1c.jpg"></p> <p>以上でエスカレーションプランの設定は完了です。</p> <h3 id="4-対応プランの作成">4. 対応プランの作成</h3> <p>対応プランとは、インシデントが発生した際に</p> <ul> <li>どういったインシデントで、影響はどれくらいなのか</li> <li>インシデントの概要はどういったものか</li> <li>どのエスカレーションプランを使用するか</li> </ul> <p>を設定します。この対応プランはアラートに紐付き、アラートが発生次第 Incident Managerに通知されます。 それでは、具体的に対応プランを作成していきます。</p> <h4 id="4-1-対応プランの詳細の設定">4-1. 対応プランの詳細の設定</h4> <p>対応プランの名前と表示名を入力し、設定します。 入力する名前には下記のような制約があります。</p> <ul> <li>1 ~ 200文字</li> <li>有効な文字:A ~ Z、a ~ z、0 ~ 9、ハイフン、アンダーバー</li> </ul> <p>表示名はオプションですが、本記事では記入しました。表示名を記入しない場合は対応プランの名前が表示されます。</p> <p><img width="615" alt="8-1.PNG (23.0 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/72e89958-b156-4dde-9ef6-92ae83963a71.PNG"></p> <h4 id="4-2-インシデント作成の詳細の設定">4-2. インシデント作成の詳細の設定</h4> <p>ここでは、下記の設定を行います。</p> <ul> <li>インシデントのタイトルの入力 <ul> <li>インシデントの一覧に表示されるようになるので、識別できるようにしておきましょう。</li> </ul> </li> <li>インシデントの影響度をリストから選択 <ul> <li>影響は「<strong>影響なし、低、中、高、重大</strong>」から選択します</li> </ul> </li> <li>概要では、インシデントの概要を入力 <ul> <li>マークダウンで入力します。どういったインシデントなのか、どういった対応が望ましいのか、などを記入し、誰が見ても対応に困らないようにしておくことを推奨します。</li> </ul> </li> </ul> <p><img width="611.25" alt="8.PNG (42.9 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/683f5bfa-cbcf-439f-855f-80b004c0a817.PNG"></p> <h4 id="4-3-チャットチャネルの設定エンゲージメントプランの選択---オプション">4-3. チャットチャネルの設定、エンゲージメントプランの選択 - オプション</h4> <p>インシデント対応時の関係者連絡をするためのチャットチャネルを指定します。 ここでは事前準備であらかじめAWS Chatbotを設定します。 本記事ではSlackのチャネルを設定しました。 エンゲージメントプランの選択も行います。 先ほど作成したエンゲージメントプランを選択しました。</p> <p><img width="616.5" alt="9.PNG (47.1 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/a8503157-9827-4e9f-b947-23e12a9ad5d8.PNG"></p> <p>以上で、対応プランの作成が完了します。</p> <h2 id="テスト環境での実施">テスト環境での実施</h2> <p>Incident Managerの設定が完了しましたので、あとはインシデントが発生した際の動作確認を行うだけです。さすがに本番環境でインシデントが発生するのを待つのは怖いので、本記事ではテスト環境として以下のような環境を用意しました。</p> <ul> <li>AWS EC2を使用し、CPU使用率を監視するアラートを作成</li> <li>CPU使用率が閾値を超えた場合、アラートが発生し、Incident Managerで作成した対応プランが動作</li> </ul> <p>それでは、アラートに対応プランを紐付けするところから行きましょう。 アラートはAWS CloudWatchで設定をしています。アラート作成画面の遷移中、<strong>System Manager アクション</strong>の設定があります。そこで先ほど作成した対応プランを指定します。</p> <p><img width="590.25" alt="11.PNG (23.0 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/b0bde3bf-c279-4ba4-a4fc-33a072e5c4de.PNG"></p> <p>それでは、アラートを発火してみましょう。<br /> 今回はCPU使用率の監視設定を1%以上に設定することでアラートを発生させました。</p> <h2 id="Incident-Managerを用いたインシデント対応">Incident Managerを用いたインシデント対応</h2> <p>インシデント管理の手順に沿って対応方法をご紹介します。</p> <h3 id="1-インシデント検出">1. インシデント検出</h3> <p>インシデントが発生しますと、Incident Manager / Slack / 対応プランに登録した連絡先 に通知が来ます。それぞれの通知は下記の通りです。</p> <h4 id="Incident-Manager">Incident Manager</h4> <p><img width="1165.5" alt="12.PNG (32.7 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/cc6c483c-6345-4920-be3e-508b37da4917.PNG"></p> <h4 id="Slack">Slack</h4> <p><img width="950" alt="Inkedslack imfromed_LI.jpg (163.2 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/17/103442/013573aa-ed2a-47f1-963c-0586002d43a4.jpg"></p> <h4 id="メールアドレス">メールアドレス</h4> <p><img width="1189.5" alt="mail.PNG (24.6 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/fc0557d5-4a14-426c-80b4-ed29c96f3b2c.PNG"></p> <h4 id="音声メッセージ">音声メッセージ</h4> <p>音声メッセージに関しては、内容として</p> <ul> <li>インシデントのタイトル(対応プランの名前)</li> <li>影響の大きさ</li> </ul> <p>が英語でループされます。ものすごく焦らせてきます(汗)</p> <h3 id="2-インシデントの分類">2. インシデントの分類</h3> <p>Incident Managerの通知を選択しますと、以下のような画面に遷移します。 <img width="1792" alt="InkedInked13_LI.jpg (893.5 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/17/103442/82fb074b-09a1-405c-8b7e-25b4e71caa13.jpg"> (アカウントIDは伏せています)</p> <p>ここではインシデントの概要、メトリクス、タイムライン、エラー文などが記載されており、インシデント発生から何分経過したのかも見ることが可能になっています。</p> <p>これらの情報を元に、過去同様のインシデントが発生していないかなどを調査します。</p> <h3 id="3-インシデント解決">3. インシデント解決</h3> <p>インシデントの解決方法自体はインシデント毎に異なるため、今回は解決できたこととします。</p> <p>インシデントが解決しましたら、右上にある<strong>インシデントを解決</strong>を押します。 インシデントが解決することにより、インシデントを分析することが可能になります。 インシデントが解決したことSlackのチャネルにも通知されるので、関係者も解決したことを知ることができます。</p> <h3 id="4-インシデントの記録分析">4. インシデントの記録/分析</h3> <p>インシデントの分析を開始しますと、分析のタイトル記入と、分析に用いるテンプレートを選択します。 本記事ではAWSのテンプレートを選択し、分析を作成しました。</p> <p><img width="498" alt="17.PNG (24.3 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/09/103442/9427df05-60ac-43db-a9e2-bc61655b2f1f.PNG"></p> <p>分析では、</p> <ul> <li>インシデントの概要</li> <li>タイムライン</li> <li>インシデントに関しての質問</li> <li>アクション項目(どういった対応をしたのかを記入する場所)</li> </ul> <p>などを記入します。この記入項目を自由に設定できますが、AWSのテンプレートがインシデント管理の「お約束」といえる項目を用意してくれているため、そのまま利用できます。</p> <h4 id="4-1-インシデント分析---概要">4-1. インシデント分析 - 概要</h4> <p>概要では、インシデントの内容、なぜ発生したのか、どう対応したのか、インシデントが発生したことによりどういった影響が出たのか、をマークダウンで記入することが可能です。 <img width="1574" alt="Inked18_LI.jpg (622.9 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/17/103442/bcd8a5b1-a211-47a4-8f52-e10926d833c7.jpg"></p> <h4 id="4-2-インシデント分析---タイムライン">4-2. インシデント分析 - タイムライン</h4> <p>タイムラインでは、どの時刻に、なにが起こったのかを時系列で表示してくれます。 タイムラインには任意で追加が可能になっており、下記の画像のように反映されます。</p> <p><img width="462.75" alt="5.PNG (16.4 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/17/103442/e6da7a3b-6d3a-481f-9d9e-e005266e1bb6.PNG"></p> <p>対応した時間、作業内容などを記入します。本記事では「テスト」と記入しました。</p> <p><img width="1540" alt="Inked6_LI.jpg (518.2 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/30/103442/98d41fd7-29e2-4e3a-8e1d-f7b4ad7f9fac.jpg"></p> <p>タイムライン上に「テスト」が追加され、どの時間にどういったことを行ったのかが可視化されて分かりやすくなっています。</p> <h4 id="4-3-インシデント分析---インシデントに関しての質問">4-3. インシデント分析 - インシデントに関しての質問</h4> <p>AWSが所有している質問のテンプレートに対し回答していきます。テンプレートが質問してくる項目としては</p> <ul> <li>検出</li> <li>診断</li> <li>緩和策</li> <li>防止</li> </ul> <p>があり、それぞれを回答していくことにより今後の対応策などが見えてきます。</p> <p><img width="900.75" alt="1.PNG (63.2 kB)" src="https://img.esa.io/uploads/production/attachments/12996/2021/06/17/103442/7685e97d-1722-4535-94f3-3797933d1203.PNG"></p> <h4 id="4-4-インシデント分析---アクション項目">4-4. インシデント分析 - アクション項目</h4> <p>アクション項目では、インシデントが発生した際に、どういったアクション(対応、行動)を取ったのかを記入し、まとめることができます。 アクション項目に記入する項目としては、 * アクションのタイトル * アクションの説明 * アクションの優先度 * アクションの作業量(サイズ)</p> <p>でした。</p> <h4 id="5-インシデント分析---まとめ">5. インシデント分析 - まとめ</h4> <p>Incident Manager の分析を用いることにより、下記の利点がある、と感じました。</p> <ul> <li>インシデントへの対応の明確化</li> <li>インシデントの根本原因を理解</li> <li>インシデントの影響の分析</li> <li>組織内での学習と、共有</li> </ul> <p>インシデントをただ解決するのでなく、そのインシデントが二度と発生しないための対策までを行うので、分析を使わない手はない、と強く思います。</p> <h2 id="Incident-Manager-の料金">Incident Manager の料金</h2> <p>やはりここまで便利な機能を持ち合わせている Incident Manager なので、料金は発生します。 料金は下記の通りです。</p> <ul> <li>1 か月でアクティブな対応計画の数に基づいて課金</li> <li>1 か月あたり最大 100 件の SMS または音声メッセージが含まれる <ul> <li>追加のメッセージは、受信者の国に応じて課金されます。</li> </ul> </li> </ul> <p>参考:<a href="https://aws.amazon.com/jp/systems-manager/pricing/">&#x6599;&#x91D1; - AWS Systems Manager | AWS</a></p> <p>対応プランの数により、基本的な料金が変わってきます。対応プラン1つの料金は月$7となっています。 参考先リンクに、料金例も記載してありますので、気になる方はそちらもご確認ください。</p> <p>また、複数のAWSアカウントを利用している場合、例えば10個のAWSアカウントを所持しており、それぞれのアカウントが2つの対応プランを作成した場合、月額としては <strong>10アカウント × 2プラン × 7ドル</strong> となり、月に <strong>$140</strong> となります。</p> <p>DataDogなど他のインシデント管理ツールと比較した際に、アカウントを所持すればするほどお金がかかってしまうのがIncident Managerなので、どのインシデント管理ツールを使用するか、悩みどころですね。。。</p> <h2 id="まとめ">まとめ</h2> <p>以上で Incident Manager の流れになります。 Incident Manager を使用することにより、インシデント発生からインシデントの分析までを行うことが可能です。<br /> しかし、AWS以外のインシデント管理ツールにあって、Incident Manager にない機能などは様々あると思います。ただし、 Incident Manager は2021年の5月にリリースされたばかりなので、まだこれから様々な機能が追加されると予想されています。今後の AWS Systems Manager Incident Manager に期待しましょう!</p> wakahiro186 AWS SAPを取得しました! hatenablog://entry/26006613683347300 2021-04-27T09:00:00+09:00 2022-10-11T12:48:07+09:00 Technology & Design Department SREチームのUsekです。 昨年11月末にAWS Solution Architect Professional(AWS SAP)に合格しました。 自分で言うのもアレなのですが、この資格はかなりレベルの高い資格です。 そのため画面に”合格”と表示された時には自分の見間違えと疑い、正式に合格通知が来るまではつぶやけなかったくらいです(笑) インターネット上には合格記を書いている方はたくさんいらっしゃいますが、せっかくなので私も合格までの軌跡を記します。 ちなみに勉強期間は1年になります。ネット上には2ヶ月で合格、3ヶ月で合格、という… <p>Technology &amp; Design Department SREチームのUsekです。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/U/Usek/20210126/20210126164513.png" width="602" height="358" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>昨年11月末にAWS Solution Architect Professional(AWS SAP)に合格しました。<br /> 自分で言うのもアレなのですが、この資格はかなりレベルの高い資格です。<br /> そのため画面に”合格”と表示された時には自分の見間違えと疑い、正式に合格通知が来るまではつぶやけなかったくらいです(笑)<br /> インターネット上には合格記を書いている方はたくさんいらっしゃいますが、せっかくなので私も合格までの軌跡を記します。<br /> ちなみに勉強期間は1年になります。ネット上には2ヶ月で合格、3ヶ月で合格、という記事もありますがその人たちに比べると私の学習は泥臭いものでした。<br /> 私は元々クラウドの豊富な知識も、業務経験があったわけではないので、同じような人にとって参考になると幸いです。</p> <h3 id="AWS-SAP-とは">AWS SAP とは</h3> <p><a href="https://aws.amazon.com/jp/certification/">AWSはいくつか資格を用意しています</a>が、その中でも<a href="https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/">AWS Solution Architect Professional</a>、略してAWS SAPは上位の資格の1つです。<br /> AWS におけるシステムの管理および運用に関する 2 年以上の実務経験を持つソリューションアーキテクト担当者を対象としています。<br /> AWSにおける多種多様な知識と、その名前の通り「解決策を描く能力」が要求されます。</p> <p>バレットグループに入社する前に、クラウド時代の技術トレンドを把握したいと考えAWS Solution Architect Associate(AWS SAA)は取得していました。<br /> しかし、SAAと比べるとSAPは全く別物の試験といえます。</p> <p>まず、言うまでもありませんが難易度が違います。<br /> SAAはAWS内の各サービスの知識を問います。<br /> 一方SAPは知識を前提として、複数のサービスを組み合わせて最適な解決策を問います。<br /> 提示されるシチュエーションは実践的かつ広範囲です。SAAでは出題されないサービスも多数問題として現れます。<br /> 私が受けた時のSAAは正答率65%で合格だった記憶がありますが、SAPは正答率を75%必要とされます。この10%が非常に大きいです。</p> <p>次に、たとえ十分な知識と経験を持っていても、その回答が最適でない場合は間違いになります。<br /> 模擬問題で回答を見ても「本当にそうか?自分の考えのほうが正しいのではないか?」と納得がいかないこともありました。<br /> 私は<a href="https://blog.bltinc.co.jp/entry/2020/12/02/000000">前回の記事</a>で書いたように、セキュリティを担当しているということもあり、<br /> ”費用がかかっても安全な方法を採用したい”という思いがあります。<br /> しかし回答では「その回答はセキュリティとして過剰、費用がかかるから不適」となります。<br /> どこまでが過剰なのかを判断することは難しいですが、×は×、受け入れるしかありません。</p> <p>最後に試験のボリューム。制限時間の180分で75問を解く必要があります。<br /> 1つの問題を2分半で回答する必要がありますが、問題文は長文が多く、じっくり読んでいると時間が足りません。<br /> プロフェッショナルにふさわしい実力を持っていたとしても、試験の時間配分に慣れていないと”そもそも75%問いていない”ということにもなってしまうでしょう。<br /> 余談ですが、試験問題が英文を機械的に和訳したものなので、カタカナ用語が多いこともあり、意味がわかりにくい問題文が表記されることがあります。<br /> 試験では英語の原文も見ることができるので、日本語が腑に落ちなかったらそちらを見るとよいです。平易な英語で書かれています。</p> <h3 id="なぜAWS-SAPを受験しようとしたのか">なぜAWS SAPを受験しようとしたのか</h3> <p>AWSを本格的に業務で利用するようになったのはバレットグループに入社してからになります。<br /> バレットグループは提供するサービスの大半でAWSを使用しているので、知らないでは済まされません。<br /> 業務で使用しているサービスを都度調べているだけでは成長スピードが上がりませんし、<br /> 今現在使用していないサービスを利用した新しいシステムを生み出すことも難しいでしょう。<br /> 自己研鑽と実益を兼ねて試験勉強に取り組もうと決めました。<br /> 最初に書いたように、AWS SAPは2 年以上の実務経験を想定しています。<br /> 業務でAWSを使い始めてから1年で取得するという、自分にとっては高い目標を定めました。</p> <h3 id="1度目の受験2020年6月まで">1度目の受験(2020年6月)まで</h3> <p>入社直後の2019年10月に開催されたAWS Innovate オンラインカンファレンス<br /> <a href="https://aws.amazon.com/jp/blogs/news/aws-innovate-20191001/">AWS Innovate オンラインカンファレンス 〜初心者から上級者までクラウドの最新情報がわかる 60 セッション〜</a> <br /> 内に「AWS認定-試験対策-ソリューションアーキテクト-プロフェッショナル-」のカンファレンスがあったので受講しました。<br /> どんな分野が出るのかを簡単な模擬問題を含めて説明を受けました。<br /> これを視聴した当時は「そんなに難しくなさそう」と考えた記憶があります(苦笑)</p> <p>次に<a href="https://www.aws.training/Details/eLearning?id=42403">Exam Readiness: AWS Certified Solutions Architect – Professional (Japanese)</a>という<br /> 公式のトレーニング(英語の翻訳が画面下に表示される動画)を受講しました。<br /> 内容はそれほど濃くありませんし、すぐに修了しますが、雰囲気を掴むには良いコンテンツだと思います。</p> <p><a href="https://aws.koiwaclub.com/">AWS WEB問題で学習しよう</a></p> <p>こちらのサイトはいわゆる「黒本」と呼ばれるもので、SAAでお世話になった人もいるのではないでしょうか。<br /> 有料ですがSAPをはじめ、AWSの資格の問題がたくさん載っています。<br /> ですが、個人的な印象として、「ちょっと本物の問題とは趣が違うな・・・」という印象です。難易度も本物のほうが高いです。<br /> SAP自体が近年大きく改訂されたことも影響しているのかもしれません。<br /> こちらのサイトの正解率が高いことは重要ですが、高いならば試験に合格するか、といわれると「NO」だと思います。</p> <p><a href="https://jayendrapatil.com/aws-certified-solution-architect-professional-exam-learning-path/">Jayendra's Cloud Certification Blog</a></p> <p>外国人の個人ブログですが、AWS試験界隈では有名どころです。<br /> というよりSAPの勉強方法は限られているため皆ここに行きつきます(笑)<br /> 各ページをGoogle翻訳して学習しました。手を抜かずに一つ一つ分からない単語を調べていくと結構な時間がかかります。<br /> それでもAWSサービスの使い方を深く、かつ短い文章で説明してくれているこのサイトは大変役に立ちます。</p> <p><a href="https://www.udemy.com/course/aws-53225/">AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集</a></p> <p>普段からお世話になっている動画学習サイトUdemyにある唯一の日本語の模擬問題集です。<br /> 出てくる問題の雰囲気は本番に近いですが、やはり本番より難易度は低いと思います。<br /> とはいえ貴重な模擬問題集。ここに書かれていることは全て覚えるつもりで学習しました。</p> <p>上記の模擬問題を何回か繰り返し、非常事態宣言が開けた6月末に試験を受けました。<br /> ・・・が、もう途中から「これは無理だ」となりました。事前に学習した問題よりずっと難易度は高かったです。<br /> SAPの問題は広範囲に及びます。模擬問題に出てこないかつ通常業務で使わない知識が要求されるとお手上げです。<br /> 60%とぜんぜん足らず不合格でした。</p> <h3 id="2度目の受験2020年11月まで">2度目の受験(2020年11月)まで</h3> <p>AWS SAPの取得を諦め、目標も達成できないと気落ちしていたところに以下の書籍が発売されました。</p> <p><a href="https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88-%E3%83%97%E3%83%AD%E3%83%95%E3%82%A7%E3%83%83%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%AB-%E8%A9%A6%E9%A8%93%E7%89%B9%E6%80%A7%E3%81%8B%E3%82%89%E5%B0%8E%E3%81%8D%E5%87%BA%E3%81%97%E3%81%9F%E6%BC%94%E7%BF%92%E5%95%8F%E9%A1%8C%E3%81%A8%E8%A9%B3%E7%B4%B0%E8%A7%A3%E8%AA%AC-%E5%B9%B3%E5%B1%B1-%E6%AF%85/dp/4865942483/ref=asc_df_4865942483/?tag=jpgo-22&amp;linkCode=df0&amp;hvadid=342428724851&amp;hvpos=&amp;hvnetw=g&amp;hvrand=17253666351252475668&amp;hvpone=&amp;hvptwo=&amp;hvqmt=&amp;hvdev=c&amp;hvdvcmdl=&amp;hvlocint=&amp;hvlocphy=1009342&amp;hvtargid=pla-919621259218&amp;psc=1&amp;th=1&amp;psc=1">AWS認定ソリューションアーキテクト-プロフェッショナル 試験特性から導き出した演習問題と詳細解説 </a></p> <p>念願の日本語のAWS SAP本。未だにSAPの日本語参考書・問題集としては唯一のはずです。<br /> SAP合格に必要とされる様々なサービスがカテゴリーごと網羅的かつ分かりやすくまとめられています。<br /> 最後に掲載されている模擬問題も実践の問題に近いです。<br /> この本に書かれている内容はJayendraさんのブログと併せてすべて頭の中に叩き込もうとしました。</p> <p>やる気が再度燃え上がり、前回の試験の感触から「まだまだ足りない」と考えさらに学習教材を探すことにしました。</p> <p><a href="https://aws.amazon.com/jp/architecture/well-architected/">AWS Well-Architected</a></p> <p>Well-ArchitectedはAWS公式の「AWSを活用するためのベストプラクティス集」。<br /> 業務で度々目にする内容ですが、今一度初心に帰ろうと、内容を一通り読みました。<br /> 記憶から漏れていた知識・サービスがあることに前回の学習がぬるかったことを再認識し、ノートにまとめました。</p> <p><a href="https://www.udemy.com/course/aws-solutions-architect-professional-practice-exams-amazon/">AWS Certified Solutions Architect Professional Practice Exam</a></p> <p>もう日本語教材だけなどと甘えていられない、とUdemyで英語の問題集を購入しました。<br /> 先紹介した日本語のUdemy AWS SAP対策と似た内容でした。こちらを日本語の模擬問題同様75%正解できるように何回も解きました。<br /> 何回やっても覚えられないものですね・・・。</p> <p><a href="https://www.udemy.com/course/aws-solutions-architect-professional/">Ultimate AWS Certified Solutions Architect Professional</a></p> <p>こちらは問題集ではなく、AWS SAPに出題されるサービスと抑えるべき勘所をスライドで紹介している動画コンテンツになります。<br /> ”Ultimate”すなわち”究極”とタイトルされていますが、素晴らしい内容でした。実際この内容から出題された記憶もあります。<br /> ボリュームが多い上に全文英語なのでやり切るにはエネルギーが必要ですが、私を合格に導いてくれたと思っています。<br /> かなりお高いので割引のタイミングを逃さないようにしましょう(笑)</p> <p>1回目の挑戦で用いた模擬問題を含め、何回もやり直ししました。<br /> 当初11月の3連休前に受ける予定でしたが、悔いを残したくないと思い1週間先にリスケしました。<br /> 世間では3連休Gotoとかなんとか言われていたみたいですが、朝から晩まで試験勉強漬け状態でした。<br /> 2020年は不幸にも行動が抑制される一年でした。ただ、「コロナのせいで停滞してたまるか」という気持ちは持ち続けていました。</p> <p>2回目の試験は1回目とはぜんぜん異なり、かなりの手ごたえがありました。<br /> すべての問題を解いた後、もう1回見直ししてなお時間に余裕がありました。1回目はいくつか問題を飛ばしてギリギリ終了だったような。<br /> それだけの手応えがあってもなお、試験終了のボタンを押すのは非常に緊張しました。<br /> 最初に書いたように、画面に合格の文字が出た時には最初書いたように、見間違いを恐れて喜ぶことができませんでした。<br /> 合格スコアはかなり薄氷で、これだけの手ごたえがあってなおギリギリなのか・・・と改めてAWS SAPの難しさを再認識しました。<br /> AWS SAPを取得した結果、AWSについてまだまだ理解が足りないということが理解できました(笑)</p> <h3 id="資格取得後">資格取得後</h3> <p>せっかく得た知識も使わないとどんどん忘れていってしまうものです。<br /> 幸い他メンバーがAWSのアーキテクチャの成否や、実現したい要望を私に相談してくれます。<br /> (知らないことばかりだな・・・)と調べながら回答しています。<br /> AWS SAPを取得し、AWSのことがまだまだ分かっていないということが分かりました(笑)</p> <p>そもそもAWSも物凄いスピードでサービスが追加・更新されています。<br /> たとえば、私が試験を受けた2020/11/22時点ではKinesis Data Streamsのデータ保持期間は1週間でした。<br /> 「長期間のデータ保持にKinesisは向かない」とされていましたが、AWS re:Invent 2020で<a href="https://aws.amazon.com/jp/about-aws/whats-new/2020/11/amazon-kinesis-data-streams-enables-data-stream-retention/">保持期間1年のアナウンス</a>。<br /> これまでシングルAZにのみ対応だった<a href="https://aws.amazon.com/jp/about-aws/whats-new/2020/12/amazon-redshift-launches-ability-easily-move-clusters-between-aws-availability-zones/">Redshiftが別AZに移動できる</a>ようになったり、これまで使えなかった<a href="https://aws.amazon.com/jp/about-aws/whats-new/2020/12/announcing-amazon-route-53-support-dnssec/">DNSSECをRoute53がサポート</a>されたりと、早くも知識が古くなっています。恐ろしい・・・。</p> <h3 id="最後に">最後に</h3> <p>バレットグループはAPN(AWS Partner Network)に所属しています。<br /> AWSのパートナーを名乗るに相応しい会社であるべく、私以外のメンバーも学習と研鑽を続けています。<br /> 今後もAWSのみならず、様々な技術に関してカラフルバレットで発信していけるよう、頑張ります。</p> Usek 【2行読めばOK!】UI/UXについて「ちょっと」だけ理解する。 hatenablog://entry/26006613617484781 2021-01-12T09:00:00+09:00 2022-10-12T14:03:05+09:00 皆さんこんにちは! Technology Departmentのデザインチームに所属している、かみしろです。 近年、デザインの世界において「UI/UX」というワードを耳にする機会が増えてきました。 聞いたことはあるけれど、あまり理解出来ていない! そもそも「UI/UX」って何?って思っている方もいるのではないでしょうか? 今回は、UI/UXについて書いてみました。 デザイナーとコミュニケーションをとるときにも役立つと思うので、ぜひ読んでみてください。 結論から書きます。 UI/UXとは? UI(見た目) UX(製品やサービスを利用して感じたこと) 次から具体的に書いていきます。 何となく分かっ… <p>皆さんこんにちは! <br> Technology Departmentのデザインチームに所属している、かみしろです。</p> <p>近年、デザインの世界において「UI/UX」というワードを耳にする機会が増えてきました。<br> 聞いたことはあるけれど、あまり理解出来ていない!<br> そもそも「UI/UX」って何?って思っている方もいるのではないでしょうか?</p> <p>今回は、UI/UXについて書いてみました。<br> デザイナーとコミュニケーションをとるときにも役立つと思うので、ぜひ読んでみてください。</p> <p>結論から書きます。<br> UI/UXとは?</p> <div style="border:2px solid #cccccc; border-radius:10px; margin:15px 0;padding:15px 10px;"> <ul>  <li>UI(見た目)</li>  <li>UX(製品やサービスを利用して感じたこと)</li> </ul></div> <p>次から具体的に書いていきます。<br> 何となく分かったからOK〜。<br> 読むのに疲れたよ〜。って方は、最後まで読まなくて大丈夫です!</p> <h1 id="UIとは" style="border-left:3px solid #59CACC; text-indent:10px;">UIとは?</h1> <p>UIとは「User Interface(ユーザーインターフェース)」の略称です。<br> 一般的に、ユーザーと製品やサービスとのインターフェース(接点)のことを指します。</p> <p>Webサイトであれば、 「デザイン」「フォント」「色」「画像」「ボタン」など ユーザーの目に触れる外観はすべて「UI」です。</p> <h1 id="UXとは" style="border-left:3px solid #59CACC; text-indent:10px;">UXとは?</h1> <p>UXとは「User Experience(ユーザーエクスペリエンス)の略語です。<br> 一般的に、ユーザーが製品やサービスを利用して得られる体験のことを指します。</p> <p>これだけだと少し分かりにくいですね。<br> ECサイトを例に考えてみましょう。</p> <p>ECサイトで買い物をしたときにこんなことを感じたことはありませんか?</p> <ul> <li>欲しい商品がすぐに見つかる</li> <li>商品購入の導線が分かりやすい</li> <li>カスタマーセンターの対応がよかった</li> <li>商品写真と実物が異なる</li> <li>商品発送が遅い</li> </ul> <p>など、いろいろな感情が生まれたことがあると思います。<br> 製品やサービスを利用する一連の中で、感じたこと全てがUXです。<br> 良い感情も悪い感情も全てUXです。</p> <h1 id="UIとUXの関係って" style="border-left:3px solid #59CACC; text-indent:10px;">UIとUXの関係って?</h1> <p>何となくUI/UXについてご理解いただけたでしょうか?<br> この2つは全くの別物ですが、切り離して考えることは難しいのです。</p> <p>優れたUXを提供するには優れたUIが必要になります。<br> 先ほど同様、ECサイトを例に考えてみましょう。</p> <p>下記のようなECサイトがあります。</p> <ul> <li>フォントが読みにくい</li> <li>お問い合わせフォームが使いにくい</li> <li>商品購入のボタンが分かりにくい</li> </ul> <p>どうでしょうか?<br> きっと多くの人は、もう使いたくないと感じたと思います。</p> <p>低クオリティのUIは、ユーザーに不快感やストレスを与えてしまいます。<br> 結果、UXを下げる要因につながります。</p> <p>なので、優れたUXを提供するには優れたUIが必要です。</p> <h1 id="まとめ" style="border-left:3px solid #59CACC; text-indent:10px;">まとめ</h1> <p>UI/UXとは?</p> <div style="border:2px solid #cccccc; border-radius:10px; margin:15px 0;padding:15px 10px;"> <ul>  <li>UI(見た目)</li>  <li>UX(製品やサービスを利用して感じたこと)</li> </ul></div> <p>UI/UXについて「ちょっと」だけご理解いただけたなら嬉しいです!<br> 最後まで読んでいただきありがとうございました!</p> m9kami Programmerであること hatenablog://entry/26006613668416951 2020-12-25T00:00:00+09:00 2022-10-12T14:03:20+09:00 Bullet Group Advent Calendar 2020 25日目の記事です。 こんにちは、@syl-k です。 これまでお読みいただいた皆さん、本当にありがとうございました。 25日、最終日のアドベントカレンダーでは、先日広島県江田島市で開催させていただいた小学生向けプログラミング教室と、それを通じて何を伝えていきたいのかについて投稿していきます。 江田島プログラミング体験教室 2020年11月28日に広島県江田島市にあるコワーキングスペース フウドさんで小学生を対象にしたプログラミング体験教室を開催させていただきました。 というのもバレットグループが広島で開発ラボを立ち上げる際、… <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 25日目の記事です。</p> <p>こんにちは、@syl-k です。</p> <p>これまでお読みいただいた皆さん、本当にありがとうございました。<br /> 25日、最終日のアドベントカレンダーでは、先日広島県江田島市で開催させていただいた小学生向けプログラミング教室と、それを通じて何を伝えていきたいのかについて投稿していきます。</p> <h2 id="江田島プログラミング体験教室">江田島プログラミング体験教室</h2> <p>2020年11月28日に広島県江田島市にあるコワーキングスペース フウドさんで小学生を対象にしたプログラミング体験教室を開催させていただきました。<br /> というのもバレットグループが広島で開発ラボを立ち上げる際、実に多くの方にご協力いただき、その方々になにか恩返しがしたい!、バレットが来てよかった!と思ってほしいと純粋に思ったのがきっかけです。<br /> そこで<br /> <b>「せっかく開発ラボでエンジニアがいるだからプログラミング教室をやろう!」</b><br /> と思ったことが始まりでした。</p> <h3 id="準備から実際にやってみて">準備から実際にやってみて</h3> <p>準備期間約1ヶ月、予算も時間もない中で小学校低学年の子供たちが来て何が一番楽しんでもらえるのか、テクノロジーやプログラミングを通じて何を教えていきたいかと常に考える期間でした。</p> <p>結果、キャラクターの3Dモデルを使って簡単な会話ができるアプリを作成し、子供たちに身近にあるテクノロジーを体験してもらえるようにしました。 <br> 生まれたときからスマートフォンがある世代でありながら、PCに向かって様々なことを話しかけている様子を見て、初めての体験を与えることができたのではと思います。</p> <p>また閉会後はご両親の方々ともお話しもさせていただき、プログラミングとは何なのか、小学校のプログラミング授業や宿題についてなどたくさんのお話しをさせていただきました。 <br> お子さんへ体験教室をすると同時に、あまりITにふれる機会の少なかったご家族の方へ説明する場を設けることと共感を得る重要性も感じた貴重な時間でした。</p> <h2 id="プログラミングを通したIT教育">プログラミングを通したIT教育</h2> <p>つまるところプログラミングとはどういうものなのでしょうか?</p> <ul> <li>英数記号から成るプログラムを書きシステムを作ること</li> <li>次々と新しいものが出て、なんか難しそうなこと</li> <li>最近流行っている職業で、PCの前に座り黙々とキーボードを叩くこと</li> </ul> <p>などなど</p> <p>多くの印象があると思います。 <br> パーソナルコンピューターが一般化されてから2020年までのIT発展は凄まじいものです。 <br> 年々新しいテクノロジーやサービスが出てくるため扱う技術の幅も種類も増えてきていますし、それに比例して多くの企業でエンジニア採用が進んでいます。 <br> また集中できる環境で黙々と作業することが楽しく感じる人も多く、その分話しかけづらいなどの印象を持たれている人も多いのではないでしょうか。 <br> そういう人たちによる専門職の印象はあると思います。</p> <p>しかし、それと同時にテクノロジーを学ぶためのハードルもどんどん下がってきています。 <br> オンラインスクールや学習教材の充実、プログラミング言語の発達と最近ではノーコードと呼ばれるプログラミングをしなくてもシステムが組めるサービスも出てきました。 <br> いい意味で専門性が薄くなり、システムエンジニアでない人でも深いテクノロジーの知識を持っている方が増え、ビジネスに活かされています。</p> <h3 id="プログラミングを学ぶ意味">プログラミングを学ぶ意味</h3> <p>このような状況だからこそ気軽に子供たちにはプログラミングを学んでほしいなと個人的には思っています。 <br> それは「プログラミングのスキルを学んでシステムエンジニアになってほしい」という意味ではなく、プログラミングを通してロジカルシンキングと課題解決能力が学べると思っているからです。</p> <p>よくプログラムは「思った通りのは動かない。書いた通りに動く」と言われます。 <br> <b>コップを持つ</b>というプログラムを書くだけでも一苦労です。</p> <p>右手で持つのか、左手で持つのか、持つだけで持ち上でなくていいのか、そもそもどのコップを持つのか、考えようと思えばいくらでも「コップを持つ」という動作で必要な要素は考えられます。 <br> 本当は左手で持たせたいのに右手で持ってしまうのは、そのようにプログラムを書いてしまったためです。 <br> 一見細かい部分ではありますが、その要素を理解してプログラミングできるということは、暗黙的に伝えるのではなく、自分が何を伝えたいのかしっかりと理解できる力を持てることだと思います。</p> <p>またコップを持ち上げるプログラムが、動かしてみると持ち上げることができない場合、 <br> 「なぜ持ち上げられないのだろう?」、「コップは本当につかめているのか?」、「手を前に差し出せているのか?」、「そもそもコップはそこにあるのか?」 <br> など正常に動かない原因をいくつも考え、正しいものを探し出し、解決まで導く力を育もことにつながると思います。</p> <p>今後も多くのITサービスが出て来るでしょうし、コロナのような問題も多くあると思います。 <br> そういう状況でもしっかりと乗り越える力をつける一助になるよう、バレットグループでもプログラミング教室を続けていければと思います。</p> <p>このブログはBulletGroupが運営しております。 BulletGroupについてはこちら <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbltinc.co.jp%2F" title="バレットグループ株式会社/Bullet Group Inc." class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p> syl-k 4Kディスプレイを導入したら作業が快適になりました hatenablog://entry/26006613659929034 2020-12-24T00:00:00+09:00 2022-10-11T12:52:03+09:00 Bullet Group Advent Calendar 2020 24日目の記事です。 こんにちは、佐藤です。 最近ではリモートワークの機会増えたことにより、 作業環境を整えた方もいらっしゃるのではないでしょうか? 今回は私がリモートワークの際に4Kディスプレイを購入して、 半年ほど使用した際に感じたメリットを紹介していきたいと思います。 購入した4Kディスプレイ 31.5インチのディスプレイを購入しました。 購入した商品はこちらです。 (2020年4月に購入した時は、56000円くらいでした) どうして4Kディスプレイを買おうと思ったか 前の常駐先の先輩にオススメされたことがきっかけです。… <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 24日目の記事です。</p> <p>こんにちは、佐藤です。</p> <p>最近ではリモートワークの機会増えたことにより、 <br/> 作業環境を整えた方もいらっしゃるのではないでしょうか?</p> <p>今回は私がリモートワークの際に4Kディスプレイを購入して、 <br/> 半年ほど使用した際に感じたメリットを紹介していきたいと思います。</p> <h3 id="購入した4Kディスプレイ">購入した4Kディスプレイ</h3> <p>31.5インチのディスプレイを購入しました。 購入した商品はこちらです。 <br/> (2020年4月に購入した時は、56000円くらいでした) <br/> <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.amazon.co.jp%2FPro%25E5%25AF%25BE%25E5%25BF%259C%25E3%2580%2591BenQ-%25E3%2583%2587%25E3%2582%25A3%25E3%2582%25B9%25E3%2583%2597%25E3%2583%25AC%25E3%2582%25A4-EW3270U-31-5%25E3%2582%25A4%25E3%2583%25B3%25E3%2583%2581-%25E3%2582%25A2%25E3%2582%25A4%25E3%2582%25B1%25E3%2582%25A2%25E6%25A9%259F%25E8%2583%25BDB-I%2Fdp%2FB07BQWD83J%2Fref%3Dsr_1_1%3F__mk_ja_JP%3D%25E3%2582%25AB%25E3%2582%25BF%25E3%2582%25AB%25E3%2583%258A%26dchild%3D1%26keywords%3DBENQ%2B4k%2B31.5%26qid%3D1606903072%26s%3Dcomputers%26sr%3D1-1" title="Amazon | BenQ EW3270U 4K エンターテインメントモニター (31.5インチ/4K/HDR/VA/DCI-P3 95%/USB Type-C/HDMIx2/DP1.2/スピーカー/輝度自動調整機能(B.I.)搭載) | ベンキュージャパン | ディスプレイ 通販" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p> <h3 id="どうして4Kディスプレイを買おうと思ったか">どうして4Kディスプレイを買おうと思ったか</h3> <p>前の常駐先の先輩にオススメされたことがきっかけです。</p> <p>前の職場では、主にデータ作成をしていて、 <br/> AccessやExcelの資料など複数枚表示して作業を進めていました。 <br/></p> <p>ディスプレイ2枚で作業していると表示領域が狭く、 <br/> 色々と不便に感じていたので、購入しました。</p> <h3 id="実際に半年使ってみて感じたメリット">実際に半年使ってみて感じたメリット</h3> <h4 id="1画面の切り替えをする必要がほとんどない">1.画面の切り替えをする必要がほとんどない</h4> <p>今までは24インチのディスプレイを2台用意して作業を行っていましたが、 <br/> 仮想デスクトップを用意して切り替えながら作業をすることもよくありました。</p> <p>4Kディスプレイは、一つの画面上に複数サイトを開いて見ることが出来るので、 <br/> 切り替えることがほとんどなくなりました。</p> <h4 id="2表示領域が広い">2.表示領域が広い</h4> <p>特にコードやターミナルで実行した内容を確認したいときに読みやすいと感じています。</p> <p>このようなブログを書くときも画面を縦に分割して表示すれば、 <br/> スクロールすことなく文章の先頭から末尾まで確認できる点が良いです。</p> <h4 id="3ディスプレイ周りがスッキリする">3ディスプレイ周りがスッキリする</h4> <p>デスクの横幅が80cmほどと比較的幅が狭いですが、 <br/> 2台並べているときよりもスッキリして個人的に満足しています。</p> <p><figure class="figure-image figure-image-fotolife" title="実際の写真です"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsbx310/20201202/20201202190420.jpg" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>実際の写真です</figcaption></figure></p> <h4 id="オススメのサイズ">オススメのサイズ</h4> <p>オススメのサイズは、32~34くらいです。</p> <p>これより下回るサイズのディスプレイだと <br/> 画面を4分割した時に文字が細かくて読みづらく、 <br/> 拡大表示しなければならなくなると思いますので、 <br/> あまりオススメしません。</p> <p>32インチを下回る4Kディスプレイは、 <br/> ゲーム等の用途で購入を考えた方が良さそうです。</p> <h3 id="まとめ">まとめ</h3> <p>半年ほど4Kディスプレイを使用した感想ですが、 <br/> 特に使いづらさを感じることはありませんでした。</p> <p>31.5インチだと特にサイトの表示を拡大する必要もなく、 <br/> サイトを4分割にしても文字の小さな等は特に感じません。</p> <p>久しぶりに出社した際に24インチディスプレイ2台で作業を行うと、 <br/> やはり物足りなく感じました。笑</p> <p>作業効率が上がると思いますので、是非検討してみてはいかがでしょうか。</p> <p>このブログはBulletGroupが運営しております。 BulletGroupについてはこちら <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbltinc.co.jp%2F" title="バレットグループ株式会社/Bullet Group Inc." class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p> tsbx310 なぜ僕は業務に対してスピードにこだわるのか? hatenablog://entry/26006613668092549 2020-12-23T00:00:00+09:00 2022-10-11T12:55:14+09:00 Bullet Group Advent Calendar 2020 23 日目の記事です。 みなさん、こんにちは。 バレットグループの制作部隊のデザインチームでディレクターしている有村です。普段は子どもを寝かせた後は夜な夜なゲームの毎日ですww ところで多くの業務に追われ自分の時間を取るのにもままならない状況ってけっこうないですか?特に20代の時はほぼほぼ仕事に時間を取られてイライラしてました…。 広告業界でデザインをやっていたので、徹夜続きでその頃は「ブラック企業」なんて言葉もなく、徹夜や残業は当たり前の時代でした…友達の呑みの誘いを断るのもしばしば。幹事を買って出てでも集まることが好きな自… <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/y/yellowegg6/20201221/20201221154250.jpg" width="1200" height="675" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 23 日目の記事です。</p> <p>みなさん、こんにちは。 バレットグループの制作部隊のデザインチームでディレクターしている有村です。普段は子どもを寝かせた後は夜な夜なゲームの毎日ですww <br><br><br> ところで多くの業務に追われ自分の時間を取るのにもままならない状況ってけっこうないですか?特に20代の時はほぼほぼ仕事に時間を取られてイライラしてました…。 広告業界でデザインをやっていたので、徹夜続きでその頃は「ブラック企業」なんて言葉もなく、徹夜や残業は当たり前の時代でした…友達の呑みの誘いを断るのもしばしば。幹事を買って出てでも集まることが好きな自分にとっては辛かったし、イライラする原因のひとつでした。ただ、仕事仲間と和気藹々とできる環境だったのが唯一の救いで激しい業務にも耐えれてました。 <br><br><br> そんな中、何とかこの状況を少しでも改善しようと試みたのが「スピード」を格段に上げて行くというもので、単純に『スピード上げたら作業時間減って早く帰れるんやん!!』って安直な考えから始まりました。 あと、衝撃を受けた上司の言葉もあり加速的にスピードを上げました。その言葉がこれです。<b>「遅い仕事なら誰でもできる!!」 </b></p> <p><span style="font-size: 150%">1.</span><br> <span style="color: #dd830c"><b>まず取りかかったのは、アプリケーションを知る!!でした。</b></span><br>進化しているアプリケーションを熟知してフルに機能を使いこなすことで、作業を単純化、機械的にしたことでスピードを上げることができました。 例えば、使う素材は1箇所のデータにまとめるとか、タッチタイピングができない自分は「い」で変換すると「いつもありがとうございます。」と出るように辞書機能をカスタマイズしたりしてました。 部品が少ないほど機械は壊れにくいと言われるように工数が少ないとミスも減ると自負しております!!なので作業を減らし機械的にできる作業は機械(システム)で行ってました。</p> <p><span style="font-size: 150%">2.</span><br> <span style="color: #dd830c"><b>次にやったのは整理整頓です!!</b></span><br>身の回りもそうだし、PCのファルダーの整理、デスクトップの整理、整理できるところはなるべくやりました。そうすることで「モノを探す時間」を減らす事ができました!!これは先輩から言われた「人生で一番無駄な時間がモノを探す時間なんよ!」がヒントになってます。</p> <p><span style="font-size: 150%">3.</span><br> <span style="color: #dd830c"><b>最後は業務をなるべく早く減らすです!!</b></span><br> 1日に溜まっていく業務の中で「直ぐ終わるもの」「考えなくてもできる作業」は第一優先で終わらせてました。例えば返信に関するものや、データの訂正などです。これをやっとけば相手のターンの待ちになり、相手に取っては返信が早く返ってくるのでちょっとした信用にも繋がります!!自分の業務も減り、少し信用も獲れるという一石二鳥ですw。 <br><br><br> 業務のスピードを上げた事で時間ができ、激務も軽減、イライラも解消といういい流れで、思わぬ産物として信用も獲れるようになりました。デザインの仕上がりのスピードが早いと周囲にも認知され仕事を振られる事も増えましたが、これも信用と捉えています!!(ある意味これは先行利益か??) あと、作業が早いと提出も前倒しになりミスの発覚も早くなり、ミスを未然に防げるので余裕を持って納品できるようにもなりました。 <br><br><br> 以上、<b>『なぜ僕は業務に対してスピードにこだわるのか?』</b>でした。</p> <p><br> <span style="color: #d32f2f">みなさんは日々、毎日業務をこなしていく中で何に一番こだわっていますか??</span></p> yellowegg6 壁と私 hatenablog://entry/26006613668114913 2020-12-22T00:00:00+09:00 2022-10-11T12:56:39+09:00 Bullet Group Advent Calendar 2020 22日目の記事です。 はじめまして、デザイナーのkamiです。 バレットグループ初のデザイナーとして採用していただき、来年3年目に入ろうとしております。昔からデザイナーやってました風に見せかけて働いておりますが、実は経歴は普通より少し変わっています。 もともとのバレットグループとの出会いは『壁』。今回は、バレットでの『壁と私』の歴史をご紹介します。 2016年 壁画を描く 2018年 壁画を眺める 2020年 壁画を移す 小泉内閣が発足した2001年。 美大のグラフィックデザイン学科卒業後、一般的なデザイン業界の道には進まず、… <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 22日目の記事です。</p> <p>はじめまして、デザイナーのkamiです。<br /> バレットグループ初のデザイナーとして採用していただき、来年3年目に入ろうとしております。昔からデザイナーやってました風に見せかけて働いておりますが、実は経歴は普通より少し変わっています。 <br /> もともとのバレットグループとの出会いは『壁』。今回は、バレットでの『壁と私』の歴史をご紹介します。</p> <ul> <li>2016年 壁画を描く</li> <li>2018年 壁画を眺める</li> <li>2020年 壁画を移す</li> </ul> <p>小泉内閣が発足した2001年。<br /> 美大のグラフィックデザイン学科卒業後、一般的なデザイン業界の道には進まず、日本に上陸したばかりの某シアトル系コーヒーショップの魅力に取り憑かれ、カスタマーサービスやバリスタの育成、そして何よりコーヒーの世界に没頭して毎日を過ごしておりました。 同時に、その素晴らしいビバレッジやフードの世界観を伝える壁画や黒板を描いてほしいと頼まれることも多々あり、数えきれないほどの壁画や黒板をたくさんの店舗で描いてきました。</p> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221170953.jpg" width="943" height="960" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221170955.jpg" width="912" height="912" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221170951.jpg" width="774" height="960" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221170959.jpg" width="865" height="960" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221170948.jpg" width="1200" height="664" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221170945.jpg" width="1200" height="859" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <p>無我夢中で働いていて、はっと気づいたら30代後半。</p> <p><i>あっという間にこんな歳だし、親も歳だし(ら・ら・らより抜粋)</i></p> <p>ということで、何か違うことがしてみたいな…と思っていた矢先、たまたまお会いする機会のあった現・バレット取締役員から「うちのエントランスに壁画描いてみない?」とお声をかけていただきました。<br /> <span style="font-size: 80%">(この頃の超絶アナログ野郎だった自分は、まさか2年後にIT系の弊社で働くなんてことは1mmも思ってませんでした)</span></p> <p><i>なんとも人生ってわからない</i></p> <p>芸大出身の妹にも協力をお願いし、2016年夏に壁画制作がスタート。<br /> テーマは、『常識を打ち破るベンチャーマインド』<br /> ドラクロワ作の絵画『民衆を導く自由の女神』をオマージュし、新宿というカオスと情熱、様々な世界を想像力で広げていきました。 <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221172329.jpg" width="1080" height="1080" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span> 当初のラフスケッチですが、混沌とした世界観がしっかりと感じ取れます。笑</p> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221173128.jpg" width="640" height="640" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221173101.jpg" width="960" height="1199" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221173331.jpg" width="900" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221173614.jpg" width="884" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <p>基本なるべく社員さんたちがいない時間帯にペイントの作業していたのですが、たまたま遅くまで残っていた社員さんが差し入れを買ってきてくれたり、「毎朝、進捗を楽しみにしてます」と話しかけてくれたり、IT業界の人たちのことを先入観で傲慢そうなイメージを持っていたので、この会社は素敵な人が多いなぁと親近感を持ったことを覚えています。<br /> 3ヶ月かけて壁画を無事納品し、また機会があれば依頼してくださいとご挨拶してお別れしました。</p> <p>そして、2年後の2018年。<br /> 飲食業界から心機一転し、バーで働きながらデザインの再勉強中だった私。<br /> 冒頭にも出演していただきました現・バレット取締役員に、「今デザイナー目指してるの?うちでやってみない?」と突然のお声かけいただき、壁画を描いたバレットに社員としてまさかの入社。 自分の描いたカオスな寿司のペイントを社員として眺めるのは、なんとなく当初は恥ずかしかったです。<br /> <span style="font-size: 80%">今回の本筋から逸れるので多くは語りませんが、筆を片手に戦ってきたアナログ人間にとってHTMLやCSSは完全に地獄にしか感じられず、苦痛の日々が半年くらいありました。 </span></p> <p>そして、WEB業界に少しづつ慣れてきた2020年夏。<br /> 本社の移転が決定。もちろん壁ともお別れするつもりでした。が、<br /> 3回目のご登場!!現・バレット取締役員から「壁画を移動して、かっこいい額装してみない?」という提案が!!!<br /> もちろん、答えは<span style="font-size: 150%">『YES,I CAN!』</span><br /> すぐさま壁ぶち壊しプロジェクトを立ち上げ、壁画を壊さずに切り出す方法を美術業者さんと何度も打ち合わせをし、ついに8月1日に工事開始。<br /> 毎日パソコンと向き合っているので久しぶりのアナログ作業。忘れかけていた感覚に右脳が震えましたのを覚えてます。<span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221175334.jpg" width="1200" height="848" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span> 壁の裏から電気の配線が出てきて一時騒然となったり、思った以上に大変な作業になりましたが8時間かけて無事に壁画の切り出し成功。</p> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221180813.jpg" width="900" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221175416.jpg" width="900" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221175513.jpg" width="900" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221180415.jpg" width="900" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <p>マットブラックのイカした額装を施し、重さ100kgにもなる壁画が8月15日新オフィスの会議室に見事にカムバックしました。</p> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221182241.jpg" width="834" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuha0319/20201221/20201221181943.jpg" width="895" height="1200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <p>これで壁の物語はいったん完結です。</p> <p>今のわたしは、新たなWEBデザインという新しい壁に向かって切磋琢磨しております。<br /> 飲食業をしていた頃、「カスタマーエクスペリエンスとは?」という課題に何十年も真剣に向き合ってきましたが、これからはデザインでのユーザーエクスペリエンスを追求し今日もパソコンに向かいます。 -fin-</p> kazuha0319 Github Actionsを触ってみた hatenablog://entry/26006613663461463 2020-12-21T00:00:00+09:00 2022-10-11T12:57:06+09:00 Bullet Group Advent Calendar 2020 21日目の記事です。 どーも皆さまお久しぶりです!Technology Department(開発部)でインフラ周りを担当している山口です! 今年もあと10日で終わりますね。。。皆さんは今年どんな年だったでしょうか?今年はコロナでいろいろ大変だった中、個人的には子供が誕生して喜ばしい一年ともなりました! 来年は東京オリンピックも開催予定(あるのかな?)ですし、コロナの状況も気になりますが、今年よりもさらに良い一年になることを期待して過ごしております! さて今回はCI/CDサービスの一つでありますGithub Actionsを触… <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 21日目の記事です。</p> <p>どーも皆さまお久しぶりです!Technology Department(開発部)でインフラ周りを担当している山口です!</p> <p>今年もあと10日で終わりますね。。。皆さんは今年どんな年だったでしょうか?今年はコロナでいろいろ大変だった中、個人的には子供が誕生して喜ばしい一年ともなりました! 来年は東京オリンピックも開催予定(あるのかな?)ですし、コロナの状況も気になりますが、今年よりもさらに良い一年になることを期待して過ごしております!</p> <p>さて今回はCI/CDサービスの一つであります<a href="https://github.co.jp/features/actions">Github Actions</a>を触る機会がありましたのでこちらについてご紹介していきます!</p> <p><figure class="figure-image figure-image-fotolife" title="GithubActions"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201215/20201215151509.png" width="200" height="200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Github Actions</figcaption></figure></p> <h1 id="CICDとは">CI/CDとは</h1> <p>とその前に簡単にCI/CDについて少しだけ触れたいと思います。<br /> リリースを短期間で行うために開発スピードもそうですが、テストやデプロイなどの運用の部分の効率化を図らなければ品質を担保したまま世の中に素早くサービスを提供することが難しいです。 そこを解決するCI/CDという技術的なプラクティスがあります。</p> <p>簡単に説明しますと、CI(継続的インテグレーション)とはリポジトリに対して変更がかかるタイミングで自動的にテストやビルドを実行されるような仕組みのことで、CD(継続的デリバリー)は自動でテストやビルドが完了後、アプリケーションがいつでもリリース可能な状態にする、つまり自動でデプロイ可能にする仕組みのことです。</p> <p>これらのCI/CDを行うサービスはいくつも存在しており代表的なものでいうとJenkins、CircleCIやTravisCIなどが挙げられますが、そのサービスの中の一つでありますGithub Actionsをご紹介します。</p> <h1 id="Github-Actionsとは">Github Actionsとは</h1> <p>続いてGithub Actionsについてですが、その名の通りGithubが提供しておりGithub自体に組み込まれているCI/CDサービスです。<br /> ベータ版が2018年に限定公開され、GitHub社がMicrosoftに買収後の2019年にGAとなりました。現在では機能も充実してきたということで注目が高まってきました。</p> <p><figure class="figure-image figure-image-fotolife" title="Github"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201214/20201214152443.png" width="256" height="256" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Github</figcaption></figure></p> <h2 id="特徴">特徴</h2> <p>特徴としてまず<b>Githubとの親和性が高い</b>点です(そりゃそうだろと思いますがw)。他のCI/CDサービスではpushイベントによるCI/CDがメインで、他のイベントはサポートがほとんどされておらずイベント発生時に自動で実行するように自前でその機構を構築する必要性がありました。 しかし、Github ActionsはGithubに関わる様々なイベントに対応することが可能であり容易にCI/CD環境を構築することが可能です。あと、Githubで完結しますので管理という観点でも非常に良いですね。</p> <p>また、<b>料金的にも安価</b>という点です。パブリックリポジトリは無制限で、プライベートリポジトリでもFreeプランであれば2000分/月とのことで他サービスと比較しても利用障壁は低く検証もしやすいです。</p> <p>さらには<b>自由度が高い</b>点です。GitHubホストランナーとして利用されるVMはMicrosoftAzureのStandard_DS2_v2サイズのものを使用しておりスペックは以下の通りです。</p> <ul> <li>vCPU:2</li> <li>メモリ:7GiB</li> <li>SSD:14GiB</li> </ul> <p>上記以外でもセルフホストランナーという機能があり、ユーザー側で独自に実行環境を用意してカスタマイズ性やセキュリティを強固にした状態でCI/CDを実行することも可能なのでユーザーにとっては嬉しい機能ですね。</p> <h1 id="触ってみた">触ってみた</h1> <p>それではいよいよ触ってみます。まずはどこで設定や実行結果が確認できるかというとGithubのリポジトリのActionsタブからが確認することができます。 <figure class="figure-image figure-image-fotolife" title="Actionsタブ"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201216/20201216101122.png" width="1200" height="370" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Actionsタブ</figcaption></figure></p> <p>Github Actionsはワークフローという単位で構成されYAMLファイルで作成します。このファイルをリポジトリの<code>.github/workflows</code>ディレクトリに保存する必要があります。</p> <p>基本的には目的別でワークフローのテンプレートや、アクション等を活用しながらワークフローを作成していきます。<br /> アクションとは様々な一連の処理がパッケージされたもので、GitHub Marketplaceから検索して利用も可能ですし自作することも可能です。</p> <p>今回は下記のデフォルトで提供されるワークフローのテンプレートを元に説明していきます。<br /> また、今回登場する用語やテンプレート内で使用している構文について、簡単に表にまとめましたのでワークフローファイルの構成を確認する際にご参考いただければと思います。</p> <pre class="code" data-lang="" data-unlink># This is a basic workflow to help you get started with Actions name: CI # Controls when the action will run. on: # Triggers the workflow on push or pull request events but only for the master branch push: branches: [ master ] pull_request: branches: [ master ] # Allows you to run this workflow manually from the Actions tab workflow_dispatch: # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called &#34;build&#34; build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 # Runs a single command using the runners shell - name: Run a one-line script run: echo Hello, world! # Runs a set of commands using the runners shell - name: Run a multi-line script run: | echo Add other actions to build, echo test, and deploy your project.</pre> <ul> <li><p>簡単な用語集</p> <table> <thead> <tr> <th> 用語 </th> <th> 内容 </th> </tr> </thead> <tbody> <tr> <td> ワークフロー </td> <td> 何らかのプロセスを実行する最小単位 </td> </tr> <tr> <td> ジョブ </td> <td> ワークフロー内で実行する処理のまとまり </td> </tr> <tr> <td> ステップ </td> <td> ジョブ内で実行する処理 </td> </tr> <tr> <td> アクション </td> <td> ステップ内で実行する処理がパッケージされたもの </td> </tr> </tbody> </table> </li> <li><p>今回使用するワークフロー構文集</p> <table> <thead> <tr> <th> 構文 </th> <th> 内容 </th> </tr> </thead> <tbody> <tr> <td> name: </td> <td> 各工程の名前設定 </td> </tr> <tr> <td> on: </td> <td> トリガーとなるイベント設定 </td> </tr> <tr> <td> push: </td> <td> pushイベント </td> </tr> <tr> <td> pull_request: </td> <td> プルリクエストイベント </td> </tr> <tr> <td> branches: </td> <td> 対象のブランチ指定 </td> </tr> <tr> <td> workflow_dispatch: </td> <td> 手動実行設定 </td> </tr> <tr> <td> jobs: </td> <td> ジョブの設定 </td> </tr> <tr> <td> build: </td> <td> ジョブ名(任意のもので良い) </td> </tr> <tr> <td> runs-on: </td> <td> 実行環境の指定 </td> </tr> <tr> <td> step: </td> <td> ステップの設定 </td> </tr> <tr> <td> uses: </td> <td> アクションの呼び出し </td> </tr> <tr> <td> run: </td> <td> コマンド実行 </td> </tr> </tbody> </table> </li> </ul> <p><br> <code>on:</code>はワークフローを実行するトリガーとなるイベントを設定します。<br /> 今回はmasterブランチへpush、pull_requestを行うとワークフローが実行されます。また、各種イベントだけでなく<code>workflow_dispatch:</code>を使用すれば手動で実行も可能です。</p> <p><figure class="figure-image figure-image-fotolife" title="手動実行"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201216/20201216171103.png" width="1200" height="307" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>手動実行</figcaption></figure></p> <p>続いて、1つのワークフローは1つ以上のジョブで構成されます。<code>jobs:</code>で処理させたいジョブを構成します。そのジョブは<code>runs-on:</code>で指定した環境で実行されます。<br /> また、<code>self-hosted</code>を指定してセルフホストランナーを利用して独自に用意した環境にて実行することも可能です。<br /> さらに、<code>runs-on:</code>でなく<code>container:</code>を指定することによってコンテナ上でも実行することも可能です。</p> <p>さらに、ジョブの中に<code>steps:</code>と呼ばれる一連のタスクがあります。ステップでは<code>run:</code>でコマンドを実行したり、<code>uses:</code>でアクションを呼び出したりします。</p> <p>今回は<code>ubuntu-latest</code>を指定しているためUbuntuの仮想環境内で実行されることとなり、ジョブの動きとしては<code>actions/checkout@v2</code>のアクションを使用してVM上にリポジトリをチェックアウトして、<code>echo</code>コマンドで文字列を出力するというシンプルなジョブとなっております。</p> <p><br> <code>on:</code>で設定していたイベントによって自動的にワークフローが実行されます。成功するとコミットメッセージの隣に緑のチェックが表示されます。 <figure class="figure-image figure-image-fotolife" title="ワークフロー実行中"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201216/20201216170954.png" width="1200" height="243" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>ワークフロー実行中</figcaption></figure></p> <p><figure class="figure-image figure-image-fotolife" title="ワークフロー成功"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201216/20201216171031.png" width="1200" height="241" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>ワークフロー成功</figcaption></figure></p> <p>各ステップの実行時間やログなどの詳細な結果もActionsタブから確認することができます。もちろんSlackへ実行結果を通知する機構を組み込めばGithubを覗かなくても確認することも可能です。</p> <p>今回であると<code>echo</code>コマンドによって<code>Hello, world!</code>などのメッセージが正常に出力されていることが確認できます。 <figure class="figure-image figure-image-fotolife" title="実行ログ"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/g/gucchon90/20201216/20201216143435.png" width="1200" height="583" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>実行ログ</figcaption></figure></p> <h1 id="まとめ">まとめ</h1> <p>いかがだったでしょうか?今回は簡単な概要の説明でしたが、弊社ではPRが出されるとリンターやテストを自動的に実行するようなCI環境構築・検証を行なっており今後もCI/CDパイプラインを構築して自動化を目指していきたいと思います!</p> <p>皆様もGithubをお使いであれば十分検証してみる価値はあると思いますので試してみてがいかがでしょうか?</p> <h1 id="参考文献">参考文献</h1> <ul> <li>GitHub Actions 実践入門 (技術の泉シリーズ(NextPublishing))</li> </ul> gucchon90 タッチタイピング柱になろう hatenablog://entry/26006613666533640 2020-12-20T00:00:00+09:00 2022-10-11T13:00:20+09:00 この記事はBullet Group Advent Calendar 2020 20日目の記事です。 みなさん初めまして! 2020年10月よりTDでRubyエンジニアとして働き始めたhiroといいます。 いきなりですが、この記事をご覧になっている方々は、コロナ禍でどの様に働いていますか?? 弊社ではリモートワークが推奨されており、自分は入社後からずっとリモートワークで働いています。 同じようにリモートワークに移行された方も多いのではないでしょうか?? また、リモートワークに移行したことによりテキストベースでのコミュニケーションをする機会がとても増えました。 そこで役に立つのが『タッチタイピング… <p>この記事は<a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 20日目の記事です。</p> <p>みなさん初めまして! 2020年10月よりTDでRubyエンジニアとして働き始めたhiroといいます。<br /> いきなりですが、この記事をご覧になっている方々は、コロナ禍でどの様に働いていますか??</p> <p>弊社ではリモートワークが推奨されており、自分は入社後からずっとリモートワークで働いています。<br /> 同じようにリモートワークに移行された方も多いのではないでしょうか??</p> <p>また、リモートワークに移行したことによりテキストベースでのコミュニケーションをする機会がとても増えました。</p> <p>そこで役に立つのが『タッチタイピング』です!</p> <p>タッチタイピングができることで爆速でテキストベースでのコミュニケーションを行うことができるのです!<br /> また、業務の面でもドキュメント作成やプログラミングなど『PCを使用して文字を打つ』業務の全てがスピードアップします。</p> <p>仕事が早い = カッコいい = モテる!!<br /> つまりタッチタイピングができる = モテモテ!! 凄い!!</p> <p>そしてタッチタイピングは練習することで絶対に誰でも習得することができます。</p> <p>自分も元々人差し指でキーボードぽちぽちマンだったのですが、1ヶ月練習することでタイピングタッチを習得しました。(まだモテモテではありませんが...)</p> <p>皆さんの社内にもキーボードを一切見ることなく文字を入力し続ける『タッチタイピング柱』達がいると思います。</p> <p>この機会に皆さんもタッチタイピング柱を目指しませんか??</p> <h1 id="タッチタイピング習得まで">タッチタイピング習得まで</h1> <h2 id="まずはひたすらe-typingでホームポジションの練習">まずはひたすらe-typingでホームポジションの練習</h2> <p>まずはタッチタイピングの基本であるホームポジションを学びましょう。</p> <p>キーボードの『F』と『J』のキーにちょっとした突起が付いてるのが分かりますか??<br /> そこに左手の人差し指と右手の人差し指を置いてみましょう。</p> <p>そして他の指はそれぞれ順番に横に置きます。親指はスペースの近くにいればOKです。</p> <p>そう、その構えが『タッチタイピングの型、ホームポジション』です!</p> <p>世の中のタッチタイピング柱達はみんなその構えを使えます。<br /> このホームポジションこそタッチタイピングの基本です。</p> <p>そしてこのホームポジションから、他のキーがどの位置にあるのかを覚えましょう。<br /> 例えば「『G』はホームポジションから左手の人差し指を一つ右に動かした位置にあるんだな」みたいな感じです。<br /> そしてその練習をするのが『e-typing』です!</p> <p>こんな感じで画面上に使う指とキーの場所が表示されるので、それを元に適切な指の動かし方とホームポジションを学びましょう!</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hiro_blt/20201217/20201217201910.png" width="646" height="479" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>ここで大事なのは『適切な指でキーを叩く』ことです。</p> <p>今までで染み付いた我流のタイピングを捨てて、矯正することでこの後の伸び方が変わってきます。</p> <p>e-typingではキーの配置を完全に覚えるまで繰り返し練習しましょう。</p> <h2 id="寿司打でひたすら練習">寿司打でひたすら練習</h2> <p>キーの配置を覚えた後は『寿司打』というサイトでひたすら練習しましょう!</p> <p><iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Ftypingx0.net%2Fsushida%2F" title="寿司打" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="http://typingx0.net/sushida/">typingx0.net</a></cite></p> <p>こんな感じで寿司が流れてくるので、流れていってしまう前に文字をタイピングします。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hiro_blt/20201218/20201218105620.png" width="727" height="557" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>寿司打は『3000円コース』『5000円コース』『10000円コース』と3種類のコースがあります。<br /> 初めは3000円コースで練習しましょう。</p> <p>目標は10000円コースをクリアすることです!<br /> 目安としてそれくらいの実力があればタッチタイピングができるということです。</p> <p>このとき大事なのが『絶対にキーボードを見ない』ことです!</p> <p>初めのうちはキーボードを見ながら入力したほうが絶対に早いですが、それだとタッチタイピングは絶対に身につきません!<br /> キーボードを見れないもどかしさを超えた先にタッチタイピング柱への道があるのです...</p> <p>初めは全然できないと思いますが、それでも練習し続けましょう!</p> <p>そして『10000円コース』をクリアした時に、きっとあなたはタッチタイピング柱になっているはずです...</p> <h2 id="タッチタイピング柱になった後">タッチタイピング柱になった後</h2> <p>もしかして10000円コースをクリアしたことで終わりと思ってます??</p> <p>タッチタイピング柱になった後もまだまだ練習は続きます。</p> <p>某柱達が『全集中常中』を身に付けたように、皆さんも常に練習しましょう!</p> <p>タイピング界にはもっと上がたくさんいます。<br /> ちなみに自分はこれくらいの実力です。</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hiro_blt/20201217/20201217202119.png" width="622" height="515" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>まだ全国には1000人もの猛者がいるのです。(ちなみに現在1位の方は21760円です...)</p> <p><strong>『一日一万回、感謝のタッチタイピング』</strong></p> <p>やがてタイピングの速度は音を置き去りにすることでしょう...</p> <h2 id="番外編自作キーボード">番外編 自作キーボード</h2> <p>もしタッチタイピングにハマった人はキーボードにこだわるのも面白いかもしれません。<br /> 自分はタイピングにハマりすぎてキーボードを自作しました</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/h/hiro_blt/20201218/20201218112745.jpg" width="1200" height="538" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>Mint60という比較的簡単に組める自作キーボード初心者の方にオススメなキーボードです。</p> <p>分離型のキーボードは手が窮屈にならないので、肩こり対策などにも効果があるみたいです。</p> <p>はんだごてや工具など初期費用が少しかかるのですが、興味がある方は是非いかがでしょうか?<br /> やっぱり自分で作ったキーボードだと愛着も湧くのでタイピングするときの楽しみもマシマシですよ!</p> <h1 id="最後に">最後に</h1> <p>タッチタイピングを習得することでPCを使う仕事が爆速になったことでしょう。</p> <p>これからは爆速で社内ドキュメントを作って「え、また俺何かしちゃいました??」みたいにドヤ顔もできます。</p> <p>Twitterで呟く時もPCから呟けば爆速でtweetできます。</p> <p>推し声優のラジオにメールを送るときでも爆速でメールが打てます。</p> <p>上司にSlackで謝る時も爆速で文字を打つことで誠意を見せることができるでしょう。</p> <p>自分的にはPCを使って仕事をする内は一生役に立つスキル&習得が比較的簡単だと思うのでぜひ皆さんも練習してみてください!</p> hiro_blt terraformでお手軽に静的サイトを公開 hatenablog://entry/26006613666160909 2020-12-19T00:00:00+09:00 2022-10-11T13:02:15+09:00 Bullet Group Advent Calendar 2020 19日目の記事です。 こんにちは!SREチームたかはしです! 栄えあるアドベントカレンダーの19日目、どんな記事を書かせて頂こうか悩みましたが「terraformで s3 + cloudfront を構築し、静的サイトを公開する方法」をご紹介したいと思います! こちら以前自分が業務上で行ったことなのですが、とてもとても楽に環境構築 & サイト公開までできて感動しました。 簡単なポートフォリオサイトの公開などで使用することもあるかと思いますので、皆さんにもお試しいただければと思います。 前提 pcにterraformがインストー… <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 19日目の記事です。</p> <p>こんにちは!SREチームたかはしです!</p> <p>栄えあるアドベントカレンダーの19日目、どんな記事を書かせて頂こうか悩みましたが「terraformで s3 + cloudfront を構築し、静的サイトを公開する方法」をご紹介したいと思います!<br> こちら以前自分が業務上で行ったことなのですが、とてもとても楽に環境構築 &amp; サイト公開までできて感動しました。<br> 簡単なポートフォリオサイトの公開などで使用することもあるかと思いますので、皆さんにもお試しいただければと思います。</p> <h2 id="前提">前提</h2> <ul> <li>pcにterraformがインストール済み(もしまだインストールされていない場合は<a href="https://blog.bltinc.co.jp/entry/2020/07/10/090000">こちらの記事</a>を参考にインストールをお願いします)</li> <li>AWSアカウントは作成済み</li> </ul> <p>以上を前提に手順を説明していきます!</p> <h2 id="手順">手順</h2> <h3 id="AWSコンソールにて">AWSコンソールにて</h3> <p><b>IAMユーザーの作成</b></p> <ul> <li>IAMコンソールに遷移</li> <li>サイドバー"ユーザー" より "ユーザーを追加" をクリック<br /> <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20201217/20201217192155.png" width="873" height="376" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></li> <li>任意のユーザー名を設定</li> <li><code>アクセスの種類 : プログラムによるアクセス</code> を選択</li> <li><code>次のステップ</code> をクリック</li> <li><code>アクセス許可の設定</code> より <code>既存のポリシーを直接アタッチ</code> 選択</li> <li><code>AdministratorAccess</code>をチェック</li> <li><code>次のステップ</code> をクリック</li> <li><code>タグの追加</code>任意のタグを設定</li> <li>確認後、<code>ユーザーの作成</code>をクリック</li> </ul> <p>これで、アクセスキー/シークレットキーの取得ができるので保存してください<br> AWSコンソールでの作業はいったん以上です!</p> <h3 id="ローカルにて">ローカルにて</h3> <p><b>terraformファイルの作成</b></p> <p>まずは<a href="https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-files.html">こちらのAWSドキュメント</a>を参考に、<code>~/.aws/credentials</code>に先ほどのキー情報を登録してください</p> <p>その後、任意のディレクトリを作成(自分は<code>terraform-aws</code>としました)し、<br> 作成したディレクトリ内に<code>variables.tf</code>ファイルを作成してください。<br> このファイルでは、Terraformで使うプロバイダーの設定をします。<br> プロバイダーとはインフラを管理する対象プラットフォームのことです。<br> 今回はAWSを利用しますので、AWS用のプロバイダー設定を記述します。<br></p> <p>ファイルの中身は下記のように記述してください。</p> <pre class="code variables.tf" data-lang="variables.tf" data-unlink>provider &#34;aws&#34; { version = &#34;~&gt; 2.0&#34; region = &#34;ap-northeast-1&#34; }</pre> <p>同じように<code>terraform-aws</code>配下に<code>resouce.tf</code>ファイルを作成してください。<br> ここにはAWSクラウド上に作成したいリソースを記述します。<br></p> <p>基本的にこちらのコピペで大丈夫ですが、 <code>default_root_object</code> ではCloudFrontのデフォルトルートオブジェクトを指定できます。 自分は<code>index.html</code>としていますが、任意のものをしてしてください。</p> <pre class="code" data-lang="" data-unlink>#s3 resource &#34;aws_s3_bucket&#34; &#34;image-bucket&#34; { bucket = &#34;20201219&#34; acl = &#34;private&#34; region = &#34;ap-northeast-1&#34; } #cloudfront resource &#34;aws_cloudfront_origin_access_identity&#34; &#34;origin_access_identity&#34; { comment = &#34;origin access identity for s3&#34; } resource &#34;aws_cloudfront_distribution&#34; &#34;s3_distribution&#34; { origin { domain_name = &#34;${aws_s3_bucket.image-bucket.bucket_regional_domain_name}&#34; origin_id = &#34;${aws_s3_bucket.image-bucket.id}&#34; s3_origin_config { origin_access_identity = &#34;${aws_cloudfront_origin_access_identity.origin_access_identity.cloudfront_access_identity_path}&#34; } } enabled = true is_ipv6_enabled = false default_root_object = &#34;index.html&#34; logging_config { include_cookies = false bucket = &#34;${aws_s3_bucket.image-bucket.bucket_domain_name}&#34; prefix = &#34;prefix&#34; } default_cache_behavior { allowed_methods = [&#34;DELETE&#34;, &#34;GET&#34;, &#34;HEAD&#34;, &#34;OPTIONS&#34;, &#34;PATCH&#34;, &#34;POST&#34;, &#34;PUT&#34;] cached_methods = [&#34;GET&#34;, &#34;HEAD&#34;] target_origin_id = &#34;${aws_s3_bucket.image-bucket.id}&#34; forwarded_values { query_string = false cookies { forward = &#34;none&#34; } } viewer_protocol_policy = &#34;allow-all&#34; min_ttl = 0 default_ttl = 3600 max_ttl = 86400 } price_class = &#34;PriceClass_200&#34; restrictions { geo_restriction { restriction_type = &#34;none&#34; } } tags = { Environment = &#34;dev&#34; } viewer_certificate { cloudfront_default_certificate = true } } #iam data &#34;aws_iam_policy_document&#34; &#34;cf_to_s3_policy&#34; { statement { actions = [&#34;s3:GetObject&#34;, &#34;s3:ListBucket&#34;] resources = [ &#34;${aws_s3_bucket.image-bucket.arn}&#34;, &#34;${aws_s3_bucket.image-bucket.arn}/*&#34;, ] principals { type = &#34;AWS&#34; identifiers = [&#34;${aws_cloudfront_origin_access_identity.origin_access_identity.iam_arn}&#34;] } } } resource &#34;aws_s3_bucket_policy&#34; &#34;cf-to-s3&#34; { bucket = &#34;${aws_s3_bucket.image-bucket.id}&#34; policy = &#34;${data.aws_iam_policy_document.cf_to_s3_policy.json}&#34; }</pre> <p><b>terraform実行</b></p> <p>これら二つのファイルが用意できましたら、あとは簡単です。<br> CUIで<code>terraform-aws/</code>に移動し、まず<code>terraform init</code>コマンドを実行してください。</p> <pre class="code" data-lang="" data-unlink>cd 任意のパス/terraform-aws/ terraform init</pre> <p>こちらのコマンドで Terraform の実行に必要なバイナリがダウンロードされます。<code>Terraform has been successfully initialized!</code> と表示されたら成功です。<br></p> <p>次に<code>terraform plan</code>を実行してください。リソースが正常に作成できるか実際に作成する前に確認できます。</p> <pre class="code" data-lang="" data-unlink>terraform plan</pre> <p>最後に<code>terraform apply</code>を実行してください。こちらのコマンドで実際に、クラウド上にリソースが作成されます。<br> 実行途中<code>Do you want to perform these actions?</code>と、本当に実行するか確認されるので<code>yes</code>と入力してEnterを押してください。</p> <pre class="code" data-lang="" data-unlink>terraform apply</pre> <p><code>Apply complete!</code>と表示されたら成功です。<br> 早速AWSコンソールにリソースを確認しにいきましょう!</p> <h3 id="AWSコンソールにて-1">AWSコンソールにて</h3> <p><b>cloudfrontコンソール</b></p> <p>ディストリビューションが作成されていますね <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20201217/20201217191907.png" width="702" height="233" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p><code>Origin Domain Name</code> を確認するとオブジェクトの取得先がs3になっていることがわかります。<br> それではs3も見に行ってましょう!</p> <p> <b>s3コンソール</b></p> <p><code>resouce.tf</code>で指定したバケット名でバケットが作成されていることがわかります。<br> <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20201217/20201217191910.png" width="882" height="316" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>これで問題なく静的サイト公開に必要なリソースを作成できました!!<br> それでは、バケットに静的サイトのコンテンツをアップロードしましょう。<br> 該当のバケットをクリックし、コンテンツをアップロードします!</p> <p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20201218/20201218102546.png" width="1200" height="431" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <p>(今回アップロードしたファイルは<a href="https://free-hp.net/">こちらのサイト</a>で配布されているものです。)</p> <h3 id="ブラウザにて">ブラウザにて</h3> <p>Coludfrontドメインにアクセスすると、静的サイトが公開されていますことが確認できます! <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/T/Takahashi_Blt/20201216/20201216230426.png" width="1200" height="568" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p> <h2 id="最後に">最後に</h2> <p>いかがでしたでしょうか!<br> あっという間に静的サイトを公開できる環境を構築できたと思います。<br> 別のアカウントに同じ環境を作りたい、となった時もこのコードを保存しておけば瞬時に作成できますね!<br> infrastructure as code のメリットはとても大きいので、今後もどんどん取り入れていきたいです!</p> Takahashi_Blt コードレビューの方針を考えてみた hatenablog://entry/26006613666060558 2020-12-18T00:00:00+09:00 2022-10-12T14:03:31+09:00 Bullet Group Advent Calendar 2020 の 18 日目の記事は水野が担当いたします。 コードレビュー、してますか? 弊社の開発部 (Technology Department) の Ruby プロダクトチームでは喜ばしいことにコードレビューの文化を作り上げることができており、日々愛を込めてレビューし合っています。 時には文字だと感情が伝わりにくく、言葉が強く感じてしまうことがあったため、「アニメアイコンにすれば伝わり方変わるんじゃね?」などと冗談半分で変更してみた結果、二次元の女性キャラクターに指摘されているように感じ取れて気分が良かったと、好感触だったことがありま… <p><a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> の 18 日目の記事は水野が担当いたします。</p> <p>コードレビュー、してますか?<br /> 弊社の開発部 (Technology Department) の Ruby プロダクトチームでは喜ばしいことにコードレビューの文化を作り上げることができており、日々愛を込めてレビューし合っています。</p> <p>時には文字だと感情が伝わりにくく、言葉が強く感じてしまうことがあったため、「アニメアイコンにすれば伝わり方変わるんじゃね?」などと冗談半分で変更してみた結果、二次元の女性キャラクターに指摘されているように感じ取れて気分が良かったと、好感触だったことがありました。<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> <span style="font-size: 80%">※ 個人差があります。</span><br /> 悩まれている方がいらっしゃれば、ぜひお試しください。</p> <p>実際、捉え方は人それぞれですので、なるべく相手の気分を悪くしないような言葉遣いを特に文字でのやりとりは気を付けています。<br /> このような相手の気持ちを考えて伝えるためにはどうするのが良いとか、表現に関しての記事を書こうと初めは思っていたのですが、最近コードレビューによる進捗の遅れが著しく感じたので、定めた方針について書いていきます。</p> <p>当然なことを書いていくだけになるかと思いますが、以外に見落としがちだったりするので、ご参考になれば幸いです。</p> <h2 id="コードレビューの目的">コードレビューの目的</h2> <p>まず目的から考えてみました。</p> <p>クローズされた PR を見返してみると、「こうすればもっとスマートに書ける」や「こんな書き方どうかな?」などといった<strong>書き方</strong>のコードレビューが多く見られました。<br /> より良いコードにしたい、可読性を高くしたいと考える IT エンジニアが弊社には多いので、必然的にそうなってしまったのかと思います。</p> <p>可読性を高くすることはひとつの目的ではあると思いますが、第一のコードレビューの目的にするのは違うと考え、僕は以下のように定めました。</p> <h3 id="要望通りの仕様になっていること">要望通りの仕様になっていること</h3> <p>まずは<strong>要望通りの仕様</strong>になっていることが大前提です。当然ですね。<br /> 仕様と異なっていれば問題になります。</p> <h3 id="実装者以外にメンテナンスできるようにする">実装者以外にメンテナンスできるようにする</h3> <p><strong>書いたコードの内容をチームメンバーに理解してもらうこと</strong>は特に重要だと考えました。<br /> 他人<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup>が読んですぐに理解できないソースコードは敬遠され、今後メンテナンスされなくなってしまいます。</p> <p>そのためには、いずれ未来の自分がこのソースコードを改修しなければならないことを意識してコードレビューするべきです。<br /> つまり、コードレビューは改善点などの指摘だけではなく、<strong>ソースコードの意図に関する質問</strong>もしていくべきだと思います。</p> <h3 id="バグの指摘を目的にしない">バグの指摘を目的にしない</h3> <p>バグの指摘を目的にすると、他の目的の意識が薄くなってしまうと考えました。<br /> 指摘をしてはいけないというわけではなく、<strong>バグを発見するためのコードレビュー</strong>はやめるべきだと思います。<br /> バグを探す時間をテストの網羅性を確かめる時間に費やした方が結果的にバグは減っていくと思います。</p> <h2 id="コードレビューの方法">コードレビューの方法</h2> <p>意識しても実際にコードレビューすると難しい場合もあると思うので、方法もざっくりと考えてみました。</p> <h3 id="テストコードを読む">テストコードを読む</h3> <p>テストコードを読むことで、対応した内容がわかるはずです。<br /> コードレビューの最後にもう一度テストコードを読むことで網羅性の確認も行いましょう。<br /> そもそもテストコードの追加・修正がなかった場合は指摘事項になります。</p> <h3 id="コードレビューに優先度をつける">コードレビューに優先度をつける</h3> <p>例えば下記のような問題は最優先にコードレビューするべきです。</p> <ul> <li>システムや損益に関わってくる問題</li> <li>後から修正するのが非常に困難な問題</li> </ul> <p>このような観点のコードレビューがまだできていない場合は、他の軽微な問題は検出するべきではありません。<br /> もちろん、検知した場合はコメントを残しましょう。</p> <p>しかし、このように様々な観点のコードレビューをしていくと、どのコードレビューを優先して対応すべきかわかりません。<br /> 先頭にラベルを付けてコメントすることで意図がわかるようにすると良いと思います。</p> <ul> <li>[MUST] <ul> <li>絶対に対応して欲しいコメント</li> </ul> </li> <li>[IMO] (In my opinion) <ul> <li>自分ならこう対応するなどといった意見や提案のコメント</li> </ul> </li> <li>[NITS] (nitpick) <ul> <li>細かい指摘などのコメント</li> </ul> </li> <li>[ASK] <ul> <li>質問や確認のコメント</li> </ul> </li> </ul> <p>[NITS] が書かれたコメントは低い優先度と捉え、重要な機能でなかったり、時間に余裕がない場合は対応せずにマージを許容します。<br /> ただし、<strong>後からでも修正が可能</strong>だと判断できたものに限りとします。<span style="font-size: 80%"><s>対応されずにずっと残るやつ</s></span></p> <h2 id="コードレビューの依頼">コードレビューの依頼</h2> <p>依頼するときも気をつけなければいけない点がいくつか出てきていたので、この機会に考えてみました。</p> <h3 id="レビュアーを指名する">レビュアーを指名する</h3> <p>僕の所属するチームでは、Slack でユーザーグループにメンションを送ってコードレビューの依頼をしていました。<br /> ですが、基本的に決まったメンバーのみがレビューしていることに気付きました。<br /> そもそも仕様がよくわかっていないので自分がレビューして問題ないのか、誰かが対応してくれるだろうなど、レビューし辛い環境となっていたようです。</p> <p>このままではよろしくないので、<strong>レビュアーを指名する</strong>方針を定めました。</p> <p>レビュアーを指名することにより、自分がやらなければいけない責任感が生まれるのか、コードレビューのまわりが良くなったのでオススメです。</p> <p>指名するメンバーを決めるのは適当ではなく、チームによって決め方を定めておくと良いと思います。 例えば、僕の所属するチームでは下記のようにレビュアーを多くしないように 2 人で定めています。</p> <ul> <li>設計メンバーから 1 人 <ul> <li>あるいは機能に詳しいメンバーから 1 人</li> </ul> </li> <li>実装メンバーから 1 人</li> </ul> <p>もちろん、指名されていないメンバーも余裕がある方はコードレビューして問題ありません。</p> <h3 id="変更ファイル数を少なくする">変更ファイル数を少なくする</h3> <p>変更ファイル数が多くなってくるとレビュアーの負担になるだけではなく、時間がかかると判断して後回しになってしまう傾向があるので、なるべく少なくするように努力するべきです。<br /> なるべく細かくチケットを分けたり、機能変更とリファクタリングは分けて PR を作成するなど、変更ファイル数を少なくしましょう。</p> <p>僕の感覚では、変更ファイル数が 10 以下だとすんなり始められ、15 を超えてくると見て見ぬ振りをしたくなってきますw</p> <h3 id="作業メモを書く">作業メモを書く</h3> <p>本当にメモ書き程度で良いので、それなりの規模の回収などの場合は、なにかに作業メモを残しましょう。<br /> どのような意図で変更したのかがレビュアーにわかりやすくなるだけではなく、日を跨いでしまう作業でもどこまで対応したか思い出せる手段にもなります。</p> <p>概要や背景なども書いておくと、自分がやるべきタスクが見えてくることもあるのでオススメです。<br /> 弊社では同様の作業があった場合などにもすぐ参考できるように <a href="https://esa.io/">esa</a> に書き溜めています(\( ⁰⊖⁰)/)</p> <h2 id="最後に">最後に</h2> <p>コードレビューは簡単なようで難しいですよね。<br /> 今回書いた内容が最善というわけでもありませんし、またコードレビューによる遅れなどが見えてきたら考える時間を作るつもりです。</p> <p>この機会に皆さまも再考してみてはいかがでしょうか?</p> <p>最後までご覧いただき、ありがとうございました!</p> <h2 id="参考記事">参考記事</h2> <ul> <li><a href="https://osak.hatenablog.jp/entry/code-review-objectives-and-howto">コードレビューの目的と考え方</a></li> <li><a href="https://qiita.com/godgarden/items/3ea57a7ee6dbff1df6e6">レビューコメントにラベルをつけるだけで開発効率があがって幸せになれそうな話</a></li> </ul> <div class="footnotes"> <hr/> <ol> <li id="fn:1"> <p>口調を変えたり、名前まで変更するのはさすがに怒られるのでやめました。<a href="#fnref:1" rev="footnote">&#8617;</a></p></li> <li id="fn:2"> <p>他人とは数ヶ月経った自分も指す。過去の自分は他人だ。<a href="#fnref:2" rev="footnote">&#8617;</a></p></li> </ol> </div> zuno_onuz 2020年 心に響いたポエム ベスト5 hatenablog://entry/26006613665584812 2020-12-17T00:00:00+09:00 2022-10-11T13:03:18+09:00 こちらは🎄Bullet Group Advent Calendar 2020 17日目の記事です こんにちわ SREを担当している しょーや(show--ya) です 本日は以前ご紹介させていただいた「社内ポエム」が好評でしたので 新しく続々と投稿されているポエムの中から 2020年 心に響いたポエム ベスト5 をご紹介させていただきます!! 前回の記事はこちらとなります! blog.bltinc.co.jp 「社内ポエムとは?」などは前回の記事に書かせていただいておりますので ぜひ合わせてお読みくださいませ それでは 、私が独断と偏見で選んだ「2020年 心に響いたポエム ベスト5」の発表で… <p>こちらは🎄<a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 17日目の記事です</p> <p>こんにちわ<br /> SREを担当している しょーや(show--ya) です</p> <p>本日は以前ご紹介させていただいた「社内ポエム」が好評でしたので<br /> 新しく続々と投稿されているポエムの中から <strong>2020年 心に響いたポエム ベスト5</strong> をご紹介させていただきます!!</p> <p>前回の記事はこちらとなります!<br /> <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.bltinc.co.jp%2Fentry%2F2020%2F03%2F02%2F090000" title="社内ポエム 個人的ベスト5のご紹介 - Colorful Bullet" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://blog.bltinc.co.jp/entry/2020/03/02/090000">blog.bltinc.co.jp</a></cite></p> <p>「社内ポエムとは?」などは前回の記事に書かせていただいておりますので<br /> ぜひ合わせてお読みくださいませ</p> <p>それでは 、私が独断と偏見で選んだ「2020年 心に響いたポエム ベスト5」の発表です 👏</p> <h2 id="第5位決定を下さないのは誤った決定を下すより悪">【第5位】決定を下さないのは、誤った決定を下すより悪</h2> <p>▼選出理由</p> <p>こちらのポエムは読んでそのままの意味、どストレートに私は解釈しました。 どうしても判断を誤った時のことを恐れすぎ、慎重になりすぎて中々決定を下せない状態に 心当たりがありグサっと刺さったため選出させていただきました!</p> <p>雑すぎて誤った判断を下すのもよくないですが、いつまでも決断を下さないことも悪であることを今後はもっと意識します!!</p> <h2 id="第4位非常時は互いに我慢の限界値が下がっていることを認識してコミュニケーションを">【第4位】非常時は互いに我慢の限界値が下がっていることを認識してコミュニケーションを</h2> <p>▼選出理由</p> <p>どうしても高稼働になり、いつもより余裕がなくることというのはあるのですが そんな時はお互いに余裕がなくなっていることを意識して、いつもより丁寧なコミュニケーションを取らないと「こっちはいつも通りのつもりなのに何かギクシャクする」という自体が発生してしまいますよ。という教えが込められていると読み取りました</p> <p>また、そんな状態に心当たりがなくもないため、大切な教訓の一つとして選出させていただきました!</p> <p>3位以上のポエムには前回から引き続き<br /> デザイナーさんにオリジナルイラスト を書いていただきました!!!!!</p> <p>ポエムと合わせてイラストもお楽しみください!!</p> <h2 id="第3位一次回答すると依頼者目線では受付完了になる">【第3位】一次回答すると、依頼者目線では受付完了になる</h2> <p><figure class="figure-image figure-image-fotolife" title="一次回答すると、依頼者目線では受付完了になる"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/show--ya/20201216/20201216153521.jpg" alt="&#x4E00;&#x6B21;&#x56DE;&#x7B54;&#x3059;&#x308B;&#x3068;&#x3001;&#x4F9D;&#x983C;&#x8005;&#x76EE;&#x7DDA;&#x3067;&#x306F;&#x53D7;&#x4ED8;&#x5B8C;&#x4E86;&#x306B;&#x306A;&#x308B;" width="1200" height="1138" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>一次回答すると、依頼者目線では受付完了になる</figcaption></figure> ▼選出理由</p> <p>質問や依頼がきた際に、完璧な回答を準備するためにレスポンスが遅れてしまうよりも 「その時点でわかる範囲の回答」と「想定する今後の展開」を一次回答として伝えることで 依頼者に対して「この依頼、受付けましたよ」を確実に伝えておくことが仕事をする上で大切。 ということをわかりやすく 表現してくれているポエムだと感じたため選出しました</p> <h2 id="第2位泥水はより上流で濾過するべし">【第2位】泥水はより上流で濾過するべし</h2> <p><figure class="figure-image figure-image-fotolife" title="泥水はより上流で濾過するべし"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/show--ya/20201216/20201216150550.jpg" alt="&#x6CE5;&#x6C34;&#x306F;&#x3088;&#x308A;&#x4E0A;&#x6D41;&#x3067;&#x6FFE;&#x904E;&#x3059;&#x308B;&#x3079;&#x3057;" width="1200" height="664" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>泥水はより上流で濾過するべし</figcaption></figure> ▼選出理由</p> <p>何かにつけて「これは後に回そう」「今はこれはやらなくていいや」と後回しにしてしまうと いざ取り掛かろうとしたとき、かなりの範囲が泥水かしてしまっていて作業が肥大化してしまう。そうなる前にできるだけ早く対処しましょう!!!!自分への戒めも込めての選出です!</p> <h2 id="第1位推測するな計測せよ">【第1位】推測するな、計測せよ</h2> <p><figure class="figure-image figure-image-fotolife" title="推測するな、計測せよ"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/show--ya/20201216/20201216150614.jpg" alt="&#x63A8;&#x6E2C;&#x3059;&#x308B;&#x306A;&#x3001;&#x8A08;&#x6E2C;&#x305B;&#x3088;" width="937" height="731" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>推測するな、計測せよ</figcaption></figure> ▼選出理由</p> <p>「推測してました!計測します!」となりがちな方には ぜひ毎朝唱えていただきたくなるほどシンプルですが、効果絶大な一文でしたので、今回の第一位として選出いたしました!</p> <p>何かを調査・検証する際は「推測だけでなく、計測した結果」を添えるように意識すると<br /> 仕事の質が格段に上がりますので、改めて強く意識してみるといいかもしれません。</p> <h2 id="番外編3ヶ月頑張って作った機能が使われずに削除される気持ちわかる">【番外編】3ヶ月頑張って作った機能が、使われずに削除される気持ちわかる?</h2> <p>▼選出理由</p> <p>ぴえんということだけはわかる。。。<br /> 供養のため選出しました👻</p> <h2 id="さいごに">さいごに</h2> <p>日々の業務の中で「これ大切だな」と感じた考え方など、気軽に色んな人から蓄積される社内ポエムは意外な発見があったりするので、もし良ければ皆さまも導入してみてください♪</p> <p>最後までご覧いただきありがとうございました!</p> show--ya 働く2児のママの1日 hatenablog://entry/26006613664227331 2020-12-15T09:30:00+09:00 2022-10-11T13:07:26+09:00 皆さまはじめまして! Bullet Group Advent Calendar 2020 15日目の記事を担当させて頂きますmaripigです! デザインチームでデザイナー(コーダーもちょこっと)をしています。 実はこのブログのデザインを担当した人なんですが、お恥ずかしながら今回初めて投稿させて頂きます!ドキドキ。 今回は、働きながら2児の母をしておりますmaripigがバレットに入社してから経験した 「通勤でのワーママ生活」と「リモートでのワーママ生活」の1日を比較。 どちらにも良さがあったりすると思うので、これからワーママ頑張ろう!と思っている方への何かのヒントになればいいなーなんて思って… <p>皆さまはじめまして!<br /> <a href="https://adventar.org/calendars/5143">Bullet Group Advent Calendar 2020</a> 15日目の記事を担当させて頂きますmaripigです!<br /> デザインチームでデザイナー(コーダーもちょこっと)をしています。<br /> 実はこのブログのデザインを担当した人なんですが、お恥ずかしながら今回初めて投稿させて頂きます!ドキドキ。</p> <p>今回は、働きながら2児の母をしておりますmaripigがバレットに入社してから経験した 「通勤でのワーママ生活」と「リモートでのワーママ生活」の1日を比較。<br /> どちらにも良さがあったりすると思うので、これからワーママ頑張ろう!と思っている方への何かのヒントになればいいなーなんて思っております。</p> <h4 id="始めにちょこっと自己紹介">始めにちょこっと自己紹介</h4> <p>バレットには入社して1年8ヶ月程。二人目妊娠中の、切迫早産で入院中に前職の会社の業績が悪化し倒産。。。 途方に暮れていたところを、旦那さんの転職先であるバレットに夫婦共々採用して頂きました>&lt;!(本当に感謝しかないです・・・!) 子供たちは現在3歳ともうすぐ5歳になる男の子。2人とも同じ保育園に通ってます。 通勤してた頃の子供たちは2歳と4歳。コロナの影響でリモート化が加速し、今年3月からはほぼ全リモートです。</p> <h3 id="ではさっそく朝のようすから">ではさっそく、朝のようすから…</h3> <p>【通勤】<br />     6:00 起床(私だけ) 化粧・着替えなど自分の身支度を一気に済ませる<br />  6:30〜7:00 寝室のカーテンを開けて(子供たちご機嫌で起きてこい〜と念じつつ)朝ご飯の準備<br />  7:00〜8:00 子供たちを起こして朝食を食べる<br />  8:00〜8:30 保育園の準備(着替えと連絡ノートの記入・検温など)して、私は家を出る。<br />  8:30〜9:00 電車で通勤(パパは子供たちを保育園へ)<br />  9:00〜   お仕事開始!</p> <p>【リモート】<br />  7:00〜7:15 起床(みんな一緒に。最近先に私が起きてると長男が泣いて怒るので…w)<br />  7:15〜7:30 長男と一緒にトイレ(これも先にいくと怒る…w)<br />  7:30〜8:10 朝食<br />        (子供たちはだらだら〜と食べてるのでこの間に化粧とか着替えを)<br />        (この間にパパは布団上げたりとか、保育園に持って行く服とか準備してくれてる)<br />  8:10〜8:40 子供たちの着替えと保育園の準備、、、慌ただしく出発!<br />  8:40〜9:00 登園(徒歩)6月に引っ越しして、10月に転園したので、ある程度は慣れたけどまだまだ朝は教室の前でとてもぐずる。。。<br />        (この間にパパは掃除機とか食器洗ったりとか家事をしてくれてます。本当に感謝。。。)<br />  9:30頃   お仕事開始!(時間のあるときは朝ヨガやってから)</p> <h3 id="お昼">お昼!</h3> <p>【通勤】<br />  TDの中でタイミングが合う人と一緒に外ご飯が多い。同じ職場なので旦那さんと行くことも多かったです!<br />  会社の周りにいろんなおいしいお店があるので飽きないですね。<br />  たまに頑張ってお弁当持って行くことも。</p> <p>【リモート】<br />  旦那さんとなるべく時間併せてご飯とってます。<br />  最近は <a href="https://nosh.jp/?utm_source=google&amp;utm_medium=cpc&amp;utm_campaign=nosh&amp;utm_content=nosh&amp;utm_term=%E3%83%8A%E3%83%83%E3%82%B7%E3%83%A5&amp;gclid=Cj0KCQiA8dH-BRD_ARIsAC24umZT2keC5NnVqG4YNby5A5qkad62pYjiJenJ-hLZsxHwfxJuOR9De_MaAmArEALw_wcB">nosh(ナッシュ)</a>を頼み始めたのでこれを食べることが多いです。<br />  あとはコンビニとかお弁当屋さん行ったり、日によっては前の日の残り物とか。</p> <h3 id="そしてあっという間に夜">そして、あっという間に夜!</h3> <p>【通勤】<br />  17:00 退勤<br />  18:00 保育園到着!お迎え(自転車)<br />  18:30〜19:00 帰宅してからさっと夕飯の用意(大抵さっと作れる1品調理。自然と麺類が多くなるw)<br />  19:00〜20:00 子供たちとご飯食べて、片付け<br />  20:00〜20:50 パパが早い日は親子2人ずつでお風呂。遅い日は自分と子供たちで。<br />  21:00頃 寝かしつけ<br />  22:00頃 子供たちが寝てから残っている家事(食器洗い・洗濯)をしたり少し残ってる仕事したり<br />  0:00前後 就寝</p> <p>【リモート】<br />  18:00 退勤<br />  18:00〜18:30 保育園到着!お迎え(徒歩)<br />  18:30〜18:45 子供たちと歩いて帰る時間がおしゃべりタイム(家に着くと家事が始まってしまうのでママと子供の貴重な時間だったりもする)<br />  18:45〜19:10 夕飯の支度(最近はいろいろと手抜きを覚えて、Uber や 冷食のお世話になることもしばしば!ほどよい手抜き大事!)<br />  19:10〜20:00 夜ご飯(リモートなのでパパも一緒にご飯食べれることが増えた!!)<br />  20:00〜21:00 まったりしたあとお風呂(お風呂もほぼ毎日パパも子供と一緒に入れるので素敵・・・!)<br />  21:00〜22:30 寝かしつけ(最近子供たちの体力がついてきてなかなか寝てくれない…)<br />  22:30〜   残っている家事だったり、夫婦で映画見る時間だったり、仕事が残っているときは作業時間だったり<br />  0:00前後 就寝</p> <h2 id="まとめ">まとめ</h2> <p>ご覧頂くとなんとなくおわかりかなと思いますが、リモートは通勤時間(ドアtoドアで片道1時間弱)がなくなる分全体的に余裕のある時間の使い方になってますね。それぞれのメリットは↓ こんな感じかなと。</p> <p>【通勤】<br /> ・電車に乗って通勤する分、朝の時間はシビアに。緊張感はありますが、登園時のグズグズも時間が限られている分スパッと割り切れる!<br /> ・出社する分おしゃれにはちゃんと気を遣うので、メリハリがあって気持ちも切り替えやすい<br /> ・退勤時も同じく、電車の時刻があるのでずるずる仕事をしてしまうことはまずないかなと<br /> ・お昼はいろいろ選べるから飽きない!ランチ代はかかるけども…</p> <p>【リモート】<br /> ・通勤時間がない分、朝はゆっくり過ごせる(ヨガとかできる時間が増えた!)<br /> ・同じく通勤時間がない分、お迎えギリギリまで仕事ができる!<br /> ・お昼休憩にくつろげる!バレットでは昼休憩意外にも15分のシエスタ制度がありますが、家だと周りに気兼ねなく休めますよね!<br /> ・ランチ代は割と節約できる(人によるとは思いますが)家だと残り物をそのままチンして〜とかちょっとアレンジして〜とかもできますしね!<br /> ・ちょっとした隙間時間に家事もできちゃう。<br /> ・パパも家にいるので平日の家族の時間が増えたな〜と思うのもいいところ!</p> <h4 id="以上">以上。</h4> <p>もちろん、通勤でのメリットもありますがやはりリモートワークはワーママにとっては嬉しい環境ですよね。<br /> バレットはフレックスタイムもあるので、その点も働きやすさの1つかなと。<br /> 保育園って意外と保護者会や行事で早めに保育園にお迎え行かなければいけない日が1〜2ヶ月に1回くらいあったりとか<br /> 小さいうちは病気もしがちなので、朝病院に連れて行ってから保育園預けてお仕事とかもできるので<br /> 本当に柔軟に働けるのはありがたい限りです!!!</p> <p>このご時世、特にライフワークバランスに目を向けられる機会が増えてきてるかなと思いますが<br /> 私は育休からの復帰がバレットでよかったなーと、とても感じています。<br /> もちろん制度もそうですが、働く人たちが温かい人たちばかりなのもとても魅力。<br /> これからもバレットで楽しくお仕事していけたらなーと思います!</p> <p>最後までお読み頂きありがとうございました!</p> maripig61