検索結果

DevOps の世界は決して立ち止まりません。そして Linux Professional Institute（LPI）も同様です。DevOps Tools Engineer 認定試験 バージョン2.0 のリリースにより、LPI は試験内容を、現在プロダクション環境で実際に使われている技術――コンテナ化、クラウドネイティブアーキテクチャ、そして現代的な開発手法――にしっかりと合わせました。 この記事では、更新された最初の試験範囲である 701.1：モダンソフトウェア開発（Modern Software Development） を一緒に見ていきます。学習のためにも、実務での理解のためにも、頭の中に明確な全体像（メンタルマップ）を構築できるよう支援します。 多くの変更が加えられた一方で、変わらないものもあります。それは、強固なソフトウェアエンジニアリングの基礎は今でも重要であるという点です。比重 6 を持つ試験範囲 701.1 では、現代のランタイム環境に本当に適したソリューションを設計できることが求められます。つまり、サービスがデータ、セッション、セキュリティ、パフォーマンス、スケーラビリティ、信頼性をどのように扱うのかを、理論ではなく実践的な分散システムの文脈で理解している必要があります。 アーキテクチャの基盤：サービス、マイクロサービス、クラウドネイティブ設計 現代のアプリケーション設計は、サービス指向およびクラウドネイティブの原則によって大きく形作られています。バージョン 2.0 では、Service Oriented Architecture（SOA）を含むサービスベースのアーキテクチャ、特に マイクロサービス が強く重視されています。 アーキテクチャ理解を深めたいのであれば、Martin Fowler の仕事は非常に優れた参考資料です。彼と共著者たちは、アプリケーションアーキテクチャ、SOA やマイクロサービス、不変（immutable）サーバー、モノリスと結合度、そして疎結合の重要性についての記事を提供しています。これらの概念は、試験範囲全体にわたって暗黙的に登場します。 新しい認定試験では、コンテナ内で実行され、クラウド環境で自然に動作するソフトウェアを設計できることが明確に期待されています。これは、密結合されたモノリシックシステムからの脱却という、業界全体の現実的な変化を反映しています。 同時に、試験は現実も認識しています。レガシーシステムは依然として存在するという事実です。今回の試験では、レガシーなモノリシックソフトウェアを移行・統合する際のリスクを認識することが明示的に求められています。これは多くの組織が直面している課題を踏まえたものであり、革新と安定性のバランスを取った戦略的なモダナイゼーションが必要であることを示しています。 クラウドネイティブおよびコンテナファースト開発の採用 認定試験バージョン 2.0 における最も重要な更新点のひとつが、クラウドネイティブおよびコンテナファースト設計への明確なフォーカスです。これは単にアプリケーションをクラウドにデプロイするという話ではありません。弾力性、自動化、分散インフラの利点を最大限に活かすソフトウェアを構築すること、そしてコンテナで動作し、クラウドサービスにデプロイされるソフトウェアを設計できるスキルを示すことが求められます。 これらのスキルは、クラウドを単なるホスティング環境として使うだけでは不十分です。クラウドが持つ動的かつ分散された特性を最大限に活用できるよう、アプリケーションを設計する能力も含まれます。 Cloud Native Computing Foundation（CNCF）によると、クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドといった動的な環境において、スケーラブルなアプリケーションを構築することを可能にします。実際には、これは コンテナ化され、動的にオーケストレーションされ、マイクロサービスを中心に構成されたアプリケーション を意味します。 コンテナ向けの設計では、ステートレスなサービスと不変性（immutability） が重要です。各コンテナは理想的には 1 つの役割に集中し、容易に置き換え可能で、摩擦なく水平スケールできるべきです。この考え方は、耐障害性を高め、デプロイを簡素化し、自動化をはるかに効果的にします。 API、データ、ステート管理 分散システムにおいて、API はすべてをつなぎとめる「接着剤」です。試験では引き続き、REST を中核となるアーキテクチャスタイルとして、JSON を標準的なデータ形式として重視しています。 RESTful の原則を理解することは、HTTP メソッドを暗記すること以上の意味を持ちます。スケールし、進化し続けることができる、予測可能で一貫性のあるインターフェースを設計することが重要です。RESTful 原則に関する包括的な入門資料では、REST の基本的な制約条件から実践的な設計パターンまで、優れたチュートリアルとベストプラクティスが提供されています。 JSON:API のような仕様は、データ構造を標準化し、サービス間の相互運用性を向上させます。また、jsonapi.org では、JSON を用いた API [...]

