【考察】設計について（１）

要件定義からテスト設計までの流れで個人的に思うところのメモ

自分の経験の整理

いきなりモデリングは止めよう

理由

モデリングをしていると、仕事をやった気持ちになるけれど 実現してほしいことに近づいているか？というと そもそも近づくべき目的を共有していなかったということになりがちだと思うから。

なんとなく分かったつもりで抽象度の高い整理にむけて手を動かすのは良くない。

ユースケース図も同じ。

まず業務フローを作ろう

抽象度の高いところよりも、まず個別具体的なところを整理することが大事だと思う。

ユーザーにとって大事なのはモデリングでもオブジェクト指向でもアジャイルでもDDDでもなくて「問題を解決してくれること」。

ユースケース図とかモデルで分かった気持ちになる前に、その対象となる「ユーザーが実現したいこと」をちゃんと認識合わせから始めた方が良い。

この時点では ER図とかも、考えなくていいと思っている。

集中すべきは「あなたは何をどのようにしたい（しているの）」だけ。

みんなで問題や解決したいことの対象についての「ストーリー」を共有することもしないで モデリングとかやってはいけないと思う。

業務フローというと堅苦しくてドキュメンテーションな臭いがするというのであれば、システムで実現したい（もしくは している）ことのラフスケッチという言い方でも良い。

取っ掛かりとして簡易

モノコト分析、でコト（フロー）は、ユーザーにとっても話やすいところなので 仕様共有の取っ掛かりとして ちょうど良い。

• 今はこんな感じで、これをこういう風にしたい（ユーザー）

• それは何故ですか？（開発）

• こういう問題を感じているから（ユーザー）

ひょっとしたら「今はこんな感じ」で終わるかもしれませんが まずは そこからスタート。

ユーザーにとって分かりやすい表現

ユーザー自身にとって分かりやすい表現なので、少なくとも その意味での意思不通にはなっていない状態です。

*1

ユーザーにとって分かりやすいけど、開発側にとって曖昧であったり分かりにくい内容は 質問する事で、ユーザーにとっても「そうそう そうだね。業務担当外の人からすると そういう表現だと分かりやすいですね」となって、ユーザーと開発側にとって分かりやすい表現（ストーリー）になっていきます。

アクターが明確になる（を明確にする）

アクター*2を把握することで システムで実現したい目的の主語が明確になります。

「これ、だれ（なに）のために やっているんでしたっけ？」というときに 拠り所になります。

アクターの属性（権限とか）によって フロー（動き）だけでは分かりにくい「なぜ」が見えます。

アクターが増えるとシステムの規模は激増（激減）もありうるので、ちゃんとやりましょう*3。

やりたいことを共有する

ユースケースの整理（事前条件・事後条件の整理）やモデリング（システムの抽象化・データ構造*4）をしていると「あれ？これ 何をやりたいんだっけ？」ということになりがちです。

設計中は「やりたいことを整理している（もしくは できてる）」と思っていますが、いざユーザーと会話すると お互いに分かった気持ちになっているだけで 何を機能仕様として決定しているのか、やりたいことは充足しているのか ということが 明確になっていない状態だったということは起こりえます。

そういう時に「業務フローとして整理した〇〇は ユースケースとしてこういう風に整理しました。」と照合をしていけば 何を決めたのか ということが明確になります。

「フローにて課題と思われる〇〇は こうすることで解消できます」ということも あるかもしれませんね。

ユーザーと協力関係を築ける

相互理解は協力関係を構築するための第一歩。

地味かもしれないけど、このはじめの一歩をサボると、ユーザー・開発側相互に「彼らは良く分かっていない」と陰口を言う敵対関係にすらなってしまいます。

議論はすべきですが、敵対は無価値です。

Note

現行踏襲は業務フローではない

現行踏襲（＝旧システムを見ておいて）は業務フローではありません。それは調査依頼といいます。分析ですらありません。調査依頼でもないかもしれません。旧システムの設計を実装から書き起こすという仕事です。良し悪しもありませんし、意思も目的もありません。ただの作業です。作業は設計とはいいません。工数としてお金をもらって作業はしますが、それを設計というのは間違っていると思いますし、やったとしても その作成物は転記をした以上の価値も責任もありません。

