システム開発の基礎知識! あなたの会社は外注丸投げで大丈夫?

近年話題になっているDX化や企業の内製化は、システム開発と密な関係性にあります。本記事では、これまでに行われてきたシステム開発手法の解説や、これからの開発に際してますます重要となる内製化などについて詳しく解説します。

システム開発とは

どんな企業も、経営するなかで少なからず課題を抱えています。課題の内容は業務改善が必要なものや、新規事業への参入や市場の開拓に向けたもの、時代とともに変化するコンプライアンスへの対応など多岐にわたります。そこで、こういった問題を解決するための手段が「システム開発」です。それぞれの課題に適したシステムやサービスを構築し、問題の解決をプログラム上で実現することがシステム開発の本質といえます。

システム開発の手法

システム開発の手法にはいくつかの種類があり、プロジェクトの規模や目的によって使い分けられています。ここでは、実際の開発現場で用いられている手法をそれぞれ解説します。

ウォーターフォール

ウォーターフォール型は、もっとも歴史のある開発手法です。1970年代には主要なものになっており、名前のとおり滝の水が落ちるように、開発工程を上流から下流まで細かく区切って、あらかじめ決められた順序でプロジェクトを進めます。大まかに分類した実際の作業工程は、「要件定義→設計→開発→テスト→リリース→運用・保守」といった順序となります。ウォーターフォール型は、工程を定めて進行することで見通しが立てやすいというメリットがある一方、最初に要件定義をするため、あとから変更が利きにくいというデメリットもあります。

プロトタイピング

プロトタイピング型のシステム開発は、早い段階でシステムのプロトタイプを試作し、発注側と認識をすり合わせながら開発を進める手法です。最初に大まかなシステムを作り、使用感を確認しながら細かい仕様を決めることができるため、発注側と開発側の間で見解の相違が起こりづらいというメリットがあります。プロトタイプを作る分のコストや開発側の負担はそれなりにかかりますが、プロジェクトの規模がそれほど大きくなければ、開発中の大きな修正を防ぐことができるなどメリットも大きい手法です。

スパイラルモデル

スパイラルモデル開発は、「スパイラル（螺旋）」という言葉のとおり、いくつかに分けた機能ごとに開発のPDCAサイクルを繰り返し、最終的に一つの大きなシステムを完成させる手法です。機能単位の開発工程はウォーターフォール型開発に近く、要件定義、設計、開発、テスト、発注側のレビューという流れで行われます。一度の開発ごとにレビュー段階で発注側の要望を聞くことができるため、修正点をまとめたうえで次の開発に移ることができます。

スパイラルモデルは、特に高品質な完成品が求められる大規模プロジェクトに有効と言えます。しかし、規模が大きくなればなるほど関わる人の数も増えて、プロジェクト全体の把握が難しくなったり開発工数が膨れ上がったりするため、開発期間が延びてしまうリスクがあります。

アジャイル

アジャイル開発は、「agile」という英単語から名づけられた言葉です。「機敏な」「頭の回転が速い」などの意味を持っていることから、最初に大まかな方針だけを決め、開発するシステムを機能ごとに分けて素早く工程を進めていく手法のことを指します。一見スパイラルモデルと似ているようですが、アジャイルは現在主流になっている開発手法の一つで、スパイラルモデルよりも開発の計画性を重視する特徴があります。

ウォーターフォール型の開発では、最初の段階で機能や設計を全て決定してしまうため、開発途中で仕様変更の必要があった場合に手戻りが発生してしまうデメリットがありました。一方、アジャイル開発の場合は仕様変更がある前提で進めていくため、都度修正を加えながら機能ごとのこまかいリリースを繰り返して、最終的に一つのシステムを素早く完成させることができます。

DevOps

DevOps（デブオプス）は、開発チームと運用チームが協力しながらシステム開発を行う手法のことです。アジャイル開発でも運用チームが機能テストをしたりリリースから運用・保守を行ったりしていましたが、開発とテストの速度に差があり、アジャイルの強みである俊敏性が損なわれる場合がありました。また、アジャイルがシステムやソフトウェアの開発手法改善を重視する考え方であるのに対して、DevOpsは同様の考え方をリリースや運用の段階にも拡大しています。プロダクト全体の品質保持に重きをおいて開発することで、より効率良く高品質なシステムを完成させることが期待できます。

