はてなブックマーク

情報システム部でAWS周りの運用保守をしている「ねぎ」です、こんにちは！ この記事は弥生 Advent Calendar 2022の4日目エントリーです。 今回の記事では、 AWSアカウントが増えてきて各アカウントの構成がどうなっているかがわからない！ 他のアカウントはどのような構成でサービスが稼働しているんだろう？ など、このAWSアカウントでは、ある程度どういうAWSサービスを利用しているのかが把握できる そんなAWS構成図の自動描画に関する仕組みを紹介したいと思います。 構成図描画の比較 全体構成 Code系 ECS / Fargate / ECR EventBridge / Lambda その他のリソース 工夫した点 あとがき 一緒に働く仲間を募集しています 構成図描画の比較 みなさんはAWSの構成図どうされていますでしょうか？ 「aws構成図 ツール」などで検索してみると色々なも

この記事は 弥生 Advent Calendar 2022の10日目の記事です。 こんにちは、弥生の広報・PRチームの庄村です。 突然ですが、弥生の開発本部にはオフィシャルマスコットキャラクターが存在します。 その名も「もくにゃん」 このキャラクター、とにかくかわいい。 社内にもファンが多数おり、Slackスタンプにもなって超絶愛されキャットの地位を獲得しています。 技術勉強会である「もくテク」を盛り上げるために生まれたとか。なんかそのあたりのいろんな経緯には、笑いあり涙ありたぶんいろんなエピソードがありますが、本記事ではその辺はすべてすっ飛ばし、社内マスコット作成のメリットともくにゃんへの愛を語ります。 学びは特にありませんが、しばしお付き合いください。 「もくテク」とは？ 弥生株式会社が運営する勉強会。 もくもく会ではなく、わいわいする会。 競合他社でもテクノロジーを語るときは仲間。

こんにちは、弥生の日高 @hidakatsuya です。普段は クラウド見積・納品・請求書サービス「Misoca」 の開発に携わっています。 Misoca には、作成した請求書などの帳票を PDF としてダウンロードするだけでなく、PDF の内容を印刷したり、郵送したり、FAX として送信するなど、PDF が関連する機能が多くあります。そして、毎日非常に多くの PDF が Misoca 上で生成されています。 今回は、そんな Misoca の PDF をどのようにテストしているのかについてまとめたいと思います。 Misoca の PDF 本題に入る前に、Misoca で扱っている PDF についてもう少しだけ説明しておきます。 請求書・納品書・見積書・注文書・注文請書・検収書・領収書の7種類の PDF がある 請求書・納品書・見積書は複数のテンプレートを提供している 執筆時点で、請求書には

こんにちは。弥生の内山です。 この記事は弥生 Advent Calendar 2021 23日目の記事です。 qiita.com はじめに 現在、弥生では新しいサービスの開発を行っており、今後主流となりうる技術を積極的に取り入れる方針で進めています。 本記事のタイトルにあるマイクロサービスアーキテクチャやGraphQLもそのようにして取り入れてきました。 ただし、それらの技術を実際にプロダクトに適用するのは一筋縄ではいかず、いろいろな遠回りを行った末にどうにか適用できた、というのが実際のところでした。 その過程については、前回12/16のもくテクにてお話させていただきました。 mokuteku.connpass.com この過程の中で特に苦労したのが、既にREST APIとして構築したサービス群をGraphQL APIのサービス群へ移行させることでした。 もくテクの発表では、かなりの駆け足

弥生 Advent Calendar 2021 6日目の記事です。 システム開発部Misocaチームエンジニアの mizukmb です。 クラウド請求書作成ソフトであるMisocaのインフラはサービス稼動開始からつい最近までAWS EC2を使ってアプリケーションを運用していましたが、この度Dockerコンテナ管理サービスであるECSに移行し、この移行作業がほぼ完了致しました 🎉 ECS移行に際しては長い時間をかけて準備や検証を行っており、開発者ブログで紹介したいネタがいくつかあるのですが、今回は実際にEC2で稼動するappサーバを無停止且つ段階的にECSに移行した方法について紹介したいと思います。 ECS移行前の状態と作業の概要 移行前のMisocaアプリケーションのインフラは複数台のEC2インスタンス上で稼動しており、各EC2インスタンスへのリクエスト振り分けはALBを使って制御してい

