![見出し画像](https://assets.st-note.com/production/uploads/images/52146450/rectangle_large_type_2_2154340a2cee6baa4db07301728e3943.png?width=1200)
【#07】イケてるエンジニアは見失わない。ユーザの課題解決ストーリー。
「イケてるエンジニアはココが違う!」をテーマに技術的で意識高い系の記事を投稿しています。こちらの目次に沿って週1回ペースで記事を投稿しているので、この記事が「面白かった!」という方はフォローまたはシェアしてもらえると嬉しいです。
前回の振り返りと今回の結論
前回、こちらの記事で「システムはユーザの課題に対して、解決策を提供している」というお話しました。
今回は、システムが解決策を提供するためのビジネスアーキテクチャの設計について、考察していきます。
今回の結論はこちら!
✅ システムに解決策の”素”を入力する「人やモノ」を設計しよう。
✅ UMLで利用者の課題解決ストーリーの脚本を書こう。
✅ 課題解決ストーリーを見失うな。
では、いきましょう!
システムに解決策の”素”を入力する「人やモノ」を設計しよう。
システムが解決する利用者の課題を設定したあとは、いよいよ解決策を提供する仕組みを設計していきます。
エンタープライズアーキテクチャに基くビジネスアーキテクチャの設計では、まずシステムが解決策を提供するために必要な業務を行う「組織」を設計します。ここでいう「組織」には、組織に所属している「人」、組織が所有している「モノ」(システムや装置)が含まれます。なので「組織」を「人やモノ」と読み替えても差し支えありません。
システムは、それ自体ではデータの入出力を行うことしかできず、データを出力するためには、データを入力してあげる必要があります。つまり、解決策を出力するためには、解決策の”素”をシステムに入力する必要があります。そして、その入力業務を行う「組織」、つまり「人やモノ」の設計が必要になってきます。
身近なシステムとして「天気予報システム」を例に、解決策の”素”の入力業務について考えてみましょう。天気予報システムは、私達が抱えている「明日の天気を正確に把握する。」という課題に対して「明日の天気は晴れ、降水確率0%」という解決策を提供してくれます。このとき、解決策の”素”は「衛星画像・温度データ・有資格者の判断」のようなデータです。そして、これらデータをシステムに入力する業務を行っている「人やモノ」が「人工衛星・温度計・気象予報士のみなさん」という具合です。
このように多くのシステムにおいて、いくつもの「人やモノ」がシステムに解決策の”素”を入力するという業務を行ってくれています。
私達エンジニアは、利用者に解決策を提供するために、解決策の”素”をシステムに入力する「人やモノ」を設計しなければいけません。
UMLで利用者の課題解決ストーリーの脚本を書こう。
では、解決策の”素”をシステムに入力する「人やモノ」は、どのように設計していくのでしょうか?流儀はいろいろあると思われるものの、個人的には「ユースケース図」や「ユースケース記述」の作成が「人やモノ」の設計に相当するんじゃないか考えています。
「ユースケース図」や「ユースケース記述」は、UML(Unified Modeling Language:統一モデリング言語)と呼ばれる、記載方法が統一された”言語”で表現されます。
「ユースケース図」は、システムを中心に置き、課題を抱えている利用者や解決策の”素”を入力する「人やモノ」を「アクター」と称してシステムの周囲に配置、各「アクター」がシステムに対して行う操作を「ユースケース」と定義して図示したものです。
「ユースケース記述」は、「ユースケース図」で定義された「ユースケース」を実現するための手順を記述したものです。この辺の詳しい解説は、こちらのサイトで分かりやすく説明されいますので、こちらを参照ください。
そして、「ユースケース図」や「ユースケース記述」の作成は、利用者の課題を解決するためにどうやっていくのか?というストーリーの”脚本”を書くことと同じだと考えています。
UMLにおいて、課題を抱えている利用者や解決策の”素”を入力する「人やモノ」は「アクター」と称されています。役者です。役者。利用者の課題を解決していくというストーリーを進めていく役者です。ということは、システムはストーリーが展開される「舞台」、「ユースケース」はストーリーを構成する「エピソード」、「ユースケース記述」は「エピソード」の「台本」とみなすことができるわけです。
私達エンジニアが「ユースケース図」や「ユースケース記述」を作成してるとき、作成しているのは単なるシステムの設計書ではありません。利用者の課題解決ストーリーを、UMLという”言語”を使って表現した”脚本”なのです。
そう、エンジニアは脚本家です!
課題解決ストーリーを見失うな。
「さぁ、オモロイ”脚本”書くぞ!」とPCに向かうとき、注意しないといけないことがあります。私達エンジニアが脚本家として、課題解決ストーリーの”脚本”を書くとき、「アクター」どうしの関係や、「ストーリー」と「エピソード」の関係について一貫性を保ち続ける必要があります。
「アクター」どうしの関係とは「主役」と「脇役」の関係です。”脚本”を書くときは、「脇役」が「主役」より出しゃばっらないようにしないといけません。「ストーリー」と「エピソード」の関係とは、全ての「エピソード」は「ストーリー」を成立させるためのものという関係です。”脚本”を書くときは、「ストーリー」と関係のない「エピソード」を書いてはいけません。
例えば「進撃の巨人」。ご存知の方は共感してもらえると思うんですけど、「主役」と「脇役」の関係、「ストーリー」と「エピソード」の関係、すごくないですか?「主役」と「脇役」が絡み合い、「エピソード」と「エピソード」が絡み合い「なんで、こんなにオモロイんだよ!」と叫びたくなるようなストーリーが見事に設計されています。
そして、システム設計でも「進撃の巨人」のような”脚本”を書かないといけないわけです。
課題解決ストーリーにおいて、「主役」は課題を抱えている利用者、「脇役」は解決策の”素”を入力する「人やモノ」になります。天気予報システムであれば、「主役」は予報結果を閲覧する私達、「脇役」は「人工衛星・温度計・気象予報士のみなさん」です。そして、「人工衛星が衛星画像を入力する」「気象予報士さんが有資格者の判断を入力する」というエピソード(ユースケース)が絡み合うことで、課題解決ストーリーが見事に成立します。
繰り返します。
私達が”脚本”を書くとき、「アクター」どうしの関係や、「ストーリー」と「エピソード」の関係について一貫性を保ち続けなければいけません。
しかし、実際のシステムの開発現場では、これらの一貫性が保てなくなりストーリーが破綻してしまうことが起こりえます。「脇役」が「主役」より出しゃばってきてしまう(優先順位がチグハグ)。「ストーリー」と関係のない「エピソード」を書いてしまう(使わない/使えないゴミ機能に命の時間を費やす)。こんなことが、起こります。
どうしてでしょうか?
その理由は、エンジニアはストーリーを設計している時間よりもエピソード(ユースケース)を設計・実装している時間のほうが、圧倒的に長いからです。更に、ストーリーよりもエピソードのほうが、具体的で分かりやすいからです。その結果、目の前のエピソードを設計・実装することが日常となり、本来の目的である課題解決ストーリーを見失ってしまいます。
構造的に「本来の目的を見失ってしまいやすい」環境に、エンジニアは置かれていると言えます。
しかし、イケてるエンジニアはこんな環境でも「本来の目的」を見失うことはありません。
イケてるエンジニアは「本来の目的を見失ってしまいやすい」という開発現場の構造的な特徴を理解したうえで、ストーリーの一貫性を保ち続けるように最大限の注意を払っています。
問題や調整事項が発生したときは、本来の目的である課題解決ストーリーにおける「主役」と「脇役」の関係立ち戻り、優先順位をつけて判断を行っています。機能仕様が肥大化してきたときは、課題解決のストーリーと結びつきを精査し、結びつかない機能はバッサリ削るという判断ができます。
イケてるエンジニアは、本来の目的を見失いません。
これは人生も同じです。
まとめ
今回の結論はこちら。
✅ システムに解決策の”素”を入力する「人やモノ」を設計しよう。
✅ UMLで利用者の課題解決ストーリーの脚本を書こう。
✅ 課題解決ストーリーを見失うな。
次回は、今回の考え方を人生設計に応用する方法について、考察したいと思います。
この記事が気に入ったらサポートをしてみませんか?