mizzsugar’s blog

日々感じていることや学んだことを書きます。エンジニアリング以外にも書くかもしれません。

PyCon APAC 2023参加ログ

4年ぶりに現地参加しました！　

2023-apac.pycon.jp

1日目と2日目に参加しました。1日目は夕方からの参加でしたが、2日目は1日中いました。 久しぶりにお会いできた人、はじめましての人、よく会う人とお話して大変元気をもらいました！

1日目

会場についたのが夕方だったので、最後のトークだけ聞きました。その後、PyCampとPyLadiesの合同懇親会にお邪魔しました。

ModuleNotFoundErrorの傾向と対策:仕組みから学ぶImport

モジュール・パッケージの仕組みとModuleNotFoundErrorの対策についてでした。モジュールの話は初心者でもよくみるエラーだけれども、掘ればなかなか底が見えないでしょうから、15分にわかりやすくまとめていて関心しました。

特に P27のModuleNotFoundErrorのよくある原因とその対策の表は、重宝しそうです。ModuleNotFoundErrorに出くわすたびに見返したくなる良いページでした。 よくある原因5「同名のパッケージが存在する」は、命名規則をちゃんと決めてなくてかぶっちゃったとか、命名よく考えないで開発し続けたらこうなったとか根深そうなのでそこらへんの対策も考えないとなと思いました。

speakerdeck.com

PyCampとPyLadiesの合同懇親会

総勢29名の参加でした！　沼津のPyCampでTAしたので滑り込めました。 他の地域のはじめましての方や久々の方とワイワイできて楽しかったです！　料理もビールも美味しかったです！

pyconjp.connpass.com

2日目

怒号の久しぶりに会う人ラッシュでした。廊下、お菓子コーナー、After Partyに感謝！ After Partyはじめましてラッシュでもありました。

Let's implement useless Python objects

「Pythonで使えないオブジェクトを作ろう！ 使えないオブジェクト自体は使えないけど、使えないオブジェクトを作る過程はPythonを理解するのに役に立つよ」という趣旨でした。 力強いトークと白熱した質疑応答で臨場感のあるオフラインカンファレンスらしい一時を過ごしました。

speakerdeck.com

Pythonアプリケーションのオブザーバビリティ強化

前半はObservabilityとは？という話、後半はOpenTelemetryとPython用のツール「opentelemetry-instrument」の紹介でした。

OpenTelemetryとは、トレース、メトリック、ログなどのテレメトリーデータの収集・管理をするツールやライブラリを開発するオープンソースのプロジェクトです。監視系ツールのSaaSやAWSなどのマネージドツールの違いは、OpenTelemetryは計装方法やログの標準仕様を策定しているところです。共通の方法・フォーマットなのでダッシュボードツールなどのプラットフォームを容易に切り替えられるそうです。 その中でも、容易に使えるのがopentelemetry-instrumentです。セッションの中ではflask製のAPIに対してトレーシングしていましたが、もとのコードを編集することなく収集できるのは手軽で良いなと思いました。 また、JavaやRubyなど他の言語でもOpenTelemetryの似たようなツールがあるのでPython以外でも役に立つ内容でした。

ご当地グルメマップを作ろう

静岡のPythonコミュニティの中心的存在、佐野さんのトークです。 PyCampのテキストを終えた方の次のステップとして、PyCampで学んだスクレイピングを使ってご当地グルメマップを作ろうという内容でした。 この手のチュートリアルは全体像を踏まえずともテキスト追えば動くものを作れてしまうので（良くも悪くも）、「データの流れを整理してからコードを書こう」という主張は次のステップとしてとても良いメッセージだなと思いました。

speakerdeck.com

After Party

オリジナルビール美味しかったです！　予想以上に本格的なクラフトビールで驚きました...！　販売してほしいです。

はじめましての方や久しぶりに会った方などいろんな方とお話できて楽しかったです。話に夢中であんまりご飯食べれなかったけれども、ビール2杯飲めたので満足です。 いろんなテーマで話して、覚えているだけでもこんな感じでした。

  • RとPythonの比較の話
  • Streamlit最近人気ですねという話
  • 機械学習系のPoC作るにはStreamlitかDjangoかAWSやAzureなどのマネージドツールに全のせか
  • 本を書いた人の体験談
  • オフショアの話

などなど..

