BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ カルチャー&手法 に関するすべてのコンテンツ

  • スタッフプラスエンジニアになる:リーダーシップとコミュニケーションのトレーニングが大切

    技術的なキャリアを追求したいエンジニアに対する業界のサポートが不十分であり、それがエンジニアに影響を及ぼしている。多くの優れた技術者が、管理職を探すことを余儀なくされている。スタッフプラスエンジニアの役割への道は簡単ではない。スタッフプラスエンジニアになるためのリーダーシップとコミュニケーションに関するトレーニングは、彼らがより優れた技術リーダーになる助けとなる。

  • CircleCIレポートにより、成功したソフトウェアチームがより大規模で、広範囲にテストを実施していることがわかった

    CircleCI(継続的インテグレーション・継続的デリバリープラットフォーム)は、2022年ソフトウェアデリバリ状況レポートの調査結果をリリースした。このレポートでは、最も成功したソフトウェアデリバリチームがより大きなチームであり、広範囲に及ぶテストを行い、デプロイの準備ができていることを優先していることが明らかになった。

  • ゲーミフィケーションによるソフトウェア品質の向上

    バグハンティングやリスクストーミングゲームをプレイするBingo Bongoセッションにより、品質を向上させることができる。ゲーミフィケーションは学習を支援し、日常業務を面白くし、チームスピリットを強化することができる。ゲームをプレイすることはオフィスでの日常業務の一部であり、効果的な作業時間と見られるべきである。ゲーミフィケーションでは、創造的なプロセスによって真の価値が生み出される。

  • スタッフプラスエンジニアとして成功するための5つの行動

    スタッフプラスエンジニアは、より大きな影響を与える技術リーダーとして機能するものである。物事を成し遂げる彼らの能力は、他の人を成長させ、指導するため、彼らの個々の能力を超えたものになる。テクノロジー業界は、エンジニアが個別に作業するという考えから離れてきている。コラボレーションがスタッフプラスの役割において最も重要な行動の1つとなる。

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

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

  • Lyftにおけるマイクロサービステストの拡張と自動化

    Liftは以前、エンドツーエンドのテストなど、いくつかの目的でクラウドベースの分離環境を使用していた。しかしながら、マイクロサービスの数が増えるにつれて、これらの環境を用いたテストでは拡張性が不足するようになり、次第に価値を失っていった。先日の記事では、Lyftが共有ステージング環境においてリクエスト分離を使用したテストへ移行し、運用デプロイメントのゲート管理に受け入れテストを使用するようになった経緯を紹介した。

  • TSS(チーム一体給与)を全社的な報酬評価に採用する

    TSS(チーム一体給与)は、チームを越えた評価を行うことで、結果が自動的に調整され、スケールアップが可能になる。さらに、そのスコアを見ることで、どこに会話が必要なのかが分かる。TSSは、新たなスキルを習得し、適応することを促すのだ。

  • Lyftの開発者エクスペリエンス: クラウドからローカル環境へ

    Lyftのエンジニアリングチームが自社のモノリスを分解して、マイクロサービスの集合体として再構成したのは2018年のことだった。Dockerコンテナを使用したモジュラ開発環境は、後にクラウドへと移行した。最近公開された記事には、時が経ち、マイクロサービスの数が爆発的に増加するのに伴って、同社の開発ツールがそれに追いつこうと苦心した様子が書かれている。開発環境をエンジニアのマシンに戻す必要があったのだ。

  • ソフトウェアとクラウドサービスによる環境への影響の測定

    ソフトウェアは、耐用年数の制限、あるいはエネルギー消費の増加に影響を及ぼす。クラウドサービスによって引き起こされる環境への影響を測定することが可能である。ソフトウェアアーキテクチャの設計により、必要なハードウェアと電力の量が決まる。ソフトウェアはハードウェアリソースに対して経済的か、あるいはを浪費となる。

  • サイト信頼性エンジニアとスペシャリストのマインドセット

    サイト信頼性エンジニア(SRE)には、ジェネラリストとスペシャリストがある。Blamelessのチームが先頃、SRE専門チームのアドバンテージを詳説した記事を発表した。SREのスペシャリスト的な性格については、その採用プロセスからも明らかである。個人の持つスキルセットに応じて、企業は、SREをさまざまな専門的役割に関与させることができるのだ。

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

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

  • QCon Software Development Conference - 見逃せない7つのトラック

    マイクロフロントエンドはなぜ重要なのか? 組織構造をスピードやフローの面から最適化するにはどうするべきか? マイクロサービスを成功させるにはどうすればよいのか? 有名なハイテク企業が、数百万のユーザや何十億というトランザクションをサポートしながら、並外れたユーザエクスペリエンスを途絶えることなく提供できるのはなぜだろう、と疑問に思ったことはないだろうか?新たなプロセスやソフトウエアのベストプラクティスを探してはいないだろうか?

  • セキュリティ・バイ・デザインがクラウド移行のリスク管理にどのように役立ったか

    企業がクラウドに移行したとき、最初から利害関係者を参加させたり、セキュリティを関与させたりすることが困難であったため、セキュリティの問題が発生した。継続的なクラウドDevOpsプロセスの一部としてセキュリティ評価を組み込み、プロジェクトのライフサイクル全体を通じてセキュリティリスク管理にアジャイル戦略を採用することで、移行中のセキュリティのガバナンスを強化することができた。

  • TSS(Team-set salaries)によるアジャイルチームの公平な個人報酬

    TSS(team-set salaries、チーム一体給与)は、マルチスキルで協調的、かつ自律的なチームの各メンバに対して、公平な報酬を設定することのできる手法である。メンバはそれぞれ、自分自身ではなく、同僚のみを評価する。それによって、給与の決定に関する直接的な発言権が与えられるのだ。

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

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

BT