MQTT

の転職・求人情報

MQTT の正社員求人の件数(2026年11月8日時点)

2026年11月8日時点で、Offers Jobs で募集中の MQTT の正社員の求人は4件(3社)です。業務委託と「業務委託から正社員」の求人は数えていません。

出所:Offers Jobs 掲載の正社員求人(n=4・2026年11月8日時点)をもとに Offers 集計

  • IoT Platform Engineer

    株式会社ビットキー

    クラウドエンジニア
    IoT Platform Engineer
    • 年収 700万円 ~ 1,200万円

    • 雇用形態: 正社員

    • 勤務地:

  • インフラエンジニア

    株式会社ビットキー

    インフラエンジニア
    インフラエンジニア
    • 年収 700万円 ~ 1,200万円

    • 雇用形態: 正社員

    • 勤務地:

  • スマートファクトリーの「頭脳」を創る。全体制御ソフトウェア開発エンジニア募集!

    スマートファクトリーの「頭脳」を創る。全体制御ソフトウェア開発エンジニア募集!
    • 年収 700万円 ~ 1,120万円

    • 雇用形態: 正社員

    • 勤務地:

  • 【日本・北米・欧州の多くの空港に導入!】自動運転モビリティのソフトウェア開発

    【日本・北米・欧州の多くの空港に導入!】自動運転モビリティのソフトウェア開発
    • 年収 600万円 ~ 1,000万円

    • 雇用形態: 正社員

    • 勤務地:

転職ノウハウ
職種から転職・求人情報を探す
開発言語から転職・求人情報を探す
報酬から転職・求人情報を探す
その他の条件から転職・求人情報を探す
お知らせ
お問い合わせ
新規ユーザー登録

アカウントを作成して、求人情報のブックマークや応募の管理ができます。

登録特典:

  • ・求人情報のブックマーク
  • ・高度な求人検索
  • ・スカウトメール受信
無料会員登録

求人に関するサマリ

MQTTとは何か

MQTTの概要

MQTTは、軽量で効率的な通信プロトコルとして知られています。正式名称は「Message Queuing Telemetry Transport」で、IoT(Internet of Things)デバイスや、リソースの制限されたネットワーク環境での使用に適しています。MQTTの特徴は、少ないネットワーク帯域幅で大量のデータをやり取りできる点にあります。私たちの日常生活でも、気づかないうちにMQTTが活躍している場面が多いんです。例えば、スマートホームデバイスの制御や、工場の生産ラインのモニタリングなど、さまざまな場面で利用されています。MQTTは、デバイス間の通信を円滑にし、効率的なデータ交換を可能にする重要な役割を果たしているのです。

MQTTの歴史

MQTTの誕生は、1999年にさかのぼります。IBM社のAndy Stanford-ClarkとArcom社(現在のEurotech社)のArlen Nipperによって開発されました。当初は、石油パイプラインの監視システムのために設計されたのですが、その汎用性と効率性が評価され、幅広い分野で採用されるようになりました。2014年には、OASISによって標準化され、現在ではバージョン5.0まで進化しています。MQTTの歴史を振り返ると、IoTの発展とともに成長してきた様子がうかがえます。

MQTTの特長

MQTTには、他のプロトコルと比べて際立つ特長があります。まず、軽量であることが挙げられます。ヘッダーが小さく、通信のオーバーヘッドが少ないため、帯域幅の制限されたネットワークでも効率的に動作します。また、パブリッシュ/サブスクライブモデルを採用しているため、多対多の通信が容易です。さらに、QoS(Quality of Service)レベルを設定できるため、通信の信頼性を柔軟に調整できるのも魅力的です。これらの特長により、MQTTは IoT 時代の主要なプロトコルとして注目を集めているのです。

MQTTの仕組み

パブリッシュ/サブスクライブ型モデル

MQTTの中核となるのが、パブリッシュ/サブスクライブ型モデルです。このモデルでは、メッセージの送信者(パブリッシャー)と受信者(サブスクライバー)が直接やり取りするのではなく、ブローカーと呼ばれる中間者を介してコミュニケーションを行います。パブリッシャーはメッセージをブローカーに送信し、サブスクライバーは興味のあるメッセージをブローカーから受け取ります。この仕組みにより、送信者と受信者が互いを知る必要がなくなり、柔軟なシステム構築が可能になるんです。例えば、温度センサーがデータをパブリッシュし、複数のモニタリングデバイスがそのデータをサブスクライブする、といった使い方ができます。

