スピードある開発をするために意識していること

開発を行う上で絶対に避けて通れない工程の１つに「要件定義」があります。

前置きとして、似たものに「要求定義」がありますが、

• 要求定義は「〜したい」と利用する側が希望する、ビジネスで何が必要なのかなどを記載したもの
• 要件定義は「〜が必要」としてシステムの仕様書、システムが何をしなければならないかなどを記載したもの

で、意味が大きく異なります。要求定義について書いているブログはこちら。

今回は「要件定義」。この要件定義に失敗してしまうと、システム開発すべてに支障をきたし、最悪の場合、プロジェクトを失敗させてしまいます。

失敗の原因には、

• 仕様変更がやたらと多い
• サービスたちあげたけど運用がまわらない

など、最初にサービス全体のイメージが固められないまま、システム開発を進めてしまっていることがあります。

当然イメージが固まりきっていないので、システムを開発して具体的に形になってくると、それならこうした方がいいよねとか、この機能がないと運用がまわりません、など要求が後工程になればなるほどあふれてくる…こんなことはよくある話です。

そのため、いかに運用のオペレーションを含めて具体的にまとめておくことが出来るかが開発が成功できるかのポイントになってきます。
そうならないために、下記のようなことに気を付けてやっています。

気をつけていることその１：要求内容の把握

システム開発で一番問題になりやすいのが、出来上がったシステムが要望どおりかどうかということです。要望どおりのシステムを設計するためには、まず要求を理解することが重要。常にそのシステムを利用する側とコミュニケーションを取り、要望を満たしているかを確認しながら行うことが大事です。

弊社では最近は、AdobeXDを用いてモック（実物とそっくりに似せて作られた試作品のこと）を作成して、各関係者にインプットしていくやり方が主流になってきています。これにより基本的には、後工程になっても、そのモックをベースに情報の共有を行っていくことで、各関係者に同じ粒度で情報を共有を行うことができます。

AdobeXDについて書いているブログはこちら。

気をつけていることその２：全体像の把握

運用を含めて「誰が」「いつ」「どんなこと」が出来ないといけないのか一連のサービスの流れの中で、抜け漏れがないか確認していく。ここで抜け漏れがあると仕様変更・リスケのリスクが増えてしまいます。

特に運用要件は、後回しになることが多いですが、基本となる業務フローは、要件定義の段階で考慮されているか確認するようにしています。

気をつけていることその３：最小限の構成の把握

要求の中には下記のように分類することが出来ると思います。

1. 絶対に必要な機能
2. あったら便利な機能
3. なくてもなんとかなる機能

初期の開発では、「1. 絶対に必要な機能」はもちろん主要な機能として開発に組み込んでいきます。「3. なくてもなんとかなる機能」は初期機能としては、開発する必要はないと思います。

「2. あったら便利な機能」が悩ましいところですが、サービスインして実際に運用が始まると、作ったけど使われない機能がでてくることもあります。こういうのは大抵「あったらよさそうな機能」を作ったことによって発生することが多いです。

最小の構成で費用と時間を最小に抑えて、素早くサービスインできることがベストです。

あれもこれもと多様な機能を盛り込んでしまい、サービスインが遅れることは、避ける必要があります。ここは、関係各所の人達とコミュニケーションをとり、合意形成をして、アウトプットを残しておくことが重要です。

気をつけていることその４：課題・未決事項の洗い出し

当然、要件がふわっとしていたり、設計していくうえで決めて欲しいこと、確認しないといけない内容等出てきます。これらを課題・未決事項として洗い出し、整理することも重要になってきます。

プロジェクトが成功するためには、上流工程でやりたいことが明確になっていて、ちゃんと関係各所とコミュニケーションをとり、合意形成がなされていることが重要です。

要求する側も開発に任せ状態になることもありますが、お互いに協力して、取り組んでいく環境ができればよりよい開発ができるようになると思います。

いかに早く、よりよいサービスを提供できるか共通意識をもって開発をしていくように心がけていきたいですね。