BT

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

寄稿

Topics

地域を選ぶ

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

  • 優れたスタッフプラスエンジニアになるには

    スタッフプラスエンジニア(staff-plus engineer)としての自分の有効性を高めるためには、コミュニケーション、リスニング、技術的戦略、ネットワークのスキルを高めることが大切だ。Blanca Garcia Gil氏はQCon London 2022で、スタッフプラスエンジニアとして成功するための5つの行動指針について講演した。さらに氏は、2022年5月10日~20日のQCon Plusでも講演する予定である。

  • スタッフプラスエンジニアとして技術職に留まるには

    テクノロジに携わり続けたいと願うエンジニアには、スタッフプラスエンジニア(staff plus engineer)になる、という方法がある。スタッフプラスエンジニアは、他の人々に影響力を持たせることがその役割だ。周りの人々を巻き込むというのは難しく、コミュニケーションや影響力のあるスキルに取り組む必要がある。Nicky Wrightson氏はQCon London 2022で、"The Secret Strategy for Landing That Staff Engineer Role"と題して講演した。氏はQCon Plus May(2022年5月10日~20日)でも講演する予定である。

  • オープンソースによってどのようにしてstaff+の役割への道を開けるか

    オープンソースへの貢献と長期的なコミュニティの関与は、staff+エンジニアの役割への道を歩むのに役立つ。文面によるコミュニケーションスキルは、オープンソースで一般的な非同期的なリモートワークの鍵となる。あなたの貢献はビジネスニーズと一致している必要がある。それによって、あなたの知名度が上がり、キャリアの可能性が広がる。Alex Porcelli氏はQCon London 2022で発表した。

  • ソフトウェアが気候変動にどのように影響するか、ソフトウェアエンジニアがそれに対して何ができるか

    地球上のいたるところで大量のソフトウェアが実行されており、このソフトウェアは実行時にエネルギーを消費する。残念ながら、世界中のエネルギーのほとんどはまだ化石燃料の燃焼によって生成されている。ソフトウェアエンジニアがソフトウェアを改善して、処理に使用するエネルギーを少なくすることができれば、化石燃料を燃焼させることによって生成する必要のあるエネルギーが少なくなり、気候にとってより適した状態となる。

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

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

  • 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だ。時間をかけてコードを抽象化し、他のユースケースに適合させることで、ベストプラクティスを普及させることができる。

BT