はじめに

業務も顧客ニーズも、想像以上のスピードで変わる時代。
いま求められているのは、変更に強く、短期間で価値を届け続けられる開発アプローチではないでしょうか。

本記事では、その実現を目指して私たちが研究・実践している「開発方法論」の考え方をご紹介します。

背景と課題

現在の開発現場では、要件変更や顧客ニーズの変化は日常茶飯事です。
しかし、従来型の大規模・モノリシックな開発では、その変化のスピードに追い付けず、柔軟に対応することが難しい場面が少なくありません。

その結果として、
・リリース遅延
・コスト超過
・実際の業務にフィットしないシステム
・顧客と開発側の認識齟齬の拡大
といった問題が発生しやすくなります。

特に大規模プロジェクトでは、ユーザが実際に動作確認を行うのが終盤の受入テスト工程になることも多く、そこで初めて認識のズレが顕在化します。
そして、わずかな要件変更であっても影響範囲は広範囲に及び、プロジェクト後半に大きな手戻りが発生してしまいます。

こうした課題を乗り越えるには、
・継続的な変更を前提にした設計・開発を行うこと
・早期に価値を提供できる仕組みを作ること
・ユーザとの認識のズレを早期に解消すること
が不可欠です。

そこで本記事では、複数の手法を組み合わせることで「変更に強く、短期間で価値を届け続ける」開発方法論をどのように実現するのかを解説していきます。

開発方法論の3つのポイント

この方法論のポイントは以下の３つです。

①業務変更に迅速かつ柔軟に対応

　― 変化を前提とした設計を行う ―
　・変わりにくいデータ中心のアプローチにより、変わりやすいプロセスや機能を優先した
　　個別最適化を回避
　・APIファーストにより、柔軟な拡張・開発効率が向上
　・ドメイン分析・マイクロサービス思想を取り入れた疎結合なシステム構成により、変更
　　時の影響範囲を局所化
業務変更が起きても「継続的に改善できる」構造を実現

②早期の価値提供

　― 短期間で「使えるもの」を届ける ―
　・ローコード/ノーコード開発×高速開発を支えるツールの組み合わせにより、開発を高速
　　化しPJ期間を短縮
ユーザ要望の変化に迅速に対応、長期開発の末に「完成したが使われない」リスクを防ぐ

高速開発を支えるツールとは？
開発を自動化・効率化し、短期間でシステム構築できるようにするツールのこと。
当社では特定のツールに固定せず、プロジェクトの特性に応じて以下例のようなツールを活用している。
・アプリケーションの自動生成ができるAI
・テーブル、画面、処理の一括生成ができるソフトウェア
・汎用的な画面テンプレート集　など

③認識齟齬をなくし、価値あるアプリを提供

　― PJ初期に実物ベースで合意形成する ―
　・プロジェクト初期段階から動く試作アプリを作成
　　ユーザが実際にアプリを使ってみながらレビューを繰り返し要件を具体化
　・試作アプリによる仕様認識合わせ後に、精度の高い見積もりを提示
「仕様通りだが期待と違う」を防ぐ、PJ遅延やコスト増等の仕様変更によるリスクを低減

変化の激しい時代において、価値を届け続けるための“構造”と“進め方”の両面を統合した開発アプローチです。

核となる設計原則

つづいて価値を届け続けるための“構造”について、設計原則を詳しく説明します。

（１）データ中心のアプローチ、変わりにくいものを先に定義/設計

データはビジネスを支える最も重要で、かつ変わりにくい資産と捉え、データを起点とした設計を採用します。
業務プロセスやUIは、ビジネスや組織の変化に伴い比較的頻繁に変わりますが、顧客情報や取引履歴などのデータは長期間にわたって使われ続けます。
そのため業務フローやUIを作り込む前に、「どのようなデータを扱う業務なのか」データに着目した業務分析を行い、データ構造を先に定義・設計することが重要と考えます。

（２）APIファースト

システム設計の初期段階で、画面やビジネスロジックよりも先に、API設計/実装を最優先する考え方です。
データ中心のアプローチを前提に、データを扱うAPIを基軸としてシステム構築を行います。

（３）ドメイン分析・マイクロサービス

小規模なサービス群を組み合わせてアプリケーションを構築するマイクロサービスを採用します。
マイクロサービスにおいて重要なのは、サービス間の依存関係を小さく保ちながら、適切な単位でサービスを分割することです。
この方法論ではこれを実現するために、ドメイン分析の結果に基づいてマイクロサービスを設計します。

ドメイン分析とは、業務を意味のある単位（ドメイン）に分解し、それぞれを独立したサービスとして設計する考え方です。
各ドメインごとにアプリケーションを分割することで、サービス間の依存関係を最小限に抑え、変更が発生した場合でも影響を特定のサービス内に閉じ込めること・並行開発をすることが可能になります。

導入メリット

この方法論によって期待される効果は以下の通りです。

・変更耐性の高いシステム構築により、継続的かつ迅速な変更・拡張が可能になる
・高速開発を実現することで、素早く価値を提供できる
・実物ベースで合意形成を行うことで、仕様変更によるPJ遅延やコスト増といったリスクを事前に防止できる

つまり、「作って終わり」ではなく、変化に適応しながら価値を届け続けられる開発へと転換できます。
変化が当たり前の時代において、この違いはプロジェクトの成功を大きく左右します。

注意点・前提

適用にあたっては２つの注意点・前提があります。

・マイクロサービスが常に最適ではない
　疎結合な設計は変更耐性を高めますが、分割単位を誤ると複雑性や運用負荷が増大するリ
　スクもあります。
　どの単位で分割するのか、どこまで独立させるのか。
　業務特性やチーム体制を踏まえた設計判断が必要になります。

・ローコード/ノーコード開発や高速開発を支えるツール活用が前提である
　早期価値提供を実現するためには、ローコードや高速開発を支えるツールの活用が重要な
　前提となります。
　開発スピードを担保できる技術との組み合わせがあってこそ、効果を最大化できます。

おわりに

開発アプローチについて、理解できたでしょうか？

変化が当たり前の時代において、
重要なのは「いかに正しく作るか」だけでなく、
「いかに変わり続けられるか」ではないでしょうか。

本記事が、開発のあり方を見直すきっかけになれば幸いです。