第1段階のEoDのコツとは

誰しも設計者は,業務がどのようにソフトウェアに落ちるのかについて,イメージを持っていると思う。そのイメージは,必ず何らかの「軸」と「箱」で整理されたものであるはずだ。しかし,「軸」と「箱」が何なのか?というと,それはドメイン依存なものなので,形式的に語れないところが,もどかしい。しかし,パターンは何らかあるはず。例えば,今後の拡張性を第一に考え,しかも何らかのルールの組み合わせで全体の流れが構成できるのであれば,(Eclipse Platformのような)コア+プラグインというソフトウェアアーキテクチャを採用し,プラグインの候補を洗い出すための「軸」を定義して顧客と一緒にそれを探すというパターンが思いつく(これは今の仕事の受け売りだが)。あとは,例えばお金の流れの履歴を蓄積して,それを元に集計などを行う要求があれば,「金銭」をオブジェクト化し,金銭の「流れ」はオブジェクトの関連で表す。そして集計を見据えてVisitorパターンを適用できるように「金銭」オブジェクトを汎化しておき,顧客と一緒に「金銭」の種類と関連を定義していく,というパターンもあるだろう。

顧客の業務を,実装に近いデザインパターンで考えられるようにするとき,アーキテクトは「この場合はこのパターン」という引き出しを多く持っていればいるほど,「軸」と「箱」を見つけやすい,ということが言える。つまり,業務の内容をしっかりと理解するための「知識」と「理解力」,そしてそれらと「ソフトウェアアーキテクチャのパターン」との最適な組み合わせについて,豊富な経験が求められるのではないだろうか。さらに言えば,顧客の要求の中で,「軸」と「箱」からはみ出てしまうものがあれば,はみ出さないような仕様を提案できる「行動力」も求められるだろう。

業務分析を「ソフトウェアアーキテクチャの観点なしで」行っている光景をよく目にする。それではシステム構築のための作業とは言えないし,実装に対してプラスなことは得られない(業務は顧客に聞けばいい)。要求定義,業務分析を「 第1段階のEoD」なんだと意識して作業すると,スムーズに実装につなげられる。

では,第1段階のEoDに対して,何かコツ的なものはあるのだろうか?

身近なアーキテクトが実践していたコツは,「何でも2次元の表に落としてみる」ことだ。人間は3次元の世界で生活しているので,やっぱり「2次元」で整理できないことは理解できるわけがない。逆に言うと,2次元の表にできたら,それは整理できた証拠と言ってもいいのかもしれない。

それと,最大のコツは,顧客に「軸」と「箱」を理解させることによって,顧客が「システム構築の楽しさ」を理解してもらい,積極的に仕様検討に参加させる,ということだろう。整理の方法さえ与えてしまえば,顧客は「システム開発は辛いものなんだ」という認識も変わってくるはずだ。そうなればこっちのもので,かなり開発の都合(つまり,わがまま)をわかってもらえるようにもなる。XPの「オンサイト顧客」は,単に仕様をいつでも聞ける,ということではなく,一緒に設計ができるようにする,ということなんだと思う。

・・・と書いてきたが,実は第1段階のEoDができる人間は非常に少数だ。そして,たぶん僕は,その少数に入っていない。第1段階のEoDができるかどうかが, アーキテクトとエンジニアの違いなんだと思う。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて