よいミーティングの作り方 - 弥生開発者ブログ
こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 ついにECS execできるようになったことに咽び泣いていますが、今日の記事は全然関係ない話です。 社内向けに「どうすれば質の高いミーティングを作れるか」を検討した読み物記事を書いていたのですが、社外に出しても問題ない内容だったので開発者ブログに載せることになりました。 割と社内では評判が良かったので、参考になる部分があれば幸いです。 目次 目次 はじめに 要点 よいミーティングとは ミーティングとは よいミーティングの条件 目的の達成度 達成度と時間のバランス 効率の良いミーティング ミーティングの準備 ミーティングの目的とゴールを明確にする ミーティングの参加者を決める ミーティングの前提情報を洗い出す ミーティングの進行方法を決める ミーティングの実施 ファシリテーターの役割 タイムキーパーの役割 参加者の役
アプリケーションの不調を発見し、チームで改善できた話 - 弥生開発者ブログ
弥生 Advent Calendar 2020 8日目の記事です。 開発本部の id:mizukmb です。普段はMisocaのインフラの面倒を見たりしています。 Misocaの開発チームでは毎週SLOの状況を共有する時間をとっています。SLOを設定した話は別記事で紹介しています。 tech.misoca.jp 先日、開発チームに共有したところ普段よりもレスポンスタイムが悪化してることがわかりました。これ以上の悪化はサービスに大きな悪影響を及ぼしてしまう事も懸念されました。 そこで、年末年始をトラブルなく過ごせるように開発チームでボトルネックを見つける会を開き、原因の特定から実際に改善し効果が表われたことを確認できました。 問題発見 Misocaには時期によってアクセス数の波があります。月末・月初はアクセス数が普段と比べて多くなり、レスポンスタイムもそれに伴って増加しやすい傾向にあります。
VSCodeでDraw.ioをLive Shareしたら最高の体験だった - 弥生開発者ブログ
こんにちは、弥生のMisoca開発チームの黒曜(@kokuyouwind)です。 Kaigi on Railsの登壇が決まったのでよろしくおねがいします。弥生社員としては初登壇になります。 「おめでとうございます。 選考の結果、あなたのプロポーザルは採択されました！」 とのことなので、Kaigi on Railsお話しにいきますー— 黒曜 (@kokuyouwind) August 25, 2020 前回の記事が濃厚だったため、今回はライトなTips記事です。よろしくおねがいします。 tech.misoca.jp 👯♀️ VSCode LiveShareを使ったリモートペアプログラミング 皆さん、ペア作業してますか？ ペアプログラミングはドライバー・オペレータの交代など具体的なノウハウも多く、このブログでも以前に紹介記事を書きました。 tech.misoca.jp 上記の記事ではリモー
🔦「お気持ち会」で暗闇を払う - 弥生開発者ブログ
こんにちは、@mugi_uno です。気付いたら弥生社員になってました！！ プロジェクトの立ち上げはむずかしい Misocaチームで何かしらの課題に取り組む場合、基本的にはプロジェクト化して進めていきます。 その際、まずはインセプションデッキを作成して「目的やゴールは何か」「何をして、何をしないか」といったことを明文化し、メンバーで認識を揃える作業をします。 ですが、現実的にはそれ自体が難しいケースが存在します。 何から手を付ければいいのかわかりません！ たとえば 多種多様な立場の人が参加するプロジェクトを始めるが、メンバー個々人が何を重要視しているかを互いに知らない ○○について効率化したいけど、具体的に何が課題で次に何をすべきかが誰もハッキリとは見えていない 膨大なタスクが存在していて、どういった判断軸で優先順位をつけていけばいいのかがわからない みたいな経験はないでしょうか。 このよ
急なレスポンスタイム悪化から、オープンソースプロジェクトにPull Requestを送るまで - 弥生開発者ブログ
こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 最近はシャニマスのイベントシナリオ感想記事をnoteにまとめたりしています。 😨 急に本番のレスポンスタイムが悪化した話 Webエンジニアにとって、「本番障害」という4文字ほど見たくないものはないでしょう。 本番障害ほどではないにしても、「急なレスポンスタイム悪化」もあまり見たくない文字列ですね。まぁ、見たくなくても向こうからやってくるんですが… というわけで、今回は本番レスポンスが急に悪化したときの話です。いろいろ調べた結果、利用しているオープンソースプロジェクトが原因だったことがわかりPull Requestを送ったので、その流れをまとめてみたいと思います。 ❗️ レスポンスタイム悪化の検知 Misocaでは監視ツールとしてMackerelを、APMツールとしてSkylightを利用しています。 本番レスポン
Misocaのリモートワーカーの仕事環境2019 - 弥生開発者ブログ
こんにちは。@KawamataRyoです。 エンジニアになってから着々と体重が増えて、先日80kgの大台に乗りました。 大学の部活ではライト級（60kg以下）で試合に出てたのでその頃から20kgの増量。日々色々な方面で成長中です。 さて今回は、Misocaのリモートワーカーの仕事環境のお話です。 以前こちらの記事で紹介してから早2年、メンバーの入れ替わりもありリモートの環境も大分変わったと思うので、2019年度版を改めて紹介します。 @KawamataRyo リモート歴 基本勤務時間 6ヵ月 8:00〜17:00 仕事環境のこだわり モニターアームがカッコいいと思い、無駄にディスプレイを浮かせています。キーボードの押打でめっちゃディスプレイが揺れるのが悩み 椎間板ヘルニア持ちなので、デスク、椅子は良いものを使っています。昇降デスクなので時々スタンディングデスクとしても使っています 隣にベン
「斧を研ぐ時間」エンジニアリングフライデーという試み - 弥生開発者ブログ
こんにちは Misoca 開発チームの id:mallowlabs です。最近は ドラえもん のび太の牧場物語 にハマっています。使っている道具のグレードを上げるために、牧場はそっちのけで鉱山にこもって鉱石を掘り出す毎日です。 さて、先日の 軽減税率・区分記載請求書対応のリリース は開発チームにとっても比較的大きなリリースでした。そのため、リリースの直前には、このリリースに関係しないコミットは master ブランチにマージを控えることになり*1、自然と開発メンバーが普段使っているツールの整備や自由研究が行われることになりました。 ふりかえりで、このいわゆる「斧を研ぐ時間」がよかったという声が複数出たため、この時間を狙って作ってみようという TRY が生まれて「エンジニアリングフライデー」という試みが生まれました。 今回はこのエンジニアリングフライデーについて紹介したいと思います。 エンジ
年末なのでBug Bashしてみたら盛り上がった - 弥生開発者ブログ
Misoca開発チームの北村です。 年末の寒波で山に雪が増えることを期待しています。 年末だしBug Bashやってみた 年越しまでWork-In-Progressな作業を持ち越したくない（年明けに記憶を取り戻すのが大変そう） 休暇直前に大きなリリースはしたくない ということで、この機会にBug Bashをやることにしました。Misocaで開催するのは初めての試み。 Bug Bashのやり方などはKyashさんの下記の記事を参考にしました。 blog.kyash.co Bug Bashやってみた 普段一緒に仕事しないメンバーで3チームを作り、Misocaを叩いてみました。 いじわるな入力：めちゃくちゃ長い文字列、HTMLの要素を書き換えて本来想定しない値を設定する ブラウザを2つ立ち上げて、同じデータを同時に編集する URLを書き換えて他の人の情報が見れないか 何度もreloadしたりsu
褒めるチャンネルを作ったらポジティブなフィードバックが集まって来て嬉しくなった話 - 弥生開発者ブログ
Misoca開発メンバーの北村です。 先日Misocaの有志で岐阜県の金華山にハイキングに行きました。私は3歳の長男を連れて参加。 金華山は登山口からの標高差が300mほどで、子どもも楽しめる良い山でした。*1 これからの季節は天気が良ければ冠雪した御嶽山や南アルプスを眺めることができそうです。 さて、子ども連れの登山・ハイキングで避けたいのは、山で「疲れた」「怖かった」というネガティブなイメージが子どもの心に残ってしまうこと。継続的に山に親しんでもらうためには、その登山が良い思い出、成功体験として刻まれて欲しいものです。 そのために私が実践していることは、「褒める」ことです。 登山口が見えるようなところまで登ったら「あんなところから登ったんだよ、すごいね！」、下山したら山頂を振り返り「あんな高いところまで頑張って登ったね！えらいね！」と褒めます。おかげで、今のところはお山に行くことは長男
レガシーなフロントエンドコードを整理するためにどう立ち向かったか - Misoca開発者ブログ
2エントリ連続でこんにちは、@mugi_unoです。 名古屋には台湾ラーメンイタリアンという名物があるそうです。 富山県民の私には理解が追いつきませんでした。 フロントエンドでの金額計算処理 さて、Misocaは請求書作成サービスなので、金額計算処理が欠かせません。 フロントエンドも例外ではなく、消費税額や合計額を算出するロジックが存在します。 機能変更が必要になった!! 諸事情により、そのロジックに変更を加える必要が生じました。 長くプロダクトを支えてくれていた存在ですが、内容的にはいわゆるレガシーなコードで、たびたび開発者ミーティングでも課題として挙げられることがありました。 git log で確認してみると、該当コードに対しての機能的な変更は2015年の冬から行われていません。 何が問題だったのか？ DOM操作と計算ロジックの混在 Misocaでは、新しくコードを書く際はVueやRe
👋Farewell song - 弥生開発者ブログ
mzpです。こんにちは。 今回、Misocaを辞めて転職する決断をした。そのため、これがこのブログへの最後の投稿となる。なので、Misocaへの感謝を述べつつ退職の報告としたいと思う。 🏢出会い 新卒で自動車メーカーの系列会社に入社し社内SEをしていたが、やりたいこととのギャップを感じはじめたので転職活動をはじめた。 その中で、以前から知っていたMisoca(当時の社名はスタンドファーム)に話を聞きにいった。 自分が自社サービスに興味があったことと、Misocaも資金調達に成功し人を増やすタイミングだったことがうまくマッチし、入社を決めた。 こう書くとちゃんと活動したように見えるが、実際は退職を宣言したあと、何人かの知人とご飯を食べていたら話が進んでいたので運要素が大きい。 資金調達に成功してうんぬんは最近知った。 当時のメモには選んだ理由に以下のものが書かれている。 なぜスタンドファー
RubyKaigi2018 で現存する最古の Ruby をフロッピーディスクに入れて配布します - 弥生開発者ブログ
id:mizukmb です。こんにちは。 昨日紹介した 📖ステッカー帳 に引き続き、 RubyKaigi2018 でお配りするノベルティを紹介します。 来る RubyKaigi2018 にて、 Misoca ではノベルティとして Ruby 0.49 のソースコードが入ったフロッピーディスク を配ります。 こちらの紹介と、 Ruby 0.49 のビルド方法や実際に動かしてみた内容について書きたいと思います。 フロッピーディスク 💾 外観はこんな感じで、 RubyKaigi2018 仕様のジャケットと一緒にケースに入っています。ケースは自立するので飾ることができます。かっこ良いですね。 こちらのフロッピーディスクですが、実際に読み込むことができ、中には Ruby 0.49 のソースコードが入っています。 Ruby 0.49 はこちらで公開・配布されています。 ftp://ftp.ruby-
🔥カンバンを完了させるということ - 弥生開発者ブログ
こんにちは、mzpです。 Misoca Advent Calendar 2017 の13日目の記事を書きます。 🔖Misocaのカンバン Misocaでは、各プロジェクトごとに付箋が作られ、壁に貼っていた。台紙となっている模造紙のことを名古屋ではB紙と呼ぶので、「MisocaのB紙」と呼んでいた。 名古屋オフィス外で働いている人と情報共有が難しかったため今はTrelloに移行している。 🚀完了したプロジェクト 完了したプロジェクトは場所でまとめて管理していた。 Doneの杜と呼んでいた。最初は「いっぱい終わったなー」と満足して見ていたが、だんだんと片づけたい気持ちが増してきた。 ⛩出雲大社への奉納 ちょうどその時期にRubyWorld Conference 2017のために島根に行くことが決まっていたので、出雲大社に奉納できないかと思って調べてみた。 FAQを確認すると 古い御神札・御
特定のブランチをもとに本番同様の動作確認ができる「レビュー環境」の話 - 弥生開発者ブログ
こんにちは。tkykです。 みなさん、コードレビューしていますか？今日はMisocaのレビュープロセスで用いられている、とっても便利な「レビュー環境」について紹介します。 Misocaのレビュー体制とその課題 MisocaではPull Request（以下、PR）ベースの開発体制をとっており、必ず他のエンジニアによるPRのレビューを経てから、masterへマージすることになっています。 レビュー時に動作確認をするには、エンジニア各自がローカル環境にブランチをチェックアウトして行うのですが、時にはそれだけでは不都合なケースもあります。 非エンジニアにも動作確認をしてほしい 動作確認をするための条件を整えたい 最終的にはマージされないコードを一時的に追加したい 依存するライブラリのバージョンを変更したい RAILS_ENV=production でビルド・実行したい などなど このようなケース
心理的負担を抑えつつVue.jsを0.12→2.4にアップグレードした話 - 弥生開発者ブログ
こんにちは、@mugi_uno です。 RubyKaigi盛り上がりましたね〜！ そして広島は美味しいものがたくさんでした。次回の仙台も楽しみですね！ さて、みなさんはフロントエンドのフレームワークには何を利用していますか？ Misocaでは一部機能でReact/ReduxによるSPA構成を採用しています。 めろたん(@renyamizuno_)の書いた過去のエントリーにも登場していますね。 tech.misoca.jp しかし、Misocaで利用しているのはReactだけではありません。 jQuery React/ReduxはSPAなどでパワーを発揮しますが、逆に気軽に取り回しにくいため、ちょっとしたコンポーネントを作りたいケースなどでは、さくっと書けるjQueryを利用することもまだまだ多いです。 しかし、DOM操作が柔軟すぎるため影響範囲が読めなかったり、ビューと状態の管理が複雑にな
MisocaのCI構成まとめ - 弥生開発者ブログ
こんにちは。4月からMisocaにjoinしました、tkykです。京都市内からリモートで働いています。盆地特有のねっとりとした暑さをやり過ごしつつコードを書いている今日この頃です。 さて、今回はMisocaのCI（Continuous Integration）環境がどうなっているか、その全体像を紹介したいと思います。 そもそもCIの目的とは？ ソースコードの一部に対する変更が、アプリケーション全体の動作を壊してしまっていないか、常時チェックするのが目的です。 そのために何をしているか CI専用のサーバに、変更点を含むソースコード全体をチェックアウトして、依存ライブラリのインストールと必要な前処理を行い、すべてのテストを実行します。 すべてのテストがエラーなくpassしたことをもって、CIが通ったとしています。 Gitを使った開発フローとの統合 MisocaはGitHub上で開発を行なってい
Controllerのリファクタリング ~または私は如何にして肥大化していくControllerをやめてDHHによるControllerの書き方を愛するようになったか~ - 弥生開発者ブログ
こんにちは！ Misoca開発チームのめろたん(@renyamizuno_)です！ 最近LEGOランドが開園したので行きたいのですが、地味に遠いため行けてないマンです。 最近あった面白いことは、 スマホでスクショとか撮れないなぁと思って色々確認したら、 最近スクショとかカメラ撮れんなーと思ってストレージがいっぱいなのかなぁ と思って見たら 最大が25GBに対してアプリ1TBとかでクソ笑う pic.twitter.com/inymgYrToH— わかり亭めろたん。 (@renyamizuno_) 2017年4月7日 アプリとかキャッシュとかがスマホのストレージ容量をありえないくらい超越してたことです。 はい。 今回は最近ありえないほど大きくなってしまったControllerをいかにリファクタリングしたか*1というのをざっと書きたいと思います。 おおきくなるController どうしても大き
よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った - 弥生開発者ブログ
Misoca開発チームの黒曜(@kokuyouwind)です。 先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。 お題「みなさんRubocopになってもらって『直しました』といってください。『何を直したんですか？』と聞くので、直したところを答えてください」 須藤さん「直しました」「何を直したんですか？」「RSpecをTestUnitにしました」 #nagoyark03— 黒曜@技術書典2 か-13 (@kokuyouwind) 2017年2月11日 流しの技術フェローに教わったペアプロのコツ 先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。 今回はkakutaniさんから教わった内容のまとめと
及川卓也氏のプロダクトへの想いとプロダクトマネジメント - 弥生開発者ブログ
こんにちは、Kosukeです。:) IncrementsのQiitaプロダクトマネージャー及川卓也さんがMisocaへいらっしゃったので、インタビューさせて頂きました！ （左から共同創業者 松本、及川さん、代表 豊吉、Kosuke） 及川卓也氏のプロフィール 一般社団法人情報支援レスキュー隊 代表理事。東京出身。早稲田大学理工学部卒。 専門だった探査工学に必要だったことからコンピューターサイエンスを学ぶ。 卒業後は外資系コンピューター企業にて、研究開発業務に従事。米国マイクロソフトに派遣され、Windowsの開発を行う。その後もWindows関連のプロジェクトに関わっていたが、どうせWindowsの仕事をするのならと、マイクロソフト株式会社(当時)に転職。 マイクロソフトではWindowsの開発を行い、最終的には日本語版と韓国語版のWindowsの開発の統括を務める。 2006年にグーグル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