システム開発を成功させるためのポイント

ここまでシステム開発の手法について解説しましたが、発足したプロジェクトを成功に導くポイントはどこにあるのでしょうか。本項では、システム開発にあたってまず考えるべき点について紹介します。

課題の定義づけをきっちりと行う

サービスやソフトウェアの開発を行う目的は、企業の業務改善のためであることが多いです。たとえば、ある業務においてそれまで人が行っていたことをシステムで自動化することができれば、かなりの工数削減が実現します。しかし、現実的にはすべてをシステム任せにすることはできません。

そこで、あらかじめどんな問題をどこまで、どのようにシステム化するのかを考える必要があります。逆にいえば、最初の段階で課題の定義づけをしたうえで明確なゴールを決められれば、開発プロジェクトを成功へと導く近道になります。

受注者と発注者間で密なコミュニケーションをとる

プロジェクトの発足時からシステムのリリースに至るまで、常に発注側と受注側の間で密なコミュニケーションがとられていることも、システム開発の成功のために必要です。機能や細かい仕様を決定する要件定義で緊密に連携することはもちろん大切ですが、それ以降も連絡をつづけて、双方の認識に差が生まれないように気をつけましょう。

企画立案者と開発者が異なる場合、指示書を異なった文脈で理解してしまうおそれが生じます。また、たとえ途中まで順調に開発が進んでいたとしても、いつ修正や変更が必要になるかわかりません。日頃から密なコミュニケーションをとり、イメージを共有しておけば、不測の事態がおこった場合にも迅速に適切な対応をとることができます。

システム開発を外注に丸投げするリスク

これまでにも多くの企業では、業務の一部をシステム化して改善を図る「IT化」が行われてきましたが、現在はIT化を手段とした「DX化」が注目されています。DXが成功すれば業務改善はもちろん、企業競争力の優位性を獲得したり、これまでになかったデータを用いて自社での新規開発を計画したりすることもできます。

DX化の観点でもシステムやソフトウェアの開発は重要性を増しているといえますが、その手法にはより機敏に柔軟な対応ができるアジャイル方式が求められます。プロジェクトの内容によっては外注も一つの選択肢ですが、すべてのケースで丸投げしてしまうと自社でアジャイルな開発を行うノウハウが蓄積されず、世の中のDX化から取り残されてしまうリスクがあります。

内製化をいかにして進めるか

企業がDX化の波に乗り遅れないためには内製化を進めることが重要です。ただ、すべての開発段階で内製化を検討するというように、ハードルを上げすぎる必要はありません。日本企業で内製化が進みづらい理由として主に考えられているのは、DXを担う人材の不足です。特に開発のノウハウがない企業は、0から内製化を始めることはとても難しく感じるのではないでしょうか。

社内へ無理なくノウハウを蓄積するために、システムの開発チームに自社の人材を派遣する方法もあります。派遣されたメンバーはプロジェクトに参加しながら、アジャイルな開発手法を学ぶことができ、社内へノウハウを持ち帰ることが可能です。また、直接プロジェクトに加わることでコミュニケーションも密にとることができ、より要望に沿ったシステムが完成するというメリットもあります。

日本マイクロソフトの「Cloud Native Dojo」

内製化を効率的に進めるために、専用の人材育成プログラムを用いる方法もあります。日本マイクロソフトが提供している「Cloud Native Dojo」は、提携しているパートナー企業と自社のメンバーが共同で開発を行うことで、アジャイル開発のノウハウを学ぶことができる人材育成プログラムです。

確かな技術力を持ったプロジェクトメンバーに、Azureを始めとしたクラウドネイティブサービスのコーチングをしてもらえるため、まったく知見がない状態からスタートしても、プロジェクトで協同するうちに知識を身につけることができます。もちろん「Cloud Native Dojo」における開発がゴールではなく、得た知識やノウハウを自社の内製化につなげる足がかりとすることが目標です。

まとめ

システム開発の外注は効率的な手法であるものの、自社にノウハウが蓄積せず、DX化も遅れるリスクがあります。内製化を0から始めることは簡単ではありませんが、日本マイクロソフトの「Cloud Native Dojo」なら、豊富な知見を持ったパートナー企業と協同することで自社にノウハウを蓄積させることが可能です。