DeepL翻訳と翻訳結果の送信ができるSlackアプリを作ってみた

こんにちは!
CIO室コーポレートエンジニアリンググループでインターンをしている赤羽です。

この記事は、マネフォアドベントカレンダー2021 7日目の投稿です。

今回はSlack上でショートカットから呼び出せるDeepL翻訳アプリを紹介します。

今回紹介するアプリはこちらで公開されているソースコードを参考にさせていただき、機能を追加したりアレンジしたものをPythonで作成しました。

完成品使用例

使用方法

/deeplと入力してショートカットを呼び出すとDeepL翻訳のポップアップウィンドウ(モーダル)が開きます。

あとは画像の手順通りですが、説明がなくても直感的に操作できるようになっていると思います。

続きを読む

Jira Cloud for Sheets, Google Apps Script, Google Data Portalを使って、日次で不具合消化状況を可視化してみた

この記事はマネーフォワードアドベントカレンダー2021🎄の2日目の記事です。
 
こんにちは!HRソリューション本部でQAエンジニアをしている森田です。
HRのQAグループでは、HR領域の複数プロダクトに対する品質保証活動を行っています。

私は、2021年8月末に1stリリースを迎えたクラウド年末調整のテストマネージャー(自称)として、テスト計画〜テスト進捗管理〜不具合管理に携わっていました。

さて、みなさんは、どのように不具合消化状況(次のリリースで消化予定の不具合チケット件数とその進捗)を把握されていますか?

なるべく開発チームの工数(コミュニケーションコスト含む)を取らずに、不具合の消化状況を見れないか、重要度の高い不具合が溜まってきた時に気づけるようにできないか。そんなことを考え、Jira Cloud for Sheets, Google Apps Script, Google Data Portalを使って、クラウド年末調整の不具合消化状況を可視化してみることにしました。

すでに利用していたツール

  • 案件や不具合の管理:Jira Software
  • コミュニケーションツール:Slack

 

行ったこと(最終アウトプットイメージ)

1.不具合消化状況の可視化(日次)

  • 各月(リリースごと)の不具合総数、不具合残数(Sprintが今回、かつ、進捗が未完了)、完了不具合件数(Sprintが今回、かつ、進捗が完了)

2.”BUG”かつ”highest”かつ”未完了”のチケット番号をSlackで通知(日次)

(余談)なぜ懐中電灯なのかについては、こちらの記事をご覧ください。

続きを読む

こんにちわ、5年前にお世話になっていた開発者のものです

こんにちは
マネーフォワードでVPoEをしています、渋谷(@ryoff) です。

この記事はマネーフォワードアドベントカレンダー2021🎄の1日目の記事です。

私は戻ってきた

アドベントカレンダーなにか書こうかな、って悩んでたんですが、実は最近、VPoE業をしつつも、とあるプロダクトのチームリーダーも兼務し始めたので、その話を書こうと思います。

実はこのプロダクト、自分が2014年にマネーフォワードに入社後に立ち上げを経験したプロダクトでして、2016-2017年ぐらいに次期リーダーに託して自分は別の業務に移っていきました。

エンジニアのキャリアにおいて、1つのプロダクトに関わり続ける事はむしろ珍しく、数年で別の業務、もしくは、別の会社へと移っていくことも多いのではないかと思います。
過去自分が関わったプロダクトに戻ってくる、という経験は珍しいので、 過去自分が関わったコード・設計・チームは、自分が抜けた後の数年でどう変わっていったのか という体験レポートをお届けしようと思います。

当時のプロダクト

添付の画像はこのプロダクトの first commit message です。
※ ちなみにこのコミットをした開発者は、自分の後任の次期リーダーになってくれました。

続きを読む

チームでやっている ZenHub x Scrapbox を使ったフルリモートなアジャイル開発の紹介

こんにちは!
マネーフォワード クラウド横断本部のWebエンジニアの はるやま (@linnefromice) です。

現在クラウド横断本部で行っている既存サービスのリプレイスプロジェクトにおける開発チームでの開発プロセスの紹介をさせていただきたいと思います!

背景

