#1 開発工程、何をしているのか(要件定義)

投稿者: | 2021年3月9日

業務システム開発には、古くから言われている開発工程というものがあります。この工程の考え方は、おそらくどんな開発現場でも基本的な考え方になるので、仮にアジャイル開発でやっているという現場に入ることになったとしても役に立つはずです。

また、SIerに勤めるプログラマ、SEは、おおむね上流フェーズの経験を獲得していくことが往々にして求められてきますから新卒でそういった企業に勤める予定がある人には参考になるかもしれません。

開発フェーズごとに考える

システム開発のプロジェクトで、モノが出来上がるまでにはどのようなフェーズがあるか振り返ってみましょう。おおむね下記のようなステップがあります。

  • 要件定義
  • 基本設計、外部設計
  • 詳細設計、内部設計、開発
  • 単体テスト
  • 結合テスト
  • 総合テスト
  • 運用

ちなみに、どこそこの会社ではそれは要件定義ではなく、要求定義(=もっと上流)に入る、というところもあれば、逆に基本設計に入る、など前後1フェーズずれることはあります。また、実務でも「スケジュール上〇〇のフェーズは終了したが、一部は後続フェーズでも継続する」ということはよくありますし、逆に先のフェーズに使えそうなものをすでに作り始めているということもあります。

あくまで目安です。ここに書いた以外の成果物も考えられるものはいくらでもあります。とはいえ、なんでも作ればいいってものではないので優先順位的に必要な情報の整理をやらないといけません。

要件定義

要件定義のフェーズの目的は、定義対象のシステムや、システムの外側(別システムや、人間)が今どのような状況にあるのか(Asis)と、課題は何か、課題を解決するためにこれからどうするのか(Tobe)をまとめることです。

ここは「発注側」がしっかりやらねばならない範囲ですので、私たちのようなベンダ側に属する人らはそれを「受領する側」です。とはいえ、場合によっては発注側と一緒に作っていくこともありますので多少の知識は必要です。

主な成果物には、機能要件では下記が主要なものになってきます。いずれも、AsisとTobeの両方を作っていきましょう。

  • 業務フロー
  • 業務シナリオ
  • システム間の連携図
  • 運用カレンダー、タイムスケジュール
  • 画面イメージ(簡単なもの)
  • 課題一覧、対応方針

対して非機能要件では、下記のような要件が主です。

  • セキュリティ
  • 性能
  • 可用性

業務フロー、業務シナリオ

超重要

相互補完的なので1つにまとめてしまいますが、まずこれが一番重要なのではないかと思います。これがなければ、非機能要件にある要素の妥当性も評価できません。例えばセキュリティでいえば、閉ざされた社内システムだとしても、製品出荷時の品目コードと数量しか書かれていない情報・機能と、人事評価に関る情報が乗った機能とでは事情が違います。

1日に全社的に誰もが使う機能と、特定の部署が月に数回検索する程度ではレスポンスとして求められる基準も異なるでしょう。(後者は、少々検索が重くても許容されやすい)

四半期に1度しか使わなくても、決算にかかわる重要機能である場合、障害回復の要求は高くなりますが、機能が使えなくてもシステム外でどうにか運用できるものは障害回復の要求も低くなります。

もちろん大きな組織ともなれば、「誰それが承認するというプロセスを踏んでいるか」などを見られるので、監査のために持っているのではないかと思います。監査の観点から重要度が低いところは省略されていて、開発するうえで抜け漏れがあってそのままは使えない、なんてことがあるかもしれませんが…。

具体例

必要なことは、誰が、いつ・どんな条件(何をきっかけに)に、誰と、どんな情報をやり取りするかという点です。

ipaのページにサンプルがありますのでこちらが参考になります。このフローは「とある業務の一部」ですから、もっと大局的に見た視点が必要です。より粒度が大局的な業務フローやその説明がシナリオとして必要です。(=業務概要図)

IPAのサンプルダウンロードページ
出典:SEC IPAの超上流から攻めるIT化の事例集より

人によってはL1、L2、L3などというレイヤーが必要だ、という言い方をしている人がいますが、内容を見る限りそれに相当するものが上記URLにサンプルがアップされています。とてもいい教材です。

システム間の連携図

関係者を明らかにするためにも必要

システムとシステムが連携する場合には、担当している会社、人物が違うことがありますし、データのやり取りが必要になれば打ち合わせが必要です。システム間で連携がある場合には、どのようなデータをどのタイミングでやりとりしているかをはっきりさせておきましょう。

