歴史から考えるアーキテクチャとマネジメント

ソフトウェアアーキテクチャとプロジェクトマネジメントは相互に絡み合う要素です。この関係性を歴史の流れから考えていくと面白い推測が成り立ちます。

「アーキテクチャとは」というのに定まった定義はありませんが、大枠では「システムの目的や環境を前提とし、様々な利害関係者の関心事を整合させた、システムの構成や構造」のことです。

これはもちろん「あるべき姿」です。完成されたシステムには必ず構成や構造がありますが、それが「システムの目的や環境、あるいは様々な利害関係者の関心事」と完全に合致しているとは限りません。

（ソフトウェア）アーキテクチャという言葉、あるいは（ソフトウェア）アーキテクトという用語は2000年前後から一般的になってきました。逆にいえば当時は「システムの構造や構成」と「システムの目的や環境、あるいは様々な利害関係者の関心事」の不一致があったということでしょう。

では、2000年以前という時代に何があったのでしょうか？

ホストコンピューターとウォーターフォール

1980年代まではシステム開発といえばホストコンピューターが主流で、一般的な企業システムの対象は経理や会計といった事務処理が中心でした。そのため当時利用されていたCOBOLやRPGといった言語は「ファイルを入力し、加工して出力する」といった処理に最適化されています。

この時代のマネジメント手法として一般的だったのがウォーターフォールです。ウォーターフォールは要件定義＞基本設計＞詳細設計＞実装といった工程ごとに品質を保証し、次工程に進みます。このため手戻りが少なくなるとともに、前行程の成果物を分析することで次工程の計画を最適なものとできます。

ウォーターフォールの課題として指摘されるのは「前工程の品質が高いという前提が成り立たない」ことではありますが、この時代は「今よりはマシだった」というように思います。

1つ目にはホストコンピューターのメーカーを決定すれば、自動的にソフトウェアの構成や構造が決定していたから。2つ目は経理や会計といった事務処理が対象であったことです。これらによりマネジメント上のリスクを低減させることができるためです。

（もちろん「人月の神話」は1975年に書かれていますから、この時代ですらウォーターフォールは完ぺきなものではありません。しかし、人月の神話はOSの開発という特殊なコンテキストで書かれていることも理解しておくべきでしょう）

ダウンサイジングとアーキテクチャ

しかし、ネットワークによるシステム間連携が実現されてくると標準化とオープン化の波が起き、1980年代後半にはダウンサイジングと呼ばれる脱ホストコンピューターの動きが一気に広まります。

特にクライアントサーバモデルやウェブサーバモデルのような処理の分散化が一般的となり、システム構成を複雑化させました。また、同時にシステム構築費の低下により、各企業が単純な事務処理ばかりではなくフロント業務やコミュニケーション業務といった領域にもシステム化を進めます。こうした業務は企業戦略と密接に結びつくことが多いため、企業ごとに規定や規則がバラバラになってきます。

こう考えるとアーキテクチャという定義が2000年ごろに生まれてきた理由もわかります。システムの構成の決定というプロセスは、その昔「ハードウェアを選定する＝作業前に決定しているもの」であったのが、2000年ごろには「企業の業務を理解し、個別に選定していく＝作業しながら決定していくもの」というように変化していったのです。

ウォーターフォールの限界

このようにアーキテクチャの決定が作業プロセスの中に織り込まれてきたときにウォーターフォールというアプローチには限界が生じます。なぜならシステムの構成や構造が安定していないと、各工程で作った成果物の品質を保証する方法がなくなるからです。

ここであらためてソフトウェア開発とは何か、ということを考えなくてはなりません。ソフトウェアの開発は要件定義から基本設計＞詳細設計＞実装という形で「目的を実現手段に変換していく」というものです。逆にいえば実現手段に必要な要素を抽出していくことが設計の工程でもあります。単純にいえば「この画面には何があればいいか」という問いの答えるのが設計です。

ところが実現手段が曖昧なまま、つまり、画面の大きさやUIコントロールの種類や数に制約が決まっていないと前工程で設計したものが次工程で利用できるのかが保証できなくなります。広い画面や最適なUIコントロールを定義しても、それが実現手段とマッチしていなければ実現できないのです（コストと期間のバランスにおいて）。

ですが、もちろんのこと「実現手段に必要な要素の抽出」には段階があります。要件定義段階で「ボタンはいくつ必要か」を決める必要はないですし、基本設計で「どういうSQLを投げるか」は必ずしも必須な要素ではないのです。

つまり、段階的にアーキテクチャを決定しながら、実現手段への要素をそろえていくというのが必要になるのです。これはウォーターフォールとは全体を最初に考えるおという前提とは折り合いにくいものでした。

