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

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

エンジニアの「ドキュメントよりコード書きたい」を本気で解決してみた!

f:id:curama-tech:20200710184201p:plain

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

今回は、長年に渡って整備できなかった開発ドキュメントを、全員で整備する取り組みをはじめた、という内容です。

本記事は、6/10に開催した「失敗に学べ!くらしのマーケットの開発「失敗」LT会 vol.1」でのLT内容を再構成したものです。

課題

テクノロジー本部の長年の課題の1つに、「ドキュメントがない」 というものがあります。 ドキュメントがないと、

f:id:curama-tech:20200710184255p:plain

開発や環境構築などのわからないことは、Slackや口頭で聞く必要があります。 この状況では、教える側がその対応に都度時間を使う必要があり、また、内容も記憶頼りになり正確かどうか保障ができません。 特に教える側は往々にして忙しいことが多く、聞く側からすると、聞きづらい雰囲気の場合があり、ゆえに、聞く側が自己解決を試み時間がかかったり、聞かずに放置されてしまうということが起こります。

反対に、ドキュメントがあると、

f:id:curama-tech:20200710184306p:plain

聞く側が自主的に探せるようになり、また、探せなかったとしても、教える側が「xxxで検索してみて」と、キーワードを伝えることで解決できます。 それにより、教える側が都度対応していた時間を減らすこと、聞く側の聞きづらさの解消ができます。 また、内容が記憶頼りではなくなり、内容の間違いや忘れを防止できます。 さらには、教える側の使える時間が増えるため、ペアプロなどより価値の高い時間の使い方ができるようになります。

このようなメリットがあるとわかっていても整備が進まないのが、ドキュメントです。

どうすれば、ドキュメントを充実させていくことができるのでしょうか。

そんな中、ある方から次のようなアドバイスをもらいました。

転機

f:id:curama-tech:20200710184317p:plain

f:id:curama-tech:20200710184329p:plain

たしかに、コードとドキュメントどっちに時間を使うべきか迷ったり、一人で書こうとして整備が進まなかったドキュメントですが、みんなで同時に書くのであれば、時間の設定や全員の責任として、書くことができるはずです。

これは良いのではないか、ということで実施してみました。

やってみた

実施にあたって、次の3つのポイントを決めました。

  1. ドキュメントのフォーマット
  2. ドキュメントの項目
  3. イベント化する

順番に、 f:id:curama-tech:20200710184343p:plain

まずはゴールを決め、そこに求められるドキュメントのフォーマットを決めます。 今回達成されるべきゴールは、そのドキュメントを他の開発チームが読んで理解できることです。 現在の状態では、フォーマットを詳細に決めてもそれを全て守ることに頭を使ってしまうので、ゴールが達成に必要な必要最低限のものだけにします。

記事は、機能単位の粒度で1つの記事にまとめます。 記事が長くなる可能性がありますが、それよりも記事が分散し探す手間が増えたり、更新漏れの発生を防ぐためにまとめます。 今後、記事が長くなってから分割することを考えればよく、まずは記事を書くことに集中します。 その他、事実と感想を分けることや、図や表を使ってわかりやすくすることなど、基本的なことだけ決めます。

f:id:curama-tech:20200710184357p:plain

次に、ドキュメントの項目出しをします。 チーム毎にこれまで扱った開発内容のドキュメントを書いていくため、まず項目の抜け漏れがないか確認をするため、同じ項目を複数名で同時に作成してしまうことを防ぐために行います。 どの項目から作成に着手するかはチームで判断して大丈夫です。 ただし、2,3回...と継続して取り組んでいき、どの項目もいずれ書くことになるので、優先度は決めなくても問題ないと思います。

f:id:curama-tech:20200710184406p:plain

最後に、ドキュメントを書くことをポジティブに認識していけるように、この取り組みをイベント化していきます。 また、ゴールが達成されているかの確認と、成果を出すことに意識を向けるために、ほかの開発チームからレビューをもらうようにします。 ドキュメントは全員で作成、更新していくものであり、全員が参加すること、という意識付けでもあります。

