「イケてるエンジニアはココが違う！」をテーマに技術的で意識高い系の記事を投稿しています。こちらの目次に沿って週１回ペースで記事を投稿しているので、この記事が「面白かった！」という方はフォローまたはシェアしてもらえると嬉しいです。

前回の振り返りと今回の結論

前回、こちらの記事で「システムはユーザの課題に対して、解決策を提供している」というお話しました。

今回は、システムが解決策を提供するためのビジネスアーキテクチャの設計について、考察していきます。

今回の結論はこちら！
✅　システムに解決策の”素”を入力する「人やモノ」を設計しよう。
✅　UMLで利用者の課題解決ストーリーの脚本を書こう。
✅　課題解決ストーリーを見失うな。
では、いきましょう！

システムに解決策の”素”を入力する「人やモノ」を設計しよう。

システムが解決する利用者の課題を設定したあとは、いよいよ解決策を提供する仕組みを設計していきます。

エンタープライズアーキテクチャに基くビジネスアーキテクチャの設計では、まずシステムが解決策を提供するために必要な業務を行う「組織」を設計します。ここでいう「組織」には、組織に所属している「人」、組織が所有している「モノ」（システムや装置）が含まれます。なので「組織」を「人やモノ」と読み替えても差し支えありません。

システムは、それ自体ではデータの入出力を行うことしかできず、データを出力するためには、データを入力してあげる必要があります。つまり、解決策を出力するためには、解決策の”素”をシステムに入力する必要があります。そして、その入力業務を行う「組織」、つまり「人やモノ」の設計が必要になってきます。

身近なシステムとして「天気予報システム」を例に、解決策の”素”の入力業務について考えてみましょう。天気予報システムは、私達が抱えている「明日の天気を正確に把握する。」という課題に対して「明日の天気は晴れ、降水確率0%」という解決策を提供してくれます。このとき、解決策の”素”は「衛星画像・温度データ・有資格者の判断」のようなデータです。そして、これらデータをシステムに入力する業務を行っている「人やモノ」が「人工衛星・温度計・気象予報士のみなさん」という具合です。

このように多くのシステムにおいて、いくつもの「人やモノ」がシステムに解決策の”素”を入力するという業務を行ってくれています。

私達エンジニアは、利用者に解決策を提供するために、解決策の”素”をシステムに入力する「人やモノ」を設計しなければいけません。

UMLで利用者の課題解決ストーリーの脚本を書こう。

では、解決策の”素”をシステムに入力する「人やモノ」は、どのように設計していくのでしょうか？流儀はいろいろあると思われるものの、個人的には「ユースケース図」や「ユースケース記述」の作成が「人やモノ」の設計に相当するんじゃないか考えています。

「ユースケース図」や「ユースケース記述」は、UML（Unified Modeling Language：統一モデリング言語）と呼ばれる、記載方法が統一された”言語”で表現されます。

「ユースケース図」は、システムを中心に置き、課題を抱えている利用者や解決策の”素”を入力する「人やモノ」を「アクター」と称してシステムの周囲に配置、各「アクター」がシステムに対して行う操作を「ユースケース」と定義して図示したものです。

「ユースケース記述」は、「ユースケース図」で定義された「ユースケース」を実現するための手順を記述したものです。この辺の詳しい解説は、こちらのサイトで分かりやすく説明されいますので、こちらを参照ください。

そして、「ユースケース図」や「ユースケース記述」の作成は、利用者の課題を解決するためにどうやっていくのか？というストーリーの”脚本”を書くことと同じだと考えています。

UMLにおいて、課題を抱えている利用者や解決策の”素”を入力する「人やモノ」は「アクター」と称されています。役者です。役者。利用者の課題を解決していくというストーリーを進めていく役者です。ということは、システムはストーリーが展開される「舞台」、「ユースケース」はストーリーを構成する「エピソード」、「ユースケース記述」は「エピソード」の「台本」とみなすことができるわけです。