トピックとメッセージ

MQTTでは、メッセージの振り分けに「トピック」という概念を使用します。トピックは、階層構造を持つ文字列で表現され、例えば「home/livingroom/temperature」のような形式になります。パブリッシャーは特定のトピックにメッセージを送信し、サブスクライバーは興味のあるトピックを購読します。面白いのは、ワイルドカードを使用して複数のトピックを一度に購読できる点です。「home/#」と指定すれば、home以下のすべてのトピックを購読できるんです。これにより、柔軟なメッセージのルーティングが可能になります。トピックの設計は、システムの効率と管理のしやすさに大きく影響するので、慎重に行う必要があります。

ブローカーの役割

MQTTシステムの中心的な役割を果たすのが、ブローカーです。ブローカーは、パブリッシャーからのメッセージを受け取り、該当するトピックを購読しているすべてのサブスクライバーにメッセージを配信します。また、クライアントの接続管理やセッション維持なども担当します。ブローカーの性能と安定性は、MQTTシステム全体の動作に直結するため、適切な選択と設定が重要です。有名なMQTTブローカーには、Mosquitto、HiveMQ、EMQXなどがあります。それぞれ特徴が異なるので、システムの要件に応じて選択するのがよいでしょう。ブローカーの選定は、MQTTシステムの成功を左右する重要な要素の一つなんです。

MQTTの利用シーン

IoTデバイスでの利用

MQTTは、IoTデバイスの通信プロトコルとして広く採用されています。例えば、スマートホームシステムでは、温度センサー、湿度センサー、動体検知センサーなどのデバイスがMQTTを使ってデータを送信します。これらのデータは、中央のコントローラーで集約され、家電の制御や環境の最適化に活用されるんです。また、ウェアラブルデバイスでも MQTTが使われています。心拍数や歩数などの健康データを、省電力でサーバーに送信するのに適しているんですよ。IoTデバイスは通常、バッテリー駆動で限られた処理能力しか持たないため、MQTTの軽量性が大きな利点となっています。

産業用IoTでの活用

産業分野でも、MQTTの活用が進んでいます。工場の生産ラインでは、各種センサーやアクチュエーターがMQTTを使ってデータをやり取りし、生産プロセスの監視や制御を行っています。例えば、温度センサーが異常を検知すると、MQTTメッセージを送信して警告を発したり、自動的に冷却システムを起動したりできるんです。また、物流分野では、トラックや貨物のリアルタイム追跡にMQTTが使われています。位置情報や状態情報をMQTTで送信することで、効率的な配送管理が可能になります。MQTTの信頼性と効率性が、産業用IoTの発展を支えているんですね。

大規模チャットシステムでの利用

MQTTは、大規模なチャットシステムやメッセージングプラットフォームでも活用されています。FacebookのMessengerやIBMの Watson IoTプラットフォームなど、多くのユーザーを抱えるサービスでMQTTが採用されているんです。MQTTのパブリッシュ/サブスクライブモデルは、多数のクライアント間でのリアルタイムなメッセージ配信に適しています。また、QoSレベルを設定できるため、重要なメッセージの確実な配信と、雑談などの軽いメッセージの効率的な配信を両立できるんです。大規模システムでのMQTTの採用は、その拡張性と効率性の高さを証明していると言えるでしょう。

MQTTの利点

軽量さと効率性

MQTTの最大の利点の一つが、その軽量さと効率性です。MQTTのヘッダーは最小で2バイトと非常に小さく、ペイロードも必要最小限に抑えられています。これにより、帯域幅の制限されたネットワークでも効率的に動作し、バッテリー消費を抑えることができるんです。例えば、携帯電話網を使用するIoTデバイスでは、この軽量性が通信コストの削減につながります。また、処理能力の低いマイクロコントローラーでも容易に実装できるため、幅広いデバイスで利用可能です。MQTTの軽量さは、IoTの普及に大きく貢献していると言えるでしょう。

双方向通信の利便性

