くらしのマーケット開発ブログ

「くらしのマーケット」を運営する、みんなのマーケット株式会社のテックブログ。積極採用中です。

競技プログラミングのススメ

こんにちは、 @akira です。本年もよろしくお願いいたします。

2021 年のテックブログ一本目は、競技プログラミングの紹介記事になります。

サンプルコードは Go で記載しています。

競技プログラミングとは

出題されたお題をデータ構造とアルゴリズム(+数学 etc...)を駆使して解く競技です。

実際のコンテストでは制限時間内に難易度の違う問題が複数出題されるので、それらをいかに早く解くかを競います。

例えばこんな問題が出題されます。

自然数 n (1 <= n <= 1000)が与えられたとき、1からnまでの和を求める calcSum() を実装せよ

まず naive に brute force でこの問題のアルゴリズムを実装してみましょう。

brute force は、パスワードを一文字ずつ変えながらログインを試みる攻撃手法 brute force attack の名前などに使われており、「強引に何かを行う」といった意味をもつ単語です。

競技プログラミングにおいては、「総当りで計算する」といった意味合いがあります。

func calcSum(n int) int {
    rev := 0
    for i := 1; i <= n; i++ {
        rev += i
    }
    return rev
}

このとき、時間計算量は O(n) 、空間計算量は O(1) です。

時間計算量は、ざっくり言うと必要な手順の回数を指します。上記のアルゴリズムでは n 回ループが実行されるので、O(オーダー)記法で O(n) になります。

空間計算量は、ざっくり言うと必要なメモリの量を指します。上記のアルゴリズムでは、返り値の変数 rev 以外はメモリを使っていないとみなすと、O(1)(常に一定)と表せます。

この問題、時間計算量 O(1) で解くことができます。

問題は 1~n までの和を求めているので、初項 1、公差 1 の等差数列の和を求めればよいことになります。

初項 a、公差 d、項数 n、末項 l の等差数列における初項から第 n 項までの和 S は、以下の式で求められます。

S = n * (a + l) / 2 =  n / 2 * (2 * a + (n - 1) * d)

今回は a = 1, d = 1, n = n, l = n であるため、上記に代入すると

S = n / 2 * (2 * 1 + (n - 1) * 1) = n * (n + 1) / 2

この公式を利用することで空間計算量は O(1) 、今回のように n が大きくない(n <= 1000) 場合は、時間計算量 O(1) で計算することができます。

func calcSum(n int) int {
    return n * (n + 1) / 2
}

競技プログラミングの楽しさ

上記の問題だけでは少し物足りなかったかもしれません。

もっと本格的な問題を考えてみましょう。

ローマ数字は I, V, X, L, C, D, M (それぞれ 1, 5, 10, 50, 100, 500, 1000)を組み合わせて数を表す
通常は左から右に向かって大きい数から順に表すが、以下のケースは例外となる

・I は V(5), X(10) の前に書くことで IV(4), IX(9) を表せる
・X は L(50), C(100) の前に書くことで XL(40), XC(90) を表せる
・C は D(500), M(1000) の前に書くことで CD(400), CM(900) を表せる

自然数 num (1 <= num <= 3999) が与えられたとき、そのローマ数字を文字列で返す convertToRoman() を実装せよ

私は最近この問題を解いたのですが、最初の回答が以下です(ワントゥスリィ!)

var m map[int]string = nil

func convertToRoman(num int) string {
    m = make(map[int]string, 0)
    m[1] = "I"
    m[2] = "II"
    m[3] = "III"
    m[4] = "IV"
    m[5] = "V"
    m[6] = "VI"
    m[7] = "VII"
    m[8] = "VIII"
    m[9] = "IX"
    m[10] = "X"
    m[20] = "XX"
    m[30] = "XXX"
    m[40] = "XL"
    m[50] = "L"
    m[60] = "LX"
    m[70] = "LXX"
    m[80] = "LXXX"
    m[90] = "XC"
    m[100] = "C"
    m[200] = "CC"
    m[300] = "CCC"
    m[400] = "CD"
    m[500] = "D"
    m[600] = "DC"
    m[700] = "DCC"
    m[800] = "DCCC"
    m[900] = "CM"
    m[1000] = "M"

    rev := ""
    for num >= 1000 {
        q := num / 1000
        num %= 1000
        rev += strings.Repeat(m[1000], q)
    }
    num, rev = calc(rev, num, 100)
    num, rev = calc(rev, num, 10)
    _, rev = calc(rev, num, 1)
    return rev
}

func calc(rev string, num, d int) (int, string) {
    q := num / d
    num %= d
    rev += m[q * d]
    return num, rev
}