私達エンジニアが「ユースケース図」や「ユースケース記述」を作成してるとき、作成しているのは単なるシステムの設計書ではありません。利用者の課題解決ストーリーを、UMLという”言語”を使って表現した”脚本”なのです。

そう、エンジニアは脚本家です！

課題解決ストーリーを見失うな。

「さぁ、オモロイ”脚本”書くぞ！」とPCに向かうとき、注意しないといけないことがあります。私達エンジニアが脚本家として、課題解決ストーリーの”脚本”を書くとき、「アクター」どうしの関係や、「ストーリー」と「エピソード」の関係について一貫性を保ち続ける必要があります。

「アクター」どうしの関係とは「主役」と「脇役」の関係です。”脚本”を書くときは、「脇役」が「主役」より出しゃばっらないようにしないといけません。「ストーリー」と「エピソード」の関係とは、全ての「エピソード」は「ストーリー」を成立させるためのものという関係です。”脚本”を書くときは、「ストーリー」と関係のない「エピソード」を書いてはいけません。

例えば「進撃の巨人」。ご存知の方は共感してもらえると思うんですけど、「主役」と「脇役」の関係、「ストーリー」と「エピソード」の関係、すごくないですか？「主役」と「脇役」が絡み合い、「エピソード」と「エピソード」が絡み合い「なんで、こんなにオモロイんだよ！」と叫びたくなるようなストーリーが見事に設計されています。

そして、システム設計でも「進撃の巨人」のような”脚本”を書かないといけないわけです。

課題解決ストーリーにおいて、「主役」は課題を抱えている利用者、「脇役」は解決策の”素”を入力する「人やモノ」になります。天気予報システムであれば、「主役」は予報結果を閲覧する私達、「脇役」は「人工衛星・温度計・気象予報士のみなさん」です。そして、「人工衛星が衛星画像を入力する」「気象予報士さんが有資格者の判断を入力する」というエピソード（ユースケース）が絡み合うことで、課題解決ストーリーが見事に成立します。

繰り返します。
私達が”脚本”を書くとき、「アクター」どうしの関係や、「ストーリー」と「エピソード」の関係について一貫性を保ち続けなければいけません。

しかし、実際のシステムの開発現場では、これらの一貫性が保てなくなりストーリーが破綻してしまうことが起こりえます。「脇役」が「主役」より出しゃばってきてしまう（優先順位がチグハグ）。「ストーリー」と関係のない「エピソード」を書いてしまう（使わない／使えないゴミ機能に命の時間を費やす）。こんなことが、起こります。

どうしてでしょうか？

その理由は、エンジニアはストーリーを設計している時間よりもエピソード（ユースケース）を設計・実装している時間のほうが、圧倒的に長いからです。更に、ストーリーよりもエピソードのほうが、具体的で分かりやすいからです。その結果、目の前のエピソードを設計・実装することが日常となり、本来の目的である課題解決ストーリーを見失ってしまいます。

構造的に「本来の目的を見失ってしまいやすい」環境に、エンジニアは置かれていると言えます。

しかし、イケてるエンジニアはこんな環境でも「本来の目的」を見失うことはありません。

イケてるエンジニアは「本来の目的を見失ってしまいやすい」という開発現場の構造的な特徴を理解したうえで、ストーリーの一貫性を保ち続けるように最大限の注意を払っています。

問題や調整事項が発生したときは、本来の目的である課題解決ストーリーにおける「主役」と「脇役」の関係立ち戻り、優先順位をつけて判断を行っています。機能仕様が肥大化してきたときは、課題解決のストーリーと結びつきを精査し、結びつかない機能はバッサリ削るという判断ができます。

イケてるエンジニアは、本来の目的を見失いません。
これは人生も同じです。

まとめ

今回の結論はこちら。
✅　システムに解決策の”素”を入力する「人やモノ」を設計しよう。
✅　UMLで利用者の課題解決ストーリーの脚本を書こう。
✅　課題解決ストーリーを見失うな。

次回は、今回の考え方を人生設計に応用する方法について、考察したいと思います。