2022年10月20日にオンラインセミナー『Non-IT人材でもわかる！DX時代の開発プロセス講座』を開催いたしました。
この記事では当日用いた資料を公開しし、そのポイントを解説しています。
目次
なぜDX推進に開発プロセスの理解が必要なのか？
近年、人事異動などでIT領域の知見をあまり持たないままDX推進担当になってしまい、何から学び始めるべきか悩んでいる方が増えているようです。
当社へも「DX担当者になったらはじめにプログラミングを学ぶのが良いのか？」「プログラミング学習の方法を教えてほしい」などのご相談を数多くいただいています。
しかし、プログラミング学習はDXを推進する立場の方にとって重要なものではありません。もちろん、プログラミングの知識があれば助けにはなりますが、それよりもまず押さえてほしいのは「開発プロセス」についての知識です。
システム開発の全体像を掴むことで、DXプロジェクトの工程を理解し、大事なポイントは何かを想定して行動できるようになるためです。
企画や設計なしに「作る」ことはできない
システム開発のプロセスは、家を建てる工程に例えるとNon-ITの方でもわかりやすくなります。下記のように、まず内容を決めて、設計をして、その後に作る工程（プログラミングやテスト）が始まります。
開発プロセス（家を建てる工程での例え）
- 作るモノの内容を決める（建築家と間取りを決める）
- 設計する（設計士が図面におこす）
- 作る（基礎から構造、屋根、内装、外壁等を施工する）
- テストする（基礎の上に家を建てる）
プログラミングは、この工程の中で一番工程の多い「作る」の中の一部分、例えば内装工事にあたります。つまり、プログラミングの知識は全工程の中でみると小さな一要素でしかないため、ここから学び始めるのはDX推進担当者にとって決して効率的な方法ではありません。
また、プログラミング言語にはさまざまな種類があります。外国語を学ぶ際に英語、フランス語、中国語を一度に習得するのが難しいのと同じで、複数のプログラミング言語を一度に習得するのは困難といえます。
このような理由から、NCDCでは「DX推進担当として何から学び始めるべきか」というご相談に対しては、プログラミングよりも開発プロセスから学び始めることをおすすめしています。
基本的な開発プロセス
最も基本的な開発プロセスは次のとおりです。
要求定義・要件定義
一般的な開発プロセスは要求定義から始めます。ここでは、ユーザーのシステムに対する要望事項を定義します。それをシステム要件（開発すべき具体的な機能）に絞り込んで、何を作るか決めていくことを要件定義と呼びます。
基本設計・詳細設計
設計の部分は、多くの場合２つに分かれています。
基本設計はNon-ITの方でも理解できるような内容が書かれており、詳細設計はプログラマーなど専門知識を持つ人向けの指示書となっています。
開発・プログラミング
設計書をもとにプログラムを作成してアプリケーションを開発します。
単体テスト・結合テスト・総合テスト
テストについても、多くの場合は複数工程に分かれています。
単体テストでは、プログラムが動くがどうか最小単位の状態でテストを行います。
次の結合テストでは他システムとの接続テストを行い、最後の総合テストでユーザーが使う実際のシナリオを作って仕上げのテストを行います。
工程の名称は企業によって異なる場合がありますが、実施内容に大きな差異はありません。プロジェクトの内容によってはある工程が省略されたり、別工程内に包含されたりする場合もあります。
「ウォーターフォール」と「アジャイル」
前述した基本的な開発プロセスを上から順番に、後戻りすることなく進めていく手法を「ウォーターフォール型」の開発といいます。従来はシステム開発といえばこれが一般的でした。
しかし、近年はこのような開発プロセスでは期待に応えるのが難しいケースも増えてきています。特にDXのためのシステム開発においてはその傾向が強いといえます。
その代表的な要因の一つは、急速な時代の変化です。
一般的なウォーターフォール型の開発だと、開始からリリースまで1年以上かかることもよくあります。しかし、変化が早い現代では、1年かけてつくったシステムが完成時には時代遅れになるということも起こり得ます。
また、DXプロジェクトの持つ特徴もウォーターフォール型の開発に向かない理由としてよく挙げられます。
DXプロジェクトは最初に要件をしっかりと確定できない場合もあります。たとえばAIで何かを判断するようなシステムを企画しても、AIの精度が100%期待通りにはならない可能性が高く、はじめから高精度を要件として求めることは不可能といえます。この場合、ウォーターフォール型で必要となる「要件定義」を正確に行うことができないという問題が生じます。
もし高精度な判定ができるだろうと1年かけてシステム開発をした場合、出来たシステムの精度が低く使い物にならなければ1年という期間とその間の費用を無駄にしてしまいます。
このような要因から、DXに関するプロジェクトではウォーターフォール型のような従来の開発プロセスではうまくいかない場合が多いのです。
そこで、DX時代に期待されているのがアジャイル型の開発プロセスです。
アジャイル開発のメリットとデメリット
アジャイル型は、大まかな要件定義をした後、２〜4週間のスプリント（開発期間）を繰り返す開発プロセスです。
下図のとおり、ウォーターフォール型は1年以上経ってはじめて公開（動くシステムを確認）できるような流れですが、アジャイル型では２〜4週間ごとに機能が公開されていきます。
アジャイル型の開発は、はじめから「こういうシステムが完成形である」と正確な要件定義はできない前提で考えられています。定義しても短い期間で変わることがあるため、ウォーターフォール型と比較して変化に柔軟に対応することが可能です。
たとえば、AIの精度が100%ではないかもしれないという状態でも一旦動くものを作ってみて、短期間で実際に動く機能の確認を行う。確認の結果、期待通りの動作が難しければ少し改善を加えて次のスプリントでまた作ってみる。というような進め方になります。
アジャイル型の主なメリットとして、次の三つが挙げられます。
- 短期間でリリースすることが可能
- 短いサイクルで動作確認できるため、リスクを素早く発見し、対応できる
- 継続的に機能追加を行い、システムを拡張・成長させることができる
これらのメリットから、最初に要件をしっかりと確定できないことが多いDXプロジェクトにおいてはアジャイル開発の方が向いているのがわかると思います。
しかし、デメリットもあることを認識しておく必要があります。
アジャイル型の主なデメリットとしては、次の二つが挙げられます。
- ウォーターフォール型と比べ、期間もコストもかかるが多い
- ハイパフォーマンスな人材を複数名・長期間確保することが難しい
アジャイル開発はスプリント（開発期間）がずっと続いていくため、よく「終わりのない旅」に例えられます。この終わりのない旅には向き不向きがあります。
例えば、SaaS事業者は提供しているサービスを継続的に改善し続ける（新機能の追加開発を繰り返す）こと自体が本業なので、終わりのない旅であるアジャイル型の開発プロセスが向いています。
しかし、製造業の事業会社などが新規事業としてサービスを作ってみる場合は、年度や予算の区切りが決められている場合が多く、終わりのない旅は許されません。そのため、いつ何ができるのか計画できないアジャイル開発は悪く作用してしまう場合もあります。
また、IT人材不足という社会的な課題に改善の兆しが見えないため、ハイパフォーマンスなIT人材が長旅に付き合い続けるのは困難だという問題もあります。
このように、アジャイル開発の方が良いと一概にいえないデメリットも存在します。
ウォーターフォールとアジャイルの組み合わせ
それでは、どちらの開発プロセスを採用するのが望ましいのでしょうか？
ひとつの具体例として、事業会社が新しい事業の一部としてDXに取り組もうとしているケースで考えてみます。
この場合、下記のような前提条件が付くことが多いのではないでしょうか。
- 予算や期間の計画がある取り組みである。
- 要件は明確ではなく、柔軟に変わっていく必要がある。
- ハイパフォーマーのエンジニアが社内やプロジェクト内に十分いるわけではなく、外部委託が主になる。
このような条件を全てクリアするのは、ウォーターフォールでもアジャイルでも難しいといえます。
では、どうすれば条件を（ある程度）満たせるのか。一例としてNCDCがDXプロジェクトに多く採用している開発プロセスをご紹介します。
ハイブリッド型の開発プロセス
NCDCでは、基礎部分はウォーターフォール型を、応用部分はアジャイル型をというように二つの開発プロセスを組み合わせたハイブリット型の開発プロセスを採用することがよくあります。
まず、要件を基礎部分と応用部分の二つに分けます。
- 基礎部分は、絶対に欠かせない要件
- 応用部分は、必要になると思うがはじめから詳細要件まで詰めるのは難しい領域
と考えてください。
基礎部分のプロジェクトは作るものをしっかり定義してウォーターフォール型のプロセスで開発を進めます。そうすることで、コストや期間を守ってサービス公開まで行います。
その後に続く応用部分のプロジェクトはアジャイル型で、継続的・迅速に開発を進めて、順次追加機能を公開していきます。
ただ、基礎部分のプロジェクトではウォーターフォールの欠点である「最後にならないとアプリケーションを見て確認できない」という問題が起こり得るため、基礎部分のプロジェクトのうち開発フェーズのみアジャイル型のプロセスを採用することもあります。短いスプリント（開発期間）単位で開発成果物を確認しながら開発を進めるのです。これは、ウォーターフォールの中にアジャイルを組み込むという方法です。
詳しくは下図をご覧ください。
ハイブリッド型の開発プロセスのイメージ
一般的にウォーターフォールでの開発期間が終わると保守・運用フェーズに入ることが多いのですが、このハイブリッドなプロセスの場合、一次リリース後も応用部分の開発が継続するため、基礎部分のプロジェクトを運用しつつ、応用部分のプロジェクト開発も同じメンバーで行います。
その結果、別の保守要員を確保する必要がなくなり、プロジェクト運営上の安全性も確保できて品質の向上が期待できます。
ここまでウォーターフォールとアジャイルの比較を中心に開発プロセスを説明してきましたが、続いてDXプロジェクトでよく出てくるMVPやPoC、UXデザインについても説明します。
DXプロジェクトとMVP
MVP(Minimum Viable Product)とは、実行可能な最低限の機能を持った製品という意味で、2011年に発表された考え方です。当時、エリック・リースがトヨタの生産方式などを研究してサービスの新規立ち上げのフレームワークとして「リーンスタートアップ」という書籍を発表し、その書籍の中で、MVPを作ってユーザーの反応を計測し、改善案を考えることが提唱されました。
2011年から10年以上経った現在では、MVPの考え方も大きく変わってきています。
「実行可能な最低限の機能」への期待値は徐々に上がり、最低限の機能さえ動作すれば想定外の操作への対応はなくても許容するというものではなくなってきている感があります。特に、品質に厳しい日本ではMVPとはいえ最初からある程度の品質が求められるケースも多々あります。
DXプロジェクトとPoC
PoC（概念実証）とは、本格的な開発プロセスに入る前に、検証が必要と思われる内容についてのみ検証用プログラムなど作成して、フィードバックを得ることをいいます。
例えば、簡易的な仕組みをユーザーに試してもらって事業性の評価を行ったり、技術的な実現可能性を確認したりと、さまざまなタイプが考えられます。そのため、何をどの様に検証するのかをしっかり定義してPoCを行う必要があります。
また、実証する必要があるか否かを考えると、机上検証だけで十分なケースもあるため、PoCで何を作るかは、そもそも「作る」必要があるのかという点も含めて検討することが重要です。
近年は、本格的なシステム開発までしなくてもシステムの画面モックである程度の操作性を確認できるツールや、ノーコード・ローコードでアプリ開発できるツールが豊富にあります。
それらを用いてPoCを行えることもあるので、NCDCでは、できるだけ簡単に検証できる部分からはじめて、開発（プログラミング）するのは最終手段くらいのつもりでPoCを計画することをおすすめしています。
DXプロジェクトとUXデザイン
UXデザインとはユーザーエクスペリエンス（User experience）デザインの略称で、ユーザー（顧客）体験を設計することを意味します。DXの文脈でも関連して語られることの多いキーワードです。
たとえば新しいプロダクトやサービスを立ち上げても、現代は機能や性能、価格競争で差別化を図るのが難しくなっています。ユーザーも機能や性能の細かい比較より、それを使うこと得られる心地よい体験や満足感であるUXに重きを置いてモノやサービスを選んでいるといえます。
結果的に、UXを重視したモノやサービスが生き残る時代になってきています。
検証段階でも無視できないUX
下記の図は、ヘンリック氏が示したMVPのイメージを伝えるものとして有名な絵です。
例えば「運転していて楽しい車を開発したい！」というユーザーニーズがあるとします。
絵の上段のように未完成の車を途中で見せられても（１〜３のイラスト）ユーザーはそれが自分の求めているものかどうか判断できないため満足するはずもなく、しかめ面をしています。車の完成形（4のイラスト）を見てユーザーははじめて良し悪しを評価できるようになります。
一方で、絵の下段ではまずはスケートボードから始まり、少しずつ機能を拡張しながらその都度楽しく運転できるもの（最低限の機能を持ったプロダクト）を提示されるため、ユーザーはそれが自分の期待に合っているかどうか判断できます。そして機能が拡張すれば徐々に満足度が上がっていきます。
絵の下段ではスケートボードや自転車、バイクを順次ユーザーに提示して（１〜３のイラスト）、得られた評価（ユーザーの表情）を見ながら次のステップに進めていったため、最終的に「運転していて楽しい車」のひとつの正解としてオープンカーに辿り着けたのだといえます。
評価判断ができる最低限の機能（MVP）を作ってユーザーに体験してもらい、フィードバックをもらうことが大切だということをこの図は示しています。
しかし、近年はMVPとはいえ、最初から上の概念図の下段でいう自転車かバイクくらいのレベルのプロダクトを用意しないと、ユーザーから正しいフィードバックは得られない状況になってきています。
先に、本来は「実行可能な最低限の機能を持った製品」であったMVPでさえも高い品質が要求されることも多くなっていると説明しましたが、それと同じく、UXへの期待も高くなっているのです。
はじめから「これが正解」というかたち（要件）を決めてシステム開発をするのが難しいDXのプロジェクトでは、MVPやPoCの工程を挟むケースや、アジャイル型のシステム開発プロセスを採用するケースが多いと思います。
検証の段階でも、開発や継続的な改善に取り組む段階でも、UXは無視できない重要な要素となってきているため、開発プロセスの検討に際しては、早い段階でUXデザインの考え方を取り入れるなど、UXという要素を意識した進め方が重要だと思います。
DX推進やDX人材研修のご相談はNCDCへ
開発プロセスは難しいものではありません。ウォーターフォールとアジャイルのどちらが優れているかという単純な考え方ではなく、それぞれの特徴（メリット、デメリット）と自社で今後取り組むモノの特徴を考えて、最適な進め方を選ぶことが重要です。
「DXだからアジャイル型にする」、「DXだからMVPで検証する」というような固定概念に囚われず、柔軟に考えることをおすすめします。
NCDCは、豊富なDX支援の実績と知見を活かし、UXデザインの手法を用いたサービス検討からシステム開発、PoCまで一元的なご支援が可能です。 また、システム開発の内製化支援や、リスキリングなどの一環で取り組めるDX人材研修もオーダーメイドでご提供しています。
ご興味のある方は、ぜひ一度NCDCにご相談ください。