レビューが終わったら、全員で簡単にドキュメントの概要を発表しあいます。

結果

「xxxで検索してみて」と言えるタイミングが増えました。 結果として、教える側が都度付きっきりで教えていた時間を、他のことに使えています。 また、ドキュメントのレビュー時に、レビュワーが初めて知る内容もあり、そのタイミングからすでに理解が深まっていく様子でした。

今年4月に1回目を開催し、毎月1回開催し、6月までに計3回開催しました。

ドキュメントは増えてきましたが、カバレッジをもっと上げるために今後も月1回で継続開催し、カバレッジが高まってきたら数ヶ月に1回の開催のように、頻度を落としてもいいと思います。

おわりに

そもそもドキュメントがないとドキュメントの有用性を理解できなく、ドキュメントが書かれないという悪循環に陥ると思いますが、ドキュメントのカバレッジが上がり、日常的に使うようになってくると、逆にドキュメントがないことが目立つようになってくると思います。 そうなると、このような取り組みをしなくても、その気持ち悪さから自然とドキュメントを作成し、そこを補完しようとする気持ちに私はなると考え、今後はカバレッジが上がるにつれて、ドキュメントを書くカルチャーも根付いてくるのではないかと思いました。

動画初心者がAWS Elemental MediaConvert使ってみた!

f:id:curama-tech:20200703183513p:plain

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

今回は、動画の知識がない初心者がAWS Elemental MediaConvertを使って動画変換してみた、という内容です。

ことのはじまり

先日、仕事で動画撮影の機会があり、合計6時間(1920x1080, 60fps)ほど撮影しました。 動画撮影の機会も、ましてや6時間も撮影する機会はこれまでなく、データ量を特に考えずに撮影してしまい、いざSDカードを開いてみると、6時間かつ60fpsということもあり、データ量が65GBとなっていました。

困ったのは、GPUが積まれていたり、SSDの空き容量が十分といった動画編集に向いたPCが手元にはなく、普通のPCでこのまま処理すると、編集や書き出しに相当の時間がかかることが予想できました。SSDの空き以外にも、編集は元のサイズでできたとしても書き出しは時間がかかりそうで、とはいえ、一度、編集のためにサイズの小さい720pにするだけでも6時間もあるとこれも変換に時間がかかることが予想できました。

解決案

そもそもの原因はマシンスペックが動画向けでないことであり、解決策として次の3つを検討しました。

  1. マシンスペックを上げる
  2. EC2のGPUインスタンス + ffmpeg
  3. AWSの動画変換サービス

1,2に関してはGPUやどこまでの性能が必要かを調べる必要がありますが、3であればマネージドであり性能面は気にせず、また、物理デバイスを用意する時間も省けるのではないかと考え、今回は3を選択することにしました。

AWSの動画変換サービス

AWSのメディア系サービスのうち、動画変換ができそうなのはこの2つでした。

違いの明確な説明を発見できなかったですが、簡単に次のようです。

  • Amazon Elastic Transcoder
    • 基本的な動画の変換ができる
  • AWS Elemental MediaConvert
    • 動画の変換の他に、結合、イメージの挿入などができ、Transcoderよりも高度
    • Elastic Transcoderのページの冒頭からMediaConvertを推奨している表記があり、今後はMediaConvertがメインになっていく?

今回は次の2つの点を要件とし、

  • ローカルで扱いやすくするためにデータ量を減らすこと
    • 720p, 30fpsに変換する
  • 4GB毎に分かれている動画ファイルを連結すること

この要件を満たすことができる、MediaConvertを使ってみることにしました。

MediaConvertの料金は、出力ファイルの時間、1分単位での課金です。 また、ベーシック階層とプロフェッショナル階層があり、Pro と記載のあるオプションやメニュー、パラメータを選択するとプロフェッショナル階層での課金になるようです。

