2022年5月31日にオンラインセミナー『Non-IT人材でもわかる！専門家だけに依存しないDX時代のシステム開発』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。
本セミナーの主な対象は、事業部門でシステム開発を含めたDX推進に関わる方や、システム開発に初めて参画しようとしている方です。
また、DXの文脈におけるシステム開発の目的は、大きく分けて「新規サービスの創出」「業務プロセス改革」の2種類が考えられますが、ここでは主に「新規サービスの創出」を想定した解説をしていきます。
DX時代の到来によるシステム開発のあり方の変化
近年、特にDXというキーワードが注目を集めはじめてから、企業のシステム開発のあり方は大きく変化してきています。
かつてのシステム開発プロジェクトは情報システム部門が主体となって、IT知識を持った人材を中心に進めるのが主流でした。しかし、DXの文脈においてはIT人材であるか否かに関わらずシステム開発に深く関与したり、事業部門が情報システム部門を経由せず直接システム開発を外部ベンダーに依頼したりする機会が多くなってきています。
このようにシステム開発のニーズは増えている一方で、多くの費用をかけたにも関わらず思った通りのシステムができなかった等の失敗談もよく耳にします。
では、高額になりがちなITへの投資を有意義なものにするために、発注者側（特にNon-ITの事業部門）は何に気をつけてプロジェクトを進めればいいのでしょうか？
事業企画からシステム開発までの流れ
ITの専門家だけに依存しないシステム開発のポイントを知っていただくために、この先はDXプロジェクト（デジタルを活用した新規サービス創出）の一般的な流れに沿って解説していきます。
「アイディア創出」「PoC」「展開」の３つフェーズに分けて説明するので、まずは下図の流れを確認してください。
アイデア創出フェーズのポイント
アイデア創出フェーズで重要なのは、構想したアイデアをできる限り具体的なものに落とし込んでおくことです。
事業化にシステム開発が欠かせない場合、事業性評価のタイミングでシステム開発費の概算見積りをとる必要がありますが、この時にできるだけ具体的な要件を決めて見積りを依頼することが大切です。
具体的な要件がわかればITベンダーはより正確な見積りを出すことができます。一方で、漠然としてアイデアだけ伝えて見積りを依頼すると、ITベンダーは不明瞭な部分のリスクを考慮するので高い見積りが出てきがちです。
また、見積りの依頼先は、できれば情報システム部門などとの取引実績があるベンダーが良いでしょう。発注者の業務やカルチャーへの理解があるベンダーの方が、見積りの精度が高まるためです。
PoCフェーズのポイント
PoCフェーズで重要なことは、「PoCで何を検証したいか」を明確に設定することです。
検証目的に応じて必要なこと・不要なことを選別していきます。わざわざPoCで検証する必要がないと判明すれば、PoCの期間を設けず、代わりにMVP(必要最小限の機能だけを実装した製品)のリリースに踏み切るなどの進め方も考えられます。
このフェーズ以降はシステム開発の重要性が増してベンダーとの対話も多くなってきます。システムの機能に過不足が発生するのを防ぐためには、ベンダーとの継続的な対話の中で必要・不要を常に明確に伝えることが大切です。
さらに細かく噛み砕いていくと、開発ベンダーと議論すべきポイントは大きく分けて以下の５つあります。
- どこまで作るか？（機能要件）
- PoC向けの開発物の取り扱い
- どこまで作るか？（非機能要件）
- PoCのスケジュール
- どこで作るのか？
一つずつポイントを解説していきます。
1.どこまで作るか?（機能要件）
PoC用のシステムの場合あくまで検証が目的なので、「最低限どのような機能を用意すれば目的を達成できるか」を決めることが重要です。何が必要な機能なのかは検証の主体者である事業部側（発注者側）が考える必要があります。
一方で、どれだけのコストや期間がかかるかは開発ベンダーの方が詳しいので、どんな機能にしたらいくらの費用がかかるのかなど相談しながら進める必要があります。
検証の目的と、費用・期間の両者を併せて検討し、PoCを完遂できる必要最低限の開発範囲を見定めていきます。
2.PoC向けの開発物の取り扱い
PoC用に開発したものを商用への展開時も活用するのか、あくまでPoC用に用途を絞るのかを考えて、開発ベンダーと合意しておく必要があります。
PoCで作成したものをその後も活かす場合、PoC以降は差分の開発で済むため後工程のコストと期間をスリム化できる可能性が高くなります。
一方で、この方針の場合、開発初期の段階から展開を見据えた拡張性（たとえばユーザーが増えた際の対応など）の検討が必要となります。ユーザー数の増加やそれに伴う負荷の増大は、PoC時点では不確定であることが一般的で、それゆえに後になって検討不十分であったことが判明するリスクもあります。
また、PoC後にも活かすつもりで入念に拡張性を検討したとしても、PoCで看過できない大きな問題が発覚してプロジェクトが頓挫したり、機能を一から練り直すという決断を迫られたりするリスクもあります。
PoCのみに用途を絞ったシステムを用意する場合、成果物が比較的にシンプルになるため、開発コストと開発期間を圧縮し、迅速に検証を開始することができます。一方で、PoC完了後の製品開発に際してはベースとなる成果物が存在しないため、十分なコストと期間の確保が必要になります。
もちろんPoC時の設計や考え方は次開発でも踏襲できる部分はありますが、コードや環境は基本的には作り直しになります。
PoC向けの開発物の取り扱いをどちらにするかでその後の方針が大きく左右されるため、この点を曖昧にせず、開発ベンダーとも相談してしっかり検討する必要があります。
3.どこまで作るか？（非機能要件）
検証だけに用いるものであれば、非機能要件（拡張性・性能・可用性・セキュリティなど明確な「機能」として出てこない要件）は検証を遂行するための最低限の基準をクリアしていれば問題ありません。しかし、正式展開する製品には非機能要件の各側面でPoC時よりも遥かに高度かつ厳密な条件が求められることがほとんどです。
非機能要件をどこまで充実させるかによって、開発のコストと期間は大きく変動します。そのため、PoCの段階では検証の目的を達成するための最低限の非機能要件を見定めて開発ベンダーに伝えることが重要です。一方で商用も見据えるなら将来必要となる非機能要件もこの段階で検討しておく必要があります。
4.PoCのスケジュール
PoCのスケジュールは、「企画段階に開発・検証それぞれに必要な期間を見定め、全体の期間をそれぞれの工程の合算として策定する」という方針で定めるのが望ましい形です。先に企画から検証までの全体期間を定めると、開発期間が不足してしまう傾向にあります。
「全体期間を定めてから各工程に按分する」のではなく「各工程の積み上げとして全体工程を定める」のがお勧めです。
5.どこで作るか
結論からいうとできるだけクラウドを活用することがお勧めです。まずSaaSを、それが無理であればPaaSを、最後にIaaSという順で活用を検討します。
SaaSのようなできるだけ手間をかけずに使えるもので対応できるのであれば、検証開始までの期間を大きく短縮することができます。
ちなみに、ここまで主な対象として説明してきた「新規サービス創出に関するシステム開発」とは別の話ですが、「業務プロセス改革」を目的としてシステムの見直しをする際も、最近は「製品に業務を合わせる」という考え方が一般的になってきています。
展開フェーズのポイント
PoCが終わって、いざこのサービスを商用リリースしよう！というフェーズでは、展開のプランを考え、事業モデルから適切な運用方法や遂行体制を決めることが大切です。
展開の方法は、大きく分けて「ウォーターフォール的な進め方」と「アジャイル的な進め方」の２種類が考えられます。
「ウォーターフォール的な進め方」の場合、予めリリースのタイミングと各タイミングでリリースする機能を決めておき、その計画通りにシステム開発を進めます。
一定の期間で当初予定していた機能の開発・リリースを完了させ、次の段階でユーザーからの要望への対応を計画するような流れになります。リリース頻度は、半年から1年程度のサイクルで設定します。
ある程度長期の開発・改修計画に基づいて、計画通り上流から下流へ作業を進めていくタイプのプロジェクトの場合は、この進め方が適しています。
「アジャイル的な進め方」の場合、最初のリリース後はユーザーからのフィードバックに基づいてこまめに機能開発・リリースを繰り返していきます。リリース頻度は、2~4週間で設定します。
ユーザーの反応を常にウォッチし、短いサイクルでそのときに優先すべきものから開発・リリースしていくことが求められる場合、かつ、プロジェクトを推進する組織に「アジャイルな文化」が醸成されている場合は、この進め方が適しています。
この２つの方法を比較する際、開発手法としてアジャイルとウォーターフォールのどちらが優れているのかという議論になってしまいがちですが、これはあくまで手段の選択に過ぎません。
大切なのは、事業モデルから適切な方法が何かを考えることや、その進め方に必要な遂行体制を構築できるのかどうかも見極めて方針を決めることです。
システム開発のご相談はNCDCへ
日本企業ではITとビジネスが切り離されている体制が一般的であったため、ビジネス側の要求を迅速に・柔軟にシステム化することを不得手としている企業はまだまだ多いのではないかと思います。
本セミナーがこれから「ビジネスとシステムの連携」を深めていきたい方の参考になれば幸いです。
NCDCでは、新規システム構築の要件定義から開発まで一元的なご支援が可能です。
IT部門が関与せずビジネス部門のみで企画している新規デジタルサービスの支援実績も数多くありますので、どうすればビジネス部門のアイデアをうまくシステム化できるかお悩みの方はぜひお問い合わせください。