DevOps Tools Engineer 認定資格 バージョン2.0について 2025年11月、Linux Professional Institute（LPI）は Linux Professional Institute DevOps Tools Engineer 認定資格のバージョン2.0 をリリースしました。本試験は、ソフトウェアを協調的に開発・提供するために使用される一連のツールを対象としており、ソフトウェア開発者とシステム管理者の双方のスキルを拡張する内容となっています。 DevOps Tools Engineer 認定資格の V2.0 アップデートは、現在の DevOps 実践により適合するよう、試験構成と全体的なビジョンを近代化したものです。オープンソースツールを用いてソフトウェア開発と運用を橋渡しするという中核領域はこれまでと変わりませんが、V2.0 では一部の試験範囲が再編成され、「更新ドラフト（updated draft）」として位置づけられています。これは、進化し続けるツールや手法に対応するため、カリキュラムが今後も修正される可能性があることを示しています。 V2.0 のリリースでは、試験内容が基礎から再構成・更新・近代化されました。V1 では、コンテナ、構成管理、インフラストラクチャ、CI/CD、監視といった、従来型の幅広い DevOps 分野を軸に構成されていましたが、V2.0 では、今日の実際のエンジニアリングワークフローにより密接に沿ったトラック構成が導入されています。新しい構成では、ソフトウェアエンジニアリング、コンテナ、Kubernetes、セキュリティ、可観測性（Observability）に重点が置かれており、現代の DevOps チームが日常的に依存している技術と実践を反映しています。 この新バージョンは、より明確な構成、洗練されたトピックの区分、更新されたツール要件を備えつつ、LPI の理念の中心であるオープンソース重視の姿勢を維持しています。 総じて、DevOps Tools Engineer V2.0 は単なる内容の改訂ではありません。それは、現代の DevOps の現実に合わせて認定資格そのものを再調整したものです。V1 との概念的な連続性を保ちながらも、その対象範囲、構造、提供方法を進化させ、より高速で自動化され、協調的な環境で働くプロフェッショナルを支援する内容となっています。 学習教材と本シリーズについて この認定資格の公式ラーニング教材は、非常によく整理されており、すでに LPI の Learning Portal で利用可能です。この教材は、試験範囲をより深く理解し、ツールを実際に操作しながら学び、明確な指針と自信を持って試験準備を進めたい方にとって、非常に優れたリソースです。内容はステップ・バイ・ステップで構成されており、認定資格取得までの道のりを、より楽しく、達成しやすいものにしてくれます。 本記事は、LPI ブログに掲載される導入シリーズの第1回目です。このシリーズでは、LPI DevOps Tools Engineer の試験範囲を順に巡っていきます。各トピックごとに、最も重要なツールやスキルを要約し、学習を始める際に役立つドキュメントを紹介していきます。 今後の記事を活用するための準備 これから公開される記事を読み進め、DevOps [...]