プロジェクト発足当時は2人だったのですが、現在5人にまでメンバーが増え、そのうちの1人は海外居住者なので現在入国できておらずフルリモートで参画しています。海外居住者でないメンバーに関しては最低週1出社としていて、チームとしてはほとんどがリモートでの勤務がベースになっています。
(当たり前なことではあるのですが、)途中参画したメンバーはそれまでの経緯や意思決定をキャッチアップも必要ですし、初期メンバーはそれに対するフォローだったり、メンバー同士の相談などもなるべく低コストでスムーズにしたいです。

上記のような背景があり、仮にフルリモートだとしてもチーム開発を問題なく継続していけるためのルール/仕組みづくりを行ってきました!

その前にリモートにおけるコミュニケーション問題

エンジニア周りに限った話ではないのですが、リモート化によって、何よりコミュニケーション自体の難しさがどのチームにもあり、今もまだ話題になることが多いです。
リアルで集まっていたときのような空気感による気軽さがなくなり、直接対面して会話していたときには伝わっていたようなニュアンスも伝わらなくなり…と、他にも様々な課題があると思いますが、新規参画者においては特に顕著に起こりやすく、自分たちのチームにはグローバルメンバーもいるので、参画当初は前述のような課題がありました。

続きを読む

開発者でも取り組める!発展期のサービスこそ、SLOやDatadogダッシュボードで状態を可視化してメンバーに安心を届けよう

こんにちは。
2021年10月からマネーフォワード クラウド勤怠の開発チームでSREとして働いています、VTRyo です。

入社2週間経過ブログを書いて以来の登場です。
https://moneyforward.com/engineers_blog/2021/10/28/mf-on-boarding/

現在の僕は、チーム一人目のSREとして活動しています。せっかくなので、SRE立ち上げ記を綴っていきます。

第1話は 「サービスの状態を可視化して、まずはチームメンバーに安心を与えていこうな」 という話をします。

話さないこと

  • SREそのものについて
  • 具体的な作業ログ

経緯

10月某日。入社オリエンや開発オリエンが終わって徐々にSRE活動を始めることになりました。

必要なチャンネルに一通り招待され、どんなやり取りが発生するかを把握していきます。
そこで、真っ先に気になったのはモニタリングに関することでした。

errorsチャンネルに、Rollbarでトラッキングされたエラーが四六時中ずっと流れています。

通知だけされていて「あ、これは通知はされていますがユーザ影響のないものです」といった、いわゆるオオカミ少年と化していました。

続きを読む

MUI v5 化を経て気づいたやっておいたよかったこと/やっておけばよかったこと

こんにちは!
マネーフォワード クラウド横断本部のWebエンジニアの はるやま (@linnefromice) です。

現在クラウド横断本部では BtoB 向けサービスのリプレイスプロジェクトの開発を行っており、その過程で実施した UI ライブラリのバージョンアップを通して学んだことを紹介させていただきたいと思います!(@thinceller)、一緒にこちらの対応方針を考えたり対応をしました!)

背景

現在進行中のプロジェクトは2021年初から着手しており、UIライブラリとして他PJでも利用実績のあった MUI (当時 Material-UI ) を選定しました。
当時の最新バージョンは v4 でしたが、開発を進めるうちに v5 の情報が上がってきました。
v5 のスケジュールを見ると、プロダクトリリース前に v5 が正式バージョンとなることがわかったので、v5 にあげるための活動をスプリントに組み込み、実際にバージョンアップに取り組むことにしました。

参考

取り組んだこと

こちらはバージョンアップ時の実際の Pull Request です。

続きを読む

サーバサイドの進捗に依存しないための Next.js x GraphQL のフロントエンド開発の工夫

こんにちは!
マネーフォワード クラウド横断本部のWebエンジニアの はるやま (@linnefromice) です。

現在クラウド横断本部では BtoB 向けサービスのリプレイスプロジェクトの開発を行っており、今回は とフロントエンド開発においてそのプロジェクトで悩んだ点とそれに対する工夫の紹介をさせていただきたいと思います!(Special Thanks かわかみさん(@thinceller)、一緒にアーキテクチャの実現とこのフローを考えてもらいました)

プロジェクトの特徴