f:id:curama-tech:20200703183541p:plain

今回、6時間、1080p、60fpsの動画を、同じ6時間、720p, 30fps, AVC(H.264, ベーシック階層)コーデックに変換すると次の課金になります。

6(時間) * 60(分) * 0.017(米ドル/分) = 6.12(米ドル)

(東京リージョン、2020/07/02現在)

使ってみた

MediaConvertによる動画変換の流れは、次の通りです。

  1. 入力ファイル(変換元のファイル)をS3にアップロードする
  2. MediaConvertでジョブを作成、実行する
  3. ジョブ完了後、出力ファイル(変換後のファイル)がS3にアップロードされる

(初回利用の場合はジョブ作成前に、MediaConvert用のIAMロールの作成が必要です。)

1,3はそのままの意味なので、記事では、2のジョブの作成と実行について取り上げます。

入力ファイルの設定

まず、ジョブ一覧にある、ジョブの作成 から作成画面に移ります。 f:id:curama-tech:20200703183603p:plain

ジョブの作成画面で、入力の追加を押下し、入力1,2,3...に、入力ファイルのS3パスを設定してきます。 今回は複数の入力ファイルの結合もするため、入力を複数作成しており、入力の番号順に結合が行われます。

f:id:curama-tech:20200703183619p:plain

全ての結合するファイルを設定したら、入力ファイルの設定は完了です。

次に出力ファイルの設定をしていきます。

出力ファイルの設定

出力グループの追加を押下すると、グループの選択モーダルが表示されます。 今回はファイルグループを選択します。 f:id:curama-tech:20200703183638p:plain

次に、File Group送信先に、出力ファイルを作成するS3パスを指定します。 f:id:curama-tech:20200703183649p:plain

出力ファイルの設定は完了です。

次にエンコードの設定をしていきます。

エンコードの設定

Output 1 をクリックすると、エンコードの設定画面が表示されます。

ざっと眺めてみると、コーデックや解像度など知っているものもありますが、 f:id:curama-tech:20200703183713p:plain

画面下に行くと、知らない設定値が並んでいます。 画面最下部を見ると、ノイズ低減、イメージ挿入、色補正もできるようです。 f:id:curama-tech:20200703183728p:plain

現状は、ゼロベースで設定できるだけの知識をもっていないので、今回はプリセットを使うことにしました。

設定画面上部のプリセットから適切なものを選択します。

f:id:curama-tech:20200703183741p:plain

今回は、 720p, 30fps, AVCで出力したいため、次のプリセットを選択しました。

System-Generic_Hd_Mp4_Avc_Aac_16x9_Sdr_1280x720p_30Hz_5Mbps_Qvbr_Vq9

f:id:curama-tech:20200703183753p:plain

エンコードの設定は完了です。

最後に、IAMロールの設定をします。

IAMロールの設定

ジョブの設定 からIAMロールを設定します。

f:id:curama-tech:20200703183808p:plain

ここまでで必要な設定は完了しました。

実行と結果

ジョブを開始し、ジョブ一覧でCOMPLETEになると、S3に出力ファイルが作成されている状態です。

今回、長さはバラバラですが動画を3本、計6時間分を並列で変換処理しました。

その結果、動画1本の処理時間はおおよそ60〜90分で変換でき、 6時間分の全ての動画ファイルのサイズは合計で9.9GBになり、ローカルで扱える状態になりました。

おわりに

今回、はじめてAWSの動画関連のサービスを使ってみました。

MediaConvertは、プリセットがあったため、初心者でも動画の変換を行うことができました。 今回のような長時間の動画変換や、また、システムにアップロードされる動画の変換など、安定した動作環境、スケールする動作環境が要件になる場合にMediaConvertのようなマネージドサービスを選択するのは正解と思いました。

今回は仕事で使用しましたが、運動会など家庭で長時間の動画を撮ったときも使えそうですね。