MQTTは、双方向通信を容易に実現できるのも大きな利点です。パブリッシュ/サブスクライブモデルにより、デバイスは同時に情報の送信者にも受信者にもなれます。例えば、スマートホームシステムでは、温度センサーがデータを送信すると同時に、制御コマンドを受信することができます。この双方向性により、リアルタイムな制御や監視が可能になるんです。また、クライアント間の直接的な通信が不要なため、ファイアウォールやNAT越しの通信も容易になります。MQTTの双方向通信機能は、複雑なシステムの構築を簡素化し、開発効率を高めるのに役立っています。

スケーラビリティ

MQTTは、優れたスケーラビリティを持っています。1つのブローカーで数十万のクライアントを同時に処理できるケースもあるんです。これは、パブリッシュ/サブスクライブモデルの効率性と、MQTTプロトコルの軽量さによるものです。例えば、大規模なIoTプラットフォームでは、数百万のデバイスからのデータを効率的に収集し、処理することができます。また、クラスタリング技術を用いることで、さらに大規模なシステムにも対応可能です。MQTTのスケーラビリティは、ビジネスの成長に合わせてシステムを拡張できる柔軟性を提供しているんですね。

信頼性

MQTTは、3つのQoS(Quality of Service)レベルを提供することで、通信の信頼性を確保しています。QoS 0は「最大1回配信」、QoS 1は「最低1回配信」、QoS 2は「正確に1回配信」を保証します。これにより、アプリケーションの要件に応じて適切な信頼性レベルを選択できるんです。例えば、重要な制御コマンドにはQoS 2を使用し、定期的なセンサーデータの送信にはQoS 0を使用するといった具合です。また、Last Will and Testament(LWT)機能により、クライアントの予期せぬ切断を検知し、適切に対応することができます。MQTTの信頼性機能は、ミッションクリティカルなシステムでの使用も可能にしているんですよ。

セキュリティ機能

MQTTは、セキュリティにも配慮した設計になっています。TLS/SSLを使用した暗号化通信をサポートしており、データの機密性を確保できます。また、ユーザー名とパスワードによる認証機能も標準で備えています。さらに、クライアント証明書を使用したより強固な認証も可能です。例えば、企業のIoTシステムでは、各デバイスに固有の証明書を割り当てることで、不正なデバイスのアクセスを防ぐことができるんです。また、トピックベースのアクセス制御により、クライアントごとに適切な権限を設定することも可能です。MQTTのセキュリティ機能は、IoTシステムのセキュリティ要件に柔軟に対応できるよう設計されているんですね。

不安定なネットワークでの利用

MQTTは、不安定なネットワーク環境でも効果的に動作するように設計されています。例えば、モバイル通信を使用するIoTデバイスでは、通信が途切れたり遅延したりする場合がありますが、MQTTはこのような状況にも対応できるんです。持続的セッション機能により、クライアントが一時的に切断されても、再接続時にメッセージを受信できます。また、Keep Alive機能を使用することで、接続の維持と監視が可能になります。さらに、QoSレベルを適切に設定することで、重要なメッセージの確実な配信を保証できます。MQTTの這いような特性は、移動体通信や衛星通信など、不安定なネットワークを使用するアプリケーションで特に重要になってくるんですよ。

MQTTの具体的な実装

MQTTブローカーの種類

MQTTシステムの中核を担うMQTTブローカーには、さまざまな種類があります。オープンソースのMosquittoは、軽量で高性能なブローカーとして人気があります。小規模なプロジェクトから中規模のシステムまで幅広く使用されていますね。一方、HiveMQは商用のブローカーで、大規模な企業システムでの利用に適しています。クラスタリング機能や詳細な監視機能が特徴です。EMQXは、IoT向けに最適化された高性能ブローカーで、100万以上の同時接続を処理できる能力を持っています。VerneMQは、Erlang/OTPで書かれた分散型ブローカーで、高い拡張性を誇ります。これらのブローカーは、それぞれ特徴が異なるので、システムの要件に応じて適切なものを選択することが重要です。

主要なMQTTクライアント

