開発の複雑度が増すほど、コンピュータサイエンスが重要に
「端的にいえば、コンピュータサイエンスは物理法則であり、原理・理論。ソフトウェア工学は決まりや規律、プラクティスと呼ばれているものだ」
萩原氏はまず、コンピュータサイエンスとソフトウェア工学の違いや、両者の役割について説明。コンピュータサイエンスの要素としては、アルゴリズム、リソースやスケジュール管理、クラウドの分散処理などでも重要なCAP定理（FLP〔Fischer/Lynch/Paterson〕定理）、プロトコル設計などが挙げられる。一方、ソフトウェア工学には、見積もりや要求開発、概念モデリング、ALM（Application Lifecycle Management）、プロジェクト管理などがある。そして、両者に共通する部分がプログラミングだ。
工学的アプローチでは仮説・検証が重要だが、ソフトウェア工学ではその点が重視されないといわれる。
それぞれの構成要素を見ても、日本はソフトウェア工学に偏っているのがわかる。たとえば、大学院で専門的にコンピュータサイエンスを学んだとしても、ソフトウェア技術者になって開発の現場に行くと、それがほとんど活かされていないケースも多い。やはり、「コンピュータサイエンスが実務で直接的に役立つわけではない」とする傾向が強く、どうしても「組織での効率的な開発体制」「品質・生産性の向上」といった、ソフトウェア工学領域が重視される。
「もちろんそれも重要なことだが、品質などにかかわる規律の側面だけに偏重することなく、技術の方向性を決めるコンピュータサイエンスにも目を向ける必要がある」（萩原氏）
ソフトウェア工学への偏りは、萩原氏が紹介した両分野の「名著」でも明らかになった。ソフトウェア工学の名著がほとんど翻訳版であるのに対し、コンピュータサイエンスは7冊中6冊が英語版（原書）であったのだ。萩原氏によれば、コンピュータサイエンスの書籍は対象読者が少ないので部数が見込めず、もともと出版されにくいことに加え、翻訳できる人が同分野の専門家に限られ、その限られた翻訳者候補も多忙で翻訳に携わる時間が確保できないため、日本語訳が出ることはほとんど期待できないのだという。
「翻訳版を待っていても出てこないので、どうしても英語でそのまま読むことになる。敷居は高いかもしれないが、コンピュータサイエンスを理解するには、そこを乗り越えなければならない。ソフトウェア技術者としてレベルアップを図るために、ぜひチャレンジしていただきたい」（萩原氏）
なお、担当業務にもよるが、コンピュータサイエンスやソフトウェア工学の必要性を実感しにくい方も少なからずいるだろう。なぜソフトウェア技術者にこうした知識・素養が求められるのか、萩原氏は次のように説明した。
「たとえば、小規模でシンプルなWebアプリケーションなど、フレームワークでコードを自動生成して容易に開発できるような場面では、アルゴリズムがどうで、概念モデルがこうで……といった面倒なことを厳密に考える必要はない。ただし、ソフトウェア開発の複雑度が増すと、途端にそうはいかなくなる」（萩原氏）
この「ソフトウェア開発の複雑度」は、大きく4つの要素から成り立っているという。
1つは「問題領域（ドメイン）」で、IT化の対象となる領域を指す。複雑な問題領域としては、たとえば航空機や原子力発電の制御などが挙げられる。このように扱う対象自体が複雑な場合には、手軽なWebアプリケーションのように開発しようとしても当然不可能となる。
2つ目は「開発規模」で、機能数やデータ項目数、データ量、画面数といった量の問題だ。人間の理解力には限界があるので、リソースの管理をはじめ、コンピュータサイエンスやソフトウェア工学の要素が必要となってくる。
3つ目は「適応すべき複合技術」。問題領域ではなく、解決する方法の複雑度を意味する。
そして、4つ目は人間系の話で「開発組織」の複雑さだ。たとえば、ステークホルダーが非常に多い場合などは、ソフトウェア開発も難しくなる。
証明されたアルゴリズムを組み込んで、正常な動作を保証せよ
萩原氏は、コンピュータサイエンスの分野で扱う事象のわかりやすい例として、次のような複数プロセスの同時実行時に取りうる結果についての問題を紹介した。
プロセスhとプロセスvがwriteを同時実行しているとき、このプログラムの8行目で得られる結果は？
1. h.w[1] 2. v.w[1] 3. h.w[2] 4. h.w[3] 5. v.w[2] 6. h.w[4] 7. h.w[5] 8. Print (v.r[ ] + ”-” + h.r[ ])
「vとhがそれぞれ一番最後に書き込んだ値である「2-5」が出力されると考えがちだが、実はそうではない。複数プロセスの同時実行で取りうる結果は、一貫性モデルに依存する」と、萩原氏は説明する。
最後の書き込み「2-5」が得られるのは、条件としてLinearizabilityが保証される場合のみ。一貫性モデルがEventual Consistency（結果整合性）の場合には、取りうる結果は「0-0」「0-1」「0-2」...「1-0」「1-1」...「2-5」と、さまざまな値の組み合わせが考えられる（0は1を書き込む前の初期値）。
プロセスhとプロセスvがそれぞれ5と7で最後に書き込んだ値が出力されるとは限らない。
これがクラウドとなれば、並列で動くプロセスは2つどころではない。数十、数百のプロセスが並列で動くので、取りうる結果の組み合わせは無数に膨れ上がる。さらに現実問題として、ネットワーク遅延・切断、メッセージ喪失、動的構成変更など、さまざまな状況が想定される。すべての想定される条件に対してプログラマがテストを行うのはまず不可能だ。
こうした問題を解決する上で必要になるのが、コンピュータサイエンスにおける「Correctness Criteria」という考え方だという。前述のLinearizabilityは一貫性を与える制約で、Correctness Criteriaの一種だ。
「Correctness Criteriaを満足する、つまりコンピュータサイエンスの世界で証明されているアルゴリズムを支援する機構をアーキテクチャに組み込み、アプリケーションをその機構で実装することで、アプリケーションはアルゴリズムに基づいて正常に動作することが保証される。機構の例としては、データベースの一貫性を保証するスケジューラなどがある」（萩原氏）
さらに、コンピュータサイエンスの視点で考察すべき別の例として、萩原氏は、HbaseやCassandraなどNoSQLで実装されているアルゴリズム「LSM-Tree（Log Structured Merge-Tree）」の問題点にも触れた。
「LSM-Treeでは、データベースへの書き込み時に既存のデータを直接更新するのではなく、まずログに書き込む。既存データに対する変更は後で行うので、書き込みスループットを向上して高速化することができる。ただし、読み取り時には、ログとメモリ上のキャッシュ、ディスクの既存データを比較して、最新のデータを手繰るような処理が必要になるため、読み取りレイテンシーの予見が難しくなってしまう。ガベッジコレクションなどでもレイテンシーの予見が難しくなるが、同じようなアルゴリズムはたくさんある」（萩原氏）
つまり、コンピュータサイエンスの何らかのアルゴリズムを採用すると、「どこか他にツケがまわる」制約もあるということだ。そのような問題への対応も考える必要があるだろう。
萩原氏はまとめとして、コンピュータサイエンスとソフトウェア工学の関係を次のように整理した。
- コンピュータサイエンスの進化がアーキテクチャスタイルやプログラミングモデルを変えて、その上にノウハウとしてのプラクティスが乗る。
- ソフトウェア工学はプラクティスを体系化する枠を提供する。
「サイエンスに基づく進化によって、たとえばRDBというものが登場し、RDBに紐付くプラクティスが体系化された。同じようにNoSQLというものが出てきて、そこでプラクティスが生まれている。やはり、コンピュータサイエンスが新しいパラダイムを作り、イノベーションを牽引する主軸と考えるべき」（萩原氏）
最後に萩原氏は、これからの取り組みについて「ITのイノベーションの大半はクラウドから起こると思っている。そのため、分散システムが主要なテーマになっていく」と語り、セッションを閉じた。
日本マイクロソフト株式会社
〒108-0075 東京都港区港南 2-16-3 品川グランドセントラルタワー
TEL: 03-4332-5300 (大代表)
