ITアーキテクトに必要な考え方

日経Systems2013年9月号に、「ITアーキテクトの留意点」という記事があり、参考になったのでメモ書き。

日経BP書店｜雑誌バックナンバー　-　日経ＳＹＳＴＥＭＳ2013年9月号

【1】V字形開発におけるITアーキテクトの6つのポイントが示されている。

(1)変更容易性の優先度を高くする

新規開発では、作るのに精一杯で、変更容易性まで手がまわらないのが普通だろう。
本番リリース後、障害を収束させて安定稼働させていくと、変更容易性が機能改善の柔軟性や顧客の要望を素早く実現させることに直結する。

しかし、稼働後のシステム修正は、付け焼刃的なパッチ修正が多いのが現実。
なぜなら、システムを保守するメンバーは次々に入れ替わるため、新規開発で作ったアーキテクチャは崩れてしまいがちだから。
すると、どんどん品質が劣化するし、顧客の要望を実現しようにも、改善パッチの工数がどんどん膨れ上がってしまう。
保守コストの増大は、顧客のビジネスの機会損失に直結する。

だから、アーキテクトはシステムの変更容易性を考慮したアーキテクチャ設計が必要になってくる。
ここで、システムの変更容易性は、保守性という品質特性に相当する。
つまり、アーキテクチャ設計に保守性も含める必要がある、と筆者は述べている。

僕が思うには、この発想は、おそらくソフトウェアプロダクトライン開発における共通基盤とアプリケーション基盤の区別につながっていくのだろう、と考えている。

(2)解決領域より問題領域を優先する

アーキテクチャによる解決を目指す場合、対症療法よりも根本原因の解決につながるようにすべき。
性能が悪くなる現象に対して、付け焼刃的な解決策を取るのではなく、本来はこのような解決を目指すべきだ、という方向がある、と筆者は述べている。

だが、実際の現場では、コストや納期の関係で難しいのが実情。
僕が思うに、コストや納期とアーキテクチャのトレードオフという問題があるがゆえに、根本的な解決は難しいと考えている。

(3)データベースはPushモデルよりもPullモデルにする

よくある例は、日々の業務の履歴を蓄積したトランザクションテーブルから、夜間バッチ処理で集計した結果をサマリー用テーブルへデータを作り、翌日に参照できるようにする設計が多い。
この設計にする理由は、集計結果を表示するテーブルと日々の履歴を更新するテーブルを分けることによって、性能悪化を防ぐこと。
バッチ処理だけでなく、DBの複製(レプリケーション)も同じ発想。

しかし、バッチ処理もレプリケーションもデータをPushしているのであり、本来の理想は一つのデータを加工して参照するPullモデルであるべき、と筆者は述べている。
データの整合性の観点からも、一つのDBで参照も更新もする方が、データの矛盾は起きにくい。

僕が思うに、「One Fact, One Place」というDBの設計思想から言えば、Pullモデルが本来のあるべき姿なのだろうが、実際の現場ではその発想には限界があると考えている。
やはり、リアルタイムの集計処理ではなく、日次バッチ処理で集計結果を残す場合も必要だったり、性能要件を考えると、参照系DBと更新系DBに分ける設計方法を取るのが自然だ。

(4)複雑さを生む要因を認識する

複雑さを解消するために、普通はシステムを何らかの観点で分割していく。
参照系と更新系、可用性や拡張性などの観点がある。
それによって、システムのSLAを保証したり、性能要件を実現したりする。

しかし、システムを分割するアーキテクチャは良いのだが、やり過ぎると、システムの運用が大変になってくる。
その理由は、分割したシステムの間で、データの整合性を保証する仕組みが別途必要になるからだ。
それが、システム間連携、いわゆる外部接続の機能に相当する。
外部接続は業務システムでかなり神経を使う部分だ。
だから、システム間連携をできるだけ避けて、高度な品質要求を現実的なコストで実現する方法を考えよう、と筆者は述べている。

僕が思うに、確かにそうだけれども、業務システムでは、システム間連携の機能があるかないかで、そのシステムの寿命に大きく関わると考えている。
REATやSOAPのようなリアル連携の仕組みがあれば、必要な情報をすぐに取得でき、その結果を別システムに取り込むこともできる。
あるいは、バッチ処理を使って、必要なデータをまとまって取得することで、大量データを処理することもできる。

ERPの落とし穴part3～外部システム連携がプロジェクトのボトルネック: プログラマの思索

そのような仕組みがあれば、アーキテクチャは古いけれど安定稼働しているシステムをそのまま残して、システム間連携で必要なデータを必要なタイミングで取得する方法で、安く逃げることもできる。
つまりラッピングという外部接続の技術を採用することもできるわけだ。

(5)アプリケーション資産を蓄積する

ここでの資産とは、再利用可能な資産を意味する。
筆者は、アプリケーションとインフラの分離、パッケージ製品を使った再利用、移植性の担保という観点を述べている。
例えば、クラウドによって、システムとインフラを分離でき、システムの可搬性(移植性)がやりやすくなってきた事情もある。

クラウドのもう一つの本質～ソフトウェアの可搬性を確保する: プログラマの思索

この辺りの考え方は、ソフトウェアプロダクトラインにおけるコア資産という再利用資産の形成、とか、品質特性における移植性の確保につながっていくのだろう。

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

しかし、ソフトウェアの再利用は、理想論が多すぎる。
何らかのブレークスルーが必要だろうと思う。

ソフトウェア再利用の概念: プログラマの思索

ソフトウェア部品化の幻想: プログラマの思索

(6)技術の枝葉よりも技術の根を理解する

技術の進化が激しいIT業界では、知っている量よりも学力を持続する方が重要と筆者は述べている。
つまり、特定の製品やサービスの知識に依存せず、移り変わる技術の本質を見抜く方が重要と述べている。

僕が思うに、最近のIT技術者は、技術の変化が激しいためにその流れに追いつくだけで精一杯なのが実情と考える。
だから、C++やJavaからRubyやPython、クラウド、モバイルのようにどんどん技術を追いかける方に注力せざるを得ず、上流工程に当たる業務知識の取得まで手が回らない場合が多いように思う。
Cobolで腕を鳴らしていたとしても、Javaで一流であったとしても、iPhoneやAndroidの開発では、また一から勉強し直さなくてはならない状況は多いのだ。

アジャイル開発は常識だ: プログラマの思索

だから、サービスや製品のように、ある程度のベストプラクティスが機能として詰まった形で世の中に普及する方が現実的なのだろうと思う。
その方が習得するコストが減るからだ。

【2】読んでみて参考になるけれども、アーキテクチャ設計の作業にもっとアジャイル開発のアイデアを注入できないか、という問題意識を持っている。
実際の現場では、顧客と要件定義しながら、開発チームではインフラを構築したり、フレームワークを検証するなどの並行開発をしている時が多い。

そうでなければ、外部設計が完了後に、すぐに開発に取り掛かれないからだ。
綺麗なV字形開発では、タスクの実施が遅すぎる。
デスマーチプロジェクトでは、インフラ構築やフレームワーク検証といったアーキテクチャ構築・検証作業が不十分のまま、開発に突入して、結合テスト工程で火を噴くパターンが非常に多い。

裏プロセスは並行プロセス: プログラマの思索

つまり、WF型開発であっても、成功プロジェクトの現場では、無意識のうちに並行開発という形で、アジャイル開発のアイデアを相当な部分で実施している場合が多い。
アーキテクチャの構築・検証作業をプロトタイピングという名前で、アジャイル開発に近いことを行なっているのだ。
この辺りのやり方を形式知ないし経験知としてまとめられないか、と思っている。