冒頭の「はじめに」の部分でシステムを発注する側の人間（発注者）は「お客様」ではなく「プロジェクトメンバー」であるとの書き出しから始まっていますが、まさにその通りだと思います
何らかのシステムを作るとき、依頼を出す方はITベンダなりシステムエンジニアなりに要望を伝えたら自分の仕事は終わったと考えがちですが、そもそもちゃんとシステムの仕様をきちんとまとめ伝えているのかというとなかなかこれができない
「実際のものがないとよく分からないからとにかく一旦作ってよ！」
みたいな感じで始めてしまい、途中からどんどん追加の機能なり仕様なりを追加していってゴチャゴチャになってしまうことが多いのだと思います
確かに「システム開発」って聞いただけでも開発者でなければ何をすればよく分からず、手っ取り早く教えてもらいたくなる気持ちも分からなくもないのですが、自分たちの業務なりビジネスなりに深く関わることなので他人に任せっきりになってしまうのも、やはりどうかと思います
本書の冒頭では裁判沙汰になったある事案について語られ「ユーザー側にも責任があるんだよ」という例が示されております
「じゃあどうやって発注側の人たちは取り組んでいけばよいのか？」ということについて本文の中で解説されていくという流れです
本書の構成は「ザ・ゴール」などと同様の物語形式となっており個人的にはとても読みやすい内容でした
私なりに全部読んでみて特に重要だなと思った内容は以下の2点です
- 業務フロー図を作成する
- 要件定義を行う
重要というかある意味で基本中の基本なのかもしれませんが、この辺がよく分かっていないと最初からズッコケるのが目に見えそう…
ということで第1章から第2章にかけてこの辺の解説を絡めたお話が展開していきます
業務フロー図を描く上でのポイントとしては、「目的」を書き込んでおくことが良いとされています
また「懸念事項」や「理想」もできる限り洗い出して記載しておく方が良いそうです
こうすることで業務フローが本当に目的にかなうものであるのか？や目的と照らし合わせて不要な業務がないか？などの検証をする上でも重要とのこと
懸念や理想についても本当に役立つシステムを作る際のヒントがあぶりだされるとのことです
確かに進めている途中で目的を見失い、「結局何のためにやっているんだっけ？」みたいな状態にはまってしまい手段が目的になるみたいな本末転倒なパターンもありがちです
「目的」を常に意識して、それを達成するためにはどうするのが良いかといったことを考えながら進めるのがやはり重要なのだと思います
次に要件定義で重要なポイントとしては以下のようにまとめられております
- 要件は必要かつ十分であるか
- 要件は十分に詳細化されているか
- 業務の例外や異常を考慮しているか
- 要件が正しく管理させているか
- 体裁・文言
こうしたポイントをチェックすることでシステム開発を進めるうえで必要なことを漏れなく洗い出せるのでしょう
いずれにしても自社の業務なりをきちんと把握して、その上でどう改善していくかを考えないとモヤモヤしたままで何も解決できない
まずはその辺を整理して本当の課題ってものと向き合うところから始めるのがベターでしょう
要件定義というのは要するに仕様をまとめるということだと思います
要件には大きく分けて2通りあり「業務要件」と「システム要件」と定義されており、発注者側は「業務要件」の方をまとめる義務があります
先ほどの業務フロー図に実際の業務を落とし込み整理し、システム化を行う対象となる業務の流れを明確にすることがシステム開発成功への第一歩なのでしょう
まだまだ私自身システム開発というものについてよく分からないことだらけですので本書を頼りに何度も読み返し、理解を深められるようにしていきたいです
コメント