ITサービス運営におけるアーキテクチャの役割

2014年11月15日に開催されたJJUG CCC 2014 Fallにて「Javaエンジニアのためのアーキテクト講座」と題して発表を行いました。資料は以下です。

「良いアプリケーションを作る」時代から「良いITサービス運営を実現する」時代になったことで、アーキテクトの役割はどうなったか、という内容を話しました。

今回は自分なりにITサービス運営というものをモデルを書いてみました。v0.1となっていますが、まだまだ見直せることはあると思っています。

元ネタはソフトウェア品質モデルです。ソフトウェア品質モデルでも「外部」「内部」といった静的な要素に加えて、「利用時」「プロセス」といった動的な要素も含めて、お互いに依存したり影響を与えたりするということが定義されていました。ITサービス運営ということを考えて、もう一歩、複雑な構成となっています。大きく分けて「ITサービスを構成する要素」と「ITサービス運営に関わる利害関係者」となります。

ITサービスを構成する要素

要素名	特徴	例
利用者の体験価値	利用者が体験して感じるもの 利用者によって評価が異なる	AさんとBさんで評価が異なる
サービスの振る舞い	外部から見てわかる振る舞い 誰がテストしても同じ結果 仕様（機能と非機能）	仕様とテストケース 品質特性 API
動的な構成	システム実行時の要素と相互作用 流れ、実行、プロセス	インスタンス 処理 実行環境/インフラ
静的な構造	成果物が配置された静的な構造 後に残り、参照可能	ソースコード クラス、テーブル定義 ドキュメント

ITサービス運営の利害関係者

要素名	特徴	関心事
企画プロセス	ITサービスの振る舞いを管理する 振る舞いの追加や変更を要求する	売上 要求
開発プロセス	静的な構造を作る 構造を追加し、変更する 素早さが求められる	リリース計画 開発ツール
運用プロセス	動的な構成を管理する 動的構成の追加や変更を受け入れる 安定が求められる	デプロイ 監視
業務プロセス	ITサービスを利用し、利用者にサービスを提供する 利用者からフィードバックを得る 安定が求められる	現場 効率化

このITサービス運営モデルで考えるべきことは以下の4つです。

1. 個別の関心事を持つ利害関係者がいる
2. 価値は利用者の体験によって定義される
3. 複雑な構成要素によって成り立つ
4. フィードバックによって持続的に成長する

これらの観点を考慮しつつ、各要素のバランスをとることがアーキテクチャの役割であり、それをデザインすることがアーキテクトの仕事ということになります。アーキテクチャ設計を進める上でも、そういった各要素を意識することが大事です。

もっと書きたいのですが、時間がないので詳細については資料を確認してください...。

オンラインでのフィードバックを見ていると「内容が難しくて分かりにくかった」というのがいくつかありました。モデルまでは理解していただいていていたようですが、後半のアーキテクトに求められる作業やスキルあたりが飛ばしすぎました。ここは反省をしております。次回、こういった機会には、もっと分かりやすく伝えられるようにします。

最後に書きましたが「アーキテクト的な発想」は職業がアーキテクトでなくてもできます。むしろ、すべてのエンジニアがITサービス運営全体を意識するというのは非常に大事なことだと思っています。