はじめに

さて、今回からは新しい章が始まります。題して「業務適用」ということで、前章で作っったアプリを使って業務を行っててみようという試みです。これも実際に動くものを見るのがいいのですが、紙の上での説明となります。従来のシステム開発では、業務アプリを作って終わりというケースが多いように思います。理由は作り手側と使い手側の乖離です。

使い手側いわゆるユーザーが、SIerとかの開発会社に頼んで業務システムを作ってもらうという図式で、作り手側はできたものを納品して終わりという関係である。従って、いざ使おうとするとうまく動かないという事態が発生する。システム的にバグだとか行ったものは改修してくれるのですが、業務オペレーション上で問題が生じるとそこは直してくれない。

というのも、仕様は最初の方に決められていて、その時って業務オペレーションがどうなるかのイメージが乏しいわけで、できて動かしてみて初めてこんなはずではなかったとなる。また、これもよくあるのだが、システム開発のプロジェクトにアサインされる担当ってキーパーソンでない場合が多い。仕様決めは彼らがやるわけだから、インフォーマルにやられているような部分は仕様から外れてしまうので、表層的な機能しか実装できないことになって使えないとなる。

だから、そうならないためにはシステム開発のプロジェクトでは、作り手と使い手の共同作業にしなくてはいけません。前章では実装編ということでインプリメンテーションをとりあえずやったという段階です。その段階でもユーザだけでやる場合は問題ないのですが、開発ベンダーが入っている場合でもユーザは必ず入ってむしろ主導権をとるようにして行います。

そして、業務適用という段階に入っていくわけですが、ちゃんと使えるように実装されたかというと難しいものがあります。動かさないと分からない、あるいは動かしてみてこんなはずではなかったと気がつくこともあります。ですから、まだプロトタイプと言ってもよいでしょう。ここから、プロトタイプを動かしながら実装に戻ることもしながらブラッシュアップしていきます。

このようなプロトタイピング手法が重要なメソッドになります。動かしてみて追加修正が出てきたらまた設計しなおして実装してという繰り返しを行います。ですから、そういったことができるプラットフォーム、ツールでなくてはいけません。いちいちコードを書きなおしたり、高いスキルでないとできないというのは不適です。Kintoneを採用しているのはIT専門家でないユーザ部門のひとでもできるからです。次回から、実際にオペレーションをしながら検証していきます。
  

No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/108

Leave a comment