システム開発の進め方は１つしかないと思うな

SIer、ベンダー、etc.…

…いわゆる受注生産を行うIT企業ってまだまだ国内にたくさんあると思います。自社製品やサブスクモデルのWebサービスを提供してらっしゃる企業もあるかと思いますが、ここでは主に準委任や請負などで発注者の業務システムを受注し、開発するIT企業についてお話したいと思います。

システム開発。

開発モデルには昔から色々あったのですが、これについてはメリデメや適切な取捨選択について一時期に比べればかなり知られるようになってきたので今回は割愛したいと思います。

今回は

アナログ to デジタル（新規開発）
デジタル to デジタル（再構築/リプレース）

の違いについて触れてみたいと思います。

といっても、ここ２０年で完全にド新規の開発…要はこれまでシステム化されておらず紙媒体での運用やメール/Excelなどで運用していた業務をＩＴ化することで生産成功率の向上などを行おうとするような開発というのは恐ろしく激減しました。

昨今の現役エンジニアの中には、「現行システムから次期システムに作り替える」という開発しか経験したことがない、という人も多いのではないでしょうか。

私自身、60、70以上のプロジェクトに何らかの形で参画、経験してきましたけども、ド新規の開発というのは４～５件程度だったかもしれません。

ですが、だからといってこの「新規開発」と「再構築」にはいろいろと違いがあり、新規開発全盛の頃は当たり前のように実施されていた作業や作成されていたドキュメントなどを知らなくていいか？というとそのようなことはありません。なぜなら、ド新規でなくてもそれぞれの開発ベンダーの都合で、再構築であったとしてもド新規に近い開発を余儀なくされることがあるからです。

たとえば、現行のシステム資産が顧客にない状態。
サブスクのサービスなどを利用している場合、システム自身はサービス提供する企業の資産であって、内部構造などを開示することはありません。このようなシステムを利用すると、月々の経費、コストを節約することにはつながるかもしれませんが、そこからベンダー/メーカーを変えたい場合に内部仕様を次期システムのベンダに伝えることはできませんし、最悪の場合、データ移行すらできない場合だって起きかねません。

サービス自体は操作して確認することが可能かもしれませんが、内部はブラックボックスなので「答え（現行仕様）」を知らないと開発できない…なんて言い出すエンジニアやプロジェクトマネージャーはとても多くなってしまいました。

中には、そういうシステム利用をしてきた発注者側に責任があるような言い方をする人もいたりします。

そういう人たちは、そもそも「開発」の大原則を理解していません。

現行のシステムやサービスからのシステム移行である以上、現行と同じものが欲しいなんてことは絶対にありません。現行と同じものが欲しいのなら、現行のシステムやサービスをそのまま使い続ければいいはずです。

現行の仕様や設計など内部を知れば知るほど、余計な先入観をあたえ、まったく同じ仕様を実現すれば「最低限」が保証されるため、自分たちで思考、検討する労力をケチって、手を抜こうとするエンジニアやプロジェクトマネージャーが非常に目立ちます。

新規開発を経験したことのあるエンジニアやプロジェクトマネージャーであれば、そのようなことをせずともゼロから最短で設計する術を知っています。ここに、開発の引き出しの多さが如実に表れます。

特に昨今は開発モデルに関係なく「ドキュメンテーション」に重きを置かないエンジニアもどきが増加傾向にあり、失敗、問題、トラブルが後を絶ちません。

DFD

DFDとはデータフローダイアグラムの略で、最近ではほぼみかけなくなった設計書式の１つです。システムにおけるデータの流れを表した図で、システムの機能を洗い出すために使用されますが、用途・効能はそれだけではありません。「データ」という言葉がつくようにデータベースの設計にも大いに役立ちます。目的別にもちょっと触れてみましょう。

システム機能を洗い出す

DFD自体は要件定義工程で利用されることが多かったりしますが、基本的には「機能」の内容や量が確定するまで利用されますので、基本設計工程で作成することも当然あります。

要件定義で作成するときは、業務フロー図などから各アクティビティごとに取り扱うエンティティを整理することが主目的となっています。そもそも現在のITシステムといえばデータベースにデータを格納し、必要に応じて抽出・利用するものがほとんどです。機能間やプロセス間が一切のDBアクセスもなしに連動するシステム…というのは非常に稀でしょう。

厳密にはこのような連携にはならない