プログラマの思索

平鍋さんの記事「データモデリングなきアジャイル開発は危ういか？：An Agile Way：ITmedia オルタナティブ・ブログ」がとても分かりやすかったのでメモ。

【元ネタ】
データモデリングなきアジャイル開発は危ういか？：An Agile Way：ITmedia オルタナティブ・ブログ

Twitter / akipii: とても良い記事。昔ながらの設計技法が古くなっている事実を認識すべき RT @hiranabe: 渡辺さん稲見さんへ返信ブログ書きました。「データモデリングなきアジャイル開発は危ういか？」 http://bit.ly/UsO1aA

Twitter / yusuke_arclamp: アーキテクチャ設計の生成パターンは良いのがないんだよね。結局、プロトや繰り返し開発のようにプロジェクトマネジメントでリスク回避的に選択するのがベストプラクティスになってて。

Twitter / akipii: 愚直にストーリーカードをソースへ変換して改善する方法しか見いだせていない RT @yusuke_arclamp アーキテクチャ設計の生成パターンは良いのがないんだよね。結局プロトや繰り返し開発のようにプロジェクトマネジメントでリスク回避的に選択するのがベストプラクティスになってて

Twitter / akipii:@sugimoto_kei @yusuke_arclampさんの意図は、アーキテクチャ設計には再利用可能なレベルのパターンはまだ存在しない。それ故にアジャイル開発のようなリスク回避のマネジメント手法でしか解決できないという意味だと思います。DOAも多分そのレベルではないのでしょう

Twitter / yusuke_arclamp: @sugimoto_kei @akipii リファクタリングは広範囲に影響を与える要素（利用者の多いDBやI/F）の変更には向かないというのが一般論です。横断的な要素の設計は事前にやるべきでしょうね。

Twitter / ItagakiShintaro: この辺、Unified Processで整理ついてんじゃ？アジャイリストはプロセス重視のUPは嫌いだから参考にしない? "@hiranabe: 渡辺さん稲見さんへ返信ブログ書きました。「データモデリングなきアジャイル開発は危ういか？」 http://bit.ly/UsO1aA "

アジャイル開発でも、フィーチャ駆動開発(FDD)やドメイン駆動設計(DDD)のように概念モデルを事前に作ってから開発していく開発プロセスは以前から主張されている。
だから、DOAでも同様の傾向は言えると思う。

平鍋さんの記事で面白いのは以下の部分だ。

(引用開始)
最後の但し書きについて一言。
高リスク制約と思われていたものが、最近変更コストが低くなった、という例も本当に多い。たとえば、インフラアーキテクチャの選定と構成は、クラウドが出てから本当に劇的に変わった。先日、AWSの玉川さんと話していて分かったのだが、いまや、机上の推定と計算でインフラの構成を決めているなんて時代遅れだ。クラウドでは、マシンやロードバランサー、コア数やCPUスペックまで、プログラムのように変更できる。すなわち、変更可能性が飛躍的に向上した。こうなると、「緻密に設計する」のではなく、「まずやってみる」、とか、「やって見て、足りなかったら変更する」という方が圧倒的に、コストが低い。
これは、少し年代が高い人は分かると思うが、昔はマシンの時間が高価で、コンパイルにとても時間がかかったから、机上デバッグしていたのに、今は一人ひとつのPCが当たり前になり、IDEが進化してその場でどんどんコンパイルできるようになった。こうなると、「机上デバッグ」なんてするよりも「まずはコンパイルしてみる」という方が圧倒的に生産性が高い。
そんなわけで、高リスク制約と思われているものでも、最近は後で変更が可能となってきたものが多い。それに、工夫すれば後で変更するオプションをできるだけ維持しながら開発できる。こう考えることで、できるだけ、ユーザに見える動くソフトウェアを、すばやく提供すること、すなわち、ケーキを縦に作ることが可能になってきた。
それに、クラウドをはじめ、試すコスト、はどんどん下がっている。ケーキをどれだけ縦に切れるか、その勾配はどんどん垂直に近くなっているのである。
(引用終了)

平鍋さんの指摘通り、Webシステムの基盤作りは、きちんと設計してからサーバーを構築する手法が普通だった。
だから、「設計書を作る→サーバーを構築する→構築テストを行う」というウォーターフォール型っぽい構築方法が主流だった。

何故ならば、CPUやHDD、メモリをどれくらいに確保して、サーバー台数をどれだけ確保すべきか、性能要件をきちんと設計しなければ、構築後に作り直すのはとても手間が掛かるし、コストもかかるからだ。
非機能要件は特にあらかじめ設計しなくてはならない、というのは、アーキテクチャ駆動の開発プロセスでは主流の考え方だ。

しかし、クラウドの技術が普及するに連れて、サーバーインフラもソフトウェアと同様に変更が容易になってきた。
CPUやHDD、ロードバランサーのような負荷分散もクラウドならば、簡単にスケールアップ可能だ。

すると、まずはサーバインフラを作って都度対応しながら、あるべきサーバインフラを作っていくという手法が取りやすくなる。
時代の変化が激しいからこそ、事前に作った計画に時間をかけすぎたり、事前に作った計画に固執するのが逆にリスクになっているのだ。

ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索にも書いたけれど、概念モデルを洗練させていくと「ブレイクスルー」が訪れて、設計モデルが分析モデルに変身し、本来のあるべきドメインが見えてくるという主張もある。

とはいえ、都度対応しやすい分野(文脈)もあればそうでない場合もある。
基幹系システムのように１０年間は最低使えるシステムを作る場合、１０年先を見越したシステム作りをするためにアーキテクチャ主導の設計を取る場合もあるだろう。

コンテキスト次第とはいえ、アジャイル手法が設計技法にも浸透しつつあると言えるだろう。
色々考えてみる。