Allied ArchitectsAllied ArchitectsEngineer Blog

サービス開発における要件定義とか

2017/11/6 未分類

入社以来、書かねばと思いつつ、実に2年10ヶ月もブログを書くことから逃げ続けたimai78でございます。

(プライベートのブログは既に4年以上書いてません><

今回は、みんながエッジの効いた技術の話題を書いているので、ちょっと変えて「サービス開発における要件定義」について書いてみます。

前段

サービス開発であっても、要件定義という工程は必要です。

その際、ワタクシメが大事にしている観点を書いておきます。

FURPS(Functionality, Usability, Reliability, Performance, Supportability)

QCD(Quality, Cost, Delivery)

有名なこの2つは、有名なだけあって非常に有効な観点になってくれます。

改めて書くまでもないですが FURPS は以下の略で、要件定義における機能要件と非機能要件を測定するためのモデルです。

  • Functionality:機能性
  • Usability:使いやすさ
  • Reliability:信頼性
  • Performance:性能
  • Supportability;保守性

そして、QCD は以下を略したものです。

  • Quality:品質
  • Cost:費用
  • Delivery:納期

前者はソフトウェア開発における品質モデル、後者は生産技術の基本的なフレームワークで、弊社のような SIer ではない IT 企業にとっても非常に有用です。

FURPSについて

僕の経験則になってしまいますが、ユーザーから要望を聞く場合、その殆どが Usability についてのものでした。専門家たる我々は、この Usability に対する要望から必要な機能を考え、機能を支えるべき信頼性、性能、保守性を導き出します。

Web サービスを開発している企業にとって開発のスピード感は特に重要なものですが、それ以上に開発者と開発以外を担うメンバーとが足並みを揃えて同じ市場に挑む事がとても大切です。

その中において、市場や営業の要望をエンジニアが正しく理解する事ができるという事は、齟齬から発生する手戻りや不要な摩擦も減らせる以上の価値を生み出せるポイントと言えます。

QCD について

品質をどのように解釈すべきかという話しになってしまいますが、ここは素直に FURPS の完成度をイメージし、費用はその品質を実現する為に必要な投資額を、納期はそのまま「いつ完成するか」を考えるものだと理解しましょう。

この QCD という指標は、エンジニア以外とのコミュニケーションにおいて非常に有用なものとなります。

品質を良くしようとすれば費用か納期を犠牲にせざるえず、費用を抑えようとすれば品質か納期が犠牲に、納期を早めようとするなら品質を犠牲にするかより多くの費用の投下が必要になる、と極めて分かりやすい作用が発生するからです。

まとめ

エンジニアにとって、自分たちが開発していくシステム、ソフトウェアに対する知識は非常に膨大で深いため、時にその知識に埋没してしまう事もあるのですが、こと弊社ではそんな中でもエンジニアリングを担うメンバーもそうでないメンバーも闊達なコミュニケーションを通じてサービスを少しでも良くしていくよう心がけたいと考えています。

そんな弊社に興味をお持ち下さった方、ぜひご連絡下さい!!

ページTOPへ