リモートワークなので VSCode で Remote-SSH しながら LiveShare を試す

f:id:curama-tech:20200407155134j:plain

バックエンドエンジニア 兼 SRE のまのめです。

ご時世もあり、弊社の東京オフィスではリモートワークが推奨されています。
オフィスではデスクトップの Linux PC を使っている人が大半なので、リモートワークでは ssh でオフィスの PC にアクセスして作業する人が多いです。

これで基本的には問題ないのですが、困りの種になっているのが「コーディングのことを相談しづらい」というところです。
オフィスにいれば PC を持っていくなりして、コードを見せながら説明できるのにな〜。

ということで、VSCode の LiveShare 機能を、リモートワークで試してみました!

やってみる

まず先に、ホスト側が共有したいのは ssh でつないだ PC にあるコードなので、Extension のRemote - SSHを入れて、ssh で接続した画面を用意しておきます。
(画面左下に、「SSH:HOSTNAME」と出ていることを確認します)
そしてその画面上で、LiveShare の Extensionを入れます。

導入自体に関しては、公式の Quick Start を見るのが早いです。
なお作業する人が全員、LiveShare の Extension を入れておく必要があります。

ホスト側は、LiveShare のアイコンからメニューを出して、「コラボレーションセッションの開始」をクリックします。
初回は認証とかが必要なので、GitHub のアカウントなどで認証をしておきましょう。
準備ができると、クリップボードにリンクがコピーされるので、それを相手に伝えましょう。
リンクが分からなくなったらこのマークをクリックでコピーできます。

f:id:curama-tech:20200407155200j:plain
LiveShare の招待リンク

URL を受け取った側は、そのリンクを踏むと LiveShare されたコードに入れます。

これだけです!

やってみた感想

音声通話も Extension でできるようですが、今回試したときは Slack コールで音声通話をしながらコードを見ました。
ホスト側のカーソルや選択範囲などがハイライトされるので、「ここのコードが…」みたいなのを説明しやすかったです。

f:id:curama-tech:20200407155210j:plain
(思いっきりプロダクトコードなので、モザイクをかけています)

そして結構驚きなのですが、Remote-SSH で接続したコードであっても、大変スムーズにアクセスできて、レイテンシも少ないという感触です。
ssh over VPN という状態なのにもかかわらず、重いと感じたことがありませんでした。

今回はコーディングの相談という形でしたが、今後ペアプロやモブプロをすることになってもこれを使いたいです。
僕は普段 Emacs でコーディングをしているのでほとんど VSCode を使わないのですが、この機能のために環境だけでも整えておこうかなと思います。

まとめ

VSCode の LiveShare は、大変便利で作業がはかどりました。
Remote-SSH しながらでも快適にできることがわかったので、みなさんもぜひ試してみてください。

僕たちテックチームでは「くらしのマーケット」を一緒に作る仲間を募集しています。
こういった「これできるようにしたい!」をまずやってみる、という仲間がたくさん在籍しています。
一緒にくらしのマーケットを盛り上げたい!という方はコーポレートサイト https://www.minma.jp/ までお気軽にご連絡ください!

DDD開発をしてみての振り返り

バックエンドエンジニアの@akiraです。
今回はチームで採用しているドメイン駆動設計について、実際に開発してみて三ヶ月ほど経ちましたので、その知見等を公開したいと思います。
まず初めに、ドメイン駆動設計の基礎をおさらいしましょう。

f:id:curama-tech:20200324204507j:plain
ひざまずいて話を聞くたんさん

ドメイン駆動設計(Domain-Driven Design)とは

Eric Evans氏が提唱した設計手法です。
ドメインモデルを使って、実装とドメインの概念を一致させることで、ドメインの複雑な問題を解決できます。