MQTTクライアントも、多様な選択肢が用意されています。Paho MQTTクライアントは、Eclipse Foundationが提供するオープンソースのクライアントライブラリで、Java、Python、C、JavaScript等、多くの言語をサポートしています。組み込みシステムからWebアプリケーションまで、幅広い用途で利用されていますね。MQTTnetは、.NET向けの高性能なクライアントライブラリで、Windows IoTやXamarinアプリケーションでの利用に適しています。mqtt.jsは、Node.jsやブラウザで動作するJavaScript用のクライアントライブラリで、WebアプリケーションでのMQTT利用を容易にします。これらのクライアントライブラリを使用することで、開発者は効率的にMQTTを実装できるんです。選択の際は、使用する言語や環境、必要な機能を考慮することが大切です。

プログラミング言語での実装例

MQTTの実装は、多くのプログラミング言語で可能です。例えば、Pythonを使用した簡単な実装例を見てみましょう。Paho MQTTクライアントを使用すると、わずか数行のコードでMQTTクライアントを作成できます。接続設定、メッセージの送受信、切断処理などの基本的な操作が簡単に行えるんです。JavaScriptでは、mqtt.jsを使用してブラウザ上でMQTTクライアントを実装できます。これにより、リアルタイムのWeb アプリケーションが容易に構築できます。C言語では、組み込みシステム向けの軽量なクライアントライブラリが利用可能で、リソースの制限された環境でもMQTTを実装できます。各言語の特性を活かしつつ、MQTTの機能を最大限に活用する実装が可能なんですよ。

MQTTの動作例

基本的な接続と通信

MQTTの基本的な動作を理解するには、実際の接続と通信の流れを見てみるのが一番です。まず、クライアントはブローカーに接続要求を送信します。この際、クライアントIDやユーザー名、パスワードなどの認証情報を提供することもあります。接続が確立すると、クライアントはトピックをサブスクライブしたり、メッセージをパブリッシュしたりできるようになります。例えば、温度センサーデバイスが「sensor/temperature」というトピックにデータをパブリッシュし、モニタリングアプリケーションがそのトピックをサブスクライブする、といった具合です。通信が終了したら、クライアントは適切に切断処理を行います。この一連の流れが、MQTTの基本的な動作なんです。シンプルながら、効率的なデータ交換を実現しているんですよ。

QoS(サービスの品質)レベルによる動作の違い

MQTTには3つのQoSレベルがあり、それぞれで動作が異なります。QoS 0は「最大1回配信」で、メッセージは確認応答なしで送信されます。これは最も軽量ですが、メッセージの紛失の可能性があります。QoS 1は「最低1回配信」で、メッセージは確認応答付きで送信されます。受信確認がない場合、メッセージは再送されるため、少なくとも1回は配信されることが保証されますが、重複配信の可能性があります。QoS 2は「正確に1回配信」で、4段階のハンドシェイクにより、メッセージが正確に1回だけ配信されることを保証します。これは最も信頼性が高いですが、オーバーヘッドも大きくなります。例えば、センサーデータの定期送信にはQoS 0を、重要な制御コマンドにはQoS 2を使用するなど、用途に応じて適切なQoSレベルを選択することが重要です。

Keep Alive機能の動作

MQTTのKeep Alive機能は、クライアントとブローカー間の接続を維持するために使用されます。クライアントは接続時にKeep Alive間隔を設定し、その間隔内に少なくとも1回はブローカーとの通信を行う必要があります。通常のメッセージがない場合、クライアントはPINGREQメッセージを送信し、ブローカーはPINGRESPで応答します。例えば、Keep Alive間隔を60秒に設定した場合、クライアントは60秒以内にメッセージを送信するか、PINGREQを送信する必要があります。この仕組みにより、ネットワークの切断や障害を迅速に検知できるんです。また、ファイアウォールやNATの設定によっては、この定期的な通信が接続を維持するのに役立つこともあります。Keep Alive機能は、MQTTの信頼性向上に貢献する重要な要素なんですよ。

MQTTの拡張機能

持続的セッション

MQTTの持続的セッション機能は、クライアントの一時的な切断時にも情報を保持し、再接続時にスムーズに通信を再開できるようにする仕組みです。クライアントが接続する際に「Clean Session」フラグをfalseに設定すると、ブローカーはそのクライアントのセッション情報を保持します。これには、サブスクリプション情報やQoS 1、QoS 2のメッセージなどが含まれます。例えば、モバイルデバイスがネットワークの不安定な場所を移動する場合、一時的に切断されても再接続時に未受信のメッセージを受け取ることができるんです。この機能により、不安定なネットワーク環境でも信頼性の高い通信が可能になります。ただし、ブローカーのリソース消費が増加するため、使用する際はシステムの要件を考慮する必要がありますね。

