今回は、最近なにかと顧客との関係構築にはオウンドメディアが重要と耳にしますが、オウンドメディアだけではなく、『システム』を作る際、開発側ではなく発注側が気を付ける注意点です。
『システム』を作る際にどのようなことに気を付けないと、運用し始めてからここが使いづらいとか、いけてないな～となってしまうのでしょうか。
技術がなくても大丈夫！事前準備が成功のカギ
システム開発の成否は準備段階で80、90％が決まります。
普通にやればまず失敗するということです…。このことは、インターネットで検索すると、どこでも目にします。そして、開発したシステムが失敗に終わったとしても、そのシステムを開発した会社の技術レベルが低いと言い切れるわけでもありません。むしろ個々の技術者は非常に優秀な場合もあります。
システム開発で結果に大きな差を及ぼすのは、「開発対象となるシステムが備えるべき機能要件をどれだけ事前に想定できたか」になります。一言でいえば、「そもそもどんなシステムにしたいのか？」を決めることです。この作業工程を「要件定義」といいます。
開発側からすると、要件定義力は発注側が備えるべき能力と言われることが多いですが、実際に要件定義をきちんと理解して作成できる非エンジニアは少ないでしょう。それに要件定義力を鍛えようにも一般的な会社が頻繁にシステムの開発をすることはないと思われますし、要件定義の技術を備えろ！と言われても困難でしょう。
良いシステム（ここでは初めに企画・想定した思い通りに作られたシステムとします）を作るためには、きちんと現状の業務フローとどのようにしたいのかを要件定義に盛り込むことです。
要件定義の落とし穴と、意外なヒトに成功の秘訣あり！？
要件定義はベンダーやSIer（System Integrator）がヒアリングをもとに作成することが多いので、必ずと言ってよいほど作成はされます。ただ、慣れているとはいえ、ベンダーやSIerは会社の業務を把握していません。現状の業務フロー、要件定義をヒアリングしながら作成してみて初めて理解するのです。
そして、この準備（業務フロー・要件定義）が甘いために、「ここに入力できるようになっていない」といったこと「この欄は入力誤りがない様に自動で番号付与し、ロックをしといてほしかった」、「レポートでこの数値が取れないから分析しようとしてもできない」といったことがシステムをリリースしてからわりと早い段階で起きてしまうのです。
システム開発は「書かれていないけどこうしてほしかった」というニュアンスまで理解して進めることはありません。だからよく、普通に考えたら分かるでしょなんていざこざを聞きますが、それはエンジニアからすれば要件定義に書かれていません。非エンジニアからすれば、多少の融通は利かせてよという認識の差から起こります。
まずは現状の業務の流れを書くのですが、業務知識や現在のシステムを理解していることは前提として、能力のあるなしではなく、業務フローを書く向き不向きがあると思っています。フローチャートを使って業務を説明してみてと書かせてみて、一番細かく書いた人に要件定義を書いてもらうのもよいでしょう。
パワポ作成はあくまでも過程。何度も処理作業をしながら確認を！
では実際に書いてみましょう！
まずは手書きで紙に書いてから、パワポで作成するのがオススメです。試しに1つ頻繁に起こる処理フローを書いて番号を振っていってみてください。
番号の振り方としては、【チャネル】-【処理名】-【処理名の行程番号】とほとんどの業務が少なくとも3階層は使いますので、メール-受注-メール返信＝1-1-5というように、番号も3階層くらいで振り始めたほうがよいです。
手で書いて、パワポに作成し終えるとそれっぽくなり、作った気になりますが、ここでもう一度、パワポを印刷し、実際に現在のシステムを使いながら抜け漏れがないか入念に確認しましょう。そして、新しいシステムでどういう制御をすれば省略でき作業効率できるのか、UI的に誤操作を防げるのかを考えながら要件定義をしていきましょう。
簡単な一例ですが、画面のレイアウトを書いて、このBoxはアルファベットとひらがな入力可。文字数は30字、データは顧客情報の入っているデータベースから自動で持ってくるなどと整理していくと要件定義の漏れも少なくなるでしょう。
成功に近道なし！結果的にコスト圧縮となるシステム開発とは
業務フロー・要件定義を書く上で、慣れることで作業時間の短縮はできますが、近道はないと思います。今やっていること、そしてそれをどう改善、変更できればよいものとなるのかを1つ1つ漏れなく丁寧に書くことが、リリース後の保守・改修費用を抑えられることになり、全体のコスト圧縮となることでしょう。
