デベロップメントオンラインゲーム開発に最適なプログラミング言語は何か?最近のゲーム開発者は、ゲームをより分かりやすく、魅力的なものにすることに注力しています。そのためには、最適なプログラミング言語を選択するという問題が生じます。すべての要件を満足する言語を選ぶのは簡単ではありませんが、JavaScriptのようなリーダに頼ることは可能です。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Jeffさん、インタビューの時間を頂いて、ありがとうございます。あなたの活動やScrum@Scaleの状況を拝見していますが、世界中で採用されている公認トレーナプログラムのセットアップで多忙を極めているようにお見受けします。Allianceのリーダが私たちに、スクラムをスケールアップするためのフレームワーク開発に協力してほしい、と依頼してきたのです。当時の私たちは、スクラムチームの人たちだけでなく、ビジネスや役員にとっても有用なフレームワークを求めていました。Allianceが考えていたような、組織的なビジネスアジリティをサポートするものはありませんでした。彼らはまた、このスケールアップモデルを、人々がコントリビューションし、フィードバックやケーススタディの共有を通じて発展できるようなものにしたい、と思っていました。スクラム自体がそうであるように、このスケーリングフレームワークをオープンソースにしたいとも考えていました。Allianceのリーダと交渉して、2018年の初め、トレーニングの提供とインストラクタの認証を行うジョイントベンチャのScrum@Scaleを設立し、活動を開始しました。私は、Scrum@Scaleコンテントのチーフプロダクトオーナをしています。基本的には、インストラクタをトレーニングするためのカリキュラムの監督や開発、Scrum@Scaleガイドのコンテンツの作成などが仕事です。世界中でScrum@Scale実践家のトレーニングを提供しながら、新たなScrum@Scaleインストラクタのための"トレーナのトレーニング"全般をサポートしてきました。現在では、世界中に約100名の認定トレーナを擁しています。Masterコースの提供もしています。講演の誘いもありますし、研究や論文の執筆も続けています。私たちは、新たに2冊の本も書いています。Fieldbook"のレビューをしているところです。Sutherlandの手によるもので、企業の役員や大規模組織がスクラムにアプローチする方法や、組織全体にスクラムを展開する方法を考える上で役立つことを目的にしています。現在は予約注文を受付中で、10月に出版される予定です。Time"の続編になるもので、人々や組織がフレームワークを適用し、実験する方法について、たくさんのケーススタディを紹介しています。Patternsの書籍化に取り組んできました。この本は最終編集中で、2019年の夏か秋には出版する予定です。スクラムパターンは非常に重要です。ハイパフォーマンスなスクラムを実現するには、スケールアップに取り掛かる前に、チームレベルで推奨パターンを実装する必要がある、ということが分かったからです。デイリースタンドアップイベントのような、いくつかのプラクティスをつまみ食いしようとしても、それではうまくいきません。推奨パターンをすべて実践できなければ、スクラムのすべてのメリットを得ることはできないのです。私たちは何年もの間、私たちのコースでそのパターンを教えてきました、その一部がドキュメント化された書籍が出版されるというのは、大変うれしいことです。これは重要な成果であって、スクラムとScrum@Scaleの採用を成功させる手助けとなることでしょう。Sutherlandさん、それは素晴らしいですね。どちらの本も、読むのが楽しみでなりません!あなた方はオープンソースを活用して、Scrum@Scaleガイドを一般公開するだけでなく、誰でもGitHubでフィードバックや改善提案を返すことができるようにしていますね。Scrum@Scaleサイトには、トレーニングされたプロフェッショナルによるケーススタディが数多く含まれています。トレーナやコーチが無償でアドバイスしたり、質問に答えたりする、グローバルな仮想Scrum@Scaleプラクティスコミュニティの構築にも成功していますし、Slackチャネルも一般公開されています。最初に、オープンソースにした理由を説明しましょう。Schwaberと私は、スクラムを正式なものにしました。私はそれを、無償でオープンソースにしたいと思っていました。世界中に早く広めたかったのです。これがスクラムで非常にうまくいったので、Scrum@Scaleでもこのモデルを拡大し、改善することにしたのです。実践者が認定トレーナになるためには、ケーススタディを提出して、それをオープンソースにする意思を持っていることが必要です。すべてがWebサイトで公開されている訳ではなく、準備中のものもありますが。1,000件のケーススタディが掲載されれば、さまざまな人たちや組織がScrum@Scaleを、自身の文化や組織に合わせてカスタマイズし、実装した様子がすべて分かるようになります。スクラムと同じく、規範的なモデルというものはありません。フレームワークには適用能力があって、組織による調整の繰り返しを支援しています。さまざまなケーススタディを、私たちのサイトを通じて紹介したいと思っています。既存のほとんどのスケーリングフレームワークと比べた場合、これが大きな違いです。仮想コーチングセッションでも、フォーラムを提供しています。誰でも質問が可能で、課題を共有し、ベストプラクティスをすぐに手に入れられるような、コミュニティが作り上げられているのです。私が間違っていなければ、あなたは2014年にScrum@Scaleのデザインに着手して、最初のロールアウトを行いました。その後、2018年5月になって、Guideの最初のイテレーションを、Scrum@ScaleのWebサイトでリリースしています。フレームワークの正式版を書き始めて、2014年に、Scrum@Scaleトレーニングのロールアウトを開始しました。既存のスケーリングフレームワークでハイパフォーマンスなチームを手にすることができなかった多くの人たちが、Scrum@Scaleを使ってハイパフォーマンスを何度も実現した方法を文書化するように、私に求めてきました。"Sutherlandさん、あなたのやったことを文書にしてくれませんか。"そこで私は、Scrum@Scaleで実践した、最初の実装と最初のプロトタイピングに立ち返ることにしました。これは1983年に、米国とカナダで150の銀行を運営する、ある大規模な金融企業で行われたものです。私はそこのCTOで、先進システムを担当するVPでした。最初は数名のリーダクラスのメンバによる自主的参加で始まって、スクラムプラクティスを使った別の運用モデルを採用していました。私は役員に、最も収益の大きいビジネスユニットを選択して、スクラム実践のテストをするように提案しました。最初はセールスやマーケティング、サポート、導入、開発といったATM関連の部署全体を対象に、アジャイルバブルを発生させたのですが、それがよく機能して、成果をあげることができました。スプリント計画ミーティングを毎週実施して、プロダクトマネージャとチームが顔を合わせて、プロダクトバックログの優先順位の設定や、デリバリを完全化するための組織的な障害への対処を行いました。その結果、開発中の機能を毎週金曜日にデプロイできるようになったのです。スクラムだけではなく、Scrum@Scaleのプロトタイプも実施した結果、6ヶ月を待たず、行内で最も収益性の高いビジネスユニットになりました。銀行側がそのビジネスユニットの拡大に対して2,000万ドルの投資を決定したので、Scrum@Scaleをもっと大規模にするための資金が生まれました。当時目にしたアンチパターンは、非アジャイルなビジネスユニットによる、ウォーターフォール型のリーダシップでした!彼らのプロジェクトはすべて遅延していました。それを修正するため、マネジメントはさらに多くの人材を無計画に投入し、日次や週次のステータスミーティングやレポートによる詳細な報告を要求しました。これらはただ、プロジェクトをさらに遅延させるだけだったのです。リーダーシップの状況は、現在でもあまり改善されていません。Gatheringで、200~300名の出席者に対して、"スクラムを実践しているが、マネジメントはウォーターフォール形式で行われている、という人はいますか?"と質問しました。すると、そこにいた人たちのほぼ100パーセントが手をあげたのです。今日に至るまで、私たちはこのアンチパターンを目の当たりにしている、ということです。マネージャやリーダは、一般的なウォーターフォール形式のレポートをすべて受け取りたいのです。それなのに彼らは、それをチームやアジリティとは隔離した形で、スケーリングフレームワークを採用します。この一般的状況は、人々や組織に多大な苦痛をもたらします。それこそが、最も普遍的なアンチパターンなのです。Scrum@Scaleは、このような状況を変えて、エンドツーエンドの変革において、リーダシップが積極的な役割を果たすようにデザインされています。今の話にもありましたが、大きな変革を妨げる最大の課題のひとつは、組織のリーダを参加させることです。リーダは関心を持っていますし、アジャイルのメリットを望んではいるのですが、それが自分たちのためだとは思っていません。彼らは、一般論として、よりアジャイルで機敏な組織になることよりも、アジャイルを実践すること自体に注目しています。考え方よりもテクニックを重視しているのです。最初に、役員に次のように話すのです。"皆さんはチームがアジャイルであることを望んでいますが、チームだけではうまくいきません。これは新しい話ではありません。過去60年間、ウォーターフォールの世界でプロジェクトが失敗を重ねてきた最も大きな理由は、組織の問題を是正する上で、幹部社員の協力が得られなかったことなのです。アジャイルプロジェクトでも、これと同じアンチパターンが発生しています。See"と呼ぶ活動のために、数人のコーチを派遣しています。昨年はToyotaのチームで、適切なアジャイル展開を行うことによって劇的な改善が見込まれるような、組織上の最大の問題を特定することができました。次に、特定したその問題を確認するために、カスタマイズされた役員向けワークショップを開催し、価値と影響の大きさによって優先順位を設定した上で、それらをアジャイルがどのように解決できるかを確認しました。リーダを含めた私たちチームは、変革のためのバックログとそれを実施するロードマップを作成して、最優先課題に取り組みました。続いて、パフォーマンスの高いスクラムバブルを数チームで立ち上げて、スケールアップ前にそれが有効であることをリーダに示すための、ある種の概念実証を行いました。Team"、つまりEATを導入しました。EATの大きな役割は、障害を食べる(eat)ことです。コミュニケーションの経路としての役割を担います。私たちの経験から言えるのは、初期段階から役員の関与を得ることが、変革を成功させる上で不可欠だ、ということです。開始した時点ですべてが必要な訳ではありませんが、組織内にアジャイルを導入することを確約し、実際に機能させる人、あるいは少数の人たちが必要なのです。それを望まないのであれば、ウォーターフォールに留まるべきです。アジャイルに移行したところで、大したメリットはないでしょう。さまざまなカンファレンスで、リーダやチームによる組織のリファクタリングという概念を発表されていますが、どちらについても、マネジメントの考え方を大きく変える必要があります。Scrum@Scaleによると、アジャイルかつ持続可能な組織は、"脆弱な(Fragile)"組織とは対照的に、トレーニングされたマネージャ、要するにリーダが、組織をリファクタすることになっています。"非脆弱(Anti-Fragile)"組織と呼ばれる、最高に成熟した組織では、組織をリファクタするのはチームの役割とされています。これについて、詳しく説明して頂けますか?アジャイルから"非脆弱"へはどうやって移行するのか、その大きな違いは何なのか、ひとつの状態から別の状態に移行するのには、どの程度の時間が必要なのか、といったことです。プロダクションのバックログに対する生産性を最大化するためには、チームのデリバリを迅速かつ容易にするような方法でチームを編成し、運営することが必要だ、という例を、これまでに何度となく見てきました。一例としてLEGOでは、大規模なプログラムを立ち上げて、チームの人選や構成の決定に6ヶ月を費やした後にスクラムを採用しましたが、うまく行きませんでした。Kniberg氏を招聘しました。氏はある朝、開発者全員をひとつの部屋に集めました。そこで、プロダクトオーナがバックログを提示して、全員に"チームはどうあるべきか"を問いました。数時間のうちに、全員が組織化のあるべき方法を考え出し、すぐに成果を上げることができたのです。必要なのは、適切なバックログを支える適切なチーム構成であり、適切なチームにおける適切な人たちなのです。チームはクロスファンクショナルで、可能な限り機能指向でなければなりません。そこから直接入力を得ることが、成功には欠かせないのです。ほとんどの組織では、従来のウォーターフォール型のマネジメントが、アジリティから自らの身を守る手段として、チーム構成やスケーリングフレームワークへのアプローチを決めています。組織をリファクタリングする目的は、組織を調整し、潜在的に再構築することによって、価値のフローを守り、組織的な債務を排除する作業を継続することにあるのです。"アジャイル成熟状態"のマネージャは、リーダと呼ばれるようになり、そしてプロダクトバックログに取り組むチームを、完全に自己組織化するようになります。リーダ(マネージャ)は、プロダクトの実現とビジネスのアジリティを最高の形でサポートするために、組織のリファクタリングを行う責務を担います。"非脆弱な成熟状態"では、チームが製品戦略を設定し、プロダクトの方向性を示し、価値のフローを最大化するために組織をリファクタします。リーダはチームの要請に応じて、継続的改善のサポートと実現を行います。このレベルにまで達した組織の数は、まだ多くありません。要約すると、私たちに必要なのは、初期バックログを作成し、そのバックログに沿ってチームを編成することです。それがScrum@Scaleの基本なのです。現在の目標は、大規模な組織において、半分の時間で2倍の価値を提供可能にすることです。そのためには、まずスクラムを適切に適用すること、次に大規模なデリバリが可能なように組織を編成すること、この2つが不可欠なのです。スケーラビリティの実現には、チームの数は問題ではありません。必要なのは、プロダクションを増やすことです。ウォーターフォールの世界では、チームに人を投入するほどスケジュールは遅延します。それはBrooksの法則であり、ウォーターフォールのアンチパターンです。このアンチパターンを回避するには、スケーラビリティを最大化するように、組織を再設計する必要があります。チームの人数が倍になれば、プロダクションも倍にならなくてはなりません。これは難しいことです。スクラムとScrum@Scaleは、ソフトウェア以外の開発産業にも適用できると言われています。ソフトウェア開発産業において、エンジニアリングプラクティスとしてのDevOpsとは、どのように統合されているのでしょうか。今日では、ほとんどの組織が、リリースインフラストラクチャのエンジニアリングの手段として、さらにはそれが提供する多くの文化的メリットを目的として、DevOpsを積極的に採用しています。1983年に立ち返ってみましょう。私が最初に、銀行でScrum@Scaleのプロトタイプを導入した頃です。当時の私たちは、毎週金曜日の午後に、実用的な機能をデリバリしていました。そのためには構築、テスト、さらにデプロイメントも自動化しなくてはなりませんでした。それは今日、私たちがDevOpsと呼んでいるものです。DevOpsとは、最終的には、構築、テスト、デプロイメントを通じて人が関与しない、という意味です。手作業によるプロセスの排除は、常にスクラムの大きな目標でもあります。スクラムの初期の段階から、それは変わっていません。1995年頃、私は、上場したばかりの企業で働いていました。そこで最初に行ったことのひとつは、毎週デプロイ可能なチームをセットアップすることでした。サーバをサーバルームから運び出して開発ルームに置き、継続的デプロイメントをサポートしたのです。DevOpsは常に、スクラムを支える思想全体の一部でありました。当時の私たちは、スクラムのフレームワークとプラクティスの形式化に取り組んでいました。それらのエンジニアリングプラクティスが、スクラムおよびスクラムガイドの定義の重要な部分になると考えていたのです。Beck氏が当時、私たちと一緒に仕事をしていました。Beck氏と私たちは、氏がエンジニアリングプラクティスを中心とし、私たちがチームやプロダクトバックログ、組織的プラクティスを中心とすることで同意していました。ProgrammingとDevOpsプラクティスが常に含まれていたのです。DevOpsは今日おもに、重要な概念のひとつであると理解されています。これはツールベンダが、構築、テスト、デプロイ、運用サポートを完全な自動化な達成に取り組んでいるためです。技術的な卓越性を実現するためには、チームはまずアジャイルでなければなりません。DevOpsはデプロイメントを自動化するツールですが、それによって実現される文化的なメリットの方が重要なのです。Projects"という記事を書いて、Scrum@Scaleと継続的デプロイメントについて説明しました。この記事は、継続的デプロイメントと運用サポートの自動化を公開した初めてのものです。Licensing、ExpediaのBookingデータエンジニアリングチームなど、いくつかの企業で、クロスドメインの複雑なアプリケーションやデータインテグレーションを毎日扱ってきたのですが、彼らはリリースパイプラインに投資するのではなく、自動化のスキルをほとんど、あるいはまったく持たない人材を採用したり、役割を複製してサイロ化したり、手作業をさらに増やすようなことを行っていました。リーダ層の抵抗、コミットメントやトレーニングの欠如については、これまでに話しました。ウォーターフォール組織のマネージメントは、リスクが高く失敗の多いウォーターフォールを長く実践してきたために、アジャイルがさらなるリスクになることを恐れているのです。アジャイルやDevOpsに関するトレーニングを受けていなかったり、論文を読んだことのないリーダは、適切に導入されたDevOpsやアジャイル転向が価値のフローと利益を増大し、欠陥を削減させるということが理解できません。アジャイルがリスクを大幅に低減することについては、広範な業界データが存在します。アジャイルの成果に関する研究出版物をひとつも読んだことのないリーダが存在するという事実は、世界的に、この業界の大きな機能不全なのです。第2の側面は、これが重要なのですが、自動化に関するものです。Rico氏が、構築からテスト、デプロイメントまでのパイプラインの自動化への投資に対する収益を示した、画期的な論文と書籍を発表しています。その中で氏は、投資収益率が72,000パーセントを越えることを証明しました。アジャイルはリスキーで、自動化にはコストが必要だと考えている経営陣は、社内のリリース技術やDevOps自動化に対して継続的な投資を行う企業によって、自らのビジネスを失うことになるでしょう。3,200のスクラムチームを擁して、3秒に1件異常の新機能を市場に提供しているAmazonは、自動化への1ドルの投資に対して72,000ドルの利益を得ているのです。この説明として、Amazonがドイツ国内でローンを提供し始めた時、ドイツ最大の銀行が、彼らに対抗することは不可能だ、この市場を諦めるしかない、と私に打ち明けたことがあります。"Amazonは数分でローンを処理することができる。数分でリスクを評価してローンを提供できるのだ。数週間を要していたのでは歯が立たない。"そこで、その大規模なレガシ企業の幹部たちは、目を覚まさなくてはなりません。なくば、彼らは"Uber"されるか、あるいは"Amazon"されることになるでしょう。UberやAmazonが市場を握ってしまえば、もはや取り戻すことはできないのです。Webサイトにあります。スマートホーム用IoTに特化したあるイタリア企業のケースでは、ローカルとリモート、3つの外部ベンダを合わせた複数のチームが、ハードウェアとソフトウェアとサプライヤの間の面倒な依存関係を廃城しながら、crum@Scaleを使ってスケールアップした様子が確認できます。約20回のスプリントを通じて、同社は、生産性を18倍に向上することができました。基本的にはScrum@Scaleの導入ですが、複数の組織にまたがっている点が特徴です。このすべてが、優れたスクラムをベースとした、組織レベルのScrum@Scaleによって推進されることで、プロダクトのより早い、より高品質で、より低いリスクでの提供という目標に、人々を集結させているのです。組織内でScrum@Scaleを実践し、フィードバックを集めることによって、リーダ、特に戦略や報告を推進する幹部層の、考え方やアプローチのあり方が大きく変わっていきます。数年前に、Ciscoの経営陣に会ったことがあります。同社のシリコンバレーの事業所には、約1,000のスクラムチームがありました。彼らはベロシティに関するデータを見せてくれましたが、どのチームも改善されていませんでした。私は彼らに、"Scrum@Scaleのデリバリが改善されていないのは、正しくスケールアップできていないから"だ、と言いました。経営陣はすぐに、いくつかの変更を決定しました。スクラムマスタ全員をトレーニングすること。次に、チームが継続的改善に投資していることを確認することです。最初の重要な指標は、チームのベロシティです。これは、どのように機能しているのか、プロセス改善とどのように結び付いているのか、どのように改善されているのかを知る上で重要です。私は自身の会社をスクラムで運営していますが、幸福感の指標を使っています。今の働き方について、皆が幸せだろうか?ベロシティが向上しても、幸福感が下がるようでは、結局は行き詰まってしまうのではないでしょうか。望んでいるのは、幸福感を高く保ちながら、ベロシティを改善することなのです。第3の指標は、非常に重要であり、かつ誰も注目していない、収益です。チームが大量のポイントを提供するのに対して、プロダクトオーナがポイント毎にどれだけの収益をあげられるのか。その数値を高くして、増加させたいのです。プロダクトオーナのパフォーマンスも測りたい部分です。チームがポイントを倍増し、プロダクトオーナがポイント当たりの収益を倍にすれば、収益は400パーセントになる計算だからです。efficiency)です。ベロシティの問題のひとつは、チーム間での比較ができないことです。私たちは昨年、Toyotaと仕事をしたので、同社が生産システムで使用している測定値をいくつか試してみることにしました。プロセス効率は、理想的な作業時間を実際の時間で割ったものです。理想的には1日でデリバリ可能な作業が、さまざまな待ち時間のため、完了までに20日を要したとしましょう。この場合のプロセス効率は、1日を20日で割った値、すなわち5パーセントになります。ほとんどのスクラムチームのプロセス効率は10パーセント未満です。Electricsのマネージャは、同社のプロセス効率が5パーセントであったということを、私たちに伝えてくれました。プロセス効率の数値を上げることができれば、生産性は飛躍的に向上します。プロセス効率の便利なところは、チーム間での比較が可能なことです。リーンの定義によれば、プロセス効率は最低でも25パーセントなくてはなりません。従ってほとんどのスクラムチームはリーンではない、ということになります。私は現在、チームレベルでクライアントと協力して、彼らのプロセス効率の解析と向上を支援しています。プロセス効率に注目することで、一部のチームは1回のスプリント内でその向上を実現しました。1スプリントでベロシティを倍増できたチームもあります。ベロシティ、幸福感、そして1ポイント単位の収益、あるいはプロダクトオーナに対する1ポイント単位の提供価値という、私たちがいつも使用している3つの指標を紹介しました。現在は特に、プロセス効率の向上に注目しています。Toyotaにおいて最高のチームが実現しているように、価値を提供するにはどうすればよいか、ということです。Sutherlandさん、あなたのアジャイル業界で達成した成果は、本当に素晴らしいものです。新たな考え方や働き方、コラボレーションの方法を紹介して、世界中で何百万の人たちに影響を与えました。それとともに、行動の活発さも非常に印象的です。coffee、バターコーヒー)で始めるようにしています。新陳代謝の向上や、体重の減少あるいは維持に効果があるからです。朝の始まりにはこれが一番ですね。diet)のように、高タンパク高脂肪な食事をしています。エネルギーを高く維持し、行動し続けられるようにしてくれます。私の本当のモチベーションとなっているのは、数多くの優秀な企業やチームが、Scrum@Scaleの導入に成功していることです。500のスクラムチームを擁しているIntelの事業部長と話をした時には、同社では"スクラムとScrum@Scaleを使用したこの10年で、生産性を18倍に向上することができた"、と教えてくれました。スクラムが生み出されたのは、このためなのです。ひとつに絞るのは難しいですが、最も行うべき重要なことは、バックログを高い準備段階にすることです。その次には、レトロスペクティブでしょうね。レトロスペクティブは、次のスプリントで実装されるプロセス改善を確認するためのものです。バックログを準備することができて、スプリント毎に改善を実行できるならば、優れたスクラムチームであると言えるでしょう。Gun"で、スクラムフレーム開発者のひとりです。Schwaber氏と共同で1993年に開発され、1995年になって正式化されたこのモデルは、それ以来、世界中で数多くのソフトウェア開発会社によって採用されてきました。Sutherland氏は、今日のビジネスにおけるニーズを満たすために、フレームワークの進化する方向をリードする、中心的な専門家です。そのメリットの実現は、ソフトウェア開発に限定されるものではありません。氏はこの戦略を、金融やヘルスケア、テレコムといった他の産業にも適応させてきました。スクラムとScrum@Scaleは現在幅広く採用されており、生産性の極めて高い開発チームを実現しています。Partnersのシニアアドバイザ兼アジャイルコーチとして、Sutherland氏は幹部社員をトレーニングし、世界中の組織とベストプラクティスの共有を行っています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。