※ この記事は業務システムおよびWebシステムを想定しています
要約
システム開発において「エンドユーザー」「ITサービス提供者」「ITサービス（システム）開発者」の３つのアクター（ロール）をしっかり念頭におこうという記事です。
システムを取り巻く３つのアクター
どんな業務システムにも３つのアクター（それぞれのロールを担った人）が関わります。
３つのアクター（ロール）：
- エンドユーザー
- ITサービス提供者
- ITサービス（システム）開発者
それぞれのアクターはそれぞれの役割分担（ロール）のための要件を持ちます。
業務デザインと業務オペレーション
事業を成長させていくには業務を遂行するだけでなく、業務のやり方を日々改善して行く必要があります。
ここで、業務のやりかたを改善する業務工程を「業務デザイン」、業務の遂行の工程を「業務オペレーション」と呼ぶことにします。
「業務デザイン」担当は業務を変革することで企業を成長させることを役割とし、「業務オペレーション」担当は定まった業務設計の中で業務を遂行し成果を出すことが役割となります。
もちろん現実的にはオペレーションしながら同じ人が業務改善することはあるかもしれません。しかしそれは業務分析の視点から見ると同一アクターが複数のロールを担っていることになるでしょう。
上記の３つのアクターと２つの業務工程をマトリクスにしてみます。
すると６つの業務ロールとその担当が必要なことがわかります
業務とロールのマトリクス
業務部門（エンドユーザー）の業務
業務部門（エンドユーザー）の業務はどのシステム開発の現場でもしっかりと認識されている部分です。
業務部門の業務は業務部門が担います。
オペレーション中心企業ではこの業務のオペレーション部分が自社の強みであり、自社で担う部分になります。
オペレーション中心企業というのは私の作った言葉ですが、小規模飲食業などをイメージしてもらうのとわかりやすいかもしれません。
ラーメン屋を始めるにあたって飲食コンサルに業務や業務を行うための場を構築してもらい、自分たちでは日々のラーメン屋の業務を遂行するような企業をオペレーション中心企業と表現しています。
ITサービス提供業務
ITサービス提供業務としているのは、ITサービスマネジメントやシステム運用に関する業務です。
2010年代半ばからITサービス提供企業ではITサービス提供業務のうち、システムの安定運用に関する仕組みの構築や運用をSite Reliability Engineering(SRE)というエンジニアに担当させ改善・運用を効率的に行うのが流行してきています。
開発者業務
システム開発のそのものだけでなく、障害やバグの調査時にITサービス提供者との役割分担や本番環境の情報をどう得るか等のケースの業務のやりかたの検討も必要です。
システムの内製に強い企業では、開発者業務自体のシステム化・自動化が進められています。
ITエンジニアの好む「プログラマの三大美徳」という言葉もありますし、ITエンジニア文化が組織にあるとこのあたりが改善されやすくなるのかもしれません。
オペレーション中心企業でのシステム開発
オペレーション中心企業ではラーメン屋の例でいったように、業務デザインと構築（下図赤い部分）はコンサルなどに外注されることになります。
業務システムが必要な場合は、システム開発も外注されます。
オペレーション中心企業が自社システムを開発すると、業務部門のオペレーション部分が話の中心になってしまうため、ITサービス提供業務、開発者業務についての検討はおろそかになりがちです。(下図青い部分）
オペレーション中心企業からの受託システム開発ではこの部分に工数を割くことについて、理解が得るのは難しいのが実態ではないでしょうか。
自社システムの開発を決めた企業は、ITサービス提供業務や開発業務についても念頭においてシステム開発・運用を行う必要があります。
自社内製ITサービス提供企業からみた各業務
ITサービス提供企業では立ち位置が異なってきます。
ITサービス提供企業は、業務デザイン（サービスデザイン）を中心に動きます。
主に、エンドユーザー向けサービス設計（業務設計）、ITサービス提供の業務の構築が強みであり、自社で担う部分になります。(下図赤い部分）
ITサービス提供企業からすると業務オペレーション部分(下図赤い部分）はエンドユーザーのサービス利用になります。
そのため、自社で担当するという部分ではありません。
また、ITサービス提供者の業務（システム運用）についても、ITサービス提供企業は比較的にシステム化・ITサービス化をしっかり行うことが多いでしょう。
自社で運用業務を行う場合もサービス成長のためにこの部分は省力化していきます。
受託システム開発での注意点
オペレーション中心企業を相手にした受託システム開発では「業務部門向け業務設計・業務システム開発」（下図赤い部分）が話の中心になります。
そのため、先述した通り、ITサービス提供の業務についての話がおろそかになりがちです。（下図青い部分）
受託システム開発を行う企業は、開発業務はシステム開発会社内で考え、構築するにしても、ITサービス提供業務についてはお客様にしっかりと話し合い、構築していく必要があります。
受託システム開発でITサービス提供業務がまともに設計されていない状態になると、良いITサービス提供・システム運用ができません。
サービス状況が見えなくないため、良いサービスが提供できているか判別ができなくなるためです。
ITサービス提供者側からエンドユーザーへのシステムメンテナンス等について告知や、ITサービスに関する問い合わせ対応フローなども構築する必要があります。
ITサービス提供を担うのは、開発を担当した会社なのか、お客様の情報システム部門に行ってもらうのか、それとも第３社の運用会社に運用してもらうのかというレベルから話し合いながらどの程度システム化・サービス化していくか検討したほうがいいでしょう。
このあたりは古くからITサービスマネジメントやシステム運用設計としてナレッジが体系化されてきた部分もありますが、純粋にエンドユーザー向けの業務分析・設計手法と同じように、アクター分析・ユースケース分析などを行っていくと、セキュリティ等の非機能要件もまとめやすくなります。
３つのアクターを念頭においたシステム開発を
今回は３つのアクター、２つの業務工程について紹介しました。
システム開発においては、特に「３つのアクター」を認識しておく必要があります。
いずれかのアクターの業務の改善にあまりに投資（改善工数の割当）が行われなわれていないと、そこが非効率、低品質化し、事業成長のボトルネックになることがあります。
また、３つのアクターを意識することで要件の把握漏れや考慮漏れの防止に繋がります。
エンドユーザー、ITサービス提供者、開発者のそれぞれの業務にどれくらいの工数を割いていくかは、それぞれの現場の状況によりますが、自分たちはそれぞれのアクター向けにどのくらい工数を割いているかは把握しておくのが良いかもしれません。