システム開発の基本概念
システム開発の基本概念
システム開発、システム構築、ソフトウエア開発、IT開発等、言葉の定義はたくさんありますが、今回のコラムでは、これらをまとめてシステム開発という事にしましょう。そして最後の部分でDX開発や最近のトレンドにも触れたいと思いますが、今更聞けないことも含めてわかりやすく解説をしたいと思います。
システム開発とは、簡単に言えば「仕組みを作ること」を指します。 企業、自治体、政府、団体など様々な業種業界においては、IT技術を駆使してさまざまな仕組みを構築し、業務効率化、利便性、安心安全、ビジネス拡大、社会を支えるインフラを作ったり、創造することがシステム開発の目的です。 具体的な例としては、販売や在庫を管理したり、生産を管理したりする企業向けの様々な管理システムや、従業員の勤怠管理システム、顧客情報管理システム、最近ではAIなどで予測をしたりするシステムを作ることが該当します。成果物としては、ソフトウエアプログラム、そのソフトウエアが動作するためのハードウエアや各種ツール、打合せ時に作成した、システム全体が理解できるような概念図や業務課題に対しての対策（ASISとTOBE）などがあります。
システム開発の重要性
システム開発は、企業の業務効率化を達成するために必要不可欠です。日本が抱えている本質的課題の中で、少子高齢、労働人口不足がありますが、効率化だけではなく、自動化や機械化を図り、人手不足を解消することも必要になりますし、インターネットを利用したシステムがあれば、少ない人数で販売を拡大することもできるでしょう。そして販売を拡大するだけでは物足りず、販売を予測するシステムがあれば、経営的な資金繰りにも参考になりますし、金融機関に提出すれば融資にも説得力があります。
また、ここで少し詳しく解説しておきたいのは、世の中には共通業務を効率化するための出来上がったパッケージシステムというものがあります。販売管理や在庫管理などは、多くの企業でその対象業務が存在しており、そのような業務については、一からオーダーメイドでソフトウエアを開発するのではなく、安価なパッケージシステムがお薦めです。従ってその企業独自の業務や課題、又はパッケージシステムは利用しているが、そのデータを活用して経営数値の可視化をしたいなどのニーズが発生した場合に本解説が該当するということです。
システム開発の工程
要件定義の重要性
要件定義とは、システム開発の目的や必要な機能、希望の納期などを明確化する工程です。システムエンジニアが発注元にヒアリングを行い、求められる要件を確認します。この工程は最初の入り口となりますので最も重要です。下流工程に行った時に、例えばこの機能は何のために作るのかなど疑問が生じた時に上流の要件定義として記述されている事項として立ち戻ることができるからです。システムを利用する人が何人、何十人、何百人なのか、この画面はだれが閲覧できれば良いのか、入力する担当者の所属はどこなのか、など作りてからするとたくさん疑問がでてくるものです。そして一番重要なことは、システムの開発目的です。社内コスト削減の為の業務効率化が目的であれば、現状の課題とシステム完成時の利用イメージの差異などがわかる資料も準備しておくべきです。そのようなＫＰＩを用意しておけば、システム稼働後にＰＤＣＡサイクルを回すことができます。システム導入の費用対効果というものです。
設計の種類とポイント
当社では、システム開発の作業内容を一般の方にご説明する場合に、マイホームを建てる時の事例を活用して説明することが多いです。マイホームの場合、外観図面があって、その後詳細図面や設計図をもとに打合せを何回も重ねていくと思われますが、システム開発も流れが同じです。以下に設計書の種類と内容を解説いたしますが、必ずこのような設計書が必ず必要という事ではありません。開発規模や納期および業務によって必要不必要が分かれてきますし、それによって費用も変動しますので。極端なケースでは、お金が無いから作成しなくて良いと顧客から要望を受けることもあります。しかしながら設計書はテスト作業時に使いますし、システム稼働後に何らかの改修作業（カスタマイズと言う）が発生した場合に設計書が無ければ、開発した担当者でないと改修作業が安くなりません。もしもその担当者が退職してしまうなどのリスクを回避するのであれば、設計書は最低限残すべきでしょう。
基本設計
基本設計（概要設計とも言います）とは、要件定義書を元に要求される機能を実現するための骨組みを設計します。例えばデータベースに求められる項目要件やテーブル構造、どの機能はどの項目と関連しているのかなど、構造化された資料として技術者に伝えるためのものに仕上げていきます。
詳細設計の外部設計
外部設計（基本設計に含まれる場合もあります）とは、操作画面などシステムの見た目を設計する工程です。デザインだけでなく、ボタンをクリックした時の挙動なども含めてユーザーインターフェースを設計します。この工程ではデザインも要求されますのでUIデザイナーも参加するケースがあります。また、操作性は常に向上されなければなりませんので、前工程でframeworkというシステム全体としての共通の動作を決める工程もあります。選択系の入力項目であればラジオボタンなのかドリルダウンなのか、メニュー画面は丈夫なのか左右のどちらかで縦に並んだ方が良いとか悪いとか、決定すべき事項、打合せすべき事項はたくさんあります。
詳細設計の内部設計
内部設計（詳細設計）とは、実現するシステムの各プログラムを設計する工程です。各プログラムが利用するデータベースや入力項目などの一つ一つの制御やAPIなどを細かく決定します。この工程では直接お客様との打合せというものはほぼありません。内部の技術者が打合せしながら進めていく事になります。お客様への納品物としてプログラム以外に設計書も要求しておくべきでしょう。理由は将来このシステム開発を担当した会社が倒産したり何らかの理由で撤退した場合にはこのドキュメントは次の新しいシステム担当をするＩＴ会社に見えることによって費用をおさえることができる可能性が高まります。そのような意味でシステム開発委託契約を締結される時は、納品成果物として、設計書、ソースプログラム、テスト仕様書、テスト結果報告書などを求めることをお忘れなく。
開発とテストの流れ
開発の事をプログラミングと言います。設計書に従って実際にコーディング（機会が判読できるコードで命令を書いていく作業）を行う工程です。プログラマーが一斉に作業を進めます。大工さんが設計書を見ながら基礎工事、柱を立てて棟上げ、大きな構造を作り上げ、その後詳細な部屋単位（メニューや機能単位）で作り上げていくイメージと同じです。徐々に形となって見えてきますので、棟上げ後に柱の位置を移動することなどは無いですよね。それと同様に、この段階になると仕様変更など後戻り（やり直し修正）が発生すると工数が増加するだけでなく、いろいろなところに影響しますので、後戻り作業が多発すると、品質が低下する可能性があります。従って前工程である設計書でのお客様確認が重要な工程という事になる理由です。また開発をする技術や言語は多岐に渡ります。そして日進月歩で新技術が次から次に発表されます。この業界では新しいものは良いという定義はありません。新しいものに飛びついても、その技術が使える技術者は発表直前では不在です。安定して活用されており、開発事例が多く、開発技術者も多いものを選択すると安心でしょう。
どんな技術を利用して、どんな言語で開発をするのか、しっかり説明をしてもらいましょう。またシステムエンジニアが作成する設計書は技術者よりのドキュメントが多く、一般の方には理解しにくいものになりがちなので、このあたりも顧客ファーストでわかりやすい資料を提供していただけるかどうかも業者選びのポイントだと言えます。後述しますが、最近では試作品を作り実際に動くものを見て頂きながら工程を進めていくプロトタイプ型のアジャイル開発手法も流行しています。
テストとは、開発したプログラムに不具合がないかチェックする工程です。単体テストと言いますが、作成したプログラム１本１本に対して、基本的に不具合が無いかどうかをチェックします。その後の工程としてプログラム同士が連携していますので、結合して相互にテストしていきます。一般的には作ったプログラマーとは別のプログラマー又はシステムエンジニアがテストを行うこともあります。不具合が見つかった場合はプログラマーが修正を担当しますが、モーラ性を担保するために、同じような箇所も横展開して不具合が無いかどうか点検をします。一般の方はテストは簡単だと思われがちですが、テスト工程に重みを置いているIT会社ほど責任があるちゃんとした会社だと言えるでしょう。お客様に納品する前の最後の工程となりますので、ここで不具合をたくさん発見することができれば品質が向上しますので、仮に不具合はゼロ件でしたという報告を聞いた時は、逆におかしいと判断すべきです。
運用・保守について
システムの運用が開始された後は、必要に応じてサポート支援を行います。本番稼働時の立会いや、教育、データ移行など、運用や保守を担当する技術者がしばらくの間はお客様がシステムに慣れるまでサポート支援します。多くの場合１か月程度で落ち着いてきますが業務やシステム規模により半年以上かかるケースもあります。安定稼働後ははシステムの緊急時のトラブル発生時に対応することになります。また上流工程でＫＰＩ等作成している場合であれば、是非費用対効果の検証を継続して行いましょう。費用をかけて開発したシステムの効果を測定することによって、次の機能追加や改善点が見えてくるものです。システムは運用とセットですから会社の業務内容の変更や拡大に伴いシステムも変化し続けなければなりません。しっかり評価を継続して実際に利用している社員にもアンケートを取るなど工夫することをお勧めいたします。
開発手法とは
ウォーターフォールモデル
ウォーターフォール型開発とは、その名前の通り水が上から下方向に流れるように上流工程から下流工程へと計画通りに進める開発手法のことです。ウォーターフォール型開発では前述した「要件定義→外部設計→内部設計→コーディング→納品」という工程が一本道のようにつながっており、途中の工程を省くことができません。また、基本的には前の工程への手戻りは想定されていないため、開発工程の途中段階で仕様変更が発生したとしても対応するのは難しい、又は対応したら追加費用が発生し、品質も悪くなる傾向があります。しかしながらこの手法は従来からの伝統的な手法であり、メリットとしては、当初に決定した開発スケジュールや開発コスト通りに開発が進められるため、管理やコントロールがしやすいという特徴があります。柔軟性に欠ける反面、計画通りに進めやすい開発手法といえるでしょう。また封建的なピラミッド構造の組織（日本式）に合うと言われています。
アジャイルモデル
アジャイル型開発は、アプリやソフトウェア開発で用いられる手法の1つです。そもそも「アジャイル」とは直訳すると「素早い」「機敏な」「頭の回転が速い」という意味があります。アジャイル型開発では、納品する機能、プロダクトまたはプロジェクトをスプリントと呼ばれる小単位に区切って開発を進めるため、言葉の意味通り素早く、短い期間でシステムを開発することが可能です。細かい単位で「計画、設計、テスト」を繰り返すことで、開発期間が短くてもより希望に適したプログラムを形成しやすくなります。端的に言えば、開発の計画を大まかに立てたうえで、「今後の仕様や設計の変更を前提に」開発を行う手法がアジャイル開発です。プロダクト開発を、その時々のニーズに合うように設計を進めることができるので、開発の途中での計画、設計変更も可能です。アジャイル開発はプロダクトを一度開発してもその後に更新したり内容を変更したりすることもできるので、より時代やニーズにあったプロダクト開発ができます。そのため、更新が必要なWebサービスやモバイルゲームなどの開発にも優れていて、常に使いやすさを意識してバージョンを更新することができるのです。都度、アップデートが必要なサービスの開発に向いています。
スパイラルモデル
スパイラルモデルとは、小さなサイクルを繰り返しながら進めていく手法です。サイクルごとに、要件定義、設計、実装、テスト、評価を実施し、開発の進捗状況やリスクを分析しながら、システムをじっくり完成させていきます。実際には、単純スパイラルモデル、拡張スパイラルモデル、反復型スパイラルモデル他、手法が更に分類されますが、プロジェクトの規模や複雑さ、要求の変化の多さなど可能性などに合わせて、適切に選択することが重要となります。小単位の機能で開発していくアジャイル開発と比較するとスパイラルモデルは、小さな単位で要件と設計、実装を繰り返すことになります。メリットとしては、要件定義と設計を繰り返しながら進めることから、要件の変更や仕様の不具合を早期に発見し、素早くその都度修正することができます。例えば、システムの要件定義が完了した後に、ユーザーから新たな要件が追加された場合等、前述したウォーターフォールモデルでは、要件定義からやり直さなければならず、開発の遅延やコストの増加につながる可能性があります。しかしながら、スパイラルモデルでは、要件定義のサイクルの中で、新たな要件を追加することができますので、要件の変更に柔軟に対応することができ、開発の遅延やコストの増加を抑えることができます。反対にスパイラルモデルのデメリットとしては、小さなサイクルを繰り返しながら開発を進めるため、開発に時間がかかったり、コストもその分余裕を持つ必要があったり、技術力の高いエンジニアが必要となります。この手法に対応できるエンジニアとしては、例えば、要件定義と設計のサイクルの中で、技術的な問題を直ぐに修正対応するためには、技術力の高いエンジニアスキルが必要となりますし、リスク評価を行うためには、リスクを評価するスキルや経験も兼ね備えた要員が必要となります。この手法が向いている分野としては、社会インフラ系では医療機器制御や航空機制御開発、ロボット開発、マーケティングを伴うWebサイトのような要求事項の変化が激しいものや運用ミスが許されないものに向いていると言われています。
プロトタイピング
プロトタイピング（prototyping）とは、新事業にともなうサービス実験や検証段階の新規ビジネスモデルなどに伴うプロダクトの開発を開始する前段階に行うことが多いです。簡易的なデザインや機能を実装した最終成果物の試作品（プロトタイプ）を用いて、試行錯誤を繰り返すことになります。紙芝居や設計書、及び図面上だけでなく、成果物により近い状態で検証・改善ができるため、より使い方（ユーザー）の立場になってサービスやプロダクトを動作可能で視覚的に開発することができます。プロトタイピングのメリットとしては最終成果物に対するイメージをより具体的に掴むことが可能になりますので、早い段階において不具合やイメージとのズレなどの修正点に気づき、完成後に手戻りをするといったリスクを防止することができます。また、クライアントのニーズを確認・調整しながら開発を進めていくため、余分なコストと労力がかかるリスクを低減することもできます。それによって開発チームメンバー間、顧客と開発メンバー間の認識にズレが生じることを最小限にすることも可能です。サービスやプロダクトの開発において仕様書や設計図だけを用いた際、それだけでは個々の認識やイメージにズレが生じ、プロジェクトの進行に支障をきたしてしまうことがありますので、有効なお薦めの手法かと考えます。しかしながらデメリットとしては、要望が次々と増えてしまったり、細かな要求をされたりしてしまうと、その都度修正が必要になりプロジェクトの進行が滞ってしまう可能性があります。そして段階的に試行錯誤を繰り返すことになり、メリットは大きい反面、それが返って開発側の工数増加にもつながりますし、修正する度に労力やコストがかかってしまい、内部ミーティング回数が増えるなど時間を浪費することにもなりかねないので、範囲と作業工数目安、及び計画を最初に決めておくことが良いでしょう。
システム開発の成功へポイント
コミュニケーションの取り方
システム開発の成功へのポイントで一番重要な要素はコミュニケーションだと言っても過言ではありません。大別するとお客様とITベンダーとのコミュニケーション、顧客企業内でのコミュニケーション、そしてベンダー内でのコミュニケーションと３階層あります。そしてプロジェクトの成功失敗要因については外的要因が多いように思われがちですが、実は内的要因であり、その中でもコミュニケーション、そして本質課題は「報告連絡相談」が重要だという事になります。言うまでもなく報連相にはポイントがあり双方で気を付ける必要があります。特に「何度注意しても改善しない」「報連相すらできない」若手社員に悩む上司は、まずは認識の違いや文化習慣、世代を理解することから始めましょう。
要件の明確化
基本設計の前工程には要件定義があります。これは開発担当者がクライアント担当者にヒアリングした内容をもとにソフトウェアに必要な機能等を盛り込んだ資料です。基本設計ではこの要件定義にもとづいて、外側から見てどのような動きをするのかを確認します。従って、上流の上流でという位置づけになり、明確でなければなりませんし、万人に理解できる資料が求められます。その為には業務フロー図もこの段階で作成することもあります。業務フロー図とは業務の内容や処理の方法などを視覚的に表現したものです。業務の開始から完了までの各プロセスを記号や図形で示して矢印で結ばれていることが一般的です。各プロセスでどのような処理を行うのか分かりやすく示せるのがメリットです。システムを利用する際の全体的な処理の流れを把握するのに役立ちます。
開発パートナー（会社）の選び方
システム開発専門の企業は開発のプロです。従って安心してシステム開発を依頼できることや、成果物のクオリティの高さは期待できます。また企業内でシステム開発に携わる人員や設備を用意する必要がないため、システム開発後に余計なコストがかかってしまうリスクも低いです。 またシステム開発を外注委託することにより、外部からITに関する最新の知識や他社事例などを含めたノウハウを得られることも魅力です。ではどんな開発パートナーを選べばよいのでしょうか。
システム開発会社はたくさんありますが、現在の日本の課題である少子高齢化労働人口減少により、エンジニア不足が問題となっています。特にアプリ開発、webシステム開発、AI開発、組込み開発、クラウド開発に関する技術は日々最新の技術が発表されており、内容次第では有名大企業でも変化に対応するリソースの確保が困難なケースもあります。また、開発会社と受託企業との契約が曖昧で、トラブルに発展したり、サービスや運用などについても協議されないまま信頼関係のみで依頼してしまって、システムが停止してしまった事件などもあります。開発パートナー会社を選定される時は、契約内容、力量、管理者のコミュニケーション能力、開発会社の業務経験、システム構築経験や開発実績、そして最後には費用見積もりが費用相場と比較して極端に安価であれば、疑う視点も必要です。少なくても３社ぐらいに声をかけて、提案してもらって予算内で業者を決定していくプロセスが重要です。
システム開発の費用と相場感
コストを左右する要因
システム開発コストは安価で品質が担保されていることに目が行きがちですが、こちらの例もマイホーム同様、どんな材料を使って、どんな工法で、どんな工夫をしているか、住居人の人数、住居人の年齢や特徴をどこまで考慮しているか？使い勝手や間取りなど生活空間は快適なのか。これと同様にシステム開発にもコストを左右する要素がたくさんあります。ベテラン技術者が担当すればコストは高くなりますし、作成する資料の精度や新規導入なのか、旧システムからの移行なのかによってもコストは変動します。従って、できるだけ詳しい見積もり項目を指定して提出してもらうようにしましょう。
費用効率の良い開発を行うには
「フレームワーク」という言葉を聞かれたことはありますか。元来、「枠組み」という意味があります。システム開発を行う際に、頻繁に必要とされる基礎的な機能をまとめて提供してくれるものです。そのため、枠組みを使ってweb開発作業（プログラミング）をするのがフレームワークになります。例えば、「人に何かを訴求するときに文章を書くコツ」として「起承転結」という考え方があります。これも一種のフレームワークと言えるでしょう。「人に何かを訴える文章」を書いたことがない！ という人でも、「起承転結」になぞらえて書けば、分かりやすい文章を書くことができます。このようにフレームワークとは、「そのルールに沿って使用することで高度な知識や技術がなくても、うまくいくように考えられた道具やツール」ということです。
プログラミング言語は、例えばコンピュータに「”おはようございます。”と表示しなさい」と、人間が命令するために使う文字や言葉と同じものです。日本語や英語中国語など普段使用する言語に種類があるように、CやJavaなどコンピュータ言語もさまざまな種類があります。それに対してフレームワークは、コンピュータ言語を使用して何かのweb開発をしたいと考えたとき、その手助けをしてくれるツールの1つです。例えば、履歴書を作成するとき、市販されているような様式や枠組みなど記載項目が初めからあるものと、真っ白な紙に枠組みから書いていくのでは、作業量は全く違いますね。フレームワークは「このように制作してください」と予めルール化されているので、利用することで開発するまでの作業量はグッと効率化されます。このようなフレームワークを利用する開発を行うことによって費用を抑制できますし、拡張性も高くなります。
まとめ
まとめ
いかがでしたでしょうか。システム開発について理解していただけましたでしょうか。現代では、ビジネスの生産性を向上するたえに、人件費をアップするために、一つ一つの業務プロセスを改善してITシステムを利用して効率化することは必須となってきております。お客様にとってはシステム開発を依頼するときには、まずは費用が一番気になるところかと思います。何もベースが無いところからお客様の要望するシステムを開発するときには、イメージと違ったとか、機能が足りないとか、機能は作ったけど使えないとか、使うことが無いとか、本番稼働後１年経過したら急にシステムのスピードが遅くなったとか、様々な事象を経験してまいりました。ソフトウェア開発及びシステム開発会社は世の中にたくさんありますが、ITの事がよくわからないお客様の事情をよく理解して、トラブルにならないようにマネジメントしてくれる会社は多くは無いです。契約をする前にお客様のニーズをくみ取れるかどうか、身の丈に合ったシステムを提案してくれるかどうかを見極めてください。契約締結をしてシステム開発工程作業中に、この技術者を変えてくれ？なんて言わないように、事前に担当するシステムエンジニアやプログラマーとも面談する方が良いと思います。また、今後検討される技術領域の中には、直近この数年先に当たり前になるであろうクラウドサービス、ChatGDPに代表されるようにAI技術についても10年以内には企業内で使いこなしているシーンが当たり前になるといっても過言ではありません。技術に使われるのではなく、使いこなしていく為に、これから一歩一歩、経営改革と業務改革とIT化、そしてDX化へ進んでいけれるように、まずは優良パートナー選びから始めましょう。
