こんにちは。SEタケです。
システム開発を発注したいけど、ちゃんと役立つシステムにしてもらえるのか、不安ではありませんか。システム開発を打診してみても、見積額も様々だったり、いったいどういうところに気を付けて発注すればいいんでしょうね。。
この記事は、クラウドで提供しているシステムやパッケージ製品を検討したものの、目的に合ったものがなく、独自のシステムを開発する必要がある方を想定しています。
発注にあたり、システムに必要な機能については、ある程度整理されているのではと思います。
ですが、システムの品質は、機能だけではありません。機能は満たしているけど、レスポンスが悪かったり、情報漏洩のリスクがあったり、頻繁に止まってリカバリが必要だったり、そういうことがあると困りますよね。しっかり使いやすくて安心なシステムであってほしいはずです。
そういった、機能以外の要件のことを非機能要件といいます。システムの導入を成功させるためには、機能要件と同じように非機能要件も押させえておく必要があるのですが・・多くのシステム発注時に、非機能要件は意識されないことが多いです。
もちろん非機能要件についてはベンダー側も意識していますので、殆どの場合、事前に確認されます。ですが、合意が曖昧なまま開発が進んでしまってトラブルになることも結構あります。見えない部分ですので、お互いに「このくらいは普通かな」「確認するまでもないか」と考えてしまい、認識にずれが生じてしまうためです。
非機能要件を満たすにもコストはかかりますが、どのくらい満たしていればいいか判断が難しいかもしれません。あれもこれもと、あまり高い要求をしても高額になりますので、限られたコストで最低限どういうところを押さえておく必要があるのか、どうしてもこれくらいは欲しい、というポイントを整理しておかれる方がいいかと思います。
ということで今回は、非機能要件について、IPA（独立行政法人情報処理推進機構）が提唱する「非機能要件の６大項目」を元に少し説明します。IPAは情報処理技術者試験なども運営している組織ですので、信頼できる指標です。
これらの指標をもとに、必要なものと必要でないものを整理しておかれると、よりスムーズにシステム導入ができるかと思います。
可用性
使いたいときに使えるか、という視点です。
システムは常に動けるわけではありません。定期的なメンテナンスが必要な場合もありますし、普段は問題なく動いていても、一時的に想定より多くのアクセスがあったり、予期しないトラブルによって止まることもあります。
可用性を高めるには、止まりにくいプログラムにする以外にも、余裕のあるシステム構成にしたり、予備の機器を用意したり、監視と自動復旧の仕組みを入れるなど、様々な方法があります。
可用性の要件としては、下記のような点に注目して整理してみましょう。
- ２４時間稼働している必要があるのか、営業時間だけでいいのか。
- 月１～２回くらいはちょっと調子が悪くなっても、システムを再起動して数分で回復するならOKなのか、稼働中は絶対止まってはいけないのか。
- 災害時などにどのくらい耐えられるか、システムが壊れた時にすぐ復旧できるのか、データのバックアップから復元はできるか。
性能/拡張性
レスポンスが早いかどうか、利用者やデータが増えて遅くなってきたときに拡張しやすいか、という視点です。
ストレスを感じないレスポンスは、３秒以内といわれています。頻繁に使用する機能はもっと早いほうが効率的ですし、めったに使用しない画面は少し遅くても問題ないかもしれません。
普段は早くても、利用が多い時間帯などに遅くなることはありますし、特定の機能だけ遅い場合もありますので、基準を明確にしておくといいでしょう。
また、レスポンスは同時アクセス数やデータ量によって変わってきます。利用者やデータが増えると機器やネットワークなどを拡張したりする必要があるのですが、そういうことが容易にできるかどうか（拡張性）も、ご確認ください。
運用/保守性
システムを使っていくにあたり、人によるメンテナンスや障害時の対応は必要ですので、これらがしやすいシステムかどうかも重要です。
例えば下記のような点です。
- 定期的なメンテナンスの方法や障害時の対応について、わかりやすいマニュアルを用意してもらえるかどうか。
- メンテンナンスしやすく、手間がかからないようになっているか。
- 障害発生時にすぐ気づけるよう、監視の仕組みなどがあるかどうか。
システムは導入して終わりではありません。運用コストがなるべくかからないかどうかも大事なポイントですね。
移行性
現在使用しているシステムがある場合は、新しいシステムにデータや運用を移行する必要があります。移行しやすいかどうか、というのも大事な要点になります。
新しいシステムを導入したはいいけど、システムを移行する段階になって意外と手間取ることもあります。現行のシステムとデータ構造の違いが大きかったり、システム構成の違いで業務の継続と移行作業の両立が難しいなどのケースもあります。
移行に必要な期間、移行の方法（段階的に移行するなど）、移行が必要な資産やデータ量について、予め要件を整理しておくとスムーズに移行できます。
セキュリティ
不注意や悪意による、情報漏洩やデータ消失など、セキュリティ事故を防ぐための要件です。
情報漏洩は信用問題に直結しますし、場合によっては刑事罰を受けることもあります。また、データ消失もビジネスを続けることができなくなってしまう場合がありますので、必ず考えておく必要があります。
セキュリティ事故は、内部の利用者によるものと、外部からの不正アクセスによるものがあります。
内部の利用者に対しては、ユーザの役割ごとに機能や情報への利用制限を設けるなどの方法をとります。また、ユーザがいつどのデータにアクセスしたか、利用ログを取ることもあります。あまり厳密にしすぎても、必要な情報にアクセスできず業務が滞ってしまうこともありますので、バランスが難しいところです。
外部からの不正アクセスに対しては、二段階認証、プログラムの方式、ネットワーク構成、不正の追跡・監視・検知の仕組みなど、さまざまな手段で対応します。
システム環境/エコロジー
システムの設置環境や消費エネルギー量などに関する要求です。
コンピュータは場所を取りますし、熱や音も発生させます。システム導入によって仕事場が狭くなったり、音がうるさかったり、部屋が暑くなるかもしれません。また、重いコンピュータが地震の時に転倒するようだと危険です。
その他、消費電力を抑えるなどエコロジーにも配慮したいところですね。
まとめ
非機能要件は、システム導入時の大事な要件ですが、見過ごされがちです。そのため、非機能要件の合意不足がトラブルになることも多いです。
とはいえ、非機能要件を纏めるのは大変ですので、そもそもあまり考慮する必要のない方法をとるというのもお勧めです。
例えば、システム環境にクラウドプラットフォーム（AWS、Azure、GCP、など）を利用するという方法があります。クラウドプラットフォームは、セキュリティ対策は施されていますし、拡張性もあり、クラウドですのでシステム環境の考慮も不要です。
また、ローコード開発ツールを利用するという方法もあります。こちらはクラウドプラットフォームと同様のメリットに加え、可用性や運用/保守性の面からも、ある程度保証されています。
結論としては、システム開発を行う場合、まずはローコード開発ツールを検討されることをお勧めします。必要な機能がローコード開発ツールで実現できない場合は、クラウドプラットフォームを検討、最後にそれ以外の方法、という順番で検討されてはどうでしょうか。
ローコード開発ツールが気になった方は、下記の記事も参考になるかと思います。
ローコード開発はkintoneがおすすめ、kintoneの特徴
非機能要件も考慮して、システム導入がトラブルなく進められることを願っています。
以上、最後までお読みいただきありがとうございました。
コメント