[数ヶ月の放浪から帰ってまいりました…]
システム開発会社の中で仕事をしてきたわけでもない(非システムエンジニアという意味において)単なる一般人である私が、システム開発について失敗しない方法として最終的に落ち着きつつある結論は
『システム開発準備段階のシステム設計書(要求仕様書)を完璧な状態にする』
ということです。
(薄々分かっていたことではありますが…)
完璧な状態とは、「開発着手後から納品まで一切の仕様変更をしない」という前提で記載した書類(ドキュメント)のことです。
つまり、開発依頼者にとっては「要求仕様書=納品物」ともいえる状態に持って行くわけです。
さて、そうなると準備段階(書類作成段階)において、システム開発依頼者には驚異的な負担とプレッシャーが掛かってきます。
なぜなら、開発前段階であるが故に相談できるシステムエンジニアやプログラマーがいないという状態を覚悟する必要があるからです。
そこで、「システムについての知識が無くてもシステムの設計を可能にする方法」を確立しなければなりません。
少なくとも、システムエンジニアが見て「これなら●●の工期で費用は■■円くらいかなぁ」と、見積もりの概算を弾き出せるレベルに仕上げる必要があります。
まず、開発言語やデータベース、サーバーやネットワーク構造などをどうするかという部分は完全に無視します。
すでに制約がある場合は別ですが、普通はいきなり「開発言語は何にします?」と聞かれても「ハァ???いや…別に…決まっていませんが?」です。
楽天ビジネスの見積もりサービスなどでは、開発条件について詳しく記載する部分がありますが、正直なところ「何を書けばよいのか」すら分かりません。
システムエンジニアの側にすれば、そんなことも決まっていないのに見積もり取らせようとするなよ!という感じなのでしょうが、分からないものは分からないのですから仕方ありません。
仕方ありませんので、技術的な部分は敢えて空欄にしておきます。
その代わり、別の情報で補います。
それが
【Why:目的】
… システムや機能の目的
【Who:利用者】
… システムや機能のユーザー(人だけでなく別の機能がユーザーになることもあります)
【What:扱う情報・データ】
… 商品・メールアドレス・名前・住所・ID情報など
【How:機能】
… どんな処理をするのか。データを表示する、メールを送信する等
【When:利用時間】
… WEBシステムなら365日24時間が普通でしょうか。機能なら、どんな場合にその機能が起動するのか等
【Where:利用場所】
… WEBシステムならインターネットに接続された場所。機能なら、ログインした状態、こういう場合など制約条件になると思われます。
【How many:利用頻度】
… WEBシステムなら、1日どれくらいのアクセスがあるか。会員サイトであれば利用人数など。機能なら1時間に1回、1年に1回など。
具体的に数字で表現することが重要。ちょっと少なめ等のあいまいな表現は出来る限り使わないように心がけること。
の5W2Hの7項目で記述された機能・システムの説明です。
具体的には次のような感じになります。
開発すべきシステムは、【Why:目的】の為に【Who:システム利用者】が【What:システムで扱う情報・データ】を【How:機能】するものです。
このシステムは【When:利用時間】【Where:利用場所】において【How many:利用頻度】使われます。
このシステムで必要になる機能は、【Why:目的】の為に【Who:システム利用者】が【What:システムで扱う情報・データ】を【How:機能】するものです。
この機能は【When:利用時間】【Where:利用場所】において【How many:利用頻度】使われます。
複雑なシステムになるほど構成要素としての機能も増えますが、単純な機能に分解して考えることでシステムエンジニアではなくても複雑なシステムを設計できます。
一言でいえば『5W2Hで説明される機能の集合体によって5W2Hで説明されるシステムを作る』ということです。
実際には、まだ理論に過ぎません。本当にこの方法で上手くいくのか検証を行う必要があります。
理論的には、この方法を使えば、"紙"の状態で銀行のオンラインシステムの設計も可能な筈です。
次からは検証編に入っていきます。
(最終的には銀行のオンラインシステムの要求定義書を公開するところまで行きたいですね)
システム開発会社の中で仕事をしてきたわけでもない(非システムエンジニアという意味において)単なる一般人である私が、システム開発について失敗しない方法として最終的に落ち着きつつある結論は
『システム開発準備段階のシステム設計書(要求仕様書)を完璧な状態にする』
ということです。
(薄々分かっていたことではありますが…)
完璧な状態とは、「開発着手後から納品まで一切の仕様変更をしない」という前提で記載した書類(ドキュメント)のことです。
つまり、開発依頼者にとっては「要求仕様書=納品物」ともいえる状態に持って行くわけです。
さて、そうなると準備段階(書類作成段階)において、システム開発依頼者には驚異的な負担とプレッシャーが掛かってきます。
なぜなら、開発前段階であるが故に相談できるシステムエンジニアやプログラマーがいないという状態を覚悟する必要があるからです。
そこで、「システムについての知識が無くてもシステムの設計を可能にする方法」を確立しなければなりません。
少なくとも、システムエンジニアが見て「これなら●●の工期で費用は■■円くらいかなぁ」と、見積もりの概算を弾き出せるレベルに仕上げる必要があります。
まず、開発言語やデータベース、サーバーやネットワーク構造などをどうするかという部分は完全に無視します。
すでに制約がある場合は別ですが、普通はいきなり「開発言語は何にします?」と聞かれても「ハァ???いや…別に…決まっていませんが?」です。
楽天ビジネスの見積もりサービスなどでは、開発条件について詳しく記載する部分がありますが、正直なところ「何を書けばよいのか」すら分かりません。
システムエンジニアの側にすれば、そんなことも決まっていないのに見積もり取らせようとするなよ!という感じなのでしょうが、分からないものは分からないのですから仕方ありません。
仕方ありませんので、技術的な部分は敢えて空欄にしておきます。
その代わり、別の情報で補います。
それが
【Why:目的】
… システムや機能の目的
【Who:利用者】
… システムや機能のユーザー(人だけでなく別の機能がユーザーになることもあります)
【What:扱う情報・データ】
… 商品・メールアドレス・名前・住所・ID情報など
【How:機能】
… どんな処理をするのか。データを表示する、メールを送信する等
【When:利用時間】
… WEBシステムなら365日24時間が普通でしょうか。機能なら、どんな場合にその機能が起動するのか等
【Where:利用場所】
… WEBシステムならインターネットに接続された場所。機能なら、ログインした状態、こういう場合など制約条件になると思われます。
【How many:利用頻度】
… WEBシステムなら、1日どれくらいのアクセスがあるか。会員サイトであれば利用人数など。機能なら1時間に1回、1年に1回など。
具体的に数字で表現することが重要。ちょっと少なめ等のあいまいな表現は出来る限り使わないように心がけること。
の5W2Hの7項目で記述された機能・システムの説明です。
具体的には次のような感じになります。
開発すべきシステムは、【Why:目的】の為に【Who:システム利用者】が【What:システムで扱う情報・データ】を【How:機能】するものです。
このシステムは【When:利用時間】【Where:利用場所】において【How many:利用頻度】使われます。
このシステムで必要になる機能は、【Why:目的】の為に【Who:システム利用者】が【What:システムで扱う情報・データ】を【How:機能】するものです。
この機能は【When:利用時間】【Where:利用場所】において【How many:利用頻度】使われます。
複雑なシステムになるほど構成要素としての機能も増えますが、単純な機能に分解して考えることでシステムエンジニアではなくても複雑なシステムを設計できます。
一言でいえば『5W2Hで説明される機能の集合体によって5W2Hで説明されるシステムを作る』ということです。
実際には、まだ理論に過ぎません。本当にこの方法で上手くいくのか検証を行う必要があります。
理論的には、この方法を使えば、"紙"の状態で銀行のオンラインシステムの設計も可能な筈です。
次からは検証編に入っていきます。
(最終的には銀行のオンラインシステムの要求定義書を公開するところまで行きたいですね)
私は数個の大規模プロジェクトが失敗した状況を見てきました。
原因は次の3点にあると考えております。
1)顧客がシステムを知らない(貴殿の反省通り)
2)SEが必要なフレームワークの選択を誤る
3)必要なプログラマを集められない
今回は知らない会社へ発注したようですので、2),3)の問題にも該当します。
発注する場合は、会社のトップ同士で話しができるような開発体制を取る必要があります。
・工程の遅延
・技術者の能力不足
・品質問題
など見つかった段階でただちにトップ会談に持ち込むことが重要と考えます。
システムの開発途中に社員が会社を辞めるなどは貴社のシステム開発に担当者とトップとの意見の相違があるようにも思われます。
技術者は顧客優先を採りたい場合が多いのですが、サラリーマンである以上、会社優先となり板ばさみになることが多くあります。
気心の知れた外注会社を育成するくらいの気持ちで長く付き合うことも必要です。