Retained Messages

Retained Messagesは、MQTTの興味深い機能の一つです。パブリッシャーがメッセージをリテインフラグ付きで送信すると、ブローカーはそのメッセージを保持し、該当するトピックを新たにサブスクライブしたクライアントに即座に配信します。これは、最新の状態情報を新規クライアントに提供するのに役立ちます。例えば、部屋の現在の温度をRetained Messageとして送信しておけば、新しくシステムに接続したデバイスは即座に最新の温度情報を取得できるんです。ただし、Retained Messagesは慎重に使用する必要があります。不要になったRetained Messageは、空のペイロードで上書きするなどして適切に管理することが大切です。この機能を上手く活用することで、効率的な情報共有が可能になりますね。

Last Will and Testament(LWT)

Last Will and Testament(LWT)は、クライアントの予期せぬ切断を検知し、他のクライアントに通知するためのMQTTの機能です。クライアントは接続時にLWTメッセージを設定でき、正常に切断されずにタイムアウトした場合、ブローカーがこのメッセージを指定されたトピックにパブリッシュします。例えば、重要なセンサーデバイスが突然オフラインになった場合、LWTメッセージにより管理システムに即座に通知することができるんです。これにより、システムの異常を迅速に検知し、適切な対応を取ることが可能になります。LWT機能は、特に信頼性が重要なシステムで有用です。ただし、ネットワークの一時的な不具合でLWTが発動する可能性もあるため、適切なタイムアウト設定と再接続ロジックを組み合わせて使用することが重要ですね。

MQTTの今後の展望

標準化の進捗

MQTTの標準化は着実に進んでいます。現在、最新バージョンのMQTT 5.0が2019年に OASIS(Organization for the Advancement of Structured Information Standards)によって承認されています。この新バージョンでは、メッセージの有効期限設定、共有サブスクリプション、拡張認証機能など、多くの新機能が追加されました。例えば、メッセージの有効期限設定により、古くなったデータを自動的に破棄できるようになり、リアルタイムデータの扱いがより柔軟になったんです。標準化の進展により、異なるベンダー間の相互運用性が向上し、MQTTの採用がさらに加速すると予想されます。今後も、IoTやエッジコンピューティングの発展に合わせて、標準化の取り組みが続けられるでしょう。MQTTの進化を見守るのは、とてもワクワクしますね。

新たな利用シーンと応用例

MQTTの活用領域は、今後さらに拡大していくと予想されます。例えば、自動運転車両でのデータ通信や、スマートシティのインフラ管理など、新たな分野での採用が期待されています。自動運転車両では、車両の状態や周囲の環境情報をリアルタイムで共有するのにMQTTが使用される可能性があります。また、ブロックチェーン技術とMQTTを組み合わせたIoTセキュリティソリューションの研究も進んでいます。これにより、デバイスの認証やデータの改ざん検知がより強固になる可能性があるんです。さらに、エッジコンピューティングの普及に伴い、MQTTがエッジデバイスとクラウドの間の効率的なデータ転送に活用されるケースも増えていくでしょう。MQTTの軽量性と柔軟性が、これらの新しい技術トレンドと相性が良いんですよ。今後のMQTTの進化と、それによって実現される新たなサービスや製品に、大いに期待が持てますね。

エンジニア・PdMの正社員転職プラットフォーム「Offers(オファーズ)」では、非公開求人を含む豊富なIT・Web業界の転職情報を提供しています。高年収の求人や最新技術スタックを扱う企業など、あなたのスキルを最大限に活かせるポジションが見つかります。専任のキャリアアドバイザーが、入社日調整や条件交渉をきめ細かくサポート。正社員の転職をお考えの方は、Offersまでご相談ください。

閉じる

