こんにちは、Hです。
年明け1週間の仕事はいかがでしたか？
私たちの現場はさっそくフル稼働です。
そんな私たちの担当範囲の1つに事務システムがあります。
行員様が日々の業務を実施していくうえで利用されるもので
その出来如何で業務効率に影響を及ぼす大変な重要なシステムです。
今回はその事務システムの機能開発をするときに気を付けている点についてです。
機能が必要とされる背景を理解しないまま、開発していないでしょうか？
またきちんと利用される機能仕様を考えられているでしょうか？
ありがちな開発依頼（既存と同じような感じで）
ユーザから既存システムについて機能開発の依頼が入りました。
新しいサービスを提供するにあたって、事務側の業務が増えるので
それに伴って機能が必要となったようです。
「hatanakaさん、今度決済サービスを拡張するのに伴って
いくつか事務作業が発生するんだよね。
それで事務機能が必要になったからちょっと見積もってもらえる？」
そこでどんな機能なのかをヒアリングしました。
「どんな機能ですか？」
「この間開発してもらった○○サービスの照会と登録、承認機能とほとんど同じ。
画面の検索条件と表示項目についてはあとで画面イメージを送るんでそれ見ておいて。
明日には見積もりを出せるよね。」
「はい、大丈夫です。」
私たちがメンテナンスしている事務システムは
照会、登録、承認といったよく利用される機能があり
またそれはある程度テンプレート化されており、見積もりもしやすくなっています。
前回作ったばかりの機能ともほぼ同じということで
画面イメージを確認後見積もりを提示しました。
そして見積もりが承認されると、いくつか機能仕様について
不明な点を問い合わせて、それを明らかにしたら開発へと進めていきます。
・検索条件やチェック仕様
・一覧画面で表示する件数や表示順など
・登録・承認時の業務チェック内容
ここまできたらまずは一段落といったところでしょうか。
でも本当にこの機能、ユーザにとって適切な仕様になっているのでしょうか？
事務機能の種類は限られているが、利用されるシーンは千差万別
新しいサービスを提供する場合、当然のことながら業務フローをまとめて
そこで必要な作業やシステム側に求めることが上がってきます。
システム側に求めることは機能要求として吸い上げて
開発側に渡されてきます。
「実験！インパクト・マッピング」でも記載しましたが
この過程でもともと業務をどのように想定していたかの
情報伝達が漏れることが多いです。
たしかにその情報がなくても機能を開発することはできますし
実際にそのように進めていくこともあります。
事務機能を種類分けした場合、現在は概ね下記の分類で収まるので
それほど要求の背景を知らなくても開発が進められるというわけです。
・照会
・個別登録・承認
・一括登録・承認
・ファイル出力
・帳票出力
しかしながら業務としてどのように利用されるかを共有することで
開発側もこの機能は仕様としてこうする方がいいんじゃないか？
といった視点も持てると思います。
例えば照会機能1つとっても、検索条件の過不足や画面項目の表示内容や
検索結果のファイル出力はできたほうがいいか否かなど
利用シーンを想定することで「本当に必要なことってなんだろう？」と考えることができます。
逆に不要な機能であれば開発から外して、開発コストを削減するといったこともできるわけです。
「この機能は何のためにあるのか？」
その問いに対してきちんと説明できるかどうかがその機能が
きちんと使われるかどうかの一つのバロメータかもしれません。
開発は効率化しても、ユーザの要求は省略しない
ただ開発を行うにあたってはあらかじめ予算や開発着手への承認を得る必要もあり
とりあえず必要になるかもといった機能については開発をしておこうという
思惑も発生すると思います。
事務機能のようにある程度定型化された機能はどんどん開発効率を上げて
要望が発生したらできるだけ早く提供できるような進め方が大切です。
そこで効率化できた時間をユーザからの要求について検討したり、
一緒に考えたりすることがプロジェクトマネージャにも求められていることだと思います。
また、より低コスト・短納期で機能を提供できるよう仕組みづくりに取り組まなくてはいけません。
最近、ハイブリッドアジャイルのように基幹系システム開発でも取り入れていこうという
動きが活発化してきているのはそういったことも背景にあるかもしれません。
ただ間違ってもユーザの要求まで省略（効率化）しないようにしないといけませんね。
せっかく開発した機能が使われなかったら、それこそユーザにも頑張ってくれたエンジニアにも
申し訳が立ちませんからね。
今年も役に立つ機能をたくさんできるよう頑張っていきたいと思います。