ゴリ押し感満載で、前半のローマ数字を打ち間違えたらそれだけで不正解となりそうなコードですね。実装も大変だった記憶があります。

ただ、上記のコードでも正解として通過はしました。

後ほど比較するためにざっくりで時間計算量を出すと、

  • num を 1000 以下にするのに for で記載してますが、1000 で modulo を取っているのでループは1回しか回らず
  • strings.Repeat() は O(log2(q)) とすると

最終的には O(log2(q)) でしょうか。

このコードをより改善しようと試みて書いたのが次のコードです。

var m map[int]string = nil

func convertToRoman(num int) string {
    m = make(map[int]string, 0)
    m[1] = "I"
    m[5] = "V"
    m[10] = "X"
    m[50] = "L"
    m[100] = "C"
    m[500] = "D"
    m[1000] = "M"

    rev := ""
    for num >= 1000 {
        q := num / 1000
        num %= 1000
        rev += strings.Repeat(m[1000], q)
    }
    num, rev = calc(rev, num, 100)
    num, rev = calc(rev, num, 10)
    _, rev = calc(rev, num, 1)
    return rev
}

func calc(rev string, num, d int) (int, string) {
    q := num / d
    num %= d

    if q == 9 || q == 4 {
        rev += m[d] + m[(q+1) * d]
    } else if 6 <= q && q <= 8 { // 8,7,6
        rev += m[5 * d] + strings.Repeat(m[d], q % 5)
    } else if 2 <= q && q <= 3 { // 3,2
        rev += strings.Repeat(m[d], q)
    } else if q == 5 || q == 1 {
        rev += m[q * d]
    }

    return num, rev
}

より短い行数で書けましたが、桁に 6,7,8 が登場する場合は strings.Repeat() も呼ばれるため、時間計算量は先程のものから悪化してしまっています。

どうにかならないものかと、他の方が提出した回答を眺めていると、次のような考え方で実装されていて驚愕でした(別の言語だったため、Go で再実装しています)。

今回の問題の numnum <= 3999 の制約があります。つまり千の位はたかだか 3 までということです。そこから次のような考え方が生まれたのでしょう。

func convertToRoman(num int) string {
    M := []string{"", "M", "MM", "MMM"}
    C := []string{"", "C", "CC", "CCC", "CD", "D", "DC", "DCC", "DCCC", "CM"}
    X := []string{"", "X", "XX", "XXX", "XL", "L", "LX", "LXX", "LXXX", "XC"}
    I := []string{"", "I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX"}
    return M[num/1000] + C[(num%1000)/100] + X[(num%100)/10] + I[num%10]
}

各桁で取りうる値を全て slice に保持しておいて、後はその値の文字列を連結しているだけの非常にエレガントなコードです。

時間計算量は、slice (array) は memory access のため O(1) 、 num <= 3999 であることと定数であれば O(1) としてみなせるため O(1 * 4) = O(1) になります。

こんなコードを最初にかけたら非常にスマートで楽しいに違いない、と苦しみながら解いた私は感じます。

これが競技プログラミングの楽しさではないでしょうか。

オススメの競技プログラミングサイト

以下のサイトが個人的におすすめです。無料で問題を沢山解けます。

上記以外にも、ゲーム感覚で挑戦できるCodingameなど、たくさんあります。

自分に合ったプラットフォームを選択するとより競技プログラミングが楽しくなるかなと思います。

終わりに

競技プログラミングに取り組むことで時間計算量や空間計算量を意識するようになり、実務でコードを書く際にも効率的にリソースを使えるようになります。

上記のような一見大変そうな問題をスマートに解くことにも楽しさはあるので、まだご経験のない方はこれから挑戦してみてはいかがでしょうか。

それでは!

2020年のQAチームを振り返る

こんにちは、QAエンジニアのざきです。 イルミネーションにワクワクする時期ですが、今年は大人しくStay Homeを続けています。

f:id:curama-tech:20201224104953j:plain
数年前の大根やぐらライトアップ〜宮崎市田野町〜

2020年も年末を控え、来年の行動目標やチーム方針を検討する中で、そう言えば今年のQAチームはどうだったのか、簡単に振り返りたいと思います。

▼QAチーム体制

2020年1月よりQAチームとして独立したチーム体制になりました。当時のメンバーは私を含めて2名。 (昨年時点では複数ある開発チームの中の1チームにQA2名が所属していました)
11月に2名がジョインし、以降は4名体制になりました。※フルタイム勤務のメンバーだと3名体制。

▼仕事の内容

各所からの依頼を受けて大まかに以下の作業を行っています。

【開発チーム関連】

  • テスト計画の作成

  • テスト設計・レビュー

  • テスト実施(結合テスト[IT]、総合テスト[ST])

  • リリース判定

