はじめに

入社してまもなく半年のオーケーアイです。この度弊社のCEOから「テストツールを開発せよ！」との指令を拝命し、開発が完了しましたので自身の頭の整理も兼ね、開発プロセスを振り返ります。いまだ、未熟なひよっこがさまざまな資料を調べに調べて書いていますので、そのつもりでご覧いただければと思います。

企画概要

弊社が開発・保守をしています、とあるアプリケーションでも仕様変更やバグ修正を行った際にエンドツーエンドのテストを実施しますが、さまざまな条件をテストするため諸条件を設定できるツールを使用しています。今回の開発はそのテストツールの課題を改善するというものです。

要件定義

さて、テストツールを作るということはわかりましたが、どのようなものを作ればよいのでしょうか？何が課題でシステムを用いてどのように課題を解決すればよいのでしょうか？

それを具体化して文書化するのが要件定義の工程です。要件とは必要な条件であり、要件を定めるにはユーザーが求めるものを特定する必要があります。（要求定義）さらにシステムを開発するには、対象の業務において実現するシステムと手作業の範囲を定めることも必要です。この一連の工程を要件定義といい、ステークホルダー間で合意し形にしたものが要件定義書となります。　

とある調査でもシステム化の失敗の過半数以上は要件定義の失敗であると述べられていました。要件定義の難しさはそもそも、イメージを具体化することやコミュニケーションの難しさからきていることは容易に想像できます。ユーザーは、「なんとなく不便だな」と感じていることを開発側に具体化して説明しなければなりませんし、普段、お互いに当たり前で口にする必要がないと思っていることも、ユーザーと開発側のバックグラウンドが異なれば異なるほど意思疎通のズレにつながります。

今回の開発では、このあたりのハードルはかなり低いものでした。普段から同じ仕事をしていてコミュニケーションを取りやすいメンバーに気軽にお話しを聞くことができましたし、私自身がユーザーとして現行ツールの課題を感じていたからです。

要件定義書には決まった様式はないようですが、一般的に必要だとされている項目を列挙します。

• 目的（システムで実現したいこと/課題/背景など）
• 業務要件（システム化対象の業務の目的/手順：業務フロー/システム化の範囲など）←現行業務を見える化し、システムが果たす部分を明確化する
• 機能要件（システムが持つべき機能）←業務要件を満たすことのできる機能を定める
• 非機能要件（セキュリティ/ハードウェア/運用など）←機能要件以外のもろもろ必要な要件
• 開発計画

以下、今回作成した要件定義書です。

【目的・業務要件・システム化範囲を示したもの】

【業務要件を満たす機能要件一覧】

ここまで要件定義について述べさせていただきましたが、実は開発をずいぶん進めてからさぼってんじゃねーよとお叱りを受け文書化に取り組んだ次第です。今回は社内のみで使用するシステムであり、課題が明確で求められる機能が特定しやすく、なおかつすぐにコミュニケーションがとれる超めぐまれた環境だったので手戻りなく進めてこれましたが、このような前提条件はそうそうなく、システム化において事前の計画や意思疎通はとても重要だということが理解できました。

テストツールの記事についてはまとまり次第アップしていこうと思います。