システム開発における問題点

�@　[　誤った人選　]
一般定型業務と違って、システム開発では開発者の発想や能力により、全くパフォーマンスの異なるシステムが出来上がります。
その影響は使った回数分増幅されるため、小さな差異でも、大規模で使用頻度の高いシステムを長年使った場合、企業全体では計り知れないほど大きな違いが生じることになります。

Ａ社では、開発責任者が決定される場合、その人物の過去に作ったシステムテムの内容（質）が問われることは一切無く、また人選権のある人に評価能力が無いため、適任でない人物が選ばれることになります。
そのため、彼らの作ったシステムは、現実に今も会社に莫大な損害を与え続けていますが、そのことに気が付いている人はほとんどいません。

正しく人選するためには、より上位にある責任者の人選を正しく選ぶことからはじめなければなりません。
技術的な能力と経験が豊富で物事を客観的で合理的な判断が出来る人をそのポストに就けるべきです。
表面的な見栄え（数や規模）でなくシステムの質を吟味し、作成者のシステム開発に対する主義主張や考え方さえも考慮する、いわゆる徹底した能力主義を貫くことであります。

�A　[　机上のシステム開発　]
Ａ社ではシステム開発の際、ユーザーとIT部門が打合せをして作成しますが、このような机上の検討のみで優れたシステムはできません。
ユーザーは、システム開発について熟知してはいないため、ユーザーにはシステムを最大限に有効活用する為の、業務見直しを含めたベストな要望をすることはできません。
また一方、IT部門は仮に業務知識を持っていたとしてもその業務を実践しているわけではない為、現行業務を変えることもなく大部分はユーザーに言われるままに作ることになるため、ユーザー発想の枠を大きく超えることはできません。
特に、最も重要な入力作業の効率化及び正確化に関しては、作業の細かい流れと発生頻度が大きく係わってくるため、作成者はユーザーと全く同じように業務を体験しながら作成することが必要とされます。
しかし、Ａ社の業務はIT担当者が体験できないほど複雑でも専門性の高いものでもなく、体験可能にもかかわらず、そのようなことは一切行われず、机上のみでの作成となっています。
実務体験には時間等のコストが発生するため、現実には無理だとういう意見もあります。
しかし、打合せのみでは理解困難であったり方針を決め兼ねていたことが体験により一目瞭然となり、打合せ、質問、回答待ち、机上での悩みなどに要していた時間を圧縮するという効果があるため、一概に体験にはコストがかかるとは言えません。
また、仮に体験することにより余計な時間がかかったとしても、システムには些細な違いが大きなパフォーマンスの差となって現れるという特徴があるため、長い目で見ればパフォーマンスの差が体験コストを十分吸収するということが考えられます。
確かに中にはコストの割りに効果が見込めないため、体験する価値の無いケースも存在すると思いますが、短絡的にできないと言う前に、本当に価値が無いのかどうか良く考えて正しい結論を出す必要があります。

本当に質の高いシステム作るためには、明らかに価値の無い場合や不可能な場合を除いて、IT部門員ができるだけ長期間現場に駐在して実務を体験しながら作成及び改良すべきです。

�B　[　開発後は無検証　]
使用前には全く気が付かなくても使用してみて初めて気が付くことが非常にたくさんあります。
事後に気付いたことに基づき、改良を続けるかどうかがシステムの良し悪しを決定します。
従って、使用開始後の改良が最も重要です。がＡ社ではそのことを認識できないため、事後の改良を行うことなど一切無く、ユーザーの改善要求を却下する傾向にさえあります。

�C　[　パッケージ化・外注化方針　]
パッケージには一般的に下記のようなメリットがあると考えられており多くの企業が導入しています。

１．　不具合が少ない
２．　特注と比較して価格が安い
３．　導入までの期間が短い
４．　業務にシステムを合わせるのでなく標準化されたシステムに業務を合わせることができる

しかし、下記のような大きなデメリットがあることはあまり認識されていないようです。

１．　個別の操作性や効率を犠牲にして汎用的に作ってあるため、業務が本当に最適化されることは通常
　　　無い
２．　事実上、機能変更が不可能な場合が多く、最も重要な事後の改良ができない
３．　メリット４．の反面、パッケージが提供する業務が必ずしも最良ではなく、業務改善や他社との差
　　　別化の妨げにもなり得る

上記のメリットは必ずしもメリットとは言い難いものや社内作成でも克服できるものばかりであるのに対し、デメリットの方は致命傷になりかねないものばかりであるため、社内にIT部門が存在する限りできるだけパッケージの使用は避けるべきです。例えば、

