はじめに
こんにちは！yamakazu (@yamarkz) です。
10月から下期も始まり、10X社内は色々と変化が生まれ始めました。大きくは組織のアーキテクチャが刷新され、実務検証(ここから半年がProof of Concepts期間)が始まったところが大きいです。
アーキテクティングの重要性を所属組織の構造変化という観点から経験知として学ぶ機会に遭遇できているのは貴重で、新たに加わる変化 (評価制度や目標設定など) でどのように組織が変化するのかは個人的にも関心があり、良い/悪い含めて前向きに学んでいきたいです。
さて今回はそんなアーキテクティング方面の話として、ソフトウェアアーキテクチャ分野で提唱されている アーキテクチャ特性 と呼ばれる概念と、それに対する10Xでの取り組みを紹介します。
ソフトウェアアーキテクチャに関心のある方は既に知っている概念かもしれません。知らない方は、是非この機会に知ってもらいたいです。
- はじめに
- ソフトウェアの性質的側面を考慮する難しさ
- アーキテクチャ特性の導入
- 10Xにおけるアーキテクチャ特性の定義
- アーキテクチャ特性に対する考慮を文化にする
- 変化を加えたことによる手応え
- 今後の展望
- 最後に
- 参考資料
ソフトウェアの性質的側面を考慮する難しさ
章題の通り、ソフトウェア開発における性質的側面を考慮することは難しいと思っています。
少なくとも、要求に対してできることを示す機能的側面への考慮と比較すると、性質的側面の方が難しいことは明らかです。
なぜでしょう？
様々な意見が出そうですが、2つ理由があると考えています。
- 要件に現れにくい (暗黙的な要件)
- システムの構造や仕組みを理解しなければ考慮できない (システム理解の必要性)
性質的側面は暗黙的です。
「〜できる」といった機能仕様はプロダクトマネージャーや顧客でも理解でき、定義することもできます。しかし、「〜の場合、〜として振る舞う」や「〜をしたら、〜までになっている」といった状況描写を踏まえた性質を示す要件は定義できる場合もあれば、そもそも話にすら上がらない場合があります。(筆者はそういったシーンを幾度も経験しました)
具体的には「操作Aをした後、5分以内に処理が完了し、次の操作に移れるようにする」「操作Aは並行可能だがデータ操作は衝突してはいけない」「操作A後の処理は時間を要すが、操作を止めてはいけない」という要件が仮にあった場合、「パフォーマンス」「同時実行性」「完全性」といった性質を考慮してシステムを作る必要があります。
しかし、ここで挙げた制約条件を顧客が話してくれることは極めて稀で、仕様を定義するプロダクトマネージャーでも「データ操作の衝突」といったことまで考慮できていることは多くはないです。
これはプロダクトマネージャーの力不足なのではなく、システムを理解しないと考慮できない (難しい) からです。
この考慮問題を解決するにはどうすれば良いのか悩みました。
エンジニアが仕様策定に深く踏み込んで関わることで解決できそうですが、それだと責任分界点が曖昧になることや対応範囲が広くなり、業務効率が落ちそうです。
それとも間にレビューステップを挟むことでなんとかすると良いでしょうか？レビューを挟んだとしても、そもそもどの観点で要件と仕様に含める性質を確認するべきかを理解できていなければ、レビューしたところで考慮できないままです。
できないことを経験する中で、どうすればよかったのかを振り返り学んでいくこともできますが、これまた体当たり的なアプローチだなとも思います。(= 失敗経験がなければ洗練されない)
そう悩み考えていた時にタイミングよく遭遇したのが「アーキテクチャ特性」という概念でした。
アーキテクチャ特性という考えと見方を理解の足がかりにし、共通の考え方(フレーム) を持つことで、個人の力量頼みの考慮とレビュー品質を標準化することができそうだと考えました。
何も拠り所がない中で手探りに自分達のやり方を模索するよりも、まずは先人の知恵を借り、思考の型を学び、技術を習得した後、自分達流のスタイルを見つけに行った方が良いのではと考え、兎に角試してみようという気持ちになりました。ダメならまた考え直せば良いと。
これが「アーキテクチャ特性」を社内標準語、そして考え方として提唱し始めた背景です。
まだまだ言い出したばかりで、浸透しきれているとは言い難い言葉と概念ですが、地道な活動を続けてソフトウェア品質の向上に貢献していきたいという願いがあります。
以下では10X社内で共有してある社内ドキュメントから、具体的に行っているアプローチを紹介します。類似の問題に遭遇している or アプローチを検討している方の参考になれば幸いです。
アーキテクチャ特性の導入
アーキテクチャ特性という言葉は「Fundamentals of Software Architecture (日本語訳書: ソフトウェアアーキテクチャの基礎)」で定義されました。
著書の公開以前から厳密な定義なしに類似の言葉がソフトウェアアーキテクチャ界隈の本でも使われていました(Design It!で自然に出てくる)が、明確に定義されたのは著書からです。
類義語として品質特性や非機能要件という言葉が挙げられ、細かなニュアンスやスタンスは違えど、大きくは同じ概念ではあります。
著書でも述べられていますが、あえてアーキテクチャ特性と呼ばれる言葉を選択する理由は、アーキテクチャやシステム全体の成功に不可欠な関心ごとを、その重要性の対象(アーキテクチャ自体のこと)を損なうことなく表現するからです。
10Xでもこの考えに賛同し、「アーキテクチャ特性」という言葉を一般用語として採用しています。
一般用語として採用したものの、単に「アーキテクチャ特性を活用しよう」と言い出したところで導入は進みません。まずは率先して良いということを近いメンバーに共有しつつ、共通理解を持てる状態作りに取り組みました。
次章では社内に残したドキュメントを紹介します。
10Xにおけるアーキテクチャ特性の定義
原著である「ソフトウェアアーキテクチャの基礎」をそのまま読み込んで理解するのが一番ではありますが、理解の取っ掛かりとして自分達なりの解釈を定義しておきたいなとも思い、原著の内容をベースとして、10X社としてどう解釈するかを定義しました。
原著よりも端的で実践的な内容になっています。
このドキュメント内容を一つの拠り所にして、以降の社内での取り組みに反映しました。
アーキテクチャ特性に対する考慮を文化にする
個人がアーキテクチャ特性を理解し、開発や設計シーンで意図的に意識を向けられるようになるだけでも十分効果があると思います。
一方で、活用することを個人の力量に頼ってしまうのは属人的で再現性が低く、持続可能性に欠けます。関心に差がある場合、意識の向け方にも差が生まれる可能性が残ります。
理想は考慮を個人の力量に頼るのではなく、仕組みや運用によって複数人の意識を共有して取り組めるようになることです。この複数人で意識を共有できることを「文化」と捉えています。
アーキテクチャ特性に対する考慮を文化にするために、10Xでは3つの取り組みから始めました。
1. DesignDocでの考慮
10Xでは機能開発を進める際に、DesignDocを書くことが推奨されています。
DesignDocを書き終えた時点で特性の考慮がなされているのが理想です。なぜなら一番出戻りが小さくて済み、リーズナブルに対応できるからです。
直近でもDesignDocを書き出す時点で、セキュリティのアーキテクチャ特性を満たすためのプラクティスが社内で議論されていました。
性質要件を早い段階 (DesignDocの書き出し前、コードは1行も書いてない) で気づくことができ、Shift Leftできていることを実感します。
2. 開発ライフサイクルでの考慮
10Xではイシューの選定から機能のリリースまでの道のりを開発ライフサイクルと呼んでいます。
いずれブログで紹介してほしいトピックなので、ここでは詳細には触れませんが、所謂開発プロセスのことです。
全ての開発ライフサイクルステップにアーキテクチャ特性への考慮をMustで含めることは混乱を生むので、部分的な範囲で考慮をMustにする運用を始めてみました。
外部との連携箇所はシステムの中でも特に考慮が必要とされるので、そこでは必ずアーキテクチャ特性への考慮がなされているかをレビューで確認するようにしています。
3. 日常会話での活用
標準語に定めたとて、使わなければ浸透しません。
自ら率先して「アーキテクチャ特性」と発言するようにしていました。
スケーラビリティやパフォーマンスといった特性の話をしていたなら、「そのアーキテクチャ特性を守るためにはどう考えていますか？」とあえて特性を個別で指摘するのではなく、「アーキテクチャ特性」として捉えて言葉の存在や考え方の存在に気づいてもらえるようにするなどです。
これはかなり極端な例ですが、同じ目線で話ができる、感所を持って考えられるメンバーを増やしていくためには大事な活動です。
変化を加えたことによる手応え
アーキテクチャ特性に対する考慮活動に取り組み始めた中で、一定手応えを感じてきました。
これまでの取り組みを振り返って、手応えを感じた内容を紹介します。
1. システム全体の特性を示す地図を作った
アーキテクチャ特性というフレームを通してStailerというプロダクトを捉えた時、どのように見えるのかを可視化し、ドメインの地図を作ってみました。
こう整理してみると、登場するドメインが多く、特性も多種多様で、かなり複雑なプロダクトであることがよくわかります。
これを見た時、これまで自身が体感していた複雑さ以上に複雑であることを見せつけられた気持ちになりました。
どの開発チーム(アプリケーション開発 or モジュール開発)がどの領域に責任を持つべきかも、地図をもとに一定整理がつけられたのは副次的な発見でした。
地図によって新しいメンバーにどういったドメインが存在するのか、ドメインに対してどういった考慮が求められるのかがわかりやすく伝えられそうなので、キャッチアップ情報にも良いかもしれません。
2. 漠然としたシステム品質に対して説明可能な状態になった
「バグがない期待通りの動き」という、人によって解釈や認識がぶれる抽象的な品質に対する認識が、具体で明瞭な定義に要素分解され、一定説明可能な状態になりました。
会話に出てくる「品質」がパフォーマンスを指しているのか、ユーザビリティを指しているのかでは全く意味が違います。
「品質」という抽象単語ではなく、「パフォーマンス」という具体単語で品質を改善したいとなればボトルネックの計測 → 改善策の検討 → 実施 → 改善効果計測 と具体の行動に移ることができます。
品質に限らず、システムに備えたい性質が何であるかを具体性高く示し、建設的な議論ができるようになったのは大きな前進でした。
3. パートナーごとに重視する観点が説明可能な状態になった
Stailerは1プロダクトで複数のパートナーをサポートする、マルチテナントSaaSと捉えることができます。開発と運用上難しいと感じるのが、パートナーごとにビジネスステージが異なるという点です。
ステージごとに求められるアーキテクチャ特性が異なるのと、そこに現れるアーキテクチャ特性がトレードオフの関係にあります。この状況で開発をするのは非常に認知負荷が高いです。
整理をする以前から認知負荷を感じていましたが、言語化することができませんでした。
なぜかわからないが経験したことのないやりづらさを感じる… そんな状態。そこからアーキテクチャ特性のフレームで捉え直すことで、要求される特性とそのトレードオフが原因であるということが明らかになりました。
明らかになったものの、まだこの認知負荷が高い状況は打開できていません。この状況を打開する術として、Stailerではドメインごとのモジュール分割を始めようとしています。
モジュール分割を推進する根拠として「パートナーごとの要求特性にトレードオフがあり、認知負荷が高い」というのは、取り組むアプローチの確らしさの裏付けになりました。
4. ドメインごとの性質考慮と推奨する実装戦術が明らかになった
Stailerはプロダクトの特徴として、外部システムと密に連携を取ることで価値が生まれます。どのパートナーでも必ず外部連携が生まれるため、外部連携開発は避けては通れません。
また、外部連携はその名の通り外部の運用制御不可能な対象とネットワーク通信を行うので、自社内に閉じた機能の開発以上に必要な考慮が増えます。
プロダクトローンチ上開発の必要性があり、考慮対象が多い領域の開発運用の負荷をなるべく低減していきたいという狙いのもと、各ドメインで必要とされるアーキテクチャ特性と、それらを得るために推奨される実装戦術を明文化しました。
これにより、漠然と何か考慮と対策が必要そうという状態から、最低限守るべき特性を保証しやすい状態にできました。
以上が取り組みを振り返って感じた、4つの手応えでした。
今後の展望
新しく開発する機能や加える変更では基本的にはアーキテクチャ特性への考慮を必須にして、特性を考慮できなかったが故に発生する出戻りや運用対応の困りごとを減らしていきたいです。
具体的には、DesignDocで考慮を必須にすることや、考慮事例を紹介して新規メンバーでも考えが及びやすい土壌を作るなどです。まだまだ走り出して成果事例が少ないのですが、1つずつ積み上げていきます。
また、新規開発はもちろんなのですが、既存実装の方面でも品質向上を目指した取り組みとして、設計書の整備とテストケースを刷新するプロジェクトが始まっています。
こちらでも既存の実装で暗黙的に存在している特性を明文化し、併せてテストケースの拡充も行って品質向上を目指していきます。過程で関わるメンバーにも品質側面への考慮意識を共有できるようにしていきたいという狙いを持っています。
最後に
10Xで導入を始めた「アーキテクチャ特性」という概念について紹介してきました。
元々漠然と抱いていたソフトウェア品質の課題感に一石を投じてくれるような考えに出会えたことに感謝したいです。自分自身もこの取り組みをきっかけに、以前よりも性質観点の考慮を意識的に見れるようになりました。
まだまだ組織に文化が浸透したとは言い難く、長い時間がかかりそうですが中長期目線で品質向上と、組織の開発運用力の向上に貢献できるように粘り強く取り組んでいきたいです。
10Xではソフトウェア開発をアーキテクチャ方面からの改善を始めています。 ICやEMとしてやってきたが、今後はアーキテクトとして価値を発揮したいという方にはとても良い機会を提供できます。ご応募をお待ちしています。