【その他】

  • 不具合の報告 >調査・切り分け >解決 or 修正依頼

  • 仕様問い合わせ >回答

  • データ修正依頼 >担当チームへの仲介 >実行結果の確認

▼今年変わったこと

フルリモート化

会社として、チームとして、大きく変わった点としては「働き方」です。2020年12月時点でQAメンバーは全員が「ジョブ型コース(完全リモートワーク)」を選択しています。
コミュニケーションツールはSlack、Zoomがメインとなり、直接顔を見て話す機会は無くなりましたが仕事はこなせています。

また、新メンバーのオンボーディングも、フルリモート対応でありながら成功しています。
気を付けた点として、分からないことや説明しづらいものは、即座にZoomを繋げて対面的な説明を行った事です。 もちろん、内容によりますがテキストベースで解決出来るものはSlackで返答を行い解決します。

しかし、モバイル端末の操作・挙動やブラウザで発生している事象についてとなると、テキストベースで話を進める事は非効率(認識がずれていると後々手戻り・やり直しになる)になるため、即解決!をモットーに即Zoom!で対応しました。 後のお話で、オンラインでも顔を見て話をしてもらえると安心感が高まり、状況を落ち着いて整理・説明できた、と嬉しいコメントをいただきました。

タスク・スケジュールの可視化

昨年は開発チームのメンバーとして所属していたため、タスク一覧や管理シートはなく、個人のタスクは日々のデイリーで報告するのみで、パッと見てアサイン状況や進捗度合いを確認する術はなく、都度聞いて確認するというスタイルでした。

独立したチームとなりメンバーの状況が分からない(相手から見れば私の状況が分からない)ことは、思った以上に影響があり、例えばQA宛に依頼されたタスクを互いに対応しているなど、情報共有と業務連携で改善が必要だと気付きました。

即座に、Googleスプレッドシートを利用して、タスクのアサイン・対応状況を一覧化し、先々のリリース予定も把握できるようQAカレンダーを作成・運用しました。これにより、重複対応が発生することなく、期限と進捗を見て必要時にはヘルプに入るなど、互いの状況が把握しやすく連携も取りやすい状態へ進化する事ができました。
また、このシートは誰でも閲覧可能なため、QAのリソースやスケジュールの見通しを全体的に公開できる良いキッカケにもなりました。

▼今年の課題と来年への思い

QAチーム発足から1年を前に、率直な課題として以下が挙げられます。

1.経験値・ナレッジの属人化

開発チームの数に対してQAメンバーの人数が少ないため、QAはいくつかのプロジェクトを兼任しなければなりません。そうなるとどうしても、「そのメンバーしか把握していない仕様やテスト作業のナレッジ」が発生します。細かな粒度でアップデートされる情報類についても同じ事が言えます。

新メンバーも含め、チームメンバー全員が一定の水準でテスト作業を行えないとQA(品質保証)にはなりません。限られたリソース・定められた期限の中でどの様にチームとして解決すべきか皆で一緒に取り組みたいと思っています。

2.テスト自動化

これは主に、リグレッションテストの効率化を図りたいと考えています。デプロイ前に実行する自動テスト(E2E)は開発エンジニアにて作成されていますが、QAの為のテスト自動化は実現できていません。リリースの大小を問わず、毎回行う繰り返しテストを手作業で確認するのは確実性はありますが、効率化できるポイントでもあると思います。どんなタイミングでも遅延することなくスムーズなリリースを提供するためにも腹を決めてやるしかないのです。

とは言ったものの、、テストシナリオの策定、コードの記述、動作確認・メンテナンスなど、テスト自動化は実現したから終わるものではなく、半永久的に付き合っていく事になります。と同時に、実行結果の取得についても、単純にエラーが無かったなどの判断ではなく、デザインやボタンの状態も確認する必要があるなど、考える材料が多くなかなか踏み出せていませんが、メンバーも徐々に増えているので来年こそは取り組もうと考えています。(皆様お力添えくださいませ)

3.ボトルネックの汚名返上

前項1.で取り上げたように、QAはいくつかのプロジェクトを兼任しているため、リリースタイミングが重複すると進捗度合いや作業量によってリソース不足に陥ります。そういう時は開発チームにヘルプいただく事になりますが、これにより、ヘルプしてもらう方の本来の業務をストップさせてしまいます。と同時に、それでもテストが間に合わずリリースが遅延するとなればQAがリリースのボトルネックになってしまいます。