ドメインとは対象ビジネスが扱う業務領域のことであり、ソフトウェアによって解決しようとしている問題とも言えます。
ドメインモデルとは、ドメインから必要な概念を抽出したものであり、ユビキタス言語から構築されるものです。
ドメインモデルとユビキタス言語は、定義だけでは理解し辛いかもしれませんので、10円玉を例に説明します。

現実世界における10円玉の属性をいくつかピックアップすると、以下などが挙げられるかと思います。

  1. ほぼ銅で作られている
  2. 約4.5グラム
  3. 所々傷がある
  4. 10円の金銭的価値をもつ
  5. 硬貨

しかし、ソフトウェアの世界において10円玉の概念を実装するならば、上記全ての属性が扱われることはないでしょう。
例えば「10円の金銭的価値を持つ」という属性だけが抽出されてクラスとして定義されます。
このクラスがドメインモデルであり、10円玉から「10円の金銭的価値を持つ」属性だけを抽出することをモデル化と言います。
また、この「10円の金銭的価値を持つ」自体がユビキタス言語です。
ユビキタス言語は、ドメイン駆動設計で開発を行うチーム内で共有する言語のことで、ドメインの概念や仕様を指します。

ところで、券売機の組み込みソフトウェアをドメイン駆動設計で開発する場合、「紙幣」または「硬貨」として定義される「お金」の「種類」というユビキタス言語があるかもしれません。
この場合、上記の10円玉の属性における「硬貨」はユビキタス言語として定義されているため、ドメインから抽出され、モデル化されます。

ドメインはそれ単体では広範囲な領域となるため、通常は複数の小さなドメインに分かれます。
この複数に分けられたドメインサブドメインと言います。
サブドメインで最も価値が大きく重要なものをコアドメインと呼び、他のサブドメインと区別します。

ドメイン駆動設計はStrategic Design(戦略的設計)とTactical Design(戦術的設計)の二つで構成されます。
Strategic Designはドメインの分析とモデリングをどう行うかを示すビジネス的設計であり、Tactical Designはどのようにコードを書くかの技術的設計を指します。

ドメイン駆動設計には主に二種類の登場人物がいます。
デべロッパーとドメインエキスパートです。
デべロッパーは、要するにコードを書く人です。
ドメインエキスパートは、そのドメインに詳しい人を指しますが、必ずしもビジネス側で働く人を指すとは限りません。
デべロッパーがドメインエキスパートを兼ねていることもあります。
ユビキタス言語は、デべロッパーとドメインエキスパートの両方が理解できる言語でなければなりません。

Eric氏はドメイン駆動設計においてレイヤードアーキテクチャーを推奨していますが、関心の分離ができれば他のアーキテクチャーでも実装は可能でしょう。
また、プログラミング言語としては、オブジェクト指向プログラミングが可能な言語を推奨しています。

クリーンアーキテクチャ

私のチームでは、クリーンアーキテクチャーに則ってコードを書いています。
クリーンアーキテクチャーには次の三つの層が存在します。

また上記の三層には次の依存関係があります。各層が矢印の方向に依存しています。

Domain層 <- Application層 <- Infrastructure層

Domain層はどこにも依存せず、Domain層内でドメインロジックの実装が完結します。
Application層はDomain層に依存し、Domain層で定義されたドメインモデルを使って特定のユースケースを実装します。
Infrastructure層はApplication層に依存し、Application層で定義されたServiceやRepositoryなどのインタフェースの実装を行います。

クリーンアーキテクチャーによって依存性を一方向に保ちながら関心を分離することができ、コードが非常に読みやすくなります。

ドメイン駆動設計の採用直後からドメインモデルの作成まで

昨年末からドメイン駆動設計による新規開発がスタートしましたが、当時はドメイン駆動設計に詳しいメンバーが”SAMURAI”こと@karkiしかいませんでした。
私はWeb上の記事を読み漁って基礎知識を吸収しつつ、理解した内容を社内勉強会を開催してチームメンバーに共有しました。
また、Eric Evans著書『Domain-Driven Design: Tackling Complexity in the Heart of Software』(英語版)を福利厚生で購入して読み込み、理解を深めました。

