ビジネスではシステムは欠かせない存在になっています。中小企業とてシステムの利活用無くしてビジネスを遂行することはもはや不可能ですし、システムの規模は着々と拡大しています。しかし、システム開発の現場ではまだまだたくさんの課題が残されています。システムを扱う者としては、現状あるシステムの課題と対応策を知り、ビジネスの成功にしっかりと効果を発揮するようなシステムの構築が求められます。
では、その課題と対応策とは一体何でしょうか？本稿ではシステム開発プロセスにおける課題と対応策についてご紹介します。
システム開発の課題とは？
それではさっそく、システム開発でよく発生する課題についてご紹介します。
システム開発の標準化がされていない
システム開発はそこに携わる開発者の経験や能力が、品質と生産性に大きな影響を与えます。しかしながら、昨今の大規模化・複雑化したシステム開発では多人数の開発要員が同時に作業を進めることも多く、開発プロセスや成果物に何らかの基準を定めなければ、システムの品質と整合性を確保することができません。
しかしながら、中堅以上のIT企業ではシステム開発の標準化が行われている一方で、中小規模のIT企業では開発標準が整っていなかったり、間違った基準を策定したりしているなどの問題があります。
システム開発の目的が共有されていない
システム開発の初期フェーズ、ヒアリング段階・ヒアリング段階でシステム開発の目的が共有されていないケースが少なくありません。システム開発を依頼するクライアントは「あんなことがしたい」「こんなことがしたい」という要望をたくさん提案します。そうした要望を受けて、現実的観点から可能な方法を探り、時には要否を考えてシステム開発を提案するのがIT企業の仕事です。
しかしこの段階で「システム開発の目的」が共有されていないことが多く、IT企業はクライアントの要望を極力盛り込んだシステム開発を提案してしまい、結果として現状に即さないシステムができ上ってしまいます。
業務の見直しがされていない
システムは今ある業務をより効率良く行えるようになったり、各業務で生成される情報を蓄積したり、それを活用するために存在します。ただし、システムを導入したからといって業務効率が劇的に上がったり、売上が急激に増加したりするようなものではありません。
システムはあくまで「ツール」です。そのため、そのツールを扱う業務の見直しが実行されていないと、システムを導入してもその効果を最大限引き出すことはできません。多くのシステム開発ではそうした業務の見直しが忘れられがちです。
開発途中のシステム要件変更が許容されない
システム開発というのは、基本的に手戻りが発生しないように計画が組まれています。ものづくりの現場で考えてみても、商品開発から設計仕様、実際の設計やプロトタイプの制作、金型の製造などのプロセスを考えると、途中で設計仕様の変更が生じるとかなりの手戻りが発生し、計画遅延やコスト増が起きます。
これと同じように、システム開発でも後工程での手戻りがプロジェクト全体に大きな影響を与えるため、極力手戻りが発生しないよう計画が組まれているのです。しかし、昨今急激に変化するビジネス環境において、システム開発途中に要件が変更になることは多々あります。そうした要件変更に対応できるようバッファ（余裕）を持っていないと、そこに様々な問題が発生します。
新しい技術を取り入れる準備ができていない
近年はAI（Artificial Intelligence：人工知能）やIoT（Internet of Things：モノのインターネト）がIT業界の大きなトレンドになっています。たとえば工場においてIoTを導入すれば、生産ラインの監視をシステムに任せて、それを中央から人がコントロールするような「スマート・ファクトリー」も実現できます。
ただし、IoTを導入することでこれまで以上に、情報が洪水のように溢れていくため、情報漏えいが懸念されます。そこで工場のセキュリティ強化が重要になるわけですが、そうした新しい技術への準備が何よりも大変なところです。
以上のように、システム開発にはたくさんの課題があります。また、それらの課題はIT企業によっても違いますし、対応策も異なってきます。皆さんの会社では、どういった課題を抱えているでしょうか？
システム開発課題の対応策
フレームワークを取り入れる
正しい開発標準を策定するためには、まず開発者全員が共通認識のもと話を進められるような環境を整える必要があります。これを可能にするのが、IPA（情報処理推進機構）が提唱する『共通フレーム』です。システム開発の構想段階から開発・運用・運用・廃棄に至るまでのライフサイクル全般を通じて、必要な作業項目が包括的に規定されています。
ただし、共通フレームは、日本においてシステム開発に関係する人々（利害関係者）が「共通言語」で話すことができるようにすることを目的に策定されているため、さまざまな開発モデルや実装方式でも利用できるように、成果物の種類や書式などは規定していません。あくまで共通フレームと「共通言語」にして、企業ごとに開発標準を作っていく必要があります。
クライアントとIT企業が協力体制を取る
システム開発の現場ではよく、「開発に関することはIT企業が行うこと」「業務の見直しに関することはクライアントが行うこと」といった分業体制が見られますが、実際は初期フェーズから最後までクライアントとIT企業が協力体制を取ることがとても重要です。
たとえば、システム開発の目的共有1つとっても、IT企業とクライアントが協力し合って確認しなければ、開発段階で認識の相違が起きたり、さまざまな問題が起きたりする原因になります。その結果、計画遅延が発生し、コストが増加し、最終的には実態に即していないシステムが完成してしまいます。
システム設計段階から情報の共有と品質を守る
システム開発が長期間にわたり、当初予定していた構想から実装段階において想定が変わってくることはよく起こります。そのためソフトウェア開発においては、基本設計や詳細設計段階でのドキュメント化（仕様書）はバイブルといってもよく、どこをどのように変更するべきかを検討する際にも、設計書に立ち返ることは非常に重要です。
そのため、設計書は統合的に管理され開発に携わるメンバーは誰でも閲覧ができる環境を整備し、「いつ」、「誰が」、「何を」変更したのかも適切に管理することが大切です。
そのため、WordやExcel、Visioなどを使った手作業で各個人が管理するのでは、修正の反映が徹底されず、自分に必要な箇所だけ更新されるなど、バージョンの管理もままなりません。