新着求人
もっと見る
おすすめのイベント
もっと見る
  • 【Claude Code】鹿野さんが実践するエンジニアの日常業務を爆速にする最新推しツール 大公開

    開催前

    【Claude Code】鹿野さんが実践するエンジニアの日常業務を爆速にする最新推しツール 大公開

    AIコーディングエージェントの普及により、エンジニアがAIで「コードを書く」ことは当たり前になってきました。しかし、「開発以外の日常業務」には、まだAIを十分に活用しきれていないケースが少なくないのではないでしょうか。 そこで本イベントでは、前回の並行開発イベントでもご好評いただいた鹿野壮氏を再びお迎えし、鹿野氏の日常業務のフロー全体、およびそれぞれの業務におけるAI活用の実例をデモ付きで解説いただきます。 前半のLTでは、鹿野氏より仕様策定→要件定義→チケット作成→実装→PR作成・レビュー→リリース→顧客説明といった業務の流れをお話しいただきます。続く公開デモでは、その業務フローに沿って実際にどのようなツールをどう使っているのかを画面を見せながら解説いただきます。 後半のディスカッションでは、業務のボトルネックや手戻りを減らす工夫、成果物評価の迅速化、チームへの展開方法など、現場目線でさらに深掘りしていきます。 AIを使った業務効率化に取り組みたいが全体像がつかめていない方から、すでに部分的に活用しているがさらに広げたい方まで、幅広いエンジニアのご参加をお待ちしています。

  • AIに任せる前にCloudflare Workersのクセを知る!設計思想から学ぶ本番運用の勘所

    開催前

    AIに任せる前にCloudflare Workersのクセを知る!設計思想から学ぶ本番運用の勘所

    昨今、CloudflareはCDNやR2だけでなく、Cloudflare Workersを中心に、エッジ環境でWebアプリケーションやAIワークロードを実行できるプラットフォームとして急速に存在感を高めています。個人開発で触ったことのある方は増えてきましたが、「プロダクションで本格的に使っている」となると、まだまだ少ないのが現状ではないでしょうか。 また、AWSやGCPとは設計思想や開発体験が大きく異なるため、「興味はあるが、既存のインフラにどう導入すればいいのかわからない」「Workersで何がどこまでできるのかイメージしきれない」という声も耳にします。 そこで本イベントでは、Honoの作者でありCloudflareのDeveloper AdvocateであるYusuke Wada氏と、『Cloudflare Workers 実践ガイド』の著者の一人であるchimame氏をお迎えし、Cloudflare Workersの全体像から実践的なユースケースまでを紐解きます。 Cloudflareが気になり始めた方から、AWS/GCPメインの環境にCloudflareを取り入れたい方まで、幅広いエンジニアのご参加をお待ちしています。

  • 人間のレビューなしで"そのまま出せる"デザインは作れるか こぎそさんに聞く デザインハーネスの現在地

    アーカイブ公開中

    人間のレビューなしで"そのまま出せる"デザインは作れるか こぎそさんに聞く デザインハーネスの現在地

    AIコーディングエージェントの進化により、コードだけでなくUIデザインの領域でもAIに任せられる範囲が広がりつつあります。しかし、「AIが出力したデザインを人間のレビューなしでそのまま出せるか?」と問われると、まだ自信を持ってイエスと言える方は少ないのではないでしょうか。 そうした中、AIに「デザイナーの脳内」を型として渡し、デザインの実装だけでなく、評価や改善までを自動化していく「デザインハーネス」という考え方があります。AIにデザインをつくらせて終わりではなく、その出力を評価し、改善するサイクルをできるだけ自律的に回していくことで、AIに任せられる範囲をさらに広げていくアプローチです。しかし、デザインハーネスとは具体的に何を整備すればいいのか、実際にどこまでの品質が出せるのかを体系的に語れる事例はまだ多くありません。そこで本イベントでは、デザインシステムの構築やAIワークフローの実践に豊富な経験を持つこぎそ氏をお迎えし、デザインハーネスの基礎から、具体的な実践事例までを紐解きます。 前半のLTでは、こぎそ氏よりデザインハーネスの基礎的な考え方を整理いただいた上で、Design.mdやMCP連携、デザインシステムとの接続といった実際のワークフローに落とし込んだ実践事例、そして「デザイナーの脳内をどう型化していくか」という方法論をお話しいただきます。 後半のディスカッションでは、AIが出力するデザインの評価軸や、人間が介在すべき領域の見極め、実作業のメイン環境の選び方など、デザインエンジニアの現場目線でさらに深掘りしていきます。 AIを活用したデザインワークフローに関心がある方から、デザインハーネスの導入を検討されている方まで、幅広いデザインエンジニアのご参加をお待ちしています。

    開催日:

    2026年10月15日(木)19:00~20:00

  • AIでコード書く前に、要求・要件定義足りてる?ミノ駆動さんと改めて考える ドメイン駆動設計

    アーカイブ公開中

    AIでコード書く前に、要求・要件定義足りてる?ミノ駆動さんと改めて考える ドメイン駆動設計

    AIコーディングエージェントの進化により、コードを書くスピードはかつてないほど速くなりました。しかし、いくらAIで早くたくさん開発できたとしても、初手の要求・要件定義が十分にできていなければ、結局は使われない機能を量産してしまうのではないでしょうか。 AI時代において、設計や実装の多くはAIに置き換わりつつあります。だからこそ、人間の価値は「問題を定義し、発見する」ことにシフトしていく——そう考えると、要求・要件定義の重要度はこれまで以上に増してきています。しかし、普段の業務で要求・要件定義に本格的に取り組んだ経験がないエンジニアの方も多いのが現状です。 そこで本イベントでは、前回ご好評いただいた「AI時代×ドメイン駆動設計」に続く第2弾として、ミノ駆動氏を再びお迎えし、AI時代だからこそ向き合うべき要求・要件定義の考え方と実践を紐解きます。 前半のLTでは、ミノ駆動氏より、エンジニアに今後求められる「具体→抽象」の思考力、目的を起点とした設計の考え方、そして明日から始められる要求・要件定義の第一歩についてお話しいただきます。 後半のディスカッションでは、「Claude Codeに頼めばよしなにやってくれるのでは?」という率直な疑問から、要求・要件定義は誰が書くべきか、優秀なエンジニアの要求・要件定義は何が違うのかなど、現場目線でさらに深掘りしていきます。 「AIにコードは任せられるようになったけど、その前段階をどうすればいいかわからない」という方にこそ参加いただきたいイベントです。

    開催日:

    2026年10月6日(火)19:00~20:00

  • 【Claude Code】世界のスタートアップが必死に求める「GTMエンジニア」とは

    アーカイブ公開中

    【Claude Code】世界のスタートアップが必死に求める「GTMエンジニア」とは

    AIの進化によってプロダクト開発のハードルが下がった今、企業の関心は「いかに良いものを作るか」から「どうやって市場に届け、ユーザーに使ってもらうか(Go-To-Market)」へとシフトしています。 こうした変化の中で、海外のAIスタートアップを中心に急速に注目を集めているのが「GTM(Go-To-Market)エンジニア」です。 営業でも、マーケターでも、単なる開発エンジニアでもない。 かつて10人のチームで回していた営業・マーケティング・オペレーションの設計からAIによる自動化までを、1人で主導する新たな役割です。 しかし、日本ではまだ認知が広まっておらず、「GTMエンジニアって具体的に何をしているのか」をイメージできている方はほとんどいないのが現状です。 そこで本イベントでは、GTMエンジニアリングの研究・発信を行う中村氏と、GTMエンジニアとして実践されているnumashi氏をお迎えし、海外での動向から日本での実態まで、GTMエンジニアという仕事の全体像を紐解きます。 前半のLTでは、お二人にそれぞれの視点からGTMエンジニアの役割や実際の業務内容、海外と日本での位置づけの違いについてお話しいただきます。 後半のディスカッションでは、どんな方がGTMエンジニアに向いているのか、単なる効率化で終わらせず売上に繋げるには、日本の組織での最初の一歩など、現場目線でさらに深掘りしていきます。 エンジニアとしての新たなキャリアの可能性を探している方から、GTMエンジニアリングに興味がある方まで、幅広いご参加をお待ちしています。

    開催日:

    2026年9月29日(火)12:00~13:00

転職に役立つノウハウ
もっと見る
  1. HOME>
  2. 開発言語・フレームワークから求人を探す>
  3. MQTT
職種
ポジション
開発言語・フレームワーク
勤務地
給与
出社頻度
無料登録して求人を見る