要件定義支援サービス

「情報システム化を依頼したいが、どのように頼んでいいかわからない」「過去に情報システム化した時に、細かいところがうまく伝わらず、失敗した」・・・といった声がよく聞かれます。

これは、要件定義をせずに「ｘｘを自動化したい」という漠然とした思いを具現化することが難しいことと、そのまま依頼した場合に「ｘｘを自動化すればいいのだろう」という理解でシステム化（自動化）したことが原因です。

これは、客観的に現状の課題を表現することが難しく、「ｘｘを自動化したい」という漠然とした手段（機能）の表現になりがちなことに加え、そのまま情報システム開発を依頼した場合に背景や目的がわからないことから、「ｘｘを自動化すればいいのだろう」という理解でシステム化（自動化）せざるを得ないことで、「思ったのと違った」という結果になりがちです。

よくある例として、「見積から請求書へ自動で転記したい」というニーズを考えます。

課題を単なる「転記の自動化」と捉えると、複数ある見積もりの１つが正式に請求に回るケースや、爾後値引き要請がある場合などに、個別に手作業で対応する必要が生じ、本末転倒です。納品書が必要な場合は、更にややこしいことになってしまいます。

つまり、情報システム化をするのであれば、その企業固有の事情である「爾後値引き要請に応じる場合が多く、請求直前に値引き額を入れて調整している」「前月分の調整額を反映させる必要がある」といったケースを整理した上で、「見積書・納品書・請求書」の作成までを情報システム化の対象とする必要があります。

このように、表層的な課題認識ではなく、本来「あるべき姿」を定義し、そこからの乖離をいかにして埋めるかという発想で現状の課題を整理し、関連する前後の業務も含めて対象（DX的な視点）でするほうが、全体の生産性が向上ます。

ここまでやって初めて、どのような要素技術を使って課題を解決するかが検討できるようになります。情報システムは目的ではなく手段なので、要件定義も「初めに自動化ありき」では、うまく行かないのです。

参考：経済産業省資料 ～ 「理想と現状の差分は何か」※外部ページを開きます

それでは、要件定義は必ず要るかといえば、ごく小規模であれば不要といえます。

極端な話、元々10%だった消費税が15%になったから改修する、といった場合に、いちいち要件をまとめるまでもないでしょう。

その代わり、今消費税を計算しているしくみを作る時点で、「あとで消費税が変わった時に、設定の変更だけで対応できるようにする」という要件を含めておきます。

実際に、事前の要件定義をせずに作ったシステムで、消費税の計算をする各所において個別に税率を設定しているため、あちこち修正したものの漏れが生じたケースが散見されました。

建設業のように、見積もりと工事後の実態が異なるのが常態化しているようなケースでは、そのような「業界ルール」があることを開発者に伝えないと、多くの場合「仕様の漏れ」が生じます。

ちょっとでも例外の自覚があるようであれば、箇条書きレベルであっても、要件としてまとめた方が確実です。

前述の例で、見積書～請求書までを「転記」で実現しようとすると、例外のオンパレードになり、構造が複雑になります。

データベースの発想があれば、同一情報がそのまま見積書～納品書～請求書のように表現しつつ、爾後の値引き等を別管理することで表現した方が、シンプルな構造につながることに気づきます。

これは、開発コストの削減だけでなく、爾後機能拡張する際にも、短時間・低コストでできるようになります。

情報システム化した際に、根本的な原因をクリアできていないと、他の課題が噴出しかねません。

例えば、先の「転記を自動化する」だけであれば、転記してはいけないものまで転記されてしまったり、転記漏れがあっても検出せずに次の処理に移ってしまう、ということがよく起こります。

「転記ミスが多い」「手間と時間がかかりすぎる」といった表層的な課題から、「転記せずに使い回せるようにする」「表記方法を標準化する」といった具合に、根本的な課題にたどり着ければ、情報システム化対象を必要最小限に抑えられます。

人が作業する前提であれば、「過去の膨大な見積もり情報から、類似情報を参考にして、新たな見積もりを作成する」というのは、効果はありそうでも、作業負荷がかかりすぎて現実的とは言えません。

ところが、データベース（DB）の技術を使えば、数百万件の取引データから、類似案件を抽出することは、秒のオーダーで終わります。

メディアなどの情報に頼ると、「今は○○○の時代」的な表現が多く、最新技術が魔法のように見えてしまいがちです。