現行システム調査を開発側したとしても 現行業務フローを作成して そこでユーザー自身の表現として精査して合意形成をしないと炎上すること必至です。

ちなみに ちょっとだけ言い方を変えた「現行通りの結果が出ること」も業務フローではありません。*5

完全な（？）マイグレーションは別かもしれませんが、これについては別枠なものだと思うので割愛します*6。

御用聞きではない

業務フローの整理は ユーザーのやりたいことを共有しているだけで 御用聞きではないです。

あくまで スタートラインと目的（目標ではない）の共有です。

「初期段階の状態を共有しただけ」ということをユーザーとも共有しておかないと 後でこじれます。

機能要件・非機能要件の確定でもないです。

旧システムがあると、システム化自体はできるんだろうと思ってしまうかもしれないけれど クラサバからWebシステムだと随分と作法が変わります。

ありがちなのがダイアログ。

例えばWebシステムでダイアログがフローの中に入ってくると工数が想定以上に跳ね上がります。

SPAなら出来ますよ！とかいう 出来る出来ないの話ではなくて、チーム体制や開発フレームワークなど全体（お金も含めた）の話です。

向き合うのはシステム

ユーザーの要求に応じてシステムを構築するのがスタートかもしれませんが、最終的にはシステムが作り出す付加価値に向き合うことを念頭にしておいた方が良いと思います。

この付加価値は得られるサービスからの直接的な便益だけではなくて 運用コスト（改修コスト）や開発コスト（品質など）も含めた話です。

ユーザーの要求を全てに行き渡らせると多分炎上します。ここで言う「全て」というのは、例えば ユーザーはプログラミングレベルの実装まで「要求」を出してくることがありますが それを そのまま受け取めると炎上するということを指しています*7。

そういうことを言いそうだなぁ、と思ったときに ユーザーに あなたたちが注力すべきは システムの目的ですよ という拠り所として ユーザーに理解しやすい表現である業務フローは良い素材です。

Hint

私が実際にやっていた行動に近しいアプローチ手法かも、と思ったのは

マジカランドへようこそ！ - マジカランド - 業務フローが誰でも簡単に書ける魔法のカード「マジカ！」

これ自体を使ったことは無いけれど、私の仕様の落とし込みに近い印象。

子供っぽいと思うかもしれないけれど、押さえるべき観点は押さえられていると思います。

過去の経験として

前提：私の立場は開発チームというよりも間接部門的なチームにいたので当事者ではないです。

大規模なシステム再構築プロジェクトの話

「ストーリーを共有することもしないで モデリング」なんてするの？と思うかもしれないですが 業務フローを作らずに、現行システムをベースにユースケース記述（図）を大々的に整理をしているプロジェクトがありました。

並行してモデリングもしていました。

たしかにユースケースとモデリングを相互にブラッシュアップするというのは正しいアプローチだと思います。

でも、そもそも何について、どういうことを実現するために それに取り組んでいるのか ということの足場や問題点をユーザーと開発側で共有をしていない中では できるものも出来ないんじゃないだろうか？と私は思いました。

開発側に非常に頭の切れる人がいたけれど、逆にその人が頭が切れるがゆえに 他のメンバー（チーム）との認識している世界が大きく異なっていたようにも思います。ユーザーの基準がその「できる人」基準になってしまって、他が付いて行っていないという感じです。

地味ではあるし、双方にとって「当たり前」かもしれないけれど、それを再構築することが目的の開発ということで 初心に戻って 業務フローから丁寧に整理すれば良いのに、、と思っていました。

特に個人的には、既存システムのリプレースの時こそ 当たり前を整理することを怠らないことが大事だと思います。そぎ落とすにしろ 付加価値をつけるにしろ、現行という土台を壊すなり 見直すなりした先に次期システムと言われるものがあるわけですから。

結局、私は途中で離れたけど、少なくとも一旦は頓挫したんじゃないかなぁ、たしか。。

ちなみに

ただし 多分、このまま設計・実装をしていくと、フローを中心とした旧来型と言われる開発手法になると思いますので、簡単に手続き型のシステムが出来上がります。