2020年(2名体制の頃)の苦い思いを繰り返さないよう、2021年は増強されたチームで汚名返上をします。まずはしっかりとしたテスト計画を立てること、リリース時期が重複する際のリソース配分・割当をカレンダー管理した上で、どうしても調整が必要な時にはチーム内で協議した結果を開発チームへ共有し全員で解決策を見出す、これらを徹底します。爆速で進むくらマの進化を速やかにユーザーへ届けるためにQAも進化し続けます。

おわりに

チームビルディングについては手探りな領域が多いものの、チーム内外問わず、全社的に「やってみよう!」という前向きな雰囲気なので、まだまだやれる事はある!と感じています。何をするのか・しないのか、ではなく「何が出来るかな」を最初に考えながら来年も様々なミッションを全員でクリアしていきます。

来年もQAに関する情報を発信していくので、どうぞお楽しみに!

フルリモートワークでのオンボーディング施策

こんにちは。みんなのマーケットでCTOをしている戸澤です。

当社ではコロナ以前からリモートワークで働ける状態でした。 ただどちらかというと東京もしくは宮崎のオフィスで働くのが主流で、利用するメンバーはそこまでいませんでした。

3月下旬のリモートワークを会社全体で初めるタイミングでは、うまく仕事が回るのだろうか、という不安がありましたが、試行錯誤していく中でリモート環境下でも開発を回していく体制や仕組みを整えられてきました。 その結果、オフィスへの出社が不要なフルリモートでの採用も開始し、募集も日本全国、全世界に拡大しました。 その成果もあり、従来のオフィス出社の前提だと採用できなかったであろう鹿児島や韓国に住んでいるメンバーも入社しています。

今回はフルリモート環境下で入社したメンバーのオンボーディングをどう進めているかについて振り返っていきます。 フルリモートワーク以前から在籍しているメンバーはメンバー間の関係性や業務の基礎理解がすでに出来ている状態ですが、新しく入社するメンバーはそれがない状態で、直接会わずにリモートで進めるのは初めての試みでした。

昨日(2020/12/17)の東京の感染者は過去最多822人となりましたが、フルリモートでの転職を考えている方が働くに際しての安心できる材料として、また、フルリモートに悩んでいる組織運営者の助けとなれれば幸いです。

新卒入社メンバーに行ったこと

他メンバーが隣に座っている状態を再現する

新卒メンバーは4月1日の入社日からリモートでの研修、OJTとなりました。 まだ社会人としての働き方に慣れてない状態、業務の基礎がつかめてない状態で自宅にひとりになるフルリモートは懸念がありました。

研修は例年通り新卒向けのオンボーディング用のドキュメントに沿って進めますがリモートの状況だと、わからないところで手が止まってしまったり、新卒メンバーの会話の中で理解を深めることが難しい状況でした。

その対策として、新卒メンバーと指導メンバーでZoomを繋ぎっぱなしにしました。このZoomはいつもはミュートにしておきますが、ミュートを解除して話しかけると誰かが反応できる状態になります。これにより、新卒メンバー同士での解決や、新卒メンバーの疑問をすぐに指導メンバーに確認し解決することや、相談しやすい状況を作ることができました。

特に新卒メンバーのオンボーディングでありがちな、会話の中で確認を取っていくためテキストで表現が難しい内容や、遠慮して聞きづらいという状況を回避できました。 この施策は4月から8月まで行い、Zoom以外のビデオ通話サービスも試しましたが、ミーティングを開きっぱなしにしやすいことや、通話の品質や安定性でZoomが一番使いやすかったです。

中途入社メンバーに行ったこと

他メンバーが隣に座っている状態を再現する

中途メンバーは社会人として仕事を進められるためZoom繋ぎっぱなし施策は行っていませんが、次に施策を行っています。

  • ペアプログラミング
  • Slackにチームスレッドをつくり気軽に聞けるようにすること
  • Slackのテキストだと伝えづらいものはカジュアルにZoomやGoogle Meetを使い会話して解決すること
  • チューター制度
  • デイリーMTGの中で困っていることも話してもらい、早くに他メンバーがサポートに入れる状態を作ること

また、業務やスキル面以外でお互いにどんな人と働くか知りたいという意見もリモートワークを進めていく中で上がってきました。その方法として、全チームではありませんが、Zoomランチや、海外出身のメンバーも多いので出身の国について語ってもらう疑似海外旅行Zoomなどを開催することもあります。

内容の抜け漏れをなくす、検索できるようにする

4月以降、ドキュメントのカバレッジを上げていく中で、オンボーディング用のドキュメントの充実と更新を進めています。

オンボーディング用のドキュメントができる以前は、会話の中で教えていくことが多く、質問されないと伝え漏れること、時間がかかること、伝え間違えることがありました。そのため、開発していく中でのミスや認識違いによる手戻りが発生したほか、特にフルリモート下で組織を拡大していくに当たって、そのスケーラビリティが課題となっていました。

