ユーザーの要求を正しく実装へつなぐ　システム設計のセオリー

まとめ
この本を読んだ理由
仕事に活かせるポイント
目次
感想

まとめ

システム開発で失敗してしまうあるあるとしては、要件定義で要件を定義し切れていなかったと言うことがあるわけですが、死捨て鵜飼発が失敗してしまう理由は、それだけではなかったりするのですよ。設計のミスだって、よくある出来事。じゃあ、どうすればいいの？というお話ですが、それは業務とデータをきちんと把握すること。ただ、それだけ。業務とデータをしっかり把握しないで、実装技術を考えること自体に無理があるんですよね、と。そして、業務とデータをの全容を把握するには、きっちり要件定義をする必要がありますねって言う話ですな。なんだ！　やはり、そこからじゃないか。

この本を読んだ理由

ひょんなことから、業務システム開発のPMを行うことになりまして･･･。はて、私は何屋さんだろう？という気がしなくもないのですが、復習の意味を込めて、設計について学び直しました。

仕事に活かせるポイント

設計フェーズで発生する事故の大半は「設計の手戻り」のような気がしています。そんな手戻りが発生しないためにはどうすれば良いのか？本書では手戻りの発生原因を次の2点にまとめています。①情報システムが組み込むべき業務設計のイメージを、ユーザーと開発者が共有していない。②データの不備。同音異義語や別名の洗い出し、用語統一、コード設計のデータ精微が不十分。

序章
0.1　システム設計へのアプローチ
第1章　情報システムと設計
1.1　情報システムにおける設計
1.2　設計の全体像と基本方針
第2章　論理設計のはじめに
2.1　要件定義でやっておくべきこと
2.2　実装の下準備
第3章　データ設計のセオリー
3.1　データの設計
3.2　外部インターフェイス設計
3.3　データの実装
第4章　プロセス設計のセオリー
4.1　業務プロセスの概要定義
4.2　業務プロセスの詳細定義
第5章　機能設計のセオリー
5.1　機能の概要定義
5.2　機能の詳細定義
第6章　ユーザビリティ設計のセオリー
6.1　ユーザビリティの概要定義
6.2　ユーザビリティの詳細定義
第7章　設計のToBeを実装のAsIsにつなぐために
7.1　インフラ系と運用系の仕様固め
7.2　SOA・アジャイル開発への期待
あとがきに代えて

感想

ひょうんなことから、業務システム開発のPMを、久しぶりにやることになりまして。古くなってしまった私の知識をリフレッシュさせるために、この本を手に取ったわけですね。

システム開発がうまく行かない。その原因の多くは、ユーザーの要求を把握し切れていなかった、つまり、要件定義が十分に行えていなかったというところに、はなしがつきるわけですね。しかしですね、かといって、要件定義が開発プロジェクトを失敗委に追い込む原因の100％でははないのです。

設計がうまく行かなくて失敗することだってあるんですよ、と。だから、設計をちゃんとやりましょうね。そのためのプロセスはこうですよ、と教えてくれるのが本書。

すてき。

ちなみに本書では、次の3点を定義して、設計というプロセスを進めていくのだという。

①データ
②業務プロセスとそれを実現する機能
③データと業務プロセスの交差点、およびデータと機能の交差点

まとめると、シンプルだ。

そしてここでも出てくる、業務プロセス。業務プロセスがちゃんと理解できていないと、まともな設計なんか、できないってことですね。

さてさて。

では、業務プロセスをどのように設計に落とし込んでいくのかというと、本書では次のようにその流れを定義しています。

①要件定義（論理設計）：要求の実現化に関する、開発者と利用者の間の合意形成。合意に伴い、次の②基本設計（論理設計）のインプット都市て有効な成果物を作成することを目指します。
②基本設計（論理設計）：要件に応じた設計結果に関する開発者と利用者の間の合意形成。合意に伴い、次の③基本設計（物理設計）のインプットとして有効な成果物を作成することを目指します。
③基本設計（物理設計）：上記②の結果に基づき、物理的要素を加味して、実装の準備を行います。これに伴い、次の④詳細設計（物理設計）のインプットとして有効な成果物の作成を目指します。
④詳細設計（物理設計）：実装のための設計を行います。

やっぱ、要件定義と設計を、バスって切ってしまっちゃだめなんだよな。

ユーザのやりたいことから、業務フローをかしかして、業務プロセスに落とし込んで、設計に入っていく。まとめてしまえば簡単ですが、ユーザーのやりたいことというばくっとしたイメージを、ユーザー側と、開発者側で握れていなければ、その後のプロセスは全部意味のないものになってしまうわけですね。そして、その業務プロセスを流れるデータはどのようなものか？データにはどのような処理が成されるのか？ここもきっちり握れていないと、アウトになってしまうわけですな。

奥が深いな、設計は。
そして、要件定義が重要なんだな。
ちなみに、要求はユーザが情報システムで実現したいこと。要件は要求に基づき、成約を踏まえて、情報システムに盛り込むべきもの。