After Partyのあとは静岡組で2次会しました（写真忘れた）。これも楽しかったです！

締め

総じて楽しかったです！　移動や酒で疲れはありましたが、PyConハイで乗り切って元気に帰宅できました！ 最近は仕事がマネジメント寄りなのでコード書いてなくて、前日まで「久々の人と会うの恥ずかしいな...」とか思っていたのですが皆さん暖かくて前日までの不安など、この締めを書くまで忘れていました笑 わかりやすいトークが多かったので話についていけて安心しました（でも引き続きキャッチアップは怠らず）　あと、今の仕事ではコード書かないけど世の中に対する視野は広がった（良くも悪くも）のかなと思えた一面もありました。

来年も笑顔で会えるよう、気を改めて無理ない程度にアグレッシブに技術を楽しもうと思いました。

「単体テストの考え方/使い方」を読んで

この本の概要

ソフトウェアの品質改善とプロジェクトの成長のための単体テストの戦略を解説しています。 良い単体テストとはなにかから、リファクタリング戦略・モック戦略、単体テストと結合テストの違いまでテストの考え方について幅広く扱っています。

https://www.amazon.co.jp/dp/4839981728

おすすめしたい人

  • テストコードを書いたことがあり、テストコードでどこまで書くか・どのプロダクションコードに対してどのようなテストコードでテストすべきか方針に悩んでいる人。

感想

単体テストの話だけでなく、プロダクションコードの設計についても触れられていて、包括的にコードの品質改善のことを考えられてよかったです。 モックや単体テスト・結合テストの違いなど、普段から使っているけれどもいざ自分の考えをまとめようとするととうまく整理できていないところについて 学術的な背景にも触れて書かれていました。自分の経験を整理する一助となりました。

特に学びになったところ

単体テスト・結合テストの違い

「単体」と呼ばれる少量のコードを検証する。
実行時間が短い。
隔離された状態で実行される。
  • 単体テストには古典派とロンドン学派の2つの流派がある。
  • 古典派は1つの振る舞いに対してテストし、ロンドン学派は1つのクラスに対してテストする。
  • 古典派はテストケース間で共有される依存(DBやファイルシステム)のみモックし、ロンドン学派は不変依存(値オブジェクトや列挙型などその値のみで識別されるもの)を除く全ての依存に対してモックする。
  • 著者は古典派を好んでおり、ロンドン学派だと実装の詳細に対するテストになりやすく賛同できない。

モックの使い方

  • 単体テストではモックを使わない。管理下にあるコードをモックすると整合性が取れていなくてもテストが通ってしまう場合がありテストの価値が下がる。
  • スピードが遅くなることが懸念されるが、整合性はテストで担保されるべきでありチェックすべきとこる。
  • DBのテストは書き込みは必ずテストする。読み込みは重要な部分だけテストする。
  • 結合テステストでは管理外のコードも利用するので、管理外のコードに対してのみモックを使う。
モックを使っていいのはシステム間コミュニケーションの場合で、かつそのコミュニケーションが外部から観察できる場合である。

リファクタリングが必要なコードの識別

  • コードの種類を4つに分類している
協力オブジェクトの数が少ない 協力オブジェクトの数が多い
コードの複雑さ・ドメインにおける重要性が低い 取るにとらないコード コントローラ
コードの複雑さ・ドメインにおける重要性が高い ドメインモデル・アルゴリズム 過度に複雑なコード

SQLAlchemy2.0でPostgreSQLを使うメモ

SQLAlchemy2.0でPostgreSQLを動かす際、driverどれにするか迷ったのでメモ。

結論

その時はasync使う必要がなかったのでpsycopgにした。FastAPIなどasyncをモリモリ使う場合はasyncpgにするとDB接続以外のところでasync使って速度出そうとしているのをうまく活かせそう。

ORMでのBULK INSERTの最適化

SQLAlchemy2.0ではほとんどのdriverでBULK INSERT + RETURNING(executemany() + RETURNING)の最適化が施された。executemany()の最適化は1.4でpsycopg2に対して最適化されたもので、他のdriverにも適用されるようになった。1.4のpsycopg2ではexecutemany()のみの最適化だったが、2.0の他のdriver にはexecutemany()だけでなくその後のRETURNINGも含めた最適化が施された。

psycopg

