開発の複雑度が増すほど、コンピュータサイエンスが重要に
「端的にいえば、コンピュータサイエンスは物理法則であり、原理・理論。ソフトウェア工学は決まりや規律、プラクティスと呼ばれているものだ」
萩原氏はまず、コンピュータサイエンスとソフトウェア工学の違いや、両者の役割について説明。コンピュータサイエンスの要素としては、アルゴリズム、リソースやスケジュール管理、クラウドの分散処理などでも重要なCAP定理（FLP〔Fischer/Lynch/Paterson〕定理）、プロトコル設計などが挙げられる。一方、ソフトウェア工学には、見積もりや要求開発、概念モデリング、ALM（Application Lifecycle Management）、プロジェクト管理などがある。そして、両者に共通する部分がプログラミングだ。
工学的アプローチでは仮説・検証が重要だが、ソフトウェア工学ではその点が重視されないといわれる。
それぞれの構成要素を見ても、日本はソフトウェア工学に偏っているのがわかる。たとえば、大学院で専門的にコンピュータサイエンスを学んだとしても、ソフトウェア技術者になって開発の現場に行くと、それがほとんど活かされていないケースも多い。やはり、「コンピュータサイエンスが実務で直接的に役立つわけではない」とする傾向が強く、どうしても「組織での効率的な開発体制」「品質・生産性の向上」といった、ソフトウェア工学領域が重視される。
「もちろんそれも重要なことだが、品質などにかかわる規律の側面だけに偏重することなく、技術の方向性を決めるコンピュータサイエンスにも目を向ける必要がある」（萩原氏）
ソフトウェア工学への偏りは、萩原氏が紹介した両分野の「名著」でも明らかになった。ソフトウェア工学の名著がほとんど翻訳版であるのに対し、コンピュータサイエンスは7冊中6冊が英語版（原書）であったのだ。萩原氏によれば、コンピュータサイエンスの書籍は対象読者が少ないので部数が見込めず、もともと出版されにくいことに加え、翻訳できる人が同分野の専門家に限られ、その限られた翻訳者候補も多忙で翻訳に携わる時間が確保できないため、日本語訳が出ることはほとんど期待できないのだという。
「翻訳版を待っていても出てこないので、どうしても英語でそのまま読むことになる。敷居は高いかもしれないが、コンピュータサイエンスを理解するには、そこを乗り越えなければならない。ソフトウェア技術者としてレベルアップを図るために、ぜひチャレンジしていただきたい」（萩原氏）
なお、担当業務にもよるが、コンピュータサイエンスやソフトウェア工学の必要性を実感しにくい方も少なからずいるだろう。なぜソフトウェア技術者にこうした知識・素養が求められるのか、萩原氏は次のように説明した。
「たとえば、小規模でシンプルなWebアプリケーションなど、フレームワークでコードを自動生成して容易に開発できるような場面では、アルゴリズムがどうで、概念モデルがこうで……といった面倒なことを厳密に考える必要はない。ただし、ソフトウェア開発の複雑度が増すと、途端にそうはいかなくなる」（萩原氏）
この「ソフトウェア開発の複雑度」は、大きく4つの要素から成り立っているという。
1つは「問題領域（ドメイン）」で、IT化の対象となる領域を指す。複雑な問題領域としては、たとえば航空機や原子力発電の制御などが挙げられる。このように扱う対象自体が複雑な場合には、手軽なWebアプリケーションのように開発しようとしても当然不可能となる。
2つ目は「開発規模」で、機能数やデータ項目数、データ量、画面数といった量の問題だ。人間の理解力には限界があるので、リソースの管理をはじめ、コンピュータサイエンスやソフトウェア工学の要素が必要となってくる。
3つ目は「適応すべき複合技術」。問題領域ではなく、解決する方法の複雑度を意味する。
そして、4つ目は人間系の話で「開発組織」の複雑さだ。たとえば、ステークホルダーが非常に多い場合などは、ソフトウェア開発も難しくなる。