例えばECサイトの場合ですが、「取引基盤・プラットフォーム」としての機能を持っています。店舗もなどほかの売上を持っている場合にはこの後ろに売上や請求といった基幹システムが構えていることもあります。(ECサイトのみで売上・請求の管理できる場合にはないかもしれません。)

そうなれば、あるタイミングでの受注登録、売上登録といったシステム連携が発生します。

ほかにも頻繁に製品がリリースされる場合には、ワークフローなどでリリース承認済のものをECサイトに自動的に載せる、といったことも考えられます。そのようなシステム間連携については明らかにしておく必要がありそうです。

運用カレンダー、タイムスケジュール

業務の流れに着目する業務フローと業務シナリオに対して、時間軸の流れに着目したものが運用カレンダーとタイムスケジュールです。日報、月報、四半期などの集計要素がある場合まとめておくべきです。

また日付によって業務を止められないタイミングがあれば関係者で共有しておくべきです。

画面イメージ(簡単なもの)

いうまでもありませんが、機能の概要がわかる程度のものが必要です。Asisでの画面、帳票はベンダが機能分析する際に一番役立つ資料です。

課題一覧、対応方針

現状の課題とその対応策をまとめたものです。業務フロー(Asis)から現状を分析し、課題点と対応策を鑑みて、業務フロー(Tobe)と画面イメージ(機能設計)に反映させます。

例えば「受付システム」の例で課題として考えられるのは、紙のウェイティングリストの運用では待っているお客さんがその場から離れられない点といえます。そのため、一度来店して受け付けるとスマホ等でその状況を確認できる、という対応策を導いています。

変えなくてもよい、現行と同等にしたほうが良いことがあります。なぜなら、意味もなく変えれば混乱が生じますし、むしろサービスの質が劣化することすらあり得ます。

例えば上記の受付システムでは、店舗外から受付られないようにと考えています。これは、いたずら登録によって運用が混乱しないようにという考慮です。(もちろんこの点の課題がクリアできるのであればTobeに加えます)

セキュリティ

データをどのように守るかについて書きます。考え方としては下記のような点があります。これらを達成するためにより具体的にブレイクダウンが必要です。

  • 権限のある人に必要なデータだけを見せること
  • 何らかのインシデントが発生した場合に検知できること
  • 検知した場合に影響範囲を特定できること

例えば機能面からはロール制御などが必要ということになりますし、DBにアクセスする保守作業員に対する申請・承認などの運用フローについての取り決めということもあるでしょうし、データベースに保持する

サンプルは…?

こういうものは「調達」をする法人のサイトに要件書が転がっていたりします。書き出すときの参考になるでしょう。

厚生労働省のサイト内をセキュリティ要件で検索した結果

性能

「〇〇な状況下で××な性能を出すこと」をまとめます。

例えば請求書を自動作成するサブシステムの開発時には下記のような性能仕様がありました。

  • 売上データは基幹システムより午前6時以降連携する。
  • 業務開始は9時であるので、9時時点には請求書作成が必要である。
  • 連携データの不備+修正と、リトライを考慮して、1回あたり1時間で作成を完了すること。

有象無象な検索処理の性能は一律○○秒が目安でいいかもしれません。あまり高い水準を書きすぎると、結局ベンダからの「調整のお願い」が来ますので手間ばっかりかかりますよ。

前提となるユーザ数や業務量の定義も必要です。(例えば売り上げのデータはどの程度なのか、など)開発ベンダはここにある情報をもとに「性能測定」をしています。(後で遅いとか重いとか言わないなら構わんよ)

可用性

先に出た運用スケジュールもここでは役に立つでしょう。システムには止まっていてもいい時間帯と動いていなければならない時間帯があります。それらを踏まえてメンテナンスの時間帯も計画していきます。

例えばECサイトの場合にはほぼ100%が求められると思いますし、社内システムであれば夜11時以降はシステムが止まるといっても許容されることが多いと思います。

ディスク、ネットワーク、サーバなどの障害が発生したときの備えや、データが失われないようにバックアップの仕方も定義します。

基本設計、外部設計

このフェーズの目的の1つ目は要件定義フェーズの深堀のようなもので、システムでは何をするのか、システム外(=人間や他システムなど)が何をするのかという「線引き」をすること。2つ目はシステム全体を支えるテーブル定義、ER図、DFDなどを設計し、後続の個別機能の設計や開発に備えることです。

次回

基本設計編を書いていきます。

おまけ

サンプルを探しにいくと調達案件の仕様書などは生きたサンプルですから、参考になります。その過程の中でこんなものがありました。面白かったのでURLを張っておきます。

情報システムに係る政府調達の在り方について