pysycopg3とも言えるが、psycopgが正式名称。(psycopgのバージョン2はpsycopg2、psycopgのバージョン3はpsycopgというなんともややこしい…)

ベンチマークをみると、BULK INSERT後のRETURNINGがかなり改善されたことがわかる。 https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html#benchmarks

psycopg2

BULK INSERとRETURNINGのベンチマークに1.4と2.0で差がない。SQLAlchemy1.4でexecutemany()の高速化がすでに実装されたので、BULK INSERT後のRETURNINGのサポートをしないそう。

asyncpg

こちらもpsycopgと同様、かなり改善された。BULK INSERTとは関係ないが、asyncpgを呼び出す側にevent loopなどasyncの仕組みを実装しないといけないのが面倒。FastAPIなどasyncが標準の仕組みにのせるならasyncpgを使うべきだろう。

pyconf2022の感想

プロダクトマネージャーのカンファレンス「pmconf2022」をオンライン視聴したので感想をざっくりと。 2022.pmconf.jp

全体的な感想

プロダクトマネージャーの仕事の一部を担い始めたので初参加してみましたが、どのセッションも学びが大きかったです。各現場で問題となっていたこととそれに対する取り組みや、プロダクトマネージャーのキャリアの歩み方の体験談などが紹介されていました。 どの話も「その苦しみ・辛さめっちゃわかって、アアア…！（苦痛な叫び）」とも「取り組みがすばらしすぎて、アアア…！（感嘆）」となりました。

プログラミング言語と違ってプロダクトマネージャーは横の繋がりを得にくく、プログラミング言語と比較すると最近注目され始めた分野でノウハウが溜まっていないので オンサイト交流会参加したかったなあと 発表内容を聞いてから思いました。

気になった登壇

『組織として』顧客を理解するインタビュー習慣の作り方

  • 毎日インタビューが行われており、しかもそれに職務関係なくエンジニアやデザイナーでも参加できるという取り組み。
  • 2人組でインタビューし、インタビューを数行のインタビュースナップショットに協力してまとめる運用。インタビューをまとめるのが楽になり、心理的ハードルがさがった。
  • インタビューで得た知見が属人化せず、チームや組織の共通理解に。
  • インタビューのハードルが下がったことでインタビューが習慣化され、インサイトがプロダクトに反映されるまでのリードタイムが圧縮された。 speakerdeck.com

今日から始める「実例マッピング」

  • 「実例マッピング」とは、機能に対するユーザーの使い方の具体例を意識的に集め、備えるべき要件を導くワークショップ。
  • 作ってみてから不具合があることや要件不足に気づく問題を解決。
  • 要件定義の段階で要望に現れないユーザーの使い方が拾えないこと、要件レビューの段階で実際に作るべきものとのズレが見つけられないことが原因。
  • 要件の文書を書いてレビューしてもらう運用だと、「要望とズレた内容が書かれていないか」に気を取られて「これで要望を満たせるのか」の確認は難しい。
  • Alp社だと、プロダクトマネージャー、開発メンバー、CSなどのビジネス職メンバーでワークショップを行い、30分ほどで終わるとのこと。
  • 要件を作るために実例や疑問を上げることが求められる。要件の文書レビューのように書いた内容に収まった議論で終わり漏れが出来てしまうのを防げる。 speakerdeck.com

アウトカム最大化のためのプロダクト開発と組織

  • チームが意思決定権を持ちアウトカムに責任をもつことによって、アウトカムの最大化を図った。
  • POとデザイナーが仕様を作り各開発チーム(機能チーム・基盤チームと技術領域で分けていた)がそれにそった開発をする運用だと、社内受託的な開発になってしまい、チームがアウトカムに責任を持ちにくい状態になってしまった。
  • 仕様策定・リリース・検証の責任を一貫して担えるクロスファンクショナルなチームに移行。チームはPdM・デザイナー・フルスタックエンジニアで構成。
  • POは作りたい体験の優先順位を決め、チームに割り振る。この時、仕様の詳細度は低い状態で渡す。
  • チームでCPF・PSF・SPFを達成するための最小アウトプットを考え、不確実性を下げて仮説を明確にする。その後プロダクトを作り、立てた仮説に対しての検証を行い、チームで振り返る。
  • 仮説を立てる段階から巻き込むことで、チーム全員が当事者意識を持つようになりアウトカムが最大化する。 speakerdeck.com