しかし、冷静に考えれば、最新技術は使った人が限定され、長期間使用した場合の課題も誰も経験していません。

このため、大抵の「（今の時代だった）○○○」の多くは、3年も経たないうちに、忘れ去られてしまいます。

長期間安定して業務に適用するのであれば、多くの実績がある、確立された技術要素を使った方が確実です。

辞書的な意味としては、発注者（利用者）の要望を開発者に正確に伝えるため、明確化すること。

多くの場合、要件定義書の形で、文書化される。

利用者（＝非開発側）の視点で、情報システムの仕様を表現した設計書。

多くの場合、画面や帳票など、利用者の目に直接触れる要素を中心に、機能等が表現される。

同種のものが複数ある場合に、元になるもの。台帳と同義。

情報システムの世界では、同種のデータはあちこちに分散させず、一カ所にまとめるため、多くの場合データベースと同義となる。

本来は、商取引などの記録を指し、情報システムでは伝票や見積もりなど日々発生する、処理すべき対象データを指す。

周囲の状況に合わせ、対象物が期待する機能を維持できるようにする行為。

情報システムでは、定期的な機能の見直しや、これに伴う機能追加、隠れた不具合への対応などの他、使い方に関するアドバイスなどのサービスが含まれる。

参考：日本産業規格の簡易閲覧　ISO/IEC/IEEE 14764:2022※外部ページを開きます

とりあえず、漠然とした状態で構いません。

経験豊富なスタッフが、担当者からのヒアリングを元に仮説を立て、課題を客観的に棚卸しします。

証憑類・現環境などの調査や、関係者へのヒアリングなどを通じて、顕在化している課題だけでない、潜在的な課題を発掘し、それらを含めた真の原因を探ります。

費用対効果の評価のため、実現すべき対象範囲案を複数提示します。

ここから対象範囲を決めていただき、対応期間・見積額（いずれも、当社が開発する場合、他社が開発する場合は参考情報）などが決まります。

とかく、デザインに振れがちなWebページ作りですが、多くのケースで本来の目的を見失っています。

例えば、飲食店なのに場所が掲載されていなかったり、宿泊業なのに予約は電話のみであったり、特徴あるサービスなのに関連キーワードがゼロであったり、文言を変更するのにいちいち業者を頼まなくてはいけなかったり・・・

目的が集客であれば、ターゲットとする顧客に対して、何をどのようにアピールするか、法人か個人か、顧客と接点を持つまでの作戦をどうするか・・・といったことを、Webページという媒体で表現するために、機能／非機能要件をまとめることで、こうしたちぐはぐなWebページを回避できます。

要件定義のコンサルティングのみを行うのではなく、半数以上のケースで当社自身が開発も行っています。

このため、よくある「実現不可能な要件定義書」は、提案しません。

大小様々なシステム開発を通じて行った要件定義のノウハウが、延べで1800件分以上蓄積されています。

このため、業種・規模などに依らず、様々な経験を有しており、同じ業務でも背景となるビジネスが異なれば、最適解も異なる前提で接することができます。

これまでの例では、短いものだと1週間、長くても4ヶ月で一定の結論（要件定義書）に到達しています。

お急ぎの場合、期間優先で要件を定義します。

今の業務手順の延長ではなく、目的に最適化してゼロベースで見直しを図ります。

どのような改善方針がとれるか、期間や予算はどの程度になりそうか、といった内容について、無料相談を行っています。匿名でも構いません。

今使っているExcelの様式や伝票類などがあれば、TV会議で共有しながら、原因となりそうな箇所のあたりをつけたり、改善の方向性についての助言をすることができます。

要件定義は、当事者自身のビジネスを、情報システム化を前提に表現したものです。

このため、第三者が代行すると、教科書的なものとなりがちで、当事者固有の事情を反映することが難しいため、共同作業が前提となります。

要件定義書には、ひな形（決まった様式）はありません。

各社各様に抱えている課題も異なれば、実現する方向も異なります。

要件定義書は、実態に合わせて、必要な内容を織り込めば、形式は問われません。

要件を定義しないと、表面的な機能の実装とならざるを得ず、それによってどんな課題を解決するかといった目的が共有されません。

ある程度複雑なしくみを作る場合、機能の列挙だけで依頼すると、効果や拡張性、使い勝手等の点で、想定と異なる可能性が増大します。