システム改修によくあるトラブル

こんにちは。キムニーです。

システム開発を伴う起業が最近多いので、将来起こり得るシステム改修のトラブルについて、代表例をまとめてみました。

度重なる仕様追加で、新しいシステム加えようとしても、もはや整合性取れない事件

ビジネスは日が経つにつれ、オペレーションが少しずつ変わり、商品が増え、業態も変化し、関係者も増えていきます。最初はとてもシンプルな機能であっても、そのような変化のたびに仕様変更および仕様追加が伴います。毎回、システムを全部変えるのはお金がかかりますので、殆どの場合は付け焼刃でシステムに変更を加えていきます。そうするとどうしても数年後には、いびつな仕様のシステムに様変わりしてしまいます。ある程度の年数が経ったら、大規模な改修が必要になるでしょう。

要件定義書及び仕様書無いので、もともとの仕様が理解できない事件

びっくりするかもしれませんが、システムを構築する際に、要件や仕様をやりとりした資料が残っていない場合が多くあります。そうすると、開発の担当者が変わったりするときに、仕様が伝承されません。その場合は、ソースコードを解読したり、当時の人にヒアリングして仕様書を再現させることになるので、大規模なシステムの場合は、大きな遅れの原因になりやすくなります。最近、アジャイルというスピード重視の開発スタイルが流行っていて、資料をほとんど作らずに開発だけしてしまうことがあるようなので、気をつけて下さい。

仕様書がコードから自動生成されていて、それじゃ仕様書の意味ないよ事件

日本の大企業に納品するときによくある話です。昔からの納品の習慣で、ただプログラムを納めるのではなく、仕様書を納品する文化がありました。大規模なシステムになると、仕様書に膨大な時間を費やすことになるため、ソースコードから自動で仕様書っぽい資料を作るソフトウェアが売られるようになりました。当然、その仕様書はソースコードを見るレベルと同じなので、仕様書が存在していないのと同じ事件が起こることになります。

勝手に外部パッケージ導入されて、既存システムと連携できる仕様になってるかを確認されてなかった事件

外部の商品を上手く使用することで、開発期間を短くすることができます。ただし、外部システムと連動させる場合は注意が必要です。インターフェイスが元々用意されていることは稀で、もしインターフェイスが用意されていたとしても、そこに課金があったり、内製のシステム側の方でインターフェイスを合わせる手間が発生する場合があります。

ソースコードが汚いし、スパゲティーだし、コメント無いから、既存システムを解読するのが大変だ事件

1つのアウトプットを出す場合であっても、プログラムの書き方は、何百通とあり、千差万別です。経験の多いプログラマーは、誰かが改修することを踏まえて、誰が見ても分かりやすいプログラムを書きますが、経験の浅いプログラマーは、とても複雑なプログラムを書いてしまいます。また経験の浅いプログラマーは、たいてい仕様書も粗雑です。とくに外部に発注する場合は、請負会社のエンジニアの力量をきちんと見極めましょう。

売り物なのにGPLのソースコード見つけちゃった事件

さいきんは、とても多くのオープンソースがあり、いろんなサービスを開発できるようになりました。しかしオープンソースの多くは、商用を禁止しているので、必ずライセンスを確認しましょう。

担当者が代わる代わる違うこと言うから、要件まとまらない事件

1つの業務に複数の担当者がいる場合は、かならず担当者の要望を全員一致で合意するところから始めましょう。さもないと、作り終わった後に、私はこういう使い方をしない!つかいずらい!という声があがり、要件を聞くところからやり直しが発生してしまいます。

潜在不具合(バグ)たくさん見つけちゃった事件

既存のシステムに仕様変更を加えることにより、今までは機能していなかったバグが、新しい機能が作用して、表面化するバグというのもあります。人間がコードを書いている以上、バグは0パーセントになることはありません。ですが、テストによってそのバグを修正していくことにより、使えるシステムとなります。しかし納品日を無理やり縮めたり、発注金額を下げたりすることで、そのテスト工数が異常に少なることがありますので注意しましょう。

外部システムのほうにバグがあって、しかも治してくれない事件

先ほども書いたように、上手く外部のシステムを活用すると開発期間が短くなりますが、不具合(バグ)の保証期間というのは、長くても1年位なので、それを過ぎるとバグがあっても治してくれません。ですので納品される時には、自社でもバグが発生しないかしっかりテストをしておきましょう。

外部システムの商品がすでになくなっちゃって、OSアップデートに対応出来なくなっちゃった事件

外部のシステムを利用するときのリスクは、その会社が潰れてしまったとか、その商品が無くなってしまったということが起きることです。日本の大企業は、商品開発が止まったとしても、ある程度の期間はサポートを続ける場合が多いのですが、ベンチャー企業の商品や、海外の商品は、開発が止まったと同時にサポートも無くなってしまうことが多いので注意してください。

Windowsのアップグレードごとに改修しなければいけない事件

殆どの企業では、WindowsのPCを使っていると思いますが、Windowsアプリケーションを作る場合は、OSがアップグレードされる度に、ちゃんと動作するかを確認する必要があります。場合によっては、Windowsの内部のライブラリが変更されたり、インターフェースが変更されている場合があり、毎回改修が必要になることもあります。もしそれが売り物だった場合は、改修は避けられないので、その工数が蓄積し、利益を圧迫して、売れば売るほど赤字となることもあります。逆に言うと、ベンチャー企業や海外企業は、このあたりの改修は非積極的で「仕様です」「そういう契約です」というサポート体制が多い様です。

さて、現在のランキングは何位でしょう?
下のボタンをクリック!
にほんブログ村 ベンチャーブログ 起業・独立支援へ