BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ケーススタディ に関するすべてのコンテンツ

  • 無限を表現する: 開発者にとって不可能なこと

    開発者は、その日々の業務の中で、不可能なことに直面する場合がある。無限大を直接的に表現することや、あるいは物理的に独立したコンピュータ上に無限大の精度を保持することは不可能だ。ストレージや表現には限界があり、この不可能性を無視するか、あるいは意識するかによって、バグやシステムの挙動が期待とは異なるものになる可能性がある。Kelvin Henney氏はQCon London 2022で、6つの不可能(Six Impossible Things)について基調講演を行った。

  • 高品質なアラートで開発者のオンコールを軽減する

    開発者にとって、オンコールはますます現実味を帯びてきている。アラートの改善によるノイズの低減、自動化、警告の削除は、オンコール作業の苦痛を最小限にするのに役立つ。自動化の原動力となるのは、Infrastructure as Codeだ。時間をかけてコードを抽象化し、他のユースケースに適合させることで、ベストプラクティスを普及させることができる。

  • ディフェクト・マスの測定が重要な製品領域のテストにどのように役立つか

    「ディフェクト・マス」と呼ばれる測定を導入することで、プロジェクトは開発によって最も影響を受けた領域を見つけることができ、影響を受けた領域ごとに実行するテストの数を決定するのに役に立った。この測定値を他のKPIと一緒に使用することで、テストに集中する役に立った。顧客のインシデントの数を減らすことができた。

  • 実車を使用したリモートソフトウェアの実証と妥当性確認の実装

    Bosch は、シミュレートされた車ではなく、実際の車を使って自動回帰テストとユーザテストを行っている。目的は、テストエンジニアとユーザの両方の観点で、ソフトウェアを可能な限り迅速にテストすることだ。車にはリモートでアクセスが可能で、チームメンバは乗車せずに行うことができる。

  • ゼロバグポリシを使ってバグを解決する

    ゼロバグポリシ(zero bug policy)を採用すると、バグの優先順位付けが容易になり、チームの可視性とバグへの対応性を向上することができる。ただし、過激な変革なので、意思決定とバグの修正時間に関して、自分自身の状況に合わせることが必要だ。

  • モブプログラミングの集団的習慣は技術品質を高めるための土壌になり得る

    モブ(mob)プログラミングは、プロダクトをアジャイル手法で開発する上で、古い習慣を新しく効果的な習慣に変えるための有効な手段だ。周りを人に囲まれた環境において集団で培われた習慣は、簡単に忘れることはない。モブプログラミングは各メンバに対して、新たな習慣を定常的に実践させることによって、それらを取り入れやすくする。チームは同じ作業の繰り返しを容認しない。仕事を行うためのよりよい方法を探しているのだ。

  • PayPalがGraphQLを採用し、開発者の生産性向上を実現

    PayPalは先頃、近年のPayPalにおけるGraphQLの採用について解説したブログ記事を公開した。2018年のCheckoutアプリケーションひとつから始まった導入はその後、GraphQLフェデレーションを使用した統合型のフェデレーションAPIを構成するまでに至っている。組織全体に及ぶGraphSQLの採用は、開発者の生産性向上やアプリケーション提供の迅速化といった成果を生み出した。

  • 自己不信やインポスタ症候群から脱却し、テクノロジにおける多様性のメリットを見出すまで

    Charu Bansal氏は、自身が非技術的なバックグラウンドを持っていることから、そのキャリアにおいて、自分がセキュリティに関する価値を提供できないのではないかと不安を持つ、インポスタ(詐欺師)症候群に度々陥っている。The Diana Initiative 2021で行った講演の中で氏は、非技術系のキャリアから情報セキュリティの分野に転向したことによる多様な観点を持つことが、困難なセキュリティ問題を解決する上でいかに役に立ったか、という話をした。

  • 分散DevOpsチーム: デジタルコネクションチームのサポート

    グローバルに分散したチーム内でデジタルコネクションを確立するために、組織はチームメンバにコラボレーションツールと視覚化ボードを備えた追加のモニターの両方を提供した。オンラインチャットとホワイトボードを使用したコラボレーションは、ボードをチームのニーズに合わせる調整のため、当初は課題があった。

  • テスタは製品定義にどのように貢献できるのか

    製品の定義と設計にテスタのフィードバックを活かすことは、ビジネスのための価値ある行動だ。組織のニーズに耳を傾け、ビジネスの目標を理解し、さまざまなスキルやプラクティスを駆使してテストプロセスをカスタマイズする作業は、プロダクトがまだ"机上の空論"である時からテスタが始められるひとつの方法である。

  • 継続的セキュリティテストを有効にしてテストにセキュリティを追加する

    チームは、テストプロセスにセキュリティテストを追加し、機能テストの自動化の一部としてセキュリティチェックを追加して領域の特定ができるようになるためにセキュリティの専門家によってトレーニングをうけることが可能だ。これにより、継続的なセキュリティテストが可能になり、すべてのリリースでセキュリティテストの対象範囲が広がり、セキュリティの欠陥を早期に発見できる。

  • テストピラミッドを使って品質を左シフトする

    品質の左シフト(前倒し)とは、開発終了後に品質テストを行うのではなく、ソフトウェア開発サイクルの早期に品質を作り込む、という意味である。テストピラミッドモデルを使うことで、テストをより早いステージに移動させることが可能になり、統合時に問題となる欠陥を開発早期に発見することが可能になる。

  • 確率論的データサイエンスモデルのテストから学んだこと

    ���ータサイエンスモデルは統計的なブラックボックスだ — そのテストには、アルゴリズムや乱数性、統計学といった数学的テクニックの理解が必要になる。データサイエンスモデルの検証で有効なのは、しきい値を用いた出力差異の処理だ。

  • Strangler Fig Patternを使用したマイクロサービスへのモノリスの移行

    ScholarPackは、Strangler Fig Patternを使用してモノリスバックエンドから移行した。彼らは、顧客のニーズをターゲットにするために段階的な開発と継続的デリバリーを適用し、その間にモノリスを絞め殺した。

  • データサイエンスチームにアジャイルを導入する

    アジャイルはデータサイエンスチームの、ステークホルダとのコラボレーション改善と生産性向上に寄与する。優先順位が明確になることで、作業への集中と成果の提供が可能になるのだ。実践する上で重要なのは、アジャイルの旅に同行することによって、データサイエンスチームの賛同を得ることである。

BT