その対策として、開発フローやルール、システム、プロダクトの理解ができるオンボーディング用のドキュメントをエンジニア、デザイナー、QAの職種別に作成しました。作成後も入社のタイミングで不足している内容や変更になっている部分のアップデートも継続的に行っています。

その成果として、1回の入社人数が増えても対応出来ています。 また、部署配属から概ね1週間ほどで業務に取り掛かることができるようになり、事前の理解度が高まっていることや自分で調べることができる状態にもなっているため、進捗が途中で止まることが少なくなりました。

最後に

転職、就職しようとしている方は入社先で活躍できるか、心配されると思います。

その心配を解消でき早く活躍、成果をあげられるよう、これからもオンボーディングのハードルを下げ、新しいメンバーが業務やルールを早く理解できるように整備を続けていきたいと思います。

Work From Home #1

こんにちは、決済チームでバックエンドエンジニアをしております、 @akira です。

今回は、今年 3 月からリモートワークを開始した @akira が現在、

  • どのような環境で
  • どのように働いているか

をまとめた記事になります。

Work From Home は広義の意味でリモートワークと同義であり、以下では WFH と略称で記載しています。

Index

職場環境など

私は 2019 年 9 月にみんマに入社しており、前職では最大で週一回 WFH しているような状況でした。

弊社はフルフレックスのため、休憩一時間を除いて毎日平均 8 時間働ければ出勤・退勤のタイミングは問われません。

作業環境は、オフィスにあった Desktop(Ubuntu)を自宅に搬送し、ローカルで開発しています。

開発メンバーの中には、EC2 上に開発環境を構築している方もいます。

自宅のデスク

今のデスクは次のような状態です。

@akira&#x27;s desk
普段はもので溢れかえっているデスク

上記アイテムは今年 3 月に入ってから買い揃えたのではなく、キーボード以外は事前に揃えていたものでした。1
それぞれの選択理由を以下に記載します。

机は前職の時にダイニングテーブルを購入していました。
子供の頃、学習机だとどこか違和感を感じ、リビングのダイニングテーブルではそれらの違和感がなく、恐ろしく作業が捗った経験があったことがきっかけです。

この違和感を深堀りしていくと「机の高さが合っていなかったのでは」との結論に達し、高さ 70cm のテーブルを調べていった結果、ダイニングテーブルにたどり着きました。Amazon の履歴が 1 年ほどしか保存されていないので詳細は失念してしまいましたが、おそらく価格は 5 万円前後です。

椅子

椅子は DXRACER の Racing モデルの赤で、オンラインゲーム用に 3~4 万円で購入しました。
3 年以上使っていますが、WFH でずっと座って仕事をするならばコスパはとてもよいと思います。

モニター

モニターは ASUS 27 インチのもので、かなり昔に 2~3 万円で買ったので今はおそらく廃盤になっています。
27 インチ程度あれば、作業をする上でおそらく困らない気がします。もっと大きな画面で作業すれば、また意見が変わってくるかもしれないです。

モニター台

モニター台は Amazon で数千円で購入したもので、上記の写真だとわかりづらいですが、モニター台直下にタコ足を配置するのが目的でした。

タコ足

タコ足も Amazon で 2~3 千円で購入したものです。
6 個口ですが、正直 8 個口くらいあっても良かった気もしています。

キーボード

キーボードは Magic Keyboard の US 配列です。以前は Bluetooth 対応の数千円の Mac 配列のものを使っていたのですが、TX(Typing Experience)が良くなかったので、少し前に Keychron K2 Gateron Brown Switch を購入して 1~2 ヶ月程使っていました。

Keychron K2 は Mac 配列の(Win 配列にも変更可能な)キーボードで、Gateron Brown Switch は高級感のあるような打ち心地で素晴らしかったです。

一方で、次第に私は

  • キーの”遊び”が少なく
  • 最低限の力で type できる
  • type sound は(自分自身が不快に感じなければ)あってもなくてもよい

キーボードが好みだと気づき、各種キーボードのスペックを 4 時間にらめっこした結果、最終的に Magic Keyboard に落ち着きました。

前職でも Magic Keyboard を使っていたため、その経験も大きく寄与しているかもしれません。

マウス

以前 PC で FPS(First Person Shooting)をしており、その際に RAZER DEATHADDER ELITE を約 1 万円で購入しました。

それよりも前は bluetooth のマウスを使っていたのですが、電池を格納しているためか、ちょっとしたカーソル移動も重く感じました。
その結果、有線のマウスに落ち着きました。

Laptop

