この投稿は、2023年JINSのアドベントカレンダー8日目の記事です。
自己紹介
JINSのデジタル推進部に所属している佐藤(@Takuma_Sato)と言います。
デジタル推進部は、デジタル戦略に関わる様々な実行を行っています。その中で私は、ITアーキテクト/テックリードとして、システム企画・システム全体設計・サイバーセキュリティ等の領域を担当しています。
はじめに
JINSは、アイウエアやウェアラブル端末等の企画、製造、販売をしていて、いわゆるSPAモデル(製造小売業)の事業を営んでいます。
海外にも展開しており、中国や台湾、北米など幾つかの国・地域で事業活動をしています。
小売業は、日々変化するお客様の動向に合わせてビジネスをする必要がありまして、ビジネスアジリティを強く求められます。当然ながら、事業を支えるシステムにもそれを実現することが期待されていて、実際どのように実現していくかは日々挑戦ではありますが、ITアーキテクトとしてどのように考えているかを少しお話ししたいと思います。
アーキテクチャは色々ある
ビジネスアジリティを実現するためのシステムとは何かを考え、設計し、実装に移し、そして継続的に成長させる全てに関わることが、JINSでのITアーキテクトの役割と言えますが、一般的に、ITアーキテクトはどのような人であるのか、せっかくなので生成系AIに聞いてみたいと思います。(GPT-4ではなく、Bardに聞いてみた)
//Bardの回答を一部抜粋
質問：
ITアーキテクトとは、企業においてどのような役割や責任を持つロールかを説明してください。
回答：
ITアーキテクトとは、企業のビジネス目標とIT戦略を統合し、企業全体のITアーキテクチャを設計・構築・運用する専門家です。
具体的には、以下の業務を担当します。
企業の経営戦略とIT戦略の策定
企業全体のITアーキテクチャの設計・構築・運用
新規システムの導入・開発プロジェクトの推進
既存システムの改善・保守プロジェクトの推進
社内外の関係者との調整・コミュニケーション
ITアーキテクトは、企業のIT戦略を実現するために、ビジネスとITの両方の視点から、企業全体のITアーキテクチャを設計・構築・運用する役割を担います。
ITアーキテクチャと一言で言っても、それが扱われる文脈により主とする内容が変わったりします。分かりやすい分類としては、ビジネス観点のアーキテクチャ(ビジネスアーキテクチャ)と、テクノロジー観点のアーキテクチャ(システムアーキテクチャ)です。
そして、そのアーキテクチャに紐づく要素(例：「ビジネスオペレーション」と「システム設計」)もありまして、これらを含めて全体整合性を取りながら、ビジネスアジリティを実現していくことがアーキテクチャ設計に含まれると考えています。
絵にするとこんな感じですね。
アーキテクチャ設計で重要なこと
今回は、システムアーキテクチャにフォーカスしたいと思いますが、このシステムアーキテクチャにおいても色々な関心事がありまして、設計する上では注意が必要です。
図示すると、こんなことを考慮して、設計していく感じです。
ちなみに、この図は『ソフトウェアシステムアーキテクチャ構築の原理』で記載されているもので、システムアーキテクチャを取り巻く要素を表しており、ITアーキテクトの活動範囲を確認するのに役立ちます。(一部表現を変更しています)
この図を見てお分かりのとおり、「ビュー」という要素がありまして、これは違う関心事を持っている関係者たちの視点で、アーキテクチャとして見る観点が変化することを意味します。
例えば、ITインフラを担当する人、アプリケーション開発を担当する人、データモデルを考えDB設計に落とし込む人のそれぞれが関心事としているシステムアーキテクチャがあるということですね。そして、それら全てがシステム開発においては必要でありまして、これら全てを調整・整合していくことがITアーキテクトの役割だと思います。
技術的負債とエントロピー
はい、毎度おなじみの技術的負債です。
技術的負債の発生は、技術的な選択によって生み出されたモノが原因ではありますが、その選択は多くの場合、ビジネスサイドの要求(QCD)に基づいて行われた妥協の産物であることが多いと言えます。
技術的負債の発生プロセス
技術的負債をより深く理解するには、エントロピーとの関係で見直すと良いです。
これもBardに聞いてみました。
質問：
技術的負債の発生するメカニズムと、エントロピーとの関係を説明してください。
回答：
エントロピーとは、物理学における概念で、系の無秩序さや複雑さを表す量です。ソフトウェアの技術的負債は、ソフトウェアの構造や仕様が複雑化することで、ソフトウェアのエントロピーが増加します。
エントロピーが増加すると、ソフトウェアの変更や修正が困難になります。これは、ソフトウェアの構造や仕様が複雑化することで、変更の影響範囲が広がり、変更を行うためのコストやリスクが高まるためです。
技術的負債を放置すると、ソフトウェアの品質が低下し、ビジネスの継続性に支障をきたす可能性があります。そのため、技術的負債を適切に管理し、エントロピーを増加させないようにすることが重要です。
パブリッククラウドが全盛な昨今、ITインフラ管理においては、IaCを用いることで、環境をコードで定義して可視化を高め、環境の作り直しを容易にしたりできます。また、その環境をObservabilityの観点でモニタリングやアラートを仕込んで管理することで、システムのエントロピーをコントロールできるようにもなってきています。
アプリケーション開発においても、コードの可読性を高めることはもちろんのこと、適切なコメントアウトを充実させたり、有効だと認められいているデザインパターンを採用することで、より保守性の高いプログラムを作ることが求められています。
設計に込めた意志はメタ情報として管理する
アーキテクチャ設計やシステム設計は「問題解決の手段」が表現されているはずです。
そして、たくさんある設計パターンの中からそれを選ぶに至った背景や理由があるはずで、私はそれを「設計のメタ情報」と呼んでいます。これをきちんと言語化することにより設計者以外の人たちが、そのシステム設計に至った背景や理由を理解するで、その後のシステム改修の方向性を適切に決める判断材料になります。
このような作業を通してシステムのエントロピーの増大を抑えられることを期待しており、このメタ情報が記載されたものがADRだと思います。
設計のメタ情報を言語化する目的は、「その後のシステム改修の方向性を適切に決める」ためなので、重量で多量な情報を言語化するだけでは可読性が下がります。その為、ポイントを絞って端的に記載する方が有益です。
以下の情報が良いと言われています。
- タイトル (title)
決定事項が端的に分かる表題を記載する - ステータス (status)
このレコードがどういう扱いであるかを記載する - コンテキスト (context)
なぜその決定に至ったのかの理由を説明する - 決定 (decision)
どんな設計であるかを具体的に記述する - 影響 (consequences)
この決定による「期待する効果」や「リスク・問題」を記載する
まとめ
自然言語で書かれた「設計のメタ情報」は、エントロピーの増大を管理して技術的負債の発生を抑制することに役立つと思うので、JINSでも取り入れています。しかしまだ有益な運用ができてはいないので、トライアンドエラーしながら進めていきたいと思います。
明日は、内田さん(@j-uchi)のネットワークな記事の予定です。お楽しみに!
参考
『ソフトウェアシステムアーキテクチャ構築の原理』
アーキテクチャ・デシジョン・レコードの勧め
ADR – アーキテクチャ上の設計判断を記録しよう