「エンジニアリングマネージャーのしごと」を読んで

この本の概要

エンジニアリングマネージャーの仕事や、必要なスキルや考え方についてまとめられています。 物語形式で書かれており、新しい会社で初めてマネジメント職についた主人公が仕事を進めていく内容になっています。親近感をもてたのでサクサク読み進められました。

www.oreilly.co.jp

おすすめしたい人

  • エンジニアリングマネージャーになったばかりの人
  • 面識のないメンバーばかりのチームのエンジニアリングマネージャーに拝命された人

感想

マネジメント系の本は心構え中心に語られることが多い印象でしたが、この本は採用・1on1・評価面談など実務に沿って書かれているので助かりました。それぞれの実務に1章使っており、どのような考え方のフレームワークで挑むのかしれて良かったです。

また、マネージャーのアウトプットは常に意識しないといけないなと思いました。 マネージャーはMTGが多いとよく聞きますが、これを考えると納得です。

マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット

特に学びになった章

３章 上手なコミュニケーションをするには

  • タスクを委譲するにあたっての説明責任と実行責任という考え方。説明責任は委譲できない。
  • 委譲のものさしの考え方。チームメンバーの経験やスキルをみて委譲の具合をコントロールしてタスクを振るべし。
    • 委譲なし(自分でやる)
    • 自分がやり方を示す
    • 相手が行い自分がガイドする
    • 相手が行い自分が頻繁にチェックする
    • 相手が行い自分がときどきチェックする
    • 終わったら相手が知らせてくれる
    • 完全な委譲(相手がやる)

４章 1on1

  • 1on1では、チームメンバーがキャリアに合わせて適度なやりがいや満足感をもってできるようにするために、その人の個性やモチベーションをどう活用するかを探る
  • 1回目の1on1では、チームメンバーとの関係性を正しい方向に進ませるためにコントラクティングというエクササイズを行う。これを使えばお互いに期待していることを率直に話し合える。
    • いちばんサポートが必要な分野はどこか？
    • どんな形でフィードバックやサポートを受けたいか？
    • 一緒に働く上での問題は何か？
    • マネージャーのサポートがうまくいっていないことはどうすればわかるか？
    • ミーティングの内容の機密性はどれくらいか？

5章 何が人を動かすのか？

  • 個人は性格やモチベーションが異なるため、その人の欲求に沿ってその人に合った仕事を任せるのが大事。
  • 継続的にスキルを向上させるために大切なこと
    • 支援ありでできるタスクを与えること
    • タスクの完成を支援する豊富な知識を持つ適任者がいること
  • 管理と安定によってモチベーションが高まる人もいれば、カオスや変化によって高まる人もいる。1on1などの会話を通してチームメンバーがどちらなのかを探るのが良い。　

15章 デュアルラダー

  • 本章内で、ICへ進むキャリアとマネージャーとして進むキャリアについて、それぞれの職位（ジュニア〜シニアみたいなやつ）を表にして定義してくれている
  • チームメンバーのキャリアについて、表をたどりながら1on1や評価面談すると良さそう
  • コード書きながらマネージャーをしている人について、マネージャーとコードを書くのを両立しているなら問題ないが、マネージャーの仕事に支障をきたしているなら仕事量を調整したほうが良い

17章 スタートアップ

  • 変化がめまぐるしくカオスになりやすいスタートアップこそ、チーム編成・品質・組織の拡張などエンジニアリングマネージャーの考え方やスキルを持つ人が必要
  • 会社やCTOがスピード感をもって物事を進めようとすることに対する歯止め役になり、スピードのバランス調整することに寄与する

「失敗から学ぶRDBの正しい歩き方」を読んで

この本の概要

RDBを使って開発する上で、よく起こる問題とその解決策が書かれています。 テーブル設計からMySQL/PostgreSQLの違いを踏まえたロックの仕組みなど、内容は多岐に渡ります。 1章あたりが短いため、サクサク読めます。「やりすぎたJSON」「聞かないINDEX」など章のタイトルがわかりやすいので、「近々INDEX設計をするからこの章を読もう」みたいな辞書的な使い方もできます。

gihyo.jp