Laptop は会社支給の Macbook Pro です。主に通話する際に使っています。
また、サブモニターとしても使っています。

Desktop

Desktop は会社支給の THIRDWAVE(OEM)に Ubuntu をインストールして使っています。
上記写真の右下に、床に直置きして使っています。

出勤から退勤まで

概ね次のようなスケジュール感で仕事しています。

  • 10:00 ~ 11:00 出勤
    • メールを見たり、ルーティン業務をこなしたり、Slack を眺めます
  • 12:00 チーム MTG
    • Zoom でチームミーティングを行います
      • 時間は特に決めていません
      • 今日やることと共有事項の二点を順番に話していきます
  • 13:00 ~ 15:00 のどこか 1h ランチ
    • 最近は(部署関係なく)社内メンバーを相手に、コーチングの練習を 1on1 で 30 分実施しています
      • コーチングを実施する側として、トレーニングメンバーに選出頂いたことがきっかけです
      • コミュニケーションの絶対量を稼げるため、非常にプラスになっています
  • 19:00 ~ 20:00 退勤
    • 出勤時間から逆算して、大体の目安で退勤します

上記よりも細かい粒度ですと

  • コミュニケーションは基本的に Slack のテキストベース、話したほうが早い内容は Slack call、さらに顔が見えたほうが良い内容は Zoom で行っています
    • このようなやり方で特に問題はないと個人的には思っています
  • 必要ならば、10 行以上の文章を Slack や GitHub 上で書くこともあります
    • 何かを共有したり教えたりするときに、背景も含めて全部説明すると大ボリュームになることがあります
      • 口頭でのコミュニケーションをそのまま文字に起こすと、これくらいの絶対量になるのかもしれません
  • 決済チームではほぼ雑談をしないため、ちょっとしたスキを見つけて雑談するようにしています
    • 仕事の話だけでは相手が今どのような状況(感情、体調 etc...)なのかが把握しずらいため、効果てきめんです

現在の WFH の課題

以下四点あると考えています。

  • テキストのミスコミュニケーション
  • 運動不足
  • 長時間座りつづけることによる身体的ダメージ
  • コミュニケーションのサイロ化

テキストでやりとりをしていると、同じ言葉でも context の違いによって意味が異なるケースがあります。
上述の「背景も含めて全部説明する」ことでもカバーできますが、口頭で会話したほうが正確で早いかもしれません。

運動不足については、リングフィットアドベンチャー を買おうか迷っているのですが、筋トレやランニングなどでも充分な気がしており、目下検討中です。

長時間座り続けることについては、スタンディングデスクの購入も検討しましたが、座ることのリスクをきちんと精査できていないため、一旦ストップしています。本当にまずいとわかった段階で購入予定です。

コミュニケーションのサイロ化については、オフィスで仕事をしていたときと比べ、部署の垣根を超えて話す機会が減ったと考えています。逆に今は Slack のテキストベースで仕事をしているので、業務に関係のない話を振りにくい、振られにくいのではないか、とも考えています。

実際に、色々なメンバーと話をしていても、自チーム以外のメンバーと話す機会がないので話したい、という声をよく聞くようになりました。

確かに出社していたときは、退勤後に話しながら駅まで歩いたりする空間などがありました。そういった小さな空間がアナログからデジタルに移行した際に淘汰されてしまったように感じています。

そこで(まだ 2 回しか開催できていませんが)社内で「すべらない話」を主催し、部署関係なくコミュニケーションできる機会を意図的に作っています。結果はノーコメントですが、目的は達成できているように思います。

WFH Tips

初歩的な内容なのであまり参考にはならないかもしれませんが、WFH のちょっとしたコツを紹介します。

  • Typing Speed を鍛える
  • Reading Speed を鍛える
  • 小休憩する
  • 音楽は流さない
  • 室内の CO2 濃度に注意する
  • 糖分補給

WFH ではよりテキストベースのコミュニケーションとなる旨を上述しましたが、テキストの input 方法は現在は typing が主流かと思います(将来は音声認識が主流となっているかもしれませんね)。 そのため、Typing Speed がテキストベースのコミュニケーションの Output Speed に直結します。 typing が遅いと自覚されている方は練習すると良いかもしれません。

私は大学時代にある小説にハマり、カフェに入って 6 時間かけて全部読み切るなど、活字を読むことに抵抗がありませんでした。最近は英語の文章や記事、論文を呼んでいて、英語の文章に対する抵抗感もほぼなくなりつつあります。このような経験が WFH におけるテキストのコミュニケーションスピードの向上に一役買っているように思います。

口頭でのコミュニケーションは synchronous であり、基本的にその場で理解する必要があるため、スピード自体にあまり差はないように思います(早口同士のコミュニケーションのスピードは早いかもしれませんが、業務において相手を選ぶことはできないでしょう)。