メリット１．の不具合に関しては、社内作成でもしっかりした社員が作成し、テストすれば問題ありません。

メリット２．の価格に関しては、パッケージが安いのは特注と比較した場合であり、直接費で見る限り無償である社内作成より高価なのは明らかです。
たとえ社内作成のための人件費を考慮しても、パッケージ導入時に社内IT部門で発生する見積もり依頼、問合せ、伝達、交渉、稟議などの仲介やパッケージ学習等のための余計な労働費をパッケージに加算すると、パッケージの方が安価になることは少なく、そこにパッケージカスタマイズ料や講習受講費が発生すればパッケージはさらに高くなります。

メリット３．の導入までの期間に関しても、パッケージ導入時に発生する余計な仲介や学習にかかる時間が社内開発期間を上回る場合もあるため、必ずしもパッケージは導入までの期間が短いとは言えません。

また、パッケージではなく特注システムを外部のソフト会社に丸投げすることも避けるべきです。
というのもソフト会社の目的が発注元企業の業績を向上させることではなく、自身が儲けることにあるからです。
そのため、優れたソフトを作ろうと努力するより、できるだけ手を抜き契約違反にならない程度のものを作り、料金の回収に懸命になる会社が多数存在するのです。
仮に懸命に作ったとしても、ベストに近いものを作るには業務を体験することもなく外部からできるものではありません。
さらに、パッケージほどではありませんが、外注したソフトは一般的に柔軟性が低く、最も重要な事後の改良が容易にできません。
例えば、社内で行えば無償でしかも数分間ででき、大きな効果が期待できる変更があったとしても、外注作成システムの変更にはコストがかかるため諦めるというケースも頻繁に発生しています。
変更自体にかかるコストばかりでなく、社内のIT部門では見積もり依頼問合せ、伝達、交渉、稟議など仲介等のための余計な時間と労力がパッケージ以上にかかります。
これらの時間と労力は変更自体にかかる部分よりも大きく上回る場合も多く、そのような場合は外注化するメリットが全くありません。

従来のようにアプリケーション開発が困難かつ多大な時間と労力を要した時代ならともかく、技術の進歩により簡単かつ生産性が大きく向上した今日、些細な変更を外部に注文することは非常に無駄なことです。
Ａ社のように、自社に開発能力がある場合は、できるだけ社内で作成するべきところを、基本的にIT部門は内作せず外注ソフトまたはパッケージを導入する方針にしているため、何十億円もの費用を浪費しているのが現状です。

また、Ａ社ではユーザーがIT部門の働きに大いに失望し、使用をボイコットしたり、独自にパッケージを導入するケースも複数発生しています

結論を述べますと、外注やパッケージ会社は、システムが正常に稼働することは保証してもＡ社の業績までは保証してくれません。そのため、仮に人員不足などの理由で外部企業を利用するにしてもシステム開発を依頼するのではなく、社内に取り込む形で技術者を雇い、自社の責任及び主導で開発を行い、あくまで業務面でのパフォーマンスを追及すべきです。

�D [　回避可能な障害の発生　]
障害の発生は避けられないものですが、工夫すれば回避可能なものも沢山存在します。
しかし、Ａ社ではそのような工夫を怠り、障害の発生を放置しているどころか、実施前から障害の発生が十分予想されるようなやり方で作業を行い、自らが障害を作り出していることも頻繁にあります。
このように無駄な障害対応が、IT部門本来の業務であるシステム開発に計り知れない支障をきたしています。

�E　[　変化の回避　]
ホストコンピュータにしか馴染みの無い世代の管理職の中には、新しいものを嫌いどのような案件もクライアントサーバやＷＥＢやＰＣではなくホストで処理を行うことを強要する人達が存在します。
彼らは稀にクライアントサーバを使用することになっても、流行りだから使うというだけで世間でホストよりクライアントサーバが好まれる理由を理解していません。
そのため、クライアントサーバのメリットを享受するどころかデメリットによる被害ばかりを被るという結果に陥っています。

�F　[　自己利益、自部門利益の追求　]
本来、ユーザーや会社全体の利益を考えて行動することが、個人や自部門の評価に繋がり、また利益となるはずです。
しかし、Ａ社IT部門の管理職層は目先の個人利益や自部門利益ばかりを追求し、ユーザーや会社全体を考えてシステムを構築しないため、評価は最低になり、個人利益も自部門利益も損なうという逆の結果になっています。