Linuxマシンの電源を入れたとき、裏側では何が起きているのか？ Linuxマシンの電源ボタンを押したとき、その裏側で何が起きているのか考えたことはありますか？サーバーの電源が切れている状態は、壮大なコンサートホールが静まり返り、暗闇に包まれているようなものです。ステージには誰もおらず、客席も空っぽです。 しかし電源ボタンを押すとき、あなたは単にスイッチを入れているのではありません。そこから、複雑で美しいパフォーマンスを始める合図を送っているのです。 デジタル交響曲の4つの楽章 このパフォーマンスは4つの楽章から成り立っており、静寂に包まれたホールを、生き生きとした交響曲へと変えていきます。それぞれの楽章には主役がいて、役割があり、そして輝く瞬間があります。 第1楽章：会場スタッフ（ファームウェア：BIOS / UEFI） 最初の一音が奏でられる前に、会場スタッフ（マシンのファームウェア）が暗いステージに姿を現します。彼らの最初の仕事は、建物そのものが安全であることを確認することです。 メインの電源系統を入れ、ステージ照明や安全装置をテストしながら、チェックリストを一つずつ確認していきます。これが POST（Power-On Self Test） です。もし会場が安全でないと判断された場合、スタッフはすべての作業を中止し、問題を報告します。 安全が確認されると、次はスケジュールの確認です。これには2つの方法があります。 旧来の方式（BIOS）いつも同じ場所、つまりステージ入口にある台帳の最初のページ（MBR：マスターブートレコード）を確認し、次の責任者を探します。 現代的な方式（UEFI）より洗練された方法で、オフィスにあるデジタルのスケジュール表（NVRAM）を確認し、そこからEFIシステムパーティション（ESP）内にあるステージマネージャーの部屋を直接指し示します。 第2楽章：ステージマネージャー（ブートローダー：GRUB2） 会場の安全が確保されると、ステージマネージャー（GRUB2）がスポットライトを浴びて登場します。彼らは一時的な存在ですが、非常に重要な役割を担っています。ショーの間ずっと居続けるわけではありません。 ステージマネージャーは、プログラム冊子（grub.cfg）を手にしています。そこには、現在のカーネル、過去のバージョン、リカバリーモードなど、実行可能な演目が一覧されています。 数秒後、メインとなる演目を選択し、演台を整え、譜面台に必要な楽譜（カーネルパラメータ）を置き、指揮者をステージに呼び出します。そして、何事もなかったかのように静かに建物を後にします。 第3楽章：指揮者と舞台スタッフ（カーネルと initramfs） 指揮者、つまり Linuxカーネル がステージ中央に立ちます。彼らはパフォーマンスの最初から最後まで演台に立ち続け、テンポ（スケジューラ）や音響（メモリ管理）を制御します。 しかしこの時点では、楽器はまだケースに入ったままで、演奏台も設置されていません。そこで指揮者はすぐに、舞台スタッフ（initramfs）を呼び出します。この専門の一時チームは、重要な初期設定作業を迅速にこなします。 楽器ケースを開けるストレージドライブを読み取るために必要な基本ドライバ（カーネルモジュール）を読み込みます。 演奏台を組み立てる本来のルートファイルシステムを見つけてマウントし、オーケストラが座る場所を用意します。 本物のステージが準備できると、switch root と呼ばれる操作が行われます。これにより、仮のステージは完全に消え、本物のステージが置き換わります。 第4楽章：コンサートマスターと演奏者たち（初期化システム：systemd） ここで指揮者（カーネル）は、演奏者たちの統率をコンサートマスター（systemd）に引き継ぎます。最初のプロセス（pid 1）として、コンサートマスターはオーケストラ全体の登場を指揮します。 旧来のコンサートマスター（SysVinit）は、演奏者を一人ずつ呼び入れていました。まずバイオリン、次にチェロ、その次にフルート……という具合で、着実ですが時間がかかります。 一方、systemdは現代的な名手です。どのパートが同時に登場しても問題ないかを正確に把握しています。コンサートマスターの鋭い合図とともに、オーケストラは次のように登場します。 打楽器（ジャーナル／デーモン）ログ記録サービスが、リズムを刻むかのように動き始めます。 弦楽器（ミドルウェア）NetworkManager などのサービスが起動し、ステージと外の世界をつなぐ調和を織り成します。 木管楽器（ユーザーアプリケーション）最後に、Webサーバー、オーディオプレーヤー、データベースといった複雑な旋律が奏でられます。 すべてが同時に、連携し、正確に、そして圧倒的な美しさで進行します。 グランドフィナーレ わずか数秒のうちに、静寂は調和へと変わります。コンサートホールは生命を帯び、照明は輝き、交響曲は最高潮に達します。 観客であるあなたの目の前には、ログインプロンプトという形で幕が上がります。オーケストラは準備万端、あなたの指示を待っています。 静まり返っていたホールは、見事な連携の結晶へと姿を変えました。それこそが、4つの楽章で構成されたLinuxのブートプロセス なのです。 さらに詳しく知りたい方へ ブートプロセスとの具体的な関わり方については、LPIのLearningサイトにあるガイドをご覧ください。

