ソフトウェアアーキテクトにはキャリアパスがない
なぜソフトウェアアーキテクトに明確なキャリアパスがないのか？
理由は4つあります。
1.ソフトウェアアーキテクチャ事態の定義が業界で定まっていないから
まずそもそも「ソフトウェアアーキテクチャ事態の定義が業界で定まっていない」というのが事実として挙げられます。
暫定的に「ソフトウェアアーキテクチャのマインドマップ」を作成されてますが、これも数年後には変わっているでしょう。
2.アーキテクトの役割が拡大し続けているから
次に、ソフトウェアアーキテクトの役割が拡大し続けているという点が挙げられます。
10年前には、ソフトウェアアーキテクトは、モジュール性やコンポーネント、パターンといったアーキテクチャにおける純粋な技術的側面だけを扱っていればよかった。
現在、ソフトウェアアーキテクチャの役割は、マイクロサービスのようなより広範囲の能力を活用する新しいアーキテクチャスタイルの台頭により拡大してきている。
3.ソフトウェア開発エコシステムが急速に進化しているためにアーキテクチャが変化し続けているから
「ソフトウェアアーキテクチャとは、一度実装すると変更が難しいい、基本的な構造の選択に関するものである」という記述はもう古い定義です。
今や、マイクロサービスのような斬新的に構築していくという考え方にたった現代的なアーキテクチャが登場しました。
著作「進化的アーキテクチャ」のマインドマップ：https://mobile.twitter.com/Akapon2010/status/1505481288220033027
4.ソフトウェアアーキテクチャのについての資料の大半が、単なる歴史的経緯となってしまっている
Wikipediaのソフトウェアアーキテクチャのページを開くと、大量の専門用語や相互参照された広大な知識が確認できます。
確かに凄まじい情報量が積み重ねられていますが、Wikipediaにある専門用語は、その多くが役割を終えたものや失敗したものばかりです。
https://en.wikipedia.org/wiki/Software_architecture
数年前には間違いなく有効なソリューションだったものも、文脈の変わった現代では機能しないものとなっています。
結論、時代背景によってアーキテクチャはいくらでも代わります。
例えば、以前はOSサーバーを商用で利用するとすると、Windows Serverのライセンスとハードウェアが必要になりました。
この状態で10以上のサービスを使用するマイクロサービスアーキテクチャスタイルを使用することは不可能でしょう。
ところが、時代とともにLinuxがフリーのOSとして有効になり、ハードウェアが安く手に入るようになるにつれ、複数台のサーバーを動かすことが現実的になり、マイクロサービスアーキテクチャも有効なものであると認識されるようになったのです。
これはつまり、マイクロサービスアーキテクチャに時代が追いついたということでしょう。
その上さらにAWSやAzureを中心としたクラウドサービスが広がり、サーバーの保守運用作業はクラウドサービスに依存している状況です。。
この状態であればアーキテクチャはさらに高速に進化する可能性がります。
このような時代背景では、特定のアーキテクチャに関する資料を作成したとしても、すぐに廃れてしまう。（それゆえ、アーキテクトは「すぐに古びない本を書くにはどうすればいいか」を悩んでいた）
ソフトウェアアーキテクチャの仕事を定義してみる
これまでソフトウェアアーキテクチャの仕事が困難である理由を探してきたが、それでもあえてアーキテクトの仕事を定義すると以下のようになります。
ソフトウェアアーキテクチャの仕事をあえて定義すると、
であると定義した。
以下それぞれ詳細を説明していきます。
1.ソフトウェアアーキテクトの仕事：システムの構造の決定
システムの構造とは、そのシステムを実装するアーキテクチャスタイルの種類のことです。
などなどです。
アーキテクチャスタイルの一覧は以下のサイトから確認できます。
https://minegishirei.hatenablog.com/entry/2023/01/27/183831
2.ソフトウェアアーキテクトの仕事:アーキテクチャ特性
ソフトウェアアーキテクトの特性とは、ソフトウェアアーキテクチャの成功基準を定める大切な指標です。
可用性
信頼性
テスト容易性
スケーラビリティ
セキュリティ
アジリティ
耐障害性
デプロイ用意性
学習容易性
システムが適切に稼働するためにはこれらの特性を考慮することが求められます。
3.ソフトウェアアーキテクトの仕事:アーキテクチャ決定
アーキテクチャ決定は、システムをどのように構築するべきかのルールを定めるものです。
例えばレイヤードアーキテクチャ上でビジネス層とサービス層のみがデータベースに直接アクセスできるというアーキテクチャ決定を定めることで、プレゼンテーション層が直接データベースを呼び出すのを制限します。
アーキテクチャ決定とは、システムの制約を形作り、何が許されて何が許されないかを定めた開発チームへの指針へとつながる大切なルールです。
4.ソフトウェアアーキテクトの仕事:設計指針
例えば、
開発チームはマイクロサービスアーキテクチャのサービス間の非同期メッセージングを利用してパフォーマンスを向上させるべき
という設計指針が示されている。
アーキテクトに必要とされる8つの資質
与えられる役割や肩書き、職務に関係なく、ソフトウェアアーキテクトには次の8つの役割が期待される
アーキテクチャ決定を下す
アーキテクトにはチームや部門、あるいは企業全体の技術的な決定を導くために使用されるアーキテクチャ決定や設計指針を定義することが期待されている。
アーキテクチャを継続的に分析する
アーキテクトには、アーキテクチャや現在の技術環境を継続的に分析し、その上で改善策を提案することが期待されます。
アーキテクトの仕事を評価する場合、3年以上前に定義されたアーキテクトが今日時点でどれくらい持続されているかをビジネスと技術の二つの視点から評価することが大事です。
ですが、既存のアーキテクチャを継続的に分析することにエネルギーを注いでいるアーキテクトは少ないです。
加えて、アーキテクトが継続的に分析し忘れてしまいがちなものに、テストやリリースのための環境があります。
その結果、ほとんどのアーキテクチャは構造的崩壊を起こしてしまっているのが実情です。
構造的崩壊の結果、開発者がコーディングや設計を変更していく中で、パフォーマンスや可能性、スケーラビリティといったアーキテクチャ特性に影響が出てしまいます。
ユニットテストの通過率やCICDツールの活用、レビューやドキュメントの有無などは、必ずチェックし、アーキテクチャの特性を保守し続けることが求められます。
最新のトレンドを把握し続ける
アーキテクトには、最新の技術や業界の動向を把握しつづけることが求められます。
なぜなら、アーキテクトが下す判断は一定期間変更が難しいものがほとんどであるからです。
主要な業界の動向を理解し、それに沿うことはアーキテクトが見据えた適切な判断を下すのに役に立つでしょう。
決定の遵守を徹底してもらう
アーキテクトには、アーキテクチャ決定や設計指針の遵守を徹底することが期待されます。
- 具体例:レイヤードアーキテクチャの場合
レイヤードアーキテクチャは技術的な側面でいくつかの層に役割を分担するモノシリックなアーキテクチャです。（https://minegishirei.hatenablog.com/entry/2023/01/27/214843）
この場合、レイヤードアーキテクチャでのデータベースアクセスをビジネス層とサービス層のみに限定してます。
しかしながら、ユーザーインターフェースの開発者がパフォーマンス上の理由からデータベースにアクセスしようとした場合、
レイヤードアーキテクチャの規約から違反が発生してしまうことでしょう。
その後、アプリケーションやシステムはアーキテクチャの特性という面で期待に応えられなくなってしまう。
決定の遵守とは何か
つまるところ、アーキテクトが定義し文書化し伝達したアーキテクチャ決定や基本方針に開発チームがしたがっているかを、アーキテクトが継続的に検証することが求められるのです。
さまざまなものに触れ、経験している
アーキテクトには、さまざまな技術、フレームワーク、プラットフォーム、環境に触れていることが求められます。
これは少なくとも、さまざまな技術に親しんでいなければならないという意味です。
というのも、今日のほとんどのシステムにまつわる環境は異種混合のものとなっているからです。
この期待は開発者に求められるものと同じではなく、例えば、一種類のキャッシュソフトウェアの専門家であることよりも、10修理のキャッシュソフトウェアそれぞれの長所と短所をよく捉えていることが価値があるという意味です。
例えば、Webフレームワークについても、それぞれの長所と短所、言語などを把握しておくほうが良いでしょう。
事業ドメインの知識を持ってる
アーキテクトには、事業ドメインに関する一定の専門知識が求められます
事業ドメインの知識がなければ、システムが満たすべきアーキテクチャ特性を設定できず、ビジネス要件を満たす効果的なアーキテクチャを設計できないでしょう。
大手金融機関で働いていながら、平均方向性指数や社交契約、金利上昇などの一般的な金融用語を理解していないアーキテクトを想像してみると
まずコミュニケーションの点で躓く可能性が高いです。
アーキテクチャでもデータが重要である。
データは企業にとって最も貴重な財産であると言われている。
企業は手持ちのデータを有効活用したいtと考えている。
意思決定にデータを活用する方法を常に模索している。
既存顧客へのサービス提供、新規顧客の獲得、顧客維持率の向上、売上予測
データへのこのような依存は、すべてのソフトウェアがデータのために存在しているとすらいえる。
パイプラインアーキテクチャもイベント駆動アーキテクチャもスペースベースアーキテクチャもすべてデータが中心となっている。
そのため、アーキテクトは企業内のデータがつねに使用可能なものかどうかを確かめなければならない。
アーキテクトがデータについて意識する前に、企業内部のデータは次の2種類あることを念頭に置いておくこと。
- 業務用データ
業務に使用されるデータのこと。売上、取引データ、在庫などなど。
これらのデータは「必要に迫られて」「必然的に」発生することが多い。
つまり、これらのデータが使用可能でなくなるならば、企業の事業そのものが破綻することを意味しています。
通常はMySQL,PostgreSQL,SQLServer,Oracle DatabaseなどRDMSを用いて管理されます。
- 分析用データ
データサイエンティストや機械学習エンジニアが使用するデータで、予測や傾向分析などに使用します。
この種のデータは日々の業務に不可欠なものではなく、長期的な意思決定に使用されます。
RDMSでの管理も可能ですが、Bigqueryなど専用のデータベースも出てきています。
まとめ:ソフトウェアアーキテクチャとは何か？
アーキテクトの仕事は、そもそもアーキテクチャが頻繁に変わるものなので定義することが難しい。
それでもあえて仕事を定義するとすれば以下の5つであり。
アーキテクトには以下の6つの要素を満たしている人が望ましく。
ソフトウェアアーキテクトとは何か？
title:【ソフトウェアアーキテクト入門】アーキテクトとはどんな役割か？
description:私たちは、ソフトウェアアーキテクチャの仕事を、1. システムの構造2. システムがサポートしなければならないアーキテクチャ特性3. アーキテクチャ決定4. そして設計指針 の組み合わせであると定義した。
img:https://tshop.r10s.jp/rakutenkobo-ebooks/cabinet/8849/2000008128849.jpg?fitin=560:400&composite-to=,|560:400
category_script:True
redirect:https://minegishirei.hatenablog.com/entry/2023/02/07/114407
