ロナンです。Equal1で量子ソフトウェアエンジニアリングを統括しています。私たちは、高度なスピンベース技術を用いて、完全統合型の量子コンピュータを設計・構築しています。Equal1は、アイルランド、アメリカ、カナダ、日本、ルーマニア、そして私が住んでいるオランダにオフィスを構えています。以前は、量子制御システムを開発するQbloxで働いていました。
Equal1では、高性能量子コンピュータ「RacQ」を稼働させるフルスタックシステムの構築に注力しています。このシステムは、数千個の論理補正量子ビット、さらにはそれ以上の規模まで拡張できるように設計されています。量子プロセッサ（QPU）の「頭脳」とも呼ばれています。
毎日新しいことを学べる上に、知識豊富で優秀な同僚たちと一緒に仕事ができるので、私の仕事はとても魅力的です。このブログを始めたのは、私が学んだことを皆さんと共有するためです。もちろん、秘密を漏らすつもりはありませんよ！
お気軽にronanまでメールしてください。ronanさらに詳しく知りたい場合は、LinkedInでつながってください！
***Disclaimer: While I work at Equal1 by the day, this blog is a personal project and does not reflect the views of my employer. The thoughts, ramblings, and opinions shared here are mine alone and haven’t been vetted, approved or modified by anyone but myself.
***Qblox在籍時の私の役割はシステムアーキテクトでした。以下は、当時の私の役割に関するメモです。
これは私がよく聞かれる質問です。「システムアーキテクト（sysarch）には具体的にどのような仕事が期待されているのですか？」答えは企業、事業展開国、ビジネス領域によって異なります。しかし、一つだけ変わらない概念があります。それはコミュニケーションです。
はい、アーキテクトの役割は、開発チームやエンジニアリングチーム、経営幹部、顧客など、誰に対しても複雑なアイデアを分かりやすく伝えることです。まずは顧客や製品チームと共に問題点を理解することから始まります。そして、顧客を満足させるソリューションを生み出すことこそ、この役割の醍醐味なのです。
そこから、従来型のシステム要件分析、そして多くの場合、概念実証プロトタイプ作成フェーズへと進みます。このフェーズでは、私は通常、直接作業に携わります。その後、製品開発へと進み、私は技術リーダーとして、製品が完成するまで様々な部門のチームと連携して作業を進めます。最後に、製品の発売後のサービス提供が行われます。
アーキテクチャ上の意思決定はどのように行うのでしょうか？アーキテクトの役割は必ずしも決定を下すことではなく、意思決定に必要なインプットを統合することで問題を明確化することです。例えば、製品チーム（「この新製品の開発コストはいくらですか？市場投入までの期間はどれくらいですか？」）やCxOチーム（「この新技術に投資すべきでしょうか？ROIと長期戦略はどうなっていますか？」）などが挙げられます。
これは、主観的な判断を挟まず、考えられるすべての解決策の長所と短所を調査し、明確に定義するという、デカルト的な思考法に基づいています。また、導入にかかる労力だけでなく、長期的な保守、運用コスト、チームの認知負荷なども考慮に入れ、コスト対効果を評価することでもあります。
さらに重要なのは、社会的な連携を交渉することです。なぜなら、エンジニアが嫌がったり、プロダクトマネージャーが理解できなかったりするアーキテクチャの決定は、必ず失敗するからです。決定を下すには、関係者全員を巻き込む必要があります。プロダクト＆ビジネスループにおいては、選択したものがビジネス価値をもたらすことを確認してください。エンジニアリングループにおいては、シニアエンジニアから批判を求め、彼らが実行に責任を持つようにしてください。
ソフトウェア製品を持つすべての企業にとって、これは繰り返し問われる質問です。「なぜ、いつリファクタリングすべきか？」既存の製品が遅く不安定で、蓄積された技術的負債のために問題の修正に時間がかかりすぎる場合、リファクタリングの時期だと考えるのが一般的です。しかし、答えは必ずしも正しいとは限りません。むしろ、アーキテクトの役割はセカンドシステム効果を防ぐことです。
私の個人的な哲学は、day-1の決定を適用し、「双方向の扉」テストでそれらをチェックすることです。リファクタリングは、一方通行の扉（プライマリデータベースパラダイムの選択のように、元に戻すことがほぼ不可能）なのか、それとも双方向の扉（内部ライブラリの選択のように、後で簡単に変更可能）なのか？一方通行の扉は徹底的な検証が必要ですが、双方向の扉はスピードが求められます。
一見すると、システムアーキテクトの役割は、エンジニアリングチーム（問題解決に追われる時間を減らす）と製品チーム（市場投入までの時間を短縮する）の両方に価値をもたらす適切なエンジニアリング文化を提唱することにもある。
一般的な考え方は、_開発の後半で時間を節約するために、今エンジニアリング/ソフトウェア スタックに投資する_ことですが、実際の課題は、投資と過剰設計の適切なバランスを取ることです。つまり、価値を付加しないものを過剰に設計するのではなく、製品の開発とメンテナンスを容易にするための適切なツールとソフトウェア コンポーネントを開発します。
これはまた、アーキテクトが製品チームや経営幹部チームと頻繁にコミュニケーションを取り、常に問題解決に追われるのではなく、将来を見据えた適切なエンジニアリングに力を注ぐチームの活動を促進する必要があることを意味する。
ある時点で、システムのリファクタリングだけでは不十分になります。なぜなら、コンウェイの法則が適用されるからです。「*システムを設計する組織は、その組織のコミュニケーション構造を模倣した構造を持つ設計を生み出すことになる。」
解決策は必ずしも人員配置を変えることではなく、チームの成果を事業組織と整合させ、両チームの成果がそれぞれの部分の総和よりも大きくなるようにすることです。チームのコミュニケーション構造が非効率なために十分な価値を生み出せない場合は、より優れたコンポーネントと、事業にさらなる価値をもたらすAPIの約束によってチームの成果が定義されるようなシステムを構築します。また、チームが新しいコンポーネントを作成できない場合は、作業をよりシンプルなコンポーネントに分割し、より分かりやすいAPIの約束に落とし込みます。
しかし、より重要なのは、チームと組織間の社会的連携を促進することです。チームが自ら変化してより大きな価値を生み出す会社を想像してみてください。それこそが理想的な状況ではないでしょうか？
AIは私の働き方をどのように変えたか？大きく変わりました！開発者がバイブコーディングを行うように、アーキテクトはコード生成のための入力としてLLMに直接与えることができる「バイブデザイン」（およびバイブシステム要件）をより上手に記述する必要があります。
AIはデザインの反復作業において非常に役立ちます。同じデザインの多くのバリエーションを迅速に生成できるため、さまざまな選択肢をより迅速に検討できます。そして、それらのデザインは迅速にプロトタイプ化され、その前提や開発の複雑さを検証できます。
しかし、より重要なのは、AIはエンジニアに取って代わるものではなく、彼らの能力と創造性を増強するためのものであることを忘れてはならないということです。AIは、エンジニアの判断力や専門知識を代替するツールではなく、設計プロセスを強化するためのツールなのです。
例えば、以下の図を見てください。右側の図は量子ビット3（Z 2 Z 3 ）にエラーがあることを示していますが、実際には量子ビット1と2にビザンチンエラーが発生しているのです。このことを指摘できるLLM（量子法修士）は何人いるでしょうか？（詳しい説明はこちら）
***