チームでの作業整理はなぜ難しいのか 仕事を効率よく整理することは簡単ではありません。特にチームで協力して作業する場合、その難易度は一気に高まります。タスク管理の複雑さは急速に増していくため、適切なツールを選ぶことが不可欠です。 しかし、データを特定のエコシステムに囲い込む商用サービスに依存したくないとしたら、どうでしょうか？ 私はオープンソースかつセルフホスト可能なツールを好んで使っています。そのため、Trello や Asana のようなプラットフォームに代わる、柔軟でプライバシーに配慮した選択肢を探していました。そこで出会ったのが Vikunja です。Vikunja は軽量で使いやすく、カンバン、ガント、リスト、テーブルといった複数のプロジェクトビューを備えた、オープンソースのタスク管理ツールです。 この記事では、Vikunja の仕組みや優れた点、そして私自身のワークフローに合わせてどのようにカスタマイズしているかを紹介します。 他のタスク管理ツールではなく、Vikunja を選んだ理由 オープンソースのプロジェクト管理ツールは数多く存在しますが、その多くは「インターフェースが複雑すぎる」「習得に時間がかかる」といった使い勝手の問題を抱えています。私は以下のツールも検討しました。 OpenProject：機能は豊富だが、私の用途には複雑すぎた ProjectLibre：成熟したツールだが、ユーザビリティに欠ける Redmine：定番ではあるが、古く使いづらい印象 一方で Vikunja は、驚くほどシンプルです。機能性と使いやすさのバランスが非常によく、個人利用はもちろん、小規模チームにも最適だと感じました。 Vikunja を際立たせる主な機能 Vikunja が他のオープンソースツールと一線を画す理由は何でしょうか。ここでは主な機能を紹介します。 複数のタスク表示形式 Vikunja では、用途に応じてタスクをさまざまな形で管理できます。 カンバンボード：作業フローを視覚的に把握するのに最適 ガントチャート：スケジュール管理や期限設定に理想的 テーブルビュー：スプレッドシートのような構造的表示 リストビュー：シンプルで従来型の ToDo リスト ホスティングの自由度 Vikunja は以下の方法で利用できます。 自分のサーバーで運用する セルフホスト Vikunja の マネージドクラウドサービス を利用し、開発を金銭的に支援する Open API と WebHooks による拡張性 自動化に対応した 完全な API を提供 WebHooks により、外部からアクションをトリガー可能 プライバシー重視のオープンソース AGPLv3 ライセンスの完全オープンソース データのロックインなし。プロジェクトは常に自分のもの ローカルバックアップ機能により、データ消失を防止 タスク自動化とクイック追加機能 「明日 17時」のような 自然言語入力で期限設定 タスクの割り当て、優先度設定、ラベル付けを素早く実行 私のワークフローにおける Vikunja [...]

あなたにとって何が大切かを、雇用主に伝えましょう！ Open Source JobHubとLinux Professional Institute（LPI）は再び連携し、「オープンソース・プロフェッショナル職業調査（Open Source Professionals Job Survey）」の第3回を開始しました。この調査は、現在そして将来において、自由ソフトウェアおよびオープンソースソフトウェア分野で働くプロフェッショナルにとって、キャリアの中で何が最も重要なのかを理解することを目的としています。 質問はわずか8問、所要時間は約5分と、とても簡単に意見を共有できます。今年の調査では、テクノロジーに関する経験やAIの活用状況に加え、エネルギー効率やサステナビリティ（持続可能性）が、参加者の組織においてどのような役割を果たしているかを探る質問が含まれています。 皆さまからの回答は、雇用主が、あなたのようなオープンソース・プロフェッショナルの期待に沿った取り組みを行うための、非常に貴重な指針となります。 影響を与える準備はできていますか？2026年版 オープンソース・プロフェッショナル職業調査に、ぜひ今すぐご参加ください！ 個人を特定できるデータは一切収集されません。オープンソース分野のキャリアの未来づくりにご協力いただき、ありがとうございます。 なお、2025年版 オープンソース・プロフェッショナル職業調査の結果にご興味のある方は、こちらをクリックしてください。

