【読書】システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意

モニターということで、ソフトバンククリエイティブ様より御本を贈って頂きました。ありがとうございます。

まだ隅々までは目を通しきれてはいないのですが、いま読んでいて思ったことなど書いておきたいと思います。



■はじめに

この本の最後の章には次のような記述があります。

・本書は共通・文書化などを取り上げているため、「ウォーターフォール」型開発に関する書籍だととらえられてしまうのではないかという危惧を抱いています。 

・本書ではあえて設計や文書化の方法に多くの説明を行っています。これは、「設計要素を知っていて文書や記述を削る」のは適切な行為だと思いますが、「設計要素があることを知らずに文書や記述を削る」のは品質やプロジェクトの遂行に対してマイナスの要素をもたらすと考えているからです。 

・アジャイル開発では「設計はしない」「設計書は書かない」ととらえているとしたら、それは誤解です。アジャイル開発においても当然設計は行います。

この本自体は、要求から始めて段階的に設計を詳細化していくというスタイルで記述されており、一見するとウォーターフォールなソフトウェア開発における上流工程のエンジニアリングについて書いてあるように見えます。

しかし、先ほど引用した文章に書いてあるとおり、著者の意図は『この本に書いてある順番どおりに設計プロセスを進めて欲しい』ではなくて、あくまで『各種設計フェーズにおける検討事項や設計する際のポイントについて理解してもらいたい』なのです。

ここを押さえて読むのと押さえないで読むのとでは、だいぶ受ける印象が違うと思います。

※なお、3つ目の引用では、アジャイルと設計・ドキュメンテーションの関係について触れているのですが、この点はとても大事だと思います。大事なことなので繰り返し書きますが、アジャイルなソフトウェア開発でも設計はするし、必要なだけのドキュメントは書きます。



■感想

システム設計についてこれから始める人にとってはいろいろ便利な本なのかなーと思いました。

タイトルにあるとおり、この本はシステム設計についての本なので、システムを構築するにあたっての知見がいろいろと詰めてあります。例えば、要件定義から設計の間にやるべきこととして、次のような作業を上げています。

●全体設計
・システム境界図
・システム俯瞰図
・サブシステム連携概要 

●アーキテクチャ方針
・オンラインアプリケーション方針
・帳票出力方式
・ジョブ管理・実行方針 

●標準設計
・文書テンプレート
・記述粒度・ガイドライン
・設計基準 

●共通設計
・画面共通
・帳票共通
・バッチ共通
・DB共通
・メッセージ共通

割とがっつりと検討してますよね。で、この"がっつり"という点が個人的には重要だと思っています。

例えば、システム設計について経験したことが無い人がその辺りの知識を自主的に学ぼうと思った場合を考えます。個人的にちょっとしたツールなどを作るときに、設計などやってみて知見をためるというのは1つの優れたやり方ではあるのですが…　こと設計については話がやや異なると思っていて、それは"ちょっとしたツール"という規模だと、上述したような質・量で事前の検討はしないと思うからです（してもあまりメリットを実感できないと思います）。つまり、そこから学ぶことができるはあくまで"ちょっとしたツール"の規模の複雑さと、それに応じた設計までにしかならないということです。

あるいは、自主的に学ぶのではなく実際にシステムを作るときに失敗などを経験し、そこから学ぶのもよいのですが、現場で失敗するのはいろいろとおいしくないし、それよりは先人の知恵から学んだ方が良いわけで、そういう意味でこの本は便利だなーと思いました。


で、この本を読む時、成果物として定義してあるドキュメントの書き方からそのまま覚えていくという、ストレートな学び方もありだと思うのですが、ここまでかっちりしたドキュメントが必要となる現場はともかく、そうでない現場にいる人であれば、もう少しエコに読み進めていくのが良いとも思います。

システムの構築を行う際にその設計が求められる理由や、その設計を行うことによってどのようなリスクを事前に考慮できるのかなど、そういった観点に立って読んでいくと良いということです。


また、粒度や方針・整合性といった、一貫性のある設計をするのであれば否応なしに意識せざるをえない観点について、繰り返し記述が入っているのも良いと思いました。そういうのは大事です。

設計における一貫性を検討しない（設計思想がない）まま実装を始めてしまうと、やはり当然というか、コードからは設計レベルにおける意図が見えてこないような成果物ができてしまうだけなので…　やはりそういうソースは保守していくのも面倒だし…



■最後に

この本はオブジェクト指向やドメイン駆動なアーキテクティング・デザインについての本ではないと断ってあるのですが、OODやDDDから始める場合だってオブジェクトを永続化するのに使うのは大体の場合DBなわけで、そうであるならI/Oやトランザクションについて検討するのはやはり重要なわけです（この本に書いてあるような事柄を検討しないまま実装するとだいたい後で酷い目に会います）。

この本は、そういう意味でも"開いた"内容になっているので、この本に書いてあることがズバリ当てはまるような業務系のSEだけではなく、広い意味で設計に関わっていくような人はまず押さえておくとよいのかなーと思いました。

個人的には、手元においてハンドブックみたいに使おうかなーと思っています。