f:id:curama-tech:20200324204512j:plain
勉強会の様子

12月あたりからおおよそドメイン駆動設計を理解できてきたので、@karkiと共に初期のTactical Designを進めていくことにしました。
@karkiは、くらしのマーケットのビジネスに詳しいのはもちろんのこと、システムにも非常に詳しいため、デべロッパーでありながらドメインエキスパートでもありました。
彼からも随時ドメインについての知識を吸収し、理解を深めていきました。

Tactical Designはまず、ホワイトボードでドメインモデルを描くことから始めました。
UMLほど正確には描かずに、本当にラフな感じで描いて修正していきました。
おおよそドメインモデルが描けたら、今度はTypeScriptでざっくり実装していきました。
ドメインモデルのメソッドを追っていき、目的の処理ができることを確認して、初期のTactical Designを完了しました。

Strategic Designで悩む

ドメインの中で、共通のドメインモデルを使う三つのサブドメインが存在していました。
これらのサブドメインを別々に実装するか、一つにまとめて定義するかで苦悶しました。
まとめたサブドメインから別々に切り出して実装することは比較的容易だが、別々に実装したドメインモデルを統合するのは難しいとチームで判断し、結局サブドメインをまとめることにしました。
今振り返ると、この判断で間違いなかったと思います。
サブドメイン単位でISSUEを切って、各々開発に着手し始めました。
まとめたサブドメインは共通のドメインモデルを使うため、設計変更やリファクタリングが発生する度にマージコンフリクトが発生しました。
コンフリクトが発生するとDXも低下するため、リファクタリングは別PRを立てて一回のリファクタリングのスコープを限定することでコンフリクトの量を減らすことができました。

Tactical Designとテーブル設計

サブドメインのDomain層とApplication層のコードが書き終わったあたりで、テーブル設計にも着手し始めました。
インタフェースを実装するクラスが二種類存在するドメインモデルは、それぞれの具象クラス独自の属性が少なく、クラスの種類も二種類と少なかったため、シングルテーブル継承で設計しました。
一方、インタフェースの実装クラスが多数存在するドメインモデルは、具象テーブル継承で設計しました。

ドメイン駆動設計とテーブル設計

実はこの開発が始まる前に、私は既存機能のリプレイスをドメイン駆動設計で行なっておりました。
既存機能のPythonコードをドメイン駆動設計 + TypeScriptで実装し直し、DBのテーブルは既存のテーブルを使う、といった開発でした。
しかし、この開発で大いに苦労しました。
というのも、テーブルは一切変更しないため、ドメインモデルのプロパティがテーブルのカラムに依存したものとなってしまったためです。
なんとか実装したのですが、DBとのやり取りでDBModelとドメインモデルの変換処理が毎回発生し、そのためのコードを大量に書く結果となりました。

ドメイン駆動設計によるリプレイスでは、テーブルを変更しない場合は、ドメインモデルがデータモデルに依存しないように気をつけましょう。

ユビキタス言語とドキュメントについて

ユビキタス言語は、ドメインエキスパートとデべロッパーの両方が理解していなければいけない言語です。
ユビキタス言語をコードとして実装する上で、日本語のユビキタス言語を英語に変換する必要があり、その対応表をチーム専用の辞書として作成しました。
辞書には特定の概念(単語)が英語と日本語で表現されているため、コードを読んでどんなドメインの概念が表現されているかがよく分かるようになりました。
ドメインモデルのプロパティ名やメソッド名もユビキタス言語を使うことで、より一層ドメインの知識を反映したコードが書けました。

ドメイン駆動設計を成功させるためのTips

ドメイン駆動設計を三ヶ月やってみて非常に大切だと感じた点が二つあります。