シアトルGNU/Linuxカンファレンス（SeaGL）は、第13回目の開催として、11月7日から8日にかけてワシントン大学に戻ってきました。SeaGLは、これまで一貫してコミュニティ主導で、完全に無料のイベントであることを誇りとしてきました。ここで言う「無料」とは、参加のために登録したり、個人情報を提出したりする必要がないという「自由」を意味します。まるで毎週開かれる地元のファーマーズマーケットにふらっと立ち寄るような気軽さで参加できる、草の根的な技術サミットなのです。今年もその伝統は受け継がれ、ワシントン大学（UW）のHUBを中心に、2日間にわたって講演、ディスカッション、さまざまなアクティビティが行われました。また、周辺のシアトル近隣地域でもいくつかの関連イベントが開催されました。このイベントは、学生や地元のオープンソースグループ、そして（シアトルの北約2時間に位置する）ベリンガムから参加した人々を含む、多くのボランティアによって完全に運営・支援されています。 Jon “maddog” Hallと私は、Linux Professional Institute（LPI）を代表して参加し、日曜日のプログラムでそれぞれ講演を行いました。すべての講演は録画され、ハイブリッド形式での参加が可能で、講演後にはSeaGLのMatrixスペース上で、登壇者と参加者の双方が参加する活発なディスカッションチャンネルが設けられました。私たちの講演動画は、SeaGLのボランティアが録画映像の処理を終え次第、オンラインで公開される予定です。 木曜日：到着とローカル・ハッカースペース訪問 私は木曜日の正午頃にシアトルに到着し、レンタカーを借りて、ワシントン大学HUBから徒歩約15分の距離にあるUniversity Innにチェックインしました。このホテルは、会場に最も近いホテルの一つです。夕方早めの時間に、UWキャンパス近くにあるdev/hackコミュニティスペースを訪れました。そこでは、Seattle Community Network（SCN）のメンバーや、他のコミュニティのdev/hack関係者たちが、オープンソースのネットワーキングやオーディオ関連のさまざまなプロジェクトにすでに取り組んでいました。このシアトルのdev/hackスペースには、学生、研究者、地域の人々、ボランティア、そして地元のプロフェッショナルが集まっており、その中にはテクノロジー分野に直接関わっているわけではない、地元のセラピストも含まれていました。 その日の夜遅くには、LinuxFest Northwest（LFNW）の理事であるGarth Johnson氏と、Cascade SteamのMichael Gan氏が、ベリンガムから来たLFNWの学生ボランティアの一団とともに到着しました。彼らはdev/hackのメンバーから温かく迎えられ、Seattle Community Networkが他のコミュニティグループとともに拠点を構える、複数階にわたるdev/hackビルの案内を受けました。この見学は、ベリンガムでコミュニティが集まり、メイカーやオープンソースプロジェクトを共有できるスペースを運営しているCascade Steamプロジェクトに関わるGarth氏とMichael氏にとって、非常に興味深いものでした。 ツアーの後、私たちは空港へmaddogを迎えに行きましたが、通常のシアトルの交通渋滞に加え、工事による空港周辺の混乱もあり、非常に厳しいドライブとなりました。それでもmaddogは比較的機嫌よく、Uディストリクトで遅めの夕食をとりました。 金曜日：SeaGL開幕 金曜日の朝は、Café On the AveでGarth氏、Michael氏、学生ボランティアたちと朝食をとり、その後UW HUBへ歩いて移動し、LPIのブース設営を行いました。maddogのテーブルクロスや資料、そしてハロウィン後のお菓子がたっぷり入った大きなボウルのおかげで、私たちのブースには途切れることなく来場者が訪れました。多くの参加者がLPI認定について学び、20％割引バウチャーのQRコードを写真に収め、メンバーシッププログラムについて質問してくれました。あるいは、ただ雑談をしに立ち寄る人もいましたが、それも大歓迎でした。私たちの目的は、Linuxやオープンソースのコミュニティに関わる新しい人々と出会うことだからです。 金曜日は、UW HUBの複数フロアで終日講演トラックが行われ、廊下での会話を楽しむ時間も十分にありました。来場者のおよそ20％は、SeaGLが初めての人や、無料でオープンなカンファレンスとはどんなものかを見に来た学生でした。 その日の夜のソーシャルイベントは、Ada’s Technical Bookstoreで開催され、SeaGL提供の無料ピザに加え、SCN創設者のEsther Jang氏が率いるバンド「Si Tu Savais」による無料のライブジャズ演奏、そしてSCNのための資金調達オークションが行われました。会場は満員で、初日の締めくくりとして素晴らしいひとときとなりました。 土曜日：講演、来場者、そして忙しいLPIブース 土曜日も再びCafé On the Aveで一日を始め、2日目のカンファレンスに参加しました。この日はmaddogと私の両方が講演を行い、全体的な参加者数も金曜日以上に多く感じられました。 私は、最近博士号を取得し、現在UWで博士研究員を務め、また私自身もボランティアとして関わっているSeattle Community Network（SCN）を設立したEsther Jang氏による土曜日の基調講演に参加しました。Esther氏は、コミュニティISPのネットワークスタックと、それを支えるアプリケーションについて説明しました。これらはオープンソースのソリューションを活用し、SCNのネットワークがなければインターネット接続を持てないシアトル各地の複数のコミュニティに対して、有線、WiFi、セルラーアクセスを提供しています。 続く2つ目の基調講演では、UWのHuman Design and Engineering学部の准教授であるNadya Peek氏が登壇し、デジタルファブリケーションや個人の創造性に関するプロジェクト、そしてオープンソースソリューションが、機械やそれを動かすソフトウェアの保守をどのように容易にするかについて語りました。 （https://depts.washington.edu/machines/） 講演時間中であっても、私たちのブースは学生、研究者、教育者、地元のプロフェッショナルで賑わい続けました。質問内容は基礎的なものから、DevOpsやセキュリティ認定といった新しい分野に関するものまで幅広いものでした。 長い一日の後、私たちは2回目のソーシャルイベントは見送りました。maddogと私は日曜日に早朝便を控えていたため、シアトル在住でSeaGLの常連参加者であるAndrew Puch氏とSamuel Henrique氏とともに、近くの「The Dough Zone」というレストランでカジュアルな夕食をとりました。ここは餃子や麺類を中心とした、西海岸で成長中のカジュアルなチェーン店です。 Samuel氏はAWSに勤務しており、長年Debianコミュニティに貢献してきた人物です。彼は最近、ブラジルからアイルランドを経由してシアトルに移り住んだばかりだったため、彼のような才能ある人材を雇えるのは、大企業にとって他国にとっての「損失」だね、と冗談を交わしました。 Andrew氏は、街を移動するうえで役立つ貴重なアドバイスをしてくれました。このカジュアルな夕食は、Debian Linuxのようなコミュニティプロジェクトで培われたスキルが、いまや世界最大級の企業や組織を支えるシステムを動かす力へと変わっていることを、改めて実感させてくれるものでした。 コミュニティと継続性 SeaGLの大きな強みの一つは、強固なコミュニティ意識です。週末を通じて、LinuxFest NorthwestやAll Things Openなど、LPIが関わる他のイベントでも顔を合わせた参加者たちと再会しました。SeaGLとベリンガムのオープンソースコミュニティの間で、ボランティアや運営者が重なっていることが、こうしたつながりを強め、参加を活発なものにしています。 SeaGLは活発なMatrixスペースを維持しており、カンファレンス終了後の数日間、多くの参加者が「今までで最高のSeaGLだった」「すでに来年が楽しみだ」といった感想を共有していました。Matrixには各登壇者専用の「ルーム」もあり、講演の前後や最中にディスカッションを行うことができます。私の知る限り、こうした仕組みを提供しているカンファレンスはSeaGLだけです。 追加のアクティビティとしては、地元グループ「Resist Tech Monopolies（RTM）」による“Disco-Tech”エリアがあり、プロプライエタリなツールから自由ソフトウェアの代替へ移行する手助けを行っていました。この名称はやや誤解を招くかもしれませんが、RTMは協同組合型クラウドや自由ソフトウェアの代替を支援しつつも、多くのユーザーがパブリッククラウドやビッグテック由来の技術から恩恵を受けていることも認識しています。RTMのブースには親切で知識豊富なスタッフが立ち、クローズドなソフトウェアに代わる自由・オープンソースの選択肢をまとめた有益なリストを提供していました。また、SeaGL創設者の一人であるAdam Monsen氏が主導する、非公式なGPG鍵署名ミーティングも行われ、個人的な信頼のウェブを構築する場となっていました。 SeaGL…また来年！ SeaGLは大規模なイベントではありませんが、オープンソース、教育、コミュニティによる協働を心から大切にする人々を、毎年確実に結びつけています。LPIにとっては、学習者、ボランティア、教育者、そして長年の貢献者たちと、形式張らないオープンな環境で出会える貴重な場です。 個人的にも、自由ソフトウェアやLinuxに関心を持つすべての人を歓迎してくれるカンファレンスに参加できるのは、とても新鮮です。それこそがSeaGLを本当に特別な存在にしている理由の一つです。さらに、UWのキャンパスは私にとって特別な場所でもあります。娘はUWを卒業し、息子は現在、同大学で博士課程に在籍しています。 1980年代のバンド「A Flock of Seagulls」は、きっともうトレードマークの髪型を卒業しているでしょう。しかしSeaGLは違います。毎年、新旧問わず多くの“Flocker”たちを、変わらず両手を広げて迎え入れています――マレットヘアは不要です。 この週末は、実りある対話、強い存在感、そして太平洋岸北西部の自由ソフトウェアコミュニティと再びつながる貴重な機会をもたらしてくれました。