手続き型は、事実ややりたいことの積み上げ型（ボトムアップ）だと考えています。取っ掛かりもあり 上述のような業務フローを作成するという前提を含めて ある程度 大きく間違ったところに行きつかないと思っています。

そういう意味では良い手法だとすら思っています。

そこにトップダウン的な意味でのオブジェクト指向といわれるようなモデリングとユースケースによる整理で味付けをしていくと、保守や変更に強い（仕様が複数個所に分散していない・分散化しやすい構造）に近づいていくので更に良くなる、という感じです。 *8

ニュアンスとしては、ユーザーの要求を整理して、それをシステムにするとボトムアップで終わるんだけど、向き合う相手をシステムそのものとしたら ユーザーの要求に対して 何かしらの整理をトップダウンでする必要がありますよね？という感じです。

小さいとか使い捨てとか言われるシステムが手続き型でも良いんじゃないの？と言われるのは そういう意味からだと思っています。継続成長をさせるようなシステムは「ユーザー要望そのまんま」だけでは足りなくて プラスアルファとしてシステムとしての柔軟性や拡張性を持たせる必要がありますよね、という感じです。

さいごに

手続き型について、非常に規模が大きすぎて構築するだけでも泣きそうになる場合、確実に構築できる手段として選ばれているケースもあるように思います。やれSIerだ、IT土方だと 揶揄されるところかもしれませんが、ある意味では規模に対して思考停止して手を動かそう。。と涙目状態な開発案件という言い方も出来なくはないです。言い方は良くないですが「開発手法そのものが万人に理解できる」という訴求力です。それってエンジニアリングなの？という指摘はもっともだと思いますが、札束で顔を殴れる人たちにとって 理解不能であるというよりも 理解できるということは それだけでも価値があるということだと思います。

私自身は開発側（作り手側）として、積み上げた事実に対して 自分達の考えをトップダウンで盛り込みながら成長するシステムや開発（手法も含めて）にかかわる方が楽しいだろうと思っていますが*9。

手続き型でシステムで実現したい目的のひな型となるものを整理した上で、本来目指したいシステムをリファクタリングする、というのをバランスよく満たすと プロジェクトの進捗・チームのレベルアップ・リリース後も含めたシステムの成長 がイイ感じになるんじゃなかろうか？と夢想しつつ、 とりあえず、本日の思いつき整理はここまでにしようかと思います。

アーキテクトの審美眼 （DB　magazine　selection） [ 萩原正義 ]

現場で役立つシステム設計の原則 変更を楽で安全にするオブジェクト指向の実践技法 [ 増田亨 ]

*1:モデリングとかコンポーネント図とか 私がユーザーだったらどうでも良い表現です。ちゃんと 私の求めていることを分かっていますか？これを一番分かってほしい

*2:UML的な意味です。つまり内部・外部のシステムも含みます

*3:極論ですが、同じようなフローでもアクターによってシステム内部の挙動が全く違う ということは起こりえます

*4:モデリングとERは厳密には違いますが

*5:現行踏襲とすぐ言うユーザーは、合意形成の責任は取らないと宣言していると ほぼ同値なので 逃げられるなら逃げた方が無難です。もしくは責任に対する対価を請求額に計上しておいた方が良いでしょう。

*6:どこかの市とどこかのベンダーが訴訟をしていますが、そこについて私なりに思うところはありますが 割愛します

*7:素人が半端な知識で大工に口出しすると家が崩壊するのと同じ。良い職人は そこで施工主に「ダメだよ」と諭してくれます。でも、基礎工事をサボっているのを素人なりに見て取って「あれ大丈夫なの？」というのは重要です。このあたりの塩梅は難しいところですが、ニュアンスとしては こんな感じです。

*8:何をもってトップダウンと表現するのか？というところについては文脈によって結構違ってきます。たとえば「アーキテクトの審美眼」だと手続き型をボトムアップと表現してて、「現場で役立つシステム設計」だとオブジェクト指向の方をボトムアップと表現しています。どちらも それぞれの整理においては「正しい表現」だと 私は思っています。ここでは「アーキテクトの審美眼」側の意味で言っています。

*9:まぁ、一人開発ですから、関係ないんですけどね