一方で、テキストでのコミュニケーションは asynchronous 2であり、その場で理解する必要がありません。そのため、スピード自体に差が出ます。この Reading Speed を上げていくことで、仕事全体をスピードアップできるはずです。

WFH によって、Slack のメンション以外は自分の作業を遮る事象は減ったように思います。そのため、1~3 時間ノンストップで作業していることもしばしばありました。

きりのいいところまで進めてしまったほうがもちろんよいのですが、全てを一度に片付けようとせず、必要に応じて目線を PC からそらして窓を見たりするなどの、ほんのちょっとの休憩は意識して取り入れるようにしています。

また、音楽を聞きながら仕事をされる方もいると思うのですが、個人的には必須ではなく、必要だと感じたときに音楽を流していました。

私は映画の soundtrack を流すことが多く、一人で戦争をしている状態が多かったのですが、これをやめました。

音楽によって作業効率が上がっている場合はよいのですが、逆効果に感じる場面もありました。よくよく考えてみれば、音楽を聞くことで生産性がプラスになる時間と、マイナスになる時間があってもおかしくはなく、効果は一様でないと今では考えています。

(私はやっていないのですが、)マリオカートの最終ラップで流れる BGM を流すことで作業の効率が高まる、などの説もあるようです。しかし、この手法は短時間のみ効果を発揮するのではないかと考察しています。

たしかにマリオの立場になって考えてみたら、最終ラップの BGM がゴールしてさらに 20 周した後でようやく止まると事前に知っていたら、その音楽が流れても全く焦りませんし、呑気にコースアウトしながら走っているかもしれませんね。

音楽を聞いている方で、作業効率が安定しない場合は、仕事中の音楽を完全にシャットアウトしてみるとよいかもしれません。

室内の CO2 濃度は、締め切った部屋で仕事をしていると高くなりがちです。CO2 濃度が低いほどパフォーマンスは上がるようですので、気がついたときに外の空気を吸うなどをしています。

最後に糖分ですが、糖分不足ですとやはり頭が回らないこともあります。その場合は積極的に糖分を補給しています。最近は HARIBO ゴールドベア にハマっています。

終わりに

上記を振り返ってみると、自宅であってもオフィスで仕事していても、仕事そのものには変わりがないという点はあらためて自覚しました。 工夫している点も、オフィスであっても実行できるものが多いですね。

ただし、WFH 特有の課題はあるため、今後はこちらを解決していって、より快適に仕事できるようにしていきます。

それでは次のブログでお会いしましょう!


  1. 業務外では主に Macbook Pro (2015 JIS, 2020 US)を使っていて、以前は Desktop(Ubuntu)も使っていました

  2. 日本語の文章内でも英語を使うことで英語の output をしているのですが、いつかみんマのルー大柴と呼ばれるその日まで続けていきます

コードをいじらずにPythonアプリケーションのメモリリークを検証する方法

こんにちは、バックエンドエンジニア・SREのカーキです。 最近くらしのマーケットのシステムで一部の Python アプリケーションにあったメモリリークを検証した時に学んだ検証方法について書きたいと思います。

メモリリークとは?

メモリリークはプログラムが確保したメモリを使用後に解放されず、プログラムのメモリ使用率がどんどん上がり続ける現象です。メモリリークがあると該当のプログラムがシステムのすべてのメモリを使い切って、システムがクラッシュする可能性があるので少し面倒なバグです。

リークの再現

弊社では現在Python 3.5.0を使っていますが、便宜のため以下のようにPython2系のdel関数の落とし穴を使ってメモリリークを再現します。

import time

class MyLeakyObject(object):
    def __init__(self, parent=None):
        self.parent = parent
        self.children = []
        self.value = 'x' * 100000

    def __del__(self):
        print("deleting")

def main():
    for i in range(2000):
        a = MyLeakyObject()
        a.children.append(MyLeakyObject(parent=a))
        time.sleep(3)

if __name__ == "__main__":
    main()

Python 3.4以降は上記__del__関数の落とし穴が解消されてるみたいです。

Python 2系でメモリリークを起こさないようにするには__del__関数使わない、または他のオブジェクトのレファレンスを持つ時にweakrefモジュールを使うのがおすすめです。

コードをいじらずにメモリリークを検証する方法

アプリケーションのコードにメモリプロファイラを入れて検証することが難しいケースもあると思って (例えばプロダクションでしか再現しないケースなど)、コードをいじらずにメモリリークの検証方法を調べたところ Pyrasiteという素晴らしいライブラリーを見つけました。Pyrasiteを使うと動いてるPythonのプロセスにコードを注入することができるので、Pyrasite + Pythonの好きなメモリプロファイラの組み合わせで簡単にメモリリークの検証ができます。

