Opt Technologies Magazine

オプトテクノロジーズ 公式Webマガジン

テクノロジーマネジメント専門チーム「チーフアーキテクト室」はじめました

制度・環境 マネジメント アーキテクチャ DevOps SRE

alt

2021年10月に新設したOpt Technologiesのテクノロジーマネジメント部門「チーフアーキテクト室」についてご紹介します。

あいさつ

Clojurian 1のlagénorhynque (a.k.a. カマイルカ 🐬)です。

昨年2021年の初めにはClojureでのGraphQL API開発に関する記事を書きました。

その後の私は、特定の開発チーム/メンバーとプロダクトから開発組織全体へと向き合う対象を広げ、技術面のマネジメントをリードする役割(ロール名はChief Architect)を受け持つに至り、Opt Technologiesおよびオプト全社の技術的なテーマについて日々試行錯誤しています。

本記事では、昨年秋に新たに発足したテクノロジーマネジメント部門「チーフアーキテクト室」がどのような背景から生まれ、何を目指しているのか簡単にご紹介します。

チーフアーキテクト室とは

チーフアーキテクト室は2021年10月に新設した開発組織横断的なテクノロジーマネジメント専門の部署です。

オプトの開発組織Opt Technologiesが携わるシステム開発運用に関して

  • 様々なレイヤーの標準化
  • 仕組みの自動化/高度化
  • 知見共有/スキルアップの支援

を推進することを主要なミッションとしています。

発足以降、現在まで私lagénorhynqueがこの部門の室長(= チーフアーキテクト)を務めています。

開発組織/企業全体の組織とシステムという両面のアーキテクチャ2を最適化したいという思いから、広い意味でのアーキテクト3のトップとして「チーフアーキテクト」(Chief Architect)というロール名を採用しました。

実態としては主に(技術寄りの) CTOやVPoTに近い役割を想定しています。

ちなみに2022年6月現在、Opt Technologiesにはチーフアーキテクト室のほかに3つの開発部門(ビジネステクノロジー開発部、データテクノロジー開発部、AIソリューション開発部)があります。

3つの開発部門がそれぞれ特定の業務領域のシステム開発運用もしくはR&Dを担うのに対して、チーフアーキテクト室はそうした個別の開発部門を超えて開発組織/会社全体の観点から共通の技術マネジメント戦略を立案し施策を推進するという位置付けです。

チーフアーキテクト室発足の背景

Opt Technologiesの現在

オプトの内製開発専門組織Opt Technologiesは2016年春に正式に発足し、この2022年春で丸6年になります。

インターネット広告代理店という営業職が主体となった企業文化の中で初めて本格的なソフトウェア開発専門組織を立ち上げ、エンジニア/エンジニアリングマネージャー問わず自分たちに合った制度や環境を自分たちで議論しながら整備し、様々な業務を支えるために多数の開発チームとプロダクトを発展させてきました。

個々の開発チームはそれぞれに担当プロダクトの技術選定から開発運用プロセスまで広範な裁量を持ち、多種多様なチームとプロダクトが集まるエコシステムが育っていきました。

執筆時点の開発組織の規模は全体で60名ほど(オプト全社約600名の1割に相当)とそれほど大規模なものではありませんが、4つの開発部門、約10の開発チーム、(安定運用フェーズのものもの含めて)大小30ほどのプロダクトで構成されています。

利用している技術もフロントエンド、バックエンド、インフラ、データ分析に関して幅広い言語やライブラリ/フレームワーク、ツールが含まれています4。

2021年春の転機

Opt Technologiesにとって大きな転機となったのは、発足から5年が経過した昨年2021年春頃に前任のCTO (@hiraivaさん)が退任/退職し、経験豊富な複数のエンジニアたちの退職も重なったことでした。

開発組織の運営体制を再構築して組織的な開発力を向上させていくためには何が必要だろうかという議論を進め、その中で注目したひとつの重要なテーマが戦略的なテクノロジーマネジメントの必要性でした。

改めて組織の状況を振り返ってみると、Opt Technologiesでは個々の開発チームとメンバーによる自治と自助努力によってプロダクトの開発運用が支えられてきました。

それぞれのチームとプロダクトの目的に合わせて自由に選択できる範囲が非常に広いことから、開発者としてゼロから検討し試行錯誤する機会が充実している一方で、各チーム各メンバーで独自に再発明/再発見しなければならない領域が多いことも意味していました。

また、普段の業務において個々の開発チームは分かれて活動しており、自然とチームを超えた知見共有が促される仕組みも整備されていないためチームやメンバーに閉じた知見が多くなり、せっかくの経験がチームの再編やメンバーの出入りによって失われうる属人性の高い状態にありました。

そのような潜在的なリスクがフルリモートワークで変化した働き方の中でいよいよ顕在化しつつありました。