こんにちはmisocaアプリの評価が3.5になって嬉しいtijinsです。 今日はAndroidアプリのインストルメンテーションテストについて紹介します。 Misocaアプリのテスト MisocaアプリはCIによる自動テストとリリース前の手動テストを行っているのですが、開発スピードと品質のバランスを保つ為、手動のテストの自動化を進めています。 3種類の自動テスト Misocaアプリでは3種類の自動テストを使用しています。 今回は、インストルメンテーションテストについて説明します。 インストルメンテーション テスト エミュレーターまたは実機上で実行されるテストです。 実際のアプリを動作させているので手動テストと同等の検証が可能ですが、実行速度が遅いです。 Unitテスト 開発PCのJVM上で実行されるテストです。 エミュレーターを介さない為、高速なテストが可能ですが、AndroidOSやCo

はじめに こんにちは、 id:RKTM です。 先日乗鞍岳にバックカントリースキーに行きました。昔は弱音を吐きながら必死で下りたルートを、今回は気持ちよく颯爽と（主観ですが）滑れるようになり、スキー技術の上達を感じて嬉しかったです。 位ヶ原から乗鞍岳剣ヶ峰方面 Rails 6.1の新機能：dependent: :destroy_async を使ってみた さて、最近MisocaはRails 6.1にアップデートしました。*1 早速Rails 6.1の新機能 dependent: :destroy_async を導入しましたので、その紹介をします。 dependent: :destroy_async は、関連を非同期で削除する Railsの関連を設定する際、 親 has_many :子, dependent: :destroyという設定を書いた人は多いと思います。これは「親のレコードを削除する

こんにちは、 @mugi_uno です。 Misocaがサービスローンチされたのは 2011年です。実は2021年は10年目ということで何気に節目の年だったりします。 10年もあれば世の中的にもさまざまな技術変遷があり、Misocaもその波に乗っていけるよう、日々改善を繰り返してきました。 というわけで今回は、私自身がフロントエンド側の作業を多くやってきたこともあり「この10年間でMisocaのアーキテクチャがどのように変わってきたのか？」をフロントエンド側に焦点を絞って振り返ってみたいと思います。 ※ 意思決定に関する資料が無いものも存在するため、一部は情報に基づく推察になる点をご承知おきください。 年表 いきなりですが、ざっくり年表を書いてみました。 上部の黄色いラインは、フロントエンドに大きい影響を与えたMisocaの機能です。 これをもとに、サービスローンチから順を追って見てみます

こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 ついにECS execできるようになったことに咽び泣いていますが、今日の記事は全然関係ない話です。 社内向けに「どうすれば質の高いミーティングを作れるか」を検討した読み物記事を書いていたのですが、社外に出しても問題ない内容だったので開発者ブログに載せることになりました。 割と社内では評判が良かったので、参考になる部分があれば幸いです。 目次 目次 はじめに 要点 よいミーティングとは ミーティングとは よいミーティングの条件 目的の達成度 達成度と時間のバランス 効率の良いミーティング ミーティングの準備 ミーティングの目的とゴールを明確にする ミーティングの参加者を決める ミーティングの前提情報を洗い出す ミーティングの進行方法を決める ミーティングの実施 ファシリテーターの役割 タイムキーパーの役割 参加者の役

こんにちは、 @mugi_uno です。 少し前に背骨の手術を受けたら身長が伸びました。 🎉 受注管理機能をリリースしました 2020/12/10に、Misocaに新しく「受注管理機能」をリリースしました。 www.misoca.jp いままでは、請求書・見積書・納品書といった単位でのステータス管理が主でしたが、新たに追加された受注管理機能を使うことで、案件単位でステータスを管理しつつ、各文書への変換も簡単に行えるようになりました。 そして、同時にこの受注管理機能は、開発面においても様々な新しい技術面でのトライもありました。 Vue.js & Vue Composition API GraphQL Apollo Client & Vue Apollo Atomic Design Scoped Style 今回は、これらについてどういった対応をしたのかと、リリース後にふりかえってみてそれぞ

こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 そしてこの記事は弥生 Advent Calendar 2020の 11日目の記事です。 昨日の担当はkosappiさんのCodePipelineのステージ間で変数を受け渡しするでした。 プログラミング言語について Misoca開発チームでは主にサーバーサイド側言語としてRuby、クライアントサイド言語としてTypeScriptを利用しています。 一方で弥生製品開発チームは主にC#を利用しており、最近ではTypeScriptやGo言語も一部で利用しています。 そうなってくると、気になるのは「今後新しいプロダクトを作るとしたら、プログラミング言語は何にするべきなのか？」ということです。 今回はそれぞれの言語の特徴や向いている用途について、ざっくりまとめていきたいと思います。なお極力資料を探しながら正確に書こうと思います

この記事は弥生 Advent Calendar 2020 の10日目の記事です。 こんにちは。@kosappi です。最近は SRE としてインフラの改善に取り組んでいます。 Misoca 開発チームでは AWS を利用してインフラを構築しています。 AWS CodePipeline で使える変数の受け渡しが便利だったので、今回はこれを紹介します。 CodePipeline の基本機能について知りたい方は AWS による CodePipeline の紹介をご覧ください。 AWS CodePipeline（継続的デリバリーを使用したソフトウェアのリリース） CodePipeline における変数の受け渡し CodePipeline では各アクションの成果物をアーティファクトでやりとりできます。 近頃は、これに加えて「変数」という成果物も扱えるようになっています。 参考: AWS CodePi

弥生 Advent Calendar 2020 8日目の記事です。 開発本部の id:mizukmb です。普段はMisocaのインフラの面倒を見たりしています。 Misocaの開発チームでは毎週SLOの状況を共有する時間をとっています。SLOを設定した話は別記事で紹介しています。 tech.misoca.jp 先日、開発チームに共有したところ普段よりもレスポンスタイムが悪化してることがわかりました。これ以上の悪化はサービスに大きな悪影響を及ぼしてしまう事も懸念されました。 そこで、年末年始をトラブルなく過ごせるように開発チームでボトルネックを見つける会を開き、原因の特定から実際に改善し効果が表われたことを確認できました。 問題発見 Misocaには時期によってアクセス数の波があります。月末・月初はアクセス数が普段と比べて多くなり、レスポンスタイムもそれに伴って増加しやすい傾向にあります。

こんにちは、弥生のMisoca開発チームの黒曜(@kokuyouwind)です。 Kaigi on Railsの登壇が決まったのでよろしくおねがいします。弥生社員としては初登壇になります。 「おめでとうございます。 選考の結果、あなたのプロポーザルは採択されました！」 とのことなので、Kaigi on Railsお話しにいきますー— 黒曜 (@kokuyouwind) August 25, 2020 前回の記事が濃厚だったため、今回はライトなTips記事です。よろしくおねがいします。 tech.misoca.jp 👯‍♀️ VSCode LiveShareを使ったリモートペアプログラミング 皆さん、ペア作業してますか？ ペアプログラミングはドライバー・オペレータの交代など具体的なノウハウも多く、このブログでも以前に紹介記事を書きました。 tech.misoca.jp 上記の記事ではリモー

こんにちは、弥生 Misoca チームでマークアップをする方のデザイナー @kanizmb です。 今回、約1年をかけて古の Bootstrap の撤去および CSS 設計手法の導入（FLOCSS 化）をやり遂げたので、これらの変更をどのように進めていったかについてお話しします。 どういった状況だったか Misoca ローンチは 2011年、当時最新であった Bootstrap 2.3.2 を用いて構築が始まりました。(*1) 当初は請求書の郵送に特化した非常にシンプルなサービスだったため、少しの上書きでスムーズに開発が進められ、Bootstrap のメリットを存分に生かせていたのだと思います。 しかし時は流れ、取引先管理、品目管理、外部サービスとの連携など、機能が増え続けるとどんどん綻びが出始めます。 設計方針もないままに野放図に差し込まれた CSS たちは、いつしか激しい詳細度バトルを

