SIOS Applicationsの過去未来
はじめに
第2回では、アジャイル開発にて「ProjectKeeper Professional」を開発していく過程を紹介しました。ここまで終われば、製品出荷のフローに乗せて出荷準備をし、市場に製品を出すということになりますが、各社とも製品出荷を行うには「品質保証」の仕組みを通すのが一般的になってきていると思います。
「品質保証」の仕組みを通すことは、パッケージ製品に限らず、受託開発で開発した納品物も含まれますので、受託開発を行っている方も参考になると思います。
一般的に品質保証と聞いて、思い浮かべるのはなんでしょうか？「テスト」「レビューの仕組み」と言ったところでしょうか。製品を開発している私たちにとって、品質保証とは、当社の製品を購入していただく顧客に対して、製品の品質に保証を与えるのに必要な証拠を残す活動すべてを指しています。したがって、要求仕様を残す、要求にしたがったコードをレビューする、テストケースを作成する、テストを実行した結果を残す、テスト結果をレビューする、などの活動すべてを指すことになります。
一般的に、ソフトウエア開発を行うときには、以下のような活動を指します。
1．要求仕様レビュー
2．コードレビュー
3．変更管理
4．構成管理
5．リリース管理
6．ソフトウエアテスト
上記の活動の意味・説明は、参考文献、参考Webサイトなどたくさんあるので、割愛させていただきます。今回は、上記の項目を、当社、最初のパッケージ開発製品で営業支援システムの「SIOS Applications Sales Force Automation+（以下、SFA＋）」でどのように適用していったか、また開発当初から現在までどのように変わっていったかを見ていきたいと思います。そして、製品を世に出すということへの取り組みの変化を実感していただきたいと思います。
要求仕様レビュー
SFA＋はパッケージ製品ですので、ユーザーの要求があらかじめ存在しているわけではなく、見えないユーザー要求に対して「こうであろう」的な予測をしなければいけません。そういう意味では、パッケージ製品における要求仕様の作成は受託開発などの開発と比べると難しい部分があるかもしれません。
パイロットユーザーを選定して、製品を試用してもらい、要求を吸い上げるという方法もありますが、最初に開発したSFA＋は、パイロットユーザーもいない状況でした。そのため、受託開発で培ってきたノウハウと、自社の営業部門へのヒアリングを行うことでシステム要求をまとめました。
SFA＋は、営業業務を効率化するためのシステムであり、営業業務は一般企業であれば、どの企業にも存在し、大筋の業務の流れはどの企業も大きく変わらないということから、システム要求仕様はそれほど時間をかけることなく作成することができました。
また当初は、要求仕様の作成と同時に、レビュー・承認者を設定し、定期的なレビューを実施しました。しかし、各レビュー時点で、見えないユーザー要求に対して「その要求が本当に正しいものなのか」「真にユーザーが求めているものなのか」を検証、検討するのはとても難しく、常にまだ見ぬ顧客の業務やビジネスに対して本当の価値を提供できるかどうかを念頭に試行錯誤する必要がありました。
このようにシステム要求仕様作成に関して試行錯誤を繰り返すような場合は、アジャイル的な手法が非常に有効でした。
現在では、このような方法で検討されたシステム要求は前回の連載にてご紹介したRedMineというITS（Issue Tracking System:問題追跡システム）で管理されており、このシステムにより製品ロードマップ、顧客要望、バグ情報などが一元管理されています。