Linux Professional Institute（LPI）では、オープンソースを心から理解し、実践しているプロフェッショナルの声を紹介することを大切にしています。今回の「Share Your Voice」インタビューでは、1990年代後半にLinuxとの歩みを始め、以来、複数の大陸・業界・技術分野にわたって経験を積んできた、経験豊富なソリューションアーキテクトであるテイムール・エレリアン氏にお話を伺いました。データセンター運用のリーダーから、次世代のITプロフェッショナルの育成まで、彼のストーリーは、認定資格とコミュニティへの関与が、キャリアと文化の両方をどのように形作るのかを示しています。 IT分野でのキャリアはどのように始まったのですか？ 私のキャリアは1990年代後半に始まり、技術エンジニアリングを中心としていました。この初期の時期に、システム、ネットワーク、運用に関する実践的な経験を積み、Linuxおよびオープンソース分野での専門性を早い段階で確立しました。2000年代初頭には、大規模なインフラ部門を率いる立場となり、チームの管理、システムの近代化、Tier IIIデータセンターの設計および運用の監督を担当しました。この経験を通じて、Linuxとオープンソース技術が、拡張性と信頼性に優れたITサービスを構築するうえで、いかに大きな可能性を持っているかを実感しました。 Linuxとオープンソースがキャリアの中心になったのはいつですか？ 私は当初から、Linuxを単なる低コストな代替手段としてではなく、イノベーションを生み出すための堅牢なプラットフォームとして捉えていました。私のキャリアでは、中東およびアフリカ全域において、政府、銀行、大学向けに高い耐障害性を備えたインフラを設計してきましたが、その基盤には常にLinuxとオープンソースがありました。2002年には、LPIC-1認定を取得することで、この専門性を明確な形にしました。すでに10年以上のLinux実務経験がありましたが、この認定は、私のスキルを国際的に証明すると同時に、オープンソースコミュニティへの継続的なコミットメントを再確認する貴重な機会となりました。 認定資格は、あなたの成長にどのような影響を与えましたか？ LPIC-1認定は、私にとって大きな転機でした。長年業界に身を置いていても、継続的な学習が不可欠であることを改めて認識させてくれたのです。その後、コンテナ、Kubernetes、OpenShiftといった分野の専門資格も取得しました。これらの認定資格は、単にソリューションを実装できるだけでなく、他の人々が自信を持ってオープンソース技術を導入できるよう指導する立場としての私を形作ってくれました。 現在の役割と注力している分野について教えてください。 現在、私は北米でソリューションアーキテクトとして働いています。主な役割は、オープンソースを中心に据えたマルチ・ハイブリッドクラウド戦略を企業が採用できるよう支援することです。若手アーキテクトのメンタリングを行い、プロダクトチームと連携して新機能の方向性を検討し、顧客に対してはプロトタイプの作成や戦略的ワークショップを通じた支援を行っています。技術的な深さ、リーダーシップ、そしてコミュニティづくりが融合した仕事だと感じています。 日常業務以外では、どのような形で貢献していますか？ 私にとって、コミュニティとメンタリングは非常に重要です。教育セッションの支援、オープンソース導入戦略への貢献、そしてLinuxスキルを身につけようとする新しいプロフェッショナルたちの指導を行ってきました。私が大切にしているのは、単に技術を提供することではありません。人々がオープンソースを信頼し、その中で成長できる文化を育むことです。 モチベーションの源は何ですか？ Linuxを大規模に導入したり、コンテナ技術を取り入れたり、オープン・ハイブリッドクラウドへ移行したりと、組織が変革を遂げる瞬間を見るたびに、この道を選んで本当に良かったと感じます。オープンソースは単なる技術スタックではありません。協調、透明性、そしてレジリエンス（回復力）という考え方そのものです。それが、私を日々突き動かしています。 余暇はどのように過ごしていますか？ もちろん、私はテクノロジーが大好きです。しかし、テクノロジー以外では自然の中で過ごすことも好きで、ガーデニングはその楽しみを満たしてくれる活動の一つです。 私はガーデニングとテクノロジーを組み合わせており、センサーやコントローラーを使った自動水やりシステムを庭に導入しています。これにより、最適な水やりを実現できるだけでなく、旅行中でも植物の健康状態を監視できます（もちろん、これらはすべてオープンソースのソフトウェアとハードウェアを使っています）。それと、旅行が大好きだということも言っておきます！ << このシリーズの前回の記事を読む | LPIの成功事例をさらに読む >>