�G　[　入力作業効率の軽視　]
入力作業をいかに効率化するかがユーザーの労働コストを決定するため入力作業の効率化はコスト削減のための最も重要な要素です。
本ソフトウェア「復元」は１人あたりの使用頻度が低いユーティリティーなので操作効率をそれほど重視して作っていませんが、私が使用頻度の高い業務システムを開発するときには、常に１秒でも早く、１つでも少ないキー操作で入力作業ができるよう心掛けています。
しかし、Ａ社IT部門の幹部は私がその重要性を訴えても「入力なんかデータが入りさえすればどうでもいい。蓄積されたデータが活用できたらそれで十分だ。」と言って重要性を認めようとはしません。
そのため、入力簡素化の努力も自動化もされることなく、作業は煩雑、手動入力、二重入力、三重入力のままとなり、ユーザーの不満は一向に解消されません。

ある新聞記事に「システム開発をせずに、何十人もの人間を雇い人海戦術にしたところシステム開発費よりも低コストになり良かった。」とういう会社経営者のコメントが載っていました。
果して本当にシステム開発費より安かったのでしょうか。
もちろん、使用期間の短いものを外注で開発する場合など、開発の価値が無いものも存在するため、上記の例がどちらであったか断定は出来ません。
しかし、人件費の高い先進国では人海戦術の方が低コストで良いということは少ないと思われるため、コスト比較が正確にできてない可能性があります。
普通の商品と違いシステムというのは値段があってないようなもので無償のシステムの方が何億円も掛けて作ったソフトより価値が高い場合もあり得ます。
特に労働価値と賃金があまり比例していない日本の労働市場の下では、見る目さえあればそれを逆手に取り、非常に安価に優れたシステムの構築ができる可能性があります。
少なくとも言えるのは、システム開発能力を持つ人間が、その人海戦術に駆り出され、挙句の果てに開発時間の何倍もの時間を費やすというようなことは以ての外です。
しかし、Ａ社では実際にこのようなことも時々行われます。

労働力だけの問題ではなく入力ミスを防止するという観点からも、自動化可能なものは徹底的に自動化し、自動化不可能なものもできるだけ無駄なく短時間で入力できるように工夫すべきです。

�H　[　IT部門の役割　]

かつてＡ社のシステムは社内開発が中心でした。
しかし、近年はアウトソーシングという言葉に踊らされたためか、外注による作成またはパッケージ導入が中心になりました。
そのため、IT部門の役割はユーザーと外注企業との仲介または障害対応がメインになり、ますます存在価値が無くなって来ています。
あまり重要でない障害対応やインフラの整備、運用、保守をアウトーソーシングするのなら分かります。が、非常に重要な開発を自社で行わないのは致命的であるのと同時に、近年は開発効率の向上により外注企業との仲介に要するものよりも少ない時間や労力で作成できることも多くなったため、非常に無駄なことでもあります。

�I　[　他社の実態　]

Ａ社はこれらの点において典型的でかつ極端な例なのかも知れません。
私も業務上他社との接触があり、直接間接に見聞きした範囲で判断すると、多かれ少なかれ多数の企業が同様の傾向を持つように思います。

大手コンピュータメーカーなどは、技術者や基幹部分には少なくとも技術的には非常に優秀な人材をとり揃えているのかも知れません。が、世間も認める超一流企業の某コンピュータメーカーでさえ、Ａ社に出入りする末端の従業員達の行っている仕事はあまりにも粗末なものなのです。
例えば、自動化ツールを作成するならミスも発生させずボタン１つで一瞬のうちに終了する設定を、毎回手動で長時間掛けて行い、明らかに労働力を浪費しているばかりでなくミスも連発しております。自動では起りえないミスを犯し、それが原因となる障害を発生させて、Ａ社からの信頼を失うといった始末なのです。
加えて、難しい設定が一切無く「次へ」ボタンを押していけば素人でも簡単にインストールできるソフトをインストールするためだけの理由で泊りがけの出張をするというようなことが平気で行われています。

�@〜�Iで述べたことは、あまりにも幼稚でレベルの低い話であるため信じ難いと思われる方も多いと思いますが、現実にはこのようなことが日本型企業の実態だと推測できます。
上記のような無駄や非効率と直接は関係ありませんが、連日報道されている大企業の不祥事を見ても、日本企業がいかに杜撰な経営を行っているかが判断できます。