おすすめしたい人

  • RDBMSを使ってなにかを作る上で、予め起こりうる問題を防ぎたい人（もしくはすでに問題が起こって困っている人）
  • 運用に耐えるテーブル設計ができるようになりたい人

感想

RDBを使って何か作っている方は、手元に1冊持っていることをおすすめします。 私は、RDBを使う中で何かあればこの本を手に取っています。開発の指針にもしており、大変助かっています。

また、本書の「はじめに」に、RDBの使い方のアンチパターンを学ぶ意義を以下のように書いています。RDBのアンチパターンを学ぶ重要さが身にしみました。

データベースは長く付き合っていかねばならない相手であり、開発者はその特性ゆえの問題にぶつかることがあります。

(中略)

  • データベースの停止はサービスの停止を伴うことが多いため、メンテナンスしにくい
  • データは常に増え続け、リファクタリングしにくい
  • サービスの中核を担うため、変更による影響が大きい

特に学びになった章

4章: 効かないINDEX

  • INDEXが使われるには以下の条件が必要。
1. 検索結果がテーブル全体の20％未満
2. 検索対象のテーブルが十分に大きい(数万〜数十万行が目安)
  • WHERE age * 10 > 100など検索対象の列を加工するとすべての行に対してage * 10を実行する必要ができてINDEXが使われないので、age > 100/10にするなどその列を計算しないようにします。
  • 統計情報のためのサンプリング前後で大量のデータの更新があったりすると、統計情報と実際のテーブルで乖離してINDEXが使われないことがあります。その場合は統計情報を更新します。

8章: JSONの甘い罠

  • JSON型のデメリット
* ORMが使えない(個人的に、DjangoやSQLAlchemyはJSON型サポートしているけど他の言語はどうなのか気になります。)
* データの整合性が保てない
* データの中身を指定できない
* 参照整合性制約を強制できない
  • JSON型のメリット
* JSONをそのものに対応している
* スキーマレスに値を保存できる
→Web APIのレスポンスなど仕様変更が頻繁なデータをエラーなく保存するのに役立つ。Web APIの場合、必要なデータは正規化してその他が含まれるJSONは別のテーブルに分ける設計もあり。
  • Entity Attribute ValueからJSON型にしない方がよい場合
* 正規化することができない
* JSONに対して頻繁に更新を行いたい
* 検索条件としてJSON内の属性を固定できない

13章: 知らないロック

MySQLとPostgreSQLとではロックの仕様が異なります。

PostgreSQL

PostgreSQLではSELECTでも「AccessShareLock」という一番小さいレベルのロックを取るので、以下の場合はLOCKテーブルとデッドロックが発生します。 MySQLではLOCK TABLE実行時にそれまでのアクティブなトランザクションを暗黙的にコミットするので、デッドロックが起こりません。

-- トランザクションA
demo=# BEGIN;
BEGIN
demo=# SELECT * FROM demo;

-- トランザクションB
demo=# BEGIN;
BEGIN
demo=# SELECT * FROM demo;

-- トランザクションA
demo=# LOCK TABLE demo;
LOCK TABKE
-- ここでAとBのデッドロックが発生する
MySQL
ギャップロック
  • 「INDEXを持つ行」と「INDEX値を持つ行」の間にやるギャップ
  • 先頭の「INDEX値を持つ行」の前に存在するギャップ
  • 末尾の「INDEX値を持つ行」の後に存在するギャップ へのロック。
WHERE id > 3 AND id < 8

で、id=4,7の行が実際にある場合、 id=5~6がギャップロックの範囲。

ネクストキーロック

行ロックとその行の直前のギャップロックの組み合わせ。

-- トランザクションA
mysql > BEGIN;
mysql > UPDATE demo SET num = 2 WHERE id < 3;

-- トランザクションB
mysql > BEGIN;
mysql > UPDATE demo SET num = 3 WHERE id = 3;
-- ネクストキーロックによってトランザクションAではid=3の行もロックの対象になるので、この時点で待たされます。

14章: ロックの功罪

  • ロックは並列処理でデータの一貫性を守るためにあります。
  • トランザクション分離レベルは
1. read uncommited
2. read commited
3. repeatable read
4. serializable

があり、下に行くほど並列度が下がります。

