
ハッカソン
ハッカソンとは、新しい技術製品やソリューションを構築するために人々が集まり、定められた期間で行われる共同イベントです。ハッカソンという言葉は、「hack(ハック)」と「marathon(マラソン)」という言葉の合成語です。ハッカソンの目的は、多様な背景や異なるスキルを持つ人々が集まり、革新的なものを作り上げることにあります。
ハッカソンは主にソフトウェア開発に焦点を当てることが多いですが、ハードウェアや他の種類のプロジェクトが含まれることもあります。参加者はチームに分かれて作業を行い、特定のテーマや問題を与えられることもあれば、自由な課題に取り組むこともあります。参加者は、使用が許可されたAPIやデータセットなどの技術的なリソースにアクセスし、その分野の専門家から指導を受けたり、フィードバックを受けたりする場合もあります。
ハッカソンは企業、大学、非営利団体など様々な組織によって開催され、小規模で参加者を限定したイベントから、数百人または数千人の参加者による大規模な集まりまで、さまざまな種類があります。ハッカソンではプロトタイプの作成、新しいビジネスプランの開発といったアウトプットが期待される場合もありますが、単にコラボレーション、交流、新しいスキルを学ぶ機会であったりもします。
ハッカソンは、人々が集まって共通の興味ある課題に取り組み、新しいテクノロジーソリューションを生み出す、とても楽しい機会です。
イベント
マガジン
技術ブログ
オランダに住んでいる私は、電車で過ごす時間がかなり多く、たいていその時間を使って、ビルダーコミュニティが発信している内容をチェックしています。これまでは、そのためにノートパソコンを開いたり、スマートフォンでブラウザタブを操作したりする必要がありました。2026 年 9 月 21 日週、遅れている電車を待っている間に、AWS Builder Center のモバイルアプリでトレンド記事をスクロールしたり、ワークショップを確認したりしていました。そのおかげで、空いた 20 分間をとても有効に活用できました。そこで今週は、まず Builder Center モバイルアプリをご紹介できることをうれしく思います。 AWS Builder Center が iOS と Android のモバイルアプリとして利用できるようになり 、デスクトップやウェブ以外にもエクスペリエンスが拡張されました。AWS Builder ID を使用すると、サインインした状態を複数のセッションで維持しながら、トレンド記事の閲覧、600 以上の AWS Skill Builder コースへのアクセス、無料のサンドボックス環境を使ったハンズオンワークショップの管理を、モバイルデバイスから行えます。AWS Heroes、Community Builders、User Group Leaders をフォローしたり、外出先から Builder Loft のイベントカレンダーを確認したり、購読しているトピックやコミュニティのプッシュ通知を受け取ったりすることもできます。また、このアプリは Wishlist 機能にも対応しており、製品に関するフィードバックを AWS チームへ直接送信できます。Apple App Store および Google Play Store で世界中から利用できます。 Builder Center には今週、さらに 2 つの機能が追加されました。 Polls を使うと、ホームフィードからコミュニティに質問できます。質問を入力し、2~5 個の回答候補を追加して、期限を設定すると、ユーザーが投票できます。結果は随時更新され、コメント欄で議論することもできます。投票は匿名で、作成者には集計された数とパーセンテージのみが表示されます。一方、 Zero to Shipped ハッカソンは、9 月 18 日から 10 月 2 日まで開催されています。コーディングエージェントを AWS に接続し、実際に動作するアプリケーションを構築して AWS 上で公開すると、総額 28,000 ドルの賞金プールの一部を獲得できるチャンスがあります。受賞する 5 つのプロジェクトには、それぞれ 5,000 ドル分の AWS クレジットと AWS Builder のグッズセットが贈られます。 9 月 14 日週のローンチ 9 月 21 日週は、このほかにも次のような発表がありました。 Amazon Connect Talent が一般提供を開始しました 。Amazon Connect Talent は、大規模な採用活動を行う人材獲得チーム向けの、AI を活用した採用ソリューションです。Amazon が長年培ってきた採用ノウハウを基盤としており、AI エージェントを使って構造化された音声面接を実施し、エビデンスに基づく評価を行い、候補者を一貫した基準でスコアリングします。これにより、採用担当者は最終判断に集中できます。候補者は、どのデバイスからでも 24 時間 365 日面接を受けることができ、採用担当者はスコア、文字起こし、詳細な評価結果を翌朝確認できます。AI による評価中は、候補者のすべてのデータが匿名化されます。また、各コンピテンシーは評価基準に基づいて採点され、すべてのスコアは面接中の具体的な根拠と紐付けられます。さらに、採用担当者はすべての採用について最終的な意思決定権を維持します。一般提供版には、コンピテンシーに基づく評価、適応型の質問を行う AI 主導の音声面接、ブランドに合わせてカスタマイズ可能なモバイルファーストの候補者ポータル、管理者向けオンボーディングツールが含まれています。 Amazon Corretto 27 が一般提供を開始しました 。Amazon Corretto 27 は、無償かつマルチプラットフォーム対応の OpenJDK ディストリビューションの Feature Release 版で、Linux、Windows、macOS 上でダウンロードして利用できます。サポートは 2027 年 4 月まで提供されます。主な機能として、すべての環境で G1 がデフォルトのガベージコレクターとして採用されたこと(JEP 523)、TLS 1.3 向けの耐量子ハイブリッド鍵交換(JEP 527)、より小さいメモリフットプリントを実現するコンパクトなオブジェクトヘッダー(JEP 534)、さらに Java Flight Recorder の記録データが JVM 外に出る前に機密情報を削除する、JFR のプロセス内データ編集機能(JEP 536)などがあります。また、強化されたパターンマッチング、構造化並行処理、遅延定数のプレビューも継続されており、Vector API のインキュベーター版も含まれています。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供を開始しました。Kimi K3 は、コーディングおよびナレッジワーク向けに Amazon Bedrock で利用できるようになりました。 。Moonshot AI によると、Kimi K3 は同社で最も高性能なモデルであり、2.8 兆パラメータ規模に到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模なリポジトリを対象とする長時間のコーディングセッション、複数ドキュメントの分析、拡張エージェント型ワークフローに適しています。Moonshot AI は、Kimi K2 と比較してスケーリング効率が約 2.5 倍向上したとしています。Kimi K3 は、Amazon Bedrock 上のオープンウェイトモデルとして初めて明示的なプロンプトキャッシュをサポートしており、コンテキストを複数のモデル呼び出しで再利用する際のレイテンシーと入力コストの削減に役立ちます。 AWS は利用開始時のエクスペリエンスを刷新しました 。新しいプロジェクトを開始するビルダー向けに、よりシンプルな新しい体験を発表しました。最初に設定作業をすべて完了するのではなく、適切なデフォルト設定ですぐに開始できます。Google、GitHub、Apple などの既存の ID プロバイダーを使用してサインアップでき、多くの新規ユーザーではクレジットカードも不要です。また、AWS Free Tier の一環として 100 ドル分の無料クレジットが提供されます。AWS は作業を「プロジェクト」単位で整理します。プロジェクトには AWS アカウントと共有設定が含まれ、セキュリティ管理も AWS 側で適用されます。チームメンバーを招待できます。IAM ユーザーを設定する必要はありません。月間利用上限額は 20 ドルから設定でき、後から高度な AWS 機能を追加費用なし、かつ移行作業なしで有効化できます。このエクスペリエンスは、徐々に新しいお客様にも展開されています。 新しい低コストで耐久性に優れた Amazon EC2 T8i インスタンスが一般提供を開始しました 。Amazon EC2 T8i インスタンスは、Intel Xeon Scalable プロセッサ(Granite Rapids)を搭載しており、EC2 インスタンスの中でも特に低コストな選択肢の1つです。前世代の T3 インスタンスと比較して、最大 30 %優れたコストパフォーマンスを提供します。マイクロサービス、低トラフィックの Web サイト、開発・テスト環境、小規模なデータベースなど、CPU 使用率が低~中程度のワークロード向けに設計されています。T8i インスタンスは、T3 と比較してコンピューティング性能が最大 70 %向上し、ネットワーク帯域幅が最大 1.25 倍、Amazon EBS 帯域幅が最大 2.4 倍向上しています。また、同じ CPU クレジットシステムを使用しているため、T3 からのアップグレードも容易です。 AWS Elastic Beanstalk に Cluster Mode が導入されました 。AWS Elastic Beanstalk Cluster Mode は、Amazon EKS を基盤とする共有インフラストラクチャ上で複数のアプリケーションを運用するチーム向けの、新しいフルマネージドオプションです。各アプリケーションを個別に運用するのではなく、単一の運用基盤上で複数のアプリケーションを実行できます。これにより、アプリケーションの数が増えるにつれて、アプリケーションあたりのコストを削減できます。Java、.NET、Python、Node.js、PHP、Ruby、Go のソースコードをアップロードでき、Elastic Beanstalk がコンテナ化を自動的に処理します。また、必要に応じて Cloud Native Buildpacks も利用できます。Cluster Mode には、自動ロールバックを備えた本番環境向けのデプロイ戦略、イベント駆動型のオートスケーリング、AWS Secrets Manager との統合、ネイティブな OpenTelemetry オブザーバビリティ、AI を活用したトラブルシューティングが含まれています。Standard Mode と Cluster Mode の環境は、同じアプリケーション内で並行して実行できるため、チームは環境を1つずつ段階的に移行できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS European Sovereign Cloud での構築 — 2つの新しい記事では、AWS European Sovereign Cloud 上での構築について紹介しています。これは、独自のコントロールプレーン、IAM、請求、コンソール、サービスエンドポイントを備え、独立したパーティションとして運用される欧州向けの独立したクラウドです。最初のリージョンはドイツ・ブランデンブルクに開設されます。最初の投稿では、アカウント構造とガバナンス、コードとしてのインフラストラクチャとしてのアイデンティティ、集中ロギング、データ保護、AWSパーティション全体で機能するパーティション対応ARNの構築など、 安全なランディングゾーンの設計について説明します 。2つ目は、AWS European Sovereign CloudのAmazon Bedrock次世代推論エンジンでGemma 4オープンウェイトモデルが一般公開されたことを発表しました 。データ保持やオペレーターアクセスゼロのモデルでは、推論は完全にeusc-de-east-1の範囲内にとどまります。 新しい AgentCore ランタイム:伸縮性に優れ、最適化され、一貫して高速な起動 — エージェントを実行するためのマネージドコンピューティングレイヤーである Amazon Bedrock AgentCore ランタイムの新バージョンを発表しました。新しいランタイムでは、セッション中のピーク時のメモリ量を保持し続けるのではなく、セッションがメモリを解放するとその分を回収します。そのため、料金はセッション全体を通じた実際の使用量に基づいて計算されます。また、コンテナイメージのサイズや同時実行数に関係なく、一貫したコールドスタート時間を実現します。これは、環境を一度準備してスナップショットを取得し、新しいインスタンスごとにそのスナップショットを復元することで実現しています。空のエコーエージェントを使ったテストでは、新しいランタイムは 200 MB のイメージから最大 2 GB までの約 2 秒で P75 コールドスタートを実現しました。これに対し、元のランタイムでは約 5.4 秒から 30 秒かかりました。 更新された AWS Well-Architected ストリーミングメディアレンズの紹介 — 動画ストリーミングワークロードのアーキテクチャのベストプラクティスを提供する改訂版ストリーミングメディアレンズを公開しました 。今回の改訂では、2021 年の初版から対象範囲が拡大され、5つのストリーミングシナリオをカバーしています。これには、Amazon IVS を使ったインタラクティブライブストリーミング、最大 25,000 人の同時視聴者に対応するリアルタイムストリーミング、低遅延ライブストリーミング、広告対応コンテンツの収益化、さらに強化されたビデオオンデマンドおよびライブストリーミングのガイダンスが含まれます。また、カーボンフットプリントの削減に重点を置いた新しいサステナビリティのベストプラクティス、拡張されたオブザーバビリティおよびインシデント対応フレームワーク、多層 DRM とフォレンジックウォーターマーキングを活用した高度なコンテンツ保護も追加されています。レンズホワイトペーパーとカスタムレンズがご利用いただけるようになりました。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re: Invent — AWS re: Invent が 11 月 30 日から 12 月 4 日までラスベガスに戻ります。2, 200 以上のセッション時間、ロケーション、講演者がライブ配信されます。AWS re: Invent の指定席は 10 月 6 日にオープンします。 今すぐ登録して 、指定席が開いたら、チョークトーク、ワークショップ、ビルダーズセッションに参加する準備をしてください。 AWS Summits – AWS Summits は、クラウドと AI をカバーする無料の実地イベントです。re: Inventが間近に迫った今、今年のサミットは終わりに近づいています。 最後のサミットはドバイ (9月30日)にドバイワールドトレードセンターで開催され、60以上のセッション、AWSビレッジ、ハンズオンワークショップが行われます。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 レバノン (9月26日)、 マレーシア、クアラルンプール (9月26日)、 フィリピンのセブ(9月26日)、フィリピンのダバオ (9月26日)、 英国のコムサム・マンチェスター(10月1日)、 イタリア、ローマ (10月2日)などがあります。 夏は正式に終わり、9 月を迎えましたが、私のいる場所では、まだ天候が季節の移り変わりに追いついていないようです。日中は今でも例年になく暖かく、本格的な秋が訪れる前の、最後の穏やかな午後なのではないかと思っています。この陽気が続いているうちに、できるだけ満喫しようと思います。9 月 28 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。
はじめに タイミーでは、世界中で開催される技術系カンファレンスの参加を支援する「Kaigi Pass」という制度があります。今回は、2026年9月5日(土)に中野セントラルパークカンファレンスにて行われた、Product Engineering Conference 2026に5名が現地参加してきました。 本レポートでは、参加したエンジニアが注目したセッションごとに、参加者自身の視点で学びや気づきをまとめました。読者の皆様にとって、今後の学びの参考になれば幸いです。 営業・CSを「開発の当事者」にする — 少人数チームで複数プロダクトを動かすDev<>Ops連携の方法 speakerdeck.com こちらのセッションは、estieの山本龍平さん・北村大助さんによる、少人数で複数プロダクトを動かすなかで、営業・CSがプロダクト開発の当事者になる取り組みについての共同発表でした。 Ops(営業やCS)は、要望をDev(開発)に渡して実装を待たない。AIでモックを作り顧客に当て、課題と解決策の仮説を磨き込んでからDevに渡す。現場に近いOpsが仮説検証を一定担うことで、質と速度を上げる、というのが主題でした。 印象的だったのは、Opsの北村さんの話です。小さく早く検証することを前提に、動くものを用意して顧客とのコミュニケーションコストを下げ、検証精度を上げていることでした。 仮説検証はDevの役割だと思い込んでいた私にとって、Opsが回せるよう検証環境で支えるという体制は、前提を覆される話でした。また、仮説検証に対する「小さく、早く」といった姿勢をどのようにOpsに共有しているのかという疑問が浮かびました。 そういったプロダクト開発に対する理解向上の取り組みとして タッグ開発 Night が紹介されていました。社内のハッカソンに近いイベントで、Opsが顧客要望をもとにAIでプルリクエスト(PR)を出す。仮説を試す部分をDevと進める場でした。 このほか、 Preview環境でPRごとに専用DBを用意する取り組み など、Opsの越境を助ける具体事例も紹介されていました。自社でも、まずは「動くものを顧客に当ててからDevに渡す」ところから試せそうです。自身の役割を越境するだけでなく、担当領域への越境を助ける環境づくりまで含めて、組織としてプロダクト開発を進める視点を得た発表でした。 津守( @ytsumori59 ) エンジニアリングは、どこまで拡大解釈できるか 心技体をつないだままで事業責任者になった話 speakerdeck.com 柳川さんのセッションでは、エンジニアリングを「責任を引き受ける営み」として捉え、技術の実装にとどまらず、プロダクトのアウトカムまで責任範囲を広げる考え方が語られていました。 責任範囲を広げる鍵として示されたのが、責任を負う実感(心)、スキル(技)、現場感覚(体)です。3要素を切り離さずに育てることが重要だと、私は受け取りました。 AIはスキルを伸ばす助けになります。一方、責任を引き受ける実感は、組織環境にも左右されます。そのため、個人プロダクトのリリースなど、社外で自ら意思決定と結果を引き受ける経験も有用だと提示されていました。 技術や知識の活用をAIが支援する範囲は、今後さらに広がっていきます。だからこそ、アウトカムに責任を持つ姿勢の重要性は増すのではないかと感じました。 私は、「プロダクトエンジニア」という言葉には、アウトカムへコミットする姿勢が含まれると考えています。その延長線上に事業責任者という役割がある、という捉え方には納得感がありました。 この話を聞き、仕事で大切にしている「ジブンゴト」という言葉を思い出しました。物事を自分の責任として捉え、行動する姿勢です。今回のテーマにも通じると感じました。 発表では、「エンジニアは元来ラストマンである」という問いかけもありました。ここでいう「ラストマン」とは、成果物の最終責任を引き受ける立場を指します。また、組織の中に暗黙的な親子関係が生まれる、という経営学的な視点も印象に残りました。 AIが成果物の生成を支援する範囲が広がるほど、最終的な責任を誰が担うのかを意識する必要があります。自分はどこまで責任を引き受けるのか。改めて考える機会になりました。 また、また、柳川さんの発表そのものも素晴らしいものでした。「責任」を起点に話を展開し、帰納的にセッションのテーマへ収束させる構成や、洗練された言葉選びが強く印象に残りました。 これまで聴講したセッションの中でも、特に心を動かされました。エンジニアとして、職業人として、こんなふうに生きたいと思わせてくれるセッションでした。 志賀( @akitoshiga ) その機能が使われないのは、業務の捉え方を間違えたから?─プロダクトエンジニアのメタモデル設計論 特に印象に残ったのは、機能をリリースするというアウトプットがあっても、顧客の業務が良くなるというアウトカムにはつながらないことがある、という話です。その原因が機能の不足ではなく、そもそもの業務の捉え方にあったという点が、日々の開発を振り返るきっかけになりました。 このセッションで紹介されたのが、業務をどのような概念や関係性で捉えるかという「メタモデル」の考え方です。その土台には、一次情報から業務の流れを理解することがあります。データがどう移動するかに加えて、誰が何を判断し、どのように仕事を進めているのかを捉える。現場を観察し、可能であれば体験し、専門家との対話で判断の背景を確かめる。業務モデルは会議室の議論だけでは完成しない、という話が心に残っています。 業務の中心となる概念を見極める観点も参考になりました。例えば契約であれば、さまざまな処理の軸に、顧客と交わした約束があります。個々の処理やデータ項目を整理するだけでなく、それらが何を軸につながっているのかを考えることが、モデルの土台になるのだと受け取りました。 また、良い業務モデルは、顧客が業務の進め方を組み立て、運用する負担を吸収するという話もありました。柔軟な機能を用意しても、その組み合わせや使い分けを顧客が一から考える必要があれば、負担は残ります。業務理解をモデルに反映することは、コードの構造だけでなく、顧客がどれだけ無理なく使えるかにも関わるのだと思いました。 ここからは、タイミーの身近な機能を題材に、この考え方を自分なりに当てはめてみます。 例えば求人を公開する際には、募集人数が定員に達していない場合に、設定に応じて公開範囲を自動で広げる仕組みがあります。詳しくは、 求人の公開範囲 についてをご覧ください。 この仕組みを単なる機能拡張ではなく「業務の流れ」として捉え直してみます。すると、応募状況や残り時間を踏まえて「どのタイミングで求人を届ける相手を広げるか」という事業者の判断を支えていることが見えてきます。 言われてみれば当然のことですが、日々の開発に追われているとつい見落としがちな視点です。機能が裏で支えている判断や作業にまで解像度を戻してこそ、本質的な設計や検証ができるのだと改めてハッとさせられました。 効果を確かめる際も、自動で公開範囲が広がったかというシステム挙動だけでなく、事業者様の手間が減り必要な人数の確保につながったかを見る必要があると思います。同時に、ワーカーさんにとっても希望や条件に合う仕事との出会いにつながったかも重要です。「募集が埋まる」という数値だけでなく、その先の就業が双方の期待に沿う体験になったかまで視野を広げることが、まさにセッションで聞いた「業務を捉える」ということなのだと感じました。今後の自分の開発でも、この視点を忘れずに向き合っていきたいです。 細野 越境負債:称賛されるほど、負債は返済されない 「越境をしても、越境が必要になってしまう状況そのものは越境では改善されない」という内容。越境が越えている境界を組織のそれであるとし、プロダクトの価値最大化のために越境は必要だが、一方でそういう境界を最適化する手法として組織再編を挙げていた。つまり、プロダクト価値の創出のために越境が必要だという状況は、組織の境界が最適でないということを意味する。もちろん越境は組織再編行為ではないため、最適でない状況そのものは、越境では改善されない。 たしかにそういう状況ならそう言えるかもしれない。組織の境界を越える行為を越境と呼ぶならば、組織再編が根本解決手段の一つであり得る。またそれを役割の境界であるとするなら、職務記述やロールの定義を更新すべきなのかもしれない。 ただどうしても、境界があれば越境が可能になる。境界を意識させないために私達は、これまでにも「何でも屋」、「遊撃部隊」、「フルスタックエンジニア」、「FDE」などを生み出してきた。実際のところ何でもできる人の手が空いているのなら何でも幅広く任せるほうが、少なくとも短期的なプロダクト価値の最大化にとっては最適だと言える。境界がある限り、越えたくなる。そして価値を創出している限り、越境は称賛されなければならない。 個人的には、どこかに線を引く限り越境はなくならないと思うし、それは称賛されるべきだとも思う。 口藏( @mizunokura ) おわりに Product Engineering Conferenceは初開催ながら、多くの参加者が集まり、皆さんのプロダクトエンジニアリングに対する熱量を感じました。 各セッションを通じて、プロダクトエンジニアリングについて改めて考える機会になりました。今回得た学びはタイミーでのプロダクト開発にも活かしていきたいと思います。 次回の開催については未定とのことですが、開催される際はぜひ次回も参加したいと思います。















