介護や医療、ヘルスケア、シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織づくりやサービスの内製化を進めてきました。
「『継続性アーキテクト』という生き方」というタイトルをつけていますが、タイトルで名詞化しているのは釣りで、アーキテクトの仕事について書いています。これは私がアーキテクトという仕事の可能性について考える中で、「継続性」に注目するとその仕事の価値がより発揮されていくのではないかと考えた内容をまとめたものです。
アーキテクトが抱える葛藤
私は役割柄、採用などでソフトウェアエンジニア（以下、エンジニア）と面談をする機会が多く、年に約200人くらいの方と話をしており、キャリアについて話を聞く機会も多くあります。その中で多くの方のキャリアのゴールとして挙がるものの一つに、ソフトウェアアーキテクト（以下、アーキテクト）があります。おそらくこれにはいくつかの意味があります。
まず、システムアーキテクチャの全体像を描ききれるような能力を身に着けたいということ。それから、システムアーキテクチャの根幹に関わるような部分での技術的な意思決定をできる裁量を得て、自身の能力を最大限に活かしたいということ。そして、その重要な役割に見合った待遇を得たいということ。
実際に優秀なアーキテクトとして働ける人材は採用市場での需要が非常に高く、エンジニアにとって技術で敬意を抱けるわかりやすい役割です。キャリアのゴールとして意識されるのもうなずけます。このときにイメージされるアーキテクトの仕事としては、高い設計能力を活かしてソフトウェアアーキテクチャを設計し、その完成形を形にすることかと思います。
一方、実際にソフトウェアアーキテクト（やそれに近い立場）として活動をしている人たちは、「本当にそれほどよい設計というものが必要とされているのか」「”Just enough” （ちょうどよい塩梅）な設計はどのくらいか」といった葛藤を抱えていたりすることはご存知でしょうか？
クリーンアーキテクチャやドメイン駆動設計のようなソフトウェアの設計に関する技法を学び、人一倍質の高いソフトウェア設計について関心があるはずのアーキテクトが、設計の価値について疑問を持ちながら働くのはなぜでしょうか。
一つ目の理由は、完成させてリリースすることではなく、サービスを成功させるということが仕事の中心になったことが挙げられます。とくにサービスの立上げフェーズではサービスがユーザーにとって価値を持つのか、使ってもらえるのかといったことのほうが大きな課題であることが多く、ソフトウェアの設計には新しい問題はないことが多かったりします。
二つ目の理由として、ソフトウェアが完成しなくなったことが挙げられます。サービスとしてチームが継続的に改善をしていくことが当たり前になりました。これによって一人の人が完成させた設計の姿というものの意義が相対的に薄れ、ソフトウェアの設計は継続的な開発とチームの能力によって常に変化していくものとなりました。
様々な能力水準を持つ人たちが入れ替わりながらソフトウェアをメンテナンスしていく場合、油断をすると深い設計意図を持った初期設計は容易に崩されることになります。
アーキテクトは、優れた設計をするために能力を高めた結果、高度な設計をするよりもほどよいわかりやすさで軽量にスピードをもって開発をしていけるほうが価値があるのではないかという感覚を持つに至る人が多いようです。
では、アーキテクトの価値は減ってきたのか。それをこれから考えていきたいと思います。
アーキテクトが必要なソフトウェアの「規模」と「複雑さ」
アーキテクトが必要とされるシステムの特徴は、技術難度が高いこと。技術難度の高さには「規模」と「複雑さ」という要素があります。規模と複雑さの両方の特性の難度を持ったシステムも存在します。
「規模」の難度が高いとは、システムの規模が大きいソフトウェアの開発です。関わる人が多いことも大規模システム開発という呼び方をしますが、ここではあくまで作っているものの規模の大きさを指しています。機能や業務が多く、その結果としてシステム規模が大きくなる場合と、多くのユーザーによる大規模トラフィックをさばくためにシステム規模が大きくなる場合が代表例です。
機能や業務が多い場合の例としては銀行や保険のような金融業や大手のECなどが挙げられます。大規模トラフィックをさばくための例としてはLINEやメルカリのようなサービスが挙げられます。
「複雑さ」の難度が高いとは、システム化する対象のドメインが持つ困難さです。設計難度の高い課題として知られている非同期処理や並行処理、分散処理などに関する技術的な解決を必要とするようなものが代表例になります。そのもの単独で難度が高いのもありますし、信頼性や応答速度が一定の水準を求められたり扱うデータの件数や容量といった複数の条件を考慮した結果、実用可能な設計を考えると難度が高くなるということもよくあります。
例えば、同時接続数の多い動画配信の仕組みや大量のメッセージを遅延なく並行に送信し続けるメッセージングアプリの仕組みなどは「複雑さ」の難度が高い場合の例と言えます。
「積み重ね」がアーキテクトの可能性を広げる
技術難度の高い問題を解くことはアーキテクトの大きな価値です。ただ、サービスの成長が停滞してくると新しい課題というのが生まれにくくなってきます。こうなってくると、アーキテクトが腕を振るう仕事というのが少なくなるため、アーキテクトは新しい課題を求めて別のサービスの立上げへ仕事の場を移したり、社内でその場がないとなると職場を変えて自分の次の活躍の場を探したりします。
こうして新しい課題を求めて次々と仕事の場を移していくのは、性質の違う課題を解き続けて自身の能力を発揮できるという楽しみはあります。一方、サービスの成長の停滞とともにリセットして次を探すという形になるため、自身の設計判断や問題の解決が最後に社会にインパクトを残すというところまでつながりにくいという課題もあります。
では、アーキテクトに他の選択肢はないのだろうか。そう考えていた自分にとってヒントになったのが関将俊さんという人の存在です。関さんはRubyKaigi や JaSST、XP祭りなどのカンファレンスでご自身のチームやプロダクトについて発表をしています。続けて発表を見ていく中で、ストーリーが続いていることに気づきました。たとえばご自身の仕事のチームとXPについて話をしている発表だと、2004年から2007年、2008年、そして2019年と、同じコンテキストで続いているチームの話をしています。
時系列で発表を追っていくと、チームやプロセス、そしてソフトウェアの成熟度合が上がっていっていることがよくわかります。関さんの話の環境はスタートアップがサービスを立ち上げるというような文脈とは違っているのですが、このその時その時の状況で必要な工夫を重ねていくことで成熟度合を上げていくという仕事の仕方はヒントになります。
現代では「作って終わり」という開発は減り、リーンスタートアップのような考え方が一般に知られるようになりました。こうした変化の中でアーキテクトは、目新しい問題を解き続けるというキャリアとは違う、新しいキャリアを歩けるようになってきました。
こうした新しいアーキテクトのあり方を、この記事では「継続性」のアーキテクトと呼んでいます。スナップショットでサービスにとって必要な設計をするのではなく、サービスに継続して関わり、成長段階に合わせて必要な設計をし続けるという役割です。
優れた初期設計をつくり難しい問題を求めて転々とするのではなく、サービスの成長段階に併走して、その時々に出てくる課題をアーキテクチャとチームの中でどのように解決していくかを考え、実行をしていく。
体制や成長、目指す姿など、その時々のサービスの状況にあわせて設計の見直しをかけたり、チームへ働きかけたりして仕事の場の成熟度合を上げていく。そして、それによって社会に価値のあるインパクトを出す仕事をする。
自身の仕事にこだわりを持っているエンジニアにとって、そんな継続性のアーキテクトの仕事は魅力的な仕事になると考えています。
「継続性のアーキテクト」が活躍できる環境とは？
最後に「継続性のアーキテクト」が実現できるのはどのような環境か。企業やサービスに必要な条件を、5つ挙げてみました。
1．今後長きにわたってニーズが増えるマーケットである
2．マーケットの置かれた環境が変化していく
3．対象となるマーケットで1位になる力を持っている
4．ビジネスモデルが変化していく
5．システムが硬直化することを許容しない
継続性のアーキテクトとして働くには、1つ目に、ビジネスの寿命が長いことが条件になります。どれだけサービス開発の場を継続性をもたせてやっていこうとしても、ビジネスが終わったら寿命はそこで終わりです。これから長期間に渡って、ニーズが拡大していく市場であることはなによりも大事な条件になります。
2つ目に、属するマーケット自体の環境が変化しやすいと、それに合わせてビジネスが変化する必要があります。経済動向や法規制の影響など外部要因でビジネスが変化を求められる環境は、ドメインの変化にあわせて変化していく必要があり、継続性のアーキテクトの価値が発揮しやすい環境です。
3つ目は、そのマーケットで他社に打ち勝ち、1位になれる力を持っているかどうかです。採用面談をしていると、「〇〇業界に興味があるので、その業界に属する企業に行きます」という言葉をよく聞きます。興味のある業界に属する企業に就職することはすばらしいことですが、その業界の中で競争力のあるポジションを取る力があるかは重要です。その力がないと、やはりビジネスの寿命によってサービス開発の継続性は途絶えることになります。
4つ目に、ビジネスモデルを変化させていけることもポイントです。たとえ成長を続けるマーケットであっても、ビジネスモデルに変化がない場合は新しい性質の問題は生まれにくくなります。
そして、5つ目は、すでに運用されているサービスが硬直化していないこと。多くの場合、リリースしてから順調に拡大し、収益もそれなりに上がっているサービスは、変更しないことが優先され変化することに保守的になります。システムを硬直化していくことを良しとしない文化を持つ企業に行くことは継続性のアーキテクトが価値を発揮する大事なポイントです。
こうした条件を兼ね備えた環境であれば、ビジネスの変化に応じてソフトウェアが変化し続けていくことが価値を持ちやすいため、継続性のアーキテクトという働き方が実現できると考えています。
筆者の所属しているエス・エム・エスではここに書いたような視点で、アーキテクトという仕事を位置づけています。待遇もふくめてアーキテクトがキャリアのゴールになるような会社にしているので、関心のある方はぜひスライドも見てみてください。
アーキテクト人材のキャリアの考え方から、エス・エム・エスでのアーキテクトとしての機会や環境について紹介しています。
少しでも気になったら、軽く話してみるだけでも結構ですので、下記リンクからご連絡ください。お待ちしています。
