![](https://smilekao.com/wp-content/uploads/2024/04/news3125-1024x576.png)
この記事では、要件定義の前に重要なことや、方針の策定のポイントについてご紹介します。
システム開発について、課題をお持ちの方は、
下記よりお気軽にご相談ください。
目次
システム開発は、「成功」しない・・・
システム開発の問題は、「成功」しない事です。
上の表は古いデータですが、70%以上が、「課題あり」「失敗」と回答しています。
つまり、「成功」しないのです。。
原因は、
次の3点です。
①開発段階の要件不足 → 品質
②計画遅延 → 納期
③予算の超過 → コスト
つまり、品質(Q)、コスト(C)、納期(D)= QCDが原因だとわかります。
この、QDCがうまく行かないのは、
依頼主は、依頼をしたシステム開発会社に全て任せる事ができる
と思っている事が原因だと考えます。
特に、
「要件定義」が失敗するためだと、私は考えます。
しかし、
実際は、この「要件定義」の前の
方針の段階が不十分である事が多いです。
そのため、
方針を中心に、説明します。
要件定義が重要な理由
![テスト工程](http://wordpress.smilekao.com/wp-content/uploads/2021/04/7工程の関係-1024x500.png)
開発されたシステムは、テストを行う必要がありますが、
テストは、
「単体テスト・結合テスト」「総合テスト」「受入テスト」の3段階があり、
図のように、
「開発」「設計」「要件定義」が対応しています。
「単体テスト・結合テスト」「総合テスト」は、
主に開発会社が行うものであり、
設計通りに開発ができているかを確かめるものです。
「受入テスト」は、主にお客様が行うものであり、
望んでいたもの=要件定義通りにできているかを確かめるものです。
![要件定義が基本](https://smilekao.com/wp-content/uploads/2021/04/テスト工程2-1-1024x687.png)
上の図のように、
「要件定義」は、設計、開発の起点であり、
「要件定義」は、受入テストの確認項目です。
それゆえ、「要件定義」が重要なのです。
「要件定義」は、お客様ご自身で決めていただくことであって、
開発会社がわかる事ではありません。
「要件定義」の失敗とは、お客様がご自身で決める事に失敗しているということになります。
全体の流れと検討内容
![システム化流れ](https://smilekao.com/wp-content/uploads/2021/04/1-1-1024x437.png)
どのように要件定義すればいいのか、先に全体をみてみます。
システム開発では、上記のように、大きく8工程が必要です。
お客様が行う内容は、
①方針
②計画
③要件定義
⑤テスト、移行、運用
8工程のうち、6工程に及びます。
開発会社は、
設計、
開発、
テスト、
この3工程だけです。
つまり、お客様は、開発会社に丸投げできないのです。
システム開発がうまく行かないのは、
お客様ご自身の課題が多い状態で、
システム開発会社に丸投げをしてしまうことが主な原因だということになります。
移行、運用、この2工程は、それ自体重要ですが、
事前に計画をすれば、あとは実施するだけであることを考えると、
①方針、②計画が、重要です。
また、③要件定義は、方針、計画に基づいて確定させる必要がありますので、
先に、①方針、②計画、を決めておく必要があります。
現状分析と課題の特定
新しいシステムを考えるとき、現状分析と、あるべき姿を特定し
そこへ到るための課題を見出す必要があります。
これが、すべての出発点です。
現状分析と課題の特定の手法は、以下を参考にしてください。
![ワークフロー作成例](https://smilekao.com/wp-content/uploads/2020/10/ワークフロー作成例.png)
上の例では、
上段が、現在のワークフロー
下段が、目指すべきワークフローです。
こうして図にしておくと、理解しやすく、便利でしょう。
ただし、図だけでは、解釈はひとによって異なりますので、
文字にして特定をしておく必要があります。
この後、以下のような
ニーズ整理表を作成し、課題を明確にしましょう。
![ニーズ整理表](https://smilekao.com/wp-content/uploads/2021/04/ニーズ整理表-759x1024.png)
「経営レベル」「業務レベル」「業務の仕組みレベル」の3階層)に分けて、
整理する事がポイントです。
ニーズ整理表のエクセルファイルをお渡しします。
興味がある方は、以下よりお問合せください。
方針
![](http://wordpress.smilekao.com/wp-content/uploads/2021/04/unnamed-file-7.png)
システム化方針は、「プロジェクト憲章」とも呼ばれ、
社内で議論が錯綜した時などに、必ず立ち返るもので
大変、重要です。
図のシステム化方針のエクセルファイルをお渡しします。
興味がある方は、以下よりお問合せください。
背景
なぜこれをやることになったか?
どんな問題が、誰にどのように影響しているのか?
を、具体的に記載しておきます。
システム化のテーマ
下の目的を一言で表すような言葉で設定します。
プロジェクトの合言葉のように使います。
目的
「経営レベル」「業務レベル」「業務の仕組みレベル」の3階層)に分けて、
記載しておきましょう。
期待成果
これも、
「経営レベル」「業務レベル」「業務の仕組みレベル」の3階層)に分けて、
記載しておきましょう。
制約条件
「期間」「費用」「リソース(体制、設備、機器など)「改善条件」「その他」の5項目について、記載します。
「改善条件」では、
「システムだけの見直しをするのか」
「業務プロセスまで含めた見直しをするのか」
「組織・体制や制度・ルールまで踏み込んだ見直しをするのか」
を確認します。
プロジェクト範囲
どのプロセス、どの地域が対象で、どれが対象外か?
このプロセスの開始と終了地点は?
これらを明確に決めておきます。
プロジェクトの途中で、対象外の事柄が入って来やすいですが、
その時は、それを排除する基準を事前に決めておきます。
責任範囲
誰がこのプロジェクトの成否を決めるのか?
数値目標
目標の達成度を計る数値項目は何で、
成功数値はいくらか?
予算目標は?
いつまでに?
こうしたことを事前に決めておきます。
プロジェクトチーム
参加者を事前に決めておきます。
計画
計画では、以下の5項目を決定します。
①機能の特定
②実現方法
③中間目標
④成果物
⑤運営ルール
要件定義
ここまで決まれば、
あとは、粛々と決めていくだけです。
主な内容は、
以下の通りです
①業務フロー
②業務要件
③機能要件
④機能配置
⑤外部連携
⑥データ構造
⑦画面構成
⑧非機能要件
⑨必要ライセンス
⑩法律確認(必要時)
この具体的な内容は、
改めて、記載したいと思います。