これは2021年10月、ウィンドウズ11のリリース時に掲載された記事の更新版である。 2021年10月、Microsoftは6年以上ぶりとなるウィンドウズの新バージョンをリリースした。 このバージョンのOSには 11 という番号が付けられています。 それ以来、この疑問は何百万人もの人々の心をとらえている： Windows 10? Or Windows 11? じゃあ、代わりにGNU/Linuxを使えばいいじゃないか！ Linuxが1991年に発売されて以来、ウィンドウズからLinuxに移行するチャンスは、コンピューター・ユーザーの興味をそそるものとなっている。コストに見合った価値を得、一貫したセキュアな環境を維持することを重視する企業では、Linuxは特に魅力的である（記事中の理由3+を参照）。 Linuxへのアップグレードのサイトでは、乗り換える理由や、希望するコンピューター・システムのセットアップ方法について、多くのリソースを提供している。 Windows 10のサポートとアップデートは2025年10月に終了するため、Linuxについて調べ、仕事や個人的なコンピューティングをこのリッチで堅牢なプラットフォームで行う準備をする時間がある。 この記事のオリジナル版では、Linuxに乗り換える11の理由を挙げている。 今回のアップデートには、関連する2つの新しい理由が含まれている。 1. 不必要で高価なハードウェアのアップグレードを避ける Windowsのハードウェア要件は、当時のデスクトップやラップトップシステムに常に負担をかけてきた。 Windows 11はこの忌まわしい遺産を受け継いでいる。 Windows 11を動かすには、多くの人が新しいコンピュータを必要とすると予想され、そのため、システム要件を測定するミニ産業が発展している。 特に古いグラフィックカードは、新しいWindowsに合わないことが判明するかもしれない。 多くのハードウェアのアップグレードを促進するかもしれない他の機能は、UEFI（Unified Extensible Firmware Interface）と呼ばれるWindowsファームウェアと、セキュアブート／トラステッド・ブート機能である。 Windows 11の機能とタイミングを取り上げた記事のひとつに、MicrosoftはなぜWindows 10より小幅な機能改善しかないメジャーアップグレードを推し進めるのか、という質問があった。 この記事によれば、コンピューターベンダーはより多くの利益を求め、Microsoftに新しいパソコンの販売を促進するよう働きかけたという。 これらの買い物はすべてCEOのボーナスを増やすかもしれないが、あなたが取引の当事者になる必要はない。 絶え間ないアップグレードは計画的陳腐化の悪質な例であり、環境保護論者や消費者擁護論者は少なくとも1950年代からこれを非難してきた。 Linuxは常に比較的スリムだが、開発者が慎重に機能を追加するにつれて、メモリとディスクの必要量は増えている。 多くのコンピューター・ユーザーは、古いハードウェアに固執し、Windowsの新バージョンへの価値の疑わしい「アップグレード」の代替手段として、長年にわたってLinuxを採用してきた。 1+. 有害廃棄物との闘い 古いパソコンがまだ使えるのに新しいパソコンを買うのは、財布に負担をかけるだけでなく、地球とそこに住む人々にとって不必要な浪費だ。 コンピューターには多くの危険な化学物質が含まれており、低所得層の労働者や発展途上国の住民に有毒廃棄物として押し付けられる。 特に、ウィンドウズ11への切り替えによって、4億8000万キログラム（自動車32万台分）の電子廃棄物が増えると見積もられている。 廃棄物の多くが子どもたちによって掃除され、彼らの生活環境を汚染していることを考慮してほしい。 必要以上に貢献したくないはずだ。 2. 望むプログラムを実行する権利を維持する ハードウェアやオペレーティング・システムのベンダーは、しばらくの間、TPM（Trusted Platform Module）技術を推奨してきた。 ウィンドウズ11は、TPMバージョン2.0を必須とし、それを組み込んだ最初のバージョンのオペレーティング・システムである。 TPMは、アプリケーションにその出所を証明する鍵で署名することを要求し、コンピュータのハードウェア、ファームウェア、オペレーティング・システムに鍵をチェックさせる。 多くのユーザーが、正規のアプリケーションを装ったマルウェアをダウンロードするように偽装されているため、TPMはこうしたユーザーを保護することができる。 しかしTPMは、OSベンダーにインストールされるものを完全にコントロールさせるものでもある。 また、政府がそのプロセスに首を突っ込み、政府が気に入らないアプリケーションをベンダーにブロックさせたらどうなるだろうか？ 多くの人々にとって、アプリケーションのコントロールを大規模な機関に委ねることは、破壊的なプログラムを避けるための合理的なトレードオフかもしれない。 トレードオフに関するバランスの取れた評価については、ジョナサン・L・ジットレイン法学教授の著書『The Future of Internet and How to Stop It』をお勧めする。 一方、TPMに代わる方法としては、コンピューターの衛生管理をしっかり学び、証明書を自分でチェックし、マルウェアに感染しにくいフリーソフトにこだわることだ。 3. 一貫性の維持と管理 企業やその他の大組織は、大量のコンピューターを維持しなければならない。 全スタッフをWindowsの新バージョンに移行させるのは一大プロジェクトであり、おそらく断片的に行われるだろう。 [...]