SDLC の手法とはソフトウェア開発者が業界標準の SDLC フレームワークを使いこなして管理するための手順と原則を指します。
SDLC は software development life cycle (ソフトウェア開発ライフサイクル) の略で、エンジニアと開発者がソフトウェアプロジェクトのフェーズを追跡して管理する手法を指します。 一部の開発者は SDLC を科学的手法のソフトウェア開発版とみなしています。つまり、SDLC は製品リリースやアップデートのためにエンジニアが適切な手順をたどり、適切な質問を尋ねていることを確認するためのものだということです。 SDLC はバリューストリームの一例と言われることもあります。つまり、価値あるソフトウェア製品を提供するための完全なエンドツーエンドプロセスだというものです。
SDLC フレームワークには次のような 7 つの基本フェーズがあります。
- 分析 (顧客ニーズとソフトウェア要件)
- 計画の作成
- 設計の準備
- コーディング/ソフトウェア開発の開始
- テスト実施
- 展開
- 保守
ソフトウェア開発プロジェクトにおいてこのフローをたどるのは、ソフトウェアの品質を維持しながらコストを抑えて生産時間を短縮するためです。 このようなステップは会社や業界が違っても比較的標準化されていますが、このステップを完了するために用いる技法や戦略は異なるため、SDLC の手法の出番となるわけです。 この記事では SDLC を最新のソフトウェア開発環境に円滑に導入するためのさまざまな型や技法を説明します。
一般的に、ウォーターフォール型は最も古く直接的な SDLC へのアプローチであり、1 つのフェーズが終了してから次へと進みます。 各フェーズには独自のアウトラインとサブステップがあり、それが水が流れ落ちる (ウォーターフォール) のように自然に次のフェーズへと続きます。 開発チームは時間をかけて各フェーズを完了してから次のフェーズへと進みます。
この型の中心コンセプトは、1 つのフェーズを終了したら後戻りはできないということです。各ステージは前のステージの成功と情報に依存しているからです。 フェーズごとに個別の計画がありますが、その計画は前のフェーズを基に構築されています。 人によってはウォーターフォール型は机上の空論であり理想論すぎると言い、現実の複雑で動的なプロジェクトを実際に遂行するために使用することを想定していないと言います。
ウォーターフォールモデルは使用される技法と同じくらい単純明快なプロジェクトには最適です。たとえば、絶えず顧客のフィードバックを受けたり要件が変更されたりしないようなソフトウェアです。 一部の専門家は、ウォーターフォール型は柔軟性に欠けるため時代遅れだとまで言いますが、ウォーターフォール型はより新しい調整可能な SDLC 手法の基礎としての役割を果たしています。
リーン型 SDLC はリーン生産方式と同じ手順と原則を使用します。これは、無駄を省き部分より全体に注目するという手法です。 具体的には、リーン手法によってソフトウェア開発に次のような生産の原則が採用されます。
- 無駄を省く
何が不可欠な作業ですか？ 不必要な書類やミーティング、過剰な計画でチームにマルチタスクを強いて行き詰らせないようにしましょう。 - 学習の強化
プロセスの各段階に立ち会わせて常に改善を奨励します。 - 意思決定にできるだけ時間をかける
時間を最適化してタスクについてじっくり考え、労力を惜しまないことで顧客に最高の価値を確実に提供できるようにします。 - 成果の展開はできるだけ早く
時間と労力を無駄にするものを省くことで製品やアップデートのリリースを早めることが鍵となります。 - チームに権限を与え、一体感を築く
無駄を省くことはマイクロマネジメントも排除することになり、チームを信頼してコミュニケーションを取り、仕事に全力を尽くすことにつながります。 - 全体像に注目する
細部も重要ですが、進捗や目標達成を犠牲にすべきではありません。
リーン型は「もっと少ないリソースでもっと多くのことができないか」を問います。 ここでの目標は製品開発のスピードを上げてコストを抑えることです (そしてもちろん製品の性能は下げません)。 継続的な改善と尊重を通じて、顧客のためにより多くの価値を創出するための労力とリソースを最適化することを目指します。
ウォーターフォールアプローチの方が先に登場しましたが、業界全体で開発者から人気があるのはアジャイル型です。 ウォーターフォール型の手順を基礎に、チームがさらに柔軟で動的に対応できるよう支援します。 アジャイル型は適応性が高いため、イノベーション、高品質製品、そして複雑な開発プロジェクトにも対応します。
アジャイルアプローチの中心原則のひとつは、早く失敗を受け入れてよりよい結果を達成するということです。 そのために、このアプローチでは継続的なリリースサイクルを使用して、各イテレーションで前回からの小さな段階的変更を加えます。 これにより徹底した製品のテストと継続的な調整によってプロジェクトの小さなエラーを特定し、コストのかさむ大きな問題を回避します。 ステークホルダーにはこのサイクルでも常に最新情報を提供します。
アジャイル型の弱点の 1 つは、製品や機能を「完璧」にするにはどれだけの時間がかかるのか、その作業自体いつ完了するのか、という点です。 アジャイル型の拡大版が「スケールドアジャイル」型であり、チームは高品質の成果物を早く作成することに集中します。 この実践法には次のようなサブメソッドが含まれます。
エクストリームプログラミング (XP) は、十分にテストを行い柔軟性と高品質を兼ね備えた良質なコードを構築するために使用されます。 これは、ペアプログラミング、ユニットと機能テスト、継続的コミュニケーションなどの手法によって実施されます。 エクストリームプログラミングの主な価値とは次のとおりです。
- コミュニケーション
- シンプルさ
- フィードバック
- 敬意
- 勇気
このフレームワークは時間管理とスケジューリングを重視します。これはアジャイル型に通じる部分です。 カンバン方式の基本原則は、生産プロセスをビジュアルカードで追跡してサポートし、必要なステップとタイムフレームの概要をこのカードを使って示します。 このスケジューリング技法は継続的フローとサイクルタイムが決め手であり、タスクは「To-Do」、「進行中」、「レビュー中」、「完了」といった段階を進んでいきます。
スクラムもアジャイルに近いフレームワークで、時間管理に役立つだけでなく、ロールやチームコラボレーションにも注目して、生産過程でデリバリを頻繁に行えるようにするものです。 スクラムの主なコンセプトはスプリントサイクルというスピード (時間短縮) に関するものです。 スクラムベースの開発のステップ/コラボレーションには以下が含まれます。
- チームがスプリントの優先順位を特定する計画ミーティング
- チームが次のスプリントに必要な要件とリソースを検討するコミットメントミーティング
- チームが 1 日の作業量や潜在的な障害について意識の統一を図る毎日の短時間のスタンドアップミーティング
- スプリント後にチームが実装された新しい機能について話し合うデモミーティング
- 同じくスプリント後に、チームが反省点や上手くいった点と上手くいかなかった点について振り返るレトロスペクティブミーティング
イテレーションモデルでは、反復を中心にソフトウェア開発を進めます。 すべての要件について徹底した詳細なアウトラインを使用するのではなく、この開発チームはソフトウェア要件一式を試して一足飛びにテストフェーズに入り、そのプロジェクトの必須要素を徹底して評価し特定します。 このようにソフトウェアを 1 つずつ構築することで、システムの開発が完了してローンチの準備ができるまでプロジェクトは洗練され磨かれ続けます。
このイテレーションは短時間かつ安価に構築されます。この手法が持続可能である秘訣はここにあります。 反復的な SDLC 手法で考慮すべき最も重要な側面は、慎重にリソースを追跡して時間、資金、労力を無駄にしないことです。 これらのテストは進行が速いため、チームが複数のフェーズを同時に進めることも珍しくありません。
DevOps は新しい SDLC 手法のひとつで、アジャイル型とリーン型の両方から影響を受け、ソフトウェアプロジェクトの成功を最大化するために開発チームと運用チームのコラボレーションを強化します。 この 2 チームは緊密に連携して作業するため (時には 1 つのチームにまとめられることもあるため)、DevOps の実践にはより高い規律、定期的なフィードバック、プロセス改善、自動化が含まれます。
理想はこの手法が従来のマインドセットを脱却し、革新的なテクノロジーとインフラストラクチャ管理プロセスを使用して期間短縮とハイペースの生産の需要を満たすことです。 目標は時間を節約してコミュニケーションを促すことで、全員がプロジェクトの障害と優先順位を理解して、開発と運用が互いに相手を阻害しないようにすることです。
スパイラル型は柔軟性とカスタマイズがテーマです。 イテレーションモデルと同様に、スパイラル手法は反復を使用してプロジェクトの目的を固めます。 そのためにチームはプロジェクトが完結したとみなされるまで 4 つのフェーズ (計画、リスク管理、エンジニアリング、評価) を繰り返し実行します。 これによって開発者は問題を迅速に発見し、結果に満足するまで製品を磨き上げます。 スパイラルアプローチは、SDLC に汎用的なアプローチなどなく、ニーズに合わせて各プロジェクトをカスタマイズすべきだという立場を取ります。
最後に V 字モデルを紹介します。これはウォーターフォール型を現代風にアレンジしたものです。 この手法はテストを中心とし、開発プロセスの各ステージでテストが実施されます。 これが「V モデル」と呼ばれるのは validation (妥当性確認) と verification (検証) という 2 つのコンセプトを使用するためです。
妥当性確認フェーズでは、チームがプロジェクトの要件と全体設計を作成します。 妥当性確認の各フェーズは検証フェーズと相関関係にあり、検証フェーズではテストとユーザー受け入れを行います。 ウォーターフォールモデルのように、各ステージは前のステージが完了してから開始されます。 これが最も役立つのは、多数の不明な要件がある場合ですが、この直線的構造は制限的でもあります。
これらの SDLC 手法は開発チームの成功の核となる部分です。このような反復的プロセスが支出削減につながり、製品の生産期間が短縮され、ハイエンドソフトウェアをリリースできます。 アジャイルやリーンアプローチのような手法は SDLC 界でますます人気が高まっていますが、その適応力の高さが開発チームの重荷になる可能性があります。
コミュニケーションを増やし、ワークフローを簡素化し、テストを追跡し、進捗を監視するため、ServiceNow は貴社のソフトウェア開発プロセスがどれほど柔軟性が高いものでも、SDLC 手法を管理するための革新的なプラットフォームを提供します。 計画段階で既存のアジャイルツールである Jira や Azure DevOps Boards に Strategic Portfolio Management を使って容易に統合することができます。 また、ServiceNow の ITSM Pro プラットフォームの DevOps 機能を使用して DevOps パイプラインとの包括的統合も提供します。
このレベルの統合でデータの最適化を継続できるうえ、ハイエンドのアプリケーションとサービスを ServiceNow で得ることができるので、バリューストリーム管理 (VSM) の優先順位を決定してソフトウェア管理プロジェクトの作成、保守、ガバナンスを改善できます。 ServiceNow が SDLC 手法の簡素化のためにできることについて、詳細をご覧ください。