アプリケーションの特性とソフトウェア開発のプロセスモデル

アプリケーションの特性に合ったソフトウェア開発プロセスモデルを選択する

ソフトウェア開発にはいくつかのプロセスモデルが存在しており、多くのチームがそれらのモデルに沿って開発を行なっています。

「ウォーターフォールモデル」や「アジャイルソフトウェア開発」は、ソフトウェア開発の関係者であれば身近なワードです。

それでは「ソフトウェアを開発するときに、どんなプロセスモデルで開発をするのが良いでしょうか?」
これは、開発プロジェクトを開始する時に重要な課題です。

この記事では、前述の課題について、 アプリケーションの特性 という観点から考えてみたいと思います。

アプリケーションの特性: 煩雑系ソフトウェアと複雑系ソフトウェア

ソフトウェアの特性は大きく分けて2つに分類できます。

1.複雑系ソフトウェア

複雑系のソフトウェアは、課題や問題点がそもそも見えていない(見えにくい)ソフトウェアを指します。
このような特性のソフトウェアは、不完全な課題に対して、解決策を模索し、トライアンドエラーを繰り返しながら潜在的な課題や問題を解決する必要があります。

2.煩雑系ソフトウェア

煩雑系のソフトウェアは、課題や問題点は既にわかっているが、因果関係が深く入り組んでいたり、一つのビジネスフローの工程が膨大であるソフトウェアを指します。
複雑な因果関係を解決するためには、専門的な分野に対する深いドメイン知識や、時間を掛けた分析・調査が必要です。

どのようなソフトウェアが複雑系、煩雑系にあたるか

1.複雑系

• 新しい技術を使ったソフトウェア
• 現在の市場にはない、新しいビジネスモデルを提供するソフトウェア
• SNSやエンタメ系のソフトウェア
• etc

複雑系ソフトウェアは、ユーザーのニーズや課題感を探り、検証するフェーズから始まります。
ユーザーが潜在的にもっている課題感に対して仮説を立て、それを検証するためにある程度、実際に試してみないとわかりません。

新しい技術とは、例えばVR、AR、ブロックチェーンなどがこれにあたるでしょう。
これらの中には、明確な課題を持って実現されているプロダクトも存在しますが、技術自体が新しいため、私達の生活のどんな課題を解決してくれるかは、まだ仮説と検証を繰り返す必要があります。

TwitterやInstagram、TicktockなどSNSと呼ばれるようなソフトウェアは、ユーザーに新しい体験を提供することで世の中に普及していきます。
前述のソフトウェアは、今でこそ多くの人が日常的に使っていますが、開発された時点では確実にヒットする保証はおそらくなかったでしょう。

ユーザーのフィードバックと改善を繰り返して、徐々に世の中に広まっていくのが複雑系のソフトウェアの特徴といえます。

2.煩雑系

• 銀行、乗り物の運行管理などの基幹系ソフトウェア
• アナログで行っている業務をデジタルで置き換えるソフトウェア(行政・医療など)
• etc

煩雑系のソフトウェアは、解決すべき問題やユーザーのニーズが明確であったり、既に業務フローが確立されています。

例えば、銀行や飛行機の運行管理など、既に世の中にある仕組みを動かソフトウェアは煩雑系と呼べるでしょう。

また、現時点ではアナログで作業している業務をデジタル化(ソフトウェア化)するようなものについてもこれにあたります。
これらのシステム化には、業務についての深いドメイン知識が必要であり、多くの分析が必要なため煩雑系と分類できます。

ソフトウェアの特性と開発プロセスモデル

複雑系ソフトウェア → アジャイルな開発モデル

課題やニーズが明確でない複雑系ソフトウェアにおいては、正確な設計は難しく、長期的な計画は立てにくい傾向があります。
綿密に計画を立てても、検証の結果次第では、何度も作り直しが発生する可能性が有るためです。

こういったソフトウェアには、開発中に発生する問題に対して「適応性」に重視したプロセスである、アジャイルな開発プロセスが向いていると言えます。

スクラムなどのフレームワークを用いることで、柔軟に「設計→開発→検証」のサイクルを繰り返し、本当に解決したい問題が見つけるまで安定した開発を行うことができます。

煩雑系なソフトウェア → シーケンシャルな開発モデル

要件が明確であり、事前にしっかりとした調査や計画が必要な煩雑系のソフトウェアには、段階的に開発工程を進めていくシーケンシャルな開発モデルが向いています。

煩雑系のソフトウェアは、多くの因果関係や依存関係が存在するため、長期的な計画でプロジェクトをコントロールしていくことで、想定外のトラブルや未発見の問題を事前にある程度見つけることができるというメリットがあります。

シーケンシャルな開発モデルの代表としては 「ウォーターフォールモデル」が一般的です。

まとめ

世の中では、「アジャイル開発は、ウォーターフォールより優れている」というような意見や「アジャイル開発は、ウォーターフォールより品質が低いので良くない」など様々な考え方が存在しています。

何が正解かは、状況によるというのが前提ではありますが「ソフトウェアの特性によって適正な開発プロセスモデルは変わってくる」というのがこの記事で言いたいことになります。

開発するソフトウェアの特性について理解することで、適切な開発プロセスを選択するための手助けになれば幸いです。

参考文献

More Effective Agile “ソフトウェアリーダー”になるための28の道標

今回の記事は、こちらの書籍で登場する 「Cynefin(カネヴィン、クネビン)」 というフレームワークを参考にさせていただきました。

Cynefinは、状況や問題を、不確実さや複雑さをもとに5つのドメインに分類するためのフレームワークで、状況や問題を以下の5つに分類しています。

• 単純
• 複雑
• 煩雑
• 混沌
• 無秩序

Cynefinを用いてアプリケーションの複雑性や不確実性については、この本の「第3章複雑さと不確実さという課題に対処する」という章に詳しく書かれています。

興味がある人は、ぜひ読んでみてください！