Web 世代が知らないエンタープライズシステム設計

会計や販売管理などのシステムについての知識が少ない Web 系のエンジニアにはもちろん、業務システムにかかわる全てのエンジニアにとって、予定通りにエンタープライズシステム、つまり企業情報システムを予定通りに稼働させるのは至難の業だ。
稼働のカギはシステムの設計にある。本書では長年の経験を持つプロたちが、16 の視点から、実践的なシステム設計の 80 勘所を示している。
全てを読めば、データモデリングを通じた業務設計、正確なプロジェクトのスコープとデータモデルを用いたセオリーの決定、GOAL の共有、システム開発方法論とデータマネジメントを通じた業務ドメインの理解、適切なキーパーソンへのヒアリングとこれを反映した業務フロー図、データモデルの作成、などについてその道のプロならではのものの見方、仕事の進め方が自然と伝わってくる。
腐ることのないシステム設計の本質に迫る独自のノウハウ満載の他に類を見ない 1 冊だ。
第 1 章 若奥さんを助けるための「花束問題」、これが解けたら立派な中堅技術者だ
第 2 章 本当は怖い「プログラミングの学び過ぎ」、実装オジサンを避ける必須知識はこれだ
第 3 章 顧客の要件があいまいすぎる? プロは嘆く前に「専門性」を磨く
第 4 章 スコープ決定の「やってはいけない」、予算や納期にこだわるべからず
第 5 章 DX 時代に UI 偏重は危険、ユーザーヒアリングのまんま設計するな!
第 6 章 2025 年の崖を前に再構築を見送り、情シス部長はなぜそう決めたのか
第 7 章 しっかりしたシステム企画を立てるコツ、アリストテレス伝来の「型」にはめよう
第 8 章 「構築すべきではないシステム」の構築を避ける目的手段展開法
第 9 章 「RDB 生みの親」の提言から 50 年、データの泥沼から出られない日本企業
第 10 章 設計者やプログラマーは「見えない問題の探求者」、創造の暗黙知を継承せよ
第 11 章 ジャック・ウェルチをぎゃふんと言わせた、伝説のコンサルに学ぶ「方法論」の本質
第 12 章 システム設計で成功したいあなたへ、業務ドメインにデータモデリングで切り込もう
第 13 章 顧客の部門長に何が何でも会い、「あるべきシステム」を掘り出せ
第 14 章 顧客も技術者も不幸になる人海戦術に終止符を、実データで設計を吟味せよ
第 15 章 若手エンジニアには分からない? 業務システムになぜ RDB が必要か
第 16 章 Web 世代の皆さん、企業情報システムを見たことがありますか?

『Web 世代が知らないエンタープライズシステム設計』 (IT 勉強宴会 編、日経 BP、2022 年 4 月刊) は、企業の会計や販売管理などを支える業務システムを、予定どおりに稼働させるための上流工程の考え方を、全 16 章にわたって示した書籍です。副題は「16 の視点から学ぶ一生使える上流工程の勘所」で、版元は、長年の経験を持つ執筆陣が 16 の視点から実践的なシステム設計の 80 の勘所を示す本と紹介しています。想定する読者は、会計や販売管理などのシステムの知識が少ない Web 系のエンジニアに加えて、業務システムにかかわるエンジニア全般です。

全 16 章の構成、花束問題から企業情報システムの姿まで

目次は 16 の章が順に並ぶ形で、部の区切りはありません。第 1 章「若奥さんを助けるための「花束問題」、これが解けたら立派な中堅技術者だ」から始まり、第 2 章はプログラミングを学び過ぎることの危うさ、第 3 章は顧客の要件のあいまいさに向き合う専門性、第 4 章はスコープ決定でやってはいけないこと、第 5 章は UI に偏った設計とユーザーヒアリングの扱いを取り上げます。第 6 章は 2025 年の崖を前に再構築を見送った情報システム部長の判断、第 7 章はシステム企画を立てる型、第 8 章は構築すべきではないシステムを避ける目的手段展開法です。中盤以降は、第 9 章が RDB の生みの親の提言から 50 年を経てもデータの泥沼から出られない日本企業、第 10 章が創造の暗黙知の継承、第 11 章が方法論の本質、第 12 章が業務ドメインにデータモデリングで切り込む方法、第 13 章が顧客の部門長に会ってあるべきシステムを掘り出すこと、第 14 章が人海戦術をやめて実データで設計を吟味すること、第 15 章が業務システムに RDB が必要な理由と続き、第 16 章「Web 世代の皆さん、企業情報システムを見たことがありますか?」で締めくくります。版元の紹介文によれば、全体を通して、データモデリングを通じた業務設計、プロジェクトのスコープの決め方、システム開発方法論とデータマネジメントを通じた業務ドメインの理解、キーパーソンへのヒアリングとそれを反映した業務フロー図の作成といった仕事の進め方が伝わる構成です。

上流工程でデータモデルを先に固める理由

業務システムの設計が Web サービスの開発と大きく違うのは、扱うデータが会社の業務そのものを映していて、画面やプログラムよりもはるかに長く使われる点です。顧客、商品、取引先、勘定科目といったデータは、販売、購買、会計など複数の業務で共有され、どこか 1 か所の定義が曖昧なまま作られると、後から組まれる多くのシステムに食い違いが広がります。そのため 要件定義 の段階で、業務の言葉をデータの構造に落とし、どのデータが何によって一意に決まるのかを関係者と合意しておくことが、後工程の手戻りを減らすうえで決定的に効きます。関係データベースの設計で データ正規化 が重視されるのも、同じ事実を 1 か所にだけ持たせ、更新の食い違いを構造で防ぐためです。画面の要望を聞いた順に作り込む進め方は小さなサービスでは速く見えても、部門をまたぐ業務システムでは、データの持ち方の不整合として後から大きなつけを払うことになりがちです。

業務システムに関わる Web 系エンジニアに向く理由と、向かない目的

本書が合うのは、Web 系の開発を経験したあとで業務システムの案件に加わり、顧客の要望をどう聞き、何を先に決めるべきかに迷っている人です。章の題の多くが、要件のあいまいさ、スコープの決め方、ヒアリングの相手、実データでの検証といった上流の現場で起きる場面を正面から扱っているため、自分の案件の状況と照らし合わせながら読み進められます。一方で、目次には、特定の言語やフレームワーク、クラウドの製品を使った実装の手順を章として立てた項目はありません。コードの書き方や製品の設定を学びたい場合は、目的に合う別の本を選ぶほうが近道です。

業務システムの設計で、画面の要望に振り回されずにデータと業務の構造から考える足場を持ちたい人にとって、上流工程の勘所を章ごとの場面として示す本書は、案件に入る前に読んでおく価値の高い一冊です。本書でデータモデルの重みを理解したあとに、関係データベースの設計そのものを体系的に学びたくなったら、データベース本の選び方 を手がかりに次の一冊を探すと、上流の判断と設計の技法を地続きで身につけられます。