ダーティーリード ファジーリード ファントムリード ロストアップデート
read uncommited 発生 発生 発生 発生
read commited 起きない 発生 発生 発生
repeatable read 起きない 起きない 発生 発生
serializable 起きない 起きない 起きない 起きない
  • ロストアップデートは複数トランザクションで更新が並列に行われた場合、後に実行されたトランザクションで結果が上書きされる現象。ロストアップデートはトランザクション分離レベルによって振る舞いが変わるため、運用途中で変更した場合、値がずれるなどSQLの結果が意図せず変更されることがあります。
-- repeatable readの場合
-- トランザクションA
BEGIN;
SELECT 価格 FROM 商品 WHERE id = 1; -- 1000

-- トランザクションB
BEGIN;
SELECT 価格 FROM 商品 WHERE id = 1; -- 1000
UPDATE 商品 SET 価格 = 価格+1 WHERE id = 1;
SELECT 価格 FROM 商品 WHERE id = 1; -- 1001
COMMIT:

-- トランザクションA
UPDATE 商品 SET 価格 = 価格 + 5 WHERE id = 1;
COMMIT;
SELECT 価格 FROM 商品 WHERE id = 1; -- 1005
-- repeatable readの場合ファジーリードが発生しないため、価格が1005になるが、read commitedの場合は1006になります。
  • PostgreSQL9.1以降とMySQLではrepeatable readでもファントムリードが発生しない
  • MySQLではSELECT ... FOR UPDATEでロックをした場合、repeatable readを利用していても直前にコミットされたレコードを返す
  • 並列度を維持しつつデータの一貫性を担保するには、repeatable readを設定している場合に一貫性を担保したい箇所でSELECT ... FOR UPDATEで排他ロックを取得してロストアップデートを防ぐなど工夫が必要。

近況報告と自己紹介

最後にブログ書いたの、2021年12月とか書かなすぎだろ…　ってことで重い腰を上げて書くことに。

久々に書くことにしたきっかけ

最近、Meetyというカジュアル面談のプラットフォームで会ったことない方々とお話するのを楽しんでいます。 カジュアル面談する前に、その方のnoteやブログがあったら読んで、どんな方か解像度を上げてからお話するのですが 「私とカジュアル面談する方、私に対する解像度低いまま挑んでいるのでは…？」 と気づいてしまいました。

せっかくお時間いただくのでもうちょっと自分のこと知ってもらって話に華を咲かせたいなと思い、執筆します。

期間が空きすぎた経緯としては、 チームビルディングとかプロダクト開発の進め方など、 唯一解のない仕事の比重が増え キャッチアップする内容もプロダクトマネジメントやエンジニアリングマネジメントなどが中心になったことが大きいです。

唯一解のないものは、対立しやすいので正直書くのが怖いです。って思っているうちに9ヶ月も月日が流れましたｗ

今までのブログ記事では、「Pythonで…する方法」など唯一解のあるもの中心に書いており、唯一解なら違う考えの人がいないので対立しようがないだろうと考えていました。

これからのブログ方針

とはいえ、やっぱり会ったことのない人と話す時は自分の考えを知ってもらった方がお互い実りのある時間を過ごせるはずです。 ですので、徒然と普段考えていることや↑の学びも書こうと思います。 ただ、やはりこの手の唯一解のないものに対する自分の考えを公開するのはまだ勇気が要るので、ひっそり公開しようと思いますｗ

多分、しばらくはTwitterで「ブログ書いた！」とツイートしないかもしれません。

自己紹介

  • 5期目のスタートアップで正社員1名エンジニアしています。*1
  • 静岡県静岡市在住で、フルリモートで働いています。半年に1回くらいのペースで出社します。
  • 主戦場はWebサービス開発のバックエンドですが、フロントエンド（やたまにインフラ）もやっています。
  • PdM補佐*2やPjMしています。

近況（2022年8月時点）

*1:他に業務委託で4名います。勤務頻度は副業の方もいれば週2や5の方もいてバラバラです。

*2:インセプションデッキ書いて要求定義のたたき台作ったり、技術的な観点から開発の優先順位の交渉したりしますが、最終決定権はないのであくまでPdM「補佐」と書きました。

*3:「正社員のキャリアマネジメント含めないとEMの経験としては弱い」と複数名から知見をいただき、自分はEM業したことがあるとはまだ言えないんだなと認識しています。早くEM業できるくらい会社成長させて挑戦したいです。