そもそも小さな開発チームのメンバーで開発運用に必要なスキルセットを一通りカバーできるとは限らず、技術的な意思決定であれ開発運用プロセスであれ一貫した設計思想のない偶発的な選択が積み重なればプロダクトの開発運用が非効率になり、品質が損なわれ、寿命がいたずらに縮むことにもなりかねません。

その当時、私lagénorhynqueはエンジニアリングマネージャーを始めて半年ほどでしたが、ソフトウェアアーキテクトの視点で見ても現状のやり方は開発組織としてさすがに非効率かつ脆弱なところがあり、明確な意志を持って組織的な技術戦略を描く存在としてのCTOもしくはVPoTが必要だろうと考えていました。

新体制の構築

まずは私の所属している開発部門(広告運用支援ツール開発を担うビジネステクノロジー開発部)の範囲での開発の標準化を模索し始めてみましたが、特定の開発チーム/プロダクトに向き合いながら片手間で組織全体の技術問題に立ち向かうにはどうしても限界がありました。

CTOもしくはVPoTのような開発組織横断的な役割を帯びてテクノロジーマネジメントを推進する専任のチームを作る必要があると思うに至り、準備期間を経て2021年10月に「チーフアーキテクト室」という小さな部署を新設しました。

ちなみに、社内にCTOというポストを再び設けるという選択肢もありましたが、CTOという役割に求められうる役割は多岐にわたる中で一個人に最終決定権を集中させるよりもエンジニアリングマネージャーのリーダー複数名(Opt Technologiesの部長陣)で主要な役割を分掌する体制で進めていくのが妥当そうだと考えられたことから、当面はCTOを設置しないという判断に至りました。

その際に開発組織のマネジメントにおける役割分担を明確にするため、RACI図を用いてロールごとの実態の把握と調整も行いました。

将来に向けた構想と現在の取り組み

新設部門チーフアーキテクト室の現在のミッションは、Opt Technologiesが携わるシステム開発運用における標準化、自動化/高度化、知見共有/スキルアップ支援を推進することにより開発組織としての力を高めることです。

しかし私はすでにその先のより大きな可能性にも期待しています。

中長期構想

  • Opt Technologiesのシステム開発運用力の継続的向上

というコアミッションにとどまらず、

  • エンジニアに限らない全社員のITリテラシーとプログラミング/ソフトウェア開発についてのスキルアップ支援
  • オプトを含むデジタルホールディングスグループを横断したテクノロジーマネジメントの推進

といった領域にも積極的に関与し、IT/デジタルの力をビジネスに最大限活かせる会社へと成長していくのを技術面から後押ししていこうと構想しています。

ITエンジニア/プログラマのひとりである私にとっても、ネット広告/Webマーケティングを主なフィールドとする事業会社の中でエンジニアが重要な役割を果たす主役となるように環境を整えていくのは取り組みがいのある仕事であり、それによってビジネスの可能性が広がっていくのは大きな喜びです。

ネット広告代理店として知られるオプト、デジタルシフトの推進を掲げるデジタルホールディングスが自らDXを実践し事業を生まれ変わらせていく過程では必ずエンジニアの力が重要な意味を持つでしょう。

会社全体へ向けた取り組みはまだまだ動き出したばかりですが、所属部門/チームの枠組みにとらわれずエンジニアらしさを活かしながら幅広く活動していくことが新たなコラボレーションに繋がるのだと実感し始めています。

短期目標

一方、当面の短期的な目標として

  • 「生産性」の定量分析
  • 定期的なプロダクト開発運用成熟度のチェック
  • アプリケーション開発運用の基礎としてのインフラ共通基盤の構築
  • プロダクトを安定運用していくための支援体制の整備

に重点的に取り組んでいます。

ソフトウェア開発における「生産性」とは何かというのは単純な答えのないテーマですが、我々の組織の場合にどのような数値で生産性を捉えて継続的に維持向上させるのか定義し分析し可視化しようとしています。

現在はGitHubでの活動状況に注目してFindy Teamsというサービスも利用しながらDevOpsのFour Keys 5などの指標を分析し始めています。

また、開発している個々のプロダクトの開発運用プロセスを継続的に高い水準に引き上げていく標準化の一環としてその成熟度(maturity)を定期的にチェックする枠組みを整えようとしています。

具体的には、日本CTO協会によるDX Criteriaや書籍『プロダクションレディマイクロサービス ――運用に強い本番対応システムの実装と標準化』などを参考にしながら組織とシステム(マイクロサービスエコシステム)に関する推奨プラクティスの実践状況をチェックする項目を整備しています。

そのほかにも、主にDevOpsやSRE (site reliability engineering)のアイディアを参考にしながら、より効率的にシステムを開発運用するための仕組み作りを着々と進めています。

重視している理念

