プログラマーはシステムを開発するな！
これまで、システム導入が失敗する理由について触れてきましたが、今回、さらにもう１つ、開発者側の致命的な問題についてお話しします。
開発テクニックは重要ではない
去に私が接してきた全てのプログラマー（PG）に共通していえることなのですが、彼らは、開発テクニックに強い関心があり、先端技術を駆使してシステムの画面を色々と工夫しようとします。例えば「リストのここをクリックすると、項目の並び順が瞬時に変わるようにしたい」だとか「マウスをドラッグした時、その部分が拡大表示されるようにしたい」だとか。もちろん、きめ細かく配慮の行き届いた画面を顧客のために作りたいという心がけは良いのです。しかしそれが往々にして、顧客の業務の本質には関係ない、表面的なだけの小手先の機能の実現となり、PGの自己満足で終わってしまいがちです。
例えば業務管理系システムであれば、まずその会社の業務について深く理解していなければなりません。さらに、その会社の経営方針や、管理職の考え、実際にシステムを使用するオペレーターのスキルなどを見据えるトータルな視野も必要になります。ところが多くのPGは、顧客の業務内容や会社の実情には、開発テクニックほどの強い関心を持っていません。そのため、「何のためのシステム」であるかがきちんと捉えられていないのです。
顧客の業務の実情を把握しているか
例えば、細かいマウス操作でいろいろ便利な機能が使い分けられるシステムを作っても、オペレーターがコンピュータ慣れしていない人達であれば、むしろ基本的な数値入力とキーボード操作だけで使用できるシステムの方が良いわけです。
切心から、誰でも簡単に、いろいろな画面から商品情報を取り出せる仕様にしたとします。現場のオペレーターには便利で好まれるかもしれませんが、仕入先や商品原価までもが誰にでも丸分かりになってしまうのならば、経営者としてはありがたくないでしょう。
とんどのシステム開発において、顧客の業務を把握したシステムエンジニア（SE）が指示書を作成し、それに沿ってPGがプログラミングを行います。しかし、指示書に業務の全てを事細かに書き起こすことは非現実的です。不可能ではないかもしれませんが、膨大な作業量になる上、実際にプログラミングを始めてから、改善案や懸念材料が新たに発見されることも多いのです。ですから「指示書以外の事柄は全て不要」というスタンスは危険過ぎます。PGが顧客の業務の実情を把握しておかねばらないゆえんです。
中国、インドへのアウトソースが失敗する理由
近年、安い人件費の魅力につられ、中国、インドへシステム開発をアウトソースする傾向にあります。しかし一般的に彼らは、指示書の通りには作ってくれても、そこに書かれていないことについては配慮しません。ですから、「マイナスの数値が入力できてしまう年月日欄」だとか「５桁のパスワードを入力する画面で６桁以上入力してもエラーメッセージが出ない欄」などが生じたりするわけです。
日本人が働いている下請け企業にシステム開発をまかせていた時ですら、満足に使えるシステムを納品できなかったソフト会社が、海外へ開発をアウトソースしたりすれば、「こんなことも理解されないまま納品されてしまった」という顧客からの苦情が増加するのは当たり前です。
相互に深い有機的なつながりがあるべきシステムをパーツに分け、指示書で無機質に表現して別々に開発させ、つなぎ合わせて動かそうとすること自体、無理があるのだと思います。「システムはSEが開発すべき」というのが私の持論です。SEの資質をもったPG、もしくはPGにもなれるSEが開発しなければ、本当に使えるシステムにはならないという意味です。「指示書に書いてあることだけ実現させれば完成」というPGの考えこそ、使えないシステムがたくさん開発されてきた元凶です。あらゆる点について細大漏らさぬ指示書の作成など不可能なわけですから、指示書には示されていない問題や懸念要素を察知し対応できるスキルこそ開発者には必要なのです。
開発テクニックは重要ではない
去に私が接してきた全てのプログラマー（PG）に共通していえることなのですが、彼らは、開発テクニックに強い関心があり、先端技術を駆使してシステムの画面を色々と工夫しようとします。例えば「リストのここをクリックすると、項目の並び順が瞬時に変わるようにしたい」だとか「マウスをドラッグした時、その部分が拡大表示されるようにしたい」だとか。もちろん、きめ細かく配慮の行き届いた画面を顧客のために作りたいという心がけは良いのです。しかしそれが往々にして、顧客の業務の本質には関係ない、表面的なだけの小手先の機能の実現となり、PGの自己満足で終わってしまいがちです。
例えば業務管理系システムであれば、まずその会社の業務について深く理解していなければなりません。さらに、その会社の経営方針や、管理職の考え、実際にシステムを使用するオペレーターのスキルなどを見据えるトータルな視野も必要になります。ところが多くのPGは、顧客の業務内容や会社の実情には、開発テクニックほどの強い関心を持っていません。そのため、「何のためのシステム」であるかがきちんと捉えられていないのです。
顧客の業務の実情を把握しているか
例えば、細かいマウス操作でいろいろ便利な機能が使い分けられるシステムを作っても、オペレーターがコンピュータ慣れしていない人達であれば、むしろ基本的な数値入力とキーボード操作だけで使用できるシステムの方が良いわけです。
切心から、誰でも簡単に、いろいろな画面から商品情報を取り出せる仕様にしたとします。現場のオペレーターには便利で好まれるかもしれませんが、仕入先や商品原価までもが誰にでも丸分かりになってしまうのならば、経営者としてはありがたくないでしょう。
とんどのシステム開発において、顧客の業務を把握したシステムエンジニア（SE）が指示書を作成し、それに沿ってPGがプログラミングを行います。しかし、指示書に業務の全てを事細かに書き起こすことは非現実的です。不可能ではないかもしれませんが、膨大な作業量になる上、実際にプログラミングを始めてから、改善案や懸念材料が新たに発見されることも多いのです。ですから「指示書以外の事柄は全て不要」というスタンスは危険過ぎます。PGが顧客の業務の実情を把握しておかねばらないゆえんです。
中国、インドへのアウトソースが失敗する理由
近年、安い人件費の魅力につられ、中国、インドへシステム開発をアウトソースする傾向にあります。しかし一般的に彼らは、指示書の通りには作ってくれても、そこに書かれていないことについては配慮しません。ですから、「マイナスの数値が入力できてしまう年月日欄」だとか「５桁のパスワードを入力する画面で６桁以上入力してもエラーメッセージが出ない欄」などが生じたりするわけです。
日本人が働いている下請け企業にシステム開発をまかせていた時ですら、満足に使えるシステムを納品できなかったソフト会社が、海外へ開発をアウトソースしたりすれば、「こんなことも理解されないまま納品されてしまった」という顧客からの苦情が増加するのは当たり前です。
相互に深い有機的なつながりがあるべきシステムをパーツに分け、指示書で無機質に表現して別々に開発させ、つなぎ合わせて動かそうとすること自体、無理があるのだと思います。「システムはSEが開発すべき」というのが私の持論です。SEの資質をもったPG、もしくはPGにもなれるSEが開発しなければ、本当に使えるシステムにはならないという意味です。「指示書に書いてあることだけ実現させれば完成」というPGの考えこそ、使えないシステムがたくさん開発されてきた元凶です。あらゆる点について細大漏らさぬ指示書の作成など不可能なわけですから、指示書には示されていない問題や懸念要素を察知し対応できるスキルこそ開発者には必要なのです。