こんにちは、@mugi_uno です。気付いたら弥生社員になってました！！ プロジェクトの立ち上げはむずかしい Misocaチームで何かしらの課題に取り組む場合、基本的にはプロジェクト化して進めていきます。 その際、まずはインセプションデッキを作成して「目的やゴールは何か」「何をして、何をしないか」といったことを明文化し、メンバーで認識を揃える作業をします。 ですが、現実的にはそれ自体が難しいケースが存在します。 何から手を付ければいいのかわかりません！ たとえば 多種多様な立場の人が参加するプロジェクトを始めるが、メンバー個々人が何を重要視しているかを互いに知らない ○○について効率化したいけど、具体的に何が課題で次に何をすべきかが誰もハッキリとは見えていない 膨大なタスクが存在していて、どういった判断軸で優先順位をつけていけばいいのかがわからない みたいな経験はないでしょうか。 このよ

こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 最近はシャニマスのイベントシナリオ感想記事をnoteにまとめたりしています。 😨 急に本番のレスポンスタイムが悪化した話 Webエンジニアにとって、「本番障害」という4文字ほど見たくないものはないでしょう。 本番障害ほどではないにしても、「急なレスポンスタイム悪化」もあまり見たくない文字列ですね。まぁ、見たくなくても向こうからやってくるんですが… というわけで、今回は本番レスポンスが急に悪化したときの話です。いろいろ調べた結果、利用しているオープンソースプロジェクトが原因だったことがわかりPull Requestを送ったので、その流れをまとめてみたいと思います。 ❗️ レスポンスタイム悪化の検知 Misocaでは監視ツールとしてMackerelを、APMツールとしてSkylightを利用しています。 本番レスポン

はじめに こんにちは、 @rktm です。 Misocaではプロジェクトを開発プロセスの基本としています。 recruit.misoca.jp ですがプロジェクトの枠からこぼれるタスクが増えてきました。 それらタスクをこなすべく、1年ほど前に「遊軍」というチームを作りました。 遊軍チームは当初はお試し運用でしたが価値を継続的に出せており、今は定着しています。 その遊軍チームについて、創設の背景、運用結果について書きます。 前回のブログ記事「フロントエンドチームはじめてました」と合わせて、Misocaでの、問題を個々人の努力だけではなく、組織構造の変化によって解決する事例としてお読みいただければ幸いです。 tech.misoca.jp 遊軍創設の背景：個々人の「余裕」「余力」に頼っていてはこなせないタスクが積み上がってきた Misocaでは、2018年末ぐらいから大規模な機能追加・改修プロジ

こんにちは @mugi_uno です。 某ウイルスで不安な日々が続きますが、ひとまずうがい・手洗いをちゃんとやっています。 フロントエンドチームができてました 最近買ったiPadProが嬉しくて書いてしまった謎のロゴ Misocaでは半年ほど前にフロントエンドチームを新たに立ち上げました。 自分たちなりの形でひっそりと活動を続けてきて、幾つか成果も出てきています。 なぜチームを作ったのか / 何をやってるのか といった点をご紹介したいと思います。 徐々に表面化してきたフロントエンドの課題 Misocaでは個々人が「バックエンドエンジニア」「フロントエンドエンジニア」といった肩書を持っておらず、必要に応じてバックエンドもフロントエンドも触ります。 しかし、全体的にはフロントエンド側に比重を置くのは一部のメンバーに限られており、それに伴うさまざまな課題が表面化してきました。 個々人による改善活