チーフアーキテクト室はオプトという会社組織とそこで開発運用するシステムのより良いアーキテクチャを構想し実現していく役割を果たすためにあらゆる手段を用います。

その過程では、これまでに醸成されてきた開発組織Opt Technologiesの良き文化を踏まえながら以下のような考え方を大切にしています。

オープンなコミュニケーションとフラットな組織

  • クローズドなコミュニケーションを回避し、情報の非対称性を解消する

人事や顧客/案件固有のセンシティブな情報に関するものを除いて社内での様々な意思決定に関わる議論が社内のオープンな場で行われ、記録され、共有されること、それは組織内のコミュニケーションを円滑にし、十分な情報を得て組織の問題に主体的に向き合うために不可欠なものだと考えています。

例えばマネージャーの役割を持つ者だけがアクセスできるような情報は必要最小限にとどめ、メンバーを信頼してデフォルトで情報を開示し、説明の責任を果たし、入手可能な情報の不均衡を抑制します。

  • 階層的な構造を排除し、心理的安全性を確保する

職位や在籍年数、年齢などの属性の違いによる上下関係の意識、それに基づく一種の権威的で非対称なコミュニケーションスタイル6は活発なコミュニケーションや信頼関係の醸成を阻害する可能性があります。

人それぞれに仕事上の役割分担/分業による権限と責務の範囲に差異があってもそれは貴賤を決めるものではなく、「上」の立場だから、「下」の立場だからとコミュニケーションのしかたを変える必要はありません。

立場の違いによらず対等であることを基本的な前提とし、自由7な意見の表明を歓迎し尊重します。

ちなみに、Opt Technologiesは主に中途採用のエンジニアたちが集まって始まった組織という歴史的経緯も影響してか、実態として上司部下や先輩後輩という意識がかなり希薄な傾向があります。

  • フェアで合理的な議論を重視する

プロセスとして対等な関係を担保するため、組織の意思決定や活動に対する提案や異議、批判などを自由に議論できるチャネルをフォーマルなものからカジュアルなものまで多重的に確保します。

論理的で合理的な議論によって自分たちで組織のあり方を決めていく(裏を返せば、非論理的で非合理的なことを押し付ける/押し付けられるようなことはしない)というのがOpt Technologiesの良き伝統であり、開発組織の範囲にとどまらず会社全体として重視したい発想でもあります。

文化とはそのコミュニティの構成員の言動、振る舞いの積み重ねで醸成されるものであると考えており、私自身も日々実践することを大切にしています。

ちょうど書籍『Team Geek ――Googleのギークたちはいかにしてチームを作るのか』で語られていることにも大いに共感があります。

チーム/個人の自立と自律

  • それぞれのチーム/個人で主体的に動くことを支援し尊重する

Opt Technologiesの部門、チーム、個人それぞれの単位で自らより良いあり方を描いて組織の広範なマネジメントに関与していくことを奨励します。

日々の目の前の業務に限定されない組織的なテーマに意見を述べたり行動を始めたりする人が支援され、評価される環境をより充実させようとしています。

マネジメントとはそもそもマネージャーというタイトルを持つ人だけが向き合うべきことではなく、緩やかにマネージャーの不要な組織にしていきたいという思いがあります。

  • 自治的/自律的で分権/分散的な組織とシステムを志向する

