はじめに
開発部門から製品開発に異動してきた渡邉です。
開発部門では、ecbeingのパッケージをお客様の業務・運用に合うようにカスタマイズを行いお客様にご提供するというのがメインのお仕事でした。
製品開発に異動してきてから、開発部門で心掛けていたことを製品開発でどう活かすか日々考えています。
そこで、開発部門時代、カスタマイズの際に気を付けていたことをご紹介しながら、製品開発でも心がけていることを紹介いたします。
お客様の要望の真意はなんなのかを考える
お客様から依頼された機能を言われた通りに製造すると、運用する場面になって使いにくかったり、意図した物が出来上がっていない場合があったりします。
言われたものを作ったのにクレームになる、なんてこともあったりします。
要望が出た段階で、この機能はどんな目的で追加されるかを確認することで、運用には適しているか、必要な場所に必要なものが揃っているかなど要望に沿った機能を作成することができます。
お客様の要件が実際の運用に合うかを考える
お客様に依頼された機能を作成する際に、要望されている機能よりも運用に適している実装方法がないかを検討します。
例えば「データをインポートしたいので、インポート画面を作ってほしい。」という依頼があったとします。
お客様のご依頼通りのものを作った場合、運用軽減につながるでしょうか？
そのままインポート画面を作成しても運用はできると思うのですが、実際の運用を確認してみるとインポート画面ではなく、インポートバッチを作った方が効率的で、正確に運用ができる場合があったりします。
担当者は、データを取り込む手段はインポート画面から行うことしか浮かばなかっただけかもしれません。
運用を軽減できる手段などを提案することで、より良い運用が行えるようになるだけでなく、運用コスト削減につながることもあります。
では製品開発で出来ることはなんだろうか
前述の内容はどれも１つのお客様の場合に対応している例となります。
では、「製品開発としてはどうだろう。」と考えてみました。基本的な考え方は、変わらないと思います。
ただし、あるユーザにはマッチするが、ほとんどのユーザにはマッチしない機能とならないような工夫が必要になります。
以下はほんの一例ですが挙げてみました。
・ 開発部門から、実際にお客様から頂いた改善要望について意見を募り機能を検討する
・ プランニング・要望検討会などで、実装する優先順位を検討する
・ 実際のサイトを調査して、事例を集める
業種、規模、バックにあるシステムなどさまざまなシチュエーションがあるので複数のタイプを想定して、汎用的にかつ運用しやすさを考慮した機能を考えていくことが必要だと考えます。
まとめ
開発部門、製品開発どちらも利用していただくユーザの立場になって物事を考えていくことが重要だと思います。
ユーザの立場になることで、機能の利便性、運用のしやすさが見えてくるので、より良いモノづくりができると思います。
