『システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意』
を読んだので、その内容について纏めます。本書の内容を一言に圧縮すると、
「要件と開発を橋渡しするための基礎力養成ドリル」
です。
中でも肝要と感じたトピックは、以下の３つです。
- 可不可よりも過不足を捕らえること
- 設計は品質と背中合わせだということ
- 絵を書くこと
これらについて、順に思考を巡らせます。
1. 可不可よりも過不足を捕らえること
ここでいう設計は、「顧客から要件を聞き出しまとめた後～「プログラムの具体的な実装方法を考える直前」までを対象としています。
その上で、先ず抑えた方がよい事として、可不可よりも過不足を捕らえることがあります。
要件定義をしている中で私自身もよくやりがちなのが、
「Aは標準の機能で対応可能です。Bは今のシステムのままでは対応できないため、新規開発が必要です。」
といった応対で終えてしまうことです。
顕在化した要件に対する応答としてなら、「可」とは思いますが、必要十分な対応かという視点であれば「否」と思います。
上記のような応対はもちろん、システムで対応出来る事と出来ない事との線引きに有効です。
次のステップとして、「過不足」を捕らえ、評価できるようになれと本書は語ります。
「過不足」とは『こんな事は無いのかな？』『こういう要件があるのなら、他にこんな要件があるはずでは・・・？』といった確認事項を指します。
例えば、
「国内の企業からある原料を購入するには、Xという機能を使えば対応可能です。ただ、海外の企業からですと、Xでは対応できませんので、カスタマイズが必要です。」
という「可不可」が存在したなら、次のような「過不足」へと考えを巡らせます。
『国内の複数企業から同じ原料を購入することは無いのだろうか？』
『海外の企業から購入する要件があるのなら、輸出に関する要件もあるはずでは・・・？』
といったように。
こういった「過不足」を確認事項として顧客とシェア出来るようにすると、ワンランク上の技術者となれるだろうと、本書は謳っています。
2. 設計は品質と背中合わせだということ
本書の中で多く出てくるキーワードに、「品質」があります。
設計をする際のビューポイント（視点）として「品質」の指標を用いたり、品質を担保するために設計の「型」を使ったりと言った例が挙げられています。
私が過ごしてきたプロジェクトでは、「開発の後からどんなテストをするか、品質を担保するか考える」環境が多く、設計の際に品質の事について考えを巡らせる機会は少ない印象がありました。
※私が単にそう感じただけである可能性もありますが。
「品質」の指標という点で言うなら、ISO9126やISO/IEC25000シリーズなどがあります。
しかしこれらはフルコース過ぎて、すべてをこなすには体力や時間が足りなさ過ぎます。
以前のプロジェクトで実際にISO9126を適用して、テストをどう作るか考えた事がありますが、６つある大分類のうち２つしか使うに至りませんでした。
※４つはリソースが足りない、必要がない、やる時期でないなどの理由から対象外としました。
これはあくまでも「テストをするとなった直後の話」ですので、設計時であれば、６つすべてを考慮に入れてもよいのでは、と考えます。
考慮に入れるとはいえ、そこで「過不足」の検討をすることは必至であると思いますが。
3. 絵を書くこと
最後に、私が大切と感じた事に、「絵」があります。
本書では始終に渡って多くの「絵」が出てきます。
「絵」で表現するメリットの最たるものは、「共有のしやすさ」にあると私は思っています。
文章では、「自身で考えていること」がすべからく表現出来ない時が多いとも思っています。
いずれにせよ「共通認識」がある程度必要ですが、文章よりは「絵」の方がその量を抑えられます。
文章では背景情報の共有や、用語の意味の共有に細心の注意を払う必要があります。
「絵」であれば、書き方やオブジェクト、色の意味だけを共有すれば「本論」に入ることができます。
「本論」も、「絵」であれば俯瞰して話を進めることができるため、考慮に漏れがないかが気付きやすくなります。
本書にはそんな共有のための「絵」が具体例として多く収録されています。
先輩や自分自身が書いていた絵はもちろん、その他の絵の意義や有用性を再認識する契機になりました。
以上が、私が本書を読んで考えを巡らせたことです。
この本には、設計について学ぶ道もいくつか参考文献などの形で示されていました。
それらでこの先の道標を確認しつつ、まだまだ思考を巡らせます。