■    コードは書かない、ドキュメントは作らない

さて、ここからは開発ということになります。設計フェーズではプロセスを構成する要素を定義し、「プロセス要素表」というものを作成します。開発ではそれに従って実装していきます。具体的なやり方に入る前にすこし考え方のようなことについて議論していきましょう。開発というと要件定義から起こされたプログラム仕様書に従ってコーディングをするというのが一般的ですが、そこを考え直そうではないかというのが趣旨です。

ですから、Webサービスとも違うわけです。Webサービスは明らかにコードを書いてサービスを作っていきます。もちろん、フレームワークやモジュールを利用したり、マッシュアップといった組み合わせもありますが、基本的にはコーディングが開発作業の重要な位置を占めているわけです。そういったやり方だと開発という言葉が合うのですが、コードを書かないとなると開発というのもおかしいかもしれません。

では、コードを書かないのならどうやってシステムを作っていくのかということになります。ざっくり言うと既成のソフトウエアを組み合わせてシステムを作るということです。家を建てるのにプレハブ工法というのがありますがそんなイメージになります。ですから、開発という言葉はそぐわないですね。家を開発するとは言いませんから。開発ではなく構築と言ったほうがぴったりします。従って、業務システムの場合はシステム開発とはいわずにシステム構築と呼ぶことにします。

逆に、業務システムに使われるソフトウエアは開発することになります。ある機能を実現するために開発されたソフトウエアを組み合わせて組み上がったものが業務システムとなっていくわけです。ノンコーディングで構築されるというのはこういうことです。ただ、全部が全部コードレスかというと現実には多少のプログラミングをする場合ももちろんあります。本当に特殊な機能の盛り込みとかインターフェースといった部分です。

また、既成のソフトウエアは特定の業務システム向けの仕様で作ってあるわけではありませんから、ぴったりフィットしない場合や不足機能があったりします。そんなときについアドオンとかカスタマイズということをしたくなります。それは極力しない方向で考えます。不充分なところや不足する点は人間がカバーしてもよいという割り切りをします。何でもかんでもITで自動化するというのはやめたほうがよいと思います。

例えば、業務フロー進行を自動化しようとすると分岐の嵐になったり頻繁な差し戻しがおきて却って複雑してしまうということがあります。あるいは、トラブルがあった時の異常の発見、復旧に時間がかかることもしばしばおきます。人間の目で管理できる限界を超えてしまっているわけです。しかしある程度人間がシステムに入り込んでおけば防ぐことが可能です。

それと、業務システム構築の段階でプログラミングすればするほどバグの発生という危険が待っています。よくERPなんかでもテストの時にバグが発見されて修正に追われるのはアドオン部分だと言われています。その点、既成のソフトウエアを利用すればその点は非常に楽です。きちっとテストされバグフィックスされたものが納入されるわけですから安心して使えます。だから、余計な手をあとから加えないでそのまま使えばよいのです。

今や、そうしたソフトウエアがクラウド上に多く置かれるようになったのでそれを利用しない手はありません。このクラウドソフトを見てもお分かりのようにドキュメントはありませんよね。多くは、ソフトウエアのヘルプを開けば分かるようになっています。昔のように分厚いドキュメントを書くのだが、いつも間にかメンテできなくなり誰も読まなくなり、結局はコードを書いた人に聞くなんて破目に陥ることもなくなっています。"コードは書かない、ドキュメントは作らない"という方向で行きたいものです。

No TrackBacks

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

Leave a comment