規模はアンバランスでアンビバレント(ソフトウェア分析)
ソフトウェアの規模は桁違い
ソフトウェアの規模、例えば、プログラムのソースコード行数(SLOC: Source Lines Of Code)は、ソフトウェアシステムによって、桁違いの規模です。それも1桁とか2桁とかのおとなしい桁違いではなく、もっと大きな桁桁違いです。桁(x4)違いかもしれません。
例えて言うなら、部屋の模様替えと都市計画の違いくらいの桁違いです。箪笥を部屋のどこに配置するのか?ということと、野球スタジアムの配置くらい違います。
桁違いのソフトウェアを分析するには
部屋の模様替え計画と都市計画の手法は同じです。ってそんな訳はありません。これらは別々の手法で計画し、別々の手法で部屋や都市の模様替えをします。
これが正しい方法です。というか、部屋の模様替え計画と都市計画が同じ計画だと思っている人がいないでしょう。
1000行のトイプログラムと、100万行の魑魅魍魎プログラムは別々の手法で計測し、別々の手法で分析します。
もちろん実装も別々の手法です。要求分析からアーキテクチャ設計、コーディング、テスティング、デバッギング、運用、保守も別々の手法です。でも実際は・・・
実際は規模を気にせず分析
ところが実際は、1000行のプログラムも100万行のプログラムも、規模を(少しだけ気にしながらも)気にせずに同じように分析しています。これが実際の現場です。
これは都市計画の専門家集団が部屋の模様替えを計画し実施している、または部屋の模様替えをしている人がついでにその場の思い付きで都市計画しているようなものです。(お詫び:部屋の模様替えの専門家をディスる文章がありましたことをお詫びします。決して思い付きだけで部屋の模様替えをしている訳でありません。たぶん、きっと。)
ソフトウェア開発ではこのような規模問題があちこちにあります。気を付けて気にしてください。でも実際のところ、どうすればいいのでしょうか。
規模だけでなく開発の実態に合わせて分析
今回は規模により分析手法を変えるという結論になりそうですが、ソフトウェア開発では規模問題だけではありません。後日、紹介する予定ですが、アジャイルソフトウェア開発かウォーターフォール型開発か、フルスクラッチで作るのか、OSSやCOTSのパッケージ利用開発なのか、ノーコードやローコード開発なのか、生成AI利用開発なのかの区別問題があり、それぞれで分析手法は異なります。一緒にするのは危険です。
しかし規模による差は上記の問題を含んでいます。つまり規模別にすることで上記の区別をしなくても済む可能性があります。この意味でも規模に応じた分析は大事です。
ではどうすればいいのか?文字数が多くなってきましたので、これは後日のアジャイル開発のところで触れたいと思います。
ということで今日の結論。「ソフトウェアは規模別に分析」以上です。
マンガFAQの引用元:ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構