Posted on

恐怖!現場にはびこる趣味プログラム

趣味から生まれた社内システムの光と影

Excelマクロや Microsoft Access など、一人の担当者が趣味の延長で作成したシステムが企業内に残されていることは珍しくありません。これらのシステムは、当初は小規模な業務効率化のために作られたものが多く、時間とともに重要性を増していくことがあります。しかし、趣味で作られたプログラムは、専門のシステム会社やSEには解読が困難な場合があります。

正確に言えば、熟練のSEは素人の作るプログラムを見たくないというのが本音です。その理由として、コーディング規約や設計思想の違い、ドキュメンテーションの不足などが挙げられます。また、趣味で作られたシステムは、セキュリティやスケーラビリティ、保守性などの面で問題を抱えていることが多いのです。

このような状況は、組織にとって長期的なリスクとなる可能性があります。システムの作成者が退職したり、異動したりした場合、そのシステムの維持や更新が困難になる可能性が高くなります。また、業務プロセスの変更や法令の改正などに対応できず、組織の業務効率を低下させる原因となることもあります。

したがって、趣味で作られたシステムを組織の正式なシステムとして採用する場合は、専門家による評価や再設計が必要となることが多いでしょう。また、長期的な視点で、これらのシステムを標準化されたプラットフォームに移行することも検討する必要があります。

個人開発から組織管理へ:システム移行の課題

現在進行形で、お手製の子システムを作り続けている担当者も少なくありません。これらのシステムは、特定の業務ニーズに迅速に対応するために作られることが多く、初期段階では非常に効果的に機能します。しかし、システムの利用者数や利用頻度が増えるにつれて、新たな課題が浮上してきます。

最もよく聞かれる問題は、片手間ではメンテナンスが間に合わなくなることです。システムの規模が拡大し、機能が複雑化するにつれて、バグの修正や新機能の追加に要する時間と労力が増大します。また、ユーザーからの要望や問い合わせへの対応も増え、システム管理者の負担が急激に増加することがあります。

このような状況に直面した際、多くの担当者はシステム会社への依頼を検討します。しかし、自作システムの引き継ぎを快く引き受けてくれるシステム会社は多くありません。その理由として、システムの設計思想や仕様が標準的でない場合が多いこと、ドキュメンテーションが不十分であることなどが挙げられます。

結果として、システムの作成者は孤立し、増大する業務負担に苦しむことになります。また、組織全体としても、重要なシステムの維持管理が一個人に依存する状況は、大きなリスクとなります。このジレンマを解決するためには、早い段階でシステムの重要性を認識し、組織的な支援体制を整えることが重要です。

自作システムリプレイスの費用対効果

自作システムの維持が困難になった場合、多くの組織はそのシステムを専門のシステム会社によって作り直すことを検討します。しかし、この過程では新たな課題に直面することになります。システム会社に依頼して同じ仕様のシステムを作る場合、相応の費用がかかることは避けられません。

この高コストの背景には、いくつかの要因があります。まず、プロフェッショナルなシステム開発には、要件定義、設計、開発、テスト、導入といった体系的なプロセスが必要となります。また、セキュリティ対策、スケーラビリティの確保、ドキュメンテーションの作成など、自作システムでは見落とされがちな要素も考慮する必要があります。

さらに、気軽に始めてしまった自作システムとその利用ユーザーに不満なく、システムをリプレイスすることは容易ではありません。ユーザーは既存システムの使い勝手に慣れており、新システムへの移行に抵抗を示す可能性があります。また、長年の運用で蓄積された独自の業務ノウハウや例外処理を、新システムに完全に反映させることは困難を伴います。

このような状況下で、コストと機能のバランスを取りながら、満足度の高いシステムリプレイスを実現することは、組織にとって大きな挑戦となります。成功のカギは、ユーザーとの密接なコミュニケーション、段階的な移行計画、そして柔軟な予算管理にあると言えるでしょう。

段階的アプローチによる最適化リプレイス

子システムのリプレイスにおいて最も難しい課題は、コストの差を克服することです。自作システムと専門家によるシステム開発では、必要とされる投資額に大きな開きがあります。この課題を解決するためには、戦略的なアプローチが不可欠です。

まず最初に取り組むべきは、リプレイスのゴールを明確に定義することです。何を完成させれば成功と言えるのか、具体的な指標を設定する必要があります。これには、システムの機能要件だけでなく、パフォーマンス、セキュリティ、ユーザビリティなどの非機能要件も含まれます。明確なゴール設定により、不要な機能の開発を避け、コストを抑制することが可能になります。

次に重要なのは、費用を上げずに運用や利用方法を調整しながら、要件定義を行うことです。これには、現行システムの詳細な分析が必要です。どの機能が本当に必要で、どの機能は廃止または簡素化できるのかを見極めます。また、新しいテクノロジーやクラウドサービスの活用により、開発コストを削減できる可能性もあります。

さらに、ユーザーの協力を得ることも重要です。ユーザーの業務プロセスを見直し、必要に応じて変更することで、システムの複雑性を減らし、開発コストを抑えられる場合があります。このプロセスでは、ユーザーとの密接なコミュニケーションが不可欠です。

最後に、段階的なアプローチを検討することも有効です。システム全体を一度にリプレイスするのではなく、優先度の高い機能から順次開発・導入していくことで、リスクとコストを分散させることができます。

まとめ

システム会社へツールや子システムのメンテナンスをお願いするには、業務知識も踏まえたITコンサルティングが必要になります。一般的にスキルが高いと呼ばれるSEでは、目的の結果が得られないこともあるでしょう。

お手製で作ったシステムをシステム屋に華麗にパスするには、パスを受けるSEやシステム会社の選定も大切になります。ユーザーはシステムを作りたいのではなく、業務を楽にしたいのである。というのは、客はドリルが欲しいのではなく、穴を空けたいのである、という言葉に似てますね。

目的をしっかりと整理したシステム開発を依頼するなら、アタラキシアDXをぜひご検討ください!