では、早速先程メモリリークを再現したコードで検証したいと思います。

1. Gdbをインストールする

Gdbunix系のシステムのデバッガーです。PyrasiteがGdbに依存してるのでインストールが必要です。インストール方法はOSによって違いますが、少し調べたら簡単にできるので割愛します。

2. Pyrasiteと好きなメモリプロファイラをインストールする

メモリ検証のツールとして今回Objgraphという便利なライブラリーを使います。

$ pip install pyrasite objgraph

3. Pyrasite shellを使ってプロファイラのコードを注入して検証する

まず、検証したいPythonプロセスのpidを調べます (以下の leak.py は上記のメモリリーク再現用のコードと同様のものです)

$ ps aux | grep leak.py
ec2-user 32497  0.0  0.0 132752  6224 pts/0    S+   04:46   0:00 /home/ec2-user/.pyenv/versions/2.7.10/bin/python leak.py
ec2-user 32541  0.0  0.0 119392   984 pts/4    S+   04:46   0:00 grep --color=auto leak.py

そして、pidを使ってpyrasiteのシェルに入ってプロファイラのコードを注入します。 今回はpyrasiteのシェルの中でobjgraphを使ってメモリリークの検証したいと思います。

$ pyrasite-shell 32497
Pyrasite Shell 2.0
Connected to '/home/ec2-user/.pyenv/versions/2.7.10/bin/python leak.py'
Python 2.7.10 (default, Nov 30 2020, 02:13:01)
[GCC 7.3.1 20180712 (Red Hat 7.3.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(DistantInteractiveConsole)

>>> import objgraph
>>> objgraph.show_growth()
function                       1492     +1492
wrapper_descriptor             1050     +1050
builtin_function_or_method      724      +724
method_descriptor               590      +590
dict                            587      +587
tuple                           524      +524
weakref                         496      +496
list                            271      +271
getset_descriptor               222      +222
type                            214      +214

この段階でまだメモリリークしてることがはっきり見えませんが、数秒後にまた objgraph.show_growth()を実行してみると以下のような結果になります:

>>> objgraph.show_growth()
MyLeakyObject       16        +2
list               275        +2
dict               594        +2

メモリリークを再現したMyLeakyObjectクラスのオブジェクトがgcされずに増えてることがわかるかと思います。数秒後にまたチェックすると同じく増え続けます。

>>> objgraph.show_growth()
MyLeakyObject       18        +2
list               277        +2
dict               596        +2

....数秒後

>>> objgraph.show_growth()
MyLeakyObject       20        +2
list               279        +2
dict               598        +2

....数秒後

>>> objgraph.show_growth()
MyLeakyObject       24        +4
list               283        +4
dict               602        +4

これで明らかにMyLeakyObjectにどこかメモリリーク発生してることがわかるかと思います。

それでは、メモリリークを直してみましょう。__del__関数の落とし穴によってリークしていたので、__del__関数を削除するだけで直るはずです。

import time

class MyLeakyObject(object):
    def __init__(self, parent=None):
        self.parent = parent
        self.children = []
        self.value = 'x' * 100000 

    #def __del__(self):
    #    print("deleting")

def main():
    for i in range(2000):
        a = MyLeakyObject()
        a.children.append(MyLeakyObject(parent=a))
        time.sleep(3)

if __name__ == "__main__":
    main()

修正後に同じくpyrasite + objgraph で検証してみた結果は以下の通りです:

>>> import objgraph
>>> objgraph.show_growth()
function                       1491     +1491
wrapper_descriptor             1050     +1050
builtin_function_or_method      724      +724
method_descriptor               590      +590
dict                            577      +577
tuple                           524      +524
weakref                         496      +496
list                            261      +261
getset_descriptor               222      +222
type                            214      +214

>>> objgraph.show_growth()
wrapper_descriptor     1062       +12
getset_descriptor       226        +4
member_descriptor       214        +3
weakref                 499        +3
dict                    580        +3
method_descriptor       591        +1

>>> objgraph.show_growth()
>>> objgraph.show_growth()
>>> objgraph.show_growth()
>>> objgraph.show_growth()
>>> objgraph.show_growth()

ご覧の通り、objgraph.show_growth() を何回打ってもMyLeakyObject が上の方に上がって来なくなったことがわかるかと思います!

以上、コードをいじらずにPythonアプリケーションのメモリリークを検証する方法の紹介でした。 Pyrasiteobjgraph を使ってみて個人的にすごく便利だと思ったので、みなさんもぜひ機会があれば使ってみてください!