こうした背景から生まれてきたのがアジャイルです。

アジャイルの福音

アジャイルはイテレーティブなタイムボックス型管理です。何よりも素晴らしいのは不確定性を段階的に確定していくことを前提（変化ヲ抱擁セヨ）としている点でしょう。しかも、XPなどは「動くソフトウェアでユーザーと会話せよ」というプロセスを提唱しました。つまり、事前にシステム構成を確定するのではなく、作りながら考えていき、間違っていたら手戻りをしたほうが全体的にコストが低い、ということでした。これはウォーターフォールが前提として「手戻りゼロ」と根底から覆すコロンブスの卵的発想だったのです。

当時、アーキテクチャ設計に苦しんでいたエンジニアにとって、これは福音となります。ウォーターフォールを前提とすると業務もよくわからないままにシステム構成を確定的に決定する必要があります。そしてあとから変えることはできません。しかし、アジャイルであれば「とりあえず」で進めておいて、あとで間違っていることが分かれば修正すればいいのです。

この福音がこそ、アジャイルが優秀なエンジニアによって熱狂的に迎えられた利用だと考えられます。

アジャイルによるアーキテクチャ軽視

ですが、熱狂があったからこそアジャイルには暗黒面がありました。それは「アーキテクチャ設計の軽視」です。

アーキテクチャ設計の軽視とは、つまり、システムの目的や環境、そして利害関係者の関心事を理解することへの軽視です。アジャイルでは「動くソフトウェアで語る」ために、ともかく素早くシステムを作り上げることが重視されました。結果としてRailsのように高速に開発が可能なツールがもてはやされます。これらは「Railsがそもそもシステムの目的に適しているか」という視点が抜けたままソフトウェア開発に突入することを意味します。設計工程を極端に短くし、利害関係者間の合意を得ないままソフトウェアを作ってしまうのです。

こうした誤解を生んだ理由はいくつか考えられます。

1つ目はアジャイルを推進したエンジニアは優秀であり、業務を理解しながらアーキテクチャを組むことが当然であった点。彼らにとって目的に合致したシステム構成を考えるというのは「言うまでもないこと」であったように思います。

2つ目は事例として既存システム構成を前提、あるいは小規模なシステム開発などでアーキテクチャ設計の重要度が限定的である点。これはアジャイルチームがユーザー企業内の保守運用に向いているという議論からも明らかです。

やはり、どう考えても初期のXPやTDDは小さなアプリケーションを対象にしすぎており、かつ、極端すぎたのです。

アジャイルの失敗談を聞くと、その多くはアーキテクチャ設計の不在、つまり、実現性のない設計をしていたことにつきます。ですからソフトウェアが出来上がってくると矛盾が許容できなくなり、崩壊していくのです。特に大規模で複雑な案件では顕著でした。

前段に書いたようにアーキテクチャ設計を適切に実施するためにアジャイルが考えられたのだとしたら、そのアジャイルがアーキテクチャ設計を軽視するように広まってしまったのは非常に残念なことです。

プロジェクトマネジメント論によるアーキテクチャ軽視

一方で、エンタープライズ陣営もまた、別の意味でアーキテクチャ設計を軽視していました。システム開発が失敗する理由をプロジェクトマネージメントの問題として引き受けすぎたのです。

そもそもプロセスとは繰り返し実施することで効率化を図ります。これを額面通りに考えるとシステム構成を固定化しようとする圧力となります。企業においてマネジメント成果を蓄積するためにはシステム構成を安定する必要があるのです。これがプロジェクトごとにシステム構成を最適化されることを嫌い、新しい技術の導入を避けることになります。これもまたアーキテクチャ設計の軽視なのです。

これもまた皮肉な話です。システム開発の失敗が多くなったのはアーキテクチャ設計やユーザー理解が複雑になったことが主要因なのに、その根本には触れずにプロセスだけを改善しようとしたのです。

これからのアーキテクチャとマネジメント

最近になってアーキテクチャ設計の論点からマネジメント論やソフトウェア品質論を語る向きは増えてきたと言えるでしょう。

そもそもソフトウェア開発における動的要素（プロセス）と静的要素（構成や構造）は、機能という断面を通じてユーザーの要求から決定され、かつ密接にかかわります。動的要素（プロセス）と静的要素（構成や構造）のバランスをとることでしかソフトウェア開発は成功しないのです。

当然ですが、僕もこうしたバランスが理解できず、多くの失敗をしてきました。両者は切っても切れない存在です。両者の理解を深めることでアーキテクトとてしても、プロジェクトマネージャーとしても優秀になることでしょう。