マイクロサービスアーキテクチャの文脈でも「コンウェイの法則」(Conway's Law)や「逆コンウェイ戦略」(Inverse Conway Maneuver)が取り上げられることがよくありますが、組織とシステムの間には相互作用があることを認識し、構造(構成要素とその関係)をふさわしい形に設計しましょう。

スケーラブルな、つまり規模の変化に柔軟に対応できる組織およびシステムとして運営するため、(開発チームに限らず任意の)チームとシステムコンポーネントが自律的にそれぞれの責務を果たしつつ全体としてビジネスの目的に向けて機能する分散的なアーキテクチャを基本パターンとして採用します。

現在のOpt Technologiesは決して巨大な開発組織ではありませんが、過去数年の間に発展してきた自治を重視する組織文化との相性も良いと考えています。

  • 多様性(diversity)と持続可能性(sustainability)を重視する

近年、DE&I (diversity, equity and inclusion)やSDGs (Sustainable Development Goals)の理念に対する企業としての取り組みの重要性が高まっていますが、ITシステムを開発運用する組織の範囲においても関わる人々の多様なあり方を肯定し包摂していくことがより大きな価値を生み出し持続的な発展に繋がっていくものと考えています。

この組織の主要な構成員であるエンジニアもそれぞれに異なるバックグラウンドからスキルを高め個性を発揮しながら組織とシステムに向き合っています。

その力が全体の中で最大限に活かされ、一方で属人性や偶発的な複雑性に圧倒されてしまうことがないように、共通のプロトコルや仕組み、環境を整備することこそがチーフアーキテクト室のミッションです。

DevOps/SREの思想と実践

DevOpsとSRE (site reliability engineering)という概念は、その背景にもなっている「アジャイルソフトウェア開発」と同様に一種の思想や文化運動でありプラクティスの集まりでもあり、ソフトウェア開発コミュニティの中で発展してきたもので唯一の共通の定義は存在しません。

両者の関係8も含めて様々な捉え方が可能ですが、Opt Technologiesの文脈においても組織とシステムをより高めるための発想として大いに共感があり、特に以下のような広い意味で重視しています。

  • 開発(dev)と運用(ops)に限らず領域/部門/チーム/職種を超えて効果的にコラボレーションできる組織文化を醸成する

DevOpsというと狭義にはCI/CDのパイプラインを整備し、テストやインフラ構築をコード化/自動化し、開発と運用の役割やプロセスを統合していくことを指すことが多いでしょう。

しかし、より一般化してdevとopsとの間にとどまらず広く組織の全体、さらには組織の外に対してもコミュニケーションを促進し、コラボレーションを発展させていくという組織文化変容の取り組みへと拡張することもできます。

『Effective DevOps ――4本柱による持続可能な組織文化の育て方』でも語られているように、システム開発運用に関する技術的な手法やツールのみに注目するのではなく、組織そのもののあり方に向き合い変えていく取り組みが極めて重要だと考えています。

  • ソフトウェアエンジニアリングの発想で非本質的な業務を効率化/最小化し仕組みの信頼性を高める

SREといえばソフトウェアシステムの運用における信頼性向上のための具体的なプラクティス(サービスレベル目標(SLO)、エラーバジェット、ポストモーテムなど)が思い浮かびますが、SRE的なアプローチが活きるのはシステム運用の領域にとどまりません。

例えば、私たちが向き合っているネット広告というビジネスドメインや会社のバックオフィス業務はまだまだ煩雑で属人的な手ごわい「運用」にあふれています。

運用するシステムの信頼性を継続的に高めながら、広く会社全体のプロセスをソフトウェアエンジニアらしい発想で変えていこうとしています。

かつてOpt Technologiesには広告効果測定ツールADPLANのためのSREチームが存在しましたが、今回新たにチーフアーキテクト室の活動の一環として組織横断的に環境整備や支援に取り組むSREチームを立ち上げようとしており、『SREの探求 ――様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践』などから他社/コミュニティの事例に学びながら動き始めています。

おわりに

私はOpt Technologiesの発足初期からの約6年をともにしてきたエンジニアのひとりとして、オープンでフラットで自由を大切にする組織文化がとても気に入っています。

一方で、開発組織の歴史の積み重ねと内外の環境の変化の中で直面している困難も確かにあります。

ソフトウェアシステムの開発運用がビジネスにおいてますます重要な意味を持つようになってきているからこそ、ITエンジニアは幅広いフィールドで業務に寄り添いながらシステムだけでなく組織のあり方さえ変えることができる存在だと考えています。

困難を乗り越えビジネスのさらなる成長へ向けて、システムと組織のアーキテクチャを構想し実現していく――ソフトウェアエンジニアとして取り組みがいのある仕事ではないでしょうか。

Opt TechnologiesではDevOpsやSREの発想を活かして組織とシステムを変革したい野心的なエンジニアを求めています。

カジュアル面談も可能ですので、下記リンク先よりお気軽にご応募ください。

  1. Clojureプログラマはたいてい"Clojurian"または"Clojurist"と呼ばれます。↩

  2. アーキテクチャ(architecture)とは、望む性質に向けて設計判断を積み重ねた結果として現れる構造であると捉えています。(ソフトウェア)システムはもちろん人の組織にもアーキテクチャを見出すことができます。↩

  3. アーキテクト(architect)とは、(アーキテクチャという用語との関係でいえば)アーキテクチャを構想/設計する人のことです。ちなみに英語ではarchitectという語を動詞として使うこともできます。↩

  4. 主な利用技術について詳しくはOpt Technologies公式サイト参照。↩

  5. cf. エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog↩

  6. 例えば何らかの意味で「上」の立場の人が「下」の立場の人を呼び捨てにする、「下」の立場の人が「上」の立場の人を特別に丁重に扱うなど。↩

  7. 自由(liberty)とは無条件で何をしてもよいという意味ではありません。法哲学/政治哲学の古典的な議論(J.S.ミル『自由論』)において「他者危害原理」というものが知られていますが、そこでは他者に危害を加えない限り何をしようとかまわないことが自由と定義されます。自由(もしくはより一般に人権)という概念には内在的な制約があると考えられるのです。↩

  8. 有名な理解のしかたは class SRE implements DevOps 、つまり抽象的な思想、理念(インターフェース)としてのDevOpsに対して具体的な実践例(具象クラス)としてのSREというものです。↩