こんにちは。 デザイナーの@torimizunoです。 最近はリモートの日が増えたこともあり、リングフィットアドベンチャーで運動不足を解消する日々です。 今回は、現在進行形で進んでいる「ユーザー体験統一プロジェクト」について、1年間の歩みについてご紹介します。 まだまだ真っ最中ですが、1年という区切りでどのような取り組みや成果があったのか、お伝えしていきます。 立ち上げ 立ち上げについては、過去入社エントリーで触りだけ、取り上げました。 Misocaはサービスリリースから5年以上経ち、Web・iOS・Androidと3つの手段で提供されています。 長年サービスを運用していく中、プラットフォーム内、OSをまたいでユーザー体験の違いが発生してしまっていました。 社内でもデザインの生産性の低下につながったり、実装時に調査と意思決定に負荷が発生しており、「サービスでユーザー体験を一元化することで、

こんにちは。 最近、スラムダンクの新装版を買ってバスケ熱があがっている @RyoKawamata です。気になるキャラは森重 寛です。 さて、今回はMisoca流のふりかえり についてまとめてみました。 ふりかえりというと、一つの空間に皆で集まり、ポスト・イットにKPTを書いてホワイトボードに貼って、、、というイメージがあると思いますが、Misocaはフルリモートワークの会社です。 リモートでどのようにふりかえりを行うのか？まだあまり事例がないものだと思うので紹介します。 ふりかえりとは？ 最初にふりかえりの定義を確認。 ふりかえりはスクラムの文脈だとスプリントレトロスペクティブです。スプリントレトロスペクティブは、下記のように定義されています。プロジェクト、チームを継続的に改善していくために、とても重要なものですね。 スプリントレトロスペクティブは、スクラムチームに考える機会を与えるもの

メリークリスマス！🎄 この記事はMisoca+弥生 Advent Calendar 2019の25日目です。 qiita.com 最終日の記事は、初日から24日ぶり2回目となる黒曜(@kokuyouwind)がお送りします。 💎 Ruby 2.7 will be released! ついに本日、Ruby 2.7 が正式リリースされますね！ Misocaでは id:eitoball の尽力により、すでにRuby 2.7対応のPull Requestがマージ待ちの状態です。年末までにリリースするかは未定ですが、遅くとも年明け最初の週にはリリースできると思います。 また、アドベントカレンダー初日に書いたActivePattern gemとMethodMatchable gemも、Ruby 2.7.0がリリースされたら合わせてバージョンを上げる予定です。 Experimentalな機能とはいえ

こんにちは！遊軍チームに所属しているRKTMです。 先日、ボルダーの課題開拓で3本の課題設定&初登できました。簡単な課題ですが、初登者として名前が残るのは特別な気分ですね。 未開拓の岩。倒木と、クラックの落ち葉と土とコケを処理してやっと登れます。 機能の廃止を分析に基づいて決断する さて、最近Misocaでは、「チュートリアル機能」を廃止しました。 機能を廃止するというのは大きな決断でしたが、今回はその廃止にいたるまでの経緯と分析について書くことにします。 当たり前のことを当たり前にやっているだけですが、Misocaの意思決定の一例としてお読みいただければ幸いです。（分析は、機密情報に触れる部分があるため、概要に留めています。また、KPIについても同様に詳細は省略しています。） 「チュートリアル機能って効果あるの？」 Misocaにおけるチュートリアルは契約直後のお客様全員に表示される機能

Misoca開発チームの黒曜(@kokuyouwind)です。 技術書典7の準備があんまり進んでなくてワタワタしています。 📅 木テク 少し前の話になってしまいますが、8月8日に開催されたもくテクpowered by Misoca #2でFeature Flagを使ったリリースの話をしてきました。 以下がそのときの発表スライドです。 今回はこの発表内容をブログでおさらいしたいと思います。 🚩 FeatureFlag Feature Flagは、機能の有効・無効をコード上で切り替えるテクニックです。(Feature ToggleやFeature Switchなどと呼ばれることもあります。) ざっくり言うならば、以下のようにフラグに応じて機能を有効にするのがFeature Flagです。 if feature_enabled? process_with_feature() else pro