試験開発協力者 特別座談会・前編
新試験「LinuC システムアーキテクト認定」が始まります！
システムの設計・開発・運用までをトータルに管理できる
１ランク上の実力を持ったエンジニアを育てたい（前編）
LPI-Japanでは2023年11月から、LinuCの新しい認定として「LinuCシステムアーキテクト認定」試験を開始します。これは、これまでLinux技術者認定資格試験として実施されてきた「LinuCレベル1、2、3」の上位に位置する認定として新たに設けられたもので、システム開発のより上流の工程から、トータルな視点で設計や開発、そして運用までを管理できる技術者=システムアーキテクトとしてのスキルを見るものです。
「LinuCシステムアーキテクト認定」の試験開発（出題範囲及び問題の作成）にあたっては、各界で活躍されているハイレベルエンジニアの皆様から多くのご協力をいただきました。本日はその中から、8名の方々にお越しいただき、新試験に対する考え方や、試験開発にあたって大事にされたことなどを語っていただきました。さまざまな話題で盛り上がった座談会、その内容を前・後編の2回に分けてご紹介します。
システムをトータルに開発・管理できる人材を育てるための上位認定試験
----最初に、今回新しく始まる試験「LinuCシステムアーキテクト認定」について、主催者であるLPI-Japanの安良岡さんから、どのような試験なのか、新試験を立ち上げる狙いや、LinuC認定の中での位置付けについてご紹介いただけますか。
安良岡これまでもLinuCには、レベル1～３という3段階の認定が設けられていました。これらはLinuxの初心者から特定領域の専門家まで、主にLinuxの個々の技術に関する知識やスキルを見ることを目的にしています。
そうしたLinuxの技術認定について、近年多くの企業の方々にヒアリングしてきたところ、特定領域の専門家も大事だが、そうしたさまざまな特定領域の技術や知識を組み合わせて、1つのシステムをトータルに開発・管理できるような人材が欲しいという意見を多くいただきました。
そこで、LPI-Japanとしてもその声に応えるべく、従来のレベル1～３の階層に加えて、今回の「LinuCシステムアーキテクト認定」を新たに立ち上げることにしたのです。
----Linuxが社会のインフラも含めた多くの重要なシステムに使われるようになり、社会におけるLinuxの重要度も大きく上がりました。その結果、システム開発の中で必要になる個々の技術力だけでなく、そのシステム全体の目的や構成といった段階から、きちんと考えて、設計・管理できる人材が必要になったということでしょうか。
安良岡システムアーキテクトの認定を作ろうとした狙いはそういったところにあります。ただ1つ誤解のないように申し添えておくと、この「LinuCシステムアーキテクト認定」は、取得したことがそれだけで実力の証明になるというよりは、むしろ一人前のアーキテクトを目指して研鑽の旅に出るためのパスポートのように捉えていただくとよいかもしれません。
システムアーキテクトがシステム全体の構想を考えるということは、たくさんの要求や制約事項を満たすようにシステム全体の大局的な構成を決め、その全体が想定通りに動くように個別要素の動きを決める、というような複合的な課題を同時解決するバランス感覚のようなものが必要と考えています。それには当然技術的な知識だけでなく、自身のさまざまな経験の蓄積や、他の技術者、経営者、業務の担当者といった方々とのコミュニケーション、リレーションも欠かせません。
認定で担保された知識にこれらを組み合わせることで初めてアーキテクトとして実戦で活躍できるようになるものとイメージしています。
今回の試験作成に協力してくれた各分野の専門家から8人のゲストをご紹介
----まず、ゲストの皆さんからひと言ずつ、自己紹介をお願いできますでしょうか。
面面（おも）です。これまでずっとセキュリティをメインに手がけてきて、現在はサイオステクノロジーで執行役員を務めています。役員といっても、本人は現場で毎朝4時くらいから米国を中心にセキュリティ系のニュースを見張っていて、セキュリティリサーチとか、自社の情報セキュリティの「CSIRT（シーサート：Computer Security Incident Response Team）」を担当しています。
平野保険会社でインフラを担当しています、平野（ひらの）です。これまでの経歴では一貫してインフラを手がけてきましが、ここ数年は社内でPMO (Project Management Office)のような立場でテスト推進などを担当しています。モットーは、やはり「シンプル・イズ・ベスト」で、設計書を大量に書かなくてもすぐに理解してもらえるシンプルさを大切にしています。
嵯峨嵯峨（さが）と申します。現在の職場は8月からで、外資系ベンダーのサポートを担当しています。前職ではネットワーク系でキャリアを重ね、F 1の車両データ伝送用ネットワークを設計した経験もあります。実はインディーズミュージシャンとしても活動しているんですが、仕事でも音楽でも、クリエイティブなことをやる時に近道はしないというのが信条です。
西川西川（にしかわ）です。私は最初データベースやフロントエンドの技術者として業務アプリ開発をメインに手掛けてきて、その後LinuxやSolarisなどを学びながら、システム全体を1人で見られるようになってきました。仕事の上では、ワンステップ上を目指すために「好奇心」を大切にしています。また、「小さいことに“すべて“が宿る」を信条に一つひとつのことを丁寧に向き合うようにしています。
岡島岡島（おかじま）です。メインの業務は、システム開発会社でお客様から受注したシステムの開発を担当しています。最近はまたそれらに加えてAIなどの最新技術の研究・開発をしており、これまで提案が難しかった分野においてもシステム化を提案する仕事もしています。今回の試験開発では、実際のシステム開発の知見から、試験の内容が現場で使えるスキルに結びつくかといった観点でお手伝いをしています。
櫻井NECソリューションイノベータの、櫻井（さくらい）です。以前はオンプレミスの超大型システムでプロジェクトマネージャー（PM）などを務めてきて、今はMicrosoft Azureのクラウドを担当する部門で、やはりPMやアーキテクトとして仕事をしています。座右の銘が２つあって、1つは「SEは全知全能であるべき」＝SEはその業務内容をすべて知らないと成り立たない。もう１つは、モチベーションを大切にするためにも「自分にしかできないことしか、やらない」です。
芦川ニフティの芦川（あしかわ）です。業務はISPサービス向けのシステム開発・運用のエンジニアリングマネージャーを務めています。仕事のモットーというか、現在の立場でいつも心がけていることは、やはり若手技術者の育成をどうするかというところです。今回の「LinuCシステムアーキテクト認定」の試験開発も、そういう技術者育成に自分も貢献できればと思って参加させていただきました。
安江安江（やすえ）です。現在は製品ベンダーにてPost Salesの技術支援サービスを提供するポジションで働いています。また前職では、大規模プライベートクラウド基盤の設計・構築を複数領域の実作業者や全体PMなど色々なポジションにて担当しました。仕事にあたって大事にしているのは、「日々好奇心を忘れないように」ということですね。
技術者としての「面白そう」から若手育成まで、それぞれの目標で協力を決める
----皆さんそれぞれにお考えがあって、今回の試験開発に協力してくださったと思いますが、ご自身の動機や背景を教えていただけますか。
面一言でいうと、面白そうだなという興味ですね。以前からアーキテクト系のところはやってみたいと思っていたんです。また安良岡さんから、クラウド関連の内容をちゃんと取り入れたいというのを伺って、それは非常にいいなと思ったのも参加の大きなきっかけになりました。
平野私も、自分の興味が大きかったですね。自分でも試験はたくさん受けてたくさん合格している方だと思いますが、作る側の立場は経験がなかったので、お話をいただいて、これを逃す手はないと思って、すぐにお引き受けしました。
岡島私はもともとLinuCの認定試験が、一番実務に役立つ試験だと思っていたんです。自分でもレベル1～3まで認定取得したし、会社でも若手にぜひ受験するよう勧めているんですけど、そういうLinuCファンの1人として何か協力したいというのがありました。
----ありがとうございます。LinuCを応援してくださるアーキテクトの方に、こうして協力していただけるのは、本当にうれしいですね。
櫻井私は以前もLinuCの試験開発に参加していたのですが、その中でSE同士の会話ってやっぱり楽しいんですよ。皆さんのいろいろな考え方を聞いたり意見交換するのが面白くて、今回も進んで参加したというところがあるんです。
嵯峨僕も、人間関係は大きいですね。LPI-Japanとも結構長いお付き合いですが、今回も安良岡さん始め、お話をした皆さんの印象が大変良かったので、ぜひ自分も一緒にやらせてもらいたいと思いました。
「アーキテクトの能力を問う試験とは何か？」を議論しながら作っていった
----今回試験開発に協力いただいた中で、ご苦労されたことや、大切にしたことなどがあればお聞かせいただけますか。
平野まず今回、アーキテクトの能力を問う試験なので、そこをどう作るかに苦心しました。LinuCレベル1～3のように、個別の技術要素について問う方が問題は作りやすいんですけど、それだとシステム全体を見るというアーキテクト認定の主旨とは少し軸が異なってきます。個々の技術を組み合わせて1つのシステムに結実させる役割がアーキテクチャだと考えているので、そこをどう問うのかが、正直かなり難しかったですね。
面その「アーキテクトの試験としてどう作るか」には、非常に共感しますね。例えばセキュリティに関わる出題範囲を定義するとして、私自身はセキュリティが専門なので、現場の技術者に必要な技術は何かとかはよく分かっています。でも「アーキテクトの試験＝セキュリティ技術の試験」ではないんです。「アーキテクトとして知らなくてはいけない最低限のセキュリティって何だ？」というさじ加減と、そこに必要な部分だけをピックアップするというのが、すごく大変でした。これは、他の技術分野でも、試験の開発時にはいつも論点になります。
安江私も、アーキテクトの試験ならではの難しさは、非常に強く感じました。個々の技術知識を問うような内容ではなく、アーキテクトとしてシステムを構築する時に必要な能力を問えるような出題をイメージし、それを出題範囲として文字にしていくのがすごく難しかった。
櫻井そこを乗り越える上で、やっぱり出題範囲策定のためのディスカッションはすごく有効だったと思います。アーキテクトの試験を作るといっても、その前提となる自分の経験値やアーキテクトの踏むべきプロセスなどが、世の中一般のアーキテクト像と一致しているのかが、そもそも確信できない時が多々あります。
そこで皆さんと、例えば性能設計なら「昔のこのやり方は、今に合っているのか？」みたいな議論を何度も重ねて、今でも合っていると確信できて、初めて実際の試験開発に入る。そうした確認の手順を踏めたことが、質の高い設問につながったと思っています。