失敗しないシステム開発の結論。そして検証編へ

[数ヶ月の放浪から帰ってまいりました…]

システム開発会社の中で仕事をしてきたわけでもない（非システムエンジニアという意味において）単なる一般人である私が、システム開発について失敗しない方法として最終的に落ち着きつつある結論は

『システム開発準備段階のシステム設計書（要求仕様書）を完璧な状態にする』

ということです。
（薄々分かっていたことではありますが…）

完璧な状態とは、「開発着手後から納品まで一切の仕様変更をしない」という前提で記載した書類（ドキュメント）のことです。
つまり、開発依頼者にとっては「要求仕様書＝納品物」ともいえる状態に持って行くわけです。

さて、そうなると準備段階（書類作成段階）において、システム開発依頼者には驚異的な負担とプレッシャーが掛かってきます。

なぜなら、開発前段階であるが故に相談できるシステムエンジニアやプログラマーがいないという状態を覚悟する必要があるからです。


そこで、「システムについての知識が無くてもシステムの設計を可能にする方法」を確立しなければなりません。
少なくとも、システムエンジニアが見て「これなら●●の工期で費用は■■円くらいかなぁ」と、見積もりの概算を弾き出せるレベルに仕上げる必要があります。

まず、開発言語やデータベース、サーバーやネットワーク構造などをどうするかという部分は完全に無視します。
すでに制約がある場合は別ですが、普通はいきなり「開発言語は何にします？」と聞かれても「ハァ？？？いや…別に…決まっていませんが？」です。

楽天ビジネスの見積もりサービスなどでは、開発条件について詳しく記載する部分がありますが、正直なところ「何を書けばよいのか」すら分かりません。
システムエンジニアの側にすれば、そんなことも決まっていないのに見積もり取らせようとするなよ！という感じなのでしょうが、分からないものは分からないのですから仕方ありません。

仕方ありませんので、技術的な部分は敢えて空欄にしておきます。

その代わり、別の情報で補います。

それが

【Why：目的】
　…　システムや機能の目的
【Who：利用者】
　…　システムや機能のユーザー（人だけでなく別の機能がユーザーになることもあります）
【What：扱う情報・データ】
　…　商品・メールアドレス・名前・住所・ID情報など
【How：機能】
　…　どんな処理をするのか。データを表示する、メールを送信する等
【When：利用時間】
　…　WEBシステムなら365日24時間が普通でしょうか。機能なら、どんな場合にその機能が起動するのか等
【Where：利用場所】
　…　WEBシステムならインターネットに接続された場所。機能なら、ログインした状態、こういう場合など制約条件になると思われます。
【How many：利用頻度】
　…　WEBシステムなら、１日どれくらいのアクセスがあるか。会員サイトであれば利用人数など。機能なら１時間に１回、１年に１回など。
　　　具体的に数字で表現することが重要。ちょっと少なめ等のあいまいな表現は出来る限り使わないように心がけること。

の5W2Hの７項目で記述された機能・システムの説明です。

具体的には次のような感じになります。

開発すべきシステムは、【Why：目的】の為に【Who：システム利用者】が【What：システムで扱う情報・データ】を【How：機能】するものです。
このシステムは【When：利用時間】【Where：利用場所】において【How many：利用頻度】使われます。

このシステムで必要になる機能は、【Why：目的】の為に【Who：システム利用者】が【What：システムで扱う情報・データ】を【How：機能】するものです。
この機能は【When：利用時間】【Where：利用場所】において【How many：利用頻度】使われます。


複雑なシステムになるほど構成要素としての機能も増えますが、単純な機能に分解して考えることでシステムエンジニアではなくても複雑なシステムを設計できます。
一言でいえば『5W2Hで説明される機能の集合体によって5W2Hで説明されるシステムを作る』ということです。

実際には、まだ理論に過ぎません。本当にこの方法で上手くいくのか検証を行う必要があります。
理論的には、この方法を使えば、"紙"の状態で銀行のオンラインシステムの設計も可能な筈です。


次からは検証編に入っていきます。
（最終的には銀行のオンラインシステムの要求定義書を公開するところまで行きたいですね）