一つ目は、”とにかく早くプロトタイプを作ること”です。
ドメイン駆動設計は、一度の設計でベストなドメインモデルが手に入ることはなく、数多くのリファクタリングを経てそれに近づいていくとEric氏は指摘しています。
毎回のリファクタリングに時間がかかっていると設計が改善せず、見通しの良い設計となっていくこともないでしょう。
そのため、ドメイン駆動設計の導入段階で、ある程度コードを書ける必要があります。

二つ目は、”コミュニケーション”です。
これは、仕事をする上での一般的なコミュニケーションの重要性とは少し意味が異なります。
ドメイン駆動設計では日々のコミュニケーションでもユビキタス言語が使われるため、そこでユビキタス言語自体が鍛えられ洗練されていくのです。
その結果、認識違いを見つけたり、より良い設計のアイデアが生まれたりと、Eric氏が著書で述べている”ブレークスルー”に繋がります。

f:id:curama-tech:20200324204519j:plain
足のニオイが気になるねこ

おわりに

現在もドメイン駆動設計でコードを書いており、改善点はまだまだたくさんありそうです。
今後も色々なやり方を試してみて、より良い方法を見つけていきたいです。

私たちテックチームでは「くらしのマーケット」を一緒に作る仲間を募集しています。
みんなのマーケットでDDD開発をしたい方は、ぜひコーポレートサイト https://www.minma.jp/ までお気軽にご連絡ください!

第三回LTを開催しました

テクノロジー本部バックエンドエンジニアの福原です。
くらしのマーケットを運営しているみんなのマーケットでは、
社内 LT 会を定期的に開催しています。 LT 会がついに第三回を迎えたので、
会社の雰囲気を伝える&こんな発表をしているよというのを紹介していきたいと思います!

LT 会とは

LT とはLightning Talksの略で、 5 分程度の短いプレゼンをする会です。
LT は、IT 系の勉強会などで開催されていることが多いです。
みんなのマーケットでは、技術枠と自由枠を分けて LT 会をしています。

開催のきっかけ

みんなのマーケットでは、新卒の研修が終わったタイミングで、学んだ内容を発表する会があります。
その発表会に触発されたエンジニア(福原)が、勝手に開催したのがきっかけです。
発表する人を募集したところ、思ったより反応がよく、第三回を開催することができました。

発表内容

今までの発表の内容として、テック系の LT は

  • ぼくは Emacs を使う
  • モダン Web フロントエンド開発環境解説
  • お絵かきチャットに挑戦

といったように、自分で作ってみた系のものから最新技術を取り入れる系まで、様々な分野の発表がありました。 また、自由枠では

  • 坂道グループの Web ページを比較してみた
  • 「わかりやすい文章」の書き方
  • 学ぶ技術

のように自分の趣味を絡めた発表もありました。

開催して良かったこと

開催して良かったこととして、

  • 社内メンバーの興味ある技術がわかった
  • 今までキャッチアップしてなかった分野の技術を知れた
  • LT をきっかけに開発できた(LT 駆動開発)

の 3 つが大きかったです。
また、「次は自分も発表したい」という声が上がったのも良かったと思います。

次回の課題

LT 会の発表終了後には、LT 会に関しての感想や要望を上げてもらっているのですが
その際に、「他部署からも発表者を募ろう」という意見がありました。
第 4 回はテクノロジー本部だけではなく、他部署の発表枠を作ることで
非エンジニアが問題と感じている部分を、技術で解決できないかと試みたいと思います。

最後に

今まで、社内で LT 会を開催してなかったのがもったいないくらい、良い発表がいっぱい聞けました!
特に自分の分野とは違う分野の発表が多々あり、どれも勉強になりました。
今後はこの LT 会から、実際にプロダクトに使われるものが出てきたらな良いな、と主催者として思ってます。

私たちテックチームでは「くらしのマーケット」を一緒に作る仲間を募集しています。
みんなのマーケットで LT をしたい方は、ぜひコーポレートサイト https://www.minma.jp/ までお気軽にご連絡ください!