今回のプロジェクトはリプレイスのため、既存のサービスで実現している機能の再現/改善または新規機能の開発を行うのですが、

  1. 現行サービスのコアモデル/データをベースに扱う必要がある
  2. サービスの特徴として、他のクラウドサービスとの連携により実現したい機能が多い

のような特徴があります。
これらの特徴により、

  • サーバサイドの開発
    • 要件定義/設計および他サービスとの連動の詳細設計など上流でやるべき活動のコストが高く、すぐ開発着手はできない状態
  • フロントエンドの開発
    • リプレイスにおける機能要求/要件整理と現行システムの挙動の整理ができれば、デザイン->開発とサーバサイドより比較的早く開発着手ができる状態

フロントエンドがサーバサイドより比較的早く開発着手ができる状態なので、サーバサイドに極力依存しない開発フローで出来る限りproductionレベルのフロントエンド構築を進める方法を考えました。

続きを読む

Github Actionsを利用して作業を自動化してみよう

こんにちは。
CTO室マイクロサービス推進部で働いている元(Won)です。

マイクロサービス推進部では、Github Actionsを利用した自動化の取り組みを進めています。
今回は、以前のブログ記事で紹介した「メール取込」の開発で行われている自動化の取り組みと、改善した内容について紹介します。

目次

  1. Github Actionsとは?
  2. Issue作成自動化
  3. PR作成自動化
  4. まとめ
  5. 終わりに

Github Actionsとは?

https://github.com/features/actions
Githubイベントをトリガーにして一連のワークフローを実行する機能です。

Github Actionsのトリガーで利用される例としては

  • Issue
    • open
    • close
  • Pull Request
    • open
  • Scheduled events(定期実行)

などなど多くのイベントを扱うことができます。

続きを読む

本番稼働中のEKSクラスタにCluster Autoscalerを導入した話

こんにちは。
マネーフォワードでエンジニアとして働いているgotoken(@kennygt51)です。
今回は、当社の提供するサービスの一部が稼働しているEKSクラスタにCluster Autoscalerを導入した話をします。

Cluster Autoscalerとはなにか

Cluster AutoscalerとはKubernetesクラスタのNodeのオートスケーリングを実現するツールです。需要に応じてKubernetesクラスタのNodeを自動的に追加・削除します。

Cluster Autoscalerがトリガされるタイミングは2つあります。Nodeが増えるタイミング(スケールアウト)と、Nodeが減るタイミング(スケールイン)です。

スケールアウトはリソースが足りない状態になるとトリガされます。ここでいう「リソースが足りない」とは、Podが起動できない状態になった(Pending状態のPodが存在する)という意味です。逆にスケールインは、リソース過多の状態になるとトリガされます。「リソース過多」とはPodのResource RequestsをみたときにそのNodeで動いているPodが他のNodeで動かせるという意味です。

つまり、クラスタ全体やNodeのロードアベレージが上下した際にスケールするのではなく 「Pending状態のPodができたタイミングであったりNodeのリソースに対して稼働中のPod数が少なくなったタイミングでスケールする」 という挙動になります。

なぜCluster Autoscalerを導入しようとしたのか

実は当社のEKSクラスタは当初、Cluster Autoscalerを導入していませんでした。

理由としては次の2点です。

続きを読む

StepFunctionsを使ってSageMakerエンドポイントのデプロイを実行する

こんにちは、CTO室AI推進部@ken11です。
みなさんカナリアは好きですか?
僕は大好きです。
華麗なパスさばき、高速ドリブル、迫力のシュート、カナリア軍団ブラジル代表のプレーはいつ見ても美しい…

ええ、もちろんここはエンジニアブログなのでサッカーの話をしに来たわけではありません。サッカーの話がしたい人は恵比寿に来てもらえれば夜な夜なCLの試合を見守る僕とサッカー談義を繰り広げることが可能かもしれません。

今日話したいのはカナリアはカナリアでもカナリアリリースの話です。
SageMakerエンドポイントってカナリアリリースできるの?

SageMakerエンドポイントのデプロイ

結論からいえば、頑張ればカナリアリリースできます。
そもそもSageMakerエンドポイントってデプロイ作業とかみなさんどうしてますか?

続きを読む